SCADA Server and Real Time OS

K

Thread Starter

kapil

i am working on intouch 8.0 scada from last one year,i want to get an answer about one basic question.

my question is: scada is a real time system then it should require a real time os for it although i am using windows 2000 server (OS) which is not a RTOS,
 
C

Curt Wuollet

Then obviously, your scada is not a real time system. Does that answer your question? W2K likes to take a break every now and then to flush buffers, scribble on disks, and do other secret stuff. The fact that it was sold to you as real time is hardly surprising, as they probably call it Open as well. The time to be asking these questions is before you sign the check.

Regards
cww
 
my scada (wonderware, intouch 8.0) is successfully runing on windows server 2000. i am using around 5000 tags, please give a specific answer of my question
 
W

William Sturm

Your system is most likely a soft realtime system. Soft real time systems attempt and usually succeed in keeping timely communications with the plant or process.  If they fall behind a little there is no major consequence.  This is opposed to a hard real time system, where any missed timing may result in a system failure.

As far as I know, it is possible to have hard real time inside a Windows system, but it takes specialized software kernels.  I don't know if WW claims to have any hard real time kernels in their system.

Bill Sturm
Abbeytronics LLC
 
The specific answer to your question is that if your SCADA is running on MS Windows 2000, then it's not a real time system in the sense that you are thinking of. "Real time" is a very flexible concept though.

If it's "successfully running" though, then it's a little difficult to see what your problem is. If it's not "successfully running", then you'll have to tell us what the problem is and what it is you want to do that you can't do now.
 
would u please tell me, is there any karnel in wonderware 8.0 which is playing a roll of rtos. i have read some articals abt windows NT 4.0 which have some features of RTOS that is why its used in automation industry. so is there same type of features windows server 2000 have
 
>is there any karnel in wonderware 8.0 which is playing a roll of rtos. <

No

>i have read some articals abt windows NT 4.0 which have some features of RTOS <

MS Windows NT4.0 is not an RTOS, and doesn't attempt to be one.

>that is why its used in automation industry. <

MS Windows is only used in the automation industry (and anywhere else for that matter) because they have OEM contracts to have it pre-loaded on a lot of computers. There is no other reason.

>is there same type of features windows server 2000 have <

MS Windows NT4.0 is not an RTOS, and neither is 3.1, 3.5, 5.0 (Windows 2000), 5.1 (XP), 6.0 (Vista), or 6.1 (Windows 7).
 
C

Curt Wuollet

I do not believe WonderWare has any RTOS functionality on it's own. And neither does W2K. It is used in industry because Windows is the devil they know and no one wants to expend the effort to learn anything else, except where they absolutely need a RTOS.

Management clings to the notion that if its Windows, anyone can do it. And from what I've seen, they have anyone try. I am of the belief that the people you _should_ have doing your critical business and control functions would have no problem with another OS. But Windows is what management and IS know how to use, and they fear the unknown and don't want to lose any control. So, regardless of how wretched it is for the task, Windows is the only option they will seriously consider. And there are certain advantages, just not from a control engineering or technical viewpoint. I am continually impressed with the ingenuity and effort people will expend to make it work. It would be so much easier and less expensive to start with a reasonable candidate for control work. Check out the OPC thread.
But, there it is.

Regards
cww
 
ok, windows 2000 server is not a RTOS.

but can u explain me how it is getting possibe to access and control of plant data, using wonderware scada server which is working fine from last one year. how scada do this real time processing running on non real time OS (window server 2000).

do u have any study material clearing all my doubts?

please reply
 
W

William Sturm

A non real time OS can be fast and provide excellent performance. It just does not guarantee a maximum latency time. For example, a non real time OS may work perfectly 99.9% of the time, but .1% of the time it might have a significant delay. A real time OS is designed for 100% on time performance.

Bill Sturm
Abbeytronics LLC
 
C

Curt Wuollet

That's easy, most processes occur at a rate where the time variation, at least for display purposes, isn't that important because people are hardly real time. So SCADA is greatly relaxed compared to actual control, which often has stricter requirements on timing. That's why Windows is restricted to display in any sane design and actual control is done with PLCs, etc. for anything faster than people speed. And you don't need much reading on this, just get to where you can see a sensor turning on and off and compare that to when it shows up on the SCADA. This time skew, which is going to be considerable with 1000 pts., is normally completely ignored for the sake of customer happiness, but it can and does cause problems when signals of one sample are compared to another sample. If you want something even remotely close to realtime, you don't start with 45 million+ lines of code including the kitchen sink and Bob, and it's not point and click. You should have doubts, for sure.

Regards
cww
 
Wonderware is the name of a company, not the name of a product. Wonderware sells a software application product called Intouch. There is a version 8 of this product. Wonderware also sells a soft logic application product called InControl. Wonderware's InTouch product is fairly popular, the InControl product is not.

