"Most systems people use the
term real-time rather loosely," the young manager said. We were seated
over dinner with three members of her staff and some other managers who took part
in the day's seminar. "They say they've got a real-time constraint when they're
worried about impatient insurance brokers or bankers sitting in front of their
terminals. A real-time system, in their minds, is just one that needs to be 'quick
as a bunny.' If they fail to meet that constraint, their users might be inconvenienced
or even annoyed. When we use the term, it means something rather different."
Her co-workers began to smile, knowing what was coming. "We build
systems that reside in a small telemetry computer, equipped with all kinds of
sensors to measure electromagnetic fields and changes in temperature, sound, and
physical disturbance. We analyze these signals and transmit the results back to
a remote computer over a wide-band channel. Our computer is at one end of a one-meter
long bar and at the other end is a nuclear device. We drop them together down
a big hole in the ground and when the device detonates, our computer collects
data on the leading edge of the blast. The first two-and-a-quarter milliseconds
after detonation are the most interesting. Of course, long before millisecond
three, things have gone down hill badly for our little computer. We think of that
as a real-time constraint."
I had been lecturing that
day on the use of data flow modeling techniques for system specification. There
had been the odd question about the use of such techniques for real-time systems,
and my (typically glib) answer was that the techniques were applicable, though
perhaps not totally sufficient. After all, my own earliest work with data flow
modeling had been at Bell Labs and at La CEGOS Informatique, in both cases working
on real-time systems. Or were those real-time systems? Maybe they were really
just systems that needed to be 'quick as a bunny'? The young manager's graphic
example had left me in some doubt.
It has always been
clear that something more than the basic tools of structured analysis are needed
to specify timing and synchronization requirements. In the simplest case, that
"something" could be as trivial as a set of textual annotations, perhaps
directly on the data flow diagrams. But for even slightly more complicated cases,
there is the possibility of linked timing and ordering constraints that may involve
a dozen or more system components. There has been a need for a systematic way
to deal with such constraints.
Over the last few years,
I began to hear favorable reports of some real-time modeling techniques called
the Hatley/Pirbhai Extensions. This multi-perspective approach combined data flow
decomposition with model components constructed in control- and information-space.
The result appealed to me as a specification technique that was not only applicable,
but for most cases sufficient for real-time systems. I contacted the developers
and started to try out their extensions.
The act of writing
a Foreword is a kind of endorsement. It says, if nothing else, "Read this
book, it couldn't hurt." In this case, I can be considerably more positive
than that. I can tell you that I learned valuable new techniques from Hatley and
Pirbhai, and that I apply them regularly on real-world real-time applications.
