Standardizing Battle Management Language Facilitating Coalition Interoperability

Transcription

1 Standardizing Battle Management Language Facilitating Coalition Interoperability Scott A. Carey Martin S. Kleiner Northrop Grumman Information Technology 1286 Eisenhower Road Leavenworth, KS (913) Ext. 34 Michael R. Hieb, Ph.D. IITRI/AB Technologies Group 1901 N. Beauregard St. Alexandria, VA (703) Richard Brown TPIO-ABCS 415 Sherman Ave. Fort Leavenworth, KS (913) Keywords: Battle Management Language (), Eagle Simulation Language, Command and Control Simulation Interface Language (CCSIL), Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR), Army Battle Command Systems (ABCS), Joint Common Data Base (JCDB), Land Command and Control Information Exchange Data Model (LC2IEDM), Future Combat Systems (FCS), NATO Doctrine. ABSTRACT: Communication of command and control (C2) information for military forces is moving towards more digitized systems. As such, not only are humans consuming this information but also more and more automated systems are doing so. Most recently there has been a need to use simulations to stimulate and be stimulated by the Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR) systems. This communication is becoming less interpersonal and more data oriented. The most critical C2 information, the commander s intent, orders and directives, does not currently flow as data. 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 for the future forces that have robotic components. The United States Army s Simulation to C4I Overarching Integrated Product Team (SIMCI OIPT) has identified as an essential issue for addressing this problem. This paper addresses the SIMCI OIPT proposed approach of adapting representations of orders and directives so that they are directly derived from doctrine and reside within the current standardized C4ISR data models. This provides a means to link the (terminology and symbology) directly to their doctrinal source; and it allows operational forces to use their C4ISR 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. Additionally, we examine how this approach can be expanded to the Joint and Combined/Coalition domains to not only advance interoperability between simulations and C4ISR devices but also between Services and other national forces. 1. Introduction The purpose of this paper is to describe the progress being made towards, and importance of, a single Army Battle Management Language () [7] and how can be expanded to encompass Joint and Combined/Coalition forces to improve interoperability in multiple areas. With NATO as an example, military forces today are developed, trained, deployed, and employed as coalitions [18]. One only needs to look at the major force employments of the past fifteen years (DESERT STORM, Bosnia- Herzegovina, Kosovo, and Afghanistan) to see the everincreasing use of Coalition forces. The coordinated use of forces from multiple countries poses many challenges not the least of which is interoperability. Interoperability encompasses many areas including equipment, ammunition, fuel, doctrine and tactics to name a few. Perhaps the greatest interoperability challenge is command and control. 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

2 and operations in the accomplishment of the mission. [11] Command and Control (C2) of military operations has always been a key target for technology advancement. The development of automated digitized C2 systems, which for the U. S. Army has occurred exceedingly rapidly in relative terms [10] [6], 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. We approach this problem initially as a current crucial simulation interoperability issue. However, this problem will also impact C4ISR 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 C4ISR science and technology areas. The Army s SIMCI OIPT [22] has developed a comprehensive approach to solving Simulation to C4ISR Interoperability. The fundamental premise is to align and integrate the Architectures [14], Software Components [23] and Data Representations [13] [25] of both C4ISR and Simulations Systems. 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 and has 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 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 among the simulation and the C4ISR systems. Enabling the C4ISR 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 C4ISR systems significant progress still needs to be done. This is due to the reliance on unstructured, and quite often ambiguous free text within the operational C2 messages that are passed within the C4ISR systems. Free text can seldom be efficiently parsed. 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 [20] or the Command Forces (CFOR) software [9] 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

