Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!pt.cs.cmu.edu!fas.ri.cmu.edu!dstewart
From: dstewart@fas.ri.cmu.edu (David B Stewart)
Newsgroups: comp.realtime
Subject: Re: What is "real-time" really?
Message-ID: <8178@pt.cs.cmu.edu>
Date: 26 Feb 90 18:37:28 GMT
References: <98692@linus.UUCP> <1990Feb24.195542.21454@newcastle.ac.uk> <98987@linus.UUCP>
Organization: Carnegie-Mellon University, CS/RI
Lines: 104

In article <98987@linus.UUCP> Duncan Thomson writes:
>
>1. Real-time systems must provide answers by some specified time.
>
>2. The time response of the system must be "deterministic", i.e. one must
>   be able to be certain that functions will be performed within specified
>   time limits.
>
I definitely agree.

>I have a couple of problems with these definitions. 
>
>First, it is not enough to say that a real-time system is one which must
>provide answers by a specific time.  Consider a company's payroll system,
>which absolutely must compute the pay of each employee by the 29th of the 
>month (otherwise all hell breaks loose).  This system has "hard" timing
>requirements, but I doubt that many people would want to consider it a 
>real-time system.  There are plenty of other examples, with time scales
>ranging from very short to very very long.  Where does one draw the 
>"real-time" line?

That's a good question.  I would probably say the system is non-realtime
because there is a human that issues the command "Print pay checks".
If the system was completely autonomous, and there was never any
humans involved, then it would be a real-time system.  In such a
case the system would have to make sure the checks are printed on time,
but it cannot do them too early because additional employee information,
such as sick days, new employees, etc. may cause the value of the check
to change.  These timing constraints will then make the system real-time.
However, because we are talking on the order of magnitude of "days"
instead of seconds, most computer systems are fast enough to handle this task
using a conventional operating system, only because they have so little to
do compared to the amount of time they have; what if that one computer
had a million things to do, in a very specific order; would it succeed?
That all depends on how it is programmed ... and at that point it would
be a real-time system.

One note about real-time systems:  Few problems occur on under-used
systems, since there is enough time to do everything.  The timing constraints
start to cause problems on a system that is running at near capacity.
Because applications running on the order of milliseconds are much more
likely to be hitting the full bandwith of the CPU then an application
running on the order of days (it takes lots and lots of stuff to keep
a computer busy for days non-stop), they are the ones most likely to
require the special real-time techniques ... i.e. considering time
as an important factor in all equations.


>
>Second, I don't like the "deterministic" answer too much either, mainly 
>because I doubt that there are many "real-time" systems out there which
>are really deterministic.  

Can you imagine an airplane on auto-pilot with nondeterministic
performance?  Can you imagine the system controlling a production line
that cannot guarantee that everything stays on schedule; what would
your car look like if the robot welds the doors shut because it was
late in starting the job?  The "true" real-time systems are
deterministic; those systems that are not deterministic still require
work until they are.  Nobody wants to buy a non-deterministic system,
who knows what it might do! :-)

>One of the net responses raised the issue of
>"proving" that the system can meet its time constraints.  Given the current
>state of the art, I doubt that there are any real real-time systems which
>have actually be formally proven to be able to meet their timing requirements.
>Or are there?

The "proving" part is the tough one.  Too many of
todays real-time systems have been developed ad-hoc, just testing
and hacking code until it works right;  it is not really possible
to prove that they work right, thus something can go wrong.  Much of the 
research into real-time systems is to remove this ad-hoc method of creating
systems, and replacing them with straightforward programming practices,
that provably have deterministic results in all situations.

>
>I still stick to my definition (until I get convinced of the error of my
>ways by some of you experts out there) that "real-time" means "timing 
>constraints so tight that you have to use special programming techniques
>to meet them."  

The only special technique you need is to consider time into any algorithms
that you develop; the big question is how to you consider it?  Take as an
example an iterative Numerical-Methods algorithm
In a non-realtime environment you would say, "Iterate until
error less than 0.00001" whereas in the real-time environment you
might say "Iterate until error less than 0.00001 OR time > 0.3", in
which case the iteration may stop at slightly lower precision, but
at least it is on time to pass on to the part of the system that 
needs it.  But is this the best way?  What if the non-precise answer
is not good enough, is this method of including time sufficient?
What about for all those applications which are non-iterative,
what do you do then?  Those are the questions that are being asked by
real-time system designers, all in the quest of making real-time
system design much easier and much more predictable than the
old days of trial-and-error.

~dave
-- 
David B. Stewart, Dept. of Elec. & Comp. Engr., and The Robotics Institute, 
	Carnegie Mellon University,  email: stewart@faraday.ece.cmu.edu 
The following software is now available; ask me for details
        CHIMERA II, A Real-time OS for Sensor-Based Control Applications