Mine Warfare (MIW) Community of Interest (COI) Efforts Towards the Development of Future Data

Standards to Enable a Net-Centric Capability

Megan A. Cramer Mine Warfare Program Office (PMS495)

Program Executive Office Littoral and Mine Warfare (PEO LMW) Washington, DC - U.S.

Abstract— The U.S. Navy established the Mine Warfare (MIW) Community of Interest (COI) in 2007 to develop data strategies in support of a future information-based architecture for naval MIW. The MIW COI is actively pursuing standard data exchange as a mechanism to facilitate the creation of a future service oriented architecture (SOA) and improved interoperability within the MIW system-of-systems. Initiatives include publishing data standards to facilitate implementation of open architecture (OA) and net-centric approaches as well as the development of a Data Standards Guidebook to facilitate the generation of future standards. During the past year, the COI published the data standard for MIW Contacts and prepared a foundational structure and schema for a MIW sensor data format using the hierarchical data format (HDF) specification as a common approach to managing unstructured sensor data in support of post mission analysis (PMA). Looking forward, the COI is implementing a data model roadmap to manage the data standards generation process for MIW-relevant tactical, meteorological and environment data, and sensor data. The development of data standards directly enables technology insertion by providing inputs to algorithms and modules. The use of a standard format also reduces integration costs and risk through early communication of available data and associated metadata. The access to common data standards allows new technologies to be more easily analyzed and incorporated during the verification and validation (V&V) process. An agile approach to technology insertion, enabled by common data standards, will ultimately result in an improved future MIW capability.

Keywords-net-centric; mine warfare (MIW); data standards; service oriented architecture (SOA); Open Architecture (OA)

I. INTRODUCTION With the introduction of improved sensors and unmanned

vehicles, naval mine warfare (MIW) forces will use large amounts of information that will need to be produced, exchanged, and processed within a bandwidth-constrained architecture. To address this challenge, the MIW Community of Interest (COI) was formed in 2007 to develop data strategies and standards to effectively and efficiently manage this information and develop a future net-centric architecture for the mission area. This paper will explore the Mine Warfare community’s efforts to develop and publish data standards as

an essential component of a future service-oriented architecture, which is planned to improve interoperability and reduce technology integration costs through the implementation of an open business model enabling third party development.

II. BUILDING A FUTURE NET-CENTRIC ARCHITECTURE The MIW COI is actively pursuing standard data exchange

as a mechanism to facilitate the creation of a future net-centric architecture, including multiple applications and databases, which will improve interoperability and reduce integration costs within the MIW system-of-systems. The implementation of net-centric software approaches offers a virtual platform for technology integration, leveraging Commercial Off the Shelf (COTS) software components, Government Off the Shelf (GOTS) reuse, and third party software development. The data throughput among these applications and the associated databases becomes the forcing function in implementation to ensure interoperability between multiple SOA-based applications and databases, which are oftentimes developed and supported by multiple organizations.

A. Programmatic Initiatives The major programmatic initiatives involved with building

a net-centric environment is the migration of both the US Navy Command and Control (C2) and Post Mission Analysis (PMA) software to a service oriented architecture (SOA). The single integrated tactical decision aid (TDA) for MIW C2 in the U.S. Navy is the Mine Warfare and Environment Decision Aids Library (MEDAL), which is migrating to a SOA version with a complete software rewrite to Enterprise Architecture (EA). A future new-start program for integrated, multi-sensor PMA will be Net-centric Sensor Analysis for MIW (NSAM). A prototype of NSAM is currently in development to demonstrate Open Architecture (OA). For both efforts, the requirement to leverage SOA concepts within the constraint of operating within a disconnected, intermittent, and low-bandwidth (DIL) environment has been fully considered. This new software architecture will integrate information from multiple user processes and facilitate collaboration within the common operational and tactical pictures. Essential to successful

implementation of this architecture and the ability to exchange information is the need for common data standards and semantics for exchanging information.

B. MIW Data Model Working Group The MIW Data Model Working Group (DMWG) was

established by the MIW COI to develop and publish data standards for the MIW community of software developers, data providers, interface managers, third party developers, and information users. The DMWG is an open forum of both government and industry participation with the objective to improve interoperability and integration costs by minimizing point-to-point interfaces through the development of common standards for MIW information exchange.

Initiatives by the MIW DMWG include publishing data standards to facilitate implementation of OA and net-centric approaches as well as the development of a Data Standards Guidebook [1] to facilitate the generation of future standards. The Data Standards Guidebook includes a template model, which as described in the Guidebook “presents a consistent structure to developers new to MIW COI data model efforts that allows them to rapidly integrate their data elements into an agreed upon structure without the need for significant rework of previously addressed design problems.”

