Architectural Pattern for Software Components


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

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:


R. Peter Bonasso, R. James Firby, Erann Gat, David Kortenkamp, David P. Miller, and Mark G. Slack. “Experiences with an architecture for intelligent, reactive agents”. In: Journal of Experimental & Theoretical Artificial Intelligence, Volume 9, 1997, DOI: 10.1080/095281397147103.
general_principles:architectural_patterns:components · Last modified: 2019/05/20 10:49