Situation Analysis for the Tactical Army Commander · 2012-08-03 · Situation Analysis for the...

Situation Analysis for the Tactical Army

CommanderFinal report

É. DorionA. Bergeron GuyardDRDC Valcartier

Defence R&D Canada – ValcartierTechnical Report

DRDC Valcartier TR 2010-174May 2011

Situation Analysis for the Tactical ArmyCommanderFinal report

É. DorionA. Bergeron GuyardDefence R&D Canada – Valcartier

Defence R&D Canada – ValcartierTechnical ReportDRDC Valcartier TR 2010-174May 2011

Principal Author

Éric Dorion

Approved by

Patrick MaupinH/C2 DSS

Approved for release by

Christian CarrierChief scientist

c© Her Majesty the Queen in Right of Canada as represented by the Minister of NationalDefence, 2011

c© Sa Majesté la Reine (en droit du Canada), telle que représentée par le ministre de laDéfense nationale, 2011

Abstract

Between 2003 and 2009, Defence Research & Development Canada (DRDC) conductedthe Applied Research Project (ARP) 12of named Situation Analysis for the Tactical ArmyCommander (SATAC). The focus of this project was to reflect on the possibility to useautomated reasoning techniques and tools on top of the Joint Consultation Command andControl Information Exchange Data Model (JC3IEDM). This data model is the ontologyused by the Land Forces in their command and control software applications.

The project produced a number of scientific publications, contract reports, a software pro-totype and recommendations to the Land Forces. This report summarizes the findings thatwere made, which are further explained in the affiliated project deliverables.

Résumé

De 2003 à 2009, Recherche et développement pour la défense Canada (RDDC) a réaliséle projet 12of appelé Analyse de la Situation pour le Commandant d’Armée Tactique (AS-CAT). Le but de ce projet était de réfléchir sur la possibilité d’utiliser les techniques etoutils du raisonnement automatisé sur le Joint Consultation Command and Control Infor-mation Exchange Data Model (JC3IEDM). Ce modèle de données est l’ontologie utiliséepar les forces terrestres pour leurs applications logicielles de commandement et contrôle.

Le projet a produit nombre de publications scientifiques, rapports de contrats, un prototypelogiciel et des recommandations à la force terrestre. Ce rapport résume les découvertes quisont expliquées plus en détail dans les autres livrables liés au projet.

DRDC Valcartier TR 2010-174 i

This page intentionally left blank.

ii DRDC Valcartier TR 2010-174

Executive summary

Situation Analysis for the Tactical Army Commander:Final report

É. Dorion, A. Bergeron Guyard; DRDC Valcartier TR 2010-174; Defence R&DCanada – Valcartier; May 2011.

Background: Situation Analysis for the Tactical Army Commander (SATAC) was an Ap-plied Research Project (ARP) evolving under the auspices of the DRDC 12o – Commandthrust. Its official military partner was the Directorate of Land Requirements (DLR). Theproject officially started in May 2005 and ended in April 2009. SATAC’s goal was to pro-vide the Canadian Land Forces with the means to develop an automated reasoning capabil-ity in order to support Situation Analysis (SA) for the Tactical Army Commander (TAC).Informally, SA is the process by which one gains Situation Awareness, which in turn is amental representation of the state of the environment of interest. The TAC is consideredto be any leader with an assigned mission and allocated resources, operating in a complexand austere environment where risk and stress are the norm rather than exception. Being"tactical", the TAC is typically short on time to react and lack supporting analytical staff.

Principal results: SATAC showed that the current Army’s database technology used byits Operational DataBase (ODB), which is based on the Joint Consultation Command andControl Information Exchange Data Model (JC3IEDM) is adequate to build automatedreasoning agents that will exploit information that currently overflows human cognitivecapabilities. This is materialized into twelve DRDC documents (from technical notes totechnical reports), eight contract reports, a software prototype and participation to manyworkshops on the subject.

Significance of results: The development of automated reasoning tools and techniquesworking over their current software suite clearly shows the Army that better informationmanagement could be achieved. While new sensors are added to their already loaded con-stellation, it becomes apparent that information will eventually overflow their technicalcapability. It is essential to find methods of processing information that will offload the al-ready overburdened tactical army commander. SATAC provided a sound technical solutionthat can be tailored to the specific needs of the Army.

Future work: The lessons learned in SATAC should be used to define a more encompass-ing project like a TDP. Such a project would enable the creation of automated reasoningagents that address real sensors and real operational data. It would also enable the Army tolearn the process of building such agents and to customize the approach for its own specificneeds.

DRDC Valcartier TR 2010-174 iii

From a scientific perspective, research into other aspects of artificial intelligence such asmachine learning would be desirable. This is justified by the acknowledged principle thathuman reasoning is naturally coupled with the learning process. Keeping a conceptualbarrier between these two sub-fields of artificial intelligence might prove to be the wrongstrategy to follow in the long term.

iv DRDC Valcartier TR 2010-174

Sommaire

Situation Analysis for the Tactical Army Commander:Final report

É. Dorion, A. Bergeron Guyard ; DRDC Valcartier TR 2010-174 ; R & D pour ladéfense Canada – Valcartier ; mai 2011.

Contexte : Le Projet de recherche appliquée (PRA) Analyse de la situation pour le com-mandant d’armée tactique a évolué sous les auspices du vecteur 12o – Commandement.Son partenaire militaire officiel était le Directorat Besoins en ressources terre (DBRT). Leprojet a débuté en mai 2005 et s’est terminé en avril 2009. Le but d’ASCAT était de donneraux forces canadiennes la possibilité de développer une capacité de raisonnement automa-tisé dans le but de supporter l’analyse de la situation (AS) pour le commandant d’arméetactique (CAT). Informellement, l’analyse de la situation est le processus par lequel on ac-quiert la conscience de la situation (CS) qui est en fait une représentation mentale de l’étatde l’environnement d’intérêt. Le CAT est défini comme étant tout dirigeant ayant reçu unemission et des ressources, oeuvrant dans un environnement complexe et austère où le risqueet le stress sont la norme plutôt que l’exception. Étant "tactique", le CAT a peu de tempspour réagir et ne dispose pas d’accès à une équipe d’analystes.

Résultats principaux : SATAC a montré que la technologie de base de données actuellede l’armée utilisée par son "Operational DataBase (ODB)", dérivée du "Joint ConsultationCommand and Control Information Exchange Data Model (JC3IEDM)", est adéquate pourconstruire des agents de raisonnement automatisé qui exploiteront l’information, évitantainsi de surcharger la capacité cognitive de l’humain. Cette démonstration est décrite dansdouze publications de RDDC (allant des notes aux rapports techniques), huit rapports decontrats, un prototype logiciel ainsi que la participation à plusieurs ateliers de travail sur lesujet.

Portée des résultats : Le développement d’outils et de techniques de raisonnement auto-matisé fonctionnant sur la suite logicielle actuelle de l’armée démontre qu’une meilleuregestion de l’information peut être réalisée. Alors que de nouveaux capteurs sont ajoutésà leur constellation déjà surchargée, il est clair que l’information finira par excéder leurcapacité technique. Il est essentiel de trouver des façons de traiter cette information detelle sorte qu’elle ne surcharge pas le CAT déjà très occupé. ASCAT a produit une solidesolution technique qui peut être adaptée aux besoins particuliers de l’armée.

Recherches futures : Les leçons apprises dans ASCAT devraient servir à la définitiond’un projet plus englobant, tel un projet de démonstration technologique (PDT). Un tel

DRDC Valcartier TR 2010-174 v

projet permettrait la création d’agents de raisonnement automatisé applicables à des cap-teurs et des données opérationnelles réelles. Cela permettrait aussi à l’armée d’apprendrele processus de construction de tels agents et de les adapter à ces besoins particuliers.

