Specification for: Coalition Battle Management Language (C-BML)

Initial Draft v0.01

Simulation Interoperability

Standards Organization

(SISO)

Phase 2Specification for:

Coalition Battle Management Language (C-BML)

Reference Architecture

Message Framework / Transport Metadata

XMonth 201X

Prepared by:

Simulation Interoperability Standards Organization

C-BML Industry Task Team (CITT)

Copyright © 201X SISO. All rights reserved.

Initial Draft v0.01

Specifications for: Coalition Battle Management Language (C-BML)

Initial Draft v0.01

Copyright © xxxx by the Simulation Interoperability Standards Organization (SISO), Inc.

P.O. Box 781238

Orlando, FL 32878-1238, USA

All rights reserved.

Permission is hereby granted for SISO developing committee participants to reproduce this document for purposes of SISO product development activities only. Prior to submitting this document to another standards development organization for standardization activities, permission must first be obtained from the SISO Standards Activity Committee (SAC). Other entities seeking permission to reproduce this document, in whole or in part, must obtain permission from the SISO Executive Committee (EXCOM).

SISO EXCOM

P.O. Box 781238

Orlando, FL32878-1238, USA

Change Log

Date / Author / Description / Spec Comment ID
08/03/2012 / Régis MAUGET / Initial version / NA

TABLE OF CONTENTS

1Introduction

1.1Background

1.2Purpose and Intended Audiences

1.3Scope

1.4Objectives

1.5Related Standards

2References

2.1SISO References:

Document Number

2.2Technical References:

3Definitions (fill in as needed)

4Acronyms and Abbreviations (fill in as document is fleshed out)

5C-BML Standard Development Framework

5.1Why is C-BML Standard Development Framework required?

5.2C-BML Standard Development Framework overview

5.3Message Framework

6Transport Metadata Identification

6.1What is a metadata?......

6.2Approach used

7Basic statements

8List of candidate standards ans technologies

8.1FIPA

8.1HTTP

8.2SMTP

8.3HLA

8.4DIS

8.5TENA

9Study of candidate standards and technologies metadata

10C-BML Phase 2 Transport Metadata

10.1Required Metadata

10.2Optional Metadata

LIST OF FIGURES

Figure 1:C-BML Standard Development Framework overview

Figure 2:C-BML Reference Architecture overview

Figure 3:C-BML Reference Architecture – Message Framework

Figure 4:Minimal information for information transport

1

Copyright © 201XSISO. All rights reserved.

Initial Draft v0.01

Specifications for: Coalition Battle Management Language (C-BML)

Initial Draft

1Introduction

The Coalition Battle Management Language (C-BML) is a standard language for expressing and exchanging plans, orders, and reports across: command and control (C2) systems; live, virtual and constructive modeling and simulation (M&S) systems; and robotic systems.

1.1Background

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:

  • Conducting Simulation Interoperability Workshops (SIWs) that:
  • Identify requirements and respective interoperability gaps.
  • Exemplify solution possibility in prototypes.
  • Demonstrate applicability of standards.
  • Evaluating interoperability domains in depth in Study Groups (SG) that:
  • Conduct surveys of the related domains.
  • Develop plans on how to reach consensus.
  • Identify potential solutions.
  • Preparing standards in Product Development Groups (PDGs).

A review of technical papers at SISO, Command and Control Research and Technology Symposium (CCRTS), other forums, as well as military customer requirements, discloses a continuing need for improvement in the capability of Command and Control (C2) and Modeling and Simulation (M&S) systems to interoperate. This has often been motivated 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 M&S tools for Course of Action Analysis (COAA) and Mission Rehearsal, as well as emerging work on robotic forces, has created an increased requirement for interoperability across these systems. In addition, the move to net-centric and network-enabled operations creates new opportunities and context within which M&S must support the warfighter. Military operations are no longer conducted by single services and a single national force. Rather, they are increasingly joint down to the tactical level and likely to be conducted within a coalition or alliance such as the North Atlantic Treaty Organization (NATO). This leads to a requirement for multinational interoperability and the development of standards for inter-system information exchange.

