Developing Battle Management Language into a Web ... - CiteSeerX

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 1 of 14

Developing Battle Management Language into a Web Service

Michael R. Hieb, Ph.D. Alion S &T 1901 N. Beauregard St. Alexandria, VA 22311-1705 (703) 933-3376 [email protected] William P. Sudnikovich Atlantic Consulting Services, Inc. 167 Avenue at the Common Shrewsbury, NJ 07702 (732) 460-9416 [email protected]

Andreas Tolk, Ph.D. VMASC Old Dominion University Norfolk, VA 23529 (757) 686-6203 [email protected]

J. Mark Pullen, D.Sc. George Mason University Computer Science/C3I MS4A5 George Mason University Fairfax, VA 22030 (703) 993-1538 [email protected]

Keywords: Battle Management Language (BML), Extensible Modeling and Simulation Framework (XMSF), Command and Control Simulation Interface Language (CCSIL), Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR), Army Battle Command Systems (ABCS), Joint Common Data Base (JCDB), Command and Control Information Exchange Data Model (C2IEDM ABSTRACT: Battle Management Language (BML) is the unambiguous language used to: 1) command and control forces and equipment conducting military operations and, 2) provide for situational awareness and a shared, common operational picture. It can be seen as a standard representation of a digitized commanders intent to be used for real troops, for simulated troops, and for future robotic forces. BML is particularly relevant in a network centric environment for enabling mutual understanding. A prototypical implementation of a Battle Management Language was developed and demonstrated at the beginning of 2003. While the first prototype was U.S. Army centric, an initiative \ under the Extensible M&S Framework (XMSF) is transforming the BML prototype into a Joint and Coalition solution based on open standards. The initial prototype demonstrates a Web enabled or Extensible Battle Management Language (XBML) “extended” by applying the concepts of the XMSF. This paper concentrates on showing in detail, how XMSF standards were applied. The end state for XBML will be a methodology for developing standard doctrinal terms and allowing these to be accessed as Web services. In the future Global Information Grid (GIG), each Service could have its own ‘BML’ Web service, linked to a Joint overarching BML. In this paper we examine the following XBML issues. - Transforming proprietary interfaces to open standards (via the Extensible Markup Language (XML) and the Simple Object Access Protocol (SOAP)); - Developing Modeling and Simulation Web services that can be distributed via the Web; - Transforming existing data representations to international Joint standards (by using standardized Coalition data models such as the Command and Control Information Exchange Data Model (C2IEDM)); - Evaluating the applicability of XBML for Global Information Grid (GIG) Enterprise Services (GES).

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 2 of 14

1. Introduction

1.1 XMSF

A critical deficiency in current simulation systems is the lack of a standard methodology for representing Command and Control information. Many advanced simulations have excellent representations of command and control internal to their simulations, but do not use this representation when dealing with other simulations or Command and Control systems (here we define C2 systems as the range of planning to execution systems used in military operations). See [5,13,16] for related work in simulation C2 formats.

XMSF is a set of open standards, developed by existing standards bodies, and methodologies for their application to facilitate reuse, composability, and orchestrated execution of distributed and heterogeneous Modeling and Simulation (M&S) applications. Because it is based on Web standards, it has the ability to provide simulation services to a wide class of live systems. XMSF uses open standards to increase the efficiency of development and applicability of simulation systems. Many software systems that composably scale to worldwide scope utilize Internet and Web technologies. XMSF, by applying these Web-based technologies, is an advance toward composable simulation systems and is a viable technical platform to integrate live systems, such as C4ISR systems.

Battle Management Language (BML) was developed to close this gap by contributing to the development of a common standard to represent military tasks, actions and missions, both in simulations and C2 systems [4,5]. A proof of principle of this was developed in the domain of ground forces (for a US Army Mechanized Brigade) [19]. BML will allow a commander to develop a plan and exchange data with other organizations – the commander’s subordinates, his superiors and his equals. BML can be interpreted as the digitized commanders intent, which is interpretable by command and control systems and executable by simulation systems. Typically, a federation of simulation systems will be employed to support the mission planning systems for training or operations. In addition, the systems involved can be highly aggregated (such as a joint logistics system tracking movement of assets or a large joint simulation system) or very detailed (platform specific systems). The challenge for BML is to provide a common methodology, a common syntax and semantics. However, each nation and service will have different tasks unique to itself, and BML must be flexible enough to accommodate them. Extensible Battle Management Language builds on the experience of the US Army proof of principle implementation by using internet standards to develop web-enabled interfaces. However, while internet standards are a tremendous aid to developing flexible interfaces (addressing BML methodology and syntax), they do not address the issue of common semantics. XBML uses the Command and Control Information Exchange Data Model in order to establish a common representation for tasks, actions and missions. XBML represents mission in terms of Who, What, Where, When, Why as an organizing principle

Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) systems are of particular interest in composable simulations because they are the windows through which the warfighters see the world. There is a growing requirement to interface existing and emerging simulations to C4ISR systems. We believe that ultimately the best solution is to use the same underlying Information Technology (IT) infrastructure supporting M&S and C4ISR systems, facilitating the delivery of simulation services for operational applications as required. To do this, XMSF must be extended and integrated into emerging C4ISR systems and standards. Using XMSF to integrate simulations into C4ISR networks is discussed in [24, 25]. Software systems that composably scale to worldwide scope using Internet and Web technologies are strong candidates for use in composable simulations. XMSF is characterized by the application of open standards and open sources to increase the efficiency and applicability of distributed simulation systems. Therefore, XMSF is an evolutionary step toward advanced distributed simulation not necessarily limited to military standards. XMSF uses particular standards related to the Web, to reach the next level of this domain of distributed computing. By embracing commercial Web technologies as a sharedcommunications platform and a ubiquitous-delivery framework, military M&S can fully leverage mainstream practices for enterprise-wide software development. Its focus on open, Web-based standards and technologies doesn’t imply that XMSF is limited to the public Internet; it can just as well operate on secure military networks. Two of these Web-based standards play a particular role in XBML:

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 3 of 14

