# Windows NT, CLI and STI (NT and real-time)

V

(Originally posted Wed 07/01/1998)
Dear Mr. Shields,
I hope you forgive me for my changes in the original text.

> “A real-time system is a system that controls an ongoing process and delivers its outputs no later than is necessary for effective control.”<

A control system is a system that controls an ongoing process and delivers its outputs no later than is necessary for effective control.

> The question of real-time is virtually 100% dependent on the process. Real time control of the dam gates on a slow moving river may require a response time no faster than an hour; real time control of an annealing furnace may require a response time of 30 seconds; for the control surfaces of a jetliner, maybe a few milliseconds; for a Mach 3 fighter it may be fractions of a millisecond. <

The question of control is virtually 100% dependent on the process. Control of the dam gates on a slow moving river may require a response time no faster than an hour; control of an annealing furnace may require a response time of 30 seconds; for the control surfaces of a jetliner, maybe a few milliseconds; for a Mach 3 fighter it may be fractions of a millisecond.
The intent of the changes is to ask the following questions:
Are there any comments on these variants of the text?
What does the text lose after the changes?
Does it become more foggy?
Thanks,

Institute of Automation & Electrometry
Novosibirsk Russia

D

#### Donald W. Carr

(Originally posted Wed 07/01/1998)
I think the changes you made illustrate that all control systems are real-time systems. We should strive to use the word “control” instead of the word “real-time” wherever possible. All real-time systems are not control systems though. As an example a data collection program might be considered real-time since all data must be acquired within time constraints, but since no outputs are sent, it is not a control system.
Also, how about if we drop the words “hard” real-time and “soft” real-time and instead give the consequences of failure such as: possible loss of life, large financial loss, small financial loss, the plant will be shut down, etc. There is so much disagreement in the meaning of “hard” and “soft” that I tend to ignore these words and try to figure out the consequences of failure and the timing requirements from other descriptions of the system.
Don.

J

#### John Fridye

(Originally posted Wed 07/01/1998)
Yes, terminology can become very nebulous. I think in order to better understand the world we develop models and we make categorizations. However, if you move outside the scope of the original model or categorization then the understanding you are trying to achieve can break down.
I think your sentences make sense because the context around the sentence allows us to categorize the meaning according to our own experience and understanding. Just because as a writer you do not explicitly categorize “control system” as real-time does not keep me as a reader from making that categorization to help further my understanding of what you wrote.
For control systems, I may want to make the following categorizations:
Automated Control vs. Manual Control
Relay Control vs. Computer Control
Timer control vs. Real-time control ??

If my audience understands these categorizations then I can use these categorizations to convey an idea or some meaning. If my audience does not understand, then I better take the time to give definitions, give examples or to other explain my meaning to my audience.
Is manual control real-time control (I do not really know)?
I would classify a steering wheel, a gas pedal, and a brake pedal on a car as a manual control system. The process of driving the car in this manner is a very effective control most of the time. However, when an automobile accident occurs I would have to say that effective control has broken down. Does this breakdown make the process of driving a car non-real-time. Every system can breakdown. Thus, do we really want effective control at a very high availability (99.99% availability or higher?). I personally do not know the answer but my gut feeling is to not categorize driving a car as real-time control.
If I place a timer on an outdoor security light to turn the light on at dusk and to turn the light off at dawn, I would categorize this as a timer control system. Is this real-time control? The timer is doing an effective job. What happens if I get a power outage, and the timer now turns the light on during the middle of the day. I no longer have effective control. Again, I personally would not classify timer control systems as real-time.
Since, my categorization helps my understanding, I will continue. You of course can make your own categorizations or none at all.
One final note, I think that this whole thread should be categorized as PHILOSOPHY.

M

#### Michael Griffin

(Originally posted Thu 07/02/1998)
At 20:34 01/07/98 -0700, Vladimir E. Zyubin wrote:
<clip>
At Tue, 30 Jun 1998 10:07:46 -0400, Shields, Lester R wrote:
“A real-time system is a system that controls an ongoing process and
delivers its outputs no later than is necessary for effective control.”
A control system is a system that controls an ongoing process and
delivers its outputs no later than is necessary for effective control.
<clip>
I agree that the term “real-time” has been so much abused that it has lost much of whatever meaning it originaly had. It has become in many cases a marketting term much like “object oriented” is for computer programing (or “artificial intelligence” was a few years ago) and is simply used to pad out advertising brochures.
Having said that, I do feel that there is a need to distinguish between systems that will work correctly regardless of timing, and those which will not. For example, consider the following two systems:
A) A pneumatically operated pick-and-place.
B) A robot driven by electric servo drives.