D’une perspective scientifique, faire de la recherche dans des aspects complémentairesde l’intelligence artificielle, comme l’apprentissage machine, serait souhaitable. Cela sejustifie par le principe reconnu que le raisonnement humain est naturellement couplé auprocessus d’apprentissage. Le maintien d’une barrière conceptuelle entre ces deux sous-champs de l’intelligence artificielle pourrait se révéler être une stratégie fallacieuse à longterme.

vi DRDC Valcartier TR 2010-174

Table of contents

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Résumé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i

Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iii

Sommaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . v

Table of contents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii

List of figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

1 SATAC Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2 Knowledge Representation Study . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2.1 Fundamentals of Knowledge Representation . . . . . . . . . . . . . . . . 2

2.1.1 Syntactical Aspects of KR . . . . . . . . . . . . . . . . . . . . . 3

2.1.2 Inferential Aspects of KR . . . . . . . . . . . . . . . . . . . . . 3

2.1.3 Expressiveness capabilities of Knowledge RepresentationMechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.2 Knowledge Representation in Computer Systems . . . . . . . . . . . . . . 6

2.2.1 Relational Model and the Entity-Relationship Model . . . . . . . 7

2.2.2 Logic, Description Logic and OWL . . . . . . . . . . . . . . . . 8

2.3 Evaluation and Comparison of KRMs in Computer Systems . . . . . . . . 8

2.3.1 Evaluation and Comparison Criteria . . . . . . . . . . . . . . . . 9

2.3.2 General Evaluation and Comparison of some KRMs . . . . . . . 9

2.4 Situating JC3IEDM and P-JC3IEDM in SATAC’s Problem Space . . . . . 10

3 Situation Analysis Support System Prototype . . . . . . . . . . . . . . . . . . . 11

3.1 Choice of an Appropriate KRM . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Selection of an Operational Scenario . . . . . . . . . . . . . . . . . . . . 11

DRDC Valcartier TR 2010-174 vii

3.3 The SASS Prototype Architecture . . . . . . . . . . . . . . . . . . . . . . 13

3.3.1 Software Architecture Description . . . . . . . . . . . . . . . . . 13

3.3.2 The Simulator Service . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.3 The Observer Service . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.4 The Reasoning Service . . . . . . . . . . . . . . . . . . . . . . . 15

3.3.4.1 The Ambush and Spotlite Reasoning Agents . . . . . . 16

3.3.5 The Presentation Service . . . . . . . . . . . . . . . . . . . . . . 17

4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

Annex A: SASS Prototype Convoy Scenario Vignette . . . . . . . . . . . . . . . . . 23

List of symbols/abbreviations/acronyms/initialisms . . . . . . . . . . . . . . . . . . 30

viii DRDC Valcartier TR 2010-174

List of figures

Figure 1: A Taxonomy of KR Languages and Formalisms . . . . . . . . . . . . . 6

Figure 2: Master Event List Snippet . . . . . . . . . . . . . . . . . . . . . . . . . 12

Figure 3: SASS Components Diagram . . . . . . . . . . . . . . . . . . . . . . . . 14

Figure 4: The Simulator Service . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

Figure 5: Trigger Message Creation Process . . . . . . . . . . . . . . . . . . . . . 15

Figure 6: SASS Prototype Running on Battleview . . . . . . . . . . . . . . . . . . 18

Figure A.1: Convoy Resupply Scenario Map . . . . . . . . . . . . . . . . . . . . . . 23

DRDC Valcartier TR 2010-174 ix


x DRDC Valcartier TR 2010-174

1 SATAC Background

Situation Analysis for the Tactical Army Commander (SATAC) was an Applied ResearchProject (ARP) evolving under the auspices of the DRDC 12o - Command thrust. Its officialmilitary partner was the Directorate of Land Requirements (DLR). The project officiallystarted in May 2005 and ended in April 2009. The first year was devoted to the conduct ofa scoping study [1] that enabled the definition of the key activities that were undertaken inthe project. This report constitutes the final deliverable of the project and aims at explainingits principal results and discoveries.

SATAC’s goal was to provide the Canadian Land Forces with the means to develop anautomated reasoning capability in order to support Situation Analysis (SA) for the TacticalArmy Commander (TAC). Informally, SA is the process by which one gains SituationAwareness, which in turn is a mental representation of the state of the environment ofinterest [2]. The TAC is considered to be any leader with an assigned mission and allocatedresources, operating in a complex and austere environment where risk and stress are thenorm rather than the exception. Being "tactical", the TAC is typically short on time to reactand lack supporting analytical staff.

The main concern of the project was to identify the supporting technologies that wouldhelp the TAC maintain situational awareness. This concern was exacerbated by the factthat the TAC is not able to mentally process the multitude of information elements thatcompose a situation. In the Army, these information elements come from many diversesensors (e.g. ELINT, SIGINT, HUMINT) and are processed and stored in the OperationalDataBase (ODB). The ODB is the Canadian implementation of STANAG 5525 [3], theJoint Consultation Command and Control Information Exchange Data Model (JC3IEDM),a data model that aims at enabling systems-to-systems semantic interoperability betweenNATO coalition partners.

Adopting the ODB as a central technology artefact for the project not only came as a naturalchoice, but also as a DLR requirement. However, there was two competing technical im-plementations of the ODB: The first was a classical database implementation built on SQLServer 2000, and the other was implemented as an OWL ontology [4]. The former consti-tutes the Army’s current implementation while the latter is a translation of the JC3IEDMinto OWL [5] proposed by Matheus and Ulicny [6]. SATAC took under its responsibility toreflect on both representations (hereafter termed JC3IEDM and P-JC3IEDM), with respectto the overarching project goal, and make proper recommendations to DLR.

In order to achieve SATAC’s goal under the aforementioned technological constraint ofthe ODB (either in its database or OWL form), three scientific activities were conducted.Firstly, a study of Knowledge Representation Mechanisms (KRMs) was done to determineboth the level of expressiveness of database schemas and OWL representations as well astheir respective inferencing mechanisms. This was done in order to advise the Army on

DRDC Valcartier TR 2010-174 1

what technology to adopt in a relatively near future (Horizon II, 6 to 10 years). Secondly,cognitive engineering activities were conducted with Subject Matter Experts (SMEs) inorder to determine the exact cognitive information requirements of the TAC in four typi-cal military operational scenarios. Thirdly and last, a Situation Analysis Support System(SASS) prototype was built to demonstrate the results and findings of the project and pre-sented to the DRDC Command Thrust (12o) meeting in May 2009. This report summarizesthe results and findings of knowledge representation studies and the SASS prototype, whilethe results of the cognitive engineering studies are further explained in [7].

2 Knowledge Representation Study

The aim of the Knowledge Representation (KR) study was two-fold: 1) To make a surveyof the scientific literature, to establish the state of the art in KR and to describe how KRmechanisms support inferencing in knowledge-based computer systems. It includes aninventory of the approaches, paradigms, techniques, languages, tools, etc. used for KR incomputer systems, as well as an evaluation of these approaches in the context of SATAC. 2)To show how the JC3IEDM and the P-JC3IEDM map against the generic framework andcriteria developed in the first part. This chapter summarizes the findings that are furtherexplained in [8, 9, 10, 11, 12]

2.1 Fundamentals of Knowledge RepresentationKnowledge Representation refers to formalisms and languages to represent knowledgebases as well as reasoning mechanisms to manipulate them. As such, KR is a surrogateto what it is meant to describe and serves as an ontological basis on which formal machineprocessing can occur. Inferencing is one of those processes that make use of knowledgebases. The ability to perform inferencing (or automated reasoning) is greatly influencedby the choice of the KR Mechanism (KRM). Since the JC3IEDM ontology is representedboth in the Entity-Relationship model and the Web Ontology Language (OWL) KRMs,one would ask which representation is better suited for supporting military operationalinferencing, i.e. the type of automated reasoning that is meaningful from a military stand-point. But first, a broad picture of KR formalisms must be painted where JC3IEDM andP-JC3IEDM can be situated in.

