RobMoSys adopts a composition-oriented approach to system integration that manages, maintains and assures system-level properties, while preserving modularity and independence of existing robotics platforms and code bases, yet can build on top of them. System Composition is the action or activity of putting together a service robotics system from existing building blocks (e.g. software components) in a meaningful way, flexibly combining and re-combining them depending on the application's needs.

• Composition is about the management of the interfaces between different roles (participants in an ecosystem) in an efficient and systematic way.
• Composition is about guiding the roles via superordinate composition-structures.
• Composition is about explicating and managing properties.
• Composition is about the right levels of abstraction.
• Composition is about access restriction and views for roles.

We operationalize architectural patterns and composition such that properties of system-of-systems become known in order to build trust in the system under development.

System composition puts a focus on the new whole that is created from existing parts rather than on making parts work together only by glueing them together: the whole still consists of its parts, they do still exist as entities and are thus still exchangeable. This is in contrast to integration.

Software components, for example, that are subject to composition shall be taken as-is (and only configured on model level within predefined configuration boundaries). Software components thus have to be built with this intention right from the beginning. The context in which they will later be composed is unknown, which puts special requirements on their composability and the overall workflow.

Composition is about guiding the roles via superordinate composition-structures. It is about adhering to a composition structure, thus gaining immediate access to all other parts that also adhere to this (same) structure. In contrast, integration is about building adapters between (all) parts or even modifying the parts themselves.

A distinction between integration and composition can be drawn by the effort (see ¹⁾): the ability to readily combine and recombine composable components distinguishes them from integrated components, which are modified with high effort to make them work with others, essentially by writing adapters. The integrated part amalgamates with the whole (i.e. the whole becomes one part, individual parts blend together, as red and green water will mix), thus making it hard to remove or exchange individual parts from the whole. If they are removed, it requires new adapters/adjustments.

Acknowledgement

This document contains material from:

• Lotz2018 Alex Lotz, "Managing Non-Functional Communication Aspects in the Entire Life-Cycle of a Component-Based Robotic Software System", Dissertation, Technische Universität München, München 2018.
• Lutz2017 Matthias Lutz, “Model-Driven Behavior Development for Service Robotic Systems: Bridging the Gap between Software- and Behavior-Models,” 2017. (unpublished work)
• Stampfer2018 Dennis Stampfer, "Contributions to System Composition using a System Design Process driven by Service Definitions for Service Robotics". Dissertation, Technische Universität München, München, Germany, 2018.