Attachment 3 - TAGARS Table of Musts.pdf

TECHNICALLY ADVANCED GENERAL AVIATION RESEARCH

SIMULATOR (TAGARS)

FEDERAL AVIATION ADMINISTRATION

CIVIL AREOSPACE MEDICAL INSTITUTE

HUMAN FACTORS RESEARCH DIVISION

(AAM-500)

STATEMENT OF WORK

Table of “musts”

Sect ion

Parag raph

Pa ge

“Must” Statement

1.3.

ii. 7 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.

1.3.

iii. 7 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.

i. 7 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.

1.3.

i. 8 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.

1.3.

ii. 8-

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 i. 9 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.1 i. 9 The contractor solution must consist of 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 i. 9 Contractor must supply a software configuration plan for all software development modules.

2.2.

i. 9 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).

2.2.

i. 9 The software packages must include routines to easily edit, compile, catalog and link software modules, and to add new modules if needed.

2.2.

i. 9 All software provided must remain government property and must not be available to third parties except in direct support of FAA contract work.

2.2.

i. 10 Graphics editing software must support easy creation, editing, and integration of graphics into cockpit displays by a minimally trained user.

2.2.

i. 10 Graphics created must be executable under Windows or Linux and linked to variables broadcast from the main simulation computer.

https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages https://spectrum.ieee.org/computing/software/the-2017-top-programming-languages

2.2.

i. 10 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.

2.2.

i. 10 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.

i. 10 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).

2.2.

i. 10 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).

3.0 i. 10 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.

3.0 ii. 10 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.

3.1 i. 11 Maximum cockpit size must be no larger than:

7 feet long

5 feet wide

5.5 feet tall

3.2 i. 11 Cockpit seats must be:

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

4.0 i. 11 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).

4.0 i. 11 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.

4.0 i. 11 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.

4.0 i. 11 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.

4.0 i. 11 Display configurations must be able to be modified by an operator without programming skills.

4.0 ii. 11

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.

4.0 ii. 12 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/ad vanced_avionics_handbook/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)

4.0 iii. 12 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.

4.0 iii. 12 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.

4.0 iv. 12 Individual instruments and displays and their layouts must be reconfigurable in real time at any time during system operation.

4.0 iv. 12 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.

4.0 iv. 12 When one of the preprogrammed configurations are selected, all displays must automatically reconfigure for the new display layout.

4.0 v. 12 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 i. 13 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 i. 13 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).

4.2 i. 13 The displays must be full color and have anti-aliasing.

4.2 i. 13 The displays must have flat, non-glare screens, multi-touch-input capability and adjustable brightness/contrast.

4.2 i. 13 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.

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

4.3 i. 13 The processing throughput must never exceed 90 milliseconds (this is a deviation from Level 6, which requires no longer than 150 msec).

4.3 i. 13 The instrument displays (content, as stated in 4.0) must be updated at a minimum rate of 30 HZ (33 msec).

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

4.5 i. 13

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.1 i. 14 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.

i. 14 The flight control that drives the pitch and roll of the aircraft must be representative of that found in this class of airplane.

5.1.

i. 14 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.

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

5.1.

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

5.1.

i. 15 The pitch, roll, and yaw controls must be driven by a force-feedback control loader system.

5.1.

i. 15 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 includes 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 i. 15 Control automation must function appropriately for the Control and Display system selected for the mission of the simulated load.

5.2.

i. 15 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.

5.2.

i. 15 A list of the systems being simulated and stimulated must be presented by the contractor to the Government’s acquisition team.

5.2.

i. 15 With their proposal, the contractor must provide a simple system block diagram showing the relationship between the various system modules proposed

5.2.

i. 15

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.

5.3.

i. 16 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.

5.3.

i. 16 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.1 i. 16 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).

6.1 i. 16 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.

6.1 i. 16 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 headset or cockpit speaker.

6.1 i. 16 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 i. 16

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).

6.2 i. 17 The amplitude of the sound must be adjustable in real time from the operator's station.

7.2 i. 17 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.

7.2 i. 17 The interface to the Image Generators and MetaVR must use the standard default settings, configurations, and defined protocols for that software.

7.3 i. 17 The communication with the OTW display system must use high-speed Ethernet.