Since SATAC’s goal was to reflect on automated reasoning over JC3IEDM andP-JC3IEDM, two aspects of KR were studied in the project. First, the syntactical notionsof KR which are the rules by which information can be stored and organized in a specificKRM, and second, the inferential aspects that are enabled or constrained by the choice ofa specific KRM.

2 DRDC Valcartier TR 2010-174

2.1.1 Syntactical Aspects of KR

From a representational point of view, KRs possess a certain number of constructs thatenable the proper representation of the domain they model. The following lists a commoncore of these KR building blocks:

Concept – A central construct of any KRM that specifies what exists in the domain,

Attribute – The characteristics or features concepts may have,

Constraint – The limiting conditions for attributes (default values, types, cardinalities,etc.)

Relation – The formal description of interactions between concepts or attributes (e.g.subsumption ("is-a"), mereology ("part-of"), etc),

Axiom – A knowledge element that is considered to be true and cannot be proved by therules of inferencing of this knowledge system,

Instance – A physical manifestation of a specific concept.

An analysis of a specific KRM with regard to its capability to represent a domain must beconducted on the basis of these KRM constructs.

2.1.2 Inferential Aspects of KR

The choice of a specific KRM conditions the ability to reason over the knowledge base dueto its distinct syntactical characteristics. It is therefore important to consider inferencing(or automated reasoning) as a process that is inherently coupled with the KRM.

From a general perspective, inferencing on a knowledge base follows either a forward rea-soning (data-driven) or a backward reasoning (goal-driven) approach. The first approachrelies on the appearance of new information in the knowledge base to trigger the infer-encing process while the latter actively seeks the supporting information in the knowledgebase to confirm a hypothesis (the goal).

From a strict computational perspective, an important inferential aspect is the search mech-anism (control regime). This aspect is also influenced by the underlying structure of theknowledge base. The search mechanism is a strategy against which inferencing is per-formed. Many control regime strategies exist: Depth-first, Breadth-first, depth-limited,best first, bi-directional, etc.). The first two, depth-first and breadth-first are the most com-monly known:


Depth-first – The interpreter uses the first reduction, and then tries to reduce it to sub-goals. A depth-first inference extends the current path as far as possible (or up to amaximum depth) along a given branch before backtracking to the last choice pointand trying the next alternative path.

Breadth-first – The interpreter tries all possible inferences at a given level (all one-stepextensions of current paths) before moving deeper. This is an uninformed searchmethod that examines all the nodes of a graph systematically in search of a solution,without considering the goal of the research or using heuristics to limit the searchdomain.

Other aspects of inferencing that may influence the choice of a KRM are soundness, com-pleteness, ability to reason over taxonomies, exception and constraint checking, excitabilityof procedures.

2.1.3 Expressiveness capabilities of Knowledge RepresentationMechanisms

KRMs are assessed from four different viewpoints in order to determine their distinctivecapabilities:

Conceptual level – The actual primitives needed to be included in a KRM,

Epistemological level – the types of structural primitives in the KRM that are needed tosupport the targeted inference strategies,

Logical level – The semantics of the formalism the KRM supports (e.g. First-order logic,Description logic, etc.),

Implementation – Deals with how a KRM is actually stored in computers and how infer-ence mechanisms work from a computational point of view.

Since syntactical and inferential aspects are tightly coupled for automated reasoning overa knowledge base, a criteria set for the adequacy of KRMs must involve both aspects. Ta-ble 1 describes such criteria against which the JC3IEDM and PJC3IEDM were judged.Columns "S" and "I" refer to "Syntactical" and "Inferential", respectively. It must be notedthat "Clear semantics" is a measure of expressiveness of the KRM. A tradeoff exists be-tween expressiveness and efficiency as well as between expressiveness and effectivenessin the sense that the more expressive a KRM is, the more complex must be the inferenceprocedures to provide effective reasoning mechanisms. And the more complicated infer-ence procedures are, the less efficient they tend to be. There is no perfect balance betweenexpressiveness or efficiency. The choice depends on many factors, such as performanceof the computer system, how quick an answer is needed, the kind of answer – "yes" or


Level Criterion S I ExplanationImplementation Compactness

√Allows storage of knowledge in aspace-efficient way.

Efficiency√

Draws inferences in a time-efficient way.

Logical Clearsemantics(expressiveness)

√The meaning of well-formed ex-pressions must be clearly speci-fied.

Soundness(effectiveness)

√If the explicit information inthe knowledge base is true,then the retrieved implicit in-formation must also be true.

Completeness(effectiveness)

√An inference process is completeif it can derive all true conclu-sions from a set of premises.

Consistency√

The possibility to infer knowl-edge elements that contradict.

Epistemological Naturalness(understandability)

√How natural is it to organize in-formation about a particular do-main? How easy is it to un-derstand and follow conclusionsmade from the knowledge base?

Modularity√

Any particular change in aknowledge domain must affecta limited part of the knowledgebase.

Granularity√

Determines the size of the knowl-edge base atomic elements.

Conceptual Conciseness√ √

How concisely pieces of knowl-edge are represented.

Table 1: Criteria of Adequacy of KR Languages


"no" – or involvement of human knowledge to adjust results. However, KRMs that arevery expressive usually become undecidable or semidecidable. Undecidability means thattrue implicit knowledge cannot be retrieved after a finite number of steps of reasoning.Semidecidability means that a positive answer can be found after a finite number of steps,but negative results cannot be proven after a finite number of steps. Decidability is also aconstituent of effectiveness and belongs to both the syntactical and inferential aspects ofKR. It is impossible to associate decidability with any one level of KR. Therefore, in acontext where the purpose of the KRM is to support automated reasoning, there must be atradeoff between the level of expressiveness, efficiency and effectiveness.

2.2 Knowledge Representation in Computer Systems

Figure 1: A Taxonomy of KR Languages and Formalisms


Figure 1 presents a general taxonomy of KRMs. The diagram is a graphical representationof the KRMs described in this report and is not per se an authoritative classification. Thefigure uses the UML notation in which an arrow denotes a specialization and a diamonddenotes a relation of aggregation. Many conceptual overlaps exist in KR models; thereforeany attempt to classify them depends on the importance given to each KR characteristics.

Generally, the evolution of KR models shows a development of two forms of knowledge:The first is descriptional and is devoted to classification or categorization. Such repre-sentations are focused on classes, their attributes or properties, and hierarchies. The sec-ond, is assertional and focuses on characteristics of individual objects and relationshipsbetween them [13]. As such, any KR presents strength and weaknesses when comparedto one another. The next section briefly describes the KRMs on which the JC3IEDM andP-JC3IEDM are built. The interested reader will find greater details on other KRMs in [8].

2.2.1 Relational Model and the Entity-Relationship Model

The relational model for database management is a database model based on predicatelogic and set theory. This model proposed by E.F. Codd [14] was designed as a naturalway to store data the same way it is stored in tables. The relational model was not ini-tially prepared to describe categories, axioms and other knowledge-related features, but itwas created for elegant representation of data in comparison with network and hierarchi-cal models; it is therefore a lightweight ontology representation. The Entity-Relationship(E-R) model came in an effort to couple the relational model with a semantic model. Atthe representational level, the information structures for entity and relationship instancesstrongly resemble relations. The only abstraction directly supported in the original E-R model is aggregation, although there are extended models that include generalization.Mapped against our conceptualization of a KR, the E-R model can be interpreted as fol-lows:

Concept – can be represented by E-R entity,

Attribute – can be represented by E-R attribute,

Constraint – may correspond to E-R integrity constraint, but often must be specifiedoutside the E-R model,

Relation – corresponds to E-R relationship,

Axiom – may correspond to E-R integrity constraint, but often must be specified outsidethe E-R model,

Instance – The actual data.

Inferencing in the implemented view of the E-R model is achieved with SQL (StructuredQuery Language) but present several defects [15].


