Introduction to Real-time Systems

Advanced Operating Systems (M)

Lecture 2
Introduction to Real-time Systems

• Real-time systems deliver services while meeting

some timing constraints
• Not necessarily fast, but must meet some timing deadline
• Many real-time systems are embedded as part of some larger device or
system
• Washing machine, photocopier, mobile phone, car, aircraft, industrial plant, etc.
• Representative classes: digital process control; telephony and multimedia

• Frequent requirement to validate for correctness

• Many embedded real-time systems are safety critical: if they do not
complete in a timely and correct basis, serious consequences result
• Bugs in embedded real-time systems can often be difficult or expensive to
fix: you can’t just run “software update” on a car!

2
 Example: Digital Process Control
• Controlling some device (“the plant”)
Controller using an actuator, based on sampled
Control-law sensor data
A/D D/A
•
Reference rk computation uk
input: r(t) u(t) Effective control depends on correct
control law computation, reference
A/D input, and accuracy of measurements
yk

• Time between measurements of y(t),

y(t)
r(t) is the sampling period, T
Sensor Plant Actuator
• Small T better approximates analogue control
but large T needs less processor time; if T is
too large, oscillation will result as the system
fails to keep up with changes in the input

set timer to interrupt periodically with period T;

at each timer interrupt, do
• A simple control loop is conceptually
do analogue-to-digital conversion of y(t) to get yk; simple to implement
compute control output uk based on reference rk and yk;
do digital-to-analogue conversion of uk to get u(t); • Complexity comes from multiple control loops
end do; running at different rates, and from systems
that must switch between different modes of
operation

3
Examples: Drive-by-Wire and Telephony

Example: Drive by Wire

• Real-time systems are increasingly Steering Brake Accelerator Gears

built as distributed systems

• The components of the system are Brake
actuator Controller Engine

connected via some communications area network controls

network
Wheel Engine
• E.g., a sensor that sends data to the controller sensors sensors

process over a local area network, perhaps as Control

system
part of a drive by wire car
Example: drive-by-wire controls in a car
• •! All data must be delivered
E.g., a voice-over-IP telephony system, Example:
where reliably
Packet Voice
–! Bad if you turn the steering wheel, and nothing happens
real-time speech data is transferred over a
•! Commands from control system have highest priority, then sensors and actuators, then
wide area IP network such as the Internet
control inputs

•
Copyright © 2007 University of Glasgow

These systems not only need to run a Packet

–! Anti-lock brakes have a faster response time
doesn’t skid
switched
than the driver, so prioritise to ensure the car
voice network

control law under time constraints, but must schedule and prioritise communications
•! Network
All rights reserved.

must also schedule communications

according to deadlines Example: voice-over-IP
•! Voice is digitised and sent as a sequence of packets
–! Constant spacing, every 10-30ms depending on codec
•! Strict timeliness requirement
4 –! Mouth to ear delay needs to be less than approximately 150ms
–! Packets must be played out with equal spacing
Types of Real-Time System
• Purely cyclic • Asynchronous, mostly predictable
• Every task executes periodically • Most tasks are not periodic
• Demands in resources (e.g., computing, • The time between consecutive
communication, or storage) do not vary executions of a task may vary
significantly from period to period considerably, or the variations in
resource utilisation in different periods
• Example: most digital controllers and
may be large
real-time monitors
• These variations have either bounded
• Mostly cyclic ranges or known statistics
• Most tasks execute periodically
• Asynchronous, unpredictable
• The system must also respond to some
• Applications that react to external events
external events asynchronously (e.g.,
and/or have tasks with high and variable
fault recovery and external commands)
run-time complexity
• Example: modern avionics and process
• Example: intelligent real-time control
control systems

Easier to reason about systems that are more cyclic, synchronous, and predictable

5
Implementation Considerations

• Some real-time embedded systems are complex,

implemented on high-performance hardware
• E.g., industrial plant control, avionics and flight control systems

• But, many are implemented on hardware that is low

cost, low power, and low performance, but light-
weight and robust
• E.g., consumer goods
• Often implemented in C or assembler, fitting within a few kilobytes of
memory; correctness primary concern, efficiency a close second

• We are interested in proofs of correctness of the

