Simulink Models for Autocode Generation∗

J. S. Freudenberg

Embedded Control Systems

University of Michigan

1 Simulink Models
Suppose that you have developed a Simulink model of a virtual world, such as a wall or spring-mass system.
We have seen how to choose the parameters of the virtual world so that it has desired properties. For
example, we have seen how to choose the spring constant and inertia of the virtual spring-mass system so
that it has a desired frequency of oscillation and satisfies a maximum torque limit. We also learned how to
add damping to such a model to counteract the destabilizing effect of forward Euler integration. Once we
develop a model of the virtual world that behaves correctly in simulation, it remains to implement this world
in C code that can be executed on the S32K microprocessor. Until now we have simply written the C code
by hand, and have debugged any resulting errors as necessary. Such errors may arise from simple mistakes
in implementing the force feedback algorithm, such as using incorrect parameter values or sign errors. They
may arise in converting from physical units to units that the processor understands, such as duty cycle and
encoder counts. Other errors arise from type conversions, such as those from signed to unsigned integers of
different lengths. Furthermore, changes to the virtual world that are relatively easy to model in Simulink by
adding additional blocks may require substantial work to code in C.
The potential difficulties with hand coding control algorithms have not proven too burdensome in our lab
exercises. However, many real world applications are much more complex, and the time taken to hand code
an algorithm, with all the necessary debugging, may take months. Hence, if we already have an algorithm
that works well in simulation, it would be advantageous to be able to generate C code directly from the
Simulink model. Even if this code is not used in production, it may be used for testing on hardware, thus
enabling the rapid prototyping paradigm for embedded software design. In this approach, control algorithms
are first tested on a model of the system to be controlled. If the algorithms work correctly on the model,
then autocode generation is used to obtain C code that can be tested on the mechanical hardware, thus
enabling an additional level of testing and debugging to take place. The idea is that the algorithms will be
known to work before they are coded into C, and thus any errors that arise must be in the coding, not in
the original algorithm specification.
Consider the Simulink diagram in Figure 1. As we have seen, with appropriate values of k, Jw , b, and
T , we may successfully implement a virtual spring mass system that is a harmonic oscillator with specified
period that satisfies the limit imposed on the reaction torque. The C code required to implement this
system on the microprocessor must perform several tasks in addition to computing the reaction torque for
a given wheel position, as shown in Figure 1. Wheel position must be obtained from the quadrature decode
function of the FlexTimer. The duty cycle must be updated and sent to the PWM function of the FlexTimer
subsystem. Because wheel position comes from the FlexTimer in encoder counts, it must be converted into
degrees. The reaction torque generated by the Simulink model is in N-mm, and must be translated into
duty cycle. Variable type conversions must be performed. The FlexTimer peripheral on the S32K must be
initialized for quadrature decode and PWM, just as we initialized them when hand coding in C.
The various initialization and unit conversion tasks are tedious and error prone. We shall see that the best
way to deal with these is to write Simulink subsystems that perform these tasks correctly. It will take some
effort to do so, but once we are done, we will have a library of these subsystems that can be reused so that
∗ Revised September 17, 2019.

1
 −1

reaction torque (N−mm)

thetawddot thetawdot thetaw

T T
k 1/Jw
z−1 z−1
thetaz
Step in wheel (degrees) 1/virtual inertia Discrete−Time Discrete−Time
spring
constant Integrator Integrator1

damping

Figure 1: Discrete Simulation of Virtual Wheel and Torsional Spring with Damping.

we never have to do these low level operations again. This will free us to spend time designing virtual worlds
using the Simulink model, and then automatically creating the C code that runs on the microprocessor.
To generate C code from a Simulink model, we shall need several additional software tools. These
include Simulink Coder, a Mathworks product that generates C code from a Simulink model and Embedded
Coder, another Mathworks product that, when used in conjunction with Simulink Coder, ensures that the
generated code is compact and efficient. In addition, we shall need Simulink blocks that initialize the S32K
microprocessor and that supply device drivers for its peripherals such as the FlexTimer. These blocks are
available from the Model-Based Design Toolbox, a product of NXP.
The figures and discussion in this handout refer to Matlab version 2018a and to version 4.1 of the NXP
Model-Based Design Toolbox.

