Best Practice in Robotics (BRICS)Grant Agreement Number: 231940

01.03.2009 - 28.02.2013

Instrument: Collaborative Project (IP)

Tool chain (BRIDE) delivered as BRICSsoftware distribution

Hugo Garcia, Herman Bruyninckx

Deliverable: D4.4

Lead contractor for this deliverable: Katholieke Universiteit LeuvenDue date of deliverable: April 01, 2011Actual submission date: April 25, 2011Dissemination level: PublicRevision: 1.0

Executive Summary

Model-Driven Engineering (MDE) tools for robotics that focus on modeling robotic applica-tions as component based application are a currently being developed in Japan (OpenRTM),Korea (OPRoS), and Europe (BRICS). There is no significant similar or complementary activityknown to take place in North-America, since the very popular Robot Operating System (ROS)is not focusing (at all) on this level of MDE support. All but the ROS efforts have focused on de-veloping a tool chain based on the Eclipse Platform; the motivation for this choice are ratherobvious, given the enormous popularity of Eclipse and its large (professional) user, developerand business community, which is, worldwide, second to none in relevant industrial domains,such as embedded systems and web services (“Service Oriented Architectures”). Currently allthree MDE efforts have released versions of their product at different stages of developmentmaturity. Coordination efforts between all groups are still in the initial phases. The motivationfor such inter-continental coordination is that all three efforts are developing a Model-drivenEngineering tool based on Component Based Development, thus the underlying domain mod-els (should) share a commonality that could potentially be integrated in a unified standardform. Yet the Eclipse based tools have been implemented with different code bases and usingdifferent approaches, available from the rich variety of projects within the ecosystem fosteredby the Eclipse Foundation. In addition, the available tooling only works for specific compo-nent framework, and hence is not reusable over all three development efforts. The differentapproaches are not yet compatible although the few common developments that have alreadytaken place (driven by the BRICS project, with OpenRTM and ROS in particular) have resultedin some “proof-of-concept” bridge code implementations at the component level, but these donot (yet) really provide a usable degree of interoperability.

The European effort (i.e., our BRICS development) is based on:1 Conceptual model: the BRICS Component Model (BCM).2 Reference implementation: the Orocos real-time component framework.

The former is believed to be sufficiently advanced that it can have a worldwide impact; thelatter is mainly used because expertise with it is readily available within the BRICS consortium,and because it already offers a fairly decent implementation of the conceptual model.

The status of this effort is that an Eclipse-based “BRIDE” (BRICS Integrated Development En-vironment) prototype is realised, which supports the developer in the structural model part ofthe BCM; the links with the other BCM parts (coordination, behaviour, communication) areconceptually clear (as a result of the numerous interaction with BRICS’ Component ModelTask Force1) and their place within the Eclipse toolchain is identified, but no implementationsexist already. The BCM took a long time to mature, and only materialised after the insight grewthat the 5Cs for separation of concerns should become the guiding principle for all complexrobotic software designs; these “5Cs” are: Computation, Communication, Coordination, Con-nection, and Configuration. None of the developments worldwide are already based on thatinsight, and hence, are much more ad hoc, in the sense of less strictly based on a clear design“best practice”.

Currently, development with available command line based tooling is mature enough to becombined with different development tools such as IDE’s in order produce stable commer-cial grade robotics software. The tooling is amenable enough to be usable in different soft-

1This Task Force was established towards the end of Year 1 as a new, cross-Work Package activity within BRICS,for the specific reason that we realised we definitely needed something like the BCM to unify many of the effortswithin the consortium; and, in a later stage, also to harmonize the BRICS efforts with other international efforts.Not only the Japanes and Korean ones, but also other European efforts, like SmartSoft.

ii BRICS Deliverable D4.4

ware development methodologies but none of those methodologies have been documentedor presented as a collection of best practices. Thus, sharing of components between groups ishindered by adapting the code base to different development tools and software developmentprocesses. Yet, the process for developing components using Orocos is structured enough, toprovide a context for integration within specific IDE’s such as Eclipse, which present a uniqueuser interface and work flow for software development.