System “A” will always operate correctly regardless of the speed or repeatability of the control system. A valve fires, a slide advances, a sensor is made, and then the next valve is activated. Yes a much faster controller may give you a small (normally insignificantly small) improvement in cycle time, but the correct motions will occur regardless of this.
System “B” however requires definite control timing criteria to be met if the robot is to always describe the correct motion path.
I like to consider that “real-time” describes not the control system, but rather the requirements of the system which is to be controlled. This is I think the “precise terminology” which is required.

>The question of control is virtually 100% dependent on the process.
Control of the dam gates on a slow moving river may require a
response time no faster than an hour; control of an annealing
furnace may require a response time of 30 seconds; for the control
surfaces of a jetliner, maybe a few milliseconds; for a Mach 3 fighter
it may be fractions of a millisecond.<

Yes, all four of these processes require real-time control; they really only differ in their time scales. I might call the control systems that operate them “real-time control systems”. That however really only means that in each case the control system was found to be capable of offering effective control of a real-time process.
The phrase “real-time system” conveys some usefull information about how the system (i.e. the process) behaves and the type of control required. The phrase “real-time control system” does not.
The “real-time” in the phrase “real-time operating system” seems to mean something quite different from its use in industrial control systems. It seems to have been adopted to try to describe operating system designs which are commonly applied in operating systems which may be used in constructing control systems for “real-time systems” (that is real-time industrial processes). Since this is quite a mouth full, they simply abrieviated this to “real-time operating system”, or “RTOS”. Whether a particular RTOS is suited for use in a specific real-time application, is of course up to the control system desiger to decide.

Michael Griffin

M

#### Mike Granby

(Originally posted Thu 07/02/1998)
To my mind, the definition is a real time application is one where the rate of data processing is such the input data can be handled as it becomes available, and output data can be provided as it required. For example, real time generation of computer animation means that the frames are drawn at something like 30 fps. Real time audio compression means that the data stream is compressed as quickly as it is being sampled. The antonym of a “real time” application is thus something like a “batch” application. All control systems must thus by definition be real time applications, or they would not be able to control properly.
The problem comes when people try to apply the words “real time” to operating systems, rather than to application software. It is certainly true that some operating systems make it easier to write real time application than others, but I would maintain that “real time”-ness in the sense I have defined it above is a property of those applications and not of the underlying OS.
When the term is applied to operating systems, it tends to be used to mean that the operating system has low latencies and is deterministic. But neither of these properties is a yes-or-no issue, in that latencies must be considered relative to the time-frame of the application, and determinism is meaningless unless the set of inputs to be used to determine the response in question is defined.
I would thus rather throw away all the overloaded terminology we’re arguing about. I’d much rather refer to operating systems by terms such as “responsive” or “predictable”, as such terms don’t come with all the ill-defined baggage of the more usual language. Indeed, I’d even go as far as saying that it is only particular features of an operating system that should be described in such terms. I’d then much rather leave the term “real time” for applications only, where its meaning is much clearer, and much less open to debate.

Mike Granby
http://www.paracon.demon.co.uk

D

#### David Wooden

(Originally posted Thu 07/02/1998)
[email protected] wrote:
<snip>
I would classify a steering wheel, a gas pedal, and a brake pedal on a car as a manual control system. The process of driving the car in this manner is a very effective control most of the time. However, when an automobile accident occurs I would have to say that effective control has broken down. Does this breakdown make the process of driving a car non-real-time. Every system can breakdown. Thus, do we really want effective control at a very high availability (99.99% availability or higher?). I personally do not know the answer but my gut feeling is to not categorize driving a car as real-time control.
<snip>
My opinion is that the very fact that the breakdown of this control system has had catastrophic consequences would indicate that driving a car is indeed a real-time control system. This would seem trivial, but I think that it points out the distinguishing point of the term real-time: that timely response is critical.
Just my opinion, for what it’s worth (and the standard disclaimer: no one else’s).

David Wooden, OEM Engineer
Wizdom Controls, Inc. (Intellution)
Naperville, IL

A

#### A. V. Pawlowski