2.2.2 Logic, Description Logic and OWL

Logic (and to some extent, all KRs) is a family of formal languages in which both knowl-edge can be expressed, and reasoning can be carried out. The language is specified bya specific syntax and semantics. The syntax specifies well-formed expressions and its se-mantics is the means by which meaning is conveyed by these well-formed expressions. Forcarrying out reasoning, logic sanctions what is called sound inference or truth preservinginference [16]. An inference is sound if all conclusions are true, given true premises.

The syntax, semantics and inference mechanism differ depending on the kind of logic.Descriptions of the most frequently used logics along with their strengths and weaknessesare discussed in [8]. This report will focus on Description Logic (DL) as a superset of theweb ontology language (OWL), the latter being P-JC3IEDM’s KRM.

DL is a subset of First-Order Logic (FOL). Its syntactical body is determined by the choiceof a certain number of constructors enumerated in Table 2. Any specific subsets of theseconstructors define instances of DL languages that present distinctive levels of expressive-ness. As noted in [8], the more expressive a language is, the more difficult it is to reasonover that language. OWL-DL for instance is a DL subset that implements SH I Q . Eventhough this language is relatively constrained in expressiveness, it is undecidable in certainsituations [17].

DL languages map against our KRM framework as the following:

Concept – The concepts enumerated in the Terminological Box (TBox),

Attribute – Slot or attribute depending on the specific language,

Constraint – Implemented with the concept of equivalent classes,

Relation – Binary relation implemented with Properties,

Axiom – Expressed as assertions in the Assertional Box (ABox),

Instance – Individual declared in the ABox.

2.3 Evaluation and Comparison of KRMs in ComputerSystems

The KRMs considered in this project were briefly described and projected against our syn-tactical framework (Capability to represent concepts, attributes, constraints, relations, ax-ioms and instances). To compare KRMs between one another, we used the criteria setdescribed in subsection 2.1.3 (see Table 1). This effectively enabled us to compare theKRMs both from syntactical and inferential perspectives, thus determining the broad levelof adequacy of specific KRMs (in the context of this project).


Constructor Name Syntax SemanticsAtomic concept A AI ⊆ ∆I

S

Atomic role R RI ⊆ ∆I ×∆I

Transitive role R ∈R+ RI =(RI )+

Conjunction CuD CI ∩DI

Disjunction CtD CI ∪DI

Negation ¬C ∆I \CI

