











|
Real-Time Software Awareness
Enough Knowledge To Be Dangerous

Defining The Fundamental Terms
Embedded real-time software is
often referred to as the most difficult software to get right. These key
terms were first defined in the 60's and their operational meanings haven't
changed since then. Specifically:
Real-Time System:
a system that controls an environment by receiving data, processing them,
and taking action or returning results sufficiently quickly to affect the
functioning of the environment at that time.
[ref: James Martin, Design of Real-Time
Computer Systems, Englewood
Cliffs, NY: Prentice-Hall, 1967.]
But we can take a more direct
approach and define the term as it relates to what happens if such a system
fails to respond "sufficiently quickly":
Real-Time System:
A system that must satisfy explicit (bounded) response time constraints
or it will fail.
[ref: Phillip A. Laplante, Real-Time Systems
Design and Analysis; An Engineer's Handbook, New York, NY:
IEEE Computer Society Press, 1992.]
What makes real-time systems so
hard to get right? They typically have these "challenges" to the developer:
- Modern real-time systems are usually embedded in devices or
mechanisms for which the software most monitor data and issue
controlling commands.
- Many real-time systems interact with a "user" for whom they
perform a needed function.
- Real-time systems frequently require the concurrent processing
of multiple inputs. Beyond the most trivial examples, real-time
systems include both periodic (traditionally called "cyclic")
processing at multiple frequencies and aperiodic (driven by
sporadic events) processing.
- Real-time systems are frequently constrained by physical
limitations. These normally include processor resources (memory
and throughput), response times, input/output channel bandwidths,
storage device capacities and transfer rates, and so forth.
- Real-time systems frequently have various sensor and intersystem
interfaces that provide continuous or periodic input and actuator
or intersystem interfaces that must be driven periodically. The
sampling interval tolerances, event response intervals, and
response precision are often critical. Permitted variances in
responses are often required to be small as well.
- The reliability of the software in such systems usually must be
very high. This may be obvious when considering military systems,
but the cost of correcting a software problem in a common
appliance controller is overwhelming after a million units have
been sold and distributed nationwide.
[Derived from: John R. Ellis,
Objectifying Real-Time Systems,
New York, NY: SIGS Books,
Inc., 1994.]
Now let's look at a definition
of the other key term in this phrase:
Embedded Computer System:
- A computer system that is physically incorporated into a larger
system whose primary function is not data processing.
- It is integral to such a larger system from a design,
procurement, or operations viewpoint.
- Its outputs generally include information, computer control
signals, and computer data.
[Derived from: Subcommittee on Software Engineering Standards, Technical
committee on Software Engineering,
IEEE Computer Society: "Software
Engineering Terminology - Draft of 23 March 1978"]
So, when we combine these
definitions, we find that an embedded real-time system is one
in which the computer is a component of and usually providing a controlling
function for some larger system. The software running in the embedded
processor is expected to respond to data inputs, often derived from various
sensors, within some predetermined time constraints. The bound on the
response time constraint is often called a deadline.
Not yet convinced that developing
such systems should be entrusted to only someone with considerable real-time
system experience? Let's go on...
Learning More
Visit the following
retiSoft
pages to learn more about the various aspects of developing and embedded
real-time system, and especially the software for such a system.
|