Battlespace Objects

1. Battlespace Objects Hans Polzer 19 May 2003

2. Overview • Background/Motivation • Battlespace Objects • Context • Relevance to IERs and IORA tables • Summary

3. 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) • Usually 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 • Motivated by specific operational/tactical tasks/missions • About specific battlespace objects involved in the tasks/missions • Described in conceptual or physical/relative terms

4. 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. 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 • Same battlespace objects can have different IDs in different messages • Aggregation and different operational perspectives create naming issues • Physical 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. 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. 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. 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. 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. 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. 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. 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. 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. 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 • Authority 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.) • Friendly/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. 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