Standardizing Battle Management Language - A Vital Move Towards the Army Transformation

Fort Leavenworth, KS 66027 913 684-3137 BrownR@leavenworth.army.mil Keywords: Battle Management Language BML, Eagle Simulation Language, Command and Control Simulation Interface Language

Scott A Carey

Martin S Kleiner

LOGICON Technology Solutions

1286 Eisenhower Road

Leavenworth, KS 66048

(913) 250-0130 Ext 34

scarey@logicon.com

mkleiner@logicon.com

Michael R Hieb, Ph.D.

IITRI/AB Technologies Group

1901 N Beauregard St

Alexandria, VA 22311-1705 (703) 933-3376

mhieb@iitri.org 

Richard Brown

TPIO-ABCS

415 Sherman Ave

Fort Leavenworth, KS 66027 (913) 684-3137

BrownR@leavenworth.army.mil

Keywords: Battle Management Language (BML), Eagle Simulation Language, Command and Control Simulation Interface Language (CCSIL), Command, Control, Communications, Computers, and Intelligence (C4I), Army Battle Command Systems (ABCS), Joint Common Data Base (JCDB), Future Combat Systems (FCS)

ABSTRACT: In recent years there has been a move towards digitizing military Command and Control (C2) systems and communicating not only with other humans, but also with automated systems Most recently, there has been a need to use simulations to stimulate and be stimulated by the Command, Control, Communications, Computers, and Intelligence (C4I) systems Communication between C4I systems and Simulations is becoming less interpersonal and more data oriented As each new system is developed to be more differentiated and specialized, the result is a confusion

of new “languages” and an overall reduction in the ability to effectively communicate C2 information What is needed

is a standardized Battle Management Language (BML).

The Army has established a Simulation to C4I Interoperability Overarching Integrated Product Team (SIMCI OIPT) to identify and work on key interoperability issues BML has been identified to the SIMCI OIPT as not only an essential simulation issue, but also an important C4I issue The most critical C2 information, the commander’s intent, his orders and directives, does not currently flow as data Instead, it is communicated as “free text” elements within messages or

as stand-alone files While suitable for interpersonal communication, it is inadequate for use with simulations, or as we have shown, for future forces that have robotic components

This paper examines the fundamental problem of communicating C2 information unambiguously We briefly review the major efforts to solve the BML problem and explain why they are insufficient for solving the large-scale problem Our approach to develop a BML is to adapt representations of orders and directives (such as the operations order) so that they are directly derived from doctrine and reside within the current standardized C4I data models like the Joint Common Data Base (JCDB) This accomplishes two primary goals First, it provides for a means to link the BML (terminology and symbology) directly to their doctrinal source Second, it allows operational forces to use their C4I systems to 1) interact with supporting simulations to conduct rigorous, realistic training and support mission rehearsals; and 2) in the future, support an expedited military decision making process A BML properly designed and implemented will allow Army forces to not only “train as they fight” but also transition to the Objective Force and the Future Combat Systems

1 Introduction

The purpose of this paper is to describe the progress being

made towards, and importance of, a single Army Battle

Management Language (BML) “Command and control

functions are performed through an arrangement of

personnel, equipment, communications, facilities and

procedures employed by a commander in planning, directing, coordinating, and controlling forces and operations in the accomplishment of the mission.” [8] Command and Control (C2) of military operations has always been a key target for technology advancement The development of automated digitized C2 systems, which has occurred exceedingly rapidly in relative terms [7] [4], has

both enabled and demanded the specialization and

differentiation of specific functional area support systems,

e.g All Source Analysis System (ASAS), Advanced Field

Artillery Tactical Data System (AFATDS), Maneuver

Control System (MCS), etc The focus of our method of

communications has shifted away from human to human

towards these automated systems Along with this change

has come a proliferation of operating systems, data

representation schemata and other aspects that now

confront us with a “confusion of languages” much as in the

biblical account of the Tower of Babel

In this paper, we are concerned with the problem of

standardizing the representation and communication of C2

planning and execution information Examples of this

information are the Operations Order and Fragmentary

Order We approach this problem initially as a current

crucial simulation interoperability issue However, this

problem will also impact C4I systems in the near term, and

the objective force in the far term Thus, our solution, to

be applicable to all of these areas, must also address future

C4I science and technology areas

The Army’s SIMCI OIPT [16] has developed a

comprehensive approach to solving Simulation to C4I

Interoperability The fundamental premise is to align and

integrate the Architectures [11], Software Components [17]

