MeROS: SysML-based Metamodel for ROS-based Systems

The complexity of today's robot control systems implies difficulty in developing them efficiently and reliably. Systems engineering (SE) and frameworks come to help. The framework metamodels are needed to support the standardisation and correctness of the created application models. Although the use of frameworks is widespread nowadays, for the most popular of them, Robot Operating System (ROS), a contemporary metamodel has been missing so far. This article proposes a new metamodel for ROS called MeROS, which addresses the running system and developer workspace. The ROS comes in two versions: ROS 1 and ROS 2. The metamodel includes both versions. In particular, the latest ROS 1 concepts are considered, such as nodelet, action, and metapackage. An essential addition to the original ROS concepts is the grouping of these concepts, which provides an opportunity to illustrate the system's decomposition and varying degrees of detail in its presentation. The metamodel is derived from the requirements and verified on the practical example of Rico assistive robot. The matter is described in a standardised way in SysML (Systems Modeling Language). Hence, common development tools that support SysML can help develop robot controllers in the spirit of SE.


I. INTRODUCTION
The development of civilisation has led to an increase in the importance of robotics. Many modern robotic systems are complex. To create them as effectively and reliably as possible, it is necessary to follow systems engineering (SE), where metamodels play an essential role [1], [2], [3]. Robots, especially complex ones, are mostly controlled with usage of software. Hence, in robotics, SE is inextricably linked with software engineering, where frameworks have been crucial for many years [4], [5]. Diverse robotics frameworks have been developed so far [6], [7], [8]. Some steps towards standardisation have been made in recent years, and ROS (Robot Operating System) has come to the fore. Stand-alone ROS 1 (ROS version 1) [9] is unsuitable for hard RT (Real Time) systems, so one of the solutions in practical applications (e.g., [10], [11], [12], [13], [14], [15]), is to integrate ROS 1 with Orocos [16], [17]. Over time, ROS 1 has evolved to, among other things, improve its performance. Known and crucial problems in the face of some contemporary applications (e.g. cybersecurity, RT performance) led to the development of a new version of the framework, ROS 2 [18], [19]. ROS 1 has evolved considerably from the initial distributions. Its metamodels created so far are now incomplete and outdated (sec. V). According to ROS metrics 1 , new ROS 1 distributions have practically replaced older ones in terms of distro downloads stats. Above indications point to the need to formulate an up-to-date, recent metamodel for the latest versions of ROS 1 and ROS 2, which this article undertakes by presenting the new metamodel for ROS -MeROS.
MeROS is founded on SysML (Systems Modeling Language) [27], [28], a profile of UML (Unified Modeling Language). Modelling in languages from the UML family addresses a number of important aspects of systems engineering [29]. These include the use cases [ In practice, documentation is created both prior to implementation and, in many cases, through a process of reverse engineering [30] for existing systems. Agiletype strategies involve modifying the documentation as the project develops [31].
The following presentation starts with formulating the requirements (sec. II) for the MeROS metamodel. These requirements are allocated to the metamodel that is described in sec. III. The way to present a model of a specific application based on MeROS is presented on a practical example in sec. IV. A comparison of the MeROS with similar metamodels is presented in sec. V. The paper is finalised with conclusions (sec. VI).

II. METAMODEL REQUIREMENTS
The requirements [RX] formulation process for MeROS metamodel is multi-stage and iterative. In the beginning, the initial requirements were formulated based on: (i) literature review (both scientific and ROS wiki/community sources), (ii) author experience from supervising and supporting ROS-based projects, and finally, (iii) author experience from EARL (Embodied Agent-based cybeRphysical control systems modelling Language) [24] PIM development and its applications (e.g. [23], [32], [33]). Verification of draft versions of MeROS by its practical applications led to an iterative reformulation of requirements and MeROS itself. The article presents the final version of both MeROS metamodel and the requirements it originates from.
MeROS requirements are depicted on a number of dedicated SysML diagrams. The requirements are organised in a tree-like nesting structure, with additional internal relations, and labelled following this structure. The general requirements are presented in Fig. 1. Here, and in the following diagrams, the elements (components, relations) specific for a particular version of ROS (ROS 1 or ROS 2) are labelled with an "rv" tag with the ROS version that the element is specific for. The lack of a tag means the element is general for both ROS versions.    Server manages (ii) ROS Parameters, (iii) roscore forms a collection of programs and nodes that are pre-requisites of a ROS 1-based system. Finally, (iv) ROS Namespace reflects the ROS concept to organise nodes and communication connections. Both ROS Master and rosout are executed with roscore. ROS Parameter Server is a part of ROS Master.
To achieve intuitiveness, MeROS presents a Running system structure (Fig. 4)   many communication components use the same topic both on the publisher and the subscriber side. In opposition, the expression of topic names on arrows connecting communicating components, i.e., without dedicated communication components, let to reduce the number of components needed to depict communication for many topics and a low number of communicating components. The other advantage of using dedicated communication components is that the particular connection can be split into several diagrams (e.g. ibd (internal block diagram) or sd (sequence diagram)), where the same object represents this connection in every associated diagram. Services [R4.2] and actions [R4.3] should be depicted as an addition to the presentation of the particular topics. It should be noted that rqt_graph represents actions as a number of topics and services. In MeROS, the topics and services being part of an action can be aggregated, which reduces the number of depicted connections.
The compactness and simplicity [R6] and its nesting requirements are presented in Fig. 5. There are three elements in the requirements set that satisfy the evolution of the ROS 1 finalised with its ultimate release -Noetic Ninjemys - (

A. METAMODEL COMPOSITION
The degree of specificity of a metamodel is a compromise between its comprehensiveness (and, therefore, more general formulation) and a more accurate representation of a particular subclass of specific implementations. The metamodel contains compositions of elements and other primary relationships. Attributes and operations range widely, in particular between ROS 1 and ROS 2. Hence, their inclusion would lead to overgrowth and complication of the metamodel [R6]. Models derived from the metamodel can define their operations and new relations specific to a particular system.
The SysML blocks reflect ROS concepts [R3], and their composition is depicted in bdd (block definition diagrams). The metamodel is formulated in a single SysML package. Hence, Workspaces and Intrasystems are composed into ROS System (Fig. 8). In MeROS, a Communicating Component (Fig. 9) is a crucial abstraction of a number of ROS concepts to represent their standardised role regarding communication. It should be noted that behavioural aspects of a particular model specified in MeROS can be formulated by operation specification as an act (activity), sd (sequence), or stm (state machine) diagrams. The Intrasystem is one of the aggregates added to the base ROS concepts in MeROS. For clarity, relations of Communicating Components are depicted in several diagrams. Fig. 10 considers Topics and their Data Structures. Here, the Communicating Component can act as a publisher or a subscriber.   view, ROS 1 specific Topics included in Action have their equivalents in ROS 2 specific Services. The Actions are depicted in two diagrams - Fig. 12 and Fig. 13. Similarly to Services, the Communicating Component can act as a server or a client.    Besides standard ROS communication methods, the Non-ROS are also included (e.g., http request) to achieve interfaces with Non-ROS parts of the general system. An Action Data Structure comprises data used by three of five Topics composed in Action, i.e., goal, feedback and result. Two remaining Topics, i.e., cancel and status are standardised.
The Communication Channel [34] concept depicted in Fig. 15 is introduced to aggregate specializations of ROS connection (Topic connections, Service connections, and Action connections) as well as Non-ROS Connections. The Node (Fig. 16) composes Parameters and Nodelets (the latter in ROS 1). Two specific Nodes are considered in the metamodel: ROS Master and rosout. In ROS 2, Component Container aggregates Nodes executed in a single process. The Intrasystem (Fig. 17) composes ROS and Non-ROS Communicating Component specializations as well as Connections between them. A Parameter block is introduced also for ROS 1. In ROS 2, due to safety reasons, Parameter is composed only into Nodes. Optionally Intrasystem composes the other Intrasystems. The Running System (Fig. 18) is a specialisation of the Intrasystem that can be executed. Hence, two Nodes are needed for ROS 1: rosout and ROS master. It should be noted that although MeROS could be classified as PSM, the initial, general system description with Communications Channels and Intrasystems corresponds to PIM specification. Then, the detailing of these aggregates corresponds to the transition from PIM to PSM. The way Communicating Components use various types of connections is presented in Fig. 19. Both ROS and Non-ROS Communicating Components can communicate via Non-ROS Connections, but only ROS Communicating Components use ROS Connections. The Namespace (Fig. 20) aggregates elements of the Intrasystem, but only ROS related. In opposition to the Intrasystem, the Namespace does not specialise Communicating Component. Hence, it can not act as Communicating Component. The Workspace (Fig. 21) contains of Packages that compose the files related to general ROS concepts such as Node source codes, communication structures definitions, etc.   Thanks to a dedicated component to represent communication, the diagram in Fig. 22 can be split into two considering publisher (Fig. 23) and subscriber (Fig. 24) separately, without losing information. It is especially useful when system fragments are presented after its decomposition that subdivides communication channels.

2) Service
For each ROS Service, there is at most one server and a number of clients ( Fig. 28 and Fig. 29). Service-type communication is bidirectional and realises RPC (remote procedure call).  3) Action ROS Action communication's general, simplified structure ( Fig. 30) is analogous to ROS Service. These type of presentation is universal for ROS 1 and ROS 2. An Action (Fig. 31) is based on several Topics in ROS 1, while on Topics and Services in ROS 2. In practice, to present an action-related communication compactly on sd diagram (Fig. 32) particular Topics and Services can be generalised as a request (for /goal and /cancel) and a response (for /status, /feedback and /result). It should be noted that this diagram presents the Action communication sequence in a simplified way. The detailed behaviour of the Action server and Action client in ROS 1 is specified by state machines 2 . ROS 2 Action server and Action client behaviour is analogous. Here, these two state machines are depicted in stm diagrams. In the description, in addition to the original ROS wiki presentation, the Topics are directly mentioned both in transitions and states actions. Fig. 33 depicts the ROS 1 Action server state machine. Its transitions depend on the new messages sent by the Action client or internal predicates. The ROS 1 Action client state machine (Fig. 34) depends on the server state provided by the Action server in /status Topic and internal predicates.

