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

Slides:



Advertisements
Similar presentations
Three-Step Database Design
Advertisements

UJTL Ontology Effort TMCM Nelson And Marti Hall. Overview Vision for the UJTL and METLs Scenario Mapping Findings Proposed POA&M outline.
Copyright © 2006 Data Access Technologies, Inc. Open Source eGovernment Reference Architecture Approach to Semantic Interoperability Cory Casanave, President.
1 Building scientific Virtual Research Environments in D4Science Paul Polydoras University of Athens, Greece.
Copyright Irwin/McGraw-Hill Data Modeling Prepared by Kevin C. Dittman for Systems Analysis & Design Methods 4ed by J. L. Whitten & L. D. Bentley.
Chapter 3 Data Modeling Copyright © 2014 McGraw-Hill Education. All rights reserved. No reproduction or distribution without the prior written consent.
Access Control Methodologies
Overview of OASIS SOA Reference Architecture Foundation (SOA-RAF)
OASIS Reference Model for Service Oriented Architecture 1.0
Object-Oriented Analysis and Design
©Ian Sommerville 2006Software Engineering, 8th edition. Chapter 8 Slide 1 System models.
NaLIX: A Generic Natural Language Search Environment for XML Data Presented by: Erik Mathisen 02/12/2008.
Security Extensions to the DOD Architecture Framework Kevin Richardson Information Assurance Lab Auburn University Computer Science and Software Engineering.
Pittsburgh, PA Copyright 2004, Carnegie Mellon University. All rights reserved. Concepts for Writing Effective Process Guidance Suzanne Garcia.
Introduction and Overview “the grid” – a proposed distributed computing infrastructure for advanced science and engineering. Purpose: grid concept is motivated.
1 ITC242 – Introduction to Data Communications Week 12 Topic 18 Chapter 19 Network Management.
Analysis Concepts and Principles
Creating Architectural Descriptions. Outline Standardizing architectural descriptions: The IEEE has published, “Recommended Practice for Architectural.
Web Service Architecture Part I- Overview and Models (based on W3C Working Group Note Frank.
Chapter 2 Network Models.
Executive Dashboard Systems Secure CITI Adam Zagorecki April 30, 2004.
UML Class Diagrams: Basic Concepts. Objects –The purpose of class modeling is to describe objects. –An object is a concept, abstraction or thing that.
Domain-Specific Software Engineering Alex Adamec.
Introduction to UDDI From: OASIS, Introduction to UDDI: Important Features and Functional Concepts.
SC32 WG2 Metadata Standards Tutorial Metadata Registries and Big Data WG2 N1945 June 9, 2014 Beijing, China.
2002 October 10SFWR ENG 4G030 Translating from English into Mathematics SFWR ENG 4G Robert L. Baber.
Chapter 4 System Models A description of the various models that can be used to specify software systems.
ITEC224 Database Programming
Interaction Modeling. Introduction (1) Third leg of the modeling tripod. It describes interaction within a system. The class model describes the objects.
Architecting Web Services Unit – II – PART - III.
High Level Architecture Overview and Rules Thanks to: Dr. Judith Dahmann, and others from: Defense Modeling and Simulation Office phone: (703)
Army Net-Centric Data Strategy Center Of Excellence (ANCDS) Army Data Harmonization and Integration Working Group (ADHIWG) Sever Ciorlian ANCDS Team Lead.
Computer Science 101 Database Concepts. Database Collection of related data Models real world “universe” Reflects changes Specific purposes and audience.
Requirement Engineering. Review of Last Lecture Problems with requirement Requirement Engineering –Inception (Set of Questions) –Elicitation (Collaborative.
This material was developed by Duke University, funded by the Department of Health and Human Services, Office of the National Coordinator for Health Information.
Headquarters U. S. Air Force I n t e g r i t y - S e r v i c e - E x c e l l e n c e © 2008 The MITRE Corporation. All rights reserved From Throw Away.
Adaptive Hypermedia Tutorial System Based on AHA Jing Zhai Dublin City University.
SponsorProblem AssessRisk SolutionStrategy Measures of Merit (MoM) Human & OrganisationalIssues Scenarios Methods & Tools Data Products
Software Architecture and Design Dr. Aldo Dagnino ABB, Inc. US Corporate Research Center October 23 rd, 2003.
System models l Abstract descriptions of systems whose requirements are being analysed.
Sommerville 2004,Mejia-Alvarez 2009Software Engineering, 7th edition. Chapter 8 Slide 1 System models.
FEA DRM Management Strategy Presented by : Mary McCaffery, US EPA.
NATO UNCLASSIFIED Bi-SC Concept for Connecting NATO and National Training Capabilities IPR Angel San Jose Martin ACT Project Manager Wolfhard Schmidt.
 Copyright ProcessVelocity, LLP Slides intended for informational purposes only. CMM and Capability Maturity Model are registered in the U.S. Patent.
Distribution and components. 2 What is the problem? Enterprise computing is Large scale & complex: It supports large scale and complex organisations Spanning.
Assessing the Military Benefits of NEC Using a Generic Kill-Chain Approach David Nevell QinetiQ Malvern 21 ISMOR September 2004.
Unified Modeling Language User Guide Section 4 - Basic Behavioral Modeling Chapter 16 - Use Cases Chapter 17 - Use Case Diagrams.
Introduction to Grids By: Fetahi Z. Wuhib [CSD2004-Team19]
Consultative process for finalizing the Guidance Document to facilitate the implementation of the clearing-house mechanism regional and national nodes.
Architecture View Models A model is a complete, simplified description of a system from a particular perspective or viewpoint. There is no single view.
1 Technical & Business Writing (ENG-715) Muhammad Bilal Bashir UIIT, Rawalpindi.
Distributed Data Analysis & Dissemination System (D-DADS ) Special Interest Group on Data Integration June 2000.
JRA1.4 Models for implementing Attribute Providers and Token Translation Services Andrea Biancini.
Object storage and object interoperability
Johnson Carmichael Kay Kummerfeld Hexel1 Context Evidence and Location Authority the disciplined management of sensor data into context models.
Introduction to Active Directory
Computer Security: Principles and Practice
Copyright (c) 2014 Pearson Education, Inc. Introduction to DBMS.
 To explain why the context of a system should be modelled as part of the RE process  To describe behavioural modelling, data modelling and object modelling.
I n t e g r i t y - S e r v i c e - E x c e l l e n c e As of: 3/1/2016 Air Force Weather Agency CEISC Committee Focus Shift - Proposed Modification to.
Network Centric Planning ---- Campaign of Experimentation Program of Research IAMWG Dr. David S. Alberts September 2005.
Business System Development
facilitating the Net-enabled Ecosystem
Chapter 10 Understanding Work Teams
Physical Data Model – step-by-step instructions and template
Unified Modeling Language
Distribution and components
UML Class Diagrams: Basic Concepts
Ch 15 –part 3 -design evaluation
Entity/Data Representation in Different Contexts, Frames of Reference, and Context-Changing Events Hans W. Polzer March 21, 2018.
Presentation transcript:

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

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

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

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

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

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

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)

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)

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

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

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

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

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

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)

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