Battle Management Language:

A Triangle with Five Sides

Charles Turnitsa, Dr. Andreas Tolk

Virginia Modeling Analysis & Simulation Center (VMASC)

Old Dominion University

Norfolk, VA 23529

cturnits@odu.edu, atolk@odu.edu

Keywords:

Coalition Battle Management Language, Grammar, Ontology, Conceptual Interoperability

ABSTRACT: The case has been made to this body, over the past few years, how the path to conceptual

interoperability mandates a method for systems to communicate, unambiguously, with a common language. One of the

major efforts to accomplish such a method has been the different studies and prototypes developed under the name of

Battle Management Language. It has been shown in many of the reports about BML activities that there are three

aspects of BML, all of which are necessary to achieve the whole. Recently, it has been shown that the regions

connecting these aspects are equally important as the aspects they connect – perhaps more so, for they are key in

allowing the aspects to synthesize and synchronize. The three aspects, of course, are Protocol, Representation, and

Doctrine. The region connecting Protocol and Representation is Grammar, and the region connecting Doctrine with

Representation is Ontology. This paper seeks to show what those terms are, and what sorts of applications can be

expected to fulfill these, the fourth and fifth parts of the triangle.

1 Introduction

It has been recognized for some time that the need for

higher levels of interoperability between our

simulations and our C4I systems is required in order to

satisfy the 21st century information demands of the

warfighter. In order to provide a framework describing

the levels of interoperability, within which systemic

research can take place, the Levels of Conceptual

Interoperability Model was devised, and revised, by

researchers at VMASC1. Using this model to evaluate

the current state of the art, we can see that most C4I

and M&S systems that interoperate are at level 1 or 2,

with only a precious few beginning to touch at level 3.

One of the ongoing research programs designed to

address the issue of increased interoperability is the

collection of efforts related to Battle Management

Language, or BML. For several years now, BML

efforts have been organized through and around

SISO2, including a study group (espousing an

international version of BML, known as Coalition

Battle Management Language, or C-BML), which is

progressing to a product development group. This

paper will address not only the state of affairs for C-

1 Virginia Modeling Analysis and Simulation Center 2 Simulation Interoperability Standards Organization

BML, but also give an overview of what is meant by

Conceptual Interoperability. The areas of research that

can most increase the level of interoperability of C-

BML are presented, with descriptions and

recommendations for implementation. Finally, an

assessment of how these recommendations will benefit

us will be presented.

2 Conceptual Interoperability

The goal of increased levels of interoperability is what

SISO exists to accomplish. This is also the goal of

research and standardization projects such as C-BML.

In order to measure the state of art, as well as the state

of practice, of interoperability, research scientists at

VMASC developed the Levels of Conceptual

Interoperability Model, or LCIM. It is a model,

described in seven levels, of increased interoperability,

starting with level 0 (no interoperability), and ending in

level 6 (conceptual interoperability). The LCIM has

been presented in several articles, book chapters, and at

conferences [7]. It has been modified both due to new

research at VMASC, and as the response to critique by

the scientific community [8]. Figure 1 shows the levels

and how they are connected to other terms, such as

integratability, interoperability, and composability.

Figure 1: Levels of Conceptual Interoperability

The different levels are characterized as follows:

Level 0: Stand-alone systems have No

Interoperability

Level 1: On the level of Technical Interoperability,

a communication protocol exists for exchanging

data between participating systems. On this level,

a communication infrastructure is established

allowing the exchange of bits and bytes.

Level 2: The Syntactic Interoperability level

introduces a common structure to exchange

information, i.e., a common data format is applied.

On this level, a common protocol to structure the

data is used.

Level 3: If a common information exchange

reference model is used, the level of Semantic

Interoperability is reached. On this level, the

meaning of the data is shared.

Level 4: Pragmatic Interoperability is reached

when the interoperating systems are aware of the

methods and procedures that each other are

employing. In other words, the use of the data – or

the context of its application – is understood by the

participating systems.

Level 5: As a system operates on data over time,

the state of that system will change, and this

includes the assumptions and constraints that

affect its data interchange. If systems have attained

Dynamic Interoperability, then they are able to