Here we present a prototype implementation of a Model-driven Engineering tool that ad-dresses one particular problem in the development process (using Orocos to provide exe-cutable code), namely, the deployment phase of an application. For this phase, a structuralmodel can be designed within the tool. The tool is based on a pragmatic approach to usabilityduring component development by robotics engineers which we constrain within three se-quential meta processes of (structural) Model → Code → Deploy. The combination of a metaprocess, Orocos and Eclipse, sets the stage for exploring the problems and solutions for devel-oping an IDE for robotics, namely, development process and work flow integration, models thatrepresent all aspects of the system (i.e., also behaviour, communication, configuration,. . . ), agraphical editor to manipulate the models, a specific product based on the models that are in-tegrated with the available command line tooling and using command line tooling that is bestsolved using an IDE, integration and extension of the work flow of the component frameworkvia the IDE such as state machine implementation (“discrete behaviour”) or control algorithm(“continuous behaviour”) development.

BRICS Deliverable D4.4 iii

Contents

1 Problem description 1

2 Model Driven Engineering metamodels 6

2.1 MDE in Eclipse: the Eclipse Modelling Project “EMF” . . . . . . . . . . . . . . . . . 6

2.2 BCM, OpenRTM, OPRoS, Orocos and ROS as MDE instantiations . . . . . . . . . 7

3 The BRICS Component Model 9

4 Conclusions 13

iv BRICS Deliverable D4.4

1 Problem description

The goals of BRICS WP4’s Year 2 efforts were (i) to research the “best” approach for developingan Integrated Development Environment (IDE) for Robotics from a Model-driven Engineeringperspective, and (ii) to make a prototype implementation in Eclipse, to let the community testout the BRICS approach with concrete software. We set out to answer:

1 Who develops robotic software in terms of roles?2 How is robotic software developed, more specifically, which is the process from the pro-

grammers point of view to be used?3 What are the necessary and essential concepts needed for representation of a model(s)

for robotic software?The answer to the last question, the “modelling”, is being given within the BRICS project in a setof concerted activities in different work packages. The preliminary result is the so-called BRICSComponent Model (BCM)—see Section 3 for some more details—that covers all aspects of themodelling of robotics systems. In the context of the work described in this document, only thesimplest part of the BCM, namely the so-called structural model had matured enough to beusable in a concrete software development in Eclipse.

The functionality and work flow of an IDE is determined by the role definition of the user ofthe IDE as seen in the evolution of Eclipse which evolved out of the needs of programmers thatuse object oriented programming languages. During the recent past years there has been abig effort withing the Eclipse community to provide MDA (“Model Driven Architecture”) and/or MDE (“Model Driven Engineering”) support1. The MDA effort has largely been centeredaround UML2 based tools, which follow a two step process of (i) model building, and (ii) codegeneration from the models. More interesting has been the development of tooling to supportDomain Specific Languages (DSL), that allow a specific sub-domain of science and technologyto use the terms and operations that it is familiar with, without having to go to the much moreabstract and domain-independent terminology of UML. By using a DSL, we can provide a con-ceptual model that is more akin to the way that robotic engineers visualize and describe roboticapplications. In addition, a DSL is easier to correlate and translate to an ontology for robotics.3

Within the literature we find the roles for developing component based software to be basedon theory laid down 10 years ago when close to no practical experience was available. Twomajor roles are defined based on the perceived notions of how component software should beconstructed:

1 The Component Designer.2 The Application Builder.

Yet, the separate roles are artificial and represent a theoretical separation of concerns basedon the structure of component frameworks and the dogmatic premise of software re-usabilityand not on explicit and tacit knowledge encountered during actual development of software.The holy grail of software re-usability once was one of the major premises for the acceptanceof object oriented based technologies yet in practice that promise has rarely been achievedbeyond the context of well defined generic API’s such as Boost. For most applications the realityis that the other benefits of object oriented technologies have prevailed as evidenced in theusage of software patterns and their implementation. Therefore, we have decided to take a

1Both terms, MDA and MDE, are considered to be synonyms; the former is a trademark of the OMG, the ObjectManagement Group.

