Coalition BML Study Group Report - The Naval …blais/Documents/DRAFTCoalition... · Web viewCoalition - Battle Management Language Study Group Final Report Study Group Officers Co-Chair:

D R A F T

Simulation Interoperability Standards Organization

Coalition - Battle Management Language Study Group

Final Report

Study Group Officers

Co-Chair: Major Kevin Galvin

Co-Chair: Dr. Michael R. Hieb

Vice Chair: Dr. Andreas Tolk

Secretary: Charles D. Turnitsa

Editor: Curtis Blais

Date: 30 June 2005

Version 0.4

D R A F T1

D R A F T

CHANGE LOG

Version Date Editor Changes0.1 5/3/2005 Blais Initial rough draft for group review and document planning0.11 5/4/2005 Blais Rewrites from Per Gustavsson (2.1.9.3) and Eugene Joseph (March

working group meeting presentation summary)0.111 5/4/2005 Blais Added thoughts from Pierre Gauvin regarding development of a

task list grammar (section 3).0.12 5/5/2005 Blais Added input on ACSIS from Bruce Carlton (2.1.10); started adding

material to NPS response to C-BML project summary (2.1.11)0.2 5/28/2005 Blais Reorganized document content; completed material on relevant

NPS project work; rough material for BML background information, study group TOR, study group activities

0.21 5/31/2005 Blais Ontology Use Case inputs from Rob Wittman (pasted to the end of section 4 until the material is smoothly integrated)

0.22 6/2/2005 Blais Changed title of section 2 to Related Work0.23 6/10/2005 Blais Input from Andreas Tolk on the German SOKRATES program.0.3 6/17/2005 Blais Folded the 5/31 Rob Wittman ontology use case inputs into the

narrative of that section. Took an initial cut at describing the operational aspects of a use case for the ontology section (just described a hypothetical situation and began some discussion of the use of strong semantics in the information representations).

0.4 6/23/2005 Galvin Made changes to the Executive Summary, Main Body of the Report in particular the C-BML Plan (section 3) Added NATO ET-016, Project SINCE as related work and research conducted by UK (2.1.12 and 2.1.13) Added page numbering, new Ontology Annex to replace Section 4 – Section 4 now Product Description

D R A F T2

D R A F T

Executive Summary

Over a number of years considerable efforts have been made to develop mechanisms to provide interoperability between Command and Control (C2) systems and simulations. This was initially predominantly driven by the need to reduce the costs associated with inputting data into simulations that supported C2 training. The development of digitized C2 systems and the opportunity to utilize Modeling and Simulation (M&S) tools for Course of Action Analysis (COAA) and Mission Rehearsal and work on robotic forces has meant that there is an increased requirement for interoperability between these systems. In addition military operations are no longer conducted by single services and a single national force. It is increasingly joint down to the tactical level and likely to be conducted within a coalition or alliance such as NATO. This has led to a requirement for multinational interoperability and the development of standards in support of this. (This may need to expressed better but should provide background to interoperability efforts related to the problem)

The Simulation Interoperability Standards Organization (SISO) Standards Activity Committee (SAC) formally endorsed the establishment of a Study Group (SG) on Coalition Battle Management Language (C-BML) in September 2004. A set of Terms of Reference nominated the officers and provided a statement of work for the C-BML SG, identifying the following tasks:

The study group shall conduct a paper survey comprising as many international contributions applicable to the C-BML effort as possible.

The study group shall develop a plan of how these various efforts identified in task one can contribute to a common C-BML standard/standard framework.

The study group shall formulate a set of recommendations on how to proceed toward a C-BML Product Development Group (PDG).

The products resulting from the establishment and execution of these tasks include, but are not limited to:

A literature survey summarizing the results of the first task, and; A final report, to be delivered during the Simulation Interoperability Workshop

(SIW) Fall 2005, which summarizes the results of the second and third tasks.

An initial face-to-face meeting was held through March 7-9, 2005 and brought together 35 international experts. Five universities (Carnegie Mellon University, George Mason University (GMU), Naval Postgraduate School, Old Dominion University, and the University of Texas) participated in the event. Represented nations were Canada, France, Germany, Sweden, United Kingdom, and the United States. A well-attended meeting of the C-BML SG was held at the Spring SIW in San Diego on April 7, 2005. At that meeting, an overall schedule for conduct of the SG effort was proposed and approved.

In parallel to C-BML Study Group activities, the NATO Modeling and Simulation Group (NMSG) established a 12 month Exploratory Team 016 on C-BML. The team led by

D R A F T3

D R A F T

France held its first meeting in Paris on February 14-15, 2005 with 7 nations represented. It endorsed the requirement for a C-BML and has proposed that a 3-year Technical Activity Program should be established. Their recommendations will be submitted to a meeting of the NMSG in October 2005 in Poland and they anticipate using a C-BML specification developed by SISO.

In addition the SAC gave approval after the Spring 2005 SIW in San Diego for the establishment of a SG to examine the requirement for a Military Simulation Definition Language (MSDL). It is a separate but related activity to C-BML. Its primary purpose is to provide initialization to simulation systems independent of the simulation and scenario generation tools. The Co-Chair of C-BML SG was appointed the Vice-Chair of the MSDL SG to ensure that there was no duplication of effort.

The following recommendations are made:

SISO should establish a PDG in order to develop a C-BML standard; That a phased approach should be taken to the development of the standard; The PDG should be separate from a proposed MSDL PDG in the first phases but

as work on developing a Tasking Grammar matures these two efforts may be merged so that one standard is eventually derived that provides for the full scope of C-BML;

To establish engagement with C2 community to ensure joint ownership and development of the standard.

D R A F T4

D R A F T

Table of Contents

1 Introduction..............................................................................................................61.1 Battle Management Language..............................................................................71.1.1 BML – Doctrine View.........................................................................................71.1.2 BML – Representation View...............................................................................81.1.3 BML – Protocol View.......................................................................................101.1.4 Operational Need and Expected Benefits..........................................................101.1.5 Problem Definition and Identification of Risks in Use of C-BML...................101.2 C-BML Study Group Terms of Reference.........................................................111.3 C-BML Study Group Meetings..........................................................................111.4 Document Organization......................................................................................132 Related Work.........................................................................................................142.1 Projects...............................................................................................................142.1.1 Aide a la Planification d’Engagement Tactique (France)..................................142.1.2 Geospatial BML (US Army Engineer Research and Development Center).....152.1.3 ABACUS Architecture (Raytheon)...................................................................172.1.4 VMASC Battle Lab, Old Dominion University, Norfolk, Virginia, USA (Chuck Turnitsa) 182.1.5 EXPLAIN Project (North Side, Inc., Canada)...................................................192.1.6 IMASE Scenario Generation Tool (Paul Morley and Lisa Pereira)..................192.1.7 Formal Tasking Language Grammar (Rob Wittman).......................................202.1.8 Task Analysis Leading to BML Vocabulary.....................................................212.1.9 Identification of Need (Per Gustavsson, Ericsson, Sweden).............................222.1.10 Army C4ISR and Simulation Initialization System (Bruce Carlton, ARL/UT)242.1.11 XML-based Tactical Language Research (Naval Postgraduate School)...........282.1.12 SOKRATES (Germany - FGAN-FKIE)............................................................302.1.14 UK Research into BML..........................................................................................312.2 Relevant Publications (These should be a separate Annex which are referred to only in this paragraph).......................................................................................................313 Plan for C-BML Specification Development........................................................324 Product Description...............................................................................................345 Recommendations..................................................................................................38Appendix A........................................................................................................................40March 2005 C-BML Study Group Meeting Report..........................................................40Appendix B........................................................................................................................59SISO Product Nomination Form.......................................................................................59Appendix C........................................................................................................................64C-BML Study Group Participants.....................................................................................64References..........................................................................................................................66

D R A F T5

D R A F T

1 Introduction

The Simulation Interoperability Standards Organization (SISO) is responsible for the identification of applicable standards to support distributed simulation in all simulation domains and to develop standards in case no available standards are applicable to fulfill the community’s interoperability needs. These objectives are achieved by:

Presentations during the Simulation Interoperability Workshops (SIW);o Identifying requirements and respective interoperability gapso Exemplifying solution possibility in prototypeso Demonstrating applicability of standards

Evaluating interoperability domains in depth in Study Groups (SG) that;o Conduct surveys of the related domainso Develop plans on how to reach consensuso Identify potential solutions

Preparing standards in Product Development Groups (PDG).

Over a number of years, multiple papers at both SIW and in the Command and Control Research and Technology Symposiums (CCRTS) have dealt with the need for, and potential contributions to, interoperability in the domain of Command and Control (C2)-to-Modeling and Simulation (M&S) interoperability based on the use of unambiguous information exchange definitions. The concept of Battle Management Language (BML) was discussed during several workshops. BML was not a new concept and had its genus in Eagle BML and Command and Control Simulation Interface Language (CCSIL) (May need to expand here so that there is an audit trail to previous efforts)

During the Spring SIW 2004, a meeting of subject matter experts decided that there was considerable merit in taking the BML initiatives that had been carried out in the US Army and developing a Coalition BML (C-BML). As a result a statement of work was drafted and submitted to the SAC.

The establishment of C-BML SG was accepted by the SAC and the Terms of Reference (TOR) listed the following tasks:

The study group shall conduct a survey comprising as many international contributions applicable to the C-BML effort as possible.

The study group shall develop a plan of how these various efforts identified in task one can contribute to a common C-BML standard/standard framework.

The study group shall formulate a set of recommendations for a C-BML Product Development Group.

It stated that the products resulting from the establishment and execution of these tasks shall include, but one not limited to:

D R A F T6

D R A F T

A literature survey summarizing the results of the first task, and; A final report, to be delivered during the SIW Fall 2005, which

summarizes the results of the second and third tasks.

The Command, Control, Communication, Computers, and Intelligence (C4I) Forum is sponsoring this SG. In addition to its SISO membership, the SG collaborates with other organizations with potential interest in this work, in particular the North Atlantic Treaty Organization (NATO) and the Command and Control Research Technology Symposium (CCRTS) groups interested in this topic.

The C-BML Study Group formally began work at the Fall SIW 2004. It submitted an interim report at the 2005 Spring SIW, and completed work with submission of this final report to the EXCOM, SAC and CC at the 2005 Fall SIW. In addition to electronic collaboration facilitated by use of the SISO web site, interim meetings were held in conjunction with other M&S-related conferences during the period of performance.

1.1 Battle Management Language

Overview of BML (although the following is extracted from 05S-SIW-007 by Tolk/Blais as a starting point it needs to be written as part of the report and not appear as an extract that does not flow – the diagram showing the three views should be inserted at this point)

BML is defined as an unambiguous language to command and control forces and equipment conducting military operations and to provide for situational awareness and a shared, common operational picture. BML is being designed as a standard representation of a "digitized commander's intent" to be used for real troops, for simulated troops, and for future robotic forces.

BML has not yet been formally specified. A C-BML PDG will produce such a formal specification in Phase 1. So far, three views have been identified that must be included in such a definition: the doctrine view, the representation view, and the protocol view. We describe and discuss these three views in detail in the following subsections.

1.1.1 BML – Doctrine View

Every term used within BML must be unambiguously defined and must be rooted in doctrine. In other words, the doctrine view must be a glossary comprising each term and its unambiguous definition as well as the source of this definition.

The glossary must be aligned with other SISO efforts to create a standard dictionary for use within M&S solutions (e.g., the RPR FOM definitions of the FOM/SOM lexicon (abbreviations used for first time should be in full or explained in a footnote)) and respective C2 efforts such as the Command and Control Information Exchange Data Model (C2IEDM)1. Furthermore, the glossary must be aligned with the manuals and

1 It is worth mentioning that each attribute in the C2IEDM has a mandatory field providing the meaning of this attribute. This field also has a pointer to the source of the definition. This can be compared to the FOM

D R A F T7

D R A F T

handbooks used to describe doctrines for the warfighter. A starting point should be NATO and ABCA2 publications supported by the relevant national publications.

A misperception often surfacing in discussions is that the doctrine view implements only a single doctrine. This is not the case. The view provides unambiguous definition of a doctrine, but allows different doctrinal viewpoints of services or nations to be defined. The BML doctrine view – once it is standardized – helps to describe different doctrines in a common form. Therefore, it actually will help show different partner viewpoints regarding doctrine.

In particular the groundbreaking work having done for the US Army is documented in the reports referenced in detail in [1, 2]. Setting up a C2 ontology is not a trivial task and should not be underestimated. That we are not there yet does not mean that the work having been done so far is not useful. The contrary is the case: this is the basis to work on standard recommendations and show methods and procedures to be followed by future C-BML group. Nonetheless, no generally accepted standard not even to cope with ontologies in general is established yet, which leads to the recommendation to keep the recommended standards to the minimum (as there is no alternative yet), but to encourage more research on this topic, as currently initiated with US studies on BML for Air Operations and Naval Warfare.

It has been discussed to what extent ontological layers will be necessary to express doctrine. The authors are convinced that we will need to extend the standard from the currently recommended glossary approach to a more semantically rich ontology approach, but there is no solution accepted by all target domains of C-BML that is applicable today. Therefore, the glossary approach is the best we can do currently, and further work is necessary. The glossary is a first step leaving future options open.

1.1.2 BML – Representation View

The representation view structures and relates the terms defined in the doctrinal view in such a way that they result in the description of executable missions and tasks. A mission is defined by a sequence of tasks that must be executed in an orchestrated manner. The representation must not only allow description of the various tasks but also composition and orchestration of these tasks into missions. Furthermore, the representation must comprise military means, which can be units or platforms or simulated entities. Being able to cope with causalities and temporal relationships in terms used by the warfighter is required and connects the representation view to the doctrine view.

Lexicon specified in the HLA standard.2 ABCA is a standardization program that was initiated in 1947 after the close cooperation of the allies in World War II, initially only involving three countries America, Britain and Canada. Australia joined the program in 1964. New Zealand were granted observer status in 1965. Today, the focus of the Program is on interoperability, defined as: “the ability of Alliance Forces, and when appropriate, forces of Partner and other Nations, to train, exercise and operate effectively together in the execution of assigned missions and tasks”.

D R A F T8

D R A F T

In earlier phases of the US prototype development for BML, the use of the C2IEDM was evaluated, recommended, and implemented. However, as various doctrines may require tasks and missions outside the current scope of C2IEDM, extensions and enhancements must be defined and consistently applied. Current discussions evolve around the question if BML data elements should be based on the C2IEDM or if something new is needed, such as BML data elements defined by the BML Web Service Description Language (WSDL) used in the recent US prototype demonstrated during the 2004 Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC).