comprehend the state changes that occur in the

assumptions and constraints that each other is

making over time, and are able to take advantage

of those changes. In particular when interested in

the effects of operations, this becomes increasingly

important.

Level 6: Finally, if the conceptual model – i.e. the

assumptions and constraints of the meaningful

abstraction of reality – are aligned, the highest

level of interoperability is reached: Conceptual

Interoperability. This requires that conceptual

models will be documented based on engineering

methods enabling their interpretation and

evaluation by other engineers. In other words, on

this we need a “fully specified but implementation

independent model” as requested in [14] and not

just a text describing the conceptual idea.

Related work of various M&S experts supports these

findings. During a recent panel discussion3 on

Priorities for M&S Standards, Zeigler explicitly stated

in his presentation that standardization must be aimed

at the modeling level to ensure interoperability between

systems. This means that the standardized level must

be higher than the programming level standards

currently applied. For “meaningful interoperability,”

the sharing of standardized data via standardized

protocols, such as the Distributed Interactive

Simulation (IEEE1278) protocol or the High Level

Architecture (IEEE1516) standard, is necessary, but

not sufficient. The coordination of the underlying

conceptual models and the harmonization of the

operational ideas are the real crux to create

interoperable solutions. Instead of only standardizing

the information exchange requirements, the underlying

modeled cause-effect-chains must also be coordinated.

3 BML – Overview

Battle Management Language is the name of a very

loosely organized set of ongoing research projects, all

designed to assist in system-to-system interchange of

data concerning battlefield conditions. In 2001 it was

formally defined [10] as “…the unambiguous language

used to command and control forces and equipment

conducting military operations and to provide for

situational awareness and a shared, common

operational picture”. The systems that this definition

addresses include C4I systems, simulation systems, and

(in the future) robotic forces. Using BML, it should be

possible for any of these types of systems to

communicate, unambiguously, with any other of these

types of systems.

This type of system-to-system communication is

demanding when it involves systems within the same

organization. It grows more complex and demanding

when the systems are owned by the same nation, but by

different organizations (US Army, US Navy, as an

example). The current state of study is concerned with

what is potentially the most difficult, as well as

3 Spring Simulation Interoperability Workshop, Orlando, FL,

March 2003

possibly the most valuable (if it can be solved). This

state is the international, multi-agency requirement for

coalition system-to-system interchange. For this

reason, the current version of BML under study is

known as C-BML, or Coalition Battle Management

Language.

Since the formalization of the BML ideas, it has been

recognized that there are four guiding principles that

must be followed in order for a BML implementation

to function correctly. These principles (enumerated

below) have been the guiding pillars for all further

BML work. Together, the four of them form the test of

whether a data interchange technique satisfies the

definition of being a Battle Management Language.

BML must be unambiguous

BML must not constrain the full expression of the

commander’s intent

BML must use the existing C4ISR data

representations when possible.

BML must allow all elements to communicate

information pertaining to themselves, their mission

and their environment in order to create situational

awareness and a shared, common operational

picture.

C2 System C2 System

Simulation

System

Robotic

System

BML tasking:

Command and Control

Forces and Equipment

BML reporting:

Provide for

Situational Awareness

Figure 2: BML Tasking and BML Reporting

These principles are very difficult to simultaneously

satisfy, due to the conflicting nature of several of them.

Many (if not most) systems that convey a commander’s

intent do so by allowing free text comments to

accompany a data transmission. In this way, natural

language messages can be employed by the

commander to express his ieas. The difficulty here, of

course, is that natural language messages are very

difficult to disambiguate. To satisfy all of these

requirements, a battle management language must be

rich enough in structure to accommodate system

interoperability for a complex domain. That richness is

achieved by having several simultaneous views into

achieving the goal. This brings us to the BML triangle.

4 Three Sides of the BML Triangle

In order for BML to provide proper interoperability

support, it was determined early on that there should be

three different views of the same problem. These three

views support the four requirements of BML, and in

turn support each other. Conceptually, the three co-

supporting views form what has become to be known

as the BML triangle.

BML

BM

L D

oct

rine

BML Representation

BM

L P

roto

cols

Figure 3: BML Triangle

