IT-606 Embedded Systems (Software)

About This Presentation

Title:

IT-606 Embedded Systems (Software)

Description:

IT-606 Embedded Systems (Software) Real-Time Support Krithi Ramamritham S. Ramesh Kavi Arya KReSIT/ IIT Bombay – PowerPoint PPT presentation

Number of Views:122

Avg rating:3.0/5.0

Slides: 111

Provided by: krithi

Category:

more less

Transcript and Presenter's Notes

Title: IT-606 Embedded Systems (Software)

1
IT-606Embedded Systems(Software)
Real-Time Support

Krithi Ramamritham
S. Ramesh
Kavi Arya
KReSIT/ IIT Bombay

2
Functional Design Mapping
SourceIan Phillips, ARM VSIA 2001
3
What is real about real-time?

computer world
e.g., PC
average response for user
Interactive
occasionally longer
reaction user annoyed
computer controls speed of user
computer time

real world
Industrial system, airplane
environment has own speed
reaction too slow deadline miss
reaction damage, pot. loss of human life
computer must follow speed of environment
real-time

4
Real-Time Systems

A real-time system is a system that reacts to
events in the environment by performing
predefined actions

within specified time intervals.
5
Flight Avionics

CLIENT SERVER

Constraints on responses to pilot inputs,
aircraft state updates
6

Constraints
Keep plastic at proper temperature (liquid, but
not boiling)
Control injector solenoid (make sure that the
motion of the piston reaches the end of its
travel)

7
Real-Time Systems Properties of Interest

Safety Nothing bad will happen.
Liveness Something good will happen.
Timeliness Things will happen on time -- by
their deadlines, periodically, ....

8
In a Real-Time System.
Correctness of results depends on valueand its
time of delivery

correct value delivered too late is incorrect
e.g., traffic light light must be green when
crossing, not enough before
Real-time
(Timely) reactions to events as they occur,
at their pace(real-time) system (internal)
time same time scale as environment (external)
time

9
Performance Metrics in Real-Time Systems

Beyond minimizing response times and increasing
the throughput
achieve timeliness.
More precisely, how well can we predict that
deadlines will be met?

10
Types of RT Systems

Dimensions along which real-time activities can
be categorized
how tight are the deadlines?
--deadlines are tight when
laxity (deadline -- computation time) is
small.
how strict are the deadlines?
what is the value of executing an activity
after its deadline?
what are the characteristics of environment? how
static or dynamic must the system be?

11
Hard, soft, firm

Hard -- result useless or dangerousif deadline
exceeded

Soft -- result of some - lower value if deadline
exceeded

Firm -- If value drops to zero at deadline

12
Examples

Hard real time systems
Aircraft
Airport landing services
Nuclear Power Stations
Chemical Plants
Life support systems

Soft real time systems
Mutlimedia
Interactive video games

13
Real-Time Items and Terms

Task
program, perform service, functionality
requires resources, e.g., execution time
Deadline
specified time for completion of, e.g., task
time interval or absolute point in time
value of result may depend on completion time

14
Plan

Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Applications
Scheduling in Real-time systems
Operating System Approaches

15
Timing Constraints

Real-time means to be in time --- how do we know
something is in time?how do we express that?
Timing constraints are used to specify temporal
correctness finish assignment by 2pm,
be at station before train departs.
A system is said to be (temporally) feasible, if
it meets all specified timing constraints.
Timing constraints do not come out of thin
airdesign process identifies events, derives
models, and finally specifies timing constraints

16
Overall Picture
17

Periodic
activity occurs repeatedly
e.g., to monitor environment values, temperature,
etc.

period
18

Aperiodic
can occur any time
no arrival pattern given

aperiodic
aperiodic
19

Sporadic
can occur any time, but
minimum time between arrivals

mint
sporadic
20
Who initiates (triggers) actions?

Example Chemical process
controlled so that temperature stays below danger
level
warning is triggered before danger point
so that cooling can still occur
Two possibilities
action whenever temp raises above warn-- event
triggered
look every fixed time interval
action taken when temp above warn
-- time triggered

21
t
time
TT
ET
22
t
time
TT
ET
23
ET vs TT

Time triggered
Stable number of invocations
Event triggered
Only invoked when needed
High number of invocation and computation demands
if value changes frequently

24
Slow down the environment?

