Communication protocols

T

Thread Starter

T.POL

I am working with PLCs and automation systems for seven years. All these years I am learning for different types of communication (Profibus, ArcNet, RCOM, Modbus, Ethernet etc) What is the
reason (except the commercial) of having so many "different" communication protocols instead of having one common protocol for all systems which will give the possibility (if the companies
wanted to do so) to connect different systems (PLC, SCADA, SENSORS etc) from various companies?

I am looking forward to receiving from you
Best regards
Tassos Polychronopoulos
ABB Constructions SA
El.Power & Automation sys Dept.
email : [email protected]
 
D

Darold Woodward

As someone whose life seems to revolve around protocol issues these days, I'd like to comment. First -- why? most of the protocols have their roots in vendor specifc protocols of one sort or
another and have some degree of optimization for the types of information that vendor was concerned about.

The most notable protocol that is both an exception and a contradiction of this is Modbus. It really is specialized for Modicon PLC registers. However, its specialization is generic enough that most people can adapt their systems to it and get something useful out of it. Modbus has become a defacto standard because
it is a fairly easy and cheap "lowest common denominator" of protocols.

The only notable industry I've seen that has adopted "one" protocol is the European substation automation industry. They all use IEC 60870-5-101 or 103 and soon 104. While this sounds great, in practice there are lots of vendor specific extensions in 103 and lots of vagueness in 101. Therefore interoperability between devices from ABB, Siemens, and others really only exists on a limited basis.

An interoperability demonstration and report concerning the IEC protocol was conducted, but it required only interoperability at a low level of functionality and required some fairly extensive coordination between vendors before success was achieved.

In North America, UCA 2.0 is expected by some to become that one protocol for future substation integration. While it will deliver a lot of cool stuf, it is based on standards that are either not used or no longer in wide or growing use in the industrial integration arena. I'm still not sure if that helps or hurts us in the long run, but we're going to find out.

With UCA the protocol was developed and conformance and interoperability tests are still under development. This means that the main goal of interoperability for now will be up to the developers to follow the specs with no certification procedure. Interoperability
will probably be realized, but it sure would have been nice to have the testing and certification in place before products entered the market.

While the idea sounds good, I haven't found an example where an entire industry has ever reached consensus quickly enough to have a single standard. This lack of standards is what doomed the original laser discs. Sony spent lots of money selling beta VCRs to the public. Only recently have PC and peripheral manufacturers
gotten together and developed tight enough specs to start to eliminate some of the integration issues with Personal Computers.

We're going to be set back again by the push for Ethernet. It is a great physical layer, but the application layers are just as numerous as the other networks you sited. I'm not convinced we'll have it solved in the near future in the industrial control world.

Darold Woodward PE
SEL Inc.
[email protected]
 
P

Peter Placek

Dear Tassos,

It is very hard to answer your question. I am afraid there is no clear answer. We can ask similar question: "Why people all around the world do not speak the same language? It would be
so much easier!" We are probably just of the nature.

But instead of trying to answer your question, more important might be to find a solution. There is several activities and groups around, but I believe more successful one is OPC Foundation. The OPC communication has become
quite common in industry automation lately, providing connection among all protocols you mentioned.

Sincerely,

Peter Placek.


____ Merz Company ... _________________________________
Peter Placek, Sales and Marketing Manager
tel: +420 48 510 0272, fax: +420 48 510 0273
http://www.merz-sw.com
_____ ... for Clean Sound of Software
 
C

Curt Wuollet

Hi Tassos

There is no good reason (except political and commercial) to have so many. A few variations perhaps, but, not dozens. Ethernet will wipe out a lot of low level protocols because that is driven by computer professionals that can see how ridiculous the situation is. But, the proprietary vendors will then destroy Ethernet by
plopping dozens of incompatible, non-interoperable protocols on top of it instead of encapsulating their protos in the existing
Internet protos. Eventually there will be a return to reason, driven, again from the outside. But, greed and avarice are much more prevelant than altruism and concern for the customer, so
expect another couple of generations before people realize the enormous advantage of sharing open protocols.

