Concrete examples of “Intelligent Agents” solving problems in real-world, military-relevant domains are not widespread. The promise of Intelligent Agents – autonomous, inter-communicating programs capable of performing complex tasks – has given rise to a number of agent architectures. These architectures, however, are merely the infrastructure for implementing agents – neither intelligence nor autonomy is guaranteed. To move towards the goal of truly intelligent agents, we need to integrate these agent architectures with powerful, well-understood Intelligent Systems technology. For example, in a recent project the following Intelligent Systems were implemented in our software:
Furthermore, the capability of these intelligent agents must then be demonstrated in a useful problem domain.
ArtisTech has demonstrated how a hierarchical architecture of highly-specialized agents, utilizing different types of intelligent system software can be used to:
We demonstrated agents in more pro-active roles as well. We have used agents in a network resource maintenance role, creating a distributed Tactical Operating System (TOS) that is more robust and more fault-tolerant in the unreliable network environment of the battlefield. We joined this distributed system with a client agent that is capable of diagnosing and repairing failures in the client’s connection to the TOS. By utilizing both of these agents, we create an environment in which the user can utilize the TOS normally, even during a failure condition. The underlying agent architecture can maintain the user’s access to a network resource, and only alert the user in the case of fatal errors.
ArtisTech Agent Examples
Listeners: A Listener agent is responsible for monitoring a source of data for new information. When new information is available, it is packaged into a Message and tagged with a unique string that represents the type of data contained within, as well as the name and location (that is, network host) of the Listener agent.
In a tactical system that ArtisTech developed, there were several Listeners. The most important is an “alert” agent. This agent is responsible for monitoring a stream of sensor data, and looking for hostile or unknown entities that are within a specified distance of a friendly unit. When such a unit is detected, the position of the entity is packaged and sent to all agents that are listening for messages from the alert listener.
Another Listener is responsible for monitoring the audio feed from the Fire Teams’ microphones. This audio is captured by the Speech Server and parsed using an Augmented Transition Network (ATN) parser. The parsed speech is captured by the audio listener agent, which transmits the information to the rest of the system. Another agent – the Position listener – performs a similar function with GPS positional data. In this case, the position listener monitors the position of a single unit in TOS, and broadcasts changes to other agents in the system.
Analyzers: Analyzers are agents that collect data from Listeners and analyze that data to discover events or patterns of interest to the user. A single analyzer may require data inputs from a number of listeners, or may record a log of all data received for temporal analysis. When an analyzer discovers data of interest, it packages this data into a message (including the messages from the listener containing the data), and broadcasts that message to all interested agents.
In the tactical example, the most prominent analyzer is the Speech analyzer. For every audio listener, there is a speech analyzer that is responsible for determining whether a given string of spoken text is a unit identification. This analysis is performed using a Bayesian Belief network that considers the arrangement of words within a spoken sentence, the words themselves, and the amount of “noise” words (words we are not interested in) contained within the sentence. If the probability output by the network exceeds a specified threshold, a message is sent to all interested agents indicating that a unit identification has occurred.
A different kind of analyzer, referred to as a Correlator, is responsible for detecting patterns in messages from other agents. In the tactical system, we use two Correlators. The first is an agent responsible for capturing all “alert” events, and matching them with “identification” events, producing a single “encounter” event in which a soldier has been alerted to the presence of an unknown unit, and then identified that unit. This agent utilizes JESS, using a set of rules about the temporal and geographic coincidence of events. A second correlator is responsible for removing redundant events from this system – for example, a second, redundant unit identification event for the same Unknown entity.
Planners: Planners are agents that aid in a user’s decision-making process by generating and analyzing possible responses to an event. This process often includes interaction with a human user. In the tactical system, the Planning process is actually spread across several agents. The first is the Planner, an agent that captures an “encounter” event, queries the positions of all available friendly units, and generates a set of possible responses to the encounter. A separate agent, the Handler, performs some automatic scoring on these plans, and presents the list of plans to the Commander.
Monitors: Once a response plan is selected by the Commander, the execution of that plan is delegated to a Monitor agent. Monitor agents collect data from the Listeners attached to all units involved in the execution of the plan. This sensor input drives the monitor’s internal Finite State Machine, allowing the agent to track the execution of the plan until an end state – task completion, task interruption, or re-planning – occurs. Once a completion state has been reached, a message indicating that the entire chain of events (from sensor input to completed plan) has been resolved is broadcast to other agents in the system.