Today is...
Wednesday, August 23, 2017
Welcome to Control.com, the global online
community of automation professionals.
Featured Video...
Featured Video
A demonstration of EtherCAT control of linear motors using the CTC EtherCAT master.
Our Advertisers
Help keep our servers running...
Patronize our advertisers!
Visit our Post Archive
Windows NT, CLI and STI (NT and real-time)
One of the problem of NT with real-time is that the system uses CLI/STI (CLear Interrupt/SeT Interrupt). Somebody say me that the kernel itself use hard-coded CLI/STI. As the kernel cannot be modified, this definitively prevent hard real-time under NT. Can anybody confirm or invalidate this affirmation?
By Antoine PERRIN on 18 November, 1999 - 9:32 am

(Originally posted Tue 05/26/1998)
Here is the situation:
I am currently studying hard-real time extensions for Windows NT. One of the problem of NT with real-time is that the system uses CLI/STI (CLear Interrupt/SeT Interrupt). In principle, these operations are used only in the HAL and in the drivers... Theorically, by rewriting the HAL and choosing well-written drivers (hard stuff?) you can expect good performances from NT...
Here is my question:
But somebody say me that the kernel itself use hard-coded CLI/STI. As the kernel cannot be modified, this definitively prevent hard real-time under NT.
Can anybody confirm or invalidate this affirmation?
Antoine PERRIN
CJ-international

(Originally posted Wed 05/27/1998)
Why does the existence of sections of non-interruptible code prevent "real time" operation, assuming of course that those pieces of code are small and deterministic?

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Wed 05/27/1998)
Mike, your question is a good one. Of course interrupt response code must be small and deterministic. One of the primary problems in our definition of "hard" vs. "soft" real-time is not the architecture of Windows NT. It can only do so much with the 4 hardware levels built into the Intel x86 architecture. The compromise is that all device interrupts are handled at the same hardware level with tight small code to note the system clock at the time of the interrupt, queue a task for processing and to branch out of interrupt mode. I think Microsoft does the best it can with the kernel and HAL routines as it can with the Intel architecture. Anyone that builds on the HAL must keep the idea in mind that processing interrupts should be done in the same way that MS does it - quickly and queue a task for later execution at the background interrupt level.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Wed 05/27/1998)
Dick these are good points. I think I understand most of it. I do not
proclaim to be a hardware expert. However I can setup a mean DOS or Windows
3.x machine <G>
My question(s). How does the Alpha or PowerPC compare? What about Merced?
And does anyone know if there Real-time extensions for Windows NT that will operate on an Alpha? I guess I need to do some more digging.

Dale Ross
Mitsubishi Electric Automation

Microsoft BackOffice MVP

(Originally Fri05/29/1998)
In general, the RISC machines differ from the Intel x86 architecture by offering smaller faster instructions, uniformly sized instructions, and lots of unallocated registers. This is true of PowerPC, Alpha, Sparc, MIPS and the HP-PA processor which is the basis of Merced. They also offer interleaving of instructions and multistaged pipeline execution and much faster floating point algorithms, but these are at the core of Pentium II and Merced as well. To my knowledge, no RISC chip offers any real-time interrupt features, however, when there are lots of registers, it can be used to "emulate" the action of a real-time architecture. The Intel architecture requires that the interrupt save context (register contents and stack pointers) to MEMORY on interrupt and restore them from MEMORY on return from interrupt. A real-time computer like the ModComp Classic had 16 interrupt levels with 16 registers for each level, one of which was the stack pointer; it did not need to save anything to respond to an interrupt.
The WinNT HAL serves to allow other CPU architectures to emulate the x86 architecture. This is why the 733 MHz Alpha running WinNT works like a 4-500 MHz Pentium. When running DEC UNIX it works like a 733 MHz UNIX machine.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

(Originally posted Thu 05/28/1998)
I agree with all of this. My question, though, was aimed at the original poster who seemed to be claiming that the existence of STI-CLI pairs within the kernel made necessarily NT unsuitable for real time applications.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

By Vladimir E. Zyubin on 18 November, 1999 - 11:08 am

(Originally posted Mon 06/01/1998)
Dear Mr. Caro,

Would you like to share your definition of 'hard'/'soft' RT OS with the list?
(Your 'hard' sounds to me like 'hardware'. Is it correct?
If so, what about the QNX community?)
Many Thanks,
Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Wed 06/03/1998)
To refine my earlier message on hard vs. soft O/S-First of all, <<real-time>> has a relative definition: if it's fast enough for the application, it's real time. This is why real-time for temperature control may be 4-10 seconds, while flow control is 100-300 milliseconds, and nuclear flux control is 2-3 milliseconds. Part of my background has included real-time computers like the Modcomp Classic, DEC PDP-11, and Foxboro FOX/1 and 1A. These computers made interrupt response very fast via HARDware assistance. All popular microprocessors do NOT have specific hardware support for external interrupts other than the system clock, system faults, and DMA types of I/O. All external interrupts and switching of task threads occurs under SOFTware control. To me, HARD real-time must have some hardware assist, as opposed to SOFT real-time that does NOT. So we have the types of trivial arguments like how many angels can sit on the head of a pin, or does hard real-time require a software modification to the WinNT HAL? All software emulations of hardware interrupt and task switching are SOFT real-time. The only question is how good (time efficient) is the emulation of hardware.
The Intel x86 architecure cannot be made to provide HARD real-time, it does not have enough registers or interrupt levels. It's all soft real-time, although it may be fast enough for a given application. Use of a RISC engine may offer some hardware support for real-time by allocation of its many registers to interrupt levels. RISC also allows better emulation of interrupt levels than the current CISC microprocessor architectures. To my knowledge, there is only one commercial application of RISC to real-time computing which is from Modcomp that sells a VME microcomputer called REAL/STAR using Motorola 88110 RISC microprocessors and their own port of UNIX called REAL/IX. I would take comfort in calling a REAL/STAR computer running REAL/IX a <<HARD>> real-time system.
QNX was written with their own kernel designed for the best real-time that could be supported on the Intel x86 architecture. It is still, IMHO, a soft real-time O/S, but a lot closer to industrial automation requirements than AT&T UNIX on Pentium. By the way, please note that AT&T UNIX was written for telecom applications which often require true real-time response as well. Not much was included in the UNIX O/S since it was written for the PDP-11 which had 16 levels of hardware supported priority interrupt. UNIX didn't need soft real-time on this computer since that form of task switching was handled in hardware.
Dick Caro
Richard H. Caro, Vice President
Automation Research Corporation

By Vladimir E. Zyubin on 18 November, 1999 - 11:19 am

(Originally posted Thu 06/11/1998)
Dear members,

Firstly, I must apologize for my attempt to discuss the eternal question - what does 'real-time' mean.
Secondly, many thanks to Mr. Caro and other members for their definitions of RT. The definitions considerably improve my private collection of the ones.
So, I have a couple of questions to the List members:
1. What is the practical value of the term? (with technical viewpoint, please ;-)
2. Is there anybody who interpret the term (when it appears in a technical article) as 'mauvais ton'?
3. How many professionals are ready or think of to throw out the term from the vocabulary?
Many thanks in advance...
With kind regards,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

P.S. I hope the List members forgive me for the heretical thought:
In any text that does not contain a definition of RT, the term can be painlessly replaced by 'cool' (for OSes) and by ' ' (for control systems) :-)

By E. Douglas Jensen on 18 November, 1999 - 11:43 am

