[comp.realtime] Real-Time references wanted

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
------------------------------------------------------------------------------

stein@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