ABSTRACT

As simulations have evolved, interoperability between them has emerged as a fundamental technique for increasing their applicability and minimizing the cost of development and maintenance. From totally independent systems, through manual interfaces, automated interfaces, messaging standards, control standards, and architectural standards - the field has been transformed from a set of independent programs into a loose confederation working together to maximize each others contributions. The next step in this evolution is the inclusion of real-world combat computers in the simulation federations, particularly command and control computers.

This paper will define the steps that must be taken to support this integration with a large number of simulation systems. It will explore interoperability projects that are taking place within the simulation and C4I system communities, describing architectures such as the simulation High Level Architecture, the Modular Reconfigurable C4I Interface, the Defense Information Infrastructure - Common Operating Environment, and the Joint Military Command and Information System. Interoperability methods for the generic integration of systems built to a common architecture will be proposed and some argument given to its viability.

1 SIMULATION INTEROPERABILITY

Though simulations have been used by the military for analysis and training for centuries, it was not until the advent of computer networks that the issue of integrating multiple heterogeneous systems emerged. Prior to that, it was naturally assumed that each simulation was a virtual world unto itself, and that information exchange was a laborious, human-driven process. Analytical simulations were the first to crack the "interoperability barrier" by creating simulations that were specifically designed to accept the output of another model as the input for beginning a different stage of analysis.

The virtual community created the Simulator Networking (SIMNET) systems with their associated protocols for joining multiple copies of the same simulator into a common synthetic world. Those these were intended for homogeneous simulations at a single location, they pointed the way for more ambitious projects. Distributed Interactive Simulation (DIS) protocols followed, adding the ability to join a large variety of simulations and to do so across wide area networks.

As this was developing the constructive community was creating the Generic Data System (GDS) to bridge the gaps between constructive simulations. These allowed widely different simulations to exchange world data and deposit it in a common data repository and analysis system. This was followed by the Aggregate Level Simulation Protocol (ALSP) which created a more dynamic environment and provided distributed management functions.

The High Level Architecture (HLA) promises to join both of these communities and allow them to work together at a level not attainable before. Simulations from many fields: staff training, crew training, live training, analysis, engineering, and testing will be able to take advantage of a single architecture for distributed simulation.

The next step in this evolution seems to be the integration of real world C4I systems into the synthetic world. Projects like the Modular Reconfigurable C4I Interface (MRCI), Tactical Simulation System (TACSIM), and other experiments are illustrating the fact that these command systems can be extensions of the distributed simulation paradigm. TACSIM supports dedicated interfaces between simulations and intelligence analysis systems and MRCI promises to extend this to the generic level available to simulations through the HLA Run Time Infrastructure (RTI). With this continuous expansion of the dimensions of interoperability it is probable that the integration of other forms of combat computer systems will follow: radar trackers, radios, communication stations, operational sensor systems, and even combat aircraft. As real systems, particularly C4I systems, settle into the use of standard message formats and data exchange methods, the level of interoperability between these different fields will continue to increase.

The era of dedicated, stand alone simulation models is coming to a close. The class of problems that can be addressed with today's technology far exceeds the ability of a single model to capitalize upon. Distributed, cooperative simulation solutions that can still operate independently are going to be the systems of the foreseeable future.

A topological illustration of each of these levels of interoperability is shown in Figure 1.

Figure 1. Simulation Interoperability Techniques

2 C4I SYSTEM INTEROPERABILITY

Within the military command and control communities, standardization programs have been evolving in response to operational and budgetary issues very similar to those encountered in the simulation community. As computerized systems were developed for command, control, communications, and intelligence a variety of different hardware architectures, data representations, and network standards created an environment in which each system was electronically isolated from the others around it. Each was unable to exchange data except through direct human intervention. Standardization first occurred within each service and is now extending across the services and into allied systems.

2.1 Messages

The most basic characteristic of information is the ability to communicate it in an understandable form. Messages generated at one source must be correctly understood by a number of recipients. The Joint Interoperability of Tactical Command and Control Systems (JINTACCS) program is one of the most successful programs at creating standard messages which can be understood by humans and read by computers. These standards dictate the "punctuation" of the message, eliminating the military message equivalents of sentence fragments, run-on sentences, and mis-abbreviation. JINTACCS messages are recognizable by their abundant use of the "/" character as a punctuation symbol.

The United States Message Text Format (USMTF) organizes JINTACCS by defining a set of standard messages. The information contained in these creates the equivalent of "sentences" for military topics. These are grouped together to make "paragraphs" which describe all of the information that may be known about an enemy unit or that may be needed to serve a friendly unit. Multiple paragraphs can be placed in single message to allow the exchange of specific information on a large number of battlefield entities.

2.2 Network

