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

A

Armin Steinhoff

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

Jonathan Lyall

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

Simon Martin

(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:[email protected]
 
V

Vladimir E. Zyubin

(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
 
(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 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: [email protected] WWW: http://WWW.MPM-ENG.COM/
 
V

Vladimir E. Zyubin

(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:[email protected]
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)
 
S

Simon Martin

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

Armin Steinhoff

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

E. Douglas Jensen

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

Vladimir E. Zyubin

(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
 
S
(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
 
C

Christopher Griffin

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

Armin Steinhoff

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

Vladimir E. Zyubin

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

Armin Steinhoff

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

Bill Hullsiek

(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
[email protected]
 
V

Vladimir E. Zyubin

(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:[email protected]
Institute of Automation & Electrometry
Novosibirsk Russia
 
A

Armin Steinhoff

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