chapter 1

What is a time-triggered
embedded system?

In this introductory chapter, we consider what is meant by the phrases ‘embedded

system’ and ‘time-triggered system’ and we examine how these important areas overlap.

1.1 Introduction
Current software applications are often given one of a bewildering range of labels:

● Information system
● Desktop application
● Real-time system
● Embedded system
● Event-triggered system
● Time-triggered system

There is considerable overlap between the various areas. We will therefore briefly con-
sider all six types of application in this chapter, to put our discussions of time-triggered
embedded systems in the remainder of this book in context.

1.2 Information systems

Information systems (ISs), and particularly ‘business information systems’, represent a
huge number of applications. Although many of the challenges of information system
development are rather different from those we will be concerned with in this book, a

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

For further information about time-triggered systems, please visit: www.tte-systems.com
4 WHAT IS A TIME-TRIGGERED EMBEDDED SYSTEM?

basic understanding of such systems is useful, not least because most of the existing
techniques for real-time and embedded development have been adapted from those
originally developed to support the IS field.
As an example of a basic information system, consider the payroll application illus-
trated schematically in Figure 1.1.
This application will, we assume, be used to print the pay slips for a company, using
employee data provided by the user and stored in the system. The printing of the
cheques might take several hours: if a particularly complex set of calculations are
required at the end of a tax year, and the printing is consequently delayed by a few
minutes, then this is likely to be, at most, inconvenient. We will contrast this ‘incon-
venience’ with the potentially devastating impact of delays in a real-time application
in later examples.
ISs are widely associated with storage and manipulation of large amounts of data
stored in disk files. Implementations in file-friendly languages, such as COBOL, were
common in the 1960s and 1970s and such systems remain in widespread use, although
most such systems are now in a ‘maintenance’ phase and new implementations in
such languages are rare.
Modern IS implementations make far greater use of relational databases, accessed
and manipulated using the SQL language. Relational database technology is well
proven, safe and built on a formal mathematical foundation. While the design and
implementation of large, reliable, relational database systems is by no means a trivial
activity, the range of skills required to develop applications for use in a home or small
business is limited. As a consequence, the implementation of such small relational

Backup
store

Backup data

P60 data
Choice (text
P60 data format)
GDU
Clerk Options Payroll
System
BACS data BACS data
Clerk will Employee data (text
perform format)
backups on
ZIP disks

FIGURE 1.1 A high-level schematic view (dataflow diagram) of a simple payroll system.
Refer to Appendix A for details of this notation

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

This file may be freely redistributed provided only that this footer remains intact.
 INTRODUCTION 5

database systems has ceased to be a specialized process and relational database design
tools are now available to, and used by, many desktop computer users as part of stan-
dard ‘office’ packages.
However, new demands are being placed on the designers of information systems.
Many hospitals, for example, wish to store waveforms (for example, ECGs or auditory
evoked responses) or images (for example, X-rays or magnetic resonance images) and
other complex data from medical tests, alongside conventional text records. An exam-
ple of an ECG trace is shown in Figure 1.2.
For the storage of waveforms, images or speech relational databases systems, opti-
mized for handling a limited range of data types (such as strings, characters, integers
and real numbers), are not ideal. This has increased interest in object-oriented database
systems (’object databases’), which are generally considered to be more flexible.
Voltage

Time

FIGURE 1.2 An example of an electrocardiogram (ECG) signal

1.3 Desktop systems

The desktop / workstation environment plays host to many information systems, as
well as general-purpose desktop applications, such as word processors. A common
characteristic of modern desktop environments is that the user interacts with the
application through a high-resolution graphics screen, plus a keyboard and a mouse
(Figure 1.3).
In addition to this sophisticated user interface, the key distinguishing characteris-
tics of the desktop system is the associated operating system, which may range from
DOS through to a version of Windows or the UNIX operating system.
As we will see, the developer of embedded applications rarely has an operating sys-
tem, screen, keyboard or mouse available.

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

For further information about time-triggered systems, please visit: www.tte-systems.com
6 WHAT IS A TIME-TRIGGERED EMBEDDED SYSTEM?

Mouse
Sound
card

Desktop
Keyboard Publishing
System

High-resolution
graphics screen
Scanner

Scanner

FIGURE 1.3 An example of part of the design for a GUI-driven desktop application

