Networking Protocols

There are almost as many network protocol solutions in the industrial space as there are automation vendors. Every controller provider either has a proprietary protocol that they bundle with their solutions or a preferred software provider that has written a closed set of drivers to provide an interface over a network. Despite what it may seem to someone in the midst of struggling to get information from all of their capital equipment, the differences in these protocols exist mostly for benign, engineering-oriented reasons.

In the last 15 years, there has been a massive shift to using Ethernet as the physical layer of networks in factories. This has all but replaced older serial communication transmission such as RS232. The main reason for this is that serial devices have to connect in series, meaning that each pair of devices that need to communicate with each other must be directly linked. Ethernet allows many devices to be networked together through nodes and switches using shared infrastructure. This doesn't just dramatically reduce the cost of networking equipment; in many cases it simply makes the networks we want to make possible.

Ethernet seems like the ideal way to connect all the devices in your factory. So why all the different protocols?

The problem with traditional TCP/IP transport over Ethernet (what the World Wide Web runs on) is that it is not real time. This is the dirty secret of the web. To manage all the traffic between computers over a network and ease congestion, data packets getting sent from one computer to another get to pick their own route. Or rather, each subsequent router and switch along the way gets to pick which router or switch to send the packet to next. This is analogous to two cars driving between cities. They will arrive at the same destination, but could take two completely different routes to get there.

For humans requesting photos and videos and sending messages over the internet this isn't noticeable, but when you are counting on a feedback loop between a sensor, a pneumatic piston, and a cutoff switch to work in sync with each other, you are working at another level of precision. Hard real-time requirements in automation control require protocols with short, predictable cycle times and low communication jitter. Three popular network systems that meet these requirements are:

EtherCAT - Originally developed by Beckhoff Automation, EtherCAT (Ethernet for Control Automation Technology) is a leading, open network that is supported by many OEMs, technology groups, and end users standardized in IEC 61158. For a good overview of how the protocol works, watch this youtube video.

PROFINET - Based on experiences learned from the popular fieldbus PROFIBUS, PROFINET was created to be a comprehensive real-time industrial ethernet solution. It achieves this by providing three types of communication. Traditional TCP/IP is normal IP traffic routed over the Profinet physical layer. This is used to send information back and forth to high-level IT systems such as your ERP. Real Time bypasses traditional TCP/IP layers and moves data directly between devices. Isochronous Real Time allows for precise synchronization between devices by allowing transmission at precisely set time intervals on a small scale.

DeviceNet - Rockwell Automation's solution for device-level control and networking. Despite Rockwell's reputation for being a 'closed system', the company has opened DeviceNet's software and architecture up to third-party vendors to increase adoption.

When purchasing capital equipment, the networking protocol and capabilities of the controller should be part of the same discussion as the its Parts per Hour and Mean Time to Failure statistics. Its important that your OEM uses open protocols that can inter-operate with other controllers, have real time capabilities (short, predictable cycle times and low communications jitter), and can communicate with non-realtime systems used for your corporate and business needs.

This article was originally posted on LinkedIn.