Managing Command and Control Information Using a C2IEDM Based - - PowerPoint PPT Presentation

managing command and control information using a c2iedm
SMART_READER_LITE
LIVE PREVIEW

Managing Command and Control Information Using a C2IEDM Based - - PowerPoint PPT Presentation

Managing Command and Control Information Using a C2IEDM Based Tasking Grammar Dr. Michael Hieb C4I Center George Mason University mhieb@gmu.edu Content 1. Battle Management Language 2. The need for a C2 Grammar 3. A BML Tasking Grammar 4.


slide-1
SLIDE 1

Managing Command and Control Information Using a C2IEDM Based Tasking Grammar

  • Dr. Michael Hieb

C4I Center mhieb@gmu.edu George Mason University

slide-2
SLIDE 2

Content

  • 1. Battle Management Language
  • 2. The need for a C2 Grammar
  • 3. A BML Tasking Grammar
  • 4. Illustration by Example
  • 5. Conclusion
slide-3
SLIDE 3

Definition

BML is an unambiguous language used for the command and control

  • f forces and equipment conducting military operations.

BML is being developed as a standard representation of digitized C2 information for executable plans, orders, requests and reports

Simulation Systems Robotic Forces C2 Systems C2 Systems

Battle Management Language

  • for military units,
  • for simulated forces, and
  • for future robotic forces.
slide-4
SLIDE 4

Battle Management Language Representations

Division attacks on order in zone to seize OBJ SLAM. Division Mission Form of maneuver: Penetration Main effort: BLUE-MECH-BDE2,

  • n order BLUE-ARMOR-BDE1

Supporting effort: BLUE-MECH-BDE1 BLUE-ARMOR-BN1 Deep: None Reserve: BLUE-AVN-BDE1 Security: BLUE-CAV-SQN1 Tactical Combat Force: BLUE-MECH-TM1 Division Concept of Operations Tasks to Subordinates

Protect (Division Rear Area) DSA On order Tactical Combat Force BLUE-MECH-TM1 Protect (Division left flank) Zone (PL AMBER to PL BLUE) On order Screen BLUE-CAV-SQN1 Support (B-A-BDE1) Zone On order Follow and Support (B-A- BDE1) BLUE-ARMOR-BN1 Reserve AA EAGLE On order Occupy BLUE-AVN-BDE Seize (OBJ SLAM) Zone On order Follows and Assumes (B-M- BDE2) BLUE-ARMOR-BDE1 Penetrate (MRR2) Zone On order Attacks BLUE-MECH-BDE2 Fix (MRR1) Zone On order Attacks BLUE-MECH-BDE1 Why Where When What Who

slide-5
SLIDE 5

US Army BML Proof of Principle

BML GUI CAPES OTB C4ISI

XML – BML Parser

BML acts as the common denominator

Multi-Source Database Augmented with BML

slide-6
SLIDE 6

Limited Demonstration of BML to NATO

  • Objectives
  • Demonstrate the feasibility of a generic interface standard between C2 and

M&S-type systems

  • Show limitations of current standards that must be addressed by the BML

Working Group MSG-048

  • Build experience to help structure the Technical Research Program
  • Demonstration Architecture

C2IEDM Augmented with APLET BML

C2IEDM C2IEDM+

+ Database

Database

CAPES

COA Definition APLET

Simulation

JSAF

Simulation Push CoA Pull CoA Push CoA

BML Web services

Battle Management Language

slide-7
SLIDE 7

Command and Control Systems Modeling and Simulation Systems

C2 Domain Language(s) JC3IEDM

Peacekeeping BML Logistics BML Air BML geoBML Maritime BML Ground BML

Battle Management Language

slide-8
SLIDE 8

The Command and Control Information Data Exchange Model (C2IEDM) provides a standard Command and Control Vocabulary. Battle Management Language

OBJECT-TYPE OBJECT-ITEM ORGANIZATION -TYPE MATERIAL-TYPE PERSON -TYPE FACILITY-TYPE FEATURE-TYPE ORGANIZATION MATERIAL PERSON FACILITY FEATURE

C2IEDM implements the principles

  • f object-oriented programming

– Generalization and Specialization – Inheritance of common attributes

New Information can be modeled by extending existing knowledge

slide-9
SLIDE 9

C2IEDM – yet another data model?

  • C2IEDM was designed to support the unambiguous definition of

information exchange requirements in the operational domain.

  • The contributions of data modeling experts as well as operational

experts and users from more than 20 countries over more than 15 years ensure technical maturity and operational applicability based on mutual agreement and multilateral consensus.

  • This makes the C2IEDM unique in the technical as well as the
  • perational domain. Every recommended alternative must be

measured against these criteria and achievements.

  • Army Deputy Chief of Staff G3/5/7 mandated the use of C2IEDM