In September 2004, the Simulation Interoperability Standards Organization (SISO) Standards Activity Committee (SAC) approved the establishment of a Study Group (SG) on Coalition Battle Management Language (C-BML). The C-BML SG was formed under the following premise:

In order to improve simulation interoperability and better support the military user with M&S-based capabilities an open standards-based framework is needed that establishes operational and technical coherence among C2 and M&S systems. The objective capability will enable automatic and rapid unambiguous initialization and control of one by the other.

The foundation for such a capability is a Battle Management Language (BML), a concept that has been discussed during several SISO workshops and prototyped in a technology demonstration. BML is not a new concept, having its genesis in the 1990’s in Eagle BML and the Command and Control Simulation Interface Language (CCSIL) from the Synthetic Theatre of War (STOW) program. In the international C2 community there is a history of complementary efforts to achieve country and system-independent technical and semantic standards for conveying information relevant to C2.

The objective capability can only be realized through standards that define technical and operational coherence between C2 and M&S systems. Technical coherence is relatively straightforward given the variety of technologies that exist today to engineer distributed integrated systems, such as the Common Object Request Broker Agent (CORBA), Web Services, and Extensible Mark-up Language (XML). Operational coherence is the fundamental difficulty to achieving the objective capability. It requires that a precise and unambiguous set of concepts, semantics, and business rules be established as the basis for communications and control between C2 and M&S systems. Previous simulation standards, such as the High Level Architecture (HLA), have had similar objectives in the simulation-to-simulation area. Today, the semantic misalignment between M&S standards and C2 standards form a barrier to achieving the desired objective capability. A BML must derive directly from the C2 view of operations.

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. As a result a statement of work was drafted and submitted to the SISO SAC. The Terms of Reference (TOR) for the C-BML SG listed the following tasks:

  • The study group shall conduct a paper survey identifying as many international contributions applicable to the C-BML effort as possible.
  • The study group shall develop a plan of how these identified efforts can contribute to a common C-BML standard and a standard framework.
  • The study group shall formulate a set of recommendations on how to proceed toward a C-BML Product Development Group (PDG).

The TOR stated that 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.
  • 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 sponsored the SG efforts. In addition to its SISO membership, the SG collaborated with other organizations with potential interest in this work, in particular the North Atlantic Treaty Organization (NATO) Modeling and Simulation Group (MSG) and the CCRTS. The C-BML SG formally began work at the Fall 2004 SIW. It completed work with submission of a final report to the Executive Committee (EXCOM), SAC, and Conference Committee (CC) at the Fall 2005 SIW. That report recommended initiation of a Product Development Group to proceed with development of a specification for C-BML for standardization through SISO, and provided a Product Nomination to that end. The SAC approved the Product Nomination, resulting in establishment of a Product Development Group and Drafting Group for development of the C-BML specification.

The C-BML specification will be produced in phases resulting in incremental versions that provide increasing capability. For all phases and versions, the C-BML SG recommended using the Joint Command, Control, and Consultation Information Exchange Data Model (JC3IEDM) as the basis for C-BML reference implementations and standards. Each version of the C-BML specification will have:

  • A Data Model
  • An Information Exchange content and structure specification
  • An Information Exchange Mechanism specification
  • Guidelines

