Designing the Integrated System

 Scope

  This analysis examined the current SCOUT and FIST2FAC architectures with the goal of integrating a SCOUT-like capability into a realistic 3D battle-space environment that FIST2FAC provides. SCOUT-like aspects for integration include biometric data collection as well as introducing UAVs into battle scenarios. This included an in-depth analysis of the hardware and software systems from both systems to determine the feasibility of integration in their current form, a study of alternatives and what adjustments would be needed to maximize the potential of integration.

Objectives

  The goal of this analysis is to evaluate the proposed integrated system across technical areas to determine how effectively the integration could be done in the current environment. A fully successful integration would transform the current system into the model as defined in the CONOPS, and may change as requirements, hardware, and software development continue to evolve. The functional areas outlined below provide a broad spectrum analysis regarding the current implementation level of effort.

Overview

  An integrated model consists of SCOUT and FIST2FAC components would offer researchers the opportunity to collect biometric and operational data from prospective naval destroyer operators and UAV operators during simulated training engagements and exercises. This data could be utilized to build baseline metrics for stress, task optimization, UAV Operator efficiency, and mission coordination effectiveness across multiple stations. The ability to gather these metrics quickly and accurately, without the need for real world exercises, will enable faster and more complete scenario analysis, which in turn will lead to optimized mission planning and procedures.

Assumptions

 This analysis assumes a “SCOUT 2.0” system (currently in development) which is expected to offer biometric tracking capabilities such as heart rate monitoring, eye tracking, mouse click rate, and file touch rate. Additionally, the database for SCOUT is currently a flat file; SCOUT 2.0 will include an XML database to achieve two objectives. One objective is to convert to a database form to facilitate data analysis (data analysis is cumbersome with the current format) and the second objective is to convert the data to database form so that it is able to be used within FIST2FAC, which uses a database for event and object data. The current version of SCOUT does not combine biometric spikes with event data; this database will provide the ability to complete this necessary step.  

  SCOUT also is a networked single user platform at present; the upgraded SCOUT 2.0 system will include the ability to utilize multiple UAV Operators during a mission. SCOUT 2.0 would then have an Automated Task Allocation Scheduler, or rather a tool which would allocate UAVs based on biometric data output from the Operators. One of most powerful aspects of SCOUT is the ability to offload tasks as an Operator’s workload increases. This ability would allow the Navy to entertain the concept of multiple UAVs assigned to one Operator: if one Operator becomes overwhelmed, there would be a mechanism to detect the problem, offload work, and thereby reduce risk.

Lastly, SCOUT 2.0 will feature a live feed data to simulate reconnaissance. Live feed data could be valuable not only for UAV Operators, but also for other actors in the naval battlespace.

These scenarios are each future enhancements that the SCOUT team has indicated are parts of the desired end state for the SCOUT system as a whole.

A further clarification for FIST2FAC is that the system that the team analyzed was a “FIST2FAC Lite” system. This system was based off the system that the NRL houses in the DC metropolitan area. The Navy has a much more extensive system located in Hawaii, complete with gunner props. The NRL system is lighter version of that system. Though it has distributed capabilities, the system is housed in one room of the NRL’s facility. Team assessments were based on the FIST2FAC Lite version.

 

References

All the applicable documents are listed in the table below.

Deliverable Type

Entrance Criteria

Objective (Exit Criteria)

Responsible Branch

Purpose of Deliverable

Project Proposal

Project Kick-off

Accepted Project Proposal

Systems Engineering Team

To define scope of the project

Concept of Operations

Accepted Project Proposal

PAP Team approval, Faculty advisor approval, sponsor approval and acceptance

Systems Engineering Team

Contract Deliverable

System Requirements Specification (SRS) document

Accepted Concept of Operations

PAP Team approval, Faculty advisor approval, sponsor acceptance

Systems Engineering Team

Supporting documentation for Contract Deliverable (Feasibility Analysis)

System Description Document (SDD)

Accepted Concept of Operations, accepted system requirements (from SRS)

PAP Team approval, Faculty advisor approval, sponsor acceptance

Systems Engineering Team

Supporting documentation for Contract Deliverable (Feasibility Analysis)

Feasibility Analysis

Accepted SRS and SDD

PAP Team approval, Faculty advisor approval, sponsor acceptance

Systems Engineering Team

Contract Deliverable

Recommendations for Integration

Accepted SRS and SDD

PAP Team approval, Faculty advisor approval, sponsor acceptance

Systems Engineering Team

Contract Deliverable

Program Management Plan

Project Kick-Off

PMP

Program Manager

Timely contract execution within budget and scope

Risk Management Plan

Project Kick-Off

Dynamic RMP

Systems Engineering Team

Risk mitigation for contract execution

Product Assurance Plan

Project Kick-Off

Dynamic PAP

Systems Engineering Team

Quality assurance for contract execution

Core System Design Document

Completion of SDD

Faculty advisor approval

Systems Engineering Team

Supporting design documentation detail

Table 1 – Reference Document Matrix

 

Approach

The team had access to minimal data on the systems in question, so the team used a qualitative analysis to design and evaluate alternatives for integration. In order to evaluate the viability of an integrated training system, the team performed a functional decomposition of both SCOUT and FIST2FAC Lite. While doing so, the team worked with the NRL to develop a Concept of Operations (CONOPS) for the integrated system. The CONOPS allowed the team to collaboratively identify the different goals of the different stakeholders for the integration, as well as learn more about the systems and the end goal for integration. The team worked with FIST2FAC Lite SMEs and SCOUT SMEs to identify several options for integration. Upon doing so, the team worked through the integration and determined strengths and weaknesses with different approaches. Throughout the process, the team analyzed biometric data collection for usefulness at each station within SCOUT and FIST2FAC Lite. Additionally, the team analyzed database design. The team attempted to incorporate interfaces so as not to limit the design for future integration implementation.

Evaluation Criteria

Upon a review of the system architecture, the team identified different design possibilities to execute for integration. These alternatives included three options, a Linked Independent Systems Alternative, a SCOUT Plugin Alternative and a Fully-Integrated (SCOUT) Alternative. For detailed documentation regarding the integration scenarios, please click the link below:

http://seor.gmu.edu/contact.html

Or contact Dr. Kathryn Laskey directly at:

klaskey@gmu.edu