Hi, I am doing my project "Internet bases control of real-time system". Currently it's somewhat working. The project is done is Java (to make it cross platform). Java seems a bit slow, so it's not really working real-time. I can clearly see a delay even when working on local LAN. Basically there are 3 sections. One client side from where devices are connected (using DAC), one server side (all data are sent from all clients to this server) and the web applet from where you can view each client data. From the web applet you can see status, change status, start-stop machine. Currently we are using a motor as test client but this can be changed to accommodate other things. Now I want to know is this actually a feasible project? IS there any potential for this kind of project? What can I do to improve it? Maybe I can later incorporate JINI to it? How can I make it close to real time? Is that at all possible in Java?

Thanks

 

You must first define what you want to control and what response time is absolutely required to control it. If your internet control system can
*always* meet the time requirement then it is real time. "Real time" is always relative to the process being controlled.

 

You have lots of questions and not too much information.

Here's the quick overview of the state of real-time Java. The Java community process has produced a real-time Java specification and you can read it at:

"www.jcp.org/jsr/detail/1.jsp":http://www.jcp.org/jsr/detail/1.jsp

The primary issue is garbage collection. None-real-time garbage collection usually runs at a high priority and so will cause the application to pause, typically for some milliseconds to garbage collect.

There are some real-time Java implementation which have determinism in the micro-second range. I expect to see more of these. Perhaps of interest to the PuffinPLC people, there's some discussion of linking real-time Java with RTLinux - could be a very interesting mix. Feel free to contact me if you'd like more info on any of these.

None of that seems to be your situation since you seem to be interested in "real-time" across a network. While we haven't found Java to be slow in these situation - we've moved 3000+ round-trip (SECS) messages per second on a 200Mhz class embedded machine - that's not the same as saying it's real-time. Clearly, and regardless of the language, you need to optimize the code for performance. There are many possible optimizations which depend on the applications. For example, if you want to move many small packages then the TCP_NODELAY flag will help with this, but hinder in other situations.

This will still not get you real-time. There are many other network considerations that have been considered here before (network topology, hubs vs. switches, etc. etc. etc.) With the correct topology you can get close. If you want to go true, real-time then there are options but many other things to consider (UDP, real-time networking stack, etc. etc.) and that's a different and more complex story.

Jim Redman
[email protected]
http://www.ergotech.com

 

I beg to differ.

Real-time is not the same as real fast.

Real-time is about satisfying completion time constraints (deadlines are the most common example) according to some objective function such as meeting all hard deadlines (this is what "hard real-time" means), or minimizing the number of missed deadlines, or minimizing the mean tardiness. These latter two are common examples of "soft real-time" in the technical sense as opposed to the popular misconception that "soft real-time" means "que sera sera").

The keystone property of a real-time system is predictability of timeliness. Predictability is a continuum, from determinism (absolute predictability) at one end, to total non-determinism (measured in terms of entropy, or coefficient of variation, etc.). Consequently, real-time systems are not necessarily deterministic -- that is not only a special case but a relatively unusual special case that is difficult to achieve in general and fortunately not commonly required.

The completion time constraints for real-time actions
may be microseconds to megaseconds.

Real-time resource management (i.e., driven by the
action time constraints) is usually needed whenever the action execution durations and completion time constraints leave so little slack time that arbitrary sequencing of the actions would result in unacceptable performance with respect to the sequencing objective function (e.g., too many missed deadlines, too large a mean tardiness, etc.).

Traditional real-time practitioners tend to think that real-time computing is confined to static device-level monitoring and control. This is not true. In the application domain where I work (military combat platforms, battle management, command and control), there are a great many mission-critical and safety-critical real-time control actions in which the time constraints (often deadlines) range from a second to 10's of seconds to an hour. When an AWACS and a UAV and a surveillance satellite and an intelligence satellite are all collaborating to perform machine-to-machine closed loop control to put an F-16's missile on a fleeting target, it is a life and death situation (for both adversaries),
and yet the time frames involved are seconds and minutes not microseconds and milliseconds. Note that this type of real-time system is highly dynamic, not static as most low level real-time subsystems are. Resource management must be real-time -- meaning based on using action time constraints and satisfying the sequencing objective function -- for the system's behavior to be dependably timely.

