1 / 18

ASW COI Data Strategy

ASW COI Data Strategy. Presented by Colleen Cannon (PEO IWS5SE) to ASW Executive Steering Group 03 August, 2007. Why develop an ASW Data Strategy?. Because it is DoD and Navy policy… DoD Memo Net-Centric Data Strategy , 9 May 2003

farrah-pennington
Download Presentation

ASW COI Data Strategy

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ASW COIData 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.2Data 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 Organization ASW COI Flag Oversight ASW CFB Chair-Lead NMAWC Advisory (Requirements) ASW Executive Steering Group (ESG) IWS5 Chair ASW CFT Co-Chair ASW Systems Engineering Team (ASSET) IWS5SE Chair System of Systems System Engineering 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. 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 Next meeting 23 August @ BAE Systems 80 M St.

  5. What we are doing to realize the first increment of the ASW Data Strategy C2 Other ASW Interfaces Exposure Sensors

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

  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

  10. ASW COI Engineering Process for Sensor Data Model Harmonization Engineering process: compare data-model baselines, reconcile differences if possible, verify merger with working systems, repeat Phase I, Initial effort Phase II, secondary effort Phase III, ongoing efforts Pilot ASW sensor Extend Pilot to other ASW Sensors Complete All Sensor Data 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 • 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 • 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 Data models XML schemas 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 • 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:

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

  12. IdentifyStakeholders ConductWorkshop UpdateProducts Develop Draft Vocabulary Products Decide VocabularyFormat Research RelatedVocabulary Efforts ValidateProducts with Stakeholders no Vocabulary Validation UpdateProducts yes Obtain COI Forum Chair’s Signature Update OfficialVocabulary Baseline RegisterVocabulary Obtain COIApproval yes Modifications? Products complete? no ASW COI ESG COI Forum ASW Vocabulary Development & Validation Process ASW C2 Vocabulary Development Pilot

  13. ASSET DMWG P. Blackledge Dr. Etter ESG N6/NGF @ NUWC ASWIP “Clambake” Development Community Socialization 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. . . . TW-08 Demos USW DSS TAML CNDE MDA SIPS TRACKS STDA METOC ACOUSTIC (ORG SIM sensor BASELINE PRODUCTS USW DSS B2 Data Baseline USW DSS BUILD CYCLE TIME LINE APB BUILD CYCLE TIMELINE ADDITIONAL BUILD CYCLE TIMELINES (P8, A(V)15, Surveillance, Etc.)

  14. Data Sharing in a Net-CentricDoDDoD 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

  15. ASW Data StrategyOngoing 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

  16. 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.

  17. 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

More Related