I am concerned about a lack of advances in PC based HMI/SCADA. As I see it, the vendors of the most heavily used HMI products have shifted their focus away from developing solid, continuous-use software for monitoring and control. They now seem possessed with the concept of "enterprise integration". While this is important, it is offered at the expense of basic HMI capability. In fact, it seems that significant HMI software enhancement stopped some years ago. The number of innovative features added in the last five years can be counted on one hand. Support for OLE technologies (ActiveX Controls, OPC) and some vendors selection of VBA as a scripting language are examples (honorable mention to Wizards and Dynamos). The bulk of the HMI/SCADA market is held [captive?] by two or three vendors that continue to offer largely cosmetic changes to the same software. Meanwhile, industrial automation installations are growing larger, involving higher I/O counts, and a larger number of controllers and networks. Technology as a whole is advancing at an ever accelerating rate, and in particular, state-of-the-art software tools and technologies are experiencing an almost complete shift from where they were just a few years ago. I fear the automation community is saddled with HMI solutions that are not keeping pace with the growth in automation systems, advanced software technologies, and exclude the use of "enterprise integration" solutions not controlled by the HMI provider. With this as a premise, I hope you will engage me in a [lively] discussion focusing on the future of HMI and SCADA. How do you feel about your choices for HMI today? Do you value the "enterprise" solutions from these vendors? Have you used or seen an HMI offering truly innovative features? Am I completely wrong? Is HMI just a word processor now, and all you want is to type your document? Where do we go from here? Thank you, Jeff Dean firstname.lastname@example.org For the sake of full disclosure, I am not an employee of any HMI vendor, though I have been in the past. My work still involves automation - software development for integrators. Additionally, these are my opinions and they do not necessarily reflect those of my employer, or anyone else for that matter. :)
> HMI solutions that are not keeping pace with the growth in automation systems, advanced software technologies, and exclude the use of "enterprise > integration" solutions not controlled by the HMI provider. > Phew - that is a refreshing challenge to the high-blown PR the trade press is schmoozing us with. > Have you used or seen an HMI offering truly innovative features? Am I completely wrong? Is HMI just a word processor now, and all you want is to type your document? Where do we go from here? What basic HMI capabilities and innovations do you want to see? I can think of many changes to the software and its support model that I would like to see, but I am hard pushed to name those I could persuade the plant owners to pay for. I do see licences and support options getting cheaper and simpler (or if not getting cheaper at least bundling more integration options in with the licenses.) This "innovation" is a bottom-line benefit for the owners. David Corking email@example.com ISA Member in a personal capacity
In my opinion, Jeff you are right. The underlying capability of most control systems, 10 years ago, was "retarded" (I could say a lot on that). See, today, people are getting lazy and the crunching inside is object oriented. The counterpart of it is that more objects to be moved, more holes are needed like Microsoft (Swiss cheese). In other words, all these nice goodies are only to please management. But not to furbish designers. In 1980, there was the Micon multiloop. I believe no one could have exhausted its loop capability. We could do endless fuzzy strategies. Well, big ones (no name) succeded in killing it. In 1975, I visited a completely automated cement plant (and you know there is a lot in it). It had colored CRT. It was what we called minicomputer based, all done consistant inside. In 1990, that same company evaporated like Micon above. Whose fault f....n management: easy to please). ISA in my 30 years, it was so little to me (sorry). I bet Jeff, most software cats at say (no name) need going back to "numerical recipes". Let me know the best one in your mind. <firstname.lastname@example.org>
On January 23'rd, in response to my inquiry about HMI innovations, David Corking asked: >>What basic HMI capabilities and innovations do you want to see? As the saying goes, be careful what you ask for -- you just might get it. I wouldn't have asked the question if I didn't have a plethora of ways to improve todays HMI. Not modest improvements that add a handful of features that a few users will take advantage of, but across the board changes that will accelerate HMI development and over the long term reduce maintainance costs and improve operator effeciency. Capabilities that don't require a technical leap of faith, but those that can be built on reliable existing technology, and tools. To realize these advantages will require advances in both the development and runtime aspects of HMI. Reducing development costs means improving the HMI developers experience. Make his or her job one of creating a great tool for the plant staff as opposed to droning through "double-click, select tag, click ok, repeat." Reducing maintainance costs means, not having to stop production to modify existing or integrate new displays. It means improving documentation of the completed HMI (not just screen shots and tag lists which are marginal use to anyone). And it means creating tools specifically with "I started 2 days ago and have to fix this 5 year old system developed by a systems integrator that dissappeared" in mind. Also improve the runtime environment by improving the speed and quality of information presented to the operations and maintainance staff. An HMI is more than just pretty pictures or cartoons; It's a critical view of what's happening in your facility. Everyone needs to be able to train on it without impacting production, and risking equipment or lives. So finally an HMI should be a training tool and should, out of the box, support a training mode. But that doesn't give any specific features or technologies, simply lofty goals, right? Well, let's go a step further on a couple of points. -- NETWORKING -- * I want redundancy - if one goes down I want the other to pick up automatically with minimal (sub-second) recovery time. * I want syncronization - All nodes should display the same values and alarm status. I have seen too many two node installations of leading HMI products where a secondary node lagged behind the primary by seconds. And when I ACK an alarm on one node, I want the other to display my acknowledgement post-haste. * I want server discovery - Install the run-time, start it, and it comes up with displays reading live data and displaying alarms. No playing games about which machine is the "server" so that one machine isn't overloaded, and no need to hang yellow sticky notes off each machine so to try and remember its cryptic name. * I want security - An HMI must be designed for reliability. Not simply crash-proofed, but support for system and data resialiancy and protection. This should start with encrypting everything that goes on the network and validating that data received from the network is (1) coming from where is should be and (2) complete and accurate. No scare tactics, but an honest concern: how hard would it be for someone to get into your facility, plug in a laptop computer, and start siphoning off data. Can you say with absoulte certainty that it is 100% impossible for someone to penetrate your plant network from the internet? -- SCALABILITY -- * I want more power - An HMI that says, without a moments hesitation that they can support todays largest installations. Not one that hemms and haws about 32,000 or 64,000 tags, but one that will fit my needs even if I need a million tags. An HMI can be designed in such a way that, tag counts don't matter anywhere but the device communications drivers. (I'll upgrade my server to move from 1000 tags to 1,000,000 - I'll conceed that) :) * I want unlimited client notes - An HMI shouldn't require me to upgrade my server every time I add new clients. I want an HMI that will support 200 clients (even though I may only ever use 2). Never let it be said I don't know what I want. And I could go on, but I've already started rambling. Do these features sound useful to you? Pie in the sky? Wishful thinking? Tell me though, what do -YOU- want in an HMI? Do you see any one vendor, Wonderware, Intellution, CiTech, Rockwell, ICONICS, etc. breaking away from the pack and taking an active role in building a next generation HMI, or are they sitting on their laurels? Yours, Jeff Dean email@example.com
Excuse me, I am a Spanish speaker and I am not so good in English. Well I will speak something now. I think that Jeff Dean is right. I will give my opinion regarding this topic. First, I will speak about my Software. I have called it SisPro, In that software the development time is too low, what you have to do is just add objects and modify its properties in a Visual Metaphor just like Microsoft Visual Basic or Borland Delphi. The developer have a group of basic objects that serves just for everything (if you do not believe that, then contact me and I will show you) from simple 2D sketches to 3D representations. The user do not have to program a single line of code, the only work that he has to do is create objects and modify its properties. (Just an additional note: I was seeing a SCADA Software from one company that I prefer not mention here. It is better to say that other person showed the software to me. The person was in trouble because the system was impossible to manipulate, a not ergonomical interface with many parameters, many steps, etc, etc. If you are interested in the firm or the software that I am mentioning here just write to my personal email and I will let you know). Regarding the communication, the user can define variables (named tags but all of you). Then define from what interface it will be imported, for example another machine, some PLC connected to the PC, a Hardware Card connected to one slot on your machine or whatever you can imagine. It has an open arquitecture, what you only need is a developed driver for that PLC, Hardware, etc. Regarding the number of tags, hahaha, that's a good point, I think that a software of that type must have not limitations, the only limit lay on the driver, if you have programmed a non efficient driver then you are limited in the numbers of Variables, just as a simple example imagine that you have a PLC capable to answer to a command frame asking for a simple word, but have another frame that can answer with n words. If you program your driver for receiving variables in a cache manner then it will work more efficiently. For the cache you can read words that are located very close at the same time, that's assuming that that two words at needed at that time. Regarding the interface I can tell you that the first time it was used in a Sugar Mill, the people there was capable of using the Runtime interface in just two days. It is very simple and intuitive interface but powerful at the same time. SisPro is capable of working as a Client and as a Server at the same time. And the only delay involved in the refreshing of a variable (tag) in a Client Machine is just related with the speed and traffic of your network. You must count also with a network topology capable of giving you redundancy facilities. For example suppose an RS-485 Network, from one machine you can read variables from two PLCS. From other machine in the same Network, you can read through a RS-232 interface the variables of one PLC. If the last Machine get frozen, then you will go on seeing the parameter of that PLC in the other machine connected from the RS-485 interface of the network. SisPro handles security in various levels, from the user point of view, there is one or many Administrators and one or many Users. You can define what outputs one user can modify. You define every user log, etc, etc. In the network the information is send codified, and other security aspects that I'll not mention here. Just another point that makes me laugh a lot, imagine that the company that it is using that software I have mentioned early in this message it is not giving the protocols to use with their controllers, can you imagine that, if I want information about OMRON Hostlink I can find it from OMRON, if I want information about AB I can find it from AB, If I want info from LG I can find it from LG, etc, etc. That info is just one click from my computer and a few minutes of download. Then a little of imagination and programming time and voi-la you have a beta version of your driver. I think that all of they are sitting in their laurels the ones that are not giving their protocols and the ones that are imposing theirs not evolving software. Just another thing that goes out of the scope of this message, does anyone knows if OMRON have some debugging facilities in theirs PLCs. I was using C200HX, HE and HG and there wasn't that facility. I am asking how a firm can sell a product without that facility when you can find in the market other products with it. I was contacting OMRON Canada, just asking if they want a Simulator for be used in theirs PLCs and I have not reply from them. The point that I can say here is that the problem with software arises from many points, ranging from SCADA and ending in development software and programming software. I was using the tool for programming another firm PLCs and when I tried to program just like the manual said, my program was not working, when I contacted them, they were giving no answer to my questions, can you believe that. That's another point bad documentation from products that maybe are brought to the market in a hurry, it sounds just like a Bill Gates syndrome in PLCs world, hahahaha!!! I was working with another PLCs software setting the Tx speed of a serial port, and then when I was trying to communicate with my program it was impossible, Can you imagine where was the buggy situation?, the first thing I though was that my program was wrong, no no no, it was the PLCs software. In the list of the combobox for selecting the speed, all the elements were sorted alphabetically, can you imagine that, 1200 was first than 300 for example, the program was using the speeds in the Index order and not what it was showed to me. Excuse me if I do not reply any message from the list directed to me, I am checking the list bimonthly, so if you want to get in touch with me write to firstname.lastname@example.org that's the address that I check more frequently. You can talk with me from 7:00 am to 3:30pm (GMT -05:00 Easter Time USA and Canada) through yahoo chat, hotmail chat or ICQ. I am always working outside so maybe at that time I will not be there, I am always from Monday to Friday from 7:00am to 8:30pm, but mostly I will be there all the time till 3:30pm. @ yahoo I am orelbigm @ hotmail I am orelbigm @ ICQ 103652640 Best Regards Orelbi
Hi Jeff The whole problem here is the proprietary model. Under that model the emphasis will always on what is good for the vendor with what is good for the buyer as only a necessary burden. They choose the platform you use, they choose the functionality provided, and they determine what you can do with it. When they are not busy obsoleting what you have to sell a new generation, they are chasing whatever crackpot idea Microsoft has regardless whether it is germain to you or automation in general. It sure seems to me that the direction is being set by people who have nothing to do with my circumstances and who possess a vision that I am not a party to. They will only develop on the least reliable platforms available because "that's where the money is" and leave you holding the bag because it crashes frequently. They are obsessed with office applications and despise the interoperability that a plantwide system really needs. From any rational engineering perspective, many of these decisions and choices are indefensible. But they are good minions of the Great Master Microsoft where all the money comes from. I'll bet they are chomping at the bit to announce that their factory floor packages are "".NET""!! compatible which is arguably irrelevant to all but a very few. Most here will argue bitterly with the assertion thsy are going the wrong way, but I would like to propose an alternative. Suppose there were a package developed by integrators and users. And, suppose that as each specialty and idiosyncracy were addressed, the changes were made available to all so that each problem and feature only had to be developed once. And suppose that it ran on many platforms so it was scalable without silly per seat or per tag costs. And suppose it ran on the most stable and reliable platforms. If you want a feature you would not only be allowed but encouraged to add it. If you need to know exactly how something really works, you would have the source and a wide network of developers and users to help you. Now suppose the developers tried very hard to work with every system and piece of equipment you may encounter. Would all this do a better job of solving your problems? Now suppose it was all free and you got the source and the latest version with a smile and you could put it on as many machines as you like, legally. This is what we of the Linux PLC project are trying to do for you and me and everybody. If we get your support and help we can do it. And I defy any of the naysayers to come up with a reason it can't be this way. If it sounds better than the alternative, come on over, we've got a lot to do. Regards cww
> And I defy any of the naysayers to come up with a > reason it can't be this way. If it sounds better than the alternative, come on > over, we've got a lot to do. Your argument against the corporate fashions is very persuasive. There must be enough money in our industry to give PuffinPLC the same support Michael Tiemann got for the famous enterprise he started in 1989. Can you get your hands on it? (If I remember the story right the product already existed, and they got the development money to continue by earnings from consulting and customizing for hardware firms.) David
Curt, I have spent quite a bit of time on the LinuxPLC project web site reviewing archived discussions and the design. Having been a member of two HMI development teams and a SoftControl engine development team (actually 3, but that's a story for a different day), I have a keen interest in what ya'll are doing. It seems the scope of the LinuxPLC project overlays my skill-set quite nicely. But, more on that in a minute. I agree whole-heartedly that proprietary models have limitations and that vendors will seek to build and sell product that maximize their bottom line. However, I don't fully buy into the idea that this will always run contrary to a buyers needs. I do expect when the good of the buyer is sufficiently neglected by vendors that rules of the free market will have an impact. A dissatisfied market will be ultimately served by new solutions from new sources addressing their demands. (new sources being OpenSource, or new vendors with proprietary solutions) Simply put, I'm wondering when that market upheaval will occur in HMI/SCADA, and what the new solutions will do to displace the likes of Rockwell, Siemens, Wonderware/Invensys, and Intellution/Emerson in HMI/SCADA applications. In respect to Microsoft's technologies, I will say that they have enabled creation of incredible software (some crummy software too) and been instrumental in making the PC a tool that can be learned and used by a vast majority of the population. Good or bad, devilish or angelic, they offer the most widely used operating system in the world. Their platform allows developers to create amazing software to address a great expanse of problems. But, not everything they do is good for Industrial Automation - some of it is though. As a developer, I see substantial technologies in .NET that must be looked at. Is .NET good for Industrial Automation? I don't know yet. I think the Common Language Runtime (CLR) if applied to IEC1131 might have an interesting impact on SoftControl, but that's a lab exercise. The CLR may not allow for real-time execution. The new .NET distributed services will change the way component software is distributed and how it communicates and may have a significant [negative] impact on CORBA. Good or bad? Again, I don't know yet. I'm looking very close at the technology because (1) it is the most ambitious drive to change software development in years (2) it appears to offer new, easier, robust solutions to existing problems and (3) it's simply from the most intelligent (in a software development capacity) company on the globe. I would be remiss to pass it off as a bump in the road, and I would be equally remiss to not take into account the needs of industrial automation and how the use of a technology will impact users of my software. Back to Linux PLC. I see interesting possibilities with an OpenSource soft control engine to educate engineers on soft control, and further expand the use of PC's for control. (an application I believe strongly in) I have seen the belly of the PLC beast, and didn't like all that I saw. To date my reluctance to participate is driven by personal objections. I've spent years advancing my skills and continue to spend countless hours keeping them up to date. I want to continue to develop industrial automation software for a living, because I love the work I do and have done. I am thrilled every time I see my products installed in the field. And I love knowing that users are happy with these tools and that it is enabling them to create all manners of products. Ultimately, it comes down to paying the bills, and OpenSource just doesn't do that. So while I wish you great luck with the project, I hope ya'll don't do too good of a job and reduce the need for my skills developing shrink-wrap Industrial Automation software. :-) Yours, Jeff Dean email@example.com
Hi Jeff A well reasoned and thoughtful response. I will not argue that the proprietary model is entirely bad. To the extent that the rewards are earned, I have no problem with it, indeed I have and do write software for money. We all have bills to pay. I applaud it while it is good and the costs are in line with the value delivered. We all know a fair deal when we see one. TO all the rest who wonder what my problem is: It's the excess that bothers me. We have several things in this market that are clearly out of wack, where competition doesn't seem to restore balance. Where people are able to gouge and eliminate choice and ignore quality and service. Where customers are locked-in and this is exploited to their detriment. No one here can say in honesty that this isn't happening. There are other things that make it clear that decisions are being made not to further the state of the art or expand the market or other healthy tendencies but for less than noble intentions. I am a conservative by nature but not to the point where anything goes to make a buck. At some point it goes beyond good business or even hard business to something less honorable than deserves the name business. We used to use terms like profiteering and chiseling and a host of others to describe practices that go over the line with the purpose of taking advantage of the other party in what should be a fair transaction. Now it seems we no longer recognize that there is a line. Something is wrong when I cannot buy a PLC that doesn't require that I buy and install software from only one company, Microsoft. That is not competition. There is no choice. Something is wrong when no two companies can ever use the same means of communication or the same protocols or the same anything. This is not for purposes of improvement or to provide a real advantage to the user or integrator, indeed this "Tower of Babel" does great harm in limiting the size and scope of projects and costs huge amounts of wasted time and energy in the name of limiting choice. Sure you can pick from a hundred systems, but God help you if you need a piece from one system and and try to use it with another. This is not competition, this is not choice This is a subtle form of customer warfare, to waste their time for the benefit of the vendor. Something is wrong when you have to buy upgrade after upgrade which causes chaos and a great deal of intangible expense simply for bug fixes and to correct flaws in the original purchase. Yes this happens in software, but it's wrong when it's a profiteering strategy and vigorously persued with forced obsolesence. If you think these are all good strategies and "that's business" I doubt that I can sway you anyway. We at the LinuxPLC project are working to provide a choice and an alternative that is customer and solution provider friendly and a change of pace from all that type of "business" We don't seek to destroy it, we seek to provide an example of what can be done if people cooperate and work together. If we can provide a choice, you can then decide who you would rather do "business" with. Regards cww
Curt: I have finally had it. Your endless span of Microsoft and others.........welcome to free enterprise (that ought to get you a spamming)......the bottom line is...... Users want common functionality amongst programs as well as can be. In this case F5 is refresh, CTRL C is copy etc. whether in excel or RSLogix 5. This is what I want....so quit speaking for the masses. Are there a million things that Microsoft does wrong....sure but my Grandfather had a saying and it is still true today and I will add one of my own.... He used to say...."I have never been given a job yet by a poor man, only by a rich one" and he meant he never complained about someone getting rich because it drives the economy. This is contrary to your anarchistic view of the world. My saying is "Everybody thinks the boss is an a**hole, yet given the oportunity, most want to have his job" this is the same mentality you come across with, whether intentional or not. My company uses Lotus Notes and if I hit F5 one more time to refresh (F9 in Lotus). I think I am going to scream.....Microsoft may not be the best of breed in the world in any or all areas but at least they are a defacto standard that I can usually count on and to be honest, that is all I care about. The world isn't out to get you Curt..........honest. Dave Ferguson UPM-Kymmene Blandin Paper Company DAVCO Automation
Dave, A quick re-read of Curt's post seems (to me, anyway) to be directed more at Rockwell/Omron/Modicon/Siemens...ad naseum. These are the companies that refuse to communicate, lock you into proprietary solutions, etc. You are correct in stating that for many, common functionality *IS* king. That is the problem with the PLC vendors today. I want to have a comm port ( or even several ports) that I can plug a cable into a SLC 5/03 on one end, and a Siemens S7 on the other end, flip a few bits for protocol, baud rate, or whatever, and have them start talking. While I hold no love for MS, they have done something right at some point anyway to get into the position that they are in. Common function on the OS level is good. You are right in that. How about extending it into our world a little bit? (one of) The (ambitious) goal of the L-PLC project is to provide interoperability and communication to as many other systems as they can without getting into trouble. I think that this is a great idea. In short, you are right. Common function is good. I just want to see it in more places than the desktop. --Joe Jansen
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
In response to Dave Ferguson <ferguson@GRANDNET.COM>: <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.
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
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
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". </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
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
Lou, I agree with you in some cases. I would bet the proverbial "dollars to doughnuts" however that if Rockwell /Allen Bradley were to publish their spec for DH-485, which is supported by every processor in the SLC-500 line, they would see many other PLC manufacturers scramble to support it. The competitors would do so in order to be compatible and get into some AB Only shops. Likewise, it would allow AB to get some Micrologix processors or even SLC's into the Modicon, Siemens, etc only plants. And I think that if AB took the first step in this way, everyone else would soon follow. Imagine if AB, or whomever, developed a dumb-ish I/O controller that lived on DH-485, and a remote processor just sent I/O commands that this "brick" would perform. (Sounds far-fetched, perhaps, but I have used ML1000's for just this purpose). Now AB could sell these little DH485-I/O bricks to people running a Modicon, et al. This would expand thier market in this area. Although to be honest, if AB did this, they would probably see their overall market position decrease, as their SLC line is overpriced in comparison to other offerings. I will be the first to admit that when I spec an AB processor, it is because of communication compatibility with existing equipment and not because of anything that it can do. I guess they achieved their objective, haven't they?? As we said at the last place I worked: "Allen Bradley. You might be able to buy better, but you sure won't pay more!" --Joe Jansen
>As we said at the last place I worked: >"Allen Bradley. You might be able to buy better, but you sure >won't pay more!" The SLC may be somewhat expensive, but it is my PLC of choice, as long as I am not paying for it. It is fast, very reliable, and easy to use. Can anyone recommend a PLC with an overall better design than a SLC 500? Bill Sturm
Your request for a PLC with a better overall design than a SLC is very open ended. I prefer to use a Modicon Compact than an AB SLC. Why - I'm more familiar with it and it does the job. It also is reliable, fast and easy to use - as are the offerings from GE, Siemens, etc, etc I think it comes down to: 1) will the hardware do the job you need it to and, 2) are you familiar enough with the product to use it effectively without having to jump thru hoops 3) is support readily available at a reasonable price. If ACME made a PLC and you used it frequently and worked out/around its bugs/features, I'm sure you would also say it also is reliable, fast and easy to use.
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
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
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
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
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
* 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. Suggest you look at some of the Network Management applications and/or Visio 'Reverse Engineering' tools. Essentially, what you are asking for is that each software package or each component publish its meta-model and interface points. I think all you are asking for is that the Control System vendors catch-up to common practice in the IT world. I should be able to plug in Visio into my PLC network, and have it 'automatically discover' all of the PLC, all of the modules, and all of the ladder programs. In essence, each component should be able to describe itself. You don't need to publish Source, all you need to do is publish for meta-models, and the interface, and expose them to user-friendly tools. -bill hullsiek, software engineer
Hmmm...... Sounds like Jini, or Lon was doing sometthing like this. MS too to compete with Sun. Problem : What about non-compliant devices, old devices, and Linux based OSS projects that won't be able to buy their way in? Most of these schemes live in a dream world where everything and every vendor cooperates. And the word proprietary comes to mind. With public ownership to eliminate advantages for one vendor or another, a scheme like this might be doable going forward. The trouble with the status quo is that a week after you release it, there would be half a dozen incompatible competing schemes. How do you get enough vendors and users to support it to make it work? Regards cww
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
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
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 firstname.lastname@example.org **********************
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
> Although this has gotten way out of hand, and I promise this > is the end from me......... Everybody likes analogies, but they usually aren't very good. > 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. Good thing I can drive my Chevy on the OPEN highway. It would really suck if I could only drive it on the Chevy highway, and couldn't drive it on the Dodge Highway. Mark Blunier Any opinions expressed in this message are not necessarily those of the company.
But sometimes analogies may be pretty good. A small manufacturer who outsources his service needs looks like this. He might even want to consider lease vs buy options. But a larger organization, say for example a major airline, doesn't buy and replace one airplane at a time. All of the commercial airplanes fly the friendly skies and can communicate with air traffic control. They have even standardized internationally on the comm protocol. But an airline like Southwest that buys only Boeing 737's has the advantage of standardization at the maintenance and operation levels that another airline who buys many different planes from different companies enjoys. Of course, you might feel that Southwest is being shortsighted and locking themselves into a proprietary product. It seems to work for them. Ditto for a laundromat... Regards, Lou Heavner
(Lou wrote) But sometimes analogies may be pretty good. A small manufacturer who outsources his service needs looks like this. He might even want to consider lease vs buy options. But a larger organization, say for example a major airline, doesn't buy and replace one airplane at a time. All of the commercial airplanes fly the friendly skies and can communicate with air traffic control. They have even standardized internationally on the comm protocol. But an airline like Southwest that buys only Boeing 737's has the advantage of standardization at the maintenance and operation levels that another airline who buys many different planes from different companies enjoys. Of course, you might feel that Southwest is being shortsighted and locking themselves into a proprietary product. It seems to work for them. (Joe) --Please excuse my limited knowledge of the airline industry-- But someday, if for some inexplicable reason, Southwest decides that they want to buy an Airbus, it will still communicate with the same traffic control tower as the Boeing. They will not have to replace all the radio's on the boeings or the Airbusses in order to have cockpit to cockpit communications. That is the difference. I don't expect the hardware to be interchangeable. I don't expect to pull the processor out of a SLC and pop a GE 90/30 into the backplane and have it start talking. But how about an ethernet jack on a SLC and an ethernet jack on a GE that speak the same language? I don't want the components to be indistinguishable. Quite the contrary, I would like to see them leaping over eachother with improvements. I just want to be able to buy the brand that best suits the application without paying huge penalties in communication and data collection, etc. (Lou) Ditto for a laundromat... (Joe) My argument applies here also. If I take out the Maytag and slide in a GE, the electrical and water connections all still work. I need not wire in a different voltage, different plug, etc. Likewise, I need not change pipe size, faucet connections, threads on the hoses, etc. It is interchangeable AT THE INTERFACE LEVEL. That is the key point I want to make. What happens on the processor side of the connection is whatever they want. What happens on the cable side, though, should be standardized, so that it doesnt matter whose processor is connected to the other end of the cable. --Joe Jansen
(Joe) >My argument applies here also. If I take out the Maytag and slide in a GE, >the electrical and water connections all still work. I need not wire in a >different voltage, different plug, etc. Likewise, I need not change pipe >size, faucet connections, threads on the hoses, etc. It is interchangeable >AT THE INTERFACE LEVEL. That is the key point I want to make. What >happens on the processor side of the connection is whatever they want. >What happens on the cable side, though, should be standardized, so that it >doesnt matter whose processor is connected to the other end of the cable. Ever been to Europe or is this perfect world you seek only in the US......... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation
---------- Forwarded message ---------- From: "Blunier, Mark" <Mark.Blunier@Williams.com> > Although this has gotten way out of hand, and I promise this > is the end from me......... Everybody likes analogies, but they usally aren't very good. > > 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. Good thing I can drive my Chevy on the OPEN highway. It would really suck if I could only drive it on the Chevy highway, and couldn't drive it on the Dodge Highway. >>>>Start Joe Jansen Likewise, I can purchase parts from aftermarket sources. I do not need to purchase my front brake assembly from my Chevy distributor, etc. My Chrysler van as Ansco wipers, GE headlights, etc. These are commodity parts, priced reasonably, I have many choices ranging in quality and price, and yet, inexplicably, Chevy and Ansco are both profitable. ******* 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. ******* I am not a tree hugger, mink releaser, PETA member, vegetarian, etc. although I hardly see where that applies. You make paper. Your paper is competitive to other paper producers. If someone doesn't like your paper, they can go to IP and buy from them. Doing this, however does NOT require the user to rip out all of their printing presses to effect the change. That is the difference. If your paper is going to be purchased, it has to consistently prove itself on the open market. This is what capitalism is about. If I have a better product than you, and it is priced better than yours, I will sell more than you, and you will adapt or go out of business. The problem is that the automation vendors have installed artificial barriers to change that defeat this basic principle, putting themselves into Ivory towers that now are beginning to crumble. Now, if I have a better system than you, and it is priced at the same or lower level than yours, you still win because the customers would have to invest far more to change than what they would see in savings/improvements by using mine. ******* 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................... ******* Actually, I make capacitors. Not exactly proprietary. The only reason we keep our lead in the market place is because we invest heavily in product improvements, new processes, etc. If I need to continually prove my product to be "best of class" in my field, why shouldn't they? ******* 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............. ******* Boo-Hoo-Hoo. This problem is self imposed. I do not upgrade any existing equipment because, frankly, there isn't anything worth a damn out there that would compel me to. If AB came out with something truely innovative, though, I would start to retro-fit. Case in point: The SLC 5/05 processor. Communicates over Ethernet. When this rolled out, I retro fitted all of the lines in the plant I was at to include at least one of these. Had they been priced realistically, ($3000 is NOT realistic for a 5/04 with a 10BaseT daughter board), I would have included several in each line. My point is that if the automation leaders would do something compelling, the retro fits would start to lift us out of the slump. Jim Pinto: No, I have not spent much time pursuing this train of thought. This is just my take based on my corner of the world. I could easily get retro fit approval for compelling systems. What would do it? Well, since I am LOCKED IN to using AB SLC equipment, I will follow that. How about a 5/06 processor which contained the capability of a 5/05, and integrated an x86 based pc, all backplane communicating, that could host RSView, WW, LinuxPLC, or whatever. Some shared memory would slide data back and forth. Form Factor might be an issue, so make it a double wide card, or possible hang it off the left of the rack, and incorporate some bracketing/cabling to move the power supply over a bit. I would even live with an extra "black box" if they could just get it to talk properly using a big mapped I/O, or specific N, F, ST, A or whatever file table rather than those awful M-files. Anyway, just an aside.... Dave: Nokia, etc. pretty much wants us to give our stuff away for free anyway. They can, at anytime however, go to Panasonic and buy capacitors. These are the same size, following an **industry wide standard**. Even with this standarad, we are not only in business, but posted record profits AGAIN last quarter. How can this be? The automation model "proves" that we must use incompatible size, capacitance, shape, and anything else that we can to lock our customers into using only our product. And even despite this "proven" model, our stock goes up, and Rockwell, et. al. doesn't. I think there might be something to this industry standard thing after all... Anyway, I will wait for the anti-rant and flames to hit me. Thanks for the outlet... --Joe Jansen
Automation Listers : With all this discussion about how nice it would be, could be, should be to have standards, perhaps its time to refer the List to Pinto's Law of Market Confusion : C=P x V/U where C is the Confusion V is the number of Vendor's supporting more than one "standard" U is the number of happy Users and P is Pinto's Confusion-factor, which decreases non-linearly with time It's on the web at : http://www.jimpinto.com/writings/confusion.html Again, because of the low volume and fragmented marketplace (customized requirements) it is VERY difficult for any company to develop, or support, a "standard". Cheers: jim ----------/ Jim Pinto email : email@example.com web: www.JimPinto.com San Diego, CA., USA ----------/
Dave Ferguson wrote: > > 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. This is simple fearmongering, the great majority of the jobs in the automation industry aren't tied to platform choice And that's all we're advocating is real choice. Standardisation in the computer industry creates literally millions of jobs through the explosive growth that commodity computing has brought about. > 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. The auto industry is an excellent example of standardization. The big 3 have all experienced enormous increases in productivity by increasing commonality and reducing parts inventories. > 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. Except I'm not hypocritical. I don't use any Microsoft software at all and I am working hard on the solution to proprietary PLC use. I am fully capable of deploying automation without their content. > 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............. I am giving away what I specialize in.... www.linuxplc.org. What are you afraid of? > Be careful what you wish for........... > > Dave Ferguson > > Blandin Paper Company > UPM-Kymmene > DAVCO Automation I really suspect the motives of someone who opposes choice and criticizes an effort to act in the public interest. Even if we are misguided, we mean well. Peace. Regards cww
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 firstname.lastname@example.org **********************
An aside to the legal discussion in this thread. Who gets sued has nothing, repeat NOTHING, to do with who is responsible? And yes, I'm screaming! Regards, Phil Corso, PE Trip-A-Larm Corp (Deerfield Beach, FL)
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@example.com
Hi Dave > From: "Dave Ferguson" <firstname.lastname@example.org> > > Curt: > > I have finally had it. Your endless span of Microsoft and > others.........welcome to free enterprise (that ought to get you a > spamming)......the bottom line is...... > > Users want common functionality amongst programs as well as can be. In this > case F5 is refresh, CTRL C is copy etc. whether in excel or RSLogix 5. This > is what I want....so quit speaking for the masses. I am speaking _to_ the masses. I want only the best for them. I fear from what I read that many suffer from the Stockholm Syndrome where victims, in time, come to identify with and even vigorously defend their kidnappers. Because I don't use any MS software, I have a little more distance and objectivity than most of the population and I see them resigning themselves to treatment they absolutely wouldn't accept from GM or ATT or any other of their everyday vendors. Yes, standardization is a very good thing. I write about it a lot. And simplicity is beauty. What I am saying is that an alternate standard built with the purpose of treating people better and actually operating in their best interest rather that some megacorporation's interest, can provide all the same advantages that you attribute to the monopoly. Standardization without the tithing to Bill. And with the advantages that come from cooperation and sharing. And we'll give it to you. I'm really amazed at the opposition to that and the approval of the other. > Are there a million things that Microsoft does wrong....sure but my > Grandfather had a saying and it is still true today and I will add one of my > own.... > > He used to say...."I have never been given a job yet by a poor man, only by > a rich one" and he meant he never complained about someone getting rich > because it drives the economy. This is contrary to your anarchistic veiw of > the world. I often say the same thing, there's a difference between earning and extortion. But both can make you rich. I am not an anarchist, I am simply a principled capitalist. I do not believe that doing good and doing business are mutually exclusive. > My saying is "Everybody thinks the boss is an a**hole, yet given the > oportunity, most want to have his job" this is the same mentality you come > across with, whether intentional or not. Actually I liked my Boss, he left and I haven't rushed to judgement on the new one. > > My company uses Lotus Notes and if I hit F5 one more time to refresh (F9 in > Lotus). I think I am going to scream.....Microsoft may not be the best of > breed in the world in any or all areas but at least they are a defacto > standard that I can usually count on and to be honest, that is all I care > about. That much is obvious. > The world isn't out to get you Curt..........honest. With certain exceptions who email me idiotic threats, I'm inclined to agree with you. After all, I'm working to make things better. Regards cww
Wow... ...maybe this is why I usually avoid discussion groups. But it's a slow day at work & I figured I would read this whole topic thru. As a 10-year controls engineer who has worked with a variety of PLCs, DCSs & HMIs, (including of course plenty of Allen-Bradley), I am immediately suspicious of anyone who would so vigorously defend the status quo, particularly when so many shortcomings are obvious. Does Mr. Ferguson just work for his paper company, or does he have other ties to Microsoft or Rockwell? Further, what the heck do tree-huggers have to do with controls? When you speak of "your" forest, Mr. Ferguson, is it yours to "harvest", or just the last remnants of a temperate rainforest that once covered much of North America? Like nearly everyone I know in the industrial automation business, I have experienced a wide variety of hassles & poor customer service from Rockwell. But you don't have much choice, do you? I would love to see an HMI package that incorporated a tag builder, saving me hours of laborious CSV-file editing while simultaneously eliminating data-entry errors. I whole-heartedly applaud the Linux-PLC project & its goals. I am convinced that something drastic must occur before the big control companies change their strategy - it's simply been successfully producing revenue for too long. Being an optimist (and a lover of trees), I expect something drastic within the next few years. I'm rooting for Linux.
I am responding to the insightful email from Jeff Dean expressing concern regarding the lack of advances in PC-based HMI/SCADA. Perhaps I can help to shed some light on this topic - from marketing and business standpoints : The growth of HMI/SCADA software came in the late '80s and early '90s, with the encroachment of PCs on the Plant floor, and the ability to do most SCADA and DCS functions cheaply and effectively in PC software. A horde of PC software startups mushroomed into significance. But, the initial growth could not be sustained, and the two leaders soon became part of larger automation companies - Intellution was acquired by Emerson Electric. Wonderware went public and was then bought by Siebe (now Invensys). Their software was integrated into the Corporate DCS architectures. It is interesting - and significant - that both Wonderware and Intellution (acquired because they were expected to zoom beyond $ 100m in annual sales) are (a decade later) still way, way below that target (my estimate is not much beyond $50m). And all the others are still relatively small ($ 20m). Allen-Bradley (now Rockwell) rushed off to acquire software catalysts and develop their own Software Division - and they too are fizzling. The business & marketing points are these : 1/ There is very little growth in conventional HMI/SCADA software, and hence the big companies are looking for other growth arenas - now presumed to be in Enterprise software. 2/ Good software is the realm of small, creative teams. Big companies are notoriously poor at developing innovation and creativity. This is why, as Jeff Dean points out : "significant HMI software enhancement stopped some years ago. The number of innovative features added in the last five years can be counted on one hand. " 3/ Prices are falling sharply - smaller companies and even third-world countries (India, China, Far East) have good software skills, available at a much lower cost. HMI/SCADA software is being developed (and copied) elsewhere. That said, where does the growth lie? Jeff Dean points out : "Meanwhile, industrial automation installations are growing larger, involving higher I/O counts, and a larger number of controllers and networks. Technology as a whole is advancing at an ever accelerating rate, and in particular, state-of-the-art software tools and technologies are experiencing an almost complete shift from where they were just a few years ago." My own belief is that new and innovative software will come from small, creative teams - probably from start-ups and garage shops. Innovation starts in the gut - not in a Supervisor's PERT chart. Future millionaires come not from paltry annual pay raises, but from stock ownership in the next Intellution and Wonderware. The age of centralized DCS and PLC systems is past - future HMI/SCADA will not simply emulate DCS/PLC functions. Bring on peer-to-peer I/O systems and internet-based complex-adaptive systems! Jeff invites discussion! C'mon, Automation List, let's discuss! Cheers: jim ----------/ Jim Pinto email : email@example.com web: www.JimPinto.com San Diego, CA., USA ----------/
Jim and Jeff raise interesting points. It is important, though, to recognize that we are talking about a cluster of software functions, and some of them are more visible than others. HMI has changed the least in the last two years, primarily because it is the easiest to work with...OPC and ActiveX objects are easy to build and easy to manipulate, and there is a finite universe of them necessary to build process control HMI. You need a tank, you need a pipe, you need a flow meter, etc. SCADA has become part of the PLC realm and changes are slow as the behemoths do the dance of expansion and contraction. Even in the O&G, power and water distribution areas, there is little more in the SCADA realm. But under the surface, there is a lot going on...behind the HMI, and below the SCADA interface. Just as XML is fueling the drive to consolidate supply chains, the back-end of control software is getting most of the attention, and will continue to get it for the foreseeable future. The fact is, that unless the peer-to-peer systems and the internet-based systems can talk to the rest of the enterprise, they will be fairly useless for industrial automation. That's where the real revolution in automation software is going on. Walt Boyes --------------------------------------------- Walt Boyes -- MarketingPractice Consultants firstname.lastname@example.org 21118 SE 278th Place - Maple Valley, WA 98038 253-709-5046 cell 425-432-8262 home office fax:801-749-7142 ICQ: 59435534 "Strategic marketing, sales and electronic business consulting for the small and medium-sized enterprise: http://www.waltboyes.com" ---------------------------------------------
<clip> > The fact is, that unless the peer-to-peer systems and the internet-based > systems can talk to the rest of the enterprise, they will be fairly useless > for industrial automation. I'm curious Walt, why is that? Regards cww
Curt Wuollet asks: <mucho snipparoo> >I'm curious Walt, why is that? Because the front-end of control software (the HMI end) works well enough to be a near-commodity. There are a finite number of control scenarios and the tools exist to make building HMI and SCADA and distributed control systems out of building blocks easily and cost effectively. But the revolution taking place in manufacturing, and the real cost reductions are taking place in supply chain consolidation and in the integration of the entire enterprise, from CRM through MES to plant floor automation, to MIS and financial functions. Remember that the reason companies spend money on control systems is different than the reason most of us play with them. They do it to realize cost savings, efficiencies, and make money. We do it, at bottom, because it is fun, and it is a cool toy. Yes, we like to make money, personally, but unless you are a plant manager or a c-level enterprise officer, you have a different view of the usefulness and necessity of new control software than they do. Walt Boyes
Hi Walt So the future of Factory Automation is in the realm of IS? I've done both and I think the IS folks will take exception to that. Perhaps in your consultancy you can propose this total view. It's here where the collision occurs. Many businesses are doing their "line of business" software in Java these days, especially if they are involved in e-whatever. Many do this with divergent platforms. Right now, this grand scheme "from the factory floor to the boardroom" implies a single source solution when the world is not going this way. Furthermore, this would require a much more unified and harmonious relationship between IS and the automation folks than I have observed. Businesses also do their Enterprise Systems for cost savings and other criteria not necessarily in tune with what folks do with machinery. Attractive as it may or may not be, the "factory floor to boardroom" folks I've talked to have only one way to do it. This is wonderful if your information operation is compatible. It is a horrific kludge if it is not. This is because the situation on the IS end is diverse and the situation on the automation end is not. Lest you think I'm nitpicking, I have actually had people propose that we migrate the enterprise end to accomplish this. Right now there are perhaps a half a dozen enterprise class platforms available for the manufacturing suite. There is exactly one for the automation end. Five of the six will not integrate cleanly because that is a design goal of the sixth. I hope you can appreciate that I see this utopian world of seamless integration as being a lot less viable and therefore important than you do. If the automation vendors wish to be taken seriously, they will need to account for the fact that not everyone sees things their way. I just don't see the Automation technology choices driving the IS technology choices. And that's a very good thing. Regards cww
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. 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. 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. Notice how the big analysts, Gartner and ARC, have repositioned themselves. 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. You may want to suggest that IT can't handle control. Lots of us fondly believe that. 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. 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. 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. Walt Boyes --------------------------------------------- Walt Boyes -- MarketingPractice Consultants email@example.com 21118 SE 278th Place - Maple Valley, WA 98038 253-709-5046 cell 425-432-8262 home office fax:801-749-7142 ICQ: 59435534 "Strategic marketing, sales and electronic business consulting for the small and medium-sized enterprise: http://www.waltboyes.com" ---------------------------------------------
Walt, Nice post. I can't speak for machine control or the discrete industries, but in the process industry there is still often too much variability getting into products. There is certainly room for reducing variability in the process. Regulatory controls are still occasionally misapplied or poorly applied or simply deteriorate in performance over time. The boardroom can't be bothered with these details, but if somebody doesn't pay attention then the boardroom will make poor decisions and lose some of the benefits of all their information integration. So at the field end of the wires, there are opportunities for developing better products and methods to identify and discriminate between good data and bad data as well as process performance. This is an area where smart instrumentation can play and fieldbusses can help, but it also cares little whether there is an MS or "x"nix box somewhere on the other end. I guess I'm suggesting that maybe the choice of bit-crunching platforms are less important than how they are applied. And in the end, the platforms that deliver will be the ones chosen. Regards, Lou Heavner Emerson Performance Solutions - but speaking for myself
> 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
The subject is interesting, but I think that there's the main aspect not yet considered. What does the Board Room want from a HMI?
If we consider the Human-Machine interface in two tiers, things will fall into place. On one tier is the operator looking at the screen and intervening whenever necessary. At the Board level there's the Director (Engineering) who wants to know about half a dozen patrameters of his/her plant that's been giving her sleepless nights. Because they tell her about how her plant is behaving, and whether it's time to take certain steps withour waiting any further.
Walt, I'm so glad you suggested that I may be wrong. It wouldn't be much very interesting or much fun if everyone either agreed or held their tongues. Your message made me think, but I hold firm to my position. Please read on and lets see if we can't find some room for movement in yours. You are absolutely correct. I also believe that many companies find it important for information from automation systems to easily be accessible to information systems. I did not intend to infer otherwise. Whether the goal is to integrate with an ERP system or simply get values in a spreadsheet and print a report, this has long been a requirement of HMI/SCADA systems. Your message did confuse me in one respect. It seems that on one hand you're saying that HMI has a limited role on the plant floor and that today it is all that it needs to be. Yet on the other hand, you seem endorse the vendors positions that the HMI is the information conduit to the enterprise and that advances are necessary to fill that role. I'm sure I simply don't have a clear understanding of what your belief is. And I would appreciate any clarification. I do agree that the equipment represented on most HMI displays is limited. Further, the primitives provided by the drawing software (squares, circles, lines, etc.) are even easier to account for. How many different ways can someone draw a square and make it change colors, move, resize, rotate, and blink? Not too many. That functionality does not leave much room for significant advancement, but why shouldn't HMI designers use best-of-breed tools like Visio and Photoshop, or any number of other off the shelf packages to build displays? And what if we consider the other 90% of what an HMI does: Networking? Alarming (Historical and Real-time)? Historical logging and retrieval? Recipe management? Quality analysis? Reliability? Redundancy? Data integrity? For years these core capabilities and responsibilities of an HMI have been mostly ignored by the major vendors. Whether viewing the data on the screen or integrating with other systems in the enterprise, assuring that the data is accurate and limiting down time is critical. >>But under the surface, there is a lot going on...behind the HMI, and below >>the SCADA interface. The fact that there is a lot going on under the surface is -EXACTLY- why I am interested in the direction HMI/SCADA systems need to go. Are you proposing that the development of new and faster control networks, the increasing number of instruments in any single installation, and the continually growing size of new facilities and systems should have no impact on the HMI or SCADA application? Or further that the tremendous evolutions occurring is software design, development, and deployment should not impact what HMI software is in use? I can not rationalize that opinion because I believe there are opportunities for growth in traditional HMI resulting directly from the growth in automation systems and the advances in software technologies. Let me summarize by restating my premise: Enterprise integration is where traditional HMI providers have focused their new development efforts. They have introduced any number of new products claiming each will provide the desired level of integration. They have not extended their core product(s) to work with existing open technologies, instead they have introduced new middleware that allows them to further cement their position on the plant floor. Enterprise integration is important in many applications, however given a sufficiently open HMI/SCADA system there are solutions available on the market that can address all industrial automation applications. These vendors continue sitting on their HMI laurels with products they designed and developed years ago while they attempt to attain projected revenue growth. It seems there is little interest in improving the capabilities or reliability of their core products. In previous messages I have identified several features I believe should be incorporated into a modern HMI. These are capabilities none of the major vendors offer, yet I have heard integrators and end-users clamoring for. Is the solution a squirrel? (who saw the EDS commercial during the super bowl?) :) Or will one of the vendors get back to their roots and realize they can achieve revenue projections by capturing a greater share of the HMI market? How many threads have you seen on the A-List that start with "which package is better" and end up with discussions of who provides the best support. If there were a clearly better solution, any one of them could achieve their revenue goals by simply cannibalizing the competition and I would be [somewhat] pacified because the market would have a better option. :) Yours, Jeff Dean firstname.lastname@example.org
As I read this 5 years later, we are still dealing with exactly the same issues. Jim, Jeff, and Walt all make excellent arguments and have great points - and, boy, do you guys write well! Their points are still applicable today, and will probably be for some time to come.
I speak with Integrators and manufacturers who deal with automation on a daily basis. The consensus is that the software quality STILL isn't up to par - that the bells and whistles that are being promoted are being overshadowed by stability issues. And the focus STILL seems to be MES, ERP, get it working with SAP, PeopleSoft, Six Sigma, Rockwell's getting CMMI level 2 certified, Wonderware touts 21CFR11 support - Choose your lofty goal - everyone still seems to be going in a different direction. And they're very cool ideas - each and every one of them. The message I get from integrators goes back to basics - we still can't see what's going on with production from our desk, what happened to "paperless manufacturing" we still can't even connect to our existing SQL databases, and don't even get me started on stability of industrial software - those words are becoming an oxymoron. As an industry, we're still dealing with the same crummy software with new bells and whistles - we don't have the economy of scale to do any better, right?
Rich Meritt wrote an interesting article on the commodification of HMI/SCADA packages. He makes great points: everybody's software's strikingly similar and the prices on some of the cheap versions (that effectively do the same thing) are plummeting.
Funny thing is, when I talk to integrators about the packages their implementing it's either: Wonderware, RSView, Intellusion, WinCC, or a short list of others with common denominators including: large companies, steep pricing models, and the same general quality of software. It seems that the old adage, "You can't get fired with IBM" seems to apply with these HMI/SCADA giants. Ironic that manufacturing embraces old technologies so strongly, for an industry that's historically been defined by innovation.
In any event, I hear "outsourcing, outsourcing, outsourcing", "go with the lower cost", and I would predict this sort of thing too. But I see lots of complaints toward the behemoths that eventually lead to purchases. End users and integrators are telling industrial software companies that their policies and models are acceptable. I don't see anything going anywhere as long as this continues.
"Design Simplicity Cures Engineered Complexity"
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 >
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
HMI is slowing being replaced with A.I., meaning there's no need for human intervention. The system will be intelligent enough to analyse the I/O, environment, parameter etc given and derive it's own efficient algorithm to operate itself.
At the top level, what we do is just placing "blocks" into the manufacturing system. Well...another of my crazy dreams :)
I feel like stirring the pot a bit here. What's the future of SCADA? Advanced embedded devices, large-scale, robust ubiquitous networks, Linux, Windows, Java?
Are we making progress?
Nathan Boeger, CISSP
In reply to Nathan Boeger: I replied to some of this under another heading, so I won't repeat myself too much here, but here are my opinions.
"SCADA" - I think the HMI side of it will be web based.
"Advanced embedded devices" - A lot of current "embedded" hardware will be replaced by things that are packaged in a nice box, but which are more like a PC. There is some very interesting very inexpensive ($50) hardware now (e.g. Marvel "Plug Computing") based on ARM chips that can run a standard Debian OS.
"large-scale, robust ubiquitous networks" - The big problem at the present time is proprietary network protocols are hampering the effectiveness of automation systems.
"Linux" - It will see increasing use, probably in server and embedded applications first though. It's already at work in a lot of factories; the users just don't know it.
"Windows" - On the average engineering desktop for basic e-mail and word processing, it is still quite strong because IT departments have such a large installed base. I don't see it ever having a strong presence on the shop floor though because few people would have enough confidence in its reliability and security.
"Java" - The answer to that depends on the application. What we have seen over the past 10 or 20 years is that the new languages which are successful are used for particular areas of application, rather than being "one size fits all". For very large server applications. Java is a success. For consumer electronics applications, Java is a success. For desktop applications - well that's a different story.
As to where Java goes in future, that is going to depend a lot on what Oracle decides to do with it. And that's the problem with languages like Java (or C#). Somebody has a business plan for it, and that plan may not include you in its future. The best thing that could happen to Java would be for everyone else to pry its future out of the fingers of Oracle. We'll have to see what happens over the next few months though.
I fear the future will be very much like the past. The obsession with Microsoft has inhibited progress for decades and none of the majors are moving quickly to change. Observe that much of the data passing in even the newest products takes place with technology that even Microsoft has declared obsolete long ago. The intense activity required to simply keep up with the forced upgrade mill saps much of the vitality that could be spent on innovation and refinement. That is not to say there won't be progress, but expect it to come from non major sources. No matter how excellent these are, it will be difficult to crack the walls of the Tower of Babel to produce any significant change in the industry. This arena actively works against change. Sooner or later though, one of the majors will, forced by loss of share or simple stagnation, break the mold and attempt something different and of they succeed to any significant extent will actually spur acceptance of new ideas. Or some small outfit will come up with something great that leverages the advantages of the non Microsoft world and disrupts the status quo. It's the dark side of lock in. Making it as difficult as possible to change cuts both ways. None of the majors has the agility to deal with change.
I have to agree with you that this fascination with Windows by hot shot IT college boys or Management in Suits that say Windows is the way to go with everything is creating havoc in the HMI world.
Keep in mind that to take for example a very robust UNIX system and turn it into Microsoft windows does not make the turbine turn any faster or the paper wind up an sooner on the real.
An operator screen is an operator screen. To spend hundreds of thousands of dollars to rip out a perfectly good HMI and pay to have graphics redrawn in visual basic or dot net is shear lunacy, when the operator gets to stare at the same drawings he had before. Where is the bang for the buck?
The fear is that the companies can not find a reliable source for their aging HMI hardware. But that fear is now gone with a source like Workstations Express. Hard core UNIX companies, that want to be free of upgrades and viruses should take a look at the possibilities with workstationsexpress.com.
Yes, I remember a Cimplicity demo designed to get us to "upgrade" from the UNIX version to the Windows version. It was slower and would hang and crash during the demo, while the UNIX version just ran until we took it down to blow out the dust and crap, then run for another year. From the demo, you would have to be out of your mind to switch, but they got a lot of the shops to do it anyways, because ????
Obviously, it has nothing to do with function or reliability. I think the pitch was "any idiot can deal with Windows" and by implication, your critical processes. I've seen several examples of where they took that to heart. Indeed some of the pleas we see on this list scare me to death, and make me glad I'm not a worker in those factories.
>I think the pitch was "any idiot can deal with Windows" and by implication, your critical processes. <
Why not run the critical parts on Linux/Unix server and let the user run a Windows client ?
Web based must NOT necessarily mean using a standard web browser. We have developed a Client/Server software that can be used like that but is optimized for HMI / SCADA.
Please evaluate our solution and give me your response.
In reply to Curt Wuollet: It's funny that the one operating system on the market that is sold as being *the* OS for people who just want use computers without having to learn anything about them is a version of UNIX - Mac OS/X. If MS Windows is so great and UNIX is so hard to use, then how does Apple manage to sell so many computers?
As far as HP hardware is concerned, there is an experimental version of QEMU (CPU emulator) that supports PA-RISC as a guest architecture. Given that, old software that ran on HP workstations should be able to run in emulation on new hardware indefinitely.
IF, it were up to me, it would all run on Linux. But, until the majors see the light, you would have to roll you own, with a few exceptions :^) It would be interesting if the vendors who used to run on UNIX would port to Linux. Wouldn't be very hard or expensive either. Would need new drivers for modern hardware.
Yes, the harder to use part is mostly just MS marketing. Obviously, if you can "do MAC" on top of *nix and sell it to Macheads, you can do all the bells and whistles needed. I don't think very many people on this list would have any problems with Linux if they made any effort at all, or for some reason _had_ to learn it. I've certainly struggled more with some PLC software.
I like and use Linux on one of my machines, but I'm geeky enough to enjoy command line programming when I need to, and can troubleshoot drivers and write code. The real problem I have with Linux is the same problem I have with most open source systems-- they are all buggy as hell. Mozilla is having terrible trouble with Firefox add-ins, Dhrupal is having a classic fail meltdown, as is Joomla. Wikipedia is a casual user's interface nightmare from hell.
If I could be assured that these back end issues wouldn't crop up as problems, failures and security vulnerabilities, I'd not give a rodent's posterior what OS the HMI or whatever is written in, and I don't think most users would care much either.
All they want is for something to work when they want it to, with a high probability of it continuing to do so for the projected lifecycle of the device or system, which is upwards of 30 years on average now in automation installations.
Editor in Chief
Control and Controlglobal.com
Mailto:wboyes [at] putman.net
Read my blog SoundOFF!! At www.controlglobal.com/soundoff
Ah, yes. The best trolls are the classic ones. I've seen that one used a few times. If you want cww to bite on it though, I think you'll have to add something about what a terrible programming language C is and how all programs written in it are doomed to failure, etc. etc. Perhaps add something about Perl, as I think he's used that as well.
To turn back to the original (revived) topic, I notice that Nathan Boeger seems to have dropped a couple of topics on us (here and in another posting) and then vanished. He brought up some interesting points though, which I think deserves some serious discussion.
To give this a bit more focus, I'll add some questions of my own.
1) What do people think of web based HMI? Pros? Cons? Perhaps good for some applications but not others?
2) What about doing an HMI client directly in the browser with AJAX, versus a Flash/Java/Silverlight/ActiveX plug-in? (The latter methods really just use the web browser as a downloader for the application).
3) XML versus JSON versus anything else?
4) Does anyone think the automation vendors will start using hosted web applications for any of their development software? Would the idea that the vendor could then just turn that software off at will make anyone nervous about the long term maintainability of their automation systems?
> Ah, yes. The best trolls are the classic ones. I've seen that one used a few times. If you want cww to bite on it though, I think you'll have to add something about what a terrible programming language C is and how all programs written in it are doomed to failure, etc. etc. Perhaps add something about Perl, as I think he's used that as well. <
You know that just about everything would disappear if all the C apps did. At some level almost all become C based :^) I'm more agnostic about perl, the last I heard they were installing the kitchen sink API.
> To turn back to the original (revived) topic, I notice that Nathan Boeger seems to have dropped a couple of topics on us (here and in another posting) and then vanished. He brought up some interesting points though, which I think deserves some serious discussion.
> To give this a bit more focus, I'll add some questions of my own.
> 1) What do people think of web based HMI? Pros? Cons? Perhaps good for some applications but not others? <
More important, what do the vendors think about Web Based HMI? Will the AB/RA patent situation cloud the waters forever?
> 2) What about doing an HMI client directly in the browser with AJAX, versus a Flash/Java/Silverlight/ActiveX plug-in? (The latter methods really just use the web browser as a downloader for the application).
> 3) XML versus JSON versus anything else?
> 4) Does anyone think the automation vendors will start using hosted web applications for any of their development software? Would the idea that the vendor could then just turn that software off at will make anyone nervous about the long term maintainability of their automation systems? <
It would sure make for interesting contract talks and keep legal dept's busy. There is a strong trend for these issues to be user driven, everywhere else but in automation.
Web based systems!
User Driven software apps!
Single dimensional thinking.
What is really needed, and is very much on the horizon, are systems and software applications that self generate structured information by using virtual knowledge and data to drive more complex data.
Until then, the computer and any application it may run, can best be
described as a rather simplistic aid to human endeavor.
In reply to Bob Pawley:
But the software will still have to communicate with operators, maintenance and engineering personnel, managers and supervisors, etc. You'll still need a display and input devices (keyboard, mouse, touch screen, etc.). Regardless of how the application itself is generated, the same HMI questions remain.
Which patent are you specifically referring to? Is there one that is much more onerous than all of the others? I was a little shocked to see how many patents RA is applying for. Talk about stifling innovation, I guess I have a fresh reason to dislike them.
They contend that they own the whole idea of displaying PLC data on a web page. And they were granted a patent. That was ages ago, so I don't have the data on this machine. I imagine google would find it.
Example of what a great idea software patents are.
> Which patent are you specifically referring to? <
Here's one, This one is authored by Ken Crater: US /Patent/ 5805442
And two assigned to Schneider: US Patent 7062335, 06732191
Indeed there are so many that I would need to look a lot harder to find the RA/AB one.
But that is exactly the point. Slog through these and see how much you want to risk coding a Browser based HMI. At any time these deep pocket types could do you in. And although the display of PLC data
seems rather obvious today and among us, the USPO is still using quill pens and is most efficient when granting patents in areas where they have no knowledge.
And these may even be defensive patents to stave off a battle of titans. But, they effectively stifle anyone without the means to game the court system from trying to compete. One of the many reasons for the glacial pace of change in automation.
> Which patent are you specifically referring to? <
Late breaking news: I must apologize for naming AB/RA as the one claiming to own the PLC data on a browser idea. I dug around some and it was Schneider. My memory of discussions 8 years ago was faulty. The chilling effect to the industry is the same.
And lest you forget, Ken Crater is the father and guiding genius behind this list. Schneider learned their lesson from the Solaia patent...they haven't tried to strongarm people to enforce Ken's patent, even though it is such an early one that they probably have a winner.
Editor in Chief
Control and Controlglobal.com
Read my blog SoundOFF!! At www.controlglobal.com/soundoff
That may very well be, but the effect is the same. Even though GS/Modicon has acted as a good citizen with Modbus.org for which they need to be commended, lawyers and investors of money or sweat balk at "They can, but they won't". Even promises like MS made recently not to use their patent portfolio against OSS are not as enforceable as a patent held by an entity with all the money in the world. And the recent Tom Tom and FAT actions bear this out. And once the ugly snarl has been woven, it's not apparent how to make it go away. It may get to the point that, if you have anything at all to lose, you avoid writing new software. I'm OK, they can have my 98 Neon and assorted computer junk. But losing a million dollar idea would hurt even an OSS fan. OSS could be a defense if you are operating in the public interest, but I bet money would win.
At what point do we or should I say do YOU draw the line at OPEN. Is it at Operating Systems, is it at Control systems, or is it at Controls Engineering. Why do you not program for FREE. It is because you are a Capitalist, only your argument is at being a Capitalist up until you want to be a Socialist.
Lets all stop writing control code for pay and start doing it for free. We will join and meet at the commune and start farming and bartering as a form of money.
The center of Capitalist and democracy is Intellectual Property rights. No property rights, no democracy..............it is hypocrisy to draw the line at Operating systems and the "evil Empire" that Rockwell, Microsoft, etc. are. They have Millions of dollars invested in development and have every right to protect it.
When you buy a new TV from Samsung, I now feel that it is my right to watch YOUR TV. I would not have to buy a new TV if you would share yours. It is unfair that I should have to PAY for a new TV when you have one. For that matter, I want to make one. I feel that I have every right to the chips for free and the LCD technology that it is made from. If they GAVE me that technology for free, I could build a better TV for myself and it would not cost me a trip to Best Buy.
I have no issue with the thought of Open Sourcing, I have no issue with Capitalism and making money and protecting rights, I have no issue with making money for your work. I do have an issue with drawing lines in the sand that suit my opinion and tossing the other thoughts out. What you assume should be open and available technology to everyone. At one time was unheard of and was INVENTED by someone through their either own sweat and tears or working for an Employer. Either way, they have every right to protect it and not GIVE it away if they do not want to.
Control Systems Engineer (And damn proud that I get PAID to be one)
That's easy. I write software for free when I can and when it's mine to give. I write software when I get paid to write it and then the decision whether it should be free or not is up to the owner. I think both are worthwhile. Your argument would be that it's right for the bottled water people to be able to shut off and even outlaw the taps. I think public utilities are not a communist plot. They are the best way to get people what they need. They can still buy water if they wish.
If I want a free OS, and I can contribute I do. The whole Linux arena is a really good thing for me and everyone else. There was a time when I could not write software because it was so expensive that you had to work for someone that could afford it to have the tools. Obviously Linux is much better because I or anyone else can own the tools. It's probably not all that great for the monopolists, but why should they have to exclusive right to control what I do with my computer? Or if I can write software? A lot of people think there is something wrong with that. That only people who should be able to publish software are those who fleece their customers and break antitrust laws. That's very strange. Nothing else works that way.
It's a straw argument anyways, At least 99% of the software written to date is so specific that it wouldn't be of any use to the public and it's not published, free or closed. That's the test, perhaps. Obviously, if I buy a computer, there is no rational reason that I and everyone else should have to pay MS and only MS to use it. If I want to automate things, there is no reason that I should have to do it in a way that pleases you or enriches a select few companies that pay no attention to what I need to be able to do. I just outlined for a list member how to do something that they need to do with free tools and commodity hardware and software I can write and they are free to write. Is that wrong because it doesn't profit any of the big companies in automation? If it's easier and cheaper to do with commercial stuff, so be it. What's better for the customer?
If the bottled water companies invented and own the taps, then it is their right to shut them off or not if they have protected them.
As far as Monopolistic goes, you should find out a little bit more about the motives behind the MS anti-trust lawsuits and the EU etc. You assume that because they were ruled against on some fronts, that that ruling was not motivated by some other motives.
If you dig in deeper you find that there were other motives behind such things. I will not bore everyone with this old triage here. Just like if you read history, Thomas Edison was a genius (great PR) but when you dig deeper, you find that he, Westinghouse and Tesla were stabbing each other in the back at every turn and twist.....including using the Electric Chair to rally against AC power. Sometimes there is more to the story than you see before you or in the press. Dig into the MS issue more, and you find other entities trying to protect their interests just as hard as MS.
The answer to your question is yes. If Dell wants to sell computers that the masses want with the OS that the masses are familiar with and tend to like. Then in order to get that OS at a commodity price, they sign deals to package it on their computers. If the masses wanted something else (in large numbers)(re-read last part) then Dell would quickly turn that route.
I have written a control program that writes control programs. Sort of a "I want 3 valves with 2 limits, and 8 motors with 2 PIDS", fill in the blanks and it writes the control code, builds HMI screens and generates CAD drawings. Should I have to give this away for free, because when I bid a job I have an advantage over someone else bidding, just because they will not take the time to write this program themselves ???
We are now in like our 11th year of arguing this issue. And now we could ad Google and its monopoly into the debate. They are bundling and tying in everything............a new target.
Proprietary Control Systems Engineer PCSE ;)P
Yes, it has been a while. But don't ever dismiss our pleasant debate as pointless. When we started, Open wasn't even in the automation vocabulary. Now, folks understand that there is a difference, and more important, have begun to imagine how much easier things could be without the artificial barriers to doing perfectly rational things due to proprietary zeal.
> If the bottled water companies invented and own the taps, then it is their right to shut them off or not if they have protected them. ,
Yes, but they want to patent the idea of water, ignoring how basic it is.
> As far as Monopolistic goes, you should find out a little bit more about the motives behind the MS anti-trust lawsuits and the EU etc. You assume that because they were ruled against on some fronts, that that ruling was not motivated by some other motives. <
Oh, absolutely. When you stomp out competition, assimilate and destroy companies that have better ideas, and generally use market dominance to eliminate any choice for consumers, you do tend to make a few enemies. If none of the worlds companies have any chance of penetrating the US or even their own markets due to exclusive agreements, it does tend to piss them off. But unlike MS, I'm sure that all would still allow MS to be one of the choices on a level playing field. Well, most of them anyway.
> If you dig in deeper you find that there were other motives behind such things. I will not bore everyone with this old triage here. Just like if you read history, Thomas Edison was a genius (great PR) but when you dig deeper, you find that he, Westinghouse and Tesla were stabbing each other in the back at every turn and twist.....including using the Electric Chair to rally against AC power. Sometimes there is more to the story than you see before you or in the press. Dig into the MS issue more, and you find other entities trying to protect their interests just as hard as MS. <
And there is nothing wrong with that in a capitalistic system, up to a point. We will, hopefully, soon be past the days of Robber Barons and "anything goes". Certain entities can still ignore the rule of law. And while some of the laws are. overtly or covertly, intended to limit "foreign" competition, most are reaction to real wrongdoing in the past. There have to be limits to have fair competition. It's like physical property; I can forbid neighbors from my property and call the law in if they trespass. But, in most places, I can't lay land mines or shoot them.
> The answer to your question is yes. If Dell wants to sell computers that the masses want with the OS that the masses are familiar with and tend to like. Then in order to get that OS at a commodity price, they sign deals to package it on their computers. If the masses wanted something else (in large numbers)(re-read last part) then Dell would quickly turn that route. <
That's kinda where we differ. I don't have any problem with MS being one of the choices when I buy a PC. But MS was actually trying to make it illegal to buy a PC with no operating system. And they effectively have achieved the same goal with abuse of their monopoly power. And that clearly sustains an illegal monopoly. Fair or not, I think a dominant vendor should be prohibited from making exclusive agreements that prevent any competition. PC sellers may choose not to support alternatives, or MS, for that matter. But then, no OS should be an option and MS shouldn't be allowed to starve them out. This is getting very close to the line, because you should be able to give deals to your friends. But, not to the extent that you can kill agnostics or prevent competition. I think the EU browser proposal is probably a good compromise, but MS only agreed because FireFox is making the point moot and they can't repeat their past dirty tricks to stop it. I think something similar should apply to operating systems, only with no default.
> I have written a control program that writes control programs. Sort of a "I want 3 valves with 2 limits, and 8 motors with 2 PIDS", fill in the blanks and it writes the control code, builds HMI screens and generates CAD drawings. Should I have to give this away for free, because when I bid a job I have an advantage over someone else bidding, just because they will not take the time to write this program themselves ??? <
No, I have never attempted to tell you what to do with what you write. But, if I do the same with free tools and underbid you, you should do the same. Because, you _have_ the choice to do the same. That doesn't limit profit but it does lower costs. After all, we are not selling the tools, we are selling the IP. Now, it you were granted a patent on the PID concept.
> We are now in like our 11th year of arguing this issue. And now we could ad Google and its monopoly into the debate. They are bundling and tying in everything............a new target. <
I don't necessarily disagree with you on that. But at least you don't _have_ to use Google. They are treading on both sides of a fine line.
This is a new area of enterprise and there are many issues yet to be solved.
> Dave Ferguson
> Proprietary Control Systems Engineer PCSE ;)P
cww Paying for my principles, I guess :^)
If it is Ken's patent, then I may have to take back what I said in my
earlier post...maybe Schneider hasn't learned from the Solaia mess.
I've just started looking at this stuff recently, but I like the idea of using AJAX in the browser for an HMI, rather than downloading a program that requires a plugin or other software to be installed. What would be nice are real vector graphics in a browser. (SVG???)
XML is kind of fat, but it very common and open, so it is really best at this point (IMHO).
I don't think people will used hosted applications for mission critical systems, not yet anyways.
In reply to William Sturm: I've been using SVG in the web browser for HMI, and it seems to work quite nicely. If you are interested in how I did it, I have documented it (including SVG snippets) on my project web site: "http://mblogic.sourceforge.net/mbtools/hmiserver/hmiserverintro-en.html"
That shows examples of how I did push buttons, pilot lights, gauges, strip charts, etc. The nice thing about using SVG is that you aren't limited to whatever "controls" someone provided you. You can make your own custom shapes and animate them the same way. For example, I've used the same technique to animate a tank as I've used to animate a column gauge. Someone sent me a screen shot where they adapted it for a variety of different tanks and hoppers in a dairy (and they were a lot more artistic than my efforts).
> XML is kind of fat, but it very common and open, so it is really best at this point (IMHO). <
> I don't think people will used hosted applications for mission critical systems, not yet anyways. <
I was thinking that the vendors might find it attractive for the development software because they would have lots of options for billing you in dozens of different ways. Even if all the technical problems were solved though, I'm pretty sure that I don't like the idea that the vendor could turn off the tap whenever they felt like it.
That's a completely different thing from a web based HMI though. A web based HMI doesn't tie you to a vendor like a hosted app does.
I just took a look on the Internet to see what other people are doing with web HMI systems, and I turned up a few interesting links.
1) "http://www.control.com/thread/1026215289". This one is interesting because apparently I had a discussion with someone here in 2005 that I had forgotten all about. This is interesting in that it shows this is not a new subject here.
2) "http://www.svgopen.org/2004/papers/SVGforSCADA/". A Phd candidate at the Swiss Federal Institute of Technology Lausanne wrote paper titled "SVG for SCADA Applications A practical approach". The paper may be useful background for someone interested in the subject, but it won't tell you how to implement anything. Despite calling it "a practical approach", he apparently didn't create an actual application and so has missed a lot of practical problems and solutions.
This is an interesting paper written in 2008 by some engineers at Mikron (a machine tool vendor). They describe their new web based HMI using SVG which they developed as an HMI system for their machining centres. The paper describes the overall architecture and design of the system.
I find the fact that they've done this very interesting, as it is exactly the sort of application which I expected to be the early adopter of this technique.
However, I'm not keen on their actual software design. I won't provide a detailed criticism of it unless someone is interested, but I think their server design is based on the wrong components, making it far more complex than it needs to be. Their artwork is very limited (artistically) because of the way they generate it. I also think they also made a mistake in limiting themselves to SVG instead of combining it with HTML.
Overall though, it is a good example of what can be done with a modern web based HMI, and worth reading.
In reply to M Griffin about SVG
Here is a short description about how to use SVG within http://pvbrowser.org
SVG is only one of the techniques available in pvbrowser.
Example SVG screenshots:
PS: pvbrowser is Open Source
In reply to pvb: Do you find it easier to use a drawing program like Inkscape, or to just write the XML for SVG directly?
In reply to M Griffin:
> Do you find it easier to use a drawing program like Inkscape, or to just write the XML for SVG directly? <
I think Inkscape is a good solution, because it has an integrated XML-editor.
Thus you can do both,
- design graphically
- write XML
within the same application.
I would not suggest any of those for control purposes. Or for that matter, critical content applications. Everything about webcrafting is in continual flux and probably will be in the future as well, as everyone searches for the slickest look and the fastest methods to create pages. But, if you step back from the edge, there are stable, well tested tools that would serve well for industrial projects. And using that well defined subset would probably ensure a low incidence of browser issues as well. The good thing about FOSS for this is that I can continue using Mozilla 1.X as long as I wish. Even if I upgrade the OS. If I need to change I can do it on my schedule. I did a test and RedHat 4.0 will still load and run on a new machine. That's pretty old. And given the breakneck development pace, Linux won't be without problems, but I can fix all so far and no one can tell me I can't run any version there has ever been. You do have to live with some change. I think you would agree that the changes in the last few years have been phenomenal and very much for the better. Especially for non-dinosaurs, But the dino stuff is still there for us.
I work very often with up to date tools where i have a high working performance like windows,office 2007, visual studio 2009,RDP, wikipedia..
But then i also have to work with different scada tools, i always feel like i'm going back 10 to 15 years.
=> no object orientation,
=> no drag'n' drop support for the user,
=> inflexible systems
=> support intensive
=> for everything you need expensive courses
=> closed (no open access to the eng. data)
=> not for information working environment like the "internet/wikipedia" generation need (i was talking about information, not the code on the plc ;-) )
=> also why is opc ua not opensource ????
In reply to Max: I suppose that SCADA tools feel like they are from 10 or 15 years ago because the market leaders today *are* from 10 or 15 years ago with just incremental improvements since then.
As for OPC UA, not even the specs are open. The business though is all about selling proprietary drivers to plug into proprietary programs so they can use proprietary protocols. Where is the incentive to be open?
I would add:
As long as people buy the closed stuff :^).
There is the answer in a nutshell, when closed = no sale,
there will be change.
First off, Hello all. Secondly I apologize for not reading the entire thread. I found this site while trying to find open source host based automation software for Linux. I found MatPLC and looking forward to trying it out.
My point to this thread:
I totally understand the safety concerns of using foss in a factory setting. However, there are many people out there like me who are trying to do small-mid sized projects and trying to find our way. Would it not make sense to release portions of what you have to the community? Keep what you need to keep to preserve your jobs, and give a little boost to projects out there like Arduino [www.arduino.cc] or Orocos [www.orocos.org].
I don't need to run an assembly line in my garage, but I would like to automate my home brew setup with a linux pc and a pic micro.
A little background on me:
I am a hobbyist. I did a 2year assoc program back in 95 and have no professional experience with automation control. I became interested in Microchip programmable ics and have been tinkering around with them and the arduino (atmel based).
You might be interested in something I have just finished - a FORTH for the PIC18F2525/4525 family.
Contact me of-line for details - b m durdle (at) xtra (dot) co (dot) nz
(ignore the spaces ...)
> You might be interested in something I have just finished - a FORTH for the PIC18F2525/4525 family. <
> Contact me of-line for details - bmdurdle (at) xtra (dot) co (dot) nz
(ignore the spaces ...) <
I get an error on that email address. So what is a FORTH?
FORTH is an operating system/programming method/self-defining language designed for embedded systems. It uses "words" not instructions and allows you to build up a solution to your needs with re-usable components in a very compact format ideal for use with microcontrollers.
My version uses the serial interface capability of the MPU to accept programming instructions from any PC running hyperterminal or similar TTY interface. The core program is approximately 8k of Flash memory.
The email address I sent was incorrect - try:
bruce (dot) durdle (at) xtra (dot) co (dot) nz
In reply to Alex B:
Standard PLCs, SCADA, and HMI systems are not normally used for safety purposes. That is usually done with dedicated and certified safety hardware. Safety hardware is usually a small part of a normal control system.
What matters for the software that is used to control a process is that it is reliable, flexible, and that it performs the desired functions. The safety system is normally able override the machine control system whenever necessary.
As for why people release software as open source / free software, well, having a piece of software is not the same thing as having a software business. Advertising, marketing, sales, promotion, billing, service, etc. can all be a lot more important to the "business" side of things than the quality of the actual software is. So, for anyone whose idea of a software business is setting up a distribution network and persuading people to part with a few thousand dollars/euros per license, they are probably in for a disappointment.
And to be realistic about things, a lot of software components are becoming a commodity just like a lot of computer hardware has. There's no money to be made in selling web server software. All the best ones are free. There's no money to be made in selling low end databases for the same reason. Programming languages have almost completely gone the same way, and operating systems are heading that way as well. None the less, IBM, HP, Red Hat, Intel, Fujitsu, etc. all seem to manage to find a way to make money out of free software.
I think that the automation industry will sooner or later go the same way. Soft logic, HMI, SCADA, data logging, and other similar systems can all be easily become commodities. Any companies who want to operate in that market will need to figure out how to fit their business into that reality, just like other software companies have had to do in markets that have already gone through that process.
In reply to M Griffin:
Our http://pvbrowser.org is free software. I think we would have no chance competing with the major vendors, because we do not have the marketing capacity.
We do not want to reinvent the wheel. Thus by using Open Source components we can build a solution that is eventually more capable as closed source solutions can be.
For the GUI part we use http://www.qtsoftware.com/
We also use data acquisition/communication libraries from other projects.
By building a framework like http://pvbrowser.org we can build HMI/SCADA solutions for our customers without paying license fees at all. Our income is from building solutions for our customers. This can be compared to building web pages for customers. We earn money by building HMI/SCADA solutions for our customers and NOT by selling software licenses.