Integrated Battle Management Language Physical Data Model ...c4i.gmu.edu/pdfs/BML_Arch/IBML OPORD SV-11... · JC3IEDM Edition 3_0_2 dated 20090715. [2]. The descriptions of these

1 December 2009

Integrated Battle Management Language

Physical Data Model for US JC3IEDM Extensions

Draft

Project Number: AV-1 006

Prepared by:

Office of the Army Chief Information Officer Architecture, Operations, Networks and Space Mission

Army Net-Centric Data Strategy Branch Arlington, VA 22202

and

CECOM Life Cycle Management Command

Software Engineering Center Fort Monmouth, NJ 07703-5207

IBML Operations Order Draft DoDAFSystem View-11 1 December 2009

ANCDS i

Revision History

Revision Date Description of Change


ANCDS ii

TABLE OF CONTENTS

1 Introduction ........................................................................................................................... 1

1.1 PURPOSE .............................................................................................................................. 1 1.2 SCOPE .................................................................................................................................. 1 1.3 OBJECTIVE............................................................................................................................ 1 1.4 INTENDED AUDIENCES ........................................................................................................... 1

2 References............................................................................................................................. 2

2.1 GENERAL REFERENCES......................................................................................................... 2 2.2 MILITARY REFERENCES ......................................................................................................... 3

3 Definitions ............................................................................................................................. 4

4 Acronyms and Abbreviations.............................................................................................. 5

5 DoDAF Systems View – 11 .................................................................................................. 6

5.1 OVERVIEW............................................................................................................................. 6 5.2 DODAF SYSTEMS VIEW – 11 REPRESENTATION.................................................................... 6 5.2.1 NOTATION .......................................................................................................................... 6 5.2.2 COLORING OF EXTENSIONS ................................................................................................ 6

6. Description of IBML OPORD Extensions Accepted to US JC3IEDM .............................. 7

6.1 ACTION-MANOEUVRE-EMPLOYMENT EXTENSION.......................................................... 7 6.1.1 DESCRIPTION ..................................................................................................................... 7 6.1.2 IMPLEMENTATION ............................................................................................................... 7 6.1.3 ADDITIONAL TABLE ............................................................................................................ 7 6.1.3.1 ATTRIBUTES.................................................................................................................... 7 6.1.4 AMENDMENT ...................................................................................................................... 9 6.1.5 PHYSICAL DATA MODEL REPRESENTATION IN IDEF1X NOTATION..................................... 10 6.2 HEADER CODES EXTENSION ................................................................................................ 10 6.2.1 DESCRIPTION ................................................................................................................... 10 6.2.2 IMPLEMENTATION ............................................................................................................. 11 6.2.3 ADDITIONAL ATTRIBUTE ................................................................................................... 11 6.2.4 AMENDMENT .................................................................................................................... 14 6.2.5 PHYSICAL DATA MODEL REPRESENTATION IN IDEF1X...................................................... 14 6.3 LOCATION OF ISSUE EXTENSION .......................................................................................... 14 6.3.1 DESCRIPTION ................................................................................................................... 14 6.3.2 IMPLEMENTATION ............................................................................................................. 14


ANCDS iii

6.3.3 ADDITIONAL ATTRIBUTES AND RELATIONSHIP ................................................................... 14 6.3.4 AMENDMENT .................................................................................................................... 14 6.3.5 PHYSICAL DATA MODEL REPRESENTATION IN IDEF1X...................................................... 15 6.4 MAP EXTENSION.................................................................................................................. 15 6.4.1 DESCRIPTION ................................................................................................................... 15 6.4.2 IMPLEMENTATION ............................................................................................................. 15 6.4.3 ADDITIONAL TABLE .......................................................................................................... 15 6.4.3.1 ATTRIBUTES.................................................................................................................. 16 6.4.4 AMENDMENT .................................................................................................................... 17 6.4.5 PHYSICAL DATA MODEL REPRESENTATION IN IDEF1X...................................................... 17

7. Description of Additional IBML OPORD Extensions ...................................................... 19

7.1 WHAT CODES EXTENSION ................................................................................................... 19 7.1.1 DESCRIPTION ................................................................................................................... 19 7.1.2 IMPLEMENTATION ............................................................................................................. 19 7.1.3 ADDITIONAL TABLE .......................................................................................................... 19 7.1.4 AMENDMENT .................................................................................................................... 19 7.1.5 PHYSICAL DATA MODEL REPRESENTATION IN IDEF1X...................................................... 19 7.2 WHY CODES EXTENSION ..................................................................................................... 20 7.2.1 DESCRIPTION ................................................................................................................... 20 7.2.2 IMPLEMENTATION ............................................................................................................. 20 7.2.3 ADDITIONAL TABLE .......................................................................................................... 20 7.2.4 AMENDMENT .................................................................................................................... 20 7.2.5 PHYSICAL DATA MODEL REPRESENTATION IN IDEF1X...................................................... 21

Appendix A: Enumerations Added to actv_code ................................................................ A-1

