Xref: utzoo comp.realtime:269 comp.software-eng:2216
Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!uwm.edu!srcsip!klemmer!vestal
From: vestal@SRC.Honeywell.COM (Steve Vestal)
Newsgroups: comp.realtime,comp.software-eng
Subject: Re: Real-Time references wanted
Message-ID: <35545@srcsip.UUCP>
Date: 19 Oct 89 18:03:40 GMT
References: <2925@zaphod.axion.bt.co.uk>
Sender: news@src.honeywell.COM
Lines: 25
In-reply-to: rdoyle@zaphod.axion.bt.co.uk's message of 16 Oct 89 12:55:21 GMT

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