amongst other projects related to the XMSF. (Extensible Modeling and Simulation Framework) initiative. ANDREAS TOLK is Senior Research Scientist at.
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004
Lessons Learned from C2IEDM Mappings within XBML Charles Turnitsa Sai Kovurri Dr. Andreas Tolk Virginia Modeling Analysis & Simulation Center Old Dominion University Norfolk, VA 23529 [cturnits; skovv001; atolk]@odu.edu
Liam DeMasi Dr. Verlynda Dobbs William P. Sudnikovich Atlantic Consulting Services, Inc 167 Avenue at the Commons, Suite 4 Shrewsbury, NJ 07702 [ldemasi; vdobbs, wsudnikovich]@acsinc-nj.com
Keywords: Battle Management Language (BML), Command and Control Information Exchange Data Model (C2IEDM), Data Modeling, Interoperability, Extensible BML (XBML) ABSTRACT: The Command and Control Information Exchange Data Model (C2IEDM) is a mature data model that has been developed over the past two decades by NATO experts based on information exchange request for command and control. It has been internationally standardized in the allied data publications and has been agreed to as a common model to facilitate data interchange at all tactical levels by technical and military experts of NATO. From the data modeling standpoint, the C2IEDM is an extensible data model that has the potential to become the common reference model for both future and existing Modeling and Simulation, and C4I systems. This perception reflects the evaluation of experts in this field, who recently met to discuss this issue. However, to support the interoperability of existing systems with the C2IEDM, there exists a need to map the data models of those existing systems to C2IEDM. This paper describes a process for sculpting a mapping from one data model to another data model, the target data model being the C2IEDM. The process is then applied to a real world problem, mapping the data from the US Army prototype of the Battle Management Language to the data model (C2IEDM) identified for use by the Extensible BML (XBML) project. This paper contains descriptions of BML, C2IEDM, the methodology and techniques of the mapping process, the application of the mapping process, lessons learned, and recommendations for future efforts. data domain is a pure engineering task, practically a lot of intellectual effort is necessary to ensure that the well-known conflict categories are handled appropriately. Automated translation will be limited to trivial problems, like addresses and merchandise order forms. Complex tasks, such as data descriptions of military operations, have to be supported manually. However, as pointed out in [1], if done correctly, data management and data mapping can be used to generate data mediation services for later automatic use [2]. This paper summarizes the lessons learned of such a data mapping activity.
1. Introduction The mapping of one data model to another is a process that requires a great deal of understanding of the models in question, as well as a methodical approach to the problem. The general problems have been dealt with in detail in previous presentations on data administration, data management, data alignment, and data translation. The findings of selected Simulation Interoperability Standards Organization (SISO) and North Atlantic Treaty Organization (NATO) efforts in this domain of data engineering are summarized in [1].
Since the target data model is a promising candidate for data modeling within the Global Information Grid and many projects are recommending and some even mandating its use, the experiences described in this paper may be of general value. The data model is the
Although theoretically the mapping of one data model to another data model coping with the same
04F-SIW-111
1
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 C2IEDM, also known as Generic Hub or the ATCCIS data model.
Another principle is the use of operational data models. The initial prototype used the Multi-Source Database (MSDB), a modified version of the Joint Common Database (JCDB), to prove the feasibility of using operational tactical data models as a core for BML modeling and representation. The effort to migrate BML from the U.S. Army domain into the joint and combined environment is focused on the use of international standards for the representation view. This paper describes the initial steps for the migration of an MSDB-based BML representation to a C2IEDM-based representation.
Before discussing our approach and findings, we will lay the groundwork by defining the models plus a brief discussion of the purpose of this research. 1.1 Description of BML and C2IEDM The work discussed is embedded into the Battle Management Language (BML) efforts [3]. BML is the unambiguous language used to command and control forces and equipment conducting military operations and provide for situational awareness and a shared, common operational picture. BML is being developed as a standard representation of a "digitized commander's intent" to be used for real troops, for simulated troops, and for future robotic forces. Three views are necessary to describe BML: •
A Doctrine View – BML must be aligned to doctrine;
•
A Representation View – BML must model these aspects in a way that can be interpreted and processed by the underlying heterogeneous information technology systems of the coalition;
•
A Protocol View – BML must specify the underlying protocols for transferring BML information between the participating systems.
The C2IEDM is a robust data model. Part of its strength lies in the fact that inherent to its design is the trait of extensibility. The C2IEDM is designed to be extensible in any direction that is necessary, and the employment of such an extension is fairly well documented. The C2IEDM is a data model with two decades of development history, and is maintained by the Multilateral Interoperability Program (MIP). This is a voluntary and independent organization that represents more than two dozen countries and headquarters organizations. MIP is concerned with deriving a common data architecture and data model for multi-national interoperability. What is even more important than its technical maturity is the fact that C2IEDM is derived through consensus and has active configuration management. It is a coherent, highly normalized data model, which leverages object type and subtype hierarchy structures to simplify the complexity. Its applicability to Command and Control (C2) as well as to Modeling and Simulation (M&S) issues has been documented. The C2IEDM is much more than just “another data model” for tactical data exchange and storage. The C2IEDM is comprised of common vocabulary consisting of 176 information categories that include over 1500 content elements related to all domains of military operations, such as maneuver, fire support, air defense, engineering, civil military operations, and anti terror special operations. All data and relationships are well documented and publicly available. However, the most important point is that all participating MIP nations agreed that the information exchange captured in C2IEDM is operationally relevant and sufficient for allied operations. In other words, military and technical experts from ten full member nations (Canada, Denmark, France, Germany, Italy, The Netherlands, Norway, Spain, The United Kingdom, and The United States) as well as 14 associate member nations agreed that C2IEDM is an adequate and operationally meaningful way to exchange information about military operations.
Together, the views enable complete and unambiguous representation and machine understandable communication of a commander’s intent. The general idea is to use BML as the common denominator for Command and Control data exchange. While the U.S. Army developed the prototype, the U.S. Joint Forces Command (J7/Training Directorate and J9/Experimentation Directorate) supports actual applications for joint applications. Furthermore, a SISO study group is evaluating the applicability of BML for coalition operations in the international domain. In summary, there are a number of areas of research and development designed to extend BML into new areas of use, and expose it to new audiences. From the beginning of BML it was determined that BML must be rooted in doctrine. Every term of BML must have a definition in a doctrine document, such as a field manual or a keystone/capstone document of NATO, the Joint Staff, or the Services. This principle is thoroughly applied to all BML prototypes developed under participation of the Simulation to C4I Interoperability (SIMCI) program of the U.S. Army, including the prototypes developed for the U.S. Joint Forces.
04F-SIW-111
2
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 an operation. This plan is stored in the MSDB, US Army BML Proof of Principle which is an extended BML GUI version of the JCDB with over 100 additional tables to cope with BML information exchange request. The BML Graphical User Interface (GUI) reads the plan and displays the elements following Simulation XML – BML Initialization Parser for the structure of the Multi-Source Database Operational Data Data well-know 5Ws of Based on JCDB Army Command and OneSAF Testbed Control: Who is doing What, Where, When, and Why? Terms and connections are checked for consistency with Combined standing doctrine. This Arms Planning & doesn’t limit the Execution Commander; he can act System against doctrine, he just will be made aware of it Figure 1. Components of the U.S. Army BML Prototype by BML. The plan is transmitted to the MSDB and transferred Finally, the BML results, which are executable to the One SAF Testbed to be executed by the mission plans in the form of tasks that have to be simulated forces. The plan can be sent back to aligned and orchestrated, must be communicated, i.e., CAPES as well to be the basis for ongoing future must be brought to the recipient. plans or sent to real troops to be carried out. This paper focuses on the transformation of the BML Concerning the data, the MSDB is the central piece; representation from MSDB to C2IEDM. it contains all the verbs, nouns, adjectives, adverbs and concepts of BML. Atlantic Consulting Services, Inc and Northrop Grumman developed the initial version of MSDB [5]. The MSDB employs BML data elements and BML concepts. In order to cope with all information exchange requirements, 113 tables were added to the JCDB. This MSDB is the source of the data that must be stored within C2IEDM. The target data model, in this case the C2IEDM, must be able to convey the same information, in an unambiguous manner, as it is conveyed today with the MSDB.
1.2 Components of the BML Prototype As previously stated, BML is defined in [3] as an unambiguous language that is used to Command and Control forces and equipment conducting military operations, and provide for situational awareness and a shared, common operational picture. To this end, BML results in executable descriptions of missions. These missions can be executed by “forces and equipment conducting military operations,” which includes the warfighter, simulated forces, and robotic forces. BML therefore targets interoperability between C2 systems, in particular planning systems, and other C2 systems, simulations systems, and robotic forces.
As stated before, C2IEDM was designed based on the information exchange requirements that exist on the battlefield and that have to be exchanged between C2 systems. It therefore deals naturally with orders, missions, tasks, situational awareness data, etc. C2IEDM explicitly copes with four different aspects of the battle space [4], namely:
The U.S. Army BML prototype is comprised of four components. The Combined Arms Planning & Execution System (CAPES) is part of the Future Combat System (FCS) initiative of the U.S. Army and is a Command and Control planning support system. CAPES is used to create the initial plan for 04F-SIW-111
−
3
Objects of interest and their inherent properties
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 − − −
Past, present, or future situations as represented by facts about the objects Past, present, or future activities that involve the objects Containers for grouping data into information packages.
•
The Top-Down approach starts with the associated concepts (meaningful subsets) and maps them to each other. Next, the tables are mapped and finally missing properties identified. The advantage is that common knowledge and structure of the mapping domain is used to reduce the complexity by dividing the mapping problem into subsequent classes. The disadvantage is that the associated concepts and propertied concepts can differ significantly.
•
The Bottom-Up approach starts with the mapping of the properties. This means starting with the smallest common denominator. How these properties are structured into propertied concepts and associated concepts doesn’t matter in the first step. Only in the second step, when the properties have to be tied together for obtainability in the applications, the propertied concept descriptions may have to be completed and associated respectively.
In the next section, the proposed methods for mapping a data model to the C2IEDM are described.
2. Methodology A methodical approach is required for doing any sort of data modeling or data sculpting. The steps of the proposed methodology are described below. 2.1 Top-Down versus Bottom-Up Data Mapping The general idea of properties, propertied concepts, and associated concepts [2] can be applied to cope more generally with the tasks required for data mapping. •
Property values are the allowed values for a specifying characteristic. Of particular interest are enumerations. Within relational databases, these are enumeration values for attributes.
•
Propertied concepts are a collection of specifying characteristics for an entity in the domain of knowledge. In ontologies using data models to structure its information, this can be mapped to tables and their attributes. Within relational databases, these are tables.
•
The team had several substantial discussions with subject matter experts on pros and cons of both views. In the end, we agreed to use the top-down approach for mapping and applying a bottom-up consistency check in the end. As the MSDB and C2IEDM structures are sufficiently similar, the disadvantage of potential mismappings on high levels diminished in the light of the reduced complexity of the mapping process. When devising this mapping between two distinctly different data models, there is a need to approach the process in a methodical manner composed of three main steps – each having increasingly finer scope of detail. It should be mentioned at this point that this process describes the mapping from one source model to one target model – if the process is to be symmetrical, then the work done at each step past the first is nearly doubled. The three steps are the Conceptual, the Logical, and finally, the Physical steps of the mapping process. A preliminary activity required before these steps, of course, is to gain understanding of the two different data models.
Associated concepts are semantic entities in which data is given in a broader context. Within data models, these are the views or replication domain sets.
Generally, when describing tasks, several tables are needed, associating the propertied concept describing the 5Ws with the task. Two applications are likely to have different views on what information is needed to describe a task. The same is true when looking at the tables to structure the basic information, the propertied concepts. A fighter aircraft described by army systems is likely to have other properties than the same fighter described by an air force system. Both views are valid, but it is hard to map them to each other.
2.2 Conceptual mapping The first step of mapping is a need to compare the two data models, at the very highest, or conceptual, level. A comparison at this level is done by thinking of the main features (those that underlie the basic design). Considering these features, and then trying to draw paths between respective features that are similar in scope and character. This is the conceptual step of data model mapping. A mission or a complex task is in the scope of this level. In [2], these concepts are generally referred to as associated
When working on the method to be applied in the XBML task to map MSDB to the C2IEDM, this problem had to be addressed. Generally, two ways are possible:
04F-SIW-111
4
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 concepts. They are generally application focused, i.e., the structure of the information is addressed in the best way to support the information process in the application.
3. Concepts and Relationships This approach to data modeling is built on an understanding of the concepts and relationships inherent in the distinct models, and here we discuss those conceptual definitions, and also the relationship from the source of the MSDB embedded with BML concepts to the target of BML concepts being embedded into the C2IEDM.
2.3 Logical mapping The second step is to map the necessary elements of the respective conceptual areas of the source data model, and to show how these will provide all that is necessary within the paired conceptual areas of the target data model. Note that a danger exists at this step in that there might not be the necessary data provided within the source data model to satisfy required areas of the target data model, a problem addressed by data alignment. In such a case, external provision of the data might be necessary. If this is not feasible, then the mapping process might not be possible. If it is possible, then at best the target data model will be an incomplete model. This is the logical step of data model mapping. Logical mapping deals mainly, but not exclusively, with the information available in the concepts, thus mainly dealing with tables, attributes, and enumerations, which are referred to as properties and propertied concepts in [2].
3.1 Conceptual definitions: BML BML as it is currently employed within the MSDB has some 22 different conceptual areas. These include: − − − − − − −
These different conceptual areas allow BML to, as per it’s stated goal, unambiguously describe ongoing military activities and situations, as well as provide a mechanism for very clearly and precisely describing orders and ongoing tasking. These are coherent interpretations of data groups in the context of the application; in other words, these are data being used as a logical entity within the application (here BML). In [2], this idea has been generalized to associated concepts. These groups are also often referred to as replication domains.
2.4 Physical mapping The third step is to now provide a mechanism whereby the enumerated data of the source data model is now projected into the target data model. This results in data translation for two specific models based on the general steps described before. This step will require a methodology whereby the data stored in an instantiation of the source data model can somehow have the necessary transformations and transportations performed on it so that it satisfies the target data model’s requirements for necessary data (at least insofar as there was a logical mapping of that necessary data provided for in the second step of the mapping process). The mechanism provided for at this step should ideally be robust enough to draw from any instantiation of the source data model, and to project into any instantiation of the target data model.
It was very important to not only understand these conceptual areas as they existed within the MSDB, but also how these conceptual areas were intended to be used. As an example, lets take a look at Task Organization. As it is represented within the MSDB, Task Organization employs, among others, the following tables, and groups of tables: doc, bml2_plan, org_doc, org_assoc, org, uto.
At this point in the ongoing project to map an instantiation of the BML concepts into an instantiation of the C2IEDM data model, the first step, Conceptual Mapping, has been completed, and the second, Logical Mapping, is in progress. A significant number of the insights gained during the initial research has provided a head start on the remainder of the work, namely the remaining Logical mapping steps, as well as the Physical mapping steps.
04F-SIW-111
Header Task Organization Weather Control Features Organizations Actions Who, What, Why, When, Where
Task Organization is the conceptual area that deals with the organization of forces for a particular military task. The tables and table grouping shown in Figure 2 provide a description of Task Organizations. Doc is the portion of BML that describes a document, for example a military plan, or a set of issued orders for a simulation. Org is the portion of BML that defines a friendly military organization. Uto is the unit task order, which is connected with the
5
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 •
The structure should be sufficiently generic to accommodate joint, land, sea, and air environment concerns.
•
The data model describes all objects of interest in the sphere of operations, e.g., organizations, persons, equipment, facilities, geographic features, weather phenomena, and military control measures such as boundaries.
•
Objects of interest may be generic in terms of a class or a type and specific in Figure 2. Example of the BML concept TASK_ORG [8] terms of an individually identified organization via the Org_assc table, comprising the item. All objects items must be classified as associations for the organization. The table Org_doc being of some type (e.g. a specific tank that is connected the document with the leading or upper identified by serial number WS62105B is an most parent organization, but there was no item of type "Challenger"). connection to the tasks associated with these orders. • An object must have the capability to perform a This is, however, necessary when following the Who, function or to achieve an end. Thus, a What, Where, When, Why concepts of BML. The description of capability is needed to give Why is given by the orders in the document. The meaning to the value of objects in the sphere of bml2_plan table (a modified version of the JCDB operations. “plans” table) is used to connect the document information with the unit task order. Figure 2 shows • It should be possible to assign a location to any how these tables are connected within the U.S. Army item in the sphere of operations. In addition, prototype. various geometric shapes need to be represented in order to allow commanders to plan, direct, and monitor operations. Examples include boundaries, corridors, restricted areas, minefields, and any other control measures needed by commanders and their staffs.
What is important here is that we had to understand not only what was accomplished, or represented, in each of the conceptual areas of BML, but also in how the different tables, and even entities within those tables, interacted. 3.2 Conceptual definitions: C2IEDM The four aspects discussed in section 1.2 – objects, situations, activ-ities, and containers – are portrayed through the properties (attributes) and propertied concepts (tables) of the data model. The model has identified a number of different principles in conveying the four aspects listed above. These principles are listed below, taken from [4].
04F-SIW-111
6
•
Several aspects of status of items need to be maintained.
•
The model must permit a description of the composition of a type object in terms of other type objects. Such concepts include tables of organizations, equipment, or personnel.
•
The model must reflect information about what is held, owned, or possessed in terms of types by a specific object item.
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 many entities, or entity struc-ture trees (in the case of an independent entity and all the supporting entities that go towards defining it) in the C2IEDM can best be used to represent these areas.
Task Org C2IEDM act_task
act
act_task_id
act_id
org_struct_root_org_id
cat_code
act_cat_code
name
code
org_struct_ix
org_act_assoc org_id act_id
org org_id cat_code nickname_name
org_struct_det
org_struct
org_struct_root_org_id
org_struct_root_org_id
org_struct_ix
org_struct_ix
obj_item_assc
org_struct_det_ix
subj_obj_item_id
subj_obj_item_id
obj_obj_item_id
obj_obj_item_id
obj_item_assoc_ix
obj_item_assoc_ix
cat_code subcat_code act_task_id obj_item obj_item_id
obj_item_type
cat_code
obj_item_id
unit
name
obj_type_id
unit_id
altn_identific_txt
obj_type obj_type_id
For each one of the BML concept areas, we mapped out how it could be defined using the Entities and Entity relationships from C2IEDM. This was originally captured graphically as shown in Figure 3, but then was captured in tabular form as shown in Table 1.
Throughout these efforts, the guiding principle must be to reuse as much of the previously incorporated Figure 3. Modeling TASK_ORG using C2IEDM information as possible. The main principle of model-based data There is a need to record relationships between management [2] is the definition of unambiguous pairs of items. Key among these is the data elements in the form of property values, specification of unit task organizations and properties, propertied concepts, and associated orders of battle. concepts. Creating new concepts comprising data elements that already exist somewhere else violates The model must support the specification of this very basic rule, because it creates ambiguity. In current, past, and future role of objects as part of this application this means creating new tables that plans, orders, and events. duplicate attributes already defined in another table. The same data structure should be used to record Due to this it is necessary to check the consistency of information for all objects, regardless of their the solutions bottom-up after having reach consensus hostility status. in the mapping method based on a top-down strategy. Provision must be made for the identification of sources of information, the effective and 4. Lessons Learned reporting times, and an indication of the validity of the data. We have gathered a very strong conceptual view of formal_abbrd_name
•
•
•
•
the two models, and we have already mapped the logical relationships between the two. Work has begun on the logical mapping, but it is still to be completed. Here we will discuss some of the lessons learned from our research in two areas, the mapping process itself, and also some of the insights gained from working with the two models. These lessons have strengthened our view that this process will not be done automatically in the foreseeable future but humans will be in the loop for the data management portion of data engineering.
Understanding the four aspects, as defined by these principles, is essential to understanding the conceptual area of C2IEDM, and how they are used. 3.3 Logical Relationships: From BML to C2IEDM Since we were starting with BML concepts embedded in an instantiation of the MSDB and moving to having the BML concepts embedded in an instantiation of the C2IEDM, we began by gaining an under-standing of each of the conceptual areas of BML. Next, it is necessary to identify which of the
04F-SIW-111
7
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004
Table 1. Logical Mapping Example
C2IEDM Target
MSDB Source MSDB Columns org org_id
obj_item org obj_item_id org_id cat_code="OR" cat_code="UN"
org_name
name
org_forml_abb_nm
unit unit_id
obj_item_stat affl affl_geopolitical obj_item_id affl_id affl_id obj_item_stat_ix cat_code="A FLGEO" cat_code="OR"
formal_abbrd_name
affiliation_cd
hstly_code
country
code
org_typ_indx
org_type org_typ_indx
obj_type org_type govt_org_type mil_org_type unit_type obj_type_id org_type_id govt_org_type_id mil_org_type_id unit_type_id cat_code="OR" cat_code="GVTORG" cat_code="MILORG" cat_code="UNIT"
funct_role_cd echelon_cd
size_code
msn_speciality
arm_spclsn_code
msn_cd
arm_cat_code
mobility_cd
gen_mob_code
orgt_rmk_txt
proposed methods of providing the future transport mechanism between these two models.
4.1 The Mapping Process The conceptual understanding required a good bit of study. However, once the understanding was achieved, the mechanisms for representing the objects and relationships required for BML became readily apparent in the C2IEDM.
There was an investigation into a more conventional method for doing the transport mechanism, which involved writing a set of algorithmic instructions whereby data would be extracted (enumeration data) from the source model and then inserted (with any transformations and/or additions necessary) into the target model.
Both BML and C2IEDM have, as a goal, the ability to define any sort of object that may appear within a battle space, as well as describing its relationships to other objects. Given that this is so, and that the source data would be the same for each model, we found the natural language similarities between conceptual areas to be obvious in most cases.
The path forward can be done either way, and we believe that by plumbing the conceptual mappings, as well as the logical mappings, we have shown that it is only a matter of defining the physical mechanism before a reusable method for transformation from the target model to the source model will be a repeatable process.
Where this proved to be more difficult was in that we were mapping the BML concepts as they were developed in the MSDB, an instantiated relational database with no data model, and trying to establish these concepts in a data model. An early attempt at doing the physical mapping was accomplished by defining the MSDB and C2IEDM with XML, using the Extensible Stylesheet Language (XSL) format. Then a transformation between the related relationships was done employing the Extensible Stylesheet Language Transformation (XSLT). Results are very promising, and this is one of the
04F-SIW-111
4.2 Models’ Abstraction Levels The mapping process describes the mapping of one data model to another data model. Application of this process to a real world application introduced an element that had not been previously considered: a mismatch of the levels of abstraction in which the models are defined. In the case of BML, the model is in MSDB, a database which has no data model. Even though there is a data model for the JCDB, the JDM, it has not been extended to include these BML-
8
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 required tables. This meant that all mappings from BML were from a physical database. Fortunately, in a previous task, most of the BML concepts had been defined in figures similar to Figure 1 [8]. These figures became the starting point and format for the conceptual mapping.
Acknowledgements The work described in this paper is a team effort of the XBML team. All individuals of the team as well as some additional experts contributed to the success. Following persons contributed in particular: Francisco Loaiza, Gene Simaitis and Steven Wartik (IDA), James Muguira (VMASC), Michael Hieb (Alion), and Mark Pullen (GMU). The underlying research work was funded by DMSO.
4.3 Learning C2IEDM While C2IEDM is excellent for data exchange concerning a situation, we still need to incorporate into it BML’s ability to structure data into plans for future activities.
References
The entity that is used by the C2IEDM to convey planned activities is ACTION TASK. This is defined as “an ACTION that is being or has been planned and for which the planning details are known” [4]. We found several areas where it was difficult to satisfy the needs of a standard five paragraph operational order (Situation, Mission, Execution, Service Support, and Command and Signal). These areas included plans in which an ACTION-TASK was related in some way to the completion of nonplanned tasks (which are referred to in the C2IEDM as ACTION EVENTS). We have discovered a small number of areas where extension to the C2IEDM will be necessary to be able to unambiguously convey the same information that is available within BML. In addition to this, the CONCEPT idea of C2IEDM plays a critical role as well. The CONCEPT idea enables the data modeler to merge different tasks into missions and lower-level missions into higher-level missions. It allows the fractal implementation on tasks from the platform to the unit level.
[1] Andreas Tolk: “Common Data Administration, Data Management, and Data Alignment as a Necessary Requirement for Coupling C4ISR Systems and M&S”, Information and Security, Volume 12, Number 2, pp. 164 – 174, 2003 [2] Andreas Tolk: “XML Mediation Services utilizing Model Based Data Management,” 2004 Winter Simulation Conference, SCS, Arlington, VA, December 2004 [3] 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, 2001. [4] Multilateral Interoperability Program, “Overview of the C2 Information Exchange Data Model (C2IEDM),” November 2003. [5] Hieb, M., “Battle Management Language Project Update,” C2IEDM Workshop, March 2004.
The complete documentation of C2IEDM, comprising more than 1,000 pages of definitions, was very valuable. However, even an experienced data modeler needs four to six weeks to understand the data model and an additional two to four weeks of practice with the model to understand the practical applicability.
[6] Hieb, M., Tolk, A., Sudnikovich, W., Pullen, M., “Developing Extensible Battle Management Language to Enable Interoperability,” Paper 04E-SIW-064, Spring Simulation Interoperability Workshop, 2004. [7] Brown, C., “BML Update,” SIMCI Technical Exchange, April 2002.
5. Summary
[8] DeMasi, L., “MSDB Data Path Diagrams,” SIMCI Technical Exchange, 2003.
This project describes an initial attempt to apply the theory of data engineering to a real world problem. The first step, that of Conceptual Mapping, has been successfully applied. Besides fulfilling the requirement of jointness and international applications of BML, many additional benefits potentially emerge from these tasks, such as guidelines for the mapping, tools supporting the mapping, and potentially an XML mediation service as envisioned in [2].
04F-SIW-111
[9] DeMasi, L., “C2IEDM Data Path Diagrams,” SIMCI Technical Exchange, 2004.
9
Fall Simulation Interoperability Workshop Orlando, Florida, September 2004 in programming and database analysis for M&S and web-based applications. He has been the lead on the Army BML (Battle Management Language) and DMSO XBML projects for all database work including the current transition of MSDB to C2IEDM.
Authors’ Biographies CHARLES TURNITSA is the Lab Manager for the Battle Lab at Virginia Modeling Analysis and Simulation Center (VMASC) of Old Dominion University (ODU) of Norfolk, Virginia. In addition to his work as Lab Manager, he also performs as a system engineer and researcher on several VMASC research projects. He has served in many roles as an IT professional for over a decade, performing analysis, design, and development tasks on many research projects for NASA and the US Military.
VERLYNDA DOBBS is a Senior Computer Scientist for Atlantic Consulting Services (ACS), Inc. She is currently involved in developing the C4I – M&S Reference Object Model. Prior to coming to ACS, Dr. Dobbs provided support to various organizations within the U.S. Army PEO C3T, focusing on software reuse processes, product lines, software architectures, software reuse standards, object oriented technology, quality factors and metrics for reusability. Dr. Dobbs was a member of the Computer Science faculty of Wright State University, Dayton, Ohio, where she taught courses in software engineering, distributed processing, operating systems and artificial intelligence, primarily at the graduate level. Dr. Dobbs holds a PhD degree in Computer Science from The Ohio State University, Columbus, Ohio.
SAI KOVVURI is a Computer Science Graduate Student who has worked as a Researcher at the Virginia Modeling, Analysis, and Simulation Center (VMASC) of Old Dominion University (ODU) for the past months. He supported the XBML (Extensible Battle Management Language) project, amongst other projects related to the XMSF (Extensible Modeling and Simulation Framework) initiative. 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 14 years of international experience in the field of Applied Military Operations Research and Modeling and Simulation of and for Command and Control Systems. In addition to his research work, he gives lectures in the Modeling and Simulation program of ODU. His domain of expertise is the integration of M&S functionality into real world applications based on open standards.
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.
LIAM DEMASI is a Computer Programmer at Atlantic Consulting Services, Inc. (ACS), in Shrewsbury, NJ. He has over 4 years of experience
04F-SIW-111
10
