Attachment 2 - TAGARS SOW.pdf

TECHNICALLY ADVANCED GENERAL AVIATION RESEARCH

SIMULATOR (TAGARS)

FEDERAL AVIATION ADMINISTRATION

CIVIL AREOSPACE MEDICAL INSTITUTE

HUMAN FACTORS RESEARCH DIVISION

(AAM-500)

TECHNICALLY ADVANCED GENERAL AVIATION

RESEARCH SIMULATOR PURCHASE AND

INSTALLATION CONTRACT

STATEMENT OF WORK

July 31, 2018

Contents

1 Introduction and Overview 6

1.1 Background 6

1.2 General Information: 6

1.3 Scope of Work 6

1.3.1 Simulation Device Characteristics 7

1.3.2 Aircraft Type to Be Simulated 7

1.3.3 Examples of Research Projects. 8

1.3.4 Overview/description. 8

1.4 Material 9

2.0 General Requirements 9

2.1 Hardware 10

2.2 Software 10

2.2.1 Deliverable software and formats 10

2.2.2 Graphical conventions 10

3.0 Cockpit Shell 11

3.1 Maximum Cockpit Size 11

3.2 Cockpit Seats 11

4.0 Pilot Interface I: Cockpit Instrumentation and Displays 11

4.1 Cockpit Graphics Generator Hardware Capabilities 13

4.2 Graphics System Monitor Characteristics 132

4.3 Transport Delay 13

4.4 Hardware Driver Requirements 14

4.5 Cockpit Graphics Display Editor Capability, Individual Display Reconfiguration 14

5.0 Pilot Interface II: Controls 14

5.1 Dual Manual flight controls 14

5.1.1 Pitch/Roll Control 15

5.1.2 Rudder Pedal Controls 154

5.1.3 Brakes 154

5.1.4 Control Loading / Force Feedback 15

5.2 Automatic Flight Controls 15

5.2.1 Autopilot 15

5.3 Discrete system controls 165

5.3.1 Circuit breakers and other discrete controls appropriate to the aircraft configuration 165

6.0 Pilot Interface III: Auditory Information 16

6.1 Simulated Radio/Intercom Communications 16

6.2 Simulated Aircraft and Environmental Sounds 17

7.0 Pilot Interface IV: Out the Window (OTW) Display System 176

7.1 Expected Hardware Characteristics of Government-provided Display System 176

7.2 Expected Software/Communications Interface Requirements 176

7.3 Expected OTW Software Characteristics 17

8.0 Simulation Database Modeling 17

8.1 Aircraft systems to be modeled 17

8.2 Navigational database 1817

8.3 Aero model database 17

9.0 Operator Interface: Displays and Control Functions 18

9.1 Experimenter/Operator Station (EOS) Displays 18

9.2 Hardware considerations for the EOS 198

9.3 EOS Control Functions 19

9.3.1 Control of all aircraft system functions 19

9.3.2 Control of all meteorological conditions 19

9.3.3 Control of audio levels/ cockpit isolation. 19

9.3.4 Control of ambient lighting. 19

9.3.5 Control of cockpit lighting systems. 19

9.4 EOS Scenario Editing Functions 19

9.5 Event Marker 22

9.6 Data Collection/Storage Capability and Procedures/Safeguards 222

9.6.1 Variable-rate/frequency data collection 232

9.6.2 Data collection onset/offset control (programmable and manual) 232

9.6.3 Data variable list selection for recording 233

9.6.4 Data File Format 243

9.6.5 Data back-up at trial termination 243

9.6.6 Data “always on” mode 243

9.6.7 Video/audio recording 244

9.7 Operator Control during operation 254

9.7.1 Replay 254

9.7.2 Fly out of replay 254

9.7.3 Start/stop/freeze 254

9.7.4 Changing lighting, time of day, and weather 254

9.7.5 In-flight Scenario Start 255

9.8 Other operator functions 255

9.8.1 Pseudo-pilot function 255

9.8.2 Air Traffic Control function upgrade path 265

10.0 Ad Hoc 266

11.0 Miscellaneous Requirements 266

11.1 Spare Parts List 266

11.2 Tools and Test Equipment 276

11.3 Documentation 276

11.4 Source Software Back-ups/Archive, Version Control 28

12.0 Training and Job Performance Aids (JPAs) 29

12.1 Orientation Training 29

12.2 Job-Performance Aids 29

12.3 Cold-start Procedure. 29

12.4 Agreements (right to copy training materials). 300

13.0 Acceptance Test Procedure 300

14.0 Government Furnished Property 311

15.0 Period of Performance 311

16.0 Place of Performance 321

17.0 Security 322

18.0 Engineering Change Proposals (ECP) 332

19.0 Links 332

20.0 Program Management 332

21.0 Quality Assurance 333

22.0 Communication 343

23.0 Contract Deliverables 343

24.0 Travel 344

25.0 Contracting Officer’s Representative 344

26.0 General Definitions 354

27.0 Acronyms 355

1 Introduction and Overview

i. The purpose of this contract is to provide a firm-fixed-price purchase of the components and on-site installation and training for the Technically Advanced General Aviation Research

Simulator (TAGARS) to the Office of Aerospace Medicine Civil Aerospace Medical