Importance
which parts of the system are important?
importance can change over timee.g., fuel
efficiency during emergency landing
Flow controlwho has control over speed of
processing, who can slow partner down?
environment
computer system
RT environment cannot be slowed down

25
Other Issues to worry about

Meet requirements -- some activities may run
only
after others have completed - precedence
constraints
while others are not running - mutual exclusion
within certain times - temporal constraints
Scheduling
planning of activities, such that required timing
is kept
Allocation
where should a task execute?

26
Plan

Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Application Coding
Scheduling in Real-time systems
Operating System Approaches

27
A Typical Real time system
Temperature sensor
Input port
CPU
Memory
Output port
Heater
28
Code for example
While true do read temperature sensor if
temperature too high then turn off heater
else if temperature too low
then turn on heater
else nothing
29
Comment on code

Code is by Polling device (temperature sensor)
Code is in form of infinite loop
No other tasks can be executed
Suitable for dedicated system or sub-system only

30
Extended polling example
Heater 1
Conceptual link
Temperature Sensor 1
Task 1
Heater 2
Temperature Sensor 2
Task 2
Computer
Heater 3
Task 3
Temperature Sensor 3
Temperature Sensor 4
Heater 4
Task 4
31
Polling

Problems
Arranging task priorities
Round robin is usual within a priority level
Urgent tasks are delayed

32
Interrupt driven systems

Advantages
Fast
Little delay for high priority tasks
Disadvantages
Programming
Code difficult to debug
Code difficult to maintain

33
How can we monitor a sensor every 100 ms
Initiate a task T1 to handle the
sensor T1 Loop Do sensor task T2 Schedule
T2 for 100 ms Note that the time could be
relative (as here) or could be an actual time -
there would be slight differences between the
methods, due to the additional time to execute
the code.
34
An alternative
Initiate a task to handle the sensor T1 T1 Do
sensor task T2 Repeat Schedule T2 for n 100
ms nn1 There are some subtleties here...
35
Clock, interrupts, tasks
Interrupts
Clock
Processor
Examines
Job/Task queue
Task 1
Task 3
Task 2
Task 4
Tasks schedule events using the clock...
36
Flight Simulator

CLIENT SERVER

37
Time Periods to meet Timing Requirements

CLIENT SERVER

Requirement
Choice Made
Rationale
38
Time Periods to meet Timing Requirements

CLIENT SERVER

Requirement
Choice Made
Rationale
39
Time Periods to meet Timing Requirements

40
Plan

Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Applications
Scheduling in Real-time systems
Operating System Approaches

41
Why is scheduling important?

Definition
A real-time system is a system that reacts to
events in the environment by performing
predefined actions within specified time
intervals.

42
Schedulability analysis

a.k.a. feasibility checking
check whether tasks will meet their
timing constraints.

43
Scheduling Paradigms

Four scheduling paradigms emerge, depending on
whether a system performs schedulability analysis
if it does,
whether it is done statically or dynamically
whether the result of the analysis itself
produces a schedule or plan according to which
tasks are dispatched at run-time.

44
1. Static Table-Driven Approaches

Perform static schedulability analysis by
checking if a schedule is derivable.
The resulting schedule (table) identifies the
start times of each task.
Applicable to tasks that are periodic (or have
been transformed into periodic tasks by well
known techniques).
This is highly predictable but, highly
inflexible.
Any change to the tasks and their characteristics
may require a complete overhaul of the table.

45
2.Static Priority Driven Preemptive approaches

Tasks have -- systematically assigned -- static
priorities.
Priorities take timing constraints into
account
e.g. rate-monotonic
the lower the period, the higher the priority.
Perform static schedulability analysis but no
explicit schedule is constructed
RMA - Sum of task Utilizations lt ln 2.
Task utilization computation-time / Period
At run-time, tasks are executed
highest-priority-first, with preemptive-resume
policy.
When resources are used, need to compute
worst-case blocking times.

46
Static Priorities Rate Monotonic Analysis

presented by Liu and Layland in 1973
Assumptions
Tasks are periodic with deadline equal to
period.Release time of tasks is the period start
time.
Tasks do not suspend themselves
Tasks have bounded execution time
Tasks are independent
Scheduling overhead negligible

47
RMA Design Time vs. Run Time

At Design Time
Tasks priorities are assigned according to their
periods shorter period means higher priority