and Data Representations [10] [19] of both C4I and

Simulations Systems BML is one of the most difficult and

intractable problems identified by SIMCI

1.1 The Challenge

From the 1980’s to the present the use of simulations to

support training expanded exponentially Simulations

such as Corps Battle Simulation (CBS), Brigade/Battalion

Battle Simulation (BBS), JANUS, Close Combat Tactical

Trainer (CATT), and Modular Semi-Automated Forces

(ModSAF) have significantly improved both the quantity

and quality of training opportunities This is particularly

true at the brigade, division and corps level, where the

primary focus of training is on the command and staff

processes In the past, maneuver space, number of units,

and logistic resources made it impractical and

unaffordable to conduct effective and realistic command

and staff training at the division and corps level Now,

using these supporting simulations, the highest echelons

can conduct realistic training in a more frequent and cost

effective manner

The major drawback of using computer-simulated

training, such as CBS, is the need for large contingents of

support personnel to act as workstation controllers and

provide the interface between the training unit and the

simulation The group of workstation controllers is often

as large, or larger than, the training audience While this enables training opportunities at the corps and division echelon, it is still resource-intensive and lacks the degree

of fidelity that actual combat operations present to the commander and staff

Related to this issue of large contingents of workstation controllers, is the lack of an effective means to share information and directives between the simulation and the C4I systems Enabling the C4I systems to not only exchange information but to also allow them to interact directly with the simulation will significantly reduce workstation controller requirements Good progress has been made in the area of sharing information, however, in the area of controlling the simulation directly from the C4I systems significant progress still needs to be done This is due to the reliance on unstructured, ambiguous

“free text” within the operational C2 messages that are passed within the C4ISR systems

“Free text” existing in USMTF, JVMF, and other message formats exists for the benefit of the human The highly trained, professional soldier has little problem dealing with this “free text.” Current automated systems that deal with “free text” handle it as a single data field and pass the <character string> on Understanding of the content of the <character string> does not exist within the system

A recent development in simulations is the command agent or intelligent agent software This type of simulation is designed to receive general “mission type” tasks, and cognitively process the tasks applying a situational awareness Using this information and by applying knowledge of military doctrine, tactics and techniques it determines its own solution to the problem and then issues appropriate orders and directives to the simulated forces It subsequently monitors the task’s progress against the planned progress The intelligent agent then makes corrections as necessary This type of simulation, layered over a more traditional simulation, can greatly reduce the size of the workstation controller contingent Nevertheless, the introduction of “intelligent agent”, “command entities”, or other Command Decision Model (CDM) types of software such as the combat units within the EAGLE simulation or the Command Forces (CFOR) software (see Section 3) requires unambiguous structures Free text messages are not an option A clear, unambiguous Battle Management Language is needed to control these agents

C4ISR systems are also evolving The future systems are incorporating automated decision aids, such as course of action development and analysis tools, and mission rehearsal simulations The Agile Commander Advanced Technology Demonstration (ATD) is investigating more

advanced applications for these products [20], [1] While

some emerging C4I systems, such as the FBCB2, utilize

AutoFill of certain fields in their orders messages, this is

primarily situational awareness information (e.g time,

location, etc.) and the command information is still

carried in free text form

1.2 BML

Taking the widest possible interpretation, we define BML

as:

BML is the unambiguous language used to command

and control forces and equipment conducting military

operations and to provide for situational awareness

and a shared, common operational picture.

Along with this definition, we offer four principles that

guide our discussion of BML though the paper:

1) BML must be unambiguous;

2) BML must not constrain the full expression of a

commander’s intent;

3) BML must use the existing C4I data representations

when possible; and

4) BML must allow all elements to communicate

information pertaining to themselves, their mission

and their environment in order to create situational

awareness and a shared, common operational picture

Clearly, principles 1 and 2 are difficult to reconcile We

will review how well we have addressed these principles

in Section 5, our Conclusions

Principle 3 is one that is often ignored or slighted

However, if a “new” representation is to be developed,

then it will still have to be “translated” into the organic

C4I infrastructure Thus, many advanced and flexible

planning representations, while very well suited to BML,

are not appropriate, due to integration difficulties

BML must contain no distinction between live or

simulated forces ensuring that commanders and staff can

train as they fight They use the same BML whether they

are dealing with live subordinates, a simulation, or a

Future Combat System (FCS) robot (Figure 1)

1.3 Need for BML for the Future Combat System

The FCS is a “top priority Science and Technology (S&T)

program to achieve the Objective Force.” [20] The FCS