(Originally posted Mon 06/22/1998)
(I realize that Mr. Zyubin wrote this with tongue in cheek, so I will respond in kind.)
For centuries people have recognized that if you cannot speak precisely about a topic, you cannot think precisely about it.
If all you know about gravity is "Things fall down" and if you think the terms "mass" and "force" are some pointy-headed intellectual's way of trying to make himself seem superior to you and all you need to know is that "some things weigh more," then there are limits to how well you can perform certain kinds of work-limits, perhaps, that you never encounter in your particular career.
Newton widened the scale of things we could do when he characterized gravity more precisely as a force; Einstein et al. widened the scale far more when they characterized gravity as curvature in space-time; now people are seeking to make the biggest expansion yet-to smaller as well as larger scale- by characterizing gravity in a quantum mechanical way.
This analogy is poor in the sense that only a relatively few of us have improved our professional capabilities with these increasing improvements in perception and understanding of gravity.
But for many of us on this list and elsewhere, the more accurately we understand and can speak about real-time computing-e.g., "hard," "soft," "predictability," "determinism" are especially common examples of dangerous misunderstandings-the better we can meet the needs of those systems and applications which have requirements for acceptable predictability of satisfying timeliness constraints. It's not (usually) sophistry-it's mission- and often life-critical in automation systems of significant complexity (that's a growing percentage of them).
Let's not flaunt ignorance as a badge of masculinity, and let's not throw the baby out with the bath water as Mr. Zyubin facetiously suggests.
I have placed the first draft of a new presentation about this on my web site for those who care to join me in seeking to better understand and perform real-time computing for control systems.
Doug
E. Douglas Jensen, at home
jensen@real-time.org
http://www.realtime-os.com

By Vladimir E. Zyubin on 18 November, 1999 - 3:37 pm

(Originally posted Thu 06/25/1998)
Dear Colleagues,
In despite of the kindly possibility to look like joker, I ought to confess:
It was not a joke.
Here are facts and opinions (according to my experience):
1. The probability that a man speaking "real time" can not "denotate" the term, is about 90%.
2. Frequently, the speakers do not separate two absolutely different weakly-connected things: operating system(OS) and control system(CS).
3. There are three definitions of the term at least (I personally prefer Mr.Jensen's one). But all of them are too verbose to be precise (again, IMO).
4. If somebody says without a context: "real time system", the term do not bear any valuable information.
5. In overwhelming majority of the cases, "RT OS" means just that there is a mechanism for a multitasking model of parallelism in order to provide functionality of control algorithm (e.g., corporative multitasking, preemptive multitasking, etc.). I.e., value of the term is pour.
6. "RT CS" - Is there anybody who can suggest an utilization of a control system that can not meet the requirements of the task? I.e., it sounds like a tautology.
7. There is no standard which contains a definition of the term.
8. Plus: Under these circumstances it is quite possible to speak about both OS and CS without utilization of the term. (that I, painlessly for professional conversation, am doing during several years.)

Note: I do not try to state that the term should be avoided, but, IMO, there are a lot of reasons to be careful with the term.
To make the things more clear:
I specialize in predictable deterministic stand-alone control systems with soft multithreading parallelism.
predictable - having possibility to find
maximal time of response to external evident a priory.
deterministic - the maximal time of response is not
probabilistic.
stand-alone - without OS or independent from OS.
multithreading parallelism - a model of parallelism opposite to
multitasking one, parallelism within one task closed to so-called round robin style.
soft parallelism - an opposite to CSP (Communicating Sequential
Processes) model of parallelism, characterized by lack of child-parent connections between the parallel chunks.
With best regards,

Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

By Vladimir E. Zyubin on 18 November, 1999 - 4:11 pm

(Originally posted Mon 06/29/1998)
Dear Colleagues,

I received a message with interesting comments on the topic.
The original message with my replies on it is below. Perhaps, somebody have additional pro or contra. Your comments would be interesting to me... Especially about the "Pseudo Real Time Control System".
Are there non-hypothetical control systems, where we have to distinguish the following:
• "20 control cycles per minute";
• "1200 control cycles per hour";
• "1 control cycle per 3 sec"?

(the strings marked by ">>>" and ">" are mine)

<snip>
>But, IMO, several remarks could be made...

You wrote:<
>>>6. "RT CS" - Is there anybody who can suggest an utilization
of a control system that can not meet the requirements of
the task? I.e., it sounds like a tautology.<<<

>>A Control System is not inherently Real Time. A traffic
light control system would be an example. You might want to
call this a "Sequential Time" Control system. What is
important is that one light turn red before the other light
turns green. What happens if you miss a control cycle? The
driver at the red light gets mad for waiting too long, but
that is it.<<

>Alas, I did not deal with traffic light
control systems, but... It seems to me that there are
timeline requirements in our case as well. I think the
response time is about 1 sec. (If we keep in mind that
source of the input is a timer).<

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

>IMO, a trick is included into "30 control cycles per
minute"... 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 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
time system must meet its deadlines whether those deadlines
are milliseconds or days).<<

>I agree... if the "a real time system" means
"a control system". For "OS" it is not the case.<

Thanks,

Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

(Originally posted Mon 06/29/1998)
Sometimes things strike you and you feel you have to say something, I got struck by this:

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

> >IMO, a trick is included into "30 control cycles per
> minute"... 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.

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
> time system must meet its deadlines whether those deadlines
> 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."
Also:
Use of an RTOS (real-time operating system) does not imply creation of a real-time system.
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.

Rufus

By Lester R. Shields on 18 November, 1999 - 4:26 pm

(Originally posted Tue 06/30/1998)
The best definition of a real time system is one I got from a textbook I was teaching from, to wit:
"A real-time 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.

By Vladimir E. Zyubin on 18 November, 1999 - 5:01 pm

(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 informative?
Does it become more foggy?
Thanks,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

By Donald W. Carr on 19 November, 1999 - 10:29 am

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

(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
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(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

(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
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(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

By Mike Granby on 22 November, 1999 - 4:33 pm

(Originally posted Mon 07/06/1998)
Dealing with your closing question first, I did not say that access to
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.

Moving back to the main issue again, I would like more information about
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
with your thread without yielding control to non-deterministic operating
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
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(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

By Mike Granby on 23 November, 1999 - 9:23 am

(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
of knowledge, while avoiding answering the very simple question I asked
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
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Tue 07/07/1998)
Mike,
My apologies. I didn't mean to insult your intelligence. I just find
your style of questioning objectionable. To your questions:

Windows (95, NT, 3.51, etc.) and DOS in all forms are just Disk
Operating Systems. Windows makes the multitasking easier than invoking a
new COMMAND sequence that was necessary in DOS. It also provides easier
to use memory management to take advantage of Extended Memory that is
necessary due to the handicap of the x86 architecture. If you care to
write a program to use low level timers, you may create an entire
real-time environment yourself using DOS or any form of Windows, but the
O/S does not help you in any way. Therefore, IMHO, Windows is NOT a
real-time O/S. I don't know about WinCE 3.0 which Microsoft says will
have at least fast context switching, but there has been no information
on time-based scheduling or task synchronization.

My definition: a real-time O/S provides the services to
deterministically schedule tasks based on time or external events, and
provides the services to synchronize task execution in a multitasking
environment.

Mike, you may be an ace programmer and find real-time routines in some
class-library. That doesn't help most people working on applications
who expect these services to be provided by the O/S. If you care to
follow some obscure references, I was one of the editors of the
Real-Time Extensions to FORTRAN prepared in the 1970's and which became
ANS/ISA S61.1. These were implemented by Modcomp and DEC (and maybe
others) for their FORTRAN compilers. These same extensions were
prepared for PL/I and added to the subset of that language which became
an ANSI standard, but I don't have that reference.

Please note that "real-time" does not in any way define response time
requirements. It only implies that the O/S provides services needed by
tasks to respond in a deterministic way. A genuine RTOS provides the
enforcement that library scheduler routines cannot.

Dick Caro

By Mike Granby on 23 November, 1999 - 3:19 pm

(Originally posted Tue 07/07/1998)
Your apology is accepted, and fully reciprocated with respect to my
style of questioning should you consider it objectionable. It is not
intended to be so.

Moving on to the question of Windows, I think it is important to make a
distinction between the different members of that family, as they are
all rather different in the areas we are discussing...

With Windows 3.1, the OS that most people see (ie. the GUI) is about as
far from anyone's definition of an RTOS as you could ever get.
Underlying that, though, is the virtual machine manager (VMM) used to
schedule between DOS virtual machines. One of these VMs is running the
GUI, and the others may run anything you like. I would argue that the
VMM meets you definition of an RTOS, in that you can schedule the VMs
according to interrupt events, be they from the timer or from other
external sources. Any attempt to implement a real-time application in
this way is hampered, though, by two things. Firstly, the calls into the
this "operating system under an operating system" can only be made from
virtual device drivers -- which were still most evil at that stage of
Window's evolution -- and, secondly, your entire I/O system is based
upon DOS, with all its non-re-entrant nastiness.

With Windows NT, it is a different kettle of fish altogether. It surely
meets your definition of an RTOS, and it surely does "help you" by
provide flexible scheduling, task and thread synchronisation services,
asynchronous procedure calls, and all manner of fun things. Whether or
not it is responsive enough in terms of latencies to be a true RTOS by
some people's definition is another question, but it is precisely that
quantitative nature of the definition that makes me want to throw the
term away altogether.

With Windows 95, you've got an in-between situation. It provides pretty
much all of the task stuff that you require of an RTOS, but elements of
its I/O system are still less re-entrant and responsive than Windows NT,
and large elements of its GUI are likewise single threaded. But then
again, we're not talking about graphical real-time operating systems
(GRTOS???) so perhaps this isn't relevant.

From all of this, I draw two conclusions. Firstly, all of the Windows
family have some form of scheduler which would meet *some* definition of
an RTOS, even if the latencies didn't meet other people's expectations.
Secondly, those members of the family that have weakness actually have
them in the areas of their I/O systems and their task protection
mechanisms. This fits in with my "what's the big deal" comment --
writing an RT scheduler is trivial; writing an RT I/O system is much
more complex. Even then, though, the concept of RT-ness is a sliding
scale, such that no-one can draw a line in the sand and say where RT
begins, and where it ends. As such, it does not strike me as a useful
term when used in this context.

--
Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Tue 07/07/1998)
Answered in context below:
> Moving on to the question of Windows, I think it is important
> to make a
> distinction between the different members of that family, as they are
> all rather different in the areas we are discussing...
>
> With Windows 3.1, the OS that most people see (ie. the GUI)
> is about as
> far from anyone's definition of an RTOS as you could ever get.
> Underlying that, though, is the virtual machine manager (VMM) used to
> schedule between DOS virtual machines. One of these VMs is running the
> GUI, and the others may run anything you like. I would argue that the
> VMM meets you definition of an RTOS, in that you can schedule the VMs
> according to interrupt events, be they from the timer or from other
> external sources. Any attempt to implement a real-time application in
> this way is hampered, though, by two things. Firstly, the
> calls into the
> this "operating system under an operating system" can only be
> made from
> virtual device drivers -- which were still most evil at that stage of
> Window's evolution -- and, secondly, your entire I/O system is based
> upon DOS, with all its non-re-entrant nastiness.

Win3.1 is only DOS with an ugly GUI and a single threaded multitasking
system. It needed to be run as a slave OS under a real RTOS which most
of the HMI vendors did.

>
> With Windows NT, it is a different kettle of fish altogether.
> It surely
> meets your definition of an RTOS, and it surely does "help you" by
> provide flexible scheduling, task and thread synchronisation services,
> asynchronous procedure calls, and all manner of fun things. Whether or
> not it is responsive enough in terms of latencies to be a true RTOS by
> some people's definition is another question, but it is precisely that
> quantitative nature of the definition that makes me want to throw the
> term away altogether.

Everything you say is correct except that I did not refer to thread
synchronization but for independent tasks (processes) spawned by the
timer. In a real RTOS, it is not necessary to keep a scheduling task
alive as it is in WinNT. Also, WinNT has no means, unless you write the
code, to support deadline scheduling, common in RTOS. The missing factor
is that the OS must enforce the time schedule unless blocked by higher
priority tasks. I guess that you can do all that in WinNT if you write
the code. If I specify an RTOS, I ask that the RTOS enforce these
features. You raise all the same questions that the PL/I designers
raised in 1976 about the need for Real-Time extensions to their favorite
language. It's all about a small matter of programming. Without the
enforcement of the schedule and the synchronization by the OS, it cannot
be considered as Real-Time. Ergo, WinNT, without modification cannot be
considered a RTOS.

> With Windows 95, you've got an in-between situation. It
> provides pretty
> much all of the task stuff that you require of an RTOS, but
> elements of
> its I/O system are still less re-entrant and responsive than
> Windows NT,
..clip ... and therefore less RT.
>
> >From all of this, I draw two conclusions. Firstly, all of the Windows
> family have some form of scheduler which would meet *some*
> definition of
> an RTOS, even if the latencies didn't meet other people's
> expectations.
> Secondly, those members of the family that have weakness actually have
> them in the areas of their I/O systems and their task protection
> mechanisms. This fits in with my "what's the big deal" comment --
> writing an RT scheduler is trivial; writing an RT I/O system is much
> more complex. Even then, though, the concept of RT-ness is a sliding
> scale, such that no-one can draw a line in the sand and say where RT
> begins, and where it ends. As such, it does not strike me as a useful
> term when used in this context.

Easy for you to say, Mike ace programmer. Not easy for an application
programmer to write multithreaded tasks to run real-time. Even harder
to write the OS administrative code to enforce clock synchronization
should task execution run over the allocated time gap. It all boils down
to one issue: how much real-time code must the programmer create to
enforce the real-time scheduling and synchronization tasks required to
implement the application. I say that RTOS like PSOS and Lynx or the
older RSX-11M (DEC PDP-11) and MAX III (Modcomp Classic) mad this job
easy, but I cannot even conceive of the complexity of doing the same
jobs in WinNT.

By Lester R. Shields on 1 December, 1999 - 3:46 pm

(Originally posted Tue 07/07/1998)
On Tuesday, July 07, 1998 3:45 PM, Dick Caro wrote:
> I say that RTOS like PSOS and Lynx or the
> older RSX-11M (DEC PDP-11) and MAX III (Modcomp Classic) mad this job
> easy, but I cannot even conceive of the complexity of doing the same
> jobs in WinNT.

As a long time user of the PDP-11, I often wonder why someone doesn't
rewrite RSX to run on Intel. While it didn't always make everything
easy, it did have most of the features a real-time programmer needs.
Even the features it didn't have could usually be added or synthesized.

Les

(Originally posted Wed 07/08/1998)
Great idea. Unfortunately, the PDP-11 hardware did a lot of the work.
It had 16 levels of priority interrupt and automatic context switching
in interrupt response. One way to do important stuff (like incrementing
a flow integrator) was to do it in the interrupt level. Pentium has
only 4 hardware interrupt levels, but is much faster than the PDP-11 in
any form.

Dick Caro

By Mike Granby on 1 December, 1999 - 4:38 pm

(Originally posted Wed 07/08/1998)
YOU SAID: "Everything you say is correct except that I did not refer to
thread synchronisation but for independent tasks (processes) spawned by
the timer."

Most self-proclaimed RT operating systems I have looked at only support
threads, and only a few support self-contained processes with separate
address spaces. By a thread, I mean a unit of execution which shares the
same code and data space as a number of similar units of execution.

YOU SAID: "Also, WinNT has no means, unless you write the code, to
support deadline scheduling, common in RTOS. The missing factor is that
the OS must enforce the time schedule unless blocked by higher priority
tasks."

So now you are adding dealing scheduling to the definition of an RTOS?
There is plenty of evidence against this assertion. Let us consider AMX
-- the first RTOS that I used in an industrial application. This does
not provide deadline scheduling. Further, let us consider PSOS -- the
RTOS that you suggested I study. The description of the PSOS scheduler
that I found on a Phillips web site is remarkably similar to that of
Windows NT, and of many other priority-based schedulers. There is
absolutely no mention of deadline scheduling. Further, let us consider
the July 1998 version of the comp.realtime FAQ which includes in its
definition of an RTOS the requirement that "The notion of thread
priority has to exist as there is for the moment no deadline driven OS."

In other words, the commonly used definition of an RTOS does not include
the notion of deadline scheduling. Rather, it includes the
priority-based scheduling that Windows NT (and indeed Windows 95)
implements. You may still feel that neither of these operating systems
is an RTOS, but the fact remains that BY YOUR DEFINITION -- less the
recently added requirement for deadline scheduling -- they are precisely
that.

YOU SAID: "Easy for you to say, Mike ace programmer."

Oh, stop it.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

(Originally posted Wed 07/08/1998)
Not to prolong the issue, but I still insist that to qualify as a RTOS I
ask for the following:

1. Ability to schedule an independent task to execute at some future
time increment (from now). This can also be a delay in task thread
execution. The schedule cannot be masked by execution of a lower
priority task/thread.

2. Ability to schedule an independent task to cyclically execute at a
precise time interval. I am not sure how I do this with an execution
thread.

3. Ability to queue a task execution (or resume a program thread) when
an external event occurs. External event may be a program (shared
memory) semaphore, or it may be a bit in a register of a scanned I/O
database.

I look for being able to do these operations for independent tasks by
configuration of queuing tables, not by programming. At very worst,
the scheduling task is very small.

I don't find these functions as part of the Windows NT specifications.
I am sure that it is possible to write the queuing tasks and to create a
queue manager with some reasonable high level of performance on say a
P400 processor, but it isn't part of NT.

In short, if the OS doesn't have Real-Time features, how can it be a
RTOS?

Dick Caro

By Mike Granby on 2 December, 1999 - 11:21 am

(Originally posted Thu 07/09/1998)
1. Spawn a high-priority thread which sleeps for N ms and then wakes
your other thread. Okay, so you need a bit of code, but we're talking
about ten lines or so to create the framework, and a single line to
invoke it each time.

2. Similar idea to above, but use a waitable timer within the helper
thread. If you're not running Windows NT 4.0 and so don't have a
waitable timer available, then you're okay as long as the time taken to
wake a thread is less than a system tick. This is pretty much the case
on any system built within the last few years.

3. I/O database triggered resumes need a scanning task, but is easy to
do and I've not seen a single RTOS that does this out-of-the-box. Having
a task resume from a semaphore is part of Windows NT, and thus requires
no extra effort. This can be done between threads, or across processes.

The first point is thus that you can get Windows NT to do all these
things, albeit with some user-mode coding. The more important point,
however, is that many many operating systems which claim to be RTOS's
require exactly the same amount of coding as Windows NT. You thus appear
to have two choices: Admit that Windows NT is (by a commonly used
definition) an RTOS, or admit that the term has no value! :-)

--
Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

By Jonathan Lyall on 2 December, 1999 - 11:53 am

(Originally posted Fri 07/10/1998)
Dick your first point is all cool and groovey but even in a PLC,
which IMHO is by definition RTOS a task only occurs within the
contraints of scan time.

You may set a timer to trigger a task but this timer will only
be accurate within the contstraints of scan time. Even with an
interrupt driven timer accuracy down to 1us might be the best
you can hope for.

So I guess if knowing your task will trigger in this us or the
next is close enough then this is RTOS.

(Originally posted Wed 07/15/1998)
With all due respect Dick,

I am not sure what you mean by 'Windows NT Specifications'. I respectfully suggest
that you look directly at the API. It contains (and I am not saying this is a complete list):

- calls to adjust the priority of threads,
- calls to manage multiple threads, and manage multiple processes,
- calls implementing 'interprocess' synchronization primitives such as
semaphores, mutexes etc. These can synch threads within or between processes.
- interprocess communication primitives.
- block/release a thread on single or multiple events (a daemon).

You said something about not considering something found in a class library, but I am
not sure why you would say this when in most cases the classes are thin wrappers over the
Win32 API.

Please understand that what I am saying only applies to the full NT implementation of
the Win32 API, not Win32s, not Windows 95 and most certainly not Windows 3.x or earlier.
Taking properties of Win3.x and drawing conclusions about Win32 (NT) is not comparing
apples to apples.

I don't view the techniques I use writing multi-threaded applications under Win32 as
being a whole lot different than those used writing in Micropower Pascal on DEC machines
in an earlier life.

Bill Code
MPM Engineering Ltd.
4-6240 202nd St., Langley, B.C., Canada, V2Y-1N2
E-Mail: Bill_Code@mpm-eng.com WWW: http://WWW.MPM-ENG.COM/

By A. V. Pawlowski on 23 November, 1999 - 3:21 pm

(Originally posted Tue 07/07/1998)
I think I would have to agree with Mike Granby that the term "RTOS" just
does not have much value anymore.

It used to mean (for me) a small, embedable kernel which was optimized
for computer hardware support of automation/control applications. Today
though, many of the scheduling, I/O and sychronization features that
were typically provided by that class of product are now provided (to
greater and lessor extent) by general purpose OS's, the difference being
largely speed and size.

In fact, many "real time" applications are now being successfully
supported by general purpose OS's. For better, or worse, the difference
between these classes has decreased greatly.

By Donald W. Carr on 1 December, 1999 - 2:56 pm

(Originally posted Tue 07/07/1998)
RTOS is still a valuable term. Many slow, non-critical real-time
applications can be run on a general purpose OS with at least some extra
work from the programmer. There are also real-time packages written for
general purpose operating systems that to some degree make up for what is
lacking in the OS. There is a big difference though between, say, QNX and
Windows 95 in terms of OS support for real-time applications. When I here
the term RTOS it may need some qualification, but I instantly know that
there are at least some features commonly needed by real-time applications
built into the OS. By the way, the term operating system itself is not very
precise either. What features are necessary before you can call it an
operating system? If you ask 10 different people you will get 10 different
answers, but that does not mean the term operating system has no value. And
which general purpose operating systems do you refer to that are just as
good as any RTOS for implementing time critical real-time applications
where failures could result in result in injury and/or large financial losses.

Don.

By A. V. Pawlowski on 1 December, 1999 - 4:47 pm

(Originally posted Wed 07/08/1998)
>RTOS is still a valuable term. ...............<

I will take your word that it is still valuable for you. It probably has
some for me too. But, for me, it would be hard to attach much
preciseness to it.

> ............And which general purpose operating systems do you
refer to that are just as
good as any RTOS for implementing time critical real-time
applications
where failures could result in result in injury and/or large
financial losses.....................<

I don't think I have ever said that general purpose OS's are better at
real time applications than some other
designed-for-real-time-applications OS. I did say that some successful
real time applications have been installed that run on general purpose
OS's. There is a big difference. Certainly, different OS's have
differering strengths and weaknesses.

1 out of 1 members thought this post was helpful...

(Originally posted Wed 07/08/1998)
Subject: SOFT: "Real-Time Debate"

In my younger days we referred to this type of debate as "Catching the
mice, but letting the elephants free."

At the risk of getting further embroiled, I would like to offer the
following solution:

Why not use the "official" definition given in IEEE Std 100-1992 (at
least thru the 5th edition)?.

Phil Corso,
TRIP-A-LARM CORP.

1 out of 1 members thought this post was helpful...

(Originally posted Wed 07/08/1998)
I was hoping to not get embroiled, but the answer to your question is:

Page 1083 of the aforementioned IEEE standard.

Phil Corso,
Trip-A-Larm Corp


Mike Granby wrote:

>Sounds like a good idea. What is it?

By E. Douglas Jensen on 8 December, 1999 - 11:51 am

(Originally posted Mon 07/20/1998)
It must not be such a good idea, since most academic
researchers in real-time computing don't agree with that
definition.

Doug

By Armin Steinhoff on 2 December, 1999 - 11:33 am

(Originally posted Thu 07/09/1998)
>I think I would have to agree with Mike Granby that the term "RTOS" just
>does not have much value anymore.

That means the upcoming RTOS version of WinCE has no additional values
compared to the existent versions ??

No value ? ... ask Microsoft how much this development cost :-)

>It used to mean (for me) a small, embedable kernel which was optimized
>for computer hardware support of automation/control applications. Today
>though, many of the scheduling, I/O and sychronization features that
>were typically provided by that class of product are now provided (to
>greater and lessor extent) by general purpose OS's,

Would be nice ... but this is not the reality.

> the difference being largely speed and size.

There are other important attributes ...

>In fact, many "real time" applications are now being successfully
>supported by general purpose OS's. For better, or worse, the difference
>between these classes has decreased greatly.

It depends on your definition of real-time applications ...

Armin Steinhoff

http://www.DACHS.net

By Armin Steinhoff on 1 December, 1999 - 2:54 pm

(Originally posted Tue 07/07/1998)
At 09:10 07.07.98 +0100, Mike Granby wrote:
>Dick,
>
[ ... ]
> ...... 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.

Mike ... what is the exact definition of real-time "when it is applied to
applications" ??

Here is my set of ATTRIBUTES which a real-time system must have ... when I
call it a real-time system.


ATTRIBUTES of REAL-TIME systems.

REAL-TIME Systems in general (minimum requirements)

HARDWARE
- supports at least one interrupt level
- CPU reacts to interrupts
- CPU supports context switching

SOFTWARE
- event driven management of system resources
- deterministic response times to events with a predictable jitter
- deadlines for the processing of events are met with a
predictable jitter
- supports priority levels for task processing
- supports fast context switching of tasks


HARD REAL-TIME Systems

HARDWARE
- supports different interrupt levels (priorities)
- allows nesting of interrupts
- CPU reacts fast to interrupts in the range of nanoseconds
- CPU supports fast context switching in the range to nanoseconds

SOFTWARE
- event driven management of all system resources
- priority levels for interrupt processing
- supports nesting of interrupts

- deterministic response times to events with a worst case
predictable jitter in the maximal range of 10 microseconds

- deadlines for the processing of events are met with a worst case
predictable jitter in a maximal range of 10 microsecond

- supports priority levels for task processing ( 256 at bests ...)
- supports fast context switching of tasks in the range of
microseconds
- supports different scheduling policies (POSIX)


SOFT REAL-TIME Systems

HARDWARE
- support of different interrupt levels (priorities)
is not coercive required
- nesting of interrupts is not coercive required
- CPU reacts to interrupts in the range of 100 miroseconds
- CPU supports context switching in the range to 100 microseconds

SOFTWARE
- management of system resources is not 100% bound to external events
(print and wait ...:-)

- priority levels for interrupt processing
- support of nested interrupts is not coercive required

- deterministic response times to events with a predictable jitter
in the maximal range of 100 microsecond

- deadlines for the processing of events are met with a predictable
jitter in a maximal range of 10 millisecond

- supports priority levels for task processing
- supports of context switching of tasks in the range of milliseconds
- support of different scheduling policies is not coercive required

Armin Steinhoff

<http://www.dachs.net/>

By Mike Granby on 1 December, 1999 - 3:26 pm

(Originally posted Wed 07/08/1998)
> "What is the exact definition of real-time [applications]?"

It was contained in an earlier post. In short, my definition of a
real-time application is one where input data is processed as it
arrives, and output data is provided as it is needed. It is the opposite
of old-style batch or off-line processing. All control systems are by
definition real time applications, or they'd be unable to control
things.

> HARDWARE
> [1] supports at least one interrupt level
> [2] CPU reacts to interrupts
> [3] CPU supports context switching

I agree about [1] and [2], but then again these are hardly onerous
requirements. As for the CPU supporting context switching, if this means
via hardware (ie. a single instruction to swap the entire execution
context) then you're knocking-out many self-proclaimed RTOS's that run
on processors that do not support this sort of thing. If you mean via
software, then virtually any processor is capable of doing this via
stack operations.

> SOFTWARE
> [1] event driven management of system resources
> [2] deterministic response times to events with a predictable jitter
> [3] deadlines for the processing of events are met with a predictable
jitter
> [4] supports priority levels for task processing
> [5] supports fast context switching of tasks

I don't understand "management of system resources" in [1], so I cannot
comment further on that issue. Point [2] requires deterministic response
times to events, but these responses can only be determined in the
context of the application, as the processor can only do one thing at
once. This is thus a property of the application / OS system and not of
the OS itself. The same surely applies to point [3]. I accept point [4]
without argument, while point [5] is quantitative in nature and thus not
a useful part of a solid definition.

The million dollar question: Is WinNT an RTOS under this definition?

> HARD REAL-TIME SYSTEMS

I won't go into these in detail, as most as just tighter version of the
above, although I accept that there are also some unique properties not
included in the non-hard RT definition. Overall, though, I am still left
with the feeling that most of the supposed properties of an RTOS fall
into two categories...

1/ Those properties which are defined in a quantitative way. For
example, an RTOS must meet such-and-such a context switching time, and
must be able to scheduling tasks with an accuracy of so-many
milliseconds. These values of properties are self-evidently defined by
the application in question, and so to my mind cannot form part of a
definition. While you or I might be happy with responses in
milliseconds, some people will need them in microseconds, and some
people might be happy to wait a second or two.

2/ Those properties which are easy to define in a simple system, but
which in a real application are determined just as much by the
application context than by the OS. For example, it has been said that
an RTOS must be able to guarantee that a task can be run by a given
deadline. And yet the RTOS cannot do that if the application has a
higher priority task running at that point. In other words, the response
of the system to the real world is determined as much by the application
as by the OS. Determinism at the OS level is thus only part of it -- the
really important determinism is that of the application-OS system as a
whole.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

By Armin Steinhoff on 2 December, 1999 - 11:52 am

(Originally posted Thu 07/09/1998)
At 09:55 08.07.98 +0100, Mike Granby wrote:
>> "What is the exact definition of real-time [applications]?"
>
[ clip ..]
>
>> HARDWARE
>> [1] supports at least one interrupt level
>> [2] CPU reacts to interrupts
>> [3] CPU supports context switching
>
>I agree about [1] and [2], but then again these are hardly onerous
>requirements. As for the CPU supporting context switching, if this means
>via hardware (ie. a single instruction to swap the entire execution
>context) then you're knocking-out many self-proclaimed RTOS's that run
>on processors that do not support this sort of thing.

Yes ... this criterion is too hard.

>If you mean via software, then virtually any processor is capable of doing
this via
>stack operations.
>
>> SOFTWARE
>> [1] event driven management of system resources
>> [2] deterministic response times to events with a predictable jitter
>> [3] deadlines for the processing of events are met with a predictable
>> jitter
>> [4] supports priority levels for task processing
>> [5] supports fast context switching of tasks
>
>I don't understand "management of system resources" in [1],

System resources are CPU time, shared resources like memory or IOs ...
which are assigned to processes by external events (also time events) ...
so e.g. the CPU is assigned based on external events ... priority driven.

>so I cannot comment further on that issue. Point [2] requires
deterministic >response
>times to events, but these responses can only be determined in the
>context of the application, as the processor can only do one thing at
>once. This is thus a property of the application / OS system and not of
>the OS itself. The same surely applies to point [3]. I accept point [4]
>without argument, while point [5] is quantitative in nature and thus not
>a useful part of a solid definition.

It is an important technology attribute ....

>The million dollar question: Is WinNT an RTOS under this definition?
>
>> HARD REAL-TIME SYSTEMS
>
>I won't go into these in detail, as most as just tighter version of the
>above, although I accept that there are also some unique properties not
>included in the non-hard RT definition. Overall, though, I am still left
>with the feeling that most of the supposed properties of an RTOS fall
>into two categories...
>
>1/ Those properties which are defined in a quantitative way. For
>example, an RTOS must meet such-and-such a context switching time, and
>must be able to scheduling tasks with an accuracy of so-many
>milliseconds. These values of properties are self-evidently defined by
>the application in question, and so to my mind cannot form part of a
>definition. While you or I might be happy with responses in
>milliseconds, some people will need them in microseconds, and some
>people might be happy to wait a second or two.

The response time is only an important technology parameter which helps to
meet deadlines. E.g. with a response time to events (processing start) with
a variation of milliseconds ... you can't meet deadlines (processing end)
with a variation in the range of 100us.


>2/ Those properties which are easy to define in a simple system, but
>which in a real application are determined just as much by the
>application context than by the OS. For example, it has been said that
>an RTOS must be able to guarantee that a task can be run by a given
>deadline. And yet the RTOS cannot do that if the application has a
>higher priority task running at that point. In other words, the response
>of the system to the real world is determined as much by the application
>as by the OS.

This shows how important it is that "the management of system resources" is
event driven !

The application can hold the CPU only for a defined 'time slice' ... and
will then be preempted by the scheduler . The rest has to be defined by
the task design of the whole software system.

Armin Steinhoff

http://www.DACHS.net

By Simon Martin on 1 December, 1999 - 3:44 pm

(Originally posted Tue 07/07/1998)
Hey Armin,

The definitions here have absolutely NO meaning, as you do not specify the
system this is being inserted into. The numbers you quote could be
ridiculous (too fast or too slow) depending on the system you are
controlling. As for requiring multiple interrupts levels, this is *not* a
requirement, e.g. if I destine a processor, microcontroller, ASIC, FPGA,
abacus, pocket calculator, etc. (depending on the selected technology) to
handle each event, I do not require multiple interrupt levels, I do not even
need interrupts, as I can run a polling system, which if it handles all
events "predictably given the systems time constraints" then what's the
problem?

As I said before *if you don't specify the system, real-time has no
meaning*. If a general purpose quantitative measure is required then it
should be something along the lines of:

REAL-TIME System:
A system that is guaranteed to handle all events within the time constraints
dictated by the physical system with which it is connected.

HARD REAL-TIME:
A real-time system in which the timeliness of the event handling is
guaranteed primordially by its physical configuration.

SOFT REAL-TIME:
A real-time system in which the timeliness of the event handling is
guaranteed by a combination of its physical and logical configurations.

This is a first stab, anyone want to improve on it?

Simon Martin
mailto:smartin@reuna.cl

By Armin Steinhoff on 2 December, 1999 - 11:25 am

(Originally posted Thu 07/09/1998)
Hi Martin,

At 17:54 07.07.98 -0400, you wrote:
>Hey Armin,
>
>The definitions here have absolutely NO meaning, as you do not specify the
>system this is being inserted into.

It has absolutely a meaning for the concrete "technological" reqirements
... for the real existing classes of real-time systems.

> The numbers you quote could be ridiculous (too fast or too slow)
depending on the system you are controlling.

Yes ... of cause :-). But you must define limits for differentiations ...
and these limits are always in question.

>As for requiring multiple interrupts levels, this is *not* a requirement,

A realtime system must respond to external events ... at least to manage
the most important resource - the CPU - . This must also be possible when
the CPU handels an event triggered by an hardware interrupt ... so you need
an interrupt with a higher hardware priority to serve immediately the more
important external event.

> e.g. if I destine a processor, microcontroller, ASIC, FPGA,
>abacus, pocket calculator, etc. (depending on the selected technology) to
>handle each event, I do not require multiple interrupt levels, I do not even
>need interrupts,

Interesting theory ... how do you control the different polling loops ??
How would you assign the CPU to the polling loops ???

> as I can run a polling system, which if it handles all
>events "predictably given the systems time constraints" then what's the
>problem?

Yes ... it works just for a specific class of application. But what happens
when the whole polling process takes 20ms ... and you have to respond
predictably in the time range of 50 us ... to meet the deadline of the
processing of an external event e.g. in the time range of 1ms ???

>As I said before *if you don't specify the system, real-time has no meaning*.

I talked about ATTRIBUTES of 'real-time' computer systems based on the
existing technology ... so there is a clear meaning.

> If a general purpose quantitative measure is required then it
>should be something along the lines of:
>
>REAL-TIME System:
>A system that is guaranteed to handle all events within the time constraints
>dictated by the physical system with which it is connected.

Good general definition .... as long as "time constrains" means "meeting of
all
deadlines" .

( In the real world you have to define a predictable worst case variation
in meeting of deadlines ...)

>HARD REAL-TIME:
>A real-time system in which the timeliness of the event handling is
>guaranteed primordially by its physical configuration.

Too general ... I don't see any differences to the definition of REAL-TIME !

>SOFT REAL-TIME:
>A real-time system in which the timeliness of the event handling is
>guaranteed by a combination of its physical and logical configurations.

This definition is not from (and for) this world ... guaranteed :-)

Armin Steinhoff

http://www.DACHS.net

By Simon Martin on 2 December, 1999 - 3:19 pm

(Originally posted Fri 07/10/1998)
Back again. Am I a sucker for punishment or what???

The whole gist of my previous mail was supposed to be that real-time has no
meaning in general terms, only in specific instances. Saying that a Windows
NT, QNX, POSIX, etc. is real-time,or not, per se, is like saying all cars
can do over 150 mph (this is true, drive a car off a cliff and measure the
terminal velocity!!) It depends on the circumstances!!!

With respect your comments: (answers in line)

<snip>
> > The numbers you quote could be ridiculous (too fast or too slow)
> > depending on the system you are controlling.
>
> Yes ... of cause :-). But you must define limits for differentiations ...
> and these limits are always in question.


If we are going to use limits to differentiate between real-time and non
real-time then these limits must be applicable WHATEVER CHARACTERISTICS OF
ANY GIVEN SYSTEM. Given the number of different possible characteristics,
then the only way I can see using limits is by defining them as some
function of these characteristics. What characterisitics do you use to set
the limits and how do you define the functions? That is a different subject
which we could elaborate on, if anyone wants to... (I do)

<snip>
> > e.g. if I destine a processor, microcontroller, ASIC, FPGA,
> >abacus, pocket calculator, etc. (depending on the selected technology) to
> >handle each event, I do not require multiple interrupt levels, I do not
even
> >need interrupts,
>
> Interesting theory ... how do you control the different polling loops ??
> How would you assign the CPU to the polling loops ???


How about power-on. Initialise master processor. Initialise environment for
each subsidiary processor. Release subsidiarty processors. Done.

> > as I can run a polling system, which if it handles all
> >events "predictably given the systems time constraints" then what's the
> >problem?
>
> Yes ... it works just for a specific class of application. But what
happens
> when the whole polling process takes 20ms ... and you have to respond
> predictably in the time range of 50 us ... to meet the deadline of the
> processing of an external event e.g. in the time range of 1ms ???

You said that interrupts are a requirement for a system to be considered
real-time. You agree some systems do not require interrupts to be considered
real-time. These two statements are mutually inconsistent. All I tried to
show is that to imply interrupt handling as a requirement for real-time
processing
is incorrect, and therefore should *not* be a part of a the definition of a
real-time system.

> >As I said before *if you don't specify the system, real-time has no
meaning*.
>
> I talked about ATTRIBUTES of 'real-time' computer systems based on the
> existing technology ... so there is a clear meaning.


You have only specified HALF of the system with this. The computer system.
All this system must do is react to the stimulii from the external system
within a given set of time constraints (deadlines). You must specify the
stimulii and the deadline ATTRIBUTES as well, in order to have any meaning.
If we use your definition of SOFT REAL-TIME as the basis of a hypothetical
tungsten filament lighting control system, you have overkill by a factor of
several 1000. It would be like killing a mouse with a missile, it'd kill the
mouse but isn't there an easier/cheaper/more efficient way of achieving the
same result without losing any apparent functionality or flexibility.

> > If a general purpose quantitative measure is required then it
> >should be something along the lines of:
> >
> >REAL-TIME System:
> >A system that is guaranteed to handle all events within the time
constraints
> >dictated by the physical system with which it is connected.
>
> Good general definition .... as long as "time constrains" means "meeting
of
> all deadlines" .


That was my intention...

> ( In the real world you have to define a predictable worst case variation
> in meeting of deadlines ...)


My first big difficulty. If you are suggesting that not meeting deadlines is
real-time as long as you have predictable worst cases, I hope you're never
involved in the design/construction of life threatening machinery (i.e.
anything with moving parts). It is dangerous enough comissioning new
equipment without wondering whether the response is stable... For example if
I specify a mechanical relay control system, and specify that the
predictable worst case variations is about 10 minutes (someone got hurt,
technician found the faulty relay, technician changed said relay), then I
should be shot.

In my opinion, not meeting deadlines must be considered a fatal fault.
Immediate transition to safe state should ensue. The definition of safe
state depends on the "physical" system.

> >HARD REAL-TIME:
> >A real-time system in which the timeliness of the event handling is
> >guaranteed primordially by its physical configuration.
>
> Too general ... I don't see any differences to the definition of REAL-TIME
!


The difference is that I specified that the physical configuration is
responsible for the real-timeness of the system.

> >SOFT REAL-TIME:
> >A real-time system in which the timeliness of the event handling is
> >guaranteed by a combination of its physical and logical configurations.
>
> This definition is not from (and for) this world ... guaranteed :-)