Appendix B: Enumerations Added to descr_code .............................................................. B-1

Appendix C: Additional recommended extensions to US-JC3IEDM C-1


ANCDS iv

TABLE OF FIGURES

Figure 6.1-1. IDEF1X Physical Data Model of ACTION-MANOEUVRE-EMPLOYMENT Extension ................................................................................................................................... 10 Figure 6.2-1. IDEF1X Physical Data Model of Header Codes Extension ................................. 14 Figure 6.3-1. IDEF1X Physical Data Model of Location of Issue Extension ..............................15 Figure 6.4-1. IDEF1X Physical Data Model of Map Extension .................................................. 18 Figure 7.1-1. IDEF1X Physical Data Model of What Codes Extension ..................................... 20 Figure 7.2-1. IDEF1X Physical Data Model of Why Codes Extension ...................................... 21

TABLE OF TABLES

Table 4-1. Acronyms and Abbreviations ..................................................................................... 5 Table 6.1-1. Domain of frmtn _code of ACT_MNVE_EMPLOY Table ........................................ 7 Table 6.1-2. Domain of frmtn _modfr_code of ACT_MNVE_EMPLOY Table ............................. 9 Table 6.1-3. Details of Attributes for ACT_MNVE_EMPLOY Table ............................................ 9 Table 6.1.4 Enumeration Added to cat_code of ACT_RES_EMPLOY Table ............................ 9 Table 6.2-1. Domain of topic_code of CMPNT_HDR_CNTNT Table .........................................11 Table 6.4-1. Domain of scale_code of MAP Table .................................................................... 16 Table 6.4-2. Domain of grid_sys_use_code of MAP Table ....................................................... 16 Table 6.4-3. Details of Attributes for MAP Table ....................................................................... 17 Table 6.4-4. Enumeration Added to cat_code of REF Table ..................................................... 17

IBML Operations Order Draft DoDAF System View-11 1 December 2009

ANCDS 1

1 Introduction The Army Integrated Battle Management Language (IBML) Architecture effort involves providing an enterprise wide infrastructure for the integration of the many activities developing Army, Joint, or Coalition capabilities for the Battle Management Language (BML). BML is defined as the unambiguous language used to command and control forces and equipment conducting military operations and to provide for situational awareness and a shared, common operational picture. The goal is to enhance and enable Army Battle Command Systems (ABCS) capabilities to align with emerging concepts of the Unified Battle Command (UBC) strategy as follows: create a clear, unambiguous language that supports communications between humans, automated systems and future robotic forces; improve commander and battle staff training on ABCS by reducing the training “overhead;” and facilitate planning and decision support using automated Command and Control (C2) tools. BML is being developed as a standard representation of digitized C2 information for executable plans, orders, requests and reports. It will allow a commander to develop a plan and exchange data with other organizations via digitized C2 systems as well as provide direct interaction with supporting models and simulations.

1.1 Purpose The purpose of this document is to describe the United States (US) Joint Consultation, Command and Control Information Exchange Data Model (JC3IEDM) extensions required to represent the IBML data model. The description focuses on the US JC3IEDM extensions associated with the IBML Operations Order (OPORD) schema. The document presents the systems view of these extensions to include data requirements and business rules in accordance with the Department of Defense Architecture Framework (DoDAF) Systems View – 11 (SV-11). This document is the sixth in a series of related documents [12][13][14][15][16] that together provide a consistent, detailed description of the Army IBML Architecture and its components. The completed set of documentation will be used to aid a user in understanding the Army IBML Architecture and integrating a BML capability into a system/program.

1.2 Scope Two types of extensions are presented in this document. The first type includes the extensions that have been formally submitted to the US JC3IEDM C2 Interoperability Group (CIG) Technical Working Group (TWG) by generating a CIG change proposal, accepted by the CIG, and incorporated into release US-JC3IEDM Edition 3_0_2 dated 20090715. [2]. The descriptions of these extensions are found in Section 6. The second type of extensions involves those not formally proposed to the CIG TWG, but rather implemented locally in a demonstration environment used as a proof of concept prototype. These extensions are found in Section 7. In both cases, the description of each extension includes the required additional entities, attributes, and relationships; amendments to existing entities and attributes; and representation of the extension in the Entity Relationship (ER) notation.

1.3 Objective The main objective of this product is to provide information that aids a user in understanding the IBML extensions to the US JC3IEDM.

1.4 Intended Audiences The primary audiences for this document are the Command, Control, Communications, Computers, and Intelligence (C4I) development, simulation, doctrine, training, and operational communities. Other communities of interest, although not the intended primary audience, are encouraged to leverage the SV-11 information describing the IBML OPORD extensions for use in their domains.


ANCDS 2

2 References

2.1 General References [1] Carey, S., Kleiner, M., Hieb, M.R. and Brown, R., “Standardizing Battle Management Language – A Vital Move Towards the Army Transformation”, Paper 01F-SIW-067, Fall Simulation Interoperability Workshop, 2001.

