Where do we go from here?

C

Curt Wuollet

> Curt, you've said some interesting things. But I didn't say that I was > advocating a grand scheme. > > I said that _right now_ IN THE TRENCHES, there are people working like > dogs to build the bridges you say are impossible. They are building Gates, not bridges. And I didn't say anything of the sort. They need four lane bi-directional bridges not single lane toll bridges. Bridges that can connect anything. > Why? Because we have reached the level of diminishing returns from > automation. There. I said it. The emperor has no clothes. > > We reached the level of diminishing returns from automation in the First > World about five years ago, and if you look at the activity, both in the > field and in the boardroom, since then, you can see it plainly. The > round of M&A activity started because the First World market for just > control systems has shrunk tremendously. And they are going in the wrong direction. Watch what happens to the stock of the first one to break ranks and make a deal with RedHat or Lineo. Or pledges to try to solve the "Tower of Babel" or interoperability problems. Demings definition of insanity is where you keep doing the same thing over and over and expect the results to be different. The proprietary divisive paradigm has failed. IBM knows that, GE,AB and others don't get it. Modicon has an inkling, Microsoft is in denial, but learning fast. Making systems that don't interconnect and don't interoperate is not going to get you anyplace in IT with the realities of today. > Notice how many of the major controls companies have become actively > involved in "back office" and MES projects. All of them. Notice how > many of the major controls companies have become actively involved in > CRM and SCM. All of them. Walt, you're preaching to the choir. This is gonna happen. What's holding it back is that they are only addressing Microsoft shops. > Notice how the big analysts, Gartner and ARC, have repositioned > themselves. Yes, they are now giving the server market to Linux. > Notice that jobs in the automation sector are declining, while jobs > _doing the same thing_ in the technology sector are expanding at 50% per > year. exactly. > > You may want to suggest that IT can't handle control. Lots of us fondly > believe that. I'd be the last one to suggest that. I know they will. Don't get too comfortable, I think the IT folks can do more automation than the automation folks can do IT. I was IT a couple years ago. I do just fine. IT _will_ take over this middle ground and they will do it their way because that simply makes a lot more sense and their tools cost a fraction of what the Automation vendors will push. They know a network card is $25.00 not $1000.00 and having a hundred different protocols is just plain stupid. This, by the way is who pushed Ethernet into automation. You are saying that this is going to be accomplished by automation folks pushing up. I say it will be the IT folks pushing down. When you compare proposals it will be: Hoards of servers running expensive proprietary stuff with crazy licensing schemes and expensive proprietary networks versus "Oh, we can do it by putting in a router and tying it into our existing LAN" Who do you think is gonna win that one? We both see the same picture, All I'm saying is that IT is gonna fix a lot of broken things on the way. And the automation vendors won't stand a chance with their tunnel vision tuned to only Redmond. > But the fact is, IT is _in_ control. Because the information that the > control system can put out is important, yes, but it is not anywhere > nearly as important as the information that can be bundled with it, and > the information that integrated requirements and supply systems can send > to it. > That's why Automation vendors have to start offering more than toys that connect to office applications. On real platforms that scale and integrate well. IT is not likely to change to meet your automation integration needs. > Synergy is savings. Corporate management understands that. > > You can turn this into a diatribe against Microsoft, if you want. But > that whole argument is entirely beside the point. Much "back office" > work isn't on MS platforms at all. Much of this is on "x"nix and Linux > platforms. Much of it is on MS platforms. I didn't mention MS specifically but the fact that everyone knew who I'm talking about serves to point out the problem. And no it is not beside the point. I work in UNIX shops. I can't do the integration because there are no offerings that will integrate well with UNIX. I am a Linux consultant. I can't sell the integration because there are no Linux compatible offerings. How can that possibly be beside the point. What you say only works in your world. And the automation vendors have their heads in the sand on this point. UNIX is not going away except to be overtaken soon by Linux and IT likes Linux. > What I am saying is that if you want to advance in the new world of > manufacturing, you must be not only cognizant, but also up to date with, where automation fits into the enterprise. But, you can't ignore where the enterprise is going and that's away from MS in large part and towards HA clusters and Java and other technologies that no one is addressing. Windows everywhere was yesterday. IT has a choice. Tell me a way of integrating with a Sun shop or a Linux shop that isn't a horrific kludge. Now tell me _why_ it's such a kludge. Closed systems are poor choices for integration. Regards cww
 
