Software and Systems Modelinghttps://doi.org/10.1007/s10270-021-00873-2

SPEC IAL SECT ION PAPER

Bootstrapping MDE development from ROSmanual code: Part2—Model generation and leveraging models at runtime

Nadia Hammoudeh García1 · Harshavardhan Deshpande1 · André Santos2 · Björn Kahl1 ·Mirko Bordignon3

Received: 1 March 2020 / Revised: 20 January 2021 / Accepted: 6 February 2021© The Author(s) 2021

AbstractModel-driven engineering (MDE) addresses central aspects of robotics software development. MDE could enable domainexperts to leverage the expressiveness of models, while implementation details on different hardware platforms would behandled by automatic code generation. Today, despite strong MDE efforts in the robotics research community, most evidencepoints to manual code development being the norm. A possible reason for MDE not being accepted by robot softwaredevelopers could be the wide range of applications and target platforms, which make all-encompassing MDE IDEs hardto develop and maintain. Therefore, we chose to leverage a large corpus of open-source software widely adopted by therobotics community to extract common structures and gain insight on how and where MDE can support the developers towork more efficiently. We pursue modeling as a complement, rather than imposing MDE as separate solution. Our previouswork introduced metamodels to describe components, their interactions, and their resulting composition. In this paper, wepresent two methods based on metamodels for automated generation of models from manually written artifacts: (1) throughstatic code analysis and (2) by monitoring the execution of a running system. For both methods, we present tools that leveragethe potentials of our contributions, with a special focus on their application at runtime to observe and diagnose a real systemduring its execution. A comprehensive example is provided as a walk-through for robotics software practitioners.

Keywords ROS · Models · MDE · Robotics

1 Introduction

Robots are increasingly software-intensive systems. Manyinnovations in the field are algorithmic in nature and thus

Communicated by Tao Yue, Man Zhang, and Silvia Abrahao.

B Nadia Hammoudeh Garcíanadia.hammoudeh.garcia@ipa.fraunhofer.de

Harshavardhan Deshpandeharshavardhan.deshpande@ipa.fraunhofer.de

André Santosandre.f.santos@inesctec.pt

Björn Kahlbjoern.kahl@ipa.fraunhofer.de

Mirko Bordignonmirko.bordignon@ieee.org

1 Fraunhofer IPA, Institute for Manufacturing Engineering andAutomation, Stuttgart, Germany

2 INESC TEC & Universidade do Minho, Braga, Portugal

3 Google Germany GmbH, Munich, Germany

typically implemented in software. Application domainsfor robotic solutions are proliferating [32], making stockhardware platforms repurposable by means of software. Fur-thermore, the wider digitization trend affects manufacturingthrough flagship initiatives such as Industry 4.0 and putsan emphasis on robots and other mechatronic equipmentas actors in a software-centric scenario [6]. Hence, roboticssoftware engineering is a distinctly recognized field, withdedicated publishing venues, technical committees [5], andeducational curricula [8]. In the years leading up to the estab-lishment of the field, software engineering approaches withproven track records in other domains have been appliedto robotics with various degrees of technical maturity anduptake by practitioners. These include model-based tech-niques, such as model-based software product lines (SPLsapplied to robotics software, e.g., [21,31]) and model-drivenengineering integrated development environments (MDEIDEs, e.g., [45]). Meanwhile, more traditional approachesbroadly falling under the category of software frameworkshave also been proposed [19,30,39,44]. Among them, theRobot Operating System (ROS [10]) gained widespread

123

N. Hammoudeh García et al.

acceptance in research and service robotics, with increasingsigns of adoption in the industrial domain [47]. As devel-opers of robot software using traditional frameworks forproduction-grade use cases, and as researchers in model-driven engineering approaches for robotics software, weidentified possible ways to bring some advantages of model-based techniques into standard robotics software engineeringpractice. A user study documented in [45] reveals that “usingan integrated IDE for development is not yet standard”and “reuse is made on the level of libraries, but very fewcomponent-based approaches are applied”. Our experiencewhile consulting on topics centered on robotics softwareengineering for several organizations worldwide confirmsthis finding. Aiming at completely replacing manual codedevelopment with an all-encompassing MDE IDE has, fromour point of view, historically proved difficult to impossible,given the large variety of application use cases and of targetplatforms to support. We thus instead aim at enabling devel-opers to use model-based techniques as a complement, whileleveraging large, preexisting codebases, such as the corpusof open-source ROS hand-written components (more than3000 [9]), as base for new systems. Given its open-sourcenature and its federated development process, the sharingculture within the ROS community encouraged modulariza-tion of the software in order to facilitate the interoperabilitywith software artifacts developed by others. ROS is the defacto standard in robotics research, with a big user base [29](pp. 5–6, 18–20, 24, -25). Even the International FederationofRobotics (IFR) in 2019 estimates its use to program servicerobotics applications in 70% of the cases.

ROS spreads quickly exactly due to the ease of use andminimal constraints, which means that it leaves ample roomfor errors and ambiguities. Some of them can be easilydetected with a MDE approach, specifically: (1) many errors(e.g., message type mismatches) which are not detected untilruntime; (2) proliferation of overlapping interfaces, whoseconsolidation is not enforced by the ROS architecture despitethe many efforts within the community for their consolida-tion. For the ROS concrete case, but also a characteristic oflarge ecosystems, many developers are used to code manu-ally, and therefore, much of the existing available code wasmanually written. In order to address this community, wefocus our efforts, at a first instance, on automatically gener-ating architectural models of the corresponding source code,via static analysis. As a second strategy, also to improve theunderstanding of large ROS systems, whose source code isnot necessarily always available, we complement this with aruntime monitor, which automatically extracts the model ofthe running system it is started with.

After an analysis of the results and the use of the approachto analyze real use cases, we identified not only the short-comings of our approach, but we also found an interestingand promising new application domain: the diagnosis of

robotics systems at runtime. For this paper, in comparisonwith our previous publication [33], we introduce, as novelcontribution, new features to mitigate partly or completelythe limitations found for both previous efforts, i.e., (1) thetechniques to extract models and (2) the metamodels defini-tion, and also we show our first contributions to leverage ourefforts to monitor large ROS systems during their execution.

The paper is structured as follows: The next section willcover related work, while the following one will summa-rize previous metamodeling efforts directly applicable to thecontribution later presented. Section 4 presents the basisof this paper: two approaches to automatically generatearchitectural models from existing ROS software artifacts,respectively, through static analysis of source code and run-time system monitoring. Section 5 describes our publiclyavailable cloud infrastructure for extractingmodels frompro-vided source code repositories, and a first database of modelswhich was built from open-source ROS components.

To complement the description of the approaches, in Sect.6, we compare the pros and contras of both extraction meth-ods and present one of the main novel contributions of thispaper, a tool to auto-combine the results obtained by bothmethods. This tool is based on lessons learned since our firstexperiments with model extractors [33]. Section 7 presentsour second main new contribution: An adaptation of ourmetamodels to cover additional relevant runtime informa-tion required for performance analysis at system level andfirst experiments about how our models and infrastructurecan be used to diagnose the performance of a running systemduring its execution.

Finally, Sect. 8 details, based on an use-case example,how our tooling can be used to extract models with the twoapproaches and evaluates and compares the results and theirpotentials. Using the use case, it also shows how to easethe replacement of sub-components by identifying commoninteraction patterns. The Care-O-bot 4 [37], a service robotnow engineered and commercialized by the company MojinRobotics, serves as example. Its source code is publicly avail-able and hence suitable for a walk-through style tutorial,while at the same time being representative of the complex-ity of ROS code in commercially deployed robots. Section 9recapitulates our contributions and lays out some directionsfor future work.

2 Related work

Firstly, we describe the workwhich we build upon, the RobotOperating System (ROS) andHAROS, a framework for staticcode analysis. Then, we evaluate the existing technologiesrelated to our research: (1) model-driven engineering solu-tions to program robots and specially those which produceROS code and (2) efforts to monitor and diagnose ROS.

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

2.1 ROS—the Robot Operating System

ROS [10,39] is the software framework whose conceptswe target with our effort, given its popularity and hencethe impact which we can achieve among practitioners. Itcombines software written in common languages with lit-tle architectural constraints and has a federated developmentmodel, leveraging common tools to easily share such com-ponents across organizations. This resulted in fast adoptionand a large software ecosystem.

To distill the basic constituent entities from the system,we can resort to the commonly cited analogy of ROS beinga peer-to-peer network of processes exchanging and manip-ulating data (the computation graph). This results in ROSsystems designed as a collection of small, mostly indepen-dent programs called nodes that run all at the same time andcan communicatewith eachother. The communicationmech-anisms are the topic and service patterns. Complementingthese, a common ROS library offers an extra pattern, calledaction, that simulates a simple state-machine structure.

The agents of this communication are messages andservices, which consist of language-independent data struc-tures composed of primitive data types (String, Double, Int,Boolean…). Last, collections of nodes can be started throughlaunch files, which can also be used to set parameters.

In 2007, the first distribution of ROS was released, and ingeneral, the robotics community changed significantly sincethen. In 2016, the ROS 2 project has been made public, withthe main goal of adapting ROS to new needs such as improv-ing quality of ROS code and security of ROS systems.

2.2 HAROS—static code analyzer framework for ROS

HAROS1 is a plug-in-based framework whose primary focusis static analysis of ROS software [42]. Its initial iterationbrought general-purpose quality metrics, and coding stylecompliance checks into the ROS ecosystem. More recentversions backed HAROS with an internal metamodel thatcharacterizes typical source code artifacts (e.g., packagesand different kinds of source files) and runtime entities in aROS system [40] (e.g., nodes and topics). Such ametamodel,coupled with source code parsing tools, enables HAROS toreconstruct models of a ROS system via static analysis. Inparticular, HAROS can reverse-engineer the ROS computa-tion graph by parsing C++ and Python code and ROS launchfiles. Extracted models can then be graphically visualized,subject to automated analyses, or exported as raw data forother applications. In summary, HAROS aims to providesupport for the analysis and validation of the architecturaldesign of ROS applications, without requiring the executionof said applications. However, static analysis haswell-known

1 https://github.com/git-afsantos/haros.

limitations, such as values that cannot be resolved statically.HAROS developers report this in [40], as handled by explic-itly marking extracted entities as conditional or unknown,rather than raising errors, and by allowing users to aid thesystem in resolving some of these entities. Thus, it enablesboth a wider range of analyses and a partial specificationstyle, where the boundaries of analysis results can be pro-gressively pushed. Metamodeling targeting ROS systems isseparately examined in the next section.

2.3 MDE efforts on the robotics domain

Robotics systems can be seen as consisting of independentmodules and the interfaces that allow their interaction. Basedon this idea, Brugali et al. published in 2009–2010 [22,23] a broad study about the application of component-basedsoftware engineering for robotics where the benefits of thisapproach in terms of re-usability were clearly identified.

The V3CMM-3 View Component Meta-Model [18], aplatform independent modeling language, divides the devel-opment of robotics application into different views that coverthe structural and the behavioral aspects of a component-based modeling language.

The main goals of this approach are the re-usability ofmodels and facilitation ofmodel transformations; the authorsachieved them by the introduction of the standard UnifiedModelling Language (UML) as base language.

More recent efforts applying MDE to robotics are: Smart-Soft [43], a service-oriented component-based approachcovering the entire robot development process from defining“services” (datatypes and their communication properties)and “components” (computation units that consume andproduce data through “services”) to designing full systemsthat are composed of those “components”. The SmartSofttooling generates the component’s skeleton (a wrapper forthe user code), including its interfaces and patterns forcommunication, based on service, component and systemmodels that can be graphically edited. The Papyrus DSMLRobotML [26], based on Component-Port-Connector (CPC)metamodel architectures, introduces a solution to design,simulate, and deploy robot applications.

