Tool chain (BRIDE) delivered as BRICS software distribution

Best Practice in Robotics (BRICS) Grant Agreement Number: 231940 01.03.2009-28.02.2013 Instrument: Collaborative Project (IP) Tool chain (BRIDE) delivered as BRICS software distribution Hugo Garcia, Herman Bruyninckx Deliverable: D4.4 Lead contractor for this deliverable: Katholieke Universiteit Leuven Due date of deliverable: April 01, 2011 Actual submission date: April 25, 2011 Dissemination level: Public Revision: 1.0

Executive Summary Model-Driven Engineering (MDE) tools for robotics that focus on modeling robotic applications as component based application are a currently being developed in Japan (OpenRTM), Korea (OPRoS), and Europe (BRICS). There is no significant similar or complementary activity known 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 developing a tool chain based on the Eclipse Platform; the motivation for this choice are rather obvious, given the enormous popularity of Eclipse and its large (professional) user, developer and business community, which is, worldwide, second to none in relevant industrial domains, such as embedded systems and web services ( Service Oriented Architectures ). Currently all three MDE efforts have released versions of their product at different stages of development maturity. Coordination efforts between all groups are still in the initial phases. The motivation for such inter-continental coordination is that all three efforts are developing a Model-driven Engineering tool based on Component Based Development, thus the underlying domain models (should) share a commonality that could potentially be integrated in a unified standard form. Yet the Eclipse based tools have been implemented with different code bases and using different approaches, available from the rich variety of projects within the ecosystem fostered by the Eclipse Foundation. In addition, the available tooling only works for specific component framework, and hence is not reusable over all three development efforts. The different approaches are not yet compatible although the few common developments that have already taken place (driven by the BRICS project, with OpenRTM and ROS in particular) have resulted in some proof-of-concept bridge code implementations at the component level, but these do not (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; the latter 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 Environment) prototype is realised, which supports the developer in the structural model part of the BCM; the links with the other BCM parts (coordination, behaviour, communication) are conceptually clear (as a result of the numerous interaction with BRICS Component Model Task Force 1 ) and their place within the Eclipse toolchain is identified, but no implementations exist already. The BCM took a long time to mature, and only materialised after the insight grew that the 5Cs for separation of concerns should become the guiding principle for all complex robotic software designs; these 5Cs are: Computation, Communication, Coordination, Connection, and Configuration. None of the developments worldwide are already based on that insight, 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 be combined with different development tools such as IDE s in order produce stable commercial grade robotics software. The tooling is amenable enough to be usable in different soft- 1 This 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 efforts within 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 documented or presented as a collection of best practices. Thus, sharing of components between groups is hindered by adapting the code base to different development tools and software development processes. Yet, the process for developing components using Orocos is structured enough, to provide a context for integration within specific IDE s such as Eclipse, which present a unique user interface and work flow for software development. Here we present a prototype implementation of a Model-driven Engineering tool that addresses one particular problem in the development process (using Orocos to provide executable code), namely, the deployment phase of an application. For this phase, a structural model can be designed within the tool. The tool is based on a pragmatic approach to usability during component development by robotics engineers which we constrain within three sequential meta processes of (structural) Model Code Deploy. The combination of a meta process, Orocos and Eclipse, sets the stage for exploring the problems and solutions for developing an IDE for robotics, namely, development process and work flow integration, models that represent all aspects of the system (i.e., also behaviour, communication, configuration,... ), a graphical editor to manipulate the models, a specific product based on the models that are integrated with the available command line tooling and using command line tooling that is best solved using an IDE, integration and extension of the work flow of the component framework via 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 developing an Integrated Development Environment (IDE) for Robotics from a Model-driven Engineering perspective, and (ii) to make a prototype implementation in Eclipse, to let the community test out 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 programmers 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 set of concerted activities in different work packages. The preliminary result is the so-called BRICS Component Model (BCM) see Section 3 for some more details that covers all aspects of the modelling of robotics systems. In the context of the work described in this document, only the simplest part of the BCM, namely the so-called structural model had matured enough to be usable in a concrete software development in Eclipse. The functionality and work flow of an IDE is determined by the role definition of the user of the IDE as seen in the evolution of Eclipse which evolved out of the needs of programmers that use object oriented programming languages. During the recent past years there has been a big effort withing the Eclipse community to provide MDA ( Model Driven Architecture ) and/ or MDE ( Model Driven Engineering ) support 1. The MDA effort has largely been centered around UML 2 based tools, which follow a two step process of (i) model building, and (ii) code generation from the models. More interesting has been the development of tooling to support Domain Specific Languages (DSL), that allow a specific sub-domain of science and technology to use the terms and operations that it is familiar with, without having to go to the much more abstract and domain-independent terminology of UML. By using a DSL, we can provide a conceptual model that is more akin to the way that robotic engineers visualize and describe robotic applications. 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 based on theory laid down 10 years ago when close to no practical experience was available. Two major roles are defined based on the perceived notions of how component software should be constructed: 1 The Component Designer. 2 The Application Builder. Yet, the separate roles are artificial and represent a theoretical separation of concerns based on the structure of component frameworks and the dogmatic premise of software re-usability and 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 acceptance of object oriented based technologies yet in practice that promise has rarely been achieved beyond the context of well defined generic API s such as Boost. For most applications the reality is that the other benefits of object oriented technologies have prevailed as evidenced in the usage of software patterns and their implementation. Therefore, we have decided to take a 1 Both terms, MDA and MDE, are considered to be synonyms; the former is a trademark of the OMG, the Object Management Group. 2 Unified Modelling Language, one of the OMG s widely accepted standards. 3 Such 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 a computer readable and semantically consistent form. BRICS Deliverable D4.4 1

