Agent Communication

The problem with using sequential proof methods for concurrent protocols is that in general the behavior of a system of threads does not only depend on the behavior of the single threads but also on matters like synchronization, interaction and so on. Of course, it is surely much more difficult to specify and verify a set of concurrently running threads and their interactions than specify/verify a single thread of control. Nevertheless, some researchers have contributed to this research area, using as different calculi as temporal logics [80], compositional specification and verification [25, 157], formal languages [31, 30, 33, 35] or automata and Petri nets [32, 189, 34, 137, 112, 199]. The use of a special class of Petri nets seems to us most promising to model interaction protocols and verify their behavior.

Recently, there has been a joint effort on standardizing mandatory prop-erties of a common MAS infrastructure. This effort is undertaken by the foundation for intelligent physical agents (FIPA, [76]). As of the writing of this work, the FIPA has not yet produced a complete standard. FIPA doc-uments are still under heavy construction. Nevertheless, FIPA already ad-dresses the main challenges of a MAS infrastructure with in-depth documents on agent management [73], agent communication [72, 74, 75], agent interac-tion protocols [77] and ontology management [78]. FIPA also gives advise for technical questions on mapping the specification to common techniques such as extensible markup language (XML, [265]) for structured knowledge rep-resentation and common object request broker architecture (CORBA, [201]) for synchronous object interaction. This standardization effort is promising to guide the different proposals for solving the various multi-agent system infras-tructure problems into a common direction. However, following a standard is time-consuming and restricting. Since our main target is the assessment of the AuReCon concept, we have decided to adopt the FIPA standards only as a paragon and design our own custom concepts that suit the demands mentioned in Sect. 5.1 best.

5.3 Agent Communication

5.3.1 Speech Acts

According to [165], agent communication differs from traditional forms of entity interaction techniques, such as OSF’s remote procedure call (RPC), Sun’s remote method invocation (RMI) or CORBA’s Internet inter-orb pro-tocol (IIOP) for two reasons

– Agent communication is based on exchanging propositions, rules, and ac-tions instead of objects without semantics.

– Agent communication facilitates messages that describe desired states in a declarative language, rather than a procedure or method.

98 5. Multi-Agent System Infrastructure

Due to this, research in agent communication is more likely rooted in linguis-tics and logic than in technical interaction protocols. Agent communication languages (ACLs) usually base on the linguistic concept ofspeech acts[224].

Fundamental to the speech act theory is the conjecture that using speech is often equivalent to acting. This has led to the notion of aperformativewhich is “an utterance that succeeds simply because the speaker says or asserts it”

[165].

We use the following speech acts for defining semantics in information exchange. They are defined roughly following [75].

query(q) The action of asking another agent for information.queryis accom-panied by an information specification.

inform(i) The action of giving another agent information possibly following a prior specification in aqueryspeech act.informis accompanied by a piece of information, e.g. a predicate-logic expression or a concrete object.

request(r) The action of requesting another agent to perform some action.

Actions in this sense include performing other speech acts. request is accompanied by an action specification.

agree(a) The action of agreeing to perform some action, possibly in the future. Can be interpreted as giving a commitment.agreeis accompanied by an action specification and optionally conditions of the agreement.

refuse(ref) The action of refusing to perform a given action.refuseis accom-panied by an action specification and optionally reasons for the refusal.

done(d) The action of telling another agent that an action has successfully been finished.doneis accompanied by an action specification and option-ally an action result description.

failure(f) The action of telling another agent that an action has been at-tempted but the attempt has failed. failureis accompanied by an action specification and optionally explanations for the failure.

cancel(c) The action of cancelling some previously requested and agreed action which has temporal extent, that is, it is not instantaneous.cancel is accompanied by an action specification and optionally reasons for the cancellation.

not understood(n) The action of agent i telling another agentj that i has perceived thatj has performed an action, but thatihas not understood whatj has done.not understoodis accompanied by an action specifica-tion.

In [75] a precise formalization of the feasibility preconditions as well as the rational effect of each speech act is given based on multi-modal logic. Though it may seem appealing to allow for a formal semantic model of each speech act, “the semantic issue is in practice much less important than it sounds, especially since the problem of defining and identifying conformance to the semantics is not resolved” and computationally intractable [165]. Hence, we will not go into detail regarding the formal model of speech acts. We will assume that agents implement the necessary behavior to handle the above

