rdoyle@zaphod.axion.bt.co.uk (Richard Doyle) (10/16/89)
I am currently involved in some work on real-time systems and real-time design methods, and I am looking for references to help me with the following questions: 1. What characteristics of a system make it "real-time"? 2. How many different classes of real-time systems are there, based on an assessment by characteristics? Any help that people can provide in this area will be greatly appreciated. (Please reply by e-mail). Richard Doyle ============================================================================== E-Mail: rdoyle@axion.bt.co.uk Organisation: British Telecom Research Labs (RT3123) Address: BTRL, Rm G23 SSTF, Martlesham Heath, Ipswich, Suffolk, UK. Phone: + 44 473 646654 "I am the new Number Two" ==============================================================================
es@sinix.UUCP (Dr. Sanio) (10/17/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"? > 2. How many different classes of real-time systems are there, > based on an assessment by characteristics? >(Please reply by e-mail). > Richard Doyle Some time ago, I recognized that ideas about "What is a correct rt implemen- tation" widely vary among developers, suppliers etc . So there might be some discussion. If so, either Richard should send a moderated summary or people should post as well. regards, es
rad@aragorn.cm.deakin.oz.au (Robert Alan Dew) (10/18/89)
In article <618@athen.sinix.UUCP> es@athen.UUCP (Dr. Sanio) 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"? #> 2. How many different classes of real-time systems are there, #> based on an assessment by characteristics? # #>(Please reply by e-mail). #> Richard Doyle #Some time ago, I recognized that ideas about "What is a correct rt implemen- #tation" widely vary among developers, suppliers etc . So there might be some #discussion. #If so, either Richard should send a moderated summary or people should post #as well. #regards, es I would also appreciate the answers posted for the above 2 questions. Robert Dew rad@aragorn.cm.deakin.oz.au
vestal@SRC.Honeywell.COM (Steve Vestal) (10/20/89)
> 1. What characteristics of a system make it "real-time"? > 2. How many different classes of real-time systems are there, Here are some proposed definitions that have been kicked around here: real-time: System requirements include quantitative specifications of performance. hard real-time: Quantitative performance requirements are given as inviolable, fixed deadlines (e.g., a periodically scheduled task, once dispatched, must absolutely positively complete prior to the next time it is dispatched.) soft real-time: Quantitative performance requirements are given as statistical measures (e.g., under a postulated missile arrival rate, the system must complete the "processing" of an incoming missile within time T with probability P after that missile is detected). "If it's late it's wrong" succinctly captures the second definition. However, it might also be useful to adjust it just a bit to say "if it's late it's a fault." The reason is that in some systems the very occasional missing of a deadline can be patched over to provide a degree of fault-tolerance. For example, in some control systems, if a task reaches a deadline without completing then it may be acceptable to output an approximate value every great once in awhile.
rlk@telesoft.com (Bob Kitzberger @sation) (10/20/89)
In article Richard Doyle writes: > > 1. What characteristics of a system make it "real-time"? > I'll throw in an anecdotal description of real-time systems... Here's my favorite quotation on the subject, which appears in DeMarco's foreword to _Strategies For Real-Time System Specification_ by Hatley & Pirbhai : "Most systems people use the term ``real-time'' rather loosely," the young manager said. [...] "They say they've got a real-time constraint when they're worried about impatient insurance brokers or bankers sitting in front of their terminals. A real-time system, in their minds, is just one that needs to be `quick as a bunny'. If they fail to meet that constraint, their users might be inconvenienced or even annoyed. When we use the term, it means something rather different." Her coworkers began to smile, knowing what was coming. "We build systems that reside in a small telemetry computer, equipped with all kinds of sensors to measure electromagnetic fields and changes in temperature, sound, and physical disturbance. We analyze these signals and transmit the results back to a remote computer over a wide-band channel. Our computer is at one end of a one-meter long bar and at the other end is a nuclear device. We drop them together down a big hole in the ground and when the device detonates, our computer collects data on the leading edge of the blast. The first two-and-a-quarter milliseconds after detonation are the most interesting. Of course, long before millisecond three, things have gone down hill badly for our little computer. We think of *that* as a real-time constraint." .Bob. -- Bob Kitzberger Internet : telesoft!rlk@ucsd TeleSoft uucp : ...!ucsd.ucsd.edu!telesoft!rlk 5959 Cornerstone Ct. West at&t : (619) 457-2700 x163 San Diego, CA 92121-9891 "It's a damn poor mind that can only think of one way to spell a word." -- Andrew Jackson ------------------------------------------------------------------------------
eberard@ajpo.sei.cmu.edu (Edward Berard) (10/20/89)
I realize that most of the people who were involved in programming
during the 1960s and 1970s "have all gone on now to a much happier
place" (;-)). However, there are some terms which originated in those
times which are still used today, e.g.:
- "wall time": The origin of this term had to do with "a clock
on the wall." It was meant to refer to the actual amount of
time which passed while a piece of code was executing.
- "CPU time": This term referred to the amount of time which
the computer (i.e., the CPU) devoted specifically, and
exclusively, to a piece of executing code.
It was not uncommon to hear people say things like: "The wall time on
that sucker was 15 minutes, but, you know, the CPU time was only 7
seconds." Obviously, "wall time" and "CPU time" helped to determine
the "real" capabilities of a computer system once computers began to
handle two or more "jobs" at once. (Although most folks these days
think of Apple and NeXT when they hear the word "jobs," there was a
time when "job" referred to a complete unit of work which was submitted
to the computer, or, more accurately, to an operator. 8-})
Somewhere in the distant past (probably the 1960s), someone got the
idea that a computer program, given the proper "peripherals," could
interact with things outside the computer, _while_ _the_ _program_
_was_ _executing_. Thus we were introduced to a "new kind of time":
- "real time": A real time program is a program which is aware
of, and/or synchronized with, events which take place in the
"real world" (i.e., "outside" of the computer) while the
program is executing. Said another way, the program is aware
of the passage of "real time" during its execution.
There are some interesting consequences of this definition:
1. We notice a fundamental characteristic of "real time"
applications, i.e., they _must_ be connected to the outside
world (directly or indirectly). If a piece of code is very
small, and executes very quickly, but is not connected to
the outside world, it is not a real time program.
2. All interactive programs (usually taken to mean programs
which interact with human users during execution) are "real
time programs."
3. Programs which must very closely simulate real life
conditions, especially situations where reaction time is
critical, and are interactive, also fall into the category
of real time software. Aircraft flight simulation software,
even though it executes on "minicomputers" is an example of
this type of software.
4. Of course, much of the software in embedded systems is real
time software. (An embedded computer is a computer which is
part of some larger piece of hardware, e.g., the computers
embedded in aircraft, automobiles, wristwatches, microwave
ovens, pacemakers, and, yes, even larger computers.)
It is most often in the case of embedded applications that
we hear of severe memory and time constraints. However,
these alone do not qualify an application as real time.
There must be some direct, or indirect, connection with the
outside world.
[One of the recreational activities which real time programmers often
participate in is a "real time rank out," a game characterized by much
blustering and posturing on the part of the participants. (The
testosterone and estrogen of the players often reach elevated levels.)
The central idea is to impress your opponent with the fact that _your_
software had to accomplish an ungodly amount of processing, with only
a minuscule amount of resources. The only rule is that there are no
winners. ;-)]
There are characteristics commonly found in real time systems, e.g.:
- infinite loops: While infinite loops are discouraged in
non-real-time systems, they are very common in real time
systems. Consider, for example, the fuel gauge in an
automobile. The software associated with the fuel gauge
continually tests the level of fuel in the tank, and
continually reports this to the fuel gauge.
- concurrency: The "real world" is concurrent, therefore, many
real time applications reflect this. An example would be the
software which is used in modern aircraft autopilots. Based
on such things as the desired course, the current altitude,
the current level of thrust, and the current heading,
autopilots help guide the aircraft. Many sensors scattered
throughout the aircraft may all be reporting simultaneously
to the autopilot.
However, neither of these characteristics _alone_ makes a system real
time.
-- Ed Berard
(301) 353-9652stein@dhw68k.cts.com (Rick Stein) (10/21/89)
In article <2925@zaphod.axion.bt.co.uk> rdoyle@zaphod.axion.bt.co.uk writes: > 1. What characteristics of a system make it "real-time"? I define a real-time system as any simulation requiring that a finite amount of work be accomplished in some specified, predetermined interval of time. > 2. How many different classes of real-time systems are there, > based on an assessment by characteristics? Classification by taxonomy is useful, but only for discussion. Imbedded or non-imbedded; those are the only ones that I know of. I think about real-time systems as consisting of some combination of synchronous and asynchronous processes. Each may rely on interrupts, polling, or message passing to operate. While I'm on the subject, does anyone know of any references to real-time multicomputer systems using transputers? I'm working on a book entitled "Real-time Multicomputer Software Systems" and I'm curious to know if any one may have a requirement for such a beastie. > > Richard Doyle -- Richard M. Stein (aka, Rick 'Transputer' Stein) Sole proprietor of Rick's Software Toxic Waste Dump and Kitty Litter Co. "You build 'em, we bury 'em." uucp: ...{spsd, zardoz, felix}!dhw68k!stein
korenek@ficc.uu.net (Gary Korenek) (11/17/89)
In article <7861@charlie.OZ>, rad@aragorn.cm.deakin.oz.au (Robert Alan Dew) writes: > In article <618@athen.sinix.UUCP> es@athen.UUCP (Dr. Sanio) 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"? > #> 2. How many different classes of real-time systems are there, > #> based on an assessment by characteristics? > ... Here's my interpretation of "real time" and "real-time computer system": Real-time: Exactly that. What's going on "as it occurs". Broadcasters announce football games (for example) in real-time. What the play-by-play announcers say has particular value because the game is happening *now*. Real-time computer system: A computer system that measures each event in a process as the events occur (in "real-time"). Possible processes where real-time measurement is desirable are: pipe line, refinery, oilfield, combustion engine, aircraft, building enviroment (air conditioning/heating), electrical power generation (and distribution), manufacturing. In general, the computer system acquires data from the process via instrumentation connected to certain physical parts of the process (these are called "points"... it's a point that a measurement is taken). Two possible categories of real-time computer systems are open-loop and closed-loop. An example of an open-loop system: the system obtains measurements from points in the process, converts the data from digital "instrument" format to "human usable" format, and communicates the data values to whoever is interested in seeing it (typically people who are responsible for the "quality" or "results" of the process). These people can then take the data and either ignore it, or do something with it (go manually open or close a valve, as an example). If the open-loop system includes a means to *control* (make chages to) the process, the responsible people may enter commands for the system to send out to the process (the system can open or close a valve, as an example). The main points to the open-loop system are: The system obtains data from the process, reports the data to responsible people, who then can elect to either to take action (alter the process and the result of the process) or do nothing. People are "in control" of (and are responsible for) the process. The goal is to have the process produce the desired result. An example of an closed-loop system: the system obtains measurements from points in the process. Based on this data, the *system itself* decides if the process should be altered or left alone (the system itself is responsible for the desired result of the process). If the system decides the process should be altered, it sends commands out to the process. The system obtains more measurements from the process (which is now changing because of the commands previously sent out), again decides if the process should be altered, etc. The main points to the closed-loop system are: The system obtains data from the process, and based on this data decides either to take action or do nothing. The system itself is "in control" of (and is responsible for) the process. Again, the goal is to have the process produce the desired result. Note: Some real-time systems are combinations of open-loop and closed- loop systems. There may be one or more closed-loop systems that control an individual part of a process. The closed-loop controller(s) are connected to the open-loop system in such a way that when a responsible person enters a command into the open-loop system (to alter the process), the open-loop system sends the command to the closed- loop controller, which then commands that part of the process to change. In this case, people *and* equipment share responsibility for the process to produce the desired result. In summary, these are real-time systems because they deal with events that occur within a process *as the events occur* (in real-time!). -- Gary Korenek (korenek@ficc.uu.net) | This space Ferranti International Controls Corp. | intentionally Sugar Land, Texas (713)274-5357 | left blank