Note that the notional application example above is a distributed real-time system. The raison d'etre of any distributed real-time system is to provide acceptable predictability of end-to-end timeliness. Thus, there are closed loop control functions that are spread across the nodes of the distributed system. In the example above, there are closed loop control functions involving all of the war-fighting platforms in space, the air, and on the ground -- such a loop may be on the order of 4 Hz. The issue of speed in the throughput sense is application specific and not integral to the fundamental concept of distributed real-time.

The presence of one or more networks in these control loops adds resource management complexity. There are two cases: the network can be scheduled (this usually implies that it is a custom-built special-purpose one); or it can't (almost every extant network standard and product falls into this class). When the network can be scheduled, it should be scheduled consistently
with how other hardware (e.g., processors) and software (e.g., locks) are scheduled -- to wit, according to the objective function as discussed above. When the network cannot be scheduled, its properties (notably latencies) must be taken into account in the scheduling of all other resources. If the network latencies are well characterized (deterministically or stochastically), the system resource management can readily take them into account.

If the network latencies are sufficiently dynamic or unknown, the resource management approach is forced to do the best it can, regardless of the underlying network. In general, real-time CORBA (especially Real-Time CORBA 2/Dynamic Scheduling) and the Distributed Real-Time Specification for Java must presume that the underlying network is not under their control, and must therefore confine their resource management to those resources that are under their control -- namely their own middleware resources. Both RTC and DRTSJ offer facilities to the application programmers that enable RTC and DRTSJ to help manage processor and software resources consistently with the middleware resources. The predictability of end-to-end timeliness depends greatly on how effectively these resource management facilities are employed. (I was a principle contributor to both the Real-Time CORBA 1 and 2 specs.)

Changing the topic, please note that the phrase
"real-time Java" violates Sun Microsystem's trademark (as described in detail on their web site). And anyway, there are two formal specs that address real-time in the context of the Java platform: the Sun Java Community Process "Real-Time Specification for Java" and the J Consortium's "Real-Time Core Extensions." Only the former actually has been implemented and is available (for free and as products). See "www.rtj.org":http://www.rtj.org and "www.j-consortium.org":http://www.j-consortium.org . There are some "real-time Java"-like products that do not conform to either spec. (I was a contributor to the RTSJ and am the leader of the DRTSJ team; I am also a member of the J Consortium.)

Garbage collection is certainly a critical issue but by no means is it the only critical one.

The "Distributed Real-Time Specification for Java"
is still being developed, and should be available as both a spec and a reference implementation about the end of this year. See "www.drtsj.org":http://www.drtsj.org .

For more on this whole topic, see my web site "www.real-time.org ":http://www.real-time.org (especially the preview of my new web site there). Feel free to send me email or call if you wish to discuss this topic.

Doug
--
E. Douglas Jensen
[email protected], http://www.real-time.org
Home voice 508-653-5653, home fax 508-653-3342
Cell phone: voice 508-728-0809
text http://www.bam.com/send2.htm
http://www.msg.myVZw.com

 

[snip]
> Note that the notional application example above is a distributed real-time system. The raison d'etre of any distributed real-time system is to provide acceptable predictability of end-to-end timeliness. Thus, there are closed loop control functions that are spread across the nodes of the distributed system. In the example above, there are closed loop control functions involving all of the war-fighting platforms in space, the air, and on the ground -- such a loop may be on the order of 4 Hz.
[snip]


Oops, I meant to say:
seconds (.25 Hz)
Sorry...

Doug
--
E. Douglas Jensen (at home)
[email protected], http://www.real-time.org
Home voice 508-653-5653, home fax 508-653-3342
Cell phone: voice 508-728-0809
text http://www.bam.com/send2.htm
http://www.msg.myVZw.com
[email protected]
Car phone: voice 508-395-6547
Office voice 781-271-2514, office Fax 781-271-4686

 

Standard IEEE 100-1992 "Definitions... " would definitely reduce the "bickering" over this thread as well as others. At least it (the
Standard) would serve as the baseline for professional discussion. The latter, I believe, is a basic tenet of the List!

Flame away!

Regards,
Phil Corso, PE
(Boca Raton, FL)

 

Hello List,

