TECHNOLOGY AREA(S): Human Systems

ACQUISITION PROGRAM: Program Executive Office, Future Combat Systems (IWS 7.0)

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 5.4.c.(8) 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 virtual assistant tool for combat system console operators that will improve efficiency and provide recommended actions using artificial intelligence algorithms.

DESCRIPTION: Artificial Intelligence (AI) has advanced significantly with the development of �Deep Learning� algorithms.� These algorithms have led to the commercial development and deployment of a number of software AI products such as Siri, Cortana, and Alexa, which endeavor to assist individuals in accomplishing routine daily tasks with a minimum of confusion, reduction in required time, or specifically directed research.� These algorithmically based products eliminate the need for individuals to execute specific internet searches for time, weather, locating and playing music, and setting schedules and alarms.� The Navy seeks implementation of a combat system console operator virtual assistant within the AEGIS combat system that leverages current AI algorithms and can develop new AI algorithms as required, along with a suitable modular system software architecture.

The current tasking of a combat systems console operator includes (but may not be limited to) coordinating with other console operators (via voice or text); monitoring target track data (consisting of both organic and external radar and other sensor-sourced track data); and identifying tracks and selecting those that represent a potential threat requiring engagement by various shipboard weapons systems. Additional activities include assigning weapons to specific tracks; monitoring the success and/or failure of those engagements; and re-scheduling failed engagements if sufficient time exists. This tasking represents an overwhelming workload. Given the potential growth in the number of target tracks introduced into the battlespace by the emerging development of low-cost unmanned aerial vehicles (UAVs), as well as newly developed adversarial tactics that utilize large-scale saturation raids, the potential for a console operator to suffer �information overload� has become a serious point of concern.� As a result, this can cause a catastrophic failure mode within the ship self-defense scenario.

The virtual assistant will help prevent console operator overload by replacing some tasks currently performed by human operators that could be more efficiently executed by intelligent automated software.� Examples of these tasks are monitoring radar tracks for unexpected variations and monitoring the Common Operational Picture (COP) for potential blue-on-blue or de-confliction issues.� These are better handled, at least in part, by software algorithms, which can operate ceaselessly without the otherwise vigilant efforts required by human interface.� In essence, the virtual assistant will act as the operator�s proxy within the battlespace for certain required actions in the digital domain.

The operator should be able to configure the individual virtual assistant to set up tasks and goals, and provide customized alerts.� The virtual assistant, once configured, should be capable of automatically presenting context-based options for actions to complete specific mission functions.� The configuration cache for a virtual assistant should be portable, allowing the operator to access the virtual assistant from one console to another console and potentially from one platform to another platform, enabling the operator to develop his own personal optimal virtual assistant configuration. An operator should be able to carry this configuration cache with him from posting to posting (across multiple ship postings), and load/update/reconfigure this configuration cache as needed.� It could reasonably be considered part of his personnel profile.� Ultimately, each operator�s virtual assistant might exist as a persistent presence within the battlespace digital domain, executing when the operator is disconnected or off-duty, and running pre-selected background tasks (hereafter referred to as virtual assistant �autonomous� mode). The results will be available for review when the operator logs in to a console or otherwise digitally connects to the battlespace digital domain.

This capability would enable the virtual assistant to support training utilizing the operator�s past performance to develop enhanced training scenarios focused on improving operator proficiency. The virtual assistant, as a software component running within the combat system cyber security enclave, will be subject to the same cyber security restrictions implemented to secure other software components within the combat system.� There may also be additional �virtual assistant� specific functional constraints defined and implemented within the cyber security enclave to restrict virtual assistant originated actions when the virtual assistant is operating in unattended (autonomous) mode.

The software algorithms and architecture of the virtual assistant should possess certain architectural attributes. The overall virtual assistant software architecture, as well as any algorithms implemented with it should be self-contained (for example, the software should be capable of operating independently within the combat systems computer network, without requiring external connectivity to non-organic servers) and have minimal impact on the performance of the combat system. Both the virtual assistant software architecture and any AI algorithms developed should be well documented, and conform to open systems architectural principles and standards.� The virtual assistant software architecture should provide a well-defined and documented applications program interface (API) between the architecture and any other combat systems (CS) applications or CS software infrastructure, allowing easy portability to other CS architectures (such as Ship Self-Defense System [SSDS] and the Future Surface Combatant [FSC] combat system that is currently in the planning stage). The operator must be provided with potential warning notifications as well as the capability to automatically select multiple tracks (either the entire group, or through specific track negation within a selected group) based on predicted common track sector of origin, current track bearing, track identification (ID), or track behavior. The virtual assistant will be capable of providing potential warning notifications as well as an automatic monitoring capability for communications (e.g., radio, database). The virtual assistant will be capable of learning from the current tactical situation, and make future warnings, recommendations, and actions based on past tactical behavior of both the tracked entities and the console operator. Input will be through either voice command or the tactical console control functionality. The virtual assistant will have specifically configured settings that can be saved by the operator such that both the virtual assistant�s learned behavioral patterns and the operator�s preferences for future use are restored when the operator logs in to a console.

The virtual assistant will demonstrate >50% improvement over an unassisted operator (on average) in the number of tracks that the operator can efficiently handle.

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 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 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 a concept for a virtual assistant tool for combat system console operators. The concept will describe the improvements and efficiency of the tool and show it provides recommended actions using AI. Feasibility will be established by modeling and analysis and through evaluation of estimated human performance improvements as described in the description. The Phase I Option, if awarded, will include the initial design specifications and capabilities description to build a prototype in Phase II. Develop a Phase II plan.

PHASE II: Based upon the results of Phase I and the Phase II Statement of Work (SOW), design, develop, and deliver a prototype virtual assistant tool. The prototype will demonstrate the capability to perform all parameters described in the description after implementation and integration into the combat system environment. The demonstration will take place at a Land-Based Test Site (LBTS), which represents an AEGIS Baseline 9 or newer combat system environment.� Prepare a Phase III development plan to transition the technology for Navy combat system and potential commercial 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 Government in transitioning the virtual assistant tool for Navy use. Implementation will be a fully functional tool incorporated into the AEGIS combat system baseline modernization process.� This will consist of integrating into a baselines definition, validation testing, and combat system certification.

The potential commercial applications for this technology include Automated Air Traffic Control, Public Highway traffic management, Emergency traffic management and evacuation planning, and Unmanned/Assisted Vehicle control.

REFERENCES:

1. Vasudevan, Vijay. �Tensorflow: A system for Large-Scale Machine Learning.� Usenix Associaton. 2 November 2016. USENIX OSDI 2016 Conference.� 2 November 2016. https://www.usenix.org/system/files/conference/osdi16/osdi16-abadi.pdf

2. Vasudevan, Vijay. �TensorFlow: Large-Scale Machine Learning on Heterogeneous Distributed Systems.� Usenix Association.� 2016.� 8 March 2017. http://download.tensorflow.org/paper/whitepaper2015.pdf

3. Schmidhuber, J�rgen. �Deep Learning in Neural Networks: An Overview.� Science Direct. 9 March 2014. Vol 61, Neural Networks Journal.� Jan 2016. http://www.sciencedirect.com/science/article/pii/S0893608014002135

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

KEYWORDS: Artificial Intelligence; Console Operator Virtual Assistant; Deep Learning; AEGIS Console Operator Overload; Learned Behavioral Patterns; Large-scale Saturation Raids.