Xref: utzoo comp.realtime:278 comp.software-eng:2245 Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!wugate!uunet!mcsun!ukc!stc!axion!rdoyle From: rdoyle@zaphod.axion.bt.co.uk (Number Six,The Village,6,1) Newsgroups: comp.realtime,comp.software-eng Subject: Re: What makes a system "real-time?" (Summary) Message-ID: <2988@zaphod.axion.bt.co.uk> Date: 23 Oct 89 13:42:26 GMT Sender: news@axion.bt.co.uk Reply-To: rdoyle@zaphod.axion.bt.co.uk Lines: 93 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 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 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 [...] 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" 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 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!"