IV. MEROS APPLICATION A. APPLICATION HINTS
MeROS metamodel can be employed in various ways in broad context of SE. Although, it is difficult to speak of an indication of the best procedure for its application, it is possible to formulate some practical guidelines for building a particular system model based on MeROS.

B. EXEMPLARY SYSTEM
This section presents key aspects of an exemplary system development process incorporating MeROS. The exemplary system was created within the AAL INCARE project to control the Rico assistive robot (modified TIAGo platform with controller based on ROS 1) to execute transportation attendance tasks (Fig. 35). The purpose of the following description is not to document the entire system but to illustrate, by example, representative aspects of the MeROS application. The part of the application scenario is conceptually presented in Fig. 36. Here, the system («RunningSystem» :Rico) and its behaviour are formulated in a general way. An actor (e.g. an elderly person) asks the robot to move. Then, the system recognises the voice command and vocally confirms the command's acceptance. Finally, the robot executes the motion and vocally informs that the motion is finished. In the following part of the description, the «RunningSystem» :Rico and sequence diagram frame motion execution from Fig. 36 are presented in a explicit way. The block definition diagram in Fig. 37 depicts the composition of «RunningSystem» :Rico. The «RunningSystem» :Rico structure is depicted in Fig. 38. Here, and in the following diagrams, the rosout and ROS master «Node»s were omitted to make the diagrams more compact. The specific label is needed for «CommChannel», e.g., «CommChannel» :Move To to Robot Core, because this «CommChannel» is described later on. The system is based on TaskER framework [23] developed from the RAPP approach to construct systems with variable structure [21]. The role of the TaskER is to schedule a robot's tasks. It consists of (i) Task Requesters «Node»s to submit new tasks, (ii) Task Harmoniser «Node» to schedule tasks execution, (iii) dynamic «Node»s (here, «Node» :Move To) to execute a particular task on the robot hardware and (iv) cloud part, here «NonRosCompon» :Voice Recognition and Synthesis Platform. The common part of the controller is located in «Intrasystem» :Rico. Fig. 39 illustrates how various instances of the same block are depicted in the model. Two «Parameter» Objects of the same classifier :Double are composed into «Node» :MoveBase.  The part of the scenario generally described in Fig. 36 is depicted in detail in Fig. 41. The presentation remains conceptual from the behavioural point of view, but it considers the particular parts of the «RunningSystem» :Rico.
Finally, the particular communication methods are specified on the most detailed, ROS-specific level (Fig. 42). The command_motion operation includes the sequence of four steps of communication. Three Actions realise the communication, one utilised twice. The  diagram comprises extra notes that make it easier to interpret. The part of the «Workspace» :Rico that includes previously mentioned elements is presented in Fig. 43 and Fig. 44.