2Unified Modelling Language, one of the OMG’s widely accepted standards.3Such an ontology is an equally necessary development in the domain of robotics (in addition to a model-driven

programming toolchain), since such an ontology would provide the knowledge that is used within the models in acomputer readable and semantically consistent form.

BRICS Deliverable D4.4 1

more pragmatic approach to developing our IDE by first analyzing who is actually buildingrobotic software and what is their knowledge and experience. (A set of “best practice” patternsfor robotics software will be added in the second half of the BRICS project.) We have found thatit is best to categorized the roles based on the actual knowledge and programming aptitude ofthe engineers that produce robotic software. Thus we find four roles:

• Basic Engineer.• Advanced Engineer/Programmer.• Expert Engineer.• Robotics software Engineer.

The Korean OPRoS and the Japanese OpenRTM efforts have approached their user base basedon the general, theoretical view presented in the literature. The structure of their IDE has twoperspectives: one for the component designer and one for the application builder. Each per-specive provides different sets of editors for the roles. The design of the the RTC Builder andRTC System Editor4 reflects the before-mentioned design where the RTC Builder is meant forcomponent building using a form editor for defining the properties of the component and agraphical display for the structure of one and only one component. The graphical representa-tion is very basic and not intended for user interaction, for example, the user cannot add a portdirectly to the component by manipulating a port glyph available from a palette and draggingand attaching it to the component glyph.

Figure 1.1: Screenshot from OpenRTM’s RTC Builder.

The RTC System Editor is more promising conceptually since it provides a structural view ofthe system in real-time where the connected ports and their status is introspected from a livesystem. Some level of port connectivity is achievable using this user interface, but building thesystem graphically from a available set of components is not yet possible.

We have decided to collapse roles into one perspective where the composition of individualcomponents and the building of a the structure of an application are presented within one viewof one perspective as shown in Figure 1.3; this decision is motivated by the fact that it is in full

4RTC = Robotic Technology Component, in the context of the OpenRTM project.

2 BRICS Deliverable D4.4

Figure 1.2: System Editor view in OpenRTM.

accordance with the 5C separation of concerns5 design principles that the BRICS ComponentModel Task Force has identified as a best practice to design complex software systems witha Component-Based Design approach. Thus it is our belief that our user interface will notonly be more intuitive to use, but also more natural to support a “best practice” design anddevelopment process. It is worth stressing at this point that our target user is the Basic Engineerand the Advanced Engineer/Programmer.

Next we examined the different development processes, if any, used for building robotic soft-ware. Here we found the least maturity within the context of our domain. Historically, roboticsoftware development has been based on command line tooling, and the work flow has beenbased on, and limited by, traditional software compilation and building of software. Concep-tual representation of the concepts being programed has not been much of a concern withinthe context of the compilation and building process of an application, because, until recently,(ii) all robotic systems had a design that could still fit in the head on one single “master devel-oper”, and (ii) all robotic systems were made from components designed and developed by thesame, collocated, team of engineers. In addition, there are many tools that can be used in theprocess, tools that for the most part follow the time-proven UN*X way.

We decided to examine the actual development process conducted with the command linetooling and refactor and implement that process using the IDE; the motivation being that thisapproach would have a large chance of success, since it starts from the currently accepted prac-tice, and gradually brings in more MDE concepts, approaches, and tools. In our examinationof the process we found certain activities that could better be handled by the IDE instead of thecurrent manual process, and we could identify some “priority ordering” of which of these ac-tivities could (or should) be tackled first. We defined a simplified generic work flow (Figure 1.4),used by the target roles before-mentioned, that also are within the scope of our meta-processof Model → Code → Deploy.

5These “5Cs” are: Computation, Communication, Connection, Coordination, and Configuration.

BRICS Deliverable D4.4 3

Figure 1.3: Screenshot of the current BRIDE prototype. It shows the support for the Connection config-uration of a composite component, where the interactions take place via identified input/output Ports.

One such activity is the creation of the deployment file used to describe the structure of an ap-plication. The structure of the deployment file actually contain all the concepts in our domainmodel but they are represented using a generic component definition provided by OMG. Theformat of the deployment file is the CORBA Component Property Descriptor. The process ofbuilding this file by hand is tedious and error prone.

