The Interoperability Of Military Simulation Systems In An AUSCANNZUKUS1 Context David Wilton Australian Defence Science and Technology Organisation [email protected]

Abstract. This paper discusses the interoperability of military simulation systems in an AUSCANNZUKUS context. It reviews the current state of simulation system interoperability efforts in international forums such as the CCEB and ABCA Armies, and in the US DoD. The generic requirements for simulation systems to interoperate with other simulations and C4I systems are discussed, and some “candidate” interoperability standards are reviewed.

Simulation has recently been recognised as a cost- 1. INTRODUCTION effective means of training, both for individual The US DoD and NATO define interoperability as: warfighters and collectively for organisations such as “The ability of systems, units or forces to provide headquarters. It also has potential to aid command and services to and accept services from other systems, control decision-making. The US DoD now has an units or forces, and to use the services so exchanged extensive “battle lab” infrastructure which integrates to enable them to operate effectively together” different forms of simulation, and is able to meet a variety of requirements, including training, command An alternative US DoD definition is: and control decision support, and operational analysis “The condition achieved among communications- (to model the effects of new organisations or weapon electronics systems or items of communications- systems). electronics equipment when information and There is a recent initiative within the Combined services can be exchanged directly and satisfactorily Communications Electronics Board (CCEB) to extend between them and/or their users. The degree of these facilities to the other AUSCANNZUKUS interoperability should be defined when referring to members in a Combined Federated Battle Lab (CFBL) specific cases" [1] [2], to allow combined training and other types of trials Both these definitions are similar, in that they include and experimentation using modelling and simulation. If the systems aspects of interoperability. However, the these opportunities are to be realised, there will be a first definition is broader and higher level, in that it need for the simulation systems of the participating encapsulates the high-level “business” aspects of nations to be interoperable. To date, there has been interoperability. For example, there is little point in little visible effort within the AUSCANNZUKUS having interoperable communications systems if they forums to achieve this. This paper will review the semantic meaning of the information passed is different current state of work within the AUSCANNZUKUS to for the forces at either end of a link. One benefit of the achieve interoperability, with particular emphasis on latter definition, however, is the implication of the case- simulation, and examine the generic requirements for by-case nature of interoperability requirements. simulation systems to interoperate. The need for interoperability between command, control, communications and intelligence (C3I) systems 2. AIM of Allies participating in military operations has long The aim of this paper is to review the current state of been recognised. The first AUSCANNZUKUS forum interoperability of military simulation systems of the to promote interoperability was the US-UK Combined AUSCANNZUKUS allies, and to discuss the Communications Board (CCB), which was formed requirements for simulation systems to interoperate. during World War 2, to promote interoperability Some “candidate” interoperability standards are also between the telecommunications systems of those two reviewed. Allies. Since that time, many forums have arisen, to promote both single Service and Joint interoperability. 3. INTEROPERABILITY FORUMS, Despite rapid advances in information technology, C3I INITIATIVES AND CURRENT SITUATION interoperability is reasonably well catered for. This section of the paper will discuss the However, there has been little or no effort to promote interoperability efforts of some of the interoperability between simulation systems of Allies. AUSCANNZUKUS forums and the US DoD, with regard to interoperability of simulation systems.

