Upload
gen
View
35
Download
0
Embed Size (px)
DESCRIPTION
IT-606 Embedded Systems (Software). Krithi Ramamritham S. Ramesh Kavi Arya KReSIT/ IIT Bombay. Real-Time Support. F2. Functional Design. F5. F1. F4. F3. (F2). Architectural Design. Thread. (F5). HW1. HW2. HW3. HW4. (F3). (F4). RTOS/Drivers. Hardware Interface. - PowerPoint PPT Presentation
Citation preview
1© Krithi Ramamritham / Kavi Arya
IT-606Embedded Systems
(Software)
Krithi RamamrithamS. RameshKavi Arya
KReSIT/ IIT Bombay
Real-Time Support
2© Krithi Ramamritham / Kavi Arya
Functional Design & Mapping
HW1 HW2 HW3 HW4Hardware Interface
RTOS/Drivers
Thr
eadArchitectural
Design
F1F2
F3
F4
F5Functional
Design
(F3) (F4)
(F5)
(F2)
Source:Source:Ian Phillips, ARMIan Phillips, ARM
VSIA 2001
Source:Source:Ian Phillips, ARMIan Phillips, ARM
VSIA 2001
3© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
A real-time system is a system that reacts to events in the environment by performing predefined actions
I/O - data
I/O - data
Real-Time Systems
Real-timecomputing system
event
action
within specified time intervals.
time
5© Krithi Ramamritham / Kavi Arya
CLIENT SERVER
Flight Avionics
Constraints on responses to pilot inputs, aircraft state updates
6© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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, ....
9© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
deadline (dl)
+
Hard, soft, firm
• Hard -- result useless or dangerousif deadline exceeded
value
time-
hardsoft
• Soft -- result of some - lower value if deadline exceeded
• Firm -- If value drops to zero at deadline
12© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
Plan
• Special Characteristics of Real-Time Systems
• Real-Time Constraints
• Canonical Real-Time Applications
• Scheduling in Real-time systems
• Operating System Approaches
15© Krithi Ramamritham / Kavi Arya
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 air:
design process identifies events, derives models, and finally specifies timing constraints
16© Krithi Ramamritham / Kavi Arya
Overall Picture…
physical properties of environment
timing constraints
model - design
analysis, testing
run-time dispatching
in field use
functional
temporal
17© Krithi Ramamritham / Kavi Arya
• Periodic– activity occurs repeatedly– e.g., to monitor environment values, temperature, etc.
time
period
periodic
18© Krithi Ramamritham / Kavi Arya
• Aperiodic– can occur any time– no arrival pattern given
time
aperiodicaperiodic
19© Krithi Ramamritham / Kavi Arya
• Sporadic– can occur any time, but– minimum time between arrivals
time
mint
sporadic
20© Krithi Ramamritham / Kavi Arya
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 occurTwo possibilities:– action whenever temp raises above warn
-- event triggered– look every fixed time interval; action taken when temp above warn -- time triggered
21© Krithi Ramamritham / Kavi Arya
TT
ET
time
t
22© Krithi Ramamritham / Kavi Arya
TT
ET
time
t
23© Krithi Ramamritham / Kavi Arya
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
25© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
Plan
• Special Characteristics of Real-Time Systems
• Real-Time Constraints• Canonical Real-Time Application
Coding• Scheduling in Real-time
systems • Operating System Approaches
27© Krithi Ramamritham / Kavi Arya
A Typical Real time system
Temperature sensor
CPU
Memory
Input port
Output portHeater
28© Krithi Ramamritham / Kavi Arya
Code for exampleWhile 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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
Extended polling example
Computer
Temperature Sensor 1
Task 1
Task 2
Task 3
Task 4
Conceptual link
Temperature Sensor 2
Temperature Sensor 3
Temperature Sensor 4
Heater 1
Heater 2
Heater 3
Heater 4
31© Krithi Ramamritham / Kavi Arya
Polling
• Problems– Arranging task priorities– Round robin is usual within a priority level– Urgent tasks are delayed
32© Krithi Ramamritham / Kavi Arya
Interrupt driven systems
• Advantages– Fast– Little delay for high priority tasks
• Disadvantages– Programming– Code difficult to debug– Code difficult to maintain
33© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
An alternative…
Initiate a task to handle the sensor T1
T1:
Do sensor task T2
Repeat
{Schedule T2 for n * 100 ms
n:=n+1}
There are some subtleties here...
35© Krithi Ramamritham / Kavi Arya
Clock, interrupts, tasks
Clock ProcessorInterrupts
Task 1 Task 2 Task 3 Task 4
Job/Task queue
Examines
Tasks schedule events using the clock...
40© Krithi Ramamritham / Kavi Arya
Plan
• Special Characteristics of Real-Time Systems
• Real-Time Constraints• Canonical Real-Time Applications• Scheduling in Real-time systems • Operating System Approaches
41© Krithi Ramamritham / Kavi Arya
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.
Real-timecomputing system
time
I/O - data
I/O - data
event
action
42© Krithi Ramamritham / Kavi Arya
Schedulability analysis
a.k.a. feasibility checking:
check whether tasks will meet their
timing constraints.
43© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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 <= 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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
RMA: Design Time vs. Run Time
At Design Time:Tasks priorities are assigned according
to their periods; shorter period means higher priority
48© Krithi Ramamritham / Kavi Arya
RMA: Design Time vs. Run TimeSchedulability testTask set is schedulable if
Very simple test, easy to implement.
Run-time The ready task with the highest priority is
executed.
C i
T ii1
n
n(21/ n 1)
49© Krithi Ramamritham / Kavi Arya
RMA: Exampletaskset: 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 < 0.75 ?
…. not schedulable
50© Krithi Ramamritham / Kavi Arya
RMA…A schedulability test is • Sufficient: there may exist tasksets that fail the test, but are
schedulable• Necessary: tasksets that fail are (definitely) not schedulableThe RMA schedulability test is sufficient, but not
necessary.When periods are harmonic, i.e., multiples of each other, utilization can
be 1.
51© Krithi Ramamritham / Kavi Arya
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)
52© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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
R CR
TCi
ni
in
jj hp i
j
1
( )
54© Krithi Ramamritham / Kavi Arya
Example - Exact AnalysisLet 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 task
hp(t3) = T1
R3 = 2R C C
R C C
R R
t
t
t t
t t
t t
31
1 1 2
32
1 1 2
33
32
3 1
3 1
1
3
2
3
55© Krithi Ramamritham / Kavi Arya
• R2, third highest priority taskhp(t2) = {T1 ,T3 }
R2 = 3
R C C C
R C C C
R R
t
t
t t
t t t
t t t
21
1 1 1 3
22
1 1 1 3
23
22
2 1 3
2 1 3
1
3
1
5
3
3
3
5
56© Krithi Ramamritham / Kavi Arya
• R4, third lowest priority taskhp(t4) = {T1 ,T3 ,T2 }
R4 = 9 Response times of first instances of all tasks < their periods => taskset feasible under RM scheduling
R C C C C
R C C C C
R C C C C
t
t
t
t t t t
t t t t
t t t t
41
2 1 1 1 5
42
2 2 1 1 6
43
4 1 2 3
4 1 2 3
4 1 2 3
2
3
2
6
2
5
5
3
5
6
5
5
6
3
6
6
6
5
2 2 1 2 7
44
2 3 2 2 9
45
2 3 2 2 9
45
44
4 1 2 3
4 1 2 3
7
3
7
6
7
5
9
3
9
6
9
5
R C C C C
R C C C C
R R
t
t
t t
t t t t
t t t t
57© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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.
60© Krithi Ramamritham / Kavi Arya
• 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© Krithi Ramamritham / Kavi Arya
Plan
• Special Characteristics of Real-Time Systems
• Real-Time Constraints
• Canonical Real-Time Applications
• Scheduling in Real-time systems
• Operating System Approaches
62© Krithi Ramamritham / Kavi Arya
Real-Time Operating SystemsSupport 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© Krithi Ramamritham / Kavi Arya
Real-Time Applications Spectrum
Hard
Soft
Real-Time Operating System
General-PurposeOperatingSystem
VxWorks, Lynx, QNX, ...
Linux, NT
Windows CE
Intime, HyperKernel, RTX
64© Krithi Ramamritham / Kavi Arya
Real-Time Applications Spectrum
Hard
Soft
Real-Time Operating System
General-PurposeOperatingSystem
VxWorks, Lynx, QNX, ...Intime, HyperKernel, RTX
Linux, NT
Windows CE
65© Krithi Ramamritham / Kavi Arya
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
66© Krithi Ramamritham / Kavi Arya
• 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© Krithi Ramamritham / Kavi Arya
Real-Time Extensions to General Purpose Operating
SystemsE.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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
NT Thread Priority = Process class + level
Real-timeclass
2625242322
16 Idle
Above NormalNormalBelow NormalLowest
Highest31 Time-critical
Dynamicclasses
15 Time-critical
14131211
15
High class
1 Idle
987
11
Normal class10
5432
6
Idle class
ThreadLevel
70© Krithi Ramamritham / Kavi Arya
Typical Scheduling
• Threads scheduled by executive.
• Priority based preemptive scheduling.
Interrupts
Deferred Procedure Calls (DPC)
System anduser-level threads
71© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
Linux – A Simplified View
75© Krithi Ramamritham / Kavi Arya
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
76© Krithi Ramamritham / Kavi Arya
• Linux doesn't preempt low-priority task during system call
• Linux will make high priority tasks wait for low priority to release resources
77© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
Modifying Linux kernel
• Advantages– Most problems, such as interrupt handling,
already solved– Less initial labour
• Disadvantages– No guaranteed performance– RT tasks don’t always have precedence
over non-RT tasks.
79© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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
81© Krithi Ramamritham / Kavi Arya
• Result:
Timer interrupts are programmed to service earliest scheduled event (results in aperiodic timer interrupts)
82© Krithi Ramamritham / Kavi Arya
KURT Overview (continued)
• Not suitable for hard real-time systems
• KURT can’t 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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
RT-Linux Task Structure
85© Krithi Ramamritham / Kavi Arya
RT Linux interrupt
handler
RT - Int
dispatcher
Linux Interrupt
dispatcher
RT-Linux Interrupt Dispatcher
RT int
Non RT int
86© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
Problems with RT-Linux
• Currently no support for aperiodic tasks
• Not very useful for complex RT systems
• Currently limited to simple problems
88© Krithi Ramamritham / Kavi Arya
CLIENT SERVER
Flight Simulator with RTLinux Components
89© Krithi Ramamritham / Kavi Arya
Reader
Equation
Solver
Writer
Flight Dynamics Module
Network
Fifo1
Fifo 2
90© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
Research Operating Systems
• MARS – static scheduling
• ARTS – static priority scheduling
• Spring –dynamic guarantees
• Polis – synthesizing OSs
102© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
• 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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
• 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© Krithi Ramamritham / Kavi Arya
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© Krithi Ramamritham / Kavi Arya
• 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© Krithi Ramamritham / Kavi Arya
Polis: Synthesizing OSs
• Given a FSM description of a RT application
• Each FSM becomes a task
• Signals, Interrupts, and polling
• Tasks with waiting inputs handled in FIFS order (priority order – to be done)
109© Krithi Ramamritham / Kavi Arya
• Some interrupts can be made to directly execute the corresponding task
• Needed OS execute synthesized based on just what is needed
110© Krithi Ramamritham / Kavi Arya
Distributed RT
RT-node
RT-node
RT-node
RT-nodegateway
RT-nodegateway
real-time bus
fieldbusessensorsactuatorsbackbone NW
111© Krithi Ramamritham / Kavi Arya
Environment
• Input from the environment via data collected by sensors
• Output to environment via actuators
• Real-time systems “sees” and interacts with environment via sensors and actuators
112© Krithi Ramamritham / Kavi Arya
Real-time buses• Central communication medium for (distributed) real-
time system• Data protocol specific• Temporally predictable, at least time bounded,
transmission• Synchronized (sec)• Membership info (who is alive)• Fault tolerant
– more than one physical network– no single point of failure
113© Krithi Ramamritham / Kavi Arya
Fieldbus
• connects sensors (actuators) with RTS (possibly via dedicated gateway nodes)
• needs to collect data and time of observation
• latency: time passed since event occurrence
114© Krithi Ramamritham / Kavi Arya
CAN
control area networkvery popular, used, e.g., by automotive industry (Volvo)– sender intends to send - puts bit on
channel– collisions resolved by priorities
115© Krithi Ramamritham / Kavi Arya
TDMA - TTP
time division multiple access - time triggered protocol– network time divided into slots– static assignment of slots to nodes– implicit flow control
116© Krithi Ramamritham / Kavi Arya
Summary
• Special Characteristics of Real-Time Systems
• Real-Time Constraints
• Canonical Real-Time Applications
• Scheduling in Real-time systems
• Operating System Approaches