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.

A wiki allows to create many different entry points that are dedicated to the various perspectives, needs and level of knowledge of the RobMoSys' target audience. The RoMoSys consortium maintains maximum transparency: a wiki allows to immediately publish information without delay and to iteratively extend existing pages.

The project uses a two-stage publication process for content in the wiki. This helps us to collaborate internally but at the same time release new content quickly for maximum transparency. The two-stage publishing process helps us to maintain consistency. Please note that the RobMoSys Wiki is a living document.

A link that gives a “Permission Denied” error message means that the page is being prepared for initial public release by the RobMoSys consortium (and no prior version was released). Please check back later.

A link in red font indicates a page that the consortium plans to create in future.

During the project runtime, Snapshots of the wiki are taken to freeze it. The snapshots provide a stable reference to use in project proposals. You can write your proposals based on the wiki snapshots but we encourage you to trace the updates in the live Wiki for selected pages of your interest (an updated Changelog helps you easily finding new contents)

• For a general project description, please refer to the project website at robmosys.eu
• See the video "RobMoSys explained: What is the aim of RobMoSys?" for a quick introduction
• We use the PC domain as an analogy to describe what we aim for in RobMoSys and how we achieve it
• See the primary user-stories and the technical user-stories for a user-perspective on the aims of RobMoSys
• For more detailed insights, we recommend reading the publicly available excerpt of the RobMoSys Grant Agreement: "Section 1 / Excellence"

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.

Please see the Roadmap of Tools and Software

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

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.

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.

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.

They can contribute on all tiers, but most likely will extend or connect to the composition structures on composition tier 1. Since RobMoSys is asking for runnable systems, you will probably also implement examples for tier 2 and tier 3. To not start from scratch with tier 2 and tier 3 but start with a decent level of system complexity, you can also use existing building blocks, scenarios or pilots provided by RobMoSys, see Tools and Software Baseline and pilots.

RobMoSys identifies a small set of meta meta models that are absolutely necessary for every project to adhere to. We remain open to improve their formulation and concrete representation together with the community. Contribute your structures to Tier 1 and align, connect, or use the existing structures. You can modify existing structures, but make sure to explain your reasons. Detail the changes and explain their effects.

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.

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 RobMoSys Glossary, Introduction to System Composition in an Ecosystem.

• Please refer to the RobMoSys general user stories
• Your role in the RobMoSys ecosystem probably is the Component Supplier or

• Please refer to the RobMoSys general user stories
• Your role in the RobMoSys ecosystem probably is the System Builder

• Read how the RobMoSys ecosystem is organized to see how tooling can contribute
• The RobMoSys composition structures on Tier 1 provide a starting point for the metamodels.

There are several levels of modeling. See Modeling Principles - What is "Modeling"? for an explanation.

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:
  • Markus Voelter. DSL Engineering. CreateSpace Independent Publishing Platform, 2013. http://www.dslbook.org
• 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: http://www.joser.org.

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 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.

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 Pilot Skeletons: Demonstrating the RobMoSys Approach 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.