Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcsun!sunic!tut!kurki!rks
From: rks@kurki.tut.fi (Kurki-Suonio Reino)
Newsgroups: comp.realtime
Subject: Re: What is "real-time" really?
Message-ID: <11347@etana.tut.fi>
Date: 26 Feb 90 12:17:44 GMT
References: <98692@linus.UUCP>
Sender: News@tut.fi
Reply-To: rks@kurki.tut.fi (Kurki-Suonio Reino)
Organization: Tampere University of Technology, Finland
Lines: 41

In article <98692@linus.UUCP> duncant@mbunix.mitre.org (Thomson) writes:

>Someone asked me recently what real-time really means.  After some thought,
>I answered that real-time systems were simply those {in which the 
>timing constraints were so tight that speciall programming techniques
>were required.

Properties like this should best be understood as properties of models, not
of "real" systems.  Of course, they can then be used of "real" systems also,
whenever the associated models are found useful in their description.
The question, whether a payroll system, for instance, is real-time, therefore
reduces to the question, whether real-time description techniques offer
any advantages for it.

Before trying to define real-time I think it is important to make the 
distinction between "transformational" and "reactive" systems, as Pnueli, 
for instance, does.  A transformational system is supposed to compute a final 
result on some input data, while a reactive system maintains continued 
interaction with its environment.  Real-time systems belong to the latter 
category, which cannot even theoretically be reduced to transformational
systems.  For transformational systems it makes sense to talk about their 
efficiency, but even with stringent time requirements they would not be 
real-time.  

When the specification of a reactive system determines the computations
that are possible in the system, there are two basically different ways
to deal with time requirements.  One is to understand them as efficiency
requirements that are outside the basic model of execution.  A computation
may then depend on whether some time limits are met or not, but there is
a possible computation in both cases.  The term (soft) real-time seems to
refer to these systems, where computations depend on the real time.

The other possibility is to preclude totally the missing of some deadlines.  
In that case the model defines no computations for such cases, and it is the 
implementor's task to guarantee that an implementation has only computations 
that are defined in the specification.  This seems to be what is meant by 
(hard) real-time.

Comments?

Reino Kurki-Suonio