Existential restriction ∃R.C {x|∃y.(x,y) ∈ RI and y ∈CI}Value restriction ∀R.C {x|∀y.(x,y) ∈ RI implies y ∈CI}Role hierarchy Rv S RI ⊆ SI HNominal {o} {oI} OInverse role R− {(x,y)|(y,x) ∈ RI} INumber ≥ nP {x|#{y.(x,y) ∈ PI} ≥ n} Nrestrictions ≤ nP {x|#{y.(x,y) ∈ PI} ≤ n}Qualifying number ≥ nP.C {x|#{y.(x,y) ∈ PI and y ∈CI} ≤ n} Qrestrictions ≤ nP.C {x|#{y.(x,y) ∈ PI and y ∈CI} ≥ n}

Table 2: Description Logic Constructor Names[18, p. 462]

2.3.1 Evaluation and Comparison Criteria

While Table 1 shows nine distinct criteria, the first three (expressiveness, effectiveness andefficiency) are considered as primary criteria in that they can veto out a specific KRMunder consideration. Indeed, representation of the domain (covered by expressiveness),applicability of the KRM to a specific problem domain (effectiveness) and how fast can theKRM draw inferences (efficiency) are of the utmost importance. The six remaining crite-ria (conciseness, complexity1, naturalness, understandability, modularity and flexibility),while participating in the total score of a KRM, are not permitted to rule it out on their soleaccount.

2.3.2 General Evaluation and Comparison of some KRMs

A general evaluation and comparison of many KRMs was done in [8] by a KnowledgeRepresentation expert, namely Dr. Yevgen Biletskiy of University of New Brunswick. Asubset of this evaluation is reproduced in this report (Table 3) for the KRMs that are usedby the JC3IEDM and P-JC3IEDM.

Scores in Table 3 range between 1 to 5. If the cutoff score for the primary criteria is set to3, then it can be seen that the E-R model, DL and OWL-DL basically pass the evaluationfrom a broad perspective of KRM expressiveness, effectiveness and efficiency. The three

1To accommodate the scoring, Simplicity was used as a strict converse criterion to Complexity.


Entity-Relationship Model Description Logic OWL-DLExpressiveness 3 4 3Effectiveness 4 4 4Efficiency 4 4 4Conciseness 2 4 2.5Simplicity 2.5 1 3Naturalness 3 3 2Understandability 4 3 2.5Modularity 2 3 3.5Flexibility 2.5 3 3

27 29 27.5Table 3: Comparative Summary of some KRMs

KRMs have comparable total score, DL being the highest followed by OWL-DL and theEntity-Relationship Model.

2.4 Situating JC3IEDM and P-JC3IEDM in SATAC’sProblem Space

As stated above, JC3IEDM is captured with the Entity-Relationship model andP-JC3IEDM is captured in OWL. With the fact that OWL scores slightly better than theE-R Model with respect to Table 1 criteria, one would think that P-JC3IEDM would be abetter choice for implementing an automated reasoning system. However, we must con-sider how P-JC3IEDM was actually engineered. P-JC3IEDM is an automated translationof the JC3IEDM logical model into OWL [6]. The heuristics used to produce the OWLversion are very close to the logical E-R dialect. For example, many-to-many relationshipsbetween E-R entities can only be achieved through the introduction of third entities (termedassociative entities) in order to properly identify specific relationships. The P-JC3IEDMhave those associative entities as classes. But OWL does not need associative entities toimplement many-to-many relationships and furthermore a reasoner that would resolve (un-der certain inference rules) the membership of an individual into those associative entitieswould in effect answer no viable operational question. P-JC3IEDM is therefore inadequatefor the implementation of a SASS prototype, not because of its KRM, but because of howit was engineered. This led the SASS development team to engineer the SASS prototypewith the JC3IEDM, prototype that shall be described in the next chapter.


3 Situation Analysis Support SystemPrototype

SATAC’s last goal was to build a Situation Analysis Support System (SASS) prototype. Asa proof of concept, it aimed at demonstrating the added value of injecting an automatedreasoning capability within the environment of the Tactical Army Commander (TAC). Todo so, three technological objectives needed to be met:

• To make a choice on the appropriate KRM to be used for the prototype,

• To select a scenario that would elicit an appropriate response from the prototype,

• To architect and develop the prototype while taking into account the Army’s currenttechnological constraints.

This chapter describes in further details how these objectives were addressed.

3.1 Choice of an Appropriate KRMBased on the findings described in [8, 10, 11, 12], a decision was made to choose the currentArmy’s Operational DataBase (ODB) which is implemented on the Entity-RelationshipModel (E-R Model). This at first seemedcounter-intuitive since OWL-DL (the P-JC3IEDM’s KRM) theoretically scored higher thanthe E-R Model. However, as was demonstrated in [10], reasoning over the P-JC3IEDMposed serious difficulties from an operational decision-making perspective because of P-JC3IEDM’s poor design [12]. The technical choice for the SASS prototype was then toabandon P-JC3IEDM and to focus on developping the SASS prototype over the ODB.

3.2 Selection of an Operational ScenarioSelecting an appropriate operational scenario that would elicit correctly the SASS pro-totype and show that the inferred conclusions (resulting from the automated reasoningprocesses) are relevant to the operational environment was an important task. Furthermore,the scenario events needed to highlight aspects of the TAC decision-making process, whichwere further decomposed into Situation Analysis Requirements (SARs) [7]. The challengewas thus to select the scenario that would both address the SARs and showcase the SASSprototype, while taking into account the Army’s current technology (the ODB). Since theDirectorate of Land Requirements (DLR) had already provided their Military OperationalScenario #1 (MOS #1) for the derivation of the SARs, the task became one of deriving theproper vignette to showcase the SASS prototype automated reasoning capabilities.


The SASS prototype scenario vignette was developed through a series of workshops whichbrought together members of the scientific community and military experts. After a num-ber of iterations, it was decided that the scenario would be centered around the resupplyconvoy mission described in MOS #1. The complete description of the vignette is givenin Annex A. The mission consists of three RG31s and two civilian trucks with civiliandrivers. The goal of the convoy is to resupply a forward observation base (FOB) and re-turn. In that context, the SASS prototype would advise the Convoy Commander (TAC) onthe following:

1. Threat Anticipation. Advice pertaining to the anticipation of hostile activity (specif-ically assessing the probability of being subject to an ambush).

2. Situation Awareness (SAW) Recovery. Presentation of SAW-critical information toassist the Convoy Commander restore his/her level of SAW during hostile activity /periods of high workload (specifically processing information in the ODB that comesfrom a Spotlite sensor).

Figure 2: Master Event List Snippet

The SASS Prototype scenario vignette was also enriched with finer-grained event informa-tion in order to meet the specific needs of the prototype (e.g. the exact geo-location of theconvoy with respect to scenario time). Finally, a master events list (Figure 2) was producedto highlight the SASS prototype outputs and relate them to specific SARs.


3.3 The SASS Prototype ArchitectureThe SASS prototype architecture was conceived in such a way that it addressed the broadergoal of SATAC, namely to provide the Canadian Forces with the means to build an auto-mated reasoning capability in order to support Situation Analysis. In order to do so, theprototype must provide these basic capabilities:

• To gather information elements and monitor the changes occurring in a given situa-tion,

• To reason over these information elements (produce inferences),

• To store the inferred information elements, and

• To inform the TAC about the inferred conclusions.

The prototype architecture was conditioned by some underlying assumptions and technicalconstraints:

• As discussed above, the ODB was the preferred KRM for the prototype implementa-tion. This meant that the reasoning capability had to be developed in SQL statements,which of course presents its own set of limitations [8, 10];

• An automated reasoning capability for the TAC relies on the availability of ODBs atthis level of command. Although this may not be the case with the current Army’stechnological deployment, our military partner (DLCSPM) informed us that this as-sumption is reasonable, at least for the near future;

• The prototype was to showcase automated reasoning over information elements inthe ODB provided by sensors (e.g. Spotlite sensor) after some pre-processing. Suchinformation was not available at the time of design but our military partner (DLC-SPM) acknowledged this as a requirement on which the Army would work.

3.3.1 Software Architecture Description

This subsection provides descriptive information about the main components of the SASSprototype. The architecture of the SASS prototype revolves around a set of componentsthat work in concert. The most important service components are

• the Simulator,

• the Observer,

• the Reasoning and


Figure 3: SASS Components Diagram

• the Presentation components.

Their interactions are depicted in Figure 3.

The Simulator injects the scenario events into the ODB. The changes are detected by theObserver which in turn notifies the Reasoning service. The latter uses the propositionalinformation to infer new content and feed it back to the ODB. The new information is thenhandled by the Presentation service that makes it visually available to the TAC.

3.3.2 The Simulator Service

The Simulator (Figure 4) is a standalone service component used to inject live sensoryinputs into the ODB from an XML data scenario file. The data scenario file contains SQLstatements and supplementary information that plays the operational scenario (Annex A).The Simulator also allows the user to play, pause and stop or accelerate the unfoldingoperational scenario. The fact that the Simulator service component uses an external XMLfile as a source enables the complete redesign of the operational scenario. The SASSprototype could then be fed with a search and rescue operational scenario, for example.

3.3.3 The Observer Service

The Observer is a service component that notifies subscribing client applications of mes-sages made available in the ODB. These messages are collections of information elementsadded when scenario events occur. The Observer that relies on database triggers for itstechnical implementation acts as an accumulator of atomic information element changes.When a meaningful aggregate (the message) is formed, the service relays it to the clientreasoning agent. This message creation process, depicted in Figure 5 requires aggregationheuristics that are handled by the specific client reasoning agent. Therefore, the Observeris technically independent from the reasoning agents. It is also independent from the ODB


Figure 4: The Simulator Service

since the specific surveillance task (the actual sequence of database triggers) is also gener-ated by the reasoning agent. The Observer is therefore completely decoupled, ontologicallyspeaking, from the ODB and the reasoning agents. It is, however, dependent on databasetechnology for event handling.

Figure 5: Trigger Message Creation Process

3.3.4 The Reasoning Service

The Reasoning Service lies at the heart of the SASS prototype. It is the service by whichmessages sent by the Observer are processed by inference rules (rule-based logic) and bywhich conclusions (inferences) are reached and fed back into the ODB. Those conclusionsprovide information relevant to the TAC and are sent to the Presentation Service for properdisplay.

The inference rules are derived from heuristics that represent expert knowledge of the tar-


geted reasoning process. The SASS Prototype implements two distinct reasoning pro-cesses, namely the Ambush and the Spotlite reasoners. They are designed to be distinctsoftware components, or agents, because their inference rules are distinct. Indeed, theseagents implement very different reasoning processes and required inputs from two humanexperts.

The reasoning agents are responsible for:

• Subscribing to a number of Observers,

• Tasking the Observers with lists of information elements it is interested in (includingthe database triggers),

• Listening to the Observers,

• Producing specific ODB queries in order to discover evidence that support specificconclusions (goal-driven reasoning),

• Writing the inferences in the ODB, and

• Informing the Presentation Service of the inferences.

From a software implementation perspective, the reasoning agents were implemented withthe Windows Workflow Foundation (WWF) [19]. WWF provides a framework for manag-ing parallel tasks that can be stopped, started, and persisted into a database. The frameworkcan be tailored to implement the type of reasoning used in the SASS prototype. The choiceof a .NET technology also facilitates the integration of the SASS prototype into Battleview[20], the presentation front-end .

3.3.4.1 The Ambush and Spotlite Reasoning Agents

The Ambush Reasoning Agent embodies a set of inference rules that aim at establishing thelikelihood of an impeding ambush that could occur in the unfolding of a mission. Likewise,the Spotlite agent includes rules under which threat anticipation from small arms fire eventscan be established. These rule sets were formalized through interviews with experts inthese domains. For example, interviews with the ambush expert outlined the followingconditions:

The likelihood of an ambush is considered to be high when all of the followingis true:

1. There is current enemy activity in this vicinity;

2. There were recent ambushes in this vicinity;

3. A hostile electromagnetic (EM) emission was detected in this vicinity;


4. There is an advantageous position in this vicinity;

5. There is an identifiable presence of a choke point on our route in thisvicinity;

6. The EM emission source is collocated with the choke point.

Whereas an ambush is highly likely to happen when all the conditions are met, lower like-liness is informally expressed by the expert when only a subset of the conditions are met.For example, if only the two first conditions are met and not the others, the likelihood ofan ambush is perceived to be low.

Once the inference rules were clearly established, their propositional content was translatedinto the ODB (it is assumed that the ODB is ontologically rich enough to hold this semanticinformation). Each information element defining a condition can potentially trigger theObserver to form an appropriate aggregate (message). Let us say, for example, that ahostile EM emission was detected, that it triggered the Observer and that a message wassent to the reasoner. This essentially sets to true condition #3. Because this alone is notsufficient to establish the likelihood of an ambush, the reasoner will actively query the ODBto establish the truth value of the other conditions (premises). This is necessary for certainreasons:

• The information was already in the ODB and would not trigger the Observer thatdetects changes;

• The truth values of certain premises depend on the location of the convoy;

• The truth values of certain premises depend on the perception of the TAC and there-fore require user input (e.g. Is this small arms caliber threatening to your convoy?)

While the Reasoning Agent is triggered by an Observer message (data-driven), it activelyseeks to determine the truth values of the other premises (goal-driven). Therefore, ourreasoning engine implements a hybrid approach between forward and backward chainingreasoning modes. A confirmed conclusion is written in the ODB and the PresentationService is notified. It is important to note that a conclusion can be the focus of anotherObserver, which could in turn trigger another reasoning process. This architecture thuspermits the chaining of reasoners to accomplish more complex reasoning processes. Thisaspect was not studied specifically in SATAC but offers great potential.

3.3.5 The Presentation Service

The Presentation Service acts upon notification from a Reasoning Agent. Its role is todisplay the Reasoning Agents conclusions on a map display. Although other means ofcommunication with the TAC could be used, we followed DLCSPM’s advice to show ourresults on an unspecified map display. A decision by the architecture team was later made


to use Battleview [20] has the presentation front-end application. The decision was moti-vated by the fact that Battleview was the Army’s current integrated application to providetheir battlespace situation awareness. Furthermore, our contractual partner for the SASSPrototype development was the contractual custodian for that application, which made in-tegration with SASS easier.

Figure 6: SASS Prototype Running on Battleview

Figure 6 depicts a screen capture of the BattleView system showing results from the SASSprototype. The results from the convoy scenario described in Section 3.2 are shown. Thegreen arrow indicates the current position of the convoy, and the various scenario eventsare shown in red. The conclusions of the SASS are displayed in the right pane.


4 Conclusion

This report presented the principal results and findings of project SATAC (12of). SATAC’sgoal was to provide the Canadian Land Forces with the means to develop an automatedreasoning capability. To reach this goal, the research was divided into three parts: Theknowledge representation study, the cognitive engineering study and the construction of aSASS Prototype.

The knowledge representation study revealed that of the two competing candidate knowl-edge bases, namely the JC3IEDM (E-R Model) and the P-JC3IEDM (OWL), the JC3IEDMis the better one to support an automated reasoning support system. This was achieved af-ter a theoretical comparison study of the underlying KRMs and the determination that theP-JC3IEDM is unsuitable for proper operational inferencing. The cognitive engineeringstudy revealed a set of situation analysis requirements that need to be met by a SASS inorder to maintain the tactical army commander’s situational awareness. The bigger setis divided into nested proper subsets when the situation prevents the determination of allthe SARs. The SASS Prototype was developed over the JC3IEDM (the ODB) and used theArmy’s Battleview, which is the current Army application suite for maintaining battlespaceawareness.

A natural follow-on of this project would be to build a working solution that makes useof real operational information with real sensor information. Our experience providedus with a comprehensive framework on how to build automated reasoning systems, butthe elicitation of expert knowledge (from which inference rules are derived) will alwaysremain the biggest challenge.

From an R&D perspective, automated reasoning is one but a fraction of the scientific ques-tion of developing true artificial intelligence for the Canadian Land Forces. Machine learn-ing for example is another very important aspect that was not covered by this project. De-fence R&D Canada – Valcartier currently research these scientific topics through focusedprojects, but integration in real operational systems shall reveal its own set of problems andpromises.


References

[1] Dorion, É., Gareau, M., and Roy, J. (2008), Situation Analysis for the Tactical ArmyCommander – Scoping Study Report, (TM 2006-408) DRDC – Valcartier.UNCLASSIFIED.

[2] Endsley, M.R. (1995), Toward a Theory of Situation Awareness in DynamicSystems, Human Factors Journal, 37(1), 32–64.

[3] The Multilateral Interoperability Programme (online), http://www.mip-site.org(Access Date: June 2009).

[4] Web Ontology Language (OWL) (online), http://www.w3.org/2004/OWL/(Access Date: June 2009).

[5] Matheus, C. J. and Ulicny, B., JC3IEDM 3.1a OWL Ontology (online),http://vistology.com/ont/2007/JC3IEDM3.1a/ (Access Date: June 2009).

[6] Matheus, C. J. and Ulicny, B. (2007), On the Automatic Generation of an OWLOntology based on the Joint C3 Information Exchange Data Model, In Proceedingsof the 12th International Command and Control Research and TechnologySymposium.

[7] Banbury, S., Forbes, K., Gauthier, M., Percival, R., Tremblay, S., and Rousseau, R.(2009), Identification of Situation Awareness Requirements for Tactical ArmyCommanders: Final Report, (CR 2009-008) Defence R&D Canada – Valcartier.

[8] Biletskiy, Y., Demers, H., and Duquet, J.-R. (2008), SATAC KnowledgeRepresentation and Automated Reasoning with JC3IEDM, (CR-2008-264) DefenceR&D Canada – Valcartier.

[9] Demers, H. and Duquet, J.-R. (2008), Development of Situation Analysis Exampleswith a Tactical Commander, (CR 2008-278) Defence R&D Canada – Valcartier.

[10] Demers, H. and Duquet, J.-R. (2008), Knowledge Representation Capabilities andLimitations of JC3IEDM and P-JC3IEDM, (CR 2008-255) Defence R&D Canada –Valcartier.

[11] Demers, H. and Duquet, J.-R. (2008), Automated Reasoning Capabilities andLimitations of P-JC3IEDM, (CR 2008-261) Defence R&D Canada – Valcartier.

[12] Demers, H. and Duquet, J.-R. (2008), Recommendations for SATAC, (CR 2008-262)Defence R&D Canada – Valcartier.

[13] Gomez-Perez, A., Corcho-Garcia, O., and Fernandez-Lopez, M. (2003), OntologicalEngineering, Secaucus, NJ, USA: Springer-Verlag New York, Inc.


http://www.mip-site.org

http://www.w3.org/2004/OWL/

http://vistology.com/ont/2007/JC3IEDM3.1a/

[14] Codd, E. F. (1970), A Relational Model of Data for Large Shared Data Banks,Communications of the ACM, 13(6), 377–387.

[15] Date, C. J. and Darwen, H. (2006), Databases, Types and the Relational Model (3rdEdition), Boston, MA, USA: Addison-Wesley Longman Publishing Co., Inc.

[16] Reichgelt, H. (1991), Knowledge Representation: An AI Perspective, Westport, CT,USA: Greenwood Publishing Group Inc.

[17] Horrocks, I., Sattler, U., and Tobies, S. (1999), Practical Reasoning for ExpressiveDescription Logics, In LPAR ’99: Proceedings of the 6th International Conferenceon Logic Programming and Automated Reasoning, pp. 161–180, London, UK:Springer-Verlag.

[18] Baader, Franz, Calvanese, Diego, McGuinness, Deborah L., Nardi, Daniele, andPatel-Schneider, Peter F., (Eds.) (2003), The Description Logic Handbook: Theory,Implementation, and Applications, Cambridge University Press.

[19] Windows Workflow Foundation (online),http://msdn.microsoft.com/en-us/netframework/aa663328.aspx (AccessDate: November 2009).

[20] Battleview, the newly integrated Canadian Army’s Tactical C2 System (online),http://www.thales-transportservices.com/News_and_events/LandJoint_Focus_060411_Battleview/ (Access Date: November 2009).


http://msdn.microsoft.com/en-us/netframework/aa663328.aspx

http://www.thales-transportservices.com/News_and_events/LandJoint_Focus_060411_Battleview/

http://www.thales-transportservices.com/News_and_events/LandJoint_Focus_060411_Battleview/

Annex A: SASS Prototype Convoy ScenarioVignette

Figure A.1: Convoy Resupply Scenario Map

IntroductionResupply convoy consisting of 3 x RG 31 and 2 x civilian trucks with civilian drivers todeliver supplies to FOB Valour and return (see Figure A.1). The convoy faces several chal-lenges along the route. The SASS and C2 applications2 will assist the Convoy Commander(TAC) in the following manner:

Threat Anticipation: Advice pertaining to the anticipation of hostile activity (e.g., possi-ble IED locations and ambush sites).

Situation Awareness Recovery Presentation of SA-critical information to assist the Con-voy Commander restore his/her level of SA during hostile activity / periods of highworkload (e.g, re-routing alternatives to avoid contact with hostile forces, or plausi-ble MEDEVAC sites following injury to personnel).

2Non-SASS functionality (e.g., route planning) is generically described as ‘C2 applications’


Unit Callsign Vehicle TypeConvoy Commander 11A RG 31Convoy 2IC 11B RG 31Security Vehicle 11C RG 31

Concept of OpsStart Time: 07:00:00End Time: 22:40:00

The convoy escort mission scenario comprises the following vignettes that highlight SASScapability (TA: Threat Anticipation / SA: Situation Awareness Recovery) and are indicatedin bold:

1 Pre-mission Planning

• Receive orders and mission planning (TA). C2 applications aid the identificationof go/no-go areas (terrain based), activity along chosen routes, position of friendlyforces, historical data (IED, Small Arms, any contact with insurgents) etc.

2 Depart CF Base Kanatahar

3 Small Arms Fire #1 (Map Location 1)

• Incoming Small Arms Fire when traveling through built-up area (SA). Sensors(son of SPOTLITE) indicate that Small Arms is 7.62 mm and not in the directionof the convoy, the SASS indicates to the convoy commander that although it isnot effective fire and that there is no immediate threat to the convoy, there are nofriendly units in the vicinity and there are unknown forces (presumed hostile) inthe vicinity.

◦ SASS information inputs:- Spotlight sensor with bearing & calibre (away from convoy and

small calibre)- Blue Force locations- Presence of Unknown trucks- No NGO facilities in area (to account for the presence of un-

known trucks)


- Location of convoy

◦ SASS reasoning output:- Alert TAC of presence of unknown vehicles and unknown (pre-

sumed hostile) forces in vicinity.

4 Pass Through City #1

• Enter City Limits Checkpoint (TA). Entering and leaving checkpoint is a vulnera-ble position. The C2 applications should notify the convoy commander that thiswas one of the highlighted red/danger areas identified during the planning phase.As a result the convoy commander radios vehicles in convoy to be alert – "this isa choke point, watch the buildings to the left possible firing position"

• Conduct Radio Check with Higher (SA). C2 applications notify the convoy com-mander that he now has no direct comms with higher (comms dead zones wereloaded into the system prior to departure from main camp). This notification re-minds the convoy commander that all comms to higher will have to be relayed.The C2 applications will identify (as they travel through the dead zones) whichunits/call signs to relay comms through (e.g., check point or the FOB Valour).

5 Troop Movement and Sandstorm (Map Location 2)

• Detect Cell Phone Traffic in Abandoned Village (TA). This built up area is anabandoned village - there should be no one there. The C2 applications indicatethat there has been no enemy activity recently and that the ANA is exercising inthe area at platoon strength with 3 x white pick up trucks (This information was anupdate provided en route - and was not part of the original planning information).

• Sandstorm Approaching (SA). Commander is looking for potential areas to takecover from the dust storm. The C2 applications indicate two options: built up area0.5 km ahead or location 2 km back down the route near some low ground.

• Convoy Halt and Sandstorm Hits (SA). The convoy finds a large walled compoundand closes up. The commander now uses the C2 applications to look at optionsfor modifying the route to make up for the lost time.

6 IED detonation (Map Location 3)

• IED Detonates in front of 2nd RG31 (SA). Coolant line on 2nd RG31 has beendamaged but not immediately noticed. The C2 applications indicate that there ispotential for ambush based on surrounding terrain and previous history. The con-voy commander decides to push the convoy further up the road before checkingfor any damage to vehicles.


7 Goats on Bridge (Map Location 4)

• Herd of Goats on Bridge (TA). The convoy is forced to slow down on the ap-proach to the bridge. The C2 applications indicate no drivable routes aroundbridge. Being exposed, the Commander requests that the SASS provides an as-sessment of the likelihood of an enemy ambush. The SASS advises the TAC torequest an UAV overflight based on the current availability of local UAV assets.The UAV indicates no red activity in area. The SASS also indicates the area hashad no insurgent activity recently and there are no ambush positions in the area.Convoy commander makes the decision to send the lead vehicle towards the herdto force them off the bridge.

◦ SASS information inputs:- TAC request for assessment of probability of enemy ambush- Current UAV locations and availability- Convoy location- Recent enemy activity in vicinity- Enemy ambush tactics (e.g., type of weaponary used – RPG

range and accuracy)- Terrain (e.g., observation points, ambush positions, choke

points)◦ SASS reasoning output:

- Request UAV overflight- Low probability of enemy ambush. Proceed with caution.

• Convoy Moves across Bridge (SA). C2 applications indicate that the convoy willbe late. Convoy was due to arrive at FOB Valour at 14:30; however, it is still atleast 60 minutes out. The commander uses C2 applications for options to makeup time. The C2 applications propose alternate (cross-country) route or increasespeed on current (paved) route.

• RG31 Overheats and Needs Repair. Commander checks C2 applications for clos-est facility with repair capability. C2 applications advise that this is the main base(CFB Kanatahar).

8 FOB Valour (Map Location 5)

• Commander Reviews Plan (SA). Instead of 4 hours on the road, the C2 applica-tions indicate that the return trip will likely take 6 hours. Commander uses the C2applications to plan the return trip, identifying potential rest areas in order to topup coolant that are away from red/danger areas (due to historical enemy action,terrain, ambush sites). The C2 applications upload the latest Intel from HQ enroute.


9 Cell Phone Traffic, Explosion and Bridge Out (Map Location 6)

• Increased Electro-Magnetic (EM) Emissions in Direction of Bridge (TA). SASSalerts the commander that the area of the bridge has been the scene of previousattacks on convoys - typically Small Arms and RPG. SASS indicates Kill Zone onelectronic map based on effective range of RPG (800 m). SASS indicates recentincreased levels of EM activity around bridge.

◦ SASS information inputs:- Location of convoy- Recent enemy activity in vicinity- Enemy ambush tactics (e.g., type of weaponary used – RPG


points)- EM detection

◦ SASS reasoning output:- High probability of enemy ambush. Seek alternate route.

• Look for Alternate Routes (SA). C2 applications indicate alternative passable routeto the south of the bridge where the convoy could cross over the dry river bed(based on topographical data).

• By-pass PlaceTypeBridge to South (TA). SASS identifies potential ambush posi-tions along new route based on historical data and topography.

◦ SASS information inputs:- Alternative routes calculated by C2 applications- Location of convoy- Recent enemy activity in vicinity- Enemy ambush tactics (e.g., type of weaponary used – RPG


points)

◦ SASS reasoning output:- Indicates probable locations of enemy ambush along

new route(s).

• Explosion in Direction of Bridge. After a few minutes, explosion detected bysensors.

• Approaching Dust Clouds (SA). C2 applications indicate that there is UAV asseton station within the area.


• Identification of Pursuing HostileForces (SA). C2 applications confirm no friendly forces in the area. C2 applica-tions indicate the following information: artillery is within range; potential defen-sive position at a location 1 km ahead, and convoy could simply increase speedand outrun them (hostile forces are in pick-up trucks that are slower off-road thanthe RG 31s).

• Convoy Stops to Add Coolant to Overheating RG-31 (TA). Commander looks atC2 applications to confirm terrain before stopping (no concealed positions and noprevious insurgent activity in the area).

10 ANA Checkpoint (Map Location 7)

• ANA Checkpoint Ahead (TA). C2 applications indicate that it is ANA checkpoint(this information is a recent update from Int uploaded en route). The convoycommander decides to advance to checkpoint based on this information.

• Convoy Approaches Built Up Area (TA). C2 applications indicate a previous hotspot for small arms fire ahead. Commander makes the decision to increase speedto pass through area quickly.

11 Vehicle Accident (Map Location 8)

• Crowd Gathers around Convoy following Vehicular Accident (SA). C2 applica-tions indicate that convoy is in an area not friendly to coalition forces.

• Commander Requests Support (SA). HQ notifies commander of the estimated timeof arrival of ANA patrol (from checkpoint), MPs and MEDEVAC (Blackhawk).

• Prepare for Medevac (SA). C2 applications indicate potential LZs (for specific aircraft type - Blackhawk)) that can be secured within the area (considerations areterrain, fields of fire, defensive position).


