2. AIAA-2000-4173
2
American Institute of Aeronautics and Astronautics
Nowadays a training flight simulator is a “must” for
every new aircraft. For this scope a previously
developed EFS can be able to provide a very detailed
aerodynamic database and flight mechanics model
plus all the systems and avionics simulation that were
already implemented in the EFS.
The Pilatus Aircraft’s Experience
Fig.1 The front of the cockpit and part of the
screen.
Fig.2 The front seat.
During the past couple of years an Engineering Flight
Simulator has been developed at Pilatus Aircraft Ltd.
The first idea was to provide the Aerodynamics and
Flight Mechanics office with a software tool that
would enable the engineers to analyze the flight
behavior of the airplanes in response to pre-recorded
control inputs, i.e. time histories of controls
deflections, deriving from flight testing. The
aeromodels, composed of the aerodynamic databases
and the flight mechanics models, would have been
realized in house using the aerodynamic data
calculated with theoretical or semi-empirical methods
or gathered during wind tunnel and flight tests
campaigns. It was decided that the “core” engine
solver of the six degrees of freedom equations of
movement would be off-the-shelf software: D-Six®,
from Bihrle Applied Research. The main reason of
going for an off-the-shelf product rather than
realizing the program internally was the efficiency of
human resources usage. D-Six® is a “platform” on
which all the aeromodels prepared by the engineers
can run in real time and, apart from solving the six-
degrees-of-freedom equations, it offers utility
functions such as displaying and plotting the
simulation data, manipulating coefficients curves,
matching pre-recorded flight test data (“overdrive”
function).
To take advantage of the possibility of “flying” the
virtual aircraft with a computer game device
(joystick) it was decided to create a connection to an
image generator which would provide the pilot with
an out-of-the-window view on a 20” monitor.
The following natural step was to create a more
realistic environment for the pilot. This led to the idea
of setting up a real airplane cockpit with flight
controls and forces, main systems controls and a big
flat screen, in a dedicated room. A separate room was
intended to host the control station for the EFS
operator and a facility for the flight test engineer.
It was decided not to go for a moving base simulator
because the cost of such a system is high compared to
the benefit it gives, especially when fully aerobatic
airplanes have to be simulated. In fact the longer the
accelerations to be simulated last (typical during
aerobatic maneuvers), the less realistic a moving base
system is.
Since the EFS development was connected to the
development of the new Pilatus’ trainer, it was
decided to use it also as a testbed for the avionics,
which are going to be linked to the rest of the
simulator in a short time and will allow some pilot’s
evaluation of the equipment and the HMI.
The keywords for the EFS are “flexibility” and
“reconfigurability” that allow this tool to be quickly
setup to test in advance every concept for the aircraft.
Hardware and Software description
The Pilatus Aircraft’s EFS has the external
appearance of a tandem PC-9 turboprop trainer
cockpit, rebuilt from the firewall to the rear seat
frame using, as much as possible, dismissed parts to
keep the cost as low as possible.
It is powered at the moment by four computers,
linked in a mini Ethernet network, namely:
- the host simulator computer;
- the image generator workstation;
- the control loading system computer;
- the development computer in support of the
control loading system.
3. AIAA-2000-4173
3
American Institute of Aeronautics and Astronautics
The Host computer
The host is a Pentium III PC based computer,
powered by Windows 95®, which runs the D-Six®
software.
D-Six® is a solver of the six-degrees-of-freedom
flight equations which presents a partially
reconfigurable Windows interface featuring a plotting
routine, useful for the engineering analysis, to trace
graphically the behavior of all the variables involved
in the simulation.
Fig.3 The D-Six®® simulation window.
The aeromodel is composed of the aerodynamic
database and the flight mechanics model. The first
one is assembled in D-Six®, under a certain project
name, using the tables produced from the data
gathered during wind tunnel and/or flight test
campaigns or calculated theoretically or with semi-
empirical methods.
The second one is realized with a code in C++ that
generates a Windows dynamic link library (DLL). To
“fly” an aeromodel D-Six® loads the project and the
correspondent DLL.
The C++ code allows the user to generate, specify the
functionality and control whichever simple or
complex system of the aircraft is required. This part
of the system is also where the secondary flight
controls (gear, flaps, airbrake, fuel system, etc.)
present in the cockpit are assigned to functions that
describe the airplane systems.
The Control System
Original airplane mechanical components or precisely
milled parts were adopted for the cockpit control
linkage, where low friction and minimal free play are
an issue. Behind the rear seat frame it is placed the
control loading system, which is entirely mounted on
a trolley that can be disengaged from the cockpit
stand. Onboard this trolley there are the three electric
motors that generate the forces on the controls, their
power suppliers and the amplifiers which process the
signals coming from the Control Loading Computer
(CLC), also placed on the trolley. Fokker Control
Systems provided these components. The connections
between the sticks and pedals and the electric motors
were realized using low friction and high precision
machined parts to minimize the uncorrectable free
play and histeresis.
Thanks to the solution of the detachable trolley, the
whole Control Loading System (CLS) is quickly
removable and refittable to other cockpits that have
the same connectors, requiring only the change to the
appropriate software model.
Fig.4 The Control Loading System assembly on
the trolley, fixed to the cockpit stand: the 3
motors, their power supplies and the CLC are
visible.
The CLC is a Pentium based machine powered by the
real-time operative system VX-Works, with two
datacards to communicate with the amplifiers. It
executes the engines’ control loop at 5000 Hz whilst
calculating the user’s control model at 2500 Hz.
The user’s models of the control system are aircraft
dependent and have been realized in-house, reflecting
accurately the behavior of the real systems of the
airplanes Pilatus simulate. Apart from simulating the
aerodynamic dependent forces (deriving from the
hinge moments on the control surfaces) on the
controls, it takes into account the friction, the
stretching, the free play and the inertia of every
component of the control system of the airplane.
An interesting feature of the CLS is the possibility to
modify all parameters in real-time, which allows a
work in close cooperation with the pilots, whose
movements and efforts on the controls can be traced
accurately.
The CLC calculates the forces acting on the controls
based on the data received from the host simulator
computer, like the aerodynamic pressure and the local
angles of attack, to which is linked via an UDP
protocol. It is also linked to another PC, which serves
as a controller and development machine for the
system. On this one the operator can see a graphical
representation of the system, with all the components,
the values of the parameters used by the control
system model. From this station it is possible to
monitor the movements of the controls and the forces
exerted by the pilot and modify the values of some
parameters without stopping the simulation. The
4. AIAA-2000-4173
4
American Institute of Aeronautics and Astronautics
models of the control system are written in C
language and to modify and recompile them the
simulation must be stopped to allow the loading of
the compiled code on the CLC.
The flexibility of the system allows changing the
control system model loaded in few seconds hence
giving the possibility to change quickly the airplane
flown.
The Image Generator
The generation of the out-of-the-window view is
performed by a Silicon Graphics Octane workstation
powered by two R10000 processors, with 512 Mb of
RAM and two SI graphic heads, one of which with 4
Mb of texture memory. This video channel sends the
signal to the projector placed above the cockpit while
the other channel was intended to be used to generate
a virtual instrument panel on a monitor in front of the
pilot.
Fig.5 The cockpit and the CRT projector.
The software to display the out-of-the-window view
has been realized in house and is based on
Performer®. Two terrain databases are available: one
with a low level of detail and an area of 100x100 km,
used for high altitude flight, and a smaller, more
detailed one, used for low level flight.
The Octane with the SI graphic head is fast enough to
display these terrain databases at a frame rate of 30
Hz in almost all flight conditions. The frame rate
decreases sensibly during rapid roll maneuvers at
high altitude, when many polygons of the database
pass quickly in the displayed view angle.
Considering that the EFS is used to evaluate the flight
characteristics of the aircraft, it has been decided not
to invest resources for a big and detailed terrain
database. Sometimes the pilots fly in the “deep blue”
without even seeing the terrain, concentrating on the
Head Up Display (HUD) and the data displayed. The
HUD is projected in the same channel as the out-of-
the-window view and is superimposed on the
landscape view, with the dimensions corresponding
to the angle under which the pilot sees it in the
aircraft. The symbols are the same as displayed in the
standard Pilatus PC-9 HUD but can easily be changed
to test new graphic arrangements or different data
displayed.
As the EFS has no instrumentation, the HUD, apart
from some indications in the bottom corners of the
screen, is the only mean to provide the pilot with the
flight data. To date it has proved itself sufficient to
transmit to the pilots all the data necessary for the
flight mechanics evaluation of a fully aerobatic
trainer aircraft. The solution is economic, effective
and doesn’t present the problem of collimating the
image.
Development of the Aeromodels
The term “aeromodel” designates the flight
mechanics model, which contains the information on
how to assemble the aerodynamic dataset that
describes the effects of the change of the value of
some parameters (i.e. angle of attack, sideslip angle,
linear and angular velocities and rates, etc) on the
aerodynamic coefficients.
At present the Pilatus’ EFS can mathematically
simulate four different airplanes, loading the
correspondent aeromodels: the PC-9, the PC-12, the
PC-21 P.o.C. (proof of concept, a modified PC-
7MkII) and the PC-21.
The PC-9 dataset is currently being used in the flight
training devices for this airplane operative in many
countries. The PC-12 dataset is used in a Level 6
FAA certified flight training device.
The following graphs show how much and in which
area (aerodynamics, engine, propeller) the
dimensions of the databases have increased stepping
from the model of one airplane to the next, which
testifies to the growing complexity and detail of the
models. The exception of the smaller database of the
P.o.C. in comparison to the one of the PC-12 is due to
the amount and kind of wind tunnel test data. The
data gathered for the P.o.C. was intended mainly to
study the spin behavior of the airplane.
The data are organized in 2D rows and columns text
tables; 3D and 4D data structures are realized
grouping together 2D tables.
5. AIAA-2000-4173
5
American Institute of Aeronautics and Astronautics
Fig.6 Aerodynamic data of the aeromodels.
Fig.7 Total amount of data of the aeromodels.
Validation of the Aeromodels
The validation of an aeromodel is the comparison of
how the simulated aircraft and the real one fly. It is
important to be aware of the differences between
these two to use the EFS as a proper tool for specific
goals, respecting its limitations.
At the base of using and validating an aeromodel
there is the understanding that the simulator
calculates the forces acting on an airplane, and then
its movements, hence the physical relationship cause-
effect has to be “proved”. In other words, the laws of
physics of the airplane motion drive the real flight
while simulation calculates the physics. Hence the
last one allows knowing directly, not inversely, and
instantaneously the quantities that determine the
movement of an aircraft (i.e. all the aerodynamic
coefficients, forces, accelerations).
This means that to validate an aeromodel some data
that are not usually recorded during the normal flight
testing procedures are required from the flight test
departments. This is the reason why it’s well known
that the certification of a simulator or a flight-training
device is, in a certain way, more complex than that of
the real aircraft that it represents. For the simulator it
is needed to prove that the laws of physics are
correctly represented, which in the real world is
obviously not needed.
The validation of an aeromodel is a delicate operation
that requires
- the existence of the real aircraft, adequately
instrumented, which seems obvious, but means
that the aeromodel used to develop a new aircraft
prior to its production has to “fly” without being
validated (in this case, the experience from
previous validations has a major role)
- specific data gathered during flight test
campaigns
- a pilot able to reproduce in the simulator, where
some cues may be missing, the maneuvers
performed during real flight
- for the flight characteristics, which are more
“subjective”, a pilot able to distinguish the
influence of some cues he cannot get in the EFS
from the effect of the flight mechanics
calculated.
It must be remembered also that the validating data
refer to one airplane or to a limited number of them
(the test airplanes) which are in a certain status, in
terms of number of flight hours, maintenance, etc..
The effect of this can be evidenced for example by
the fact that wear in the aircraft flight controls gives
room for free plays which are noticed by the pilot.
This can be a problem because, theoretically, the
simulator shall represent all airplanes of the same
model and hence this should be the same for the
validating data.
The Validation of the P.o.C. model
Although the amount of data available for the
aeromodel of the P.o.C. is not very large and the
quality is not optimal for the build up of an
aerodynamic database able to represent the whole
flight envelope of the aircraft, it was decided to
proceed with the validation. This was done to gain
experience and establish a clear procedure for the
aeromodel that was to come, that of the PC-21.
The P.o.C. is a PC-7MkII modified in the wing, the
tail and the engine. The aircraft is fully instrumented
and regularly used by the flight test department. This
fact afforded the availability of lots of data needed for
validation purposes.
During the validation process it was experienced that
the hardest model to get working correctly was that of
the control system. The reason is thought to be in the
many parameters (hinge moment coefficients,
frictions, free plays, etc.) whose values are difficult to
be determined exactly.
The validation of the aerodynamic database instead
was easier.
0
500
1000
1500
2000
2500
3000
3500
4000
4500
5000
PC-9 PC-12 P.o.C. PC-21
EFS Aeromodels: amount of data in Kb
Engine
Propeller
Aerodynamic
0
500
1000
1500
2000
2500
3000
3500
PC-9 PC-12 P.o.C. PC-21
EFS Aeromodels: aerodynamic data
Kb of data
# of files
6. AIAA-2000-4173
6
American Institute of Aeronautics and Astronautics
In addition to the condition of airplane trimmed for
straight flight at different airspeeds and power
settings, the validation was conducted analyzing
some maneuvers:
- stick force per G;
- rapid rolls;
- sideslips;
- looping;
- spin.
Here follow the plots of some results from the EFS
data (hollow marks) compared to the flight test.
Fig.8 Stick elevator force vs. elevator deflection.
Fig.9 Angle of attack vs. load factor.
Fig.10 Elevator deflection vs. load factor.
Fig.11 Roll rate vs. average ailerons deflection at
150 kts.
Fig.12 Ailerons stick force vs. average ailerons
deflection at 150 kts.
Fig.13 Sideslip angle vs. rudder deflection
In the following graphs, the curves less scattered are
those produced with the simulator.
0
20
40
60
80
100
120
140
160
180
200
-8 -6 -4 -2 0 2
DE (deg)
Eforce(N)
FT 130 kts
FT 200 kts
FT 250 kts
SIM 130 kts
SIM 200 kts
SIM 250 kts
0
2
4
6
8
10
12
14
16
18
20
0 1 2 3 4 5 6 7
Nz (g)
Alpha(deg)
FT 200 kts
FT 250 kts
SIM 200 kts
SIM 250 kts
-7
-6
-5
-4
-3
-2
-1
0
1
2
0 1 2 3 4 5 6 7
Nz (g)
DE(deg)
FT 130 kts
FT 200 kts
FT 250 kts
SIM 130 kts
SIM 200 kts
SIM 250 kts
-200
-150
-100
-50
0
50
100
150
200
-16 -12 -8 -4 0 4 8 12 16
Average Ail Defl [deg]
[deg/s]
FT
SIM
-180
-120
-60
0
60
120
180
-16 -12 -8 -4 0 4 8 12 16
Average Ail Defl [deg]
[N]
FT
SIM
-25
-20
-15
-10
-5
0
5
10
15
20
25
-30 -20 -10 0 10 20 30
DR (deg)
Sideslipangle(deg)
FT 100 kts
FT 250 kts
FT 310 kts
SIM 100 kts
7. AIAA-2000-4173
7
American Institute of Aeronautics and Astronautics
Fig. 14 Looping: altitude vs. time.
Fig. 15 Looping: airspeed vs. time.
Fig. 16 Looping: load factor vs. time.
Fig. 17 Looping: AoA vs time.
Fig.18 Looping: stick elevator force vs. time
Fig.19 Looping: elevator deflection vs. time.
The Performance of the EFS
The ability of the EFS to represent realistically the
behavior of an aircraft is greatly dependent on the
quality of the data available.
The P.o.C. aeromodel was built using mainly the data
gathered in a vertical wind tunnel equipped with a
rotary balance, in a range between 0° and 90° angle
of attack (AoA). The P.o.C. is hence able to
realistically simulate the stall, the post stall behavior,
the spin and the recovery from the spin. Because the
Reynolds number (Re) of the model in the wind
tunnel was lower than the one existing, this
aeromodel is representative of the real aircraft only in
a reduced flight envelope.
With the following aeromodel, the PC-21, it has been
possible to build a very detailed aerodynamic
database with the data gathered both in the vertical
wind tunnel with the rotary balance and in a bigger
wind tunnel. The last one allowed the installation of a
1:3.5 model, hence obtaining higher Reynolds
numbers, closer to the real flight conditions.
For this aeromodel the data measured in the vertical
wind tunnel range from -90° to +90° AoA, while the
data collected in the higher Re wind tunnel range
from -30° to +30° AoA. At this point it was necessary
to integrate the data coming from the two wind
tunnels into a homogeneous database. The procedure
followed was to extend the high Re data from -30° to
0
2000
4000
6000
8000
10000
12000
-5 5 15 25 35
Time (sec)
Altitude
FT
SIM
0
50
100
150
200
250
300
-5 5 15 25 35
Time (sec)
Vc(kt)
FT
SIM
0.0
1.0
2.0
3.0
4.0
5.0
-5 5 15 25 35
Time (sec)
Nz(g)
FT
SIM
-2
0
2
4
6
8
10
12
14
16
18
-5 5 15 25 35
Time (sec)
Alpha(deg)
FT
SIM
-50
0
50
100
150
200
-5 5 15 25 35
Time (sec)
Eforce(N)
FT
SIM
-6
-5
-4
-3
-2
-1
0
1
2
3
-5 5 15 25 35
Time (sec)
DE(deg)
FT
SIM
8. AIAA-2000-4173
8
American Institute of Aeronautics and Astronautics
-90° AoA and from +30° to -90° AoA using the data
from the vertical wind tunnel. The low Re data were
corrected for not very high (in absolute value) AoA to
take into account the shifting of the curves due to the
low Re. When the airflow is completely separated
from the airplane surfaces (at very high AoA) then
there is no Re correction.
Thanks to the rotary balance installed in the vertical
wind tunnel, the steady rotary data were measured.
The implementation of these data in the aeromodel
allows the simulation of the quasi-steady pre- and
post-stall flight conditions. The spin entry and
recovery are delicate points because they are not
steady conditions. For the correct simulation of these
maneuvers specific dynamic data have been gathered,
obtaining the damping derivatives and hence enabling
the description of the aircraft dynamics.
During the campaign in the big wind tunnel data were
gathered to calculate the effect of the rate of change
of the angle of attack and it will be implemented in
the future.
An interesting possibility of the EFS is to allow the
simulation of malfunctions of some systems. For
example the P.o.C. and PC-21 aeromodels allow the
study of the behavior of the aircraft with the spoilers
locked open or closed. This feature has been used to
test the capacity of the pilot in facing such an
emergency, checking the forces on the controls
needed to keep the airplane in acceptable flight
conditions. The aeromodel of the PC-12 allows a
non-symmetric flap retraction to check what are the
best actions the pilot has to take in the case of this
event happening.
Thanks to the flexible structure of the system it is
possible to introduce new features and options in a
very short time, sometime responding to the requests
in few hours.
Conclusions
In a relatively short time, less than two years, the
Aerodynamics and Flight Simulation office of Pilatus
Aircraft Ltd. has set up an engineering flight
simulator with all the features necessary to make
research and development work on the flight
mechanics characteristics of the airplanes.
The EFS is being currently used for the development
of a new aircraft investigating the behavior of the
airplane throughout the flight envelope. It is planned
to use it also during the certification phase of the PC-
21 to perform part of the flight test activity,
contributing in reducing the time-to-market of the
aircraft.
A tool like the EFS will be developed and improved
continuously to keep it ahead of the real aircraft in
order to test in advance new concepts and
modifications. In this way it fully puts into practice
the concept of a research and development tool.