It is possible that the InControl product comes with a Microsoft OS kernel (not "karnel") hack that claims to enable the InControl product to run as a real time process.

See this:

http://global.wonderware.com/EN/Pages/WonderwareInControlSoftware.aspx

It's impossible to tell from this what Wonderware means by "real-time".

Here's an excellent article describing the term "real time":

http://www.linuxdevices.com/articles/AT4288667765.html

 
C
Yes, Steeplechase and a few others do that sort of thing, but from the context here, I'm fairly sure we are talking about the SCADA product. Maybe it uses both?

I don't remember any more exactly how this is done in Windows, but RT Linux and the like work roughly like that for hard realtime and soft realtime can be achieved with the "normal" kernel with a few options compiled in. So it could be said that most any Linux distribution can be a soft realtime OS. We've had some very credible work published on this list describing that. But out of the box W2K doesn't really have any RT provisions that I know of. And of course, in any case, the code has to be written with this in mind.

Regards
cww
 
In reply to Curt Wuollet: The way this is done in MS Windows is that it isn't done in Windows. There are (or were) a couple of companies which sold a real time executive (RTE - a mini-RTOS). MS Windows was then run as one of the tasks as a guest under the RTE. The real time control application ran as another task under the RTE. Non real time applications could run on MS Windows. This included anything which needed GUI access. There were a set of inter-process communication (IPC) libraries which allowed messages to be passed between the RTE and MS Windows.

I am using the past tense for the above, because the last time that I looked at this these products seemed to be more or less dead. They were still being sold, but there didn't seem to be any development beyond minimal support taking place and MS Windows support hadn't extended past XP.

I can't recall the names of the parent companies. The products were sold through third parties under multiple names, but so far as I know there were only actually two different ones. They would sell their products to third parties who would integrate them into their soft logic (or other system) and then sell the integrated package to the final users. It was never software that an end user could make use of themselves.

Some of the older versions of real time Linux used the same approach, but with a different real time executive. However, that has been dropped in favour of putting real time features directly into the Linux kernel. If you use a stock Linux kernel from the big distros, these RT features are turned off. If you know what you are doing though, you can re-enable them and have an RTOS.

The problem with real time in an OS however is that there is an inherent conflict between real time performance and maximum average throughput. This is why Microsoft has never shown any interest in real time, as it is outside of their core market of people doing simple word processing or playing video games. Companies are doing it with Linux, but in that case it's because there are different companies pursuing different markets.

For what most people are doing however, they don't need "hard" real time. I did some experiments a few years ago on timing variation using the standard schedulers with both Linux and MS Windows and posted the results here. The conclusion was that the "soft" real time performance for Linux was much better than for MS Windows. Typical performance was the same for both, but MS Windows would have occasional random pauses of several hundred milliseconds. In typical control applications people probably wouldn't notice that though.

We should remember that normal PLCs are not real time systems either. The scan rate will vary depending on what else is going on in the system. Getting guaranteed micro-second repeatability out of a complete system requires a lot of work and testing and has zero value in most applications.
 
C
Hi Michael

> In reply to Curt Wuollet: The way this is done in MS Windows is that it isn't done in Windows. There are (or were) a couple of companies which sold a real time executive (RTE - a mini-RTOS). MS Windows was then run as one of the tasks as a guest under the RTE. The real time control application ran as another task under the RTE. Non real time applications could run on MS Windows. This included anything which needed GUI access. There were a set of inter-process communication (IPC) libraries which allowed messages to be passed between the RTE and MS Windows. <

Yes. I knew that's how they were doing it in RT Linux and RTAI But I wasn't sure Steeplechase etal. were using the same approach as that would require access to Windows internals that few have (or want :^)). The pass through in Linux was not very elegant in the real early stuff I looked at, but it worked.

> I am using the past tense for the above, because the last time that I looked at this these products seemed to be more or less dead. They were still being sold, but there didn't seem to be any development beyond minimal support taking place and MS Windows support hadn't extended past XP. <

I imagine one has to sign a lot of papers and checks and things to putz with Windows that way, and repeat for each new version.

> I can't recall the names of the parent companies. The products were sold through third parties under multiple names, but so far as I know there were only actually two different ones. They would sell their products to third parties who would integrate them into their soft logic (or other system) and then sell the integrated package to the final users. It was never software that an end user could make use of themselves. <

> Some of the older versions of real time Linux used the same approach, but with a different real time executive. However, that has been dropped in favour of putting real time features directly into the Linux kernel. If you use a stock Linux kernel from the big distros, these RT features are turned off. If you know what you are doing though, you can re-enable them and have an RTOS. <

Yes, and they are more than adequate for PLC type response times and it's handy not having to pass data with a queue. And no royalties.

> The problem with real time in an OS however is that there is an inherent conflict between real time performance and maximum average throughput. This is why Microsoft has never shown any interest in real time, as it is outside of their core market of people doing simple word processing or playing video games. Companies are doing it with Linux, but in that case it's because there are different companies pursuing different markets. <