12 Small Arms Fire #2 (Map Location 9)



13 Pass Through City #2

• Enter City Limits Checkpoint (TA). C2 applications notify convoy commander thatthe checkpoint has been identified as a hot/red spot.

• Small Arms Fire (SA). SASS indicates that SA is from a lone sniper and is notan immediate threat to the convoy and no need for further action other than tocontinue movement of convoy (based on detection of direction and type of smallarms fire – SPOTLITE).

◦ SASS information inputs:- Spotlight sensor with bearing & calibre (towards convoy, spo-

radic and small calibre)- Blue Force location- Recent enemy (sniper) activity in vicinity- Enemy ambush tactics (e.g., type of weaponry used – sniper

rifle and accuracy)- Terrain (e.g., observation points, ambush positions, choke

points)- Location of convoy- No visible enemy or enemy activity

◦ SASS reasoning output:- Assume enemy sniper. Keep convoy moving.

14 Arrive CFB Kanatahar (Map Location 10)

• Debrief Crew.

• Update Int Cell. Download intelligence captured by SASS.


List ofsymbols/abbreviations/acronyms/initialisms

ARP Applied Research ProjectAS Analyse de la situationASCAT Analyse de la situation pour le commandant

d’armée de terre tactiqueCAT Commandant d’armée tactiqueCS Conscience de la situationDBRT Directorat Besoins en ressources terreDL Description LogicDLCSPM Directorate Land Command Systems Program ManagementDLR Directorate of Land RequirementsDRDC Defence Research and Development CanadaE-R Entity-RelationshipELINT Electronic Signals IntelligenceEM ElectromagneticFOB Forward Observation BaseFOL First-Order LogicHUMINT Human IntelligenceJC3IEDM Joint Consultation Command and Control

