JC3IEDM-Main-3.1.4

Transcription

JC3IEDM-Main-3.1.4

JC3IEDM - MAIN - IPT3
V3.1.4
MULTILATERAL INTEROPERABILITY PROGRAMME (MIP)
THE JOINT C3 INFORMATION EXCHANGE
DATA MODEL
(JC3IEDM Main)
14 Feb 2012, Greding, Germany
This Multilateral Interoperability Programme (MIP) Technical Interface Design Plan has
been reviewed and is hereby approved by the Heads of Delegation of participating nations.
Release of this document to nations or agencies, who are not participants in the
Multilateral Interoperability Programme including the media and general public, require
the approval of the MIP Steering Group (MSG) in accordance with policy stated in the
MIP Communications and Liaison Plan (MCLiP). This document is the property of the
MIP participants and the information contained in this document shall not be
communicated, either directly or indirectly, to any person or agency not authorised to
receive it.
V3.1.4
RECORD OF CHANGES PAGE
Date Entered
Responsible
Individual
Remarks
16 February 2007
DMWG
JC3IEDM Edition
3.1a
13 December 2007
DMWG
JC3IEDM Edition
3.1b
24 April 2008
DMWG
JC3IEDM Edition
3.1c
11 December 2008
DMWG
JC3IEDM Edition
3.1d
14 May 2009
DMWG
JC3IEDM Edition
3.0.2 - Document
version identifier
changed from
3.1X to 3.0.X in
preparation for
release of MIP
Baseline 3.0
documentation
NA
20 May 2009
Mike Morris
Fix ACTIONCOMMENT
NA
22 May 2009
Mike Morris
Fix Hyperlinks
CP_MIP31_33001_Errors in
JC3IEDM_JC3IEDM-v2
8 March 2011
Mike Morris
Fix Editorial issues
for 3.1.1
CP_MIP31_33007_IED_JC3IEDM
3.0.2 v14
CP_31_37001_IED_JC3IEDM
3_0_2_v6
CP_31_37027_v5_IED_JC3IEDM_3_
0_2_example
CP_31_36002_v3_IED_JC3IEDM
Main-Annex G1-BRs-Text
CP_31_35001_v17_IA_JC3IEDM
16 March 2011
Mike Morris
Add IED and IA
CPs for 3.1.1
MPRT - 1521
12 May 2011
Mike Morris
Editorial changes
CP_31_35004_V9_IncreaseOperCom
mentSize_JC3IEDM
CP_31_37028_v1_OrbTask_JC3IEDM
12 May 2011
Mike Morris
Apply CPs to
make 3.1.2
NA
17 June 2011
Mike Morris
Fix headers to add
version #
NA
8 July 2011
Mike Morris
Editorial changes
CP Number
ii
V3.1.4
CP 31_39003, 31_39004, 31_39005,
31_39006, 31_39007, 31_39008,
31_39014, 31_39021, 31_39024
MPRs 1468, 1521, 1529
2 Oct 2011
Mike Morris
Apply CPs to
make 3.1.3
CP_31_40001_v2_MPR1467_JC3IED
M
CP_31_40016_02_JC3IEDM_Main_M
PR1564
12 Dec 2011
Mike Morris
Apply CPs to
make 3.1.4
iii
V3.1.4
CONTENTS
PREFACE ............................................................................................................................ xxiii
1. INTRODUCTION .............................................................................................................. 1
1.1
Evolution of the Joint C3 Information Exchange Data Model (JC3IEDM) ............. 1
1.2
Purpose of JC3IEDM Documentation ...................................................................... 4
1.3
Scope ........................................................................................................................ 4
1.4
Structure of This Document ..................................................................................... 5
1.5
Conventions for the Presentation of Examples......................................................... 5
2. OVERVIEW OF REQUIREMENTS ................................................................................. 9
2.1
Introduction .............................................................................................................. 9
2.2
General Requirements in ATCCIS Phase III............................................................ 9
2.3
Fire Support Requirements ..................................................................................... 11
2.4
Requirements in Phase IV ...................................................................................... 12
2.5
Requirements during ATCCIS 2000 (Phase V) ..................................................... 20
2.6
MIP Block 1 Work ................................................................................................. 21
2.7
MIP Block 2 Work ................................................................................................. 22
2.8
MIP Block 3 Work ................................................................................................. 22
3. OVERVIEW OF THE DATA MODEL ........................................................................... 24
3.1
Concepts Underlying the Design of the Data Model .............................................. 24
3.2
Guide to Contents ................................................................................................... 25
3.3
Foundational Structural Elements .......................................................................... 27
3.4
OBJECT-TYPE Hierarchy ..................................................................................... 31
3.5
Composition of Types (Establishment) .................................................................. 33
3.6
OBJECT-ITEM Hierarchy ..................................................................................... 35
3.7
Specifying Status of OBJECT-ITEMs ................................................................... 37
3.8
Specifying Access to OBJECT-ITEMs .................................................................. 39
3.9
Associations between OBJECT-ITEMs ................................................................. 40
3.10 Capabilities of Items and Types ............................................................................. 43
3.11 Positioning and Geometry for OBJECT-ITEMs .................................................... 45
3.12 Relationships between Items and Types................................................................. 48
3.13 ACTION: Structured Specification of Activity ...................................................... 50
3.14 Broadening Functionality of ACTION ................................................................... 55
3.15 Plans and Orders ..................................................................................................... 64
3.16 Data about Reported Data ...................................................................................... 66
3.17 Applying Security Classifications .......................................................................... 68
3.18 Citing External Information Sources ...................................................................... 69
3.19 CONTEXT as a Way of Grouping Data................................................................. 71
iv
V3.1.4
3.20 Attaching Affiliation to Items and Types ............................................................... 75
3.21 Counting Persons by Group Characteristics ........................................................... 76
3.22 Summary of JC3IEDM Features ............................................................................ 78
3.23 Examples of Potential Use ..................................................................................... 80
4. OBJECT CLASSES (TYPES OF OBJECTS) .................................................................. 83
4.1
Introduction ............................................................................................................ 83
4.2
OBJECT-TYPE Tree Structure .............................................................................. 85
4.3
FACILITY-TYPE Tree Structure .......................................................................... 88
4.4
FEATURE-TYPE Tree Structure........................................................................... 91
4.5
MATERIEL-TYPE Tree Structure ........................................................................ 95
4.6
ORGANISATION-TYPE Tree Structure ............................................................ 119
4.7
Specification of PERSON-TYPE ......................................................................... 134
4.8
AFFILIATION in Relation to OBJECT-TYPEs .................................................. 135
5. INDIVIDUALLY IDENTIFIABLE OBJECTS (ITEMS).............................................. 136
5.1 OBJECT-ITEM and Its Hierarchy ....................................................................... 136
5.2
Specification of OBJECT-ITEM .......................................................................... 137
5.3
First-Level Subtypes of OBJECT-ITEM ............................................................. 139
5.4
FACILITY and Its Subtrees ................................................................................. 140
5.5
FEATURE Subtree ............................................................................................... 164
5.6
MATERIEL.......................................................................................................... 179
5.7
ORGANISATION Subtree .................................................................................. 182
5.8
PERSON Structure ............................................................................................... 185
5.9
Comments and Amplifications ............................................................................. 188
6. RELATIONSHIPS BETWEEN ITEMS AND TYPES.................................................. 189
6.1
Classification of OBJECT-ITEMs by Type ......................................................... 189
6.2
HOLDING and HOLDING-TRANSFER ............................................................ 191
6.3
Specification of Reportable Types ....................................................................... 199
7. STATUS OF IDENTIFIABLE OBJECTS ..................................................................... 201
7.1
OBJECT-ITEM-HOSTILITY-STATUS.............................................................. 201
7.2
Introduction to OBJECT-ITEM-STATUS ........................................................... 203
7.3
OBJECT-ITEM-STATUS and Its Subtypes ........................................................ 204
7.4
Medical Extension for FACILITY-STATUS....................................................... 231
7.5
Business Rules for Status of OBJECT-ITEMs..................................................... 242
8. NETWORKS AND ACCESS TO ITEMS THROUGH ADDRESSING ...................... 243
8.1
Introduction .......................................................................................................... 243
8.2
Networks .............................................................................................................. 243
8.3
Access to OBJECT-ITEMs .................................................................................. 251
8.4
Integrated Examples ............................................................................................. 255
9. OBJECT-ITEM ASSOCIATIONS ................................................................................. 273
9.1
Introduction .......................................................................................................... 273
v
V3.1.4
9.2
Data Structure for Associations ............................................................................ 273
9.3
An Example of Organisational Relationships ...................................................... 275
9.4
An Example of Associations between Organisations and Materiel...................... 276
9.5
An Example of Associations between Organisations and Persons....................... 277
9.6
Example of Using a Facility as Part of an Obstacle ............................................. 279
9.7
A Technique for Representing Unit Boundaries Using Associations .................. 282
9.8
Organisational Structure ....................................................................................... 290
10. CAPABILITIES OF OBJECTS AND TYPES ............................................................... 295
10.1 Introduction .......................................................................................................... 295
10.2 Structure for Specifying CAPABILITY ............................................................... 297
10.3 Assigning CAPABILITY to Client Entities ......................................................... 307
10.4 ACTION-REQUIRED-CAPABILITY ................................................................ 316
11. ESTABLISHMENT STRUCTURE ............................................................................... 317
11.1 Introduction .......................................................................................................... 317
11.2 Establishment for OBJECT-TYPE ....................................................................... 317
11.3 Business Rules for Establishments ....................................................................... 320
11.4 Examples of Establishments ................................................................................. 320
11.5 Linking OBJECT-ITEMs to Establishments ........................................................ 332
12. LOCATION .................................................................................................................... 335
12.1 Concept for Representing Location and Geometry .............................................. 335
12.2 Overview of Location Structure ........................................................................... 335
12.3 Specification of the Top-Level Entity LOCATION ............................................. 337
12.4 Specification of POINT and Supporting Structures ............................................. 337
12.5 Specification of LINE........................................................................................... 348
12.6 SURFACE Structures ........................................................................................... 352
12.7 GEOMETRIC-VOLUME .................................................................................... 367
12.8 Relating LOCATIONs to OBJECT-ITEMs ......................................................... 373
12.9 The Use of Value "Undefined" for location-category-code ................................. 378
12.10 Relating LOCATIONs to ACTIONs .................................................................... 378
12.11 Business Rules ...................................................................................................... 378
13. REPORTING-DATA AND REFERENCE .................................................................... 381
13.1 Introduction .......................................................................................................... 381
13.2 REPORTING-DATA Structure............................................................................ 382
13.3 REPORTING-DATA in Relation to Other Entities ............................................. 386
13.4 Business Rule for REPORTING-DATA .............................................................. 388
13.5 An Example of REPORTING-DATA Usage ....................................................... 388
13.6 Example of Using REPORTING-DATA to Indicate Erroneous Information ...... 392
13.7 REFERENCE for External Information ............................................................... 393
13.8 ACTION-REFERENCE-ASSOCIATION ........................................................... 400
13.9 CAPABILITY-REFERENCE-ASSOCIATION .................................................. 400
vi
V3.1.4
13.10 OBJECT-ITEM-REFERENCE-ASSOCIATION ................................................ 401
13.11 OBJECT-TYPE-REFERENCE-ASSOCIATION ................................................ 402
13.12 ORGANISATION-REFERENCE-ASSOCIATION............................................ 402
13.13 REFERENCE-ASSOCIATION ........................................................................... 403
13.14 Relationship of REFERENCE to REPORTING-DATA...................................... 404
14. CONTEXT...................................................................................................................... 405
14.1 Introduction .......................................................................................................... 405
14.2 Specification of CONTEXT Structure ................................................................. 406
14.3 Providing Assessments via CONTEXT .............................................................. 414
14.4 Linking CONTEXT to REPORTING-DATA ...................................................... 420
14.5 Examples of REPORTING-DATA and CONTEXT Usage ................................. 421
14.6 Specification of CONTEXT-OBJECT-ITEM-ASSOCIATION and Its
Status .................................................................................................................... 429
14.7 Specification of ACTION-CONTEXT and Its Status .......................................... 431
14.8 Operational Information Groups and Related Structures ..................................... 433
14.9 Security Classification Specification.................................................................... 440
15. BASIC ACTION STRUCTURE .................................................................................... 443
15.1 Introduction .......................................................................................................... 443
15.2 Specification of ACTION .................................................................................... 445
15.3 Subtypes of ACTION ........................................................................................... 446
15.4 ACTION-TASK and ACTION-EVENT .............................................................. 448
15.5 ACTION-EVENT Subtype Structure................................................................... 459
15.6 The Role of Objects as Resources and Objectives ............................................... 465
15.7 ACTION-RESOURCE......................................................................................... 466
15.8 ACTION-OBJECTIVE and Related Structures ................................................... 470
15.9 Additional Structures under ACTION-OBJECTIVE-ITEM ................................ 476
15.10 ACTION-EFFECT ............................................................................................... 481
15.11 ACTION Timing .................................................................................................. 484
15.12 Maintaining Status of ACTION-TASKs and ACTION-EVENTs ....................... 486
15.13 ACTIONs in Relation to Other ACTIONs ........................................................... 491
15.14 Illustration of ACTION Structure ........................................................................ 503
15.15 A Data Example for the Schema Related to the ACTION Structure ................... 507
16. EXTENSIONS TO ACTION STRUCTURE ................................................................. 529
16.1 Introduction .......................................................................................................... 529
16.2 ACTION-REQUIRED-CAPABILITY ................................................................ 530
16.3 ACTION-RESOURCE-EMPLOYMENT Structure ............................................ 532
16.4 Rules of Engagement ........................................................................................... 539
16.5 The Role of ORGANISATION in ACTION ....................................................... 542
16.6 Setting Up a Task Organisations in Support of Plans .......................................... 547
16.7 Expanding ACTION Specifications ..................................................................... 549
16.8 Identifying Candidate Targets .............................................................................. 554
vii
V3.1.4
16.9 Adding Comments to ACTION............................................................................ 564
16.10 Locating an ACTION Directly ............................................................................. 565
17. SCHEMA FOR STANAG 2014-BASED PLANS AND ORDERS............................... 572
17.1 Introduction .......................................................................................................... 572
17.2 Design of the Plans and Orders Extension ........................................................... 572
17.3 Conceptual Description of Plan and Order Constructs ......................................... 575
17.4 An Operations Order to Illustrate the Specifications............................................ 580
17.5 Detailed Specifications for theTop Level of Plan or Order .................................. 583
17.6 Structure Specifications ........................................................................................ 585
17.7 Specification of Content for Plan or Order ........................................................... 589
17.8 Specifications for Designating Plan or Order and Maintaining Its Status ............ 596
17.9 Specification of Relationships to ORGANISATION ........................................... 599
17.10 Specifications for Distribution and Acknowledgement........................................ 601
17.11 Packaging Plans and Orders for Replication ........................................................ 604
17.12 Sequencing of Components .................................................................................. 606
17.13 A Simple Technical Example ............................................................................... 606
17.14 Example: CJFLL Operations Order and FRAGOs .............................................. 611
18. INTELLIGENCE EXTENSION .................................................................................... 630
18.1 Introduction .......................................................................................................... 630
18.2 Requirements ........................................................................................................ 630
18.3 Design Considerations .......................................................................................... 631
18.4 Specification of REQUEST .................................................................................. 632
18.5 Specification of REQUEST-ANSWER and REQUEST-ANSWERELEMENT ........................................................................................................... 633
18.6 Formulation of a Request ..................................................................................... 636
18.7 Specification of Requests ..................................................................................... 636
18.8 Intelligence Information ....................................................................................... 643
19. AFFILIATION................................................................................................................ 649
19.1 General Description .............................................................................................. 649
19.2 Specification of AFFILIATION and Its Subtypes ............................................... 649
19.3 AFFILIATION Relationships .............................................................................. 651
19.4 Intended Usage ..................................................................................................... 652
19.5 Business Rules for AFFILIATION ...................................................................... 653
19.6 Examples of Affiliation ........................................................................................ 653
20. COUNTING PERSON-TYPES BY GROUP CHARACTERISTICS ........................... 657
20.1 Introduction .......................................................................................................... 657
20.2 Description of Counting Structure........................................................................ 657
20.3 Specification of Counting Structure ..................................................................... 659
20.4 Examples of Counting .......................................................................................... 660
20.5 Characteristics That May Be Used in Counting ................................................... 667
viii
V3.1.4
21. PHYSICAL DATA SCHEMA ....................................................................................... 670
21.1 Schema Level ....................................................................................................... 670
21.2 The JC3IEDM Physical Schema .......................................................................... 670
21.3 Physical Application Schemata ............................................................................ 671
21.4 Key Management Rules to be Taken into Account for Database
Implementation..................................................................................................... 671
21.5 MIP Information Resource Dictionary (MIRD) ................................................... 671
22. TRANSFORMATION RULES FOR PHYSICAL DATA SCHEMATA...................... 672
22.1 Introduction .......................................................................................................... 672
22.2 General Transformation Rules ............................................................................. 672
22.3 Transformation Rules for the JC3IEDM Schema ................................................ 676
23. INFORMATION INTEGRITY ...................................................................................... 689
23.1 Introduction .......................................................................................................... 689
23.2 Loggable Entities.................................................................................................. 689
23.3 Rationale for Loggable Entities ............................................................................ 689
Annexes
Annex A
Glossary
Annex B
Entity Definitions and Attributes
Annex C
Attribute Definitions
Annex D
Entity Relationships
Annex E
Specifications of Enumerated Domains
Annex F
Specification of Physical Domains
Annex G1
Compendium of Text Business Rules
Annex G2
Compendium of Coded Business Rules
Annex H
Naming Conventions and Class Words
Annex I
Summary of IDEF1X Data Modelling Methodology and Notation
Annex J
References
Annex K
IDEF1X Logical Data Model Diagram
Annex L
IDEF1X Diagram of Physical Schema
Annex M
Changes Made to JC3IEDM Edition 3.0 Data Model in Evolving
JC3IEDM Edition 3.1
Annex N
Changes Made to JC3IEDM Edition 3.0 Domains in Evolving
JC3IEDM Edition 3.1
Annex O
Extensible Markup Language (XML) Reference Implementations
Annex P
SQL Script for Physical Schema Generation
ix
V3.1.4
LIST OF FIGURES
Figure 1. C2 Data in Relation to Functional Areas ......................................................................... 4
Figure 2. Independent Entities in the Data Specification .............................................................. 29
Figure 3. First Level Subtyping of OBJECT-TYPE and OBJECT-ITEM .................................... 31
Figure 4. Entity-Level View of OBJECT-TYPE Subtype Tree .................................................... 32
Figure 5. Specifying Establishments............................................................................................. 34
Figure 6. Assigning Establishment to OBJECT-ITEM................................................................. 35
Figure 7. Entity-Level View of OBJECT-ITEM Subtype Tree .................................................... 36
Figure 8. Specifying Hostility Status ............................................................................................ 38
Figure 9. Specifying Status of OBJECT-ITEMs .......................................................................... 38
Figure 10. Providing Access to an OBJECT-ITEM through ADDRESS ..................................... 40
Figure 11. Associations among OBJECT-ITEMs......................................................................... 41
Figure 12. Specifying Organisational Structure ............................................................................ 43
Figure 13. Specifying Capabilities of Objects .............................................................................. 44
Figure 14. Entity-Level View of the LOCATION Structure ........................................................ 46
Figure 15. Assigning Position and Geometry to OBJECT-ITEMs ............................................... 47
Figure 16. Assigning Type Classification to an OBJECT-ITEM ................................................. 48
Figure 17. Accounting for Holdings by an OBJECT-ITEM ......................................................... 49
Figure 18. Assigning Reporting Codes to MATERIEL-TYPE .................................................... 50
Figure 19. Basic ACTION Structure............................................................................................. 51
Figure 20. An Example of ACTION Hierarchy ............................................................................ 53
Figure 21. ACTION Subtype Structure ........................................................................................ 54
Figure 22. TARGET Structure ...................................................................................................... 56
Figure 23. REQUEST Structure.................................................................................................... 58
Figure 24. ACTION-RESOURCE-EMPLOYMENT Structure ................................................... 59
Figure 25. RULE-OF-ENGAGEMENT Structure ........................................................................ 60
Figure 26. Candidate Target Structure .......................................................................................... 61
Figure 27. Linking Candidate Targets to Operations Planning..................................................... 62
Figure 28. Tactical Characterization of IEDs ............................................................................... 64
Figure 29. Plans and Orders Structure Shown at Entity Level ..................................................... 65
Figure 30. Structure for REPORTING-DATA ............................................................................. 67
Figure 31. Relationships from SECURITY-CLASSIFICATION ................................................. 68
Figure 32. REFERENCE and Its Relationships ............................................................................ 69
Figure 33. Basic CONTEXT Structure ......................................................................................... 72
Figure 34. CONTEXT Associations ............................................................................................. 73
Figure 35. CONTEXT Assessment............................................................................................... 74
Figure 36. Structure for Specifying Affiliations ........................................................................... 75
Figure 37. Structure for Counting PERSON-TYPEs .................................................................... 77
Figure 38. High-Level View of JC3IEDM ................................................................................... 79
Figure 39. Objects, Types, and Their Relationship ....................................................................... 83
Figure 40. Entity View of First-Level Subtypes of OBJECT-TYPE and OBJECT-ITEM .......... 84
Figure 41. Specification of First-Level Subtypes of OBJECT-TYPE .......................................... 85
x
V3.1.4
Figure 42.
Figure 43.
Figure 44.
Figure 45.
Figure 46.
Figure 47.
Figure 48.
Figure 49.
Figure 50.
Figure 51.
Figure 52.
Figure 53.
Figure 54.
Figure 55.
Figure 56.
Figure 57.
Figure 58.
Figure 59.
Figure 60.
Figure 61.
Figure 62.
Figure 63.
Figure 64.
Figure 65.
Figure 66.
Figure 67.
Figure 68.
Figure 69.
Figure 70.
Figure 71.
Figure 72.
Figure 73.
Figure 74.
Figure 75.
Figure 76.
Figure 77.
Figure 78.
Figure 79.
Figure 80.
Figure 81.
Figure 82.
Figure 83.
Figure 84.
Figure 85.
Entity-Level View of OBJECT-TYPE Subtype Tree ................................................. 87
FACILITY-TYPE and Its Subtypes ............................................................................ 88
FEATURE-TYPE and Its Subtypes ............................................................................ 92
EQUIPMENT-TYPE and Its Subtypes ....................................................................... 97
CONSUMABLE-MATERIEL-TYPE and Its Subtypes ........................................... 112
ORGANISATION-TYPE Subtype Hierarchy .......................................................... 120
Entity-Level View of OBJECT-ITEM Subtype Tree ................................................ 136
Extension of OBJECT-ITEM to Alias and Comment ............................................... 138
First-Level Subtypes of OBJECT-ITEM................................................................... 140
FACILITY and Its Subtypes Less Harbour Facilities ............................................... 141
MILITARY-OBSTACLE and Its Subtype MINEFIELD ......................................... 147
FACILITY and Its Harbour-Related Subtypes.......................................................... 156
FEATURE and Its First-Level Subtypes ................................................................... 164
CONTROL-FEATURE and Its Subtypes ................................................................. 166
Illustration of Approach Direction for Runway ........................................................ 170
Specifying Runway Approach Direction................................................................... 172
METEOROLOGIC-FEATURE and Its Subtypes ..................................................... 174
MATERIEL and Its Subtype INSTRUMENT-LANDING-SYSTEM ...................... 180
ORGANISATION and Its Subtypes ......................................................................... 182
PERSON and Its Child Entities ................................................................................. 185
Specification of OBJECT-ITEM-TYPE.................................................................... 189
Specification of HOLDING ...................................................................................... 192
Assigning Reporting Codes to MATERIEL-TYPE .................................................. 200
OBJECT-ITEM-HOSTILITY-STATUS................................................................... 201
Entity-Level View of OBJECT-ITEM-STATUS Subtype Tree ............................... 204
Specification of OBJECT-ITEM-STATUS and Its First-Level Subtypes ................ 205
Subtypes of FACILITY-STATUS ............................................................................ 209
GEOGRAPHIC-FEATURE-STATUS and Its Subtypes .......................................... 215
MATERIEL-STATUS and Its Subtypes MINE-STATUS and UXO-STATUS....... 220
Entity-Level View of Medical Extension to FACILITY-STATUS .......................... 231
Specification of MEDICAL-FACILITY-STATUS and Its Child Entities ................ 233
Specification of MEDICAL-FACILITY-STATUS for Intervals .............................. 236
NETWORK Structure ............................................................................................... 244
ADDRESS Structure ................................................................................................. 252
Illustration of Example B .......................................................................................... 257
Illustration of Example C .......................................................................................... 260
Illustration of Example D .......................................................................................... 263
Specification of OBJECT-ITEM-ASSOCIATION Structure ................................... 273
An Example of an Obstacle ....................................................................................... 279
APP-6A Symbol Modifiers ....................................................................................... 282
Example of Modifiers for APP-6A Symbol .............................................................. 283
An Example of Unit Boundaries ............................................................................... 284
Unit Boundaries with Indicated Line Directions ....................................................... 286
Division in Relation to Its Boundaries ...................................................................... 287
xi
V3.1.4
Figure 86. Brigades in Relation to Their Own and Division Boundaries ................................... 287
Figure 87. Battalions in Relation to Their Own Boundaries ....................................................... 288
Figure 88. Battalions in Relation to Brigade and Division Boundaries ...................................... 288
Figure 89. Specification of ORGANISATION-STRUCTURE .................................................. 291
Figure 90. CAPABILITY in Relation to ACTION, OBJECT-ITEM, and OBJECT-TYPE ...... 296
Figure 91. Specification of CAPABILITY and Its Subtypes...................................................... 297
Figure 92. Specification of CAPABILITY Links to ACTION and Objects ............................... 308
Figure 93. Establishment Structure ............................................................................................. 318
Figure 94. Alternative Personnel Establishments for an Infantry Company............................... 324
Figure 95. Alternate Materiel Establishments for Infantry Company......................................... 327
Figure 96. Establishment Relationships between OBJECT-TYPE and OBJECT-ITEM ........... 332
Figure 97. Entity-Level View of the LOCATION Structure ...................................................... 336
Figure 98. Specification of POINT Structures ............................................................................ 338
Figure 99. Specification of LINE Structure ................................................................................ 348
Figure 100. An Example: Top View of Lines ............................................................................. 351
Figure 101. Specification of SURFACE ..................................................................................... 352
Figure 102. Illustration of CORRIDOR-AREA ......................................................................... 353
Figure 103. Illustration of ELLIPSE ........................................................................................... 355
Figure 104. Illustration of FAN-AREA Specification ................................................................ 357
Figure 105. Two Examples of FAN-AREA................................................................................ 358
Figure 106. Illustration of ORBIT-AREA .................................................................................. 359
Figure 107. Illustration of POLYGON-AREA in a Plane .......................................................... 360
Figure 108. Illustration of POLYGON-AREAs in 3-D .............................................................. 362
Figure 109. Illustration of POLYARC-AREA ........................................................................... 363
Figure 110. Illustration of TRACK-AREA................................................................................. 365
Figure 111. Specification of GEOMETRIC-VOLUME ............................................................. 368
Figure 112. Illustration of CONE-VOLUME ............................................................................. 369
Figure 113. Examples of GEOMETRIC-VOLUME .................................................................. 372
Figure 114. Specification of OBJECT-ITEM-LOCATION ....................................................... 374
Figure 115. Illustration for Line of Bearing ................................................................................ 377
Figure 116. Specification of REPORTING-DATA Structure .................................................... 382
Figure 117. REPORTING-DATA and Its Relationships to Dynamic Data ................................ 388
Figure 118. Specification of REFERENCE Structure ................................................................ 394
Figure 119. Overview of CONTEXT Structure and Its Relationships ....................................... 406
Figure 120. Specification of CONTEXT Structure..................................................................... 407
Figure 121. Specification of CONTEXT-ASSESSMENT ......................................................... 415
Figure 122. Relating CONTEXT to REPORTING-DATA ........................................................ 421
Figure 123. An Example: Two Reports about HOLDINGs of Bradyland Unit .......................... 423
Figure 124. An Example: Update of HOLDINGs for Bradyland Unit ....................................... 426
Figure 125. An Example: Four Views of a Tactical Situation .................................................... 427
Figure 126. Relating CONTEXT to OBJECT-ITEM ................................................................. 430
Figure 127. Specification of ACTION-CONTEXT .................................................................... 432
Figure 128. OPERATIONAL-INFORMATION-GROUP and Related Entities ........................ 434
Figure 129. Specification of SECURITY-CLASSIFICATION.................................................. 441
xii
V3.1.4
Figure 130.
Figure 131.
Figure 132.
Figure 133.
Figure 134.
Figure 135.
Figure 136.
Figure 137.
Figure 138.
Figure 139.
Figure 140.
Figure 141.
Figure 142.
Figure 143.
Figure 144.
Figure 145.
Figure 146.
Figure 147.
Figure 148.
Figure 149.
Figure 150.
Figure 151.
Figure 152.
Figure 153.
Figure 154.
Figure 155.
Figure 156.
Figure 157.
Figure 158.
Figure 159.
Figure 160.
Figure 161.
Figure 162.
Figure 163.
Figure 164.
Figure 165.
Figure 166.
Figure 167.
Figure 168.
Figure 169.
Figure 170.
Figure 171.
Figure 172.
Figure 173.
Basic ACTION Structure ........................................................................................ 443
Specification of ACTION Subtype Structure .......................................................... 447
Subject Taxonomy from IED Lexicon .................................................................... 452
ACTION-EVENT Subtype Structure ...................................................................... 459
Specification of ACTION, ACTION-RESOURCE, and ACTION-OBJECTIVE .. 466
Specification of ACTION-OBJECTIVE-TYPE-IMAGERY-PRODUCT .............. 476
Specification of ACTION-OBJECTIVE-ITEM-MARKING and TARGET .......... 477
Specification of ACTION-EFFECT ........................................................................ 482
Illustration of Timing for an ACTION-TASK ........................................................ 485
Specification of Status for ACTION-EVENT and ACTION-TASK ...................... 486
Specification of Functional and Temporal Associations for ACTION ................... 492
An Example of ACTION Hierarchy and Relationships .......................................... 493
An Example of Temporal Dependencies for ACTIONs ......................................... 496
Functional Relationships for Operation Foxtrot Sierra ........................................... 504
Temporal Relationships for Operation Foxtrot Sierra ............................................. 504
Enhancing the Functionality of ACTION ............................................................... 529
Specification of ACTION-REQUIRED-CAPABILITY ......................................... 531
Specification of ACTION-RESOURCE-EMPLOYMENT Structure..................... 532
Specifying Rules of Engagement for ACTIONs ..................................................... 540
Specification of ORGANISATION-ACTION-ASSOCIATION ............................ 543
An Example: Task Organisation for 1 (UK) Division............................................. 547
An Example of Planned Movement of Two Units .................................................. 551
Specification of CANDIDATE-TARGET-LIST Structure ..................................... 555
Linking Candidate Targets to ACTION for Operations Planning........................... 563
Addition of Comments to ACTION ........................................................................ 564
Specification of ACTION-LOCATION .................................................................. 567
Plans and Orders Extension Shown at Entity Level ................................................ 573
Basic Data Structures for Plans and Order .............................................................. 576
Hierarchical Decomposition of Plans and Orders ................................................... 576
Providing Content for Plan or Order Components .................................................. 577
Attaching Structured ACTION Specifications ........................................................ 578
Relating to ORGANISATION-STRUCTURE to Plans and Orders ....................... 578
Linking Annexes to Plans and Orders ..................................................................... 579
Linking Plans and Orders ........................................................................................ 580
Modifying an Order by a FRAGO .......................................................................... 580
Top-Level Specification for Plans and Orders ........................................................ 583
Specification for Hierarchical Structuring of Plans and Orders .............................. 586
Component Hierarchy for Foxtrot Sierra OPORDER ............................................. 589
Specification of Content for PLAN-ORDER-COMPONENT ................................ 590
Specification of Typing and Status for Plans and Orders........................................ 597
Relationships between PLAN-ORDER and ORGANISATION ............................. 599
Plan and Order Distribution and Acknowledgement............................................... 602
Packaging Plans and Orders for Replication ........................................................... 604
Specification of REQUEST..................................................................................... 633
xiii
V3.1.4
Figure 174.
Figure 175.
Figure 176.
Figure 177.
Figure 178.
Specification of REQUEST-ANSWER Structure ................................................... 634
Specification of AFFILIATION Structure and Its Relationships ............................ 650
Specification of OBJECT-ITEM-GROUP-ACCOUNT Structure .......................... 658
General SQL-Statement for Creating Tables and Columns..................................... 673
SQL-Statement for Creating Primary Key Constraints Using “Primary Key” Syntax
.................................................................................................................................. 675
Figure 179. SQL-Statement for Creating Primary Key Constraints Using Indexes ................... 675
Figure 180. SQL-Statement for Creating Foreign Key Constraints ............................................ 675
xiv
V3.1.4
LIST OF TABLES
Table 1. Evolution to JC3IEDM ..................................................................................................... 2
Table 2. Summary of Information Requirements ........................................................................... 9
Table 3. Categories of Operational Information ........................................................................... 10
Table 4. Initial Minimum Set of Essential IERs ........................................................................... 13
Table 5. Capsule Descriptions of Phase IV IERs ......................................................................... 14
Table 6. Article V Requirements and Fulfilment in the Model .................................................... 18
Table 7. CRO Requirements and Fulfilment in the Model ........................................................... 20
Table 8. Joint Requirements and Fulfilment in the Model ........................................................... 21
Table 9. Independent Entities and Their Roles ............................................................................. 27
Table 10. Definition of First-Level Subtypes ............................................................................... 31
Table 11. Permissible Combinations of Types for Establishments .............................................. 34
Table 12. Valid OBJECT-ITEM Associations ............................................................................. 41
Table 13. Examples of Associations ............................................................................................. 42
Table 14. Examples of REFERENCE .......................................................................................... 70
Table 15. OBJECT-TYPE Example Instances ............................................................................. 86
Table 16. Example Instances for FACILITY-TYPE and Subtypes .............................................. 90
Table 17. Example Instances for FEATURE-TYPE .................................................................... 92
Table 18. Examples of CONTROL-FEATURE-TYPE ................................................................ 93
Table 19. Examples of ROUTE-TYPE......................................................................................... 94
Table 20. Examples of GEOGRAPHIC-FEATURE-TYPE ......................................................... 94
Table 21. Examples of MATERIEL-TYPE .................................................................................. 96
Table 22. Examples of EQUIPMENT-TYPE ............................................................................... 99
Table 23. Instances of AIRCRAFT-TYPE ................................................................................. 100
Table 24. Instances of CBRN-EQUIPMENT-TYPE.................................................................. 101
Table 25. Instances of ELECTRONIC-EQUIPMENT-TYPE.................................................... 102
Table 26. Instances of ENGINEERING-EQUIPMENT-TYPE ................................................. 103
Table 27. Instances of MARITIME-EQUIPMENT-TYPE ........................................................ 104
Table 28. Instances of MISCELLANEOUS-EQUIPMENT-TYPE ........................................... 105
Table 29. Instances of RAILCAR-TYPE ................................................................................... 106
Table 30. Instances of VEHICLE-TYPE .................................................................................... 107
Table 31. Instances of VESSEL-TYPE ...................................................................................... 108
Table 32. Instances of WEAPON-TYPE .................................................................................... 111
Table 33. CONSUMABLE-MATERIEL-TYPE Example Instances ......................................... 114
Table 34. Instances of AMMUNITION-TYPE .......................................................................... 115
Table 35. Instances of BIOLOGICAL-MATERIEL-TYPE ....................................................... 116
Table 36. Instances of CHEMICAL-MATERIEL-TYPE .......................................................... 117
Table 37. Instances of RADIOACTIVE-MATERIEL-TYPE .................................................... 118
Table 38. Examples of ORGANISATION-TYPE ...................................................................... 121
Table 39. CIVILIAN-POST-TYPE Example Instances ............................................................. 122
xv
V3.1.4
Table 40.
Table 41.
Table 42.
Table 43.
Table 44.
Table 45.
Table 46.
Table 47.
Table 48.
Table 49.
Table 50.
Table 51.
Table 52.
Table 53.
Table 54.
Table 55.
Table 56.
Table 57.
Table 58.
Table 59.
Table 60.
Table 61.
Table 62.
Table 63.
Table 64.
Table 65.
Table 66.
Table 67.
Table 68.
Table 69.
Table 70.
Table 71.
Table 72.
Table 73.
Table 74.
Table 75.
Table 76.
Table 77.
Table 78.
Table 79.
Table 80.
Table 81.
Table 82.
Table 83.
Examples of GOVERNMENT-ORGANISATION-TYPE ......................................... 123
Examples of MILITARY-ORGANISATION-TYPE ................................................. 125
Examples of EXECUTIVE-MILITARY-ORGANISATION-TYPE ......................... 126
MILITARY-POST-TYPE Example Instances............................................................ 127
Examples of TASK-FORMATION-TYPE................................................................. 128
Examples of UNIT-TYPE........................................................................................... 130
Examples of GROUP-ORGANISATION-TYPE ....................................................... 133
Examples of PRIVATE-SECTOR-ORGANISATION-TYPE ................................... 134
Example Instances for PERSON-TYPE ..................................................................... 135
OBJECT-ITEM Examples .......................................................................................... 140
Example of facility-major-building-type-id ................................................................ 143
Examples of FACILITY for the First Block ............................................................... 144
Instances of AIRFIELD .............................................................................................. 145
Examples of APRON .................................................................................................. 145
Instances of BRIDGE ................................................................................................. 146
Examples of MILITARY-OBSTACLEs .................................................................... 151
Example of RAILWAY Specifications....................................................................... 153
Example of ROAD Specifications .............................................................................. 154
Instances of RUNWAY .............................................................................................. 155
Examples of FACILITY for the Second Block .......................................................... 164
Example Instances for FEATURE .............................................................................. 165
Example Instances for CONTROL-FEATURE.......................................................... 167
ROUTE Example Instances ........................................................................................ 167
ROUTE-SEGMENT Instance ..................................................................................... 168
AIR-ROUTE-SEGMENT Instance............................................................................. 169
AIRSPACE-CONTROL-MEANS Instance ............................................................... 169
Example of APPROACH-DIRECTION Specification ............................................... 171
GEOGRAPHIC-FEATURE Instance ......................................................................... 173
Examples of MATERIEL ........................................................................................... 181
Examples of INSTRUMENT-LANDING-SYSTEM ................................................. 182
Examples of CONVOY .............................................................................................. 184
ORGANISATION and UNIT Examples .................................................................... 184
Example Instances for PERSON ................................................................................ 186
Use of PERSON-IDENTIFICATION-DOCUMENT ................................................ 187
Use of PERSON-LANGUAGE-SKILL...................................................................... 188
Use of object-type-id in OBJECT-ITEM-TYPE ......................................................... 190
Illustration of HOLDING ........................................................................................... 194
Illustration of HOLDING-TRANSFER ...................................................................... 196
Options for Reporting Holdings at Higher Echelon.................................................... 198
Examples of Reportable Type Codes .......................................................................... 200
Example Instances of OBJECT-ITEM-HOSTILITY-STATUS ................................. 202
Example Instances of OBJECT-ITEM-STATUS ....................................................... 206
Examples of CONTROL-FEATURE-STATUS ......................................................... 209
Examples of FACILITY-STATUS ............................................................................. 211
xvi
V3.1.4
Table 84. Instances of AIRFIELD-STATUS ............................................................................. 212
Table 85. Instances of MINEFIELD-MARITIME-STATUS ..................................................... 214
Table 86. Examples of GEOGRAPHIC-FEATURE-STATUS .................................................. 216
Table 87. Examples of LIQUID-SURFACE-STATUS .............................................................. 217
Table 88. Examples of SOLID-SURFACE-STATUS ................................................................ 218
Table 89. Examples of LIQUID-BODY-STATUS .................................................................... 219
Table 90. Examples of MATERIEL-STATUS........................................................................... 222
Table 91. Examples of MINE-STATUS..................................................................................... 223
Table 92. Examples of UXO-STATUS ...................................................................................... 224
Table 93. Examples of ORGANISATION-STATUS................................................................. 226
Table 94. Example of Role Changing by Command Posts ......................................................... 227
Table 95. Examples of PERSON-STATUS ............................................................................... 231
Table 96. Examples of MEDICAL-FACILITY-STATUS ......................................................... 239
Table 97. Illustration of NETWORK Structure .......................................................................... 248
Table 98. Examples of PHYSICAL-ADDRESS ........................................................................ 254
Table 99. Data for Example A .................................................................................................... 256
Table 100. Data for Example B .................................................................................................. 258
Table 101. Data for Example C .................................................................................................. 260
Table 102. Example D—Intranet-Based Network ...................................................................... 264
Table 103. Example E—NETWORK and Air Tasking Order ................................................... 269
Table 104. Definition of a Network for Intercept Reporting ...................................................... 270
Table 105. Report of an Emission Intercept ............................................................................... 271
Table 106. Examples of Associations between ORGANISATIONs .......................................... 276
Table 107. Use of Associations between ORGANISATIONs and MATERIEL ....................... 276
Table 108. Instances of Associations between ORGANISATION an PERSON ....................... 278
Table 109. Data for Obstacle Example ....................................................................................... 280
Table 110. Sample Units for the Boundary Example ................................................................. 284
Table 111. Identification of CONTROL-FEATUREs ................................................................ 285
Table 112. Boundary CONTROL-FEATUREs for the Units..................................................... 289
Table 113. Data for ORGANISATION-STRUCTURE Example .............................................. 293
Table 114. Example Instances of ENGINEERING-CAPABILITY ........................................... 299
Table 115. Examples of FIRE-CAPABILITY ........................................................................... 300
Table 116. Examples of HANDLING-CAPABILITY ............................................................... 301
Table 117. Examples of MAINTENANCE-CAPABILITY ....................................................... 302
Table 118. Examples of MOBILITY-CAPABILITY ................................................................. 303
Table 119. Examples of OPERATIONAL-CAPABILITY ........................................................ 304
Table 120. Examples of STORAGE-CAPABILITY .................................................................. 305
Table 121. Examples of SUPPORT-CAPABILITY................................................................... 305
Table 122. Examples of SURVEILLANCE-CAPABILITY ...................................................... 306
Table 123. Examples of TRANSMISSION-CAPABILITY ....................................................... 307
Table 124. OBJECT-TYPE-CAPABILITY-NORM Example ................................................... 310
Table 125. Examples of OBJECT-ITEM-CAPABILITY .......................................................... 313
Table 126. Establishment Example for MATERIEL-TYPE ...................................................... 320
Table 127. Example of MATERIEL-TYPE Detail in OBJECT-TYPE-ESTABLISHMENT ... 321
xvii
V3.1.4
Table 128.
Table 129.
Table 130.
Table 131.
Table 132.
Table 133.
Table 134.
Table 135.
Table 136.
Table 137.
Table 138.
Table 139.
Table 140.
Table 141.
Table 142.
Table 143.
Table 144.
Table 145.
Table 146.
Table 147.
Table 148.
Table 149.
Table 150.
Table 151.
Table 152.
Table 153.
Table 154.
Table 155.
Table 156.
Table 157.
Table 158.
Table 159.
Table 160.
Table 161.
Table 162.
Table 163.
Table 164.
Table 165.
Table 166.
Table 167.
Table 168.
Table 169.
Table 170.
Table 171.
Example of ORGANISATION-TYPE Detail in OBJECT-TYPE-ESTABLISHMENT 322
Example of Multiple OBJECT-TYPE-ESTABLISHMENTs................................... 324
Example of a Unit Type with Two Personnel Establishments.................................. 325
Personnel-Only Establishment .................................................................................. 326
Example of a Unit Type with Two Materiel Establishments .................................... 328
Example of a Missile Container Specification .......................................................... 330
Example of a Pallet Specification ............................................................................. 331
Use of OBJECT-ITEM-OBJECT-TYPE-ESTABLISHMENT ................................ 334
Domain Values for angle-precision-code ................................................................. 340
Example Instances for POINT .................................................................................. 344
Illustration of RELATIVE-POINT Concept ............................................................. 345
Example Instances for POINT .................................................................................. 347
Examples of LINE Instances .................................................................................... 350
Example of Data to Specify a Corridor..................................................................... 354
Example of Data to Specify an Ellipse ..................................................................... 355
Example Instances of a FAN-AREA ........................................................................ 357
Example of Data Entries to Specify an Orbit ............................................................ 359
Examples of POLYGON-AREA .............................................................................. 361
Example of Data Entries to Specify a Polyarc .......................................................... 363
Example of Data Entries to Specify a Track ............................................................. 365
Rules for VERTICAL-DISTANCE Use with Geometry .......................................... 366
Examples of GEOMETRIC-VOLUME .................................................................... 371
Line of Bearing Example .......................................................................................... 377
Example REPORTING-DATAs and Related Dynamic Information ....................... 390
An Example to Negate False Information................................................................. 393
Examples of REFERENCE....................................................................................... 396
Associating REFERENCE with ACTION................................................................ 400
Associating a REFERENCE with CAPABILITY .................................................... 401
Associating REFERENCEs with OBJECT-ITEMs .................................................. 401
Associating REFERENCE to OBJECT-TYPE ......................................................... 402
Associating REFERENCE to ORGANISATION..................................................... 403
Associating REFERENCEs ...................................................................................... 404
Example of CONTEXT (Initial) ............................................................................... 410
Example of CONTEXT (Continued) ........................................................................ 411
Example of CONTEXT Use (Continued) ................................................................. 413
Unit MBT Holdings .................................................................................................. 416
Typing of Hostile Units ............................................................................................ 417
Situational Awareness............................................................................................... 419
Initial MND Report ................................................................................................... 422
The REPORTING-DATA Record for Second Report .............................................. 422
Linkage of Two Instances of REPORTING-DATA ................................................. 423
OBJECT-ITEMs and OBJECT-TYPEs of Interest................................................... 424
HOLDINGs of Bradyland Unit According to the First Report ................................. 424
Indication of Data Correction ................................................................................... 425
xviii
V3.1.4
Table 172.
Table 173.
Table 174.
Table 175.
Table 176.
Table 177.
Table 178.
Table 179.
Table 180.
Table 181.
Table 182.
Table 183.
Table 184.
Table 185.
Table 186.
Table 187.
Table 188.
Table 189.
Table 190.
Table 191.
Table 192.
Table 193.
Table 194.
Table 195.
Table 196.
Table 197.
Table 198.
Table 199.
Table 200.
Table 201.
Table 202.
Table 203.
Table 204.
Table 205.
Table 206.
Table 207.
Table 208.
Table 209.
Table 210.
Table 211.
Table 212.
Table 213.
Table 214.
Table 215.
Update of the Second Report .................................................................................... 426
Three Reports on the Location of 8th Bradyland Battalion ...................................... 427
The Predicted Location of the 8th Bradyland Battalion ............................................ 428
Construction of a CONTEXT Record from Three REPORTING-DATA Records.. 429
Linking Derived Data with Original Data ................................................................ 429
Adding an Object to an OIG ..................................................................................... 436
Definition of an Air Defence Overlay ...................................................................... 438
Definition of an Artillery Overlay ............................................................................ 439
Proper Association of OBJECT-ITEMs with Overlays ............................................ 439
Removing a Unit from OIG ...................................................................................... 440
Associating CONTEXTs .......................................................................................... 440
Examples of Action Statements ................................................................................ 444
Examples of Related Action Statements................................................................... 444
ACTION Example Instances .................................................................................... 445
IED discovery Example ............................................................................................ 457
Examples of ACTION-EVENT ................................................................................ 463
ACTION-RESOURCE Example .............................................................................. 469
Additional ACTION-RESOURCE Example ............................................................ 470
Examples of ACTION-OBJECTIVE-ITEM ............................................................ 472
Example of ACTION-OBJECTIVE-TASK ............................................................. 473
Examples of ACTION-OBJECTIVE-ITEM-MARKING ........................................ 479
Example Instances for TARGET .............................................................................. 480
ACTION-EFFECT Example .................................................................................... 484
Examples of ACTION-TASK .................................................................................. 485
Examples of ACTION-EVENT ................................................................................ 487
ACTION-EVENT-STATUS Example ..................................................................... 488
ACTION-TASK-STATUS Example ........................................................................ 491
Examples of ACTION Statements............................................................................ 492
A Simple ACTION-FUNCTIONAL-ASSOCIATION Hierarchy ........................... 494
Specifying ACTIONs that Have Codeword Designators ......................................... 495
Absolute ACTION-TASK Datetime Relationships.................................................. 497
Temporal Relationships for Closed Intervals ........................................................... 499
Examples of ACTION-TEMPORAL-ASSOCIATION ........................................... 500
Temporal Relations for Open-Ended Intervals ......................................................... 500
Use of Temporal Relationships and Offset Intervals ................................................ 502
Use of ACTION-TEMPORAL-ASSOCIATION to Initiate Other ACTIONs ......... 503
Action Statements for Operation Foxtrot Sierra ....................................................... 503
Identified Items for Operation Foxtrot Sierra ........................................................... 505
Data Description of Activities in Operation Foxtrot Sierra ...................................... 505
Associations among ACTIONs in Operation Foxtrot Sierra .................................... 507
Scenario TYPE data .................................................................................................. 508
Scenario AFFILIATION data ................................................................................... 510
Scenario ITEM data .................................................................................................. 510
Scenario ITEM to TYPE and HOSTILITY data ...................................................... 511
xix
V3.1.4
Table 216. Friendly participants ................................................................................................. 513
Table 217. Type objects including Affiliation ............................................................................ 513
Table 218. Scenario ITEM to TYPE and HOSTILITY data ...................................................... 515
Table 219. Status of Items .......................................................................................................... 516
Table 220. Associations between Items ...................................................................................... 517
Table 221. Location Data ............................................................................................................ 518
Table 222. Action Data ............................................................................................................... 519
Table 223. Item to Type and Hostility Data................................................................................ 521
Table 224. Action Detail Data .................................................................................................... 522
Table 225. EOD Team Tasking .................................................................................................. 522
Table 226. EOD Team Task Status............................................................................................. 523
Table 227. UXO Explosion Data ................................................................................................ 524
Table 228. UXO Explosion Effect Data ..................................................................................... 525
Table 229. UXO Explosion Effect Status Data........................................................................... 526
Table 230. Example of ACTION-REQUIRED-CAPABILITY ................................................. 531
Table 231. Example Instance of ACTION-RESOURCE-EMPLOYMENT .............................. 534
Table 232. ACTION-AIRCRAFT-EMPLOYMENT Example .................................................. 535
Table 233. ACTION-ELECTRONIC-WARFARE-EMPLOYMENT Example ........................ 536
Table 234. ACTION-MARITIME-EMPLOYMENT Example .................................................. 538
Table 235. Example of ACTION-RECONNAISSANCE-EMPLOYMENT.............................. 539
Table 236. Example for Rules of Engagement ........................................................................... 542
Table 237. Example Instances of ORGANISATION-ACTION-ASSOCIATION ..................... 544
Table 238. Representation of ACTIONs..................................................................................... 545
Table 239. Relationships among ACTIONs ............................................................................... 546
Table 240. Examples of Intent Statements.................................................................................. 546
Table 241. Setting Up a Task Organisation: ACTION/ACTION-TASK ................................... 547
Table 242. Association Relationships in Creating a Task Organisation ..................................... 548
Table 243. The Initial Data ......................................................................................................... 551
Table 244. Setting Up "Operation Hill 251" ............................................................................... 552
Table 245. An Initial CONTEXT from Two REPORTING-DATAs ......................................... 553
Table 246. Relating CONTEXT to ACTION ............................................................................. 553
Table 247. Locations Planned for the Battalions by Multi National Division ............................ 553
Table 248. Planned Final State of the "Operation Hill 251" ....................................................... 554
Table 249. Example Instances of CANDIDATE-TARGET-LIST ............................................. 557
Table 250. Example Instances of CANDIDATE-TARGET-DETAIL ....................................... 561
Table 251. Examples of CANDIDATE-TARGET-DETAIL-AUTHORISATION ................... 562
Table 252. Illustration of ACTION-LOCATION Usage ............................................................ 568
Table 253. Illustration of Top-Level Entities............................................................................... 585
Table 254. Example: Hierarchical Structuring of Components ................................................. 588
Table 255. Example for Operation Foxtrot Sierra: Specifying Header Content ........................ 593
Table 256. Example for Operation Foxtrot Sierra: Specifying Text Content ............................ 594
Table 257. ACTION Excerpt Linked to CONTEXT .................................................................. 595
Table 258. Use of REFERENCE for Operation Foxtrot Sierra .................................................. 595
Table 259. Assembled Content for Operation Foxtrot Sierra ..................................................... 596
xx
V3.1.4
Table 260. Example: Typing and Status of Orders .................................................................... 598
Table 261. Selected Items Associated with Operation Order for Foxtrot Sierra ......................... 601
Table 262. Example of Order Distribution and Acknowledgement ........................................... 603
Table 263. Dissemination of Orders ........................................................................................... 605
Table 264. Simple Scenario Sequence ........................................................................................ 607
Table 265. Top-Level Specifications .......................................................................................... 607
Table 266. Components of the ORDER and FRAGOs............................................................... 609
Table 267. Specifying the Content of Components .................................................................... 609
Table 268. Specifying Hierarchical Relationships among Components..................................... 611
Table 269. Data for CJFLCC OPORDER .................................................................................. 615
Table 270. FRAGOs in Relation to the OPORDER ................................................................... 626
Table 271. Top-Level Data for FRAGOs to CJFLCC OPORDER ............................................ 627
Table 272. Paragraph-Level Data for FRAGOs to CJFLCC OPORDER................................... 628
Table 273. Domain Values of request-answer-category-code ................................................... 635
Table 274. Unitary Request for OBJECT-ITEM and request-category-code ............................ 636
Table 275. Binary Requests Involving OBJECT-ITEM and OBJECT-TYPE ........................... 637
Table 276. Binary Requests Involving a Pair of OBJECT-ITEMs ............................................. 638
Table 277. Examples of Requests ............................................................................................... 640
Table 278. Example of Generating an Intelligence Request....................................................... 640
Table 279. Example of Fusion-Derived Information .................................................................. 644
Table 280. Example of Derived Information through Aggregation............................................ 645
Table 281. Specification of Types and Type Affiliations ........................................................... 653
Table 282. Specification of Items and Item Affiliation .............................................................. 655
Table 283. Basic Data for Counting Examples........................................................................... 661
Table 284. Representation of OBJECT-TYPEs ......................................................................... 661
Table 285. Input for Example A ................................................................................................. 662
Table 286. Data Specification for Example A ............................................................................ 662
Table 287. Input for Example B ................................................................................................. 663
Table 288. Data Specification for Example B ............................................................................ 663
Table 289. Input for Example C ................................................................................................. 663
Table 290. Data Specification for Example C ............................................................................ 664
Table 291. Input for Example D ................................................................................................. 665
Table 292. Data Specification for Example D ............................................................................ 665
Table 293. Input for Example E.................................................................................................. 666
Table 294. Data Specification for Example E ............................................................................ 666
Table 295. Attribute Characteristics for Counting...................................................................... 668
Table 296. Logical Data Model Elements and Their Physical Counterparts .............................. 672
Table 297. Generic Physical Datatypes ...................................................................................... 674
Table 298. Transformation Rules for Optionality....................................................................... 674
Table 299. Class Word Abbreviations ........................................................................................ 678
Table 300. JC3IEDM Logical Term Abbreviations ................................................................... 678
Table 301. JC3IEDM Multiple Term Abbreviations .................................................................. 684
Table 302. Relationships between Class Words and Physical Datatypes ................................... 685
Table 303. Physical Datatypes and Optionality for Additional Columns ................................... 686
xxi
V3.1.4
xxii
V3.1.4
PREFACE
THE JOINT C3 INFORMATION EXCHANGE DATA MODEL
(JC3IEDM Main)
MIP VISION
The vision for the Multilateral Interoperability Programme (MIP) is to become the
principal operator-led multinational forum to promote international interoperability of
Command and Control Information Systems (C2IS) at all levels of command.
MIP SCOPE
The MIP scope is to deliver a command and control interoperability solution
focused on the Land operational user in a Joint environment.
MIP MISSION
MIP is to further develop and improve interface specifications in order to reduce
the interoperability gap between different C2IS.
MIP TASKS
Support fielded MIP solutions.
Further improve the MIP solution by adopting modern development approaches and
standards1.
Harmonise with NATO and leverage other appropriate standards2.
Improve flexibility in using the MIP solution in ad-hoc coalitions.
Extend the scope of MIP interoperability.
Engage Air, Maritime and other Coalition of Interests to cooperate with MIP.
Examine better ways of structuring the MIP programme.
AIM OF JC3IEDM MAIN DOCUMENT
The JC3IEDM main document describes the specification of the MIP
interoperability solution that has been formally reviewed and agreed upon. This serves as a
coherent set of documents needed to build and test a MIP Common Interface and gives a
basis for further development and improvement.
1 Examples of approaches and standards include the NATO Architectural Framework (NAF), Model Driven
Development, Service Orientation and common standards (XML, UML, RDF, etc.).
2 Examples include NNEC, APP-11, APP-6, etc.
xxiii
V3.1.4
EXECUTIVE SUMMARY
After the introduction, Chapter 2 provides an overview of requirements with a
general statement of the data specifications. Following on from this, an outline of the
Conceptual Data Model (Chapter 3) provides a general description of the design
considerations, a brief description of the model concepts in operational terms and a
summary description of the model in technical terms.
Details of the Logical Data Model (Chapters 4 to 20) cover the following topics:
Introduction (highlights of the data structures, operational requirements for the structure,
and design considerations); Subject Area Exposition (structure, entity and attribute
definitions, explanation of the structure, illustrative examples, and pointers to operational
uses of the data); Business Rules (restrictions that are needed for interoperability but
cannot be readily captured within the formal modelling methodology) and Comments
including any further topics that are worthy of inclusion but do not readily fit into any of
the categories cited above.
Chapters 21 to 23 give details of Physical Data Model Specification and provide
the rationale for the physical specifications and promulgate them. The remaining physical
specifications are contained in the annexes. Of particular importance are Annexes G1 and
G2 providing business rules for the model and Annexes M & N detailing the evolving MIP
standard since version 3.1c
The means to achieve this is known as the MIP solution. This is a set of items
delivered by the MIP programme at the end of each baseline3. It includes the MIP
specifications, Standard Operating Procedures and other documentation that is required for
implementation of specifications and for use of the MIP Common Interface (MCI)4.
3
The overall MIP Calendar is divided into 'Baselines' or evolutionary solutions, each 5-year block allocates three years
for development and two years for 'in-service' use.
4 The MCI is a logical description of the configuration of two or more implementations (in software and/or hardware) of
the MIP specifications that enables information exchange between two or more C2IS of different nations.
xxiv
V3.1.4
1.
1.1
INTRODUCTION
Evolution of the Joint C3 Information Exchange Data Model (JC3IEDM)
1.1.1 General
1.1.1.1 Data interoperability requires a rigorously defined semantic vocabulary that
is embedded in a structured context.
1.1.1.2 The structure of information is expressed in a data model, developed and
documented in accordance with an accepted methodology. The model defines the standard
elements of information that form the basis for interoperability between automated
Command and Control Information Systems (C2ISs) that accommodate the model's
information structure.
1.1.1.3 Since information exchange requirements (IERs) change over time, there is
a need to design a flexible generic model that can adapt over time to changing information
needs and serve as a basis or hub for new systems. For these reasons the data model was
initially known as the Generic Hub (GH) Data Model. The name was changed to Land C2
Information Exchange Data Model (LC2IEDM) in 1999 and an updated version was
released in 2002.
1.1.1.4 Development continued to include considerably more joint content. The
new version was released in November 2003 as C2 Information Exchange Data Model
(C2IEDM) Edition 6.1. Priority operational requirements entailed a modification to the 6.1
specification. A final Block 2 specification was released as Edition 6.15e in October 2005.
1.1.1.5 The current version incorporates additional development and the data from
the NATO Corporate Reference Model. As a result, the scope increased and the name was
changed to Joint C3 (Consultation, Command, and Control) Information Exchange Data
Model (JC3IEDM). The details of evolution are shown in the table below.
1.1.1.6 The extent of requirements agreed by the MIP nations is to define only the
information that is to be exchanged rather than all of the information that would normally
be required in a national system. Consequently, JC3IEDM is first and foremost an
information exchange data model. The model can also serve as a coherent basis for other
information exchange applications within functional user communities. The general
pattern is to use a subset of JC3IEDM and add functional extensions.
1.1.1.7 As a minimum the JC3IEDM must preserve the meaning and relationships
of the information to be exchanged and thereby attain the interoperability associated with
NATO Level 5 of System Interconnection that is defined as automated exchange of data
between C2IS databases subject to user-imposed constraints.
1
V3.1.4
Table 1. Evolution to JC3IEDM
Short
Label
Title
Version
WP 5-2
ATCCIS Battlefield Generic Hub Data
Model
ATCCIS Battlefield Generic Hub
Level 2 Data Model: Specification for
5
the Demonstration
ATCCIS Battlefield Generic Hub 3
Data Model Specification
The Land C2 Information Exchange
Data Model
Data Model
Data Model
The C2 Information Exchange Data
Model
Model
Model
The Joint C3 Information Exchange
Data Model
Data Model
Data Model
Data Model
Data Model
Data Model
Data Model
Data Model
Data Model
Data Model
Data Model
Ed 1.0
23 April 1993
GH
ATCCIS PWG
Ed 1.0
26 August 1994
GH2
ATCCIS PWG
Ed 1.0
12 December 1996
GH3
ATCCIS PWG
Ed 2.0
19 September 1997
GH3
ATCCIS PWG
Ed 3.0
10 July 1998
GH3
ATCCIS PWG
ATCCIS PWG
MIP PMG
WP 5-3
WP 5-5
WP 5-5
WP 5-5
6
ADatP-5
ADatP-32
WP 5-5
C2IEDM
C2IEDM
C2IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
JC3IEDM
Date of issue
Informal
Name
Producer
Ed 0.5
10 December 2004
GH4/
LC2IEDM
GH4/
LC2IEDM
GH5/
LC2IEDM
GH6/
C2IEDM
GH6/
C2IEDM
GH6/
C2IEDM
JC3IEDM
Ed 3.08
9 December 2005
JC3IEDM
MIP PMG
Ed 3.1a
16 February 2007
JC3IEDM
MIP PMG
Ed 3.1b
13 December 2007
JC3IEDM
MIP PMG
Ed 3.1c
24 April 2008
JC3IEDM
MIP PMG
Ed 3.1d
11 December 2008
JC3IEDM
MIP PMG
Ed 3.0.29
14 May 2009
MIP PMG
Ed 3.1.1
16 Mar 2011
Ed 3.1.2
12 May 2011
Ed 3.1.3
2 October 2011
Ed 3.1.4
14 February 2012
JC3IEDM
(Block 3)
JC3IEDM
(Block 3)
JC3IEDM
(Block 3)
JC3IEDM
(Block 3)
JC3IEDM
(Block 3)
Draft 2.0
1 October 1999
Ed 2.0
31 March 2000
Ed 5.0
7
18 March 2002
Ed 6.1
20 November 2003
Ed 6.15
26 September 2004
Ed 6.15e
4 October 2005
ATCCIS PWG
ATCCIS PWG
MIP PMG
MIP PMG
MIP PMG
MIP PMG
MIP PMG
MIP PMG
MIP PMG
5
This version was used for ATCCIS demonstration in the autumn of 1995.
6
ADatP-5 was already in use and was replaced by ADatP-32 in the subsequent version.
7
This is ATCCIS Baseline 2.0 publication, the last before merger with MIP.
8
The numbering sequence was changed to correspond to MIP block of intended use.
9
The numbering sequence was changed to correspond to MIP block of intended use.
2
V3.1.4
1.1.2 Fundamental Information Structure/Data Modelling Concepts
1.1.2.1 Trying to create an information structure that represents all of the
information about an area of operations is an understandably complex task. Data
modelling methodologies have adopted several conventions that parallel the military staff
processes in many ways. There are three models that are presented in the JC3IEDM,
namely the conceptual, logical and physical.
1.1.2.2 Conceptual Data Model. The Conceptual Data Model represents the high
level view of the information in terms of generalised concepts such as Actions,
Organisations, Materiel, Personnel, Features, Facilities, Locations and the like. This model
could of interest to senior commanders wishing to verify the scope of the information
structure. The presentation in Chapter 3 may be viewed as conceptual.
1.1.2.3 Logical Data Model. The Logical Data Model represents all of the
information within scope and is based upon breaking down the high level concepts into
specific information that is regularly used. For example, a tank is an armoured fighting
vehicle that is a piece of equipment that is a piece of materiel. This breakdown follows
human reasoning patterns and allows command and control systems to generalise by
recognising, for instance, that tanks are equipment. A logical data model specifies the data
structure using an entity-attribute-relationship diagram supplemented by supporting
documentation. This model should be of interest to staff officers to ensure that the
operational information content is complete. Most of the main part of the document as
well as a number of annexes focus on logical aspects of the model.
1.1.2.4 Physical Data Model. The Physical Data Model provides the detailed
specifications that are the foundation for an information exchange mechanism. It may also
be the basis for physical schemata that define database structure in national systems. The
physical data model is of primary concern to C2IS system developers building JC3IEDMcompliant systems. The specification of the physical data model is to be found in the
annexes to this document. One annex is the MIP Information Resource Dictionary (MIRD)
that stores all of the logical and physical metadata. It serves as the authoritative source of
JC3IEDM specifications.
1.1.2.5 Data Modelling Tool. The diagrams for the model are documented in
IDEF1X notation using ERwin™ Version 4.1.4 software from Computer Associates
International, Inc.
1.1.3 The Notion of a C2 Data Model as a Hub
1.1.3.1 A C2 data model of necessity must encompass information from multiple
functional areas in the domain of military operations. Consequently, a C2 data model
serves as a "hub" for unifying information concepts that are embodied in the data
specifications of functional areas. The concept of interdependence between the C2 data
model and the speciality subjects represented by functional areas is illustrated in the figure
below.
1.1.3.2 The desired goal in the long run would be a federation of data
specifications that use the C2 data model as the basis for functional area models. This
would ensure that the data that is common is viewed and structured in a standard way and
3
V3.1.4
that the data model views can be readily integrated into coherent structures wherever such
integration is needed.
1.1.3.3 Initial evolution of the model included specific inputs from the following
functional areas: conventional fire support, barrier engineering operations,
communications and electronics, and personnel administration. Operational requirements
have been drawn from these as well as other areas, as documented in Chapter 2.
Figure 1. C2 Data in Relation to Functional Areas
1.2
Purpose of JC3IEDM Documentation
The aim is to provide the following:
a.
A description of the common data in an overall model that contains all
relevant data abstracted in a well-structured and normalised way,
unambiguously reflecting their semantic meaning.
b.
A base document that can be used as a reference for future amendments to
the model.
c.
A core upon which nations can base their own modelling efforts of chosen
areas and onto which specialised area models can be attached or "hung."
d.
A basic document that nations can use to present and validate functional data
model views with their own specialist organisations.
e.
A specification of the physical schema required for database implementation.
1.3
Scope
The scope of the JC3IEDM is directed at producing a corporate view of the data
that reflects the multinational military information exchange requirements for multiple
4
V3.1.4
echelons in joint/combined wartime and crisis response operations (CRO). The data model
is focused on information that supports:
•
Situational awareness
•
Operational planning
•
Execution
•
Reporting
The scope includes data from various functional areas according to the requirements
levied by MIP and NATO.
1.4
1.5
Structure of This Document
1.4.1 The organisation of the main body of this paper is summarised as follows:
a.
Introduction (Chapter 1).
b.
Overview of Requirements (Chapter 2) provides a general statement of
requirements for the data specifications.
c.
Overview of the Conceptual Data Model (Chapter 3) provides a general
description of design considerations, a brief description of the model
concepts in operational terms, and a summary description of the model in
technical terms.
d.
Details of the Logical Data Model (Chapters 4 to 20) cover the following
topics: Introduction (highlights of the data structures, operational
requirements for the structure, and design considerations); Subject Area
Exposition (structure, entity and attribute definitions, explanation of the
structure, illustrative examples, and pointers to operational uses of the data);
Business Rules (restrictions that are needed for interoperability but cannot be
readily captured within the formal modelling methodology); and Comments
(any further topics that are worthy of inclusion but do not fit into any of the
categories cited above).
e.
Details of Physical Data Model Specification (Chapters 21 to 23). These
chapters provide rationale for the physical specifications and promulgate
some of them. The remainder are contained in the annexes.
Conventions for the Presentation of Examples
1.5.1 Introduction
1.5.1.1 Relational schemas at the logical level consist of entities, attributes, and
relationships. At the physical level, entities are termed tables and attributes are the
columns in a table. Examples in this document are presented in the form of physical
tables; however, logical names are used for labelling tables and columns uses. In general,
occurrence of an entity is termed an instance, whereas occurrence of an attribute is termed
a value.
1.5.1.2 The columns in an instance table correspond to attributes of the entity
whose name is given at the top of the table. Each row lists the example attribute values for
5
V3.1.4
an instance of an entity. The values in an instance table are for illustration only and are not
intended for use in implementation databases.
1.5.1.3 The specific conventions for presentation are listed in the following section.
1.5.2 Conventions
1.5.2.1 Use of double line. A double vertical line is used to separate those columns
corresponding to key attributes on the left from the non-key attributes on the right. A
double horizontal line separates the row with attribute names from the rows containing
values.
ENTITY-NAME
key attribute 1
key attribute 2
non-key attribute 1
non-key attribute 2
Value
Value
Value
Value
Value
Value
Value
Value
1.5.2.2 Null value. A dash (—) as an attribute value denotes a null value.
ENTITY-NAME
key attribute
non-key attribute 1
non-key attribute 2
Value
Value
Value
Value
Value
—10
1.5.2.3 Abbreviation of attribute name. Sometimes, for better readability or to
accommodate lengthy logical names, the attribute names are abbreviated. One or more
asterisks replace part of the attribute name with the replacement rules given in a note
below the table. The replacement rule is unique to each table. The first table below
features full attribute names, while the attribute names in the second table are abbreviated:
MILITARY-OBSTACLE-TYPE
military-obstacletype-id
military-obstacle-type-categorycode
military-obstacle-typesubcategory-code
6420
6421
6422
Dragon teeth
Roadblock
Tetrahedron
Moveable and prefabricated
—
**-id
**-category-code
**-subcategory-code
6420
6421
6422
Dragon teeth
Roadblock
Tetrahedron
—
Note: ** = "military-obstacle-type"
1.5.2.4 Split table. If an instance table with many attributes cannot be shown as a
single array, then it is split into two parts. The split is marked by a dashed line at the
location of the split.
10
A dash (—) denotes a null value. This convention is used throughout the document.
6
V3.1.4
RAILWAY
**-id
**-trackgauge-code
**-trackcount
**-train-densitycount
**-block-distancedimension
**-sleeper-densitydimension
8100
Standard
2
100
1000
1
8200
Standard
1
50
500
1
Note: ** = "railway"
**-gross-trailingload-quantity
**-maximumspeed-rate
**-tractionsystem-code
**-signalsystem-code
**-signal-systemefficiency-code
50
100
100
70
Electric
Not electric
Semaphore
Position light
75%
85%
The primary key is sometimes inserted in front of the second part (and any subsequent
part) of an instance table for better readability. This is particularly useful when there are
many rows. The values for all native and foreign key entries are for representation only as
the requirement for data exchange is that the fields must be completely filled.
RAILWAY
**-id
**-trackgauge-code
**-trackcount
**-train-densitycount
**-block-distancedimension
8100
8200
Standard
Standard
2
1
100
50
1000
500
1
1
**-id
**-signal-systemefficiency-code
8100
8200
50
100
100
70
Electric
Not electric
Semaphore
Position light
75%
85%
1.5.2.5 Omission of attributes. A single wavy line at the right side of an instance
table indicates that the columns for the rest of the non-key attributes have been omitted. A
double wavy line between two attributes in an instance table indicates that columns for
one or more non-key attributes have been omitted.
RAILWAY
**-id
**-trackgauge-code
**-trackcount
8100
8200
Standard
Standard
2
1
1
1
50
100
Electric
Not electric
Semaphore
Position light
1.5.2.6 Omission of first non-key attribute. If the first non-key attribute is
omitted or the first non-key attribute and additional sequential attributes are omitted, then
the “candy cane” line at the right side of the key attributes is used.
REPORTING-DATA
*-id
3201
3202
3203
**-countingcategory- indicatorcode
code
*-credibility-code
Reported
Reported
Reported
Yes
Yes
Yes
Reported as a fact
Reported as a fact
Reported as a fact
*-reporting-datetime
*-timingcategorycode
*-reportingorganisation
-id
20050414113000.000
20050421140000.000
20050428123000.000
[Absolute]
[Absolute]
[Absolute]
[2nd MTF]
[2nd MTF]
[2nd MTF]
Note: * = "reporting-data"
7
V3.1.4
1.5.2.7 Use of brackets ( [ ] ). Brackets indicate the actual data that is being
referred to as an aid in readability. Most often the value is inserted next to an identifier to
indicate the object that is referenced by the identifier, as in the following example:
ACTION-OBJECTIVE-ITEM
actionaction-objectiveid
index
action-objective-itemcategory-code
action-objective-itemprimacy-code
object-item-id
1
2
3
4
5
1
1
1
1
1
Not otherwise specified
TARGET
Primary
Primary
Alternate
Primary
Alternate
15 [Control feature "Steel"]
14486 [6 Guards Tank Division]
16 [Feature—Hill 126]
57 [52 Inf Div]
17 [Feature—Hameln]
6
1
Secondary
18 [Control feature—Route Club]
Brackets are also used to represent the actual data in place of an identifier. In physical
implementation the column would contain only the identifier; in the example below the
name of the organisation that the identifier refers to would be contained in other tables:
OBJECT-ITEM-STATUS
object-item-id
object-itemstatus-index
object-item-statuscategory-code
*-emissioncontrol-code
reportingdata-id
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
1
2
3
4
5
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
—
—
—
—
—
3201
3202
3203
3204
3205
8
V3.1.4
2.
OVERVIEW OF REQUIREMENTS
2.1
Introduction
This chapter provides an overview of the information exchange requirements that
underpin the model. The requirements range from general in the first phase to specific in
the later phases.
2.2
General Requirements in ATCCIS Phase III
2.2.1 Modelling work started early in Phase III (in 1992) without a formal
statement of information exchange requirements. The Data Subgroup was staffed by a
combination of serving military officers and technical experts. The extensive military
experience resident in the group assured that the initial design would be a sound basis for
further development to incorporate the general concepts outlined in the table below.
Table 2. Summary of Information Requirements
Major Topic
Information Category
Forces (friendly and enemy)
Force composition
Force disposition
Force sustainment
Mobility and transportation
Weapons systems
C4I and other information systems
Land
Sea
Air
Space
Political
Cultural
Economic
Mission
C3 conditions
Intelligence
Targeting
Deployment, movement, and manoeuvre
Force security
Sustainment
Environmental conditions—physical
Environmental conditions—civil
Situational information
Operational context
—
2.2.2 The table below expands the summary. It should be understood that the
goal was to use the categories of information selectively to accommodate only those
aspects that were germane to exchange of information between national C2 elements and
within multinational formations.
9
V3.1.4
Table 3. Categories of Operational Information
Information Category
Definition
1. Friendly or Enemy Forces
1.1 Force Composition
1.2 Force Disposition
Types and numbers of military and non-military forces.
Locations of military forces.
1.3 Force Sustainment
1.4 Mobility and
Transportation
Capabilities for logistical support (supply, maintenance, medical, etc.).
Capability for inter- and intra-theatre movement of forces and materiel.
1.5 Weapon Systems
1.6 C4I and Other
Information Systems
Type, number, capabilities, and limitations of weapon systems.
Type, number, capabilities, and limitations of C4I and other information processing systems.
2. Environmental Conditions
Factors arising from nature and the physical environment as modified by man. Includes
land, sea, air, and space.
2.1 Physical
2.1.1 Land
2.1.2 Sea
2.1.3 Air
2.1.4 Space
2.2 Civil
2.2.1 Political
2.2.2 Cultural
2.2.3 Economic
3.1 Mission Information
3.2 Command, Control,
and Communications
3.3 Intelligence
3.4 Targeting
General characteristics of natural and man-made terrain and geological features. Includes
information on buildings and infrastructure (roads, communications, etc.) appropriate to the
mission.
General characteristics of the ocean surface and subsurface, harbours, and littoral (coastal)
waters.
General characteristics of the lower atmosphere, including climate, visibility, and weapon
effects on the atmosphere.
General characteristics of the upper reaches of earth’s atmosphere.
Information about political, cultural, and economic conditions in the areas (hostile, friendly,
and neutral) of military interest.
Information relating to the people, their national government, and international and nongovernment organisations.
Information relating to language, customs, laws, and religion.
Information relating to manpower, materiel, and money.
3. Situational Awareness Information
Factors that frame and influence the execution of the mission. Includes instructions and
policies; rules of engagement; status of preparations for the mission; description of the
theatre; and time constraints.
Command relationships and procedures for effective management of forces and
accomplishment of the mission. Includes planning, communications systems connectivity,
and interoperability.
Threat-related information and general information regarding the enemy that affects mission
accomplishment. Includes enemy doctrine, probable courses of action, and vulnerabilities.
Information relating to targets. Includes dispersion, camouflage, hardness, identification,
mobility, and range from potential attacking forces.
3.5 Deployment,
Movement, and
Manoeuvre
Status of lines of communication and planning for deployment, movement or manoeuvre.
3.6 Force Security
3.7 Sustainment
Information regarding rear area security; and air, maritime, and land superiority.
Information relating to the sustainment of forces in conducting the mission.
—
4. Operational Context
Scenarios and missions involved
Phases of operation (peace, crisis, war)
Stress and threat levels.
Organisations and locations affected
Operational perspective (national, theatre, tactical).
2.2.3 The Data Subgroup supplemented the general requirements with
contributions and suggestions from individual delegates who used various reference
documents as sources, including NATO STANAGs and messages, national field manuals
and guides for tactical operations, and selected standard operating procedures. The general
considerations that emerged for model design are listed below:
a.
Objects of military significance need to be identified. In this context,
"objects" refer to physical things including units, equipment, stores,
10
V3.1.4
personnel, facilities, geographic features, and also to non-physical concepts
such as coordination points, lines, and areas. Such objects may already exist
and be known; they may also be newly identified or projected in the future.
b.
Individual objects must be distinguished from the classes of objects to which
they belong. Many objects are of interest primarily in terms of their class or
category rather than as an individual object; for example, tanks, armoured
brigades, or infantrymen.
c.
Objects and their types need to be described with a number of characteristics
that are sufficient for supporting command and control tasks. For example, it
must be possible to describe the size of a unit, the name of a commanding
officer, or the military load classification of a bridge. Such information tends
to be dynamic in nature; as new information becomes available other
information becomes outdated or nullified.
d.
An explicit subset of the requirement in paragraph c is the need for
information elements associated with objects to permit suitable display of the
operational situation.
e.
Selected information about certain characteristics of objects needs to be
retained for a period of time. For example, it must be possible to keep a
historical log of the location of a unit for purposes of tracking and to specify
predicted future locations of a unit for purposes of planning. Such a time
record is also needed for other dynamic characteristics of objects, such as
their operational or personnel status and their holdings in terms of other
objects (e.g., the number of troops and/or equipment in a particular unit).
2.3
Fire Support Requirements
2.3.1 Some requirements were gleaned from specialised functional areas. One of
these was fire support. Fire support is the collective and coordinated use of indirect fire
weapons, armed aircraft, and other lethal and non-lethal means in support of a battle plan.
2.3.2 Fire support consists of three essential parts: command and control, target
acquisition for intelligence use, and employment of attack resources. These elements
constitute a good description of the more general C2 challenge.
a.
Command and control. A large part of C2 activity consists of
synchronisation, which is defined as the arrangement of military actions in
time, space, and purpose to produce maximum relative combat power at a
decisive point.
b.
Target acquisition for intelligence use. Target acquisition allows the joint or
combined force to detect, identify, and locate targets with sufficient accuracy
and timeliness to permit their attack. It is a product of intelligence derived
from comparison, corroboration, integration, analysis, and evaluation of
information collected by any of the intelligence disciplines such as signals
intelligence (SIGINT), human intelligence (HUMINT), and imagery
intelligence (IMINT).
c.
Employment of attack resources. The following attack resources may be
employed in fire support: mortars, cannon (howitzers and guns), rocket and
missile launchers, fixed wing aircraft, rotary wing aircraft, naval gun fire
11
V3.1.4
(NGF), and electronic warfare (EW). The attack resources can be
characterised as lethal or non-lethal. Lethal fire support resources include
field artillery and mortars, NGF, and air support. Non-lethal fire support
resources include offensive EW, reflected energy emitters, and smoke and
illumination munitions and their delivery systems.
2.3.3 The types of information to be exchanged in multinational and joint fire
support operations are exemplified by the following categories:
a.
Joint and combined fire support planning, allocation of resources, and
commanders' guidance.
b.
Enemy and situation data including target identification and location
information.
c.
Fire support requests and schedule of fires.
d.
Friendly force location and scheme of manoeuvre information.
e.
Joint terminal control actions as provided by a forward air controller,
forward observer, gunfire spot team, or laser designation team.
f.
Coordination and integration of joint use of lethal and non-lethal assets.
g.
Battle damage assessment information of friendly and enemy fires.
h.
Ammunition status.
2.4
Requirements in Phase IV
2.4.1 IERs for Phase IV were produced by the newly formed Operational Group
at the first meeting11. The initial set selected by the Operational Group is listed in the table
below. IERs are grouped according to staff function under column heading “Domain.” The
last column lists the tracking number that is used in a subsequent table.
11
ATCCIS meeting AWG IV-1 in September 1997 at Ede, The Netherlands.
12
V3.1.4
Table 4. Initial Minimum Set of Essential IERs
Domain
Abbreviation
Short title
Source
No
G2
FIRST HOSTILE ACT
First Hostile Act
APP9
16
INTREP
Intelligence Report
APP9
21
INTREQ
Intelligence Request
APP9
22
G3
G4
G1
INTSUM
Intelligence Summary
APP9
23
LANDINTREP
Land intelligence Report
APP9
25
ENSITREP
Enemy situation report
APP9
14
PRESENCE
Presence
APP9
39
OWNSITREP
Own Land Force Situation report
APP9
37
ROEREQ
Rule of engagement request
APP9
42
ROEIMPL
Rule of engagement implementation
APP9
41
ASSESSREP
Commander's assessment
APP9
6
NBCCDR
NBC Chemical Downwind Report
APP9
33
NBCEDR
NBC Effective Downwind Report
APP9
34
NBC1
NBC 1
APP9
31
NBC3
NBC 3
APP9
32
OPO Std 2014
Operational Order
Stanag 2014
OPLAN
Operational Plan
Stanag 2014
FRAGO
Fragmentary order
APP9
18
LOGSITLAND
Logistic Situation Report Land Forces
APP9
27
LOGASSESSREP
Logistic Assessment Report
APP9
26
CASAVACREQ
Casualty Evacuation request
APP9
8
PERSREP
Personnel report
APP9
38
MEDASSESSREP
Medical assessment report
APP9
28
MEDSITREP
Medical Situation report
APP9
29
Fire
NNFP.FP
Non-Nuclear Fire Planning. FP
APP9
35
Support
FMR.FMC
Fire Mission Report. Fire mission
Command
APP9
17
AFU.FUS
Artillery Fire Unit Fire Unit Status
APP9
3
Engineer
BARREP
Barrier Report
APP9
7
Support
OBSREP
Obstacle Report
APP9
36
DMLORD
Reserved Demolition Order
APP9
13
SCATMINWARN
Scatterable Minefield Warning
APP9
47
SCATMINREQ
Scatterable Minefield Request
APP9
46
SCATMINREP
Scatterable Minefield Report
APP9
45
Air
WCO
Weapons Control Order
APP9
48
Defence
ADREP
Air Defence Report
APP9
2
ACO
Airspace Control Order
APP9
1
AIRATTACKWARN
Air Attack Warning
APP9
4
AIRREQ
Air Request
APP9
5
HELLSREP
Helicopter Landing site report
APP9
19
HELQUEST
Helicopter Request
APP9
20
JAATMSNO
Joint Air Attack Team Mission Order
APP9
24
Air OPS
Helicopters
G5
CMOSITREP
Civil/military Operation order
APP9
10
Electronic
Warfare
MIJIWARNREP
Meaconing,Intrusion,Jammin,Interference
Warning Report
APP9
30
13
V3.1.4
Domain
G6
Abbreviation
Short title
Source
No
EWRTM
EW Request/Tasking Message
APP9
15
CCISSTAREP
CCIS Status Report
APP9
9
COMSITREP
Communications situation report
APP9
11
RFREQREQ
Radio Frequency Request
APP9
40
RRFREQREQ
APP9
43
2.4.2 This set of IERs is referred to as Article V requirements. The table below
provides brief description of each requirement. The purpose is copied directly from the
source document.
Table 5. Capsule Descriptions of Phase IV IERs
IER Name
Abbreviated Name
Reference
APP-9/2-5-7
Airspace control order
ACO
To standardise the method used to provide specific orders for airspace management from a higher
command to subordinate units.
APP-9/2-4-7-2
Air Defence Report
ADREP
To standardise the method used to provide a summary of Air Defence (AD) engagements since the last
ADREP, and to report the status and availability of AD equipment and ammunition.
APP-9/2-4-6-2
Artillery fire unit. Fire unit status
AFU.FUS
To report, amend or delete a record of ammunition held by a delivery unit for current or planned
operations.
APP-9/2-5-1
Air attack warning
AIRATTACKWARN
To standardise the method used to warn of imminent enemy air strikes against friendly forces. It may be
used in conjunction with either Global Early Warning (GEW) or Local Early Warning (LEW) messages
generated by automated AD systems.
APP-9/2-5-4
Air request
AIRREQ
To standardise the method used to request tactical air support for land or maritime operations.
APP-9/2-4-1-1
Commander’s assessment
ASSESSREP
To standardise the method used to advise superior Commanders of the situation/operations in the reporting
Commander's area of concern, his assessment of the overall situation, and his intended or recommended
actions based on that assessment.
APP-9/2-4-8-1
Friendly obstacle list-barrier report
BARREP
To standardise the method for disseminating information from formation to unit level on friendly
obstacles, current and planned, in the own forces barrier plan.
APP-9/2-1-3
Casualty Evacuation Request
CASEVACREQ
To request medical casualty evacuation support for single and multiple evacuation and by whatever
means. (Medical operational personnel responsible for planning, ordering and directing medical
evacuation will use information in this message to task medical evacuation assets).
CCIS Status Report
CCISSTATREP
APP-9/2-8-6 (A 347)
To standardise the method for providing information concerning the status of Command, Control and
Information Systems (CCIS).
Civil/Military Operations Situation
Report
CMOSITREP
APP-9/2-10-2
To standardise the method for submitting Civil/Military Operation (CMO) Situation Reports.
Communications Situation Report
COMSITREP
APP-9/2-8-7
To standardise the method for submitting daily communications reports to provide a summary of
friendly forces communications and information systems status in support of operations and exercises.
14
V3.1.4
IER Name
Reserved demolition order
Abbreviated Name
DMLORD
Reference
APP-9/2-4-8-8
To standardise the method for disseminating information relating to the execution of a reserved
demolition.
APP-9/2-4-1-3
Enemy Land Forces Situation
ENSITREP
Report
The method used to report and inform on the Enemy Forces situation, to include: locations, boundaries,
status, Order of Battle (ORBAT) and subordination of units / formations.
APP-9/2-4-13-6
EW Requesting/Tasking Message
EWRTM
To standardise the method used by a Joint Force Commander to task Electronic Warfare (EW) assets in
support of an operational plan. It is also used by component commanders to request the support of EW
resources outside their command.
APP-9/2-2-6
First Hostile Action
FIRST HOSTILE ACT
To rapidly provide Supreme Allied Commander Europe (SACEUR) with information on initial enemy /
opposing force (OPFOR) hostile acts in order to enable him to react as early as possible.
Fire mission report. fire mission
command
FMR.FMC
APP-9/2-4-6-5
To standardise the method used to transmit a command to check fire, cancel check fire, cease loading,
cancel cease loading, and fire; to transmit ready, rounds complete, and cannot comply to the observer,
and to transmit the completion of a fire mission.
Fragmentary order
FRAGO
APP-9/2-4-1-4
To standardise the format for and essential elements of an abbreviated form of an Operation Order for use
between commands, formations and units. The FRAGO is intended for use to:
a.
Issue key sections of an Operation Order before the complete order has been produced.
b.
Provide specific instructions to commanders who do not require the complete Operation
Order.
c.
Provide a summary of the complete order to serve as confirmatory notes.
d.
Issue timely changes to the existing Operation Orders.
e.
Provide an outline operational directive (Mission Order) for use in fast moving mobile
operations.
APP-9/2-5-9
Helicopter Landing Site Report
HELLSREP
To standardise the method used to transmit helicopter landing site reports.
APP-9/2-5-11
Helicopter Request
HELQUEST
To standardise the method used by units to request transport helicopter or utility helicopter support.
APP-9/2-2-7
Intelligence Report
INTREP
To inform SACEUR, Allied Command Europe (ACE) commanders and other addressees of essential
elements of intelligence information obtained through tactical collection efforts. The INTREP provides
timely information regarding events that could have an immediate and significant effect on current or
pending planning and operations in peace, time of tension and war.
Intelligence Request
INTREQ
APP-9/2-2-8
To standardise the method by which military authorities and forces of NATO nations and NATO
commands request intelligence from each other.
Intelligence Summary
INTSUM
APP-9/2-2-10
To inform SACEUR and other addressees periodically on military and related politico / economic
intelligence and assessment thereof which give an indication of change in potential OPFOR capabilities,
preparedness, or military posture, activities, intentions, objectives and/or courses of action in peace,
time of tension and war.
15
V3.1.4
IER Name
Abbreviated Name
Reference
APP-9/2-5-14
Joint Air Attack Team Mission
JAATMSNO
Order
To standardise the method for providing essential information required in a Joint Air Attack Team
(JAAT) Mission Order (Msn O).
APP-9/2-2-11
Land Intelligence Report
LANDINTREP
To inform SACEUR of significant changes in the location, combat effectiveness, and other essential
elements of information concerning Non-NATO ground Order of Battle (OOB) formations/Units (land
forces including naval infantry).
APP-9/2-6-1-1
Logistic Assessment Report
LOGASSESSREP
To inform superior headquarters of the command’s logistics status and to provide an assessment of the
overall logistics situation for forces, together with intended or recommended action.
Logistic Situation Report Land
Forces
LOGSITLAND
APP-9/2-6-1-6
To standardise the method for providing a superior headquarters with an evaluation of a unit or
formation’s logistic situation, capability, and deficiencies/surpluses. [Deficiencies/surpluses in logistic
holdings may be reported separately by the LOGDEFREP (IER ref APP-9 / 2-6-1-4) or LOGSURPREP
(IER ref APP-9 / 2-6-1-7) messages respectively.]
Medical Assessment Report
MEDASSESSREP
APP-9/2-6-2-1
To inform higher formations of the Medical and Health services status and to provide an overall
assessment of the Medical and Health services situation for in-place and reinforcing forces, together
with any remedial action taken or planned.
APP-9/2-6-2-2
Medical Situation Report
MEDSITREP
To inform higher formations of the Medical and Health services situation for friendly forces and/ or
other personnel for whom reporting is required, e,g, In case of peace support operations those personnel
operating under a UN mandate authority, or supporting civilian agencies and staff.
Meaconing, Intrusion, Jamming and
Interference Warning Report
MIJIWARNREP
APP-9/2-4-13-9
To standardise the method used in times of peace and crisis to warn NATO nations, Commands and
Units of hazardous electronic warfare (EW) situations caused by MIJI-incidents of hostile, friendly
(inadvertent) or unknown origin.
APP-9/2-4-5-5
Nuclear Biological and Chemical
NBC1
Report 1
To standardise the method used to report and inform on NBC events. This report is specifically used to
provide the observer's initial report giving basic data on a single nuclear, biological or chemical attack.
APP-9/2-4-5-7
Nuclear Biological and Chemical
NBC3
Report 3
To standardise the method used to report and inform on NBC events. This report is specifically used to pass
immediate warning of predicted contamination and hazard areas following an NBC attack.
NBC Chemical Downwind Report
NBCCDR
APP-9/2-4-5-2
disseminate a forecast of all meteorological data required for the chemical hazard area prediction procedure.
It is sent every 6 hours and covers 3 consecutive 2 hour periods.
APP-9/2-4-5-3
NBC Effective Downwind Report
NBCEDR
provide the effective down wind data needed for the prediction of fallout areas following a nuclear burst, for
either the nearest 6 hours or for a period of more than 6 hours ahead.
APP-9/2-4-6-8
Non nuclear fire planning. fire plan
NNFP.FP
To standardise the message format used to transmit fire plan targets and/or orders in a specified target
list, to delete fire plan targets and/or orders from a specified target list in a fire plan or to delete an
entire plan.
16
V3.1.4
IER Name
Obstacle report
Abbreviated Name
OBSREP
Reference
APP-9/2-4-8-7
To standardise the method for reporting obstacles up the chain of command.
APP-9/2-4-1-8
Own Land Forces Situation Report
OWNSITREP
To standardise the method used to report and inform on the Own Land Forces situation, to include
deployment, status and/or Order of Battle (ORBAT) or Task Organisations (TASKORG) of own and
subordinate units/formations, and to report the presence of units/formations/installations not under command.
APP-9/2-1-5
Personnel Report
PERSREP
Provides commanders and staffs with a summary of personnel information by quantities and categories.
APP-9/2-4-4-2
Presence
PRESENCE
To standardise the method for identifying or confirming the presence of units/formations/installations within
a particular area. The report is used to keep a commander informed on the deployment of all military
units/formations/installations within his area of responsibility that both are and are not under his command.
APP-9/2-8-5
RFREQREQ
To standardise the method for requesting allocation of radio frequencies other than for radio relay.
Rule of engagement implementation
ROEIMPL
APP-9/2-4-2-3
To standardise the method for formally implementing or cancelling Rules of Engagement (ROE(s)).
Rule of engagement request
ROEREQ
APP-9/2-4-2-2
To standardise the method by which SACEUR requests from the NATO Defence Planning Committee
(DPC), and Subordinate Commanders request from SACEUR, authority to implement specific Rules of
Engagement (ROE(s)) within his/their command area.
Radio Relay Frequency Request
RRFREQREQ
APP-9/2-8-6
To standardise the method for requesting allocation of radio relay frequencies.
Scatterable minefield report
SCATMINREP
APP-9/2-4-8-11
To standardise the method for disseminating information required for a friendly scatterable minefield report.
APP-9/2-4-8-12
Scatterable minefield request
SCATMINREQ
To standardise the method for disseminating information required for a friendly scatterable minefield request.
APP-9/2-4-8-13
Scatterable minefield warning
SCATMINWARN
To standardise the method for disseminating information required for a friendly scatterable minefield
warning.
STANAG 2014
Operation order
OPO
To standardise the format for and essential elements of an Operation Order for use between commands,
formations and units.
STANAG 2014
Operation Plan
OPLAN
To standardise the format for and essential elements of an Operation Plan for use between commands,
formations and units.
APP-9/2-4-7-5
Weapons Control Order
WCO
To standardise the method used to order a new Air Defence (AD) weapon control status over a specific
area(s) for a given period of time.
2.4.3 Since each IER encompasses a relatively broad range of data, the IER was
partitioned into a set of smaller and more manageable pieces that are referred to as
Information Content Elements (ICEs). The table below lists the IERs and their ICE count.
17
V3.1.4
Percentage Complete
100%
5
5
100%
2
25
23
1
1
1
18
16
13
13
100%
10
10
100%
7
7
100%
10
9
6
6
100%
1
5
5
100%
12
9
3
2
DMLORD
16
3
13
13
14
ENSITREP
24
2
22
21
15
EWRTM
10
5
4
4
100%
16
FIRST HOSTILE ACT
8
8
8
100%
17
FMR.FMC
6
3
2
2
100%
18
FRAGO
29
1
28
28
100%
19
HELLSREP
22
21
21
100%
20
HELQUEST
11
11
10
21
INTREP
5
3
1
1
22
INTREQ
29
2
2
25
24
23
INTSUM
22
1
2
19
19
100%
24
JAATMSNO
31
3
28
28
100%
25
LANDINTREP
21
19
18
26
LOGASSESSREP
4
4
4
100%
27
LOGSITLAND
10
10
10
100%
28
MEDASSESSREP
9
7
7
100%
29
MEDSITREP
14
14
14
100%
30
MIJIWARNREP
7
7
7
100%
31
NBC1
19
1
17
17
100%
32
NBC3
13
1
12
12
100%
33
NBCCDR
5
1
4
4
100%
34
NBCEDR
4
1
3
3
100%
1
ACO
8
2
ADREP
6
1
3
AFU.FUS
28
1
4
AIRATTACKWARN
1
5
AIRREQ
21
2
6
ASSESSREP
13
7
BARREP
13
8
CASEVACREQ
7
9
CCISSTATREP
13
10
CMOSITREP
6
11
COMSITREP
6
12
COMMON
13
Requirement
Withdrawn
3
1
2
1
1
1
1
2
2
1
18
Incomplete
Complete
8
IER
Not Applicable
8
No
ICE Grand Total
Requirement Total
Clarification Needed
Table 6. Article V Requirements and Fulfilment in the Model
2
92%
100%
2
89%
1
90%
1
67%
100%
1
1
95%
91%
100%
1
96%
1
95%
Complete
Incomplete
Percentage Complete
Requirement Total
24
23
1
10
10
100%
23
23
23
100%
PERSREP
4
4
4
100%
39
PRESENCE
8
2
6
6
100%
40
RFREQREQ
14
6
8
6
41
ROEIMPL
10
8
8
100%
42
ROEREQ
7
7
7
100%
43
RRFREQREQ
10
10
10
100%
44
SCATMINREC
16
2
14
14
100%
45
SCATMINREP
13
2
11
11
100%
46
SCATMINREQ
18
2
16
16
100%
47
SCATMINWARN
13
2
11
11
100%
48
WCO
8
8
8
100%
550
537
Not Applicable
4
ICE Grand Total
Requirement
Withdrawn
Clarification Needed
V3.1.4
35
NNFP.FP
31
3
36
OBSREP
12
2
37
OWNSITREP
38
No
IER
Grand Total
640
2
50
40
96%
2
11
75%
2
97%
2.4.4 The table provides an accounting of the disposition of requirements. The
categories are as follows:
a.
Complete—Data identified in the ICE can be represented in the model or is
derivable from the model.
b.
Incomplete—Data identified in the ICE cannot be fully represented in the
model; modifications to the model may entail addition of domain values,
new attributes or new entities.
c.
Clarification Needed—The ICE definition is either ambiguous or contains
references to undefined acronyms or abbreviations that cannot be deciphered
by the analysts.
d.
Requirement Withdrawn—An initial requirement put forth by the
Operational Group has been withdrawn from further consideration.
e.
Not Applicable—The type of data identified in the ICE definition is not
appropriate for the data model specification. It generally deals with data that
applies to the structure or administration of the underlying IER as a
formatted message.
2.4.5 ICEs that are categorised as Not Applicable or Requirement Withdrawn are
subtracted from the grand total. The result is labelled Requirement Total and it represents
the basis for accounting the degree to which the model satisfies requirements. The basis
ICEs then are assessed as Complete, Incomplete, or Clarification Needed. The column
Percentage Completed expresses the ratio of Complete to Requirement Total.
19
V3.1.4
2.5
Requirements during ATCCIS 2000 (Phase V)
2.5.1 Work on Article V requirements continued during Phase V. The
Operational Group issued an additional set of requirements at first referred to as Peacetime
Support Operations (PSO), later changed to Military Operations Other Than War
(MOOTW)12. Near the end of the phase NATO adopted the expression Crisis Response
Operations (CRO) in lieu of MOOTW.
2.5.2 CRO requirements are listed in the table below to indicate the general
categories that are covered. Detailed elements are not shown because they are stored in an
Access database. The Operational Group drew upon multiple sources to produce a set that
is unique to the ATCCIS programme and is not documented elsewhere. The categories are
the same as for Phase IV.
Percentage
Complete
Clarification
Needed
Incomplete
Complete
IER
No
ICE Grand
Total
Table 7. CRO Requirements and Fulfilment in the Model
1
Arrest Report
11
11
100%
2
Border Crossing
22
22
100%
3
Camps
26
17
100%
4
Civil Military Operations
47
46
5
Confiscated Equipment
44
42
6
EOD Incident
28
28
7
Holdings Parties
37
35
8
Host Nation Support
13
13
9
Incident Report
183
175
10
Mass Graves
16
16
100%
11
Meteorology
22
22
100%
12
Personnel Identification
36
36
100%
13
PSYOPS
24
22
14
Refugees and Displaced
Persons
9
9
Grand Total
518
503
1
2
98%
95%
100%
2
95%
100%
4
4
2
95%
92%
100%
10
5
97%
2.5.3 ATCCIS Heads of Delegation enlarged the scope in Phase V by adding
requirements for joint interfaces that are needed to support land operations. Formal
12
Requirements were issued during AWG 2000-2 in September 2000 in Lisbon.
20
V3.1.4
requirements were issued13 by the Operational Group and are listed in the table below. The
requirements are stored in the same database form as was the case for CRO. The table
accounts for the ICEs in the same way as the previous table.
Airfield zone
8
8
100%
2
Aviation areas
6
6
100%
3
Aviation route
10
10
100%
4
Command and Control-Weapon points
5
5
100%
5
Coordination Altitude
5
5
100%
6
Forward Arming and Resupply Point
6
6
100%
7
Maritime Operational Graphics
5
5
100%
8
Close Air Support Resources
7
7
100%
9
Close Air Support Status
5
5
100%
10
Naval Gun Fire Resources
7
7
100%
11
Naval Gun Fire Status
5
5
100%
12
Airfield Facility
15
15
100%
13
Air Plan - Airspace Control Order14
62
58
14
Air Plan - Air Tasking Order
28
28
100%
15
Harbour Facility
8
8
100%
16
Order of Battle AIR
15
15
100%
17
Order of Battle SEA
16
15
18
Unit Tactical Summary
9
9
222
217
Grand Total
3
1
Percentage
Complete
Complete
1
IER
No
Incomplete
Grand Total
Clarification
Needed
Table 8. Joint Requirements and Fulfilment in the Model
95%
94%
100%
4
98%
2.6
MIP Block 1 Work
2.6.1 Work on outstanding issues from the Article V, CRO and CJTF IERs
continued during this phase of work.
2.6.2 The Data Modelling Working Party of the Data and Procedures Working
Group was given a limited set of requirements extracted from the MIP Tactical C2IS
13
14
Requirements were made available during AWG 2000-4 in March 2001 in Oslo.
There is one ICE that has been classified as Not Applicable.
21
V3.1.4
Interoperability Requirement (MTIR). The added requirements were specific in nature as
listed below:
a. Identification of a service number for personnel.
b. Emission control policy for units, facilities, and equipment.
c. Mission Oriented Protective Posture (MOPP) for units.
d. Chemical, Biological, Radiological and Nuclear (CBRN) threat levels for
control features.
e. New requirements for domain values for events, facilities and
organisations.
f.
Capability to specify dimensions for facilities.
2.7
MIP Block 2 Work
2.7.1 A major task in Block 2 was the merging of two data models: C2IEDM
Edition 6.1 and the NATO Corporate Data Model Version 4.0. The activities entailed a
detailed comparison of specifications at entity, attribute, and domain levels and resolution
of any differences in specifications (such as naming, definitions, or equivalent
representations). Extensive quality review was imposed on all products that included the
IDEF1X model itself, all documentation, and the data dictionary. The result was
JC3IEDM Edition 0.5—an interim release in December 2004.
2.7.2 Work continued with issues remaining from Block 1 and structural
improvements to the data specifications arising from new information exchange
requirements as well as any deficiencies that were uncovered as the result of testing or
analysis. Principal additions to the specification stemmed from several sources: air
tasking order, maritime mine warfare, CBRN, Allied Command for Transformation, and
the concept of Operational Information Group to support the information exchange
mechanism.
2.7.3 JC3IEDM version number was changed to Edition 3.0 vice Edition 1.0 in
order to bring it into correspondence with Block 3 of MIP programme of work.
2.8
MIP Block 3 Work
2.8.1 A major effort in Block 3 was an extension to accommodate the concept of
plans and orders in accordance with STANAG 2014 Edition 9. Now the extension
provides a structure for the management of plans and orders, enables the combined use of
data and textual elements as content, and smoothes the transition from purely text-based
plans and orders to a largely structured form.
2.8.2 Considerable amount of effort was devoted to dealing with any deficiencies
uncovered during testing or analysis and documented through the MIP Problem Report
(MPR) system. This work included accommodation of any operational requirements that
were deemed critical for Block 3. The activity to finalize Block 3 baseline specification
was given first priority. The work to incorporate requirements into future versions was
conducted in parallel as a second priority.
22
V3.1.4
2.8.3 The ability to support Tactical reporting of Improvised Explosive Devices
(IEDs) was identified as a high priority requirement for the JC3IEDM. Using the Weapons
Technical Intelligence IED Lexicon (December 2008) developed by the Joint Improvised
Explosive Device Defeat Organization (JIEDDO), this capability was added in the 3.1.1
version of the model.
2.8.4 Additional requirements were identified from the Operational Situation
Report Irregular Actor (OPSITREP IA) Message Reference Number A011 (draft). A
limited set of those requirements were incorporated into the 3.1.1 Edition of the
specification.
23
V3.1.4
3.
OVERVIEW OF THE DATA MODEL
The overview presents principal features of the data structure. It also serves as an
introduction to the detailed exposition of the data model specifications to be found in the
remainder of the document. Section 3.1 summarises the basic concepts underlying the
design of the data model. Section 3.2 serves as a broad guide to the contents of data model
specification. The remaining material constitutes a high-level overview of the model. One
of the goals is to indicate the scope of the model in covering information categories of
interest to the operational user. Examples and explanations use operational language as
much as possible.
3.1
Concepts Underlying the Design of the Data Model
3.1.1 JC3IEDM is intended to represent the core of the data identified for
exchange in a command and control (C2) environment. As a minimum it needs to deal
with the following:
a.
The structure should be sufficiently generic to accommodate joint, land, sea,
and air environmental concerns.15
b.
All objects of interest in the sphere of operations need to be described to
include organisations, persons, equipment, facilities, geographic features,
weather phenomena, and military control measures such as boundaries.
c.
Objects of interest may be generic in terms of a class or a type and specific
in terms of an individually identified item. All object items must be
classified as being of some type (e.g. a specific tank that is identified by
serial number WS62105B is an item of type "Challenger" that is a heavy UK
main battle tank).
d.
An object must have the capability to perform a function or to achieve an
end. Thus, a description of capability is needed to give meaning to the value
of objects in the sphere of operations.
e.
It should be possible to assign a location to any item in the sphere of
operations. In addition, various geometric shapes need to be represented in
order to allow commanders to plan, direct, and monitor operations. Examples
include boundaries, corridors, restricted areas, minefields, and any other
control measures needed by commanders and their staffs.
f.
Several aspects of status of items need to be maintained.
g.
Composition of a type object in terms of other type objects needs to be
specified. Such concepts include tables of organisations, equipment, or
personnel.
h.
Information about what is held, owned or possessed by a specific object
needs to be reflected.
Currently, the model addresses primarily land operations and some joint interfaces. In
many cases, extensions to other functional areas can be accommodated by simply adding
appropriate vocabulary to the existing data elements.
15
24
V3.1.4
i.
There is a need to record relationships between pairs of items. Key among
these is the specification of unit task organisation and order of battle.
j.
Current, past, and future roles of objects as part of plans, orders, and events
need to be specified.
k.
The specifications should allow recording information for all objects,
regardless of their hostility status.
l.
Provision must be made for the identification of sources of information, the
effective and reporting times, and an indication of the validity of the data.
3.1.2 Use of free text is to be minimized, since there cannot be an agreed
understanding of most textual content, and textual content is generally not subject to
automated processing by a C2 system.
3.1.3 Some of the important rules for managing information cannot be
represented using a formal modelling standard; reliance needs to be placed on textual
supplements, often referred to as "business rules."
3.1.4 The overall goal is to specify the minimum set of data that needs to be
exchanged in coalition or multinational operations. Each nation, agency or community of
interest is free to expand its own data dictionary to accommodate its additional
information exchange requirements with the understanding that the added specifications
will be valid only for the participating nation, agency or community of interest. Any
addition that is deemed to be of general interest may be submitted as a change proposal
within the configuration control process for inclusion in future versions of the
specification.
3.2
Guide to Contents
3.2.1 Introduction
3.2.1.1 A schema based on relationships guarantees that almost any part of the
specification depends on one or more of the other parts. Such cross-dependence makes it
difficult to organise the document in a sequence that would make it easy to comprehend
the material. It may be necessary to move back and forth between chapters and between
sections in a chapter.
3.2.1.2 The model in its most abstract sense may be thought of as a metamodel that
provides the structural skeleton for following broad topics:
a.
Objects of interest and their inherent properties
b.
Past, present, or future situation as represented by facts about the objects
c.
Past, present, or future activities that involve the objects
d.
Mechanisms for grouping data into information packages.
The content of the model in terms of attributes and sets of enumerated values represents
the semantics of a given functional domain. The specific semantics of JC3IEDM flow
from the requirements that are characterised in Chapter 2. However, the generic structural
framework of the model readily supports extension of the model to accommodate
additional domain semantics.
25
V3.1.4
3.2.2 Objects
A basic element in data specification is the definition of the universe of discourse.
The first step is to characterise the objects about which information is to be held. For
JC3IEDM, these are facility, feature, materiel, organisation, and person either identified
uniquely as items or used according to their class or type characteristics. Both items and
types are needed as structural elements. The taxonomy of type objects in a hierarchical
structure is presented in Chapter 4. Corresponding taxonomy for item objects appears in
Chapter 5. The model requires that every item object must be classified as a type object.
Properties are associated with either type or item as most appropriate. The combination of
the two results in a full characterisation of an item. The linking mechanism is described in
Chapter 6.
3.2.3 Situational Awareness
Situational awareness entails a broad range of information about objects, including
type-to-type relationships, item-to-type relationships, capabilities of objects, affiliation of
objects, status of items, location of items, physical or electronic addressing of items, and
item-to-item relationships. There is no particular order that is more meaningful than
another and the reader is encouraged to follow one’s own interests.
a.
A most significant operational relationship between items and types specified
in Chapter 6 deals with the notion of possession where an item object is said
to own or control numbers object types (a specific unit has 5 of a given
vehicle type). The model refers to this relationship as a holding. Chapter 6
also contains a specification that permits the assignment by organisations of
their own codes to materiel types for purposes of standardised reporting
within their sphere of control.
b.
Status of items is specified in Chapter 7.
c.
An operational need to access items by means of physical or electronic
addressing is satisfied through the specification described in Chapter 8. This
chapter also contains a specification of networks (nominal Chapter 5 material
that is presented in Chapter 8 due to close relationship with addressing).
d.
Item-to-item relationships—referred to as associations—are described in
Chapter 9. In addition to general relationships, there is a special specification
for organisational structure that is intended to capture information such as
unit task organisation and order of battle.
e.
Capability descriptions can be attached either to types or to items as
amplifying information. The specification is presented in Chapter 10.
f.
Type-to-type relationships to describe composition are referred to as
establishment in the model and are specified in Chapter 11.
g.
Location of items refers both to geographic positioning and geometries that
may be assigned to them. The description is to be found in Chapter 12.
h.
A requirement to assign one or more categories of affiliation is satisfied
through the specification in Chapter 18.
26
V3.1.4
3.2.4 Activity, Plans, and Orders
Activity encompasses planning of operations and reporting of events. Plans may be
turned into orders. The basic specification of activity is presented in Chapter 15 and
describes the use of objects as resources, objectives, or effects of activity. Extensions to
enrich the specification of activity in several ways, including rules of engagements and
creation of lists of candidate targets, are presented in Chapter 16. Chapter 17 presents a
design to develop and store plan and order specifications that conform to STANAG 2014
provisions. The design permits activities specified as structured data to be used in
conjunction with text-based formats. Further extensions to deal with reconnaissance and
intelligence requests is specified in Chapter 18.
3.2.5 Grouping of Information
The model contains a structure entitled REPORTING-DATA that is related to most
instances of dynamic data. The description is contained in Chapter 13. A construct in
Chapter 14 referred to as context permits collections of individual records to be treated as
a package of information. Context structure has multiple uses and can be linked to items
and activities. There is also a provision for assessment to be attached to a context. Chapter
20 permits descriptive information of various kinds to be attached to groups of person
types.
3.3
Foundational Structural Elements
3.3.1 Entities
3.3.1.1 Basic concept in data specification is an entity, i.e., any distinguishable
person, place, thing, event, or concept about which information is to be kept. Properties or
characteristics of an entity are referred to as attributes. The attributes make explicit the
data that is to be recorded for each concept of interest.16 This edition of the model contains
292 entities. The entire structure is generated from 19 independent entities, that is, entities
whose identification does not depend on any other entity. All other entities are dependent
entities. Independent entities are defined in the table below. The general role that each
entity serves is also suggested.
Table 9. Independent Entities and Their Roles
Entity
Name17
ACTION
ADDRESS
Entity Definition
An activity, or the occurrence of an activity, that may utilise
resources and may be focused against an objective. Examples
are operation order, operation plan, movement order,
movement plan, fire order, fire plan, fire mission, close air
support mission, logistics request, event (e.g., incoming
unknown aircraft), or incident (e.g., enemy attack).
Precise information on the basis of which a physical or
electronic destination may be accessed.
Role in the Model
Dynamics
(How, what, when
something is to be done,
is being done, or has
been done.)
Provides means to record
postal and electronic
addresses.
A summary of IDEF1X methodology and notation that is used for data specification in this
document appears in Annex I.
17
The convention is to annotate the names of entities in capital letters and separate words by
hyphens. If the name of an entity is used in plural, then a lower-case "s" is appended to the name
without changing the name (e.g., the plural of CAPABILITY is written CAPABILITYs).
16
27
V3.1.4
Entity Name17
Entity Definition
Role in the Model
AFFILIATION
A specification of a country, nationality, ethnic group, functional
group, exercise group, or religion to which membership or
allegiance may be ascribed.
A list of selected battlespace objects or types that have
potential value for destruction or exploitation, nominated by
competent authority for consideration in planning battlespace
activities.
The potential ability to do work, perform a function or mission,
achieve an objective, or provide a service.
Provides means to assign
affiliations to type or item
objects.
Information to support
ACTION.
CANDIDATETARGET-LIST
CAPABILITY
COMPONENTHEADERCONTENT
COMPONENTTEXT-CONTENT
CONTEXT
RELATIVECOORDINATESYSTEM
GROUPCHARACTERISTIC
LOCATION
OBJECT-ITEM
OBJECT-TYPE
PLAN-ORDER
REFERENCE
REPORTING-DATA
RULE-OFENGAGEMENT
SECURITYCLASSIFICATION
VERTICALDISTANCE
Introductory subject matter intended to identify an element of a
plan or order.
A textual statement of substantive subject matter.
A collection of information that provides in its entirety the
circumstances, conditions, environment, or perspective for a
situation.
A rectangular frame of reference defined by an origin, x and y
axes in the horizontal plane, and a z-axis. The vertical z-axis is
normal to the xy-plane with positive direction determined from
the right-hand rule when the x-axis is rotated toward the y-axis.
A reference to a set of characteristics that may be used for
identifying a distinct collection of objects. Examples of
characteristics include age group, malady, gender, language,
and triage classification.
A specification of position and geometry with respect to a
specified horizontal frame of reference and a vertical distance
measured from a specified datum. Examples are point,
sequence of points, polygonal line, circle, rectangle, ellipse, fan
area, polygonal area, sphere, block of space, and cone.
LOCATION specifies both location and dimensionality.
An individually identified object that has military or civilian
significance. Examples are a specific person, a specific item of
materiel, a specific geographic feature, a specific coordination
measure, or a specific unit.
An individually identified class of objects that has military or
civilian significance. Examples are a type of person (e.g., by
rank), a type of materiel (e.g., self-propelled howitzer), a type of
facility (e.g., airfield), a type of feature (e.g., restricted fire area),
or a type of organisation (e.g., armoured division).
A planned or ordered scheme worked out beforehand for the
accomplishment of an operational objective.
Identification of a record of information.
The specification of source, quality and timing that applies to
reported data.
A specification of mandatory guidance for the way a given
activity is to be executed.
The security classification applicable to an information resource
within the domain of classified security information.
A specification of the altitude or height of a point or a level as
measured with respect to a specified reference datum in the
direction normal to the plane that is tangent to the WGS84
ellipsoid of revolution.
Indication of expected
capability for types and
actual capability for items
Used in conjunction with
plan and order
specifications.
Used in conjunction with
plan and order
specifications.
Multiple roles including
grouping of information.
Support to LOCATION for
specifying relative
geometry.
Supports the counting of
types of persons
according to selected
characteristics.
Geopositioning of objects
and creation of shapes
(Where)
Identifying individual
things.
(Who and What)
Identifying classes of
things.
(Who and What)
The top-level entity for
identification of a plan or
order.
Pointing to external
information in support of
REPORTING-DATA.
Support for the reporting
function.
Support to ACTION.
Support to CONTEXT,
NETWORK-SERVICE
and REFERENCE
Support to LOCATION in
specifying elevation or
height.
3.3.1.2 The independent entities and their relationships are illustrated in the figure
below. A dot at the end of a relationship line denotes "many." The relationships shown in
this diagram are either many-to-many (solid line with two dots) or non-identifying one-tomany (dashed line). For example, the relationship between OBJECT-ITEM and
28
V3.1.4
LOCATION is to be interpreted as a pair of statements that an OBJECT-ITEM may have
zero, one, or more LOCATIONs and that a LOCATION may apply to zero, one, or more
OBJECT-ITEMs. The entities that connect to the rest of the structure by means of nonidentifying relationships provide auxiliary specifications that are needed for precise
definition of the concepts that are being captured. Some of the relationships are recursive,
such as those relating ACTION to itself.
CANDIDATE-TARGET-LIST
RULE-OF-ENGAGEMENT
REPORTING-DATA
REFERENCE
CAPABILITY
ACTION
SECURITY-CLASSIFICATION
CONTEXT
COMPONENT-HEADER-CONTENT
PLAN-ORDER
COMPONENT-TEXT-CONTENT
OBJECT-TYPE
OBJECT-ITEM
LOCATION
VERTICAL-DISTANCE
RELATIVE-COORDINATE-SYSTEM
AFFILIATION
GROUP-CHARACTERISTIC
ADDRESS
Figure 2. Independent Entities in the Data Specification
3.3.1.3 The IDEF1X standard permits the use of many-to-many relationships only
at a conceptual level in explanatory diagrams such as this one. A fully developed data
model must replace the many-to-many relationships with the appropriate structures that
admit only one-to-many relationships. The resolution of many-to-many relationships can
lead to complex structures. The balance of the paper describes the result for JC3IEDM.
3.3.1.4 All model explanations in this chapter are presented at the entity level as in
the preceding figure. The following section summarises the basic concepts underlying the
data model. Subsequent chapters contain detailed descriptions of the fully attributed data
model.
29
V3.1.4
3.3.2 Identifying "Things" in the Sphere of Operations
3.3.2.1 "Things" must be identified as the first step—who are the actors and what
things are available to be used by or are used by the actors? Model design encompasses
two categories of objects: those that can be identified individually (by name—2 (SP)
Armoured Cavalry Brigade, Jubilation T. Cornpone, by call sign or serial number or
license plate or passport number, and so on) and those that represent grouped or class
properties (a tank, a ship, an M1A2 tank, a helicopter, a howitzer, a rifle, an armoured
brigade, a light infantry battalion, an infantryman, a refugee). The two categories are used
in parallel as basic structural elements of the model. Data characteristics are entered either
on the item side or the type side as appropriate. Any characteristic described on the type
side also applies to the item when the item is assigned a type classification. The linkage
from item to type is mandatory in the model.
3.3.2.2 JC3IEDM uses the name OBJECT-TYPE to refer to class objects and
OBJECT-ITEM for individually identified instances. Implicit in the distinction between
type and item is the assumption that data relating to OBJECT-TYPEs will tend to be
relatively static or persistent (i.e., the values of the attributes are not likely to change very
often over time), whereas the data characteristics related to OBJECT-ITEMs are likely to
be more dynamic. For example, if a characteristic is about a type (e.g., M1A1 Abrams
Tank), it is an attribute of OBJECT-TYPE. Thus, calibre of main gun, track width, and
load class are characteristics of OBJECT-TYPE. However, the call sign, actual fuel level,
munitions holdings, and current operational status of a specific tank are characteristics of
an OBJECT-ITEM. The mandatory classification of an instance of OBJECT-ITEM as an
instance of OBJECT-TYPE assures that the item inherits all the characteristics of the type.
3.3.2.3 Item and type objects are subdivided into extensive hierarchies. The firstlevel hierarchy is parallel and is illustrated in the figure below. There are five categories or
subtypes to encompass any object within the scope of the model: facility, feature, materiel,
organisation, and person. A subtype is the same thing as its parent, but it has some
properties that do not apply to its siblings. Complete subtyping is denoted by a double line
under the circle. It means that no other category is envisioned within the scope of the
model. A circle with one line underneath is a symbol for incomplete subtyping. It means
that more subtypes could be defined if needed. Definitions of subtype entities are
presented in the table below the figure.
3.3.2.4 The next three sections present specification to describe (a) the hierarchical
structure of types, (b) composition of types, and (c) the hierarchical structure of items.
Major relationships that connect types and items are discussed in subsequent sections.
30
V3.1.4
OBJECT-TYPE
OBJECT-ITEM
FACILITY-TYPE
FACILITY
FEATURE-TYPE
FEATURE
MATERIEL-TYPE
MATERIEL
ORGANISATION-TYPE
ORGANISATION
PERSON-TYPE
PERSON
Figure 3. First Level Subtyping of OBJECT-TYPE and OBJECT-ITEM
Table 10. Definition of First-Level Subtypes
Entity
Entity Definition
FACILITY
An OBJECT-ITEM that is built, installed, or established to serve some particular
purpose and is identified by the service it provides rather than by its content.
An OBJECT-TYPE that is intended to be built, installed or established to serve some
particular purpose and is identified by the service it is intended to provide rather than
by its content. Examples include a refuelling point, a field hospital, and a command
post.
An OBJECT-ITEM that encompasses meteorological, geographic, and control
features of military significance.
An OBJECT-TYPE that encompasses meteorological, geographic, and control
features of military significance. Examples include a forest, an area of rain, a river, an
area of responsibility.
An OBJECT-ITEM that is equipment, apparatus or supplies of military interest without
distinction as to its application for administrative or combat purposes.
An OBJECT-TYPE that represents equipment, apparatus or supplies of military
interest without distinction to its application for administrative or combat purposes.
Examples include ships, tanks, self-propelled weapons, aircraft, etc., and related
spares, repair parts, and support equipment, but excluding real property, installations,
and utilities.
FACILITY-TYPE
FEATURE
FEATURE-TYPE
MATERIEL
MATERIEL-TYPE
ORGANISATION
An OBJECT-ITEM that is an administrative or functional structure.
ORGANISATIONTYPE
An OBJECT-TYPE that represents administrative or functional structures.
PERSON
An OBJECT-ITEM that is a human being to whom military or civilian significance is
attached.
PERSON-TYPE
An OBJECT-TYPE that represents human beings about whom information is to be
held.
3.4
OBJECT-TYPE Hierarchy
3.4.1 The OBJECT-TYPE subtyping tree is extended beyond the first level as
illustrated in the figure below. The taxonomy of OBJECT-TYPE can be defined in
different ways. There is no right or wrong way. The structure described in the figure
happens to satisfy the stated information exchange requirements most closely. Since most
references to a type are done through the root level, the specification is relatively
insensitive to any particular form of taxonomy below the root.
31
V3.1.4
OBJECT-TYPE
object-type-category-code
FACILITY-TYPE
PERSON-TYPE
facility-type-category-code
AIRFIELD-TYPE
FEATURE-TYPE
MATERIEL-TYPE
materiel-type-category-code
feature-type-category-code
CONSUMABLE-MATERIEL-TYPE
BRIDGE-TYPE
CONTROL-FEATURE-TYPE
control-feature-type-category-code
HARBOUR-TYPE
ROUTE-TYPE
consumable-materiel-type-category-code
AMMUNITION-TYPE
ORGANISATION-TYPE
organisation-type-category-code
GEOGRAPHIC-FEATURE-TYPE
BIOLOGICAL-MATERIEL-TYPE
CHEMICAL-MATERIEL-TYPE
RADIOACTIVE-MATERIEL-TYPE
CIVILIAN-POST-TYPE
EQUIPMENT-TYPE
equipment-type-category-code
GROUP-ORGANISATION-TYPE
AIRCRAFT-TYPE
PRIVATE-SECTOR-ORGANISATION-TYPE
CBRN-EQUIPMENT-TYPE
GOVERNMENT-ORGANISATION-TYPE
ELECTRONIC-EQUIPMENT-TYPE
government-organisation-type-category-code
ENGINEERING-EQUIPMENT-TYPE
MILITARY-ORGANISATION-TYPE
MARITIME-EQUIPMENT-TYPE
MISCELLANEOUS-EQUIPMENT-TYPE
military-organisation-type-category-code
RAILCAR-TYPE
UNIT-TYPE
WEAPON-TYPE
MILITARY-POST-TYPE
TASK-FORMATION-TYPE
VEHICLE-TYPE
VESSEL-TYPE
vessel-type-category-code
SUBSURFACE-VESSEL-TYPE
EXECUTIVE-MILITARY-ORGANISATION-TYPE
SURFACE-VESSEL-TYPE
Figure 4. Entity-Level View of OBJECT-TYPE Subtype Tree
3.4.2 The specification permits a sixth categorisation of OBJECT-TYPE that is
not visible in the diagram. It has the value "Unknown" in order to correspond to the same
value on the item side. This categorisation is necessary to deal with detection and tracking
problems where the exact classification of the detected object cannot be determined, but
its existence must be recorded and information about it must be collected.
3.4.3 Most of the categories are reasonably self-explanatory with the possible
exception of GROUP-ORGANISATION-TYPE, CIVILIAN-POST-TYPE, and
MILITARY-POST-TYPE. GROUP-ORGANISATION-TYPE was created in response to
32
V3.1.4
CRO requirements to deal with groups that are not truly organisations but have to be
treated as a collective object for data purposes. Consequently, groups of people such as
refugees and prisoners of war are treated as pseudo-organisations. Post type is a type of
position that is filled by a single individual, such as commander of a military unit or chief
of a police department. It enables the set of duties inherent in a position or a billet to be
distinguished from the type of person that may fill the post.
3.4.4 The figure displays two non-identifying relationships (dashed lines) with a
diamond at one end and a dot at the other. A diamond indicates that the relationship is
optional. No data needs to be passed from one entity to the other. A dot has the same
meaning as cited earlier—it is the many end of a one-to-many relationship. The
relationship from EQUIPMENT-TYPE to UNIT-TYPE allows the identification of the
major type of equipment that can be associated with a unit, e.g., Leopard III Main Battle
Tank is the major equipment for a tank battalion. The relationship from UNIT-TYPE to
MILITARY-ORGANISATION-TYPE permits a refinement in specifying headquarters
units. For example, a headquarters company may be designed to serve a division or a
brigade. This relationship enables an explicit association that states that an instance of a
type headquarters company is intended to serve as the headquarters element of a type
division.
3.5
Composition of Types (Establishment)
3.5.1 Concept of Establishment
3.5.1.1 Composition of types of objects needs to be represented in data. For
example, a military organisation may specify that:
a.
A given type of unit is authorised to have quantities of various types of
materiel (e.g., an artillery battery is authorised to have six howitzers).
b.
A given type of formation is to be composed of quantities of types of units
(e.g., a battalion is to include three companies and two supporting platoons).
c.
A given type of unit is to consist of quantities of persons typed according to
specialty and rank (e.g., an infantry squad is to consist of a senior sergeant, 2
corporals, and 12 riflemen having any one of three junior grades).
3.5.1.2 A specification for composition of a unit may include multiple types of
things, such as the following:
A French engineer regiment has a wartime establishment of 500 regular
troops, 150 drivers, 100 vehicles, 20 minelayers, and 20,000 mines.
3.5.1.3 It may be necessary to capture a bill of materials or parts list for types of
equipment in support of logistics. A parts list may catalogue components of a rifle, all
items of equipment expected to be present on a combat-ready main battle tank, or
enumerate all weaponry and equipment that is certified as a package for safe carriage on a
given model of an F-16 fighter.
3.5.1.4 Every type of authorisation or statement of composition cited above can be
represented using the concept of establishment. An establishment is an authorisation or
other form of specification that associates, under specified conditions for a given instance
of a type of object, a number of instances of other object types as its constituent elements.
33
V3.1.4
3.5.2 Specification of Establishment
3.5.2.1 The structure is illustrated in the figure below. An instance of OBJECTTYPE may have one or more establishments assigned to it in OBJECT-TYPEESTABLISHMENT. The actual composition is specified in a child entity OBJECTTYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL that lists the numbers of specific
OBJECT-TYPEs authorised in the establishment. The instances of OBJECT-TYPE that
appear in the detail are identified through the relationship "is-specified-as-part-of."
is-specified-as-part-of /
references
OBJECT-TYPE
is-made-up-through /
specifies-the-composition-of
OBJECT-TYPE-ESTABLISHMENT
is-specified-through /
is-a-component-of
identifies-establishment-for-detail-object-type-in /
references
OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL
Figure 5. Specifying Establishments
3.5.2.2 The second non-identifying (dashed-line) relationship with the diamond at
its head permits unambiguous re-use of data in building establishment hierarchies. For
example, if a given company type has two establishments (say, summer peacekeeping and
winter wartime) and it is being cited as a component of a new task force type, the
relationship enables the selection of one of the two establishments.
3.5.2.3 Not all combinations of types are needed. The allowable combinations are
restricted by means of a business rule, as summarised in the table below.
Table 11. Permissible Combinations of Types for Establishments
Detailed Established FACILITY-
FEATURE
MATERIEL
ORGANISATION
PERSON-
TYPE
-TYPE
-TYPE
-TYPE
TYPE
FACILITY-TYPE
NA
FEATURE-TYPE
NA
NA
NA
NA
NA
MATERIEL-TYPE
NA
NA
NA
ORGANISATION-TYPE
NA
NA
NA
PERSON-TYPE
NA
NA
Legend: = Permissible combination
NA = Not allowed
34
V3.1.4
3.5.3 Assigning Establishments to Items
Instances of establishments are assigned to instances of OBJECT-ITEM by means
of the associative entity OBJECT-ITEM-OBJECT-TYPE-ESTABLISHMENT, as
illustrated in the figure below. Statements of the following kind can be recorded: As of 1
March 1997, the 19th (US) Mechanized Division is assigned a specific Type Mechanised
Division Establishment for war operations in a temperate climate.
OBJECT-TYPE
OBJECT-ITEM
is-assigned-through
is-assigned-establishment-through
OBJECT-ITEM-OBJECT-TYPE-ESTABLISHMENT
Figure 6. Assigning Establishment to OBJECT-ITEM
3.6
OBJECT-ITEM Hierarchy
3.6.1 Full OBJECT-ITEM subtype hierarchy is illustrated in the figure below.
The reader should note that the structure below the first subtype level is not parallel to the
type side. The design is deliberate in response to requirements. Subtypes are created only
when there are information elements that belong to a single object category. For example,
there is no subtype under OBJECT-TYPE that is equivalent to METEOROLOGICFEATURE; yet this entity has seven subtypes of its own.
3.6.2 There is a sixth categorisation of OBJECT-ITEM with the value
"Unknown" that is not visible in the diagram as mentioned in the discussion of types.
35
V3.1.4
OBJECT-ITEM
FEATURE
FACILITY
MATERIEL
ORGANISATION
UNIT
AIRFIELD
ANCHORAGE
PERSON
CONVOY
BASIN
INSTRUMENT-LANDING-SYSTEM
APRON
PERSON-LANGUAGE-SKILL
BRIDGE
BERTH
PERSON-IDENTIFICATION-DOCUMENT
QUAY
GEOGRAPHIC-FEATURE
DRY-DOCK
JETTY
CONTROL-FEATURE
HARBOUR
RAILWAY
AIRSPACE-CONTROL-MEANS
ROAD
RUNWAY
ROUTE-SEGMENT
ROUTE
SLIPWAY
NETWORK
APPROACH-DIRECTION
AIR-ROUTE-SEGMENT
NETWORK-CAPACITY
MILITARY-OBSTACLE
METEOROLOGIC-FEATURE
NETWORK-SERVICE
MINEFIELD
NETWORK-FREQUENCY
ATMOSPHERE
ICING
CLOUD-COVER
LIGHT
MINEFIELD-LAND
PRECIPITATION
MINEFIELD-MARITIME
VISIBILITY
MINEFIELD-MARITIME-CASUALTY-ESTIMATE
WIND
MINEFIELD-MARITIME-SUSTAINED-THREAT-MEASURE-OF-EFFECTIVENESS
Figure 7. Entity-Level View of OBJECT-ITEM Subtype Tree
3.6.3 Some characteristics of OBJECT-ITEM or one of its subtypes may require
that multiple values be maintained in a database at the same time. The technique for
handling such cases is to create child entities. A child entity depends on its single parent in
a one-to-many relationship. The subtype hierarchy has several child entities as defined
below with examples that illustrate reasons for multiple values:
a.
NETWORK-CAPACITY—An identification of the specific capacities of a
NETWORK. A network may use multiple bandwidths with different
protocols on each.
36
V3.1.4
b.
NETWORK-FREQUENCY—The specification of a discrete frequency that
is used on a specific NETWORK. A network uses multiple frequencies. It
may be as simple as lower and upper bounds for a band or a set of
frequencies for frequency hopping radios.
c.
NETWORK-SERVICE—An identification of the specific type of
communications service provided by a specific NETWORK. A network may
simultaneously provide several services, the Internet being a good example.
d.
PERSON-IDENTIFICATION-DOCUMENT—A document used to identify
a specific PERSON. Almost every person carries multiple identification
documents, such as driver licences, military identification cards, and
passports.
e.
PERSON-LANGUAGE-SKILL—A proficiency or ability of a specific
PERSON with regard to a specific language. A person may have skills in
several languages or differing reading, writing and speaking skills in the
same language.
f.
MINEFIELD-MARITIME-CASUALTY-ESTIMATE—An estimate of the
average number of casualties for a given number of vessel transits through a
specific MINEFIELD-MARITIME. This entity along with the entity in
Bullet (h) enable the presentation of tabular data of specialised effectiveness
for maritime minefields.
g.
MINEFIELD-MARITIME-SUSTAINED-THREAT-MEASURE-OFEFFECTIVENESS—A measure of effectiveness for a specific MINEFIELDMARITIME in terms of probability of mine function against a transit vessel
over a given period of time.
3.6.4 OBJECT-ITEM has child entities that are not part of the taxonomy.
OBJECT-ITEM-ALIAS permits alternative identification of an item. OBJECT-ITEMCOMMENT enables two types of comments to be appended to an item: a short one for use
with symbology and a longer one for general use.
3.6.5 Three other child entities of OBJECT-ITEM that are not part of the subtype
hierarchy are described in subsequent sections.
3.7
Specifying Status of OBJECT-ITEMs
3.7.1 There is a general requirement of specifying the status of items at a given
time (past, present, or predicted). The main topics include (a) classifying the hostility state
of an OBJECT-ITEM and (b) assigning categories to OBJECT-ITEMs to capture
administrative, medical, physical, and procedural states or conditions.
3.7.2 Most objects of the battlefield can be characterised as friend or enemy. This
information is not inherent to the specific object. The hostility status of an object is a
classification that a specific organisation gives to this object. It means that a specific
object may have different hostility status given by different organisations, and that the
hostility status may vary with time. The known or perceived friendly or aggressive
intentions of an object are recorded in the entity OBJECT-ITEM-HOSTILITY-STATUS
whose structure of is illustrated in the figure below.
37
V3.1.4
OBJECT-ITEM
has /
is-ascribed-to
OBJECT-ITEM-HOSTILITY-STATUS
provides-applicable-information-for /
is-referenced-to
REPORTING-DATA
Figure 8. Specifying Hostility Status
3.7.3 The planning process and situational awareness require knowledge of the
status of various objects. One aspect is operational status. For example, the operational
status of a tank could describe the degree of damage it has suffered, its current mobility, or
its capacity to fire its gun. The entity-level structure for capturing status is illustrated in the
figure below.
has /
is-ascribed-to
OBJECT-ITEM
OBJECT-ITEM-STATUS
object-item-status-category-code
CONTROL-FEATURE-STATUS
FACILITY-STATUS
facility-status-category-code
AIRFIELD-STATUS
MEDICAL-FACILITY-STATUS
MINEFIELD-MARITIME-STATUS
GEOGRAPHIC-FEATURE-STATUS
geographic-feature-status-category-code
LIQUID-BODY-STATUS
LIQUID-SURFACE-STATUS
SOLID-SURFACE-STATUS
MATERIEL-STATUS
materiel-status-category-code
MINE-STATUS
UXO-STATUS
ORGANISATION-STATUS
PERSON-STATUS
Figure 9. Specifying Status of OBJECT-ITEMs
38
V3.1.4
3.7.4 Subtypes of OBJECT-ITEM-STATUS hold the attributes that are tailored
to describing the status of subtypes of OBJECT-ITEM. For example, the status of an
enemy military ORGANISATION (a unit) could range from fully operational to
destroyed; and the status of a soldier could be ready, incapacitated, wounded, absent,
missing, arrested, captured, or killed. A control feature could be activated or deactivated.
3.7.5 Additional structure for MEDICAL-FACILITY-STATUS (not shown in
the figure above) provides a number of details in terms of patient types, patient arrivals,
medical condition types, surgical triage, surgical backlog, and disposition of patients.
3.7.6 Data structure permits multiple records to be kept about the status of an
instance of OBJECT-ITEM to reflect changes that occur over time or differing status
assessments that may be provided about a single OBJECT-ITEM by several units or
organisations, particularly when the assessment is about an element of the opposing force.
3.8
Specifying Access to OBJECT-ITEMs
3.8.1 There can be multiple ways to contact facilities, organisations, and persons,
including anything from a postal address to a telephone number to a World Wide Web
address. It also encompasses the use of call signs on radio nets since a call sign is a way of
reaching a specified organisation or person and represents an address as much as an e-mail
address.
3.8.2 Access to an item may be specified through physical and electronic
addressing. The physical address is a straightforward listing of the elements of an address
in text form. Electronic address is defined in relation to a specified network and a
specified service on the network.
3.8.3 An instance of OBJECT-ITEM, such as a military unit, may be a subscriber
to multiple services on a single network. It may also participate as a subscriber on several
different networks. The conditions of subscription may also be dictated by operational
considerations permitting active or restricting to passive participation.
3.8.4 The structure is illustrated in the figure below. The ADDRESS structure
provides a means for specifying an access address for an object. ADDRESS is an
independent entity because a given address need not be owned by a specific object. This is
most obvious in case of an office or house address where the occupancy can change but
the address remains the same. A similar situation can occur in the electronic world where a
telephone number may be re-assigned or an e-mail address shared by a number of
individuals or offices.
39
V3.1.4
OBJECT-ITEM
has-for-address /
is-t he-address-for
OBJECT-ITEM-ADDRESS
is-reference-for
object-item-category-code
FACILITY
ADDRESS
facility-category-code
NETWORK
address-category-code
provides /
is-provided-by
PHYSICAL-ADDRESS
NETWORK-SERVICE
can-be-access ed-via /
provides-access-to
uses /
is-specified-for
ELECTRONIC-ADDRESS
NETWORK-FREQUENCY
is-assigned-through
Figure 10. Providing Access to an OBJECT-ITEM through ADDRESS
3.9
Associations between OBJECT-ITEMs
3.9.1 Specification of Associations
3.9.1.1 Every instance of OBJECT-ITEM may have some type of relationship to
another instance of OBJECT-ITEM in the sense of belonging, using, controlling, being
constrained by, occupying and so on. For example, a division has full command of three
brigades, or full command of two and operational control of the third if the third belongs
to another nation. A specific main battle tank (MBT) is issued to a certain armoured
infantry company. The model uses a simple structure to capture such information, as
illustrated in the figure below.
3.9.1.2 The entity OBJECT-ITEM participates in an association twice: once as a
subject and once as an object. The category codes that are at the heart of the specification
are aligned to read from subject to object. The status entity that is attached to each
association records whether the effective datetime provided through REPORTING-DATA
is a start or end of an association. An association can be made and broken multiple times.
40
V3.1.4
is-the-subject-of
is-the-object-of
OBJECT-ITEM
OBJECT-ITEM-ASSOCIATION
has /
is-ascribed-to
ORGANISATION
P
OBJECT-ITEM-ASSOCIATION-STATUS
is-referenced-to
is-the-reporting-agent-for /
is-reported-by
REPORTING-DATA
Figure 11. Associations among OBJECT-ITEMs
3.9.1.3 Associations that are necessary for C2 are shown in the table below. The
meaning of associations for eleven OBJECT-ITEM relationships are specified by a
category code and in some cases an additional subcategory code. The allowable values for
each association are listed as a business rule. Some examples of potential associations are
illustrated in Table 13.
Table 12. Valid OBJECT-ITEM Associations
Subject OBJECT-ITEM
CONTROLFEATURE
FACILITY
FEATURE
GEOGRAPHICFEATURE
MATERIEL
ORGANISATION
PERSON
Not known
Object OBJECT-ITEM
CONTROL-FEATURE
Yes
Yes
—
Yes
Yes
—
—
—
FACILITY
—
Yes
Yes
—
Yes
—
—
Yes
FEATURE
—
Yes
—
—
—
—
—
—
GEOGRAPHIC-FEATURE
—
Yes
—
—
—
—
—
—
Yes
—
Yes
—
Yes
Yes
MATERIEL
—
Yes
ORGANISATION
Yes
Yes
—
Yes
Yes
Yes
Yes
Yes
PERSON
—
Yes
Yes
—
Yes
—
Yes
Yes
Not known
Yes
Yes
—
Yes
—
—
—
—
41
V3.1.4
Table 13. Examples of Associations
(a) Category Value: Supplementary
Subcategory Value: Plays the role of
Plays the role of ORGANISATION
ORGANISATION
Org1 serves as an enemy unit (Faker, in an exercise)
(b) Category Value: Has its role physically embodied by
Has its role physically embodied by MATERIEL
A light ship serves as an air control
point
CONTROL-FEATURE
(c) Category Value: Is physically represented in its entirety by part of
Is physically represented in its
entirety by part of GEOGRAPHIC-FEATURE
A boundary is represented by a river
CONTROL-FEATURE
(d) Category Value: Serves as
Serves as MATERIEL
MATERIEL
A truck serves
as a bus
CONTROL-FEATURE
FACILITY
A truck serves as an
obstacle
A cave serves as a
hospital (or a wine cellar!)
GEOGRAPHICFEATURE
A windmill serves as A school serves as an
a contact point, land hospital
FACILITY
(e) Category Value Is situated in
CONTROL-FEATURE
GEOGRAPHICFEATURE
ORGANISATION
Org1 is situated in
Area of Operations 1
Org1 is situated in
Natural Cave1
Org1 is situated in Wine
cellar1!!!
MATERIEL
Aircraft1 is situated in
Air Corridor1
Guns1 is situated in
Natural Cave1
Truck1 is situated in
Hangar1
CONTROLFEATURE
Area of operation1 is
situated in Area of
Operations 2
GEOGRAPHICFEATURE
River1 is situated in
Area of Operations 1
Lake1 is situated in
Natural Cave1
Field Hospital1 is
situated in Area of
Operations 1
Field Hospital1 is
situated in Natural
Cave1
Is situated in
FACILITY
FACILITY
MeetingPoint1 is situated
in School1
Field Hospital is situated
in School1
3.9.2 Organisational Structure
3.9.2.1 It is difficult to infer organisational hierarchies purely from instances stored
as relationship records. This section describes data specifications to enable appropriate
relationships to be collected explicitly as part of a recognised group, such as an order-ofbattle (ORBAT) or a unit task organisation (UTO).
3.9.2.2 The structure is illustrated in the figure below. A structure may be assigned
to any organisation. A given structure, such as UTO, may be associated with a plan or an
operations order.
42
V3.1.4
OBJECT-ITEM
ACTION
is-the-subject-of
is-the-object-of
action-category-code
ORGANISATION
is-configured-as-specified-in /
specifies-the-configuration-of
is-referenced-in /
refers-to
references /
is-relevant-for
ORGANISATION-STRUCTURE
includes /
is-an-element-of
ORGANISATION-STRUCTURE-DETAIL
is-specified-for /
requires-the-use-of
ACTION-TASK
Figure 12. Specifying Organisational Structure
3.10
Capabilities of Items and Types
3.10.1 Specifying and monitoring the capability of objects can be an important
factor within the military planning process. Knowledge about capability may help in
analysis of feasible actions that are open to friendly forces or in assessing the likelihood of
actions that may be open to enemy forces. Capability statements can also be subject to
various kinds of conditions. For example, the speed with which a vehicle can manoeuvre
over land may depend on the type of terrain, and the range of a weapon may depend on the
type of ammunition that is used. Capability structure is designed to embody two concepts:
the need to characterise capability itself and to link it to other parts of the model that use
specifications of capability. The structure is illustrated in the figure below.
43
V3.1.4
CAPABILITY
requires-as-a-minimum /
is-minimum-required-for
is-quantified-in /
quantifies
ACTION-REQUIRED-CAPABILITY
is-quantified-in /
quantifies
ACTION
OBJECT-ITEM
is-specified-with /
is-specified-for
OBJECT-ITEM-CAPABILITY
is-quantified-in /
quantifies
OBJECT-TYPE
is-specified-as-having /
is-normal-quantity-stated-for
OBJECT-TYPE-CAPABILITY-NORM
capability-category-code
is-the-load-in /
specifies-the-stored-amount-of
STORAGE-CAPABILITY
ENGINEERING-CAPABILITY
is-used-in-the-definition-of /
is-defined-with
HANDLING-CAPABILITY
FACILITY-TYPE
MAINTENANCE-CAPABILITY
MOBILITY-CAPABILITY
OPERATIONAL-CAPABILITY
SUPPORT-CAPABILITY
EQUIPMENT-TYPE
SURVEILLANCE-CAPABILITY
FIRE-CAPABILITY
Z
TRANSMISSION-CAPABILITY
MATERIEL-TYPE
AMMUNITION-TYPE
is-defined-with
is-defined-with
Figure 13. Specifying Capabilities of Objects
3.10.2 The CAPABILITY structure represents a list of generic capabilities that
can be attribute to objects and their types. Subtypes of CAPABILITY add amplifying
information for certain classes of capability. Some are linked to subtypes of OBJECTTYPE in order to permit more precise specification. For example, FIRE-CAPABILITY is
linked to AMMUNITION-TYPE, TRANSMISSION-CAPABILITY is linked to
ELECTRONIC-EQUIPMENT-TYPE, ENGINEERING-CAPABILITY is linked to
FACILITY-TYPE and STORAGE-CAPABILITY is linked to OBJECT-TYPE.
3.10.3 CAPABILITY is linked to three independent entities in order to provide the
following functions:
a.
Specify the expected or normal capability for OBJECT-TYPEs.
44
V3.1.4
b.
Estimate or record the actual capability of OBJECT-ITEMs.
c.
State (through ACTION-REQUIRED-CAPABILITY) the required
capability of OBJECT-ITEMs or OBJECT-TYPEs when they are needed as
resources for carrying out ACTIONs.
3.10.4 Expected / Normal Capability. The entity OBJECT-TYPE-CAPABILITYNORM represents staff planning data concerning the capabilities of different OBJECTTYPEs. The data can be used to:
a.
Provide a broad threat analysis in terms of enemy or potentially hostile
OBJECT-TYPEs.
b.
Assist in the selection of friendly OBJECT-TYPEs for the tasks to be done.
c.
Aid an application program in classifying OBJECT-TYPEs in accordance
with operational user’s preferences.
3.10.5 Actual Capability. The capabilities of individual items may differ from the
norm due to attrition or other factors. The entity OBJECT-ITEM-CAPABILITY holds the
perceived value of a specific CAPABILITY of an OBJECT-ITEM where it differs from
the norm or where there is no norm. This part of the specification could hold a threat
analysis for individual enemy elements, e.g., an enemy tank regiment may have
demonstrated a capability to move at a faster rate than its expected norm.
3.10.6 Required Capability. It may be necessary to specify a required capability in
conjunction with some activity. This enables optimal resource usage for planning as well
as for managing resources during the life of an activity.
3.11
Positioning and Geometry for OBJECT-ITEMs
3.11.1 Concept for Representing Location and Geometry
3.11.1.1 The data structure under the independent entity LOCATION captures
two distinct but related concepts of interest to planners and operators:
a.
Specification of geometry that is required to describe objects;
b.
Placement of objects or their geometry with respect to the Earth's surface or
with respect to each other.
3.11.1.2 The ability to specify geometry permits the description of various open
or closed boundaries, such as areas of responsibility, orbits, phase lines, and objectives, as
well as the shape of airfields, runways, ammunition dumps, and a security fence
surrounding an ammunition dump. The positioning of objects with respect to the Earth's
surface is achieved by linking the entity OBJECT-ITEM to the LOCATION entity.
3.11.2 Overview of Location Structure
3.11.2.1 Overall structure for specifying location and geometry is illustrated in
the figure below at the entity level. The LOCATION structure is self-contained and
largely independent of other parts of the model. One exception occurs when a coordinate
system is set up relative to some battlefield object. This is shown by the relationship
between OBJECT-ITEM-LOCATION and OBJECT-REFERENCE.
45
V3.1.4
LOCATION
VERTICAL-DISTANCE
location-category-code
GEOMETRIC-VOLUME
POINT
P
LINE
SURFACE
geometric-volume-category-code
surface-category-code
LINE-POINT
CONE-VOLUME
SPHERE-VOLUME
CORRIDOR-AREA
point-category-code
POLYGON-AREA
ABSOLUTE-POINT
absolute-point-category-code
POLYARC-AREA
CARTESIAN-POINT
FAN-AREA
GEOGRAPHIC-POINT
TRACK-AREA
RELATIVE-POINT
ORBIT-AREA
relative-coordinate-system-reference-category-code
ELLIPSE
POINT-REFERENCE
OBJECT-REFERENCE
SURFACE-VOLUME
OBJECT-ITEM
OBJECT-ITEM-LOCATION
Figure 14. Entity-Level View of the LOCATION Structure
3.11.2.2 The basic element is a point; it plays a role in generating every other
geometric construct in the specification. The location of the point can be expressed in
absolute terms geographically with respect to Earth’s surface or in an Earth-centred
coordinate frame. It may also be located in relative terms with respect to another point that
may be absolute or relative itself. The vertical distance for a point may be specified in
several ways: as a measured altitude with respect to mean sea level, a measured height
with respect to ground or water level, a pressure altitude or pressure height, or simply
stated to be the local surface, as would be the case for an armoured vehicle moving
through the countryside.
3.11.2.3 Lines are generated from a series of points that are connected in a
specified order. The part of a line between two successive points is a line segment; a
46
V3.1.4
sequence of connected line segments defines the line, or more properly a polygonal path.
A line may close on itself if the first and last points that define the line are the same; in
this case a line may serve as a boundary for a surface. If the first and last points are not the
same, then the line is an open line, such as a phase line or a one-way route.
3.11.2.4 Surfaces are built either directly from lines or the points provide part of
the specification. For example, a polygon area is defined by a closed boundary line. An
ellipse is completely defined by three points.
3.11.2.5 Most volumes are built by using the horizontal projection of a surface
onto the Earth’s surface to define the outer boundaries of a general cylinder and to specify
the top and bottom vertical distances to close off the volume. Thus, any of the geometric
figures that are constructed as surfaces can be the basis for a volume. Two additional
volume geometries—cones and spheres—require individual specifications.
3.11.3 Supporting Structures in LOCATION
LOCATION structure is supported by additional specifications for vertical distance
and a coordinate system to enable relative geometry. The independent entity VERTICALDISTANCE is a specification of the altitude or height of a point or a level as measured
with respect to a specified reference datum in the direction normal to the plane that is
tangent to the WGS84 ellipsoid of revolution. Specification of RELATIVECOORDINATE-SYSTEM enhances functionality of LOCATION by establishing a local
reference frame. RELATIVE-COORDINATE-SYSTEM has two subtypes: one defines a
coordinate system with respect to an arbitrary point and the second with respect to location
of an object. If the object is moving or changing its orientation, then the coordinate system
is also changing. Any geometry that is specified relative to this coordinate system will also
move with it.
3.11.4 Linking LOCATIONs and OBJECT-ITEMs
Model construct relates OBJECT-ITEM to LOCATION through the associative
entity OBJECT-ITEM-LOCATION. The overall view for associating objects with
LOCATION is illustrated in the figure below.
LOCATION
OBJECT-ITEM
is-geometrically-defined-through
provides-geometric-definition-for
Figure 15. Assigning Position and Geometry to OBJECT-ITEMs
47
V3.1.4
3.12
Relationships between Items and Types
This section deals with three sets of direct relationships between items and types:
classification of items according to type, possession of types by items, and the assignment
of identifying codes to types of materiel for reporting purposes.
3.12.1 Classification of OBJECT-ITEMs by Type
3.12.1.1 A specific OBJECT-ITEM must be associated with at least one instance
of OBJECT-TYPE. This is a fundamental structural feature of the model. Data elements
are defined on the type or item side as is most appropriate and the information needs to be
shared between the two sides. The ability to classify OBJECT-ITEMs as OBJECT-TYPE
makes any information that is stored as type data applicable to the item. Thus, any
characteristic of an item that can be described as a type property does not need to be
carried as a property on the item side.
3.12.1.2 The linkage between item and type permits the recording of differing
interpretations of what the type of an item may be, especially in regard to opposing forces
or any other assessment that is based on uncertain or incomplete information. For
example, Unit A may classify an unknown object first as a vehicle, then successively (as
better information becomes available) an armoured vehicle, a tank, a main battle tank, and
a T72. It also permits the recording of differing interpretations of the same object by
different organisations. Unit B may be looking at the same object as Unit A but classify it
successively as a vehicle and an APC. The structure also enables a history of
classifications to be kept as a means for understanding the decisions that were made at the
time a classification was considered valid.
3.12.1.3 The OBJECT-ITEM-TYPE structure is illustrated in the figure below.
The relationship is read as follows: an OBJECT-ITEM is classified as one or more
OBJECT-ITEM-TYPEs. The letter P at the "many" end stands for "positive" P making the
classification of an item mandatory.
OBJECT-TYPE
OBJECT-ITEM
is-classified-as
is-used-as-a-classification-for
P
OBJECT-ITEM-TYPE
Figure 16. Assigning Type Classification to an OBJECT-ITEM
3.12.2 Holdings and Transfers by Items
3.12.2.1 The purpose of HOLDING and HOLDING-TRANSFER specifications
is to provide commanders with a dynamic update of changes to information on stockpiles
48
V3.1.4
of specific equipment and consumable materiel held by national or multinational forces
declared to an operation, as well as specified equipment and materiel held by various
formations in support of such forces.
3.12.2.2 The staff officer may wish to know how many tanks of a given type a
certain unit possesses and how many of them are operational, or how many enemy
companies there are within a given area (an instance of CONTROL-FEATURE), or how
many rounds of an ammunition type are stored in a particular arsenal, or how many cargo
pallets are contained on a particular airlift aircraft, or how many mechanics does a given
maintenance company have, or which types of weapons and sensors are held by a specific
weapons platform (e.g., instance of an aircraft or tank)18.
3.12.2.3
The structure is illustrated in the figure below.
3.12.2.4 The entity HOLDING addresses the association of a specific object
(OBJECT-ITEM) with a class of objects (OBJECT-TYPEs) where the relationship is
defined by the general notion of inclusion in the sense of ownership, possession,
assignment, or control. Each count of the number of a class in a HOLDING is subject to a
qualifying condition.
3.12.2.5 Holding specifies what an OBJECT-ITEM actually has or is estimated
to have at a particular time. The holding may be an estimate for a future date, such as the
expected count of a given type of equipment a week from now. In this way, expected
replenishment or repair of materiel can be reflected in the holdings that serve as one of the
sources of information for combat operations planning.
OBJECT-ITEM
has /
belongs-to
HOLDING
is-subject-of /
is-constrained-to
OBJECT-TYPE
is-correspondent-in /
is-transaction-for
is-changed-by /
changes
HOLDING-TRANSFER
is-referenced-to
is-referenced-to
REPORTING-DATA
Figure 17. Accounting for Holdings by an OBJECT-ITEM
18
The load of weapons carried by a specific close air support aircraft is a case in point.
49
V3.1.4
3.12.2.6 The entity HOLDING-TRANSFER supports the recording of logistic
transactions, such as losses or gains. Its specifications enable it to indicate the reason for a
transfer, the quantity of a transfer, and the corresponding instance of OBJECT-ITEM that
is the providing or receiving agent in a transaction.
3.12.2.7 Previously discussed establishment indicates what an organisation or
materiel is supposed to be composed of or is authorised to have; HOLDING captures what
the organisation has or materiel actually contains (or is thought to have) at a particular
time. The comparison of the two sets of numbers enables a number of staff evaluations,
such as the setting of logistic/personnel replenishment requirements, an assessment of
organisational capability, or need for requisition.
3.12.3 Identifying Reportable Items
3.12.3.1 An organisation, such as NATO HQ or a regional headquarters, may
create lists of materiel types using a standard coding scheme for reporting purposes, such
as Land Forces Reportable Item List (LFRIL) or Reportable Item Code (RIC). An
organisation may choose to create these types of codes in order to enforce standard
reporting about equipment (type of materiel) that its subordinate organisations hold.
3.12.3.2 The model includes an entity ORGANISATION-MATERIEL-TYPEASSOCIATION in order to enable the designation a reporting code for instances of
MATERIEL-TYPE. The linkage to organisation is necessary since the codes depend on
the establishing organisation. The structure is illustrated in the figure below.
ORGANISATION
assigns-reporting-code-in
MATERIEL-TYPE
is-assigned-reporting-code-in
ORGANISATION-MATERIEL-TYPE-ASSOCIATION
Figure 18. Assigning Reporting Codes to MATERIEL-TYPE
3.13
ACTION: Structured Specification of Activity
3.13.1 Introduction
3.13.1.1 This chapter describes the basic concepts for representing activity in the
model. The independent entity ACTION is the root for this representation. The related
structure includes mechanisms for specifying items or types as resources and objectives
for activity, recording effects of activity, classifying activities as planned tasks or
unplanned events, keeping status of activities, and relating activities to each other
functionally and temporally.
3.13.1.2 ACTION together with its substructures specifies and describes
operations planned for, or carried out, in the sphere of operations. It is also used to
describe unplanned happenings that are of military interest. The underlying concept for
50
V3.1.4
modelling ACTIONs is based on a statement in which something carries out an activity to
affect something at some time. Within the model, the "something" within the basic action
statement is described by an OBJECT-TYPE or an OBJECT-ITEM. Thus, OBJECTTYPEs and OBJECT-ITEMs are related to ACTION in three distinct ways: as resources
objectives, and subjects of effects, as illustrated in the figure below. The figure also shows
two associations that link sets of ACTIONs functionally and temporally. Functional
associations enable the building of complex statements, such as operations orders, from
simple statements in cascading hierarchies. Temporal associations provide for timing of
ACTIONs in relation to one another in specific or general terms.
3.13.1.3 ACTION-RESOURCE is defined as "An OBJECT-ITEM or an
OBJECT-TYPE that is required, requested, allocated or otherwise used or planned to be
used in conducting a specific ACTION." ACTION-RESOURCEs are those OBJECTITEMs and OBJECT-TYPEs that have been specified as the things performing, things
being used in or allocated to, or things whose use is qualified in some way, in carrying out
a specific ACTION.
3.13.1.4 ACTION-OBJECTIVE is defined as "The focus, in terms of an
OBJECT-ITEM, OBJECT-TYPE, or ACTION-TASK, in conducting a specific
ACTION." ACTION-OBJECTIVEs are those OBJECT-TYPEs or OBJECT-ITEMs that
are specified to be (or excluded from) the focus of an ACTION.
ACTION
ACTION-FUNCTIONAL-ASSOCIATION
ACTION-TEMPORAL-ASSOCIATION
ACTION-RESOURCE
ACTION-OBJECTIVE
ACTION-EFFECT
OBJECT-TYPE
OBJECT-ITEM
Figure 19. Basic ACTION Structure
3.13.2 Role of Objects as Resources, Objectives, and Subjects of Effects
3.13.2.1 As an example of resources and objectives, the 11th (NL) Air Mobile
Brigade may use 4 Chinook helicopters (an ACTION-RESOURCE) to transport 100
troops to a landing zone (ACTION-OBJECTIVE).
3.13.2.2 Effectiveness of operations needs to be monitored and the potential
effects of planned or pending activity need to be estimated. To this end, ACTIONEFFECT is defined as "A perceived effectiveness of a specific ACTION against a specific
51
V3.1.4
item or its type." For example, the reported result may be that the enemy force has been
diminished by at least 50 percent and the enemy position was captured.
3.13.2.3 The ACTION-EFFECT estimate specifies a quantity if the objective is
an OBJECT-TYPE, or a fraction if the objective is an OBJECT-ITEM. Operations
performance could be evaluated by comparing ACTION-EFFECTs to stated ACTIONOBJECTIVEs. ACTION-EFFECT permits the capture of information about effects of
ACTIONs whether intended or not. This may be collateral damage, for example, where
the intended target was an ammunition plant but the nearby infrastructure was hit.
3.13.3 Relating ACTIONs
3.13.3.1 General. The promulgation and understanding of an operations order is
dependent upon the complex linkage of a series of assigned actions (tasks). These tasks are
linked functionally (e.g. The Corps Barrier Zone Completion is decomposed into several
Divisional Barrier Zone tasks which is then further decomposed into Brigade Barrier Zone
tasks and so on). There is also a temporal dimension that indicates that Action A cannot
start before Action B is completed (e.g., A unit cannot achieve Phase Line 2 until it has
achieved Phase Line 1. The model provides two associative entities that specify the
dependencies between ACTIONs and allow for the creation of hierarchies:
a.
ACTION-FUNCTIONAL-ASSOCIATION
relationships; and
b.
ACTION-TEMPORAL-ASSOCIATION
dependencies between ACTIONs.
caters
caters
to
to
functional
time-specific
3.13.3.2 ACTION-FUNCTIONAL-ASSOCIATION. The entity ACTIONFUNCTIONAL-ASSOCIATION records the relationship of a specific ACTION as being
dependent on, supporting, or derived from another specific ACTION. The categories of
association include the following phrases:
Has as a provisional sub-ACTION, Has as a sub-ACTION, In order that, In
response to, Is a modification of, Is a prerequisite for, Is a template for, Is an
alternative to, Uses as a reference.
The simplest relationship is where an ACTION includes a number of other subordinate
ACTIONs. This is illustrated in the figure below, where Action 2 is the major action that
is supported by Action 1. Action 1 consists of four ACTIONs (Action 3 to Action 6); three
of the actions are subordinated to Action 1 directly (Action 3 to Action 5), while the fourth
action (Action 6) is subordinated to Action 5. In this example, the relationship hierarchy
can be represented by the phrases as "Is a sub-Action of" in case of connecting lines and
"In order that" for the support.
52
V3.1.4
Figure 20. An Example of ACTION Hierarchy
3.13.3.3 ACTION-TEMPORAL-ASSOCIATION. The timings of sub-actions
that are part of a complex action will frequently be interdependent. The entity ACTIONTEMPORAL-ASSOCIATION is designed to handle the data requirements associated with
temporal dependencies between ACTIONs. ACTION-TEMPORAL-ASSOCIATION is
the assignment of an ACTION (i.e., ACTION-TASK) to be time-dependent for its
execution on another ACTION (e.g., ACTION-EVENT or ACTION-TASK).
3.13.3.4 Absolute Temporal Dependence. There are several ways to establish
temporal dependence. The simplest method and one that does not require the entity
ACTION-TEMPORAL-ASSOCIATION is through the use of absolute time when such
specification is appropriate. In this method, the absolute start and end times are specified
using the attributes in ACTION-TASK (to be described) so that the sub-tasks are carried
out in the correct sequence.
3.13.3.5 Relative Temporal Dependence. The required start time of the overall
action may not be known, or perhaps the unit tasking the ACTION is flexible with regard
to the exact time the sub-actions are to start or end provided they start or end at some time
relative to another action. In order to specify temporal dependence the concept of temporal
relationships has been employed. These are characterised by phrases such as "Starts at the
end of," "Starts during and ends after," and "Starts at the same time and ends after." These
temporal relationships permit specification of the relative order in which ACTIONs are to
occur without stating any actual times.
3.13.3.6 Offset Temporal Dependence. The temporal association also provides
the flexibility of specifying fixed offset intervals, wherein a subject ACTION is to start at
some specified time interval before or after a particular reference point in the object task.
For example, the transportation of troops may be part of a larger mission to attack a
position held by the enemy, requiring that the movement to the landing zone be executed
30 minutes before the attack starts.
3.13.3.7 General Functionality. ACTIONs can be related together in very
complex ways using the concepts of absolute time, temporal relationships, and temporal
relationships with offset intervals. It is possible to formulate plans without specifying a
particular start time (or H-hour) while still being able to specify the interrelated time
dependencies between its constituent sub-actions. In order to fix a start time for such a
plan, it is merely necessary to introduce a new ACTION, with a specified planned start
time, and relate it to the ACTIONs to be initiated, e.g., H-hour will be 0900, 15 August
2006.
53
V3.1.4
3.13.4 Subtypes of ACTION
3.13.4.1 ACTION structure is illustrated in the figure below. It has two
subtypes—ACTION-EVENT and ACTION-TASK—in order to describe two kinds of
activities that entail different data requirements. The entity ACTION-EVENT-DETAIL
and its subtype IED-TACTICAL-CHARACTERIZATION capture addition information
about events. Six entities—CBRN-EVENT, CHEMICAL-BIOLOGICAL-EVENT,
RADIOACTIVE-EVENT, NUCLEAR-EVENT, RADIOLOGICAL-EVENT, and
NUCLEAR-WEAPON-EVENT—are subtypes under ACTION-EVENT to handle
specialised chemical-biological-radiological-nuclear data requirements. The two status
entities allow progress of activities to be recorded.
ACTION
ACTION-EVENT
ACTION-TASK
ACTION-EVENT-STATUS
ACTION-TASK-STATUS
ACTION-EVENT-DETAIL
action-event-category-code
action-event-detail-category-code
CBRN-EVENT
cbrn-event-category-code
IED-TACTICAL-CHARACTERIZATION
CHEMICAL-BIOLOGICAL-EVENT
RADIOACTIVE-EVENT
radioactive-event-category-code
NUCLEAR-EVENT
RADIOLOGICAL-EVENT
nuclear-event-category-code
NUCLEAR-WEAPON-EVENT
Figure 21. ACTION Subtype Structure
3.13.4.2 ACTION-TASK is defined as "An ACTION that is being or has been
planned and for which the planning details are known." It concerns those ACTIONs over
which control can be exercised or which are predicted (such as friendly operations, and
those enemy activities that are being anticipated as a result of intelligence assessment). It
can represent actions that are typically found in plans, orders, and requests.
54
V3.1.4
3.13.4.3 ACTION-EVENT is defined as "An ACTION that is an incident,
phenomenon, or occasion of military significance which has occurred or is occurring but
for which planning is not known." This entity is intended to capture ACTIONs that simply
occur and need to be noted. An ACTION-EVENT may trigger an ACTION-TASK. For
example, the encounter of a scattered minefield near the landing zone will result in an
evasive manoeuvre. An observer in the field may also use ACTION-EVENT to report his
sightings that result from a recorded ACTION-TASK of which he has no knowledge.
3.13.4.4 Status entities permit the monitoring of the effectiveness and progress
of both tasks and events as follows:
a.
ACTION-TASK-STATUS captures the perceived appraisal of the planning
and execution progress of a particular ACTION-TASK in fractional terms or
through the reporting of actual starting and ending times.
b.
ACTION-EVENT-STATUS reports the perceived appraisal of the actual
progress of an ACTION-EVENT as determined by the reporting
organisation. The progress is estimated fractionally at a given time. Fractions
are expressed as ratios in the specification; therefore, ration value of 0 would
coincide with a starting datetime and ration value of 1 with the end.
3.13.5 Adding Comment to ACTION
The entity ACTION-COMMENT and ACTION-COMMENT-CONTENT enables two
types of comments to be appended to an instance of ACTION: an annotation for use with
symbology in ACTION-COMMENT and a representation of long texts attached to ACTIONs in
the ACTION-COMMENT-CONTENT entity for general use.
3.14
Broadening Functionality of ACTION
3.14.1 Introduction
A number of model constructs add to the scope of data that can be captured to
enrich a specification of ACTION:
a.
Marking objectives
b.
Extending specification of ACTION-OBJECTIVE to TARGET
c.
Extending specification of ACTION-TASK to REQUEST
d.
Specifying required capabilities
e.
Designating roles of an organisation with respect to ACTION
f.
Specifying constraints or guidance on the use of ACTION-RESOURCE
g.
Imposing rules of engagement
h.
Providing CANDIDATE-TARGET-LIST as an aid in operational planning
i.
Linking ACTION to CONTEXT as a mechanism for specifying or recording
starting, intermediate, or ending conditions.
j.
Adding a specification to capture details of IED incidents to support tactical
reporting.
55
V3.1.4
3.14.2 Marking ACTION-OBJECTIVE-ITEM and Its Role as a Target
3.14.2.1 Some instances of ACTION-OBJECTIVE-ITEM may need to be
marked in some way either to avoid fratricide or more often to be designated as targets.
The instances of ACTION-OBJECTIVE-ITEM that are actually targets require additional
data specifications. The latter use entails two entities—TARGET and its child entity
TARGET-PERSONNEL-PROTECTION, as illustrated in the figure below.
ACTION-OBJECTIVE
is-authority-for-the-use-of /
is-used-as-specified-by
action-objective-category-code
OBJECT-ITEM
is-specified-as /
is-specification-of
ORGANISATION
is-the-user-of /
is-used-by
is-indicated-by /
is-indicator-of
ACTION-OBJECTIVE-ITEM-MARKING
action-objective-item-category-code
is-reported-by
TARGET
REPORTING-DATA
is-recognised-as-having /
is-ascribed-to
Z
TARGET-PERSONNEL-PROTECTION
is-referenced-to
Figure 22. TARGET Structure
3.14.2.2 ACTION-OBJECTIVE-ITEM-MARKING is defined as "The
technique of indicating the position of an ACTION-OBJECTIVE-ITEM at a given time
for the benefit of a using ORGANISATION." It is used to specify requirements, plans, and
results of marking an ACTION-OBJECTIVE-ITEM position or an associated reference
position. Assignment of the resource that provides marking services is specified in
ACTION-TASK. ACTION-OBJECTIVE-ITEM-MARKING provides an opportunity to
add coordinating details for the user of the marking services.
3.14.2.3 TARGET is a subtype of ACTION-OBJECTIVE-ITEM. It is defined as
"An ACTION-OBJECTIVE-ITEM that is subject to capture, destruction or intelligence
operations." Essentially, TARGET provides additional data about an ACTION-
56
V3.1.4
OBJECTIVE-ITEM when it is the focus of air-defence, direct fire support,
reconnaissance, and other operational tasks.
3.14.2.4 TARGET-PERSONNEL-PROTECTION is defined as "An assessment
of the general protective posture of personnel with respect to first and second volleys for
the specific TARGET." The protective posture refers to states such as standing, prone, dug
in, and under cover. It captures the change of state, if any, between the first volley and the
second volley. For example, personnel may have been prone at the first volley, but may be
dug in at the second volley.
3.14.3 REQUEST for Intelligence and Combat Information
3.14.3.1 Requests for intelligence need to be linked to the products of
surveillance and reconnaissance. A REQUEST is a special instance of ACTION-TASK
that can use all the functionality of the ACTION structure to specify a requirement to
collect information. The execution planning in response to the request would be done
within the same structure as any other ACTION. Once the collection is complete, one or
more REQUEST-ANSWERs can be created. The structure for REQUEST-ANSWER is
3.14.3.2 Affirmative REQUEST-ANSWER indicates that additional information
may be recorded elsewhere in the model. The pointer to such information is implemented
through the entity REQUEST-ANSWER-ELEMENT. For example, a hostile unit may
have been located at a given coordinate as a result of a search for enemy units in a
prescribed region. This information would be recorded in OBJECT-ITEM-LOCATION
that is linked to REPORTING-DATA (a topic described in a subsequent section). An
instance of REQUEST-ANSWER-ELEMENT would then be able to indicate the correct
instance of REPORTING-DATA that is part of the REQUEST-ANSWER.
57
V3.1.4
ACTION
ACTION-EVENT
ACTION-TASK
action-task-category-code
REQUEST
results-in /
is-a-response-to
REQUEST-ANSWER
is-comprised-of
is-referenced-to
REQUEST-ANSWER-ELEMENT
is-part-of
REPORTING-DATA
Figure 23. REQUEST Structure
3.14.3.3 Negative entry in REQUEST-ANSWER is actually a genuine piece of
information that cannot be recorded elsewhere. If the search for hostile units results in
none being found, then that finding is recorded in REQUEST-ANSWER.
3.14.4 Capabilities Required for an ACTION
3.14.4.1 The ability to specify a required CAPABILITY in order to complete an
ACTION is necessary for planning optimal employment of resources and for managing
resources during the life of an ACTION. ACTION-REQUIRED-CAPABILITY is defined
as "The specific CAPABILITYs required to satisfy an agreed operational need (an
ACTION)."
3.14.4.2 Use of this construct permits the matching of the available capabilities
of objects or their types to the required capabilities in the selection of the most appropriate
resources. Also, if the ACTION-REQUIRED-CAPABILITY is known, and, if a resource
that was selected to match a CAPABILITY was suddenly not available or was no longer
able to provide the requisite CAPABILITY, the knowledge helps a planner to allocate
replacement assets.
3.14.5 Role of an ORGANISATION with Respect to an ACTION
3.14.5.1 Specifying Additional Roles. The addition of an associative entity
between
ACTION
and
ORGANISATION
(ORGANISATION-ACTIONASSOCIATION) permits the explicit specification of any role or roles that an
ORGANISATION may have in relation to an ACTION over and above those implicit in
58
V3.1.4
the role of an organisation as an ACTION-RESOURCE. The roles could include initiation,
coordination, planning, authorisation, oversight, distribution of orders and so on.
3.14.5.2 Specifying Commander's Intent/Concept of Operations. The second,
important function of the entity ORGANISATION-ACTION-ASSOCIATION is to enable
the specification of commander’s intent or concept of operations for an ACTION.
Generally, this would be the top-level or mission task statement for a unit.
3.14.6 Guidance for Use of Resources
3.14.6.1 The structure consists of ACTION-RESOURCE-EMPLOYMENT and
its
subtypes
ACTION-AIRCRAFT-EMPLOYMENT,
ACTION-ELECTRONICWARFARE-EMPLOYMENT, ACTION-MARITIME-EMPLOYMENT, and ACTIONRECONNAISSANCE-EMPLOYMENT. These entities enable the operational planner to
provide additional guidance in the employment of resources either in relation to a specific
objective or independently of it. The structure is illustrated in the figure below.
requires /
is-required-for
ACTION
ACTION-RESOURCE
is-focussed-on /
is-focus-of
ACTION-OBJECTIVE
is-the-subject-of /
is-relevant-for
is-used-according-to /
describes-use-of
Z
ACTION-RESOURCE-EMPLOYMENT
action-resource-employment-category-code
ACTION-AIRCRAFT-EMPLOYMENT
ACTION-ELECTRONIC-WARFARE-EMPLOYMENT
ACTION-MARITIME-EMPLOYMENT
ACTION-RECONNAISSANCE-EMPLOYMENT
Figure 24. ACTION-RESOURCE-EMPLOYMENT Structure
3.14.6.2 ACTION-RESOURCE-EMPLOYMENT is defined as "The procedure
for using a specific ACTION-RESOURCE with or without dependence upon a specific
ACTION-OBJECTIVE." It specifies additional guidance in the use of resources for a
specific activity. The use may also depend on the objective of the activity.
3.14.6.3 ACTION-AIRCRAFT-EMPLOYMENT is defined as "The procedure
that guides the utilisation of an ACTION-RESOURCE that is capable of atmospheric
flight." The structure is currently used to specify some restrictions on aircraft employment
that are intended to avoid harm to friendly troops and that also may be useful for deconflicting fires. The main data elements are: approach offset code, terminal attack
59
V3.1.4
direction angle, egress direction angle, deplanement method code, and in-flight report
requirement indicator code.
3.14.6.4 ACTION-ELECTRONIC-WARFARE-EMPLOYMENT is defined as
"The technique used by an ACTION-RESOURCE for Electronic Warfare by electronic or
mechanical means." The structure is currently used to specify electronic or mechanical
means to conduct both offensive measures and defensive countermeasures.
3.14.6.5 ACTION-MARITIME-EMPLOYMENT is defined as "The procedure
that guides the use of an ACTION-RESOURCE in a maritime environment." The structure
is currently used to specify the parameters for coordinated air/sea procedures.
3.14.6.6 ACTION-RECONNAISSANCE-EMPLOYMENT is defined as "The
parameters that guide the use of an ACTION-RESOURCE that is employed in a
reconnaissance role." The structure is currently used to specify the parameters for
collection, such as expected extent of target coverage, whether the coverage should be
mono or stereo, and the type of sensor to be used.
3.14.7 Rules of Engagement
3.14.7.1 Rules of engagement need to be applied to operational activities. The
functions include the imposition of a rule of engagement by an authorising agency, a
request to be relieved from a rule of engagement and the consequent authorisation for
relief if appropriate, and a request that a rule of engagement be imposed and the
consequent authorisation for it if appropriate. The model incorporates for this purpose a
structure illustrated in the figure below.
ACTION
RULE-OF-ENGAGEMENT
OBJECT-ITEM
ACTION-TASK
is-the-owner-of
is-constrained-by
is-a-constraint-on
ORGANISATION
ACTION-TASK-RULE-OF-ENGAGEMENT
has
specifies
ORGANISATION-ACTION-TASK-RULE-OF-ENGAGEMENT-STATUS
Figure 25. RULE-OF-ENGAGEMENT Structure
3.14.7.2 RULE-OF-ENGAGEMENT is defined as "A specification of
mandatory guidance for the way a given activity is to be executed." In essence, it provides
a list of rules. ACTION-TASK-RULE-OF-ENGAGEMENT is defined as "The imposition
of a specific RULE-OF-ENGAGEMENT on a specific ACTION-TASK." It links rules to
an activity. ORGANISATION-ACTION-TASK-RULE-OF-ENGAGEMENT-STATUS is
defined as "The status of the relationship between a specific ORGANISATION and a
specific ACTION-TASK-RULE-OF-ENGAGEMENT with respect to a request for
60
V3.1.4
application, a request for cancellation, or an authorisation." It is a mechanism for
managing rules of engagement.
3.14.8 Candidate Target Lists
3.14.8.1 The primary purpose of this structure is to enable the building of target
lists for consideration during planning processes. The notion of a potential target is
different from the notion of TARGET (a model entity) that is actually specified as an
objective of an activity. The structure permits the nomination of targets at any number of
echelons with or without a change in target numbering. An item or type may be nominated
as a target multiple times, possibly with a different activity focus in each nomination. The
authorisation of candidate targets may also occur at multiple levels.
3.14.8.2 The structure to record potential targets includes two tiers of entities:
the first to create candidate target lists and the second to itemise candidate targets
individually. The entities CANDIDATE-TARGET-LIST and CANDIDATE-TARGETDETAIL serve this purpose. Authorisations for lists in their entirety and individual targets
separately are provided through CANDIDATE-TARGET-LIST-AUTHORISATION and
CANDIDATE-TARGET-DETAIL-AUTHORISATION. Since target lists are often likely
to be related to each other, such as battalion and brigade-nominated lists with division
lists, the model includes the CANDIDATE-TARGET-LIST-ASSOCIATION. A similar
provision is made for relating individual targets, for example, the elements of a complex
target such as a military airbase, a major logistics facility, or a naval port, through the
entity CANDIDATE-TARGET-DETAIL-ASSOCIATION. The structure is illustrated in
the figure below.
is-the-subject-of
is-the-object-of
consists-of /
makes-up
CANDIDATE-TARGET-LIST-ASSOCIATION
is-assigned /
is-the-approval-for
CANDIDATE-TARGET-DETAIL
CANDIDATE-TARGET-LIST-AUTHORISATION
is-the-subject-of
is-the-object-of
CANDIDATE-TARGET-DETAIL-ASSOCIATION
is-assigned /
is-the-approval-for
CANDIDATE-TARGET-DETAIL-AUTHORISATION
candidate-target-detail-category-code
CANDIDATE-TARGET-DETAIL-ITEM
CANDIDATE-TARGET-DETAIL-TYPE
Figure 26. Candidate Target Structure
61
V3.1.4
3.14.8.3 CANDIDATE-TARGET-LIST structure can be used to create
prioritised lists of individually identified candidates. For example, Division A could
nominate an enemy brigade for attack, a radar site for intercept activity, and an area in
which friendly fire is to be avoided because a long-range reconnaissance patrol may be
occupying it. The same structure can also be used to create targeting objectives by classes
that may reflect the commander’s intent: for example—in order of priority—commandand-control centres, armoured fighting vehicles, POL supplies, and fire-control radars.
Target lists can also be nested.
3.14.8.4 Candidate target lists and individual candidate targets can be linked to
the ACTION structure as illustrated in the figure below. The connection can be at the list
level or for individual item or type that is nominated for consideration in the operational
planning process.
ACTION
is-focussed-on /
is-focus-of
may-be-used-in-planning /
planning-may -use
ACTION-OBJECTIVE
consists-of /
makes-up
ACTION-TASK
CANDIDATE-TARGET-DETAIL
action-objective-category-code
candidate-target-detail-category-code
may-be-specified-as /
may-specify
ACTION-OBJECTIVE-TYPE
CANDIDATE-TARGET-DETAIL-ITEM
may-be-specified-as /
may-specify
CANDIDATE-TARGET-DETAIL-TYPE
Figure 27. Linking Candidate Targets to Operations Planning
3.14.9 Locating ACTION Directly
3.14.9.1 An instance of ACTION is normally located indirectly by specifying
the location of an instance of ACTION-RESOURCE-ITEM or ACTION-OBJECTIVEITEM or both. However, a requirement exists to locate an activity without recourse to
either resource or objective or both. The primary uses are in (a) stating broad mission-level
requirements in plans and orders and (b) locating instances of ACTION-EVENTs.
3.14.9.2 Mission-type planning may entail embodiment of commander’s intent
in outlining schemes of manoeuvre or defensive postures that are to be prepared. The
62
V3.1.4
statements at the high level may be simply that a friendly formation is to block here,
execute a supporting attack there, and concentrate the main attack here. These are
examples of general activity statements from which the detailed statements will be
developed. If the entire plan is thought of in hierarchical terms of actions and sub-actions,
these activities would be near the root of the hierarchy. Standards, such as APP-6(A),
support symbology for activities of the kind cited. The ability to situate task graphics for
display independently of the location of resources or objectives is an operational
requirement.
3.14.9.3 Event reporting may also be accomplished simply by being able to give
the location of the event. For example, I see enemy tanks moving at Point P1 or I see
enemy activity in Area A2. There may nothing of particular interest at P1 or A2 that could
serve as a suitable reference to establish a location. The report basically describes an
activity at some location citing a type of object as a resource. A type object cannot be
located directly within the constraints of the data specification and it should not be
necessary to create an instance of an artificial item simply to serve as a reference for
location. Similar situation may occur in the civil sector in reporting drive-by shootings,
eruptions of riots, and pools of flooding. In some cases, such as flooding, there is neither a
resource nor an objective.
3.14.9.4 The data specification includes an associative entity ACTIONLOCATION that enables geolocating an instance of ACTION directly without necessarily
relying on the location of a resource or an objective.
3.14.10 Context for an ACTION
3.14.10.1 CONTEXT structure enables the specification of related data of the
type that is referred to as an operational overlay. The planner can use the CONTEXT
information to judge the merits of a plan or an order, and to assess a need for changes.
Broader view of CONTEXT is discussed in a subsequent section.
3.14.10.2 ACTION-CONTEXT links ACTION to CONTEXT. In general,
CONTEXT helps to set the whole situation, background, or environment relevant to a
particular ACTION. It can specify conditions that must precede an ACTION or those that
should result from the execution of an ACTION. It can also be used to impose additional
constraints on ACTIONs and to preserve a historical sequence of snapshots of the actual
execution of plans.
3.14.11 IED Incident Characterization
3.14.11.1 The basic description of an IED incident is accommodated by the
ACTION and ACTION-EVENT structure as shown in the figure below. The IED itself as
a physical object will be represented as an instance of OBJECT-ITEM. The IED will have
a role as either a resource—if it explodes—or as an objective if it is discovered in an
unexploded state. The status information for an incident is captured through ACTIONEVENT-STATUS. The geolocation or position of the IED is reported through ACTIONLOCATION (as described in Section 3.14.9). The status and location entities are linked to
REPORTING-DATA to capture the date/time, reporting organisation, and other details.
63
V3.1.4
3.14.11.2 The tactical employment features that are germane to an IED incident
are specified in the entity IED-TACTICAL-CHARACTERIZATION—a subtype of
ACTION-EVENT-DETAIL. More than one instance of an IED-TACTICALCHARACTERIZATION report may be made against the same incident since the entity is
a subtype of ACTION-EVENT-DETAIL and therefore linked to REPORTING-DATA
that provides details about each source of information.
ACTION
action-id
action-name-text
ACTION-EVENT-STATUS
ACTION-EVENT
action-event-id (FK)
action-event-status-index
has /
is-ascribed-to
action-event-status-completion-ratio
action-event-status-feint-indicator-code
reporting-data-id (FK)
is-detailed-through
ACTION-EVENT-DETAIL
is-referenced-to
action-event-detail-index
action-event-detail-classification-code
action-event-detail-crime-indicator-code
action-event-detail-text
action-event-detail-intended-outcome-code
is-referenced-to
REPORTING-DATA
reporting-data-id
reporting-data-accuracy-code
reporting-data-category-code
reporting-data-counting-indicator-code
reporting-data-credibility-code
reporting-data-reliability-code
reporting-data-reporting-datetime
reporting-data-source-type-code
reporting-data-timing-category-code
reporting-data-real-data-exercise-use-only-code
reference-id (FK)
reporting-data-reporting-organisation-id (FK)
IED-TACTICAL-CHARACTERIZATION
action-event-detail-index (FK)
ied-tactical-characterization-emplacement-code
ied-tactical-characterization-employment-method-code
ied-tactical-characterization-suicide-code
ied-tactical-characterization-use-sequence-code
ied-tactical-characterization-vehicle-placement-code
Figure 28. Tactical Characterization of IEDs
3.15
Plans and Orders
3.15.1 The basic operational requirements for plans and orders are the provisions
of STANAG 2014 Edition 9. The data schema is designed to:
a.
Satisfy most STANAG 2014 requirements in storing a plan or order in data
and maintaining the proper structure or paragraphing,
64
V3.1.4
b.
Enable the use of the ACTION and other JC3IEDM specifications of
structured data to represent those parts of a plan or order that are appropriate
for structured data,
c.
Permit the use of textual information to specify those parts of a plan or order
that cannot be expressed as structured data,
d.
Permit the use of textual information to supplement those parts of a plan or
order that are represented as structured data.
3.15.2 The structure is shown in the figure below.
OBJECT-ITEM
PLAN-ORDER
PLAN-ORDER-HEADER-CONTENT
P
PLAN-ORDER-COMPONENT
ORGANISATION
PLAN-ORDER-ASSOCIATION
ORGANISATION-PLAN-ORDER-ASSOCIATION
ORGANISATION-PLAN-ORDER-ASSOCIATION-STATUS
PLAN-ORDER-DISTRIBUTION
PLAN-ORDER-DISTRIBUTION-ACKNOWLEDGEMENT
PLAN-ORDER-COMPONENT-STRUCTURE
plan-order-category-code
Z
COMPONENT-TEXT-CONTENT
P
PLAN
Z
ORDER
PLAN-ORDER-COMPONENT-CONTENT
P
PLAN-STATUS
PLAN-ORDER-COMPONENT-CONTENT-REFERENCE
P
ORDER-STATUS
REFERENCE
CONTEXT
context-category-code
Z
OPERATIONAL-INFORMATION-GROUP
OPERATIONAL-INFORMATION-GROUP-PLAN-ORDER-CONTENT
Figure 29. Plans and Orders Structure Shown at Entity Level
3.15.3 PLAN-ORDER is the top-level entity through which warning orders, plans,
operation orders, fragmentary orders, separate annexes, and any other document identified
in STANAG 2014 can be managed. The content that applies to the entirety of a PLANORDER is specified in PLAN-ORDER-HEADER-CONTENT.
3.15.4 The detailed content for an instance of PLAN-ORDER is specified using
the child entity PLAN-ORDER-COMPONENT. It serves as the basis for collecting all of
the information that is attendant to the component. It handles the following tasks:
65
V3.1.4
a.
Multilayer hierarchical structuring among the components in terms of their
relative position within a plan or order as well as linking components from
one instance of PLAN-ORDER to another.
b.
Providing substantive content for each component. This is accomplished
through PLAN-ORDER-COMPONENT-CONTENT that acts as a collector
of applicable information by providing points of attachment for groups of
data from other parts of the model, such as header, textual information,
structured data information, and external references.
3.15.5 Supporting structures deal with relationships between an instance of
PLAN-ORDER to ORGANISATION and between different instances of PLAN-ORDER;
distribution lists and acknowledgements; and the grouping of instances of PLAN-ORDER
into OIGs for dissemination.
3.15.6 ORGANISATION-PLAN-ORDER-ASSOCIATION
enables
the
identification of the organisation responsible for the plan as well as the organisation (oneperson post, such as the commander) that authorises the plan. The individual who occupies
the post can be identified in the existing data structure via association between PERSON
and an ORGANISATION that is a post. The entity ORGANISATION-PLAN-ORDERASSOCIATION-STATUS specifies the starting or stopping of the associations.
3.15.7 PLAN-ORDER-ASSOCIATION permits the management of plans in terms
of succession. The functionality includes attaching separately managed annexes to the
main plan, the instances of PLAN-ORDER that turn a plan into an order, and FRAGO
instances that modify an order.
3.15.8 STANAG 2014 specifies distribution lists and a need for
acknowledgement. The specification provides for these requirements through the entities
PLAN-ORDER-DISTRIBUTION
and
PLAN-ORDER-DISTRIBUTIONACKNOWLEDGEMENT.
3.15.9 The specification includes two status entities to keep track of progress of
instances of a plan or an order via the entities PLAN-STATUS and ORDER-STATUS.
3.15.10 The
entity
OPERATIONAL-INFORMATION-GROUP-PLANORDER-CONTENT enables the identification of instances of PLAN-ORDER as a
coherent group that is attached to an OPERATIONAL-INFORMATION-GROUP that is
then used as a mechanism in replication. A specific example would be the grouping of a
main plan and its separately managed annexes.
3.16
Data about Reported Data
3.16.1 Introduction
3.16.1.1 Considerable amount of information about a situation in an operational
arena consists of reports by persons or organisations. These generally refer to dynamic
data, such as location, status, holdings, associations, and classification, regardless of
whether the information refers to friendly, neutral, or hostile elements. It is also important
to know for each estimate or report its validity, source, effective starting or ending times,
and reporting time. The model captures the substantive information in numerous entities
and the amplifying information in REPORTING-DATA and its subtypes.
66
V3.1.4
3.16.1.2 Amplifying information enables a staff officer to compare different
reports and make a sensible interpretation of the data. It also allows the staff officer to
enter his own perception of reality based upon the raw data; this may be particularly
applicable to an intelligence function that produces correlated information at a higher
quality level.
3.16.1.3 REPORTING-DATA permits a mechanism for maintaining a historical
record that applies not only to the past and present, but also to the future. Thus, it is just as
easy to record that the required stockage level of an ammunition stock should be 10,000
three days from now as it is to record that the reported stockage level yesterday was 8,200.
3.16.2 REPORTING-DATA Structure
3.16.2.1 REPORTING-DATA is defined as the specification of source, quality
and timing that applies to reported data. Its structure is illustrated in the figure below. It
has a mandatory relationship to ORGANISATION whose role is that of a reporting agent.
Its two subtypes serve to specify timing information.
REPORTING-DATA
provides-information-related-to /
is-amplified-by
REFERENCE
REPORTING-DATA-ABSOLUTE-TIMING
REPORTING-DATA-RELATIVE-TIMING
ACTION
serves-as-timing-reference-for /
uses-as-timing-reference
OBJECT-ITEM
ACTION-TASK
is-reported-by
ORGANISATION
Figure 30. Structure for REPORTING-DATA
3.16.2.2 Ability to cite sources of information that are external to the data
structures is useful. The sources could be ADatP-3 messages, printouts of electronic mail,
memoranda of telephone conversations, and other physical storage means that need to be
consulted. REFERENCE provides this functionality. REFERENCE pointers can be
67
V3.1.4
associated with one or more instances of REPORTING-DATA in order to amplify the data
that is referred to by REPORTING-DATA.
3.16.3 Specifying Time
3.16.3.1 Time points and time periods need to be specified; for example, the
starting time of an action, the reporting time of a situation report, and the period of time
covered by a weather forecast. Time may be fixed or relative:
a.
Fixed (absolute) with respect to the standard calendar (e.g., 120700Z Sep69)
b.
Relative with respect to an arbitrary origin that may be unspecified (e.g.,
D+3).
Absolute and relative time characteristics are captured in subtypes REPORTING-DATAABSOLUTE-TIMING and REPORTING-DATA-RELATIVE-TIMING.
3.16.3.2 REPORTING-DATA-ABSOLUTE-TIMING is defined as "A
REPORTING-DATA that specifies effective datetime that is referenced to Universal
Time." The specified time can be in the past, the present, or the future. The date follows
the Gregorian calendar and the 24-hour clock time is defined with respect to Universal
Time.
3.16.3.3 Effective time can also be relative. REPORTING-DATA-RELATIVETIMING is defined as "A REPORTING-DATA that specifies effective timing that is
referenced to a specific ACTION-TASK." Relative timing makes operational sense only in
relation to planned activities; consequently, the origin of the time scale is established in
reference to an instance of ACTION-TASK.
3.17
Applying Security Classifications
Security classification is applied to the entities shown in the figure below. The data
elements in SECURITY-CLASSIFICATION provided for classification level,
classification policy, and an appropriate caveat if applicable.
CONTEXT
REFERENCE
NETWORK-SERVICE
Figure 31. Relationships from SECURITY-CLASSIFICATION
68
V3.1.4
3.18
Citing External Information Sources
3.18.1 REFERENCE structure provides the ability to cite external sources of
information. REFERENCE is defined as "Identification of a record of information." The
structure of REFERENCE and its relationships to ACTION, CAPABILITY, OBJECTITEM, OBJECT-TYPE, ORGANISATION, REPORTING-DATA, SECURITYCLASSIFICATION and itself is illustrated in the figure below.
3.18.2 The information that instances of REFERENCE point to can be used to
amplify or support the data in one or more instances of the associated entities. The entity
REFERENCE-ASSOCIATION enables the recording of relationships between instances
of REFERENCE. In addition, the entity ORGANISATION-REFERENCEASSOCIATION identifies the administrative role that any instance of databased
ORGANISATION has with respect to an instance of REFERENCE. Note that the
organisational roles internal to documents cited in REFERENCE are identified in one of
the attributes of REFERENCE.
is-the-subject-of
is-the-object-of
REFERENCE
applies-to
REFERENCE-ASSOCIATION
has-relevant-information-in
ACTION
ACTION-REFERENCE-ASSOCIATION
applies-to
CAPABILITY
CAPABILITY-REFERENCE-ASSOCIATION
applies-to
OBJECT-TYPE
OBJECT-TYPE-REFERENCE-ASSOCIATION
applies-to
OBJECT-ITEM
OBJECT-ITEM-REFERENCE-ASSOCIATION
is-amplified-by
REPORTING-DATA
is-reported-by
is-administered-by
ORGANISATION
has-a-role-w ith-respect-to
ORGANISATION-REFERENCE-ASSOCIATION
provides-to
Figure 32. REFERENCE and Its Relationships
69
V3.1.4
3.18.3 A variety of examples are illustrated in the table below. There are
references to an e-mail message, a transcript of a report over combat net radio, a facsimile
sent over a secure line, a printed report by a UN commission, a NATO dictionary, a book
on data modelling, and others. Any of these can be linked to information in a database
through the relationship that REFERENCE has to other entities.
3.18.4 The appropriate security classification that applies to a reference is
identified by a link to SECURITY-CLASSIFICATION, as illustrated in Sub-table (b).
Table 14. Examples of REFERENCE
(a) REFERENCE
*-id
*-contentcategorycode
*-title-text
securityclassificatio
n-id
301
Report
Potential terrorist
activity
Electronic file,
detached
physical
storage
2nd
Intelligence
Group
IGR-725
—
sc555
102
Report
Paper-based
—
—
Report
FO Capt
Ertugrul
7th Signal
Battalion
SR-291
567
Sighting of
enemy position
Communications
status for 7th
Division
COMSITREP
—
sc556
890
Report
—
Paper-based
UN
Commission
on Human
Rights
—
—
123
Guidance
—
NATO MAS
AAP-06
456
Technical
document
—
Electronic file,
detached
physical
storage
Paper-based
Thomas A.
Bruce
—
6606
Guidance
—
Paper-based
NIMA
STANAG
2211
990
Order
—
Paper-based
HQ 3rd
Division
OPORD 0417
7713
Guidance
—
Paper-based
TO-1-1F111D-1
1234
Technical
document
—
—
Air Force
Materiel
Command
MIP DMWG
4433
Technical
document
Description of
signal equipment
Paper-based
HQDA
Human
Rights
Situation in
Bradyland
NATO
Glossary of
Terms and
Definitions
Designing
Quality
Databases
with IDEF1X
Information
Models
Geodetic
Datum,
Projection,
Grids and
Grid
References
Ops Order
for Operation
Purple
Dragon
F-111D
Flight
Manual
The C2
Information
Exchange
Data Model
(C2IEDM
Main)
Signal Data
References:
Signal
Equipment
*-descriptiontext
*-mediumtype-code
*-originatortext
*-short-titletext
Paper-based
Note: * = "reference"
70
C2IEDMMain-USDMWGEdition6.1
FM 24-24
sc557
—
sc558
V3.1.4
(b) SECURITY-CLASSIFICATION
**-id
**-level-code
**-policy-text
**-caveat-text
sc555
sc556
sc557
sc558
Confidential
Secret
Unclassified
Unclassified
—
—
—
—
—
—
—
—
Note: ** = "security-classification"
3.19
CONTEXT as a Way of Grouping Data
3.19.1 Introduction
3.19.1.1 Data tends to be distributed in various tables throughout a database that
is designed on relational principles. Even a single table may contain disparate elements of
data. Operational needs strongly support the concept of "grouping" or "packaging" data in
order to provide a coherent picture that is relevant to a given situation or circumstance.
CONTEXT provides a mechanism for referring to one or more records in various tables
and treating them as a single "context."
3.19.1.2 CONTEXT may entail a collection of data that is relevant to the
situation, background, or environment for a particular unit or activity. It can specify
conditions that must precede an ACTION or those that should result from the execution of
an ACTION. A planner can use the context information to judge the merits of an
operational plan, and make changes in order to respond to a changing operational
situation. A commander can use the context information to provide his assessment.
CONTEXT can also be used to record the history of an evolving operation, capture a
situation as it existed at some time in the past or portray a situation as it is expected to
exist at a future date.
3.19.1.3 Since a specific CONTEXT can represent the view of the current
operational picture that is held by a particular unit, it can be shared with other units or
organisations. The sharing need not be limited to the operational picture, but can apply to
any defined concept that can be encompassed within CONTEXT specifications. One of the
possible applications of CONTEXT is to serve as the basis for exchange or distribution of
information.
3.19.2 Basic CONTEXT Structure
3.19.2.1 The basic structure of CONTEXT consists of CONTEXT-ELEMENT
and its status, CONTEXT-ASSOCIATION and its status, and a subtype OPERATIONALINFORMATION-GROUP (in brief, OIG19). The structure that enables an instance of
CONTEXT to be defined, amended, and managed is illustrated in the figure below.
3.19.2.2 Data that is to be associated with an instance of CONTEXT is identified
through CONTEXT-ELEMENT. Data may be moved in or out of an instance of
CONTEXT by indicating the particular instances of CONTEXT-ELEMENT that apply at
any given time. The entity CONTEXT-ELEMENT-STATUS keeps track of the inclusion
19
OIG is not a formal abbreviation; it is used only in the explanatory text.
71
V3.1.4
status and its timing. This technique preserves data integrity while allowing the data
content to change for any instance of CONTEXT.
3.19.2.3 The entity CONTEXT-ASSOCIATION and its child entity to indicate
status permit the linking of one instance of CONTEXT to another with the relationship
defined by the value of the category code in the association.
3.19.2.4 OPERATIONAL-INFORMATION-GROUP
is
a
specialised
CONTEXT with defined categories of operational information. The concept of an
operational information group was created in order to have sets of information that are
subject to standard definition of their content, and represent the owning organisation’s
view at a given time, such as the current friendly picture. Once an instance of an
OPERATIONAL-INFORMATION-GROUP is created, it is to be maintained under the
same identifier but the content of the instance is permitted to change over time.
OPERATIONAL-INFORMATION-GROUP is used by applications to manage
organisational views of data and to exchange them with other participants.
provides-to
CONTEXT
is-the-object-of
CONTEXT-ASSOCIATION
is-the-subject-of
has /
is-ascribed-to
has-as-constituent-part /
is-a-part-of
P
CONTEXT-ASSOCIATION-STATUS
Z
OBJECT-ITEM
CONTEXT-ELEMENT
is-cited-in /
is-referenced-to
has /
is-ascribed-to
establishes /
is-established-by
P
CONTEXT-ELEMENT-STATUS
REPORTING-DATA
establishes /
is-established-by
is-reported-by
ORGANISATION
Figure 33. Basic CONTEXT Structure
72
V3.1.4
3.19.3 Relationship of CONTEXT to Other Entities
CONTEXT is related to other entities as illustrated in the figure below. The
functionality that the associations provide is summarised as follows:
CONTEXT
is-the-subject-of
CONTEXT-REPORTING-DATA-ASSOCIATION
is-the-object-of
REPORTING-DATA
is-reported-by
is-cited-by
P
OPERATIONAL-INFORMATION-GROUP-ORGANISATION-ASSOCIATION
has /
is-ascribed-to
has-a-role-with-respect-to
P
OPERATIONAL-INFORMATION-GROUP-ORGANISATION-ASSOCIATION-STATUS
is-the-subject-of
establishes /
is-established-by
OBJECT-ITEM
is-the-object-of
CONTEXT-OBJECT-ITEM-ASSOCIATION
has /
is-ascribed-to
ORGANISATION
establishes /
is-established-by
establishes /
is-established-by
CONTEXT-OBJECT-ITEM-ASSOCIATION-STATUS
provides-circumstances-for
ACTION-CONTEXT
ACTION-CONTEXT-STATUS
has /
is-ascribed-to
is-placed-within
ACTION
Figure 34. CONTEXT Associations
a.
An instance of CONTEXT can be related to an instance of ACTION. This is
an important linkage that:
(i)
Permits an ACTION to be made a part of a CONTEXT in defining
Operational Information Groups
(ii) Enables packages of information to be coupled to plans and orders
making them a condition of plans or orders or amass related
information, such as the trace of activity in time.
b
An instance of CONTEXT can be related to an instance of OBJECT-ITEM.
This permits:
73
V3.1.4
(i)
A set of information to be associated with an instance of OBJECTITEM or
(ii) Make an instance of OBJECT-ITEM part of CONTEXT.
c.
OPERATIONAL-INFORMATION-GROUP is a subtype of CONTEXT. It
is an important concept that makes extensive use of CONTEXT and its
relationships. The association with ORGANISATION aids in the
management of OPERATIONAL-INFORMATION-GROUPs.
d.
CONTEXT can support correlation of data where several elements of
information are collected as part of the CONTEXT and can then be related to
the "new" information that is derived from the "raw" data via CONTEXTREPORTING-DATA-ASSOCIATION.
3.19.4 CONTEXT-ASSESSMENT
3.19.4.1 The entity CONTEXT-ASSESSMENT provides an opportunity for an
ORGANISATION to add to any instance of CONTEXT a limited amount of free-text
information to convey information that cannot be represented in structured data. One of
the possibilities is to give an overall appraisal of unit capability where CONTEXT collects
the relevant elements of information, such as status, location, and holdings. Explanatory
information can be added to plans and orders when an instance of CONTEXT with an
assessment is linked to an instance of ACTION. Addition of text in CONTEXTASSESSMENT is optional, but if an assessment is added it becomes an integral part of the
"context."
3.19.4.2
The structure for CONTEXT-ASSESSMENT is illustrated in the figure
below.
OBJECT-ITEM
CONTEXT
is-a-part-of
ORGANISATION
CONTEXT-ELEMENT
identifies-the-data-for
CONTEXT-ASSESSMENT
is-referenced-to
is-cited-in /
is-referenced-to
is-reported-by
REPORTING-DATA
Figure 35. CONTEXT Assessment
74
V3.1.4
3.20
Attaching Affiliation to Items and Types
3.20.1 General Description
3.20.1.1 There is a need to identify, for various reasons, one or more
associations according to country, nationality, ethnicity, or allegiance. It is quite
conceivable to have a person of one nationality, associated with a country that is different
from his nationality, and owing allegiance to yet another entity that may not even be a
country.
3.20.1.2 The independent entity AFFILIATION has four subtypes that represent
sets of values to enable the tagging of types or items. AFFILIATION has an identifying
relationship to OBJECT-TYPE to set the persistent type characteristics. AFFILIATION is
linked to OBJECT-ITEM to enable the specification of individual exceptions to the
characterisation that an item inherits by association with a type.
3.20.1.3
The structure is illustrated in the figure below.
OBJECT-ITEM
OBJECT-TYPE
has
has
OBJECT-TYPE-AFFILIATION
is-ascribed-to
OBJECT-ITEM-AFFILIATION
is-referenced-in
AFFILIATION
affiliation-category-code
AFFILIATION-ETHNIC-GROUP
AFFILIATION-FUNCTIONAL-GROUP
AFFILIATION-GEOPOLITICAL
AFFILIATION-RELIGION
Figure 36. Structure for Specifying Affiliations
3.20.2 Specification of AFFILIATION and Its Subtypes
3.20.2.1 An AFFILIATION is defined as "A specification of a country,
nationality, ethnic group, functional group, exercise group, or religion to which
membership or allegiance may be ascribed." The subtype AFFILIATION-ETHNICGROUP provides a list of ethnic groups. AFFILIATION-FUNCTIONAL-GROUP
specifies groups characterised by their primary purpose. It also has a name attribute that
permits the entry of any ad hoc description within criminal, exercise, multinational, and
terrorist categories. AFFILIATION-GEOPOLITICAL provides a list of countries or
75
V3.1.4
political entities. The list includes country or nationality codes that have been aligned with
country code list in ISO 3166. AFFILIATION-RELIGION provides a list of religions.
3.20.2.2 AFFILIATION-FUNCTIONAL-GROUP enables the specification of
groups as data since it is difficult to determine in advance all the potential functional
groups, and it is equally indeterminate how many exercise countries or other objects may
be needed.
3.20.3 AFFILIATION Relationships
3.20.3.1 An OBJECT-TYPE-AFFILIATION is defined as "A relationship
between a specific OBJECT-TYPE and a specific AFFILIATION that identifies an
inherent allegiance." This entity is to be used routinely to assign a permanent normal or
persistent affiliation to an instance of OBJECT-TYPE. Because each instance of OBJECTITEM must be associated with at least one instance of OBJECT-TYPE, the item inherits
allegiance characteristics from the type.
3.20.3.2 An OBJECT-ITEM-AFFILIATION is defined as "A relationship
between a specific OBJECT-ITEM and a specific AFFILIATION." This entity is intended
to record exceptions to affiliations identified in OBJECT-TYPE and may include the
following cases:
3.21
a.
Affiliations that differ from the type affiliation that are inherited through
OBJECT-ITEM-TYPE.
b.
Serial affiliations that represent succession of affiliations over time.
c.
Multiple affiliations that are valid at the same time.
Counting Persons by Group Characteristics
3.21.1 Introduction
3.21.1.1 Article V First Hostile Act and multiple CRO requirements point to a
need to count PERSON-TYPEs grouped by one or more characteristics that in effect
stratify or segment a given population. The data structure described in this section permits
the counting of PERSON-TYPEs according to one or more characteristics. It enables the
reporting of the number of killed and injured as the result of a bomb explosion or some
other form of attack. It also satisfies a number of CRO requirements for accounting of
refugee camp occupants. For example, one could express how many young girls from
Kosovo are afflicted with diphtheria.
3.21.1.2
The structure is presented in the figure below.
76
V3.1.4
OBJECT-TYPE
OBJECT-ITEM
has-an-associated /
is-associated-with
PERSON-TYPE
OBJECT-ITEM-GROUP-ACCOUNT
is-cited-in /
is-the-count-of
is-enumerated-in /
is-part-of
OBJECT-ITEM-GROUP-ACCOUNT-DETAIL
is-the-reason-for /
is-based-on
ACTION
provides-categorisation-for /
is-classified-according-to
Figure 37. Structure for Counting PERSON-TYPEs
3.21.2 Description of Counting Structure
3.21.2.1 The structure is made up of two principal parts. The first consists of the
entity OBJECT-ITEM-GROUP-ACCOUNT and its child OBJECT-ITEM-GROUPACCOUNT-DETAIL. These entities permit as many groupings to be accounted for as is
necessary for an instance of OBJECT-ITEM at a specified time. The actual count is
specified in OBJECT-ITEM-GROUP-ACCOUNT-DETAIL together with an attribute that
further qualifies the count to account for morbidity and other states that the counted group
may occupy. The count could be for a refugee camp, hospital, POW camp, or another
facility; an organisation; a geographic location; a control feature; or even a meteorologic
feature, such as an area affected by a tornado. The second part is the GROUPCHARACTERISTIC entity. It permits as many factors to be entered as needed
simultaneously in order to capture the required stratification. Thus, we could be talking
about the number of Algerian adult females who happen to be Catholic and are infected by
smallpox and are triaged as T4.
3.21.2.2 The current design permits group counting only for instances of
PERSON-TYPE that are identified through a mandatory non-identifying relationship from
PERSON-TYPE to OBJECT-ITEM-GROUP-ACCOUNT-DETAIL. The limitation is due
to the set of operational requirements that pointed only to types of persons. The structure
can be generalised to encompass OBJECT-TYPE or additional structure could be added to
accommodate likely counting possibilities for other types, such as MATERIEL-TYPE.
3.21.2.3 The characteristics that apply to any particular group that is to be
counted may be drawn from the native attributes of the entities OBJECT-TYPE,
PERSON-TYPE, and GROUP-CHARACTERISTIC. The relationship between GROUPCHARACTERISTIC and OBJECT-ITEM-GROUP-ACCOUNT-DETAIL has been made
optional to permit cases where the grouping inherent in the definition of PERSON-TYPE
77
V3.1.4
(that necessarily includes OBJECT-TYPE) provides an adequate set of discriminators for
the desired count.
3.21.2.4 The underlying cause or causes for the reported counting must be
specified through the ACTION structure. The specific link is the optional non-identifying
relationship from ACTION to OBJECT-ITEM-GROUP-ACCOUNT. The ACTION
structure enables the identification of the agent (ACTION-RESOURCE) and the "target"
(ACTION-OBJECTIVE) as appropriate.
3.21.3 Specification of Counting Structure
3.21.3.1 A GROUP-CHARACTERISTIC is defined as "A reference to a set of
characteristics that may be used for identifying a distinct collection of objects." The
characteristics that can be selected are age group, gender, malady type, malady
transmissibility indicator, language, and triage code.
3.21.3.2 An OBJECT-ITEM-GROUP-ACCOUNT is defined as "A reference to
accounting for a set of groups that are associated with the specific OBJECT-ITEM at the
time specified by REPORTING-DATA. The accounting may result from or be affected by
a specific ACTION."
3.21.3.3 An OBJECT-ITEM-GROUP-ACCOUNT-DETAIL is defined as "The
total count and condition of a specific group included in a specific OBJECT-ITEMGROUP-ACCOUNT. The group is defined as a specific PERSON-TYPE that may also be
categorised by a specific GROUP-CHARACTERISTIC." The key attributes account for
the number in a group and a qualifier that adds descriptors such as ailing; captured;
deserted; killed; or missing.
3.22
Summary of JC3IEDM Features
3.22.1 An overview of the data model is illustrated in the figure below. The main
entities are shaded in grey. The grouping of entities is instructive in itself. The bottom part
of the diagram centred about OBJECT-TYPE, OBJECT-ITEM, and LOCATION is
intended to support situational awareness: what is out there, what it has, what is it
supposed to have, where it is, what is its status, what are its relationships with other
objects.
78
V3.1.4
PLAN-ORDER
REFERENCE
CAPABILITY
ACTION As soci ations
ACTION
RULE-OF-ENGAGEMENT
ACTION-OBJECTIVE
ACTION-RESOURCE
REPORTING-DATA
ACTION-EFFECT
CONTEXT
OBJECT-TYPE
HOLDING
OBJECT-ITEM-TYPE
AFFILIATION
OBJECT-ITEM
ADDRESS
LOCATION
OBJECT-ITEM-STATUS
VERTICAL-DISTANCE
COORDINATE-SYSTEM
Figure 38. High-Level View of JC3IEDM
3.22.2 The upper part is focused on PLAN-ORDER, ACTION with
CAPABILITY, CONTEXT, and RULE-OF-ENGAGEMENT being oriented primarily to
ACTION. Much of this data tends to be dynamic in nature: what are the objects capable of
and how are they to be used, how are they being used, and what are they achieving.
3.22.3 REPORTING-DATA plays a special role in the model. It records reporting
data about much of the information held in the lower part of the model. It also serves as
the means for that information to be used in multiple ways in developing courses of action,
allocating resources, preparing plans, and executing operations orders, all of which are in
the province of the upper part of the model.
3.22.4 The upper and the lower parts are connected through a number of
associative entities that are used for linking plans, orders, and requests through objectives,
resources, and effects to OBJECT-TYPEs and OBJECT-ITEMs.
3.22.5 An example to illustrate the use of the data structures follows.
79
V3.1.4
3.23
Examples of Potential Use
3.23.1 Plans and Orders
A plan may be structured in a five-paragraph format using the PLAN-ORDER
structure. Part of its content may be provided by ACTION specifications, as discussed
below.
3.23.2 Supporting PLAN-ORDER via ACTION
The steps in developing the ACTION specifications to support a PLAN-ORDER:
may include the following:
a.
Create a new ACTION-TASK or specify new parameters for an existing
ACTION in order to take the initiative or to respond to an ACTION-EVENT.
b.
Add detail to the ACTION-TASK by using the functional and temporal
associations. This permits the subdivision of the plan into sub-activities with
differing functional and temporal relationships to the high-level plan.
c.
Identify the ACTION-OBJECTIVEs in terms of OBJECT-TYPEs and/or
OBJECT-ITEMs. This is the mechanism for identifying key objectives in
terms of enemy units, facilities, and materiel (e.g., destroy a bridge in enemy
held territory).
d.
Search for the required CAPABILITYs to perform the ACTION. This is the
process of matching the appropriate ACTION-RESOURCE to meet the
requirements of a specific ACTION. For example, crossing of an obstacle
requires the employment of an engineer UNIT-TYPE with the appropriate
CAPABILITY, and the movement of personnel requires vehicles or aircraft
with the appropriate payloads.
e.
Allocate OBJECT-TYPE as an ACTION-RESOURCE to an ACTIONTASK based on its OBJECT-TYPE-CAPABILITY-NORM. Having
identified the requirement for troop-carrying vehicles, this step requires the
allocation of, for example, 12 Blackhawk helicopters.
f.
Search for OBJECT-ITEMs whose OBJECT-ITEM-CAPABILITY matches
the OBJECT-TYPE-CAPABILITY-NORM for their type in order to
determine what resources are available for this ACTION. For example, the
3rd US Aviation Brigade may have 24 Blackhawk helicopters and the 1st US
Marine Expeditionary Force may have 12.
g.
Allocate individual OBJECT-ITEMs as ACTION-RESOURCEs to an
ACTION-TASK. Twelve Blackhawk helicopters from the 3rd US Aviation
Brigade are designated to perform the task.
h.
Define CONTROL-FEATUREs to support the ACTION. Such features may
be air corridors, low-level transit routes, or target areas.
3.23.3 Reporting of Status
Status reporting deals with a wide range of objects, from an individual soldier to a
complete situation report. The entities used to generate such reports encompass most of
the data model. The following is a sample of possible applications:
80
V3.1.4
a.
The OBJECT-ITEM-STATUS entity can be used to record information
about individual OBJECT-ITEMs (e.g., Sgt. T. Hanks is wounded in action;
15 (GE) Panzer Division is fully operational).
b.
The OBJECT-ITEM-HOSTILITY-STATUS entity is used to record the
hostility status of OBJECT-ITEMs (e.g. Assumed friend, Faker, Joker,
Hostile or Unknown).
c.
ACTION-TASK-STATUS may be used to provide updates on the dynamics
of the situation (e.g., minefield laying 70 percent complete, estimated time of
completion + 2 hours).
d.
ACTION-EVENT-STATUS provides a means of reporting unplanned
activity (e.g., flooding started in New Orleans at 1626 on 7 September 2005).
e.
OBJECT-ITEM associations can be used to specify a friendly/enemy order
of battle (in particular, OBJECT-ITEM-ASSOCIATION).
f.
Establishments and HOLDING can be used to indicate surpluses or
deficiencies (e.g., 1 (DA) Mechanised Brigade has a holding of 50 Leopard I
main battle tanks whereas it is established to have 56).
81
V3.1.4
(This page is left blank intentionally)
82
V3.1.4
4.
4.1
OBJECT CLASSES (TYPES OF OBJECTS)
Introduction
4.1.1 Objects, Types, and Their Relationships
4.1.1.1 Objects and their types are modelled as OBJECT-ITEMs and OBJECTTYPEs, respectively. An OBJECT-ITEM represents an individual object of military
significance, e.g., the unit "1 DIV" or a truck with a specific license plate. An OBJECTTYPE represents a class of objects, e.g., an armoured division or a type of vehicle (such as
"Truck").
4.1.1.2 The distinction between OBJECT-TYPEs and OBJECT-ITEMs is
paramount in the model to enable the characteristics of objects to be specified at the
correct level of generality. If a characteristic is about a class, e.g., Leopard-2, it is an
attribute of OBJECT-TYPE; therefore, calibre of main gun, track width, and load class are
characteristics of OBJECT-TYPE as they apply to all instances of Leopard-2. If a
characteristic is unique to a specific instance, it is an attribute of OBJECT-ITEM;
therefore, the identifying number of a specific Leopard-2 is a characteristic of OBJECTITEM. Attributes of OBJECT-TYPEs tend to be more static (i.e., less subject to changes
over time) than attributes of OBJECT-ITEMs, as the former must hold for all objects of a
particular class while the latter information applies to a single object.
4.1.1.3 The structure which is provided in the model to satisfy the requirements
comprises three parts: (1) OBJECT-TYPE and its subtyping hierarchy; (2) OBJECTITEM and its subtyping hierarchy; and (3) the entity OBJECT-ITEM-TYPE. The three
basic entities and their relationships are illustrated in the figure below.
OBJECT-TYPE
OBJECT-ITEM
is-classified-as
P
OBJECT-ITEM-TYPE
Figure 39. Objects, Types, and Their Relationship
4.1.1.4 The link between an object and its class is specified using OBJECT-ITEMTYPE, which is an associative entity used to classify a particular OBJECT-ITEM as being
of a particular OBJECT-TYPE. This allows each instance of OBJECT-ITEM to "inherit"
information that is stored about its corresponding class. The specification of OBJECTITEM-TYPE is presented in Chapter 6.
83
V3.1.4
4.1.2 The Subtyping Tree Structures
4.1.2.1 Subtyping is based on the fact that a characteristic that is applicable to one
(class of) object(s) does not need to be applicable to all (classes of) objects. For example, a
bridge has a military load classification while a unit does not; a person has a gender while
a facility does not. Based on this idea, the subtypings of OBJECT-ITEM and OBJECTTYPE are developed by first identifying the object characteristics relevant to command
and control and then attributing those characteristics at the appropriate level of generality.
The resulting first-level subtyping hierarchies are illustrated in the figure below.
OBJECT-TYPE
OBJECT-ITEM
FACILITY-TYPE
FACILITY
FEATURE-TYPE
FEATURE
MATERIEL-TYPE
MATERIEL
ORGANISATION-TYPE
ORGANISATION
PERSON-TYPE
PERSON
Figure 40. Entity View of First-Level Subtypes of OBJECT-TYPE and OBJECT-ITEM
4.1.2.2 The basic subtyping structures under OBJECT-ITEM and OBJECT-TYPE
are similar. Both incorporate an immediate subtyping of OBJECT-ITEM (-TYPE) into
ORGANISATION(-TYPE), PERSON(-TYPE), MATERIEL(-TYPE), FACILITY(TYPE) and FEATURE(-TYPE); this is nearly a complete subtyping, which implies that
everything of interest can be classified as being one of these five types. An exception is
made for a transient effect to account for tracking an unknown object. However, it is
expected that once enough information is available the unknown object would be reclassified in one of the basic five categories. Some of the subtypes may entail an
additional level of subtyping when one part of an object category (or subtype) has
characteristics that are not shared by another part of the same category.
4.1.2.3 The type and item subtyping structures can also differ since the information
characteristics that are needed on the type side may not apply to the other side, and vice
versa. For example, the subtyping of ORGANISATION-TYPE is different from subtyping
of ORGANISATION; MATERIEL-TYPE is subtyped but MATERIEL is not.
4.1.2.4 The complete subtyping structure for type is presented in this chapter.
Chapter 5 specifies OBJECT-ITEM subtyping structure.
84
V3.1.4
4.2
OBJECT-TYPE Tree Structure
4.2.1 First-Level Structure
4.2.1.1 Many objects are of interest primarily in terms of a class or category rather
than as individually identified items, for example, a tank, a helicopter, a howitzer, a rifle,
an armoured brigade, an infantryman. A considerable amount of information can be
conveyed about an object through its membership in a class. In order to capture this
information, the data model contains the independent entity OBJECT-TYPE and its
subtype hierarchy. The data structure for OBJECT-TYPE and the first level of subtyping
is illustrated in the figure below.
OBJECT-TYPE
object-type-id
object-type-decoy-indicator-code
object-type-name-text
MATERIEL-TYPE
FACILITY-TYPE
facility-type-id (FK)
materiel-type-id (FK)
materiel-type-reportable-item-text
materiel-type-stock-number-text
materiel-type-supply-class-code
materiel-type-issuing-height-dimension
materiel-type-issuing-length-dimension
materiel-type-issuing-width-dimension
FEATURE-TYPE
feature-type-id (FK)
ORGANISATION-TYPE
PERSON-TYPE
organisation-type-id (FK)
person-type-id (FK)
organisation-type-command-function-indicator-code
organisation-type-command-and-control-category-code
organisation-type-description-text
person-type-category-code
person-type-subcategory-code
person-type-rank-code
Figure 41. Specification of First-Level Subtypes of OBJECT-TYPE
4.2.1.2 An OBJECT-TYPE is defined as "An individually identified class of
objects that has military or civilian significance." It is a generalisation of five other object
classes that are treated in the data model as subtypes of OBJECT-TYPE. The attributes
are:
a.
object-type-id—The unique value, or set of characters, assigned to represent
a specific OBJECT-TYPE and to distinguish it from all other OBJECTTYPEs. This does not change over time and therefore there will be a
requirement to generate a unique identifier for each type of object for which
the command and control system needs to retain or specify information.
85
V3.1.4
b.
object-type-category-code—The specific value that represents the class of
OBJECT-TYPE. It serves as a discriminator that partitions OBJECT-TYPE
into subtypes. The domain values are: FACILITY-TYPE; FEATURE-TYPE;
MATERIEL-TYPE; ORGANISATION-TYPE; PERSON-TYPE; Not
known.20 Note: The value "Not known" is intended for initial use in tracking
situations where the object being tracked cannot be definitively classified.
The value is necessary on the type side since the data specification mandates
that the categorisation of an item must match that of the type.
c.
object-type-decoy-indicator-code—The specific value that denotes whether a
specific OBJECT-TYPE represents an object class acting as a decoy. The
domain values are: No; Yes. Note: This attribute is intended to represent a
type of object that has been designed expressly for purposes of acting as a
decoy. Being a "decoy" is its inherent property. The use of real equipment in
faker or other roles has to be handled differently (see associations) since
playing a role of that kind is not an inherent characteristic of the object.
d.
object-type-name-text—The character string assigned to represent a specific
OBJECT-TYPE.
4.2.1.3 An example instance21 table22 for OBJECT-TYPE is given in the table
below.
Table 15. OBJECT-TYPE Example Instances
OBJECT-TYPE
objecttype-id
object-type-categorycode
object-type-decoyindicator-code
object-type-nametext
1234
ORGANISATION-TYPE
No
Tank Regiment
721
391
141
72
41
42
43
57
44
MATERIEL-TYPE
ORGANISATION-TYPE
FEATURE-TYPE
ORGANISATION-TYPE
ORGANISATION-TYPE
ORGANISATION-TYPE
ORGANISATION-TYPE
ORGANISATION-TYPE
ORGANISATION-TYPE
No
No
No
No
Yes
No
No
No
No
Anti-tank missile
Div HQ Bn
Line of contact
Parachute Bn
Fd Artillery Bde
Fd Artillery Rgt
Construction Bn
Armour Division
Transport Company
4.2.2 Overview of the Complete OBJECT-TYPE Tree Structure
4.2.2.1 An overview of the OBJECT-TYPE subtype tree structure is illustrated in
the figure below at the entity level.
Attributes with class word code have a set of domain values associated with them. The
complete lists and their definitions are contained in Annex E.
21
In IDEF1X, occurrences of an entity are termed instances, whereas occurrences of an attribute
are termed values.
22
The columns in an instance table correspond to attributes of the entity whose name is given at
the top left of the table, and the rows are example attribute values for instances of the entity. A
double line is used to separate those columns corresponding to key attributes (on the left) from
non-key attributes (on the right). The values in the instance tables are for illustration only and are
not intended for use in implementation databases.
20
86
V3.1.4
OBJECT-TYPE
FACILITY-TYPE
PERSON-TYPE
AIRFIELD-TYPE
FEATURE-TYPE
MATERIEL-TYPE
BRIDGE-TYPE
HARBOUR-TYPE
ROUTE-TYPE
AMMUNITION-TYPE
ORGANISATION-TYPE
RADIOACTIVE-MATERIEL-TYPE
CIVILIAN-POST-TYPE
EQUIPMENT-TYPE
AIRCRAFT-TYPE
CBRN-EQUIPMENT-TYPE
RAILCAR-TYPE
UNIT-TYPE
WEAPON-TYPE
MILITARY-POST-TYPE
TASK-FORMATION-TYPE
VEHICLE-TYPE
VESSEL-TYPE
SURFACE-VESSEL-TYPE
Figure 42. Entity-Level View of OBJECT-TYPE Subtype Tree
4.2.2.2 Detailed specifications are presented in subsequent sections.
4.2.2.3 A general rule proscribing category code changes is specified in Annex G1,
Section G1.2.1.
87
V3.1.4
4.3
FACILITY-TYPE Tree Structure
FACILITY-TYPE and its subtypes are illustrated in the figure below. The
specification details are provided below.
FACILITY-TYPE
BRIDGE-TYPE
AIRFIELD-TYPE
airfield-type-id (FK)
bridge-type-id (FK)
airfield-type-use-category-code
bridge-type-design-type-code
HARBOUR-TYPE
harbour-type-id (FK)
military-obstacle-type-id (FK)
harbour-type-category-code
military-obstacle-type-category-code
military-obstacle-type-subcategory-code
Figure 43. FACILITY-TYPE and Its Subtypes
4.3.1 Specification of FACILITY-TYPE
4.3.1.1
The entity FACILITY-TYPE is defined as "An OBJECT-TYPE that is
intended to be built, installed or established to serve some particular purpose and is
identified by the service it is intended to provide rather than by its content." The attributes
are:
a.
facility-type-id—The object-type-id of a specific FACILITY-TYPE (a role
name for object-type-id).
b.
facility-type-category-code—The specific value that represents the class of
FACILITY-TYPE. It serves as a discriminator that partitions FACILITYTYPE into subtypes. Example domain values are: AIRFIELD-TYPE;
BRIDGE-TYPE; Cemetery/graveyard/burial ground; Decontamination
facility; Forward arming and refuelling point; Fuel handling point;
HARBOUR-TYPE; Medical facility, hospital field; MILITARYOBSTACLE-TYPE; Observation post; POL point; Rail facilities; Relay
facility; Site, radar; Site, logistic; Transloading facility; Not otherwise
specified.
4.3.1.2
The domain set for facility-type-category-code is extensive, but only
four of the values—AIRFIELD-TYPE, BRIDGE-TYPE, HARBOUR-TYPE and
MILITARY-OBSTACLE-TYPE—have additional data characteristics that must be
expressed in subtypes. The FACILITY-TYPE data specifications are rather sparse since
they are tailored for an operational user of a C2IS system who is primarily interested in a
FACILITY-TYPE with respect to the service it provides rather than its content or detailed
88
V3.1.4
description. This view may be contrasted with the needs of a modelling and simulation
application that must generate an artificial environment.
4.3.1.3 Categorisations
of
FACILITY-TYPE
and
FEATURE-TYPE
(GEOGRAPHIC-FEATURE-TYPE) are derived from Digital Geographic Exchange
Standard (DIGEST) [DIGEST 2001].23 DIGEST is a multinational effort by NATO
nations to reach agreement on standards for geographic products. Volume 4 of DIGEST
(Feature and Attribute Coding Catalog) provides a list of feature types, attributes, and
agreed domain values.
4.3.2 Specification of AIRFIELD-TYPE
The entity AIRFIELD-TYPE is defined as "A FACILITY-TYPE that is a class of
an area prepared for the accommodation (including any buildings, installations, or
equipment) of landing and take off of aircraft." The attributes are:
a.
airfield-type-id—The facility-type-id of a specific AIRFIELD-TYPE (a role
b.
airfield-type-use-category-code—The specific value indicating an airport's
main use. The domain values are: Civil; Joint; Limited; Military.
4.3.3 Specification of BRIDGE-TYPE
The entity BRIDGE-TYPE is defined as "A FACILITY-TYPE that is a class of
structures (including overpasses and viaducts), fixed or moveable, spanning and/or
providing passage over an object." The attributes are:
a.
bridge-type-id—The facility-type-id of a specific BRIDGE-TYPE (a role
b.
bridge-type-design-type-code—The specific value that represents the design
class of BRIDGE-TYPE. Example domain values are: Arch; Box-girder;
Cantilever; Suspension; Truss; Not otherwise specified.
4.3.4 Specification of HARBOUR-TYPE
The entity HARBOUR-TYPE is defined as "A FACILITY-TYPE that is a
restricted body of water, an anchorage, or other limited coastal water area and its water
approaches from which and in which shipping operations are projected or supported." The
attributes are:
23
a.
harbour-type-id—The facility-type-id of a specific HARBOUR-TYPE (a role
b.
harbour-type-category-code—The specific value that represents the class of
HARBOUR-TYPE. Example domain values are: Coastal (Breakwater);
Inland water way; Open roadstead; River (Basins).
Now referred to as AGeoP-3 [Ref. DIGEST 2001]. See also [STANAG 7074 2001].
89
V3.1.4
4.3.5 Specification of MILITARY-OBSTACLE-TYPE
4.3.5.1 The entity MILITARY-OBSTACLE-TYPE is defined as "A FACILITYTYPE that is a class of man-made devices or passive defence works that are designed to
stop, impede, or divert movement of amphibious or ground forces." The attributes are:
a.
military-obstacle-type-id—The facility-type-id of a specific MILITARYOBSTACLE-TYPE (a role name for object-type-id).
b.
military-obstacle-type-category-code—The specific value that represents the
class of MILITARY-OBSTACLE-TYPE. Example domain values are:
Abatis; Anti-tank wall; Dragon teeth; Roadblock; Tetrahedron; Not
otherwise specified.
c.
military-obstacle-type-subcategory-code—The specific value that represents
the detailed class of MILITARY-OBSTACLE-TYPE. The domain values
are: Fixed and prefabricated; Moveable; Moveable and prefabricated.
4.3.5.2 The business rules for relating category and subcategory for MILITARYOBSTACLE-TYPE are specified in Annex G2, Section G2.2.4.
4.3.6 Examples of FACILITY-TYPEs
The table below provides examples for FACILITY-TYPE and its four subtypes.
Sub-table (a) lists thirteen instances of FACILITY-TYPE. The first two refer to instances
of the subtype AIRFIELD-TYPE, the next two to HARBOUR-TYPE and the last six
instances point to the subtypes BRIDGE-TYPE and MILITARY-OBSTACLE-TYPE. The
data for the subtypes is shown in Sub-tables (b), (c), (d), and (e).
Table 16. Example Instances for FACILITY-TYPE and Subtypes
(a) FACILITY-TYPE
facility-type-id
6311
6301
6304
AIRFIELD-TYPE
AIRFIELD-TYPE
HARBOUR-TYPE
6305
6312
6313
6314
6315
6316
6317
6420
6421
6422
HARBOUR-TYPE
Depot, not otherwise specified
Maintenance facility
Supply dump
BRIDGE-TYPE
BRIDGE-TYPE
BRIDGE-TYPE
(b) AIRFIELD-TYPE
airfield-type-id
airfield-type-use-category-code
6311
6301
Civil
Joint
90
V3.1.4
(c) BRIDGE-TYPE
bridge-type-id
bridge-type-design-type-code
6315
6316
6317
Box-girder
Suspension
Truss
(d) HARBOUR-TYPE
harbour-type-id
harbour-type-category-code
6304
6305
Inland water way
River (Basins)
(e) MILITARY-OBSTACLE-TYPE
4.4
military-obstacletype-id
military-obstacle-type-categorycode
military-obstacle-typesubcategory-code
6420
6421
6422
Dragon teeth
Roadblock
Tetrahedron
—
FEATURE-TYPE Tree Structure
4.4.1 The Concept of FEATURE-TYPE
The concept of FEATURE-TYPE is used to describe a class of elements that can
be either natural features that may influence operations or artificial features representing
administrative, political, or tactical constraints to be taken into account. An individual
feature can be a real-world occurrence of a structure, a phenomenon, or some other entity
which is described by a set of characteristics and which is associated with a specific
geographic location. Since the concept of FEATURE-TYPE embraces a wide range of
elements, it is further subdivided into two categories.
4.4.2 Specification of FEATURE-TYPE
4.4.2.1 The structure of FEATURE-TYPE is illustrated in the figure below.
4.4.2.2 The entity FEATURE-TYPE is defined as "An OBJECT-TYPE that
encompasses meteorological, geographic, and control features of military significance."
The attributes are:
a.
feature-type-id—The object-type-id of a specific FEATURE-TYPE (a role
b.
feature-type-category-code—The specific value that represents the class of
FEATURE-TYPE. It serves as a discriminator that partitions FEATURETYPE into subtypes. The domain values are: CONTROL-FEATURE-TYPE;
GEOGRAPHIC-FEATURE-TYPE; Meteorologic feature type; Not
91
V3.1.4
FEATURE-TYPE
feature-type-id (FK)
control-feature-type-id (FK)
control-feature-type-echelon-code
geographic-feature-type-id (FK)
geographic-feature-type-category-code
geographic-feature-type-subcategory-code
ROUTE-TYPE
route-type-id (FK)
route-type-category-code
Figure 44. FEATURE-TYPE and Its Subtypes
4.4.2.3 The table below provides examples of FEATURE-TYPE.
Table 17. Example Instances for FEATURE-TYPE
OBJECT-TYPE
FEATURE-TYPE
object-type-id
feature-type-id
4321
Major freshwater river
4321
4322
4323
4324
4311
4312
4313
4314
7622
7623
7624
7625
Marsh/swamp
Ridge line
Dense forest
Phase line-Alpha
Air-defence corridor-Bravo
Objective area-Charlie
Area of responsibility-Delta
Air traffic services route-Echo
Minimum risk route-Foxtrot
Supersonic route-Golf
Transit route-India
4322
4323
4324
4311
4312
4313
4314
7622
7623
7624
7625
4.4.3 Specification of CONTROL-FEATURE-TYPE
4.4.3.1 CONTROL-FEATURE-TYPE is used to represent abstract objects created
or assigned by military authorities for the purposes of planning and coordination,
especially in operational areas. It is a non-permanent point (e.g., start point for a road
move, or a reserved demolition), line (e.g., a Main supply route or No fire line), area (e.g.,
a Slow-go area), or volume (e.g., an air corridor) that may be overlaid on a map. A control
feature would normally be drawn on a map overlay, traced, or superimposed onto digitised
map data and assigned a descriptive title, symbol, or name (e.g., Line of departure, Corps
boundary).
92
V3.1.4
4.4.3.2 A CONTROL-FEATURE-TYPE is defined as "A non-tangible FEATURETYPE of military interest that may be represented as a geometric figure and is associated
with the conduct of military operations." The attributes are:
a.
control-feature-type-id—The feature-type-id of a specific CONTROLFEATURE-TYPE (a role name for object-type-id).
b.
control-feature-type-category-code—The specific value that represents the
class of CONTROL-FEATURE-TYPE. It serves as a discriminator that
partitions CONTROL-FEATURE-TYPE into subtypes. Example domain
values are: Airspace coordination area; Area of interest; Area of
responsibility; Artillery area; Crossing site; Decision point; Drop zone; Fire
support coordination line; Forward line of troops; Landing zone; ROUTETYPE; Strong point; Supply area.
c.
control-feature-type-echelon-code—The specific value that represents the
echelon level of an organisation that is to be associated with a specific
CONTROL-FEATURE-TYPE. Example domain values are: Army; Army
group; Battalion; Battalion group; Brigade; Company; Company group;
Corps; Division; Platoon; Section; Squad; Team/fire team/crew
4.4.3.3 Annex G1, Section G1.2.2 specifies rules when the value of controlfeature-type-category-code is "Battle position."
4.4.3.4 Examples of CONTROL-FEATURE-TYPEs are presented in the table
below.
Table 18. Examples of CONTROL-FEATURE-TYPE
control-feature-type-id
control-feature-type-echelon-code
4311
4312
4313
4314
7622
Phase line
Air-defence corridor
Objective area
Area of responsibility
ROUTE-TYPE
Company
—
Battalion
Division
—
7623
7624
7625
ROUTE-TYPE
ROUTE-TYPE
ROUTE-TYPE
—
—
—
4.4.4 Specification of ROUTE-TYPE
4.4.4.1
A ROUTE-TYPE is defined as "A CONTROL-FEATURE-TYPE that
is the prescribed course to be travelled from a point of origin to a destination." The
attributes are:
a.
route-type-id—The control-feature-type-id of a specific ROUTE-TYPE (a
role name for object-type-id).
b.
route-type-category-code—The specific value that represents the class of
ROUTE-TYPE. Example domain values are: Area navigation route; Main
supply route; Polar route; TACAN route; Unmanned aerial vehicle route.
93
V3.1.4
4.4.4.2 The table below provides examples of ROUTE-TYPE and amplifies the
data of the previous table.
Table 19. Examples of ROUTE-TYPE
ROUTE-TYPE
route-type-id
route-type-category-code
7622
7623
7624
Air traffic services route
Minimum risk route
Supersonic route
7625
Transit route
4.4.5 Specification of GEOGRAPHIC-FEATURE-TYPE
4.4.5.1 A geographic feature is intended to describe permanent or durable natural
features. A GEOGRAPHIC-FEATURE-TYPE is defined as "A FEATURE-TYPE that
describes terrain characteristics to which military significance is attached." The attributes
are:
a.
geographic-feature-type-id—The
feature-type-id
of
a
specific
GEOGRAPHIC-FEATURE-TYPE (a role name for object-type-id).
b.
geographic-feature-type-category-code—The specific value that represents
the class of GEOGRAPHIC-FEATURE-TYPE.24 Example domain values
are: Coastal hydrography; Landform; Wetland; Not otherwise specified.
c.
geographic-feature-type-subcategory-code—The
specific
value
that
represents the detailed class of GEOGRAPHIC-FEATURE-TYPE. Example
domain values are: Beach; Bluff/cliff/escarpment; Depression; Gully/gorge;
Hill; Island; Lake/pond; Marsh; Mountain; River/stream; Rock strata/rock
formation; Sand dune/sand hill; Valley; Water (except inland).
4.4.5.2 The business rules for relating category and subcategory
GEOGRAPHIC-FEATURE-TYPE are specified in Annex G2, Section G2.2.5.
for
4.4.5.3 The table below provides example instances for GEOGRAPHICFEATURE-TYPE.
Table 20. Examples of GEOGRAPHIC-FEATURE-TYPE
geographic-featuretype-id
geographic-feature-typecategory-code
geographic-feature-typesubcategory-code
4321
4322
4323
4324
Inland water
Inland water
Landform
Wetland
River/stream
Lake/pond
Mountain
Marsh
The Feature and Attribute Coding Catalog (FACC), Volume 4 of the DIGEST standard,
provides a specification of GEOGRAPHIC-FEATURE-TYPEs [Ref. FACC 1994]. Supplemental
information is drawn from STANAG 7074: Digital Information Exchange Standards (DIGEST), NATO
24
UNCLASSIFIED, Edition 2.1, September 2001 [Ref. STANAG 7074].
94
V3.1.4
4.5
MATERIEL-TYPE Tree Structure
The MATERIEL-TYPE subtyping hierarchy is extensive. It is presented in three
sets of specifications: MATERIEL-TYPE entity itself, EQUIPMENT-TYPE hierarchy,
and CONSUMABLE-MATERIEL-TYPE hierarchy.
4.5.1 Specification of MATERIEL-TYPE
4.5.1.1 MATERIEL-TYPE is defined as "An OBJECT-TYPE that represents
equipment, apparatus or supplies of military interest without distinction to its application
for administrative or combat purposes." The attributes are:
a.
materiel-type-id—The object-type-id of a specific MATERIEL-TYPE (a role
b.
materiel-type-category-code—The specific value that represents the class of
MATERIEL-TYPE. It serves as a discriminator that partitions MATERIELTYPE into subtypes. The domain values are: CONSUMABLE-MATERIELTYPE; EQUIPMENT-TYPE; Not otherwise specified.
c.
materiel-type-reportable-item-text—The character string assigned to
represent a specific MATERIEL-TYPE, selected from the Reportable Item
Code list issued by NATO.
d.
materiel-type-stock-number-text—The character string assigned to represent
a specific MATERIEL-TYPE. This attribute is intended for the NATO Stock
Number, which is a 13-digit number of which four digits designate a class,
two digits designate a nation, and seven digits designate a national code
number.
e.
materiel-type-supply-class-code—The specific value that represents the
NATO supply class of MATERIEL-TYPE. The domain values are: Class I;
Class II; Class III; Class IIIa; Class IV; Class V.
f.
materiel-type-issuing-height-dimension—The
one-dimensional
linear
distance representing the maximum distance measured perpendicular to the
base plane of the specific MATERIEL-TYPE when it is prepared for
shipment or storage.
g.
materiel-type-issuing-length-dimension—The
one-dimensional
linear
distance representing the maximum distance measured from end to end and
parallel to the central axis of specific MATERIEL-TYPE when it is prepared
for shipment or storage.
h.
materiel-type-issuing-width-dimension—The
one-dimensional
linear
distance representing the maximum distance measured from side to side and
perpendicular to the central axis of a specific MATERIEL-TYPE when it is
prepared for shipment or storage.
4.5.1.2 Examples of MATERIEL-TYPE are provided in the table below. The
examples include instances that are considered to be durable and not intended for
consumption (EQUIPMENT-TYPE) as well as those that are meant to be used up in the
normal conduct of operations other than through attrition (CONSUMABLE-MATERIELTYPE).
95
V3.1.4
Table 21. Examples of MATERIEL-TYPE25
OBJECT-TYPE
MATERIEL-TYPE
object-type-id
materiel-type-id
68763
9576
49662
179
813
Challenger MBT
Scorpion Light Tank/Reconnaissance Vehicle
Abrams MBT
LARS, Multiple Rocket Launcher
Attack Helicopter, AH-64
68763
9576
49662
179
813
EQUIPMENT-TYPE
EQUIPMENT-TYPE
EQUIPMENT-TYPE
EQUIPMENT-TYPE
EQUIPMENT-TYPE
86978
8440
574
11
25472
SA 80 Assault Rifle
L1A1 120-mm tank gun
UK Armoured Regiment Standard Ammo Pack
Warrior Armoured Fighting Vehicle
86978
8440
574
11
25472
EQUIPMENT-TYPE
EQUIPMENT-TYPE
EQUIPMENT-TYPE
1869
L1A2 120-mm HESH27
1869
6687
1870
1871
Bradley AFV
Diesel Fuel 200-litre Drum
Bulk Diesel Fuel, 5,000-litre Tank
6687
1870
1871
EQUIPMENT-TYPE
L1A2 120-mm APFSDS26
4.5.2 EQUIPMENT-TYPE Tree Structure
Hierarchies for classifying equipment types can be created in multiple ways. The
hierarchy selected here reflects most closely the operational requirements that underlie the
entire data specification. What is presented in this section may be considered to be a
specific data view that need not necessarily be the user view. The data specifications for
EQUIPMENT-TYPE can be combined with CAPABILITY data to create different
hierarchies to reflect the views that the user considers most appropriate. The structure of
EQUIPMENT-TYPE and its subtypes is illustrated in the figure below. It should be noted
that the subtyping is complete due to the presence of a category for specifying
miscellaneous equipment.
The dashed line at the right side of an instance table indicates that columns for one or more
(non-key) attributes have been omitted.
26
APFSDS—Armour-Piercing Fin-Stabilised Discarding Sabot (a type of tank gun ammunition).
27
HESH—High Explosive Squash Head (a type of tank gun ammunition).
25
96
V3.1.4
EQUIPMENT-TYPE
AIRCRAFT-TYPE
equipment-type-id (FK)
aircraft-type-id (FK)
equipment-type-loaded-weight-quantity
equipment-type-unloaded-weight-quantity
equipment-type-maximum-height-dimension
equipment-type-maximum-length-dimension
equipment-type-maximum-width-dimension
equipment-type-fuel-capacity-quantity
aircraft-type-category-code
aircraft-type-airframe-design-code
aircraft-type-model-code
aircraft-type-manning-code
aircraft-type-military-civilian-code
aircraft-type-main-purpose-code
aircraft-type-design-role-code
aircraft-type-design-range-code
aircraft-type-weather-qualifier-code
aircraft-type-training-category-code
aircraft-type-load-category-code
aircraft-type-takeoff-and-landing-code
aircraft-type-wing-span-dimension
electronic-equipment-type-id (FK)
electronic-equipment-type-category-code
electronic-equipment-type-subcategory-code
RAILCAR-TYPE
railcar-type-id (FK)
railcar-type-category-code
railcar-type-subcategory-code
railcar-type-gauge-dimension
engineering-equipment-type-id (FK)
engineering-equipment-type-category-code
WEAPON-TYPE
weapon-type-id (FK)
weapon-type-category-code
weapon-type-subcategory-code
weapon-type-calibre-text
weapon-type-fire-guidance-indicator-code
maritime-equipment-type-id (FK)
maritime-equipment-type-category-code
maritime-equipment-type-subcategory-code
miscellaneous-equipment-type-id (FK)
CBRN-EQUIPMENT-TYPE
miscellaneous-equipment-type-category-code
miscellaneous-equipment-type-subcategory-code
cbrn-equipment-type-id (FK)
cbrn-equipment-type-category-code
VEHICLE-TYPE
vehicle-type-id (FK)
VESSEL-TYPE
vehicle-type-category-code
vessel-type-id (FK)
vessel-type-magnetic-degaussing-code-number-quantity
vessel-type-prismatic-coefficient-ratio
vessel-type-dead-weight-quantity
vessel-type-draught-dimension
vessel-type-gross-registered-tonnage-quantity
vessel-type-height-above-the-waterline-dimension
vessel-type-propeller-count
vessel-type-propulsion-type-code
vessel-type-operational-displacement-quantity
vessel-type-maximum-speed-rate
vessel-type-acoustic-merit-index-quantity
SURFACE-VESSEL-TYPE
subsurface-vessel-type-id (FK)
surface-vessel-type-id (FK)
subsurface-vessel-type-category-code
subsurface-vessel-type-dived-displacement-quantity
subsurface-vessel-type-speed-cavitation-quantity
subsurface-vessel-type-torpedo-loading-gear-indicator-code
surface-vessel-type-category-code
surface-vessel-type-displacement-quantity
surface-vessel-type-maximum-deck-load-quantity
Figure 45. EQUIPMENT-TYPE and Its Subtypes
97
V3.1.4
4.5.2.1
Specification of EQUIPMENT-TYPE
4.5.2.1.1 An EQUIPMENT-TYPE is defined as "A MATERIEL-TYPE that is
not intended for consumption." Expressed in another way, EQUIPMENT-TYPE is a class
of durable goods. The attributes are:
a.
equipment-type-id—The materiel-type-id of a specific EQUIPMENT-TYPE
(a role name for object-type-id).
b.
equipment-type-category-code—The specific value that represents the class
of EQUIPMENT-TYPE. It serves as a discriminator that partitions
EQUIPMENT-TYPE into subtypes. The domain values are: AIRCRAFTTYPE; CBRN-EQUIPMENT-TYPE; ELECTRONIC-EQUIPMENT-TYPE;
ENGINEERING-EQUIPMENT-TYPE; MARITIME-EQUIPMENT-TYPE;
MISCELLANEOUS-EQUIPMENT-TYPE; RAILCAR-TYPE; VEHICLETYPE; VESSEL-TYPE; WEAPON-TYPE.
c.
equipment-type-loaded-weight-quantity—The numeric value that represents
the weight of a specific EQUIPMENT-TYPE including the normal
maximum payload, crew, and personal/organisation equipment as well as the
basic issue items. The unit of measure is kilogram.
d.
equipment-type-unloaded-weight-quantity—The
numeric
value
that
represents the weight of a specific EQUIPMENT-TYPE including onequipment materiel that is an integral part of the equipment when issued. The
unit of measure is kilogram.
e.
equipment-type-maximum-height-dimension—The one-dimensional linear
distance representing the maximum distance measured perpendicular to the
base plane of the specific EQUIPMENT-TYPE.
f.
equipment-type-maximum-length-dimension—The one-dimensional linear
distance representing the maximum distance measured from end to end and
parallel to the central axis of a specific EQUIPMENT-TYPE.
g.
equipment-type-maximum-width-dimension—The one-dimensional linear
distance representing the maximum distance measured from side to side and
perpendicular to the central axis of a specific EQUIPMENT-TYPE.
h.
equipment-type-fuel-capacity-quantity—The numeric value that represents
the usable fuel capacity of an EQUIPMENT-TYPE. The unit of measure is
litre.
4.5.2.1.2 Example instances for EQUIPMENT-TYPE are provided in the table
below. Further examples of the many subtypes of EQUIPMENT-TYPE are presented in
the sections below together with the specifications of each subtype.
98
V3.1.4
Table 22. Examples of EQUIPMENT-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
object-typename-text
materiel
-type-id
materiel-typecategory-code
materiel-typeissuing-heightdimension
materiel-typeissuing-lengthdimension
materiel-typeissuing-widthdimension
301101
Tractor Whl Ind
Ded—830M
Truck Tank
Water
301101
EQUIPMENT-TYPE
—
—
—
301102
EQUIPMENT-TYPE
—
—
—
301102
(b) EQUIPMENT-TYPE
*-categorycode
*-loadedweight-quantity
*-unloadedweight-quantity
*-maxheight-dim
*-maxlength-dim
*-maxwidth-dim
*-fuelcapacity-qty
301101
VEHICLETYPE
—
301102
VEHICLETYPE
8,636
[kilogram]
25,045
[kilogram]
3,932
[kilogram]
3.780
[metre]
2.294
[metre]
7.620
[metre]
6.629
[metre]
3.454
[metre]
2.703
[metre]
400
[litre]
200
[litre]
*-id
Note: * = "equipment-type"
4.5.2.2
Specification of AIRCRAFT-TYPE
4.5.2.2.1 AIRCRAFT-TYPE is defined as "An EQUIPMENT-TYPE that is
designed to fly." The attributes are:
a.
aircraft-type-id—The equipment-type-id of a specific AIRCRAFT-TYPE (a
b.
aircraft-type-category-code—The specific value that represents the class of
AIRCRAFT-TYPE. The domain values are: Fixed wing; Lighter than air;
Rotary wing; Space vehicle; Not known; Not otherwise specified.
c.
aircraft-type-airframe-design-code—The specific value that represents the
design of the airframe of an AIRCRAFT-TYPE. Example domain values are:
Balloon; Bomber; Fighter; Helicopter; Not known.
d.
aircraft-type-model-code—The specific value that represents the specific
design of an AIRCRAFT-TYPE. Example domain values are: 1049 Super
Constellation; A-4A Skyhawk; AH-1 Huey Cobra; Mig-21U Mongol A; TA4 Skyhawk; YAK 130 / AEM/YAK 130; Not otherwise specified.
e.
aircraft-type-manning-code—The specific value that represents whether an
aircraft is designed to be manned or unmanned. The domain values are:
Manned; Unmanned; Unmanned remotely piloted; Unmanned not remotely
piloted; Not known.
f.
aircraft-type-military-civilian-code—The specific value that represents
whether an aircraft is primarily intended for military or civilian use. The
domain values are: Civilian; Military; Not known.
g.
aircraft-type-main-purpose-code—The specific value that represents the
main purpose of an AIRCRAFT-TYPE. Example domain values are:
Airborne early warning; Anti-submarine warfare (MPA); Electronic counter
measures; Reconnaissance, photographic; Tanker.
h.
aircraft-type-design-role-code—The specific value that represents the
designed role of an AIRCRAFT-TYPE. The domain values are: Defensive;
Multi role; Offensive; Support; Not known; Not otherwise specified.
99
V3.1.4
i.
aircraft-type-design-range-code—The specific value that represents the
designed range of an AIRCRAFT-TYPE. The domain values are: Long;
Medium; Short; Not known.
j.
aircraft-type-weather-qualifier-code—The specific value that represents the
weather conditions in which an AIRCRAFT-TYPE can perform its mission.
The domain values are: All weather; Clear; Not known.
k.
aircraft-type-training-category-code—The specific value that denotes
whether an aircraft can be used for training purposes. The domain values are:
No; Yes; Not known.
l.
aircraft-type-load-category-code—The specific value that represents a
loading capability of an AIRCRAFT-TYPE. The domain values are: Heavy;
Light; Medium; Not known; Not otherwise specified.
m.
aircraft-type-takeoff-and-landing-code—The specific value that represents
the takeoff and landing designation of an AIRCRAFT-TYPE. The domain
values are: Short takeoff/landing; Vertical short takeoff/landing; Vertical
takeoff/landing; Not known; Not otherwise specified.
n.
aircraft-type-wing-span-dimension—The one-dimensional linear distance
representing the spread of the wings of a specific AIRCRAFT-TYPE
measured from end to end.
4.5.2.2.2 Permissible combinations of domain values for aircraft-type-categorycode and aircraft-type-airframe-design-code are specified in Annex G2, Section G2.2.1.1.
4.5.2.2.3 A usage rule for the domain value "Not otherwise specified" in the
aircraft-type-category-code domain is specified in Annex G1, Section G1.2.3.
4.5.2.2.4 Examples of AIRCRAFT-TYPE are provided in the table below.
Table 23. Instances of AIRCRAFT-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
materiel-typereportable-item-text
materiel-typesupply-class-code
501101
AH-64C APACHE
501101
EQUIPMENT-TYPE
HB1ZBB
Class II
501102
501103
BOEING 747-400
F-15B EAGLE
501102
501103
EQUIPMENT-TYPE
EQUIPMENT-TYPE
—
HA13GB
Class II
Class II
(b) EQUIPMENT-TYPE
***-id
***-category-code
*-loaded-weightquantity
*-unloaded-weightquantity
501101
501102
501103
AIRCRAFT-TYPE
AIRCRAFT-TYPE
AIRCRAFT-TYPE
—
—
—
—
—
—
(c) AIRCRAFT-TYPE
**-id
**-category-code
**-airframedesign-code
**-modelcode
**-manningcode
**-militarycivilian-code
**-mainpurpose-code
501101
501102
Rotary wing
Fixed wing
Helicopter
Transport
AH64C
B74740
Manned
Manned
Military
Military
Attack
Cargo airlift
501103
Fixed wing
Fighter
F15B
Manned
Military
Attack/strike
Note: ** = "aircraft-type"
100
V3.1.4
**-designrole-code
**-designrange-code
**-weatherqualifiercode
**-trainingcategorycode
**-loadcategorycode
Offensive
Short
—
—
Light
Support
Offensive
Long
Medium
All weather
—
—
Not known
Heavy
Medium
**-takeoff-andlanding-code
Vertical
takeoff/landing
—
—
**-wingspandimension
—
—
—
4.5.2.3
Specification of CBRN-EQUIPMENT-TYPE
4.5.2.3.1 CBRN-EQUIPMENT-TYPE is defined as "An EQUIPMENT-TYPE
that is designed for specialised roles in detecting, decontaminating or reconnoitring CBRN
agents." The attributes are:
a.
cbrn-equipment-type-id—The equipment-type-id of a specific CBRNEQUIPMENT-TYPE (a role name for object-type-id).
b.
cbrn-equipment-type-category-code—The specific value that represents the
class of CBRN-EQUIPMENT-TYPE. Example domain values are:
Automated biological detector; Automated radiation detector; Mass
spectrometer; CBRN reconnaissance vehicle; Radiation spectrometer.
4.5.2.3.2 Examples of CBRN-EQUIPMENT-TYPE are provided in the table
below.
Table 24. Instances of CBRN-EQUIPMENT-TYPE
(a) MATERIEL-TYPE
objecttype-id
materieltype-id
materiel-type-supplyclass-code
1501101
NBC suit, large
1501101
NB31CA
Class IV
1501102
CBRN Decon
vehicle, Magirus 7t
Dosimeter
individual, handheld
1501102
EQUIPMENTTYPE
EQUIPMENTTYPE
EQUIPMENTTYPE
NCZZZZ
Class IV
ND2ZZZ
Class IV
1501103
1501103
(b) EQUIPMENT-TYPE
*-id
*-category-code
1501101
1501102
1501103
CBRN-EQUIPMENT-TYPE
CBRN-EQUIPMENT-TYPE
CBRN-EQUIPMENT-TYPE
—
7,000
—
—
—
—
(c) CBRN-EQUIPMENT-TYPE
**-id
**-category-code
1501101
1501102
CBRN decontamination vehicle
1501103
Radiation spectrometer
Note: ** = "cbrn-equipment-type"
4.5.2.4
Specification of ELECTRONIC-EQUIPMENT-TYPE
4.5.2.4.1 ELECTRONIC-EQUIPMENT-TYPE is defined as "An EQUIPMENTTYPE that is designed to use electronic processing to realise its primary function." The
attributes are:
101
V3.1.4
a.
electronic-equipment-type-id—The equipment-type-id of a specific
ELECTRONIC-EQUIPMENT-TYPE (a role name for object-type-id).
b.
electronic-equipment-type-category-code—The specific value that represents
the class of ELECTRONIC-EQUIPMENT-TYPE. Example domain values
are: Communication; Electronic warfare; Fire control; Navigation; Sensor.
c.
electronic-equipment-type-subcategory-code—The specific value that
represents the detailed class of ELECTRONIC-EQUIPMENT-TYPE.
Example domain values are: Beacon; Communication system; Identification
friend/foe; Meteorological radar; Radar, air-traffic control; Video broadcast
device.
4.5.2.4.2 Permissible combinations of domain values for electronic-equipmenttype-category-code and electronic-equipment-type-subcategory-code are specified in
Annex G2, Section G2.2.1.2.
4.5.2.4.3 Examples of ELECTRONIC-EQUIPMENT-TYPE are provided in the
table below.
Table 25. Instances of ELECTRONIC-EQUIPMENT-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
materieltype-id
objecttype-id
601101
WEASEL
601101
EQUIPMENT-TYPE
RB11BZ
Class II
601102
601103
COBRA
AN-VRC-261
601102
601103
EQUIPMENT-TYPE
EQUIPMENT-TYPE
RA12BZ
—
Class II
Class II
(b) EQUIPMENT-TYPE
*-id
*-category-code
601101
ELECTRONICEQUIPMENT-TYPE
601102
601103
—
—
—
—
—
—
(c) ELECTRONIC-EQUIPMENT-TYPE
**-id
**-category-code
**-subcategory-code
601101
601102
601103
Fire control
Navigation
Communication
Counter-artillery radar
Beacon
Radio broadcast device
Note: ** = "electronic-equipment-type"
4.5.2.5
Specification of ENGINEERING-EQUIPMENT-TYPE
4.5.2.5.1 ENGINEERING-EQUIPMENT-TYPE
is
defined
as
"An
EQUIPMENT-TYPE that is designed to accomplish engineering functions." The attributes
are:
a.
engineering-equipment-type-id—The equipment-type-id of a specific
ENGINEERING-EQUIPMENT-TYPE (a role name for object-type-id).
102
V3.1.4
b.
engineering-equipment-type-category-code—The specific value that
represents the class of ENGINEERING-EQUIPMENT-TYPE. Example
domain values are: Bridge vehicle; Earthmover; Mine clearer; Minefield
marking; Tactical floating bridge.
4.5.2.5.2 Examples of ENGINEERING-EQUIPMENT-TYPE are provided in the
table below.
Table 26. Instances of ENGINEERING-EQUIPMENT-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
701101
CATERPILLAR
701101
LE24ZZ
Class IV
701102
LEOPARD 1A 5,
BRIDGE
APC M113,
MINE LAYER
701102
EQUIPMENTTYPE
EQUIPMENTTYPE
EQUIPMENTTYPE
LE41ZZ
Class II
LE31BZ
Class II
701103
701103
(b) EQUIPMENT-TYPE
*-id
*-category-code
701101
ENGINEERINGEQUIPMENT-TYPE
701102
701103
—
—
—
—
—
—
(c) ENGINEERING-EQUIPMENT-TYPE
**-id
**-category-code
701101
Dozer
701102
701103
Mechanised bridge layer
Mine layer, armoured vehicle mounted
Note: ** = "engineering-equipment-type"
4.5.2.6
Specification of MARITIME-EQUIPMENT-TYPE
4.5.2.6.1 MARITIME-EQUIPMENT-TYPE is defined as "An EQUIPMENTTYPE that is designed to be used in a maritime environment." The attributes are:
a.
maritime-equipment-type-id—The equipment-type-id of a specific
MARITIME-EQUIPMENT-TYPE (a role name for object-type-id).
b.
maritime-equipment-type-category-code—The specific value that represents
the class of MARITIME-EQUIPMENT-TYPE. Example domain values are:
Anchor; Depth-charge launcher; Maritime mine disposal vehicle; Radar
reflector.
c.
maritime-equipment-type-subcategory-code—The specific value that
represents the detailed class of MARITIME-EQUIPMENT-TYPE. Example
domain values are: Buoy, beacon dan; Cutter, explosive; Sonar, depressed
angle towed array; Sweep, mechanical snagline.
103
V3.1.4
4.5.2.6.2 Permissible combinations of domain values for maritime-equipmenttype-category-code and maritime-equipment-type-subcategory-code are specified in
Annex G2, Section G2.2.1.3.
4.5.2.6.3 Examples of MARITIME-EQUIPMENT-TYPE are provided in the
table below.
Table 27. Instances of MARITIME-EQUIPMENT-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
991101
991102
991103
Marker buoy
Sonar
Sweep
991101
991102
991103
EQUIPMENT-TYPE
EQUIPMENT-TYPE
EQUIPMENT-TYPE
—
—
—
Class II
Class II
Class II
(b) EQUIPMENT-TYPE
*-id
*-category-code
991101
MARITIMEEQUIPMENT-TYPE
991102
991103
—
—
—
—
—
—
(c) MARITIME-EQUIPMENT-TYPE
**-id
**-category-code
**-subcategory-code
991101
991102
Buoy
Sonar, maritime
991103
Sweep
Buoy, beacon dan
Sonar, depressed angle
towed array
Sweep, mechanical
snagline
Note: ** = "maritime-equipment-type"
4.5.2.7
Specification of MISCELLANEOUS-EQUIPMENT-TYPE
4.5.2.7.1 MISCELLANEOUS-EQUIPMENT-TYPE is defined as "An
EQUIPMENT-TYPE whose designed function does not fit in any other defined category."
The attributes are:
a.
miscellaneous-equipment-type-id—The equipment-type-id of a specific
MISCELLANEOUS-EQUIPMENT-TYPE (a role name for object-type-id).
b.
miscellaneous-equipment-type-category-code—The specific value that
represents the class of MISCELLANEOUS-EQUIPMENT-TYPE. Example
domain values are: Beacon, light; Printing machine; Searchlight; Smoke
generator; Tank.
c.
miscellaneous-equipment-type-subcategory-code—The specific value that
represents the detailed class of MISCELLANEOUS-EQUIPMENT-TYPE.
Example domain values are: Boom; Boom and centreline drogue; Centreline
drogue; Wingtip drogue.
104
V3.1.4
4.5.2.7.2 Permissible combinations of domain values for miscellaneousequipment-type-category-code and miscellaneous-equipment-type-subcategory-code are
specified in Annex G2, Section G2.2.1.4.
4.5.2.7.3 Examples of MISCELLANEOUS-EQUIPMENT-TYPE are provided in
the table below.
Table 28. Instances of MISCELLANEOUS-EQUIPMENT-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
1401101
1401101
EQUIPMENT-TYPE
—
—
1401102
Light house, Lands
End, (UK)
Container, 30 feet
1401102
EQUIPMENT-TYPE
—
—
1401103
1401104
1401105
HP Laser Jet 4L
Air refuelling
Air refuelling
1401103
1401104
1401105
EQUIPMENT-TYPE
EQUIPMENT-TYPE
EQUIPMENT-TYPE
—
—
—
Class IV
—
—
(b) EQUIPMENT-TYPE
*-id
*-category-code
1401101
MISCELLANEOUSEQUIPMENT-TYPE
1401102
1401103
1401104
1401105
—
—
20,000
3,000
—
—
—
—
—
—
Note: *** = "equipment-type"
(c) MISCELLANEOUS-EQUIPMENT-TYPE
**-id
**-category-code
**-subcategory-code
1401101
1401102
1401103
Beacon, light
Container
Printing machine
—
—
—
1401104
1401105
Aircraft refuelling
Aircraft refuelling
Boom and centreline drogue
Wingtip drogue
Note: ** = "miscellaneous-equipment-type"
4.5.2.8
Specification of RAILCAR-TYPE
4.5.2.8.1 RAILCAR-TYPE is defined as "An EQUIPMENT-TYPE that is
designed to operate on rail tracks." The attributes are:
a.
railcar-type-id—The equipment-type-id of a specific RAILCAR-TYPE (a
b.
railcar-type-category-code—The specific value that represents the class of
RAILCAR-TYPE. Example domain values are: Locomotive; Railed
equipment; Rolling stock; Tram.
c.
railcar-type-subcategory-code—The specific value that represents the
detailed class of RAILCAR-TYPE. Example domain values are:
105
V3.1.4
Locomotive, diesel; Wagon, articulated vehicle transporter; Wagon, car
transporter; Wagon, flatbed; Wagon, passenger; Wagon, refrigerated.
d.
railcar-type-gauge-dimension—The one-dimensional linear distance
representing the horizontal distance measured from side to side and
perpendicular to the central axis of a specific railcar track.
4.5.2.8.2 Permissible combinations of domain values for railcar-type-categorycode and railcar-type-subcategory-code are specified in Annex G2, Section G2.2.1.5.
4.5.2.8.3 Examples of RAILCAR-TYPE are provided in the table below.
Table 29. Instances of RAILCAR-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materiel
-type-id
901101
Locomotive,
diesel/electric, MY
Wagon, cattle, RYAN
(EI)
Wagon, passenger,
VIRGIN
901101
EQUIPMENT-TYPE
—
Class IV
901102
EQUIPMENT-TYPE
—
Class IV
901103
EQUIPMENT-TYPE
—
Class IV
901102
901103
(b) EQUIPMENT-TYPE
*-id
*-category-code
901101
901102
901103
RAILCAR-TYPE
RAILCAR-TYPE
RAILCAR-TYPE
—
—
—
—
—
—
(c) RAILCAR-TYPE
**-id
**-category-code
**-subcategory-code
**-gauge-dimension
901101
901102
901103
Locomotive
Rolling stock
Rolling stock
Locomotive, diesel/electric
Wagon, cattle
Wagon, passenger
—
—
—
Note: ** = "railcar-type"
4.5.2.9
Specification of VEHICLE-TYPE
4.5.2.9.1 VEHICLE-TYPE is defined as "An EQUIPMENT-TYPE that is
designed to operate on land routes (other than rail) with a primary role of transporting
personnel, equipment or supplies." The attributes are:
a.
vehicle-type-id—The equipment-type-id of a specific VEHICLE-TYPE (a
b.
vehicle-type-category-code—The specific value that represents the class of
VEHICLE-TYPE. Example domain values are: Armoured personnel carrier;
Automobile; Bicycle; Maintenance; Truck.
4.5.2.9.2 Examples of VEHICLE-TYPE are provided in the table below.
106
V3.1.4
Table 30. Instances of VEHICLE-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materiel
-type-id
1601101
APC M113
1601101
AD21BZ
Class II
1601102
M578, Recovery
1601102
AD51ZZ
Class II
1601103
Bicycle
Kildemoes (DA)
1601103
EQUIPMENTTYPE
EQUIPMENTTYPE
EQUIPMENTTYPE
—
Class IV
(b) EQUIPMENT-TYPE
*-id
*-category-code
1601101
1601102
1601103
VEHICLE-TYPE
VEHICLE-TYPE
VEHICLE-TYPE
—
—
—
—
—
—
(c) VEHICLE-TYPE
**-id
**-category-code
1601101
1601102
1601103
Armoured personnel carrier
Armoured service support
Bicycle
Note: ** = "vehicle-type"
4.5.2.10 Specification of VESSEL-TYPE
4.5.2.10.1 VESSEL-TYPE is defined as "An EQUIPMENT-TYPE that is
designed to operate on or under the water surface." The attributes are:
a.
vessel-type-id—The equipment-type-id of a specific VESSEL-TYPE (a role
b.
vessel-type-category-code—The specific value that represents the class of
VESSEL-TYPE. It serves as a discriminator that partitions VESSEL-TYPE
into subtypes. The domain values are: SUBSURFACE-VESSEL-TYPE;
SURFACE-VESSEL-TYPE; Unclassified miscellaneous unit; Not known.
c.
vessel-type-magnetic-degaussing-code-number-quantity—The numeric value
that represents the peak vertical component of the magnetic field under a
ship on the worst heading and at certain depth. The unit of measure is
microtesla.
d.
vessel-type-prismatic-coefficient-ratio—The numeric quotient value that
represents a ratio of the volume displaced by the hull in relation to the
volume of a prism or cylinder of cross section equal to the greatest crosssection of the submerged part of the hull and of length equal to the ships
length between perpendiculars. The value must be in the range from 0 to 1.
e.
vessel-type-dead-weight-quantity—The numeric value that represents the
carrying capacity of a ship. Dead weight is the difference between the Full
displacement (Gross weight) and the Light displacement (Net weight). The
unit of measure is metric ton.
107
V3.1.4
f.
vessel-type-draught-dimension—The numeric value of the distance from the
Deep Water Line (DWL) to the lowest permanent projection on the hull of a
vessel type including sonar domes, propellers, rudders, or other projections.
g.
vessel-type-gross-registered-tonnage-quantity—The numeric value that
represents a ship's internal cubic capacity or freight-carrying capacity. The
unit of measure is Gross Registered Tonnage (GRT). A unit of Gross
Registered Tonnage is equal to 2.83 cubic metres.
h.
vessel-type-height-above-the-waterline-dimension—The
one-dimensional
linear distance representing the distance from the waterline to the topmost
point of an unloaded vessel.
i.
vessel-type-propeller-count—The integer value representing the number of
propellers on the ship.
j.
vessel-type-propulsion-type-code—The specific value that represents the
type of power used to move the vessel. Example domain values are:
Combined diesel and gas turbine; Diesel engine; Gas turbine; Water jet.
k.
vessel-type-operational-displacement-quantity—The numeric value that
represents the weight or volume of water moved by the vessel on the surface
of the water. The unit of measure is metric ton.
l.
vessel-type-maximum-speed-rate—The numeric value of the maximum
speed that a vessel type can maintain for one hour or less with a clean hull
immediately out of dry docking or refit. The speed is measured in knots. The
specified value must be greater than or equal to 0 (zero).
m.
vessel-type-acoustic-merit-index-quantity—The numeric value that indicates
the total acoustic level.
4.5.2.10.2 Examples of VESSEL-TYPE are provided in the table below.
Table 31. Instances of VESSEL-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materiel
-type-id
1701101
Danbjoern (DA)
1701101
EA24AB
Class II
1701102
Fenja (DA)
1701102
EA29AZ
Class IV
1701103
Niels Juel (DA)
1701103
EB15BC
Class II
1701104
Nautilaus
1701104
EQUIPMENTTYPE
EQUIPMENTTYPE
EQUIPMENTTYPE
EQUIPMENTTYPE
—
Class II
(b) EQUIPMENT-TYPE
*-id
*-category-code
1701101
1701102
1701103
1701104
VESSEL-TYPE
VESSEL-TYPE
VESSEL-TYPE
VESSEL-TYPE
3685
3455
1320
3000
3115
3165
1215
1500
108
V3.1.4
(c) VESSEL-TYPE
**-id
1701101
1701102
1701103
1701104
**-categorycode
**-magnetic-degaussingcode-number-quantity
**-prismaticcoefficient-ratio
**-dead-weightquantity
**-draughtdimension
SURFACEVESSEL-TYPE
SURFACEVESSEL-TYPE
SURFACEVESSEL-TYPE
SUBSURFACEVESSEL-TYPE
10000 [nT]
0.8
2000
35
20000 [nT]
0.7
4000
38
15000 [nT]
0.6
3000
25
4000 [nT]
0.3
2000
27
Note: ** = "vessel-type"
**-gross-registeredtonnage-quantity
**-height-above-thewaterline-dimension
**-propellercount
**-propulsiontype-code
800
1600
1200
2000
45
75
55
55
Unknown
Unknown
Unknown
Unknown
Diesel Engine
Gas Turbine
Gas Turbine
Diesel Engine
**-operationaldisplacement-quantity
**-acoustic-meritindex-quantity
7500
18
87
12500
10500
9000
25
24
20
96
96
52
4.5.2.11 Specification of SURFACE-VESSEL-TYPE
4.5.2.11.1 SURFACE-VESSEL-TYPE is defined as "A vessel principally
designed to operate on the water surface." The attributes are:
a.
surface-vessel-type-id—The vessel-type-id of a specific SURFACEVESSEL-TYPE (a role name for object-type-id).
b.
surface-vessel-type-category-code—The specific value that represents the
class of surface vessel. Example domain values are: Aircraft carrier, ASW;
Ammunition ship, transport; Destroyer, escort; Merchant ship, heavy lift;
Torpedo boat, air cushion.
c.
surface-vessel-type-displacement-quantity—The
numeric
value
that
represents the maximum volume of water moved by the vessel when it is
fully loaded. The unit of measure is cubic metre.
d.
surface-vessel-type-maximum-deck-load-quantity—The numeric value that
represents the Ship's maximum allowable deck load. The unit of measure is
kilogram.
4.5.2.11.2 Examples of SURFACE-VESSEL-TYPE are provided in Sub-table (d)
below.
109
V3.1.4
(d) SURFACE-VESSEL-TYPE
***-id
***-categorycode
***-displacementquantity
***-maximum-deckload-quantity
1701101
Icebreaker
—
—
1701102
1701103
Ferry
Frigate
—
—
—
—
Note: *** = "surface-vessel-type"
4.5.2.12 Specification of SUBSURFACE-VESSEL-TYPE
4.5.2.12.1 SUBSURFACE-VESSEL-TYPE is defined as "A vessel principally
designed to operate under the water surface." The attributes are:
a.
subsurface-vessel-type-id—The vessel-type-id of a specific SUBSURFACEVESSEL-TYPE (a role name for object-type-id).
b.
subsurface-vessel-type-category-code—The specific value that represents the
class of subsurface vessel. Example domain values are: Deep submergence
vehicle; Submarine, attack, guided missile; Submarine, coastal; Submarine,
midget, swimmer; Submersible, research, military.
c.
subsurface-vessel-type-dived-displacement-quantity—The numeric value that
represents the volume of water that is moved by the subsurface vessel when it
is entirely below the surface. The unit of measure is ton.
d.
subsurface-vessel-type-speed-cavitation-quantity—The numeric value that
represents the speed at which the subsurface vessel will form bubbles or a
vacuum in the water. The unit of measure is knots.
e.
subsurface-vessel-type-torpedo-loading-gear-indicator-code—The specific
value that indicates whether a subsurface vessel has torpedo loading rails and
lifting bands. The domain values are: No; Yes.
4.5.2.12.2 Examples of SUBSURFACE-VESSEL-TYPE are provided in the Subtable (e) below.
(e) SUBSURFACE-VESSEL-TYPE
****-id
****-category-code
1701104
Submarine, attack,
guided missile
****-displacementquantity
****-maximum-deckload-quantity
****-torpedo-loadinggear-indicator-code
—
—
Yes
Note: **** = "subsurface-vessel-type"
4.5.2.13 Specification of WEAPON-TYPE
4.5.2.13.1 WEAPON-TYPE is defined as "An EQUIPMENT-TYPE of any kind
used in warfare or combat to attack and overcome an enemy." The attributes are:
a.
weapon-type-id—The equipment-type-id of a specific WEAPON-TYPE (a
b.
weapon-type-category-code—The specific value that represents the class of
WEAPON-TYPE. Example domain values are: Air-defence; Cannon;
Missile system; Rocket artillery; Tank.
c.
weapon-type-subcategory-code—The specific value that represents the
detailed class of WEAPON-TYPE. Example domain values are: Air-defence
110
V3.1.4
automatic cannon; Air-defence missile launcher; Anti-tank gun, medium;
Flame-thrower; Mortar, light; Surface-to-surface missile launcher, short
range.
d.
weapon-type-calibre-text—The character string assigned to represent a
specific calibre of a WEAPON-TYPE.
e.
weapon-type-fire-guidance-indicator-code—The specific value that indicates
whether a specific WEAPON-TYPE provides fire guidance. The domain
values are: No; Yes.
4.5.2.13.2 Permissible combinations of domain values for weapon-type-categorycode and weapon-type-subcategory-code are specified in Annex G2, Section G2.2.1.6.
4.5.2.13.3 Examples of WEAPON-TYPE are provided in the table below.
Table 32. Instances of WEAPON-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
801101
801102
801103
M109 A2
LEOPARD 2 A5
MARDER 1 A3
801101
801102
801103
EQUIPMENT-TYPE
EQUIPMENT-TYPE
EQUIPMENT-TYPE
CA1AED
AA14AB
AC31CC
Class II
Class II
Class II
(b) EQUIPMENT-TYPE
*-id
*-category-code
801101
801102
801103
WEAPON-TYPE
WEAPON-TYPE
WEAPON-TYPE
12500
45000
—
11000
43000
—
(c) WEAPON-TYPE
**-subcategory-code
**-calibre-text
**-fire-guidanceindicator-code
Field artillery
Howitzer
155 MM
No
Tank
Not otherwise
specified
Battle tank, medium
Armoured infantry
fighting/combat vehicle
120 MM
30 MM
No
No
**-id
**-category-code
801101
801102
801103
Note: ** = "weapon-type"
4.5.3 CONSUMABLE-MATERIEL-TYPE Tree Structure
The structure of CONSUMABLE-MATERIEL-TYPE and its subtypes is
illustrated in the figure below. The specification details are provided below.
4.5.3.1
Specification of CONSUMABLE-MATERIEL-TYPE
4.5.3.1.1 A CONSUMABLE-MATERIEL-TYPE is defined as "A MATERIELTYPE that is an expendable class of supply." Consumables can generally be issued in
different standard quantities, each having its own packaging.
111
V3.1.4
CONSUMABLE-MATERIEL-TY PE
consumable-materiel-type-id (FK)
consumable-materiel-type-subcategory-code
consumable-materiel-type-hazard-code
consumable-materiel-type-is suing-element-code
consumable-materiel-type-is suing-count
consumable-materiel-type-is suing-unit-of -measure-code
consumable-materiel-type-is suing-w eight-quantity
consumable-materiel-type-perishability-indicator-code
consumable-materiel-type-united-nations-number-code
AMMUNITION-TY PE
ammunition-type-id (FK)
ammunition-type-category -code
ammunition-type-calibre-text
ammunition-type-mine-maritime-firing-code
ammunition-type-exercise-mine-flare-c olour-code
BIOLOGICAL-MA TERIEL-TYPE
biological-materiel-type-id (FK)
biological-materiel-type-category-code
biological-materiel-type-subcategory -code
biological-materiel-type-pers istency-code
chemical-materiel-type-id (FK)
chemical-materiel-type-category-code
chemical-materiel-type-subc ategory-code
chemical-materiel-type-persistency-code
RA DIOACTIVE-MATERIEL-TYPE
radioactive-materiel-type-id (FK)
radioactive-materiel-type-category-code
radioactive-materiel-type-primary-radiation-c ode
Figure 46. CONSUMABLE-MATERIEL-TYPE and Its Subtypes
4.5.3.1.2 CONSUMABLE-MATERIEL-TYPE provides various attributes that
describe the packaging in question. The attributes are:
a.
consumable-materiel-type-id—The
materiel-type-id
of
a
specific
CONSUMABLE-MATERIEL-TYPE (a role name for object-type-id).
b.
consumable-materiel-type-category-code—The specific value that represents
the class of CONSUMABLE-MATERIEL-TYPE. It serves as a
discriminator that partitions CONSUMABLE-MATERIEL-TYPE into
subtypes. Example domain values are: AMMUNITION-TYPE;
BIOLOGICAL-MATERIEL-TYPE;
CHEMICAL-MATERIEL-TYPE;
Construction materials; Drug; Food; Fuel; Fuse; Medical supply; Money;
Personal equipment; RADIOACTIVE-MATERIEL-TYPE; Not known.
c.
consumable-materiel-type-subcategory-code—The specific value that
represents the detailed class of a specific CONSUMABLE-MATERIELTYPE. Example domain values are: Blood; Lubricant; Matting; Medicine;
NBC kit; Oil; Petrol; Uniform; Wire; Wood.
112
V3.1.4
d.
consumable-materiel-type-hazard-code—The specific value that represents a
CONSUMABLE-MATERIEL-TYPE that requires special handling because
of environmental or safety reasons. Example domain values are: Chemical;
Corrosive; Explosive; Inflammable; Radiation; Toxic.28
e.
consumable-materiel-type-issuing-element-code—The specific value that
represents a standard unit in which a specific CONSUMABLE-MATERIELTYPE is made available. Example domain values are: Bulk; Day of supply;
Drum; Pack; Pallet; Unit.
f.
consumable-materiel-type-issuing-count—The integer value representing the
aggregated units in which a specific CONSUMABLE-MATERIEL-TYPE is
made available.
g.
consumable-materiel-type-issuing-unit-of-measure-code—The specific value
that represents the unit of measure of which a standard quantity (unit) of a
specific CONSUMABLE-MATERIEL-TYPE is made available. Example
domain values are: Cubic metre; Each; Kilogram; Kilometre; Litre; Metre;
Metric ton; Square metre.
h.
consumable-materiel-type-issuing-weight-quantity—The numeric value that
represents the gravitational force exerted on an amount of a standard unit of
issue for a specific CONSUMABLE-MATERIEL-TYPE when it is prepared
for delivery. The unit of measure is kilogram.
i.
consumable-materiel-type-perishability-indicator-code—The specific value
that represents whether a particular CONSUMABLE-MATERIEL-TYPE is
liable to decay or spoil. The domain values are: No; Yes.
j.
consumable-materiel-type-united-nations-number-code—The specific value
that represents the United Nations (UN) Numbers that are four-digit numbers
used world-wide in international commerce and transportation to identify
hazardous chemicals or classes of hazardous materials. Example domain
values are: UN Dangerous Goods # 1005; UN Dangerous Goods # 1134; UN
Dangerous Goods # 1836; UN Dangerous Goods # 2814; UN Dangerous
Goods # 3333.
4.5.3.1.3 Permissible combinations of domain values for consumable-materieltype-hazard-code
and
consumable-materiel-type-united-nations-number-code
are
specified in Annex G2, Section G2.2.2.2.
4.5.3.1.4 Example instances
provided in the table below.
for
are
The normal markings consist of UN followed by a 4 digit numeric code. The codes with
explicit meanings are illustrated by the following: UN1263 = paint; UN1170 = ethanol; UN2910 =
Radiac; UN1.4 = small arms ammunition.
28
113
V3.1.4
Table 33. CONSUMABLE-MATERIEL-TYPE Example Instances
*-id
*-category-code
574
AMMUNITIONTYPE
AMMUNITIONTYPE
AMMUNITIONTYPE
25472
1869
1870
1871
POL
POL
*-issuingelement-code
*-issuingquantity
*-issuing-unit-ofmeasure-code
*-issuing-weightquantity
Pack
50
Each
100
Pallet
200
Each
2,000
Pallet
500
Each
4,000
Drum
Bulk
200
5,000
Litre
Litre
220
7,000
Note: * = "consumable-materiel-type"
4.5.3.1.5 Not all combinations of domain values for CONSUMABLEMATERIEL-TYPE attributes that specify category code and subcategory code are
meaningful. A number of constraints have been placed on the choice of domain values to
limit the combinations to those that are operationally sensible. The resulting set of valid
combinations is specified in Annex G2, Section G2.2.2.1.
4.5.3.1.6 The value Day of supply for consumable-materiel-type-issuing-elementcode is defined as "A Day of supply (at combat rate) is the amount of consumable materiel
required to enable a formation (unit, i.e. Division, Brigade etc) to carry out operations for
1 day." It is to be used in connection with providing a quantitative assessment of the
unit’s/formation’s current holding of commodities or materiel using standardised
measurements/units of expenditure for manpower, fuel, rations, ammunition, medical,
material, water, spares. It also helps in the assessment of changes needed to current
holdings of commodities/materiel required to meet future plans.
4.5.3.1.7 The normal denomination used at a high level of reporting is Days of
Supply (DOS) as defined. In general, the rate of consumption depends on operational
tempo. For example, 1 DOS at combat rate can be interpreted by the receiving staff officer
as equating to 2 DOS at defensive rate, 3 DOS at rest area rate, and so on.
4.5.3.2
Specification of AMMUNITION-TYPE
4.5.3.2.1 An AMMUNITION-TYPE is defined as "A CONSUMABLEMATERIEL-TYPE that is a complete device charged with explosives, propellants,
pyrotechnics, initiating composition, or nuclear, biological, or chemical material for use in
military operations." The attributes are:
a.
ammunition-type-id—The consumable-materiel-type-id
AMMUNITION-TYPE (a role name for object-type-id).
b.
ammunition-type-category-code—The specific value that represents the class
of AMMUNITION-TYPE. Example domain values are: Bomblet; Hand
grenade; Mine, anti-personnel; Rocket; Seabed mine; Torpedo.
c.
ammunition-type-calibre-text—The character string assigned to represent a
specific calibre of an AMMUNITION-TYPE.
d.
ammunition-type-mine-maritime-firing-code—The specific value that
represents the firing mechanism for a maritime mine. Example domain
114
of
a
specific
V3.1.4
values are: Acoustic audio frequency; Coarse, anti-sweep; Magnetic V,
vertical component; Very sensitive, anti sweeper.
e.
ammunition-type-exercise-mine-flare-colour-code—The specific value that
represents the colour of the flare released by the exercise mine. The domain
values are: Green; Orange; Red; White; Yellow.
4.5.3.2.2 Permissible combinations of domain values for ammunition-typecategory-code and ammunition-type-mine-maritime-firing-code are specified in Annex
G2, Section G2.2.2.3.
4.5.3.2.3 Examples of AMMUNITION-TYPE are provided in the table below.
Table 34. Instances of AMMUNITION-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
1001101
1001101
Class V
MA4BAP
Class V
MC34AA
Class V
1001104
—
Class V
1001105
Mine flare
1001105
CONSUMABLEMATERIEL-TYPE
MA29GT
1001104
7.62 MM X 51MM
TRACER
120 MM
APPFSDS-T
Bomb, cluster,
gator
Mine, moored
—
Class V
1001102
1001103
1001102
1001103
(b) CONSUMABLE-MATERIEL-TYPE
*-id
*-category-code
1001101
AMMUNITIONTYPE
AMMUNITIONTYPE
AMMUNITIONTYPE
AMMUNITIONTYPE
AMMUNITIONTYPE
1001102
1001103
1001104
1001105
*-issuingelement-code
*-issuingquantity
*-issuing-weightquantity
Pack
50
Each
—
Pallet
48
Each
1,500
Pallet
1
Each
750
Unit
1
Each
—
Pack
50
Each
—
(c) AMMUNITION-TYPE
**-id
**-category-code
**-calibre-text
1101101
1101102
1101103
1001104
Small-arms ammunition
Gun shell
Bomb
Mine, moored
7.62 X 51MM
120 MM
—
—
1001105
Mine, maritime, moving
**-mine-maritimefiring-code
**-exercise-mine-flare-colourcode
—
—
—
Acoustic audio
frequency
—
—
—
—
—
Green
Note: ** = "ammunition-type"
4.5.3.3
Specification of BIOLOGICAL-MATERIEL-TYPE
4.5.3.3.1 A
is
defined
as
"A
CONSUMABLE-MATERIEL-TYPE that is either a microorganism that causes disease in
115
V3.1.4
man, plants, or animals or causes the deterioration of materiel; or a toxin, produced by an
animal, plant, or microorganism, which may kill, seriously injure, or incapacitate
personnel through its physiological effects." The attributes are:
a.
biological-materiel-type-id—The consumable-materiel-type-id of a specific
BIOLOGICAL-MATERIEL-TYPE (a role name for object-type-id).
b.
biological-materiel-type-category-code—The specific value that represents
the class of BIOLOGICAL-MATERIEL-TYPE. The domain values are:
Bacterial; Toxic industrial material; Toxin; Viral; Not known; Not otherwise
specified.
c.
biological-materiel-type-subcategory-code—The
specific
value
that
represents the detailed class of a specific BIOLOGICAL-MATERIELTYPE. The domain values are: Chlamydia; Rickettsiae; Not otherwise
specified.
d.
biological-materiel-type-persistency-code—The
specific
value
that
represents the temporal variation of the effectiveness of a BIOLOGICALMATERIEL-TYPE under determined conditions after its dispersal. The
domain values are: Non-persistent; Persistent; Thickened; Not known. The
domain value set for this attribute is shared with one or more other attributes
and is defined in the set persistency-code.
4.5.3.3.2 Permissible combinations of domain values for biological-materieltype-category-code and biological-materiel-type-subcategory-code are specified in Annex
G2, Section G2.2.2.4.
4.5.3.3.3 Examples of BIOLOGICAL-MATERIEL-TYPE are provided in the
table below.
Table 35. Instances of BIOLOGICAL-MATERIEL-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
1101101
Unknown virus
1101101
—
—
1101102
Chlamydia
bacteria
Unknown toxic
materiel
1101102
—
—
—
—
1101103
1101103
*-id
*-category-code
*-issuing-element-code
*-issuing-count
1101101
BIOLOGICALMATERIEL-TYPE
—
—
—
—
—
—
1101102
1101103
116
V3.1.4
(c) BIOLOGICAL-MATERIEL-TYPE
**-id
**-category-code
**-subcategory-code
**-persistency-code
1101101
1101102
1101103
Viral
Bacterial
Toxic industrial materiel
Chlamydia
Persistent
Persistent
Not known
Note: ** = "biological-materiel-type"
4.5.3.4
Specification of CHEMICAL-MATERIEL-TYPE
4.5.3.4.1 A CHEMICAL-MATERIEL-TYPE is defined as "A CONSUMABLEMATERIEL-TYPE that is a substance that is not produced by a living organism, and does
not emit radiation but may kill, seriously injure, or incapacitate personnel through its
physiological effects or cause the deterioration of materiel." The attributes are:
a.
chemical-materiel-type-id—The consumable-materiel-type-id of a specific
CHEMICAL-MATERIEL-TYPE (a role name for object-type-id).
b.
chemical-materiel-type-category-code—The specific value that represents
the general class of a specific CHEMICAL-MATERIEL-TYPE. Example
domain values are: Blister agent; Incapacitating agent; Nerve agent;
Penetrating agent; Vomiting agent.
c.
chemical-materiel-type-subcategory-code—The
specific
value
that
represents the detailed class of a specific CHEMICAL-MATERIEL-TYPE.
Example domain values are: Arsine; Di-phosgene; Phosgene oxime; Sarin;
Trimeric mustard.
d.
chemical-materiel-type-persistency-code—The specific value that represents
the temporal variation of the effectiveness of a CHEMICAL-MATERIELTYPE under determined conditions after its dispersal. The domain values
are: Non-persistent; Persistent; Thickened; Not known. The domain value set
for this attribute is shared with one or more other attributes and is defined in
the set persistency-code.
4.5.3.4.2 Permissible combinations of domain values for chemical-materiel-typecategory-code and chemical-materiel-type-subcategory-code are specified in Annex G2,
Section G2.2.2.5.
4.5.3.4.2 Examples of CHEMICAL-MATERIEL-TYPE are provided in the table
below.
Table 36. Instances of CHEMICAL-MATERIEL-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
1201101
Nerve gas,
Tabun
1201101
—
—
1201102
Blister gas
1201102
—
—
1201103
Chlorine gas
1201103
—
—
117
V3.1.4
*-id
*-category-code
*-issuing-count
1201101
CHEMICALMATERIEL-TYPE
—
—
—
—
—
—
1201102
1201103
(c) CHEMICAL-MATERIEL-TYPE
**-id
**-category-code
**-subcategory-code
**-persistency-code
1201101
1201102
1201103
Nerve agent
Blister agent
Choking agent
Tabun
Chloropicrin
Non-persistent
Persistent
Non-persistent
Note: ** = "chemical-materiel-type"
4.5.3.5
Specification of RADIOACTIVE-MATERIEL-TYPE
4.5.3.5.1 A RADIOACTIVE-MATERIEL-TYPE
is
defined
as "A
CONSUMABLE-MATERIEL-TYPE that is a substance which spontaneously emits
radiation, and which may kill, seriously injure, or incapacitate personnel through its
physiological effects or causes the deterioration of materiel." The attributes are:
a.
radioactive-materiel-type-id—The consumable-materiel-type-id of a specific
RADIOACTIVE-MATERIEL-TYPE (a role name for object-type-id).
b.
radioactive-materiel-type-category-code—The specific value that represents
the class of RADIOACTIVE-MATERIEL-TYPE. Example domain values
are: Cesium-137; Fresh reactor fuel; Nuclear weapon fallout; Plutonium-239;
Toxic industrial material.
c.
radioactive-materiel-type-primary-radiation-code—The specific value that
represents the most intense radiation emitted by a RADIOACTIVEMATERIEL-TYPE. The domain values are: Alpha radiation; Beta radiation;
Gamma radiation; Neutron; Not known.
4.5.3.5.2 Examples of RADIOACTIVE-MATERIEL-TYPE are provided in the
table below.
Table 37. Instances of RADIOACTIVE-MATERIEL-TYPE
(a) OBJECT-TYPE
MATERIEL-TYPE
objecttype-id
materieltype-id
1301101
Plutonium-239
1301101
—
—
1301102
Phosphorus-32
1301102
—
—
1301103
Tritium
1301103
—
—
118
V3.1.4
*-id
*-category-code
*-issuing-count
1301101
RADIOACTIVEMATERIEL-TYPE
—
—
—
—
—
—
1301102
1301103
(c) RADIOACTIVE-MATERIEL-TYPE
**-id
**-category-code
**-primary-radiation-code
1301101
1301102
1301103
Plutonium-239
Alpha radiation
Beta radiation
Beta radiation
Note: ** = "radioactive-materiel-type"
4.6
ORGANISATION-TYPE Tree Structure
The model view of ORGANISATION-TYPE tree structure is illustrated in the
figure below. The details of ORGANISATION-TYPE and its subtypes are provided in the
sections below.
4.6.1 Specification of ORGANISATION-TYPE
4.6.1.1 The entity ORGANISATION-TYPE is defined as "An OBJECT-TYPE that
represents administrative or functional structures." It is constituted to accomplish an aim,
purpose, or mission. The attributes are:
a.
organisation-type-id—The object-type-id of a specific ORGANISATIONTYPE (a role name for object-type-id).
b.
organisation-type-category-code—The specific value that represents the class
of ORGANISATION-TYPE. It serves as a discriminator that partitions
ORGANISATION-TYPE into subtypes. The domain values are: CIVILIANPOST-TYPE;
GOVERNMENT-ORGANISATION-TYPE;
GROUPORGANISATION-TYPE; PRIVATE-SECTOR-ORGANISATION-TYPE;
Not otherwise specified.
c.
organisation-type-command-function-indicator-code—The specific value that
denotes whether an ORGANISATION-TYPE has a command function. The
domain values are: No, Yes.
d.
organisation-type-command-and-control-category-code—The specific value
that denotes the command and control classification of an ORGANISATIONTYPE. Example domain values are: Command post; Headquarters; Operations
centre.
e.
organisation-type-description-text—The character string assigned to represent
the specific ORGANISATION-TYPE.
119
V3.1.4
ORGANISATION-TYPE
organisation-type-id (FK)
organisation-type-command-function-indicator-code
organisation-type-command-and-control-category-code
organisation-type-description-text
government-organisation-type-id (FK)
CIVILIAN-POST-TYPE
civilian-post-type-id (FK)
government-organisation-type-main-activity-code
civilian-post-type-category-code
group-organisation-type-id (FK)
group-organisation-type-category-code
private-sector-organisation-type-id (FK)
military-organisation-type-id (FK)
military-organisation-type-service-code
has-for-support-a-specific /
is-constituted-to-support
private-sector-organisation-type-category-code
private-sector-organisation-type-main-activity-code
UNIT-TYPE
unit-type-id (FK)
unit-type-category-code
unit-type-arm-category-code
unit-type-arm-specialisation-code
unit-type-supplementary-specialisation-code
unit-type-general-mobility-code
unit-type-qualifier-code
unit-type-size-code
unit-type-principal-equipment-type-id (FK)
unit-type-supported-military-organisation-type-id (FK)
executive-military-organisation-type-id (FK)
executive-military-organisation-type-category-code
MILITARY-POST-TYPE
military-post-type-id (FK)
military-post-type-category-code
military-post-type-rank-code
TASK-FORMATION-TYPE
task-formation-type-id (FK)
task-formation-type-category-code
Figure 47. ORGANISATION-TYPE Subtype Hierarchy
4.6.1.2 Permissible combinations of organisation-type-command-functionindicator-code and organisation-type-command-and-control-category-code are specified
in Annex G2, Section G2.2.3.1.
4.6.1.3 Example instances for ORGANISATION-TYPE are provided in the table
below. This extended list is broken down further when the subtypes are discussed.
Subtypes include information that is specific to the subtype.
120
V3.1.4
Table 38. Examples of ORGANISATION-TYPE
ORGANISATION-TYPE
*-id
*-category-code
*-commandfunctionindicator-code
*-commandand-controlcategory-code
12345601
CIVILIAN-POST-TYPE
No
—
12345602
CIVILIAN-POST-TYPE
GOVERNMENT-ORGANISATIONTYPE
No
—
Operations
centre
12345603
12345604
12345605
12345606
12345607
12345608
12345609
12345610
12345611
12345612
12345613
12345614
12345615
12345616
12345617
12345618
12345619
12345620
12345621
12345622
12345623
12345624
12345625
12345626
12345627
12345628
12345629
12345630
12345631
Yes
PRIVATE-SECTORORGANISATION-TYPE
Task formation
No
—
Task formation
No
—
Task formation
No
—
Task formation
No
—
Unit
No
—
Military post
No
—
Education
organisation
No
—
Health organisation
No
—
Unit
No
—
Corporation
No
—
Corporation
No
—
Corporation
Yes
Command post
Unit
No
—
Unit
No
—
Unit
No
—
Unit
Yes
Command post
Unit
Yes
Command post
Unit
No
—
Unit
No
—
Unit
No
—
Unit
No
—
Unit
No
No
No
No
—
—
—
—
Media
Refugee
Merchant
Writer
No
—
Military post
No
—
Military post
Headquarters
Executive military
organisation
Yes
121
*-description-text
Secretary of Defense US
Chief of Police - Brno
V3.1.4
*-id
*-category-code
Yes
Headquarters
Yes
Headquarters
No
—
12345632
12345633
12345634
*-description-text
Executive military
organisation
Executive military
organisation
Unit
Note: * = "organisation-type"
4.6.2 Specification of CIVILIAN-POST-TYPE
4.6.2.1 CIVILIAN-POST-TYPE is defined as "An ORGANISATION-TYPE with
a set of duties that are intended to be fulfilled by one person in private sector and nonmilitary government organisations." The attributes are:
a.
civilian-post-type-id—The organisation-type-id of a specific CIVILIANPOST-TYPE (a role name for object-type-id).
b.
civilian-post-type-category-code—The specific value that represents the
class of CIVILIAN-POST-TYPE. Example domain values are: Aid
administrator; Government minister; Police chief.
4.6.2.2 Examples of CIVILIAN-POST-TYPE are provided in the table below in
which Sub-table (a) is repeated from a previous table.
Table 39. CIVILIAN-POST-TYPE Example Instances
(a) ORGANISATION-TYPE
*-categorycode
*-id
12345601
12345602
*-command-functionindicator-code
*-command-andcontrol-category-code
No
—
No
—
CIVILIANPOST-TYPE
CIVILIANPOST-TYPE
*-description-text
Secretary of
Defense - US
Chief of Police Brno
(b) CIVILIAN-POST-TYPE
**-id
**-category-code
12345601
12345602
Government minister
Police chief
Note: ** = "civilian-post-type"
4.6.3 Specification of GOVERNMENT-ORGANISATION-TYPE
4.6.3.1 GOVERNMENT-ORGANISATION-TYPE
is
defined
as
"An
ORGANISATION-TYPE that controls and administers public policy either under a
national or international mandate." The attributes are:
a.
government-organisation-type-id—The organisation-type-id of a specific
GOVERNMENT-ORGANISATION-TYPE (a role name for object-type-id).
b.
government-organisation-type-category-code—The specific value that
represents the class of GOVERNMENT-ORGANISATION-TYPE. It serves
as a discriminator that partitions GOVERNMENT-ORGANISATION-TYPE
122
V3.1.4
into subtypes. Example domain values are: International civil; MILITARYORGANISATION-TYPE; National civil.
c.
government-organisation-type-main-activity-code—The specific value that
represents the main activity of a GOVERNMENT-ORGANISATION-TYPE.
Example domain values are: Agriculture programs; Food programs; Social
programs. The domain value set for this attribute is shared with one or more
other attributes and is defined in the set main-activity-code.
4.6.3.2 Examples of GOVERNMENT-ORGANISATION-TYPE are provided in
the table below. Sub-table (a) replicates part of the previous Table 38. These examples are
further subtyped in the following sections.
Table 40. Examples of GOVERNMENT-ORGANISATION-TYPE
*-id
*-category-code
12345603
Yes
12345604
12345605
12345606
12345607
12345608
No
No
No
No
No
Operations
centre
—
—
—
—
—
12345609
No
—
12345610
No
—
12345611
12345615
12345616
12345617
No
Yes
No
No
—
Command post
—
—
12345618
12345619
12345620
12345621
12345622
12345623
12345624
12345629
12345630
No
Yes
Yes
No
No
No
No
No
No
—
Command post
Command post
—
—
—
—
—
—
12345631
Yes
Headquarters
12345632
Yes
Headquarters
12345633
Yes
Headquarters
12345634
No
—
123
*-descriptiontext
Task formation
Task formation
Task formation
Task formation
Unit
Military post
Education
organisation
Health
organisation
Unit
Unit
Unit
Unit
Unit
Unit
Unit
Unit
Unit
Unit
Unit
Military post
Military post
Executive military
organisation
Executive military
organisation
Executive military
organisation
Unit
V3.1.4
(b) GOVERNMENT-ORGANISATION-TYPE
**-id
**-category-code
**-main-activity-code
12345603
12345604
12345605
12345606
12345607
12345608
12345609
12345610
12345611
International civil
International civil
—
—
—
—
—
—
Education programs
Health programs
—
12345615
12345616
12345617
12345618
12345619
—
—
—
—
—
12345620
12345621
12345622
12345623
12345624
12345629
12345630
12345631
12345632
12345633
12345634
—
—
Infrastructure and construction
repair programs
—
—
—
—
—
—
—
—
Note: ** = "government-organisation-type"
4.6.3.3.
An example of the use of government-organisation-type-main-activitycode is a military unit type which has education or civilian reconstruction as its main
activity. This could be expressed by sub-typing the GOVERNMENT-ORGANISATIONTYPE as a MILITARY-ORGANISATION-TYPE (through the government-organisationtype-category-code) and also specifying the appropriate domain value for the governmentorganisation-type-main-activity-code attribute.
4.6.4 MILITARY-ORGANISATION-TYPE Tree Structure
4.6.4.1
Specification of MILITARY-ORGANISATION-TYPE
4.6.4.1.1 MILITARY-ORGANISATION-TYPE
is
defined
as
"A
GOVERNMENT-ORGANISATION-TYPE that is officially sanctioned and is trained and
equipped to exert force." The attributes are:
a.
military-organisation-type-id—The government-organisation-type-id of a
specific MILITARY-ORGANISATION-TYPE (a role name for object-typeid).
b.
military-organisation-type-category-code—The specific value that represents
the class of MILITARY-ORGANISATION-TYPE. It serves as a
discriminator that partitions MILITARY-ORGANISATION-TYPE into
subtypes. The domain values are:
EXECUTIVE-MILITARYORGANISATION-TYPE;
MILITARY-POST-TYPE;
TASKFORMATION-TYPE; UNIT-TYPE; Not otherwise specified.
124
V3.1.4
c.
military-organisation-type-service-code—The specific value that represents a
military, paramilitary, irregular force, force or group, capable of functioning
as an offensive or defensive combat or support organisation. Example
domain values are: Air Force; Army; Border guard; Combined; Joint; Local
defence force; Local militia; Marines; Navy; Not otherwise specified; Not
known.
4.6.4.1.2 Examples of MILITARY-ORGANISATION-TYPE are shown in the
table below. The data for ORGANISATION-TYPE and GOVERNMENTORGANISATION-TYPE may be found in the previous Table 38 and Table 40.
Table 41. Examples of MILITARY-ORGANISATION-TYPE
*-id
*-category-code
*-service-code
12345603
TASK-FORMATION-TYPE
Air Force
12345604
12345605
12345606
12345607
12345608
TASK-FORMATION-TYPE
TASK-FORMATION-TYPE
TASK-FORMATION-TYPE
UNIT-TYPE
MILITARY-POST-TYPE
Marines
Army
Navy
Guerrilla
Territorial force
12345611
12345615
12345616
12345617
12345618
12345619
12345620
12345621
12345622
12345623
12345624
12345629
12345630
12345631
12345632
12345633
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
MILITARY-POST-TYPE
MILITARY-POST-TYPE
Army
Army
Army
Army
Army
Army
Army
Army
Army
Army
Army
Army
Army
Army
Army
Army
UNIT-TYPE
Army
12345634
Note: * = "military-organisation-type"
4.6.4.2
Specification of EXECUTIVE-MILITARY-ORGANISATIONTYPE
4.6.4.2.1 EXECUTIVE-MILITARY-ORGANISATION-TYPE is defined as "A
MILITARY-ORGANISATION-TYPE whose function is to manage and direct the military
establishment." The attributes are:
a.
executive-military-organisation-type-id—The military-organisation-type-id
of a specific EXECUTIVE-MILITARY-ORGANISATION-TYPE (a role
b.
executive-military-organisation-type-category-code—The specific value that
represents the class of EXECUTIVE-MILITARY-ORGANISATION-TYPE.
Example domain values are: Headquarters; Logistics; Transportation.
125
V3.1.4
4.6.4.2.2 Examples of EXECUTIVE-MILITARY-ORGANISATION-TYPE are
shown in the table below. The full subtype tree is represented in Sub-tables (a) through
(d).
Table 42. Examples of EXECUTIVE-MILITARY-ORGANISATION-TYPE
*-id
*-category-code
GOVERNMENTORGANISATIONTYPE
12345631
12345632
12345633
*-command-andcontrol-categorycode
Yes
Headquarters
Executive military
organisation
Yes
Headquarters
Executive military
organisation
Yes
Headquarters
Executive military
organisation
*-descriptiontext
**-id
**-category-code
12345631
12345632
12345633
—
—
—
(c) MILITARY-ORGANISATION-TYPE
***-id
***-category-code
***-service-code
12345631
12345632
12345633
Army
Army
Army
Note: *** = "military-organisation-type"
(d) EXECUTIVE-MILITARY-ORGANISATION-TYPE
****-id
****-category-code
12345631
12345632
12345633
Headquarters
Logistics
Personnel
Note: **** = "executive-military-organisation-type"
4.6.4.3
Specification of MILITARY-POST-TYPE
4.6.4.3.1 MILITARY-POST-TYPE
is
defined as
"A
MILITARYORGANISATION-TYPE with a set of duties that can be fulfilled by one person." The
attributes are:
a.
military-post-type-id—The military-organisation-type-id of
MILITARY-POST-TYPE (a role name for object-type-id).
b.
military-post-type-category-code—The specific value that represents the
type classification of a MILITARY-POST-TYPE. Example domain values
are: Intelligence officer; Maintenance technician; Operations officer.
c.
military-post-type-rank-code—The specific value that represents a
designation for a military or naval grade that establishes the relative position
126
a
specific
V3.1.4
or status of a specific MILITARY-POST-TYPE. Example domain values
are: OF-1; OF-2; OF-3.
4.6.4.3.2 Examples of MILITARY-POST-TYPE are provided in the table below.
The full subtype tree is represented in Sub-tables (a) through (d).
Table 43. MILITARY-POST-TYPE Example Instances
*-id
*-category-code
12345629
12345630
12345608
*-descriptiontext
No
—
Military post
No
—
Military post
No
—
Military post
GOVERNMENTORGANISATION-TYPE
**-id
**-category-code
12345629
12345630
12345608
—
—
—
***-id
***-category-code
***-service-code
12345629
12345630
12345608
MILITARY-POST-TYPE
MILITARY-POST-TYPE
MILITARY-POST-TYPE
Army
Army
Army
(d) MILITARY-POST-TYPE
****-id
****-category-code
****-rank-code
12345629
13245630
12345608
Operations officer
Intelligence officer
Air liaison officer
OF-3
OF-2
OF-4
Note: **** = "military-post-type"
4.6.4.4
Specification of TASK-FORMATION-TYPE
4.6.4.4.1 TASK-FORMATION-TYPE is defined as "A MILITARYORGANISATION-TYPE that is constituted on a temporary or semi-permanent basis for
the purpose of carrying out a specific operation, mission or task." The attributes are:
a.
task-formation-type-id—The military-organisation-type-id of a specific
TASK-FORMATION-TYPE (a role name for object-type-id).
b.
task-formation-type-category-code—The specific value that represents the
class of TASK-FORMATION-TYPE. Example domain values are: Group
(navy); Joint task force; Patrol.
127
V3.1.4
4.6.4.4.2 Military forces may be organised in different ways. Some formations
may be set up in response to a specific task. Examples of such formation types are
illustrated in the table below. The full subtype tree is represented in Sub-tables (a) through
(d).
Table 44. Examples of TASK-FORMATION-TYPE
*-id
12345603
12345604
12345605
12345606
*-category-code
*-descriptiontext
Yes
Operations centre
Task formation
No
—
Task formation
No
—
Task formation
No
—
Task formation
**-id
**-category-code
12345603
12345604
12345605
12345606
—
—
—
—
***-id
***-category-code
***-service-code
12345603
12345604
12345605
12345606
TASK-FORMATION-TYPE
TASK-FORMATION-TYPE
TASK-FORMATION-TYPE
TASK-FORMATION-TYPE
Air Force
Marines
Army
Navy
(d) TASK-FORMATION-TYPE
****-id
****-category-code
12345603
12345604
12345605
12345606
Air task force
Amphibious task force
Patrol
Military-convoy-type
Note: **** = "task-formation-type"
4.6.4.5
Specification of UNIT-TYPE
4.6.4.5.1 UNIT-TYPE is defined as "A MILITARY-ORGANISATION-TYPE
whose structure is prescribed by competent authority." One aim of UNIT-TYPE subtype is
to permit unique specification of tables of organisation and equipment (referred to in this
model as establishment, as discussed in a subsequent section) for any unit of interest
within the scope of the model. A second aim is to provide information that is necessary for
generating unit symbology for situation displays. The attributes are:
128
V3.1.4
a.
unit-type-id—The military-organisation-type-id of a specific UNIT-TYPE (a
b.
unit-type-category-code—The specific value that represents the class of
UNIT-TYPE. The domain values are: Combat; Combat service support;
Combat support; Special operations forces; Not known.
c.
unit-type-arm-category-code—The specific value that represents the
designation of a military branch for a particular UNIT-TYPE. Example
domain values are: Armour; Aviation; Infantry; Medical; Signal.
d.
unit-type-arm-specialisation-code—The specific value that qualifies the
functional specialisation of a particular UNIT-TYPE. Example domain
values are: Aerial exploitation; Dental; Military police; Nuclear;
Surveillance.
e.
unit-type-supplementary-specialisation-code—The specific value that
supplements the designation of a particular UNIT-TYPE. Example domain
values are: Air assault; Armoured; Mechanised; Naval.
f.
unit-type-general-mobility-code—The specific value that represents the
general mobility of a unit, seen as a whole. Example domain values are: Air,
fixed wing; Amphibious; Land, tracked.
g.
unit-type-qualifier-code—The specific value that conveys additional
information on the specified UNIT-TYPE. Example domain values are:
High/medium altitude air defence; Long range; Tactical; Theatre missile
defence.
h.
unit-type-size-code—The specific value that represents the relative size of
the commonly accepted configuration of military formations. Example
domain values are: Army; Army group; Battalion; Battalion group; Brigade;
Company; Company group; Corps; Division; Platoon; Regiment;29 Section;
Squad; Team/fire team/crew; Not known.
i.
unit-type-principal-equipment-type-id—The equipment-type-id of the
EQUIPMENT-TYPE that is predominantly associated with a specific UNITTYPE for the purpose of identification (a role name for object-type-id). For
example an armoured unit can have as its principal equipment "Vehicle,
tank" and specifically "Battle-tank, heavy." This distinction is important in
the calculation of unit effectiveness where the primary consideration is
percentage of principal equipment operational rather than the percentage of
all equipment.
j.
unit-type-supported-military-organisation-type-id—The
militaryorganisation-type-id of a specific MILITARY-ORGANISATION-TYPE that
is supported by a specific UNIT-TYPE (a role name for object-type-id).
4.6.4.5.2 Valid combinations of domain values for a combination of six attributes
of UNIT-TYPE are specified in Annex G2, Section G2.2.3.2. The table contained in that
section should be consulted to guide implementation decisions.
Note: UK and FR regiments, being comprised of three or four manoeuvre units, are
represented as the "Battalion" unit-type-size-code, based on the comparative table of NATO
formations and units, as prescribed in STANAG 2356.
29
129
V3.1.4
4.6.4.5.3 The table below illustrates the use of UNIT-TYPE in characterising unit
types of interest. The full subtype tree is represented in Sub-tables (a) through (d).
Table 45. Examples of UNIT-TYPE
*-id
*-category-code
12345607
12345611
12345615
12345616
12345617
12345618
12345619
12345620
12345621
12345622
12345623
12345624
12345634
*-descriptiontext
No
No
Yes
No
No
No
—
—
Command post
—
—
—
Unit
Unit
Unit
Unit
Unit
Unit
Yes
Yes
No
No
No
Command post
Command post
—
—
—
Unit
Unit
Unit
Unit
Unit
No
No
—
—
Unit
Unit
**-id
**-category-code
12345607
12345611
12345615
12345616
12345617
12345618
12345619
12345620
12345621
12345622
—
—
—
—
—
—
—
—
—
Infrastructure and construction
repair programs
12345623
12345624
12345634
130
—
—
—
V3.1.4
***-id
***-category-code
***-service-code
12345607
12345611
12345615
12345616
12345617
12345618
12345619
12345620
12345621
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
Guerrilla
Army
Army
Army
Army
Army
Army
Army
Army
12345622
12345623
12345624
12345634
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
Army
Army
Army
Army
(d) UNIT-TYPE
****-id
****-categorycode
12345607
12345611
12345615
12345616
12345617
12345618
12345619
12345620
Combat
Combat
Combat support
Combat
Combat
Combat
Combat
Combat
12345621
Combat
12345622
Combat support
12345623
12345624
12345634
****-arm-category-code
****-arm-specialisationcode
****-supplementaryspecialisation-code
—
—
—
—
—
—
—
—
—
—
—
—
—
Light unit
—
Airborne
—
—
Infantry
Manoeuvre
Information warfare
Manoeuvre
Armour
Infantry
Infantry
Field artillery, howitzer/gun
Field artillery, multi rocket
launcher
Engineer
Engineer, construction
—
Combat support
Combat service
support
Military intelligence
Transportation
Interrogation
Transportation, railways
—
—
Combat support
Headquarters and signals
—
Note: **** = "unit-type"
131
V3.1.4
****-generalmobility-code
****-qualifiercode
****-size-code
****-principalequipment-type-id
****-supported-militaryorganisation-type-id
—
—
—
—
—
—
Coy
Div
Coy
—
—
—
—
—
—
—
—
—
—
Div
Battalion group
—
68763
[Challenger MBT]30
—
—
—
—
Bn
86978
[SA80 Assault Rifle]
—
Land, tracked
Land, towed
—
—
Coy
Bde
—
—
Land, tracked
—
Rgt
—
88023
[155-mm Field Artillery]
88024
[MLRS]
—
—
—
—
Bn
Coy
—
—
—
—
Land
—
Plt
Coy
—
—
—
12345621
—
4.6.4.5.4 When a command post is to be represented, the unit-type-size-code to
be used is the actual size of the unit to which it belongs. For example, Unit Type
12345615 is the command post of a company, so it is sized as a company. Another
example is Unit Type 12345620 that is the command post of an artillery brigade, so it is
sized as a brigade.
4.6.4.5.5 When a unit-type-size-code is specified for a headquarters unit type (i.e.
the unit that serves to establish or to man a command post), the value chosen should be for
the size of the headquarters unit itself rather than the size of the unit that the headquarters
serves. Examples of headquarters unit type include Unit Type 12345634, a company-size
formation intended to set-up the command post for an artillery brigade type (identifier
12345621).
4.6.4.5.6 Each nation has a different way of classifying its own units. The model
supports the representation of as many UNIT-TYPEs as possible (within the constraints of
common sense). It should be recognised that the manner of classifying units within the
data structure may not correspond to national classification policy. However, national
implementations of external displays for operational users can (and should) be built to
support the national doctrine and naming conventions. The internal classification within
the database of a C2 application (based on the model) can be entirely invisible to the user
of that application.
4.6.5 Specification of GROUP-ORGANISATION-TYPE
4.6.5.1 GROUP-ORGANISATION-TYPE is defined as "An ORGANISATIONTYPE that is non-formal in nature and classes together its members due to mutual or
common circumstances." The attributes are:
a.
group-organisation-type-id—The organisation-type-id of a specific GROUPORGANISATION-TYPE (a role name for object-type-id).
The use of brackets ([ and ]) is to provide the meaning of the object being referenced by the
identifier value.
30
132
V3.1.4
b.
group-organisation-type-category-code—The specific value that represents
the class of GROUP-ORGANISATION-TYPE. Example domain values are:
Displaced person; Landowner; Media, local; Refugee.
4.6.5.2 Examples of GROUP-ORGANISATION-TYPE are provided in the table
below.
Table 46. Examples of GROUP-ORGANISATION-TYPE
*-id
*-category-code
12345625
12345626
12345627
12345628
GROUP-ORGANISATIONTYPE
*-descriptiontext
No
—
Media
No
—
Refugee
No
—
Merchant
No
—
Writer
(b) GROUP-ORGANISATION-TYPE
**-id
**-category-code
12345625
12345626
12345627
12345628
Media, international
Refugee
Merchant
Writer
Note: ** = "group-organisation-type"
4.6.6 Specification of PRIVATE-SECTOR-ORGANISATION-TYPE
4.6.6.1 PRIVATE-SECTOR-ORGANISATION-TYPE is defined as "An
ORGANISATION-TYPE that is a non-government organisation and is constituted for
business, commerce, manufacturing, trade, relief or philanthropy." The attributes are:
a.
private-sector-organisation-type-id—The organisation-type-id of a specific
PRIVATE-SECTOR-ORGANISATION-TYPE (a role name for object-typeid).
b.
private-sector-organisation-type-category-code—The specific value that
represents the class of a PRIVATE-SECTOR-ORGANISATION-TYPE.
Example domain values are: Defence industry; News media; Philanthropic.
c.
private-sector-organisation-type-main-activity-code—The specific value that
represents the main activity of a PRIVATE-SECTOR-ORGANISATIONTYPE. Example domain values are: Agriculture programs; Food programs;
Social programs. The domain value set for this attribute is shared with one or
more other attributes and is defined in the set main-activity-code.
4.6.6.2 Examples of PRIVATE-SECTOR-ORGANISATION-TYPE are provided
in the table below.
133
V3.1.4
Table 47. Examples of PRIVATE-SECTOR-ORGANISATION-TYPE
*-id
*-category-code
12345612
12345613
12345614
*descriptiontext
No
—
Corporation
No
—
Corporation
No
—
Corporation
(b) PRIVATE-SECTOR-ORGANISATION-TYPE
**-id
**-category-code
12345612
12345613
12345614
Defence industry
Manufacturing
News media
—
—
Social program
Note: ** = "private-sector-organisation-type"
4.7
Specification of PERSON-TYPE
4.7.1 The entity PERSON-TYPE is defined as "An OBJECT-TYPE that
represents human beings about whom information is to be held." The attributes are:
a.
person-type-id—The object-type-id of a specific PERSON-TYPE (a role
b.
person-type-category-code—The specific value that represents the class of
PERSON-TYPE. The domain values are: Civilian; Military; Paramilitary;
Not known; Not otherwise specified.
c.
person-type-subcategory-code—The specific value that represents the
detailed class of PERSON-TYPE. Example domain values are: Displaced
person; Intellectual; Landowner; Media, national; Non-government
employee; Prisoner of war; Refugee.
d.
person-type-rank-code—The specific value that represents a designation for
a military, naval, or civil grade that establishes the relative position or status
of a specific PERSON-TYPE in an organisation. The code values correspond
to grades in STANAG 2116. Example domain values are: OF-1; OR-5; Other
ranks.
4.7.2 The table below provides example instances for PERSON-TYPE. The
types of persons are defined in Sub-tables (a) and (b). The affiliations of the types are
defined in Sub-tables (c), (d), and (e) where NATO affiliation is specified in Sub-table (d)
and the nationalities are specified in Sub-table (e). The affiliations are linked to the
instances of PERSON-TYPE in Sub-table (f). Note that the structure permits multiple
affiliations to be noted as in the case of person-type-id 1236 whose nationality is French
and who is associated with NATO.
134
V3.1.4
Table 48. Example Instances for PERSON-TYPE
(a) OBJECT-TYPE
objecttype-id
object-typecategory-code
1234
PERSON-TYPE
No
War correspondent
1235
1236
5311
5312
5313
PERSON-TYPE
PERSON-TYPE
PERSON-TYPE
PERSON-TYPE
PERSON-TYPE
No
Yes
No
No
No
—
Staff officer
—
—
—
(b) PERSON-TYPE
person-type-id
person-typecategory-code
person-typesubcategory-code
person-typerank-code
1234
1235
1236
5311
5312
5313
Civilian
Not known
Military
Military
Paramilitary
Military
Journalist
Refugee
Government employee
Displaced person
Terrorist
Prisoner of war
—
—
OF-9
[Captain]
—
[Sergeant]
4.8
AFFILIATION in Relation to OBJECT-TYPEs
The concept of affiliation includes a geopolitical or nationality characteristic
among other options. The AFFILIATION structure is specified in Chapter 19. The
affiliation information is appended to an instance of OBJECT-TYPE by means of an
associative entity. The AFFILIATION specification includes set of business rules that
regulate the relationship between AFFILIATION and OBJECT-TYPE. Some rules require
a mandatory attachment of an instance of AFFILIATION to an instance of OBJECTTYPE as an inherent part of the type characterization.
135
V3.1.4
5.
INDIVIDUALLY IDENTIFIABLE OBJECTS (ITEMS)
5.1
OBJECT-ITEM and Its Hierarchy
The independent entity OBJECT-ITEM identifies individual instances of objects
and records information concerning individual characteristics that are not typical of the
class. OBJECT-ITEM is broken down into a hierarchy of subtypes. The entire tree
structure at entity level is illustrated in the figure below.
OBJECT-ITEM
FEATURE
FACILITY
MATERIEL
ORGANISATION
UNIT
AIRFIELD
ANCHORAGE
PERSON
CONVOY
BASIN
APRON
BRIDGE
BERTH
QUAY
GEOGRAPHIC-FEATURE
DRY-DOCK
JETTY
CONTROL-FEATURE
HARBOUR
RAILWAY
ROAD
RUNWAY
ROUTE-SEGMENT
ROUTE
SLIPWAY
NETWORK
APPROACH-DIRECTION
AIR-ROUTE-SEGMENT
NETWORK-CAPACITY
MILITARY-OBSTACLE
NETWORK-SERVICE
MINEFIELD
NETWORK-FREQUENCY
ATMOSPHERE
ICING
CLOUD-COVER
LIGHT
MINEFIELD-LAND
PRECIPITATION
MINEFIELD-MARITIME
VISIBILITY
WIND
Figure 48. Entity-Level View of OBJECT-ITEM Subtype Tree
136
V3.1.4
5.2
Specification of OBJECT-ITEM
5.2.1 OBJECT-ITEM is defined as "An individually identified object that has
military or civilian significance." This can range from a unit to a single person, an entire
tank to a single bolt, and a mountain to a pile of dirt. OBJECT-ITEM can represent not
only physical objects, but can also represent intangible or abstract objects such as
rendezvous points, phase lines, and boundaries. The attributes are:
a.
object-item-id—The unique value, or set of characters, assigned to represent
a specific OBJECT-ITEM and to distinguish it from all other OBJECTITEMs. For example, a particular unit (e.g., 1 Bn 2 (US) Inf Bde) will be
labelled by a unique identifier that can be used to access information relating
to that unit.
b.
object-item-category-code—The specific value that represents the class of
OBJECT-ITEM. It serves as a discriminator that partitions OBJECT-ITEM
into subtypes. The domain values are: FACILITY; FEATURE; MATERIEL;
ORGANISATION; PERSON; Not known. Note: The value "Not known" is
intended for initial use in tracking situations where the object being tracked
cannot be definitively classified. When sufficient information becomes
available to determine an appropriate classification, a new instance of
OBJECT-ITEM would be created with appropriate value for object-itemcategory-code.
c.
object-item-name-text—The character string assigned to represent a specific
OBJECT-ITEM.
5.2.2 OBJECT-ITEM has three child entities that add amplifying information.
OBJECT-ITEM-ALIAS adds alternate labelling of an item that is assumed to be persistent. The
entity OBJECT-ITEM-COMMENT and OBJECT-ITEM-COMMENT-CONTENT enables two
types of comments to be appended to an instance of OBJECT-ITEM: an annotation for use with
symbology in OBJECT-ITEM-COMMENT and a representation of long texts attached to
OBJECT-ITEMs in the OBJECT-ITEM -COMMENT-CONTENT entity for general use. The
structure is illustrated in the figure below.
5.2.3 Additional naming of an instance of OBJECT-ITEM beyond that in objectitem-name-text is represented in a separate child entity OBJECT-ITEM-ALIAS. The child
construct permits multiple names to be assigned to a single instance of OBJECT-ITEM
according to specific categories. OBJECT-ITEM-ALIAS is defined as "An additional
name for an OBJECT-ITEM." The attributes are:
a.
a specific OBJECT-ITEM and to distinguish it from all other OBJECTITEMs.
b.
object-item-alias-index—The unique value, or set of characters, assigned to
represent a specific OBJECT-ITEM-ALIAS for a specific OBJECT-ITEM
and to distinguish it from all other OBJECT-ITEM-ALIASs for that
OBJECT-ITEM.
c.
object-item-alias-category-code—The specific value that represents the class
of OBJECT-ITEM-ALIAS. The domain values are: Alternate name; Elint
137
V3.1.4
notation; Emissions sorting code; Geolocation; Track identifier; Unit
designator.
d.
object-item-alias-name-text—The character string assigned to represent a
specific OBJECT-ITEM.
OBJECT-ITEM
object-item-id
object-item-name-text
has
has-comments-added-by /
provides-comments-about
OBJECT-ITEM-ALIAS
object-item-id (FK)
object-item-alias-index
object-item-alias-category-code
object-item-alias-name-text
OBJECT-ITEM-COMMENT
object-item-id (FK)
object-item-comment-index
object-item-comment-symbol-annotation-text
is-referenced-to
REPORTING-DATA
reporting-data-id
reference-id (FK)
has-content-added-by /
provides-content-about
OBJECT-ITEM-COMMENT-CONTENT
object-item-id (FK)
object-item-comment-index (FK)
object-item-comment-content-index
object-item-comment-content-text
object-item-comment-content-sequence-ordinal
Figure 49. Extension of OBJECT-ITEM to Alias and Comment
5.2.4 Comments with respect to an OBJECT-ITEM can be added in a separate
child structure comprised of entities OBJECT-ITEM-COMMENT and OBJECT-ITEMCOMMENT-CONTENT. OBJECT-ITEM-COMMENT is defined as "A comment that
adds information about a specific OBJECT-ITEM." The attributes are:
a.
b.
object-item-comment-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-COMMENT for a specific
OBJECT-ITEM and to distinguish it from all other OBJECT-ITEMCOMMENTs for that OBJECT-ITEM.
c.
object-item-comment-symbol-annotation-text—The character string assigned
to represent symbology annotation for an OBJECT-ITEM in accordance with
symbology representation (e.g. APP-6A).
138
V3.1.4
d.
reporting-data-id—The unique value, or set of characters, assigned to
represent a specific REPORTING-DATA and to distinguish it from all other
REPORTING-DATAs.
5.2.5 The object-item-comment-symbol-annotation-text permits for the addition
of information in a limited 20 character field in accordance with symbology representation
(e.g. APP-6A). The relationship to REPORTING-DATA enables dynamic management of
content in OBJECT-ITEM-COMMENT.
5.2.6 OBJECT-ITEM-COMMENT-CONTENT is defined as " The actual text
that comprises the comments for a single OBJECT-ITEM-COMMENT." The attributes
are:
a.
b.
object-item-comment-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-COMMENT for a specific
OBJECT-ITEM and to distinguish it from all other OBJECT-ITEMCOMMENTs for that OBJECT-ITEM.
c.
object-item-comment-content-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-COMMENT-CONTENT for
a specific OBJECT-ITEM-COMMENT and to distinguish it from all other
OBJECT-ITEM-COMMENT-CONTENTs for that OBJECT-ITEMCOMMENT.
d.
object-item-comment-content-text—The character string assigned
represent a general comment about a specific OBJECT-ITEM.
e.
object-item-comment-content-sequence-ordinal—The integer value that
indicates the relative order of an OBJECT-ITEM-COMMENT-CONTENT
entry.
to
5.2.7 OBJECT-ITEM-COMMENT-CONTENT provides for the addition of staff
remarks and contributes to an improved description for purposes of situational awareness.
Multiple OBJECT-ITEM-COMMENTs with the same object-item-id and object-itemcomment-index and different object-item-comment-content-index records should be
interpreted as one comment against a single OBJECT-ITEM. In that case the respective
values of object-item-comment-content-text have to be concatenated in the order specified
by object-item-comment-content-sequence-ordinal.
5.3
First-Level Subtypes of OBJECT-ITEM
5.3.1 The first level of OBJECT-ITEM categorisation results in five subtypes:
FACILITY, FEATURE, MATERIEL, ORGANISATION, and PERSON. The first-level
subtyping of OBJECT-ITEM mirrors the subtyping of OBJECT-TYPE for purposes of
classification. The attribute-level representation of this structure is illustrated in the figure
below. The detailed specifications are presented in subsequent sections.
139
V3.1.4
OBJECT-ITEM
object-item-id
MATERIEL
FEATURE
feature-id (FK)
materiel-id (FK)
feature-category-code
materiel-category-code
materiel-serial-number-identification-text
materiel-lot-identification-text
materiel-hull-number-text
materiel-mine-requisition-case-number-text
ORGANISATION
organisation-id (FK)
organisation-category-code
FACILITY
facility-id (FK)
PERSON
person-id (FK)
person-birth-datetime
person-blood-type-code
person-gender-code
person-professing-indicator-code
facility-primary-construction-material-code
facility-base-identification-code-text
facility-height-dimension
facility-length-dimension
facility-width-dimension
facility-major-building-type-id (FK)
Figure 50. First-Level Subtypes of OBJECT-ITEM
5.3.2 The table below provides examples of OBJECT-ITEM.
Table 49. OBJECT-ITEM Examples
OBJECT-ITEM
object-item-id
78128
ORGANISATION
1 Bn 2 (US) Inf Bde
3051
ORGANISATION
Enemy unit has been observed
but not identified
57
FEATURE
Rhone River
77709
FEATURE
Task Force Blue Goose FSCL
[Fire Support Coordination Line]
66499
PERSON
General Smith
4311
FACILITY
Blackbush Airfield
384753
FACILITY
MF432 [minefield]
9447
FACILITY
BFO-1210 [obstacle]
102
FACILITY
DIVISION TRUNK SYSTEM
5411334
FACILITY
Kharman Harbour
12950
MATERIEL
M-8986-YT [vehicle]
5.4
FACILITY and Its Subtrees
The specification of FACILITY and its subtypes is presented in three sections due
to the large number of subtypes. Section 5.4.1 specifies the entity FACILITY itself and its
attributes. Section 5.4.2 deals with the following eight subtypes of FACILITY:
140
V3.1.4
AIRFIELD, APRON, BRIDGE, MILITARY-OBSTACLE, NETWORK, RAILWAY,
ROAD, and RUNWAY. Section 5.4.3 specifies HARBOUR and the following related
facilities: ANCHORAGE, BASIN, BERTH, DRY-DOCK, JETTY, QUAY, and
SLIPWAY. Graphic representation of the data structure for Sections 5.4.1 and 5.4.2 is
FACILITY
facility-id (FK)
NETWORK
network-id (FK)
network-category-code
network-subcategory-code
network-architecture-code
network-channel-count
network-maximum-capacity-rate
network-minimum-capacity-rate
network-means-code
network-set-number-count
APRON
apron-id (FK)
apron-weight-bearing-capacity-quantity
AIRFIELD
airfield-id (FK)
airfield-air-traffic-control-presence-indicator-code
airfield-hangar-area-quantity
airfield-instrument-landing-system-presence-indicator-code
airfield-international-civil-aviation-organisation-text
airfield-visual-navigational-aid-indicator-code
MILITARY-OBSTACLE
military-obstacle-id (FK)
BRIDGE
military-obstacle-category-code
bridge-id (FK)
bridge-longest-span-length-dimension
bridge-span-count
bridge-usage-code
ROAD
road-id (FK)
road-category-code
road-shoulder-width-code
road-traffic-density-count
road-weather-condition-category-code
road-quality-code
RAILWAY
railway-id (FK)
railway-track-gauge-code
railway-track-count
railway-train-density-count
railway-block-distance-dimension
railway-sleeper-density-dimension
railway-gross-trailing-load-quantity
railway-maximum-speed-rate
railway-traction-system-code
railway-signal-system-code
railway-signal-system-efficiency-code
RUNWAY
runway-id (FK)
runway-lighting-presence-indicator-code
runway-weight-bearing-capacity-quantity
runway-pavement-classification-number-count
runway-pavement-type-code
runway-pavement-subgrade-category-code
runway-pavement-maximum-tyre-pressure-code
runway-pavement-evaluation-method-code
Figure 51. FACILITY and Its Subtypes Less Harbour Facilities
141
V3.1.4
5.4.1 Specification of FACILITY
5.4.1.1 A FACILITY is defined as "An OBJECT-ITEM that is built, installed or
established to serve some particular purpose and is identified by the service it provides
rather than by its content." In effect, this means that virtually anything man-made is
defined as a FACILITY. The attributes are:
a.
facility-id—The object-item-id of a specific FACILITY (a role name for
object-item-id).
b.
facility-category-code—The specific value that represents the class of
FACILITY. It serves as a discriminator that partitions FACILITY into
subtypes. The domain values are: AIRFIELD; ANCHORAGE; APRON;
BASIN; BERTH; BRIDGE; DRY-DOCK; HARBOUR; JETTY;
MILITARY-OBSTACLE; NETWORK; QUAY; RAILWAY; ROAD;
RUNWAY, SLIPWAY; Not otherwise specified.
c.
facility-primary-construction-material-code—The specific value that
represents the major material used in building the specific FACILITY.
Example domain values are: Asphalt; Cobblestone; Metal; Pebble; Rock; Not
d.
facility-base-identification-code-text—The character string assigned to
represent a designation of the common additional reference given to a
specific military base/facility.
e.
facility-height-dimension—The one-dimensional linear distance representing
the height of a specific FACILITY.
f.
facility-length-dimension—The one-dimensional linear distance representing
the length of a specific FACILITY.
g.
facility-width-dimension—The one-dimensional linear distance representing
the width of a specific FACILITY.
h.
facility-major-building-type-id—The facility-type-id of a specific
FACILITY-TYPE that identifies the class of major buildings in a particular
FACILITY (a role name for object-type-id).
5.4.1.2 The dimension attributes are included in FACILITY to permit the user to
indicate in a simple way the two- or three-dimensional size of an instance of FACILITY
when its geospatial location and orientation is not of interest. The latter specifications are
available, when needed, for any instance of OBJECT-ITEM through a linkage to the
LOCATION submodel, as described in Chapter 12.
5.4.1.3 Guidance on the usage of the foreign key facility-major-building-type-id is
given in Annex G1, Section G1.2.4.
5.4.1.4 The table below provides an example to assist in expressing the relationship
from FACILITY-TYPE to FACILITY (using facility-major-building-type-id). The
FACILITY is defined in Sub-table (a). The associated FACILITY-TYPE is shown in Subtables (b) and (c) and the relationship FACILITY-TYPE to FACILITY (using facilitymajor-building-type-id) is shown in sub-tables (a) and (c).
142
V3.1.4
Table 50. Example of facility-major-building-type-id
(a) OBJECT-ITEM
objectitem-id
398
FACILITY
object-itemname-text
*-id
Village ABC
398
*-categorycode
*-heightdim
*-lengthdim
*-widthdim
Not otherwise
specified
—
—
—
*-majorbuilding-type-id
10742
Note: * = "facility"
(b) OBJECT-ITEM-TYPE
object-item-id
object-type-id
object-item-type-index
reporting-data-id
398
10741
[Village]
1
2711
[Reporting organisation is Unit A]
(c) OBJECT-TYPE
objecttype-id
10741
10742
FACILITY-TYPE
FACILITY-TYPE
No
No
Village
Apartment Building
5.4.1.5 Example instances for FACILITY are illustrated in Table 51. This list of
facilities provides the basis for subsequent examples when instances of subtypes of
FACILITY are discussed.
143
V3.1.4
Table 51. Examples of FACILITY for the First Block
OBJECT-ITEM
objectitem-id
FACILITY
object-item-nametext
*-lengthdimension
*-widthdimension
—
—
—
430
34
17
14
—
—
—
—
—
75
—
—
—
—
25
APRON
BRIDGE
BRIDGE
MILITARYOBSTACLE
MILITARYOBSTACLE
MILITARYOBSTACLE
MILITARYOBSTACLE
MILITARYOBSTACLE
MILITARYOBSTACLE
34
52
227.4
220
220
2737.4
45
11
27.4
1.5
842
2
2
110
0.5
1.2
450
3
1
25
2.5
—
500
500
—
1000
35
102
NETWORK
—
—
—
7731
8100
8200
NETWORK
RAILWAY
RAILWAY
—
—
—
—
—
—
—
—
—
9100
ROAD
—
4473
—
9200
ROAD
—
24140
—
4312
905445
6444
6601
RUNWAY
RUNWAY
RUNWAY
RUNWAY
430
25
15
14
2750
3360
1340
1668
45
45
30
45
4311
905444
6443
6600
4312
1 (UK) Armd Division
Dressing Station
Salzburg
Sevilla
Helsinki Malmi
Bromma
Salzburg Apron H22
4311
905444
6443
6600
4312
905445
5998
7436
Sevilla Apron M87
Vasco de Gama
Golden Gate Bridge
905445
5998
7436
384753
MF 432
384753
435262
MF 433
435262
897433
MF 434
897433
9447
BFO-1210
9447
55662
New York Harbor
55662
55668
Cheasapeake Bay
55668
398
102
7731
8100
8200
9100
9200
4312
905445
6444
6601
DIVISION TRUNK
SYSTEM
World Wide Web
Reading
B&O
Broadway from E.
17th St to Columbus
Circle
Route 50 Beltway Anne Arundel County
Runway 16/34
Runway 09/27
Runway 18/36
Runway 12
*-categorycode
*-heightdimension
*-id
398
Not otherwise
specified
AIRFIELD
AIRFIELD
AIRFIELD
AIRFIELD
APRON
Note: * = "facility"
5.4.2 Eight Subtypes of FACILITY
5.4.2.1
AIRFIELD as a Subtype of FACILITY
5.4.2.1.1 AIRFIELD is defined as "A FACILITY that is an area prepared for the
accommodation (including any buildings, installations, or equipment) of landing and take
off of aircraft." The attributes are:
a.
airfield-id—The facility-id of a specific AIRFIELD (a role name for objectitem-id).
b.
airfield-air-traffic-control-presence-indicator-code—The specific value that
indicates whether a specific AIRFIELD provides air traffic control. The
domain values are: No; Yes.
c.
airfield-hangar-area-quantity—The numeric value that represents the total
hangar area in a specific AIRFIELD. The unit of measure is square metre.
144
V3.1.4
d.
airfield-instrument-landing-system-presence-indicator-code—The specific
value that indicates whether a specific AIRFIELD has an instrument landing
system. The domain values are: No; Yes.
e.
airfield-international-civil-aviation-organisation-text—The character string
assigned to represent the description the international civil aviation
organization (ICAO) identifier commonly used throughout the world for
reference to a known aviation facility.
f.
airfield-visual-navigational-aid-indicator-code—The
specific
value
indicating whether or not the airport has a visual navigational aid displaying
flashes of white or colored light to indicate the location of an airport. The
5.4.2.1.2 Examples of instances of AIRFIELD are shown in the table below. The
table provides additional data for examples corresponding to those cited in the table above.
Table 52. Instances of AIRFIELD
AIRFIELD
airfieldhangarareaquantity
airfield-instrumentlanding-systempresence-indicatorcode
airfieldinternational-civilaviationorganisation-text
airfield-visualnavigationalaid-indicatorcode
airfieldid
airfield-air-trafficcontrolpresenceindicator-code
4311
Yes
2500
Yes
LOWS
Yes
6443
6600
905444
Yes
Yes
Yes
10000
2500
14000
No
Yes
Yes
EFHF
ESSB
LEZL
Yes
Yes
Yes
5.4.2.2
APRON as Subtype of FACILITY
5.4.2.2.1 APRON is defined as "A FACILITY that is an area intended for
parking, loading, unloading and/or servicing." The attributes are:
a.
apron-id—The facility-id of a specific APRON (a role name for object-itemid).
b.
apron-weight-bearing-capacity-quantity—The numeric value that denotes the
maximum gravitational force exerted on the surface of a specific APRON.
The unit of measure is kilograms per square centimetre.
5.4.2.2.2 Examples of instances of APRON are shown in the table below. The
table provides additional data for examples corresponding to those cited in Table 51.
Table 53. Examples of APRON
APRON
apron-id
apron-weight-bearing-capacity-quantity
4312
905445
10000
12500
5.4.2.3
BRIDGE as Subtype of FACILITY
5.4.2.3.1 BRIDGE is defined as "A FACILITY that is a structure (including
overpass and viaduct), fixed or moveable, spanning and/or providing passage over an
object." The attributes are:
145
V3.1.4
a.
bridge-id—The facility-id of a specific BRIDGE (a role name for objectitem-id).
b.
bridge-longest-span-length-dimension—The one-dimensional linear distance
representing the longest span’s length in a specific BRIDGE.
c.
bridge-span-count—The integer value representing the number of sections
that a specific BRIDGE may have.
d.
bridge-usage-code—The specific value that represents the usage of a specific
BRIDGE. Example domain values are: Foot; Railway; Vehicle; Not
5.4.2.3.2 Examples of instances of BRIDGE are shown in the table below. The
Table 54. Instances of BRIDGE
BRIDGE
5.4.2.4
bridge-id
bridge-longest-spanlength-dimension
bridge-spancount
bridge-usagecode
5998
7436
40
100
4
2
Railway/vehicle
Multiple use
MILITARY-OBSTACLE as a Subtype of FACILITY
5.4.2.4.1
Specification of MILITARY-OBSTACLE
5.4.2.4.1.1 MILITARY-OBSTACLE is defined as "A FACILITY designed to stop,
impede, or divert movement of amphibious or ground forces." The concept is intended to
encompass those facilities that are constructed or built to serve specifically as obstacles in
military operations. Natural geographic features that are used as part of the obstacle design
are identified through associations, as discussed in Chapter 9. MILITARY-OBSTACLE
has one subtype—MINEFIELD—as illustrated in the figure below. MINEFIELD in turn
has the two subtypes MINEFIELD-LAND and MINEFIELD-MARITIME in order to
capture the different data specifications that are attendant to the land and maritime mining
operations. Furthermore, the entity MINEFIELD-MARITIME has two child entities—
MINEFIELD-MARITIME-CASUALTY-ESTIMATE and MINEFIELD-MARITIMESUSTAINED-THREAT-MEASURE-OF-EFFECTIVENESS—to enable the presentation
of tabular data of specialised effectiveness for maritime minefields.
146
V3.1.4
MILITARY-OBSTACLE
military-obstacle-id (FK)
MINEFIELD
minefield-id (FK)
minefield-category-code
minefield-identification-text
minefield-mine-spacing-dimension
minefield-destruction-datetime
minefield-category-code
MINEFIELD-MARITIME
MINEFIELD-LAND
minefield-maritime-id (FK)
minefield-land-id (FK)
minefield-land-depth-placement-code
minefield-land-function-code
minefield-land-pattern-code
minefield-land-persistence-code
minefield-land-stopping-power-code
minefield-maritime-depth-placement-code
minefield-maritime-expected-vessel-transit-count
minefield-maritime-function-code
minefield-maritime-mmoe-initial-threat-probability-ratio
minefield-maritime-detection-probability-ratio
minefield-maritime-life-duration
minefield-maritime-mine-detailed-text
minefield-maritime-mines-laid-count
minefield-maritime-bottom-natural-camouflage-code
minefield-maritime-subfunction-code
minefield-maritime-casualty-estimate-index
has
has
minefield-maritime-casualty-estimate-average-count
minefield-maritime-casualty-estimate-given-transit-count
minefield-maritime-sustained-threat-measure-of-effectiveness-index
minefield-maritime-sustained-threat-measure-of-effectiveness-planned-duration
minefield-maritime-sustained-threat-measure-of-effectiveness-probability-ratio
Figure 52. MILITARY-OBSTACLE and Its Subtype MINEFIELD
5.4.2.4.1.2 The attributes of MILITARY-OBSTACLE are:
a.
military-obstacle-id—The facility-id of a specific MILITARY-OBSTACLE
(a role name for object-item-id).
b.
military-obstacle-category-code—The specific value that represents the class
of MILITARY-OBSTACLE. It serves as a discriminator that partitions
MILITARY-OBSTACLE into subtypes. The domain values are:
MINEFIELD; Not otherwise specified.
5.4.2.4.2
Specification of MINEFIELD
5.4.2.4.2.1 MINEFIELD is defined as "A MILITARY-OBSTACLE that is an area
or volume containing mines." (Definition is adapted from two definitions of Minefield in
Joint Pub 1-02). The attributes are:
147
V3.1.4
a.
minefield-id—The military-obstacle-id of a specific MINEFIELD (a role
name for object-item-id).
b.
minefield-category-code—The specific value that represents the class of
MINEFIELD. It serves as a discriminator that partitions MINEFIELD into
subtypes. The domain values are: MINEFIELD-LAND; MINEFIELDMARITIME.
c.
minefield-identification-text—The character string assigned to represent the
designation of a minefield.
d.
minefield-mine-spacing-dimension—The one-dimensional linear distance
representing the distance between the mines emplaced in a specific
MINEFIELD.
e.
minefield-destruction-datetime—The character string representing a point in
time that designates the destruction of a specific MINEFIELD.
5.4.2.4.2.2 Business rule that applies to the use of minefield-destruction-datetime is
given in Annex G1, Section G1.3.1.
5.4.2.4.3
Specification of the Subtypes of MINEFIELD
5.4.2.4.3.1 MINEFIELD-LAND is defined as "A MINEFIELD that is an area of
land containing mines." In land mine warfare, a mine is an explosive or other material,
normally encased, designed to destroy or damage ground vehicles, boats, or aircraft, or
designed to wound, kill, or otherwise incapacitate personnel. The attributes are:
a.
minefield-land-id—The minefield-id of a specific MINEFIELD-LAND (a
role name for object-item-id).
b.
minefield-land-depth-placement-code—The specific value that indicates the
placement of mines with respect to the surface. The domain values are:
Subsurface; Surface; Mixed; Not known.
c.
minefield-land-function-code—The specific value that represents the
intended function of the specific MINEFIELD-LAND. Example domain
values are: Heavy tactical; Nuisance; Phoney.
d.
minefield-land-pattern-code—The specific value that represents the pattern
of a specific MINEFIELD-LAND. The domain values are: Regular
minefield; Regular minefield, thickened with scattered mines; Scattered; Not
known.
e.
minefield-land-persistence-code—The specific value that represents the
option for terminating the effectiveness of a specific MINEFIELD-LAND.
The domain values are: Permanent; Remote activated destruction; Timed
automatic destruction; Not known.
f.
minefield-land-stopping-power-code—The specific value that represents the
stopping power of a particular MINEFIELD-LAND. The domain values are:
High; Low; Medium.
5.4.2.4.3.2 MINEFIELD-MARITIME is defined as "A MINEFIELD that is an area
or volume of water containing mines." In naval mine warfare, a mine is an explosive
148
V3.1.4
device laid in the water with the intention of damaging or sinking ships or of deterring
shipping from entering an area. The attributes are:
a.
minefield-maritime-id—The minefield-id of a specific MINEFIELDMARITIME (a role name for object-item-id).
b.
minefield-maritime-depth-placement-code—The specific value that indicates
the intended depth placement of maritime mines. The domain values are:
Bottom; Surf zone; Surface; Volume; Not known.
c.
minefield-maritime-expected-vessel-transit-count—The
representing the expected number of transiting vessels.
d.
minefield-maritime-function-code—The specific value that represents the
intended function of a specific MINEFIELD-MARITIME. The domain
values are: Defensive; Offensive; Protective.
e.
minefield-maritime-mmoe-initial-threat-probability-ratio—The
numeric
quotient value that represents the planned or estimated likelihood that the
first target ship to enter the minefield will be a casualty. MMOE stands for
Minefield Measurement Of Effectiveness. The value must be in the range
from 0 to 1.
f.
minefield-maritime-detection-probability-ratio—The numeric quotient value
that represents the probability that a mine will be located during MCM
operations. The value must be in the range from 0 to 1.
g.
minefield-maritime-life-duration—The numeric value that represents a
quantity of time in milliseconds for the estimated life of the MINEFIELDMARITIME.
h.
minefield-maritime-mine-detailed-text—The character string assigned to
represent a description of a specific mine.
i.
minefield-maritime-mines-laid-count—The integer value representing the
number of maritime mines laid in a specific MINEFIELD-MARITIME.
j.
minefield-maritime-bottom-natural-camouflage-code—The specific value
that represents the description of the ground of a lake, river, or ocean, or
other body of water with respect to the ability to hide mines on the bottom at
a specific MINEFIELD-MARITIME. Example domain values are: Stable
and smooth flat bottom; Rough bottom; Irregular bottom; Bottom covered in
seaweed.
k.
minefield-maritime-subfunction-code—The specific value that represents the
intended purpose of the MINEFIELD-MARITIME. Example domain values
are: Anti-invasion; Anti-shipping; Blockade; Harassment.
integer
value
5.4.2.4.3.3 MINEFIELD-MARITIME-CASUALTY-ESTIMATE is defined as "An
estimate of the average number of casualties for a given number of vessel transits through
a specific MINEFIELD-MARITIME." The attributes are:
a.
b.
minefield-maritime-casualty-estimate-index—The unique value, or set of
characters, assigned to represent a specific MINEFIELD-MARITIMECASUALTY-ESTIMATE for a specific MINEFIELD-MARITIME and to
149
V3.1.4
distinguish it from all other MINEFIELD-MARITIME-CASUALTYESTIMATEs for that MINEFIELD-MARITIME.
c.
minefield-maritime-casualty-estimate-average-count—The integer value
representing the planned or estimated number of casualties for a specific
MINEFIELD-MARITIME-CASUALTY-ESTIMATE that would occur as an
average in a large number of transit attempts.
d.
minefield-maritime-casualty-estimate-given-transit-count—The integer value
representing the given number of transits for a specific MINEFIELDMARITIME-CASUALTY-ESTIMATE.
5.4.2.4.3.4 MINEFIELD-MARITIME-SUSTAINED-THREAT-MEASURE-OFEFFECTIVENESS is defined as "A measure of effectiveness for a specific MINEFIELDMARITIME in terms of probability of mine function against a transit vessel over a given
period of time." The attributes are:
a.
b.
minefield-maritime-sustained-threat-measure-of-effectiveness-index—The
unique value assigned to represent a specific MINEFIELD-MARITIMESUSTAINED-THREAT-MEASURE-OF-EFFECTIVENESS for a specific
MINEFIELD-MARITIME and to distinguish it from all other MINEFIELDMARITIME-SUSTAINED-THREAT-MEASURE-OF-EFFECTIVENESSs
for that MINEFIELD-MARITIME.
c.
minefield-maritime-sustained-threat-measure-of-effectiveness-plannedduration—The numeric value that represents a quantity of time in
milliseconds for the planned or estimated duration for a specific
MINEFIELD-MARITIME-SUSTAINED-THREAT-MEASURE-OFEFFECTIVENESS.
d.
minefield-maritime-sustained-threat-measure-of-effectiveness-probabilityratio—The numeric quotient value that represents the planned or estimated
likelihood of threat over an extended period for a specific MINEFIELDMARITIME-SUSTAINED-THREAT-MEASURE-OF-EFFECTIVENESS.
The value must be in the range from 0 to 1.
5.4.2.4.4
Examples of MILITARY-OBSTACLEs
Examples of MILITARY-OBSTACLEs are illustrated in the table below in Subtable (a). The category code has only two values: one points to the subtype MINEFIELD
that carries additional information about an obstacle that happens to be a minefield. The
other value (Not otherwise specified) would be used for all other instances of military
obstacles whose characterisation would come from the type side through the attribute
military-obstacle-type-category-code. Sub-table (b) provides amplifying information for
those instances of MILITARY-OBSTACLE that are MINEFIELDs.
150
V3.1.4
Table 55. Examples of MILITARY-OBSTACLEs
(a) MILITARY-OBSTACLE
military-obstacle-id
384753
MINEFIELD
435262
897433
55662
55668
9447
MINEFIELD
MINEFIELD
MINEFIELD
MINEFIELD
(b) MINEFIELD
*-id
*-category-code
*-identification-text
*-mine-spacing-dimension
*-destruction-datetime
384753
435262
897433
55662
55668
MINEFIELD-LAND
MINEFIELD-LAND
MINEFIELD-LAND
MINEFIELD-MARITIME
MINEFIELD-MARITIME
—
—
—
Blue Port Alpha
Red Port Bravo
10 [m]
25 [m]
3 [m]
50 [m]
150 [m]
20070101010101.000
—
—
20070201010101.000
—
Note: * = "minefield"
(c) MINEFIELD-LAND
**-id
**-depthplacement-code
**-functioncode
**-pattern-code
**-persistencecode
**-stoppingpower-code
384753
Mixed
Nuisance
Regular minefield,
thickened with
scattered mines
Remote
activated
destruction
Medium
435262
897433
Surface
Subsurface
Phoney
Protective
Scattered
Regular minefield
Not known
Permanent
Low
High
Note: ** = "minefield-land"
(d) MINEFIELD-MARITIME
***-id
***-depthplacement-code
***-expected-vesseltransit-count
***-functioncode
***-mmoe-initial-threatprobability-ratio
55662
55668
Bottom
Volume
50
27
Defensive
Offensive
0.50
0.83
Note: *** = "minefield-maritime"
***-detectionprobabilityratio
0.10
0.50
***-bottomnaturalcamouflage-code
***subfunctio
n-code
15
Stable and smooth
flat bottom
Antiinvasion
30
—
Blockade
***-lifeduration
***-minedetailed-text
***-mineslaid-count
15552000000
—
7776000000
—
(e) MINEFIELD-MARITIME-CASUALTY-ESTIMATE
minefield-maritime-id
****-index
****-average-count
****-given-transit-count
55662
55668
55662
1
1
2
120
250
85
20
30
90
Note: **** = "minefield-maritime-casualty-estimate"
151
V3.1.4
(f) MINEFIELD-MARITIME-SUSTAINED-THREAT-MEASURE-OF-EFFECTIVENESS
minefield-maritime-id
*****-index
*****-planned-duration
*****-probability-ratio
55662
55662
55668
1
2
1
5184000000
15552000000
7776000000
0.75
0.40
0.60
Note: ***** = "minefield-maritime-sustained-threat-measure-of-effectiveness"
5.4.2.5
NETWORK as a Subtype of FACILITY
NETWORK is closely related to ADDRESS; therefore, specifications of
NETWORK and its child entities are presented in Chapter 8 together with the specification
of ADDRESS and related entities.
5.4.2.6
RAILWAY as a Subtype of FACILITY
5.4.2.6.1 RAILWAY is defined as "A FACILITY that is a track or set of tracks
made of steel rails along which trains run." The attributes are:
a.
railway-id—The facility-id of a specific RAILWAY (a role name for objectitem-id).
b.
railway-track-gauge-code—The specific value that represents the distance
between the internal sides of rails on a RAILWAY line. The domain values
are: Narrow; Standard.
c.
railway-track-count—The integer value representing the number of tracks on
a RAILWAY line.
d.
railway-train-density-count—The integer value representing the maximum
number of trains, which can be moved in each direction over a specified
section of track in a 24 hour period.
e.
railway-block-distance-dimension—The one-dimensional linear distance
representing the minimum length of the passing track intervals for single
track lines or the safety margin related to the signalling system on double or
multiple track lines.
f.
railway-sleeper-density-dimension—The one-dimensional linear distance
representing the average horizontal distance measured from side to side and
perpendicular to the central axis of the gap between two RAILWAY sleepers
(ties).
g.
railway-gross-trailing-load-quantity—The numeric value that represents the
maximum tonnage that can be moved under optimum conditions. The unit of
measure is metric ton.
h.
railway-maximum-speed-rate—The numeric value that denotes the
maximum speed that it is possible to move on a specific RAILWAY. The
unit of measure is kilometres per hour. The specified value must be greater
than or equal to 0 (zero).
i.
railway-traction-system-code—The specific value that represents the motive
power (engine type) that is supported along a specific RAILWAY. The
domain values are: Electric; Not electric.
j.
railway-signal-system-code—The specific value that represents the type of
signal system used for the RAILWAY. Example domain values are: Colour
light; Position light; Semaphore.
152
V3.1.4
k.
railway-signal-system-efficiency-code—The specific value that represents
the percentage value used to compute the inevitable delays caused by the
type of signalling in use on the RAILWAY line. The domain values are: 5065%; 70-75%; 80-85%; 85%.
5.4.2.6.2 Examples of instances of RAILWAY are shown in the table below. The
Table 56. Example of RAILWAY Specifications
RAILWAY
*-id
*-track-gaugecode
*-trackcount
*-train-densitycount
*-block-distancedimension
*-sleeper-densitydimension
8100
8200
Standard
Standard
2
1
100
50
1000
500
1
1
Note: * = "railway"
*-gross-trailingload-quantity
*-maximumspeed-rate
*-traction-systemcode
*-signal-systemcode
*-signal-systemefficiency-code
50
100
100
70
Electric
Not electric
Semaphore
Position light
75%
85%
5.4.2.7
ROAD as a Subtype of FACILITY
5.4.2.7.1 ROAD is defined as "A FACILITY that is a path or way with a
specially prepared surface." The attributes are:
a.
road-id—The facility-id of a specific ROAD (a role name for object-item-id).
b.
road-category-code—The specific value that represents the type of ROAD.
Example domain values are: Lane; Main; Motorway; Pedestrian.
c.
road-shoulder-width-code—The specific value that represents the average
horizontal distance measured from side to side and perpendicular to the
central axis of a specific hard shoulder (lane/area beside a highway for
broken-down or not running vehicles). The domain values are: Over 2m; 1 to
2m; Under 1m.
d.
road-traffic-density-count—The integer value representing the average
number of vehicles that occupy one kilometre of road space, expressed in
vehicles per kilometre.
e.
road-weather-condition-category-code—The specific value that describes the
passability of a ROAD considering the impact of weather on that ROAD.
The domain values are: All-weather; Fair-weather; Limited all-weather.
f.
road-quality-code—The specific value that represents a subjective rating of
the quality of the ROAD. The domain values are: Excellent; Fair; Good;
Poor.
5.4.2.7.2 Examples of instances of ROAD are shown in the table below. The
153
V3.1.4
Table 57. Example of ROAD Specifications
ROAD
*-categorycode
*-shoulderwidth-code
*-traffic-densitycount
*-weather-conditioncategory-code
*-qualitycode
9100
Main
Under 1m
250
All-weather
Excellent
9200
Regional
1 to 2m
50
All-weather
Good
*-id
Note: * = "road"
5.4.2.8
RUNWAY as a Subtype of FACILITY
5.4.2.8.1 RUNWAY is defined as "A FACILITY that is a specifically prepared
surface along which aircraft take off and land." The attributes are:
a.
runway-id—The facility-id of a specific RUNWAY (a role name for objectitem-id).
b.
runway-lighting-presence-indicator-code—The specific value that indicates
whether a specific RUNWAY has runway lighting. The domain values are:
No; Yes.
c.
runway-weight-bearing-capacity-quantity—The numeric value that denotes
the maximum pressure that a specific RUNWAY is capable of carrying. The
unit of measure is kilograms per square centimetre.
d.
runway-pavement-classification-number-count—The
integer
value
representing the pavement Classification Number (PCN), which is part of the
standard ICAO (International Civil Aviation Organization) method of
reporting pavement strength for pavements with bearing strength greater than
5,700 kilograms (12,500 pounds).
e.
runway-pavement-type-code—The specific value that represents the type of
pavement classification, which is part of the standard ICAO (International
Civil Aviation Organization) method of reporting pavement strength for
pavements with bearing strength greater than 5,700 kilograms (12,500
pounds). The domain values are: Flexible; Rigid.
f.
runway-pavement-subgrade-category-code—The specific
value
that
represents the pavement subgrade classification, which is part of the standard
ICAO (International Civil Aviation Organization) method of reporting
pavement strength for pavements with bearing strength greater than 5,700
kilograms (12,500 pounds). The domain values are: High; Low; Medium;
Ultra-low.
g.
runway-pavement-maximum-tyre-pressure-code—The specific value that
represents the pavement maximum tyre pressure classification, which is part
of the standard ICAO (International Civil Aviation Organization) method of
5,700 kilograms (12,500 pounds). The domain values are: High; Low;
Medium; Ultra-low.
h.
runway-pavement-evaluation-method-code—The specific value that
represents the pavement evaluation method classification, which is part of
the standard ICAO (International Civil Aviation Organization) method of
5,700 kilograms (12,500 pounds). The domain values are: By experience;
Technical evaluation.
154
V3.1.4
5.4.2.8.2 Examples of instances of RUNWAY are shown in the table below. The
Table 58. Instances of RUNWAY
RUNWAY
*-id
*-lightingpresenceindicatorcode
*-weightbearingcapacityquantity
*-pavementclassification
-numbercount
*pavementtype-code
*-pavementsubgradecategorycode
*-pavementmaximumtyre-pressurecode
*-pavementevaluationmethodcode
4312
6444
6601
905445
Yes
Yes
Yes
Yes
2500
10000
2500
14000
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
Note: * = "runway"
5.4.3 Harbour-Related Subtypes of FACILITY
The data structure for HARBOUR and harbour-related facilities is illustrated in the
figure below.
5.4.3.1
HARBOUR as Subtype of FACILITY
HARBOUR is defined as "A FACILITY that is a restricted body of water, an
anchorage, or other limited coastal water area and its water approaches from which and in
which shipping operations are projected or supported." The attributes are:
a.
harbour-id—The facility-id of a specific HARBOUR (a role name for objectitem-id).
b.
harbour-airport-near-indicator-code—The specific value that represents
whether an airport is near the HARBOUR. The domain values are: No; Yes.
c.
harbour-approach-channel-depth-dimension—The one-dimensional linear
distance representing the depth maintained by dredging and guaranteed by
the harbour authority of the specific HARBOUR.
d.
harbour-biologically-secure-availability-indicator-code—The specific value
that represents whether the HARBOUR is capable of supplying biologically
secure facilities, to include quarantine facilities. The domain values are: No;
Yes.
e.
harbour-convoy-marshalling-indicator-code—The specific value that
represents whether the HARBOUR is capable of supplying convoymarshalling facilities. The domain values are: No; Yes.
f.
harbour-day-limit-net-explosive-quantity—The numeric value that represents
the maximum net explosive quantity that can be handled at the HARBOUR
during the day. The unit of measure is kilogram.
g.
harbour-night-limit-net-explosive-quantity—The numeric value that
represents the maximum net explosive quantity that can be handled at the
HARBOUR during the night. The unit of measure is kilogram.
h.
harbour-degaussing-indicator-code—The specific value that represents
whether degaussing facilities are available. The domain values are: No; Yes.
155
V3.1.4
FACILITY
HARBOUR
facility-id (FK)
harbour-id (FK)
harbour-airport-near-indicator-code
harbour-approach-channel-depth-dimension
harbour-biologically-secure-availability-indicator-code
harbour-convoy-marshalling-indicator-code
harbour-day-limit-net-explosive-quantity
harbour-night-limit-net-explosive-quantity
harbour-degaussing-indicator-code
harbour-dirty-ballast-indicator-code
harbour-entrance-restrictions-ice-indicator-code
harbour-entrance-restrictions-swell-indicator-code
harbour-entrance-restrictions-text
harbour-estimated-time-of-arrival-indicator-code
harbour-fire-fighting-capability-code
harbour-fire-fighting-indicator-code
harbour-first-port-of-entry-indicator-code
harbour-fresh-water-availability-indicator-code
harbour-lash-indicator-code
harbour-lighterage-availability-indicator-code
harbour-maximum-vessel-draught-dimension
harbour-maximum-vessel-length-dimension
harbour-maximum-vessel-width-dimension
harbour-mean-tidal-current-rate
harbour-passenger-handling-indicator-code
harbour-persistence-code
harbour-overhead-limits-indicator-code
harbour-pilotage-availability-indicator-code
harbour-pilotage-requirement-indicator-code
harbour-prevailing-wind-direction-code
harbour-prevailing-wind-maximum-speed-code
harbour-prevailing-wind-maximum-speed-rate
harbour-refuelling-availability-indicator-code
harbour-refuelling-location-text
harbour-refuelling-type-code
harbour-seasonal-detail-text
harbour-shelter-quality-code
harbour-tanker-facilities-indicator-code
harbour-tidal-mean-neap-range-dimension
harbour-tidal-mean-spring-range-dimension
harbour-tidal-text
harbour-transit-accommodation-indicator-code
harbour-tug-availability-indicator-code
harbour-turning-area-indicator-code
harbour-vehicle-handling-type-code
BASIN
basin-id (FK)
basin-deadweight-tonnage-quantity
basin-depth-dimension
basin-location-text
BERTH
berth-id (FK)
berth-deadweight-tonnage-quantity
berth-depth-dimension
berth-location-text
berth-major-vessel-class-code
berth-maximum-beam-dimension
berth-maximum-capacity-quantity
berth-maximum-vessel-count
berth-day-limit-net-explosive-quantity
berth-night-limit-net-explosive-quantity
berth-rail-availability-indicator-code
berth-roll-on-roll-off-indicator-code
berth-turnaround-time-duration
ANCHORAGE
anchorage-id (FK)
anchorage-bottom-type-code
anchorage-day-limit-net-explosive-quantity
anchorage-draught-high-tide-dimension
anchorage-draught-low-tide-dimension
anchorage-moorings-type-code
anchorage-night-limit-net-explosive-quantity
anchorage-prevailing-wind-direction-code
anchorage-vessel-tonnage-quantity
SLIPWAY
slipway-id (FK)
DRY-DOCK
slipway-gradient-angle
slipway-location-text
dry-dock-id (FK)
dry-dock-boat-lift-capacity-quantity
dry-dock-depth-dimension
dry-dock-location-text
dry-dock-marine-railway-size-code
QUAY
quay-id (FK)
quay-container-handling-type-code
quay-container-maximum-handling-length-dimension
quay-container-maximum-handling-weight-quantity
quay-crane-offloading-lift-quantity
quay-crane-offloading-type-code
quay-day-limit-net-explosive-quantity
quay-draught-dimension
quay-maximum-deadweight-tonnage-quantity
quay-night-limit-net-explosive-quantity
quay-rail-capacity-count
quay-rail-served-indicator-code
quay-storage-code
quay-vessel-maximum-beam-dimension
JETTY
jetty-id (FK)
jetty-day-limit-net-explosive-quantity
jetty-maximum-deadweight-tonnage-quantity
jetty-maximum-draught-dimension
jetty-night-limit-net-explosive-quantity
jetty-rail-capacity-count
jetty-rail-served-indicator-code
jetty-vessel-maximum-beam-dimension
Figure 53. FACILITY and Its Harbour-Related Subtypes
156
V3.1.4
i.
harbour-dirty-ballast-indicator-code—The specific value that represents
whether the port has sufficient facilities for receiving oily or chemically
contaminated dirty ballast. The domain values are: No; Yes.
j.
harbour-entrance-restrictions-ice-indicator-code—The specific value that
represents whether ice is a natural factor restricting the entrance of vessels
into the port. The domain values are: No; Yes.
k.
harbour-entrance-restrictions-swell-indicator-code—The specific value that
represents whether heavy swell is a natural factor restricting the entrance of
vessels into the port. The domain values are: No; Yes.
l.
harbour-entrance-restrictions-text—The character string assigned to
represent the factors other than tide, heavy swell, and ice restricting entrance
into the port.
m.
harbour-estimated-time-of-arrival-indicator-code—The specific value that
represents whether an estimated time of arrival message is required. The
n.
harbour-fire-fighting-capability-code—The specific value that represents the
class of fire fighting capability available at a specific HARBOUR. The
domain values are: Afloat; Ashore; Not otherwise specified.
o.
harbour-fire-fighting-indicator-code—The specific value that represents
whether the HARBOUR is capable of supplying fire-fighting facilities. The
p.
harbour-first-port-of-entry-indicator-code—The
specific
value
that
represents whether the port may be used by a vessel that needs to clear
foreign goods and personnel through Customs and Immigration. The domain
q.
harbour-fresh-water-availability-indicator-code—The specific value that
represents whether the HARBOUR is capable of providing fresh water. The
r.
harbour-lash-indicator-code—The specific value that represents whether the
HARBOUR can support the Lighter Aboard Ship (LASH) transportation
system. The domain values are: No; Yes.
s.
harbour-lighterage-availability-indicator-code—The specific value that
represents the possibility for transferring goods from a ship to a wharf or
another ship using a boat, usu. flat-bottomed at a specific maritime port. The
t.
harbour-maximum-vessel-draught-dimension—The one-dimensional linear
distance representing the maximum draught of vessel that the specific
HARBOUR can accommodate.
u.
harbour-maximum-vessel-length-dimension—The one-dimensional linear
distance representing the maximum length of vessel that the specific
v.
harbour-maximum-vessel-width-dimension—The one-dimensional linear
distance representing the maximum width of vessel that the specific
157
V3.1.4
w.
harbour-mean-tidal-current-rate—The numeric value that denotes the
average velocity of the tidal flow at the specific HARBOUR. The unit of
measure is kilometres per hour. The specified value must be greater than or
equal to 0 (zero).
x.
harbour-passenger-handling-indicator-code—The specific value that
represents whether the HARBOUR is capable of handling passengers. The
y.
harbour-persistence-code—The specific value that represents whether the
HARBOUR is permanent or temporary. The domain values are: Permanent;
Temporary; Not known.
z.
harbour-overhead-limits-indicator-code—The specific value that represents
whether bridge and/or overhead power cables exist. The domain values are:
No; Yes.
aa.
harbour-pilotage-availability-indicator-code—The specific value that
represents whether a pilot is available at the port. The domain values are: No;
Yes.
bb. harbour-pilotage-requirement-indicator-code—The specific value that
represents whether the HARBOUR requires vessels to have a pilot. The
cc.
harbour-prevailing-wind-direction-code—The specific value that represents
the direction of the wind that most frequently occurs for the specific
HARBOUR. Example domain values are: North; South; Northeast; East;
West. The domain value set for this attribute is shared with one or more
other attributes and is defined in the set direction-code.
dd. harbour-prevailing-wind-maximum-speed-code—The specific value that
represents the maximum degree of discrimination or resolution for which the
prevailing wind speed is stated. The domain value set for this attribute is
shared with one or more other attributes and is defined in the set speedprecision-code. The domain values are: Knots; Kilometres per hour; Metres
per second.
ee.
harbour-prevailing-wind-maximum-speed-rate—The numeric value that
denotes the maximum recorded strength of wind at the specific HARBOUR.
The unit of measure is kilometres/hour. The specified value must be greater
ff.
harbour-refuelling-availability-indicator-code—The specific value that
represents whether the HARBOUR has refuelling facilities. The domain
gg. harbour-refuelling-location-text—The character string assigned to represent
a statement of the specific refuelling details that relate to the specific
HARBOUR.
hh. harbour-refuelling-type-code—The specific value that represents the
refuelling means available at the specific HARBOUR. The domain values
are: Bunkering, barge; Fixed installation; Tanker, road; Not otherwise
specified.
158
V3.1.4
ii.
harbour-seasonal-detail-text—The character string assigned to represent a
statement of the specific seasonal details that relate to the specific
HARBOUR.
jj.
harbour-shelter-quality-code—The protection provided from wind, sea, and
swell in the area where normal port operations are conducted. The domain
values are: Excellent; Fair; Good; Poor.
kk. harbour-tanker-facilities-indicator-code—The specific value that represents
the availability of facilities to process tankers at a specific HARBOUR. The
ll.
harbour-tidal-mean-neap-range-dimension—The one-dimensional linear
distance representing the average range just after the first and third quarters
of the moon when there is the least difference between high and low water
for a specific HARBOUR.
mm. harbour-tidal-mean-spring-range-dimension—The one-dimensional linear
distance representing the average range just after the new and full moon
when there is the greatest difference between high and low water for a
specific HARBOUR.
nn. harbour-tidal-text—The character string assigned to represent a statement of
the specific tidal details that relate to the specific HARBOUR.
oo. harbour-transit-accommodation-indicator-code—The specific value that
represents whether the HARBOUR is capable of supplying transit
accommodation facilities. The domain values are: No; Yes.
pp. harbour-tug-availability-indicator-code—The specific value that represents
the availability of tugs at a specific HARBOUR. The domain values are: No;
Yes.
qq. harbour-turning-area-indicator-code—The specific value that represents
whether there is a turning basin or other water area available in a specific
HARBOUR. The domain values are: No; Yes.
rr.
harbour-vehicle-handling-type-code—The specific types of facilities
available at a specified HARBOUR. The domain values are: Roll on/roll off
fixed link span; Roll on/roll off floating ramp; Roll on/roll off moveable link
span; Not known; Not otherwise specified.
5.4.3.2
ANCHORAGE as Subtype of FACILITY
ANCHORAGE is defined as "A FACILITY that is a place where vessels anchor."
The attributes are:
a. anchorage-id—The facility-id of a specific ANCHORAGE (a role name for
object-item-id).
b. anchorage-bottom-type-code—The specific value that represents the
description of the ground under the water of a lake, ocean, or other body of
water at a specific ANCHORAGE. Example domain values are: Clay; Mud;
Rock; Sand.
c. anchorage-day-limit-net-explosive-quantity—The
numeric
value
that
ANCHORAGE during the day. The unit of measure is kilogram.
159
V3.1.4
d. anchorage-draught-high-tide-dimension—The one-dimensional linear distance
representing the maximum draught of vessel at high tide that the specific
ANCHORAGE can accommodate.
e. anchorage-draught-low-tide-dimension—The one-dimensional linear distance
representing the maximum draught of vessel at low tide that the specific
ANCHORAGE can accommodate.
f.
anchorage-moorings-type-code—The specific value that represents the class
of mooring available at the specific ANCHORAGE. The domain values are:
Buoy; Dolphin; Fixed post; Not otherwise specified.
g. anchorage-night-limit-net-explosive-quantity—The numeric value that
ANCHORAGE during the night. The unit of measure is kilogram.
h. anchorage-prevailing-wind-direction-code—The specific value that represents
the direction of the wind that most frequently occurs for the specific
ANCHORAGE. Example domain values are: North; South; Northeast; East;
West. The domain value set for this attribute is shared with one or more other
attributes and is defined in the set direction-code.
i.
anchorage-vessel-tonnage-quantity—The numeric value that represents the
maximum tonnage of a vessel that can be accommodated at a specific
ANCHORAGE. The unit of measure is metric ton.
5.4.3.3
BASIN as Subtype of FACILITY
BASIN is defined as "A FACILITY that is an open area of water, usually artificial
and enclosed by dock gates lined with wharves, warehouses and berths to enable vessels to
load and unload." The attributes are:
a. basin-id—The facility-id of a specific BASIN (a role name for object-item-id).
b. basin-deadweight-tonnage-quantity—The numeric value that represents the
maximum deadweight tonnage that can be accommodated for a vessel at the
specific BASIN. The unit of measure is metric ton.
c. basin-depth-dimension—The one-dimensional linear distance representing the
depth of water available at the BASIN at low tide.
d. basin-location-text—The character string assigned to represent a statement of
the details that relate to the specific BASIN.
5.4.3.4
BERTH as Subtype of FACILITY
BERTH is defined as "A FACILITY that is a space or length in the water at a
harbour allocated to or reserved for a vessel to dock and moor for loading or unloading."
The attributes are:
a. berth-id—The facility-id of a specific BERTH (a role name for object-itemid).
b. berth-deadweight-tonnage-quantity—The numeric value that represents the
maximum deadweight tonnage that can be accommodated for a vessel at the
specific BERTH. The unit of measure is metric ton.
160
V3.1.4
c. berth-depth-dimension—The one-dimensional linear distance representing the
depth of water available at the BERTH at low tide.
d. berth-location-text—The character string assigned to represent a statement of
the details that relate to the specific BERTH.
e. berth-major-vessel-class-code—The specific value that represents the class of
vessels to be serviced. The domain values are: Barge; Breakbulk; Container;
RoRo; Not otherwise specified.
f.
berth-maximum-beam-dimension—The one-dimensional linear distance
representing the width athwartships, including all projections, of the largest
vessel a specific BERTH can process.
g. berth-maximum-capacity-quantity—The numeric value that represents the
maximum tonnage a specific BERTH can process per day. The unit of
measure is Gross Registered Tonnage (GRT).
h. berth-maximum-vessel-count—The integer value representing the maximum
number of vessels a specific BERTH can process at the same time.
i.
berth-day-limit-net-explosive-quantity—The numeric value that represents the
maximum net explosive quantity that can be handled at the BERTH during the
day. The unit of measure is kilogram.
j.
berth-night-limit-net-explosive-quantity—The numeric value that represents
the maximum net explosive quantity that can be handled at the BERTH during
the night. The unit of measure is kilogram.
k. berth-rail-availability-indicator-code—The specific value that represents the
availability of railroad transportation capability at a specific BERTH. The
l.
berth-roll-on-roll-off-indicator-code—The specific value that represents
whether or not the BERTH has roll on/roll off capabilities. The domain values
are: No; Yes.
m. berth-turnaround-time-duration—The character string that represents a time
period representing the average units of time for the process of docking,
unloading, reloading and undocking a ship for a specific BERTH.
5.4.3.5
DRY-DOCK as Subtype of FACILITY
DRY-DOCK is defined as "A FACILITY that provides an enclosure for
maintenance, building or repairing ships, from which water can be pumped out." The
attributes are:
a. dry-dock-id—The facility-id of a specific DRY-DOCK (a role name for
object-item-id).
b. dry-dock-boat-lift-capacity-quantity—The numeric value that represents the
maximum tonnage of a boat-lift that can be utilised to remove a vessel from a
specific DRY-DOCK. The unit of measure is metric ton.
c. dry-dock-depth-dimension—The one-dimensional linear distance representing
the depth of water available at the DRY-DOCK when the dock is full of water.
d. dry-dock-location-text—The character string assigned to represent a statement
of the details that relate to the specific DRY-DOCK.
161
V3.1.4
e. dry-dock-marine-railway-size-code—The specific value that represents the
bearing capacity of the underwater railway in the DRY-DOCK. The domain
values are: Large; Medium; Small.
5.4.3.6
JETTY as Subtype of FACILITY
JETTY is defined as "A FACILITY that is a platform that may be fixed or floating
extending from a shore, normally attached to a wharf or the shore, and which allows
access to a vessel lying alongside, used to secure, protect and provide landing and docking
for vessels." The attributes are:
a. jetty-id—The facility-id of a specific JETTY (a role name for object-item-id).
b. jetty-day-limit-net-explosive-quantity—The numeric value that represents the
maximum net explosive quantity that can be handled at the JETTY during the
c. jetty-maximum-deadweight-tonnage-quantity—The numeric value that
represents the maximum deadweight tonnage for a vessel at the specific
JETTY. The unit of measure is metric ton.
d. jetty-maximum-draught-dimension—The one-dimensional linear distance
representing the maximum draught of vessel that the specific JETTY can
accommodate.
e. jetty-night-limit-net-explosive-quantity—The numeric value that represents
the maximum net explosive quantity that can be handled at the JETTY during
f.
jetty-rail-capacity-count—The integer value that represents the maximum
number of goods/freight cars that the JETTY can accommodate at the same
time.
g. jetty-rail-served-indicator-code—The specific value that represents whether
the JETTY has railway facilities. The domain values are: No; Yes.
h. jetty-vessel-maximum-beam-dimension—The one-dimensional linear distance
representing the maximum beam or width of vessel that the specific JETTY
can accommodate.
5.4.3.7
QUAY as Subtype of FACILITY
QUAY is defined as "A FACILITY that is a solidly constructed platform, usually
parallel to the shoreline of navigable water, alongside which a vessel can be docked or
berthed and, on which, the vessel can be accessed and cargo can be loaded or unloaded on
one side of the vessel only." The attributes are:
a. quay-id—The facility-id of a specific QUAY (a role name for object-item-id).
b. quay-container-handling-type-code—The specific value that represents the
class of container handling equipment available at a specific QUAY. Example
domain values are: Container straddle lift; Reach stacker; Shunting/terminal
tractor.
c. quay-container-maximum-handling-length-dimension—The one-dimensional
linear distance representing the maximum length of a container that can be
handled at the QUAY.
162
V3.1.4
d. quay-container-maximum-handling-weight-quantity—The numeric value that
represents the maximum container weight that can be handled at the QUAY.
The unit of measure is kilogram.
e. quay-crane-offloading-lift-quantity—The numeric value that represents the
maximum weight that can be handled by a crane at the QUAY. The unit of
measure is kilogram.
f.
quay-crane-offloading-type-code—The specific value that represents the class
of crane offloading equipment available at a specific QUAY. Example domain
values are: Floating crane; Railed crane; Wheeled crane.
g. quay-day-limit-net-explosive-quantity—The numeric value that represents the
maximum net explosive quantity that can be handled at the QUAY during the
h. quay-draught-dimension—The one-dimensional linear distance representing
the maximum draught of vessel that the specific QUAY can accommodate.
i.
quay-maximum-deadweight-tonnage-quantity—The numeric value that
represents the maximum deadweight tonnage that can be accommodated for a
vessel at the specific QUAY. The unit of measure is metric ton.
j.
quay-night-limit-net-explosive-quantity—The numeric value that represents
the maximum net explosive quantity that can be handled at the QUAY during
k. quay-rail-capacity-count—The integer value representing the maximum
number of goods/freight cars that the QUAY can accommodate at the same
time.
l.
quay-rail-served-indicator-code—The specific value that represents whether
the QUAY has railway facilities. The domain values are: No; Yes.
m. quay-storage-code—The specific value that represents the class of storage
facilities available at a specific QUAY. Example domain values are: Grain
silo; Munitions and explosives; Warehouse.
one-dimensional
linear
n. quay-vessel-maximum-beam-dimension—The
distance representing the maximum beam or width of vessel that the specific
QUAY can accommodate.
5.4.3.8
SLIPWAY as Subtype of FACILITY
SLIPWAY is defined as "A FACILITY that provides a sloping surface or inclined
structure leading down to the water." The attributes are:
a. slipway-id—The facility-id of a specific SLIPWAY (a role name for objectitem-id).
b. slipway-gradient-angle—The rotational measurement of a gradient, measured
between the top of the slipway to the surface of the water, for a specific
SLIPWAY.
c. slipway-location-text—The character string assigned to represent a statement
of the details that relate to the specific SLIPWAY.
163
V3.1.4
5.4.3.9
Examples for Harbour-Related Facilities
Examples are provided in the table below.
Table 59. Examples of FACILITY for the Second Block
(a) OBJECT-ITEM
FACILITY (Harbour)
object-itemid
facilityid
facilitycategory-code
facilityheightdimension
facilitylengthdimension
facilitywidthdimension
5411334
5411335
5411336
Kharman Harbour
Portsmouth Harbour
Marchwood
5411334
5411335
5411336
HARBOUR
HARBOUR
HARBOUR
24
40
23
5230
4100
1800
4821
2300
1100
(b) OBJECT-ITEM
SLIPWAY
object-item-id
object-itemname-text
slipwayid
slipwaygradient-angle
slipway-locationtext
655280
655281
Daedalus One
Barbican
655280
655281
15
18
Lee-on-the-Solent
Plymouth
5.5
FEATURE Subtree
Because the specification encompasses a broad range of objects, FEATURE has
been subtyped into three categories: CONTROL-FEATURE, GEOGRAPHIC-FEATURE,
and METEOROLOGIC-FEATURE, as illustrated in the figure below.
FEA TURE
feature-id (FK)
f eature-category-code
CONTROL-FEATURE
METEOROLOGIC-FEA TURE
control-feature-id (FK)
meteorologic-f eature-id (FK)
control-feature-category-c ode
meteorologic-f eature-category-code
meteorologic-f eature-interpretation-code
meteorologic-f eature-probability-ratio
meteorologic-f eature-source-code
GEOGRAPHIC-FEATURE
geographic-feature-id (FK)
geographic-feature-bottom-hardnes s-code
geographic-feature-bottom-penetration-quantity
geographic-feature-solid-s urf ace-composition-code
geographic-feature-surfac e-category-code
geographic-feature-terrain-code
geographic-feature-vegetation-code
geographic-feature-vegetation-subcategory-code
Figure 54. FEATURE and Its First-Level Subtypes
5.5.1 Specification of FEATURE
5.5.1.1 FEATURE is defined as "An OBJECT-ITEM that encompasses
meteorological, geographic, and control features of military significance." In other words,
164
V3.1.4
FEATUREs are used to describe characteristics, phenomena, or other similar objects that
are associated with a geographic location. These entities are of interest in the operational
arena, and may be administratively defined or occur naturally. The attributes are:
a.
feature-id—The object-item-id of a specific FEATURE (a role name for
object-item-id).
b.
feature-category-code—The specific value that represents the class of
FEATURE. It serves as a discriminator that partitions FEATURE into
subtypes. The domain values are: CONTROL-FEATURE; GEOGRAPHICFEATURE; METEOROLOGIC-FEATURE; Not otherwise specified.
5.5.1.2 The table below provides example instances for FEATURE.
Table 60. Example Instances for FEATURE
OBJECT-ITEM
FEATURE
object-item-id
feature-id
11245
674
Phase Line Tango
Rhone River
11245
674
CONTROL-FEATURE
GEOGRAPHIC-FEATURE
45932
83576
37622
45932
83576
37622
ROUTE
ROUTE
ROUTE-SEGMENT
93444
A-9
Appalachian Trail
Flight path New York to
London
Eiffel Tower restriction
93444
96412
Approach direction west
96412
AIRSPACE-CONTROLMEANS
APPROACH-DIRECTION
679
675
676
677
El niño
Mount Everest
Everglades
Black Forest
679
675
676
677
GEOGRAPHIC-FEATURE
GEOGRAPHIC-FEATURE
GEOGRAPHIC-FEATURE
5.5.2 CONTROL-FEATURE as a Subtype of FEATURE
CONTROL-FEATURE describes objects which are of interest but which do not
physically exist (e.g., boundary line, airspace coordination area). CONTROL-FEATURE
has four subtypes-AIRSPACE-CONTROL-MEANS, APPROACH-DIRECTION,
ROUTE and ROUTE-SEGMENT-that have their own unique properties. ROUTESEGMENT has a further subtyping structure represented by-AIR-ROUTE-SEGMENT.
The data structure is illustrated in the figure below.
165
V3.1.4
CONTROL-FEATURE
control-feature-category-code
APPROACH-DIRECTION
ROUTE-SEGMENT
approach-direction-id (FK)
route-segment-id (FK)
approach-direction-category-code
approach-direction-angle-text
route-segment-category-code
route-segment-mobility-code
route-segment-mode-of-transportation-code
route-segment-category-code
airspace-control-means-id (FK)
airspace-control-means-transit-instruction-text
ROUTE
AIR-ROUTE-SEGMENT
route-id (FK)
air-route-segment-id (FK)
route-direction-usage-code
route-mobility-code
route-mode-of-transportation-code
air-route-segment-required-navigation-performance-code
air-route-segment-civil-military-code
air-route-segment-international-route-code
air-route-segment-maintained-speed-rate
air-route-segment-description-text
Figure 55. CONTROL-FEATURE and Its Subtypes
5.5.2.1
Specification of CONTROL-FEATURE
5.5.2.1.1 CONTROL-FEATURE is defined as "A non-tangible FEATURE of
military interest that is administratively specified, may be represented by a geometric
figure, and is associated with the conduct of military operations." This expresses the idea
of administratively defined objects created by military authorities and controlling or
affecting the activities of military formations. The attributes are:
a.
control-feature-id—The feature-id of a specific CONTROL-FEATURE (a
b.
control-feature-category-code—The specific value that represents the class
of CONTROL-FEATURE. It serves as a discriminator that partitions
CONTROL-FEATURE into subtypes. The domain values are: AIRSPACECONTROL-MEANS; APPROACH-DIRECTION, ROUTE; Not otherwise
specified; ROUTE-SEGMENT.
166
V3.1.4
5.5.2.1.2 The table below provides example instances for CONTROLFEATURE.
Table 61. Example Instances for CONTROL-FEATURE
CONTROL-FEATURE
control-feature-id
45932
83576
37622
ROUTE
ROUTE
ROUTE-SEGMENT
93444
96412
APPROACH-DIRECTION
5.5.2.2
ROUTE as a Subtype of CONTROL-FEATURE
5.5.2.2.1 ROUTE is defined as "A CONTROL-FEATURE that is the prescribed
course to be travelled from a specific point of origin to a specific destination." The
attributes are:
a.
route-id—The control-feature-id of a specific ROUTE (a role name for
object-item-id).
b.
route-direction-usage-code—The specific value that represents the assigned
direction for the traffic on the route. The domain values are: Alternating;
One-way; Two-way.
c.
route-mobility-code—The specific value that indicates the suitability of a
specific ROUTE for movement. The domain values are: Foot; Tracked;
Wheeled, all road; Wheeled, general; Wheeled and tracked; Not known. The
and is defined in the set mobility-code.
d.
route-mode-of-transportation-code—The specific value that indicates the
mode of transportation of a specific ROUTE. The domain values are: Air;
Inland waterway; Multi mode; Pipeline; Rail; Road; Sea; Terrain. The
and is defined in the set mode-of-transportation-code.
5.5.2.2.2 Business rules that specify allowable combinations of values for routemobility-code and route-mode-of-transportation-code are specified in Annex G2, Section
G2.3.1.
5.5.2.2.3 Example instances for ROUTE are provided in the table below. The
table specifies that a route identified by the route-id 45932 is capable of carrying wheeled
or tracked vehicles with direction of travel alternating. The second route identified by
route-id 83576 is suitable only for foot traffic in both directions.
Table 62. ROUTE Example Instances
ROUTE
route-id
route-direction-usage-code
route-mobility-code
route-mode-of-transportation-code
45932
83576
Alternating
Two-way
Wheeled and tracked
Foot
Road
Terrain
167
V3.1.4
5.5.2.3
ROUTE-SEGMENT as a Subtype of CONTROL-FEATURE
5.5.2.3.1 ROUTE-SEGMENT is defined as "A portion of a route usually without
an intermediate stop, as defined by two consecutive significant points." The attributes are:
a.
route-segment-id—The control-feature-id of a specific ROUTE-SEGMENT
b.
route-segment-category-code—The specific value that represents the class of
ROUTE-SEGMENT. It serves as a discriminator that partitions ROUTESEGMENT into subtypes. The domain values are: AIR-ROUTESEGMENT; Not otherwise specified.
c.
route-segment-mobility-code—The specific value that indicates the
suitability of a specific ROUTE-SEGMENT for movement. The domain
values are: Foot; Tracked; Wheeled, all road; Wheeled, general; Wheeled
and tracked; Not known. The domain value set for this attribute is shared
with one or more other attributes and is defined in the set mobility-code.
d.
route-segment-mode-of-transportation-code—The specific value that
indicates the mode of transportation of a specific ROUTE-SEGMENT. The
domain values are: Air; Inland waterway; Multi mode; Pipeline; Rail; Road;
Sea; Terrain. The domain value set for this attribute is shared with one or
more other attributes and is defined in the set mode-of-transportation-code.
5.5.2.3.2 Business rules that specify allowable combinations of values for routesegment-mobility-code and route-segment-mode-of-transportation-code are specified in
Annex G2, Section G2.3.2.
5.5.2.3.3 An example of ROUTE-SEGMENT is provided in the table below. The
table specifies that a route segment identified by the route-id 37622 has certain special
characteristics.
5.5.2.3.4 ROUTE-SEGMENT has a subtype entity to deal with specific
requirements related to the air community.
Table 63. ROUTE-SEGMENT Instance
ROUTE-SEGMENT
*-id
*-category-code
*-mobility-code
*-mode-of-transportation-code
37622
AIR-ROUTE-SEGMENT
Not known
Air
Note: * = "route-segment"
5.5.2.4
AIR-ROUTE-SEGMENT as a Subtype of ROUTE-SEGMENT
5.5.2.4.1 AIR-ROUTE-SEGMENT is defined as "A portion of a route to be
flown usually without an intermediate stop, as defined by two consecutive significant
points." The attributes are:
a.
air-route-segment-id—The route-segment-id of a specific AIR-ROUTESEGMENT (a role name for object-item-id).
b.
air-route-segment-required-navigation-performance-code—The
specific
value that represents the required navigation performance when flying routes
for which external route navigation aids are not provided. The domain values
are: 1; 4; 5; 6; 12.5; 20.
168
V3.1.4
c.
air-route-segment-civil-military-code—The specific value that represents the
civil/military status of the AIR-ROUTE-SEGMENT. The domain values are:
Both; Civil; Military.
d.
air-route-segment-international-route-code—The
specific
value
that
represents the domestic/international status of the AIR-ROUTE-SEGMENT.
The domain values are: Domestic; International.
e.
air-route-segment-maintained-speed-rate—The numeric value that denotes
the speed of movement to be maintained between route points. The unit of
measure is kilometres per hour. The specified value must be greater than or
equal to 0 (zero).
f.
air-route-segment-description-text—The character string assigned
represent the description of specific AIR-ROUTE-SEGMENT.
to
5.5.2.4.2 An example of AIR-ROUTE-SEGMENT is provided in the table
below.
Table 64. AIR-ROUTE-SEGMENT Instance
AIR-ROUTE-SEGMENT
*-id
*-required-navigationperformance-code
*-civilmilitary-code
*-internationalroute-code
*-maintainedspeed-rate
*-description-text
37622
20
Civil
International
—
—
Note: * = "air-route-segment"
5.5.2.5
AIRSPACE-CONTROL-MEANS as a Subtype of CONTROLFEATURE
5.5.2.5.1 AIRSPACE-CONTROL-MEANS is defined as "A CONTROLFEATURE that reserves airspace for specific airspace users, restricts the action of airspace
users, controls the actions of specific airspace users, and/or requires airspace users to
accomplish specific actions." The attributes are:
a.
airspace-control-means-id—The control-feature-id of a specific AIRSPACECONTROL-MEANS (a role name for object-item-id).
b.
airspace-control-means-transit-instruction-text—The
character
string
assigned to represent the specific transit instructions for a specific airspace.
5.5.2.5.2 Example of AIRSPACE-CONTROL-MEANS is provided in the table
below. In order to specify that a route segment identified by the route-id 37622 has certain
special characteristics there would have to be an entry in the OBJECT-ITEMASSOCIATION entity.
Table 65. AIRSPACE-CONTROL-MEANS Instance
airspace-control-means-id
airspace-control-means-transit-instruction-text
93444
No high-speed passes through Eiffel Tower
5.5.2.6
APPROACH-DIRECTION as a Subtype of CONTROL-FEATURE
5.5.2.6.1 APPROACH-DIRECTION is defined as "A CONTROL-FEATURE
that specifies approach directional details for takeoff and landing." The intent of this entity
169
V3.1.4
is to indicate the landing direction on a given runway. The runway itself is specified as an
instance of FACILITY. The attributes of APPROACH-DIRECTION are:
a.
approach-direction-id—The control-feature-id of a specific APPROACHDIRECTION (a role name for object-item-id).
b.
approach-direction-category-code—The specific value that differentiates
between left, right and centre parallel runways, Short Takeoff and Landing
(STOL) or true as applicable. The domain values are: Centre; Left; Right;
STOL; True.
c.
approach-direction-angle-text—The character string assigned to represent a
runway in terms of a whole number nearest one-tenth of the magnetic
azimuth of the centreline of the runway, measured clockwise from magnetic
north (where six degrees is used as the break off point for the next highest
number).
5.5.2.6.2 The concept of APPROACH-DIRECTION is illustrated in the figure
below for two parallel runways that are oriented approximately from northeast to
southwest. If the landing or takeoff is to be from northeast to southwest, then either
direction 23L or 23R is to be used. This corresponds to magnetic azimuth of
approximately 230 degrees. If the landing or takeoff is to be from southwest to northeast,
then either direction 5L or 5R is to be used. In this case, the direction corresponds to
magnetic azimuth of approximately 50 degrees.
Figure 56. Illustration of Approach Direction for Runway
170
V3.1.4
5.5.2.6.3 The specifications of instances of APPROACH-DIRECTION that
correspond to the figure are provided in the table below.
Table 66. Example of APPROACH-DIRECTION Specification
APPROACH-DIRECTION
approachdirection-id
approach-directioncategory-code
approach-directionangle-text
96412
96413
96414
96415
Left
Right
Left
Right
23 L
23 R
3L
3R
5.5.2.7
RUNWAY-APPROACH-DIRECTION-ASSOCIATION
5.5.2.7.1 RUNWAY-APPROACH-DIRECTION-ASSOCIATION is defined as
"A relationship of a subject RUNWAY with an object APPROACH-DIRECTION." The
specification is illustrated in the figure below.
5.5.2.7.2 The attributes of RUNWAY-APPROACH-DIRECTIONASSOCIATION are:
a.
runway-id—The facility-id of a specific RUNWAY (a role name for objectitem-id).
b.
approach-direction-id—The control-feature-id of a specific APPROACHDIRECTION (a role name for object-item-id).
c.
runway-approach-direction-association-slope-ratio—The numeric quotient
value that represents the incline of the runway seen from the direction of the
APPROACH-DIRECTION as proportion of vertical change with respect to
the length of the runway. The value must be in the range from -.09 to +.09.
Note: A negative value indicates a downward slope.
d.
runway-approach-direction-association-landing-distance-dimension—The
one-dimensional linear distance representing the length of the runway that is
declared available and suitable for the ground run of an aircraft landing. The
unit of measurement is feet.
e.
runway-approach-direction-association-takeoff-distance-dimension—The
one-dimensional linear distance representing the length of the available
takeoff run plus the length of the overrun, if available, for an aircraft to
takeoff. The unit of measurement is feet.
5.5.2.7.3 A specific RUNWAY may have up to two APPROACH-DIRECTIONs.
171
V3.1.4
OBJECT-ITEM
object-item-id
FACILITY
FEATURE
facility-id (FK)
feature-id (FK)
CONTROL-FEATURE
RUNWAY
runway-id (FK)
runway-lighting-presence-indicator-code
runway-weight-bearing-capacity-quantity
runway-pavement-classification-number-count
runway-pavement-type-code
runway-pavement-subgrade-category-code
runway-pavement-maximum-tyre-pressure-code
runway-pavement-evaluation-method-code
APPROACH-DIRECTION
approach-direction-category-code
approach-direction-angle-text
is-the-object-of
is-the-subject-of
RUNWAY-APPROACH-DIRECTION-ASSOCIATION
runway-id (FK)
runway-approach-direction-association-slope-ratio
runway-approach-direction-association-landing-distance-dimension
runway-approach-direction-association-takeoff-distance-dimension
Figure 57. Specifying Runway Approach Direction
5.5.3 Subtype of FEATURE: GEOGRAPHIC-FEATURE
5.5.3.1 GEOGRAPHIC-FEATURE is defined as "A FEATURE describing terrain
characteristics to which military significance is attached." In general, this represents any
natural object or configuration of ground or water represented on a map or chart. The
attributes are:
a.
geographic-feature-id—The feature-id of a specific GEOGRAPHICFEATURE (a role name for object-item-id).
b.
geographic-feature-bottom-hardness-code—A specific value that represents
the subjective indication obtained by a diver of the hardness of the
172
V3.1.4
liquid/solid surface interface and is the result of a single arm thrust. Example
domain values are: Arm penetrates to elbow; Arm penetrates to wrist.
c.
geographic-feature-bottom-penetration-quantity—The numeric value that
represents the depth to which a diver is able to thrust his fist or fingers into
the surface of the solid/liquid interface. The unit of measure is metres.
d.
geographic-feature-solid-surface-composition-code—The specific value that
represents the composition of the surface of the GEOGRAPHIC-FEATURE.
Example domain values are: Coral; Ice; Sand; Snow.
e.
geographic-feature-surface-category-code—The
specific
value
that
represents the type of surface of the GEOGRAPHIC-FEATURE. The
domain values are: Liquid surface; Solid surface; Not otherwise specified.
f.
geographic-feature-terrain-code—The specific value that represents a tract of
land. Example domain values are: Flat; Hilly; Undulating.
g.
geographic-feature-vegetation-category-code—The specific value that
represents the general vegetation class on a specific GEOGRAPHICFEATURE. Example domain values are: Bare; Jungle; Plant cultivation;
Woodland. The domain value set for this attribute is shared with one or more
other attributes and is defined in the set vegetation-category-code.
h.
geographic-feature-vegetation-subcategory-code—The specific value that
represents the detailed vegetation class on a specific GEOGRAPHICFEATURE. Example domain values are: Desert; Forest; Jungle,
coastal/estuary; Tundra. The domain value set for this attribute is shared with
one or more other attributes and is defined in the set vegetation-subcategorycode.
5.5.3.2 The business rules for relating geographic-feature-vegetation-categorycode and geographic-feature-vegetation-subcategory-code for GEOGRAPHICFEATURE-TYPE are specified in Annex G2, Section G2.3.3.
5.5.3.3 Examples of GEOGRAPHIC-FEATUREs are listed in the table below.
Table 67. GEOGRAPHIC-FEATURE Instance
GEOGRAPHIC-FEATURE
*-id
*-bottom-hardness-code
*-bottom-penetration-quantity
674
—
—
675
676
677
678
679
—
—
—
Arm penetrates to elbow
Arm penetrates to wrist
—
—
—
0.5
0.2
Note: * = "geographic-feature"
173
*-solid-surfacecomposition-code
*-surfacecategory-code
Not otherwise
specified
Coral
Snow
Earth
Earth
Sand
Liquid surface
Liquid surface
Solid surface
Solid surface
Solid surface
Solid surface
V3.1.4
*-terrain-code
*-vegetation-categorycode
*-vegetation-subcategory-code
Mountainous
Wetlands
Not known
Not known
Marsh
—
—
Flat
Not known
Not known
Rangeland
Not known
Bare
Grassland
—
—
5.5.4 METEOROLOGIC-FEATURE as a Subtype of FEATURE
METEOROLOGIC-FEATURE has an incomplete subtyping comprising seven
subtypes: ATMOSPHERE, CLOUD-COVER, ICING, LIGHT, PRECIPITATION,
VISIBILITY, and WIND. Each instance of METEOROLOGIC-FEATURE (and one of its
subtypes) describes a single meteorological condition. The subtype structure of
METEOROLOGIC-FEATURE is illustrated in the figure below.
meteorologic-feature-id (FK)
meteorologic-feature-category-code
meteorologic-feature-interpretation-code
meteorologic-feature-probability-ratio
meteorologic-feature-source-code
meteorologic-feature-category-code
ATMOSPHERE
CLOUD-COVER
atmosphere-id (FK)
cloud-cover-id (FK)
atmosphere-humidity-ratio
atmosphere-inversion-layer-code
atmosphere-pressure-quantity
atmosphere-pressure-system-category-code
atmosphere-temperature
atmosphere-temperature-gradient-code
cloud-cover-category-code
cloud-cover-base-dimension
cloud-cover-top-dimension
cloud-cover-average-coverage-code
cloud-cover-light-refraction-ratio
ICING
PRECIPITATION
icing-id (FK)
precipitation-id (FK)
icing-category-code
icing-severity-qualifier-code
precipitation-category-code
precipitation-rate
LIGHT
WIND
light-id (FK)
wind-id (FK)
light-category-code
light-up-datetime
light-down-datetime
light-moon-phase-code
wind-category-code
wind-air-stability-category-code
wind-altitude-layer-code
wind-direction-angle
wind-effective-downwind-direction-angle
wind-speed-rate
wind-nuclear-yield-qualifier-code
VISIBILITY
visibility-id (FK)
visibility-category-code
visibility-direction-code
visibility-range-dimension
Figure 58. METEOROLOGIC-FEATURE and Its Subtypes
174
V3.1.4
5.5.4.1
Specification of METEOROLOGIC-FEATURE
5.5.4.1.1 METEOROLOGIC-FEATURE is defined as "A FEATURE that
describes reported or forecast weather and light conditions." Several types of
meteorological (MET) information are used in tactical operations and provided for various
periods of use (e.g., 12 hours, 24 hours).
5.5.4.1.2 A METEOROLOGIC-FEATURE describes a meteorological condition
at a specific location. This location (e.g., a specific area or point) is identified using
OBJECT-ITEM-LOCATION. Several conditions that are described using
METEOROLOGIC-FEATURE can depend on altitude; in such cases, a set of
METEOROLOGIC-FEATURE instances is used and associated with OBJECT-ITEMLOCATION representing the correct altitude (using a POINT or SURFACE specification)
or using a range of altitudes specified by a GEOMETRIC-VOLUME (using geometricvolume-upper-vertical-distance-id and geometric-volume-lower-vertical-distance-id).
5.5.4.1.3 A METEOROLOGIC-FEATURE also describes a meteorological
condition at a specific time, either a past time for observations or a future time for weather
predictions. The effective starting datetime specified in the REPORTING-DATA links it
to the OBJECT-ITEM-LOCATION. A prediction can be made for an entire period of time
by also specifying the ending datetime of the prediction in the same instance of
REPORTING-DATA. To support the creation of predictions, METEOROLOGICFEATURE provides an attribute that specifies the probability of the condition occurring at
the specified location within the specified timeframe.
5.5.4.1.4 Each METEOROLOGIC-FEATURE describes only a single
meteorological condition. However, it is possible to construct a composite weather image
by defining multiple METEOROLOGIC-FEATUREs with different OBJECT-ITEMLOCATION s, but which all refer to the same REPORTING-DATA.
5.5.4.1.5 The attributes are:
a.
meteorologic-feature-id—The feature-id of a specific METEOROLOGICFEATURE (a role name for object-item-id).
b.
meteorologic-feature-category-code—The specific value that represents the
class of METEOROLOGIC-FEATURE. It serves as a discriminator that
partitions METEOROLOGIC-FEATURE into subtypes. Example domain
values are: ATMOSPHERE; CLOUD-COVER; Cyclone; Hurricane; ICING;
LIGHT; PRECIPITATION; Storm; Thunderstorm; Tornado; Tropical storm;
Typhoon; VISIBILITY; Whirlwind; WIND; Not otherwise specified.
c.
meteorologic-feature-interpretation-code—The specific value that denotes
the statistical meaning of a specified METEOROLOGIC-FEATURE. The
domain values are: Absolute maximum; Absolute minimum; Average
maximum; Average minimum; Nominal.
d.
meteorologic-feature-probability-ratio—The numeric quotient value that
represents the likelihood that a specific condition will occur for a specific
METEOROLOGIC-FEATURE. The value must be in the range from 0 to 1.
e.
meteorologic-feature-source-code—The specific value that denotes the basis
for the estimate of a condition for a specific METEOROLOGIC-FEATURE.
The domain values are: Forecast; Observed.
175
V3.1.4
5.5.4.1.6 Note that an instance of METEOROLOGIC-FEATURE should have
only one corresponding LOCATION, as the probability attribute in METEOROLOGICFEATURE is only intended for a single location over a specific period of time.
5.5.4.2
ATMOSPHERE as a Subtype of METEOROLOGIC-FEATURE
ATMOSPHERE is defined as "A METEOROLOGIC-FEATURE that specifies
humidity, pressure, and temperature characteristics of Earth's atmosphere." The attributes
are:
a.
atmosphere-id—The meteorologic-feature-id of a specific ATMOSPHERE
b.
atmosphere-humidity-ratio—The numeric quotient value that represents the
proportion of water present in the air to the maximum amount of water
(saturation point) possible at a given temperature and pressure. The value
must be in the range from 0 to 1.
c.
atmosphere-inversion-layer-code—The specific value that represents the
height of the inversion layer in the atmosphere. The stability class describes
the degree of mixing of released material in the atmosphere. The domain
values are: A; B; C.
d.
atmosphere-pressure-quantity—The numeric value that denotes the ambient
air pressure in terms of force per unit area. The unit of measure is kPa
(Kilopascals).
e.
atmosphere-pressure-system-category-code—The specific value that
represents the class of a pressure system in a particular ATMOSPHERE.
Example domain values are: Cold front; High pressure centre; Ridge line.
f.
atmosphere-temperature—The numeric value that indicates the heat of the
ambient air for a specific ATMOSPHERE.
g.
atmosphere-temperature-gradient-code—The specific value that represents
heat change with respect to the ground and 100 m in elevation in a certain
area. Acts as an indication of vertical air movement between the ground and
higher elevations. The domain values are: Neutral; Stable; Unstable; Not
known.
5.5.4.3
CLOUD-COVER as a Subtype of METEOROLOGIC-FEATURE
5.5.4.3.1 CLOUD-COVER is defined as "A METEOROLOGIC-FEATURE that
specifies the characteristics of clouds above Earth's surface." The attributes are:
a.
cloud-cover-id—The meteorologic-feature-id of a specific CLOUD-COVER
b.
cloud-cover-category-code—The specific value that represents the prevailing
class of a specific CLOUD-COVER. The domain values are: Clouds;
Radioactive cloud; Smoke.
c.
cloud-cover-base-dimension—The
one-dimensional
linear
distance
representing the elevation of the lowest cloud base for a specific CLOUDCOVER.
176
V3.1.4
d.
cloud-cover-top-dimension—The
one-dimensional
linear
distance
representing the elevation of the highest cloud ceiling for a specific CLOUDCOVER.
e.
cloud-cover-average-coverage-code—The specific value that represents the
average density of a specific CLOUD-COVER as fractional coverage. The
domain values are: 0/8; 1/8; 2/8; 3/8; 4/8; 5/8; 6/8; 7/8; 7-8/8; 8/8.
f.
cloud-cover-light-refraction-ratio—The numeric quotient value that
represents the velocity of light in a specific CLOUD-COVER as a fraction of
the velocity of light in a vacuum, based on cloud height. This represents the
inverse of the index of refraction. The value must be in the range from 0 to 1.
5.5.4.3.2 The entity provides both the lowest elevation and the highest elevation
of clouds. These attributes are important in air operations, particularly in airborne and
reconnaissance activities, as well as for targeting.
5.5.4.4
ICING as a Subtype of METEOROLOGIC-FEATURE
ICING is defined as "A METEOROLOGIC-FEATURE that specifies the
accumulation of frozen water on stationary or moving surfaces." The attributes are:
a.
icing-id—The meteorologic-feature-id of a specific ICING (a role name for
object-item-id).
b.
icing-category-code—The specific value that represents the class of a
particular ICING. The domain values are: Clear icing; Mixed icing; Rime
icing.
c.
icing-severity-qualifier-code—The specific value that represents the severity
of a particular ICING. The domain values are: Light; Moderate; Severe.
5.5.4.5
LIGHT as a Subtype of METEOROLOGIC-FEATURE
LIGHT is defined as "A METEOROLOGIC-FEATURE that specifies the
availability of natural illumination by type and time." The attributes are:
a.
light-id—The meteorologic-feature-id of a specific LIGHT (a role name for
object-item-id).
b.
light-category-code—The specific value that represents the class of LIGHT.
The domain values are: Civil twilight; Darkness, Daylight; Moonlight;
Nautical twilight.
c.
light-up-datetime—The character string representing a point in time that
designates the time of day that marks the beginning of the period of
effectiveness of the specified type of LIGHT.
d.
light-down-datetime—The character string representing a point in time that
designates the time of day that marks the end of the period of effectiveness
of the specified type of LIGHT.
e.
light-moon-phase-code—The specific value that represents the phase of the
moon for a specific LIGHT. The domain values are: Full moon; New moon;
Waning moon; Waxing moon.
177
V3.1.4
5.5.4.6
PRECIPITATION as a Subtype of METEOROLOGIC-FEATURE
PRECIPITATION is defined as "A METEOROLOGIC-FEATURE that specifies
the type of particulate matter in the Earth's atmosphere and the rate of its descent onto the
Earth’s surface." The attributes are:
a.
precipitation-id—The
meteorologic-feature-id
PRECIPITATION (a role name for object-item-id).
of
a
specific
b.
precipitation-category-code—The specific value that represents the
prevailing class of a specific PRECIPITATION. Example domain values are:
Hail; No precipitation; Rain; Sleet; Snow.
c.
precipitation-rate—The numeric value that denotes the amount of
PRECIPITATION deposited per unit time. The unit of measure is
millimetres per hour. The specified value must be greater than or equal to 0
(zero).
5.5.4.7
VISIBILITY as a Subtype of METEOROLOGIC-FEATURE
VISIBILITY is defined as "A METEOROLOGIC-FEATURE that specifies the
distance at which an object illuminated by light in the visual spectrum can be detected."
The attributes are:
a.
visibility-id—The meteorologic-feature-id of a specific VISIBILITY (a role
b.
visibility-category-code—The specific value that represents the class of
obscurant that governs a particular VISIBILITY. Example domain values
are: Blowing snow; Fog/mist; Sandstorm; Smoke.
c.
visibility-direction-code—The specific value that represents the direction for
which a specific VISIBILITY is valid. Example domain values are: East;
North; South; West. The domain value set for this attribute is shared with
one or more other attributes and is defined in the set direction-code.
d.
visibility-range-dimension—The
one-dimensional
linear
distance
representing the distance which can be surveyed using visual observation for
a specific VISIBILITY.31
5.5.4.8
WIND as a Subtype of METEOROLOGIC-FEATURE
WIND is defined as "A METEOROLOGIC-FEATURE that specifies the velocity
and directional characteristics of atmospheric movement." The attributes are:
a.
wind-id—The meteorologic-feature-id of a specific WIND (a role name for
object-item-id).
Note (US Army AR 310-25): In US weather observing practice, the greatest distance in a
given direction at which it is just possible to see and identify with the unaided eye (a) in the
daytime, a prominent dark object against the sky at the horizon, and (b) at night, a known,
preferably unfocused, moderately intense light source. After the visibility has been determined
through the entire horizon circle, they are resolved into a single value of prevailing visibility for
reporting purposes.
31
178
V3.1.4
5.6
b.
wind-category-code—The specific value that represents the class of WIND.
Example domain values are: Constant; Gusting; Squalls; Variable; Not
known.
c.
wind-air-stability-category-code—The specific value used to indicate the
class of air stability. Example domain values are: Simplified, unstable;
Simplified, stable; Detailed, very unstable; Detailed, neutral.
d.
wind-altitude-layer-code—The specific value used to indicate the class of the
altitude for a specific set of reported wind data. Example domain values are:
2000 metres; 8000 metres; 14,000 metres; 30,000 metres.
e.
wind-direction-angle—The rotational measurement clockwise between the
line of true North and the direction from which a specific WIND originates.
f.
wind-effective-downwind-direction-angle—The rotational measurement of
the mean downwind direction at ground level in the hazard area towards
which the cloud travels.
g.
wind-speed-rate—The numeric value that denotes the distance per unit time
of a specific WIND. The unit of measure is kilometres per hour. The
h.
wind-nuclear-yield-qualifier-code—The specific value used to identify
predicted wind values associated with nuclear fallout prediction for a specific
Nuclear yield group. Example domain values are: ALFA; BRAVO;
CHARLIE; FOXTROT; GOLF. The domain value set for this attribute is
shared with one or more other attributes and is defined in the set nuclearyield-group-code.
MATERIEL
5.6.1 MATERIEL Structure
The structure of MATERIEL and its single subtype is illustrated in the figure below.
5.6.2 Specification of MATERIEL
5.6.2.1 MATERIEL is defined as "An OBJECT-ITEM that is equipment, apparatus
or supplies of military interest without distinction as to its application for administrative or
combat purposes." The attributes are:
a.
materiel-id—The object-item-id of a specific MATERIEL (a role name for
object-item-id).
b.
materiel-category-code—The specific value that represents the class of
MATERIEL. It serves as a discriminator that partitions MATERIEL into
subtypes. The domain values are: INSTRUMENT-LANDING-SYSTEM;
c.
materiel-serial-number-identification-text—The character string assigned to
represent a specific MATERIEL. Comment: The serial number, frequently
found stamped on an object, may be unique only for a MATERIEL-TYPE
with a specific model number.
179
V3.1.4
MATERIEL
materiel-id (FK)
materiel-serial-number-identification-text
materiel-lot-identification-text
materiel-hull-number-text
materiel-mine-requisition-case-number-text
instrument-landing-system-id (FK)
instrument-landing-system-beam-width-dimension
instrument-landing-system-glide-path-angle
instrument-landing-system-magnetic-variation-angle
instrument-landing-system-slaved-variation-angle
instrument-landing-system-bearing-angle
instrument-landing-system-threshold-crossing-height-dimension
instrument-landing-system-localiser-distance-dimension
instrument-landing-system-distance-measuring-equipment-distance-dimension
Figure 59. MATERIEL and Its Subtype INSTRUMENT-LANDING-SYSTEM
d.
materiel-lot-identification-text—The character string assigned to represent a
specific production of a specific MATERIEL. For example, it might be used
to specify the production lot of propellant or other munitions.
e.
materiel-hull-number-text—The character string assigned to represent the
number assigned to a specific vessel, which when associated with a specific
hull type or ship type, uniquely identifies that vessel.
f.
materiel-mine-requisition-case-number-text—The character string assigned
to represent the book/record keeping number to keep track of individual
mines.
5.6.2.2 The table below provides examples of MATERIEL. The entries appear in
the database as a result of some activities. The background information is as follows:
a.
A suspicious object is found. Its body is black and is marked with a red
symbol on it (materiel-id = 5467).
b.
A new vehicle is acquired: It is blue and its number plate is M-8986-YT
(materiel-id = 12950).
c.
Ammunition is captured (materiel-id = 5468).
d.
An Instrument landing system is identified for an airport.
180
V3.1.4
Table 68. Examples of MATERIEL
MATERIEL
materiel-id
5467
12950
5468
1234
materiel-categorycode
Not otherwise
specified
Not otherwise
specified
Not otherwise
specified
INSTRUMENTLANDING-SYSTEM
materiel-serialnumberidentification-text
materiel-lotidentification
-text
materielhull-numbertext
materiel-minerequisition-casenumber-text
3-0004-66772-09
—
—
—
M-8986-YT
2-99X-084
—
—
5-9803-89932-11
143-732
—
—
—
—
—
—
5.6.3 INSTRUMENT-LANDING-SYSTEM as a Subtype of MATERIEL
5.6.3.1 INSTRUMENT-LANDING-SYSTEM is defined as "A MATERIEL that
provides aircraft with horizontal and vertical guidance just before landing and during
landing, and at certain fixed points, indicates the distance to the reference point of
landing." The attributes are:
a.
instrument-landing-system-id—The
materiel-id
of
a
specific
INSTRUMENT-LANDING-SYSTEM (a role name for object-item-id).
b.
instrument-landing-system-beam-width-dimension—The one-dimensional
linear distance representing the extreme horizontal distance measured from
side to side and perpendicular to the central axis of the main beam coil of a
specific localiser.
c.
instrument-landing-system-glide-path-angle—The rotational measurement
from the horizontal plane to the glide path, where the positive angle is
vertically upward.
d.
instrument-landing-system-magnetic-variation-angle—The
rotational
measurement of the angular difference between true north and magnetic
north.
e.
instrument-landing-system-slaved-variation-angle—The
rotational
measurement of the fixed value of magnetic variation applied to true
direction to obtain the magnetic values for radials, courses and headings.
f.
instrument-landing-system-bearing-angle—The rotational measurement
clockwise from true North to the localiser used for final approach guidance.
g.
instrument-landing-system-threshold-crossing-height-dimension—The onedimensional linear distance representing the height above the landing
threshold on a normal glide path.
h.
instrument-landing-system-localiser-distance-dimension—The
onedimensional linear distance representing the extreme horizontal distance
measured perpendicular from the end of the runway to the localiser antenna
position.
i.
instrument-landing-system-distance-measuring-equipment-distancedimension—The one-dimensional linear distance representing the distance
between the distance measuring equipment and the associated landing
threshold.
181
V3.1.4
5.6.3.2 The table below provides examples of INSTRUMENT-LANDINGSYSTEM.
Table 69. Examples of INSTRUMENT-LANDING-SYSTEM
*-id
*-beam-widthdimension
*-glidepath-angle
*-magneticvariation-angle
*-slaved-variationangle
*-bearingangle
—
—
—
1234
Note: * = "instrument-landing-system"
5.7
*-threshold-crossing-heightdimension
*-localiser-distancedimension
*-distance-measuring-equipmentdistance-dimension
—
—
—
ORGANISATION Subtree
5.7.1 Specification of ORGANISATION
5.7.1.1 ORGANISATION is defined as "An OBJECT-ITEM that is an
administrative or functional structure." Two forms of military organisation are represented
by explicit subtypes, namely, UNIT and CONVOY. The structure of ORGANISATION
hierarchy is illustrated in the figure below.
ORGANISATION
CONVOY
UNIT
convoy-id (FK)
unit-id (FK)
convoy-day-speed-rate
convoy-day-vehicle-gap-dimension
convoy-halt-duration
convoy-night-speed-rate
convoy-night-vehicle-gap-dimension
convoy-packet-gap-dimension
convoy-packet-size-count
unit-formal-abbreviated-name-text
unit-identification-text
Figure 60. ORGANISATION and Its Subtypes
5.7.1.2 The attributes of ORGANISATION are:
a.
organisation-id—The object-item-id of a specific ORGANISATION (a role
b.
organisation-category-code—The specific value that represents the class of
ORGANISATION. It serves as a discriminator that partitions
ORGANISATION into subtypes. The domain values are: CONVOY; UNIT;
182
V3.1.4
5.7.1.3 The following comment applies to object-item-name-text when it used for
an organisation. The name may be the designator (but not a call sign) for an observer,
forward air controller, laser designator team, or a specific flight of aircraft. (Ref. ADatP-3,
FFIRN 1028, "Unit Identifier"—The identification of a military, paramilitary, or
government agency unit as used in official communications within military
establishments.)
5.7.2 CONVOY as a Subtype of ORGANISATION
5.7.2.1 CONVOY is defined as "An ORGANISATION that is a group of vehicles
or vessels organised for the purpose of control and orderly movement with or without
escort protection." The attributes are:
a.
convoy-id—The organisation-id of a specific CONVOY (a role name for
object-item-id).
b.
convoy-day-speed-rate—The numeric value that denotes the maximum
distance per unit time that a specific CONVOY is to maintain during
daylight operations. The unit of measure is kilometres per hour. The
c.
convoy-day-vehicle-gap-dimension—The one-dimensional linear distance
representing the distance between vehicles in a particular CONVOY during
daylight operations.
d.
convoy-halt-duration—The numeric value that represents a quantity of time
in milliseconds representing the aggregated units of time that a specific
CONVOY may remain stationary during operations.
e.
convoy-night-speed-rate—The numeric value that denotes the maximum
distance per unit time that a specific CONVOY is to maintain during
operations in darkness. The unit of measure is kilometres per hour. The
f.
convoy-night-vehicle-gap-dimension—The one-dimensional linear distance
representing the distance between vehicles in a particular CONVOY during
operations in darkness.
g.
convoy-packet-gap-dimension—The one-dimensional linear distance
representing the distance between packets in a particular CONVOY.
h.
convoy-packet-size-count—The integer value that represents the number of
vehicles per packet in a particular CONVOY.
5.7.2.2 Examples of convoys are presented in the table below. Parameters
governing convoy configuration and movement restrictions are defined for five different
convoys.
183
V3.1.4
Table 70. Examples of CONVOY
(a) OBJECT-ITEM
ORGANISATION
object-item-id
organisation-id
3331
3332
3333
3334
Convoy1
Convoy2
Convoy3
Convoy4
3331
3332
3333
3334
CONVOY
CONVOY
CONVOY
CONVOY
3335
Convoy5
3335
CONVOY
(b) CONVOY
convoyid
convoy
-dayspeedrate
convoy-dayvehicle-gapdimension
convoyhaltduration
convoy
-nightspeedrate
convoynightvehicle-gapdimension
convoypacketgapdimension
convoypacketsizecount
3331
3332
3333
3334
3335
30
40
25
30
35
10
15
10
10
15
300000
180000
240000
120000
300000
20
30
20
25
30
10
15
10
10
15
100
150
100
100
140
30
20
10
20
30
5.7.3 UNIT as a Subtype of ORGANISATION
5.7.3.1 UNIT is defined as "A military ORGANISATION whose structure is
prescribed by competent authority." (e.g., in the form of a table of organisation and
equipment; specifically, part of an organisation). A formation is specified as a UNIT. The
attributes are:
a.
unit-id—The organisation-id of a specific UNIT (a role name for objectitem-id).
b.
unit-formal-abbreviated-name-text—The character string specifying the
common formal abbreviation used to designate a specific UNIT.
c.
unit-identification-text—The character string assigned to represent a unit’s
identification.
5.7.3.2 An example of how the entities OBJECT-ITEM, ORGANISATION and
UNIT are used together to specify instances of real-world units is shown in the table
below.
Table 71. ORGANISATION and UNIT Examples
(a) OBJECT-ITEM
ORGANISATION
objectitem-id
organisation-id
organisationcategory-code
4597
4598
4599
101st Airborne Division
3rd Cavalry Bn
1/33 Field Artillery Bn
4597
4598
4599
UNIT
UNIT
UNIT
4600
4601
4602
4603
4604
4605
9112 Prov Coy
Hava Ind. Tug. - TUR
33 Mknz. Tug. - TUR
Brigada Mecanizada Independente - PRT
Brigada Ligeira de Intenvencao - PRT
1 Pulk Lotnictwa Mysliwskiego - POL
4600
4601
4602
4603
4604
4605
UNIT
UNIT
UNIT
UNIT
UNIT
UNIT
184
V3.1.4
(b) UNIT
5.8
unit-id
unit-formalabbreviated-name-text
4597
101 Div
3VSAA
4598
4599
4600
4601
4602
3 CAV
1/33 FA Bn
9112 Pro Coy
Kayseri HIT
33 B
1WWBB
2KLAB
2CDBA
—
—
4603
4604
4605
BMI
BLI
1PLM
—
—
—
unit-identification-text
PERSON Structure
5.8.1 Specification of PERSON
5.8.1.1 PERSON is a necessary entity for exchange of command and control
information at the international level, since there is a requirement to track the identity and
location of commanders and key staff at many echelons. There may also be a need to
identify hostages and victims of national disasters or acts of terrorism. The structure for
PERSON is illustrated in the figure below.
PERSON
person-id (FK)
person-birth-datetime
person-blood-type-code
person-gender-code
person-professing-indicator-code
is-identified-by /
identifies
is-recognised-as-having /
is-ascribed-to
person-id (FK)
person-identification-document-index
person-id (FK)
person-language-skill-index
person-identification-document-code
person-identification-document-number-text
person-language-skill-category-code
person-language-skill-general-proficiency-code
person-language-skill-listening-proficiency-level-code
person-language-skill-reading-proficiency-level-code
person-language-skill-speaking-proficiency-level-code
person-language-skill-writing-proficiency-level-code
Figure 61. PERSON and Its Child Entities
5.8.1.2 A PERSON is defined as "An OBJECT-ITEM that is a human being to
whom military or civilian significance is attached." The attributes are:
a.
person-id—The object-item-id of a specific PERSON (a role name for
object-item-id).
b.
person-birth-datetime—The character string representing a point in time that
designates the date when a specific PERSON was born.
185
V3.1.4
c.
person-blood-type-code—A code which represents the specific blood type of
a PERSON. The domain values are: A Rh Positive; A Rh Negative; B Rh
Positive; B Rh Negative; O Rh Positive; O Rh Negative; AB Rh Positive;
AB Rh Negative; Not known.
d.
person-gender-code—A code that represents the classification of a PERSON
based on reproductive physiological traits. The domain values are: Female;
Male; Not known. The domain value set for this attribute is shared with one
or more other attributes and is defined in the set gender-code.
e.
person-professing-indicator-code—The specific value that represents
whether a specific PERSON professes a religious preference. The domain
5.8.1.3 The table below provides instances for PERSON. Sub-table (a) contains
data for OBJECT-ITEM and sub-table (b) contains data for PERSON.
Table 72. Example Instances for PERSON
(a) OBJECT-ITEM
object-item-id
4532
7539
7540
7546
PERSON
PERSON
PERSON
PERSON
William A. Smith
Jessica L. Williams
Audrey H. Muhler
Ferdinand Seville
1
2
3
4
PERSON
PERSON
PERSON
PERSON
John W. Stone
Jack Stevens
José Andrés Serrano
Juan M. Castillo
(b) PERSON
person-id
person-birthdatetime
person-bloodtype-code
person-gendercode
person-professingindicator-code
4532
7539
7540
7546
1
2
3
4
19600421000000.000
—
19551112000000.000
19800509000000.000
19630422000000.000
19551003000000.000
19700425000000.000
19601214000000.000
B RH Positive
O Rh Negative
AB Rh Negative
Not known
—
—
—
—
Male
Female
Female
Male
Male
Male
Male
Male
—
Yes
No
Yes
—
—
—
—
5.8.2 PERSON-IDENTIFICATION-DOCUMENT
5.8.2.1 PERSON-IDENTIFICATION-DOCUMENT has been added to the model
as a child entity of PERSON. PERSON-IDENTIFICATION-DOCUMENT is defined as
"A document used to identify a specific PERSON." It allows the identification of specific
documents that a particular PERSON may have. The attributes are:
a.
object-item-id).
b.
person-identification-document-index—The unique value, or set of
characters, assigned to represent a specific PERSON-IDENTIFICATION-
186
V3.1.4
DOCUMENT for a specific PERSON and to distinguish it from all other
PERSON-IDENTIFICATION-DOCUMENTs for that PERSON.
c.
person-identification-document-code—The specific value that represents the
type of document used to identify a specific PERSON. The domain values
are: Civilian identification card; Not otherwise specified; Military
identification card; Military orders; Passport.
d.
person-identification-document-number-text—The character string assigned
to represent the identifying number of the specific document used to identify
a PERSON.
5.8.2.2 The table below lists examples for personal identification. Data for Person
3 (Jose) shows that he has a passport and a military identification card, while only a
civilian identification card is listed for Person 4 (Juan).
Table 73. Use of PERSON-IDENTIFICATION-DOCUMENT
person-id
personidentificationdocument-index
person-identificationdocument-code
person-identificationdocument-numbertext
3
3
4
1
2
1
Passport
Military identification card
Civilian identification card
32354335
5370305
44323312J
5.8.3 PERSON-LANGUAGE-SKILL
5.8.3.1 PERSON-LANGUAGE-SKILL is a child entity of PERSON. PERSONLANGUAGE-SKILL is defined as "A proficiency or ability of a specific PERSON with
regard to a specific language."
5.8.3.2 The attributes are:
a.
object-item-id).
b.
person-language-skill-index—The unique value, or set of characters,
assigned to represent a specific PERSON-LANGUAGE-SKILL for a
specific PERSON and to distinguish it from all other PERSONLANGUAGE-SKILLs for that PERSON.
c.
person-language-skill-category-code—The specific value that represents the
particular language of PERSON-LANGUAGE-SKILL. Example domain
values are: Danish; Norwegian; Portuguese. The domain value set for this
attribute is shared with one or more other attributes and is defined in the set
language-category-code.
d.
person-language-skill-general-proficiency-code—The specific value that
represents the general level of proficiency of a specific PERSON in a
specific language skill. The domain values are: Elementary; Excellent; Fair;
No significant or practical proficiency; Very good; Not known.
e.
person-language-skill-listening-proficiency-level-code—The specific value
that represents the level of listening comprehension of a specific PERSON in
a specific language skill. The domain values are: 0; 1; 2; 3; 4; 5. The domain
187
V3.1.4
value set for this attribute is shared with one or more other attributes and is
defined in the set language-skill-proficiency-code.
f.
person-language-skill-reading-proficiency-level-code—The specific value
that represents the level of reading comprehension of a specific PERSON in
a specific language skill. The domain values are: 0; 1; 2; 3; 4; 5. The domain
g.
person-language-skill-speaking-proficiency-level-code—The specific value
that represents the level of speaking proficiency of a specific PERSON in a
specific language skill. The domain values are: 0; 1; 2; 3; 4; 5. The domain
h.
person-language-skill-writing-proficiency-level-code—The specific value
that represents the level of writing proficiency of a specific PERSON in a
specific language skill. The domain values are: 0; 1; 2; 3; 4; 5. The domain
5.8.3.3 A simple example in the table below illustrates the use of the PERSONLANGUAGE-SKILL structure for linguistic abilities. Data shows that Person 1 (John) has
modest proficiency in German and high proficiency in Dutch; Person 2 (Jack) has fair
proficiency in Portuguese, very good proficiency in Spanish, and an undetermined
proficiency in French. Both are native English speakers.
Table 74. Use of PERSON-LANGUAGE-SKILL
person
-id
*index
*-categorycode
*-generalproficiencycode
*-listeningproficiencylevel-code
*-readingproficiency
-level-code
*-speakingproficiencylevel-code
*-writingproficiency
-level-code
1
1
1
2
German
Dutch
Elementary
Excellent
1
5
2
5
2
5
1
5
1
2
2
2
2
3
1
2
3
4
English
Portuguese
Spanish
French
English
Excellent
Fair
Very good
Not known
Excellent
5
3
4
—
5
5
3
4
—
5
5
4
5
—
5
5
2
4
—
5
Note: * = "person-language-skill"
5.9
Comments and Amplifications
While each object is always represented as unique OBJECT-ITEM, different
instances of OBJECT-ITEMs may refer to the same real-world object. As an example,
consider a situation in which two reporting organisations have sighted the same enemy
unit but neither can give a positive identification. Because they have no way of knowing
that they are referring to the same object, they must create their own unique OBJECTITEM identifiers when reporting their sighting. The task of combining and correlating raw
intelligence data such falls outside the model; however, results of the correlation can be
captured in data.
188
V3.1.4
6.
RELATIONSHIPS BETWEEN ITEMS AND TYPES
This chapter deals with three sets of direct relationships between items and types:
classification of items according to type, possession of types by items, and the
identification of types of materiel according to a given scheme, such as Land Forces
Reportable Item List (LFRIL).
6.1
Classification of OBJECT-ITEMs by Type
6.1.1 Introduction
6.1.1.1 There is a requirement to represent more than one classification of any
specific OBJECT-ITEM. This permits the recording of differing interpretations by several
organisations of what the type of an item may be. This also enables the historical registry
of classifications as a means for understanding the decisions that were made at the time a
classification was considered valid.
6.1.1.2 The ability to classify OBJECT-ITEMs as OBJECT-TYPE makes any
information that is stored as type data applicable to the item. Thus, any characteristic of an
item that can be described as a type property does not need to be carried as an attribute on
the item side.
6.1.2 Linking an OBJECT-ITEM to an OBJECT-TYPE
6.1.2.1 The many-to-many relationship between OBJECT-TYPE and OBJECTITEM is resolved by an associative entity called OBJECT-ITEM-TYPE. It is defined as
"A record of the perceived classification of a specific OBJECT-ITEM as a specific
OBJECT-TYPE." The structure is illustrated in the figure below.
OBJECT-ITEM
object-item-id
OBJECT-TYPE
object-type-id
is-classified-as
P
OBJECT-ITEM-TYPE
object-item-id (FK)
object-type-id (FK)
Figure 62. Specification of OBJECT-ITEM-TYPE
6.1.2.2 OBJECT-ITEM-TYPE has only one native attribute: object-item-typeindex—The unique value, or set of characters, assigned to represent a specific OBJECTITEM-TYPE for a specific OBJECT-ITEM and a specific OBJECT-TYPE and to
distinguish it from all other OBJECT-ITEM-TYPEs for that OBJECT-ITEM and that
OBJECT-TYPE.
189
V3.1.4
6.1.2.3 The presence of the index enables different classifications to be recorded
over a period of time. The use of this data structure is illustrated in the table below. For
example, Unit A may classify an unknown object (item id 911) first as a vehicle (type id
10741), then successively, as better information becomes available, as an armoured
vehicle (type id 5432), a tank (type id 687322), a main battle tank (type id 72254), and a
T72 (type id 133794). Bracketed entry in the object-type-id column shows the underlying
data that the object-type-id represents. The fact that information about Object 911 is being
provided by Unit A is made available through REPORTING-DATA structure. The
bracketed entries in the reporting-data-id indicate part of the information that applies to
the instances of OBJECT-ITEM-TYPE via the relationship from REPORTING-DATA to
OBJECT-ITEM-TYPE.
6.1.2.4 Additional examples are provided in the last three rows of the table. An
allied unit—1st Royal Horse Artillery Regiment (1 RHA)—is classified as a UK field
artillery regiment. The 6 Guards Tank Division is an opposing force unit whose real
identity is initially unknown. It is only identified by its object-item-id 14486. Thus, the
first classification that is made considers it to be an armoured regiment. As more
information becomes available, the unit is re-classified as an armoured division.
Table 75. Use of object-type-id in OBJECT-ITEM-TYPE
OBJECT-ITEM-TYPE
object-item-id
object-type-id
reporting-data-id
911
10741
[Vehicle, not otherwise
specified]
5432
[Armoured vehicle]
687322
[Tank]
72254
[Main battle tank]
133794
[T72]
75
[UK Fd Arty Regt]
644
[OR Armd Rgt]
610
[OR Armd Div]
1
2711
1
2714
2717
2721
2724
1001
911
911
911
911
1793
[1 RHA]
14486
[6 Guards Tank Division]
14486
1
1
1
1
1
1
1002
[effective datetime = dt1]
1003
[effective datetime =d t2, dt2>dt1]
6.1.2.5 The existing business rules specify that each instance of OBJECT-ITEM be
typed at least once. If the initial classification does not change, then there is no need for
additional records in OBJECT-ITEM-TYPE. If the classification changes due to new
information, then a new record should be inserted in OBJECT-ITEM-TYPE and in
REPORTING-DATA as illustrated in the examples. On the other hand, the records may
come from different units reporting on the same item (as would be shown through
REPORTING-DATA) and classifying it differently. That case presents a problem in
interpretation, but that is external to the data structure that provides a place to store the
underlying data.
190
V3.1.4
6.1.3 Business Rules for OBJECT-ITEM Classification
6.1.3.1 The IDEF1X diagrammatic specification is not capable of ensuring that the
values of discriminators (a role played by category codes) in the hierarchy for an
OBJECT-ITEM match the values of discriminators in the hierarchy for the OBJECTTYPE to which it is related. Rules to ensure this consistency need to be defined outside the
diagram as part of a complete IDEF1X specification. Statement of rules that are applicable
at the time of original classification are specified in Annex G2, Section G2.4.1.
6.2
HOLDING and HOLDING-TRANSFER
6.2.1 Introduction
6.2.1.1 The purpose of HOLDING and HOLDING-TRANSFER specifications is
to provide commanders with a dynamic update of changes to information on stockpiles of
specific equipment and consumable materiel held by national or multinational forces.
6.2.1.2 The staff officer may wish to know how many tanks of a given type a
certain unit possesses and how many of them are operational. They may need to know
how many enemy companies there are within a given area (an instance of CONTROLFEATURE), or how many rounds of an ammunition type they have stored in a particular
arsenal. Another staff officer or commander may need to know how many cargo pallets
are contained on a particular airlift aircraft, or how many mechanics does a given
maintenance company have, or finally, which types of weapons and sensors are held by a
specific weapons platform (e.g., instance of an aircraft or tank)32.
6.2.1.3 The entity HOLDING addresses the association of a specific object
(OBJECT-ITEM) with a class of objects (OBJECT-TYPEs) where the relationship is
defined by the general notion of inclusion in the sense of ownership, possession,
assignment, or control. Each count of the number of a class in a HOLDING is subject to a
qualifying condition.
6.2.1.4 Holding specifies what an OBJECT-ITEM actually has or is estimated to
have at a particular time. The holding may be an estimate for a future date, such as the
expected count of a given type of equipment a week from now. In this way, expected
replenishment or repair of materiel can be reflected in the holdings that serve as one of the
sources of information for combat operations planning.
6.2.1.5 The entity HOLDING-TRANSFER supports the recording of logistic
transactions, such as losses or gains. Its specifications enable to indicate the reason for a
transfer, the quantity of a transfer, and the corresponding instance of OBJECT-ITEM that
is the providing or receiving agent in a transaction.
6.2.1.6 A subsequent chapter introduces the concept of establishment as a way of
relating an OBJECT-TYPE to another OBJECT-TYPE. Such an establishment details
what an OBJECT-TYPE is authorised to have in terms of other OBJECT-TYPEs.
Comparison of establishment and HOLDING can disclose information about surpluses
and deficiencies.
32
The load of weapons carried by a specific close air support aircraft is a case in point.
191
V3.1.4
6.2.1.7 The structural diagram is presented in Section 6.2.2. HOLDING is
specified in Sections 6.2.3; Section 6.2.4 contains an example; and Section 6.2.5 points to
business rules. HOLDING-TRANSFER is specified in Sections 6.2.6, while Section 6.2.7
presents an example. The chapter concludes with Section 6.28 that provides suggestions
for managing HOLDING data within echeloned formations.
6.2.2 The Structure for HOLDING and HOLDING-TRANSFER
The structure for representing HOLDINGs and HOLDING-TRANSFERs is
OBJECT-ITEM
OBJECT-TYPE
object-item-id
object-type-id
has /
belongs-to
is-subject-of /
is-constrained-to
HOLDING
object-item-id (FK)
object-type-id (FK)
holding-index
is-correspondent-in /
is-transaction-for
holding-operational-count
holding-total-quantity
holding-on-hand-quantity
holding-required-total-quantity
holding-required-on-hand-quantity
holding-required-calculation-method-code
is-referenced-to
is-changed-by /
changes
HOLDING-TRANSFER
object-item-id (FK)
object-type-id (FK)
holding-index (FK)
holding-transfer-index
holding-transfer-reason-code
holding-transfer-quantity
holding-transfer-corresponding-object-item-id.object-item-id (FK)
is-referenced-to
REPORTING-DATA
reporting-data-id
reference-id (FK)
reporting-data-reporting-organisation-id.organisation-id (FK)
Figure 63. Specification of HOLDING
192
V3.1.4
6.2.3 Specification of HOLDING
HOLDING is defined as "The quantity of each specific OBJECT-TYPE that is
held by, installed in, or included with a specific OBJECT-ITEM." The attributes are:
a.
b.
a specific OBJECT-TYPE and to distinguish it from all other OBJECTTYPEs.
c.
holding-index—The unique value, or set of characters, assigned to represent
a specific HOLDING for a specific OBJECT-ITEM and a specific OBJECTTYPE and to distinguish it from all other HOLDINGs for that OBJECTITEM and that OBJECT-TYPE. Note: This attribute permits a historical
record of HOLDINGs to be maintained for an instance of an OBJECTITEM.
d.
holding-operational-count—The integer value representing the number of
specific OBJECT-TYPEs a specific OBJECT-ITEM has available for
operations.
e.
holding-total-quantity—The numeric value representing the total quantity, to
include reserves, of specific OBJECT-TYPEs physically held by a specific
OBJECT-ITEM. The unit of measure is derived from the OBJECT-TYPE
specification.
f.
holding-on-hand-quantity—The numeric value representing the quantity of
specific OBJECT-TYPEs physically held on-hand, not including reserves, by
a specific OBJECT-ITEM.
g.
holding-required-total-quantity—The numeric value representing the total
quantity of specific OBJECT-TYPEs required to be held on-hand and in
reserve by a specific OBJECT-ITEM to meet the NATO assigned task in
accordance with Force Standards or established mission requirements.
h.
holding-required-on-hand-quantity—The numeric value representing the
quantity of specific OBJECT-TYPEs, not including reserves, required to be
held on-hand by a specific OBJECT-ITEM in accordance with Force
Standards or established mission requirements.
i.
holding-required-calculation-method-code—The
specific
value
that
represents the required stocks calculation method used for the count of
OBJECT-TYPEs in a specific HOLDING. The domain values are: Level of
effort, Target.
j.
REPORTING-DATAs. 33
Since each instance of HOLDING is an estimate, REPORTING-DATA provides the
amplifying information about that estimate. Part of the amplifying information identifies the
organisation that is reporting the HOLDING, since the estimate is likely to have little value unless
33
193
V3.1.4
6.2.4 Business Rules for HOLDING
Restrictions that are placed on pairings of items and types in HOLDING to reflect
operationally meaningful combinations are specified in business rules. The permissible
combinations are specified in Annex G2, Section G2.4.2.
6.2.5 Example of HOLDING Data
6.2.5.1 The use of HOLDING is illustrated in the table below. The table lists the
kind of records that may be maintained for own forces (in this case, a fictional unit—101st
(US) Mechanized Brigade). The unit holdings example lists two types of equipment and
the total military personnel assets.
6.2.5.2 The identifying information for each OBJECT-ITEM and OBJECT-TYPE
is included in brackets only for ease of reading. In an actual database this information
would be held in related tables. The last column contains an indirect reference to
REPORTING-DATA where the effective date for the holding estimate is indicated. It
should be noted that the first three records with index 41000001 constitute a single report
and refer to one instance of REPORTING-DATA. The REPORTING-DATA (were it
displayed) would show that the unit itself did the reporting and that the holding is an
actual count of both equipment and personnel.
6.2.5.3 Three additional entries for the 101st Brigade have an index 41000002,
since these are updates for several items reported earlier, namely, BFV, M1A1, and
military personnel. All of these refer to a second instance of REPORTING-DATA that
corresponds to the next reporting cycle on 8 August.
Table 76. Illustration of HOLDING
HOLDING
object-item-id
object-type-id
41822010
[101 Mech Bde]
41822010
[101 Mech Bde]
41822010
[101 Mech Bde]
41822010
[101 Mech Bde]
41822010
[101 Mech Bde]
41822010
[101 Mech Bde]
214015
[Bradley Fighting Vehicle (BFV), M-2]
229005
[Tank, Main Battle, M1A1]
41600
[Military person-type]
214015
[Bradley Fighting Vehicle (BFV), M-2]
229005
[Tank, Main Battle, M1A1]
41600
[Military person-type]
holdingindex
holdingoperationalcount
holdingtotalquantity
41000001
94
102
1 Aug
41000001
55
58
1 Aug
41000001
3607
3943
1 Aug
41000002
88
102
8 Aug
41000002
49
58
8 Aug
41000002
3511
3943
8 Aug
its source is known. The details of REPORTING-DATA entity are described in a subsequent
chapter.
194
V3.1.4
6.2.6 Specification of HOLDING-TRANSFER
HOLDING-TRANSFER is defined as "The specification of the OBJECT-TYPE
quantity expected to be added to or subtracted from a specific HOLDING." Its attributes
are:
a.
b.
a specific OBJECT-TYPE and to distinguish it from all other OBJECTTYPEs.
c.
holding-index—The unique value, or set of characters, assigned to represent
a specific HOLDING for a specific OBJECT-ITEM and a specific OBJECTTYPE and to distinguish it from all other HOLDINGs for that OBJECTITEM and that OBJECT-TYPE.
d.
holding-transfer-index—The unique value, or set of characters, assigned to
represent a specific HOLDING-TRANSFER for a specific HOLDING and to
distinguish it from all other HOLDING-TRANSFERs for that HOLDING.
e.
holding-transfer-reason-code—The specific value that characterises the basis
for a specific HOLDING-TRANSFER. Example domain values are: Fixedterm loan; Permanent transfer; Scrapped; Total due in.
f.
holding-transfer-quantity—The numeric value representing the quantity of
specific OBJECT-TYPE involved in a specific HOLDING-TRANSFER. A
negative quantity decreases the HOLDING and a positive quantity increases
the HOLDING.
g.
holding-transfer-corresponding-object-item-id—The object-item-id of a
specific OBJECT-ITEM that is either recipient or provider of a specific
HOLDING-TRANSFER (a role name for object-item-id).
h.
REPORTING-DATAs. 34
6.2.7 Example of HOLDING-TRANSFER Data
6.2.7.1 The example illustrates some of the uses that HOLDING-TRANSFER
enables. The scenario involves a transportation battalion, a maintenance unit, and a depot.
The data for the example is shown in the table below. The items are identified in Sub-table
(a). The transportation battalion operates two types of trucks as identified in Sub-table (b).
The initial or starting holdings are shown in Sub-table (c). The holdings for 4777 are not
really needed, but they are included for completeness and subsequent use. Note that the
actual entries for REPORTING-DATA are not included, but the effective dates are shown
to the right of the table.
REPORTING-DATA provides the amplifying information about an instance of HOLDINGTRANSFER. Part of the amplifying information identifies the organisation that is reporting the
transfer. The details of REPORTING-DATA entity are described in a subsequent chapter.
34
195
V3.1.4
Table 77. Illustration of HOLDING-TRANSFER
(a) OBJECT-ITEM
object-item-id
123
4777
55220
ORGANISATION
ORGANISATION
FACILITY
Transportation Bn A
Maintenance Coy B
Rear Depot C
(b) OBJECT-TYPE
objecttype-id
457
888
MATERIEL-TYPE
MATERIEL-TYPE
No
No
Truck Type M
Truck Type P
(c) HOLDING (Initial)
objectitem-id
objecttype-id
holdingindex
holdingholding-totaloperational-count
quantity
reportingdata-id
123
457
111001
17
17
11101
1 Nov
123
888
111002
10
13
11101
1 Nov
4777
457
422001
0
0
42201
1 Nov
4777
888
422002
0
0
42201
1 Nov
55220
457
533001
45
45
55501
1 Nov
55220
888
533002
30
30
55501
1 Nov
(d) HOLDING-TRANSFER (Initial)
objectitem-id
objecttype-id
holdingindex
*-index
*-reason-code
*-quantity
*-correspondingobject-item-id
reportingdata-id
123
888
111002
123001
Transfer for
maintenance
Scrapped
2
4777
11102
3 Nov
1
—
11117
4 Nov
3
123
55502
5 Nov
123
888
111002
123002
55220
457
533001
533001
Permanent
transfer
Note: * = "holding-transfer"
(e) HOLDING (After initial transfers)
holdingholding-totalholding-index operational-count
quantity
reportingdata-id
object-item-id
object-type-id
123
457
111003
20
20
11102
6 Nov
123
888
111004
7
10
11102
6 Nov
4777
457
422003
0
0
42202
6 Nov
4777
888
422004
0
2
42202
6 Nov
55220
457
533003
42
42
55502
6 Nov
55220
888
533004
30
30
55502
6 Nov
(f) HOLDING-TRANSFER (Second)
objectitem-id
objecttype-id
holdingindex
*-index
*-reason-code
*-quantity
*-correspondingobject-item-id
4777
888
422004
422001
123
457
111003
123001
123
888
111004
123001
Return to custodian
2
123
42203
7 Nov
Destroyed or lost
4
—
11103
8 Nov
Destroyed or lost
1
—
11104
9 Nov
Note: * = "holding-transfer"
196
reportingdata-id
V3.1.4
(g) HOLDING (Final)
holdingholding-totalholding-index operational-count
quantity
reportingdata-id
object-item-id
object-type-id
123
457
111005
16
16
11105
11 Nov
123
888
111006
8
11
11105
11 Nov
4777
457
422005
0
0
42203
11 Nov
4777
888
422006
0
0
42203
11 Nov
55220
457
533005
42
42
55503
11 Nov
55220
888
533006
30
30
55503
11 Nov
6.2.7.2 Two Type P trucks held by the transportation battalion need to be repaired,
while a third one has been damaged beyond repair and is to be scrapped. In addition, the
depot is transferring 3 Type M trucks to the transportations battalion. The transactions are
shown in Sub-table (d) where there is no receiving item for the scrapped truck. In real life,
the truck would have been transferred to a logistics organisation for disposal. Note that
Truck Type P entails two transfers from the same instance of HOLDING.
6.2.7.3 The holdings reported 5 days after the initial holdings and after the
transfers in Sub-table (d) have taken place are shown in Sub-table (e).
6.2.7.4 The second set of transfers entails the return of repaired trucks and the loss
of 5 trucks due to combat operations. The transfers are recorded in Sub-table (f) where the
loss of four Type M and one Type P truck is shown.
6.2.7.5 The final HOLDING for 11 November is shown in Sub-table (g).
6.2.8 Suggestions for Management of Echeloned HOLDING Data
6.2.8.1 A fundamental challenge in maintaining organisational holding information
for echeloned formations is the treatment of aggregation in moving from the lower
echelons to the higher. How the holdings are reported at various echelons is a command or
staff decision in the management of operational data. The options at each level are either
to roll up (total) lower level inputs and add any entries that are held only at the reporting
level or to create a new report, based on the lower level inputs, but possibly using broader
categories for reporting. For example, the lower level, say companies, may report various
truck holdings using very detailed categories as to type and model number. The brigade
may choose to report in only three broad categories according to light, medium, and heavy
load-carrying capacity. The reporting categories may also be determined by the
commander's preferences, such as those in a LFRIL (discussed in a succeeding section).
6.2.8.2 The following procedure is suggested as the preferred policy for managing
echeloned holding information:
Each echelon is expected to enter its own estimate of holdings. It
may be an arithmetic sum of its holdings at the echelon together with the
holdings submitted by its subordinate units without re-classification of type
categories. It may aggregate type categories into more inclusive broad
categories. It may also omit selected type categories that are deemed too
detailed for use at a higher echelon. The details may vary with command
guidance, but each echelon is expected to provide an input.
197
V3.1.4
6.2.8.3 Recipient of a holding report may have an update to a previous submission
or a replacement for it and has no way of interpreting the true intent of the provider. The
following procedure is suggested as the preferred policy for managing this situation:
Every submission of a holding report must be complete with respect
to the types that are included in the report.35
6.2.8.4 One of the advantages of the procedure in Paragraph 6.2.8.2 is that the
reporting of holdings at any echelon does not depend on the availability of data from the
lower echelon levels. It assures that an entry is made at each echelon regardless of the
status of reporting below that echelon level, even if the staff must make estimates of
holdings on behalf of its constituent units. Furthermore, even if the replication contract for
holdings is filtered by omitting data for echelons below a certain level, the recipient will
not be deprived of vital information.
6.2.8.5 As an example of echeloned reporting, the holding of PERSON-TYPEs by
a brigade will include all the PERSON-TYPEs not only in the brigade headquarters
company but also those in all its constituent units. Likewise, the holdings of tracked
vehicles comprises all those in the brigade manoeuvre battalions as well as the supporting
units and the brigade headquarters.
6.2.8.6 The OBJECT-TYPE under which a holding is reported may change with
echelon to reflect differing needs with respect to the granularity of data. The example in
the table below illustrates the concept. Battalion ABC has three companies under its
command each with its own complement of equipment. The battalion itself has 6 APCs in
its table of equipment. Sub-table (a) shows the holdings for individual units. Each
company reports to the battalion its holdings as shown in the first three records. The
battalion may report its total holdings at the detailed level that is shown as Option 1. In
this case, each type of equipment is reported separately. On the other hand, the battalion
may report its total holdings aggregated at the tank and APC level. The latter option is
shown as Option 2. The choice of the type of reporting is based on operational
considerations or command guidance.
Table 78. Options for Reporting Holdings at Higher Echelon
(a) Unit Holdings
Unit
Equipment Type
Total Number
Number Operational
Coy A
Coy B
Coy C
Bn ABC
Tank Type 1
Tank Type 2
APC Type 17
APC Type 11
16
12
18
6
15
10
15
5
This procedure also provides a way of submitting correct data without indicating that
any of the previous data was incorrect, thereby avoiding an indirect mechanism that is described in
Chapter 14. The disadvantage of this approach is that the historical data may not be correct.
35
198
V3.1.4
(b) Holdings Reported by Battalion
Option 1
Option 2
Equipment
Type
Total
Number
Number
Operational
Equipment
Type
Total
Number
Number
Operational
Tank Type 1
Tank Type 2
APC Type 17
APC Type 11
16
12
18
6
15
10
15
5
Tank
APC
28
24
25
20
6.3
Specification of Reportable Types
6.3.1 An organisation, such as NATO HQ or a regional headquarters, may create
lists of materiel types using a standard coding scheme for reporting purposes. Two such
specifications are Reportable Item Code (RIC) and the Land Forces Reportable Item List
(LFRIL) codes. The data specifications in the model are not limited to any particular
sphere of activity and the structure should be viewed as a general concept usable by any
organisation that needs a coded reference set for reporting.
6.3.2 The model includes an associative entity ORGANISATION-MATERIELTYPE-ASSOCIATION in order to enable the designation of instances of MATERIELTYPE with a specific reporting type code. The linkage to organisation is necessary since
the codes and the membership of the list can vary according to the organisation that
creates the list. The structure is illustrated in the figure below.
6.3.3 ORGANISATION-MATERIEL-TYPE-ASSOCIATION is defined as "A
relationship of an ORGANISATION as a subject with a MATERIEL-TYPE as an object."
The attributes are:
a.
b.
materiel-type-id—The object-type-id of a specific MATERIEL-TYPE (a role
c.
organisation-materiel-type-association-reportable-type-code—The specific
value that represents the class of ORGANISATION-MATERIEL-TYPEASSOCIATION. The domain values are: Land forces reportable item list;
Reportable item code.
d.
organisation-materiel-type-association-reportable-type-text—The character
string assigned to represent the Reportable type code for a specific
MATERIEL-TYPE, as assigned by a specific ORGANISATION.
e.
organisation-materiel-type-association-reportable-type-datetime—The
character string representing a point in time that designates when the
Reportable type code referenced by the ORGANISATION-MATERIELTYPE-ASSOCIATION is assigned.
It should be noted that reporting type code becomes a code once it is defined by the
responsible organisation; however, it is not a code that is always known in advance (in
which case the codes could be listed as a pre-defined pick list) nor does it have to be the
same code for different organisations. The model uses the class word text to accommodate
these possibilities.
199
V3.1.4
MATERIEL-TYPE
ORGANISATION
materiel-type-reportable-item-text
materiel-type-stock-number-text
materiel-type-supply-class-code
materiel-type-issuing-height-dimension
materiel-type-issuing-length-dimension
materiel-type-issuing-width-dimension
assigns -reporting-code-in
is-assigned-reporting-code-in
organisation-materiel-type-association-reportable-type-code
organisation-materiel-type-association-reportable-type-text
organisation-materiel-type-association-reportable-type-datetime
Figure 64. Assigning Reporting Codes to MATERIEL-TYPE
6.3.4 The table below provides examples of LFRIL codes issued by XXX Corps
on 1 February 2002 to be used in reports by all of its subordinate units.
Table 79. Examples of Reportable Type Codes
organisation-id
materiel-type-id
*-code
*-text
*-datetime
[XXX Corps]
[Lynx 1 helicopter]
LFRIL
AABIC0
[1 Feb 2002] [0800]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[XXX Corps]
[NATO]
[NATO]
[NATO]
[NATO]
[NATO]
[NATO]
[NATO]
[NATO]
[NATO]
[NATO]
[ATGW AFV Marder/Milan]
[90MM-JPZ-GE]
[105MM-Leopard 1]
[AFV 30MM Scimitar]
[105MM-M102 towed howitzer]
[81MM dismounted mortar]
[MILAN guided missile]
[Anti-tank mine]
[NBC protective clothing set]
[F50 gasoline civil]
[F54 diesel fuel]
[AH9-Lynx]
[AFV-MARDER-1A3]
[TDEST-JPZ-K]
[MBT-LEO-1A5]
[AFV-SCIMITAR]
[SHL-203HW-HE]
[LMOR-TYPE-87]
[ATGW-MILAN-IR]
[MINE-AT-SATM]
[NBC-SMK-LGE]
LFRIL
LFRIL
LFRIL
LFRIL
LFRIL
LFRIL
LFRIL
LFRIL
LFRIL
LFRIL
LFRIL
RIC
RIC
RIC
RIC
RIC
RIC
RIC
RIC
RIC
RIC
AAC2FB
ACB2CE
AC83CJ
ACB1CB
AHB2C0
AKA2AB
AD21C0
AZ1200
S11130
YF5000
YF5400
HB21DA
AC11DA
AC16EZ
AA13AB
AC14BZ
MB28AH
BC16EA
BB22AA
MG15BZ
NB31CA
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[1 Feb 2002] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
[NATO]
[NATO]
[MOGAS-UL-98RON]
[F-54-DIESEL]
RIC
RIC
PA13BA
PA31AA
[17 Mar 2005] [0800]
[17 Mar 2005] [0800]
Note: * = "organisation-material-type-association-reportable-type"
200
V3.1.4
7.
STATUS OF IDENTIFIABLE OBJECTS
This chapter deals with a general requirement of specifying the status of items at a
given time (past, present, or predicted). The main topics include:
a.
Classifying the hostility state of an OBJECT-ITEM,
b.
Assigning categories to OBJECT-ITEMs to capture administrative, medical,
physical, and procedural states or conditions.
Section 7.1 provides the specifications for hostility status; Section 7.2 is a general
introduction to OBJECT-ITEM-STATUS and its subtypes; Section 7.3 specifies the
details for recording the status of all OBJECT-ITEMs with the exception of MEDICALFACILITY-STATUS that is the subject of Section 7.4. The chapter ends with Section 7.5
that provides a cross-reference to the applicable business rules that are listed in Annex G2.
7.1
OBJECT-ITEM-HOSTILITY-STATUS
7.1.1 Most objects of the battlefield can be characterised as friend or enemy. This
information is not inherent to the specific object. The hostility status of an object is a
classification that a specific organisation gives to this object. It means that a specific
object may have different hostility status given by different organisations, and that the
hostility status may vary with time. The known or perceived friendly or aggressive
intentions of an object are recorded in the entity OBJECT-ITEM-HOSTILITY-STATUS
whose structure of is illustrated in the figure below.
OBJECT-ITEM
object-item-id
has /
is-ascribed-to
OBJECT-ITEM-HOSTILITY -STATUS
object-item-id (FK)
object-item-hostility -status-index
object-item-hostility -status-code
Figure 65. OBJECT-ITEM-HOSTILITY-STATUS
7.1.2 OBJECT-ITEM-HOSTILITY-STATUS is defined as "A record of the
perceived hostility classification of a specific OBJECT-ITEM." Its attributes are:
a.
a specific OBJECT-ITEM and to distinguish it from all other OBJECTITEMs. It is a foreign key migrated by the identifying relationship "has/is
ascribed to" from OBJECT-ITEM. The attribute identifies the specific
OBJECT-ITEM that is the subject of a specific OBJECT-ITEMHOSTILITY-STATUS designation.
201
V3.1.4
b.
object-item-hostility-status-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-HOSTILITY-STATUS for a
specific OBJECT-ITEM and to distinguish it from all other OBJECT-ITEMHOSTILITY-STATUSs for that OBJECT-ITEM.
c.
object-item-hostility-status-code—The specific value that represents the
perceived hostility status of a specific OBJECT-ITEM. For FACILITY,
FEATURE, and MATERIEL this is interpreted to indicate that it is used,
owned, or controlled by friendly or hostile forces. Example domain values
are: Assumed friend; Assumed hostile; Assumed involved; Assumed neutral;
Friend; Hostile; Involved; Neutral; Unknown.
d.
REPORTING-DATAs.
7.1.3 Illustrative instances of specification of OBJECT-ITEM-HOSTILITYSTATUS are shown in the table below that includes three sub-tables. In this example, the
status of three separate objects is reported by four different organisations as follows:
a.
A tank is initially assumed to be hostile by the 1 SP Division; later the Division
reports it as "assumed friend." Additional observation by 21 SP Brigade results in a
verified classification of "friend."
b.
A certain guerrilla group is classified by the 1 FR Division as "assumed involved";
subsequent contact with the 2 SP Division confirms that the group is actually
"friend."
c.
The 14 UK Division reports that Hilltop Y is under the control of hostile forces.
Table 80. Example Instances of OBJECT-ITEM-HOSTILITY-STATUS
(a) OBJECT-ITEM-HOSTILITY-STATUS
object-item-id
object-item-hostilitystatus-index
object-item-hostilitystatus-code
reportingdata-id
7382 [M-60]
7382 [M-60]
1
2
Hostile
Assumed friend
101
102
7382 [M-60]
885
[Guerrilla Group X]
885
[Guerrilla Group X]
33568891 [Hilltop Y]
3
1
Friend
Assumed involved
103
104
2
Friend
105
1
Hostile
106
202
V3.1.4
(b) REPORTING-DATA
*-category*-id
code
*-countingindicatorcode
*-credibility-code
Reported as plausible 20051201113000.000
*-reportingorganisation-id
[object-item-name-text]
[absolute]
146
[1 SP Div]
146
[1 SP Div]
101
Reported
—
102
Reported
—
Reported as a fact
20051201180000.000
[absolute]
103
Reported
—
Reported as a fact
20051202083000.000
[absolute]
104
Reported
—
Reported as a fact
20051115133000.000
[absolute]
105
Reported
—
Reported as a fact
20051117161500.000
[absolute]
106
Reported
—
Reported as a fact
20051130170500.000
[absolute]
843
[21 SP Bde]
177
[1 FR Div]
2244
[2 SP Div]
[14 UK Div]
(c) REPORTING-DATA-ABSOLUTE-TIMING
** reporting-data-id
**-effective-start-datetime
**-effective-end-datetime
101
102
103
104
105
106
20051201112000.000
20051201175500.000
20051202080500.000
20051115131500.000
20051117160500.000
20051130165500.000
—
—
—
—
—
—
Note: ** = "reporting-data-absolute-timing"
7.2
Introduction to OBJECT-ITEM-STATUS
7.2.1 The planning process and situational awareness require knowledge of the
status of various objects. The status refers to the capability of these objects to perform
their roles. This case is called operational status. For example, the operational status of a
tank could describe the degree of damage it has suffered, its current mobility, or its
capacity to fire its gun. The entity-level structure for capturing status is illustrated in the
figure below.
7.2.2 The subtypes of OBJECT-ITEM-STATUS refer directly to FACILITY,
MATERIEL, ORGANISATION, and PERSON. In case of FEATURE that has three
subtypes, specification of status was deemed to be inappropriate for METEOROLOGICFEATURE. Consequently, the status subtypes include only the two subtypes: CONTROLFEATURE and GEOGRAPHIC-FEATURE.
7.2.3 Three subtypes of OBJECT-ITEM-STATUS have subtypes of their own.
FACILITY-STATUS is subtyped into AIRFIELD-STATUS, MINEFIELD-MARITIMESTATUS and MEDICAL-FACILITY-STATUS; GEOGRAPHIC-FEATURE-STATUS
has the subtypes LIQUID-BODY-STATUS, LIQUID-SURFACE-STATUS and SOLIDSURFACE-STATUS; MATERIEL-STATUS has the subtypes MINE-STATUS and
UXO-STATUS.
7.2.4 The presentation of details in Section 7.3 follows the order of the figure
with the exception of MEDICAL-FACILITY-STATUS that is covered in Section 7.4.
203
V3.1.4
OBJECT-ITEM
has /
is-ascribed-to
OBJECT-ITEM-STATUS
FACILITY-STATUS
AIRFIELD-STATUS
LIQUID-BODY-STATUS
MATERIEL-STATUS
MINE-STATUS
UXO-STATUS
ORGANISATION-STATUS
PERSON-STATUS
Figure 66. Entity-Level View of OBJECT-ITEM-STATUS Subtype Tree
7.3
OBJECT-ITEM-STATUS and Its Subtypes
7.3.1 Specification of OBJECT-ITEM-STATUS
7.3.1.1 OBJECT-ITEM-STATUS is defined as "A record of the perceived
condition of a specific OBJECT-ITEM as determined by the reporting organisation." One
use of OBJECT-ITEM-STATUS is to allow multiple reports by independent observers of
the same OBJECT-ITEM. Another is to maintain the historical values of status as it
changes over time. The structure of OBJECT-ITEM-STATUS including its first-level
subtypes, is illustrated in the figure below.
204
V3.1.4
OBJECT-ITEM-STATUS
object-item-id (FK)
object-item-status-index
ORGANISATION-STATUS
object-item-status-booby-trap-presence-code
object-item-status-emission-control-code
organisation-status-id (FK)
object-item-status-index (FK)
organisation-status-operational-status-code
organisation-status-operational-status-qualifier-code
organisation-status-availability-code
organisation-status-command-and-control-role-code
organisation-status-commitment-status-code
organisation-status-fire-mode-code
organisation-status-cbrn-dress-state-code
organisation-status-radiation-dose-quantity
organisation-status-readiness-code
organisation-status-readiness-duration
organisation-status-reinforcement-code
organisation-status-reserve-indicator-code
organisation-status-training-code
organisation-status-usage-status-code
control-feature-status-id (FK)
control-feature-status-investigation-status-code
control-feature-status-cbrn-threat-level-code
control-feature-status-security-status-code
control-feature-status-usage-status-code
PERSON-STATUS
MATERIEL-STATUS
person-status-id (FK)
materiel-status-id (FK)
person-status-duty-status-code
person-status-physical-status-code
person-status-physical-status-qualifier-code
person-status-radiation-dose-quantity
person-status-reserve-indicator-code
materiel-status-body-colour-code
materiel-status-marking-code
materiel-status-marking-colour-code
materiel-status-demolition-status-code
materiel-status-imo-compliant-indicator-code
materiel-status-operational-status-code
materiel-status-operational-status-qualifier-code
materiel-status-operational-status-mode-code
materiel-status-reserve-indicator-code
materiel-status-safety-status-code
materiel-status-usage-status-code
materiel-status-buoy-malfunction-code
FACILITY-STATUS
facility-status-id (FK)
facility-status-demolition-status-code
facility-status-enemy-activity-condition-code
facility-status-mine-presence-code
facility-status-occupation-program-indicator-code
facility-status-operational-status-code
facility-status-operational-status-qualifier-code
facility-status-reserve-indicator-code
facility-status-security-status-code
facility-status-usage-status-code
geographic-feature-status-id (FK)
geographic-feature-status-mine-presence-code
geographic-feature-status-surface-recirculation-indicator-code
Figure 67. Specification of OBJECT-ITEM-STATUS and Its First-Level Subtypes
7.3.1.2 The attributes of OBJECT-ITEM-STATUS are:
a.
a specific OBJECT-ITEM and to distinguish it from all other OBJECTITEMs. It is a foreign key migrated by the identifying relationship "has/is
ascribed to" from OBJECT-ITEM. The attribute identifies the specific
OBJECT-ITEM that is the subject of a specific OBJECT-ITEM-STATUS
estimate.
b.
object-item-status-index—The unique value, or set of characters, assigned to
represent a specific OBJECT-ITEM-STATUS for a specific OBJECT-ITEM
and to distinguish it from all other OBJECT-ITEM-STATUSs for that
OBJECT-ITEM.
205
V3.1.4
c.
object-item-status-category-code—The specific value that represents the
class of OBJECT-ITEM-STATUS. It serves as a discriminator that partitions
OBJECT-ITEM-STATUS into subtypes. The domain values are:
CONTROL-FEATURE-STATUS; FACILITY-STATUS; GEOGRAPHICFEATURE-STATUS; MATERIEL-STATUS; ORGANISATION-STATUS;
PERSON-STATUS; Not known.
d.
object-item-status-booby-trap-presence-code—The specific value that
indicates whether a specific OBJECT-ITEM has been booby-trapped. The
domain values are: No; Unknown; Yes.
e.
object-item-status-emission-control-code—The specific value that represents
the emission control status of a specific OBJECT-ITEM. The domain values
are: EMCON 1; EMCON 2; EMCON 3.
f.
REPORTING-DATAs.
7.3.1.3 The use of OBJECT-ITEM-STATUS is illustrated in the table below. There
are several instances of OBJECT-ITEMs in all categories. For some of the items, more
than one status report exists as is indicated by the values of the index attribute. A set of
instances of REPORTING-DATA that are referred to by instances of OBJECT-ITEMSTATUS is illustrated in Sub-tables (b) and (c). These instances are cited in subsequent
sections in relation to examples for subtypes of status.
Table 81. Example Instances of OBJECT-ITEM-STATUS
(a) OBJECT-ITEM-STATUS
object-item-id
3051
[1 R IRISH]
3051
[1 R IRISH]
14486
14486
4
[SN 3-004-66772-09]
398
[1 UK Armd Div Dressing
Station 1]
890
[José Fernández Cuesta]
890
[José Fernández Cuesta]
891
[Ramiro de Maeztu
Barbeito]
*index
1
2
1
2
*-category-code
ORGANISATIONSTATUS
ORGANISATIONSTATUS
ORGANISATIONSTATUS
ORGANISATIONSTATUS
*-booby-trappresencecode
*-emissioncontrolreportingcode
data-id
—
EMCON 3
01
—
EMCON 3
02
—
—
04
—
—
05
1
MATERIEL-STATUS
Unknown
EMCON 3
06
1
FACILITY-STATUS
Yes
EMCON 3
07
1
PERSON-STATUS
No
—
09
2
PERSON-STATUS
No
—
10
1
PERSON-STATUS
No
—
11
Note: * = "object-item-status"
206
V3.1.4
(b) REPORTING-DATA36
**-counting**-category- indicator**-id
code
code
**-credibility-code
**-timingcategorycode
**-reportingorganisation-id
[absolute]
3051
[1 R Irish]
3051
[1 R Irish]
6337
[11 SP Br]
2244
[2 SP Div]
**-reporting-datetime
01
Reported
No
02
Reported
Yes
Reported as a fact
20051103091200.000
[absolute]
04
Reported
—
Reported as a fact
20051031160000.000
[absolute]
05
Reported
—
Reported as
uncertain
20051115171500.000
[absolute]
06
Reported
—
Reported as a fact
20051116134500.000
[absolute]
07
Reported
—
Reported as a fact
20051108090000.000
[absolute]
09
Reported
—
Reported as a fact
20050901131500.000
[absolute]
10
Reported
—
Reported as a fact
20050905131400.00
[absolute]
11
Reported
—
[absolute]
101 Reported
—
Reported as
20051111073200.000
uncertain
102 Reported
—
Reported as a fact
20051201180000.000
[absolute]
103 Reported
—
Reported as a fact
20051202083000.000
[absolute]
104 Reported
—
Reported as a fact
20051115133000.000
[absolute]
105 Reported
—
Reported as a fact
20051117161500.000
[absolute]
11
No
[absolute]
Reported
[absolute]
2112
[21 SP Br]
343
[1 UK Armd Div]
12
[15 PO Bn]
9398
[1 PO Bde]
952
[5 CA Bde]
146
[1 SP Div]
146
[1 SP Div]
843
[21 SP Bde]
177
[1 FR Div]
2244
[2 SP Div]
3051
[1 R Irish]
Note: ** = "reporting-data"
*** reporting-data-id
***-effective-start-datetime
***-effective-end-datetime
01
02
20051102110000.000
20051103090000.000
—
—
04
05
06
07
09
20051031154500.000
20051115171000.000
20051116131000.000
20051108083500.000
20050901123000.000
—
—
—
—
—
10
11
11
20050905131000.000
20051111071500.000
20051102110001.000
—
—
—
Note: *** = "reporting-data-absolute-timing"
7.3.2 Specification of CONTROL-FEATURE-STATUS
7.3.2.1 CONTROL-FEATURE-STATUS is defined as "An OBJECT-ITEMSTATUS that is a record of condition of a specific CONTROL-FEATURE." The
attributes are:
The dashed line at the right side of the table indicates that some attributes that are not
relevant to the example have been omitted.
36
207
V3.1.4
a.
control-feature-status-id—The control-feature-id of the CONTROLFEATURE that is the subject of a specific CONTROL-FEATURE-STATUS
b.
OBJECT-ITEM.
c.
control-feature-status-investigation-status-code—The specific value that
represents the investigation status of the site encompassed by a specific
CONTROL-FEATURE. The domain values are: Investigated, negative;
Investigated, positive; Investigation denied; None; Under investigation; Not
known.
d.
control-feature-status-cbrn-threat-level-code—The specific value that
represents the assessed CBRN threat level status of a specific CONTROLFEATURE that defines a given operational area for friendly forces. The
domain values are: High; Medium; Low.
e.
control-feature-status-security-status-code—The
specific
value
that
represents the protection status of the site encompassed by a specific
CONTROL-FEATURE. The domain values are: Guarded; None; Secured;
Not known.
f.
control-feature-status-usage-status-code—The specific value that represents
the usage of a specific CONTROL-FEATURE. The domain values are:
Activated; Deactivated; Not known. The domain value set for this attribute is
shared with one or more other attributes and is defined in the set usagestatus-code.
7.3.2.2 Example of status for individual objects is provided in the table below. The
example conveys the following information:
a.
Control Feature 427 is planned to become an artillery area. The first statusreport is made as soon as it has been identified for that purpose, but it is
currently outside own control. The second status-report is made when the
area is being watched so that entry to the area can be controlled/reported, but
no detailed investigation of the area has been done. The third status-report is
issued when an artillery unit has taken actual control of the area.
b.
Control Feature 7826 is a planned crossing site that is suspected of being
mined. An investigation of the area has been initiated, as reported in the first
status-report. The next report is issued when the investigation is finished and
the area is under visual control. The third report is sent when troops have
arrived at the site and secured it against hostile takeover.
208
V3.1.4
Table 82. Examples of CONTROL-FEATURE-STATUS
*-id
*-investigationstatus-code
*-cbrn-threatlevel-code
*-securitystatus-code
*-usagestatus-code
1
Not known
—
None
Deactivated
2
None
—
Guarded
Deactivated
3
None
—
Secured
Activated
1
Under investigation
—
None
Deactivated
2
Investigated,
negative
—
—
Guarded
Deactivated
—
Secured
Activated
427
[Artillery area]
427
[Artillery area]
427
[Artillery area]
7826
[Crossing site]
7826
[Crossing site]
7826
[Crossing site]
3
Note: * = "control-feature-status"
7.3.3 Specification of FACILITY-STATUS and Its Subtypes
The specifications for FACILITY-STATUS is presented in Section 7.3.3.1.
FACILITY-STATUS has the subtypes AIRFIELD-STATUS, MINEFIELD-MARITIMESTATUS and MEDICAL-FACILITY-STATUS, as illustrated in the figure below.
FACILITY-STATUS
facility-status-id (FK)
facility-status-demolition-status-code
facility-status-enemy-activity-condition-code
facility-status-mine-presence-code
facility-status-occupation-program-indicator-code
facility-status-operational-status-code
facility-status-operational-status-qualifier-code
facility-status-reserve-indicator-code
facility-status-security-status-code
facility-status-usage-status-code
AIRFIELD-STATUS
airfield-status-id (FK)
airfield-status-day-operations-code
airfield-status-flight-support-category-code
airfield-status-evaluation-indicator-code
airfield-status-maximum-nbac-throughput-count
airfield-status-maximum-nbac-park-count
airfield-status-maximum-wbac-throughput-count
airfield-status-maximum-wbac-park-count
medical-facility-status-id (FK)
minefield-maritime-status-id (FK)
minefield-maritime-status-code
minefield-maritime-status-colour-code
minefield-maritime-status-expected-level-mcm-code
minefield-maritime-status-mines-detected-quantity
minefield-maritime-status-mines-detected-count
minefield-maritime-status-mine-zone-risk-code
minefield-maritime-status-seeding-code
minefield-maritime-status-swept-depth-quantity
minefield-maritime-status-threat-ratio
minefield-maritime-status-mine-detection-code
minefield-maritime-status-mines-count
medical-facility-status-surgery-backlog-duration
Figure 68. Subtypes of FACILITY-STATUS
209
V3.1.4
7.3.3.1
Specification of FACILITY-STATUS
7.3.3.1.1 FACILITY-STATUS is defined as "An OBJECT-ITEM-STATUS that
is a record of condition of a specific FACILITY." Its attributes are:
a.
facility-status-id—The facility-id of the FACILITY that is the subject of a
specific FACILITY-STATUS (a role name for object-item-id).
b.
OBJECT-ITEM.
c.
facility-status-category-code—The specific value that represents the class of
FACILITY-STATUS. It serves as a discriminator that partitions FACILITYSTATUS into subtypes. The domain values are: AIRFIELD-STATUS;
MINEFIELD-MARITIME-STATUS; MEDICAL-FACILITY-STATUS; Not
d
facility-status-demolition-status-code—The specific value that represents the
status of a specific FACILITY destined for demolition. Example domain
values are: Abandoned incomplete; Executed; Planned reserve; Prepared for
execution; State 1. The domain value set for this attribute is shared with one
or more other attributes and is defined in the set demolition-status-code.
e.
facility-status-enemy-activity-condition-code—The specific value that
represents the status of enemy activity around or at the FACILITY. The
domain values are: Cold; Hot.
f.
facility-status-mine-presence-code—The specific value that indicates
whether a specific FACILITY contains mines. The domain values are: No;
Yes; Not known. The domain value set for this attribute is shared with one or
more other attributes and is defined in the set mine-presence-code.
g.
facility-status-occupation-program-indicator-code—The specific value that
indicates whether an occupation programme is present at the facility. The
h.
facility-status-operational-status-code—The specific value that represents the
operational status of a specific FACILITY. The domain values are:
Marginally operational; Not operational; Operational; Substantially
operational; Temporarily not operational; Not known.
i.
facility-status-operational-status-qualifier-code—The specific value that
represents the qualification of the operational status of a specific FACILITY.
Example domain values are: Breached; Covered by fire; Denied, Destroyed;
Heavily damaged; Lacking vital resources; Lightly damaged; Lost; Marked;
Moderately damaged; Passable; Prepared for execution; Under construction;
Not known.
j.
facility-status-reserve-indicator-code—The specific value that represents
whether a specific FACILITY has been placed in reserve. The domain values
are: No; Yes.
k.
facility-status-security-status-code—The specific value that represents the
security status of a specific FACILITY. The domain values are: Guarded;
None; Secured; Not known.
210
V3.1.4
l.
facility-status-usage-status-code—The specific value that represents the
usage of a specific FACILITY. The domain values are: Activated;
Deactivated; Not known. The domain value set for this attribute is shared
with one or more other attributes and is defined in the set usage-status-code.
7.3.3.1.2 Example of status for individual objects is provided in the table below.
The example conveys the following information:
a.
Facility 398 is a dressing station just opened by 1 UK Armoured Division.
b.
Facility 7749 is an airfield situated near Vandel in Denmark that—although
still able to operate—has been prepared for demolition. The second report is
issued after demolition was executed but was not completely successful.
c.
Facility 92634 is a hostile maintenance facility, still in action and secured by
enemy troops. The second report is sent after the successful destruction of
the facility in an air raid.
Table 83. Examples of FACILITY-STATUS
FACILITY-STATUS
*-id
[object-item-nametext]
objectitemstatusindex
398
[1 UK Armd Div
Dressing Station 1]
7749
[Vandel Airfield (DNK)]
7749
[Vandel Airfield (DNK)]
92634
[Hostile Maintenance
facility]
92634
[Hostile Maintenance
facility]
1
1
2
1
2
*-categorycode
*-demolitionstatus-code
*-enemyactivityconditioncode
MEDICALFACILITYSTATUS
Not otherwise
specified
Not otherwise
specified
Not otherwise
specified
Not known
—
No
Unknown
Prepared for
execution
Abandoned
incomplete
Not known
—
No
—
—
No
—
—
Not known
Unknown
—
—
—
—
Not otherwise
specified
*-minepresencecode
*-occupationprogramindicator-code
Note: * = "facility-status"
*-operationalstatus-code
*-operational-statusqualifier-code
*-reserveindicator-code
*-securitystatus-code
*-usagestatus-code
Substantially
operational
Operational
Not operational
Operational
Not operational
—
—
—
Activated
—
Moderately damaged
—
Destroyed
Yes
No
—
—
Guarded
Secured
Secured
None
Deactivated
Deactivated
In action
Deactivated
7.3.3.2
Specification of AIRFIELD-STATUS
7.3.3.2.1 AIRFIELD-STATUS is defined as "A FACILITY-STATUS that is a
record of conditions of a specific AIRFIELD." The attributes are:
a.
airfield-status-id—The facility-id for a specific AIRFIELD (a role name for
object-item-id).
b.
211
V3.1.4
OBJECT-ITEM.
c.
airfield-status-day-operations-code—The specific value that indicates the
status of a specific AIRFIELD to only operate during daylight. The domain
values are: Both; Day; Night; Not known.
d
airfield-status-flight-support-category-code—The specific value that
indicates the capability of a specific AIRFIELD to function under defined
flight rules. The domain values are: IFR; VFR; Not known.
e.
airfield-status-evaluation-indicator-code—The specific value that indicates
that an AIRFIELD has been checked and its characteristics have been
verified. The domain values are: No; Yes.
f.
airfield-status-maximum-nbac-throughput-count—The
integer
value
representing the maximum count of narrow body civilian aircrafts (NBAC)
that specific AIRFIELD can process per day.
g.
airfield-status-maximum-nbac-park-count—The integer value representing
the maximum count of narrow body civilian aircrafts (NBAC) that can be
parked at a specific AIRFIELD at one time.
h.
airfield-status-maximum-wbac-throughput-count—The
integer
value
representing the maximum count of wide body civilian aircrafts (WBAC)
that specific AIRFIELD can process per day.
i.
airfield-status-maximum-wbac-park-count—The integer value representing
the maximum count of wide body civilian aircrafts (WBAC) that can be
parked at a specific AIRFIELD at one time.
7.3.3.2.2 An example of AIRFIELD-STATUS usage is in the table below.
Table 84. Instances of AIRFIELD-STATUS
AIRFIELD-STATUS
*-id
*-day-operationscode
*-flight-supportcategory-code
*-evaluationindicator-code
4311
6443
6600
905444
1
1
1
1
Both
Day
Both
Both
IFR
VFR
IFR
IFR
Yes
No
Yes
Yes
Note: * = "airfield-status"
*-maximum-nbacthroughput-count
*-maximum-nbacpark-count
*-maximum-wbacthroughput-count
*-maximum-wbacpark-count
100
54
153
160
20
6
25
34
100
25
75
85
10
3
10
20
7.3.3.3
Specification of MINEFIELD-MARITIME-STATUS
7.3.3.3.1 MINEFIELD-MARITIME-STATUS is defined as "A FACILITYSTATUS that is a record of condition of a specific MINEFIELD-MARITIME." The
attributes are:
212
V3.1.4
a.
minefield-maritime-status-id—The facility-id of the MINEFIELDMARITIME that is the subject of a specific MINEFIELD-MARITIMESTATUS (a role name for object-item-id).
b.
OBJECT-ITEM.
c.
minefield-maritime-status-code—The specific value that represents the
known status of a MINEFIELD-MARITIME. The domain values are:
Closed; Open.
d.
minefield-maritime-status-colour-code—The specific value that represents
the known status of mined channels of a MINEFIELD-MARITIME. The
domain values are: Green; Red; Yellow.
e.
minefield-maritime-status-expected-level-mcm-code—The specific values of
expected mine countermeasures (MCM) to be employed against a
MINEFIELD-MARITIME. The domain values are: Heavy MCM; Light
MCM; Moderate MCM; No MCM.
f.
minefield-maritime-status-mines-detected-quantity—The numeric value
representing the number of mines detected in a specific MINEFIELDMARITIME.
g.
minefield-maritime-status-mines-detected-count—The
integer
value
representing the number of mines detected in a specific MINEFIELDMARITIME at the time of the report.
h.
minefield-maritime-status-mine-zone-risk-code—The specific value that
represents the known threat (risk) of a MINEFIELD-MARITIME. The
domain values are: Little; Serious; Very great.
i.
minefield-maritime-status-seeding-code—The specific value that indicates
the seeding details for a MINEFIELD-MARITIME. Example domain values
are: Initial implant; Second reseeding; Fourth reseeding; Ninth reseeding.
j.
minefield-maritime-status-swept-depth-quantity—The
numeric
value
representing the depth below the surface to which minesweeping has taken
place. The unit of measure is metres.
k.
minefield-maritime-status-threat-ratio—The numeric quotient value that
represents the current percentage threat to the enemy of a specific
MINEFIELD-MARITIME. The value must be in the range from 0 to 1.
l.
minefield-maritime-status-mine-detection-code—The specific value that
represents the status of the means of detection of a mine in a MINEFIELDMARITIME. Example domain values are: Sighted; Swept acoustic, AF;
Swept mechanical; Swept, bottom team sweep.
m.
minefield-maritime-status-mines-count—The integer value representing the
number of mines within a specific maritime minefield at the time of the
report.
213
V3.1.4
7.3.3.3.2 An example of MINEFIELD-MARITIME-STATUS usage is in the
table below.
Table 85. Instances of MINEFIELD-MARITIME-STATUS
*-id
27
[Port Alpha
Defence]
28
[Landing Area
Bravo]
27
28
*-code
*-colourcode
*-expected-level-mcmcode
*-mines-detectedquantity
1
Open
Amber
High MCM
3
1
Closed
Red
Moderate MCM
15
2
2
—
Closed
—
Yellow
—
Moderate MCM
—
15
Note: * = "minefield-maritime-status"
*-minesdetected-count
*-mine-zonerisk-code
*-seedingcode
*-swept-depthquantity
*-threatratio
*-minedetection-code
*-minescount
—
15
—
—
Serious
—
Initial implant
—
First
reseeding
—
0.75
—
—
—
—
—
Sighted
—
20
—
10
Serious
—
100
—
Swept
mechanical
influence
25
—
7.3.4 Specification of GEOGRAPHIC-FEATURE-STATUS and Its
Subtypes
GEOGRAPHIC-FEATURE-STATUS and its three subtypes are illustrated in the
figure below. The entities are included in order to be able to represent the dynamic aspects
of solid and water surfaces. Their specifications are presented below.
7.3.4.1
Specification of GEOGRAPHIC-FEATURE-STATUS
7.3.4.1.1 GEOGRAPHIC-FEATURE-STATUS is defined as "An OBJECTITEM-STATUS that is a record of condition of a specific GEOGRAPHIC-FEATURE."
The attributes are:
a.
geographic-feature-status-id—The
geographic-feature-id
of
the
GEOGRAPHIC-FEATURE that is the subject of a specific GEOGRAPHICFEATURE-STATUS (a role name for object-item-id).
b.
OBJECT-ITEM.
214
V3.1.4
geographic-feature-status-id (FK)
geographic-feature-status-mine-presence-code
geographic-feature-status-surface-recirculation-indicator-code
LIQUID-BODY-STATUS
liquid-body-status-id (FK)
liquid-surface-status-id (FK)
liquid-body-status-bottom-current-rate
liquid-body-status-thermal-layer-depth-quantity
liquid-body-status-tidal-stream-rate
liquid-body-status-underwater-visibility-quantity
liquid-surface-status-sea-state-code
liquid-surface-status-surface-condition-code
liquid-surface-status-wave-direction-code
solid-surface-status-id (FK)
solid-surface-status-code
solid-surface-status-demolition-status-code
solid-surface-status-surface-condition-code
solid-surface-status-surface-firmness-code
solid-surface-status-vegetation-category-code
solid-surface-status-vegetation-subcategory-code
Figure 69. GEOGRAPHIC-FEATURE-STATUS and Its Subtypes
c.
geographic-feature-status-category-code—The specific value that represents
the class of GEOGRAPHIC-FEATURE-STATUS. It serves as a
discriminator that partitions GEOGRAPHIC-FEATURE-STATUS into
subtypes. The domain values are: LIQUID-BODY-STATUS; LIQUIDSURFACE-STATUS; SOLID-SURFACE-STATUS.
d.
geographic-feature-status-mine-presence-code—The specific value that
indicates whether a specific GEOGRAPHIC-FEATURE contains mines. The
domain values are: No; Yes; Not known. The domain value set for this
mine-presence-code.
e.
geographic-feature-status-surface-recirculation-indicator-code—The specific
value that indicates whether the surface will recirculate as a result of rotor
downwash. The domain values are: No; Yes.
215
V3.1.4
a.
Geographic Feature 33 is Hilltop Y, which is currently under hostile control.
First report indicates that the surface of the hilltop is firm earth covered with
grass and can carry light helicopters, but it is not known whether the area is
mined. The second report is issued after friendly troops/units have taken
control of the hilltop and have not detected any mines.
b.
Geographic Feature 44 is a mountain pass that has been selected for use in an
operation. The first status-report only informs about the surface conditions
indicating that the surface may recirculate and that it is unknown whether the
pass is mined or not. The second report indicates that the pass is mined. The
third report is issued after own troops/units have cleared the mines and have
gained control of the pass and surface condition information is updated.
c.
Geographic Feature 55 is Lake Ontario. The first report indicates small
waves from West. The second report indicates higher waves from South,
while the third report indicates no waves. No mines are indicated in any
reports.
d.
Geographic Feature 66 is Loch Ness. The first report indicates the depth of
the thermal layer and visibility, and indicates that there are mines present.
The second report updates the thermal layer and visibility information, and
no mines were found (it was only Nessie that was spotted).
Table 86. Examples of GEOGRAPHIC-FEATURE-STATUS
*-id
*-minepresence-code
*-surface-recirculationindicator-code
SOLID-SURFACESTATUS
SOLID-SURFACESTATUS
SOLID-SURFACESTATUS
SOLID-SURFACESTATUS
SOLID-SURFACESTATUS
LIQUID-SURFACESTATUS
Not known
No
No
No
Not known
Yes
Yes
—
No
Yes
No
—
No
—
No
—
*-category-code
33
[Hilltop Y, Hostile]
1
33
2
44
[Mountain pass]
44
1
2
44
3
55
[Lake Ontario]
55
1
2
55
3
66
[Loch Ness]
66
1
LIQUID-BODYSTATUS
Yes
—
2
LIQUID-BODYSTATUS
No
—
Note: * = "geographic-feature-status"
216
V3.1.4
7.3.4.2
Specification of LIQUID-SURFACE-STATUS
7.3.4.2.1 LIQUID-SURFACE-STATUS is defined as "A GEOGRAPHICFEATURE-STATUS that is a record of condition of a specific liquid surface." The
attributes are:
a.
liquid-surface-status-id—The geographic-feature-id of the GEOGRAPHICFEATURE that is the subject of a specific LIQUID-SURFACE-STATUS (a
b.
OBJECT-ITEM.
c.
liquid-surface-status-sea-state-code—The specific value that represents a
range of wave heights on a specific liquid surface. Example domain values
are: Calm (glassy); Slight; Rough; High; Phenomenal.
d.
liquid-surface-status-surface-condition-code—The specific value that
represents the physical status of a liquid surface area. The domain values are:
Drained; Ice; Liquid; Mixed; Not known.
e.
liquid-surface-status-wave-direction-code—The
specific
value
that
represents the direction of waves in a specific liquid surface. Example
domain values are: East; North; South; West. The domain value set for this
direction-code.
Table 87. Examples of LIQUID-SURFACE-STATUS
*-id
object-item-status*-surfaceindex
*-sea-state-code condition-code
55
55
1
2
55
3
*-wave-direction-code
Calm (rippled)
Slight
Liquid
Liquid
West
South
Calm (glassy)
Liquid
—
Note: * = "liquid-surface-status"
7.3.4.3
Specification of SOLID-SURFACE-STATUS
7.3.4.3.1 SOLID-SURFACE-STATUS is defined as "A GEOGRAPHICFEATURE-STATUS that is a record of condition of a specific solid surface." The
attributes are:
a.
solid-surface-status-id—The geographic-feature-id of the GEOGRAPHICFEATURE that is the subject of a specific SOLID-SURFACE-STATUS (a
b.
217
V3.1.4
OBJECT-ITEM.
c.
solid-surface-status-code—The specific value that represents the status of a
specific solid surface. The domain values are: Cleared; Contaminated,
Destroyed; Heavily damaged; Lightly damaged; Moderately damaged;
Obstructed; Not known.
d.
solid-surface-status-demolition-status-code—The specific value that
represents the status of an object destined for demolition. Example domain
values are: Abandoned incomplete; Executed; Planned reserve; Prepared for
execution; State 1. The domain value set for this attribute is shared with one
or more other attributes and is defined in the set demolition-status-code.
e.
solid-surface-status-surface-condition-code—The specific value that
represents the physical status of a solid surface area. The domain values are:
Dust; Earth; Flood; Ice; Sand; Snow; Not known; Not otherwise specified.
f.
solid-surface-status-surface-firmness-code—The
specific
value
that
represents the firmness of a surface area, in terms of its ability to support
land vehicles or helicopters. The domain values are: Hard; Moderate; Soft;
Very soft.
g.
solid-surface-status-vegetation-category-code—The specific value that
represents the general vegetation class of a specific SOLID-SURFACESTATUS. Example domain values are: Bare; Jungle; Wetlands; Woodland.
The domain value set for this attribute is shared with one or more other
attributes and is defined in the set vegetation-category-code.
h.
solid-surface-status-vegetation-subcategory-code—The specific value that
represents the detailed vegetation class of a specific SOLID-SURFACESTATUS. Example domain values are: Cropland; Grass/scrub/brush; Marsh;
Tundra. The domain value set for this attribute is shared with one or more
other attributes and is defined in the set vegetation-subcategory-code.
7.3.4.3.2 The business rules for relating solid-surface-status-vegetation-categorycode and solid-surface-status-vegetation-subcategory-code for SOLID-SURFACESTATUS are specified in Annex G2, Section G2.3.3.
Table 88. Examples of SOLID-SURFACE-STATUS
*-id
33
33
44
44
44
1
2
1
2
3
*-code
*demolition
-statuscode
*-surfaceconditioncode
*-surfacefirmnesscode
*vegetationcategorycode
*vegetationsubcategory
-code
Not known
Cleared
Not known
Obstructed
Cleared
—
—
—
—
—
Earth
Earth
Not known
—
Sand
Moderate
Moderate
—
Hard
Hard
Rangeland
Rangeland
—
Bare
Bare
Grassland
Grassland
—
—
—
Note: * = "solid-surface-status"
218
V3.1.4
7.3.4.4
Specification of LIQUID-BODY-STATUS
7.3.4.4.1 LIQUID-BODY-STATUS is defined as "A GEOGRAPHICFEATURE-STATUS that is a record of condition of a specific liquid body." The attributes
are:
a.
liquid-body-status-id—The geographic-feature-id of the GEOGRAPHICFEATURE that is the subject of a specific LIQUID-BODY-STATUS (a role
b.
OBJECT-ITEM.
c.
liquid-body-status-bottom-current-rate—The numeric value that denotes the
rate of the liquid movement at the bottom surface of the sea. The unit of
measure is knots. The specified value must be greater than or equal to 0
(zero).
d.
liquid-body-status-thermal-layer-depth-quantity—The numeric value that
represents the distance below the liquid surface where the distinct interface
between surface waters and cooler waters; regions between warmer upper
layer (epilimnion) and the lower cold layer (hypolimnion) of the liquid where
temperature declines abruptly (1 degree C or more per meter) with increasing
depth. The unit of measure is metres.
e.
liquid-body-status-tidal-stream-rate—The numeric value that represents the
horizontal water movements due to tidal forcing. The unit of measure is
knots. The specified value must be greater than or equal to 0 (zero).
f.
liquid-body-status-underwater-visibility-quantity—The numeric value that
represents the distance at which an object disappears given the ambient light,
suspended organic and inorganic particulate measure, dissolved substances,
plankton and the waters molecular structure. The unit of measure is metres.
Table 89. Examples of LIQUID-BODY-STATUS
LIQUID-BODY-STATUS
*-id
*-bottomcurrent-rate
*-thermal-layerdepth-quantity
*-tidal-streamrate
*-underwatervisibility-quantity
66
1
0.0
20.0
0.0
20.0
66
2
0.0
10.0
0.0
5.0
Note: * = "liquid-body-status"
7.3.5 Specification of MATERIEL-STATUS and Its Subtypes
The structure for MATERIEL-STATUS and its two subtypes—MINE-STATUS
and UXO-STATUS—is illustrated in the figure below. The acronym UXO is an accepted
military abbreviation for unexploded ordnance. The specifications of MATERIEL-
219
V3.1.4
STATUS, MINE-STATUS, and UXO-STATUS are presented in Sections 7.3.5.1, 7.3.5.2,
and 7.3.5.3, respectively.
MA TERIEL-STATUS
materiel-s tatus-id (FK)
materiel-s tatus-category-code
materiel-s tatus-body-colour-code
materiel-s tatus-marking-code
materiel-s tatus-marking-colour-code
materiel-s tatus-demolition-status-code
materiel-s tatus-imo-compliant-indicator-code
materiel-s tatus-operational-status-code
materiel-s tatus-operational-status-qualif ier-code
materiel-s tatus-operational-status-mode-code
materiel-s tatus-res erve-indicator-code
materiel-s tatus-saf ety-status-code
materiel-s tatus-usage-status-code
materiel-s tatus-buoy-malfunc tion-code
materiel-s tatus-category-code
UXO-STA TUS
uxo-status-id (FK)
uxo-status-exposure-code
uxo-status-qualif ier-code
MINE-STA TUS
mine-status-id (FK)
mine-status-mine-buried-ratio
mine-status-code
mine-status-air-drop-eff ect-c ode
mine-status-maritime-mine-qualif ier-code
Figure 70. MATERIEL-STATUS and Its Subtypes MINE-STATUS and UXO-STATUS
7.3.5.1
Specification of MATERIEL-STATUS
7.3.5.1.1 MATERIEL-STATUS is defined as "An OBJECT-ITEM-STATUS that
is a record of condition of a specific MATERIEL." The attributes are:
a.
materiel-status-id—The materiel-id of the MATERIEL that is the subject of
a specific MATERIEL-STATUS (a role name for object-item-id).
b.
OBJECT-ITEM.
c.
materiel-status-category-code—The specific value that represents the class of
MATERIEL-STATUS. It serves as a discriminator that partitions
MATERIEL-STATUS into subtypes. The domain values are: MINESTATUS; UXO-STATUS; Not otherwise specified.
d.
materiel-status-body-colour-code—The specific value that represents the
current colour scheme of a specific MATERIEL. Example domain values
are: Auburn; Chrome; Grey; Maroon; Multicoloured; Yellow; Not known.
220
V3.1.4
e.
materiel-status-marking-code—The specific value that represents the type of
marking of a specific MATERIEL. The domain values are: Numbers; Stripe;
Stripes; Symbols; Writing; Not known; Not otherwise specified.
f.
materiel-status-marking-colour-code—The specific value that represents the
colour of the markings of a specific MATERIEL. Example domain values
are: Black; Blue; Orange; Purple; White; Not known.
g.
materiel-status-demolition-status-code—The specific value that represents
the status of a specific MATERIEL destined for demolition. Example
domain values are: Abandoned incomplete; Executed; Planned reserve;
Prepared for execution; State 1. The domain value set for this attribute is
shared with one or more other attributes and is defined in the set demolitionstatus-code.
h.
materiel-status-imo-compliant-indicator-code—The specific value that
indicates whether a vessel complies with International Maritime
Organisation standards. The domain values are: No; Yes.
i.
materiel-status-operational-status-code—The specific value that represents
the operational status of a specific MATERIEL. The domain values are:
Marginally operational; Not operational; Operational; Substantially
operational; Temporarily not operational; Not known.
j.
materiel-status-operational-status-qualifier-code—The specific value that
represents the qualification of the operational status of a specific
MATERIEL. Example domain values are: Denied; Destroyed; Heavily
damaged; Lacking vital resources; Lightly damaged; Lost; Moderately
damaged; Not known.
k.
materiel-status-operational-status-mode-code—The specific value that
represents the firepower or mobility or communications degradation of a
specific MATERIEL. Example domain values are: Communications only;
Firepower only; Mobility and firepower; Mobility only; Not known.
l.
materiel-status-reserve-indicator-code—The specific value that represents
whether a specific MATERIEL has been placed in reserve. The domain
m.
materiel-status-safety-status-code—The specific value that represents the
arming state of a specific MATERIEL that is a weapon or ammunition. The
domain values are: Armed; Neutralized; Safe; Unassembled; Not known.
n.
materiel-status-usage-status-code—The specific value that represents the
usage of a specific MATERIEL that is a weapon or ammunition. The domain
values are: Activated; Deactivated; Not known. The domain value set for this
usage-status-code.
o.
materiel-status-buoy-malfunction-code—The specific value that represents
the type of malfunction of a buoy. The domain values are: No flag; No radar
reflection; Buoy not in sight; Serviceable buoy has dragged its position; No
light.
221
V3.1.4
a.
Materiel 4 with Serial Number 3-004-66772-09 is reported marginally
operational due to heavy damage. The damage has affected both mobility
and firepower capabilities. It has been deactivated (taken out of action).
b.
Materiel 11 is an M-60 tank that is reported as (fully) operational without
any damage. The third status entry (*-id 11, Index 3) shows’the M-60 to be
lightly damaged with respect to firepower. Although operational, it has been
taken out of action (probably for repair).
Table 90. Examples of MATERIEL-STATUS
MATERIEL-STATUS
*-categorycode
*-body-colourcode
*-markingcode
*markingcolourcode
1
Not otherwise
specified
Beige
Not known
Not known
—
—
1
Not otherwise
specified
Not otherwise
specified
Not otherwise
specified
Camouflage,
desert, grey
Camouflage,
desert, grey
Camouflage,
desert, grey
Not known
Grey
—
—
Not known
Grey
—
—
Not known
Grey
—
—
MINE-STATUS
MINE-STATUS
MINE-STATUS
—
—
—
—
—
—
—
—
—
—
—
—
—
*-id
*demolitionstatus-code
*-imocompliantindicatorcode
4
[SN 3-00466772-09]
11
[M-60 Tank]
11
2
11
3
22
22
23
1
2
4
23
5
UXO-STATUS
—
—
—
—
—
Prepared for
execution
—
23
6
MINE-STATUS
—
—
—
Executed
*-reserveindicatorcode
*-safetystatuscode
*-usagestatus-code
—
Note: * = "materiel-status"
*-operational*-operationalstatus-qualifierstatus-mode-code
code
*-buoymalfunctioncode
Marginally
operational
Heavily damaged
Mobility and
firepower
—
—
Deactivated
Operational
Operational
Operational
Operational
Operational
Not known
—
Lightly damaged
—
—
—
—
Firepower only
—
—
—
—
Yes
—
—
—
—
—
Armed
Armed
Activated
Activated
Deactivated
Activated
Activated
—
—
Operational
—
Not operational
—
—
—
—
—
—
—
—
—
Armed
Armed
Neutralized
—
—
—
—
—
—
7.3.5.2
Specification of MINE-STATUS
7.3.5.2.1 MINE-STATUS is defined as "A MATERIEL-STATUS that is a record
of condition of a specific mine." The attributes are:
a.
mine-status-id—The materiel-id of the MATERIEL that is the subject of a
specific MINE-STATUS (a role name for object-item-id).
222
V3.1.4
b.
OBJECT-ITEM.
c.
mine-status-mine-buried-ratio—The numeric quotient value that represents
the percentage of the maritime mine that is buried. The value must be in the
range from 0 to 1.
d.
mine-status-code—The specific value that represents the status of a mine.
Example domain values are: Activated mine; Classified mine; Removed
mine; Rendered safe mine.
e.
mine-status-air-drop-effect-code—The specific value that represent the
behaviour of air-delivered mine after weapon release. Example domain
values are: Parachute malfunction; Parachute and arm malfunction, skip,
broke up; Arm malfunction; Unknown.
f.
mine-status-maritime-mine-qualifier-code—The
specific
value
that
represents the qualification status of a specific maritime mine. Example
domain values are: Countermined; Exploded right side; Neutralized;
Rendered safe.
7.3.5.2.2 Example of status for individual objects that are mines is provided in
the table below.
Table 91. Examples of MINE-STATUS
MINE-STATUS
*-id
*-mine-buried-ratio
*-code
*-air-drop-effect-code
*-mine-qualifier-code
22
1
.1
Normal
—
22
1
.5
Normal
—
23
4
.3
—
—
23
6
—
Activated
mine
Activated
mine
Identified
mine
Rendered
safe mine
—
—
Note: * = "mine-status"
7.3.5.3
Specification of UXO-STATUS
7.3.5.3.1 UXO-STATUS is defined as "A MATERIEL-STATUS that is a record
of the condition of an explosive ordnance that has been primed, fused, armed, or otherwise
prepared for action, and which has been fired, dropped, launched, placed in such a manner,
as to constitute a hazard to operation, and remains unexploded either by malfunction or for
any other cause." The attributes are:
a.
uxo-status-id—The materiel-id of the MATERIEL that is the subject of a
specific UXO-STATUS (a role name for object-item-id).
b.
OBJECT-ITEM.
223
V3.1.4
c.
uxo-status-exposure-code—The specific value that represents the visual
status of a specific Unexploded Explosive Ordnance. The domain values are:
Fully exposed; Partially exposed; Partially exposed, body; Partially exposed,
nose; Partially exposed, side; Partially exposed, tail; Unexposed; Not known;
d.
uxo-status-qualifier-code—The specific value that represents the
qualification status of a specific Unexploded Explosive Ordnance. The
domain values are: Broken; Intact; Leaking; New; Old; Rusted; Not known;
7.3.5.3.2 Example of status for individual objects that are unexploded ordnance
(UXOs) is provided in the table below.
Table 92. Examples of UXO-STATUS
UXO-STATUS
*-id
object-item-status-index
*-exposure-code
*-qualifier-code
23
5
Partially exposed, body
Intact
Note: * = "uxo-status"
7.3.6 Specification of ORGANISATION-STATUS
ORGANISATION-STATUS is defined as "An OBJECT-ITEM-STATUS that is a
record of condition of a specific ORGANISATION." The attributes are:
a.
organisation-status-id—The organisation-id of the ORGANISATION that is
the subject of a specific ORGANISATION-STATUS (a role name for
object-item-id).
b.
OBJECT-ITEM.
c.
organisation-status-operational-status-code—The specific value that
represents the operational status of a specific ORGANISATION. The
domain values are: Marginally operational; Not operational; Operational;
Substantially operational; Temporarily not operational; Not known.
d.
organisation-status-operational-status-qualifier-code—The specific value
that represents the qualification of the operational status of a specific
ORGANISATION. Example domain values are: Destroyed; Heavily
damaged; Lacking vital resources; Lightly damaged; Lost; Moderately
damaged; Not known.
e.
organisation-status-availability-code—The specific value that gives the
availability status of an ORGANISATION without regard to readiness.
Example domain values are: After 30 days; Between 48 hours and 4 days;
Within 48 hours.
f.
organisation-status-command-and-control-role-code—The specific value that
represents the role played by a command and control ORGANISATION.
Example domain values are: Advanced command post; Peace headquarters;
Static command post; Tactical command post.
224
V3.1.4
g.
organisation-status-commitment-status-code—The specific value that gives
the commitment status of an ORGANISATION. The domain values are:
Committed; Uncommitted.
h.
organisation-status-fire-mode-code—The specific value that represents the
status of weapons employment constraint for a specific ORGANISATION.
The domain values are: Hold fire; Weapons free; Weapons hold; Weapons
tight; Not known.
i.
organisation-status-cbrn-dress-state-code—The specific value that represents
the Mission Oriented Protective Posture (MOPP) status defining the NBC
(CBRN) dress code of a specific ORGANISATION. The domain values are:
MOPP ready; MOPP 0; MOPP 1; MOPP 2; MOPP 3.
j.
organisation-status-radiation-dose-quantity—The numeric value that
represents the average radiation dose to which the members of an
organisation have been exposed. The unit of measure is centiGray (cGy).
k.
organisation-status-readiness-code—The specific value that gives the
readiness level of an ORGANISATION. Example domain values are: Battle
stations; Runway alert; Not otherwise specified.
l.
organisation-status-readiness-duration—The numeric value that represents a
quantity of time in milliseconds reflecting the maximum interval in which an
ORGANISATION is to respond to an immediate order.
m.
organisation-status-reinforcement-code—The specific value that represents
whether a specific ORGANISATION has additional or detached strength.
The domain values are: Detached only; Normal strength; Reinforced and
detached; Reinforced only; Not known.
n.
organisation-status-reserve-indicator-code—The
specific
value
that
represents whether a specific ORGANISATION has been placed in reserve.
The domain values are: No; Yes.
o.
organisation-status-training-code—The specific value that represents the
assessed training status of a specific ORGANISATION. The domain values
are: Amber; Green; Red; Not known.
p.
organisation-status-usage-status-code—The specific value that represents the
usage of a specific ORGANISATION. The domain values are: In action; Out
of action; Not known. Note: The value "Out of action" simply indicates that
a unit has been rotated out of an active combat role. The underlying reasons
may be rest, resupply, heavy losses, or scheduled rotation.
7.3.7 Examples of ORGANISATION-STATUS
7.3.7.1 Two sets of examples are presented in this section to illustrate the uses of
ORGANISATION-STATUS. The first example refers to a set of individual objects. The
second example illustrates a change in roles by command posts.
7.3.7.2 An example of status for individual objects is provided in the table below.
a.
Organisation 3051, which is 1 R IRISH, is first reported (fully) operational,
at normal strength and in action. Later the 1 R IRISH has suffered light
225
V3.1.4
damage and has been taken out of action and classified "in reserve", put on
24 hour alert, and expected to be fully available again within 48 hours. The
third status-report is issued when the 1 R IRISH is sent back in action,
although it still has light damage but is regarded as substantially operational.
b.
The 6 Guards Tank Division is reported initially as moderately damaged and
estimated to be unable to return to action within the next 48 hours. It is
judged to be at the lowest level of readiness. The second status-report
informs that the 6 Guards Tank Division is back in action, although it is still
not in visibly better condition.
Table 93. Examples of ORGANISATION-STATUS
ORGANISATION-STATUS
*-id
object-item*[object-itemstatusoperationalname-text]
index
status-code
3051
[1 R IRISH]
3051
[1 R IRISH]
3051
[1 R IRISH]
14486
[6 Guards
Tank
Division]
14486
[6 Guards
Tank
Division]
1
2
3
*-operationalstatusqualifier-code
Operational
—
Substantially
Lightly damaged
operational
Substantially
Lightly damaged
operational
**-command*availability and-control- commitment
-code
role-code
-status-code
*-firemodecode
—
—
—
—
Within 48
hours
—
Committed
—
—
—
—
—
1
Marginally
operational
Moderately
damaged
Between
48 hours
and 4 days
—
—
—
2
Marginally
operational
Moderately
damaged
—
—
—
—
Note: * = "organisation-status"
*-cbrn*-radiation*dress-statedose*-readiness- readinesscode
quantity
code
duration
*-reinforcementcode
MOPP 1
MOPP
Ready
MOPP 0
—
—
—
Normal strength
—
—
—
8640000
Normal strength
Yes
—
—
—
Normal strength
No
—
—
—
—
Reinforced only
—
—
—
—
—
Reinforced only
—
*-trainingcode
Green
Green
Green
Amber
Amber
*-usagestatuscode
In action
Out of
action
In action
Out of
action
In action
7.3.7.3 Example of role changes for command posts. The scenario consists of a
mechanised division engaged on a defensive line with two mechanised brigades forward
and one armoured brigade in reserve. The commander of the armoured brigade is also the
designated successor to the division commander. The division has a main command post
and an alternate command post. The other units also have main command posts. At a
certain time, the division main re-locates over an eight-hour period during which the
alternate takes over the functions of the main. At the end of the move the division main
resumes its role and the acting main reverts to alternate. Two days later the division main
command post is destroyed in an enemy raid. The division commander is killed during the
raid. At that point, the main command post of the armoured brigade becomes the main
command post of the division in accordance with established procedures.
226
V3.1.4
7.3.7.4 The data representation of this situation37 is shown in the table below
through a series of sub-tables. Sub-table (a) identifies three command posts. Their status is
shown in Sub-tables (b) and (c). The first three records represent the initial reporting
indicating that the command posts are operational. The next two records [(128,2) and
(7051,2)] show that the Div Main CP is not operational and that Div Alternate CP is acting
in the capacity of division main. The next two records [(128,3) and (7051,3)] show the
command posts reverting to their normal roles after the Div Main CP completes its move.
The penultimate record reports that Div Main CP has been heavily damaged and is no
longer operational. The last record updates the status of the Armoured Bde.
7.3.7.5 At this point, the Armoured Brigade CP takes over the role of the division
main. However, this cannot be shown through the command and control code in
ORGANISATION-STATUS since the CP has the same nominal role. The fact that a
command post from a lower echelon acts in a CP role in a higher echelon must be shown
through an association, as illustrated in Sub-tables (e) and (g). The appropriate timing
information for all status and association data is shown in Sub-tables (g) and (h).
Table 94. Example of Role Changing by Command Posts
(a) OBJECT-ITEM
object-item-id
object-item-category code
128
ORGANISATION
Mech Div Main CP
7051
ORGANISATION
Mech Div Alternate CP
8432
ORGANISATION
Armoured Bde CP
(b) OBJECT-ITEM-STATUS
object-item-id
*index
*-category-code
*-booby-trapindicator-code
reportingdata-id
128 [Mech Div Main CP]
1
ORGANISATION-STATUS
—
EMCON 3
101
7051 [Mech Div Alternate
CP]
1
ORGANISATION-STATUS
—
EMCON 3
102
8432 [Armoured Bde CP]
1
ORGANISATION-STATUS
—
EMCON 3
103
128
7051
128
7051
128
8432
2
2
3
3
4
2
ORGANISATION-STATUS
ORGANISATION-STATUS
ORGANISATION-STATUS
ORGANISATION-STATUS
ORGANISATION-STATUS
ORGANISATION-STATUS
—
—
—
—
—
—
EMCON 3
EMCON 3
EMCON 3
EMCON 3
—
EMCON 3
104
105
106
107
108
109
37
No data is shown for the two mechanised brigades since they are incidental to the
example.
227
V3.1.4
(c) OBJECT-ITEM-HOSTILITY-STATUS
object-item-id
**index
**-code
reporting-data-id
128 [Mech Div Main CP]
1
Friend
111
7051 [Mech Div Alternate
CP]
1
Friend
112
8432 [Armoured Bde CP]
1
Friend
113
128
7051
2
2
Friend
Friend
114
115
128
7051
128
8432
3
3
4
2
Friend
Friend
Friend
Friend
116
117
118
119
Note: ** = "object-item-hostility-status"
(d) ORGANISATION-STATUS
***-id
***operationalstatus-code
128
1
Operational
***-operational***-command-andstatusqualifier-code control-role-code
***-usage***statuscommitment
code
-status-code
—
Main command post
Committed
In action
Committed
In action
7051
1
Operational
—
Step up/alternate
command post
8432
1
Operational
—
Main command post
Committed
Out of
action
128
2
7051
128
—
—
Committed
Out of
action
2
Temporarily
not
operational
Operational
—
Main command post
Committed
In action
3
Operational
—
Committed
In action
7051
3
Operational
—
Main command post
Step up/alternate
command post
Committed
In action
128
4
—
—
2
Heavily
damaged
—
—
8432
Not
operational
Operational
Main command post
Committed
In action
Note: *** = "organisation-status"
(e) OBJECT-ITEM-ASSOCIATION
****-subject-objectitem-id
****-objectobject-item-id
****index
****-category-code
****-subcategory-code
8432
128
1
Supplementary
Plays the role of
Note: **** = "object-item-association"
(f) OBJECT-ITEM-ASSOCIATION-STATUS
*****-subjectobject-item-id
*****-objectobject-item-id
*****
-index
*****-associationstatus-index
*****-statuscategory-code
reportingdata-id
8432
128
1
1
Start association
210
Note: ***** = "object-item-association"
228
V3.1.4
(g) REPORTING-DATA
*-category- *-countingindicator-code
*-id
code
*-credibility-code
101
102
103
Reported
Reported
Reported
—
—
—
Reported as a fact
Reported as a fact
Reported as a fact
20030814123100.000
20030814121500.000
20030814132000.000
[absolute]
[absolute]
[absolute]
128
7051
8432
104
105
106
107
108
Reported
Reported
Reported
Reported
Reported
—
—
—
—
—
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
20030815090000.000
20030815090000.000
20030815120000.000
20030815120000.000
20030817083200.000
[absolute]
[absolute]
[absolute]
[absolute]
[absolute]
128
7051
128
7051
8432
210
109
111
112
113
Reported
Reported
Reported
Reported
Reported
—
—
—
—
—
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
20030817084000.000
20030817084000.000
20030814123101.000
20030814121501.000
20030814132001.000
[absolute]
[absolute]
[absolute]
[absolute]
[absolute]
8432
8432
128
7051
8432
114
115
116
117
118
119
Reported
Reported
Reported
Reported
Reported
Reported
—
—
—
—
—
—
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
20030815090001.000
20030815090001.000
20030815120001.000
20030815120001.000
20030817083201.000
20030817084001.000
[absolute]
[absolute]
[absolute]
[absolute]
[absolute]
[absolute]
128
7051
128
7051
8432
8432
(h) REPORTING-DATA-ABSOLUTE-TIMING
101
102
103
104
105
106
20030814123100.000
20030814121500.000
20030814132000.000
20030815090000.000
20030815090000.000
20030815120000.000
—
—
—
20030815120000.000
20030815120000.000
—
107
108
210
109
111
20030815120000.000
20030817083180.000
20030817083500.000
20030817084000.000
20030814123101.000
—
—
—
—
—
112
113
114
115
116
20030814121501.000
20030814132001.000
20030815090001.000
20030815090001.000
20030815120001.000
—
—
—
—
—
117
118
119
20030815120001.000
20030817083181.000
20030817084001.000
—
—
—
7.3.8 Specification of PERSON-STATUS
7.3.8.1 PERSON-STATUS is defined as "An OBJECT-ITEM-STATUS that is a
record of condition of a specific PERSON." The attributes are:
229
V3.1.4
a.
person-status-id—The person-id of the PERSON that is the subject of a
specific PERSON-STATUS (a role name for object-item-id).
b.
OBJECT-ITEM.
c.
person-status-duty-status-code—The specific value that represents the
availability of a specific PERSON for duty at a military or civilian post of
employment. This attribute details PERSONs either as being present or holds
the reason why a PERSON is not at duty. The domain values are: Absent;
Arrested; Assumed killed in action; At duty; Deceased; Deserted;
Hospitalised; Hostage; Missing; On leave; Prisoner of war; Not known.
d.
person-status-physical-status-code—The specific value that represents the
general physical status of a specific PERSON. The domain values are: Fit;
Incapacitated, not walking; Incapacitated, walking; Slightly incapacitated;
Not known.38
e.
person-status-physical-status-qualifier-code—The specific value that
qualifies the health conditions of a specific PERSON at a specific point in
time. Example domain values are: Injured; Ill, contagious; Pregnant;
Wounded.
f.
person-status-radiation-dose-quantity—The numeric value that represents the
total radiation dose to which a person has been exposed. The unit of measure
is centiGray (cGy).
g.
person-status-reserve-indicator-code—The specific value that represents
whether a specific PERSON has been placed in reserve. The domain values
are: No; Yes.
7.3.8.2 Example of status for individual objects is provided in the table below. The
example conveys the following information:
a.
José Fernández Cuesta is first reported injured, slightly incapacitated and on
leave. According to the second report, he has recovered and is back in duty
again.
b.
Ramiro de Maeztu Barbeito is reported fit and at duty (could be part of the
daily routine personnel reporting).
38
The person-status-physical-status-code is a qualifier on the person-status-duty-status-code.
Thus, this attribute describes qualifications or restrictions on a person’s suitability for duty as a
function of physical condition.
230
V3.1.4
Table 95. Examples of PERSON-STATUS
PERSON-STATUS
person-status-id
[object-itemname-text]
*-dutystatuscode
1
On leave
2
1
Person 1
[José Fernández
Cuesta]
Person 1
[José Fernández
Cuesta]
Person 2
[Ramiro de
Maeztu Barbeito]
*-physicalstatusqualifier-code
*-radiationdosequantity
Slightly
incapacitated
Injured, slight
—
No
At duty
Fit
—
—
No
At duty
Fit
—
—
No
*-physicalstatus-code
Note: * = "person-status"
7.4
Medical Extension for FACILITY-STATUS
7.4.1 Introduction
7.4.1.1 The APP-9 IERs Medical Assessment Report (MEDASSESSREP) and
Medical Situation Report (MEDSITREP) contain a number of requirements that deal with
the matter of casualties such as arrivals, treatment, disposition, and backlog. The status of
casualties must be accounted for in several categories: medical cause, grouping by type,
evacuation destination, and surgery triage. The entity-level structure is illustrated in the
figure below.
FACILITY-STATUS
has
MEDICAL-FACILITY-STATUS-CASUALTY-BED-OCCUPANCY
has
has
MEDICAL-FACILITY-STATUS-PENDING-SURGERY
MEDICAL-FACILITY-STATUS-PENDING-CASUALTY-EVACUATION
includes-report-of /
report-is-part-of
MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTY-GROUP
report-is-part-of
MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTY-TYPE
report-is-part-of
MEDICAL-FACILITY-STATUS-INTERVAL-EVACUATION
Figure 71. Entity-Level View of Medical Extension to FACILITY-STATUS
231
V3.1.4
7.4.1.2 The requirements present two kinds of challenges: typing of casualties in
several disparate categories and incremental reporting. The need is to be able to specify
how many of a given category occurred in the interval between time t1 and time t2.
7.4.1.3 The solution is to treat the requirements that hold at a point in time as a
status of a medical facility and represent them as child entities. The requirements that
specify data aggregated over a period of time are also represented by child entities that
take advantage of effective starting and ending datetimes in REPORTING-DATAABSOLUTE-TIMING to establish the interval over which the status reporting is valid.
7.4.1.4 Specifications for recording the status of medical facilities are presented
next, and are followed by an integrated example to illustrate the uses of every entity.
7.4.2 MEDICAL-FACILITY-STATUS
7.4.2.1 The detailed structure for MEDICAL-FACILITY-STATUS and its three
child entities for point estimates is illustrated in the figure below.
7.4.2.2 The entity MEDICAL-FACILITY-STATUS is defined as "A FACILITYSTATUS that is a record of condition of a specific medical facility." The attributes are:
a.
medical-facility-status-id—The facility-id for a specific MEDICALFACILITY-STATUS (a role name for object-item-id).
b.
OBJECT-ITEM.
c.
medical-facility-status-surgery-backlog-duration—The numeric value that
represents a quantity of time in milliseconds for the estimated period of
effectiveness for performing pending surgeries for a specific MEDICALFACILITY-STATUS.
7.4.3 Point Estimates of MEDICAL-FACILITY-STATUS
7.4.3.1 The three child entities are MEDICAL-FACILITY-STATUSCASUALTY-BED-OCCUPANCY,
MEDICAL-FACILITY-STATUS-PENDINGCASUALTY-EVACUATION,
and
MEDICAL-FACILITY-STATUS-PENDINGSURGERY. They are defined below.
232
V3.1.4
MEDICAL-FACILITY-STATUS-CASUALTY-BED-OCCUPANCY
has
medical-facility-status-casualty-bed-occupancy-index
medical-facility-status-casualty-bed-occupancy-group-code
medical-facility-status-casualty-bed-occupancy-count
MEDICAL-FACILITY-STATUS-PENDING-CASUALTY-EVACUATION
has
medical-facility-status-pending-casualty-evacuation-index
medical-facility-status-pending-casualty-evacuation-destination-code
medical-facility-status-pending-casualty-evacuation-sitting-count
medical-facility-status-pending-casualty-evacuation-stretcher-count
has
medical-facility-status-pending-surgery-index
medical-facility-status-pending-surgery-triage-code
medical-facility-status-pending-surgery-count
Figure 72. Specification of MEDICAL-FACILITY-STATUS and Its Child Entities
7.4.3.2 The
entity
MEDICAL-FACILITY-STATUS-CASUALTY-BEDOCCUPANCY is defined as "The count of bed occupancy according to specified source
grouping for a specific MEDICAL-FACILITY-STATUS." The attributes are:
a.
b.
OBJECT-ITEM.
c.
medical-facility-status-casualty-bed-occupancy-index—The unique value, or
set of characters, assigned to represent a specific MEDICAL-FACILITYSTATUS-CASUALTY-BED-OCCUPANCY for a specific FACILITY and a
specific OBJECT-ITEM-STATUS and to distinguish it from all other
instances
of
MEDICAL-FACILITY-STATUS-CASUALTY-BEDOCCUPANCY for that FACILITY and that OBJECT-ITEM-STATUS.
d.
medical-facility-status-casualty-bed-occupancy-group-code—The
specific
value that represents the categorisation of casualties in a specific MEDICAL-
233
V3.1.4
FACILITY-STATUS-CASUALTY-BED-OCCUPANCY.
The
domain
values are: Friendly forces; Local civilians; Opposing forces. The domain
defined in the set casualty-group-code.
e.
medical-facility-status-casualty-bed-occupancy-count—The integer value
representing the aggregated number of beds that are occupied by the
specified group in a specific MEDICAL-FACILITY-STATUSCASUALTY-BED-OCCUPANCY.
7.4.3.3 The entity MEDICAL-FACILITY-STATUS-PENDING-CASUALTYEVACUATION is defined as "The count of pending evacuees in each group according to
the intended destination for a specific MEDICAL-FACILITY-STATUS." The attributes
are:
a.
b.
OBJECT-ITEM.
c.
medical-facility-status-pending-casualty-evacuation-index—The
unique
value, or set of characters, assigned to represent a specific MEDICALFACILITY-STATUS-PENDING-CASUALTY-EVACUATION
for
a
specific FACILITY and a specific OBJECT-ITEM-STATUS and to
distinguish it from all other instances of MEDICAL-FACILITY-STATUSPENDING-CASUALTY-EVACUATION for that FACILITY and that
OBJECT-ITEM-STATUS.
d.
medical-facility-status-pending-casualty-evacuation-destination-code—The
specific value that represents the destination of casualties awaiting
evacuation in a specific MEDICAL-FACILITY-STATUS-PENDINGCASUALTY-EVACUATION. The domain values are: Home or holding
country; Medical facility in theatre; Returned to duty. The domain value set
the set evacuation-destination-code.
e.
medical-facility-status-pending-casualty-evacuation-sitting-count—The
integer value representing the aggregated number of casualties to be
evacuated that are capable of sitting in a specific MEDICAL-FACILITYSTATUS-PENDING-CASUALTY-EVACUATION.
f.
medical-facility-status-pending-casualty-evacuation-stretcher-count—The
integer value representing the aggregated number of casualties that must be
evacuated using stretchers in a specific MEDICAL-FACILITY-STATUSPENDING-CASUALTY-EVACUATION.
7.4.3.4 The entity MEDICAL-FACILITY-STATUS-PENDING-SURGERY is
defined as "The count of pending surgeries according to specified triage grouping for a
specific MEDICAL-FACILITY-STATUS." The attributes are:
234
V3.1.4
a.
b.
OBJECT-ITEM.
c.
medical-facility-status-pending-surgery-index—The unique value, or set of
characters, assigned to represent a specific MEDICAL-FACILITYSTATUS-PENDING-SURGERY for a specific FACILITY and a specific
OBJECT-ITEM-STATUS and to distinguish it from all other instances of
for
that
FACILITY and that OBJECT-ITEM-STATUS.
d.
medical-facility-status-pending-surgery-triage-code—The specific value that
represents the categorisation of surgery cases according to multilevel triage
classification scheme in a specific MEDICAL-FACILITY-STATUSPENDING-SURGERY. The domain values are: T1-Very seriously injured;
T2-Seriously injured; T3-Minimally injured.
e.
medical-facility-status-pending-surgery-count—The
integer
value
representing the number of pending surgeries for the specified triage
category in a specific MEDICAL-FACILITY-STATUS-PENDINGSURGERY.
7.4.4 Interval Estimates of MEDICAL-FACILITY-STATUS
7.4.4.1 Some of the data required to describe the status of a medical facility is
represented through entities that cover aggregated data for some period of time. The three
entities are MEDICAL-FACILITY-STATUS-INTERVAL-EVACUATION, MEDICALFACILITY-STATUS-INTERVAL-CASUALTY-GROUP, and MEDICAL-FACILITYSTATUS-INTERVAL-CASUALTY-TYPE. These are illustrated in the figure below.
235
V3.1.4
report-is-part-of
MEDICAL-FACILITY-STATUS-INTERVAL-EVACUATION
medical-facility-status-interval-evacuation-index
medical-facility-status-interval-evacuation-destination-code
medical-facility-status-interval-evacuation-count
report-is-part-of
MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTY-TYPE
medical-facility-status-interval-casualty-type-index
medical-facility-status-interval-casualty-type-code
medical-facility-status-interval-casualty-type-arrival-count
medical-facility-status-interval-casualty-type-admitted-count
report-is-part-of
MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTY-GROUP
medical-facility-status-interval-casualty-group-index
medical-facility-status-interval-casualty-group-code
medical-facility-status-interval-casualty-group-completed-surgery-count
medical-facility-status-interval-casualty-group-death-count
Figure 73. Specification of MEDICAL-FACILITY-STATUS for Intervals
7.4.4.2 The entity MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTYGROUP is defined as "A MEDICAL-FACILITY-STATUS that specifies the count of
deaths and completed surgeries for each of specified groups during the period defined by
the effective beginning and ending datetimes stipulated through REPORTING-DATA."
The attributes are:
a.
b.
OBJECT-ITEM.
236
V3.1.4
c.
medical-facility-status-interval-casualty-group-index—The unique value, or
set of characters, assigned to represent a specific MEDICAL-FACILITYSTATUS-INTERVAL-CASUALTY-GROUP for a specific FACILITY and
a specific OBJECT-ITEM-STATUS and to distinguish it from all other
instances of MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTYGROUPs for that FACILITY and that OBJECT-ITEM-STATUS.
d.
medical-facility-status-interval-casualty-group-code—The specific value that
represents the categorisation of casualties in a specific MEDICALFACILITY-STATUS-INTERVAL-CASUALTY-GROUP. The domain
values are: Friendly forces; Local civilians; Opposing forces. The domain
defined in the set casualty-group-code.
e.
medical-facility-status-interval-casualty-group-completed-surgery-count—
The integer value representing the number of completed surgeries for
casualties in the specified group in a specific MEDICAL-FACILITYSTATUS-INTERVAL-CASUALTY-GROUP.
f.
medical-facility-status-interval-casualty-group-death-count—The
integer
value representing the number of deceased casualties in the specified group
in a specific MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTYGROUP.
7.4.4.3 The entity MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTYTYPE is defined as "A MEDICAL-FACILITY-STATUS that specifies the count of
casualty arrivals and admissions in each of specified groups according to specified
medical classification during the period defined by the effective beginning and ending
datetimes stipulated through REPORTING-DATA." The attributes are:
a.
b.
OBJECT-ITEM.
c.
medical-facility-status-interval-casualty-type-index—The unique value, or
set of characters, assigned to represent a specific MEDICAL-FACILITYSTATUS-INTERVAL-CASUALTY-TYPE for a specific FACILITY and a
instances of MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTYTYPE for that FACILITY and that OBJECT-ITEM-STATUS.
d.
medical-facility-status-interval-casualty-type-code—The specific value that
represents the categorisation of casualties according to the type of illness or
injury in a specific MEDICAL-FACILITY-STATUS-INTERVALCASUALTY-TYPE. The domain values are: Battle stress/psychiatric;
Diseased; Non-battle injury; Wounded in action.
e.
medical-facility-status-interval-casualty-type-arrival-count—The
integer
value representing the number of new casualties of the specified type in a
specific MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTY-TYPE.
237
V3.1.4
f.
medical-facility-status-interval-casualty-type-admitted-count—The integer
value representing the number of admitted casualties of the specified type in
a specific MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTYTYPE.
7.4.4.4 The entity MEDICAL-FACILITY-STATUS-INTERVAL-EVACUATION
is defined as "A MEDICAL-FACILITY-STATUS that specifies the count of casualties
evacuated in each of specified groups according to the intended destination during the
period defined by the effective beginning and ending datetimes stipulated through
REPORTING-DATA." The attributes are:
a.
b.
OBJECT-ITEM.
c.
medical-facility-status-interval-evacuation-index—The unique value, or set
of characters, assigned to represent a specific MEDICAL-FACILITYSTATUS-INTERVAL-EVACUATION for a specific FACILITY and a
instances of MEDICAL-FACILITY-STATUS-INTERVAL-EVACUATION
for that FACILITY and that OBJECT-ITEM-STATUS.
d.
medical-facility-status-interval-evacuation-destination-code—The specific
value that represents the disposition of casualties according to the evacuation
destination in a specific MEDICAL-FACILITY-STATUS-INTERVALEVACUATION. The domain values are: Home or holding country; Medical
facility in theatre; Returned to duty. The domain value set for this attribute is
shared with one or more other attributes and is defined in the set evacuationdestination-code.
e.
medical-facility-status-interval-evacuation-count—The
integer
value
representing the number of casualties that have been evacuated to the
specified destination in a specific MEDICAL-FACILITY-STATUSINTERVAL-EVACUATION.
7.4.5 An Example of MEDICAL-FACILITY-STATUS
7.4.5.1 The example involves the 2nd Medical Treatment Facility (MTF) operating
in an active combat area. The 2nd MTF submits reports of its current status at weekly
intervals on the 14th, 21st, and 28th of April 2001. It also provides summary reports of the
results covering the periods between weekly current status reports.
7.4.5.2 The following is a summary of the example data that is contained in the
tables:
a.
On 14 April 2005 the 2nd MTF has 19 patients of whom 10 are awaiting
surgery, 8 are awaiting evacuation and 1 is occupying a bed but is not
awaiting surgery nor evacuation.
238
V3.1.4
b.
Between 14 and 21 April the 2nd MTF receives 21 new patients of whom 20
are admitted, 9 surgeries are completed, and 9 patients are evacuated. Three
patients are returned to duty, and two patients die.
c.
On 21 April 2005 the MTF has 25 patients of whom 14 are awaiting surgery
and 5 are awaiting evacuation.
d.
Between 21 and 28 April the MTF receives and admits 8 new patients,
performs 17 surgeries, evacuates 5 and returns to duty 4 patients. One patient
dies.
e.
On 28 April 2005 the MTF has 23 patients with 15 awaiting surgery and 5
are slated for evacuation.
7.4.5.3 The detailed data for this example are presented in a series of sub-tables as
part of the overarching table below.
Table 96. Examples of MEDICAL-FACILITY-STATUS
(a) OBJECT-ITEM-STATUS
object-item-id
object-item-statusemission-control-code
reportingdata-id
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
1
2
3
4
5
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
—
—
—
—
—
3201
3202
3203
3204
3205
(b) OBJECT-ITEM-HOSTILITY-STATUS
object-item-id
*-index
*-code
reporting-data-id
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
1
2
3
4
5
Friend
Friend
Friend
Friend
Friend
3211
3212
3213
3214
3215
Note: * = "object-item-hostility-status"
(c) REPORTING-DATA
**-id
****-countingcategory- indicatorcode
code
**-reporting-datetime
**-timingcategorycode
3201
3202
3203
Reported
Reported
Reported
Yes
Yes
Yes
Reported as fact
Reported as fact
Reported as fact
20050414113000.000
20050421140000.000
20050428123000.000
[absolute]
[absolute]
[absolute]
[2nd MTF]
[2nd MTF]
[2nd MTF]
3204
3205
3211
3212
3213
Reported
Reported
Reported
Reported
Reported
Yes
Yes
Yes
Yes
Yes
Reported as fact
Reported as fact
Reported as fact
Reported as fact
Reported as fact
20050421150000.000
20050428133000.000
20050414113001.000
20050421140001.000
20050428123001.000
[absolute]
[absolute]
[absolute]
[absolute]
[absolute]
[2 MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
3214
3215
Reported
Reported
Yes
Yes
Reported as fact
Reported as fact
20050421150001.000
20050428133001.000
[absolute]
[absolute]
[2nd MTF]
[2nd MTF]
**-credibilitycode
239
**-reportingorganisation
-id
nd
V3.1.4
(d) REPORTING-DATA-ABSOLUTE-TIMING
*** reporting-data-id
3201
3202
3203
3204
3205
3211
3212
3213
3214
3215
20050414060000.000
20050421060000.000
20050428060000.000
20050414060000.000
20050421060000.000
20050414060001.000
20050421060001.000
20050428060001.000
20050414060001.000
20050421060000.000
—
—
—
20050421060000.000
20050428060000.000
—
—
—
—
—
(e) FACILITY-STATUS
****-id
object-itemstatusindex
[2nd MTF]
1
[2nd MTF]
2
[2nd MTF]
3
[2nd MTF]
4
[2nd MTF]
5
****operationalstatus-code
****-categorycode
MEDICALOperational
FACILITY-STATUS
MEDICALSubstantially
FACILITY-STATUS operational
MEDICALOperational
FACILITY-STATUS
MEDICALOperational
FACILITY-STATUS
MEDICALOperational
FACILITY-STATUS
****-operationalstatus-qualifiercode
****-reserveindicator-code
****-usagestatus-code
—
No
Activated
Lacking vital
resources
No
Activated
—
No
Activated
—
No
Activated
—
No
Activated
Note: **** = "facility-status"
(f) MEDICAL-FACILITY-STATUS
medical-facility-status-id
medical-facility-status-surgerybacklog-duration
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
1
2
3
4
5
35700000
55200000
89100000
55200000
89100000
(g) MEDICAL-FACILITY-STATUS-CASUALTY-BED-OCCUPANCY
medical-facilitystatus-id
object-item-statusindex
*****index
*****-groupcode
*****count
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
1
1
1
2
2
2
3
3
3
1
2
3
1
2
3
1
2
3
Friendly forces
Opposing forces
Local civilians
Friendly forces
Opposing forces
Local civilians
Friendly forces
Opposing forces
Local civilians
14
3
2
16
8
1
17
6
0
Note: ***** = "medical-facility-status-pending-casualty-bed-occupancy"
240
V3.1.4
(h) MEDICAL-FACILITY-STATUS-PENDING-CASUALTY-EVACUATION
*-index
*-sittingcount
[2nd MTF]
1
1
Medical facility in theatre
4
1
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
1
2
2
3
3
2
1
2
1
2
Home or holding country
2
1
0
3
0
1
2
2
0
2
*-destination-code
*-stretchercount
Note: * = "medical-facility-status-pending-casualty-evacuation"
(i) MEDICAL-FACILITY-STATUS-PENDING-SURGERY
**-pendingsurgery-index
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
1
1
1
2
2
2
3
3
3
1
2
3
1
2
3
1
2
3
**-triage-code
T1-Very seriously injured
T2-Seriously injured
T3-Minimally injured
**-count
3
2
5
7
3
4
1
11
3
Note: ** = "medical-facility-status-pending-surgery"
(j) MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTY-GROUP
***-index
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
4
4
4
5
5
1
2
3
1
2
5
3
nd
[2 MTF]
***-completedsurgery-count
***-deathcount
Friendly forces
Opposing forces
Local civilians
Friendly forces
Opposing forces
7
2
0
15
1
2
0
0
0
1
Local civilians
1
0
***-code
Note: *** = "medical-facility-status-interval-casualty-group"
(k) MEDICAL-FACILITY-STATUS-INTERVAL-CASUALTY-TYPE
****index
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
nd
[2 MTF]
[2nd MTF]
4
4
4
4
5
5
5
5
1
2
3
4
1
2
3
4
****-code
Battle stress/psychiatric
Diseased
Non-battle injury
Wounded in action
Battle stress/psychiatric
Diseased
Non-battle injury
Wounded in action
****-arrivalcount
****-admittedcount
2
7
4
8
1
0
1
6
2
6
4
8
1
0
1
6
Note: **** = "medical-facility-status-interval-casualty-type"
241
V3.1.4
(l) MEDICAL-FACILITY-STATUS-INTERVAL-EVACUATION
*****-index
[2nd MTF]
4
1
4
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
[2nd MTF]
4
4
5
5
5
2
3
1
2
3
Returned to duty
Returned to duty
5
3
2
3
4
*****-destination-code
*****-count
Note: ***** = "medical-facility-status-interval-evacuation"
7.5
Business Rules for Status of OBJECT-ITEMs
7.5.1 Business Rules for OBJECT-ITEM-HOSTILITY-STATUS are specified in
Annex G1, Section G1.4.1.
7.5.2 Business Rules for OBJECT-ITEM-STATUS are specified in Annex G1,
Section G1.4.2.
7.5.3 Valid combinations of domain values for FACILITY-STATUS,
MATERIEL-STATUS, ORGANISATION-STATUS or PERSON-STATUS attributes are
specified in Annex G2, Section G2.5.1.
7.5.4 Valid combinations for attributes ***-status-operational-status-code, ***status-operational-status-qualifier-code, ***-status-operational-status-mode-code, and
***-status-usage-status-code, where *** denotes FACILITY, MATERIEL or
ORGANISATION, are specified in Annex G2, Section G2.5.1.
7.5.5 Permissible combinations of domain values for attributes person-statusduty-status-code and person-status-physical-status-code are specified in Annex G2,
Section G2.5.1.2.
7.5.6 Rule for starting and ending times of interval child entities of MEDICALFACILITY-STATUS is specified in Annex G1, Section G1.4.3.
242
V3.1.4
8.
NETWORKS AND ACCESS TO ITEMS THROUGH ADDRESSING
8.1
Introduction
8.1.1 This chapter provides the specifications that enable OBJECT-ITEMs to be
contacted or reached. Although specification of networks belongs in Chapter 5 since
NETWORK is in the hierarchy of OBJECT-ITEM as a subtype of FACILITY, network
specifications are so closely related to access for OBJECT-ITEMs that the presentation of
the two topics is improved if they are integrated.
8.1.2 The chapter contains three major sections. The first sets forth the
specifications for networks and illustrates a use with an example. The second contains the
specifications for obtaining access to instances of OBJECT-ITEM. The third section
presents examples that makes use of both sets of specifications to describe access to
networks with different topologies.
8.2
Networks
8.2.1 Concept of Network in the Model
8.2.1.1 The primary purpose of network specification is to enable a description of
communications services that need to be provided to military commanders and their staffs
to support C2IS networks in a potentially hostile environment. Crisis management and
peacekeeping scenarios show that inclusion of commercial and strategic communications
systems is also relevant.
8.2.1.2 The scope of specification is limited primarily to logical communications
architectures. Focus is on the identification of networks and the services that are provided
with minimal extension to physical implementation. The emphasis on logical aspects of
networks is in keeping with the primary goal of supporting staff planning processes as
general guidance for the scope of the data model.
8.2.1.3 The main concern in physical architecture is the identification of the
materiel assets that are used to establish network connections. The model contains
considerable amount of specification for representing materiel, facilities, and status of
items. These are in the model due to other requirements. The specifications could be used
to describe physical architectures, if so required, without necessarily representing the
detail that would be found in a model specialised for communications-electronics.
8.2.1.4 The network extension describes characteristics of the network, to include
the kind of service provided (e.g., voice, facsimile, telex) and the intended use of the
network (e.g., fire-support, C2). It enables applications to perform functions such as:
a.
Modelling of tactical communications systems;
b.
Modelling of networks, nodes and connections between nodes;
c.
Planning of tactical communications systems.
8.2.2 Specification of NETWORK
8.2.2.1 The specification of NETWORK includes a number of characteristics that
deal with cryptography, general frequency band and channelisation, capacity, modulation,
243
V3.1.4
and security classification. The structure for NETWORK and its child entities is illustrated
in the figure below.
NETWORK
NETWORK-FREQUENCY
network-id (FK)
uses /
is-specified-for
network-means-code
network-id (FK)
network-frequency-index
network-frequency-band-code
network-frequency-channel-number-text
network-frequency-discrete-frequency-quantity
network-frequency-band-lower-frequency-quantity
network-frequency-band-upper-frequency-quantity
network-frequency-effective-start-datetime
network-frequency-effective-end-datetime
network-frequency-modulation-code
network-frequency-purpose-text
has /
is-specified-for
provides /
is-provided-by
NETWORK-CAPACITY
NETWORK-SERVICE
network-id (FK)
network-capacity-index
network-id (FK)
network-service-index
network-service-category-code
network-service-subcategory-code
network-service-cryptographic-indicator-code
network-service-cryptographic-plan-short-title-text
network-service-cryptographic-code-short-title-text
network-service-iff-mode-code-text
security-classification-id (FK)
has /
is-ascribed-to
provides-to
network-capacity-bandwidth-code
network-capacity-protocol-code
NETWORK-SERVICE-STATUS
network-id (FK)
network-service-index (FK)
network-service-status-index
network-service-status-indicator-code
security-classification-id
security-classification-level-code
security-classification-policy-text
security-classification-caveat-text
Figure 74. NETWORK Structure
8.2.2.2 NETWORK is defined as "A FACILITY that provides bearer services for
communication and information services and is composed of one or more links and
nodes." The attributes are:
a.
network-id—The facility-id of a specific NETWORK (a role name for
object-item-id).
b.
network-category-code—The specific value that represents the class of
NETWORK. Example domain values are: Broadcast; Multicast; Point-topoint.
c.
network-subcategory-code—The specific value that represents the specific
class of NETWORK. Example domain values are: Circuit switched; Packet
switched; Virtual circuit switched.
d.
network-architecture-code—The specific value that represents the
architecture of a specific NETWORK. Example domain values are: ARCnet;
Ethernet; Token ring.
244
V3.1.4
e.
network-channel-count—The integer value representing the number of
channels that a specific NETWORK can provide.
f.
network-maximum-capacity-rate—The numeric value that represents the
maximum data rate that a specific NETWORK can process. The unit of
measure is kilobits per second (KBS). The specified value must be greater
g.
network-minimum-capacity-rate—The numeric value that represents the
minimum data rate that a specific NETWORK is required to process. The
unit of measure is kilobits per second (KBS). The specified value must be
greater than or equal to 0 (zero).
h.
network-means-code—The specific value that represents the physical linkage
between the nodes of a specific NETWORK. Example domain values are:
Cable; Fibre optic; Radio relay.
i.
network-set-number-count—The integer value representing the frequency
hopping set number parameter for this specific NETWORK.
8.2.3 Specification of NETWORK-FREQUENCY
A network description may require that discrete frequencies be specified, such as
centre frequency for a guard channel, upper and lower operating limits or sets of
frequencies over which frequency-hopping radios must operate. The entity NETWORKFREQUENCY is designed to store such information. NETWORK-FREQUENCY is
defined as "The specification of a discrete frequency that is used on a specific
NETWORK." The attributes are:
a.
object-item-id).
b.
network-frequency-index—The unique value, or set of characters, assigned
to represent a specific NETWORK-FREQUENCY for a specific
NETWORK and to distinguish it from all other NETWORK-FREQUENCYs
for that NETWORK.
c.
network-frequency-band-code—The specific value that represents the
frequency band of a specific NETWORK. Example domain values are: High
frequency; Ultra high frequency; Very low frequency.
d.
network-frequency-channel-number-text—The character string assigned to
represent the channel number associated with a specific NETWORKFREQUENCY.
e.
network-frequency-discrete-frequency-quantity—The numeric value that
represents the radio frequency that a specific NETWORK may use. The unit
of measure is kilohertz.
f.
network-frequency-band-lower-frequency-quantity—The numeric value that
represents the lowest radio frequency of a specific contiguous band that a
NETWORK may use. The unit of measure is kilohertz.
g.
network-frequency-band-upper-frequency-quantity—The numeric value that
represents the highest radio frequency of a specific contiguous band that a
NETWORK may use. The unit of measure is kilohertz.
245
V3.1.4
h.
network-frequency-effective-start-datetime—The
character
string
representing a point in time that designates the effective assignment of a
specific OBJECT-TYPE-ESTABLISHMENT to a specific OBJECT-ITEM.
i.
network-frequency-effective-end-datetime—The
character
string
representing a point in time that designates the end of the authorised period
of effectiveness for a specific NETWORK-FREQUENCY.
j.
network-frequency-modulation-code—The specific value that represents the
modulation of a specific NETWORK. Example domain values are: Double
side band; Frequency modulation; Phase shift keying.
k.
network-frequency-purpose-text—The character string assigned to represent
the specific purpose of a NETWORK-FREQUENCY.
8.2.4 Specification of NETWORK-SERVICE
8.2.4.1 The main characteristic of a network is that subscribers can be connected
via the same kind of communications service. Many networks are capable of providing
multiple services. In order to provide appropriate addresses for network subscribers, it is
necessary to distinguish among the services. NETWORK-SERVICE is defined as "An
identification of the specific type of communications service provided by a specific
NETWORK." The attributes are:
a.
object-item-id).
b.
network-service-index—The unique value, or set of characters, assigned to
represent a specific NETWORK-SERVICE for a specific NETWORK and to
distinguish it from all other NETWORK-SERVICEs for that NETWORK.
c.
network-service-category-code—The specific value that represents a general
type of service that a specific NETWORK is intended to provide. Example
domain values are: Identification friend or foe; Message handling service;
Tactical data link.
d.
network-service-subcategory-code—The specific value that represents a
detailed type of service that a specific NETWORK is intended to provide.
Example domain values are: Hypertext transfer protocol; IFF mode 1; Link
11.
e.
network-service-cryptographic-indicator-code—The specific value that
represents whether a specific NETWORK-SERVICE is encrypted. The
f.
network-service-cryptographic-plan-short-title-text—The
assigned to represent a specific cryptographic plan.
g.
network-service-cryptographic-code-short-title-text—The character string
assigned to represent a specific cryptographic code.
h.
network-service-iff-mode-code-text—The character string assigned
represent a specific IFF mode code combination.
i.
security-classification-id—The unique value, or set of characters, assigned to
represent a specific SECURITY-CLASSIFICATION and to distinguish it
from all other SECURITY-CLASSIFICATIONs.
246
character
string
to
V3.1.4
8.2.4.2 The network-service-category-code and network-service-subcategory-code
attributes form a complex domain; that is, not every subcategory is applicable to every
category. Permissible combinations of values are specified in Annex G2, Section G2.6.1.
8.2.4.3 The security classification, security policy and any security caveats of a
network service is provided by the relationship from the SECURITY-CLASSIFICATION
entity. This specification is explained in paragraph 14.9.
8.2.5 Specification of NETWORK-SERVICE-STATUS
8.2.5.1 NETWORK-SERVICE-STATUS is defined as "A record of the perceived
condition of a specific NETWORK-SERVICE as determined by the reporting
organisation." The attributes are:
a.
object-item-id).
b.
c.
network-service-status-index—The unique value, or set of characters,
assigned to represent a specific NETWORK-SERVICE-STATUS for a
specific NETWORK-SERVICE and to distinguish it from all other
NETWORK-SERVICE-STATUSs for that NETWORK-SERVICE.
d.
network-service-status-indicator-code—The specific value that denotes
whether the specific NETWORK-SERVICE is active. The domain values
are: No; Yes.
e.
REPORTING-DATAs.
8.2.6 Specification of NETWORK-CAPACITY
8.2.6.1 NETWORK-CAPACITY is defined as "An identification of the specific
capacities of a NETWORK." The attributes are:
a.
object-item-id).
b.
network-capacity-index—The unique value, or set of characters, assigned to
represent a specific NETWORK-CAPACITY for a specific NETWORK and
to distinguish it from all other NETWORK-CAPACITYs for that
NETWORK.
c.
network-capacity-bandwidth-code—The specific value that represents a
bandwidth capacity that is supported by a NETWORK. Example domain
values are: Eurocom; Frame relay; ISDN; Switched 56.
d.
network-capacity-protocol-code—The specific value that represents an
application-level (OSI model level 3 to 7) protocol governing the
information transfer in a NETWORK. Example domain values are:
Appletalk; DECnet; OSI; SNA.
247
V3.1.4
8.2.7 Examples of Networks
8.2.7.1 Use of data structures specified in the previous paragraphs is illustrated in
the table below. Sub-tables (a) and (b) identify five networks. Their properties are
characterised in Sub-tables (c), (d), (e), and (f). The 20 CMBG COMMAND CBT NET
provides only voice service; the DIVISION TRUNK SYSTEM is capable of providing
voice service, facsimile, and electronic mail. The NATIONAL REAR LINK represents the
satellite link that could provide general data transfer, voice service and video service
capabilities to other NETWORKS. The MIP IOT&E and MIP SOLUTION DEPLOYED
are more detailed in terms of bandwidth capacity and protocols that they support. This
example serves as a basis for an example of network access that is presented in a
subsequent section.
Table 97. Illustration of NETWORK Structure39
(a) OBJECT-ITEM
objectitem-id
object-itemcategory-code
101
102
103
104
105
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
20 CMBG COMMAND CBT NET
NATIONAL REAR LINK
MIP IOT&E
MIP SOLUTION DEPLOYED
(b) FACILITY
facility-id
101
102
103
104
105
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
(c) NETWORK
*-id
*-categorycode
*-subcategorycode
*-architecturecode
*-channelcount
*-maximumcapacity-rate
101
102
103
104
105
Broadcast
Point-to-point
Point-to-point
Point-to-point
Point-to-point
—
Circuit switched
Circuit switched
Packet switched
Packet switched
—
—
Mixed
Ethernet
Mixed
1
24
16
—
—
4.8
19.8
64
—
—
Note: * = "network"
*-minimum-capacityrate
*-means-code
*-set-numbercount
1.2
9.6
16
—
—
—
Mixed
Radio link, satellite
Twisted pair cable
Mixed
123456
—
—
—
—
The dashed line at the right side of the table indicates that some attributes that are not relevant
to the example have been omitted.
39
248
V3.1.4
(d) SECURITY-CLASSIFICATION
**-id
**-level-code
**-policy-text
**-caveat-text
sc990
sc991
sc992
sc993
sc994
Unclassified
Unclassified
Unmarked
Unmarked
Unclassified
NATO
NATO
Releasable to NATO
Releasable to NATO
Nation
(e) NETWORK-FREQUENCY
network
-id
***index
101
101
102
103
1
2
1
1
***-band-code
***-channelnumber-text
***-discretefrequencyquantity
***-band-lowerfrequencyquantity
***-band-upperfrequencyquantity
Very high frequency
Very high frequency
Very high frequency
Super high frequency
—
—
—
—
5040
6500
40000
7 250 000
3000
30000
30000
3 000 000
10800
108000
108000
30 000 000
Note: *** = "network-frequency"
***-effective-startdatetime
***-effective-enddatetime
***-modulation-code
***-purpose-text
20031017000000.000
20031018000000.000
—
20031028000000.000
20041017235900.000
20041018235900.000
—
20040601235900.000
Frequency modulation
Frequency modulation
Frequency shift keying
Upper side band
Guidance frequency
Stand by
Guidance frequency
Guidance frequency
(f) NETWORK-SERVICE
network-id
****-index
****-category-code
****-subcategory-code
101 [20 CMBG COMMAND CBT NET]
102 [DIVISION TRUNK SYSTEM]
103 [NATIONAL REAR LINK]
104 [MIP IOT&E]
104 [MIP IOT&E]
104 [MIP IOT&E]
105 [MIP SOLUTION DEPLOYED]
1
1
2
3
1
2
3
1
2
3
1
2
3
4
Voice service
Voice service
Facsimile
Message handling service
Data transfer
Voice service
Video service
Data transfer
MCI
Data transfer
MCI
Tactical data link
Electronic mail
Hypertext transfer protocol
MCI Mode 1
Electronic mail
MCI Mode 3
Electronic mail
Link 16, data
Note: **** = "network-service"
249
V3.1.4
****-cryptoindicator-code
****-crypto-planshort-title-text
****-crypto-codeshort-title-text
****-iff-modecode-text
securityclassification-id
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
AMSL 601
AMSL 602
AMSL 602
AMSL 602
AMSL 603
AMSL 603
AMSL 603
AMSL 604
AMSL 604
AMSL 604
AMSL 605
AMSL 605
AMSL 605
AMSL 605
AMST 331
AMST 332
AMST 332
AMST 332
AMST 333
AMST 333
AMST 333
AMST 334
AMST 334
AMST 334
AMST 335
AMST 335
AMST 335
AMST 335
—
—
—
—
—
—
—
—
—
—
—
—
—
—
sc991
sc992
sc992
sc992
sc993
sc993
sc993
sc994
sc994
sc994
sc995
sc995
sc995
sc995
(g) NETWORK-SERVICE-STATUS
network-id
101 [20 CMBG COMMAND CBT
NET]
102 [DIVISION TRUNK
SYSTEM]
102 [DIVISION TRUNK
SYSTEM]
102 [DIVISION TRUNK
SYSTEM]
104 [MIP IOT&E]
104 [MIP IOT&E]
104 [MIP IOT&E]
105 [MIP SOLUTION
DEPLOYED]
105 [MIP SOLUTION
DEPLOYED]
105 [MIP SOLUTION
DEPLOYED]
105 [MIP SOLUTION
DEPLOYED]
networkservice-index
network-servicestatus-index
network-servicestatus-indicator-code
reporting-data-id
1
1
Yes
18623
1
1
Yes
18724
2
1
Yes
18725
3
1
Yes
18726
1
2
3
1
2
3
1
1
1
1
1
1
1
1
Yes
Yes
Yes
Yes
Yes
Yes
Yes
20993
20994
20995
21778
21779
21780
22356
2
1
Yes
22357
3
1
Yes
22358
4
1
Yes
22359
(h) NETWORK-CAPACITY
network-id
networkcapacity-index
network-capacitybandwidth-code
network-capacityprotocol-code
104 [MIP IOT&E]
104 [MIP IOT&E]
1
2
1
2
1
2
3
—
—
FDDI
—
10 Mbps
—
—
TCP/IP
Mixed
TCP/IP
NetBEUI
TCP/IP
X400
X25
250
V3.1.4
8.2.8 Use of NETWORK Specification with Other Parts of the Model
8.2.8.1 FACILITY-STATUS and REPORTING-DATA can be used to keep track
of an established network. The same entities can also be used to indicate future activation
of networks and their elements.
8.2.8.2 An organisation that is planning a network can be modelling by associating
the planning ORGANISATION via ORGANISATION-ACTION-ASSOCIATION to an
ACTION-TASK. The objective and resources of the plan/order/request can be specified
via ACTION-OBJECTIVE and ACTION-RESOURCE. The specified objective is the
network and the specified resources are the communications-electronics units and
equipment types that will be used for implementation.
8.3
Access to OBJECT-ITEMs
8.3.1 Concept of Access in the Model
8.3.1.1 There is a need to be able to reach or address facilities, organisations, and
persons. The means by which an item can be reached are many and include anything from
a postal address to a telephone number to a World Wide Web listing. It even encompasses
the use of call signs on radio nets since a call sign is a way of reaching a specified
organisation or person and represents an address as much as an e-mail address.
8.3.1.2 The model permits access to be specified for any instance of OBJECTITEM through physical and electronic addressing. The physical addressing is a
straightforward listing of the elements of an address in text form. All other accesses are
defined in relation to a specified network and a specified service. The specification can be
as simple as creating a generic telephone network and then listing telephone numbers of
the subscribers or it can be a highly detailed link-by-link specification of a complex
network of networks. Some of the possibilities are suggested by the examples in the
following section.
8.3.1.3 Participation in a network is determined in several ways. Having the right
termination equipment is part of it, such as facsimile machine at the end of a telephone
line. In other cases, it may be having the right software, such as fax application on a
computer terminal. An instance of OBJECT-ITEM, such as a military unit, may be a
subscriber to multiple services on a single network. It may also participate as a subscriber
on several different networks. Subscription to a network need not be determined solely by
the capabilities of equipment or software. The conditions of subscription may also be
defined by operational requirements that are dictated by commanders. For example,
specific permissions may be granted for active (i.e., transmitting) participation in certain
networks, such as command net or a fire support net, although any node with the proper
equipment would be able to listen to the traffic on the nets.
8.3.2 Specification of ADDRESS
8.3.2.1 The ADDRESS structure provides a means for specifying an access address
for an object. ADDRESS is an independent entity because a given address need not be
owned by a specific object. This is most obvious in case of an office or house address
where the occupancy can change but the address remains the same. A similar situation can
251
V3.1.4
occur in the electronic world where a telephone number may be re-assigned or an e-mail
address shared by a number of individuals or offices.
8.3.2.2 The data structure is illustrated in the figure below. The independent entity
ADDRESS has two subtypes—PHYSICAL-ADDRESS and ELECTRONICADDRESS—where the actual address is specified. The entity ELECTRONIC-ADDRESS
has a mandatory non-identifying relationship from NETWORK-SERVICE to identify the
type of service and the network that provides it. The structure permits any number of
access specifications to be assigned to an instance of OBJECT-ITEM through the
associative entity OBJECT-ITEM-ADDRESS.
OBJECT-ITEM
object-item-id
has-for-address /
is-the-address-for
OBJECT-ITEM-ADDRESS
object-item-id (FK)
address-id (FK)
object-item-address-index
FACILITY
facility-id (FK)
object-item-address-call-sign-text
object-item-address-primacy-code
object-item-address-authorisation-indicator-code
object-item-address-transmit-receive-code
network-id (FK)
network-frequency-index (FK)
is-reference-for
ADDRESS
address-id
address-place-name-text
ELECTRONIC-ADDRESS
is-assigned-through
NETWORK-FREQUENCY
network-id (FK)
network-frequency-index
network-frequency-band-code
network-frequency-channel-number-text
network-frequency-discrete-frequency-quantity
network-frequency-band-lower-frequency-quantity
network-frequency-band-upper-frequency-quantity
network-frequency-effective-start-datetime
network-frequency-effective-end-datetime
network-frequency-modulation-code
network-frequency-purpose-text
address-id (FK)
uses /
is-specified-for
electronic-address-name-text
network-id (FK)
network-service-index (FK)
address-id (FK)
network-id (FK)
network-means-code
provides /
is-provided-by
can-be-accessed-via /
provides-access-to
PHYSICAL-ADDRESS
NETWORK
NETWORK-SERVICE
network-id (FK)
physical-address-category-code
physical-address-residence-text
physical-address-street-text
physical-address-street-additional-text
physical-address-postal-box-text
physical-address-postbox-identifier-text
physical-address-city-text
physical-address-geographic-text
physical-address-postal-code-text
physical-address-province-text
physical-address-district-text
Figure 75. ADDRESS Structure
252
V3.1.4
8.3.2.3 ADDRESS is defined as "Precise information on the basis of which a
physical or electronic destination may be accessed." The attributes are:
a.
address-id—The unique value, or set of characters, assigned to represent a
specific ADDRESS and to distinguish it from all other ADDRESSs.
b.
address-category-code—The specific value that represents the class of
ADDRESS. It serves as a discriminator that partitions ADDRESS into
subtypes. The domain values are: ELECTRONIC-ADDRESS; PHYSICALADDRESS; Not otherwise specified.
c.
address-place-name-text—The character string assigned to represent the
name of the place related to the subject address.
8.3.3 Specification of PHYSICAL-ADDRESS
8.3.3.1 PHYSICAL-ADDRESS is defined as "An ADDRESS that represents a
physical location that is reachable by use of transportation, to include the use of postal
services." The attributes are:
a.
b.
physical-address-category-code—The specific value that represents the class
of the PHYSICAL-ADDRESS. The domain values are: Mailing address; Not
otherwise specified; Physical address; Postmark; Return address.
c.
physical-address-residence-text—The character string assigned to represent
the residence name of the PHYSICAL-ADDRESS.
d.
physical-address-street-text—The character string assigned to represent the
street name for a specific PHYSICAL-ADDRESS.
e.
physical-address-street-additional-text—The character string assigned to
represent specific additional information such as the house number, the
apartment number, rural route number, building number, room number,
office or equivalent number to complete the physical address for a specific
PHYSICAL-ADDRESS.
f.
physical-address-postal-box-text—The character string assigned to represent
a specific post office box of the PHYSICAL-ADDRESS.
g.
physical-address-postbox-identifier-text—The character string assigned to
represent a specific letter box number of the PHYSICAL-ADDRESS.
h.
physical-address-city-text—The character string assigned to represent the
city name of the PHYSICAL-ADDRESS.
i.
physical-address-geographic-text—The character string assigned to represent
the geographic region of the PHYSICAL-ADDRESS.
j.
physical-address-postal-code-text—The character string
represent the postal code of the PHYSICAL-ADDRESS.
k.
physical-address-province-text—The character string assigned to represent
the province of the PHYSICAL-ADDRESS.
l.
physical-address-district-text—The character string assigned to represent the
district of the PHYSICAL-ADDRESS.
253
assigned
to
V3.1.4
8.3.3.2 Examples of addresses are presented in the table below.
Table 98. Examples of PHYSICAL-ADDRESS
PHYSICAL-ADDRESS
address
-id
physical-addresscategory-code
physicaladdressresidence-text
701
702
703
704
705
Mailing address
Physical address
Mailing address
Physical address
Mailing address
—
Broadchalk
—
—
Amalienborg
706
Physical address
—
physical-addressstreet-text
Maple Street
—
—
Berlinstrasse
Amalienborg
slotsplads
—
physicaladdress-streetadditional-text
physicaladdress-postalbox-text
123
—
—
172
—
—
—
PO Box 27
—
—
—
—
physical-addresspostboxidentifier-text
physicaladdress-citytext
physicaladdressgeographic-text
physicaladdress-postalcode-text
physicaladdressprovince-text
physicaladdressdistrict-text
—
—
—
—
—
—
Springfield
Upson Downs
Upson Downs
Ingolstadt
København K
—
Virginia, USA
Dorset, UK
Dorset, UK
Germany
Denmark
Afghanistan
22153
—
DT11 8RE
—
1257
—
—
—
—
—
—
Arghandab
—
—
—
—
—
Badakhshan
8.3.4 Specification of ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS is defined as "An ADDRESS that is reached by using
the specified NETWORK-SERVICE." The attributes are:
a.
b.
electronic-address-name-text—The character string assigned to represent a
specific ELECTRONIC-ADDRESS.
c.
object-item-id).
d.
8.3.5 Specification of OBJECT-ITEM-ADDRESS
8.3.5.1 OBJECT-ITEM-ADDRESS is defined as "An association between an
OBJECT-ITEM and an ADDRESS to specify the means by which a FACILITY,
ORGANISATION or PERSON can be accessed." The attributes are:
a.
b.
254
V3.1.4
c.
object-item-address-index—The unique value, or set of characters, assigned
to represent a specific OBJECT-ITEM-ADDRESS for a specific OBJECTITEM and a specific ADDRESS and to distinguish it from all other
OBJECT-ITEM-ADDRESSs for that OBJECT-ITEM and that ADDRESS.
d.
object-item-address-call-sign-text—The character string assigned
represent a specific OBJECT-ITEM that uses a specific ADDRESS.
e.
object-item-address-primacy-code—The specific value that represents the
priority that a specific ADDRESS has with respect to a specific OBJECTITEM. The domain values are: Primary; Secondary; Tertiary.
f.
object-item-address-authorisation-indicator-code—The specific value that
denotes whether the OBJECT-ITEM is permitted by command authority to
use a specific ELECTRONIC-ADDRESS. The domain values are: No; Yes.
g.
object-item-address-transmit-receive-code—The specific value that denotes
the OBJECT-ITEM usage of an ELECTRONIC-ADDRESS in terms of
transmission and reception. The domain values are: Receive; Transmit;
Transmit and receive.
h.
object-item-id).
i.
network-frequency-index—The unique value, or set of characters, assigned
to represent a specific NETWORK-FREQUENCY for a specific
NETWORK and to distinguish it from all other NETWORK-FREQUENCYs
for that NETWORK.
j.
REPORTING-DATAs.
to
8.3.5.2 A business rule regarding the attribute object-item-address-transmitreceive-code is specified in Annex G1, Section G1.5.1.
8.4
Integrated Examples
This section presents six examples of specification that feature differing topologies
and network participation.
8.4.1 Example A—Broadcast Net
8.4.1.1 Example A features a single command net for 2nd Battalion. It uses combat
net radio and has as participants the battalion headquarters, a SHORAD battery, and a
mortar company. The participant list is intended for exposition purpose only since it
clearly is incomplete from an operational perspective.
8.4.1.2 The data for this example is presented in the table below. Sub-tables (a)
through (d) specify the characteristics of the objects in the example—three units, one
network, and two types of service that are available over the network. Sub-tables (e) and
(f) specify the addresses that apply to each type of service. Sub-table (g) associates
addresses with the units and specifies that these services are used for transmission and
reception purposes. The tables stipulate that the battalion headquarters and the SHORAD
255
V3.1.4
battery participate in the network for voice and facsimile services, while the mortar
company is a subscriber only for voice service. This example does not need the
specification of network frequencies.
Table 99. Data for Example A
(a) OBJECT-ITEM
objectitem-id
0444
012
041
085
FACILITY
ORGANISATION
ORGANISATION
ORGANISATION
2BN COMMAND NET
2BN HQ
2BN SHORAD
2BN Mortar Coy
(b) FACILITY
facility-id
0444
NETWORK
(c) NETWORK
*-id
*-categorycode
*-subcategorycode
*-architecturecode
*-channelcount
0444
Broadcast
—
—
2
4.8
Note: * = "network"
**-minimum-capacity-rate
**-means-code
**-set-number-count
1.2
Radio link, general
654321
**-id
**-level-code
**-policy-text
**-caveat-text
sc995
sc996
Secret
Unclassified
NATO
NATO
Releasable to NATO
Releasable to NATO
(e) NETWORK-SERVICE
network-id
**-index
**-category-code
**-subcategory-code
0444 [2BN COMMAND NET]
0444 [2BN COMMAND NET]
1
2
Voice service
Facsimile
Note: *** = "network-service"
**-cryptographicindicator-code
**-cryptographicplan-short-title-text
**-cryptographiccode-short-title-text
**-iff-mode-codetext
Yes
—
AMSL 605
—
AMST 335
—
—
—
sc995
sc996
(f) ADDRESS
address-id
10001
10002
10003
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
—
—
—
256
V3.1.4
(g) ELECTRONIC-ADDRESS
address-id
network-id
10001
10002
10003
—
123-456-7890
123-456-7891
0444
0444
0444
1
2
2
(h) OBJECT-ITEM-ADDRESS
****inde
x
****callsigntext
****primac
y-code
****authorisatio
n-indicatorcode
****transmitreceivecode
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
objectitem-id
addre
ss-id
012
[2BN HQ]
10001
1
Charlie
1
Primary
Yes
012
[2BN HQ]
10002
1
—
Second
ary
Yes
041
[2BN
SHORAD]
041
[2BN
SHORAD]
085
[2BN
Mortar
Coy]
10001
1
Charlie
2
Primary
Yes
10003
1
—
Second
ary
Yes
10001
1
Charlie
3
Primary
Yes
netwo
rk-id
networkfrequenc
y-index
reporti
ngdata-id
—
—
1135
—
—
1135
—
—
1135
—
—
1135
—
—
1135
Note: **** = "object-item-address"
8.4.2 Example B—Two Broadcast Nets
8.4.2.1 Example B is similar to the previous example and features the same units,
but the network situation is somewhat different. There are now two nets that mandate
individual participation by command decision. It is enforced by the use of different
encryption schemes. One net connects the battalion headquarters with the SHORAD
battery and offers both voice and facsimile services (transmit and receive) that are
available to both units. The second net connects the battalion headquarters with the mortar
company and offers only voice service (also transmit and receive). An example is
illustrated in the figure below. Numbers underneath the names of units and nets in the
figure are identifiers for data entry. As in the previous example, no specification of
network frequencies is needed.
Figure 76. Illustration of Example B
257
V3.1.4
8.4.2.2 The data for this example is presented in the table below.
Table 100. Data for Example B
(a) OBJECT-ITEM
objectitem-id
0909
0744
012
041
085
FACILITY
FACILITY
ORGANISATION
ORGANISATION
ORGANISATION
2BN NET
2 BN FS NET
2BN HQ
2BN SHORAD
2BN Mortar Coy
(b) FACILITY
facility-id
0909
0744
NETWORK
NETWORK
(c) NETWORK
*-id
*-categorycode
*-subcategorycode
*-architecturecode
*-channelcount
0909
0744
Broadcast
Broadcast
—
—
—
—
2
1
4.8
4.8
Note: * = "network"
*-minimum-capacity-rate
*-means-code
*-set-number-count
1.2
1.2
Radio link, general
Radio link, general
427622
—
**id
**-level-code
**-policy-text
**-caveat-text
sc997
sc998
sc999
Secret
Secret
Secret
NATO
NATO
NATO
Releasable to NATO
Releasable to NATO
Releasable to NATO
Note: **"= "security-classification"
(e) NETWORK-SERVICE
network-id
***-index
***-category-code
***-subcategory-code
0909 [2BN NET]
0909 [2BN NET]
0744 [2 BN FS NET]
1
2
1
Voice service
Facsimile
Voice service
***-cryptographicindicator-code
***-cryptographicplan-short-title-text
***-cryptographiccode-short-title-text
***-iff-modecode-text
Yes
Yes
—
AMSL 602
AMSL 603
—
AMST 333
AMST 334
—
—
—
—
sc997
sc998
sc999
258
V3.1.4
(f) ADDRESS
address-id
20001
20002
20003
20004
20005
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
—
—
—
—
—
address-id
network-id
20001
20002
20003
20004
—
123-456-7890
—
123-456-7891
0909
0909
0744
0909
1
2
1
2
****-callsign-text
****primacycode
****authorisation
-indicatorcode
objectitem-id
addre
ss-id
****inde
x
012
[2BN HQ]
012
[2BN HQ]
012
[2BN HQ]
041
[2BN
SHORAD]
041
[2BN
SHORAD]
085
[2BN Mortar
Coy]
20001
1
Charlie 1
Primary
Yes
20002
1
—
Yes
20003
1
Charlie 1
Seconda
ry
Primary
Yes
20001
1
Charlie 2
Primary
Yes
20004
1
—
Seconda
ry
Yes
20003
1
Charlie 3
Primary
Yes
****-transmitreceive-code
netwo
rk-id
networkfrequenc
y-index
reporti
ngdata-id
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
—
—
20011
—
—
20011
—
—
20011
—
—
20011
Transmit and
receive
—
—
20011
Transmit and
receive
—
—
20011
8.4.3 Example C—Multiple Network-Multiple Access
8.4.3.1 Example C is somewhat more involved than the previous two. It features
three organisations and four networks. Each network offers different services: Combat Net
has voice; Division Trunk System has voice, fax, and e-mail; National Rear Link offers
general data transfer, voice and video service and the MIP Solution Deployed is listed for
e-mail, HTTP, MCI Mode 3 and Link 16. While 20th CMBG is provided information
through its National Rear Link network, it interacts with 1st Voltigeurs infantry battalion
through the Combat Net (voice service). It also has fax and e-mail services access on the
Division Trunk System network. Furthermore, 20th CMBG interacts with its coalition
partner, the 10th US Mountain Division, through the MIP Solution. The example is
259
V3.1.4
NA
TI
ON
AL
10 R E
3 AR
LI
NK
20
T
CB
G
B 101
CM
20 CMBG HQ
201
1 VOLTIGEURS
INF BN
202
T
NE
M
IP
DE SO
PL LU
T
10 OYE IO
5
D N
K
UN
TR
ON TEM
SI
VI SYS 0 2
I
D
1
10 US Mountain
DIV
203
Figure 77. Illustration of Example C
8.4.3.2 The data for the example is presented in the table below. Network details
are shown in a previous Table 97.
Table 101. Data for Example C
(a) OBJECT-ITEM
objectitem-id
101
102
103
105
201
202
203
FACILITY
FACILITY
FACILITY
FACILITY
ORGANISATION
ORGANISATION
ORGANISATION
20 CMBG COMMAND CBT NET
NATIONAL REAR LINK
MIP SOLUTION DEPLOYED
20 CMBG HQ
1 VOLTIGEURS INF BN
10 US MOUNTAIN DIV
(b) SECURITY-CLASSIFICATION
*-id
*-level-code
*-policy-text
*-caveat-text
sc440
sc441
sc442
sc443
sc444
sc445
sc446
sc447
sc448
sc449
sc450
Unclassified
Unclassified
Unclassified
Secret
Confidential
Confidential
Confidential
Unmarked
Unmarked
Unmarked
Unmarked
NATO/PFP
NATO/PFP
NATO/PFP
NATO
NATO
NATO
NATO
—
—
—
—
Releasable to NATO/PFP
Releasable to NATO
Releasable to NATO
Releasable to NATO
Releasable to NATO
—
—
—
—
Note: * = "security-classification"
260
V3.1.4
(c) NETWORK-SERVICE
network-id
**-index
**-category-code
**-subcategory-code
101
[20 CMBG COMMAND CBT NET]
102
[DIVISION TRUNK SYSTEM]
102
102
1
Voice service
1
Voice service
2
Facsimile
3
Electronic mail
1
2
3
1
2
3
4
Data transfer
Voice service
Video service
Data transfer
MCI
Tactical data link
MCI Mode 3
Electronic mail
Link 16, data
Note: ** = "network-service"
**-cryptoindicator-code
**-crypto-planshort-title-text
**-crypto-codeshort-title-text
**-iff-modecode-text
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
AMSL 601
AMSL 602
AMSL 602
AMSL 602
AMSL 603
AMSL 603
AMSL 603
AMSL 605
AMSL 605
AMSL 605
AMSL 605
AMST 331
AMST 332
AMST 332
AMST 332
AMST 333
AMST 333
AMST 333
AMST 335
AMST 335
AMST 335
AMST 335
—
—
—
—
—
—
—
—
—
—
—
sc991
sc992
sc992
sc992
sc993
sc993
sc993
sc995
sc995
sc995
sc995
(d) ADDRESS
address-id
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
—
—
—
—
—
—
—
—
—
—
—
—
—
261
V3.1.4
(e) ELECTRONIC-ADDRESS
address-id
network-id
3001
3002
3003
3004
3005
3006
—
123-456-7777
[email protected]
www.20cmbg.mil
www.10UsmntnDiv.mil
123.111.32.10 1010 1
20CMBGNode 1 1
123.111.32.11 1010 1
10MntnDiv 2 2
[email protected]
[email protected]
—
—
—
—
101
102
102
105
105
105
1
2
3
1
1
2
105
2
105
105
105
103
103
103
3
3
4
1
2
3
3007
3008
3009
3010
3011
3012
3013
(f) OBJECT-ITEM-ADDRESS
object-item-id
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
201 [20 CMBG
HQ]
202 [1
VOLTIGEURS
INF BN]
203 [10 US
MOUNTAIN DIV]
203 [10 US
MOUNTAIN DIV]
203 [10 US
MOUNTAIN DIV]
addres
s-id
***inde
x
***-callsigntext
***primacycode
***authorisatio
n-indicatorcode
3001
1
Bravo 2
Primary
Yes
3002
1
—
Yes
3003
1
—
3004
1
—
3006
1
—
3008
1
—
3010
1
—
3011
1
—
3012
1
—
3013
1
—
3001
1
Bravo 9
Secondar
y
Secondar
y
Secondar
y
Secondar
y
Secondar
y
Secondar
y
Secondar
y
Secondar
y
Secondar
y
Primary
3007
1
—
3009
1
—
3010
1
—
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Yes
Secondar
y
Secondar
y
Secondar
y
Yes
Yes
Yes
***-transmitreceive-code
networ
k-id
networkfrequen
cy-index
reporti
ngdata-id
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
Transmit and
receive
—
—
2011
—
—
2011
—
—
2011
—
—
2011
—
—
2011
—
—
2011
—
—
2011
—
—
2011
—
—
2011
—
—
2011
—
—
2021
—
—
2144
—
—
2144
—
—
2144
Transmit and
receive
Transmit and
receive
Transmit and
receive
Note: *** = "object-item-address"
8.4.4 Example D—Complex Intranet-Based Network
8.4.4.1 Example D represents a complex network whose backbone is an intranet
called Danish Eurocom System. The intranet consists of four interconnected radio relays.
Four organisations are connected to the intranet and receive various services. The intranet
provides only telephone service to two of the organisations. The other two organisations
262
V3.1.4
receive a broader range of services. The network is illustrated in the figure below. Each
object in the figure is labelled with a number that is its identifier used in the tabular
example to follow. The intranet in the middle is shaded; its internal connections are shown
graphically but are not represented in the tables. The nets are shown as dashed lines. The
services provided on the nets consist of data transfer with the exception of those nets that
have the service listed in the figure (Net A1, Net B, Net C, and Net D1). All the nets
provide a single service with the exception of Net A1 that features both telephone and
facsimile services.
Org A 2323
Client 11
3705
Ne
t
50 A2
02
Org C
2315
Server 1
3704
Client 12
3706
3
tA
Ne 03
0
5
Net C
7001
Telephone
Net A4
5004
Org B
2333
Net B
6001
Telephone
Net A1 5001
Telephone
Fax
Radio
Relay
73001
Radio
Relay
73002
Radio
Relay
73004
Radio
Relay
73003
Net D1
8011
Telephone
DANISH EUROCOM SYSTEM
73006
Net D2
8012
Org D 2387
Client 21
4508
Client 22
4509
Ne
80 t D3
13
4
tD
Ne 14
80
Figure 78. Illustration of Example D
263
Server 2
4507
V3.1.4
8.4.4.2 The reader should note that the data represents only network topology, i.e.,
the addresses correspond to a network and a service. The objects that participate in a
common net and service use the same address. If more detail were to be provided, such as
the net addresses of any of the servers and clients, then individual addresses would have to
be created for each of the nodes for which the specific address is desired.
8.4.4.3 The data for the example are presented in the table below.
Table 102. Example D—Intranet-Based Network
(a) OBJECT-ITEM
objectitem-id
73006
73001
73002
73003
73004
2323
2333
2315
2387
3704
3705
3706
4507
4508
4509
5001
5002
5003
5004
6001
7001
8011
8012
8013
8014
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
ORGANISATION
ORGANISATION
ORGANISATION
ORGANISATION
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
FACILITY
Danish Eurocom System
Radio Relay 1
Radio Relay 2
Radio Relay 3
Radio Relay 4
Org A Node
Org B Node
Org C Node
Org D Node
Server 1
Client 11
Client 12
Server 2
Client 21
Client 22
Net A1
Net A2
Net A3
Net A4
Net B
Net C
Net D1
Net D2
Net D3
Net D4
264
V3.1.4
(b) FACILITY
facility-id
73006
73001
73002
73003
73004
3704
3705
3706
4507
4508
4509
5001
5002
5003
5004
6001
7001
8011
8012
8013
8014
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
NETWORK
(c) SECURITY-CLASSIFICATION
*-id
*-level-code
*-policy-text
*-caveat-text
sc660
sc661
Secret
Secret
Nation
Nation
—
—
sc662
sc663
sc664
sc665
sc666
Secret
Secret
Secret
Secret
Secret
Nation
Nation
Nation
Nation
Nation
—
—
—
—
—
sc667
sc668
sc669
sc670
Secret
Secret
Secret
Secret
Nation
Nation
Nation
Nation
—
—
—
—
(d) NETWORK
**-id
**-categorycode
**-subcategorycode
**-architecturecode
**-channelcount
73006
5001
5002
5003
5004
6001
7001
8011
8012
8013
8014
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Point-to-point
Packed switched
Circuit switched
Packed switched
Packed switched
Packed switched
Circuit switched
Circuit switched
Circuit switched
Packed switched
Packed switched
Packed switched
Mixed
—
Ethernet
Ethernet
Wireless
—
Wireless
Wireless
Wireless
Ethernet
Ethernet
—
—
—
—
—
—
—
—
—
—
—
Note: ** = "network"
265
V3.1.4
**-means-code
**-set-number-count
Radio relay
Fibre optic
Fibre optic
Fibre optic
Fibre optic
Cable
Mixed
Mixed
Mixed
Cable
Cable
—
—
—
—
—
—
—
—
—
—
—
(e) NETWORK-SERVICE
network-id
***-index
***-category-code
***-subcategory-code
73006
5001
5001
5002
5003
5004
6001
7001
8011
8012
8013
8014
1
1
2
1
1
1
1
1
1
1
1
1
Data transfer
Voice service
Facsimile
Data transfer
Data transfer
Data transfer
Voice service
Voice service
Voice service
Data transfer
Data transfer
Data transfer
***cryptographicindicator-code
***-cryptographicplan-short-titletext
***-cryptographiccode-short-titletext
***-iff-modecode-text
Yes
No
No
No
No
No
No
No
No
No
No
DAMSL 715
—
—
—
—
—
—
—
—
—
—
DAMST 344
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
—
sc660
sc661
sc662
sc663
sc664
sc665
sc666
sc667
sc668
sc669
sc670
266
V3.1.4
(f) ADDRESS
address-id
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
ELECTRONIC-ADDRESS
—
—
—
—
—
—
—
—
—
—
—
—
address-id
network-id
5711
5712
5713
5714
5715
5716
5717
5718
5719
5720
5721
5722
—
—
—
—
—
—
—
—
—
—
—
—
73006
5001
5001
5002
5003
5004
6001
7001
8011
8012
8013
8014
1
1
2
1
1
1
1
1
1
1
1
1
objectitem-id
address
-id
****index
****callsigntext
********authorisationprimacyindicatorcode
code
2323
5712
1
—
—
Yes
2323
5713
1
—
—
Yes
3704
5714
1
—
—
Yes
3704
5715
1
—
—
Yes
3704
5716
1
—
—
Yes
3705
5714
1
—
—
Yes
3706
5715
1
—
—
Yes
2333
5717
1
—
—
Yes
267
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
networknetwork- frequency reporting
id
-index
-data-id
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
V3.1.4
objectitem-id
address
-id
****index
****callsigntext
********authorisationprimacyindicatorcode
code
2315
5718
1
—
—
Yes
2387
5719
1
—
—
Yes
4507
5720
1
—
—
Yes
4507
5721
1
—
—
Yes
4507
5722
1
—
—
Yes
4508
5721
1
—
—
Yes
4509
5722
1
—
—
Yes
73001
5711
1
—
—
Yes
73001
5712
1
—
—
Yes
73001
5716
1
—
—
Yes
73001
5717
1
—
—
Yes
73002
5711
1
—
—
Yes
73002
5718
1
—
—
Yes
73003
5711
1
—
—
Yes
73003
5719
1
—
—
Yes
73003
5720
1
—
—
Yes
73004
5711
1
—
—
Yes
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
Transmit
and
receive
networknetwork- frequency reporting
id
-index
-data-id
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
—
—
333
8.4.5 Example E: Use of NETWORK in Air Tasking Order
8.4.5.1 Each planned aerial mission implies the specification of a code for each
mode the IFF/SIF uses. Each code has a significant operational meaning. For the
establishment of the mission, it is necessary to exchange these elements through an Air
Tasking Order (ATO). For example. Mode 3 and its corresponding code brings knowledge
268
V3.1.4
on the IFF associated with this mission (e.g. flight phase, mission type, control agency,
etc.). The following ATO excerpt shows in bold how the IFF/SIF codes are captured.
AMSNDAT/1743/-/-/-/GAR/-/30M/DEPLOC:NZCH/ARRLOC:NZCH//
MSNACFT/1/OTHAC:KC130J/MOBIL43/-/-/21743/34211//
AMSNLOC/091700ZJUN/092300ZJUN//
AMPN/ALERT STATUS FOR AAR 2//
TASKUNIT/5 SQUADRON/ICAO:NZAA//
The first digit encodes the mode number (for example, 21743 is mode 2 and 34211 is
mode 3). The table below shows the usage of the NETWORK subtree that captures this
data. A more complete example would show how the ACTION structure (through
OBJECT-ITEM-ADDRESS) is used to represent fully the ATO mission as shown above.
Table 103. Example E—NETWORK and Air Tasking Order
(a) OBJECT-ITEM
object-item-id
3562
FACILITY
—
(b) FACILITY
facility-id
3562
NETWORK
(c) NETWORK
network-id
3562
C
*-id
*-level-code
*-policy-text
*-caveat-text
sc11
sc12
Secret
Secret
Nation
Nation
—
—
(e) NETWORK-SERVICE
network-id
network-servicecategory-code
network-servicesubcategory-code
3562
[IFF/SIF placeholder]
3562
[IFF/SIF placeholder]
1
Identification friend or foe
IFF mode 2
sc11
2
Identification friend or foe
IFF mode 3
sc12
(f) ADDRESS
address-id
10001
ELECTRONIC-ADDRESS
IFF/SIF mode/code placeholder
269
V3.1.4
address-id
electronic-addressname-text
network-id
10001
1743
3562
1
10001
4211
3562
2
8.4.5.2 Sub-table (d) explicitly identifies the IFF/SIF modes, while Sub-table (f)
the IFF/SIF codes. The combination represents in data the full IFF/SIF mode and code
(21743 and 34211) as used in the ATO.
8.4.6 Example F: Electronic Intelligence Activity Reporting
8.4.6.1 An EW squadron is conducting an ESM-type mission in its area of
operations. At 1837, a 6-second radio transmission (VHF frequency band, encrypted) is
detected. This example shows how the NETWORK structure is used in reporting such an
event. Based on this information the higher echelon would consider the next course of
action that includes an option to conduct a jamming operation against the source of
emission.
8.4.6.2 The definition of a network and its parameters that characterise the
intercept and serves as the basis for the intercept report is presented in the table below.
Table 104. Definition of a Network for Intercept Reporting
(a) OBJECT-ITEM
objectitem-id
356
FACILITY
EW Intercept
(b) FACILITY
facility-id
356
NETWORK
(c) NETWORK
networkid
networkcategory-code
networksubcategory-code
network-meanscode
356
Broadcast
—
Radio link,
terrestrial
(d) NETWORK-FREQUENCY
network
-id
*index
*-band-code
356
1
Very high frequency
*-channelnumber-text
*-discretefrequencyquantity
*-band-lowerfrequencyquantity
*-band-upperfrequencyquantity
—
6040
3000
10800
Note: * = "network-frequency"
270
V3.1.4
8.4.6.3 The intercept is reported as an instance of ACTION-EVENT where the
ACTION-RESOURCE is the nominal network defined in the previous table. ACTIONOBJECTIVE remains unspecified because it is not known. Details of data are presented in
the table below. Sub-tables (a) - (d) specify the event, whereas Sub-table (e) through its
link to REPORTING-DATA (Sub-tables (f) and (g)) provides critical information about
the intercept including the reporting organisation and the time and duration of the
intercept.
Table 105. Report of an Emission Intercept
(a) ACTION
action-id
action-name-text
87014
ACTION-EVENT
EW Activity Report 7004
(b) ACTION-EVENT
action-event-id
87014
Communications interception
(c) ACTION-RESOURCE
action-resourcecategory-code
action-resourcecriticalityindicator-code
action-resourcequalifier-code
action-resourceauthorisingorganisation-id
ACTION-RESOURCE-ITEM
—
—
—
actionaction resource
-index
-id
87014
1
(d) ACTION-RESOURCE-ITEM
action-id
action-resource-index
object-item-id
87014
1
356
(EW Intercept)
(e) ACTION-EVENT-STATUS
actionevent-id
action-eventstatus-index
action-event-statuscompletion-ratio
action-eventstatus-feintindicator-code
reporting-data-id
87014
1
1.0
No
rd278
(f) REPORTING-DATA
*-id
*-categorycode
*-credibilitycode
rd278
Reported
Reported as a
fact
20050927190300.000
232 [ELINT org]
(g) REPORTING-DATA-ABSOLUTE-TIMING
**-reporting-data-id
rd278
20050927183705.000
20050927183711.000
8.4.6.4 At this stage it would be simple to specify a counteraction, such as
electronic jamming, in a form of an ACTION-TASK that would be linked to the emission
event via ACTION-FUNCTIONAL-ASSOCIATION using a value "In response to" for
the category code.
271
V3.1.4
(This page is left blank intentionally)
272
V3.1.4
9.
OBJECT-ITEM ASSOCIATIONS
9.1
Introduction
There is a requirement to link an instance of OBJECT-ITEM to another instance in
order to describe the relationships that exist between them. A prime example is the set of
command relationships between units; relationships may be created, changed, or
terminated at various times as needed in response to current operations and plans.
9.2
Data Structure for Associations
9.2.1. The construct for associations is illustrated in the figure below. It allows
any instance of OBJECT-ITEM to be related to any other. For example, a unit can be
related to another unit to express command relationships by using the entity OBJECTITEM-ASSOCIATION. The nature of a relationship is specified by means of attributes in
the association entity. The status entity is part of the mechanism to indicate the start or end
of an actual or planned association. The effective date is one of the information elements
conveyed through REPORTING-DATA, but the status entity states whether the effective
date is a beginning or termination of an association.
OBJECT-ITEM
object-item-id
is-the-subject-of
is-the-object-of
ORGANISATION
object-item-association-subject-object-item-id (FK)
object-item-association-object-object-item-id (FK)
object-item-association-index
object-item-association-category-code
object-item-association-subcategory-code
action-task-id (FK)
has /
is-ascribed-to
is-reported-by
REPORTING-DATA
reporting-data-id
P
object-item-association-index (FK)
object-item-association-status-index
object-item-association-status-category-code
reference-id (FK)
is-referenced-to
Figure 79. Specification of OBJECT-ITEM-ASSOCIATION Structure
273
V3.1.4
9.2.2 The entity OBJECT-ITEM-ASSOCIATION is defined as a relationship of
an OBJECT-ITEM as a subject with another OBJECT-ITEM as an object. Its attributes are
defined as follows:
a.
object-item-association-subject-object-item-id—The object-item-id of a
specific OBJECT-ITEM that serves as the subject of a specific OBJECTITEM-ASSOCIATION (a role name for object-item-id).
b.
object-item-association-object-object-item-id—The object-item-id of a
specific OBJECT-ITEM that serves as the object of a specific OBJECTITEM-ASSOCIATION (a role name for object-item-id).
c.
object-item-association-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-ASSOCIATION for a
subject OBJECT-ITEM and an object OBJECT-ITEM and to distinguish it
from all other OBJECT-ITEM-ASSOCIATIONs for those OBJECT-ITEMs.
d.
object-item-association-category-code—The specific value that represents
the type of relationship between the subject OBJECT-ITEM and the object
OBJECT-ITEM in a specific OBJECT-ITEM-ASSOCIATION. Note: The
full set of domain values for the category code is available in Annex E.
e.
object-item-association-subcategory-code—The
specific
value
that
represents the detailed type of relationship between the subject OBJECTITEM that is an ORGANISATION and the object OBJECT-ITEM that is an
ORGANISATION in a specific OBJECT-ITEM-ASSOCIATION. The full
set of domain values for object-item-association-subcategory-code is
available in Annex E.
f.
action-task-id—The action-id of a specific ACTION-TASK (a role name for
action-id). Note: This foreign-key attribute is migrated through the
relationship "references" from ACTION-TASK. Its use is described in
Chapter 16.
9.2.3 The business rules that set out the permissible values for object-itemassociation-category-code for pairs of OBJECT-ITEMs as well as the additional rules that
apply to subcategory code for ORGANISATION to ORGANISATION relationships are
specified in Annex G2, Section G2.7.1. The values may be thought of as describing a
semantically correct relationship between a subject and an object or, equivalently, between
a "parent" and a "child." Additional rules that apply to Q-routes are specified in Annex
G1, Section G1.6.1.
9.2.4 The primary purpose of the entity OBJECT-ITEM-ASSOCIATIONSTATUS is to mark the beginning and termination of an association. It is defined as a
record of the perceived condition of a specific OBJECT-ITEM-ASSOCIATION as
determined by the reporting organisation. The attributes of OBJECT-ITEMASSOCIATION-STATUS are defined as follows:
a.
274
V3.1.4
b.
c.
d.
object-item-association-status-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-ASSOCIATION-STATUS
for a specific OBJECT-ITEM-ASSOCIATION and to distinguish it from all
other OBJECT-ITEM-ASSOCIATION-STATUSs for that OBJECT-ITEMASSOCIATION.
e.
object-item-association-status-category-code—The specific value that
indicates if the status of a specific OBJECT-ITEM-ASSOCIATIONSTATUS refers to the beginning or termination of the association. The
domain values are: End; Start. The domain value set for this attribute is
shared with one or more other attributes and is defined in the set associationstatus-category-code.
f.
REPORTING-DATAs.
9.3
An Example of Organisational Relationships
9.3.1 An important aspect in military operations is the specification of groupings
in formations, often referred to as order of battle. The model construct of OBJECT-ITEMASSOCIATION provides a mechanism for this. The categorisation is specified through
two attributes as follows:
a.
object-item-association-category-code—The business rule for domain values
indicates that there are four general categories for grouping the associations
between two organisations: Admin and combat service support, Command
and control, Fire unit and combat support, and Supplementary.
b.
object-item-association-subcategory-code—This attribute lists the specific
categories that are assigned to one of the general groups. The full list is
provided in Annex E.
Permissible doctrinal combinations of domain values for category and subcategory codes
when the associations apply to ORGANISATIONs are specified as part of Annex G2,
Section G2.7.1.
9.3.2 The third data attribute—action-task-id—is used to link an instance of an
association to an instance of a task. Application of this attribute is illustrated in Section
16.6.
275
V3.1.4
9.3.3 A specific example of organisational relationships is represented in the
table below to show the following:
a.
1 RHA is under Operational Command of the 52nd Mechanised Infantry
Division.
b.
1 R IRISH is under Tactical Control of the 52nd Mechanised Infantry
Division.
c.
1 RHA is in Direct Support of the 1 R IRISH.
d.
1 R IRISH is Under Command for Administration of the 52nd Mechanised
Infantry Division.
Table 106. Examples of Associations between ORGANISATIONs40
*-subject-objectitem-id
*-object-objectitem-id
*-index
*-category-code
*-subcategory-code
57
[52 Inf Div (M)]
1793
[1 RHA]41
1
Command and control
Has operational
command of
57
[52 Inf Div (M)]
3051
[1 R IRISH]
57
[52 Inf Div (M)]
3051
[1 R IRISH]
1793
[1 RHA]
3051
[1 R IRISH]
1
Command and control
Has tactical control of
1
Fire unit and combat
support
Has under command for
admin
Has in direct support
2
Support services - per
adm rpl
Note: * = "object-item-association"
9.4
An Example of Associations between Organisations and Materiel
A supporting unit needs to earmark half of its diesel fuel supply for use by a
supported unit. The data tables for this example are shown in the table below. The objects
of interest are defined in Sub-tables (a) through (d) and the allocation of fuel is made
through the association in Sub-table (e) for the notional units identified as 57 and 1793.
Table 107. Use of Associations between ORGANISATIONs and MATERIEL
(a) MATERIEL-TYPE
materiel-type-id
[object-type-name-text]
24301101
Bladder of diesel fuel
*-id
*-category-code
24301101
POL
*-subcategorycode
*-issuing-elementcode
*-issuing-count
Diesel fuel
Bulk
10,000
Litre
41
1 RHA: 1st Regiment Royal Horse Artillery, which is a UK field artillery regiment.
40
276
V3.1.4
(c) OBJECT-ITEM
object-item-id
10001
10002
MATERIEL
MATERIEL
Bladder 1
Bladder 2
(d) OBJECT-ITEM-TYPE
object-item-id
object-type-id
reporting-data-id
10001
10002
24301101
24301101
1
1
14001
14002
(e) OBJECT-ITEM-ASSOCIATION
**-subject-objectitem-id
**-objectobject-item-id
**-index
**-category-code
57
[supporting unit]
57
[supporting unit]
1793
[supported unit]
10001
1
Is accounting authority for
10002
1
Is accounting authority for
10002
1
Consumes
Note: ** = "object-item-association"
9.5
An Example of Associations between Organisations and Persons
9.5.1 The table below provides examples of OBJECT-ITEM-ASSOCIATION
when the subject is an ORGANISATION and the object is a PERSON. This example also
includes the extension to status in Sub-table (b) as well as the appropriate instances of
REPORTING-DATA as illustrated in Sub-tables (c) and (d). In this example, Person 4 has
been assigned to Organisation 1793 on 15 February 2000 with an expected term of 4
months. Since there is no other data, it must be assumed that he is still assigned to the
same organisation. The history of Person 1 is detailed next.
9.5.2 The history of Person 1 is as represented in data follows:
a.
Person 1 is assigned to Organisation 7818 on 15 July 1996.
b.
Person 1 is attached to Organisation 3051 on 1 December 1999 for an
expected duration of one month.
c.
The attachment of Person 1 to Organisation 3051 is terminated on 2 January
2000; Person 1 returns to his assigned organisation where he is expected to
spend only 3 more weeks.
d.
The assignment of Person 1 to Organisation 7818 is terminated on 28
February 2000.
e.
Person 1 is assigned to Organisation 3051 on 1 March 2000 and is expected
to be with Organisation 3051 for a period of 3 years.
277
V3.1.4
Table 108. Instances of Associations between ORGANISATION an PERSON
(a) OBJECT-ITEM-ASSOCIATION
*-objectobject-item-id
*-index
*-category-code
7818
[Person 1]
1
Has on assignment
3051
3051
1793
[Person 1]
[Person 1]
[Person 4]
1
2
1
Has on attachment
Has on assignment
Has on assignment
(b) OBJECT-ITEM-ASSOCIATION-STATUS
*-objectobject-item-id
*
-index
**-index
**-categorycode
reportingdata-id
7818
3051
3051
3051
7818
1793
1793
[Person 1]
[Person 1]
[Person 1]
[Person 1]
[Person 1]
[Person 4]
[Person 4]
1
1
1
1
1
1
1
1
1
2
3
2
1
2
Start association
Start association
End association
End association
End association
Start association
End association
303
21
22
23
309
37
38
7818
3051
3051
[Person 1]
[Person 1]
[Person 1]
1
2
2
3
1
2
End association
Start association
End association
374
55
61
Note: ** = "object-item-association-status"
(c) REPORTING-DATA
***-id
***-categorycode
***-credibility-code
***-timingcategory-code
***-reportingorganisation-id
303
Reported
Reported as a fact
[absolute]
7818
21
22
23
309
37
Reported
Planned
Reported
Planned
Reported
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
[absolute]
[absolute]
[absolute]
[absolute]
[absolute]
3051
3051
3051
7818
1793
38
374
55
61
Planned
Reported
Reported
Planned
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
[absolute]
[absolute]
[absolute]
[absolute]
1793
7818
3051
3051
Note: *** = "reporting-data"
****-reporting-data-id
****-effective-start-datetime
****-effective-end-datetime
303
21
22
23
309
37
38
374
55
19960715000000.000
19991201090000.000
20000101000000.000
20000102120000.000
20000123000000.000
20000215000000.000
20000615000000.000
20000228000000.000
20000301090000.000
—
—
—
—
—
—
—
—
—
20030228000000.000
—
61
Note: **** = "reporting-data-absolute-timing"
278
V3.1.4
9.6
Example of Using a Facility as Part of an Obstacle
9.6.1 The White Horse Bridge across the Yukon River initially serves as a
passage between two minefields located on the north side of the river, one on each side of
the bridge. The contingency plan is to use the bridge as part of an obstacle. If the units of
the joint task force that are now deployed on the north side of the river need to withdraw,
the bridge will be demolished to become part of the main obstacle. The general layout is
illustrated in the figure below where North is toward top of the page.
Figure 80. An Example of an Obstacle
9.6.2 The sequence of events is as follows:
a.
On 22 October 2003, 1 CA Brigade creates a contingency plan to set up an
Obstacle Alpha that consists of three components: two minefields and a
demolished bridge.
b.
Minefield West is laid and activated on 2 November, followed by Minefield
East on 3 November.
c.
The White Horse Bridge is reported to be prepared for demolition on 3
November.
d.
On 7 November, the brigade elements north of the river cross to the south.
The bridge is demolished and Obstacle Alpha becomes operational in its
entirety.
9.6.3 The data representation of this sequence is shown in the table below. Subtables (a), (b), (c), (d), and (e) specify the four facilities of interest in this scenario. The
status of the facilities is specified in Sub-tables (f) and (g), while associations that link the
three components to Obstacle Alpha are specified in Sub-tables (h) and (i). The last two
Sub-tables (j) and (k) provide the timing information as appropriate. There are two status
records each for the bridge and Obstacle Alpha. The first status for the bridge reports it as
operational and prepared for demolition, while the second status entry reports the
demolition. The first status for Obstacle Alpha is a planning entry with no effective time,
while the second one indicates that Obstacle Alpha is implemented at the same time as the
bridge demolition.
279
V3.1.4
Table 109. Data for Obstacle Example
(a) OBJECT-ITEM
FACILITY
objectitem-id
facilityid
1
West Minefield
1
2
East Minefield
2
3
Obstacle Alpha
3
4
White Horse Bridge
4
facility-categorycode
facilityheightdimension
facilitylengthdimension
facilitywidthdimension
—
300
105
—
320
90
—
650
325
—
200
10
MILITARYOBSTACLE
MILITARYOBSTACLE
MILITARYOBSTACLE
BRIDGE
(b) BRIDGE
bridge-id
bridge-longest-spanlength-dimension
bridge-spancount
bridge-usagecode
4
40
5
Railway/vehicle
(c) MILITARY-OBSTACLE
military-obstacle-id
1
2
3
MINEFIELD
MINEFIELD
NOS
(d) MINEFIELD
minefield
-id
minefieldcategory-code
minefieldidentification-text
minefield-minespacing-dimension
1
2
MINEFIELD-LAND
MINEFIELD-LAND
Minefield West
Minefield East
10 (m)
10 (m)
(e) MINEFIELD-LAND
minefieldland-id
minefieldland-depthplacementcode
minefieldland-functioncode
1
Mixed
Nuisance
2
Mixed
Nuisance
minefield-landpattern-code
minefieldlandpersistence
-code
minefieldlandstoppingpower-code
Regular minefield,
thickened with
scattered mines
Regular minefield,
thickened with
scattered mines
Remote
activated
destruction
Remote
activated
destruction
Medium
(f) OBJECT-ITEM-HOSTILITY-STATUS
object-item-id
*-index
*-code
reporting-data-id
1[Minefield West]
2 [Minefield East]
3 [Obstacle Alpha]
4 [White Horse Bridge]
3 [Obstacle Alpha]
1
1
1
1
2
2
Friend
Friend
Friend
Friend
Friend
Friend
695
696
697
698
699
700
Note: * = "object-item-hostility-status"
280
Medium
V3.1.4
(g) OBJECT-ITEM-STATUS
object-item-id
*index
*-category-code
*-booby-trapindicator-code
reportingdata-id
1[Minefield West]
1
FACILITY-STATUS
—
—
701
2 [Minefield East]
3 [Obstacle Alpha]
3 [Obstacle Alpha]
1
1
1
2
2
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
FACILITY-STATUS
—
—
—
—
—
—
—
—
—
—
702
703
704
705
705
(h) FACILITY-STATUS
facility-status-id
**demolitionstatus-code
**-minepresence
-code
**-occupationprogramindicator-code
—
—
—
Prepared for
execution
Yes
Yes
Yes
No
—
—
—
—
Executed
No
—
—
Yes
—
1[Minefield West]
2 [Minefield East]
3 [Obstacle Alpha]
4 [White Horse
Bridge]
4 [White Horse
Bridge]
1
1
1
3 [Obstacle Alpha]
2
1
2
**-category-code
Note: ** = "facility-status"
**-operational-statuscode
**-operational-statusqualifier-code
**-reserveindicator-code
**-securitystatus-code
**-usagestatus-code
Operational
Operational
Not operational
Operational
—
—
Prepared for execution
Passable
—
—
—
—
—
—
—
—
Activated
Activated
—
—
Not operational
Operational
Destroyed
—
—
—
—
—
—
Activated
(i) OBJECT-ITEM-ASSOCIATION
***-subject-objectitem-id
***-object-objectitem-id
***index
***-categorycode
***-subcategorycode
1[Minefield West]
2 [Minefield East]
4 [White Horse
Bridge]
3 [Obstacle Alpha]
3 [Obstacle Alpha]
1
1
Is part of
Is part of
—
—
3 [Obstacle Alpha]
1
Is part of
—
Note: *** = "object-item-association"
(j) OBJECT-ITEM-ASSOCIATION-STATUS
***-subjectobject-item-id
***-objectobject-item-id
***
-index
***-status-index
***-statuscategory-code
reportingdata-id
1
3
1
1
Start association
711
2
4
1
2
4
3
3
3
3
3
1
1
1
1
1
1
1
2
2
2
Start association
Start association
Start association
Start association
Start association
711
711
712
712
712
281
V3.1.4
(k) REPORTING-DATA
****-id
****categorycode
701
702
703
Reported
Reported
Planned
—
—
—
Reported as a fact
Reported as a fact
Reported as a fact
20031102094900.000
20031103154200.000
20031022103000.000
704
Reported
—
Reported as a fact
20031103171000.000
705
711
Reported
Planned
—
—
Reported as a fact
Reported as a fact
20031107081000.000
20031022103000.000
712
Reported
—
Reported as a fact
20031107081000.000
****-countingindicator-code ****-credibility-code
****-reporting-datetime
****-timingcategorycode
****-reportingorganisationid
[absolute]
[absolute]
Timing not
available
Timing not
available]
[1 CA Bde]
[1 CA Bde]
[1 CA Bde]
[absolute]
Timing not
available
[absolute]
[1 CA Bde]
[1 CA Bde]
[1 CA Bde]
[1 CA Bde]
Note: **** = "reporting-data"
(l) REPORTING-DATA-ABSOLUTE-TIMING
*****-reporting-data-id
701
702
705
712
*****-effective-start-datetime *****-effective-end-datetime
20031102094500.000
20031103153000.000
20031107080000.000
20031107080000.000
—
—
—
—
Note: ***** = "reporting-data-absolute-timing"
9.7
A Technique for Representing Unit Boundaries Using Associations
9.7.1 Introduction
9.7.1.1
The purpose of tactical boundaries is to regulate responsibilities for
certain areas in order to avoid conflicts between operations conducted by adjacent units.
Traditionally the human brain can comprehend readily who is responsible for which area
when the boundaries are drawn on a paper map. The challenge is to create data
specifications that can be displayed to the human in the accustomed form but also to
assure that an automated application can understand it in the same way.
9.7.1.2
This section presents the recommended technique for the creation and
display of unit boundaries by use of associations. The technique assures conformance to
APP-6A symbology standard for showing unit boundaries.
9.7.2 Requirement for Representation of Unit Boundaries
9.7.2.1
APP-6A states that a unit boundary can have certain modifiers as
Figure 81. APP-6A Symbol Modifiers
282
V3.1.4
9.7.2.2
The modifiers are listed as follows:
B
Echelon (unit-type-size-code and control-feature-type-echeloncode in data model terms).
N
Hostile (enemy) (a text modifier to indicate hostility = ENY, not
relevant to this example)
T
Unique Designation (of the unit on one side, typically unit-formalabbreviated-name-text)
T1
Unique Designation (of the unit on the other side, typically unitformal-abbreviated-name-text)
9.7.2.3
An example is illustrated in the figure below:
Figure 82. Example of Modifiers for APP-6A Symbol
9.7.2.4
In order to specify the correct unique designators for the symbol it is
necessary to associate the units (in the example above units 2ID and 25ID) with the actual
line (a CONTROL-FEATURE) using OBJECT-ITEM-ASSOCIATION.
9.7.3 Development of an Example
9.7.3.1
A typical operational layout for a division with two brigades forward
deployed is illustrated in the figure below. Each of the brigades has two battalions forward
deployed. All boundaries are marked with appropriate modifiers according to APP-6A.
9.7.3.2
These include:
Several steps are involved in developing the data for the example.
a.
The identification (in data) of units themselves.
b.
The definition of control features that represent segments of unit boundaries.
c. The association of control features with the units in order to provide proper
annotation for the boundaries.
283
V3.1.4
Figure 83. An Example of Unit Boundaries
9.7.3.3
In order to set the scene, it is necessary to identify the units for which
the boundaries will be drawn. The table below presents a list of units that appear in the
figure above. The UNIT table shows the abbreviated unit names that are used for labelling
boundary segments.
Table 110. Sample Units for the Boundary Example
(a) OBJECT-ITEM
object-item-id
4597
ORGANISATION
1st Division
4598
4599
4600
4601
4602
ORGANISATION
ORGANISATION
ORGANISATION
ORGANISATION
ORGANISATION
1st Brigade
2nd Brigade
1st Battalion 1st Brigade
2nd Battalion 1st Brigade
1st Battalion 2nd Brigade
4603
ORGANISATION
2nd Battalion 2nd Brigade
(b) ORGANISATION
organisation-id
4597
4598
4599
4600
UNIT
UNIT
UNIT
UNIT
4601
4602
4603
UNIT
UNIT
UNIT
284
V3.1.4
(c) UNIT
unit-id
4597
4598
4599
4600
4601
4602
4603
1DIV
1.1BDE
1.2BDE
1.1.1BN
1.1.2BN
1.2.1BN
1.2.2BN
9.7.3.4
The unit boundaries for the example can be represented by using 12
instances of CONTROL-FEATURE as specified in the table below.
Table 111. Identification of CONTROL-FEATUREs
(a) OBJECT-ITEM
object-item-id
1
2
3
4
5
6
7
8
9
10
11
FEATURE
FEATURE
FEATURE
FEATURE
FEATURE
FEATURE
FEATURE
FEATURE
FEATURE
FEATURE
FEATURE
1Div Left Boundary
1Div Rear Boundary
1Div Right Boundary
1.2BDE Rear Boundary
1.1BDE Rear Boundary
1.1BDE/1.2BDE Common Boundary
1.2.1BN Rear Boundary
1.2.1BN/1.2.2BN Common Boundary
12
FEATURE
1.1.1BN/1.1.2BN Common Boundary
(b) FEATURE
feature-id
1
2
3
4
5
CONTROL-FEATURE
CONTROL-FEATURE
CONTROL-FEATURE
CONTROL-FEATURE
CONTROL-FEATURE
6
7
8
9
10
CONTROL-FEATURE
CONTROL-FEATURE
CONTROL-FEATURE
CONTROL-FEATURE
CONTROL-FEATURE
11
12
CONTROL-FEATURE
CONTROL-FEATURE
9.7.3.5
The key requirement arising from APP-6 that must be implemented in
automated systems is to associate unambiguously and explicitly a unit with every instance
of CONTROL-FEATURE that pertains to it. This includes the proper labelling of
boundaries with unit and echelon designators.
9.7.3.6
In order to provide the proper unit annotation for the control features
the following business rules that are part of the existing model specification are invoked:
a.
Some uses of line entail a direction, as in axis of advance. In this case, the
instance of LINE has to be interpreted as a sequence of directed line
285
V3.1.4
segments. The direction of the line is assumed to be in the ascending
enumeration of the points that define the line.
b.
Some uses of line entail a preferred side, such as forward line of own troops
(FLOT) where the symbology calls for dragon teeth on one side. When side
has meaning for a line, the left-hand side is interpreted according to the
direction of the line as determined from an ascending numeration of the
points of the line (this is referred to as the Left Hand Rule).
When the values “Is to the left of” and “Is to the right of” for object-item-associationcategory-code are used in conjunction with directed line segments, then it is possible to
place the modifiers (T and T1) properly.
9.7.3.7
The figure below shows the direction of the different lines forming the
boundaries as in the example. The illustration is included in order to assist the reader in
understanding why the particular values for object-item-association-category-code are
chosen in the following set of figures.
Figure 84. Unit Boundaries with Indicated Line Directions
9.7.3.8
The geometric representation of the associations of units to the various
boundaries is illustrated in a series of figures (Figure 85, Figure 86, Figure 87, and Figure
88). These associations are specified as data to provide the proper designation of unit
boundaries in accordance with APP-6A. It should be noted that two additional associations
are needed for brigades besides those in Figure 86 in order to show brigade relationships
to division boundaries.
286
V3.1.4
Figure 85. Division in Relation to Its Boundaries
Figure 86. Brigades in Relation to Their Own and Division Boundaries
287
V3.1.4
Figure 87. Battalions in Relation to Their Own Boundaries
Figure 88. Battalions in Relation to Brigade and Division Boundaries
288
V3.1.4
9.7.3.10 The table below contains 21 entries that record the associations needed
to represent battlefield geometry for the example.
Table 112. Boundary CONTROL-FEATUREs for the Units
*-index
*-category-code
4597
1
1
Is to the left of
4597
4597
4599
4598
4599
4598
4599
4598
4602
4603
4600
4601
4602
4603
4600
4601
4602
4601
4600
4603
2
3
4
5
6
6
1
3
7
8
9
10
11
11
12
12
1
3
6
6
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
Is to the left of
Is to the left of
Is to the left of
Is to the left of
Is to the left of
Is to the right of
Is to the left of
Is to the left of
Is to the left of
Is to the left of
Is to the left of
Is to the left of
Is to the left of
Is to the right of
Is to the left of
Is to the right of
Is to the left of
Is to the left of
Is to the right of
Is to the left of
9.7.3.11 OBJECT-ITEM-ASSOCIATION has a companion status entity that is
linked to REPORTING-DATA that would identify the units responsible for each boundary
specification.
9.7.4 Graphic Representation of Unit Boundaries
An instance of CONTROL-FEATURE is a logical construct that cannot be
represented on a display without further specification. It must be instantiated by
association either to a geometric construct (such as the lines suggested by the figures in the
example) or to other elements of the battlefield, such as geographic features (rivers,
streams, ridges, forest lines, and so on) or a combination of the two. The following values
of object-item-association-category-code permit geographic features to be linked to
control features:
Value
Definition
Is physically partially represented by
all of
Part of the subject CONTROL-FEATURE is described or delineated
by the whole of the object GEOGRAPHIC-FEATURE.
Is physically partially represented by
part of
Part of the subject CONTROL-FEATURE is described or delineated
by part of the object GEOGRAPHIC-FEATURE.
entirety by all of
The whole of the subject CONTROL-FEATURE is described by the
whole of the object GEOGRAPHIC-FEATURE.
entirety by part of
The whole of the subject CONTROL-FEATURE is described by part
of the object GEOGRAPHIC-FEATURE.
289
V3.1.4
9.7.5 Restricted Use of Association Values in Specifying Unit Boundaries
The following values of object-item-association-category-code must not be used
for specifying organisational boundaries when the boundaries are defined in accordance
with APP-6A requirements:
Value
9.8
Definition
Is bounded in the front by
The subject ORGANISATION has part or all of its frontal boundary
specified by the object CONTROL-FEATURE.
Is bounded in the rear by
The subject ORGANISATION has part or all of its rear boundary
specified by the object CONTROL-FEATURE.
Is bounded on the left by
The subject ORGANISATION has part or all of its left-flank
boundary specified by the object CONTROL-FEATURE.
Is bounded on the right by
The subject ORGANISATION has part or all of its right-flank
boundary specified by the object CONTROL-FEATURE.
Is partially bounded by
The subject OBJECT-ITEM is partially bounded by the object
OBJECT-ITEM.
Organisational Structure
9.8.1 Introduction
It is difficult to infer organisational hierarchies purely from instances stored in
OBJECT-ITEM-ASSOCIATION. The hierarchy can only be inferred from an exhaustive
examination of relationship records. This section describes data specifications to enable
appropriate relationships to be described explicitly as part of a recognised group, such as
an order-of-battle (ORBAT) or a unit task organisation (UTO).
9.8.2 Specification
9.8.2.1 The structure is illustrated in the figure below. An organisational structure
can be described using ORGANISATION-STRUCTURE, ORGANISATIONSTRUCTURE-DETAIL and OBJECT-ITEM-ASSOCIATIONs (if more than one unit is
required in an ORBAT). ORGANISATION-STRUCTURE is a child of
ORGANISATION to serve as the top-level entity that together with ORGANISATIONSTRUCTURE-DETAIL identifies all instances of OBJECT-ITEM-ASSOCIATION that
pertain to the specific instance of ORGANISATION-STRUCTURE. This specification
enables the re-use of any relationship recorded in OBJECT-ITEM-ASSOCIATION in
multiple
instances
of
ORGANISATION-STRUCTURE.
ORGANISATIONSTRUCTURE is linked to ACTION-TASK through an optional non-identifying
relationship.
290
V3.1.4
OBJECT-ITEM
ACTION
object-item-id
is-the-subject-of
is-the-object-of
action-id
action-name-text
ORGANISATION
organisation-id.object-item-id (FK)
is-configured-as-specified-in /
specifies-the-configuration-of
object-item-association-subject-object-item-id.object-item-id (FK)
object-item-association-object-object-item-id.object-item-id (FK)
object-item-association-index
object-item-association-category-code
object-item-association-subcategory-code
action-task-id (FK)
organisation-structure-root-organisation-id.organisation-id (FK)
organisation-structure-index
organisation-structure-name-text
organisation-structure-category-code
includes /
is-an-element-of
is-referenced-in /
refers-to
ORGANISATION-STRUCTURE-DETAIL
organisation-structure-root-organisation-id (FK)
organisation-structure-index (FK)
organisation-structure-detail-index
object-item-association-index (FK)
is-specified-for /
requires-the-use-of
references /
is-relevant-for
ACTION-TASK
action-task-id.action-id (FK)
action-task-activity-code
action-task-minimum-duration
action-task-estimated-duration
action-task-maximum-duration
action-task-planned-start-datetime
action-task-start-qualifier-code
action-task-planned-end-datetime
action-task-end-qualifier-code
action-task-priority-code
action-task-entailed-safety-degree-code
action-task-overt-covert-code
action-task-detail-text
action-task-timing-day-code
action-task-timing-hour-code
action-task-meteorological-impact-code
action-task-operational-level-code
candidate-target-list-id (FK)
Figure 89. Specification of ORGANISATION-STRUCTURE
9.8.2.2 The entity ORGANISATION-STRUCTURE is defined as the hierarchical
configuration of a specific root ORGANISATION where the configuration is specified by
reference to a set of associations between instances of OBJECT-ITEM. Its attributes are:
a.
organisation-structure-root-organisation-id—The organisation-id of a
specific ORGANISATION that is the root of the hierarchy for a specific
ORGANISATION-STRUCTURE (a role name for object-item-id).
b.
organisation-structure-index—The unique value, or set of characters,
assigned to represent a specific ORGANISATION-STRUCTURE for a
specific ORGANISATION and to distinguish it from all other
ORGANISATION-STRUCTUREs for that ORGANISATION.
c.
organisation-structure-name-text—The character string assigned to represent
a specific ORGANISATION-STRUCTURE.
291
V3.1.4
d.
REPORTING-DATAs.
e.
organisation-structure-category-code—The specific value that represents the
type of the ORGANISATION-STRUCTURE. The domain values are: Order
of battle, Task organisation and Not otherwise specified.
9.8.2.3 The entity ORGANISATION-STRUCTURE-DETAIL is defined as “The
identification of a specific OBJECT-ITEM-ASSOCIATION as an element in a specific
ORGANISATION-STRUCTURE.” The attributes are:
a.
organisation-structure-root-organisation-id—The organisation-id of a
specific ORGANISATION that is the root of the hierarchy for a specific
ORGANISATION-STRUCTURE (a role name for object-item-id).
b.
organisation-structure-index—The unique value, or set of characters,
assigned to represent a specific ORGANISATION-STRUCTURE for a
specific ORGANISATION and to distinguish it from all other
ORGANISATION-STRUCTUREs for that ORGANISATION.
c.
organisation-structure-detail-index—The unique value, or set of characters,
assigned to represent a specific ORGANISATION-STRUCTURE-DETAIL
for a specific ORGANISATION-STRUCTURE and to distinguish it from all
other
ORGANISATION-STRUCTURE-DETAILs
for
that
ORGANISATION-STRUCTURE.
d.
e.
f.
9.8.3 Discussion
9.8.3.1 The model structure permits the unit task organisation (UTO) for a
particular division to be described, for example, UTO for the 19th (US) Mechanized
Division that has three brigades. The root organisation in ORGANISATIONSTRUCTURE would be 19Div and the detail would pick up three relationships that
indicate that 19Div commands Brigades A, B, and C. The structure also permits the
inclusion of other relationships, such as associated facilities, if they are relevant to the
structural description of the organisation.
9.8.3.2 A parent organisation need not exist or be created before organisation
structure can be specified. For example, a notional Multinational Division (North) or
MND(N) for short is created and becomes the root organisation. Subsequently, the units
that are subordinated to MND(N) would be specified in the same way as in case of 19Div
292
V3.1.4
and, in addition, another relationship would have to be specified that would indicate which
unit is playing the role of divisional assets of MND(N).
9.8.3.3 The relationship to ACTION-TASK permits any instance of
ORGANISATION-STRUCTURE to be associated with any instance of ACTION-TASK.
In this way, a new mission that entails the formation of a joint task force could have the
joint task force description associated with it.
9.8.3.4 The Recommended structure for nations to use to represent ORBAT and
Taskorg is the ORGANISATION-STRUCTURE and ORGANISATION-STRUCTUREDETAIL (for a single unit no need for ORGANISATION-STRUCTURE-DETAIL). In
order to differentiate between a TaskOrg and an ORBAT, organisation-structurecategory-code shall be used in ORGANISATION-STRUCTURE.
9.8.4 An Example of ORGANISATION-STRUCTURE
9.8.4.1 A new joint task force named JTF PURPLE is being formed. Its main
component is the 2nd Infantry Brigade that has three battalions under its command. The
joint task force is supported by a tactical fighter squadron, a Marine rifle company, and a
field medical treatment facility. The objects of interest are defined in the table below. Data
that would appear in subtypes is omitted.
9.8.4.2 The associations of interest are listed in Sub-table (b). In this example, all
records are used because only data that are relevant to the example are listed. In an actual
operational application this table could contain hundreds or thousands of entries from
which only these would be used in defining organisational structure.
Table 113. Data for ORGANISATION-STRUCTURE Example
(a) OBJECT-ITEM
object-item-id
101
ORGANISATION
Joint Task Force PURPLE
202
303
304
305
406
507
608
709
810
ORGANISATION
ORGANISATION
ORGANISATION
ORGANISATION
ORGANISATION
FACILITY
FEATURE
ORGANISATION
PERSON
2nd Infantry Brigade
11th Infantry Battalion
12th Infantry Battalion
14th Armoured Battalion
405th Tactical Fighter Squadron
319th Medical Treatment Facility
Eastern Afghanistan Area of responsibility
7th US Marine Rifle Company
Brigadier General Motors
(b) OBJECT-ITEM-ALIAS
object-itemid
object-itemalias-index
object-item-aliascategory-code
object-item-alias-name-text
810
1
Alternate name
Diesel
293
V3.1.4
(c) OBJECT-ITEM-ASSOCIATION
*-subjectobject-item-id
*index
101
202
1
Command and control
Has operational control of
202
202
202
101
202
303
304
305
406
507
1
1
1
1
1
Command and control
Command and control
Command and control
Command and control
Controls
Has full command of
Has full command of
Has full command of
—
101
101
101
608
709
810
1
1
1
Is constrained or enabled by
Command and control
Is under command of
—
—
*-category-code
*-subcategory-code
(d) ORGANISATION-STRUCTURE
organisation-structure-rootorganisation-id
organisationstructure-index
reportingdata-id
101
1
17854
(e) ORGANISATION-STRUCTURE-DETAIL
**-rootorganisation-id
**index
**-detailindex
***-subjectobject-item-id
***-objectobject-item-id
***-index
101
101
101
101
101
1
1
1
1
1
1
2
3
4
5
101
202
202
202
101
202
303
304
305
406
1
1
1
1
1
101
101
101
101
1
1
1
1
6
7
8
9
202
101
101
101
507
608
709
810
1
1
1
1
Note: ** = "organisation-structure"
9.8.4.3 Only a single record appears in Sub-table (d) because only one
configuration is being described. The root organisation may have several different
ORBATs assigned to it to represent the current structure and planned structures. It may
have different structures prescribed for different contingencies envisioned in concept
plans.
9.8.4.4 The final Sub-table (e) identifies every association that applies to the
specification of structure for JTF PURPLE.
9.8.5 Business Rule for Representing Order of Battle (ORBAT) and Task
Organisation (Taskorg)
A suggested usage rule is specified in Annex G1, Section G1.6.2.
294
V3.1.4
10. CAPABILITIES OF OBJECTS AND TYPES
10.1
Introduction
10.1.1 Requirements
10.1.1.1 There is a need to specify and monitor the capability of objects.
Information concerning capabilities can be used within the planning process to analyse the
feasibility of actions that may be open to friendly forces and to examine the likelihood of
actions that may be open to opposing forces.
10.1.1.2 There is a need to describe the way in which the capability of objects
can be affected by various kinds of conditions. For example, the speed with which a
vehicle can manoeuvre over land may depend on the type of terrain, and the range of a
weapon may depend on the type of ammunition that is used.
10.1.2 Overview
10.1.2.1 The design of a capability structure embodies two concepts: the need to
characterise capability itself and to link it to other parts of the model that use
specifications of capability. The content of this section introduces the concept of capability
as an entity, shows how it is related to other objects and activities, and then describes the
details of the capability specification itself.
10.1.2.2 CAPABILITY is defined as "The potential ability to do work, perform
a function or mission, achieve an objective, or provide a service." The entity and its
subtypes represents generic capabilities that can be ascribed to objects and their types. The
specifications characterise a diverse range of abilities, such as maximum speed or
maximum storage capacity, through the attributes capability-category-code at the top level
and category and descriptor attributes in the subtypes of CAPABILITY. The categorycode refers to a general class of abilities (e.g., the ability to transport things) while the
subtype attributes provide the detail by referring to a single ability within that class (e.g.,
the ability to transport a given amount of liquid). A specific capability can be formulated
by creating an instance of CAPABILITY that has the appropriate category and descriptor
codes.
10.1.2.3 The structure that links CAPABILITY to three client entities is
illustrated in the figure below. First, it is linked to OBJECT-TYPE via OBJECT-TYPECAPABILITY-NORM to describe the normal or expected capabilities for a specified class
of objects. Second, it is linked to OBJECT-ITEM via OBJECT-ITEM-CAPABILITY to
provide estimates of the actual capability of a specific object at a given time. Third, it is
linked to ACTION through ACTION-REQUIRED-CAPABILITY to specify the
capability required in order to perform a desired action. Each of the associative entities
provides an attribute with which to specify a numerical value for that particular capability.
295
V3.1.4
CAPABILITY
is-quantified-in /
quantifies
ACTION
is-quantified-in /
quantifies
is-specified-with /
is-specified-for
OBJECT-ITEM
is-quantified-in /
quantifies
OBJECT-TYPE
Figure 90. CAPABILITY in Relation to ACTION, OBJECT-ITEM, and OBJECT-TYPE
10.1.2.4 Most specialisations of CAPABILITY require additional attributes that
are made available through subtyping. The subtyping is based on capability-category-code
where each subtype identifies a particular ability in more detail, that is, each subtype
describes the conditions affecting the CAPABILITY in question. For instance,
MOBILITY-CAPABILITY has a code to identify the type of terrain and FIRECAPABILITY identifies the type of ammunition that is discharged.
10.1.3 Rationale
10.1.3.1 There are several reasons underlying the choice for the CAPABILITY
structure:
a.
The structure explicitly and unambiguously identifies those abilities that are
available within the model—a fundamental requirement for information
exchange.
b.
The structure provides support for the classification of EQUIPMENT-TYPEs
at the application level to represent user views. If multiple capabilities
pertain to a single type of object, the user can create a classification
hierarchy based on the functional requirements, such as operations planning
or logistics support. For example, an EQUIPMENT-TYPE that has a
MOBILITY-CAPABILITY is a vehicle of some kind; an EQUIPMENTTYPE with a FIRE-CAPABILITY is a weapon of some kind. But it could be
the same instance of EQUIPMENT-TYPE such as a Leopard tank. As
another instance, a Chinook CH47D transport helicopter has both an air
manoeuvre capability and a transport capability.
10.1.3.2 It should be noted that CAPABILITY is intended to describe only
certain properties of an object rather than its inherent characteristics, such as the number
of wheels on a vehicle or the type of motor it has. The latter properties are modelled as
descriptive attributes of OBJECT-ITEM or OBJECT-TYPE and their subtypes.
296
V3.1.4
10.2
Structure for Specifying CAPABILITY
The basic structure comprises the entity CAPABILITY and one level of subtyping
along functional lines. The structure is illustrated in the figure below.
CAPABILITY
capability-id
capability-day-night-code
capability-unit-of-measure-code
engineering-capability-id (FK)
engineering-capability-category-code
engineering-capability-descriptor-code
engineering-capability-facility-height-dimension
engineering-capability-facility-length-dimension
engineering-capability-facility-width-dimension
FIRE-CAPABILITY
fire-capability-id (FK)
fire-capability-category-code
fire-capability-descriptor-code
fire-capability-weapon-type-code
ammunition-type-id (FK)
HANDLING-CAPABILITY
handling-capability-id (FK)
handling-capability-cargo-category-code
handling-capability-descriptor-code
handling-capability-action-code
maintenance-capability-id (FK)
maintenance-capability-category-code
maintenance-capability-station-count
maintenance-capability-level-code
MOBILITY-CAPABILITY
mobility-capability-id (FK)
mobility-capability-category-code
mobility-capability-descriptor-code
mobility-capability-terrain-type-code
SUPPORT-CAPABILITY
operational-capability-id (FK)
operational-capability-category-code
operational-capability-level-code
operational-capability-qualifier-code
STORAGE-CAPABILITY
support-capability-id (FK)
storage-capability-id (FK)
support-capability-category-code
support-capability-descriptor-code
storage-capability-cargo-category-code
storage-capability-descriptor-code
storage-capability-condition-code
object-type-id (FK)
surveillance-capability-id (FK)
surveillance-capability-category-code
surveillance-capability-descriptor-code
transmission-capability-id (FK)
transmission-capability-category-code
transmission-capability-descriptor-code
electronic-equipment-type-id (FK)
Note: Entities that contribute foreign keys to CAPABILITY subtypes are not shown.
Figure 91. Specification of CAPABILITY and Its Subtypes
297
V3.1.4
10.2.1 Specification of Entity CAPABILITY
10.2.1.1 The entity CAPABILITY is defined as "The potential ability to do
work, perform a function or mission, achieve an objective, or provide a service." The
attributes are:
a.
capability-id—The unique value, or set of characters, assigned to represent a
specific CAPABILITY and to distinguish it from all other CAPABILITYs.
b.
capability-category-code—The specific value that represents the general
class of a CAPABILITY. It serves as a discriminator that partitions
CAPABILITY into subtypes. The domain values are: ENGINEERINGCAPABILITY;
FIRE-CAPABILITY;
HANDLING-CAPABILITY;
MAINTENANCE-CAPABILITY;
MOBILITY-CAPABILITY;
OPERATIONAL-CAPABILITY; STORAGE-CAPABILITY; SUPPORTCAPABILITY; SURVEILLANCE-CAPABILITY; TRANSMISSIONCAPABILITY.
c.
capability-day-night-code—The specific value that defines the light
conditions that apply to a particular CAPABILITY. The domain values are:
Day; Day and night; Night.
d.
capability-unit-of-measure-code—The specific value that represents the
quantities in terms of which the magnitude of a specific CAPABILITY
descriptor is stated. Example domain values are: Cubic metre; Cubic metre(s)
per hour; Degree; Each; Hour; Kilogram; Kilogram(s) per hour; Kilometre;
Kilometre(s) per hour; Litre; Metre; Metric ton; Round(s) per minute;
Second; Square metre; Square metre(s) per hour.
10.2.1.2 The allowable choices of items or types that may be associated with a
particular value of capability-category-code are specified in Annex G2, Section G2.8.1.
10.2.2 ENGINEERING-CAPABILITY
10.2.2.1 ENGINEERING-CAPABILITY is defined as "A CAPABILITY,
required for planning, of those ORGANISATIONs and PERSONs or ORGANISATIONTYPEs and PERSON-TYPEs that are deemed as having the ability to perform
construction or destruction activities." This includes performing mobility and countermobility tasks. This category of CAPABILITY applies to ORGANISATIONs,
ORGANISATION-TYPEs, PERSONs, or PERSON-TYPEs.
10.2.2.2 The entity ENGINEERING-CAPABILITY provides additional
information concerning the conditions for which the engineering capability is defined, that
is, the type of facility which is being constructed or destroyed (or in the case of obstacles,
breached) as well as the dimensions of that facility. The attributes are:
a.
engineering-capability-id—The capability-id of a specific ENGINEERINGCAPABILITY (a role name for capability-id).
b.
engineering-capability-category-code—The specific value that represents the
class of ENGINEERING-CAPABILITY. The domain values are: Breaching;
Construction; Demolition.
298
V3.1.4
c.
engineering-capability-descriptor-code—The specific value that represents a
specific ENGINEERING-CAPABILITY in terms of a measurable quantity.
The domain values are: Rate; Time.
d.
engineering-capability-facility-height-dimension—The
one-dimensional
linear distance representing the vertical distance, measured from the lowest
to the highest reference, of either the FACILITY-TYPE itself (in the case of
construction) or the breach in the FACILITY-TYPE (in the case of
destruction).
e.
engineering-capability-facility-length-dimension—The
one-dimensional
linear distance representing the horizontal distance, measured from end to
end and parallel to the central axis, of either the FACILITY-TYPE itself (in
the case of construction) or the breach in the FACILITY-TYPE (in the case
of destruction).
f.
engineering-capability-facility-width-dimension—The
one-dimensional
linear distance representing the horizontal distance, measured from side to
side and perpendicular to the central axis, of either the FACILITY-TYPE
itself (in the case of construction) or the breach in the FACILITY-TYPE (in
the case of destruction).
g.
facility-type-id—The object-type-id of a specific FACILITY-TYPE (a role
name for object-type-id). It represents the specific instance of FACILITYTYPE that is the objective of the capability.
10.2.2.3 Examples specifying ENGINEERING-CAPABILITY are illustrated in
the table below. For instance, the first record cites a capability to build a one square
kilometre anti-tank minefield during the day. The unit of measure for the example is in
hours. This and other specification of capability can be applied to types or items with a
numeric value corresponding to the specified unit of measure.
Table 114. Example Instances of ENGINEERING-CAPABILITY
(a) CAPABILITY
capabilityid
capability-daynight-code
capability-unit-ofmeasure-code
567003
567004
567005
Day
Night
Day
Hour
Square metres/hr
Hour
(b) ENGINEERING-CAPABILITY
*-id
*-categorycode
*-descriptorcode
*-facilityheightdimension
*-facilitylengthdimension
*-facilitywidthdimension
567003
Construction
Time
—
300 [m]
1000 [m]
567004
Breaching
Rate
—
—
—
567005
Demolition
Time
10 [m]
10 [m]
20 [m]
facilitytype-id
[Minefield,
anti-tank]
[Minefield,
anti-tank]
[Building]
Note: * = "engineering-capability"
10.2.2.4 Engineering capabilities can be described for different echelon levels.
For instance, a bridge-building platoon may be capable of either constructing two bridges,
each 20 metres long, or a single bridge that is 40 metres long. A company that is made up
299
V3.1.4
of three platoons may therefore be capable of building a single bridge that is 120 metres
long. The first capability can be described at platoon level, the second at company level.
10.2.3 FIRE-CAPABILITY
10.2.3.1 The entity FIRE-CAPABILITY is defined as "A CAPABILITY,
required for planning, of those FACILITYs, MATERIELs, ORGANISATIONs and
PERSONs, or FACILITY-TYPEs, EQUIPMENT-TYPEs, ORGANISATION-TYPEs and
PERSON-TYPEs that are deemed as having the ability to discharge or launch a projectile
or missile." The FIRE-CAPABILITY entity provides additional information about the
type of projectile which is being discharged or launched. The attributes are:
a.
fire-capability-id—The capability-id of a specific FIRE-CAPABILITY (a
role name for capability-id).
b.
fire-capability-category-code—The specific value that represents the class of
FIRE-CAPABILITY. Example domain values are: Air to air; Ground to sea;
Sea to air.
c.
fire-capability-descriptor-code—The specific value that represents the FIRECAPABILITY that is being quantified. Example domain values are: Burst
fire rate; Maximum range; Safety distance factor.
d.
fire-capability-weapon-type-code—The specific value that represents the
general type of weapon that an EQUIPMENT-TYPE is qualified to employ.
The domain values are: Conventional; Nuclear, Dual capable; Non combat
capable; Not known.
e.
ammunition-type-id—The consumable-materiel-type-id of a specific
AMMUNITION-TYPE (a role name for object-type-id). It represents the
specific instance of AMMUNITION-TYPE that denotes the type of
projectile that can be fired.
10.2.3.2
The table below illustrates two FIRE-CAPABILITY specifications.
Table 115. Examples of FIRE-CAPABILITY
(a) CAPABILITY
capability
-id
capabilitycategory-code
100369
100370
FIRE-CAPABILITY
FIRE-CAPABILITY
—
—
Kilometre
Round(s) per minute
(b) FIRE-CAPABILITY
*-id
100369
100370
*-categorycode
Ground to air
Ground to
ground
*-descriptor-code
*-weapontype-code
Maximum range
Maximum fire rate
Conventional
Conventional
ammunition-type-id
[Gun shell, 105 MM]
[Small-arms ammunition,
7.62 X 17]
Note: * = "fire-capability"
10.2.4 HANDLING-CAPABILITY
10.2.4.1 The entity HANDLING-CAPABILITY is defined as "A
CAPABILITY, required for planning, of those FACILITYs and MATERIELs, or
300
V3.1.4
FACILITY-TYPEs and EQUIPMENT-TYPEs that are deemed as having the ability to
move materiels (raw materials, scrap, semi-finished, and finished) to, through, and from
productive processes; in warehouses and storage; and in receiving and shipping areas."
The attributes are:
a.
handling-capability-id—The capability-id of a specific HANDLINGCAPABILITY (a role name for capability-id).
b.
handling-capability-cargo-category-code—The specific value that represents
the class of cargo subject to the HANDLING-CAPABILITY. Example
domain values are: Arms, ammunition and explosives; Bulk cargo; Coal;
Liquid cargo; Prisoners of war. The domain value set for this attribute is
shared with one or more other attributes and is defined in the set cargocategory-code.
c.
handling-capability-descriptor-code—The specific value that represents the
HANDLING-CAPABILITY that is being quantified. Example domain
values are: Bulk liquid; Maximum cargo height; Maximum count.
d.
handling-capability-action-code—The specific value that represents the type
of a specific HANDLING-CAPABILITY. The domain values are: Hoist;
Load; Load or unload; Unload.
10.2.4.2
specifications.
The
table
below
illustrates
two
HANDLING-CAPABILITY
Table 116. Examples of HANDLING-CAPABILITY
(a) CAPABILITY
capability
-id
122334
122335
HANDLING-CAPABILITY
HANDLING-CAPABILITY
—
—
Item(s) per day
Litre(s) per hour
(b) HANDLING-CAPABILITY
*-id
*-category-code
*-descriptor-code
*-condition-code
122334
122335
Mail
Liquid cargo
Maximum count
Bulk liquid
Load or unload
Load
Note: * = "handling-capability"
10.2.5 MAINTENANCE-CAPABILITY
10.2.5.1 The entity MAINTENANCE-CAPABILITY is defined as "A
CAPABILITY, required for planning, of those FACILITYs, MATERIELs,
ORGANISATIONs and PERSONs or FACILITY-TYPEs, EQUIPMENT-TYPEs,
ORGANISATION-TYPEs, and PERSON-TYPEs that are deemed as having the ability to
provide a range of activities required to restore or maintain operational usage." The
attributes are:
a.
maintenance-capability-id—The
capability-id
of
a
MAINTENANCE-CAPABILITY (a role name for capability-id).
301
specific
V3.1.4
b.
maintenance-capability-category-code—The specific value that represents
the class of MAINTENANCE-CAPABILITY. Example domain values are:
Cable; Electrical: Navigational equipment; Paint shop; Shotblast.
c.
maintenance-capability-station-count—The integer value representing the
number of operational maintenance stations, fully outfitted with the
necessary equipment and maintenance personnel, available for the purpose of
repairing and servicing materiel.
d.
maintenance-capability-level-code—The specific value that represents the
extent of repairs or servicing that can be accomplished. The domain values
are: Emergency only; Limited; Major; Moderate.
10.2.5.2
specifications.
The table below illustrates two MAINTENANCE-CAPABILITY
Table 117. Examples of MAINTENANCE-CAPABILITY
(a) CAPABILITY
capability
-id
100388
100389
—
—
Each
Each
(b) MAINTENANCE-CAPABILITY
*-id
*-category-code
*-station-count
*-level-code
100388
100389
Electrical
Paint shop
5
2
Major
Limited
Note: * = "maintenance-capability"
10.2.6 MOBILITY-CAPABILITY
10.2.6.1 MOBILITY-CAPABILITY is defined as "A CAPABILITY, required
for planning, of those FACILITYs, MATERIELs, ORGANISATIONs and PERSONs or
FACILITY-TYPEs, EQUIPMENT-TYPEs, ORGANISATION-TYPEs, and PERSONTYPEs that are deemed as having the nominal ability to move in space, air, on water,
under water, or over a specific type of terrain."
10.2.6.2 The MOBILITY-CAPABILITY entity specifies additional information
about the kind of mobility and, in certain cases the conditions for which the manoeuvre
capability is defined, in particular, the type of terrain that is being traversed. The attributes
are:
a.
mobility-capability-id—The capability-id of
CAPABILITY (a role name for capability-id).
b.
mobility-capability-category-code—The specific value that represents the
class of MOBILITY-CAPABILITY. Example domain values are: Air, fixed
wing; Air, rotary wing; Amphibious; Dismounted; Land, tracked; Land,
wheeled; Sea, subsurface; Sea, surface.
c.
mobility-capability-descriptor-code—The specific value that represents the
MOBILITY-CAPABILITY that is being quantified. Example domain values
302
a specific MOBILITY-
V3.1.4
are: Maximum altitude; Military load classification - one-way tracked;
Minimum depth; Planning speed.
d.
mobility-capability-terrain-type-code—The specific value that represents the
class of terrain to which a particular MOBILITY-CAPABILITY pertains.
The domain values are: Cross-country; Road; Snow; Terrain independent;
Not known; Not otherwise specified.
10.2.6.3 Examples of MOBILITY-CAPABILITY are depicted in the table
below. The table sets up the capability descriptions with actual values carried in the
associative entities that link capability statement to a specific OBJECT-ITEM or
OBJECT-TYPE (or as required for an ACTION). The user can specify appropriate
maximum speeds for cross-country and road day manoeuvres during an exercise or
deployment by referring to different instances of CAPABILITY, namely 100348 and
100349.
Table 118. Examples of MOBILITY-CAPABILITY
(a) CAPABILITY
capabilityid
capability-categorycode
100348
100349
124773
124774
MOBILITY-CAPABILITY
MOBILITY-CAPABILITY
MOBILITY-CAPABILITY
MOBILITY-CAPABILITY
Day
Day
Day and night
Day and night
Kilometre(s) per hour
Metre
(b) MOBILITY-CAPABILITY
*-id
*-category-code
*-descriptor-code
*-terrain-type-code
100348
100349
Land, tracked
Land, wheeled
Maximum speed
Maximum speed
Cross-country
Road
124773
124774
Sea, surface
Air, fixed wing
Planning speed
Minimum take off
distance
—
—
Note: * = "mobility-capability"
10.2.7 OPERATIONAL-CAPABILITY
10.2.7.1 The entity OPERATIONAL-CAPABILITY is defined as "A
CAPABILITY, required for planning, of those objects and types of objects that are
deemed as having the ability, the training and the equipment to perform an operation."
This entity permits operational roles to be assigned to units or unit types in addition to the
roles that are inherent in the typing of units. The attributes are:
a.
operational-capability-id—The capability-id of a specific OPERATIONALCAPABILITY (a role name for capability-id).
b.
operational-capability-category-code—The specific value that identifies a
particular OPERATIONAL-CAPABILITY. Example domain values are: Air
assault; Airborne; Civilian law enforcement; Engineer, combat; Joint
intelligence; Medical evacuation; NBC, decontamination; Peace support;
Search and rescue; Signal, support; Supply (class III); Target acquisition;
Water purification.
303
V3.1.4
c.
operational-capability-level-code—The specific value that represents the
force level at which the specific OPERATIONAL-CAPABILITY is intended
to be performed. The domain values are: Corps; Division; Force;
Operational; Strategic; Tactical; Theatre.
d.
operational-capability-qualifier-code—The specific value that represents the
degree to which the specific OPERATIONAL-CAPABILITY can be
fulfilled. The domain values are: High; Low; Medium.
10.2.7.2 The table below illustrates three OPERATIONAL-CAPABILITY
specifications. The general intent of these specifications is to indicate supplemental
operational capabilities that a specified item, such as a unit, may have beyond those
inherent in its typing.
Table 119. Examples of OPERATIONAL-CAPABILITY
(a) CAPABILITY
—
—
—
Each
Each
Each
capability-id
534222
534223
534224
(b) OPERATIONAL-CAPABILITY
*-id
*-category-code
*-level-code
*-qualifier-code
534222
534223
534224
Artillery survey
Attack
Counter intelligence
Tactical
Tactical
Strategic
High
Medium
Low
Note: * = "operational-capability"
10.2.8 STORAGE-CAPABILITY
10.2.8.1 The entity STORAGE-CAPABILITY is defined as "A CAPABILITY,
required for planning, of those FACILITYs and MATERIELs or EQUIPMENT-TYPEs
and FACILITY-TYPEs that are deemed as having the ability to hold a specific OBJECTTYPE." The attributes are:
a.
storage-capability-id—The capability-id of
b.
storage-capability-cargo-category-code—The specific value that represents
the class of cargo subject to the STORAGE-CAPABILITY. Example domain
values are: Arms, ammunition and explosives; Bulk cargo; Coal; Liquid
cargo; Prisoners of war. The domain value set for this attribute is shared with
one or more other attributes and is defined in the set cargo-category-code.
c.
storage-capability-descriptor-code—The specific value that represents the
STORAGE-CAPABILITY that is being quantified. Example domain values
are: Maximum cargo height; Maximum count; Maximum weight bearing;
NEQ limit.
d.
storage-capability-condition-code—The specific value that represents the
type of storage condition. The domain values are: Climate controlled;
Covered; Hardened; Open.
304
a
specific
STORAGE-
V3.1.4
e.
a specific OBJECT-TYPE and to distinguish it from all other OBJECTTYPEs. It identifies the specific instance of MATERIEL-TYPE that is the
objective of the capability.
10.2.8.2
specifications.
The
table
below
illustrates
two
STORAGE-CAPABILITY
Table 120. Examples of STORAGE-CAPABILITY
(a) CAPABILITY
capabilityid
capability-categorycode
capability-unitof-measure-code
333989
333990
STORAGE-CAPABILITY
STORAGE-CAPABILITY
—
—
Litre
Cubic metre
(b) STORAGE-CAPABILITY
*-id
*-cargo-category-code
Petroleum, oils and
lubricants
Coal
333989
333990
*-descriptor-code
*-condition-code
object-type-id
Bulk liquid
Climate controlled
[Petroleum]
Bulk volume
Open
[Coal]
Note: * = "storage-capability"
10.2.9 SUPPORT-CAPABILITY
10.2.9.1 SUPPORT-CAPABILITY is defined as "A CAPABILITY, required for
planning, of those FACILITYs, MATERIELs and ORGANISATIONs or FACILITYTYPEs, EQUIPMENT-TYPEs and ORGANISATION-TYPEs that are deemed as having
the ability to provide supplies or services." The attributes are:
a.
support-capability-id—The capability-id of
b.
support-capability-category-code—The specific value that represents the
class of SUPPORT-CAPABILITY. Example domain values are: Bedding;
Food/rations; Medical supplies; Sewage; Supply (class III).
c.
support-capability-descriptor-code—The specific value that represents the
SUPPORT-CAPABILITY that is being quantified. The domain values are:
Bed count; Bulk liquid; Bulk volume; Maximum count; Operating table
count.
10.2.9.2
specifications.
The
table
below
illustrates
a
two
specific
SUPPORT-
SUPPORT-CAPABILITY
Table 121. Examples of SUPPORT-CAPABILITY
(a) CAPABILITY
capabilityid
557201
557202
SUPPORT-CAPABILITY
SUPPORT-CAPABILITY
—
—
Each
Litre(s) per minute
305
V3.1.4
(b) SUPPORT-CAPABILITY
*-id
*-category-code
*-descriptor-code
557201
557202
Bedding
Sewage
Bed count
Bulk liquid
Note: * = "support-capability"
10.2.10 SURVEILLANCE-CAPABILITY
10.2.10.1 SURVEILLANCE-CAPABILITY is defined as "A CAPABILITY,
required for planning, of those FACILITYs, MATERIELs, ORGANISATIONs and
PERSONs or FACILITY-TYPEs, EQUIPMENT-TYPEs, ORGANISATION-TYPEs and
PERSON-TYPEs that are deemed as having the nominal ability to observe aerospace,
surface or subsurface areas, places, persons, or things, by visual, aural, electronic,
photographic or other means." The attributes are:
a.
surveillance-capability-id—The
capability-id
of
a
SURVEILLANCE-CAPABILITY (a role name for capability-id).
specific
b.
surveillance-capability-category-code—The specific value that represents the
class of SURVEILLANCE-CAPABILITY. The domain values are:
Communications; Electronic; Human; Imaging; Signal; Not known; Not
c.
surveillance-capability-descriptor-code—The specific value that represents
the SURVEILLANCE-CAPABILITY that is being quantified. The domain
values are: Maximum range; Minimum range.
10.2.10.2 The table below illustrates three SURVEILLANCE-CAPABILITY
specifications.
Table 122. Examples of SURVEILLANCE-CAPABILITY
(a) CAPABILITY
capabilityid
467231
467232
Day
Night
Kilometre
Kilometre
467233
—
Kilometre
(b) SURVEILLANCE-CAPABILITY
*-id
*-category-code
*-descriptor-code
467231
467232
467233
Imaging
Electronic
Communication
Maximum range
Maximum range
Minimum range
Note: * = "surveillance-capability"
10.2.11 TRANSMISSION-CAPABILITY
10.2.11.1 The entity TRANSMISSION-CAPABILITY is defined as "A
CAPABILITY, required for planning, of those MATERIELs or MATERIEL-TYPEs that
are deemed as having the ability to generate, receive or affect signals in the
electromagnetic spectrum." The attributes are:
306
V3.1.4
a.
transmission-capability-id—The
capability-id
of
a
TRANSMISSION-CAPABILITY (a role name for capability-id).
specific
b.
transmission-capability-category-code—The specific value that represents
the class of TRANSMISSION-CAPABILITY. The domain values are:
Receive; Transceive; Transmit.
c.
transmission-capability-descriptor-code—The specific value that represents
the TRANSMISSION-CAPABILITY that is being quantified. The domain
values are: Maximum frequency; Maximum pulse repetition frequency;
Minimum frequency; Minimum pulse repetition frequency; Power.
d.
electronic-equipment-type-id—The equipment-type-id of a specific
ELECTRONIC-EQUIPMENT-TYPE (a role name for object-type-id).
10.2.11.2 The table below illustrates two TRANSMISSION-CAPABILITY
specifications.
Table 123. Examples of TRANSMISSION-CAPABILITY
(a) CAPABILITY
capability
-id
144433
144434
—
—
Megahertz
Kilohertz
(b) TRANSMISSION-CAPABILITY
*-id
*-category-code
*-descriptor-code
electronic-equipment-type-id
144433
Transceive
[High frequency direction finder]
144434
Receive
Maximum
frequency
Minimum pulse
repetition frequency
[GPS receiver, military]
Note: * = "transmission-capability"
10.3
Assigning CAPABILITY to Client Entities
The details of linking capability specifications to the three client entities are
presented in this section. The users are ACTION, OBJECT-ITEM, and OBJECT-TYPE.
The structural details are illustrated in the figure below.
307
V3.1.4
CAPABILITY
capability-id
ACTION
action-id
action-name-text
is-quantified-in /
quantifies
action-id (FK)
capability-id (FK)
action-required-capability-quantity
OBJECT-ITEM
object-item-id
is-quantified-in /
quantifies
object-item-id (FK)
capability-id (FK)
object-item-capability-index
is-specified-w ith /
is-specified-for
object-item-capability-mission-primacy-code
object-item-capability-quantity
OBJECT-TYPE
object-type-id
is-quantified-in /
quantifies
object-type-id (FK)
capability-id (FK)
object-type-capability-norm-mission-primacy-code
object-type-capability-norm-quantity
Figure 92. Specification of CAPABILITY Links to ACTION and Objects
10.3.1 OBJECT-TYPE-CAPABILITY-NORM
10.3.1.1 The entity OBJECT-TYPE-CAPABILITY-NORM is defined as "The
standard value of a specific CAPABILITY of an OBJECT-TYPE." The entity represents
staff planning data concerning the capabilities of OBJECT-TYPEs.
10.3.1.2 OBJECT-TYPE-CAPABILITY-NORM links OBJECT-TYPE to
CAPABILITY are shown in the figure below. An OBJECT-TYPE may be associated with
any number of standard capabilities. Since OBJECT-TYPE-CAPABILITY-NORM refers
to types rather than items, the capabilities it defines tend to be static. The attributes are:
a.
a specific OBJECT-TYPE and to distinguish it from all other OBJECTTYPEs. It identifies a specific OBJECT-TYPE for which a particular
OBJECT-TYPE-CAPABILITY-NORM is specified.
b.
308
V3.1.4
c.
object-type-capability-norm-mission-primacy-code—The specific value that
represents the priority of the role that a specific capability, restricted to be an
OPERATIONAL-CAPABILITY, has for the specific OBJECT-TYPE. The
domain values are: Primary; Secondary; Tertiary. The domain value set for
this attribute is shared with one or more other attributes and is defined in the
set mission-primacy-code.
d.
object-type-capability-norm-quantity—The numeric value that represents the
aggregated units of a specific CAPABILITY that is specified in a particular
OBJECT-TYPE-CAPABILITY-NORM to be attainable for a specific
OBJECT-TYPE. The unit of measure is defined in the CAPABILITY
specification.
10.3.1.3 An example of how the specification is utilised is detailed in the table
below. It shows some OBJECT-TYPE-CAPABILITY-NORMs for a number of different
OBJECT-TYPEs relating to the CAPABILITYs specified in Section 10.2 and repeated
here for ease of reference. The following statements are conveyed by the table:
a.
A Turkish engineer company can build a facility (specified in a subtype not
shown here) in 3 hours during the day.
b.
ABBOT 105-mm self-propelled (SP) gun42 normally has a fire range of 10
km. The applicable ammunition could be specified via FIRE-CAPABILITY.
c.
A certain type of water supply facility can load 2000 litres per hour.
d.
A maintenance facility has 5 stations for Electrical work.
e.
A Turkish field artillery battalion has a tertiary mission (where the character
of the mission is described in a subtype not shown here).
f.
Combat Engineer Tractor (CET)43 is normally able to achieve a maximum
cross-country velocity of 57 kilometres per hour (the terrain type is specified
in Table 118).
g.
A type of facility has the ability to store coal.
h.
A national civil health program can provide 100 units of bedding for
humanitarian aid.
i.
A UAV is to conduct electronic surveillance in Afghanistan.
j.
An electronic equipment type (high density direction finder) has to transmit
and receive data at a certain level of performance.
The ABBOT 105-mm SP is a self-propelled armoured 105-mm Artillery Gun currently in use
in several NATO armies.
43
CET—Combat Engineer Tractor (a UK-manufactured vehicle in service).
42
309
V3.1.4
Table 124. OBJECT-TYPE-CAPABILITY-NORM Example
(a) CAPABILITY
capability-id
reference
sub-tables
567003
100369
122335
100388
100348
534222
333990
557201
467232
144433
FIRE-CAPABILITY
HANDLING-CAPABILITY
MOBILITY-CAPABILITY
STORAGE-CAPABILITY
SUPPORT-CAPABILITY
Day
Hour
(b) - (l)
—
—
—
Day
—
—
—
Night
—
Kilometre
Litre(s) per hour
Each
Each
Cubic metre
Each
Kilometre
Megahertz
(c) - (l)
(d) - (l)
(e) - (l)
(g) - (l)
(f) - (l)
(h) - (l)
(i) - (l)
(j) - (l)
(k) - (l)
(b) ENGINEERING-CAPABILITY
*-id
*-categorycode
*descriptorcode
567003
Construction
Time
—
300 [m]
1000 [m]
facilitytype-id
[Minefield,
anti-tank]
(c) FIRE-CAPABILITY
**-id
**-category-code
**-descriptor-code
ammunition-type-id
100369
Ground to air
Maximum range
[Gun shell, 105 MM]
Note: ** = "fire-capability"
(d) HANDLING-CAPABILITY
***-id
***-category-code
***-descriptor-code
***-condition-code
122335
Liquid cargo
Bulk liquid
Load
Note: *** = "handling-capability"
(e) MAINTENANCE-CAPABILITY
****-id
****-category-code
****-station-count
****-level-code
100388
Electrical
5
Major
Note: **** = "maintenance-capability"
(f) MOBILITY-CAPABILITY
*****-id
*****-category-code
*****-descriptor-code
*****-terrain-type-code
100348
Land, tracked
Maximum speed
Cross-country
Note: ***** = "mobility-capability"
(g) OPERATIONAL-CAPABILITY
*-id
*-category-code
*-level-code
*-qualifier-code
534222
Artillery survey
Tactical
High
(h) STORAGE-CAPABILITY
**-id
**-cargo-category-code
**-descriptor-code
**-condition-code
object-type-id
333990
Coal
Bulk volume
Open
[Coal]
Note: ** = "storage-capability”
310
V3.1.4
(i) SUPPORT-CAPABILITY
***-id
***-category-code
***-descriptor-code
Bedding
Bed count
557201
Note: *** = "support-capability"
(j) SURVEILLANCE-CAPABILITY
****-id
****-category-code
****-descriptor-code
467232
Electronic
Maximum range
Note: **** = "surveillance-capability"
(k) TRANSMISSION-CAPABILITY
*****-id
*****-category-code
144433
Transceive
Maximum frequency
Note: ***** = "transmission-capability"
(l) OBJECT-TYPE-CAPABILITY-NORM
object-type-id
capabilityid
object-type-capability-normmission-primacy-code
object-type-capabilitynorm-quantity
[TU Eng Coy]
[ABBOT 105-mm SP gun]
[Water supply facility]
[Maintenance Facility]
[Combat Engineer Tractor]
[TU Fld Art Bn]
[Coal storage facility]
[National civil, Health programs]
[UAV]
567003
100369
122335
100388
100348
534222
333990
557201
467232
144433
—
—
—
3
10
2000
5
57
—
300
100
1000
—
—
—
Tertiary
—
—
—
—
10.3.2 OBJECT-ITEM-CAPABILITY
10.3.2.1 The entity OBJECT-ITEM-CAPABILITY is defined as "A perceived
value of a specific CAPABILITY of an OBJECT-ITEM." OBJECT-ITEM-CAPABILITY
allows an ORGANISATION to make an estimate of the actual capability of an OBJECTITEM to carry out a specified action whose value may differ from its OBJECT-TYPECAPABILITY-NORM, that is, the standard capability of its type, or for which a norm is
not specified.
10.3.2.2 Since OBJECT-ITEM-CAPABILITY refers to items rather than types,
the capabilities it represents are likely to be more dynamic than norms. A new assessment
of the capability of an OBJECT-ITEM may be made by an ORGANISATION, and the
same ORGANISATION may reassess capabilities as they change or as the need for
reassessment arises. Each time this occurs a new instance of OBJECT-ITEMCAPABILITY must be created. The attributes are:
a.
a specific OBJECT-ITEM and to distinguish it from all other OBJECTITEMs. It identifies a specific OBJECT-ITEM that is the object of an
OBJECT-ITEM-CAPABILITY.
b.
specific CAPABILITY and to distinguish it from all other CAPABILITYs. It
311
V3.1.4
identifies the specific CAPABILITY that is the subject of an OBJECTITEM-CAPABILITY.
c.
object-item-capability-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-CAPABILITY for a specific
OBJECT-ITEM and a specific CAPABILITY and to distinguish it from all
other OBJECT-ITEM-CAPABILITYs for that OBJECT-ITEM and that
CAPABILITY.
d.
object-item-capability-mission-primacy-code—The specific value that
represents the priority of the role that a specific capability, restricted to be an
OPERATIONAL-CAPABILITY, has for the specific OBJECT-ITEM. The
domain values are: Primary; Secondary; Tertiary. The domain value set for
set mission-primacy-code.
e.
object-item-capability-quantity—The numeric value that represents the
aggregated units of a specific CAPABILITY that is estimated to be attainable
for a specific OBJECT-ITEM. The unit of measure is defined in the
CAPABILITY specification.
f.
REPORTING-DATAs.
10.3.2.3 An example of OBJECT-ITEM-CAPABILITY is provided in the table
below. The first two records show two OBJECT-ITEMs: an Engineer Company and a
Spanish 105 mm gun. The relevant instances of CAPABILITYs are shown in Sub-tables
(b) thru (l). Sub-table (m) shows that the Engineer Company has an ENGINEERINGCAPABILITY that has changed based on new information accompanied by a new
Reporting data. The Spanish 105 mm gun is shown with a FIRE-CAPABILITY. The third
instance of OBJECT-ITEM-CAPABILITY specifies that the Baghdad water supply
facility has the current ability to provide water at the rate of 1500 litres per hour. The
attribute reporting-data-id references the amplifying information, such as reporting
organisation and time for these estimates.
312
V3.1.4
Table 125. Examples of OBJECT-ITEM-CAPABILITY
(a) OBJECT-ITEM
object-item-id
12333444
[TU 1st Eng Coy 3rd Eng Bn]
34976383
[ABBOT 105 mm SP gun]
22500567
[Baghdad water supply facility]
69987377
[Turkish FA Bn]
65419747
[PL - X1 Combat Engineer Tractor]
ORGANISATION
MATERIEL
FACILITY
ORGANISATION
MATERIEL
34229777
[Bosporus bridge]
98763000
[BMP-1 Armoured personnel carrier]
32334901
[Camp Doha maintenance facility
45660871
[Baltimore coal storage facility]
22548976
[Walter Reed hospital]
67003421
[Predator]
98763008
[Thompson HFDF]
FACILITY
MATERIEL
FACILITY
FACILITY
FACILITY
MATERIEL
MATERIEL
(b) CAPABILITY
capability-id
reference
sub-tables
567003
100369
122335
100388
100348
100349
100350
534222
333990
557201
467232
144433
FIRE-CAPABILITY
HANDLING-CAPABILITY
MOBILITY-CAPABILITY
MOBILITY-CAPABILITY
MOBILITY-CAPABILITY
STORAGE-CAPABILITY
SUPPORT-CAPABILITY
Day
Hour
(b) - (l)
—
—
—
Day
—
—
—
—
—
Night
—
Kilometre
Litre(s) per hour
Each
Each
Each
Each
Cubic metre
Each
Kilometre
Megahertz
(c) - (l)
(d) - (l)
(e) - (l)
(g) - (l)
(g) - (l)
(g) - (l)
(f) - (l)
(h) - (l)
(i) - (l)
(j) - (l)
(k) - (l)
(c) ENGINEERING-CAPABILITY
*-id
*-categorycode
*descriptorcode
567003
Construction
Time
—
300 [m]
1000 [m]
(d) FIRE-CAPABILITY
**-id
**-category-code
**-descriptor-code
ammunition-type-id
100369
Ground to air
Maximum range
[Gun shell, 105 MM]
Note: ** = "fire-capability"
313
facilitytype-id
[Minefield,
anti-tank]
V3.1.4
(e) HANDLING-CAPABILITY
***-id
***-category-code
***-descriptor-code
***-condition-code
122335
Liquid cargo
Bulk liquid
Load
Note: *** = "handling-capability”
(f) MAINTENANCE-CAPABILITY
****-id
****-category-code
****-station-count
****-level-code
100388
Electrical
5
Major
Note: **** = "maintenance-capability"
(g) MOBILITY-CAPABILITY
*****-id
*****-category-code
*****-terrain-type-code
100348
100349
Land, tracked
Land, tracked
Cross-country
Road
100350
Land, tracked
Planning speed
Military load classification
- one-way tracked
Military load classification
- one-way tracked
Road
Note: ***** = "mobility-capability"
(h) OPERATIONAL-CAPABILITY
*-id
*-category-code
*-level-code
*-qualifier-code
534222
Artillery survey
Tactical
High
(i) STORAGE-CAPABILITY
**-id
**-cargo-category-code
**-descriptor-code
**-condition-code
object-type-id
333990
Coal
Bulk volume
Open
[Coal]
Note: ** = "storage-capability"
(j) SUPPORT-CAPABILITY
***-id
***-category-code
***-descriptor-code
557201
Bedding
Bed count
Note: *** = "support-capability"
(k) SURVEILLANCE-CAPABILITY
****-id
****-category-code
****-descriptor-code
467232
Electronic
Maximum range
Note: **** = "surveillance-capability"
(l) TRANSMISSION-CAPABILITY
*****-id
*****-category-code
144433
Transceive
Maximum frequency
Note: ***** = "transmission-capability"
314
V3.1.4
(m) OBJECT-ITEM-CAPABILITY
object-itemid
capability
-id
object-itemcapability-index
object-item-capabilitymission-primacy-code
object-itemcapability-quantity
reportingdata-id
12333444
567003
1
—
2
rd611
12333444
34976383
22500567
32334901
65419747
567003
100369
122335
100388
100348
2
1
1
1
1
—
—
—
—
—
rd697
rd652
rd225
rd100
rd891
69987377
34229777
98763000
45660871
22548976
534222
100349
100350
333990
557201
1
1
1
1
1
Tertiary
—
—
—
—
4
9
1500
3
40
—
22548976
67003421
98763008
557201
467232
144433
2
1
1
—
—
—
150
10
350
200
rd779
rd674
rd675
rd456
rd571
150
500
—
rd572
rd670
rd987
10.3.2.4 OBJECT-ITEM-CAPABILITY is intended to be used to specify
capabilities for an OBJECT-ITEM when those capabilities differ from the standard
capabilities defined through OBJECT-TYPE-CAPABILITY-NORM or no norm is
specified. Generally, OBJECT-ITEM-CAPABILITY should be used to supersede a
standard capability (or, for that matter, a previous estimate) that has been defined for a
given OBJECT-ITEM. If no instance of OBJECT-ITEM-CAPABILITY exists which
defines a particular CAPABILITY for a specific OBJECT-ITEM, it is to be assumed that
OBJECT-TYPE-CAPABILITY-NORM applies for that OBJECT-ITEM (if defined).
10.3.2.5 OBJECT-ITEM-CAPABILITY is not intended to be used for recording
every change in the capabilities of an OBJECT-ITEM. Changes in terrain, weather
conditions, and operational status can all affect the capabilities of an object. OBJECTITEM-CAPABILITY should only be used to record those changes in capabilities that the
operational user deems necessary for the planning process.
10.3.2.6 CAPABILITY structure can also handle the "Military Load
Classification" (MLC) concept. MLC is one of the capabilities that can be specified for
facilities and facility types such as a road or bridge and for materiel and materiel types
such as a vehicle. When this capability is used for a bridge for instance, it specifies the
bridge’s tactical bearing capability. But when it is used for a vehicle, it specifies the MLC
code for the vehicle and helps to estimate bridge’s bearing capability for that specific
vehicle or other different types of vehicles that have a military load classification
specified. An example of this concept is given in Table 125 above. In sub-table (a) there
are two records that show two OBJECT-ITEMs: Bosporus Bridge and BMP-1 Armoured
personnel carrier. The relevant instances of CAPABILITYs are shown in Sub-tables (b)
and (h). The bridge’s classification type is one-way tracked. Sub-table (m) shows that both
the Bosporus Bridge and BMP-1 Armoured personnel carrier have military-loadclassification specified. For Bosporus Bridge, the military-load-classification is 150 while
it is 10 for the BMP-1. Therefore the planner can deduce from this information that the
bridge can bear 15 BMP-1 armoured personnel carriers one-way at one time.
315
V3.1.4
10.4
ACTION-REQUIRED-CAPABILITY and its use are described in Chapter 16.
316
V3.1.4
11. ESTABLISHMENT STRUCTURE
11.1
Introduction
There is a need to be able to specify the composition of types of objects in terms of
other types. Thus, for example, a commander may require to specify that a certain unit
type is authorised to have certain numbers of facility or materiel types; to specify that a
type of unit is composed of certain numbers of other unit types; or to specify that a type of
unit is composed of certain numbers of person types. Logistics documentation may consist
of a bill of materials or a parts list for an equipment type. A parts list may catalogue
components of a rifle, all items of equipment expected to be present on a combat-ready
main battle tank, or enumerate all weaponry and equipment that is certified as a package
for safe carriage on a given model of an F-16 fighter. Generally, this is the type of
information that is contained in tables of organisation and equipment, bill of materials,
parts lists, and structure of a notional task force.44 All such authorisations can be
represented using the establishment specifications presented in this chapter.
11.2
Establishment for OBJECT-TYPE
11.2.1 The model implements the concept of establishment using two entities:
OBJECT-TYPE-ESTABLISHMENT and its child OBJECT-TYPE-ESTABLISHMENTOBJECT-TYPE-DETAIL. OBJECT-TYPE-ESTABLISHMENT is the parent entity that
provides
general
information
about
the
establishment.
OBJECT-TYPEESTABLISHMENT-OBJECT-TYPE-DETAIL identifies the instances and numbers of
OBJECT-TYPEs that are constituent parts of the establishment. The structure used for
specifying establishments is illustrated in the figure below. The details are provided in
paragraphs below. Specification for assigning an existing establishment to an instance of
OBJECT-ITEM is provided at the end of this chapter.
The concept of a bill of materials (BoM) is derived from the manufacturing industry where it is
defined as a document that includes manufacturer’s part numbers, quantity required, device
descriptions, value, type or size, and reference designators.
44
317
V3.1.4
OBJECT-TYPE
object-type-id
is-specified-as-part-of /
references
established-object-type-id (FK)
object-type-establishment-index
object-type-establishment-effective-datetime
object-type-establishment-category-code
object-type-establishment-environment-condition-code
object-type-establishment-name-text
object-type-establishment-operational-mode-code
is-specified-through /
is-a-component-of
identifies-establishment-for-detail-object-type-in /
references
object-type-establishment-index (FK)
object-type-establishment-object-type-detail-index
object-type-establishment-object-type-detail-major-part-indicator-code
object-type-establishment-object-type-detail-count
object-type-establishment-object-type-detail-object-type-id (FK)
object-type-establishment-detail-object-type-establishment-index (FK)
Figure 93. Establishment Structure
11.2.2 OBJECT-TYPE-ESTABLISHMENT is defined as "The authorisation or
other form of specification that associates with the established OBJECT-TYPE numbers of
specific OBJECT-TYPEs under specified conditions." The attributes are:
a.
established-object-type-id—The object-type-id of a specific OBJECT-TYPE
that is authorised in a specific OBJECT-TYPE-ESTABLISHMENT and
whose establishment details are specified in OBJECT-TYPEESTABLISHMENT-OBJECT-TYPE-DETAIL (a role name for object-typeid).
b.
object-type-establishment-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-TYPE-ESTABLISHMENT for a
specific OBJECT-TYPE and to distinguish it from all other OBJECT-TYPEESTABLISHMENTs for that OBJECT-TYPE.
c.
object-type-establishment-effective-datetime—The
character
string
representing a point in time that designates the beginning date of the period
318
V3.1.4
of effectiveness of a specific OBJECT-TYPE-ESTABLISHMENT. Note:
The effective date for establishments can be given only to the nearest day.
d.
object-type-establishment-category-code—The specific value that represents
the class of OBJECT-TYPE-ESTABLISHMENT when the established and
detail OBJECT-TYPEs are instances of MATERIEL-TYPE. The applicable
domain values are: Complete equipment schedule; Parts catalogue. Note:
This attribute applies only when the OBJECT-TYPE is a MATERIELTYPE. In that case the category code is a key indicator of data contents. For
example, a complete equipment schedule for a main battle tank may include
radio sets, tools, user handbooks, etc. A parts catalogue for a main battle tank
may consist of a chassis, a gun, a power pack, wheels, track-links, panels,
nuts, bolts, screws, etc.
e.
object-type-establishment-environment-condition-code—The specific value
that represents the environmental conditions for which a specific OBJECTTYPE-ESTABLISHMENT is authorised. The domain values are: Arctic;
Desert; Jungle; Mountain; Temperate; Tropical; Not known; Not otherwise
specified.
f.
object-type-establishment-name-text—The character string assigned to
represent a specific OBJECT-TYPE-ESTABLISHMENT.
g.
object-type-establishment-operational-mode-code—The specific value that
represents the operational mode for which a specific OBJECT-TYPEESTABLISHMENT is authorised. The domain values are: Civil support;
Humanitarian support; Internal security; Peace; Peace keeping; Peace
support; War.
11.2.3 OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL is defined
as "The number of a specific OBJECT-TYPE that is authorised by a specific OBJECTTYPE-ESTABLISHMENT." The attributes are:
a.
b.
c.
object-type-establishment-object-type-detail-index—The unique value, or set
of characters, assigned to represent a specific OBJECT-TYPEESTABLISHMENT-OBJECT-TYPE-DETAIL for a specific "established"
OBJECT-TYPE and to distinguish it from all other OBJECT-TYPEESTABLISHMENT-OBJECT-TYPE-DETAILs for that OBJECT-TYPE.
d.
object-type-establishment-object-type-detail-major-part-indicator-code—The
specific value that denotes whether a detail is a ‘major part’ when the
established and detail OBJECT-TYPEs are instances of MATERIEL-TYPE.
The domain values are: No; Yes.
319
V3.1.4
e.
object-type-establishment-object-type-detail-count—The
integer
value
representing the count of the numbers of a specific OBJECT-TYPE
authorised to be part of a specific OBJECT-TYPE-ESTABLISHMENTOBJECT-TYPE-DETAIL.
f.
object-type-establishment-object-type-detail-object-type-id—The
objecttype-id of a specific OBJECT-TYPE that is authorised to be held in the
establishment of a specific OBJECT-TYPE (a role name for object-type-id).
g.
object-type-establishment-detail-object-type-establishment-index—The
object-type-establishment-index that identifies the specific establishment
associated with the "detailed" OBJECT-TYPE in a specific OBJECT-TYPEESTABLISHMENT-OBJECT-TYPE-DETAIL (a role name for object-typeestablishment-index).
11.3
Business Rules for Establishments
11.3.1 The model structure specified in the previous section permits any category
of OBJECT-TYPE to be established with any other category of constituent OBJECTTYPE. Not all combinations are meaningful or deemed necessary in support of military
operations. Valid combinations for establishment are specified in Annex G1, Section
G1.7.1.
11.3.2 Business Rules for operationally meaningful establishment details are
specified in Annex G1, Section G1.7.2.
11.4
Examples of Establishments
This section presents a series of examples using the establishment specification.
These range from specifying an establishment for MATERIEL-TYPE to specifying
organisational, personnel, and materiel compositions for ORGANISATION-TYPE to
using establishment specifications to describe packaging concepts.
11.4.1 An Establishment for MATERIEL-TYPE
11.4.1.1 The table below illustrates an OBJECT-TYPE-ESTABLISHMENT
when the OBJECT-TYPE is a MATERIEL-TYPE. Sub-tables (a) and (b) list the
equipment types that are used in this example. Sub-tables (c) and (d) present a parts
catalogue for a grenade launcher (object-item-id = 115) that is equipped with a firing pin
(id = 117), a trigger guard (id = 118), and a pistol grip (id = 119).
Table 126. Establishment Example for MATERIEL-TYPE
(a) OBJECT-TYPE
(b) MATERIEL-TYPE
objecttype-id
115
117
118
119
*-id
*-categorycode
*-reportableitem-text
*-stocknumber-text
*-supplyclass-code
Infantry small arms light
support weapon--Grenade
Launcher 30 mm
Firing Pin
Trigger guard
Pistol Grip
115
EQ
—
24010001111
CLS2
117
118
119
EQ
EQ
EQ
—
—
—
14010001111
16200001111
17210001111
CLS2
CLS2
CLS2
Note: * = "materiel-type"
320
V3.1.4
(c) OBJECT-TYPE-ESTABLISHMENT
establishedobject-type-id
**index
**-effective-datetime
**-categorycode
**-environmentcondition-code
**-nametext
**-operationalmode-code
115
1
20020110000000.000
Parts
catalogue
Temperate
—
—
Note: ** = "object-type-establishment"
(d) OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL
established
-objecttype-id
***index
***-objecttype-detailindex
***-object-typedetail-major-partindicator-code
***-objecttype-detailcount
***-objecttype-detailobject-type-id
***-detail-objecttype-establishmentindex
115
115
115
1
1
1
1
2
3
No
No
No
1
1
1
117
118
119
—
—
—
Note: *** = "object-type-establishment"
11.4.1.2 The role of the attribute object-type-establishment-detail-object-typeestablishment-index in creation of hierarchies of establishments is discussed in a
subsequent section.
11.4.2 Equipment Establishments for ORGANISATION-TYPEs
This example illustrates instances of OBJECT-TYPE-ESTABLISHMENT when
the OBJECT-TYPE is an ORGANISATION-TYPE and the OBJECT-TYPEESTABLISHMENT-OBJECT-TYPE-DETAIL consists of MATERIEL-TYPEs. The data
is taken from war and peace establishments for a UK Armoured Regiment and 6 Guards
Tank Division.
a.
The following establishments became effective in January 1985: a UK
Armoured Regiment was authorised to have 48 Challenger MBTs for use in
peacetime in an unspecified climate environment, and 57 Challenger MBTs
for use in wartime in a desert climate.
b.
The following establishments for arctic climate became effective in March
1990: an OR Armoured Division was authorised to have 170 T64s for use in
peacetime and 190 T64s for use in wartime.
Data representation of the establishment statements is illustrated in the table below.
Table 127. Example of MATERIEL-TYPE Detail in OBJECT-TYPE-ESTABLISHMENT
(a) OBJECT-TYPE-ESTABLISHMENT
*index
*-effectivedatetime
*-categorycode
*-environmentcondition-code
*-nametext
*-operationalmode-code
4321
(UK Armd
Regt)
4321
(UK Armd
Regt)
644
(OR Armd Div)
644
(OR Armd Div)
1
198501000
00000.000
—
—
Peace
TOE
Peace
2
198501000
00000.000
—
Desert
War
TOE
War
1
199003000
00000.000
199003000
00000.000
—
Arctic
Peace
—
Arctic
Peace
TOE
War
TOE
2
321
War
V3.1.4
(b) OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL
**index
***index
***-major-partindicator-code
***count
4321
(UK Armd Regt)
4321
(UK Armd Regt)
644
(OR Armd Div)
644
(OR Armd Div)
1
1
—
48
2
1
—
57
1
1
—
170
2
1
—
190
**-detail-object-typeestablishment-index
***-object-type-id
68763
(Challenger MBT)
68763
(Challenger MBT)
706
(T64)
706
(T64)
—
—
—
—
Note: *** = "object-type-establishment-object-type-detail"
11.4.3 Organisation Establishments for ORGANISATION-TYPE
11.4.3.1 The table below illustrates an OBJECT-TYPE-ESTABLISHMENT
when the OBJECT-TYPE is ORGANISATION-TYPE and the OBJECT-TYPEESTABLISHMENT-OBJECT-TYPE-DETAIL captures ORGANISATION-TYPEs. Subtables (a), (b), (c), and (d) provide data for unit type specification. Sub-table (e) lists
establishments for instances of ORGANISATION-TYPE. The organisational breakdown
is shown in Sub-table (f). It specifies that a company (type-id 1233) consists of 4 platoons
and that a platoon (type-id 1234) consists of 5 squads (type-id 1235).
Table 128. Example of ORGANISATION-TYPE Detail in
organisationtype-id
organisation-typecategory-code
organisation-typedescription-text
1233
1234
1235
Infantry Company
Infantry Platoon
Infantry Squad
governmentorganisation-type-id
government-organisation-typecategory-code
government-organisationtype-main-activity-code
1233
1234
1235
—
—
—
military-organisationtype-id
military-organisationtype-category-code
military-organisationtype-service-code
1233
1234
1235
UNIT-TYPE
UNIT-TYPE
UNIT-TYPE
Army
Army
Army
(d) UNIT-TYPE
unittypeid
unittypecategory
-code
unit-typearmcategorycode
unit-type-armspecialisationcode
unit-typesupplementaryspecialisationcode
unit-typegeneralmobilitycode
unittypequalifiercode
unittypesizecode
1233
1234
Combat
Combat
Infantry
Infantry
—
—
Mechanised
Mechanised
—
—
—
—
Coy
Plt
322
V3.1.4
1235
Combat
Infantry
—
Mechanised
—
—
Sqd
(e) OBJECT-TYPE-ESTABLISHMENT
establishedobject-type-id *-index
1233
1
1234
1
*-effectivedatetime
*-categorycode
20000211000
000.000
20000211000
000.000
—
Mountain
—
Mountain
*-name-text
Infantry
Company TOO
Infantry Platoon
TOO
War
War
Note: * = "object-type-establishment"
(f) OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL
**index
***index
***count
***-objecttype-id
1233
1234
1
1
1
1
—
—
4
5
1234
1235
1
1
11.4.4 Multiple Establishments for ORGANISATION-TYPE
11.4.4.1 Differences in composition of types of objects can be represented either
by defining new types or defining different establishments. These are decisions that force
planners face. The following example deals with unit types that are given more than one
establishment. The example builds on the one in the previous section by postulating that
the squads at the lowest level have two establishments—one for mountain environment
and another for temperate environment. The double establishment at the squad level forces
the specification of double establishments at the superior platoon and company level units.
11.4.4.2 The table below illustrates the cascading effect from the bottom up.
Sub-table (a) lists establishments for instances of ORGANISATION-TYPE. Each unit
type has two establishments. The organisational breakdown is shown in Sub-table (f). The
actual establishments for the squad are not shown, but simply postulated. Details of
differences in personnel and equipment are presented in subsequent examples. A crucial
element is the use of the attribute detail-object-type-establishment-index that permits the
selection of one of two alternative establishments. Note that this is the role name for the
attribute object-type-establishment-index in Sub-table (e) so that the values for
corresponding instances must be the same. As an illustration of one step, one can trace the
establishments for the platoons (object-type-id = 1234). In Sub-table (b) row 3 the value
"1" in the last column indicates that the first of two establishments for the squad are to be
used. Since "1" indicates "Mountain" establishment for the squad, the platoon in effect
must also have a "Mountain" establishment. Row 4 of Sub-table (b) has the value "2" in
the last column. This points to the "Temperate" establishment for the squads, and hence
for the platoon. The attribute detail-object-type-establishment-index enables the re-use of
establishment data. Alternative treatment is illustrated in a subsequent example.
323
V3.1.4
Table 129. Example of Multiple OBJECT-TYPE-ESTABLISHMENTs
(a) OBJECT-TYPE-ESTABLISHMENT
*-index
*-effective-datetime
**-name-text
1233
1233
1234
1234
1235
1235
1
2
1
2
1
2
20000211000000.000
20000211000000.000
20000211000000.000
20000211000000.000
20000211000000.000
20000211000000.000
Mountain
Temperate
Mountain
Temperate
Mountain
Temperate
Inf Coy Est. alt. 1
Inf Coy Est. alt. 2
Inf Plt Est. alt. 1
Inf Plt Est. alt 2
Inf Sqd Est. alt. 1
Inf Sqd Est. alt. 2
War
War
War
War
War
War
**-index
***-index
***-count
***-objecttype-id
1233
1233
1234
1234
1
2
1
2
1
1
1
1
4
4
5
5
1234
1234
1235
1235
1
2
1
2
11.4.5 Alternative Personnel Establishments
11.4.5.1 One of the reasons for different establishments for a unit type is that the
personnel composition may be different. Such an instance is illustrated in the figure below
that shows two different personnel authorisations for an infantry company. The first
alternative results in a company with 190 soldiers and the second with 210 soldiers. The
differences stem from the squad level since the personnel composition above the squad
level is identical. This example is consistent with that of the previous section.
Infantry Coy Est. alt. 1
1 Captain, 1 Sergeant
Infantry Coy Est. alt. 2
1 Captain, 1 Sergeant
Made up from 4
Infantry Platoon Est. alt. 1
1 Lieutenant, 1 Sergeant
Made up from 4
Infantry Platoon Est. alt. 2
1 Lieutenant, 1 Sergeant
Made up from 5
Infantry Squad Est. alt. 1
6 Private (Class 4)
3 Private (Class 1-3)
Made up from 5
Infantry Squad Est. alt. 2
8 Private (Class 4)
2 Private (Class 1-3)
Figure 94. Alternative Personnel Establishments for an Infantry Company
324
V3.1.4
11.4.5.2 Data for the example appears in the table below. Sub-table (a) identifies
instances of person type and Sub-table (b) lists the number of personnel of each type for
each unit type under each alternative, as indicated by explanatory notes to the right of the
table.
Table 130. Example of a Unit Type with Two Personnel Establishments
(a) PERSON-TYPE
persontype-id
person-typecategory-code
person-typesubcategory-code
person-type-rank-code
11
12
13
14
15
16
Military
Military
Military
Military
Military
Military
—
—
—
—
—
—
OR-1 [Private Class 4]
OR-2 [Private Class 1-3]
OF-1 [Lieutenant/Second Lieutenant]
OR-5 [Sergeant(Junior)]
OF-2 [Captain]
OR-6 [Sergeant (3 Years Seniority)]
**index
***index
***count
***-objecttype-id
1233
1
1
1
15
—
1233
1
2
1
16
—
1233
2
1
1
15
—
1233
2
2
1
16
—
1234
1
1
1
13
—
1234
1
2
1
14
—
1234
2
1
1
13
—
1234
2
2
1
14
—
1235
1
1
6
11
—
1235
1
2
3
12
—
1235
2
1
8
11
—
1235
2
2
2
12
—
Company
Alternative 1
Company
Alternative 2
Platoon
Alternative 1
Platoon
Alternative 2
Squad
Alternative 1
Squad
Alternative 2
11.4.5.3 Since the table above is part of the establishment specifications that
include both an organisational and personnel compositions, the total number of personnel
for each establishment would have to be derived by using Table 130 that provides the
number of personnel by type in each unit type in conjunction with Table 129 that provides
the organisational composition—the number of subordinate units at each echelon above
the lowest.
325
V3.1.4
11.4.5.4 If the data requirement is simply to provide the aggregated totals of
personnel composition at each echelon without specifying the organisational composition,
then the data product would be as shown in the table below.
Table 131. Personnel-Only Establishment
**index
***index
***-count
***-objecttype-id
1233
1
1
1
15
—
1233
1233
1233
1233
1233
1
1
1
1
1
2
3
4
5
6
1
4
4
120
60
16
13
14
11
12
—
—
—
—
—
1233
2
1
1
15
—
1233
1233
1233
1233
1233
2
2
2
2
2
2
3
4
5
6
1
4
4
160
40
16
13
14
11
12
—
—
—
—
—
1234
1
1
1
13
—
1234
1234
1234
1
1
1
2
3
4
1
30
15
14
11
12
—
—
—
1234
2
1
1
13
—
1234
1234
1234
2
2
2
2
3
4
1
40
10
14
11
12
—
—
—
1235
1
1
6
11
—
1235
1
2
3
12
—
1235
2
1
8
11
—
1235
2
2
2
12
—
Company
Alternative 1
Company
Alternative 2
Platoon
Alternative 1
Platoon
Alternative 2
Squad
Alternative 1
Squad
Alternative 2
11.4.6 Alternative Materiel Establishments
11.4.6.1 Examples of organisational and personnel establishments have been
presented in the previous sections. Additional establishment specification could arise from
differences in the materiel composition of the unit types. The infantry company is
authorised to be equipped in two different ways as illustrated in the figure below.
326
V3.1.4
Infantry Coy Est. Alt. 1
2 - Light Mortar 55mm
2 - Anti-Tank Guided Missile Mid Range - Milan
Infantry Coy Est. Alt. 2
2 - Light Mortar 55mm
2 - Anti-Tank Guided Missile Mid Range – Milan
2 – Shotgun 12-Gauge M870
Made up from 4 Infantry Platoon Est. Alt. 1
10 – sub-machine gun 5.56 mm
20 – Rifle 7.92 mm – Mauser
15 –Grenade Launcher 30 mm
Made up from 4 Infantry Platoon Est. Alt. 2
21 – Rifle 7.92 mm – Mauser
16 –Grenade Launcher 30 mm
Made up from 5 Infantry Squad Est. Alt. 1
11 – Light Mortar 55 mm
16 – Grenade Launcher 30 mm
Made up from 5 Infantry Squad Est. Alt. 2
15 – Light Mortar 55 mm
20 – Rifle 7.92 mm - Mauser
Figure 95. Alternate Materiel Establishments for Infantry Company
11.4.6.2 Data for this example is presented in the table below. Sub-tables (a) and
(b) identify the appropriate instances of MATERIEL-TYPE. Sub-table (c) lists the
establishments for these instances. In most cases, there are two establishments for
employment in mountain and temperate environments. The details of the actual
establishments are not shown. Sub-table (b) lists the establishments for the unit types; it is
a repeat of a table presented in an earlier section. The specification of materiel type of
establishments for these unit types is presented in Sub-table (e). When instances of
MATERIEL-TYPE is indicated as part of establishment for ORGANISATION-TYPE in
Sub-table (e) and more than one establishment is associated with that instance of
MATERIEL-TYPE in Sub-table (d), an unambiguous choice of the correct establishment
is enabled by entering an appropriate value in object-type-establishment-detail-objecttype-establishment-index column.
11.4.6.3 A careful reading of Sub-table (c), (d), and (e) will show that in most
cases the environmental conditions for the unit type establishments are matched with the
environmental conditions for the materiel type establishments. Three exceptions occur as
shown by the grey squares in Sub-table (e). In these cases, the equipment has a temperate
establishment but is assigned to the unit type establishment meant for mountain
environment.
327
V3.1.4
Table 132. Example of a Unit Type with Two Materiel Establishments
(a) OBJECT-TYPE
objecttype-id
(b) MATERIEL-TYPE
111
112
Mortar Light 51 mm A
Infantry Anti-Tank Guided
Missile System Medium
Range - Milan
Infantry Small Arm submachine Gun 5.56 mm
Infantry Small Arm Rifle
7.92 mm Mauser
Infantry Small Arm light
support weapon Grenade
Launcher 30 mm
Infantry Small Arm
Shotgun 12-Gauge M870
113
114
115
116
materieltype-id
*-categorycode
*-stocknumber-text
*-supplyclass-code
111
112
EQ
EQ
—
—
13310001111
2320001111
CLS2
CLS2
113
EQ
—
33030001111
CLS2
114
EQ
—
12020001111
CLS5
115
EQ
—
24010001111
CLS2
116
EQ
—
24200001111
CLS2
(c) OBJECT-TYPE-ESTABLISHMENT (for MATERIEL-TYPE)
*index
*-category-code
*-nametext
111
111
112
113
113
114
115
115
116
116
1
2
1
1
2
1
1
2
1
2
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
Complete equipment schedule
Parts catalogue
Parts catalogue
Temperate
Mountain
Temperate
Temperate
Mountain
Temperate
Temperate
Mountain
Temperate
Mountain
—
—
—
—
—
—
—
—
—
—
(d) OBJECT-TYPE-ESTABLISHMENT (for ORGANISATION-TYPE)
*index
*-name-text
1233
1233
1234
1234
1235
1235
1
2
1
2
1
2
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
20020110000000.000
Mountain
Temperate
Mountain
Temperate
Mountain
Temperate
Inf Coy Est. alt. 1
Inf Coy Est. alt. 2
Inf Plt Est. alt. 1
Inf Plt Est. alt 2
Inf Sqd Est. alt. 1
Inf Sqd Est. alt. 2
War
War
War
War
War
War
328
V3.1.4
(e) OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL
**-index
***-index
***-count
***-object-typeid
1233
1
1
2
111
2
1233
1233
1233
1233
1234
1
2
2
2
1
2
1
2
3
1
2
2
2
2
15
112
111
112
116
112
1
1
1
1
1
1234
1234
1234
1234
1234
1
1
1
2
2
2
3
4
1
2
10
20
15
16
11
113
114
115
112
113
2
1
2
1
1
1234
1234
1235
1235
1235
1235
1235
1235
1235
1235
2
2
1
1
1
1
2
2
2
2
3
4
1
2
3
4
1
2
3
4
21
16
11
11
16
21
15
10
20
15
114
115
111
113
115
116
111
113
114
116
1
1
2
2
2
2
1
1
1
1
11.4.6.4 Although the examples of establishment for the mountain and temperate
employment of three unit types were decomposed into several parts for purposes of
exposition, the complete establishment specification would be presented in two entities.
OBJECT-TYPE-ESTABLISHMENT would be Sub-table (a) of Table 129; the detail data
for that establishment would be a set of records in OBJECT-TYPE-ESTABLISHMENTOBJECT-TYPE-DETAIL drawn from Table 129 Sub-table (b), Table 130 Sub-table (b),
and Table 132 Sub-table (e). It should be noted that all data that belongs to a single
establishment for a specific instance of OBJECT-TYPE must be referenced to the same
value of object-type-establishment-index.
11.4.7 Examples of Establishment in Packaging
11.4.7.1 This section contains two examples where establishment concepts are
used to represent packaging. The first one is for a missile in its container. The second
example is used to specify the contents of a pallet.
11.4.7.2 The flexibility of the establishment structure in the model is
demonstrated in the following example (see the table below) where the requirement to
specify a missile container containing one Patriot missile is satisfied via OBJECT-TYPEESTABLISHMENT and OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL.
Sub-tables (a) through (f) show the inputs required in the OBJECT-TYPE hierarchy. Subtables (g) and (h) contain the data needed to describe the Patriot missile in its packaged
state.
329
V3.1.4
Table 133. Example of a Missile Container Specification
(a) OBJECT-TYPE
objecttype-id
1278
MATERIEL-TYPE
No
1279
MATERIEL-TYPE
No
1280
MATERIEL-TYPE
No
Patriot Missile
Container
Patriot Missile
Patriot Missile in
Container
(b) MATERIEL-TYPE
*-stocknumber-text
*-supplyclass-code
EQUIPMENTTYPE
—
1234567890123
Class5
1279
—
4321987654321
Class5
1280
—
1234123456789
Class5
*-id
*-category-code
1278
*-issuingheight-dim
*-issuinglength-dim
*-issuingwidth-dim
1.554
[metre]
0.980
[metre]
1.554
[metre]
5.720
[metre]
4.620
[metre]
5.720
[metre]
1.554
[metre]
0.980
[metre]
1.554
[metre]
(c) CONSUMABLE-MATERIEL-TYPE
**-id
**-categorycode
**subcategorycode
**-hazardcode
**-issuingelementcode
**issuingcount
**-issuingunit-ofmeasure
**-issuingweightquantity
**perishabilityindicator
—
Explosives
—
1
Each
—
Yes
—
Explosives
—
1
Each
—
Yes
AMMUNITIONTYPE
AMMUNITION1280
TYPE
1279
Note: ** = "consumable-materiel-type"
(d) AMMUNITION-TYPE
ammunitiontype-id
ammunition-typecategory-code
ammunition-typecalibre-text
1279
1280
Surface-to-Air Missile
Surface-to-Air Missile
—
—
(e) EQUIPMENT-TYPE
equipmenttype-id
equipment-typecategory-code
equipment-type-loaded-weightquantity
equipment-type-unloaded-weightquantity
1278
2000 (kg)
2000 (kg)
(f) MISCELLANEOUS-EQUIPMENT-TYPE
miscellaneousequipment-type-id
miscellaneous-equipment-typecategory-code
miscellaneous-equipment-typesubcategory-code
1278
Container
—
(g) OBJECT-TYPE-ESTABLISHMENT
1280
***-index
1
***-effectivedatetime
19970323000000.000
***-categorycode
***-environmentcondition-code
Parts catalogue
330
—
***-name-text
Container Loaded with
Patriot Missile
V3.1.4
(h) OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL
**index
***index-id
***-count
***-object-typeid
1280
1
1278
Yes
1
1278
—
1280
1
1279
Yes
1
1279
—
11.4.7.3 The table below shows how to specify a pallet that is loaded with 100
jerricans of oil. More complex examples such as pallets of ammunition with a standardised
mixture of different kinds and amounts of ammunition are of course also possible. The
data for the OBJECT-TYPE hierarchy is contained in the Sub-tables (a) through (c). The
authorised quantities for this type of pallet are shown in Sub-tables (d) and (e).
Table 134. Example of a Pallet Specification
(a) OBJECT-TYPE
object-typeid
3279
MATERIEL-TYPE
No
4657
MATERIEL-TYPE
No
Jerrican of Oil
Pallet of 100
jerricans of oil
(b) MATERIEL-TYPE
*-id
*-category-code
4657
*-issuinglengthdimension
*-issuingwidthdimension
Class3
0. 80
[metre]
0. 40
[metre]
0.20
[metre]
Class3
1.90
[metre]
2.20
[metre]
2.20
[metre]
*-stocknumber-text
*-supplyclass-code
—
4321987654321
—
4321123456789
CONSUMABLEMATERIELTYPE
CONSUMABLEMATERIELTYPE
3279
*-issuingheightdimension
(c) CONSUMABLE-MATERIEL-TYPE
**-id
**categorycode
**subcategorycode
**-hazardcode
**-issuingelementcode
**issuingcount
**-issuingunit-ofmeasure
**-issuingweightquantity
***perishabilityindicator
3279
4657
POL
POL
Lubricant
Lubricant
Inflammable
Inflammable
Jerrican
Pallet
1
1
Each
Each
15.6 [kg]
1572 [kg]
No
No
Note: ** = "consumable-materiel-type"
(d) OBJECT-TYPE-ESTABLISHMENT
***index
***-effectivedatetime
***-category-code
***-environmentcondition-code
***-name-text
4657
1
19940208000000.000
Parts catalogue
—
Pallet of 100 oil cans
(e) OBJECT-TYPE-ESTABLISHMENT-OBJECT-TYPE-DETAIL
****index
4657
1
*****-index
*****-major-partindicator-code
*****-count
*****-objecttype-id
****-detail-object-typeestablishment-index
Yes
100
3279
—
Note: **** = "object-type-establishment"
Note: ***** = "object-type-establishment-object-type-detail"
331
V3.1.4
11.5
Linking OBJECT-ITEMs to Establishments
11.5.1 Since OBJECT-TYPEs may have more than one establishment at any given
time, it is necessary to link instances of establishment with the corresponding items. The
model provides the linkage by means of the associative entity OBJECT-ITEM-OBJECTTYPE-ESTABLISHMENT illustrated in the figure below. It is defined as "A specification
of an OBJECT-TYPE-ESTABLISHMENT that is authorised for a specific OBJECTITEM."
OBJECT-TYPE
OBJECT-ITEM
object-type-id
object-item-id
is-assigned-establishment-through
object-type-establishment-index
object-type-establishment-effective-datetime
object-type-establishment-category-code
object-type-establishment-environment-condition-code
object-type-establishment-name-text
object-type-establishment-operational-mode-code
is-assigned-through
OBJECT-ITEM-OBJECT-TYPE-ESTABLISHMENT
object-item-id (FK)
object-type-establishment-index (FK)
object-item-object-type-establishment-index
object-item-object-type-establishment-effective-datetime
Figure 96. Establishment Relationships between OBJECT-TYPE and OBJECT-ITEM
11.5.2 The associative entity carries only one native key attribute generically
labelled "-establishment-index.” It permits more than one establishment to be associated
with or authorised for any of the allowable subtypes of OBJECT-ITEM. The other primary
attributes are foreign keys that identify the relevant establishment. In addition, each entity
has one data attribute to record effective datetime. The definitions of the attributes are:
a.
b.
332
V3.1.4
c.
d.
object-item-object-type-establishment-index—The unique value, or set of
characters, assigned to represent a specific OBJECT-ITEM-OBJECT-TYPEESTABLISHMENT for a specific OBJECT-ITEM and a specific OBJECTTYPE-ESTABLISHMENT and to distinguish it from all other OBJECTITEM-OBJECT-TYPE-ESTABLISHMENTs for that OBJECT-ITEM and
that OBJECT-TYPE-ESTABLISHMENT.
e.
object-item-object-type-establishment-effective-datetime—The
character
string representing a point in time that designates the effective assignment
date of a specific OBJECT-TYPE-ESTABLISHMENT to a specific
OBJECT-ITEM.
11.5.3 The table below illustrates the use of the linkage. Basic establishment data
is shown in Sub-table (a). This is repeated from an earlier example and represents the
following two statements:
a.
The following establishments became effective in January 1985: a UK
Armoured Regiment was authorised to have 48 Challenger MBTs for use in
peacetime in an unspecified climate environment, and 57 Challenger MBTs
for use in wartime in a desert climate.
b.
The following establishments for arctic climate became effective in March
1990: an OR Armoured Division was authorised to have 170 T64s for use in
peacetime and 190 T64s for use in wartime.
These establishments were assigned to nominally actual units as follows:
a.
A peacetime establishment (authorising 48 MBTs) was assigned to 2 RTR
effective as of 6 January 1994.
b.
A wartime establishment (authorising 57 MBTs) was assigned to 2 RTR
effective 13 March 1994
c.
2 RTR was re-assigned the peacetime establishment effective 13 June 1994
(authorised to hold 48 MBTs again).
d.
A peacetime establishment (authorising 170 T64s) was assigned to 6 Guards
Tank Division on 2 January 1994.
e.
A wartime establishment (authorising 190 T64s) was assigned to 6 Guards
Tank Division on 17 March 1994.
These assignments are shown in Sub-table (b).
333
V3.1.4
Table 135. Use of OBJECT-ITEM-OBJECT-TYPE-ESTABLISHMENT
(a) OBJECT-TYPE-ESTABLISHMENT (for ORGANISATION-TYPE)
established-objecttype-id
4321
[UK Armd Regt]
4321
[UK Armd Regt]
644
[OR Armd Div]
644
[OR Armd Div]
*-index
1
2
1
2
*-effectivedatetime
*-name-text
198501000
00000.000
198501000
00000.000
199003000
00000.000
—
Peace TOE
Peace
Desert
War TOE
War
Arctic
Peace TOE
Peace
Arctic
War TOE
War
199003000
00000.000
(b) OBJECT-ITEM-OBJECT-TYPE-ESTABLISHMENT (for ORGANISATION)
object-item-id
established-objecttype-id
**index
object-item-**index
object-item-**effective-datetime
1917
[2 RTR]
1917
[2 RTR]
1917
[2 RTR]
14486
14486
4321
[UK Armd Regt]
4321
[UK Armd Regt]
4321
[UK Armd Regt]
644
[OR Armd Div]
644
[OR Armd Div]
1
1
19940106000000.000
2
1
19940313000000.000
1
2
19940613000000.000
1
1
19940102000000.000
2
1
19940317000000.000
334
V3.1.4
12. LOCATION
12.1
Concept for Representing Location and Geometry
12.1.1 The data structure under the independent entity LOCATION captures three
distinct but related concepts of interest to planners and operators:
a.
Specification of geometry that is required to describe operational objects.
b.
Placement of objects or geometry with respect to the Earth or with respect to
each other.
Specification of geometry that is required to describe the symbology of the
object on the display.
c.
12.1.2 The ability to specify geometry permits the description of various open or
closed boundaries, such as areas of responsibility, orbits, phase lines, and objectives, as
well as the shape of airfields, runways, ammunition dumps, and a security fence
surrounding an ammunition dump. The positioning of objects with respect to the Earth is
achieved by associating the entities representing objects with the LOCATION entity.
12.2
Overview of Location Structure
12.2.1 The overall structure for specifying location and geometry is illustrated in
the figure below at the entity level. For the most part, LOCATION structure is selfcontained and independent of other parts of the model. One exception occurs when a
coordinate system is set up relative to some battlefield object. This is shown by the
relationship between the entities OBJECT-ITEM-LOCATION and OBJECTREFERENCE.
12.2.2 The basic element is a point; it plays a role in generating every other
geometric construct in the specification. The location of the point can be expressed either
in absolute or relative terms. Absolute specifications are stated with respect to either a
standard description of the Earth’s surface or an Earth-centred Cartesian coordinate
system. Relative specifications are stated with respect to another point that may be
absolute or relative itself.
12.2.3 Vertical distances for a point may be specified in several ways: as a
measured altitude with respect to mean sea level, a measured height with respect to ground
or water level, a pressure altitude or pressure height, or simply stated to be the local
surface, as would be the case for an armoured vehicle moving over the terrain.
12.2.4 Lines are generated from a series of points that are connected in a specified
order. The part of a line between two successive points is a line segment; a sequence of
connected line segments defines the line, or more properly a polygonal path. A line may
close on itself if the first and last points that define the line are the same; in this case a line
may serve as a boundary for a surface. If the first and last points are not the same, then the
line is an open line, such as a phase line or a one-way route.
12.2.5 Surfaces are built either directly from lines or the points provide part of the
specification. For example, a polygon area is defined by a closed boundary line. An ellipse
is completely defined by three points. Almost any figure, even an ellipse, could be
335
V3.1.4
approximated by a polygonal area; however, it is somewhat more efficient to provide
explicit specifications for some of the figures that are called for in the operational
requirements, and in some cases it is essential since not all geometric aspects can be
completely described by polygons. For example, the specifications for corridor, orbit, and
track require additional parameters as will be described in subsequent sections.
LOCATION
VERTICAL-DISTANCE
GEOMETRIC-VOLUME
POINT
P
LINE
SURFACE
LINE-POINT
CONE-VOLUME
SPHERE-VOLUME
CORRIDOR-AREA
point-category-code
ABSOLUTE-POINT
POLYGON-AREA
POLYARC-AREA
CARTESIAN-POINT
FAN-AREA
GEOGRAPHIC-POINT
TRACK-AREA
RELATIVE-POINT
ORBIT-AREA
ELLIPSE
POINT-REFERENCE
OBJECT-REFERENCE
SURFACE-VOLUME
OBJECT-ITEM
Figure 97. Entity-Level View of the LOCATION Structure45
12.2.6 Most volumes are built by using the horizontal projection of a surface onto
the Earth’s surface to define the outer boundaries of a general cylinder and to specify the
top and bottom vertical distances to close off the volume. Thus, any of the geometric
This diagram is focused on the specification of LOCATION only. OBJECT-ITEM and
OBJECT-ITEM-LOCATION are in the diagram because they support the definition of
RELATIVE-COORDINATE-SYSTEM. The dependency between LOCATION and ACTION via
ACTION-LOCATION is presented in Chapter 17 (Section 17.9.2).
45
336
V3.1.4
figures that are constructed as surfaces can be the basis for a volume. Two additional
volume geometries—cones and spheres—do not follow this pattern and require individual
specifications.
12.2.7 The notion of LOCATION and its subtypes is discussed and illustrated in
detail in the sections following immediately. The topics covered are as follows:
a.
Section 12.3—Specification of LOCATION.
b.
Section 12.4—Specification of POINT and supporting structures
VERTICAL-DISTANCE and RELATIVE-COORDINATE-SYSTEM.
c.
Section 12.5—Specification of LINE.
d.
Section 12.6—Specification of SURFACE.
e.
Section 12.7—Specification of GEOMETRIC-VOLUME.
f.
Section 12.8—Specification of OBJECT-ITEM-LOCATION as a way of
connecting instances of LOCATION to instances of OBJECT-ITEM and
providing additional specifications.
g.
Section 12.9—The Use of Value "Undefined" for location-category-code.
h.
Section 12.10—Cross-reference to specification of ACTION-LOCATION.
i.
Section 12.11—Cross-references to business rules.
12.3
Specification of the Top-Level Entity LOCATION
12.3.1 LOCATION is defined as "A specification of position and geometry with
respect to a specified horizontal frame of reference and a vertical distance measured from
a specified datum." LOCATION is an independent entity that has only two attributes: its
identifier and a discriminator that points to one of its four subtypes. The attributes are:
a.
location-id—The unique value, or set of characters, assigned to represent a
specific LOCATION and to distinguish it from all other LOCATIONs.
b.
location-category-code—The specific value that represents a class of
LOCATION. It serves as a discriminator that partitions LOCATION into
subtypes. The domain values are: GEOMETRIC-VOLUME; LINE; POINT;
SURFACE; Undefined.
12.3.2 Four values for location-category-code point to geometric subtypes of
LOCATION: a zero dimensional POINT, a one dimensional LINE that can be a polygonal
path, a two-dimensional SURFACE, and a three-dimensional GEOMETRIC-VOLUME.
Thus, LOCATION can specify geometry as well as position in space. The four subtypes of
LOCATION, their substructures, and the relationships among them are described in detail
in the sections below. The use of value "Undefined" for location-category-code is
explained in a subsequent section.
12.4
Specification of POINT and Supporting Structures
12.4.1 Introduction
POINT is a key element in the LOCATION structure. The data structure for
POINT and its supporting elements is illustrated in the figure below. All geometric
constructs are defined either totally or partially in terms of the POINT structure. A POINT
337
V3.1.4
can be either an ABSOLUTE-POINT or a RELATIVE-POINT. ABSOLUTE-POINT in
turn can be specified either as a GEOGRAPHIC-POINT with respect to the Earth’s
surface or a CARTESIAN-POINT with respect to an Earth-centred frame of reference.
The specification of a RELATIVE-POINT requires a supporting data structure
RELATIVE-COORDINATE-SYSTEM to set up a frame of reference for relative
geometry. The specification of altitudes, heights or elevations is enabled through
VERTICAL-DISTANCE.
VERTICAL-DISTANCE
relative-coordinate-system-id
vertical-distance-id
vertical-distance-reference-code
vertical-distance-dimension
vertical-distance-precision-code
vertical-distance-datum-text
POINT
point-id (FK)
point-category-code
is-specified-for
point-category-code
is-endpoint-of-x-vector-for /
is-defined-using
is-endpoint-of-y-vector-for /
is-defined-using
ABSOLUTE-POINT
absolute-point-id (FK)
is-origin-for /
is-defined-using
absolute-point-vertical-distance-id (FK)
POINT-REFERENCE
relative-coordinate-system-id (FK)
point-reference-origin-point-id (FK)
point-reference-x-vector-point-id (FK)
point-reference-y-vector-point-id (FK)
CARTESIAN-POINT
cartesian-point-id (FK)
cartesian-point-x-coordinate-dimension
cartesian-point-y-coordinate-dimension
cartesian-point-z-coordinate-dimension
cartesian-point-x-precision-code
cartesian-point-y-precision-code
cartesian-point-z-precision-code
OBJECT-REFERENCE
object-reference-object-item-id (FK)
object-reference-location-id (FK)
object-reference-object-item-location-index (FK)
GEOGRAPHIC-POINT
used-for-expression-of /
expressed-with-reference-to
geographic-point-id (FK)
RELATIVE-POINT
relative-point-id (FK)
relative-point-x-coordinate-dimension
relative-point-y-coordinate-dimension
relative-point-z-coordinate-dimension
relative-point-x-precision-code
relative-point-y-precision-code
relative-point-z-precision-code
geographic-point-latitude-coordinate
geographic-point-longitude-coordinate
geographic-point-latitude-precision-code
geographic-point-longitude-precision-code
Figure 98. Specification of POINT Structures
338
V3.1.4
12.4.2 Specification of POINT
The entity POINT is defined as "A zero dimensional LOCATION." POINT itself
has only two attributes. The attributes are:
a.
point-id—The location-id of a specific POINT (a role name for location-id).
b.
point-category-code—The specific value that represents the class of POINT.
It serves as a discriminator that partitions POINT into subtypes. The domain
values are: ABSOLUTE-POINT; RELATIVE-POINT.
Substantive information is contained in the two subtypes of POINT.
12.4.3 Specification of ABSOLUTE-POINT and Its Subtypes
12.4.3.1
This section presents the specifications for ABSOLUTE-POINT and its two
subtypes: GEOGRAPHIC-POINT and CARTESIAN-POINT.
12.4.3.2 ABSOLUTE-POINT is defined as "A POINT in a geodetic system."
The model uses the World Geodetic System 1984 (WGS 84) frame of reference as the
standard. The attributes are:
a.
absolute-point-id—The point-id of a specific ABSOLUTE-POINT (a role
name for location-id).
b.
absolute-point-category-code—The specific value that represents the class of
ABSOLUTE-POINT with respect to the reference frame. It serves as a
discriminator that partitions ABSOLUTE-POINT into subtypes. The domain
values are: CARTESIAN-POINT; GEOGRAPHIC-POINT.
c.
absolute-point-vertical-distance-id—The vertical-distance-id that specifies
the vertical distance for a specific ABSOLUTE-POINT (a role name for
vertical-distance-id).
The height or altitude specification is obtained by reference to the independent entity
VERTICAL-DISTANCE whose specification is in Section 12.4.6.
12.4.3.3 GEOGRAPHIC-POINT is defined as "An ABSOLUTE-POINT that
has its position specified with respect to the surface of the World Geodetic System 1984
(WGS 84) ellipsoid." The attributes are:
a.
geographic-point-id—The absolute-point-id of a specific GEOGRAPHICPOINT (a role name for location-id).
b.
geographic-point-latitude-coordinate—The numeric value that represents the
angle between the plane of the equator and a line perpendicular to the
ellipsoid surface and passing through the GEOGRAPHIC-POINT.
c.
geographic-point-longitude-coordinate—The numeric value that represents
the angle between the initial (zero or Greenwich) meridian and the meridian
of the GEOGRAPHIC-POINT measured in the plane of the Equator.
d.
geographic-point-latitude-precision-code—The specific value that represents
the resolution used for the expression of a value of a latitude coordinate.
Example domain values are: 1/10 second; Degree; Mil; Minute. The domain
defined in the set angle-precision-code.
339
V3.1.4
e.
geographic-point-longitude-precision-code—The
specific
value
that
represents the resolution used for the expression of a value of a longitude
coordinate. Example domain values are: 1/10 second; Degree; Mil; Minute.
attributes and is defined in the set angle-precision-code.
12.4.3.4 GEOGRAPHIC-POINT is the only entity in the data model with
"coordinate" attributes—latitude and longitude.
12.4.3.5 The domain values for attributes geographic-point-latitude-precisioncode and geographic-point-longitude-precision-code are listed in the table below. These
angular values correspond to operational requirements originating from selected ADatP-3
messages. Equivalent precision in terms of a fraction of a degree is shown in the third
column. The last column lists the linear equivalence that is valid at the equator. Two
dimensional angular precision corresponds to a circle at the equator. Two-dimensional
angular precision for points away from the equator corresponds to an ellipse. The northsouth axis remains the same as at the equator, but the east-west axis decreases in
proportion to the value of cosine at the latitude. For example, the length of the axes for an
ellipse corresponding to a "Second" at latitude 45 degrees would be 30.86 and 21.82
metres. The values at latitude 60 degrees would be 30.86 and 15.43 metres (since cos 60o =
0.5).
Table 136. Domain Values for angle-precision-code
Value
Definition
1/100 second
1/1000 minute
1/10 second
Angular precision is expressed to the precision of 1/100 of a second.
Angular precision is expressed to the precision of 1/1000 of a minute.
Angular precision is expressed to the precision of 1/10 of a second.
1/100 minute
Angular precision is expressed to the precision of 1/100 of a minute
(centiminute).
Angular precision is expressed to the precision of a second.
Angular precision is expressed to the precision of 1/10 of a minute.
Angular precision is expressed to the precision of a minute (60
seconds).
Angular precision is expressed to the precision of 1 mil (1/6400 of a full
circle).
Angular precision is expressed to the precision of 1/10 of a degree.
Angular precision is expressed to the precision of a degree (60
minutes).
Second
1/10 minute
Minute
Mil
1/10 degree
Degree
Fraction of
degree
Linear
equivalence
1/360,000
1/60,000
1/36,000
1/6000
0.3087 m
1.852 m
3.087 m
18.52 m
1/3600
1/600
1/60
30.87 m
185.2 m
1852 m
9/160
6250.5 m
1/10
1
11.11 km
111.1 km
12.4.3.6 CARTESIAN-POINT is defined as "An ABSOLUTE-POINT that has
its position specified in a three-dimensional Earth-centred Cartesian system." The
attributes are:
a.
cartesian-point-id—The absolute-point-id of a specific CARTESIAN-POINT
(a role name for location-id).
b.
cartesian-point-x-coordinate-dimension—The
one-dimensional
linear
distance representing the X-component of a coordinate which expresses the
position of a point in a three-dimensional Cartesian coordinate system that is
fixed to the earth, where the X-axis lies in the planes of the Equator and the
Greenwich meridian.
c.
cartesian-point-y-coordinate-dimension—The
one-dimensional
linear
distance representing the Y-component of a coordinate which expresses the
340
V3.1.4
fixed to the earth where the Y-axis is perpendicular to both the X- and Zaxes completing the right-handed coordinate system.
d.
cartesian-point-z-coordinate-dimension—The
one-dimensional
linear
distance representing the Z-component of a coordinate which expresses the
fixed to the earth, where the Z-axis coincides with the mean rotation axis of
the Earth.
e.
cartesian-point-x-precision-code—The specific value that represents the
resolution used for the expression of a value of a Cartesian x-coordinate.
Example domain values are: 30 metre; Centimetre; Kilometre; Nautical mile.
attributes and is defined in the set distance-precision-code.
f.
cartesian-point-y-precision-code—The specific value that represents the
resolution used for the expression of a value of a Cartesian y-coordinate.
g.
cartesian-point-z-precision-code—The specific value that represents the
resolution used for the expression of a value of a Cartesian z-coordinate.
12.4.4 RELATIVE-COORDINATE-SYSTEM
12.4.4.1 There is a requirement to be able to use a local reference frame.
RELATIVE-COORDINATE-SYSTEM specification permits this functionality. It has two
subtypes: one defines a coordinate system with respect to an arbitrary point and the second
with respect to location of an object. If the object is moving or changing its orientation,
then the coordinate system is also changing. Any geometry that is specified relative to this
coordinate system will also move with it.
12.4.4.2 The independent entity RELATIVE-COORDINATE-SYSTEM is
defined as "A rectangular frame of reference defined by an origin, x and y axes in the
horizontal plane, and a z-axis. The vertical z-axis is normal to the xy-plane with positive
direction determined from the right-hand rule when the x-axis is rotated toward the yaxis." The attributes are:
a.
relative-coordinate-system-id—The unique value, or set of characters,
assigned to represent a specific RELATIVE-COORDINATE-SYSTEM and
to distinguish it from all other RELATIVE-COORDINATE-SYSTEMs.
b.
relative-coordinate-system-reference-category-code—The specific value that
represents the source of the reference for defining the origin and axial
directions for a specific RELATIVE-COORDINATE-SYSTEM. It serves as
a discriminator that partitions RELATIVE-COORDINATE-SYSTEM into
subtypes. The domain values are: OBJECT-REFERENCE; POINTREFERENCE.
341
V3.1.4
12.4.4.3 RELATIVE-COORDINATE-SYSTEM
subtype
OBJECTREFERENCE is defined as "A RELATIVE-COORDINATE-SYSTEM that has its frame
of reference defined by using the position and orientation of a specific OBJECT-ITEM at
a given point in time." The attributes are:
a.
b.
object-reference-object-item-id—The object-item-id of a specific OBJECTITEM that serves as a reference in defining a specific RELATIVECOORDINATE-SYSTEM (a role name for object-item-id).
c.
object-reference-location-id—The location-id associated with a specific
OBJECT-ITEM that serves as a reference in defining a specific RELATIVECOORDINATE-SYSTEM (a role name for location-id).
d.
object-reference-object-item-location-index—The object-item-location-index
for a specific OBJECT-ITEM-LOCATION that is used in defining a specific
RELATIVE-COORDINATE-SYSTEM (a role name for object-itemlocation-index).
Reference OBJECT-ITEM must have a point position and bearing angle specified. It is
assumed that the longitudinal axis of the OBJECT-ITEM is aligned with the bearing angle
and that its transverse axis is at right angles to the longitudinal axis. The point position
serves to define the origin for the coordinate system; the bearing angle determines positive
direction of the x-axis; the positive direction of the y-axis is pointed along a vector
through the origin that is oriented at 90 degrees counter clockwise from the x-axis.
12.4.4.4 RELATIVE-COORDINATE-SYSTEM subtype POINT-REFERENCE
is defined as "A RELATIVE-COORDINATE-SYSTEM that uses three specific POINTs
to establish its frame of reference." The attributes are:
a.
b.
point-reference-origin-point-id—The point-id of a specific POINT that
defines the origin for a specific RELATIVE-COORDINATE-SYSTEM (a
role name for location-id).
c.
point-reference-x-vector-point-id—The point-id of a specific POINT that
defines the x-vector for a specific RELATIVE-COORDINATE-SYSTEM (a
d.
point-reference-y-vector-point-id—The point-id of a specific POINT that
defines the y-vector for a specific RELATIVE-COORDINATE-SYSTEM (a
12.4.4.5 The z-axis in a RELATIVE-COORDINATE-SYSTEM is defined by
the right-hand rule. If the x-axis is rotated toward the y-axis, then the thumb points in the
positive direction along the z-axis.
342
V3.1.4
12.4.5 Specification of RELATIVE-POINT
RELATIVE-POINT permits a specification of geometry in relation to a single spot
on Earth. Relative geometry can simplify the specification of local geometry by avoiding
the use of multiple latitude and longitude entries and relying on Cartesian offsets from the
known point. RELATIVE-POINT is defined as "A POINT whose position is specified
with respect to a specific RELATIVE-COORDINATE-SYSTEM." The attributes are:
a.
relative-point-id—The point-id of a specific RELATIVE-POINT (a role
b.
relative-point-x-coordinate-dimension—The one-dimensional linear distance
representing the displacement of the specific RELATIVE-POINT along the
x-axis with respect to a specific RELATIVE-COORDINATE-SYSTEM.
c.
relative-point-y-coordinate-dimension—The one-dimensional linear distance
y-axis with respect to a specific RELATIVE-COORDINATE-SYSTEM.
d.
relative-point-z-coordinate-dimension—The one-dimensional linear distance
z-axis with respect to a specific RELATIVE-COORDINATE-SYSTEM.
e.
relative-point-x-precision-code—The specific value that represents the
maximum resolution used for the expression of a value of an x-coordinate.
f.
relative-point-y-precision-code—The specific value that represents the
maximum resolution used for the expression of a value of a y-coordinate.
g.
relative-point-z-precision-code—The specific value that represents the
maximum resolution used for the expression of a value of a z-coordinate.
h.
12.4.6 VERTICAL-DISTANCE
12.4.6.1 A VERTICAL-DISTANCE is defined as "A specification of the
altitude or height of a point or a level as measured with respect to a specified reference
datum in the direction normal to the plane that is tangent to the WGS84 ellipsoid of
revolution." The attributes are:
a.
vertical-distance-id—The unique value, or set of characters, assigned to
represent a specific VERTICAL-DISTANCE and to distinguish it from all
other VERTICAL-DISTANCEs.
343
V3.1.4
b.
vertical-distance-reference-code—The specific value that represents the
reference system for a specific VERTICAL-DISTANCE. Example domain
values are: Chart datum; Local datum; Mean sea level; Pressure datum QFE;
Pressure datum QNH; Pressure datum standard atmosphere; WGS84 geoid.
c.
vertical-distance-dimension—The
one-dimensional
linear
distance
representing the distance with respect to the specified vertical datum.
d.
vertical-distance-precision-code—The specific value that denotes the
precision of specifying a VERTICAL-DISTANCE. Example domain values
are: 30 metre; Centimetre; Kilometre; Nautical mile. The domain value set
the set distance-precision-code.
e.
vertical-distance-datum-text—The character string assigned to represent a
specific vertical reference datum.
12.4.6.2 Caution: The current specification has a non-identifying relationship
from VERTICAL-DISTANCE to ABSOLUTE-POINT. Since CARTESIAN-POINT is a
subtype of ABSOLUTE-POINT and has its own attribute for vertical distance (cartesianpoint-z-coordinate-dimension), it is possible to provide two specifications of vertical
distance for the same instance of CARTESIAN-POINT. If the two vertical distance
specifications were to be used in an implementation, care must be taken to assure that the
values chosen for cartesian-point-z-coordinate-dimension in CARTESIAN-POINT and
those associated with the foreign-key absolute-point-vertical-distance-id in the supertype
ABSOLUTE-POINT are consistent.
12.4.7 Examples of POINT
12.4.7.1 Instances of GEOGRAPHIC-POINT
Examples are provided in the table below. The relevant altitude data is included in
Sub-table (d). The angular and vertical distance precision codes need not be identical for
all points as is the case in the example. The choices were made to simplify the example.
Frequent use of this table is made in other instance tables.
Table 137. Example Instances for POINT
(a) POINT
(b) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
absolute-pointcategory-code
absolute-pointvertical-distance-id
1812
612
999
3112
613
1810
777
346
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
1812
612
999
3112
613
1810
777
346
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
11001
11001
11001
11002
11003
11003
11001
11003
344
V3.1.4
(c) GEOGRAPHIC-POINT
geographic
-point-id
geographicpoint-latitudecoordinate
geographic-pointlongitudecoordinate
geographicpoint-latitudeprecision-code
geographic-pointlongitudeprecision-code
1812
612
999
3112
613
1810
777
346
30.860
30.720
30.360
30.290
30.290
30.150
30.647
30.530
-98.671
-98.588
-98.658
-98.631
-98.580
-98.538
-98.639
-98.518
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(d) VERTICAL-DISTANCE
verticaldistance-id
vertical-distancereference-code
vertical-distancedimension
vertical-distanceprecision-code
vertical-distancedatum-text
11001
11002
11003
Mean sea level
Mean sea level
Mean sea level
200
356
1000
10 m
1m
10 m
—
—
—
12.4.7.2 Instances of RELATIVE-POINT
12.4.7.2.1 An example of a simple right-angle triangle serves to illustrate the
concept of RELATIVE-POINT as shown in the table below. Sub-tables (a) through (d)
specify the three absolute points (900, 901 and 902) that are used to define an instance of
RELATIVE-COORDINATE-SYSTEM.
12.4.7.2.2 Sub-table (e) specifies the RELATIVE-COORDINATE-SYSTEM and
indicates that it uses POINT-REFERENCE. Sub-table (f) provides the detail by indicating
the defining points. In this case, the reference frame is aligned along the easting (x-axis)
and northing (y-axis) directions.
12.4.7.2.3 The points that actually make up the triangle are specified in Sub-tables
(g) and (h). Point 701 lies 4000 metres east of the origin; Point 702 lies 3000 metres north
of the origin; and Point 703 lies 4000 metres east and 3000 metres north of the origin.
Table 138. Illustration of RELATIVE-POINT Concept
(a) POINT
(b) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
900
ABSOLUTE-POINT
900
GEOGRAPHIC-POINT
3001
901
902
ABSOLUTE-POINT
ABSOLUTE-POINT
901
902
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
3001
3001
geographic
-point-id
900
901
902
38.0000
40.0000
38.0000
-80.0000
-80.0000
-78.0000
—
—
—
—
—
—
345
V3.1.4
verticaldistance-id
3001
Mean sea level
0
—
—
(e) RELATIVE-COORDINATE-SYSTEM
relative-coordinatesystem-id
relative-coordinate-systemreference-category-code
100
POINT-REFERENCE
(f) POINT-REFERENCE
point-referenceorigin-point-id
point-reference-xvector-point-id
point-reference-y-vectorpoint-id
100
900
902
901
(g) POINT
point-id
point-category-code
701
702
RELATIVE-POINT
RELATIVE-POINT
703
RELATIVE-POINT
(h) RELATIVE-POINT
relativepoint-ycoordinatedimension
relativepoint-zcoordinatedimension
relativepoint-xprecisioncode
relativepoint-yprecisioncode
relativepoint-zprecisioncode
relativecoordinatesystem-id
relativepoint-id
relativepoint-xcoordinatedimension
701
4000
0
0
10 metre
10 metre
30 metre
100
702
703
0
4000
3000
3000
0
0
10 metre
10 metre
10 metre
10 metre
30 metre
30 metre
100
100
12.4.7.3 Second Example of RELATIVE-POINT
12.4.7.3.1 Points that had been defined in the previous Table 137 as absolute have
been re-specified in the table below as being relative to a coordinate frame defined by
Points 999, 9991, and 9992.46 These points are specified in Sub-tables (a) through (d).
They define the coordinate frame aligned east and north, as specified in Sub-tables (e) and
(f). Relative specification for the other points is shown in Sub-table (g).
Note that the same point identifiers were used for ease of cross-referencing; however,
if both absolute and relative specifications were to be stored in the same database, the relative
point identifiers would have to be different from the absolute point identifiers.
46
346
V3.1.4
Table 139. Example Instances for POINT
(a) POINT
pointid
(b) ABSOLUTE-POINT
point-categorycode
absolute
-point-id
999
ABSOLUTE-POINT
999
GEOGRAPHIC-POINT
11001
9991
9992
1812
612
3112
613
1810
777
346
ABSOLUTE-POINT
ABSOLUTE-POINT
RELATIVE-POINT
RELATIVE-POINT
RELATIVE-POINT
RELATIVE-POINT
RELATIVE-POINT
RELATIVE-POINT
RELATIVE-POINT
9991
9992
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
11001
11001
geographic
-point-id
999
9991
9992
30.360
30.360
31.000
-98.658
-98.000
-98.658
—
—
—
—
—
—
verticaldistance-id
11001
Mean sea level
200
—
—
(e) RELATIVE-COORDINATE-SYSTEM
relative-coordinate-systemreference-category-code
707
POINT-REFERENCE
(f) POINT-REFERENCE
point-referenceorigin-point-id
point-reference-xvector-point-id
point-reference-yvector-point-id
707
999
9991
9992
(g) RELATIVE-POINT
relative
-pointid
relative-pointx-coordinatedimension
relative-pointy-coordinatedimension
relative-pointz-coordinatedimension
relativepoint-xprecisioncode
relativepoint-yprecisioncode
relativepoint-zprecisioncode
relativecoordinatesystem-id
1812
612
3112
613
1810
777
346
-1234
6686
2590
7483
11528
1816
13398
55550
40000
-7777
-7777
-27775
31886
18887
0
0
156
800
800
0
800
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
Metre
707
707
707
707
707
707
707
12.4.7.3.2 The ability to specify relative points is especially useful in cases where
a geometry needs to be translated rigidly (i.e., moved without rotation in the horizontal
plane). Translation may be accomplished by simply giving new coordinates to the
reference points that define the coordinate system.
347
V3.1.4
12.5
Specification of LINE
12.5.1 Formal Specification of a LINE
12.5.1.1 A line is defined by specifying an ordered sequence of points. The
structure for specifying a LINE is illustrated in the figure below.
LOCATION
location-id
LINE
line-id (FK)
POINT
point-id (FK)
point-category-code
is-defined-using /
is-used-in-the-definition-of
P
is-used-as /
makes-reference-to
LINE-POINT
line-id (FK)
line-point-index
line-point-sequence-ordinal
line-point-point-id (FK)
Figure 99. Specification of LINE Structure
12.5.1.2 A LINE is defined as "A LOCATION that is defined by two or more
POINTs connected by one-dimensional line segments in an ordered sequence." This
concept of LINE is known as a polygonal path. If a LINE consists of a single straight
segment, it is called a line segment. LINE has only a single attribute:
line-id—The location-id of a specific LINE (a role name for location-id).
12.5.1.3 The actual definition of the line is attained by specifying its defining
points through the child entity LINE-POINT. LINE-POINT is defined as "A specification
of one of an ordered sequence of POINTs used to define the specific LINE." If the first
instance of LINE-POINT and the last instance of LINE-POINT refer to the same instance
of POINT, then the line is said to be closed (e.g., a boundary). The attributes are:
a.
line-id—The location-id of a specific LINE (a role name for location-id).
b.
line-point-index—The unique value, or set of characters, assigned to
represent a specific LINE-POINT for a specific LINE and to distinguish it
from all other LINE-POINTs for that LINE.
c.
line-point-sequence-ordinal—The integer value that indicates the relative
order of a LINE-POINT among the set of LINE-POINTs associated with a
specific LINE.
d.
line-point-point-id—The point-id of a specific POINT that is used as a
LINE-POINT in specific sequence in defining a particular LINE (a role name
for location-id).
348
V3.1.4
12.5.2 Interpretation of LINE Specifications
12.5.2.1 Proper interpretation of the meaning of LINE specifications depends on
the type of points that are used as well as the operational use of the line objects. The
purely geometric notion of lines as being "straight" is not necessarily valid when operating
in a geodetic frame of reference, such as the surface of the Earth. In other cases, a
rectilinear frame of reference may be used locally as an approximation to the surface of
the Earth. The following paragraphs discuss the implications when a line object is defined
using Cartesian, geographic, and relative points.
12.5.2.2 Line segment based on Cartesian points. These lines would normally be
used to indicate a relationship between a point on the surface of the Earth and a point in
space, such as the line-of-sight and distance to a satellite. The line segments should be
interpreted as being straight. This would also apply to line segments between two points in
space that are not shadowed by the Earth. The case of a line segment that would intersect
the geoid is left open for further definition by operational users.
12.5.2.3 Line segment based on geographic points. The use of these points
implies that the specification is intended with respect to the geodetic reference frame
defined by the surface of the Earth. Consequently, any line segment between two
geographic points is actually a curve in the normal geometric sense. To avoid the
possibility of ambiguity that could arise from interpreting line segments based on different
map projections, any line segment between a pair of geographic points at essentially the
same vertical distance is to be considered a great circle path. If the vertical distance at the
endpoints is significantly different, then the vertical projection of the segment onto the
Earth’s surface is assumed to be a great circle path and the vertical distance at any
intermediate point is linearly proportional to the path length to that point.47 If the intended
path does not conform to a great circle, then sufficient number of intermediate points and
corresponding line segments should be included in the specification of LINE to
approximate the desired path.
12.5.2.4 Line segment based on relative points. Relative offsets are measured
with respect to a rectilinear frame of reference. The frame can be tilted with respect to the
local horizontal plane. Such specification can be used for a slanted line, such as a glide
path to a runway. However, another potential use of relative geometry is to approximate
lines, such as line of bearing, with respect to one’s own position where the xy-plane is
tangent to the Earth at the reference point and normal to the local vertical. Divergence
between the tangent plane (and consequently the line) and the surface of the Earth
becomes larger as the offsets are specified at increasing distances from the reference point,
particularly in the vertical dimension. Specifically, points at 1 km from the reference point
have elevation differences of 8 cm, whereas points at 100 km from the reference point
have elevation differences of nearly 800 m.
For any line segment, if va=vertical distance at the start point, vb=vertical distance at
the end point, sT=Earth-level great circle path distance between points a and b, s=path length from
point a along the great circle path, and vs=vertical distance at s, then the vertical distance at a point
s is vs=va+(s/sT)*(vb–va).
47
349
V3.1.4
12.5.3 Business Rules for Specification of LINE
Some restrictions cannot be expressed by the diagrammatic rules of the IDEF1X
data modelling notation. The additional constraints are expressed as business rules:
a.
A line segment between a pair of GEOGRAPHIC-POINTs on the surface of
the Earth is defined to be a great circle path. A line segment between a pair
of CARTESIAN-POINTs or RELATIVE-POINTs is defined to be straight.
b.
Some uses of line entail a direction, as in axis of advance. In this case, the
instance of LINE has to be interpreted as a sequence of directed line
segments. The direction of the line is assumed to be in the ascending
enumeration of the points that define the line.
c.
Some uses of line entail a preferred side, such as forward line of own troops
(FLOT) where the symbology calls for dragon teeth on one side. When side
has meaning for a line, the left-hand side is interpreted according to the
direction of the line as determined from an ascending numeration of the
points of the line (this is referred to as the Left Hand Rule). Left-hand side is
the preferred side.
d.
The values that denote the order of the points (the attribute line-pointsequence-ordinal) in the specification of a line must begin with 1 and
increase by 1 each time. Changes to the line-point-sequence-ordinal may
alter the geometric appearance of the line.
e.
A closed LINE must start and end on the same point, that is, the first and last
values of line-point-sequence-ordinal must be associated with the same linepoint-point-id.
12.5.4 Examples of LINE Specifications
12.5.4.1 A specification of an instance of a LINE entails several instances of
LOCATION: one for the instance of LINE itself and several more for each of the points
needed in the definition. Example instances for LINE-POINT are given in the table below.
The points are re-used from a previous example to define three lines.
Table 140. Examples of LINE Instances
(a) LOCATION
location-id
1812
POINT
612
999
3112
POINT
POINT
POINT
613
1810
777
346
7001
POINT
POINT
POINT
POINT
LINE
7002
7003
LINE
LINE
350
V3.1.4
(b) GEOGRAPHIC-POINT
geographic
-point-id
1812
612
999
3112
613
1810
777
346
30.860
30.720
30.360
30.290
30.290
30.150
30.647
30.530
-98.671
-98.588
-98.658
-98.631
-98.580
-98.538
-98.639
-98.518
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(c) LINE-POINT
line-id
line-pointindex
line-point-sequenceordinal
line-pointpoint-id
7001
7001
7001
7001
7002
7002
1
2
3
4
1
3
1
2
3
4
1
3
346
613
1810
346
1812
612
7002
7002
7003
7003
7003
2
4
1
2
3
2
4
1
2
3
999
1812
3112
613
777
12.5.4.2 Line 7001 has four LINE-POINTs. The first LINE-POINT (346 with
sequence number 1) and the last LINE-POINT (346 with sequence number 4) are
identical; therefore, Line 1 is closed. Line 7002 is also closed since the first and the last
points in the sequence are the same. (It will be seen later that both Line 7001 and Line
7002 form the perimeters of specific SURFACEs.) Line 7003 has three LINE-POINTs and
is not closed. Line 7003 may be thought of as composed of two line segments, one from
Point 3112 to Point 613 and another from Point 613 to Point 777. The partial (twodimensional) geometry of these POINTs and LINEs is illustrated in the figure below.
Figure 100. An Example: Top View of Lines
351
V3.1.4
12.6
SURFACE Structures
12.6.1 Specification of SURFACE
12.6.1.1 A SURFACE is defined as "A two-dimensional LOCATION." The
model structure is illustrated in the figure below. The structure features specifications for
seven distinct geometric constructs that have been identified as requirements. Some of
these—such as polyarc, track, corridor, and orbit—stem explicitly from descriptions in the
ADatP-3 message F011 Airspace Control Order (ACO).
LOCATION
location-id
SURFACE
LINE
surface-id (FK)
line-id (FK)
constitutes-the-set-of-waypoints-for /
is-defined-using
POINT
CORRIDOR-AREA
point-id (FK)
corridor-area-id (FK)
point-category-code
corridor-area-width-dimension
corridor-area-centre-line-id (FK)
POLYGON-AREA
is-the-boundary-for /
is-used-to-define /
is-bounded-by
has-as-its-bearing-origin
polygon-area-id (FK)
polygon-area-bounding-line-id (FK)
is-part-of-the-boundary-for
POLYARC-AREA
polyarc-area-id (FK)
polyarc-area-begin-bearing-angle
polyarc-area-end-bearing-angle
polyarc-area-arc-radius-dimension
polyarc-area-defining-line-id (FK)
polyarc-area-bearing-origin-point-id (FK)
is-beginning-point-for /
is-defined-using
is-ending-point-for /
is-defined-using
TRACK-AREA
track-area-id (FK)
track-area-left-width-dimension
track-area-right-width-dimension
track-area-begin-point-id (FK)
track-area-end-point-id (FK)
FAN-AREA
fan-area-id (FK)
fan-area-minimum-range-dimension
fan-area-maximum-range-dimension
fan-area-orientation-angle
fan-area-sector-size-angle
fan-area-vertex-point-id (FK)
ELLIPSE
ORBIT-AREA
orbit-area-id (FK)
orbit-area-alignment-code
orbit-area-width-dimension
orbit-area-first-point-id (FK)
orbit-area-second-point-id (FK)
is-the-vertex-for /
is-defined-using
is-first-point-for /
is-defined-using
is-second-point-for /
is-defined-using
is-the-centre-for /
has-as-its-centre
ellipse-id (FK)
is-the-first-conjugate-point-for /
has-as-its-first-conjugate-point
ellipse-centre-point-id (FK)
ellipse-first-conjugate-diameter-point-id (FK)
ellipse-second-conjugate-diameter-point-id (FK)
is-the-second-conjugate-point-for /
has-as-its-second-conjugate-point
Figure 101. Specification of SURFACE
12.6.1.2
a.
The attributes are:
surface-id—The location-id of a specific SURFACE (a role name for
location-id).
352
V3.1.4
b.
surface-category-code—The specific value that represents the class of
SURFACE. It serves as a discriminator that partitions SURFACE into
subtypes. The domain values are: CORRIDOR-AREA; ELLIPSE; FANAREA; ORBIT-AREA; POLYARC-AREA; POLYGON-AREA; TRACKAREA.
12.6.2 Specification of SURFACE Subtypes
Each SURFACE may be one of seven subtypes: CORRIDOR-AREA, ELLIPSE,
FAN-AREA, ORBIT-AREA, POLYARC-AREA, POLYGON-AREA and TRACKAREA.
12.6.2.1
CORRIDOR-AREA
12.6.2.1.1 A CORRIDOR-AREA is defined as "A SURFACE that is defined by
its width and a sequence of points." The attributes are:
a.
corridor-area-id—The surface-id of a specific CORRIDOR-AREA (a role
b.
corridor-area-width-dimension—The one-dimensional linear distance
representing the horizontal distance measured from side to side for a
CORRIDOR-AREA and distributed equally with respect to its centreline.
c.
corridor-area-centre-line-id—The line-id of a specific LINE that defines the
central line for a specific CORRIDOR-AREA (a role name for location-id).
12.6.2.1.2 An example of CORRIDOR-AREA is illustrated in the figure below.
The centre line is an instance of LINE that is defined by five points as marked in the
figure. The width dimension is a single parameter that determines the outer boundaries of
the corridor.
Figure 102. Illustration of CORRIDOR-AREA
12.6.2.1.3 An illustration of the notional data that would be required to specify the
corridor is shown in the table below. It is called notional, because specific values for
latitude and longitude coordinates are not provided.
353
V3.1.4
Table 141. Example of Data to Specify a Corridor
(a) LOCATION
location-id
3211
POINT
3212
3213
3214
3215
3216
POINT
POINT
POINT
POINT
LINE
3217
SURFACE
geographic
-point-id
3211
3212
3213
3214
3215
30.860
30.720
30.360
30.290
30.290
-98.671
-98.588
-98.658
-98.631
-98.580
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(c) LINE-POINT
line-id
line-pointindex
line-pointpoint-id
3216
3216
3216
3216
3216
461
462
463
464
465
1
2
3
4
5
3211
3212
3213
3214
3215
(d) SURFACE
(e) CORRIDOR-AREA
surface-id
surface-categorycode
corridorarea-id
corridor-areawidth-dimension
corridor-areacentre-line-id
3217
CORRIDOR-AREA
3217
2000
3216
12.6.2.2 ELLIPSE
12.6.2.2.1 An ELLIPSE is defined as "A planar SURFACE in the form of an
ellipse." The shape of the ellipse is defined by means of three points that establish the
origin and the endpoints of the major and minor semi-axes. The attributes are:
a.
ellipse-id—The surface-id of a specific ELLIPSE (a role name for locationid).
b.
ellipse-centre-point-id—The point-id of a specific POINT that defines the
geometric centre for a specific ELLIPSE (a role name for location-id).
c.
ellipse-first-conjugate-diameter-point-id—The point-id of a specific POINT
marking the diameter on the first axis of a specific ELLIPSE (a role name for
location-id).
d.
ellipse-second-conjugate-diameter-point-id—The point-id of a specific
POINT marking the diameter on the second axis of a specific ELLIPSE (a
354
V3.1.4
Business Rule. The conjugate diameter points must be placed in such a way
that the line connecting the first conjugate diameter point to the centre point
and the line connecting the second conjugate diameter point to the centre
point must be perpendicular.
12.6.2.2.2 An example of an ELLIPSE is illustrated in the figure below using the
three defining points called for in the specification. The selection of which conjugate point
is first or second is arbitrary. Furthermore, it is immaterial whether the conjugate point is
placed on one end of an axis or the other. In this example the first conjugate point is
placed on the North end of the semi-minor axis. One could just as easily have picked an
alternate first conjugate point to be the South end of the semi-minor axis. The geometric
figure that would be generated would be exactly the same. The specification is easy to use
in that the selection of the three defining points does not leave any room for uncertainty as
to the shape and orientation of the ellipse with respect to a geographic frame of reference.
Figure 103. Illustration of ELLIPSE
ellipse is shown in the table below. It is called notional, because specific values for
Table 142. Example of Data to Specify an Ellipse
(a) LOCATION
location-id
3311
POINT
3312
3313
POINT
POINT
3314
SURFACE
geographic
-point-id
3311
3312
3313
30.860
30.720
30.360
-98.671
-98.588
-98.658
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
355
V3.1.4
(c) SURFACE
(d) ELLIPSE
surface-id
surface-categorycode
ellipse
-id
ellipse-centrepoint-id
ellipse-firstconjugatediameter-point-id
ellipse-secondconjugatediameter-point-id
3314
ELLIPSE
3314
3311
3312
3313
12.6.2.3 FAN-AREA
12.6.2.3.1 A FAN-AREA is defined as "A SURFACE that is in the form of a
truncated ring sector, lying between and being bounded by the rays emanating from the
centre point of the ring and having a specified central angle."48 This structure is useful in
describing control features such as weapon/obstacle danger templates and downwind
hazard areas in the case of CBRN operations. The attributes are:
a.
fan-area-id—The surface-id of a specific FAN-AREA (a role name for
location-id).
b.
fan-area-minimum-range-dimension—The one-dimensional linear distance
representing the distance from the vertex to the inner ring of the ring sector
used to specify the FAN-AREA.
c.
fan-area-maximum-range-dimension—The one-dimensional linear distance
representing distance from the vertex to the outer ring of the ring sector used
to specify the FAN-AREA.
d.
fan-area-orientation-angle—The rotational measurement clockwise between
the line of true north and the left side of the sector for a specific FANAREA.
e.
fan-area-sector-size-angle—The rotational measurement clockwise between
the left and right sides of the sector for a specific FAN-AREA.
f.
fan-area-vertex-point-id—The point-id of a specific POINT that defines the
vertex for the specific FAN-AREA (a role name for location-id).
48
The central angle (in polar coordinates) is measured from the fan-area-orientation-angle to the
fan-area-orientation-angle plus the fan-area-sector-size-angle. The elevation of the sector is that of
the centre point. The sector is specified by the width of the ring defined by minimum and
maximum values for the range (in polar coordinates), and the size of the central angle of the sector.
356
V3.1.4
12.6.2.3.2 The diagram in the figure below illustrates the essential characteristics
that are needed to specify a FAN-AREA.
N
Orientation
angle
sector-size angle
(central angle)
Maximum range dimension
Minimum range dimension
vertex
E
Figure 104. Illustration of FAN-AREA Specification
12.6.2.3.3 Example instances for FAN-AREA are illustrated in the table below.
Sub-tables (a), (b), (c), and (d) repeat data from a previous table for those POINTs that
serve as references in defining FAN-AREAs. Sub-table (e) is the data for SURFACE (the
supertype of FAN-AREA) table. Sub-table (f) shows that FAN-AREA 4 has a vertex at
Point 612 and covers a 90 degree sector beginning at 45 degrees (Northeast) and ending at
135 degrees north (Southeast) and is therefore centred at 90 degrees and oriented
eastward. FAN-AREA 6 has a vertex at Point 999 and also has a 90-degree "span"
between 315 degrees (Northwest) and 405 degrees (Northeast), which is equivalent to 45
degrees; therefore, Surface 6011 is oriented in a northerly direction.
Table 143. Example Instances of a FAN-AREA
(a) POINT
(b) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
612
999
ABSOLUTE-POINT
ABSOLUTE-POINT
612
999
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
11001
11001
geographic
-point-id
612
999
30.720
30.360
-98.588
-98.658
1/10 minute
1/10 minute
1/10 minute
1/10 minute
verticaldistance-id
11001
Mean sea level
200
10 m
—
(e) SURFACE
surface-id
4
6
FAN-AREA
FAN-AREA
357
V3.1.4
(f) FAN-AREA
fan-area-id
fan-areaminimum-rangedimension
fan-areamaximum-rangedimension
fan-areaorientationangle
fan-areasector-sizeangle
fan-areavertexpoint-id
4
6
10,000
50,000
100,000
250,000
45
315
90
90
612
999
12.6.2.3.4 The examples specified in the previous table are illustrated graphically
in the figure below.
Surface 4
Surface 6
45º
100.000
10.000
612
90°
Figure 105. Two Examples of FAN-AREA
12.6.2.4 ORBIT-AREA
12.6.2.4.1 An ORBIT-AREA is defined as "A SURFACE that is (a) an open
rectangular section defined by its width and the distance between the two specific
POINTs, (b) is closed by two half-circles with radii equal to half the width, and is
positioned left, centred, or right with respect to the line formed by the defining points."
The attributes are:
a.
orbit-area-id—The surface-id of a specific ORBIT-AREA (a role name for
location-id).
b.
orbit-area-alignment-code—The specific value that represents the placement
of a specific ORBIT-AREA with respect to its defining reference axis. The
domain values are: Centre; Left; Right.
c.
orbit-area-width-dimension—The
one-dimensional
linear
distance
representing the horizontal distance measured from side to side for a specific
ORBIT-AREA.
d.
orbit-area-first-point-id—The point-id of a specific POINT that defines the
initial point of an axis for a specific ORBIT-AREA (a role name for locationid).
e.
orbit-area-second-point-id—The point-id of a specific POINT that defines
the final point of an axis for a specific ORBIT-AREA (a role name for
location-id).
358
V3.1.4
12.6.2.4.2 An example of ORBIT-AREA is illustrated in the figure below. The
first and second points establish a centre line that constitutes a reference for placing the
orbit—left, centred or right. All three possibilities are shown in the figure. Width
dimension provides the remaining critical parameter for specifying an orbit. The arcs at
the beginning and end of the orbit have radii that are equal to half of the width.
Width
Left orbit
Centre line
First point
Second point
Centre orbit
Right orbit
Figure 106. Illustration of ORBIT-AREA
orbit is shown in the table below. It is called notional, because specific values for latitude
and longitude coordinates are not provided.
Table 144. Example of Data Entries to Specify an Orbit
(a) LOCATION
location-id
5511
POINT
5512
5514
POINT
SURFACE
(b) POINT
(c) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
5511
5512
ABSOLUTE-POINT
ABSOLUTE-POINT
5511
5512
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
5577
5577
(d) GEOGRAPHIC-POINT
geographic
-point-id
5511
5512
30.720
30.360
-98.588
-98.658
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(e) VERTICAL-DISTANCE
verticaldistance-id
5577
Pressure datum
standard atmosphere
8000
100 metre
—
359
V3.1.4
(f) SURFACE
(g) ORBIT-AREA
surface-id
surfacecategory-code
orbitarea-id
orbit-areaalignmentcode
orbit-areawidthdimension
orbit-areafirst-pointid
orbit-areasecond-pointid
5514
ORBIT-AREA
5514
Left
10000
5511
5512
12.6.2.5 POLYGON-AREA
12.6.2.5.1 A POLYGON-AREA is defined as "A SURFACE that has its
boundaries defined by a specific LINE." An example is a planar area whose boundary is in
the form of an ordered sequence of line segments that begin and end at the same point
(closed polygonal path). The attributes are:
a.
polygon-area-id—The surface-id of a specific POLYGON-AREA (a role
b.
polygon-area-bounding-line-id—The line-id of a specific closed LINE that
constitutes the boundary for a specific POLYGON-AREA (a role name for
location-id).
12.6.2.5.2 An example of POLYGON-AREA is illustrated in the figure below.
The bounding line is defined by the sequence of points from 1 to 7.
Figure 107. Illustration of POLYGON-AREA in a Plane
12.6.2.5.3 An example of two POLYGON-AREAs is given in the table below.
Sub-table (a) shows the six points, two lines, and two surfaces. The points are specified in
Sub-tables (b) through (e). The bounding lines are specified in Sub-table (f). The surfaces
are specified in Sub-table (g). The association of bounding lines with the surfaces being
defined are specified in Sub-table (h). The vertices of bounding Line 666 for Surface 682
are Points 346, 613, and 1810. Similarly, Surface 694 is defined by means of association
with Line 675 as its boundary. The vertices of Line 675 are specified in LINE-POINT as
Points 1812, 612 and 999.
360
V3.1.4
Table 145. Examples of POLYGON-AREA
(a) LOCATION
location-id
1812
POINT
612
999
613
1810
346
POINT
POINT
POINT
POINT
POINT
666
675
682
694
LINE
LINE
SURFACE
SURFACE
(b) POINT
(c) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
1812
612
999
613
1810
346
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
1812
612
999
613
1810
346
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
11001
11001
11001
11003
11003
11003
geographic
-point-id
1812
612
999
613
1810
346
30.860
30.720
30.360
30.290
30.150
30.530
-98.671
-98.588
-98.658
-98.580
-98.538
-98.518
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(e) VERTICAL-DISTANCE
verticaldistance-id
11001
11002
11003
Mean sea level
Mean sea level
Mean sea level
200
356
1000
10 m
1m
10 m
—
—
—
(f) LINE-POINT
line-id
line-pointindex
666
1
1
346
666
666
666
675
675
2
3
4
1
3
3
2
4
1
3
1810
613
346
1812
612
675
675
2
4
2
4
999
1812
361
line-pointpoint-id
V3.1.4
(g) SURFACE
surface-id
682
694
POLYGON-AREA
POLYGON-AREA
(h) POLYGON-AREA
polygon-area-id
polygon-area-bounding-line-id
682
694
666
675
12.6.2.5.4 Surface 694 is a triangle at an elevation of 200 metres and Surface 682
is a triangle at an elevation of 1000 metres. Geometry of the two POLYGON-AREAs is
illustrated in the figure below. The upper triangle is Surface 682 and the lower triangle is
Surface 694.
(346)
(613)
(1810)
1000
(1812)
(612)
31.00
500
(999)
30.75
30.50
200
30.25
30.00
-98.7
-98.6
-98.5
Figure 108. Illustration of POLYGON-AREAs in 3-D
12.6.2.6 POLYARC-AREAs
12.6.2.6.1 A POLYARC-AREA is defined as "A SURFACE that consists of a
circular arc and a polygonal segment defined by a specific LINE whose beginning
coincides with the initial point of the arc and whose end coincides with the last point of the
arc." The attributes are:
a.
polyarc-area-id—The surface-id of a specific POLYARC-AREA (a role
b.
polyarc-area-begin-bearing-angle—The rotational measurement clockwise
from true North to the left side of a horizontal conical section used in
defining a specific POLYARC-AREA.
c.
polyarc-area-end-bearing-angle—The rotational measurement clockwise
from true North to the right side of a horizontal conical section used in
defining a specific POLYARC-AREA.
362
V3.1.4
d.
polyarc-area-arc-radius-dimension—The one-dimensional linear distance
representing the distance from the vertex to the ring sector used to define part
of a specific POLYARC-AREA.
e.
polyarc-area-defining-line-id—The line-id of a specific LINE that is used to
define part of a specific POLYARC-AREA (a role name for location-id).
f.
polyarc-area-bearing-origin-point-id—The point-id of a specific POINT that
specifies the origin for bearing angles that define an arch for a specific
POLYARC-AREA (a role name for location-id).
12.6.2.6.2 An example of POLYARC-AREA is illustrated in the figure below.
The "poly" part is the polygonal line defined by Points 1 through 5. The "arc" part is the
circular arc from "Begin bearing" to "End bearing."
Figure 109. Illustration of POLYARC-AREA
polyarc area is shown in the table below. It is called notional, because specific values for
Table 146. Example of Data Entries to Specify a Polyarc
(a) LOCATION
location-id
8811
POINT
8812
8813
8814
8900
8901
POINT
POINT
POINT
LINE
SURFACE
8903
POINT
363
V3.1.4
(b) POINT
(c) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
8811
ABSOLUTE-POINT
8811
GEOGRAPHIC-POINT
—
8812
8813
8814
8903
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
8812
8813
8814
8903
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
—
—
—
—
geographic
-point-id
8811
8812
8813
8814
8903
30.860
30.720
30.360
30.290
30.290
-98.671
-98.588
-98.658
-98.631
-98.580
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(e) LINE-POINT
line-id
line-pointindex
line-pointpoint-id
8900
8900
8900
8900
17
203
73
14
1
2
3
4
8811
8812
8813
8814
(f) SURFACE
surface-id
8901
POLYARC-AREA
(g) POLYARC-AREA
polyarcarea-id
polyarc-areabegin-bearingangle
polyarc-areaend-bearingangle
polyarc-areaarc-radiusdimension
polyarc-areadefining-lineid
polyarc-areabearing-originid
8901
100
255
5000
8900
8903
12.6.2.7 TRACK-AREAs
12.6.2.7.1 A TRACK-AREA is defined as "A SURFACE that is a rectangular
section with its length defined by the two specific POINTs and its width by the sum of the
widths to the left and right of the connecting line between the two points." The attributes
are:
a.
track-area-id—The surface-id of a specific TRACK-AREA (a role name for
location-id).
b.
track-area-left-width-dimension—The one-dimensional linear distance
representing the horizontal distance to the left measured orthogonally to the
reference axis for a specific TRACK-AREA.
c.
track-area-right-width-dimension—The one-dimensional linear distance
representing the horizontal distance to the right measured orthogonally to the
reference axis for a specific TRACK-AREA.
364
V3.1.4
d.
track-area-begin-point-id—The point-id of a specific POINT that defines the
initial point of a reference axis for a specific TRACK-AREA (a role name
for location-id).
e.
track-area-end-point-id—The point-id of a specific POINT that defines the
final point of a reference axis for a specific TRACK-AREA (a role name for
location-id).
12.6.2.7.2 An example of TRACK-AREA is illustrated in the figure below. The
connecting line is defined by the "Begin point" and "End point." The separate
specifications for width dimension are measured to the left and right of the connecting
line.
Left width
Right width
Begin point
End point
Figure 110. Illustration of TRACK-AREA
track area is shown in the table below. It is called notional, because specific values for
Table 147. Example of Data Entries to Specify a Track
(a) LOCATION
location-id
9331
POINT
9332
9400
POINT
SURFACE
(b) POINT
(c) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
9331
9332
ABSOLUTE-POINT
ABSOLUTE-POINT
9331
9332
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
—
—
geographic
-point-id
9331
9332
30.860
30.720
-98.671
-98.588
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(e) SURFACE
surface-id
9400
TRACK-AREA
365
V3.1.4
(f) TRACK-AREA
trackarea-id
track-area-leftwidth-dimension
track-area-rightwidth-dimension
track-areabegin-point-id
track-areaend-point-id
9400
15000
10000
9331
9332
12.6.3 Additional Constraints in Specifying SURFACE
Some restrictions cannot be expressed by the diagrammatic rules of the IDEF1X
data modelling notation. The additional constraints are expressed as business rules:
a.
When an instance of LINE is used as a boundary in defining an instance of
SURFACE, either side of the boundary line could be construed to be the area
bounded by the line. The rule adopted for this model is that the inside of the
boundary line is on the left-hand side. Thus, if a polygon is traversed in
counter clockwise direction (according to the values in line-point-sequenceordinal), then the included area is inside the polygon. If the polygon is
traversed in a clockwise direction, then the included area is outside the
polygon.
b.
If a boundary line is a complex figure in three-dimensional space, such as a
figure-eight, by the previous rule the line could include all area. To avoid
such possibilities, it is required that a boundary line shall be specified in such
a way that its projection onto a horizontal plane does not intersect itself.
c.
In creating the specification for ELLIPSE, the conjugate diameter points
must be placed in such a way that the line connecting the first conjugate
diameter point to the centre point and the line connecting the second
conjugate diameter point to the centre point must be perpendicular.
d.
SURFACES that are defined using CARTESIAN-POINTs or RELATIVEPOINTs at the same vertical distance are considered to be geometrically flat
planes. SURFACEs that are defined using GEOGRAPHIC-POINTs at the
same vertical distance are to be considered as approximately conforming to
the geoid in curvature. Further constraints are not specified pending the
development of operational requirements.
12.6.4 Specification of Vertical Distance for Surfaces
12.6.4.1 The specification of vertical distances for instances of SURFACE
admits several possibilities. If the instance of SURFACE is to be used to specify a planar
geometry (and not as an intermediate step in a specification of volume geometry), then the
rules in the table below apply.
Table 148. Rules for VERTICAL-DISTANCE Use with Geometry
Surface Geometry
Defining Geometry
Rule for Vertical Distance
CORRIDOR-AREA
Centre line (multiple points)
Same vertical distance specification;
planar surface
ELLIPSE
Three points
planar surface
FAN-AREA
Single point
Planar surface
366
V3.1.4
ORBIT-AREA
Two points
planar surface
POLYARC-AREA
Polygonal line (multiple points)
Origin point for arc
planar surface
POLYGON-AREA
Bounding line (multiple points)
As appropriate
TRACK-AREA
Two points
planar surface
12.6.4.2 The relationship between VERTICAL-DISTANCE and ABSOLUTEPOINT enables a simple approach to assuring that the vertical distance specification is
identical for any set of points: the same value of absolute-point-vertical-distance-id should
be entered in each of the point records.
12.7
GEOMETRIC-VOLUME
12.7.1 Specification of GEOMETRIC-VOLUME
12.7.1.1 The structure for specifying GEOMETRIC-VOLUME is illustrated in
the figure below. The three major subtypes specify geometry for cone, sphere, and
cylinder whose horizontal shape is defined by an instance of SURFACE. A
GEOMETRIC-VOLUME is defined as "A specific LOCATION that is a threedimensional bounded space." This is a useful construct in describing the geometry of
control features such as air corridors, surface to air missile coverage zones, and no fly
zones.
12.7.1.2
The attributes are:
a.
geometric-volume-id—The location-id
VOLUME (a role name for location-id).
b.
geometric-volume-category-code—The specific value that represents the
class of GEOMETRIC-VOLUME. It serves as a discriminator that partitions
GEOMETRIC-VOLUME into subtypes. The domain values are: CONEVOLUME; SPHERE-VOLUME; SURFACE-VOLUME.
c.
geometric-volume-lower-vertical-distance-id—The vertical-distance-id of a
specific VERTICAL-DISTANCE that defines the altitude or height of the
lower level for a specific GEOMETRIC-VOLUME (a role name for verticaldistance-id).
d.
geometric-volume-upper-vertical-distance-id—The vertical-distance-id of a
specific VERTICAL-DISTANCE that defines the altitude or height of the
upper level for a specific GEOMETRIC-VOLUME (a role name for verticaldistance-id).
367
of
a
specific
GEOMETRIC-
V3.1.4
LOCATION
VERTICAL-DISTANCE
vertical-distance-id
location-id
vertical-distance-reference-code
vertical-distance-dimension
vertical-distance-precision-code
vertical-distance-datum-text
POINT
bounds-on-the-top
point-id (FK)
bounds-on-the-bottom
point-category-code
GEOMETRIC-VOLUME
geometric-volume-id (FK)
geometric-volume-lower-vertical-distance-id (FK)
geometric-volume-upper-vertical-distance-id (FK)
SURFACE
surface-id (FK)
SPHERE-VOLUME
is-the-centre-for /
has-as-its-centre
sphere-volume-id (FK)
sphere-volume-radius-dimension
sphere-volume-centre-point-id (FK)
CONE-VOLUME
is-the-vertex-for /
has-as-its-vertex
cone-volume-id (FK)
cone-volume-defining-surface-id (FK)
cone-volume-vertex-point-id (FK)
is-used-to-define /
is-defined-using
SURFACE-VOLUME
surface-volume-id (FK)
is-used-to-define /
is-defined-using
surface-volume-defining-surface-id (FK)
Figure 111. Specification of GEOMETRIC-VOLUME
12.7.1.3
Some examples of volumes are the following:
a.
A general cylinder, which may be defined by the vertical projection of a
specific area with horizontal planes bounding its top and bottom;
b.
A sphere that may be truncated by horizontal boundary planes at the top and
bottom;
c.
A cone that may be truncated by horizontal boundary planes at the top and
bottom.
12.7.2 CONE-VOLUMEs
12.7.2.1 A CONE-VOLUME is defined as "A GEOMETRIC-VOLUME whose
boundary is swept by a line that has a fixed point and another that moves along the path
defined by the border of a specific SURFACE." If the closed path is the boundary of a
circle and the vertex is on a line perpendicular to the plane of the circle, the CONEVOLUME will be a right circular cone.
368
V3.1.4
12.7.2.2 The specification of CONE-VOLUME requires identification of a point
that serves as its vertex and a reference area whose boundary generates the surface of the
cone. This is achieved by a mandatory non-identifying relationship ("is the vertex for/has
as its vertex") between POINT and CONE-VOLUME and a second mandatory nonidentifying relationship ("is used to define/is defined using") between SURFACE and
CONE-VOLUME. The attributes are:
a.
cone-volume-id—The geometric-volume-id of a specific CONE-VOLUME
(a role name for location-id).
b.
cone-volume-defining-surface-id—The surface-id of a specific SURFACE
that is the defining cross-section for a specific CONE-VOLUME (a role
c.
cone-volume-vertex-point-id—The point-id of the specific POINT that is the
vertex of a specific CONE-VOLUME (a role name for location-id).
12.7.2.3 A notional CONE-VOLUME is illustrated in the figure below. The
reference area is the specific SURFACE that is used to generate the cone. The cone may
originate at the vertex and be unbounded. It can also be truncated at either the bottom or
the top by using the lower and upper bounds specified in GEOMETRIC-VOLUME as
foreign keys migrated through non-identifying relationships from VERTICALDISTANCE.
12.7.2.4 The SURFACE used to specify a CONE-VOLUME does not have to be
a circle or an ellipse. It can be any instance of SURFACE. Thus, a CONE-VOLUME does
not have to be restricted to regular cones. For example, if the instance of SURFACE
happens to be a rectangle, the instance of CONE-VOLUME could be a pyramid.
Figure 112. Illustration of CONE-VOLUME
12.7.3 SPHERE-VOLUMEs
12.7.3.1 A SPHERE-VOLUME is defined as "A GEOMETRIC-VOLUME that
has its horizontal boundaries defined by the spherical surface determined by the radius and
the specified POINT." The attributes are:
a.
sphere-volume-id—The geometric-volume-id of a specific SPHEREVOLUME (a role name for location-id).
369
V3.1.4
b.
sphere-volume-radius-dimension—The one-dimensional linear distance
representing the radius from the centre that defines the surface for a specific
SPHERE-VOLUME.
c.
sphere-volume-centre-point-id—The point-id of a specific POINT that
defines the centre for a specific SPHERE-VOLUME (a role name for
location-id).
12.7.3.2 An example of SPHERE-VOLUME is illustrated in Figure 113
following the discussion of SURFACE-VOLUME.
12.7.4 SURFACE-VOLUMEs
A SURFACE-VOLUME is defined as "A GEOMETRIC-VOLUME that has its
horizontal boundaries defined by a specific SURFACE." The attributes are:
a.
surface-volume-id—The geometric-volume-id of a specific SURFACEVOLUME (a role name for location-id).
b.
surface-volume-defining-surface-id—The surface-id of a specific SURFACE
that defines the horizontal boundaries for a specific SURFACE-VOLUME (a
12.7.5 Examples of GEOMETRIC-VOLUMEs
12.7.5.1 Example instances for GEOMETRIC-VOLUME are presented in the
table below. The table specifies two general cylinders (Geometric Volume 1 and
Geometric Volume 4) and a hemisphere (Geometric Volume 2).
a.
Geometric Volume 1 (id=13801) and Geometric Volume 4 (id=13809) are
based on the same instance of SURFACE and have the same ground-level
projection—namely, Surface 682, which is a triangular POLYGON-AREA
defined by the bounding line 666 (Sub-tables (f) and (g)). The two volumes
result from two different pair of altitude levels (Sub-tables (h) and (i)).
b.
Geometric Volume 2 (id=13807) is a sphere limited by elevations of 200 and
5,200 metres (from Sub-tables (h) and (i)). The radius of the sphere is 5,000
metres (from Sub-table (j)). The centre point (POINT 777) has elevation of
200 metres (from Sub-tables (c) and (h)). Thus, Geometric Volume 2 is a
sphere with a radius of 5,000 metres centred at a point with an elevation of
200 metres and bounded by horizontal planes at elevations of 200 and 5,200
metres. This is simply a hemisphere that has a radius of 5,000 metres. (It
might represent the coverage associated with a "search radar" located at
POINT 777.)
370
V3.1.4
Table 149. Examples of GEOMETRIC-VOLUME
(a) LOCATION
location-id
613
POINT
1810
777
346
666
682
POINT
POINT
POINT
LINE
SURFACE
13801
13807
13809
GEOMETRIC-VOLUME
GEOMETRIC-VOLUME
GEOMETRIC-VOLUME
(b) POINT
(c) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
613
1810
777
346
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
ABSOLUTE-POINT
613
1810
777
346
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
GEOGRAPHIC-POINT
—
—
12012
—
geographic
-point-id
613
1810
777
346
30.290
30.150
30.647
30.530
-98.580
-98.538
-98.639
-98.518
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
1/10 minute
(e) LINE-POINT
line-id
line-pointindex
line-pointpoint-id
666
1
1
346
666
666
666
2
3
4
2
3
4
613
1810
346
(f) SURFACE
surface-id
682
POLYGON-AREA
(g) POLYGON-AREA
polygon-area-id
polygon-area-bounding-line-id
682
666
(h) VERTICAL-DISTANCE
verticaldistance-id
12012
12013
13001
13002
13003
13004
Mean sea level
Mean sea level
Mean sea level
Mean sea level
Mean sea level
Mean sea level
200
5200
1000
3000
6000
8000
—
—
—
—
—
—
—
—
—
—
—
—
371
V3.1.4
(i) GEOMETRIC-VOLUME
geometric-volume-id
geometric-volumecategory-code
geometric-volumelower-verticaldistance-id
geometric-volumeupper-verticaldistance-id
13801 [Geometric Volume 1]
SURFACE-VOLUME
SPHERE-VOLUME
SURFACE-VOLUME
13001
12012
13003
13002
12013
13004
(j) SPHERE-VOLUME
sphere-volume-id
sphere-volume-radiusdimension
sphere-volumecentre-point-id
13807
5000
777
(k) SURFACE-VOLUME
12.7.5.2
surface-volume-id
surface-volume-defining-surface-id
13801
13809
682
682
Geometric illustrations of the examples are illustrated in the figure
below.
8000
6000
5200
G
etric
eom
me 4
Volu
5000
3000
777
200
346
613
1000
5000
ric
1810 eomet
G
me
Volu
1
0
Geometric Volume 2
Figure 113. Examples of GEOMETRIC-VOLUME
12.7.6 Specification of Vertical Distance for Volumes
If a surface geometry serves only as an intermediate specification for volume
geometry, then there may not be a need to specify vertical distance for any of the points.
Any instance of GEOMETRIC-VOLUME may have an upper and a lower vertical
distance specified for it. These act as parallel cutting planes to limit the volume.
Specification of operational geometry, such as corridors, orbits, and tracks, include such
limits. However, it is conceivable that unusual circumstances may dictate a specification
of a volume whose upper (or lower) bound may be defined through an instance of
SURFACE and the other bound by the cutting plane in GEOMETRIC-VOLUME.
372
V3.1.4
12.7.7 Specification of Vertical Distance for "Point" and "Line" Volumes
12.7.7.1 The operational requirements that influenced the development of
LOCATION structure specify a need for assigning lower and upper vertical distances for
control features that are geometrically described as points or lines. It could be a contact
point or a coordination line with imposed lower and upper flight levels. Such specification
requires the concepts of "point-volume" and "line-volume."
12.7.7.2 A "point-volume" can be specified by creating a vertical line. Two
points need to be defined having the same longitude and latitude (or relative) coordinates
but assigned different vertical distances. The points would then be used to create an
instance of LINE.
12.7.7.3 A "line-volume" can be specified by creating a vertical surface. A set of
points needs to be defined to correspond to the desired line in the horizontal dimension
with vertical distance set to lower level. Then another set of corresponding points needs to
be defined with vertical distance set to upper level. The result would be a paired set of
points with each pair having the same coordinates but different vertical distances. The
points would then have to be connected as a closed polygonal line starting with the first
lower point, progressing to the last lower point, moving to the last upper point, progressing
to the first upper point, and finally closing the line at the first lower point. The resulting
line would then be used as a bounding line in the definition of an instance of POLYGONAREA. This creates a vertical surface that may be thought of as a sheet of paper on edge.
12.8
Relating LOCATIONs to OBJECT-ITEMs
12.8.1 Specification of OBJECT-ITEM-LOCATION
12.8.1.1 The model construct relates OBJECT-ITEM to LOCATION through
the associative entity OBJECT-ITEM-LOCATION. The overall view for associating
objects with LOCATION is illustrated in the figure below. OBJECT-ITEM-LOCATION
has a mandatory non-identifying relationship to REPORTING-DATA. A subtype of
REPORTING-DATA features the attributes reporting-data-absolute-timing-effectivestart-datetime and reporting-data-absolute-timing-effective-end-datetime that permits the
specification of either starting or ending times, or the dwell time of any instance of
OBJECT-ITEM at any location.
373
V3.1.4
OBJECT-ITEM
object-item-id
LOCATION
location-id
is-geometrically-defined-through
provides-geometric-definition-for
object-item-id (FK)
location-id (FK)
object-item-location-index
object-item-location-vertical-accuracy-dimension
object-item-location-horizontal-accuracy-dimension
object-item-location-bearing-angle
object-item-location-bearing-accuracy-angle
object-item-location-bearing-precision-code
object-item-location-inclination-angle
object-item-location-inclination-accuracy-angle
object-item-location-inclination-precision-code
object-item-location-speed-rate
object-item-location-speed-accuracy-rate
object-item-location-speed-precision-code
object-item-location-meaning-code
object-item-location-relative-speed-code
Figure 114. Specification of OBJECT-ITEM-LOCATION
12.8.1.2 The entity OBJECT-ITEM-LOCATION is defined as "An association
of an OBJECT-ITEM with a LOCATION that enables the geographic position of the
OBJECT-ITEM to be specified. The operational meaning of geometry may also be
specified." The attributes are:
a.
b.
location-id—The unique value, or set of characters, assigned to represent a
specific LOCATION and to distinguish it from all other LOCATIONs.
c.
object-item-location-index—The unique value, or set of characters, assigned
to represent a specific OBJECT-ITEM-LOCATION for a specific OBJECTITEM and a specific LOCATION and to distinguish it from all other
OBJECT-ITEM-LOCATIONs for that OBJECT-ITEM and that
LOCATION.
d.
object-item-location-vertical-accuracy-dimension—The
one-dimensional
linear distance representing the uncertainty in terms of probable error range
for the vertical axis of a specific OBJECT-ITEM-LOCATION.
e.
object-item-location-horizontal-accuracy-dimension—The one-dimensional
linear distance representing the uncertainty in the horizontal plane in terms of
probable circular error for a specific OBJECT-ITEM-LOCATION.
374
V3.1.4
f.
object-item-location-bearing-angle—The rotational measurement clockwise
from the line of true North to the direction of motion in the horizontal plane
of a specific OBJECT-ITEM at a specific LOCATION.
g.
object-item-location-bearing-accuracy-angle—The rotational measurement
of a sector that represents the uncertainty range in the estimate of the bearing
at a specific OBJECT-ITEM-LOCATION. The sector is bisected by the
bearing.
h.
object-item-location-bearing-precision-code—The specific value that
represents the maximum resolution used for the expression of a bearing
angle. Example domain values are: 1/10 Second; Degree; Mil; Minute. The
and is defined in the set angle-precision-code.
i.
object-item-location-inclination-angle—The rotational measurement from
the horizontal plane to the direction of motion of a specific OBJECT-ITEM
at a specific LOCATION (point or shape), where the positive angle is
vertically upward.
j.
object-item-location-inclination-accuracy-angle—The
rotational
measurement of a vertical sector that represents the uncertainty range in the
estimate of the inclination at a specific OBJECT-ITEM-LOCATION. The
sector is bisected by the inclination.
k.
object-item-location-inclination-precision-code—The specific value that
represents the maximum resolution used for the expression of an inclination
angle. Example domain values are: 1/10 second; Degree; Mil; Minute. The
and is defined in the set angle-precision-code.
l.
object-item-location-speed-rate—The numeric value that denotes the motion
of a specific OBJECT-ITEM at a specific LOCATION in terms of distance
per unit time. The unit of measure is kilometres per hour. The specified value
must be greater than or equal to 0 (zero).
m.
object-item-location-speed-accuracy-rate—The numeric value that denotes
the uncertainty range in the estimate for the speed at a specific OBJECTITEM-LOCATION where the speed estimate falls at the centre of the
accuracy range. The unit of measure is kilometres per hour. The specified
value must be greater than or equal to 0 (zero).
n.
object-item-location-speed-precision-code—The
specific
value
that
represents the maximum resolution used for the expression of speed. The
and is defined in the set speed-precision-code. The domain values are:
Knots; Kilometres per hour; Metres per second.
o.
object-item-location-meaning-code—The specific value that represents the
meaning of the LOCATION geometry as it pertains to the OBJECT-ITEM.
The domain values are: Association with command post; Centre of mass;
Centre of mass (automated derivation); Commander determined; Line of
bearing; Shape; Sounding.
375
V3.1.4
p.
object-item-location-relative-speed-code—The specific value that represents
the speed of the object relative to its normal speed. The domain values are:
Fast; Medium; No speed; Slow.
q.
REPORTING-DATAs.
12.8.1.3 Four domain values for object-item-location-meaning-code are intended
to handle position reporting for objects that may be deployed over an extensive area, such
as military formations. An object is normally reported to be at a point position that
represents the aggregate of all its components. The four options are represented by the
following values:
a.
Association with command post—The point representing the location of the
ORGANISATION is the same as that of its command post.
b.
Centre of mass—A point representing the mean position of an OBJECTITEM.
c.
Centre of mass (automated derivation)—A point representing the mean
position of an OBJECT-ITEM. It is calculated by automated means.
d.
Commander determined—A point representing the position of an OBJECTITEM in accordance to criteria specified by competent authority.
12.8.1.4 The domain value "Shape" for object-item-location-meaning-code
indicates that the geometry specified in LOCATION represents a two- or threedimensional configuration of an object. Its primary use is likely to be for instances of
FACILITY. The domain value "Sounding" indicates the depth of water within the
geometry specified in LOCATION. The geometry is most likely to be a single point;
however, it could also be an area. The use of the domain value "Line of bearing" is
illustrated in the following example.
12.8.2 An Example: Specifying Line of Bearing
12.8.2.1 The domain value "Line of bearing" in object-item-location-meaningcode may be used to record the direction to an observed (possibly unknown) object by a
detecting platform. This could apply to any detection technique such as radar tracking,
electronic or communications intercepts, sonar tracking or optical observation. The data
for specifying line of bearing can be represented by the geometry of FAN-AREA using the
observer’s position as the vertex for the fan and centering the fan on the line of bearing.
The sector-size angle for the fan represents the precision with which the line of bearing
can be established. The minimum range dimension is set to zero and the maximum range
dimension is left null to indicate an open fan. The geometry is illustrated in the figure
below.
376
V3.1.4
toward
observed
object
N
FAN-AREA
observer
E
Figure 115. Illustration for Line of Bearing
12.8.2.2 The following example postulates that 37th Surveillance Squadron (in
the form of one of its aircraft) detects an emission. Two instances of OBJECT-ITEM play
a role: the observer and the unknown object that is emitting. The table below contains the
data for this example. Sub-tables (a) define the object instances. Sub-tables (b) define the
geometry for the two objects: point geometry for the observer and fan-area geometry for
the observed object. FAN-AREA 4 has a vertex at Point 612 (observer point) and covers a
3-degree sector centred at 45 degrees (Northeast). The nominal line of bearing is directed
at 45 degree orientation with respect to true North with uncertainty of 1-1/2 degrees to
either side. Sub-table (c) assigns the appropriate geometry to the correct object.
Table 150. Line of Bearing Example
(a1) OBJECT-ITEM
object-item-id
3201
2200
ORGANISATION
Unknown
37th Surveillance Squadron
VHF emission
(a2) ORGANISATION
(a3) UNIT
organisationid
organisationcategory-code
unit-id
unit-formal-abbreviatedname-text
3201
UNIT
3201
37SSQ
(b1) LOCATION
(b2) POINT
location-id
612
4
POINT
SURFACE
(b3) ABSOLUTE-POINT
pointid
point-categorycode
absolute
-point-id
612
ABSOLUTE-POINT
612
GEOGRAPHIC-POINT
—
377
V3.1.4
(b4) GEOGRAPHIC-POINT
geographic
-point-id
612
30.720
-98.588
1/10 minute
1/10 minute
(b5) SURFACE
surface-id
4
FAN-AREA
(b6) FAN-AREA
fan-area-id
fan-areaminimum-rangedimension
fan-areamaximum-rangedimension
fan-areaorientationangle
fan-areasector-sizeangle
fan-areavertexpoint-id
4
0
—
45
3
612
(c) OBJECT-ITEM-LOCATION
objectitem-id
locatio
n-id
3201
2200
612
4
***-index
*-verticalaccuracydimension
*-horizontalaccuracydimension
*-bearingangle
*-speedrate
*-meaningcode
reportingdata-id
1
1
100
10
100
10
330
—
340
—
—
Line of bearing
8400
8400
Note: * = "object-item-location"
12.9
The Use of Value "Undefined" for location-category-code
12.9.1 The value "Undefined" for location-category-code has a special purpose
since it has no geometric content. Its use may indicate that:
a.
The location of an object is simply unknown.
b.
The operator does not wish to enter a specific location at the given time (for
example, prior to commitment of forces to an operation).
c.
The location of a tracked object has been lost. In the latter case, the status of
"Undefined" indicates the most current valid operational data and remains in
that status until and if the location of the tracked object has been reestablished.
12.9.2 The relationship of OBJECT-ITEM-LOCATION with REPORTINGDATA is necessary to provide the effective time for "Undefined" as the most current
operational status.
12.10 Relating LOCATIONs to ACTIONs
The specification is presented in Chapter 17 (Section 16.10).
12.11 Business Rules
12.11.1 General rules for specifying LOCATION to assure consistency and
proper interpretation are specified in Annex G1, Section G1.8.1.
12.11.2 Specific uses of OBJECT-ITEM-LOCATION are specified in Annex
G1, Section G1.8.2.
378
V3.1.4
12.11.3 Geometry that can be associated with an instance of OBJECT-ITEM is
restricted according to its type classification. The specific rules are specified in Annex G2,
Section G2.9.
12.11.4 Valid geometries to be used in representing activity or event symbology
are specified in Annex G2, Section G2.9.
379
V3.1.4
(This page intentionally left blank)
380
V3.1.4
13. REPORTING-DATA AND REFERENCE
13.1
Introduction
13.1.1 REPORTING-DATA
13.1.1.1 Considerable amount of information about an operational situation
consists of reports by persons or organisations. These generally refer to dynamic data,
such as location, status, holdings, associations, and classification, regardless of whether
the information refers to friendly, neutral, or hostile elements. It is also important to know
for each report the source, the effective and reporting datetimes, and the degree of validity
of information. If information is provided without an indication of the source, the validity,
and the applicable times, it raises questions as to the source (Who says so?), the quality (Is
this information verified?), and timing (When did it happen and when was this reported?).
The model can capture both types of information: the substantive information is
represented in numerous entities and the amplifying reporting information in
REPORTING-DATA structure.
13.1.1.2 REPORTING-DATA structure provides a mechanism for maintaining a
time record that applies not only to the historical past and the immediate present, but also
to the future. Thus, it is just as easy to record that the planned stockage level of an
ammunition stock should be 10,000 three days from now as it is to record that the reported
stockage level yesterday was 8,200.
13.1.1.3 Effective datetimes in REPORTING-DATA can be made relative to
planned activity. For example, a unit may be given a mission with a starting time of DDay and H-Hour. The effective time for relevant dynamic data can then be expressed
relative to the starting time of activity, e.g. D+1.
13.1.1.4 Specifications for REPORTING-DATA structure are presented in
Sections 13.2 through 13.6.
13.1.2 REFERENCE
13.1.2.1
It is useful to be able to cite sources of information that are external
to the data structures. The sources may be written operations plans, ADatP-3 messages,
printouts of electronic mail, memoranda of telephone conversations, and other physical
storage means. They may provide essential information that is not stored in a database.
The means for this functionality is an independent entity REFERENCE.
13.1.2.2
The information cited in an instance of REFERENCE may be
linked to instances of ACTION, CAPABILITY, OBJECT-ITEM, OBJECT-TYPE, and
REPORTING-DATA as well as other instances of REFERENCE. It is also possible to
indicate the role that any instance of an organisation exercises with respect to an instance
of REFERENCE through a separate association.
13.1.2.3
with Section 13.7.
Specifications for REFERENCE structure are presented beginning
381
V3.1.4
13.2
REPORTING-DATA Structure
The functions required of the REPORTING-DATA concept entail the specification
of absolute times as well as relative times. The absolute and relative time characteristics
are captured in a subtype hierarchy consisting of REPORTING-DATA-ABSOLUTETIMING and REPORTING-DATA-RELATIVE-TIMING, respectively. The resultant
structure is the REPORTING-DATA entity with its subtyping, as illustrated in the figure
below.
REFERENCE
REPORTING-DATA
reference-id
reporting-data-id
reference-id (FK)
is-amplified-by
REPORTING-DATA-ABSOLUTE-TIMING
reporting-data-absolute-timing-reporting-data-id (FK)
reporting-data-absolute-timing-effective-start-datetime
reporting-data-absolute-timing-effective-end-datetime
REPORTING-DATA-RELATIVE-TIMING
reference-approval-datetime
reference-content-category-code
reference-creation-datetime
reference-description-text
reference-electronic-source-text
reference-file-size-quantity
reference-format-text
reference-language-code
reference-lifecycle-code
reference-medium-type-code
reference-originator-text
reference-physical-size-text
reference-primary-location-text
reference-publication-datetime
reference-releasability-text
reference-security-classification-code
reference-short-title-text
reference-title-text
reference-transmittal-type-code
reference-validity-period-begin-datetime
reference-validity-period-end-datetime
reference-verification-code
reference-version-text
reporting-data-relative-timing-reporting-data-id (FK)
reporting-data-relative-timing-offset-duration
reporting-data-relative-timing-reference-action-task-id (FK)
serves-as-timing-reference-for /
uses-as-timing-reference
ACTION
action-id
action-name-text
OBJECT-ITEM
object-item-id
is-reported-by
ORGANISATION
ACTION-TASK
action-task-id (FK)
action-task-activity-code
action-task-minimum-duration
action-task-estimated-duration
action-task-maximum-duration
action-task-planned-start-datetime
action-task-start-qualifier-code
action-task-planned-end-datetime
action-task-end-qualifier-code
action-task-priority-code
action-task-entailed-safety-degree-code
action-task-overt-covert-code
action-task-detail-text
action-task-timing-day-code
action-task-timing-hour-code
action-task-meteorological-impact-code
action-task-operational-level-code
candidate-target-list-id (FK)
Figure 116. Specification of REPORTING-DATA Structure
382
V3.1.4
13.2.1 The REPORTING-DATA Entity
13.2.1.1 REPORTING-DATA is defined as "The specification of source, quality
and timing that applies to reported data." The attributes are:
49
a.
REPORTING-DATAs.
b.
reporting-data-accuracy-code—The specific value that represents, for
intelligence purpose, the general appraisal of the subject matter in graded
terms to indicate the extent or degree to which it has been judged to be free
from mistake or error or to conform to truth or some recognised standard
value. The domain values are: Confirmed; Doubtful; Improbable; Possible;
Probable; Truth cannot be judged.
c.
reporting-data-category-code—The specific value that represents, for usual
operational purposes, the nature of a specific REPORTING-DATA. The
domain values are: Assumed; Erroneous; Inferred; Planned; Predicted;
Reported.49
d.
reporting-data-counting-indicator-code—The specific value that denotes
whether the data referred to by a specific REPORTING-DATA is based on a
count of objects. The domain values are: No; Yes. Note: The intent is to
provide assurance to the recipient that the number reported was obtained
through an inventory and is not merely a guess or an estimate.
e.
reporting-data-credibility-code—The specific value that represents, for
normal operational use, the degree of trustworthiness of the data referenced
by a specific REPORTING-DATA. The domain values are: Indeterminate;
Reported as a fact; Reported as plausible; Reported as uncertain.
f.
reporting-data-reliability-codeThe specific value that represents, for
intelligence purpose, the general appraisal of the source in graded terms to
indicate the extent to which it has been proven it can be counted on or trusted
in to do as expected. The domain values are: Completely reliable; Fairly
reliable; Not usually reliable; Reliability cannot be judged; Unreliable;
Usually reliable.
g.
reporting-data-reporting-datetimeThe character string representing a point
in time that designates when the data referenced by the REPORTING-DATA
is provided.
h.
reporting-data-source-type-codeThe specific value that identifies the
source type from which intelligence information is obtained and which is
referred to by a specific REPORTING-DATA. Example domain values are:
Air reconnaissance; Captured material; Electronic intelligence; Prisoner of
war; Unattended ground sensor.
i.
reporting-data-timing-category-code—The specific value that represents the
absolute, uncertain or relative timing for a specific REPORTING-DATA. It
serves as a discriminator that partitions REPORTING-DATA into subtypes.
Use of the domain value "Erroneous" is shown in Section 13.6.
383
V3.1.4
The domain values are: REPORTING-DATA-ABSOLUTE-TIMING;
REPORTING-DATA-RELATIVE-TIMING; Timing not available.
j.
reporting-data-real-data-exercise-use-only-code—The specific value that
determines whether a specific REPORTING-DATA refers to real data in an
exercise scenario. The domain value is: Real.
k.
reference-id—The unique value, or set of characters, assigned to represent a
specific REFERENCE and to distinguish it from all other REFERENCEs.
l.
reporting-data-reporting-organisation-id—The
identifier
of
the
ORGANISATION that is responsible for providing the data that is
referenced by the specific REPORTING-DATA (a role name for objectitem-id).
13.2.1.2 All the information kept with the REPORTING-DATA entity is
qualified with its category-code that states its nature, with its accuracy-code that denotes
whether the data has been corroborated by an independent second source, with its
credibility-code that represents the degree of trustworthiness for the data and with its
reliability-code that represents the general appraisal of the source to indicate the extent to
which it has been proven it can be counted on or trusted to do as expected. These attributes
are needed to make appropriate use of the data.
13.2.1.3 The attribute reporting-data-timing-category-code is used either to
point to absolute or relative timing subtype entities where the appropriate timing data is
entered or to indicate that timing data is not available. The latter case is likely to arise
from reporting observations of status, location, activity, events or other information where
the observer cannot ascertain neither the effective start nor end time. This would be
especially appropriate in cases of spot reports where the observation period would be
limited, such as episodic glimpsing of an opposing force. The same may hold true for an
observer of a natural or a political event where the observer simply chances to note an
activity, such as flooding or rioting. In cases where the value of reporting-data-timingcategory-code is set to "Timing not available" the recommended procedure is to use
reporting-data-reporting-datetime since that is the only effective time that is available.
13.2.1.4 REPORTING-DATA features an attribute ent_cat_code at the physical
level only. It aids system developers in finding the entity to which REPORTING-DATA
refers in order to retrieve information that is to be associated with a given CONTEXT (as
described in next chapter). In its absence, the systems would be forced to search all tables
that have a relationship to REPORTING-DATA.
13.2.1.5 The linking of an instance of REPORTING-DATA to one or more
records should be viewed as a single fact that remains permanent. No copies of the records
of the records already linked to an instance of REPORTING-DATA should be made
because such practice would violate operational logic represented in the design of data
specifications.
13.2.2 REPORTING-DATA-ABSOLUTE-TIMING
13.2.2.1 REPORTING-DATA-ABSOLUTE-TIMING is defined as "A
REPORTING-DATA that specifies effective datetime that is referenced to Universal
384
V3.1.4
Time." Universal Time is Greenwich time calculated from midnight at the Greenwich
meridian. The purpose of this entity is to enable a specification of effective datetime in
absolute terms for any data referenced by an instance of REPORTING-DATA. The
specified epoch can be in the past, the present, or the future. The attributes are:
a.
reporting-data-absolute-timing-reporting-data-id—The reporting-data-id of a
specific REPORTING-DATA-ABSOLUTE-TIMING (a role name for
reporting-data-id).
b.
reporting-data-absolute-timing-effective-start-datetime—The character string
representing a point in time that designates the beginning of the period of
effectiveness for the data referenced by a specific REPORTING-DATAABSOLUTE-TIMING.
c.
reporting-data-absolute-timing-effective-end-datetime—The character string
representing a point in time that designates the ending of the period of
effectiveness for the data referenced by a specific REPORTING-DATAABSOLUTE-TIMING.
13.2.2.2 It is expected that the start and end datetimes would be used
individually in most cases. If both are used for the same instance of REPORTING-DATA,
then the same value of reporting-data-category-code must apply to both. For example, if
an actual event is reported, then both starting and ending times must be prior to the current
time. If the applicable values of reporting-data-category-code are different, then two
instances of REPORTING-DATA must be specified.
13.2.2.3 The values of reporting-data-category-code can be considered to
belong to one of two classifications: factual and nonfactual. Factual refers to data that is
to be interpreted as actual or real includes; the classification includes the values
"Reported" and "Inferred." Nonfactual refers to data that cannot be assumed to be actual or
real; the classification includes the values "Assumed," "Planned," and "Predicted." 50Any
instance of dynamic data reported as nonfactual remains nonfactual even when the real
clock time is later than the starting or ending time. If the status actually changes as
postulated in any nonfactual category, then a new instance of status must be created with
an instance of REPORTING-DATA in the factual category. For example, if a minefield is
predicted to be inactivated at a given time, an updated status must be specified to record
the actual inactivation.
13.2.3 REPORTING-DATA-RELATIVE-TIMING
REPORTING-DATA-RELATIVE-TIMING is defined as "A REPORTINGDATA that specifies effective timing that is referenced to a specific ACTION-TASK."
Relative timing makes operational sense only in relation to planned activities;
consequently, the origin of the time scale is established in relation to an instance of
ACTION-TASK. The attributes are:
The present discussion does not apply to the value "Erroneous" of reporting-datacategory-code that has a specialised role.
50
385
V3.1.4
a.
reporting-data-relative-timing-reporting-data-id—The reporting-data-id of a
specific REPORTING-DATA-RELATIVE-TIMING (a role name for
reporting-data-id).
b.
reporting-data-relative-timing-offset-duration—The numeric value that
represents a quantity of time in milliseconds from a given reference for a
specific REPORTING-DATA-RELATIVE-TIMING.
c.
reporting-data-relative-timing-reference-action-task-id—The action-task-id
of a specific ACTION-TASK that serves as the origin for the time scale of a
specific REPORTING-DATA-RELATIVE-TIMING (a role name for actionid). The initial point of ACTION-TASK constitutes the reference.
13.2.4 Entry of Timing Data
13.2.4.1 The intent of datetime in REPORTING-DATA is to represent
operational information and not necessarily system information. The meaning of effective
datetime in REPORTING-DATA-ABSOLUTE-TIMING is unambiguous: it is the actual
time when something was seen or counted or status assessed or when something is
supposed to happen in the future.
13.2.4.2 The issue with reporting datetime in REPORTING-DATA is not as
clear. In a manual system it would mean when did the information become available at the
first echelon to which the report would be made. This could be made immediately by
combat net radio or it would be the time at which a combat patrol returns to its parent unit
because it had to maintain radio silence while on patrol. It may even be delayed by the
need to process photographic film. In an automated system the answer would seem to
depend on rules that the operational user chooses to enforce. One option is to enforce the
manual datetime. However, an argument could be made that the information is not
available to the user of an automated system until it is entered into the system. In the latter
case, using system datetime as a default seems reasonable. Lowest level echelons may not
be equipped with automated systems, so there may be a delay in moving the information
to an echelon that has an automated system. The process can be accelerated if the lower
echelons use digital entry devices (DEDs) that can input the information directly.
13.2.4.3 One of the values for reporting-data-timing-category-code is "Timing
not available." Use of this value is justified only in case when observations of events or
other data for which neither starting nor ending effective time can be determined. The
reasonable option in that case is to use reporting time since that is the only real
information that is available and it represents the effective observation time. Any use of
REPORTING-DATA that entails information about one’s own forces should always have
an effective time (starting time, in most cases, or possibly intervals with both starting and
ending times).
13.3
REPORTING-DATA in Relation to Other Entities
13.3.1 The primary function of REPORTING-DATA structure is to provide
amplifying information related to dynamic data. It can specify a past or future time when a
piece of dynamic information is perceived to be valid, its general quality or reliability, its
source, and its reporting datetime. This type of amplifying information allows a staff
386
V3.1.4
officer to compare different reports and make a sensible interpretation of the data. It also
allows the staff officer to enter his own perception of reality based upon the raw data; this
may be particularly applicable to the intelligence function that may produce new
correlated information at a higher quality level.
13.3.2 The non-identifying relationships that REPORTING-DATA has to other
entities in the model is illustrated in the figure below 51. These are generally referred to as
dynamic, since the information to be recorded in these entities is expected to be more
subject to change than that represented in reference data (such as OBJECT-TYPE).
REPORTING-DATA is linked to most of these entities through a non-identifying
relationship "provides applicable information for." Each relationship requires that a record
in REPORTING-DATA be created for every new piece of dynamic information. The
linked entries include:
a.
Classification of OBJECT-ITEMs, held in the OBJECT-ITEM-TYPE entity.
b.
Friend-foe-neutral indication for OBJECT-ITEMs, held in the OBJECTITEM-STATUS entity.
c.
Operational status of individual OBJECT-ITEMs, held in the OBJECTITEM-STATUS entity and its subtypes.
d.
Position and geometry are accessed through OBJECT-ITEM-LOCATION
entity.
e.
Status and quantities of OBJECT-TYPEs in the possession of OBJECTITEMs, maintained in the HOLDING entity.
f.
Status of associations between pairs of OBJECT-ITEMs of different
categories, held in the STATUS entities related to OBJECT-ITEM
association entities (total of 11).
g.
Various addresses that may be used to contact an object, provided through
OBJECT-ITEM-ADDRESS.
h.
Actual capabilities of individual OBJECT-ITEMs, held in the OBJECTITEM-CAPABILITY entity.
i.
Status of subtypes of ACTION, held in the ACTION-TASK-STATUS and
ACTION-EVENT-STATUS entities.
j.
Amplifying information about instances of EVENTs, provided through
ACTION-EVENT-DETAIL.
k.
Results of activities—completed, in progress, or future desired, reported
through ACTION-EFFECT.
l.
Anticipated protective posture of target personnel, specified through
TARGET-PERSONNEL-PROTECTION.
m.
Creation of lists of candidate targets, specified through CANDIDATETARGET-LIST structure.
REPORTING-DATA has an identifying relationship to CONTEXT-REPORTINGDATA-ASSOCIATION. Its specification and use is discussed in Chapter 14.
51
387
V3.1.4
n.
Authorisation of candidate targets, held in the CANDIDATE-TARGETLIST-AUTHORISATION
and
CANDIDATE-TARGET-DETAILAUTHORISATION entities.
o.
Responses to REQUESTs that are recorded as REQUEST-ANSWERs.
13.4
Business Rule for REPORTING-DATA
A business rule for the use of REPORTING-DATA is specified and explained in
Annex G1, Section G1.9.
ACTION-COMMENT
ACTION-EFFECT
ACTION-EVENT-DETAIL
ACTION-EVENT-STATUS
ACTION-TASK-STATUS
ACTION-LOCATION
CANDIDATE-TARGET-LIST-AUTHORISATION
CANDIDATE-TARGET-DETAIL-AUTHORISATION
HOLDING
HOLDING-TRANSFER
OBJECT-ITEM-ADDRESS
OBJECT-ITEM-AFFILIATION
REPORTING-DATA
OBJECT-ITEM-COMMENT
OBJECT-ITEM-GROUP-ACCOUNT
OBJECT-ITEM-STATUS
OBJECT-ITEM-TYPE
NETWORK-SERVICE-STATUS
REQUEST-ANSWER
TARGET-PERSONNEL-PROTECTION
Figure 117. REPORTING-DATA and Its Relationships to Dynamic Data
13.5
An Example of REPORTING-DATA Usage
13.5.1 This section presents an extended example in the use of REPORTINGDATA in connection with six other entities that contain dynamic information. The table
below consists of a group of instance tables. An instance of REPORTING-DATA may be
referred to by one or more instances of dynamic data, but only from within a single table.
If a unit submits a unit report by entering a number of records in different tables that
together comprise the contents of the report, then as many instances of REPORTINGDATA must be created as there are tables. Such may be the case with Reporting Data 01,
Reporting Data 0111 and Reporting Data 011, reported by 2 (SP) Cav Bde.
388
V3.1.4
13.5.2 Reporting Data 01 is referred to by one record in OBJECT-ITEM-STATUS
[Table 151 (b)] that specifies the status of Item 0122, the 9th Cavalry Regiment52.
Actually, the substantive status information would be found in the table
ORGANISATION-STATUS that is not shown here. Reporting Data 0111 is referred to by
one record in OBJECT-ITEM-HOSTILITY-STATUS [Table 151 (c)] that specifies the
hostility status of Item 0122, the 9th Cavalry Regiment.
13.5.3 Reporting Data 011 is referred to by three records in HOLDING [Table 151
(d)]. These records specify the holdings of the units 0122, 0129, and 0345. It can be seen
from the HOLDING entity that object-item 0122 has a total of 1000 items of the type 0312
and all of them are operational. The same kind of information can be determined about
items 0129 and 0345.
13.5.4 Reporting Data 02 provides metadata about the specification of command
relationships in OBJECT-ITEM-ASSOCIATION (Sub-table (e1)) through the associative
entity OBJECT-ITEM-ASSOCIATION-STATUS (Sub-table (e2)). Unit 0345 is under full
command of unit 0129 and unit 0129 is under full command of unit 0122. Since the two
records in OBJECT-ITEM-ASSOCIATION-STATUS have the same reporting-data-id
both have been reported at the same time by the same organisation, and have the same
effective datetimes.
13.5.5 Reporting Data 03 provides metadata about the unit’s own report about its
position; this is item 0122 (the Spanish Cavalry Regiment) in Sub-table (f) with point-id
10552.
13.5.6 The 9th Spanish Cavalry Regiment reports the presence of an enemy unit
(object-item 0332). The instances of REPORTING-DATA have been given the numbers
04, 041, and 042. Reporting Data 04 is referred to in Table 151 (f) for the position of the
enemy unit (point-id 11892); Reporting Data 041 in Table 151 (g) for its classification by
type (object-type-id 035), and Reporting Data 042 in Table 151 (c) for its hostility status
(Hostile).
13.5.7 Reporting Data 05 is associated with the classification of object-item 0331
in Sub-table (g). Reporting Data 07 refers to the determination of the hostility status (Subtable (c)) for the same object-item by another unit.
13.5.8 The 4th Armd Regt reports under Reporting Data 06 an enemy unit (objectitem-id 0333) to be at a position identified by point-id 11893. In the same report, this
object has also been classified as type 035 in Table 151 (g) (referred to by Reporting Data
061) and as hostile in Table 151 (c) (referred to by Reporting Data 062).
13.5.9 NATO Corps G-2 reports the estimated position, bearing angle, and speed
of object-item 0332 in Sub-table (f), as indicated by Reporting Data 08.
13.5.10 Reporting Datas 051 and 052 indicate the desired position for objectitems 0532 and 0533 in Sub-table (f) as specified by the 2nd (SP) Cavalry Brigade.
52
While there is no instance table of OBJECT-ITEM, the identity of this unit can be determined
by looking at the reporting organisation of Reporting Data 04.
389
V3.1.4
Table 151. Example REPORTING-DATAs and Related Dynamic Information
(a) REPORTING-DATA53
*-id
*-accuracy- *-category*-countingcode
code
indicator-code
*-credibility-code
*-reliability-code
01
Possible
Reported
—
Reported as plausible
Completely reliable
0111
011
02
03
04
041
042
05
06
061
062
07
08
051
052
Possible
Possible
Possible
Possible
—
—
Doubtful
—
—
—
Improbable
—
—
—
—
Reported
Reported
Reported
Reported
Reported
Reported
Reported
Reported
Reported
Reported
Reported
Reported
Reported
Planned
Planned
—
No
—
—
—
—
—
—
—
—
—
—
—
—
—
Reported as uncertain
Indeterminate
Indeterminate
Indeterminate
—
—
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Completely reliable
Fairly reliable
(null)
(null)
REPORTING-DATA (continued)
*-sourcetype-code
20051201090000.000
—
Absolute
—
—
[2 (SP) CAV BDE]
20051201090000.000
20051201090000.000
20051201090000.000
20051201090000.000
20051202104500.000
—
—
—
—
—
Absolute
Absolute
Absolute
Absolute
Absolute
—
—
—
—
—
—
—
—
—
—
[2 (SP) CAV BDE]
[2 (SP) CAV BDE]
[2 (SP) CAV BDE]
[2 (SP) CAV BDE]
0122 [9 Cavalry Rgt]
20051202104500.000
20051202104500.000
—
Eyeball
observation
Absolute
Absolute
—
—
—
01
20051202122500.000
20051202164000.000
20051202164000.000
20051202164000.000
—
—
—
Eyeball
observation
—
—
—
—
Absolute
Absolute
Absolute
Absolute
—
—
—
—
—
—
—
02
[11 Cavalry Rgt]
[4 Armd Rgt]
[4 Armd Rgt]
[4 Armd Rgt]
Absolute
Absolute
Absolute
Absolute
—
—
—
—
—
—
—
—
[NATO Corps G-2]
[2 (SP) CAV BDE]
[2 (SP) CAV BDE]
20051202104500.000
20051203053000.000
20051204150000.000
20051204150000.000
*-timing*-real-data-exercise- reference
category-code
use-only-code
-id
53
390
V3.1.4
(b) REPORTING-DATA-ABSOLUTE-TIMING
**-effective-start-datetime54
01
0111
011
02
dt1 < dt11
dt1 < dt11
dt1 < dt11
dt1 < dt11
—
—
—
—
03
04
041
042
05
dt2 < dt11
dt3 <dt12
dt3 <dt12
dt3 <dt12
dt4 >dt13
—
—
—
—
—
06
061
062
07
08
051
052
dt5 <dt14
dt5 <dt14
dt5 <dt14
dt6 >dt12
dt88
dt21
dt22
—
—
—
—
—
—
—
(c) OBJECT-ITEM-STATUS
objectitem-id
object-itemstatus-emissioncontrol-code
reporting
-data-id
0122
027
ORGANISATION-STATUS
EMCON 3
01
(d) OBJECT-ITEM-HOSTILITY-STATUS
objectitem-id
object-item-hostilitystatus-index
object-item-hostilitystatus-code
reporting
-data-id
0122
0332
0333
0331
027
1
2
1
Friendly
Hostile
Hostile
Assumed friendly
0111
042
062
07
(e) HOLDING
objectitem-id
objecttype-id
holdingindex
holding-operationalcount
holding-totalquantity
reportingdata-id
0122
0129
0345
0312
0341
0427
01
04
02
1000
500
20
1000
600
30
011
011
011
(f) OBJECT-ITEM-ASSOCIATION
***-subject-objectitem-id
***-object-objectitem-id
***-index
***-category-code
***-subcategorycode
0122
0129
0129
0345
06
01
Command and control
Command and control
Has full command of
Has full command of
54
The symbols < and > indicates the relative timing of related reports.
391
V3.1.4
(g) OBJECT-ITEM-ASSOCIATION-STATUS
****-subjectobject-item-id
****-objectobject-item-id
****-index
****-associationstatus-index
****-categorycode
reportingdata-id
0122
0129
0129
0345
06
01
1
1
Start
Start
02
02
Note: **** = "object-item-association"
(h) OBJECT-ITEM-LOCATION
objectitem-id
locationid
*****index
*****-horizontalaccuracydimension
*****bearingangle
*****speed-rate
0332
11892
01
100
30º
40
04
0333
0224
0122
0332
0532
11893
22893
10552
22153
31212
01
01
027
01
01
100
1000
—
100
—
45
—
—
30
—
60
—
—
40
—
06
06
03
08
051
0533
31213
01
—
—
—
052
reportingdata-id
Note: ***** = "object-item-location"
(i) OBJECT-ITEM-TYPE
object-item-id
object-type-id
reporting-data-id
0331
0332
0333
0147
035
035
03
01
01
05
041
061
13.5.11 To some extent the REPORTING-DATA entity also provides a means
to keep related pieces of information together by using the same reporting-data-id (and
indeed the same meta information) as a pointer to more than one piece of dynamic data
within the same table.
13.5.12 Not all elements of information, however, can be linked using the same
reporting-data-id. In general, different pieces of dynamic information receive different
reporting-data-ids because the meta information associated is different (for example, any
of the values for effective datetime, reporting datetime, credibility code, or reporting
organisation are different). This implies that not all of the contents of reports and returns
can be reproduced on the basis of a single reporting-data-id. A mechanism for such linking
is described in Chapter 14.
13.6
Example of Using REPORTING-DATA to Indicate Erroneous Information
13.6.1 An operational unit reports its position at a given time. The G-3 staff
realises later that the wrong position has been reported by mistake and wishes to negate
the reported location by indicating that the data is invalid or erroneous. The mechanism
that the data specification provides is to enter a second record for the position report but
link it to a second record in REPORTING-DATA with the value "Erroneous" in the
reporting-data-category-code.
13.6.2 The data for the example is shown in the table below. Sub-table (a)
identifies the unit that is reporting its own position. Sub-table (b) links the reporting unit
with a specification of LOCATION that has the value of 51 for its identifier. The location
data is not shown but it can be assumed to be a geographic point. Sub-tables (c) and (d)
392
V3.1.4
specify the appropriate entries in REPORTING-DATA tables. The unit reported its
position on 5 November 2003 at 1035 hours with effective datetime at 5 November 2003
1025 hours. It realised its mistake 30 minute later and entered another record in Sub-table
(b) for the same instance of OBJECT-ITEM (the unit) and the same instance of
LOCATION ( identifier 51), but a different value for object-item-location-index and a
different value for reporting-data-id. The second instance of REPORTING-DATA in Subtables (c) and (d) now carries the value "Erroneous" in reporting-data-category-code, has
a new reporting time (30 minutes after the original report), but uses the original values for
start datetime.
Table 152. An Example to Negate False Information
(a) OBJECT-ITEM
object-item-id
78128
ORGANISATION
1 Bn 2 (US) Inf Bde
(b) OBJECT-ITEM-LOCATION
object-item-id
location-id
object-itemlocation-index
reporting-data-id
78128
78128
51
51
1
2
5403
5404
(c) REPORTING-DATA
*-id
*-categorycode
5403
Reported
5404
Erroneous
*-credibilitycode
*-reportingdatetime
*-timingcategory-code
[Absolute]
78128
[Absolute]
78128
Reported as a 200311051035
fact
00.000
fact
00.000
5403
5404
20031105102500.000
20031105102500.000
—
—
13.6.3 This technique should be used only when correct data is not provided as a
subsequent entry. If subsequent correct entry is available, then a better procedure is to use
the CONTEXT structure explained in the next chapter to link the correct entry to the
incorrect entry.
13.7
REFERENCE for External Information
13.7.1 REFERENCE is defined as "Identification of a record of information." The
structure of REFERENCE and its relationships to ACTION, CAPABILITY, OBJECTITEM, OBJECT-TYPE, ORGANISATION, and itself is illustrated in the figure below 55.
The information that instances of REFERENCE point to can be used to amplify or support
the data in one or more instances of the associated entities. The entity REFERENCE-
55
The relationship of REFERENCE to REPORTING-DATA is shown in the previous
figure.
393
V3.1.4
ASSOCIATION enables the recording of relationships between instances of
REFERENCE. In addition, the entity ORGANISATION-REFERENCE-ASSOCIATION
identifies the administrative role that any instance of databased ORGANISATION has
with respect to an instance of REFERENCE. Note that the organisational roles internal to
documents cited in REFERENCE are identified in one of the attributes of REFERENCE.
REFERENCE
reference-id
is-the-subject-of
is-the-object-of
ACTION
reference-association-subject-reference-id (FK)
reference-association-object-reference-id (FK)
reference-association-index
action-id
action-name-text
reference-association-category-code
applies-to
OBJECT-TYPE
action-id (FK)
reference-id (FK)
object-type-id
action-reference-association-category-code
action-reference-association-part-text
applies-to
object-type-id (FK)
reference-id (FK)
object-type-reference-association-category-code
OBJECT-ITEM
object-item-id
applies-to
object-item-id (FK)
reference-id (FK)
object-item-reference-association-index
object-item-reference-association-category-code
object-item-reference-association-specific-part-text
reference-id (FK)
organisation-reference-association-index
is-administered-by
organisation-reference-association-category-code
organisation-reference-association-start-datetime
ORGANISATION
is-reported-by
REPORTING-DATA
is-amplified-by
reporting-data-id
capability-id (FK)
reference-id (FK)
applies-to
capability-reference-association-category-code
provides-to
CAPABILITY
capability-id
reference-id (FK)
Figure 118. Specification of REFERENCE Structure
13.7.2 The attributes for REFERENCE are:
a.
b.
reference-approval-datetime—The character string representing a point in
time that designates the date when the artefact that is cited in a specific
REFERENCE was approved.
c.
reference-content-category-code—The specific value that represents the
classification of the general content of the artefact cited in a specific
REFERENCE. Example domain values are: Authorisation; Directive; Health
document; Map; Order; Technical document; Template.
394
V3.1.4
d.
reference-creation-datetime—The character string representing a point in
time that designates the creation date for the artefact cited in a specific
REFERENCE.
e.
reference-description-text—The character string assigned to represent a
description of the artefact cited in a specific REFERENCE. This field may
be used to provide additional information about a REFERENCE, such as
International standard book number when applicable.
f.
reference-electronic-source-text—The character string assigned to represent
the electronic source of the artefact cited in a specific REFERENCE.
g.
reference-file-size-quantity—The numeric value that represents the size of an
electronic version of the artefact cited in a specific REFERENCE. The unit
of measure is kilobyte.
h.
reference-format-text—The character string assigned to represent the data
format of the artefact cited in a specific REFERENCE.
i.
reference-language-code—The specific value that identifies the language
used in the artefact cited in a specific REFERENCE. Example domain values
are: Danish; Dutch; French; Norwegian; Spanish. The domain value set for
set language-category-code.
j.
reference-lifecycle-code—The specific value that represents the lifecycle of
the artefact cited in a specific REFERENCE. The domain values are: Draft;
Final; Obsolete.
k.
reference-medium-type-code—The specific value that represents the type of
medium of the artefact cited in a specific REFERENCE. Example domain
values are: Electronic file, network; Film; Magnetic tape; Not known.
l.
reference-originator-text—The character string assigned to represent the
identity of the originator of the artefact cited in a specific REFERENCE.
m.
reference-physical-size-text—The character string assigned to represent the
size of a physical version of the artefact cited in a specific REFERENCE.
n.
reference-primary-location-text—The character string assigned to represent
the identity of the primary physical or electronic location of the artefact cited
in a specific REFERENCE.
o.
reference-publication-datetime—The character string representing a point in
time that designates the date of publication for the artefact cited in a specific
REFERENCE.
p.
reference-releasability-text—The character string assigned to represent the
releasability restrictions for the artefact cited in a specific REFERENCE.
q.
reference-short-title-text—The character string assigned to represent an
abbreviated title or name of the artefact cited in a specific REFERENCE.
r.
reference-title-text—The character string assigned to represent the name of
the artefact cited in a specific REFERENCE.
s.
reference-transmittal-type-code—The specific value that represents the
means by which the artefact cited in a specific REFERENCE is transmitted
to the recipient. Example domain values are: Courier message; E-mail
395
V3.1.4
message; Phone message; Radio message; Secure fax message; Not known;
t.
reference-validity-period-begin-datetime—The character string representing
a point in time that designates the beginning of the period of validity for the
content in the artefact cited in a specific REFERENCE.
u.
reference-validity-period-end-datetime—The character string representing a
point in time that designates the end of the period of validity for the content
in the artefact cited in a specific REFERENCE.
v.
reference-verification-code—The specific value that represents the
verification of the artefact cited in a specific REFERENCE. The domain
values are: Reference unverified; Reference verification not available;
Reference verified.
w.
reference-version-text—The character string assigned to represent the
identification of the version of the artefact cited in a specific REFERENCE.
x.
13.7.3 A variety of examples are illustrated in the table below. There are
references to an e-mail message, a transcript of a report over combat net radio, a facsimile
sent over a secure line, a printed report by a UN commission, a NATO dictionary, a book
on data modelling, and others. Any of these can be linked to information in a database
through the relationship that REFERENCE has to other entities.
Table 153. Examples of REFERENCE
(a) SECURITY-CLASSIFICATION
*-id
*-level-code
*-policy-text
**-caveat-text
sc100
sc101
sc102
Confidential
Secret
Unclassified
NATO
NATO
NATO/EAPC
sc103
Unclassified
Nation
Releasable to NATO
Releasable to NATO
Releasable to NATOEAPC
—
sc104
Unclassified
Nation
—
396
V3.1.4
(b) REFERENCE (first of three)
**-id
**approval
datetime
**contentcategorycode
301
—
Report
102
—
Report
567
—
Report
890
—
Report
123
456
—
—
660
6
2001102
5000000.
000
—
Guidance
Technical
document
Guidance
987
Directive
**electronic
-sourcetext
**-filesizequantity
**formattext
**language
-code
Potential
terrorist
activity
Sighting of
enemy
position
Communicati
ons status for
7th Division
—
24
Microsoft
Word
English
Final
—
—
Text
Turkish
Final
—
—
Text
French
Final
—
—
—
Text
English
Final
—
—
—
—
1320
—
pdf
Text
English
English
Final
Final
—
—
—
Text
English
Final
—
—
—
Text
English
Draft
—
—
—
Text
English
Final
**creationdatetime
**descriptiontext
20040812
000000.0
00
20040714
000000.0
00
20040911
000000.0
00
20040700
000000.0
00
—
—
20010516
000000.0
00
20040729
000000.0
00
20040730
000000.0
00
**lifecyclecode
990
2004080
1000000.
000
Order
771
3
123
4
—
Guidance
—
—
—
—
Text
English
Final
2003110
1000000.
000
2003110
1000000.
000
Technical
document
20031100
000000.0
00
20031100
000000.0
00
—
https://mip
site.lsec.d
nd.ca
https://mip
site.lsec.d
nd.ca
4800
pdf
English
Final
2700
pdf
English
Final
—
Technical
document
Technical
document
—
Description of
APC
Description of
signal
equipment
—
—
Text
English
Final
—
—
Text
English
Final
123
5
442
2
443
3
—
Technical
document
—
—
Note: ** = "reference"
397
V3.1.4
(b) REFERENCE (second of three)
**physicalsize-text
**publication
-datetime
**releasabili
ty-text
**-shorttitle-text
Division
G-3
—
—
IGR-725
1 page
Battalion
S-3
—
—
SR-291
3 pages
Division G-6
—
—
COMSITREP
45 pages
Corps
Document
Repository
200410000
00000.000
—
—
NATO MAS
—
—
200012000
00000.000
Releasable
AAP-06
547 pages
—
—
49 pages
—
Releasable
STANAG 2211
987
Paper-based
HQ 3rd Division
60 pages
2nd Bde G-3
Paper-based
HQ 3rd Division
62 pages
2nd Bde G-3
Div and bde
staffs only
Div
personnel
only
OPLAN 04-17
990
199200000
0000.000
200110250
00000.000
200407300
00000.000
200408010
00000.000
—
Paper-based
Thomas A.
Bruce
NIMA
7713
Paper-based
430 pages
1234
—
Air Force
Materiel
Command
MIP DMWG
492 pages
287th Fighter
Sqn Ready
Room
—
1235
—
MIP DMWG
538 pages
4422
Paper-based
HQ TRADOC
4433
Paper-based
HQDA
**-mediumtype-code
**-originatortext
301
Electronic file,
detached
physical storage
2nd Intelligence
Group
—
102
Paper-based
567
Paper-based
890
Paper-based
FO Capt
Ertugrul
7th Signal
Battalion
UN
Commission on
Human Rights
123
Electronic file,
detached
physical storage
456
Paper-based
6606
**-id
**-primarylocation-text
OPORD 04-17
197206160
00000.000
—
TO-1-1F-111D1
200312190
00000.000
—
C2IEDM-MainUS-DMWGEdition6.1
—
200312190
00000.000
—
55 pages
—
US Govt
agencies
370 pages
—
198503000
00000.000
199412290
00000.000
C2IEDMAnnexes-USDMWGEdition6.1
FM 7-7
398
—
FM 24-24
V3.1.4
(b) REFERENCE (third of three)
**id
**-title-text
301
—
102
—
567
—
890
Human Rights
Situation in
Bradyland
NATO
Glossary of
Terms and
Definitions
Designing
Quality
Databases
with IDEF1X
Information
Models
Geodetic
Datum,
Projection,
Grids and Grid
References
Ops Plan for
Operation
Purple Dragon
Ops Order for
Operation
Purple Dragon
F-111D Flight
Manual
123
456
660
6
987
990
771
3
123
4
123
5
442
2
443
3
The C2
Information
Exchange
Data Model
(C2IEDM
Main)
The C2
Information
Exchange
Data Model
(C2IEDM
Annexes)
The
Mechanized
Infantry
Platoon and
Squad (APC)
Signal Data
References:
Signal
Equipment
**transmittal
-type-code
**-validityperiod-begindatetime
**-validityperiod-enddatetime
**verificatio
n-code
**version
-text
securityclassificati
on-id
E-mail
message
Radio
message
Secure fax
message
—
—
—
—
sc100
—
—
—
—
—
20040910000000
.000
200409120000
00.000
—
—
sc101
Not known
—
—
Reference
verified
2
—
Courier
message
—
—
Reference
verified
5
sc102
—
—
—
Reference
verified
—
—
—
—
—
Reference
verified
—
Courier
message
20040815000000
.000
—
—
0.8
Courier
message
20040815000000
.000
200409260000
00.000
—
1.0
—
—
—
Reference
verification
not
available
—
—
—
—
—
6.1
—
—
—
—
6.1
—
—
—
Reference
unverified
—
sc103
—
—
—
Reference
verification
not
available
—
sc104
13.7.4 The security classification, security policy and any security caveats of a
reference is provided by the relationship from the SECURITY-CLASSIFICATION entity.
This specification is explained in paragraph 14.9.
399
V3.1.4
13.7.5 The examples in the rest of this chapter use the data presented in the table
above.
13.8
13.8.1 The entity ACTION-REFERENCE-ASSOCIATION is defined as "A
relationship between a specific ACTION and a specific REFERENCE." The attributes are:
a.
action-id—The unique value, or set of characters, assigned to represent a
specific ACTION and to distinguish it from all other ACTIONs.
b.
c.
action-reference-association-category-code—The specific
value
that
represents the class of a specific ACTION-REFERENCE-ASSOCIATION.
Example domain values are: Is changed by; Is defined by; Is directed by; Is
referenced by; Is reported by.
d.
action-reference-association-part-text—The character string assigned to
represent a specific part of the artefact that applies in a specific ACTIONREFERENCE-ASSOCIATION.
13.8.2 The table below relates two instances of REFERENCE to an instance of
ACTION. The document identified as 987 is the draft plan and serves as the input for
guiding the development of the database entries for the ACTION structure. When the
execution of the plan is ordered by means of the document identified as 990, then the
appropriate status changes can be made in the ACTION records.
Table 154. Associating REFERENCE with ACTION
action-id
reference-id
*-category-code
*-part-text
5551
[Operation Purple Dragon]
5551
[Operation Purple Dragon]
987
Is amplified by
—
990
Is directed by
—
Note: * = "action-reference-association"
13.9
13.9.1 The entity CAPABILITY-REFERENCE-ASSOCIATION is defined as "A
relationship between a specific CAPABILITY and a specific REFERENCE." The
attributes are:
a.
b.
c.
capability-reference-association-category-code—The specific value that
represents the class of a specific CAPABILITY-REFERENCE-ASSOCIATION.
The domain values are: Is amplified by; Is defined in; Is described by.
400
V3.1.4
13.9.2 The table below illustrates the simple association that can be made to link
an external document cited in REFERENCE to provide an extended description of the
instance of CAPABILITY that is identified as 11111.
Table 155. Associating a REFERENCE with CAPABILITY
capability-id
reference-id
capability-referenceassociation-category-code
11111
4422
Is described in
13.10 OBJECT-ITEM-REFERENCE-ASSOCIATION
13.10.1 The entity OBJECT-ITEM-REFERENCE-ASSOCIATION is defined
as "A relationship between a specific OBJECT-ITEM and a specific REFERENCE." The
attributes are:
a.
object-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.
b.
c.
object-item-reference-association-index—The unique value, or set of characters,
assigned to represent a specific OBJECT-ITEM-REFERENCE-ASSOCIATION
for a specific OBJECT-ITEM and a specific REFERENCE and to distinguish it
from all other OBJECT-ITEM-REFERENCE-ASSOCIATIONs for that
OBJECT-ITEM and that REFERENCE.
d.
object-item-reference-association-category-code—The specific value that
represents the class of a specific OBJECT-ITEM-REFERENCEASSOCIATION. Example domain values are: Is activated by; Is authorised by;
Is deactivated by; Is referenced by; Is reported in.
e.
object-item-reference-association-specific-part-text—The
character
string
assigned to represent a specific part of the artefact that applies in a specific
OBJECT-ITEM-REFERENCE-ASSOCIATION.
13.10.2 The table below shows three examples of references associated with
units. The first record is associated with the 7th Division. The other two records associate
JC3IEDM documentation with the 2nd Automation Company that will be using the data
specifications to build a C2 system.
Table 156. Associating REFERENCEs with OBJECT-ITEMs
referenceid
*index
*-category-code
*-specificpart-text
333
[7th Div]
567
1
Is referenced by
—
375
[2nd Automation Coy]
375
[2nd Automation Coy]
1234
1
—
1235
1
Has instructions provided
in
Has instructions provided
in
object-item-id
Note: * = "object-item-reference-association"
401
—
V3.1.4
13.11 OBJECT-TYPE-REFERENCE-ASSOCIATION
13.11.1 The entity OBJECT-TYPE-REFERENCE-ASSOCIATION is defined
as "A relationship between a specific OBJECT-TYPE and a specific REFERENCE." The
attributes are:
a.
object-type-id—The unique value, or set of characters, assigned to represent a
specific OBJECT-TYPE and to distinguish it from all other OBJECT-TYPEs.
b.
c.
object-type-reference-association-category-code—The specific value that
represents the class of a specific OBJECT-TYPE-REFERENCEASSOCIATION. Example domain values are: Has capabilities defined in; Is
described by; Is procured using; Is referenced in; Is specified by.
13.11.2 The table below shows a record that associated the flight manual for an
F-111D aircraft with its type that is part of the reference information in the database.
Table 157. Associating REFERENCE to OBJECT-TYPE
object-type-id
398
[F-111D aircraft]
160022
[AN/GRC-213 HF Radio Set]
referenceid
object-type-referenceassociation-category-code
7713
Has training supported by
4433
Is described by
13.12 ORGANISATION-REFERENCE-ASSOCIATION
13.12.1 The entity ORGANISATION-REFERENCE-ASSOCIATION is
defined as "A relationship between a specific ORGANISATION and a specific
REFERENCE." The attributes are:
a.
b.
c.
organisation-reference-association-index—The unique value, or set of
characters, assigned to represent a specific ORGANISATIONREFERENCE-ASSOCIATION for a specific ORGANISATION and a
specific REFERENCE and to distinguish it from all other ORGANISATIONREFERENCE-ASSOCIATIONs for that ORGANISATION and that
REFERENCE.
d.
organisation-reference-association-category-code—The specific value that
represents the class of a specific ORGANISATION-REFERENCEASSOCIATION. Example domain values are: Is approval authority for; Is
creator of; Is planner of; Is release authority for.
e.
organisation-reference-association-start-datetime—The
character
string
representing a point in time that designates the start of a specific
ORGANISATION-REFERENCE-ASSOCIATION.
402
V3.1.4
13.12.2 The table below illustrates the responsibilities of two MIP organisations
with respect to JC3IEDM documentation (Main and Annexes). The first two records
indicate that DMWG is the creator of the documents; the next two show that PMG
approves the documents, and finally the last two records state that PMG also has the
authority to release the documents.
Table 158. Associating REFERENCE to ORGANISATION
organisation-id
reference-id
*-index
*-category-code
*-start-datetime
20451
[MIP DMWG]
20451
[MIP DMWG]
32277
[MIP PMG]
32277
[MIP PMG]
32277
[MIP PMG]
1234
1
Is creator of
19980816080000.000
1235
1
Is creator of
19980816080000.000
1234
1
Is approval authority for
19980816080000.000
1235
1
Is approval authority for
19980816080000.000
1234
2
Is release authority for
19980816080000.000
1235
2
Is release authority for
19980816080000.000
32277
[MIP PMG]
Note: * = "organisation-reference-association"
13.13 REFERENCE-ASSOCIATION
13.13.1 The entity REFERENCE-ASSOCIATION is defined as "A relationship
of a REFERENCE as a subject with another REFERENCE as an object." The attributes
are:
a.
reference-association-subject-reference-id—The reference-id of the subject
REFERENCE in a specific REFERENCE-ASSOCIATION (a role name for
reference-id).
b.
reference-association-object-reference-id—The reference-id of the object
REFERENCE in a specific REFERENCE-ASSOCIATION (a role name for
reference-id).
c.
reference-association-index—The unique value, or set of characters, assigned
to represent a specific REFERENCE-ASSOCIATION for a subject
REFERENCE and an object REFERENCE and to distinguish it from all
other REFERENCE-ASSOCIATIONs for those REFERENCEs.
d.
reference-association-category-code—The specific value that represents the
class of relationship between a subject REFERENCE and an object
REFERENCE for a specific REFERENCE-ASSOCIATION. Example
domain values are: Cancels; Includes; Is derived from; Supersedes.
403
V3.1.4
13.13.2 The first record in the table below establishes a relationship between the
Main document of JC3IEDM specification and the Annexes. The second record relates the
operations plan and the operations order for a military operation.
Table 159. Associating REFERENCEs
*-subject-reference-id
*-object-reference-id
*-index
*-category-code
1235
990
1234
987
1
1
Supplements
Is modification of
Note: * = "reference-association"
13.14 Relationship of REFERENCE to REPORTING-DATA
The examples of REFERENCE identified as 102 and 301 in the previous Table
153 represent operational data whose essential elements are likely to be entered into a
database. The information stored in the database may include identification of
organisations, units, and persons, their relationships, their typing, their location, their
activities, and status. Such data would be linked to records in REPORTING-DATA. In
turn, the identifiers 102 and 301 (as foreign keys) would be entered in the appropriate
records to indicate that supporting non-structured information is available.
404
V3.1.4
14. CONTEXT
14.1
Introduction
14.1.1 Operational needs strongly support the concept of "grouping" or
"packaging" data in order to provide a coherent picture that is relevant to a given situation
or circumstance at a given time. Data tends to be distributed in various tables throughout a
database that is designed on relational principles. CONTEXT provides a mechanism for
referring to one or more records in various tables and treating them as a single "context."
The basic structure is illustrated in the figure below.
14.1.2 CONTEXT may entail a collection of data that is relevant to the situation,
background, or environment for a particular unit or activity. It can specify conditions that
must precede an ACTION or those that should result from the execution of an ACTION.
A planner can use the context information to judge the merits of an operational plan, and
make changes in order to respond to a changing operational situation. A commander can
use the context information to provide his assessment. CONTEXT can also be used to
record the history of an evolving operation, capture a situation as it existed at some time in
the past or portray a situation as it is expected to exist at a future date.
14.1.3 Since a specific CONTEXT can represent the view of the current
operational picture that is held by a particular unit, it can be shared with other units or
organisations. The sharing need not be limited to the operational picture, but can apply to
any defined concept that can be encompassed within CONTEXT specifications. One of the
possible applications of CONTEXT is to serve as the basis for exchange or distribution of
information.
14.1.4 The basic structure of CONTEXT consists of CONTEXT-ELEMENT and
its status, CONTEXT-ASSOCIATION and its status, and a subtype OPERATIONALINFORMATION-GROUP (in brief, OIG56). CONTEXT structure is specified in Section
14.2 with the exception of OIG that is presented in Section 14.8. The various uses that
CONTEXT enables are presented in the subsequent sections as follows:
56
a.
CONTEXT-ASSESSMENT provides the possibility of adding a limited
amount of free text to convey information that cannot be represented in
structured data. The topic is covered in Section 14.3.
b.
CONTEXT can support correlation of data where several elements of
information are collected as part of the CONTEXT and can then be related to
the "new" information that is derived from the "raw" data via CONTEXTREPORTING-DATA-ASSOCIATION. The topic is covered in Section 14.4.
c.
Section 14.5 presents examples to illustrate the use of CONTEXT
specifications.
d.
An instance of CONTEXT can be related to an instance of OBJECT-ITEM.
This topic is covered in Section 14.6.
e.
An instance of CONTEXT can be related to an instance of ACTION. This is
an important linkage that (i) permits an ACTION to be made a part of a
OIG is not a formal abbreviation; it is used only in the explanatory text.
405
V3.1.4
CONTEXT and (ii) enables packages of information to be coupled to plans
and orders making them an inherent part of ACTION. The specification of
ACTION-CONTEXT is presented in Section 14.7. The use referred to in (i)
is needed to define Operational Information Groups. The use cited in (ii) is
described and illustrated in Section 16.7.
f.
OIG is an important concept that makes extensive use of CONTEXT and its
relationships. Specifications of OIG and related structures are presented in
Section 14.8.
CONTEXT
is-the-subject-of
is-the-object-of
has /
is-ascribed-to
P
CONTEXT-ASSOCIATION
identifies-the-data-for
is-the-subject-of
establishes /
is-established-by
CONTEXT-ASSESSMENT
is-referenced-to
is-a-part-of
is-the-object-of
CONTEXT-ELEMENT
Z
is-cited-in /
is-referenced-to
has /
is-ascribed-to
P
REPORTING-DATA
is-reported-by
is-cited-by
establishes /
is-established-by
P
OPERATIONAL-INFORMATION-GROUP-ORGANISATION-ASSOCIATION
has /
is-ascribed-to
P
OPERATIONAL-INFORMATION-GROUP-ORGANISATION-ASSOCIATION-STATUS
OBJECT-ITEM
is-the-subject-of
is-the-object-of
establishes /
is-established-by
ORGANISATION
has /
is-ascribed-to
establishes /
is-established-by
provides-circumstances-for
has /
is-ascribed-to
provides-to
ACTION-CONTEXT
establishes /
is-established-by
ACTION-CONTEXT-STATUS
is-placed-within
ACTION
Figure 119. Overview of CONTEXT Structure and Its Relationships
14.2
Specification of CONTEXT Structure
14.2.1 Introduction
14.2.1.1 The structure that enables an instance of CONTEXT to be defined,
amended, and a set of CONTEXTs to be managed is illustrated in the figure below.
406
V3.1.4
CONTEXT
provides-to
context-id
CONTEXT-ASSOCIATION
context-name-text
is-the-subject-of
is-the-object-of
context-association-subject-context-id (FK)
context-association-object-context-id (FK)
context-association-category-code
is-a-part-of
Zcontext-category-code
has /
is-ascribed-to
operational-information-group-id (FK)
operational-information-group-category-code
CONTEXT-ELEMENT
P
context-id (FK)
context-element-index
context-association-subject-context-id (FK)
context-association-object-context-id (FK)
context-association-status-index
context-association-status-category-code
context-association-status-effective-datetime
context-association-status-establishing-organisation-id (FK)
has /
is-ascribed-to
P
OBJECT-ITEM
context-id (FK)
context-element-index (FK)
context-element-status-index
is-cited-in /
is-referenced-to
object-item-id
context-element-status-category-code
context-element-status-effective-datetime
context-element-status-establishing-organisation-id (FK)
REPORTING-DATA
reporting-data-id
reference-id (FK)
establishes /
is-established-by
establishes /
is-established-by
ORGANISATION
is-reported-by
Figure 120. Specification of CONTEXT Structure
14.2.1.2 CONTEXT is built primarily through indirect reference to information
via REPORTING-DATA and secondarily through associations with other entities as
discussed in subsequent sections. REPORTING-DATA has multiple connectivity to other
entities in the model, as illustrated in Figure 117 of the preceding chapter. Data that is to
be associated with an instance of CONTEXT is identified through CONTEXTELEMENT.
14.2.1.3 Data may be moved in or out of an instance of CONTEXT by
indicating the particular instances of CONTEXT-ELEMENT that apply at any given time.
The entity CONTEXT-ELEMENT-STATUS keeps track of the inclusion status and its
407
V3.1.4
timing. This technique preserves data integrity while allowing the data content to change
for any instance of CONTEXT.
14.2.1.4 The entity CONTEXT-ASSOCIATION and its child entity CONTEXTASSOCIATION-STATUS permit the linking of one instance of CONTEXT to another
with the relationship defined by the value of the category code in the association.
14.2.2 Specification of CONTEXT
14.2.2.1 The entity CONTEXT is defined as "A collection of information that
provides in its entirety the circumstances, conditions, environment, or perspective for a
situation." In fact, an instance of CONTEXT is essentially a collection of instances of
REPORTING-DATA under a single label. The attributes are:
a.
context-id—The unique value, or set of characters, assigned to represent a
specific CONTEXT and to distinguish it from all other CONTEXTs.
b.
context-category-code—The specific value that represents the class of
CONTEXT. It serves as a discriminator that partitions CONTEXT into
subtypes. The domain values are: Assessment; Correction; Correlation;
Negation; Not otherwise specified, OPERATIONAL-INFORMATIONGROUP; Overlay; Prediction.
c.
context-name-text—The character string assigned to represent a specific
CONTEXT.
d.
The category attribute enables the user to classify in data the contents of a specific
CONTEXT within the scope of the allowable domain set for the attribute. The name
attribute permits an instance of CONTEXT to be labelled in natural language, for example,
"Current situation at noon on 1 January 2005." The security classification information is
identified in the SECURITY-CLASSIFICATION entity and refers to the entire package of
data that is defined in a specific CONTEXT.
14.2.2.2 Specification of the subtype OPERATIONAL-INFORMATIONGROUP of CONTEXT is presented in Section 14.8.
14.2.3 Specification of CONTEXT-ELEMENT and CONTEXT-ELEMENTSTATUS
14.2.3.1 An instance of CONTEXT is created by associating with it the
appropriate instances of REPORTING-DATA. This is accomplished by means of a child
entity CONTEXT-ELEMENT. It is defined as “A reference to a specific REPORTINGDATA that is a constituent part of a specific CONTEXT.” The attributes are:
a.
b.
context-element-index—The unique value, or set of characters, assigned to
represent a specific CONTEXT-ELEMENT for a specific CONTEXT and to
distinguish it from all other CONTEXT-ELEMENTs for that CONTEXT.
408
V3.1.4
c.
REPORTING-DATAs.
In effect, the entity CONTEXT provides a title for a set of data and CONTEXTELEMENT lists the members of the set.
14.2.3.2 The addition or removal of instances of CONTEXT-ELEMENT are
managed through CONTEXT-ELEMENT-STATUS. The entity is defined as "A record of
the perceived state of a specific CONTEXT-ELEMENT as determined by the establishing
organisation." The inclusion of CONTEXT-ELEMENT-STATUS in the specification
enables the user to change the information content of a specific CONTEXT over time.
14.2.3.3
The attributes of CONTEXT-ELEMENT-STATUS are:
a.
b.
context-element-index—The unique value, or set of characters, assigned to
represent a specific CONTEXT-ELEMENT for a specific CONTEXT and to
distinguish it from all other CONTEXT-ELEMENTs for that CONTEXT.
c.
context-element-status-index—The unique value, or set of characters,
assigned to represent a specific CONTEXT-ELEMENT-STATUS for a
specific CONTEXT-ELEMENT and to distinguish it from all other
CONTEXT-ELEMENT-STATUSs for that CONTEXT-ELEMENT.
d.
context-element-status-category-code—The specific value that indicates
whether a specific CONTEXT-ELEMENT-STATUS refers to the addition or
removal of the CONTEXT-ELEMENT from the CONTEXT. The domain
values are: Addition, Removal.
e.
context-element-status-effective-datetime—The character string representing
a point in time that designates the beginning of the period of effectiveness for
a specific CONTEXT-ELEMENT-STATUS.
f.
context-element-status-establishing-organisation-id—The identifier of the
ORGANISATION that establishes a specific CONTEXT-ELEMENTSTATUS (a role name for object-item-id).
14.2.4 Example of CONTEXT Use
14.2.4.1 An Allied mechanised brigade has been involved in heavy action; it has
suffered significant losses both in personnel and materiel. It is now disengaged and is in
the process of reconstitution.
14.2.4.2 The data for this example are displayed in the table below. Sub-table (a)
shows selected holdings of the brigade: MBTs, APCs, and personnel. Sub-table (b)
presents the commander’s judgement about the status of the brigade. Sub-table (c)
indicates the current location of the unit. The appropriate reporting data for each of the
classes of information contained in the first three sub-tables is recorded in Sub-tables (d)
and (e). Sub-tables (f) and (g) show that the three separate sets of data are combined into a
single CONTEXT. Sub-table (h) shows the time at which the brigade created the unit
report. Sub-table (i) provides the initial entry datetimes for the current data content.
409
V3.1.4
Table 160. Example of CONTEXT (Initial)
(a) HOLDING
object-itemid
object-typeid
holdingindex
reportingdata-id
[Mech Bde]
[Mech Bde]
[Mech Bde]
[MBT]
[APC]
[Personnel]
1
1
1
32
37
1357
58
54
1806
rd6
rd6
rd6
(b) ORGANISATION-STATUS
*-id
OBJECT-ITEM-STATUS
reporting-dataid
1
Marginally
operational
Moderately damaged
rd7
[Mech
Bde]
object-item-id
locationid
reporting-dataid
[Mech Bde]
[Point 41]
1
rd9
(d) REPORTING-DATA
**-id
**-category- **-countingcode
indicator-code
**-credibility-code
rd6
Reported
Yes
Reported as a fact
rd7
Reported
—
Reported as a fact
rd9
Reported
—
Reported as a fact
*****-reportingreporting- organisation
datetime
-id
199808160
93000.000
199808160
94000.000
199808160
91000.000
[Mech Bde]
[Mech Bde]
[Mech Bde]
(e) REPORTING-DATA-ABSOLUTE-TIMING
***-reporting-data-id
rd6
rd7
rd9
19980816080000.000
19980816090000.000
19980816090000.000
—
—
—
(f) SECURITY-CLASSIFICATION
****-id
****-level-code
****-policy-text
****-caveat-text
sc1
Secret
NATO
Releasable to NATO
Note: **** = "security-classification"
(g) CONTEXT
context-id
c72
context-categorycode
context-nametext
Not otherwise
specified
Mech Bde Unit
Combat Report
sc1
(h) CONTEXT-ELEMENT
context-id
reporting-data-id
c72
c72
c72
1
2
3
rd6
rd7
rd9
410
V3.1.4
(i) CONTEXT-ELEMENT-STATUS
context-id
contextelement-index
*****index
*****-categorycode
*****-effective-datetime
*****-etablishingorganisation-id
c72
1
1
Addition
19980816103000.000
[Mech Bde]
c72
c72
2
3
1
1
Addition
Addition
19980816103000.000
19980816103000.000
[Mech Bde]
[Mech Bde]
Note: ***** = "context-element-status"
14.2.4.3 The brigade has done well after one week of recovery operations. The
operational count of its equipment and personnel has improved and its operational status
has changed from "Marginally operational" to "Substantially operational." The data are
shown in the table below where the relevant tables from the previous set have been
repeated with the new data added. The new holdings and status data are associated with
reporting data identifiers rd13 and rd14. These are added to the table CONTEXTELEMENT (Sub-table (g)). However, the table CONTEXT-ELEMENT-STATUS (Subtable (i)) shows that the data content of Context c72 changed by removing data associated
with rd6 and rd7 and adding data associated with rd13 and rd14.
Table 161. Example of CONTEXT (Continued)
(a) HOLDING
object-itemid
object-typeid
holdingindex
reportingdata-id
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
[MBT]
[APC]
[Personnel]
[MBT]
[APC]
1
1
1
2
2
32
37
1357
45
42
58
54
1806
58
54
rd6
rd6
rd6
rd13
rd13
[Mech Bde]
[Personnel]
2
1633
1806
rd13
*-id
[Mech
Bde]
[Mech
Bde]
OBJECT-ITEM-STATUS
reporting-dataid
1
Marginally
operational
Substantially
operational
Moderately damaged
rd7
—
rd14
2
(c) REPORTING-DATA
reporting **-category-data-id
code
rd6
rd7
rd9
rd13
rd14
Reported
Reported
Reported
Reported
Reported
**-countingindicator-code **-credibility-code
Yes
—
—
—
—
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
Reported as a fact
**-reportingdatetime
19980816093000.000
19980816094000.000
19980816091000.000
19980823114500.000
19980823114500.000
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
411
V3.1.4
rd6
rd7
19980816080000.000
19980816090000.000
—
—
rd9
rd13
rd14
19980816090000.000
19980823113000.000
19980823113000.000
—
—
—
(e) CONTEXT-ELEMENT
context-id
reporting-data-id
c72
c72
c72
c72
c72
1
2
3
4
5
rd6
rd7
rd9
rd13
rd14
(f) CONTEXT-ELEMENT-STATUS
context-id
contextelement-index
****index
****categorycode
****-effective-datetime
****etablishingorganisation-id
c72
c72
c72
c72
c72
c72
c72
1
2
3
1
2
4
5
1
1
1
2
2
1
1
Addition
Addition
Addition
Removal
Removal
Addition
Addition
19980816103000.000
19980816103000.000
19980816103000.000
19980823115000.000
19980823115000.000
19980823115000.000
19980823115000.000
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
[Mech Bde]
Note: **** = "context-element-status"
14.2.5 Specification of CONTEXT-ASSOCIATION and CONTEXTASSOCIATION-STATUS
14.2.5.1 Relationships between any pair of instances of CONTEXT can be
recorded using the entity CONTEXT-ASSOCIATION. It is defined as "A relationship of a
CONTEXT as a subject with another CONTEXT as an object." The attributes are:
a.
context-association-subject-context-id—The context-id of a specific
CONTEXT that serves as the subject of a specific CONTEXTASSOCIATION (a role name for context-id).
b.
context-association-object-context-id—The context-id of a specific
CONTEXT that serves as the object of a specific CONTEXTASSOCIATION (a role name for context-id).
c.
context-association-category-code—The specific value that represents the
type of relationship between the subject CONTEXT and the object
CONTEXT in a specific CONTEXT-ASSOCIATION. The domain values
are: Is next after; Is part of/Is sub-context of; Supersedes; Supplements.
14.2.5.2 The status of instances of CONTEXT-ASSOCIATION can be
maintained via the entity CONTEXT-ASSOCIATION-STATUS. It is defined as "A
record of the perceived state of a specific CONTEXT-ASSOCIATION as determined by
the establishing organisation." The attributes are:
412
V3.1.4
a.
context-association-subject-context-id—The context-id of a specific
CONTEXT that serves as the subject of a specific CONTEXTASSOCIATION (a role name for context-id).
b.
context-association-object-context-id—The context-id of a specific
CONTEXT that serves as the object of a specific CONTEXTASSOCIATION (a role name for context-id).
c.
context-association-status-index—The unique value, or set of characters,
assigned to represent a specific CONTEXT-ASSOCIATION-STATUS for a
specific CONTEXT-ASSOCIATION and to distinguish it from all other
CONTEXT-ASSOCIATION-STATUSs
for
that
CONTEXTASSOCIATION.
d.
context-association-status-category-code—The specific value that indicates
whether a specific CONTEXT-ASSOCIATION-STATUS refers to the
beginning or termination of the association. The domain values are: End;
Start. The domain value set for this attribute is shared with one or more other
attributes and is defined in the set association-status-category-code.
e.
context-association-status-effective-datetime—The
character
string
representing a point in time that designates the beginning of the period of
effectiveness for a specific CONTEXT-ASSOCIATION-STATUS.
f.
context-association-status-establishing-organisation-id—The identifier of the
ORGANISATION that establishes a specific CONTEXT-ASSOCIATIONSTATUS (a role name for object-item-id).
14.2.5.3 An example of CONTEXT-ASSOCIATION is provided by building on
the example of the previous section. The example is extended in the table below. The
mechanised brigade was re-deployed to garrison after several additional weeks of combat.
The previous CONTEXT that represented combat unit report was no longer appropriate
and another CONTEXT was created to represent the unit report in garrison. A new context
c89 is created notionally without further details.
Table 162. Example of CONTEXT Use (Continued)
(a) SECURITY-CLASSIFICATION
*-id
sc2
*-level-code
*-policy-text
*-caveat-text
Secret
NATO
Releasable to NATO
(b) CONTEXT
context-id
c72
c89
context-nametext
Not otherwise
specified
Not otherwise
specified
Mech Bde Unit
Combat Report
Mech Bde Unit
Garrison Report
sc1
sc2
(c) CONTEXT-ASSOCIATION
**-subject-contest-id
**-object-contest-id
**-category-code
c89
c72
Supersedes
Note: ** = "context-association"
413
V3.1.4
(d) CONTEXT-ASSOCIATION-STATUS
**-subjectcontest-id
**-objectcontest-id
c89
c72
**index
***-categorycode
***-effective-datetime
***-etablishingorganisation-id
1
Start
19980915140000.000
[Mech Bde]
Note: ** = "context-association"
Note: *** = "context-association-status"
14.2.6 Business Rule for CONTEXT-ASSOCIATION
A business rule to avoid circular nesting of instances of CONTEXT through
CONTEXT-ASSOCIATION is specified in Annex G1, Section G1.10.
14.3
Providing Assessments via CONTEXT
14.3.1 Structure
14.3.1.1 Commander’s or staff assessments can touch upon many topics either
singly or in combination. In order to provide the capability to record assessments about the
broadest range of data by using a limited amount of free text, a child entity of
CONTEXT—CONTEXT-ASSESSMENT—has been added to the model. Addition of text
is optional, but if an assessment is added it becomes an integral part of "context." The
structure is illustrated in the figure below.
14.3.1.2 The entity CONTEXT-ASSESSMENT is defined as "A record of
appraisal by a specific ORGANISATION regarding the information that is referenced by a
specific instance of CONTEXT." The attributes are:
a.
b.
context-assessment-index—The unique value, or set of characters, assigned
to represent a specific CONTEXT-ASSESSMENT for a specific CONTEXT
and to distinguish it from all other CONTEXT-ASSESSMENTs for that
CONTEXT.
c.
context-assessment-text—The character string assigned to represent an
appraisal regarding the information that is referenced by a specific instance
of CONTEXT.
d.
context-assessment-limiting-factors-code—The specific value that represents
the logistic factors, which are degrading operational capability in a specific
CONTEXT-ASSESSMENT. Example domain values are: Cross-servicing
capability; Equipment limitations; No change; No limitations.
e.
REPORTING-DATAs.
414
V3.1.4
OBJECT-ITEM
CONTEXT
context-id
object-item-id
context-name-text
security-class if ication-id (FK)
identif ies-the-data-f or
is-a-part-of
ORGA NISATION
organis ation-id.object-item-id (FK)
organis ation-c ategory-code
CONTEXT-A SSESSMENT
context-id (FK)
context-ass essment-index
context-ass essment-text
context-ass essment-limiting-f actors-code
prov ides-applicable-inf ormation-f or /
is-ref erenced-to
CONTEXT-ELEMENT
context-id (FK)
is-cited-in /
is-ref erenced-to
is-reported-by
REPORTING-DATA
reporting-data-id
reporting-data-counting-indicator-c ode
reporting-data-reliability -code
reporting-data-timing-category -code
ref erence-id (FK)
reporting-data-reporting-organisation-id.organisation-id (FK)
Figure 121. Specification of CONTEXT-ASSESSMENT
14.3.2 Examples of Assessments
Three examples are presented. The first one concerns inadequate resources to
accomplish a mission; the second one deals with differing interpretations about an
observed enemy force; and the last one is a situation assessment involving a group of
several types of operational information.
14.3.2.1 Assessment of Holding
An armoured brigade is planning its operations for the next day. It has just reported
its current holdings of MBTs as well as the projections for the next 24 and 48 hours. It has
been assigned an attack mission for the next day against a strong enemy force. The data is
shown in the table below and consists of three parts. Sub-table (a) presents the actual and
the predicted holdings of the type of MBT that equips the brigade. The appropriate
characterisations of these data are contained in Sub-table (b). Sub-table (f) links the
instances of REPORTING-DATA to CONTEXT. The commander of the brigade inserts
his views on the adequacy of the available equipment for the mission at hand in Sub-table
415
V3.1.4
(g). He also affirms his confidence in being able to achieve the degree of operational
equipment readiness that was projected for a time two days hence.
Table 163. Unit MBT Holdings
(a) HOLDING
object-itemid
objecttype-id
holdingindex
reportingdata-id
[AR Bde]
[AR Bde]
[AR Bde]
[MBT]
[MBT]
[MBT]
1
2
3
32
37
49
56
56
56
rd1
rd2
rd3
(b) REPORTING-DATA
reportingdata-id
*-categorycode
*-countingindicator-code
*-credibilitycode
*-reportingdatetime
rd1
Reported
Counted
Planned
—
rd3
Planned
—
rd55
Inferred
—
rd66
Inferred
—
19980808083
000.000
19980808083
000.000
19980808083
000.000
19980808093
000.000
19980808113
000.000
[AR Bde]
rd2
Reported as a
fact
Reported as
plausible
Reported as
plausible
Reported as
plausible
—
[AR Bde]
[AR Bde]
[AR Bde]
[AR Bde]
rd1
rd2
rd3
rd55
rd66
19980808080000.000
19980809090000.000
19980810060000.000
19980808093000.000
19980808113000.000
—
—
—
—
—
***-id
sc3
***-level-code
***-policy-text
***-caveat-text
Secret
NATO
Releasable to NATO
Note: *** = "security-classification"
(e) CONTEXT
context-id
c1
Assessment
context-name-text
Concern with Number
of Operational MBTs
sc3
(f) CONTEXT-ELEMENT
context-id
reporting-data-id
c1
c1
1
2
rd1
rd3
416
V3.1.4
(g) CONTEXT-ASSESSMENT
context-id ****-index
c1
1
c1
2
****-text
****-limiting-factors-code
reporting-data-id
The success of the operation assigned to
this unit tomorrow is questionable due the
low number of MBTs expected to be
operational. A delay of 24 hours would
see the operational ready rate increase to
88% with a substantial improvement in
the likelihood of mission success.
I am highly confident of being able to
have this number of operational MBTs.
Equipment limitations
rd55
—
rd66
Note: **** = "context-assessment"
14.3.2.2 Assessment of Enemy Forces
14.3.2.2.1 A mechanised company in forward defensive position spots enemy
activity and reports the presence of an enemy battalion. Such a relatively large force is
judged to be a significant threat to the company. However, the Division G-2 staff, relying
on collection assets made available to them, concludes that the enemy formation that was
initially sighted by the forward-deployed company is actually a platoon of combat
engineers with the task of deceiving opposing observers.
14.3.2.2.2 The data for this example are shown in the table below in six parts.
Sub-table (a) records the judgement of the reporting unit about the type of object that is
being reported—in this case, the type assignment is made for an enemy unit. Sub-tables
(b) and (c) record the appropriate reporting data. The reporting-data-id rd4 identifies the
mechanised company as the source, and reporting-data-id rd5 points to Division G-2. Subtable (e) links the instances of REPORTING-DATA to instances of CONTEXT, one
created by the mechanised company and the second by division G-2. Sub-table (f) contains
three entries. The first one deals with data referred to by rd4 expressing the company’s
concern. The second and third refer to a context that includes both rd4 and rd5. The
second by Division G-2 points out that the concern is misplaced since the enemy unit
represents only a slight threat. The third record provides the reason for the judgement by
the G-2.
Table 164. Typing of Hostile Units
(a) OBJECT-ITEM-TYPE
object-item-id
object-type-id
reporting-data-id
[Hostile Unit X]
[Hostile Unit X]
[Infantry Battalion]
[Combat Engineer Platoon]
1
1
rd4
rd5
(b) REPORTING-DATA
*-accuracycode
*-categorycode
*-credibilitycode
rd4
—
Reported
Plausible
rd5
rd111
Possible
Possible
Inferred
Inferred
—
Reported as
plausible
rd555
rd600
Probable
Probable
Inferred
Inferred
—
—
*-id
*-source-typecode
19980810151500.000
—
[Mech Coy]
19980811103500.000
19980810170000.000
Various sources
—
[Div G-2]
[Mech Coy]
19980811120000.000
19980811160000.000
—
—
[Div G-2]
[Div G-2]
417
V3.1.4
rd4
rd5
19980810143500.000
19980811102000.000
—
—
rd 111
rd555
rd600
19980810170000.000
19980811120000.000
19980811160000.000
—
—
—
***-id
***-level-code
***-policy-text
***-caveat-text
sc4
sc5
Secret
Secret
NATO
NATO
Releasable to NATO
Releasable to NATO
Note: *** = "security-classification"
(e) CONTEXT
context-id
context-name-text
security-classificationid
c2
c3
Assessment
Dangerous Position
sc4
Assessment
Threat Re-assessment
sc5
(f) CONTEXT-ELEMENT
context-id
reporting-data-id
c2
c3
c3
1
1
2
rd4
rd4
rd5
(g) CONTEXT-ASSESSMENT
context-id
****-index
****-text
****-limiting-factors-code reporting-data-id
c2
1
c3
1
c3
2
This rather sizeable enemy unit is a threat to
our right flank.
The enemy unit is much smaller and is not
likely to be a threat.
Our analysis of reconnaissance imagery
leads to the conclusion that the enemy
formation is engaged in a deception
operation.
—
rd111
—
rd555
—
rd600
Note: **** = "context-assessment"
14.3.2.3
Assessment Regarding Own Unit Status, Own Holdings, and
Enemy Force Disposition
14.3.2.3.1 This unit is the same as in the example of Section 14.2.4. Now a
different context is constructed using some of the same data as in the previous example.
The situation is complicated by the fact that three hostile regiments are deployed in
locations to pose a threat to the brigade, particularly in its weakened state. If the enemy
forces discern the status of the brigade, they may choose to use the opportunity for an
immediate attack.
14.3.2.3.2 The data are displayed in the table below. Sub-table (a) shows selected
holdings of the brigade: MBTs, APCs, and personnel. Sub-table (b) presents the
commander’s judgement about the status of the brigade. Sub-table (c) is part of the data
provided by the parent Division G-2 regarding the disposition of opposing forces. The
appropriate reporting data for each of the classes of information contained in the first three
418
V3.1.4
sub-tables is recorded in Sub-tables (d) and (e). Sub-tables (f), (g) and (h) show that the
three separate sets of data are combined into a single CONTEXT. The brigade
commander/s assessment is shown in Sub-table (i); it references data in Sub-tables (a), (b),
and (c).
Table 165. Situational Awareness
(a) HOLDING
object-itemid
object-typeid
holdingindex
reportingdata-id
[Mech Bde]
[Mech Bde]
[Mech Bde]
[MBT]
[APC]
[Personnel]
1
1
1
32
37
1357
58
54
1806
rd6
rd6
rd6
*-id
[Mech
Bde]
OBJECT-ITEM-STATUS
reporting-dataid
1
Marginally
operational
Moderately damaged
rd7
object-item-id
locationid
reporting-dataid
[BQ AR Regt 1]
[BQ AR Regt 2]
[BQ Motorised Regt]
[Point 1]
[Point 2]
[Point 3]
1
1
1
rd8
rd8
rd8
(d) REPORTING-DATA
reporting- **-categorydata-id
code
**-countingindicator-code
**-credibilitycode
**-reportingdatetime
Reported as a
fact
Reported as a
fact
Reported as a
fact
—
19980816093
000.000
19980816094
000.000
19980816073
000.000
19980816193
000.000
[Mech Bde]
rd6
Reported
Yes
rd7
Reported
—
rd8
Reported
—
rd111
Inferred
—
[Mech Bde]
[Div G-2]
[Mech Bde]
rd6
rd7
rd8
rd111
19980816080000.000
19980816090000.000
19980816060000.000
19980816193000.000
—
—
—
—
(f) SECURITY-CLASSIFICATION
****-id
****-level-code
****-policy-text
****-caveat-text
sc6
Secret
NATO
Releasable to NATO
Note: **** = "security-classification"
419
V3.1.4
(g) CONTEXT
context-id
context-nametext
c4
Assessment
Situational
Assessment
sc6
(h) CONTEXT-ELEMENT
context-id
reporting-data-id
c4
c4
1
2
rd6
rd7
c4
3
rd8
(i) CONTEXT-ASSESSMENT
context-id *****-index
c4
1
*****-text
*****-limiting-factors-code reporting-data-id
This rather sizeable enemy unit is a threat to
our right flank, particularly given the operational
status of the Brigade. A careful watch must be
kept for any change in posture and disposition.
—
rd111
Note: ***** = "context-assessment"
14.4
Linking CONTEXT to REPORTING-DATA
14.4.1 Introduction
14.4.1.1 Multiple observations may require correlation or fusion of data. The
estimate or prediction based on these observations will result in new records. For example,
an intelligence analyst may create an intelligence appreciation about the location of an
enemy unit by basing it on a number of different observations that place nominally
different units at approximately the same place and the same time. The analyst then creates
an entry in OBJECT-ITEM-LOCATION with an associated entry in REPORTINGDATA. There is a need to be able to relate the derived and the original data. This is done
through CONTEXT-REPORTING-DATA-ASSOCIATION that relates a specific
CONTEXT as a subject with another REPORTING-DATA as an object. For example, an
analyst’s Reporting Data 4 may be associated through CONTEXT with previous
Reporting Data 1, Reporting Data 2, and Reporting Data 3.
14.4.1.2 This association between CONTEXT and REPORTING-DATA may
also be used to correct erroneous records.
14.4.2 Specification of CONTEXT-REPORTING-DATA-ASSOCIATION
14.4.2.1 The structure is illustrated in the figure below.
14.4.2.2 CONTEXT-REPORTING-DATA-ASSOCIATION is defined as "A
relationship of a CONTEXT as a subject and a REPORTING-DATA as an object." The
attributes are:
a.
b.
REPORTING-DATAs.
420
V3.1.4
c.
context-reporting-data-association-category-code—The specific value that
represents the type of relation of a specific CONTEXT with a specific
REPORTING-DATA. The domain values are: Implies; Is confirmed by; Is a
correction of; Is defined to be; Is negated by; Is superseded by.
CONTEXT
context-id
context-name-text
is-a-part-of
CONTEXT-ELEMENT
is-the-subject-of
CONTEXT-REPORTING-DATA -A SSOCIA TION
context-id (FK)
context-id (FK)
context-reporting-data-as sociation-category-code
is-cited-in /
is-ref erenced-to
is-the-object-of
REPORTING-DA TA
reporting-data-id
reporting-data-counting-indicator-c ode
reporting-data-reliability -code
reporting-data-timing-category -code
ref erence-id (FK)
Figure 122. Relating CONTEXT to REPORTING-DATA
14.5
Examples of REPORTING-DATA and CONTEXT Usage
Three examples illustrate uses of the CONTEXT and REPORTING-DATA
structures. The first example deals with a report that turns out to be false. The second
example shows how a previously reported HOLDING that has an error is supplanted by a
correct report, and contrasts the handling of a correction with a normal update. The third
example demonstrates how data that is derived from other data—as is likely in developing
intelligence assessments—can be linked to the source data.
14.5.1 Correction of Erroneous Data
14.5.1.1 Multi-National Division (MND) reports a sighting of the 8th Bradyland
Battalion at location Y on 19 November 2003 at 1122 hours. The reporting datetime is 19
November 2003 at 1125 hours. The data records are presented in the table below.
421
V3.1.4
Table 166. Initial MND Report
(a) OBJECT-ITEM
object-item-id
1
2
ORGANISATION
ORGANISATION
Multi National Division
8th BJ Battalion
(b) LOCATION
location-id
3043 [Y]
POINT
Note: The remainder of specification for notional point Y is not shown.
object-item-id
location-id
reporting-data-id
2
3043
1
915
(d) REPORTING-DATA
*-id
915
[RD1]
*-categorycode
*-countingindicatorcode
Reported
—
*-credibilitycode
*-reportingdatetime
Reported as a
fact
2003111911
2500.000
Absolute
1
915
20031119112200.000
—
14.5.1.2 On 19 November 2003 at 1420 hours, MND sends another report
stating that the 8th Bradyland Battalion had not been seen and, in fact, the previous report
was in error. The technique for handling this new information from the data perspective
entails, as the first step, the creation of a new instance of REPORTING-DATA with the
same effective datetime as in the previous report. The new record is shown in the table
below.
Table 167. The REPORTING-DATA Record for Second Report
(a) REPORTING-DATA
*-id
992
[RD2]
*-categorycode
*-countingindicator-code
Reported
—
*-credibilitycode
*-reportingdatetime
fact
000.000
Absolute
1
(b) REPORTING-DATA-ABSOLUTE-TIMING
992
20031119112200.000
—
422
V3.1.4
14.5.1.3 The next step is to link the new instance of REPORTING-DATA with
the previous one. This is done using the CONTEXT structure as shown in the table below.
The first REPORTING-DATA (RD1) is identified as an instance of CONTEXTELEMENT. The new instance of CONTEXT is linked via CONTEXT-REPORTINGDATA-ASSOCIATION record with the second REPORTING-DATA record (RD2), using
the value "Is negated by" for the context-reporting-data-association-category-code.
Table 168. Linkage of Two Instances of REPORTING-DATA
(a) CONTEXT
context-id
contextcategory-code
context-name-text
555097
Negation
Incorrect Data ABC
—
(b) CONTEXT-ELEMENT
context-id
reporting-data-id
555097
12301
915
(c) CONTEXT-REPORTING-DATA-ASSOCIATION
contextid
reportingdata-id
context-reporting-dataassociation-category-code
555097
992
Is negated by
14.5.2 Correcting and Updating Records
14.5.2.1 The MND reports that the 8th (Bradyland) Mechanised Infantry
Company holds 12 Leopards (11 operational), 5 mortars (4 operational) and 10 trucks (8
operational) (see left part of the figure below). In the second report, the MND reports that
the company has APCs instead of Leopards. The corrected holdings of the 8th Mechanised
Infantry Company are displayed in the right part of the figure.
8
BJ
8
BJ
12
11
12
11
5
4
5
4
10
8
10
8
Figure 123. An Example: Two Reports about HOLDINGs of Bradyland Unit
14.5.2.2 Representation of the two reports and their relationship requires several
steps. However, the first step is the identification of the objects or types for which data is
to be held. This is shown in the table below.
423
V3.1.4
Table 169. OBJECT-ITEMs and OBJECT-TYPEs of Interest
(a) OBJECT-ITEM
object-item-id
100001
ORGANISATION
[Multi National Division]
ORGANISATION
[8th Bradyland Mechanised Infantry Company]
100002
(b) OBJECT-TYPE
object-type-id
200001
200002
200003
200004
MATERIEL-TYPE
MATERIEL-TYPE
MATERIEL-TYPE
MATERIEL-TYPE
—
—
—
—
Battle tank, heavy
Armoured personnel carrier
Weapon, mortar
Truck
(c) AFFILIATION
affiliation-id
affiliation-category-code
8001
AFFILIATION-GEOPOLITICAL
(d) AFFILIATION-FUNCTIONAL-GROUP
affiliation-id
affiliation-functional-group-name-text
8001
Bradyland
(e) OBJECT-TYPE-AFFILIATION
object-type-id
affiliation-id
200001
200002
200003
200004
8001
8001
8001
8001
14.5.2.3 The first report of Bradyland unit holdings is shown as data in the table
below and those for the second report in the table below. In both cases, the three instances
of HOLDING are reported under the same instance of REPORTING-DATA as permitted
by the business rules adopted for the model.
Table 170. HOLDINGs of Bradyland Unit According to the First Report
(a) HOLDING
object-itemid
object-typeid
holdingindex
reportingdata-id
100002
100002
100002
200001
200003
200004
1
1
1
11
4
8
12
5
10
11001
11001
11001
reportingdatacategory-code
reportingdata-countingindicator-code
reporting-datacredibility-code
reporting-datareportingdatetime
reporting-datareportingorganisation-id
Reported
Yes
Reported as a
fact
20031201000000
.000
100001
(b) REPORTING-DATA
reporting
-data-id
11001
(RD1)
424
V3.1.4
HOLDINGs of Bradyland Unit According to the Second Report
(a) HOLDING
objectitem-id
objecttype-id
holdingindex
reportingdata-id
100002
200002
1
11
12
11002
100002
100002
200003
200004
2
2
4
8
5
10
11002
11002
(b) REPORTING-DATA
reporting
-data-id
11002
(RD2)
reportingdatacategory-code
Reported
Yes
Reported as a
fact
20031202000000
.000
100001
14.5.2.4 The procedure for recording the fact that the data in the first report is
corrected by the data in the second report entails creating a CONTEXT that has the first
instance of REPORTING-DATA (RD1) as an element. In turn, CONTEXT is linked via
CONTEXT-REPORTING-DATA-ASSOCIATION to the second instance of
REPORTING-DATA (RD2). The relationship of the first instance of REPORTING-DATA
to the second is characterised by the phrase "Is a correction of." The data records are
shown in the table below.
Table 171. Indication of Data Correction
(a) CONTEXT
context-id
contextname-text
23001
Correction
—
—
(b) CONTEXT-ELEMENT
context-id
reporting-data-id
23001
12304
110001 (RD1)
(c) CONTEXT-REPORTING-DATA-ASSOCIATION
context-id
reportingdata-id
23001
110002 (RD2)
Is a correction of
14.5.2.5 The previous table contains data that shows that the first report was
incorrect. By giving the context-reporting-data-association-category-code the value "Is a
correction of" the first HOLDINGs are "marked" as wrong. The value "Is a correction of"
indicates that the new HOLDINGs constitute a complete revision of a previous one that
was in error. Merely stating in the second report that there are APCs is not sufficient. This
could be interpreted as a statement that the Bradyland unit is now holding only APCs and
no mortars or trucks.
14.5.2.6 An update of a report offers a comparison with the example just
discussed. An update does not indicate that the previous report was wrong. It is merely
new data. A specific example is illustrated in the figure below. The operational
HOLDINGs have decreased due to heavy damage in the course of a battle. The data
records are presented below the figure.
425
V3.1.4
BJ
8
12
4
5
2
10
8
Figure 124. An Example: Update of HOLDINGs for Bradyland Unit
Table 172. Update of the Second Report
(a) HOLDING
objectitem-id
objecttype-id
holdingindex
reportingdata-id
100002
100002
100002
200002
200003
200004
2
3
3
4
2
8
12
5
10
11003
11003
011003
(b) REPORTING-DATA
reporting
-data-id
11003
(RD3)
reportingdata-categorycode
Reported
Yes
Reported as a
fact
20031203000000.
000
100001
14.5.2.7 It should be noted that in this case there is no need to link the new
instance of REPORTING-DATA with any previous one.
14.5.3 Deriving New Data from Existing Data
14.5.3.1 This example deals with the creation of new information from existing
sets of data. The process is sometimes referred to as fusion or correlation of data. The
scenario includes reports made by two NATO nations about the movement of a Bradyland
unit on 25 September 2003. One report is provided by the 2nd (DA) Battalion and two
reports by the 7th (SP) Battalion. The situation is graphically illustrated in the figure
below. The first panel shows the Bradyland unit as perceived by the Danish battalion. The
Danish battalion reports that the 8th Bradyland Battalion is at location W at 0900 hours
and is moving in a specified direction with speed v1. The second panel shows the situation
as first reported by the 7th (SP) Battalion that the Bradyland unit is located at position X at
1000 hours. The second report (third panel) by the Spanish indicates that the same
Bradyland battalion has moved to location Y with speed v2 in a specified direction at 1040
hours. Multi-National Division receives these reports and predicts that the Bradyland unit
is expected to be at position Z (Hill 251) at 1330 (fourth panel).
426
V3.1.4
I
II
II
DK
2
Hill 251
Hill 251
II
II
8
8
BJ
BJ
II
7
III
SP
IV
II
Hill 251
8
BJ
II
BJ
8
II
SP
7
Figure 125. An Example: Four Views of a Tactical Situation
14.5.3.2
The data resulting from these reports is presented in the table below.
Table 173. Three Reports on the Location of 8th Bradyland Battalion
(a) OBJECT-ITEM
object-item-id
1
2
3
4
ORGANISATION
ORGANISATION
ORGANISATION
ORGANISATION
Multi National Division
2nd DK Battalion
7th SP Battalion
8th BJ Battalion
(b) LOCATION
location-id
3041 (W)
3042 (X)
3043 [Y]
POINT
POINT
POINT
Note: The remainder of specification for notional point Y is not shown.
object-item-id
location-id
object-item-locationspeed-rate
reportingdata-id
4
4
4
3041
3042
3043
1
1
1
v1
99007
99008
99009
427
—
v2
V3.1.4
(d) REPORTING-DATA
*-id
*-categorycode
99007
Reported
99008
Reported
99009
Reported
*-credibilitycode
*-reportingdatetime
Absolute
2
Absolute
3
Absolute
3
fact
00.000
fact
00.000
fact
00.000
99007
20030925090000.000
—
99008
99009
20030925100000.000
20030925104000.000
—
—
14.5.3.3 Multi-National Division now uses the three reports to predict that the
Bradyland unit is expected to be at position Z (Hill 251) at 1330, as shown in the fourth
panel of the previous figure. The data for this prediction is presented in the table below
where the effective datetime is later than the reporting datetime.
Table 174. The Predicted Location of the 8th Bradyland Battalion
(a) LOCATION
location-id
3044 [Point Z]
POINT
(b) OBJECT-ITEM-LOCATION
object-item-id
location-id
reporting-data-id
4
3044
1
99010
(c) REPORTING-DATA
*-id
*-categorycode
*-credibilitycode
*-reportingdatetime
99010
Inferred
Reported as a
fact
200309251215
00.000
*-timing*-reportingcategory-code organisation-id
[Absolute]
1
99010
20030925133000.000
—
14.5.3.4 Since the prediction by the Multi-National Division is derived, it is
necessary to record this fact in the database. The results are shown in the table below.
428
V3.1.4
Table 175. Construction of a CONTEXT Record from Three REPORTING-DATA Records
(a) CONTEXT
context-id
contextname-text
555091
Correlation
Data for
estimation
—
(b) CONTEXT-ELEMENT
context-id
reporting-data-id
555091
555091
555091
1
2
3
99007
99008
99009
14.5.3.5 Once the CONTEXT records based on the three reports are created, the
appropriate instance of CONTEXT is linked to the instance of REPORTING-DATA that
points to the data derived by MND. The result is shown in the table below.
Table 176. Linking Derived Data with Original Data
context-id
reportingdata-id
555091
99010
Implies
14.6
Specification of CONTEXT-OBJECT-ITEM-ASSOCIATION and Its Status
14.6.1 CONTEXT can be related to OBJECT-ITEM in order to provide
amplifying information about an instance of OBJECT-ITEM and, conversely, an
OBJECT-ITEM can be made part of a CONTEXT.
14.6.2 Even data without a direct relationship to OBJECT-ITEM within the data
structure can be given significance. For example, the fact that an enemy unit is moving to
a position from which it would pose an immediate threat to a friendly unit may be
implicitly seen from a map display; however, it can be made explicit in situational
awareness by linking the data about enemy position and movement to the position or
status of the friendly unit.
14.6.3 CONTEXT-OBJECT-ITEM-ASSOCIATION is defined as "A relationship
of a CONTEXT as a subject with an OBJECT-ITEM as an object." Its structure is
illustrated in the figure below. The attributes are:
a.
b.
c.
context-object-item-association-category-code—The specific value that
represents the type of relationship between a specific CONTEXT and a
specific OBJECT-ITEM in a specific CONTEXT-OBJECT-ITEMASSOCIATION. The domain values are: Includes; Is relevant to.
429
V3.1.4
CONTEXT
OBJECT-ITEM
context-id
context-name-text
is-the-subject-of
object-item-id
is-the-object-of
ORGA NISATION
context-id (FK)
object-item-id (FK)
organis ation-id.object-item-id (FK)
context-object-item-association-category-code
has /
is-ascribed-to
establishes /
is-established-by
context-id (FK)
object-item-id (FK)
context-object-item-association-status-index
context-object-item-association-status-c ategory-code
context-object-item-association-status-eff ective-datetime
context-object-item-association-status-establishing-organisation-id.organis ation-id (FK)
Figure 126. Relating CONTEXT to OBJECT-ITEM
14.6.4 The current validity of a relationship between an instance of OBJECTITEM and an instance of CONTEXT can be recorded via entity CONTEXT-OBJECTITEM-ASSOCIATION-STATUS. It is defined as "A record of the perceived state of a
specific CONTEXT-OBJECT-ITEM-ASSOCIATION as determined by the establishing
organisation." The attributes are:
a.
b.
c.
context-object-item-association-status-index—The unique value, or set of
characters, assigned to represent a specific CONTEXT-OBJECT-ITEMASSOCIATION-STATUS for a specific CONTEXT-OBJECT-ITEMASSOCIATION and to distinguish it from all other CONTEXT-OBJECTITEM-ASSOCIATION-STATUSs for that CONTEXT-OBJECT-ITEMASSOCIATION.
d.
context-object-item-association-status-category-code—The specific value
that indicates whether a specific CONTEXT-OBJECT-ITEMASSOCIATION-STATUS refers to the beginning or termination of the
association. The domain values are: End; Start. The domain value set for this
association-status-category-code.
430
V3.1.4
14.7
e.
context-object-item-association-status-effective-datetime—The
character
string representing a point in time that designates the beginning of the period
of effectiveness for a specific CONTEXT-OBJECT-ITEM-ASSOCIATIONSTATUS.
f.
context-object-item-association-status-establishing-organisation-id—The
identifier of the ORGANISATION that establishes a specific CONTEXTOBJECT-ITEM-ASSOCIATION-STATUS (a role name for object-item-id).
Specification of ACTION-CONTEXT and Its Status
14.7.1 Introduction
The structure for ACTION-CONTEXT and its status is illustrated in the figure
below. The association of CONTEXT with ACTION has two different uses. A CONTEXT
can be attached to ACTION in order to provide amplifying or normative information. This
use is discussed in Section 16.7. The ACTION-CONTEXT entity also permits an instance
of ACTION to be included as part of an instance of CONTEXT using the value "Is
included in" for action-context-category-code. This functionality is important when
CONTEXT structure is used to define operationally meaningful data sets. The current
validity of relationships between an instance of ACTION and an instance of CONTEXT
may be recorded via the entity ACTION-CONTEXT-STATUS.
14.7.2 Specification of ACTION-CONTEXT and Its Status
14.7.2.1 ACTION-CONTEXT is defined as "A relationship between a specific
ACTION and a specific CONTEXT." Its attributes are:
a.
b.
c.
action-context-index—The unique value, or set of characters, assigned to
represent a specific ACTION-CONTEXT for a specific ACTION and a
specific CONTEXT and to distinguish it from all other ACTIONCONTEXTs for that ACTION and that CONTEXT.
d.
action-context-category-code—The specific value that represents the nature
of the ACTION-CONTEXT as it relates to a specific ACTION and a specific
CONTEXT. The domain values are: Desired; Final state, actual; Final state,
planning; Initial state, actual; Initial state, planning; Intermediate state,
actual; Intermediate state, planning; Is included in; Maximum required;
Minimum required.
431
V3.1.4
ACTION
CONTEXT
action-id
context-id
action-name-text
context-name-text
security-class ification-id (FK)
is-placed-within
prov ides-circumstances-for
OBJECT-ITEM
object-item-id
ACTION-CONTEXT
action-id (FK)
context-id (FK)
action-context-index
action-context-category-code
has /
is-ascribed-to
ORGA NISATION
organis ation-id (FK)
ACTION-CONTEXT-STA TUS
action-id (FK)
context-id (FK)
action-context-index (FK)
action-context-status-index
action-context-status-c ategory-code
action-context-status-eff ective-datetime
action-context-status-establishing-organisation-id (FK)
establishes /
is-established-by
Figure 127. Specification of ACTION-CONTEXT
14.7.2.2 ACTION-CONTEXT-STATUS is defined as "A record of the
perceived state of a specific ACTION-CONTEXT as determined by the establishing
organisation." Its attributes are:
a.
b.
c.
action-context-index—The unique value, or set of characters, assigned to
represent a specific ACTION-CONTEXT for a specific ACTION and a
specific CONTEXT and to distinguish it from all other ACTIONCONTEXTs for that ACTION and that CONTEXT.
d.
action-context-status-index—The unique value, or set of characters, assigned
to represent a specific ACTION-CONTEXT-STATUS for a specific
ACTION-CONTEXT and to distinguish it from all other ACTIONCONTEXT-STATUSs for that ACTION-CONTEXT.
e.
action-context-status-category-code—The specific value that indicates
whether a specific ACTION-CONTEXT-STATUS refers to the beginning or
termination of the association. The domain values are: End; Start. The
and is defined in the set association-status-category-code.
432
V3.1.4
14.8
f.
action-context-status-effective-datetime—The character string representing a
point in time that designates the beginning of the period of effectiveness for a
specific ACTION-CONTEXT-STATUS.
g.
action-context-status-establishing-organisation-id—The identifier of the
ORGANISATION that establishes a specific ACTION-CONTEXTSTATUS (a role name for object-item-id).
Operational Information Groups and Related Structures
14.8.1 Introduction
14.8.1.1 The concept of an operational information group was created in order
to have sets of information that are subject to standard definition of their content and that
represent the owning organisation’s view at a given time, such as the current friendly
picture. Once an instance of OPERATIONAL-INFORMATION-GROUP is created, it is
to be maintained under the same identifier but the content of the instance is permitted to
change over time. The latter requirement results in the addition of status entities that
enable the tracking of the data that is included in CONTEXT (and consequently, the
OPERATIONAL-INFORMATION-GROUP) at any given time. The status entities
enforce one of the basic design goals: maintenance of data integrity at all times.
14.8.1.2 One of the primary motives for the concept of informational groups is
to provide a basis for information exchange among conformant systems. Instead of simply
exchanging new data within the scope of an exchange contract that covers a defined part
of the model, OPERATIONAL-INFORMATION-GROUP itself would serve as the basis
for a contract with the expectation that it is an operationally more rational approach. Thus,
each unit’s view of some aspect of the area of operations would be available to other units
that fall within military exchange protocols.
14.8.1.3 Previous sections provide specifications for entities linked to
CONTEXT. This section completes the specification of OPERATIONALINFORMATION-GROUP itself and its association with ORGANISATION including the
status of the association. The structure is illustrated in the figure below. Examples are
included at the end of the section.
14.8.2 Specification of OPERATIONAL-INFORMATION-GROUP
The entity OPERATIONAL-INFORMATION-GROUP is defined as "A
CONTEXT that encompasses a set of pre-defined operational information." Its attributes
are:
a.
operational-information-group-id—The
context-id
of
a
specific
OPERATIONAL-INFORMATION-GROUP (a role name for context-id).
b.
operational-information-group-category-code—The specific value that
represents the class of OPERATIONAL-INFORMATION-GROUP. The
domain values are: Composed plan; Correlated enemy and unknown;
Friendly and neutral (organisational); Globally significant; Friendly and
neutral (non-organisational); Uncorrelated enemy and unknown.
433
V3.1.4
The category attribute enables the user to classify the contents of a specific
OPERATIONAL-INFORMATION-GROUP within the scope of the allowable domain set
for the attribute.
CONTEXT
OBJECT-ITEM
context-id
object-item-id
context-name-text
ORGA NISATION
operational-inf ormation-group-id (FK)
operational-inf ormation-group-category-code
is-cited-by
P
OPERATIONAL-INFORMATION-GROUP-ORGANISATION-ASSOCIA TION
operational-inf ormation-group-organisation-assoc iation-index
operational-inf ormation-group-organisation-assoc iation-category-code
establishes /
is-established-by
has /
is-ascribed-to
P
OPERATIONAL-INFORMATION-GROUP-ORGANISATION-ASSOCIA TION-STATUS
operational-inf ormation-group-organisation-assoc iation-index (FK)
operational-inf ormation-group-organisation-assoc iation-status-index
operational-inf ormation-group-organisation-assoc iation-status-category-code
operational-inf ormation-group-organisation-assoc iation-status-ef f ective-datetime
operational-inf ormation-group-organisation-assoc iation-status-establishing-organisation-id (FK)
Figure 128. OPERATIONAL-INFORMATION-GROUP and Related Entities
14.8.3 Specification of OPERATIONAL-INFORMATION-GROUPORGANISATION-ASSOCIATION and Its Status
14.8.3.1 The
entity
OPERATIONAL-INFORMATION-GROUPORGANISATION-ASSOCIATION is defined as "A relationship of a specific
OPERATIONAL-INFORMATION-GROUP with a specific ORGANISATION for
specifying the role of the ORGANISATION with respect to the OPERATIONALINFORMATION-GROUP." The attributes are:
a.
context-id
of
a
specific
b.
434
V3.1.4
c.
operational-information-group-organisation-association-index—The unique
value, or set of characters, assigned to represent a specific OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATION
for
a
specific OPERATIONAL-INFORMATION-GROUP and a specific
ORGANISATION and to distinguish it from all other OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATIONs for that
OPERATIONAL-INFORMATION-GROUP and that ORGANISATION.
d.
operational-information-group-organisation-association-category-code—The
specific value that represents the type of relationship between a specific
and
a
specific
ORGANISATION in a specific OPERATIONAL-INFORMATIONGROUP-ORGANISATION-ASSOCIATION. The domain values are: Is
under operational responsibility of; Is under proxy responsibility for.
14.8.3.2 The
entity
OPERATIONAL-INFORMATION-GROUPORGANISATION-ASSOCIATION-STATUS is defined as "A record of the perceived
state of a specific OPERATIONAL-INFORMATION-GROUP-ORGANISATIONASSOCIATION as determined by the establishing organisation." Its attributes are:
a.
context-id
of
a
specific
b.
c.
operational-information-group-organisation-association-index—The unique
value, or set of characters, assigned to represent a specific OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATION
for
a
specific OPERATIONAL-INFORMATION-GROUP and a specific
ORGANISATION and to distinguish it from all other OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATIONs for that
OPERATIONAL-INFORMATION-GROUP and that ORGANISATION.
d.
operational-information-group-organisation-association-status-index—The
unique value, or set of characters, assigned to represent a specific
OPERATIONAL-INFORMATION-GROUP-ORGANISATIONASSOCIATION-STATUS
for
a
specific
OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATION
and
to
distinguish it from all other OPERATIONAL-INFORMATION-GROUPORGANISATION-ASSOCIATION-STATUSs for that OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATION.
e.
operational-information-group-organisation-association-status-categorycode—The specific value that indicates whether a specific OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATION-STATUS
refers to the beginning or termination of the association. The domain values
are: End; Start. The domain value set for this attribute is shared with one or
more other attributes and is defined in the set association-status-categorycode.
f.
operational-information-group-organisation-association-status-effectivedatetime—The character string representing a point in time that designates
435
V3.1.4
the beginning of the period of effectiveness for a specific OPERATIONALINFORMATION-GROUP-ORGANISATION-ASSOCIATION-STATUS.
g.
operational-information-group-organisation-association-status-establishingorganisation-id—The identifier of the ORGANISATION that establishes a
specific
OPERATIONAL-INFORMATION-GROUP-ORGANISATIONASSOCIATION-STATUS (a role name for object-item-id).
14.8.4 Examples of CONTEXT Usage for OIGs
14.8.4.1 Addition of a Valid OIG Object
The example in the table below shows how a unit is attached to an existing
instance of a CONTEXT. Sub-table (a) represents the instance of CONTEXT to which
new information about an OIG object is to be added. Sub-tables (b) define the object to be
101st Airborne Division. Sub-tables (c) indicate that Object u1 is to be included as part of
Context c1. Sub-tables (d), (e), and (f) provide the essential typing and status information
about the 101st Airborne Division that is to be included as part of the Context c1. (Note:
Other elements of information, such as location, could have been included, but are omitted
for simplicity.) Finally, Sub-tables (g) attach the typing and status information of Object
u1 to Context c1.
Table 177. Adding an Object to an OIG
(a) CONTEXT
context-id
context-name-text
c1
OPERATIONAL
INFORMATION GROUP
NO Brig N Friendly and neutral
(organisational) OIG
(b1) OBJECT-ITEM
object-item-id
object-item-categorycode
u1
u11
ORGANISATION
ORGANISATION
NO Brigade
(b2) ORGANISATION
organisation-id
u1
u11
UNIT
UNIT
(b3) UNIT
unit-id
u1
u11
101 Div
NO Bde
(c1) CONTEXT-OBJECT-ITEM-ASSOCIATION
context-id
object-item-id
context-object-itemassociation-category-code
c1
u1
Includes
(c2) CONTEXT-OBJECT-ITEM-ASSOCIATION-STATUS
contextid
objectitem-id
*-index
*-categorycode
*-effectivedatetime
*-establishingorganisation-id
c1
u1
i1
Start
dt1
u11
Note: * = "context-object-item-association-status"
436
V3.1.4
object-item-id
object-type-id
reporting-data-id
u1
ut1
i1
r1
(e) OBJECT-ITEM-HOSTILITY-STATUS
object-item-id
**-index
**-code
reporting data-id
u1
i1
Friend
r3
Note: ** = "object-item-hostility-status"
(f1) OBJECT-ITEM-STATUS
object-item-id
***-index
***-category-code
reporting-data-id
u1
i1
ORGANISATION-STATUS
r2
Note: *** = "object-item-status"
(f2) ORGANISATION-STATUS
****-id
****operationalstatus-code
u1
i1
Operational
****************-cbrncommand- commitmen fire****dressmodet-statusavailability and-controlcode state-code
code
role-code
-code
****operationalstatusqualifier-code
—
—
—
—
—
MOPP 1
Note: **** = "organisation-status"
(g1) REPORTING-DATA
*****id
*****-categorycode
r1
r2
r3
Reported
Reported
Reported
*****-credibility-code
*****-reliabilitycode
Reported as plausible Completely reliable
Note: ***** = "reporting-data"
(g2) REPORTING-DATA-ABSOLUTE-TIMING
*-reporting-data-id
*-effective-start-datetime
r1
r2
d1
d1
r3
d1
Note: * = "reporting-data-absolute-timing"
(h1) CONTEXT-ELEMENT
context-id
reporting-data-id
c1
c1
i1
i2
r1
r2
(h2) CONTEXT-ELEMENT-STATUS
context
context-id
element-index
c1
c1
i1
i2
**index
**-categorycode
**-effectivedatetime
**-establishingorganisation-id
i1
i1
Addition
Addition
dt1
dt1
u11
u11
Note: ** = "context-element-status"
14.8.4.2 Rationale for Using CONTEXT-OBJECT-ITEM-ASSOCIATION
14.8.4.2.1 Using only CONTEXT-ELEMENT to associate objects with a
CONTEXT may pose a problem as described in the example below. The use of
CONTEXT-OBJECT-ITEM-ASSOCIATION as illustrated by this example solves the
437
V3.1.4
potential problem. The example uses the term overlay but the concept applies equally to
OIGs.
14.8.4.2.2 Consider an air defence unit with its type (OBJECT-ITEM-TYPE),
status (OBJECT-ITEM-STATUS), location (OBJECT-ITEM-LOCATION), and a
CONTEXT representing an air defence overlay. One could conform to a strict business
rule saying that in order to associate this unit to the air defence overlay its type, status and
location must be associated with the context through CONTEXT-ELEMENT (which is in
accordance with the business rule with respect to OIGs). Sub-tables (a) through (g) in the
table below represent the situation in outline form.
Table 178. Definition of an Air Defence Overlay
(a) CONTEXT
context-id
context-name-text
c2
Air defence overlay
(b) OBJECT-ITEM
object-item-id
u2
Air defence unit
(c) REPORTING-DATA
reporting-data-id
r3
r4
r5
object-item-id
reporting-data-id
u2
r3
(e) OBJECT-ITEM-STATUS
object-item-id
reporting-data-id
u2
r4
(f) OBJECT-ITEM-LOCATION
object-item-id
reporting-data-id
u2
r5
(g) CONTEXT-ELEMENT
context-id
reporting-data-id
c2
c2
c2
1
2
3
r3
r4
r5
14.8.4.2.3 Now consider an artillery unit being introduced. The artillery unit is
supposed to be part of an artillery overlay. The artillery unit shares reporting data records
with the air defence unit, a case that may occur in start-state data. The obvious way to
associate the artillery unit with the artillery overlay would be to associate the
REPORTING-DATA records with the CONTEXT through CONTEXT-ELEMENT, as
shown in the table below.
438
V3.1.4
Table 179. Definition of an Artillery Overlay
(a) CONTEXT
context-id
context-name-text
c3
Artillery overlay
(b) OBJECT-ITEM
object-item-id
u3
Artillery unit
(c) REPORTING-DATA
reporting-data-id
r3
r4
r5
object-item-id
reporting-data-id
u3
r6
(e) OBJECT-ITEM-STATUS
object-item-id
reporting-data-id
u3
r7
(f) OBJECT-ITEM-LOCATION
object-item-id
reporting-data-id
u3
r8
(g) CONTEXT-ELEMENT
context-id
reporting-data-id
c3
c3
c3
1
2
3
r3
r4
r5
14.8.4.2.4 The result of this operation would be that both units would be
associated with both overlays! One way to resolve this problem is to use CONTEXTOBJECT-ITEM-ASSOCIATION. The problem is solved by associating the air defence
unit with the air defence overlay and artillery unit with the artillery overlay, as shown in
the table below.
Table 180. Proper Association of OBJECT-ITEMs with Overlays
context-id
object-item-id
c2
c3
u2
u3
14.8.4.3 Removal of a Unit from an OIG
The table below shows that Unit u1 was removed from Context c1 at (dt2).
439
V3.1.4
Table 181. Removing a Unit from OIG
contextid
objectitem-id
*index
*-categorycode
*-effectivedatetime
*-establisingorganisation-id
c1
u1
I2
End
dt2
u11
Note: * = "context-object-item-association-status"
14.8.4.4 Association of CONTEXTs
If an object is part of an overlay (as in Section 14.7.2), then it is possible to link the
overlay (say, Context c4) with the Context c1 (one of the NO OIGs). The data are shown
in the table below.
Table 182. Associating CONTEXTs
(a) CONTEXT
context-id
context-name-text
c1
OPERATIONALINFORMATION-GROUP
NO Brig N Friendly and
neutral (organisational) OIG
c4
Overlay
Operations overlay
(b) CONTEXT-ASSOCIATION
subjectcontext-id
objectcontext-id
context-associationcategory-code
C4
C1
Is part of/Is sub-context of
(c) CONTEXT-ASSOCIATION-STATUS
subjectcontext-id
objectcontext-id
*index
*-categorycode
*-effectivedatetime
*-establishingorganisation-id
C4
C1
I1
Start
dt3
u11
Note: * = "context-association-status"
14.9
Security Classification Specification
14.9.1 The entity SECURITY-CLASSIFICATION accommodates three data
concepts as illustrated in the figure below. The entity was made independent in order to
make the three data concepts available in multiple places in the JC3IEDM data
specification.
440
V3.1.4
applies-to /
is-marked-with
component-header-content-id
component-header-content-topic-heading-text
provides-to
CONTEXT
provides-to
context-id
provides-to
context-name-text
applies-to /
is-marked-with
NETWORK-SERVICE
REFERENCE
network-id (FK)
reference-id
plan-order-id (FK)
plan-order-header-content-index
plan-order-header-content-name-text
plan-order-header-content-nickname-text
plan-order-header-content-serial-number-text
plan-order-header-content-sponsor-type-text
plan-order-header-content-time-zone-code
plan-order-header-content-datetime
plan-order-header-content-message-reference-number-text
Figure 129. Specification of SECURITY-CLASSIFICATION
14.9.2 The entity SECURITY-CLASSIFICATION is defined as "The security
classification applicable to an information resource within the domain of classified
security information." Its attributes are:
a.
b.
security-classification-level-code—The specific value that represents the
security classification level for the information resource. The domain values
are: Unmarked; Unclassified; Restricted; Confidential; Secret; Top secret.
441
V3.1.4
c.
security-classification-policy-text—The character string assigned to
represent the organisation that defines the rules relating to the security
handling for the information resource.
d.
security-classification-caveat-text—The character string assigned to
represent, for the information resource, an indication of an additional specific
sensitivity, a dissemination control, or an informal marking.
14.9.3 Security classification policies represent the organisation that defines the
rules relating to the security handling for the information resource are taken from the
NCIRC TC and examples are listed below.
NATO
NATO/EAPC
NATO/PFP
NATO/EU
NATO/Ukraine
NATO/Russia
European Union
United Nations
Nation
Not otherwise
specified
The policy governing the security classification is the one defined by the North
Atlantic Treaty Organisation.
The policy governing the security classification is the one agreed between the North
Atlantic Treaty Organisation and the Euro-Atlantic Partnership Council.
The policy governing the security classification is

JC3IEDM-Main-3.1.4

Transcription

Similar documents

jc3iedm overview - MIP Public Home

sovereign lady - Great Haywood Boat Sales

JC3IEDM Metamodel

information exchange policy vocabulary (iepv)

Taklimat Pengukuhan Pelan Strategik Organisasi

an Information System Management Model

JC3IEDM-Annex O-XML-3.1.4.doc

SOMA and SoaML Overview

Unipart Group of Companies Senior Management

Malay Named Entity Recognition Based on Rule-Based