48
RMA Design Time vs. Run Time

Schedulability test
Task set is schedulable if
Very simple test, easy to implement.
Run-time
The ready task with the highest priority is
executed.

RMA Example
taskset t1, t2, t3, t4
t1 (3, 1)
t2 (6, 1)
t3 (5, 1)
t4 (10, 2)
The schedulability test
1/3 1/6 1/5 2/10 4 (2(1/4) - 1) ?
0.9 lt 0.75 ?
. not schedulable

RMA
A schedulability test is
Sufficient
there may exist tasksets that fail the test,
but are schedulable
Necessary
tasksets that fail are (definitely) not
schedulable
The RMA schedulability test is sufficient, but
not necessary.
When periods are harmonic,
i.e., multiples of each other,
utilization can be 1.

51
Exact RMA

by Joseph and Pandya, based on critical instance
analysis
(longest response time of task, when it is
released at same time as all higher priority
tasks)

What is happening at the critical instance?
Let T1 be the highest priority task. Its response
time
R1 C1 since it cannot be preempted
What about T2 ?R2 C2 delays due to
interruptions by T1.
Since T1 has higher priority, it has
shorter period. That means it will interrupt T2
at least once, probably more often.
Assume T1 has half the period of T2, R2 C2
2 x C1

53
Exact RMA.

In general
Rni denotes the nth iteration of the response
time of task i
hp(i) is the set of tasks with higher priority as
task i

54
Example - Exact Analysis

Let us look at our example, that failed the pure
rate monotonic test, although we can schedule it
Exact analysis says so.
R1 1 easy
R3, second highest priority taskhp(t3) T1
R3 2

R2, third highest priority taskhp(t2) T1 ,T3
R2 3

R4, third lowest priority taskhp(t4) T1 ,T3
,T2
R4 9
Response times of first instances of all tasks
lt their periods
gt taskset feasible under RM scheduling

57
3. Dynamic Planning based Approaches

Feasibility is checked at run-time -- a
dynamically arriving task is accepted only if it
is feasible to meet its deadline.
Such a task is said to be guaranteed to meet its
time constraints
One of the results of the feasibility analysis
can be a schedule or plan that determines start
times
Has the flexibility of dynamic approaches with
some of the predictability of static approaches
If feasibility check is done sufficiently ahead
of the deadline, time is available to take
alternative actions.

58
4. Dynamic Best-effort Approaches

The system tries to do its best to meet
deadlines.
But since no guarantees are provided, a task may
be aborted during its execution.
Until the deadline arrives, or until the task
finishes, whichever comes first, one does not
know whether a timing constraint will be met.
Permits any reasonable scheduling approach, EDF,
Highest-priority,

59
Cyclic scheduling

Ubiquitous in large-scale dynamic real-time
systems
e.g., space shuttle, LCA
Combination of both table-driven scheduling and
priority scheduling.
Tasks are assigned one of a set of harmonic
periods.
Within each period, tasks are dispatched
according to a table that just lists the order in
which the tasks execute.

Slightly more flexible than the table-driven
approach
no start times are specified
In many actual applications, rather than making
worse-case assumptions, confidence in a cyclic
schedule is obtained by very elaborate and
extensive simulations of typical scenarios.

61
Plan

Special Characteristics of Real-Time Systems
Real-Time Constraints
Canonical Real-Time Applications
Scheduling in Real-time systems
Operating System Approaches

62
Real-Time Operating Systems

Support process management and synchronization,
memory management, interprocess communication,
and I/O.
Three categories of real-time operating systems
small, proprietary kernels.
e.g. VRTX32, pSOS, VxWorks
real-time extensions to commercial timesharing
operatin systems.
e.g. RT-Linux, RT-NT
research kernels
e.g. MARS, ARTS, Spring, Polis

63
Real-Time Applications Spectrum
Hard
Real-Time Operating System
VxWorks, Lynx, QNX, ...
Intime, HyperKernel, RTX
Windows CE
General-Purpose Operating System
Linux, NT
Soft
64
Real-Time Applications Spectrum
Hard
Real-Time Operating System
VxWorks, Lynx, QNX, ... Intime, HyperKernel, RTX
Windows CE
Linux, NT
General-Purpose Operating System
Soft
65
Embedded (Commercial) Kernels

