The glossary contains descriptions of used 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.
There are two different definitions of digital platforms:
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 Petty20133)).
We distinguish integration as an activity and integration as in “integration-centric”.
See also: System Composition in an Ecosystem
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.
A service can be defined in two different ways:
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 (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.
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
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).
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.
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 Dijkstra19827)).
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:
A recurring principle for structuring meta-models at different levels of abstraction. It can be applied on the same level and between different levels.
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
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.
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.
This document contains material from: