Answers about industrial Ethernet

Why is Ethernet good for industrial applications, instead of other network protocols? Why do Ethernet protocols differ? Which should be used, fiber or copper? Pepperl+Fuchs offers answers.

09/01/2011


Valuable bandwidth is wasted when each sensor is a node on Ethernet. This figure shows that data from each sensor—just one bit representing its output state—is placed in the 46-byte-wide data payload section of the frame. All other unused data bits need tThere are many reasons why Ethernet is a good solution for industrial applications.

  • Ethernet has raw speed. This means that the bit time (time it takes to transmit a single data bit) is very short; 100 ns for a 10-Mbit network and 10 ns for a more common 100-Mbit installation. This advantage is slightly counteracted because the “overhead” of an Ethernet data frame can be quite large. The minimum Ethernet frame size is 567 bits or 72 bytes, resulting in a minimum payload of 46 bytes. To send a small piece of data using Ethernet, a lot of other data must be sent over the network within the same transmission. This is comparable to using an 18-wheeler to transport only one piece of mail from point A to point B. While the Ethernet 18-wheeler is really fast, the process is still wasteful; especially since more data (up to 46 bytes) could have been packed into that data frame without any reduction in speed.
  • Ethernet supports many services. For instance, an Ethernet-enabled device can carry its data sheets in the form of a PDF file. When necessary, the installation team can retrieve this PDF file. Other useful services are possible and have been implemented in many cases.
  • Programmers find Ethernet easy to work with. The No. 1 reason is that programmers use PCs to write application logic, and every PC has a built-in Ethernet port. There is no need to carry conversion hardware and programming adapters. Convenience cannot be underestimated, as it immediately leads to better diagnostics and thus system uptime.
  • Multiple Ethernet-based protocols can be implemented on the same physical device. In the past, a machine builder that had to use different PLCs depending on what the end user requested had to be familiar with several distinctly different types of hardware and their configuration tools. With an Ethernet device, the machine builder can simply turn on a certain protocol. In most cases, the other services mentioned above are the same. An example is the Ethernet‑based Ident Control RFID system. Today, this unit supports Ethernet/IP, Profinet, Modbus/TCP, and TCP/IP, all on the same hardware. Other services include a Web server that allows downloading a data sheet, an e-mail client, and a Java applet to initiate tag read-and-write operations. The Web interface does not change. Similarly, the command structure used to initiate RFID reads or writes from the different PLCs is identical.

In contrast, a solution where sensor data is first consolidated—in this case via an AS-Interface network—hundreds of I/O bits are combined into one Ethernet frame. This is not only a more efficient way of transmitting data to the PLC, it has many additionIt’s difficult to comment on why different Ethernet protocols came about. In most cases, different protocols have been created by competing PLC manufacturers, each claiming to have better solutions. In other, more specialized cases, the protocols were first developed to address a specific set of performance parameters (for instance, drive coordination). Later, these capabilities were addressed by two solutions, drive and digital. At first, drive did not compete with digital. Now, however, they have become competitors since both solutions address the same set of requirements. In the long run, it looks like all protocols will attempt to address all needs. Whether this is going to work or not remains to be seen. One thing is for certain. The user is going to lose if the protocol war of today is anything like the network war from 10 years ago.

Since Ethernet topologies are inherently point-to-point, creating star topologies with a switch at the center is the only feasible solution. (Hubs cause data frame collisions and are thus out of the question for automation applications.) Historically, these limitations have been a problem. Newer hardware designs include switches at each device, thus removing the star-topology limitation and allowing ring and daisy-chain topologies. This design improvement is certainly a step in the right direction. But combining this topology drawback with the fact that the Ethernet protocol frame is still too large and unwieldy to carry only a few bits of information, it should become clear that Ethernet needs another network at the sensor/actuator level. One solution (called “AS-Interface”) exists.

Combining Ethernet with AS-Interface (transparent to the PLC) uses the strength of each solution. AS-Interface is topology free and can collect I/O data from a large number of low-level field devices including sensors, safe I/O, and analog devices, and bring it in a consolidated form to Ethernet. Here, this data is efficiently transmitted in one Ethernet frame. This efficiency results in superior installation flexibility with highly distributed I/O (due to AS-Interface) and high-speed communication and diagnostics at the upper-level network (due to Ethernet).

The question of whether copper or fiber should be used has been addressed by the users: The answer is both.

While Ethernet-based systems can be implemented without the help of the IT department, it seems prudent to draw on IT expertise. If a network is completely removed from the outside world (no IT needed), the network should be safe. However, in that case, getting help from the outside is not possible. With this in mind, controls engineers are probably better off if they discuss their needs and problems with IT. IT can offer assistance in terms of network security, monitoring, and getting outside help. This input from IT will certainly result in a more productive solution with higher system availability.

There was a time when viruses, worms, and Trojan horses were a problem only for PCs. Unfortunately, that time is over. The Stuxnet virus was written specifically for the Siemens S7 platform.

- Helge Hornis, PhD, is manager, intelligent systems, Pepperl+Fuchs. Edited by Mark T. Hoske, CFE Media, Control Engineering, www.controleng.com.

www.pepperl-fuchs.us 

www.controleng.com/new-products/industrial-networks.html 

www.controleng.com/channels/plant-safety-and-security.html 

Control network security lessons from Stuxnet