Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 126 2009-10-13
126 Model-Based Design for Embedded Systems
Application
Mapping
Execution platform
Network
m
1
f
1
f
2
r
1
r
2
os
1
pe
1
os
2
pe
2
m
2
τ
1
τ
2
τ

Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 127 2009-10-13
Modeling and Analysis Framework for Embedded Systems 127
TABLE 5.2
Characterization of Tasks
Task ωδπ
τ
1
044
τ
2
066
τ
3
066
τ
4
466
5.3.1 Application Model
The task graph for the application can be thought of as an abstraction of
a set of independent sequential programs that are executed on the execu-
tion platform. Each program is modeled as a directed acyclic graph of tasks
where edges indicate causal dependencies. Dependencies are shown with
solid arrows in Figure 5.5. A task is a piece of a sequential code and is con-
sidered to be an atomic unit for scheduling. A task τ
j
is periodic and is char-
acterized by a “period” π
j
, a “deadline” δ
j

(such as a shared memory or a bus)
is handled using a resource allocation protocol, which in the current ver-
sion consists of one of the following protocols: preemptive critical section,
nonpreemptive critical section, or priority inheritance. The tasks are in the
current version scheduled using either rate monotonic, deadline monotonic,
fixed priority, or earliest deadline first scheduling [Liu00]. The properties of
a processing element can be seen in Table 5.3. Allocation and scheduling are
designed in M
OVES for easy extensions, that is, new algorithms can easily be
added to the current pool.
The interaction between the operating system and the application model
is shown in Figure 5.6. The operating system model consists of a controller,
a synchronizer,anallocator,andascheduler. The controller receives ready or
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 128 2009-10-13
128 Model-Based Design for Embedded Systems
TABLE 5.3
Characterization of Processors
pe
1
pe
2
f
1
11
Scheduling RM RM
allocation PRI_INH PRI_INH
Application
Controller
Synchronizer
Allocator

dency are mapped to different processing elements. In this case, the data to
be transferred is modeled as a message task τ
m
. Message tasks have to be
transferred across the network between the processing elements. A network
is modeled in the same way as a processing element. So far, only busses have
been implemented in our model; however, it is shown in [MMV04] how
more complicated intercommunication structures, such as meshes or torus
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 129 2009-10-13
Modeling and Analysis Framework for Embedded Systems 129
networks, can be modeled. As a bus transfer is nonpreemptable, message
tasks are modeled as run-to-completion. This is achieved by having all mes-
sage tasks running on the bus, that is, the processing elements emulating the
bus, using the same resource r
m
, thereby preventing the preemption of any
message task. Intraprocessor communication is assumed to be included in
the execution time of the two communicating tasks, and is therefore mod-
eled without the use of message tasks.
5.3.3 Task Mapping
A mapping is a static allocation of tasks to processing elements of the
execution platform. This is depicted by the dashed arrows in Figure 5.5.
Suppose that the task τ
j
is mapped onto the processing element pe
i
. The “exe-
cution time,” e
ij
measured in cycles, memory footprint (“static memory,” sm

5.3.4 Memory and Power Model
In order to be able to verify that memory and power consumption stay within
given bounds, the model keeps track of the memory usage and power costs
in each cycle. Additional cost parameters can easily be added to the model as
long as the cost can be expressed in terms of the cost of being in a certain state.
The memory model includes both static memory allocation (sm), because
of program memory, and dynamic memory allocation (dm), because of data
memory of the task. The example in Figure 5.7 illustrates the memory model
for a set of tasks executing on a single processor. It shows the scheduling
and resulting memory profiles (split into static and dynamic memories). The
dynamic part is split into private data memory (pdm) needed while execut-
ing the task, and communication data memory (cdm) needed to store data
exchanged between tasks. The memory needed for data exchange between
TABLE 5.4
Characterization of Tasks on Processors
Task esmdmpw
τ
1
21 3 2
τ
2
11 7 3
τ
3
21 9 3
τ
4
31 6 4
τ
m

)
sm(τ
4
)
sm(τ
3
)
sm(τ
2
)
sm(τ
1
)
pdm(τ
3
) pdm(τ
3
)
pdm(τ
4
)
Memory usage
(c)
τ
2
τ
1
τ
3
τ