D

Dave Ferguson

I agree.......I use RSLogix 5, 500 and 5000 and there is this "Microsoft" commonality including VBA etc. Although I agree at a fairly expensive price tag........ Same with RSView 32, VBA, object models etc. allowing "Microsoft" extensibility. But again very expensive. But where I work (which I admit may be abnormal) downtime is $15,900/HR so a $3000 price tag is not out of line.....problem is companies like mine drive the economic scale on software like this for smaller companies that cannot afford this pricing........... Now having said that........you are avoiding one critical issue with "open" source software....RESPONSIBILITY, safety etc. I am not saying it is unsafe, I am saying that the Rockwell's of the world have a huge base in liability insurance.........R&D, usability labs etc, business offices and on and on.......and that luxury adds up to $$$$$$$$. I am not saying it should be $3000 a pop but I don't have all the numbers so I don't speak about it until I understand all the costs involved before I criticize it. I agree a Linux PC is nice, cool etc. but if it causes an accident.....who do you call.....if it kills someone.....who pays......noone, because noone is responsible (although we can probably find lawyers to root out the individual responsible). Therefore right off the bat the level playing field you speak of is stacked against the "Big" HMI vendors, PLC software vendors etc. I agree with many of your and Curts points but like most politics.....you only see your side and not the other which was my point...........If this is not your viewpoint ....then like Gilda Radner........"Never Mind" Slam away......... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation
 
J

Joe Jansen/ENGR/HQ/KEMET/US

In response to Dave Ferguson <[email protected]>: <snip> >Now having said that........you are avoiding one critical issue with >"open" source software....RESPONSIBILITY, ******* >From the EULA (emphasis left as is, not added by me): THE LIMITED WARRANTY IN THIS AGREEMENT IS IN LIEU OF ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING (WITHOUT LIMITATION) ANY WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. ROCKWELL SOFTWARE INC. AND ITS LICENSORS SHALL NOT BE LIABLE FOR DAMAGES, INCLUDING ANY LOST PROFITS, LOST SAVINGS, OR OTHER INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF YOUR USE OR INABILITY TO USE THE SOFTWARE, EVEN IF RSI OR ITS RESELLER HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. <-and-> LIMITATION OF REMEDIES RSI's entire liability and your exclusive remedy shall be: 1. The replacement of the Software not meeting the Limited Warranty specified above which is returned with proof of purchase; or 2. If RSI is unable to deliver replacement Software which meets the Limited Warranty specified above, RSI or its reseller will refund your purchase price. IN NO EVENT SHALL RSI's LIABILITY TO ANY PARTY EXCEED THE PURCHASE PRICE OF THE SOFTWARE. Which means that if, because of their software, your plant explodes, killing everyone inside, they owe you roughly $3000. At most. Maybe. ******* >safely etc. I am not saying it is unsafe, >I am saying that the Rockwell's of the world have a huge base in >liability insurance.........R&D, usability labs etc, business offices >and on and on.......and that luxury adds up to $$$$$$$$. ******* And an even larger base in legal defense which will prove that it is not their problem that somebody wound up dead, or you are no longer to make production because of RS Software. ******* >I am not saying it should be $3000 a pop but I don't have all the numbers >so I don't speak about it until I understand all the costs involved before >I criticize it. > >I agree a Linux PC is nice, cool etc. but if it causes an accident..... >who do you call.....if it kills someone.....who pays......noone, because >noone is responsible (although we can probably find lawyers to root out >the individual responsible). Therefore right off the bat the level >playing field you speak of is stacked against the "Big" HMI vendors, PLC >software vendors etc. <clip> ******* Except that the "Big" vendors have enough lawyers and legal agreements that they can effectively avoid any liability better than the guy who wrote the free code. At the very least, they will keep you in court long enough that, hopefully, you just give up pursuing them and drop the case. I have been in this situation with Rockwell. RSView caused enough of a process variance that we ended up scrapping the batch, because we were unable to determine whether it was safe or not. Throughout the 'ordeal', RS blamed Microsoft, the system integrator, our maintenance people, me, the card manufacturer, the PC manufacturer, the operators, and probably a few more that I am forgetting right now. The point being that although they could offer support to help *US* correct *OUR* problem, they were not responsible for anything.
 
