Trends and how to grow the industry

C

Thread Starter

Curt Wuollet

Hi all I have seen a trend lately with Jim and Walt and others to discuss some "High Level" issues that the industry as a whole faces. In bits and pieces across discussions that sometimes go far abroad there are some recurring themes that are truly important. Lest they disappear in the noise, I thought I'd restate them succinctly. One of my functions is futurist and I am most interested in these trends and how they relate to what I am attempting to do. As I think it through the collective wisdom appears sound, we differ mostly in what to do about it. Since these are the very problems I seek to solve, I thought this should provide constructive discussion. Trend: The industry as a whole is flat or possibly even shrinking. Offered Causes: Market Saturation, we have done about all we can do with the present paradigm. Everything that can be profitably automated has been automated and further growth will require that we move to higher level integration. My take: True, to some extent. There are still vast opportunities at the low end, the "easy stuff". The trick here is in the "profitably" part and overcoming inertia. My contention is that with the costs involved, we have only been able to address the most compelling needs for automation. I have seen in many instances, companies start down the road and after a project or two are sufficiently bloodied to lose enthusiasm. There are also expectations that we can do things that seem simple and perfectly logical but with the present tools and methods are neither. The higher end opportunities are there but the prevailing attitudes towards closed systems and proprietary solutions is a very weak and in fact, paradoxical position to address these from. Bottom line summation: If I am a company that has invested in some automation seen the elephant so to speak and now seeks to take the next step and tie these islands of automation together and to my enterprise system., my prospects are bleak or worse. If I wanted to make sure that none of my diverse systems would work together or interoperate, I'd call the Automation vendors, they are expert at preventing systems integration. Unless all your automation is from a single vendor and all your IS systems run Microsoft, there isn't much hope. On the low end, the cost of providing solutions is the barrier. How to fix it: Integration and interoperability have to be design goals going forward. This will require acceptance of common standards. protocols, and Open Systems. If there were one universal communications method, the difficulty of integrating systems would decrease by several orders of magnitude. If it were truly open, the drivers would get written on the IS side even for legacy systems and oddballs. The only way that this can realistically be accomplished is if those means are absolutely independent and publicly owned. period. If it even appears that any one vendor or group of vendors can control it in any way, Game Over. If it's owned by a consortium. Game Over. We have already tried those two approaches many times with each one being a complete and utter failure. Public ownership is the only possible way to get full participation in this climate. This industry is also hobbled by the enormous cost of duplication. Not only are there 50 complete lines of incompatible products that accomplish the same tasks, there are at least 25 incompatible busses to do it on. This is not the way to grow an industry. This is not the way to lower costs. 98% of that R&D money was wasted in terms of providing solutions especially at the low end. If the PC industry were still working this way, it would be in the same shape. The ubiquitous, efficient, cheap, networking that makes this message possible is the direct result of standardization around the Internet Protocols. These, it can be argued, are not publicly owned. but they started out that way and at this point they cannot be manipulated to the advantage of any one commercial entity so the effect is the same. Growing sideways is obviously not working at providing explosive growth in this industry. To move forwards requires the same sort of changes that take place in any volume based industry. None of the 50 product lines is going to achieve the volume to lower costs and improve efficiency in delivery of services. Suppose all the cost and effort to maintain all these parallel solutions were concentrated on a few. How much more progress could be made? How much more efficient would support be?, programming? Suppose hardware was compatible. How much less would it cost? Suppose that every one used the same languages and algorithms and common modules were shared. How much less of a project would be programming and how many fewer bugs and problems would there be. How can this be accomplished in this hyper competitive industry? Perhaps it can't. Some days, I begin to think that way. But, if it can, it will be by providing a strictly independent, publicly owned alternative that can be readily expanded, changed, and adapted at will to cover the maximum number of situations. In this way it can achieve volumes where code reuse and commonality attack the problems facing the industry. I'm curious how some of you others see the situation and what exactly you are doing to fix it. Regards cww
 
D

David McGilvray