C2IEDM fulfills the needs of the conceptual schema for information exchange as described in section 2 of this paper. The logical recommendation therefore is that the SG should analyze (a) if the C2IEDM is generally applicable to cope with these issues or if there are counterexamples, and (b) what extension rules need to be captured and standardized in order to ensure consistency between separately developed extensions and enhancements.

A number of organizations are already using the C2IEDM, and therefore it should be possible to evaluate their rules to determine if they are a good basis for standardization. In particular, the Multinational Interoperability Programme (MIP) group is of interest as well as the former NATO Data Administration Group. In particular, the US and a number of other member nations of the MIP are initiating a Coalition Secure Management and Operations System (COSMOS) Advanced Concept Technology Demonstration (ACTD) to explore transformational information exchange capabilities in Coalition operations. Among the proposed objectives of the ACTD is demonstration of interoperability among US and other nations’ equivalent echelon applications within a consolidated network environment using data modeling and exchange mechanisms compliant with MIP specifications.

In short term, the C2IEDM is the core representation to be exploited for information exchange in this ACTD. Execution of this ACTD program will provide valuable insights into the power and readiness of the C2IEDM for widespread coalition adoption to improve interoperability and warfighting capability.

Furthermore, commercial solutions, such as data federation or data migration services, may comprise valuable algorithms and rules applicable to BML challenges as well.

The representation view is academically interesting and challenging and the SG should make this clear in discussions of possible alternatives. There are several expert opinions concerning the applicability of data models to cope with ontological challenges. Additional ideas and future model-driven solutions need to be evaluated. One possibility is the use of Artificial Intelligence (AI) approaches, such as the Knowledge Interchange Format (KIF), to support the structuring process by (semi-) automatic tools. Linguistic approaches and methods used for knowledge sharing between intelligent software agents would also seem to be valuable.

D R A F T9

D R A F T

However, in conjunction with the recommendation at the end of section 3.1, there are no current solutions applicable to all three target domains of BML besides the C2IEDM, so our recommendation is to standardize the use of the C2IEDM and additionally discuss other ongoing efforts.

1.1.3 BML – Protocol View

In order to communicate necessary initialization data into BML and the resulting executable missions and tasks from the BML to the executing system, communication protocols are needed. The protocol view standardizes the way the description of the executable tasks and assigned executing military means is transported from the BML implementation to the target system, be it a C2 device, a simulation system, or a robot.

The use of Extensible Mark-up Language (XML) to describe the information exchange requirements is fundamental, as XML is the only standard for data description accepted by the C2 community, the simulation community, and the robotic community. Within the Extensible BML (XBML) project and follow-on efforts, the use of http-based web services was chosen. Based on results in ongoing work of the Extensible M&S Framework (XMSF) SG, as well as other interested experts in the domain of application of web services within computer grids, solutions that are more general may be needed in the international domain, which further point to XML.

Grid services are one example for alternative future research. Although they follow the same principles for data exchange and invocation, these services allow more alternatives within applicable protocols for web communication.

Based on the actual web service solution, the PDG should analyze advantages and disadvantages of alternatives and point to connected effects within the community. However, our recommendation is to start with standardizing XML as the initial means to be used for the protocol view, as XML is the only standard accepted by all three target domains as the necessary component schema on which the export schema can be based.

1.1.4 Operational Need and Expected Benefits

**TBD Not enough to be just C2 to simulation (e.g., ability to save time/effort through the use of the language); include initiatives to move toward robotic forces; overview of benefits (basis for common understanding and reuse; representation of knowledge, not just data; interoperability; ability to infer new knowledge from the axioms) and concerns (limited and immature tools; need to tie to upper ontologies; keep them small – component domain knowledge) regarding ontologies**

1.1.5 Problem Definition and Identification of Risks in Use of C-BML

**TBD**

D R A F T10

D R A F T

1.2 C-BML Study Group Terms of Reference

The statement of work for the C-BML SG identifies the following tasks:

Conduct a Paper Survey comprising as many international contributions applicable to the C-BML effort as possible.

Develop a Plan of how these various efforts identified in task 1 can contribute to a common C-BML standard or to a standard framework.

Formulate a set of Recommendations on how to proceed toward a C-BML product development group.

The products resulting from the establishment and execution of these tasks shall include, but not be limited to, a literature survey summarizing the results of task 1 and a final report (the present document) summarizing the results of tasks 2 and 3.

1.3 C-BML Study Group Meetings

During the kick-off meeting in Fall 2004, it was decided to have a first interim meeting during the I/ITSEC 2004 in December 2004 in Orlando, Florida. This meeting was held in collaboration with a NATO pre-kickoff-meeting on the same topic. During the NATO M&S Group (MSG) meeting in October 2004 in Koblenz, Germany, the MSG decided to set up an expert team to evaluate the applicability of BML ideas for the alliance in the form of an Exploratory Team (ET-016). The official kick-off for this activity took place in February 2005 in Paris, France.

As the time for discussions and presentations during the official SIW meetings is always limited, and because the meeting in Orlando during I/ITSEC showed a tremendous international interest in BML – another face-to-face meeting was planned to be conducted in March 2005 at the Virginia Modeling Analysis and Simulation Center (VMASC) with room for presentation of potential contributors and time for the discussion of ideas.

This meeting focused on the survey task of identifying possible international contributions applicable to the C-BML effort. Beside the SISO experts and members of the SG, invitations were send to other subject matter experts, in particular the authors of the soon to be published special issue of the Journal on Transactions on Simulations, Society for Modeling and Simulation (SCS), on “Military Simulation Systems and Command and Control Systems Interoperability.” Another aspect was consensus based on the work of the MIP and the C2IEDM – both identified as potential contributions to a broader M&S-to-C2 solutions in previous NATO and SISO conferences.

A face-to-face meeting was held at VMASC in Norfolk, Virginia, on 7-9 March, 2005. The meeting was chaired by Major Kevin Galvin and hosted by Dr. Andreas Tolk. Scott Hanson represented the SAC of SISO. It brought 35 international experts together. Five universities (Carnegie Mellon University, George Mason University (GMU), Naval Postgraduate School, Old Dominion University, and the University of Texas) participated in the event; six nations participated (Canada, France, Germany, Sweden, UK, and USA).

D R A F T11

D R A F T

The C-BML SG conducted an open meeting on 7 April 2005 during the Spring 2005 SIW in San Diego, California. The SG has established a close working relationship with the Military Scenario Definition Language (MSDL) for automated initialization of C2 and simulation systems. Other activities at the Spring SIW included a C2IEDM tutorial and presentation of papers 05S-SIW-007, 018, 019, 055, 068, 140, and 154. Discussion areas included (This section needs to be sorted out as it is only a list and does not encapsulate the discussions):

BML Levels for simulation and C2 systems C2IEDM Specification, Level 1 but not sufficient – need M&S extensions BML Services Level 2 BML Ontology, Level 3 [what is it and what does it provide to the warfighter] –

R&D areas: Ontologies, Taxonomies, Language Grammars, etc. CMN introduced new area of concern for BML – how to include terrain-based

reasoning in command decision-making NATO ET-16 Research and Technology Agency (RTA)/NMSG on C-BML –

Lionel Khimeche, France http://www.rta.nato.int Co-Chair is Erik Chaum, NUWC/DMSO Reviewed survey inputs to Study Group from the VMASC meeting ACTION: Need to create a separate input to the C-BML survey from NPS.

Include questions/issues regarding robot control languages. ahn/Denny thesis work regarding C2IEDM data base performance.

JRD3 – Chuck’s boss is the chief architect UK has a recommended BML Framework for Resources Reusability – LCDR Angel San Jose, SP (Navy Ops

Research Lab) MSG-042 – foster simulation reusability within NATO and PfP countries Ontologies for resource characterization and resource identification Synthetic Environment Development Tools Evaluation Project (SEDTEP) Need to have the military users participate in the development of the ontologies Goal to compose vocabularies with C2IEDM? Different warfare domains?

Current focus is C2 domain – probably a phased approach to a specification. Ontology work is clearly important but immature.

How to deal with the population of Army knowledge into BML. Spent inordinate amount of time for a limited scope (through 70 manuals). SISO is not the place for standardization effort for US air doctrine or Spanish land doctrine, but these will have to be done in the long run. UK has a doctrinal committee to deal with this – need to develop a doctrinal ontological base.

C-BML SG schedule:

NATO ET-16 meeting at The Hague, Netherlands, 25-26 April 2005 SG interim telecon – 4 May 2005 SG prep for Euro-SIW telecon – 22 June 2005 SG meeting at 05 Euro-SIW, Toulouse, France – 30 June 2005

D R A F T12

http://www.rta.nato.int/

D R A F T

SG interim telecon – 19 July 2005 SG report meeting at GMU – 2-3 August 2005 NATO ET meeting GMU – 15-16 September 2005 Final SG meeting at Fall 05 SIW – 22 September 2005

1.4 Document Organization

**Report Outline**

D R A F T13

D R A F T

2 Related Work

2.1 Projects

Attendees to the March 2005 Study Group meeting (Appendix A) were asked to respond to a survey to describe their current work with C-BML or their interest in future C-BML standards in relation to their current projects. The following is a summary of information received from the respondents.

2.1.1 Aide a la Planification d’Engagement Tactique (France)

2.1.1.1 Problem Statement

APLET (Aide a la Planification d’Engagement Tactique) is a French Ministry of Defence Research and Technology program which aims to investigate the capabilities offered by M&S for its use in an exiting French Brigade level C2 system, SICF, for Course of Action Analysis (COAA) purposes. APLET explores the technical issues of C2 and M&S coupling and will provide recommendations for interface specifications and data models to overcome the gap between current M&S and legacy C2.

One of APLET’s technical challenges is dealing with the definition and design of the simulation data model which has to be consistent with SICF data representation. APLET’s approach is to find a C2 data model that can be re-used and improved to build the APLET data model.

2.1.1.2 Solution Proposed

This led to the conclusion that the C2IEDM was the most suitable to APLET requirements, for the following reasons:

C2IEDM is a recent and very complete model (good coverage of the land forces’ requirements);

Most of APLET data can be represented with the C2IEDM data model; C2IEDM is the current convergence point of the C2 international community and

is supported from an operational point of view; SICF is based on ATCCIS GH5 (in full), which is version 5 of C2IEDM.

However, simulation needs many more parameters and attributes than C2. Those specific requirements are introduced by several models for the simulation purposes. For example, physical behaviour which comprises speed characteristics, probability of hit, probability of kill, detection probability are not represented in C2IEDM. Moreover, a simulation needs to manage several values for some parameters. For example, a military unit has several “values” for its status: status imported form the C2 system, status modified by simulation operators to initialize the simulation, and the set of values along simulation time during execution.

D R A F T14

D R A F T

Being out of the scope of C2 systems, such objects, attributes, and parameters are not within the frame of C2IEDM. They are managed internally by simulations and are not transmitted to C2 systems. Thus, APLET’s lessons learned will provide Change Proposals for submission to the MIP Data Modeling Working Group (DMWG) in order to enhance and improve C2IEDM.

In conclusion, APLET’s data model is being designed as an extension of C2IEDM. This approach facilitates the mapping of APLET’s data model with C2IEDM and gives APLET a “natural” interoperability with C2 systems based on C2IEDM, like SICF.

2.1.1.3 C-BML Relevance

In the scope of the C2-simulation interoperability studies, APLET converged towards architecture similar to the US XBML prototype, with the definition of an “APLET BML” XML schema consistent with the C2IEDM. Further, the motivation is to make this “APLET BML” format available to the SISO C-BML SG, as a contribution to the standardization effort. On the other hand, APLET will evolve to take into account efforts of the C-BML SG, and make the APLET’s BML compliant with C-BML format defined by the C-BML SG/PDG. This effort will be conducted in the frame of the upcoming NATO MSG-40 on C-BML experimentations. The objective is to promote BML within NATO and go further in operational use in a NATO BML standard.

2.1.2 Geospatial BML (US Army Engineer Research and Development Center)


Terrain and weather information is perhaps the only truly ubiquitous information relevant to all aspects of C2 and M&S. Consequently, this area (terrain and weather information generation) would greatly benefit from and contribute to a common approach to BML development and extension. Efforts to reach a common terrain/environment model have heretofore focused largely at the data level. The US Army Engineer Research and Development Center (ERDC) invests in numerous projects in the areas of Battlespace Environments and Military Engineering information and knowledge, and their role and application in both M&S and C2 domains. One ongoing project in the area of M&S and C2 interoperability is Common Maneuver Networks for Embedded Training, Mission Planning, and Rehearsal which utilizes Battlespace Terrain Reasoning and Awareness products and OneSAF Objective System (OOS) as platforms for proof-of-principle development and demonstration.


The ERDC is developing automated decision support services that apply tactical terrain behavior and activity models to terrain and dynamic environment data. The approach taken is to derive a maneuver ontology from maneuver related tasks found in the US Army Universal Task List (AUTL), and US FM 3-0 “Operations”, and FM 3-90 “Tactics”. The resulting information and knowledge products aid planning, preparation

D R A F T15

D R A F T

and execution of tactical missions and operations. ERDC seeks to abstract and represent terrain and dynamic environment through a rich set of discrete objects (spatial and temporal) and relationships to tactical entities and tasks. Instances of these objects and relationships can then be extracted from the current and future large terrain and dynamic environment datasets and databases – essentially reducing large terrain data sets to their tactical essence and expressing the reduction in an ontology for interoperability at the conceptual level. On this base, the ERDC builds tactically relevant decision aids that can be used by commanders, staff, subordinates or software services for C2 and modeling and simulation. The tactical patterns that are represented in the decision aids are registered to and modulated by terrain and dynamic environment and can be used as building blocks for lower echelon implementation of commander’s intent in a like battlespace context. A concrete example of this approach is a maneuver ontology mapped to the local schemas of both SAF and C2 platforms, entities and tasks. Interoperability is demonstrated by exporting planned routes and maneuver networks from the C2 platform into the maneuver conceptual schema. From there, routes and networks will be imported into the M&S platform.

The advantages of this broad abstraction and representation of the battlespace context are numerous:

Consistent with current state-of-the-art in representation of other tactical entities and relationships

All-inclusive framework for planning and manipulating targets, terrain, activities, plans, sensing, shooting, moving, etc.

Interactive visualization and integration of COA by human users, including rapid exploration of “what-if” scenarios and plan modification leading to deep understanding of the interaction of tactical operations and terrain and dynamic environment context

Facilitates communication between humans and software systems by representation of tactical pattern entities and context in a common language

Network-friendly representation of all entities and relationships, including terrain and dynamic environment, in relatively lightweight databases and structures that reduce bandwidth and storage and processing requirements at nodes

Enables application of state-of-the-art algorithms for feasible option generation and search, dynamic tracking and synchronization, and efficient task sequencing and scheduling


