Question: Why are you here?

Question: What do we cover in this course?

 Introduction to Real Time Systems

What is a Real Time (RT) System?

Classification and definition of RT Systems:
◼ Hard vs. Soft Systems
◼ Event Driven systems - Interrupt vs. Polled approaches
◼ Time drive Systems

©Paul Davies. Not to be copied, used, or revised without explicit written

permission from the copyright owner. 2
 3
Real Time Systems – A Definition

◼ Unfortunately, there is no single, all embracing formal definition of what

constitutes a real-time system.

◼ Real time (RT) systems are defined informally by a set of characteristics and
properties that they exhibit, that differentiate them from other non real-
time systems such as “on-line” or “batch” systems.

◼ Such a definition is complicated by the fact that some non RT systems may
exhibit some of the same properties/characteristics of their RT cousins and
is further compounded by the fact that not all RT systems exhibit all of the
properties/characteristics listed here.

◼ If this sounds a bit vague, then remember that it is equally difficult to define
what constitutes a non real-time system.

◼ Taking all this into account, the most popular Real-time definitions, in
increasing order of importance, are listed below.
Popular Real-Time System Definitions 4

1. “A real time system is generally a control system , often embedded into

equipment so that it is not obvious that it is even a computer. It takes in
information from its environment, processes it and generates a response.”

Real World Inputs Real World Responses

Sensor Actuator
Actuator11
Sensor11

Sensor
Sensor22 Actuator
Actuator22
Real
Real
Time
Time
Sensor
Sensor33
System
System Actuator
Actuator33

Sensor
Sensornn
Actuator
Actuatornn
 5
Popular Real-Time System Definitions (cont…)

2. “ A real time system reacts, responds and alters its actions to affect
the environment in which it is placed” .

3. “A real time system implies that there is something significant and

important about its response time.”

Sensor
Sensor11 Real
Real Actuator
Actuator11 ‘T’ Response Time
Time
Time
Input ‘X’ Output ‘Y’
System
System
Input ‘X’

Processing Time ‘T’ Output ‘Y’

(A common miss-perception of a RT system is that the response time to events

should always be lightening fast. This is not necessarily true. A Real time system’s
response just has to be ‘timely’, the definition of which will vary considerably from
application to application. It could be uSec or minutes“)
 Response Times
Thermostat
depend upon Context

Heater

Temperature Control for optimum Painting preservation

Acceptable Real-Time delay: 1-2 hours

Face time Video TV + Music

Acceptable Real-Time delay: 200 ms Acceptable Real-Time Delay:15 ms
Popular Real-Time System Definitions (cont…) 7

4. “A real time system has a guaranteed, calculatable (we use the

word ‘deterministic’), worst case response time to an event under
its control.”

(That is, in theory, you should always be able to take account of all sensor, software
and hardware delays, the workload of the CPU etc. and be able to calculate under all
circumstances, what the worst case response/delay to an input signal will be.)

Note: As well as a max response time, a RT system might also specify a minimum
response time meaning that the system must not respond any earlier than that time,
or it may even quote a min-max tolerance or window in which the response should
be generated. The response time can vary each time but should fall within that
window on each and every occasion.

5. “A real time system is a system where the correct answer at the wrong
time is the wrong answer”.
 8
Examples of real-time systems

Traffic Lights Tracking the Puck Tesla Autopilot

Nuclear Power Plant Fly by wire Aircraft

Real time systems are dedicated to carrying out one well defined task. 9

Pacemaker with embedded ultra low power Microcontroller

 10

Hard Real-Time Systems

Definition: 11
◼ A hard real-time system is one where a failure to meet the specified worst
case response time leads to overall system failure.
◼ Example: Given input ‘X’ the system responds with output Y in < 10ms. If it
takes ‘10.1ms’ then the system could well fail and you are out of a job.
◼ Engine management systems in cars are some of the most demanding hard
real-time systems to meet emissions and give a smooth ride.

Engine Management System

 12
Other Examples of Hard Real Time Systems

➢ Pace maker – monitoring blood oxygen levels and delivering a pulse

(don’t want to take too long processing that output !!!).
➢ Vehicle Anti-lock braking systems (ABS),
➢ Vehicle Stability and Traction Control in cars.
➢ Auto-pilot in an aircraft or helicopter.
➢ Digital Signal Processor (DSP) such as CD/MP3 player or digital filter
(time is especially critical here if acceptable sound is to be produced.)
➢ Many games are also real time – e.g. racing car and flight simulations.

◼ In summary, hard real time systems are extremely ‘time sensitive’.

Many real-time systems are also “safety critical” where failure results in destruction of 13
the system with possible loss of life and potential damage to the environment.

