On September 24, 2003, Vladimir E. Zyubin wrote:
> 1. any control system is real time by definition of "control system".

Agreed. However, for instance a word processing system need not be real time (and usually isn't).

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

The real use of this term is in the bridging of the divide between the IT folks and the control folks: in the IT dept, practically nothing is real-time, while on the control side practically everything needs to be.

Neither side thus really understands the term - IT people because they don't need it, automation people because they've never met anything that wasn't. However, I suspect it's one of the major reasons why automation engineers cringe at the use of PCs in automation, without knowing why.

Putting a name on the reason helps explain it to others, and helps evaluate it rationally.

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

 

Hello automation,

On September 24, 2003, Vladimir E. Zyubin wrote:
>> 1. any control system is real time by definition of "control system". <

On September 25, Jiri Baum wrote:
> Agreed. However, for instance a word processing system need not be real aacc> time (and usually isn't). <

Which way we can discuss the problem if we do not have the definition. Also I can imagine how your definition looks like... it seems to me your definition will not include a number... just something about time constraints. So... Nobody will use a word-processing with the delay of a year. So, the systems have a time constraint, etc. Any system has a time constraint on response time. From the other hand if somebody put a digit in the definition, it is very easy to demonstrate that so called RT problem is a pure hardware problem.

>> 2. Ceterum censeo... There is no real definition for the term
>> "real time", so the term must be eliminated from the professional
>> vocabulary...
> The real use of this term is in the bridging of the divide between the
> IT folks and the control folks: in the IT dept, practically nothing is
> real-time, while on the control side practically everything needs to be.
>
> Neither side thus really understands the term - IT people because they
> don't need it, automation people because they've never met anything that
> wasn't. However, I suspect it's one of the major reasons why automation
> engineers cringe at the use of PCs in automation, without knowing why.
>
> Putting a name on the reason helps explain it to others, and helps
> evaluate it rationally. <

Agreed. "Real-time" is just emotional words, as well as "cool", "good", etc. And when I see the words in an article pretended to be a technical one, I understand that either the author is not clever enough or the author thinks I a moron. No need to say there are a lot of the articles... and products that use the words in their names.

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

 

On September 24, 2003, Vladimir E. Zyubin wrote:
> >> 1. any control system is real time by definition of "control
> >> system".

On September 25, 2003, Jiri Baum wrote:
> > Agreed. However, for instance a word processing system need not be
> > real time (and usually isn't).

On September 30, 2003, Vladimir E. Zyubin wrote:
> Which way we can discuss the problem if we do not have the definition.
> Also I can imagine how your definition looks like... it seems to me
> your definition will not include a number... just something about time
> constraints. So... Nobody will use a word-processing with the delay of
> a year. So, the systems have a time constraint, etc. <

Nevertheless, the time constraint is not nearly of the same sort as the time constraint on an industrial controller.

Perhaps more importantly, nobody bothered to calculate the maximum running time of the word processor, and it may in fact be arbitrary (most people hit the reset button after a few minutes/hours, anyway).

> Any system has a time constraint on response time. From the other hand
> if somebody put a digit in the definition, it is very easy to
> demonstrate that so called RT problem is a pure hardware problem. <

No, it is not. For instance, in most implementations the malloc(3) call takes arbitrary time. This doesn't stop its use in word processors, because the pathological performance is very very rare. It does prevent its use in control programs, regardless of what hardware you run it on.

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

> > The real use of this term is in the bridging of the divide between
> > the IT folks and the control folks: in the IT dept, practically
> > nothing is real-time, while on the control side practically
> > everything needs to be.

> > Neither side thus really understands the term - IT people because
> > they don't need it, automation people because they've never met
> > anything that wasn't. However, I suspect it's one of the major
> > reasons why automation engineers cringe at the use of PCs in
> > automation, without knowing why.

> > Putting a name on the reason helps explain it to others, and helps
> > evaluate it rationally.

> Agreed. "Real-time" is just emotional words, as well as "cool",
> "good", etc. <

No, it is an objective property. For instance, a PLC is real-time, because in the back of the manual there's table giving the maximum running times for every single function. Linux isn't, because its manual lacks this information (and in fact explicitly says things like "delayed by an arbitrary amount of time").

This makes it impossible to write a control system in plain Linux (or plain Windows) - arbitrary delays make for broken control. However, it's quite reasonable to write a word processor in Linux or Windows, since usually the delays are quite short.

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

 

While your statement might well be true for some control applications, its just plain silly to make the assertion widnows or linux cannot be used in all cases, since its being done on a regular basis, with generally acceptable results.

Arbitrary delays in many control systems are not that big of a deal, since it often is not important, as long as they are within some acceptable level, sometimes measured in minutes.

The key is to determine what level of arbitrary delays you can accept, and do what you can to see that the end result is within acceptable parameters.

If you have one 100 millisecond hickup once or twice a year because of the OS you chose, how is that any worse than a 2 hour hickup caused by a power supply failure every couple of years?

 

Once more unto the breach dear friends.

On October 21, 2003, Jiri Baum wrote:
<clip>
> No, it is an objective property. For instance, a PLC is real-time,
> because in the back of the manual there's table giving the maximum
> running times for every single function. <

However, there are still a number of factors which make it difficult or impossible to predict the response time of a PLC. The length of the execution path which the program will take in any individual scan will normally vary.
Communications events will often affect the scan rate. WIth some PLCs, connecting a programming computer will slow the scan rate significantly. Knowing the execution time of a PLC instruction is of no more assistance than
knowing the execution time of a microprocessor instruction in a computer. If you wish to define "real-time" as "completely predictable", a PLC is not "real-time". However, few industrial applications truely require real-time behaviour.

<clip>
> This makes it impossible to write a control system in plain Linux (or
> plain Windows) - arbitrary delays make for broken control.
<clip>

In most industrial applications arbitrary delays make for arbitrary delays, not "broken control". Your statement is too general. Stock Linux (or Windows) may function quite satisfactorily in most applications. The "arbitrary
delays" in newer versions of the Linux kernal are orders of magnitude smaller than the scan rate of a PLC (comparable information for Windows seems to be very difficult to find).

I believe that the term "real-time computing" originated as a means of distinguishing interactive systems from batch processing. In industrial applications, "real-time" simply indicates that response time must be considered as a particularly significant design factor.

--

************************
Michael Griffin
London, Ont. Canada
************************

 

On October 22, 2003, Bob Peterson wrote:
> While your statement might well be true for some control applications,
> its just plain silly to make the assertion widnows or linux cannot be
> used in all cases, since its being done on a regular basis, with
> generally acceptable results. <

OK, perhaps I did state it rather strongly; however, if professionals cringe at the use of VB in automation, I suspect this issue is a great part of that.

Of course, if it's just a monitoring system, or something where failure is an option, there's no problem.

> Arbitrary delays in many control systems are not that big of a deal,
> since it often is not important, as long as they are within some
> acceptable level, sometimes measured in minutes. <

If nothing else, many control systems will require response in the hundreds-of-ms range because otherwise buttons won't work.

> The key is to determine what level of arbitrary delays you can accept,
> and do what you can to see that the end result is within acceptable
> parameters. <

Yeah; and how do you know what level of arbitrary delays you're going to get from a Windows or Linux machine? (Some delays might get worse as time goes on - for instance, as disk fragmentation increases.)

> If you have one 100 millisecond hickup once or twice a year because of
> the OS you chose, how is that any worse than a 2 hour hickup caused by
> a power supply failure every couple of years? <

I guess it's not; having 100 ms hickups say once a day would probably be the worst - too rarely to see what's happening, too often to ignore it.

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

 

On October 23, 2003, Jiri Baum wrote:
> On October 22, 2003, Bob Peterson wrote:
> > While your statement might well be true for some control applications,
> > its just plain silly to make the assertion widnows or linux cannot be
> > used in all cases, since its being done on a regular basis, with
> > generally acceptable results. <
>
> OK, perhaps I did state it rather strongly; however, if professionals
> cringe at the use of VB in automation, I suspect this issue is a great
> part of that. <

VB is just totally unsuitable for any kind of realtime control. Its just too unpredictable, and has a nasty habit of hanging up. OTOH, something written in C or some other language might be quite acceptable.

> Of course, if it's just a monitoring system, or something where failure
> is an option, there's no problem.
>
> > Arbitrary delays in many control systems are not that big of a deal,
> > since it often is not important, as long as they are within some
> > acceptable level, sometimes measured in minutes. <
>
> If nothing else, many control systems will require response in the
> hundreds-of-ms range because otherwise buttons won't work. <

A lot of PLCs out there with scantimes in that range that work. Its a minor nuisance to the operator, but it does not amke it unusable. I have seen PLC programs with scan time of near 1/2 second that worked. I don't consider it ideal, but its not a big deal in a lot of cases.

> > The key is to determine what level of arbitrary delays you can accept,
> > and do what you can to see that the end result is within acceptable
> > parameters. <
>
> Yeah; and how do you know what level of arbitrary delays you're going to
> get from a Windows or Linux machine? (Some delays might get worse as
> time goes on - for instance, as disk fragmentation increases.) <

Disk fragmentation is a major issue with any windows machine. however, there are techniques and/or software that can eliminate this problem. A worse problem with windows is continual updates. But, if not connected to the outside world this is not really an issue either.

 

On October 23, 2003, Jiri Baum wrote:
<clip>
> OK, perhaps I did state it rather strongly; however, if professionals
> cringe at the use of VB in automation, I suspect this issue is a great
> part of that.
<clip>

Professionals cringe at the use of VB for anything. The reasons for this however have nothing to do with PCs or operating systems.

> > The key is to determine what level of arbitrary delays you can accept,
> > and do what you can to see that the end result is within acceptable
> > parameters. <
>
> Yeah; and how do you know what level of arbitrary delays you're going to
> get from a Windows or Linux machine? (Some delays might get worse as
> time goes on - for instance, as disk fragmentation increases.)
<clip>

Yet, somehow this doesn't really seem to be the sort of problem which we see from day to day. Most automation tasks don't require real time performance. Those that do (e.g. waveform generation or acquisition) are often offloaded to specialist hardware (e.g. data acquisition boards). There are genuine applications for real time operating systems (e.g. QNX), but these are a minority.

--

************************
Michael Griffin
London, Ont. Canada
************************

 

Jiri has this right. For an excellent description of real-time, with all it's the nuances see

http://www.qnx.com/developer/articles/dec1200b/index.html

jk

 

Bob Peterson:
> > > While your statement might well be true for some control
> > > applications, its just plain silly to make the assertion widnows
> > > or linux cannot be used in all cases, since its being done on a
> > > regular basis, with generally acceptable results. <

Jiri Baum:
> > OK, perhaps I did state it rather strongly; however, if
> > professionals cringe at the use of VB in automation, I suspect this
> > issue is a great part of that. <

Bob Peterson:
> VB is just totally unsuitable for any kind of realtime control. Its
> just too unpredictable, and has a nasty habit of hanging up. OTOH,
> something written in C or some other language might be quite
> acceptable.

One still has to be careful not to do silly things in the real-time part, like allocating memory or reading the disk; and disabling swap (and the screen-saver, and any scheduled stuff) sounds like a good idea.

> > > Arbitrary delays in many control systems are not that big of a
> > > deal, since it often is not important, as long as they are within
> > > some acceptable level, sometimes measured in minutes. <

> > If nothing else, many control systems will require response in the
> > hundreds-of-ms range because otherwise buttons won't work. <

> A lot of PLCs out there with scantimes in that range that work. Its a
> minor nuisance to the operator, but it does not amke it unusable. I
> have seen PLC programs with scan time of near 1/2 second that worked.
> I don't consider it ideal, but its not a big deal in a lot of cases.

Like I said, hundreds-of-ms range. At 500ms (1/2 second), the operator will have to press buttons very firmly, but, as you say, it's only a minor nuisance.

> > > The key is to determine what level of arbitrary delays you can
> > > accept, and do what you can to see that the end result is within
> > > acceptable parameters. <

> > Yeah; and how do you know what level of arbitrary delays you're
> > going to get from a Windows or Linux machine? (Some delays might get
> > worse as time goes on - for instance, as disk fragmentation
> > increases.) <

> Disk fragmentation is a major issue with any windows machine.
> however, there are techniques and/or software that can eliminate this
> problem.

Yeah; you have to be careful to catch them all, though.

> A worse problem with windows is continual updates. But, if not
> connected to the outside world this is not really an issue either.

Assuming you take great care with any laptops that connect to it.

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

 

Jiri Baum:
> > OK, perhaps I did state it rather strongly; however, if
> > professionals cringe at the use of VB in automation, I suspect this
> > issue is a great part of that.

Michael Griffin:
> Professionals cringe at the use of VB for anything. <

Well, there is that.

> > > The key is to determine what level of arbitrary delays you can
> > > accept, and do what you can to see that the end result is within
> > > acceptable parameters. <
> > Yeah; and how do you know what level of arbitrary delays you're
> > going to get from a Windows or Linux machine? (Some delays might get
> > worse as time goes on - for instance, as disk fragmentation
> > increases.)
> Yet, somehow this doesn't really seem to be the sort of problem which
> we see from day to day. <

I suspect mostly they'd show up as "undiagnosed malfunction". Timing glitches are hard to diagnose at the best of times.

> Most automation tasks don't require real time performance. Those that
> do (e.g. waveform generation or acquisition) are often offloaded to
> specialist hardware (e.g. data acquisition boards). <

Umm, don't confuse high-performance with real-time performance. One talks of the speed itself, the other of *guarantees* on the speed.

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

 

Jiri Baum:
> > No, it is an objective property. For instance, a PLC is real-time,
> > because in the back of the manual there's table giving the maximum
> > running times for every single function.

Michael Griffin:
> However, there are still a number of factors which make it difficult
> or impossible to predict the response time of a PLC. The length of the
> execution path which the program will take in any individual scan will
> normally vary. <

That's up to the programmer, of course; simple stepladder is just simple addition. Often, one can do a worst-case: count the longest possible path for all branches. If that's short enough, no further analysis is required.

> Communications events will often affect the scan rate. WIth some PLCs,
> connecting a programming computer will slow the scan rate
> significantly.
Generally, these should be noted in the manual, with the relevant figures.
>
> If you wish to define "real-time" as "completely predictable", a PLC
> is not "real-time". However, few industrial applications truely
> require real-time behaviour. <

Usually, real-time just means "with a predictable upper bound".

> <clip>
> > This makes it impossible to write a control system in plain Linux
> > (or plain Windows) - arbitrary delays make for broken control.
> <clip>
> In most industrial applications arbitrary delays make for arbitrary
> delays, not "broken control". Your statement is too general. <

Perhaps it is; but most apps will have at least some parts in which it's not really acceptable for the controller to take a two-second break while it does some house-keeping. In an office application, people hardly notice.

> Stock Linux (or Windows) may function quite satisfactorily in most
> applications. The "arbitrary delays" in newer versions of the Linux
> kernal are orders of magnitude smaller than the scan rate of a PLC
> (comparable information for Windows seems to be very difficult to
> find). <

There is that (though one really needs to count delays from the application's point of view, rather than just kernel delays).

> In industrial applications, "real-time" simply indicates that response
> time must be considered as a particularly significant design factor. <

I agree with this definition.

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

 

On October 25, 2003, Jiri Baum wrote:
<clip>
> > However, there are still a number of factors which make it difficult
> > or impossible to predict the response time of a PLC. The length of the
> > execution path which the program will take in any individual scan will
> > normally vary.
>
> That's up to the programmer, of course; simple stepladder is just simple
> addition. Often, one can do a worst-case: count the longest possible path
> for all branches. If that's short enough, no further analysis is required.
<clip>

For any non-trivial PLC program, it isn't "simple" because the program is too large to reasonably analyse in this way. You could equally say that it's "just simple addition" to do the same for a program running on a PC. The question isn't whether it's possible, it's whether it is practical with any reasonable amount of effort. In either case the answer is no.

> Perhaps it is; but most apps will have at least some parts in which it's
> not really acceptable for the controller to take a two-second break while
> it does some house-keeping. In an office application, people hardly notice.
<clip>

People would notice, they just have very low expectations when dealing with office applicaitons.

(The following is from a separate message)
On October 25, 2003, Jiri Baum wrote:
> > Most automation tasks don't require real time performance. Those that
> > do (e.g. waveform generation or acquisition) are often offloaded to
> > specialist hardware (e.g. data acquisition boards).
>
> Umm, don't confuse high-performance with real-time performance. One talks
> of the speed itself, the other of *guarantees* on the speed. <

Don't confuse real-time with high performance either. A data acquisition board guaranties real time sampling or waveform generation. This doesn't necessarily (although it can) mean high speed operation. The reason you would use a data acquisition board instead of simpler (and much cheaper) analogue cards is because the sampling (or output) and storage of the data takes place at a precisely defined interval independently of what the PC may otherwise be doing. This means you can do something requiring real time performance (sampling data) without a real time operating system.

I am not saying that you are entirely wrong. I have seen systems that occasionally malfunction because Windows NT and VB are not real time systems. I could tell you a long sad tale of someone who ran into another instance of
this problem on Friday. I am simply saying that many if not most industrial applications don't require real time performance. For many of those that do, a viable solution may be to perform the real time tasks in dedicated hardware.

--

************************
Michael Griffin
London, Ont. Canada
************************

 

Predictability is not the issue here. A real-time computation has to be bounded. For example, let's say we have a real-time computation that requires an algorithm that sorts, in ascending order, the values or 4 analog inputs and that the sorting library at hand uses a rock-sort. The values of the 4 analog inputs are unpredictable. On one pass, the values may already be sorted, requiring only one pass by the sorting routine. On the next pass the values might be in descending order,
require 4 passes by the sorting routing. The time it takes for the sorting computation to solve this is unpredictable, but it is bounded. With the right operating environment, the programmer can calculate or measure the exact time it takes to make this computation in the worst
case condition his application offers. He can then assess whether or not this condition meets his application's real-time requirement.

Real-time is an object property, but it's based on boundaries, not predictability.

On October 25, 2003, Jiri Baum wrote:
> From: Jiri Baum
> > > No, it is an objective property. For instance, a PLC is
> real-time,
> > > because in the back of the manual there's table giving
> the maximum
> > > running times for every single function.
>
> Michael Griffin:
> > However, there are still a number of factors which make it
> difficult
> > or impossible to predict the response time of a PLC. The
> length of the
> > execution path which the program will take in any
> individual scan will
> > normally vary. <

Yes. The execution path, and solution time, will vary when the algorithm uses any non-trivial set of operations.

> That's up to the programmer, of course; simple stepladder is
> just simple addition. Often, one can do a worst-case: count
> the longest possible path for all branches. If that's short
> enough, no further analysis is required. <

For better of worse, many PLC engines try to enforce an execution time boundary by providing instruction sets that only perform trivial operations.

jk

 

Hi Michael, Jiri

I would just add that realtime performance and hardware are proportional. Systems that operate with predictable timing operate with the absolute minimum of software in the time critical paths. They have either very small, very efficient code or decouple a small part to run the time critical tasks. But there is little difference these days between using a low tech analog card with a small decoupled realtime executive and using an intelligent data acquisition system as they are the same approach. Adding a processor to do this is both expensive and arguably unnecessary with the entry level PC's offering hundreds of MIPS and dedicated RT systems still running on 8 and 16 bit procs with often less than one. Design is still the key and no amount of horespower will make up for a bad
one. If you are going to do realtime, one should start with a reasonable candidate. Too often, this is a marketing decision and as a result PCs are held to be unreliable and uncapable in this arena. The hardware isn't the problem. Every sad story I've heard has had the same idiotic decision at it's root.

Regards

cww