Hi Curt, I'll bite. I agree with the stated trend and the various market symptoms. My prescription, however, is slightly different. At this point I'll declare my affiliation with automationX since my forecast, while not necessarily requiring automationX specifically, certainly fits the paradigm. I believe that the future of automation will look remarkably like the internet. The internet provides an instructive example of distributed computing. The internet model includes ubiquitous independent thin clients, standardized network protocol and robust servers effectively managing multi-million dollar businesses. The robust servers, in the industrial landscape, instead of interacting with various databases will connect directly to commodity I/O modules and, in the future, commodity final elements (sensors, actuators, etc.). The server software provides the control system functionality (control, data archiving & trending, visualization, alarming, simulation, on line help, etc. as required). As well, the server software will provide the glue to seamlessly connect downloaded software (algorithms) in distributed i/o modules, etc. The advantages are pretty clear. First, industrial automation practitioners finally get a taste of the power of the network. Rather than dedicated operator stations (even if PCs), users including engineers, maintenance personnel and operators will interact with the system using common browser like software than can be easily loaded an any standard machine that doesn't necessarily need to be dedicated to the task. Maintenance and engineering types especially increase efficiency exponentially, by accessing the various systems under their responsibility from wherever they are using existing hardware. While not necessarily using the public internet, users can instantly connect to the process regardless of where they are in the plant, city, or even country, provided a network connection is available. Secondly, the server concept is crucial, not withstanding the inherent reluctance from many on this list and the industry. Clearly a variety of technical solutions are available and actively used by IT people for internet and other mission critical applications, details of which I would be happy to discuss with those interested, to provide the reliability of any DCS and PLC offering. The key, however, is the decoupling of software from the proprietary hardware and rehosting on commodity hardware to ensure standardized protocols and open hardware. The field side will be populated with i/o modules and final process elements that are mixed and matched according to capabilities and not proprietary networks. Today a variety of open fieldbus networks are available that achieve just this, including Profibus and others. Decoupling (ie the end of DCS and PLC as we know them today) can be expected to further the acceptance of open bus networks and increase the proliferation, lower the cost and increase features of the available networks. Eventually, I would expect an office Ethernet (perhaps even Ethernet) will rapidly emerge. The end result is that competition and interoperability exists at all levels for both hardware and software, including the client, server, and field, with barriers effectively removed at all levels. Each component competes on its own merit and can be replaced at any time like switching brands of pencils. Costs plummet and products with favoured features are rewarded. The model is elegant, simple and proven. The only barrier to acceptance seems to be the vested interests of the 50 odd existing vendors and the sheep like behaviour of users and integrators who have blindly accepted their dated message. Best Regards, dwm
 
D

Dave Ferguson

I have listened to this for months and I will relate my experience where I work and I still say it has had an effect even though others don't/won't admit it. In 1998 we purchased 100's of PC's for control and networked everything together. We also implemented an ERP due to "Y2K" and passed a ton of information back and forth. We paid Millions$$$$$ doing Y2K audits and going through all of our vendor equipment from Provox DCS's to programs written in Allen Bradley data basic modules to GE drives to ABB systems and on and on. The reality is we found very few bugs but we got caught up in all the fervor just like a lot of companies because noone really knew so therefore better safe than sorry....... Also many jumped on board and got "pet" projects pushed through under the "Y2K" issue and management bought into that excuse. We updated versions of perfectly fine DCS modules etc. "just in case"........we updated old PC's and equipment.....tore out an old IBM mainframe and replaced it (unfortunately) with BAAN and on and on. So in 1998, 1999 and early 2000 any vendor that sold to us and all of the vendor consultants made great profits from us and I assume many others.......................As well as huge amounts of internal resources used on this issue. Then 2000 shows up and very little issues appear (a couple)....management starts questioning the sanity of all of this money spent and 2001's budgets are slashed because we spent so much and double the scrutiny for any "automation" or "IT" project. Now all of these vendors got big dollars for a couple of years and really thin profits for a couple of years and the net result is a couple of great years and a couple of very poor years. Problem is this economy has no long term outlook. We work on a quarter to quarter report world and guess what.......bad quarter.....lay off everyone and "M&A". No profits this quarter....sell your stock and go somewhere else. We put all of our eggs in the quick buck (get rich quick) theory and now we are paying for it...........The other side of the coin involved "CUSTOMER SERVICE"....when money is rolling in left and right, slash customer service...who needs those damn customers. Now customers are demanding service and yet with no income or very discrete spending, no budget for customer service and the viscous circle goes on and on. We reached for the brass ring and made easy money a few years ago and unfortunately crammed many years of updates and revisions into a couple of years and now will pay for that for the next 5-10. There are many other factors involved but IMHO this had a major effect on the problem at least that is what I see at our small corporate piece of the pie. (2-3rd largest forest products corp. in the world, depending on who's survey you use) UPM-Kymmene...... These are my not UPM's opinions but I would like to hear how others see this spending issue (Y2K). I am not trying to create some big Y2K debate as many threads have touched on but rather the "Aftermath" of this debacle. I also am not so foolish to think this is the only issue involved......just one of them but not one to be ignored.......We are all trying to justify our decisions and don't want to talk about them...... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation
 
C

Curt Wuollet

Hi Dave The only place we really differ is on private ownership of the IP, protocols, etc. You guys believe that you can do it with proprietary software and live with the existing mess. I have observed that if you are a competitor, you can not attract any cooperation or bring people together. I like your product but interoperability is still an issue. We seek to find a way to form a cooperative effort that is neutral and impartial so that companies can contribute to the common good without aiding a competitor. I'm cautiously optimistic that if there ever will be cooperation and consensus, our model will be the most attractive. Replacing proprietary with less proprietary isn't as good a solution but it's a step in the right direction. Regards cww
 
