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 an architectural framework, algorithm set, and Applications Program Interface for a Common Core Combat System (CCCS) Modular Multi-platform integration and coordination Data Exchange (MPDEX) subsystem capable of providing data synchronization and common operational picture coherency across multiple coordinating warfighting platforms.

DESCRIPTION: The current implementation of the AEGIS Combat System has fundamental architectural limitations deriving from its initial hardware and software design constraints. These architectural limitations have forced the use of inefficient “bolt-on” style modernization modifications and enhancements to meet evolving 21st century threats. Currently available commercial systems and software that might be considered for adaptation to partially address the Navy’s ever-growing needs for advanced situational awareness (SA) (e.g., the FAA Air Traffic Control System hardware and software) are dated in their design. They lack the flexibility and track capacity required to adequately address tactical requirements. Specifically, the currently available commercial technology mentioned above is limited in that it lacks the capability to track, identify, and manage complex air, surface and subsurface entities and threats present in a combat environment. Additionally, such commercial systems have no intrinsic abilities to provide the other critical weapon and sensor coordination services provided by an effective combat system implementation. Since no viable commercial alternatives exist or can be adapted, it becomes necessary for the Navy to pursue a different avenue of exploration.

A fundamental architectural redesign of the combat system’s core is needed to enable efficient, rapid, and cost-effective addition of new capabilities, such as multi-platform sensor and weapons coordination, off-board or organic on-the-fly sensor and weapons integration, built-in cyber resilience, and real-time fault recovery. To address these critical needs, a new CCCS architecture is currently in the planning stage, with the intent of providing a modular set of platform-agnostic common combat system services.

This CCCS implementation, when supplemented by platform-specific sets of weapon, sensor, and communications capabilities modules, will constitute a new modular and dynamically adaptable combat system design that can evolve to meet future emerging threats in a rapid and cost-effective manner. An innovative virtual communications channel, a data exchange architectural model, and a software framework that utilizes all available physical data communications pathways in an opportunistic manner are needed to insure real-time communications responses. Each virtual channel supported by this subsystem shall be fully characterized, and that characterization must be maintained dynamically throughout the effective lifetime that the channel is needed. The virtual channel subsystem developed will be utilized within the CCCS architecture currently under development in PEO IWS 1 to provide redundant, resilient, and radio frequency (RF) environment-adaptive real-time tactical data communications across multiple warfighting platforms within a battlegroup.

The innovative technology will improve the reliability and bandwidth of cross-platform combat systems data exchange services, thus improving multi-platform tactical coordination. In addition, this technology will significantly improve battlespace SA, thus reducing the management complexity of the overall battlespace. This allows for a reduction in the number of platforms needed in a specific tactical arena by improving the overall tactical efficiency of the battlegroup as a whole.

Development of an MPDEX architectural framework, algorithm set and Applications Program Interface (API) for use within the CCCS architecture, or as a modernization enhancement for future AEGIS baselines, is needed. MPDEX should, when taken in conjunction with (i) an appropriate CCCS core combat system modular architectural framework and software component API, (ii) an appropriate CCCS Ecosystem software execution model and software application or component API, and (iii) an appropriate multi-platform coordinated and synchronized Distributed Common Operational Picture (DCOP) subsystem, provide a comprehensive “core” architectural model for a complete, versatile platform-agnostic combat system implementation. “Core” means this system implementation will provide combat system services and capabilities satisfying common tactical warfighting requirements that span various and diverse surface combatants. This core combat system implementation, when configured with the appropriate surface warfighting platform-specific sensor and weapons capability software modules, should be capable of fulfilling the functional warfighting capabilities and requirements needed to support current U.S. Navy surface platforms well into the future.

The CCCS MPDEX will provide a CCCS modular cross-platform data exchange mechanism and synchronization capability through utilization of current shipboard communications services. MPDEX will make maximum use of currently available hardware-based communications facilities or other high-level communications capabilities in a manner intended to satisfy the following design criteria. First, it will need to increase the overall reliable/guaranteed bandwidth. Second, it will need to improve connection reliability and anti-jam resistance. Lastly, it will need to provide automatic hardware-connection “fail-over” capability in the event of loss of a hardware-based connection pathway. One method to achieve this goal is by utilizing the concept of “dynamic hardware channel bonding and aggregation”, in which a set of “virtual communications channels” are created and managed by the MPDEX algorithms and architecture resident within combat system host platform implementations operating at both communications endpoints. Each virtual communications channel will be associated with a “virtual” communications transceiver (or “node”) instance, capable of supporting the combat system’s network application layer. From the point of view of the combat system and its underlying network application layer, a “virtual” communications channel will appear and function as a “generic” physical communication interface and matching transceiver, supporting the same capabilities as other physical shipboard wireless transceiver suites. Software modules (and other client applications within the combat system) requesting the creation and/or assignment of a MPDEX virtual channel will be able to specify a set of minimum performance parameters for that channel, including minimum acceptable data up/down transfer bandwidth, data senescence/delay, maximum acceptable jitter, etc. during channel creation. Virtual channel Quality of Service (QOS) performance parameters (based on the metrics provided by the client application during channel creation and instantiation) will also be maintained in real time for each executing virtual channel instance and be made available to the client application by the MPDEX API. Client applications could qualify their requests for communications services through the MPDEX API by specifying minimum QOS parameters (e.g., data senescence, jitter, maximum and minimum bandwidth) needed for the task at hand. The potential parametric ranges for the requirements above will be wholly dependent on the requirements of any potential combat system client applications, but any prospective MPDEX implementation should be able to satisfy parametric requirements that range from single-digit millisecond to minutes (for data delay and jitter), and from kilobytes/sec to gigabits/sec (for bandwidth). It is important to note that there may also be other design approaches that achieve the capabilities described; however, any successful technological implementation must be capable of meeting the three design criteria outlined above.

