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

Component bundling 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:

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