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 Top Plant program honors outstanding manufacturing facilities in North America. View the 2013 Top Plant.
The Product of the Year program recognizes products newly released in the manufacturing industries.
The Engineering Leaders Under 40 program identifies and gives recognition to young engineers who...
The true cost of lubrication: Three keys to consider when evaluating oils; Plant Engineering Lubrication Guide; 11 ways to protect bearing assets; Is lubrication part of your KPIs?
Contract maintenance: 5 ways to keep things humming while keeping an eye on costs; Pneumatic systems; Energy monitoring; The sixth 'S' is safety
Transport your data: Supply chain information critical to operational excellence; High-voltage faults; Portable cooling; Safety automation isn't automatic
Case Study Database

Case Study Database

Get more exposure for your case study by uploading it to the Plant 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.

Maintaining low data center PUE; Using eco mode in UPS systems; Commissioning electrical and power systems; Exploring dc power distribution alternatives
Synchronizing industrial Ethernet networks; Selecting protocol conversion gateways; Integrating HMIs with PLCs and PACs
Why manufacturers need to see energy in a different light: Current approaches to energy management yield quick savings, but leave plant managers searching for ways of improving on those early gains.

Annual Salary Survey

Participate in the 2013 Salary Survey

In a year when manufacturing continued to lead the economic rebound, it makes sense that plant manager bonuses rebounded. Plant Engineering’s annual Salary Survey shows both wages and bonuses rose in 2012 after a retreat the year before.

Average salary across all job titles for plant floor management rose 3.5% to $95,446, and bonus compensation jumped to $15,162, a 4.2% increase from the 2010 level and double the 2011 total, which showed a sharp drop in bonus.

2012 Salary Survey Analysis

2012 Salary Survey Results

Maintenance and reliability tips and best practices from the maintenance and reliability coaches at Allied Reliability Group.
The One Voice for Manufacturing blog reports on federal public policy issues impacting the manufacturing sector. One Voice is a joint effort by the National Tooling and Machining...
The Society for Maintenance and Reliability Professionals an organization devoted...
Join this ongoing discussion of machine guarding topics, including solutions assessments, regulatory compliance, gap analysis...
IMS Research, recently acquired by IHS Inc., is a leading independent supplier of market research and consultancy to the global electronics industry.
Maintenance is not optional in manufacturing. It’s a profit center, driving productivity and uptime while reducing overall repair costs.
The Lachance on CMMS blog is about current maintenance topics. Blogger Paul Lachance is president and chief technology officer for Smartware Group.