Architectures for Distributed Information Fusion To Support Situation Awareness on the Digital Battlefield

Transcription

1 Architectures for Distributed Information To Support Situation Awareness on the Digital Battlefield Stephen M. Jameson Artificial Intelligence Laboratory Lockheed Martin Advanced Technology Laboratories Camden, NJ, USA Abstract Future military battlefield systems, exemplified by the US Army s Future Combat System initiative, are characterized by the extensive use of mobile sensing systems, unmanned platforms, and decision aiding systems at the lowest levels of the combat force. The effective deployment, control, and exploitation of these capabilities will require the ability to form real-time situational awareness for each warfighter using all information available. In this paper we describe previous work we have done in information fusion, and discuss the unique problems associated with supporting battlefield situational awareness. We present some candidate architectures we have evaluated for performing distributed information fusion, and discuss the approach that we are now pursuing to this problem. Distributed Information which we submit is ideally suited to support Situation Awareness in the challenging constraints of the rapidly emerging Digital Battlefield. 2 The Battlefield Situation Awareness Problem Keywords: Situation Awareness, Information, Distributed Information, Intelligent Agents. 1 Introduction Future military battlefield systems, exemplified by the US Army s Future Combat System initiative, are characterized by the extensive use of mobile sensing systems, unmanned platforms, and decision aiding systems at the lowest levels of the combat force. The effective deployment, control, and exploitation of these capabilities will require the ability to form real-time situational awareness for each warfighter using all information available. This will require cooperative distributed fusion of the information generated at each node. The Artificial Intelligence laboratory at Lockheed Martin Advanced Technology Laboratories (ATL) has been pursuing work in Information and Situation Awareness for over 10 years, including the highly successful Rotorcraft Pilot s Associate (RPA) program. Recent work in Mobile Intelligent Agents has given us an additional powerful technology for information dissemination, retrieval, and monitoring on the digital battlefield. Over the past two years, on contract and IR&D funding, we have pursued a merger of the two technologies to produce an architecture for Figure 1 - Notional Future Battlefield System Figure 1 illustrates an example of the Battlefield Situation Awareness problem. A future battle force, such as is envisioned by the US Army s Future Combat System (FCS) initiative, includes a set of participants, including manned helicopters, manned combat vehicles, unmanned Air Vehicles (UAV s), unmanned ground vehicles (UGV s) and several dismounted combat units, all communicating over a tactical radio network. Each participant has one or more sensors. In order for each element of this force to operate effectively, that element must have Situation Awareness, an understanding of the battlespace around them, including friendly and hostile forces as well as environmental factors. For effective coordinated action, this Situation Awareness must be a shared among all participants, a concept commonly referred to as the Common Tactical (CTP).

