Is ISA a rip-off?

Anita Richards wrote:

news:...

The greater Linux community, including many, many talented people at HP and IBM, not to mention thousand of other developers working on the Linux kernel ensures that you have the world's #1 software/computer science team working on your kernel/Rtos. If you are a technician, or got your computer degree from a business/mail_order college, then I'd suggest you do not look under the ladder logic. Embedded Linux is robust, and more stable than most RTOS solutions used by the larger, more expensive PLCs. If you are using smaller PLCs, it most like use a 'state_machine' to support the minimal functions of a low end PLC. Again, either way, if you are not predisposed to look at and learn about such things, then you do not have to. Either way, that does not subtract from the robustness of using a linux or linux derivative as the bases for the embedded OS on a particular processor that runs your controls processes.

However, for those persons who want to learn more, or save money, or both, it's nice that embedded linux gives you that option.

These aformentioned typical controls semantics and hueristics are not implemented any differently on an embedded linux PLC than the commercial PLCs. Linux based PLCS cost less, offer more flexibility, and are more fun to work with, than overprice, proprietary PLC solutions. They work just fine, and other, competant people can follow the work, and continue support and make enhances, easily using embedded linux control solutions. Ever get the shaft from a major PLC vendor, when they deprecated existing product lines of PLCs? That little trick has no place in embedded linux controls, as it is trivial to migrate controls software to a different hardware platform.

I agree with what you are saying. Using an embedded linux driven controls solution, is just like selecting between ABB, Allen-Bradley, Siemens, Modicon, AutomationDirect, etc etc. Except you get the sourcecode, have thousands of brillant people willing to help you, get robust and secure communications, and save a bundle of cash. The robustness of the solution is just as valid. It's hard for me to understand people who make contrary statements, when they have not even tried an embedded linux solution. But, many people are using embedded linux in the products they purchase and they are not even aware of it. I have coded on both commercial PLCs and embedded linux controls solutions. Both work fine. Embedded linux is easier to maintain across the lifetime of a facility, as you avoid getting burned by the 'we done offer or support that product any more' trick. Embedded linux is everywhere, including some major PLC vendors that are not going public with the information. You see, when you robustly analyze a network, different kernels and TCP/IP stacks give off details of what their RTOS/State_machine is using. It's called fingerprinting and it is a common technique for hacker/terrorist recon. No doubt, the dispostion of many folks in this news group, would lead me to believe that many are not even aware that this can be done, to verify what the actual RTOS/State_machine software is actually running on your favorite vendors PLC you and analyze the returned packets and how PLCs handle errors and frame datagrams. You think these PLC vendors just implement ethernet, and TCP/IP on a variety of products, without leveraging the relevant existing and published source code repositories? Dream on. The problem is that this sort of hack by commercial vendors is not very robust in the area of security. When you add the need to support all things microsoft for the PC that the technicians used to develop this PLC software on, you are really opening up your controls network to HUGE security holes.

If you use and learn about linux, you will discover these things in time. If you are happy with Microsoft and your PLC vendors, then just keep your head in the sand. See no evil, therefore evil does not exist? And you know what, until your facility is comprimised, you are safe in your prejudice.

Don't use embedded linux, if you are happy with your existing commercial PLC vendors. But, most of the companies I work for as a consultant, want to save money, have issues with there software and equipment suppliers, and are dam worried about secure communications solutions. All of my clients are embracing embedded linux for both PLC_style controls and SCADA needs and it's mostly their idea.

I have received lots of private emails concerning this thread. Do not let the voices of a few recalcitrant purveyors sour your attraction for technology that is superior and less expensive! Learn about Linux.

In fact, I just got a call from a company that has been doing database work for petroleum distributors for a very long time, using Linux. One the guys mentioned my name and mentioned using linux for their controls and SCADA needs. Now it seems I must travel to south Florida and sit on a yacht, and discuss embedded linux controls with some sort of wealthy tycoon. He is upset with a major vendor but likes what his accounting services contractor has done for him with an opensource database and linux. Wait until he sees all of his processes, mechanical, electrical and communications details in a linux base SCADA system. He dreams it and I shall built. I was warned that he has recently come out of retirement, due to boredom, and he is an excessive compulsive, driven to success.

ttfn,

Peace and Prosperity, my friends! James

There is a big difference between using an embedded linux product in the field and actually programming it from scratch. If your embedded linux product can be pulled out of the box, inserted in my process, wired in, and it works, that it is a good product. If I have to spend time programming it, or have to peruse thousands of lines of source code to figure out what it is doing, then it is worthless.

If you are a control vendor, then go ahead and make and provide these linux solutions. Get the specialized talent you need, pay them accordingly, and start selling. On the other hand, if you are in the middle of a plant, with a few thousand loops to worry about, all you really have time for is to make sure that everything is working, and occasional tuning.

Going further, we have to consider that perhaps a few thousand users are dependent upon one vendor to do all that OS work. If they did it themseles, instead of one team of 20 serving all of them, there would be one team of 20 (more likely less) for each one of them. Costs of 20 people is $1MM to 2MM/yr Cost of 10 people per customer would be 2000*10 *50000 = $1,000,000,000. Can you justify spending 1000 times the money on personnel? Fully debugging software can thake a while. An error which costs $2000 for the vendor to correct is going to cost 4000,000 to correct. Some efficiency.;

If you want to offer a linux package, fully turnkey to a plant, then you are likely to receive some success. If we have to program controllers from scratch, it's not a good idea.

Michael