Real-Time Adaptive Data Model and Dynamically Extensible Markup Language for Distributed Common Operational Picture
AREA(S): Information Systems
PROGRAM: PEO IWS 1.0, AEGIS Combat System Program Office
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.
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.
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
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.
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.
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).
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.
J.,“Summary of the 2018 National Defense Strategy.” US Department of Defense,
“Extensible Markup Language (XML) 1.0 (Fifth Edition).” Worldwide Web
Consortium (W3C)., 26 November 2008. http://www.w3.org/TR/xml/
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
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