V. RELATED WORK
Papers in the scope of the literature review are chosen based on an intensive study of the previous scientific work in robotic systems modelling. In particular, the survey [20] is deeply analysed. As the qualification criterion for this review, the ROS metamodel was chosen that must be described using UML language or SysML language. Six papers describing five metamodels met this criterion, and all used UML to describe ROS 1. The metamodels are contrasted with the representative requirements to which MeROS is subjected (Tab. 1) and that clearly differentiate compared metamodels. For clarification, the table refers to aspects of the metamodels, which are visualised in the analysed papers' diagrams.
The authors of [26] present Ecore -the ROS 1 metamodel as the central part of the ReApp workbench created to support the efficiency of software creation for robotic systems. The metamodel is specified in a single, extensive structural diagram, with the ROS node being its central part. The diagram describes the aspects of the running system and comprises all ROS communication methods.  In the paper [35], the authors propose two methods based on the created RosSystem metamodel. It aims at the automated generation of models from manually written artefacts through static code analysis and monitoring the execution of the running system. A large part of the work is concentrated on the toolchain. This ROS metamodel is structurally specified in a UML class diagram, emphasising communication methods.
HyperFlex toolchain [36], [37] includes extensive and comprehensive metamodel addressing ROS 1 and complementary Orocos. Formerly, these two frameworks were used together to take from the RT properties of Orocos and the elasticity of ROS. The presentation of HyperFlex is complex [36], [37], and both the running system and workspace are considered. Concepts such as nodelet or metapackage are missing due to the HyperFlex period of its foundation.
RoBMEX [38] was created as a top-down methodology based on a set of domain-specific languages that enhance the autonomy of ROS-based systems by allowing the creation of missions graphically and then generating automatically executable source codes conforming to the designed missions. Hence, the ROS metamodel was extended by the upper layer with mission/task specification. The metamodel is complex and inspiring and consists of running and workspace parts. Regarding the workspace, the grouping concepts are introduced as subpackages, classified in Tab. 1 as metapackage for generality.
ROSMOD [39] is the Robot Operating System Modeldriven development tool suite, an integrated development environment for rapid prototyping componentbased software for ROS. Its internal metamodel is complex and comprises a number of standard ROS concepts and additional grouping concepts. Although the description is extensive, the ROSMOD was created in 2016, hence some current concepts are missing, like ROS actions or nodelets.