(Originally posted Thu 07/02/1998)
My two pennies on the definition of “Real Time” system.
1) For me, “real time” means a system which monitors and/or responds to external events so quickly that there is no practical (some might tighten it to observable) delay in the system’s measurement or response as observed in the external time frame. The speed of response needed to make something “real time” is relative to, and set solely by, the time between external events.
2) I have used the meaning above for over thirty years now and it has served me well, whether talking about control systems, computer software (OS’s included) or anything else.

I think scheduling, priorty handling, interrupt handling, etc. are techniques used to achieve and implement “real time” systems. I think terms like determinism, garanteed response, repeatable timing, known delay, etc. describe common attributes, and metrics, of real time systems.

D

#### Dick Caro

(Originally posted Thu 07/02/1998)
Nonsense! There is such a thing as a Real-Time operating system. If you have only used Windows you don’t know what one is. I will not repeat the many previous postings related to response time - they are correct. If it is fast enough for the application, it is real-time.
However, any RTOS must provide a way to schedule tasks on a timed basis:
1. Run a task X milliseconds from NOW (scheduled)
2. Run a task every Y milliseconds (cyclic)
3. Run a task at Z, a specified time-of-day

Most RTOS also provide a method to run a task on some external event or alert other than time. Most of the instances, the OS provides some SEMAPHORE mechanism to allow inter-process signaling.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

M

#### Mike Granby

(Originally posted Fri 07/03/1998)
As an aside, why do you need to bring Windows into this?
It seems to me that your prejudices are showing.
Moving on to the main issue, your definition of a real-time operating system as contained in your posting is simply that of an OS that is capable of providing timer-based scheduling. All three operations that you list are in fact that same thing—the ability to switch to a given task at some particular time, or more precisely (since switching to the task in question might not be possible) the ability to mark that task as ready to run. In fact, I’m not even sure that the time-of-day issue comes into the question of a RTOS at all, as many real-time applications have no need to know anything about the time-of-day!
Anyway, if timer-based scheduling is really the definition of an RTOS, it is so light-weight as to be meaningless, hence my assertion that the term should only be applied to applications. Your requirement to schedule tasks in response to events adds nothing to your definition— all operating systems must have the ability to switch tasks in response to interrupts, as in essence they do little else! As for task synchronisation primitives, these surely have even less to do with the argument, and they can in any case easily be implemented outside the OS.
My main point thus remains that implementing a real-time application— a term about which I would hope there is no debate—does not require a real-time operating system, and a real-time operating system does not guarantee the ability to implement a real-time application. Given that an RTOS is thus neither a sufficient or a necessary condition for a real-time application, I find little merit in applying the term to the operating system at all.

Mike Granby
http://www.paracon.demon.co.uk

V

(Originally posted Mon 07/06/1998)
>I think the changes you made illustrate that all control systems are real-time systems. We should strive to use the word “control” instead of the word “real-time” wherever possible. All real-time systems are not control systems though. As an example a data collection program might be considered real-time since all data must be acquired within time constraints, but since no outputs are sent, it is not a control system.<

I agree that data acquisition systems are not control systems... and I think that all data acquisition systems have time-connected requirements that have to be met as well as other requirements.
But, IMO, it’s so obviously that it need not to be accentuated... everywhere and with this terminology at least.
About the “should”: IMO, it is problem of freedom and expediency. Everybody may say, ‘I wish to use “real-time” for my goal’. Another example, when somebody tries to find out “real-time” with the search engines he finds Mr.Jensen’s page. It is good article and I don’t feel moral rights to say to Mr. Jensen, ‘You should strive to use “scheduling”...’ and so on.

> Also, how about if we drop the words “hard” real-time and “soft” real-time and instead give the consequences of failure such as: possible loss of life, large financial loss, small financial loss, the plant will be shut down, etc. There is so much disagreement in the meaning of “hard” and “soft” that I tend to ignore these words and try to figure out the consequences of failure and the timing requirements from other descriptions of the system.<

I can speak only behalf of me: I don’t use the words because I don’t see its useful effect. But it seems to me, that sometimes somebody see profit of the use... Mostly in discussions on the topic “My open hard real-time OS is more hard, more open, and more real-time than yours” I think that the gentlemen will not agree with you and me.

At Tue, 30 Jun 1998 10:07:46 -0400, Shields, Lester R wrote:
>>“A real-time system is a system that controls an ongoing process and
delivers its outputs no later than is necessary for effective control.”<<