Information Exchange Data ModelKRM Knowledge Representation MechanismKR Knowledge RepresentationMOS Military Operational ScenarioNATO North Atlantic Treaty OrganizationODB Operational DataBaseOWL Web Ontology LanguagePDT Projet de démonstration technologiquePRA Projet de recherche appliquéeR&D Research and DevelopmentRDDC Recherche et développement pour la défense CanadaSA Situation AnalysisSAR Situation Analysis RequirementSASS Situation Analysis Support SystemSAW Situation AwarenessSATAC Situation Analysis for the Tactical Army CommanderSIGINT Signals IntelligenceSME Subject-Matter ExpertSTANAG Standard NATO AgreementTAC Tactical Army Commander


TDP Technical Demonstration ProgramUML Unified Modeling LanguageWWF Windows Workflow FoundationXML Extended Markup Language


DOCUMENT CONTROL DATA(Security classification of title, body of abstract and indexing annotation must be entered when document is classified)

1. ORIGINATOR (The name and address of the organization preparing thedocument. Organizations for whom the document was prepared, e.g. Centresponsoring a contractor’s report, or tasking agency, are entered in section 8.)

Defence R&D Canada – Valcartier2459 Pie-XI Blvd. North, Québec QC G3J 1X5,Canada

2. SECURITY CLASSIFICATION (Overallsecurity classification of the documentincluding special warning terms if applicable.)