[2] Command and Control (C2) Interoperability Working Group (CIG), US-JC3IEDM Edition 3_0_2, 15 July 2009.

[3] Defense Information Systems Agency, Department of Defense, MIL-STD-2525B, “Common Warfighting Symbology,” 30 January 1999, w/Change 1, 1 July 2005.

[4] “Department of Defense Architecture Framework,” Version 1.5, 23 April 2007.

[5] “Department of Defense (DoD) Dictionary of Military and Associated Terms,” 12 April 2001, As Amended Through 17 October 2008.

[6] Federal Information Processing Standards Publication 184, “Integrated Definition for Information Modeling (IDEF1X),” 21 December 1993.

[7] Hieb, M., Mackay, S., Powers, M., Kleiner, M., and Pullen, J., “The Environment in Network Centric Operations: A Framework for Command and Control,” 12th International Command and Control Research and Technology Symposium, Newport, Rhode Island, 2007.

[8] Joint Consultation, Command and Control Information Exchange Data Model, “JC3IEDM-Annex B-Entities-GBR-DMWG,” Edition 3.1b, 13 December 2007.

[9] Joint Consultation, Command and Control Information Exchange Data Model, “JC3IEDM-Annex C-Attributes-GBR-DMWG,” Edition 3.1b, 13 December 2007.

[10] Joint Consultation, Command and Control Information Exchange Data Model, “JC3IEDM-Annex E-Domains-GBR-DMWG,” Edition 3.1b, 13 December 2007.

[11] Levine, S., Pullen, J., Hieb, M., Pandolfo, C., Blais, C., Roberts, J., and Kearly, J., “Joint Battle Management Language (JBML) Phase 1 Development and Demonstration Results,” IEEE Fall Simulation Interoperability Workshop, Orlando, Florida, 2007.

[12] Office of the Army Chief Information Officer, Architecture, Operations, Networks and Space Mission Army Net-Centric Data Strategy Branch and CECOM Life Cycle Management Command Software Engineering Center, “Integrated Battle Management Language Operations Order Schema Specification,” Version 1.0 Draft, 31 May 2009.

[13] Office of the Army Chief Information Officer, Architecture, Operations, Networks and Space Mission Army Net-Centric Data Strategy Branch and CECOM Life Cycle Management Command Software Engineering Center, “Integrated Battle Management Language (IBML) Architecture IBML Operations Order Schema V1.0a Mapping to US JC3IEDM,” Draft, 30 June 2009.

[14] Office of the Army Chief Information Officer, Architecture, Operations, Networks and Space Mission Army Net-Centric Data Strategy Branch and CECOM Life Cycle Management Command Software Engineering Center, “Integrated Battle Management Language (IBML) Architecture Department of Defense Architecture Framework (DoDAF) Operational View-7 (OV-7),” Version 1.0, 2 October 2009.

[15] Office of the Army Chief Information Officer, Architecture, Operations, Networks and Space Mission Army Net-Centric Data Strategy Branch and CECOM Life Cycle Management Command Software Engineering Center, “Integrated Battle Management Language (IBML) Architecture Department of Defense Architecture Framework (DoDAF) Technical View-1 (TV-1),” Version 1.0, 10 April 2009.

[16] Office of the Army Chief Information Officer, Architecture, Operations, Networks and Space Mission Army Net-Centric Data Strategy Branch and CECOM Life Cycle Management Command Software Engineering Center, “Integrated Battle Management Language (IBML) Architecture IBML Operations Order Web Service Specification,” 28 July 2009.


ANCDS 3

[17] United States National Imagery and Mapping Agency (NIMA). TR 8350.2, “Department of Defense Word Geodetic System 1984 - Its Definition and Relationships with Local Geodetic Systems,” Third Edition, Amendment 1. Washington, D.C., NIMA, 3 January 2000. ftp://164.214.2.65/pub/gig/tr8350.2/wgs84fin.pdf.

[18] US-0805-001-JC3IEDM Change Proposal, “Location of Issue,” 28 May 2008.

[19] US-0805-002-JC3IEDM Change Proposal, “Map,” 29 May 2008.

[20] US-0806-001-JC3IEDM Change Proposal, “ACTION-MANOEUVRE-EMPLOYMENT,” 10 July 2008.

[21] US-JC3-09-010 Change Proposal, “Header Codes,” 5 January 2009.

2.2 Military References [FM 3-90] Headquarters, Department of the Army, Washington, DC, “Field Manual (FM) 3-90, Tactics,” posted 13 January 2006.

[FM 7-15] Headquarters, Department of the Army, Washington, DC, “Field Manual (FM) 7-15, The Army Universal Task List,” posted 13 January 2006.

[FM 100-25] Headquarters, Department of the Army, Washington, DC, “Field Manual (FM) 100-25, Doctrine for Army Special Operations Forces,” posted 12 January 2006.

[FM 3-0] Headquarters, Department of the Army, Washington, DC, “Field Manual (FM) 3-0, Operations,” posted 12 January 2006.

