Designing safety-critical operating systems
By David Kleidermacher
Director of Engineering
E-mail: davek@ghs.com
Mark Griglock
Safety- Critical Engineering
Manager
E-mail: markg@ghs.com
Green Hills Software
Whether you are designing a
telecom switch, a piece of
medical equipment or one of
the many complex systems
aboard an aircraft, certain
critical parts of the application
must be able to operate under
all conditions. Indeed, given
the steadily increasing speed of
processors and the economi-
cally-driven desire to run mul-
tiple applications, at varying
levels of criticality, on the same
processor, the risks continue to
grow.
Consider a blood gas ana-
lyzer used in an intensive care
unit. The analyzer may serve
two distinct purposes. First, it
monitors the level of oxygen
and other gasses in the
patient’s bloodstream, in real
time. If any monitored gas
reaches a dangerously low or
high level, the analyzer should
produce an audible alarm or
take some more direct,
interventionary action. But the
device may have a second use,
offering a historical display of
gas levels for “offline” analysis.
In such a system, data logging,
data display and user interface
threads may compete with the
critical monitoring and alarm
threads for use of the processor
and other resources.
In order for threads of vary-
ing importance to safely coex-
ist in the same system, the OS
that manages the processor and
other resources must be able to
properly partition the software
to guarantee resource availabil-
ity. The key word here is guar-
antee. Post-design, post-imple-
mentation testing cannot be
counted on. Safety-critical sys-
tems must be safe at all times.
Terminology
The following terms are
used in this article:
• Thread: A lightweight unit
of program execution.
• Process: A heavyweight unit
consisting primarily of a dis-
tinct address space, within
which one or more threads
execute.
• Kernel: The portion of an
OS that provides core sys-
tem services such as sched-
uling, thread synchroniza-
tion and inter-process com-
munication.
Memory protection
Fault tolerance begins with
memory protection. For many
years, microprocessors have in-
cluded on-chip memory man-
agement units (MMU) that en-
able individual threads of soft-
ware to run in hardware-pro-
tected address spaces. But many
commercial RTOS never enable
the MMU, even if such hardware
is present in the system.
When all of an application’s
threads share the same memory
space, any thread could—inten-
tionally or unintentionally—cor-
rupt the code, data or stack of
another thread. A misbehaved
thread could even corrupt the
kernel’s own code or internal
data structures. It is easy to see
how a single errant pointer in
one thread could easily bring
down the entire system or at
least cause it to behave unex-
pectedly.
For safety and reliability, a
process-based RTOS is prefer-
able. To create processes with
individual address spaces, the
RTOS need only create some
RAM-based data structures and
enable the MMU to enforce the
protections described therein.
The basic idea is that a new set
of logical addresses is
“switched in” at each context
switch.
The MMU maps a logical ad-
dress used during an instruc-
tion fetch or a data read or write
to a physical address in memory
through the current mapping.
It also flags attempts to access
illegal logical addresses, which
have not been “mapped” to any
physical address. The cost of
processes is the overhead inher-
ent in memory access through
a look-up table. But the payoff
is huge. Careless or malicious
corruption across process
boundaries is rendered impos-
sible. A bug in a user interface
thread cannot corrupt the code
or data of a more critical thread.
It is truly a wonder that non-
memory protected OS are still
used in complex embedded sys-
tems where reliability, safety or
security are important.
Enabling the MMU has
other benefits as well. One big
advantage stems from the abil-
ity to selectively map and
unmap pages into a logical ad-
dress space. Physical memory
pages are mapped into the logi-
cal space to hold the current
process’ code; others are
mapped for data. Likewise,
physical memor y pages are
mapped in to hold the stacks of
threads that are part of the pro-
cess. An RTOS can easily pro-
vide the ability to leave a page’s
Active
Redundant
Figure 1: Redundancy via system heartbeats.
worth of the logical addresses
after each thread’s stack un-
mapped. That way, if any thread
overflows its assigned stack, a
hardware memory protection
fault will occur. The kernel will
suspend the thread instead of
allowing it to corrupt other im-
portant memory areas within
the address space (like another
thread’s stack). This adds a
level of protection between
threads, even within the same
address space.
Memory protection, includ-
ing this kind of stack overflow
detection, is often helpful dur-
ing the development of an ap-
plication. Programming errors
will generate exceptions that
are immediately detected and
easily traceable to the source
code. Without memory protec-
tion, bugs can cause subtle cor-
ruptions that are very difficult
to track down. In fact, since
RAM is often located at physi-
cal address zero in a f lat
memory model, even NULL
pointer dereferences will go
undetected! (Clearly, logical
page zero is a good one to add
to the “unmap list.”)
System call
Another issue is that the kernel
must protect itself against im-
proper system calls. Many ker-
nels return the actual pointer to
a newly created kernel object,
such as a semaphore, to the
thread that created it, as a
handle. When that pointer is
passed back to the kernel in sub-
sequent system calls, it may be
de-referenced directly. But what
Active
if the thread uses that pointer to
modify the kernel object di-
rectly or simply overwrites its
handle with a pointer to some
other memory. The results may
be disastrous.
A bad system call should
never be able to take down the
kernel. An RTOS should, there-
fore, employ opaque handles
for kernel objects. It should also
validate the parameters to all
system calls.
Fault tolerance and high
availability
Even the best software has la-
tent bugs. As applications be-
come more complex, perform-
ing more functions for a soft-
ware-hungry world, the number
of bugs in fielded systems will
continue to rise. System design-
ers must, therefore, plan for fail-