2 2.1 Challenges This scenario presents a set of powerful challenges to achieving a CTP among all participants. Challenges include communication issues, processing issues, and sensor/data flow issues. Communications Issues: All wireless communication networks face tight bandwidth constraints. Battlefield communication networks couple the normal problems of low power and small equipment and antennas with the military demands for Low Probabilty of Intercept (LPI), which further diminish the available bandwidth, and the constant threat of jamming by hostile forces. Due to terrain and other factors, battlefield wireless communications are frequently unreliable no surprise to cell phone users. These problems also affect the Global Positioning System (GPS), which more and more battlefield systems are coming to rely on heavily to support knowledge of friendly forces positions. GPS susceptibility to both terrain blockage (especially in urban environments) and to jamming is an increasingly serious problem affecting the developers of such systems. Processing Issues: Modern battlefield electronic systems face numerous competing demands for processing power, including communications, operator interface, control of robotic and unmanned systems, and decision aiding systems, which include data fusion and situation awareness functions. The processing needs of advanced software overcome the increase in performance of low-power processors, required for mobile systems. As decision aiding, and the attendant situation awareness and data fusion functions are incorporated in more and more systems, the need to minimize the processing impact of these systems becomes intense. Sensor and Issues: Large-scale multi-sensor data fusion systems work best and provide maximum benefit when three conditions hold. First, the sensors must be relatively homogeneous the data provided must be of similar character. Second, there must be a reasonable degree of overlap between sensors, so that data from multiple sensors can be used to refine the tracks on most targets. Third, the data from the sensors must be independent, so that well-understood algorithms such as Kalman Filters can be properly applied. Deployed battlefield systems may violate all of these assumptions. As shown in Figure 1, the sensors may be very heterogeneous, ranging from traditional targeting radar systems to imaging systems to acoustic and chem/bio sensors. There is also likely to be a very limited degree of overlap among sensors, and a relatively sparse and inconsistent coverage of the battlespace by traditional sensors, leading to a sparsity of data which must be compensated for via other information when possible. As data from higher level offboard systems such as JSTARS are increasingly made available to lower echelons on the battlefield, as was the case with RPA, the independence between information available at different nodes in the network begins to break down. As a result, exchange and combination of information between battlefield participants must be managed carefully, both to avoid unnecessary use of communications bandwidth, but also to preserve the integrity of the data fusion process. 2.2 Requirements These challenges enable us to derive a set of corresponding general requirements for distributed information fusion architectures to support situation awareness on the modern digital battlefield. To conserve communications bandwidth, the architecture must limit the exchange of data between nodes as much as possible without impacting the ability of the receiving nodes to form a CTP. The architecture must support the incorporation of widely varying forms of sensor and other data into the CTP. It must support the development of a CTP in the face of sparse, nonoverlapping sensor coverage. And it must properly handle the presence of identical data at multiple nodes. 2.3 Key Insights As we have evaluated these requirements and challenges, some insights have emerged that have helped us to develop architectures and systems to respond to the challenge of distributed information fusion in this domain. One of the key insights we encountered in developing our approach is the idea of the Common Relevant. While it is critical for effective battlefield situation awareness that all participants have a consistent view of the battlefield, they do not all need a complete view. Rather, each participant needs to have that portion of the tactical picture that is relevant to that participant s needs. Another critical insight is that, in general, each node in a distributed data fusion network is responsible solely for disseminating information that enters the network at that node. This general principle prevents a node from propagating information it has received from another node unless there is good reason to do so. Information Pull as Well as Push: The system we developed for RPA is completely reliant on data that is sent to it by sensor systems or other data sources, i.e. pushed data. This is characteristic of almost all systems, since sensor data is typically transmitted by the sensors, whether on a data bus, an information network, or a broadcast medium. As the number of sensors on the battlefield increases, however, it will not be feasible to broadcast all information. Instead, information will have to be sent on a selective basis to those nodes that need it, with decisions made by the sender and/or recipient about what information is necessary when. Further, much information necessary for situation awareness is not currently broadcast or transmitted, but is

3 instead stored in databases or other repositories. Examples of this sort of information include terrain and weather databases, intelligence information, and mission plan information. Situation Awareness systems requiring this sort of information will have to provide an automated means of making very specific information requests of a variety of nonhomogeneous databases. 3 Previous Work 3.1 Submarine Operational Automation System (SOAS) Contact Reports Sensor Intel Status Situation Reasoning Object Analysis Group Region Contact Correlate Fuse ID Meta-Controller Management Situation Analysis Threat Lethality Class Capability Threat Intent Doctrine Force Structure Behavior Analysis World View Contacts Environment Regions Ownship Groups Models Goal Management Situation Understanding Sensor Coverage Weapon Coverage Ownship P(detection) Vulnerability Scene Stability Task Management Figure 2 SOAS SA Architecture SA Tasks From 1989 through 1994, ATL led the DARPA-sponsored Submarine Operational Automation System (SOAS) program, which sought to produce a semi-automated Submarine command center. The SOAS system centered around the Situation Assessment (SA) and Tactical Planning (TP) components. ATL developed the SA component (Figure 2), and technology and concepts developed during this effort underlie much of our following work in, Situation Assessment, and Intelligent Agents. Functionality developed on SOAS has been transitioned into the contact management and HCI components of the US Navy s AN/BSY-2 Submarine Combat System. groupings of contacts into tracks within each region. In addition to position and velocity information, the correlator relied on classification information about the contacts and tracks, and on known tactics of submarine behavior, such as zigzag maneuvering, to generate hypotheses about contact correlation and future state. The Situation Analysis (Level 2) evaluated the resulting track picture to identify and monitor threats to ownship. Each track is evaluated for lethality based on the hypothesized class, and the known capabilities of that class of platform. Hypotheses of its intent are generated based on knowledge of doctrine and observations about force structure (the set of tracks). These hypotheses are evaluated over time against the observed behavior of the track to identify the most likely intent. The Situation Understanding (Level 3) component evaluated the results of object analysis and situation analysis to provide an assessment of the impact of the situation on ownship. It continuously computes updated estimates of ownship and threat sensor and weapon coverage. Based on this, it estimates the likelihood of each threat platform detecting ownship, and the likelihood of ownship being able to continue detecting and tracking that threat. It estimates likelihood of ownship successfully killing each threat track, if necessary, and likewise the likelihood of each threat being able to kill ownship. Based on these estimates, it evaluates the overall vulnerability of ownship. It further monitors the scene over time to assess the stability of the picture. The overall assessments of vulnerability and scene stability are employed by the Tactical to plan offensive, defensive, and reconnaissance actions. The Meta-Controller is the second top-level SA component. It provides a goal- and rule-driven control of the Situation Reasoning process. The Meta-Controller evaluates updates to the World View against rules and goals to define tasks which are executed by the Situation Reasoning function. The Meta-Controller enabled an autonomous, goal-directed Situation Assessment process, and was a precursor to ATL s Intelligent Agent technology, described in section 3.3. The Situation Reasoning component contains the reasoning functions that operate on the World View, containing sonar data, environmental information, and ownship status information, to evaluate the situation. The three functions that make up the Situation Reasoning component correspond to Levels 1, 2, and 3. The Object Analysis (Level 1) function performs the complex task of constructing a contact picture from the set of sonar contacts received by a submarine s sonar sensors. Contacts were correlated using a Knowledge-Based Multi- Hypothesis Correlator. The correlator which segregated contacts into disjoint spatial regions, and produced ranked

