Hard Realtime

There are many systems that obviously have hard-realtime requirements, such as control or data-acquisition systems. But there also are a large number of systems that don't have quite so obvious hard-realtime demands: those systems that need to react to special events in a defined small time interval. These systems may be performing non-timecritical tasks in general, but emergency shutdown routines must still be serviced with a very small delay independent of the current machine state. In such cases a hard-realtime system is required to guarantee that no such critical event will ever be missed, even if the system goes up to an enormous system load or a user-space application blocks altogether. The criteria for requiring hard-realtime as opposed to soft-realtime are the following:

• No event of a specific category may be missed under any circumstances (e.g. emergency shutdown procedure)
• the system should have low latency in response to a specific type of event.
• periodic events should be generated with a worst case deviation guaranteed.

Note that these three criteria do overlap in a certain respect and could be reduced to a single one, that being to guarantee worst case timing variance of a specific event class, but that's not what I would call a self-explanatory definition. A hard realtime system naturally also will provide high-resolution timers andappropriate alarm/sheduling functions.

RTLinux (and a non-POSIX derivative of it, RTAI) fall into the class of hard-realtime Linux variants (if you know of any others let me know). These are based on three principles (that are covered by US Patent 5,995,745)

• Unconditional Interrupt interception.
• delivery of non-realtime interrupts to the general-purpose OS as soft-interrupts.
• Run the general-purpose OS as the idle task of the RTOS.

By providing communication mechanisms that allow data exchange between RT and non-RT tasks via shared memory RT-FIFO and POSIX signals, as well as extending RT-execution to allow for user-space realtime in RTLinuxpro, a full integration of demanding realtime tasks into an embedded Linux based system is achievable. This extends the RTOS to include the full feature of GNU/Linux without limits.

A featur that is available in the latest versions of RTLinuxpro is to reserve a minimum CPU time for non-real-time (that is Linux) to ensure that no rt-task can actually monopolize the systems resources and thus de-facto crash the system (that is it will not crash it will only freez if a rt-tasks uses 100% of the CPU time continuously - for all practical purposes and from a user perspective the box is rock solid locked). The ability to reserve CPU time for Linux is relevant for systems that need to report such errornous behavior and may not simply fail silently.