a)
Central store
When a thread creates a new
Central store
central store to hold the data for
b)
ation where this program cre-
Figure 2: a) Before memory quotas and b) after.
ures and employ fault recovery
techniques. Of course, the ef-
fect of fault recovery is applica-
tion-dependent: a user interface
can restart itself in the face of a
fault, a f light-control system
probably cannot.
One way to do fault recovery
is to have a supervisor thread in
an address space all on its own.
When a thread faults (for ex-
ample, due to a stack overflow),
the kernel should provide some
mechanism whereby notifica-
tion can be sent to the supervi-
sor thread. If necessary, the su-
pervisor can then make a sys-
tem call to close down the
faulted thread or the entire pro-
cess and restart it. The supervi-
sor might also be hooked into a
software “watchdog” setup,
whereby thread deadlocks and
starvation can be detected as
well.
In many critical systems,
high availability is assured by
employing multiple redundant
nodes in the system. In such a
system, the kernel running on
a redundant node must have the
Thread B
ability to detect a failure in one
Thread B
of the operating nodes. One
method is to provide a built-in
heartbeat in the interprocessor
message passing mechanism of
the RTOS (Figure 1). Upon
system startup, a communica-
tions channel is opened be-
tween the redundant nodes and
Thread B
each of the operating nodes.
During normal operation, the
redundant nodes continually
receive heartbeat messages
from the operating nodes. If the
heartbeat fails to arrive, the re-
Space domain
Memory
cations can be tolerated. High
starved
require to run. In addition, the
could, therefore, result in a situ-
Memory
the memory quota of the creat-
guaranteed
dundant node can take control
automatically.
Mandatory vs. discretionary
access control
An example of a discretionary
access control is a Unix file: a
process or thread can, at its sole
discretion, modify the permis-
sions on a file, thereby permitting
access to the file by another pro-
cess in the system. Discretion-
ary access controls are useful for
some objects in some systems.
An RTOS that is used in a
safety- or security-critical sys-
tem must be able to go one big
step further and provide man-
datory access control of critical
system objects. For example,
consider an aircraft sensor de-
vice, access to which is con-
trolled by a flight control pro-
gram. The system designer
must be able to set up the sys-
tem statically such that the
flight control program and only
the flight control program has
access to this device. Another
application in the system can-
not dynamically request and
obtain access to this device.
And the flight control program
cannot dynamically provide ac-
cess to the device to any other
application in the system. The
access control is enforced by the
kernel, is not circumventable
by application code and is thus
mandatory. Mandatory access
Thread B
control provides guarantees.
Discretionary access controls
are only as effective as the ap-
plications using them and these
applications must be assumed
to have bugs in them.
Guaranteed resource availability: a portion of its memory quota
to satisfy the request. This kind
In safety-critical systems, a criti- of space domain protection
cal application cannot, as a re- should be part of the RTOS de-
sult of malicious or careless ex- sign. Central memory stores
ecution of another application, and discretionarily-assigned
run out of memory resources. In limits are insufficient when
most RTOS, memory used to guarantees are required.
hold thread control blocks and If an RTOS provides a
other kernel objects comes from memory quota system, dynamic
a central store. loading of low criticality appli-
thread, semaphore or other ker- criticality applications already
nel object, the kernel carves off running are guaranteed to have
a chunk of memory from this the physical memory they will
this object. A bug in one thread memory used to hold any new
processes should come from
ates too many kernel objects and ing process. If this memor y
the central store is exhausted comes from a central store,
(Figure 2a). A more critical then process creation can fail if
thread could fail as a result, per- a malicious or carelessly writ-
haps with disastrous effects. ten application attempts to cre-
In order to guarantee that ate too many new processes.
this scenario cannot occur, the (Most programmers have ei-
RTOS can provide a memory ther mistakenly executed or at
quota system wherein the sys- least heard of a Unix “fork
tem designer statically defines bomb,” which can easily take
how much physical memor y down an entire system.) In most
each process has (Figure 2b). safety-critical systems, dynamic
For example, a user interface process creation will simply not
process might be provided a be tolerated at all and the RTOS
maximum of 128KB and a should be configurable such
flight control program a maxi- that this capability can be re-
mum of 196KB. If a thread moved from the system.
within the user interface pro-
cess encounters the aforemen- Guaranteed resource availability:
tioned failure scenario, the pro- Time domain
cess may exhaust its own The vast majority of RTOS em-
128KB of memor y. But the ploy priority-based, preemptive
flight control program and its schedulers. Under this scheme,
196KB of memory are wholly the highest priority ready
unaffected. thread in the system always gets
In a safety-critical system, to use the processor (execute).
memory should be treated as a If multiple threads are at that
hard currency: when a thread same highest priority level, they
wants to create a kernel object, generally share the processor
its parent process must provide equally, via timeslicing. The
Traditional scheduler
Thread B is starved
Thread A'
Thread A
Thread A"
Scheduler using weights
Thread B CPU resource is guaranteed
Thread A'
Thread A
Thread A"
Figure 3: Traditional scheduler versus scheduler with weights.
problem with this timeslicing
(or even run-to-completion)
within a given priority level, is
that there is no provision for
guaranteeing processor time for
critical threads.
Consider the following sce-
nario: the system includes two
threads at the same priority
level. Thread A is a non-critical,
background thread. Thread B is
a critical thread that needs at
H
M
L
Figure 4: Priority inversion.
least 40 percent of the proces-
sor time to get its work done.
Because Thread A and B are as-
signed the same priority level,
the typical scheduler will time
slice them so that both threads
get 50 percent of the processor.
At this point, Thread B is able
to get its work done. Now sup-
pose Thread A creates a new
thread at the same priority
level. Consequently, there are
three highest priority threads
sharing the processor. Sud-
denly, Thread B is only getting
33 percent of the processor and
cannot get its critical work
done. For that matter, if the
code in Thread A has a bug or
virus, it may create dozens or
even hundreds of “confeder-
ate” threads, causing Thread B
to get a tiny fraction of the
runtime.
One solution to this problem
is to enable the system designer
to inform the scheduler of a
thread’s maximum “weight”
within the priority level (Fig-
ure 3). When a thread creates
another equal priority thread,
the creating thread must give
up part of its own weight to the
new thread. In our previous ex-
ample, suppose the system de-
signer had assigned weight to
Thread A and Thread B such
that Thread A has 60 percent of
the runtime and Thread B has
40 percent of the runtime.
When Thread A creates the
third thread, it must provide
part of its own weight, say 30
percent. Now Thread A and the
new thread each get 30 percent
of the processor time but criti-
cal Thread B’s 40 percent re-
mains inviolate. Thread A can
create many confederate fect each other is to provide a is linear with the number of
threads without affecting the process-level scheduler. De- threads in the partitions, an
ability of Thread B to get its signers of safety critical soft- unacceptably poor implemen-
work done; Thread B’s proces- ware have noted this require- tation. The RTOS must imple-
sor reservation is thus guaran- ment for a long time. The pro- ment the partition scheduler
teed. A scheduler that provides cess, or partition, scheduling within the kernel and ensure
this kind of guaranteed re- concept is a major part of that partition switching takes
source availability in addition ARINC Specification 653, an constant time and is as fast as
to the standard scheduling Avionics Application Software possible.
techniques is required in some Standard Interface.
critical embedded systems, par- The ARINC 653 partition Schedulability
ticularly avionics. scheduler runs partitions, or Meeting hard deadlines is one of
processes, according to a the most fundamental require-
timeline established by the sys- ments of a RTOS and is espe-
tem designer. Each process is cially important in safety-criti-
provided one or more windows cal systems. Depending on the
of execution within the repeat- system and the thread, missing
ing timeline. During each win- a deadline can be a critical fault.
dow, all the threads in the other Rate monotonic analysis
processes are not runnable; (RMA) is frequently used by sys-
only the threads within the cur- tem designers to analyze and
rently active process are predict the timing behavior of
runnable (and typically are systems. In doing so, the system
The problem inherent in all scheduled according to the designer is relying on the un-
schedulers is that they are igno- standard thread scheduling derlying OS to provide fast and
rant of the process in which rules). When the flight control temporally deterministic sys-
threads reside. Continuing our application’s window is active, tem services. Not only must the
previous example, suppose that its processing resource is guar- designer understand how long
Thread A executes in a user in- anteed; a user interface applica- it takes to execute the thread’s
terface process while critical tion cannot run and take away code, but also any overhead as-
Thread B executes in a f light processing time from the criti- sociated with the thread must
control process. The two appli- cal application during this win- be determined. Overhead typi-
cations are partitioned and pro- dow. cally includes context switch
tected in the space domain but Although not specified in time, the time required to ex-
not in the time domain. Design- ARINC 653, a prudent addition ecute kernel system calls, and
ers of safety-critical systems re- to the implementation is to ap- the overhead of interrupts and
quire the ability to guarantee ply the concept of a background interrupt handlers firing and
that the run-time characteris- partition. When there are no executing.
tics of the user interface cannot runnable threads within the ac- All RTOS incur the overhead
possibly affect the run-time tive partition, the partition of context switching. Lower
characteristics of the f light scheduler should be able to run context switching time implies
control system. Thread background threads, if any, in lower overhead, more efficient
schedulers simply cannot make the background partition, in- use of available processing re-
this guarantee. stead of idling. An example sources and increased likeli-
Consider a situation in background thread might be a hood of meeting deadlines. A
which Thread
B normally gets
all the runtime
it needs by H
making it
higher priority
M
than Thread A
or any of the
other threads L
in the user in-
terface. Due to
a bug or poor
Figure 5: Priority inheritance.
design or im-
proper testing,
Thread B may lower its own pri- low priority diagnostic agent RTOS’s context switching code
ority (the ability to do so is that runs occasionally but does is usually hand optimized for
available in practically all ker- not have hard real-time dead- optimal execution speed.
nels), causing the thread in the lines.
user interface to gain control of Attempts have been made to Interrupt latency
the processor. Similarly, add partition scheduling on top A typical embedded system has
Thread A may raise its priority of commercial off-the-shelf OS several types of interrupts re-
above the priority of Thread B by selectively halting all the sulting from the use of various
with the same effect. threads in the active partition kinds of devices. Some inter-
A convenient way to guaran- and then running all the rupts are higher priority and re-
tee that the threads in processes threads in the next partition. quire a faster response time
of different criticality cannot af- Thus, partition switching time than others. For example, an

