Friday, November 1, 2013

Four Reasons Why No Standard is the King of Automation

Posted by Joanne Bacharach

First, what do we mean by the “King of Automation”? If one standard were king, every component of an industrial automation system—from PLC to PC to PAC—would speak the same language regardless of manufacturer. In a way, this is what the micro-USB plug did for cell phones and cell phone chargers, but in industrial automation terms. (Isn’t it so much more convenient now that our cell phones and chargers all have the same plug?!)


Let’s look at some contenders for the King of the Hill, and then talk about the four reasons why none of them is truly King…yet.

The Three Contenders 

Modbus: This protocol is ideal for quick, reliable communication of simple data to and from I/O devices, while consuming low bandwidth.

Introduced in 1979 and maintained by a member-based, non-profit organization, Modbus is very established in the industry. The protocol has the advantages of a simple address scheme and standard Serial or Ethernet communication using dedicated Port 502 for TCP/IP. It is based on a Master/Slave topology, where a Master station issues commands requesting simple functions to be performed by the Slave device. These uncomplicated functions are a throwback to the solid-state relay and ladder logic days: read coil, read register, force coil, and write register.

Modbus is also open to all users and free of charge—but is it the King? Not really. Modbus is typically used for straightforward connections to devices, not for complex device modeling or for connecting on a software systems level. In the modern era, some automation tasks require more flexibility and functionality than Modbus can offer. For example, a device may support different data types than what is available in Modbus. Also, the Modbus protocol offers no security, such as data encryption.

Common Industrial Protocol (CIP): This protocol is ideal for connecting and modeling composite information across control and device layers, while leveraging the power of Internet topology.

Supported by the Open DeviceNet Vendors Association (ODVA) founded in 1995, CIP is an object-oriented protocol for modeling different devices and their attributes and behaviors. Well-known PLC manufacturers like Rockwell Allen Bradley and Omron use the CIP EtherNet/IP standard for communication. However, the device profiles in CIP go way beyond PLCs to a wide array of industrial instruments like AC motor drives, discrete sensors, and barcode readers. These profiles allow vendors to model certain information in a device (like Motor Data for an AC Drive) and use the model to send information about that device over the wire. Since CIP is considered “media-independent,” it could theoretically be used over any communication link. The grand vision of CIP is this: if a bunch of manufacturers use CIP standards for communication, then any device using CIP can be harmoniously linked over any wire or cable. CIP even has support for Modbus translation, bringing Modbus under its umbrella!

Does this make CIP the King of Automation? Not yet. At a whopping 1500 pages for just a single volume of the specification, it is fair to say the learning curve is substantial. Also, CIP still focuses more on the device layer, not necessarily the software systems layer (like HMI to server connections). As a result of these limitations and for other reasons not listed here, not all vendors fully support CIP. Check out the vendors that do support CIP at

OPC Unified Architecture (OPC UA): This protocol is ideal for secure, remote, and easily-established links between software systems while using popular IT mechanisms like URLs, TCP, and HTTP for communication.

The OPC Foundation, established in 1995, has a history in software systems communication. OPC is the standard way to connect a data server to an MES, SCADA, or HMI. OPC UA was released by the foundation about 5 years ago, and offers the advantages of bypassing Windows-specific communication protocols like DCOM. This is possible because OPC UA-enabled software can create and host endpoint URLs independent of the Operating System, similar to the type you would use on the World Wide Web. These URLs take the form “opc.tcp://IPaddress:49320” with 49320 being the single dedicated TCP port for OPC UA communication. Because OPC UA only uses this one port, it is considered firewall friendly. If that port is open, the OPC UA endpoint URL can be entered in the client software (for example, the HMI), just like you might type a URL in a browser to navigate to a website. The data is then easily passed from the endpoint (for example, a data server) to the client. Taking another page from the World Wide Web handbook, OPC UA uses the same security as e-commerce, with certificate handshaking and 128 or 256-bit encryption. In other words, if you are confident sending credit card information over the wire to Amazon, you can be confident sending sensitive or critical operations data over the wire with OPC UA. OPC UA also has flexible information modeling that can tie in real-time, alarm, and historical data. Finally, OPC UA servers can be embedded in devices, which several PLC and device manufacturers have already accomplished. (Siemens is particularly advanced on this front!)