B
At 08:29 AM 2/6/2001 -0600, you wrote: >Now having said that........you are avoiding one critical issue with "open" >source software....RESPONSIBILITY, safely etc. I am not saying it is unsafe, >I am saying that the Rockwell's of the world have a huge base in liability >insurance.........R&D, usability labs etc, business offices and on and >on.......and that luxury adds up to $$$$$$$$. > > >Slam away......... OK, you asked for it. :> Are you saying that we must use closed source software to make it easier to sue someone? I believe that the first line of responsibility falls upon the engineer who designed the system. If you put out poorly tested software, you are responsible, no matter whether it is open source or not. I have seen some dangerous situations on shrink wrapped software, like outputs sticking on. I identified the problem and solved it by working with the vendor. With open source, I would have debugged the problem myself, or I would have relied on the internet community for help. Either way, I would feel responsible if I let the problem exist. Bill Sturm
 
V

Vladimir E. Zyubin

Hello Dave, I'm sorry, It seems to me you think Bill Gates will pay for disasters his programs can produce... Bill hates responsibility (BTW, as well as all of us :). All license agreements I see include the magical words "as is", "not responsible for", etc. I don't see all license agreements from all major HMI-players, but I believe that their policy on the topic is the same. -- Best regards, Vladimir mailto:[email protected]
 
D

Dave Ferguson

You totally missed my point...........with shrink wrapped software there are a number of fixed costs that you have, buildings, personnel, benefits, utilities, INSURANCE, R&D, Usability Labs, etc, etc, etc..... that you do not have with this open source model. So do not claim that all of overhead above and beyond the price of the CD's is pure profit..........there are a number of costs that go into the "high" price. Some people on the list immediately act like there is nothing but profit here. If you have ever ran a business under a "normal" business model, versus the I-net model that by the way is failing miserably right now (check your stock exchange lately) you know differently. I am not saying that there is not room for improvement in price and product......only lets compare apples with apples....... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation
 
M

Michael Griffin