3 rehearsal simulations. The Agile Commander Advanced Technology Demonstration (ATD) is investigating more advanced applications for these products [26], [2]. While some emerging C4ISR 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 C4I Order C4I Simulation Taking the widest possible interpretation, we defined in a paper presented at the Fall 2001 Simulation Interoperability Workshop [7] as: 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 offered four principles that guided our discussion of though the paper: 1) must be unambiguous; 2) must not constrain the full expression of a commander s intent; 3) must use the existing C4ISR data representations when possible; and 4) 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, but necessary. 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 C4ISR infrastructure. Thus, many advanced and flexible planning representations, while very well suited to, are not appropriate, due to integration difficulties. Finally, without Principle 4, is useless. must contain no distinction between live or simulated forces ensuring that commanders and staff can train as they fight. They use the same whether they are dealing with live subordinates, a simulation, or a Future Combat System (FCS) robot (Figure 1). 1.3 Need for for the Future Combat System The FCS is a top priority Science and Technology (S&T) program to achieve the Objective Force. [26] 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, 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 Robots 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 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 for the U.S. Army. Section 3 goes into more detail on U.S. Army implementation. Section 4 addresses application to Joint and Combined/Coalition domains; and Section 5 concludes. 2. Concept 2.1 Requirements Figure 1: Scope Robotic Forces To determine requirements, it may be beneficial to look at the most notable simulation s. The highly structured EAGLE [20], the Command and Control Simulation Interface Language (CCSIL) [8] [21], and the

4 Army Modeling and Simulation Office (AMSO) -1 standard [3] were developed to support simulations. While successful in their application, they are not operational USMTF user friendly. Additionally, there is JVMF the language used on a daily basis by military professionals to command TADIL and control live forces. Doctrinal manuals such as FM (future FM 1-02), Operational Terms and OTH Graphics, define the vocabulary. The Gold associated grammar is defined by ADAP3 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 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. 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. Messages As emerging and future simulations are developed we are faced with three options in meeting the requirement for. First, we can continue as we have in the past and create s that are specific to each simulation. Second, we can develop a that is standard within the simulation community and create interpreters between it and the C4ISR systems. Finally, we can develop a that is standard within both the simulation and C4ISR domains. To support the train as we fight principle, we recommend developing a that is standard within both domains. Figure 2: Disparate Components of 2.2 Concept Doctrine FM (FM 1-02) ARTEPs Data Models JCDB Data Model CCSIL Eagle The SIMCI-OIPT and Director for Information Services for C4ISR (DISC4) sponsored a two-day Symposium, hosted by the Training and Doctrine Command's Integration Office for Army Battle Command Systems (TPIO-ABCS), at Fort Leavenworth, Kansas on 25 and 26 April This Symposium brought together representatives from all of the concerned communities (C4ISR development, simulation, doctrine, training, and operational communities) in order to examine the problem. Key findings from the symposium were: Unanimous agreement that a formal is needed, The ABCS Common Services Operational Requirements Document (ORD) needs to formally state the requirement, should be developed jointly between the operational and simulation communities. TRADOC is the ultimate proponent for. 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 , Operational Terms and Graphics (future FM 1-02) and -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

5 Messages XML/ Data Replication Figure 3: Concept 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). 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. 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 Simulation GUI Object Model Data/Object Models Tactical C4ISR Data Model ABCS System GUI JCDB Data Model Doctrine Doctrinal Manuals Figure 4: Implementation for ABCS Systems those areas where a term has multiple definitions or there are subtle differences in the meanings of different terms. As the work continues to align the data models among simulations and C4ISR systems then this approach, since it involves building into the JCDB, will lead to better alignment/adoption of a single for both domains (Figure 4). 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. Implementing a Battle Management Language In Section 2 we developed a concept of what should be. In this section we further envision how a once developed, could be implemented in an actual C4ISR system. Note that at this point, we are still defining what a 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 and CCSIL. 3.1 Method and Relationship to C4ISR Data Bases 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 4). To accomplish this, the must incorporate the doctrinal terms, graphics, tactics, etc. in a form that 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. 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.