Institute (AAM CAMI) Aerospace Human Factors Research Division (AHFRD, AAM-500).

1.1 Background

i. The Technically Advanced General Aviation Research Simulator (TAGARS) is part of the

Aerospace Medical Equipment Needs (AMEN) Phase II acquisition program, which was established to continue to provide urgent upgrades to the aging and obsolete research laboratory equipment of the two CAMI research divisions. The AMEN 2 program is a continuation of

AMEN 1. AMEN 1, a non-NAS Technology Refreshment (TR) effort, Acquisition Category level 5 (ACAT-5), approved on 24 May 2010, was established to replace research laboratory equipment at CAMI. AMEN 2, a non-NAS Information Technology (IT) acquisition effort, was approved by the Acquisition Executive Board (AEB) as a TR ACAT-5, on 11 June 2013. It was later designated to be a Variable Quantity (VQ) ACAT-5 effort on 30 April 2014 and tailored to move directly to the Final Investment Decision (FID) of the Acquisition Management System

(AMS) process, scheduled to occur on 16 September 2015. The AMEN 2 program requirements are presented in the AMEN 2 final Program Requirements Document (fPRD).

ii. The TAGARS supports the laboratories in the Division, which focus on improving human performance through enhanced equipment design, interface design, agency workforce optimization, investigations of work environment issues, and organizational effectiveness. This work is conducted by the Flight Deck Human Factors Research Laboratory (FDHFRL, AAM-

510) and the NAS Human Factors Safety Research Laboratory (NASHFSRL, AAM-520).

1.2 General Information

i. The AHFRD is replacing the Advanced General Aviation Research Simulator (AGARS), an older single-engine reciprocating (piston) engine research simulator with a new high-fidelity flight simulator for the purpose of continuing advanced general aviation research in established areas and expanding into others of technically advanced cockpit designs that could not be properly supported with our existing simulator, but could be supported by a current-generation simulation device.

1.3 Scope of Work

i. The AHFRD has a requirement to update the technology of its aviation simulator infrastructure. The technical update includes hardware and software acquisition, installation and training with follow-on annual maintenance of the software components in support of the

TAGARS system.

1.3.1 Simulation Device Characteristics

i. The government believes that an uncertified Level 6 equivalent Single Engine Reciprocating

Engine (SERE) fixed-wing aircraft flight simulator will meet the research requirements. The simulator will be used for conducting human factors research studies. Each study typically has requirements to modify or install hardware and software to meet the goals. As a result, a certified flight-training simulator is not appropriate or required as the changes made in displays and hardware would likely alter the basis for simulator certification. The laboratory performs no flight training and the pilots cannot log the simulator flight time (as a function of non-certified simulators being used).

ii. Because the objective of the Technically Advanced General Aviation Research Simulator

(TAGARS) is to prioritize reconfiguration of the displays and controls systems, the cockpit shell design can be generic to the single engine class aircraft. While the engine and flight performance of the simulator must be matched to a specific aircraft so as to verify the aerodynamics model, the cockpit panel must be designed to fit displays that can be reconfigured to displays of future cockpits.

It is expected that this device will be manufactured from readily available commercial materials and components to the extent possible, and manufactured to best commercial practices.

iii. The contractor must comply with the requirements of either a) or b) below in order to be found technically acceptable and to move to the Best Value determination.

a. Contractor must provide evidence, through thorough documentation (that it has previously constructed, for either internal or external research and development, a

General Aviation flight simulator, and provide information as to the location of such device to enable the government to evaluate it prior to contract award if deemed desirable by the government. (Evidence of this should include at a minimum: photos, a high-level system diagram, a description of the intended function, and for whom it was built.)

b. Provider will demonstrate, through thorough documentation, that it has engaged in the maintenance and modification of a General Aviation flight simulator in the areas of both hardware and software, and provide information as to the location of such device to enable the government to evaluate the results of this maintenance/modification activity prior to contract award if deemed desirable by the government. (Evidence of this should include at a minimum: photos, a high-level system diagram, a description of the intended function, and for whom it was built.)

This evidence of past experience will be evaluated as part of the Best Value determination, and a contractor who meets the requirements of c) below will be given the highest weighting.

c. The contractor must demonstrate experience in the engineering, design, and development of real-time flight-simulation systems, demonstrate experience in graphics modeling of instrument display systems and complex visual environments, and demonstrate ability to provide data collection and data analysis systems. The contractor must demonstrate the aforementioned by providing evidence that their organization has previously constructed a General Aviation Flight simulator, similar to that described in this SOW, and by allowing government to inspect one or more of these products that is in service. (Evidence of this should include at a minimum: photos, a high-level system diagram, a description of the intended function, and for whom it was built.)

1.3.2 Aircraft type to be simulated

i. The aircraft type desired is a complex aircraft in the category of light, high-performance single-engine, piston powered, with retractable gear. The aircraft represented must have a technically advanced cockpit as defined by the use of an Electronic Flight Instrumentation System (EFIS) and integrated (not federated) cockpit systems. Links to example cockpits are listed in Section

19.0.

1.3.3 Examples of Research Projects

i. Research expected to be conducted in this device includes examination of the following: (a) Pilot execution of Required Navigation Performance (RNP) procedures using advanced Primary Flight

