Environmental Engineering Reference
In-Depth Information
to which agents. As well as sending data to other agents, GIFA also sent
all engineering data to the archive agent (AIFA) for storage, and sent trend
information to the visualization agent (VIFA). Updated schedule information
was sent to the scheduling agent (MIFA) and a report was sent to the user
interface agent (UIFA) to send on to an analyst for monitoring purposes. If
there were any anomalies, they were sent to the FIRE agent for resolution.
If there was an anomaly, the FIRE agent would try to fix it automatically
by using a knowledge base containing possible anomalies and a set of possible
resolutions for each anomaly. To fix an anomaly, FIRE would send a spacecraft
command to GIFA to be forwarded on to the spacecraft. After exhausting its
knowledge base, if FIRE was not able to fix the anomaly, it would forward
the anomaly to the user interface agent, which then would page an analyst
and display the anomaly on the analyst's computer for action. The analyst
would then formulate a set of commands to send to the spacecraft to resolve
the situation. The commands would then be sent to the FIRE agent so that it
could add the new resolution to its knowledge base for future reference. The
commands then would be sent to the GIFA agent, which in turn sent them to
the GenSAA/Genie system for forwarding on to the spacecraft.
There were many other interactions between the agents and the legacy
software that were not covered above. Examples include the DBIFA request-
ing user logon information from the database, the AIFA requesting archived
telemetry information from the archive database to be sent to the visualiza-
tion agent, and the pager agent sending paging information to the paging
system to alert an analyst of an anomaly needing his or her attention.
4.3 Agent Concept Testbed
The motivation behind ACT was to develop a more flexible architecture than
LOGOS for implementation of a wide range of intelligent or reactive agents.
After developing the architecture, sample agents were built to simulate ground
control of a satellite constellation mission as a proof of concept. The following
discusses the ACT agent architecture and gives an operational scenario using
the satellite constellation proof of concept.
4.3.1 Overview of the ACT Agent Architecture
The ACT architecture was a component-based architecture that allowed
greater flexibility to the agent designer. A simple agent could be designed
by using a minimum number of components that would receive percepts (in-
puts) from the environment and react relative to those percepts. This type of
simple agent would be a
reactive agent
.
A robust agent could be designed using more complex components that
allowed the agent to reason in a deliberative, reflexive, and/or social fashion.
