376 

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

Pt. 60, App. C 

B

EGIN

I

NFORMATION

 

lllllllllllllllllllllll

13. [R

ESERVED

] 

14. A

CCEPTANCE

G

UIDELINES FOR

A

LTERNATIVE

 

A

VIONICS

(F

LIGHT

-R

ELATED

C

OMPUTERS AND

 

C

ONTROLLERS

) 

a. Background 

(1) For a new helicopter type, the majority 

of flight validation data are collected on the 
first helicopter configuration with a ‘‘base-
line’’ flight-related avionics ship-set; (see 
subparagraph b.(2) of this section). These 
data are then used to validate all flight sim-
ulators representing that helicopter type. 

(2) Additional validation data may be need-

ed for flight simulators representing a heli-
copter with avionics of a different hardware 
design than the baseline, or a different soft-
ware revision than that of previously vali-
dated 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. 

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., engineer-
ing flight simulator data). 

(3) The helicopter avionics can be seg-

mented into two groups, systems or compo-
nents whose functional behavior contributes 
to the aircraft response presented in the 
QTG results, and systems that do not. The 
following avionics are examples of contribu-
tory systems for which hardware design 
changes or software revisions may lead to 
significant differences in the aircraft re-
sponse relative to the baseline avionics con-
figuration: Flight control computers and 
controllers for engines, autopilot, braking 
system, and nosewheel steering system, if 
applicable. Related avionics such as aug-
mentation systems should also be consid-
ered. 

(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 vali-
dated avionics configuration. 

(b) For an avionics change to a contribu-

tory 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 valida-
tion data from the previously-validated avi-
onics 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 contribu-

tory system, the QTG may be based on vali-
dation 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 out-
comes. This should be supplemented with 
avionics-specific validation data from the 
helicopter manufacturer’s engineering sim-
ulation, 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 contribu-

tory system that significantly affects some 
tests in the QTG, or where new functionality 
is added, the QTG should be based on valida-
tion data from the previously validated avi-
onics configuration and supplemental avi-
onics-specific flight test data sufficient to 
validate the alternate avionics revision. Ad-
ditional flight test validation data may not 
be needed if the avionics changes were cer-
tified without the need for testing with a 
comprehensive flight instrumentation pack-
age. The helicopter manufacturer should co-
ordinate flight simulator data requirements 
in advance with the NSPM. 

(5) A matrix or ‘‘roadmap’’ should be pro-

vided with the QTG indicating the appro-
priate validation data source for each test. 
The roadmap should include identification of 
the revision state of those contributory avi-
onics systems that could affect specific test 
responses. 

15. T

RANSPORT

D

ELAY

T

ESTING

 

a. This paragraph describes how to deter-

mine the introduced transport delay through 
the flight simulator system so that it does 
not exceed a specific time delay. The trans-
port 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 in-
strument, and visual systems. The transport 
delay should not exceed the maximum allow-
able interval. 

b. Four specific examples of transport 

delay are: 

(1) Simulation of classic non-computer 

controlled aircraft; 

(2) Simulation of Computer Controlled Air-

craft using real helicopter black boxes; 

VerDate Sep<11>2014 

16:30 Jun 25, 2019

Jkt 247047

PO 00000

Frm 00386

Fmt 8010

Sfmt 8002

Q:\14\14V2.TXT

PC31

kpayne on VMOFRWIN702 with $$_JOB