Military Embedded Systems Spring 2005 Volume 1 Number 1

Software
MILITARY EMBEDDED SYSTEMS Resource Guide
What is real time and
why do I need it?
By Steve Furr
Not all systems need an RTOS; but of
those that do, does the designer know
what about the system is “real time”?
An RTOS can play a key role in determining
how a system runs, and it’s
critical to choose an RTOS based upon
system requirements.
Real time is a sometimes misunderstood
and misapplied property of operating systems.
Moreover, there is often disagreement
as to when a Real-Time Operating
System (RTOS) is needed. For instance,
when designing an industrial control
system or medical instrument, most engineers
and system designers would concur
that an RTOS is necessary. However,
questions arise, when it comes to other
applications, such as tracking systems
and a variety of in-vehicle devices. Is an
RTOS needed here? Or would a generalpurpose
OS such as Linux or Windows do
the job? Often, such systems do require
an RTOS, but the issue isn’t recognized
until later in the design phase.
Therefore, it’s important to understand
why the real-time capabilities provided
by an RTOS are not only beneficial, but
necessary for a wide variety of embedded
systems. For instance, consider a system
where users expect or need immediate
feedback to input. With an RTOS, a developer
can ensure that the system always
provides feedback in a timely fashion,
even when the system is handling many
other compute-intensive activities. The
user is never left wondering whether the
system has, in fact, accepted the button
push or recognized the voice command.
In a nutshell, an RTOS allows developers
to control how long a system will take
to perform a task or respond to critical
events. Deadlines can be met within predictable,
and wholly consistent, timelines,
even under heavy system loads.
What, exactly, is real time?
To appreciate what real time is, what it
isn’t, and why it’s beneficial, let us start
with a basic definition of a real-time system,
as defined in the Frequently Asked
Questions for the comp.realtime newsgroup
(news://comp.realtime or groupsbeta.google.com/group/comp.realtime):
“A real-time system is one in which the
correctness of the computations not only
depends upon the logical correctness of
the computation but also upon the time at
which the result is produced. If the timing
constraints of the system are not met, system
failure is said to have occurred.”
Real time, then, is a property of systems
where time is literally of the essence. In a
real-time system, the value of a computation
depends on how timely the answer is.
For example, a computation that is completed
late has a diminishing value, or
no value whatsoever, and a computation
completed early is of no extra value. Real
time is always a matter of degree, since
even batch computing systems have a real
time aspect to them. Nobody wants to get
their payroll deposit two weeks late!
Problems arise when many activities compete
for a system’s resources; in fact, this
is where we begin to apply the real-time
property to operating systems. In implementing
any real-time system, a critical
step in the process will be the determination
of a schedule of activities that enables
all activities to be completed on time.
Any real-time system will comprise different
types of activities: those that can be
scheduled, those that cannot be scheduled
(for example, operating system facilities
and interrupt handlers), and non real-time
activities. If non-schedulable activities
can execute in preference to schedulable
activities, they will affect the ability of the
system to handle time constraints.
Hard vs. soft real time
Often, a distinction is made between hard
and soft real time. A hard real-time constraint
is one for which there is no value
to a computation if it is late and where
the effects of a late computation may be
catastrophic. Simply put, a hard real-time
system is one where all activities must be
completed on time. A flight control system
is a good example.
On the other hand, soft real time is a property
of the timeliness of a computation
where the value diminishes according to
its tardiness. A soft real-time system can
tolerate some late answers to soft realtime
computations, as long as the value
hasn’t diminished to zero. Deadlines may
be missed, but the number and frequency
of such misses must typically comply
with Quality of Service (QoS) metrics.
Frequently, soft real time is erroneously
applied to OSs that cannot guarantee
computations will be completed on time.
Such OSs are best described as quasi real
time or pseudo real time OSs in that they
execute real-time activities in preference
to others whenever necessary, but don’t
adequately account for non-schedulable
activities in the system. Put simply, soft
real time shouldn’t be confused with non
real-time.
Positive impact
Traditionally, RTOSs have been used in
hard real-time environments where failure
to perform activities in a timely manner
can result in harm to persons or property.
But an RTOS can be just as useful
for applications that must meet QoS guarantees,
particularly when failure to do
so could result in financial penalty. This
covers obvious service scenarios, such
as “30 minutes or it’s free,” but it also
includes intangible penalties, such as lost
opportunities or loss of market share.
Moreover, real-time technology can be
applied to conventional systems in ways
that positively impact the user experience,
either by improving the perceived
response to certain events or by ensuring
that important activities execute preferentially
with respect to others in the system.
For instance, consider a device that pres-
36 / 2005 MILITARY EMBEDDED SYSTEMS Resource Guide