Stripped down and optimized versions of
timesharing operating systems.
Intended to be fast
a fast context switch,
external interrupts recognized quickly
the ability to lock code and data in memory
special sequential files that can accumulate
data at a fast rate

To deal with timing requirements
a real-time clock with special alarms and
timeouts
bounded execution time for most primitives
real-time queuing disciplines such as earliest
deadline first,
primitives to delay/suspend/resume execution
priority-driven best-effort scheduling mechanism
or a table-driven mechanism.
Communication and synchronization via mailboxes,
events, signals, and semaphores.

67
Real-Time Extensions to General Purpose
Operating Systems

E.g., extending LINUX to RT-LINUX, NT to RT-NT
Advantage
based on a set of familiar interfaces
(standards) that speed development and facilitate
portability.
Disadvantages
Too many basic and inappropriate underlying
assumptions still exist.

68
Windows NT -- for RT applications?

Scheduling and priorities
Preemptive, priority-based scheduling

non-degradable priorities

priority adjustment
No priority inheritance
No priority tracking
Limited number of priorities
No explicit support for guaranteeing timing
constraints

69
NT Thread Priority Process class level
70
Typical Scheduling

Threads scheduled by executive.
Priority based preemptive scheduling.

71
Windows NT -- for RT applications? (contd.)

Quick recognition of external events
Priority inversion due to Deferred Procedure
Calls (DPC)
I/O management
Timers granularity and accuracy
High resolution counter with resolution of 0.8
?sec.
Periodic and one shot timers with resolution of 1
msec.
Rich set of synchronization objects and
communication mechanisms.
Object queues are FIFO

72
Linux for RT apps?

Linux (and its Real Time versions) are free!!
Linux (and its Real Time versions) are Open
Source!!
Easy for developing RT applications

73
Linux for real-time?

Could increase priority for real-time tasks and
assume they get scheduled
Problem Linux optimizes average case whereas an
RTOS should work under worst case assumptions

74
Linux A Simplified View
75
Linux conflicts with RT constraints

Coarse grained synchronization long intervals
when a task has exclusive use of data ( as fine
grained leads to lot of overhead reducing the
average case performance)
Linux batches many operations for efficient use
of H/W
e.g freeing a list of pages when memory is full
reducing the worst case performance

Linux doesn't preempt low-priority task during
system call
Linux will make high priority tasks wait for low
priority to release resources

77
Real Time Linux approaches

Modify the current Linux kernel to guarantee RT
constraints
Used by KURT
Make the standard Linux kernel run as a task of
the real-time kernel
Used by RT-Linux, RTAI

Slides thanks to Swaminathan Sivasubramanian,
Iowa State University
78
Modifying Linux kernel

Advantages
Most problems, such as interrupt handling,
already solved
Less initial labour
Disadvantages
No guaranteed performance
RT tasks dont always have precedence over non-RT
tasks.

79
Running Linux as a process of a second RT kernel

Advantages
Can make hard real time guarantees
Easy to implement a new scheduler
Disadvantages
Initial port difficult, must know underlying
hardware
Running a small real-time executive is not a
substitute for a full fledged RTOS

80
KURT Overview

Developed at University of Kansas
Soft real-time system
Refines the temporal granularity of Linux
Motivation RT tasks may need a time resolution
on the order of microseconds, while non-RT tasks
may need a resolution of only milliseconds

Result
Timer interrupts are programmed to service
earliest scheduled event (results in aperiodic
timer interrupts)

82
KURT Overview (continued)

Not suitable for hard real-time systems
KURT cant guarantee priority of RT tasks over
non-RT tasks
An RT task can be blocked by a non-RT task (eg
during disk I/O) leading to priority inversion
Suitable for soft RT systems

83
RT-Linux Overview

Open source Linux project
Supports x86, PowerPC, Alpha
Patch of the regular Linux kernel (simply install
the patch and recompile the kernel)
Provides an RT API for developers
Runs Linux kernel as lowest priority process

84
RT-Linux Task Structure
85
RT-Linux Interrupt Dispatcher
RT Linux interrupt handler
RT - Int dispatcher
RT int
Non RT int
Linux Interrupt dispatcher
86
RT-Linux Overview (continued)

RT tasks are coded as modules
Modules are inserted and removed at users
discretion
Extremely good at handling periodic tasks
Communicates with non-RT kernel and other RT
tasks via fifo queues
Tools are provided for graphical analysis of RT
execution