•

•

The Extensible Markup Language (XML) is designed to improve the functionality of the Web by providing more flexible and adaptable information identification. It is a standardized file format on the basis of the Standard Generalized Markup Language (SGML) and became a wide spread standard for Web applications within the last couple of months.

BML

Simulation

The Simple Object Access Protocol (SOAP) is a protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol to let applications exchange information over the Hyper Text Transfer Protocol (HTTP), which is supported by all Internet browsers and servers.

Agreeing on a common tag set of underlying XML documents is the first step allowing unambiguous information exchange on the semantic level of interoperability. This tag set then can be used to define SOAP message content to be exchanged between these applications via the Internet or a Web-based military network supporting the minimal set of Internet standards and may later be used for semantically meaningful web service definition. Although in complementing papers the need for additional standards to insure meaningful interoperability is stressed [22, 23], this level is sufficient for XBML applications and the initialization of C4I systems by M&S applications, as we are limited to data exchange and initialization problems, hence we do not have to care about the orchestration of agile components acting in a common environments, as it is the case in distributed simulation systems. 1.2 BML Definition While XMSF ensures the integration and migration of components on a technical level, BML is the foundation for a methodology for complete and unambiguous specifications of the commander’s intend. Taking the widest possible interpretation, BML is defined [4, 5] as follows: BML is the unambiguous language used to command and control forces and equipment conducting military operations and to provide for situational awareness and a shared, common operational picture. Along with this definition, there are four principles that are fundamental to BML: 1) BML must be unambiguous; 2) BML must not constrain the full expression of a commander’s intent;

C4I

C4I

Robotic Forces Figure 1: BML Scope 3) BML must use the existing C4ISR data representations when possible; and 4) BML must allow all elements to communicate information pertaining to themselves, their mission and their environment in order to create situational awareness and a shared, common operational picture. Clearly, principles 1 and 2 are difficult to reconcile, but necessary. Principle 3 is one that is often ignored or slighted. However, if a “new” representation is to be developed, then it will still have to be “translated” into the organic C4ISR infrastructure. Thus, many advanced and flexible planning representations, while very well suited to BML, are not appropriate, due to integration difficulties. BML must contain no distinction between live or simulated forces ensuring that commanders and staff can train as they fight. They use the same BML whether they are dealing with live subordinates, a simulation, or a semi-autonomous robotic entity (Figure 1).

1.3 Roadmap to Rest of Paper The remainder of this paper is organized as follows: Section 2 describes BML and the BML application developed by the US Army. Section 3 describes how the Army BML applications were transformed into XBML using XMSF standards. Section 4 describes future plans for XBML activities and future plans; and Section 5 concludes.

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 4 of 14

2. BML Concept BML is more than a well-structured language. In its complete expression, BML must be a methodology that allows complete and unambiguous specification of C2 information, directly linked to doctrine. The methodology must represent doctrine, identify appropriate doctrinal sources, elaborate doctrine into a standardized authoritative representation, and specify the rules for how the representation communicates information

Data/Object Models

Messages

Tactical C4ISR Data Model

XML/ Data Replication

Doctrinal Manuals

BML

Figure 2: BML Concept

To accomplish this, the BML must incorporate doctrinal terms, graphics, tactics, etc. in a form that allows the intricate relationships of these abstract concepts to be linked to the physical aspects of the warfighter’s environment (organizations, features, persons, facilities, and materiel). The representation must include the necessary entities along with well-defined relationships. This then allows the basic vocabulary, semantics and syntax to be unambiguously defined as well as related to each other in a methodology. This implies developing structured message formats that can be parsed into existing and future operational messages as well as formats that communicate with simulations.

Service

Joint

International

BML must blend structure that allows automation of the language, and ease of use for the military professional. It should not be a radical change from the language the commander and staff currently use, but instead an evolution that provides a means to gain structure while remaining transparent to the user. It must be based on doctrine and linked to the doctrinal sources, both to ensure standard use/understanding, and to foster concise and precise use of the language. The technology components of BML must support the “train as you fight” concept and therefore exist in a single format, at least as far as the military professional user is concerned. The output of the automated system is dependent on whether the intended audience is a human, a software “intelligent agent” or a autonomous robot. This is an abstract concept of what BML should be. However, we need to further specify how BML, once developed, could be implemented in an actual C4ISR system. Note that at this point, we are still defining what a BML is and what the

Doctrine