for Battle Command and M&S interfaces (Memo 28 Sep 2005).

Battle Management Language

slide-10
SLIDE 10

Definition

The vocabulary must be well defined in the context of operations within an application domain to facilitate the generation of unambiguous executable tasks. BML must use a rigorous data standard so that underlying information systems (M&S or C2 Systems) can both exchange information, and facilitate coherent results and support automated reasoning. Therefore, it is desirable that BML implementations use the Multilateral Interoperability Programme (MIP) data model, the C2IEDM. BML vocabulary: C2IEDM / JC3IEDM

Battle Management Language

slide-11
SLIDE 11

There is no “Formal” Language for Military Orders and Reports.

  • In order to communicate one needs a language.
  • A language needs a vocabulary.
  • It also needs a grammar (to concatenate the lexical items)

and give meaning to the catenation.

The need for a C2 Grammar

slide-12
SLIDE 12
  • In order to communicate one needs a language.
  • A language needs a vocabulary.

The vocabulary is provided by the C2IEDM.

  • The C2IEDM is not enough. (It is not a language).
  • A language also needs a grammar.

The need for a C2 Grammar

slide-13
SLIDE 13
  • In order to communicate one needs a language.
  • A language needs a vocabulary.
  • The C2IEDM is not enough. (It is not a language).
  • A language also needs a grammar.

The need for a C2 Grammar

slide-14
SLIDE 14

The C2IEDM is not enough.

  • Military communications (orders, reports)

are not “formally” represented in the C2IEDM. ⇒ Doctrine is not carried through

when communicating through C2IEDM. However, this problem might be solved in future versions.

The need for a C2 Grammar

slide-15
SLIDE 15

However, the C2IEDM is not a language. It does not give enough meaning

  • to orders, requests, reports
  • or more generally - to the tasks.

The need for a C2 Grammar

slide-16
SLIDE 16

Tasks are listed and verbally defined in the C2IEDM table “action-task-category-code” Example: advance In C2IEDM, version 6.1.5e, its meaning is given as: “To move forward towards an objective in some form of tactical formation. This is a transitional phrase between operations which may or may not result in contact with the enemy.” This meaning is for humans, not for machines.

The need for a C2 Grammar

slide-17
SLIDE 17

action-task advance

  • rganisation-

action-association

  • Unit1

In the C2IEDM, structure is provided but grammar is missing … “Advance from assembly area Alpha to phase line Tulip!”

action-resource

  • Unit2
  • Route
  • Destination

action-objective

= Sender part of = Receiver

  • bligatory for “advance”

The need for a C2 Grammar

slide-18
SLIDE 18
  • In order to communicate one needs a language.
  • A language needs a vocabulary.
  • The C2IEDM is not enough. (It is not a language).
  • A language also needs a grammar.

The need for a C2 Grammar

slide-19
SLIDE 19

The functionality of a grammar includes the following three aspects:

  • Assign the appropriate structure to language expressions.
  • Provide the set of structures

that are valid for expressions of the language.

  • Determine how to calculate the meaning of an expression

from the meaning of its parts.

The need for a C2 Grammar

slide-20
SLIDE 20

Development of a Formal BML Grammar

What kind of Grammar do we want ? What properties should the Grammar have ?

  • Its vocabulary is based on the C2IEDM.
  • It respects “constituency” as inspired by the 5Ws

but reaches beyond.

  • It grants the calculability of concatenated meaning.
  • It is lexical-driven.
slide-21
SLIDE 21

Development of a Formal BML Grammar

What kind of Grammar do we want ? What properties should the Grammar have ?

  • Its vocabulary is based on the C2IEDM.
  • It respects “constituency” as inspired by the 5Ws

but reaches beyond.

  • It grants the calculability of concatenated meaning.
  • It is lexical-driven.
slide-22
SLIDE 22

Development of a Formal BML Grammar

What kind of Grammar do we want ? What properties should the Grammar have ?

  • Its vocabulary is based on the C2IEDM.
  • It respects “constituency” as inspired by the 5Ws

but reaches beyond.

  • It grants the calculability of concatenated meaning.
  • It is lexical-driven.
slide-23
SLIDE 23

Development of a Formal BML Grammar

What kind of Grammar do we want ? What properties should the Grammar have ?

  • Its vocabulary is based on the C2IEDM.
  • It respects “constituency” as inspired by the 5Ws

but reaches beyond.

  • It grants the calculability of concatenated meaning.
  • It is lexical-driven.
slide-24
SLIDE 24

Development of a Formal BML Grammar

What kind of Grammar do we want ? In linguistics, there four predominate phrase structure grammars:

  • Government-binding Theory (GB)
  • General Phrase Structure Grammar (GPSG)
  • Head-Driven Phrase Structure Grammar (HPSG)
  • Lexical Functional Grammar (LFG)