The BRICS (Best Practices in Robotics) [24] compo-nent model (BCM) combined the model-driven approachwith the separation of concerns paradigm and introduced the“5Cs” (Computation, Communication, Coordination, Con-figuration, andComposition) concept. TheBRICS IntegratedDevelopment Environment (BRIDE [25]) bridged BCM andROS using model-to-text (M2T) transformations to gener-ate ROS skeleton code to be filled by an application domainexpert. This achievedBRIDE’smain goal of “explicit separa-tion of two phases of the development process, i.e., capabilitybuilding and the system development” [25], and showed howto fit ROS in a model-based approach. However, it main-

123

N. Hammoudeh García et al.

tained a traditional MDE top-down approach with (partial)code generation from models, not allowing the import ofexisting, manually developed ROS systems.BRIDE and sim-ilar efforts generating ROS “boilerplate code” through adedicated backend leverage MDE to ease successive man-ual development, but do not allow for a development styleintermixing manual development and, for example, model-supported checking of component composition. Related tothe aim of easing the interoperability of ROS with other sys-tems, a visual modelling language was created to transformROS-specific message definitions to Robot Device InterfaceSpecification (RDIS) and vice versa, by mapping the com-munication mechanisms [36].

Estevez et al. [27,28] present a relevant example inlinewith our research to explore the advantages thatmodel-drivenengineering provides for the development of applications forthe concrete case of robotic manipulators platforms. It pro-vides a toolchain to go from Eclipse MDE models to ROScode for manipulation tasks.

The ongoing RobMoSys project [7] extends on Smart-Soft [43] and promises predictable composition of bothexisting and new components through MDE.

2.4 Monitoring and diagnosing of ROS applicationsat runtime

The ROS diagnostics system is mainly designed to collectinformation from hardware drivers and robot hardware foranalysis, troubleshooting and logging. The entire toolchainis composed of five components from interpreters of thecollected information to graphical diagnostics visualizers.The architecture of this stack is quite simple; it collectsall the information published in a specific message typecalled diagnostic_msgs/ DiagnosticStatus [3]. This informa-tion object contains the name of the device, its status and ashort data message. The developer of a driver is responsi-ble for adding the publisher with this diagnostic informationwhen implementing the driver. Some ROS applications usethis diagnostics tool not only for hardware components butalso for software components including evenmonitoring pro-grams. (An example related to our target experiment is thepackage cob_monitoring [2].) However, the main shortcom-ing of all these existing solutions is that they are specific fora concrete application and not very reusable.

The model-based diagnosis and repair [46] architecturetries to improve upon the limitations of the ROS diagnos-tics stack. It is an observer-based system that is meant tosupervise the system running under ROS. An observer is ageneral software entity that monitors a particular aspect ofthe system. There are different kinds of observers dependingon what aspect or property has to be supervised. The obser-vations are processed by a diagnostics engine, and finally,the result is published to the global topic /diagnosis. A rule

engine is used to trigger events after processing observa-tions or diagnoses. Unfortunately, the source code has aGPLv3 license, the repository link is broken and the projectis unmaintained, discouraging us to use it for our scenario.Even other introspection tools [20] monitor the metadata ofthe communication between nodes and its interfaces in termsof utilized network bandwidth, message frequency, jitter andeven latency. Though this is an important feature, this tooldoes not monitor the presence of required nodes or its inter-faces in the running system. Another discouraging aspect ofthe tool is that it defines a custom ROS message type as anoutput of its diagnosis, which makes it difficult to plug-into existing software components. However, in terms of re-usability and integration, an optimal monitoring tool shouldbe characterized by its flexibility by allowing interfacingwithsuch external tools seamlessly.

3 Previous work: ROSmetamodeling

Our previous works aimed to build upon the related work inorder to:

– leverage the many existing ROS components and famil-iarity with ROS conventions among robotics softwarepractitioners, rather than imposing, for example, a newMDE IDE;

– leverage model-based techniques to improve the under-standing of manually written code through automaticallyextracted models, and enable automated correctnesschecks before deployment;

– systematize the definition and adoption of best practicesby examination of such models, specifically with regardto interaction patterns (topics, services, messages): thisactivity currently depends largely on manual inspectionof wiki documentation, in turn to be manually main-tained.

– get a better understanding of the system architecture andfacilitate its evaluation during the execution.

One of the main motivations of this work is to facilitatethe composition of large systems, a task that ROS integratorsperform on a regular basis because of the availability and re-use of off-the-shelf components. The lack of tools to validate,create deployment artifacts and test the composition at designtime (currently a tedious trial-and-error process during theexecution of the code) represents, from our point of view,one of the biggest shortcomings of ROS.

The contributions of this paper leverage an existing fam-ily of three metamodels which we developed in previouswork [34]. These metamodels split the description of arobot system into: (1) the ROS metamodel (the mono-lithic description of ROS programs), (2) the component

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

interface metamodel (the extraction of the ROS-specific con-cepts to a generic Component-based architecture) and (3)the system metamodel (the composition of components andtheir connections). This previous work includes also threematching Xtext DSLs, which allow the user to check andvalidate against properties and constraints. All of this workis supported by an Eclipse tooling that allows the graphi-cal definition and the validation of the models, referred tohereafter as “ROS tooling”.

3.1 Metamodels

3.1.1 ROSmetamodel

The ecoreROSmetamodel describes the concepts of themainthree ROS dimensions:

– the filesystem (how code is organized and stored);– the computation graph (howsystems are split in processesand how these interact);

– the deployment mechanism (how entities are distributed,named, and accessed at runtime).

By layering such a minimal model on manually devel-oped ROS nodes and their disk location (the ROS packagecontainer), we can model also the “simple plumbing” infras-tructure, i.e., the interaction patterns, by describing thecommunication interfaces. We can further extract artifactnames as basis for describing the deployment phase.

The ROS metamodel defines the communication inter-faces by three aspects: (1) the type of communication(one-to-one, many-to-many or state machine pattern), (2) thedirection of the information (input or output), and (3) by thecommunication object (the data structure of the messagesbeing exchanged: message, service or action).

3.1.2 Component interface metamodel

With the component interface metamodel, we aim to achievetwo main goals: (1) to simplify the deployment process ofROS systems by leveraging the concept of “composition ofsub-systems” and (2) to facilitate the creation of hybrid sys-tems (in terms of interoperability with other frameworks,ideally component-based).

Given these goals and inspired by the ObjectManagementGroup (OMG) specification Deployment and Configurationof Component-based Distributed Applications [38], the pre-vious ROS metamodel (Sect. 3.1.1) was transformed to thisgeneric “standard” concept. That is, according to the OMG,“a named set of provided and required interfaces that charac-terize the behavior of a component”. To give to the reader anoverview of our component interface metamodel and simpli-fying its implementation, the component interface represents

all the ports (inputs and outputs) of a component or systemdescribing them as communication interfaces, whose basiccharacteristics are the communication pattern (how commu-nication is done) and the communication object (what datais communicated). To preserve the nature of the originalROS code, the component interface metamodel refers to theROS interfaces (i.e., topics, services, and action definitionsfrom the ROS specific model) and only adds the definition ofnamespaces for the entire component and or for each inter-face.

3.1.3 RosSystemmetamodel

The third metamodeling tool of this family makes use ofcomponent interface models to compose ROS nodes, sub-systems, and systems. Such composition is achieved in ROSthrough the use of launch files, in which the integratordefines the nodes to be started, the package containing eachof them, the arguments to be parsed and their grouping innamespaces and/or machines within which the nodes willbe started. Another common use of launch files is to definecomplex name assignments. This allows to transparentlyremap resource lookups for name “A” with resource lookups(of the same type) for name “B”. Furthermore, launch filescan be (and are commonly) recursively included from otherlaunch or XML files that configure the nodes by passing newarguments. This system, which currently has to be writtenmanually, can only be validated at runtime. The RosSystemmetamodel was created to possibly validate at design timethe respective interconnections between nodes.

For its implementation, the OMG specification “Deploy-ment and Configuration of Component-based DistributedApplications” [38] was also taken into consideration. Suchspecification defines a connection as “either a communica-tion path among the ports of two or more subcomponentsallowing them to communicate with each other, or (it is) acommunication path between an assembly’s external portsand an assembly’s subcomponents that delegates the exter-nal port’s behavior to the subcomponent’s ports”. For theROS case, this resulted in a list ofTopicConnections, Service-Connections and ActionConnections. We designed for ROSsystems ametamodel that apart of the definition of these con-nections, with their deployed name and the reference to thesender and receipt port, also includes the component inter-face metamodel. Figure 1 shows the class diagram of theRosSystem metamodel.

This simple definition fits perfectly to the ROS architec-ture and its deployment mechanisms and is powerful enoughto allow the validation of the composability of nodes and theidentification of any disparity of a communication object,i.e., the subscriber of a topic asking for a different messagetype than the one being published. The identification of suchdisparity results in an error emitted at design-time by our

123

N. Hammoudeh García et al.

Fig. 1 Class diagram of the RosSystem metamodel

ROS tooling. Without the tooling, such type checks are onlyperformed at runtime. There is no native design-time sup-port in ROS. Moreover, once the interconnection of differentROS nodes is validated, the tooling generates automaticallythe deployment artifacts code (i.e., the roslaunch file andan installation script). This avoids the need to debug errorsat runtime that are often caused by simply typing mistakesand ensures the successful connections between the definedcomponents.

3.2 ROS tooling

The ROS tooling is being developed, improved and testedfor real use cases by the German-funded research projectSeRoNet [14]. For this project, different institutions (fromresearch centers to robotics OEM companies) joined theirefforts to create a platform that unifies the developmentof robotics software supporting different middlewares likeOPC-UA [16], ROS or SmartSoft. We constantly inte-grate new applications, as a collection of plug-ins, into theSeRoNet tooling. These applications build upon our set ofmetamodels and the correspondingDSLs.These demonstratethe benefits of the combination of ROS andMDE techniques[35]. Among others benefits, we can mention:

– Diffuse ROS best practices. Promoting (with auto com-plete functions) the use of common specification patternsand the use of ROS naming conventions.

– Validation of system connections at design time. Thegrammar of our DSL for the definition of systems incor-porates rules (for disparity of communication objects oragents) to evaluate the composition of systems.

– Auto-generation of valid code; from the definition of asingle node to the composition of subsystems

– Introspection at design-time to improve the understand-ing of what will happen at runtime; graphical tools cansimulate the runtime performance of the system withoutexecuting it.

– Interoperability with other frameworks; through model-to-model techniques we demonstrate the auto-generationof bridges from ROS to other frameworks.

4 Automatedmodel generation from ROSsoftware artifacts

4.1 Method 1: static code analysis

For the code analysis, we use the framework HAROS [41].This powerful tool was designed with the main objective ofearly detection of problems during the software developmentphase, to give the user a diagnosis of the quality of the code.Supporting an extensive list of options, HAROS can be con-figured to check custom error types. For our concrete case,the analysis of the ROS code, it integrates the Bonsai [15]interface that extracts a simplified (but expressive enough forour purpose) syntax tree of the programs.

For the purposes of this work, we created a plug-in thatbuilds a model (conforming with the ROS metamodel inSect. 3.1.1) out of the simplified syntax tree of the ROS C++and Python code that the parsing and extraction functions ofHAROS yield. It extracts the name of the package that con-tains the node, the name of the artifact that runs the node, thename of the node itself, and the list of the communicationinterfaces of the node (topics, services and actions) connect-ing it to other nodes in the system, respectively, annotatedwith message types. HAROS actually extracts a consider-ably larger amount of information, which, however, is notneeded and thus not being processed by our plug-in.