7.3 i. 17 The simulator must feature a configuration option that allows the simulator operator to select which OTW display configuration is being used at the time.

7.3 i. 17 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.1 i. 18 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 i. 18 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 i. 18 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.

8.3 i. 18 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 aircraft.

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

8.3 iii. 18 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.1 i. 18

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. This can be done in the form of an electronic sectional chart so that airports, navigation facilities, terrain, obstructions, and airspaces are also 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 i. 19 Proposed displays must be capable of being PC driven

9.2 ii. 19 Proposed displays must be full color.

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

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

9.2 v. 19 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

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

9.2 vii. 19 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.

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

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

9.2 x. 19 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.

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

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

9.3.

i. 20 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.

i. 20 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.

i. 20 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.

9.3.

i. 20 It must also be possible to isolate the cockpit so that operators at the EOS may converse without being heard in the cockpit.

9.3.

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

9.3.

i. 20 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 i. 20 Scenario editing must use a graphical-user interface (GUI) to create and store flight scenarios for future and repeated use.

9.4 i. 20 This capability must not require computer programming knowledge by the user.

9.4 i. 20 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.

9.4 i. 20 The scenario-editing function must be integrated with other functions within a console/workstation.

9.4 i. 20 Scenario development must support the creation and editing of scenarios up to 4 hours in length.

9.4 ii. 20 The list of available scenarios must be automatically populated as each edited scenario is saved.

9.4 ii. 20

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.

9.4 ii. 21 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).

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

9.4.

i. 21 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.

9.4.

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

9.4.

ii. 21 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.

9.4.

ii. 21 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.

9.4.

ii. 21 Particular scenario flight paths for movable objects, vehicles and pseudo-aircraft must be stored, retrieved, and invoked by name or number.

9.4.

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

9.4.

iv. 21 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.

9.4.

v. 21 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.

9.4.

v. 21 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.

9.4.

vi. 21 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.

9.4.

vi. 21 Movement of objects on the display when positioning must use the convention of the object moving over a fixed map.

9.4.

vi. 21 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.

9.4.

vi. 21 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.

9.4.

vii. 22 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.

i. 22 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.

9.4.

i. 22 This must include effects encountered both on the ground (runway conditions, ground visibility) and in flight (wind, temperature, visibility, cloud layers, precipitation).

9.4.

i. 22 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.

i. 22 The scenario development function must support conditional malfunctions occurring to the simulated aircraft (programmed/triggered non-routine events).

9.4.

i. 22 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.

i. 22 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.

9.4.

i. 22 The system must allow the operator to print out a representation of a scenario file.

9.4.

i. 22 This must be a text listing of the variables and their values in the scenario file must be clearly labeled/identified.

9.4.

ii. 22 The scenario development function must allow the display and printout of a map showing stored pseudo-aircraft paths.

9.5 i. 22 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.

9.5 i. 22

This event mark must be linked to the elapsed time for that simulator run and would ideally be an index normally recorded with the minimum required dataset.

9.5 i. 23 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.

i. 23 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.

9.6.

i. 23 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.

9.6.

i. 24 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.

9.6.

i. 24 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.

9.6.

i. 24 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.

9.6.

i. 24 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.

9.6.

i. 24 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.

9.6.

i. 24 Variables in the listing must be grouped by logical categories and listed alphabetically within each logical category.

9.6.

i. 24 A base set of variables that will always be recorded must be established; for example, 6 DoF variables defining aircraft position and orientation in space along with the required elapsed-time stamp for each sample.

9.6.

i. 24 The list of data variables selected for any particular scenario must be stored with that scenario so that different scenarios can be saved that have different data lists and different data-collection rates.

9.6.

i. 24 The data recorded must, in cases where the variables are on displays in the cockpit, be in the same units as those seen by the pilot on cockpit displays (i.e., altitude in feet, airspeed in knots, etc.) and must be consistent with the units used in aviation reporting systems.

9.6.

i. 24 Data files must be stored as comma-delimited-variable (CSV) text files.

9.6.

i. 24 If writing data to CSV text format produces a performance deficit, data files can be stored in alternative binary or hexadecimal data file format so long as a means by which data files can be converted to CSV text is provided. Any converter that is needed must support batch processing to allow multiple files to be converted to CSV.

9.6.