Using the template model approach, the MIW DMWG published the data standard for MIW Contacts [2] and in conjunction with the Naval Oceanographic Office (NAVO) standardized environmental data important to the MIW mission such as bathymetry. Additionally, the community has prepared a foundational structure and schema for a MCM sensor data format using the hierarchical data format (HDF) specification [3] as a common approach to managing unstructured sensor data in support of PMA. Looking forward, the community also manages a data standards generation process for the future development of MIW-relevant tactical, metrological and environment (METOC) data, and sensor data.

C. MIW Data Standards Guidebook The MIW Data Standards Guidebook establishes the

requirements for the development of MIW Data Standards as agreed to by the MIW COI. These requirements include consideration enterprise data formats and act as a common denominator for MIW information exchange with regard to enterprise data constructs such as International Organization for Standardization (ISO) 19115 Geographic Information, Intelligence Community (IC) Information Security Marking (ISM), Geography Markup Language (GML), and Universal Core (UCore).

One purpose of the MIW Data Standards Guidebook is to provide requirements and guidelines for Logical Data Model (LDM) development adopted by the MIW DMWG to support improved interoperability and OA implementation within the MIW COI. An LDM is a logical, platform independent, description of data. The purpose of an LDM is to develop XML schema that provide a standard format for data exchange between distinct information systems. The method, protocol and underlying mechanism of data exchange is outside of the scope of the document.

The MIW LDM provides the framework for producing several useful information exchange packages for the MIW COI. Each package is called a Logical Schema (LS). A Logical Schema is a data model of a specific problem domain expressed in terms of a particular technology. Whereas a LDM is platform independent, an LS is platform dependent. The benefit of modeling the LS in UML is because it is becoming more common for applications to generate significant amounts of code automatically from a UML management tool. The Logical Schemas will also allow interested parties to generate XML Schema Definitions (XSD) documents to govern XML based information exchanges between distinct information systems. Figure 1 describes the data modeling stages described within the MIW Data Standards Guidebook.

Figure 1. Data modeling stages described within the MIW Data Standards

Guidebook.

Another purpose of the Guidebook is to describe the method by which a model developer can convert an LDM implemented in UML to a physical, XML representation of the data contained in the model. This physical representation in XML becomes the actual data standards published and implemented by the MIW COI as a mechanism to facilitate interoperability between SOA applications and databases.

D. A Template Model Approach The MIW Data Standards Guidebook describes a template

model approach to data standards development, which provides a consistent structure to developers new to MIW COI data model efforts that allows them to rapidly integrate their data elements into an agreed upon structure without the need for significant rework of previously addressed design problems. The model guides data owners, producers, and developers on how to present any necessary metadata and data in an interoperable manner and provides data consumers with an overview of the standards and structures in use throughout the community.

A template model approach is employed to standardize the format of certain common model elements, such as geospatial locations, security tagging and metadata. When geospatial locations, security tagging and metadata are present in a model, they must be modeled as described in the guidebook. Model elements for which no requirements are provided in the document may be modeled at the implementer’s discretion. The benefits of this approach include:

• Interoperability – Standard data exchange formats enable significant interoperability between software, information, and processes.

• Integration – Standard data exchange formats facilitate integration of multiple applications and information from disparate systems.

• Reuse – More effective reuse / combination of existing applications and systems.

The template LDM for the MIW COI was developed by selecting information specifications with enough depth when implemented to support multiple metadata, security, and geospatial data specifications. By utilizing targeted specifications and abstracting them for the purpose of gaining a technology independent LDM, the MIW COI has been able to ensure the single LDM design will support multiple Logical Schemas for information exchange.

E. Data Model Roadmap Beyond the standards already published, the MIW DMWG

is managing a data standards generation process for the future development of MIW-relevant tactical, metrological and environment (METOC) data, and sensor data. This process for data model development includes a kick-off meeting with Subject Matter Experts (SMEs) with knowledge relevant to the data standard, development of an overall model structure, then detail definition of the model, the creation of a data model schema and specification, testing of the schema in a test-bed, and finally, delivery of the data model for MIW DMWG approval.

This process is complete for MIW Contacts, primary METOC data, and a Mine Countermeasures (MCM) Sensor HDF Specification (MSHDF) Version 1.0. The data model entities currently in development include MCM Tasks, MIW Areas, Mine Order of Battle Threats, MCM Plans, and Asset/Effort Posits (Tracks). Version 2.0 of the MSHDF standard for PMA is also currently in development. All developed data standards are expected to be implemented by Fiscal Year (FY) 2014.

III. FACILITATING TECHNOLOGY INSERTION The development of data standards directly enables

