Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!pt.cs.cmu.edu!sei!ajpo!eberard
From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Newsgroups: comp.software-eng
Subject: Re: Real-Time references wanted
Keywords: real-time, definition
Message-ID: <614@ajpo.sei.cmu.edu>
Date: 20 Oct 89 12:33:02 GMT
Lines: 96

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