[FM 100-9] Headquarters, Department of the Army, Washington, DC, “Field Manual (FM) 100-9, Reconstitution,” posted 13 January 2006.

[ARTEP 7-32-MTP] Headquarters, Department of the Army, Washington, DC, “Army Training and Evaluation Program (ARTEP) 7-32 Mission Training Plan (MTP) for the Stryker Brigade Combat Team,” 11 July 2003.

[ARTEP 7-22-MTP] Headquarters, Department of the Army, Washington, DC, “Army Training and Evaluation Program (ARTEP) 7-22 Mission Training Plan (MTP) for the Stryker Brigade Combat Team Infantry Battalion,” 19 September 2003.

[ARTEP 7-12-MTP] Headquarters, Department of the Army, Washington, DC, “Army Training and Evaluation Program (ARTEP) 7-12 Mission Training Plan (MTP) for the Stryker Brigade Combat Team Infantry Rifle Company,” 1 June 2003.

[ARTEP 17-95F-40-MTP] Headquarters, Department of the Army, Washington, DC, “Army Training and Evaluation Program (ARTEP) 17-95F-40 Mission Training Plan (MTP) for the Cavalry Squadron Reconnaissance, Surveillance, and Target Acquisition (RSTA),” 2 February 2004.

[ARTEP 17-97F-30-MTP] Headquarters, Department of the Army, Washington, DC, “Army Training and Evaluation Program (ARTEP) 17-97F-30 Mission Training Plan (MTP) for Brigade Reconnaissance Troop,” 2 December 2002.

[ARTEP 34-117-30-MTP] Headquarters, Department of the Army, Washington, DC, “Army Training and Evaluation Program (ARTEP) 34-117-30 Mission Training Plan (MTP) for the Surveillance Troop of the Stryker Brigade Combat Team,” 28 June 2005.


ANCDS 4

3 Definitions Integrated Battle Management Language (IBML) – A collection of shared and integrated products and specifications serving as a common foundation for the development and production of advanced C2 processes across BML stakeholders including orders, reports, and geospatial capabilities. Operations Order (OPORD) – a directive issued by a commander to subordinate commanders for the purpose of effecting the coordinated execution of an operation.


ANCDS 5

4 Acronyms and Abbreviations The acronyms and abbreviations used in this product are listed in Table 4-1.

Table 4-1. Acronyms and Abbreviations

ABCS Army Battle Command Systems

ARTEP Army Training and Evaluation Program

BML Battle Management Language

C2 Command and Control

C4I Command, Control, Communications and Intelligence

CA Civil Affairs

CCIR Commander’s Critical Information Requirements

CI Counterintelligence

CIG C2 Interoperability Group

DoD Department of Defense

DoDAF Department of Defense Architecture Framework

ER Entity Relationship

FM Field Manual

IBML Integrated Battle Management Language

IDEF1X Integration Definition for Information Modeling

JBML Joint Battle Command Language

JC3IEDM Joint Consultation, Command and Control Information Exchange Data Model

MTP Mission Training Plan

NBC Nuclear, Biological, Chemical

NIMA National Imagery and Mapping Agency

OPORD Operations Order

OPSEC Operations Security

OV - 7 Operational View – 7

PSYOP Psychological Operations

RSTA Reconnaissance, Surveillance, and Target Acquisition

SV-11 System View - 11

TV -1 Technical View – 1

TWG Technical Working Group

UBC Unified Battle Command

US United States


ANCDS 6

5 DoDAF Systems View - 11

5.1 Overview The DoDAF defines a set of products that act as mechanisms for visualizing, understanding, and assimilating the broad scope and complexities of an architecture description through graphic, tabular, or textual means. The SV-11 is one of the architecture products closest to actual system design. The SV-11 is an implementation-oriented physical data model that is used to describe how the information requirements represented in the Operational View – 7 (OV-7) are actually implemented. The SV-11 descriptions presented in Sections 6 and 7 have been developed based on DoDAF Version 1.5 [4].

5.2 DoDAF Systems View – 11 Representation

5.2.1 Notation The DoDAF SV-11 documentation presents a notation that can be used for representing the required information:

- ER representation of the physical data model design using Integration Definition for Information Modeling (IDEF1X) [6]

IDEF1X terminology and notation are used for the physical data model descriptions in Sections 6 and 7.

5.2.2 Coloring of Extensions Extension changes in the diagrams are indicated in blue as follows:

- New entities are shaded in blue.

- Amended entities are outlined in blue.


ANCDS 7

6. Description of IBML OPORD Extensions Accepted to US JC3IEDM The IBML OPORD extensions incorporated into the US JC3IEDM are described in Sections 6.1 to 6.4. The description for each extension includes the following subsections: - Description of the extension - Implementation of the extension - Description of additional table(s) - Detailed description of attribute(s) for additional table(s) - Description of amendments to existing tables/attributes/enumerations - ER representation of the extension as a physical data model using IDEF1X notation