The term "Real-time" does not bring any valuable info to be use from technical point of view... or at least to be used as frequently as we have
misfortune to observe... IMO. Historically, the term was introduced by the marketologists (in order to mark out the goods... the softwares... for more info on the ad-methods see the theory of advertisment)

There is no such a thing as TIME for computer. There is a timer in the computer. The timer is an ordinary event-generator, as well as IOs.

>From this point of view the "time problem" for digital control systems can be formulated as the following simple sentence: The faster - the better.

Thanks for your attention. Vladimir

BTW, any control system has time constrant requirements (those can be reflected in the spec or can not be). From this point of view the phrase
"realtime control system" is a tautology.

:-x

 

>Hello List,
>The term "Real-time" does not bring any valuable info to be use from
>technical point of view... or at least to be used as frequently as we
>have misfortune to observe... IMO.

This might be true for the popular usage of the term "real-time" in the field of industrial automation, but it certainly is not at all true: in general, and for the actual technical usage of the term, and for the usage of the term in military systems where precise and accurate concepts and terms translate into life or death.

>Historically, the term was introduced by the marketologists (in order
>to mark out the goods... the softwares... for more info on the
>ad-methods see the theory of advertisment)

Your history is inaccurate. MITRE, a spin-out from MIT 40 years ago to design the SAGE system, used the term "real-time" to correctly characterize some of the behavior of the system. They might not have been the first, and they certainly were not the only, and have not been the last, to use the term in a technical sense.

Unfortunately it is correct to observe that practitioners -- users, not
just vendors -- routinely misuse the term (sometimes, as you say, for marketing purposes, not simply due to ignorance).

>There is no such a thing as TIME for computer. There is a timer in the
>computer. The timer is an ordinary event-generator, as well as IOs.

This is too large a topic for me to respond to here. Your comment is at least confusing if not wrong.

>From this point of view the "time problem" for
>digital control systems can be formulated as the
> following simple sentence: The faster - the better.

Incorrect. I can give you plenty of counter-examples where faster doesn't help, and even where faster is worse.


>BTW, any control system has time constrant requirements (those can be
>reflected in the spec or can not be). From this point of view the
>phrase "realtime control system" is a tautology.

How nice to see you say something I agree with.

Doug

 

Interestingly enough, you will find that a number of IEEE standards, notably the POSIX real-time one, not to mention the CORBA and many other standards, recognize that the IEEE 100-1992 definition of real-time is unsuitable. It was not written by real-time experts.

Doug
--
E. Douglas Jensen (traveling)
[email protected], http://www.real-time.org
Home voice 508-653-5653, home fax 508-653-3342
Cell phone: voice 508-728-0809
text http://www.bam.com/send2.htm
http://www.msg.myVZw.com
[email protected]
Pager 888-916-9802 and http://www.skytel.com/paging (PIN 8889169802)
Office voice 781-271-2514
office Fax 781-271-4686

 

> Interestingly enough, you will find that a number of IEEE standards, notably the POSIX real-time one, not to mention the CORBA and many other standards, recognize that the IEEE 100-1992 definition of real-time is unsuitable. It was not written by real-time experts. <

It is just violation of the identity principle.
(the requirements that any correct term shell not allow double meanings).
The identity principle is one of the base methodology principles of science and logic.

If the principle is violated, the term can not bring valuable information... but it is quite acceptable for manipulation, zombification.

--
Best regards,
Vladimir mailto:[email protected]

 

Hello List,

E. Douglas Jensen wrote:

LM> This might be true for the popular usage of the term "real-time" in the
LM> field of industrial automation, but it certainly is not at all true: in
LM> general, and for the actual technical usage of the term, and for the usage
LM> of the term in military systems where precise and accurate concepts and
LM> terms translate into life or death.

Just provide a short and clear definition of the term. What I heard before is too verbose and too obscurely to be named "a definition". Sorry.
...or it looks like just lirics... "life or dead".... "to be or not to be". Specification is a very clear thing, there should not be the words
"real time" at all... Which way the performer will prove this strange requirement? Where is "realtime-meter"?

E.g., "response time" is an accurate technical term because can be expressed in the digits, seconds, hours, minits. Sorry, "real time" is not a term at all.

>>Historically, the term was introduced by the marketologists (in order to
>>mark out the goods... the softwares... for more info on the ad-methods
>>see the theory of advertisment)