1 The combined military forces of Australia, Canada, New Zealand, United Kingdom and United States 3.1 CCEB Armies developed an Interoperability Technical The CCEB evolved from the original World War 2 Architecture (ITA) during the period 1995-98. CCB. Its mission is to coordinate all C3I issues referred However, this effort has been discontinued, as it was to it by member nations. The CCEB also has the considered that it had been superseded by the CITA. following sub-goals: Like the CITA, the ITA did not contain any standards for simulation. • Conducting liaison with AUSCANNZUKUS single service forums, namely the AUSCANNZUKUS However, simulation system interoperability is Navies C3 Board, the ABCA Armies Program, the addressed elsewhere within the ABCA program. The Air Standards Co-ordination Committee (ASCC) program contains a Quadripartite Working Group and The Technical Co-operation Program (TTCP – (QWG) Armies Operational Research (AOR), which is the AUSCANNZUKUS Defence Science co- charged with ensuring that the simulation systems of the operation program) and member Armies are able to interoperate. The approach taken has been to standardise on a particular simulation • Conducting liaison with regional defence system – JANUS – for ABCA training and operational organisations, such as NATO, to promote wider analysis (OA) use. There are two Quadripartite Allied interoperability; recently with particular Standardisation Agreements (QSTAGs) which deal with emphasis on coalition operations. simulation system interoperability: A key CCEB interoperability initiative of the last five • QSTAG 1139 Common Version of the JANUS years has been the Combined Interoperability Technical Wargame within ABCA Armies. The master list of Architecture (CITA), ACP 140, and its accompanying QSTAGs [4] has a note to the effect: “To be CITA Rationale and Development Framework (CRDF) cancelled … with effect from Feb 99. The latest [3]. The purpose and scope of the CRDF are described version of JANUS is available and US have as follows: committed to provide update.” “The purpose of the document is to explain in a • QSTAG 1144 Representative Terrain Database for logical, step-by-step manner, the process used to Common Use in Combat Models by ABCA Armies develop a technical architecture that will meet the with Particular Emphasis on JANUS. interoperability needs of the CCEB nations. … There are many IT services that could contribute to The cancellation of QSTAG 1139 does not imply that interoperability among CCEB nation CIS; each is a JANUS has been discontinued as the ABCA standard, candidate for inclusion within the CITA (i.e. for but rather that a common version will be adopted. CCEB-wide standardisation). A set of scoping There are two recent versions of JANUS available from principles has been agreed to govern which of these the US – Version 7.0 developed for use by the regular candidate services should in fact be included within Army, and the SIMITAR version for use by the the CITA at this stage. These principles take into National Guard. [5] It is not clear which version has account the scale of the requirement for the service, been adopted by the ABCA. the availability of suitable standards, the feasibility of employing a standard CCEB-wide, and the costs 3.3 US DoD Joint Technical Architecture (JTA) and risks of CCEB-wide standardisation in The JTA [6] is a US DoD IT technical architecture comparison to more local arrangements for meeting which specifies IT standards in much more detail than the same interoperability requirement.” [3, pp. vi-v] the CITA, because one of its objectives is to ensure cost 2 That is, the approach taken is to specify standards only effectiveness of national development programs . The for those categories where it is necessary to achieve JTA does have a Modelling and Simulation Domain international interoperability. Areas such as desktop Annex, which deals with simulation system standards. operating systems and human-computer interface are The Annex refers to the US DoD Modelling and not specified as combined standards, as that would Simulation (M&S) Master Plan (1992 version, now unnecessarily constraint nations’ developers, for little or superseded by [7]), which includes the following as one no combined interoperability benefit. of its objectives, and corresponding sub-objectives: It is noted that the CITA does not contain any standards • OBJECTIVE 1. Provide a common technical for simulation systems – presumably because the framework for M&S. operational requirement for simulation systems to • Sub-Objective 1-1. Establish a common high- interoperate has yet to be recognised. level simulation architecture to facilitate the interoperability of all types of simulations among 3.2 ABCA Armies themselves and with C4I systems, as well as to The American (US), British, Canadian and Australian facilitate the reuse of M&S components. Armies Program is a single Service AUSCANNZUKUS forum, of which NZ is only an associate member. 2 Details of the forum can be found at [4]. The ABCA For example, if DoD-wide HCI standards are adopted, there is a potential saving in development and user training costs

