The figure below illustrates the separation of levels and the separation of concerns. Please also refer to the 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. An architectural pattern combines several levels and several concerns. The blue line is an abstract example.

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

• 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

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

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

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

• job

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.

Skills enable tasks to become independent of the actual realization in components.

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.

• 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

• capability
• system-function

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.

• 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¹⁾

• 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

• functional block

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

• Access to scheduler
• Threads, eventually processes

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

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

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

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

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

• Below is an example of how tasks can be composed.
• It shows how tasks and skills can be composed flexibly
• Several tasks can be composed to be executed in sequence or in parallel (horizontal composition)
• A task can be refined with other tasks (vertical composition): Abstract tasks are refined to more concrete tasks.
• Refinement of tasks may be static or dynamic
  • Static: The tasks and eventually the order is known. E.g. making coffee always involves approaching the machine, putting a cup into the machine, pressing the button, etc.
  • Dynamic: The tasks and the order are not known in advance (i.e. to be solved by symbolic planning): E.g. it is not known what is the best way to clean up the table after customers left (what order, what to stack into each other, what to carry at once/first/next/last, etc.)
• Skills will finally translate to configurations of one or more components (lower right). E.g. moving the manipulator requires to configure the component for collision-free manipulation-planning in a certain environment and the manipulator component to move along these collission-free trajectories.
• Grasp cup relies on the existence of a task “recognize-object” which is later bound to “recognize-cup”.
• There are constraints that have to be maintained during the execution of a task, for example: the robot is not moving while manipulating.
• There are results of a task that effect execution of other tasks, even after the current task was finished. For example, grasping a cup means that the cup still is in the gripper after the execution is done.

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)