4.1 Protocol

The fourth principle of BML requires that all systems

(or elements) are able to communicate information

freely with each other. That information exists in two

modes: (1) it is the producing of all the information

that the element is aware of that other elements may

need, and (2) it is the consuming of all the information

that other elements are making available. All of the

elements must therefore have a common method for

data publication and data subscription. This mandates

a common protocol. The protocol that is currently

being adopted is XML, or the extensible markup

language. It is flexible and well understood, it is easily

extensible to accommodate all data needs that might

exist, and it is easily adopted as a means for

interchange by nearly all systems.

The reasons to use XML as the basis for the

interchange protocol are its many strengths. XML is

flexible, meaning that it can adapt to any data need. It

is accommodating of many different data types

(numeric elements, text strings, database cells, and

others). It is already supported by many applications,

or in cases where it is not already supported, its

structure and reliance on simple ASCII characterization

make it easy to adopt. The strongest aspect of XML is

the fact that it is a meta-markup language [18].

A markup language is a language that has a number of

established tags to identify and mark data elements in a

certain way. One widely seen example of this is

HTML. A meta-markup language differentiates from

this in that it has a standard format for the tags,

however the actual tags themselves are definable and

re-definable for each employing domain. The tags for

data interchange, for instance, that deal with dentistry

records will be different from the agreed to set of tags

that deal with the manufacture of automobile parts.

2nd company, 1st battalion

Move to PL Dogwood

And prepare def pos

Informational Document

<unit name>

<unit tasking>

<task time>

<task location>

<task object>

</>

</>

Domain XML Metatags

<unit name=“2nd company”>

<unit tasking=“move”>

<task object=“PL Dogwood”>

. . .

</>

Usable XML Document

Figure 4: XML example

Within our domain (the exchange of C4ISR data), this

becomes important not only because the domain itself

has a unique set of data elements that require

interchange, but also because there are so many

interpretations of the same data within the domain.

Many different systems, and of course the guiding

philosophies behind those systems (which we refer to

as Doctrine), have different names and definitions for

many of the same data elements. Because of this, the

meta-markup aspect of XML is extremely useful –

giving us a full palette with which to define our

markup tags.

With the first side of the triangle in place, protocol,

BML can now accommodate nearly any data element

for production and consumption, and those elements

are available for access by any system employing the

BML.

4.2 Representation

The third principle of BML requires that existing

C4ISR data representations be used for data

interchange. Clearly this is a large requirement, as the

number of data elements and situations that are

germane to C4ISR is very large. Rather than create

from whole cloth an enumerated representation,

reliance on an existing data model is a much better

option. There are many such data models, each of

which could help fulfill this requirement. For

international coalition exchange (the specific

requirement of C-BML), however, the best option

seems to be the C2IEDM, or Command and Control

Information Exchange Data Model.

The C2IEDM is an agreed-to internationally developed

and maintained data model, in ongoing development

since the 1980s, that allows for the exchange and

storage of command and control information. It is

maintained and shepherded by the Multinational

Interoperability Program [13]. In order to specifically

support multi-national coalition operations, the

C2IEDM has been designed to be neutral of all national

doctrine. Further details concerning the C2IEDM can

be found within [1,2,11,12].

The strengths and features of the C2IEDM are too

varied and complex to go into here, but a simple

feature that makes it ideal for interchange is the method

that the model employs to represent objects.

Reporting Data

Object-Item

Capability

Object-Type

Location

Action Reporting Data

Object-Item

CapabilityCapability

Object-TypeObject-Type

Location

Action

OBJECT-TYPE OBJECT-ITEM

ORGANIZATION -TYPE

MATERIAL-TYPE

PERSON -TYPE

FACILITY-TYPE

FEATURE-TYPE

ORGANIZATION

MATERIAL

PERSON

FACILITY

FEATURE

OBJECT-TYPE OBJECT-ITEM

ORGANIZATION -TYPE

MATERIAL-TYPE

PERSON -TYPE

FACILITY-TYPE

FEATURE-TYPE

ORGANIZATION

MATERIAL

PERSON

FACILITY

FEATURE

Comprehensive

Allows for

Extension

Very well

documented