• Sub-Objective 1-2. Develop conceptual models operate on local, rather than global, data. That is, of the mission space (CMMS) to provide a they do not operate in a distributed fashion. common starting point for constructing • Level A (Universal). At this level, information is consistent and authoritative M&S shared globally through distributed information representations, and to facilitate interoperability architecture. Applications can operate in a truly and reuse of simulation components. distributed fashion. • Sub-Objective 1-3. Establish data standards to [8] also defines a model of the functional components support common representations of data in of information systems which must all be interoperable models and simulations. to the required level: policy and procedures, functions Interoperability is obviously a key objective of the (applications), data and infrastructure (including M&S Master Plan. The standards mandated by the JTA communications networks). M&S Domain Annex include: the High level 4.1.2 CCEB CITA Levels of Interoperability Architecture (HLA), Federation Execution Details Data Interchange Format (FEDDIF) version 1.3, Object The CCEB CITA [3, pp. 74-6] uses a three-layer model Model Template Data Interchange Format (OMTDIF) of interoperability levels, which may be summarised as version 1.3, and MIL-STD-1821 Standard Simulator follows: Database Interchange Format (SIF) Change 2 February • Level 1 compliant systems can read and write files 1996. The Synthetic Environment Data Representation in the formats cited; transfer is either manual (e.g. and Interchange Format (SEDRIS) is listed as an floppy disk) or through dedicated links. “emerging standard”. HLA and SEDRIS are described later in the paper. • Level 2 compliant systems should be able to connect to a CCEB Intranet and perform web 4. LEVELS OF INTEROPERABILITY AND access, email, and formal messaging. Level 1 and ARCHITECTURAL REQUIREMENTS FOR 2 together broadly equate to NATO level 4 SIMULATION SYSTEMS TO INTEROPERATE interconnection. This section will address, in broad terms, the • Level 3 compliant systems involve remote database requirements for simulation systems to interoperate. access, distributed computing, object interfaces and object middleware if relevant. Also database to 4.1 Levels of Interoperability database replication, collaborative computing and special applications. Level 3 compliance is not Rather than “interoperability” being a purely binary fully satisfied by the current CITA specification but function (ie, Systems A and B can either interoperate or may fall within the emerging CITA. Level 1, 2 and not interoperate), there are various levels at which 3 together broadly equate to NATO level 5 interoperability can be achieved. This section of the interconnection. paper describes two models that define levels of interoperability. The author is also familiar with the There is no obvious level for simulation system five-layer interoperability model used by NATO; interoperability in either the LISI or CITA models. however because this is similar in concept to the LISI However, it is considered that simulation systems model and it is not in use in the AUSCANNZUKUS would need to operate in a distributed fashion, and arena, it will not be covered in this paper. therefore would be required to be at LISI level A or CITA level 3. 4.1.1 LISI Model The Levels of Information System Interoperability 4.2 Architectural Requirements (LISI) model originated from the US DoD C4ISR In order for two information systems to interoperate, it Integration Task Force. [8] The LISI model contains is necessary to define the broad areas of business four layers of interoperability: functionality which they are required to share, or • Level D (Basic). Level D is defined as the ability exchange, in order to “… provide services to and accept to support simple file exchanges between systems services from [the] other system” [1] as well as providing users with a basic Ressler et al in [9] describe the construction of a collaboration capability (eg e-mail, chat). conceptual reference model for the US Army, designed • Level C (Intermediate). At Level C, systems to cover the interconnection of simulation and C4ISR must be able to exchange and process complex file systems, and which may also be applicable to formats that can be categorised as heterogeneous simulation systems only. The model is abstract only, products, eg maps annotated with graphical and does not propose a technical architecture or any overlays. standards. It is based on four generic classes of information required to be exchanged between systems. • Level B (Advanced). This level describes systems which are interconnected but which generally The authors state that the model “can be used to assess the presence of standards for interoperability. One can