The SG proposed that the C-BML Standard evolve over time through three phases:

  • Phase I, Data Model: Phase 1.0 of the C-BML Specification describes a sufficient data model to unambiguously define a set of military orders using JC3IEDM as a starting point and extending as necessary so that they can be interpreted by C2, M&S and Robotic systems. TheC-BML Standard will describe a data model in a subset of JC3IEDM, an Information Exchange, content and structure specification in the form of an Extensible Markup Language (XML) schema and an Information Exchange mechanism specification embedded into a Web Services Description Language (WSDL) document. An initial version of the C-BML XML schema will be evaluated by the parallel NATO MSG-048 effort.
  • Phase II, Formal Structure (Grammar): Phase 2.0 will introduce a grammar (syntax, semantics, and vocabulary) as part of the Information Exchange, content and structure specification. The objective is to formalize the definition of tasks such that they are rigorous, well documented, and parse-able. The grammar will be extended to accommodate “reports” after a tasking grammar is defined. The need for a grammar for tasking and reporting is seen as a common requirement for both the C-BML and MSDL efforts and this could be conducted by establishing a joint C-BML/MSDL Tiger team for this task.
  • PhaseIII, Formal Semantics (Ontology): Phase 3.0 will include development of a battle management ontology to enable conceptual interoperability. While the SG realized the potential of ontology-based solutions it is also recognized that current approaches require additional research and agreement on processes outside of SISO to achieve applicable solutions.

This specification represents Phase 1 of the C-BML standardization effort. Development efforts across all phases is proceeding in parallel.

1.2Purpose and Intended Audiences

The C-BML Specification is intended for use by software developers (specification, design, implementation, and test) in the C2 and M&S domains. The document is a means for familiarizing developers with the structure and application of the language.

1.3Scope

This standard defines the C-BML in terms of a description of the information components of the language, a standard data model and procedures for extending the data model, a standard approach for mapping from language information components to the data model, and a standard approach for implementing the language.

The C-BML standard is intended to grow and evolve over time as the user community grows and evolves. With this in mind this initial specification includes only scenario description elements that have been matured through use within OneSAF and other simulations and that have been agreed to by the drafting and product development group.

1.4Objectives

The primary objective of this standard is to provide the mechanism that permits simulations to utilize the MSDL schema to develop and reuse military scenarios across MSDL compliant simulations and scenario generation tools.

1.5Related Standards

The Military Scenario Definition Language (MSDL) is a common representation of scenario information that can be exchanged across multiple C2 and M&S systems. Intended for use in initializing various systems, MSDL describes the physical setting of a scenario (e.g., terrain, weather), forces and force structures, control measures, and other information. MSDL has also progressed to Product Development Group status in SISO.

The MSDL and C-BML PDGs are not simply related, but have mutually dependent standards and development efforts. This dependence is rooted in the identification in MSDL of forces and scenario settings that are used in BML expressions of plans, orders, and reports. Furthermore, as a common language for initializing C2 and M&S systems, MSDL needs to contain initial sets of plans and orders (e.g., air tasking orders, initial ground movement orders, and ship-to-shore landing plans) that are expressed in C-BML. Accordingly, all C-BML products and artifacts developed under the PDG shall be shared openly with the MSDL PDG. To facilitate cooperation and collaboration between the two PDGs, one member of the groups serves on the leadership of each PDG. There are also a number of other individuals who are members of both PDGs and respective DGs, helping ensure effective coordination and collaboration across the groups in development of their respective standards products.

In the event that a conflict is identified between the C-BML PDG and the MSDL PDG, the individual discovering the conflict will notify the C-BML PDG. If the C-BML PDG cannot resolve the conflict then the conflict will be elevated to the SAC. Notification will be made to the Technical Area Director (TAD) responsible for oversight of the C-BML products in accordance with the defined appeal process found in the SISO-ADM-002-2006 SISO Policies & Procedures document.

2References

2.1SISO References:

Document Number
/ Title
1 / SISO-ADM-005-2004 / Policy for: The Style and Format of SISO documents
2 / SISO-REF-016-2006-V1.0 / Coalition Battle Management Study Group Final Report
3 / SISO-ADM-003-2002 / SISO Balloted Products Development Process (BPDP)
4 / SISO-ADM-002-2003 / SISO Policies and Procedures (P&P)

2.2Technical References:

Document Number / Title
1 / XML W3 Org web site / XML Schema

