Is ISA a rip-off?

Anita Richards wrote:


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.
> Nobody in the plant should need to look at the source code of the

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

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
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

The problem with the ISA, profibus and everything else is it is tainted to the folks and companyies that are inside. The scary part is that these old engineers really think they know controls. They do, if all you want to do is fancy twist on PID.
They do not know shit about the software underlying products. The state-machine, kernel, executive, or RTOS is what makes or breaks a control system. The problem is embedded linux is leaving green-hills, allen bradley, Wind River and company behind in decades of old decrepted technology.
If you want to learn about real controls, you have to dig deeply into the underlying assemble and ansi-C code that runs on microprocessors, DSPs, and FPGAs. It is there you will really learn about controls, determinism, multi-threaded process etc etc. The PLC vendors push ancient controls systems build on pathetic state machines or RTOS, and the obstruficate the concepts of controls.
The SCADA vendors are even worse. The good news is now that the US government, NSA, cia, and fbi are looking closely at all of this expensive bullshit, they are realizing that only embedded linux can build secure control systems with modern functionaliity. Do not look for the vendors of these old-tired systems to make their software secure. They could not do it, if they tried. Time and again, I build devices and interfaces to 'sniff' out old-tired proprietary protocols that are mostly clear text. If they bother to use encryption, it's pathetically week.
I teach technician how to code in the assembler that is available on the controller, so they can understand the native assembler language and build modular programs that are portable. You can map the 'ladder logic' elements it block of assembly code. Once you do that, you can get all sorts of hardware to run controls systems on, make controls system distributed on top of RTlinux and purchase hardware anywhere.
At that point, you can use a real programming language like ansi-C. Don't get me wrong, if a company wants to pay me money to develop controls code a particular plc or scada system, then that's OK. However, when I show them code that runs on linux based pcs and the same code or it's assembler derivative on a demo board form a semiconductor manufacture (and orders of magnitude cheaper prices) they rarely choose the proprietary path.
Do look to the ISA or Profibus or devicenet(a real poor implementation of the CAN bus) or any of their associations to really teach you anything other than how to use their products and code to be a slave to their financial aspiriations.....
Dude, that's not engineering, that's what uneducated technician do...
Real engineers can code and solve problems in a variety of languages. My last major project involved writing ansi-C code to verify the logic and calculations of PLCs. I has to reorganize their thoughts to get the software happy for all of the 'regulators'. The really sad thing is I told them the solution was correct and operable, but not optimisitc. Now they want it optimized. I told them the only way to do that is with embedded linux. I offered hardware for free(only cost me less than a thousand bucks) all of the software free. They are still thinking about my offer.
The are senior members of the ISA......
Run, don't walk, to linux, ansi C and native assembler before you really think that ladder logic programming is robust.
PS Ladder logic is good for graphical representation, and simple tasks. It is not a robust solution for complex problems. If you really want tight control aka a high speed assembly line, you have to get into the guts of the RTOS running on the processor, to do things so that 'old_folks' say, 'how did you do that'.
A computer science degree never hurts..........EEs can not code for shit!
James
Add pictures here
<% if( /^image/.test(type) ){ %>
<% } %>
<%-name%>
Add image file
Upload

Polytechforum.com is a website by engineers for engineers. It is not affiliated with any of manufacturers or vendors discussed here. All logos and trade names are the property of their respective owners.