Mission Need Statement calls for a

multi-function/multi-role system-of-systems that will meet the future ground

force requirements of the Army including: direct fire,

indirect fire, air defense, non-lethal firepower, reconnaissance, command and control on the move, and

be air transportable on C-130 aircraft The program will develop Semi-Autonomous Robotics that project tactical operations forward into enemy terrain, beyond the reach

of manned elements There are currently three identified technical roadblocks to achieving this capability: lack of robust, adaptive perceptual capabilities; intelligent, adaptive vehicle behaviors; and modular, non-intrusive soldier-robot interfaces Communicating with FCS robots cannot be via written or verbal C2 communications as currently utilized The development and implementation

of BML will help provide solutions to the second and third of these roadblocks The problems encountered communicating with intelligent agents or command agent simulations also apply to communicating with robotic agents

1.4 Roadmap to Rest of Paper

The remainder of this paper is organized as follows: Section 2 describes our approach to BML Section 3 describes other BML-related efforts Section 4 goes into more detail on BML implementation; and Section 5

Figure 1: BML Scope

Simulation

Robotic Forces BML

Order

concludes, focusing on how our BML concepts address

the four BML principles stated above

2 BML Concept

2.1 Requirements

To determine BML requirements, it may be beneficial to

look at the current BMLs Section 3 describes the highly

structured EAGLE BML and Command and Control

Simulation Interface Language (CCSIL), and the Army

Modeling and Simulation Office (AMSO) BML-1

standard These exist to support simulations, raising the

question “Is there an operational BML”? The answer is

yes It is the language used on a daily basis by military

professionals to command and control live forces

Doctrinal manuals such as FM 101-5-1 define the

vocabulary The associated grammar is defined by other

doctrinal manuals and from years of use It is tailored to

interpersonal communications and doctrine provides the

base line of common understanding amongst all users

However, operational BML lacks clearly delineated rules governing its use (semantics and syntax) and is riddled with ambiguity It works because the military professionals who use it grow up with it from the moment they enter the service They learn its idiosyncrasies as they learn the idiosyncrasies of the individuals who use it When a term is used, it has context based on the operation, unit type and echelon, and individual characteristics of the sender Likewise, when a sender selects a term to use he does so with an understanding of these same factors of the intended audience Any confusion is resolved through give and take between sender and receiver Mentoring and coaching is a part of the process of learning the “informal” BML While ease

of use is this operational language’s main strength, it is directly related to its main weakness in relation to automated systems, specifically, lack of structure As such, it is incapable of supporting the full range of automation that the Army is implementing It demands further development and modification

Figure 2: Disparate Components of BML

USMTF JVMF TADIL

OTH Gold ADAP3

JCDB Data Model

Eagle BML CCSIL

Messages

Data Models

BML

Doctrine

FM-101-5 ARTEPs

As emerging and future simulations are developed we are

faced with three options in meeting the requirement for

BML First, we can continue as we have in the past and

create BMLs that are specific to each simulation Second,

we can develop a BML that is standard within the

simulation community and create interpreters between it

and the C4I systems Finally, we can develop a BML that

is standard within both the simulation and C4I domains

To support the “train as we fight” principle, we

recommend developing a BML that is standard within

both domains

2.2 Concept

The first step in solving a problem is recognizing that a

problem exists In this case it is a matter of getting all

those concerned (C4I development, simulation, doctrine,

training, and operational communities) to recognize that

not only does the problem exist, but also that the solution

has to be a combined effort of all involved This has

begun under the leadership of the SIMCI-OIPT which

initiated a two-day BML Symposium, hosted by the

TPIO-ABCS, at Fort Leavenworth, Kansas on 25 and 26

April 2001 The Symposium brought together

representatives from all of the concerned communities in

order to examine the problem Key findings from the

symposium were:

 Unanimous agreement that a formal BML is needed,

 The ABCS Common Services Operational Requirements Document (ORD) needs to formally state the BML requirement,

 BML should be developed both for and by the operational and simulation communities

 TRADOC is the ultimate proponent for BML The next step in solving the problem is developing a concept for a BML Figure 2 depicts the current state of disparate information, messages and languages

To address this disparity we propose doing the following (Figure 3):

 Incorporate the doctrinal base into the Joint Common Data Base (JCDB),

 Build in the vocabulary as contained in FM 101-5-1, Operational Terms and Graphics (future FM 1-02) and BML-1 as data tables, and

 Build in the syntax and semantics as defined through the Army Universal Task List (AUTL) (future FM 3-15), the Army Training and Evaluation Program (ARTEP) Mission Training Plans (MTP) and the other related Field Manuals for use of the items specific to echelon and type units as relationships between data tables

