westley@avenger.uucp (Terry J. Westley) (10/18/89)
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. In particular, time is not absolute. It may be microseconds or days, depending on the application. Some people use the term "hard real-time" to distinguish between systems. What they really mean is that their system is more real-time than yours, and that it is harder to design and implement. That's usually true, but not necessarily. Terry J. Westley Arvin/Calspan Advanced Technology Center P.O. Box 400, Buffalo, NY 14225 planck!hercules!westley@cs.buffalo.edu
hs0l+@andrew.cmu.edu (Hugh Brinkley Sprunt) (10/19/89)
Here is the definition I use for "real-time system":
A real-time system is a system containing real-time tasks.
A real-time task is a task that has timing constraints (e.g.,
a deadline). Timing constraints can be hard or soft. A hard
timing-constraint must always be met (otherwise, the system
will fail). A soft timing-constraint should be met if possible,
but missing the constraint does not cause system failure.
An example of a hard timing-constraint would be the processing
of sensor data for an inertial navigation system. If the processing
is not completed within its deadline, the error in the system's
position estimates will become too great for correct system
operation.
An example of a soft timing-constraint would be the processing
for an operator request to show the status of some device being
controlled. Since the operator can tolerate a range of response
times for the request, the task may be assigned a soft-deadline.
It is good to meet the soft-deadline as often as possible. However,
this timing constraint should not be met at the expense of missing
a hard timing-constraint.
The diffiult problem in designing a real-time system (as opposed
to a non-real-time system) is to "guarantee" that the system can
meet its hard timing-constraints under "all" conditions. Once the
hard timing-constraints have been met, the next goal is to meet
the soft timing-constraints "as best as possible" without
endangering the system's hard timing-constraints.
Brinkley Sprunt
Electrical & Computer Engineering
Carnegie Mellon University
sprunt@k.gp.cs.cmu.edu, hs0l+@andrew.cmu.edurdoyle@zaphod.axion.bt.co.uk (Number Six,The Village,6,1) (10/23/89)
Before the discussion on defining characteristics of real-time systems gets too far, here's a summary of the responses I received by mail: -------------------- From: Nick Dunlavey <nickd@cs.qmc.ac.uk> OK. To get you started, let's think about some features of RTS: A controlling system and a controlled system, usually "computer hardware and software" and "sensors, actuators and plant" respectively [...] Also, we want to pick out an environment with which our system interacts, and there is feedback between the environment and system. An RTS needs to be correct, complete, reliable and durable. Most of all, it needs to be responsive, and many (most?) of the responses will be time-critical, and measured in units nearer to milliseconds than to hours. The devices that make up the set of sensors and actuators may be diverse, and less well-behaved than traditional computer peripherals. -------------------- From: jim frost <madd@world.std.com> A system is real-time if it guarantees response within a finite amount of time. Typically this time is in microseconds but some real-time systems need only respond within seconds or minutes. -------------------- From: Tim Jeffries <tjeffrie@axion.bt.co.uk> [...] I have worked in a number of different engineering environments, and in each one I've been concerned with an area called a 'real time' environment. The only things that I would say that the areas had in common, are the perception of the end user as 'getting a result' as quickly as he can see the slowest part of the system completing its task (or as fast as he can comprehend the result if the system is fast enough); and the fact that every situation that I've been in has involved the writing of some code at the machine level. Don't get me wrong, this is not necessarily a significant amount of code, but it does imply that you have quite intimate knowledge of how the engine on which you are working is performing its task. -------------------- From: "Rex A. Buddenberg" <budden@manta.nosc.mil> Beware the can of worms. There are a lot of definitions of 'real time' and I've encountered several -- the reference model work has definitely NOT straightened out this matter. The systems definition is generally in the context of several processes, each with input and output, operating together. Your sub-system, or process, is real-time if it works as fast as the next one over so you don't get a queue of data backed up. The operating systems guys tend to define real time as data driven rather than time-sliced multi-tasking. But unless you have deadline enforcement and dynamic load-shedding, you haven't really completed the problem. (Incidentally, this is a VERY interesting problem in network operating systems.) Some programmers consider anything not written in Cobol to be real time. The Ada definition has real time inadequacies mostly dealing with uncontrolled (timewise, before return) procedures -- again a deadline management problem. Several companies are working on 'real time' tweaks to Ada so it will play ball correctly. In one standards group I worked with, we defined real time as 5 milliseconds application to application for a while. Eventually, we all realized how ambiguous the term was and it's almost disappeared from the lexicon. If you find a good definition that none of these contexts break, I'd like to hear it. -------------------- Finally, Andy Cromarty <andy@ads.com> gave me a reference where he had formally tackled the issue of defining real-time systems. Here's an extract: [...] the defining feature of a real-time system is its ability to guarantee a response after a fixed time has elapsed, where that fixed time is provided as a part of the problem statement. -------------------- Thank you for all your responses. Please continue the discussion by post rather than mail. Richard Doyle -- "Procrastinate now!"