Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

SAE TECHNICAL
PAPER SERIES

Testing of the V-22 Flight Control System

Walter L. Ballauer, John R. Leet, James Mitchell, and David R. Eck

Boeing Helicopters
Philadelphia, PA

The Engineeting Society

=For Advancing Mobility 1991 SAE Aerospace Atlantic
-Land Sea ~ iand
r spacem Dayton, Ohio
April 22-26,1991

4 0 0 C O M M O N W E A L T H D R I V E , W A R R E N D A L E , P A 1 5 0 9 6 - 0 0 0 1 U.S.A.
Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

The appearance of the lSSN code at the bottom of this page indicates SAE's consent
that copies of the paper may be made for personal or internal use of specific clients.
This consent is given on the condition, however,that the copier pay a$5.00 per article
copy fee through the Copyright Clearance Center, Inc. Operations Center, 27
Congress St., Salem, MA 01 970 for copying beyond that permitted by Sections 107
or 108 of the U.S. Copyright Law. This consent does not extend to other kinds of
copying such as copying for general distribution, for advertising or promotional
purposes, for creating new collective works, or for resale.

SAE routinely stocks printed papers for a period of three years following date of
publication. Direct your orders to SAE Customer Service Department.

To obtain quantity reprint rates, permission to reprint a technical paper or permission

to use copyrighted SAE publications in other works, contact the SAE Publications
Group.

All SAE p p e r r . standards and se1Bcf.m

books are abrlracfea and #ndsrealn me
SAE Global Mmlrlv Database

No part of this publication may by reproduced in any form, irl an electronic retrieval
system or otherwise, without the prior written permission of the publisher.

ISSN 0148-71 91
Copyright 1991 Society of Automotive Engineers, Inc.

Positions and opinions advanced in this paper are those of the author(s) and not
necessarily those of SAE. The author is solely responsible for the content of the
paper. A process is available by which discussions will be printed with the paper if
it is published in SAE transactions. For permission to publish this paper in full or in
part, contact the SAE Publications Division.

Persons wishing to submit papers to be considered for presentation or publication

through SAE should send the manuscript or a 300 word abstract of a proposed
manuscript to: Secretary, Engineering Activity Board, SAE.

Printed in USA
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021
Testing of the V-22 Flight Control System
Walter L. Ballauer, John R. Leet, James Mitchell, and David R. Eck
ABSTRACT
The V-22 Fly-By-Wire Digital Flight Control Sys-
tem is arguably the most complex yet attempted. In
addition t o providing control of the aircraft in its mul-
tiple flight modes, (helicopter-conversion-airplane)
the V-22 FCS is also required t o provide an integrated
Thrust / Power Management, aircraft maneuver limit-
ing and navigation coupling.
The V-22 Flight Control System is also unique in
its use of dedicated digital data busses as an integral
part of the system architecture, and in its use of iner-
tial reference systems as prime stability augmentation
sensors. The FCS also incorporates a 5000 psi hydraulic
system.
Accordingly, the testing of such a system be-
comes a very challenging task, especially given the
schedule constraints of the V-22 program.
This paper will address the means by which the
V-22 Flight Control System was tested prior t o first
flight, with prime focus being the software verifica-
tion, hardware-software integration and system vali-
dation testing. In addition, a discussion of the regres-
sion testing required t o revalidate the flight critical
system as changes are made during the flight test de-
velopment program will be addressed.
INTRODUCTION
The V-22 Tiltrotor aircraft has been a tremen-
dous challenge t o design, develop and qualify for
flight. The V-22 Osprey encompasses several new
technologies in its design including an all composite
structure and digital Fly-By-Wire Flight Control
System. This paper will concentrate on the Flight
Control System design and particularly on t h e
software and system testing required prior t o first
flight t o insure flight safety, as well as the on-going
Boeing Helicopters
Philadelphia, PA
effort t o maintain f l i g h t safety as changes are
incorporated during the development cycle.
The V-22 aircraft is a multiservice aircraft fulfill-
ing the mission requirements of the Navy, Marines,
and Air Force. The vehicle takes off vertically and
once in flight can convert t o a fixed wing turbo-prop
configuration. This permits the user the utility of both
a helicopter and a high speed transport aircraft. The
V-22 Osprey is the culmination of many years of devel-
opment effort by Bell Helicopter and Boeing Helicop-
ter Companies starting in the Fifties with the XV-3, til-
trotor and the VZ-76 tiltwing aircraft.
The V-22 Program is currently in the flight test
stage of the full scale development contract. Full scale
development is planned t o be complete in 1992. Pro-
duction of the V-22 will be phased in following com-
pletion' of the FSD Program. Current plans call for
over 650 V-22 aircraft be procured by the military ser-
vices.
The V-22 design is a 50,000 pound basic gross
weight vehicle constructed primarily out of graphite-
epoxy composite material. I t incorporates both inte-
grated Digital Avionics System and a Digital Fly-By-
Wire Flight Control System.
The V-22 Flight Control System consists of the pi-
lot's cockpit controls, three central digital computers,
three digital data busses, analog servoloops, and
electro-hydraulic actuators tied directly t o the control
surfaces (Figure 1&2). The basic system functions in-
clude Primary Flight Control (PFCS), Automatic Flight
Control (AFCS). Interfaces are also provided for the
Full Authority Digital Engine Control (FADEC) and Air
Data System (Figure 3).
The Primary Flight Control System Architecture is
a triplex self-checking pair concept. The key feature
of this architecture is that i t is not dependent upon
cross-channel voting for primary fault detection. This
design provides two-fail operation capability with no
degradation in flying qualities following the first
failure. The Automatic Flight Control System is a
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

Figure 1. V-22 Flight Control System Equipment.

I
I
I LEFT SIDE
CONTROL LATERAL SWASHPLATE ACTUATOR
...- ..- ..
MOTION
TRANSDUCERS
I
DIRECTIONAL
I SWASHPLATE ACTUATOR

