Introduction to Computers and Programming DatorerReal-Time

i ProdukterSystems
– föreläsning 8
Eskilstuna 12 februari 2004
Dr.
Dr. Mikael
Mikael Nolin
Nolin
Real-Time Systems
Newline
Mälardalen University Information
Dr. Mikael Nolin
[email protected]
Stefan Boegård
CC Systems
”Mimer Real-Time”

Reading: lecture slides Lecture 20

May 11 2006

Volvo XC90 –
Real-Time Systems A Real-World Embedded System
• Some 35+ computers
• Heavily overloaded term • 7 networks
• Today: Real-time in
Embedded Systems
SU
UEM PDM M SUB
S3 DE
SCM V3 AUD
MMS
S2
MP1 SHM M ATM
RSM
PHM CCM
Environment SRM
MP2 ICM
V2 GSM
TC
MMM
M
ECM ICM SRS
DIM
BCM CAN-BSC BSC PAS
Sensor ES Actuator SA
S1
SWS

SWM
SHM

PSM
AEM L1
CAN-HS
S CAN-LS RE V1 ISM
S4
CPM V2
LSM
CEM DDM M

3 4
 PRS
Real-Time System: Key Concept
• What is the relation between the
• Problem: Pace of environment terms “Real-Time System” and
cannot be controlled “Embedded system”?
• The ES need to react “quick enough”
1. All Embedded Systems are Real-Time Systems
• ES need to act in “Real-Time” 2. All Real-Time Systems are Embedded Systems
– A Real-time System (RTS) 3. Some Real-Time Systems are Embedded
Environment Systems, and some Embedded Systems are
Real-Time Systems
4. In real-time I’d like to embed myself in a nice
ES warm bed (aka. I don’t know the answer)

5 6

Parallelism Parallelism (cont)

• Most RTS need to handle multiple parallel • The flow all have different timing
flow of events requirements
• Example: environment control for a meeting
• Eamples:
room
– Light should switch on/off within 0.2
• Sensors:
seconds of flipping a switch
– Temperature
– Light switch(es) – IR Intruder sensor should be polled every 5
– IR detector seconds, and alarm should sound within 8
seconds after an intruder enters the room
• Actuators:
– AC – Temperature should be at a comfortable
– Furnance level
– Lights • Sense temperature every 30 seconds.
– Intrusion alarm • Set level of AC/heating every 2 minutes.

7 8
 Parallelism (cont II) Parallelism (cont III)
• How to get computer system to handle parallel • Idea 2:
flows?
– Need to make sure that timing requirements are met. – Integrate multiple flows into one computer
• Idea 1: • Pros:
– Have one computer for each flow of input and output Used in practically
signals. – Efficient use of hardware all RTS.
• Pros: Not as bad – Saves cost (Sometimes in
– Simple and straight forward idea as it combination with
– Simplifies software architecture may seem! – Save energy Idea 1.)
• Cons: – Saves weight
– Waist of hardware resources – Lessens heat emissions
– Expensive However, the principle
– Complex connectivity is used in many • Cons: So, how is this done?
– Heavy systems to reduce – Increases software complexity
– Energy consuming
complexity.
– Heat generating
– Many source of errors Just don’t overdo it!
9 10

Tasks (aka Processes) Tasks (cont)

• Good abstraction
• Idea: Each flow is seen as a separate
• Allows partitioning of system in
task, running in parallel with other tasks.
"independent" subsystems
• Each task is an infinite loop
• Functions for each flow can be designed
and developed independently and by
different teams
Read sensors
• An operating system (OS) takes care
Calculate
Set actuators
about executing each task

Temperature Lights Intrusion detection

11 12
 Multi-tasking Multi-tasking and Real-Time
• Problem: one computer = one CPU =
execute one instruction at a time. • Tasks need to complete their execution
– How to run many parallel tasks? before
• Cannot execute tasks in parallel! – the environment changes
– Only one task at a time can be executed – timing requirements are missed
• Solution: Execute small portion of a
• Each task has a deadline.
task, and then switch to another task
– pseudoparallelism • Ideally
• If switching is done often enough, each – OS select which task to execute so that no
task will appear as if running in parallel task misses its deadline.
with the other tasks.

13 14

Scheduling Off-line scheduling

• Scheduling is:
– The process of selecting which task to • Guaranteeing deadlines is difficult
execute at what time • Idea: construct schedule before the
• In real-time systems: system is executed
– goal of scheduling is to make all tasks meet
their deadline
• Goal in desktop systems: time
– fairness, responsiveness, throughput, etc...

15 16
 Off-line scheduling (cont) Off-line scheduling (cont II)
• Terminology:
– Schedule is constructed before run-time • Traditional technique in real-time
• Off-line All these terms denote systems
– Schedule stored in table the same thing – Used for 30+ years.
• Table driven
• Today used in
– Cyclically repeated while system runs
– small and simple systems, and in
• Static cyclic scheduling
– safety critical systems
– Progress in the schedule is governed by
progress of time
• Time-triggered scheduling

17 18

Off-line scheduling (cont III) On-line scheduling

• Pros
– No OS overhead
– Very simple OS-mechanism
• OS decide which task to run
– Easy to verify that deadlines are meet • Terminology
• “Proof-by-construction”
– Predictable execution
– Schedule is constructed during run-time
• Ease system testing • On-line
• Ease system verification – Schedule may change at any time
• Cons • Dynamic scheduling
– Inflexible – Scheduling decisions are based on what
– Maybe difficult to find schedule
events takes place in the system
– May waist resources
• Blank spaces in schedule
• Event-triggered scheduling
• Often need to put in tasks too often in schedule (polling)
Progress of time is not an event, but
– May have poor responsiveness
• Difficult trade-off between excessive polling and
the firing of a timer interrupt is.
responsiveness 19 20
 WCET Period Deadline Priority
On-line scheduling (cont) 10 30 30 Hi Fixed Priority
10 40 40 Med
• Pros: Scheduling
20 50 50 Low
– Easy to add/remove tasks and update system
Deadline
– No waist-full polling is needed
– Quick response-times (for important function)
• Cons:
– Each time systems execute, a different execution
pattern may occur
• Difficult to do system testing
• Difficult to do system verification
– Larger overhead in OS and memory-usage
• Issue:
– How to guarantee that deadlines are meet?

0 10 20 30 40 50 60 time
21 22

WCET Period Deadline Priority WCET Period Deadline

10 30 30 Hi Fixed Priority 10 30 30 Earliest
10 40 40 Med 10 40 40
Scheduling Deadline First
20 50 50 Low 20 50 50

0 10 20 30 40 50 60 time 0 10 20 30 40 50 60 time
23 24
 WCET Period Deadline
10 30 30 Earliest FPS vs EDF
10 40 40
Deadline First • EDF can (often) handle higher loads and still
20 50 50
meet deadlines
• However, if EDF misses a deadline the system
may become instable (more misses)
• In FPS, if a deadline is missed its always the
lowest priority task that misses (stable
behavior)
• Support for FPS is available in “all” Real-Time
OSes
• Support for EDF is only available in research
OSes
• In both EDF and FPS method to guarantee
that deadlines are meet are available
0 10 20 30 40 50 60 time – but today not practically useful in commercial OSes
25 26