The figure below illustrates the separation of levels and the separation of concerns. Please also refer to the RobMoSys Glossary for descriptions of used terms. The levels indicate abstractions in a robotics system.

The levels can be seen as an analogy to “ISO/OSI model” for robotics that addresses additional concerns beyond communication. The analogy is interesting, because ISO/OSI partitions the communication aspect in different levels of abstraction that then help to discuss and locate contributions. The ISO/OSI separations in levels allows to develop efficient solutions for each level. Establishing such levels for robotics would clearly help to communicate between robotics experts–as ISO/OSI does in computer science.

The levels and concerns can be used to identify and illustrate architectural patterns. The blue line in the figure is an abstract example. An architectural pattern combines several levels and several concerns. For example, the architectural pattern for a software component spans across the levels of service, function and execution container.

See also

• Architectural Patterns

• The lower levels address more concerns and are more cross-cutting in their nature
• The higher levels are more abstract and address less concerns / individual concerns. They thus allow a better separation of concerns and separation of roles.
• By definition, a level can not be defined on its own, since its semantics is the relationships between the items at this “level” and those at the other levels. This exercise to get these relationships well-defined is a tough one, this is of high priority though, since “level”/“layer” is one of the most often used term in (software) architecture.
• A layer is on top of another, because it depends on it. Every layer can exist without the layers above it, and requires the layers below it to function. A layer encapsulates and addresses a different part of the needs of much robotic systems, thereby reducing the complexity of the associated engineering solutions.
• A good layering goes for abstraction layers. Otherwise, different layers just go for another level of indirection. An abstraction layer is a way of hiding that allows the separation of concerns and facilitates interoperability and platform independence.

• Individual levels always exist but are not always explicitly visible.
• Transition between layers can be fluent
• There are single layer approaches (clear separation between layers offering full flexibility in composition) but also hybrid ones (combining several adjacent layers into one loosing flexibility). For example, ROS1 implemented both the middleware and execution container while in ROS2, the middleware level is planned to be separated.
• Different levels might require different technologies
• Individual levels may also be separated horizontally (e.g. fleet of robots vs. an individual robot, or group of components vs. an individual component)

• Below are examples for each of the levels.
• They demonstrate the level of abstraction that can be found in each layer.

• A higher level objective/goal for the robot to achieve.
• At run-time, a robot might need to prioritize one mission over another in order to rise the probability of success and/or to increase the overall quality of service

Examples

• In logistics: do order picking for order 45
• serve customer
• serve as butler

Synonyms

• goal
• objective

• A task (on the Task level) is a symbolic representation of what and how a robot is able to do something, independent of the realization.
• A job that is described independent of the functional realization.
• Includes explicit or implicit constraints.
• tasks might be executed in sequence or in parallel
• task-sets might be predefined statically (at design-time) or dynamically generated (e.g. using a symbolic planner)
• tasks might need to be refined hierarchically (i.e. from a high-level task down to a set of low-level tasks)
• not to be confused with tasks in the sense of processes/threads (see Execution Container)
• see also: Task-Level Composition for Robotic Behavior

Examples

• Move to room nr. 26
• Grasp blue cup
• Get a cup from the kitchen
• deliver coffee

Synonyms

• job

See also:

• Architectural Pattern for Task-Plot Coordination (Robotic Behaviors)

A the skill level is an abstraction level that decouples task-level and service-level. The purpose of abstraction is to enable replacement and composition of components (components providing the same skill) and decoupling (e.g. separation of roles: component developer and behavior developer).

Skills provide access to the functionalities realized within components and make them accessible to the task level. Skills coordinate software components through RobMoSys Software Component Coordination interface. With skill definitions on Tier 2, skills enable the task modeling independent of the underlying software component architecture. Skill implementations are bundled with software components and are provided by the component supplier role.

A skill defines basic capabilities of a robot. The area of transition between high-level tasks and concrete configurations and parameterizations of components on the service-level.

A collection of skills is required for the robot to do a certain task. For example, a butler robot requires skills for navigation, object recognition, mobile manipulation, speaking, etc. A component often implements a certain skill, but skills might also be realized by multiple components.

Skill-level often interfaces between symbolic and subsymbolic representations.

Examples

• An abstract high level task (e.g. move-to kitchen) is mapped to concrete configurations and services that components offer (e.g. parameterize path planning, localization and motion execution components with destination set to kitchen).
• grasp object with constraint

Synonyms

• capability
• system-function

See also:

• Architectural Pattern for Component Coordination
• Robotic Behavior in RobMoSys using Behavior Trees and SmartSoft
• Skills for Robotic Behavior

A service is a system-level entity that serves as the only access point between components to exchange information at a proper level of abstraction.

Services follow a service contract and separate the internal and external view of a component. They describe the functional boundaries between components. Services consist of communication semantics, data structure and additional properties.

Components realize services and might depend on existence of a certain type of service(s) in a later system.

See also: Service-based Composition

• a coherent set of algorithms, for example implemented in libraries, that serve a unique functional purpose
• a piece of software that performs a specific action when invoked using a certain set of inputs to achieve a desired outcome¹⁾

Example

• A function implemented in an library, e.g. OpenCV Blob Finder
• An implemented algorithm, e.g. PID-controller
• Functions developed or modeled in Matlab, Simulink, etc.
• Inverse kinematics (IK) solver

Synonyms

• functional block

• provides the infrastructure and resources for the functional level
• provides mappings towards the underlying infrastructure (e.g. operating system, communication middleware).

Examples

• Access to scheduler
• Threads, eventually processes

Example elements on this level: e.g. phread, socket, FIFO scheduler

An Operating System is, for example, responsible for:

• Memory management
• Inter-Process-Communication
• Networking-Stack, e.g. TCP
• Hardware Abstraction Layer

Examples for Operating System

• Linux, Windows
• FreeRTOS, QNX, vxWorks

A (communication) middleware is a software layer between the application and network stack of the operating system. Communication middlewares are very common in distributed systems, but also for local communication between applications. They provide an abstract interface for communication independent of the operating system and network stack.

There are many distributed middleware systems available. However, they are designed to support as many different styles of programming and as many use-cases as possible. They focus on freedom of choice and, as result, there is an overwhelming number of ways on how to implement even a simple two-way communication using one of these general purpose middleware solutions. These various options might result in non-interoperable behaviors at the system architecture level.

For a component model as a common basis, it is therefore necessary to be independent of a certain middleware.

Examples

• OMG CORBA
• OMG DDS
• ACE

Solid pieces of bare metal that the robot is built of and uses to interact with the physical environment. It includes actors/sensors and processing unit.

Examples

• Sensors: laser scanner, camera
• Actuators: manipulator, robot base/mobile platform
• Processing units: embedded computer, cpu architecture

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.