Real-Time Systems
Introduction to Real-Time Systems
Real-time Systems -- Introduction
Real-time systems are defined as those
systems in which the correctness of the
system depends not only on the logical
result of computation, but also on the
time at which the results are produced.
Hard real-time systems (e.g., Avionic
control).
Firm real-time systems (e.g., Banking).
Soft real-time systems (e.g., Video on
Real-time Systems -- Introduction
Hard Deadline:
Penalty due to missing deadline is a higher
order of magnitude than the reward in meeting
the deadline
Firm Deadline:
Penalty and reward are in the same order of
magnitude
Soft Deadline:
Penalty often lesser magnitude than reward
3
A typical REAL-TIME System
Example Car driver
Mission: Reaching the destination safely.
Controlled System: Car.
Operating environment: Road conditions.
Controlling System
- Human driver: Sensors - Eyes and Ears of the driver.
- Computer: Sensors - Cameras, Infrared receiver, and
Laser telemeter.
Controls: Accelerator, Steering wheel, Break-pedal.
Actuators: Wheels, Engines, and Brakes.
5
Example Car driver (contd)
Critical tasks: Steering and breaking.
Non-critical tasks: Turning on radio.
Performance is not an absolute one. It measures the
goodness of the outcome relative to the best outcome
possible under a given circumstance.
Cost of fulfilling the mission Efficient solution.
Reliability of the driver Fault-tolerance is a must.
6
Real-Time Systems - Issues
Resource Management (RM) Issues
Scheduling, Fault-tolerance, Resource reclaiming,
Communication
Architectural Issues
Computing subsystem, Communication subsystem,
I/O subsystem
Software Issues
Requirements, specification, and verification, Real-
time languages, Real-time databases
7
Preemptive vs Non-preemptive scheduling
Preemptive Scheduling
Task execution is preempted and resumed later
Preemption occurs to execute higher priority task.
Offers higher schedulability
Involves higher scheduling overhead due to context
switching
Non-preemptive Scheduling
Once a task starts executing, it completes its full
execution
Offers lower schedulability
Less overhead due to less context switching
8
Architectural Issues
Predictability in Instruction execution time,
Memory access, Context switching, Interrupt
handling.
RT systems usually avoid caches and superscalar
features.
Support for error handling (self-checking circuitry,
voters, system monitors).
Support for fast and reliable communication
(routing, priority handling, buffer and timer
Introduction: Summary
Real-time systems require logical correctness and timeliness.
Real-time system consists of a controlling system, controlled
system, and the environment.
Real-time systems are classified as: hard, firm, and soft RT
systems.
Workload (tasks) are periodic, aperiodic.
The notion of predictability is very important in real-time systems.
Important issues include:
scheduling, resource reclaiming, fault-tolerance,
communication, architectural issues, system specification and
verification, programming languages, and databases.
10
Role of an OS in Real Time Systems
Standalone Applications
Often no OS involved
Micro controller based Embedded Systems
Some Real Time Applications are huge &
complex
Multiple threads
Complicated Synchronization Requirements
Filesystem / Network / Windowing support
OS primitives reduce the software design time
Real-Time Operating System
An RTOS is an OS for response time-controlled and eventcontrolled processes. It is very essential for large scale
embedded systems.
RTOS occupy little space from 10 KB to 100KB
The main task of a RTOS is to manage the
resources of the computer such that a particular operation
executes in precisely the same amount of time every time it
occur.
Renesas automotive dashboard
platform.
Features of RTOSs
Scheduling.
Resource Allocation.
Interrupt Handling.
Other issues like kernel size.
Scheduling in RTOS
More information about the tasks are
known
No of tasks
Resource Requirements
Release Time
Execution time
Deadlines
Being a more deterministic system better
scheduling algorithms can be devised.
Scheduling Algorithms in RTOS
Clock Driven Scheduling
Weighted Round Robin Scheduling
Priority Scheduling
(Greedy / List / Event Driven)
Scheduling Algorithms in RTOS
(contd)
Clock Driven
All parameters about jobs (release time/
execution time/deadline) known in advance.
Schedule can be computed offline or at some
regular time instances.
Minimal runtime overhead.
Not suitable for many applications.
Scheduling Algorithms in RTOS
(contd)
Weighted Round Robin
Jobs scheduled in FIFO manner
Time quantum given to jobs is proportional to its weight
Example use : High speed switching network
QOS guarantee.
Not suitable for precedence constrained jobs.
Job A can run only after Job B. No point in giving time quantum to Job B before
Job A.
Job1 = Total time to complete 250 ms (quantum 100 ms).
First allocation = 100 ms.
Second allocation = 100 ms.
Third allocation = 100 ms butjob1self-terminates after 50 ms.
Total CPU time ofjob1= 250 ms
Scheduling Algorithms in RTOS
(contd)
Priority Scheduling
(Greedy/List/Event Driven)
Processor never left idle when there are ready tasks
Processor allocated to processes according to priorities
Priorities
static
- at design time
Dynamic - at runtime
Process
Average
Burst
Time
Priority
Waiting
Time
Turnaround
Time
10
16
16
18
18
19
8.2
12
Nested Preemption Priority Scheduling
Timeline for Priority-based Preemptive Scheduling
Resource Allocation in RTOS
Resource Allocation
The issues with scheduling applicable here.
Resources can be allocated in
Weighted Round Robin
Priority Based
Some resources are non preemptible
Dynamic Memory Allocation in RTOS
Device I/O and Time Management
Solutions to Priority Inversion
Non Blocking Critical Section
Higher priority Thread may get blocked by
unrelated low priority thread
Priority Ceiling
Each resource has an assigned priority
Priority of thread is the highest of all priorities
of the resources its holding
Priority Inheritance
The thread holding a resource inherits the
priority of the thread blocked on that resource
Other RTOS issues
Interrupt Latency should be very small
Kernel has to respond to real time events
Interrupts should be disabled for minimum
possible time
For embedded applications Kernel Size
should be small
Should fit in ROM
Sophisticated features can be removed
No Virtual Memory
No Protection
Peripheral devices and protocols
Interfacing
Serial/parallel ports, USB, I2C, PCMCIA, IDE
Communication
Serial, Ethernet, Low bandwidth radio, IrDA,
802.11b based devices
User Interface
LCD, Keyboard, Touch sensors, Sound, Digital
pads, Webcams
Sensors
A variety of sensors using fire, temperature,
pressure, water level, seismic, sound, vision
Example of Rtos
Wind River Systems
VxWorks
pSOS
QNX Software Systems
QNX
Mentor Graphics
VRTX
Palm Computing
PalmOS
Mobile OS
SymbianOS
Linux based
Embedded Debian Project
convert Debian to an
embedded OS
ETLinux
for PC104 SBCs
uCLinux
for microprocessors that
dont have MM
uLinux (muLinux)
distro fits on a single
floppy
RT-Linux
Introduction
25
Contents
Real-Time Operating System (RTOS) Vs. General Purpose OS
(GPOS)
Can Linux provide real-time guarantees?
Commercial RTOSs
RTLinux Vs. Linux: Architectural comparison
RTLinux Vs. Linux: Code perspective
26
RTOS Vs. GPOS
RTOS
needs deterministic timing behavior
Works under worst case assumptions
GPOS
high throughput and fairness
Optimizes for the average case
Hence, the design objectives of the OSs are
different
27
Can Linux provide real-time guarantees?
-- No!!
Linux
non-preemptible kernel
A system call might take long time to complete
Tasks can be released only with 10ms precision
Virtual memory
Introduces unpredictable amount of delays
Variable priority
Each task is assigned a priority which varies over the
time; this is to achieve fairness
28
Can Linux provide real-time guarantees?
-- No!! (contd..)
Linux
Linux will batch several operations for efficient use of H/W
delaying all tasks
Linux also reorders requests from multiple processes for H/W
efficiency
Linux does not preempt low priority task in a system call,
instead queues the high priority task
Linux makes high priority tasks to wait for low priority tasks to
release resources
Therefore, Linux cannot provide real-time
29
Commercial RTOS
RTLinux Monolithic kernel with loadable modules
QNX Microkernel approach
VxWorks Monolithic kernel
LynxOS Microkernel
ARTS, Spring, KURT, RTAI, etc.
30
RTLinux: Overview
Open source Linux project
Supports x86, PowerPC, Alpha
Available as a patch to the regular Linux kernel
Provides an RT API for developers
Runs Linux kernel as lowest priority process
31
Linux Kernel
User Processes
System libraries
Device drivers
I/O
Linux kernel
Hardware Interrupts
Hardware
32
RTLinux Kernel
Linux is executed in the background
User Processes
Real Time Tasks
System libraries
Device drivers
I/O
Direct
h/w
access
Linux kernel
Software Interrupts
RT-Scheduler
RTLinux Plug-in
I/O
Hardware Interrupts
Hardware
33
Linux Kernel: code
perspective
THE
controller
User
Process
M1
M2
M2
M3
Linux Monolithic kernel core
M4
RAM
Kernel Loadable Modules
Module M2 service
(system call)
DISK
34
THE
RTLinux Kernel: code perspective
RT Load
command
controller
Load RT core
RTM2
RTM3
M1
Linux Monolithic kernel core
M2
RT-Core Module
M3
RAM
Kernel Loadable Modules
RT core
DISK
35