LM> Your history is inaccurate. MITRE, a spin-out from MIT 40 years ago to
LM> design the SAGE system, used the term "real-time" to correctly characterize
LM> some of the behavior of the system. They might not have been the first, and
LM> they certainly were not the only, and have not been the last, to use the
LM> term in a technical sense.

I admit the author of the term is a scientists. Sometimes scientist try to introduce bad terms... Those are waiting for the Ockham (Occam) Razor
...e.g., because of the total misusing of the term. The term does not provide the identity principle.

Term (in addition to it short and clear definition) either must be expressed in digits or must have event nature and must have the antonym:
1. No one say, realtime is 10 sec, 2. there is no such a thing as "irreal time".

LM> Unfortunately it is correct to observe that practitioners -- users, not
LM> just vendors -- routinely misuse the term (sometimes, as you say, for
LM> marketing purposes, not simply due to ignorance).

99,(9)% of use. And users just read read the misleading articles... and repeat the sentences.

>>There is no such a thing as TIME for computer. There is a timer in the
>>computer. The timer is an ordinary event-generator, as well as IOs.

LM> This is too large a topic for me to respond to here. Your comment is at
LM> least confusing if not wrong.

It would be very interesting to hear out. ...in a short form if it is possible.

>>From this point of view the "time problem" for digital control systems
>>can be formulated as the following simple sentence:
>>The faster - the better.

LM> Incorrect. I can give you plenty of counter-examples where faster doesn't
LM> help, and even where faster is worse.

So called RT problems are strictly connected with the limit of processor power. There is no any problem if there is no this limit. So called RT
problems are problem of non-zero time of perfomance.

>>BTW, any control system has time constrant requirements (those can be
>>reflected in the spec or can not be). From this point of view the phrase
>>"realtime control system" is a tautology.

LM> How nice to see you say something I agree with.

I am sure there is a lot of things we both consider to be true...

--
Best regards,
Vladimir mailto:[email protected]

 

Vladimir E. Zyubin (on "real time"):
> Just provide a short and clear definition of the term. What I heard
> before is too verbose and too obscurely to be named "a definition".

A real-time control system is a control system which guarantees that response time constraints will be met.

Details:

- The guarantee can only really be evaluated at the end of
programming, when both the program and the constraints have
been input into the design system. At that stage, the design
system will evaluate whether the constraints can be met (and
probably assist in modifying the design, if necessary).

- The guarantee can either be absolute ("hard real-time") or
with some allowed deviation ("soft real-time"), eg percentage
of missed deadlines or mean/stdev tardiness.

Design systems and components can be classified based on the extent to which they facilitate and support design of real-time control systems.

> Term (in addition to it short and clear definition) either must be
> expressed in digits or must have event nature and must have the
> antonym: 1. No one say, realtime is 10 sec, 2. there is no such a
> thing as "irreal time".

The antonym is "non-real-time" - the system does not provide a guarantee that it will meet timing constraints (or a required percentage etc), even though in practice it may do so.

Most control systems in actual use are borderline non-real-time - the PLC or other control system was programmed and commissioned, but no formal analysis of its timeliness was done. Since PLCs are designed to have a uniform execution time, and timeliness appears sufficient during
commissioning, this is usually satisfactory, but it means that there's no indication of whether or not there is a margin of safety.


Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Hello Jiri,

On Wednesday, July 10, 2002, 7:57:51 AM, Jiri Baum wrote:

JB> Vladimir E. Zyubin (on "real time"):
>> Just provide a short and clear definition of the term. What I heard
>> before is too verbose and too obscurely to be named "a definition".

JB> A real-time control system is a control system which guarantees that
JB> response time constraints will be met.

Any control system shell meet the requirements (the specification). If there are words about time constraints among the requirements, the control shell meet it. Otherwise the system is not a control system, but rather it is a defective artefact. End of story.

BTW, I never see people saying "real time" about analog control systems, so, there should be words about digital control system in the definition.

JB> Details:

JB> - The guarantee can only really be evaluated at the end of
JB> programming, when both the program and the constraints have
JB> been input into the design system. At that stage, the design
JB> system will evaluate whether the constraints can be met (and
JB> probably assist in modifying the design, if necessary).