4 3.2 Rotorcraft Pilot s Associate Sensors Unfused Sensor Fused Battlefield Assessors Battlefield Assessment Internal Situation Assessment Assessed Battlefield s Route Survivability Battle Attack Comms Pilot Display and Interaction Pilot Controls and Displays Figure 3 Rotorcraft Pilot s Associate Architecture From 1993 through 1999, ATL participated in the Rotorcraft Pilot's Associate (RPA) Advanced Technology Demonstration program, sponsored by the US Army s Aviation Advanced Technology Directorate (AATD), at Ft. Eustis, Virginia. [1] RPA (Figure 3) is a decision aiding system that helps Army combat helicopter pilots analyze and manage massive amounts of onboard and offboard data while flying the craft, executing the mission, and remaining safe. In the RPA system, data from a variety of onboard and offboard sensors is fused by a real-time multi-sensor system into a consolidated picture of the battlespace. Assessors evaluate this battlespace picture to gain additional information about the state of the battlefield (Battlefield Assessment) and the state of the vehicle (Internal Situation Assessment). The results of the assessment are used by a set of planners to determine vehicle route (Route ), threats to vehicle safety (Survivability ), battle position and attack strategy (Battle and Attack s), and communications scheduling (Comms ). A sophisticated Controls and Displays suite manages interaction with the pilots, presenting the current battlefield picture and any system recommendations, monitoring pilot activities, and accepting control feedback RPA We developed the RPA subsystem [2] that receives 14 types of onboard and offboard sensor data from up to 200 targets, correlates it, and fuses it into a consolidated picture of the battlespace. The RPA system was an evolution of the SOAS SA Object Analysis function, in which the multi-hypothesis correlator was replaced by the more efficient JVC algorithm due to the stringent real-time requirements of the RPA system. The system (Figure 4) consists of three main elements. A set of Input and Output routines manage the real-time interfaces with the sensor systems and the other components of the RPA system. The input routines read input from the sensor systems at a maximum rate of 10Hz and pre-process the input using tailored sensor-specific modules into a common input format and information content. Once per second, the output routines post-process the track databases to construct the fused output picture and output this to the other RPA components. Per Sensor Per Cluster Input Preprocessing Updated Sensor Tracks Prediction Predicted CTF Clustering CTF/Sensor Track Clusters Cost Functions Cost Matrix Assignment CTF/Sensor Track Assignments Updated CTF Tracks Postprocessing Output Sensor Updates Navigation Stationary EOB CentralTrackFile TrackFile Management Navigation Status base Access Platform Characteristics Sensor Characteristics Central TrackFile Sensor TrackFile Figure 4 RPA Functional Flow A set of Trackfile and base management routines maintain the relationships among a set of track databases, one for each sensor providing input, and a Central Trackfile which stores the fused picture. These routines also provide access to a variety of data about platform, sensor, and weapon characteristics used by. A set of Core Routines perform the heart of the data fusion processing. The Prediction function performs time-alignment across the sets of data being fused to ensure that valid comparisons can be made. The Clustering algorithms break down the battlespace into geographically distinct regions to limit the computational complexity of the following algorithms. Cost Functions operate on each cluster to compute a matrix of composite similarity values between each input sensor data item and the candidate fused tracks. The Assignment function uses the optimal JVC (Jonker-Volgenant-Castanon) algorithm to compute matches between sensor data and fused tracks. Once the matches are identified, algorithms are applied to update the state of the fused trackfile based on the associated sensor data Class and ID Processing One of the key algorithmic advances of the RPA system was its ability to effectively combine the processing of kinematic (position and velocity) information with the processing of Class (vehicle type), ID (specific vehicle information), and IFF (friend/hostile) information. This processing takes place during the comparison of sensor data with fused tracks, by the Cost Functions, and during the updating of the fused trackfile with associated sensor data by the algorithms. ATL s work in both areas [2] drew on the earlier SOAS work and represented major

