User Tools

Site Tools


RobMoSys Glossary

The glossary contains descriptions of used terms.

General Terms


A collaboration model (cf. Bosch20101), Iansiti20042) ), 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

Digital Platform

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

System Composition (Activity)

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

System Integration (Activity)

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

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

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:


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:


A combination of interacting elements organized to achieve one or more stated purposes. 5)


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

Extra-functional properties (see Sentilles20126) ) 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

Modeling Twin

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

Engineering Model

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.

Activity (in a RobMoSys software component)

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

Mission (Level)

Task (as in task plot for robotic behavior or as in task level)

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

Skill (Level)

Service (Level)

Function (Level)

Execution Container (Level)

Operating System and Middleware (Level)

Hardware (Level)

SmartSoft / The SmartSoft World

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.

Communication Pattern

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

See also:

General Principles

Separation of Roles

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.

Separation of Concerns

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

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

Freedom OF choice vs. freedom FROM choice

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

Architectural Pattern

  • 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
  • e.g. extra-functional property

Objectives for Architectural Patterns

  • Facilitate building systems by composition
  • Support Separation of Roles

Block, Port and Connector

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 (Concern)

Computation is related to active system parts that consume CPU time

Communication (Concern)

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

Coordination (Concern)

  • 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 (Concern)

  • 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

Cross-Cutting Concern

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:



Jan Bosch, Petra Bosch-Sijtsema. “From integration to composition: On the impact of software product lines, global development and ecosystems”, in Journal of Systems and Software, Volume 83, Issue 1, January 2010, Pages 67-76, ISSN 0164-1212, DOI: 10.1016/j.jss.2009.06.051
Iansiti, Marco, and Roy Levien. “Strategy as Ecology”, in Harvard Business Review 82, no. 3 (March 2004).
Mikel D. Petty and Eric W. Weisel. “A Composability Lexicon”, in Proc. Spring 2003 Simulation Interoperability Workshop, March 2003, Orlando, USA.
Clemens Szyperski. “Component Software: Beyond Object-Oriented Programming (2nd ed.)”. In Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2002.
ISO/IEC 15288:2008 (IEEE Std 15288-2008
Séverine Sentilles. “Managing Extra-Functional Properties in Component-Based Development of Embedded Systems”. Dissertation. Mälardalen University, Västerås, Sweden, 2012.
E. W. Dijkstra. “On the role of scientific thought”. In Selected Writings on Computing: A Personal Perspective, pages 60–66. Springer-Verlag, 1982.
Edward A. Lee. “Disciplined Heterogeneous Modeling”. In: MODELS 2010. Invited Keynote Talk. Oslo, Norway, 2010.
glossary · Last modified: 2019/05/20 10:46