>A control system is a system that controls an ongoing process and
delivers its outputs no later than is necessary for effective control.<

Again, in my opinion, nobody can speak, ‘we should prohibit the words “real-time”.’ But before to write the words, it would be reasonable to glance all existent definitions and ask yourself, ‘Will I have the desirable effect on my readers or not?’
Best Regards,

D

#### Dick Caro

(Originally posted Mon 07/06/1998)
Clearly, you have not attempted to implement a real-time application on an O/S that does not have any real-time features. Sure, it can be done -- all you need is access to a low-level timer. Then you need to implement all of the features supported by a RTOS yourself, hopefully as re-entrant and re-usable objects. For those of us that choose to not drive down to low level programming, I prefer to have my O/S provide those features for me. WindowsNT does not. PSOS does. It is all too easy to trivialize the features of past generations of RTOSs which are necessary to implement embedded systems. I still maintain that if an O/S does not support the most basic of time-based scheduling functions, it cannot be called a Real-Time O/S.
By the way, how do I schedule end-of-shift reports if I do not have access to a time-of-day clock?
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

R

#### Rufus

(Originally posted Mon 07/06/1998)
>In fact, I’m not even sure that the time-of-day issue
comes into the question of a RTOS at all, as many real-time applications
have no need to know anything about the time-of-day!<

I think time-of-day is mostly useful when someone says: “Hey buddy, you got the real time?” It usually has more meaning for humans than applications.

>..Anyway, if timer-based scheduling is really the definition of an RTOS,
it is so light-weight as to be meaningless..

all operating systems must have the ability to switch tasks in response
to interrupts, as in essence they do little else!<

CP/M and DOS are operating systems, have drivers and interrupts, but don’t do multi-tasking.
I wouldn’t consider interrupt processing the same as multi-tasking. Nor would I consider event-responsiveness the same as scheduling.

synchronisation primitives, these surely have even less to do with the
argument, and they can in any case easily be implemented outside the OS.<

Why have an operating system at all when one can easily write interrupt handlers, scheduling algorithms, task switching routines without an OS?

>My main point thus remains that implementing a real-time application—
a term about which I would hope there is no debate—does not require a
real-time operating system, and a real-time operating system does not
guarantee the ability to implement a real-time application.<

No arguments here.
One could also implement a graphical user interface without Windows, too.
But would one?

>Given that
an RTOS is thus neither a sufficient or a necessary condition for a
real-time application, I find little merit in applying the term to the
operating system at all.<

I think there are operating systems that have features and characteristics that make developing the “real-time application” difficult or impossible.
I think an operating system designed to facilitate and support the creation of “real-time application”s should be titled a “real-time operating system”.
Why not just call a “sports car” a “car”?

Rufus V. Smith
Gunther International

M

#### Mike Granby

(Originally posted Mon 07/06/1998)
[1] Dick made the point that semaphores were a more-or-less defining
feature of RTOS, or at least that most of them supported such a thing.
The point I was making was that such things are not related to the
"real-time-ness" of the operating system. If they were a defining
property, then one would be able to convert a non-RTOS into an RTOS by
writing a very simple bit of user-mode code. This would surely reduce
the definition of an RTOS to something so non-fundamental as to be
useless.

[2] Indeed not. So I guess the definition of an RTOS is claimed to be
one which helps you write real time applications. But the definition of
a "real time" is not tied down without knowing what the particular
application is. Since the RTOS must exist independent of its
applications, I would still assert that the first two letters of that
abbreviation are woefully ill-defined compared to when they are used in
other contexts.

[3] Ah, so it comes down to what an operating system is *intended* to
do. In other words, it is more likely to be a badge used in marketing a
product than a real, definable property which can be measured according
to some standard.

[4] Marketing? QED

Mike Granby
http://www.paracon.demon.co.uk

M

#### Mike Granby

(Originally posted Mon 07/06/1998)
the time-of-day was unnecessary for applications such as the one your
quote. Rather, I disputed your inclusion of time-of-day scheduling in
the definition of an RTOS. I would have thought that it was self-evident
that there exist many real-time applications that do not need
time-of-day information, and that to thus include it in your definition
was superfluous.

this putative timer-based scheduling definition. One can certainly
create a thread in Windows NT which is be run after a given period. Are
you saying that the accuracy with which that time period can be
specified is not sufficient for "real time" applications? If so, is this
down to the existence of over-sized non-interruptible sections of code?
Is it the existence of higher priority threads that refuse to yield the
processor? Or is it the difficulties of performing certain operations
system services?