While not a current focus of the C-BML SG, expression of the current situation and COP is an essential and inevitable exercise for building C-BML. Commander’s intent/taskings for subordinate echelons is formulated based on a given battlespace context – COP/current situation. Planning for execution without benefit of a consistent terrain context will introduce ambiguity in C-BML not present in current planning.

D R A F T16

D R A F T

A critical requirement to achieve the ultimate goal of Center is an extension of BML, designated here as the geoBML, that maps the tactical task-based representations of the BML to the geospatial and temporal requirements of and enablers for the tactical activities. Traditional linear combat operations and central planning within a tactical operations center allowed commanders, staffs, and subordinates to communicate mission intent and tactical concepts around a map or sand table in a visual and iterative process. Future force operations will require distributed planning and execution. The shared understanding and communication of the geospatial and temporal aspect of plans and course-of-action in a distributed environment requires that terrain and dynamic environmental context be explicitly represented for distribution and visualization in a net-centric force. Current and future ERDC programs are developing explicit tactical terrain ontologies to enable this process, but these information structures need to be organized and sequenced to support the implementation and elaboration of mission command in a distributed battlespace. Selected ERDC programs and the developers of BML can work together toward the development of the geoBML to ensure a consistent semantic language for ubiquitous application of terrain and dynamic environment context to enable and support mission command in the net-centric future force.

2.1.3 ABACUS Architecture (Raytheon)


Raytheon has been tasked with developing a ‘rebaselined’ Advanced Battlefield Computer Simulations (ABACUS) architecture for the next generation Command and Staff Trainer (CAST) for the UK Ministry of Defence (MoD). ABACUS is the current legacy training system, a broad coverage aggregate-level simulation, which has been interfaced to the BOWMAN C2 system3 over the past year. However, due to limitations in both systems’ interfacing capabilities, the current interoperability is restrictive and limited. The next generation architecture must be much more robust and flexible with HLA capability, as well as easily adapted to additional C2 components (Battlefield Information System Applications (BISA) planned to be introduced in parallel with future BOWMAN upgrades over the next several years.


In a report already delivered to the MoD, Raytheon has proposed a revised ABACUS system based on a service-oriented architecture (SOA). The system uses the C2IEDM schema as a baseline for its simulation database, and will incorporate a C2IEDM-based object model to help ensure interoperability with C2 systems. Raytheon expects to build on and re-use existing design work already available (e.g. SIMCI C-ROM efforts (in full)) in order to further reduce design risk and effort. The architecture also includes an external interface management layer which will provide adapters for translation of required simulation data into appropriate information exchange formats for data transfers

3 BOWMAN is the UK program that provides a digitized radio for the British Army in order to facilitate secure voice and passage of data.

D R A F T17

D R A F T

with external systems, including those required for HLA-capable simulations, BISAs, and related C2 systems.


The C-BML is seen as a natural and cohesive extension needed for the proposed ABACUS Rebaseline architecture. By participating in the C-BML working group and the BML standards development, Raytheon expects to gain experience needed for incorporating BML capabilities into the interface adapter design for the revised system, thus providing ‘out of the box’ interoperability not only based on a recognized standards work, but also based on a composable and extensible framework which helps guarantee information exchange compatibility with future C2 systems. The timing for the planned BML standards development along with the Rebaseline architecture schedule are seen as complementary and achievable over the next several years.

2.1.4 Name of Project (VMASC, ODU, Norfolk, Virginia, USA)


The modern C2 data (meaning C2 systems, and their data models) world is very complex. To be of use they are often not only systems, but of necessity they are systems of systems. In both cases, they are required to interoperate with other systems from within the same service (Army, Navy, etc.), the same nation, and across national boundaries. This interoperability comes at an extreme cost - namely the tedious design and redesign of system to system interchange mechanisms. And those mechanisms often are the cause of misinterpreted or misunderstood data by the receiving system. It is believed that this is a problem that is solvable.


It is proposed that if we can understand the ontological meaning of the data and data needs that these different systems have, and if there is a sufficiently complete referential data model that can satisfy translating to and from these different ontologies, then the interoperability of systems will not only become easier to perform (through the mechanism of a well designed referential data model), but also the data exchanged through such a system would be consumable with a higher degree of assured validity by the target system. The contribution of research work to this system is three-fold: (1) to study what is meant by an ontology, in particular an ontology of a referential data model and its intended use; (2) to propose a method for evaluating a referential data model, and its use rules, against that definition; (3) to apply that method against the C2IEDM and report on my findings.


D R A F T18

D R A F T

This work is considered relevant to the C-BML group in that it will produce an artifact, namely findings, that can be evaluated to see if it is sufficiently rigorous to be seriously considered. And if it is, then it can be used as an artifact identifying the sufficient completeness of the C2IEDM to be used as a referential data model for the inter-system, inter-service, and inter-national data exchange envisioned by the C-BML project.

2.1.5 EXPLAIN Project (North Side, Inc., Canada)


The EXPLAIN project is focused on semantic understanding of texts describing military scenarios in Natural Language (English), and the generation of simulation scripts based on these descriptions. The partners in this project are North Side Inc., the RALI research group of the University of Montreal and eNGENUITY Technologies of Montreal. The EXPLAIN project was kicked off on December 8, 2004 in Montreal.


Ultra rapid scenario specification will improve mission effectiveness. Currently, the behavior of military simulations is specified programmatically. As a result, preparation for a complex military operation or exercise is today a matter of several months. With Natural Language specification, it becomes feasible to specify scenarios much faster and as a result, to consider many more tradeoffs, resulting in more effective missions. The ability to specify scenarios in English would enable end-users, including officers in the field, to specify simulations directly.


Our goal is to generate BML, or any formal description lending itself to automated processing, automatically from Operational Orders and plans and exercise description in English. They intend to cooperate and exchange information with anyone who has a serious lexicon development effort underway or potential users of the technology they are developing. They plan to use their work on military and anti-terrorist ontologies likely to attain standard status.

2.1.6 IMASE Scenario Generation Tool (Paul Morley and Lisa Pereira)


The IMASE Scenario Generation Tool (ISGT) has the requirement to support the rapid generation of Operational Test threat scenarios for system testing of US Army Intelligence and Electronic Warfare (IEW) Systems. The scenarios are executed using M&S to generate a synthetic environment in which to immerse the IEW System Under Test (SUT). The current M&S environment is provided by Tactical Simulation Operation Test (TACSIM-OT), but is limited to stimulating the All Source Analysis System (ASAS) System. TACSIM-OT is being replaced by the Intelligence Modeling and

D R A F T19

D R A F T

Simulation for Evaluation (IMASE) System of Systems. The IMASE System will leverage off of the experience and successes of TACSIM-OT to extend M&S support to IEW Sensor Systems and other IEW Processing Systems.


As of right now, ISGT has entered into one of the last phases of development. Its current capabilities include multiple client/server using a Microsoft SQL, intelligence data importing using UOBDAT v8.1, scenario data import/export using ISGT XML schema, and scenario data exporting using the MSDL schema. Other capabilities include a data driven database and HLA runtime data import using the MATREX FOM v0.5 rev3.


ATEC Headquarters has given the task to examine the integration of ISGT, BML, ACSIS, and the C3 Driver. Currently ISGT has been able to export scenario data to other M&S systems, such as OOS using MSDL v3.1.0 Block C build 21. In terms of BML specifically, it is of the understanding that ISGT may be able to use BML to link to other M&S and C2 systems, provided that they also know how to manipulate BML. Being able to speak BML would provide ISGT with the same type of capability as the import and export of scenario data via the ISGT XML schema, but at a much global level. ISGT would be able to export scenario data using BML in order to populate scenarios for M&S and C2 systems that understand BML. In turn, ISGT would also be able to populate a new scenario by being able to import BML scenario data generated by M&S and C2 systems.

2.1.7 Formal Tasking Language Grammar (Mitre)


At present it is difficult to determine and ensure consistency, overlap, and coverage between the tasking languages that are part of MSDL and BML because both MSDL and the Army BML lack a common formally defined tasking language grammar.


The US Army BML effort originated based on a need to provide US Army commanders with an unambiguous language to command and control forces and equipment conducting military operations and to provide for situational awareness and a shared, common operational picture. To do this BML developers are driven by four underlying principles: 1) BML must be unambiguous, 2) BML must not constrain the expression of a commander’s intent, 3) BML must use standardized C2 data and message representations, and 4) BML must allow forces to communicate information pertaining to the mission, their status and their environment. An important part of the US Army BML is a tasking language telling subordinate forces what actions to take. [Sudnikovich,

D R A F T20

D R A F T

William. US Army/DoD BML Project Overview and Status, C-BML SG meeting, 7 March 2005.]

The MSDL originated to offer a simulation independent scenario definition allowing scenario reuse among simulations supporting the MSDL format. Keeping the MSDL free of simulation specific references and information, and using an open and available data interchange format are of primary importance in the development and evolution of MSDL. As with BML an important part of the MSDL is a tasking language telling subordinate forces what actions to take during the execution of the simulation.

Ideally, a common tasking language supported by both MSDL and BML would allow BML generated orders to be saved in MSDL format and imported into simulations as part of the simulation scenario generation process. At present it is difficult to determine and ensure consistency, overlap, and coverage between the tasking languages that are part of MSDL and BML because both MSDL and the US Army BML lack a common formally defined tasking language grammar.

Currently, the Military Scenario Development Environment (MSDE) and US Army BML developers are generating a common, single, formal tasking language grammar that can be implemented in an XML-based format (MSDL) and supported within the C2IEDM (BML) implementation. The resulting implementations will allow BML generated tasks to be imported via MSDL into the simulations leveraging the MSDL technology. MSDL and BML developers are working together to demonstrate this capability during I/ITSEC 2005. [MSDL & BML Development Team. BML and the MSDL Implementation Plan for Collaborative Grammar Development in FY05, Working Draft.]


This effort directly and positively impacts the C-BML community by providing a formal unambiguous grammar definition for the US Army BML effort that can be shared among and used to unify the Air Force, Coalition, and other BML efforts.

2.1.8 Task Analysis Leading to BML Vocabulary (Mitre)


How can the requirements of an order/task be identified in a common way across the doctrine of the coalition? Key considerations include:

Independent of the doctrine of each coalition member, there are common terms of when, where, and why. Each of these “terms” is represented differently in the natural language within the doctrine of each coalition member.

Given common terms exist, these terms provide a common computational language across all doctrine.

The syntax, grammar, and vocabulary cannot be identified without a detailed understanding of the targeted ontology that is represented in doctrine.

D R A F T21

D R A F T

The “context” of the language changes when an order applies to a smart vs. a dumb unit.

The information should be derived from the explicit language of the task. In other words, the analysis must assume the doctrine is correct and is not subject to interpretation. If the task is incorrect, then the task must be corrected first. The analyst must not take expert liberties in the analysis. If liberties are taken, the language is no longer traceable and will not pass the Verification, Validation and Accreditation (VV&A) activities.


The following activities need to be conducted:

Perform a task analysis to identify that information which is provided with, or in context to, the specific order/task.

Identify the information required, and information that results from situational understanding (SU) (SU information is a required input for “dumb” actors/units).

Identify methods of specifying why in context to these terms. For example, of all the task input terms, the one representing a firm constraint in context to the mission is the “why”.

All the terms identified from the task must be placed in context to both the language and the doctrine; in other words it must be both human readable and computational.


This effort will provide a methodology for specifying language requirements based on the tasks to be communicated. This applies to real (smart) units as well as robotic and simulated units to address terms required as input with the order providing constraints or requirements to smart and dumb units. For dumb units additional information representing situational understanding needs to be communicated as well.

2.1.9 Identification of C-BML Need (Ericsson, Sweden)


This summary covers four different, but related, topics that address the need for a C-BML: (1) planning for Joint operations; (2) operational Joint command support; (3) assessment of commander’s intent; (4) opponent’s intent.


Planning for Joint Operations. The calls for joint operations also imply the necessity for joint planning. In order to avail adaptable units of soldiers or units from various service branches and nations the commanders intent must be possible to express unambiguously. The assumption made are that there exists doctrines/workflows that can be expressed in a

D R A F T22

D R A F T

way that facilitates machine reading and that the coalition forces are allowed to exchange information/data during simulations. The solution is to create a planning tool where commanders from various service branches and nations are able to work in collaboration simultaneously with their own views and representations.

Operational Joint Command Support. The mission scene is changing, since the deployed units need to interact with other units from other branches or nations. Each one of the branch/nation has a command language and representations, which often are unique for them. This variety creates difficulties in describing the commander intent. The mission scene is changing in such a way that a more joint appearance in operations are required along with that doctrine need to be expressed in machine-readable format. The solution is to enable for commander intents to be translated/understood unambiguously by other commanders regardless of national and service branches affiliation. This must be done in a way that keeps the different commander familiar with their own taxonomy, representations etc.

Assessment of Commander’s Intent. When acting in the constantly changing operative scene the ability to adapt to the new operational picture is essential. Training is performed weeks/days/hours prior to the mission but the commander might have to adapt to completely new ways for conducting it with respect to the changeableness. In order to avoid that old behavior influences the commander or that group thinking is present some type of real-time assessment is necessary during the operations. Further more it entails the use of another nation’s, service branch commander intentions during training of units/individuals using their own doctrinal procedures. One of the key assumptions is that there exists information fusion capability to align sensor data towards commander intentions. The solution is to use information fusion methods/algorithms to ascertain what commander intent that are currently conducted and how it connects with intentions at higher levels. Then it is possible to assess if the goal will be met.

Opponent’s Intent. When the own forces commander intentions are possible to express, used in planning and available for assessment the opponent intention may also be described using the same ontology/taxonomy. Thereby the decision support system makes the opponents intention and ours countermeasures available and simultaneously still meet our own commander’s intention. Assume that there is a probable way for describing commander intent not only to the taxonomy of today but also in the future.


Planning for Joint Operations. The relevance for a C-BML is the ability for the user to represent intent in own nation/service representations (BML) that can be mapped/translated to a C-BML and used in C2 or simulation systems.

Operational Joint Command Support. Refer to the above statement, with addition of the ability for commanders from different nations/services to share each other’s intentions in their own command and control systems.

D R A F T23

D R A F T

Assessment of Commander’s Intent. Refer to the above, with addition of the ability to map the current progress of an operation against the planned issuing warnings.

Opponent’s Intent. The relevance to C-BML is that without a common language it is a much harder task to represent opponent’s intentions.

For the ideas/solutions presented above some work has been done, some work is in progress and some is planned:

The work within LedsystM4 is one source for methodology and for an example of building doctrinal representations;

Swedish Defence Material Administration vision and practical work within the field;

The Swedish Armed Forces (SweAF) Ground Combat Model is an existing BML for ground forces and might be used as a case study for alignment towards C-BML;

Work within Swedish industry (Ericsson and others) to build efficient decision support systems for commanders;

