Where do we go from here?

J

Thread Starter

Jeff Dean

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 [email protected] 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. :)
 
D

David Corking

> 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 protected] 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. <[email protected]>
 
C

Curt Wuollet

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
 
D

David Corking

> 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
 
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 protected]
 
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 protected] web: www.JimPinto.com San Diego, CA., USA ----------/
 
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 protected]
 
W
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 w[email protected] 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" ---------------------------------------------
 
C
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
 
C
<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
 
D

Dave Ferguson

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
 
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
 
C
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
 
O

Orelbi Gonzalez Miranda

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 [email protected] 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
 
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 [email protected]
 
J

Joe Jansen/ENGR/HQ/KEMET/US

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
 
W
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 protected] 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" ---------------------------------------------
 
H

Heavner, Lou [FRS/AUS]

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
 
C

Curt Wuollet

Hi Dave > From: "Dave Ferguson" <[email protected]> > > 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
 
Top