Tag Name based communication

K

Thread Starter

Kiran

Dear,

I would like to know the advantages of Tag name based communication (TCP/IP-CIP Protocol) over address based communication (Modbus or Ethernet)?

We are working on communication establishment between Yokogawa DCS and AllenBradley Control Logix PLC.

Please share your valuable knowledge and experience.

Thank you very much.

regards,
Kiran
 
You asked about the significance of tag names in communications.

Using tag names has been standard practice in process control since control loops were defined almost a century ago. A tag name is an alias conveniently formed to make it easier for our frail human memory to associate with an abstract item. ISA has defined in the S5 series of standards, ways to form tag names associated with the primary control or measurement technology (Pressure, Temperature, Flow, Level, etc.) and a location item associated with a portion of a plant or manufacturing process.

The Internet uses an abstract number to define a host location which is actually a 32-bit number, but expressed in a format that breaks down into four decimal strings for convenience (Ex. 27.233.15.12) But even that is not easy enough for us to remember, so the Internet assigns domain names to Internet hosts such as "Control.com" for the list server for this list. Domain names are just tag names.

For many years, PLC programming used the termination location on the I/O rack to name a field sensing or actuating device. It was left as an exercise to the logic programmer to correctly remember the nature of a point (input or output) and its relationship to other I/O. Documentation was also left to the user. This is just like the way computer memory locations were assigned by programmers when they coded in machine code even before Assembly Language.

Modern PLC programming now assigns tag names to I/O points, and allows naming of Function Blocks, their attributes, and constants as well. Not only do tag names make it easier for us to read for later understanding, but they allow portability of source code from one installation to the next where the wiring may not be exactly the same.

Dick Caro
===============================================================
Richard H. Caro, CEO, CMC Associates
Certified Automation Professional (ISA)
E-Mail: [email protected]
Buy my books at the ISA Bookstore:
Wireless Networks for Industrial Automation
Automation Network Selection
Consumers Guide to Fieldbus Network Equipment for Process Control
===============================================================
 
J
You are using OPC for this task?

OPC recognizes tag names and speeds the process of building a tagbase.
 
J

James Ingraham

I almost hate to post a reply because Dick Caro's covers it so well. But I'll try to tackle it from a different angle and hopefully add something useful to the discussion.

Imagine 5 years from now you pull up this project. Which would you rather see: "N7:20" or "Tank_17_Pressure"?

Let's make it worse. Here's a partial map of some data in a hypothetical Siemens PLC:
MW4: pressure in tank 17
MW6: temperature in tank 17
MW8: pressure in tank 18
MW10: temperature in tank 18
Now I want to add a new variable, the level in the tanks. I can't just put the level for 17 in with the other variables for 17; there's no room left. So I either have to re-map everything, or else level is now stuck out somewhere else, not nicely grouped with the rest of the data for that tank.

Tags are just a vastly superior way to do things. But it gets even better when you throw communication into the mix, as you've asked about.

I'll switch to Modbus registers here. If you do a read over Modbus/TCP of register 17, with a length of 4, you will get data back, REGARDLESS OF WHETHER THAT DATA IS MEANINGFUL! Maybe you were supposed to only read 1 registers (remember, length is in bytes, and registers are two bytes each!). Maybe you were supposed to start at 16 instead of 17. Whatever the case, you now have garbled data. It's even worse the other way; write to register 0 with a length of 125 words, and you just killed everything in the PLC. If you have tag names however, you can only read from tags that are actually defined. If you try to read from "blargh" and "blargh" is undefined, you'll get a read error and immediately know there is a problem, rather than thinking everything is fine and continuing with bad data. And the write side is even better, because in addition the PLC knows how big the tag you're writing to is and won't let you overwrite the bounds of it.

I suppose I should say something good about the old system or registers. For simple things, it's simple. Modbus/TCP is about a billion times easier to implement the EtherNet/IP. But it's rare that things like that matter.

Hope that helps.

-James Ingraham
Sage Automation, Inc.
 
The practical differences are really more related to proprietary protocols versus open protocols. AB has their Ethernet-IP protocol which they use in most of their PLCs. The other protocol you mentioned was Modbus/TCP, which is an open protocol used by multiple vendors.

If the problem you are trying to solve is "how do I connect my Yokogawa DCS to my Allen Bradley Control Logix PLC", then what you really want to evaluate is:

a) What hardware and software combinations to you need to put this into effect?

b) Is there any chance that you might want to connect anything else in future that isn't from AB?

For "a" you have to evaluate this in terms of cost and simplicity. You want something simple so it is easy to get working and maintain.

For "b" you have to consider that if you buy anything else that *isn't* from AB (or one of their partners), it's pretty unlikely to use AB's Ethernet-IP (CIP). That means you will need yet *another* protocol for that vendor's hardware (vendor lock-in is the whole reason for why proprietary protocols exist). A lot of other vendors have their own proprietary protocols as well, so this is not just a problem with AB.

The "tag" versus "address" issue is a bit of a red herring however. A lot of the PLCs that use Modbus (or Modbus/TCP) don't use a Modbus register layout and require you to configure how the protocol maps to their own address system. That means the "addresses" are effectively "tags", although they're numerical digits rather than text.

When you are doing communications you're rarely reading from or writing directly to a PLC's I/O area. Rather, you are generally working with some internal memory that has been processed through the PLC's logic. In that case, you are working with whatever addresses and address names the guy who wrote your PLC program decided to use on the spur of the moment. My experience has been that unless you are the guy who actually wrote the program it's pretty much a lost cause figuring out what something means just from a short tag name, especially when there several dozen very similar names that do slightly different things. If you've got any documentation on what the interface address (or "tag") areas are, then it doesn't really matter what they are called. The biggest advantage that a tag based system has is that it's easier for a programmer to make changes and revisions, primarily because a "tag" doesn't necessarily imply an order or size while a numerical "address" usually does. That isn't a consideration that matters much to the people operating or maintaining the system however.

In the end, look at what you will need to implement the solution, think about whether that will cause future problems that you can *reasonably* forsee, and base your decisions on the practicalities.
 
I am confused about what the proper name of AB's "Ethernet/IP" protocol is. That name is a tautology. Then there's CIP (Common Industrial Protocol). That's hubris. And there's ODVA, the acronym for the group that maintains the specifications for the protocol in question. I have no idea what ODVA stands for.

Hey, but for only $350USD you can know more.

I understand that AB is a business and needs to make money to pay its employees and send dividends to its shareholders. But they could make money from selling best-in-class APIs for their protocol. I don't understand the motive behind AB's or ODVA's specification gatekeeping.
 
C

curt wuollet

Yes, you do. $$$$
Opening their protocol would let you buy "best of class" for each particular function. Keeping control means you will be an all XXX shop. Everything from connectors to protocols is slanted towards this goal. And when they stress "open" (small o, their definition) they accomplish the same thing by documenting one set of functions and simply using another, undocumented set. For example, try to find the functions they use for their programming tools. In many cases, whatever they describe as "open" is more difficult to reverse engineer than their "closed" versions. With few exceptions, the word open is meaningless at best in automation. It's often used paradoxically. Even worse, they actually fool some folks.

Regards
cww
 
EtherNet/IP is intended to be an Open Network. ODVA manages the standard. I've been involved for 15 or more years as a product developer for these networks. What it really comes down to is an attempt to chase Siemens Profi-Net. And although its OPEN, Rockwell contributes a great deal of human capitol to the endeavor. I believe that EtherNet/IP has improved 1000 fold from its introduction and the ODVA is doing a good job providing tools and direction to vendors so that products conform to a set of interoperability benchmarks. Just my opinion of course, I'm a member of ODVA as a device vendor and we try to play on all Industrial Networks.
 
J

James Ingraham

Yeah, I'm not real happy with Allen-Bradley / Rockwell Automation's naming of EtherNet/IP. First of all, note the capital "N." Ethernet has a lower case "n," EtherNet/IP has an upper case "N." They capitalized the "N" to fit with the DeviceNet / ControlNet naming scheme. The "IP" stands for "Industrial Protocol," despite the fact that for 99% of people when you say "Ethernet IP" they think you mean "TCP/IP," or potentially "UDP/IP." (And the other 1% think "intellectual property.") EtherNet/CIP would have been a much better name, but they didn't ask me.