look horizontally across the model to see if each activity performance, and they do not accurately describe is covered and vertically within activities to assess the interoperability or explain what causes depth of standards within a given activity or interoperability performance to vary … both the information type”. [9] C4I systems and M&S communities need a single, There does not appear to be any other generic reference consistent measure of interoperability performance model for the interoperability of simulation systems, … a descriptive model of interoperability is also apart from the HLA, which is a specific architecture needed to explain how interoperability works.” [10, rather than a reference model. (The HLA will be p. 7] described in the next section of the paper). 5. CANDIDATE STANDARDS FOR 4.3 Generic Requirements for Simulation SIMULATION SYSTEM INTEROPERABILITY System Interoperability Despite the lack of clear requirements for Neither of the generic levels-of-interoperability models combined/coalition interoperability levels and described in Section 4.1 above appear to be directly architectures, there are some existing US standards that related to simulation systems. That is, it is unclear as to appear to be prime candidates for any international what level of interoperability is required for such simulation interoperability effort. These are described systems. Sutton [10] claims to have identified a in this section of the paper. number of deficiencies of the LISI model when applied to simulation systems, and proposes an alternative – 5.1 Distributed Interactive Simulation (DIS) Causal – model. Some of his claims could be disputed [11], [12] (for example, he states that the LISI model does not The Distributed Interactive Simulation (DIS) protocol address the issue of compatible objects and object originated as a communications protocol developed in models of different simulations, whereas this could the 1980s by the US Defense Advanced Research clearly be considered under the heading of Data). Projects Agency (DARPA) to network together tank Sutton also emphasises the top-down, “business”-level training simulators. The DIS standard emerged in the requirements of interoperability and notes some early 1990s. DIS is a networking standard that provides deficiencies of HLA as an interoperability standard: a method of communicating entity state and other “ … the focus of interoperability must be on ‘end- information between heterogeneous simulations on the to-end’ interoperability, that is from one C4I same physical communications network (either wide - Warrior (decision-maker) to another. … Two or local - area network). State information is different simulations may comply with some level of communicated by formatted messages known as the HLA but they can still remain uninteroperable protocol data units (PDUs). PDU types include: … Black and Harris reported that … three-node, six- appearance and movement of entities, weapons firing, federate tests … running under HLA RTI 1.3-2 detonation of ordnance, collision detection and resulted in some runs in which federates crashed or logistical resupply. lost as many as 100 attributes, and occasional high DIS has become an open standard now sponsored by interaction latency between one and eight seconds.” the IEEE - the latest version of which is IEEE 1278.1a - [10, p. 2] 1998. This version has 67 PDU types with additional The ABCA Armies view the “one C4I Warrior to support for voice radio and tactical data links, mine another” aspect as operational interoperability, and it is warfare and the environment. considered to be as critical a requirement as technical DIS is a relatively simple standard, and provides a interoperability, which relates to the ability to exchange reasonably effective method of enabling cooperation raw data between systems. between heterogeneous simulations. However, it has There appears to be a grey area as to what constitutes some significant disadvantages, including: necessary and sufficient conditions for simulation • The fact that DIS is now an international de jure systems to interoperate, at both the operational and standard means that changes to it are a complex technical levels, and whether these conditions can be process and require a long time to gain agreement. defined for a general case, or need to be considered on a case-by-case basis. This is exacerbated when • DIS is not a particularly efficient standard, from a considering international interoperability, where bandwidth viewpoint, due to the broadcast mode of pressures to completely standardise application operation and the fact that PDUs contain redundant environments do not exist, and there could be a large information. number of disparate legacy systems to accommodate. • Compliance with the standard provides no This is an area that should be the subject of further guarantee of operational interoperability. DIS is research. As stated by Sutton: basically a communications protocol and provides “Existing models of interoperability do not provide no high level architecture or mechanism for consistent, objective measures of interoperability