I thoroughly agree. I supplied these in order to get people to think what is
really required. As I learnt a long time ago in tech support, never give the
answer as part of the question, otherwise you'll just hear "Yeah, green
light, that's right" or something of the type when it's really red and the
guy never checked.

Ok, if you want something more concrete then what I would like to see for
these measures would be:

HARD REAL-TIME:
Maximum time to handle a given event <= 10% physical system's maximum
Total event handling capacity >= 10 times the physical system's maximum

SOFT REAL-TIME:
Maximum time to handle a given event <= physical system's maximum
Total event handling capacity >= physical system's maximum

This guarantees timeliness of all event handling and allows for some
differentiation between the different types of real-time systems. What
parameters do you use here? What characteristics and relationships are
relevant?

Simon Martin
mailto:smartin@reuna.cl

By Vladimir E. Zyubin on 7 December, 1999 - 1:37 pm

(Originally posted Fri 07/17/1998)
Good morning/afternoon/evening,

On Fri, 10 Jul 1998, Simon Martin wrote:
<snip>
> ... I supplied these in order to get people to think what is
> really required. As I learnt a long time ago in tech support, never give the
> answer as part of the question, otherwise you'll just hear "Yeah, green
> light, that's right" or something of the type when it's really red and the
> guy never checked.

I'm sorry that I have broken into your extremely interesting
conversation. But if the bellow is a trick to get people to think
then I have definitely caught this bait. :-)