5.3 Agent Communication 99

mentioned speech acts correctly. In our opinion, it is much more important to formally model and verify the exchange of messages itself, namely the interaction protocols used. This will be tackled in Subsect. 5.3.3.

5.3.2 Messages and Conversations

The usual atom in agent communication is the exchange of a semantic in-formation package between two agents following a well-defined syntax. This atom is implemented usingmessages. Messages comprise structured informa-tion on the speech act, on the message identity and membership to a certain message sequence, on the used language and ontology, on sender, receiver and priority as well as on the actual content of the information exchange. Though there are many components of messages as presented in [72], we will focus on the most important ones needed to underpin our agent communication formalization.

Definition 5.3.1 (Message). A message m is a 4-tuple m = (sa,(s, r),(c, cp, cs), cont). sa ∈ {q, i, r, a, ref, d, f, c, n} is a speech act, s ∈ A is the sending agent, r ∈ A is the receiving agent, c is the con-versation the message belongs to, cp ∈ ^N is the conversation protocol the message belongs to,cs∈^Nis the sequence number of the message within the conversation andcontis the actual content of the message.

Remark 5.3.1. As abbreviation, messages are classified by their speech act.

For example, a message containing an inform speech act is called inform message.

Usually, agent communication is not only based upon exchanging a single message, but exchanging several messages in a sequence. This sequence is calledconversation.

Definition 5.3.2 (Conversation). Aconversationcis a goal-oriented and preferably finite sequence of messages.

c=h(sa₁,(a, b),(c, cp,1), cont₁),(sa₂,(b, a),(c, cp,2), cont₂), . . .i As given by the definition, we assume a conversation to be a sequence of messages that are exchanged between only two agentsaandb. Messages al-ways belong to a unique conversation even in the case only one message is sent to reach a certain goal. Messages in conversations are numbered accord-ing to their semantic order within the conversation. This order is not always equivalent to the order in which messages are delivered by the asynchronous message-passing system.

To correctly participate in a conversation, an agent has to keep track of the progress of the conversation, i.e. the message round it is in. To realize this, we have decided to implement conversations in mental categories called intentions. They define the state of the conversation from the viewpoint of the agent. Further details on intentions in general and their use for agent communication can be found in Chap. 7.

100 5. Multi-Agent System Infrastructure

To keep the participation in a conversation computable and such tractable for artificial agents, there is need for common patterns of behavior in con-versations that occur frequently.Interaction protocols are sets of such well-defined conversation patterns. In the broader sense, interaction protocols are the algorithms of distributed systems. While conversations are always defined between two agents, interaction protocols may comprise conversations involv-ing more than two agents. Due to this, the message exchange in interaction protocols does not necessarily follow a sequential order. Several conversations of an interaction protocol may run concurrently or even in parallel.

The inherent concurrency of interaction protocols makes modeling and verifying them a very difficult tasks. Nevertheless, we have demanded in Sect. 5.1 that we have to be able to verify the behavior of agent commu-nication in general and interaction protocols in particular to guarantee the desired multi-agent system behavior. Therefore, we are in need of an ap-propriate model of concurrent computation. A good modeling paradigm for concurrent protocols offers a representation of the concurrent flow of control, a natural way to specify asynchronous behavior and mutual exclusion, a con-cise notion of fairness and the ability to use different layers of abstraction to compose model parts. Perhaps the most important property of such a mod-eling paradigm is the notion of local state. The global state of the system should always be derivable solely from the set of local states of its different components. Petri nets satisfy these demands. Additionally, they use a quite suggestive and nevertheless formally sound graphical notation. Since all our definitions rely on an algebraic description of components, the special class ofalgebraic Petri netsseems to be most suitable.

In Petri nets local states are represented by places(denoted by ellipses) andtokenson these places (drawn bold within ellipses). Atomic processes are represented bytransitions (drawn as rectangles). Arcs connect places with transitions and model control and data flow. In algebraic Petri nets places, tokens and arcs are typed according to algebraic abstract data types. Take a look at the transitionqueryin Fig. 5.1 to get an example for this.queryis connected to the placesPending Information,Queried Informationand

5.3 Agent Communication 101

Fig. 5.2.Petri net modelNiof the inform protocol

Query Messages. The process represented byquerycan happen (fire), iff the inscription of the incoming arcinfo?can be unified with a token onPending Information In this case, query takes away the concrete instance info?