more pragmatic approach to developing our IDE by first analyzing who is actually building robotic software and what is their knowledge and experience. (A set of best practice patterns for robotics software will be added in the second half of the BRICS project.) We have found that it is best to categorized the roles based on the actual knowledge and programming aptitude of the 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 based on the general, theoretical view presented in the literature. The structure of their IDE has two perspectives: one for the component designer and one for the application builder. Each perspecive provides different sets of editors for the roles. The design of the the RTC Builder and RTC System Editor 4 reflects the before-mentioned design where the RTC Builder is meant for component building using a form editor for defining the properties of the component and a graphical display for the structure of one and only one component. The graphical representation is very basic and not intended for user interaction, for example, the user cannot add a port directly to the component by manipulating a port glyph available from a palette and dragging and 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 of the system in real-time where the connected ports and their status is introspected from a live system. Some level of port connectivity is achievable using this user interface, but building the system graphically from a available set of components is not yet possible. We have decided to collapse roles into one perspective where the composition of individual components and the building of a the structure of an application are presented within one view of one perspective as shown in Figure 1.3; this decision is motivated by the fact that it is in full 4 RTC = 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 concerns 5 design principles that the BRICS Component Model Task Force has identified as a best practice to design complex software systems with a Component-Based Design approach. Thus it is our belief that our user interface will not only be more intuitive to use, but also more natural to support a best practice design and development process. It is worth stressing at this point that our target user is the Basic Engineer and the Advanced Engineer/Programmer. Next we examined the different development processes, if any, used for building robotic software. Here we found the least maturity within the context of our domain. Historically, robotic software development has been based on command line tooling, and the work flow has been based on, and limited by, traditional software compilation and building of software. Conceptual representation of the concepts being programed has not been much of a concern within the 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 developer, and (ii) all robotic systems were made from components designed and developed by the same, collocated, team of engineers. In addition, there are many tools that can be used in the process, 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 line tooling and refactor and implement that process using the IDE; the motivation being that this approach would have a large chance of success, since it starts from the currently accepted practice, and gradually brings in more MDE concepts, approaches, and tools. In our examination of the process we found certain activities that could better be handled by the IDE instead of the current manual process, and we could identify some priority ordering of which of these activities 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-process of Model Code Deploy. 5 These 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 configuration 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 application. The structure of the deployment file actually contain all the concepts in our domain model but they are represented using a generic component definition provided by OMG. The format of the deployment file is the CORBA Component Property Descriptor. The process of building 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 the context of the IDE based on MDE principles using a DSL specific to our reference implementation that solved a specific problem in the development of component based robotic applications. 4 BRICS Deliverable D4.4