The mentioned plug-in is publicly available2 and can beused for the generation of two different types of models(Sect. 3):

– ComponentmodelThismodel is generated froma singleROS node, identified by a ROS package and the name ofthe node with in the package

– RosSystem model This model describes a complete(sub) system and all its constituents. It is generated froma single ROS launch file and the packages and files ref-erenced from that launch file.

In the first case, generating a model representing a singleROS node, the scanner takes as input the name of a node andthe ROS package that contains the node. The automaticallygenerated result is a ROS model (Sect. 3.1.1) for a node inXtext grammar. By importing it into the ROS tooling, it canbe visualized and integrated with other nodes.

For the second case, generating a model representing afull RosSystem that consists of multiple nodes, the extractor

2 https://github.com/ipa320/ros-model-cloud.

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

Fig. 2 Architecture overview of the approach using HAROS to extractthe models. One parser analyzes a launch file to discover the system-level structure, i.e., RosSystemmodel and component interface models.A second parser extracts the ROS model from all discovered nodes

takes as input the name of a launch file that describes thesystem and the name of the ROS package that includes thelaunch file. The HAROS launch files parser can extract thenames of the packages used in the system and the names ofnodes that compose the full system. With the list of nodenames and packages, we recursively call the extraction ofmodels of single nodes to obtain all the required models ofdependency packages. The parser also extracts the names-pace where each node is started (instances of the source codeclasses) within a system, which we need for the Compo-nentInterfacemetamodel (Sect. 3.1.2). The generatedmodelsof individual nodes and the extracted connectivity informa-tion are then combined into the full RosSystem model (Sect.3.1.3). Figure 2 shows a schematic diagram of this approach.

Part of the technical contribution of this publication is theimprovement of HAROS for the support of ROS actions.

HAROS, being an analysis framework that heavily relieson source code parsers and static analysis, comeswith its ownset of limitations. One of the most obvious limitations is lan-guage support:HAROSonly supportsC++andPython,whileROS is a multilingual framework with client libraries forC++, Python, Lisp, Java, JavaScript, and more. Although asignificant limitation, HAROS is sufficient for our use cases,considering that C++ and Python are the main client librariesused in the community, representing 85% of the availablecode base [9], while other bindings are more experimental.

Another significant limitation of HAROS is static analysisitself. As stated in Rice’s theorem, any non-trivial semanticproperty of a program is undecidable. In this context, thismay translate to ROS topic and service names that cannotbe fully resolved, for instance, when their values are com-puted dynamically. This issue can be mitigated if developersfollow coding guidelines—making the source codemore pre-dictable, easier to fit into a pattern. The ROS community hasproposed some code quality guidelines, but these are largelyignored, resulting in a heterogeneous code base, despite some

recurring patterns (Sect. 2.2). With the advent of ROS 2—which comes with its own set of guidelines and enforcingtools out of the box [12]—we expect better overall perfor-mance, precision and recall from model extraction based onstatic analyses. At the time of writing, support for ROS2 isstill an ongoing effort for HAROS, which is able to han-dle ROS2 workspaces but lacks parsing support for the newclient libraries.

4.2 Method 2: runtime systemsmonitoring

With static analysis being the most convenient approach toextract models from source code, we also pursued the goalof automated generation of models from ROS artifacts foralready deployed, running systems. The idea is to monitor arunningROS systemand inspect the communication betweenall its executing programs in order to extract the nodes, com-ponents, and system models, to then import them into themetamodels ecosystem of the ROS tooling. With this com-plementary approach, we cover the following use cases:

– Non-open-source software (OSS) Although ROS code isoften OSS, the ROS framework is also used for com-mercial applications where, due to business reasons orlicensing matters, the source code is not available andthe end user can only run the pre-compiled binary code.

– Unsupported ROS distributions The model extractor wasdeveloped for the newest ROS distribution. However,since the first ROS release (March 2010), the frameworkevolved in different distributions (13 in total at the timeof this writing) with only the last 3 being maintained.

For this contribution, we use a simple introspectionmethod: we analyze all the running nodes and their callsthrough the ROS master (i.e., the central broker for commu-nications between nodes).

As explained in Sect. 3, the starting point of our architec-ture is a definition of a node based on two criteria: (1) thefile system level and (2) the computational level. Unfortu-nately, with the current implementation of the runtimemodelextractor (using exclusively ROS framework sources) wecannot obtain the first item, i.e., we are not able to extract theinformation about how the software is saved, distributed, ororganized on the disk. A future improvement of this approachcombining the information we get from ROS (the currentmonitor) with the one that a Linux tool to manage processesprovide (i.e., path to the executable file) could help to obtainfurther information and complete the model.

In order to comply with the architecture and to allowinteroperability and full integration of models generatedautomatically through the runtime inspection method, theanalysis at runtime generates in addition to the systemmodelan artificial (fictitious) instance of the ROS model for each

123

N. Hammoudeh García et al.

Fig. 3 Extracting models using the runtime model extractor. Only thesystem and component interface model can be deduced using ROS’introspection methods

node found by tracing the computation graph as availablefrom the ROS master node. This allows to generate the fullmodel as depicted in Fig. 2 although the runtime monitor canonly “see” the system level including node interconnectivity,see Fig. 3. For the ROS model, a fictitious ROS package isdefined to hold all the nodes and their interface descriptions.In this generated model, we see one of the limitations of thisapproach: the runtime monitor cannot differentiate the infor-mation of two of the ROS dimensions: the deployment andthefilesystem level.More specifically, it cannot disambiguatewhether a node was launched on a specific namespace, orwhether the original source code already identified the inter-faces within a particular namespace infrastructure.

All the code related to the runtime model extractor is pub-licly available3 and documented.

This method is very useful to inspect and get an overviewof a system, but from the qualitative point of view, it is not themost informative analysis method. First, because this moni-tor can observe only a specific execution at a certain point intime, therefore it does not capture, for example, a very com-mon programming strategy in ROS, where a topic is beingsubscribed to within the call of a service client. Also ana-lyzing an already running system does not match one ofthe main motivations of our work: The analysis of softwarecomposition at design time performed to avoid errors andthus problems at runtime. On the other hand, this methodopens a new door for the analysis and diagnostics of systemsat runtime based on modeling languages.

Later in this paper, in Sects. 6 and 7, we will show ourefforts made to mitigate the drawbacks of this approach andto leverage its potential at runtime.

3 https://github.com/ipa-nhg/ros_graph_parser.

Additionally, to further expand on this method there areother approaches under consideration, like creating a wrap-per for the ROS master to capture all the traffic, or even tointervene at the transport level, by running a monitor in par-allel during execution and intercepting any call to the master.

5 Leveragingmodels in manual ROS codedevelopment

With the tools for the auto-generation ofmodels implementedand integrated successfully with the metamodels and ROStooling, our next step is to exploit these tools in two phases.Firstly, by providing a cloud system for convenient and,potentially, large-scale analysis of ROS code (given a quickenough uptake from the ROS community), and secondly, bycollecting generated models in a database to allow for com-parisons and, ultimately, systematization of the adoption ofcommon patterns and practices. Both tools use the static codeanalysismethod, sincewith the runtime introspectionwe can-not extract filesystem information (part of this informationis mixed with the one related to deployment on the result-ing models), which makes it unfeasible to use this method todetect common patterns of interaction.

5.1 Cloud tools for automatedmodel generation

We use the metamodels defined with a platform-independentlanguage and with accompanying tooling developed in Javawithin an Eclipse environment. In addition, to generate themodels, a local installation of HAROS and its libraries andROS packages is required. Seeing this as a limitation andentry barrier for some users, we decided to provide a cloudsolution. The system can be accessed through a web inter-face to generate models from publicly available code (hostedon Git version-control systems, the most commonly usedplatform to share code for the ROS community). The webinterface runs a Docker container [4] with a pre-configuredimage, that already contains all the required Linux libraries,ROS packages and HAROS. This image also sets up and pre-pares the workspace and the extractor script. We made alsopublic4 this docker image and the source code of the con-figuration for the analysis. This Docker-based architectureallows also the triggering of multiple jobs in parallel on sev-eral Docker containers. This feature (supported by the webinterface) was a strong motivator for the cloud solution. Byallowing large-scale analysis of packages, this concept canbe used to extract common patterns over large codebases, tothen advise users about “de-facto” standards, and produce agood base set of re-usable models for the ROS tooling.

4 https://github.com/ipa320/ros-model-cloud.

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

5.2 Extracting best practices frommodels

The advantages of ROS in terms of fast-prototyping andfederated development (such as simple txt-based messagedefinition, robust, yet simple to use communication libraries,no dependence on specific IDEs) were clearly the factorspromoting its wide expansion, but at the same time thesecharacteristics spurred its growth without a common defini-tion of specifications and interfaces.

The increasing adoption of ROS in professional domainshighlights the need of conventions and best practices as state-ments to assure, on the one hand, a minimum threshold ofsoftware quality and, on the other hand, to allow the easyintegrability of the different modules and systems. However,there exists no tool or even common documentation (beyondwhat users spontaneously share over a wiki) collecting allthis knowledge in a formal format. Neither exists a quantita-tive global study analyzing the use of the different patternsto define a proper set of best practices. As can be expected,within the community there are common working groups(for applications like manipulation, task planning, naviga-tion, etc.) where some common specifications are definedlike de-facto standards, but without a fixed common formator specifications DSL. With the structures to formalize ROSinterfaces in place (Sect. 3.1.1), a tool for automatic large-scale analysis available (Sect. 5.1) and awareness of the needfor common specifications, we put efforts toward an extratechnical contribution to analyze a diverse set of drivers fordifferent devices types to create a common set of specifica-tions. This is performed in two separate steps:

1. Identification of commonly used communication objects(the messages types of the communications betweennodes) and their provision as a basic dictionary. This dic-tionary is publicly available5 and will be automaticallyloaded to any new ROS project created within the ROStooling.

2. Identification of common patterns. In collaboration withthe EU H2020 project ScalABLE 4.0 [13], we createda growing database of specifications (patterns for typi-cally used robotics components, e.g., actuator controller,sensors, I/O devices…) by analyzing systematically themodels of diverse drivers for types of devices.6 For thisconcrete project’s use case, the component specificationsaim to help the configuration and use of a task orchestra-tor.

To complement this set of models, we contributed a newwizard to the ROS tooling to compare one by one the inter-faces of two models (the target one and a standard one or a

5 https://github.com/ipa320/RosCommonObjects.6 https://github.com/ScalABLE40/scalable_component_model.

custom specification). This feature returns as a result a list ofpotential errors that may hinder the integration of the com-ponent with other generic standardized modules, like:

– theuseof uncommonmessages (communicationobjects).This issue produces amismatch between both sides of thecommunication channel.

– the absence of a required interface. This issue preventsthe establishment of the communication.

The experiment section contains an example demonstra-tion of this feature (Sect. 8.1.2)

6 Evaluation of the extracted informationand combination of bothmethods

The first part of the section evaluates the results obtained byboth methods and their reliability when they are applied toreal ROS robot systems; in other words, we aim to answerthe following research question:

RQ1 How complete is the information we can automat-ically obtain (from code-to-model extraction methods) todescribe a large Robot Operating System application as aset of modular and reusable components and the interactioninterfaces among them? Is there incorrect information?

For our approach, this question is directly related to thefollowing one: is the automatically extracted informationenough tomake a good use of ourMDEROSTooling?Whichprovides us benefits like validation of the composition, auto-generation of deployment artifacts or interoperability withother frameworks.