Hard Real Time: Sometimes failure is not an option!

 14

• Computer (sensor) failure was implicated in the

downing of two Boeing 737 Max 8 planes : Lion Air
Flight 610 and Ethiopian Airlines Flight 302 both
crashed under similar circumstances shortly after
takeoff killing > 350 people.
• It is believed a single failed sensor led the computers
to override the pilot during take-off, forcing the plane’s
nose to pitch downwards and eventually crash.
Soft Real-Time Systems
 16
Definition:
◼ A soft real-time system implies that failure to meet a specified response time
merely results in system degradation not necessarily outright failure.

➢ A Soft Real time system’s specification will typically quote an average

response time against which degradation (not necessarily failure) can be
judged.

➢ The response time of a Soft Real Time system is thus not fixed and may
improve or degrade within acceptable limits depending upon system
loading”.

◼ Of course system degradation ultimately becomes system failure if the

response time becomes so intolerable that it no longer functions acceptably.
Example Soft Real Time Systems 17

◼ An Elevator control system.

◼ Response times vary considerably

with the time of day and number of
passengers.

◼ There is no worst case response, but

the system could be said to have
failed if all the passengers decide it
is quicker to walk instead.

◼ We might consider it to work

acceptably if 95% of passenger
requests are met within 30 seconds,
averaged over a day.
Example Soft Real Time Systems 18

▪ A Cruise control for a Car.

▪ A convenience for the driver rather

than a life or death system.

▪ Requirements dictate that the speed

of the car be maintained to +/- 2kph
of a set speed 95% of the time.

▪ Does the system fail if speed falls

momentarily by 5kph – probably not
and quite possible if going up hill with
heavy load or if some sensor detects
an impending crash.

▪ Demonstrating that soft RT systems meet

their objectives is actually more difficult
than proving the same for hard RT
systems. (Can you think why?)
Spectrum of All Software Systems 19
 20
Further Classification of Real-Time Systems

◼ Real time systems can also be classified on the basis of how they generate
their responses.

◼ There are two simple classifications here:-

➢ Event driven systems

➢ Time driven systems
 21

Event Driven Systems

 22
Event Driven, Real-Time Systems.

◼ An event driven system, is one in which the input sensor is responsible for
detecting that some important ‘event’ (e.g. a push button, or temperature
change etc) critical to the system’s success and operation has taken place.

◼ The occurrence of the event thus triggers a response from the system.

◼ For example an elevator is event driven, so is a burglar alarm, both are based
on digital inputs such as push buttons etc.

Detecting Events
◼ Events are usually detected in one of two ways.

1. Sensor generates an interrupt.

2. System ‘polls’ the status of each sensor periodically.

◼ Let’s take a look at each approach.

 Main thread ISR thread
Approach 1: Interrupts
An interrupt is an electrical input signal
generated by a sensor to inform the CPU
that an important event has occurred.

Save State

Restore State

The CPU…

• Suspends its current thread of execution

• Saves the current state of the task it was running
• Calls an interrupt handler or interrupt service routine to deal with the
event and clears interrupt
• Loads previous state and resumes original thread
Approach 1: : Interrupt Driven Sensors LED acting as
“actuator”

Interrupt
signal

Push Button
acting as
“Sensor”

Push button generates interrupt. Response is to toggle LED

 25
Advantages of Interrupt Based Event Driven Systems:-

◼ More predictable and deterministic response times, particularly useful in

hard real-time systems.

◼ Response time to each sensor is independent of the number of sensors,

(provided the system is not overloaded with interrupts).

◼ Interrupts and hence Sensors can be prioritised.

◼ Creates spare processing power. CPU is free to do other things between

interrupts.
Disadvantages to Interrupt Based, Event Driven Systems 26

◼ Requires more expensive hardware and more complex software

◼ Need sensors capable of generating an interrupt.

(not all of them can e.g. analog inputs are usually captured with an ADC.
You may need a comparator to decide if the voltage is above/below a
critical threshold and use that to generate the interrupt).

◼ Additional hardware to prioritise Interrupts from multiple sensors.

◼ System level code (i.e. interrupt handlers) to deal with the interrupt and
trigger the execution of users code able to process and respond to it.
Disadvantages to Interrupt Based, Event Driven Systems (cont….)27
◼ The use of interrupts makes systems more difficult to Test and Debug
systems. This is because

◼ Sensor Interrupts occur asynchronously to the main program/thread

execution with unpredictable frequency and timing.
(You can’t always predict when they will happen relative to the main
thread )

◼ Interrupt handlers introduce multi-threaded code to the system, where

the main program and the interrupt handler code often have to
communicate and can be notoriously difficult to write and debug.