> Ok, if you want something more concrete then what I would like to see for
> these measures would be:
>
> HARD REAL-TIME:
> Maximum time to handle a given event <= 10% physical system's maximum
> Total event handling capacity >= 10 times the physical system's maximum
>
> SOFT REAL-TIME:
> Maximum time to handle a given event <= physical system's maximum
> Total event handling capacity >= physical system's maximum
>
> This guarantees timeliness of all event handling and allows for some
> differentiation between the different types of real-time systems. What
> parameters do you use here? What characteristics and relationships are
> relevant?

It seems to me that 10% looks very strange for the definition
that pretends to be strict. And I can not understand which way it
can guarantee timeliness of all event handling... Well, perhaps,
if there are only 10 unified event sources in the control system.

IMO, to guarantee timeliness of all event handling, the
following conditions must be true (just for a control system
with events handled by interrupt service routines):

I
Sum(Max(i)) <= Tmin(j), where
i=1

Max(i) - maximal time to handle an event i, i = 1,2,...,(I-1),I;
I - quantity of asynchronous events in the system;
Tmin(j) - minimal required response time for the system
(supposedly, it is equal to the response time of an event
j).

I.e., to mathematically test the control system, we have
to:

1. Choose the minimal required response time from required
response times of all events that there are in the control
system -- Tmin(j);

2. Calculate maximal handling time for every event of the
system -- Max(i), i = 1, 2, 3, ..., I;

I
3. Sum the results -- Sum(Max(i));
i=1

4. Compare the result with the minimal required response time.

If the result less or equal to the minimal required response time
then you are King of the Controlled Object.

Note: It is neither applicable for all possible control
systems nor strict mechanism. It is just my humble attempt to
make the things a bit clear. For example, a) for a control system
with a polling mechanism it is not the case, b) ditto if the
required response times is very different, etc... I.e., if there
is necessity then control systems, data acquisition systems, and
other digital applications should be categorized via mechanism
utilized in order to provide implementation of the requirements
of the technical specification for development. IMO.

By the way, the requirements in overwhelming majority of
the cases are stated with the simple sentence:
The accuracy shall be no worse than... ;-)
arenŠt it?

Regards,

Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

"In mathematics all is simple: any problem either is trivial
or has no solution... :-)"
E. Zakhryamin (mathematician, my old pal)

By Simon Martin on 7 December, 1999 - 2:14 pm

(Originally posted Wed 07/29/1998)
Thanks Vladimir,

I stand (er sit) corrected. I think we need a mix of the 2 to insure
timeliness, such that:

Let P be a physical process
Let D be a control device
Let S be a system consisting of P to be controlled D
Let Event be the set of all events to be handled by RS
Let n be the number of events in Event
Let e(i) be the i-th element of Event
Let Tmaxp(i) be the maximum time permissible by P for D to handle event
e(i)
Let Tmaxd(i) be the maximum time D will take to handle event e(i)
Let Cthroughput be defined as the following condition:
n n
Sum f*Tmaxd(i) <=3D Sum Tmaxp(i) (This I take to be your
definition)
i=3D0 i=3D0
Let Ctimeliness be be defined as the following condition:
f*Tmaxd(i) <=3D Tmaxp(i) 0<=3Di<=3Dn (This I take from my original
definition)

If Cthroughput and Ctimeliness hold true for f=3D1 =3D> S can be
considered realtime
If Cthroughput and Ctimeliness hold true for f=3D0.8 =3D> S can be
considered soft realtime
If Cthroughput and Ctimeliness for f=3D0.1 =3D> S can be considered
hard realtime

This definition makes sure that ALL events can be processed, and ALL
events are timely.

A different approach for soft realtime might be to lift the restriction
on Ctimeliness and just make sure that all events are handled, e.g.

If Cthroughput holds true for f=3D0.8 =3D> S can be considered soft
realtime

Any more contributions. (This is fun, but then again I have a strange
sense of humour)

Simon Martin

By Vladimir E. Zyubin on 8 December, 1999 - 11:52 am

(Originally posted Fri 07/31/1998)
Hello to everybody,

At Fri, 17 Jul 1998 16:36:49 -0400 Simon Martin wrote:
>
> I stand (er sit) corrected. I think we need a mix of the 2 to insure
> timeliness, such that:
>
> Let P be a physical process
> Let D be a control device
> Let S be a system consisting of P to be controlled D
> Let Event be the set of all events to be handled by RS
> Let n be the number of events in Event
> Let e(i) be the i-th element of Event
> Let Tmaxp(i) be the maximum time permissible by P for D to handle event
> e(i)
> Let Tmaxd(i) be the maximum time D will take to handle event e(i)

Accepted. Excellent notation.

> Let Cthroughput be defined as the following condition:
> n n
> Sum f*Tmaxd(i) <= Sum Tmaxp(i) (This I take to be your definition)
> i=0 i=0

Just a comment:
My original condition expressed in your notation will look like:

n
Sum Tmaxd(i) <= Min{Tmaxp(i)}, where
i=0

Min{Tmaxp(i)} - the minimal time of the set of Tmaxp(i).