specification of its syntax and semantics will be. However we need to do this with an awareness of how it will be used to ensure it is capable of being implemented. BML is being built based upon work that has gone before, EAGLE BML and CCSIL [6, 16, 17]. Figure 2 shows graphically our BML implementation concept. This consists of: • A C4ISR Database (used by a C4ISR application). BML must be imbedded and integrated into the C4ISR Database. • A Doctrine Repository, with doctrine accessible to the C4ISR application. The more strongly the BML terms are tied to how live forces are trained and employed will enable how well BML will perform. • A technology to disseminate BML terms from the Doctrine Repository and a technology for exchanging BML messages.

XML/ Data Replication

Coalition Data Model

XML/ Data Replication

Joint Data Model

XML/ Data Replication

Service Data Model

NATO Doctrine

BML

Joint Doctrine

BML

BML

Figure 3: BML Methodology

Service Doctrine

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 5 of 14

This paper covers the technology and representation points identified above. XMSF provides the best technology solution at this time as shown in this paper. However, the aspects of BML related to Doctrine are not covered here. In many cases, it is difficult for Simulations to identify one authoritative doctrine source (ironically, it is often possible to identify many sources, however they invariably overlap each other). Figure 3 shows the scope of the BML methodology. This paper shows how BML can be extended from a service specific implementation (Army using specific interfaces) to an approach linking coalition, joint and service elements. It is important to note that there may be different BML “dialects”. A populated BML for the Army will be different from a populated BML for the Air Force due to the difference in how they employ their forces. But the way that a BML language is constructed must be standard so BML information can be exchanged and understood. A key aspect of BML is that with the vocabulary and its associated relationships built into a database, Graphical User Interfaces (GUI) and other applications can be constructed that allow implementation of BML. Several advantages result from this approach. • Building the vocabulary into the database focuses on the semantic level and leaves room for alternative implementations on the lower levels of interoperability, such as using Internet technologies utilizing XML tag sets. • The terms, as they are used in messages, can be linked to their doctrinal definitions to assist users (senders and receivers) in understanding the precise intent of the author. This can be extremely helpful in those areas where a term has multiple definitions or there are subtle differences in the meanings of different terms. • As efforts continue to align the data models between simulations and C4ISR systems, this approach, since it involves building BML into the JCDB, will lead to better alignment/adoption of a single BML for both domains. • Ensuring that the database includes the graphics as well as the terms will assist in transitioning from course of action development and analysis tools linked to the database to producing the operations order. It enables this as either an auto fill of structured formatted messages, or as a GUI-based representation of the current situation and operational objectives.

3. Transforming BML into XBML The transformation of the Army BML prototype to a Joint, Combined XMSF BML prototype is conducted in phases. As the XMSF project looked at BML, it was fairly straightforward to determine which XMSF standards would be applied first, in order to “open up” the interfaces. Follow-on phases include the migration of the database used for the MSDB, the integration of additional functionality by new components, and extending the semantics of the BML vocabulary. In this section we describe what was done in Phase 1 of XBML, conducted in 2003. In the following section we describe the future phases of XBML, which are currently under development or which will be done in the near future. 3.1 Army BML Proof of Principle (PoP) The actual BML Demonstrator comprises the following elements as shown in Figure 4: • To generate orders, the Combined Arms Planning and Execution System (CAPES) is used. This is a prototype US Army Planning System. This C4ISR component creates operational orders (OpOrds) that are exchanged using a proprietary tagged XML document [2]. • A Multi Source Data Base (MSDB) is based on the U.S. Army Standard data model of the Joint Common Data Base (JCDB), which has been extended by the BML development team by introducing over 100 new tables and relations. It is accessed via standardized database manipulation statements based on ODBC or JCDB. It is implemented in open source software of the Linux environment. • A BML Demonstrator specific XML-BML Parser reads the information from the XML document and generates data manipulation statements. The XMLBML Parser reads the XML document, maps the information to data elements of the Multi Source Data Base (MSDB), and inserts the information contained in the document into the MSDB. • A BML Graphical User Interface (BML-GUI) allows data manipulation of the content of the MSDB under consideration of the semantic and syntactic constraints of the BML. The input of CAPES can be used as a basis to create more detailed operational orders for the subordinated units (which are simulated using the OTB simulation system). • The MSDB information is based on the U.S. Army doctrinal language. In order to execute such orders, this information has to be mapped from doctrinal terms to OTB interpretable terms. This is done by the C4I Simulation Interface (C4ISI), which reads the MSDB and generates order files for OTB.

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 6 of 14

BML GUI

OTB

XML Parser

MSDB

C4ISI

CAPES

Figure 4: Army BML Proof of Principle •

Finally, the M&S component OneSAF Test Bed (OTB) system is used to simulate the effect of the generated orders. It reads the order generated by C4ISI and executes them respectively.

Figure 4 shows a simplified version of the US Army BML PoP demonstration. Note that each element of the PoP communicates with the MSDB in a different manner, using unique interfaces and protocols. Also the components must be physically resident on a local network. The BML PoP is more fully described in [19] It is worth mentioning that the Army BML prototype focused on the application. Its objective was to proof that an unambiguous definition based on Army doctrine is possible (by defining the BML vocabulary), that C4ISR data can be used as a hub (by extending the JCDB), and that an application can support C4I as well as M&S