6 ORGANIZATION-TYPE ORGANIZATION-TYPE identifier ORGANIZATION-TYPE function code ORGANIZATION-TYPE echelon code ACTION category code 1 EVENT 2 TASK 3 NULL ACTION ACTION identifier ACTION category code ACTION verb code WHO ORGANIZATIONWHO ORGANIZATION identifier ORGANIZATION-TYPE identifier (FK) TASK WHAT TASK identifier (FK) TASK name TASK desired effect description code TASK start date TASK end date TASK estimated duration TASK minimum duration TASK maximum duration ORGANIZATION-TASK ORGANIZATION identifier (FK) ORGANIZATION-TASK identifier TASK Identifier (FK) ORGANIZATION-TASK requirement category code ORGANIZATION-TASK rejection code ORGANIZATION-TASK support requirement amplification text. WHY WHEN WHERE ACTION-LOCATIONWHERE ACTION identifier (FK) ACTION-LOCATION index ACTION-LOCATION latitude coordinate ACTION-LOCATION longitude coordinate Figure 5: Subset of JCDB Tables showing the 5 Ws The 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 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 5 depicts a subset of JCDB tables. This subset reflects a capability within the JCDB to establish the data and relationships required for 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). WEAPONS-CONTROL-CODE 0 No Statement 1 Weapons Free 2 Weapons Hold 3 Weapons Tight 4 Unknown Table 1

7 Further study is required to determine if the enumerations and relationships as they currently exist are sufficient for implementation or, as we suspect, if additional tables and relationship will be required. 4.2 Look and Feel of One great challenge to getting 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 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. In constructing we need to consider its flexibility versus its efficiency. Efficient takes the form of interactions that are highly structured, such as communications between pilots and air traffic controllers or between artillery observers and fire direction center. The efficiency accommodates the tension of dangerous, stressful situations and the potential for degraded communications media. Flexible, on the other hand, approaches the concept of free text where the users communicate in natural language. Describing what 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 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 specification. Initial applications implementing the will probably be text based, but linked to graphics. This is because most current operational and simulation applications are still text based. A application of the operations order for instance would probably look very much like the current 5 paragraph operations order, however with much more structure applied to the five paragraphs. The structure orients on the 5 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. Terms, such as block could be hyperlinked to the appropriate definition and doctrinal reference. For instance FM (future FM 1-02) 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

8 Figure 6: Army, Joint and NATO Doctrine Hierarchies [17] 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. 4. Application to Joint and Combined/Coalition Domains The focus of this paper thus far has been on developing a in order to improve interoperability between Army C4ISR systems and simulations. This section will address how this problem extends to the other U. S. Services as well as to coalition members. It will also examine how can be applied to help solve not only the C4ISR to simulations interoperability problem, but also help solve interoperability issues between the Services themselves and between coalition members. 4.1 Interoperability requirement. When examining interoperability issues concerning the different Services, or between nations in a coalition we usually talk about issues affecting their working together. We are not talking about their C4ISR systems being interoperable with simulations. Since the early 1990 s the U. S. Services have undertaken an extensive revision of Service and Joint doctrine to first document and then to standardize and align their doctrine with a goal of improving interoperability in training and execution. This same process is occurring within formal alliances such as NATO (see Figure 6). NATO has a Standardization Organization (NSO) whose role is to enhance interoperability of Alliance forces to train, exercise and operate effectively together, and when appropriate, with forces of Partner and other nations, in the execution of their assigned tasks. [18, p. 314] It is almost impossible to imagine a situation in the future when a single U. S. Service will be unilaterally employed. Because future military operations, and a significant amount of training, will be Joint in nature, it is critical that a Joint Service approach be taken to the development effort. The same issues that have driven the Army to embark on this program also confront the other Services as they develop both their C4ISR and simulation systems. While the other Services have or may have related efforts under consideration, it would seem only sensible that an attempt be made to harmonize and standardize these endeavors. Forgoing this, we will face the same set of disparate solutions that will mirror our current intra-service interoperability problems. Similarly as was pointed out earlier we are seeing more and more frequently combined efforts to solve world problems. Seldom is unilateral use of force by a nation the