Then, in the second part of this section, we introduce anewcontribution.A feature that allows the combinationof theoutcomes obtained by both methods and, therefore, producesas result a complete model, in terms of expressiveness andamount of interfaces.

6.1 Comparison of static and runtimemodelextraction

We assume that our metamodels, defined from the three ROSpillars (i.e., (a) the filesystem, (b) the computation graph,and (c) the deployment information) and successfully usedfor the design and deployment of real systems are valid todescribe a robotic application and secondly that the goal ofthe extractors is to instantiate them completely.

Both extractor methods are conceived with the samepurpose in mind: to auto-generate models. However, the con-cepts employed are very different. The static analysis of codeallows early detection of errors, while the runtime modelextractor cannot prevent execution issues. It can, however,

123

N. Hammoudeh García et al.

give the user a good understanding of the (current) behaviorof a system.

In [33], we analyzed themodels auto-generated using bothour methods (the static analysis of the code and the intro-spection at runtime of the application) on real robot systems.Considering the known limitations of both methods based ontheir design, the comparison can be shortly summarized by:

– With static code analysis, we are able to get all theinformation to completely instantiate all the fields of theROS models (Sect. 3.1.1), which are the basis of ourset of metamodels and, consequently, the basis of all theapplications of our models in terms of validation, com-posability and interoperability. On the other hand, thestatic analysis performs worse out on the rate of inter-faces found (detecting 10 to 50% less interfaces thanthe runtime monitor), mainly because of the dynamicallyassigned values on the code.

– With runtime monitoring, we are not able to completelyinstantiate the models (this method misses the filesysteminformation), and its biggest disadvantage is that in case anode failed and diedwewill not be able to detect it, whichmakes the models obtained via this method potentiallyunreliable. But, in comparison with the static analysis,we get a very large amount of data (up to the 90% of theinterfaces running on the system).

The immediate conclusion of this analysis is that whileone fails on the data volume, the other fails in expressiveness.Then, if we want to get the entire model as the most evidentimprovement we can perform to combine both approaches.Hereunder, we present a recent technical contribution thatanalyses and merges the result of both methods to obtain amore exhaustive model.

6.2 Solution: combination of the twomethods

Considering the pros and contras and identifying the com-plementary advantages of each extraction method, we definedifferent strategies (supporting different use cases) to appro-priately combine the result of both methods. With thissolution, we obtain a more precise model that the separateones or a “simple” merge of the results that will produce abunch of duplicated data. Before we identify the character-istics and potential uses of each strategy, we have to remarkthat, on the one hand, this feature will be used at design timebut using the results of a previous analysis of the executionof a system. The runtime data can indifferently come fromthe real target system, from its simulated version or evenfrom a run on a different machine of a set of the desiredcomponents. On the other hand, this solution considers onlycomponents, because it is the only reliable informationwe areable to extract from the runtimemonitoring method. Also we

assume an iterative design and development process, wherewe can subject early drafts of the to-be-developed systemto runtime monitoring and integrate obtained insights intothe further development process. This is a realistic scenario,since the federated development process and sharing culturein the ROS software ecosystem frequently have new devel-opers build on preexisting (sub)systems.

We first define the distinct sets of component interfacemodels we can obtain by comparing the extraction results ofboth extractors:

– Set A Components from static and not in runtimeanalysis: these are the components foundduring the staticanalysis but not present during the runtime extractions.It could contain components that were not started on oursystem or died before we recorded the data.

– Set B Components from runtime and not in staticanalysis: these are component found running on the sys-tem but not detected by the static analyzer, probablybecause the source codewas not available for the analysisor not supported by HAROS. This includes componentinterfaces dynamically generated at runtime.

– Set Cnames Common components in both analyses:these are common components found in both analyses.Note that Cnames only hold component names, as thereare actually two sets CA and CB holding potentially(but not necessarily) different models mA(c) ∈ CA andmB(c) ∈ CB describing the same components c.

– Set D Common components, all interfaces from bothmodels: these are the same components as described byC, but with a redefinition of their list of interfaces as thesum of the interfaces from both analyses:D = {mA(c)⊕mB(c) | c ∈ C}. Note that this set is already the result ofa first merging step common to both strategies.

The two merging strategies considered are: Strategy A:Inclusive merge. This computes the union set of the threesets A B and D above. This is the less restrictive one andit is optimal for an exhaustive debug of systems, but it isthe less recommended strategy to diagnose systems at run-time, since it will likely contain duplicated components andinterfaces for those cases where the static analyzer was notable to extract correctly the names of the interfaces. StrategyB: Enriching merge. With this strategy, we will complementthe result of the static analysis by adding to its componentsthe missed interfaces, which will increase considerably theamount of data information without corrupting the modelswith fictitious (filesystem) information. Formally this com-putes the union of A and D. That means that the resultedmodel supports all our tools and features (e.g., it can be usedto deploy the entire system).We can imagine that this strategycan be used for alternative purposes; for example, without aprevious static analysis, the user can just define a system as a

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

list of components (only the names) and let this feature to fillout the interfaces of each component, which is a great andeasy method to define new robot specifications.

In Sect. 8, the reader can find a detailed analysis of themetrics of the data from all the strategies obtained by a realexperiment with a large system.

7 Runtime target: model adaptation andleveragingmodels at runtime

In this section, we analyze the usability and validity of ourmetamodels to reach the new target goals for this paper: allowthe detection of errors not only at design but also at runtime.

First of all, we have to evaluate the usability of our modelsto describe the peculiarities of a ROS at runtime. In otherwords, we aim to answer the following research question:

RQ2 Can a component-based MDE approach with thesame metamodel cover all the peculiarities that character-ize a Robot Operating System application at design and atruntime? What relevant information has to be considered toanalyze also a system during its execution?If we apply the previous research question to our researchand our previous efforts, we have to reconsider here if ourmetamodels are complete enough to cover the necessaryinformation or if we missed relevant runtime particularities.

Based on this evaluation, our next action was the adap-tation of the metamodels to solve the found shortcomings.Finally, we present our first features, that thanks to the restof our approach and the new adaptation and combination ofmodels, leverage our effort to monitor and diagnose ROSsystems at runtime.

7.1 Suitability for runtime analysis

We have demonstrated in previous publications [33,34] thevalidity of our metamodels to design ROS robot applica-tions, and we have consolidated our concept with all thecomplementary tools (see Sect. 3.2) that shows to the ROScommunity the benefits of the use of MDE technologies.Although the main target of all our efforts until now wasdesign time, now that we covered this first phase of thesoftware development, we recently started to explore thepotentials of our research during the execution of the sys-tem.

Our first novel contribution is a tool to diagnose a runningapplication using our models , which helps us also to find thedeficiencies of the metamodels by using static analysis coderesults to check ROS system at runtime. Unsurprisingly, thispointed out a deficiency of our models to deal with one ofthe most conflictive tools of ROS, the parameters and theparameter server [11]. This shared and multivariable dictio-nary can be used to exchange data between all the programs

with access to the ROS master. These data can be exchangeddynamically and at runtime, and there is no need to definethem at design time. Even more a parameter in ROS can bedefined without the specification of its type attribute (i.e.,Boolean, String…), which gives freedom to the user to setany value during the execution of the program. Depending onthe software architecture design, these parameters can influ-ence the behavior of the system considerably and so far thereis not a optimal approach to validate them.

The new ROS 2 version has set more restrictions to thedevelopers concerning the definition of parameters, which,from our point of view, is an appropriate action and a stepforward on code quality and systems validation.

7.2 Metamodels adaptation to support runtimesystems

Themigration of our full tooling to ROS 2 is de facto the nextstep of our work. ROS 2 is already consolidated in terms ofavailable software packages and the community of users sup-porting it. The extension of the metamodels to support ROS2 will be minimal. In fact, we have already successfully inte-grated some code generators. Then, and because in ROS (orROS 1) we miss completely a proper definition of parame-ters, we have adapted our metamodels to be able to supportthe description of the parameters and validate their values atruntime in the sameway that ROS 2 expects to use them. Andlastly, we updated the monitor extractor at runtime to supportthis newmodel extension and be able to automatically extractall the shared information of the parameter server dictionary.

This new extension allows the user to describe also param-eters at design time and to set to them a type and a defaultvalue. We also give to the user the option to re-define thevalue of the parameter at the application specific level, likeROS does at runtime or design time using its deploymentartifacts. In parallel, we added to our DSLs validators theappropriate rules to check the correctness of the redefinitionof parameters. In the next section,we introduce the first lever-age tools that we created to validate this new extension of ourmetamodels.

7.3 Leveragingmodels at runtime

After the study of the current state of the art to diagnoseROS systems during their execution, we found the use ofMDE as a good fit for this domain, since it can simplify andsignificantly optimize error debugging and even facilitate theintegration of error-handling techniques.

The final goal of our efforts is to develop a diagnosis andmonitoring framework whose main objective is the integra-tion of existing open-source ROS based tools as observers.This framework is directly linked to the ROS models, usingthem to (1) evaluate continually if the components and inter-

123

N. Hammoudeh García et al.

faces running on the system are the expected ones (we calledthis tool ROS Graph observer) and (2) to select from themodels the sensitive properties to be monitored during thedesign of the application and auto-generate the deployablecode for its inspection (we called this feature propertiesobserver). Although the property observers do not addressthe functional-safety-concerns regarding robotics software[17], these property observers, which are independent of theapplication program written in Python, can be used to diag-nose system-level properties bymonitoring component-levelproperties.

The basis of the ROS Graph observer is our runtimeintrospection parser and extractor, which can return at anytime the list of the current nodes running on our systems,the interfaces that connect them and all the parameters settogether with their values. All this information is obtainedas formally structured through our metamodels. We built ageneric system diagnostics tool (the rosgraph_monitor) uponit that does not require an application-specific configuration.

Figure 4 shows a simplified overview of the approach.First, we give to the rosgraph_monitor a desired.rossystemmodel specification file of our desired system, which con-tains the list of the nodes, interfaces, and /or parameters thatwe expect to be running on our robot, and second we callperiodically the ros_graph_parser to output the current sta-tus current.rossystem of the system. Finally, we interpret andcompare for both models (1) the nodes (components), (2)the interfaces contained within them (component ports) andthe established connections and (3) the type of the parame-ters and their fixed values. Lastly, it outputs the result of thisanalysis.

For a full integration of ROS and our Xtext languages, weimplemented a pyparsing-based interpreter that makes all theinformation contained on our models accessible from ROSnative code. Also, the result of the analysis is published asa common ROS topic that can be interpreted and visualizedwith the common ROS diagnostics tools or sent to an error-handling tool to deal with the fail and reconfigure the system.

The de facto use of this feature is to verify if a set of essen-tial components have been started and are running. Printingan error in case one of them died or does not present theexpected interfaces. This approach simplifies significantlythe diagnosis of a system at runtime, without the need ofthe development of a new specific diagnostic program foreach component or having this part embedded on the driver.Moreover, we discovered other uses of this feature; currently,we use it to quickly and easily detect if a robot setup has allthe requirements (in terms of interfaces) to perform a con-crete task and if it is compatible with other existing softwarelibraries. For these cases, the desired RosSystem file, that weuse as input, describes through our models format the spec-ifications for a concrete software application and the ROSGraph observer will evaluate if the current running system

Fig. 4 Architecture overview of the ROS graph observer approach. Theflow of the information begins with the runtime running system and itsmodel equivalent obtained thanks to the ros_graph_parser, comparingthis data with the desired.rossystem; this solution publishes a diagnos-tic_msg with the status of the current execution

fulfills the requirements. If it does not, a detailed diagnos-tics message will list the missing interfaces. This can alsobe extended to proof parameters and parameters values for amore precise study of compatibility.