Curt Wuollet, Owner
Wide Open Technologies
 
U

Unique Systems

1. Politics and Money
2. Some protocols are used for different levels of communications. For example DeviceNet is used primarily for device level communications, PLC to
discrete I/O (limit switch, motor starter, etc.). Profibus can carry larger amounts of data and might be used to communicate with a whole remote I/O rack. Ethernet is primarily used for information that is not time critical,
information going from a PLC to an accounting program in the front office.
These are VERY general descriptions, it is hard to categorize a specific protocol for one specific use because they can be used many different ways depending on the application.

Check out this link for a comparison of many of the industrial networks.
http://www.synergetic.com/compare.htm

Steve
 
H

Hullsiek, William

> What is the
> reason (except the commercial) of having so many "different"
> communication protocols instead of having one common protocol
> for all systems which will give the possibility (if the companies
> wanted to do so) to connect different systems (PLC, SCADA,
> SENSORS etc) from various companies?


We attemped to do this in the 1980's, with Manufacturing Message Service (MMS).

MMS has been commented on quite a bit, so search the archives on the list.

What we learned, is that we need a COMMON OBJECT MODEL, that is vendor extensible.
In the 1980's, most vendors had brain-dead processors, with limited memory space and a static architecture. The overhead of mapping vendor specific stuff to a common object model, then putting that into a common protocol was too much.


There was also the issue of "software development" costs. The internet protocol suite is so prevalent today, because the federal government paid for most of the research and development costs. Inexpensive code and specifications results in lower cost products. Hence the popularity of Modbus.

In a nut-shell, the 'up-front capital costs', and 'knowledge cost' of the proprietary interfaces is cheaper. The last analysis I did (4 years ago), indicated there was a payback period of 5-7 years for open protocols. Which is why MMS makes sense for Utilities.

OPC is a pretty good hack that is available today. However, it is typically not a native protocol to PLC's, DCS and SCADA.


William F. Hullsiek
Software Engineer
 
R

Ralph Mackiewicz

There are a number of reasons (all my opinion only) for this but the commercial reasons cannot be overlooked:

1. Having "one common protocol for all systems" assumes that there is only one set of problems to be solved. Unfortunately, the world is more complex than that. There are many different, and sometimes incompatible, requirements for industrial networking applications. No single solution can possibly fulfill all the requirements without significant tradeoffs in performance, functionality, price, etc. We can probably get by with a much smaller number of protocols than we have, but a single solution is not possible.

2. Dominant control vendors prefer solutions that they control (at least initially) for numerous commercial and technical reasons.

3. Most users don't seem to care about unification of communications protocols in the industrial control market. If they did, the
situation we have would not exist. There is no conspiracy to deprive us of interoperability. If customers insisted on interoperability between brands of PLCs and other controls the suppliers would respond or innovative companies would be formed to meet this need. Instead, the need is so small that this niche is serviced by (relatively)
small third party suppliers who provide this capability to the minority of customers that care about interoperability.


Regards,
Ralph Mackiewicz
SISCO, Inc.

The opinions given above should be attributed to me and not
my company because my company did not write them...I did.
 
A

Andrew Piereder

Aside from commercial?

There are technical features that make one "standard" better than another for a certain application, but in my experience this is seldom a criterion in deciding for one standard over another. Most applications only use a fraction of features and/or power a particular protocol can provide and could legitimately use any one of several alternatives. In many, possibly most cases, the decision for a particular vendor's product entails a choice of a particular protocol.

Andy Piereder
Pinnacle IDC
 
R

Rob Hulsebos

>> ...What is the reason (except the commercial) of having so many
>> "different" communication protocols instead of having one common
>> protocol for all systems ...?

>We're going to be set back again by the push for Ethernet. It is a
>great physical layer, but the application layers are just as numerous
>as the other networks you sited. I'm not convinced we'll have it
>solved in the near future in the industrial control world.

Hear hear. I'm trying to keep track of all the 'open' protocols that exist on this planet. I lost track somewhere above 100.