9 ACTION-OBJECTIVE ACTION-id (FK) ACTION-OBJECTIVE-index ACTION-OBJECTIVEcategory-code WHY ACTION WHAT ACTION-id ACTION-category-code ACTION-name ACTION-category-code ACTION-TASK ACTION-EVENT ACTION-TASK-id (FK) ACTION-TASK -minimum-duration ACTION-TASK -maximum-duration ACTION-TASK -estimated-duration ACTION-TASK -planned-start-date ACTION-TASK -planned-end-date ACTION-TASK -planned-start-time ACTION-TASK -planned-end-time WHEN ORGANISATION-TYPE ORGANISATION-TYPE-id ORGANISATION-TYPE -category-code ORGANISATION-TYPE- CATEGORY-CODE UNIT-TYPE POST-TYPE UNIT-TYPE UNIT-TYPE-id (FK) UNIT-TYPE -category-code UNIT-TYPE -mobility-code UNIT-TYPE -service-code UNIT-TYPE -size-code (echelon) ORGANISATION WHO ORGANISATION-id (FK) ORGANISATION -category-code ORGANISATION -nickname-name ORGANISATION -type-id (FK) LOCATION WHERE LOCATION-id LOCATION -category-code ORGANISATION-ACTION-ASSOCIATION ORGANISATION-id (FK) ACTION-id (FK) ORGANISATION-ACTION-ASSOCIATION-index ORGANISATION-ACTION-ASSOCIATION -category-code ORGANISATION-ACTION-ASSOCIATION -effective-date ORGANISATION-ACTION-ASSOCIATION -effective-time ORGANISATION-ACTION-ASSOCIATION -intent-text MATERIAL-POINT ORGANIZATION-POINT FACILITY-LOCATION FEATURE-LOCATION PERSON-POINT Figure 7: Subset of LC2IEDM Tables showing the 5 Ws desired mode of operation. Instead either temporary (as in DESERT STORM) or permanent (as in NATO) coalitions of nations provide forces to resolve or prevent conflicts. As was pointed out in Bendz et al [5], Coalitions of national forces are the norm for almost all current operations, making agile and effective force interoperability a key element in the ability to quickly and effectively respond to crisis situations. Unfortunately, today s national C4ISR and force developments and employment strategies tend to be done individually on a national basis, posing serious obstacles to effective coalition operations. A, as described in this paper, developed and applied by the other Services and by coalition members would not only allow interoperability among their C4ISR systems and simulations, but also among themselves. 4.2 Technical Approach To create the Army we describe an approach of: Incorporating the doctrinal base into the Joint Common Data Base (JCDB), Building in the vocabulary as contained in FM , Operational Terms and Graphics (future FM 1-02) and -1 as data tables, and Building in the syntax and semantics as defined through the AUTL, ARTEP-MTP and the other related Field Manuals for use of the items specific to echelon and type units as relationships between data tables. Expanding this approach to other Services and the Joint level would involve Incorporating the individual Services and Joint doctrinal base into the C2 Core Data Model. Expanding the vocabulary from the FM (future FM 1-02) to Joint Publication 1-02, Department of Defense Dictionary of Military and Associated Terms, as well as any Service specific dictionaries. Expanding the syntax and semantics as defined through the Universal Joint Task List (UJTL), CJCSM B, and Joint Doctrinal manuals; as well as each Service s task list (Universal Naval Task List (UNTL), OPNAVINST /MCO /USCG COMDTINST M3500.1; Air Force Task List (AFTL), Air Force Doctrine Document 1-1) and their respective doctrinal manuals. Expanding it to a coalition such as NATO would be more challenging but follow the same paradigm: Incorporating NATO doctrine into the Land Command and Control Information Exchange Data Model (LC2IEDM).

