Architectural Templates

To implement a multi-robot control architecture an abundant set of software architectures and architecture templates exists with varying degrees of applicability and level of details.

The following sections lists a selected set of reference architectures which are related to the implementation of a control architecture for reconfigurable multi-robot systems.

FIPA Abstract Architecture

The FIPA Abstract Architecture (Foundation for Intelligent Physical Agents 2002a) provides a template for the software architecture of physical multi-agent systems with focus on agent communication. FIPAintends to establish agent interoperability by defining communication standards and is therefore of particular interest for an application with heterogeneous multi-robot systems. The architecture specifies services and message formats which in combination define a so-called Agent Communication Channel. ThisAgent Communication Channel in-terconnects agents for a speech-act based information exchange (Searle, Kiefer, and Bierwisch 1980). This communication channel is established through several main services: message transport service, agent directory service, and service directory service. A message transport service acts correspondingly to a post office. First, it receives an envelope also referred to as letter, which contains a message. Then it uses the information of the letter to identify the recipients. In case the current message transport service is directly associated with the recip-ient it delivers the letter. Otherwise the letter is forwarded to reciprecip-ient’s associated message transport service. An agent directory service permits to identify the message transport service which is responsible for the recipient agent: each agent registers itself in this directory with a communication endpoint; here the related message transport service.

Table 5.1: Structure of a message according to theFIPAStandards (Foundation for Intelligent Physical Agents2002b).

Category Parameter Description

Type of communicative act

performative Classification into: inform, request, propose, not_understood, . . .

Participant(s)

sender Sender of the message

receivers One or more receivers of the message

reply-to One or more receivers of the message - allows for redirection

Content of message

content Main payload of the message with arbitrary content, which can be encoded in different ways

Description of content

language User-defined language of the content, e.g., la-bel on how to interpret content

encoding Encoding (bit-efficient, xml, string) of the content, e.g., use to reduce message size ontology Ontology that should be used when

interpret-ing the content

Control of conversation

protocol Interaction protocol selection to validate the protocol conformance of communication conversation-id Identify a particular dialogue between

agents, which follows an interaction protocol reply-with Conversation label

in-reply-to Continue a labelled conversation

reply-by Request a reply within a certain time frame

The exchange of information is based on messages, which are standardised according to the fields listed in Table5.1. The fieldssender,recipientsandcontentare mandatory. AFIPA

mes-sage can contain arbitrary payload in thecontent field. To communicate how to process and understand the data in the content field, thecontent language field allows to provide a label.

Given that a shared understanding exists on the label, agents can thereby identify whether and how they are able to process the content field. Since the general concept ofFIPA communica-tion is based upon speech-act theory (Searle, Kiefer, and Bierwisch1980),FIPAmessage com-munication assumes that agents can enter one or more conversations on particular topics with each other. This approach is a distinctive element compared to robotic frameworks which often neglect this element of conversation or rather stateful communication. The usage of speech-act theory is reflected in the consideration of interaction protocols and conversation. Interaction protocols allow a high-level structuring of communication based on so-called performatives, so that a default structure of a conversation between two agent can be described even without knowing the actual content of the messages. The use of conversation which follow a particular interaction protocol therefore allows for the potential validation of distributed agent commu-nication, e.g., to achieve auction based agreement (Weiss2009). TheFIPAstandards suggest the use of content languages such as FIPA-SL (Foundation for Intelligent Physical Agents2002a) or KIF (Genesereth1998), but custom content languages can also be defined. A number of imple-mentations of the architectural template exist with a focus on software agents andJava Agent DEvelopment Framework (JADE) (Bellifemine, Poggi, and Rimassa 1999) has been the first reference implementation. Other approaches are Jack^{T M} (Winikoff 2005), FIPA-OS (Poslad, Buckle, and Hadingham2000) and Mobile-C (Chen, Cheng, and Palen2006). All reference im-plementations are JAVA-based except for Chen, Cheng, and Palen’s Mobile-C, which is based on C/C++. Mobile-C’s focus is however on software agents and migration of software agents across different physical machines. Hence, despite the popularity ofFIPAstandards in the field of multi-agent systems, an adoption of these standards in the area of physical agents is rarely seen.

