1. ASW COI Data Strategy Presented by Colleen Cannon (PEO IWS5SE) to ASW Executive Steering Group 03 August, 2007

2. Why develop an ASW Data Strategy? Because it is DoD and Navy policy… –DoD Memo Net-Centric Data Strategy, 9 May 2003 –DoD Directive 8320.2 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 exact data formats and vocabularies to create accurate knowledge without human intervention We have numerous ASW systems that can’t share similar data Because we have the opportunity… To define and implement as design of choice in new developments As we bring on new sensors we can simplify the integration Due to a data format error, the Mars Climate Orbiter missed the planet!

3. ASW COI Flag Oversight ASW CFB Chair-Lead ASW Executive Steering Group (ESG) IWS5 Chair ASW CFT Co-Chair ASW Systems Engineering Team (ASSET) IWS5SE Chair NMAWC Advisory (Requirements) ASW COI Organization System of Systems System Engineering LCS SOS pilot ASW SoS Level Risk Management ASW OA Pilot & Software Governance ASW Mission Capability Architectures (MCA) PSDB DMWG Data Sharing Demos C2 Data Fusion

4. Next meeting 23 August @ BAE Systems 80 M St. Who will develop the ASW Data Strategy? The ASW Data Management Working Group (DMWG) has been established to do this –Consistent with DoD terminology and intent –Initial meeting held 23-24 July 2007 –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) Break-out groups met for Command and Control, Sensors and Sensor Performance Prediction –Way Ahead plan developed for each group –Data sharing pilot efforts proposed by each group

5. What we are doing to realize the first increment of the ASW Data Strategy

6. DMWG Broad “To Do” List Align with the Joint C2 Capability Portfolio Management process - JFCOM Identify requirements for new data capabilities Participate in the DoD COI Forum –Best Practices and Lessons Learned from other COIs Meet FORCEnet Data Strategy Compliance Action List (CAL 5) requirements

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

8. DMWG Next Steps Establish common ASW vocabulary and data model through model driven architecture 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)

9. Back-ups

11. ASW COI Engineering Process for Sensor Data Model Harmonization Phase II, secondary effortPhase III, ongoing effortsPhase I, Initial effort Working assumptions Compare vocabularies using data-model operational views Generate XML schemas and transition mappings to match Maintain working systems throughout Iterative process with multiple repetitions, refinements, milestones: Sonobuoys Extend metadata xml work to non-acoustic sensor types Extend to other COIs – ISR, C2, MIP, MIW, MDA, etc. Evaluate P-8A net demo Data models XML schemas Engineering process: compare data-model baselines, reconcile differences if possible, verify merger with working systems, repeat Pilot ASW sensorExtend Pilot to other ASW SensorsComplete All Sensor Data Data models XML schemas Data models XML schemas Must comply with ASW CONOPS DoN CIO XML, Naming and Design Rules (NDR), DoD Metadata Repository rules, Perhaps additional requirements Reconciling proven assets might provide A “quick win” 2007 pilot project, and also Establish a successful ongoing process Determine sensor data consumers and producers within the COI, and determine data requirements Reconcile metadata in XML Structural Semantic Discovery – ONI auxiliary XML, others Raw sensor data: assess Sensor ML Build class diagrams from existing schemas Extend sonobuoy metadata xml work to all acoustic sensors Identify non acoustic and environmental sensors Determine data availability gaps e.g. dynamic ONI to P-8 linkage, storage, timeliness,... Begin P-8A net demo preparations

12. Stage 3 Stage 2 Stage 1 SPP/METOC Data Process Current Information Exchange Requirements Consumers Producers Existing & ‘To Be’ Exchange Mechanisms Anticipated Data Requirements Pilot Test Approach Accumulation and Evaluation of Exchange Mechanisms Extension/development to meet 95% current and 20% future needs Test and Assessment Release

13. ASW Vocabulary Development & Validation Process Identify Stakeholders Decide Vocabulary Format Research Related Vocabulary Efforts Update Products Validate Products with Stakeholders Update Products Obtain COI Approval Update Official Vocabulary Baseline Register Vocabulary Develop Draft Vocabulary Products Conduct Workshop yes no yes Modifications? Products complete? ASW COI ESG Obtain COI Forum Chair’s Signature COI Forum Vocabulary Validation ASW C2 Vocabulary Development Pilot

14. ADDITIONAL BUILD CYCLE TIMELINES (P8, A(V)15, Surveillance, Etc.) APB BUILD CYCLE TIMELINE USW DSS BUILD CYCLE TIME LINE USW DSS TAML CNDE MDASIPS TRACKS STDA METOC ACOUSTIC (ORG SIM sensor Core Set of registered software, artifacts/assets, interfaces, and data definitions. Revised set of registered software, artifacts/assets, interfaces, and data definitions. Revised set of registered software, artifacts/assets, interfaces, and data definitions. ASSET DMWG P. Blackledge ESG Dr. Etter ASWIP “Clambake” USW DSS B2 Data Baseline N6/NGF @ NUWC BASELINE PRODUCTS... TW-08

15. Data Sharing in a Net-Centric DoD DoD Directive 8320.2 “Data is an essential enabler of net-centric warfare” –Make data visible, accessible & understandable Develop “discovery metadata” – what & where is the data Make data available in shared spaces – eg. networks Negotiate and publish community “semantic metadata” (vocabularies) and “structural metadata” (formats) “Semantic and structural agreements for data sharing shall be promoted through communities” –Establish and evolve a Community of Interest Among those who need to share data –Work with Enterprise Services and related COIs

16. ASW Data Strategy Ongoing Efforts Goal: A common ASW data strategy that supports Joint and Coalition architectures and DoD Net-centric compliance policy –Brief the common core baseline product at the 1 August ASW ESG –Brief at the Summer ASWIP and the Fall NDIA Undersea Warfare Conference Significant attention by N6 and N6F on the ASW COI and Data Sharing (Pilot demo proposal – Evaluate Data Models supporting multi-mission use of common data) OA-Fn Demonstration (JTM Data Model evaluation) –Identify possible FY07 funding Maritime Domain Awareness (MDA) COI Pilot Program –Use results from their Data Management WG Initial focus on USW-DSS functionality and CANES/CNDE common core –Contacts, track data, TAML and MDA XML schema –Environmental data, METOC COI –Reusable core architecture Sensor data –WSDL tool output and ONI XML schema –Platform Sensor Database Signature Data –Platform Sensor Database

17. Product Questions (Capture in Next Steps ) Whatever data elements we choose to be ASW core –Are they all in a common core (and which ones) –Are they registered What is the near term – long term progression – –what is available now, what is close but not registered yet, what is in development that we can influence.

18. DMWG An iterative process that includes a: –Quick win core baseline –Method to identify more interfaces, feed in more fleet requirements, plug in more pieces of architecture –Description of top level node to node what needs to be exchanged and who needs what and when –Core set of definitions –Common Vocabulary