Displays, (b) use of head-worn displays using synthetic or enhanced vision for avoidance of terrain and obstructions, (c) use of enhanced guidance graphics for 4-D navigation, (d) detection and avoidance of airborne traffic, (e) effects of Terrain Awareness and Warning Systems

(HTAWS) and automation on pilot performance and workload.

1.3.4 Overview/Description

i. The device must consist of a cockpit environment including:

(a) An enclosed cockpit shell. Means must be provided to keep the temperature within the cockpit comfortable during operation. It may have “open” windows; areas of the shell which would have

Plexiglas windows or bubbles in the aircraft may be represented by appropriately shaped, sized, and positioned openings in the shell. The cockpit shell does not need to be specific to any certain aircraft and can be generic in nature to the single-engine class aircraft. The shell design must have the ability to allow cockpit panel reconfiguration of displays and interchanging of different control-panel configurations.

(b) The experimental environment requires multiple recording devices such as cameras, eye-tracking equipment, and head-mounted optical devices, sound equipment and other devices that are attached to the cockpit shell. The inclusion of mounting points for these devices is addressed in section 3.0 ii.

(c) An operator's (often called “instructor’s”) control station (see Level 6 requirements). This must be separate from the simulator, which must feature controls for manipulating the simulation scenario. For our purposes, a scenario is defined as a set of conditions that describe simulator initial conditions as well as subsequent changes in weather, winds, and the appearance of pseudo vehicles as triggered by operator-selected events or changes in monitored variable. Scenario editing must include, but not be limited to, the ability to set a starting location, weather and atmospheric conditions, time of day, movements of pseudo vehicles, and the setting of triggers for recording flight data and varying weather and pseudo vehicle paths.

(d) High-resolution graphical display(s) for instrumentation depiction.

ii. The graphic displays must be capable of generating the following cockpit instrumentation (per

Level 6 requirements):

(1) Primary instruments and navigation displays including a Primary Flight Display (PFD) and a Multi-Function Display (MFD), the latter providing a moving map as one of its multiple functions.

(2) Engine/power-plant/power-train instrumentation (EICAS, etc.)

(3) Communications system display (this may be part of an integrated nav/com system)

(e) Simulation software and hardware to interface to the cockpit displays

(f) Control input systems

(g) Interface capability to connect with an out-the-window (OTW) visual scene display system

(MetaVR image generator system).

(h) Audio communications system (see Level 6 requirements)

1.4 Material

i. The contractor must provide the following per their descriptions in the SOW below:

(a) All hardware and computers purchased or developed for this program

(b) All system software and executable software

(c) System installation

(d) System training

(e) User documentation that must allow operators to easily operate, debug, and maintain the system.

2.0 General Requirements

2.1 Hardware

i. The contractor solution must consist of Commercial off the Shelf (COTS) components to the greatest extent possible and if non-COTS items are proposed as part of the contractor’s proposed solution, the contractor must coordinate with Government.

2.2 Software

i. Contractor must supply a software configuration plan for all software development modules.

2.2.1 Deliverable software and formats

i. Source programs for government use only must be provided, on electronically readable storage media that are separate from the simulator, for all software developed under the contract and must use a widely used, accepted and well-documented high-level programming language, comparable to those specified in the IEEE Spectrum index

(https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages). The software packages must include routines to easily edit, compile, catalog and link software modules, and to add new modules if needed. All software provided must remain government property and must not be available to third parties except in direct support of FAA contract work.

Graphics editing software must support easy creation, editing, and integration of graphics into cockpit displays by a minimally trained user. Graphics created must be executable under

Windows or Linux and linked to variables broadcast from the main simulation computer.

Graphical presentations on the head-down cockpit displays (sets of instrumentation) must be selectable from the menus used on the Operator Station and in the Operator Station scenario editor. The proposed system must contain no software that requires other than initial licensing (no recurring annual licensing or separate development and run-time licenses).

2.2.2 Graphical Conventions

i. Generally accepted software conventions for human-computer interface (HCI) must be followed for all graphical-user interface (GUI) applications (e.g., FAA Human Factors Design Standard, section 5.12, GNOME, Motif, or comparable) to guarantee acceptable human performance during operation of the simulator. For example, graphical input buttons must, per convention, depict the action that they cause or enable, not the current state of the system or subsystem (e.g., input buttons are not to be labeled with status indicators, and status indicators must appear as separate graphics). GUI guidelines must be appropriate to the computer operating system desktop environment to be used but must also adhere to best practices for optimizing human performance (e.g., published guidelines for GNOME, 2.0, or comparable Windows guidelines documents). Details of the Operator’s Station Interface and applicable standards will be discussed at the first post-award meeting to verify that appropriate criteria have been identified and will be used.

3.0 Cockpit Shell

i. The primary focus of the AHFRD’s flight-deck experiments is the pilot’s performance while using the technically advanced controls and cockpit displays. Even though a specific FAA Level