CONVERSION ACTUATOR SWASHPLATE ACTUATOR

FLAP LEVER
MI RUDDER ACTUATORS I
I ENGINE LEVER FLIGHT
CONTROL
COMPUTER CONTROL DRIVEIFEEL FLIGHT
CONTROL
DATA
NOSE WHEEL STEERING 1 BUS

NACELLE POS XDUCER

ELEVATOR ACTUATORS
SWASHPLATE ACTUATOR
FLAPPING XDUCER RIGHT SIDE
T -b SWASHPLATE ACTUATOR

SWASHPLATE ACTUATOR

Figure 2. V-22 Flight Control Block Diagram.

 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

conventional triplex cross channel monitored archi- have been developed specifically for flight control
tecture providing single fail operate-failsafe capa- use. These macros provide the basic building blocks
bility (Figure 4). For the FSD initial flight test activity required t o design the flight control software and in-
an Analog Backup Computer is provided for pro- sure that the performance is as required by the system
tection against possible generic software errors. The requirements.
ABC is not part of the production V-22 Flight Control
System. V-22
FLIGHT
CONTROL
SOFTWARE
PRIMARY CONTROL SYSTEM PFCS -
AUTOMATIC FLIGHTCONTROL -AFCS

PFCS
rytj--q-l
PILOTS
CONTROLS
- -
+ h
NACELLE ANGLE

A:T;:
AIRSPEED
AERO-
+
ROTOR

E; ; ; ; ; ;
DYNAMICS
MGMT

DIGITAL
t HYBRID
b GOVERNER +
Figure 5. V-22 FCS Software Hierarchy.
ENGINE i ROTOR RPM
4
I J The test philosophy of the V-22 Flight Control
AFCS
COMMAND STABILI- INERTIAL
MODEL =TION SENSORS System is a bottom-up approach. Each individual ele-
FEEDBACKS
ment is tested at the lowest level possible and again at
COUPLED
each succeeding level until the complete system is as-
SYSTEM
GUIDANCE sembled on the flight aircraft for the flight test activ-
ity. Figure 6 presents a simplified graphical flow chart
Figure 3. V-22 Flight Control Partitioning. of this approach. The test activity was broken into
t w o phases, hardware and software verification and
system validation. The verification process was pri-
marily accomplished by the flight control system sub-
contractor, General Electric ACSD. The system valida-
tion was accomplished at Boeing Helicopters.
he test facilities required t o support the devel-
opment of the V-22 Flight Control System consist of
the hardware and Software Development facilities,
and the V-22 lntegration Laboratory at General Elec-
tric ACSD in Binghamton, New York; the Flight Con-
CHANNEL 3 c c o lrzi
~
trol System lntegration Rig (FCSIR); and the Flight Sim-
ulation Laboratory at Boeing Helicopters in Philadel-
FCS O A T 1 BUS phia. In addition the Ground Test Article (GTA) and
Aircraft No. 1 and 2 were used during initial system
ELECTAiC
CONVEASW checkout.
ACTUATOR
The FCSIR facility included all elements o f the
V-22 Flight Control System from the basic electrical
Figure 4. FCS Architecture. and hydraulic supplies, pilot cockpit controls, digital
and analog sensors, flight control computers, and the
The V-22 Flight Control System software is parti- electric and electro-hydraulic actuators. The actuators
tioned similarly t o the functional partitioning of the were installed into rigs that simulated both the con-
basic system. There are three computer programs that trol surface characteristics, the aircraft structural stiff-
make up the full software compliment, the Input- ness and aerodynamic loading. The hydraulicdistribu-
Output Processor (IOP), the Primary Flight Control Sys- tion and electrical wire also closely duplicated the ac-
tem (PFCS), and the Automatic Flight Control System tual aircraft hardware. Figures 7,8,9and 10 show the
(AFCS) programs. The programs are broken down FCSIR facility. A more detailed description o f the
into separate functional elements; Executive, Input FCSIR is provided later in this paper. One unique fea-
Signal Processing, Data Management, Built-In-Test, ture of the FCSIR laboratory is its ability t o tie into ei-
Control Laws, and Actuator Signal Management. Fig- ther the avionic system integration lab and or the
ure 5 shows the hierarchical breakdown of the V-22 flight simulation facility. This capability allows hard-
Flight Control System software. A key element t o the ware in the loop testing with the pilots t o complete
software design is a collection of macro functions that the validation process.
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

INTEGRATION INTEGRATION INTEGRATION GE 1

I
BIB

I
>
I
, . - - - - - - - - -PRODUCTION
------- 1 HARDWARE/
SOFTWARE
INTEGRATION
+ ACCEPTANCE
TESTING
DELIVERY
VERIFICATION -+. . .
I
1 I 4 l %6TB
I A I
I I
I I
I I I
I I
I
SRA WRA .
I
L
r I
I I
PRODUCTION
L------,,,,,,,,,,,----J

I
SOFTWARE
VERIFICATloN
HARDWARE
VERIFICATION
-b
I MACROS
MODULE CROSS-

'FCS'
SECTION

(HARDWARE ISOFTWARE)
VERIFICATION
----,
Figure 6A. System Preflight Testing.

I
GE I B I B
I

SYSTEM SERVO
FROM
6A

CLOSED
WITH
MODELS

'FCS' TOP LEVEL MISSION WEAPON