At 20:52 06/02/01 -0500, Bill Sturm wrote: <clip> >Are you saying that we must use closed source software to make it easier >to sue someone? I believe that the first line of responsibility falls upon the >engineer who designed the system. If you put out poorly tested software, >you are responsible, no matter whether it is open source or not. <clip> >Either way, I would feel responsible if I let the problem exist. <clip> As a somewhat related point, I don't believe we have any such thing as third party liability here if someone is injured at work. The employer (and employee) is completely responsible, not the software vendor regardless of open source or not. I must say that I find Mr. Sturm's attitude the correct one. The first, last, and only objective of a design should be preventing accidents from happening, not finding ways of apportioning blame. However, I am a bit curious. What sort of software induced safety risks was Mr. Ferguson referring to? I thought the trend was to get away from having general purpose programmable devices responsible for safety, and to use special purpose certified safety devices. This way a user program or run-time or OS bug will not place anyone in danger. Furthermore, if we realistically look at what we are talking about here, I think we are comparing different PC (or PC like) based control systems. In other words we are comparing some large company's soft logic system (there are several brands) combined with Windows NT, versus the "Linux PLC" plus Linux (or some such similar combination). I wasn't aware that anyone's soft logic system was recommended for applications where it was required to provide safety related functions. We can hardly condemn a soft logic system if someone applies it to a purpose for which it was never intended. If we dispense with the safety issue, then criticism of the "Linux PLC" or other similar open source projects really centres around quality, reliability, features, support, training, documentation, ease of use, etc. It is rather a bit premature to judge it on these points. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Likewise, you have completely missed ours. I would be happy to pay the $3000+++ price tag for RSView, WonderWare, or whomever if they did not lock me into their proprietary systems!!! I would smile while cutting the PO if I knew that the package I bought was able to communicate optimally with everything in my plant. Not "it can do it with these extra converter modules", not through some crippled driver that RSI licenses out, but actual plug it into an ethernet, assign an IP, and away it goes. I agree that there are overhead burdens involved. You still cannot convince me that I got good value for my PCMK card and cable. The card was $1300, and the cable was just under $300. This is for what basically amounts to an RS-485/422 comm card. I worked for allen bradley for a year, in downtown Milwaukee, in a line supervisor/technician position (SMP pilot lab, 6th floor, 2nd shift for anyone interested). I can tell you right now that their overhead is in the layers of management. R&D is slow, if not stopped. From Don Davis (Rockwell CEO) to the line operator there was 9 "layers". The company is literally staggering under the weight of it's management (check YOUR stock holdings). Those that object to pricing object to things like the $1500+ comm module. This is literally less than $100 in parts. But they can justify it because they purposely make their communications incompatible with anything that is not made by them. And that is the crux of all of our complaints. Just make the hardware communicate. No offense to Curt, but I honestly believe that if I could take a PLC-5, and plug it into a network with a Siemens, an Omron, and a Modicon, and have them all send data back and forth with no jerking around (heck, if it was possible at all it would be a huge leap forward), my interest in the PuffinPLC would probably decline. The promise of his group is having something, ANYTHING, that does not have the primary objective of locking me into 1 hardware line. ---------- you are avoiding one critical issue with "open" >source software....RESPONSIBILITY, safely etc. I am not saying it is unsafe, >I am saying that the Rockwell's of the world have a huge base in liability >insurance ----------- You spoke of RESPONSIBILITY in your original post. If it was not intended to imply that open source would be harder to sue than shrink wrap (which I still maintain is a false statement), then what exactly did you mean? I would actually feel safer being able to examine the core system files to determine why the application just dumped and the processor locked. When this happens to a SLC, and you actually waste the time to call it in, they just tell you that you did something wrong, or it is in a noisy environment (no kidding, it's a production area), or the phase of the moon was wrong, or some other run around that basically says "We are still selling lot's of them, so it isn't bad enough to worry about". &lt;/rant> In summary, The point isn't who has more overhead. The point is that nobody is willing to unlock their communications enough to let their equipment compete on merit rather than installed base and lock-in. And that is really *THE* point. If they had to compete on merit, they are afraid they would lose. (any of them. They all have the same mentality.) --Joe Jansen
 
H

Heavner, Lou [FRS/AUS]

Joe Jansen posts: ... In summary, The point isn't who has more overhead. The point is that nobody is willing to unlock their communications enough to let their equipment compete on merit rather than installed base and lock-in. And that is really *THE* point. If they had to compete on merit, they are afraid they would lose. (any of them. They all have the same mentality.) LH replies: Perhaps, but one of the downsides of closed proprietary designs are that they are expensive to "unlock", even if they are the most competitive in the market. It is sometimes a challenge for vendors to allow different generations of their own products to communicate. And I'm not sure end users are ready for all their current systems to be abandoned by vendors designing new truly open systems from the ground up. Technology can move forward as fast as possible, but adopters of new technology still have to justify the purchase of new technology. I don't disagree with you, only that there may be a feasibility component to the willingness argument that goes beyond fear of commoditization or merit based competition. Regards, Lou Heavner Emerson Performance Solutions
 
R

Ralph Mackiewicz

From the ARC News Wire of 9 Feb 2001. The title seems to contradict recent comments made in this forum. Might be interesting to see what the survey results are. Regards, Ralph Mackiewicz SISCO, Inc. > >>ARC Survey: Change Is the Constant in the HMI Market > > ARC Survey: Constant Change in the HMI Market > > The only constant in the HMI software market is continuous change. As > the needs of end users and OEMs evolve, their HMI software needs and > requirements also change. Just ask yourself what are the most > important HMI software attributes? What type and level of services are > required? What are the operating systems of choice? And what future > requirements will be demanded of the next generation of HMI software? > ARC would greatly appreciate all end users and OEMs who utilize HMI > software to take a few minutes and answer some brief questions that > will help ARC define those future HMI software requirements. As a > reward for all those who participate, ARC will make the results of the > survey public at no cost to all participants. > > To take the survey, click below: > http://www.arcweb.com/websurveyor/wsb.dll/ARC/HMI.htm >
 