components (by coupling with CAPES and OTB). The following sections will deal with the migration of BML to the XMSF environment to ensure that BML is embedded into a commercially viable and commercially supported IT infrastructure (technical level) and that the Army prototype can by semantically extended to be applied for other services and nations (semantic level). Figure 5 shows the results of the first phase of XBML. Each of the interfaces between the components comprising the original Army BML Proof of Principle (PoP) demonstration environment were investigated to determine approaches to incorporate open, Web-based methods to implement the interfaces to conform with the principles of XMSF. As indicated earlier, two Web-based standards that were chosen to implement the interfaces to

BML GUI SOAP MSDB Data

MSDB Updates

SOAP Data for OTB

OTB

U S D O P A P

XML document

JDBC Interface S O A P

ODBC

C4ISI

ODBC

MSDB

XML Parser

Figure 5: XBML Testbed – Phase 1

S O A P

S O CAPES A P

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 7 of 14

construct the XBML prototype were XML and SOAP. XML was used to provide a standard way to structure the data passed between the components. SOAP was used to package the ODBC and JDBC calls to the MSDB database. SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. A SOAP message is constructed from a number of elements. The first of these is called the envelope and is used to describe the basics of the SOAP message such as the content and how to process the message. The second part consists of the rules about custom data types. The ability to create custom data types, a feature also of XML, is an important characteristic of SOAP lending to its ability to support extensibility. The last part describes the application of the envelope and the data encoding rules for representing the Remote Procedure Call (RPC) calls and responses, including the use of HTTP as the underlying transport. The plan output from the CAPES application was already constructed in an XML format. The CAPES XML plan however, was in a format developed earlier in the CAPES program and did not conform to the BML schema. A parser was written for the Army PoP demonstration that mapped the CAPES XML plan format into the BML schema and used Open Data Base Connectivity (ODBC) functions to store the data in the MSDB. The XBML project uses this parser to accomplish the mapping between attribute tags for the construction of the BML but implements a SOAP transport mechanism between CAPES and the MSDB. For the BML PoP the interface between the BML GUI and the MSDB was implemented using standard PostgreSQL JDBC (Java DataBase Connectivity) drivers to communicate with the MSDB. To bring this interface into conformance with the XMSF concepts a SOAP-based version of the JDBC driver was developed. The SOAPbased driver works in much the same way as a standard JDBC driver. It implements the standard java interfaces that any JDBC driver would implement. The main difference is how the driver works. A standard JDBC driver would accept the API calls then use its own proprietary transport protocol and API to access the database directly. The SOAP-based driver that was developed is split into two pieces. On the client side is the JDBC driver, this is the class called by the BML GUI and looks like any other JDBC driver. The second part is the JDBC web service that resides on the same machine as the database being accessed and is never directly called by the client. The web service uses the standard PostgreSQL driver to communicate with the database. It takes the information returned by the PostgreSQL driver, turns it into an XML document and sends it back to the

client via SOAP. The client code turns the XML document back into objects that are then accessed via the normal JDBC API. This approach was chosen for a number of reasons. First, it allowed us to make the BML GUI SOAP-based without actually having to modify any of the original GUI code, only new code to implement the SOAP elements had to be constructed. Second, this same driver could be re-used by any Java application to access a database accessible via the Internet. In fact, by using the JDBC-ODBC bridge driver provided by Sun Microsystems in the web service, we could now make any database accessible via an ODBC driver, accessible over the Internet via our SOAPbased JDBC driver. The C4ISI reads BML data from the MSDB and generates order files for OTB. In the PoP demonstration, ODBC was used to access the MSDB to get the BML information necessary for generating the tasking orders to send to OTB. The C4ISI creates messages to send to OTB to create friendly and enemy units, place those units on a battlefield, create battlefield features, and create friendly unit activities. The C4ISI sends these messages using the standard User Datagram Protocol (UDP) network interface that is commonly used with OTB. Since OTB could not be modified to use SOAP in place of UDP, a Java and a C++ module were created to run on the same machine as OTB that implemented an interface to SOAP while maintaining the UDP network interface. The C4ISI Core was modified with two Java modules that implemented an interface to SOAP, a C++ module that gets the data from the plan object and gives it to a Java module, and a C++ module that gets the data from a Java module and sends it to OTB via UDP. The Java Native Interface (JNI) was used to invoke the interactions between the C++ and Java code modules. The results of Phase 1 were demonstrated at the Interservice/Industry Training, Simulation and Education Conference (I/ITSEC). Figure 6 shows the demonstration configuration, which had 3 nodes, two at I/ITSEC at the Orlando Conference Center and one node at George Mason University in Fairfax Virginia. The nodes at I/ITSEC were physically on the I/ITSEC network and communicated to the GMU node through the commercial Internet. All of the nodes accessed one MSDB located at the XMSF booth at I/ITSEC. The NEW-V component was a Web-based whiteboard/conferencing application. The implementation of XML and SOAP in accordance with XMSF principles among the components of the BML demonstration environment allowed seamless, distributed and remote execution of each of the components. The demonstrations conducted during the I/ITSEC laid the groundwork for extending the XMSF

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 8 of 14

I/ITSEC Orlando, Florida

OTB CAPES GUI NEW-V

OTB CAPES GUI NEW-V

INTERNET

OTB CAPES GUI NEW-V

MSDB XMSF Booth

GMU Fairfax,Virginia

JFCOM / VMASC Booth