Information Fusion research project at University of Skövde.

2.1.10 Army C4ISR and Simulation Initialization System (ARL/UT, USA)


C4ISR systems have evolved to support full Network-Centric Warfare (NCW)5 to provide commanders and their staffs with a complete and accurate COP of the battle space in near real-time. M&S systems have also evolved to support large federations of hundreds of workstations and servers exchanging information between many disparate simulation systems linked to many disparate service-specific and Joint C2 systems to provide a Joint National Training Capability (JNTC). Most DoD training exercises, testing, and experimental events today, involve the integration of live C2 systems with a federation of live, virtual, and constructive (LVC) simulations. M&S are currently being embedded in C2 systems for decision-aid, COA analysis, mission rehearsal, and training purposes. NCW has blurred the lines between C2 and M&S.

The US DoD operational environment requires the rapid projection of joint force capability packages within a new “deploy = employ” paradigm. Force capability packages that are quickly alerted, task organized, and deployed conducting en-route adaptive planning, COA analysis, and mission rehearsal. Adaptive planning is the capability to create and revise plans rapidly and systematically, as circumstances require. Adaptive planning occurs in a networked collaborative environment in which plans, planning tools, and pertinent databases are linked together, with warfighters working across multiple services, coalition partners, organizational levels, and functional areas. Full NCW requires major changes in both the deliberate and crisis action military

4 Swedish C2 system5 US terminology.

D R A F T24

D R A F T

planning process, all the way from the strategic-level of war down to the operational-level Military Decision Making Process (MDMP) of conducting COA analysis and developing and disseminating tactical Operation Orders.