The previously described tool checks whether the compo-nents, their ports, their connections, and the parameters thatwe expect during the design of our application are presentduring its execution, but we can move one step forward. Atruntime, the values of the objects of the exchanged infor-mation are also available, we just have to subscribe to therunning interfaces, and our models contain a formal descrip-tion of the type of this information. Upon this, we recentlydeveloped a new plug-in for our Tooling that allows the userto set at design time the thresholds for a number or the con-crete expected value of the information objects. This plug-inwill auto-generate, as outcome, a ROS python node that willpublish a diagnose error if the value of one object propertyinfringes the user-defined range.

For example, thanks to our metamodels, we know thatan arm driver expects as command an array of Floats thatrepresent the desired position for each joint. With this newplug-in, the user can select the armcommand interface and setthe maximum and minimum values for the position of eachjoint. The auto-generated observer, executed together withthe rest of the application, will publish an error message ifone joint position command exceed the limits. Even more,the generated code is implemented in such way that it can beeasily extended to, not only publish the diagnosticsmessages,but also call other functions, like in this case could be stopor reject the move command action.

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

This novel contribution aims to be a first step to bridge ourMDE efforts with error-handling and self-adaptation tech-nologies. We propose here an approach where using a singlemetamodel we can describe the desired specifications of thesystem and generate its full deployment artifacts togetherwith a set of properties observers. The observers’ outputscould feed an error-handling software, that, analyzing thedata, can identify and react to behavior anomalies.

8 Use case example

All the tools and concepts presented in this paper are beingimproved, tested and evaluated on real demonstrators in thecontext of the ongoing project SeRoNet.

In order to practically demonstrate the concrete technicalcontributions of this paper, we report in this section a use casebased on the commercially deployed service robot Care-O-bot4 or cob4 (Fig. 5). Given its complexity, we can considerit an adequately representative example for service roboticsapplications.

The goal of this section is both to highlight the advantagesand convenience of our toolswhen applied to the typical tasksthat a robotics software engineer performs and to point out thelimitations of the different approaches, to be possibly tackledas future work. So, in order to facilitate the understandingof the next subsections and the vocabulary used to describethe experiments, we firstly list the set of publicly availablerepositories from which to source the companion material:

Fig. 5 Care-O-bot4 full robot. Developed by Mojin Robotics

– ROS Tooling This repository contains the ROS tool-ing infrastructure and also serves as the storage fordocumentation. By tooling, we mean the Eclipse envi-ronment and the full Java and ecore implementation ofthe metamodels, as well as the Xtext and Xtend grammarimplementations, a set of wizards for the graphical repre-sentations and the support tools to automatically import,create or modify the models.7

– ROS Cloud tool This repository contains the backendcode of the web interface publicly available to extractmodels (i.e., ros-model.seronet-project.de).Wemade thisrepository public for the cases where the source code isnot hosted online. Furthermore, all the script tools usedto extract models are available within this repository.8

– ROS Graph parser This repository holds the ROS pack-age used for the monitoring and extraction of models atruntime.9

– ROS Graph monitor This repository holds the ROS nodethat parse and compare a desired specification modelof a system and the actual runtime status from theros_graph_parser. And then publish a diagnostic mes-sage as result of the comparison.10

– ROS Experiments This repository contains the resultsof different analysis, including the full results of theexperiment explained in this section corresponding to theversion cob4-25.11

To perform the system experiments, we used the soft-ware description of the drivers that manage the hardware ofthe cob4-25. We selected the most characteristic modules ofwhich a real robot consists of (for the mechanic and sensingpoint of view) and provide interfaces to run a complete appli-cation. Listing some of them, we have included for instancethe basewith threewheels: the joystick to teleoperate it; three2D laser scanners used to navigate the environment; three3D cameras for visualization tasks; components like light,mimic control, and sound for general robot–user interaction.Figure 5 shows the real aspect of one of the robot of the series.

This section is divided into four parts: first we focus theexperiment on the static code analysis to auto-extract mod-els and show an example of its benefits together with theweb cloud infrastructure to analyze and find a componentreplacement for our robot, second we show how our auto-extraction methods perform the analysis for a complete largeROS system and compare the obtained results; then, third,we explore the use, with the two strategies, of our new fea-ture to combine both methods. Finally, fourth, we introduce

7 https://github.com/ipa320/ros-model.8 https://github.com/ipa320/ros-model-cloud.9 https://github.com/ipa-led/ros_graph_parser.10 https://github.com/ipa-hsd/rosgraph_monitor.11 https://github.com/ipa-nhg/ros-model-experiments.

123

N. Hammoudeh García et al.

our first experiments using models to diagnose a ROS largesystem at runtime.

8.1 Components model extraction through staticcode analysis

8.1.1 ROSmodel extraction through static code analysis

The first step to import models into the ROS tooling is tostatically analyze the atomic, self-contained software entitiesin ROS, that is, the nodes. To perform this step, we invokedthe HAROS framework providing as input the name of thepackage that contains, in this case, theC++code and the nameof the node. To cover all the possible cases, we provide tothe user different methods: the cloud web interface, a locallyrunning extraction script (this requires a local installation ofHAROS) and the provided pre-configured Docker container.

For this concrete walk-through tutorial, we opted for thecloud solution, giving as input (the information of one of thescanners node):

– Git repository github.com/ipa320/cob_driver– Package cob_sick_s300– Node name cob_sick_s300

The code in Lst. 1 shows the result of the analysis. Import-ing the auto-generated model to the ROS tooling, we canvisualize the driver of this scanner as shown in Fig. 6

PackageSet { package {CatkinPackage cob_sick_s300 { artifact {

Artifact cob_sick_s300 {node Node { name cob_sick_s300

publisher {Publisher { name ’scan’

message ’sensor_msgs.LaserScan’},Publisher { name ’scan_standby’

message ’std_msgs.Bool’},Publisher { name ’/diagnostics’

message ’diagnostic_msgs.DiagnosticArray’}}}}}}}}

Listing 1 sick_s300.ros file in Xtext format generated automatically bythe cloud tool

8.1.2 Leveraging static code analysis to extract commonspecifications: component replacement use

To show the potential of large-scale code analysis made pos-sible by our cloud system, we choose a typical use case inrobotics: a system integrator in need of replacing one of thecomponents of a system. The process of replacing a robotcomponent starts with an evaluation of the alternatives inthe market, firstly, in terms of hardware (physical dimen-sions and electronic requirements), and secondly, in termsof compatible software. In our case, we will focus on 2D

Fig. 6 Tooling visualization of the auto-generated model for a Sicks300 scanner driver

laser scanners (specifically, those for which a ROS driverexists), which can potentially replace the SICK S300 laseron the current setup of the Care-O-bot. The ROS wiki pro-vides an open catalog of supported sensors [1]. From thislist, we filtered those whose software is not up-to-date or notpublicly available. We obtain a final list of seven scanners tobe evaluated. In order to know which of them are compatiblewith the rest of our system, we have obtained the model foreach of them using our cloud tooling for the extraction (i.e.,http://ros-model.seronet-project.de) with the following inputlist:

HLS-LFCD LDS:

– Git github.com/robotis-git/hls_lfcd_lds_driver– Package hls_lfcd_lds_driver– Node name hlds_laser_publisher

Hokuyo:

– Git github.com/ros-drivers/hokuyo_node– Package hokuyo_node– Node name hokuyo_node

Pepperl Fuchs r2000:

– Git github.com/dillenberger/pepperl_fuchs– Package pepperl_fuchs_r2000– Node name r2000_node

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

Fig. 7 Teraranger Evoauto-generated model importedon the tooling which shows anerror because of the use of anon-common ROS messagepattern for a publisher interface

Rplidar:

– Git github.com/Slamtec/rplidar_ros– Package rplidar_ros– Node name rplidarNode

Sick Safety Scanners:

– Git github.com/SICKAG/sick_safetyscanners– Package sick_safetyscanners– Node name sick_safetyscanners_node

Teraranger Evo:

– Git github.com/Terabee/teraranger_array/– Package teraranger_array– Node name teraranger_evo

Neato XV-11:

– Git github.com/rohbotics/xv_11_laser_driver– Package xv_11_laser_driver– Node name neato_laser_publisher

Having obtained the auto-generated models (ros-model–experiments/scanner_comparison) , we imported all of theminto the tooling.

Thefirst check is the evaluationof the use of standardmes-sages. This check was not passed by the Teraranger Evo (asshown in Fig. 7) and by the Sick Safety Scanners because bothuse non-generic message types (i.e., the use custom-definedones) for the communication. The use of communicationobjects not included in the ROS tooling dictionary can besolved by updating it , but this is only recommended after asystematic evaluation of existing software and matched pat-terns.

Validate the file: hlds_laser_publisher.rosfor the specifications model: Laser2DScan.rosOK:- OK: Publisher for message type sensor_msgs/

LaserScan found: scan -> scan

Listing 2 Result, generated by the tooling, of the comparison of thehlds_laser_publisher with the common specification pattern for a 2DLaser scanner

In the case of the scanners, through a previous anal-ysis of several nodes we already distilled a de facto

“standard” specification model from commonly used code(scan_comparison/Spec/Laser2DScan.ros). The second partof this test is to compare all the automatically obtained mod-els with this generic specification by using the comparisonmodels tool (Sect. 5.2). All the analyzed package except theTeraranger Evo passed this check; Lst. 2 shows the outputwe obtained for all the drivers that fulfilled the requirementof publishing their output through the standard message typesensor_msgs/LaserScan. Lst. 3 shows the result of an unsuc-cessful check.

Validate the file: teraranger_evo.rosfor the specifications model: Laser2DScan.rosERRORS:- ERROR: missed a publisher for message type:

sensor_msgs/LaserScan

Listing 3 Result, generated by the tooling, of the comparison of theteraranger_evo with the common specification pattern for a 2D Laserscanner

The third part of this test is to compare the modelsobtained automatically with the model of the current scannermounted on the Care-O-bot, the SICK S300. The model ofthis driver is shown in Lst. 1. Unsurprisingly, none of thenodes passed the test, whose result is shown in Lst. 4. Asfor Care-O-bot, there is a special best practice requirement,that all the drivers report constantly the current status of thehardware by publishing a diagnostics message. The lack ofthe diagnostics message will produce a warning for the Care-O-bot. The other error pointed by the test is due to the SICKS300 having non-common standby mode which can be pub-lished by its driver. However, this property is not needed, andits absence is not considered an error and neither a warning.

Validate the file: hokuyo_node.rosfor the specifications model: sick_s300.rosERRORS:- ERROR: missed a publisher for message type:std_msgs/Bool- ERROR: missed a publisher for message type:diagnostic_msgs/DiagnosticArrayOK:- OK: Publisher for message type sensor_msgs/

LaserScan found: scan -> scan

Listing 4 result of the comparison of the hokuyo_node with thesick_s300 model generated by the tooling

123

N. Hammoudeh García et al.

Thanks to the static code analysis, the open-source natureof ROS and the tools we developed upon our metamodels tocheck and compare models, we demonstrated how the useof a MDE approach for ROS common software simplifiessignificantly the identification of common design patterns.

8.2 Automatic extraction of ROS large systemmodels

8.2.1 Systemmodel extraction through static code analysis

The previous section analyzed only one of the nodes thatcompose the full robot. Performing such an operation inde-pendently for every single node is a tedious task. To facilitatethe analysis of a system composition, we use the launch fileparser of HAROS. Practically speaking, launch files, writtenin XML format, are used in ROS to start together severalprograms.

Figure 8 showsanoverviewof the approach runningonourcloud system within a Docker container. First of all, we haveto locate the source code of all the ROS software requiredto run our system. Typically, ROS system integrators installa released stable version of the dependencies in binary formbut for this analysis we need a local build of the full sourcecode and all its dependencies. To automate the solution ofthis issue, we created a script that first asks ROS for allthe dependencies of the target package (command rospackdepends-indent) and second obtains for each single packagethe GitHub URL that holds the source code (command roslo-cate info). Once we have this information, we checked outall the source code to our workspace and compile all thesepackages each package in an isolated environment , optionrecommended as the cloned packages can likely have differ-ent make system variants (catkin and non-catkin). When thebuild completes, we combine all the isolated builds, mak-ing our workspace ready to be analyzed with HAROS. Thelaunch files in ROS are very powerful and can be used tomanage and potentially fully redefine the behavior of a robot.This also means that they are very complex and hard to befully supported by any automated tooling. Even more, whenwe consider a Care-O-bot whose launch file architecture isdefined to support all the possible combinations of modulesand configurations. Ultimately, this results in themain launchfile being translated into an entangled combination of launchandXMLfiles, with recursive inclusions and parsing of argu-ments and parameters. To streamline this analysis, we createda script (ros-model-experiments/tools/roslaunch-dump) that,given the original root launch file, is able to create a new onethat resolves all the namespaces (ns), names of the param-eters and the monolithic includes of single nodes and theirparameters.

Having this obtained launch file, the next step is to use theHAROS launch parser to detect the name of the packages and

name of nodes, and the namespace that organizes the nodes.With this information, together with a successful build ofall the packages, we invoke the source code extractor (samecode than in the previous step of the experiment) to generateautomatically:

– a set of component models (.ros files), including themodel of the Sick S300, i.e., Lst. 1) ros-model-experi-ments/cob4-25/cob4-25_static/rosnodes