Once these tables and relationships exist they can be extracted and/or updated in the JCDB either through data replication, or messaging (current formats or emerging formats such as XML) This concept can be expanded in the future to include Joint and International interoperability by including Joint and NATO doctrine into the respective data models as shown in Figure 4, as the data models are synchronized

With the vocabulary and its associated relationships built into the database, graphical user interfaces (GUI) and other applications can be constructed that allow implementation of the BML

Several advantages result from this approach

 Building the vocabulary into the database allows for exchanging information through data replication and emerging technologies such as eXtensible Markup Language (XML)

 The terms, as they are used in messages, can be linked to their doctrinal definitions to assist users (senders and receivers) in understanding the precise intent of the author This can be extremely helpful in those areas where a term has multiple definitions or

Figure 4: BML Concept Scalability

Figure 3: BML Concept

BML

XML/

Data

Replication

JCDB

BML

XML/

Data

Replication

C2 Core Data Model Joint Doctrine

BML

XML/

Data

Replication

Doctrine

Planning BML

Messages Data/Object Models

XML/

Data

Replication

JCDB Data Model

Doctrine

FM-1-02 Other FMs ARTEPs

Planning BML

Messages Data/Object Models

XML/

Data

Replication

JCDB Data Model

Doctrine

FM-1-02 Other FMs ARTEPs

there are subtle differences in the meanings of

different terms

 As the work continues to align the database models

between simulations and C4I systems then this

approach, since it involves building BML into the

JCDB, will lead to better alignment/adoption of a

single BML for both domains (Figure 5)

 Ensuring that the database includes the graphics as

well as the terms will assist in transitioning from

course of action development and analysis tools

linked to the database to producing the operations

order It enables this as either an auto fill of

structured formatted messages, or as a GUI-based

representation of the current situation and operational

objectives

3 Related Battle Management Languages

As mentioned earlier, the majority of command and

control information, intended for processing by humans,

is currently exchanged in “free text.” There are fields in

formatted messages for free text and staffs routinely use

nonstandard email attachments that cannot be parsed into

the operational database As we move towards the use of

“intelligent agent” software in simulations and even

towards the robotic Future Combat Systems (FCS) it

becomes imperative that we find a solution to the “free

text” challenge The intent, however, is not to restrict the

commanders’ ability to issue mission type orders or

convey their intent, but to bring more structure to them in

order to facilitate the interface with automated systems

The following paragraphs look at three implementations

of BML that address this challenge

3.1 EAGLE Combat Model Battle Management

Language

In 1989 the U.S Army Training and Doctrine Command

(TRADOC) Analysis Center (TRAC) at Fort Leavenworth

in cooperation with Los Alamos National Laboratories

and MITRE began development of the EAGLE combat

model Eagle is a Corps/Division level combat model

with resolution down to battalion or company level The

EAGLE Battle Management Language (EAGLE BML)

[14] was developed as part of the EAGLE simulation as a

means for simulated combat units (Corps through

Company level) within EAGLE to do the following:

 Know what their missions are,

 Create a plan to execute the mission,

 Convey the plan to subordinates,

 Assess the situation and evaluate execution of the

plan,

 Advance the current plan, and

 Plan for contingencies

EAGLE BML is divided into three sub-languages: a Mission Language, a Situational Awareness Language, and a Battle Management Language

The Mission Language defines the language used by commanders to express a unit’s mission It uses domain specific and domain related knowledge engineering terminology It includes a very structured format for the operations order and predefined data types for each field Data representations are used to store tactics and techniques for planning and execution, not just words but also the “How.” For example:

Task (equates to a mission activity – roughly equivalent

to an ARTEP Task) and the <Rules for selection>

Scheme of Maneuver and <Rules for Selection>

Sequence of Phases Roles for subordinate units (type) Tasks to accomplish per phase Objective

This equates to:

Unit has to <attack> Mission Activity is <deliberate attack against enemy prepared position> The scheme of maneuver is <Frontal attack> Typical phases are

<conduct passage of lines, attack 1st echelon forces, …> The unit will have the role of <lead battalion main attack> with task to <attack> in the 2nd phase to take

<enemy 1st echelon battle position>.