Figure 1.4: Generic work flow. This is a preliminary, since very incomplete version of the overall Development Process that the BRICS project (eventually) wants to identify, document and suppport. This current version reflects that part of the overall process that fits to the scope of the current BRIDE prototype. BRICS Deliverable D4.4 5

2 Model Driven Engineering metamodels Our metamodel for constructing, both, the BCM (BRICS Component Model, Sec. 3), and the model for our reference implementation, is Ecore 1, a key aspect of the (more recent, hence not yet very widely used, at least in a robotics context!) Eclipse eco-system. As explained, the BCM has had a long gestation period and is still being developed; the main reason being that there is currently no best practice available in this context, so a very intensive, creative and innovative step was required (and successfully completed, at least at the conceptual level). The BCM is meant to represent a generic component model yet this approach precluded its direct use as the model for the graphical editor. The graphical editor is built using Eclipse s Graphical Modeling Framework (GMF) Tooling and Runtime 2 provided by the Graphical Modeling Project. GMF works by generating most of the code necessary to implement a graphical editor that is designed to represent and edit and Ecore domain model. Unfortunately, the GMF tooling expects the domain model to be structured in a particular manner akin to the precepts of graph theory (as applied to represent, for example, a tree and/or composite patterns) and not a conceptual model that has an amorphous structure. Thus there is the need to have separate and multiple models, that, although representing the component model, are structured to work with GMF. BRIDE s first Domain Specific language (DSL, Sec. 2.1) is thus constructed to provide just enough visual conceptual information to the user such as the structural part of a component based application can be realized. (This is depicted in Fig. 1.3.) This model is in turn linked to another model that represents the deployment file; this file contains the information about how the components in the structural model will be mapped to the process or thread primitives offered by the operating system underlying the robotics application that has been modelled and 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 applications based on a structured data model. 3 The Model-Driven Engineering community has produced a very generically applicable metamodelling structure, as depicted in Fig.2.1. This is a seemingly over-simple structure, but it has 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 metameta-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 domain are most familiar with. But all these DSLs are based on the same model at a higher level of abstraction, 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 and ROS: 5 at the M3 metametamodel level, all frameworks talk about components, interconnected by ports over which they communicate data and events. This level basically just in- 1 http://wiki.eclipse.org/ecore 2 This 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. 3 http://www.eclipse.org/modeling/ 4 Some of these will be reported about in other Deliverables of the BRICS project: harmonization, architectures,... 5 The 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 M3 M2 meta model (DSL) metametamodel instance of instance of meta model (DSL) DSL Designer M1 domain model domain model domain model DSL User instance of M0 Real-world systems Figure 2.1: The OMG standard meta modelling structure. troduces what are the primitive concepts that a certain model will consist of, and how they 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 the details about what a component really consists of (still at the conceptual, class level), what a communication really does, etc. Only the OpenRTM and OPRoS frameworks have something at this level, but not represented in a formal, computer-processable way, which is a pre-requisite for later automatic transformation of models, and generation of 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 be modelled themselves. Examples of such transformations could be: the transformation of a sub-system (meta)model developed within BRIDE into an equivalent model that can be used in the OpenRTM toolchain; or the generation of a Domain Specific Model for, say, the robotics sub-domain of surgical robotics, that conforms to the BCM that holds for all robotics systems in all robotics sub-domains. None of the mentioned model transformations (or model conformity checks) has already been implemented within BRICS, but the chosen Eclipse approach (based on EMF and GMF) makes these things a lot easier to adopt in the future, since (i) the BRICS Component Model is getting a complete M0 M3 set of models, and (ii) a lot of tools and implementations are being developed within 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 able to give a more detailed, still high-level overview of the similarities and differences between the MDE frameworks that are being developed in the domain of robotics: M0 M3 metamodelling: BCM will have them all, in computer-processable representations; OpenRTM and OPRoS have only the M0 to M2 levels, with the latter also not very formally 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 conforms to Source Language Metamodel Source Model Source conforms to Metamodeling Language Metametamodel conforms to Transformation Definition conforms to Transformation conforms to Target Language Metamodel conforms to Target Model Target Figure 2.2: The relationships between different representation and programming languages within OMG s Model Driven Engineering. Eclipse features: BCM will use all modelling, transformation and model-conformity checking features that are available (or under further development) within Eclipse; OPRoS and OpenRTM s model editors are just plug-ins in Eclipse; and Orocos and ROS use Eclipse only as a code-level Integrated Development Environment, without using any of the 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 way as BRICS did, that is, following the full Model-Driven Engineering conceptual metamodelling approach, with the (still not fully complete) toolchain support from the (latest, most advanced version of the) Eclipse project. As should be clear from the previous Chapters, we confronted the problem of designing something like the BRICS Component Model using some of the concepts of Domain Driven Developing, where we first define the domain model that represents our conceptual framework. Currently, our conceptual framework for developing robotic software is based on Component Based Development where our basic model is just structural, that means that is only based on the 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, on which computer programs could do transformations, code generation and consistency checking. Two other component framworks of interest in this context are Service Component Architecture (SCA) 1, and OSGi 2 ; both have already formally represented component models, with most of the modelling primitives mentioned above. Hence, both serve as very good sources of inspiration, but their typical use cases (web services, and Java-based service oriented architecture systems) have rather different performance and functionality requirements from the robotics 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 graphical modelling of) a robotic system; these are subject of the further work to be done on BRIDE in the 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. 1 http://www.oasis-opencsa.org/sca, http://www.osoa.org/display/main/sca+ Expressed+as+a+UML+Model. 2 http://www.osgi.org. BRICS Deliverable D4.4 9

