Buschmann et. al.¹⁾ provides the following descriptive definition of a pattern in general:

“A pattern describes a particular recurring design problem that arises in specific design contexts, and presents a solution to it. The solution scheme is specified by describing its constituent components, their responsibilities and relationships, and the ways in which they collaborate.” ²⁾

Moreover, Buschmann et. al.³⁾ lists some common properties of a pattern:

• “Patterns document existing, well-proven design experience.”
• “Patterns provide a common vocabulary and understanding for design principles.”
• “Patterns support the construction of software with defined properties.”
• “Patterns help you build complex and heterogeneous software. Patterns help you manage software complexity.”

The proposed scheme by Buschmann for describing a software pattern consists of a Context, Problem and the Solution. This triple is used below to also describe individual architectural patterns which analogously address recurring design problems in robotics software development, each occurring in a specific design context, and present a well-proven solution to the design problem. There are two fundamental objectives that drive the design of all presented architectural patterns, namely:

• Facilitate building systems by composition
• Support Separation of Roles

Each architectural pattern needs to contribute towards these two objectives.

This is a template for describing an architectural pattern including the required sections that the description must comprise.

A context describes a situation in which the design problem occurs. Also relate the context to:

• the Levels and Concerns
• involved Roles

This part describes a recurring problem that repeatedly arises in a given context. This can start with a general, open ended problem and get more concrete with driving forces and concrete requirements that the solution must fulfill. Also, constraints to consider and desired properties of the solution can be expressed here.

The solution describes how the problem is solved, thereby balancing the driving forces. In some cases, available technologies can be listed here that solve the given problem.

Any discussion of shortcomings, differences or references to other patterns can be described here.

Specific scenarios or technologies that help to understand the problem and/or solution can be listed here.

(alphabetical order)

• Architectural Pattern for Communication
• Architectural Pattern for Component Coordination
• Architectural Pattern for Software Components
• Architectural Pattern for Managing Transitions of System States
• Architectural Pattern for Task-Plot Coordination (Robotic Behaviors)
• Architectural Pattern for Service Definitions
• Architectural Pattern for Stepwise Management of Extra-Functional Properties

• Architectural Pattern for Coordination-Frame Transformation
  • Transformation tree (e.g. TF in ROS, Time-Stamps, Pose-Stamps, etc.)
• Subsidiarity Principle
  • at any time a clear control hierarchy
  • delegate decision spaces top-down in the hierarchy
• Knowledge Representation
  • central Knowledge Base
  • synchronize and conflate distributed system-models over global IDs
• Reservation based Resource Management
  • in KB through Tasks and Skills for coordination of Components