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

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.

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.

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:

• Component metamodel

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.

• Architectural Pattern for Task-Plot Coordination (Robotic Behaviors)
• Architectural Pattern for Software Components
• Separation of Levels and Separation of Concerns

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.