2 Bit Manipulations
We have used structures provided by NXP to access various bit-fields in S32K registers. One can also perform
bit manipulations using Simulink blocks. This is sometimes necessary when developing a Simulink model
to generate code that must interface with hardware (think of the dip switches and LEDs in the lab). For
example, Figures 2-3 illustrate a subsystem that converts a single 32-bit unsigned integer into four 8-bit
unsigned integers. The blocks used to build these figures are found in the Simulink Library Browser Menu:

- Simulink/Sources/Constant
- Simulink/Signal Attributes/Data Type Conversion
- Simulink/Ports & Subsystems/Subsystem
- Simulink/Sinks/Display

- Simulink/Logic and Bit Operations/Bitwise Operator

- Simulink/Logic and Bit Operations/Shift Arithmetic
- Simulink/Signal Routing/Mux

The same blocks may be used to build a subsystem that performs the reverse conversion, from four 8-bit
unsigned integers to a single 32-bit unsigned integer. Such a subsystem is illustrated in Figures 4-5. A more
elegant way to perform bit manipulations is through the use of Matlab S-functions to insert C code directly
into a Simulink block. We shall learn about S-functions in a subsequent handout.

2
Port Data Types
It is often convenient to have the data types of all signals displayed on the Simulink diagram. To do so, enable
the option Display/Signals & Ports/Port Data Types. The results are illustrated in Figures 2-4. Note
that there are also options to display signal dimensions (Display/Signals & Ports/Signal Dimensions),
and to denote vector valued signals with wider lines (Display/Signals & Ports/Wide Nonscalar Lines).

    


  


   
 

Figure 2: A subsystem to convert a 32 bit unsigned integer into four 8 bit unsigned integers.

Bitwise Vy = Vu
uint32 uint32 uint8
AND Qy = Qu uint8
0xFF Ey = Eu
Least significant 8 bits Shift Data Type Conversion
Arithmetic

Bitwise Vy = Vu * 2^−8
uint32 uint32 uint8
AND Qy = Qu >> 8 uint8
0xFF00 Ey = Eu
uint8
uint32 Bitwise Shift Data Type Conversion1 1
1 Operator1 Right 8 Bits Out1
In1

Bitwise Vy = Vu * 2^−16
uint32
AND Qy = Qu >> 16 uint32 uint8 uint8
0xFF0000 Ey = Eu
Bitwise Shift Data Type Conversion2
Operator2 Right 16 Bits

Bitwise Vy = Vu * 2^−24
uint32
AND Qy = Qu >> 24 uint32 uint8 uint8
0xFF000000 Ey = Eu
Shift Data Type Conversion3
Most significant 8 bits
Right 24 Bits

Figure 3: Inside the subsystem block that performs the conversion in Figure 2.

uint8 uint32 256

(0 1 0 0) In1 Out1

Constant Subsystem Display

Figure 4: A subsystem to convert four 8 bit unsigned integers into a 32 bit unsigned integer.

3 Device Driver Blocks

In order that C code generated from a Simulink model interface with the peripheral devices on the S32K, it
is necessary to use device driver blocks that are specific to these peripherals. For example, in Figure 6 is a
block that reads the 16 bit counter with which the quadrature decode function of the FlexTimer keeps track
of wheel position.
The driver block in Figure 6 may be used to develop a subsystem to convert encoder counts into wheel
angle in degrees. Such a subsystem is shown in Figures 7-8.

3
 Vy = Vu
uint32 uint32
uint32 Qy = Qu
Ey = Eu
Data Type Conversion Shift
Arithmetic
uint8
Vy = Vu * 2^8
uint8 uint32 uint32
uint32 Qy = Qu << 8
uint8 uint32
1 uint8 Ey = Eu 1
In1 Data Type Conversion1 Shift Out1
uint8 Arithmetic1
Vy = Vu * 2^16 Sum of
uint32 uint32
Qy = Qu << 16 uint32 Elements
Ey = Eu
Data Type Conversion2 Shift
Arithmetic2

Vy = Vu * 2^24
uint32 uint32
uint32 Qy = Qu << 24
Ey = Eu
Data Type Conversion3 Shift
Arithmetic3

Figure 5: Inside the subsystem block that performs the conversion in Figure 4.

Figure 6: A block to read the 16 bit FlexTimer quadrature decode counter (FlexTimer QD read.slx)

Figure 7: A subsystem to read the encoder counter from the FlexTimer and output wheel angle in degrees
(read wheel.slx).