UNCLASSIFIED

3. TITLE (The complete document title as indicated on the title page. Its classification should be indicated by the appropriateabbreviation (S, C or U) in parentheses after the title.)

Situation Analysis for the Tactical Army Commander: Final report

4. AUTHORS (Last name, followed by initials – ranks, titles, etc. not to be used.)

Dorion, É.; Bergeron Guyard, A.

5. DATE OF PUBLICATION (Month and year of publication ofdocument.)

May 2011

6a. NO. OF PAGES (Totalcontaining information.Include Annexes,Appendices, etc.)

46

6b. NO. OF REFS (Totalcited in document.)

20

7. DESCRIPTIVE NOTES (The category of the document, e.g. technical report, technical note or memorandum. If appropriate, enterthe type of report, e.g. interim, progress, summary, annual or final. Give the inclusive dates when a specific reporting period iscovered.)

Technical Report

8. SPONSORING ACTIVITY (The name of the department project office or laboratory sponsoring the research and development –include address.)

Defence R&D Canada – Valcartier2459 Pie-XI Blvd. North, Québec QC G3J 1X5, Canada

9a. PROJECT OR GRANT NO. (If appropriate, the applicableresearch and development project or grant number underwhich the document was written. Please specify whetherproject or grant.)

12of

9b. CONTRACT NO. (If appropriate, the applicable number underwhich the document was written.)

10a. ORIGINATOR’S DOCUMENT NUMBER (The officialdocument number by which the document is identified by theoriginating activity. This number must be unique to thisdocument.)

DRDC Valcartier TR 2010-174

10b. OTHER DOCUMENT NO(s). (Any other numbers which maybe assigned this document either by the originator or by thesponsor.)

11. DOCUMENT AVAILABILITY (Any limitations on further dissemination of the document, other than those imposed by securityclassification.)( X ) Unlimited distribution( ) Defence departments and defence contractors; further distribution only as approved( ) Defence departments and Canadian defence contractors; further distribution only as approved( ) Government departments and agencies; further distribution only as approved( ) Defence departments; further distribution only as approved( ) Other (please specify):

12. DOCUMENT ANNOUNCEMENT (Any limitation to the bibliographic announcement of this document. This will normally correspondto the Document Availability (11). However, where further distribution (beyond the audience specified in (11)) is possible, a widerannouncement audience may be selected.)

Unlimited

13. ABSTRACT (A brief and factual summary of the document. It may also appear elsewhere in the body of the document itself. It is highlydesirable that the abstract of classified documents be unclassified. Each paragraph of the abstract shall begin with an indication of thesecurity classification of the information in the paragraph (unless the document itself is unclassified) represented as (S), (C), or (U). It isnot necessary to include here abstracts in both official languages unless the text is bilingual.)

Between 2003 and 2009, Defence Research & Development Canada (DRDC) conducted the Ap-plied Research Project (ARP) 12of named Situation Analysis for the Tactical Army Commander(SATAC). The focus of this project was to reflect on the possibility to use automated reasoningtechniques and tools on top of the Joint Consultation Command and Control Information Ex-change Data Model (JC3IEDM). This data model is the ontology used by the Land Forces intheir command and control software applications.

The project produced a number of scientific publications, contract reports, a software prototypeand recommendations to the Land Forces. This report summarizes the findings that were made,which are further explained in the affiliated project deliverables.

14. KEYWORDS, DESCRIPTORS or IDENTIFIERS (Technically meaningful terms or short phrases that characterize a document and couldbe helpful in cataloguing the document. They should be selected so that no security classification is required. Identifiers, such asequipment model designation, trade name, military project code name, geographic location may also be included. If possible keywordsshould be selected from a published thesaurus. e.g. Thesaurus of Engineering and Scientific Terms (TEST) and that thesaurus identified.If it is not possible to select indexing terms which are Unclassified, the classification of each should be indicated as with the title.)

Knowledge Representation Automated Reasoning Cognitive Engineering Ontology JC3IEDM

Canada’s Leader in Defenceand National Security

Science and Technology

Chef de file au Canada en matièrede science et de technologie pourla défense et la sécurité nationale

www.drdc-rddc.gc.ca

Defence R&D Canada R & D pour la défense Canada

Situation Analysis for the Tactical Army Commander · 2012-08-03 · Situation Analysis for the...

Documents

Transcript of Situation Analysis for the Tactical Army Commander · 2012-08-03 · Situation Analysis for the...