CONSOLIDATED SITUATIONAL AWARENESS FOR AIRCRAFT CARRIER
DECISION CENTERS
C2 Decision Making & Cognitive Analysis Track
JEFFREY D. HICKS, POINT OF CONTACT
University of Nebraska and 21st Century Systems, Inc., 704 Edgewood Blvd. Papillion, Nebraska,
USA 68046
E-mail: jeff@21csi.com Phone: 402-212-7474 Fax: 402-597-6466
DR. PLAMEN V. PETROV
st
21 Century Systems, Inc., 12612 Decatur Street Omaha, Nebraska, USA 68154
E-mail: plamen@21csi.com Phone: 402-384-9893 Fax: 402-493-3168
DR. ALEXANDER D. STOYEN
University of Nebraska and 21st Century Systems, Inc., 12152 Windsor Hall Way, Herndon, Virginia
USA 20170
E-mail: astoyen@computer.org Phone: 571-323-0080 Fax: 571-323-0082
DR. QUIMING ZHU
st
University of Nebraska and 21 Century Systems, Inc., University of Nebraska, Computer Science
Department, PKI 281D, 6001 Dodge Street Omaha, Nebraska, USA 68182-0500
E-mail: zhuq@unomaha.edu Phone: 402-554-3684 Fax: 402-554-3284
Form Approved
OMB No. 0704-0188
Report Documentation Page
Public reporting burden for the collection of information is estimated to average 1 hour per response, including the time for reviewing instructions, searching existing data sources, gathering and
maintaining the data needed, and completing and reviewing the collection of information. Send comments regarding this burden estimate or any other aspect of this collection of information,
including suggestions for reducing this burden, to Washington Headquarters Services, Directorate for Information Operations and Reports, 1215 Jefferson Davis Highway, Suite 1204, Arlington
VA 22202-4302. Respondents should be aware that notwithstanding any other provision of law, no person shall be subject to a penalty for failing to comply with a collection of information if it
does not display a currently valid OMB control number.
1. REPORT DATE
3. DATES COVERED
2. REPORT TYPE
JUN 2002
00-00-2002 to 00-00-2002
4. TITLE AND SUBTITLE
5a. CONTRACT NUMBER
Consolidated Situational Awareness for Aircraft Carrier Decision
Centers
5b. GRANT NUMBER
5c. PROGRAM ELEMENT NUMBER
6. AUTHOR(S)
5d. PROJECT NUMBER
5e. TASK NUMBER
5f. WORK UNIT NUMBER
7. PERFORMING ORGANIZATION NAME(S) AND ADDRESS(ES)
21st Century Systems Inc,704 Edgewood Blvd,Papillion,NE,68046
9. SPONSORING/MONITORING AGENCY NAME(S) AND ADDRESS(ES)
8. PERFORMING ORGANIZATION
REPORT NUMBER
10. SPONSOR/MONITOR’S ACRONYM(S)
11. SPONSOR/MONITOR’S REPORT
NUMBER(S)
12. DISTRIBUTION/AVAILABILITY STATEMENT
Approved for public release; distribution unlimited
13. SUPPLEMENTARY NOTES
The original document contains color images.
14. ABSTRACT
15. SUBJECT TERMS
16. SECURITY CLASSIFICATION OF:
17. LIMITATION OF
ABSTRACT
a. REPORT
b. ABSTRACT
c. THIS PAGE
unclassified
unclassified
unclassified
18. NUMBER
OF PAGES
19a. NAME OF
RESPONSIBLE PERSON
13
Standard Form 298 (Rev. 8-98)
Prescribed by ANSI Std Z39-18
CONSOLIDATED SITUATIONAL AWARENESS FOR AIRCRAFT CARRIER
DECISION CENTERS
JEFFREY D. HICKS, POINT OF CONTACT
University of Nebraska and 21st Century Systems, Inc., 704 Edgewood Blvd. Papillion, Nebraska,
USA 68046
E-mail: jeff@21csi.com Phone: 402-212-7474 Fax: 402-597-6466
DR. PLAMEN V. PETROV
21st Century Systems, Inc., 12612 Decatur Street Omaha, Nebraska, USA 68154
E-mail: plamen@21csi.com Phone: 402-384-9893 Fax: 402-493-3168
DR. ALEXANDER D. STOYEN
st
University of Nebraska and 21 Century Systems, Inc., 12152 Windsor Hall Way, Herndon, Virginia
USA 20170
E-mail: astoyen@computer.org Phone: 571-323-0080 Fax: 571-323-0082
DR. QUIMING ZHU
University of Nebraska and 21st Century Systems, Inc., University of Nebraska, Computer Science
Department, PKI 281D, 6001 Dodge Street Omaha, Nebraska, USA 68182-0500
E-mail: zhuq@unomaha.edu Phone: 402-554-3684 Fax: 402-554-3284
ABSTRACT
As the Naval Forces progress toward the network-centric environment envisioned by
JV 2010 and JV2020, their dependency upon decision-making aids will grow
exponentially as the warfighter’s thirst for knowledge from the flood of information
rises. As noted from Joint Vision 2020, we "...must be able to take advantage of
superior information converted to superior knowledge to achieve "decision
superiority" - better decisions arrived at and implemented faster....". Particularly of
concern are the shortfalls in the consolidated situational awareness available to the
decision makers in the Tactical Flag Command Center (TFCCs) and Combat Direction
Center (CDCs) onboard aircraft carriers. The existing CDC and TFCC systems do not
provide integrated and fused information which requires more people to glean
information out of multiple, stove-piped systems. The current systems are not designed
to enhance decision-making and information is not presented in an integrated,
graphically based manner that facilitates communications and decision support. This
increases response times, resulting in reduced mission effectiveness. 21st Century
Systems, Inc. is proposing a unique solution to this issue, the Advanced Battlestation
with Decision Support System (ABS/DSS) that utilizes an Agent-based Decision
Support System coupled with a 2D/3D Battlespace Visualization Tool. The ABS/DSS
utilizes 21CSI’s Agent Enhanced Decision Guide Environment (AEDGE™)
Architecture which expedites generation of Agent-based systems.
1
Introduction
In response to the capability shortfall for consolidated situational awareness in aircraft carrier decision
centers, 21CSI is designing, prototyping and will transition a Decision Support System for the
Advanced Carrier Battlestation. The Advanced Battlestation with a Decision Support System
(ABS/DSS) is a battlespace visualization and decision-aid system that will be used by a battle group
commander and his staff who man the decision centers. The ABS/DSS’s suite of information
management tools prioritize and re-configure the battle picture in real-time to display the tactical
information in a manner that is more easily understood and absorbed by combat watchstanders. The
development of 21CSI’s ABS/DSS is being pursued through a progression of software deliverables: a
standalone proof-of-concept mock-up, a detailed prototype, a prototype partially-integrated with
other program components’ prototypes, a prototype fully integrated distributively, an integrated
prototype validated in a Navy testing environment, and finally, an operational insertion of intelligent
decision aids into the fleet. The ABS/DSS utilizes 21CSI’s Agent Enhanced Decision Guide
Environment (AEDGE™) Architecture which expedites generation of Agent-based systems.
In the following, we will first, in section 2, present an overview of the Advanced Battlestation with
Decision Support System. In order to more fully present the functionality and capabilities of the
ABS/DSS several screen captures of actual running software are used as example illustrations. In
section 3, we describe the AEDGETM architecture and its application in implementing the decision aid
model used in the Advanced Battlestation with Decision Support System. We use diagrams and
examples to illustrate the coherent relations among the software modules and the functionalities each
of the modules will play in terms of their implementation of the mixed strategy. In Section 4, we will
briefly discuss the advantages of using the AEDGE architecture in developing systems for complex,
interactive, time- and mission-critical decision support systems. Section 5 briefly summarizes the
major technique points of the paper.
2
Battlespace Visualization
The current configuration of 21CSI’s ABS/DSS allows the watchstander to navigate the 3D
battlespace using an attached joystick. Consolidated situational awareness is gained through
exploration of the integrated air, ground, maritime, and subsurface environments of the battlespace.
Visual cues such as a numeric heading marker, view altitude, and attack angle (located centerline and
above the display), whiskey grid lines (engraved into the surface topography), and grid ID markers are
used for operator references to facilitate orientation in the 3D environment. Objects in 3D space are
represented by standardized Navy AADC icons. The ABS/DSS utilizes Digital Terrain Elevation
Data (DTED) and Digital Bathymetric Data (DBDB-V) to provide a 3D terrain for the watchstander
to navigate. The operator can select the transparency of the terrain such that a terrain feature will not
Figure 1. 3D ABS/DSS Display
completely hide the presence of a high interest contact or enemy ground asset. Similarly, the digital
bottom contour data is used for the ocean, river, and lake bottom visualizations.
Selecting the “2D” button generates a 2D bird’s eye view of the battlespace, shown as the popup
window in the upper left hand corner of the 3D display of Figure 2. This 2D map displays contacts
using standardized Navy Advanced Combat Direction System (ACDS) icons and the watchstander
can selectively change the geographic scale of the 2D map using the zoom function. Observer and
object motion in the 2D and 3D space is synchronized. As the watchstander navigates using the
joystick in the 3D display, the observer icon (a white circle) moves correspondingly on the 2D display.
Additionally, if the watchstander needs to quickly jump from one location in the battlespace to
another location some distance away, the watchstander need only to click on that location on the 2D
display and both the 2D and 3D visual displays are transported to that location.
A heading leader is included on the observer icon in the 2D map to provide additional visualization
cues for the watchstander. The heading leader turns with the observer and corresponds to the heading
marker in the 3D map. In other words, navigation in the 2D/3D domains is completely linked with
each domain supporting the visualization in the other domain.
Figure 2. Synchronized 2D/3D ABS/DSS Display
The watchstander has the ability to display information about any known contact in the system. This
information is contained in the Track Information Box, shown in the lower left hand corner of Figure
3. The contact’s Track number, Identification Friend or Foe (IFF) designator, identification, location
(lat/long), bearing, course, speed, range, altitude, are displayed. If information is desired on a contact
that is currently in the field of view of the watchstander in the 3D battlespace, the watchstander simply
selects the contact using the mouse pointer and the information block will automatically be updated.
As shown in Figure 3, the watchstander has selected track 1023, the ship (CG-67) in the lower right
of the 3D display. The contact is now highlighted green (friendly) to indicate that this is the contact
for which the track information is displayed. If however, the contact is not in the field of view, the
watchstander selects the “Action” button and then manual enters the desired contact number in the
popup box as shown in Figure 3, in the lower left hand corner of the 3D display. In addition to
contacts, the ABS/DSS provides for the capability to select all fixed or mobile ground assets. The
information about these ground assets is displayed similar to the procedure described for contacts.
Figure 3. Hooking Contact for Track Information, ABS/DSS
In the current configuration of 21CSI’s ABS/DSS, rudimentary agent technology is employed in order
to facilitate the watchstander’s situational awareness. Agents notify the watchstander of contacts that
violate tripwires. The tripwire values are operator selectable by selecting the “Alert Presets” button
and using the appropriate password. Adjustable tripwires for contacts include but are not limited to:
Minimum or Maximum Airborne Speed
Minimum Airborne Range
Minimum or Maximum Airborne Altitude
Minimum or Maximum Surface Speed
Minimum Surface Range
Minimum or Maximum Submerged Speed
Minimum Submerged Range
Threat IFF
Contact Weapon Range
Initial Detection of Hostile Contacts
The agents utilized by the DSS analyze all known contacts against the Alert Presets and displays a
message in the Alert Message Box if a tripwire is violated. The displayed message indicates the time
of the alert, the contact number, and the tripwire exceeded as shown in the lower right hand corner of
Figure 4. In this case, at 2141:10Z a new hostile contact, designated track 1032 is reported. The
Alert Message Box, in its normal configuration operates as a waterfall display with the most recent
alert appearing at the top. If the watchstander desires to sort the alerts, he may sort the alerts in
ascending or descending chronological order and/or by contact number.
Figure 5. Recommendations on ABS/DSS
Figure 4. Alert Messages on the ABS/DSS
The ABS/DSS is supported by 21CSI implemented COTS voice synthesis and recognition software
that allows the watchstander more freedom in performing his duties in a less distracted, hands-free
environment. Using Text-to-Speech voice synthesis, 21CSI’s ABS/DSS utilizes a computergenerated voice to deliver aural alert notifications to the watchstander’s headset or external speakers.
Abbreviated voice notifications are provided to lessen the distraction of the watchstander by alerting
the watchstander of an alert instead of watchstander having to inefficiently check the Alert Message
Box continuously for new alerts. If the abbreviated voice notification stimulates a need for further
information about the alert, the watchstander has an archived list of the alerts in the Alert Message
Box to review. For voice recognition, 21CSI’s ABS/DSS uses grammatical rule sets to implement
system control functions to facilitate operation in a hands-free environment. For example, the
watchstander simply speaks into the headset to “Hook Contact Number XX” or “Zoom Contact
Number XX.” The verbal commands provide an alternative hands free operating mode for the
respective manual button operations described above.
21CSI’s ABS/DSS utilizes agents to analyze the battlespace to provide recommendations to the
watchstander concerning the tactical situation. The ABS/DSS lists the recommendations in the Agent
Window located in the lower center of the 3D display. Additionally, 21CSI’s ABS/DSS provides
audible notification of the recommendations via the voice synthesis software. Recommendations are
specific to the particular warfighting specialty that the watchstander is responsible for at the respective
station. In the case shown in Figure 5, the agent recommended “1025 COVER 1040” just after track
1040 took off from an unfriendly airstrip (1025 is a friendly fighter). As the situation progresses, the
tactical picture changed when track 1021, a helicopter, is endangered. The rules of engagement have
changed and the agent recommends “1025 KILL 1040.” Similarly, Figure 5 shows a recommendation
for refueling the friendly fighter 1026. 21CSI’s ABS/DSS provides recommendations only and the
human-in-the-loop can choose to accept the recommendation and issue the order to 1025 or ignore
the recommendation if other considerations not available to the ABS/DSS must be incorporated into
the decision.
3
Software Architecture - AEDGETM
21CSI’s extensible multi-component Decision Support Systems (DSS) architecture, known as
AEDGETM, is a standardized COTS, DII COE compliant agent architecture that enables complex DSS
to be developed as an expansion of the AEDGETM core functionality. The need for a standardized
common infrastructure has led us to design an environment where both agents and real/simulated
entities (or representations of real-world assets) are represented as first-class objects capable of
interacting with each other. The AEDGETM is 21CSI’s undertaking to build a common reference
framework and a test-bed environment for integrated simulation and agent-based decision support.
The architecture describes the data objects, interfaces, communication mechanisms, component
interactions, and integration mechanisms for the AEDGE™ and its extensions. The ABS/DSS is an
extension of the AEDGETM. In this section we will introduce the AEDGE Architecture and in section
4 the advantages of using the AEDGE will be briefly discussed.
3.1 AEDGE Information Flow
The AEDGE Information Layer provides data format definitions (data Objects) and information flow
descriptions shown in Figure 6. As part of the AEDGE infrastructure, four major packages of data
Classes are defined. These classes form the base AEDGE information environment, which supports
persistent and remote data access through serializable data.
Geographic and Terrain Data. These define locations, routes, and geographic areas, with their
coordinates, elevations, and properties. For example, terrain properties (elevation, soil type,
vegetation, etc.) are stored in TerrainData objects. Coordinates and locations are encoded by
Location objects, which also define unique names for the locations.
Entity and Track Data. This hierarchical set of classes defines the data objects associated with track
information. Entities are characterized with their speed, heading, fuel status, and so on. Targets carry
priority and classification data, while Platforms contain information about the weapons and sensors
carried onboard.
Agent Data. While Agents are mostly functional entities and not typically data-heavy objects, some
Agents may choose to preserve some or all of their data in a serializable (or persistent) format. Such
Agents will be able to store and modify their characteristics as well as possess the ability to migrate
among network nodes.
Metrics and Measures Data. As part of the AEDGE information infrastructure, performance,
scoring and other measures and metrics are supported. The Metrics and Measures package defines
the data classes for storing and exchange of metrics data. These include Trainee Scores,
Communication Measures, Load Measures, Interaction Measures, and so forth.
Data-Bridge Interfaces. Though not part of the Information Layer, the data bridges are essential
components of the AEDGE infrastructure as they provide connectivity to external, components, and
information sources. External information sources, such as DIS/HLA compliant simulators, Sensor
Feeds, Standard Databases, instrumentation and monitoring and visualization tools, etc. can be
connected and interact with the AEDGE through a variety of data bridges.
3.2 AEDGE Components and Services
21CSI’s AEDGE components are the base software units providing various functionalities to the user
and to other components. Figure 7 shows these base units. Infrastructure Components are
components that provide connectivity and manage other components. All Functional Components
encode algorithms for various types of processing. Components communicate to each other by
sending Service Requests (using the Service object to store the request data) and receiving Service
Results. When a given component needs to send a message to the “clients” or Service Requestors
subscribed to it, simple Message object is used for efficiency. The message can advertise service
availability at the sender component or it may provide a one-time notification or information item.
Manager
Infrastructure Component (Manager)
Agent
Functional Component (Agent)
svc
Service object
[class, type, parameters, QoS required]
res
Service Result object
[service, code, result, QoS received]
msg
Message object
[receiver, message]
Figure7.6.AEDGE
AEDGEbase
Information
Flow
Figure
components
and services
3.2.1 Component Interactions
In the AEDGE architecture, components communicate among each other via the Service
Provider/Service Requester Protocol (SPSR). Service providers are components that implement an
algorithm or need to share their data (data sources). Service requesters are the components that need
a function performed for them by some other component or need to import data from another
component. Both service requesters and service providers implement remote interfaces, which enables
such components to communicate over a TCP/IP network. The remote interface implementation is
currently based on Java RMI (remote method invocation, a type of simplified ORB service), though
the Architecture is not dependent on this implementation.
The SPSR protocol is based on three data objects: Service, ServiceResult and Message. The Service
object encapsulates the class, the type, the required quality of service (QoS) and the parameters of a
service request. The ServiceResult object provides a reference to the original service, a return code
(success or failure), a return object (String, Recommendation, etc), and an actual received QoS.
Messages provide a way of service providers to advertise the availability of new services and to notify
subscribers of new data available.
Service provider components register their location and the services they provide with a Component
Registry, which is responsible for tracking and maintaining service provider information current.
Service requesters lookup service provider information from the Component Registry and then
establish a direct connection with the providers they wish to engage. A service request (either
blocking or non-blocking) is sent from the service requestor to the service provider. The provider
then replies (immediately or at some future time with a ServiceResult.
3.2.2 Agents and Agent Interactions
Agents in AEDGE are specialized components that generate recommendations either in response to a
user inquiry or spontaneously, according to their function. Agents are usually organized in agent
communities, unified under an Agent Manager component, which is responsible for invoking and
synchronizing individual agents.
The Agent Manager interacts with agents via the SPSR protocol, while users (through UIs) interact
with the Agent Manager through more user-friendly Inquiry/Recommendation exchange protocol
(IREP). The users can query the agent manager by sending context information (entities, georeferences, target information, etc.) and specific requests for recommendations. The query is internally
translated to service requests and sent to the Agent Manager. The users are not limited to the IREP –
they can use any query representation, such as SQL queries, as long as they can be internally
converted to service requests.
Upon receiving a user-level query, the Agent Manager selects and invokes the appropriate agents to
perform the desired tasks. The Agent Manager has a table of registered Agents and their capabilities.
Thus, the Agent Manager is the one that partitions the problem, sends sub-tasks to the individual
Agents, and later combines and deconflicts the solutions. After an overall solution is reached, the
Agent Manager forms a set of recommendations, which are returned to the User via a ServiceResult
object. In essence the IREP is a user-friendly protocol build on top of the SPSR protocol.
Request
Local or Remote
Access
User
Component Interface
Registry
Inquiry
Look-up
Register
Registered
Recommendations
Services
Service
Service
Services
ServiceResult
Service
Providers
Request
Agent Manager
Registered
Agents
Service
Service
Services
Service
Register
ServiceResult
Service
Implement
Service
Services
Service
Requester
Component
Message
Service
Service Provider
Provider
Notify Component
ServiceResult
Request
Agent
Implement
Service
Figure 9. Agent Components over AEDGE services
Figure 8. AEDGE SPSR protocol interactions
The interactions among agents and the Agent Manager are solely based on the SPSR protocol, as
these are optimized for efficiency and not necessarily for user-friendliness. Figure 10 demonstrates
four different modes of User/Agent-Manager/Agent interactions, described below.
User
Interface
(a)
User
Interface
(b)
Recommendations
Inquiry
Service
Request
Agent
Manager
Agent 1
(c)
Agent
Manager
Agent 2
Agent 1
Agent
Manager
Agent
Manager
Agent 1
Agent 2
User
Interface
(d)
User
Interface
Service
Result
Agent 2
Agent 1
Agent 2
Figure 10. Different modes of agent interactions: (a) User to Agent Manager; (b) Agent Manager
to individual agents; (c) User bypasses Agent Manager; and (d) Agent-Direct interaction.
a) User to Agent Manager Interactions. Essentially the user sends an inquiry to the Agent
Manager, based on the user’s current needs and query representation language. The inquiry may
consist of a task description and optionally a context update, such as platforms, targets, georeferences etc. The inquiry is internally serialized and translated into service requests, which are
then sent to the Agent Manager via the SPSR protocol. After the Agent Manager performs the
requested tasks, it sends a reply in the form of a set of recommendations. Recommendations are
core objects in AEDGE’s framework, which represent desired actions and commands.
Recommendations may be produced by both Agent Managers and users and are interpreted by
Entities to form tasks and orders. In this case Recommendations are generated by the Agent
Manager and sent for approval to the User.
b) Agent Manager to Individual Agents. In this interaction the Agent Manager partitions the task
to subtasks for the individual agents, registered under the Manager. Subtasks are then sent to the
agents via the SPSR protocol, encapsulated in Service objects. After the individual agents arrive
at a solution they respond to the Agent Manager with ServiceResult objects, which are interpreted
by the Manager. The Agent manager performs synchronization and deconfliction of the individual
agents’ results to ensure that the user will receive a coherent set of recommendations (in case
individual agents had provided conflicting information).
c) User bypasses Agent Manager. The user can interface directly with the individual agents, using
the SPSR protocol. If the user process can locate the Service Provider of an agent (via a
Component Manager where that agent is registered), the user can send service requests directly to
the agent and listen for the ServiceResult object in the reply. This places the burden of locating
and interfacing with the agent’s service provider on the user, but it provides more flexibility and
faster response.
d) Agent-Direct interaction. Agents can communicate with each other indirectly (through the
Agent Manager) or directly, via the SPSR protocol. The Requester agent looks up other agents’
service providers from any component manager (including the Agent Manager) and can then send
service requests to other individual agents. The Provider Agent handles the service request just
like it would handle a request from the Agent Manager. The Requester agent needs to be able to
handle the ServiceResult returned by the Provider. Agent-direct interaction provides the flexibility
of extending the agent community that belongs to an Agent Manager without having to modify the
login of the Manager itself.
4
Benefits of the AEDGETM Architecture
21st Century Systems, Inc.’s AEDGE provides a common framework, information exchange
mechanisms, and standard libraries of agent algorithms. The AEDGE kernel is extended by a family of
components, which provide users with customized decision support toolkits. AEDGE has an open
architecture, capable of connecting to any data source as well as exporting data to any well-defined
format.
AEDGE provides multiple levels of customization. The AEDGE-based Scenario Editor can
automatically generate user-built scenarios and scripts. Rules and triggers for agent behaviors can be
created and modified by the advanced user. AEDGE also provides APIs for custom extensions of
agents, data bridges, and the COP framework. The sophisticated user will be able to use AEDGE as a
flexible development and testing environment for DSS components. The practical user will enjoy
AEDGE’s versatile data connectivity and its near-real-time execution and monitoring of DSS
functions. As a built-in bonus, AEDGE provides connections to a number of simulators and data
formats, including HLA, DIS, DTED, DBDB2, XML, as well as support for multiple modes of
distribution (CORBA, RMI, TCP/IP).
5
Conclusion
This project explores the problem of providing consolidated situational awareness to aircraft carrier
decision centers by fielding an Agent-based decision support system coupled with a 2D/3D linked
battlespace visualization tool. 21CSI has chosen to implement the system utilizing 21CSI’s Agent
Enhanced Decision Guide Environment (AEDGE™). The effort has been extremely successful in the
rapid development, and prototyping of the system and initial shore-based testing has been very
encouraging. The ABS/DSS is ready for code production and extensive at-sea testing.
6
Acknowledgements
We thank PEO Carriers for the opportunity to demonstrate the power of 21CSI’s Agent Enhanced
Decision Guide Environment (AEDGE™) Architecture in the rapid development of decision support
systems.
7
Bibliography
Hicks, J. D., Stoyen, A. D., Zhu, Q. “Intelligent Agent-Based Software Architecture for Combat
Performance under Overwhelming Information Inflow and Uncertainty,” Proceedings of the
Seventh IEEE International Conference on Complex Computer Systems, ICECCS’2001, Skovde,
Sweden, June 2001.
2. Petrov, P. V., Stoyen, A. D. “An Intelligent-Agent Based Decision Support System for a Complex
Command and Control Application,” Proceedings of the Sixth IEEE International Conference on
Complex Computer Systems, ICECCS’2000, Tokyo, Japan, September 2000.
3. Petrov, P. V. “Applications of Agent Architectures to Decision Support in Distributed Simulation
and Training Systems,” Dissertation Thesis. New Jersey Institute of Technology, Newark, NJ,
May 2000.
st
4. Petrov, P. V., Stoyen, A. D., Hicks, J. D., Myers, G. “21 Century Systems, Inc.’S Agent
TM
Enabled Decision Guide Environment (AEDGE )” IAT 2001 Maebahsi, Japan, October 2001.
1.