Heheh. You just state that there are no means to predict apriory the behaviour (response time) of control system. In practice. But in theory? I see no reasons why it is impossible.

BTW, your statement means that achievements of "RT science" have no predictable power (property to forecast the result). It is just a
descriptive science... kinda geography or zoology...

JB> - The guarantee can either be absolute ("hard real-time") or
JB> with some allowed deviation ("soft real-time"), eg percentage
JB> of missed deadlines or mean/stdev tardiness.

I am sorry. It is not convicing enough to me.
E.g., there is no such a thing as "absolute" in the digital world. We can open any book on microprocessor architecture and read about the interrupts and the latency time... there is no 0% deviation. So, according to the statement, HRT is a nonsense. Or kinda "abstract control system", just a theoretical model.

JB> Design systems and components can be classified based on the extent to
JB> which they facilitate and support design of real-time control systems.

See no way till I can tell RT from SRT, HRT from SRT, RTCS from just control system.

BTW, another underwater rock in the definition: all control systems have
time constraints that can be reflected in the spec or can be not
reflected in the spec.

>> Term (in addition to it short and clear definition) either must be
>> expressed in digits or must have event nature and must have the
>> antonym: 1. No one say, realtime is 10 sec, 2. there is no such a
>> thing as "irreal time".

JB> The antonym is "non-real-time" - the system does not provide a guarantee
JB> that it will meet timing constraints (or a required percentage etc),
JB> even though in practice it may do so.

Lyrics. But I like the word "required" in the sentense. Again, if system can not meet the requirements, it must be thrown out into the rubbish dump.

JB> Most control systems in actual use are borderline non-real-time - the
JB> PLC or other control system was programmed and commissioned, but no
JB> formal analysis of its timeliness was done. Since PLCs are designed to
JB> have a uniform execution time, and timeliness appears sufficient during
JB> commissioning, this is usually satisfactory, but it means that there's
JB> no indication of whether or not there is a margin of safety.

IMO, it would me more approach if everybody speak about the response time... It is clear term and it can be expressed with the digits... It is more preferable than the fog of "real-time" pseudo-science speculation.

And yes, we can speak about response time, but is it the main characteristic of the control system? What about MTBF, robastness, maintainability, logical errors, etc., etc., etc. ;-)

Can the time constraint of 1 hours +-1 min be an object of pride? IMO, it can be. As well as it can be an easy to fulfil. So what is the info the words "real time" brings to the listener? kind of "believe me, during the design I had a lot of
problem with time constraints and by chance the system meets the requirements"?

Our case is just a case of the positioning (an advertisement trick). So, the "term" should be eliminated from the professional dictionaries
and every use of the words should be object of ridicule... IMO.

--
Best regards,
Vladimir mailto:[email protected]

 

Vladimir E. Zyubin wrote:
>Hello List,
>
>On Monday, July 01, 2002, 8:03:21 PM, E. Douglas Jensen wrote:
>>>Hello List,
>>>The term "Real-time" does not bring any valuable info to be use from
>>>technical point of view... or at least to be used as frequently as we
>>>have misfortune to observe... IMO.
>
>LM> This might be true for the popular usage of the term "real-time" in
>LM> the field of industrial automation, but it certainly is not at all
>LM> true: in general, and for the actual technical usage of the term,
>LM> and for the usage of the term in military systems where precise and
>LM> accurate concepts and terms translate into life or death.
>
>Just provide a short and clear definition of the term. What I heard
>before is too verbose and too obscurely to be named "a definition".
>Sorry. ...or it looks like just lirics... "life or dead".... "to be or
>not to be". Specification is a very clear thing, there should not be
>the words "real time" at all... Which way the performer will prove this
>strange requirement? Where is "realtime-meter"?

There are a great many scientific and engineering concepts and terms are cannot be defined on a bumper sticker.

If you read my definitions, you see that in real-time computing, as in the general field of scheduling theory, the optimality criterion (or objective function) is specified by the system designer. The technically accurate definition of "hard real-time" involves an objective function that says "always meet all hard deadlines." The technically accurate definition of soft real-time involves all other objective functions; as I already pointed out in a prior message, very common examples include "minimize the number of missed deadlines," "minimize the mean tardiness," etc. These are very easily measured values on the "real-time meter." It is easier to separate the real-time meter into an objective function value meter, and a predictability meter, rather than combining them. These two meters for the hard real-time case are then "meet all hard deadlines" and "with probability=1." Obviously in all cases, these requirements are expressed subject to specified conditions on properties of the load, the system, and the execution environment.

