COMpatibility and control

  • Thread starter Michel A. Levesque, ing.
  • Start date
M

Thread Starter

Michel A. Levesque, ing.

Hi all,
I've been following a few threads here and the discussions involving open systems, communications and Windows seem to be
converging. So I'll just add my 2 cents worth.

1.Windows is proprietary and not truly open(ok, this statement is iffi).
2.Windows is not the best platform for control.
3.Windows is the only widely accepted OS.
4.Most automation suppliers are following WINwhatever because this is what customers want.
5.Most customers want a package that is stable, easy to configure, can be modified by an 8 year old, has acceptance by everyone (even suits), can actually be used to control equipment (versus just attempting to).
6.Most SCADA or HMI packages are on the Windows bandwagon because of #3 and #4 and not because of #5.

So, can anyone suggest viable alternatives for an OS that will take all of these points into account. This choice of OS could then be pushed in one concerted movement by all involved in the automation field.

This last paragraph states the huge can of worms that would be opened by trying to push this "new" standard. Unfortunately, we will have to live with what we have. The only remote way to change
this situation in the short term is by having MS opt out of the automation field. This could be done by adding some sort of "flash in the pan feature" that front office users want but which would make WINwhatever useless for automation. Only then would we all look for anything else that would work. Lo and behold, we would be right back to the pre-WINwhatever era.

Any takers?



Michel A. Levesque eng., mcp
Directeur Bureau Montreal
AIA Inc.
[email protected]a
 
I am searching on the open system for PLC SCADA and HMI software beside of Microsoft OS. There's an alternative OS caled QNX that was used in our equipment for SCADA and HMI. There's a vendor I dealing with : REALFLEX in Houston, TX. They provide solid OS and reliable operation since it is Unix based OS.
You can take a look...
 
R
List Management Account wrote:

> 1.Windows is proprietary and not truly open (ok, this statement is
> iffi).

What, you means might not actually be proprietary;-)

> So, can anyone suggest viable alternatives for an OS that will take
> all of these points into account. This choice of OS could then be
> pushed in one concerted movement by all involved in the automation
> field.

I have never understood why we must do everything with one OS. Windows is fine by me for front ends, but when I want to do e.g. an embedded headless active gateway, windows is all cons and
no pros.

> The only remote way to change
> this situation in the short term is by having MS opt out of the
> automation field. This could be done by adding some sort of "flash
> in the pan feature" that front office users want but which would
> make WINwhatever useless for automation.

Um, Microsoft already have opted out of the automation field, leastways they have not come up with the goods. And as I pointed out, they are happy to support groups that promote fancy techniques that suit office but not automation.

With this business of dropping DCOM in favour od SOAP (even less suitable for IA architectures), they appear to have shot themselves in the foot.

I notice nobody has been defending OPC from a technical viewpoint.

I also note that my headless communications gateways are installed by electricians who screw them to the wall and connect the cables. They are pre-configured and need no maintenance.

Why would I want to put windows on such a box? To make it easier to use? So that I could run MS Word on it if I wanted? (oops, no display).

There are a number of systems out there suitable for such embedding, and they are all reasonably similar, once you know one you can handle them all. It is also easy to port software between them (indeed they are in part binary
compatible).

Broadly speaking we are talking about POSIX based embedded systems, examples include PicoBSD and QNX, but most of all Linux. There are numerous Linux distributions designed for embedded systems, so you can find something allready fine tuned to your requiremnets, including specialist needs such as flash based systems, real time
extensions, and distributions for non-Intel hardware such as low power ARM chips (yes John, you can use it WITHOUT a fan!).

If you have any embedded systems experience, you may wish to look at www.embedded-linux.org,
the corporate members list reads like a who's who of the industry, these are not toy start ups but
major organisations who offer complete packages with full support (support is always good in Linux, it is how companies actually make their money;-) )