5 advances in data fusion capability in the RPA system. The Cost Function procedure enables this combined processing of disparate information through a design which computes a set of 7 similarity metrics between a sensor data report and a fused track. These include metrics comparing Position, Velocity, Bearing, Aspect, IFF, Class, and some sensor-specific parameters. Each metric was tailored so that an inconclusive match would yield a value of 0.5, while a perfect match would yield 1.0 and complete dissimilarity would yield 0.0. The composite cost metric was obtained as the product of the results of the seven functions. SENSOR 1 CLASS: TRACKED Resulting Class: TRACKED AIR DEFENSE Air Tracked Entity Land Wheeled Armor Artillery Air Defense Support Tracked ADU T_ADU_MEDIUM_1 T_ADU_MEDIUM_2 T_ADU_LONG_1 T_ADU_LONG_2 SENSOR 2 CLASS: AIR DEFENSE Wheeled ADU Resulting ID: ONE OF THESE 4 At ATL we have developed the Extendable Mobile Agent Architecture (EMAA) [6], which provides an infrastructure for the deployment of intelligent mobile agents. An agent is launched at a processing node with a set of instructions contained in an itinerary, a control construct which permits highly flexible control over agent behavior. Based on conditions or information it encounters, it may need to migrate to another node to continue performing its task or locate needed information. EMAA makes use of the portability inherent in the Java language to migrate the agent from its current processor to the target platform and execute it on that processor. The original applications of EMAA involved the use of mobile agents for search, retrieval, and dissemination of intelligence information in battlefield networks. Later applications exploited persistent Sentinel Agents for monitoring data in distributed information systems to alert a user or client when certain conditions or events occurred. A further extension to the agent capability was the development of the Postmaster facility [7], which permitted mobile agents traveling through a network to exchange information and requests for information Use of Information Agents to Support Information Figure 5 Example of Class in RPA The Class algorithms combine Class and ID information expressed in a class hierarchy (Figure 5). Each sensor report or fused track has a class representation which specifies the confidence of each node in the hierarchy. A set of Modified Bayesian Evidence Combination algorithms developed by ATL are used to compare, combine, and summarize this information. 3.3 Intelligent Agents for Information Retrieval and Dissemination Since 1995, ATL has been developing technology for Mobile Intelligent Agents to support dissimination, retrieval, and monitoring of information on the digital battlefield. [5] An Intelligent Agent is a persistent software construct that is able to interact with its environment in order to perform tasks on behalf of the user, to further the user s goals. Mobility implies that the agent is able to travel between nodes of a network in order to make use of resources that are not locally available. Intelligence, in this context, implies that the agent is imbued with some degree of knowledge of its environment or subject domain that allows it to make decisions that affect its behavior, in response to changing characteristics of its environment, or the problem at hand. Figure 6 - Sentinel Agent used to augment CTP In order to meet the challenge of supporting information pull as well as push, we began in 1999 to investigate the use of mobile intelligent agents to provide information to supplement the data fusion process. We focused on the problem of improving the CTP by identifying areas in the fused sensor data which could or should be improved through the application of additional data from other nonreporting sources. An example of such an application is illustrated in Figure 6. In this system, the output of Sensor is collected to form the basis of the CTP. A persistent Sentinel Agent examines the CTP to determine areas where additional information is needed. This analysis is based on

