1. Anti-Submarine Warfare Community Of Interest (ASW COI)
Presented by
Colleen Cannon (PEO IWS5SE)
to the DoD COI Forum
16 October 2007

2. OUTLINE Overview of ASW COI Organizational Structure ASW Data Strategy
Relationship to DoD and Coalition COIs
Areas of Interest in FY08
ASW Data Strategy
Why, Who, What, Where (data environment)
ASW Command and Control (C2) Pilot Implementation
Focus Areas
Alignment Through Mediation
Future Data Management Working Group Efforts Next Steps Broad “To Do” List
Questions?

3. Overview of ASW COI Organizational Structure
ASW COI Flag Oversight
ASW CFB Chair-Lead
NMAWC Advisory
(Requirements)
ASW Executive Steering
Group (ESG)
IWS5 Chair
ASW Systems Engineering
Team (ASSET)
IWS5SE Chair
System of Systems (SoS) Engineering
ASW Community of Interest established
ASW Systems Engineering Team (ASSET) established under ASW ESG
ASW Data Management Working Group
Identifying players
Lead for ASW Data Strategy activities
Implement DoD and Navy policies
Make data visible, accessible and understandable
Bring architecture and data strategy into alignment
ASW OA Pilot &
Software Governance
DMWG
Data Sharing
Demos
ASW
Mission Capability
Architectures (MCA)
ASW SoS Level
Risk Management
PSDB
C2 Data
Fusion
LCS SoS pilot

4. Overview of ASW COI Relationship to DoD and Coalition COIs
Joint Command
and Control
(JC2 CPM)
Consolidated
Net-Centric Data
Environment (CNDE)
Infrastructure
DoD Universal
Core &
NCES
Maritime Domain
Awareness (MDA)
COI (AIS)
Meteorology
Oceanography
(METOC) COI
Anti-Submarine
Warfare COI
Multilateral
Interoperability
Programme (MIP) COI
(JC3IEDM)
Coalition
Mine Warfare COI
Alignment required with related COIs and Enterprise Services

5. Overview of ASW COI Areas of Interest in FY08
Navy Enterprise Architecture and Data Strategy
Open Architecture – Data Strategy – Enterprise Architecture – Service Oriented Architecture
Metrics
System of Systems Engineering
Mission
Capability Architecture
Data Strategy
Risk
Management
Open Architecture
Common Data Vocabulary and
Pilot Demonstration Working Groups
Command and Control
Sensors
Sensor Performance Prediction
Implementation Driven
Software Reuse
Software Governance
LCS ASW Pilot CEP
DNS Follow-On

6. Why Develop An ASW Data Strategy?
Because it is DoD and Navy policy…
DoD Memo Net-Centric Data Strategy, 9 May 2003
DoDD Data Sharing in a Net-Centric Department of Defense, 2 Dec 2004
Navy Enterprise Architecture and Data Strategy Policy, 6 Apr 2007
Because it is at the heart of ASW interoperability…
Need it to effectively share data among network users
Net-centric systems require precise, and known data formats and vocabularies to accurately evaluate and manipulate information without human intervention
We have numerous ASW systems that can’t share similar data
Because we have the opportunity…
. . . to define and implement it as the design of choice in new developments
. . . to simplify integration as we bring on new sensors
Making ASW data visible, accessible, understandable and trusted,
managed by ASW COI

7. Who Will Develop The ASW Data Strategy?
The ASW Data Management Working Group (DMWG) has been established under ASSET to do this
Consistent with DoD terminology and intent
Initial meeting held July – second meeting held 23 August
Over 30 participants from inside and outside the ASW community (POC list is 70+)
Core
ASW PEOs & Labs, NMAWC, CFT, USW-DSS, usw-xml WG, ONI, Industry
Identified related COIs and stakeholders
Mine Warfare, METOC and Maritime Domain Awareness (MDA) COIs, Consolidated Navy Data Enterprise (CNDE), NETWARCOM, Joint C2 Capability Portfolio Manager, Multilateral Interoperability Programme (MIP)
Pilot demonstration groups established for Command and Control, Sensors and Sensor Performance Prediction
Way Ahead plan developed for each group
Pilot demonstration efforts proposed by each group
Next meeting BAE Systems 80 M St.

8. Data Management Working Group What we are doing to realize the ASW Data StrategyC2
Other ASW
Interfaces
Exposure
Sensors