interoperability, such as rationalising the semantic • An object model template specification, which meaning of entities. describes the format for object models. DIS is not considered to be a suitable standard for Each federate must have an associated simulation object interoperability of AUSCANNZUKUS simulation model (SOM) and each federation a federation object systems; however, it may be required to be maintained model (FOM), developed in accordance with the object as a legacy standard in the short term, for applications model template specification. It is not feasible to create such as JANUS. a universal object model, and therefore the HLA cannot be considered as a universal interoperability tool or 5.2 HLA [7], [13] standard. Federations need to be created on a case-by- case basis, consistent with the basic purpose and goals The HLA is a methodology designed to support the of the distributed simulation(s). interaction of heterogeneous simulations. It is mandated by the US DoD in both the JTA and the M&S The HLA is an architecture, or in other words, a Master Plan. [6], [7] The key objective of the HLA is conceptual approach to ensure simulations can interact. as stated previously in this paper: It is not an application or specification in itself. Associated with the HLA is an RTI, which is a software “Establish a common high-level simulation implementation, available from the Internet. The RTI is architecture to facilitate the interoperability of all designed to provide an infrastructure, including types of simulations among themselves and with C4I communications protocols and services, to support systems, as well as to facilitate the reuse of M&S operations of a federation execution. components. “ [7, Chapter 4] The HLA is also in the process of being coordinated as Relevant US DoD policy with respect to the HLA is as an international standard by the IEEE - Standard 1516. follows: As in the case of DIS, this could tend to impede the “The evolution of the HLA will be managed by the standardisation process; however, the fact that the HLA DoD Executive Council for Modelling and allows user communities to create their own federations Simulation (EXCIMS) through its Architecture should prevent grid-lock caused by a standards body. Management Group (AMG). This structure The HLA has several advantages over DIS, including: provides a means for the DoD Components to identify and address any emergent issues in • More efficient use of bandwidth. subsequent refinements to the HLA. Compliance • It provides much greater flexibility, in its ability to with the HLA does not mandate the use of any allow the tailoring of federations for specific particular implementation of supporting software purposes. such as the run time infrastructure. … The Department shall cease further development or Ryan and Zalcman [12], however, note that the greater modification of all simulations which have not flexibility can also be a disadvantage: unless all achieved, or are not in the process of achieving, federates agree on a FOM, they will not be able to HLA-compliance by the first day of FY 1999, and interoperate, even though they are HLA-compliant. shall retire any non-compliant simulations by the To ensure operational interoperability between first day of FY 2001.” [14] heterogeneous simulations, there must be the ability to The HLA is based on a premise that no single exchange metadata on entity and other high level simulation can satisfy the requirements of all users. information and to interpret its semantic meaning in a Sub- goals are, therefore, to provide for simulation consistent manner. There must also be a common, or reuse (by tailoring an existing simulation for other interoperable, infrastructure to facilitate technical applications, rather than developing a new simulation) interoperability. Within HLA, the FOMs facilitate and interoperability between simulations. consistent interpretation and the RTI provides an infrastructure to exchange data. In theory, this should In the HLA, simulations are known as federates and a be sufficient to ensure interoperability within a given set of cooperating simulations is known as a federation. federation. Note, however, Sutton’s comment at Prototype federations have been developed in the areas Section 4.3 above: “Two different simulations may of operational and tactical level training, analysis and comply with some level of the HLA but they can still engineering. remain uninteroperable.” [10, p.2] The necessary and There are three parts to the HLA: sufficient conditions for simulation system interoperability need to be clarified. • A set of ten HLA rules which govern how federates and a federation can behave, 5.3 SEDRIS [15] • An interface specification (rules for how federates communicate with the run time infrastructure - Common representation of the physical environment is RTI) and a key requirement for interoperability between simulation systems. The level of interoperability achieved depends heavily upon the degree of

consistency, completeness and non-ambiguity of • Spatial Reference Model. The SRM fully defines environmental data. No uniform and effective standard the specification of coordinates, datums, mechanism previously existed for describing, reusing, projections, and a variety of geo- and non-geo- and interchanging environmental data among simulation referenced spatial reference systems as used in applications. Additionally, data sharing rarely occurs SEDRIS interchange. between the operational and simulation communities, • Tools and Utilities. A set of software tools and although each community requires representations of utilities, based on the SEDRIS Interface the same real world entities. Specification, have been developed to aid in The SEDRIS Project is a research and development viewing elements of a SEDRIS transmittal. effort focused on providing a per-run time interchange SEDRIS primarily provides a transmittal, rather than mechanism supporting the distribution of source data, storage, format. It can handle a whole range of terrain three-dimensional models and integrated databases that (including surface type and trafficability), ocean, describe the physical environment for both simulation atmosphere (including weather and obscuration) and and operational use. The capability to share common space data, as well as phenomenology, such as weapons descriptions of the physical environment through a effects and electromagnetic emissions. [16] standard interface is a precondition for interoperability. The progress estimate given in [15], as at June 1999, The objectives of the SEDRIS project are as follows: was for all deliverables to be available by December • Articulate and capture the complete set of data 1999. However, it is not clear as to whether or not this elements and associated relationships needed to was achieved. fully represent the physical environment. • Support the full range of simulation applications 6. CONCLUSIONS (e.g., computer-generated forces; manned, visual Until comparatively recently, the military C3I and M&S and sensor systems) across all environmental communities maintained a wide separation from one domains (terrain, ocean, atmosphere and space). another. There was no perceived need to integrate • Provide a standard interchange mechanism to pre- systems or to agree on interoperability standards. The distribute environmental data and promote database emergence, however, of integration between both reuse and interoperability among heterogeneous classes of system to provide functionality such as simulations. command and control decision support and mission planning and rehearsal, has resulted in a pressing need The deliverables are as follows: for interoperability. The US has recognised this need in • A common data representation model and the M&S Master Plan and Joint Technical Architecture associated data dictionary. The data model will (the JTA not yet, apparently acknowledging the need to remove ambiguity by ensuring that all types of integrate C3I and simulation systems). However, the environmental data are captured and relationships recognition is yet to reach the AUSCANNZUKUS between alternate representations (e.g., feature nations. The current CCEB CITA takes neither versus geometry) are defined. simulation systems interoperability, nor the need to integrate C3I and simulation systems, into account. • Interface Specification. Provides a consistent interface between a user’s (either a data provider or Neither of the interoperability levels models reviewed a data consumer) application and SEDRIS in this paper (LISI and CCEB CITA) appears to be transmittals. The API decouples the user’s formulated with simulation systems in mind. Also, application from the transmittal’s data structures, there does not appear to be a widely accepted reference allowing the SEDRIS data model, its transmittal model on which to base interoperability standards mechanism-specific data structures, and the user’s decisions, particularly in defining the minimum application to evolve relatively independently of standards necessary to obtain interoperability in a each other. combined force or coalition environment. There appears to be a need for further work in this area. • SEDRIS Transmittal Format (STF). The STF provides a platform independent data interchange The US HLA and SEDRIS standards appear to be prime format for SEDRIS transmittals. It is a file format candidates for adoption by the AUSCANNZUKUS that defines the organisation of a persistent nations. DIS may have utility as a legacy standard, but SEDRIS format. is considered to be too limited in terms of its functionality and performance to be adopted on a • Data Coding Standard. The SEDRIS Project has medium- or long-term basis. developed a classification, attribute, and state data- coding standard. This allows enumeration to be separated from the data model and data dictionary REFERENCES for greater flexibility and extensibility. [1] US Joint Publication 1-02, Dictionary of Military and Associated Terms. URL