Standard messages require a standard messaging system to transmit them between a variety of equipment types. In 1994, the proof-of-concept for the Global Command and Control System was fielded. This allowed computers from many locations to exchange data by both "pushing" it to other systems and "pulling" it from systems, creating the seeds for a globally distributed set of data that is completely accessible from anywhere in the world. The system allows other computers to join the network through the use of Common Operating Environment (COE) standards and components. By adhering to the COE standards or reusing the COE components, any C4I system can join the command network and exchange data with systems already resident on the network. The COE standards describe how systems must interact with each other, similar to the Internet protocols which allow a network to span the world without stumbling on the barriers of language, telephone line, computer architecture, and electric power differences.

2.3 Operations

The Command and Control Reference Model (C2RM) is an attempt to further standardize military communications by creating a standard taxonomy that describes all events and states in military operations, particularly command and control (Figure 2). The C2RM standardizes the phases of combat and the types of activities that are occurring in each of these phases. It formulates the steps through which all decisions are made and when information should be exchanged.

Figure 2. C2 Operations Standard

2.4 International

The International Command and Control Systems Interoperability Project (IC2 SIP) is attempting to extend interoperability beyond US systems into those of our allies in Germany and France. Between different countries there are the barriers of language, message format, and computer architecture which make combined operations in Iraq, Somalia, and Bosnia very difficult. Assuming that the content of military operations and communications is similar, this project converts messages from one country into the language and format of another. The messages being translated are very data intensive and contain little "free text", as a result the system is less a language translator than a data reformatter.

IC2 SIP uses a concept like Inter-lingua for data description, a language to which any other language can be translated and from which any language can be synthesized. This allows an "Appliqué" message in US Variable Message Format to pass through a decomposition template, be converted into the common data format, fed into a composition template, and reformatted as a French "SIR" or German "GeFuSys" message (Figure 3).

Figure 3. International C4I Interoperability

3 BRIDGING THE GAP

Constant standardization has created an optimistic atmosphere in which military program managers expect to join all combat computer systems - be they command and control, maintenance, or simulation. As these interfaces develop, it is clear that the method for computer translation and communication is quite similar to that used in interpersonal interfaces. The liberal insertion of translators, templates, and bounding of expression make the computers seem less magical than one might have hoped, but they are performing tasks for which humans have yet to develop concise, efficient methods in any domain - computer, spoken, or written.

3.1 Special Cases

The excitement for interoperability between simulations and command and control computers is based upon the operational success of dedicated interfaces in use today (Figure 4). These include the ability of the Tactical Simulation System (TACSIM) to generate intelligence reports about a synthetic battlefield and transmit them directly into intelligence processing systems using the USMTF messages described above. The Warrior, All Source Analysis System (ASAS), Enhanced Tactical Users Terminal (ETUT), and Enhanced Processing and Dissemination System (EPDS) are all used by intelligence analysts to manage and process reports on enemy activities and TACSIM can feed the same reports to these systems during training exercises. This allows the analysts to work with simulated data in the same form, quantity, and with the same interface that he/she uses in a real conflict.

Figure 4. Current Simulation-C4I Interfaces

The Corps Battle Simulation (CBS) has also been able to create interfaces with the Maneuver Control System/Phoenix (MCS/P) and Advanced Field Artillery Tactical Data System (AFATDS) computers. A commander can enter firing orders and plans into the AFATDS system and transmit these into the simulation rather than to real-world artillery systems. He may also receive force status information from CBS through the simulation/C4I interfaces. In both cases the orders can be read, acted upon, simulated, and the results disseminated without requiring the intervention or translation of a human operator. These efficiencies reduce the man-power and the time required to prepare for training exercises.

Similarly, the Air Warfare Simulation (AWSIM) has been extended to accept Air Tasking Orders (ATOs) from the Contingency Theater Automated Planning System (CTAPS). This allows Air Force commanders to prepare daily mission orders in their combat system and send it directly to the simulation. Personnel do not have to be trained to understand the simulation interface and order syntax, a skill that is not useful to combat soldiers.

Each of these interfaces is a dedicated instance which can not easily be extended to other systems. But the concepts are being converted to standard architectures and formats in both the simulation and command and control arena. Future simulation systems are being designed to interface with the training audience purely through their native computer systems.

3.2 Design Standards

The Warfighter Simulation 2000 (WARSIM 2000), currently under development, must reduce the man-power required to operate an exercise by 33% in the near-term and 67% long-term. Much of this savings is being accomplished by interfacing the simulation with the training audience through their native equipment, eliminating a layer of "role players" that currently translate real-world orders into simulation orders and simulation reports into real-world reports. These "role players" make up a significant number of training personnel during an exercise and are usually extracted from the training audience, missing the opportunity to practice their skills. WARSIM will interface with the following communications systems: Enhanced Position Locating and Reporting System (EPLRS), Single Channel Ground and Airborne Radio System (SINCGARS), and the Mobile Subscriber Equipment (MSE), providing connectivity to a host of information processors for maneuver, artillery, logistics, air defense, and intelligence operations.