fromPending Informationand placesinfo?onQueried Informationand a query message(q, (i, j), ·, info?)onQuery Messages. All transitions in the net behave according to this rule totally independently and concurrently.

In this context, a transition t in conflict to other transitions for the same token is treatedfair by a system run (denoted byϕ), ifft does not fire only finitely often, though being activated infinitely often. Of course, we cannot give a further detailed introduction to algebraic Petri nets. Please refer to [213] for details. We will rather present concrete agent interaction protocols that we are using, show their Petri nets models and describe their behavior verbally.

Inform Protocol. The inform protocol is the simplest protocol used in our multi-agent system infrastructure. It enables an agent i to arbitrarily send a piece of information to an agent j without waiting for any reply. Before using the inform protocol, agenti should belief that agentj does not have the information to be transferred and that the information is of use for agent j. Figure 5.2 shows the Petri net model of this protocol. The left half of the figure models the behavior of the sending agent in the course of the protocol, the right half models the behavior of the receiving agent. In the middle the asynchronous message passing system is denoted. Message tuples are denoted as given by Def. 5.3.1 leaving out the information about the conversation. The message system is assumed to be reliable, though not necessarily preserving sequence.

Agenti initiates the protocol by taking a piece of informationinfofrom Pending Information, wrapping it into an inform message(i, (i, j),·, info) and sending it via the transitioninform. A not specified moment later, the

102 5. Multi-Agent System Infrastructure

Fig. 5.3.Petri net modelNqof the query protocol

receiving agentjcan consume the inform message and store it in its informa-tion base represented byInformationvia the transitionreceive inform.

Query Protocol. The query protocol allows an agenti with an informa-tional shortcoming to contact another agentj for provision of this informa-tion. Before using the query protocol, agenti should belief that agentj has the information wanted. Figure 5.3 shows the Petri net model of this pro-tocol. Agent i initiates the protocol by taking a specification info? of the demanded information fromPending Information, storing this information specification onQueried Informationto keep it from being queried again and sending the information specification in a query message to agentj. All this is modeled by the transition query. The queried information remains queried as long as no matching information has come from agent j. After receiving the query message viareceive query, agentj can look up the in-formation, wrap it in an inform message and send the information to agenti (inform). To participate correctly in the protocol, agentjmust also transmit the information that the demanded information is not available. Otherwise, agenti would wait forever. After receiving an information that matches the information specification, agent i can update its information database ac-cordingly (receive inform).

Immediate Action Request Protocol. The immediate action request protocol allows an agent i to request an agent j to immediately perform

5.3 Agent Communication 103

Fig. 5.4.Petri net modelNiarof the immediate action request protocol

an action a. This protocol is usually used for simple atomic actions that can be performed without further thought. Before using the immediate ac-tion request protocol, agent i should belief that agent j is able to perform actiona. Figure 5.4 shows the Petri net model of this protocol. Agenti ini-tiates the protocol by deciding to request a pending action a or to cancel it. The latter is discussed later. Modeled by the transition request, agent i wraps a in a request message, sends it to agent j and marks the action as requested (Requested Actions). After receiving a request message via receive request, agentj tries to perform actiona. It either succeeds to do so or it fails. In case of success, agentj sends a done message to agenti, in case of failurejsends a failure message toi. This non-deterministic behavior is modeled by the conflicting transitionsdoneandfailure.

Agent i can only update the actiona to the state of being done (Done Actions) iff agentjhas sent a done message. If agentihas received a failure message it tries to modifya(possibly following the explanation in the failure message) and allows for a new protocol round by placing a⁰ on Pending Actions. To avoid infinite runs of the protocol further assumptions have to be made about the conflicting transitionsrequestandcancel. They should

104 5. Multi-Agent System Infrastructure

Fig. 5.5.Petri net modelNcarof the commitment-based action request protocol have mutual exclusive preconditions for being enabled. A typical example for a precondition ofrequestcould be thatahas not yet been requested for more than a sufficiently high number of times. This information could be stored in aand can be updated according to the conversation sequence number of the exchanged messages. As soon as this upper bound on the number of requests has been reached, onlycancelcould be enabled.

Commitment-based Action Request Protocol. The commitment-based action request protocol is among the most complex two-party inter-action protocol used in AuReCon. The protocol allows an agentito convince another agentjfirst to undertake a commitment for an actionaand to try to