INCOMPLETE INFORMATION EXCHANGE IN A SIMULATION ENVIRONMENT: A COMMUNICATION LAYER APPROACH Paulo T. Silva1, Porfírio Filipe2, Helder Coelho3 1, 2
Instituto Superior de Engenharia de Lisboa, Departamento da Engenharia da Electrónica e Telecom. e de Computadores, R. Conselheiro Emídio Navarro, 1, 1949-014 Lisboa, Portugal 3 Faculdade de Ciências da Universidade de Lisboa, Departamento de Informática, Bloco C5, Piso 1, Campo Grande, 1749-016 Lisboa, Portugal 1
[email protected], 2
[email protected], 3
[email protected]
Abstract. The paper presents a communication layer, fitted to simulate incomplete information exchange among software agents inhabiting a simulation environment. The communication layer is designed to ensure simulation repeatability at the message exchange level. Message exchange impact on repeatability is found to have some addressable open issues within RoboCup-Rescue simulation environment’s present stage. The RoboCup-Rescue simulation environment architectural model is considered. This model considers multiple heterogeneous software agents and several domain specific aspect simulators. In this model, a set of communicative acts sustains all inter-agent information exchange as well as agent-world acting and sensing capabilities. RoboCup-Rescue communicative acts are classified from the simulation repeatability perspective. It is assumed that agent’s information exchange model, follows a connectionless simple request-reply communication pattern. A reliable UDP-based protocol, less resource demanding than TCP, is proposed. Incomplete information exchange is regarded as a nonfunctional facet. Knowledge of the environment communicative acts is introduced at the communication layer, so that application level independency is achieved on that nonfunctional facet. The paper describes the experiments and presents the results that validate the proposal of an UDP-based reliable protocol. The RoboCup-Rescue simulation environment is used to materialize and analyze the proposed classification of communicative acts.
1
Introduction
Real world incomplete information exchange phenomena happen in the context of environment perception and human communication, within natural or technological disaster scenarios. As incomplete information exchange phenomena may influence human behavior, it is an important issue to take into account for the construction of simulation environments exhibiting real world characteristics, such as the RoboCup-Rescue.
The RoboCup-Rescue is a simulation environment that combines human behaviors and various disaster domain specific issues such as: earthquakes, fires, logistics or traffic jams, and presents them as a coherent scene [1]. RoboCup-Rescue has been undertaken to put large-scale simulations in use in the domain of search and rescue for large-scale disasters [2]. Within RoboCup-Rescue interest group [3], some attention roused up around simulation repeatability issue, after the first RoboCup-Rescue Simulation League championship (at Fifth International RoboCup event [4]). At RoboCup-Rescue present stage, attention focuses mainly on simulation repeatability of disaster domain aspects. Open issues are found when looking from the communicative acts and reliability perspective. In this paper a communicative acts analysis, driven from agents and simulator reliability perspective, is proposed. The RoboCup-Rescue simple connectionless UDP protocol exhibits reliability limitations. A construction of communication layers over simple UDP protocol is also proposed. Different software agent types (species) inhabit RoboCup-Rescue simulation environment: civilian, fire fighter, ambulance, police, and city offices. Such agents act autonomously and decide their actions to save victims according to disaster situations. Each agent may also hold up a self-preserving concern, as each one of them is also a potential victim. Agent autonomy suggests a loosely coupled interaction model among different agents from the same specie, and therefore among different species. Inter-agent communication support is also founded on this loose coupling principle. The typical communication scenario does not presuppose a peers, prior to conversation, virtual connection establishment. Dialogue happens “if possible” and with eventual interference from the surrounding environment. Agents act upon the simulated world and sense the world’s state by means of message exchange. Action and perception messages add reliability requirements at the communication support level: such messages may not be lost, they must arrive in order and unintentional duplicate messages must be avoided. This paper proposes the design of communication layers responsible to vouch for the coexistence of both a loosely coupled and reliable communication model. Usage of such layers ensures simulation repeatability at the message exchange level. Holding the same communication characteristics over different simulations allows focusing on agent’s specific aspects while varying information exchange completeness. This paper defines briefly the software agent concept and outlines its communication pattern. Then it describes RoboCup-Rescue domain characteristics and its simulation environment architectural model. Next, a classification of the RoboCup-Rescue communicative acts is proposed. Assuming RoboCup-Rescue model, the next section identifies the technical problems to be tackled by a communication layer and describes the proposed solutions. From there it proceeds to describe the experiments conceived to validate the proposals. Finally, immediate conclusions, and points to be discussed in the future, are presented.
2
Software Agents Architectural Baseline
The term software agent is used to refer any software process with the ability to sense its surrounding environment and decide its own actions according to situations [5]. Within each specific environment, a set of communicative acts representing perceptions and action commands are defined. In this paper the software architecture concept focuses both on the significant structural elements of the system, such as subsystems, classes, and nodes, as well as the collaborations that occur among these elements, as defined in [6]. Such collaborations are established via communicative acts. In a process-oriented perspective, communicative acts are exchanged between a client process (agent) and a process representing the agent’s surrounding environment – this process will be designated as a kernel. The kernel operates as a server process managing a large number of client processes (software agents) and their communicative acts. On the other hand, each agent also operates as a “serving” process, meaning that its actions are highly bound to a continuous perception of the environment (kernel) communicative acts. The Fig. 1 represents communication between software agents and the kernel – to simplify the diagram, similar processes are presented as members of a set, meaning that for communication purposes, each member has the same communication demands of the set to which it belongs. Agent set
action
Ag1 Ag2
Kernel Ag3 … perception
Fig. 1. Message exchange – the agent gets perceptions and applies actions.
The Fig. 1 depicts an architectural baseline where all the communication must always go throw the kernel. So, agents do not use a point-to-point communication pattern when talking to each other. Inter-agent communication is regarded as acting and perceiving the surrounding environment. The architectural baseline also suggests an intuitive classification of each communicative act: it belongs either to an action or to a perception. In a processoriented perspective each communicative act is materialized as, one or more, messages at the adopted communication protocol level. In this paper we consider that processes belonging to the agent set follow a simple request-reply communication pattern. An additional consideration is that short message (under 64kbyte) flow is the typical communication scenario, although large messages may sporadically occur. Attaining minimal communication temporal costs is an important design issue, as communication must happen as soon as possible. Minimization of permanent resource
allocation is an additional requirement, as environment may involve a large number of communicating parts, drawing near real world complexity. The guidelines described above are materialized within RoboCup-Rescue platform [7], which is a simulation environment involving a very large number of heterogeneous agents in a hostile context. Disaster rescue is one of the most serious social issues, but while the rescue domain is intuitively appealing as a large-scale multi-agent domain, it has not yet given through analysis on its domain characteristics.
3
RoboCup-Rescue Domain Characteristics
RoboCup-Rescue simulator was designed based on Kobe-Awaji, 1995 Japan’s earthquake, where over 6000 citizens were killed, 300000 injured and led to property damage exceeding 300 billion dollars. The Kobe case is properly documented in [1]. Soon after the large earthquake, buildings collapsed, many civilians were buried in the collapsed buildings, fires propagated, and it became difficult for agents to move because roads were blocked by debris. In the aftermath of Kobe’s earthquake, information about the disaster was not communicated immediately due to damage of the information infrastructure. Roads and open areas, which had been designed as fire breaks, actually became combustion pathways allowing collapsed wooden structures to be exposed to air. Efforts to fight the rapidly spreading fires were hindered by disrupted water supplies. Rescue teams could not reach the affected areas due to fire, damaged roadways and the flow of refugees. Accurate information as to where rescue teams were was also lacking. Aerial surveillance by helicopter finally provided that information but at the cost of drowning out the faint sounds of victims trapped in collapsed buildings. In the immediate term, RoboCup-Rescue initiative will provide a general software-based simulator platform for simulating a wide range of disasters, including earthquakes, tsunamis, fires, etc [2]. The Table 1 illustrates RoboCup-Rescue domain characteristics. Table 1. RoboCup-Rescue domain characteristics.
Number of agents Agents in team Logistics Information access Representation Control Filed structure Motion
100 or more Heterogeneous, Hierarchical Major issue Very bad Symbolic & Non-Symbolic Distributed / Semi-Central Dynamic (GIS - Geographic Information System) Move along roads
In rescue domain, there are heterogeneous agents acting autonomously: civilian, fire fighter, ambulance, police, and city offices. Some of them have hierarchical structure in themselves; for example, fire fighters are composed of fire brigades and a fire office; fire office agents can order fire brigade agents [8].
3.1 RoboCup-Rescue Simulation Environment The RoboCup-Rescue simulator is designed to combine human behaviors and various disaster simulations, and to present them as coherent and comprehensive scene. The RoboCup-Rescue architectural model exhibits four main blocks: multiple heterogeneous software agents; several domain specific aspect (DSA) simulators; a kernel operating as a hub between agents and DSAs; and a set of communicative acts. The set of communicative acts sustains all inter-agent information exchange as well as agent-world acting and sensing capabilities. The RoboCup-Rescue simulator considers several DSA simulators. Each DSA plugged into the simulator, computes what will happen in the world, including what the agents in the world will do and what the effects of their actions will be. Integration of DSA and agent behavior is achieved through a kernel working as a hub. Kernel controls the simulation evolution and facilitates information exchange among processes. Agents deployed in this simulated environment should be able to percept each scene and apply actions on it. The Fig. 2 depicts the RoboCup-Rescue architecture. 3 2
gathered actions
action
Domain Specific Aspect set
Agent set
DSA1
Ag1 Ag2
DSA2
Kernel Ag3 …
…
perception 1
simulation results 4
Fig. 2. The simulator architecture (Ag ≡ Agent; DSA ≡ Domain Specific Aspect).
The kernel manages the simulation system as follows: 1. the kernel sends individual sensory information to all agents in the simulation world; 2. each agent submits its action command to the kernel; 3. the kernel sends agent’s action commands to all DSA simulators; 4. each DSA simulator update states of the disaster space to the kernel; and; 5. the kernel advances the simulation clock in the disaster space. It is interesting to note that the simulator includes graphical interface viewers to enable simulation visualization. In the above loop, after step 4 and before step 5, the
kernel sends update states to the viewers so that they may render each world situation visual projection. The simulation system repeats this loop 300 times. Typically it takes a few seconds to simulate one turn. All the agents must decide an action for a few seconds.
4
Classification of Communicative Acts
Agent actions are transmitted to the kernel to renew the world’s conditions. Visual and auditory information, as well as agent-agent communication, are also exchanged via the kernel. The Table 2 presents the set of communicative acts, as defined in the RoboCup-Rescue domain [9]. Table 2. RoboCup-Rescue communicative acts.
Communicative act Initialization init Sensory Information see hear listen Action Commands move act say tell
Information transfer
Function
agent → kernel
Initialization of agents
agent ← kernel agent ← kernel (agent) agent ← kernel (agent)
Visual information acquisition Said or told by individual Told via transmission line
agent → kernel agent → kernel
Motion of agent body General action term – implemented ones are: extinguish, rescue, load, unload, clear Transmission to an individual Broadcast by radio or other transmission line
agent → kernel (agent) agent → kernel (agent)
The Table 2 presents an intuitive functional classification of communicative acts, where three sets are devised: initializing, sensing and acting. This classification is a functional one; given the question “what does an agent do?” one finds the following answer: “it has to introduce himself to the world, and afterwards sense and act”. The approach presented in this paper considers that the reliability criteria impose a different classification of communicative acts. We begin trying to answer the following questions: “which communicative acts may be lost?” and “what does it mean to loose a communicative act?”. Let us illustrate these questions with some simple scenarios: “a fire brigade sends an action command in order to move to a burning location to the world (kernel); but it is not received”, and in another typical scenario, “the world notifies an agent that its location is on fire”. Both previous scenarios are sketches where loss of any communicative act, conduces to a non-desirable inconsistence between the world’s reality and the agent’s representation of that reality. The RoboCup-Rescue communicative acts that lead to
this anomaly are the ones that transmit world acts: move, act and see. The transmission of such communicative acts should be reliable. Considering another kind of scenario where “an agent yells for help” one admits that distance, physical barriers or environment noise, interferes on message propagation. As such, some agents do not listen any thing at all, while others listen to some form of corrupted message. The RoboCup-Rescue communicative acts, admitted to be totally or partially lost are: say, tell, hear and listen. Transmission of such communicative acts is non-reliable. In short, the classification of RoboCup-Rescue communicative acts (CA), according to the reliability criteria, suggests the following two sets: • Reliable CA = {move, act, see, init}; world facts communication, and initialization; • Non-reliable CA = {say, tell, hear, listen}; inter-agent communication. The non-reliable CA set represents the incomplete information exchange concept. In order to attain the repeatability requirement, exchange of non-reliable CAs must occur in a controlled mode. This way a specific CA interference pattern is reproducible. Repeatability at the CA level also allows for agents to be tuned according to any interference pattern.
5
Communication Layer
The classification of CAs, driven by the reliability nonfunctional criteria, brings up the next question: “where to assign the design responsibility of reliable and non-reliable CA sets?” This paper proposes the design of communication layers that directly support the reliability criteria concerning CA sets. Given the existence of two different sets, the knowledge of domain communicative acts is added to the communication layers. The primitives at the communication layer have some minimal domain knowledge in order to distinguish whether a particular communicative act is either a reliable or non-reliable CA. In this context, controlled exchange of non-reliable CAs is materialized as controlled message corruption exchange. Message corruption includes total message loss, partial message loss or message mutation. The first stage in the design of controlled message corruption facet is to guarantee message delivery. The second stage is to augment the communication layer domain knowledge, regarding the non-reliable CAs. This knowledge grants the necessary competence for the communication layer to grasp and corrupt a non-reliable CA. The Fig. 3 illustrates the proposed communication layers and its parallel within TCP/IP family model.
Agents
Kernel
DSA
Incomplete Information Exchange (CA Knowledge)
Process
Reliable Long UDP Reliable UDP
Transport
UDP - User Datagram Protocol IP - Internet Protocol
Internet
Ethernet, Token Ring, FDDI, Satellite, Radio, ...
Network Access
Fig. 3. Proposed communication layer versus TCP/IP family model.
Information exchange between kernel and any other process is implemented as a collection of UDP (User Datagram Protocol) messages [10]. According to [11], a connectionless communication protocol, such as UDP, can be used when communication follows a simple request-reply pattern. However connectionless communication protocol typically does not guarantee message delivery, so it may severely affect simulation execution repeatability requirement – connectionless inherent message loss happens in a non-controlled fashion. A reliable protocol was designed to prevent messages from being lost, ensure message sequencing and discard message duplicates, attending minimization of resource demands requirement. The existence of sporadic large messages (greater than 64kbyte) was considered and a Reliable Long UDP message format devised. Large message format is achieved through a segmentation procedure. The adopted Long UDP format is properly defined described in [9]. The implementation of controlled message corruption is achieved through an intrusion at one of the two non-reliable CA sub-sets: either at the sender sub-set {say, tell}, or at the receiver sub-set {hear, listen}. The higher communication layer incorporates the domain knowledge as to distinguish the messages upon which the intrusion is to be applied. The interface between the application and the protocol levels is materialized with the send and receive primitives. The Fig. 4 and Fig. 5 show UML [12] activity diagrams, that respectively exhibit send and receive behavior at the Reliable UDP level. Primitives send and receive are designed to ensure message delivery, duplicates discarding and proper order reception. Both these primitives follow a blocking semantic implementation. These primitives are implemented using the acknowledgement reception and timeout retransmission technique. This implementation does not claim to be a new protocol. Its purpose is to materialize the proposal of a reliable protocol over UDP. This reliable protocol, is less resource demanding than TCP, but still imposes the additional cost of an acknowledgement reception message. The Fig. 8 (at section 6) shows a time cost comparison among the raw UDP protocol; a reliable protocol such as the one described here (one that implements the acknowledgement reception and timeout retransmission technique); and a technique that merely decreases message loss proportion.
Initiate entry(msg)/msgToPost = build( msg, ^id.get() ) exit/initiateTrials()
msgToPost msgReceived
Trying Message Posting Post Message entry/^UDP.send( msgToPost ) [NOT exhaustedTrials()] exit/updateTrials()
Get Received ID after(TIMEOUT)
Get Received Type
Waiting for Ack
[exhaustedTrials()]/INSUCCESS
UDP Receive entry/^UDP.receive()
[else]
[receivedID == ^id.get()]
[else] Deal with NEG_ACK entry/^id.initiate() [receivedType == NEG_ACK]
/SUCCESS
[receivedType == ACK] Deal with ACK entry/^id.setNext()
Fig. 4. Reliable UDP, send primitive activity diagram.
The Fig. 4 remarks the existence of two send states: one that posts a message and another that waits for its reception acknowledgement. A typical send scenario proceed as follows: • a message is built containing a sequence identifier (“Initiate” state) msgToPost = build(msg,^id.get()) • the message is posted to the UDP layer (“Post Message” state) ^UDP.send(msgToPost) • wait for the acknowledgement of the sent message (“Waiting for Ack” state) ^UDP.receive() • test the identifier of the received message (“Get Received ID” activity) • test the type of the received message (“Get Received Type” activity) • when both identifier and type match the expected ones, advance message identifier ^id.setNext() It is important to note that each message is insistently (a configurable number of trials) posted to the UDP layer until a proper acknowledgement, referring that same identifier, is received. An additional care was taken to reinitiate the sequence message identifier upon reception of a negative acknowledge. A negative acknowledge indicates that, in the
past a sender successfully sent messages to a receiver but at the present moment, the receiver forgot the sender. A negative acknowledge scenario occurs when a long period of time separates consecutive messages and the receiver decides to purge information regarding old senders. Upon a negative acknowledge reception, the sender reinitiates its sequence message identifier and retransmits the same message with the new identifier. The Fig. 5 shows that receive primitive catalogues its communicating peers and uses that information to decide whether to ignore or acknowledge each received message. An out of order message is always discarded and an acknowledge indication sent to its peer. The catalogue consists on a set, where each element contains: peer identification (IP address, port) and protocol data (expected message identifier, timestamp of last properly received message). Get Received ID Waiting for Message UDP Receive entry/^UDP.receive()
msgReceived Get Catalogue ID
NEG_ACK UDP Send entry/build( NEG_ACK, receivedId ) [else] ACK UDP Send entry/build( ACK, receivedID )
[else] [receivedID > catalogueID AND ^catalogue.isNew(receivedID)] [receivedID