VI. CONCLUSIONS AND DISCUSSION
Diagrams are an integral part of the description of component-based robot control systems. ROS comprises rqt_graph tool that generates diagrams with the structure of the running system. This capability is readily used by software developers (e.g., [40], [41]) due to its ease of use. Unfortunately, this tool has many limitations despite its numerous advantages and configurability. Hence, in parallel to automatically generated diagrams, others are needed, some of which are based on UML/SysML. The most comprehensive modelling solutions include explicitly defined metamodels. As a novelty regarding previous works, this paper proposes an up-to-date metamodel for finale release of ROS 1 and ROS 2 supported by profile to support the metamodel application in ROS applications models. In MeROS, the metamodel of original ROS concepts is extended by the abstract grouping concepts. It lets to present part of the system in a PIM-like style instead of a platform specific -PSM.
Although the adoption of UML/SysML-based domain metamodels has many positive implications, it also has its problems and limitations. Although the diagrams can be drawn in general-purpose graphics programs, this is not advisable, especially for complex systems. Modelling software such as Enterprise Architect or Visual Paradigm is highly recommended when creating UML/SysML projects. In particular, creating a set of diagrams outside a SysML project is more time-consuming, and it is easier to introduce errors. In practice, the cost of modelling software is not a major obstacle, and its popularity makes it easier to implement its employment. A problem with SysML development environments is that they are not standardised in many aspects and vary considerably in functionality. This problem makes it difficult to use advanced features such as automatic model analysis, e.g. to check for metamodel compatibility.
There are many methodologies for conducting and documenting projects, and not all are based on languages from the UML family. In some simplification, one could say that some project teams use UML extensively while others do not at all 4 . In the case of academic robotics projects, the lack of widespread UML use in earlier years may have been partly due to their typically relatively small scope. When projects are extensive and multi-asset, and the consequences of failure are high, the use of UML allows for greater efficiency of operation and reduced risk of project failure. Hence, contemporary complex robotics projects should benefit from appropriate tools to support their guidance and documentation, as has been the case for many large-scale projects, e.g., from the space industry (e.g., [42]) or the medical industry (e.g., [43]).
Many skilful and experienced programmers have not used UML 5 . This is due to the lack of absolute necessity to use such tools both for the programming and the development of small projects. Hence, the first use of UML in a developers' team can consume a disproportionate amount of time. Another problem is the synchronisation of diagrams with source code. Here, the answer is, among other things, the appropriate level of generality of the diagrams so that unnecessary details are not mapped there. The automatic generation of code from the diagrams or the automatic generation of selected diagrams based on code can also be helpful. Finally, it is worth mentioning that UML diagrams do not constitute a complete system description. In particular, the description by diagrams can be complemented by mathematical expressions. A way of combining these two ways of description is presented in, e.g. [24]. SysML parametric diagrams also respond to this problem.
System development involves the use of a number of tools organised in toolchains. The degree of tools interaction varies. In software engineering, the aim is to create clear procedures for system development, indicating the dependencies between the successive stages of the development process. In robotics, there have been many works dedicated to toolchains (SmartMDSD [44], RobotML [45], [46]), nowadays the ROS is common middleware (e.g. [47], BRIDE [48], HyperFlex [36]). MeROS is part of the toolchain used in the Robot Programming and Machine Perception Team at Warsaw University of Technology (WUT). Currently, on the base of MeROS, the controllers are specified for the following robotic platforms: • Velma service robot [33], [25] 6 (Fig. 45a) (Custom controller based on ROS 1 and Orocos for hardware control and simulation in Gazebo), • assistive robot Rico [23], [32] 7 (Fig.45b) (Extended PAL controller based on ROS 1 and Orocos, recent works with ROS 2 in simulation), • MiniRyś -mobile robot with various modes of locomotions 8 (Custom controller based on ROS 2 for hardware control and simulation in Gazebo), • Dobot Magician -portable, 4-DOF robotic manipulator 9 (Custom controller based on ROS 2 for hardware control). At the forefront of the toolchain stays the modelling of the system with PIM using the EARL-based [24] SPSysML [49]. EARL is derived from agent theory [14], [22], [21]. Nowadays, in the intermediate stage, MeROS plays the major role as a PSM. Finally, FABRIC [13], as well as alternative approaches [50], [51] are used to support  . He is working on the modelling and design of robots and programming methods of robot control systems. The research targets service and social robots as well as didactic robotic platforms. His personal experience concerns the development and modelling of robotic frameworks, manipulator position-force and impedance control, safety in robotic research. Recently, he was the head of the WUT group in AAL -INCARE project "Integrated Solution for Innovative Elderly Care".