The Air Force's National Air and Space Warfare Model (NASM) is being designed to operate in a similar manner, achieving the same savings, and providing the same training improvements. It will exchange orders, reports, and plans through a host of real combat systems, such as the Contingency Theater Automated Planning System (CTAPS), Joint Deployable Intelligence Support System (JDISS), Special Operations Forces Planning and Rehearsal System (SOFPARS), and Tactical Data Information Link (TADIL).

The Navy's Battle Force Tactical Trainer (BFTT) has opted for a slightly different interface to accomplish the same objectives. The Joint Military Command and Information System (JMCIS) is a system and messaging standard for many command and control systems and BFTT will participate in that network as if it were a real command node. All data will be exchanged through the JMCIS standard and the differences between simulation and command systems will be obscured.

4 DOMAIN SPECIFIC INTERFACES

To accomplish the type of interoperability that has been discussed above it is essential that standards emerge and be used in both the simulation and combat computer arenas.

4.1 Simulation Architectures

The first experiments in simulation interoperability relied upon dedicated interfaces between two simulations and were followed by standards designed to support the functionality necessary to share a synthetic battlefield. This same transformation is beginning to occur with regard to interfaces between simulations and C4I systems. The next generation of training simulations are pushing for seamless interfaces to C4I systems and they plan to accomplish this by creating dedicated interfaces directly from the simulation to the C4I systems (Figure 5). This provides connectivity to C4I systems only through a specific host simulation. To support generic interoperability the interface to the C4I system must be through a standard protocol which can be accessed directly by any simulation adhering to the standard.

Figure 5. New Simulation-C4I Interfaces

To create simulation interoperability the High Level Architecture uses the Runtime Infrastructure (RTI), allowing applications on a variety of host computers to access a standard set of services for exchanging data with other applications connected to it. Extending this bridging technique will allow any simulation to access any C4I system through standard RTI services. The Defense Modeling and Simulation Office (DMSO) is developing the Modular Reconfigurable C4I Interface (MRCI) to serve as a common gateway application to C4I systems architectures (Figure 6). It will operate as an RTI member and support the exchange of information between compliant simulations and C4I systems. However, the design calls for the integration of simulation specific software into the real C4I systems which is a significant limitation to the ability to implement and scale the solution.

Figure 6. MRCI Interfaces

4.2 C4I Architectures

Within the C4I community, the standard emerging most prominently is the Global Command and Control System (GCCS), of which the Joint Military Command and Information System (JMCIS) is an instance. Once interfaces are built for these standards the simulation community will be able to access any of the processing, communication, analysis, and decision support systems operating on these networks. As computerized combat systems continue to grow they will adhere to the GCCS standard and interoperabilty with simulation systems will be achieved without special consideration.

4.3 Bridging Architecture

The final step would be to replace the MRCI with a more general, non-intrusive gateway that joins the simulation and the C4I standard protocols. New simulations will not be required to understand C4I specific services, but rather, a single interface will provide the bridging mechanism for connecting to all RTI compliant simulations.

Similarly, the Joint Simulation Systems (JSIMS) project proposes a single architecture for all command staff trainers. Within this architecture there exists a component which specifically models the physical performance of pieces of equipment. This component also supports the surrogate representation (ghosting) of real-world equipment. This capability specifically targeted at the ability for a simulation to communicate with internal models with out having to differentiate between real equipment and simulated equipment. The methods required to export or import a message across the simulation-C4I boundary are encapsulated in the equipment component, allowing the simulation and the C4I system to operate naturally without special consideration for the receiving equipment. This begins to support the identification of a non-intrusive bridge between the two domains which understands both communication standards, but does not interfere with the operations of systems in either world (Figure 7). Such a Simulation-C4I Gateway could serve any simulation adhering to the RTI and any C4I system adhering to the COE. Remote systems on both sides could join the exercise without having to be configured for participation.

Figure 7. Bridging Two Architectures

5 CROSS DOMAIN ARCHITECTURES

Though the military is going to great lengths to join simulations and C4I systems, in the future, simulation capability may be built directly into real-world C4I systems. The current trend to provide decision support capabilities to commanders through their C4I systems is already placing simulation-like capabilities within their combat systems. A joint simulation-C4I architecture could allow the creation of a system from the pieces needed for their mission (real or training), whether they come from a simulation or tactical source.

Creating a cross domain architecture will require a joint requirements analysis process to identify the commonality between simulations and C4I systems. This must be followed by a process of requirements alignment in which similar, but not identical requirements, are matched and a system designed to meet both of them, or to modify them into a common requirement. From this set of requirements a common simulation-C4I architecture can be developed. It must be able to accommodate both the simulation and C4I specific requirements in order to serve both communities. Finally, the internal and external interfaces, be they simulation or C4I, must be defined.

