RTOS – Real-Time Operating System. • What is a real-time system? • A real-time
system is any information processing system which has to respond to externally ...
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
RTOS – Real-Time Operating System •
What is a real-time system? •
A real-time system is any information processing system which has to respond to externally generated input stimuli within a finite and specified period •
the correctness depends not only on the logical result but also the time it was delivered
•
failure to respond is as bad as the wrong response!
•
The computer is a component in a larger engineering system => EMBEDDED COMPUTER SYSTEM
•
99% of all processors are for the embedded systems market • • •
[ Alan Burns & Andy Wellings @ University of York ] [ Stephem A. Edwards @ Synopsys, Inc. ] [ Kang G. Shin @ University of Michigan ]
SoC - rtos - 1
© Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Terminology •
Hard real-time - systems where it is absolutely imperative that responses occur within the required deadline. E.g. Flight control systems.
•
Soft real-time - systems where deadlines are important but which will still function correctly if deadlines are occasionally missed. E.g. Data acquisition system.
•
Real real-time - systems which are hard real-time and which the response times are very short. E.g. Missile guidance system.
•
Firm real-time - systems which are soft real-time but in which there is no benefit from late delivery of service.
•
A single system may have all hard, soft and real real-time subsystems •
© Peeter Ellervee
in reality many systems will have a cost function associated with missing each deadline
SoC - rtos - 2
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Operating Systems •
An operating system is a program that provides an environment for executing other programs, often providing facilities for I/O, a filesystem, networking, virtual memory, and multitasking: a way to run multiple program concurrently on a single processor.
•
Task scheduling policies •
timesharing - the main goal is fairness: providing similar interactive response times for all running processes
•
real-time OS - the main objective is to meet deadline, i.e., to make sure each process that must complete by a certain time does so.
SoC - rtos - 3
© Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Timesharing Systems •
The scheduler’s goal is to provide all processes with acceptable interactive performance.
•
Fairness is the objective: no one user should be able to monopolize the processor’s resources at the expense of others. • •
Timeslices are used usually Combined with priority numbers
© Peeter Ellervee
SoC - rtos - 4
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Real-Time Operating Systems •
Deadlines - missing a deadline in a hard real-time system can be catastrophic (nuclear power plant, aircraft control surfaces, etc.)
•
RTOSs try to meet deadline using a simple principle - suspending low-priority processes when one with higher priority starts
•
Four main functions • • • •
•
Process management and synchronization Memory management IPC I/O
Must also support predictability and real-time constraints
SoC - rtos - 5
© Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Real-Time Scheduling •
Collection of tasks, each with a initiation time, a deadline, an execution time, and a period
•
Sporadic tasks - assumed to be periodic with a minimum period
•
Rate-Monotonic Scheduling (RM)
P1
•
Single processor, fixed-priority tasks, no communication, preemptive scheduler
P2
•
Task with the shortest deadline has the highest priority
P3
•
Suffers from ignoring the dynamic behavior of the system - it is designed for the worstcase situation
© Peeter Ellervee
SoC - rtos - 6
Σ
A B C
B
A
B
C
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Other Scheduling Approaches
•
Earliest Deadline First (EDF) - dynamic reordering of priorities •
Problems with cyclic time-slice schedulers •
poor aperiodic response time
•
long schedules
•
Problems with common priority-driven schedulers •
EDF: High run-time overheads
•
RM: High schedulability overheads
Combined Static and Dynamic Scheduling (CDS)
•
Two task queues • •
•
Dynamic Priority (DP) scheduled by EDF Fixed Priority (FP) scheduled by RM
CSD has near zero schedulability overhead •
Most EDF schedulable task sets can work under CSD
SoC - rtos - 7
© Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
RTOS for SoC •
Small memories, slow processors
•
Small-memory embedded systems used everywhere • • • •
•
automobiles factory automation and avionics home appliances telecommunication devices, PDAs,...
Massive volumes (10K-10M units) --> Saving even a few dollars per unit is important: • • •
cheap, low-end processors (Motorola 68K, Hitachi SH-2) max. 32-64 KB SRAM, often on-chip low-cost networks, e.g., Controller Area Network (CAN)
© Peeter Ellervee
SoC - rtos - 8
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
RTOS for Small-Memory Embedded Systems • • •
•
Despite restrictions, must perform increasingly complex functions General-purpose RTOSs (VxWorks, pSOS, QNX) too large or inefficient Some vendors provide smaller RTOSs (pSOS Select, RTXC, Nucleus) by carefully handcrafting code to get efficiency
RTOS Requirements • • •
Code size ~ 10 kB Must provide all basic OS services: IPC, task synchronization, scheduling, I/O All aspects must be re-engineered to suit small-memory embedded systems: •
API
•
IPC, synchronization, and other OS mechanisms
•
Task scheduling
•
Networking
SoC - rtos - 9
© Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Minimizing Kernel Size •
Location of resources known •
allocation of threads on nodes
•
compile-time allocation of mailboxes, etc., so no naming services
•
Memory-resident applications: •
•
no disks or file systems
Simple messages •
e.g., sensor readings, actuator commands
•
often can directly interact with network device driver
•
Reducing Kernel Execution Overhead •
Task Scheduling: EDF, RM can consume 10-15% of CPU
•
Task Synchronization: semaphore operations incur context switch overheads
•
- Intertask Communication: often exchange 1000’s of short messages, especially if OO is used
© Peeter Ellervee
SoC - rtos - 10
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Message Passing •
Tasks in embedded systems may need to exchange thousands of short messages per second
•
Traditional IPC mechanisms (e.g., mailbox-based IPC) do not work well • •
•
high overheads no “broadcast” to send to multiple receivers
For efficiency, application writers forced to use global variables to exchange information •
Not safe if access to global variables unregulated
SoC - rtos - 11
© Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
State Messages • •
Uses single-writer, multiple-reader paradigm Writer-associated state message “mailbox” (SMmailbox) •
A new message overwrites previous message
•
Reads do not consume messages
•
Reads and writes are non-blocking, synchronization-free
•
Read and write operations through user-level macros •
Much less overhead than traditional mailboxes
•
A tool generates customized macros for each state message
•
Problem with global variables: a reader may read a half-written message as there is no synchronization
•
•
Solution: N-deep circular message buffer for each state message •
pointer is updated atomically after write
•
if writer has period 1 ms and reader 5 ms, then N=6 suffices
New Problem: N may need to be in the 100’s
© Peeter Ellervee
SoC - rtos - 12
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Memory Protection •
Needed for fault-tolerance, isolating bugs
•
Embedded tasks have small memory footprints • •
•
Can use just 1 or 2 page tables from lowest level of hierarchy Use common upper-level tables to conserve kernel memory
Map kernel into all task address spaces • •
Minimize user-kernel copying as task data and pointers accessible to kernel Reduce system call overheads to little more than for function calls
SoC - rtos - 13
© Peeter Ellervee
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
Proprietary Kernels •
Small and fast commercial RTOSs: QNX, pSOS, VxWorks, Nucleus, ERCOS, EMERALDS, Windows CE,...
• • • •
Fast context switch and interrupt response
•
How to support real-time constraints
•
Small in size No virtual memory and can lock code & data in memory Multitasking and IPC via mailboxes, events, signals, and semaphores
•
bounded primitive exec time
•
real-time clock
•
priority scheduling
•
special alarms and timeouts
Standardization via POSIX RT extensions
© Peeter Ellervee
SoC - rtos - 14
D e p a r t m e n t
o f
C o m p u t e r
E n g i n e e r i n g
RT Extensions • • • •
RT-UNIX,RT-LINUX, RT-MACH, RT-POSIX Slower, less predictable, but more functions and better development environments RT-POSIX: timers, priority scheduling, rt files, semaphores, IPC, async event notification, process memory locking, threads, async and sync I/O Problems: coarse timers, system interface and implementation, long interrupt latency, FIFO queues, no locking pages in memory, no predictable IPC
Research RTOSs • • • • •
Support RT scheduling algorithms and timing analysis RT sync primitives, e.g., priority ceiling Predictability over average performance Support for fault-tolerance and I/O Examples: Spring, Mars, HARTOS, MARUTI, ARTS, CHAOS, EMERALDS
© Peeter Ellervee
SoC - rtos - 15