Figure 3.1: Formal model of the BRICS Component Model. What are the parameters that define all functionalities? Configuration Coordination Connection Computation Communication When is something computed and communicated? Where is something computed, and communicated to/from? What is communicated? How is something communicated? Figure 3.2: Separation of Concerns: the 5Cs of Component-based design 10 BRICS Deliverable D4.4

CompositeComponent Component1 (communication) Component3 (communication) Component2 (communication) Structural component model Figure 3.3: Structural composition. CompositeComponent Component1 Communication3 Component3 Communication1 Component2 Communication4 Communication2 Structural component model + Communication Figure 3.4: Communication concern: each connection between components can be a full-fledged component in itself, taking care of the exchange of data and events between component Ports. BRICS Deliverable D4.4 11

CompositeComponent Component1 Communication3 Component3 Communication1 Communication2 Component2 Communication4 Structural model + Communication + Coordination Figure 3.5: Coordination: each component can have a Finite State Machine to implement its discrete behaviour. 12 BRICS Deliverable D4.4

4 Conclusions Our prototype addresses only one practical problem of one phase of the development process yet the insight gained by the development of the prototype pave the way for the successful completion of a more robust MDE base product that addresses the problems currently encountered in the whole development process of component based robotic software. We are actively working in establishing a robust and accessible community of users, building a Generic Component Graphical 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 upon our selected user is the goal of minimizing the learning curve currently needed in order to program a robot. It is hoped that BRIDE can and will be used not only in industry and research groups but also within the context of the extraction of our future Master and PhD s in Mechatronics. Fortunately, the Orocos community is well established and provide a easily available and diverse group of users at different levels who can alpha and beta test BRIDE in a rigorous manner. In addition, the Eclipse community is also accessible and can provide not only a user base 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 implementation aspects needed in order to build a more robust editor. We now have an implementation that demonstrates how different models can interact using a editor built with GMF. We have identified the need to build a GCGE that focused on the structural aspects of a component based application. Furthermore, with the guidance of the 5C s, we envision a modular architecture that separates the different C s into modules that will interact with the GCGE. Exposure to the our users to the protoype have and will provide much needed insight into their tacit knowledge thus enhancing the usability of the GCGE. The current BCM represents the formal theoretical model of component software while the models used by BRIDE represent the pragmatic domain models needed for the development of software. The pragmatic models expand on the concepts of the BCM. The integration and usage of established models such as SCA are expected to contribute greatly to the further development of models. BRICS Deliverable D4.4 13