CCSDS Reference Architecture

The Consultative Committee for Space Data Systems (CCSDS) is an organisation which has been formed by a number of space agencies to establish standards across the space industry with focus on communication and data systems. Similarly to the FIPAAbstract Architecture theCCSDSsuggests aReference Architecture for Space Data Systems(RASDS) for an applica-tion in spaceflight systems. A comparison between theFIPAand theCCSDSapproach exists (CCSDS MOIMS SM&C and IEEE FIPA Comparison2007) and the comparison shows several similarities between the two approaches, including the message transport facilities and the use of interaction patterns. The comparison suggests thatFIPA’s approach is more general and flex-ible, whereasCCSDS’s approach is more restrictive due to its known application context and focus on space applications. In contrast toFIPA, theCCSDSstandards consider access control, quality of service, and require a message abstraction layer. Meanwhile,FIPA standards con-sider a fully distributed communication system, aka peer-2-peer communication, something which is of no concern for theCCSDScommunication system. Hence,FIPAstandards are bet-ter suited for an application in a multi-robot scenario.

The comparison shows thatFIPAandCCSDSapproaches are closely related and partially over-lapping. FIPA based applications are expected to be adaptable for integration into a space related software system. Hence, using aFIPA-based implementation approach is a comprise to maintain a level of flexibility for novel, research oriented application, while at the same time targeting a future space application.

Functional Reference Model

As part of the identification of development and design techniques for space mission Putz and Elfving (1991) have suggested a set of reference models including the so-calledFunctional Ref-erence Model(FRM), theApplication Reference Model (ARM)and theOperations Reference Model (ORM). TheFRMhas been developed to establish a methodology to design space control system with the help of a generic template which can fit all kind of control architectures. Fig-ure5.1depicts the basic structure of this template, which is split into three vertical and three horizontal layers. The vertical decomposition leads to a hierarchical control layout composed

Figure 5.1:The basic structure of theFRMas described by Putz and Elfving (1991, p. 94).

of three execution, planning and control layers for the mission (C), its tasks (B) and resulting actions (A). Assuming an application of this reference model for robot control, layer A provides the lowest level of granularity and highest level of detail. Its implementation corresponds to the actual control system on a robotic system, and an action corresponds to the execution of one or more control functions of a robotic system, e.g., opening or closing a gripper. More complex robot activities or rather tasks require the sequencing of multiple actions, which are part of layer B. An overall robotic mission is based on the sequencing of a set of tasks at layer C.

Nominal (sensor) feedback allows to establish sensor-based control loops, while a non-nominal feedback channel allows to extract significant information from the nominal and forward con-trol channel, e.g., to identify strategies for failure handling. Each layer can provide local failure handling, but when the layer fails to identify and apply the failure handling approach, it has to delegate the error handling to the next upper (commanding) layer.

"TheFRM, because of its extremely generic nature, is necessarily vague in details" (Putz and Elfving1991, p. 25), and since it is only an architectural reference model, it does not provide implementation details. However, theFRMhas been complemented with theARMandORM.

TheARMdetails aFRM-based control architecture by focusing on the implementation of a par-ticular application, and Putz and Elfving give multiple application classes as examples among which are: control of robot systems and control of surface roving vehicles’ motion. Working out theARMfor a particular application class corresponds to the identification of application specific control loops, actions, and action sequencing. The overall development approach fol-lows a rather strict hierarchical decomposition approach to identify and design the capabilities

of individual robots with respect to a specific space mission. This approach still leaves the detailed design of software interfaces open to the developers who implement the architecture.

Finally, theORMgroups operational aspects along three dimensions. The first dimension al-lows to assign the performance of a function to either a human or a machine. The second dimension distinguishes between an online performance and an offline performance of a tool.

The third dimension considers the application of functions on-board/on-orbit or on-ground, e.g., while the former requires space qualified software development, the latter does not. A classification along these dimensions defines the requirements for systems or persons who per-form and/or trigger an activity. Hence, this classification clarifies needs and responsibilities, and facilitates the identification of development needs, e.g., for the interface design and space qualification of components.