Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uakari.primate.wisc.edu!polyslo!csun!psivax!torkil
From: torkil@psivax.UUCP (Torkil Hammer)
Newsgroups: comp.realtime
Subject: Re: What makes a system "real-time?"
Message-ID: <2910@psivax.UUCP>
Date: 19 Oct 89 20:41:48 GMT
References: <1989Oct18.151758.5227@planck.uucp>
Reply-To: torkil@psivax.UUCP (Torkil Hammer)
Organization: Pacesetter Systems Inc., Sylmar, CA
Lines: 107

In article <1989Oct18.151758.5227@planck.uucp> westley@avenger.UUCP (Terry J. Westley) writes:
#In article <2925@zaphod.axion.bt.co.uk> rdoyle@zaphod.axion.bt.co.uk writes:
#>I am currently involved in some work on real-time  [..]
#>	1. What characteristics of a system make it "real-time"?
#
#Here's the definition I use for what makes a system "real-time:"
#
#	A system is real-time when the result of some
#	operation is wrong because it is late.
#

This is one of the possibilities, but real-time is a fuzzy buzzword.

There are so many classes of systems being buzzed.

The following are my thoughts on how to classify real-time systems:

1.  Observation, calculation and correction on the fly.  This is the
    classical real-time definition.  Examples include airplane control
    systems which merges human input and autonomous motor control which
    doesn't.  Also,
    Progrmmable controllers, ranging from disk drive, optical readers and
    printers to washing machine applications.  These do not accept human
    corrective input once they are started, except for reset.

2.  Ticket booking and related systems which have multiple data entry
    points and potential resource clashes.  Airline reservation, Bridal
    registries and computer contolled warehouses fall in this category.

3a. Anything where an operator gets impatient and does something stupid
    if the screen doesn't move fast enough.  This is the natural realm
    of emergency containment systems: 911 telephone, police dispatch,
    onboard police car database access, surgery room medical database access.

3b. Anything where a higher speed earns a higher price.  Spreadsheets
    come to mind.  A slow spreadsheet can make the operator blow smoke
    through his ears but there isn't anything stupid he can do.

Class 1 is what I will call physical real time.  What distinguishes
the class is that too fast is as disastrous as too slow.
This class can be further differentiated based on the relationship
between required accuracy and required resolution.
1a. In a true lockstep system, such as a waveform synthesizer or a
redundant dual cpu setup, you want more accuracy than just the
resolution.  No problem, since the CPU always changes its output
pin at the same point within a machine cycle.
1b. In fixed timeslot situation, such as a disk controller, you
have a time window with hard edges.  As long as you are in the
window, close enough is good enough, but everything is lost if
you drift outside the slot.
1c. In a soft window situation, such as an airplane autopilot,
there is a penalty proportional to the timing inaccuracy, but
no well-defined safety envelope.
1d. In combined situation, such as an engine fuel metering
system, there is a premium for being exactly on time, and a cost
proportional to the inaccuracy up to a hard safety limit where
everything is lost because the motor backfires.
You might also want to characterize based on short term stability
(waveform generator) and long term (time broadcasts and electric power).
This general class is the original real-time class, known for at least a
century since people started regulating steam engines, and formalized
at some university by a treatise on motor governers.  Does anybody
have the exact reference?

What distinguishes class 2 is simultaneous access to a shared
resource in physical real time, leading to various jamming problems.
What matters here is a safeguarded access sequencing, but oh so many
system managers have skimped on that one and put in faster
CPU's because they think they "minimize the size of the windows
of vulnerability", but they get burned just the same.  Some think
a little more and figure that privilege or priority leveling will
solve the problem - and get burned as well.  (Current theory is
that only semaphores operating at one higher level of abstraction
than the access are safe in the general case).
A related problem is what we called the 'deadly embrace' where 2
processes are waiting (indefinitely) for each other to relinquish
control over a shared, but not time-sharable peripheral.
This class is the first of the mind-bogglers, when computing suddenly
went outside the realm of just programming and soldering.
It was formally recognized around 1963.  Does anybody know the
exact reference? (I think it was Dijkstra or Naur)

What distinguishes class 3 is urgency.  Penalty for being late,
no penalty for being early, no reward for being on time,
and no access clash.
The subdivision is that 3a has a hard limit while 3b doesn't.
In 3a, the faster the safer but fast enough is good enough.
In 3b you get more performance [and hype] for more money.
3c. Again there are combinations, such as an air traffic controller,
where there is a hard limit of crashing or misdirected planes, and
a penalty of operator aggravation proprotional to the delay.
This class is the Buzzing New Age of 'real-time', unheard of
before 1988 (I think).

Speaking of buzzwords:  'real-time' often is babbled into
'real-time-constraint (system)', and a related buzzer is
'embedded system' which depends a lot on whose bed you are in.
'Multi processor', a buzzword from the 1960's, means sometimes
timesharing on one cpu, sometimes cooperating cpu's and
sometimes redundant cpu's.

Some general cleanup and naming conventions are sorely needed.
It would also be nice to have a better classification system than this.

Comments are invited.

Torkil Hammer