• Tables

• Attributes

• Relations

• Extension rules

XML tags

Available

Figure 5: C2IEDM High Level View

The C2IEDM divides up the data describing an object

into persistent, type oriented data (captured in the

C2IEDM tables related to OBJECT_TYPE). Likewise,

the model captures the non-persistent data concerning

single instances of an object (such as a particular unit,

or an individual vehicle or soldier) within the C2IEDM

tables related to OBJECT_ITEM. For information

exchange this is extremely useful, as it allows for the

single transference between systems of the persistent

data, and then through intelligent linking of the non-

persistent data, a wealth of descriptive data is already

in place, and the ephemeral pieces of information (such

as state, location, mode, etc) can be transferred as

required in an efficient manner.

The ways the C2IEDM can structure and organize data

for meaningful interchange and the richness with which

it covers C4ISR data make it an ideal choice for BML

representation. It is also complimentary of our choice

for a BML protocol as well that the C2IEDM works

very will with XML [15].

With the second side of the triangle in place,

representation, BML can now represent any C4ISR

data element that may be required. And since this side

of the triangle relies on the C2IEDM, an international

model, the multi-national requirements of C-BML are

also met.

4.3 Doctrine

The remaining two principles of BML that are not

covered by protocol and representation, namely the

ability to represent the commanders intent, and to

accomplish all interoperability communications in an

unambiguous manner, requires the use of very clear

language elements. In order to make BML

operationally sound, those language elements need to

be in line with the business rules of the military

organization that is using the BML for

communications. Those business rules are found

within the published doctrine of the military

organization. To satisfy the first and second principles,

therefore, BML must base its communications

capability upon one or more published doctrines.

There are several means for accomplishing this, at least

from a US point of view. First, there is the resource of

the many joint manuals, as well as individual service

manuals (i.e. – US Army Field Manuals). These

publications are the source for the US military rules of

operation. Another possibility would be some of the

doctrinally sound publications that enumerate the many

possible tasks that can be undertaken by elements of

our military – such as the Universal Joint Task List, or

UJTL.

We are addressing a special case of BML within this

paper – namely Coalition Battle Management

Language. The concept of coalition operations almost

certainly mandates that there will be a confluence of 2

or more doctrines in place. BML can accommodate

more than one doctrine at once, but each doctrine must

be represented. In this case, the doctrine of coalition

partners must be represented by well-documented

sources of their own national doctrine.

Having doctrine be one of the main views into a Battle

Management Language also helps to satisfy the

unambiguous requirement (principle 1). If each

communication made is based on terms and concepts

from published doctrine, then there can be little room

for misinterpretation.

With the third side of the BML triangle in place, we

can now be sure that the terms that we use during our

communications between systems are unambiguous, as

they are based on published doctrinally sound

glossaries and manuals.

4.4 Summary of the Three Sides

We now can see from our three sides how the four

principles can be satisfied.

We have a way to describe terms in an

unambiguous way (based on published doctrinal

terms).

We can represent a commander’s intent (provided

that his intent is inline with published doctrine).

We can represent all of the required data terms that

a C4ISR system may require (but relying upon a

data model crafted for C2 data exchange).

We can ensure that our means for data transferal is

understood and can be used by all of our systems

(by relying on the flexible and adaptable protocol

of XML).

There are some problems, however. These problems

exist largely at the juxtaposition of the sides of the

triangle. Where protocol and representation meet, for

instance, we can see that we have a technical syntax for

interchange provided for by the protocol (XML), and

that we have a lexicon of useable C4ISR terms

provided for by the representation (C2IEDM).

However, how do we provide for a linguistic syntax,

whereby the terms are assembled into meaningful

communication messages (or sentences, to borrow a

term from natural language).

Similarly, there is an identifiable problem at the point

where representation meets with doctrine. The

representation view (C2IEDM) gives us the means for

communicating all of the C4ISR terms required, in a

doctrinally neutral manner, free from the assumptions

and requirements that various national systems might

place on such representation. Yet the doctrine view

has us cast all of our communications in terms of a

national doctrine. We are attempting to use doctrinally

neutral terms to convey doctrine.

These two problems can be solved, we believe, by