6 aerodynamic and engine model is required, the cockpit shell can be generic for the single-engine class aircraft. The Aerospace Human Factors Research Laboratory has multiple rooms with visual-display options, which requires the simulator to be mobile on casters, which can be locked when the simulator is in its final location. The shell/platform must be securable in its final location to avoid any movement, which can be achieved by something on the order of threaded stand-off posts (manually adjusted) or similar such devices that shift some of the weight from the casters to these posts. Any such mechanisms must be placed frequently enough around the perimeter of the platform to avoid any flexing or bending of the frame when the posts are lowered to contact the floor.

ii. Mounting points (anchor points, platforms, attachment points) for video cameras that will be used to monitor and record pilot activity in the cockpit must be included in the shell. The precise location of these attachment points is to be determined in the post-award conference. The intent is to have the minimum capability of both a wide-angle comprehensive view of the cockpit and a second view which is zoomed to capture any particular display or control. It is also likely that a profile image of the pilot may be desired to monitor head movement, etc. Thus, there is a likelihood of mounting points being required on the aft bulkhead of the simulator inside the cockpit (for wide and instrument views) and potentially points on either side of the cockpit (on the outside of the simulator) that would allow cameras to be mounted to capture images of the pilots when required. The precise locations will depend upon the types of cameras selected, but the usual diameter and thread specifications used on most tripods and standard camera mounts must be provided or allowed for.

3.1 Maximum Cockpit Size

i. Maximum cockpit size must be no larger than:

7 feet long

5 feet wide

5.5 feet tall

3.2 Cockpit Seats

i. Cockpit seats must be:

Two seats side-by-side with forward/aft and vertical adjustments typical of this aircraft class.

4.0 Pilot Interface I: Cockpit Instrumentation and Displays

i. The graphical displays must be capable of generating real-time graphics used for aircraft cockpit displays. This includes depictions of dials, switches and instruments (analog and digital) to be in the cockpit (displays dependent upon aircraft model and configuration used as a base design).

These displays must be updated in real-time based upon pilot-initiated aircraft dynamics and/or pilot intervention through switches and knobs for each display or, if selected, through a touch-sensitive screen. However, should the latter be the interface of choice for the proposer, the precise means of activation (interface behavior) must be determined in consultation with the design review team at the post-award design meeting as there are both acceptable and unacceptable interface strategies that could be used. Instrument display information (meaning data content) must be updated at a minimum rate of 30 HZ, whereas display refresh rate is expected to be at least 60 Hz. Display configurations must be able to be modified by an operator without programming skills.

ii. The display suite provided with the initial delivery of the simulator must include an Electronic

Flight Instrumentation System (EFIS) that contains a Primary Flight Display (PFD) that includes but is not limited to attitude, altitude, airspeed, heading, vertical velocity, radio altimeter, and some guidance information (particularly a flight-path marker and localizer and glide-slope error indicators) as well as a Synthetic Vision background, a Multi-function Display (MFD) that provides a moving map and navigational capability (to include the usual route/flight plan entry, recall, manipulation and use functions) as well as the ability to enter navigational and communications radio frequencies (i.e., an integrated nav/comm unit), and power plant instrumentation. These must be consistent with the standards and guidelines contained in the following documents/sources regarding the appearance and functioning of the display systems:

(a) FAA Advisory Circular 23.1311-1C, Installation of Electronic Displays in Part 23 Airplanes, sections 8.0 (Flight Displays), 9.0 (Powerplant displays), 10.0 (Electronic Displays for

Navigation Information), and 13.0, 13.3 (as it relates to GAMA publication No. 10, Design of Cockpit/Flight Deck), 13.5, 17.9 through 17.13, 19.0 (Lag time and data update), 20.0

(controls), and 22.0 (Color standardization).

(b) GAMA Publication No. 12, “Recommended Practices and Guidelines for an Integrated

Flightdeck/Cockpit in a 14CFR Part 23 (or equivalent) Certified Airplane.”

(c) FAA Advanced Avionics Handbook, Chapter 2: Electronic Flight Instruments (provided as a general reference)

(www.faa.gov/regulations_policies/handbooks_manuals/aviation/advanced_avionics_handbo ok/media/aah.ch02.pdf)

(d) RTCA/DO-267A, Minimum Operational Performance Standards for the Depiction of

Navigation Information on Electronic Maps.

(e) RTCA/DO-315A: Minimum Aviation Performance Standards (MASPS) for Enhanced Vision

Systems, Synthetic Vision Systems, Combined Systems, and Enhanced Flight Vision

Systems. (as applicable to synthetic vision background on the PFD)

iii. Numerous examples exist of EFIS systems that meet the basic design standards required for certification, and the electronic instrumentation to be represented in this simulator must be consistent, in terms of appearance and function, with what is being fielded in technically advanced aircraft as of this announcement. Examples of PFD/MFD suites that meet these criteria can be seen in the Garmin G600, G1000, G2000, and G5000 systems, as well as systems manufactured by Avidyne, Honeywell, and Rockwell. The initial display system provided in the simulator must represent this class of electronic displays and provide the same functions as seen in the majority of these systems.

iv. Individual instruments and displays and their layouts must be reconfigurable in real time at any time during system operation. The cockpit displays, simulated switches and display layouts must be stored in a system library and retrieved via menu selection (from the operator’s control station) in order to facilitate reconfiguration of displayed instrumentation. When one of the preprogrammed configurations are selected, all displays must automatically reconfigure for the new display layout.

