• A common way to handle system complexity is Component-Based Software Engineering
• Individual components are composable building-blocks that can be (re-)used in different applications (i.e. systems)
• Components in a system are not independent of each other but need to exchange data
• Interconnected components realize (and collaboratively execute) overall system functions (e.g. the navigation stack)

Modeling and developing a software component is the main responsibility of Component Suppliers.

This architectural pattern relates to the following abstraction levels:

• Skill (level) requires a coordination interface for each component
• Service (level) specifies interaction points to other components (i.e. the communication concern)
• Function (level) realizes the component’s internal functionality
• Execution Container (level) links functionality with the execution platform (i.e. the computation concern)
• Hardware (level) allows to directly interact with sensors and/or actuators within a component

• The overall system behavior at run-time is the result of sets of interconnected components that need to be executed in a systematic and deterministic way.
• Real-world environments are open-ended and unpredictable in nature which requires a certain adaptability and flexibility of the robot system behavior.
  • System flexibility in turn requires run-time reconfigurability of individual components. Configuration options of individual components might involve design-time and run-time configurability and depend on the internal (i.e. functional) realization of a component.
• There are cases where several provided services might need to be realized in a single component (e.g. because the used library cannot be separated into several components)
• The overall role of a component is manifold:
  • to realize a coherent set of provided services
  • to specify dependencies to other services (provided by other components)
  • to encapsulate (i.e. decouple) the functional (internal) realization of services from their general representation on system level
  • to specify allowed configuration options and possible run-time modes (i.e. to be used from the skill level)
  • to hide platform-related details such as communication middleware, operating system and internally used device drivers (i.e. mapping to the execution container and interacting with sensors/actuators)

The concept of a component spans across several abstraction levels:

From a functional point of view, a component spans over “Execution Container”, “Function”, “Service” and optionally also the “Skill” levels. From the robotic behavior coordination point of view, a component is on the level of robotic skills¹⁾.

A flexible component model that allows different bundlings of several provided services and that decouples the service definition from its realization within a component:

• a component can realize more than one provided service but a certain provided service is realized by exactly one distinct component
• a component should implement or use a service but not define it (service definition is a separated step)

In addition to the “regular” services a component also implements a generic configuration and coordination interface that provides access to:

• the component's life-cycle state automaton
• admissible run-time modes (i.e. activity states)
• the component's configuration parameters (i.e. allowed parameter sets)
• the coordinated dynamic wiring of component’s services (i.e. without conflicting with the component's internal functionality)

See also:

• Component metamodel

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.