adding fourth and fifth sides to the triangle.

5 BML Grammar – the 4th Side of the Triangle

The set of rules within a language that determines

whether communication messages, or sentences, are

well formed is known as a grammar. A definition for a

context-free grammar follows. We suggest a context

free grammar simply because it should prove

sufficient, without introducing the additional

complexities of having context dependent structure.

A context free grammar, G, is defined as:

G = (N; ; P; S)

G is the Grammar itself, all that follows is a formal

definition of what the grammar contains

N is the set of all non-terminal symbols

is the set of terminal symbols (not in N)

P is the set of production rules that allows us to

formulate a string of terminal, and non-terminal,

symbols into a meaningful grammatically correct

sentence

S is a start symbol found in N – it is the symbolic

pointer to a grammatically correct sentence

For the purposes of BML, these symbols can be

defined as follows.

N is the finite set of non-terminal symbols, which

are used as markers within the grammar to signify

things such as statements, or even classes of

terminal symbols (which would be things like

nouns, verbs, and pronouns in a natural language)

is the set of all our possible data elements

(words or symbols), or our lexicon

P includes all the patterns (which can be simple or

recursive) of symbols (from N or ) that can be

constructed to legally satisfy statement structure

S is the set of all symbols that would appear at the

head of a legal statement formed using the rules of

the grammar

A very simple example of a production rule for a BML

grammar might be as follows. Suppose we wanted to

construct a production rule that allows for the simple

assignment of a task to a unit. The elements involved

in doing so are the name of the unit being addressed,

the term for the task being assigned, and perhaps a time

and location. Such a statement (S) might look

something like this:

S U A T L

Here the non-terminal symbols (from N) are

representative of terminal symbols (data elements)

from , which are as follows:

U is the non-terminal symbol representing the

class of names for units

A is the non-terminal symbol representing the

class of names of actions, or tasks

T is the non-terminal symbol representing a

time for the action

L is the non-terminal symbol representing a

location for the action

This is, of course, a very simple example and not even

very practical; after all both time and location can be

represented in any number of ways (not before time X,

at time X, after time X, etc). Also, there is no

provision for the inclusion of an object of the action

(such as Attack Unit X, or Defend Bridge X, or

Advance to PL X).

We can see from this definition, without having to

delve into it too deeply here, that a proper BML

grammar would have a full set of production rules.

Since P is potentially recursive, the set may not be a

finite set, but could offer an infinite number of

combinations where patterns recursively refer to each

other, and recombine into other larger, but still legal (in

terms of our grammar) patterns. Hence, all of the

representation terms could be assembled into

meaningful message types that satisfy the rules of the

grammar, and could thereby be received with

linguistically syntactic understanding by the system

being transmitted to. A complete set of such

production rules allows us to declare a formal

language, L, such that L (G) is a full grammar.

Earlier in this paper, mention was made of the LCIM

(see section 2 above). Before introducing a grammar,

the best that could be achieved by BML would be the

early stages of level-2 interoperability – the correct

technical format, as well as a common protocol would

be employed (i.e. – XML). Once we introduce a

grammar, however, we can accommodate almost a full

implementation of level-2 interoperability (syntactic

interoperability). Level-2 interoperability implies

proper syntactic understanding by the participating

systems (for which a grammar is required).

6 BML Ontology – the 5th Side of the Triangle

Much more complex than the introduction of a

grammar, however, is the introduction of a formal

ontology. The problem that a formal ontology can help

to solve is simply this – it gives a clear understanding

of what the various terms of a language mean, and

makes clear the relationships between those terms as

well as the properties that comprise the terms

themselves. A definition is given within [1], as:

An Ontology is an attempt to formulate an

exhaustive and rigorous conceptual schema

within a given domain. Although this is

typically a hierarchical data structure

containing all the relevant entities, it is not

necessarily a tree. Furthermore, in addition to

the entities, the ontology contains

relationships and rules (such as theorems and

regulations) within that domain. Therefore, a

taxonomy is a subset of an ontology. Daconta,

Obrst, and Smith describe an “ontology

spectrum” identifying weak semantic

representations such as relational databases

and taxonomies at one end of the spectrum

