|
Combat System Dynamic Resource Management
Navy SBIR 2019.2 - Topic N192-113 NAVSEA - Mr. Dean Putnam - [email protected] Opens: May 31, 2019 - Closes: July 1, 2019 (8:00 PM ET)
TECHNOLOGY AREA(S): Battlespace, Electronics, Sensors
ACQUISITION PROGRAM: PEO IWS 1.0, AEGIS Integrated Combat Systems 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 Dynamic Resource Management (DRM) front-end tool for disparate commercial off-the- shelf (COTS) virtualization implementations for the AEGIS Combat System (ACS) to improve combat system operational availability.
DESCRIPTION: ACS resources consist of networked computing equipment and integrated software. The current approach to maximize ACS availability in the event of a system casualty (i.e., equipment failure or battle damage) is to use redundant hardware and software running in parallel. However, it is largely a manual process to restore the ACS to a redundant state upon repairing the ACS after a system casualty. In addition, not all functions in the ACS are currently redundant. The ACS program office has moved the AEGIS Weapon System portion of ACS to a virtual environment in the AEGIS Virtual Twin and is considering moving all ACS software to a virtualized environment. In order to do this, there must be a way to automatically move software functions to available computing assets during a system casualty and keep the ACS running even when all equipment in one space is impacted. Modern virtualization implementations have mechanisms to provision and remove virtual machines across a distributed environment (e.g., multiple servers in a data center), but each vendor implementation is unique and therefore does not provide the needed standard. The ACS Dynamic Resource Management (DRM) sought will provide a �front- end� standard to provisioning and removal functions built into disparate combat system virtualization implementations that give the same functionality to ACS.
The ACS DRM will provide automatic restoration to fully redundant operational functions by orchestrating the functionality of COTS virtualization implementations via a standard interface. In Navy ships, it is important to have multiple instances of an application running and to have those instances running in separate locations. This allows the application to failover to an instance in another location if one location in the ship sustains battle damage. The ACS DRM must maintain redundant copies of software in different ACS equipment spaces on ACS ships, given those ACS equipment locations on the ship will be available to the ACS DRM. Keeping multiple copies of system functions running in different parts of the ship and being able to fail in real time will improve the survivability of the ACS. Additionally, new operational capabilities written to this framework will gain the benefit of this combat system redundancy and recoverability from the outset, and more easily integrate the ACS. With greater insight into ACS status, ACS equipment sparing can be optimized.
This SBIR topic will develop a front-end to implement the ACS DRM. The effort will demonstrate it is vendor agnostic by implementation for the ACS DRM on at least two different COTS virtualization products (such as VMWare, Hyper-V, and KVM) to show the same functionality on both while presenting the same interface to ACS software. Servers used for the prototype should be Intel-based. The solution will demonstrate how ACS DRM handles failover, using Government-provided representative ACS software. This representative ACS software will have redundant operation and reporting mechanisms built into it, which will be accessible to the ACS DRM. The ACS DRM software solution itself must also be redundant and capable of failover in a casualty. Failover time and restoration times will be measured and evaluated. Detection of a fault requiring combat system failover and switching operation to the duplicate application should take no more than one second. Restoration to fully redundant operation should take no more than 30 seconds. The ACS DRM will provide a Graphical User Interface (GUI) that shows the status of all ACS DRM-controlled assets and allows an operator to manage ACS DRM configuration and operation. The ACS DRM should restore redundant operation of an application due to simulated loss of an instance of that application. The ACS DRM will provide interfaces for C/C++ and Java.
The Phase II effort will likely require secure access, and NAVSEA will process the DD254 to support the contractor for personnel and facility certification for secure access. The Phase I effort will not require access to classified information. If need be, data of the same level of complexity as secured data will be provided to support Phase I work.
Work produced in Phase II will likely 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 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 project 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 advanced phases of this contract.
PHASE I: Identify and design a concept for a front-end tool for the ACS DRM. Demonstrate, through analysis and modeling, that the ACS DRM approach can feasibly meet the requirements of the Description. Develop a Phase II plan. 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 front-end tool for the ACS DRM for testing and evaluation. This prototype should also include a prototype Software Development Kit (SDK) and draft documentation for integration and operation. Demonstrate that the prototype can meet the requirements in the Description. Determine if the technology has the potential to meet Navy performance goals.
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 ACS DRM front-end tool to Navy use. The final ACS DRM product will consist of an executable ACS DRM, an ACS DRM SDK, and documentation for integration and operation. Assist the Navy in testing at Navy land-based facilities, and possibly on an AEGIS ship. The target programs for ACS DRM are the ACS and the Ship Self Defense System (SSDS). Help in certifying ACS DRM through rigorous at-sea testing prior to fielding for AEGIS and later on other Navy ships.
Although this topic specifically addresses the ACS, the potential for use in fields other than the military is considerable. It can be beneficial in any computing environment where unattended high availability is required, such as data centers, power grid applications, machinery control applications, and many others. ACS DRM can be used in any implementation to recover from equipment failure by reconfiguring itself to use operational equipment. By always running multiple instances, a single failure will not result in a loss of service.
REFERENCES: 1. Rohloff, Kurt, Schantz, Richard, and Gabay, Yarom. "High-Level Dynamic Resource Management for Distributed, Real-Time Embedded Systems.� Conference: Proceedings of the 2007 Summer Computer Simulation Conference, SCSC 2007, San Diego, California, USA, 16-19 July 2007. https://web.njit.edu/~rohloff/papers/2007/Rohloff_Schantz_Gabay_DASD2007.pdf
2. LeBlanc, Lynn. �Multi-hypervisor management: Have you read the fine print?� Tech Republic, 23 January 2013. https://www.techrepublic.com/blog/data-center/multi-hypervisor-management-have-you-read-the-fine-print/
KEYWORDS: AEGIS Combat System; Dynamic Resource Management; Combat System Operational Availability; Combat System Virtualization; Combat System Redundancy; Combat System Failover
|