Hi Joe: Proprietary systems are here to stay - until such time as someone can determine how to fund the cost of development and maintaining the open software concept. What would you say to a different approach? Preparatory software at the lower level that endows the I/O of any manufacturer with intelligence during detail design or plant auditing. Primary and advanced control solutions as well as business solutions could then be generic and distributed - automatically by function, service, process, plant etc. The lower level software may also be capable of communicating from one control system to another as it forms the common mode between them. Would something like this be of interest? Bob Pawley
 
At 10:29 AM 2/8/2001 -0500, you wrote: >No offense to Curt, but I honestly believe that if I could take a PLC-5, >and plug it into a network with a Siemens, an Omron, and a Modicon, and >have them all send data back and forth with no jerking around (heck, if it >was possible at all it would be a huge leap forward), my interest in the >PuffinPLC would probably decline. The promise of his group is having >something, ANYTHING, that does not have the primary objective of locking me >into 1 hardware line. Too bad the VME based PLC's, such as the PLC-VME or the GE 90-70 or the old TI/Siemens 565 don't get more market focus. What an excellent idea. An open backplane with a standard PLC processor. Even better, I think it could share the backplane with a PC. Vendors could mix and match I/O cards, especially useful for motion control... Too bad they cost so much, I guess that they don't sell many. I have noticed that most VME motherboards command astronomical prices. Better yet, if the PLC vendors could agree on a standard RTOS, then even the processor cards could be a commodity item. Vendors could sell ladder logic engines... OEM's could write their own control software and run it on a common platform. I know that this idea has been around for a while, but it never becomes very popular. Why? Actually, I think I know why. The major vendors profit margins would shrink as their prices drop and development costs "maybe" go up. I wish that some of the major US based PLC vendors, there still is one, isn't there, would listen. We do not necessarily need "PC" based controls, IMHO, if we had another style that was easier to fit into a control panel and wire I/O to. This is not about Windows or Linux. This is simply about using open standards that already exist. They must be simple (Linux is not) and reliable (Windows is not). Sorry, those are my opinions. I'm sure that at least some of you will agree. Lets say that Compact PCI was chosen, along with some OS that was simple. Many real time kernels, such as AMX or C-Executive would work nicely. Both of these have source code available, I believe. The source would not be available for free, but for a reasonable fee companies could invest in it. The Compact PCI prices would need to be priced like a mid sized rack based PLC. STD bus would have worked, but it is obsolete. This used to exist in small doses, but no big vendors ever jumped on the bandwagon and put money behind it. It is too bad for the users that they do not. The first company may get some great sales, at least until the others catch up. Please do it!!! Well, time to wake up now. Bill Sturm
 
J

Joe Jansen/ENGR/HQ/KEMET/US

Bob, If I were building an entirely new plant, probably. My problem, however, is supporting many different brands of PLC throughout several plants. What I am talking about is, as I mentioned earlier, having AB release the spec for DH-485, as an example. As other manufacturers rushed to support communication in this format, I could begin tying my micrologix1000 to on Omron PLC for data exchange. Then, my Modicon or Siemens could jump into the loop and harvest data from the rest of the line for reporting upstream, etc. etc. etc. I need something that will work now with what I have. I can justify a new comm module for several PLC's, I cannot justify (nor would I try) ripping out the entire control system to replace it with the latest distributed control, open- ethernet buzzword, buzzword, blah blah blah... --Joe Jansen
 
D

Dave Ferguson