Hello, Automation List : Curt Wuollet <[email protected]> has written a significant and insightful commentary on Automation biz trends. Curt agrees that the market is saturated, and re-caps the reasons. He correctly wishes to review the causes and offer solutions. I hope this important subject brings a lottttt of discussion from all us Engineers. The industry as a whole is flat or possibly even shrinking. Curt : >Market Saturation: we have done about all we can do with the >present paradigm. Everything that can be profitably automated >has been automated and further growth will require that we >move to higher level integration. Jim Pinto : Nope! Higher level integration will NOT increase the size of the market. The needs are the needs, and doing more does NOT increase the needs. Indeed, lowering the price often REDUCES market size : If I need an alarm relay, the availability of a half-price product does NOT double the market. Curt : >There are still vast opportunities at the low end, the "easy stuff". Jim : Nope ! The "easy stuff" becomes a commodity, and the "horde of hungry hangers on" starts to lower the price. Curt : >The higher end opportunities are there but the prevailing attitudes >towards closed systems and proprietary solutions is a very weak >and in fact, paradoxical position to address these from. Jim: Yep ! Curt : >Bottom line summation: If I am a company that has invested in some >automation and now seeks to take the next step and tie these >islands of automation together and to my enterprise system, >my prospects are bleak or worse. >The Automation vendors, they are expert at preventing systems >integration. Unless all your automation is from a single vendor and all >your IS systems run Microsoft, there isn't much hope. >On the low end, the cost of providing solutions is the barrier. Jim : Right on, my friend! Every read the above paragraph 3 times, and memorize! Curt : >How to fix it: >Integration and interoperability have to be design goals going forward. >This will require acceptance of common standards. protocols, >and Open Systems. Public ownership is the only possible way to get >full participation in this climate. Jim : Right ! But, in a small and relatively closed-end market, that is a dream which will be VERY difficult to atain. Curt : >This industry is also hobbled by the enormous cost of duplication >Not only are there 50 complete lines of incompatible products that >accomplish the same tasks, there are at least 25 incompatible busses >to do it on. Jim : Amen, brother Curt ! Curt : >Growing sideways is obviously not working at providing explosive growth > in this industry. To move forwards requires the same sort of changes >that take place in any volume based industry. None of the 50 product >lines is going to achieve the volume to lower costs and improve efficiency >in delivery of services. Jim : The primary problem in Industrial Automation is LOW VOLUME - hence only custom solutions at a high price are available. Curt : >Suppose all the cost and effort to maintain all these parallel solutions > were concentrated on a few. How much more progress could be made? > How much more efficient would support be? programming? > Suppose hardware was compatible. How much less would it cost? >Suppose that every one used the same languages and algorithms >and common modules were shared. How much less of a project would >be programming and how many fewer bugs and problems would there be? Jim : All good questions - and all dreams in the industrial automation business for 2 primary reasons : 1/ Low volume and 2/ Vast variety of needs. Curt : >How can this be accomplished in this hyper competitive industry? >Perhaps it can't. Jim : No one has yet found a way. I laud Control.com and others who are trying to stimulate Open Systems. Curt : >If it can, it will be by providing a strictly independent, publicly owned >alternative that can be readily expanded, changed, and adapted at >will to cover the maximum number of situations. In this way it can >achieve volumes where code reuse and commonality attack the problems > facing the industry. Jim : Curt - your entire (fairly long) email (which I have clipped here, for brevity) should be published - I invite InTech, Control Engineering, I&CS, CONTROL - one of the major industry journals, to publish Curt's comments in entirety! Cheers: jim ----------/ Jim Pinto email : [email protected] web: www.JimPinto.com San Diego, CA., USA ----------/
 
Automation List : David McGilvray <[email protected]> gave us a good plan to grow the industry through : >"competition and interoperability exists at all levels >for both hardware and software, including the client, >server, and field, with barriers effectively removed at all >levels. Each component competes on its own merit and >can be replaced at any time like switching brands of >pencils. Costs plummet and products with favoured >features are rewarded." Jim Pinto responds : A wonderful engineering Valhalla! But, sadly NOT a practical Marketing possibility. Because - again - the industrial automation business has low volume and custom, fragmented requirements. David McGilvray comes to the same conclusion : >The model is elegant, simple and proven. >The only barrier to acceptance seems to be the vested >interests of the 50 odd existing vendors and the sheep >like behaviour of users and integrators who have blindly >accepted their dated message. Jim : You are SO RIGHT! There is a Marketing reason for the "vested interests" of the 50-off vendors and the "sheep-like behavior" of the users and integrators. The market is stagnant and even declining. None of the vendors are making enough money to do much beyond survival. The integrators have low margins, and are "downstream" followers. The end-users are simply too busy with other priorities and too short-sighted to look much further than tomorrow. Solution : Inflection point - new technology that will change EVERYTHING, with significant 10-times-better results! The dinosaurs will be dead, and new leaders will emerge..... Cheers: jim ----------/ Jim Pinto email : [email protected] web: www.JimPinto.com San Diego, CA., USA ----------/
 
D

David McGilvray