and strong semantic representations such as

formal logics at the other end [3].

In practice it is agreed that an ontology should

contain at a minimum not only a hierarchy of

concepts organized by the sub-sumption

relation, but other 'semantic relations' that

specify how one concept is related to another.

The main purpose is the definition of entities

and their relationships.

The employment of a formal ontology is important to

cover the gap between doctrine and representation for

the reason that doctrine provides the meaning of what

we are attempting to say, yet we are saying it in

doctrinally neutral terms. A formal ontology helps us

to map the meaning found in the glossaries and

manuals of the doctrine view to the neutral (but

appropriate) terms of the representation view.

BML

BM

L D

oct

rine

BML

Representation

BM

L P

roto

cols

BMLOntology

BML

Grammar

Figure 6: Extended BML Triangle

Additionally, a formal ontology helps us to rectify the

differences that will arise from having to employ

several doctrines (such as in support of coalition

activities). A formal ontology gives specific meaning

to each of the doctrinal terms, so that regardless of the

specific term, the underlying properties and property

values of the term are understood, and so can be

matched up against similar terms from other doctrines.

The adoption of a formal ontology, where all of the

terms of the representation are clearly understood and

traceable to the definitions provided by the doctrine

view, enables our battle management language to adopt

level-3 interoperability, measured within the LCIM.

That level is Semantic interoperability, and it implies

that not only is a proper syntax being used, but also

that all of the interoperating systems have a clear

understanding of the semantic meaning behind the

terms and data being interchanged.

7 Enabling Applications

The two applications that come suggested out of this

work are, of course, the formulation of both a formal

grammar and a formal ontology. In the case of a

formal grammar for C-BML, work is already underway

to develop a complete system. The work can be found

in [4].

In the case of a formal ontology, an evaluation of the

ontology of the C2IEDM was presented to SIW during

2005, in [2,5]. The results of that evaluation were

several findings where the C2IEDM could serve as the

basis for an excellent ontology of C2 interoperability,

but also some cases where extension may be necessary.

In addition to the completion of formal systems

describing a grammar and a formal ontology, there is

also room, now, to begin adopting some of the

principles that an ontology and a grammar would lend

to BML based interchange.

An application that would anticipate some of the

benefits of a formal ontology would be an interchange

service that provided for semantic collections of data

elements. This sort of service has been suggested in

work from VMASC, where it has been shown that not

only atomic data elements need be exchanged between

systems relying on a service based data mediation

system, but also collections of these atomic elements

into semantically sound interoperability objects. The

findings are to be found in [6,15].

Similarly, an early application that would anticipate the

influence of a formal ontology is the instantiation of a

central reference model whereby BML based

exchanges would all have to be based on the same set

of base data elements – this would be a very early (and

crude, but still effective) implementation of an

apparent ontology. An example of an early application

of this technology can be found in [16].

8 The Way Ahead

It is obvious by now that the triangle of BML definitely

is morphing into a pentagon with BML doctrine,

ontology, representation, grammar, and protocol being

important views into what BML really is. The more

we are coping with this topic we are convinced that we

cannot separate these views from each other. We see

absolutely no value in separated tasks to define

protocols independent from grammars and

representations or to capture doctrine in ontologies

without having the migration to applicable schemes in

mind.

It may be time to “rip the triangle with five sides” apart

and rearrange the elements in a continuum with smooth

borders. What was the triangle becomes a “Layer

Model for C-BML”, comprising the following layers,

shown in Figure 7:

Level 0 stands alone as defined in the LCIM.

There is no connection and no alignment.

Level 1 is technically aligned as defined in the

LCIM. We can exchange bits and bytes, but

that is it.

Level 2 is the Protocol Layer. We have a

common structure as requested by the

syntactic interoperability level of the LCIM.

The currently recommended solution of XML

and web services fulfils these requirements.

Level 3 is the grammar the explains the

protocol elements and how they are

interconnected and that is able to produce

elements that can be stored in the

representation model of choice. The grammar

reflects some of the LCIM ideas coped with

on the semantic level.

Level 5

Ontological Layer

Level 4

Representation Layer

Level 3

Grammatical Layer