6.1 ACTION-MANOEUVRE-EMPLOYMENT Extension The ACTION-MANOEUVRE-EMPLOYMENT extension [20] has been incorporated into release US-JC3IEDM Edition 3_0_2 dated 20090715. [2]

6.1.1 Description The ACTION-MANOEUVRE-EMPLOYMENT extension provides the capability of representing information related specifically to the formation to be used by the Maneuver elements.

6.1.2 Implementation The ACTION-MANOEUVRE-EMPLOYMENT extension implements the needed data requirement by adding a sub-table to the ACT_RES_EMPLOY table.

6.1.3 Additional Table The following table has been added:

- ACT_MNVE_EMPLOY. The procedure that guides the use of an ACTION-RESOURCE by a manoeuver unit.

6.1.3.1 Attributes The table includes the following attributes:

- act_id. The unique value, or set of characters, assigned to represent a specific ACTION and to distinguish it from all other ACTIONs.

- act_res_ix. The unique value, or set of characters, assigned to represent a specific ACTION-RESOURCE for a specific ACTION and to distinguish it from all other ACTION-RESOURCEs for that ACTION.

- act_res_employ_ix. The unique value, or set of characters, assigned to represent a specific ACTION-RESOURCE-EMPLOYMENT for a specific ACTION-RESOURCE and to distinguish it from all other ACTION-RESOURCE-EMPLOYMENTs for that ACTION-RESOURCE.

- frmtn_code. The specific value that represents the formation to be used. The domain of this code is shown in Table 6.1-1.

Table 6.1-1. Domain of frmtn_code of ACT_MNVE_EMPLOY Table

Value Definition Physical Value

Box A unit formation with subordinate elements arranged in a box or square, or two elements up and two elements back. It is a flexible formation that

BOX


ANCDS 8

provides equal firepower in all directions. It is generally used when the enemy location is known. This formation can cause 50 percent of force to be decisively engaged at the same time, therefore limiting the combat power available to manoeuvre against an enemy.

Coil An arrangement of vehicles forming a circle and providing 360-degree security in an assembly area with the primary weapon systems and protective armor facing outward.

COIL

Column A formation in which elements are placed one behind the other. COLUMN

Diamond A tactical or movement formation that is a variation of the box formation with one manoeuvre unit leading, manoeuvre units positioned on each flank, and the remaining manoeuvre unit to the rear.

DIMOND

Echelon A unit formation with subordinate elements arranged on an angle to the left or to the right of the direction of attack (echelon left, echelon right). This formation provides for firepower forward and to the flank of the direction of the echelon. It facilitates control in open areas. It provides minimal security to the opposite flank of the direction of the echeloning.

ECHLON

Herringbone An arrangement of vehicles at left and right angles to the line of march used to establish security during an unscheduled halt.

HRNGBN

Line An arrangement of vehicles or personnel in which elements are arranged abreast of each other. This formation permits maximum fire to front and rear and a minimum of fire to the flanks.

LINE

Platoon file This formation may be set up in several methods. One method is to have three-squad files follow one another using one of the movement techniques. Another method is to have a single platoon file with a front security element (point) and flank security elements. This formation is used when visibility is poor due to terrain, vegetation, or light conditions. The distance between soldiers is less than normal to allow communication by passing messages up and down the file.

PLTFIL

Vee This formation may be set up in several methods. One method is to have three-squad files follow one another using one of the movement techniques. Another method is to have a single platoon file with a front security element (point) and flank security elements. This formation is used when visibility is poor due to terrain, vegetation, or light conditions . The distance between soldiers is less than normal to allow communication by passing messages up and down the file.

VEE

Wedge This formation may be set up in several methods. One method is to have three-squad files follow one another using one of the movement techniques. Another method is to have a single platoon file with a front security element (point) and flank security elements. This formation is used when visibility is poor due to terrain, vegetation, or light conditions. The distance between soldiers is less than normal to allow communication by passing messages up and down the file.

WEDGE

Not otherwise specified

The appropriate value is not in the set of specified values. NOS

- frmtn_mdfr_code. The specific value that provides additional instructions how the units should arrange themselves in the specified formation. The domain of this code is shown in Table 6.1-2.


ANCDS 9

Table 6.1-2. Domain of frmtn_modfr_code of ACT_MNVE_EMPLOY Table


Left The formation is angled to the left of the direction of attack. (Used to provide additional instructions when frmtn_modfr_code contains value “Echelon.”)

LEFT

Right The formation is angled to the right of the direction of attack. (Used to provide additional instructions when frmtn_modfr_code contains value “Echelon.”)

RIGHT

Open The formation is characterized by vehicle intervals of 100 meters or more and speeds under 25 mph. (Used to provide additional instructions when frmtn_modfr_code contains value “Column.”)

OPEN

Close The formation is characterized by vehicle intervals of 25 to 50 meters and speeds under 25 mph. (Used to provide additional instructions when frmtn_modfr_code contains value “Column.”)

CLOSE

