Note: This is a snapshot of the RobMoSys Wiki as of January 31 2019. Live Version for this page.
general_principles:architectural_patterns:component-coordination

Architectural Pattern for Component Coordination

The here proposed pattern structures and semantically enriches the access of the functionalities within components for coordination by defining a component coordination interface. The interface enables the run-time coordination of the components by robotic behavior models on skill and task abstraction level. This interface is the foundation for robotic behavior development and system orchestration (as described in Architectural Pattern for Task-Plot Coordination (Robotic Behaviors)).

Context

The architectural pattern can be used in the context of coordination of closed software components. The pattern deals only with the concern of coordination and is located at the abstraction level of services, lifting the access to the functionalities within a software component to the skill abstraction level (see Separation of Levels and Separation of Concerns). It involves the roles of the Service Designer (Domain Experts), the Component Supplier and the Behavior Developer.

Problem

Functionalities within closed software components needs to be coordinated to so that the robot as a whole is able to provide a service. The access to the functionalities within the components needs to be on a balanced level to avoid fine grained interaction, so that the user of the software component does not need to know implementation specific details of the component.

The coordination of the component needs to be possible without binding the behavior models (task level description) to a concrete component.

Solution

The solution is to define an uniform behavior coordination interface for robotics software components. The interface is two fold: the coordinating component part and the coordinated component part. The coordinating component part is typically realized/implemented by a sequencer component in case of a 3T / three tier architecture (see Architectural Pattern for Task-Plot Coordination (Robotic Behaviors)).

The coordination access to a component via the interface can be grouped into six basic categories, each with a different purpose, semantic and communication mechanism:

  • Configuration - Run-Time configuration or parameterization of components, for coordination.
  • Activation - Activation of activities and therefor the functionalities within the components.
  • Results (Events) - Receiving the results of the activation of the functionalities within the components.
  • Connection - Coordination of the inter-component connections and thereby configuring the data flow of the coordinated components.
  • Component Life-Cycle - Providing access to components life-cycle e.g. shutdown or error states of the components.
  • Information Query - Requesting and receiving information for coordination from components.

The relation of the interface parts to the component parts is shown by the following figure:

The realization of the coordination interface within RobMoSys is done using the Communication/Coordination and Configuration Pattern.

See also:

Discussion

The interface proposed in the pattern harmonizes the coordination access to the components and the functionality encapsulated by them. This allows for the separation of the behavior coordination and behavior models from the functionalities.

See also

Acknowledgement

general_principles:architectural_patterns:component-coordination · Last modified: 2019/05/20 10:50
http://www.robmosys.eu/wiki-sn-03/general_principles:architectural_patterns:component-coordination