I.e., if there is only 2 event in the system -- e(0) and e(1),
and, for instance, Tmaxp(0) = 1000 sec and Tmaxp(1) = 1 sec,
then the Min{Tmaxp(i)} = 1 sec.
(I do understand that this condition is extremely
rigorous, but it deliver us from consideration of order of the
event handling. Please, keep in mind that the (asynchronous)
events can appear =simultaneously=)

> Let Ctimeliness be be defined as the following condition:
> f*Tmaxd(i) <= Tmaxp(i) 0<=i<=n (This I take from my original definition)
>
> If Cthroughput and Ctimeliness hold true for f=1 => S can be
> considered realtime
> If Cthroughput and Ctimeliness hold true for f=0.8 => S can be
> considered soft realtime
> If Cthroughput and Ctimeliness for f=0.1 => S can be considered
> hard realtime

Just a couple of remarks:

1. It seems to me that "f" (I assume that "f" is just a constant)
must be on the right side of the equations. I.e.,

n n
Sum Tmaxd(i) <= f*Sum Tmaxp(i)
i=0 i=0

Tmaxd(i) <= f*Tmaxp(i) 0<=i<=n.

Otherwise, for f=0.0 you will have that Cthroughput and
Ctimeliness hold true for any system.

2. The 0.8 and 0.1 look very strange to me... why not
0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)

> This definition makes sure that ALL events can be processed, and ALL
> events are timely.

I am not sure... However, perhaps, I misunderstood
something. If so, please explain.

> A different approach for soft realtime might be to lift the restriction
> on Ctimeliness and just make sure that all events are handled, e.g.
>
> If Cthroughput holds true for f=0.8 => S can be considered soft
> realtime
>
> Any more contributions. (This is fun, but then again I have a strange
> sense of humour)

Oh, Simon, all what I can... :-)

Best Regards,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

By Simon Martin on 10 December, 1999 - 4:51 pm

(Originally posted Tue 08/04/1998)
Hi all,

I've been talking this through with a friend and we have come to the
conclusion that the concept of "determinism" must also be included in the
definiton, so using some of Vladimir's corrections of my original post,
let's try again:

Let P be a physical process
Let D be a control device
Let S be a system consisting of P to be controlled D
Let Event be the set of all events to be handled by S
Let n be the number of events in Event
Let e(i) be the i-th element of Event
Let Tmaxp(i) be the maximum time permissible by P for D to handle event e(i)
Let Twander(i) be the maximum time deviance permissible by P for the
response to event e(i)
Let Tmaxd(i) be the maximum time D will take to handle event e(i)
Let Tmind(i) be the minimum time D will take to handle event e(i)
Let h be an arbitrary constant in the range 0<h<=1 which measures the
"harshness" of the conditions that define a real time system.
Let Cthroughput be defined as the following condition:
n n
Sum Tmaxd(i) <= h*Sum Tmaxp(i)
i=0 i=0
Let Ctimeliness be defined as the following condition:
Tmaxd(i) <= h*Tmaxp(i) 0<=i<=n.
Let Cdeterminism be defined as the following condition:
Tmaxd(i)-Tmind(i) <= Twander(i) 0<=i<=n

If Cdeterminism, Cthroughput and Ctimeliness hold true for h=1 then S can be
considered realtime

If Cdeterminism, Cthroughput and Ctimeliness hold true for f=0.8 => S can be
considered soft realtime
If Cthroughput and Ctimeliness for f=0.1 => S can be considered hard
realtime


With respect Vladimir's observations
<snip>
>Just a couple of remarks:
>
>1. It seems to me that "f" (I assume that "f" is just a constant)
>must be on the right side of the equations. I.e.,
> Otherwise, for f=0.0 you will have that Cthroughput and
>Ctimeliness hold true for any system.
>
Thanks Vladimir, you can tell that it's been a long time since I last had to
do a formal proof.
>2. The 0.8 and 0.1 look very strange to me... why not
>0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)
>
It's ok to define things, but in order to take decisions then we have to
some quantifiable measure. Where do we draw the line between hard and soft
realtime? This was just my first stab at some values for defining,
quantitively, not qualitively, when to consider a system real time, and
furthermore when it is hard real time or soft real time. The value for the
"harshness" factor must be set by someone who knows more than me and can
justify the values given, but I had to have a go!!!
>> This definition makes sure that ALL events can be processed, and ALL
>> events are timely.
>
> I am not sure... However, perhaps, I misunderstood
>something. If so, please explain.
>
The condition Cthroughput will assure that the system will be able to handle
all the events that physical system generates within the restraints given by
this physical system.

The condition Ctimeliness will assure that each event will be handled within
the restrictions given by the physical system. Cthroughput is a consequence
of Ctimeliness, but I separated out both conditions for 2 reasons:

a) to be able to force a certain "slack" in the system, i.e. the system is
able to handle more events than the physical system because engineers are
very good at using Occam's Razor, quite often ignoring the non-ignorable. I
know, I'm an engineer!!!!!!

b) reading Armin's mails, there may be some rope in letting a system handle
the throughput, but not reach every deadline. This really gives me the
willies, but I defer to people who may know more, or different things, than
I do (the difference between a good solution and an optimum solution)
<snip>

I decided not to use Vladimir's definition:
n n
sum Tmaxd(i) <= min Tmaxp(i)
i=0 i=0
as I feel this is too harsh. I don't think that there are many systems that
can respond to ALL events within the maximum time to handle the most
demanding event.

Hope this discussion continues. :-)

Simon Martin

By Armin Steinhoff on 10 December, 1999 - 4:58 pm

(Originally posted Thu 08/06/1998)
>Let P be a physical process
>Let D be a control device
>Let S be a system consisting of P to be controlled D
>Let Event be the set of all events to be handled by S
>Let n be the number of events in Event
>Let e(i) be the i-th element of Event
>Let Tmaxp(i) be the maximum time permissible by P for D to handle event e(i)
>Let Twander(i) be the maximum time deviance permissible by P for the
>response to event e(i)
>Let Tmaxd(i) be the maximum time D will take to handle event e(i)
>Let Tmind(i) be the minimum time D will take to handle event e(i)
>Let h be an arbitrary constant in the range 0<h<=1 which measures the
>"harshness" of the conditions that define a real time system.
>Let Cthroughput be defined as the following condition:
> n n
> Sum Tmaxd(i) <= h*Sum Tmaxp(i)
> i=0 i=0
>Let Ctimeliness be defined as the following condition:
> Tmaxd(i) <= h*Tmaxp(i) 0<=i<=n.
>Let Cdeterminism be defined as the following condition:
> Tmaxd(i)-Tmind(i) <= Twander(i) 0<=i<=n
>
>If Cdeterminism, Cthroughput and Ctimeliness hold true for h=1 then S can be
>considered realtime
>
>If Cdeterminism, Cthroughput and Ctimeliness hold true for f=0.8 => S can be
>considered soft realtime
>If Cthroughput and Ctimeliness for f=0.1 => S can be considered hard
>realtime
>

Good definition !! The definition of Cthroughput shows the absolute worst
case ... multiplied with a simultaneousness factor ( defined by P) gives
more realistic values for the neccessary computing power.

>b) reading Armin's mails, there may be some rope in letting a system handle
>the throughput, but not reach every deadline.

When I remember right, my point was the variation of 'reaching a deadline'
... the approach was to use the precision of reaching a deadline for the
differentiation between soft and hard realtime behavior.

Regards

Armin Steinhoff

http://www.DACHS.net

By Vladimir E. Zyubin on 16 December, 1999 - 5:00 pm

(Originally posted Fri 08/07/1998)
Dear List,

At Tue, 4 Aug 1998 11:52:27 -0400 Simon Martin wrote:
<snip>
=============== TERMINOLOGY ===================
> Let P be a physical process
> Let D be a control device
> Let S be a system consisting of P to be controlled D
> Let Event be the set of all events to be handled by S
> Let n be the number of events in Event
> Let e(i) be the i-th element of Event
> Let Tmaxp(i) be the maximum time permissible by P for D to handle event
> e(i)
> Let Twander(i) be the maximum time deviance permissible by P for the
> response to event e(i)
> Let Tmaxd(i) be the maximum time D will take to handle event e(i)
> Let Tmind(i) be the minimum time D will take to handle event e(i)
> Let h be an arbitrary constant in the range 0<h<=1 which measures the
> "harshness" of the conditions that define a real time system.
> Let Cthroughput be defined as the following condition:
> n n
> Sum Tmaxd(i) <= h*Sum Tmaxp(i)
> i=0 i=0
> Let Ctimeliness be defined as the following condition:
> Tmaxd(i) <= h*Tmaxp(i) 0<=i<=n.
> Let Cdeterminism be defined as the following condition:
> Tmaxd(i)-Tmind(i) <= Twander(i) 0<=i<=n

========= DEFINITION OF REAL-TIME (APPLICATION)
==========================
> If Cdeterminism, Cthroughput and Ctimeliness hold true for h=1 then S can
> be
> considered realtime
>
> If Cdeterminism, Cthroughput and Ctimeliness hold true for f=0.8 => S can
> be
> considered soft realtime
> If Cthroughput and Ctimeliness for f=0.1 => S can be considered hard
> realtime
=================================================
<snip>

> >2. The 0.8 and 0.1 look very strange to me... why not
> >0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)
> >
> It's ok to define things, but in order to take decisions then we have to
> some quantifiable measure. Where do we draw the line between hard and soft
> realtime? This was just my first stab at some values for defining,
> quantitively, not qualitively, when to consider a system real time, and
> furthermore when it is hard real time or soft real time. The value for the
> "harshness" factor must be set by someone who knows more than me and can
> justify the values given, but I had to have a go!!!

I think nobody can justify the values because there are no criteria (I don't see at least). Where do we draw the line between hard and soft realtime? - IMO, the correct question would
be: what is reason we have to draw this line? What is value of the terms? Especially, when there are so many orthogonal definitions. It was very demonstrative when your discussion with Mr.Steinhoff about "hard/soft real time systems"
was ended by Mr.Steinhoff's sentence that he was speaking about hard/soft real time =operating= systems... I bet that words like "control" or "operating" could not allow us to get this
curious situation.

> >> This definition makes sure that ALL events can be processed, and ALL
> >> events are timely.
> >
> > I am not sure... However, perhaps, I misunderstood
> >something. If so, please explain.
> >
> The condition Cthroughput will assure that the system will be able to
> handle
> all the events that physical system generates within the restraints given
> by
> this physical system.

Yes, but it is not enough in order to handle all events in any application if we allow asynchronous appearance of the events... Ditto for Ctimeliness.

Example:
n = 20,
Tmaxp(i) = 19,9 sec, 0<=i<20,
Tmaxd(i) = Tmind(i) = 1.0 sec, 0<=i<20,
Twander(i) = 0.0 sec, 0<=i<20,
h = 0.1
----------------------------------
I.e., Cdeterminism, Cthroughput and Ctimeliness hold true for h=0.1.
Question: Will all events be handled timely if all 20 events appear simultaneously?
Answer: No.

> The condition Ctimeliness will assure that each event will be handled
> within
> the restrictions given by the physical system. Cthroughput is a consequence
> of Ctimeliness, but I separated out both conditions for 2 reasons:
>
> a) to be able to force a certain "slack" in the system, i.e. the system is
> able to handle more events than the physical system because engineers are
> very good at using Occam's Razor, quite often ignoring the non-ignorable. I
> know, I'm an engineer!!!!!!
>
> b) reading Armin's mails, there may be some rope in letting a system handle
> the throughput, but not reach every deadline. This really gives me the
> willies, but I defer to people who may know more, or different things, than
> I do (the difference between a good solution and an optimum solution)
> <snip>

Because Cthroughput is a consequence of Ctimeliness, the elimination of Cthroughput means just simplification of the definition without losing of the value. So, I dare to make the suggestion -- eliminate Cthroughput.

> I decided not to use Vladimir's definition:
> n n
> sum Tmaxd(i) <= min Tmaxp(i)
> i=0 i=0
> as I feel this is too harsh. I don't think that there are many systems that
> can respond to ALL events within the maximum time to handle the most
> demanding event.

I don't pretend it is necessary. Moreover, it is not adequate condition for =all= real cases in order to consider a system intended to control as a control system... But if you will dig deeper (will try to make the condition less
harsh) the picture will fall to pieces that will be described by different conditions (i.e., you will have a "burst of complexity"). IMO.

Oh, yes, and there is the error - either n+1 is the number of events in Event or we ought to use i=1 instead i=0. (Simon, please, consider this as a sign of my attention to your letter,
but not as a display of my captious character :-)

> Hope this discussion continues. :-)

And after this discussion the interesting question would be:
Let there is a hypothetical system with Tmaxd(i)=0.0(0<=i<n) intended to control a process... Can we consider this system as a control system? (I think no. Do you? :-)

Best regards,
--
Vladimir E. Zyubin

By Armin Steinhoff on 27 December, 1999 - 1:09 pm