MPDEX will provide a well-defined and documented API, which will allow combat systems software modules (and other client applications) to access MPDEX services. These services will include the ability to request the creation, deletion, reassignment and release of a virtual channel, the ability to specify or modify the minimum performance parameters for that channel, the ability to monitor the performance of that channel, and the ability to support a multi-platform channel endpoint discovery service.

The MPDEX subsystem and its associated API shall be well-documented and conform to open systems architectural principles and standards [Ref. 4]. Implementation attributes should include scalability and the ability to run within the computing resources available within the AEGIS Combat systems BL10. It will run in a Linux (Redhat RHEL 7.5/Fedora 29/Ubuntu 18.4.1 or later) environment. The MPDEX technology will demonstrate the following: first, the ability to create, manage, and destroy virtual communications channels based on the aggregation of a number of available physical communications channels, effectively bonding the data streams from those multiple physical channels into a single virtual data stream of higher reliability and bandwidth; second, the ability to dynamically reallocate physical channels at run-time across a virtual channel suite with minimal or no degradation in current system performance in order to maintain specified performance parameters for each virtual channel; and, lastly, the ability to monitor and report on the real-time performance of each virtual channel.

The development of the technology proposed in this topic will significantly improve the reliability and bandwidth of cross-platform Combat Systems data exchange services, thus improving multi-platform tactical coordination and having the potential to significantly improve battlespace SA, thus reducing the management complexity of the overall battlespace, which may allow for a reduction in the number of platforms needed in a specific tactical arena by improving the overall tactical efficiency of the battlegroup as a whole, with an associated overall improvement in affordability.

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: Develop an initial concept design for an MPDEX architectural model and algorithm set capable of meeting the subsystem and API requirements and capabilities outlined in the Description. (Note: The Government will furnish AEGIS BL9 or later combat systems design/architecture documentation, draft Common Core Combat Systems TLR documentation, and other appropriate material needed to assist in the development of the Phase I design effort.) Determine the feasibility of the concept by modeling and simulation. 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 a prototype MPDEX architectural model and algorithm set that meets the parameters detailed in the Description. Evaluate the prototype to ensure it meets an MPDEX design commensurate with the requirements outlined in the Description. Ensure that the prototype demonstrates the capabilities outlined in the Description during a functional test that will be held at an AEGIS and/or Future Surface Combatant (FSC) prime integrator supported Land Based Test Site (LBTS) capable of providing simulated physical communications hardware supporting multiple modalities and representing an AEGIS BL9 or newer combat system hardware environment. Provide a Phase III plan to transition the technology to Navy use.

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 MPDEX subsystem software to Navy use. Integrate the MPDEX subsystem software along with other CCCS compliant capability software modules into a prototype combat system implementation, consisting of a CCCS experimental prototype, implemented on a virtualized hardware environment within an AEGIS compliant land-based testbed. (Please note that the CCCS concept is currently being developed by PEO IWS 1SP as a potential AEGIS Combat System future replacement, as well as an initial combat system implementation for the planned FSC program currently envisioned by OPNAV N96.)

This capability has potential for dual-use capability within the commercial Air Traffic Control system in future development of an air traffic control system capable of rapid upgrade to handle increasingly 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. Mauerer, Wolfgang. “Professional Linux Kernel Architecture.” Wiley Publishing, Inc.: Indianapolis, 2008. https://cse.yeditepe.edu.tr/~kserdaroglu/spring2014/cse331/termproject/BOOKS/ProfessionalLinuxKernelArchitecture-WolfgangMauerer.pdf

3. Love, Robert. “Linux Kernel Development: A thorough guide to the design and implementation of the Linux Kernel (3rd Ed).”  Addison Wesley, 2010. https://doc.lagout.org/operating%20system%20/linux/Linux%20Kernel%20Development%2C%203rd%20Edition.pdf

4. Schmidt, Douglas. “A Naval Perspective on Open-Systems Architecture.”  SEI Blog, 11 July 2016. Software Engineering Institute, Carnegie Mellon University.  https://insights.sei.cmu.edu/sei_blog/2016/07/a-naval-perspective-on-open-systems-architecture.html

KEYWORDS: Virtual Communications Channel; Coordination Data Exchange Subsystem; Real-time Communications; Multi-platform Sensor and Weapons Coordination; Sensor and Weapons Capability Software Modules; Virtual Channel Performance Parameters