Spring Simulation Interoperability Workshop San Diego, CA, April 2005
Integrating Air and Ground Operations Within a Common Battle Management Language David Perme Gestalt, LLC 680 American Ave. - Suite 302 King of Prussia, PA 19406 (610) 768-0800
[email protected]
Andreas Tolk, Ph.D. VMASC Old Dominion University Norfolk, VA 23529 (757) 686-6203
[email protected]
William P. Sudnikovich Atlantic Consulting Services, Inc. 167 Avenue at the Common Shrewsbury, NJ 07702 (732) 460-9416
[email protected]
J. Mark Pullen, D.Sc. George Mason University Computer Science/C3I Center Fairfax, VA 22030 (703) 993-1538
[email protected]
Michael R. Hieb, Ph.D. Alion S &T 1901 N. Beauregard St. Alexandria, VA 22311-1705 (703) 933-3376
[email protected] Keywords: Battle Management Language (BML), Command and Control Information Exchange Data Model (C2IEDM), Command and Control Simulation Interface Language (CCSIL), Command, Control, Communications, Computers, Intelligence, Surveillance and Reconnaissance (C4ISR), Extensible Modeling and Simulation Framework (XMSF)
ABSTRACT: Battle Management Language (BML) is the unambiguous representation of all military Command and Control (C2) elements necessary to generate an executable plan of action – from actions to tasks, and from platforms to units. BML consists of three views: Doctrine, Representation, and Protocol. The Doctrine view describes the operational relevance of each C2 term, the Representation view enables the modeling of these C2 terms, and the Protocol view delivers an executable plan to the target system, which can be Command & Control systems, Simulation systems, or Robotic systems. The first prototype of BML was focused on the US Army ground operations, specifically the operations order (OPORD). However, none of the characteristics of BML cited above requires limiting BML to one service. Quite the opposite – from the beginning, other services and nations were part of the BML concepts. To support the United States Joint Forces Command (JFCOM), the BML team was tasked to prove the feasibility of multi-service operations within the common framework of BML. To this end, air operations were added to existing ground operations within BML using a common representation. An initial prototype was demonstrated at the Interservice/Industry Training, Simulation & Education Conference in December 2004 and is described in this paper. This paper summarizes the ongoing integration of air operations BML with ground operations BML and recommends how to approach future challenges that will occur when integrating other service or coalition requirements into a common methodological framework for BML.
05S-SIW-154
1
Spring Simulation Interoperability Workshop San Diego, CA, April 2005
1
Introduction
Battle Management Language (BML) transforms the communication of the commander’s intent from free text/prose to data. Besides contributing to the ongoing digitization of the battlefield, BML is a key concept for interoperability between Command and Control Systems and Simulations, which makes it interesting to the Simulation Interoperability Standards Organization (SISO) community. Each major simulation used today to represent military operational forces has a BML to task simulated units. Unfortunately, each of these is specific to its own simulation and often is driven by technical constraints of the simulation system and not by operational necessities of the warfighter. This paper examines the development of a common BML standard – using evidence from a recent Proof of Principle demonstration that integrated Air Operations and Ground Operations into a common BML. Taking the widest possible interpretation, BML is defined [2] as: The unambiguous language used to command and control forces and equipment conducting military operations and to provide for situational awareness and a shared, common operational picture. The objective of our BML work is to define an unambiguous language to describe the commander’s intent in a way that soldiers and systems can understand and make use of it. The resulting language should be applicable not only to simulation systems, but also to operational systems, command and control, and robotics. BML is based on the evaluating of earlier and alternative approaches, such as described in [3, 6] and [7], migrating appropriate concepts into new, open standard and webbased, joint and coalition environments, as envisioned by papers like [5, 12, 13, 15, 16] and described in more detail in the companion papers [4, 10] and [11]. 1.1 Many BMLs or One Common BML? BML will allow a commander to develop a plan and exchange data with other organizations – the commander’s subordinates, his superiors and his equals. From an operational viewpoint, there appears to be sufficient argument to define a separate vocabulary for each service. But when one looks at the operations mix that most of the services of the armed forces use, the service specific argument doesn’t stand. For example, the 05S-SIW-154
2
US Navy operates surface, sub-surface and airborne platforms, the US Army operates ground and airborne platforms, the US Air Force, airborne and space borne platforms. Thus, for example, if we were to define a Naval BML it would duplicate parts of the airborne BML of the Air Force and Army. The practical implications of this problem are significant: in some recent operations and exercises, air operations had to be limited to one of the services, as the orders and processes were not aligned sufficiently to allow efficient – or sometimes even safe – common joint operations. In addition to these operational constraints, software development and cost issues favor common development of the same solution for the same problem as well: defining a web services (including Extensible Markup Language (XML) schema and an associated Web Services Definition Language (WSDL) file) for each type of specific BML adds to the effort. For any system that would subscribe to more than one, a separate web service has to be built and maintained. Web services are indispensable in their function of providing a standardized, industry-supported method to integrate systems. The integration must be developed, the exchanging XML documents must be processed and in most cases translated. Additional services incur additional development and consequent maintenance. As pointed out in earlier papers, such as [14], XML only standardizes the syntax of information exchange. BML, however, targets semantic interoperability, i.e., the unambiguous definitions of terms and their meaning. It goes even further by communicating the use of these terms in dynamic systems (as doctrine is not static but dynamic), so the level of dynamic/pragmatic interoperability is targeted. The Who-What-When-Where-Why (5Ws) approach, developed with the initial Army focused BML effort [1, 2, 9], provided a first doctrinally correct and useful framework in which to describe a commanders’ intent as a proof of principle and feasibility. For the US Army Operations Order (OpOrd), it provided a hierarchically arranged formalized and machine processable document. Within the project described in this paper, we evaluated to what degree this effort can be reused for joint operations by applying the same principles to the US Air Force. In other words, we sought to determine whether the principal operations order structure used for the US Army, the 5Ws are applicable to US Air Force operations as well. Contrasting the information contained in the OpOrd to Air Force command orders, i.e., the Air Tasking Order (ATO), one finds that the ATO contains only some of the information that the OpOrd holds. The ATO contains the
Who, the What, most of the When, parts of the Where, and none of the Why. To complete an executable air mission order, additional documents are needed, specifically the Airspace Coordination Order (ACO), and the Special Instructions (SPINS) to fulfill the 5Ws construct. Concluding, we have found that the BML 5Ws construct appear to be a robust and sufficient framework in which to define an Air Operations capable BML vocabulary. We found that the challenge for BML to provide a common methodology, a common syntax and semantics, seems to be feasible. However, one issue that must be taken into account is the service unique characteristics (and, for SISO’s Coalition BML efforts, nationally unique characteristics). To become an adopted and successful means of communication, BML must be flexible enough to accommodate these differences. The objective of BML is not to equalize doctrines or orders; it is simply to map identical concepts to each other, so that the same things are recognized as the same things by the participating systems and services. The Air Battle Plan (ABP) produced by the US Marines must be understood by the US Air Force and US Navy and ultimately by US allies as well. 1.2 Roadmap to Remainder of Paper The remainder of this paper is organized as follows: Section 2 describes the development of Air Operations BML out of an existing Data Interchange Format. Section 3 describes how Air Operations BML was integrated with Ground Operations BML. Section 4 shows the Proof of Principle developed; and Section 5 concludes with an examination of a BML Framework.
2
Developing an Air Operations BML
The Extensible Battle Management Language (XBML) builds on the experience of the US Army proof of principle implementation by using Internet standards to develop web-enabled interfaces. Use of Internet standards is a tremendous aid to developing flexible interfaces (addressing BML methodology and syntax), but they do not address the issue of common semantics. In this phase of the project, we needed to incorporate the semantics of an air battle plan, which is analogous to the Army OPORD. It is the combination of the Air Tasking Order (ATO), the Air Coordination Order (ACO), and the Special Instructions (SPINS). For air operations, XBML uses an existing effort called Command and Control Information Exchange Data Interchange Format (C2DIF)
to establish a common representation for tasks, actions, and missions. C2DIF began development in 1998 as the centerpiece of a layered architecture for an Aerospace Operations Center (AOC) Simulation Interface. It was developed specifically to isolate the Air Simulation Interface (ASI) gateway from changes in the systems that it connected to and minimize the impact that those changes had on the gateway. The ASI has been in use from 1998 to present day for AOC training events. In the ASI, all incoming and outgoing communications are translated to and from the Command and Control Data Interface Format (C2DIF). C2DIF has undergone a continuous evolution and improvement since 1998. It has been used as the core for extension to the US Navy’s Joint Semi Automated Forces (JSAF) and Research, Evaluation, System Analysis (RESA) models, the US Air Force Air Warfare Simulation (AWSIM), and now defunct National Air and Space Model (NASM) and the Joint Simulation System (JSIMS). C2DIF was initially developed by sampling simulation systems and C2 systems for the data required that drove their air missions. The initial sample set was the Joint Theater Level Simulation (JTLS), AWSIM, RESA, the Joint Warfare System (JWARS), the Enhanced Naval Wargaming System (ENWGS), and the air component of the US Army, Corps Battle Simulation (CBS). The C2 systems polled in this process were the Contingency Air Theater Planning System (CTAPS), the Theater Battle Management Core System TBMCS and the Global Command and Control System (GCCS). The model was developed using spreadsheets and UML class diagrams. Following this analysis the design concentrated on the simplification of the class tree and the promotion of like attributes. As in the development of a responsive relational database schema, the process of designing an encoding such as C2DIF was part engineering, part experience, and part lore. The resulting structure was the result of face-to-face design meetings and testing scenarios. The overall structure is organized at the top level by message types, they are: 1) AirMissionPackage Message – Provides the relationship between air missions 2) AirMissionResults Message – Provides a normalized organization of data to provide mission feedback to C2 or simulations. 3) AirMission Message – Contains and organizes all of the mission level detail.
Event
0..1
1
dod.util::TimeParameters
CancelEvent -base : String -cancelType : -cancelledBy : String
EscortEvent -callsigns : ArrayList
SetMissionEvent
1 1
TimeEvent
ErrorEvent
-timeParameters : TimeParameters -tailChase : boolean
-missionType : String
CloseAirSupportEvent
AntiShipMissileDefenseEvent
-units : Vector
-shipName : String
LocationEvent
AirSpaceEvent
-airSpacePoint : AirSpacePoint
-startLocation : Location -endLocation : Location -airSpaceName : String -entryPointName : String -exitPointName : String -routeBehavior : -routeType : ShapeType -altitude : Distance -speed : Speed -route : AirSpaceShape -range : Distance -serialNumber : String -airSpaceUsage :
1 CancelType -id : String +ord : int -prev : CancelType -next : CancelType -upperBound : int -first : CancelType -last : CancelType +CANCEL_ALL : CancelType +CANCEL_GROUNDALERT : CancelType +CANCEL_MISSION : CancelType +CANCEL_TAKEOFF : CancelType
1 dod.c2dif.airspace::AirSpacePoint
1
1 AirSpaceUsageType -id : String +ord : int -prev : AirSpaceUsageType -next : AirSpaceUsageType -upperBound : int -first : AirSpaceUsageType -last : AirSpaceUsageType +ASSIGN : AirSpaceUsageType +DEASSIGN : AirSpaceUsageType +DEFINE : AirSpaceUsageType +UNDEFINE : AirSpaceUsageType
dod.c2dif.airspace::ShapeType 1
1 dod.c2dif.airspace::AirSpaceShape
0..1 1
1
1 RouteBehaviour -id : String +ord : int -prev : RouteBehaviour -next : RouteBehaviour -upperBound : int -first : RouteBehaviour -last : RouteBehaviour +BACK : RouteBehaviour +CONTINUOUS : RouteBehaviour +PROCEED : RouteBehaviour
Figure 1: An Air Operations Interchange Language In the AirMission Message, the missions are arranged by task units. A task unit can have a number of missions associated with it.
ancillary data that is typically not transmitted but normally coordinated beforehand, for example, Standards Conventional Load (SCL) data.
Each air mission is furthermore comprised of a series of events. The top-level events are CloseAirSupport, AntiShip, CancelEvent, LocationEvent and an ErrorEvent. From this level, the location event structure provides the bulk of the data concerning the mission. Its subtree is depicted in Figure 1. The main portion of this sub-structure is based on one of the revelations that the design team experienced during the C2DIF development was that an air mission can be most simply described as a series of events which occur at specific locations and times. Thus the specific mission sub-tree specializes primarily from the location event class. A full depiction of the C2DIF includes the airspace data located in the ACO, the Rules of Engagement located in the SPINS and
C2DIF has been vetted and updated since 1998; its selection for the Air Operations BML was based on that legacy and credibility. It has survived numerous changes to the USMTF baseline, and AOC C2 Systems as well as the simulations that are supported. Object oriented class analysis and design, combined with the initial and ongoing sample sets, has solidified the approach. For the BML project, the task was to begin with the C2DIF, map that into the 5Ws of the BML effort, and then demonstrate that functionality at both Interservice/Industry Training, Simulation and Education Conference (I/ITSEC) 2004 and in a Virtual Flag event.
3
Integrating Air Operations BML into Ground Operations BML
Transforming the Army XBML prototype described in [5] to a Joint, Combined Extensible Modeling and Simulation Framework (XMSF) BML prototype is conducted in phases. As the XMSF project looked at BML, it was fairly straightforward to determine which XMSF standards would be applied first, in order to “open up” the interfaces. In this section, we summarize the results of Phase I as described in [5] and describe the initial progress of Phase II of the XBML project. 3.1 BML in the XMSF environment The following sections deal with the migration of BML to the XMSF environment to ensure that BML is embedded into a commercially viable and commercially supported IT infrastructure (technical level) and that the Army prototype can by semantically extended to be applied for other services and nations (semantic level).
Internet. All of the nodes accessed one database (the Multi Source Database – MSDB) located at the XMSF booth at I/ITSEC. A Web-based whiteboard/conferencing application was included. The implementation of XML and SOAP in accordance with XMSF principles among the components of the BML demonstration environment allowed seamless, distributed and remote execution of each of the components. The demonstrations conducted during I/ITSEC laid the groundwork for extending the XMSF concepts to meet the challenges of future tactical Command and Control requirements. 3.2 AO XBML –I/ITSEC 2004 Demonstration The I/ITSEC XBML Demonstration comprised the following elements as shown in Figure 2: •
•
The first phase of XBML investigated approaches to incorporate open, Web-based methods for implementing the interfaces to conform to the principles of XMSF. The two Web-based standards used to implement the Web service interfaces to construct the XBML prototype were XML and the Simple Object Access Protocol (SOAP). XML was used to provide a standard way to structure the data passed between the components. SOAP provided the interfaces for the C2IEDM, ASI, and CAPES. SOAP is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. A SOAP message has three parts. The first of these is called the envelope and is used to describe the basics of the SOAP message such as the content and how to process the message. The second part consists of the rules about custom data types. The ability to create custom data types, a feature also of XML, is an important characteristic of SOAP lending to its ability to support extensibility. The last part describes the application of the envelope and the data encoding rules for representing the Remote Procedure Call (RPC) calls and responses, including the use of Hypertext Transport Protocol (HTTP) as the underlying transport. The results of Phase 1 were demonstrated at the I/ITSEC 2003 and documented in [5]. The demonstration configuration had 3 nodes, two at I/ITSEC at the Orlando Conference Center and one node at George Mason University (GMU) in Fairfax Virginia. The nodes at I/ITSEC were physically on the I/ITSEC network and communicated to the GMU node through the commercial
•
•
•
To generate ground orders, the Combined Arms Planning and Execution System (CAPES) was used. This is a prototype US Army Planning System. This C4ISR component creates OpOrds that are exchanged using a XML tagged document The Command and Control Information Exchange Data Model (C2IEDM). The C2IEDM is a product of the analysis of a wide spectrum of allied information exchange requirements. It models the information that combined joint component commanders need to exchange. It is a configuration controlled model that has the support of 27 Nations. The C2IEDM presents a real and robust approach that allows C2 systems to interoperate as well as managing the information exchange requirements for NATO operations, including civil-military coordination, war against terrorism, and other recently added requirements. Several US DoD programs are following its development and incorporating it into their systems engineering plans. The AOC Simulation Interface (ASI) – ASI is the system that contains the C2DIF, it provides a twoway transformation gateway between the AOC and simulations. It is used in exercises, demonstrations, tests, and evaluations of TBMCS and AOC training exercises. ASI provided the Air Operations XBML document used in the demonstration. The Theater Battle Management Core System (TBMCS) – This is the US Air Force’s and US Navy’s primary air planning and execution system. It generates the Air Battle Plan which consists of the ATO, ACO, and SPINS. The M&S component the Joint Semi-Automated Forces (JSAF) system is used to simulate the effect of the generated orders. It reads the generated orders and executes them respectively.
1
M1
M2
CAPES
TBMCS
CAPES XML ADAPTER
Mission Planner Workstation
2 ASI/IMCN
XBML
XBML HTTP XBML
XBML
3
XBML Web Service
4
JSAF Adpater JSAF
C2IEDM M4 M3
Figure 2: XBML Proof of Principle Integrating Air and Ground Operations The flow of the demonstration was: 1. The ground OPORD is released from CAPES as an XML Document describing the ground operations in XBML. 2. The ground OPORD is processed into C2IEDM. 3. The ABP is released from TBMCS – The ABP includes the ATO, ACO and SPINs. 4. ASI/IMCN processes the ABP (ATO, ACO and SPINS), and produces the air operations in XBML. 5. The Mission Planner Workstation (MPW) is a subsystem of ASI. It is used to add to the ABP (detailed flight planning) when the intelligent agent system, the Intelligent Mission Controller Node (IMCN) is not available. 6. The XBML describing the air operations is released and processed into C2IEDM. 7. The XBML describing the air operations is received and processed into the C2IEDM via the web service. 8. The C2IEDM Server releases the joint air and ground operations merged into one XBML document to JSAF. There, they are mapped to the doctrinally correct task identifiers to the
9.
appropriate task from instantiations in the simulation. JSAF receives the XBML and executes the ground and air battle orders.
The demonstration was presented in two booths, the Virginia Modeling and Simulation Center (VMASC) booth and at the Defense Modeling and Simulation Office (DMSO) booth. The demonstrations were well received and provided on each day of the I/ITSEC meeting. This demonstration will go forward, modified with the full AO XBML definition to Virtual Flag in July of 2005. 3.3 XBML Air and Ground Proof of Principle (PoP) The first phase of XBML was relatively straightforward, and set the stage for the following stages, which increasing focus on the semantic aspects of developing an extensible BML. Work performed in Phase 2 mapped the MSDB BML tables to the NATO Standard C2 Data Model – the C2IEDM. Phase 2 moves the basis of the MSDB to the C2IEDM. This takes the PoP from an Army basis to a Joint/Coalition basis, in keeping with the XBML project goals. Along with this comes a standard XBML XML tagset based on the C2IEDM. The Testbed will still be
using Army data, but it will demonstrate the applicability of the C2IEDM to handle “simulation” data (in the form of executable missions, tasks and actions). Phase 3 of XBML, also currently underway, incorporates additional simulations and C4ISR systems. This is essential to prove the extensibility of XBML. This will also address how BML is used in both a Joint and Service concept, as the initial OPORD will be Joint, not Army. The persistent C2IEDM-complient database will be populated with a slice of Joint tasks (based upon the Universal Joint Task List), as well as the Army tasks. The result of Phase 3 will be a testbed that other organizations can “plug” into on a component basis to test C4ISR to Simulation interoperability concepts. Phase 3 will also test the ability of BML to represent a graphical OPORD. Initial applications implementing the BML will be text based, but linked to graphics. For example, a BML application of the operations order would probably look very much like the current five paragraph operations order, however with much more structure applied to the five paragraphs. The structure orients on the 5Ws 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 Course of Action (COA) sketch and statement, and the associated synchronization matrix, and drop-down menus based on the relationship of unit type and echelon to operations, missions and tasks.
4
BML Development Options
The current integration work has highlighted several different possible development approaches for BML. Below, we describe the different options and in Section 5 we describe what we see as the way ahead. 4.1
Service Specific BMLs
This approach involves creating specific BML and XML vocabularies fro each military Service. Each Service would define its own BML and XML vocabularies for command. In effect, this is the situation that exists with the current XBML effort. The current XBML is applicable most appropriately to the US Army. It has done a credible job in detailing the OPORD in an unambiguous manner and allowing for a hierarchical representation. However, when the Air Operations was applied to it, the fit was not that good. Continuing down this path will result in many separate XML vocabularies that reside under the banner of XBML but are in fact, not interoperable. Any systems that needed to process the
XBML would have to build a separate Web service for each XBML dialect. This would greatly increase the maintenance effort for each system as well as serve to fragment the offerings, creating barriers to adoption. The advantage of this approach is that each Web service would potentially have been more responsive to the domain represented by the military Services. However, the military Services would not achieve any level of interoperability unless all of their candidate systems for that exchange (as identified in the Department of Defense Architecture Framework (DODAF) Operational Views) were implemented each Web service. Even then, software would be needed to process and present the incoming XML, and to provide the overlay to depict common timelines, geography, environment, etc. 4.2
Joint Common BML
Under this approach, a common BML and XML Schema would be developed to be used across commands and environments with extensions where needed. This is similar to the approach in the C2IEDM, in which there are generic hub concepts and special function areas. For example, the type of sonar buoy pattern to employ would be specific to an ASW (Anti-Submarine Warfare) function, but air operations would be described in a generic way usable by the aviation elements of each military Service. The goal is to create an abstraction that will allow as many tasks as possible to be completely described and remain usable to as broad an audience as possible. Taking our sonar buoy pattern as an example again, the patterns that the US Navy uses is probably not unlike patterns used by the United Kingdoms Royal Navy. Thus creating a Service specific extension would not be in keeping with the idiom of attaining an extensible and simple representation. To what extent the similarity between services and their understanding of doctrine will influence the encapsulating of data into this hub has not yet been evaluated. It is possible, however, that the degree of commonality between UK and US land forces may exceed the degree of common data between Air force and land forces. While it might be attractive for each military Service to have its own BML and thus avoid having to coordinate additions/changes, this approach would give up one of the principal benefits of Joint BML: the ability to coordinate across Service elements. 4.3
Native C2IEDM
Another approach would be to use the C2IEDM schema natively for BML and the associated XML messages. This means that the 5Ws would be replaced by standardized data elements described in the C2IEDM. Other papers, in particular [4] and [17], show the possible
mappings. The advantages are that there is a great deal of coordination that has already occurred in developing the C2IEDM and there is an active configuration control process in place. Also the DOD, especially the US Army, is very active and is contemplating adopting the model. The use of C2IEDM data elements must be accompanied by the extension and enhancement of the model based on the principles of data engineering as described in earlier papers, insures semantic interoperability, including the already reached consensus among the 27 nations supporting C2IEDM. A disadvantage of using the native C2IEDM data model is that current implementations are utilizing relational databases which exchange data using a database replication mechanism. This form of data interoperability adds technical constraints and a somewhat inflexible data protocol. More importantly, C2IEDM provides an abstracted view of C2 data that comprises entities, actions and relations. It is an elegant but difficult model to understand and thus demands a high degree of skill to use. This means that manipulating C2IEDM is not an easily transferable skill. The approach selected by our team so far is to define easier to understand constructs using the 5Ws approach, as these constructs can be directly mapped to the language used by the warfighter und are understood more easily by the engineers. However, by mapping these elements to the standardized elements of the C2IEDM, we avoid the danger of setting up a new language independent of already accomplished agreements. Our approach is summarized in the next section. Additional information of the applicability of C2IEDM and its constraints can be found in [14, 18, 19] and [20].
5
Toward a BML Methodology
Several aligned XBML projects have grappled with the issue of how best to represent the command and control (C2) information needed for interoperation among C4I, simulation, and robotic systems of the various US military Services: Army, Navy, Marines, and Air Force. In addition, the international perspective should be taken into account as well, as joint operations are more than likely to occur within a coalition and not as US-only operations. We have concluded that three distinct layers of representation are needed: •
A single overarching BML construct that integrates the requirements of all military Services is required. While it might be attractive for each Service to have its own BML and thus avoid having to coordinate additions/changes, this approach would give up one of the principal benefits of Joint BML: the ability to
coordinate across Service elements. We recognize that major aspects of the Joint BML will be defined to fit the needs of the individual Services, following for example the 5-Paragraph OpOrd for the Army and the Air Tasking Order and associated documents for the Air Force. However, to achieve the benefits obtainable from BML in the future, the coordinated joint aspects are essential. •
The military Services will have Service specific BML dialects capturing their service specific extensions of the overarching BML construct. Similar to the ideas captured in the C2IEDM, there will be hub concepts and special function areas that are only of interest to one Service. It is likely that another hub level will be introduced for international coalitions. To what extend the similarity between Services and their understanding of doctrine will influence the encapsulating of data into this hub has not yet been evaluated.
•
The required C2 information will need to have multiple interpretations because it has multiple uses that cannot work effectively with a single view. While the mapping to the C2IEDM ensures that things are named and identified unambiguously (semantic interoperability), their interpretation may differ for the participating domains. The same semantic object has different value and ultimately meaning in the dynamic use of participating systems. In other words, we need a construct to cope with the dynamic/ pragmatic side of interoperability, which means we need an ontology for system organization in addition to the universal system interface data model, and an unambiguous human and software interface to communicate orders and their results among a wide variety of automated systems, potentially including allied/coalition systems. The different views introduced to cope with the different challenges of BML (doctrine, representation, and protocol) have been proven to make sense and should be supported in the future as well.
The major focus of BML work to date has been the unambiguous human and software interface. Thus the current XBML prototype is most complete in the area of specifying the 5Ws for the Army in a format that is readily understandable by humans but unambiguous for machine understanding, and has begun to achieve a comparable level of specificity for Air Force operations. Any BML standard must support this aspect in order to achieve the basic purpose of BML. Ultimately this capability must be expanded to cover the entire range of military activities that need to be represented across C4I, simulation, and robotic systems while remaining useful to the warfighter.
Although the information represented in BML is fundamental to C4I-Simulation interoperation, an even more detailed system interface data model is required as a means of crisply specifying battlefield objects and their activities at the very detailed level, not intended for the warfighter, but needed for the general case of universal data interchange among C4I systems and simulations. Every element of the BML must be mapped to such a data model in order to exchange the information required for system interoperation in the general case. The evident candidate for this representation is the C2IEDM that has been adopted by NATO and is under serious consideration for adoption by the US. Selection of the underlying interchange data model for BML should be deferred until this decision is made; however, it is critical to recognize that effective BML interoperability will require a level of detail that is obtainable only from such a data model [14]. The current XBML prototype employs the C2IEDM in this role. The question of representing the ontology associated with BML does not yet have a single firm answer. While there is a clear need to capture the internal relationships among the objects and activities represented in BML, this information currently exists only as knowledge in the minds of the human designers. Selecting a better way to capture the information is an important goal, but it need not hold up progress in defining BML. See companion paper [10] for a discussion of possible future directions. In summary, an important finding of the XBML project is that C2 information must be represented at three levels, with each level capable of being mapped into the next level down: •
The C2 ontology, which at present takes the form of human knowledge, but in the future is likely to be formalized in a standardized fashion. There is still much work to be done in this area
•
The unambiguous human and software interface provided by BML itself, used wherever it is necessary to communicate with the warfighter. This is the current focus of the SISO working group.
•
The system interface data model, used for universal communication across system boundaries, for which the most evident candidate is the C2IEDM.
The role of SISO and its study and product development groups seems to be obvious: we need standards in all fields mentioned in this paper; some are easy to accomplish, others will require some years of research work. Groups mentioned in the acknowledgments, plus graduate students at the participating universities, established the basis for the definition of the 5Ws for the US Army. It is likely that a similar effort will be needed
for the other military Services as well. The field of ontologies is still in its infancy concerning the applicability for BML. However, the work conducted so far shows that these problems are solvable in principle and SISO can be the umbrella organization for joint and combined standardization efforts in these domains.
6. Acknowledgements The authors gratefully acknowledge and support from JFCOM for Air Operations BML and DMSO for the development of XMSF and XBML. BML was originally sponsored by the US Army Simulation to C4I Interoperability Overarching Integrated Product Team (SIMCI OIPT) [10]. The XBML work is based upon a foundation of work done by the US Army and performed by LTC Ken Wilson, Martin Kleiner, Scott Carey, and Richard Brown.
7. References [1] Carey, S., Kleiner, M., Hieb, M.R. and Brown, R., “Standardizing Battle Management Language – Facilitating Coalition Interoperability”, Paper 02ESIW-005, 2002 European Simulation Interoperability Workshop, London, England, 2002. [2] Carey, S., Kleiner, M., Hieb, M.R. and Brown, R., “Standardizing Battle Management Language –A Vital Move Towards the Army Transformation”, Paper 01F-SIW-067, Fall Simulation Interoperability Workshop, 2001. [3] CCSIL Message Content Definitions, http://ms.ie.org/cfor/cfor.html/Documentation. [4] DeMasi, L., Dobbs, V.S., Ritchie, A. and Sudnikovich, W.P., “Implementing Battle Management Language: A Case Study Using the Command and Control Information Exchange Data Model and C4I-M&S Reference Object Model”, Paper 05S-SIW-068, Spring Simulation Interoperability Workshop, 2005. [5] Hieb, M.R., Sudnikovich, W., Tolk, A., and Pullen, J.M., “Developing Battle Management Language into a Web Service”, 04S-SIW-113, 2004 Spring Simulation Interoperability Workshop, Crystal City, VA, 2004. [6] 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.
[7] Salisbury, M., “Command and Control Simulation Interface Language (CCSIL): Status Update” MITRE Informal Report, Twelfth Workshop on Standards for the Interoperability of Defense Simulations, 1995 (http://ms.ie.org/cfor/diswg9503/diswg9503.pdf) [8] SIMCI WWW Site, US Army Simulation to C4I Interoperability Overarching Integrated Product Team: http://www.simci.org, 2004. [9] Sudnikovich, W., Hieb, M.R., Kleiner, M. and Brown, R., “Developing the Army's Battle Management Language Prototype Environment”, Paper 04S-SIW-115, 2004 Spring Simulation Interoperability Workshop, Crystal City, VA, 2004. [10] Tolk, A., and Blais, C., “Taxonomies, Ontologies, and Battle Management Languages – Recommendations for the Coalition BML Study Group,” Paper 05S-SIW-007, Spring Simulation Interoperability Workshop 2005. [11] Tolk, A., Diallo, S., Dupigny, K., Sun, B. and Turnitsa, C., “Web Services based on the C2IEDM – Data Mediation and Data Storage,” Paper 05S-SIW019, Spring Simulation Interoperability Workshop 2005. [12] Tolk, A., Hieb, M.R., Galvin, K., Khimeche, L., “Coalition Battle Management Language,” Paper 04F-SIW-103, Fall Simulation Interoperability Workshop 2004, Orlando, FL, 2004. [13] Tolk, A., Hieb, M.R., Galvin, K., Khimeche, L.,: “Merging National Battle Management Language Initiatives for NATO Projects,” Paper 12 in Proceedings of the RTA/MSG Conference on “M&S to address NATO’s new and existing Military Requirements”, RTO-MP-123, Koblenz, Germany, October 2004. [14] Tolk, A. and Muguira, J., “The Levels of Conceptual Interoperability Model”, Paper 03F-SIW-007, 2003 Fall Simulation Interoperability Workshop, 2003. [15] Tolk, A. and Daly, J., “Modeling and Simulation Integration with Network-Centric Command and Control Architectures”, Paper 03F-SIW-121, 2003 Fall Simulation Interoperability Workshop, 2003. [16] Tolk, A. and Pullen, M., “Ideas for a Common Framework for Military M&S and C3I Systems”, Paper 03E-SIW-032, 2003 Euro Simulation Interoperability Workshop, 2003. [17] Turnitsa, C., Kovurri, S., Tolk, A., DeMasi, L., Dobbs, V., Sudnikovich, W., “Lessons Learned from C2IEDM Mappings Within XBML,” 04F-SIW-111,
2004 Fall Simulation Interoperability Workshop, 2004. [18] Wartik, S.P., Haugh, B.H., Loaiza, F. and Hieb, M.R. 2001 “A Methodology for Comparing C4I Data Models and Simulation Object Models”, Paper 01E-SIW-059, 2001 Euro Simulation Interoperability Workshop, London, UK, June 2001. [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] Zimmermann, B., “Integrated Army Modelling and Simulation Data Network”, MSG-022/SY-003/25 Conference on “C3I and M&S Interoperability”, Antalya, Turkey, October 2003 (published in RTOMP-123).
Author Biographies DAVID PERME is a Managing Director and partner at Gestalt LLC. Mr. Perme has been active in the simulation to simulation interoperability environment since 1991 when he was the lead engineer for the Air Warfare Simulation ALSP translator. He then worked C4I to simulation interfaces using DIS, HLA and other protocols. Mr. Perme is the designer for ASI, and has been active in the interoperability field for over 15years. He has published several papers for SISO and currently serves on the SAC committee as an appointed member. Mr Perme has MSCS from Boston University and was a fighter pilot in the US Air Force for 10 years. ANDREAS TOLK is Senior Research Scientist at the Virginia Modeling Analysis and Simulation Center (VMASC) of the Old Dominion University (ODU) of Norfolk, Virginia. He has over 15 years of international experience in the field of Applied Military Operations Research and Modeling and Simulation of and for Command and Control Systems. In addition to his research work, he gives lectures in the Modeling and Simulation program of ODU. His domain of expertise is the integration of M&S functionality into related application domains, such as C4ISR or web-based services, in particular based on open standards. WILLIAM P. SUDNIKOVICH is a Project Manager for Atlantic Consulting Services in Shrewsbury, NJ and a technical architect for the Army’s SIMCI OIPT. Prior to joining ACS in 2000, Mr. Sudnikovich held various technical and management positions with the US Army CECOM RDEC and was influential in establishing M&S activities there. He was an active contributor to the
development of the IEEE 1278 DIS standards and is a former Chairperson of the C4I Forum of the SISO Simulation Interoperability Workshops. Mr. Sudnikovich holds BS and MS degrees in Computer Science from Rutgers University and Fairleigh Dickinson University. J. MARK PULLEN is Professor of Computer Science at George Mason University, where he heads the Networking and Simulation Laboratory in the C3I Center. He holds BSEE and MSEE degrees from West Virginia University, and the Doctor of Science in Computer Science from the George Washington University. He is a licensed Professional Engineer, Fellow of the IEEE, and Fellow of the ACM. Dr. Pullen has been a leader in XMSF and heads the XBML project. He also teaches courses in computer networking and has active research in networking for distributed virtual simulation and networked multimedia tools for distance education. MICHAEL HIEB is a Vice President for C4I Programs for Alion Science and Technology. 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 extensively in the areas of M&S integration with C4I and Battle Management Language. Previously, he worked as a Nuclear Engineer for General Electric.