2 / MIP JC3IEDM web site / JC3IEDM, Annexes, and .xsd Domain Values

3 / IDEF1X Data Modeling Method, Integrated Definition Methods
FM 5-0, 20 January 2005 / Army Planning and Orders Production
FM 101-5, 31 May 1997 / Staff Organization and Operations
6 / FM 6-20-10, 8 May 1996 / The Targeting Process

3Definitions (fill in as needed)

Military ScenarioMilitary scenario includes information such as overlays, control measures, terrain, weather and unit relationships, affiliations and organization. In addition, the military scenario captures the results of mission planning, including plan objectives, scenario situation, and other data that supports execution matrices and related planning annexes.

Simulation ScenarioSimulation scenario contains:

  • A reference to the appropriate terrain database to utilize
  • Data for any additional creation of environment objects
  • Data for the weather attributes across the database
  • Data for sides, forces, and their relationships
  • Entities and units and their specific data attributes including: entity or unit composition, resource loads, subordinates, locations, orientations and initial damage state.
  • Control measures and overlay data
  • A reference to the data collection specifications
  • Specific simulation data such as the execution is to be batch or interactive
  • General scenario data such as a description of the scenario contents
  • General categorization data for the scenario to enable searches.

4Acronyms and Abbreviations (fill in as document is fleshed out)

JC3IEDMJoint Command, Control, and Consultation Information Exchange Data Model

EXCOMExecutive Committee

JC3IEDMJoint Consultation Command and Control Information Exchange Data Model

MDMPMilitary Decision Making Process

MIL STDMilitary Standard

MSDLMilitary Scenario Definition Language

M&SModeling & Simulation

PDGProduct Development Group

SACStandard Activity Committee

SISOSimulation Interoperability Standards Organization

XMLExtensible Markup Language

5C-BML Standard Development Framework

5.1Why isC-BML Standard Development Framework required?

TO DO

5.2C-BML Standard Development Framework overview

TO DO

Figure 1:C-BML Standard Development Framework overview

Figure 2:C-BML Reference Architecture overview

5.3Message Framework

TO DO

Figure 3:C-BML Reference Architecture– Message Framework

This document aims at defining the Transport Metadata of Message Framework of C-BML Reference Architecture.

6Transport Metadata Identification

6.1What is a metadata?

Extract from [1]:

“Metadata is structured information that describes, explains, locates, or otherwise makes it easier to retrieve, use, or manage an information resource. Metadata is often called data about data or information about information. Metadata is often called data about data or information about information.”

6.2Approach used

Information transport exists for a long time in computer science, because one of the first needs that appear with computerswas the need to transport information from one computer to another one. With the growth of World Wide Web and its adoption by the general public[RMA1], that need become ever more obvious.

Because of that historic, the approach to define Transport Metadata for C-BML will not be to rethink about what is information transport by itself, but rather to build upon existing standards and technologies used in that domain in order to find what are the most common pieces of information used to transport data.

So, the following approach will be used to identify Transport Metadata for C-BML:

  1. Write down same basic statements in order to clarify what will be in and out the scope of the current work
  2. Identify a list of candidate standards and technologies that are revelant to C-BML message transport
  3. Study theses candidate standards and technologies in order to identify their metadata and to compare them
  4. On the basis of that study, détermine the list of C-BML Transport Metadata

7Basicstatements

As showned in Figure 3, C-BML can be decomposed in:

  • Content, which aims at describing some information that had a clear signification in the dedicated business domain, i.e. military language or more precisely battle management language,
  • Transport, which aims at delivering the content (whatever that content is) from the sender to the receiver(s). That part of C-BML is purely technical (i.e. computer science oriented), and even if the content (i.e .C-BML message) is the core of the transport message, but no transport service can access and / or interpret that content.

So, the first statement is that transport service has no knowledge about the meaning of the content. All the business meaning is in the C-BML message, and the transport cannot understand that meaning.