Ethernet is ubiquitous. As long as it is the protocol of choice in IT, and the cost of even industrially hardened Ethernet switches and I/O are low, Ethernet will remain the communication protocol of choice for companies. So it is very important to understand what Ethernet is, how it works, and what it can and cannot do in the industrial environment.
Ethernet is a family of frame-based, or data-packet-based, networking technologies that are part of the IEEE 802.3 standard. There are several varieties. Physical Ethernet networks consist of nodes, switches, routers and repeaters. Switches, especially smart managed switches, have made it possible to have Ethernet networks consisting of a nearly infinite number of nodes.
Ethernet nodes send each other data packets. As with other IEEE 802 local area networks (LANs), each Ethernet node is given a media access control (MAC) address used to specify both the destination and the source of each data packet. All packets are broadcast; that is, they are sent to all nodes. Data in the packet causes the node for which the packet is intended to wake up and grab the data. Adapters come programmed with a globally unique address. Nearly all generations of Ethernet use the same frame formats and can be readily interconnected using bridges.
But here’s the problem. Since Ethernet is a broadcast network, all of the packets go to all of the nodes, and collisions between data packets are a serious problem. They can cause both bandwidth reduction and data loss. (Managed switches help by directing the data packet to only the designated receiving node or nodes, but they cannot eliminate collisions.)
With Ethernet, data can take variable paths and therefore variable times to travel from the sending node to the receiving node. If this is an email, nobody cares. If this is a control variable for a high-speed CNC mill, packet loss and speed loss can be disastrous. The industrial environment requires “real-time” information transfer. Because the time it takes for any given packet to arrive at its destination on an Ethernet LAN is not determined, it is difficult to guarantee real-time control functions over Ethernet. The time it takes for each packet to arrive at its destination should be determined…that is, the process must be deterministic.
A little history
Originally, data transmission on the plant floor was done by proprietary twisted pair serial communications protocols (like RS-232 and RS-485), which were deterministic by nature since they were half-duplex. There was a defined amount of time to wait for any response after sending any message from the master. The timing was very predictable (hence deterministic) but it was very slow.
One of the first, if not the first, industrial data network was Modbus, a half-duplex serial protocol devised by Hung Yu in 1979 for Modicon PLCs (hence the name MODiconBUS). Modbus, being half-duplex, is highly deterministic; but, being serial, it is quite slow, with data transmission rates as rates as low as 300 baud (and typically 2.4Kbaud).
With Ethernet, the rate of communication (the speed) is much faster, but the time span (the determinism) in which a response is expected is unpredictable. There have been many attempts to adapt Ethernet technology to better serve the plant floor. There are, at last count, over 30 network protocols specifically designed for the industrial environment. Many of these are open, and standards-based, such as Modbus, Foundation fieldbus, DeviceNet and ControlNet (the Common Industrial Protocols) and others. Three of these protocols have significant followings in both discrete and process automation: EtherNet/IP, Modbus, and Profibus and Profinet.
EtherNet/IP (where the “IP” stands for “industrial protocol”) can be easily confused with Ethernet and IP (where “IP stands for “Internet Protocol”). EtherNet/IP is an industrial protocol that operates over Ethernet, using the Common Industrial Protocols (ControlNet, DeviceNet). EtherNet/IP is an application-layer protocol, and it considers all of the devices on a network to be objects. But EtherNet/IP is built on the standard TCP/IP stack, making it easy to connect plant floor data from controllers to enterprise servers running Ethernet TCP/IP.
Although EtherNet/IP was developed by Rockwell Automation for its Allen-Bradley line of controllers, it is now considered an open standard and is managed by ODVA (www.odva.org). Formerly known as the Open DeviceNet Vendors Association, ODVA now calls itself “the organization that supports network technologies built on the Common Industrial Protocol (CIP) — DeviceNet, EtherNet/IP, CompoNet, and ControlNet.” EtherNet/IP is designed for those control applications that can accommodate a measure of non-deterministic data transfer, but it is significantly more robust and deterministic than standard Ethernet and TCP/IP are.
Profibus and Profinet are also managed as open standards by Profibus&Profinet International (PI, www.profibus.com), even though they were originally created by Siemens. Profibus is significantly more deterministic than EtherNet/IP, just as the other CIP protocols (DeviceNet and ControlNet) are. Profinet is designed to be an industrial protocol running on Ethernet, similar to EtherNet/IP. Profibus and Profinet are designed to work together, just as ODVA has revised the CIP protocols to work together.
According to PI, Profinet is an open Ethernet standard designed to be “real-time Ethernet.” It has two models: The component model or Profinet CBA, and the peripherals model or Profinet IO. The transmission times of the two models are different.
Also, there are three different protocol levels in Profinet that are differentiated by speed:
• Profinet CBA, for a plant needing reaction times in the range of 100ms, uses TCP/IP.
• Profinet CBA and IO applications needing up to 10ms cycle times use the RT (Real-Time) protocol.
• Profinet IO applications in drive systems for motion control use the IRT (Isochronous Real-Time) protocol for cycle times of less than 1 ms.
What EtherNet/IP and Profinet have shown is that determinism isn’t all or nothing. But determinism is the limiting factor to overcome. End users, machine builders and integrators often select protocols based on the purchaser’s comfort level with the vendor, or a favored protocol type. Sometimes, users will select protocols and bus types based on performance. If you need 1 ms speed, you will not choose a 250 ms response bus, regardless of how much you like the slower vendor. But the first protocol that can produce robust, fast and deterministic control—all three—will win.
Sidebar: November 2011, Determinism Vs. Speed.
To read the article, click here
Edited from a white paper by Mark Lochhaas, product manager for Advantech, www.advantech.com.