I am genuinely interesting in getting to the bottom of this, although
the identification of those features which make something *not* an RTOS
is hardly the same as finding those features which define it.

Mike Granby
http://www.paracon.demon.co.uk

D

#### Dick Caro

(Originally posted Mon 07/06/1998)
Mike,
I really don't have the time to educate people on a field of technology
well defined by many vendors of products over the past 20 or more years.
If you want to understand what a RTOS is, then buy a book. There are
many. Here is a vendor web site in case you want to start there:
http://www.isi.com/Products/pSOS/
There are many products defined to be a vehicle to HELP the user by
providing the timing and synchronizing functionality users need to solve
problems in multitasking embedded systems. The POSIX project was an
attempt in the UNIX community to provide real-time features in a uniform
way. Your words seem to indicate that you have never heard of a RTOS.
I have lived with Real-Time Operating Systems for most of my career.
Please do not trivialize the existence of an entire industry simply
because it is new to you.

Dick Caro
==============================================
Richard H. Caro, Vice President
Automation Research Corporation

V

(Originally posted Wed 07/01/1998)
Dear Colleagues,

At Mon, 29 Jun 1998 18:02:48 EDT, [email protected] wrote:
> Sometimes things strike you and you feel you have to say something, I got
struck by this:<

If there are no things that strike me,
it rather means I am dead.

> > > > Another case may be a Pseudo Real Time Control System. In
this case you may miss a few deadlines (as long as you do
not miss too many) and the consequences are not too great..
For example you may have 30 control cycles per minute
scheduled but only 28 are executed. The consequence may be
that the cost of your product is $9.02 per unit as compared to$9.0195 per unit. If you produce 20,000 units per hour
then this would cost you \$10 per hour. Of course for this
hypothetical control system, your whole production line may
shut down if the number of control cycles dips below 20
cycles per minute. Now, your company loses big dollars as
well as possible safety concerns.< < < <

... It can be easily reduced to 1 control cycle per 2 sec.
So, in our case the threshold time requirement is 3 sec (1 control
cycle per 3 sec (20 control cycles per minute)), isn't it?< < <
>
> I wouldn't be hasty in reducing 30 cycles per minute down to 1 cycle in 2
seconds. Suppose I have an operation (A) which requires, say, 20 seconds,
holding up the remaining processing, but once completed, frees the system to
do 30 cycles of (B) operation in the remaining 40 seconds? My net
throughput is 30/minute, but my processing cycles (B) are running at (rate of)
45/minute for the remaining 40 seconds. I could probably describe the system using
either number, depending upon my audience.<

IMO, your example complicates the problem in question.
I don't see less than two cases at least.
1. A-operation and B-operation are parallel
(more strict - independent). So, we can look only at
B-operation. And forgive A-operation at all.
What we see is:

B----------------------BBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
<---- 20 sec ---------><----------- 40 sec --------->
<---- 1 cycle --------><----------- 29 cycles ------>

What does it mean? IMO, it means that the requirements
for B-operation is about 20 sec. Or if we try to be more
pedantic, it is equal to 20 sec + (40sec/19cycles) = ~22sec
(19! - worst case)

2. A-operation and B-operation are sequential (i.e., we
need in B-operation after and only after the end of A-operation).
So, we can forgive time for A-operation. What we see is:

BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
--><---- 40 sec ---------><----------- 40 sec -------><---
--><---- 30 cycles ------><----------- 30 cycles ----><---
What does it mean? IMO, it means that the requirements for
B-operation is 40 sec/20 cycles = 1 cycle in 2 sec

======================================
I do understand that you may assume something different. If
so, I would like to look at an example defined more specifically.
As much as I can say I see no objective (human
independent) reasons for "minute", "second", "hour", "year", etc.
Look at "meter/inch" problem.

> And on real-time:
>
> > > > I agree that in the world in general that there would not be
a consensus on what real time is. However, because of this
forum, I think there is a greater degree of consensus on what
real time is. It has been awhile since I have been to the
Jenson Website; but I do like his definition (i.e. a real
are milliseconds or days).< < < <
>
> I don't recall if I got this from Jensen, but I've heard/read (pardon the paraphrase):

"A real-time system is one in which the timeliness of the data/response
is as important as the accuracy for it to be correct."<

