INTRODUCTION TO ETHERNET/IP AND QUALITY OF SERVICE (Part 1)

This is the first of a series of articles on EtherNet/IP and Quality of Service, a subject I haven’t tackled in the 20 years I’ve been writing about EtherNet/IP. Why you might ask? Because it’s been largely irrelevant over the years to most control engineers.

Gary Workman, formerly of General Motors, stated it precisely when he said:

As a practical matter, in the overwhelming majority of situations, on a fully switched, full-duplex, fast Ethernet network, when the originating device gets the EtherNet/IP implicit message sent, it will get delivered in a timely fashion without the control engineer having to worry about Quality of Service.  Particularly in a PLC-based control system, the Ethernet network has the bandwidth to burn.  The PLC Ethernet interface simply doesn’t have the bandwidth capability of even moderately loading a 100MBPS Ethernet link. 

As control engineers, our goal is to design and maintain an EtherNet/IP control system where implicit message traffic is preferentially handled such that the production system meets its requirements. If there is a queue anywhere in the transmission and delivery system transporting a control system message between applications, you want the control system messages in that queue to get handled before any non-control traffic gets processed by the queue handling mechanism.

This has not been a problem in the past and it is not a problem now for PLC-based Ethernet systems as PLCs don’t have the capability to generate enough EtherNet/IP messages to overwhelm a typical switch. The problem arises when you start using non-PLC-based EtherNet/IP controllers or when you have non-control devices sending large files, streaming video, or other large volumes of message traffic across the control network and interfering with control system traffic. Now, with the rise of the Internet of Things devices, more video, more sensors, more data collection, and more traffic on the control system network, control engineers are starting to see occasions where all this other traffic interferes with control traffic.

Failing to manage all these extra traffic results in EtherNet/IP control messages experiencing unacceptable periodic delays – anything on the order of a hundred milliseconds or more. When this happens, the real-time connection breaks, the controller signals a fault and, often, there is a problem in the production system.

Another situation when QoS is going to really matter to you is when routing control system traffic either within the manufacturing network or over the corporate IT network. There are many complexities to managing Quality of Service when routers are involved and even more when you have to negotiate with your IT department to use their network to meet your operating performance requirements.

This series of articles will introduce the control engineer to the Quality of Service. It will discuss what Quality of Service is and how you can manage it if you have to. Unfortunately, this can only be a general introduction to QoS, not a how-to guide. Every brand of switch and router implements Quality of Service slightly differently, uses different kinds of terms, has different algorithms, different numbers of queues where messages are held until delivered, and operating characteristics that differ from other ones.

In my next article, you’ll learn why one of the smartest control engineers in the industry told me “Take two aspirin and call me in the morning!” when I told him that my head hurt from watching too many Quality of Service videos on YouTube.