Figure 6: I/ITSEC XMBL Demo Configuration concepts to meet the challenges of future tactical Command and Control requirements.

XBML XML tagset based on the C2IEDM. The Testbed will still be using Army data, but it will demonstrate the applicability of the C2IEDM to handle “simulation” data (in the form of executable missions, tasks and actions).

3.2 Development of an XBML Testbed The first phase of XBML was relatively straightforward, and set the stage for the following stages, which increasing focus on the semantic aspects of developing an extensible BML. Work has been performed in Phase 1 to map the MSDB BML tables to the NATO Standard C2 Data Model – the C2IEDM. Phase 2, shown in Figure 7 moves the basis of the MSDB to the C2IEDM. This takes the PoP from an Army basis to a Joint/Coalition basis, in keeping with the XBML project goals. Along with this comes a standard

Figure 8 shows Phase 3 of XBML, also currently being worked on. This incorporates additional simulations and C4ISR systems. This is essential to prove the extensibility of XBML. This will also address how BML is used in both a Joint and Service concept, as the initial OPORD will be Joint, not Army. The MSDB will be populated with a slice of Joint tasks (based upon the Universal Joint Task List), as well as the Army tasks.

BML GUI XMSF

OneSAF TB

XMSF

Multi Source DB

XMSF

Based on the LC2IEDM

Figure 7: XBML Testbed – Phase 2

CAPES

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 9 of 14

BML GUI OneSAF TB

JSAF

XMSF XMSF

XMSF

XMSF

Multi Source DB

XMSF

GCCS/ Planning App

CAPES

Figure 8: XBML Testbed – Phase 3 The result of Phase 3 will be a testbed that other organizations can “plug” into on a component basis to test C4ISR to Simulation interoperability concepts. Phase 3 will also test the ability of BML to represent a graphical OPORD. Initial applications implementing the BML will be text based, but linked to graphics. A BML application of the operations order for instance would probably look very much like the current 5 paragraph operations order, however with much more structure applied to the five paragraphs. The structure orients on the 5 Ws (Who, What, When, Where, and Why) plus the required synchronization and coordination information. Structuring the order is a combination of automatic postings based on links to the higher headquarters’ order, the approved COA sketch and statement, and the associated synchronization matrix, and drop-down menus based on the relationship of unit type and echelon to operations, missions and tasks.

Figure 9 shows the objective final state of the XBML C4ISR to Simulation Interoperability testbed.

4. Using the C2IEDM in XBML This section will describe the C2IEDM, explain why it is relevant for use in Modeling and Simulation interoperability, and detail how the C2IEDM standard can be integrated into XBML. 4.1 Why the C2IEDM? It is almost impossible to imagine a situation in the future when a single U. S. Service will be unilaterally employed. Because future military operations, and a significant amount of training, will be Joint in nature, it is critical that a Joint Service approach be taken to the BML

BML GUI Service Joint Simulation

Service Simulation

Joint XMSF

XMSF

XMSF

XMSF

Multi Source DB

XMSF

Figure 9: XBML Testbed – Objective Endstate

Joint Planning App

Service Planning App

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 10 of 14

ACTION-OBJECTIVE

ACTION

ACTION-id (FK) ACTION-OBJECTIVE-index ACTION-OBJECTIVEcategory-code

WHAT ACTION-TASK-id (FK)

ACTION-id

WHY

ACTION-category-code ACTION-name

ACTION-TASK -minimum-duration ACTION-TASK -maximum-duration ACTION-TASK -estimated-duration ACTION-TASK -planned-start-date ACTION-TASK -planned-end-date ACTION-TASK -planned-start-time ACTION-TASK -planned-end-time

ACTION-category-code ACTION-TASK ACTION-EVENT ORGANISATION-TYPE ORGANISATION-TYPE-id

ORGANISATION-ACTION-ASSOCIATION ORGANISATION-id (FK) ACTION-id (FK) ORGANISATION-ACTION-ASSOCIATION-index

ORGANISATION-TYPE -category-code

ORGANISATION-ACTION-ASSOCIATION -category-code ORGANISATION-ACTION-ASSOCIATION -effective-date ORGANISATION-ACTION-ASSOCIATION -effective-time ORGANISATION-ACTION-ASSOCIATION -intent-text

ORGANISATION WHO

ORGANISATION-TYPECATEGORY-CODE

WHEN

ORGANISATION-id (FK) ORGANISATION -category-code ORGANISATION -nickname-name ORGANISATION -type-id (FK)

UNIT-TYPE POST-TYPE

MATERIAL-POINT UNIT-TYPE UNIT-TYPE-id (FK) UNIT-TYPE -category-code UNIT-TYPE -mobility-code UNIT-TYPE -service-code UNIT-TYPE -size-code (echelon)

ORGANIZATION-POINT

FEATURE-LOCATION

FACILITY-LOCATION

PERSON-POINT

LOCATION WHERE LOCATION-id LOCATION -category-code