v. The contractor must supply a dynamic graphical instrument editor software tool to create new or modify existing aircraft instruments, including the action of resizing, moving, replacing instruments or reconfiguring one or more cockpit instrument panels.

4.1 Cockpit Graphics Generator Hardware Capabilities

i. The graphical display(s) must be generated by computers separate from the main simulation host that have their own hard disk drives and storage media which must be used for performing system backups, system loading and simulation instrument design data storage.

4.2 Graphics System Monitor Characteristics

i. The graphical display(s) must be COTS units with a minimum addressable resolution of 1920 by

1080 pixels dependent upon the cockpit configuration used as a base design (small-format displays on a center pedestal may be demonstrated to be acceptable at a lower resolution). The displays must be full color and have anti-aliasing. The displays must have flat, non-glare screens, multi-touch-input capability and adjustable brightness/contrast. The displays must be viewable through 160 degrees (plus and minus 80 degrees from the centerline orthogonal to the display surface) to allow cross-cockpit viewing, and maximum brightness reduction at maximum off-axis viewing must not exceed 20 percent.

ii. Provision must be made for matching the brightness of monitors used for simulation of the instrument panel, if multiple displays are used.

4.3 Transport Delay

i. The processing throughput must never exceed 90 milliseconds (this is a deviation from Level 6, which requires no longer than 150 msec). Throughput is defined as the time to produce the last pixel in the first field of a new display video output, initiated at the time the graphic generator receives an input signal external to the graphics workstation. The instrument displays (content, as stated in 4.0) must be updated at a minimum rate of 30 HZ (33 msec).

4.4 Hardware Driver Requirements

i. The contractor must provide source code for device drivers where possible and sources for obtaining third-party drivers.

4.5 Cockpit Graphics Display Editor Capability, Individual Display

Reconfiguration

i. The purpose of the cockpit graphics display editing capability is to allow the operator to specify the layout and characteristics of instrument displays in the cockpit instrument panel. The contractor must provide a graphics editor software package with a library of graphical displays and display components which allows a variety of cockpit instruments and displays to be created for use in the real-time environment, as listed below. The contractor must specify whether they are providing a COTS graphics editor or writing a custom solution. If a COTS editor is chosen, the contractor must provide the name of the editor to be used.

(a) These displays, at a minimum, must include flight instruments (those presenting values of the required flight-performance indices), power plant/powertrain instruments, navigation displays, and associated avionics control panels (navigation, auto-flight, flight management) as currently seen in technically advanced aircraft.

(b) There must be three levels of reconfigurability as defined below:

(1) Add/move/reshape/replace/delete/re-size and change color of any part of a single display (instrument) on any of the cockpit display surfaces.

(2) Reconfigure the instrument layout of instruments/displays on any one of the cockpit display surfaces.

(3) Move a complete layout contained on one display surface to a different display surface (if multiple display surfaces are used in the layout).

(c) During simulator operation, there must be a single level of reconfigurability with defined instruments that have been developed using the contractor-furnished editor for individually selected indicators on display panels. That is to say, a defined set of instruments/displays must be assignable to whichever display surface is appropriate for a particular study or cockpit configuration.

5.0 Pilot Interface II: Controls

5.1 Dual Manual Flight Controls

i. The pitch, roll, and yaw flight controls must be representative of a typical single- engine piston-driven class aircraft and must be a side-by-side dual control system.

5.1.1 Pitch/Roll Control

i. The flight control that drives the pitch and roll of the aircraft must be representative of that found in this class of airplane. The control can be either a yoke or sidearm system. It must have the following switch activators typical of this aircraft class and representative of the actual aircraft switches:

1. Communication Switch (PTT)

2. Electric Trim control switch

3. Autopilot disconnect switch

4. Control-wheel steering switch (autopilot override)

5.1.2 Rudder Pedal Controls

i. Rudder pedal controls must be typical of this class of aircraft for driving the rudder (yaw) and nose-wheel steering.

5.1.3 Brakes

i. Brakes must be the typical toe-actuated brakes mounted on the rudder pedals of this class of aircraft.

5.1.4 Control Loading / Force Feedback

i. The pitch, roll, and yaw controls must be driven by a force-feedback control loader system. The system requires electric control loaders (not hydraulic) and must represent realistic pressure feedback to all flight controls in all flight configurations of the representative aircraft being simulated. This must include the effects of aerodynamic changes for the various combinations of drag and thrust normally encountered in flight. These correspond to actual flight conditions including the effects of attitude, thrust, drag, altitude, temperature, gross weight, center of gravity location and configuration.

5.2 Automatic Flight Controls

i. Control automation must function appropriately for the Control and Display system selected for the mission of the simulated load.

5.2.1 Autopilot

i. The requirements for this simulator are intended to represent the most advanced technical control system and control-display system of modern aircraft of the single-engine high-performance class. The Automated Flight Control System (AFCS) provides the flight director (FD), autopilot