i. 24 All data files must include a header that lists the scenario name, time and date of the data recording.

9.6.

i. 24 The data must be written such that when opened in the aforementioned spreadsheet software it must be organized in columns.

9.6.

i. 24 There must also be a header row that lists the names of each of the variables that were recorded.

9.6.

i. 25 Data must be saved to a “back-up” file at the termination of a simulator trial/run regardless of whether the data is to be permanently saved by the operator.

9.6.

i. 25 Data recording of the variables associated with the loaded scenario must always be “on.”

9.6.

i. 25 The software must be configured to present a dialog box at trial termination to ask the operator if the data must be saved permanently.

9.6.

i. 25 Clicking on the “yes” option must then provide an input box that asks for a file name.

9.6.

i. 25 The folder into which this file is placed must be set in advance so that the entire path does not need to be typed in each time.

9.6.

i. 25 The folder location must be specifiable for the scenario in the scenario editor.

9.6.

i. 25 The audio/video recording system must be included and must be capable of supporting digital removable media, and be capable of having or generating a storage format that can be replayed on other generally available video or computer devices.

9.6.

i. 25 The system must be capable of recording multiple sources of video and audio including the cockpit, cockpit displays, and selected IG displays in a multi-IG system.

9.6.

i. 25 It must also be capable of recording audio and video for no less than four cameras located in and/or around the cockpit.

9.6.

i. 25 Playback/review of the recordings must be supported off system, which is to say that although the recording system associated with the simulator may be able to replay the captured video/audio records, they should also be transferrable to transportable digital media for playback on a desk-top or laptop computer (using commercially available video playback software intended for use on personal computers).

9.7.

i. 25

The operator must be able to load a recorded flight into the simulation and replay that flight in either real time or at an accelerated rate, with the appropriate start, stop, and pause controls to allow the stored flight to be examined in detail.

9.7.

i. 26 All events that occur as a result of triggers in the original scenario must be recreated during the replay of a recorded flight. This includes changes in weather and the appearance and movement of pseudo vehicles.

9.7.

i. 26 The operator must have the ability to replay a flight to a specific point, freeze the flight, engage data collection, and begin a new data-collection session from that point in the flight, which must be saved to a new data file.

9.7.

i. 26 The operator must have control over the expected simulator-run functions of starting, stopping, or freezing the simulator during a run.

9.7.

i. 26 The scenario editor must have the ability to set the date and time of day of the scenario. As a minimum, all features of MetaVR VRSG under the Graphics and Environment tabs need to be supported in full, and manipulated from the operator’s station by a user without programming skills.

9.7.

i. 26 The scenario editor must allow changes in weather to be triggered based upon a condition being met (using the same logic and variable options from data recording). Setting of cloud layer altitudes, heights, and cloud type is also required.

9.7.

i. 26 The operator must be able to define a scenario that allows the aircraft to begin a flight scenario from an airborne location with all operational parameters set for flight. That is to say, an in-flight start requires that power plant and flight-performance variables must be populated with appropriate values so that the aircraft can successfully start as if in flight.

9.8.

i. 27 The pseudo-pilot function must be software that enables the control of vehicles, both air and ground, that are external to the simulated aircraft and are operating in the same simulated space.

9.8.

i. 27 The pseudo-pilot function must be operable in two different modes, as described below.

(a) The first includes the use of preprogrammed traffic that follows a set route. In this instance, the pseudo vehicle must be started by a trigger in the scenario editor.

(b) The second mode of operation must include a human operator manipulating the direction and altitude of the pseudo vehicle via keyboard, mouse, and joystick controls.

9.8.

ii. 27 Regardless as to whether the vehicle is manually operated by a human operator or maneuvering according to a programmed path, any situation in which the pseudo vehicle would become visible to the pilot in the simulator cockpit must result in an appropriate vehicle model being visible in the out-the-window display.

9.8.

i. 27 An air-traffic-control (ATC) function separate from the operator’s station is required for this acquisition. This function must provide a map that shows, in their current positions, ownship, pseudo vehicles, airports, navigation facilities, and other relevant data that can be selected by the operator acting as the air traffic controller (intent is to allow decluttering by selecting only displayed items that are necessary beyond the underlying map and vehicle positions).

9.8.