Figure 10: Nominal Subset of C2IEDM Tables showing the 5 Ws development effort. The same issues that have driven the Army to embark on this program also confront the other Services as they develop both their C4ISR and simulation systems. A BML, as described in this paper, developed and applied by the other Services and by coalition members would not only allow interoperability among their C4ISR systems and simulations, but also among themselves. The C2IEDM itself has been proven to be applicable for the domain of common data management by the NATO Data Administration Group (NDAG) and the domain of information exchanged by the Multilateral Interoperability Program (MIP) in the joint and combined context of C4ISR. Former studies also showed the general applicability of the C2IEDM for common data management of M&S systems [26]. We therefore believe that the approach chosen is feasible and a long-term success. However, in order to achieve this goal, rigorous definitions of the BML itself as well as how to apply and extend the C2IEDM are necessary. Just as the Army BML PoP implemented the 5Ws within the JCDB, Figure 10 shows a nominal example of them within the C2IEDM. We believe that the same concept for developing BML for the U. S. Army will also work for

the other Services, Joint and Combined/Coalition operations (see Figure 3) [4]. To create the Army BML we described an approach of: • Incorporating the doctrinal base into the Joint Common Data Base (JCDB), • Building in the vocabulary as contained in FM 101-51 [7], Operational Terms and Graphics (future FM 102) as data tables, and • Building in the syntax and semantics as defined through the AUTL, ARTEP-MTP and the other related Field Manuals for use of the items specific to echelon and type units as relationships between data tables. Expanding this approach to other Services and the Joint level would involve • Incorporating the individual Services and Joint doctrinal base into the C2IEDM. • Expanding the vocabulary from the FM 101-5-1 (future FM 1-02) to Joint Publication 1-02, Department of Defense Dictionary of Military and Associated Terms, as well as any Service specific dictionaries. • Expanding the syntax and semantics as defined through the UJTL, CJCSM 3500.04B, and Joint Doctrinal manuals; as well as each Service’s task list (Universal Naval Task List (UNTL), OPNAVINST

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 11 of 14

3500.38/MCO 3500.26/USCG COMDTINST M3500.1; Air Force Task List (AFTL), Air Force Doctrine Document 1-1) and their respective doctrinal manuals. Expanding it to a coalition such as NATO would be more challenging but follow the same paradigm: • Incorporating NATO doctrine into the C2IEDM. • Expanding the vocabulary to include Alliance Administrative Publication – 6 (AAP-6), NATO Glossary of Terms and Definitions (English and French) [1] • Perhaps most challenging would be identifying/expanding the syntax and semantics since it does not appear that a NATO equivalent of the UJTL or ARTEP exists. 4.2 Steps to bring the C2IEDM into XBML As described in Section 3.2, the XBML test bed is being developed in phases. The same is true as the C2IEDM is introduced as the ontological kernel for an extensible Battle Management. While the C2IEDM is a tremendous advance in describing a standard semantics for Command and Control, there are several challenges to using it with M&S models. The first of these is to identify where M&S data currently exchanged fits within the C2IEDM. It is likely that many simulation systems will not fulfill the requirements of the C2IEDM without special adjustments and developments, The correct mapping to the C2IEDM needs to be identified, but will not be sufficient, as that mapping will probably involve identifying several different tables which have to be associated correctly in order to keep the information together as needed by the simulation system. However, Wartick et al. have preformed a detailed mapping of the C2IEDM to the Joint Simulation System (JSIMS) Federation Object Model [27] and they have performed several other mappings to C4I models and have developed a general methodology [26], which demonstrates the general feasibility of the approach. Also, the German C2SimProxy used the ATCCIS replication mechanism to exchange data between the German C4I system HEROS and the M&S system KORA based on C2IEDM mappings [13]. The C2IEDM can be seen to have three levels of semantic entities: •

Associated concepts are semantic entities in which data is given in a context. Within C2IEDM, these can be mapped to replication domain sets. This is the minimum set of tables necessary to maintain referential integrity. All of the tables in a set have to be sent from one instance of C2IEDM to another

•

•

instance, in order that the data will make sense to the military user (one example would be an operations order). In XML, these are XML documents satisfying an XML schema. Propertied concepts are a collection of specifying characteristics for an entity in the domain of knowledge. In C2IEDM and other ontologies using data models to structure its information, these can be mapped to table and its attributes. In XML, these are the collection of XML tag sets. Property values are the allowed values for a specifying characteristic. Of particular interest are enumerations, such as the category codes and the category sub-codes in the C2IEDM. In XML, these are the allowed values within the documents.

Why is this important in the context of mapping to the C2IEDM? A single piece of data is not meaningful in the C2IEDM unless it has the necessary “associated” data. In C2IEDM terms, there is a need to maintain referential integrity. On a more practical level, this means that it may be necessary to fill several tables in order to form a replication domain set. However, one approach we are investigating with XBML for mapping M&S data to the C2IEDM is: • Starting the mapping processes on the property value level. If the models are of comparable resolution, the property values are likely to be comparable also. In the M&S domain, these assumption holds for data models used at various levels of resolution as well. If two simulation systems simulate on the entity level, it is likely that they can exchange attributes of their simulated platforms. However, if the models differ in resolution it is not only possible, but likely that the attributes of the lower resolution model can be associates or propertied concepts in the higher resolution model. (Example: while the tank is a propertied concept in the high-resolution model, the number of tanks can be a property value of a tank unit in the low-resolution model). • The next step is a comparison of the principal semantic grouping of properties into propertied concepts. Even if the systems are identical in resolution, these groupings are likely to differ. While one system models a tank as the complete concept, another systems prefers to model the hull, the weapon, and the sensors as concepts and combine them via associations to the associated concept tank. • The associated concepts are linked at last. In most cases, they implement the data support for the business logic underlying the consuming business model. In C2IEDM every object-item has to have a corresponding report table, as in the C4ISR world information exchange is always associated with messages or reports, and they are associated with

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 12 of 14

