Get documents about "C4ISR Data Ontology
Document Sample
C4ISR Data Ontology
Presented by:
Mr. George Herc
RDECOM CERDEC Software Engineering Directorate
In support of CELCMC SEC
06 April 2005
Page 1
DoD Net-Centric Data Strategy
DoD Net-Centric Consumer
Searches metadata
Producer
catalogs to find data Describes content
Data Goals: Analyzes metadata to
determine context of data
using metadata
Posts metadata in
found catalogs and data in
shared space
Pulls selected
data based on
• Ensure data is: understanding
of metadata
Security Services
(e.g., PKI,
SAML)
• Visible Metadata
Catalogs Shared Data
Ubiquitous
Global
• Available Space
Network
• Understandable
Enterprise &
Community
Web Application Services
• Trusted Sites (e.g., Web) Metadata
Registries
• Interoperable
• Responsive to users’ needs
COI / Developer
• Institutionalize Data Posts to and uses
Management metadata registries
to structure data and
document formats for
reuse and
interoperability
Strategy enabled by COIs, metadata, registries, catalogs and shared data spaces
Page 2
DoD Net-Centric Data Strategy Guidance
DoD 8320.2: Data Sharing in a Net-Centric
Department of Defense – December, 2004
• Puts in Policy DoD Data Strategy
• The Heads of DoD Components shall:
• Ensure implementation of Net-Centric data sharing,
including establishing appropriate plans, programs, policies,
processes, and procedures consistent with policies herein.
• Ensure that all current and future data assets are made
Mission Areas consistent with policies herein.
must form COIs • Support Mission Areas and Domains by taking an active
role in COIs
to manage data
CIO/G6 lead for implementing DoD 8320.2
Page 3
Summary of Data Strategy Roles and
Responsibilities
• Define Domains and Domain owners; review Domain governance
Mission • Mission Area architecture and capability planning
Area • Cross Mission Area and enterprise coordination
• Manage Domain Portfolios and information capabilities
• Ensure COI capabilities and Infrastructure are resourced
Domain • Domain architecture and capability planning; Identify Services
• Facilitate information sharing among Domains
• Develop semantic and logical agreements for data;
register COI data schemas and models
COI • Identify Authoritative Data Sources
• Promote data sharing across the Enterprise
Program Managers, • Tag Data with discovery metadata; make data available to
“Shared Space”
System Owners, • Create searchable catalogs of data assets
• Register metadata in appropriate registries, directories
Data Producers • Offer Services by planning and budgeting for services or
capabilities to be exposed to the enterprise
Reflects draft Army COI Policy and DODD 8320.2 Page 4
DoD Net-Centric Goals and COI
DoD Goals
External Metrics
External Metrics
Visible Data posted/Data listed in catalogs
Accessible Data available in shared space
Institutionalized Data management follows relevant guidance
Ontologies, taxonomies, content and format
Understandable metadata developed
Security data developed and posted/Authoritative
Trusted Data Sources identified
Metadata registered/Data management follows
Interoperable
mandated technical standards
Responsive All stakeholders are members of COI
Page 5
DoD Net-Centric Goals and their Meanings
DoD Goals Meaning
Visible Who has what data available?
Accessible Where is this data and in what format?
What and who governs the definition, lifecycle,
Institutionalized and use of this data?
Understandable What does this data mean?
Trusted Is this data trustworthy, accurate, and authoritative?
Interoperable Can my application use this data?
Responsive Is this data timely?
Page 6
DoD Net-Centric Goals and Approaches
Catalogs
Catalogs
Metadata
Registries
Visible Discovery Metadata Security Metadata
COI-specific Ontologies Semantic Metadata
Accessible
Shared Syntactic Metadata Content Metadata
Spaces Structural Metadata Pedigree Metadata
Institutionalized
Authoritative Data Sources
Understandable
Governance
Oversight Trusted Services
Processes/Practices
Interoperable Metadata Registration Search
Metrics/Incentives
Asset Inventory Data Access
Education/Training
Responsive Mediation User Feedback
Communities
of Interest
Page 7
OBJECTIVE
Define a C4ISR Data Ontology for the Integrated
Data Environment being developed for the
warfighter.
Page 8
What is an Ontology
• Metaphysics that studies the nature of existence
• An ontology is a description (like a formal
specification of a program) of the concepts and
relationships that can exist for an agent or a
community of agents
C4ISR Data Ontology
A specification mechanism for conceptualization
of C4ISR interoperability data
Page 9
C4ISR Data Ontology
Aug 04 Feb 05 Oct 05 Feb 06 C4ISR
C2IEDM Add VMF Add MTF Add TDL Data
v6.1 Ontology
Add COI/Domain Concepts
TECHNICAL APPROACH STATUS
The C4ISR Data Ontology is being Initial Ontology Complete
developed as an evolving baseline • Translated C2IEDM v6.1 into OWL,
describing data exchanges performed a W3C Ontology Language
by current message-based systems. • Adding VID data to Initial Ontology
• Aligning with DoD/Army Stakeholders
USMTF = U.S. Message Test Format COI = Community of Interest
VMF = Variable Message Format W3C = World-wide Web Consortium
TDL = Tactical Data Link VID = VMF Integrated Database
C2IEDM = C2 Information Exchange Data Model OWL = Web Ontology Language
Page 10
Semantic Web:
Dynamically Accessible Services
UDDI
(Discovery)
WSDL Ontology
(Description) Service
SOAP Registry
(Access)
XML API for
(Form)
Web Service
Application Access Web Service
SOAP Web Service
Receive Data
UDDI = Universal Description, Discovery & Integration
WSDL = Web Service Description Language
SOAP = Simple Object Access Protocol
Page 11
Ontologies Enable
The Semantic Web
• Interweave concepts & their representation
• Capture semantics describing processes
within domains
• W3C languages provide common syntax
for cross-domain information exchange
Page 12
ISSUE
Current Systems Are Not Web-Enabled
• Support tasks, not processes
– Local optimization (vertical integration)
– Lack enterprise perspective (horizontal integration)
• Point-to-point data exchanges using military
message formats
– Difficult to implement
– Expensive to maintain
• Current systems must co-exist with new
web-enabled systems
– Same data is needed to support processes
Page 13
C4ISR Data Ontology
Describes AS-IS Data Exchange
• Translates IERs into a form useful to Data Modelers
– Implemented in OWL, a W3C ontology language
• Supports re-use: No need to re-engineer for each DM
• Generates code: could be used as core for future Physical Data Models
– Uses C2IEDM v6.1 for core concepts
• C2 data used supporting multi-national operations
• System-specific concepts flagged as potential extensions to C2IEDM
• Supports IER refinement
– Early identification of gaps
• E.g., new data requirements introduced by system implementations
– Eliminate need for rarely used data concepts.
• Supports Net-Centric Data Strategy
– Reduces need for pair-wise system-specific interfaces
– Supports management of Net-Centric Checklists
IER = Information Exchange Requirements
Page 14
Ontologies Reduce # of Interfaces
to Implement and Manage
Ontology
4 DMs
means
# Interfaces I
For 100 DMs: IV
3+2+1=6
Equals 4950 Interfaces
II III
Interface
# DMs
s (99+98+…)
1
DMA DMD
2 3
4 5
DMB 6
DMC
Page 16
Ontology-Driven
Information Exchange
USER @
Ontology & DATABASE
SYSTEM A
Inference Engine
”
1
“I need X” sX
ed
ne
SERVER A
em
yst 2
“S
3 “For X:
System A needs
“X” 7 Y from System B and
Z from System C”
6 “Z” “Y” 5
4
“Send me Z
for System A” “Send me Y
for System A”
Current Systems Unchanged!
SYSTEM C SYSTEM B
Page 17
Data Modeling & Products
• Develop Data Products USER @
SYSTEM A
Ontology &
Inference
DATABASE
– IESS Engine X”
1
“I need X” s
ed
ne
SERVER A
em
yst 2
“S
–
“For X:
Data Models “X” 7
3
System A needs
Y from System B and
Z from System C”
– Ontology 6 “Z”
4
“Y” 5
– Other as defined “Send me Z
for System A” “Send me Y
for System A”
SYSTEM C Current Systems Unchanged! SYSTEM B
• Develop Web Applications
– Inference Engines
– Translation Services
Page 18
C4ISR Data Ontology
Aug 04 Feb 05 Oct 05 Feb 06 C4ISR
C2IEDM Add VMF Add MTF Add TDL Data
v6.1 Ontology
Add COI/Domain Concepts
Created Initial Ontology from Existing C2IEDM
– Converted to OWL, a W3C Ontology Language
• Version 1: Expand Ontology to Include VMF Data
– All messages identified for “minimum implementation”
– Additional VMF messages supporting SWB-2 threads
• Version 2: Expand Ontology to Include MTF Data
– Leverage Air Force USMTF ontology work
• Version 3: Expand Ontology to Include TDL Data
Page 19
C4ISR Data Ontology
Applies to Net-Centric Attributes
ASD/NII Net Centric Checklist questions are
designed to gather program information to assist
DoD leadership in better understanding our
move to net-centricity.
Questions are tagged as Foundational [F] or
Discovery [D].
– Foundational questions relate to a net-centric attribute
– Discovery questions relate to how programs implement a
feature.
The DoD C4ISR Data Ontology
Supports Foundational Issues
Page 20
C4ISR Data Ontology
• Translate IERs into a form useful to Data Modelers
– Supports Re-use: No need to re-engineer for each COI’s DM
– Generates code that can be used as core for Physical Data Model (SV-11)
• Flexible, Conceptual Representation
– Allows system-specific dialects
– Keeps system-specific concepts hidden from other systems
• Supports Net-Centric Data Strategy
– Configuration managed organizationally aligned with Army COIs.
– Configuration Management scales to DoD {and broader) enterprise scope.
• Reduces Complexity
– Reduces need for pair-wise system-specific (and COI-specific) interfaces
– Objective identification of potential extensions to C2IEDM (and other core DMs)
– Early identification of gaps
• E.g., new data requirements introduced by system implementations
– Supports IER refinement: Eliminate need for rarely used data concepts.
Page 21
Communities of Interest (COIs)
• COI is a set of stakeholders
– Who must exchange information
in pursuit of their shared
• Goals
• Interests
• Missions
• Business processes
– Who must have shared
vocabulary for the information
they exchange
COI define shared vocabulary, information to be shared, how it
should be shared.
Page 22
COI Formation – Institutional COI
Functional Relationships
COI
• Institutional COI
– Activity/Entity Based
– Hierarchical
COI
– Reflects all Relationships Entity
Relationships
– Based on Integrated
Architectures
– Functional Area (Data
Developer)
– Examples: C2, Sensors,
Effectors, Logistics, Medical,
Acquisition, etc
Army Enterprise must form Institutional COIs
Page 23
COI Formation – Expedient COI
Functional Relationships
Overlap
• Expedient COI
– Thread Based
– Capabilities Based
– Entity
Cross-Domains/Functional Relationships Overlap
– Reflects Partial Relationships
– Based on Integrated
Architectures
Mission
– Data Consumer (use Thread
Mission
Functional Area standard Thread
vocabulary)
– Examples: TST, JCAS, Global
Strike, etc.
Systems Engineering and Governance of COI Boundaries Minimizes Overlap and
Coupling Issues
Page 24
Currently Registered COIs*
• Computer Network Defense (CND)
• Distribution COI
• Force Projection
• Global Force Management - Community of Interest (GFM-COI)
• Information Operations
• Joint Electronic Warfare Data Standardization WG
• Joint Targeting Intelligence
• MASINT Community of Interest
• METOC (METEOROLOGY-OCEANOGRAPHY)
• Modeling and Simulation Community of Interest
• Sample COI Instructions
• Space COI
* From DoD Community of Interest Directory: https//extranet.itis.osd.mil/coi
Page 25
•
Summary
DoD Net-Centric Data Strategy is now Policy (DoD 8320.2 & AR 25-1)
• All must identify, prioritize, select information (data assets) to be shared with the
enterprise, and designate authoritative data sources
• Mission Areas and Domain leads must organize for battle by…
– Forming and resourcing expedient COIs (lead/support joint & Army)
– Forming Army Institutional COIs (focus area)
• CIO-G6 is organized to support Data Strategy implementation of Mission Area &
Domain leads with:
– Services and Methodology (COI Administration, Data System Engineering, Data
Modeling and products, Configuration Control, & Data Test Support)
– Best Practices/Lessons Learned (COI Program Management Plan)
– Policy & Guidance (Draft COI Policy, Draft COI Guidance Document, initial draft
of Data Engineering Guidance Document, & DA PAM 25 1-1)
• CIO-G6 teamed with Navy & Air Force to ensure common approach to implement
Net-Centricity through Net-Centric Enterprise Support for Interoperability (NESI)
• System Engineering and Integrated Architecture approach is required to execute
Data Strategy. (CJCSI 3170 - JCIDS process)
Data Strategy is critical but not sufficient to achieve Net-Centricity
Page 26
Building Toward Shared Data Interoperability
GAP Analysis
Interoperability
Assessment
Register
Data
Products
AV-2, OV-6a, OV-
7, SV-6, SV-11,
ADS, EIDs, XML
Create Common
Schema
Vocabulary
Identify Critical Business Transactions
Identify Information Exchanges and Rules
Identify Data Elements Meaning/Structure
Identify Authoritative Data Sources
Form COIs
Define purpose, participants, expectations. Establish the relationships
between COIs, Mission Area Leads, sub-domains, program managers,
system owners and other data producers. Develop governance and
funding requirements.
Page 27
Related docs