thread to the priority of the
S2
low priority thread releases the
mutex, its priority will be re-
(S1)
rS1
turned to normal and the high
M
S2
L
S1
Figure 6: Chained blocking caused by priority inheritance.
interrupt that signals the kernel
to read a sensor that is critical
to an aircraft’s f light control
should be handled with the
minimum possible latency. On
the other hand, a typical timer
tick interrupt frequency may be
60Hz or 100Hz. Ten millisec-
onds is an eternity in hardware
terms, so interrupt latency for
the timer tick interrupt is not as
critical as for most other inter-
rupts.
Most kernels disable all in-
terrupts while manipulating
internal data structures during
system calls. Interrupts are dis-
abled so that the timer tick in-
terrupt cannot occur (a timer
tick may cause a context switch)
at a time when internal kernel
data structures are being
changed. The system’s inter-
rupt latency is directly related
to the length of the longest
critical section in the kernel.
In effect, most kernels in-
crease the latency of all inter-
rS2
S2
rupts just to avoid a low prior-
ity timer interrupt. A better so-
lution is to never disable inter-
rupts in kernel system calls and
instead to postpone the han-
dling of an intervening timer
tick until the system call com-
pletes. This strategy depends
on all kernel system calls being
short (or at least that calls that
are not short are restartable),
so that scheduling events can
preempt the completion of the
system call. Therefore, the time
to get back to the scheduler may
vary by a few instructions (in-
significant for a 60Hz sched-
uler) but will always be short
and bounded. It is much more
difficult to engineer a kernel
that has preemptible system
calls in this manner, which is
why most kernels do not do it
this way.
Bounded execution times
In order to allow computation of
the overhead of system calls that
a thread will execute while do-
ing its work, an RTOS should
provide bounded execution
cally elevates the low priority A solution called the prior-
Overhead
ity ceiling protocol not only
high priority thread. Once the solves the priority inversion
(S2)
problem but also prevents
H
rS2
chained blocking (Figure 7).
In one implementation
priority thread will run. The scheme (called the highest
dynamic priority elevation pre- locker), each semaphore has
vents a medium priority thread an associated priority, which is
from running while the high assigned by the system de-
priority thread is waiting; pri- signer to be the priority of the
ority inversion is avoided (Fig- highest priority thread that
times for all such calls. Two ma- ure 5). In this example, the might ever try to acquire that
jor problems involve the timing critical section execution time object. When a thread takes
of message transfers and the (the time the low priority such a semaphore, it is imme-
timing of mutex take opera- thread holds the mutex) is diately elevated to the priority
tions. added to the overhead of the of the semaphore. When the
A thread may spend time high priority thread. semaphore is released, the
performing a variety of activi- A weakness of the priority thread reverts back to its origi-
ties. Of course, its primary ac- inheritance protocol is that it nal priority. Because of this
tivity is executing code. Other does not prevent chained block- priority elevation, no other
activities include sending and ing. Suppose a medium priority threads that might contend for
receiving messages. Message thread attempts to take a mutex the same semaphore can run
transfer times vary with the size owned by a low priority thread until the semaphore is re-
of the data. How can the system but while the low priority leased. It is easy to see how this
designer account for this time? thread’s priority is elevated to prevents chained blocking.
The RTOS can provide a capa- medium by priority inherit- Several RTOS provide sup-
bility for controlling whether ance, a high priority thread be- port for both priority inherit-
transfer times are attributed to comes runnable and attempts ance and priority ceilings, leav-
the sending thread or to the re- to take another mutex already ing the decision up to the sys-
ceiving thread or shared be- owned by the medium priority tem designer.
tween them. Indeed, the thread. The medium priority
kernel’s scheduler should treat thread’s priority is increased to Changing requirements
all activities, not just the pri- high but the high priority Many of the RTOS in use today
mary activity, as prioritized thread now must wait for both were originally designed for
units of execution so that the the low priority thread and the software systems that were
system designer can properly medium priority thread to com- smaller, simpler and ran on pro-
control and ac-
count for them.
rS1
H
Priority inversion
Priority inversion
has long been the M
bane of system de- S2
signers attempting L
to perform rate S1
monotonic analy-
sis, since RMA de- Figure 7: Priority ceilings.
pends on higher
priority threads running before plete before it can run again. cessors without memory protec-
lower priority threads. Priority The chain of blocking criti- tion hardware. With the ever-
inversion occurs when a high cal sections can extend to in- increasing complexity of appli-
priority thread is unable to run clude the critical sections of any cations in today’s embedded sys-
because a mutex (or binar y threads that might access the tems, fault tolerance and high
semaphore) it attempts to ob- same mutex. Not only does this availability features have be-
tain is owned by a low priority make it much more difficult for come increasingly important.
thread but the low priority the system designer to compute Especially stringent are the re-
thread is unable to execute and overhead, but since the system quirements for safety-critical
release the mutex because a designer must compute the systems.
medium priority thread is also worst case overhead, the Fault tolerance begins with
runnable (Figure 4). The most chained blocking phenomenon processes and memory protec-
common RTOS solution to the may result in a much less effi- tion but extends to much more,
priority inversion problem is to cient system (Figure 6). These especially the need to guarantee
support the priority inheritance blocking factors are added into resource availability in the time
protocol. the computation time for tasks and space domains. Kernel sup-
A mutex that supports prior- in the RMA analysis, poten- port for features like the prior-
ity inheritance works as fol- tially rendering the system ity ceiling protocol give safety-
lows: if a high-priority thread unschedulable. This may force critical system designers the ca-
attempts to take a mutex al- the designer to resort to a faster pabilities needed to maximize
ready owned by a low priority CPU or to remove functionality efficiency and guarantee sche-
thread, the kernel automati- from the system. dulability in their systems.