scheduling, and ways of raising the level of
abstraction when programming such systems
6
Reference Model for Real-time Systems

• A reference model and consistent terminology let

us reason about real-time systems
• Reference model is characterised by:
• A model that describes the applications running on the system
• A model that describes the resources available to those applications
• Scheduling algorithms that define how the applications execute and use
the resources

7
Jobs, Tasks, Processors, and Resources
• A job is a unit of work scheduled • A resource, R, is a passive entity
and executed by the system; on which jobs may depend
• A task, T, is a set of related jobs, J1, J2, • E.g., system memory, a hardware device
…, Jn that jointly provide some function
• Resources may have different types and
• If jobs occur on a regular cycle, the task sizes, but do not have a speed attribute
is termed periodic
• Resources are not consumed by usage,
• if jobs are unpredictable, the task is and can be reused multiple times
termed aperiodic (or sporadic, if the jobs
have deadlines once released) • Jobs compete for access to resources,
and may block if the resource is in use
• Jobs execute on a processor and
•
by another job
A resource is plentiful if there is enough
may depend on some resources
of it that nothing blocks waiting access –
• Processors are active devices on such resources can’t affect correctness,
and so are generally ignored
which jobs are scheduled
• E.g., threads scheduled on a CPU, data
scheduled on a transmission link
• A processor has a speed attribute, that
determines the rate of progress of jobs
executing on that processor

8
Execution Time of Jobs

• A job Ji will execute for time ei

• This is the amount of time required to complete execution of Ji when it
executes alone on the processor, and has all the resources it needs
• The value of ei depends on the complexity of the job and the speed of the
processor; it may vary on a given processor due to conditional branches
in the job, the effects of processor caches, etc.
• Execution times therefore fall into an interval [ei−, ei+]; assume we know this interval for every
real-time job, but not necessarily the actual ei
• Terminology: (x, y] is an interval starting immediately after x, continuing up to and including y
• Often, assume ei = ei+ and validate using worst-case execution times: inefficient, but safe

9
 •! Relative deadline – the maximum allowable job response time
•! Absolute deadline – the instant of time by which a job is required
Deadlines & (often
to be completed TimingcalledConstraints
simply the deadline)
–! absolute deadline = release time + relative deadline
–! Feasible interval for a job Ji is the interval (ri, di]
•! Deadlines are examples of timing constraints

Relative deadline, Di

Response time

Job, Ji
Copyright © 2006 University of Glasgow

Time
ri- ri+
Completion time
All rights reserved.

Release time, ri
Absolute deadline, di

10
Deadlines & Timing Constraints: Example

• A system to monitor and control a heating furnace

• The system takes 20ms to initialise when turned on
• After initialisation, every 100ms, the system:
• Samples and reads the temperature sensor
• Computes the control-law for the furnace to process the temperature readings, determine the
correct flow rates of fuel, air, and coolant
• Adjusts the flow rates to match the computed values

• The system can be modelled as a task, T, comprising jobs J0, J1, …, Jk, …
• The release time of Jk is 20 + (k × 100)ms
• The relative deadline of Jk is 100ms; the absolute deadline is 20 + ((k + 1) × 100)ms

Relative deadline = 100ms Slack time Absolute deadline for J2 = 320ms

0 20 120 220 320 420

J0 J1 J2 J3

11
Effective Release Times and Deadlines

• Sometimes the release time of a job may be later

than that of its successors, or its deadline may be
earlier than that specified for its predecessors
• Makes no sense: derive effective release time or effective deadline
consistent with all precedence constraints, and schedule using that
• Effective release time
• If a job has no predecessors, its effective release time is its release time
• If it has predecessors, its effective release time is the maximum of its release time and the
effective release times of its predecessors

• Effective deadline
• If a job has no successors, its effective deadline is its deadline
• It if has successors, its effective deadline is the minimum of its deadline and the effective
deadline of its successors

12
Hard vs. Soft Real-time Systems

• The firmness of timing constraints affects how we

engineer the system
• If a job must never miss its deadline, the system is hard real-time
• A timing constraint is hard is failure to meet it is considered a fatal error
• A timing constraint is hard if the usefulness of the results falls off abruptly at the deadline
• A timing constraint is hard if the user requires validation (formal proof or exhaustive simulation,
potentially with legal penalties) that the system always meets the constraint

