Ground Autonomy Evolution - Autonomous and Autonomic Systems - page 73

since no time is spent on a separate processing step. There is also the bene-
fit of simplicity. It is not much harder to build a semantic grammar than a
syntactical one. All requests either in the form of a natural language or struc-
tured queries were submitted to AFLOAT through one of the two interfaces
labeled 1 in Fig. 4.3 . All requests were automatically converted to an ACL to
enable inter-agent communication and collaboration.
4.1.4 Inter-Agent Communications in AFLOAT
Inter-agent communication in AFLOAT was based on the following assump-
tions:
1. Agents in AFLOAT communicated through an asynchronous message pass-
ing mechanism (i.e., asynchronous input and output messages)
2. A common message structure was maintained for all agents
3. Communication between agents was achieved through TCP/IP-based
sockets
The format of the ACL employed in AFLOAT was an enhanced version
of that proposed by Steve Laufmann [ 103 ] for “coarse-grained” agents, to
which we have added “performatives” proposed by Finin and group for the
Knowledge Query Manipulation Language (KQML) [ 24 , 81 ], and enhanced
to meet specific requirements of the domain of spacecraft mission operations.
The format for an ACL message in AFLOAT was as follows:
msg-id: A unique identifier composed of hostname, a random number, and
system time separated by dashes (e.g., kong-gen854-13412.35).
user-id: The user-id of the person who originally submitted the request.
sender: The name of the agent that the message is coming from.
receiver: The name of the agent that the message is going to (in general).
Asterisk (*) is used when we want the agent that is receiving the message
to decide to whom the message should finally go.
respond-to: The name of the agent to which the response to this request
should go. It does not apply to response messages.
reply-constraint: This is used for time constraints (e.g., ASAP, soon, when-
ever)
language: The programming language that the message expects. This is es-
pecially important when the performative is “evaluate” and the string
passed in the input-string slot is just evaluated. This would only apply to
interpreted languages (e.g., CLIPS, shell scripts, etc.).
msg-type: The message type (request, response, status, etc.).
performative: The basic task to be performed (e.g., parse, archive, generate).
recipient: The name of the user interface agent of the person to receive the
results of the request.
result-action: The type of action to invoke on the result message (display,
print, etc.).