– a RosSystem model file that contains all the compo-nents with their list of remapped interfaces and itsreferences to the original ROS model. A short partof this file is shown in Lst. 5 ros-model-experiments/-cob4-25/cob4-25_static/cob4-25_experiment.rossystem

RosSystem { Name cob4-25RosComponents ( ....ComponentInterface { name ’/base_laser_right/

driver’ NameSpace ’/base_laser_right/’RosPublishers{

RosPublisher ’/base_laser_right/scan_raw’ {RefPublisher ’cob_sick_s300.cob_sick_s300.cob_sick_s300.scan’},

RosPublisher ’/base_laser_right/scan_standby’{ RefPublisher ’cob_sick_s300.

cob_sick_s300.cob_sick_s300.scan_standby’},

RosPublisher ’/diagnostics’ { RefPublisher ’cob_sick_s300.cob_sick_s300.cob_sick_s300

./diagnostics’}}....}}}

Listing 5 Sample of the RosSystem model generated by the static codeanalyzer

Examining the result, we found three concrete launch filestructure limitations:

– The name of the interfaces is parsed as input argument.An example of this issue is the nodescan_unifier_node of the package cob_scan_unifier. Tosolve this problem, we made a small modification to theoriginal source code to obtain statically the name of theinterfaces. However, this case should be supported andthe code not modified.

– The type and name of the interfaces are parsed as param-eters. This issue is made evident by a very concrete andcommonROS framework: ros_control. This software canbe called with a list of arguments that set the type of thecontroller to be started (i.e., joint_trajectory_controller,velocity_controller, position_controller..), getting thevalueof these arguments the controller manager set at run-time for all its commands the name and the type of theinterfaces. This case is impossible to be supported by astatic code analyzer. Tomomentarily solve this issue, alsoknowing that once the type of controller is defined thedelivered interfaces are fix, we defined a special plug-infor our extractor that checks the arguments of the con-

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

Fig. 8 Diagram of the approachof system model extractionthrough static code analysis

troller_manager node using a predefined template for theros_control model.

For a complete quantitative analysis of the result, the nextstep of our experiment is the introspection of the systemat runtime, and the comparison of results obtained by bothmethods.

8.2.2 Systemmodel extraction through runtimemonitor

For this part of the experiment, we used the hardware of thereal robot (Fig. 5) and started all the components used forthe previous section analysis, in order to obtain comparableresults.

Starting the same launch file and initializing all actua-tors (i.e., base, torso, sensorring and both arms) to maketheir commands available, we called our ROS graph parser(Sect. 4.2) to extract the model of the system. The result ofthis experiment is two files:

– the fictitious component model. A .ros file model witha single ROS package containing all the nodes runningon the system and the interfaces that these nodes offerto the rest of the network cob4-25/cob4-25_runtime/rosnodes/dump.ros.

– a RosSystem model file containing a component defi-nition for all the previously found nodes and referenc-ing all the interfaces of the ROS model file. A shortexcerpt of this file is shown in Lst. 6 cob4-25/cob4-25_runtime/cob4-25.rossystem

RosSystem { Name ’cob4-25’RosComponents (....ComponentInterface { name ’/base_laser_right/

driver’RosPublishers {

RosPublisher ’/base_laser_right/scan_standby’{RefPublisher ’dump_pkg./base_laser_right/driver./base_laser_right/driver./base_laser_right/scan_standby’},

RosPublisher ’/base_laser_right/scan_raw’ {RefPublisher ’dump_pkg./base_laser_right/driver./base_laser_right/driver./base_laser_right/scan_raw’},

RosPublisher ’/diagnostics’ {RefPublisher’dump_pkg./base_laser_right/driver./base_laser_right/driver./diagnostics’}}....}}}

Listing 6 Sample of the RosSystem model generated by the runtimemonitor

A peculiarity of the result of this analysis is the additionof a fictitious node, called parameters_node, which includesa complete list of all the parameters set on the system duringthe execution including the value of all of them. This newfeature is very useful for the debug of the system; in thecase of this Care-O-bot experiment, we found a total of 1159parameters.

8.2.3 Comparison of system extraction through static codeanalysis and runtimemonitoring

In Sect. 4, we listed the technical limitations of eachapproach. Before we analyze the obtained numbers we haveto add, in favor of HAROS and the static analysis, that Care-O-bot, the case of study, is a very complex system whichmodularity enforces the definition of many of the interfacesthrough arguments. The support of this configuration by a

123

N. Hammoudeh García et al.

Table 1 Comparison of the number of components and the differenttypes of interfaces found by the both extraction methods

Static analysis Runtime analysis

Components 69 75

Topic Publisher 146 259

Topic Subscriber 36 105

Service Server 57 153

Service Client 20 0

Action Client 6 7

Action Server 6 11

Total interfaces 271 535

static code analysis tool is limited and hard to be totally inte-grated.

Table 1 shows the quantitative comparison of bothapproaches in terms of number of components and interfacesfound.

In total with the runtime approach, we found the 76 nodeslisted on the launch file, expected result as ROS starts all thenodes included on a launch file automatically once it is calledandweperformed the experimentwith a fully operative robot.However, we cannot expect that rate for the interfaces found,for example, the case of the Service Clients, and all the inter-faces activated within callbacks, that if not called (likely thecase) during the monitoring time, were fully ignored.

If we analyze the results for the static code analysis, weobtained 69 components (a total rate of a 92%). This meansthat for Care-O-bot we could find for the 92% of the compo-nents an open-source code version using just the ROS distromechanisms. Even more important, for all of them the codecould successfully build in a clean image of the operatingsystem, where all the packages dependencies where foundand installed automatically and all the quality requirementsneeded to analyze statically the code passed successfully.From this data, we can extract two main conclusions, (1)the design leveraging HAROS, the tools and the docker con-tainer solution we propose is appropriate and valid to be usedto analyze large systems and (2) the full Care-O-bot softwarestacks (that conglomerates more than 100 ROS packages) inspite of, or maybe thanks to, its open-source nature evidencea high grade of code quality, remember that at the end weanalyze C++ and Python code and how it is designed andwritten.

If we use the obtained data to answer our RQ1: “Howcomplete is the information we can automatically obtain(from code-to-model extraction methods) to describe a largeRobot Operating System application as a set of modular andreusable components and the interaction interfaces amongthem? Is there incorrect information?” we see that, firstly,in terms of informativeness the models extracted through

the static code analysis (e.g., Lst. 1) are truthful and theROS metamodels structures fully fulfilled, remember thatwe considered this as a premise requirement of our researchquestion. If we compare this model with the corresponding“node” auto-generated by the runtime monitor, we find thefollowing two types of information as missing or wrong:

– we are not getting the filesystem information (i.e., thename of the ROS package that contains this node). With-out this information, the ROS tooling is not able toauto-generate a valid launch file for the composition ofthis component with others.

– the information related to the name of the node is wrong.When the runtime model generator runs, the nodes andtheir interfaces are already remapped. The assignment ofa namespace is done during deployment phase (i.e., forthe family of metamodels, included in the RosSystemmodel file, see Lst. 5).

Secondly if we consider the usability and re-usability, theselisted issues, mainly the lack of the filesystem information,make hard (almost useless) the reuse of the single extractedmodels from the ROS Graph monitor for the composition ofnew systems. The only aspect where the analysis of this file ishelpful is to find commonly used communication object types(i.e., messages types) that upgrade the provided dictionary 1.

This conclusion, the lack of relevant data from the runtimeintrospection set the new direction of our research exploringthe possibilities to combine the results of the extractionmeth-ods and, therefore, the benefits of both.

Unsurprisingly, the ROS Graph monitor is able to findmore interfaces than the static analysis, by comparing thenumber of detected interfaces through the runtime monitor(535) and through the static code analyzer (271). A deepanalysis of the data and the cases where the static codeintrospection failed answered our RQ2: “Can a component-based MDE approach with the same metamodel cover allthe peculiarities that characterize a Robot Operating Systemapplication at design and at runtime? What relevant infor-mation has to be considered to analyze also a system duringits execution?”, and confirmed our suspicions; in ROS forlarge, and likely modular, systems the parameters and theirset and unset at runtime play a very important role and changecompletely the behavior and the interactions between thenodes once the system is deployed. Giving some numbers,for eight components (from a total of 35 software packages)all their interfaces are defined by the set of parameters andthe obtainedmodels extracted analyzing their source code areempty. Also, for a total of 18 interfaces we couldn’t deter-mine their names, which are passed as a string parameter.This is a very common practice in ROS for generic compo-nents, as the use of parameters facilitates the re-usability andeasy adaptation of a node to different applications.

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

After this study, we decided to update our models to sup-port properly the definition of parameters and improve all ourruntime introspection tools for a better analysis of the ROSparameters particularities.

8.3 Combination of the results of both extractionmethods

This step of the experiment shows how our combinationfeature can be used to compose the data obtained by bothextraction methods and obtain a more precise model of asystem. Figure 9 represents the approach we used for thisdemonstration, where we took as inputs the same models wecompared in the previous step, extracted automatically byour both extraction methods and that targeted the same sys-tem. The result will be an unique RosSystem file which datawill depend on the criteria selected by the user.

For this experiment, we used the two strategies weexplained in detail in Sect. 6.2, i.e.,

– StrategyAor inclusivemergewhich results in the unionofthe components of the static code analysis with the onesfound by the runtime monitoring tool, by the commoncomponents this strategy merges all those found.

– Strategy B or enriching merge where all the componentsfrom the static analysis are present and only for thosealso found by the runtime analysis we add the missedinterfaces.

Fig. 9 Architecture overview of the feature to combine two modelsfor Sect. 8.3 case, i.e., combine models auto-generated using our twoextraction methods for the same system, the cob4-25 robot

Table 2 Comparison of the number of components and interfacesobtained by the both model combination criteria applied to the resultsfrom a static code analysis and the runtime monitor for the cob4-25robot system. Complemented, marked in bold, with the data obtainedfor the model obtained from the combination

Strategy A Strategy B

