TECHNOLOGY AREA(S): Information Systems

ACQUISITION PROGRAM: PEO IWS 1.0, AEGIS Combat System Program Office

The technology within this topic is restricted under the International Traffic in Arms Regulation (ITAR), 22 CFR Parts 120-130, which controls the export and import of defense-related material and services, including export of sensitive technical data, or the Export Administration Regulation (EAR), 15 CFR Parts 730-774, which controls dual use items. Offerors must disclose any proposed use of foreign nationals (FNs), their country(ies) of origin, the type of visa or work permit possessed, and the statement of work (SOW) tasks intended for accomplishment by the FN(s) in accordance with section 3.5 of the Announcement. Offerors are advised foreign nationals proposed to perform on this topic may be restricted due to the technical data under US Export Control Laws.

OBJECTIVE: Develop a real-time extensible and evolvable Distributed Common Operational Picture (DCOP) battlespace data model and associated descriptive battlespace data model markup language to improve command and control.

DESCRIPTION: The current AEGIS combat system implementation does not include a comprehensive distributed (i.e., multi-platform) capability for capturing the complete battlespace operational, environmental, and tactical picture in a coherent integrated manner. Currently available commercial systems and software that might be considered for adaptation to Navy needs (e.g., the FAA Air Traffic Control System hardware and software) are dated in their design, and lack the flexibility and track capacity required to adequately address Navy tactical needs. Specifically, currently available commercial technology is limited in that it lacks the capability to track, identify, and manage complex air, surface and subsurface entities and threats present in the DoD environment. A new capability is needed within AEGIS to present a common operational picture (COP) with complete situational awareness to the combat system watch standers. In order to support the development of such a COP subsystem, an innovative design is needed for a real-time adaptive data model of the battlespace, capable of supplying fire-control quality data to combat systems software applications. Development of such a data model will require achievement of dynamic on-the-fly run-time variation capability requirements critically necessary to successfully perform the mission within a rapidly changing combat scenario. The subsystem architecture should have the capability to provide engagement quality real-time track data to any combat systems application, which makes use of the services provided by the subsystem.

Sources of data may include identification data, estimated platform sensor and weapons capabilities, and observationally-derived behavioral data for entities within the battlespace. The subsystem must be modular in nature, and support sharing of the COP across all warfighting platforms within the battlegroup in a manner which insures the data coherence of the COP on every platform to the greatest extent possible.

The DCOP architectural model is needed and must have a common, expandable, and evolvable data model that supports the relevant metric set for any potential battlespace entity. An �evolvable� data model architecture should have the intrinsic capability to support any later addition, extension and/or modification without the requirement of extensively rewriting or scrapping previously developed code. The DCOP data model, including all its constituent software structures and component data elements, should, when taken in total, be capable of quantitatively and qualitatively describing the tactical and operational characteristics of all battlespace entities. This includes friendly, hostile, and neutral (i.e., non-combatants) within the host combatant�s Battlespace Area of Responsibility (AOR). It also includes any tactically relevant surface, subsurface, underwater, air and ground sensors, and weapons systems with their associated data and control streams capable of having an impact within the scope of the DCOP Battlespace AOR. The DCOP data model must also be capable of supporting data structure components and associated data fields enabling multi-platform data synchronization, access control, time tagging, and data senescence. Since it will not be possible to completely capture all relevant parameters for newly emerging combatant entities, sensors, or weapons systems, the data model must be dynamically evolvable and extensible (at run time) to provide for the emergence of previously unknown battlespace entities and their associated operational and tactical parameters. This combination of an overarching battlespace scope, a real-time non-disruptive data model, and structure content adaptability/evolvability, as well as multi-platform data synchronization support, are required for implementation of a DCOP capability within the fleet.

A Distributed Data Model Markup Language (DDML) will be developed to provide a software data structure design tool for DCOP, and a well-defined and concise documentation mechanism for all data structures making up the DCOP data model. The DDML will implement a dynamic, evolvable, and extensible descriptive linguistic construct capable of capturing the contents and structure of all DCOP data model constituent software structures and associated component elements as described above. The DDML must consist of a human-readable / machine-readable text-based (ASCII/Unicode compliant) descriptive language construct supporting linguistic components and structures roughly based on the Extensible Markup Language (XML) 1.0 Open Standard. The intent of developing the DDML is to provide both a software data-structure design tool for DCOP, as well as a well-defined and concise documentation mechanism for all data structures making up the DCOP data model as a whole. The DDML will provide a development tool, which will assist in both initial creation as well as any future maintenance, expansion, and adaptive evolution of the DCOP data model.� This will enable the data model to capture operational and tactical characteristics of future battlespace entities not yet encountered or envisioned.

