Wht is the actual need of RTOS

Till Straumann strauman at SLAC.Stanford.EDU
Wed Dec 18 18:47:21 UTC 2002


Let me give you a (hypothetical - I don't know nothing about
real-life software in automobiles) example.

Let's look a the on-board computer in an automobile. It has
to perform several tasks, e.g. check the fuel level, control
temperature and the airbag. The airbag is an example for a
device with hard-real time requirements: Assume that there
is a shock/acceleration sensor who generates an interrupt if
there is a change in velocity exceeding a critical level.

The system _must_guarantee_ that the interrupt is delivered
and the task controlling the airbag is scheduled (the
CPU might e.g. be running the temperature controlling algorithm
at the time an accident happens) and eventually
able to fire the airbag's ignition within a critical deadline,
e.g. 500us - otherwise, safety is severely compromised.

Here are a couple of reasons, why a general purpose OS
(such as linux) can not guarantee timely response:

  - The OS might disable interrupts for (relatively) long
    times to protect internal data structures and hence
    the critical event (interrupt) is recognized too late.
  - The OS might disable the scheduler during execution
    of long stretches of code (also in order to prevent
    corruption of kernel data) - many OSes disable scheduling
    altogether while executing system calls. Linux-2.4 still
    uses this technique ('non-preemptive kernel').
    Even if the interrupt is recognized quickly, the critical
    task might get scheduled too late.
  - Virtual memory: the airbag task probably is paged out to
    a disk device when the interrupt happens. It takes a _very_
    long (and non-deterministic) time to retrieve the critical
    pages from disk. (Some OSes allow for 'locking' pages in
    memory, preventing them from being paged out.)

A hard-RTOS (like RTEMS) has been carefully designed to
minimize critical sections of code with interrupts or
scheduling disabled. RTEMS running on a modern CPU is able
to schedule a task like the 'airbag' task from the example
within less than a few tens of microseconds - in the worst
case - no matter how loaded the system is at a lower
priority!
OTOH, a hard-RTOS lacks very important features of a general
purpose OS (because adding them would make the system more
complex and hence degrade its real-time performance), most
related to protection: multiple users, multiple address spaces,
virtual memory, a protected system-call interface to the kernel,
etc. (it is much more expensive to 'trap' into the kernel,
carefully inspect / copy all arguments etc. [general purpose
OS] than just using ordinary function calls [RTOS]).

Sorry if this is too long or confusing...

-- Till






More information about the users mailing list