(Originally posted Fri 08/07/1998)
At 21:10 06.08.98 -0700, Vladimir E. Zyubin wrote:
>Dear List,
>
>At Tue, 4 Aug 1998 11:52:27 -0400 Simon Martin wrote:
><snip>
>
>> >2. The 0.8 and 0.1 look very strange to me... why not
>> >0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)
>> >
>> It's ok to define things, but in order to take decisions then we have to
>> some quantifiable measure. Where do we draw the line between hard and soft
>> realtime? This was just my first stab at some values for defining,
>> quantitively, not qualitively, when to consider a system real time, and
>> furthermore when it is hard real time or soft real time. The value for the
>> "harshness" factor must be set by someone who knows more than me and can
>> justify the values given, but I had to have a go!!!
>
>I think nobody can justify the values because there are no
>criteria (I don't see at least).

There are clear technology criterions like: time resolution, precision in meeting of deadlines and so on ...

> Where do we draw the line between hard and soft realtime?
> - IMO, the correct question would be: what is reason we have to draw this
line?
> What is value of the terms?

The question is: what criterions must be use to select the right tools to solve your control problems ?

For instance ... would you be able to test ALL operating systems to select ONE for real-time processing ?

> Especially, when there are so many
>orthogonal definitions. It was very demonstrative when your
>discussion with Mr.Steinhoff about "hard/soft real time systems"
>was ended by Mr.Steinhoff's sentence that he was speaking about
>hard/soft real time =operating= systems... I bet that words like
>"control" or "operating" could not allow us to get this
>curious situation.

An 'operating system' is a piece of software ...
a 'control system' consists of software and hardware which interfaces the real world ...
a 'control application' is a the sum of a control system and the controlled physical process. IMHO ... that's the common understanding of that terms.

Each part of control system must meet technology attributes to handle the
requirements of the controlled physical process.

My approach was to define some technological criteria in order to decide which of the so called RTOSes can be use for soft-realtime or hard-realtime control applications.

<snip>
>
>Because Cthroughput is a consequence of Ctimeliness, the
>elimination of Cthroughput means just simplification of the
>definition without losing of the value. So, I dare to make
>the suggestion -- eliminate Cthroughput.

I don't think so ... you can't be sure to meet all deadlines without the
appropriate throughput.

>> I decided not to use Vladimir's definition:
>> n n
>> sum Tmaxd(i) <= min Tmaxp(i)
>> i=0 i=0
>> as I feel this is too harsh. I don't think that there are many systems that
>> can respond to ALL events within the maximum time to handle the most
>> demanding event.

After a second thought ...I would use this definition as criterion whether a control system can meet all timelines or not ... but I would introduce a factor S for simultaneousness, because not all Tmaxp(i) can be active at the same time.


n n
S * sum Tmaxd(i) <= min Tmaxp(i)
i=0 i=0

n n
with S = max sum simul active Tmaxd(i) / sum Tmaxd(i)
i=0 i=0

('max sum simul active' is the maximum sum of Tmaxd of all groups
processes which can be active at the same time.)

or in other words ...

n n

max sum simul active Tmaxd(i) <= min Tmaxp(i)
i=0 i=0


If this condition is true ... we are _basically_ able to meet all deadlines.

But this tells us nothing about how exact the deadlines are met. My approach is to use the precision in meeting the deadlines for the
differentiation of hard and soft real-time OPERATING SYSTEMS.

[ clip ..]

>> Hope this discussion continues. :-)
>
>And after this discussion the interesting question would be:
>Let there is a hypothetical system with Tmaxd(i)=0.0(0<=i<n)
>intended to control a process... Can we consider this system as a
>control system?

Why not ?

Regards

Armin Steinhoff

http://www.DACHS.net

By Vladimir E. Zyubin on 7 January, 2000 - 4:50 pm

(Originally posted Fri 08/12/1998)
On Fri, 7 Aug 1998, Armin Steinhoff wrote:

[S -> Simon Martin, V -> Vladimir E. Zyubin]

V:
> >> >2. The 0.8 and 0.1 look very strange to me... why not
> >> >0.79999(9) or 0.1111111(1)? or Why not e^-1 (1/2.718281...)? :-)

S:
> >> It's ok to define things, but in order to take decisions then we have to
> >> some quantifiable measure. Where do we draw the line between hard and soft
> >> realtime? This was just my first stab at some values for defining,
> >> quantitively, not qualitively, when to consider a system real time, and
> >> furthermore when it is hard real time or soft real time. The value for the
> >> "harshness" factor must be set by someone who knows more than me and can
> >> justify the values given, but I had to have a go!!!

V:
> >I think nobody can justify the values because there are no
> >criteria (I don't see at least).
>
> There are clear technology criterions like: time resolution, precision in
> meeting of deadlines and so on ...

So, what are your values of h?

V:
> > Where do we draw the line between hard and soft realtime?
> > - IMO, the correct question would be: what is reason we have to draw this line?
> > What is value of the terms?
>
> The question is: what criterions must be use to select the right tools to
> solve your control problems ?

IMO, it depends on a given control problem: reliability, maintainability, robustness, ergonomics, ecology, economics, etc. Some of the criteria can be reduced to accuracy problem. Some of the accuracy problems can
be reduced to so-called "real time problem" that can be easily reduced to problem of execution efficiency... So, the "right" tool that provides solution of the problem does not mean solution of a given control problem.

> For instance ... would you be able to test ALL operating systems to select
> ONE for real-time processing ?

I don't think the adjectives "real time" can help somebody to make the choice. For instance... the choice between QNX and NT. IMO, to show the advantages of QNX you ought to use another terminology.

> Each part of control system must meet technology attributes to handle the
> requirements of the controlled physical process.

Yes, and execution efficiency is not the main attribute always and everywhere.

> My approach was to define some technological criterions in order to decide
> which of the so called RTOSes can be use for soft-realtime or hard-realtime
> control applications.

But before, we have to define words "soft-/hard-/real time control application". I doubt it is possible... moreover, necessary, but this activity is interesting and helpful.

V:
> >Because Cthroughput is a consequence of Ctimeliness, the
> >elimination of Cthroughput means just simplification of the
> >definition without losing of the value. So, I dare to make
> >the suggestion -- eliminate Cthroughput.
>
> I don't think so ... you can't be sure to meet all deadlines without the
> appropriate throughput.

If Ctimeliness is true, therefore Cthroughput is true. Ctimeliness is more harsh condition. The suggestion was just a formal remark. By the way, you can not be sure to meet all deadlines even if Ctimeliness (=>Cthroughput) holds true under existing conditions ("h" is a given constant that don't depends on the controlled process).

S:
> >> I decided not to use Vladimir's definition:
> >> n n
> >> sum Tmaxd(i) <= min Tmaxp(i)
> >> i=0 i=0
> >> as I feel this is too harsh. I don't think that there are many systems that
> >> can respond to ALL events within the maximum time to handle the most
> >> demanding event.
>
> After a second thought ...I would use this definition as criterion whether
> a control system can meet all timelines or not ... but I would introduce a
> factor S for simultaneousness, because not all Tmaxp(i) can be actice at
> the same time.
>
> n n
> S * sum Tmaxd(i) <= min Tmaxp(i)
> i=0 i=0
>
> n n
> with S = max sum simul active Tmaxd(i) / sum Tmaxd(i)
> i=0 i=0
>
> ('max sum simul active' is the maximum sum of Tmaxd of all groups
> processes which can be active at the same time.)
>
> or in other words ...
>
> n n
> max sum simul active Tmaxd(i) <= min Tmaxp(i)
> i=0 i=0
>
> If this condition is true ... we are _basically_ able to meet all
> deadlines.

The idea is reasonable. I.e., it can be formalized
via introducing of proper terms. And for the systems with non-asynchronous events it could give us a less harsh condition of the ability.
The disadvantage: It assumes utilization of an additional information. To obtain this information we have to analyze the requirements. Can the analysis be formalized or not -- is a
separate question with non-obvious answer.

> But this tells us nothing about how excat the deadlines are met. My
> approach is to use the precision in meeting the deadlines for the
> differentiation of hard and soft real-time OPERATING SYSTEMS.

It depends on what we shall consider as 'event'
and 'deadline'. At least I have a filling that proper definition of the terms could reduce the problem to the statement "the quickly the better". By the way, I am not sure that now we have an unified definition of 'events' and
'deadlines' for servo control systems...

<snip>
> >Let there is a hypothetical system with Tmaxd(i)=0.0(0<=i<n)
> >intended to control a process... Can we consider this system as a
> >control system?
>
> Why not ?

Because of the problems discussed in the Mr.Miller's message. (Because the accuracy problem is indivisible mixture of various components) And if we precisely looked at the example of two servo control systems Mr. Martin has shown [SOFT: Real time or not Real time...], we could make the conclusion: the former means execution efficiency problem, but the last looks like something different (sensor accuracy problem? resolution problem?).

Regards,
--
Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

By Armin Steinhoff on 18 April, 2000 - 3:21 pm

(Originally posted Wed 08/12/1998)
At 21:59 11.08.98 -0700, Vladimir E. Zyubin wrote:
[ clip .. ]
>> >I think nobody can justify the values because there are no
>> >criteria (I don't see at least).
>>
>> There are clear technology criterions like: time resolution, precision in
>> meeting of deadlines and so on ...
>
>So, what are your values of h?

technology requirements for operating systems for HARD REAL-TIME applications

----------------------------------------------------------------------------

HARDWARE

- supports different interrupt levels (priorities)
- allows nesting of interrupts
- CPU reacts fast to interrupts in the range from nano to micro seconds

SOFTWARE

- event driven management of all system resources
- priority levels for interrupt processing (32 up to 256)
- supports nesting of interrupts

- deterministic response times to events with a worst case predictable jitter in the maximal range of 10 microseconds

- deadlines for the processing of events are met with a worst case predictable jitter in a maximal range of 50 microsecond

- supports priority levels for task processing ( 256 at bests ...)
- supports fast context switching of tasks in the range of microseconds
- supports different scheduling policies (POSIX)


>V:
>> > Where do we draw the line between hard and soft realtime?
>> > - IMO, the correct question would be: what is reason we have to draw
this line?
>> > What is value of the terms?
>>
>> The question is: what criterions must be use to select the right tools to
>> solve your control problems ?
>
> IMO, it depends on a given control problem:
>reliability, maintainability, robustness, ergonomics,
>ecology, economics, etc. Some of the criteria can be reduced
>to accuracy problem. Some of the accuracy problems can
>be reduced to so-called "real time problem" that can
>be easily reduced to problem of execution efficiency...

My problem is now ... what is execution efficiency ??

>So, the "right" tool that provides solution of the problem does
>not mean solution of a given control problem.

Yes ... but it makes sure that you are basically able to solve the problem using that tool.

I would rely on a real hammer if I had to hammer some nails down ... but when the head of the hammer is made by pure marketing ... you will not be very successful =:-)

>> For instance ... would you be able to test ALL operating systems to select
>> ONE for real-time processing ?
>
> I don't think the adjectives "real time" can help
>somebody to make the choice. For instance... the choice
>between QNX and NT. IMO, to show the advantages of QNX you
>ought to use another terminology.

Of cause ... real-time is only one aspect. There are many other buzz words like: scaleability at run time, foot print, reliabilty, POSIX, distributed architecture ... only to name some.

BTW ... I heard that WinCE is only reconfigurable by recompiling some system parts at assembler level. 20 years ago ... the old RSX OS from DEC
used a similar procedure :-)

>> Each part of control system must meet technology attributes to handle the
>> requirements of the controlled physical process.
>
> Yes, and execution efficiency is not the main attribute always and everywhere.

'execution-efficiency' sounds as good as 'real-time' ... both connected buzz words seem to be very dangerous :-)

>> My approach was to define some technological criterions in order to decide
>> which of the so called RTOSes can be use for soft-realtime or hard-realtime
>> control applications.
>
> But before, we have to define words "soft-/hard-
>real time control application". I doubt it is possible...

It should be possible to use the time constrains of the control application
.. ?

[ clip ..]
>
>It depends on what we shall consider as 'event'
>and 'deadline'. At least I have a filling that proper
>definition of the terms could reduce the problem to the
>statement "the quickly the better". By the way, I am not
>sure that now we have an unified definition of 'events' and
>'deadlines' for servo control systems ...

IMHO ... at least these basic terms are clear defined.

BTW .... are there any natural processes which take care about deadlines ?

Reagrds

Armin Steinhoff

http://www.DACHS.net

By Peter Clout on 18 April, 2000 - 3:25 pm

(Originally posted Wed 08/12/1998)
When it comes to commercial solutions for hard real time operating systems there are two groups of solutions, self-hosted and development-target
systems. Self-hosted systems that can have run-time implementations that are ROM-able and priced accordingly are the best solution all round in my
opinion so long as the performance and packaging requirements are met.

We have some experience with Concurrent PowerMAX and this operating system meets all the requirements listed below. It runs on PowerPCs including the single and dual 300MHz PowerPC VME boards from Motorola. Timings are interrupt response of 5-12 microseconds (depending on the hardware) with jitters in the 10 microsecond range. Context switch is 35 microseconds worst case. Interrupt levels and process priorities etc. are 256. Take a look at:

http://www.ccur.com

>----------------------------------------------------------------------------
>-------------------------------------
>
> HARDWARE
>
> - supports different interrupt levels (priorities)
> - allows nesting of interrupts
> - CPU reacts fast to interrupts in the range from nano to micro seconds
>
> SOFTWARE
>
> - event driven management of all system resources
> - priority levels for interrupt processing (32 up to 256)
> - supports nesting of interrupts
>
> - deterministic response times to events with a worst case predictable
>jitter
> in the maximal range of 10 microseconds
>
> - deadlines for the processing of events are met with a worst case
>predictable jitter
> in a maximal range of 50 microsecond
>
> - supports priority levels for task processing ( 256 at bests ...)
> - supports fast context switching of tasks in the range of microseconds
> - supports different scheduling policies (POSIX)


Peter Clout
Vista Control Systems, Inc.
1137 18th. St.
Los Alamos, NM 87544-3304
(505) 662-2484
FAX (505) 662-3956
http://www.vista-control.com

By Vladimir Zyubin on 18 April, 2000 - 3:29 pm

(Originally posted Thurs 08/13/1998)
On Wed, 12 Aug 1998, Armin Steinhoff wrote:
<snip>
> technology requirements for operating systems for HARD REAL-TIME
> applications
> -------------------------------
>
> HARDWARE
>
> - supports different interrupt levels (priorities)
> - allows nesting of interrupts
> - CPU reacts fast to interrupts in the range from nano to micro seconds
>
> SOFTWARE
>
> - event driven management of all system resources
> - priority levels for interrupt processing (32 up to 256)
> - supports nesting of interrupts
>
> - deterministic response times to events with a worst case predictable
> jitter in the maximal range of 10 microseconds
>
> - deadlines for the processing of events are met with a worst case
> predictable jitter in a maximal range of 50 microsecond
>
> - supports priority levels for task processing ( 256 at bests ...)
> - supports fast context switching of tasks in the range of microseconds
> - supports different scheduling policies (POSIX)