(AP), and yaw damper (YD) functions of the G1000 system (selected as a baseline exemplar

AFCS). The contractor must provide the above-mentioned functionality either through simulation of the functionality and/or by stimulation of the systems listed above. A list of the systems being simulated and stimulated must be presented by the contractor to the Government’s acquisition team. With their proposal, the contractor must provide a simple system block diagram showing the relationship between the various system modules proposed . The contractor must demonstrate that all flight instrument functionality (primary and supplemental flight data), flight management systems, Automatic Flight Control Systems (AFCS), nav/com functionality, audio panel, engine indication system, crew alerting system, Annunciations/Alerts/Abnormal operations and hazard avoidance systems are operating according to either the G1000 Cessna

Mustang Pilot Guide 0435.11 or reference materials for a newer autopilot system, and must have options for control of heading, navigation track, back course, and altitude. Control of vertical navigation (GS and GPS overlay vertical nav) is also desirable, but may be dependent upon the avionics configuration selected. (See Section 10.0 Ad Hoc.)

5.3 Discrete system controls

5.3.1 Circuit breakers and other discrete controls appropriate to the aircraft configuration

i. Circuit breakers/discrete controls per the aircraft configuration must be included and must be capable of being triggered (“popped”) by the operator either manually or through a programmed flight scenario. By the same token it must also be possible for the operator to reset the underlying failure from the operator’s station and thus restore the simulator to unaffected operation.

6.0 Pilot Interface III: Auditory Information

6.1 Simulated Radio/Intercom Communications

i. An intercommunications system must be included that provides for communication between the operator’s station and the simulator cockpit, and that supports conventional aircraft headsets in the cockpit and at least two headsets at the operator’s station (see Level 6 requirements). This system must provide output that can be connected to an audio/video recording system and must have an input channel into which externally generated audio can be injected. The amplitude of the sound must be adjustable from the operator’s station in real time and it must be possible to isolate the operator’s station audio such that the operator can make comments that go to the output channel (for recording) but that will not be heard through the pilots’ headsets or cockpit speaker. However, the cockpit-source audio must be heard at the operator’s station at all times

(open mic, not controlled by push-to-talk switch) and be recordable.

6.2 Simulated Aircraft and Environmental Sounds

i. The simulator must provide environmental sounds relevant to the operation of the aircraft and those that would be used as feedback by the pilot, including but not limited to spatially relevant engine noise, propeller noise, cockpit warnings and alerts, ground contact sounds, and wind noise (see Level 6 requirements). The amplitude of the sound must be adjustable in real time from the operator's station.

7.0 Pilot Interface IV: Out the Window (OTW) Display System

7.1 Expected Hardware Characteristics of Government-provided Display

System

i. Acceptance testing will be conducted by the government, using a display configuration having six HD LCD projectors that are projecting onto a spherical screen with a 220-degree horizontal by 72 degree vertical view. Means for supporting at least one other OTW displays configuration will be available. This configuration will be determined by the government at a later date.

7.2 Expected Software/Communications Interface Requirements

i. Each IG uses Microsoft Windows Vista or Windows 7 for the operating system, and uses

MetaVR VRSG 5.7.2 for generating the OTW scene. The simulator must communicate the appropriate OTW scene characteristics such as 6 Degree-of-freedom (DoF) positioning, time of day, model data, model and terrain collision, and atmospheric haze and other weather conditions to the IGs. The interface to the Image Generators and MetaVR must use the standard default settings, configurations, and defined protocols for that software. The communication with the

OTW display system must use high-speed Ethernet.

7.3 Expected OTW Software Characteristics

i. The simulator must feature a configuration option that allows the simulator operator to select which OTW display configuration is being used at the time. The simulator must then remain configured to use the selected display configuration until the operator has selected a different

OTW display configuration be used.

8.0 Simulation Database Modeling

8.1 Aircraft systems to be modeled

i. The simulator software must include Level 6 representations of the following systems: flight controls, power plant, drive trains, fuel distribution, electrical distribution (and lighting), navigation, communications, ambient environment, hydraulics.

8.2 Navigational database

i. The contractor must provide a simulator software database which includes an accurate and complete navigation facilities database for the 48 contiguous United States and must provide the ability for an operator without programming skills to edit routines to change or add to the navigation database. In this case “navigation facilities database” is meant to imply, at a minimum, all VOR and VOR/TAC facilities and ILS approaches at major airports and significant

General Aviation airports.

8.3 Aero model database

i. An aero model must be included that is consistent with the requirements of a Level 6 Flight

Training Device (FTD) and represents the model/class of aircraft selected. As a minimum, the aerodynamic model must provide specific assigned variables for the aerodynamic elements critical to flight that can be edited to provide realistic aerodynamic models for various models of

ii. The Contractor must provide the Government with the capability to load and use other aero models.

iii. This must use an interactive database that includes a defined set of variables to define an aircraft's performance for FAA test purposes, with an editing capability that would allow alternate aero models to be loaded into the system and used in place of the basic supplied aero model.

9.0 Operator Interface: Displays and Control Functions

9.1 Experimenter/Operator Station (EOS) Displays

i. The Experimenter/Operator Station (see Level 6 requirements) must provide display capability to include the following:

(a) Display of flight scenario data. The operator must be able to view information, at the top level of any menu structure or as tabs, pertaining to the current conditions associated with the loaded scenario. This must include but is not limited to weather settings, data variables being collected and related information, pseudo vehicle settings where these are trigger activated, and triggers associated with the categories of variables. Triggered events must be displayed to the operator, on the operator’s station displays, when they occur so that their occurrence can be verified.