Reminder
1 second (s) = 1.0 second (100 seconds) = 1000 ms.
1 millisecond (ms) = 0.001 seconds (10-3 seconds) = 1000 µs.
1 microsecond (µs) = 0.000001 seconds (10-6 seconds) = 1000 ns.
1 nanosecond (ns) = 0.000000001 seconds (10-9 seconds).

1.4 Real-time systems

Users of most software systems like to have their applications respond quickly: the dif-
ference is that in most information systems and general desktop applications, a rapid
response is a useful feature, while in many real-time systems it is an essential feature.
Consider, for example, the greatly simplified aircraft autopilot application illustrat-
ed schematically in Figure 1.4.
Here, we assume that the pilot has entered the required course heading and that the
system must make regular and frequent changes to the rudder, elevator, aileron and
engine settings (for example) in order to keep the aircraft following this path.
An important characteristic of this system is the need to process inputs and gener-
ate outputs very rapidly, on a time scale measured in milliseconds. In this case, even a
slight delay in making changes to the rudder setting (for example) may cause the plane
to oscillate very unpleasantly or, in extreme circumstances, even to crash. As a conse-
quence of the need for rapid processing, few software engineers would argue with a
claim that the autopilot system is representative of a broad class of real-time systems.
In order to be able to justify the use of the aircraft system in practice, it is not

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

This file may be freely redistributed provided only that this footer remains intact.
 INTRODUCTION 7

x, y, z = position co-ordinates
q
υ, β, ϖ = velocity co-ordinates
p = roll rate
y, β q = pitch rate Rudder
r = yaw rate δr

Elevator
δe

x, υ Aileron
δa

z, ϖ

Pitch
Yaw (rate)
(rate) Rudder
sensors
sensor

Roll
(rate) Elevator
sensor
Aircraft
Autopilot
System
Main
pilot Aileron
controls

Position Velocity Main engine

sensors sensors (fuel)
(GPS) (3 axes) controllers

FIGURE 1.4 A high-level schematic view of a simple autopilot system

enough simply to ensure that the processing is ‘as fast as we can make it’: in this situ-
ation, as in many other real-time applications, the key characteristic is deterministic
processing. What this means is that in many real-time systems we need to be able to
guarantee that a particular activity will always be completed within (say) 2 ms, or at
precisely 6 ms intervals: if the processing does not match this specification, then the
application is not simply slower than we would like, it is useless.

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

For further information about time-triggered systems, please visit: www.tte-systems.com
8 WHAT IS A TIME-TRIGGERED EMBEDDED SYSTEM?

Tom De Marco has provided a graphic description of this form of hard real-time
requirement in practice, quoting the words of a manager on a software project:

‘We build systems that reside in a small telemetry computer, equipped with all kinds of sensors to
measure electromagnetic fields and changes in temperature, sound and physical disturbance. We
analyze these signals and transmit the results back to a remote computer over a wide-band chan-
nel. Our computer is at one end of a one-meter long bar and at the other end is a nuclear device.
We drop them together down a big hole in the ground and when the device detonates, our com-
puter collects data on the leading edge of the blast. The first two-and-a-quarter milliseconds after
detonation are the most interesting. Of course, long before millisecond three, things have gone
down hill badly for our little computer. We think of that as a real-time constraint.
(De Marco, writing in the foreword to Hatley and Pirbhai, 1987)

In this case, it is clear that this real-time system must complete its recording on
time: it has no opportunity for a ‘second try’. This is an extreme example of what is
sometimes referred to as a ‘hard’ real-time system.
Note that, unlike this military example, many applications (like the aircraft system
outlined earlier), involve repeated sampling of data from the real world (via a trans-
ducer and analog-to-digital converter) and, after some (digital) processing, creating an
appropriate analog output signal (via a digital-to-analog converter and an actuator).
Assuming that we sample the inputs at 1000 Hz then, to qualify as a real-time system,
we must be able to process this input and generate the corresponding output, before
we are due to take the next sample (0.001 seconds later).
To summarize, consider the following ‘dictionary’ definition of a real-time system:

‘[A] program that responds to events in the world as they happen. For example, an automatic-pilot
program in an aircraft must respond instantly in order to correct deviations from its course. Process
control, robotics, games, and many military applications are examples of real-time systems.’
(Hutchinson New Century Encyclopedia (CD ROM edition, 1996))