87
Problems with RT-Linux

Currently no support for aperiodic tasks
Not very useful for complex RT systems
Currently limited to simple problems

88
Flight Simulator with RTLinux Components

CLIENT SERVER

89

Flight Dynamics Module
Reader
Fifo1
Equation Solver
Network
Fifo 2
Writer
90
Example (Contd )

In the FD Module, there are three threads the
reader, the equation solver and the writer.
Reader reads the data from network and writes it
in the fifo1.
Equation solver reads data from fifo1, computes
output based on this input and writes output in
the fifo2.

91
Example (Contd )

Writer thread reads data from fifo2 and sends it
over the network.
If the three threads were in different modules,
then we could not have used fifo for passing data
between them.

92
Modules

Module is a program that can be loaded or removed
from the kernel at runtime without having to stop
or compile the kernel.
Each module requires two basic functions,
init_module() and cleanup_module().

93
Init_module()

This function is called when the module is
loaded.
Any thread that is to be used in the module has
to be created here using pthread_create() call.
The thread has to be passed a function name
(defined in the module) which defines the code
that the thread will run.

94
Init_module() (Contd)

Any fifo that is to be used in the module has to
be created here by rtf_create().
It is a good practice to destroy the fifo before
creating it, as an already created fifo might
have some data in it or some other module might
be using it.
Any other variables can also be initialized in
this function.

95
Cleanup_module()

All the fifos and threads created in the
init_module() function should be destroyed here.
Any other action that is to be taken when the
module is removed, should be implemented here.

96
Threads

We can create different modules for each thread
or implement them in the same module, its just a
programming decision.
Normally real time threads are implemented as
periodic threads, because otherwise they would
not allow any non-real-time task to run.

97
Behaviour of Threads

They are used as normal C programming threads and
their scheduling depends on the priority assigned
to them.
The time taken by a thread to execute is
independent of the module in which it was created.

98
Fifos

Fifos are used for passing data between real-time
and non-real-time tasks.
Non-real-time tasks treat fifos as ordinary
files.
A fifo should be created by a real-time task,
before any non-real-time task can use it.

99
Fifos (Contd)

A fifo cannot be used simultaneously by two
modules.
Fifo can be used to pass data between real-time
threads by implementing both threads in the same
module.
To send data rtf_put() call is used and to
receive rtf_get() call is used.

100
RTLinux as the OS contd

Provides scheduling latency of the order of ms
for real-time threads
Provides interrupt latency of the order of ms for
real-time interrupts
Provides co-existence of real-time and non
real-time interrupt handling for the same device
Provides fifo based communication mechanism
between real-time and non-real time threads

101
Research Operating Systems

MARS static scheduling
ARTS static priority scheduling
Spring dynamic guarantees
Polis synthesizing OSs

102
MARS -- TU, Vienna (Kopetz)

Offers support for controlling a distributed
application based entirely on time events
(rather than asynchronous events) from the
environment.
A priori static analysis to demonstrate that
all the timing requirements are met.

103

Uses flow control on the maximum number of
events that the system handles.
Based on the time driven model -- assume
everything is periodic.
Static table-driven scheduling approach
A hardware based clock synchronization algorithm
A TDMA-like protocol to guarantee timely message
delivery

104
ARTS -- CMU (Tokuda, et al)

The ARTS kernel provides a distributed real-time
computing environment.
Works in conjunction with the static priority
driven preemptive scheduling paradigm.
Kernel is tied to various tools that a priori
analyze schedulability.

105

The kernel supports the notion of real-time
objects and real-time threads.
Each real-time object is time encapsulated -- a
time fence mechanism The time fence provides a
run time check that ensures that the slack time
is greater than the worst case execution time for
an object invocation

106
SPRING Umass. (Ramamritham Stankovic)

Real-time support for multiprocessors and
distributed systems
Strives for a more flexible combination of
off-line and on-line techniques
Safety-critical tasks are dealt with via static
table-driven scheduling.
Dynamic planning based scheduling of tasks that
arrive dynamically.

107

Takes tasks' time and resource constraints into
account and avoids the need to a priori compute
worst case blocking times
Reflective kernel retains a significant amount of
application semantics at run time provides
flexibility and graceful degradation.

108
Polis Synthesizing OSs