A couple of thoughts:

1. The idea of the definition that reflects the
marginal ability of present-day technology is interesting enough.

2. It seems to me that the requirement "The
CPU clock friquency must be no less than..." has been omitted. IMO, this requirement could make the things a bit clear... On the other hand, in this case somebody could say that QNX installed on Intel486, 66MHz does not comply with the requirements for control application at all. I
personally would strongly disagree with his opinion... and in despite of the fact that formally he was right.

<snip>
> >> The question is: what criterions must be use to select the right tools to
> >> solve your control problems ?
> >
> > IMO, it depends on a given control problem:
> >reliability, maintainability, robustness, ergonomics,
> >ecology, economics, etc. Some of the criteria can be reduced
> >to accuracy problem. Some of the accuracy problems can
> >be reduced to so-called "real time problem" that can
> >be easily reduced to problem of execution efficiency...
>
> My problem is now ... what is execution efficiency ??

Execution efficiency problem, which appears only in digital systems, is the problem of providing of minimal time of execution of a given function only via proper programming.

As far as I remember, the words was first introduced by Mr. Griffin. So, Mr. Griffin's remarks and corrections of the definition would be greatly appreciated.

> >So, the "right" tool that provides solution of the problem does
> >not mean solution of a given control problem.
>
> Yes ... but it makes sure that you are basically able to solve the problem
> using that tool.

... but it does not make sure that you are basically able to satisfy all requirements for the control system. Therefore, the information is not sufficient (is notadequate => is not necessary everywhere)...

However, the _main_ circumstance is: the
receiving of the information does not assume any utilization of any now existent definitions of the words "real time". Let's keep in mind that the discussed problem is: the information can not be delivered by the words "real time" because the words can not be adequately defined.

> I would rely on a real hammer if I had to hammer some nails down ... but
> when the head of the hammer is made by pure marketing ... you will not be very successful =:-)

Agreed in full. The suggestion: because the hammer is characterized as a one with the head that is made by pure marketing, the head ought to be changed... :-))) ... Sorry, I have occasionally cast a glance at the subject of this
thread.

<snip>
> > I don't think the adjectives "real time" can help
> >somebody to make the choice. For instance... the choice between QNX and NT. IMO, to show the advantages of QNX you
> >ought to use another terminology.
>
> Of cause ... real-time is only one aspect. There are many other buzz words
> like:
> scaleability at run time, foot print, reliabilty, POSIX, distributed
> architecture ... only to name some.

I admit that the words "foot print" mean shameful gap in my knowledge, but the other words are pretty recognizable... until somebody does not try to use the word "open" instead of the some of them. (Just to be on a safe side: I do know OMAC's definition)

> BTW ... I heard that WinCE is only reconfigurable by recompiling some
> system parts at assembler level. 20 years ago ... the old RSX OS from DEC
> used a similar procedure :-)

Thanks for the interesting info. Conclusion: it is an old well-known solution to provide execution efficiency of software at the expense of structure (really, of maintainability and reliability)... Oh, yes, perhaps, it is not quite correct because N.Virth think that it is fatware
:-)... but I am told MS has parallel solved the priority inversion problem. :-|

<snip>
> > Yes, and execution efficiency is not the main attribute always and
> everywhere.
>
> 'execution-efficiency' sounds as good as 'real-time' ... both connected
> buzz words seem to be very dangerous :-)

:-) Good joke... I hope the above definition has made the situation a bit clear. The words are intended just to indicate the well-known problem with a more or less acceptable way. IMO, the corresponding abilities of the tools can be expressed by concrete numbers, e.g., time of context switching for a given platform, connexion between time of context switching and quantity of parallel processes, time of conversion of
physical input(output) into the internal presentation... Obviously, all these times should be real (i.e., should have a theoretical or practical confirmation)

> >> My approach was to define some technological criterions in order to decide
> >> which of the so called RTOSes can be use for soft-realtime or hard-realtime control applications.
> >
> > But before, we have to define words "soft-/hard-
> >real time control application". I doubt it is possible...
>
> It should be possible to use the time constrains of the control application
> .. ?

Yes, to show this we need just one convincing example...

<snip>
> >statement "the quickly the better". By the way, I am not
> >sure that now we have an unified definition of 'events' and
> >'deadlines' for servo control systems ...
>
> IMHO ... at least these basic terms are clear defined.
>
> BTW .... are there any natural processes which take care about deadlines ?

I would like to look at the examples too...

Regards,
--
Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

By Michael Griffin on 18 April, 2000 - 3:35 pm

(Originally posted Fri. 08/14/1998)
>On Wed, 12 Aug 1998, Armin Steinhoff wrote:
><snip>
>> My problem is now ... what is execution efficiency ??
>
Vladimir E. Zyubin replied:

>Execution efficiency problem, which appears only in digital
>systems, is the problem of providing of minimal time of
>execution of a given function only via proper programming.
> As far as I remember, the words was first introduced
>by Mr. Griffin. So, Mr. Griffin's remarks and corrections
>of the definition would be greatly appreciated.
<clip>

The phrase "execution efficiency" was commonly used in the past in computer programming literature to refer to performing a software function in as few clock cycles as possible. Achieving this was considered to be one of the greatest expressions of the programmer's art. It was contrasted with "programmer efficiency" or "programming productivity" or some such similar
phrase which referred to minimising the man hours involved in writing the program even at the expense of having a slower program.
It is interesting to remember that not all that long ago, almost all serious volume commmercial applications which ran on PCs were written in assembly language. 'C' or other compilers produced programs which were simply too large and slow to be acceptable for products like word processors. However, in the case of more specialised, lower volume applications, high level languages were used to reduce the cost of
programmer man hours. Thus you had a trade off between program speed and program cost where the optimal solution was not the same for every situation.
Nowdays as microprocessors get faster the balance has shifted towards minimising the manhours involved in writing a program. Newer
programming languages or systems such as Java are designed with this in mind.

*******************
Michael Griffin
London, Ont. Canada
mgriffin@wwdc.com
*******************

(Originally posted Fri 08/07/1998)
Isn't "hard real-time, deterministic" something like a cam and follower. The "cam follower" deflects from the cam centerline of rotation according to the cam profile and the radial position of the cam shaft. With perfect mechanical properties the "input" rotation will cause a corresponding
"output" lift. The system throughput will be directly proportional to the input (rotation) and the cam profile and the response efficiency will be 100%(response time is 0).
This to me represents a "hard-real-time, deterministic" system, But that system is pretty useless!
We have: shafts that are not rigid, hydraulic cushions, imperfect lubricants imperfect.....mechanical elements.
We also have: velocity loop controllers, processors, sensors. ..imperfect electrical elements.
IOW, we have probabilities of cause and effect. Will 1 degree of shaft cause "k" mm's of follower lift.
Prehaps a more workable definition of a "hard real-time, deterministism" follows more along the lines of acceptable levels or defined min/max levels of probability of an input event producing an associated output event, which falls within a probabilistic acceptability envelope.

FWIW
Dan Miller
Electrician
Allison Transmission

By Christopher Griffin on 10 December, 1999 - 4:53 pm

(Originally posted Wed 08/05/1998)
Correct me if I'm wrong, but the permissible time should be greater than the actual time taken, so your f
should multiply Tmaxp, rather than Tmaxd .

Also, throughput will always be true if timeliness is true, so the condition on throughput is not
necessary.

By Armin Steinhoff on 7 December, 1999 - 2:17 pm

(Originally posted Thu 07/30/1998)
Hi Simon,

At 17:03 10.07.98 -0400, you wrote:
>Hi Armin,
>
>Back again. Am I a sucker for punisment or what???

I don't have any idea why do you get this impression ? (Should I
use the '?' and '! ' more decent ?)

>The whole gist of my previous mail was supposed to be that real-time
>has no meaning in general terms, only in specific instances.

I don't agree ... 'real-time' systems are denoted in general as systems
which react to events of the real world and which response immediately
to the real world. In this sense are e.g. all online systems real-time
systems.

<snip>

>If we are going to use limits to differentiate between real-time and
>non real-time then these limits must be applicable WHATEVER
>CHARACTERISTICS OF ANY GIVEN SYSTEM.

I used these limits in order to differentiate between HARD and SOFT
real-time systems ... and doesn't use it to differentiate between
real-time and non real-time systems.

The other point is the definition of system ... 'system' means for me
in this context 'RT operating systems'.

>Given the number of different possible characteristics,
>then the only way I can see using limits is by defining them as some
>function of these characteristics. What characteristics do you use
>to set the limits and how do you define the functions?

Simple ... take a motion control application as a typical hard
real-time application and check out what attributes must have a
typical real-time OS to handle this type of application.

>That is a different subject which we could elaborate on, if anyone
>wants to...
(I do)

Yes ... it would be interesting to work out some points.

<snip>
>> > e.g. if I destine a processor, microcontroller, ASIC, FPGA,
>> >abacus, pocket calculator, etc. (depending on the selected
>> >technology) to handle each event, I do not require multiple
>> >interrupt levels, I do not even need interrupts,
>>
>> Interesting theory ... how do you control the different polling loops ??
>> How would you assign the CPU to the polling loops ???
>
>How about power-on. Initialise master processor. Initialise environment
>for each subsidiary processor. Release subsidiarty processors. Done.

Yes, you can spend for each polling process a CPU=A0 or a pure solution
in silicon (ASIC, FPGA)=A0 ... but what about the event notification
between the processes ?

An ASIC on a fieldbus controller board can interrupt the on board
micro processor ... which can interrupt the hosting PC processor ...
that's a typical design.

>> > as I can run a polling system, which if it handles all
>> >events "predictably given the systems time constraints" then
>> >what's the problem?
>>
>> Yes ... it works just for a specific class of application. But what
>> happens when the whole polling process takes 20ms ... and you have to
>> respond predictably in the time range of 50 us ... to meet
>> the deadline of the processing of an external event e.g. in the
>> time range of 1ms ???
>
>You said that interrupts are a requirement for a system to be considered
>real-time.

The problem is here the usage of the term 'system' .
I said interrupt processing is neccessary for all real-time 'operating
systems'!

>You agree some systems do not require interrupts to be considered
>real-time. These two statements are mutually inconsistent. All I
>tried to show is that to imply interrupt handling as a requirement
>for real-time processing is incorrect, and therefore should *not* be
>a part of a the definition of a real-time system.

Yes ... this is correct when we talk about real-time systems in common.
(At least when we use the definition of 'real-time system' used above ..)

[ clip ..]

>> I talked about ATTRIBUTES of 'real-time' computer systems based on the
>> existing technology ... so there is a clear meaning.
>
>You have only specified HALF of the system with this. The computer system.

Yes, this was my intention ...

>All this system must do is react to the stimulii from the external
>system within a given set of time constraints (deadlines). You must
>specify the stimulii and the deadline ATTRIBUTES as well, in order
>to have any meaning.

I don't talk about the physical meaning of deadlines for applications.

>If we use your definition of SOFT REAL-TIME as the basis of a
>hypothetical tungsten filament lighting control system, you have
>overkill by a factor of several 1000. It would be like killing a
>mouse with a missile, it'd kill the mouse but isn't there an
>easier/cheaper/more efficient way of achieving the same result
>without losing any apparent functionality or flexibility.

Yes, it's possible that some of my criteria are too hard ... there are
always a subject for discussion and it depends on the state of the
art of operating systems and computer technology.

>> > If a general purpose quantitative measure is required then it
>> >should be something along the lines of:
>> >
>> >REAL-TIME System:
>> >A system that is guaranteed to handle all events within the time
>> >constraints dictated by the physical system with which it is connected.
>>
>> Good general definition .... as long as "time constrains" means "meeting
>> of all deadlines" .

[ clip ..]

>My first big difficulty. If you are suggesting that not meeting
>deadlines is real-time as long as you have predictable worst cases,
>I hope you're never involved in the design/construction of life
>threatening machinery (i.e. anything with moving parts).

I hope you never use exclusively 'polling loops' for these types of
applications :-)

The required precision of meeting of deadlines defines the type of the
real-time application and of cause the type of the applicable RTOS. It
would be very dangerous to choose the wrong RTOS for a 'life
threatening machinery' (i.e.anything with moving parts).

[ clip ..]
>
>In my opinion, not meeting deadlines must be considered a fatal fault.

'Meeting a deadline' means for me: reaching at a defined time a physical or
logical value with a defined precision and time resolution.

The precision / variation depends on the time resolution used in the
'control' system ... an this is clearly a technologically attribute.

[ clip ..]

>
>HARD REAL-TIME:
> Maximum time to handle a given event <= 10% physical system's
> maximum

I don't believe that this works ... if I understand you right.
Each event has its own time constraints and the tolerated variation
in meeting the deadline is related to the individual constrains.

> Total event handling capacity >= 10 times the physical system's
> maximum

I don't understand this ....

>SOFT REAL-TIME:
> Maximum time to handle a given event <= physical system's
> maximum

That's too soft :-)

> Total event handling capacity >= physical system's maximum

What does it mean ?

Regards

Armin Steinhoff
STEINHOFF Automations & Feldbus-Systeme
http://www.steinhoff.de
http://www.DACHS.net

(Originally posted Thu 07/16/1998)
Undergo a little paradigm shift...
the RT stuff is available under Windows95 and NT, however it is used
a little bit differently than it was under, say, RT11.