Hi Curt, I think you raised two important issues, at least one of which has been touched be a previous poster. 1. Proprietary vs GNU or public products. Without a doubt, GNU products are very attractive - certainly due to the cost and frequently the result of attractive features. The success of Linux, both from a participation as well as an adoption perspective, is testament to this approach. Indeed, we think Linux is a great product that we fully support. This approach, however, is generally restricted to software products where product cost is predominantly labour that can be donated on an individual basis. The widespread development of products under this model, particularly where the end users are commercial, for profit enterprises, is questionable. On the other hand, there is a very definite place for commercial products, as the marketplace determines. For both software and hardware, I think it is quite valid for firms to develop and market their products. Of course, the resulting products will not be free, as labour and material inputs, and hopefully profits, must be addressed by a sticker price. I think the development of an operating system for the masses by the masses is a reasonable scenario. The development of, for example, an ERP product, on the other hand, which is used exclusively by corporations (and predominantly large multi-nationals), using donated labour has dubious prospects. The Linux PLC project not withstanding, a soft (server based per my stated model) DCS, like automationX, I think falls into the latter category. Regardless of whether a GNU free or commercial product (or a mix) prevails, however, it seems we both agree the server based model outlined previously will prevail. 2. Open & Proprietary. I get the distinct impression that open, from your perspective, necessarily requires the GNU or equivalent model (ie donated labour where the product including source code is available for free). I don't believe this. AutomationX, for example, is a proprietary product that we license to users. At the same time, automationX is, in my opinion, totally open. We comply with a number of open protocols - we use TCP/IP for client server communication and Profibus predominantly on the field side. Although over the years we have developed a number of interfaces, as a necessary requirement in today's heterogeneous industrial environment, we certainly do not go out of our way to jump on the latest bus bandwagon and generally have many times fewer interfaces than offered by typical HMI/SCADA products (which we really are not). Interestingly, and a testament to our openness, the tools we use to develop interfaces are fully available to end users and/or integrators. Finally, I would have to vehemently disagree with your assertion that we believe in private ownership of IP, protocols, etc. On the contrary, we embrace open industry standards, especially IP, protocols, etc. In fact, automationX, if a competitive product (GNU or proprietary) where available, very much complies with the model I proposed where all individual components (software and hardware) including the client, server, & field components should be individually interchangeable. Best Regards, dwm
 
C

Curt Wuollet

Hi Dave > I think you raised two important issues, at least one of which has been > touched be a previous poster. > > 1. Proprietary vs GNU or public products. Without a doubt, GNU products are > very attractive - certainly due to the cost and frequently the result of > attractive features. The success of Linux, both from a participation as > well as an adoption perspective, is testament to this approach. Indeed, we > think Linux is a great product that we fully support. This approach, > however, is generally restricted to software products where product cost is > predominantly labour that can be donated on an individual basis. The > widespread development of products under this model, particularly where the > end users are commercial, for profit enterprises, is questionable. > > On the other hand, there is a very definite place for commercial products, > as the marketplace determines. For both software and hardware, I think it > is quite valid for firms to develop and market their products. Of course, > the resulting products will not be free, as labour and material inputs, and > hopefully profits, must be addressed by a sticker price. > > I think the development of an operating system for the masses by the masses > is a reasonable scenario. The development of, for example, an ERP product, > on the other hand, which is used exclusively by corporations (and > predominantly large multi-nationals), using donated labour has dubious > prospects. The Linux PLC project not withstanding, a soft (server based per > my stated model) DCS, like automationX, I think falls into the latter > category. Regardless of whether a GNU free or commercial product (or a mix) > prevails, however, it seems we both agree the server based model outlined > previously will prevail. We disagree on the viability of the public development model. Spreading the cost of development to the users provides potentially much greater resources and certainly more objectivity than any single company can afford. We can be solution oriented rather than profit oriented. And we can be an ally to everyone and a threat to no one. As you know, I like your product and have provided only constructive criticism on the problems we saw when we considered distributing it. I am still interested, but the moment may have passed for the people who pay me. I am a pragmatist and a capitalist. Although the "Red Baiters" have already suggested that I am a communist and I've heard an anarchist. I agree with Joe that if there a way to address these needs in a commercial model and the problems would simply go away, I could live with that. I am closer to ESR than to RMS. That is, more OSS than GNU. I am not convinced that everything must be free, (as in free beer) merely that the parts needed to integrate systems and allow interoperability be really truly open or at least to the extent of say Modbus/TCP where I can implement them on an open platform to get the job done. With regard to LPLC vs AutomationX, you can prevent anyone else from exploiting or hijacking your product with the normal commercial means. To prevent anyone from exploiting or hijacking LPLC, we _have_ to use the GNU Public License as it is the only one that lets anyone contribute without having their freely given gift ripped off. The once free, always free provision makes it possible for companies to donate code to LPLC and not see it in a competitive commercial product. My philosophy doesn't enter into it. It is the only way we can make it "safe" to contribute. If the LPLC were perceived for a moment to be anything but totally independent and vendor neutral, we become a competitor. That is, by the way, why I refer to it as LinuxPLC and not PuffinPLC, Ken owns that domain and name and despite his kindness and generosity in giving us a home, we can't afford to be seen as "belonging" to control.com. We have the responsibility of preventing any contribution from ever being exploited or used to the detriment of the contributor or the public. We can't have anyone ever regret acting in the common interest. That doesn't sound like anarchy to me, it's highly principled. I take it very seriously. LPLC must belong to all or none. The important point here is that I see LPLC as a way that people can cooperate to solve the problems without giving away the store. This is widely misunderstood, I think. We can be the neutral go between. We seek to be a solution not a threat. > > 2. Open & Proprietary. I get the distinct impression that open, from your > perspective, necessarily requires the GNU or equivalent model (ie donated > labour where the product including source code is available for free). I > don't believe this. AutomationX, for example, is a proprietary product that > we license to users. At the same time, automationX is, in my opinion, > totally open. We comply with a number of open protocols - we use TCP/IP for > client server communication and Profibus predominantly on the field side. > Although over the years we have developed a number of interfaces, as a > necessary requirement in today's heterogeneous industrial environment, we > certainly do not go out of our way to jump on the latest bus bandwagon and > generally have many times fewer interfaces than offered by typical HMI/SCADA > products (which we really are not). Interestingly, and a testament to our > openness, the tools we use to develop interfaces are fully available to end > users and/or integrators. > > Finally, I would have to vehemently disagree with your assertion that we > believe in private ownership of IP, protocols, etc. On the contrary, we > embrace open industry standards, especially IP, protocols, etc. In fact, > automationX, if a competitive product (GNU or proprietary) where available, > very much complies with the model I proposed where all individual components > (software and hardware) including the client, server, & field components > should be individually interchangeable. > > Best Regards, > dwm Dave, I think you misread what I wrote. I wasn't necessarily referring to _your_ ownership of IP, protocols, etc. I do see open as a binary not a continuum. It wouldn't be a big deal but in this industry they call black white and have abused the word open to the point where it has no meaning. My use of the term is is quite clear. Let's not quibble. I am glad to see a Linux product in the mix and wish you well. I will take another look for Heartland Engineering projects and those I consult to. Regards cww
 
