1. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 1HWP May 03 Battlespace Objects Hans Polzer 19 May 2003

2. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 2HWP May 03 Overview Background/Motivation Battlespace Objects Context Relevance to IERs and IORA tables Summary

3. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 3HWP May 03 Background/Motivation C2 systems are models of the battlespace  Imperfect, incomplete, non-congruent representations of the physical and conceptual domains  Typically assume some operational context(s) oUsually from the C2 system’s frame of reference  Capture significant unstructured/unmodeled information about battlespace objects C2 system interoperation specified by IERs  Usually focused on the communicating nodes  Information exchanged between nodes is oMotivated by specific operational/tactical tasks/missions oAbout specific battlespace objects involved in the tasks/missions oDescribed in conceptual or physical/relative terms

4. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 4HWP May 03 Background/Motivation Physical implementations of C2 systems  Require selection of specific technologies and protocols  Limit information collected and represented about battlespace objects  Limit information flow between systems Removing these limitations/incompatibilities is not enough  Task and operational contexts use different identifiers for the same battlespace objects  Naming conventions and authorities don’t exist for many battlespace objects or are too narrowly scoped

5. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 5HWP May 03 Existing Approaches Message standards  Establish specific information exchanges to support specific operational tasks – message types  USMTF, APP-9, ANEP-38, ANEP-51, Link-16  Relatively few naming standards oSame battlespace objects can have different IDs in different messages oAggregation and different operational perspectives create naming issues oPhysical engagement oriented; relative identifiers (e.g., track/target ID)  No concept of reference servers (like Internet DNS) Database exchange and XML messages  Really a special type of message exchange focused on software “processability” by C2 nodes

6. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 6HWP May 03 Existing Approaches Are necessary but not sufficient Focus on technical aspects of the problem Focus on physical attributes and not conceptual attributes of the battlespace Deflect attention from the larger battlespace object representation and naming problem Address internodal IER issues  Not larger network-centric, multi-nodal, echelon, domain, national information sharing issue  Some issues cannot be addressed at the individual nodal system level

7. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 7HWP May 03 Battlespace Objects Real world objects of significance in military operations  May be hypothetical for doctrinal and weapon system development purposes, or exercise/training purposes  May be conceptual – units, orders, targets, tasks, enemy intent, etc.  May be physical – vehicles, soldiers, weapons, structures, etc. Not computer system objects!  But may be represented in a C2 system info model  May include unstructured information (video, text, etc)

8. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 8HWP May 03 Battlespace Objects Both things and processes (e.g., tasks, tactics) Subjects of IERs May have “absolute” and context-specific identifiers (e.g., hull number, target ID) Diverse naming authorities  Local to a C2 system (e.g., track ID)  Specific to an operation (e.g., task force names, plan ID)  Specific to a Service or country (e.g. hull numbers)  International (e.g., IRCS)

9. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 9HWP May 03 Battlespace Objects Names or other identifiers may be more operationally significant for some objects if  Multiple C2 nodes must share information about them to execute tasks (e.g., cooperative engagement)  C2 nodes must share them with non-C2 systems Hierarchical or other associations among battlespace objects require a broker/model  Enemy capabilities assessment  Task force composition, available weapons  Support/supporting relationships, including supply  Track ID to Order of Battle ID mapping

10. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 10HWP May 03 Battlespace Object Context Battlespace objects may have different identities in different contexts  Tail number, mission number, call sign, target ID, NSN, track ID, aircraft type, force package ID, ULN, UIC…  C2 nodes may use only one or a few of these  Mapping between the identities usually requires a third party system and/or a naming authority for contexts Users may have information relevant to battlespace objects and their context  Not reflected in the C2 information system model  Tied to model through one or more identifiers

11. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 11HWP May 03 Battlespace Object Context Identity attributes are not the only important ones  Location, operation context, time, affiliation can also be important for cross C2 interoperability IERs typically are specific to or assume an operational context for battlespace objects  A specific operation/mission/task  Current time (vice some relative or past/future time)  Specific task organization/responsibilities Can lead to interoperability problems when context is not shared across C2 systems

12. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 12HWP May 03 Battlespace Object Context Make context an explicit part of the information exchange whenever possible  Avoids ambiguity, detects context mismatches  Permits exchange to be propagated beyond C2 nodes involved – information reporting/aggregation  Battlespace object attribute values may vary based on operational context  Facilitates training/exercise/rehearsal interoperability Context is itself a complex concept to capture/represent  Simple context models may suffice for most situations

13. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 13HWP May 03 Relevance to IERs and IORA Tables IORA tables are a form of IER definition  Organized by major functional grouping and subfunctions/tasks  Unspecific as to C2 nodes involved  Information exchange/remarks describe battlespace objects/context implicitly or explicitly Example from IORA tables – Warfare area control  Engagement list for an effector under “target designation” function (list itself is not mentioned)  Objects to be engaged for some purpose (targets on the list)  The effector(s) to be used (weapon-target pairing)  Rules of engagement  Engagement order  Danger volume

14. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 14HWP May 03 Relevance to IERs and IORA Tables Battlespace object analysis indicates that this IORA table entry  Does not ID the effector or ID who/what assigned the targets to it, or effector naming/capability/status/location source Who/what is a battlespace object; effector is a battlespace object Set of effectors in the task force available and capable of engaging the targets Platforms (ID and location) hosting effectors are all battlespace objects  Does not ID any secondary effectors that might engage the target or source of effector status/capability information  Does not ID the targets other than as target ID oAuthority of target ID not mentioned, or mapping to track ID or other object ID to target ID (e.g. tail number, unit ID, structure/facility ID, etc.) oFriendly/no-strike asset locations in target area not mentioned  Does not ID the purpose of the engagement (task being performed or effect desired/expected)

15. NATO UNCLASSIFIED NIAG/SG-76: C2 Interoperability Slide 15HWP May 03 Summary Battlespace objects are key elements in the real world modeled in/shared by C2 systems Have different IDs in different contexts Naming/ID services/conventions are key to interoperability at platform level and above  Other interoperability considerations still apply Network-centric C2 requires more explicit context representation and ID services  Information broker services needed at various echelons  Consideration of what battlespace objects are involved in an IER/IORA entry will identify needed services