◼ This unpredictability means that it is almost impossible to recreate the

exact circumstances that lead to a system failing. You can’t for example
single step an interrupt handler as this affects the timing of its response.
Approach 2 : Sensor Polling

The main program continuously

probes the sensors to check their
status
Is button0 yes
pressed?

no Handle
button0 event

Is button1
pressed?
Handle
button1 event

Is button2
pressed?
Handle
button2 event
…
28
 29
Advantages of Polling in Event Driven Systems

◼ Code is easier to write. Just a function main() running a loop interrogating

sensors one after the other.

◼ No need for a complex Interrupt Service Routine

◼ The resulting program is single threaded.

◼ More easily debugged.

 30
Disadvantages of Polling in Event Driven Systems

◼ Sensor events can be missed within the polling loop.

◼ Difficulty in prioritising those sensors – no way for high priority sensor to

interrupt a low priority one – depends on polling order.

◼ Adding more sensors degrades the overall system response time since it
takes longer to poll and service all the sensors as part of the main() loop.

◼ Polling consumes lots of CPU time leaving little spare for other activities.
 31
Example Polled System from APSC 160
while( continueSuperLoop() == TRUE ) {
/* get current state of switches */
switch0 = digitalRead (SWITCH0);
switch1 = digitalRead (SWITCH1);

/* respond to each switch setting */

if(switch0 == ON && switch1 == ON) {
digitalWrite (LED0, OFF);
digitalWrite (LED1, OFF);
digitalWrite (LED2, ON);
}
else if(switch0 == OFF && switch1 == ON) {
digitalWrite (LED0, OFF);
digitalWrite (LED1, ON);
digitalWrite (LED2, OFF);
}
...
...
}
 32

Time Driven Systems

Time-Driven Systems

When certain actions have to occur at specified times, or at periodic intervals

e.g. Task A has to be performed every 30ms

Task B every 40ms
Task C every 50ms

Computer usually employs a hardware timer with say 1ms interrupt precision
toINTRO
generate the timing required to trigger activities.
TO SYSTEM SOFTWARE ENGINEERING
33
 Time-Driven Systems (cont…) 34

◼ In time driven systems, the system is usually decomposed into a number of

smaller threads or processes (see next major topic).

◼ An analysis of the computation requirements is undertaken to determine if it

will be possible to schedule them so that each will always meet their
deadline.

◼ This topic is discussed later in a lecture on Rate Monotonic Scheduling (RMS).

Utilisation is
Initially all 3 tasks 80.5%
eligible to run. A
with the highest
priority is run first

Idle
Idle

Actual Task
Scheduling using
RMS
Time ms
 35

Testing Real-Time Systems

 36
Testability Issues for Real-Time Systems

◼ Testing real-time systems is difficult because of the asynchronous “real-

world” nature of events and hence it is almost impossible to predict what a
system will be doing at any one instant in time.

◼ For example, what will an elevator be doing 5 secs after we “enable” it

◼ What will an autopilot be doing 20 mins into a flight?

◼ Can we ensure we test all lines of code and all combinations of inputs.

◼ Testing is both expensive and time-consuming and most software systems

are not exhaustively tested.

◼ With new kinds of software e.g. AI and Machine learning, it’s almost
impossible to test a system completely or even understand why it failed.
This is because the software “learns” from its exposure to situations. Two
identical machines with identical software exposed to different “learning
experiences” may make different decisions.
 37
Testing Issues for Real-Time Systems (cont…)

◼ If the system should fail, it may be difficult (impossible even?) to recreate the
exact same environment that existed just prior to the failure in order to figure
out how and why the system failed.

◼ In fact when a RT system fails there may be nothing left of it to test. This why
black boxes were installed in passenger airplanes to record all sensor data and
pilot interaction so a “post-mortem” examination of the cause of failure can
be determined.
 38
Ariane 5
◼ Exploded on its maiden flight in 1996
◼ An exception occurred when a 64-bit floating point number was assigned to a
16 bit integer and it was out of range.
Therac 25 39
◼ Radiation machine used to treat cancer patients in Canada and USA
◼ Software written by someone with inadequate experience of developing real-
time, multi-threaded software and who lacked adequate testing skills.
◼ Two types of radiation(X-Rays and Electrons) could be delivered which
required different scattering hardware to be in place. Errors occurred when
the operator changed the type of radiation to be delivered but the software
did not employ software or mechanical safety interlocks to wait for correct
scattering H/W to move into place before delivering radiation. This resulted
in massive patient overdoses and even death.

See Report http://sunnyday.mit.edu/papers/therac.pdf

 40

Real world system than killed due to inadequate testing