6 several criteria, including: areas in which data accuracy or latency does not meet requirements, possibly due to reliance on a source such as with high latency or large positional error; and areas where no data are present, but where tactical requirements, expressed in the tactical plan, indicate a need for information. When the Sentinel Agent identifies a need for additional information, it dispatches an Investigation Agent to search for the needed information in a remote data source, such as ASAS. The results of the investigation are converted into a format usable by, and passed as input to for incorporation into the CTP. This approach has been investigated in an internal research and development program and integrated into the ACT II Battle Commander s Decision Aid at the US Army Air Maneuver Battle Lab (AMBL) at Ft. Rucker, Alabama. 4 Candidate Architectures Attribute CEC Centralized DHIF Architectur e Type Peer-to-Peer Hierarchical Hierarchical Target Type Numerous distant aircraft and missiles Intelligence targets Mix of ground, air, and surface targets in the Comm. Bandwidth Timeliness Resulting Accuracy Very High bandwidth, Line of Sight Very good (fraction of a second) Fire control quality Moderate bandwidth, global network Poor (minutes to hours) Sufficient for strategic level decisions battlespace Sensors Essentially homogeneous, Heterogeneou s, widely dispersed Heterogenous, from national assets to individual sensors. Processing High Moderate High at midlevels Moderate Good (seconds) Sufficient for battlespace C2 Table 1 Summary of evaluated distributed fusion architectures. ATL is a participant in a new program, the Hunter Standoff Killer Team (HSKT) Advanced Concept Technology Demonstration, sponsored by AATD. HSKT will result in the deployment of multiple coordinating decision aiding systems, based on the RPA system. In preparation for this program, we undertook a study, funded under an internal R&D project, of architectures to support distributed data fusion to support decision aiding. We identified and evaluated three architectures, summarized in Table Single Composite Sensor Measurement Reports Local Ship Fused Aircraft Local Fused Sensor Measurement Reports Sensor Measurement Reports Missile Battery Local Fused Figure 7 - Cooperative Engagement Capability (CEC) Architecture This architecture is exemplified by the Cooperative Engagement Capability (CEC) system being implemented by the U.S. Navy for Anti-Air Warfare (Figure 7). It features a set of peer nodes, typically ships such as cruisers or destroyers, each with a high quality sensor such as the Aegis SPY 1-D radar. The nodes exchange sensor data over a very high-speed communications link. Each node correlates and fuses the sensor data from all nodes using an identical algorithm. Because of the low latency in the data dissemination between nodes, the fusion systems are operating on virtually the same input, producing virtually identical fused pictures. The combination of high quality sensor data from multiple nodes with very low latency produces a virtual Composite Track in which each track is of quality equal to or better than that available from any single sensor. The goal of the system is to produce a picture in which ships have a fire-control quality track even on targets their own radars are not currently tracking. This enables each ship to optimize the use of its own sensors, focusing them on its assigned mission, while retaining overall situational awareness of the entire battlespace, and keeping the capability to defend itself against any targets. The remarkable capabilities provided by the CEC system come at a considerable price in communications bandwidth, processing, and accuracy requirements. Extremely high communications bandwidth is required to accommodate the capabilities of the system. This link requires substantial power and a large antenna for each participant. A powerful, customized processor, the Cooperative Engagement Processor (CEP), is required to accommodate the algorithms for correlation and fusion of the data. The size and weight of the antenna and processor are such that only land-based or ship-based systems can operate at the full capability. Further, the capability to produce such a high quality picture from dispersed sensors requires extremely precise knowledge, not only of the relative positions of the sensors, but also of their relative alignments and biases.

7 The constraints imposed by this sort of architecture make it infeasible for a mobile battlefield system. Fortunately, however, the needs of the dispersed battlefield system for shared situational awareness do not require high-quality, fire control data. 4.2 Centralized There are substantial disadvantages to this architecture. First, as with its use in the US Intelligence system, it imposes a latency on the availability of the fused picture at the lower level nodes. It also imposes a single point of failure in the system, where if the fusion node is lost or loses communications, the overall Situation Awareness of the system is compromised. As a related problem, it limits the ability of the individual participants, e.g. UGV s, to operate independently or as part of a much smaller group. Finally, this architecture can require significant communications bandwidth. 4.3 Distributed Hierarchical Information Figure 8 - Example Centralized Architecture This architecture is characterized by a hierarchy of nodes, in which all information is passed up the hierarchy to a centralized fusion node. The fused picture is then disseminated to the lower nodes, typically via a broadcast medium. This sort of architecture is characteristic of the way the U.S. Intelligence Community has typically processed information. As might be expected, this architecture typically takes a long time to propagate the fused data back to the lower level nodes. There are several reasons for this. One is related to the character of the data, which are often more complex and potentially more uncertain than, for example, radar track data. Much of the data have in the past required human analysis to interpret, correlate, and fuse. Attempts to automate this process have proven much more difficult than the automation of processing of data from fire control radars and similar sensors. Another reason is that the primary purpose of the fusion system is to supply a fused picture to the decision-makers at the top of the hierarchy, and so the system need not be optimized for providing a timely fused picture to the lower nodes in the hierarchy. On a smaller scale, this sort of architecture is frequently suggested for Battlefield Situation Awareness applications. Figure 8 shows how this might work in our example application. It appears to offer some advantages. Costly processing hardware need only be provided at higher level nodes, typically on vehicles where power is less of a concern. The data fusion algorithms may also be somewhat simplified, especially if the various participants send only their unfused sensor data. Figure 9 - DHIF Node The Distributed Hierarchical Information (DHIF) architecture was developed by ATL for application to largescale command and control problems in the littoral (sea/shore interface) battlespace. In this architecture, the participants consist of nodes in a military command and control hierarchy, with each node corresponding to a military unit at some echelon. Each node/unit (Figure 9) is characterized by three things: The set of data entering the network at that node, i.e. sensors organic to that unit or reporting in through that unit. These might include intel assets associated with that unit, or a UAV-mounted sensor controlled by that unit. The parent node in the hierarchy, typically corresponding to the commanding unit. The child nodes in the hierarchy, typically subordinate units.

8 In addition to its local function of producing a fused picture for use at that level, each node has responsibility for propagating information to its parent node and to its child nodes. In order to do this while ensuring that information is not counted repeatedly, it must compute several different fused pictures, one for local use, and one, referred to as the proxy fused picture, corresponding to each node to which it must propagate information. As information is received from any other node, it is used to update the local fused track picture as well as the fused pictures corresponding to all nodes except the one from which the information is received. This architecture has the benefits of guaranteeing each node access to the entire fused picture of the battlespace, incorporating all available information. Since fusion is formed at each node in the hierarchy, the flow of information back down to subordinate nodes is much quicker than in the Centralized architecture. Further, the processing burden at higher nodes is reduced because fusion is performed at intermediate stages. The bandwidth requirements are less than if the CEC broadcast paradigm were applied to this problem. However, there is still a substantial processing requirement associated with maintaining multiple fused pictures. Further, the loss of a higher-level node essentially partitions the battlefield network by eliminating the sharing of information among that node s children. 5 Grapevine Architecture for Peer to Peer Information Each of the three architectures discussed above is a potential solution to the distributed fusion problem in the sample application domain described in Section 2, but each has significant drawbacks. In particular, none of the three meets all of the requirements described in section 2.2. To meet these requirements, we have developed the Grapevine architecture, which we are using as the basis for a distributed information fusion system we are building. 5.1 Motivation The Grapevine architecture was originally developed by ATL for use on DARPA s Small Unit Operations (SUO) program, for propagating information about threat warnings throughout a network of peer warfighter Situation Awareness Systems (SAS s). It relied on the intuition about the way that information is spread informally in networks of people, through the grapevine. An individual has an idea of what information his peers may have that may be of interest or value to himself, and an idea of the interests or needs of his peers. Based on this, the individual requests information he needs or wishes from those peers he expects to have that information. Likewise, he offers unsolicited information he has to those peers he expects to need or wish the information. A simpler version of this concept is formalized in distributed systems theory as the gossip protocol. 5.2 Grapevine Architecture Sensor from peer platorm 1 Sensor from peer platorm n Platform 1 Configuration Platorm n Configuration Local Sensor Grapevine Manager Local Sentinel Agent Grapevine Agent 1 Grapevine Agent N Local Configuration Local Fused Configuration Updates to peer platforms Sensor to platorm 1 Sensor to platorm n Figure 10 - Grapevine Architecture Processing Node The implementation of the Grapevine architecture (Figure 10) builds upon our previous work combining multi-sensor data fusion with intelligent agents. Each node in the architecture contains a process, which fuses locally obtained data (from local sensors and data sources) and data received from other peer nodes. The Grapevine Manager at each node manages the interchange of data with peer nodes. For each peer node, it contains a Grapevine agent which represents the information needs and capabilities of that peer node. As local information is generated by the sensors or other sources on the platform, each grapevine agent evaluates that information against the needs of the peer platform it represents, for such factors as: sensor type data from common sensors, e.g. JSTARS, is not sent mission the peer platform s mission may or may not require the propagation of friendly tracks location the peer platform may only need information within a geographic or temporal/geographic radius. coverage the peer platform may need information from beyond its own sensor platform. Each Grapevine agent propagates the needed information to the peer platform it represents, providing an intelligent push of data through the network. At the same time, the Grapevine Manager has a representation of the local platform s information needs and capabilities, expressed in terms of available sensors and data sources, mission, location, and sensor coverage. A Sentinel Agent within the Grapevine Manager monitors the local fused picture to identify information needs not met by the local picture. Based on this, it sends out updated configuration data for the local platform to the Grapevine manager on peer platforms. This is used to update the Grapevine Agents on the peer platforms which represent the local platform. This propagation of information needs effects