R

Ralph Mackiewicz

I've tried to stay out of this but I just can't help myself when I read some of this malarchy. > >The Automation vendors, they are expert at > >preventing systems integration. I don't know how to say this nicely: To believe that automation vendors sit around thinking about ways to "prevent" systems integration is delusional (I'm glad I toned that down). Automation vendors may not care whether they can provide integration for other peoples products. And, they may not care whether they support public non-MS standards. But, there is no purposeful effort (aka conspiracy) to screw users. If they are too stupid to see the benefit that promoting industry-wide interoperation would bring to their company they are also too stupid to coordinate a massive global conspiracy as well. I think someone recently explained it better by pointing out the silly and counter-productive bureaucratic structures that exist at some of these vendors. That I could believe. > >This industry is also hobbled by the enormous cost of duplication Not > >only are there 50 complete lines of incompatible products that > >accomplish the same tasks, there are at least 25 incompatible busses > >to do it on. > > Jim : > Amen, brother Curt ! Amen too. 25 incompatible systems is exactly what the market wants because that is exactly what the market buys. The automation market is fragmented in many ways and this plethora of comm solutions is simply a natural result of that fragmentation. Regards, Ralph Mackiewicz SISCO, Inc.
 
C
Ralph Mackiewicz wrote: > > I've tried to stay out of this but I just can't help myself when I > read some of this malarchy. > > > >The Automation vendors, they are expert at > > >preventing systems integration. > > I don't know how to say this nicely: To believe that automation > vendors sit around thinking about ways to "prevent" systems > integration is delusional (I'm glad I toned that down). Automation > vendors may not care whether they can provide integration for other > peoples products. And, they may not care whether they support public > non-MS standards. But, there is no purposeful effort (aka conspiracy) > to screw users. If they are too stupid to see the benefit that > promoting industry-wide interoperation would bring to their company > they are also too stupid to coordinate a massive global conspiracy as > well. I think someone recently explained it better by pointing out > the silly and counter-productive bureaucratic structures that exist > at some of these vendors. That I could believe. Let me pull on my analyst hat again and spell it out for you. Connectivity and interoperability, "plug compatibility", if you will, are _strategic_. In the beginning there was Modicon. All the startups supported Modbus and friends. The strategy was to carve out a piece of the existing market by being plug compatible. This strategy led to a short period where you could actually dump one vendor for another. Once market share was established, another strategy was called for. Everybody migrated their customer base to their own protocols. This strategy was twofold. It prevented the customers from jumping ship and by being wholly owned and controlled it prevented anyone else from adopting your protocols and carving out a portion of your pie. This has escalated to ridiculous proportions. This is the status quo. There are a few independents whose strategy is parasitical on a single large customer base or as an alternate to be plug compatible with everybody. These are pretty much inhibited by threat of lawsuit. The fieldbus folks have tried an end around, but have created their own mess by settling on proprietary stuff which means each new effort has to roll their own. Result....deadlock. The computer industry has had a parallel progression from IBM monopoly to plug compatibility to chaos to standardization. The real growth has come from standardization. The current situation is not inadvertant but strategic. I don't think anyone knows how to kill the monster they have created that gobbles huge amounts of diminishing resources. We seek to provide that next strategy in a healthy face-saving way and tear down the walls, it's in everyone's best interest. > > >This industry is also hobbled by the enormous cost of duplication Not > > >only are there 50 complete lines of incompatible products that > > >accomplish the same tasks, there are at least 25 incompatible busses > > >to do it on. > > > > Jim : > > Amen, brother Curt ! > > Amen too. 25 incompatible systems is exactly what the market wants > because that is exactly what the market buys. The automation market > is fragmented in many ways and this plethora of comm solutions is > simply a natural result of that fragmentation. Everyone bought black Model T's too. The auto industry prospered when someone came along and offered a real choice of colors and platforms. Henry Ford's "They can have any color they want as long as it's black" is the stage we are in today. In the not too distant future the proprietary duplicative model will seem just as dated. Strategy... Regards cww
 