10 Expanding the vocabulary to include Alliance Administrative Publication 6 (AAP-6), NATO Glossary of Terms and Definitions (English and French) Perhaps most challenging would be identifying/expanding the syntax and semantics since it does not appear that a NATO equivalent of the UJTL or ARTEP exists. Just as Figure 5 showed how the 5Ws existed within the JCDB, Figure 7 shows how they exist within the LC2IEDM. We believe that the same concept for developing for the U. S. Army will also work for the other Services, Joint and Combined/Coalition operations (see Figure 8). 4.3 Benefits The primary benefit gained from adopting a as described within this paper is increasing the interoperability between C4ISR systems and simulations. This is gained through adoption of the doctrinal terms and graphics and relating them through the data model to the physical aspects of the battlefield in such a way as to incorporate the syntax and semantics. Coupled with highly structured message formats that minimize free text, this provides messages that a computer can read, parse and act upon. The terms used in the messages are linked directly to the doctrinal source. When multiple interpretations of a term are possible the author s intended meaning can be ascertained by moving the cursor over the term. A secondary benefit of is an increase in the preciseness and conciseness of communication between human operators. A common finding of observer/controllers (OCs) of the Army s Battle Command Training Program (BCTP) has been that unit s plans/orders are longer than needed, including information contained in doctrinal manuals and/or Standing Operating Procedures (SOP); and that conflicting, or at least confusing, terminology is often intermixed between paragraphs or annexes. Linking the terms to the doctrinal definitions will allow the authors to ensure they are using the term that correctly portrays their intent. Increasing the structure of the messages will reduce extraneous and duplicate information. A tertiary benefit is gained in that a person not directly familiar with the specific domain (e.g. an individual from a different Service reading an Army OPORD) could read the message on their C4ISR device and use the hyperlinks of doctrinal terms/graphics to gain insight to the described operation. Fully developed, a as described could allow a quicker integration when a Navy Seabee unit is attached to an Army Engineer Battalion conducting hurricane relief operations. As the task organization information is input into the C4ISR devices the unit information to include organization composition, capabilities and doctrinal linkages are passed to the gaining unit through the data base allowing the Engineer battalion commander to not only know what the equipment and personnel the Seabee unit brings with it but also the doctrinal tasks/missions it can be assigned. From a coalition perspective, imagine how some of these characteristics might be even more beneficial. The free text problem faced in interpreting messages for computer use is also present when translating messages from one national language to another. will obviate the free text and interpretation of the structured text will be based on doctrinal terminology that is directly linked to the definitions through the database. It should be much simpler to interpret from one national language to another, than to interpret free text ; in fact, it should be possible to automate the process as a message is sent from one nation s C4ISR device to another nation s. 5. Conclusion In this paper, we have articulated a need for and given our approach for developing a comprehensive and flexible. We have addressed how this is scalable to include other Services, the Joint community and coalitions. We have not described a specification or an implementation of, but have explored how we can base our system implementation on a specification that is stored in a tactical C4ISR database (such as the JCDB and/ or the LC2IEDM). Building the into the tactical database makes it available for many possibleimplementing applications: messages (current formats or emerging formats such as XML), graphics, white boards, or data replication. Army Joint International XML/ Data Replication XML/ Data Replication XML/ Data Replication LC2IEDM C2 Core Data Model JCDB Data Model Figure 8: Concept Scalability NATO Doctrine Joint Doctrine FM-1-02