Accuracy is a relative thing. For every control system
accuracy is a concrete number because the requirements exist.
For any operating system both accuracy and response time is
nothing because there are no concrete requirements. And these
thoughts allow me to state that your statement will be more
correct if "real-time system" will be replaced by "control
system".

> Also:
Use of an RTOS (real-time operating system) does not imply creation of a real-time system.<

Yes. Use of an OS does not imply creation of a control system.
And vice verse: Creation of a control system does not imply use
of an OS.

>In any case, fast response is not necessarily real-time response, nor
does it necessarily guarantee it: I may not want my results right away, but an
hour from now, give or take 2 milliseconds. If I can't get it in that window,
the real-time nature of my system is insufficient for my purposes.<

Computer does not work in terms of time; computer works in
terms of events generated by timer.

From this standpoint, "fast response" is all what we need
in the case.

Best Regards,
Institute of Automation & Electrometry
Novosibirsk Russia

V

(Originally posted Mon 07/06/1998)
> Yes, terminology can become very nebulous. I think in order to better
understand the world we develop models and we make categorizations....<clip><

Golden words... Well, perhaps, I would use the words "to
orientate into" instead of "to better understand". But in any case,
your thoughts directly indicate that I am in the right list.

> I think your sentences make sense because the context around the
sentence allows us to categorize the meaning according to our own
experience and understanding. Just because as a writer you do not
explicitly categorize "control system" as real-time does not keep me
as a reader from making that categorization to help further my
understanding of what you wrote.

For control systems, I may want to make the following categorizations: ...<clip><

As to me, I would remove the human being from the system
in order to simplify the problem. Then I would give the
documentation on the car to check out the requirements. Is there
the requirement "the car should prevent automobile accidents"
in the doc? No? "the car don't lose the functionality after
automobile accidents"? "the car can not breakdown"? So, I think
all is correct in the case, i.e., the system operates according
the documentation.
Perhaps, we have to look precisely at the words
"effective control". What does it mean? According to my feeling, it
means:
work according to the requirements we (human beings)
set for. Requirements as a reflection of our (human being's)
wishes, our aims, and our experience.

> If I place a timer on an outdoor security light to turn the light on
at dusk and to turn the light off at dawn, I would categorize this as
a timer control system. Is this real-time control? ...<clip> <

1. I would use a photodiode for this purpose...
away from the lamp, of course <g>
2. To be serious: It seems to me that power outage means
breakdown for this system (a violation of requirements for
conditions of correct operation of the system). And after power
outage you have to make an initialization of the system (see the
documentation on it).

> Since, my categorization helps my understanding, I will continue. You
of course can make your own categorizations or none at all.<

I realize that it is not up to me to speak and it is not
up to you to heard, but I have a feeling that there is a lot of
words in English that have no problems with denotation: analog,
discrete, digital, micro-kernel, etc. By the way, there is a
dictionary on Internet: http://www.instantweb.com/~foldoc/
The dictionary is, IMO, good enough; and, perhaps, somebody will
find out that it will be helpful for him.

> One final note, I think that this whole thread should be categorized
as PHILOSOPHY.<

... or, maybe, as classiology (as a branch of philosophy) ;-)

Sincerely Yours,
Institute of Automation & Electrometry
Novosibirsk Russia