Level 2

Protocol Layer

Level 0

No Interoperability

Level 1

Technical Layer

Level 6

Doctrine Layer

Figure 7: Layer Model for C-BML

Level 4 is the representation layer. This layer

is an applicable scheme, such as a data model,

that is capable of storing all information,

entities, relations, etc. to explain the view of

doctrine. It reflects semantic as well as

pragmatic ideas.

Level 5 is the BML ontology. As we

understand ontology, this is a more open form

comparable to a federated scheme connecting

various applications schemes. We are talking

about the formalization of a conceptualization,

which can be captured in various

representations. As such, this level spans

from the pragmatic level to the conceptual

level of the LCIM.

Level 6 is BML doctrine, or better, the

concepts captured in applicable doctrines.

This is another application example for the LCIM. A

comparison of the different levels and layers is shown

in Figure 8. Our work at VMASC has shown that the

concepts of ontologies can be applied to capture

different viewpoints (compare also with the

accompanying paper [17]).

Based on this work, the following recommendations

can be made for the product development groups for C-

BML as well as for the partnering group working on

the Military Scenario Definition Language (MSDL):

Level 5

Ontological Layer

Level 4

Representation Layer

Level 3: Grammatical Layer

Level 2

Protocol Layer

Level 0

No Interoperability

Level 1

Technical Layer

Level 6

Doctrine Layer

Level 5

Dynamic Interoperability

Level 4

Pragmatic Interoperability

Level 3

Semantic Interoperability

Level 2

Syntactic Interoperability

Level 0

No Interoperability

Level 1

Technical Interoperability

Level 6

Conceptual Interoperability

Figure 8: LCIM (left) and Layered C-BML (right)

Ontologies can serve as a comparison and migration

tool for heterogeneous concepts. They can capture

application specific viewpoints without forcing other

applications to share these views. However, they can

be used to show which applications can be migrated or

federated. For standard development efforts like C-

BML and MSDL it is crucial to understand that sub-

concepts cannot be developed without alignment of

underlying concepts. In our view, it makes no sense to

develop tasking and reporting grammars for the sake of

developing a grammar. The grammar must be

applicable to an application, which will follow its

conceptual model. The same is true for protocols or

data models: they only become valuable when they

become applicable, and then they need to support a

common concept.

C-BML as well as MSDL must follow such a common

concept in order to support the military user

purposefully. In order to be mutually supportive, they

must further follow aligned concepts. The alignment

of these concepts must be done under supervision of

SISO, as only SISO is responsible for both groups.

We therefore recommend to establish a cross-C-BML-

MSDL conceptual expert group supporting the

Standardization Committee to ensure that C-BML and

MSDL will be aligned. We further recommend that

such cross-PDG-expert teams become common

practice for SISO in order to avoid isolated solutions.

Ontologies seem to evolve to become a potential tool to

support such expert teams.

9 Acknowledgements

The research work underlying this paper was

performed by Charles Turnitsa, during the pursuit of a

PhD in the Modeling and Simulation curriculum of Old

Dominion University. His advisor is Dr. Andreas Tolk.

Part of the underlying research was funded by US Joint

Forces Command.

10 References

[1] Tolk, A. and Blais, C.; “Taxonomies, Ontologies,

and Battle Management Languages –

Recommendations for the Coalition BML Study

Group,” Spring Simulation Interoperability

Workshop, 05S-SIW-007, San Diego, CA, April

2005

[2] Turnitsa, C. and Tolk, A.; “Evaluation of the

C2IEDM as an Interoperability-Enabling

Ontology,” European Simulation Interoperability

Workshop, 05E-SIW-045, Toulouse, France, June

2005

[3] Daconta, M., Obrst, L. and Smith, K.; “The

Semantic Web: A Guide to the Future of XML,

Web Services, and Knowledge Management,”

Wiley Publishing, Inc., Indianapolis, 2003

[4] Shade, U. and Hieb, M.; “Formalizing Battle

Management Language: A Grammar for

Specifying Orders,” Spring Simulation

Interoperability Workshop, 06S-SIW-068,

Huntsville, AL, April 2006

[5] Turnitsa, C. and Tolk, A.; “Ontology of the