The DCOP architecture should be capable of supporting the ability to allow the successful modification of DCOP data structures within an operating software environment. It is also critical that any data model changes made within an operating software environment can be accomplished without significant negative impact on currently executing software accessing the DCOP data model. Specifically, run-time modification of the DCOP data structures should be possible without: (a) requiring the running software to be paused or cease operation; or (b) requiring the need to restart/reload the system.

Both the DCOP data model and its associated DDML descriptive language architecture shall be well documented and conform to open systems architectural principles and standards. Implementation attributes should include scalability and the ability to run within the computing resources available within the AEGIS combat systems BL10 or later environment.

The DCOP data model should initially include operational and tactical parameters, maneuvering capabilities, sensors, weapons, and off-board tactical and operational data sources (Unmanned vehicles, Satellite links, etc.). Focus will be on commonly encountered battlespace entities (air, surface, and subsurface platforms) and their respective associated parameters (radar, sonar, and EW track data).

The parsing application may be written in either C++ or Java and be capable of running in both 64-bit Windows (Version 10 or later) and Linux (Redhat RHEL 7.5/Fedora 29/Ubuntu 18.4.1 or later) processing environments as a standalone application (i.e., no critical dependencies on network-based remotely hosted resources). The prototype DDML parser will demonstrate the following: (i) The ability to generate C++ data structure analogues to DDML linguistic components, and assemble them into overarching or composite data structures, each of which aligns to an associated battlespace entity; and (ii) The ability to non-destructively modify and update currently existing data structures within an operational DCOP environment.

Work produced in Phase II may become classified. Note: The prospective contractor(s) must be U.S. Owned and Operated with no Foreign Influence as defined by DOD 5220.22-M, National Industrial Security Program Operating Manual, unless acceptable mitigating procedures can and have been be implemented and approved by the Defense Security Service (DSS). The selected contractor and/or subcontractor must be able to acquire and maintain a secret level facility and Personnel Security Clearances, in order to perform on advanced phases of this contract as set forth by DSS and NAVSEA in order to gain access to classified information pertaining to the national defense of the United States and its allies; this will be an inherent requirement. The selected company will be required to safeguard classified material IAW DoD 5220.22-M during the advance phases of this contract.

PHASE I: Design, develop, and deliver a concept for a real-time extensible and evolvable DCOP battlespace data model and associated descriptive battlespace data model markup language. Establish the concept through evaluation of the ability of the proposed model. Establish that it can successfully capture all tactical and operational battlespace parameters as detailed in the Description. The Phase I Option, if exercised, will include the initial design specifications and capabilities description to build a prototype solution in Phase II.

PHASE II: Develop and deliver a prototype software DDML parsing application capable of generating data structures compatible with the C++ programming language and compliant with the requirements outlined in the Description. Use evaluation and test results to refine the prototype into a revised design that will meet Navy requirements. Develop and propose a Phase III Development Plan to transition the technology to Navy.

It is probable that the work under this effort will be classified under Phase II (see Description section for details).

PHASE III DUAL USE APPLICATIONS: Support the Navy in transitioning the technology for Navy use. Implementation will include the integration of the DCOP data model for evaluation to determine its effectiveness in an operationally relevant environment at an AEGIS test site or test bed.

This technology has potential within the commercial Air Traffic Control system in future development of an air traffic �common operational picture� capable of handling complex traffic control patterns.

REFERENCES:

1. Mattis, J.,�Summary of the 2018 National Defense Strategy.� US Department of Defense, 2018. https://dod.defense.gov/Portals/1/Documents/pubs/2018-National-Defense-Strategy-Summary.pdf

2. �Extensible Markup Language (XML) 1.0 (Fifth Edition).�� Worldwide Web Consortium (W3C)., 26 November 2008.� http://www.w3.org/TR/xml/

3. Schmidt, Douglas. �A Naval Perspective on Open-Systems Architecture.�� , Software Engineering Institute (SEI) Blog, Carnegie Mellon University, 27 March 2017.� https://insights.sei.cmu.edu/sei_blog/2016/07/a-naval-perspective-on-open-systems-architecture.html

KEYWORDS: Battle-space Data Model Markup Language; Extensible Markup Language; Distributed Common Operational Picture; Battlespace Data Model; Time-tagging and Data Senescence; Dynamically Evolvable and Extensible Data Model