UserOriented Systems Engineering for the Navys Battle Force Tactical Training BFTT Air Management No

1
User-Oriented Systems Engineering for the Navys
Battle Force Tactical Training (BFTT) Air
Management Node

• Craig A. Petersen
• David B. Cavitt
• BMH Associates, Inc.
• 5425 Robin Hood Road, Suite 201
• Norfolk, Virginia 23513-2441. U.S.A.

Kim Marshall Digital System Resources,
Inc. 2697 International Pkwy Parkway One, Suite
104 Virginia Beach, Virginia 23452
2
Introduction

• Introduce a MS software development process
  model and discuss user-oriented (motivated)
  engineering during each activity.
• Discuss the BFTT AMN.
• Discuss the user-oriented (motivated) engineering
  associated with each phase of AMN development
  life cycle.
• Discuss the integration and deployment of the AMN
  training capabilities by fleet personnel.
• Summary.

3
MS Development Life Cycle Problem

• Evolving MS standards support greater
  interoperability and reuse.
• Easier to develop larger-scale, more realistic
  synthetic training environments for all MS
  domains.
• Time constraints imposed by the schedule can pose
  problems for users trying to formulate and
  understand system requirements and
  specifications.
• User-based requirements analysis is essential to
  build a credible system.
• Prototyping supports iterative experimentation to
  evolve requirements, and discover errors or
  omissions.

4
MS Software Development Process and User Inputs
Simulation System Requirements
Military and User Domain Requirements
Simulation Domain Requirements
Reusable Components
5
Battle Force Tactical Training (BFTT)

• Naval Sea Systems Commands (NAVSEA) Performance
  Monitoring, Training, and Assessment Program
  Office (PMS-430).
• Stimulation To Combat System Sensors.
• Provides Connectivity To Use Overarching
  Synthetic Battlespace.
• Supports Intra/Inter-Ship, Battle Group, and
  Joint Training.
• Provides Real-Time, Distributed Combat System
  Operator And Team Training.
• Improved Operational Training Effectiveness
  Through Its Rapid Debrief Capability.

6
BFTT System Architecture
NAVSSI BLK 3
BOPC 3
BOPC 2
P S
BOPC 1
WSN-x 1/2/5/7
SQQ-89
COMM
SQQ-89 OBT
BEWT
NAV SIM
Q-89 LAU
INES
GFCP
C4I LAU
HARPOON
HET LAU
TWCS
CEC
DCM
CTA
BFTT Synthetic Battlespace
AWS
ACDS
CDS
SSDS MK 1/2
TRNG LAU
RESS
SPS-48
AMN
RESS LAU
AEGIS
ACTS MK 50
SPS-49
STIM/SIM
AIMS MK XII IFF
BFTT (Present)
BFTT (Future)
Combat System
7
BFTT Air Management Node (AMN)

• Improve upon the ATC/AIC training capabilities of
  the BFTT Combat Simulation Test System (CSTS)
• Improved HCI with enhanced simulation and
  modeling capabilities (i.e., fidelity).
• Initiate a migration path for BFTT using the
  Defense Modeling and Simulation Offices (DMSO)
  High Level Architecture (HLA).
• Leverage DARPAs Synthetic Theater of War (STOW)
  technology to provide a more robust and realistic
  synthetic environment capable of supporting U.S.
  Navy shipboard ATC/AIC training requirements.

8
AMN Operational and Training Capabilities

• Provide ATC and limited AIC training for CV and
  LHA/LHD ship types. Aircraft modeling includes
  all relevant Navy and USMC FWA and RWA.
• Provide for speed / heading / altitude changes
  based on published approach procedures or as
  directed by Carrier Air Traffic Control Center
  (CATCC) or Helicopter Direction Center (HDC)
  controllers.
• Provides for some emergency behavior training
  that includes failure to commence approach on
  time and/or out of position, inoperable IFF,
  divert, TACAN failure, and delta.
• Support Link4A / AIC training by providing the
  ability to send and receive Link-4A messages via
  the AMN Server which establishes communications
  directly with the shipboard combat systems.

9
AMN Users

• Initial installation on board LHD 6
  multi-purpose Amphibious Assault Ship.