when the report was generated. An area of investigation is whether these rules are necessary for exchanging M&S data. To summarize, we are developing a methodology for integrating components into the XBML test bed. The C2IEDM harmonization process will include: • Defining an interface using XML • Mapping an XML tag set to the C2IEDM tag set; if necessary, the C2IEDM will be enhanced or extended to cope with all properties and property values within the information exchange context; • The propertied and associated concepts of the information exchange context are mapped and extended to replication domain sets of the C2IEDM; • Gaps are reported back to the component developers • Extensions and enhancements of the C2IEDM are documented and reported to the national data managers for future inclusion into C2IEDM

5. Conclusion In summary, XMSF is a broad integration method based on open standards. BML is a collection of methods to capture C2 information in an unambiguous way. XBML is merges these two concepts in a powerful manner, There is a need for a unified BML methodology. BML is vital to achieve C4ISR to Simulation interoperability. It can also assist in achieving command and control interoperability within Joint and coalition environments acting as the true common language between humans, machines, Services and national militaries. BML will be interwoven with the common ontology of choice for the future Global Information Grid. The use of the international standard C2IEDM is a likely option, although no decisions have been made yet. With XBML we have demonstrated the capability of distributed, remote operation of web-enabled components. The concept of simulation applications implemented as Web services will support future network centric operational concepts. The Web based implementation facilitates the ‘smart-pull’ concept of information distribution as described in the DoD Net-Centric Data Strategy.

6. Acknowledgements The authors gratefully acknowledge and support given by the DMSO for the development of XMSF and XBML. BML was originally sponsored by the US Army SIMCI OIPT [18]. The XBML work is based upon a foundation of work done by the US Army and performed by LTC Ken Wilson, Martin Kleiner, Scott Carey and Richard Brown. The research work at VMASC was partially sponsored by General Dynamics – AIS.

7. References 1) Allied Administrative Publication – 6 (AAP-6) “NATO Glossary of Terms and Definitions (English and French)”, 2002, http://www.nato.int/docu/ stanag/aap006/aap6.htm 2) Agile Commander Advanced Technology Demonstration, June 2001, (http://www.c2d.c3sys. army.mil:443/agile.htm.) 3) Bendz, J., Johannisson, P., Ohland, G., Frank, A., Dahmann, J., Konwin, K., Lof, S. and Briggs, R., “Coalition Interoperability Through Standards-Based Collaborative Environments”, Paper 01F-SIW-053, 2001 Fall Simulation Interoperability Workshop, 2001. 4) Carey, S., Kleiner, M., Hieb, M.R. and Brown, R., “Standardizing Battle Management Language – Facilitating Coalition Interoperability”, Paper 02ESIW-005, 2002 European Simulation Interoperability Workshop, London, England, 2002. 5) Carey, S., Kleiner, M., Hieb, M.R. and Brown, R., “Standardizing Battle Management Language –A Vital Move Towards the Army Transformation”, Paper 01F-SIW-067, Fall Simulation Interoperability Workshop, 2001. 6) CCSIL Message Content Definitions, http://ms.ie.org/cfor/cfor.html#Documentation. 7) FM101-5 Staff Organization and Operations, Headquarters Department of the Army, 31 May 1997. (to be renumbered FM 5-0) 8) Haddix, F., Sheehan, J., Loesekann, M., and Scrudder, R. “Semantics and Syntax of Mission Space Models”, Paper 99F-SIW-152, Fall Simulation Interoperability Workshop, 1999. 9) Hieb, M.R., and Blalock, J., “Data Alignment Between Army C4I Databases and Army Simulations”, Paper 99S-SIW-034, Spring Simulation Interoperability Workshop, 1999. 10) Hieb, M.R., and Sprinkle, R., “Simulation Infrastructure for the DII COE Architecture: The Army Vision”, Paper 00F-SIW-035, 2000 Fall Simulation Interoperability Workshop, 2000.

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 13 of 14