It is important to emphasize that a desire for rapid processing, either on the part of
the designer or on the part of the client for whom the system is being developed, is
not enough, on its own, to justify the description ‘real time’. This is often misunder-
stood, even by developers within the software industry. For example, Waites and Knott
have stated:

‘Some business information systems also require real-time control … Typical examples include
airline booking and some stock control systems where rapid turnover is the norm.’
(Waites and Knott, 1996, p.194)

In fact, neither of these systems can sensibly be described as a real-time application.

1.5 Embedded systems

Although it is widely associated with real-time applications, the category ‘embedded
systems’, like that of desktop systems includes, for example, both real-time and, less

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

This file may be freely redistributed provided only that this footer remains intact.
 INTRODUCTION 9

commonly, information systems. The distinguishing characteristic of an embedded

application is loosely summarized in the box:

An embedded system is an application that contains at least one programmable

computer (typically in the form of a microcontroller, a microprocessor or digital signal
processor chip) and which is used by individuals who are, in the main, unaware that the
system is computer-based.

Typical examples of such embedded applications include common domestic appli-

ances, such as video recorders, microwave ovens and fridges. Other examples range
from cars through combine harvesters to aircraft and numerous defence systems.
Please note that this definition excludes applications such as ‘palm computers’ which
– from a developer’s perspective – are best viewed as a cut-down version of a desktop
computer system.
While the desktop market is driven by a need to provide ever more performance,
in order to support sophisticated operating systems and applications, the embedded
market has rather different needs. For example, recent economic, legislative and tech-
nological developments in the automotive sector mean that an increasing number of
road vehicles contain embedded systems. In some cases, such systems have been
introduced primarily as a means of reducing production costs: for example, in mod-
ern vehicles, expensive (~£600.00) multi-wire looms have now been replaced by a
two-wire controller area network (CAN) computer bus at a fraction of the cost (Perier
and Coen, 1998). In other situations, such as the introduction of active suspension
systems, the embedded systems have been introduced to improve ride quality and
handling (Sharp, 1998).
Consider a very simple example which may help to illustrate some of the require-
ments of the embedded market: the indicator light circuit for a passenger car. In this
application we need to be able to control six or more indicator lights from a switch
behind the steering wheel, allowing the driver to tell other road users that he or she
intends to turn a corner, change lane or park. For the US (and some other) markets, we
expect the indicator circuit to interact with the rear lights (so that one light flashes to
indicate the direction of a turn); in Europe, we expect indicator and rear lights to oper-
ate separately. Furthermore, in some countries, we wish to use the indicator lights as
‘parking lights’, to avoid having people run into our (parked) car at night.
The Volvo 131 (‘Amazon’) demonstrates the traditional solution to this problem.
This classic European car from the 1960s uses a considerable amount of wire and some
mechanical switches to provide indicator and braking behaviour: if we wanted to
adjust this car to operate in the US style, we would have make substantial changes to
the wiring loom. To avoid this type of expensive, labour-intensive conversion, more
modern cars use a microcontroller to provide the required behaviour. Not only does
the microcontroller solution result in a simpler, and cheaper, collection of wires, it can
also be converted between US and European indicator standards by flicking a switch
or changing a memory chip.

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

For further information about time-triggered systems, please visit: www.tte-systems.com
10 WHAT IS A TIME-TRIGGERED EMBEDDED SYSTEM?

This simple application highlights four important features of many embedded

applications.

● Like this indicator system, many applications employ microcontrollers not because
the processing is complex, but because the microcontroller is flexible and, crucially,
because it results in a cost-effective solution. As a result, many products have
embedded microcontrollers sitting almost idle for much of their operational life.
The fact that many commonly used microcontrollers are, by comparison with mod-
ern desktop microprocessors, often rather slow, is seldom of great concern.
● Unlike most microprocessors, microcontrollers are required to interact with the out-
side world, not via keyboards and graphical user interfaces, but via switches, small
keypads, LEDs and so on. The provision of extensive I/O facilities is a key driving
force for many microcontroller manufacturers.
● Like the indicator system, most embedded applications are required to execute par-
ticular tasks at precise time intervals or at particular instants of time. In this case,
for example, the indicators lights must flash on at a precise frequency and duty
cycle in order to satisfy legal requirements. This type of application is considered in
greater detail in Chapter 2.
● Unlike many desktop applications (for example) many embedded applications have
safety implications. For example, if the indicator lights fail while the car is in use,
this could result in an accident. As a result, reliability is a crucial requirement in
many embedded applications.