slide-25
SLIDE 25

Development of a Formal BML Grammar What kind of Grammar do we want ? Lexical Functional Grammar (LFG) has all the properties we asked for. Thus, our BML Grammar is designed as a LFG variant.

slide-26
SLIDE 26

Development of a Formal BML Grammar

LFG-References

Basic:

  • Kaplan, R.M. and Bresnan, J. (1982). Lexical-Functional

Grammar: A formal system for grammatical representation.

In: Bresnan, J. (Ed.), The Mental Representation of Grammatical Relations. Cambridge, MA: MIT Press. Reprinted in: Dalrymple, M., Kaplan, R.M., and Maxwell III, J.T. (Eds.), Formal Issues in Lexical-Functional Grammar. Stanford, CA: CSLI, 1995.

Advanced:

  • Bresnan, J. (2001). Lexical Functional Syntax. Malden,

MA: Blackwell.

slide-27
SLIDE 27

A BML Tasking Grammar

The production rules for the basic expressions have the following general form: B → Verb Tasker Taskee (Affected | Action) Where Start-When (End-When) Why Label (Mod)* “Verb” is an action, normally a task; “Tasker” is a “Who”, the unit which commands the task; “Taskee” is a “Who”, the unit which executes the task; “Affected” is a “Who”, the unit which is affected by the task; “Action” is another action/task affected by the task;

slide-28
SLIDE 28

A BML Tasking Grammar

The production rules for basic expressions have the following general form: B → Verb Tasker Taskee (Affected | Action) Where Start-When (End-When) Why Label (Mod)* “Where” is a “location phrase”; the “When”s are “time phrases”; “Why” is a terminal symbol giving the purpose of the action; “Label” is a label given to the task in order allow it to be referred in other basic expressions.

slide-29
SLIDE 29

A BML Tasking Grammar

The production rules for basic expressions have the following general form: B → Verb Tasker Taskee (Affected | Action) Where Start-When (End-When) Why Label (Mod)* Whether there is “Affected” or “Action” is determined by the verb. This is indicated by the round brackets. The Verb also determines the kind of Where (At-Where or Route-Where) to be used.

slide-30
SLIDE 30

A BML Tasking Grammar

Rules for basic expressions (examples)

(“verbs” are taken from LC2IEDM-table “action-task-category-code”)

B → advance Tasker Taskee Route-Where Start-When (End-When) Why Label B → ambush Tasker Taskee Affected At-Where Start-When (End-When) Why Label B → assist Tasker Taskee Action At-Where Start-When (End-When) Why Label B → attack Tasker Taskee Affected Route-Where Start-When (End-When) Why Label B → block Tasker Taskee Affected At-Where Start-When (End-When) Why Label B → defend Tasker Taskee (Affect.) Route-Where Start-When (End-When) Why Label

Rules for constituents (examples)

Start-When → start Qualifier1 Point_in_Time Start-When → start Qualifier2 Action Qualifier1 → { AFT, ASAP, ASAPNL, ASAPNL, AT, BEF, NLT, NOB }

(“qualifier terms” are taken from C2IEDM-table “action-task-start-qualifier-code”)

slide-31
SLIDE 31

Illustration by Example

Example: MIP-Exercise, Ede, NL, Nov. 2003 Extract of an (Section 3b) by MND-West (SP) to 13 NL MECH BDE: PH 1a: Fast Tactical March to PL TULIP by ROUTE DUCK. PH 1b: Defense in depth sector EAST, blocking penetration ALFA. PH 1c: Assist the rearward passage of the 12 (SP) CAV. RGT. PH 2: On order attack in direction ECHO. PH 3: Be prepared to conduct peace support ops along the border within boundaries.

slide-32
SLIDE 32

Illustration by Example

Translation to BML march MND-West(SP) MECH_BDE13(NL) along DUCK start nlt phase1a label_3_11; defend MND-West(SP) MECH_BDE13(NL) at EAST start nlt phase1b label_3_12; block MND-West(SP) MECH_BDE13(NL) MIR320(ZB) at TULIP start nlt phase1b label_3_13; assist MND-West(SP) MECH_BDE13(NL) label_3_57 at EAST start nlt phase1c label_3_14; withdraw MND-West(SP) CAV_REG12(SP) to EAST start nlt phase1c label_3_57;

slide-33
SLIDE 33

Conclusion We need a grammar such that not only humans can “understand” BML, but such that modern Information Technology systems can understand it as well. Such a grammar can be rigorously defined according to standard Linguistic principles for generation of, validation of and processing of Command and Control Information.

slide-34
SLIDE 34

Thanks for Your Attention ! Questions and Comments are appreciated.