Pt. 60, App. C

14 CFR Ch. I (1-1-19 Edition)

BEGIN INFORMATION
lllllllllllllllllllllll
13. [RESERVED]
14. ACCEPTANCE GUIDELINES FOR ALTERNATIVE
AVIONICS (FLIGHT-RELATED COMPUTERS AND
CONTROLLERS)
a. Background
(1) For a new helicopter type, the majority
of flight validation data are collected on the
first helicopter configuration with a  - baseline -  flight-related avionics ship-set; (see
subparagraph b.(2) of this section). These
data are then used to validate all flight simulators representing that helicopter type.
(2) Additional validation data may be needed for flight simulators representing a helicopter with avionics of a different hardware
design than the baseline, or a different software revision than that of previously validated configurations.
(3) When a flight simulator with additional
or alternate avionics configurations is to be
qualified, the QTG should contain tests
against validation data for selected cases
where avionics differences are expected to be
significant.

kpayne on VMOFRWIN702 with $$_JOB

b. Approval Guidelines For Validating
Alternate Avionics
(1) The following guidelines apply to flight
simulators representing helicopters with a
revised avionics configuration, or more than
one avionics configuration.
(2) The baseline validation data should be
based on flight test data, except where other
data are specifically allowed (e.g., engineering flight simulator data).
(3) The helicopter avionics can be segmented into two groups, systems or components whose functional behavior contributes
to the aircraft response presented in the
QTG results, and systems that do not. The
following avionics are examples of contributory systems for which hardware design
changes or software revisions may lead to
significant differences in the aircraft response relative to the baseline avionics configuration: Flight control computers and
controllers for engines, autopilot, braking
system, and nosewheel steering system, if
applicable. Related avionics such as augmentation systems should also be considered.
(4) The acceptability of validation data
used in the QTG for an alternative avionics
fit should be determined as follows:
(a) For changes to an avionics system or
component that do not affect QTG validation
test response, the QTG test can be based on
validation data from the previously validated avionics configuration.
(b) For an avionics change to a contributory system, where a specific test is not af-

fected by the change (e.g., the avionics
change is a Built In Test Equipment (BITE)
update or a modification in a different flight
phase), the QTG test can be based on validation data from the previously-validated avionics configuration. The QTG should include
authoritative justification (e.g., from the
helicopter manufacturer or system supplier)
that this avionics change does not affect the
test.
(c) For an avionics change to a contributory system, the QTG may be based on validation data from the previously-validated
avionics
configuration
if
no
new
functionality is added and the impact of the
avionics change on the helicopter response is
based on acceptable aeronautical principles
with proven success history and valid outcomes. This should be supplemented with
avionics-specific validation data from the
helicopter manufacturer-s engineering simulation, generated with the revised avionics
configuration. The QTG should include an
explanation of the nature of the change and
its effect on the helicopter response.
(d) For an avionics change to a contributory system that significantly affects some
tests in the QTG, or where new functionality
is added, the QTG should be based on validation data from the previously validated avionics configuration and supplemental avionics-specific flight test data sufficient to
validate the alternate avionics revision. Additional flight test validation data may not
be needed if the avionics changes were certified without the need for testing with a
comprehensive flight instrumentation package. The helicopter manufacturer should coordinate flight simulator data requirements
in advance with the NSPM.
(5) A matrix or  - roadmap -  should be provided with the QTG indicating the appropriate validation data source for each test.
The roadmap should include identification of
the revision state of those contributory avionics systems that could affect specific test
responses.
15. TRANSPORT DELAY TESTING
a. This paragraph describes how to determine the introduced transport delay through
the flight simulator system so that it does
not exceed a specific time delay. The transport delay should be measured from control
inputs through the interface, through each
of the host computer modules and back
through the interface to motion, flight instrument, and visual systems. The transport
delay should not exceed the maximum allowable interval.
b. Four specific examples of transport
delay are:
(1) Simulation of classic non-computer
controlled aircraft;
(2) Simulation of Computer Controlled Aircraft using real helicopter black boxes;

376

VerDate Sep<11>2014

16:30 Jun 25, 2019

Jkt 247047

PO 00000

Frm 00386

Fmt 8010

Sfmt 8002

Q:\14\14V2.TXT

PC31