- creator_id. A value assigned to the row to identify the organization that created that row. This is referenced by an application level business rule to an OBJ_ITEM entry with a cat_code = OR and to a corresponding ORG subtype entry. (This attribute only exists in the physical model.)

- update_seqnr. An absolute sequence number assigned to represent the validity (in terms of seniority) of a certain data item. (This attribute only exists in the physical model.)

The details of the attributes for the ACT_MNVE_EMPLOY table are shown in Table 6.1-3.

Table 6.1-3. Details of Attributes for ACT_MNVE_EMPLOY Table

Attribute Name Data Type Null/Not Null Existence

act_id Foreign Key Not Null

act_res_ix Foreign Key Not Null

act_res_employ_ix Foreign Key Not Null

frmtn_code VARCHAR (6) Not Null Mandatory

frmtn_mdfr_code VARCHAR (6) Null Optional

creator_id Number (20) Not Null

update_seqnr Number (15) Not Null

6.1.4 Amendment Within the ACT_RES_EMPLOY table, the cat_code attribute has been amended by the addition of one additional enumeration as shown in Table 6.1-4.

Table 6.1-4. Enumeration Added to cat_code of ACT_RES_EMPLOY Table


ACTION-MANOEUVRE-EMPLOYMENT

The procedure that guides the use of an ACTION-RESOURCE for manoeuvre units.

MANEMP


ANCDS 10

6.1.5 Physical Data Model Representation in IDEF1X Notation The IDEF1X physical data model representation of the ACTION-MANOEUVRE-EMPLOYMENT extension is shown in Figure 6.1-1.

Figure 6.1-1 IDEF1X Physical Data Model of ACTION-MANOEUVRE-EMPLOYMENT Extension

6.2 Header Codes Extension The Header Codes extension [21] has been incorporated into release US-JC3IEDM Edition 3_0_2 dated 20090715. [2]

6.2.1 Description The Header Codes extension provides the capability of supporting Header Codes for the Plans and Orders structure of the model.


ANCDS 11

6.2.2 Implementation The Header Codes extension implements the needed data requirement by adding an attribute and the associated domain set to the CMPNT_HDR_CNTNT table.

6.2.3 Additional Attribute The following attribute has been added to the CMPNT_HDR_CNTNT table:

- topic_code. The specific value that represents a user-defined value in a specific CMPNT_HDR_CNTNT table. The topic_code is represented as VARCHAR(6) and is NOT NULL. The domain of topic_code is shown in Table 6.2-1,

Table 6.2-1. Domain of topic_code of CMPNT_HDR_CNTNT Table


Activities of special personnel Self defined. ACT

Administration/Logistics Self defined. ADMLOG

Air Defence Self defined. AD

As required Self defined. AR

Assumptions Self defined. ASSUM

Attachments and detachments Self defined. ATT

Authorization to the extent desired for direct liaison between commanders

Self defined. DIRLIA

Bypass criteria Self defined. BYPASS

Captured documents Self defined. CAPDOC

Captured materiel and associated technical documents Self defined. CAPMAT

Commander’s Critical Information Requirements (CCIR) Self defined. CCIR

Civil affairs (CA) guidance Self defined. CAGUID

Civil Military Self defined. CM

Civil Military cooperation Self defined. CMC

Classification and declassification guidance Self defined. CLASS

Code words or nicknames Self defined. CODE

Command and Signal Self defined. CMDSIG

Command, Control, and Communications Self defined. CCC

Command Self defined. CMD

Commander’s evaluation Self defined. EMDEVL

Commander’s intent (after execution before Concept of Operations) Self defined. CI

Concept of Operations Self defined. CO

Control measures Self defined. CM

Coordinating instructions Self defined. COI

Counterintelligence Self defined. CNTINT

Counterintelligence (CI) guidance Self defined. CIG


ANCDS 12

Deep unit(s) Self defined. DEEPUN

Distribution of special intelligence studies Self defined. DOSIS

Documents Self defined. DOC

Enemy forces Self defined. ENEMY

Enemy forces and battlefield conditions Self defined. ENEMBC

Engineer Self defined. ENG

Environmental considerations Self defined. ENVCON

Execution Self defined. EXEC

Fire support Self defined. FS

Fires Self defined. FIRES

Force protection Self defined. FRCPRO

Forward unit(s) Self defined. FWDUN

Friendly forces Self defined. FRIEND

Guidance Self defined. GUID

Information and Equipment requirements Self defined. INFEQP

Information operations Self defined. INFOOP

Intelligence Self defined. INTEL

Intelligence acquisition Self defined. INTELA

Intelligence acquisition tasks to subordinate units Self defined. INTELT

Known logistics constraints Self defined. KNWLOG

Known operational constraints Self defined. KNWOPR

Left flank unit(s) Self defined. LFUN

Manoeuvre Self defined. MANOV

Materiel and Services Self defined. MATSER

Medical evacuation and hospitalization Self defined. MEDEVC

Miscellaneous Self defined. MISC

