Environmental Engineering Reference
In-Depth Information
(domain, "EUVE spacecraft")
(object-type, nil)
(object-name, nil)
(object-specifiers, nil)
(parameters, nil)
(action-start, nil)
(action-duration, nil)
(function, nil)
(input-string, "monitor the health and safety of the
spacecraft's batteries")
Start-Up and Activation of a Community of Domain Specialist
Agents in AFLOAT
To initiate the prototype, a UNIX process loaded the System Services Agent
depicted in boxes 2-11 and established a persistent socket connection with
each of them. The links were persistent to enable the SSA to monitor the
status of the nine agents. In addition to monitoring the status of the agents,
the SSA stored the location and skills base of other agents and provided ap-
propriate resources to support the agents' migration requirements. To support
fault tolerance, the ISA had the capability to monitor the status of the SSA,
and to restart it if it died. Communications from clients (i.e., external in-
terfaces - either user interfaces or remote clients) needed to be registered at
the ISA. This was necessary to relieve the processing load of the SSA. The
agents numbered 2 and higher constituted the AFLOAT server. All the agents
communicated when necessary via TCP/IP sockets. At run time, the User In-
terface Agent (UIA) was loaded. Users submitted requests to AFLOAT from
a remote web client and received responses/results locally.
4.2 Lights Out Ground Operations System
LOGOS [
175
,
177
,
181
,
183
] was a proof-of-concept system that used a com-
munity of autonomous software agents that worked cooperatively to perform
the functions previously undertaken by human operators who were using tra-
ditional software tools, such as orbit generators and command-sequence plan-
ners. The following discusses the LOGOS architecture and gives an example
scenario to show the data flow and flow of control.
4.2.1 The LOGOS Architecture
made up of ten agents, some of which interfaced with legacy software, some