If you are more interested in the DIY and make it real lean type of system (which is really more for
OEM's than IA), then www.linux-embedded.org offer a wealth of resources.

So you see there are allready a wealth of compatible alternatives out there, and
many of us are using them, and yes we can interface neatly cleanly and easily to windows based front ends. The only thing that can get in the way of the diffusion of these systems into the
realms of devices such as HMI's is the introduction of protocols whose only distinguishing feature is that they require
WINDOWS (specifically NT) at BOTH ends of the connection.
 
C

Curt Wuollet

> I've been following a few threads here and the discussions involving
> open systems, communications and Windows seem to be
> converging. So I'll just add my 2 cents worth.
>
> 1.Windows is proprietary and not truly open(ok, this statement is
> iffi).
> 2.Windows is not the best platform for control.
> 3.Windows is the only widely accepted OS.
> 4.Most automation suppliers are following WINwhatever because
> this is what customers want.
> 5.Most customers want a package that is stable, easy to
> configure, can be modified by an 8 year old, has acceptance by
> everyone (even suits), can actually be used to control equipment
> (versus just attempting to).

This is where Linux comes in. Your PLC may be running Linux before you would consider it for desktops. The number of embedded wins for Linux both here and abroad mean it's only a matter of time before someone hits on the bright idea of using Linux to get all the latest features (ethernet, internet, realtime ) in a commercial PLC at low cost with much less effort.

> 6.Most SCADA or HMI packages are on the Windows bandwagon
> because of #3 and #4 and not because of #5.
>
> So, can anyone suggest viable alternatives for an OS that will take
> all of these points into account. This choice of OS could then be
> pushed in one concerted movement by all involved in the automation
> field.

Yes, Linux. If MS on the desktop ineveitably means MS on the factory floor, will Linux get equal status when things are 50/50?

> This last paragraph states the huge can of worms that would be
> opened by trying to push this "new" standard. Unfortunately, we
> will have to live with what we have. The only remote way to change
> this situation in the short term is by having MS opt out of the
> automation field. This could be done by adding some sort of "flash
> in the pan feature" that front office users want but which would
> make WINwhatever useless for automation. Only then would we all
> look for anything else that would work. Lo and behold, we would be
> right back to the pre-WINwhatever era.
>
> Any takers?

I agree that the playing field is almost vertical and the monopoly has grown to the point of being self-perpetuating, but, is this a good thing?
Can it be turned around or is it completely out of our control?

cww
 
C

Curt Wuollet

Hi Dave.

As you will recall, we were really interested in AutomationX. Too bad we couldn't come to terms on IO. And it looked really good as a process
control/SCADA system. But it could hardly be a replacement for say a micro PLC or run out of flashRam. Unless you guys have been busy while I wasn't looking :^). No, what I am talking about here is Linux as a replacement for the custom executive or RTOS that a conventional PLC runs on. Quite a few of the hardware platforms have enough resources and you would gain free tools, free networking, www capability, and my favorite, interoperability with free, open protocols. Not bad for free. And even if resources are lacking, the new generation of SOC would provide the resources and reliability in a small form factor at low cost. The Linux PLC project faces the same delemma, we want to run on embedded class hardware and we want to have a completely free, open alternative for the "all in one" NT solutions that are available on PC class hardware. This latter market is the one that you address well, except for the free and open part. I'm still interested in AutomationX as a replacement for Cimplicity IU as soon as you can talk to all the stuff I need to talk to. It will be a while before lplc is ready for this.
Has the picture changed?

Regards

cww
 
R

Ranjan Acharya

Since when is Linux already there ... just look at the FAQs on various web sites with the horror stories of installing Red Hat Linux and other
distributions of Linux.

I just went from Red Hat 5.X to Red Hat 6.X -- 6.X does not appear to support UltraDMA EIDE controllers. That is making things less than
enjoyable (this is on a Dell Inspiron 7500 which you can buy with Linux, but good luck installing it afterwards!). The graphical installation does not work either with the VGA controller in my Dell. I have a choice on installation -- black screen of death in graphics mode, immediate lock-up in expert mode or eventual lock-up in text mode. I do not have time for all this rubbish.

I am no big fan of Windows, but it does not even come close to Linux with the installation hassles. Last thing I remember is putting in the CD-ROM, turning on the laptop and pressing <F8> to indicate that I agreed with the terms of the licence agreement. I had NT4 and NT2000 working together on the same machine in no time (C: NT4, D: NT5, ... no issues).

I still think that a system where you have to worry about the OS is not worth worrying about. Until that becomes a moot point, I will stick with my trusty PLC. The stop light and fault light rarely come on and when they do, it is not because of an OS fault. The scan time is rigid and predictable, the system is relatively tamper proof and the life cycles are much longer.

RJ
 
D

David McGilvray

Curt,

I was curious about your "free and open" comment below. Certainly, the automationX product is not free! Interesting business model - giving away intellectual property for free. At the risk of
reviving the semantic discussion, however, I take exception to the open comment. automationX is as open as it gets short of providing source code - end users & 3rd party integrators have available all tools used by M&R for system development (classes, drivers, etc). In fact, custom programs may be developed and added to the program bundle to run within the native program. If a client isn't satisfied with the I/O capability, for example, they are welcome to customize to suit, again, using all the tools available to internal developers.

dwm
 
C

Curt Wuollet

Hi Dave

No offense intended, we need Linux _products_ too. I can see where the semantics in the Automation & Control field might confuse the issue. You described it just right. And free is actually turning into an interesting business model. It depends on the need for consulting, support, and other services. Only a small part of a project is software cost. In the context of the Linux PLC, we use Webster's definitions. Free is really free, as in free beer or free speech or whatever, you can copy it and give it away or modify it. Open means really open, you get the source, there are no secrets, trade or otherwise. Unfortunately, in the real world we need some
small provision to prevent abuse of the gifts of time and skill invested so we use the Gnu Public License to see that it remains free and open. I was certainly not implying that you guys should
do anything you don't want to do, after all, freedom is all about choice. It's simply I see free and open as binary concepts not a continuum that can be stretched so that even Microsoft products are considered "Open" if not free.

I don't have a problem with AutomationX. I don't consider it open, but I'd rather my customers run on Linux than the alternatives because I have to support them. As you recall we were quite
interested in distributing the product. Where it broke down was connectivity to the fieldbusses we need. Without the source, I couldn't write the drivers we needed and without clear return on
investment, I couldn't get approval to pay you to do it. I liked the product, but customers have their own preferences for fieldbusses and we have an installed base we need to talk to.

There is a need for a non-proprietary system that can and will support any thing you want without regard to vendor preferences and politically blind to the fieldbuss wars. A system that, if needed, can sit in the middle and actually solve the miserable mess of incompatible protocols and proprietary lock-in and connect to anything we can legally write drivers for. That is the purpose and the driving force behind the Linux PLC project. That's why it _has_ to be free and open or it will never be at all. Doing anything else would be part of the problem, not part of the solution.

Regards,

cww
 
Top