semantic battlespace data mapping using tactical ...

SEMANTIC BATTLESPACE DATA MAPPING USING TACTICAL SYMBOLOGY Mariusz Chmielewski1, Andrzej Gałka1 1

Cybernetics Faculty, Military University of Technology, Kaliskiego 2, 00-908 Warsaw, Poland

Abstract. Interoperability of military C4ISR systems mainly in NATO Joint Operations has been one of crucial tasks. The most mature standard designed for system interoperability is the JC3IEDM, which was developed based on several NATO C4I models. Representing battlefield scenarios in form of pure relational data requires additional rendering mechanism to present the situation picture, which can further be reused by the decision makers. The purpose of this work is to describe the development process of JC3IEDM and APP-6A ontologies and designed model mappings. Analysis of both standards helped us realized that transformation of data structures is not the modelling goal itself. The descriptions provided within the models carry the semantics as domain values for attributes, and business rules stating their valid combinations. Through detailed review of both standards, it was possible to identify missing descriptions both in JC3 and APP-6A and most of all describe the similarities further used as a source for definition of ontology class constructors and SWRL rules. Produced models in conducted research have been applied as knowledge bases for decision support tools providing several combat scenarios, uploaded into operational JC3 database, which was then the source for migrating them into semantic model. Ontology processing services using mapping rules transformed instances of battlespace objects into symbology domain, identifying the APP-6A signs codes used by the distributed Common Operational Picture tools. Prototype subsystem, developed as proof of concept, renders the battlespace scenario based on identified semantic bridges between the JC3IEDM (used for reflecting detailed information on the battlefield) and symbology standard. Keywords: military operations, warfighting symbology, common operational picture, ontology, semantic models, decision support

1 Introduction Development of decision support tools reuses many rendering mechanisms for presentation of GIS (Geographic Information System) data along with current and future state of the battlespace elements. Representing combat scenarios in form of pure relational data requires additional algorithms to present the situation picture, which can further be reused by the decision makers. Graphical icons placed over the generated digital maps help to express current combat situation [4]. Shared situational awareness enables collaboration between sensors, actors and command centers improving synchronization, and reduces the communication delays which in result speed up decision process and increase mission effectiveness. NATO symbology standards covers the majority of battlespace and civilian elements. Analysis of taxonomy helps to understand the idea of upgrading the data of

the element on the battlespace, where incoming reports provide additional details, which can change the semantics of stored element and in result the symbol itself. Static mapping of data in the software is most usually approach found in the presentation layer. This solution is efficient but not extendable and without additional program logic could not provide mechanisms for mapping and data consistency checking. This work presents an original approach of building semantic bridges between data stored in C4ISR [12] standard model (JC3) and APP-6A symbology using ontology and reasoning mechanisms. Such case study helped us to develop transformation mechanisms for object oriented and relational data models, verify the abilities of such transformations and evaluate designed ontology metrics. Our experiences, conclusions and results have been applied in semantic mechanisms of SOA demonstrator developed under the agenda of KOS project referenced in acknowledgments. Network Centric Warfare theory defines several concepts used as a product of information flow or as a tool for decision support procedures - Situation Awareness and Common Operational Picture. Both concepts are connected with each other due to their specific domain that is battlespace description. Situation awareness (SAW) can be understand as a perception of environmental elements within a volume of time and space, the comprehension of their meaning, and the projection of their status in the near future. SAW combines perception and environment critical to decision-makers in complex, dynamic processes, in this case - military command and control [4]. Situation awareness as stated before, is achieved in minds of commanders by their analysis of incoming reports and functionalities of used C4ISR systems. Sophisticated tools for data acquisition, data mining, decision support, generate data sets representing picture of environment in the current combat space. Situation awareness contains data gathered from all available battlespace dimensions loaded form C4ISR systems. Migrated data is the key to understanding and describing environment, providing battlespace perception and preparing variants for developed decisions. Lack of data or having inadequate information and in result limited situation awareness, has been identified as one of the primary factors in accidents attributed to human error. Situation awareness characterizes wider concept than Common Operational Picture which could be described as a visualization product used by the C4I systems for Joint Operation Command Centers. To define COP can be provided from several sources which after analysis can be stated as [12] : “Common Operational Picture can be defined as a single identical display of all relevant (battlespace) information shared by more than one command. COP merges all available data providing information superiority and facilitating collaborative planning and assisting all units to achieve situational awareness.” It must be stated that COP is a tool supporting existing, in many cases legacy C4I systems using an integration layer which provides a unified means of data recognition, filtering and fusion. Such service or group of services in command system delivers current situation consisting of both military and civilian domain, general pointers and guidelines in Area of Responsibility – AOR and Area of Interest - AOI. Essential requirements for COP has been formulated in [15], in which it can be defined as a service or a set of services providing: collection of recognized pictures, data fusion and correlation of recognized pictures.

Common Operational Picture requires Geospatial Information Services often based on several standardized data sources, supported by graphic and decision support functionalities. Considering current development phase, NATO stated that the COP requirements need to be sequentially and partially extended. Battlespace view is usually a collection of information in the COP aggregated and displayed for decision support. It serves to ensure functional consistency among specific views of separate battlespace dimensions – air, ground, marine. Problems connected with achieving a perception of a situation and therefore COP, evolve indicating many concepts of battlespace and overcoming technical requirements for federated distributed real time systems.

2 APP-6A warfighting symbology standard Interoperability Exchange Data Model semantics

and

JC3

To express semantics of current combat scenario commanders have used all kinds of symbology preparing tactical maps. Standard provides common operational symbology defining details on their display and plotting, ensuring compatibility among the semantics of created battlespace picture. APP-6A [14] (Allied Procedural Publication) defines rules for creating, organizing object information through the use of a standard methodology for symbol hierarchy, information taxonomy, and symbol identifiers. This work will only describe general elements of the standard which will directly be reflected in designed mechanisms and which the Reader should be familiar with. For detailed information on APP-6A see [14]. Standard defines whole taxonomy of signs considering the rule of generalisation or specialisation. Digging deeper into the sign hierarchy enables to define object in more details. Each sign is defined in form of 15 character code which stores whole sign semantics. Given this code we can express: - coding scheme [CS] (position 1) - indicates to which overall symbology set a symbol belongs; - affiliation / exercise amplifying descriptor [AF] (position 2) – indicates the side of the conflict or special identified affiliation for exercise purposes; - battle dimension [BD] (position 3) – indicates one of the dimensions in which the units/equipment can operate in air, ground, surface, subsurface, space and other; - status [ST] (position 4) – defines the future or present indicator for the object; - function id [FK] – (position 5-10) – important semantic information which , identifies object function-type. Each position indicates an increasing level of detail and specialization; - symbol modifier [SM] – (position 11-12) - identifies indicators present on the symbol such as object rank, feint/dummy, installation, task force, headquarters staff, and equipment mobility; - country code [CC] - (position 13-14) - identifies the country with which a symbol is associated; - order of battle [OB] – (position 15) - provides additional information about the role of an object in the battlespace (differencing type of forces). The values in each field are filled from left to right unless otherwise specified. Basic symbol requires minimal information workload to present the coding scheme, affiliation, battle dimension and function id due to the fact that they reflect the basic

icon. Standard allows to leave unknown code positions blank or filled with standardized symbols “-” or “_”. Code

Description Hostile ground unit (present)

Sign

shgpu----------

shgpuc---------

Hostile ground combat unit (present)

shgpuca--------

Hostile ground armoured unit (present)

shgpucaa-------

Hostile ground anti-armoured unit (present)

shgpucaaa------

Hostile ground anti-armoured armoured unit (present)

shgpucaaaw-----

Hostile ground anti-armoured armoured wheeled unit (present)

Tab. 1 Symbol hierarchy representation in APP-6A standard presenting information for example hostile unit Table presents part of sign hierarchy in which extended coding scheme specify the object and reflect the semantics of the combat unit presented in the scenario. APP-6A extends image symbology towards mandatory and optional sign attributes.

Pic. 1(a,b) Elements of APP-6A sign with all description blocks and elements (both graphical and text – left picture), sample Common Operational Picture reflected on the CADRG map in designed prototype using APP-6A symbology (right picture) Presented set of icons can demonstrate battlefield data incompleteness, where in series of reports system may update and upgrade object’s attributes reflected further in APP-6A. Pic.1a presents scheme for defining all basic elements of the sign: the

form of all identifiers (describing their possible values, placement, development rules, and most of all required graphical elements). Several years of collaborative work in workgroup (MIP) allowed to unify the common data model dedicated for C4ISR systems integration. Model construction required specific approach for storing battlespace entities, domain values and value restrictions for defined enumerations. Main model purpose - data interoperability requires a rigorously defined semantic vocabulary (domains and domain values in that is embedded in a structured context. JC3IEDM defines elements of information that form the basis for interoperability between automated Command and Control Information Systems - in case of Polish Armed Forces Szafran, Dunaj, Podbiał, Łeba MCIS - accommodating model's information structure. Standard intent is to represent the core of the data identified for exchange across multiple functional areas of existing or legacy C4ISR systems. Model in current version 3.1b [16] consist of: 290 entities, 1594 attributes, 533 domains (enumeration types), 12409 - domain values, 259 associations, 166 hierarchy relations. Due to the large scale of the model and all available descriptions provided by MIP we have chosen a metamodel database MIRD [17] to transform chosen entities and relations to the form of semantic model. This operation required extended analysis of the JC3 semantics to: choose main parts of the model to be transformed; identify transformation rules for JC3 relational model to ontology; filter ontology classes and extract only needed elements

3 Semantic model and ontology in project application In case of presented work we apply ontologies in model descriptions to utilize the semantics of main parts and in the end provide semantic bridges between the domain models. For model representation we choose Description Logic and appropriate dialect for expressing our ontologies. Selecting currently available semantic languages we have based our models on OWL DL which is direct offspring of description logic SHOIN (ALCR+HOIN) [9]Błąd! Nie można odnaleźć źródła odwołania.. Model of formally represented knowledge is based on a conceptualization: concepts, objects and entities with relationships identified among them [1]. Conceptualization can be defined as an abstract, simplified view of the reality that the modeller wants to represent for defined purpose. Every knowledgebased system, or knowledge multiagent environment is committed to some conceptualization, explicitly or implicitly. We base our ontology design criteria on guidelines described in [1] concerning clarity, coherence, extendibility, minimal encoding bias, minimal ontological commitment. Ontology languages design criteria required that the expressiveness of the model must be also fallowed by the reasoning capabilities. Experiences taken from the First Order Logic reasoning methods and algorithms and dedicated reasoning algorithms for Description Logic (Tableux algorithm) [9] allowed to provide inference tools. Those capabilities are mainly used in the design phase of each of described ontologies and most of all they provide the matching algorithms for mapping data from JC3 to APP-6A. Designed models have been serialized in form of OWL DL, and using Protégé modelling tool. We have tested two separate strategies for model design. Based on available JC3IEDM conceptual model we managed to define set of

transformation rules that was used to convert relational model into the ontology. The transformation process consecrates on reflecting the semantics of the model not its structure. Due to this fact, some of the entities defined on the level of conceptual model have been erased and replaced by the relations between concepts e.g. associations between OBJECT-TYPE are represented by the OBJECT-TYPEASSOCIATION entity. The other tested strategy for ontology design assumed building it from scratch, therefore studying the details of modelled domain. This approach has been applied to develop the two variants of APP-6A ontology.

Pic. 2 Overview of the design process and elements of fused ontology model Unified Battlefield Ontology Ontology development for the COP enabled tool required detailed C4I system data sources especially in the aspect of visualization mechanism and GIS data standard used by the system. Current version of Unified Battlespace Ontology Model (UBOM) consists of: - MIP’s JC3IEDM model based ontology describing wide range of military operations (actions), military units and equipment, their location and available reporting data; - APP-6A Warfighting symbology standard – containing battlespace objects and their description without references to location and extended relations between objects; - Fusion mappings – ontology focused on concept definitions using JC3IEDM semantics (classes and relations) and reflecting them in APP-6A concept hierarchy. Relational model chosen as a form of JC3 representation provides difficulties to identify the semantics of model. Analysis of the model taking into account only structure will provide only model stored in OWL not ontology itself due to crucial requirements that such model must satisfy. Relational models carry overflow in form of required elements used by the RDBMS to properly construct relations among data records. To filter such elements we have chosen to process the JC3 metamodel MIRD instead of the JC3 physical model. Implementation of the JC3IEDM usually depend

on an underlying MIP Information Resource Dictionary database. Information about the JC3IEDM entities, attributes, cardinality or subtype relationships, primary or foreign keys, domains, domain values etc., are stored in this metamodel and enable to determine, under dynamic user-imposed constraints, what to replicate and how. The ontology development has been divided into two stages: in first all specified entities and their relationships are transformed into ontology classes and properties. The second stage verifies the model and refines the constructs changing the model itself to bring up the semantics (discarding association tables and introducing relations with additional characteristics). JC3 model structure consists of entities, composed of attributes. In most cases types of attributes are defined by domains which after deep overview are true holders of the model semantics. Domains are composed of domain vales which create similar structure as enumeration type. JC3 defines also business rules which are used to obtain valid domain values combinations for selected attributes. For the purpose of this work we utilize business rules for UNIT-TYPE entity to construct available variants of defined units. The domain knowledge used in this process has been described in MIR Annex G - Symbology Mapping [13]. Definitions of model transformation rules has been mainly aimed at: Generic guidelines for relational model to ontology transformation; Identification of excess relational model elements associated with physical model representation and not its contents; Definition of uniform naming conventions for created semantic model elements based on relational model predecessors; Development of additional validation rules to identify valid domain values combinations and their reflection in form of description logic class constructors or SWRL reasoning rules; Definition of optimal range of JC3IEDM elements to be transformed providing required ontology expressiveness with compact size and processing efficiency. Generation of JC3 ontology has been executed several times with different set of transformation rules. The main cause of such approach has been ontology refinement process and optimization of ontology OWL language form stored in resulting file. Final set of rules define fallowing transformations: - Entity to OWLNamedClass - Cardinality relationships to OWLObjectProperty with OWLCardinalityRestriction

-

-

Subtype relationships to OWLNamedClass subtype hierarchy Attribute to OWLObjectProperty in case where the attribute type is Domain or OWLDatatypeProperty where the attribute type is primitive type reflected in ontology by RDFSDatatype DomainValue-> OWLIndividual Domain -> OWLEnumeratedClass containing OWLIndividuals generated from DomainValues associated to this Domain BusinessRules-> OWLNamedClass with defined value restriction OWLHasValue,OWLAllValuesFrom,OWLSomeValuesFrom

Pic. 3 JC3IEDM ontology transformation algorithm based on MIRD model transformation. As stated before each of the APP-6A element can be described by the 15 character code. Positions of the code represent specific part of the element semantics. Reflecting these elements is the basis for definitions of all elements.

Pic. 4 Concept definition of APP-6A code elements

Pic. 5 Specification on Unit concepts in APP-6A

Using those elements we have defined hierarchy of symbols as specified in the APP-6A documentation. Each sign category (Equipment, Unit, Weapon, etc.) consist of concepts provided in the specification but also extended using DL class constructors to use reasoning capabilities in ontology. Unit concept sub tree allows to analyze the required conditions for inference mechanism to correctly classify individual to this class. Category-Code subclasses define individuals which identify the APP-6A enumeration codes used in sign coding e.g. Affiliation-CategoryCode - A_Indiv-ACC, D_Indiv-ACC, F_Indiv-ACC, G_IndivACC, H_Indiv-ACC, etc.

Individual naming scheme uses as a first character the specified in the APP-6A code concatenated with “_Indiv” string, followed by the abbreviation of the CategoryCode subclass. For shown example H_Indiv-ACC stands for individual from Affiliation-CategoryCode (ACC) indicating “H” code meaning Hostile. As shown on Pic. 5 prepared taxonomy focus on the combat units because of the source data which will later will be gathered from the JC3. Prepared concept list tries to reflect taxonomy based on several criteria: - Funtion-ID – defining the purpose and function of the unit (Combat-Unit, CombatServiceSupport-Unit, CombatSupport-Unit) - Affiliation – defining unit’s specified side of the conflict – Friend-Unit, HostileUnit, Neutral-Unit, Unknown-Unit) Intentionally other specified values for function-id and affiliation were not defined to minimize the size of ontology. We also concentrate on providing mapping method not fully reflecting source specifications. Definitions of classes Unit, Combat-Unit and Infantry-Combat show Description Logic constructor usage modelled using APP-6A code elements defined in ontology. (∃hasWarfighting-CodeScheme.Warfighting-CodingScheme  ∃hasUnit-FuntionID.FunctionID-CategoryCode  ∃hasStatus.Status-CategoryCode  ∃hasGroundDimension.Ground-BattleDimension  ∃hasAffiliation.Affiliation-CategoryCode) ≡ Unit hasUnit-FunctionID. {UC----_Indiv-FIDCC}≡ Combat-Unit Combat-Unit * Unit hasUnit-FunctionID. { UCI---_Indiv-FIDCC }≡ Infantry-Combat Infantry-Combat * Combat-Unit

Presented constructions use necessary conditions in form of * inclusion, subsumption or necessary and sufficient conditions in form of ≡ equality. Next stage of integration process is overcoming the differences between ontologies. Process of reconciliation of these differences is called ontology mediation, which enables reuse of data across C4I systems and, in general, cooperation between different battlespace dimensions. Considering context of semantic knowledge management, ontology mediation is important due to data sharing between heterogeneous knowledge bases and data reuse. UBOM [11] development final step is based on ontology merging (definition of Fusion.owl), which can be considered as the creation of ontology from several source ontologies. New product unifies information representation and provides equivalent concepts in source ontologies (app6a.owl and jc3.owl). Ontology merging distinguish two approaches [2],[3]: overwrite method – taking the input set of ontologies and transforming them to merged, ontology which captures the original ontologies; append method in which the original ontologies are not replaced, but rather dynamically represented in bridge ontology, created using original ontologies imports using bridge axioms. Developed solution uses the append method using ontology import functionality and introducing the mapping axioms. To present the abilities of designed models and mapping scheme we introduced definition of class MechanisedInfantry-Unit-Type which has been defined using elements of JC3 ontology as: MechanisedInfantry-Unit-Type

* Unit-Type

has-Unit-Type-Supplementary-Specialisation-Code.{Ground-UTSSC} 

has-Unit-Type-General-Mobility-Code.{Land-Tracked-UTGMC} has-Unit-Type-ARM-Category-Code.{Armour-UTACC} has-Military-Organization-Type-Service-Code.{ Army-MOTSC}

≡ MechanisedInfantry-Unit-Type

Fusion OWL defines class equality between jc3: MechanisedInfantryUnit-Type and app6a:InfantryMechanised-Combat. To demonstrate the mapping mechanisms we must introduce unit instance into the JC3 ontology which requires adding Unit and Unit-Type individuals and setting all required object property values used by the reasoner and specified in table above. Introduced equivalent axiom automatically classifies individual as app6a:InfantryMechanised-Combat setting all object property values required by the app6a ontology thus filling in the symbology semantics and in the end assigning code. Incomplete information status Code Sign Unknown ground unit (present) sugpu----------

Unknown ground combat unit (present) sugpuc---------

Unknown ground infantry unit (present) sugpuci--------

Unknown ground armored infantry unit (present)

sugpuciz-------

Unknown ground armored infantry battalion (present)

sugpucizef-----

Hostile ground armored infantry battalion (present)

shgpucizef-----

Tab. 2 Combat object representation improved using information from battlefield Table 2 presents possible combat situation provided in system where reconnaissance units supply reports (Reporting Data) identifying new units discovered within the Area of Responsibility. Unit information in fallowing reports fill the details on affiliation of the unit, its equipment – type and rank.

4 Summary In this paper we have described concept of ontology usage as mapping tool between two separate battlespace semantic standards JC3IEDM and APP-6A. Analysis of both standards directly showed that transformation of data structures must not be the crucial task while designing knowledge base. The descriptions provided within the models as enumeration types, domain values and additional descriptions carry most of the model semantics. Through detailed review of both standards, it was

possible to identify missing descriptions both in JC3 and APP-6A and most of all describe the similarities further used as a source for definition of ontology class constructors and SWRL rules. To complete designed method we have proposed an architecture and implementation of COP environment capable of utilizing JC3IEDM and mapping it to APP-6A symbology while providing currently stored battlespace scenario. Generating battlefield picture filtered and delivered on time to all command centers provides a new quality in information management. Developed software environment, equipped with ontology tools, demonstrates feasibility study of integrated dynamic battlefield, providing large scale information resources in heterogeneous systems. Extending such system with SOA specific technologies, allowed integration of legacy systems; and the ability to easily substitute alternative components to meet specific interoperability requirements. Acknowledgments. This work was partially supported by Research Project No O R00 0050 06 and PBZ-MNiSW-DBO-02/I/2007.

References 1. T.R.Gruber, Toward Principles for the Design of Ontologies Used for Knowledge Sharing, International Journal Human-Computer Studies 43, August 23, 1993 2. J. de Bruijn, A. Polleres, Towards and ontology mapping specification language for the semantic web, Technical Report DERI-2004-06-30, 2004 3. M. Ehrig, Y. Sure, Ontology mapping—an integrated approach, Proceedings of the First European Semantic Web Symposium, ESWS 2004, Vol. 3053 of Lecture Notes in Computer Science, Springer-Verlag, Heraklion, Greece, 2004 4. M. R. Endsley, D. J. Garland, Situation Awareness Analysis and Measurement: Analysis and Measurement, Lawrence Erlbaum Associates, 2000, ISBN 0805821341 5. D. Roman, U. Keller, H. Lausen, J. Bruijn, R. Lara, M. Stollberg, A. Polleres, C. Feier, C. Bussler, D. Fensel: Web Service Modeling Ontology, Applied Ontology, 2005 6. J. Davies, D. Fensel, F. Harmelen, Towards the Semantic Web: Ontology-driven Knowledge Management, HPL-2003-173, JOHN WILEY & SONS, LTD, 2003 7. M. Herrmann, O. Dalferth, M. A. Aslam, Applying Semantics (WSDL, WSDL-S, OWL) in Service Oriented Architectures (SOA), 10th Intl. Protégé Conference, 2007 8. J. Davies, D. Fensel, F. Harmelen: Towards the Semantic Web: Ontology-driven Knowledge management, HPL-2003-173, John Wiley & Sons, 2003 9. F. Baader and other, Description Logic Handbook, ISBN 0-521-78176-0, Cambridge University Press, 2003, 10. M. Chmielewski, J. Koszela, The concept of C4I systems data integration for planning joint military operations, based on JC3 standard, MCC Conference 2008 11. M. Chmielewski, Data fusion based on ontology model for Common Operational Picture using OpenMap and Jena semantic framework, MCC Conference 2008 12. DOD, JP 1-02, DOD Dictionary of Military and Associated Terms, April 2001 13. MIP, MIR–SEAWG–ANNEX G, MIP symbology mapping rules, February 2009 14. NATO, APP-6A, Military Symbols for Land Based Systems, October 1998 15. NATO, NATO Common Operational Picture (NCOP) - NC3A, 16.11.2006 r. 16. MIP, The joint C3 information exchange data model overview, 2009 17. MIP , The Joint C3 Information Exchange Data Model metamodel (JC3IEDM metamodel), 13.12.2007