"Our searches of an order is no more than a projection of
our pitiful human possibilities"
(borrowed from R. Sheckly's "Dimension of Miracles")

S

#### Simon Martin

(Originally posted Tue 07/07/1998)
Hi all,

I've just got back from the UK and found this thread. I must admit that it
is very close to my heart as I design and develop RTOS for servo control
systems.

One of the biggest questions in the design of any real-time system, which
everyone seems to overlook, is what real-time really means. At the start of
this thread someone, I think it was Mike Granby, mentioned the examples of
the dam gates, robot arm, etc. as having different requirements. This is the
basic design precept for any real-time system!!!

You cannot say that an operating system is not real-time, neither can you
say that it is, unless you specify the application constraints which it must
handle.

The opening/closing dam gates example can easily have constraints of say a
couple of seconds delay between the demand and reaction (someone requests
the gates to open, in a couple of seconds they start to move). These
constraints are fixed not by the physical characteristics of the system, but
more by the expectations of the human system that interfaces with it.

When PLCs are mentioned hare and cycle times of 10-50 ms are mentioned, I
find these ludicrously long, but that is because I am used to a different
set of constraints, I don't have to handle 2000 I/O points, I have to handle
16 axes of motion. What is real-time (enough) for the PLC system, for me is
definitely unreal-time for my line of business (try to explain to someone on
a printing system that he can only register +/-50 centimetres and he'll have
a fit [50 ms @ 10 m/s]).

So to labour a point, as Forest Gump would say "real-time is as real-time
does".

Just a quick side comment, it was mentioned that DOS was not multitasking.
This is not strictly true. My definition of multitasking is a system that
performs more than one task. DOS does this. Whilst you are typing your
report in WordStar(tm), the operating system is task switching 18 times a
second, (interrupt 0x1c) using this beat for updating the clock etc. This is
more than one task, it is part of the OS, so DOS is multitasking (of a
fashion). Now I did not say USEFULLY multitasking, but we must be careful
when we look at the subject of this thread....

Well those are a few of my thoughts on the subject, you can (and most will)
ignore me, but at least I feel better now.

Simon Martin

M

#### Mike Granby

(Originally posted Tue 07/07/1998)
Dick,

I really am sorry to say this, but I find your attitude patronising in
the extreme. You are making many assumption about me and about my level
in my previous post. If you want to duck-out of this debate then that is
all very well and good, but please don't go around claiming that there
is this wonderful accurate definition of "real time" out there for
anyone to find when this whole thread has been concerned with
pinning-down precisely such a definition.

You made an assertion about Windows NT not being a RTOS, and I attempted
to find out why it did not meet your definition of such a thing. Rather
than answer the question -- which would surely not have taken that much
of your valuable time -- you decided to attack my level of competence.
It may surprise you, but I do have a certain amount of knowledge about
these things. The point is that I am still genuinely at a loss to find a
qualitative definition on an RTOS, and frankly the URL you quote adds
little to what I know.

In your closing paragraph, you say that I have indicated that I have
never seen an RTOS. Let me correct you somewhat. All of *my* career I
have worked with -- and indeed written! -- operating systems that
exactly meet your definition of an RTOS. And that is precisely why I am
still at a loss as to what the big deal is, and why I still maintain my
assertion that the term "real time" is not precisely defined when
applied to operating systems when compared to the exact definition that
exists when it is applied to applications.

Cheers, Mike.

Mike Granby
http://www.paracon.demon.co.uk

V

(Originally posted Mon 07/06/1998)
>....For example, consider the following two systems:
A) A pneumatically operated pick-and-place.
B) A robot driven by electric servo drives. ...<

Well, I assume that in both cases we speak about digital
dam gates).

> I like to consider that “real-time” describes not the control system, but rather the requirements of the system which is to be controlled. This is I think the “precise terminology” which is required.<

...or, perhaps, rather it indicates that the control system
has requirements to response time and these requirements mean
problems with implementation. If so, the words "real time system"
might mean "The object which is to be controlled, is very complex in
sense of response time. So complex that we had problems with the
implementation. The problems have been successfully solved." IMO,
it need not to be marked every time.

> >The question of control is virtually 100% dependent on the process. Control of the dam gates on a slow moving river may require a
response time no faster than an hour; control of an annealing furnace may require a response time of 30 seconds; for the control surfaces of a jetliner, maybe a few milliseconds; for a Mach 3 fighter it may be fractions of a millisecond.< <

> Yes, all four of these processes require real-time control; they really only differ in their time scales. I might call the control systems that operate them “real-time control systems”. That however really only means that in each case the control system was found to be capable of offering effective control of a real-time process.
<

(?) It seems to me that the first example (dam gates) is
very close to the case of the system "A" (pneumatically operated
pick-and-place). Moreover, I bet that a response time of 1 hour
is not acceptable for the end user of the system "A", i.e., as
well as in the case of the system "B", it means a loss of money.
For the system "A" it means waste of energy. For the system "B" --
waste of a half-finished product (or rather producing of
goods we may, but don't agree to use .

> The phrase “real-time system” conveys some usefull information about how the system (i.e. the process) behaves and the type of control required. The phrase “real-time control system” does not. The “real-time” in the phrase “real-time operating system” seems to mean something quite different from its use in industrial control systems. ... <

It does not seems to me that the words "real-time system"
every time are used either as a synonym to "an application
system" or as a synonym to "process", but I quite agree that the
control system designers choose an OS not because of the words
"real-time"... the experienced control system designers, at least

Best Regards,