[snip]

>Term (in addition to it short and clear definition) either must be
>expressed in digits or must have event nature and must have the
>antonym: 1. No one say, realtime is 10 sec, 2. there is no such a thing
>as "irreal time".

I look forward to your illustrating this amusing claim by giving us a short and clear definition of "gravity," and telling us what its antonym is.

Unfortunately, it is very common for real-time computing practitioners to pseudo-define "real-time" and "hard real-time" and "soft real-time" in terms of numbers -- such as "hard real-time means interrupt latency less than 10 uS."

The antonym to "real-time" is seen by observing that what is required is for the system to "operate in real-time" -- i.e., to provide acceptably predictable values of the objective function. This may be done by having sufficiently excess hardware resources, or by good luck, or by careful time-constraint based resource management. Hence, the antonym is that the system does NOT operate in real-time. If you choose to coin more amusing phrases, perhaps you would like to say it "operates in ir-real time."

>>>There is no such a thing as TIME for computer. There is a timer in
>>>the computer. The timer is an ordinary event-generator, as well as
>>>IOs.
>
>LM> This is too large a topic for me to respond to here. Your comment
>LM> is at least confusing if not wrong.
>
>It would be very interesting to hear out. ...in a short form if it is
>possible.

I would enjoy it -- I'll try to find the time to do so.

>>>From this point of view the "time problem" for digital control
>>>systems can be formulated as the following simple sentence: The
>>>faster - the better.
>
>LM> Incorrect. I can give you plenty of counter-examples where faster
>LM> doesn't help, and even where faster is worse.
>
>So called RT problems are strictly connected with the limit of
>processor power. There is no any problem if there is no this limit. So
>called RT problems are problem of non-zero time of perfomance.

This has already been formally proven to be an incorrect statement. You are encouraged to read the paper [Sha, Lehoczky] in which it is proved that even as processor speed increases to infinity, there are certain task sets with certain deadlines that cannot all be always met. Of course this is a special case, but it is an existence proof that shows your claim is incorrect in general. However, I agree with you in the sense that in most cases, the issue has to do with slack time -- essentially the difference between how much time the tasks require to execute, and the time left over, which is clearly affected by processor speed. One can have a system in which the tasks have hard deadlines of say 4 seconds, which seems relatively long -- but if the tasks require say 1 second each of execution time for the processor that is used, then almost certainly the resource management will need to take the deadlines into account, contrary to popular misconception that real-time = real-fast.

>>>BTW, any control system has time constrant requirements (those can be
>>>reflected in the spec or can not be). From this point of view the
>>>phrase "realtime control system" is a tautology.
>
>LM> How nice to see you say something I agree with.
>
>I am sure there is a lot of things we both consider to be true...

In another of your replies you claim that no one talks about real-time in the context of analog control systems. That is not true. In fact, I have heard control engineers talk about real-time in the context of analog control systems, and it makes perfect sense given my definitions. Moreover, I hear decision theory people talk about real-time in the context of human control systems, which are currently regarded as more analog than digital.

Doug
--
E. Douglas Jensen (at home)
http://www.real-time.org

 

Just stumbled accross this, thought I would put my two cents in.
Real time refers to a device that has a continual input, with no time lapse. the only lapse that occurs is that of transmition. Information recieved is processed on a continual basis. DCS systems are a good example. Look at it this way, if you have a pnuematic device (even though we are talking electrical) it will respond in real time, or 'as X happens there will be an immediate response by Y'. Now a normal PC on the other hand has time delay. This is not real time.

ward H

 

Well, Except that I have not yet seen a DCS system where there is anything like "immediate response" anywhere. A response within a limited time but not "immediate" in the signal traveling sense as you would have if you hardwired the electronics.

A DCS system is normally, however, a good example of a realtime system. The response time for any event is not more than the scan time. (At least not unless someone programmed it very badly - yes that is still possible).

In real life most control loops in a DCS system seems to have a scan time of about 0.5 to 2s. Those (relatively rare) loops requiering a faster scan time have that if the system is programmed properly.