> L (!$=:, '
REQUIREMENTS
VALIDATION
REQUIREMENTS
VALIDATION
SYSTEM
VALIDATION
VALIDATION

Figure 6B. System Testing.

TI FUPERONS FUPERONI

Figure 7. V-22 Flight Control System

Integration Rig (FCSIR) Facility. Figure 8. V-22 System Integration Test.
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021
Figure 9. FCSlR Control Room.
Figure 10. FCSlR Rig Room.
Currently there are four V-22 aircraft flying; two
at the Boeing Flight Test Center in Wilmington, Dela-
ware and two at Bell's Flight Research Center in Ar-
lington, Texas. The GTA is being used for the integra-
tion and development of the Blade 1 Fold-Wing Stow
System.
The Flight Control System has evolved through
five major software block revisions. The present flight
software includes the IOP and PFCS functions only.
The AFCS software will be delivered in June, 1990 t o
begin the flight test development of the AFCS func-
tions. There have been over 1400 code and documen-
tation Software Trouble Reports generated since the
system integration and validation of the V-22 FCS
began in 1987. There are approximately 150 open
STR's for system improvements. Future plans include
t w o major updates t o the FCS functional definition t o
include the maneuvering limits and the coupled
navigation functions. These are scheduled t o be avail-
able for flight testing toward the end of 1990.
SOFTWARE VERIFICATION
Extensive, thorough verification testing has
been performed on the FCS software t o ensure that
the software satisfies its technical, operational and
performance requirements. The set of software-
unique verification tests is comprised of several thou-
sand test cases. Most of the verification testing was
performed by General Electric, the software supplier,
at their facility in Binghamton, New York. Indepen-
dent macro and .module-level verification tests were
performed by Boeing Helicopters.
The GE verification testing ensured the software
operates in accordance with the detailed functional
requirements contained in the Program Performance
Specification for each computer program. The re-
quired test results were derived from the PPS require-
ments. Tests were performed at the macro, module
and integration levels. Table 1 summarizes the tests
performed at each level of the verification and hard-
ware / software integration testing. Each of the tests
shown typically consists of several test cases.
Table 1 -Verification Test Coverage 1 Thoroughness
TESTLEVEL N O OFTESTS TEST COVERAGE
MACROS 112 TEST E V E R Y PATH a EXPANSIONFOR CORRECTFUNCTION
TEST ALLBREAKPOINTS 8 PAST VALUES
TESTFOR OVERFLOW USING FULL RANGE OFINPUTS
MODULES 789 TEST EVERY PATH FOR CORRECTFUNCTION
TEST MACRO INTERFACES
TEST ALL DATA CONSTANTS B PAST VALUES
TESTFOR OVERFLOW USING M A X VALUES Of INPUTS
SNY 45 TEST THAT MODULE INTERCONNECTIONS ARE CORRECT
INTEGRATION
HWISW 364 TESTTRIPLEX SYSTEM OPERATION
INTEGRATION
TESTCPCI 8 H W I SW INTERFACES
TESTPOWERUP INITIALIZATION 8 CHANNEL FRAME SYNCHRONIZATION
TEST ALL CONTROL PATHS
TEST FAULT DETECTION 8 RESPONSE
TEST BUILT-IN.TEST OPERATION
PERFORM TIMING 8 E N D T O END PRECISION TEST
STRESSTEST 63 PERFORM I 0 HR TEST
INIECT SERIES OF COMBINED INPUTS THROUGHOUT B BEYOND
OPERATING ENVELOPE
TEST FOR SYSTEM FAULTS. FRAME 8 NUMERIC OVERFLOW
The independent BH tests verified correct soft-
ware operation compared t o a known software
model, a BH-developed software simulation called
VECEX. The VECEX simulation was used starting early
in the V-22 FCS development t o derive the software
macro and control law requirements.
MACRO TESTS - All of the macros, structured
and functional, were thoroughly tested t o verify cor-
rect operation in accordance with the macro specifica-
tions contained in the PPS. Since the FCS software is
macro-intensive, this is a very important test level
which provided a giant step in verifying the software.
The macro tests were performed in the same VAX en-
vironment in which the software was developed using
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021
the ACT tool set in conjunction with the MIL-STD-
1750A MDAC simulator.
The macro testing verified correct operation of
each macro for every software path and source code
statement. All logic, data constants, breakpoints,
boundary values and options at each conditional
branch point were tested. All of the macro input sig-
nals were tested at the maximum representable value
t o ensure that no numeric overflows can occur. The
tests verified that there are no software errors that
would result in an undesirable interrupt or loss of a
function.
The test design approach was t o specify a suffi-
cient number of single-iteration test cases t o thor-
oughly verify correct macro operation. An analysis
was performed for each macro t o determine whether
black-box testing, which focuses on the macro inputs
and outputs, would adequately test the macro. If the
specified black-box test cases were found t o be inad-
equate, then white-box testing, which focuses on the
internal workings of the macro, was added t o check
internal values. Test breakpoints and snapshots were
used as necessary.
A set of test standards and guidelines was estab-
lished t o ensure thorough verification of the soft-
ware. These identified the detailed requirements for
testing each type of macro and module including the
following:
All macro expansions are tested
All addressing modes and register usage are tested
Initialization capability is correct
Past values are stored and used properly
Data for inputs and expected results are unique
and non-trivial
Code under test is not modified
The tests were performed on the VAX 111780 by
a command file for each macro that executes the ma-
cro with the specified inputs, stores the specified out-
puts and compares the results with the required re-
sults which were derived from the macro require-
ments. The macro performance was verified t o be cor-
rect t o the LSB. All or a selected subset of the tests
could be executed in the batch mode on the VAX.
Three utilities were developed t o generate the
test command files. The Prompter prompts the cre-
ator of the test case for inputs, outputs, comments
and the other necessary information for the test case.
The Test Compiler takes the inputs and generates the
test t o be executed on the MDAC simulator. The Com-
parer compares the actual test results using the speci-
fied test acceptance criteria and generates a report.
BH performed a detailed review of all of the GE
generated test specifications and procedures for all
levels of the verification and hardware Isoftware inte-
gration testing.
MODULE TESTS - The module testing verified
correct operation of each individual module that com-
prises the FCS flight software. The same test ap-
proach, methods, and criteria that were used for the
macro tests described above were also used for the
module testing. The module testing was aided by the
design constraint that each module have only one en-
try point and one exit point, and have the control and
data interfaces clearly defined.
The detailed test requirements for the module
testing that were applied, in addition t o the macro
test requirements above, include the following:
Correct execution order within the module is veri-
fied
Inputs cover the full range as defined by the calcu-
lated worst-case values - verify scaling and no nu-
meric overflow
All macro invoking parameters and interfaces are
verified
In addition t o the verification testing performed
by GE, BH performed independent dynamic testing of
all of the functional macros and for a cross section of
modules. These tests were performed using the VAX
111785, the HP64000 microprocessor development sys-
tem and the VECEX software simulation. The test
methodology focused on ensuring that the output
test results of the flight software running on the
HP64000 1750A processor emulator matched the re-
sults from the VECEX simulation. The test setup is il-
lustrated by Figure ll . An automatic test driver was
developed t o initialize the macros and modules under
test; apply selected sinewave, ramp and step inputs;
compare the flight software results with the VECEX
results; and record intermediate and output results.
The cross section of modules that were tested was se-
lected concentrating o n those modules t h a t are
unique and more complex. The VECEX simulation,
hosted on the VAX, is capable of generating input and
output data for each iteration of the 1750A processor
with LSB precision. Thus, the macros and selected
modules were verified t o be correct for each iteration
down t o the LSB for full-range dynamic waveform in-
puts.
-
VAX 11 I 7 8 5 IEEE 488
HIGH SPEED LINK
HP64000
VECEX
SIMULATION FLIGHT
+ TEST DRIVERS -
RS-232
SOFTWARE
SERIAL LINK
I MIL-STD-1750A
F9450
DISK
EMULATOR
PRINTERS PLOTTER OR
TAPE POD
Figure 11. Software Verification (VAX) Test Setup.
INTEGRATION TESTS - Control law module inte-
gration testing was performed by GE using t h e
HP64000 1750A processor emulator. This testing was
limited t o the PFCS and AFCS control laws since mod-
ule integration testing could n o t be conveniently
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021
performed for the other functional blocks i n the
single-processor VAX or emulator environment. The
integration testing for the other functional blocks was
performed at the hardware /software integration test
level where the other processors and computer chan-
nels were present.
The control law modules were tested as a unit
using an automated test driver t o verify all of the in-
terconnections between the control law modules.
The required results were provided by a GE developed
FORTRAN model of the software. This testing also
provided additional verification of correct control law
calculations, numeric scaling, operation of the dynam-
ic elements, initialization of values, and memory us-
age.
HARDWARE / SOFTWARE INTEGRATION
Hardware /software integration testing was per-
formed by GE at their facility t o verify operational cor-
rectness across the hardware 1 software boundaries
for the software and system electronic components
supplied by GE. This testing was performed using the
actual FCC hardware and embedded flight software,
and specialized test equipment called the Electronic
Console, which simulates all FCS inputs and outputs
for the system components not supplied by GE.
A continuous-operation stress test was per-
formed for the software embedded in the FCCs using
the electronic console environment at GE.
TRIPLEX SYSTEM INTEGRATION TESTS - Integra-
tion testing was performed t o verify correct triplex
system operation, and CPCl and hardware / software
interfaces. This level of testing also verified the soft-
ware interfaces that require interprocessor communi-
cation, hardware interfaces, or cross-channel data
that are impossible or very difficult t o test at the low-
er test levels.
The hardware /software integration test labora-
tory configuration is illustrated in Figure 12. The elec-
tronic console is comprised of a control console which
enables the tester t o perform the tests and simulates
the bus components, and an interface console which
contains the actuator and sensor simulations. The sys-
tem was stimulated using inputs via the electronic
console and the responses were evaluated via the
non-volatile memory (NVM) data, strip chart record-
ings, oscilloscopes, meters, and visual readings from
the electronic console panels.
The specific types o f tests performed during the
system integration testing include:
a Power-up initialization
Input signal selection
Fault detection and response
Control paths
FCS / Avionics bus interface
PFCS / IOP IAFCS processor communication
Channel frame synchronization
Timing and end-to-end precision
a Built-In-Test system tests
Figure 12. HW 1 SW Integration Test Configuration.
The test specifications and procedures specify
the required inputs, outputs, operator actions, and
displays t o be observed. Command files were gener-
ated that operate on the VAX and PC t o partially
automate the testing. The test cases specify inputs
and associated outputs t o verify that the specified re-
quirements are met, and that there are no software
errors that would result in an undesirable interrupt or
loss of a function. In general the tests are end-to-end
with the inputs and outputs specified at the earliest
and latest points in the software, respectively. Where
this approach was inadequate, intermediate test
points were chosen. For each test case the value of all
inputs that have an effect on the results were explicit-
ly specified and all other inputs could take on any val-
ue.
STRESS TEST - A 14-hour continuous-operation
stress test was performed for the PFCS flight software
embedded in the FCCs in the electronic console envi-
ronment t o verify that the software would continue
operating while a series of combined inputs were in-
jected throughout and beyond the operating enve-
lope. The input signals were sinewaves with varying
frequency and amplitude including magnitudes ex-
ceeding the maximum input signal amplitudes. The
input frequency ranges were selected t o provide a
pseudo random input combination at any point in
time, and t o ensure that the frequencies chosen were
not filtered out by the analog components or by the
digital sampling and processing rates. The inputs
were selected t o exercise all of the primary control
and sensor inputs including the AFCS command inputs
t o the PFCS.
The flight conditions for the stress test were cho-
sen t o reflect normal and abnormal conditions o f air-
speed, nacelle angle, engine torque, rotor and engine
speed. The flight conditions chosen provide a cross
section of scenarios encountered during the possible
system operating modes. The test case sequence pro-
vides a scenario f r o m operation o n t h e ground
through take-off, normal flight (helicopter and air-
plane mode) and system failures. The system was con-
tinuously monitored during the test t o ensure that no
software faults, time frame overruns, or numeric over-
flows occurred.
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021
SYSTEM VALIDATION TESTING
The primary task in validating the flight control
system was t o successfully integrate the separate
pieces of hardware (computers, actuators, hydraulics,
electrics, sensors) into a fully functional whole. Fol-
lowing this, the system could be tested t o ensure that
i t met its goals in terms of performance, safety, and
reliability.
In order t o accomplish this task, the FCSIR (Flight
Control System Integration Rig) was constructed. The
FCSIR provides a mechanism for assembling the sepa-
rate system components in a simulated operational
environment. As such it can be viewed as the Fly-By-
Wire equivalent of a traditional "ironbird".
As mentioned previously, the Flight Control Sys-
tem testing philosophy was based upon a "building
block", or bottom up approach, where the largest
step t o be taken was t o integrate t w o functions that
had previously been shown t o work independently.
Thus the validation of the FCS was treated as a stand
alone technical challenge until all of the FCS compo-
nents were integrated and could reliably work as a
system.
Following the system integration in the FCSIR,
the integrated system was "tied-in" with the V-22
flight simulator t o allow the pilot t o "fly" the aircraft
with the real FCS hardware in the loop. Additionally,
the FCS was integrated with the avionics laboratory t o
ensure that the interfaces necessary t o support FCS
operation in the aircraft were working. This latter
testing is especially important in an "integrated" air-
craft such as the V-22, where all fault displays are pre-
sented via the multifunction displays in the cockpit.
Obviously, the ability t o provide the pilot with rel-
evant information regarding the health of the FCS is
as pertinent t o flight safety as its performance.
The successful operation of the FCS within these
environments, including appropriate pilot ratings for
the hardware in the loop simulation, became the final
validation criteria of the FCS prior t o its release t o an
aircraft for ground running and flight.
FCSIR DESCRIPTION - The layout of the FCSIR is
shown in plan view in Figure 7, and as can be seen
consists of three areas. These areas are the "control"
area, which is essentially a clean room where the
flight control computers and their supporting test
consoles are located; the actuator room, where the
control system actuator rigs are located; and a "pow-
ernroom, where the hydraulic and electric power
sources are located. This latter room is isolated mainly
on account o f the noise generated by 5 varidrives
powering the three hydraulic pumps and four electri-
cal generators. The FCSlR components are connected
using aircraft wiring harnesses and hydraulic tubing,
so that the wire lengths and hydraulic volumes, in
general, accurately represent the conditions on the
aircraft.
Each of the actuator rigs provides a realistic sim-
ulation of the environment in which the actuators are
expected t o perform. Stiffness of the control surfaces
and backup structure are represented by the mount-
ing brackets in the rigs, and aerodynamic loading is
provided by separate load actuators.
The FCSIR control area contains t w o consoles
that support the FCCs and provide a "patch panel" in-
terface with the other FCS components. Through
these patch panels the computers can be commanded
t o interface either with real hardware, or with analog
and digital simulations of the other FCS components.
This latter capability is useful in software intensive
testing, where the hardware interfaces are not as im-
portant.
The control room also provides a home for the
FCSIR "cockpit". As with the actuator rigs, this cockpit
makes use of aircraft hardware in a geometrically ac-
curate representation of the V-22 cockpit. The cockpit
is interfaced with the computers in a similar manner
as the actuators, through the "patch panels", so that
either real or simulated control inputs can be intro-
duced into the control system.
The V-22 control system, in a break from tradi-
tion, uses MIL-STD-1553 interfaces t o communicate
with a number of its sensors, as well as w i t h the
FADECs controlling the T406 engines. As these are all
active sensors, and require physical stimulations that
cannot be provided easily in the laboratory environ-
ment, they are replaced in the FCSIR by digital simula-
tions, using mathematical models provided by the
component suppliers.
The interfaces between the FCSIR hardware and
the simulations described above is shown in Figure 13.
FCSIR /SIMULATOR AVIONICS INTERFACES -The
interfaces between the different laboratories de-
scribed above have been shown previously in Figure 8.
A more detailed description of the same interfaces is
shown as Figure 14.
The first thing that becomes apparent in viewing
these arrangements is the complexity of the signal
flow paths, and the number of buffers required t o
transfer each piece of data around. As powerful as
digital computers are, they can perform one function
even more capably if allowed, and that is t o act as
"Traffic cops". Therefore a critical design factor in de-
signing these interfaces has been streamlining the
flow of data between the different areas in order t o
maintain the bandwidth of the overall process. For
example, the flow of data, in a closed loop sense, re-
quired t o support piloted simulation with the hard-
ware in the loop is shown as originally designed in Fig-
ure 15. After the initial shakedown of the interfaces
was complete, the data flow was as shown in Figure
16. As testing continues with some of the outer loop
autopilot functions, it is t o be expected that more
changes will have t o be made in order t o reduce signal
latency.
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CONTROL SURFACE ACT2OEL HINGMOM
ACTUATOR RIG
CALCULATE SURFACE CALCULATE CONTROL
DEFLECTIONS SURFACE ACTUATOR LOADS

CONVERSION
ACTUATOR RIG

SWASHPLATE
ACTUATOR RIG

ENGINE

FLIGHT CONTROL
COMPUTERS
L.-.-.-.-.-.-.-.-.-
I
RPM, AZIMUTH

Figure 13. Math Model Integration Diagram V-22 FCSIR. -

PILOT CAB
INPUTS MOTION

SENSOR AN5600 AN5600 SIM

SIM 110 110 CAB
DISPLAY SIMULATED PERKIN ELMER3260
PROCESSORS MULTI.PROCESOR
SVSTEM (MPS)

AIRCRAFT
+ LOAD R E S P O N S E
AVIONICS BUS
SIMULATION (AIRCRAFT) II
Horsrrrc* II ;;;CocmT j 9-b 1 ~ ~ (FsL)
LAB ~ ~ ~ A T l o N
SENSOR
SIM
AN5600
110

BUS
SIM

FLIGHT
CONTROL
SVSTEM
Figure 15. FCSIR Closed Loop Testing - Pilot in the
IINTEGRATION
RIG Loop System Validation.
(FCSIR)

PILOT CAB
INPUTS MOTION

SENSOR
SIM

-
FCC

AIRCRAFT

I
-RESPONSE

II
"
LOAD AN5600
ACTUATORS 110 -ANAlOC

II SENSOR
SIM
AN5600
110
BVIC I
-
INSTRUMENTATION
-

TEST RIGS
INSTRUMENTATION
BUS
SIM Y-H-I
DIGITAL
INPUTS ~~{~~~ REPORTS

Figure 16. FCSIR Closed Loop Testing - Pilot in the

Figure 14. BHlC Interface Schematic. Loop System Validation.
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

SYSTEM INTEGRATION AND VALIDATION TEST-
ING - When the hardware began t o arrive in the FCSIR
there was a natural tendency t o ignore a structured
test approach in the rush t o get everything working.
However, as has been repeatedly emphasized
throughout this paper, the flow of testing, from initial
checkout through flight release of the validated sys-
tem, had t o be based upon a "building block" ap-
proach in order that flight safety would not be com-
promised.
Accordingly the progression of integration test-
ing was as shown in Figure 17. The functional blocks
shown are mostly self-explanatory, except for "Data
Management, which is the functional block within the
V-22 FCS that deals with channel unique processing
and the processing that provides system health status
t o the cockpit. System operation was tested in layers,
with each new layer of testing building upon a pre-
viously tested layer. The progression worked from a
component interface level into the core of the system,
the control laws, whose correct operation depends on
all other functions behaving correctly.
Consequently, the integration testing com-
menced by evaluating t h e interfaces w i t h , and
performance of, the electrical and hydraulic systems,
in order t o ensure proper FCS power supplies. Testing
continued with the checkout of the various analog
and digital interfaces t o the system, t o ensure that all
inputs were properly received and correctly scaled
into the computers.
In parallel with the testing of the system inputs,
the response of the various actuators, and their servo-
loops, were tested t o verify that output commands
from the computers were properly transmitted t o the
aircraft surfaces.
Having tested the interfaces between the out-
side world and the computers, what was left was t o
validate the control paths through the computers,
and show end t o end system operation. This began
using the most simple control paths available, t o es-
tablish that the control inputs were properly reflected
in actuator commands and control surface positions in
the various actuator rigs.
The establishment of these basic control paths
through the system allowed integration testing t o
continue along t w o parallel paths. The first path was
the testing of the system redundancy management,
this was accomplished by causing system failures and
showing that the appropriate fault reactions oc-
curred, including reconfiguration of the control laws
where appropriate. Although simple in concept, the
redundancy management testing was by far the most
complex and time consuming portion of the testing,
due t o the large number of input signals involved in
the V-22 system, and the many different combinations
of fault circumstances that had t o be tested.

I START
I
WIRING CHECKOUT

HYDRAULIC
I / F CHECKOUT
ELECTRICAL
l l F CHECKOUT
I
I I F CHECKOUT

INPUT SIGNAL
MANAGEMENT MANAGEMENT
A
AVIONICS
I I F CHECKOUT I
I
P

t
I CONTROL LAWS
(BASIC CMOS)
I
-t
ANALOG BACKUP ACTUATOR SIGNAL
I .
CONTROL LAWS
(DETAILED)
I V

S 1 W SERVOLOOP
BUILT IN TEST
I
CHECKOUT
INTEGRATION COMPLETE

Figure 17. Laboratory Integration Test Progression.

 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021
The second path was the detailed control path
performance testing. Although this testing was ini-
tially more complex t o set up, once started it becomes
relatively straightforward due t o the deterministic na-
ture o f the control path processing. The difficulty in
testing the control paths was seen, as was expected,
when the system configuration was artificially upset
by external stimuli and then tested t o see that the re-
initialization and recovery algorithms operated satis-
factorily under all conditions.
As part of the integrated system test progres-
sion, the Analog Backup Computer had also t o be test-
ed prior t o flight release of the system. As with all
other testing, the ABC was initially tested as a stand
alone unit, followed by testing as part of the total
FCS. The integrated testing was specifically t o evalu-
ate transient and fault free switching in both direc-
tions between the ABC and FCCs.
Completion of this level of testing resulted in a
system that was capable of operating consistently and
reliably as an independent system, but not a system
that could be guaranteed t o operate satisfactorily in
an integrated aircraft environment.
Therefore, as mentioned previously, testing
turned towards integrating the FCS with the simula-
tion laboratory t o provide hardware in the loop verifi-
cation of the expected aircraft handling qualities, and
with the Avionics laboratory t o verify satisfactory inte-
gration of the t w o systems.
Testing with the simulator was at a qualitative
level only, and was intended t o demonstrate t o the
program test pilots the performance of the "as built"
FCS as opposed t o the simulated system. Implicit in
this was the groundrule that the hardware in the loop
simulation would not become a handling qualitiesde-
velopment experiment, and changes t o the system
would not be made as a result of this testing in order
t o improve Cooper-Harper ratings unless flight safety
was impacted. The simulations were flown t o demon-
strate degraded modes and failure transients as well
as normal operation.
The initial integration of the FCS and Avionics
systems was designed for evaluation of the cockpit
display interfaces only, in order t o verify t h a t the
health of the FCS is properly displayed t o the pilot un-
der all circumstances. However this activity continues
as an ongoing program as the capabilities of both sys-
tems are increased. In particular, the development of
the Flight Director and blade fold / w i n g stow capabil-
ities of the V-22 mean that this level of integration
testing will be a full time activity for many months t o
come.
I t is estimated that in excess of a thousand test
cases and nine thousand hours o f FCSlR operation
were completed prior t o the system being delivered t o
the test vehicles.
AIRCRAFT INTEGRATION - With the integration
o f the FCS and Avionics completed satisfactorily t o
support flight operations, the system was released t o
the flight vehicles. Prior t o first flight, a significant
number of static ground tests were performed on the
Ground Test Article and the first aircraft for functional
testing, proof load tests and ground vibration tests
and ground running t o complete qualification of the
drive train. The flight control system was active dur-
ing all these operations. In addition system specific
tests were conducted for EMC source 1 victim compati-
bility, and for rotor control loads vs control motions.
In all, over 150 hours of restrained ground running at
a wide range of power settings were accumulated pri-
or t o first flight of the V-22 aircraft.
INITIAL FLIGHT TEST RESULTS -The first flight of
the V-22 was on Sunday March 19, 1989. The flight
lasted for approximately 0.2 hours and achieved all
the expected results with respect t o the systems oper-
ations and initial hover handling qualities. The first
full conversion t o airplane mode was completed in
September of 1989 after about 10 hours of flight. As
of February, 1990, the V-22 fleet has over 65 hours of
flight time. The handling qualities of the aircraft have
exceeded the predictions of the simulation and the
performance o f the Flight Control System has met all
expectations. The system reliability has been excel-
lent. PFCS and AFCS development will continue as the
flight envelope is expanded.
REGRESSION TESTING
The primary and absolute requirement for the
system testing is t o ensure flight safety. This require-
ment underlies the development of all tests and test
plans. Subservient t o this requirement there are t w o
purposes for regression testing. First, that functions
which have changed perform as required and second-
ly, that functionality of other (related or unrelated)
code areas are not adversely affected or inadvertently
changed. Testing for each new software version must
conclusively demonstrate that these requirements are
met.
Testing o f changed functions is relatively
straight forward since the tests required for a particu-
lar function have already been defined formally in the
CPTP and subsequent test specifications and proce-
dures, but demonstrating the health of all unchanged
functions is not clear cut. Ideally you would like t o re-
run the complete complement of tests defined for the
system (i.e. the entire testbed), but the magnitude o f
the job (the total number o f tests) and the response
time required by schedule demands do not allow that
luxury.
The careful segmentation of system require-
ments and the modular design o f the V-22 software
allow a compromise, a subset of tests which demon-
strates the functional changes and the health of the
overall system. Unfortunately the subset definition
must be derived for each specific software version, us-
ing the software version definition and the general
test plan requirements t o form a l i s t of "delta tests".
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

Any standard subset would rarely cover the changes
made and would add little value beyond what is
gained by exercising the software in the system dur-
ing a piloted simulation. In many respects the piloted
simulation could be considered the testbed for deter-
mining the health of the overall system.
Regression testing of the V-22 software involves
three related and overlapping efforts: version defini-
tion, test planning and testing and reporting. Refer
to Figure 18 for a top level view of the process which is
described in the following sections.
Quality Assurance and Configuration Manage-
ment policies for the V-22 program are enforced by
their respective organization personnel throughout
the development and regression testing of the pro-
spective software version.
SOFTWARE VERSION DEFINITION - Software ver-
sions are defined as a set of changes andlor correc-
tions to a previous version. The corrections are identi-
fied as a list of software trouble reports (STRs) which
need to be resolved in the software build or a particu-
lar software patch file. Changes and problems are
grouped together to provide orderly development
and support of the flight test development testing.
This list is communicated as a requirement to the soft-
ware supplier (GE) by way of a Software Version Defi-
nition document. Figure 19 shows how this require-
ment grows into a detailed software version defini-
tion.
Delivered software versions include a list of all
changes which have been made to the software by
the software supplier and a complete directory of all
files which comprise the software version. Changes
are tracked individually with Software Development
Change Requests (SDCRs). Each SDCR is a response to
a Software Problem Report (SPR) created by the soft-
ware supplier. SPRs are produced for each STR sub-
mitted to the supplier and for any problems found in-
dependently by the supplier. This information is doc-
umented by the software developer in a Version De-
scription Document (VDD) and is a product of their
electronic configuration management system. These
details are included as part of a more general descrip-
tion of the software version provided in a configura-
tion index.
The configuration index includes descriptions of
the computer programs, specific limitations of the ver-
sion, a complete list of the STRs closed, up to and in-
cluding this version, and a list of the STRs which are
still open (existing problems of a low priority). See
Figure 20.
REGRESSION TEST PLAN - A regression test plan
is constructed for each version of software. Tests are
chosen from each level of testing and identified in
two regression test plans, one encompassing all the
verification testing t o be performed by the software
supplier (GE) and the other providing the system
integration and validation testing to be done by the
systems integrator (BH). Both plans are reviewed and
approved by functional leads and indirectly by the
review boards.
For a particular version, the plan is a collection of
tests defined for each software trouble report (STR)
correction included in the version, plus tests added
after review of the software implementation of the
changes and a "test card" of maneuvers to be flown in
the piloted simulator.

I SOFTWARE BASELINE

I 4
+
STR GENERATION

VERSION STR TEST DEFlN

DEFINITION

I
&*+
PHASE

TEST
PLANNING
PHASE VERIFICATION TEST PLAN VALIDATION TEST PLAN

F VERIFICATION

VALIDATION

CONFIGURATION INDEX

Figure 18. Regression Testing Process.

 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021

are affected must be tested, software integration lev-

el tests are required and a hardware / software inte-
SOFTWARE I SOFTWARE
gration level test must be performed. If the range of a
: S0FTWA.F ! : module output is expanded then any module using
the output must be tested t o ensure no overflows.
Formal system integration and validation tests
,- ADDITIONAL CHANGES AND
ENHANCEMENTSI N C O R P ~ are identified whenever possible but some changes,
CHANGES FOR NEW SOFTWARE VERSION
like gain or constant changes within a module, can
not be easily or clearly demonstrated at the system
level. For these changes, special tests or checks may
TESTING AND RELEASE
have t o be defined. These may include strip chart out-
VERIFICATION VALIDATION
VERSION DESCRIPTION
puts, temporary refinements t o formal tests, electron-
CONFIGURATION INDEX i c utilities t o compare the processor memory locations
with previous version code values and / o r code inspec-
Figure 19. Interim Software Versions. tion.
Changes involving requirements' changes (e.g.
functional performance updates or enhancements)
typically result in the most extensive code changes
SOFTWARE
ELECTRONIC TROUBLE and are tested at nearly all the levels of test culminat-
DATABASE REPORT
SYSTEM
ing in a piloted evaluation in the simulation facility at
I I
I I
B H.
VERSION F CLOSED I REGRESSION TESTS AND RESULTS - Prior t o re-
I lease of a software version for flight testing, summary
DESCRIPTION I
DOCUMENT
I reports are produced identifying the pass / fail status
I
1
of the verification tests and validation tests.
I Verification test results are evaluated by a com-
I
/ pare utility t o determine if actual test results are equal
t o expected results within prespecified tolerances. Re-
ported failures are resolved on a case by case basis.
Any modifications required for the tests are documen-
\
\ ted with SPRs and SCDRs and must be approved prior
SOFTWARE 1 t o implementation and successful completion of the
I testing.
LISTINGS
- I Validation test results are reviewed and ap-
SOFTWARE
,
1
proved individually during the testing process. Any
ELECTRONIC I
CONFIGURATION / required changes t o formal procedures are identified
CHANGE
\ MANAGEMENT / in test file headers and saved for future reference and
/
\ 0
\ 0
0 formal document releases. A summary test report is
produced identifying the test versions actually per-
formed, the date they are run and their pass / fail sta-
Figure 20. Software Version Identification. tus.

Each software trouble report is reviewed for LESSONS LEARNED

completeness of the "tests required" section. The
completeness of this set of tests is judged based on a As a result of the design, development, verifica-
minimum scope of testing associated with the expect- tion, and validation of the V-22 Flight Control System
ed problem resolution. This scope is determined by there have been several significant lessons learned.
applying groundrules t o the expected software cor- 1. Develop the detailed test approach and gener-
rection or change. ate the test requirements and specifications ear-
For example, changes which do not alter the in- ly in the system and software design process.
put or output list of a module or the range of a mod- This insures complete and thorough test cover-
ule output can be fully tested at the module level. age and efficient test procedure preparation
Changes involving a macro require new macro testing later in the development cycle.
and a retest at the module level for any module con- 2. Including explicit data values in the test specifi-
taining the macro. Any identified macro or module cation moves the emphasis from thorough test
tests are rerun in their entirety. The list of modules af- planning and design t o complex number crunch-
fected is determined electronically by using search ing and creates inflexible test specifications.
utilities on the program listings. If the input / output 3. Generate more small simple test cases, rather
list of a module is changed, then all modules which than fewer large complex test cases t o facilitate
 Downloaded from SAE International by Nanjing University of Aeronautics & Astronautics, Wednesday, April 28, 2021
test updates and test modifications. This en-
hances test planning when regression testing is
required t o revalidate the software following
changes.
4. An integration facility such as the FCSlR is neces-
sary t o permit real system validation t o be ac-
complished.
5. The development of a FCSlR facility must parallel
the Flight Control System development and must
be given as much priority as the FCS hardware
and software activity.
6. All system interfaces must be included in the in-
tegration lab. A well defined interface does not
ensure that actual operation will be as expected.
7. It is extremely important t o consider real life sce-
narios in setting up design and test criteria, i.e.
ground operation, ground support equipment
characteristics, operator actions, start-uplshut-
down sequences, etc.
8. Simulator tie-in for hardware in the loop testing
is valuable not only for system validation, b u t
also for pilot training.
SUMMARY
Testing of the V-22 Flight Control System is very
thorough and provides the confidence t o permit the
flight test program t o proceed safely. The hierarchical
structure of the system and software design allows
testing at multiple levels ensuring that all system re-
quirements are met. The real test of both the person-
nel responsible for the V-22 Flight Control and of the
System itself is the maintenance of the flight safety in-
tegrity throughout the flight test program as changes
are incorporated. The regression test techniques em-
ployed allow the orderly and controlled implementa-
tion of these changes. The initial flight test results
have confirmed that the above approach t o verifica-
tion and validation of a system such as the V-22 Flight
Control System is practical and will result in a safe and
reliable product.
ACKNOWLEDGMENT
The authors wish t o acknowledge the many
years of support and in many cases extraordinary ef-
fort by the Bell-Boeing Flight Control Team and the
V-22 Flight Control Team at General Electric ACSD in
Binghamton, New York. Without the efforts of this
dedicated team the V-22 Flight Control System would
not be the success i t is.
Special acknowledgment is required for Mr. H.
Agnew and the NAVAIR personnel who supported our
activities throughout the development o f the V-22
Flight Control System.
REFERENCES
1. V-22 Tiltrotor Fly-By-Wire Flight Control Sys-
tem, Bruce L. McManus; presented at Eleventh Euro-
pean Rotorcraft Forum, Paper No. 57, The City Univer-
sity, London, England, September 10-13, 1985.
2. V-22 Control Law Development, Kevin W.
Goldstein and Larry W. Dooley; presented at 42nd An-
nual Forum of the American Helicopter Society, Wash-
ington, D.C., June 24, 1986.
3. V-22 Flight Control System; presented a t
AIAAIAHSIASEE Aircraft Design, Systems and Oper-
ations Meeting St. Louis, Mo., September 15, 1987.
4. Hardware-in-the-Loop Testing of the V-22
Flight Control System U,sing Piloted Simulation,
C. Robinson, C. Dabundo, and J. White; presented at
AlAA Flight Simulation Technologies Conference and
Exhibit, Boston, MA., August 14-16, 1989, AIAA-89-
3322.