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
UH2@PSUVM.BITNET (Lee Sailer) (10/19/89)
I've seen two different meanings assigned to "real-time." In corporate data precessing circles, it often just means something like "pretty fast" or "as fast as a person needs it to be." For example, a database might be "real-time" is the user gets the results of a query within a few seconds of hitting the <enter> key. In cases where software is an integral part of some hardware, "real-time" means that certain actions are guaranteed to complete within some known amount of time. For example, suppose that your operating system guaranteed that a file creation action would never take longer than 1/100 second, or that your program would be notified of a joystick motion within 1/1000 second of when it occurred. In this case, you could write software to do things like controlling the flaps of your space shuttle (isn't everyone working on one?) without worrying about whether the flap-controller might get swapped out at a bad time. It gets more complicated than this, because there can be multiple layers of guarantee, and so on. I like the previous responders generic defintion that a real-time system is one where an operation must complete within a certain specified time or else it is an error.
varvel@cs.utexas.edu (Donald A. Varvel) (10/19/89)
In article <89291.133937UH2@PSUVM.BITNET> UH2@PSUVM.BITNET (Lee Sailer) writes:
:I've seen two different meanings assigned to "real-time." In corporate data
:precessing circles, it often just means something like "pretty fast" or
:"as fast as a person needs it to be." For example, a database might be
:"real-time" is the user gets the results of a query within a few seconds of
:hitting the <enter> key.
While non-hard (soft?) real-time is often much better defined than this,
the above describes a segment of the field.
:In cases where software is an integral part of some hardware, "real-time"
:means that certain actions are guaranteed to complete within some known
:amount of time.
This sounds like our working definition of ``hard real-time''. Deadlines
exist, and must be met. Either we can guarantee that at design time or
a correct system cannot be designed.
:In this case, you could write software to do things like controlling the
:flaps of your space shuttle (isn't everyone working on one?) without
:worrying about whether the flap-controller might get swapped out at a bad
:time.
:
:It gets more complicated than this, because there can be multiple layers
:of guarantee, and so on.
I'm confused. Are guarantees not guarantees? ``Oh, but flap-controller
response isn't guaranteed at this level. We are sorry about your airplane,
but our design met the specifications at every level.'' Guaranteed
timeliness of low-level operations can be used to guarantee the timeliness
of higher-level operations, if that's the point.
:I like the previous responders generic defintion that a real-time system
:is one where an operation must complete within a certain specified time or
:else it is an error.
I like the previous responder's definition also, in that it includes my
work but not much of the rest of the field. I see it as excluding correct
real-time implementations of anything that interacts with an unpredictable
environment, since sensory overload is possible in nearly any such system.
Am I misinterpreting the definition?
-- Don Varvel (varvel@cs.utexas.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.edumunck@chance.uucp (Robert Munck) (10/19/89)
In article <1989Oct18.151758.5227@planck.uucp> westley@avenger.UUCP (Terry J. Westley) writes: > A system is real-time when the result of some > operation is wrong because it is late. > That's an elegant definition! Short, understandable, and exactly on the point. I expect I'll be quoting it from now on. >... Some people use the term "hard real-time" to distinguish between systems. An obvious metric would be the maximum rate at which work must be done to meet the basic definition. For example, the ratio between the time period from the stimulus to the time the result would be late to the number of lines of code that must be executed in that period. A given system would have many such ratios for different operations, so we could characterise the "real-timeness" by the highest of them. I know, there are problems with this. The "lines of code executed" measure is a problem because a poorly-coded system would have a higher number here. I really want an absolute measure of the amount of work to be done in the period, but don't know a better way to quantify it. Also, the definition of "late" will have varing degrees of "softness" before the operation is absolutely "wrong." These are all minor technical matters to be worked out in particular cases. The definition is great! -- Bob <Munck@MITRE.ORG>, linus!munck.UUCP -- MS Z676, MITRE Corporation, McLean, VA 22120 -- 703/883-6688
torkil@psivax.UUCP (Torkil Hammer) (10/20/89)
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
jrv@demon.siemens.com (James R Vallino) (10/20/89)
In article <1989Oct18.151758.5227@planck.uucp> westley@avenger.UUCP (Terry J. Westley) writes: >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. Another way I have heard this summed up is: Real time means on time. Whether you have "hard" or "soft" requirements then depends on the severity of the consequences of not meeting "on time" performance. Jim Vallino Siemens Corporate Research, Princeton, NJ jrv@demon.siemens.com princeton!siemens!demon!jrv (609) 734-3331
rdoyle@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!"
wongi@topo.UUCP (Isaac Wong) (10/24/89)
From the IEEE Standard Dictionary of Electrical and Electronics Terms Real Time (1) (general) (A) Pertaining to the actual time during which a physical process transpires. (B) Pertaining to the performance of a computation during the actual time that the related physical process transpires in order that results of the computation can be used in guiding the physical process. (2)................ -- Isaac Wong ....!sun!topo!wongi GenRad, Structural Test Product Div. Milpitas, CA wongi@topo.uucp "You have no reason to believe in this sentence" -Raymond Smullyan