Fieldbus Update
Dec 2, 1999 10:36 am, by Jim Pinto
Subject : Communications
from the Automation List dept.
Text :
Many people on the Automation List have contacted me regularly about Fieldbus. My paper : Fieldbus - A Neutral Vendor's Perspective was first presented at ISA, October '94 and an article with the same title was published in InTech July '95. This article presented a summary of all the major industrial networks and a comparison table. I have had many requests to provide updates. I am happy to let you know that I have now done an update - an article on the same subject, entitled : Fieldbus - Conflicting "Standards" Emerge, but Interoperability is Still Elusive This was recently published in Design Engineering (UK, Oct. 99) and is on the web at : http://www.actionio.com/jimpinto/fieldbus99.html Comments and suggestions welcome! Cheers: jim -------------------------------/ Jim Pinto Action Instruments Tel : 619-279-8836 (direct) email : jimpinto@actionio.com Action Instruments Webpage : http://www.actionio.com
Reply

• Re: Fieldbus Update
  Dec 8, 1999 1:41 pm, by Curt Wuollet
  >From a comment om Jim Pinto's Fieldbus Standards Update Hi Jim, I've been copying the mail on the "standards" debate and I have had to laugh at all these people wasting their time going to a standards meeting only to further their own agenda. In the end, as was mentioned, I fully believe that the Internet standards will prevail. This is driven by a totally new and startling concept in the automation industry: "What's good for the Customer". As someone who comes to automation from the UNIX and now Linux world, I am amazed at how fiercely anachronistic and blind the vendors in the industry can be to that concept. It is sad that we can't do anything better, but the reason that TCP/IP will prevail is that it has nothing to do with the automation industry. I am amazed that these vendors will go the way of the Old Line UNIX vendors with the motto, "Better dead than interoperable". NIH and Lock 'em In are death in almost every other market. There ARE different requirements, requiring different characteristics, but, there is no need for 30 or 40 protocols to meet them. From my perspective, the current market leaders are extremely vulnerable to a revolution carrying the banners of interoperability and "Open whatever" driven by the customers that feel they've been serviced long enough. I fully expect Cygnus and Linux to be at the fore front. I inherited a mostly GEF environment and the service and support, as well as the later products are orders of magnitude below "World Class". The treatment I have received from GE would be absolutely intolerable in an open world. My "Dark Horse" pick would be AutomationX or something like them. The only thing preventing the PC control products from taking over is the choice of Operating Systems that are every bit as proprietary and closed as what they replace. ( And notoriously unstable ) As the de facto "industry pundit" I am curious what you think, the "Mugging of Microsoft" aside. :^) Curt Wuollet, Linux Systems Engineer Heartland Engineering Co.
  Reply
  
  
• Re: Fieldbus Update
  Dec 14, 1999 3:09 pm, by Ralph Mackiewicz
  > I have had to laugh at all these people wasting their time going to a standards meeting only to further their own agenda. < EVERYBODY, including those attending IETF standards meetings, goes to these meetings to further their own agenda. This includes users, vendors, consultants, etc. > In the end, as was mentioned, I fully believe that the Internet standards will prevail. This is driven by a totally new and startling concept in the automation industry: "What's good for the Customer". As someone who comes to automation from the UNIX and now Linux world, I am amazed at how fiercely anachronistic and blind the vendors in the industry can be to that concept.< So, only IETF standards are driven totally by "What's good for the customer"? No private agendas ever make it into the IETF....NOT! I'm not suggesting that Internet standards won't prevail. But to suggest that only IETF driven standards have the purity of "customer interest" at heart is simply not true. Honest people with integrity can have different opinions. Companies who behave in ways you don't agree with may in fact be doing what they think is best for **their** customers. This may not be true in all cases, but just because the interactions of these companies, customers, consultants and committees results in multiple overlapping and incompatible standards doesn't mean that customer interests are completely ignored. The automation industry is fragmented with many competing requirements both technical and commercial. A single standard (IETF or not) is not possible. > It is sad that we can't do anything better, but the reason that TCP/IP will prevail is that it has nothing to do with the automation industry. < More precisely the reason is that: the IETF standards are used in many millions of computers. The automation industry is simply not that big and can't have that kind of impact on the IT industry. The automation industry can "piggyback" on the work of the IT industry because the IT industry is horizontal (and has the volume) in comparison to the vertical automation industry (which by nature has a smaller volume). It doesn't work the other way around. The requirements of the automation industry that are not addressed by generic IT technology are not of interest to the generic IT industry. > I am amazed that these vendors will go the way of the Old Line UNIX vendors with the motto, "Better dead than interoperable". NIH and Lock 'em In are death in almost every other market. < Proprietary systems are not death in the Internet market. If you have the market share, proprietary, selfishly-driven, and sometimes technically inferior "standards" become the IETF standard. And, in some cases, everyone else is left outside looking in further entrenching the commercial benefit of the original developer of the proprietary technology. But, because its the IETF, this is solely driven by the interests of the customer? That would be a naive assertion. > There ARE different requirements, requiring different characteristics, but, there is no need for 30 or 40 protocols to meet them. < The automation market seems to want all these protocols whether it needs them or not. After all, they keep writing new ones even though there are perfectly good existing standards that can do the job. > From my perspective, the current market leaders are extremely vulnerable to a revolution carrying the banners of interoperability and "Open whatever" driven by the customers that feel they've been serviced long enough. < We are all vulnerable to revolutions in technology. How many of us know how to program DNA sequences in a molecular biocomputer to control a machine? If the biotech industry has its way we will all go the way of the typesetter. Regards, Ralph Mackiewicz SISCO, Inc.
  Reply
  
  
• Fieldbus Update
  Dec 8, 1999 1:14 am, by Armin Steinhoff
  Here some comments: - I don't believe that 'Everyone in the industrial automation seems to be WAITING for "fieldbus" ' ... There are a lot of professionals who are USING already "fieldbus" ... since years. IMHO ... there will be never a single "fieldbus" which fits to all applications. The new "fieldbus" standard will include a defined number of different fieldbuses ... that means interoperability isn't a big issue between these buses. - Networks classifications: it ignores the fact that ETHERNET and ARCnet are going in the meantime down to the device level and PROFIBUS DPV1 covers parts of the PROFIBUS FMS domain. -> Standards are not in all cases "dead bureaucratic" stuff. - "ProfiBus was originally developed by Siemens in Europe ...": That's clearly not true! It was developed by a standardisation group as similar as ASI (developed by "Siemens and others" .... I couldn't trust my eyes :-) ) - "Profibus chips are available primarily under license from Siemens and similarly" I don't know what 'similarly' means ... - "ControlNet chips are available only from Rockwell(Allen-Bradley)". Not true ... SST offers an alternative FPGA based controller chip for ControlNet. Regards Armin http://www.steinhoff.de
  Reply