2
and τ
3
must be allocated until it has been read by τ
3
at the start of τ
3
’s
execution. When τ
3
becomes preempted, the private data memory of the task
remains allocated till the task finishes.
Currently, a simple approach for the modeling of power has been taken.
When a task is running, it uses power pw. The power usage of a task is zero
at all other times. The possible different power usages of tasks can be seen
as the heights of the execution boxes in Figure 5.7c. This approach can easily
be extended to account for different power contributions depending on the
state of the task.
5.4 Model of Computation
In the following, we will give a rather informal presentation of the model
of computation. For a formal and more comprehensive description, please
refer to [BHM08]. To model the computations of a system, the notion of
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 131 2009-10-13
Modeling and Analysis Framework for Embedded Systems 131
a “state”, which is a snapshot of the state of affairs of the individual pro-
cessing elements, is introduced. For the sake of argument, we will con-
sider a system consisting of a single processing element pe
i
and a set
of tasks τ

} is needed by τ
j
to finish its job on pe
i
of that period.
For the processing element pe
i
, the state component must record which
task τ
j
(if any) is currently executing, and for every task τ
j
∈ T
pe
i
record the
execution time e
ij
that is needed by τ
j
to finish its job in its current period.
We denote the state σ, where τ
j
is running and where there is a total of n
tasks assigned to pe
i
,asσ = (τ
j
, (e
i1

2
and τ
3
both have an offset of 2. Hence, τ
1
starts executing, and as bcet = wcet = 2, there is only one possible execution
time for τ
1
. The state then becomes σ
1
= (τ
1
, (2, 0, 0)).
TABLE 5.5
Characterization of Tasks
Task Priority ω bcet wcet π
τ
1
10223
τ
2
22124
τ
3
32126
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 132 2009-10-13
132 Model-Based Design for Embedded Systems
8
7
6

τ
1
π
1
π
1
π
1
π
2
π
3
π
2
τ
2
τ
3
Offset
Offset
(τ
2
,(2,2,2))(τ
2
,(2,1,1)) (τ
2
,(2,2,1))
(τ
1
,(2,2,2))

, (2, 2, 1)), and (τ
2
, (2, 2, 2)), which give rise to
four branches. In Figure 5.8, we will only continue the elaboration from state
(τ
2
, (2, 1, 2)).
Time t = 3: τ
2
finishes its execution. τ
3
is still ready and the first period of τ
1
has
completed initiating its second iteration, hence, τ
1
is also ready. As τ
1
has the
highest priority, it gets to execute. The state becomes (τ
1
, (2, 1, 2)).
Time t = 5: τ
1
finishes its execution. τ
3
is the only task ready, as the first period
for τ
2
has not yet finished. The state becomes (τ

to take over. However, at
this point, the second period of τ
3
starts, while τ
3
has not yet completed its job
for the first period. Hence, τ
3
will not meet its deadline and this example is not
schedulable.
This model of computation can easily be extended to a system with mul-
tiple processors. The system state then becomes the union of the states for
each processor.
A run of a system is an infinite sequence of states. We call a system
“schedulable” if for every run, each task finishes its job in all its periods.
In [BHM08], we have shown that the schedulability problem is decidable
and an upper bound on the depth of the part of the computation tree, which
is sufficient to consider when checking for schedulability, is established. An
upper bound for that depth is given by
Ω
M
+Π
H
·(1 +Σ
τ∈T
wcet
τ
)
where T is the set of all tasks, Ω
M

M
+Π
H
·(1 +Σ
τ∈T
X
wcet
τ
)
where T
X
is the set of all tasks that do not have a period starting at Ω
M
.
Example 5.3 Let us illustrate the challenge of analyzing multiprocessor systems by
a small example illustrated in Table 5.6.
We have Ω
M
= 27, Π
H
= LCM{11, 8,251}=22088, and Σ
τ∈T
X
wcet
τ
=
3+4 = 7. The upper bound on the depth of the tree is Ω
M
+Π
H

τ
3
(1, 13) 251 27
5.5 MoVES Analysis Framework
One aim of our work is to establish a verification framework, called the
“MoVES analysis framework” (see Figure 5.1), that can be used to provide
guarantees, for example, about the schedulability, of a system-level model
of an embedded system. We have chosen to base this verification framework
on timed automata [AD94] and, in particular, the U
PPAAL [BDL04,LPY97] sys-
tem for modeling, verification, and simulation. In this section, we will briefly
discuss the rationale behind this choice and give a flavor of the framework.
We refer to [BHM08] for more details.
First of all, the timed-automata model for an embedded system must be
constructed so that the transition system of this model is a refinement of
the computation-tree model of Section 5.4, that is, the timed-automata model
must be correct with respect to the model of computation.
Another design criteria is that we want the model to be easily extendible
in the sense that new scheduling, allocation, and synchronization principles
for example, could be added. We therefore structure the timed-automata
model in the same way the ARTS [MVG04,MVM07] model of the multi-
processor platform is structured (cf. Figure 5.6). This, furthermore, has the
advantage that the U
PPAAL model of the system can also be used for sim-
ulation, because an U
PPAAL trace in a direct manner reflects events on the
multiprocesser platform.
The timed-automata model is constructed as a parallel composition of
communicating timed automata for each of the components of the embedded
system. We shall now give a brief overview of the model (details are found in

 Allocator
j
 Scheduler
j
In the UPPAAL model, these timed automata communicate synchronously
over channels and over global variables. Furthermore, the procedural lan-
guage part of U
PPAAL proved particularly useful for expressing many
algorithms. For example, the implementation of the earliest deadline first
scheduling principle is directly expressed as a procedure using appropriate
data structures.
Despite that the model of computation in Section 5.4 is a discrete model in
nature, the real-time clock of U
PPAAL proved useful for modeling the timing
in the system in a natural manner, and the performance in verification exam-
ples was promising as we shall see in Section 5.6. One could have chosen a
model checker for discrete systems, such as SPIN [Hol03], instead of U
PPAAL .
This would result in a more explicit and less natural modeling of the timing
in the system. Later experiments must show whether the verification would
be more efficient.
The small example in Table 5.6 shows that verification of “real” sys-
tems becomes a major challenge because of the state explosion problem. The
M
OVES analysis framework is therefore parameterized with respect to the
U
PPAAL model of the embedded system in order to be able to experiment
with different approaches and in order to provide an efficient support for
special cases of systems. In the following, we will briefly highlight four of
these different models.

of clocks used compared to the four models mentioned above. The goal is
to have just one clock for each processing element, and achieving this, we
expect a major efficiency gain for the verification.
5.6 Using the MoVES Analysis Framework
In order to make the model usable for system designers, details of the timed-
automata model are encapsulated in the M
OVES analysis framework. The
system designer needs to have an understanding of the embedded system
model, but not necessarily of the timed-automata model. It is assumed that
tasks and their properties are already defined, and, therefore, M
OVES is only
concerned with helping the system designer configure the execution plat-
form and perform the mapping of tasks on it.
The timed-automata model is created from a textual description that
resembles the embedded system model presented in Section 5.3. M
OVES uses
U
PPAAL as back-end to analyze the user’s model and to verify properties of
the embedded system through model checking, as illustrated in Figure 5.1.
U
PPAAL can produce a diagnostic trace and MOVES transforms this trace into
a task schedule shown as a Gantt chart.
As M
OVES is a framework aimed at exploring different modeling
approaches, it is possible to change the core model such that the differ-
ent modeling approaches described in Section 5.5 can be supported. In the
following, we will give four examples of using the framework to analyze
embedded systems based on the different approaches. The first two exam-
ples focus on deterministic models, while the third and the fourth are based
on nondeterministic models.

the system.
The verification results show several properties of the system. First, the
system cannot be scheduled in the given form since it misses a deadline.
Second, at no point does the system use more than 7 units of power, but at
some point before missing the deadline, 7 units of power is used. Finally,
in regard to memory usage, it is verified that pe
1
uses 17 units of mem-
ory at some point before missing the deadline but not more, and pe
2
uses
12 units but not more. It is shown that Task 4 misses a deadline after 11
execution cycles. Note that Task 5 is the message task between Task 2 and
Task 3.
In order to explore possible improvements of the system, we attempt ver-
ification of the same system where pe
2
uses earliest deadline first scheduling.
The verification results can be seen in Figure 5.10.
First, the system is now schedulable, as can be seen by the
E<>allFinish() query being true. The system still has the same prop-
erties for power usage as with rate-monotonic scheduling used on pe
2
,but
the verification shows that at no point will the revised system (i.e., where pe
2
uses earliest deadline first) use more than 11 units of memory. Recall that the
system where pe
2
used rate-monotonic scheduling already before missing a

with a total of 103 tasks, as seen in Figure 5.11. These applications do not
together make up the complete functionality of a smart phone, but are used
as an example, where the number of tasks, their dependencies, and their tim-
ing properties are realistic. The applications and their properties in the smart
phone example originate from experiments done by Schmitz [SAHE04]. The
timing properties, the period, and the deadline of the tasks are imposed
by the application and can be seen in Table 5.7. The smart phone example
has been verified using worst-case execution times only. That is, in order to
reduce the state space, we have only considered a deterministic version of
the application where worst-case execution times equal best-case execution
times.
The execution cycles, memory usage, and power consumption of each
task depend on the processing element. These properties of the tasks have
been measured by simulating the execution of each task on different types of
processing elements (the GPP, the FPGA, and the ASIC) as seen in Table 5.7.
The execution cycles range from 52 to 266687 and the periods range from
0.02 to 0.025 seconds giving a total number of 504 tasks to be executed in the
hyper-period of the system.
The three applications have been mapped onto a platform consisting of
four general-purpose processing elements, all of type GPP0 running at 25
MHz, connected by a bus. The parallelism of the MP3-decoder has been
exploited to split this application onto two processing elements. The two
other applications run on their own processing element.
Having defined the embedded system with the application, the exe-
cution platform, and the mapping described above, the M
OVES analysis
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 139 2009-10-13
Modeling and Analysis Framework for Embedded Systems 139
τ
5

τ
22
τ
21
τ
27
τ
24
τ
23
τ
21
τ
8
τ
1
τ
7
τ
0
τ
6
τ
25
τ
26
τ
22
τ
11

τ
14
τ
13
τ
10
τ
7
τ
1
τ
16
τ
12
τ
9
τ
8
τ
11
τ
2
τ
3
τ
4
τ
5
τ
6

τ
52
τ
31
τ
30
τ
29
τ
28
τ
26
τ
27
τ
23
τ
22
τ
21
τ
20
τ
0
τ
2
τ
1
τ
3

mum memory usage and power consumption is 1500 bytes and 1000 mW.
The verification of this example takes roughly 3 h on a 64 bit Linux server
with an AMD dual-core processor with 2 GB of memory.
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 140 2009-10-13
140 Model-Based Design for Embedded Systems
TABLE 5.7
Application and pe Characteristics
Tasks/ Deadline/
Application Edges Period (s)
GSM encoder 53/80 0.020
GSM decoder 34/55 0.020
MP3 decoder 16/15 0.025
Frequency
pe (MHz)
GPP0 25
GPP1 10
GPP2 6.6
FPGA 2.5
ASIC 2.5
It is possible that better designs exist, for instance, where less power
is used. A general-purpose processor could, for example, run at a lower
frequency, or be replaced by an FPGA or an ASIC. This is, however, not the
focus of this case study.
5.6.3 Handling Nondeterministic Execution Times
When we allow a span of execution times between the best-case execution
time and the worst-case execution time of a task, the state space grows
dramatically, as explained in Section 5.4. We examine the system given
in Table 5.6 using an U
PPAAL model capturing the nondeterminism in the
choices for execution times in each period and using discretization of the

Examining the same system (i.e., adding the extra choice for execution time
wcet
τ
3
= 14) using an UPPAAL model with stopwatches, this example can now
be analyzed without the “Out of memory” error. Even though the verifica-
tion with stopwatches is using overapproximations, all the experiments we
have conducted so far with this model have provided exact results. Further-
more, the tendency for all these experiments is that memory consumption as
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 141 2009-10-13
Modeling and Analysis Framework for Embedded Systems 141
well as verification times are reduced by approximately 40% in comparison
to the previous model.
5.7 Summary
The classical real-time scheduling theory for single processor systems can-
not be applied directly to multiprocessor systems. Already in 1978, Mok and
Dertouzos [MD78] showed that the algorithms that are optimal for single
processor systems are not optimal for increased numbers of processors, and
in this chapter, we have seen that some of the apparently correct methods
lead to counterintuitive results, such as timing anomalies.
Hence, one aim of our work has been to establish a verification frame-
work, called the “MoVES analysis framework”, that can be used to provide
guarantees, for example, about the schedulability, of a system-level model of
an embedded system. We have chosen to base this verification framework
on timed automata and, in particular, the U
PPAAL system for modeling, veri-
fication, and simulation.
The framework allows us to model and analyze an embedded sys-
tem expressed as an application executing on a multiprocessor execution
platform, consisting of a set of possible different processors each running

LNCS, Vol. 3185, pp. 200–236, 2004.
[BHM08] A. Brekling, M.R. Hansen, and J. Madsen. Models and formal
verification of multipocessor system-on-chips. The Journal of Logic
and Algebraic Programming, 77(1):1–19, 2008.
[Gra69] R.L. Graham. Bounds on multiprocessor timing anomalies.
SIAM Journal of Applied Mathematics, 17(2):416–429, March
1969.
[HFK
+
07] C. Haubelt, J. Falk, J. Keinert, T. Schlichter, M. Streubühr,
A. Deyhle, A. Hadert, and J. Teich. A systemC-based design
methodology for digital signal processing systems. EURASIP
Journal on Embedded Systems, 2007(1):15–15, 2007.
[Hol03] G. J. Holzmann. The SPIN Model Checker: Primer and Reference
Manual. Addison-Wesley, Reading, MA, 2003.
[Liu00] J. W.S. Liu. Real-Time Systems. Prentice Hall, Upper Saddle River,
NJ, 2000.
[LPY97] K.G. Larsen, P. Pettersson, and W. Yi. U
PPAAL in a nutshell.
International Journal on Software Tools for Technology Transfer,
1(1–2):134–152, October 1997.
[MD78] A.K. Mok and M.L. Dertouzos. Multiprocessor scheduling in a
hard real-time environment. In Proceedings of the Seventh IEEE
Texas Conference on Computer Systems, Houston, TX, 1978.
[MMV04] J. Madsen, S. Mahadevan, and K. Virk. Network-centric system-
level model for multiprocessor soc simulation. In J. Nurmi,
H. Tenhunen, J. Isoaho, and A. Jantsch (editors), Interconnect-
Centric Design for Advanced SoC and NoC, Chapter 13, pp. 341–365.
Kluwer Academic Publishers/Springer Publishers, the Nether-
lands, July 2004.

puting Systems, Hong Kong, pp. 38–45, 1996.
Nicolescu/Model-Based Design for Embedded Systems 67842_C005 Finals Page 144 2009-10-13
Nicolescu/Model-Based Design for Embedded Systems 67842_C006 Finals Page 145 2009-10-1
6
TrueTime: Simulation Tool for Performance
Analysis of Real-Time Embedded Systems
Anton Cervin and Karl-Erik Årzén
CONTENTS
6.1 Introduction 146
6.1.1 Related Work 148
6.1.2 Outline of the Chapter 149
6.2 TimingandExecutionModels 150
6.2.1 Implementation Overview 150
6.2.2 Kernel Simulators 151
6.2.3 Network Simulators 152
6.3 KernelBlockFeatures 152
6.4 NetworkBlockFeatures 155
6.4.1 Wireless Networks 155
6.5 Example:ConstantBandwidthServer 156
6.5.1 Implementation of CBS in TrueTime 156
6.5.2 Experiments 157
6.6 Example: Mobile Robots in Sensor Networks 159
6.6.1 Physical Scenario Hardware . 161
6.6.2 Scenario Hardware Models 161
6.6.3 TrueTime Modeling of Bus Communication 164
6.6.4 TrueTime Modeling of Radio Communication 164
6.6.5 Complete Model 165
6.6.6 Evaluation 167
6.7 Example:NetworkInterfaceBlocks 168
6.8 LimitationsandExtensions 170

simple embedded control systems often contain a multitasking real-time
operating system with the controllers implemented as one or several tasks
executing on a microcontroller. The operating system typically uses concur-
rent programming to multiplex the execution of the various tasks. The CPU
time and, in the case of networked control loops, the communication band-
width can, hence, be viewed as shared resources for which the tasks compete.
Sampled control theory normally assumes periodic sampling and negli-
gible or constant input–output latencies. When a controller is implemented
as a task in a real-time operating system executing on a computing platform
with small resource margins, this can normally not be achieved. Preemp-
tions by higher-priority tasks or interrupt handlers, blockings caused by
accesses to mutually exclusive resources, cache misses, etc., cause jitter
in sampling intervals and input–output latencies. Likewise, for networked
control systems, medium access delays, transmission delays, and network
interface delays cause variable communication latencies.
Simulation is a powerful technique that can be used at several stages
of system development. For resource-constrained embedded control sys-
tems it is important to be able to include the timing effects caused
by the implementation platform in the simulation. TrueTime [4,11,17] is
a MATLAB
R

/Simulink
R

-based (see [23]) simulation tool that has been
developed at Lund University since 1999. It provides models of multitask-
ing real-time kernels and networks that can be used in simulation models for
networked embedded control systems.
Nicolescu/Model-Based Design for Embedded Systems 67842_C006 Finals Page 147 2009-10-1

modifying a real kernel.
• TrueTime can be used for gathering various execution statistics (e.g.,
input–output latency) and various scheduling events (e.g., deadline
overruns). Measurements can be logged to a file and then analyzed
in MATLAB.
6.1.1 Related Work
There exist today a large number of general network simulators. One of the
most well-known is ns-2 [25], which is a discrete-event simulator for both
wired and wireless networks with support for, for example, the TCP, the
UDP, routing, and multicast protocols. It also supports simple movement
models for mobile applications, where the positions and velocities of nodes
may be specified in a script. It should be noted that the default radio model
in ns-2 is very simplistic (even more simplistic than TrueTime’s), although
more accurate physical layer models may be implemented by the user [13].
Another discrete-event computer network simulator is OMNeT++ [27]. It
contains detailed IP, TCP, and FDDI protocol models and several other sim-
ulation models (file system simulator, Ethernet, framework for simulation of
mobility, etc.).
Compared to the simulators above, the network simulation part in
TrueTime is quite simplistic. However, the strength of TrueTime is the
co-simulation facilities that makes it possible to simulate the latency-related
aspects of the network communication in combination with the node com-
putations and the dynamics of the physical environment. Rather than basing
the co-simulation tool on a general network simulator and then trying to
extend this with additional co-simulation facilities, the approach has been
to base the co-simulation tool on a powerful simulator for general dynamical
systems (i.e., Simulink), and then add support for simulation of real-time ker-
nels and the latency aspects of network communication to this. An additional
advantage of this approach is the possibility to make use of the wide range
of toolboxes that is available for MATLAB/Simulink, for example, support

real-time kernel simulation.
The SimEvents
R

2 toolbox [12] is a discrete-event simulator that has been
embedded in Simulink in a way that is quite similar to TrueTime. The sim-
ulation engine in SimEvents is driven by an event calendar where future
events are listed in order of the scheduled times. In addition to the traditional
signal-based communication between blocks, SimEvents also adds entities.
An entity corresponds to an object that is passed between different blocks,
modeling, for instance, a message in a communication network. SimEvents
provides blocks for generating entities, queue blocks, server blocks, routing
blocks, control-flow control blocks, timer and counter blocks, and blocks for
interfacing the SimEvents part of the simulation with the ordinary Simulink
model. Using a queue and a server block it is possible to create a simple
model of a CPU. It is also possible to model various types of network pro-
tocols (e.g., CAN and Ethernet). The major difference between TrueTime
and SimEvents is that SimEvents is primarily aimed at discrete queue- and
server-system modeling, whereas TrueTime is aimed at models of real-time
kernels and real-time networks. SimEvents has no explicit notion of tasks and
task codes. On the other hand, TrueTime is not very well suited for modeling
of pure queueing systems.
6.1.2 Outline of the Chapter
The rest of this chapter is outlined as follows. In Section 6.2, we introduce the
underlying timing and execution models of TrueTime. Sections 6.3 and 6.4
provide introductions to the kernel block and network block functionalities.
Nicolescu/Model-Based Design for Embedded Systems 67842_C006 Finals Page 150 2009-10-1
150 Model-Based Design for Embedded Systems
We then provide three larger examples in Sections 6.5 through 6.7. Cur-
rent limitations and possible future extensions of TrueTime are discussed in

}
ssGetNonsampledZCs(S)[0] = nextHit - t;
}
The timing scheme used introduces a small delay between the block
inputs and outputs that depends on the Simulink-solver settings (1.5·10
−15
s
by default). At the same time, the scheme allows blocks to be connected in a
circular fashion without creating algebraic loops.