Is OPC UA, therefore, the King solving all communication woes? Perhaps—but as a relatively new standard, it will take time for vendors, engineers, and companies to vet and adopt it. Also, OPC UA admittedly has a bias towards the software systems level and is a more involved standard, which bumps up the learning curve for this standard as well.

Why are none of these standards the King of Automation?

The Four Reasons  

1. Trade-Offs

You are surely well-acquainted with the idea of trade-offs. For example, in a game of chess, you might lose your bishop in order to gain a valuable position. Trade-offs abound in the protocol world too. Take the Allen-Bradley ControlLogix PLC family, which uses the CIP EtherNet/IP protocol. By leveraging the custom object models of CIP, these devices are highly flexible, and the memory layout or address space is completely configurable (not fixed like Modbus). The PLC gives users the freedom to refer to an I/O point with any intelligent name desired, such as “Temperature” or “MyFunOutput”. The adaptability of the device makes it well-suited to handle complex tasks. Over the wire, however, that symbolic name “MyFunOutput” may eat up more space in the data packet than a Modbus numeric address like 40001. This means you have less room in the packet for the I/O data, and less throughput. Also, you might pay more for these highly-configurable devices than you would for a Modbus device with limited configurations.

Trade-offs like these highlight the need in the automation space for both highly flexible and dynamic protocols, as well as simple, straightforward ones.

2. Theory of Entropy

As systems lapse in to legacy and more devices become connected (from the light bulb to the CNC machine), the picture of process and operations becomes more jumbled. For example, maybe an employee who left the company five years ago designed custom software to talk a proprietary language to a scale, and no one has had the time to go back and update his code or connect that device in any other way. Maybe the company just added a new line of equipment from a new vendor and the equipment doesn’t work well with the existing HMI software. Maybe the company acquired an overseas plant with a completely different systems architecture, making MES and OEE integration a nightmare.

Whatever the case, it is clear that as automation systems distribute, multiply, and add more segments, the ability of any one standard or protocol to “rule them all” will only be challenged, not made easier.

3. Evolving Technology

When new technology is released (like the mobile and cloud-based systems of our century) it radically changes the automation landscape. A protocol that worked great in the classic environment, where every device and panel is within the same building and can be connected using serial cables (looking at you, Modbus), might now have trouble meeting the needs of the remotely connected world. It’s not Modbus’ fault; no standard can predict the future. Even a potential universal standard may eventually be displaced by new technology.

4. Difficulties of Worldwide Adoption

Worldwide adoption presents certain difficulties that may at first be obscured by the fluidity of the World Wide Web and having information at our fingertips. Politics, culture, and even geography influence our decisions to accept certain methodologies. For example, IEC 60870 was developed in Europe for power substation automation, and many European governments have adopted this as the standard for the power infrastructure in their respective countries. However, the standard used in the United States for communicating with power substations is DNP3 due to greater provisions for security in the DNP3 specification (and probably also because it was created by a US organization).

Overcoming geo-political barriers to global adoption is about more than maintaining a great protocol or standard. The organization that promotes this standard also must have an effective worldwide adoption strategy that is well-executed. It is no easy task for one organization to accomplish both protocol development and support and adoption strategy and execution.

Wrap Up

No standard rules them all, at least for now—but they can play nice. OPC UA is a good example of this, unifying many needs into one bundle.

Luckily, even though there may never be one universal standard, the rainbow of communication protocols out there can be brought under one roof with wrappers, translators, and servers.

So here’s the Kepware plug: don’t worry about those hundreds of devices speaking different protocols, and don’t fret about bridging the gap between legacy devices and brand new web-enabled software. Kepware is dedicated to making this communication easy and efficient for you. Our communications platform, KEPServerEX, can connect to devices and applications using over 150 different protocols, which of course include Modbus Serial, Modbus TCP/IP, Allen Bradley ControlLogix CIP, and OPC UA. We even offer a User Configurable (U-CON) driver for connecting to that obscure scale speaking some odd distortion of Modbus in the dark corner of the plant. And if ever a standard ascended the throne as King of Automation, we would support that too!

Download a Free 2-Hour Demo of KEPServerEX