User Tools

Site Tools


Frequently Asked Questions

This page provides answers to frequently asked questions with a technical focus. For questions related to the project in general or open calls, please refer to the project-level FAQ.

What is RobMoSys about?

When will RobMoSys be ready to use?

The core concepts are already now usable! RobMoSys is an innovation action that has just started, but a tooling baseline is already provided. This software baseline already conforms to many of the core RobMoSys principles: For example, the absolute core of RobMoSys is already fully supported by SmartSoft. The SmartMDSD Toolchain assists in applying it as a user while the open source implementation and available metamodels can serve as a base to implement open call contributions. See software baseline for tools and their roadmap and modeling roadmap.

As the RobMoSys structures evolve through the open calls, the RobMoSys metamodels and tooling will do so as well. To make use of RobMoSys, you do not have to wait for the tools and project to complete: you can already now start using the proposed structures and apply the architectural patterns in your systems to gain from the RobMoSys benefits.

Why does RobMoSys not address <put method here>, which is absolutely required to reach what RobMoSys is aiming for?

Great! We're open to your ideas and your contributions. We even have funding to do so in two open calls. RobMoSys needs the support of the robotics community to identify and realize the necessary structures to enable composition in a robotics ecosystem. See open calls and read about the role of open call applicants in the project-level FAQ

Does providing a model for my building block mean that I have to expose all my IP in that model?

No, of course not! We compare modeling to providing a data sheet in the PC analogy. The data sheets of building blocks include all information that is necessary to compose them to a system. For example, the data sheet of a graphics card contains information about its interface(s), its power consumption, and form factor. Based on these properties, a system builder can plan the system without the building block present. The data sheet allows for taking specific views on the system, for example plan for the power supply, plan for the placement of fans to optimize thermal conditions.

Models only expose what is relevant to use the building block. IP, for example, may be hidden in binary form in the software artifact that the model represents.

The RobMoSys structures seem to be complex. What's in for me as a user?

As a user of the RobMoSys approach, tools support you in applying the RobMoSys structures. That means, you will not get in touch with most of the structures, but you still can benefit from them. As an analogy, the internal mechanisms of a word processing program are complex, but it is simple to use for an author. In the same vein, you can use the RobMoSys tools to design and develop your building blocks that can be easily used by others. Or you can find the right building blocks from others to build your system. See the RobMoSys primary user-stories and the Software Baseline provided by RobMoSys.

Where can I find the RobMoSys metamodel?

The RobMoSys composition structures consists of many interlinked metamodels. Thus, there is not THE one metamodel. Please refer to organization of the RobMoSys ecosystem for the description of composition tiers. The RobMoSys composition structures on Tier 1 provide a starting point for the metamodels.

What is a component in RobMoSys?

When speaking of a “component” we refer to a software component: as the unit of composition that provides functionality to the system through formally defined services at a certain level of abstraction. See also: Component Metamodel, Definition of a component in the glossary, service-based composition of software components.

What is the difference between composition and integration?

System Composition is the activity of putting together a set of existing building blocks to match system needs with a focus on flexible (re-)combination. System integration is the activity that requires effort to combine components, requiring modifications or additional actions to make them work with others. See glossary, introduction.

I am a technology provider; where to start?

I am a system integrator; where to start?

I am a tooling provider; where to start?

I am new to MDSE, DSLs, and modeling. Where can I read about it?

As a user of the RobMoSys approach (e.g. to contribute or use building blocks on Tier 3), no MDSE expertise is required. The benefits of the approach and the structures will become usable through tooling. If you want to learn more about MDSE, we recommend reading:

  • For a brief introduction on MDSD and its benefits, see the "Section 1 / Excellence" of the published RobMoSys Grant Agreement.
  • A recommended book on MDSD:
    • Marco Brambilla, Jordi Cabot und Manuel Wimmer. Model-Driven Software Engineering in Practice. Synthesis Lectures on Software Engineering. Morgan & Claypool Publishers, 2012. ISBN: 978-1-60845-882-0. DOI: 10.2200/S00441ED1V01Y201208SWE001
  • An overview on MDSD in robotics is given by:
    • Davide Brugali. “Model-Driven Software Engineering in Robotics”. In: IEEE Robotics & Automation Magazine 22.3 (Sep. 2015), S. 155–166. DOI: 10.1109/MRA.2015.2452201.
  • Recommended read for Domain Specific Languages:
  • An extensive overview on the state of the art on DSLs in robotics can be found in:
    • Arne Nordmann, Nico Hochgeschwender, Dennis Wigand und Sebastian Wrede. “A Survey on Domain-specific Modeling and Languages in Robotics”. In: Journal of Software Engineering for Robotics (JOSER) 7.1 (Juli 2016), S. 75–99. ISSN: 2035–3928. Link:

Can I use RobMoSys with <insert robotics framework here>?

At the moment, RobMoSys provides a software baseline that conforms to the RobMoSys composition structures. RobMoSys can be mapped to other approches and we expect that several mappings will be provided: a perfect idea how to contribute to RobMoSys. The RobMoSys structures can be mapped to virtually any robotics framework. Model-based toolchains can support in this mapping. However, depending on the richness of the framework this mapping will be done on a more higher or a more lower level requiring more or less glue logic in between. Thus, some frameworks such as e.g. SmartSoft can be more easily mapped with RobMoSys than others, e.g. ROS.

ROS is in very widespread use; why does RobMoSys not build upon ROS?

ROS is semantically not rich enough to apply it for composition in an ecosystem as it is envisioned in RobMoSys. RobMoSys can be used with ROS but the restrictions mentioned in “Can I use RobMoSys with <insert robotics framework here>?” apply here, too.

ROS, in line with its overall design philosophy, does not yet give enough structure in an appropriate format in order to better support separation of roles and separation of concerns. The minimally required structures are a sound software component model which has to be formalized for use in model-driven tools in order to support separation of concerns (e.g. to maintain semantics independently of the OS/middleware mapping), to assist the different roles in conforming to structures like component life-cycles and to reduce exposed complexity by systematic and computer-assisted management of variation points.

There is a decent entry-level to contribute to the RobMoSys approach. What can I use to build upon instead of starting at a low level from scratch?

RobMoSys provides the core composition structures to build upon and extend. It provides a baseline for tools and software baseline to use or to extend. RobMoSys also provides pilots to demonstrate the use of its approach through full applications with service robots. The pilots can be provided to support designing, developing, testing, benchmarking and demonstrating their contribution.

faq · Last modified: 2017/08/01 13:58