The Situational Awareness Language is used to describe the Commander’s Critical Information Requirements (CCIR) It consists of decision variables and predefined sets of values Currently there are approximately twenty-five variables Examples are:

 Battlefield Geometry: approaching, closing, assaulting, etc.;

 Combat Effectiveness Summary: ineffective, marginally effective, effective;

 Combat Intensity: Receiving <light, medium, heavy> indirect fires, etc.;

 Logistics Status: Direct Fire Ammo <low, normal, critical>, etc.;

 Relationship to enemy: <approaching, closing> on enemy position

A simulated commander uses the Situational Awareness Language to assess his current situation and drive his actions The Situational Awareness Language is also used

to notify the higher headquarters of the unit’s status The Battle Management Language is used to direct the actions of subordinate units It consists of a <type action>

and the necessary data to accomplish the action, usually in

the form of the Mission Language It is used to change or

advance the current plan For example:

 <Change Plan><Higher hq name><New

plan><Phase to start>…;

 <Change Phase><Phase to change

to><Reason>…;

 <Change Task><Task to change><Reason>…;

 <Execute FRAGO><Higher hq name><frag

plan>…

Situational Awareness Language is also used to

synchronize the maneuver of subordinates:

 <Halt command><time>…;

 <Halt if in formation><time>…;

 <Release from formation><time>…;

 <Move out if in Formation><time>…

EAGLE BML, through this very structured process,

allows:

 Simulated combat units to plan and execute a

mission,

 The “cascading of orders” between simulated

units,

 The analyst or workstation controller to focus on

high level missions and allows the simulation take

care of the details

EAGLE BML is, however, specific to one simulation –

EAGLE It is not based upon the JCDB, and the JCDB

would need to be expanded to accommodate EAGLE’s

BML representation

3.2   Command   and   Control   Simulation   Interface

Language (CCSIL) 

CCSIL is a “special language for communicating between

and among command entities and small units of virtual

platforms generated by computers for the Distributed

Interactive Simulation (DIS) environment CCSIL

includes a set of messages and a vocabulary of military

terms to fill out those messages.” [15] CCSIL was

developed as a component of the DARPA Command

Forces (CFOR) Program [6] The CFOR program focused

on the explicit modeling of battlefield command and

control in virtual simulation CCSIL was based on the

groundbreaking work of TRAC Fort Leavenworth in their

development of the EAGLE BML Salisbury discusses

CCSIL in [15] and in-depth information is available in

[5]

Like EAGLE BML, CCSIL is a highly structured

language It consists of:

 Message Content Definitions: this document

identifies the CCSIL messages, their formats and

their data fields There are approximately 140 currently defined CCSIL messages

 Enumerations: this is the legal vocabulary for the many enumerated data types used in CCSIL messages This vocabulary was based on doctrinal references from each of the services with minor modifications made in some instances to facilitate the objectives of the program

 Formatted Data Types: this is a small set of frequently used data fields, such as point-location and date-time-group (DTG)