D

Dave Ferguson

I agree with Ralph Just like there are many, car manufacturers, cell phones, VCR's, light bulbs and on and on, because the public demands it...... Dave Ferguson Blandin Paper Company UPM-Kymmene DAVCO Automation
 
J

Joe Jansen/ENGR/HQ/KEMET/US

And the public also demands that all those cars use the same fuel. All those cell phones work off of the same towers. (ie: my Nokia can call a Motorola) All VCR brands work with all TV's Light bulbs screw into the same sockets. That's my point. Interoperability between brands. I would be better convinced if you show me different brands of the same product that are completely incompatible. Like PLC's. --Joe Jansen
 
> All VCR brands work with all TV's > > That's my point. Interoperability between brands. I would be better > convinced if you show me different brands of the same product that are > completely incompatible. Like PLC's. But in the same way that "any" VCR can work with "any" TV, so "all PLC" work the same. I can take PLC from Koyo, Modicon, and AB - each with 8 110vAC input and 8 relay out and they are all interchangeable in the high-level sense. I can swap one out and another in & control will be the same. The 8 inputs relate to the 8 outputs in the same manner. Just like the VHS tape in my VCR shows me the image on the TV. But a Sony VCR is NOT the same to program as an Emerson VCR - that's what all those "magic codes" you need to enter into your Remote mean. Each has thier own proprietary commands and proprietary data and the world keeps turning just the same. The universal remote just uses the "magic code" to handle any specific proprietary details of this one brand of appliance. Sounds like OPC drivers of sorts to me. Maybe we just need to find the lost book of "magic codes" which allow any HMI or programmer to talk to any PLC? Sounds like a quest for Bilbo (sp?) of Tolkien fame. regards - Lynn A. Linse
 
I

Ian Verhappen

I believe it was stated earlier in this thread that the potential is there, all we need is the will power to make it happen. IF we could all agree on which 'flavour' of Ethernet to use as a backbone, and which 'flavour' or maybe even a few 'flavours' of fieldbus to use we could soon have an all Digital Control System (new acronym for DCS) thus allowing us to use 'best in class' devices for each level of our integrated control and business system architecture. Of course, having everything able to talk to each other electronically is only one part of the story. We also need to be able to interchange the devices in the field which implies similar form factors and face to face and/or process connections. ISA S-97 is trying to start some work in that area. If you are interested in helping let me know. Let's grow together. Ian Syncrude Canada Ltd. PO Bag 4009, MD 0032 Fort McMurray, AB T9H 3L1 P 780 790-4079, Cell -799-6017 F 780 799-5190 [email protected]
 
R

Ralph Mackiewicz