technology insertion by providing inputs to algorithms and modules. The use of a standard format also reduces integration costs and risk through early communication of available data and associated metadata. Access to common data standards allows new technologies to be more easily analyzed and incorporated. In this way, the development of common data standards facilitates technology insertion.

A. Technology Insertion Process Common data standards play an important, central role

within the technology maturity, insertion, and assessment process. This process is illustrated in Figure 2. Beginning on the left side of the illustration, a technology is developed within the Science & Technology (S&T) community. The technology then goes through an important maturation stage where the technology progresses from Technology Readiness Level (TRL) 6 (system operating in relevant environment) to TRL 7

(system operating in an operational environment) according to the common established TRL definitions [4]. Note that this maturity of technologies from TRL 6 to 7 is a very important stage and is often facilitated by a Technology Transition Agreement (TTA) between the acquisition, requirements, and S&T communities as is a best practice according to the Technology Readiness Assessment (TRA) Deskbook [4]. The technology is then verified and validated (V&V) against exit criteria specified in the TTA. If the technology passes V&V it is integrated into a program of record; if it fails V&V it will not be integrated and will be handed back to the S&T community for further evaluation. In general, the Navy strives to keep the technology transition success rate high enough to ensure a continuous flow of both needed and breakthrough technologies to the war-fighter but not so high to drive away all risk or dilute the transitioned capability. This process is streamlined if the technology uses understood system models and common data. The technology is then cost estimated for integration and assuming integration is funded the technology is incorporated into the program of record as either a pre-planned product improvement (P3I) system upgrade or new capability insertion.

Figure 2. MIW Technology Insertion Process articulates the steps by which a technology matures from a concept into a fielded capability that is assessed

and used for input to future system improvements. The central role of common data models is highlighted.

Following system fielding, a continuous feedback loop exists including assessment and sustainment of system performance as well as other relevant factors such as user proficiency. Stakeholders such as the Fleet, the engineering community, and the S&T community, monitor assessment data and consider new technologies and improvements to the system. Additionally, an In-service System Engineering Agent (ISEA) and/or Software Support Activity (SSA) team collects and prioritizes proposed plans to update and improve the fielded system. These plans may include system function or software bug fixes, reliability improvements, hardware technology refreshes, obsolescence mitigation activities and minor capability improvements. These proposed changes based on preserving the life of the fielded system are outside the realm of the S&T community and can be described as preplanned system upgrades, or P3I. This process is iterative, and proposed changes for the system from the scientific community, engineering community, and Fleet vie for

integration and in effect compete for program funding and resources to support system capability improvements.

B. Observations There are several additional observations that can be made

by considering this technology insertion process. At all stages in the process, the use of metrics can be utilized to measure technology performance and ease of integration. The throughput within this technology insertion process is also driven by funding, and there is a natural down-selection of technologies moving through the process. Specific to technology integration, the cost or effort of integration can effectively be a metric for how open a particular system is. If there is a significant cost to integration, then the system can be considered less open than a system that has a less significant cost of integration. This is a potential metric of OA. The use of common data standards is a convenient way to communicate a component of the subsystem interface within a system, which ultimately reduces the cost of integration. Given these benefits to enabling the technology insertion process, the MIW COI is working to establish common data services and provide these to the S&T community, particularly third party developers, in order to facilitate the technology transition process.

IV. CONCLUSION The MIW COI established the MIW DMWG to publish

data standards to facilitate implementation of OA and net-centric approaches. To streamline the process of data standards development and implementation, the team has published a Data Standards Guidebook, which describes a template model

approach for data standards development. During the past year, the COI published the data standard for MIW Contacts and prepared a foundational structure and schema for a MIW sensor data format using the HDF specification as a common approach to managing unstructured sensor data in support of PMA. Looking forward, the COI is implementing a data model roadmap to manage the data standards generation process for MIW-relevant tactical, METOC, and sensor data. Ultimately, access to common data standards will result in an improved future MIW capability by streamlining the technology insertion process.

ACKNOWLEDGMENT The author would like to acknowledge and thank the

members of the MIW Data Model Working Group for their tremendous efforts in developing and publishing the MIW Data Standards Guidebook and initial net-centric standards for MIW.

REFERENCES [1] U.S. Department of Defense. Department of Navy. Program Executive

Office Littoral and Mine Warfare. 2010. Data Standards Guidebook v.0.9.1. Washington DC.

[2] U.S. Department of Defense. Department of Navy. Program Executive Office Littoral and Mine Warfare. 2010. MIW Contacts Data Standards. Washington DC.

[3] The Hierarchical Data Format (HDF) Group. www.hdfgroup.org [4] General Office of Accounting and Department (GAO), Technology

Readiness Assessment (TRA) Deskbook; September 2009. www.dod.mil/ddre/doc/DoD_TRA_July_2009_Read_Version.pdf