C2IEDM –Further studies to enable Semantic

Interoperability,” Paper 05F-SIW-084, Fall

Simulation Interoperability Workshop, Orlando,

FL, September 2005

[6] Tolk, A., Diallo, S., Dupigny, K., Sun, B. and

Turnitsa, C.; “Web Services Based on the

C2IEDM – Data Mediation and Data Storage,”

Paper 05S-SIW-019, Spring Simulation

Interoperability Workshop, San Diego, CA, April

2005

[7] Tolk, A. and Muguira, J.A.; “The Levels of

Conceptual Interoperability Model (LCIM)”. Fall

Simulation Interoperability Workshop, Orlando,

FL, September 2003

[8] Turnitsa, C.D.; “Extending the Levels of

Conceptual Interoperability Model,” Proceedings

IEEE Summer Computer Simulation Conference,

Philadelphia, PA, 2005 IEEE CS Press

[9] Blais, C., Hieb, M.R. and Galvin, K.; "Coalition

Battle Management Language (C-BML) Study

Group Report," 05F-SIW-041, Fall Simulation

Interoperability Workshop 2005, Orlando, FL,

September 2005.

[10] Carey, S., Kleiner, M., Hieb, M. R. and Brown,

R.; “Standardizing Battle Management Language

– A Vital Move Towards The Army

Transformation,” Paper 01F-SIW-067, Fall

Simulation Interoperability Workshop, Orlando,

FL, 2001.

[11] Turnitsa, C., Kovurri, S., Tolk, A., DeMasi, L.,

Dobbs, V., Sudnikovich, W.; “Lessons Learned

from C2IEDM Mappings within XBML,” Paper

04F-SIW-111, Fall Simulation Interoperability

Workshop, Orlando, Florida, September 2004

[12] Tolk, Andreas; “Moving towards a Lingua Franca

for M&S and C3I – Developments concerning the

C2IEDM,” Paper 04E-SIW-016, 2004 European

Simulation Interoperability Workshop,

Edinburgh, Scotland, June 2004

[13] Multilateral Interoperability Program; “Overview

of the C2 Information Exchange Data Model

(C2IEDM),” November 2003

[14] Davis, P.K. and Anderson, R.H.; "Improving the

Composability of Department of Defense Models

and Simulations," RAND Corporation,

http://www.rand.org/publications/MG/MG101/

[last visited January 2006]

[15] Tolk, A., Dupigny, K. and Diallo, S.; “Web

Services a Solution for Real Time M&S Data

Storage, Retrieval and Visualization,” Paper SIW-

05F-096, Fall Simulation Interoperability

Workshop, Orlando FL, September 2005

[16] Tolk, A., Sun, B.; “C2IEDM Data Mediation

Service,” Paper SIW-05F-120, Fall Simulation

Interoperability Workshop, Orlando FL,

September 2005

[17] Tolk, A.: “Multi-resolution Challenges

for Command and Control M&S Services,”

Spring Simulation Interoperability Workshop,

06S-SIW-007, Huntsville, AL, April 2006

[18] Harold, E. R., Means, W. S.; “XML In a

Nutshell”, O’Reilly & Associates, 2001,

Sebastopol, CA

11 Authors' Biographies

CHARLES TURNITSA is a graduate student

studying under Dr. Andreas Tolk at the Virginia

Modeling Analysis and Simulation Center (VMASC)

of Old Dominion University (ODU) of Norfolk,

Virginia. In addition to his academic pursuits, he also

performs as a system engineer and researcher on

several VMASC research projects. He has served in

many roles as an IT professional for over a decade,

performing analysis, design, and development tasks on

many research projects for NASA and the US Military.

ANDREAS TOLK is Senior Research Scientist at the

Virginia Modeling Analysis and Simulation Center

(VMASC) of the Old Dominion University (ODU) of

Norfolk, Virginia. He has over 15 years of

international experience in the field of Applied Military

Operations Research and Modeling and Simulation of

and for Command and Control Systems. In addition to

his research work, he gives lectures in the Modeling

and Simulation program of ODU. His domain of

expertise is the integration of M&S functionality into

real world applications based on open standards.