Components static analysis (fromprevious section)

69 69

Components runtime analysis(from previous section)

75 75

Components of the resultedmodel

100 69

Duplicated components of theresulted model

25 0

Interfaces of the resulted model 775 676

The entire results of this experiment are publicly avail-able under ros-model-experiments/cob4-25/ . In Table 2, wesummarize them quantitatively.

If we analyze the data, we see that with the strategy A weget many duplicated components interfaces, whose names(likely because theywere re-assigned using a parameter fromthe parameter server or the value dynamically passed throughcode functions) do not correspond to the final assignment atruntime. If the purpose of the user is to make an exhaustivedebug of the system, this result is the most complete that canbe obtained. Filtering the data of the resulting model, all theerrors introduced either during the design or at the executionof the application can be detected.

With the strategy B, on the other hand, we successfullycompleted a large portion of the interfaces missed by thestatic analysis (676 in total, while by the static code anal-ysis we only detected 271), and without having duplicatedcomponents. Even better, for all the components of the finalresulting model we have complete information, i.e., all thefields of our metamodels are filled including the real filesys-tem information.

If we link the experiment results with our RQ1: “Howcomplete is the information we can automatically obtain(from code-to-model extraction methods) to describe a largeRobot Operating System application as a set of modular andreusable components and the interaction interfaces amongthem? Is there incorrect information?”, we see that with thestrategy B (the enriching merge) we obtained a final RosSys-tem model that contains 69 of the 75 components started onthe real robot and all their interfaces (that correspond to a92% of the total) and for all of them we have all the requiredinformation, the related to the computational graph but alsothe filesystem part. This makes the resulting model compati-ble with all our ROS tooling features and re-usable for otherapplications and even valid for its composition with othersystems or frameworks.

123

N. Hammoudeh García et al.

8.4 Leveragingmodels at runtime

8.4.1 Auto-diagnosis of a system evaluating itscomputational graph at runtime

To show the use of our monitoring tool, we describedthe list of the most common hardware drivers of theCare-O-bot4 as a RosSystem model (file available undercob4-25_desired_components.rossystem ) and used it as thespecification of the desired system for our experiment. Whenall the necessary hardware is connected and is in runningstate, the diagnostics publisher will contain the OK statusmessage like shown in Lst. 7.

status:level: 0name: "ROS Graph"message: "running OK"hardware_id: ’’values: []

Listing 7 Diagnostics message for the rosgraph_monitor

If one of the desired nodes is not running, it is possi-ble that the system may not function as intended. Thesenodes are marked as Missing nodes with an operation level2 (ERROR). Evaluating the common specification desiredfile for the Care-O-bot4 family on the Care-O-bot4-25 ver-sion we detected, firstly, that this robot distro does not have amicrophone driver, and therefore, the sound component is notavailable. Another test we made to prove this feature was tophysically disconnect one of the robot’s cameras, which doesnot allow to start the camera driver at startup. As expected,the monitoring tool marks this also as a missing node likecan be seen in Lst. 8.

status:level: 2name: "sound"message: "Missing node"hardware_id: ’’values: []

status:level: 2name: "/torso_cam3d_right/realsense2_camera"message: "Missing node"hardware_id: ’’values: []

Listing 8 Diagnostics message for the rosgraph_monitor if a node ismissing, sound example

Although we strongly recommend the implementation ofdiagnostics messages as output for every ROS driver, withthis experiment we demonstrate that, without the extra devel-opment effort or a custom configuration, we are also able todetect component failures. But more importantly, the headcamera scenario shows an use case so far unsupported; thecamera driver was never started, because it has a precondi-tion to detect the physical hardware first, and therefore thediagnostics message from the software driver was never pub-lished and the error never showed, but still our solution coulddetect it.

Additionally, when components not mentioned as desiredare detected in the graph, it is not an error, but if the userneeds to check the extra components started on the robot, themonitoring frameworkmarks for these cases the componentsasAdditional nodeswith an operation level 1 (WARN). Theseoperation level can be used in ROS to easily filter or sort thediagnostics message by their severity.

8.4.2 Auto-evaluation of the running system and itscapabilities

For the experiments, we decided to use the common low-level functionalities of Care-O-bot; however, on ROS thereare open-source libraries to perform high-level capabilitiesthat can be applicable to any robot setup to perform complextasks. The most common robotic capabilities are navigation,perception andmanipulation and scenarios based on the coor-dination of them. One of the biggest advantages of ROS isthemodularity, adaptability and re-usability of these softwarecomponents, but to run these capabilities, your robot has tooffer a concrete set of interface that the high-level function-ality needs to get or command information. Currently theidentification of the interfaces and the check of their pres-ence has to be done manually. With our approach, we foundaway to semi-automate the process, being able to analyze therunning systemand automatically detectwhether it is suitableto run a concrete application. Going deep into the technicalimplementation, we created RosSystem models to describeformally the specifications of a capability, for example, tonavigate a robot the ROS navigation stack requires the infor-mation from a laser scanner, the kinematics tree of the robotand its odometry. Once it computes of all of this data, it willpublish a velocity twist command to the base. Lst. 9 showsthe formal model for this description for the Care-O-bot4(cob4) target.

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

RosSystem { Name ’cob4-25_navigation_capability’RosComponents (ComponentInterface { name ’navigation’RosPublishers {RosPublisher ’/scan_unified’ {RefPublisher ’cob4

/../scan_unified’},RosPublisher ’/tf’ {RefPublisher ’cob4/../tf’},RosPublisher ’/base/odometry_controller/odometry’

{RefPublisher ’cob4/../odometry’}}RosSubscribers {RosSubscriber ’/base/twist_controller/command’ {

RefSubscriber ’cob4/../command’}}}

)}

Listing 9 RosSystem model excerpt corresponding to the ROSnavigation capability specification

Using the previous model as the desired system for ourROSGraph observer feature, we get automatically amessagewith the result of the analysis. If it fails we also point to themissing interface or interfaces, Lst. 10 present and exampleof the diagnostic output.

status:level: 2name: "cob4-25_navigation_capability"message: "Capability incompatible"hardware_id: ’’values:

-key: "publishers"value: "tf"

Listing 10 rosgraph_monitor diagnostic output message when aninterface to run the Navigation capability is missing in the system

9 Conclusion and future work

The work presented in this paper aims to improve the soft-ware quality of ROS systems in a complementary fashionto other initiatives within the ROS community. The basicideas of this approach are: the exploitation of informationavailable at design time but mostly not used due to insuf-ficient tooling, in order to avoid errors at runtime and theidentification of de facto standard practices. The reuse ofsuch practices often improves quality through better under-standing of the developed code by other developers andeasier reuse/replacement of components. We pursued thisapproach through model generation by: automatic modelextraction, both from source code through static code anal-ysis and from binaries through runtime monitoring, and bymaking available the necessary tooling both as source codeand as a cloud service, together with the starting nucleusof a model database to be used and expanded by the ROScommunity. We hope that this initial effort can contribute tothe model-based verification of manually written ROS codeand push toward a future standardization of ROS interfaces

beyond the practice of manually annotating and inspect-ing wiki documentation. In addition to growing the modelsdatabase and involving further ROS developers, we plantwo further directions for our future work. The first is tomerge our cloud-based service for model generation with theEclipse tooling into a more comprehensive cloud-based IDE,necessitating no installation and offering “IntelliSense-style”suggestions to, for example, pick the most adequate messageformat given a comparison performed in the backgroundbetween the extracted model and matches in the database.The second is to continue our growing effort on monitoringand diagnostics at runtime, by adding further system proper-ties observers and integrating reasoning models to be able toautomatically handle errors during the execution of an appli-cation.

Acknowledgements The research and development project that formsthebasis for this report is partially fundedwithin the scopeof the “PAiCEDigitale Technologien für die Wirtschaft” technology programme runby theGerman FederalMinistry for EconomicAffairs andEnergy and ismanaged by the DLR project management agency “Gesellschaft, Inno-vation, Technologie—Informationstechnologien/Elektromobilität” atthe German Aerospace Center in Cologne. Other parts of this workhave been supported by the European Commission’s Horizon 2020Programme under the Grant Agreements No. 732287 (ROSIN). Andby the ERDF—European Regional Development Fund through theOperational Programme forCompetitiveness and Internationalisation—COMPETE 2020 Programme and by National Funds through the Por-tuguese funding agency, FCT—Fundação para a Ciência e a Tecnologiawithin project PTDC/CCI-INF/29583/2017 (POCI-01-0145-FEDER-029583).

Funding Open Access funding enabled and organized by ProjektDEAL.

Open Access This article is licensed under a Creative CommonsAttribution 4.0 International License, which permits use, sharing, adap-tation, distribution and reproduction in any medium or format, aslong as you give appropriate credit to the original author(s) and thesource, provide a link to the Creative Commons licence, and indi-cate if changes were made. The images or other third party materialin this article are included in the article’s Creative Commons licence,unless indicated otherwise in a credit line to the material. If materialis not included in the article’s Creative Commons licence and yourintended use is not permitted by statutory regulation or exceeds thepermitted use, youwill need to obtain permission directly from the copy-right holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.

References

1. Catalog of ROS supported sensors. http://wiki.ros.org/Sensors.Accessed 29 Mar 2021

2. COB monitoring source code-GitHub link. https://github.com/ipa320/cob_command_tools/tree/indigo_dev/cob_monitoring.Accessed 29 Mar 2021

3. DiagnosticStatus message definition. http://docs.ros.org/api/diagnostic_msgs/html/msg/DiagnosticStatus.html. Accessed 29Mar 2021

123

N. Hammoudeh García et al.

4. Docker project website. https://www.docker.com/. Accessed 25Apr 2019

5. IEEE RAS Technical Committee for Software Engineeringfor Robotics and Automation. https://www.ieee-ras.org/software-engineering-for-robotics-andautomation. Accessed 29 Mar 2021

6. Industrie 4.0 an der Börse: Software lukrativer als Hardware.https://www.wiwo.de/finanzen/geldanlage/industrie-4-0-an-der-boerse-softwarelukrativer-als-hardware/14452080-3.html.Accessed 29 Mar 2021

7. RobMoSys—Composable Models and Software. https://robmosys.eu/. Accessed 29 Mar 2021

8. Robotics Software Engineer Nanodegree Program. https://eu.udacity.com/course/robotics-software-engineer--nd209.Accessed 29 Mar 2021

9. ROS metrics wiki site. http://wiki.ros.org/Metrics. Accessed 29Mar 2021

10. ROS: Robot Operating System. http://www.ros.org/. Accessed 25Apr 2019

11. ROS wiki link to the parameter server. http://wiki.ros.org/Parameter20Server. Accessed 29 Mar 2021

12. ROS2: Developers guide. https://index.ros.org/doc/ros2/Contributing/Developer-Guide/. Accessed 28 Feb 2020

13. ScalABLE 4.0 project website. https://www.scalable40.eu.Accessed 29 Mar 2021

14. SeRoNet project website. https://www.seronet-projekt.de.Accessed 29 Mar 2021

15. Simplified interface for syntax trees and program models. https://github.com/gitafsantos/bonsai. Accessed 29 Mar 2021

16. Unified Architecture—OPC Foundation. https://opcfoundation.org/about/opctechnologies/opc-ua. Accessed 29 Mar 2021

17. Adam, S., Larsen, M., Jensen, K., Schultz, U.P.: Towards rule-based dynamic safetymonitoring formobile robots. In: Simulation,Modeling, and Programming for Autonomous Robots, pp. 207–218. Springer International Publishing, Cham (2014)