A typical CCSIL message is constructed from building blocks of data structures The most basic of these are enumerated, and formatted (Boolean, numeric, etc.) The basic data structures are strung together to form more complex data types and to build more complex relationships among the data The most complicated of CCSIL messages, the Operations Order (Message #101), consists of 16 fields of which 12 are CCSIL Structures (complex data types), 2 are CCSIL Types (enumerated data types), and 2 are alphanumeric (formatted data types) The 12 CCSIL Structures break down into many cascading data-type combinations

For example, a CCSIL operations order is structured with one or more phase sections A CCSIL phase is a first order break down of a complex military operation into a more manageable planning problem It is a building block data structure for specifying what a unit should do It contains the following fields:

 Phase Name: a meaningful, unique, alphanumeric label that describes the actions occurring during the phase The default is progressively increasing numbers in the order (1, 2,

…,n)

 Phase Method of Control: a way to identify the phase’s start time

 Phase Modifier: a means to supply additional information to a subordinate or supporting unit about the phase Phase Modifiers are optional and consist of two parts, a keyword and associated parameters

 Mission Section: a complex data structure containing the mission, operation, and task information A phase section can contain one or more CCSIL Missions The Mission Section contains the following fields:

o Mission Name: a keyword that describes in a general way the action to be taken

by the unit This is an enumerated data type

o Mission Method of Control: similar to Phase Method of Control

o Objective Section: a complex data type giving the name and type of objective of the mission In all cases it is a geographic location

o Mission Modifier: a means to supply

additional information to a subordinate or

supporting unit about a CCSIL Mission Mission

Modifiers consist of two parts, a keyword and

associated parameters

The simplest order would have one phase with one

mission and one task

Both EAGLE and CCSIL were developed from a

simulation perspective and designed to solve specific

application problems They both use program specific,

highly structured messages While doctrinally based,

neither has been formally approved by the doctrine

centers Successful use of these languages depends on

three factors: first, an understanding of when and how to

use the messages; second, a communications module that

enables packaging and unpacking the message contents

(similar to the Communications Module of the CFOR

Infrastructure Services software); and third, a

computer-generated force or other simulation implementation that

accepts and reacts to the messages

3.3 AMSO CDM BML­1

In March 1999, the “Level 1 Model for Battle

Management Language (BML-1)” [2] was published and

accepted as an AMSO Command Decision Modeling

(CDM) standard

The standard organizes doctrinal terms into the “5W’s:”

“Who, What, When, Where, and Why.” These are the key

factors that units use to reason with simulations

Additional factors influencing the 5Ws include command

relationships, formations and general terms An appendix

to the document provides some examples of pull down

menus using the terms as well as a short list of the

doctrinal references

The AMSO CDM BML-1 is not a language and was not

intended to be one While it embodies the definitions that

may constitute the semantics of a language, it lacks the

required syntax It was put forth as a standard to guide

modeling and simulation developers As we explain

throughout this paper, we believe that the above definition

and the focus on simulation developers are insufficient to

address the large-scale problem

4 Implementing a Battle Management

Language

In Section 2 we developed a concept of what BML should

be In this section, with the benefit of looking at the

current BMLs, we further envision how a BML once

developed, could be implemented in an actual C4I system

Note that at this point, we are still defining what a BML is and what the specification of its syntax and semantics will

be However we need to do this with an awareness of how

it will be used to ensure it is capable of being implemented We envision this as being built upon the work that has gone before, EAGLE BML and CCSIL 4.1 Method and Relationship to C4I Data Bases BML is more than a well-structured language It must be

a method that allows complete and unambiguous specification of C2 information, which is directly linked

to doctrine The method must represent doctrine, identify appropriate doctrinal sources, elaborate doctrine into a systematic data model, and specify how the data model communicates information We propose that the appropriate data model is the Joint Common Data Base (JCDB) (Figure 5)

To accomplish this, the BML must incorporate the doctrinal terms, graphics, tactics, etc in a form that Figure 5: Implementation for ABCS Systems

Simulation

ABCS System

GUI GUI

JCDB Data Model BML

BML BML

Object  Model

Simulation

ABCS System

GUI GUI

JCDB Data Model BML

BML BML

Object  Model

allows the intricate relationships of these abstract

concepts to be linked to the physical aspects of the

warfighter’s environment (organizations, features,

persons, facilities, and materiel) The data model must

include the necessary data tables along with the defined

relationships This builds the basic vocabulary, semantics

and syntax BML must unambiguously communicate

these required relationships This implies developing

structured message formats that can be parsed into

existing and future operational messages as well as

formats that communicate with simulations

The BML must blend structure that allows automation of

the language, and ease of use for the military professional

It should not be a radical change from the language the

commander and staff currently use, but instead an

evolution that provides a means to gain structure while

remaining transparent to the user It must be based on

doctrine and linked to the doctrinal sources, both to

ensure standard use/understanding, and to foster concise

and precise use of the language The “formal” BML must

support the “train as you fight” concept and therefore

exist in a single format, at least as far as the military

professional user is concerned The output of the

automated system is allowed to fluctuate based on

whether the intended audience is a human, an “intelligent

agent” or a FCS robot

Figure 6 depicts a subset of JCDB tables This subset

reflects a capability within the JCDB to establish the data

and relationships required for BML implementation, that

is the 5 Ws (Who, What, When, Where, and Why) and the

information needed to coordinate activities The

ORGANIZATION table provides the “Who” Its

relationship to the ORGANIZATION-TYPE table

associates the ORGANIZATION-TYPE function and

echelon codes to specific organizations The “What” is

provided through the TASK table TASKS, a directed

activity, and EVENTS, a significant occurrence, are

categories of ACTIONS, an activity The

ORGANIZATION-TASK table provides the association

of tasks to specific organizations based on the

organizations function and echelon Attributes of the

TASK table provide the “When” and the “Why” The

ACTION-LOCATION table provides the “Where”

Numerous other tables exist within the JCDB that contain

enumerations that portray information required to

coordinate activities such as the

WEAPONS-CONTROL-CODE table (see below)

Further study is required to determine if the enumerations

and relationships as they currently exist are sufficient for

BML implementation or, as we suspect, if additional

tables and relationship will be required