4
 Figure 8: Inside the “Counts to Degrees” block in Figure 7.

Similarly, a subsystem may be created that converts reaction torque from N-mm to PWM duty cycle
(Figures 9-10).

Figure 9: A subsystem to input reaction torque in N-mm and update the duty cycle of the FlexTimer PWM
module (write torque.slx).

Figure 10: Inside the “Output Torque” block in Figure 9.

By replacing the step input and scope output in Figure 1 with subsystems that interface to the S32K
(as shown in Figure 11) we begin to build a Simulink model that can be used for autocode generation of a
virtual world.

4 Processor and Peripheral Initialization

Although the basic functionality of the virtual world and its interfacing are captured in Figure 11, several
items remain before it is possible to use the model for autocode generation. We need to initialize the

5
 −1 Reaction Torque

Write Reaction Torque

thetawddot thetawdot thetaw

K Ts K Ts
Haptic Wheel Angle (degrees)
k 1/Jw
z−1 z−1
thetaz
spring 1/virtual inertia Discrete−Time Discrete−Time
constant Integrator Integrator1
Read Wheel Angle

damping

Figure 11: Simulink model from Figure 1 modified to interface with the S32K144 processor
(virtual wheel drivers.slx).

microprocessor we are using, as well as the FlexTimer peripheral for quadrature decode and PWM generation.
We also need to control the timing with which the virtual world is updated; we have done this previously by
using the LPIT to generate an interrupt at a specified rate. Finally, we may need to structure the embedded
software into multiple tasks that execute at different rates, and to address the resulting shared data issues.
To initialize the processor, we shall use an additional Simulink block, depicted in Figure 12. This
block identifies the microprocessor target, the system clock speed, the C compiler used, and other system
parameters. Finally, it is necessary to set up the FlexTimer module to provide a time base for the switched
capacitor filter used to convert the PWM output of the S32K into a linear signal for the power amplifier.
This may be done using the block shown in Figure 13.

   

 
 !"
#
 $%&!"
' ()*''


