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

Standardizing Battle Management Language - A Vital Move Towards the Army Transformation 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 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 on Understanding of the content of the 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 C4I BML Order 1.2 BML C4I Simulation Taking the widest possible interpretation, we define BML as: Robotic Forces 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 and are difficult to reconcile We will review how well we have addressed these principles in Section 5, our Conclusions Principle 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/multirole system-of-systems that will meet the future ground force requirements of the Army including: direct fire, Figure 1: BML Scope 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 describes our approach to BML Section describes other BML-related efforts Section goes into more detail on BML implementation; and Section Messages USMTF JVMF TADIL OTH Gold ADAP3 concludes, focusing on how our BML concepts address the four BML principles stated above BML Concept 2.1 Requirements To determine BML requirements, it may be beneficial to look at the current BMLs Section 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 Doctrine FM-101-5 ARTEPs BML CCSIL Data Models JCDB Data Model Eagle BML Figure 2: Disparate Components of BML 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 5 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 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 315), 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 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 depicts the current state of disparate information, messages and languages 6 Data/Object Models Messages Doctrine JCDB Data Model XML/ Data Replication FM-1-02 Other FMs ARTEPs Planning BML 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 Army Joint International Figure 3: BML Concept XML/ Data Replication LC2IEDM NATO Doctrine BML XML/ Data Replication C2 Core Data Model XML/ Data Replication JCDB Data Model Joint Doctrine BML BML Figure 4: BML Concept Scalability FM-1-02   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 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 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 Scheme of Maneuver and Sequence of Phases Roles for subordinate units (type) Tasks to accomplish per phase Objective This equates to: Unit has to Mission Activity is The scheme of maneuver is Typical phases are The unit will have the role of with task to in the 2nd phase to take 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 twentyfive variables Examples are:  Battlefield Geometry: approaching, closing, assaulting, etc.;  Combat Effectiveness Summary: ineffective, marginally effective, effective;  Combat Intensity: Receiving indirect fires, etc.;  Logistics Status: Direct Fire Ammo , etc.;  Relationship to enemy: 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 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:  …;  …;  …;  … Situational Awareness Language is also used to synchronize the maneuver of subordinates:  …;  …;  …;  … 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), are CCSIL Types (enumerated data types), and 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 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 9 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 o 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 computergenerated force or other simulation implementation that accepts and reacts to the messages ABCS System Simulation GUI Object  Model BML GUI BML JCDB Data Model BML 3.3 AMSO CDM BML­1 In March 1999, the “Level 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 Implementing a Battle Management Language In Section 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 Figure 5: Implementation for ABCS Systems 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 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 10 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 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 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-CONTROLCODE 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 11 12 ORGANIZATION-TYPE ORGANIZATION-TYPE identifier ORGANIZATION-TYPE function code ORGANIZATION-TYPE echelon code … ORGANIZATION WHO ORGANIZATION identifier ORGANIZATION-TYPE identifier (FK) … WEAPONS-CONTROL-CODE ORGANIZATION-TASK No Statement ORGANIZATION identifier (FK) Weapons Free identifier ORGANIZATION-TASK Weapons TASK IdentifierHold (FK) Weapons Tight ORGANIZATION-TASK requirement category code Unknown ORGANIZATION-TASK rejection code ORGANIZATION-TASK support requirement amplification text … ACTION category code WHAT EVENT TASK TASK TASK identifier (FK) NULL TASK name TASK desired effect description code WHY TASK start date TASK end date TASK estimated duration ACTION ACTION identifier ACTION category code ACTION verb code … WHEN TASK minimum duration ACTION-LOCATION WHERE TASK maximum duration ACTION identifier (FK) … ACTION-LOCATION index ACTION-LOCATION latitude coordinate ACTION-LOCATION longitude coordinate … Figure 6: Subset of JCDB Tables showing the Ws 13 Table 4.2 Look and Feel of BML One great challenge to getting BML implemented is making it acceptable to the military professional user If the operational community does not accept the concept and use it, the software will only take up space on a computer To make it acceptable to the “field” users, it must have the comfortable look and feel of what they are using now Where major changes are incorporated, the user must realize the benefits either through saving time or adding clarity We must show that BML will not hinder a commander’s abilities but instead will aid his command and staff process There is an advantage to addressing this problem now With the Army’s transition to a digital force it is also examining transformation’s effects on how it operates This includes digitization’s effects on information flow and processes such as the Military Decision Making Process (MDMP) Projects such as the AGILE Commander Advanced Technology Demonstration (ATD), a program whose objective is to demonstrate information technologies enabling an extremely mobile commander aided by continuous battle planning and execution control systems, and FCS, as well as the different fielding implementations of ABCS versions, set the stage for the operational force to expect changes The operational force therefore should anticipate an evolution to BML Describing what BML will look like to the user greatly depends on how the ABCS and supporting technologies evolve Currently, command and control information flow is very much dependent on textual applications The current concept for future systems envisions the flow of command and control information to be much more visual in nature where command posts at different echelons in widely divergent locations will share information through “white boards,” graphics, and animations Regardless of whether we are using text, graphics, a combination, or some other means of conveying the information, the information itself will remain generally the same Building the BML into the JCDB and linking it to whatever presentation media is used will allow making the mechanics behind translation from one media to another transparent Imagine a future training scenario where a commander draws a COA sketch on a white board and transmits this information to his subordinates, half of whom are live and half simulated The system, knowing which subordinates are live and which are simulated (they are marked as such within the JCDB), automatically translates the data transmitted to a format appropriate to the receiver The humans receive a graphic similar to what the commander was looking at while the simulated subordinate receives a data file that it can interpret From the user’s perspective, the translation is transparent; it takes place within the software but is based upon a BML specification Initial applications implementing the BML will probably be text based, but linked to graphics This is because most current operational and simulation applications are still text based A BML application of the operations order for instance would probably look very much like the current paragraph operations order, however with much more structure applied to the five paragraphs The structure orients on the Ws (Who, What, When, Where, and Why) plus the required synchronization and coordination information Structuring the order is a combination of automatic postings based on links to the higher headquarters’ order, the approved COA sketch and statement, and the associated synchronization matrix; drop down menus based on the relationship of unit type and echelon to operations, missions and tasks; drag and drop; and fill in the blanks (Figure 7) 14 15 Graphics convert to BML Division Mission Division attacks on order in zone to seize OBJ SLAM Division Concept of Operations Form of maneuver: Penetration Main effort: BLUE-MECH-BDE2, on order BLUE-ARMOR-BDE1 Supporting effort: BLUE-MECH-BDE1 BLUE-ARMOR-BN1 Deep: Reserve: BLUE-AVN-BDE1 Security: BLUE-CAV-SQN1 TCF: BLUE-MECH-TM1 Tasks to Subordinates Who What When Where Why BLUE-MECH-BDE1 Attacks On Order Zone Fix (MRR1) BLUE-MECH-BDE2 Attacks On Order Zone Penetrate (MRR2) BLUE-ARMOR-BDE1 Follows and assumes (B M-BDE2) On Order Zone Seize (OBJ SLAM) BLUE-AVN-BDE Occupy On Order AA Eagle Reserve BLUE-ARMOR-BN1 Follow and Support (B-ABDE1) On Order Zone Support (B-A-BDE1) BLUE-CAV-SQN1 Screen On Order Zone Protect (Div left flank) BLUE-MECH-TM1 TCF On Order Zone (PL Amber to PL Blue Protect (Div rear area Figure 7: Example of Graphic Conversion to BML 16 Terms, such as “block” could be hyperlinked to the appropriate definition and doctrinal reference For instance FM 101-5-1 gives two definitions for “block”” First: “A tactical task assigned to a unit that requires it to deny the enemy access to a given area or to prevent enemy advance in a given direction or an avenue of approach It may be for a specified time Units assigned this mission may have to retain terrain and accept decisive engagement.” This is used in a maneuver unit’s mission, concept of operations, or task to subordinate units Second: “An obstacle effect that integrates fire planning and obstacle effort to stop an attacker on a specific avenue of approach or to prevent an enemy from exiting an engagement area.” This is used in the engineer subparagraph of the concept of operations, the engineer subparagraph of tasks to combat support units, or Annex F (Engineer) Some terms are even more complicated such as “clear” which has nine possible meanings depending on whether the context is ground, air, logistic, meteorological, communication, etc Conclusion In this paper, we have articulated a need for BML and given our approach for developing a comprehensive and flexible BML We have not described a specification or an implementation of BML, but have explored how we can base our system implementation on a specification that is stored in a tactical C4I database (such as the JCDB) If “free text” in our message systems is the problem, then replacing “free text” with structured text is a way to solve the problem This was the approach that EAGLE BML and CCSIL took Both of these languages replaced semistructured official message formats containing “free text” fields with highly structured messages containing clearly defined data fields To communicate between a C4I device and an “intelligent agent” within EAGLE or CFOR requires an interface such as the Modular Reconfigurable C3 Interface (MRCI) MRCI interprets the information between the C4I device message format (USMTF, JVMF, etc.) and EAGLE BML or CCSIL For the most part, when the message flow is from the C4I system to the simulation a human must translate the “free text” portion of the C4I message into the highly structured CCSIL or EAGLE format Note that the efforts to solve the “free text” challenge mentioned so far have all been initiated from the simulation side of the interoperability problem Kleiner, Carey and Beach [13], based on their experiences dealing with CFOR, CCSIL, and MRCI, recognized that this would not solve the problem, and recommended that the doctrine, training, simulation and C4I development communities embark on a joint effort to resolve the problem This is now beginning SIMCI OIPT sponsored BML efforts in FY02 will explore development of a prototype BML within a JCDB type database The goal is to prove the viability of building a BML through data representation and relationships, linked to doctrine The prototype will link, through the database, the products of course of action development and analysis tools created under the AGILE Commander ATD with structured message formats that will be used to control a simulation The Defense Modeling and Simulation Office (DMSO) Functional Description of the Mission Space (FDMS) (formerly CMMS) Resource Center [9] will also be examined for possible means of linking BML to the doctrine Interoperability between C4I systems and simulations is critical for transitioning to the Army’s Objective Force Operational forces must use their C4I systems to interact with supporting simulations to conduct realistic, rigorous training, support mission rehearsals and, in the future, support an expedited military decision making process Additionally, the Research, Development, and Acquisition (RDA) and Advanced Concepts and Requirements (ACR) domains will often require the same capabilities to test and evaluate C3 systems, and to conduct controllability analysis of proposed force structure changes Achieving interoperability depends on several factors as noted in [18] While extremely important, none of these solve the “free text” challenge A well thought out and implemented BML will, thus allowing communication of command and control information in a format that can be read, parsed, interpreted and acted upon by “intelligent agent” software whether in a simulation or an FCS robot BML is vital to achieve C4I to simulation interoperability There is a need for a unified BML throughout the Army Developing an effective BML now will contribute significantly to the evolution of the Objective Force and the development of the Future Combat Systems Acknowledgements The authors would like to thank Frank Carr, Ron Sprinkle and Brian Whitfield for their detailed review of this paper Their comments materially improved this work and we are indebted to them Scott Carey and Martin Kleiner were supported by the Overarching Integrated Product Team for Simulation to C4ISR Interoperability (SIMCI OIPT) Dr Hieb was supported by the Army’s Office of the Director for Information Systems for C4ISR, the 17 Army Modeling and Simulation Office, and the SIMCI OIPT while writing this paper Dr Hieb is an Architect of the SIMCI OIPT The authors gratefully acknowledge the encouragement and support given by the SIMCI OIPT and TRADOC for the development of BML References 1) Agile   Commander   Advanced   Technology Demonstration,   June   2001, (http://www.c2d.c3sys.army.mil:443/agile.htm .) 2) Argo, H., Brennan, E.J., Collins, M.W., Gipson, K., Lindstrom, C., and MacKinnon, S., “Level 1 Model for Battle Management  Language (BML­1), TEMO Simulation Laboratory (TSL), Fort Leavenworth, KS, 23 March 1999 3) Baumann,   J.,   “Military   Applications   of   Virtual Reality”, (http://hitl.washington.edu/scivw/EVE/II.G.Military html) 4) Boutelle,   S.W   and   Filak,   R.,   “AFATDS:   The   Fire Support   Window to  the  21st   Century”,  Joint  Force Quarterly, Spring 1996 5) CCSIL   Message   Content   Definitions   (ACTD Version), http://ms.ie.org/cfor/cfor.html#Documentation 6) Command   Forces   Simulation   (CFOR)   web   site, http://ms.ie.org/cfor/cfor.html 7) Electronic   Computers   Within   the   Ordnance   Corps, Chapter   VI   –   Computers   for   Solving   Gunnery Problems (http://www.arl.mil/~mike/comphist/61ordnance/cha p6.html) 8) FM101­5   Staff   Organization   and   Operations, Headquarters Department of the Army, 31 May 1997 9) Haddix,   F.,   Sheehan,   J.,   Loesekann,   M.,   and Scrudder,   R   “Semantics   and   Syntax   of   Mission Space Models”, Paper 99F­SIW­152, Fall Simulation Interoperability Workshop, 1999 10) Hieb,   M.R.,   and   Blalock,   J.,   “Data   Alignment Between   Army   C4I   Databases   and   Army Simulations”,   Paper   99S­SIW­034,   Spring Simulation Interoperability Workshop, 1999 11) Hieb,   M.R.,   and   Sprinkle,   R.,   “Simulation Infrastructure   for   the   DII   COE   Architecture:   The Army   Vision”,   Paper   00F­SIW­035,   2000   Fall Simulation Interoperability Workshop, 2000 12) Hieb, M.R., and Staver, M.J.: “The Army’s Approach to   Modeling   and   Simulation   Standards   for   C4I Interfaces”,   Paper   98F­SIW­259,   1998   Fall Simulation Interoperability Workshop, 1998 13) Kleiner,   M.S.,   Carey,   S.A.,   and   Beach,   J., “Communicating   Mission­Type   Orders   to   Virtual Commanders”, Paper, Proceeding of the 1998 Winter Simulation Conference, December 1998 14) Ogren,  J., and Fraka,  M., “EAGLE  Combat Model Battle   Management   Language   (BML)”,   Powerpoint presentation, BML Symposium at Fort Leavenworth, KS,   25   April   2001 (http://www.simci.org/html/librsry.html  Public Folder/Meetings/Architect   Meetings/Battle Management   Language/BML   Symposium/Eagle Presentation) 15) Salisbury,   M.,   “Command   and   Control   Simulation Interface Language (CCSIL): Status Update” MITRE Informal Report, Twelfth Workshop on Standards for the   Interoperability   of   Defense   Simulations,   March 1995 (http://ms.ie.org/cfor/diswg9503/diswg9503.pdf) 16) SIMCI   WWW   Site,   Army   Overarching   Integrated Product   Team   for   Simulation   to   C4ISR Interoperability: http://www.simci.org, 2001 17) Timian,   D.H.,   Hicks,   M.W.,   and   Hieb,   M.R.,   “An Approach for Using DII COE Components to Link Simulations and C4I Systems: A Case Study Using the CMP”, Paper   00F­SIW­011,   2000   Fall Simulation Interoperability Workshop, 2000 18) Timian,   D.H.,   Hieb,   M.R.,   Lacetera,   J.,   Tolk,   A., Wertman, C., and Brandt, K.: “Report Out of the C4I Study   Group”,   Paper   00F­SIW­005,   2000   Fall Simulation Interoperability Workshop, 2000 19) Wartick,   S.P.,   Haugh,   B.A.,   Loaiza,   F.,   and   Hieb, M.R., “Building in Interoperability: A Comparison of C4I   Data   Models   and   Simulation   Object   Models”, Paper   01S­SIW­021,   2001   Spring   Simulation Interoperability Workshop, 2001 20) Weapon   System   Handbook,   United   States   Army, 2001   (http://www.saalt.army.mil/sard­ zs/saal_zs_public_docs/weapon_systems_handbook/) 18 Author Biographies SCOTT CAREY has been a senior researcher/writer and program   manager   for   Logicon   Technology   Solutions’ Knowledge   Acquisition   program   since   1994   He   is   a retired Army Lieutenant Colonel with more than twenty years experience as an armor officer. His last assignment before retirement was as the senior command and control operating   system   subject   matter   expert   and observer/controller   for   the   Battle   Command   Training Program   at   Fort   Leavenworth,   Kansas   Mr   Carey   has seven  years experience  dealing with command decision modeling. Mr. Carey has a BS degree in Education from the   University   of   Maine   and   a   MS   degree   in   Business Administration from Boston University, and is a graduate of the U.S. Army Command and General Staff College MARTIN KLEINER  has been a program manager and senior   researcher/writer   for   Logicon   Technology Solutions’   Knowledge   Acquisition  program  since   1994 He retired from the U.S. Army with the rank of Colonel and   has   experience   in   the   areas   of   maneuver   warfare, intelligence,   campaign   planning,   operational   level targeting,  and  research  and  development  He  has  seven years   experience   dealing   with   command   decision modeling   Mr   Kleiner   received   a   BS   degree   in Organizational   Behavior   and   Management   from   the University of Houston and is a graduate of the U.S. Army Command and General Staff College and the Army War College MICHAEL HIEB is a senior scientist with the IITRI/AB Technologies Group Dr Hieb was the architect of the MRCI interface project while at SAIC He received his PhD in Information Technology at George Mason University in 1996, developing an instructable Modular Semi-Automated Forces agent He performed his doctoral research at the Center for Excellence in Command, Control, Communications and Intelligence at GMU He has published over 35 papers in the areas of learning agents, knowledge acquisition, interface technology and multistrategy learning When working for IntelliTek, Dr Hieb implemented a distributed problemsolving testbed at the Goddard Space Flight Center Previously, he worked as a Nuclear Engineer for General Electric RICHARD BROWN  is currently employed as a Senior Telecommunications Manager in the Army's Training and Doctrine   Command's   Integration   Office   for   Battle Command Systems. Over the last 25 years he has been a field   artillery   specialist   in   tactical   and   fire   control systems, a designer of command posts and an integrator of   the   soldiers,   equipment   and   processes   that   form   the command   posts   for   army   units   at   all   echelons   Most recently, he has been a principal coordinator among the TRADOC Program Integration Offices  for Army Battle Command   Systems   and   the   TPIO­Synthetic   Training Environment and the TPIO­Terrain Data. Mr. Brown is a 1967 graduate of the University of Massachusetts with a BS   in   Experimental   Psychology   He   was   also commissioned a 2LT of Artillery from  ROTC. He is a graduate   w/Honors,   US   Army   Command   and   General Staff   College   and   a   graduate   w/   Honors,   US   Army Management  Staff College. Mr. Brown retired from the US Army Reserve as a LTC of Field Artillery in 1997. He received  the  US  Army  MANPRINT   Practitioner  of   the Year   Award   in   1998   for   Human   Factors   Engineering Work on the Army Battle Command System  ...  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. .. within the JCDB), automatically translates the data transmitted to a format appropriate to the receiver The humans receive a graphic similar to what the commander was looking at while the simulated... contained in FM 10 1-5 -1 , Operational Terms and Graphics (future FM 1-0 2) and BML-1 as data tables, and  Build in the syntax and semantics as defined through the Army Universal Task List (AUTL)