Mission Self defined. MISS

Most dangerous course of action Self defined. MDCOA

Most probable course of action Self defined. MPCOA

Movement (including degree(s) of notice) Self defined. MVMNT

Nuclear, Biological, Chemical (NBC) Self defined. NBC

One level up Self defined. 1LVLUP

Operation Overlay Self defined. OPROVL

Operations security (OPSEC) and deception guidance Self defined. OPSEC

Orders group meeting (including location and attendees) Self defined. ORDGRP

Period to be covered by routine reports and distribution Self defined. PERRRD

Periodic or special conferences of intelligence officers Self defined. PERSCI


ANCDS 13

Personnel Self defined. PERSCI

Prisoners of War, Deserters, Repatriates, Refugees or Inhabitants, and Other Persons

Self defined. POWDES

Provost Marshal Self defined. PM

Psychological Operations (PSYOP) Self defined. PSYOP

Public affairs guidance Self defined. PAG

Rear Unit(s) Self defined. REARUN

Reconnaissance and surveillance Self defined. RECSUR

References Self defined. REF

Reporting instructions Self defined. RPTINS

Reports and distribution Self defined. RPTDST

Reserve unit(s) Self defined. RESUN

Right flank unit(s) Self defined. RFUN

Risk guidance Self defined. RSKGUD

Risk reduction control measures Self defined. RSKRED

Routine and special reports which differ from SOP Self defined. ROUSPR

Rules of engagement Self defined. ROE

Scheme of support Self defined. SCHSPT

Service support Self defined. SVCSPT

Signal Self defined. SIGNAL

Situation Self defined. SIT

SOP Self defined. SOP

Special intelligence liaison when indicated Self defined. SPCINT

Support concept Self defined. SPTCNC

Supporting commander coordination or monitoring instructions Self defined. SPTCDR

Task organization Self defined. TSKORG

Tasks/missions to combat support units Self defined. TSKCSU

Tasks/missions to manoeuvre units Self defined. TSKMU

Tentative execution timing for use in operation planning Self defined. TENTIM

Time or condition when a plan or order becomes effective Self defined. TIMEFF

Time Zone Self defined. TZ

Transportation Self defined. TRANS

Two levels up Self defined. 2LVLUP

Weather and Light data Self defined. WTHERL

Not otherwise specified The appropriate value is not in the set of specified values

NOS


ANCDS 14

6.2.4 Amendment No additional amendments were made to existing entities.

6.2.5 Physical Data Model Representation in IDEF1X The IDEF1X physical data model representation of the Header Codes extension is shown in Figure 6.2-1.

Figure 6.2-1. IDEF1X Physical Data Model of Header Codes Extension

6.3 Location of Issue Extension The Location of Issue extension [18] has been incorporated into release US-JC3IEDM Edition 3_0_2 dated 20090715. [2]

6.3.1 Description The Location of Issue extension provides the capability of identifying the location at which a particular Plan or Order was issued.

6.3.2 Implementation The Location of Issue extension is implemented by the addition of a relationship from the LOCATION table to the PLN_ORDER_HDR_CNTNT table to record the LOCATION of the UNIT at the time the PLAN-ORDER is issued.

6.3.3 Additional Attributes and Relationship The following attributes have been added to the PLN_ORDER_HDR_CNTNT:

- obj_item_id. The unique value, or set of characters, assigned to represent a specific OBJECT-ITEM and to distinguish it from all other OBJECT-ITEMs.

- loc_id. The unique value, or set of characters, assigned to represent a specific LOCATION and to distinguish it from all other LOCATIONs.

- obj_item_loc_ix. The unique value, or set of characters, assigned to represent a specific OBJECT-ITEM-LOCATION for a specific OBJECT-ITEM and a specific LOCATION and to distinguish it from all other OBJECT-ITEM-LOCATIONs for that OBJECT-ITEM and that LOCATION.

These attributes provide the means of establishing the required relationship to represent the Location of the Unit at the time of issue of the Plan or Order.

6.3.4 Amendment No additional amendments were made to existing entities.


ANCDS 15

6.3.5 Physical Data Model Representation in IDEF1X The IDEF1X physical data model representation of the Location of Issue extension is shown in Figure 6.3-1.

Figure 6.3-1. IDEF1X Physical Data Model of Location of Issue Extension

6.4 Map Extension The Map extension [19] has been incorporated into release US-JC3IEDM Edition 3_0_2 dated 20090715. [2]

6.4.1 Description The Map extension provides the capability of storing identifying information related specifically to maps.

6.4.2 Implementation The Map extension implements the needed data requirement by adding a sub-type under the REF table.

6.4.3 Additional Table The following table has been added:

- MAP. A REFERENCE that contains information describing both the physical and digital map.


ANCDS 16

6.4.3.1 Attributes The MAP table includes the following attributes:

- map_id. The ref_id of a specific Map.

- scale_code. The specific value that represents the scale of the physical map. The domain of this code is shown in Table 6.4-1.