6 CONCLUSION

There are more similarities between simulation systems and combat systems than there are differences. If we focus on these similarities we will find opportunities for integration and cooperation that are not immediately evident otherwise. In both cases, the user of the system is a soldier who is trying to do his/her job or improve his/her ability to do that job. Realizing that the user is one-in-the-same soldier leads to a design, development, and procurement approach between systems that is common and tends to support interoperability rather than thwart it.

Simulations have had a measurable effect on the military's ability to perform effectively in combat. A joint architecture will begin closing the temporal gap between training events and performance events. As simulations become an integral part of the battlefield it will be possible to conduct just-in-time training for contingencies or fine nuances which were not predicted and planned for in earlier training. For this to occur simulations must become part of the military table of organization and equipment (TOE), they must become a go-to-war system.

REFERENCES

Allen, Gary and Smith, Roger. 1994. TACSIM: Intelligence Training for Tomorrow's Battlefield. Military Intelligence Professional Bulletin. Fort Huachuca, Arizona.

Ben-Natan, Ron. 1995. CORBA: A Guide to Common Object Request Broker Architecture. McGraw Hill. New York, NY.

Dahmann, Judith and Jefferson, Mark. 1996. The Modular Reconfigurable C4I Interface. Summary Report - 14th Workshop on Standards for the Interoperability of Distributed Simulations. Institute for Simulation and Training. Orlando, FL.

Defense Modeling and Simulation Office. 1996. High Level Architecture - Object Model Templates. DMSO. Alexandria, VA.

Defense Modeling and Simulation Office. 1995. Department of Defense High Level Architecture for Modeling and Simulation, Version 0.2. DMSO. Alexandria, VA.

Defense Modeling and Simulation Office. 1995. HLA Management Plan: High Level Architecture for Modeling and Simulation. DMSO. Alexandria, VA.

Joint Simulation System Project Office. 1996. JSIMS Domain Specific Software Architecture. http://www.jsims.mil/lfs_dssa.html.

Joint Simulation System Project Office. 1996. JSIMS Architecture Implementation Plan. http://www.jsims.mil/lfs_aip.html.

McGarry, Stephen. 1995. The DoD High Level Architecture (HLA) Run-Time Infrastructure (RTI) and Its Relationship to Distributed Simulation. Summary Report - 13th Workshop on Standards for the Interoperability of Distributed Simulations. Institute for Simulation and Training. Orlando, FL.

Mowbray, Thomas J. and Zahavi, Ron. 1995. The Essential CORBA: System Integration Using Distributed Objects. John Wiley & Sons Inc. New York, New York.

Smith, Roger D. 1995. The Conflict Between Heterogeneous Simulations and Interoperability. Proceedings of the 1995 Interservice / Industry Training Systems and Education Conference. Albuquerque, NM.

Smith, Roger D. 1996. Proceedings of the Electronic Conference on Interoperability in Training Simulation. Mystech Associates. Falls Church, VA.

Tiernan, Tom. 1996. Modular Reconfigurable C4I Interface Program Plan. DMSO Briefing. http://www.dmso.mil/projects/hla/mrci/.

US Army Communications-Electronics Command. 1996. International Interoperability Today: The International Command and Control Systems Interoperability Project. Unpublished Document. Fort Monmouth, New Jersey.

US Army Communications-Electronics Command. 1996. The Command and Control Reference Model for Modeling, Simulations, and Technology Applications. Fort Monmouth, New Jersey.

US Army Command and Control Systems. 1993. Army Tactical Command and Control System Message Catalog. ACCS-A3-500-004. Fort Monmouth, New Jersey.

US Army Command and Control Systems. 1994. Army Tactical Command and Control System Specification. ACCS-A1-100-006A. Fort Monmouth, New Jersey.

Wilson, Annette L. and Weatherly, Richard M. 1994. The Aggregate Level Simulation Protocol: An Evolving System. Proceedings of the 1994 Winter Simulation Conference. Orlando, Florida.

AUTHOR BIOGRAPHY

ROGER D. SMITH is the Chief Simulation Scientist and a Corporate Technical Director for Mystech Associates. He is actively involved in designing, developing, and fielding simulations, having contributed to JSIMS, WARSIM, BLRSI, ADST, TACSIM, AWSIM, ALBAM, and others. He is very active in the simulation community serving as the Vice Chairman for the ACM Special Interest Group on Simulation, the General Chairman for the Electronic Conferences on Training Simulation, and as a member of the editorial boards of ACM Transactions on Modeling and Computer Simulation and the International Journal of Computer Simulation, Modeling, and Analysis. His research interests include embedded simulations in operational equipment, integrated simulation-C4I systems, and problems in aggregation/disaggregation.