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.
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. 188.8.131.52) 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.
Richard H. Caro, CEO, CMC Associates
Certified Automation Professional (ISA)
Buy my books at the ISA Bookstore:
Wireless Networks for Industrial Automation
Automation Network Selection
Consumers Guide to Fieldbus Network Equipment for Process Control
You are using OPC for this task?
OPC recognizes tag names and speeds the process of building a tagbase.
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.
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.
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.
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.
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.
Sage Automation, Inc.
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.
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!"
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.
You mentioned patents...
I'm not aware of any patents that pertain to EtherNet/IP.
Do you know specifically of any patents held by ODVA or Rockwell that cover EtherNet/IP?
No, I don't. But does that mean the company that tried to patent any use of PLCs with browsers, etc etc. doesn't have some obscure patent on the technology? The latest game is to get your stuff rolled into a standard and then whip out the patent card. But, like I mentioned, the control they do retain should be sufficient to prevent widespread adoption. It makes one wonder if they have seriously considered the effect on the market that a truly Open protocol could have if adopted by the major players.
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.
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
Can you then simply make a product, or does it have to be certified/verified, etc.?
> Can you then simply make a product, or
> does it have to be certified/verified,
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.
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.
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.
>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?
I don't particularly worry about such things - have any of you read your cellular "Terms & Service Agreement?" How about your Internet access? Most of what you do daily is against the rules, because it gives the provider the right to close your account if you cause problems.
In the town I live in, I don't have the right to park my car in the same place for more than 72 hours - even on my own property.
Until the early 2000's, one could not use MODBUS without submitting all documents containing the word MODBUS for approval by Schneider Electric, plus you had to submit copies of all sales records of MODBUS products to Schneider Electric annually.
In 1998, how many of you submitted your sales records of all MODBUS products as required?
Why is Modbus so popular given you were required to disclose all of your sales data to the owners of the MODBUS specification?
It is an interesting tidbit of history. Had everyone worried so much about the rules, no one but Schneider Electric would be using MODBUS today :)
In reply to Lynn August Linse: When it comes to industrial communications, you undoubtedly know more than anyone else here, and certainly far more than I do. I think though I realize that the question I asked though was probably not one that you could reasonably give a definite answer to.
There are certain things however that companies can and cannot do with respect to trademarks. Despite Schneider Electric having once *asked* people to give them copies of documents which contain the word "Modbus", unless you were using their trademark in an infringing manner you could simply have told them to take a flying leap. Simply using a trademarked word doesn't infringe upon it. If it did, Control.com couldn't exist as we mention trademarks here all the time. You have to use the trademark in an infringing manner to have a problem, and simply using a word or phrase doesn't necessarily do so.
With Ethernet/IP, you can either just be very careful as to how you use the phrase, or as you said avoid the problem by simply not using it at all and saying that it "works with AB PLC model xyz". I would be more than happy with that solution.
AB / ODVA spends a lot of effort telling people they *must* license Ethernet/IP from them, but they never really say why. They waffle about patents, but I will be honest and say that I haven't seen any direct evidence that they have any patents on anything about Ethernet/IP that would interest me (explicit messaging). In fact it is quite possible that there is nothing in there that is even patent-able. A straightforward client - server protocol over TCP/IP wouldn't be. They may have something with regards to their safety or drives versions of their protocol, but those don't really interest me (or for that matter many other people).
They do make you sign a contract to see their specs, but that puts you under contract law. If you avoid their specs, then you avoid the contract trap. That's a very strong reason for me to *not* sign their contract. A company like yours would be in a very different position however, as you would likely want ODVA certification anyway for marketing reasons.
I just had a look at Wireshark and rather interestingly enough, it has a decoder for Ethernet/IP as well as several other protocols (such as Ethercat, Powerlink, and Profinet). There's still the big step of going from a decoder to a driver, but at least that doesn't involve starting from scratch. This is not something that I can follow up on at this time, but you have certainly provided a lot of food for thought.
I would like to however clarify what I think is the essential difference between a protocol that is "open" and one that is "not open". "Open" means that anyone can implement it without restriction. You don't have to sign any contracts, license any patents, or undergo any certification. You just go ahead and do what you want. Furthermore, *and very importantly*, all those rights are passed on undiminished to anyone who uses it. If you can't do all of those, then it's not open. It's not a matter of price, it's a matter of the freedom to do things.
There are lots of closed protocols that have been decoded. That doesn't make them open. There are lots of closed protocols that have been licensed to third parties. That doesn't make them open either. When I say "open", I means "open like the Internet" where you do whatever you want, not "open like the cable company", where you get what the cable company will allow you have.
In reply to Curt Wuollet: The reference you are looking for can be found here:
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:
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.
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.
@Curt: Also witness the tremendous fortunes made off of proprietary technology.
Here's a partial list of Fortune 100 tech companies:
58 Cisco Systems
63 Oracle (post Sun, approx)
See anybody who made a fortune on non-proprietary products? Now granted, some of these support open standards, and Dell and HP certainly have to use standards like PCI / PCI Express, ATX, USB, etc. But the big money is definitely in proprietary systems. Even Google, at 102, makes its big bucks from its highly secret search technology. Red Hat has learned how to monetize open systems, but they would need to grow by at least a factor of 5 to reach the Fortune 500, much less compete with Microsoft.
A special note about Xerox at 152. They invented Ethernet, the GUI, object-oriented programming, the mouse, desktop publishing, bitmap graphics, the integrated development environment, and the WYSIWYG concept. All of these are now "standards." They made money off of NONE of these things. (They also invented the laser printer, and that has been a source of income, but they have never done particularly well in the basic desktop printer space.)
My company used to program our machines in C, an open standard known by millions of developers. Our customers hated it, and we switched to Allen-Bradley PLCs to make them happy.
Profibus and DeviceNet may slowly be going away, but they have to count as commercial successes. EtherNet/IP and Profinet dominate, despite the ease and openness of Modbus/TCP. Profinet and OPC (both of which again must be considered sucesses) are both based on DCOM, about as closed and proprietary as a protocol can get. CIFS has done just fine. Even though IPX/SPX is dead now, killed by an open standard, it was a success for many years.
And don't forget the dead open systems, either. For every TCP/IP or Linux, there are hundreds of systems that DIDN'T make it.
We're WAY off topic at this point, but I think it has been an interesting tangent. Personally, I really prefer open standards. At a business level, I am much more practical.
Sage Automation, Inc.
Many of those have had their fingers slapped for their zeal. It is an interesting tangent. The underlying issue is bundling. It seems one product can still offer so much perceived value that it can carry sub optimal or even unabashedly exploitative cargo like the old Trojan Horse. Like the I-phone that is so cool, people don't mind being ripped off by ATT. Like Windows that is so familiar and easy that it simply doesn't matter that it's a security nightmare. I think that is what fascinates me. That may be a bit extreme as many of the things we talk about aren't horribly detrimental and often do provide functionality, but they tend to be very expensive and often quite aggravating, long term. This trend only goes so far as in a mature market, consumers begin to want the good with the good rather than accepting totally one sided licenses and marriage as a condition of meeting. Why hasn't this come about in the fairly technical field of automation? People will argue about the most petty pros and cons of one horrifically limiting package over another while completely ignoring that both seek to enslave you and put you over the barrel. It's sort of like rebranding Heroin as a new wonder pain reliever, with fewer side effects than the current crop and arguing the effectiveness pro and con, while neglecting that common problem that they are all addictive as Hell. Fascinating.
In reply to James Ingraham: You said "See anybody who made a fortune on non-proprietary products?". Well, yes, I see quite a few. HP, IBM, Dell, Oracle, and Amazon for starters. Even quite a bit of Apple's OS is open source software that they've re-branded. I'm not aware of any "Cisco network protocol"; they simply produce network hardware that supports open standards (open as in you don't need anyone's permission to use it). Intel's attempt at establishing a new line of CPUs (commonly known as the "Itanic") that wasn't compatible with anyone else's was a complete flop and it's only a matter of time before they pull it off life support. As for CIFS, yes it has been quite successful in it's niche - after they moved it off their own underlying protocol and switched to TCP/IP like everyone else.
So where's Burroughs, ICL, DEC, NCR, etc. on your list? The companies that, along with IBM, used to dominate the business, designing their own hardware, running their own OS, and programmed with their own languages? With the exception of IBM, they're gone, swallowed up by someone else, or living a marginal existence on a handful of legacy customers. What happened is the foundations of their businesses became commodities, and unlike IBM they didn't adapt and move on.
What you're missing is that the business isn't about selling the same old thing but giving it away for free and somehow making money off that ("we'll make it up on volume!"). What happened is that while at one time being able to put chips together, or writing an OS (or a database, or a compiler) were once cutting edge technologies. Well, they're not cutting edge anymore, lots of people can do it. They're commodities, and the thing about the commodity businesses is that prices get squeezed down to the minimum. For software, the minimum tends to be zero. If you want to make money in that type of market you've got to move on to products or services that aren't commodities rather than standing there twirling your moustache and chortling over all the customers who are unable to escape the clutches of your legacy products. Finding a successful business strategy in that sort of environment isn't easy, but then making money in any business seldom is.
I look at the major PLC vendors today, and I see a lot of little NCRs and ICLs. Companies selling expensive vertical solutions that don't work with anything from anyone else unless you buy a special gateway. Apple can get away with selling overpriced fashion accessories, but I can't see that strategy working in the industrial field.
I think that companies who make networked I/O, servo drives, and systems like that will be fine. Companies selling high end DCS and SCADA systems will probably be fine, provided they follow a "Red Hat" strategy and base their business on providing and supporting a complete platform. Companies who rely on having an existing base of customers who can't easily switch are going to find their customer bases fading away and new customers hard to get.
HP didn't make their fortune with truly open systems. Yes, HP (and Compaq before them) sell "standard" PCs. But that's not the big bucks. Medical equipment, test & measurement, calculators, etc. helped put HP where they are. And don't forget HP-UX, PA-RISC, and other proprietary products that helped build the company. Oh, and they were partners with Intel on the Itanic debacle.
IBM is even worse. AIX is still kicking. Most of their stuff is proprietary. They're a big backer of open source, but they're in the Fortune 500 for gigantic systems glued together with their in-house expertise. Sure, sure, they'll run a 1000 Linux virtual machines on their big iron, which helps them sell the big iron. But the big iron is THEIRS.
And Oracle? Oracle?!?! They're the WORST. Yes, they provide some open source software. It's not even CLOSE to a money maker for them. Their money comes from big systems running big proprietary Oracle software systems. So proprietary that Larry Ellison once said, "If your business model doesn't fit our software, change your business model."
Amazon is no better. Look at the Kindle. Proprietary format. BARELY supports PDF. Doesn't support EPUB. All of their really cool technology is locked up behind closed doors. Yes, they use some open technologies that help them run their business. But they never made a dime off of open tech; they sell STUFF. And if you ask them to let you see their internal software for search, logistics, warehouse management, order handling, etc., they will tell you an emphatic NO.
As for Dell, I grant that they do mostly "standard" stuff, even though Windows and x86 aren't "standards" so much as "common." Still, they often sell non-standard form factors and screwy power supplies that work only with their motherboards. And while they've benefited from things like the ATX standard, they haven't really been a contributor to open technologies the way IBM or Google has. Still, if I have to concede one of these it would be this one.
"Even quite a bit of Apple's OS is open source software that they've re-branded."
Sort of irrelevant. They may have gotten a leg up by using the MACH kernel, but their model is to close everything down. Sure, Mac OS will run on standard x86 hardware... but it's locked down so it's difficult, with a nice little legal club over your head if you try. Their fortune has come from their proprietary features, particularly with the iPod / iPhone.
"I'm not aware of any "Cisco network protocol"; they simply produce network hardware that supports open standards."
Ha! Cisco has all kinds of proprietary extensions. They have their own OS (actually several, one of which happened to be called IOS, which Apple then had to license.) Sure, their equipment handles open networks, but they lock down everything they possibly can. Cisco's big money comes from BIG systems, and trust me, you can't just pull out a AS9000 router and drop in a Juniper T series router. Hell, even the 48-port managed switches here at my company (which are Dell branded Cisco switches) have proprietary features. Don't get me started on their VoIP phones, either.
The Itanic may have flopped, but remember that the x86 architecture is as non-open as it gets. Invented by one company, held on to by them for as long as possible, with lawsuits galore whenever they can get away with it. They forced nVidia out of the chipset business, for goodness sake. When AMD came out with a very nice set of 64-bit extensions that everyone praised, Intel waited as long as possible and then grudgingly added them... with just enough difference to annoy every compiler writer on the planet.
"As for CIFS, yes it has been quite successful in it's niche - after they moved it off their own underlying protocol and switched to TCP/IP like everyone else."
This an example of the worst of both worlds. Microsoft can say "See! We support open standards like TCP/IP!" which is technically correct but useless in practice, since you're stuck using proprietary stuff like CIFS and Active Directory and Exchange anyway.
"Burroughs, ICL, DEC, NCR, etc..."
Good point. You can add a lot of others, too. (Although, don't forget DEC was bought by Compaq which is now part of HP, again reinforcing the idea that HP made its fortune of proprietary products.) But where is the Microsoft of the open world? Of all the really important open technologies we use, did any of their inventors go from a garage to billionaire? I don't see Bjarne Stroustrup or Linus Torvalds selling their 450ft yachts because they want to get a new one bigger than Paul Allen's or Larry Ellison's.
"Companies who rely on having an existing base of customers who can't easily switch are going to find their customer bases fading away and new customers hard to get."
While I hope this is true, I don't yet see any evidence of it. I have yet to have a customer ask me for a PLC other than A-B or Siemens (and many years ago Modicon, but nobody's asked us for them in nearly a decade.) I have yet to have a customer ask me for a drawing in a format other than DWG. I have yet to have a customer or vendor send me a document in anything other than an Office format. (Okay, okay, I have seen lots of PDF, but PDF got big when they were proprietary.) I once did a Profibus network layout in OpenOffice.org Draw, purely because our electrical design team was bogged down and I suck at AutoCAD, plus it LOOKED better in Draw. I had to give it to the customer in PDF format, of course.
Would I prefer to see open standards win? Yes. Do I think they always do? No. Do I think it would be a good business decision to ban non-proprietary products from our company? No. We wouldn't last a day. And what would you do for computing, btw? x86 is closed. SPARC is open, for all that that's worth. You'd have a hell of a time outfitting your company wit SPARC based desktops and laptops. I can't think of any truly open hardware systems at the level of even most smartphones.
At home, I use a lot of open source software, and I picked Android over iPhone. But I still run Windows, because I play games, and that's really the only choice. Oh, and my wife refuses to use anything else. Would I trade my marriage for running Linux? No. And I won't trade my business, either.
Sage Automation, Inc.
In reply to James Ingraham: In nit picking over details you seem to have overlooked the gist of what I said. Have a look at what IT customers who aren't maintaining legacy systems are buying from those companies today. They're not buying PA-RISC with HP-UX anymore. They're buying commodity servers with Red Hat or SUSE. By and large, the OS, database, or web server are commodities. If you're not happy with the price or service you are getting from Dell, you can switch your future orders to HP or IBM with much less pain than would have been the case in the past.
What happened in the IT market was these companies recognized that the lower levels of the "stack" have become, or are becoming commodities. The technologies are mature and improvements are incremental. If they wanted to prosper, they had to change strategy. HP's server business competes head to head with Dell on price, delivery, reliability, and service. They don't rely anymore on the fact that you once bought an HP server and are therefore stuck with them as a supplier forever more.
It's not that these vendors *wanted* to have a competitive market. The customers forced it on them by changing their buying habits. Fifteen years ago most people in the IT business would have laughed if you suggested this would ever happen. Ten years ago they would have been doubtful. Five years ago it became common knowledge. Today it's accepted practice. I could go over your previous response point by point, but really you're looking on the negative side in each case to try say the glass is half empty instead of saying it's half full (by the way, you do know that Amazon is also a major IT industry service supplier?). Of the companies that you mentioned, here's their ranking in terms of how much work they do to write Linux (as of last summer): Intel (#2), IBM (#4), AMD (#7), Oracle (#8), Google (#12). I can assure you they aren't spending all this money out of the goodness of their hearts.
Will this same process happen in the automation business? I don't see why not. Let's look at the following:
1) Ethernet with TCP/IP (or UDP/IP) has already displaced a lot of the proprietary networking hardware. Commoditisation has already started in that area (although many of the application protocols themselves are still a problem).
2) There's been no significant innovation in PLC languages in the past ten or more years. It's a mature market and ripe for commoditisation.
3) Distribution channels are becoming loosened as local dealers close down and the Internet becomes a more common medium for doing business.
4) The people using PLCs these days are much more computer literate, and are more attuned to the idea of control systems doing more than what typical PLCs are capable of these days.
5) Standardized embedded hardware designs are available, and they almost always use Linux, which means that application development in much easier than in older systems. That lowers the barriers to entry.
6) I/O systems are moving out of racks and onto networks, which breaks the link between PLCs CPUs and I/O.
So how would a vendor make money in this type of market? They can still sell I/O, servo drives, sensors, etc. Why would they want to do this? If you're one of the existing major vendors, you probably wouldn't want to. If your main business is I/O however, you would be quite happy to undermine the major vendors as that would open up a bigger share of the I/O market to you. If your business is stuck in a niche because the established vendors have a lock on the market, the classic business strategy is to do something that disrupts the existing market to create new opportunities to exploit.
Who else would benefit? Well, I know of several large system integrators who have their own soft logic systems. They like their own system because they can tune the features to how their equipment usually works and so are able to put systems together with much less programming. Customers tend to resist buying them however, because they're still proprietary systems. If a customer is going to buy a proprietary system, they may as well buy a third party system and at least have some vendor independence at the integrator level. A common open source system would remove that objection while still providing most of the advantages that the integrators really want.
What would I suggest that automation system designers do? Well for starters, I would suggest that they supply whatever it is that their customers want. Your customers are adults and they can make their own decisions. Your customer wants an AB PLC? Well fine, that's up to them and I am quite sure that AB makes very nice conventional PLCs.
On the other hand, people in the automation business should keep abreast of technology and educate themselves as to what can be done. Make contact with people in your area who can do custom applications, web servers, databases, etc. on open systems and exchange business cards with them. When a customer application comes up that you think could fit that sort of thing, you have contacts lined up that can work with you. Try things out yourself, so you've got your feet wet already when you want to take on something yourself.
The problem with waiting for your customers to ask for something, is that a lot of the time they aren't going to ask you for it if they don't know you can do it. They're going to go to someone else. Many times, the customer won't ask because they don't think there is anyone who *can* do it.
I said "you" above, but that's the third person plural "you" rather than the second person singular "you". It really applies to anyone in the business. Let's take your company for example though. I just had a look at your web site. It says you integrate robots with AB PLCs, mainly for material handling systems. You said you're happy with AB PLCs, and you're happy with the robots you're using, so let's forget those (including the programming software). What aren't you happy with? What would you like to be able to offer your customers, but you can't because it doesn't exist, it doesn't do what you want it to, or it's simply too expensive? That's where you (and anyone else) would start. If you say that you don't have any problems and you already live in the best of all possible worlds, well, congratulations. There's not too many people who can say that however.
@M Griffin: I believe I understand your point.
Let me reiterate mine. If you want to be a gazillionaire, you have to have a secret sauce.
Yes, Red Hat makes money. Yes, some big name companies have been forced into a commodities market where before they had high margins.
If you want to hit it big, you have to have something nobody can copy. HP has much higher margins on their printer ink than on their servers. Apple; 'nuff said. Microsoft; 'nuff said.
Could the mighty automation suppliers be brought low the way some of the big tech companies were? Sure, it could happen. We can even hope for it. There's nothing flawed in your vision. But you semi-alluded to the fact that to compete in that world you'd have to have SOMETHING ELSE giving you your margins. That's the secret sauce I'm talking about.
"I would suggest that they supply whatever it is that their customers want."
I'm glad we agree on that fundamental point.
"On the other hand, people in the automation business should keep abreast of technology and educate themselves as to what can be done."
In my opinion, this is true for anyone in any field.
"The problem with waiting for your customers to ask for something, is that a lot of the time they aren't going to ask you for it if they don't know you can do it."
A classic problem. I really don't know how to handle it.
One final point. In about 1999, I predicted the PLC would be replaced by PCs within 20 years. It didn't take me twenty years to figure out I was wrong. One fundamental thing I didn't take in to account was that the PLC guys would fight back. Now we've got motion instructions in ladder logic, Ethernet connectivity, SD card slots, etc. There's nothing that prevents a PLC from having direct SQL calls in ladder, or whatever. Of course, the argument goes that these are really P *A* Cs, now, rather than PLCs. So maybe I was right after all. :-)
Sage Automation, Inc