• Three separate groups of controllers Air Traffic
  Control (ATC), Air Intercept Control (AIC),
  Tactical Air Control Squadron (TACRON).
• In-port and at-sea proficiency training for
  aircraft departure / recovery.
• Scheduled for other BFTT-equipped ships
• Shore-based sites (e.g., Navy Schoolhouses)

10
User Engineering Inputs and Feedback

• ATC schoolhouse Requirements analysis, concept
  paper, functional descriptions, users guide.
• Shipboard users Users guide, prioritization of
  functional development based on fleet needs.
• Program office Requirements analysis, concept
  paper
• Program manager Requirements analysis

11
Rapid Prototyping For HCI Requirements

• AMN Human Computer Interface (HCI) provides the
  pseudo-pilot control over the simulated aircraft.
• Operator actions result in the HCI generating
  command and control messages controlling the
  flight regime of the simulated FWA and RWA.

12
Rapid Prototyping For HCI Requirements

• Blackboard HCI for initial requirements
  manifested as an Excel spreadsheet, progressively
  reviewed and refined using fleet and schoolhouse
  personnel.
• Prototype testing involved the use of ATC
  personnel interacting with real aircraft to test
  the interface functionality.
• Iterative refinement of the spreadsheet-based
  prototype resulted in a transition to a
  Motif-based implementation running on the target
  platform.
• GUI generation tool allowed rapid observation of
  proposed HCI changes.
• Prototype ultimately provided many reusable
  software components used in the final HCI
  implementation.

13
Knowledge Acquisition / Engineering (KA/E) To
Meet Modeling Requirements
Well-formalized process used to assess model
requirements.
Real-world technical and tactical knowledge
formally documented AMN FWA/RWA behaviors for
software/system developers.
14
Knowledge Acquisition / Engineering (KA/E) To
Meet Modeling Requirements

• Principle task of KA/E during AMN life cycle was
  to support ongoing development of the HCI and new
  IFOR aircraft behaviors.
• Primary sources for KA/E were CATCC, LHA NATOPS,
  and other flight manuals.
• FDs covering Approach, Departure, Communications,
  and Tactical behaviors were reviewed by
  instructors at ATC school for accuracy and
  completeness.
• FDs were traceable to verify doctrinal data.
• Where direct traceabilty was not possible, SMEs
  with relevant experience were used.
• FDs were the primary document for FWA/RWA
  behavior development.

15
Concurrent Engineering and Testing

• Extensive reuse paradigm for AMN design and
  development resulted in development emphasis on
  new interfaces to support AMN specific data flow.
• Reuse focus (interfaces) allowed for concurrent
  systems development 1) HCI, 2) aircraft
  modeling, 3) simulation / communications
  infrastructure (once the data flow was
  identified).
• Later part of development cycle required
  incremental development and delivery A1 thru A3
  tasking providing differing levels of
  functionality and training capabilities.
• End-user tests focused on stress testing system
  and operator performance.

16
Shipboard Integration and Training

• Ultimately, Navy testers ensured reliable and
  sufficient functionality within the initial BFTT
  AMN system.
• Critical training activity for the use of BFTT
  AMN by fleet personnel (aboard LHD 6) included
  pseudo-pilot training.
• Deployment schedule of LHD 6 compressed final
  activities associated with software development
  life cycle.
• Consequent shipboard training coincided with
  system installation, system testing, controller
  training, and maintenance training.

17
Lessons Learned

• Operational requirements and associated training
  priorities can vary greatly among different fleet
  personnel and enlisting feedback from a broad
  range of users is essential for general
  acceptance.
• Development of accurate, concise, and
  authoritative design documentation supports user
  analysis and is critical for the iterative
  refinement of system requirements.

18
Summary

• Inclusion of the end-user throughout the
  development process was a significant factor to
  the successful integration of the AMN with BFTT.
• The process model presented here, and its use in
  AMN development supported requirements analysis
  and definition.
• The rapid prototyping strategy for HCI
  development helped the user define, evolve, and
  refine the requirements and eventual performance
  of the system.
• The formal documentation associated with the KA/E
  activities was essential for model development
  and supported assessments (verification)
  regarding the correctness of simulated behaviors.