Under RT11 I may have written a shift report program to be scheduled
and executed by the OS. Under Windows I would have the shift report
program contain a dialog box to allow a user to conveniently
setup the reporting times, and use a high-level encapsulation of the
clock ( a CTime object ) to implement the schedule. This program
could run minimized and contain a RT thread which looks at the clock
say once per second or minute as required. I suppose you can say
that this is more complex than in the RT11 case, but I am taking
about is less that 10 C statements (not including the report, just
the code to have it happen at the end of shift) and is IMHO a
small price to pay for the GUI interface.
BTW the dialog would be generated code, and addition to the 10 lines
I estimated.

As well, on the past on the list someone referred to the to
PRIORITY_TIME_CRITICAL in a Windows app to be a joke... it seems
to work to me. Do this experiment, code an infinite loop in a
program at this priority level and watch the response to user
events disappear as the processor resource is consumed by the loop.

I use Windows NT and 95 to interface to imaging instrumentation and
provide real-time analytical results to PLCs in machine control
applications with good success.

Bill Code
MPM Engineering Ltd.
4-6240 202nd St., Langley, B.C., Canada, V2Y-1N2

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

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

If you are talking about multi-tasking operating systems, anyway.
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.

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

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

By Mike Granby on 22 November, 1999 - 4:24 pm

(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
Paradigm Controls Limited
http://www.paracon.demon.co.uk

By Armin Steinhoff on 2 December, 1999 - 11:24 am

(Originally posted Thu 07/09/1998)
At 18:34 06.07.98 +0100, Mike Granby wrote:
>[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.

Yes ... semaphores are neccessary for the management of shared resources in
a real-time system, because the usage of a shared resource is event driven.

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

Yes ...the existence of semaphores doesn't mean that there are shared
resources which are requested by real-time events.

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

IMHO ... RTOS means an OS that can handle most physical time
constrains of any application.

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

Each technology has its marketing :-)

Armin Steinhoff

http://www.DACHS.net

By Vladimir E. Zyubin on 19 November, 1999 - 3:20 pm

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

Vladimir E. Zyubin

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

By David Wooden on 19 November, 1999 - 11:26 am

(Originally posted Thu 07/02/1998)
john-fridye@HLP.COM 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

By Vladimir E. Zyubin on 23 November, 1999 - 9:18 am

(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,
Vladimir E. Zyubin
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")

By Michael Griffin on 19 November, 1999 - 10:32 am

(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."
Vladimir E. Zyubin replied:
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
London, Ont. Canada

By Vladimir E. Zyubin on 23 November, 1999 - 11:09 am

(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
control systems. If so, please look at bellow arguments (about
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,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

By Michael Griffin on 23 November, 1999 - 11:15 am

(Originally posted Tue 07/07/1998)
Vladimir E. Zyubin wrote:
<clip>
>At Thu, 2 Jul 1998 00:42:29 -0400, Michael Griffin wrote:
>>For example, consider the following two systems:
>> A) A pneumatically operated pick-and-place.
>> B) A robot driven by electric servo drives.
<clip>
Someone earlier wrote:
>> >Control of the dam gates on a slow moving river may require a
>> >response time no faster than an hour;
<clip>
Vladimir E. Zyubin wrote:
> (?) 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).

No, I believe that the example of the dam gates is a real time
system, while the pick-and-place is not. The gates are being used to control
the river level in real time. The fact that the response time is very slow
does not affect this fact. If the response from the gates does not meet the
necessary timing criteria, the river level is not controlled. This is
because the river will continue flowing whether the gate control system is
ready for it or not. In this case a late response is just as bad as no
response at all. This is what makes it a real time system.
In the example of the pneumatic pick-and-place, the P&P will sit
there until the control system initiates the next step in the movement
sequence. Control of the P&P does not depend upon meeting certain timing
schedules. Slow or erratic timing of the control will not affect whether the
pick-and-place is able to perform the correct motions. It will only affect
the process cycle time, which is another issue altogether. This is why this
is not a real time system.

>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 :-).
<clip>
We should not confuse the profitability of a production process
(which depends upon many things) with whether or not it is a real time
system. Several people have mentioned economic issues and I wish to state
that this is very much a red herring as far as whether or not something is a
real time system.

To add another twist to this discussion, if I were to use a computer
which had a "real time operating system" (e.g. QNX), and wrote software to
control the above mentioned pick-and-place, this does not suddenly make the
P&P a real time system. An RTOS is something which *may* be used as part of
a control for a real time system, but the mere presense of an RTOS (and
appropriate control software) does not automatically make the system it is
controlling a real time system.

Michael Griffin
London, Ont. Canada

By Vladimir E. Zyubin on 2 December, 1999 - 3:21 pm

(Originally posted Tue 07/14/1998)
Dear All,

Dear Mr. Griffin, I was out of the office, so, sorry for the
response time... :-)
Er... Dear Mr. Carr, I am awfully sorry for my absolutely
incorrect response on your message :-( I hope the error was
obvious... as well as grammatical ones :-)

On Tue, 7 Jul 1998, Michael Griffin wrote:
> Vladimir E. Zyubin wrote:
> > (?) 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).
>
> No, I believe that the example of the dam gates is a real time
> system, while the pick-and-place is not. The gates are being used to
> control
> the river level in real time. The fact that the response time is very slow
> does not affect this fact. If the response from the gates does not meet the
> necessary timing criteria, the river level is not controlled. This is
> because the river will continue flowing whether the gate control system is
> ready for it or not. In this case a late response is just as bad as no
> response at all. This is what makes it a real time system.

Alas, I can not agree with the statement that in the case
of the dam gates a late response as bad as no response at all:
To be less abstract, let's imagine that there are fields
of Indian corn around the gates... (I assume that in our case a
late response means an increase of flood area) So, I think it is
obvious that any response (after acceptable one) will be more
desirable than no response at all. I.e., an increase of the
response time means only more large "dead" zone around the dam.
And the faster response the better. If so, I think there are the
following versions for the example:
1. Control system of the dam gates is a "bad" example to
prove your viewpoint (i.e., control of the dam gates is not
"real-time" by your definition; and you could not negotiate with
Mr. Shields (the author of the example)).
2. It is impossible to give a constructive definition of
the words "real-time system" (that, as I feel, is very close to
"digital control system" in the case).
Oh, yes, or, perhaps, a control system of dam gates
can be either "real-time" or "non-real-time" :-)

> In the example of the pneumatic pick-and-place, the P&P will sit
> there until the control system initiates the next step in the movement
> sequence. Control of the P&P does not depend upon meeting certain timing
> schedules. Slow or erratic timing of the control will not affect whether
> the
> pick-and-place is able to perform the correct motions. It will only affect
> the process cycle time, which is another issue altogether. This is why this
> is not a real time system.

Let's make the imaginary experience:
Let's insert a delay (e.g., 10 minutes) within the
control loop... I think it will mean a disaster for the
"experimentalist" -- disaster or irreparable consequence that,
as I sometimes feel, is frequently associated with the words
"real-time"... So, the consequence will be typically "real-time":
either the experimenter will lose his job or his company
will lose the customer... :-)
Sorry, jokes apart... I see only one objective (human
independent) difference between these control systems: the form
of dependency of lost money from time -- M(t). In the case of the
dam gates it is, obviously, non-linear function. In the case of
the pneumatic pick-and-place it looks like a linear function (but
indeed non-linear as well).

> >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 :-).
> <clip>
> We should not confuse the profitability of a production process
> (which depends upon many things) with whether or not it is a real time
> system. Several people have mentioned economic issues and I wish to state
> that this is very much a red herring as far as whether or not something is
> a
> real time system.

It seems to me that a concrete time of acceptable
latency exists for any control system. I.e., there is no control
system the customers of which agree with infinite response
time. But, I think you statement is absolutely correct: the
causes for it can have not only economic ground, they may,
e.g., be based on questions of safety, ecology, ergonomics, etc.
that can not be easily reduced to an economic one. How much is
an human life? How much is clean air? and so on...

> To add another twist to this discussion, if I were to use a
> computer
> which had a "real time operating system" (e.g. QNX), and wrote software to
> control the above mentioned pick-and-place, this does not suddenly make the
> P&P a real time system. An RTOS is something which *may* be used as part of
> a control for a real time system, but the mere presense of an RTOS (and
> appropriate control software) does not automatically make the system it is
> controlling a real time system.

In my opinion, if we distinguish "operating system"
and "control system" then we ought to realize that these things
are weakly-connected (at least).
Question: Is there anybody who met in literature an
analog control system that was called "real time"?

Best Regards,

Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

By A. V. Pawlowski on 19 November, 1999 - 11:29 am

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

By Vladimir E. Zyubin on 22 November, 1999 - 4:44 pm

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

At Mon, 29 Jun 1998 18:02:48 EDT, RufusVS@AOL.COM 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
time system must meet its deadlines whether those deadlines
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.<

Please, read the statement through carefully:
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,
Vladimir E. Zyubin
Institute of Automation & Electrometry
Novosibirsk Russia

By Antoine PERRIN on 18 November, 1999 - 3:39 pm

(Originally posted Fri 06/26/1998)
Dear group,
Perhaps, the solution to the problem of "real-time" should be solved by using an other vocabulary. Recently, I read a book where the authors make the distinction between:
• closed system i.e a system that only interract with the user and is not influenced by external physical constraints (these constraints can be time considerations). Of course, from this point of view, the human operator is a very tolerant physical system ;
• open system i.e a system that must take in account the constraints of an external physical system on which it operate.

Antoine PERRIN

By Simon Martin on 23 November, 1999 - 9:20 am

(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

(Originally posted Wed 05/27/1998)
I ask the same question as Mike, I think all operating systems require sections of non-interruptable code. Operating systems have this feature in order to guarantee atomic access to critical data structures. The designers of the operating system will have paid close attention to keeping the non-interruptable sections very short, i.e. a few machine instructions.
Bill Code
MPM Engineering Ltd.
4-6240 202nd St., Langley, B.C., Canada, V2Y-1N2

By Shields, Lester R on 18 November, 1999 - 10:33 am

(Originally posted Thu 05/28/1998)
Interrupt Service Routines (ISRs) usually contain short blocks of non-interruptible code. In fact, interrupts are usually disabled during the processing of parts of the ISR. Depending on the computer architecture, the disabling of interrupts may be done by the hardware or may be left to the ISR. In either case, the ISR must reenable interrupts after a few instructions. Usually, the architects of the OS will specify the maximum time that interrupts may be disabled. For example, I believe DEC specs said that in RSX-11M, an ISR could only leave interrupts disabled for 100 microseconds.
Sections of the OS requiring atomic access to data structures can usually be handled by single-threading such sections of the OS and queuing access to these data structures. Since these structures are (or should be) only accessed through these single-threaded code sections, this code can be interrupted. In this case, the ISR is not permitted access to kernel data structures except through the queued requests.
Or at least that's how I think I remember it!
Les

(Originally posted Thu 05/28/1998)
Perhaps I should have indicated that my question was rhetorical-I agree with what you're saying about OS structure, although I would say than from my experience it is not always possible to rely on critical sections and other mutex devices within kernel code, and that in some circumstances non-interruptability is the only option.

Mike Granby
Paradigm Controls Limited
http://www.paracon.demon.co.uk

By Armin Steinhoff on 18 November, 1999 - 10:03 am

(Originally posted 05/27/1998)
Yes ...this is in general true. But most important is the handling of the DPCs ...

Armin Steinhoff
http://www.DACHS.net

By Vladimir E. Zyubin on 18 November, 1999 - 10:11 am

(Originally posted Thu 05/28/1998)
Dear Antoin,
It seams to me, Windows NT is a typical hard real time OS ;-) And your goal is just to decrease 'maximal response time'/ to increase 'maximal possible frequency of the events'.
Good luck,

Vladimir E. Zyubin
mailto:zyubin@iae.nsk.su
Institute of Automation & Electrometry
Novosibirsk Russia

Any control system is 'hard real time'... by definition.

By Bill Hullsiek on 7 January, 2000 - 4:43 pm

(Originally posted Fri 07/10/1998) The comments on RTOS are all very interesting. Many of these concepts are described in the POSIX standards.
"Soft Real-time" was described in what was known as POSIX.4 standard along with some disputed definitions in this forum. The standard
identifies application interface issues for people coming from a UN*X programming
environment. It describes the services required from an operating system, along with behavior. Service include semaphores, timers, etc. If memory serves me correctly, the standard allowed for a maximum 20 ms response time. This allows allow of companies to claim POSIX compliance. The granularity of the timer service was down
to the nano-second level. The standard may be flawed and not good enough for hard real-time. Last time I looked into this administrativia, the IEEE had a committee working on the issues.

I threw away all my POSIX stuff and I am correctly pursuing the dark-side of the force.
(Translation: working on my Microsoft certification and pursuing MES issues). It will be interesting to see what Microsoft will do with CE, and NT-Lite. (NT kernel for embedded systems). For the time being, I would place my
money on QNX-4 or WindRiver.

Bill Hullsiek
Phone: 612.430.7337
Office Hours: 6:45 to 4:30 PM CT
whullsiek@andersencorp.com

By Anonymous on 17 July, 2007 - 9:20 pm

The CS field of computability defines Real Time (or Constant Time) using the following formal definiton:
RT={M|Exists(K)All(C)[STP(C,M,K)]
In other words, a Turing machine M is in the set Real-Time if there exists some limit K such that for all input tape configurations C the TM will have halted on that input by K steps.
Every "procedure" has an equivalent TM. Every "input" can be represented by some configuration C. So if a "procedure" will halt for every "input" by some predefined number of steps K, then it is considered to belong to the set of Real-Time.
For those wondering, the set RT is actually RE because the configurations are bounded by K.