(b) Display of real-time performance data. The operator must be able to view a plan-view map

(north up) which displays the position of the simulated aircraft, an intended route if programmed, and pseudo-vehicle positions and their intended routes. Whether the map is in the form of an electronic sectional chart or other map format, airports, navigation facilities, terrain, obstructions, and airspaces must be represented. A side (flight profile) view must be presented to represent position along an approach mapped against altitude (and glideslope).

(c) Additionally, the system must allow the operator to view, in real time, the values of selected variables present in the simulation system for continuous display (digital at a minimum, strip-chart, e.g. value by time, preferred as second option). These must be accessible by a tab on the main page and not require the use of an auxiliary utility program. The operator must also have a repeater display of the main instrument panel to monitor what indications are being viewed by the simulator pilot, and room must be provided at the operator’s station for a display to depict a replica of the forward out-the-window view as seen from the simulator.

9.2 Hardware considerations for the EOS

i. Proposed displays must be capable of being PC driven.

ii. Proposed displays must be full color.

iii. Proposed displays must present/repeat all computer-generated head-down displays depicted in the simulator cockpit.

iv. Proposed display resolution must match or exceed that of the cockpit displays being repeated.

v. Proposed displays must be viewable full-time and simultaneously. Switching a single display between different inputs via a KVM, or some other means, is NOT acceptable.

vi. Off-axis brightness of proposed displays must be no less than 75% of that on the viewing centerline.

vii. Proposed displays must be viewable through 160 degrees (plus or minus 80 degrees from the display viewing centerline orthogonal to the display surface). The intent is to allow easy viewing of displays from neighboring workstations.

viii. Proposed displays must be adjustable for a down angle of at least 15 degrees, but placement in an “overhead” position should be avoided by the proposed layout.

ix. Proposed displays must not lose more than 20% of their initial brightness over their expected useable life.

x. Proposed displays must be adjustable left and right at least 30 degrees for viewing from the main operator’s position for the case of one operator present.

xi. Proposed displays must have front- or side-mounted power switches.

xii. Proposed displays must have individual brightness and contrast controls.

9.3 EOS Control Functions

9.3.1 Control of all aircraft system functions

i. The EOS must provide for control of all aircraft system functions (e.g. electrical, hydraulic) both on the ground and in-flight for both normal and emergency situations.

9.3.2 Control of all meteorological conditions

i. The EOS must provide for control of all meteorological conditions including visibility, cloud cover/layers (layer thickness and top and bottom by feet MSL, percentage of coverage, visibility within layer), day/night/dusk conditions (if supported by MetaVR) within the context of both programmed scenarios and real-time manipulation through the operator’s station.

9.3.3 Control of audio levels/ cockpit isolation

i. The EOS must provide control of output levels for all audio sources. Separate control is required for engine, propeller, wind and other ambient cockpit noise as well as auditory warnings and the voice intercom system. It must also be possible to isolate the cockpit so that operators at the EOS may converse without being heard in the cockpit (as mentioned in section 6.1).

9.3.4 Control of ambient lighting

i. The EOS must provide control of ambient lighting (daylight effect) in the cockpit.

9.3.5 Control of Cockpit Lighting Systems

i. Lighting systems in the cockpit, such as map and instrument lights, etc., must be able to be controlled both for on/off and for brightness.

9.4 EOS Scenario Editing Functions

i. Scenario editing must use a graphical-user interface (GUI) to create and store flight scenarios for future and repeated use. This capability must not require computer programming knowledge by the user. Scenarios so edited must be backed up such that a file is retained outside of the primary scenario listing folder, representing the file prior to the most recent edits. The scenario-editing function must be integrated with other functions within a console/workstation. Scenario development must support the creation and editing of scenarios up to 4 hours in length.

ii. The list of available scenarios must be automatically populated as each edited scenario is saved. A delete function must be provided in the GUI so that files no longer desired in the primary list (pull-down menu or the like) of active scenarios may either be (1) deleted altogether or (2) sent to a back-up directory for long-term storage. This must not require the user to enter the operating system to accomplish these ends, and must provide safeguards against accidental deletion in the procedure the GUI uses (ask to verify that the user wishes to delete a file).

iii. The following are specific functions/features that must be incorporated into the scenario editor:

9.4.1 Ownship and PseudoVehicles/Objects

i. For each scenario, the origin and destination airports for the ownship must be selectable.

The scenario designer must be able to designate intermediate waypoints in the flight plan.

ii. A minimum of 6 pseudo-aircraft, vehicles, or other moving objects must be selectable for inclusion in a scenario capable of using sufficient waypoints to model the pseudo-aircraft flight paths. These pseudo-aircraft must be representative of the type of aircraft that a general aviation pilot might be expected to encounter and have, in previous applications, included various single-engine GA aircraft, commuter turbojet aircraft, military transport aircraft, and helicopters. Particular scenario flight paths for movable objects, vehicles and pseudo-aircraft must be stored, retrieved, and invoked by name or number.

iii. The scenario editor must provide the ability to preview pseudo-aircraft flight paths, and paths of other moving objects and vehicles.

