# Trends and how to grow the industry

C

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

J

J

#### Jim Pinto

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

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

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

L

#### Lynn Linse

> 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

M

C