I now think we can double this number without much effort. There is Profibus on Ethernet, FF on Ethernet, Modbus on Ethernet, ControlNet/DeviceNet on Ethernet, there's IP and IP to cause eternal confusion, etc. etc.

I'm now leaving for home, and halfway have to fill up. It's strange: only 3 types of fuel in the gas station (diesel, unleaded, LPG). No separate fuel for my Honda. As consumers, we would never accept the situation of 50 types of fuel for each brand of car.


Greetings,
Rob Hulsebos
 
Relative to what William Hullsiek said:

OPC is much more than a "hack". It may not be built into PLC's but it is the closest thing to a common object model for interfacing with controls. OPC is based on distributed network objects (DCOM). MMS is a protocol and not an object model. The major SCADA systems have adopted OPC. You can buy OPC servers from any number of vendors. MMS would be dead if it wasn't for the utilities adopting it.

To Tassos Polychronopoulos:

OPC is your best bet for finding a common interface to control systems. There is not logical reason for all the various protocols.
Your best bet is to utilize OPC to give your software independence from the underlying control networks.
 
H
Hey Rob, just to stirr the pot a little, as consumers we *are* accepting the plethora of protocols. There's nobody with the power to stuff them down our throats. It's just that we like the things we want, and if a little strange protocol comes with it most of us do not take the stand to fight it off, insisting on what we really want. I see it like blaming the hockey players for the price of the game tickets.

Hugo
 
S

Sage, Pete (IndSys, GEFanuc, Albany)

Right,

But there's 50 types of oil and air filters for the cars, not to mention dozens of different engines, transmissions, tire types, brake pads, etc. I can't slap a Honda engine into my Toyota. Nor can I take the snow tires of my wife's car and put them on mine. Each car vendor has there own interface for talking to the car computer...

I'm not defending the hundreds of different protocols out there - since we have to write special drivers or qualify OPC Servers for all of them. Vendors like to have control of protocols so they can rapidly make changes without going through a committee. That said I do see a big push towards standardization.

Pete
 
C
Rob Hulsebos Philips CFT wrote:

> >> ...What is the reason (except the commercial) of having so many
> >> "different" communication protocols instead of having one common
> >> protocol for all systems ...?
>
> >We're going to be set back again by the push for Ethernet. It is a
> >great physical layer, but the application layers are just as numerous
> >as the other networks you sited. I'm not convinced we'll have it
> >solved in the near future in the industrial control world.

I think it's kind of shallow to blame the "open" people for that. Most of the proliferation was for the same reasons as in the automation world.
Now, we have most of the world standardized on the "Internet" suite of protocols and it is impossible to characterize that as a bad thing. If the Internet were run by automation vendors, no two people could mail each other and a mailing list would only reach people who had xyz computers
with xyz modems and xyz wiring. Of all those many protocols that you mention, a few are in lagacy applications and the rest are forgotten. You stand almost no chance to break standards now and be commercially succesful. even Novell and Microsoft had to bitterly concede and accept commodity standards that they don't control. The automation market just doesn't "get it" yet.

> Hear hear. I'm trying to keep track of all the 'open' protocols
> that exist on this planet. I lost track somewhere above 100.

You have a very, very, loose definition of "open". I count about a dozen and each of them serves a unique purpose as opposed to dozens that
serve identical purposes in the automation market.

> I now think we can double this number without much effort.
> There is Profibus on Ethernet, FF on Ethernet, Modbus on Ethernet,
> ControlNet/DeviceNet on Ethernet, there's IP and IP to cause
> eternal confusion, etc. etc.

That _is_ the regrettable part. Users, by popular demand, want the standardization that makes the Internet work for everyone. The automation vendors respond by spending huge amouts of time and effort to build proprietary implimentations on top of a "universal" wire protocol thereby rendering it useless as an interoperability
tool. The consumers get screwed again. and no progress has been made. Ethernet by itself, means nothing, without a single, standard protocol on top. I can see why people are not enthusiastic, proprietary Ethernet is just as bad as all the other media. They remove the magic ingredient and wonder why it's not magic anymore. If they would
simply agree to add just one, and only one, common protocol to the Internet suite of protocols, preferably encapsulated in TCP/IP, or even UDP, huge amounts of time and effort would be saved, costs would plummet and adoption would be exponential. But they would rather have a tiny piece of the market that they can control. Smart., real smart. That's why we're doing the Linux PLC, it's not very hard to do better than people who think like that.

