|2. Overview of the lc2iedm data specification|
2.2 Operational Requirements Underlying the LC2IEDM Specification
Table 2. Categories of Battlespace Information
4. Operational Context
2.3 Concepts Underlying the Data Model
2.4 Overview of Specification for Battlespace Situation
Table 3. Five Key Entities and Their Roles
2.4.2 Identification of Battlespace Elements
2.4.3 OBJECT-ITEM Hierarchy
Table 4. Definition of OBJECT-ITEMs
2.4.4 OBJECT-TYPE Hierarchy
2.4.5 Model Structures that Involve only an OBJECT-TYPE or an OBJECT-ITEM
2.4.6 Classification of OBJECT-ITEMs by Type
2.4.7 Specifying Status of OBJECT-ITEMs
2.4.8 Associations between OBJECT-ITEMs
Table 5. Valid OBJECT-ITEM Associations
2.4.10 Assignment of Establishments to OBJECT-ITEMs
2.4.13 Positioning of and Geometry for OBJECT-ITEMs
2.1.1 This chapter focusses on the Conceptual Data Model and the operational requirements it is based upon. Included in this chapter are:
(a) An overview of the operational requirements;
(b) An explanantion of the concepts underlying the data model;
(c) An extended overview of the principal features of the data model; and
(d) Example of potential uses.
2.1.2 This chapter serves as an introduction to the detailed exposition of the data model specification to be found in Chapters 3 through 17.
2.2.1 While there is no universally accepted statement of information requirements, Table 1 is the base set of information that was considered in the specification.
Table 1. Summary of Battlespace Information Requirements
2.2.2 Table 2 provides further detail, and an assessment of the relevance to the specification. This assessment should be viewed in the context of applicability for the international exchange of information between national C2 elements as well as the potential use of LC2IEDM for exchange of information between C2 elements of multinational formations.
2.3.1 The Generic Hub data model is intended to represent the core of the data identified for exchange across multiple subfunctional areas and multiple views of the requirements. Toward that end, it lays down a common approach to describing the information to be exchanged in a command and control (C2) environment.
a. The structure is meant to be generic enough to accommodate all joint, land, sea, and air environment concerns. Currently, the model addresses primarily land operations.
b. The data model describes all objects of interest in the battlespace, e.g., organisations, persons, equipment, facilities, geographic features, weather phenomena, and military control measures such as boundaries.
c. Battlespace objects are generically typed and described in accordance with a military taxonomy and specifically addressed as an item. All battlespace items must be classified as being of some type (e.g. Tank Callsign T14C is an item of type "Challenger").
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 battlespace.
e. It should be possible to assign a location to any item in the battlespace. In addition, various geometric shapes need to be represented in order to allow a commander to plan, direct, and monitor operations. Examples include boundaries, corridors, restricted areas, minefields, and any other control measures or symbolgy needed by the commanders and their staff.
f. The status of items needs to be maintained.
g. The planned assignment of resources by type to a type of battlespace objects is described as an establishment. These establishments are currently described as tables of organisations, equipment, or personnel, are basically fixed (e.g. standard Canadian Light Infantry Battalion) and must be representable in the model.
h. The actual assignment of resources by type to a specific battlespace item is described as a holding (for example the holding of 1e Battalion Les Voltigeurs). The model must reflect information such as the composition of an organisation in terms of subordinate organisation types, equipment types, and personnel types.
i. There is a need to record relationships between specific battlespace items. Key among these is the specification of command relationships in permanent or temporary organisational and task structures.
j. The model must support the specification of current, past, and future employment of battlespace items or types st be capable of being recorded.
k. The data for all battlespace objects, whether friendly or hostile, should be recorded in the same data structure.
l. Provision must be made for the identification of reporting organisations, the effective and reporting times, and an indication of the validity of the data.
2.3.2 The use of free text is to be avoided as much as possible, since there cannot be an agreed understanding of the contents.
2.3.3 Since some of the important rules for managing information in the battlespace cannot be represented in a data model, reliance needs to be placed on textual supplements, often referred to as “business rules.”
2.3.4 The intent is to specify the minimum set of data to be exchanged. The nations are free to expand their own data structures to cater to additional data representations. It is also understood that the model is to be structured in such a way so as to easily accommodate any conceivable extension.
184.108.40.206 This section describes the major features of the data, e.g., the identification of battlespace objects items or their types, their make-up, status, location, and associations.
220.127.116.11 A basic concept in data modelling is an entity, i.e., any distinguishable person, place, thing, event, or concept about which information is to be kept. The properties of an entity are referred to as attributes. The attributes make explicit the data that are to be recorded for each concept of interest. This chapter describes the data model only at the entity level. Subsequent chapters contain descriptions of the fully attributed data model.1
18.104.22.168 The Generic Hub structure is based on ten independent entities, five of which are key. These key entities are of fundamental importance in generating the structure of the data model and are defined in Table 3. They include OBJECT-ITEM, OBJECT-TYPE, CAPABILITY, LOCATION, and ACTION. The remaining independent entities are introduced in subsequent sections and are CANDIDATE-TARGET-LIST, CONTEXT, REFERENCE, REPORTING-DATA, and RULE-OF-ENGAGEMENT.
22.214.171.124 The relationships of the key entities are illustrated in Figure 2. The many-to-many relationships are denoted by a line with a dot at each end. This is permissible at a conceptual level, but must be resolved into one-to-many relationships before a model can be considered complete. The resolution of many-to-many relationships can lead to complex structures and the balance of the paper describes how it has been done for GH4.
Figure 2. Key Entities of the Generic Hub Data Model3
126.96.36.199 The battlespace consists of a large number of objects, each with its own set of characteristics. Objects may be described as a class or type rather than as individually identified items, for example, a tank, a helicopter, a howitzer, a rifle, an armoured brigade, an infantryman.
188.8.131.52 It is necessary to make the distinction between actual instances and a type in describing objects of interest. Actual instances are catered for by use of OBJECT-ITEM, e.g., 2 (SP) Armoured Cavalry Brigade. Types are recorded as OBJECT-TYPEs (e.g., a Light Infantry Battalion).
184.108.40.206 The distinction between OBJECT-TYPE and OBJECT-ITEM is vital. Implicit in this distinction is the fact that data relating to OBJECT-TYPEs will tend to be static (i.e., the values of the attributes are not likely to change very often over time), whereas the values of attributes of 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 callsign, actual fuel level, munitions holdings, and current operational status of a specific tank are characteristics of an OBJECT-ITEM.
220.127.116.11 The relationship between the two entities enables each OBJECT-ITEM to be classified as an OBJECT-TYPE, thereby inheriting characteristics of the type.
18.104.22.168 OBJECT-ITEM stands at the top of its own hierarchy with ORGANISATION, PERSON, MATERIEL, FACILITY, and FEATURE as its immediate subtypes. This subtyping is illustrated on the right-hand side of Figure 3. The subtypes are defined in Table 4.
22.214.171.124 The properties of an OBJECT-ITEM that are of interest are entered as attributes in the appropriate subtype entities.
Figure 3. First Two Levels of OBJECT-TYPE and OBJECT-ITEM Subtree Hierarchies4
126.96.36.199 OBJECT-TYPE is also treated as a family of five subtype entities: ORGANISATION-TYPE, PERSON-TYPE, MATERIEL-TYPE, FACILITY-TYPE, and FEATURE-TYPE.
188.8.131.52 The first level subtype hierarchy for OBJECT-TYPE is further subtyped in LC2IEDM in order to capture all the attributes needed for information exchange.
A resolution of the many-to-many relationships between OBJECT-TYPE and OBJECT-ITEM as well as the objects to themselves (e.g., recursive links of OBJECT-TYPE to OBJECT-TYPE) leads to a full data structure. This is described below within the scope of Figure 4.
Figure 4. Model Structures That Involve Only OBJECT-TYPE or OBJECT-ITEM5
184.108.40.206 The many-to-many relationship between OBJECT-ITEM and OBJECT-TYPE is resolved by the entity OBJECT-ITEM-TYPE (Figure 5). One of the advantages of this construct is that it permits an instance of OBJECT-ITEM, which has its own descriptive data as an item, to share in the properties of its corresponding OBJECT-TYPE. This minimises the amount of data to be stored on the item side, since the data common to a class can be stored on the type side.
Figure 5. Classifying OBJECT-ITEMs According to Type6
220.127.116.11 The entity OBJECT-ITEM-TYPE enables the retention of multiple records of the classification that may be given to a specific OBJECT-ITEM. A history of classifications may be kept, such as that of a moving object whose nature or identity is clarified over a period of time. 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.
18.104.22.168 OBJECT-ITEM-STATUS is a record of the perceived condition of a specific OBJECT-ITEM. One of the attributes of OBJECT-ITEM-STATUS records a particularly significant item of information: the perceived hostility classification of a specific OBJECT-ITEM. The entity-level data structure is illustrated in Figure 6. 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.
22.214.171.124 Just as in the case of OBJECT-ITEM-TYPE, the data structures permit 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.
Figure 6. The Specification of Status for an OBJECT-ITEM
126.96.36.199 There is a clear requirement to link different OBJECT-ITEMs and describe the relationship that exists between them. A specific main battle tank (MBT), for instance, can be owned by a certain armoured infantry brigade. A division may have full command of three brigades, or full command of two and operational command of the third if the third belongs to another nation.
188.8.131.52 Those OBJECT-ITEM associations that are deemed necessary to support C2 are recorded in LC2IEDM as the nine pairs of associations shown as a matrix in Table 5.
184.108.40.206 These nine OBJECT-ITEM relationships are specified by a category code, for which example values are shown to indicate the nature of the association.
a. FACILITY-FACILITY-ASSOCIATION: Connected to, Contains, Utilises.
b. FACILITY-FEATURE-ASSOCIATION: Encloses, Is affected by, Is bounded by, Is contained within, Is partially bounded by, Is partially contained within.
c. CONTROL-FEATURE-CONTROL-FEATURE-ASSOCIATION: Is contained in, Is end of, Is part of, Is start of, and Is successor of.
d. CONTROL-FEATURE-GEOGRAPHIC-FEATURE-ASSOCIATION: Coincides with, Coincides with part of, Is partially delineated by.
e. ORGANISATION-FACILITY-ASSOCIATION: Controls, Disestablishes, Establishes, Occupies, Uses.
f. ORGANISATION-CONTROL-FEATURE-ASSOCIATION: Controls, Establishes, Is bounded by, Is constrained or enabled by, Is user of.
g. ORGANISATION-MATERIEL-ASSOCIATION: Controls, Employs, Is accounting authority for, Is captor of, Transports.
h. ORGANISATION-ORGANISATION-ASSOCIATION: Has full command of, Has operational command of, Has operational control of, Has tactical command of, Has tactical control of, Has as alternate, Has attached, Has as reserve, Has under command for administration.
i. ORGANISATION-PERSON-ASSOCIATION: Has as a liaison officer, Has on assignment, Has on attachment, Is captor of, Is under command of.
220.127.116.11 The primary relationship among subtypes of OBJECT-TYPE is based on the concept of “establishment.” “Establishment” consists of the OBJECT-TYPEs that an OBJECT-TYPE is intended or authorised to have, e.g., the tables of organisation and equipment for a unit type or the weapons configuration of an attack helicopter. A specific statement may be that a French engineer regiment type unit has a war-time establishment of 500 regular troops, 150 drivers, 100 vehicles, 20 mine layers, and 20,000 mines.
18.104.22.168 The conceptual structure is illustrated in Figure 7. The cluster entity Establishment associates an OBJECT-TYPE with other OBJECT-TYPEs. The various components that make up that Establishment are represented in cluster entity Establishment-Detail. An Establishment-Detail is the number of a specific OBJECT-TYPE authorised by a specific OBJECT-TYPE Establishment.
Figure 7. The Concept of Establishment
22.214.171.124 The actual data structure is illustrated in Figure 8, which shows all the Establishment entities in grey. There are two entities implementing the Establishment concept both of which are supported by various Establishment Detail entities as follows:
a. ORGANISATION-TYPE-ESTABLISHMENT indicates what OBJECT-TYPEs an organization is supposed to have. These details are specified in several Establishment Detail entities as follows:
(1) ORGANISATION-TYPE-ESTABLISHMENT-ORGANISATION-TYPE-DETAIL handling details pertaining to one ORGANISATION-TYPE being composed of other ORGANIZATION-TYPEs
(2) ORGANISATION-TYPE-ESTABLISHMENT-PERSON-TYPE-DETAIL that handles the data pertaining to types of persons belonging to an establishment (e.g. Sgt Infantry)
(3) ORGANISATION-TYPE-ESTABLISHMENT-MATERIAL-TYPE-DETAIL that handles the data pertaining to types of materiel belonging to an establishment (e.g. Tank Leopard 2)
b. MATERIEL-TYPE-ESTABLISHMENT indicates what Materiel a specicifc MATERIEL-TYPE is supposed to consist of. A standard example would be an equipment parts hierarchy. The details would be stored in the Establishment Detail entity called MATERIEL-TYPE-ESTABLISHMENT-MATERIEL-TYPE-DETAIL.
Figure 8. Specifying Establishments for ORGANISATION-TYPE and MATERIEL-TYPE
A particular OBJECT-TYPE may have more than one Establishment at any given time, and a specific OBJECT-ITEM may have more than one Establishment associated with it at a given time. This is catered for by the use of MATERIEL-MATERIEL-TYPE-ESTABLISHMENT and ORGANISATION-ORGANISATION-TYPE-ESTABLISHMENT (see Figure 9). This permits statements of the following kind: 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. The establishment data structure (as described in the previous section) would detail the types and numbers of subordinate organisations, equipment, and personnel for that division.
Figure 9. Assigning Establishments to ORGANISATION and MATERIEL
126.96.36.199 OBJECT-ITEM and OBJECT-TYPE can be related through a HOLDING, showing how many of each OBJECT-TYPE are held by a specific OBJECT-ITEM together with the status of each. Thus, HOLDING allows quantities of an OBJECT-TYPE (e.g., Challenger MBT) to be attributed to a particular OBJECT-ITEM (e.g., a specific UK Armoured Regiment) that are at a particular status (e.g., operational) at a particular time. The structure of HOLDING is shown in Figure 10.
Figure 10. The HOLDING Entity between OBJECT-ITEMs and OBJECT-TYPEs
188.8.131.52 Whereas an Establishment indicates what an organization or materiel is supposed to be composed of, the Holding concept captures what the organization or material actually contains. In other words, the difference between HOLDING and Establishment is that whereas Establishment details what an OBJECT-TYPE is authorised to have in terms of other OBJECT-TYPEs, HOLDING details what an OBJECT-ITEM actually has (or is thought to have) at a particular time. For example, at a certain point in time, the 14th FR Engineer Regiment may have 300 regular troops, 100 drivers, 75 vehicles, 10 mine layers, and 16,000 mines. This concept enables the establishment of logistic/personnel replenishment requirements as well as the assessment of organizational capability.
184.108.40.206 There is a requirement to specify and monitor the CAPABILITY of battlespace objects or their types. The entity CAPABILITY can record the potential ability to do work, perform a function or mission, achieve an objective, or provide a service. It allows a set of generic capabilities through category and subcategory codes in the CAPABILITY entity itself. Additional information can be held in the subtypes illustrated in Figure 11.
220.127.116.11 The entity CAPABILITY is linked to OBJECT-ITEMs and OBJECT-TYPEs in three ways:
a. Specifying the expected or normal capability for OBJECT-TYPEs.
b. Estimating or recording the actual capability of OBJECT-ITEMs.
c. Stating (through ACTION-REQUIRED-CAPABILITY) the required capability of OBJECT-ITEMs or OBJECT-TYPEs when they are needed as resources for carrying out ACTIONs.
The links to OBJECT-ITEM and OBJECT-TYPE are described below. The link to ACTION is discussed in a subsequent section.
18.104.22.168 Expected/Normal Capability. The entity OBJECT-TYPE-CAPABILITY-NORM is defined as the standard value of a specific CAPABILITY of an OBJECT-TYPE. Since the entity relates to types rather than items, the data it contains will tend to be static. The entity represents staff planning data concerning the capabilities of different OBJECT-TYPEs. 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.
Figure 11. Specifying the Capabilities of Battlespace Objects
22.214.171.124 Actual Capability. The capabilities of individual OBJECT-ITEMs may differ from the norm due to attrition. 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. As well as recording detail of friendly troops, OBJECT-ITEM-CAPABILITY could hold a threat analysis for individual enemy OBJECT-ITEMs, e.g., an enemy tank regiment may have demonstrated a capability to move at a faster rate than its OBJECT-TYPE-CAPABILITY-NORM.
126.96.36.199 Required Capability. It is necessary to be able to specify a required CAPABILITY in order to complete an ACTION. This enables optimal resource usage for planning as well as for managing resources during the life of an ACTION. ACTION-REQUIRED-CAPABILITY is defined as the specific CAPABILITYs needed to execute a given task (i.e. an assigned ACTION). This subject is elaborated in paragraph 2.4.17.
188.8.131.52 The entity LOCATION permits the recording of point locations, as well as various open/closed multi-dimensional boundaries, such as areas of responsibility for units, axes of advance, or three dimensional air corridors. To achieve this, the LOCATION entity captures two distinct but related concepts of interest to planners and operators in the battlespace, namely the specification of the:
a. Position/location of items in the battlespace
b. Geometry of battlespace features.
184.108.40.206 The specification of position and geometry is provided by LOCATION and its subtypes POINT, LINE, SURFACE, and GEOMETRIC-VOLUME, as shown in Figure 12. The figure includes only part of the structure under LOCATION.
220.127.116.11 The linkage to battlespace objects is shown by many-to-many relationships because there may be multiple roles (a current relation, a planned relation, or a proposed relation) or because multiple location reports may be collected for each individual OBJECT-ITEM.
18.104.22.168 The specification of geometry and location can be either absolute with respect to Earth co-ordinates or relative with respect to an arbitrary point.
Figure 12. Specifying Position and Geometry for OBJECT-ITEMs
22.214.171.124 The FACILITY and FEATURE subtypes of OBJECT-ITEM are related directly to LOCATION, and therefore FACILITYs and FEATUREs can be mapped to POINTs, LINEs, SURFACEs, and GEOMETRIC-VOLUMEs. Examples of features include rendezvous points, supply routes, restricted fire areas, and air corridor). For each instance of FEATURE, a meaning is given to the geometry by specifying the type for the FEATURE. In case of FACILITY, the geometry refers only to the physical characteristics of a FACILITY, such as height, width, length, and horizontal outline.
126.96.36.199 The three other subtypes of OBJECT-ITEM (MATERIEL, ORGANISATION, and PERSON) are related only to the POINT subtype of LOCATION. For example, the location of an enemy military UNIT with respect to its centre of mass would be specified as a point co-ordinate and may also include a bearing and speed vector to express movement.
188.8.131.52 If location by POINT only is not adequate, geometry can be specified by associating a specific FEATURE with the battlespace object. As an example, if the assembly area of an armoured division (an ORGANISATION) must be recorded, then a suitable CONTROL-FEATURE can be defined and a SURFACE specified for it. A similar extension applies to FACILITY if any other geometry besides its intrinsic shape needs to be specified.
The entities discussed so far directly address the information about battlespace objects and their types. Two additional entities—REPORTING-DATA and CONTEXT—enable the specification of amplifying information and offer a mechanism for combining such information to make use of the underlying data in more complex ways.
A considerable amount of the information about the battlespace situation consists of perceptions or interpretations by persons or organisations. These generally relate to dynamic parts of information—those having to do with OBJECT-ITEM locations, status, holdings, associations, and classification. The REPORTING-DATA entity provides a mechanism for recording amplifying data for such records and includes attributes for the responsible reporting ORGANISATION, the effective date and time for the estimate, the duration for which the estimate is valid, the reporting date and time of the estimate, and the degree of validity of the estimate. In addition, external information can be cited by using the entity REFERENCE in connection with REPORTING-DATA.
184.108.40.206.1 The REPORTING-DATA and CONTEXT structure is shown in Figure 13. It permits any number of REPORTING-DATAs to be linked together to form a new REPORTING-DATA. Thus, 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 ORGANISATION-POINT with an associated entry in REPORTING-DATA that points through CONTEXT to all the data being used. For example, an analyst’s Reporting Data 4 may be associated with previous Reporting Data 1, Reporting Data 2, and Reporting Data 3.
Figure 13. Specifying Amplifying Information and Combining Such Information
220.127.116.11.2 The new information that is created by linking existing information is itself an estimate that needs to be described by a suitable REPORTING-DATA. This is done through CONTEXT-REPORTING-DATA-ASSOCIATION which relates a specific CONTEXT as a subject with another REPORTING-DATA as an object. The relationship is characterised by the following values: Implies, Is confirmed by, Is corrected by, Is defined to be, Is negated by, Is superseded by.
The entity ACTION, together with its related entities, is capable of specifying and describing all activities and events that occur in the battlespace. An ACTION is viewed as a simple statement in which something carries out an activity to affect something else at some time. The "something" is described by OBJECT-TYPEs and OBJECT-ITEMs. Thus, OBJECT-TYPEs and OBJECT-ITEMs are related to ACTION in two distinct ways: as resources and as objectives.7 ACTIONs can be characterised by the following statement:
RESOURCEs carry out and are utilised in ACTIONs,
which are focused against OBJECTIVEs.
For example, the 11th (NL) Air Mobile Brigade may use 4 Chinook helicopters (an ACTION-RESOURCE) to transport 100 troops to a landing zone (ACTION-OBJECTIVEs). Complex statements, such as operations orders, can be constructed by relating simple statements.
The basic model structure for ACTION is shown in Figure 14; its features are described in the following sections.
Figure 14. The Primary Model Structure for ACTION
18.104.22.168.1 To cater to two different data requirements, ACTION has two subtypes:
22.214.171.124.2 The entity ACTION-TASK is defined as an ACTION that is being or has been planned. It concerns those ACTIONs over which control can be exercised or which are predicted (such as friendly operations, and those enemy activities that have been predicted as a result of intelligence assessment). It can represent actions that are typically found in plans, orders, and requests.
126.96.36.199.3 An 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 a new ACTION-TASK. For example, the encounter of a scattered minefield near the landing zone will result in an evasive manoeuvre. An observer in the battlespace may also use ACTION-EVENT to report his sightings that result from a recorded ACTION-TASK of which he has no knowledge.
188.8.131.52.1 To establish a tasking there is a need to establish an aim and allocate a resource to execute it. Therefore the entities ACTION-RESOURCE and ACTION-OBJECTIVE have been introduced in order to be able to relate OBJECT-ITEMs and OBJECT-TYPEs to ACTION as assets or aims.
184.108.40.206.2 The entity 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 OBJECT-ITEMs and OBJECT-TYPEs that have been specified as the things executing, things being used in or allocated to, or things whose use is qualified in some way, in carrying out a specific ACTION.
220.127.116.11.3 The entity ACTION-OBJECTIVE is defined as the focus, in terms of an OBJECT-ITEM or OBJECT-TYPE, 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.
18.104.22.168.1 Requirement. There is a need to monitor the effectiveness of ACTIONs that are executed in the battlespace as well as to estimate the potential effects of planned or pending ACTIONs.
22.214.171.124.2 ACTION-EFFECT. ACTION-EFFECT is defined as a perceived effectiveness of a specific ACTION against a specific battlespace item or its type. For example, the enemy force has been diminished by at least 50 percent and the enemy position was captured.
126.96.36.199.3 Measuring Effects and Collateral Damage. The ACTION-EFFECT estimate specifies a quantity if the objective is an OBJECT-TYPE, or a fraction if the objective is an OBJECT-ITEM. Battlespace performance could be evaluated by comparing ACTION-EFFECTs to stated ACTION-OBJECTIVEs. It should be noted that ACTION-EFFECT permits the capture of information about effects of ACTIONs on objects that are not necessarily the objectives of the ACTION. This is referred to as collateral damage.
188.8.131.52.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 Generic Hub provides two associative entities that specify the dependencies between ACTIONs and allow for the creation of hierarchies:
a. ACTION-FUNCTIONAL-ASSOCIATION caters to functional relationships; and
b. ACTION-TEMPORAL-ASSOCIATION caters to time-specific dependencies between ACTIONs.
184.108.40.206.2 ACTION-FUNCTIONAL-ASSOCIATION. The entity ACTION-FUNCTIONAL-ASSOCIATION records the relationship of a specific ACTION as being dependent on, supporting, or derived from another specific ACTION. The categories of association are described by the following phrases: Has as a sub-ACTION, In order that, In response to/depending on, Is a modification of, 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 represented in Figure 15, 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.
Figure 15. ACTION Hierarchy
220.127.116.11.3 ACTION-TEMPORAL-ASSOCIATION. The timings of sub-actions that are part of a complex action will frequently be interdependent. The entity ACTION-TEMPORAL-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).
18.104.22.168.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 so that the sub-tasks are carried out in the correct sequence.
22.214.171.124.5 Relative Temporal Dependence. In many cases, the required start time of the overall action is not 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 permits specification of the relative order in which ACTIONs are to occur without stating any actual times.
126.96.36.199.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.
188.8.131.52.7 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.
184.108.40.206.1 There is a need to monitor 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 dates and times.
b. ACTION-EVENT-STATUS reports the perceived appraisal of the actual progress of an ACTION-EVENT. The progress is estimated fractionally at a given date and time; therefore, fraction 0 would coincide with a starting date and time and fraction 1 with the end.
220.127.116.11.2 Using Effectiveness and ACTION-TASKS. ACTION-TASK-STATUS specifies the progress of the ACTION-TASK towards completion without referring to the effectiveness of the ACTION-TASK vis a vis specified objectives. This can be used to monitor the progress of occurring ACTION-TASKs, as well as to provide an estimate of future progress of planned, expected, or ordered ACTION-TASKs.
Five additional concepts add to the scope of data that can be captured to enrich a specification of ACTION. The five concepts include:
a. CAPABILITYs that are required for an ACTION
b. A role that an ORGANISATION may have with respect to an ACTION-TASK
c. Constraints or guidance on the use of an ACTION-RESOURCE
d. Conditions imposed by rules of engagement
The relationship of these concepts to ACTION is illustrated in Figure 16.
18.104.22.168.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).
22.214.171.124.2 Use of this construct permits the matching of the available capabilities of battlespace 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, it alerts the planner that he should re-allocate replacement assets.
Figure 16. Data Structures for Enhancing the Functionality of ACTION
126.96.36.199.1 Specification Additional Roles. The addition of an associative entity between ACTION-TASK and ORGANISATION (ORGANISATION-ACTION-TASK-ASSOCIATION) permits the explicit specification of any role or roles that an ORGANISATION may have in relation to an ACTION-TASK over and above those covered by ACTION-OBJECTIVE or ACTION-RESOURCE. The roles could include initiation, co-ordination, planning, authorisation, oversight, distribution of orders and so on.
188.8.131.52.2 Specification Commander's Intent/Concept of Operations. The second, important function of the entity ORGANISATION-ACTION-TASK-ASSOCIATION is to enable the specification of commander’s intent or concept of operations for an ACTION-TASK. Generally, this would be the top-level or mission task statement for a unit.
ACTION-RESOURCE-EMPLOYMENT is the procedure to be used for utilising a specific OBJECT-TYPE or OBJECT-ITEM against an objective. 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 RULE-OF-ENGAGEMENT lists a set of approved constraints which may be invoked as appropriate to govern the way a given activity is to be executed. A rule is attached to an ACTION through ACTION-RULE-OF-ENGAGEMENT.
184.108.40.206 Context for an ACTION
220.127.116.11.1 The entity ACTION-CONTEXT, through its linkage to REPORTING-DATA via 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 record constraints on ACTIONs.
18.104.22.168.2 In general, the 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.
22.214.171.124.1 Target Lists. The model provides a mechanism for identifying OBJECT-ITEMs and OBJECT-TYPEs as candidate targets for use during operational planning. CANDIDATE-TARGET-LIST is a list of battlespace items and types that have potential value for destruction or exploitation and is nominated by competent authority for consideration in planning battlespace activities. Note that the specification of types allows for the identification of a class of targets that can be engaged as required, rather than as discrete battlespace items. The specific item or type nominations are contained in CANDIDATE-TARGET-DETAIL. Lists can be linked to ACTION-TASKS and details can be identified with ACTION-OBJECTIVES.
126.96.36.199.2 Structuring of Target Lists. The CANDIDATE-TARGET-LIST structure can be used to create prioritised lists of inidvidually identified target candidates. For example, Division A could nominate a specific enemy brigade for attack, a specific radar site for intercept activity, and a specific 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—command-and-control centres, armoured fighting vehicles, POL supplies, and fire-control radars in that order. Target lists can also be nested.
188.8.131.52.3 Target List Format. The Target List can accommodate various identification schemes including ABCA, BE, FIBE, Organisational and direct site number assignment.
184.108.40.206 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 illustrated in Figure 17.
Figure 17. A Mechanism for Handling Intelligence and Combat Information
220.127.116.11 An 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 co-ordinate as a result of a search for enemy units in a prescribed region. This information would be recorded in an entity called ORGANISATION-POINT that is linked to REPORTING-DATA. The REQUEST-ANSWER-ELEMENT would then be able to indicate the correct REPORTING-DATA that is part of the REQUEST-ANSWER.
18.104.22.168 A 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. Since the data recorded in REQUEST-ANSWER is itself an estimate, REQUEST-ANSWER is linked to REPORTING-DATA through a second relationship which permits the REQUEST-ANSWER to be used as data together with other estimates.
22.214.171.124 The Need
There is a need to specify time8 points and time periods having a specific military significance; 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. There is also a need to be able to specify time in two ways:
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).
126.96.36.199.1 The Generic Hub provides some specifications of time in the entities where they are needed as absolute time. However, time specifications for most of the dynamic data are made through REPORTING-DATA as the effective time for the data that REPORTING-DATA references. There are two exceptions where relative time may be used. One is in the ACTION structure as discussed in Section 188.8.131.52; the other is functionality provided through the REPORTING-DATA structure as illustrated in Figure 18.
Figure 18. Timing through REPORTING-DATA
184.108.40.206.2 A chronological point with respect to the standard calendar is reported through the subtype REPORTING-DATA-ABSOLUTE-TIMING. It specifies a chronological point as a date and a 24-hour clock time. The date is defined with respect to a chosen origin in the Julian calendar and the clock time is defined with respect to Universal Time.
220.127.116.11.3 If the effective time is to be relative, then it is reported through another subtype of REPORTING-DATA: REPORTING-DATA-RELATIVE-TIMING. The chronological point is an offset with respect to some defining ACTION-TASK that serves as the zero reference for the time scale. The logic is that relative time has meaning only in relation to planning activity.
18.104.22.168 An overview of the Generic Hub data model is presented in Figure 19. The nine 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 portrays the contents of the battlespace: what is out there, what does it have, what is it supposed to have, where is it, what is its status, what are its relationships with other objects in the battlespace. Most of the static reference data is to be found among these entities, such as OBJECT-TYPE and Establishment, and to a lesser degree OBJECT-ITEM and its Associations.
22.214.171.124 The upper part is focused on 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.
Figure 19. High-Level View of the Generic Hub Data Model
126.96.36.199 The entity 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.
188.8.131.52 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.
184.108.40.206 This paper concludes with an example to illustrate the use of the data structures.
220.127.116.11 This section illustrates selected features of the model as they may be of interest to a military unit engaged in operations..
18.104.22.168 Figure 20 below shows how an ORGANISATION is related to other key entities that are subtypes of either OBJECT-TYPE or OBJECT-ITEM. On the left side, its direct connection to OBJECT-TYPE represent the holdings that it may have in MATERIEL-TYPE, ORGANISATION-TYPE, and PERSON-TYPE. An establishment that may be assigned to an ORGANISATION is represented by a link to ORGANISATION-TYPE-ESTABLISHMENT, which may have as its components the types in MATERIEL-TYPE, ORGANISATION-TYPE, and PERSON-TYPE. On the right side, the connections to the subtypes of OBJECT-ITEM are the various associations that ORGANISATION may have, including one to itself.
Figure 20. ORGANISATION in Relation to Other Entities
22.214.171.124 An ORGANISATION also has a relationship with the subtype POINT of LOCATION to specify its position.
The model supports the planning process by capturing information at each stage, and permitting a variety of planning options to be examined. The steps in planning 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 a ACTION-TASK based on its CAPABILITY-NORM. Having identified the requirement for troop-carrying vehicles, this step requires the allocation of, for example, 12 Blackhawk helicopters.
f. In order to determine what resources are available for this ACTION, search for OBJECT-ITEMs whose OBJECT-ITEM-CAPABILITY matches the CAPABILITY-NORM for their type. 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.
Once the planning process is complete, an order can be generated by simply converting the status of a particular plan, or a series of plans, from “plan” to “order.”
2.5.4 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:
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. ACTION-TASK-STATUS may be used to provide updates on the dynamics of the battlespace (e.g., minefield laying 70 percent complete, estimated time of completion + 2 hours).
c. ACTION-EVENT-STATUS provides a means of reporting unplanned activity (e.g., flooding started at 1626 on 18 July 2000).
d. OBJECT-ITEM associations can be used to specify a friendly/enemy order of battle (in particular, ORGANISATION-ORGANISATION-ASSOCIATION).
e. 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).
The details of the model are described in the balance of this paper in segments that are functionally related views of the model. These segments usually cluster around the independent entities. In this way, the basic parts, or building blocks, of the Generic Hub are characterised, together with examples of their functionality.
(This page intentionally left blank)