11 Previous efforts to solve the free text challenge 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 C4ISR development communities embark on a joint effort to resolve the problem. This is now beginning. Interoperability among C4ISR systems and simulations is critical for transitioning to the Army s Objective Force. Operational forces must use their C4ISR 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. 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 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. is vital to achieve C4ISR to simulation interoperability. It can also assist in achieving command and control interoperability within Joint and coalition environments acting as the true common language between humans, machines, Services and national militaries. There is a need for a unified. Developing an effective now will contribute significantly to the evolution of the U. S. Army s Objective Force, development of the Future Combat Systems, and overall command and control interoperability of forces. 6. Acknowledgements The authors gratefully acknowledge the encouragement and support given by the SIMCI OIPT and TRADOC for the development of. 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 Army Modeling and Simulation Office, and the SIMCI OIPT while writing this paper. Dr. Hieb is an Architect of the SIMCI OIPT. 7. References 1) Allied Administrative Publication 6 (AAP-6) NATO Glossary of Terms and Definitions (English and French), 2002, stanag/aap006/aap6.htm 2) Agile Commander Advanced Technology Demonstration, June 2001, ( army.mil:443/agile.htm.) 3) Argo, H., Brennan, E.J., Collins, M.W., Gipson, K., Lindstrom, C., and MacKinnon, S., Level 1 Model for Battle Management Language (-1), TEMO Simulation Laboratory (TSL), Fort Leavenworth, KS, 23 March ) Baumann, J., Military Applications of Virtual Reality, ( html) 5) Bendz, J., Johannisson, P., Ohland, G., Frank, A., Dahmann, J., Konwin, K., Lof, S. and Briggs, R., Coalition Interoperability Through Standards-Based Collaborative Environments, Paper 01F0SIW-053, Fall Simulation Interoperability Workshop, ) Boutelle, S.W. and Filak, R., AFATDS: The Fire Support Window to the 21st Century, Joint Force Quarterly, Spring ) Carey, S., Kleiner, M., Hieb, M. and Brown, R., Standardizing Battle Management Language A Vital Move Towards the Army Transformation, Paper 01F-SIW-067, Fall Simulation Interoperability Workshop, ) CCSIL Message Content Definitions (ACTD Version), 9) Command Forces Simulation (CFOR) web site, 10) Electronic Computers Within the Ordnance Corps, Chapter VI Computers for Solving Gunnery Problems ( p6.html) 11) FM101-5 Staff Organization and Operations, Headquarters Department of the Army, 31 May (to be renumbered FM 5-0) 12) Haddix, F., Sheehan, J., Loesekann, M., and Scrudder, R. Semantics and Syntax of Mission Space Models, Paper 99F-SIW-152, Fall Simulation Interoperability Workshop, ) Hieb, M.R., and Blalock, J., Data Alignment Between Army C4I Databases and Army Simulations, Paper 99S-SIW-034, Spring Simulation Interoperability Workshop, ) 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 15) 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, ) 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 ) May, G., briefing NATO Doctrine Development, Semi-Annual Army Doctrine Conference November 2001, saadc2001briefings/natodoctrine.ppt. 18) NATO Handbook, 2001, docu/handbook/2001/index.htm 19) NATO Logistics Handbook, 1997, nato.int/docu/logi-en/1997/lo-1701.htm 20) Ogren, J., and Fraka, M., EAGLE Combat Model Battle Management Language (), Powerpoint presentation, Symposium at Fort Leavenworth, KS, 25 April ( html/librsry.html Public Folder/Meetings/Architect Meetings/Battle Management Language/ Symposium/Eagle Presentation). 21) 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 ( 22) SIMCI WWW Site, Army Overarching Integrated Product Team for Simulation to C4ISR Interoperability: ) 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, ) 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, ) 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, ) Weapon System Handbook, United States Army, ( public_docs/weapon_systems_handbook/) Author Biographies SCOTT CAREY, a senior researcher/writer and program manager for Northrop Grumman Information Technology, is a retired Army Lieutenant Colonel. 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, a program manager and senior researcher/writer for Northrop Grumman Information Technology, 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 Vice President for C4I Programs of the IITRI/AB Technologies Group. Dr. Hieb is currently an Architect for the Army SIMCI OIPT. He received his Ph.D. in Information Technology at George Mason University in 1996 and performed his doctoral research at the GMU Center for Excellence in C3I. Dr. Hieb received his MS degree in Engineering Management from George Washington University and his BS degree in Nuclear Engineering from the University of California in Santa Barbara. He has published over 45 papers in the areas of M&S integration with C4I and Machine Learning. Previously, he worked as a Nuclear Engineer for General Electric. RICHARD BROWN is a Senior Telecommunications Manager in the Army's Training and Doctrine Command's Integration Office for Battle Command Systems.. His current focus is on simulations and C3 systems interoperability. Over the last 25 years he has worked on tactical fire control systems, and integrated equipment and processes that form command posts. Mr. Brown is a 1967 graduate of the University of Massachusetts with a BS in Experimental Psychology. He retired from the US Army Reserve as a lieutenant colonel in 1997.