The RobMoSys communication patterns define the semantics in which software components exchange data over Services, e.g. via one-way “send”, two-way “request-response”, and publish/subscribe mechanisms on a timely basis or based on availability of new data. RobMoSys defines communication patterns to enable composability of services and components.
The general concept of a communication pattern originates from [Schlegel2004] where it is described in the context of the SmartSoft Framework in 2004. Since that, the there described communication patterns have been extended by several activities and have proven to be of generic use (see e.g. [UCM]). RobMoSys adopts a set of existing communication patterns (see below) that have proven to be relevant. For their definition, the wiki provides specific pointers to existing external documentation.
It is important to have a fixed set of a few communication patterns that efficiently support composition through unambiguous communication semantics and clearly defined communication interfaces. In addition, the mapping to different communication middlewares becomes possible over a generic middleware abstraction layer that is part of each communication pattern.
The communication pattern metamodel is depicted below. The name of an individual pattern (middle row of elements in the figure, e.g. send, query, push) refers to its definition in an external document as described in the remainder of this page.
The four communication patterns (see table below) define the basic set of recurring communication semantics that proved to be sufficient for all robotics use-cases related to inter-component communication at the service level (for service level, see Separation of Levels and Separation of Concerns).
|One way communication
|[Schlegel2004, pp. 85-88]
|Two way request/response
|[Schlegel2004, pp. 88-96]
|[Schlegel2004, pp. 96-99]
|1-n asynchronous condition notification
|[Schlegel2004, pp. 103-112]
The figure below provides a schematic overview of the communication semantics.
The four coordination and configuration patterns (see table below) provide recurring semantics that proved to be sufficient for robotics use-cases related to behavior coordination (coordination of software components at the lower / skill level of the robotic behavior by the sequencing layer; for layers in robotic behavior coordination see Architectural Pattern for Task-Plot Coordination (Robotic Behaviors)).
|Run-time configuration of components, see [Stampfer2016]
|see [Schlegel2014], [Lutz2017]
|Lifecycle management and mode (de-)activation
|Run-time connection re-wiring
|see [Schlegel2004, p. 112]
|Run-time monitoring and introspection of components [Stampfer2016]
Each component in a system should by default implement the slave part of each of the four patterns. In addition, there is typically one specific component per system that implements the master part of the patterns and that is responsible to centrally coordinate the robot behavior (the sequencer, see Architectural Pattern for Task-Plot Coordination (Robotic Behaviors) and for Component Coordinationfor further details).
The Parameter pattern allows run-time configuration of components. The following links provide further details:
The state management of a component is one of the central patterns for run-time coordination of components. On the one hand, state management is about the generic lifecycle state-automaton (see figure on the right) that each component implements by default and that allows coordinated handling of the component's start-up and shutdown procedures as well as the component's fatal-error mode. In addition, component's individual run-time modes can be specified as explained in the following reference:
Dynamic Wiring is used to increase run-time robustness and flexibility by dynamically changing the wiring between components. Additional details can be found here:
Run-time Monitoring and Introspection of components is an important aspect in robotics that requires dedicated interaction mechanisms. The following reference provides details of a concrete realization: