The glossary contains descriptions of used terms.

A collaboration model (cf. Bosch2010¹⁾, Iansiti2004²⁾ ), which describes the many ways and advantages in which stakeholders (e.g. experts in various fields or companies) network, collaborate, share efforts and costs around a domain or product.

Robotics is a diverse and interdisciplinary field, and contributors have dedicated experience and can contribute software building blocks using their expertise for use by others and system composition.

Participants in an ecosystem do not necessarily know each other, thus the challenge is to organize the contributions without negotiating technical agreements and without adhering to a synchronized development process to organize the contributions.

See Ecosystem Organization

There are two different definitions of digital platforms:

• Economical Definition: Multi-sided market gateways creating value by enabling interaction between two or more complementary customer groups.
• Innovation Definition: Reference architecture/implementation with an innovation ecosystem triggering broad value creation.

Platform is not to be confused with the MDA's definition. This definition relates to a concrete technology (in most cases referring to a communication middleware technology such as e.g. CORBA).

The action or activity of putting together a service robotics application from existing building blocks (here: software components) in a meaningful way, flexibly combining and re-combining them depending on the application's needs.

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

Composition is about the management of the interfaces between different roles (participants in an ecosystem) in an efficient and systematic way.

Composition is about explicating and managing properties.

Composition is about access restrictions and views for roles.

The activity that requires effort to combine components, requiring modification or additional action to make them work with others (see Petty2013³⁾).

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.

We distinguish integration as an activity and integration as in “integration-centric”.

• The ability to combine and recombine building blocks as-is into different systems for different purposes in a meaningful way.

• It is the basic prerequisite for system composition since it is the property that makes parts become building blocks. Composability has aspects both between components (parts) and the application (whole). Composability comprises syntactic and semantic aspects.

• Composability requires that properties of sub-system are invariant (“remain satisfied”) under composition

• Splittability is “inverse” relationship of composability

• The ability to compose different modules in a methodological way in order to meet predictable functional and extra-functional requirements.
• Compositionality is a system-level design concern, that reflects the extent to which system designers are able to predict the behaviour of their system on the basis of the formally known behaviour of each of the system’s components.

A component is the unit of composition that provides functionality to the system through formally defined services at a certain level of abstraction (cf. Szyperski2002⁵⁾ ).

A component holds the implementation to bridge between services and functions. A component is defined through a component model and can realize one or more services and interacts with others through services only. When speaking of components, we refer to explicit software components as in the SmartSoft World, in contrast to component as a synonym for an arbitrary piece or element of something (as e.g. in AADL).

A component comprises several levels. It is the unit of composition that is being exchanged in the ecosystem.

See also:

• Architectural Pattern for Bundling Components
• Component Metamodel
• Component Supplier role
• Component Development View

A service can be defined in two different ways:

• a service in the sense of service-oriented architectures (SOA) that provides a self-contained business functionality to a consumer independent of its realization
• one concrete form of a service that is targeted at composition of software components for robotics (see Service Level)

A combination of interacting elements organized to achieve one or more stated purposes. ⁶⁾

Any system should, in itself, be usable as a building block in a larger system-of-systems. In other words, being a component or a system is not an inherent property of any set of software pieces that are composed together in one way or another.

An organizational structure of a system that describes the relationships and interactions between the system's elements. Architectural aspects can be found at different levels of abstraction.

Extra-functional properties (see Sentilles2012⁷⁾ ) are system-level requirements that rule the way in which the system must execute a function, considering physical constraints as time and space. Typical extra-functional properties specify constraints on progress, frequency of execution, maximum time for the execution, mean time between failures, etc.

• non-functional properties

A modeling twin describes the packaging of a software/hardware artefact with its model-based representation in order to ship it as a whole (i.e. bundle) to other participants in an ecosystem. The model part of the modling twin is mandatory while the software/hardware part is optional (depending on the current artefact at hand).

See: Modeling Twin

RobMoSys foresees the definition of modeling views that cluster related modeling concerns in one view, while at the same time connecting several views in order to be able to define model-driven tooling that supports in the design of consistent overall models and in communicating the design intents to successive developer roles and successive development phases.