> And the public also demands that all those cars use the same fuel. All > those cell phones work off of the same towers. (ie: my Nokia can call > a Motorola) All VCR brands work with all TV's Light bulbs screw into > the same sockets. These analogies aren't very good for a number of reasons (e.g. All cell phones don't work off the same towers. I have a cell phone that only works with SprintPCS. Yes I can communicate with any other phone through SprintPCS but I can't change my service provider because Cingular (or whoever) won't interoperate with my phone). > That's my point. Interoperability between brands. I would be > better convinced if you show me different brands of the same > product that are completely incompatible. Like PLC's. But the critical point is that all of these examples of integration are the norm because the buyers of these products demand it. The vast majority simply won't buy an audio speaker that doesn't have an 8 ohm load with 2 wires (for example). The majority of people who buy PLCs simply don't care if every PLC is made with indentical programming software or an identical communications port. They care that they can implement the job at hand but they haven't been able (or willing) to attach VALUE to uniform standards in the PLC industry for communications (and to a lesser degree) programming software. I personally think that this is short-sighted, but then again, I don't buy PLCs so what do I know? I assume that the people who do buy PLCs are smart enough to buy what is good for them. They obviously think numerous communications standards is not that big of a problem as long as they can buy the products they need for the system they are using at the moment. If buying habits changed towards standards, the majors would all become involved in a massive global conspiracy (aka the "market") to develop and support those standards. Regards, Ralph Mackiewicz SISCO, Inc.
 
A

Anthony Kerstens

Actually, not all VCR's work with all TV's. There is NTSC and PAL. That's why there are services around for video conversion. And then there's also the coming HDTV and web based media. And then DAT, CD, MP3, and that old 8 track I have in my basement. Looks to me like consumer electronics is just as confused as automation. Anthony Kerstens P.Eng.
 
R

Ralph Mackiewicz

> Let me pull on my analyst hat again and spell it out for you. > Connectivity and interoperability, "plug compatibility", if you > will, are _strategic_. I don't think anybody disagrees with that (communications ARE strategic). What I disagree with is the contention that the majors purposely try to prevent integration ("experts at preventing integration" was the term). They don't think that your definition of equipment interchangeability via a standardized application protocol is what their customers want/need. You can disagree with them, as I do partially, on this point but: from personal experience I can tell you that the people within these companies firmly believe that they are behaving in a manner consistent with the best interests of their customers. Many of their customers reinforce that explicitly (by endorsing their activities) and implicitly (by buying their equipment). I strongly disagree with you that their intent is to screw the user. > In the beginning there was Modicon. All the startups supported > Modbus and friends. The strategy was to carve out a piece of the > existing market by being plug compatible. This strategy led to a > short period where you could actually dump one vendor for another. > Once market share was established, another strategy was called for. > Everybody migrated their customer base to their own protocols. This > strategy was twofold. It prevented the customers from jumping ship > and by being wholly owned and controlled it prevented anyone else > from adopting your protocols and carving out a portion of your pie. Your history is a bit off. Modbus was not universally accepted in the early days of PLCs. Acceptance of Modbus came much later. The early motivation to develop your own protocol was not driven by customer retention concerns, it was technical. If you wanted to support on-line programming over the same port as data access you had to develop your own protocol for it. I specifically remember this process when I was an engineer at Westinghouse's PLC group, Numa-Logic. We looked at Modbus but it did not provide the services needed to implement the features we wanted (at least the published version did not). No one from the marketing or the business side told us that we could not use Modbus. In fact, it would have been a stroke of genius to do this because we would have loved to capture market share from Modicon at the time. But we were not that smart then and NONE of our users (or potential users) asked for this at that time. We did not use Modbus because it couldn't fit the requirements. I am very confident that Data Highway, GELAN, SyNet, etc. etc. were all developed with the same basic motivations. Interoperation of equipment was simply not a consideration at that time (late 70s). The Personal Computer wasn't even an idea then. PC stood for programmable controller. Once again you attribute purposeful (and vindicative) motives to a result that happened accidentally. In hindsight, I wish we were smart enough at the time to predict the future, but the truth is we weren't that smart or prescient. > The fieldbuss folks have tried an end around, but have created > their own mess by settling on proprietary stuff which means each > new effort has to roll their own. I suppose this depends on the definition of "proprietary". > The current situation is not inadvertant but strategic. The issue I am arguing is inadvertent versus purposeful malicious intent. I maintain that the current situation is a natural result of vendors trying to satisfy customer concerns in a highly fragmented market. There is no widespread desire (anymore) by the vast majority of IA users to utilize a single application protocol to which all the vendors can respond in a unified fashion. You have a need for this, and I think its a good idea, but most users don't seem to care about this. > > > >This industry is also hobbled by the enormous cost of duplication > > > >Not only are there 50 complete lines of incompatible products > > > >that accomplish the same tasks, there are at least 25 > > > >incompatible busses to do it on. > > > > > > Jim : > > > Amen, brother Curt ! > > > > Amen too. 25 incompatible systems is exactly what the market wants > > because that is exactly what the market buys. The automation market > > is fragmented in many ways and this plethora of comm solutions is > > simply a natural result of that fragmentation. > > Everyone bought black Model T's too. The auto industry prospered when > someone came along and offered a real choice of colors and platforms. > Henry Ford's "They can have any color they want as long as it's black" > is the stage we are in today. In the not too distant future the > proprietary duplicative model will seem just as dated. You make my case. Users did not want the standard of a black model T. They opted for a plethora of different makes and models with non- interchangeable parts (even between model years). Once the industry abandoned the black Model T paradigm it grew tremendously by providing what customers wanted: constantly changing models (accompanied by excited marketing). This is exactly how we ended up with 25 incompatible systems: vendors responding to their customers. Mistakes are very easy to spot looking backward and very difficult to predict looking forward. Regards, Ralph Mackiewicz SISCO, Inc.
 
M

Michael Griffin

At 16:59 15/02/01 -0500, Ralph Mackiewicz wrote: <clip> >There is no widespread desire (anymore) by the vast majority >of IA users to utilize a single application protocol to which all the >vendors can respond in a unified fashion. You have a need for this, >and I think its a good idea, but most users don't seem to care about >this. <clip> This is more or less a chicken and egg problem. People will develop useful and profitable software products which can make use of communications to each machine provided the machines can easily be connected together. For example, most customers could see a benefit to a system which will tell them how efficiently their equipment is performing and give them hard data on down time, etc. The problem with implementing something like this though is trying to talk to the hardware. I'm sure it can almost always be done but it adds to the cost and complexity, which must be set against the potential savings. Something like this will only become popular when the communications becomes easy. At that point, universal communications will be something everyone will expect. I recall that PCs were around for a number of years before office networking became popular. Now, even very small businesses take office networking of PCs for granted. Widespread networking has changed the way PCs are used and created entirely new applications (e-mail, etc.). Few businesses today would consider buying an office PC which could not be networked. I forsee the same thing happening with industrial controls. If you want to see the sort of application I am talking about, take a look at: http://www.executivetechnologies.com/ I don't have any connection with the company other than I am looking at using their software in our plant. They produce software which monitors your production equipment, collects real data, and helps you analyse where your production bottlenecks are. The tough and expensive part (at least in my situation) is getting the PLCs to talk to it. Please keep in mind that I am not offering any sort of recommendation on the company or their particular product since I haven't used it myself yet. But this is the *type* of product which I think will cause customers to suddenly decide that all their PLCs need to communicate. Other companies are bound to come up with even more ideas. At that point simple, easy, and inexpensive connections to a plant wide communications system will be one of the most significant points on which PLCs are judged. ********************** Michael Griffin London, Ont. Canada [email protected] **********************
 
C
Hi Ralph Ralph wrote: <clip> .... > But the critical point is that all of these examples of integration > are the norm because the buyers of these products demand it. The vast > majority simply won't buy an audio speaker that doesn't have an 8 ohm > load with 2 wires (for example). The majority of people who buy PLCs > simply don't care if every PLC is made with indentical programming > software or an identical communications port. They care that they can > implement the job at hand but they haven't been able (or willing) to > attach VALUE to uniform standards in the PLC industry for > communications (and to a lesser degree) programming software. I > personally think that this is short-sighted, but then again, I don't > buy PLCs so what do I know? I assume that the people who do buy PLCs > are smart enough to buy what is good for them. They obviously think > numerous communications standards is not that big of a problem as > long as they can buy the products they need for the system they are > using at the moment. If buying habits changed towards standards, the > majors would all become involved in a massive global conspiracy (aka > the "market") to develop and support those standards. The hole in that theory is that no one has offered the option of things that work together. Let me draw an analogy as long as everyone else has :^) A lot of people could really use a basic plain jane get to work car (or truck) All the vendors tell us that's the last thing we want and offer a lot of luxury vehicles and trucks with leather upholstry. And their argument is the same, "We don't sell any of those" This _is_ logical since they don't offer any of those. Chrysler had the last one with their Omni and Horizon America series. They quit making them when they had two lines running and the cars were on allocation and selling over sticker. I'm sure those lines went to producing vehicles with a larger margin. Nothing wrong with that, just don't tell me that's what the "public demanded". Which is exactly the same line they used The truth of the matter is that after people rallied to help them out of their dire situation, they forgot them and went to the same "high margin only" policy as Ford and GM. And the Japanese won't help this time as they (with the help of their Big 3 investors) held the same line. That's why even the low line vehicles are outfitted like the space shuttle. Because "That's what the market demanded" The public can demand basic vehicles all they want but strangely, they buy only what's available. And none at all of the non-existant. Kinda skews the statistics to suit the vendors. Regards cww
 
> A lot of people could really use a basic plain jane get to work > car (or truck) All the vendors tell us that's the last thing we > want and offer a lot of luxury vehicles and trucks with leather > upholstry. And their argument is the same, "We don't sell any of > those" This _is_ logical since they don't offer any of those. I hate to say it, but the whole car analogy is pretty weak. But the market response is not. The above statement is about as accurate as it gets. The customer doesn't always know what he/she "wants" because the customer doesn't always know what is possible. (why do I feel myself getting flamed for that one) For instance: Cellular phone development started 20 years ago (give or take). Did you know you wanted one? Did you know it was possible? Was the market screaming for wireless phones? Did you want a 24 hours news channel that repeats the same stories every 30 minutes? Was the market for "news" going to revolt without it? Before it was created, did you know you wanted a PLC to replace all your pneumatic and relay controls? Personal copiers? Fax machines? Safety pin? Post-it notes? To my knowledge and recollection, the market for these products were not demanding that the manufactures of these products create them. They didn't even know it was possible, and no one even imagined how these products would change the world when they were introduced. I suggest that, thought the technologies are closely related and in many cases identical, the best analogy is computing. Imagine if your company standardized on IBM PC's... but IBM PC's could only network with other IBM PC's. Further consider if you could only use IBM monitors, keyboards, hard drives, and mice. How difficult would it be to bring a Compaq or Dell computer into your company knowing that it would not communicate with the IBM computers? What if you had to pay thousands of dollars to buy protocol "bridges" so your IBM computers could talk with your Company computers? Insane you say? Well, I say it's insane that AB doesn't talk to Siemens. The advantages to the end user may not all be obvious, but imagine if the majors all shared a common protocols for data and I/O. Systems could then be built with the best equipment, not just what works with the hardware that's already installed. I hope you will spend some time to imagine the new solutions that would be possible, and the opportunity that would ensue if Siemens, AB, Honeywell, GE, and Modicon hardware were all interchangeable without functional loss? I'd be surprised if you couldn't imagine at least a few advantages such as cost savings, availability of spare parts, ability to use another vendors specialty I/O, freedom of choice - to pick the best product at every level and stage of your applications. Real competition in all aspects of the automation system (ever felt raped by the cost of I/O cards? Because they have you locked in to a controller, network, and protocol!). Think about it - I have, Jeff Dean [email protected]
 
Top