CIP originally stood for "ControlNet Information Protocol." [NOTE: I recently tried to verify that statement and couldn't, so take it with a grain of salt.] Then they back-ported the protocol onto DeviceNet, which meant the name didn't make sense, so they changed the name to "Common Industrial Protocol." Later, they came out with EtherNet/IP, which sticks CIP information inside a TCP and / or UDP packet.

ODVA originally stood for Open DeviceNet Association. The ODVA is an independent organization, though obviously Rockwell wields tremendous influence in the ODVA. There are some big names on the ODVA member list, including numerous direct competitors to Rockwell. After ControlNet and EtherNet/IP were introduced, they changed the name to simply ODVA, since they now had control over more than just DeviceNet. ODVA now is officially not an acronym. It's just a weird name. Side note: DVD doesn't mean anything either. Originally, it was supposed to mean "Digital Video Disc," but some of the companies involved thought that was too narrow a focus and wanted to change it to "Digital Versatile Disc." They couldn't come to an agreement, so they just left the name as "DVD," without actually meaning anything.

$350 for a copy of the spec is pretty nominal, although that's the MEMBER price. It's a $1000 for the rest of us peons. Even $1000 is a drop in the bucket if you're actually developing a product for the real world. Trust me, you'll spend a LOT more than that to implement the damn thing. EtherNet/IP is not something you can do in an afternoon like Modbus/TCP is.

All in all, I've been pretty happy with EtherNet/IP in the real world, although I'm sure I'd have been just fine with Modbus/TCP, Profinet, EtherCAT, Powerlink, etc., etc., etc.

-James Ingraham
Sage Automation, Inc.
 
AB "Ethernet/IP" stands for "Ethernet Industrial Protocol". Like CIP ("Common Industrial Protocol"), it's a very generic name. If you were not very familiar with the protocol field, you might get the impression that they were *the* Ethernet industrial protocol or *the* common industrial protocol (note the lack of capitalization here). They're not the only company to do things like this. Microsoft also uses a lot of very generic names, such as "the Common Language Runtime (CLR)" as their name for the core of DotNet. I wouldn't be surprised if it was a well known tactic in the marketing and advertising business. In either case it's pretty obvious that they want you to think that what *they* do is inherently *the* standard.

As for ODVA, it stands for Open Devicenet Vendor's Association. ODVA is responsible for licensing AB's currently supported protocols to third parties. It handles AB Ethernet-IP as well as Devicenet. And yes, they will sell you a license to use those protocols, provided they want you as a "partner" and you sign their contract and agree to do what they say. I've looked at the standard contract however, and it isn't something that I would be willing to sign myself. It's possible that companies that AB particularly wants as partners may be able to negotiate better terms for themselves though.

As for why they do things this way, it's simple; it gives them more control over their customers. Lots of other companies do this as well, particularly in the computer industry. Even a formal "standards" stamp of approval from ISO or IEC can be pretty useless these days, as the proposals are typically closely hedged in by patents before a company brings them to the standards body. As a customer you have to practice a lot of caveat emptor.
 
The $1000 (or whatever it is) fee for the specs just gets you an *evaluation copy* of the specs to look them over to see if you want to pursue things further. You then have to negotiate a contract, get your contract approved, and purchase a license if you want to actually implement the specs.

This next bit is long, but I think it's an important cautionary tale. If you want a good example of how these sorts of things can go bad, have a look at what is happening today with the Java programming language. The Java language standard is controlled by something called the JCP (Java Community Process). The language however is actually owned by Oracle (who recently bought Sun). In other words, it's a lot like Ethernet/IP and ODVA.

The JCP is supposed to be provide an "open" process for the other stake holders, which include most of the largest companies in the IT business (e.g. IBM, etc.). What really made Java such a huge success however is an organization called "The Apache Software Foundation". As well as being responsible for the Internet's dominant web server, they are an umbrella organization for the numerous open source Java projects which businesses build their Java application on top of.
http://www.apache.org/

Apache has produced a set of class libraries called "Harmony" which duplicates a lot of the core functionality of Java. Harmony was backed by IBM, and Google built their Android phone OS on top of it. Under the JCP rules, Oracle should have given Apache a license to use the Java conformance tests (under the JCP rules they have to pass the conformance tests to get a license to the Java patents). Before Oracle bought Sun, they supported Apache's position. After they bought Sun (and hence Java), they now oppose Apache.

Oracle then said they were going ahead with their own proposed changes to Java whether anyone else liked it or not. They cut special deals with IBM and Apple to get their support. They launched a lawsuit against Google for supposed patent infringement (since Google's version of Java based on Harmony hadn't passed the conformance tests - as Oracle wouldn't allow it to be tested). Oracle brought in business partners who could be depended on to vote the way they were told. Apache has quite the JCP in protest. This last bit by the way is a *very* big deal, because Apache has probably done more to advance Java in recent years than anyone else. At present, no one knows where this is going to go. A lot of small companies are afraid they're going to end up getting crushed.

This is the sort of "open" which people keep trying to tell us is "good enough". "It's open, you can buy a spec document!". "It's open, we'll sell you a license (if you do what we say)!". You say you want to do something the property owner doesn't approve of? Oh, well it's not *that* sort of open.

I'm reminded of an old Russian joke (from the last century). An American told a Russian "in America we have freedom of speech. I can stand in front of the Whitehouse and shout 'down with America!' and no one will stop me." The Russian replied "we have freedom of speech too. I can stand in the middle of Red Square and shout 'down with America' and no one will stop me either!"
 
C
Yes, open if you have enough money and we like you is not Open. And open with patented bits isn't either. They would like it both ways, to be seen as open and to retain control. If they really don't get it, that's one thing, but if they do, it's fraud. And I think they do. Pick your partners carefully. That's what amazes me about all the MS partners in automation, it's like partnering with Berny Madoff where intellectual property is concerned, no one has made off with more. This model is collapsing though, with the widespread acceptance of Android, which marks the first widespread acceptance of many competitors using the same Open* product. It is now fairly well demonstrated that this can be done and it's business as usual. No fortunes were lost abandoning the hyper proprietary model and the savings were especially crucial when launching a legion of new products in a poor economy. And customers are finding that what it does is more important than what it runs on. I expect this to continue as it's found there is no downside to being open on platforms. MS has seen this and is porting to ARM, but it has been suggested this is either to freeze the market while they maneuver or just a plot to help Intel by slowing millions of ARM processors to a crawl:^)

* Android is not quite open enough for my tastes, but Google knows where the line is. And using not quite open Java is already biting them. But with widespread acceptance and uptake, I expect this will be fixed because there's a lot of money involved.

Regards
cww
 
L

Lynn August Linse

Actually, the cost for ODVA Ethernet/IP is $300 annual subscription, which pays for ODVA administrative costs (aka: the folks who bill you $300 next year :-]) and gives you the right to use an ODVA assigned Vendor Id, which is required during the CIP connection phase, plus it gives you the right to use the CIP & EthernetIP Trademarks. Not defending the cost, but I am sure the modbus-ida.org folks are green with envy since they have no way to recoup their office costs. Sad how employees today actually like to get paid, to eat and all.