9. Enterprise Data Management
Data Strategy
Consolidated Net-Centric Data Environment (CNDE)
Enterprise Data Management
Universal
Core
Related
Elements
Associated
Logistics
Legal
Sensors
Business
Medical
Imagery
Weather
USW
MDA
Universal Core - New data models can be extended from the core model with minimal effort and impact
Data models are dynamic…they can be added and removed as needed
Domain data model are “decoupled components” and do not impact each other
Communities retain control of their own data and it’s access
We plan to utilize existing data model efforts, like JC3IEDM/C2IEDM, but extend them to provide for the needs of distributed interoperable track management solutions. These models do not currently support all the needed elements for doing track management between systems. They support passing info only message about dots on a map, there are additional attributes required for supporting the vision of tactical to strategic track management. These elements will be added, documented, and then fed back to the MIP for formal inclusion in future MIP releases.
The Three Plus One Strategy involves the ability for the United States to maintain major theatre combat operations in One Theatre (i.e. Korean Peninsula, Arabian Gulf) while still being able to simultaneously sustain three other small scale contingencies or stability operations. Examples: Global War on Terror
Non-Combat Operations/Stability Ops (I.e. Tsunami Relief, Hurricane Katrina)
Low intensity conflicts (I.e. Panama/Grenada)
Nation building (Afghanistan)
UN Peacekeeping Operations
Data Sets must be beyond “Cursor On Target” functionality.
The Core Elements will include the set of attributes with agreed upon semantics in support of track management. E.g., OATM + Classification, Release-ability, etc
Associated Data Elements will include specific attributes defined and managed by a subgroup to accommodate track management in a COI (For example, acoustic data elements) and available for COI capability processing, e.g. ELINT correlation
Related Data Elements provide cross-domain augmentation data. One use could be fusing EO imagery

10. ASW COI C2 Pilot Implementation (Proposed)
ASW COI Proposed C2 Pilot – Focus Areas
Related
Universal Core
Common Core Implementations (JTM Based)
Data Requirements Based On USW DSS Use Cases
ASW COI Extensions (JTM and JC3 Based)
SOA Implementation
Security/Registration/Discovery
Data Archive/Replication/Synchronization
Associated
USW
Universal
Core
Elements
Elements
Goal: Define, implement and test Universal/Common Core and ASW COI Increment; Mediate effort with USW DSS Program of Record

11. C2 Pilot -Alignment Through Mediation
Mission Plan Data
Mission Execution Metrics
Where We Are
Composite Subsurface Track
Security
Registration /
Discovery
CANES
Universal Core ,
Orchestration
NODES
Common Core ,
ASW COI
USW DSS
Capabilities
Data Mediation
External USW
DSS NODES
USW DSS
Common Tactical Picture Q 89
Based
OTH - G
Mission Plan
(OP Areas, WSM,
Ovly, etc.)
Sensor Systems
Mission Execution Metrics
Composite Subsurface Track
GIS Features and Overlay
Surface Radar
METOC
Local AIS
Link - 11
National Sensors (
JMIE /
ELINT /
SIGINT # 1 )

12. C2 Pilot - Alignment Through Mediation
Where We Are Going
Local AIS
National Sensors (
JMIE /
ELINT /
SIGINT # 1 )
Surface Radar
ASW COI
Link - 11
Replication/Synchronization
METOC
Security
Registration /
Discovery
CANES
NODES
Universal Core
Orchestration ,
Common Core ,
ASW COI
Q89 Sensor
Mission Plan
Mission Execution Metrics
Composite Subsurface Track
USW DSS
GIS Features and Overlay
Capabilities
Data Mediation
DSS
NODES
USW DSS
Data Workspace
Capability
Collaboration Q 89
Based
GIS
Features
Sensor Systems
Mission
Plans
Mission
Execution

13. Data Management Working Group Next Steps
Establish common ASW vocabulary and data format, using Mission Capability Architecture to analyze and develop the data and metadata models
ASW C2
Reconcile existing ASW C2 data formats
Repeat process with other C2 communities
ASW Sensors
Identify sonobuoy data producers, users, formats and associated metadata
Reconcile format differences
ASW Sensor Performance Prediction (SPP)
Re-establish the Platform Sensor Database (PSDB)
Now that we've got the right people together in the DMWG we formed a process to get ASW data into common terms and format.
The way ahead for the C2 group is to take the C2 data formats that already exist in the ASW community and merge them, reconciling any differences that are found. They are starting this process with the C2 schemas for USW-DSS and the Tactical Assessment Markup Language. From there they will repeat the merging process with other existing C2 formats used by Joint and Coalition forces as well as other DoD C4I COIs.
The task of establishing common terms and format for all ASW sensor data becomes quite large due to the variety of different types of sensors used to conduct ASW operations. The sensor group has decided to break up the task by focusing first on creating a common format for sonobuoy data. They will identify the terms and format used by each current producer and consumer of sonobuoy data and merge them, similar to the C2 group. From there the group will extend their format to include all acoustic sensors, and then non-acoustic and environmental sensors as well.
The SPP group wants to first re-establish the platform sensor database. This requires updating the values in the database in its current format as a near term fix, which would be followed by an overall improvement to the format of the database. After updating the PSDB the group would then look into establishing a common exchange mechanism for transmitting the database between systems.

14. Data Management Working Group Broad “To Do” List
Align with the Joint C2 Capability Portfolio Management process – JFCOM
Identify requirements for new data capabilities
Execute pilots for Sensor Data, Sensor Performance Prediction, and C2
Participate in the DoD COI Forum
Best Practices and Lessons Learned from other COIs

15. Questions? Colleen Cannon IWS-5SE colleen.cannon@navy.mil 202-781-4462