Given the target role, the meta process and the UI designs of available IDE’s implementations,we found a particular junction of what, who and how that could be re-engineered within thecontext of the IDE based on MDE principles using a DSL specific to our reference implemen-tation that solved a specific problem in the development of component based robotic applica-tions.

4 BRICS Deliverable D4.4

Figure 1.4: Generic work flow. This is a preliminary, since very incomplete version of the overall De-velopment Process that the BRICS project (eventually) wants to identify, document and suppport. Thiscurrent version reflects that part of the overall process that fits to the scope of the current BRIDE proto-type.

BRICS Deliverable D4.4 5

2 Model Driven Engineering metamodels

Our metamodel for constructing, both, the BCM (BRICS Component Model, Sec. 3), and themodel for our reference implementation, is Ecore1, a key aspect of the (more recent, hencenot yet very widely used, at least in a robotics context!) Eclipse eco-system. As explained, theBCM has had a long gestation period and is still being developed; the main reason being thatthere is currently no “best practice” available in this context, so a very intensive, creative andinnovative step was required (and successfully completed, at least at the conceptual level). TheBCM is meant to represent a generic component model yet this approach precluded its directuse as the model for the graphical editor. The graphical editor is built using Eclipse’s Graph-ical Modeling Framework (GMF) Tooling and Runtime2 provided by the Graphical ModelingProject. GMF works by generating most of the code necessary to implement a graphical edi-tor that is designed to represent and edit and Ecore domain model. Unfortunately, the GMFtooling expects the domain model to be structured in a particular manner akin to the preceptsof graph theory (as applied to represent, for example, a tree and/or composite patterns) andnot a conceptual model that has an amorphous structure. Thus there is the need to have sepa-rate and multiple models, that, although representing the component model, are structured towork with GMF.

BRIDE’s first Domain Specific language (DSL, Sec. 2.1) is thus constructed to provide justenough visual conceptual information to the user such as the structural part of a componentbased application can be realized. (This is depicted in Fig. 1.3.) This model is in turn linkedto another model that represents the deployment file; this file contains the information abouthow the components in the structural model will be mapped to the process or thread primitivesoffered by the operating system underlying the robotics application that has been modelledand will be deployed.

2.1 MDE in Eclipse: the Eclipse Modelling Project “EMF”

EMF is “a modeling framework and code generation facility for building tools and other appli-cations based on a structured data model”.3

The Model-Driven Engineering community has produced a very generically applicable meta-modelling structure, as depicted in Fig.2.1. This is a seemingly over-simple structure, but ithas proven its value in many applications, over a variety of domains.4 From the most concrete,implementation, level M0, one climbs up one level of abstraction, to M1, and so on, to the meta-meta-model level M3. At the M1 and M2 levels, Domain Specific Languages can be defined,that connect optimally with the terminology and concepts that the practitioners in the domainare most familiar with. But all these DSLs are based on the same model at a higher level ofabstraction, so that they represent the same semantic concepts.

One example is given here, because it is very relevant to the topics reported in this document:the component models behind the BRICS Component Model, OpenRTM, OPRoS, Orocos andROS:5

• at the M3 metametamodel level, all frameworks talk about “components”, interconnectedby “ports” over which they “communicate” data and “events”. This level basically just in-

1http://wiki.eclipse.org/Ecore2This Runtime is a part of the Eclipse ecosystem that allows to run one’s own system model editors as stand-alone

programmes, without the need for a full Eclipse programme.3http://www.eclipse.org/modeling/4Some of these will be reported about in other Deliverables of the BRICS project: harmonization, architec-

tures,. . .5The BCM is explained in more detail in Sec. 3.

6 BRICS Deliverable D4.4

2.2. BCM, OPENRTM, OPROS, OROCOS AND ROS AS MDE INSTANTIATIONS

metametamodel

metamodel(DSL)

metamodel(DSL)

domainmodel

domainmodel

domainmodel

instanceof

instance of

M3

M2