I think this discussion ran way off into left-field or the green-roughs or swampy-muck or something.

"Tags" under EthernetIP are a legacy detail which Rockwell snuck into CIP.

True CIP is object-oriented - you have objects (like a Drive object) and can issue it services, which cause actions or return data. The services & data are all strictly defined in advance.

However, the RSLogix 5000 systems allow creating data objects and assigning them tag names. So CIP includes a nifty little hack which allows your client to ask for a tag, and receive the data its tied to. Objects? Not really - just named data since you won't have anyway to predict the form of that data.

The other alternative is to mimic the old SLC5/PLC5 controllers and have the ControLogix create virtual N-files, which get mapped to tagged data. Then you issue reads for N7:0 data & get chunks of 16-bit arrays returned, stuffed with all kinds of interesting 32-bit aligned memory objects.

What's best? At this point you are just using device X to query device Y and don't really care about open or multiple vendor support. Use what you want - TAGS are probably easiest.

No one will be ripping out that AB ControlLogix and swapping in a 'CLgx-clone' any day soon, but AB using CIP/EthernetIP is NOT the reason this is true. The protocol is the easiest part of the PLC to replace/duplicate. (I've written 3 CIP/EthernetIP stacks - 1 in C, 1 in C++, and the latest in Python).

- Lynn August Linse, Digi Int'l
 
C
Hi Lynn

Can you then simply make a product, or does it have to be certified/verified, etc.?

Regards
cww
 
L

Lynn August Linse

> Can you then simply make a product, or
> does it have to be certified/verified,
> etc.?

Yes, you can just make a product. It doesn't need to be tested/certified, but some large customers will require it to be tested and/or prefer to buy products which are tested.

However, to use the EthernetIP 'trademark' (aka: to advertise your product), you need to hold a valid ($300/yr) subscription to one of the CIP technologies. Course you could just advertise "it talks to Ab ControlLogix" and let people imagine what they will.

Plus the protocol-cops require you to own a valid "ODVA Vendor Id" to exchange during the CIP Open Connection phase - although I have seen several small companies just hi-jack the Allen-Bradley vendor id #1 :)

No one claims it's a "free protocol", and the definition of "Open" varies in that some require Open to equal Free, while others say that as long as the fee is reasonable and no one can deny a specific class of user from paying that fee & using the protocol, then it's Open. For example, to understand DH+ you need RA/AB to agree to take your bag of money ... and they have not been agreeing for anyone for almost a decade. So DH+ is clearly not Open. Also, things like LONworks include a list of products which licenses cannot make, so it's not really Open either. ODVA suffers neither of these defects.

Schneider Electric has also boughten into the ODVA EthernetIP pie - sidelining their IDA (as in modbus-ida) effort. ODVA has created a CIP to Modbus mapping feature, so a pure EthernetIP host (like CLgx) can issue a CIP request which causes a 'bridge device' to spawn predictable Modbus/TCP requests. Pitty the ENB hasn't added a Modbus/TCP client function which uses this.
 
In reply to Curt Wuollet: The reference you are looking for can be found here:

http://www.odva.org/Home/CIPNETWORK...bid/137/lng/en-US/language/en-US/Default.aspx

Download the PDF file: Terms of Usage Agreement (Pub 206)


The essential language is:

1.1. Licensed Vendor agrees to (...)

1.1.4. Obtain and maintain Declarations of Conformity from ODVA for its Compliant Products as prescribed by ODVA in its published policies;

1.1.5. Permit ODVA or its agents, upon demand, but no more than once annually, to test its Compliant Products for their conformance with the Licensed Technology;

1.1.6. Make a conspicuous statement in the printed or electronic documentation that is provided to the users of its Compliant Products ("Customers") that such Products conform with the Licensed Technology (a "Statement of Conformance");

Here's where you order conformance testing:
http://www.odva.org/Home/CIPNETWORK...bid/135/lng/en-US/language/en-US/Default.aspx

According to the information in their order form they charge $5000 plus an (unspecified) hourly rate. The number of hours will add up to however long it takes them to test it. Some companies will get discounts on conformance testing, but there don't seem to be any fixed rules on how the discounts are handed out.

You might also want to review the comment that I made above regarding what is happening with Java today. Conformance testing is the big stick that Oracle uses to keep their Java partners in line. Apache can't get Harmony certified as conforming because Oracle can always find a reason to simply not test it. And without passing the conformance test, Oracle can sue you for making anything that looks like Java - as Google found out with Android (which is based on Harmony) when Android phones starting cutting in on Oracle's Java licensing business with phone makers.
 
C

curt wuollet

Well, it's progress, I suppose. It doesn't have me thinking of dreaming up EthernetIP devices, but if you want to bad enough...........

Control doesn't have to be absolute, just enough of a PITA to prevent it becoming ubiquitous. Of course, that prevents it from becoming ubiquitous or even popular. That means there is still room for an Open offering to render it moot, I guess that's the good side.

Regards
cww
 
C

curt wuollet

Thanks Michael, the summary is enough to discourage me. I'd probably just have to fake enough to get by. I suppose for the big outfits it evens out when they screw each other, but it's not for voluntary use not mandated by choice of equipment. It does indicate they still don't get it. Witness the hundreds of private computer protocols on the trash heap of history.

Regards
cww
 
In reply to Lynn August Linse: Are you saying that ODVA does not require conformance testing, or are you saying that they are simply not currently pursuing anyone who distributes hardware or software without it? Their terms of use documents state that conformance testing is mandatory. I realize that it is possible that they may not have (so far) sued anyone for distributing products (hardware or software) without a license from them, but that doesn't mean they *won't*.

The legal basis for control would be their claim that AB/Rockwell holds a number of unspecified patents covering various aspects of Ethernet/IP and CIP. If they in fact do not hold any significant patents in that regards or if the patents for the areas of interest have expired, then that is a different story.

That is of course as you stated a different issue from trademarks. Lack of a trademark doesn't however prevent a protocol implementation from actually working.
 
Top