In this sense, a view establishes the link between primitives in the RobMoSys composition structures and the RobMoSys roles. Views enable roles to focus on their responsibility and expertise only. The RobMoSys composition structures ensure composability of building blocks contributed and used by the role.

See: RobMoSys Views

In contrast to Scientific Modelling, engineering models additionally need to be machine-processable in order to enable composition and usage of this model in other models. This is a fundamental feature that improves scalability and modularity of models and model-driven engineering methods. In other words, engineering models always need to provide a benefit and serve a clear purpose with respect to all the other surrounding models of the overall system where this model is part of.

A principle that enables and supports different groups of stakeholders in playing their role in an overall development workflow without being required to become an expert in every field (in what other roles cover).

A role has a specific view on the system at an adequate abstraction level using relevant elements only.

It is closely related to separation of concerns and a necessary prerequisite for system composition towards an robotics ecosystem.

A principle in computer science and software engineering that identifies and decouples different problem areas to view and solve them independent from each other (see Dijkstra1982⁸⁾).

It is the basis for separation of roles and a necessary prerequisite for system composition towards an robotics ecosystem.

System development tools generally follow one of the two following approaches:

• One approach is called freedom of choice. One tries to support as many different schemes as possible and then leaves it to the user to decide which one best fits his needs. However, that requires huge expertise and discipline at the user side in order to avoid mixing noninteroperable schemes. Typically, academia tends towards preferring this approach since it seems to be as open and flexible as possible. However, the price to pay is high since there is no guidance with respect to ensuring composability and system level conformance.
• Freedom from choice (see Lee2010⁹⁾) gives clear guidance with respect to selected structures and can ensure composability and system level conformance. However, there is a high responsibility in coming up with the appropriate structures such that they do not block progress and future designs.

• A selection of a (sub)set of concerns and levels to fulfill an objective
• An architectural pattern addresses a single level, may connect two related levels or may involve several levels
• See Architectural Patterns
• e.g. extra-functional property

• Facilitate building systems by composition
• Support Separation of Roles

A recurring principle for structuring meta-models at different levels of abstraction. It can be applied on the same level and between different levels.

See Block-Port-Connector

Computation is related to active system parts that consume CPU time

Communication concerns the exchange of information between related entities on the same level and also between the levels themselves

• Design and modeling of robot behaviors
  • i.e. what happens when and who is involved
• it includes:
  • execution order, (system) states
  • error-handling, resp. error propagation
  • run-time adaptation and (online) reconfiguraiton
  • contingency handling and adaptation rules and strategies

• Configuration involves several entities (in contrast to parametrization which typically involves one entity)
  • for example: a set of components (path planning, localization, motion execution) that is configured to work together (move to a destination)
• includes static/dynamic parameter-settings of individual components
• includes static/dynamic wiring between interacting components

A concern that cannot be separated from others or decomposed and influences or affects multiple properties and areas in a system possibly at different levels of abstraction. For example, security cannot be considered in isolation and cannot be added to a given application by introducing a security-module; it rather has to be considered in all areas of the system.

• Non-Functional Properties involve several concerns

A certain task or activity with associated concerns that someone (individual, group or organization) takes in the composition-workflow using a view. For example, the Component Supplier role uses the Component Development View view to come up with a component model that conforms to the Component Metamodel.

Someone that takes a particular role typically is an expert in a particular field (e.g. object recognition). A role takes a particular perspective or view on the overall workflow or application. It is associated with certain tasks, duties, rights, and permissions which do not overlap with other roles.

A role has a specific view on the system at an adequate abstraction level using relevant elements only. A role is responsible for supplying a part of the system. “Role” in the sense of a participant of the ecosystem.

See also:

• Roles in the Ecosystem
• RobMoSys Views

This document contains material from:

• Lotz2017 Alex Lotz, “Managing Non-Functional Communication Aspects in the Entire Life-Cycle of a Component-Based Robotic Software System,” 2017. (unpublished work)
• Lutz2017 Matthias Lutz, “Model-Driven Behavior Development for Service Robotic Systems: Bridging the Gap between Software- and Behavior-Models,” 2017. (unpublished work)
• Stampfer2017 Dennis Stampfer, “Contributions to Composability using a System Design Process driven by Service Definitions for Service Robotics,” 2017. (unpublished work)