M1

M0

instance of

Real-world systems

DSLDesigner

DSLUser

Figure 2.1: The OMG standard “meta modelling” structure.

troduces what are the primitive concepts that a certain model will consist of, and howthey can be composed. So, the mentioned frameworks share (most of) this M3 model,although none of them has already made this explicit.

• at the M2 metamodel level, the M3 concepts are made more concrete, by introducing thedetails about what a “component” really consists of (still at the conceptual, “class” level),what a “communication” really does, etc. Only the OpenRTM and OPRoS frameworkshave “something” at this level, but not represented in a formal, computer-processableway, which is a pre-requisite for later automatic transformation of models, and generationof code.

• at the M1 model level, the system developer makes a model of a concrete system, that is,using instantiations of the classes used at the M2 level.

• the M0 level is not about models anymore, but about executable code.Figure 2.2 depicts MDE’s structure about how the transformations between models can bemodelled themselves. Examples of such transformations could be: the transformation of asub-system (meta)model developed within BRIDE into an equivalent model that can be usedin the OpenRTM toolchain; or the generation of a Domain Specific Model for, say, the roboticssub-domain of surgical robotics, that conforms to the BCM that holds for all robotics systemsin all robotics sub-domains.

None of the mentioned model transformations (or model conformity checks) has already beenimplemented within BRICS, but the chosen Eclipse approach (based on EMF and GMF) makesthese things a lot easier to adopt in the future, since (i) the BRICS Component Model is getting acomplete M0–M3 set of models, and (ii) a lot of tools and implementations are being developedwithin the Eclipse ecosystem to support such transformations.

2.2 BCM, OpenRTM, OPRoS, Orocos and ROS as MDE instantiations

At this point, we have introduced a sufficient set of concepts and models, in order to be ableto give a more detailed, still high-level overview of the similarities and differences between theMDE frameworks that are being developed in the domain of robotics:

• M0–M3 metamodelling: BCM will have them all, in computer-processable representa-tions; OpenRTM and OPRoS have only the M0 to M2 levels, with the latter also not veryformally represented; Orocos and ROS are “just” M0-level implementation frameworks.

BRICS Deliverable D4.4 7

2.2. BCM, OPENRTM, OPROS, OROCOS AND ROS AS MDE INSTANTIATIONS

MetamodelingLanguage

Metametamodel

TargetLanguageMetamodel

TargetModel

conformsto

Transformation

SourceLanguageMetamodel

SourceModel

TransformationDefinition

conformstoconforms

to

conformsto

conformsto

conformsto

Source Target

Figure 2.2: The relationships between different “representation and programming languages” withinOMG’s Model Driven Engineering.

• Eclipse features: BCM will use all modelling, transformation and model-conformitychecking features that are available (or under further development) within Eclipse; OPRoSand OpenRTM’s model editors are just “plug-ins” in Eclipse; and Orocos and ROS useEclipse only as a code-level Integrated Development Environment, without using any ofthe modelling features available in Eclipse.

8 BRICS Deliverable D4.4

3 The BRICS Component Model

As the previous Chapters explained, there are a lot of advantages in following the “hard” wayas BRICS did, that is, following the full Model-Driven Engineering conceptual metamodellingapproach, with the (still not fully complete) toolchain support from the (latest, most advancedversion of the) Eclipse project.

As should be clear from the previous Chapters, we confronted the problem of designing some-thing like the BRICS Component Model using some of the concepts of Domain Driven De-veloping, where we first define the domain model that represents our conceptual framework.Currently, our conceptual framework for developing robotic software is based on ComponentBased Development where our basic model is just structural, that means that is only based onthe modelling primitives that describe the Connection aspects (also known as the component“architecture”):

• Components,• Ports, and• Connections,

and, for a more complete representation, we also include:• Composite/Peer components, and• Services offered by Components.

