Principles of Real-Time
Software Engineering
Chapter 1
Introduction:
This is a book about real-time software system development. It is distinct
from books about operating systems, networks, languages, scheduling theory,
distributed systems, CASE tools and programming languages. Wile these other
topics are discussed within the text, they are not the focus of the book.
This book is about engineering. It is an attempt to clarify the
role of the software system engineer in the design of software where its
operational correctness is dependent on its ability to work within time
and machine capacity constraints identified prior to its design. The view
expressed here is that real-time software engineers are responsible creating
product designs which address not only the functional characteristics of
the product, but the time and storage constraints as well. The created
design is seen as a tool for the system developers, rather than a milestone
document for the customer.
Design:
Here a "design" is regarded as the instrument for reasoning about how
a system works. Reasoning about a system using a design as abstraction
is distinctly different from the common practice of system developers who
function as artisans, relying on intuition for structural decisions and
external appearance for judging correctness.
This is not to say that craft should be absent from a real-time
system design. To be effective an engineer has to have a well developed
understanding of algorithms, languages, operating systems, database engines,
and the other system building blocks. Becoming familiar with components
may require some degree of tinkering. Moreover, a creative edge is a basic
prerequisite for solving new problems. But the prime contribution of the
engineer should not be to pick out components based on a hunch, nor to
jot down data and control flow diagrams in an attempt to portray an attractive
design. The prime contribution of the engineer should be to present a valid,
veritably correct solution prior to the construction of the system.
So what does a valid, verifiable design for a real-time system
look like? There are a handful of software engineering texts which focus
the student's attention on design languages. Students are sometimes led
to believe that the notations themselves are the embodiment of design.
Some of these texts promote particular graph-oriented languages for expressing
data and control flow. Others promote non-graphical design languages. Ada,
for example is promoted as a design language. While there is no doubt that
Ada Program Design Language (PDL) plays an important role in Ada software
development, it is no more a "design" than is a blueprint of a section
of a bridge. It serves to direct implementation, not understanding, just
as a blueprint serves to direct fabrication. One can not compute structural
strength from a blueprint. Information about the strengths and thermal
properties of materials must be added to the blueprint if you wish to compute
structural strength. Similarly, information about scheduling and performance
must be added to PDL in order for analysts to know whether or not time
constraints will be met. Likewise, information about memory usage is needed
to verify that the software won't run into memory problems.
Verifying Correctness:
The general notion of verifying the correctness of a design for a time
and memory constrained system is glaringly absent from most treatments
of real-time system development, with the exception of recent texts on
Rate Monotonic Analysis (RNM). While these do acknowledge the problem of
scheduling verifiability and also introduce the concept of verifiable scheduling
techniques, they deal in only one aspect of real-time: rate monotonic hard
real-time scheduling.
The issue is not at all the form of the design. The issue is its
substance. And what is the substance of a good design? As an analogy, consider
this situation from civil engineering: A high bridge is to be built across
a mile-wide, fast river. The bridge is to carry four lanes of vehicular
traffic and it must be high because the river has a canal adjacent to it
that is used for oceangoing going cargo ships.
An Approach:
How do the bridge developers approach this challenge? One way would
be to hire an artist to draw a set of pictures of a proper looking bridge.
The first picture would show the entire bridge as it might look to an individual
standing two miles away from the structure. The artist would continue by
drawing close up details of what the beams, road surface and other visible
features might look like. When the artist's work is complete, a few hundred
expert blacksmiths can be hired to hammer out the individual parts and
connect the parts together. It would be up to the blacksmiths to figure
out how to put the components together and make the bridge stand, and to
test the bridge for "strength" as it gets assembled. A retired blacksmith
can be hired to make decisions about materials and guesses about how long
it will take to put up the bridge. A concrete crew can be assigned the
problem of the footings. A road surfacing team can be hired later to put
a good layer of asphalt down as a road surface. Finally, all the blacksmiths
could drive the heaviest cars they could find over the bridge to make sure
it is safe enough for general use.
Foolish? of course! It would take a great stroke of luck to erect
a bridge this way on budget, and on schedule, that could carry its load
safely without constant attention from a team of maintenance blacksmiths.
It is likely that the bridge will lean, sway in the wind, buckle on hot
days, and that sections will fail without warning even though the bridge
once held heavier loads during testing. Indeed, it is doubtful that a bridge
like this could ever be certified as safe because knowledge of how load
is distributed throughout the bridge may not be attainable.
No doubt bridges and other structures have been built using the
artisan approach. Success is probable for small scale projects, but not
for large scale, complex projects like the bridge described.
The Way:
What we really need is to start with an assessment of soil mechanics,
wind and snow load, and river dynamics. (Is there a tide? Is this the Mississippi?)
From these results an engineering team can assemble a picture (a model)
of a bridge whose static and dynamic properties are knowable analytically.
The physical properties of every piece of the bridge can be computed prior
to spending money on fabrication. This analytical insight is the tool we
need to certify the "correctness" of the bridge. If the bridge is built
according to plan, it will work. As the bridge is erected, its components
can be individually tested within the load range to which they will be
subjected in order to verify the correctness of individual pieces. As assemblies
are placed on the incomplete structure, strain gauges can measure loading
effects on critical members to verify that deformations are within expected
limits.
The point here is that engineering practice involves an analytical
understanding of the work to be accomplished. A design of a system is the
vehicle for reasoning about the system. When we rely on an instance of
a system as a vehicle for reasoning about how it works, we become restricted
to conducting experiments on the system's behavior to answer questions
about its character. By contract, a good design gives us the opportunity
to predict system behavior for any situation.
Real-Time System Engineers:
Real-time system engineers are quite similar to civil engineers. Both
disciplines need to produce . good designs. While the civil engineer is
constrained by the environment in which the bridge is to be built, so too
is the real-time system engineer constrained by the environment in which
his or her product is to function. But instead of soil mechanics, tide,
snow and wind, the real-time system engineer faces languages, compilers,
operating systems, networks, CPU and memory characteristics. Instead of
traffic load issues, there are function activation, scheduling, and process
requirements. And, just as civil engineers linearize their characterizations
of critical properties (such as material elasticity) so too can real-time
system engineering (such as CPU utilization). This text presents one particular
linearization involving a few practical techniques for assessing characteristics
of components that matter to real-time system designers. Others are possible.
The substance of a good design can be documented in a number of
ways. Graphic methods showing activity decomposition, data, and control
flows are appropriate if they capture information which makes verification
and validation possible. PDL formats and standard English are likewise
suitable. The format used should fit the organization's needs in regard
to project size, experience, support tools and management style. This text
does not address the selection of design documentation format except to
point out some obvious deficiencies in mainstream formats. But even these
deficiencies can be overcome once the design team and management are aware
of them and augment the mainstream notations with appropriate time and
spatial constraint information.
As you read through this text it is best to give it a careful
first. reading so that you become acquainted with the subtitles of real-time
engineering concepts. Working through the problems will reinforce your
understanding and build up your acumen. When you get to sections discussing
Computer-Assisted-Software Engineering (CASE) tools you may be fortunate
enough to have access to professional quality tools through your employer
or university affiliation. If you do, make use of whatever you have. For
those with no CASE tool access, paper and pen work very well.
A Simple Exercise:
Here Is on opportunity to collect your thoughts on how a design
should be created and how It should be used. When you complete the exercise
fold your results and tuck them into the book. When you are done with the
book, repeat the exercise and compare your final results with your initial
results.
Software design is a vital step in the string of activities which
form the software development process. But the software development process
never gets started for you unless the company you work for happens to have
won the competition for the development contract. No one wins a software
development competition without a good proposal! An important ingredient
of the proposal is the section where you describe how you are going to
design the real-time software.
Assume you are on a proposal team. Your job is to explain how
you are going to design a real-time software system controlling something
critical. Perhaps the system is a component of an aircraft or submarine.
The software is stimulated with a number of periodic and non-periodic data
packets which must be processed, and which produce time constrained outputs.
Figure 1-1 is a generic representation of such a system. Note that some
of the processes make use of a disk to store or retrieve data.
-
Write one page or more describing how a real-time operating system is different
from normal commercial operating systems like UNIX.
-
Write one or more pages on how your company designs real-time software.
You can be as creative as you wish. Include the notion of fault tolerance.
You have to be convincing if you want to win the contract!
Evaluation Criteria:
-
Does the proposal describe how the real-time design will be conducted,
or does it simply say experienced people will do the design ?
-
How does the proposed effort expect to validate the design for correctness
with regard to memory and performance constraints? (Or does it just say
that it will validate without explaining how?) Does the proposed approach
defer the issues of time and memory constraints to integration time? (E.g.,
does it say that first they'll get it to "work" and then worry about making
it "fast enough" later?)
-
Does the proposal regard real-time operating systems as fast, efficient
and reliable versions of mainstream multitasking operating systems, or
is there a precise list of characteristics essential to how they propose
to do the design?
-
If the proposal states that a particular scheduling algorithm is to be
used, does it explain how this will be done for disk accesses? Does it
simply say that a particular scheduling algorithm will be used or does
it explain how it will be applied?
|