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.

49

• 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

50

• 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)

52

• 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

55

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

56

• 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.

60

• 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

66

• 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

76

• 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

81

• 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

• 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

• Some interrupts can be made to directly execute
  the corresponding task
• Needed OS execute synthesized based on just what
  is needed

110
Distributed RT
111
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
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
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
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
TDMA - TTP

• time division multiple access - time triggered
  protocol
• network time divided into slots
• static assignment of slots to nodes
• implicit flow control

116
Summary

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