> I'm now leaving for home, and halfway have to fill up. It's strange:
> only 3 types of fuel in the gas station (diesel, unleaded, LPG).
> No separate fuel for my Honda. As consumers, we would never accept
> the situation of 50 types of fuel for each brand of car.

Why then do we accept it in the automation business? Support your local Linux PLC hacker and use Open Source products wherever you can.
We built the Frankenstein monster, the only way to subdue it is to starve it until it's willing to change.

Regards,

Curt Wuollet, Owner
Wide Open Technologies No disclaimers, Go ahead and call my boss.
 
W

Warren Postma

> .... But, greed and averice are much
> more prevelant than altruism and concern for the customer, so
> expect another couple of generations before people realize the
> enormous advantage of sharing open protocols.

Open standards can promote lots of greed and avarice too. Look at Linux. Think there's no Greed and Avarice there? Sometimes we call that the "Economy", but it's really just greed and avarice, right? Not that it's all good, or all bad, just that is what fundamentally drives it. It could be better, but it could also be much worse.

Now, closed standards are basically (i) naturally going to happen because of the way systems are developed, (ii) remain closed because if the reasons you stated.

The best weapon is to convince the engineers developing systems to look at open standards first when they develop a new product. A new proprietary protocol is at best a non-issue, and at worst, a potential reason for customers not to invest in a new piece of control hardware or SCADA system, or whatever it is you're building.

Here are my predictions (never a good idea, but oh well):

1. TCP/IP for everything. This doesn't prevent you from making proprietary protocols over top of TCP/IP, however the base standard TCP/IP plus
proprietary protocols is eventually going to be noticed as putting "new wine in old wineskins". The two are not compatible in the long run, and all proprietary protocols will be reserved for small niches at the worst.

2. Modbus over TCPIP (and thus Ethernet, or whatever else) is going to be huge for whenever you need to send digital bits, or 16 or 32 bit registers between equipment and systems.

3. SOAP is going to be huge. This is the successor to XML-RPC, and it involves using the XML data formats to encapsulate a sun-RPC like layer between both compiled and script languages.

4. The existing device-net/profibus stuff will never become as ubiquitous as we hoped, but will remain strong as a niche.

5. At a low level, where Ethernet and TCP/IP is too much, then USB or potentially IEEE-1394 (aka Firewire), will be huge in the control-systems
market because the costs will be spread among both consumer electronics and computing products and industrial products.

6. Good old RS-232 links with Modbus RTU protocol will never never die! :)

Warren Postma
ZTR Control Systems
London Ontario Canada
 
D

David Leese Dresser Valve Div., Hallibur

>But there's 50 types of oil and air filters for the cars,
>not to mention dozens of different engines, transmissions,
>tire types, brake pads, etc.

As I experienced last month, there are at least 2 variations of the tire stud for 1995 Chevrolet model 1500 pickup trucks. The studs are not interchangeable. If you strip one, you have
a 50/50 chance of purchasing the correct replacement at an auto supply.

If one manufacturer can't standardize a screw on the same model vehicle, what chance is there for COMM standards among thousands of manufacturers.

D. Leese
 
R

Ralph Mackiewicz

> >> ...What is the reason (except the commercial) of having so many
> >> "different" communication protocols instead of having one common
> >> protocol for all systems ...?

...snip...snip...

> I now think we can double this number without much effort.
> There is Profibus on Ethernet, FF on Ethernet, Modbus on Ethernet,
> ControlNet/DeviceNet on Ethernet, there's IP and IP to cause eternal
> confusion, etc. etc.
>
> I'm now leaving for home, and halfway have to fill up. It's strange:
> only 3 types of fuel in the gas station (diesel, unleaded, LPG). No
> separate fuel for my Honda. As consumers, we would never accept the
> situation of 50 types of fuel for each brand of car.