The first essential step in establishing and maintaining a complete and accurate COP is to initialize systems from a common set of complete, accurate, and synchronized data. The production of Army network-centric system architectures and C2 and simulation initialization data products for real-world operations and training exercises is time intensive, expensive, and error prone. The legacy initialization process is complex, de-centralized, sequential, and primarily manual, which yields data inconsistencies between C2 systems and simulations. Current force alert-train-deploy timelines require initialization data products to be generated and synchronized in a number of days. The current process requires a number of weeks or months. The scope of this problem will continue to grow as more digital C2 systems are fielded across the US Army, as new systems (Future Combat System (FCS)6 are developed and fielded, and as these systems interoperate with joint service and coalition C2SR systems.


To begin to meet these challenges, a collaborative effort between the Central Technical Support Facility (CTSF), Army Program Executive Office for Command, Control, and Communications Tactical (PEO C3T), the Defense Modeling and Simulation Office (DMSO), and the Army Simulation-to-C2 Interoperability (SIMCI) Overarching Integrated Product Team (OIPT) has developed the Army C4ISR and Simulation Initialization System (ACSIS). The CTSF, at Fort Hood, Texas, is responsible for producing and integrating data products to initialize digital C2 systems for units equipped with the Army Battle Command System (ABCS), including the Force XXI Battle Command Brigade and Below (FBCB2) and Blue Force Tracking (BFT) systems. Applied Research Labs at the University of Texas in Austin (ARL:UT) is providing technical expertise to both the PEO C3T and the simulation community in the development of ACSIS.

The basic concept of ACSIS is to rapidly generate initialization data products, with automated tools, for both the C2 (ABCS) systems and a federation of simulations from a single integrated database of complete, accurate, and synchronized data based on a particular mission-specific or exercise-specific Unit Task Organization (UTO) data set. The ACSIS database currently includes US Army unit force structure (UTO) data, and materiel ("platforms") assigned to each echelon, and the network structure, communications systems, computer systems, network configuration data, and network addressing data for a particular mission-specific UTO. The ACSIS database is a repository of multiple UTOs, each with their associated ABCS network data. ACSIS was designed to support multiple versions of ABCS network architectures (currently 6.3.6 and 6.4). The primary purpose of ACSIS is to reduce initialization data preparation time, resources, cost and to reduce data inconsistencies and errors between systems. The PEO

6 FCS is a US Army progam to develop a number of platforms that will support the NCW concept.

D R A F T25

D R A F T

C3T objective is to reduce this C2 data production time from months to some period of time closer to 96 hours.

Although develop of ACSIS continues, ACSIS is operational today at the CTSF (PEO C3T) at Ft. Hood. ACSIS is being used to generate ABCS initialization data products for deploying Army forces. ACSIS has also been used to generate initialization data products for simulations (Ft. Hood Simulation Center- RTM/CBS) for these Army forces to train before deployment. ARL:UT is the primary organization involved with ACSIS simulation initialization. ARL:UT has focused the ACSIS effort on the DBST federation (Janus, JCATS, FireSim, EADSIM, etc.), the JCATS/JTLS federation, JWARS, and OneSAF/MSDL. (A lot of abbreviations that need explaining – this is not a US only paper)

The simulations of a federation and their C2 interfaces (sometimes called “C2 Adapters”) require initialization with the network data. The simulation algorithms are coded to accurately represent the capabilities provided by each digital C2 systems. The C2 adapters route tactical message traffic on the network between autonomous simulations and role-players with actual or surrogate C2 systems. Surrogate ISR sensors and systems also stimulate the live C2 systems through the C2 adapters. Exercise observers/controllers, “white cells”, and role-players with actual or surrogate C2 systems must be integrated into the tactical network architecture, configuration, and addressing data. Training and testing data collector devices must also be configured as actual nodes on the tactical network.

Currently ACSIS outputs ABCS network and simulation initialization data products in a number of different target system-specific formats and standard XML Data Interchange Formats (DIFs) based on the C2IEDM and the MSDL. ACSIS does the appropriate translations of data element syntax and naming convention required by the target system and formats the initialization data is the appropriate native format that the target system can directly ingest or import. However, now that data element and format standards, such as the C2IEDM, Enterprise-wide Identifiers (Global Force Management EwIDs), and the MSDL are beginning to be adopted by both the C2 and the simulation communities, less data element mappings and translations will be required. The ACSIS project has begun transition to the Army's Objective Initialization Capability (IC) program which will transition ACSIS from a "white-coat" data engineering tool used only by the CTSF to a web-enabled distributed database architecture that will put the tools in the hands of the Army warfighters themselves. The ARL:UT ACSIS team has also been involved with the development of JFCOM's Rapid Distributed Database Development System (JRD3S) in support of the JNTC program. The JRD3S goals/purpose are similar to ACSIS/IC; just with a larger scope. The ARL:UT ACSIS team has been involved with JRD3S requirements analysis and system design. ACSIS will be part of an initial JRD3S prototype in FY06 along with other services data preparation/scenario generation systems.

D R A F T26

D R A F T


BML provides a standard (semantics and syntax), unambiguous, automated means to exchange individual data elements, that represent battle management products, between C2 systems and simulations. C-BML will allow all the partners of a coalition to share battle management products across the battle space. C2 systems and simulations need to be initialized and synchronized with data contained in these tactical battle management products.

Currently the ACSIS database includes two primary categories of data – US Army force structure data (UTO) and the associated ABCS network data. ACSIS is a C2 and simulation initialization system. ACSIS is not, and it is not intended to be, a full scenario generation system. The term scenario generation is normally considered to include the development of the full situational context in which a particular training exercise or a testing event is conducted in order to achieve certain training or testing objectives.

Full training exercise, testing, or experimentation event scenario generation and full scenario initialization includes many more categories of data than just the mission-specific UTO and the associated C2 network data. The primary category of data relevant to the development of a particular training exercise scenario is the operational plans and orders; including the friendly and enemy situation, stated missions and tasks to subordinates, graphical control measures, and the many detailed annexes to the plans and orders. The higher-headquarters operational order provides the training units with the operational context that “frames” the exercise. All subordinate units’ operational orders must comply with their higher headquarters’ operational orders. Other categories of data required for full scenario generation include logistics data, weather data, geospatial terrain data, etc.

Scenario generation systems, such as the OneSAF MSDE/MSDL and the JRD3S, currently under development, are designed to include a complete situational context data set for a particular training exercise scenario. The scenario will include the situational context leading up to the start of the exercise (StartEx) and can also include scripted events that are injected into the exercise by exercise controllers/observers, “white cells”, role-players, and the Opposing Forces (OPFOR) during the conduct of the exercise.

There is one set of data that is common to the C2 (ABCS) network initialization and the training exercise scenario: the mission-specific or exercise-specific UTO. All the ABCS network data is based on a particular mission-specific UTO. The training exercise scenario is also based on a particular mission-specific UTO (Annex A of all US operational orders). The UTO includes the hierarchy of units and the platforms, equipment, and personnel assigned (on-hand) at each echelon.

Simulations need to be initialized with data contained in tactical Operational Orders and Plans, Warning Orders, Fragmentary Orders (FRAGOs), annexes, graphical control measures (overlays), execution matrixes, and other tactical battle management products. In addition to these Army battle management products, there is also a number of joint C2

D R A F T27

D R A F T

products essential for simulation initialization and scenario generation such as the Air Tasking Order (ATO), air defense plan, master air attack plan, target nomination list, joint integrated prioritized target list, and the Airspace Control Order (ACO).

These battle management products can be produced by actual US C2 mission planning systems (these include systems such as CAPES, C2PC, MCS, CPOF, TBMCS). (explain in full or as footnotes) and disseminated through the normal tactical networks to other C2 systems or these products can be produced on standard PC applications (MSDE/MSDL). In either case, simulations use the information in these battle management products to produce scenario-specific initialization data products, databases, and files.

The Army Battle Command Simulation and Experimentation (BCSE) Directorate recently approved and funded a FY05 project under the Army Model Improvement Program (AMIP) for ARL:UT to integrate BML data element constructs into the ACSIS database schema. BML, based on the C2IEDM with appropriate extensions, provides a standard (semantics and syntax), unambiguous, automated means to exchange individual data elements, that represent these battle management products, between C2 systems and simulations. An ACSIS database that includes these BML data elements will provide an automated means to share this data across a federation of simulations. As C2 mission planning systems and exercise scenario generation tools adapt BML to produce mission-specific or scenario-specific battle management products, this data can be populated in the ACSIS database. This data would then be available for the ACSIS Tool which can produce scenario-specific data files to initialize both C2 systems and a federation of simulations through a C2IEDM-XML or MSDL-XML DIF.

The key to system interoperability is data interoperability. As US Army, Joint, and Coalition ontologies are established, as standard information exchange data models are mandated and their extensions properly configuration managed, and as standard data interchange formats are mandated, legacy system database schemas will start to migrate to these data standards and new system database designs will include these standards at their inception. Web services technologies, shared data spaces, and metadata catalogs and registries will allow data producers and data consumers to post and access the right data for the right mission. The result will be rapid, complete, and accurate system initialization and synchronization for true system interoperability at the data level.

2.1.11 XML-based Tactical Language Research (Naval Postgraduate School)


The Naval Postgraduate School (NPS) is conducting research in a number of programs related to employment of M&S and Web-based technologies in tactical systems. A key area of work is information representation in the various systems and mechanisms for efficient and effective information interchange across systems. Representative efforts include:

D R A F T28

D R A F T

Undersea Warfare (USW) XML Working Group: employment of XML data formats and messaging within tactical systems

Global Information Grid (GIG) M&S Community of Interest Focus Groups: metadata, data mediation, and services supporting M&S on the GIG

Autonomous Unmanned Vehicle (AUV) Workbench: including Autonomous Vehicle Control Language (AVCL) as a representative BML for robotic forces

Common Maneuver Networks (CMN) and Mobility COP (M-COP): developing common data representations to facilitate exchange of maneuver network data among M&S and C2 systems and to form a basis for definition of a Mobility COP, including contribution to formalization of a GeoBML to describe the operational battlespace

XMSF: continued development of exemplar projects and community education to define a composable set of standards, profiles and recommended practices for web-based military modeling and simulation leveraging the extensive commercial investment in web-based technologies

Model-based Communication Networks: creating producer/consumer data semantics for task-driven information exchange to achieve Valued Information at the Right Time (VIRT)

Naval BML: extending current Army and Air Force centric BML approaches to represent Naval plans and orders

Joint Tactical Integrated Data System (JTIDS): NATO project developing XML encodings of Link 16 messages and application of binary XML compression schemes for tactical data links

COSMOS ACTD: applying C2IEDM for core data representations in a coalition information processing network


Broad technical interoperability is enabled by open standards, XML-based markup languages, Internet technologies, and cross-platform Web services supporting diverse distributed M&S simulation applications. The XMSF project is providing the technical basis for transformational interoperability via XML data and messaging interchange, profiles, and recommended practices for Web-based M&S. Specification and formalization of strong semantics is a fundamentally difficult area that has seen much research progress in recent years as part of the W3C’s Semantic Web and other initiatives. The first requirement in the area of ontologies is to allow definition and approval of complementary taxonomies that can be applied across multiple application domains. This will allow for the consistent classification of data and services via precise vocabularies. A subsequent requirement is to establish consensual common meaning. It does not suffice for there to be agreed-upon meaning within a group, but to be truly useful, there needs to be a mechanism for defining the equivalence of terms between groups (ontology mapping). This will allow for both extensibility and for interoperability. The Defense Advanced Research Project Agency (DARPA) Agent Markup Language (DAML) project has established an ontology repository for common service representations. In practice, the NATO-developed C2IEDM information-exchange data model is being exploited for tactical operations. It is particularly interesting to consider

D R A F T29

D R A F T

the implications of standard semantics like C2IEDM that help to establish commonalities between services and coalition partners. Development of effective ontologies for military operations orders (which contain tactical versions of the “who, what, when, where and how” of an operation) is a strategically important application area deserving dedicated further work. NPS is addressing this need through a number of projects and example applications (refer to the list in 2.1.11.1 above).


A key requirement of all these efforts is a well-defined language for representing the commander’s intent and conveying orders to operational forces, be they live, constructive, or robotic. If successful, the C-BML will provide the basis for unambiguous expressions upon which autonomous agents and automated decision-support systems can provide effective support to warfighters across ever-more important joint and coalition operations.

2.1.12 SOKRATES (FGAN-FKIE, Germany)


In Germany, FGAN-FKIE developed a prototype for automatic report analysis, the so-called SOKRATES system. This system takes reports written in natural language as input and inserts the analyzed content into a data base and displays it on a map as well.


In a first step, the reports are transformed into a formal representation by means of information extraction (Hecking, 2003, 2004). The formal representation used is an XML version of a feature-value structure, the standard representation format used by unification-based processing systems in the field of computer linguistics (Shieber, 1986; Bresnan, 2001). In a second step, these representations are augmented semantically by ontological processes (Schade, 2004; Schade & Frey, 2004). Last, during the post-processing step, the results are visualized within a common operation picture as well as inserted into the underlying C2IEDM data base.


The formal representation used in the SOKRATES system as well as its ontology component are grounded on the C2IEDM. The taxonomy as well as attributes, their values and their value restrictions are taken from there. Thus, the formal representation is quite similar to C-BML. The main difference lies in action framing. C-BML uses a fixed frame system (the five Ws). In contrast, the formal representation of SOKRATES is “lexical driven.” The frame system used in a specific statement is determined by the type of the respective action; e.g., if the statement is about a rest-action there will be a location-slot like C-BML’s WHERE, but if it is about a move-action there will be four kinds of WHERE-slots, namely one for source, one for determination (do we mean

D R A F T30

D R A F T

destination), one for path, and one for direction. Besides, SOKRATES also adds complexity by allowing whole statements as arguments of its “intention-slot” which mirrors C-BML’s WHY. The pros and cons of these differences to C-BML need to be identified and assessed.

2.1.13 Project SINCE (Extract from ICCRTS Paper)

2.1.14 UK Research into BML (QinetiQ)

2.1.15 NATO ET-016 Description

2.2 Relevant Publications (These should be a separate Annex which are referred to only in this paragraph)

Scott Carey, Martin Kleiner, Michael R. Hieb, Richard Brown: “Standardizing Battle Management Language – A Vital Move Towards the Army Transformation,” Paper 01F-SIW-067, Fall Simulation Interoperability Workshop, 2001

Michael R. Hieb, Andreas Tolk, William P. Sudnikovich, J. Mark Pullen: “Developing Extensible Battle Management Language to Enable Coalition Interoperability,” Paper 04E-SIW-064, 2004 European Simulation Interoperability Workshop, Edinburgh, Scotland, June 2004

Michael R. Hieb, J. Mark Pullen, William P. Sudnikovich, Andreas Tolk: “Extensible Battle Management Language (XBML): A Methodology for Web Enabling Command and Control for Network Centric Warfare,” 2004 Command and Control Research and Technology Symposium, San Diego, CA, June 2004

Charles Turnitsa et al.: “Lessons Learned from C2IEDM Mappings within XBML,” Paper 04F-SIW-111, Fall Simulation Interoperability Workshop, 2004

Andreas Tolk, Kevin Galvin, Michael R. Hieb, Lionel Khimeche: “Coalition Battle Management Language,” Paper 04F-SIW-103, Fall Simulation Interoperability Workshop, 2004

Dave Perme, Michael R. Hieb, J. Mark Pullen, William P. Sudnikovich, Andreas Tolk: “Integrating Air and Ground Operations - Within a Common Battle Management Language,” Paper 05S-SIW-154, Spring Simulation Interoperability Workshop, 2004

Andreas Tolk, Curtis L. Blais: “Taxonomies, Ontologies, and Battle Management Languages – Recommendations for the C-BML Study Group,” Paper 05S-SIW-007, Spring Simulation Interoperability Workshop, 2004

D R A F T31

D R A F T

3 Plan for C-BML Specification Development

Recommendations for defining a C-BML Specification

Phased approach with guidelines for each phase. – NATO group will be the first customerNeed representation readable by humans and machines.Need doctrinal basis.

C2IEDM7 and its successors will be the reference implementation and the recommended representation.

Phase I – C2IEDM, XML tag-set, definitions in C2IEDM (APP-6A, US Joint Publication 101) as a small start on consensus on doctrine. To show feasibility, will have subset of C2IEDM (organizations, hierarchy, tasks, given time, given location) made available through mediation services to other applications (e.g. SICF, CAPES on the C2 side; APLET, JSAF on the simulation side). Receive and produce object description transactions for tasking and reporting in C-BML. Guidelines will describe the XML schema.

Phase II – Tasking Grammar with vocabulary to replace limited set of enumerations and message structure in Phase I, for extensibility. Ideally this phase will address reporting but not the priority.

Phase III – Develop Reporting Grammar if not completed in Phase II, for bi-directional extensibility.

Phase IV – Develop ontology for composability.

Not sure what can be done with ontology. As a study group, don’t need to produce even a phase I specification, just to produce recommendations. Maybe could not include MSDL in a Phase I specification. Maybe some benefit in the grammar definition.

Product Development Group can exist for several years. Trying to establish process to move work along down the road.

1. Really need to start with a specification; may be getting too deep into ontology too fast.

2. May need to give some sense what the specification is going to look like to begin building consensus internationally.

3. Study Group report recommendation for product development proposal PDG standard(s)

4. Need to schedule in deliverable products also7 C2IEDM wil become JC3IEDM

D R A F T32

D R A F T

Some thoughts from Pierre Gauvin, 5/4/2005:

It would be useful to compile a multi-national tasking grammar: i.e. When the US talks about "Gain/ Maintain Control of Land Areas" in Canada, Australia and UK that talk about "Dominate Key Terrain". There cannot be a meaningful CBML unless we can easily translate between the nations (or harmonize what they use). As a starting point, analysts in Australia (as a tool to develop ASJETS) have constructed a preliminary mapping of task lists based on country-specific lists from Australia, Canada, UK, and US. The work has not been validated by the 4 countries.

SIW paper 05S-SIW-007 (Tolk and Blais) delineated a number of recommendations for development of the C-BML:

Establish the following subgroups should be established within the C-BML PDG:o Improving the C2IEDM: While the C2IEDM is considered the best initial

information hub currently available, it has to be improved. Studies described in [1, 2, 12] show that the resolution needs of simulation systems are not met in all areas.

o Establishing C-BML ontology subgroup: In alignment with the other ontology efforts described in this section, a subgroup has to work on recommendations on how to extend the C-BML doctrine view beyond the glossary. In addition, the ontology must bridge the current gap between the C-BML representation view and the C-BML doctrine view. A better way than a glossary to represent doctrine is needed.

o Evaluation of related standards: While XML enables separation of data definition and data content, it does not ensure that data exchanged is interpreted correctly by the receiving system. Other standards may be needed that are able to ensure correct application. The SG must evaluate such standards for future extension.

Sections Error: Reference source not found and Error: Reference source not found of paper 05S-SIW-007 recommended (1) XML, C2IEDM, and the glossary of used terms as the initial set of standards for C-BML and (2) establishment of subgroups addressing the challenges of extending the C2IEDM, establishing a C-BML ontology, and evaluating additional standards applicable to all three C-BML domains of Command and Control Devices, Simulation Systems, and Robotic Systems.

D R A F T33

D R A F T

4 Product Description

To become New Annex for Ontology

The term “ontology” has become a buzzword in recent years working its way from computer science to the M&S community through numerous papers and presentations. The term is attendant with much confusion. The classical definition of ontology is "a specification of a domain's conceptualization" (Gruber 1993). The specification is attained by defining the domain's concepts, the relationships between those concepts, and the rules defining the allowable nature of those relationships. Some describe an “ontology spectrum” spanning semantically weak representations such as relational data base structures and hierarchical taxonomies to semantically strong representations involving knowledge representations expressed in formal logic supporting automated reasoning (Daconta et. al. 2003). From (Tolk & Blais 2005), “If a formal specification concisely and unambiguously defines concepts such that anyone interested in the specified domain can consistently understand the concept’s meaning and its suitable use, then that specification is an Ontology.”

Other definitions of ontology are provided below:

Wikipedia – “An ontology is the product of an attempt to formulate an exhaustive and rigorous conceptual schema about a domain. An ontology is typically a hierarchical data structure containing all the relevant entities and their relationships and rules within the domain.” Conceptual Schema is defined as a map of concepts and their relationships.

http://ontologyworks.com/what_is_ontology.php provides a definition attributed to Barry Smith (University of Buffalo http://ontology.buffalo.edu/smith/) – “For an information system, an ontology is a representation of some pre-existing domain of reality which:

1. There exists a systematic correlation between the representation and reality,2. The representation is intelligible to a domain expert,3. The representation is formalized to allow automated information processing.”

There are two important distinctions to resolve. First, Smith goes so far as to say the description is formalized to allow automated information processing, which from a computer science perspective, is an important distinction. Secondly, Smith focuses understanding by the domain expert in contrast to the Tolk/Blais description of “anyone interested in the specified domain.” The breadth of the latter notion could have substantial implications in the size of the ontology. In both definitions, the intent is certainly to create a formal representation of the semantics of a domain to enable understanding by both human and software agents.

D R A F T34

http://ontology.buffalo.edu/smith/

http://ontologyworks.com/what_is_ontology.php

D R A F T

VMASC has conducted an investigation of an ontology for C2IEDM (Reference Euro-SIW paper). Two main branches of the C2IEDM used for data exchange are the Object and the Action. The properties of the data model have been evaluated to see how well they satisfy the three parts of an ontology; namely: (1) Are the concepts of the data model well defined and addressable in detail? (2) Are relationships between the data model well defined and addressable in detail? (3) Are there rules defining the nature of the allowable relationships and which classes of concepts they can be applied to? The work represents early stages in exploration of ontology, and the search for a method wherein the ontology of a data model can be evaluated for its completeness and sufficiency to serve as a standard referential data model allowing for conceptual data interoperability between other data models. Conceptual data interoperability is a step further removed from, and beyond, just technical interoperability. It implies that the data passed back and forth between systems is received and interpreted with semantic understanding on the part of the target system and, conversely, the source data system has a semantic understanding of what requests are made of it before it constructs the data to be exported. This can be achieved by a central referential data model that has sufficient understanding of both the data model and the underlying concepts of the other systems to be connected. Those concepts need to be specified, and since a specification of a conceptualization is an ontology, there exists the need for a sufficiently complete ontology that can address in detail the many classes of concepts and relationships that a domain might possibly have need of. The test of sufficiency is based on the three criteria listed above. In all three cases, since a complete enumeration covering all possible areas of a domain is not possible, these criteria can be satisfied by showing that the ontology of the data model in question can satisfy a derivative method for obtaining the answers for those criteria. For instance, if the data model itself cannot be said to currently provide for all the concept enumeration required and if the data model instead provides for a method of deriving all possible levels of data to create complex concepts out of simpler concepts, and then out of atomic properties, then the model can most likely provide for all the concepts needed. VMASC is currently formalizing the definition of an ontology, and also capturing the details by which that definition is applied to an existing data model. This is being applied first to the C2IEDM, but the next stage of the work will be to apply this method to other data models. This should show whether there are any data models that can serve as a central referential data model. Possible outcomes are first, that there is currently a model that fulfills all our needs. This is unlikely. Second, it may be too complex of a demand to have a data model that can serve as a central referential data model. This is also unlikely. And third, that there is currently a data model that can satisfy the majority of the criteria based on the working definition, but that will need some support before it can be called complete. This third case is the most likely outcome.

In light of the confusion surrounding the term, the Study Group decided to describe an “ontology use case” for C-BML. The objective of this description is to provide motivation and justification for expenditure of effort to develop an ontology for the

D R A F T35

D R A F T

concepts and relationships inherent in the C-BML language. There are three fundamental questions to address to scope and execute a use case. Answering these questions should help determine how much can be accomplished and what value it will add.

Question 1: What is the scope of the ontology? We want to eventually provide an ontology of the entire BML domain and would want to start with a simple tasking language component such as “Move Tactical to Specified Location” within the larger BML domain.

Question 2: What are we expecting the ontology to provide? This takes us back to the ontology definition. We would try to provide an exhaustive definition of the domain that we can compute against, that is intelligible to domain experts, and provides correlation back to the real-world. Once we identify the objective we should create some measures of performance and/or effectiveness to evaluate our use case.

Question 3: What format do we want to use to specify the ontology: OWL, LOOM, KIF, UML, etc.? What tools should we use to construct the ontology: Protégé, IODE, or something else? Perhaps this should be a goal of the use case to evaluate the tools and format specification.

Consider the following operational, albeit hypothetical, situation:

A UK Special Operations Forces team identifies a target and enters a call-for-fire (CFF) request using a hand-held device. The CFF request contains target coordinates and requested time on target. Based on the order entered, the hand-held device automatically formats and sends a message, including authentication information on the requesting unit, over satellite communications addressed to a Coalition Fire Support Coordination Center (FSCC). The FSCC approves the request and tasks a US self-propelled robotic artillery platform to perform the mission. This tasking is automatically formatted into a fire order message that is sent to the artillery platform over a radio link. The fire order is received and the weapon system prepares the firing solution and queues the mission to fire to achieve the directed time on target. The weapon system sends a message to the Coalition FSCC when firing commences and when firing is completed. The messages are processed in the FSCC for updates to situational displays. These are automatically routed to the requesting unit, causing an alert to appear on the situation display on the hand-held device.

C-BML plays into this situation in a number of contexts. The initial CFF message would use C-BML to describe the order. Receipt of the message in the Coalition FSCC would also entail recording of the content into a data base, implying possible data processing to extract information from the message to go into a data base or otherwise distributed to various views across the Coalition command structure. The request for fire at a certain location at a certain time on a certain target may convey critical information affecting the status and planning of other commanders and staff across the organization. For example,

D R A F T36

D R A F T

there may be implications on logistics planning to ensure the firing platform’s ammunition level is maintained at an appropriate level, there may be implications to maneuver of other forces in the area (ground or airspace) at the planned time of the fire, knowledge of the planned fire may preclude concern over later reports that might be received about the event from other sources, there may be fire scheduling conflicts for the robotic platform that need to be resolved, etc. Many of these issues can be addressed automatically in the information processing if the data representations carry rich enough semantics. In the case of space-time conflicts, software (in the FSCC or the firing platform, or both) can make the determination that the new mission is in conflict with other planned missions if the semantics of “scheduling conflict” is embedded in the information space.

[Notes from April SIW meeting]

Ontological basis – long term issues – Chuck, Curt, Rob, Angel?, Eugene, Lionel; want to have a use case regarding ontology in the report – from what point are we going to define ontology – missions as black box? Can we include military users in the creation of the ontology? Need use case to better understand how to make the ontology or will not know how to go further. [e.g., maybe something like a call for fire or other report situation] Important part of the report to educate others.

How to address ontology within the C-BML. Want to be able to see where operational experts will be needed in future work on this area. Need to be able to spell out the process for development of an ontology in the military operational context. Use case: Army context, maybe with robots best to have coalition based. E.g., Arty CFF (UK calling for fire with USMC providing CAS). Contact report, call-for-fire. Keep simple – main thing is to shed light on the process for creating the ontology.

Maybe start with C2IEDM to create the basis for the ontology so we can add constraints, relationships, rules, etc.

Maybe there are products from the Conceptual Model of the Mission Space.Possibly SUMO military operations efforts.

How ontology assists in generation of C-BML for information interchange. Where it fits in the big picture. What it is capable of near term; why is it not ready (if that is the case).Will need recommendation from the “ontology team” within a month on how the report will get done.

Sometimes need to see the “art of the possible” before the operational users can identify what they want.

D R A F T37

D R A F T

5 Recommendations

The Study Group recommends nomination of the C-BML Specification to Product Development under auspices of SISO. Etc….

A draft Product Nomination is provided in Appendix B as a starting point for moving the standard forward.

D R A F T38

D R A F T

- 39 - D R A F T

D R A F T

Appendix A

March 2005 C-BML Study Group Meeting Report

Report on theSimulation Interoperability Standards Organization

Coalition Battle Management Language Study GroupFace-to-Face Meeting

March 7-9, 2005

Virginia Modeling Analysis & Simulation Center (VMASC)

Old Dominion University, Norfolk, VA, U.S.A.

By: Dr. Andreas Tolk

Study Group Officers

Co-Chair: Major Kevin Galvin

Co-Chair: Dr. Michael R. Hieb

Vice Chair: Dr. Andreas Tolk

Secretary: Charles D. Turnitsa

Report: 532921-2005/01Date: March 22, 2005

- 40 - D R A F T

D R A F T

Executive Summary

The Study Group on Coalition Battle Management Language (BML) of the Simulation Interoperability Standards Organization (SISO) met at the Virginia Modeling Analysis and Simulation center (VMASC) of Old Dominion University (ODU), Norfolk, Virginia, U.S.A., on March 7-9, 2005. The meeting was chaired by Major Kevin and hosted by Dr. Andreas Tolk. Scott Hanson represented the Standards Activity Committee (SAC) of SISO.

This face-to-face meeting brought 35 international experts together. Five universities (Carnegie Mellon University, George Mason University, Naval Postgraduate School, Old Dominion University, and the University of Texas) participated in the event; represented nations were Canada, France, Germany, Sweden, United Kingdom, and United States.

The statement of work for the C-BML study group was accepted by the Standards Activity Committee and identifies the following tasks:

The study group shall conduct a Paper Survey comprising as many international contributions applicable to the C-BML effort as possible.

The study group shall develop a Plan of how these various efforts identified in task one can contribute to a common C-BML standard/standard framework.

The study group shall formulate a set of Recommendations on how to proceed toward a C-BML Product Development Group.

The products resulting from the establishment and execution of these tasks shall include, but one not limited to:

a literature survey summarizing the results of the first task, and; a final report, to be delivered during the SIW Fall 2005, which summarizes the

results of the second and third tasks.

The Command, Control, Communication, Computers, and Intelligence (C4I) forum sponsors this study group. In addition to its SISO membership, the study group collaborates with other organizations with potential interest in this work.

This meeting was targeted to contribute to the survey task, to identify additional groups that are interested in the C-BML work, and to continue the discussion of alternative views for a common C-BML standard/standard framework. To this end, 15 presentations were given and discussed. The variety and breadth of presentations demonstrated that numerous schools and agencies across several countries are exploring interoperability issues relevant to the C-BML study.

- 41 - D R A F T

D R A F T

A.1 OverviewThe Simulation Interoperability Standards Organization (SISO) is responsible for the identification of applicable standards to support distributed simulation in all simulation domains and to develop standards in case no available standards are applicable to fulfill the community’s interoperability needs. These objectives are achieved by:

Presentations during the Simulation Interoperability Workshops (SIW)o Identifying requirements and respective interoperability gapso Exemplifying solution possibility in prototypeso Demonstrating applicability of standards

Evaluating interoperability domains in depth in Study Groups thato Conduct surveys of the related domainso Develop plans on how to reach consensuso Identify potential solutions

Preparing standards in Product Development Groups.

Within the last three years, multiple papers have dealt with the need for, and potential contributions to, interoperability in the domain of M&S-to-C2-Interoperability based on the use of unambiguous information exchange definitions. The concept of Battle Management Language (BML) was discussed during several workshops. During the Spring SIW 2004, a meeting of subject matter experts decided that a detailed evaluation of C-BML efforts is necessary and drafted a statement of work. This statement of work for the C-BML study group was accepted by the Standards Activity Committee and identifies the following tasks:

Task 1. The study group shall conduct a Survey comprising as many international contributions applicable to the Coalition Battle Management Language effort as possible.

Task 2. The study group shall develop a plan of how these various efforts identified in task one can contribute to a common C-BML standard/standard framework.

Task 3. The study group shall formulate a set of Recommendations for a C-BML Product Development Group.

The products resulting from the establishment and execution of these tasks shall include, but are not limited to:

A literature survey summarizing the results of the first task, and; A final report, to be delivered during the SIW Fall 2005, which

summarizes the results of the second and third tasks.

The Command, Control, Communication, Computers, and Intelligence (C4I) Forum is sponsoring this study group. In addition to its SISO membership, the study group collaborates with other organizations with potential interest in this work, in particular the North Atlantic Treaty Organization (NATO) and the Command and Control Research Technology Symposium (CCRTS) groups interested in this topic.

- 42 - D R A F T

D R A F T

The C-BML Study Group formally began work at the Fall SIW 2004. It will submit an interim report at the 2005 Spring SIW, and will complete work and submit a final report to the EXCOM, SAC and CC by the 2005 Fall SIW. In addition to electronic collaboration facilitated by use of the SISO web site, interim meetings are held in conjunction with other M&S-related conferences during the period of performance.

During the kick-off meeting in Fall 2004, it was decided to have a first interim meeting during the I/ITSEC 2004 in December 2004 in Orlando, Florida. This meeting was held in collaboration with a NATO pre-kickoff-meeting on the same topic. During the NATO Modeling & Simulation Group (MSG) meeting in October 2004 in Koblenz, Germany, the MSG decided to set up an expert team to evaluate the applicability of BML ideas for the alliance in form of an Exploratory Team (ET-016). The official kick-off for this activity took place in February 2005 in Paris, France.

As the time for discussions and presentations during the official SIW meetings is always limited, and because the meeting in Orlando during I/ITSEC showed a tremendous international interest in BML– another face-to-face meeting was planned to be conducted in March 2005 at the Virginia Modeling Analysis and Simulation Center (VMASC) with room for presentation by potential contributors and time for the discussion of ideas.

This meeting focused on the survey task of identifying possible international contributions applicable to the C-BML effort. Besides the SISO experts and members of the study group, invitations were sent to other subject matter experts, in particular the authors of the soon to be published special issue of the Journal on Transactions on Simulations, Society for Modeling and Simulation (SCS), on “Military Simulation Systems and Command and Control Systems Interoperability.” Another aspect was consensus based work of the Multilateral Interoperability Programme (MIP) and the Command and Control Information Exchange Data Model (C2IEDM) – both identified as potential contributions to broader M&S-to-C2 solutions in previous NATO and SISO conferences.

This face-to-face meeting was held at VMASC in Norfolk, VA, on March 7-9, 2005. The meeting was chaired by Major Kevin Galvin and hosted by Dr. Andreas Tolk. Scott Hanson represented the Standards Activity Committee (SAC) of SISO. It brought 35 international experts together. Five universities (Carnegie Mellon University, George Mason University, Naval Postgraduate School, Old Dominion University, and the University of Texas) participated in the event; six nations participated (Canada, France, Germany, Sweden, United Kingdom, and United States).

- 43 - D R A F T

D R A F T

A.2 Overview of the PresentationsAs stated before, the main objective of this meeting was to gather information for the survey that has to be conducted under the statement of work for the C-BML Study Group. Invitations were sent out to experts in the domain of BML and related domains. In addition to this, all members of the Study Group were invited. The following table shows the experts who participated in this meeting:

Table 1: Workshop Participants

Name First Affiliation NationalityAbbott Jeff IDE USBlais Curt NPS MOVES Institute USBrown Dick US Army USCarlton Bruce Univ Texas USCole Casey Univ Texas USDe Champs Patrick EADS FranceDiallo Saikou VMASC Guinea/US

Doris Ken Applied Visions, Inc. USDupigny Kevin VMASC USGalvin Kevin QinetiQ UKGarcia Johnny General Dynamics USGates Burhman US Army ERDC (Common Maneuver Networks) USGiampapa Joe CMU USGustavson Per Ericson SwedenHanson Norman NGC Tactical Systems Division USHansen Scott NGC / Representing the SISO SAC USHauck Lloyd US Army (Topographic Engineering Center) USHsu Chia-Ming NGC Taiwan/US

Joseph Eugene North Side Inc. CanadaLiebert Karl Boeing USMerrit Jerry Raytheon USMorley Paul US Army Threat Systems Management Office USMuguira James VMASC USO'May Janet US Army Research Lab USPereira Lisa General Dynamics USPowers Mike US Army (Topographic Engineering Center) USPullen Mark GMU C3I Center USSalcedo Claude USAF - AFC2A, Langley AFB USSnyder Dan J9 / JFCOM USStein Mike US Army (Topographic Engineering Center) USSudnikovich Bill ACS USTolk Andreas VMASC Germany/US

Turnitsa Chuck VMASC USWade Raymond J7 / JFCOM USWittman Rob MITRE/OOS US

During the first day, all participants presented their organization and their interest in C-BML issues. Among the topics of common interest were the Command and Control Information Exchange Data Model (C2IEDM) and additional standards, in particular the Foreign national working for US agencies.

- 44 - D R A F T

D R A F T

US DoD Interface Standard MIL-STD-2525B. Furthermore, the specification of terrain was a common topic, raising issues concerning the relation of BML with SEDRIS and emerging ideas, such as the Geospatial Mark-up Language (GML).

The German IT Office declared interest, but was not able to send an officer to the meeting. Nonetheless, they committed to send information on related German efforts not later than during the upcoming next C-BML meeting during the Spring SIW 2005 in April in San Diego, CA.

All presentations are published on the Face-to-Face Minutes websites, <http://www.vmasc.odu.edu/coalitionbml/cobml_overview.html>.

A.2.1 Presentations of March 7, 2005

The first day was used to bring every participant “to the same level.” Andreas Tolk gave a short overview on the structure of SISO, the role of product development groups and study groups for standardization in general, and the role of the study group on C-BML in particular.

The chair of the study group, Major Kevin Galvin (UK Army), gave on overview on the objectives of C-BML, focusing on the overall need to develop a standard framework for M&S and Command & Control interoperability (of which BML is only a part) and the need to have a connection to the warfighter, such as the 5Ws to structure executable orders (who, what, where, when, why). He also addressed the need to develop an XML vocabulary as part of BML, based on C2IEDM XML tags, which need to be identified.

Bill Sudnikovich gave an overview on the current US work on BML. He supports the US BML work since the first prototype, starting with the feasibility demonstration initiated by the US Army Simulation C2 Interoperability Overarching Integrated Product Team (SIMCI OIPT) group. He gave an overview on the BML work as described in detail in the published reports listed in Annex A.

The presentation of Bill Sudnikovich identified several current research domains, such as the necessity to extend the C2IEDM in order to cope with all information exchange requests based on national concern issues; the challenge of coping with matching the eligibility of similar units for given tasks; how to handle the requirement to add tasks from other types of units or even to add a new task (as often observed during peace and stability operations); using ontological layers for cross-checking assets and their capabilities versus tasks; and more.

Andreas Tolk summarized these points and referred to the current work on Data Engineering addressing some of the issues. He also summarized the ideas on how to use the C2IEDM as a common information exchange reference data model for Model Based Data Management.

A.2.2 Presentations - March 8, 2005

- 45 - D R A F T

D R A F T

The second day was used for presentations on related topics, which must be evaluated during the study group to determine the connection of their initiatives to C-BML.

Johnny Garcia from General Dynamics, Advanced Information Systems, is currently a Ph.D. student in the M&S program of ODU with the Virginia Modeling Analyses & Simulation Center. Under supervision of the Andreas Tolk, he conducted an independent study on the C2SR/Simulation Technical Reference Model (C2SR/Sim TRM) and its applicability for a broader framework as proposed in the final report of the respective SISO study group. He presented initial results on how the taxonomy as currently defined in the TRM can be adapted and refined for C-BML. The results are summarized in his paper 05S-SIW-011, to be presented during the Spring SIW in San Diego, CA, in April 2005.

Chuck Turnitsa is the VMASC Battle Lab Manager and a research scientist at VMASC. He is also enrolled in the M&S program of ODU. Under the supervision of Dr. Andreas Tolk, he is conducting research on ontologies of data models, focusing mainly on the use of C2IEDM as core ontology for the Command & Control domain. The research is conducted within an independent study and final results will be presented during the upcoming European SIW in Toulouse, France. Ontology is interpreted as a formulation of an exhaustive and rigorous conceptual schema within a given domain. The core of the this research is the analysis of the object-item and object-type concepts and the action concept and its ability to cope with similar issues as C-BML challenges, such as “what units can be used to fulfill a given task?” and “what units will be affected in a similar way by an event?” Entities are seen as concepts that have addressable properties, and actions are seen as concepts that allow entities to do things and to relate to each other; as such they can be interpreted as subjects and predicates. In summary, C2IEDM can be a valuable core for ontologies, but needs to be extended.

Patrick De Champs presented two related efforts in his presentation: the NATO MSG Exploratory Team effort (ET-016) – which is likely to become the MSG technical activity (designated MSG040) in Fall 2005 – and the French program APLET, which is very similar to the US Army BML prototype.

The main ideas for NATO C-BML were proposed and accepted during the NATO MSG meeting in October 2004 in Koblenz, Germany, and the ET-016 initiative was kicked-off in February 2005 in Paris, France. The objectives of ET-016 are to investigate NATO nation interest in C-BML; propose a Technical Activity Program (TAP) and Terms of Reference (TOR) to the NATO MSG for the creation of a Technical Activity (TA); initiate a Program of Work (POW) and set-up a limited C-BML demonstration. The documents produced by the ET will be submitted to the NATO MSG during a Fall 05 meeting. ET-016 sees the C-BML study group as a supporting effort working on BML standardization.

The French efforts in this domain have been presented in various papers during recent SIW workshops, summarized under the acronym APLET for "Aide à la PLanification

- 46 - D R A F T

D R A F T

d’Engagement Tactique." APLET is a French Ministry of Defense (MoD) R&T program, which aims to investigate the capabilities offered by M&S for its integration into an existing Brigade level C2 system for Courses of Action Analysis (COAA) purposes. In addition, this program is dedicated to exploring the technical issues of C2-M&S coupling and to providing recommendations for M&S interfaces, models, and data models to overcome the gap between current M&S and legacy C2. A series of demonstrations are being developed to prove the feasibility and demonstrate the technical approaches recommended for future use. APLETs main objectives are to automate the Military Decision-Making Process for Course of Action Analysis; to foresee capabilities and added value by simulations when closely integrated with C2 systems (the French C2 system used is SICF), to explore and solve C2-simulation inter-operability issues and propose recommendations to bridge the gap between those systems, to define the most suitable simulation granularity allowing Courses of Action Analysis in compressed time, to experiment with new algorithms such as RDE (Reaction Diffusion Equation), and to propose mechanisms to automatically produce Operation Orders from a selected Course of Action.

The connection between APLET and the US BML goes back to a series of SIW presentations where both initiatives became aware of each other. The idea for a common project was born during the I/ITSEC 2003 presentation of the Extensible BML (XBML) prototype showing the potential to couple the French with the US approach. This resulted in a common NATO proposal, which was accepted.

Bruce Carlton is a scientist at the Applied Research Lab (ARL) of the University of Texas. He presented the Army C2 and Simulation Initialization System (ACSIS). The objective of ACSIS is to combine various authorized data domains into a common access server for the warfighter to initialize C2 systems. This approach is applicable to simulation systems as well, although the main focus was initially the Command and Control community. ACSIS shall help to reduce planning time for setting up a scenario to 96 hours by placing better tools in the hands of the soldier. Currently, the production of initialization data products for real-world and training exercises is problematic and time consuming. State of the art is a reduction from 11-20 months to 3-6 months for setting up a brigade-size exercise. The current ACSIS repository comprises authoritative data and integrated tools to initialize all ABCS 6.x systems and their supporting simulations, but is limited to a subset of the StartEx scenario file (the force structure and the network systems architecture, comprising units, platforms, networks, links). ACSIS evaluated C2IEDM as a “neutral language” using the XML schema defined by the Institute for Defense Analysis (IDA) from the DoD Metadata registry. To prove the feasibility of the approach to exchange data based on C2IEDM within the JWARS-GCCS COA monitoring and alert system experiment, ACSIS data was accessed via a web service: an expanded schema to support Time Phased Force Deployment Data (TPFDD) and Type Unit Characteristics (TUCHA) mapped the ACSIS database schema to C2IEDM XML conformant to the IDA XML for the physical GH6 schema. Another interesting aspect is the idea of the Force Management System (FMS) – future web access to force structure data, in which each service will have an organizational server to provide a single repository for approved Army organizational structures and unit resource

- 47 - D R A F T

D R A F T

allocation information down to the individual Billet and Asset level for use by other data systems using the Enterprise Wide Identifier (EwID) for each unit, subunit, and individual resource.

Dr. Rob Wittman is a MITRE expert who supports the Military Scenario Definition Language (MSDL) effort and the OneSAF Objective System (OOS) environment in Orlando, FL. He is starting to develop a BML Tasking Language for OOS. This is necessary because business rules normally are not part of the data model, although the play an important role in defining terms and strategy. To this end, he distinguishes language, grammar, and sentences. A language is a means to communicate using a defined set of words and rules (Encarta Dictionary), and a grammar comprises rules that determine how words are formed and used to make sentences. Sentences are sequences of words. In this sense, BML is not yet a completely defined language but only a grammar, which is sufficient for the OOS objectives. He presented BML and MSDL as mutually supporting ideas: BML for operational Command & Control information exchange including scenario-based information, and MSDL for simulation initialization including Command & Control tasking information. Both worlds can be interconnected by definition of a common grammar or translation between grammars supporting the interchange between MSDL and BML information. A demonstration at I/ITSEC 2005 by PEO STRI will show an end-to-end simulation scenario and execution leveraging BML and MSDL use of a tasking language. In summary, BML, MSDL, and a tasking language are all necessary to support the broader framework.

Jeff Abbott is the OneSAF Military Scenario Definition Environment (MSDE) Task Order Lead. He presented an MSDL Tasking Methodology as part of MSDE. MSDL is targeting common scenario development including unambiguous task identification, definition of objects and actors, task modifiers to adapt earlier plans to current developments, and generally the definition of object bounds and role modifiers. The latter idea is similar to that of Turnitsa on the need to define similarities within BML to cope with the demands of modern operations. The core idea of MSDL is to be an application independent taxonomy. Military scenarios are defined as the description of the current situation and future different courses of action, which translates into initial ground truth and ready to be executed orders in the simulation initialization data set. The work started in 2002 with the evaluation of the CCTT Exercise Initialization Tool scenario format, which resulted in the removal of the CCTT specific data. The Army Universal Task List (AUTL) was selected because it represents a “doctrine agnostic” tasking language within the scope of the US Army. In addition, the AUTL Task Titles provide the source of task enumerations enabling to work out compliance matrices. BML needs a specification and reference implementations to ensure the ability to measure compliance to the standard. The MSDL group currently is establishing a SISO Study Group.

Per Gustavson is employed by Ericson to support the Swedish Armed Forces with M&S knowledge. In addition, he is working on his Ph.D. in related M&S domains. He is interested in the C-BML efforts mainly to integrate Swedish capabilities into coalition operations in an effective and efficient manner. He used the “Level of Conceptual

- 48 - D R A F T

D R A F T

Interoperability Model (LCIM)” as his reference model, stating that conceptual or at least pragmatic interoperability is needed. In Sweden, the driving force for transformation is change in the world: new social progress, technology innovations, changes in the political will, and so on. All this drives Sweden towards net-capable solutions for future Command & Control as well as simulation. C-BML fits well in this picture, as it expresses intention across nations, forces, and domains, is persistent and is expandable upwards and downwards. Ultimately, the use of ontologies or as least taxonomies (as defined in Tolk/Blais 05S-SIW-007) will be necessary.

Curt Blais is a Research Associate Professor and Ph.D. candidate in the MOVES Institute at the Naval Postgraduate School in Monterey, CA. He presented work on related C2IEDM/BML activities at NPS, concentrating on Operations Order and maneuver network data interchange. NPS was among the first organizations to evaluate automated generation of XML tag sets based on the C2IEDM data model; this work has been documented in various master theses since 2001. Another aspect is the work on related efforts to make XML applicable in tactical systems through binary representations (e.g., XML Schema-based Binary Compression) that can conserve bandwidth while maintaining the information processing gains from XML’s structure and ubiquity. Finally, he presented basic work on the use of C2IEDM as the ontological core for a Navy BML which will enable joint interoperability with the US Army and Air Force efforts as well as the NATO ET-016.

Burhman Gates supports the US Army/ERDC on the Common Maneuver Networks Project and was interested in the applicability of C2IEDM in general, and BML in particular, for planning and optimizing of maneuver networks (the network of routes for units). BML currently decomposes executable orders in the 5Ws: Who, What, Where, When, Why. Although the “Where” information in a mission order generally refers to the location of the objective, this is not sufficient for Common Maneuver Networks and the need for specific route planning, where a coordinated task decomposition as proposed by the Military Missions-to-Means Framework (MMF) is necessary. While the MMF is situated on the strategic-operational level, Common Maneuver Networks target the tactical level. The introduction of additional components “How” and “Which (resources)”, as recommended by the US/GE bi-national SINCE project, may be of interest. On the other side, the C2IEDM already has the necessary structures to cope with such a task in a standardized way, but additional collaboration is necessary to evaluate this in detail. Furthermore, the need for a “GeoBML” was expressed, which not only considers the constraints of the terrain but also adds tactical constraints. In particular, terrain abstraction and relevant environmental effects are of interest.

Mike Stein works for the US Army ERDC (Topographic Engineering Center). He also expressed interest in more terrain context within BML efforts. The work presented by him focuses on terrain-based reasoning on the tactical level. ERDC-TEC is interested in C2IEDM, in particular the extensions using the SEDRIS Environment Data Coding Specification (EDCS) definitions. However, due to the lack of public availability of this work, an evaluation has not yet been conducted. He proposed a terrain reasoning framework consisting of a layered approached utilizing a Hierarchical Intelligent Terrain

- 49 - D R A F T

D R A F T

Situation (HITS) Architecture. This architecture supports a range of uses from terrain building tools to understanding the tactical importance of terrain. Other uses supported by the architecture are the development of an automated planning tool that works with terrain compartments (an area that has common feature throughout), situational objects and finally with GIS objects as observed by sensors. While the transportation of raw data usually requires high bandwidth, the transportation of derived knowledge only requires low bandwidth. As applications generally don’t need the raw data but rather the information or knowledge about the terrain, a combination of a bottom-up (data-driven) approach delivering top-down (mission-driven) required knowledge components seems to be the best way to go. To this end, the primary purpose of HITS is to ensure an ontological segmentation of terrain related to unit task organization and purpose. A close relationship to C-BML is perceived to be very promising for both sides.

Paul Morley works for the US Army Threat Systems Management Office and is supported by Lisa Pereira (General Dynamics) for work on the Intelligence M&S for Evaluation (IMASE) Scenario Generation Tool (ISGT). IMASE is planned to replace M&S provided by Tactical Simulation Operation Test (TACSIM-OT). ISGT should support the rapid generation of operational test threat scenarios for system testing of US Army Intelligence and Electronic Warfare (IEW) Systems. ISGT describes scenarios in XML. Collaboration with MSDL to support OOS is underway.

In summary, the presentations of this second day showed the broad interest in C-BML efforts as well as the need for a broad scope, which must be addressed either by clear definitions of domains of interest or applicable standards for these domains. In particular the need to take terrain much more into account than currently is the case was apparent in several presentations.

A.2.3 Presentations - March 9, 2005

The presentations on the third day were given by invited experts in domains that will shape the BML discussion on the mid and long term – general integration frameworks on the industrial scale such as the one used by Northrop Grumman; the application of natural language parsers; and the requirements of intelligent software agents as developed by Carnegie Mellon University.

Chia-Ming Hsu presented the Si3 Service Integration Interoperation Infrastructure, which is a service-oriented architecture framework for defense applications used by the Northrop Grumman Corporation. Experience shows that integration of M&S applications is approximately 50% of their business. A key feature is a capability that results in no change to legacy models; that’s why the web service approach based on XML interfaces was chosen. This approach migrates M&S applications, Systems of Systems, and databases into distributed services, which can be composed. He is interested in the XML based C2IEDM centric data mediation services, as they will be applied in the NATO ET-016 experiment.

- 50 - D R A F T

D R A F T

Eugene Joseph from North Side, Inc., Montreal, Canada, presented his work on Natural Language Interfaces to C2SR, Simulations, and other Intelligent Systems. He is supported by the University of Montreal (Computer Linguistics Lab). While the semantic understanding of English at large is still unsolved, demonstratable success can be reached by the use of simple English for Command & Control. By simple, it is meant constrained in the number of Lexical Units supported, but not constrained syntactically, to allow for natural expression.

The incorporation of C2IEDM into the North Side work will be done after more basic issues of dealing with object existence, temporal issues, locality, modality and so on are completed. The approach to BML as defined in SINCE (using the "W6H approach" which means extracting Who, What, Where, When, Why, How, Which information from a text) is followed. This W6H information will be encoded formally, using a high granularity data model. When a formal definition of BML will be available, it is expected that we will be able to demonstrate immediately the ability to output such W6H information using the future BML formalism.

North Side evaluated two Ontologies: SUMO and OpenCyc, and did not evaluate Dolce, which does not lend itself to NLP work. As these are Upper Ontologies, the levels covered by the C2IEDM are not represented in these ontologies, and an integration effort will be required. North Side is working currently on such an integration.

The problem of Verification and Validation of Natural Language front-ends to BML will mostly be in the area of end-to-end Validation. This means that the Validation effort will have to focus on the correct translation of the Commander's intent into the appropriate orders or the appropriate simulation. A classical Validation effort, based on numerous scenarios will be required to accomplish this.

The fact that legal BML is generated (verification) is a more mechanical issue. Once BML is defined as a formal language, the process of verifying it should be straightforward.

The final presentation of day three was given by Joe Giampapa, who works for the Robotics Institute of Carnegie Mellon University. His presentation gave an overview on current research in the domain of control languages as used for robots and how they are applicable in the broader context of BML work. The ideas of ontologies and the Semantic Web formed the framework for this project. The core idea is to transform Internet technology from presenting information to providing services in a general reusable way. In the same way that browsers display information today on heterogeneous platforms for users, this “service net” will provide more general services to the user in the future. In this “service net”, intelligent software agents proactively assist humans based on their awareness of the user’s goals and context. Joe Giampapa presented the current work on RETSINA and CoABS, giving additional references. One of the most interesting results was the necessity to add dynamic behavior to service descriptions. Even higher conceptual frames such as OWL (W3C’s Web Ontology Language) need

- 51 - D R A F T

D R A F T

extensions to cope with dynamic challenges beyond pragmatic and semantic challenges, as can be handled by ontologies.

In summary, these presentations were a good basis to initiate a discussion on the scope of C-BML. While the second day presentations identified additional domains to be covered (in particular a closer look at terrain and it constraints), the third day presentations challenged the study group with more fundamental questions regarding the support of all levels of interoperability and broad applicability in future infrastructures.

- 52 - D R A F T

D R A F T

A.3 Discussion Points on March 9, 2005

Although the main objective of this meeting was not consensus building on how the presentations will influence the work of C-BML, a first discussion was conducted to collect input for the more structured approach planned for the C-BML meetings during the Spring SIW meeting in April 2005 in San Diego, CA, and the Euro SIW meeting in June 2005 in Toulouse, France.

All participants of the workshop were asked to prepare a half page to a one page summary on their topic focusing on three points:

Problem statement: What is the problem to be solved by their approach? Solution statement: What are the assumptions and constraints are made and what

is the resulting solution? Relevance statement: How is this solution relevant to the C-BML efforts? All

contributions should keep in mind that we are in particular interested in standards applicable in the coalition domain, which means national standards and solutions are only of limited interest.

A.3.1 Preparation of the Interim Study Report for Spring SIW 2005

Three tasks have to be accomplished until Fall 2005, namely:

Task One: Assessing Currently Ongoing Efforts: This would seem to be the easiest of the three tasks and as a result of the creation of the Study Group it has provided a focus for others to inform us of their efforts in developing a BML. What seems to be common is the use of XML and C2IEDM, and there are other efforts that have the same aims such as the Military Scenario Definition Language (MSDL) but with a different focus. There is also a growing recognition, as various nations embark on the Digitization trail, that we have to add structure to the BML that we use today if we want to use simulation to stimulate operational C2 systems, or in the Military Decision Making Process (MDMP) for Course of Action Analysis and Mission Rehearsal. Recognising the need is one thing but providing adequate funding at a time when many of our countries are engaged in military operations throughout the world is a challenge.

Task Two: Evaluation a Standard Framework: Developing a standard framework is perhaps the more challenging aspect of the study. What is a “Standard Framework” or do we mean a “Framework of Standards”? A pure Command and Control BML is only part of the framework of C2 to M&S interoperability. Others include Terrain and other Geospatial data, and Scenario Generation. Both of them need BML and vice-versa. What is a BML specification? When we define a language, do we define grammar and a dictionary or do we need other formalisms? The 5W format is the first step in developing a specification, but what is needed in addition?

- 53 - D R A F T

D R A F T

Task Three: Recommend Steps to Form a C-BML Product Development Group: Should be able to identify a set of applicable standards such as XML, Web Services (SOAP, XML Schemas, etc), Data Models (C2IEDM?), and so on. Identify in addition R&D areas such as Ontologies, Task Language Grammars, etc. Need to recommend PDG activities.

The study report must summarize the findings of all three tasks. The current objective of the officers of the study group is to finalize a first “straw man” during the Spring SIW 2005 in San Diego, CA, and to add more information during the Euro SIW 2005 in Toulouse, France. The report must be finalized in Fall 2005 for the SIW in Orlando, FL. The “homework assignments” as specified in the beginning of this chapter will contribute to reach these objectives.

A.3.2 Necessity of the Protocol View

The first discussion point was if the protocol view is necessary in the context of a BML specification. The definition of this view was first published in the paper 04F-SIW-103. Three views were postulated as necessary to describe BML:

(1) A Doctrine View – BML must be aligned to doctrine;(2) A Representation View – BML must model these aspects in a way that can be

interpreted and processed by the underlying heterogeneous information technology systems of the coalition;

(3) A Protocol View – BML must specify the underlying protocols for transferring BML information between participating systems.

These views are specified in more detail in the paper referenced.

The necessity to identify an underlying protocol in the specification of BML, was discussed during the meeting. The main argument for a protocol view is that a common protocol is the basis of interoperability. If the user can choose between different protocols, additional mappings are necessary and may result in ambiguous results. A common protocol can insure technical and syntactic interoperability and – when using a common reference data model – even semantic interoperability. C2IEDM, XML, and web services seem to be a preferred and widely accepted representation for the initial phase and are extensible enough to suit other needs than those currently specified.

The main argument against a protocol view is that the protocol limits users of BML too much. Some may prefer to use their own protocols and standards, such as HLA OMT or C2-related standards – and may not want to migrate towards XML and web services. This results in the protocol view making the specification more complicated than necessary. In summary, BML should allow any protocol to be used; it might have an example implementation in web services, but must be able to evolve as technology evolves.

- 54 - D R A F T

D R A F T

Both sides have valid arguments and it will be part of the discussion during the next SIW meetings to establish a consensus for the study group.

A.3.3 What is the Content of BML?

Without doubt, the main first step of BML must be a specification for executable tasks, as this is the core piece of battle management: producing orders and tasks that are understood and can be equally executed by soldiers, simulated forces, and robots.

The initial BML core is based on the 5Ws concept, which focuses on identifying the organizations, what actions they can perform, where and when they do it, and “why” in free text, sometimes in context containers, sometimes in additional tables. It was discussed if we already know what content and what aspects of that content are needed for BML purposes (missions, orders and Command & Control), or how to consume an operations order in an unambiguous manner. The US BML work started with the Army and tried to extend to the Air Force (with some difficulty) and Navy (to be started), and is also moving to Coalition Operations. To be successful, these examples are desirable and necessary to gain an understanding of the problem, but we need to define a reproducible and understandable method and supporting tools to be successful with a general solution. We want to make business rules understandable by applications so they can be used by the applications, and these must be part of BML as well. Furthermore, representation and communication of the Commander’s intent is really the desired end state, not the process to achieve it in BML. Determining if this is sufficient must be part of more research, as well as discussions with the operational users of BML.

We gained consensus that at least for now we want to retain focus on unambiguous communications between live and constructive forces, and robotic systems; unambiguous C2/Sim communications resulting in executable orders. This discussion is directly connected to the next discussion issue: Do we want to define BML now, or do we already anticipate a standard that is designed to be improved gradually in several phases?

A.3.4 Phased Approach to Define C-BML

While everyone agreed that a broader BML is a better BML, we also realized that we need to take BML forward through consensus and that we cannot afford to allow what has been achieved to date to “sit on the shelf” only for a new set of “innovative young scientists” to start from scratch in five years time. Furthermore, BML needs to be independent of the C2 and the simulations so that we can take forward what is needed by the users (not by the projects and implementations). But we have to recognize that today projects have had to find solutions to meet a specific need. Finally, BML must provide a solution to enable coalition operations to take place.

We reached consensus that a phased approach is necessary. What these phases will be and what the sub-objectives of these phases will be must be discussed during the upcoming meetings. A flexible implementation similar to the OIPT model as used by the US Army SIMCI group may be a way to go under the umbrella of SISO.

- 55 - D R A F T

D R A F T

A.3.5 Additional Observations

The following discussion points were captured by the report writers and are not part of the main four discussion points; however, they are too important to be ignored.

The BML-MSDL integration is critical to ensure close coordination between BML and MSDL. MSDL, as a standard, needs to be divorced from OneSAF.

We have to accept that we cannot do everything at once so need to prioritize – suggest 5W construct is a good starting point but recognize that we will need 6W+H some time in the future particularly in commanding robotic forces. Should also realize that the Why (Commander’s Intent) remains for the present “free text”.

GeoBML is an important piece of the jigsaw puzzle as ultimately is Natural Language Scripting.

BML and by extension C2IEDM are used in a variety of activities that deal with different parts of the battle space at different resolutions.

BML should be able to support the 6W+H in order to make it simulation compatible (no matter what kind of simulation).

C2IEDM in its current version (and future – JC3IEDM) should remain the interchange Data Model, because it is designed with that purpose in mind (more than sixteen nations have participated in the effort). It is not complete for now but it is encompassing enough to be representative.

Participants of the C-BML should be aware that BML is a composition of ontologies (model of different views of the battle space) not a language in the computer science point of view. It provides the necessary vocabulary for Command and Control, but the associations and combinations (methods and functions) that lend meaning to a vocabulary have to be implemented as client interfaces.

A standard mapping process from any data model to BML should be designed and approved by the workshop members. Similarly a standard approach to mapping to the C2IEDM model should be presented. By standardizing these approaches, we mean that the data engineering process should be followed explicitly.

Service Oriented Architectures (SOA) should be the preferred implementation method for interoperable systems. Web services are one of the implementations of SOA; however, they are not the SOA. This gives BML the potential to be integrated within the GIG without having to make changes to its architecture. It also keeps BML within the framework of new technologies such as the semantic web project currently under way (a standard will be approved soon by the W3C). Once again it is important that participants understand that SOA does not mean web services, SOAP and XML.

The natural language ideas while important for ease of use should not affect the data models (BML or C2IEDM) but rather add another level of abstraction. Therefore special care should be taken that: (a) BML and/or C2IEDM support the language, view and resolution level provided by the commander using natural language; (b) the data derived from the natural language level should be

- 56 - D R A F T

D R A F T

consistent with not only the true intent expressed by the commander but also the structure of BML for C2 orders.

Natural language processors should go through a meticulous internal VV&A before they can be accepted as a safe way to issue C2 orders. In addition GeoBML and other uses of the BML are part of the data engineering process.

Should there be other nations involved? The XBML effort will be presented in Australia at SIMTECT. Also, there may be interest from Korea and Singapore.

We need more participation from Air Force and Navy (and Marine Corps), also more Joint support. We hope to get input from NATO ET-016 and others.

- 57 - D R A F T

D R A F T

A.4 Summary

The face-to-face meeting was a success. It could have been improved by having the presentations a little bit earlier to prepare discussions and group them more efficiently, but he objectives of the workshop were reached.

All information will be made available to the SISO Study Group on C-BML via the reflector and generally via a VMASC supported website <http://www.vmasc.odu.edu/coalitionbml/cobml_overview.html>.

- 58 - D R A F T

D R A F T

Appendix B

SISO Product Nomination Form

Please complete this form and submit to the Chair of the SISO Standards Activity Committee (SAC) or email it to [email protected]

1. Product Nomination Title:Coalition Battle Management Language

2. Proponent Name (s) and Contact Information:

First Name: Mike Last Name: Hieb

Affiliation:

Street Address:

City: State: Zip:

Phone #: FAX #:

Email Address:

Additional Proponent(s)Kevin Galvin, Andreas Tolk, Mark Pullen, Lionel Khimeche

3. Type of Product:

Standard XGuidance XReferenceAdministrative

4. Identification of the community to which product applies:

Describe the M&S community that will use and benefit from this product.The Training, Experimentation and Operational Analysis and Testing parts of the M&S community. In addition this standard will provide benefit to a much wider community that includes the C2/C4I and international/coalition

- 59 - D R A F T

D R A F T

5. Problem(s) and/or issue(s) that the proposed product addresses:

a. Provide details on the specific need or requirement for this product in the community:

There is no applicable standard that resolves the interoperability between C2 and simulation.

b. Provide details on the discussion of the need for this product in the community.There is considerable discussion on this subject for a number of years and this as lead to the creation of a NATO ET that is etc. The community is now ready to move forward to develop an appropriate standard based on initial Proof of Principle work in the US, France and other nations.

c. List similar products in the community you have investigated to ensure that no overlap exists.

Military Scenario Definition Language (MSDL) Study Group is proposing the developing of MSDL as a Product Nomination.

MIP/C2IEDM has the scope but lacks conciseness for human interpretation

DIS and RPR standards have been looked at (Exercise Management) and it has been determined they lack scope for C2-Simulation interoperability.

6. Maturity of the Proposed Product–Provide indication of the maturity of proposed product - to include alternatives, prototypes, impacts of product, and the impact of lack of product:

a. Detailed description on HOW the problem/issue will be solved (approach).There will be 4 Phases in development of C-BML as a standard

b. Brief Discussion on the Maturity of proposed product.

Extensibility etc

c. Brief Discussion on alternative approaches to the proposed product.

To have separate standards, extensions of existing standards individually for the C2

- 60 - D R A F T

D R A F T

simulation, e.g. new DIS PDUs, new RPRFOM interactions etc. In other words proliferation of standards

d. Provide examples of prototypes of the proposed product or reasons why this product will not be prototyped.

NATO ET-16/MSG 040 will provide first implementation of Version 1.0 of the proposed C-BML standard.

e. What impact will this proposed product have on the M&S community?Facilitate C2-Simulation interoperability

f. What impact will this proposed product have on the SISO community?

M&S remains viable as we move towards Net Enabled Capabilities (NATO term)

g. What is the impact to the community if this proposed product is not developed?C2 and M&S will continue to develop separate solutions. This will potentially lead to the M&S community being marginalized in the operational environment.

h. What are the domain implications for this proposed product?

i. State which existing SIW Conference forum(s) take an active interest in the development of this proposed product?

C4I Forum

7. Planned compliance testing:

NATO MSG 040

- 61 - D R A F T

D R A F T

8. Schedule:

Provide a schedule of product development milestones including reviews and reports:

Product Development Milestone Date(s)

Product Development Activity(s) Description(reviews, reports, etc.)

April 2007 Version 1.0April 2008 Version 2.0April 2009 Version 3.0April 2010 Version 4.0

9. Candidate Volunteers for the Product Development Effort:

Provide a list of individuals that may be involved in the development of this proposed SISO Product. Include their place of employment and contact information.

Name Organization Contact InformationPhone Number Email Address

Mike HiebMark PullenAndreas Tolk

10. Suggested product periodic review cycle (timeline):

Periodic Review Date(s) Review Activity(s) Description

Sep 2006Sep 2007Sep 2008Sep 2009

- 62 - D R A F T

D R A F T

- 63 - D R A F T

D R A F T

Appendix C

C-BML Study Group Participants

2004 Interservice/Industry Training, Simulation, and Education Conference (I/ITSEC)

Last First Organization EmailNATO C-BML C-BML

Abbott Jeff US OneSAF [email protected] x x

Armour Leon US DMSO [email protected] x

Bearfoot John UK Qinetiq [email protected] x x

Bennet James US DRAC/XFW [email protected] x

Bitters Barry USUniversity of West Florida [email protected] x

Blais Curtis US NPS [email protected] x

Brown Dick US TPIO-BattleCommand [email protected] x

Brutzman Don US NPS [email protected] x

Carlton Bruce USARL, University of Texas [email protected] x

Denny, Maj Ian US NPS [email protected] x

Gauvin Pierre CACoordination Office Synthetic Environment [email protected] x x

Glasow, Col Jerry US DMSO [email protected] x

Gonzalez, Lt Sabas ES Spanish Army HQ [email protected] x x

GraysonStewart US SAIC [email protected] x x

Gustavsson Per SE Ericsson [email protected] x x

JacobSilbiger IL Synergy Integration [email protected] x

Jahn, CDR Dieter US NPS [email protected] x

Khimeche Lionel FR DGA [email protected] x x

Lam Wendy US SAIC [email protected] x x

Merritt Jerry US Raytheon [email protected] x x

Miller Greg US TPO OneSAF [email protected] x

Montgomery James UKBritish Army Land Simulation Centre [email protected] x

Mullins Tom US NASIC/AENR [email protected] x

Niven Mike UK Qinetiq [email protected] x x

Orichel Tom DE Bundeswehr IT Office [email protected] x x

Parsons Doug USUS Army PEOSTRI OneSAF [email protected] x x

Perme David US Gestalt LLC [email protected] x

Pullen Mark US GMU C3I Center [email protected] x

Richardson John US ARL [email protected] x x

Roberts John US ACS, Inc [email protected] x xSan Jose, Lt Col Angel ES

Spanish Navy OR Center [email protected] x

Smith Ed US PEOSTRI/WarSim [email protected] x

Sprinkle Ron US SIMCI/PEOSTRI [email protected] x x

Stafford Todd US SAIC [email protected] x x

Sudnikovich Bill US SIMCI; ACS, Inc [email protected] x

- 64 - D R A F T

mailto:[email protected]



































D R A F T

Thomas Mark US ARL [email protected] x x

Tudor, Lt Col Grant AUAustralian Army Simulation Office [email protected] x

Wemmergard Joakim SE FMV [email protected] x x

Winters Leslie US

HQDA G3, BattleCommand, Simulation and Experimentation [email protected] x x

Wittman Rob US COS/MITRE [email protected] x x

- 65 - D R A F T






D R A F T

References

Bresnan, J. (2001). Lexical-Functional Syntax. Oxford, UK: Blackwell Publishers.

Hecking, M. (2003). Information Extraction from Battlefield Reports. Proceedings of the 8th International C2 Research and Technology Symposium (ICCRTS). Washington, DC: CCRP.

Hecking, M. (2004). How to represent the content of free-form battlefield reports. Proceedings of the 9th International C2 Research and Technology Symposium (ICCRTS). Washington, DC: CCRP.

Daconta, M. C., Obrst, L. J., and Smith, K. T. (2003). The Semantic Web: A Guide to the Future of XML, Web Services, and Knowledge Management. Indianapolis, Indiana: Wiley Publishing Inc.

Tolk, Andreas, and Blais, Curtis (2005). Taxonomies, Ontologies, and Battle Management Languages – Recommendations for the C-BML Study Group. Paper 05S-SIW-007, Spring Simulation Interoperability Workshop, San Diego, California.

- 66 - D R A F T