iv. Movable objects, vehicles, or pseudo-aircraft added to the scenario must be controllable either by time, position of the subject aircraft, a scripted event such as an aircraft flying into the path of the simulator, or controlled from the Pseudo-Pilot Workstation.

v. Pseudo-aircraft and other movable objects must be able to be assigned selectable attributes such as speed, direction and path of movement, and start/stop times. Response and appearance of the pseudo vehicle must be represented so that its performance (speed, attitude, ascent/descent rate, etc.) appears, to the simulator pilot viewing it in the out-the-widow environment, to behave as one would expect that type of aircraft or vehicle to behave.

vi. All vehicles in the scenario, including Ownship, must be positioned by two means; (a) drag-and-drop positioning on the displayed map and (b) specification of latitude and longitude of desired starting position. Movement of objects on the display when positioning must use the convention of the object moving over a fixed map. When an object is dragged to the edge of the displayed map area, the map must slew under the object being moved to continue to display the movement of the object over the map.

Functions like map zoom must be controlled by visible buttons on the display and not by calling hidden menus or controls through the use of keystrokes. The interface must, when placing ownship and pseudo vehicles, provide an immediate view, in the OTW scene, of the forward view from that aircraft or vehicle as it is placed. This allows the scenario builder to immediately verify that placement is correct. This is particularly important when there is less than perfect correspondence between the map, at the EOS, upon which the vehicle is being placed and the position as registered in the OTW view.

vii. The operator must be able to specify whether navigation or landing lights are on or off for particular pseudo-aircraft, as well as acceleration, deceleration, climb and descent profiles for the aircraft.

9.4.2 Weather Effects

i. The operator station system must provide the capability of adding a full range of weather effects either during scenario development (preprogrammed) or anytime during the simulation at the operator’s discretion. This must include effects encountered both on the ground (runway conditions, ground visibility) and in flight (wind, temperature, visibility, cloud layers, precipitation). These settings must invoke the appropriate changes in aircraft performance, and must also be transmitted from the simulation system to the computers driving the MetaVR out-the-window visuals to produce the necessary visual effects where appropriate (cloud layers, visibility, day/night).

9.4.3 Malfunctions

i. The scenario development function must support conditional malfunctions occurring to the simulated aircraft (programmed/triggered non-routine events). These must include faults or failures most commonly associated with the class of aircraft being simulated, and the faults must be able to be easily inserted either in real time during operation or as a part of the programmed scenario files, with provision, as mentioned elsewhere, to clear and reset faults and restore normal system operation.

9.4.4 Scenario Management Functions

i. After completion and previewing of a scenario control file, the system must allow the operator to load the scenario into a file that can be run on the simulator. The system must allow the operator to print out a representation of a scenario file. This must be a text listing of the variables and their values in the scenario file must be clearly labeled/identified.

ii. The scenario development function must allow the display and printout of a map showing stored pseudo-aircraft paths. One means of accomplishing this might be by a screen print of the operator’s workstation display when the pseudo vehicle paths are visible.

9.5 Event Marker

i. It must be possible to insert into the digital data stream, at the operator’s station during real-time operation, an event mark so that the occurrence of an event can be associated with a particular point in the flight. This event mark must be linked to the elapsed time for that simulator run and would be an index normally recorded with the minimum required dataset. Event marks must be unique and separately identifiable. An example of this would be incrementing the event/index mark (an integer number) by one upon each subsequent use.

9.6 Data Collection/Storage Capability and Procedures/Safeguards

9.6.1 Variable-rate/frequency data collection

i. The scenario editor must provide the capability to define, for at least two user-defined sets of variables, separate and different data-collection rates that are either selected from a list of available rates (to be defined by the user and provider in advance) or entered as a variable by the user in the scenario editor. This is necessary to be able to (1) support evaluations at both extremes of the sampling-rate continuum represented by (a) control-manipulation studies requiring high sampling rates and (b) aircraft-position monitoring requiring comparatively low sampling rates, and (2) to effectively manage the size of the resulting data files. A master file must be created and saved that represents all of the performance variables of interest plus those sufficient to allow for a replay of the recorded flight. One means of accomplishing variations in sampling rate into a data file to be used for analysis would be to resample the master data file after the fact to create files of lesser temporal resolution to be downloaded and analyzed/stored elsewhere.

9.6.2 Data collection onset/offset control (programmable and manual)

i. Data collection must be enabled by reference to programmable triggers that can be combined to define under what conditions data collection begins and under what conditions it stops. For example, the operator must be able to set up a trigger to start data collection by specifying that selected variables, e.g. latitude, longitude, altitude, elapsed time, must be greater than or equal to specified values. Comparably, data collection must continue until a second set of conditions/values specified for data-collection termination, are satisfied, and not automatically cease when the onset conditions are no longer met. A button to halt recording must be made available at the operator’s station that halts the data recording, regardless of whether the desired conditions have been met, and allow the operator to save the data. This allows the operator to have maximal control over when to start data collection, as well as when and under what conditions data collection ends.

9.6.3 Data variable list selection for recording

i. Data variables to be collected and stored must be selectable from a master list of simulator variables which exists independently of any specific created flight scenario/profile.