With gas, you make the purchase decisions and the companies respond appropriately.

I am curious, how many of the automation engineers on this list actually determine the brands of controls that are used in end user
systems?

I suspect that the people making purchase decisions are not the same people who object to the proliferation of "open" solutions.

The people who make the purchase decisions obviously don't think that having a plethora of "open" communications protocols is relevant to
their decision making process for controls.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
C

Colin T. Marsh

Hugo, you are right about consumers "accepting" the plethora of protocols. However you say "nobody has the power to stuff them down our throats". You might be right if your name is GM. They were powerful enough to resist A-B's new "offering", so ControlNet became "open".
Unfortunately most clients don't have GM's clout and have no choice but to use/accept the proprietary networks they are offered by the manufacturer. Now the client is the manufacturer's prisoner and can be restricted, by
connectivity issues, to the products supplied or approved by the manufacturer. Then watch the manufacturer protect his monopoly when a non-approved company (like ours) provides truly competitive alternatives that enables the
client's choice of OEM equipment to connect to these same networks.

Colin
 
R

Ralph Mackiewicz

> OPC is much more than a "hack". It may not be built into PLC's
> but it is the closest thing to a common object model for interfacing
> with controls. OPC is based on distributed network objects (DCOM). MMS
> is a protocol and not an object model. The major SCADA systems have
> adopted OPC. You can buy OPC servers from any number of vendors. MMS
> would be dead if it wasn't for the utilities adopting it.

1. MMS does have an object model. It is called the "Virtual Manufacturing Device Model" or VMD Model. The approach of using a virtual object model is a necessary step in building an application protocol that can support interoperability. The utility work has simply expanded the model to include application specific models like meters, relays, RTUs, etc.

2. Some clarification is needed: OPC is an API based upon COM. OPC contains a data model that is not application specific. DCOM is a protocol for distributing COM function calls, like OPC, across a network. MMS is not an API. MMS is a protocol with a non-application specific data model. MMS does not distribute functions calls like DCOM. MMS is an application level protocol for supporting real-time data access and supervisory control. While both OPC and MMS contain data models, the OPC data model is a subset of the MMS data model and they are both completely compatible with each other. OPC Servers are
available for MMS just as they are available for Profibus, Modbus, etc. etc. etc. etc. OPC is not a replacement for MMS, Modbus, Profibus, DH, etc. etc. etc. etc. nor vice-a-versa.

3. MMS would not be dead regardless of any utility activity. It is used for applications outside of utilities that require a non-vendor
specific application protocol that runs over standard internetworking gear and that supports a richer set of features than just reading/writing PLC registers with primitive addresses like "4001". There are applications where client discovery of device objects and object descriptions; and the handling of very large complex typed data sets are required outside of a Microsoft O/S.

Regards,
Ralph Mackiewicz
SISCO, Inc.
 
P

Phil Covington

The problem that I see with a "common" protocol is trying to get everyone to agree on what that "common" protocol should be. Getting a group of people with different expectations and requirements to agree on a subject can be very difficult. All one has to do is look back at the message archive of the LinuxPLC for January and February to see how difficult it is to get
everyone to agree on how to proceed. Even now there seems to be a few people working in different directions on the LinuxPLC.

Regards,

Phil Covington
 
J
I don't have a great experience in communications protocols, but my reflex is to use every time I can to use open protocols.

I agree with Warren, the Modbus protocol will have a long life. The modbus Rtu protocol is an open protocol, and number of devices can communicate via a RS485 network. You can find PLC
with the communication protocol completely integrated. (TELEMECANIQUE tsx nano) I use these PLC as external IO for my PC. Is is cheaper than dedicated IO boards.

I also work with CAN-open wich is also an non propietary protocol. You can find number of devices integrating this protocol. external IO, encoders, frequency variator, PLC ...

In a installation, if you choose an open protocol (well known), you have more chance to make your installation evoluting and safe for
many years.

Regards
J-F Portala
SoViLor company
[email protected]
 
Top