i. 27 The ATC function must allow the storage of text representing ATC calls to the aircraft that can be triggered at the appropriate times using triggers described earlier in this document.

9.8.

i. 27 The design must allow .wav files containing the ATC verbal messages to be stored and called up/played at trigger points along with the text showing what is being said in the .wav file audio. This is also seen as a separate and independent function from the main operator’s function.

9.8.

i. 27 These functions must be (1) displayed on a separate display unit when someone other than the main operator is performing either of the other described functions or (2) shown on the main operator’s display when only one operator is required to monitor/control all functions.

11.1 i. 28 A list of COTS spare parts that are likely to be needed during the operational lifetime of the simulator must be provided as a deliverable. The list must identify the part in detail and provide (1) a description, (2) location in the simulator, (3) a part number (where possible), and (4) a possible source for obtaining that part.

If there are any non-COTS parts that are likely to be needed, they must be identified in a separate section of the parts list and clearly identified as custom parts.

11.2 i. 28 Maintenance analysis must be performed for the simulator, in accordance with the laboratory’s maintenance concept, to identify commercially available tools and test equipment required to maintain both Contractor and other contractor-designed equipment used in the simulator. These requirements must be collected and submitted to the AHFRD by the Contractor in the form of a Recommended List of Commercially Available Tools and Test Equipment

11.2 ii. 28 A list must be provided of any special tools and test equipment that are not available as off-the-shelf contractor equipment but would be necessary for the laboratory to conduct normal simulator maintenance. Specific needs for this equipment are to be justified in the listing along with test specifications associated with each special tool.

11.3 i. 28 The contractor must supply, in English, the documentation to enable CAMI AHFRD personnel to operate, maintain and update the simulator. All technical documentation is to meet best commercial standards.

11.3 i. 28

The following documentation, including contractor supplied manuals, must be provided with the simulator in three copies:

(a) Index of deliverable documentation

(b) Hardware manuals comprising the following:

(1) Guide to hardware documentation that describes the hardware structure to maintenance personnel.

(2) Operating-procedures manual that serves as reference for effective use of the operator console functions.

(3) Maintenance technician operating procedures manual that provides the maintenance technician with prestart checks, start-up procedures, running checks, emergency procedures, shutdown procedures and shutdown checks.

(4) System maintenance manuals that provide first-level maintenance (board replacement).

(5) Test equipment manuals that describe the use of all furnished test equipment.

(c) Engineering support data that are produced in accordance with the Contractor's standard practice and comprise the following:

(1) Drawings that list principal components of the simulator system.

(2) System schematics illustrating the functional operation of the system.

(3) Printed circuit board and power supply unit schematics.

(4) Mechanical assemblies showing component layout and parts list.

(5) Complete wiring list.

(6) Cable assemblies showing how they are assembled,

(7) Procurement specification control document that specifies purchased contractor items.

(8) Performance specifications for maintenance information on Contractor furnished plug-in modules.

(9) Printed circuit board and load unit test specifications.

(10) Copies of documentation necessary for maintenance of system schematics, unit schematics, mechanical assemblies, and cable assemblies.

(d) Contractor-furnished documentation consisting of standard commercial off-the-shelf documentation produced by suppliers of purchased equipment used in the simulator.

(e) Parts catalog for Contractor listing, list of assemblies, index and group assembly parts list.

(f) Software documentation must comprise the following:

(1) Contractor-supplied software that comprises contractor diagnostics and operating systems.

(2) Contractor device driver software comprising the device driver software supplied by the Contractor. It must be supplied in executable form, source and object code.

(3) Contractor standard utilities software comprising the Contractor-generated standard utilities for configuring and controlling the simulator software. They must be supplied in executable form, source, and object code.

(4) Simulation software that simulates specific aircraft systems, and all software developed specifically under this contract must be supplied in executable form, source and object code.

(5) Software manuals that include a programmer's guide that describes the procedures for using the host utilities and a simulation software package that includes a software-design document for each module and program listings.

11.3 ii. 30 Software (digital) copies on a storage medium separate from the flight-simulator system must be provided for all simulator software source code and operating procedures. User's instructions must be provided for all edit routines separately and clearly identified as applicable. Quick-reference instructions must be provided for all loading, operating, editing and running procedures; these instructions must be delivered at the time the equipment is delivered.