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 term “Platform” is also used in RobMoSys with respect to the target deployment platform / robot platform. See Platform Metamodel. This is not to be confused with the “Digital Platform”.

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.

See also: System Composition in an Ecosystem

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

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

See also: System Composition in an Ecosystem

• 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 Software 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)

See also:

• Communication Pattern

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.

The entity that handles the execution of business logic within a component and manages continuous and one-shot operations. In many operating systems activities are mapped to preemptive threads that can be executed concurrently on a CPU core. In some contexts threads are also called tasks, however, this term is to be avoided for this kind of entity within the RobMoSys context as it is reserved for (behavior) tasks (see Task Level).

See Coordinating Activities and Life Cycle of Software Components

See Separation of Levels and Separation of Concerns

Is an abstract action (i.e., a job) that a robot is able to perform (see Task Level). Please note, that this term does not refer to an operating system thread (which is called activity in RobMoSys).

• job

See Separation of Levels and Separation of Concerns and Skills for Robotic Behavior

See Separation of Levels and Separation of Concerns and Service-based Composition

See Separation of Levels and Separation of Concerns

See Separation of Levels and Separation of Concerns

See Separation of Levels and Separation of Concerns

See Separation of Levels and Separation of Concerns

An umbrella term for concepts, tools (e.g. the SmartMDSD Toolchain), and content (e.g. software components) that are developed at the Service Robotics Research Center Ulm (Service Robotics Ulm). The latest generation of the SmartSoft world adheres to the RobMoSys structures. See The SmartSoft World.

The semantics in which software components exchange data over component services. RobMoSys adopts a set of few but sufficient communication patterns.

See also:

• Service

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:

• 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.
• 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.
• Lutz2017 Matthias Lutz, “Model-Driven Behavior Development for Service Robotic Systems: Bridging the Gap between Software- and Behavior-Models,” 2017. (unpublished work)