Table 6.4-1. Domain of scale_code of MAP Table


1/10,000 The scale represented is 1/10,000th the distance on the ground 1






The appropriate value is not in the list of specified values NOS

- series_text. The character string assigned to represent the series of the Map.

- edition_text. The character string assigned to represent the edition of the Map.

- suffix_text. The character string assigned to represent the suffix of the Map.

- grid_sys_use_code. The specific value that represents the grid system used in the Map. The domain of this code is shown in Table 6.4-2.

Table 6.4-2. Domain of grid_sys_use_code of MAP Table


Military grid system reference system

A system which uses a standard-scaled grid square, based on a point of origin on a map projection of the surface of the Earth in an accurate and consistent manner to permit either position referencing or the computation of direction and distance between grid positions.

MGRS

Universal transverse mercator grid

A grid coordinate system based on the transverse mercator projection, applied to maps of the Earth’s surface extending to 84 degrees N and 80 degrees S latitudes.

UTM


The appropriate value is not in the set of specified values. NOS

Not known It is not possible to determine which value is most applicable. NKN

The details of the attributes for the MAP table are shown in Table 6.4-3.


ANCDS 17

Table 6.4-3. Details of Attributes for MAP Table

Attribute Name Data Type Null/Not Null Existence

ref_id NUMBER(20) Not Null

map_id NUMBER(20) Not Null

scale_code VARCHAR(6) Not Null

series_text VARCHAR(15) Null

edition_text VARCHAR(15) Null

suffix_text VARCHAR(15) Null

grid_sys_use_code VARCHAR(6) Null

6.4.4 Amendment Within the REF table, the cat_code attribute has been amended by the addition of one additional enumeration as shown in Table 6.4-3.

Table 6.4-4. Enumeration Added to cat_code of REF Table


MAP A REFERENCE that contains information to specify a physical or a digital Map.

MAP

6.4.5 Physical Data Model Representation in IDEF1X The IDEF1X physical data model representation of the Map extension is shown in Figure 6.4-1.


ANCDS 18

Figure 6.4-1. IDEF1X Physical Data Model of Map Extension


ANCDS 19

7. Description of Additional IBML OPORD Extensions The additional IBML OPORD extensions, implemented as part of the prototype demonstration environment but not yet formally proposed for inclusion in the US JC3IEDM, are described in Sections 7.1 to 7.2. The description for each extension includes the following subsections: - Description of the extension - Implementation of the extension - Description of additional table(s) - Description of attribute(s) for additional table(s) - Description of amendments to existing tables/attributes/enumerations - ER representation of the extension using IDEF1X physical data model notation

7.1 What Codes Extension For the implementation of the IBML OPORD, the existing set of what codes provided by the default US JC3IEDM was insufficient to properly characterize the required set of tasks that can potentially by executed by US Army forces. The purpose of this extension was therefore to add the necessary what codes to fulfill this requirement. The additional what codes were obtained from the various military references found in Section 2.2.

7.1.1 Description The What Codes Extension provides the capability of representing information related specifically to additional land operations tasks.

7.1.2 Implementation The What Codes extension implements the needed data requirement by amending the actv_code attribute of the ACT_TASK table by the inclusion of additional enumerations.

7.1.3 Additional Table No table has been added.

7.1.4 Amendment Within the ACT_TASK table, the actv_code attribute has been amended by the addition of the enumerations shown in Appendix A as Table A-1. The columns of the table contain the following information:

- Physical value: enumerated value of the task

- Value: display name of the task

- Definition: definition of the task

- Task Number: numeric identifier from the source document

- Source Document: military document in which the task is defined

7.1.5 Physical Data Model Representation in IDEF1X The IDEF1X physical data model representation of the What Codes extension is shown in Figure 7.1-1.


ANCDS 20

Figure 7.1-1. IDEF1X Physical Data Model of What Codes Extension

7.2 Why Codes Extension As was the case for the What codes, the existing set of Why codes provided by the default US JC3IEDM was insufficient for the implementation of the IBML OPORD. The purpose of this extension is therefore to add the necessary Why codes to satisfy this requirement. The additional Why codes were obtained from the various military references found in Section 2.2.

7.2.1 Description The Why Codes Extension provides the capability of representing information related specifically to additional land operations effects.

7.2.2 Implementation The Why Codes extension implements the needed data requirement by amending the descr_code attribute of the ACT_EFFECT table by the inclusion of additional enumerations.

7.2.3 Additional Table No table has been added.

7.2.4 Amendment Within the ACT_EFFECT table, the descr_code attribute has been amended by the addition of the enumerations shown in Appendix B as Table B-1. The columns of the table contain the following information:

- Physical value: enumerated value of the effect

- Value: display name of the effect

- Definition: definition of the effect


ANCDS 21

7.2.5 Physical Data Model Representation in IDEF1X The IDEF1X physical data model representation of the Why Codes extension is shown in Figure 7.2-1.

Figure 7.2-1. IDEF1X Physical Data Model of Why Codes Extension