( !
+ ,& - ' -./0)-
12(& +$3
(
)4&0() ) 5

Figure 12: Initializaton block for the S32K144 from the NXP Model-Based Design Toolbox (S32KInit.slx).

5 A Virtual Spring Inertia Damper System

We can now build a complete virtual world, based on the spring damper system of Figure 1, that can be
used to generate C code for the S32K. The highest level of the Simulink model is shown in Figure 14. The
purpose of the processor initialization block in this model has already been explained. Note the presence
of a block to configure the FlexTimer module to provide the time base required for the switched capacitor
filter used to convert the PWM output of the S32K into a linear signal for the power amplifier.
The model we wish to simulate must have device driver blocks added, as in Figure 11, and must be
executed with a fixed time period. To accomplish the latter, we place the model from Figure 11 in a
Triggered Subsystem block and add a Trigger block configured to execute on a function-call, as shown in
Figure 15. The trigger block causes the simulation to be updated periodically based on the Function-Call
Generator block in Figure 14, which itself executes every T seconds.

6
Figure 13: Setting up the FlexTimer PWM module to provide a time base for the switched capacitor filter
(PWM4scfilter.slx).

There is one additional difference between Figures 15 and 11. This is the presence of the Environment
Controller block, which allows the block diagram to be used either for code generation or for simulation, in
which case the input is obtained from the Step input block in Figure 15.

Figure 14: Highest Level of the Virtual Spring Mass Damper System (one virtual wheel autocode.slx).

Initializing Parameter Values with Callbacks

It is possible to configure a Simulink model so that it initializes parameter values, such as sample time T
and the spring and inertia constants, every time it starts. To do so, assign these values in the window
File/Model Properties/Model Properties/Callbacks/InitFcn. Alternatively, assign these values using
an m-file, and place the name of the m-file (without the .m suffix) inside this window. Note that the latter
option requires that the working Matlab directory be the directory containing the Simulink model and m-file.

Sorted Execution Order

When Simulink is preparing to simulate a system that contains several blocks, it must order the execution
of these blocks to account for functional dependencies between them and the times at which they need to be

7
 Figure 15: Inside the Triggered Subsystem block from Figure 14

updated. Similarly, the C code generated by Simulink Coder from a Simulink diagram must also take the flow
of execution into account. To see the order in which Simulink will update each block in a diagram, enable
the option Display/Blocks/Sorted Order Execution. The result of doing so for the simple diagram in
Figure 1 is displayed in Figure 16. Note there are two numbers on each block: the first indicates subsystem
number (in this case there is only one subsystem), the second refers to the order that the block is executed
inside that subsystem.

0:7
0:8
−1

reaction torque (N−mm)

thetawddot thetawdot thetaw
0:3 0:9 0:4 0:1
0:0 K Ts K Ts
0:2 0:6
k 1/Jw
z−1 z−1
thetaz
Step in wheel (degrees) 1/virtual inertia Discrete−Time Discrete−Time
spring
constant Integrator Integrator1

0:5

damping

Figure 16: Discrete Simulation of Virtual Wheel with Sorted Blocks.

It is instructive to work around the diagram in Figure 16 to determine the reasons for the specified block
sorting. Keep in mind that Simulink sorts blocks according to the following two principles, paraphrased from
the Simulink user’s guide:
• During each time step of the simulation, a given block must be evaluated before any other block whose
output at that time step depends upon the output of the given block at the same time step.
• Blocks whose outputs at a given time step depend only upon past inputs and initial conditions can be
evaluated in any order consistent with the previous principle.
For example, in Figure 16, the output of the step block and the rightmost discrete integrator block must be
evaluated before the output of the leftmost summing block can be computed.

6 Simulation vs. Real Time Execution

There are important differences between general Simulink simulations that we have been doing throughout
the semester, and embedded software that must execute in real time. These differences are important to

8
consider when setting up a Simulink model for code generation.
A Simulink simulation does not need to evolve in real time. For example, it does not take precisely 10
seconds to simulate 10 seconds of the behavior of the system in Figure 1. The reason is that, between each
two simulation time steps, all the computations required to update the model must be completed. If these
computations are relatively simple, they will not take the entire time interval to complete, and the simulation
can run faster than real time. On the other hand, if the computations are complex and time consuming,
they may take longer than one time step to complete, in which case the simulation runs slower than real
time. If all we care about is the correct result at the end of the simulation, then the difference between real
time and time taken to perform the simulation computations does not matter.
Simulations that must interact with the physical world, such as the virtual worlds we implement on
the S32K which must interact with a human user through the haptic interface, must evolve precisely in
real time. This means that if the computations required to update the simulation are completed relatively
quickly, then the processor is idle for the rest of the time interval between simulation updates. On the other
hand, lengthy computations may take longer than the simulation time step, thus preventing the simulation
from executing in real time. To minimize the risk of this happening, it is sometimes necessary to break a
simulation down into multiple subsystems that contain dynamics that evolve at different rates. A subsystem
with fast dynamics must be updated at a faster rate than a subsystem with much slower dynamics. As we
shall see in Section 7, it is possible to perform such a multi-rate simulation in Simulink. However, there are
some subtleties that arise when performing multirate simulations. One issue that arises when a simulation
is broken into multiple tasks is that of guarding the integrity of any data that must be shared between the
tasks. This is done through the use of rate transition blocks, which we shall illustrate in Section 7.

7 Two Virtual Spring Inertia Damper Systems

The Simulink model developed in Section 5 is relatively straightforward and makes little use of the flexibility
afforded by multirate simulations and a multi-tasking software architecture. Let us now consider a more
complex virtual world consisting of dynamical subsystems with very different time constants. It is thus
natural to simulate these subsystems at different update rates. Compare with the discussion of hardware-
in-the-loop testing in [1].
Consider a virtual world consisting of two virtual wheels connected to the haptic wheel with virtual
torsional springs and dampers. A continuous time Simulink model of such a system is shown in Figure 17.
The parameter values for the two virtual inertias and springs have been chosen so that the frequency of
oscillation of one subsystem is ten times that of the other. Suppose that we move the haptic wheel 45◦ and
hold it in this position. Then we will experience the restoring torque plotted in Figure 18.

theta_w1_ddot theta_w1_dot theta_w1

1 1
k1 1/Jw1 s s
thetaz
Step Integrator Integrator1
spring 1/virtual inertia1
constant1

Scope2

theta_w2_dddot theta_w2_dot theta_w2

1 1
k2 1/Jw2 s s
Integrator3 Integrator2
spring 1/virtual inertia2
constant2

Figure 17: Continuous time model of two virtual wheels.

9
 r e ac t ion t or q ue ( analog mode l)
1000

800

600

400

200

−200

−400

−600

−800

−1000
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 5
time, seconds

Figure 18: Restoring torque in response to a step change in haptic wheel position.

Although it should not matter for this relatively simple model, for more complex models it is advantageous
to separate the slower and faster dynamics before implementing this model on the microprocessor. The faster
portion of the model must be implemented with a smaller time step for numerical integration than that used
for the slower portion of the model. There is no need to numerically integrate the slower dynamics at the
fast rate, and doing so has the disadvantages of increasing computation time needlessly and perhaps causing
numerical roundoff errors to accumulate.
Motivated by the preceding discussion, we consider a discrete time simulation of this system using multiple
sample rates: a slow sample rate is used for the slow dynamics and a faster rate for the fast dynamics. The
model also includes damping to counteract the destabilizing effects of the forward Euler integration. The
resulting model is shown in Figure 19.

Displaying Sample Times

It is often convenient to display subsystems executing at different rates in different colors. To do so, select
the option Display/Sample Time/Colors.
The sample time associated with a Simulink block may be displayed by selecting the block, navigating to
the menu Diagram/Properties/Block Annotation, scrolling down to the property %<SampleTime> in the
left hand list, and moving this property into the right hand column.
Both sample time colors and block annotation are illustrated in Figure 19.

Rate Transition Blocks

An important feature of the Simulink diagram in Figure 19 is the presence of rate transition blocks connecting
the fast and slow subsystems of the simulation. The purpose of these blocks differs depending on whether
they are being used in a Simulink simulation, which need not execute in real time, or for autocode generation,
which does have real time constraints. When used for simulation, the blocks insure that different parts of
the simulation are evaluated in the proper order (recall our discussion of sorted ordering at the close of
Section 5). When used for autocode generation, the rate transition blocks are used to achieve integrity and
determinism of data transfers between those parts of the generated code that must execute at different rates.
To explain further, consider what happens when a fast subsystem produces data that is used by a slow
subsystem. If the computations required to update the slow subsystem cannot be completed before the fast

10
 slow subsystem

1/z 0:0
ZOH
theta1ddot theta1
0:10 0:13 0:17 0:14 theta1dot 0:11 Rate Transition1
0:1
0:12 0:16 K Ts K Ts
k1 1/Jw1
z-1 z-1
thetaz
Step
Rate Transition spring 1/virtual inertia1 Discrete-Time Discrete-Time
constant1 Integrator Integrator1
0:15 T1 T1
b1

damping1

0:9
0:8

Scope

fast subsystem

thetaz theta2ddot theta2dot theta2

0:4 0:18 0:5 0:2
0:3 0:7 K Ts K Ts
k2 1/Jw2
z-1 z-1

spring 1/virtual inertia2 Discrete-Time Discrete-Time

constant2 Integrator3 Integrator2
0:6 T2 T2
b2

damping4

Figure 19: Discrete time model of two virtual wheels.

subsystem must execute again, the output of the fast subsystem will have changed when the slow subsystem
resumes execution, and these different values of data may result in an incorrect update to the slow subsystem.
To prevent this from happening, the rate transition block acts like a sample and zero order hold operating
at the slow period, thus insuring that all calculations required to update the slow subsystem are performed
using the value of the fast subsystem output at the beginning of the slow subsystem update. (It is assumed
that the update times for each subsystem are sufficiently long that all calculations needed to update a given
subsystem can be completed before the next update of that subsystem is required.)
Consider next what happens when a slow subsystem produces data that is used by a fast subsystem. If
the slow subsystem takes longer to update than the time interval between fast subsystem updates, then the
fast subsystem may read data in the process of being changed, leading to incorrect results. Moreover, even
if the data is transferred correctly, the timing of the transfer may vary, with the result that it is not possible
to know exactly when the fast subsystem will begin to use the new data from the slow subsystem. To resolve
these issues, a rate transition block will effectively act like a delay equal to one slow update period. Hence
the fast subsystem will always work with a value of the slow subsystem that is delayed by one slow update
period.
The latency introduced in slow to fast data transfers described in the preceding paragraph is the price
paid to insure deterministic transfer timing. It is possible to configure a rate transition block so that data
protection and/or deterministic data transfer are turned off. In these cases, the generated C code will require
less memory and execute more quickly, with the downside that unpredictable results may occur.

8 Code Generation for the Two Inertia System

It is necessary to modify the Simulink model in Figure 19 if we are to use it for autocode generation. The
reason is that different parts of the model are simulated at different rates, and the C code generated from
this model must execute at corresponding rates. The first step in preparing this diagram for auto code
generation is shown in Figure 20. In this diagram, each of the virtual wheel subsystems is implemented in a
“Triggered Subsystem” block that responds to a periodic function call generator, thus providing the block

11
with a sample period. Inside each triggered subsystem block is one of the virtual wheel subsystems: the
“slow” block contains the subsystem shown in Figure 22, and the “fast” block contains the subsystem shown
in Figure 21. Note that the sample times in the discrete integrator blocks should be set to “-1”, so that the
sample time is determined by the trigger blocks.

f()
Function−Call
Generator1
Trigger()
Virtual wheel Position2

theta2 angular speed2

Scope Fast System

torque2

Triggered
Step Subsystem:
Small Inertia (Fast Subsystem)

f()
Function−Call
Generator
−1
Trigger()
Gain
Virtual wheel Position1 Scope Reaction torque
ZOH
theta1 angular speed1

Scope Slow System

Rate Transition2
torque1

Triggered
Subsystem: 1/z
Large Inertia (Slow Subsystem)

Rate Transition1

Figure 20: Two virtual wheels implemented as triggered subsystems.

3
f() torque2
Trigger
2
angular speed2
thetawddot thetawdot thetaw
K Ts K Ts
1 k2 1/Jw2 1
z−1 z−1
theta2 Virtual wheel
spring 1/virtual inertia2 Discrete−Time Discrete−Time Position2
constant2 Integrator3 Integrator2

b2

damping2

Figure 21: Fast triggered subsystem from Figure 20.

3
f() torque1
Trigger
2
angular speed1
thetawddot thetawdot thetaw
K Ts K Ts
1 k1 1/Jw1 1
z−1 z−1
theta1 Virtual wheel
spring 1/virtual inertia1 Discrete−Time Discrete−Time Position1
constant1 Integrator Integrator1

b1

damping1

Figure 22: Slow triggered subsystem from Figure 20.

12
 The Simulink diagram in Figure 20 is used only for simulation, and is functionally equivalent to that
in Figure 19. In order to modify Figure 20 for the purpose of code generation, we must add initialization
and device driver blocks. The resulting model is shown in Figures 23-24. The processor and peripheral
initialization blocks have been placed at the highest level of the model. The device driver blocks are placed
inside the fast subsystem, so that the encoder is read and the duty cycle is updated at the fast rate. The
slow subsystem in Figure 23 is identical to that in Figure 22.
Note that the torque computed by the slow subsystem must be passed to the fast subsystem, so that
the latter may compute the total reaction torque used to update the duty cycle. Similarly, the angle of the
haptic wheel, which is obtained from the FlexTimer driver block in the fast subsystem, must be passed to
the slow task so that the latter may use this information to compute the reaction torque for the virtual wheel
with the larger inertia.
When code is generated for a multirate simulation, Simulink Coder does either one of two things. If a
real time operating system (RTOS) were available, then each subsystem could be implemented as a separate
task in the RTOS, with faster tasks given higher priority. If, as in our case, an RTOS is not available,
then Simulink Coder uses overlapped interrupts to implement “pseudo-multitasking”, an execution scheme
equivalent to multitasking. Specifically, the update period for each task is assumed to be an integer multiple
of that for the fastest task. Then a timer is used to call an interrupt routine with period equal to that of
the fastest task. The interrupt routine will check to see which of the various tasks needs to be updated at
that time (the fastest task as well as any slower tasks that require updating during this time period). If the
execution time for all the tasks needing an update is longer than the period of the fastest task, then another
interrupt will occur while the current interrupt is still in progress. The current interrupt will be preempted
until the new interrupt returns, and then resumes execution.

Figure 23: Highest level of the two virtual spring inertia system for autocode generation
(two virtual wheels autocode.slx).

13
  

 
$
  



 
















 
%
 &'
    !"
 



   !#
 


 



 

 

 

Figure 24: Fast triggered subsystem for autocode generation from Figure 23.

References
[1] J. A. Ledin. Hardware-in-the-loop simulation. Embedded Systems Programming, pages 42–60, February
1999.

14