Anyway, this is an old post, before anyone starts the usual flame wars I suggest you take a very deep look in the archives... It is quite boring to repeat the same stuff over and over again, and I guess it is quite boring to read too...

/Johan Bengtsson

 

ward H:
> Just stumbled accross this, thought I would put my two cents in.
> Real time refers to a device that has a continual input, with no time
> lapse. the only lapse that occurs is that of transmition.

That's a different meaning of "real-time" - the opposite would be
something like "historical data".

When one speaks of a real-time control system (or real-time operating
system), the meaning is that timing constraints can be specified and
guaranteed. The opposite would be something like "unbounded time".

Simply put, PLCs are real-time because there's a table in the back of
the manual which says "function X will take no more than Y time". This
means you can add up how long your program will take, and design
accordingly - and guarantee that the design is correct.

This is so obvious in automation that the term is almost meaningless -
of course everything has a timing constraint, and if you don't meet it,
you fail spec.

In other fields, it's not nearly so important: there is no real limit on
the amount of time a spreadsheet may take to calculate. General-purpose
computers and their programming languages are usually not real-time[1];
there isn't a timing table anywhere in the manual, and indeed many
common operations can take an arbitrary amount of time (without an upper
bound, unbounded). This can include simple things like "a := b+c" [2].

General-purpose computers can be made real-time, and thus useable in
automation, by the use of a special operating system (QNX, RTAI-Linux,
RTLinux) and by avoiding unbounded-time functions.

Jiri

[1] This includes VB on MS Windows; one can therefore conclude that VB
is not appropriate for control. This is not entirely fair - in many
cases the cost of the odd timing failure is less than the cost of proper
design - but should be borne in mind when selecting the environment.

The same remarks apply to Python on Linux: timing not guaranteed, but
often good enough in practice.

[2] If a, b and c are declared as integers with unbounded range, adding
two of them together can take an unbounded amount of time, even if you
restrict the range in practice.
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

 

Pretty good except for the phrase "no time lapse". All sampled (digital) systems will have a finite and variable "time lapse" for quantization or sampling uncertainty. Does this mean only analog systems can be real time? No.. Wait, analog systems still have a propagation delay. By this definition, nothing I'm aware of could be realtime. The definition must include a relation between system bandwidth and the delays and uncertainties. No visible delay is good enough in some cases. Microseconds are not good enough in others. And the predictability must be in line with the needs as well. It does take time for the pressure to propagate down the air line. :^)

It's just not a simple concept.

Regards

cww

 

People often confuse the term "real-time" with "fast". The definition I would offer for a "hard" real time system is that some of the system specifications have "hard" time constraints and failure to meet those time constraints implies the system will not function properly according to spec.

“real time” is not dependent whether the signal is continuous or not or even if it is fast relative to human perception.

Perhaps a few specific examples will do. These are example from the Honeywell DCS system (TPS, TDC 3000, APP Node, HM) that I worked on for 11 years.

1) The HM and other history collectors must operate in real-time in order to meet spec. The history must be collected within the time interval; or you get an overrun indication. The history retrieval, on the other hand IS NOT real time. Though you would like it to be as fast as possible, there is no hard spec that I am aware of
2) The data sampling for the analog Input and Outputs points is REAL TIME, since unless these are done within the time interval; the control algorithm calculations (e.g. PID) will be incorrect.
3) A control store is the highest priority action in the system and there is a real time constraint on how long between the time the store command is entered and the time the command is presented to the valve. Failure to process control commands in a timely manner can result in very serious problems and dangerous situations.

I do realize that people often refer to systems as “real-time” if something is fast relative to what they can perceive, but when you are analyzing or specifying a system the definitions need to be much more precise that what the user might perceive.

A few other examples: missile telemetry data and commands are real-time as are commands for An operator to turn a switch on a rail road line. Anti-lock brake commands from the on board computer to the brake mechanism. The commands to a Phalanx gun are real-time.

Chris Schene

 

1. any control system is real time by definition of "control system".

2. Ceterum censeo... There is no real definition for the term "real time", so the term must be eliminated from the professional vocabulary...

--
Best regards.
= Vladimir E. Zyubin mailto: zyubin @ iae.nsk.su