Specifications

NEWS 2012
www.lauterbach.com14
It is now common to perform simulation and verifica-
tion of designs before committing to hardware. This is
why tools such as MATLAB
®
and Simulink
®
have made
inroads as development software into the control
engineering market. It can save a lot of time and effort
if the control loop can be tested for the effects of many
variables before finalizing the design.
So what is the next step, after the control algorithm has
beenfoundthroughsimulation?Howisthissolutionin-
tegrated into the control hardware? For this, Simulink
enables you to generate code automatically. But can
you be sure that the program behaves the same way
on the control hardware as in the simulation?
Verification Approach
The Institute of Flight System Dynamics at Technische
Universität München came up with an interesting solu-
tion during development of a flight control system for a
Diamond DA42 (see figure 20).
After the control algorithms had been created and
functionally tested with Simulink, the corresponding
program code for the processor of the control hard-
ware was generated from the control blocks using the
Embedded Coder. Using a TRACE32 debugger, the
generated code was loaded into the control hardware
and functionally tested in-situ.
To determine the level of deviation between simulated
control behavior (red path) and real control behavior
(green path), but above all to confirm the numeric accu-
racy of the control hardware, a Processor-In-the-Loop
simulation(PIL) waschosen (see Figure 18). Essen-
tially, the PIL simulation is based on the specially de-
veloped Simulink blocks “PIL Send” and “PIL Receive”.
These were designed to implement communication
between Simulink and the TRACE32 Remote API.
In each run through, the flight control algorithm per-
forms a single calculation step of the discrete time
flight control on the target hardware. The Simulink
model provides the necessary input parameters. The
values calculated are returned to the Simulink model
and there supply the aircraft model. In a parallel calcu-
lation, the simulated flight control algorithm computes
the same values. The difference is then used to com-
pare the two results.
The testing in the stand resulted in an absolute de-
viation of 10
-13
a high level of consistency that was
elegantly and easily proven with this approach.
For more information about the project of the Institute of
Flight System Dynamics at the Technische Universität
München, go to
www.lauterbach.com/intsimulink.html.
TRACE32 Integration for Simulink
®
At the Embedded World show February 2012 in
Nuremberg/Germany, Lauterbach will be presenting
an even closer coupling between Simulink and Lauter-
bach’s TRACE32 debuggers.
Lauterbach has used the property of the Simulink code
generation that the code block always begins with a
comment line which contains the name and model
path for the block. These comment lines are available
after the generated code has been loaded into the
Simulation and Reality Draw Closer Together
Flight control algorithm
Target
Flight test
pattern
-
Deviation
protocol
Aircraft
model
Flight control
algorithm
PIL
Send
PIL
Rcv
TRACE32 Remote API
Simulink
®
model
Fig.18: Therealcontrolbehavior(greenpath)andthesimulatedcontrol
behavior (red path) are compared.