1.6 Event-triggered systems

Many applications are now described as ‘event triggered’ or ‘event driven’. For exam-
ple, in the case of modern desktop applications, the various running applications must
respond to events such as mouse clicks or mouse movements. A key expectation of
users is that such events will invoke an ‘immediate’ response.
In embedded systems, event-triggered behaviour is often achieved through the use
of interrupts (see following box). To support these, event-triggered system architectures
often provide multiple interrupt service routines.

What is an interrupt?

From a low-level perspective, an interrupt is a hardware mechanism used to notify a

processor that an ‘event’ has taken place: such events may be ‘internal’ events (such as
the overflow of a timer) or ‘external’ events (such as the arrival of a character through a
serial interface).
Viewed from a high-level perspective, interrupts provide a mechanism for creating
multitasking applications: that is applications which, apparently, perform more than one
▲

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

This file may be freely redistributed provided only that this footer remains intact.
 INTRODUCTION 11

▲
task at a time using a single processor. To illustrate this, a schematic representation of
interrupt handling in an embedded system is given in Figure 1.5.

Background Foreground

Time

Task 1

t1

ISR 1

t2
Task 1
t3
Task 2
t4

ISR 2

t5
Task 2

FIGURE 1.5 A schematic representation of interrupt handling in an embedded system

In Figure 1.5 the system executes two (background) tasks, Task 1 and Task 2. During the
execution of Task 1, an interrupt is raised, and an ‘interrupt service routine’ (ISR1) deals
with this event. During the execution of Task 2, another interrupt is raised, this time
dealt with by ISR2.
Note that, from the perspective of the programmer, an ISR is simply a function that
is ‘called by the microcontroller’, as a result of a particular hardware event.

1.7 Time-triggered systems

The main alternative to event-triggered systems architectures are time-triggered
architectures (see, for example, Kopetz, 1997). As with event-triggered architectures,
time-triggered approaches are used in both desktop systems and in embedded systems.
To understand the difference between the two approaches, consider that a hospital
doctor must look after the needs of ten seriously ill patients overnight, with the support
of some nursing staff. The doctor might consider two ways of performing this task:

● The doctor might arrange for one of the nursing staff to waken her, if there is a
significant problem with one of the patients. This is the ‘event-triggered’ solution.

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

For further information about time-triggered systems, please visit: www.tte-systems.com
12 WHAT IS A TIME-TRIGGERED EMBEDDED SYSTEM?

● The doctor might set her alarm clock to ring every hour. When the alarm goes off,
she will get up and visit each of the patients, in turn, to check that they are well
and, if necessary, prescribe treatment. This is the ‘time-triggered’ solution.

For most doctors, the event-triggered approach will seem the more attractive, because
they are likely to get a few hours of sleep during the course of the night. By contrast,
with the time-triggered approach, the doctor will inevitably suffer sleep deprivation.
However, in the case of many embedded systems – which do not need sleep – the
time-triggered approach has many advantages. Indeed, within industrial sectors where
safety is an obvious concern, such as the aerospace industry and, increasingly, the
automotive industry, time-triggered techniques are widely used because it is accepted,
both by the system developers and their certification authorities, that they help
improve reliability and safety (see, for example, Allworth, 1981; MISRA, 1994; Storey,
1996; Nissanke, 1997; Bates, 2000 for discussion of these issues).
The main reason that time-triggered approaches are preferred in safety-related appli-
cations is that they result in systems which have very predictable behaviour. If we revis-
it the hospital analogy, we can begin to see why this is so.
Suppose, for example, that our ‘event-triggered’ doctor is sleeping peacefully. An
apparently minor problem develops with one of the patients and the nursing staff
decide not to awaken the doctor but to deal with the problem themselves. After anoth-
er two hours, when four patients have ‘minor’ problems, the nurses decide that they
will have to wake the doctor after all. As soon as the doctor sees the patients, she rec-
ognizes that two of them have a severe complications, and she has to begin surgery.
Before she can complete the surgery on the first patient, the second patient is very
close to death.
Consider the same example with the ‘time-triggered’ doctor. In this case, because
the patient visits take place at hourly intervals, the doctor sees each patient before seri-
ous complications arise and arranges appropriate treatment. Another way of viewing
this is that the workload is spread out evenly throughout the night. As a result, all the
patients survive the night without difficulty.
In embedded applications, the (rather macabre) hospital situation is mirrored in the
event-driven application by the occurrence of several events (that is, several interrupts)
at the same time. This might indicate, for example, that two different faults had been
detected simultaneously in an aircraft or simply that two switches had been pressed at
the same time on a keypad.
To see why the simultaneous occurrence of two interrupts causes a problem, con-
sider what happens in the 8051 architecture in these circumstances. Like many micro-
controllers, the original 8051 architecture supports two different interrupt priority lev-
els: low and high. If two interrupts (we will call them Interrupt 1 and Interrupt 2) occur
in rapid succession, the system will behave as follows:

● If Interrupt 1 is a low-priority interrupt and Interrupt 2 is a high-priority interrupt:

The interrupt service routine (ISR) invoked by a low-priority interrupt can be interrupted
by a high-priority interrupt. In this case, the low-priority ISR will be paused, to allow the
high-priority ISR to be executed, after which the operation of the low-priority ISR will be

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

This file may be freely redistributed provided only that this footer remains intact.
 INTRODUCTION 13

completed. In most cases, the system will operate correctly (provided that the two ISRs do
not interfere with one another).
● If Interrupt 1 is a low-priority interrupt and Interrupt 2 is also a low-priority interrupt:
The ISR invoked by a low-priority interrupt cannot be interrupted by another low-
priority interrupt. As a result, the response to the second interrupt will be at the very least
delayed; under some circumstances it will be ignored altogether.
● If Interrupt 1 is a high-priority interrupt and Interrupt 2 is a low-priority interrupt:
The interrupt service routine (ISR) invoked by a high-priority interrupt cannot be
interrupted by a low-priority interrupt. As a result, the response to the second interrupt will
be at the very least delayed; under some circumstances it will be ignored altogether.
● If Interrupt 1 is a high-priority interrupt and Interrupt 2 is also a high-priority
interrupt:
The interrupt service routine (ISR) invoked by a high-priority interrupt cannot be inter-
rupted by another high-priority interrupt. As a result, the response to the second interrupt
will be at the very least delayed; under some circumstances it will be ignored altogether.

Note carefully what this means! There is a common misconception among the devel-
opers of embedded applications that interrupt events will never be lost. This simply
is not true. If you have multiple sources of interrupts that may appear at ‘random’
time intervals, interrupt responses can be missed: indeed, where there are several
active interrupt sources, it is practically impossible to create code that will deal cor-
rectly with all possible combinations of interrupts.

It is the need to deal with the simultaneous occurrence of more than one event that
both adds to the system complexity and reduces the ability to predict the behaviour of
an event-triggered system under all circumstances. By contrast, in a time-triggered
embedded application, the designer is able to ensure that only single events must be
handled at a time, in a carefully controlled sequence.
As already mentioned, the predictable nature of time-triggered applications makes
this approach the usual choice in safety-related applications, where reliability is a cru-
cial design requirement. However, the need for reliability is not restricted to systems
such as fly-by-wire aircraft and drive-by-wire passenger cars: even at the lowest level,
an alarm clock that fails to sound on time or a video recorder that operates intermit-
tently, or a data monitoring system that – once a year – loses a few bytes of data may
not have safety implications but, equally, will not have high sales figures.
In addition to increasing reliability, the use of time-triggered techniques can help to
reduce both CPU loads and memory usage: as a result, as we demonstrate throughout
this book, even the smallest of embedded applications can benefit from the use of this
form of system architecture.

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

For further information about time-triggered systems, please visit: www.tte-systems.com
14 WHAT IS A TIME-TRIGGERED EMBEDDED SYSTEM?

1.8 Conclusions
The various characteristics of time-triggered embedded systems introduced in this
chapter will be explored in greater depth throughout this book.
In the next chapter, we consider why ‘traditional’ software design techniques pro-
vide only limited support for the developers of this type of application and argue that
software patterns can provide a useful adjunct to existing approaches.

Copyright © 2001-2008 TTE Systems Ltd. All rights reserved.

This file may be freely redistributed provided only that this footer remains intact.