But that's the wonderful thing about Linux modularity. With the kernel switches and the stuff you don't need removed, it's a serious RTOS contender and finding a great deal of use in the embedded market. No parallel in the Windows world. This is what would make it such a great PLC and tools OS. Workstation and PLC could be of a common code base.

> For what most people are doing however, they don't need "hard" real time. I did some experiments a few years ago on timing variation using the standard schedulers with both Linux and MS Windows and posted the results here. The conclusion was that the "soft" real time performance for Linux was much better than for MS Windows. Typical performance was the same for both, but MS Windows would have occasional random pauses of several hundred milliseconds. In typical control applications people probably wouldn't notice that though. <

I wouldn't want to run motion control like that. The robot could be through the wall by then.

> We should remember that normal PLCs are not real time systems either. The scan rate will vary depending on what else is going on in the system. Getting guaranteed micro-second repeatability out of a complete system requires a lot of work and testing and has zero value in most applications. <

Agreed, what causes irritation is not the need for realtime as much as the rampant abuse of the term.

I should set some stuff up and play again, one of the few benefits of being unemployed is that you can be an unemployed (whatever you want) I may as well be an unemployed embedded developer for a week or two :^). I'd really like to do that for real, but they don't do it here in the woods on the river, or anyplace close.

Regards
cww
 
In reply to Curt Wuollet:

>Yes. I knew that's how they were doing it in RT Linux and RTAI But I wasn't sure Steeplechase etal. were using the same approach as that would require access to Windows internals that few have (or want :^)). <

I can't comment on Steeplechase in particular, but all the MS Windows systems that I looked at used this approach, and the RTEs were all from the same two vendors (mainly from one, actually).

As for access to MS Windows internals, there is actually a separate low-level layer of MS Windows that they completely replace. That's one of the really ugly things about this approach. That layer is actually meant to allow you to do things like this, but since nobody else actually does anything with it there's no guaranty that everything will work as advertised. That is, you don't know if someone at Microsoft has hacked around it to fix a problem with hibernate mode in laptops, or if some chip set driver will go berserk if your changes upset the read/write timings. I imagine that it is very expensive and time consuming to develop this sort of software while there is a very limited market to sell it to. It sounds like a good way to lose money.

>The pass through in Linux was not very elegant in the real early stuff I looked at, but it worked. <

This approach is one of those things which sounds nice in theory, but turns out to be less than elegant in practice in any operating system. That's why the whole idea was dropped in Linux in favour of integrating the real time code directly into the kernel. That took a lot of work over a number of years. In the end, what finally got the RT patches accepted into main line Linux was the fact that the work required for real time dovetailed quite nicely with the work required for improving multi-processor scalability. That is, a lot the changes needed for tiny embedded systems were also needed for very large super-computers. That meant that the embedded companies and the enterprise server hardware vendors were working together for once instead of complaining about each other.

>I imagine one has to sign a lot of papers and checks and things to putz with Windows that way, and repeat for each new version. <

As I mentioned above, writing this sort of software for MS Windows sounds like a good way to lose money. Because it *isn't* part of the Windows kernel but still depends on working closely with the kernel, you never know when somebody at Microsoft who's never heard of you is going to change something that makes your software stop working. Meanwhile, it's probably at least 10 or 100 times harder to write than normal software because you are working with stuff that is so poorly understood.

I have to say though that if you want to get copies of the Microsoft source code for MS Windows, it's only hard to get if you are honest. Their source code has leaked multiple times, so the virus hackers have no trouble getting hold of it. If you want a copy, you can find it on the Internet. However, I wouldn't touch it with a barge pole.

From what I've read though, it's pretty typical proprietary code. There's lots of horrible code hacks, and plenty of childish profanity and disparaging comments about co-workers and bosses.

>I wouldn't want to run motion control like that. The robot could be through the wall by then. <

Well, I said "typical" applications. Most people aren't building their own robots. If I was building a robot then yes, I would want real time control. It's not necessary for most PLC type applications though. It's not an issue that I'm even trying to address in my own projects at this time.

>Agreed, what causes irritation is not the need for realtime as much as the rampant abuse of the term. <

Do you mean like "real time SCADA systems"? As in, "I need an RTOS so I can scan a tank level once every 5 seconds?"

>I should set some stuff up and play again, <

If you're interested in real time, have a look at EMC2 (http://www.linuxcnc.org/). They're doing multi-axis motion control for CNC and robot systems using RT Linux. They're distributing it as a modified Ubuntu ISO with everything ready to go. They could probably use some help and its a pretty extensive project with a lot of developers.
 
As William Sturm explained earlier, the OS does a fair job of at least appearing to be nearly real-time (most of the time). Many processes are quite happy with not-quite-real-time control, and I am guessing that yours is one of them.

Kevin
 
Top