18. Alonso, D., Vicente-Chicote, C., Ortiz, F., Pastor Franco, J.A.,Álvarez Torres, B.: V3cmm: a 3-view component meta-model formodel-driven robotic software development. J. Softw. Eng. Robot.1, 3–17 (2010)

19. Ando, N., Suehiro, T., Kotoku, T.: A software platform forcomponent based RT-system development: OpenRTM-Aist. In:Simulation, Modeling, and Programming for Autonomous Robots(SIMPAR), pp. 87–98. Springer, Berlin (2008)

20. Bihlmaier, A., Wörn, H.: Increasing ROS reliability and safetythrough advanced introspection capabilities. Informatik 2014,1319–1326 (2014)

21. Brugali, D., Hochgeschwender, N.: Software product line engi-neering for robotic perception systems. Int. J. Semant. Comput.12, 89–107 (2018). https://doi.org/10.1142/S1793351X18400056

22. Brugali, D., Scandurra, P.: Component-based robotic engineering(part I) [tutorial]. IEEE Robot. Autom. Mag. 16(4), 84–96 (2009)

23. Brugali, D., Shakhimardanov, A.: Component-based robotic engi-neering (Part II). IEEERobot.Autom.Mag.17(1), 100–112 (2010).https://doi.org/10.1109/MRA.2010.935798

24. Bruyninckx, H., Klotzbücher, M., Hochgeschwender, N., Kraet-zschmar, G., Gherardi, L., Brugali, D.: The BRICS componentmodel: a model-based development paradigm for complex roboticssoftware systems. In: ACM Symposium on Applied Computing(SAC), SAC ’13, pp. 1758–1764. ACM, New York (2013). https://doi.org/10.1145/2480362.2480693

25. Bubeck, A., Weisshardt, F., Verl, A.: BRIDE—a toolchainfor framework-independent development of industrial servicerobot applications. In: International Symposium on Robotics(ISR/Robotik), pp. 1–6 (2014)

26. Dhouib, S., Kchir, S., Stinckwich, S., Ziadi, T., Ziane, M.:RobotML, a domain-specific language to design, simulate anddeploy robotic applications. In: Simulation, Modeling, and Pro-

gramming for Autonomous Robots (SIMPAR), pp. 149–160.Springer, Berlin (2012)

27. Estevez, E., Sánchez, A., García, J., Ortega, J.: ART2ool: a model-driven framework to generate target code for robot handling tasks.Int. J. Adv. Manuf. Technol. 97, 1–13 (2018). https://doi.org/10.1007/s00170-018-1976-z

28. Estevez, E., Sánchez-García,A.,Gámez-García, J., Gómez-Ortega,J., Satorres, S.: A novel model-driven approach to support devel-opment cycle of robotic systems. Int. J. Adv. Manuf. Technol. 82,737–751 (2016).https://doi.org/10.1007/s00170-015-7396-4

29. Foote, T.: ROS Community Metrics Report. http://download.ros.org/downloads/metrics/metrics-report-2019-07.pdf (2019)

30. Gerkey, B., Stoy, K., Vaughan, R.T.: Player robot server. Tech. rep.,Institute for Robotics and Intelligent Systems, School of Engineer-ing, University of Southern California (November 2000)

31. Gherardi, L., Hunziker, D., Mohanarajah, G.: A software productline approach for configuring cloud robotics applications. In: IEEEInternationalConference onCloudComputing (CLOUD), pp. 745–752. https://doi.org/10.1109/CLOUD.2014.104 (2014)

32. Hägele, M.: Robots conquer the world [turning point]. IEEERobot. Autom. Mag. 23(1), 118–120 (2016). https://doi.org/10.1109/MRA.2015.2512741

33. Hammoudeh Garcia, N., Deval, L., Lüdtke, M., Santos, A., Kahl,B., Bordignon,M.: Bootstrappingmde development from rosman-ual code - part 2: Model generation. In: ACM/IEEE InternationalConference onModel Driven Engineering Languages and Systems(MODELS), pp. 95–105. https://doi.org/10.1109/MODELS.2019.00-11 (2019)

34. Hammoudeh Garcia, N., Lüdtke, M., Kortik, S., Kahl, B., Bor-dignon, M.: Bootstrapping mde development from ROS manualcode—part 1:metamodeling. In: IEEE International Conference onRobotic Computing (IRC), pp. 329–336. https://doi.org/10.1109/IRC.2019.00060 (2019)

35. Hammoudeh Garcia, N., Lüdtke, M., Kortik, S., Kahl, B., Bor-dignon, M.: Bootstrapping MDE development from ROS manualcode. Int. J. Robot. Comput. (IJRC) 2 (2020)

36. Kilgo, P., Syriani, E., Anderson, M.: A visual modeling languagefor RDIS and ROS nodes using atom3. In: Simulation, Modeling,and Programming for Autonomous Robots (SIMPAR), pp. 125–136. Springer, Berlin (2012)

37. Kittmann, R., Fröhlich, T., Schäfer, J., Reiser, U., Weißhardt, F.,Haug, A.: Let me Introduce Myself: I am Care-O-bot 4, a Gentle-man Robot. In: Mensch und Computer, pp. 223–232. De GruyterOldenbourg, Berlin (2015)

38. OMG: Deployment and Configuration of Component-Based Dis-tributed Applications Specification Version 4.0. Object Manage-ment Group (2006)

39. Quigley, M., Conley, K., Gerkey, B.P., Faust, J., Foote, T., Leibs,J., Wheeler, R., Ng, A.Y.: ROS: an open-source robot operat-ing system. In: IEEE International Conference on Robotics andAutomation (ICRA)—Workshop on Open Source Software (2009)

40. Santos, A., Cunha, A., Macedo, N.: Static-time extraction andanalysis of the ROS computation graph. In: IEEE InternationalConference on Robotic Computing (IRC), pp. 62–69 (2019).https://doi.org/10.1109/IRC.2019.00018

41. Santos, A., Cunha, A., Macedo, N., Arrais, R., dos Santos, F.N.:Mining the usage patterns of ROS primitives. In: IEEE/RSJ Inter-national Conference on Intelligent Robots and Systems (IROS), pp.3855–3860 (2017). https://doi.org/10.1109/IROS.2017.8206237

42. Santos, A., Cunha, A., Macedo, N., Lourenço, C.: A framework forquality assessment of ROS repositories. In: IEEE/RSJ InternationalConference on Intelligent Robots and Systems (IROS), pp. 4491–4496. IEEE. https://doi.org/10.1109/IROS.2016.7759661 (2016)

43. Schlegel, C., Worz, R.: The software framework SMARTSOFT forimplementing sensorimotor systems. In: IEEE/RSJ International

123

Bootstrapping MDE development from ROS manual code: Part 2—Model generation and leveraging…

Conference on Intelligent Robots and Systems (IROS), vol. 3, pp.1610–1616. https://doi.org/10.1109/IROS.1999.811709 (1999)

44. Soetens, P.: A software framework for real-time and distributedrobot and machine control. Ph.D. thesis, Department of Mechani-cal Engineering, Katholieke Universiteit Leuven, Belgium. http://www.mech.kuleuven.be/dept/resources/docs/soetens.pdf (2006)

45. Stampfer, D., Lotz, A., Lutz, M., Schlegel, C.: The smartmdsdtoolchain: an integrated mdsd workflow and integrated develop-ment environment (IDE) for robotics software. J. Softw. Eng.Robot. (JOSER) 7, 3–19 (2016)

46. Zaman, S., Steinbauer, G., Maurer, J., Lepej, P., Uran, S.: Anintegrated model-based diagnosis and repair architecture forROS-based robot systems. In: IEEE International Conference onRobotics and Automation (ICRA), pp. 482–489. https://doi.org/10.1109/ICRA.2013.6630618 (2013)

47. Zhang, L., Merrifield, R., Deguet, A., Yang, G.Z.: Powering theworld’s robots—10 years of ROS. Sci. Robot. (2017). https://doi.org/10.1126/scirobotics.aar1868

Publisher’s Note Springer Nature remains neutral with regard to juris-dictional claims in published maps and institutional affiliations.

Nadia Hammoudeh García obtai-ned in 2011 her diploma degreein Telecommunication Engineer-ing from the Universidad Politec-nica de Madrid. In December 2011,she joined as research fellow theDepartment for Robots and Assis-tive Systems of Fraunhofer IPAin Stuttgart, Germany. The first 5years at IPA, among other pub-licly funded and private R&Dprojects, she was involved on thedevelopment of the service robotCare-O-bot4, that nowadays is acommercial product and which is

fully developed with open-source software, the Robot Operating Sys-tem (ROS). Her core activities within the team were related to soft-ware modularity, composability and reconfigurability. Since 2017, sheworks as project manager. She focusses her research on the adaptationof open-source robotics software to be transferred to industrial envi-ronments. More specifically in the fields of software quality assuranceand the simplification of the software design and development processby the adoption of model-driven engineering techniques.

Harshavardhan Deshpande M.Sc.received his masters degree inMechatronics from Fachhochschule Aachen in 2017. In March2018, he joined the Departmentof Robots and Assistive Systemsat Fraunhofer IPA, Stuttgart, Ger-many, as a research engineer. Hehas since been involved with con-tributing to the Robot OperatingSystem (ROS), an open-sourceproject. These projects, along withother publicly- and privately-fund-ed projects he worked on, had astrong focus on software quality

assurance. These experiences led him to his current research area in

runtime and diagnosis of open-source robotics software used specifi-cally in industrial environments.

André Santos has a master degreein Software Engineering from theUniversity of Minho. He is doinghis Ph.D., at the same Univer-sity, on how to bring standardSoftware Engineering practices tothe robotics ecosystem, specifi-cally that of the Robot OperatingSystem, in order to verify criti-cal architectural and behaviouralproperties.

Dr. Björn Kahl completed his stud-ies on theoretical physics at KielUniversity Christian-Albrechts-Universität zu Kiel, Germany, in2000 with the diploma degree.He then moved to the field ofrobotics and received his doctoraldegree in 2007 from University ofBayreuth, Germany, working onfast simulation of contact forcesin assembly tasks. He held mul-tiple research and teaching posi-tions at Bonn-Rhein-Sieg Univer-sity of Applied Sciences in theAutonomous Systems program and

supervised development of complex software systems for robotics andAI in international projects. Since 2012, he is active at Fraunhofer IPAin Stuttgart, Germany, as project manager for European and nationalresearch projects with a focus on software development for robotics.He is currently coordinating the German SeRoNet project, which istasked to push model-driven software development concepts from theEuropean RobMoSys project into the robotics market. Since 2016 heis a leading member of the ISO TC299/WG6 on Modularity for servicerobots. His main research interests are on efficient software develop-ment methods for reliable software for robotics and AI.

Dr. Mirko Bordignon received B.S.and M.S. degrees in Electrical andComputer Engineering from theUniversity of Padova, Italy, and aPhD in Robotics from the Univer-sity of Southern Denmark, withresearch stays at Örebro Univer-sity, Sweden, and Harvard Uni-versity, USA. He explored top-ics in embedded robotics, model-driven software development, anddomain-specific languages (DSLs).He then spent 4 years as a soft-ware engineer in end-of-line indus-trial automation, leveraging DSLs

and other language engineering techniques to streamline development

123

N. Hammoudeh García et al.

of .NET and PLC production code deployed in manufacturing envi-ronments. Dr. Bordignon joined Fraunhofer IPA in Stuttgart, Germany,in 2015. First as a research scientist and then as a group manager,he worked on software engineering and system integration for serviceand industrial robots, both within publicly funded research projectsand private R&D contracts. A recurring theme championed by hisgroup was open-source robotics software, with specific emphasis onthe Robot Operating System (ROS) and its adoption within industrialautomation. Since 2019, he is with Google Germany GmbH.

123