11) Kleiner, M.S., Carey, S.A., and Beach, J., “Communicating Mission-Type Orders to Virtual Commanders”, Paper, Proceeding of the 1998 Winter Simulation Conference, December 1998. 12) May, G., briefing “NATO Doctrine Development”, Semi-Annual Army Doctrine Conference 14-15 November 2001, http://doctrine.army.mil/SAADC/ saadc2001briefings/natodoctrine.ppt. 13) Menzler, H.P., Tolk, A., Kuite, J., Weyrath, T.,, "Command and Control to Simulation Proxy Solution (C2SIM-Proxy) - Loose Coupling of Disparate Worlds", European Simulation Interoperability Workshop 2001, Paper 01E-SIW-062, London, June 2001 14) NATO Handbook, 2001, http://www.nato.int/ docu/handbook/2001/index.htm 15) NATO Logistics Handbook, 1997, http://www. nato.int/docu/logi-en/1997/lo-1701.htm 16) Ogren, J., and Fraka, M., “EAGLE Combat Model Battle Management Language (BML)”, Powerpoint presentation, BML Symposium at Fort Leavenworth, KS, 25 April 2001. (http://www.simci.org/ html/librsry.html Public Folder/Meetings/Architect Meetings/Battle Management Language/BML Symposium/Eagle Presentation). 17) Salisbury, M., “Command and Control Simulation Interface Language (CCSIL): Status Update” MITRE Informal Report, Twelfth Workshop on Standards for the Interoperability of Defense Simulations, 1995 (http://ms.ie.org/cfor/diswg9503/diswg9503.pdf) 18) SIMCI WWW Site, Army Overarching Integrated Product Team for Simulation to C4ISR Interoperability: http://www.simci.org, 2004. 19) Sudnikovich, W., Hieb, M.R., Kleiner, M. and Brown, R., “Developing the Army's Battle Management Language Prototype Environment”, Paper 04S-SIW-115, 2004 Spring Simulation Interoperability Workshop, Crystal City, VA, 2004. 20) Timian, D.H., Hicks, M.W., and Hieb, M.R., “An Approach for Using DII COE Components to Link Simulations and C4I Systems: A Case Study Using the CMP”,P aper 00F-SIW-011, 2000 Fall Simulation Interoperability Workshop, 2000. 21) Timian, D.H., Hieb, M.R., Lacetera, J., Tolk, A., Wertman, C., and Brandt, K., “Report Out of the C4I Study Group”, Paper 00F-SIW-005, 2000 Fall Simulation Interoperability Workshop, 2000. 22) Tolk, A., “Composable Mission Spaces and M&S Repositories - Applicability of Open Standards”, Paper 04S-SIW-009, 2004 Spring Simulation Interoperability Workshop, 2004. 23) Tolk, A. and Muguira, J., “The Levels of Conceptual Interoperability Model”, Paper 03F-SIW-007, 2003

Fall Simulation Interoperability Workshop, 2003. 24) Tolk, A. and Daly, J., “Modeling and Simulation Integration with Network-Centric Command and Control Architectures”, Paper 03F-SIW-121, 2003 Fall Simulation Interoperability Workshop, 2003. 25) Tolk, A. and Pullen, M., “Ideas for a Common Framework for Military M&S and C3I Systems”, Paper 03E-SIW-032, 2003 Euro Simulation Interoperability Workshop, 2003. 26) Wartik, S.P., Haugh, B.H., Loaiza, F. and Hieb, M.R. 2001 “A Methodology for Comparing C4I Data Models and Simulation Object Models”, Paper 01ESIW-059, 2001 Euro Simulation Interoperability Workshop, London, UK, June 2001. 27) Wartick, S.P., Haugh, B.A., Loaiza, F., and Hieb, M.R., “Building in Interoperability: A Comparison of C4I Data Models and Simulation Object Models”, Paper 01S-SIW-021, 2001 Spring Simulation Interoperability Workshop, 2001. 28) Zimmermann, B., “Integrated Army Modelling and Simulation Data Network”, MSG-022/SY-003/25 Conference on “C3I and M&S Interoperability” , Antalya, Turkey, October 2003 (published in RTOMP-123).

Author Biographies MICHAEL HIEB is a Vice President for C4I Programs for Alion Science and Technology. Dr. Hieb is currently an Architect for the Army SIMCI OIPT. He received his Ph.D. in Information Technology at George Mason University in 1996 and performed his doctoral research at the GMU Center for Excellence in C3I. Dr. Hieb received his MS degree in Engineering Management from George Washington University and his BS degree in Nuclear Engineering from the University of California in Santa Barbara. He has published over 50 papers in the areas of M&S integration with C4I and Machine Learning. Previously, he worked as a Nuclear Engineer for General Electric. ANDREAS TOLK is Senior Research Scientist at the Virginia Modeling Analysis and Simulation Center (VMASC) of the Old Dominion University (ODU) of Norfolk, Virginia. He has over 12 years of international experience in the field of Applied Military Operations Research and Modeling and Simulation of and for Command and Control Systems. In addition to his research work, he gives lectures in the Modeling and Simulation program of ODU. His domain of expertise is the integration of M&S functionality into related application domains, such as C4ISR or web-based services, in particular based on open standards.

Paper 04S-SIW-113 – Presented at the Spring 2004 SIW Page 14 of 14

WILLIAM P. SUDNIKOVICH is a Project Manager for Atlantic Consulting Services in Shrewsbury, NJ and a technical architect for the Army’s SIMCI OIPT. Prior to joining ACS in 2000, Mr. Sudnikovich held various technical and management positions with the US Army CECOM RDEC and was influential in establishing M&S activities there. He was an active contributor to the development of the IEEE 1278 DIS standards and is a former Chairperson of the C4I Forum of the SISO Simulation Interoperability Workshops. Mr. Sudnikovich holds BS and MS degrees in Computer Science from Rutgers University and Fairleigh Dickinson University. J. MARK PULLEN is Professor of Computer Science at George Mason University, where he heads the Networking and Simulation Laboratory in the C3I Center. He holds BSEE and MSEE degrees from West Virginia University, and the Doctor of Science in Computer Science from the George Washington University. He is a licensed Professional Engineer, Fellow of the IEEE, and Fellow of the ACM. Dr. Pullen teaches courses in computer networking and has active research in networking for distributed virtual simulation and networked multimedia tools for distance education.