Communication between entities (i.e. exchange of information). Communication is a concern and relates to the following levels:

• Service (level) structures communication
• Execution container (level) provides resources for communication
• Operating System / Middleware (level) realizes communication
• Hardware (level) does communication

This architectural pattern relates to the following roles:

• Service Designer: selects communication pattern (see below)
• System Builder: selects communication middleware

• A huge number of communication middlewares
• A huge number of overlapping and conflicting communication schemes
• Requirements that the solution must fulfill:
  • Realize vertical (i.e. layers) and horizontal (e.g. components) exchange of information (with the goal to enable communication, coordination and configuration)
  • Support different schemes for data-flow oriented communication and coordination/configuration concerns
  • At the minimum provide:
    • Publish/Subscribe (i.e. data-flow) communication semantics
    • Request/Response (i.e. on demand) communication semantics
  • Support independence of the underlying middleware solution (i.e. middleware abstraction layer)
  • Reduce the huge variety of overlapping communication semantics in order to improve composability between components
  • Decouple the access to communication within a component (functional-level) from the communication between two interacting components (service-level)

An essential set of communication patterns that is rich enough to cover common communication use-cases, yet at the same time reduced enough to support composability.

• CommunicationPatterns (for continuous data transfer)
  • Request/Response
    • e.g. SmartSoft-Query
  • Publish/Subscribe
    • e.g. SmartSoft-Push (sub-variants: PushNewest and PushTimed)
• ConfigurationPattern (for component configuration)
  • Component Parametrization
    • e.g. SmartSoft-Parameter
  • Dynamic Wiring
    • e.g. SmartSoft-Wiring
• CoordinationPattern (for skill realization)
  • Component Lifecycle Automaton
    • e.g. SmartSoft-State (generic lifecycle state automaton)
  • Component (activity) Modes
    • e.g. SmartSoft-State (user-defined states) and SmartSoft-Parameter (trigger)
  • Component Feedback
    • e.g. SmartSoft-Event

See also:

• Communication Patterns

Different middlewares allow for different middleware abstraction levels. For instance, message-based middlewares require a protocol-based abstraction, while e.g. DDS allows for a higher level of abstraction (i.e. directly using the publish/subscribe communication with accordingly preselected QoS attributes). In any case, middleware details should be hidden from both, the component’s internal communication access and the communication semantics between components.

The separation of patterns into groups for Communication (i.e. continuous data exchange), Configuration (i.e. parametrization of individual components) and Coordination (i.e. skill-component interaction) provides solutions for recurring communication problems and clarifies the purpose of a particular pattern.

The communication access from within a component (i.e. communication interface access) needs to be as flexible as possible as long as it does not violate with the clearly specified communication semantics outside of the component (resp. between interacting components).

Not every semantic detail needs to be made explicit on model level (some may come from “de-facto standard” implementations). The focus in models need to be on a consistent representation and systematic management of different communication schemes.

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)