http://www.dtic.mil/doctrine/jel/doddict/data/i/032 33.html. [2] Joint Warrior Interoperability Demonstration Joint Project Office, US Defense Information Systems Agency and Joint Battle Center (1999) Tactics, Techniques and Procedures for the Combined Federated Battle Laboratories Network. [3] CCEB Publication No. 1007 (1999) CITA Rationale and Development Framework. Issue 1.0. [4] American, British, Canadian and Australian Armies’ Standardisation Program Home Page, URL http://www.abca-armies-program.org/. [5] US Army Simulation, Training and Instrumentation Command (STRICOM) home page, URL http://www.stricom.army.mil/. [6] US DOD Joint Technical Architecture (1999), Version 3.0, URL http://www-jta.itsi.disa.mil/ [7] US DoD, Modelling and Simulation Master Plan, October 1995, URL http://www.dmso.mil/documents/policy/msmp/ind ex.html. [8] US DoD C4ISR Integration Task Force (1996) Levels of Information System Interoperability. [9] Ressler, R.L., Hieb, M.R. and Sudnikovich, W. (1999) “M&S/C4ISR Conceptual Reference Model”, Proceedings of Simulation Interoperability Workshop (SIW), Fall 1999. [10] Sutton, Paul W. (1999) “Interoperability: A New Paradigm”, Proceedings of SIW, Spring 1999. [11] Neyland, Lieutenant Colonel (Retired) David L. (1997) Virtual Combat: A Guide to Distributed Interactive Simulation, Stackpole, Mechanicsburg Pa. [12] Ryan, P. and Zalcman, L. (1999) “The DIS vs HLA Debate: What’s in it for Australia?”, Proceedings of Advanced Simulation Technology and Training (SimTecT) Conference. [13] US Defense Modelling and Simulation Office (DMSO), HLA Home Page, URL http://www.dmso.mil/portals/hla.html. [14] US Under Secretary for Defense Acquisition and Technology, Memo dated September 10 1996, URL http://www.dmso.mil/documents/policy/usdat_hla. html. [15] DMSO, SEDRIS Home Page, URL http://www.dmso.mil/portals/sedris.html. [16] Phillips, Major M. and Grose, Captain R. (1999) “Military Geographic Information (MGI) – A Question of Standardisation and Application”, Proceedings of SimTecT.