9 an intelligent pull of data to meet the changing information needs of the local platform. 5.3 Benefits of the Grapevine Architecture There are several distinctive features of the Grapevine Architecture. First, it is a peer-to-peer network. Propagation of data occurs between peer nodes in the network, although in practice this would probably be implemented as an extension to some form of hierarchical command and control system. Second, peer to peer data propagation includes only data known to be of use to the recipient node, thus limiting the required processing and bandwidth. Third, the architecture is extensible. It can accommodate the addition of peer nodes merely by reconfiguring nearby nodes to reflect the addition of the new nodes. Fourth, it is survivable there is no single point of failure. Since in general each node will have multiple peers, data can spontaneously reroute around missing nodes, and thus the loss of any single node will only result in the loss of the data sources local to that node. 6 Conclusions The Development of Situation Awareness on the digital battlefield faces numerous challenges. It requires effective analysis functions to construct a picture of the battlefield entities, evaluate their characteristics and intent, and assess the overall impact of the situation. These functions must be developed and deployed in an architecture which facilitates effective transfer of both processed and unprocessed information among the various participants. Disseminating this information in a way that supports the situation awareness process requires addressing issues of processing, communications bandwidth, and the nature and deployment of sensors and data sources. These most heavily impact the data fusion process. Several architectures exist in various domains for distributed fusion of information, but each has drawbacks which limit its applicability to this problem. Such an architecture must limit the exchange of data between nodes as much as possible, support the incorporation of widely varying forms of sensor and other data, support the development of a CTP in the face of sparse, non-overlapping sensor coverage, and properly handle the presence of identical data at multiple nodes. ATL s innovative Grapevine architecture, which merges our extensive work in with technology for Mobile Intelligent Agents, draws upon some key insights we have developed during our work to meet these requirements, and appears well suited to support the development of Situation Awareness on the rapidly emerging digital battlefield. [2] Don Malkoff and Angela Pawlowski, RPA, 9th National Symposium on Sensor, Vol. 1, Infrared Information Analysis Center, pp , September [3] Martin Hofmann, Multi-Sensor Track Classification in Rotorcraft Pilot's Associate Presented at the American Helicopter Society 53rd Annual Forum, Virginia Beach, Virginia, April 29 - May 1, [4] Angela Pawlowski and Craig Stoneking, Army Aviation of Sensor-Pushed and Agent-Pulled Information, to be Presented at the American Helicopter Society 57 th Annual Forum, Washington DC, May 9-11, [5] Kenneth Whitebread and Steve Jameson, Information Discovery in High-Volume, Frequently Changing, IEEE Expert/Intelligent Systems & Their Applications Vol. 10, No. 5, October 1995 [6] Russ Lentini, Gautam Rao, and Jon Thies, EMAA: An Extendable Mobile Agent Architecture, AAAI Workshop - Software Tools for Developing Agents, July [7] Jennifer Kay, Julius Etzl, Goutham Rao, Jon Thies, The ATL Postmaster: A System for Agent Collaboration and Information Dissemination, Proceedings of the 2nd International Conference on Autonomous Agents (Agents 98). References [1] Peter Stiles and Martin Hofmann, Demonstrated Value of and Situation Assessment, Presented at the American Helicopter Society Avionics and Crew Systems Technical Specialist's Meeting, Philadelphia PA, September 23-25, 1997.