Although this has gotten way out of hand, and I promise this is the end from me......... Welcome to free enterprise.....If you drive a Ford, a Chevy front brake assembly will not work on it.....If you have a Maytag washer, a GE dryer part won't work on it..........Yet you continue to buy $25,000 Dodge trucks, what would the economy be like if there was only the "government correct" standardized car version........about a 2,000,000 worker unemployment over night. I think that all cars should be free and only my friends and neighbors should work on them for me because in this world you want......noone has a job anymore. I work in the paper industry and this kind of opinion reminds me of the "tree hugger" who wants to save my forest while living in a wooden house, or wants to stop oil drilling while driving to work.............or thinks that slaughter houses would be outlawed, while eating a hamburger. Give Microsoft a break (substitute Rockwell, Daimler Chrysler, GE etc.), this is the reason this economy has grown, after all, what do you want this "standardized" software for.......so you can make your proprietary product, cars, washer/dryers, golf clubs, and widgets better................... I just read 50 e-mails concerning the downfall of the automation market due to "hitting the wall" on diminishing returns, yet your goal is to "co-op" out the industry and give it away. Guess what happens next...........someone else thinks you should give away free and open whatever it is you specialize in......and I can't wait to hear you whine............. Be careful what you wish for........... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation
 
C
Hi Bob I'm not sure I understand how publishing the source would cost any more. Open doesn't mean that you can't sell it. Could you expand on your other idea, I'm confused. Regards cww
 
S

Steven Landau

There is a system like this on the market. The Altersys Virgo2000 is a bundled ISAGRAF IEC1131, with a HTML based MMI. It can be run on a variety of Platforms from a White Box NT, to AB's open controller, to a Diskless Linux Box. It has I/O drivers for many networks. Take A look. I haven't had a chance to use it, I have some Modicon and AB projects going right now, but when I get to choose the platform for my next project it will be this one. S. Landau SPEC
 
M

Michael Griffin

At 20:34 08/02/01 -0500, Bill Sturm wrote: <clip> >This is not about Windows or Linux. This is simply about using open >standards that already exist. They must be simple(Linux is not) and >reliable (Windows is not). Sorry, those are my opinions. I'm sure >that at least some of you will agree. > >Lets say that Compact PCI was chosen, along with some OS that was >simple. Many real time kernels, such as AMX or C-Executive would >work nicely. Both of these have source code available, I believe. >The source would not be available for free, but for a reasonable fee >companies could invest in it. <clip> Actually, with a good system design, I don't think the hardware needs to be standardised. The OS could hide the hardware implementation details from the application software. This is in fact exactly what a well designed OS is supposed to do. This would allow tailoring the hardware to particular applications and price targets. The problem with the 'PC' model is that it is usually based on proprietary software running on commodity hardware. It isn't really the hardware which is the root cause most of the problems people complain about - it's the software (including the operating system). The software is the reason you can't take a PLC program out of one type of PLC and load it into another, or why two different PLCs won't talk to each other. Soft logic systems running on PC hardware are at heart really no different in this respect. I think what you really want is commodity software running on proprietary hardware and using common communications protocols. I wouldn't dismiss Linux or other similar operating systems as "too complicated" either. If a stripped down version of it were packaged with the hardware, you would never need to see it except for the utility which lets you download your application. An OS exists to provide services to the application software. It doesn't by itself provide any value to the user, the application does. The best operating system would be one which is completely invisible. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
Curt: What I'm suggesting is a program that endows each and every I/O with all data, structure and knowledge of the device, loop, plant, service, process conditions and project - in effect making the I/O intelligent. This approach would mean that I/O addresses, control software language and other soft incompatibilities would move into the background. The designer/integrator would then be free to deal with issues on the basis of device, loop etc. letting the program handle the soft details. Bob
 
Joe Could you justify a control system audit using a system that would record and organize a model of the existing control system from device to I/O? This auditing of existing control systems would be 10 to 20 times less costly than the same function using a drawing based system, This would replace the plant's old drawing system with a dynamic, easily learned and continuously accurate model. It would also have the capability to perform the multi platform integration that we seem to be talking about and make it much easier to apply and change control strategies. Bob
 
B

Brendan Larkin

An austrian company called AutomationX has developed a Linux based HMI package which has an integrated soft PLC. This is then ported across to Windows NT/2000. The key is to continue HMI development in the Linux environment, which is open by design and concentrate on data transport to management systems (whatever platform they may be). See www.automationx.com Brendan
 
Top