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



No comments
The Engineers' Choice Awards highlight some of the best new control, instrumentation and automation products as chosen by...
Each year, a panel of Control Engineering editors and industry expert judges select the System Integrator of the Year Award winners.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
Learn how to increase device reliability in harsh environments and decrease unplanned system downtime.
This eGuide contains a series of articles and videos that considers theoretical and practical; immediate needs and a look into the future.
Learn how to create value with re-use; gain productivity with lean automation and connectivity, and optimize panel design and construction.
Go deep: Automation tackles offshore oil challenges; Ethernet advice; Wireless robotics; Product exclusives; Digital edition exclusives
Lost in the gray scale? How to get effective HMIs; Best practices: Integrate old and new wireless systems; Smart software, networks; Service provider certifications
Fixing PID: Part 2: Tweaking controller strategy; Machine safety networks; Salary survey and career advice; Smart I/O architecture; Product exclusives
The Ask Control Engineering blog covers all aspects of automation, including motors, drives, sensors, motion control, machine control, and embedded systems.
Look at the basics of industrial wireless technologies, wireless concepts, wireless standards, and wireless best practices with Daniel E. Capano of Diversified Technical Services Inc.
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
This is a blog from the trenches – written by engineers who are implementing and upgrading control systems every day across every industry.
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.

Find and connect with the most suitable service provider for your unique application. Start searching the Global System Integrator Database Now!

Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.

These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.

Click here to visit the Case Study Database and upload your case study.