• If some deadlines can be missed occasionally, with low probability, then

the system is described as soft real-time

• Hard and soft real-time are two ends of a spectrum

• In many practical systems, the constraints are probabilistic, and depend
on the likelihood and consequences of failure
• No system is guaranteed to always meet its deadlines: there is always
some probability of failure

13
Periodic Tasks

• A set of jobs that are executed at regular time

intervals can be modelled as a periodic task –
many real-world systems fit this model
• Each periodic task Ti is a sequence of jobs Ji,1, Ji,2, …, Ji,n
• The phase, φi, of task Ti is the release time ri,1 of the first job Ji,1
• The period, pi, of task Ti is the minimum length of time between release
times of consecutive jobs
• The execution time, ei, of task Ti is the maximum execution time of all jobs
in the task
• The utilisation of task Ti is ui = ei / pi and measures the fraction of time for
which the task executes
X
• The total utilisation of a system U = ui
i

14
 •! The hyper-period of a set of periodic tasks is the least common
Periodic Tasks: Example multiple of their periods: H = lcm(pi) for i = 1, 2, …, n
–! Time after which the pattern of job release/execution times starts to repeat,
limiting analysis needed
•! Example:
–! T1 : p1 = 3, e1 = 1
–! T2 : p2 = 5, e2 = 2

H = lcm(3, 5) = 15

J1,1 J1,2 J1,3 J1,4 J1,5

Copyright © 2006 University of Glasgow

J2,1 J2,2 J2,2 J2,3

Time
0 5 10 15 20 25 30
All rights reserved.

A system of periodic tasks repeats after the

hyper-period, H = lcm(pi) for i = 1, 2, …, n

15
Aperiodic and Sporadic Tasks

• Many real-time systems are required to respond to

unpredictable events
• These are modelled as aperiodic or sporadic jobs
• An aperiodic job has no deadline; a sporadic job has a deadline once
released
• It is often possible to characterise the inter-arrival times for such jobs
according to some probability distribution

• The presence of aperiodic and sporadic jobs

greatly complicates reasoning about a system
• Sporadic tasks make the design of a hard real-time system impossible,
unless some bounds can be placed on their inter-arrival times and relative
deadlines

16
Dynamic vs. Static Systems

• A multiprocessor system is dynamic if the jobs can

migrate between processors; it is static if (sets of)
jobs are bound to a single processor
• Expect static systems to have inferior performance
(in terms of overall response job time) compared to
dynamic systems
• But it is possible to validate static systems, whereas this is not always true
for dynamic systems; hence, most hard real time systems are static
• Results demonstrated for uniprocessor systems are applicable to each
processor of a static multiprocessor system; they are not necessarily
applicable to dynamic multiprocessor systems

17
Overview of Real-time Scheduling
• Jobs are scheduled and allocated • A schedule is feasible if it’s valid
access to resources according to and every job meets its timing
a scheduling algorithm and some constraints
resource access control protocol
• A scheduling algorithm is optimal
• A valid schedule satisfies the if it always produces a feasible
following conditions: schedule for a given set of jobs if
• Every processor is assigned at most one a feasible schedule exists
job at any time; every job is assigned to
at most one processor at once
• There are some scheduling algorithms
that will find some, but not all, feasible
• No job is scheduled before its release schedules, and so may fail to schedule a
set of jobs that some other algorithm
time
could schedule
• The total amount of processor time
assigned to each job is equal to its
maximum or actual execution time
• All the precedence and resource usage
constraints are satisfied

18
Real-time Scheduling Algorithms

• Two main classes of algorithm for scheduling real-

time tasks:
• Clock-driven algorithms are used for mostly static systems, where all
properties of all jobs are known at design time, such that offline
scheduling techniques can be used
• Priority-driven algorithms are used for more dynamic systems, with a mix
of periodic tasks and event-driven (aperiodic and/or sporadic tasks),
where the system must adapt to changing events and conditions

• Lecture 3: clock-driven scheduling

• Lectures 4-7: priority-driven scheduling

19
Further Reading

• Will focus on real-time scheduling in the next few

lectures

• Recommended reading:
• Jane W. S. Liu, "Real-Time Systems",
Prentice Hall, 2000, ISBN 0130996513

20