Ethernet : Application in modern manufacturing                                

While Ethernet and the TCP/IP suite are inherently non-deterministic protocols, it is possible to use them for real-time industrial networks. The development of high-speed Ethernet interfaces, switched network infrastructures, and specialized TCP/IP network stacks have allowed a multitude of industrial Ethernet protocols to operate in the millisecond range.

Industrial applications and systems require deterministic operations that traditional Ethernet and Transport Control Protocol/Internet Protocol (TCP/IP) suites did not originally support. A standardized way to describe and test industrial devices is necessary in order to aid users to characterize the performance of their software and hardware applications.

Application Issue
While Ethernet and the TCP/IP suite are inherently non-deterministic protocols, it is possible to use them for real-time industrial networks. The development of high-speed Ethernet interfaces, switched network infrastructures, and specialized TCP/IP network stacks have allowed a multitude of industrial Ethernet protocols to operate in the millisecond range.

The large variety of different protocols and vendors has caused end users to ask many questions, including:

• Which industrial network performs better for my application?
• Which vendor’s products will satisfy my given requirements?
• How will a particular device perform compared to another?
• How does one performance metric compare to another?
• How well will a particular product work in my ontrol system?

Defining performance characteristics of industrial Ethernet applications and devices is analogous to comparing the performance of automobiles. How would one rate the performance of an automobile? Choosing the type of vehicle is one of the first steps when choosing an automobile, since the performance metrics are quite different for each type. Does one’s application call for a sports car, an economical commuting car, a large pickup truck, or a minivan? Once we decide on the type of vehicle, it is necessary to compare vendors and choose which one has the best performance characteristics. In the context of a sports car, horsepower, 0 to 60 mph time, and cornering ability all describe different aspects of the performance of a sports car. The weighting that one places on each of those metrics depends on their application. The same idea applies to the industrial control system workspace. Having a standardized way to measure the performance metrics also aids end-users. Using an automobile example again, one standardized metric and method designed by the U.S. Department of Transportation is the fuel economy test. It uses a standardized series of tests and produces two commonly known metrics, city, and highway fuel economy. These metrics compare vehicles from multiple vendors to determine how the vehicles meet the requirements for their particular application. One of NIST’s long-term goals for this project is to develop standardized methods to measure the industrial Ethernet performance metrics.

Performance testing method
There are two types of communication methods in most industrial Ethernet devices:

• Publish/subscribe or peer-to-peer
• Command/response or master/slave

For publish/subscribe or peer-to-peer communications, two or more devices communicate with each other in some way that the devices themselves negotiate. This may be at an understood rate or at some predetermined condition. For example, device A wants to get a digital input value from device B at a rate of 20 times a second. Device A sends a message to device B requesting the particular value and specifies the particular rate. Device B can accept this request or deny it based on its configuration. If device B accepts the request, then it starts sending messages to device A, and possibly other devices, 20 times a second. Other than the initial request, device A does not dictate when device B will send its messages. The true rate at which the messages transmit depends solely on device B’s internal hardware and software architecture. For command/response or master/slave communications, two devices communicate with each other based on how the commander or master device dictates. Responder or slave devices can be relatively inexpensive and unintelligent, since their sole purpose is to process commands and respond back. Following the prior example, if device A wants to get a digital input value from device B at a rate of 20 times a second, device A sends a message to device B 20 times a second for that particular value. Device B responds back with the value as quickly as it can. The true rate at which the messages are sent depends on both device A’s and device B’s internal hardware and software architectures and the network connecting the two devices. Based on these two types of communication methods, two main performance metrics appear Cyclic frequency variability/jitter and latency.

                When communicating at an understood rate, the ability for the devices to maintain the desired message rate is extremely important. Control loops based on this type of communication count on the message streams to maintain at the desired rate. Control systems theory states the communications used in a control loop should operate at least twice as fast as the overall loop; however, this is not always the case in practice. For tightly coupled control loops that operate at or near the same rates, variability or jitter in the packet interval may affect the system’s performance in unintended ways. When responding to a particular command or pre-determined condition, the ability for a device to process the command or condition quickly is most important. An unexpected delay or latency in the response message coming from the device may seriously affect the system’s performance behavior. Real-time EtherNet/IP typically uses a form of publish/subscribe communications with two parallel streams of traffic, each flowing in the opposite direction. For EtherNet/IP, the desired packet rate is the Requested Packet Interval (RPI). When the request is that a device produce network traffic at a particular RPI, it is required to send back an Accepted Packet Interval (API) to the requester.

                This API value represents the agreed upon rate that each device expects to receive network packets for that particular traffic stream. Most devices use the same API rate for ingoing and outgoing real-time network streams, even though it is not a requirement of the EtherNet/IP specification. The performance test system uses network capture files to verify the device under test (DUT) maintains its desired API. The measured packet interval (MPI) is the rate at which the test system receives packets from the DUT. The basic methodology for the IENetP test system is fairly simple, regardless of the metric being measured. The process and test tool engine does not have to change to suit a particular metric, background traffic, or analysis method in the test.

Basic Methodology:

• Begin recording network traffic.
• Establish a connection with the device under test (DUT).
• Begin transmitting background network traffic, based on the particular test conditions.
• Wait for a given amount of time.
• Stop transmitting background network traffic.
• Close the connection with the DUT.
• Stop recording network traffic.
• Analyze the network traffic capture, and report he results.

The current version of the IENetP test tool is not capable of communicating directly with the DUT, capturing traffic, or issuing background traffic. The current test tool is primarily a data analysis tool, and is only for step 8 in this methodology. Future versions of the software will incorporate a greater portion of this methodology. Until the IENetP test tool is capable of communicating with the DUT directly, NIST plans to produce a recommended testing procedure that requires specific background traffic types and amounts. The user is responsible for transmitting the background traffic on the network with the current version of the tool.

Performance Testing Flexibility
The performance test system is, by design, extremely flexible, thus allowing the user to determine the performance metrics for their desired application. The test system can be as simple as attaching a crossover Ethernet cable between the tester and the DUT, or it could be as complex as a large set of infrastructure devices between the tester and the DUT. When testing the performance for one particular device, it is important to isolate the device from a network to remove any latency introduced by other infrastructure devices. That is why it is best to attach the test system directly to the DUT to keep the latency to the absolute minimum. When using a wireless DUT, it may be necessary to use a wireless access point or other network hardware to connect to the DUT unless the tester has a wireless interface, as shown. When trying to analyze the performance of a system, one may split the test system into two time-synchronized devices, although there is no requirement to split the functions for test systems with enough network ports. Network taps are here since they introduce no collisions or latency that a conventional network hub might introduce. The IENetP test tool currently supports only data analysis. The data analysis method used in the most recent version of the test tool is a distribution analysis of the cyclic frequency variability/jitter of the MPI, calculating the following values: minimum, maximum, mean, standard deviation, skewness, and kurtosis. The objective is to measure how well the DUT adheres to its configured RPI/API value while operating in a variety of network conditions.

                The objective of the IENetP test tool is to provide meaningful data to the vendor without having to know the statistical analysis in depth. The user interface will allow the vendor to specify a myriad of options to process and display data in various ways while the tool takes care of the underlying statistical analysis yielding those results. The IENetP test tool will allow the user the flexibility to generate customized reports that are relevant & meaningful for their device.