The preceding concepts can all be found in all component frameworks such Orocos, Open-RTM and OPRos, in one form or another, but not (yet) as formally represented models, onwhich computer programs could do transformations, code generation and consistency check-ing. Two other component framworks of interest in this context are Service Component Archi-tecture (SCA)1, and OSGi2; both have already formally represented “component models”, withmost of the modelling primitives mentioned above. Hence, both serve as very good sources ofinspiration, but their typical use cases (web services, and Java-based “service oriented archi-tecture” systems) have rather different performance and functionality requirements from therobotics domain.

Figure 3.1 depicts a formal (eCore) model of structural part of the BRICS Component Model.Figures 3.2-3.5 give conceptual sketches of how the other parts come into play at (the graphicalmodelling of) a robotic system; these are subject of the further work to be done on BRIDE inthe coming years.

The BRICS IDE is based on the following precepts:• Use the DSL as expressed in the commonality of all component frameworks.• Our user is an Advanced Engineer that is both a Component Designer and Application

Builder.• Adapt the IDE to simplify, improve and expedite the current process.

1http://www.oasis-opencsa.org/sca, http://www.osoa.org/display/Main/SCA+Expressed+as+a+UML+Model.

2http://www.osgi.org.

BRICS Deliverable D4.4 9

Figure 3.1: Formal model of the BRICS Component Model.

Connection

Computation

Communication

Coordination When is something computedand communicated?

Where is something computed,and communicated to/from?

What is communicated?

How is somethingcommunicated?C

on

fig

ura

tion

Wh

at

are

the p

ara

mete

rs t

hat

define a

ll fu

nct

ionalit

ies?

Figure 3.2: Separation of Concerns: the 5Cs of Component-based design

10 BRICS Deliverable D4.4

CompositeComponent

Component1

Component2

Component3

Structural component model

(computation)

(computation)

(computation)

(communication)

(communication)(communication)

Figure 3.3: Structural composition.

CompositeComponent

Component1

Component2

Component3

Structural component model + Communication

(computation)

(computation)

(computation)

Communication3

Communication2

Communication4Communication1

Figure 3.4: Communication concern: each connection between components can be a full-fledged com-ponent in itself, taking care of the exchange of data and events between component Ports.

BRICS Deliverable D4.4 11

CompositeComponent

Component1

Component2

Component3

Structural model + Communication + Coordination

(computation)

(computation)

(computation)

Communication3

Communication2

Communication4Communication1

Figure 3.5: Coordination: each component can have a Finite State Machine to implement its discretebehaviour.

12 BRICS Deliverable D4.4

4 Conclusions

Our prototype addresses only one practical problem of one phase of the development processyet the insight gained by the development of the prototype pave the way for the successful com-pletion of a more robust MDE base product that addresses the problems currently encounteredin the whole development process of component based robotic software. We are actively work-ing in establishing a robust and accessible community of users, building a Generic ComponentGraphical Editor (GCGE) and concretely establishing the relationships of the different models.

We have identified and defined out target user base. One of the major goals in focusing uponour selected user is the goal of minimizing the learning curve currently needed in order to pro-gram a robot. It is hoped that BRIDE can and will be used not only in industry and researchgroups but also within the context of the extraction of our future Master and PhD’s in Mecha-tronics. Fortunately, the Orocos community is well established and provide a easily availableand diverse group of users at different levels who can alpha and beta test BRIDE in a rigorousmanner. In addition, the Eclipse community is also accessible and can provide not only a userbase but a further development base beyond the lifetime of BRICS.

Our current prototype of BRIDE has served to solve a great number of technical and implemen-tation aspects needed in order to build a more robust editor. We now have an implementationthat demonstrates how different models can interact using a editor built with GMF. We haveidentified the need to build a GCGE that focused on the structural aspects of a componentbased application. Furthermore, with the guidance of the 5C’s, we envision a modular archi-tecture that separates the different C’s into modules that will interact with the GCGE. Exposureto the our users to the protoype have and will provide much needed insight into their tacitknowledge thus enhancing the usability of the GCGE.

The current BCM represents the formal theoretical model of component software while themodels used by BRIDE represent the pragmatic domain models needed for the developmentof software. The pragmatic models expand on the concepts of the BCM. The integration andusage of established models such as SCA are expected to contribute greatly to the further de-velopment of models.

BRICS Deliverable D4.4 13