Installing and maintaining industrial Ethernet presents unique challenges compared to traditional industrial networks such as DeviceNet and PROFIBUS. Due to these differences, protocol analysis tools are needed to speed new product developments containing industrial Ethernet, migration of legacy networks to Ethernet, and troubleshooting faults in installed networks.
By Steve Montgomery

With Ethernet, each sequential packet may use a different application protocol (OSI layer 7). We are accustomed to this complexity on our office LANs. From your office desk, you may access the Internet, e-mail, and transfer large files at almost the same time causing sequential packets of HTTP, SMTP, and FTP protocols.

In contrast, all nodes speak only one protocol on a traditional industrial sensor or control bus. For example, a DeviceNet network uses only DeviceNet protocols for wiring and connectors (OSI layer 1), for media access control and node configuration (OSI layer 2) and for application messaging (OSI layer 7). To use two protocols, such as DeviceNet and PROFIBUS, you need to install a gateway, such as an SST X-Link, between the DeviceNet and the PROFIBUS networks to buffer and translate. For another example, some controls engineers try to choose best-in-class automation components for their particular application. They could select a Rockwell Automation ControlLogix programmable logic controller (PLC), Siemens modular ET200 input/output blocks, and an SST gateway card installed in the PLC backplane to enable the ControlLogix to speak PROFIBUS to the ET200.

A typical industrial Ethernet installation may still contain multiple sequential protocols. Ethernet simplifies selection of best-in-class industrial automation components. The same Ethernet wiring, connectors, media access control, node addressing, switching and routing will support almost all the different application layer protocols. Therefore, on the same Ethernet network, you could run Modbus, T1 Direct, L1, EtherNet/IP (which includes CIP), PCCC, DNP3, and many other industrial protocols. These packets can all be seen on the same Ethernet network or even show up sequentially through the same switch. An industrial Ethernet gateway should decode Ethernet packets for application layer type and automatically translate.

Diagram 1: Sequential industrial Ethernet packets can use different application protocols.

This powerful multiple-protocols-in-sequential-packets feature of industrial Ethernet creates a challenge for designers of industrial Ethernet components and especially for network support staff. Information Technology (IT) support staff, responsible for maintaining office LANs, have long understood the need for tools such as cable testers, remote monitors, and protocol analyzers.

Fix It Fast

Cable testers ensure that the cable has good connectivity and matches specified operating parameters such as consistent impedance, capacitance, near end cross-talk between pairs (NEXT), and others. Thus a cable tester can identify bad cables before they are connected to devices. These testers typically use Time Domain Reflectometry (TDR) for impedance measurements and AC voltage sourcing/measurement for cross-talk measurements. As of this writing, available cable testers match commercial Ethernet standards but do not contain thresholds that match the upcoming industrial TIA/EIA standards (EIA/TIA 42.9 Industrial Structured Cabling committee).

Remote monitors log operating network parameters and calculate statistics. These parameters include which source addresses are active on the network, destination addresses and bandwidth consumed. The most common type of monitors are called RMON and RMON-2. Some switches offer RMON agents (or probes) within the switch but typically at a cost of over $2,000 USD (e.g. Siemens) or almost four times the price of a ruggedized industrial switch without RMON (e.g. RJ-Lnxx). Hand-held LAN testers, which include both cable test and monitor functions such as the Fluke LANmeter, can be purchased from $1,500 to $25,000 USD according to features.

A commercial office-LAN protocol analyzer typically contains segment and node level statistics, packet capture, protocol decode, and packet analysis. The statistics show the total bandwidth utilization, top talkers (% of bandwidth used by node), which nodes are causing errors, protocol distribution, frame size distribution, and more. Packet capture, protocol decoding and packet analysis can show what application is being used by each node. For example, a commercial protocol analyzer will decode HTTP, FTP, SMTP, and SNMP. Some will even decode Oracle packets.

Advanced commercial protocol analyzers may even contain a traffic generator. Traffic generators can create packets to stress the network components. The simplest form of traffic generation simply sends a 'ping' out to each node to see if they can respond. Broken communication could be caused by a bad cable, disconnected device, or a faulty device.

A good commercial protocol analyzer decodes, displays and analyzes the protocols on all seven OSI communication layers:

  • Layer 1: physical layer (e.g. cabling and connectors)
  • Layer 2: media access control and addressing
  • Layer 3: network (e.g. IP)
  • Layer 4: transport (TCP or UDP)
  • Layer 5: session (manages series of messages for complete session)
  • Layer 6: presentation (encryption, security and format)
  • Layer 7: application

Layer 5 and 6 are only used in very complex networks such as the Internet for complex routing. Plant floor Ethernet usually uses layers 1-4 and layer 7.

An ideal protocol analyzer will also capture and decode legacy protocols. The largest risk today is the loss of key personnel. For a new engineer, it typically takes 6 months to develop basic fieldbus competency and 2 years to achieve expertise on a fieldbus or industrial Ethernet protocol. If you lose a key protocol-educated person on a legacy network, then you may have lost that knowledge base forever. The industrial protocol analyzer has the knowledge built in and allows a wide range of engineers to use it for diagnostics.

For the factory floor, the best tool for more network uptime is an industrial protocol analyzer. It has all the features of a commercial LAN protocol analyzer, yet it replaces office Layer 7 protocol analysis with industrial protocol analysis. Why are industrial protocols important? Many errors are often found in the application layer, especially since both industrial Ethernet devices and gateways are relatively new and not yet bug free.

Industrial Ethernet installations often demand better timing, more ruggedness and links via gatesways compared to office Ethernet due to the need for determinism, reliability, and cross communication with legacy industrial networks. Therefore, the most common industrial Ethernet LAN faults include the following:

  1. Poor network design causing excessive bandwidth utilization and collisions
  2. Intermittent or faulty cabling, connectors, and switches
  3. Faulty network interface cards (NIC)
  4. Incomplete testing of new products to match standard protocols (i.e. bugs)
  5. Poor determinism from variable cycle time
  6. Environmental noise that creates corrupted data (errors)
  7. Incomplete or faulty fieldbus-to-Ethernet gateway
  8. Duplicate IP addresses
  9. Excessive loading of a network due to access of product with integrated web server
  10. Excessive loading of a network due to broadcast messaging
  11. Unauthorized access of PLCs
  12. Installation of the wrong product or wrong protocol version of the product.

None of the available Ethernet diagnostic tools solve all these maintenance problems. However an industrial protocol analyzer handles most issues. The different tools map out as solutions as follows:

Build It Right

Developers of new industrial Ethernet products have additional challenges. First they must test and debug their new products. They need to make sure that the product has its specified functionality and that it communicates according to the particular Ethernet protocol desired. Plus the developers must characterize product timing performance and latency variability. Minimizing this variability is key for determinism. Thus good product design requires accurately determining the cycle time for all commands and functions, its variability and minimizing both. The easiest way of achieving this is to use a protocol analyzer with microsecond or better timing resolution.

Truly Useful Tool

Woodhead Connectivity is now launching the first comprehensive industrial protocol analyzer under its NetAlert! network diagnostics brand. This PC-based NetAlert! analyzer adds industrial protocol decodes to a suite of the features found in top commercial protocol analyzers. The key diagnostics features found in the NetAlert! industrial Ethernet protocol analyzer include the following:

  • Captures up to Gigabyte data streams (limited only by RAM and hard drive size) without dropping any frames under typical conditions for 10/100 baseT rates.
  • Decodes multiple protocols simultaneously, such as Modbus-TCP, PCCC, DNP3, EtherNet/IP and others
  • Decodes two different data streams simultaneously, such as Ethernet and serial (option)
  • Displays only the data, protocols, errors or patterns of interest by selectively sorting, filtering, or searching
  • Multiple view-ports into same data set using the same or different filtering criteria - good for comparing two data frames.
  • Statistics on bandwidth utilization, errors, number of broadcast frames versus data frames, data frame size, lost frames and other.
  • Displays data in local language, ASCII, hexadecimal, and binary simultaneously in different panes. The unique binary display assists with bit-level debugging.
  • Identifies which nodes speak each different protocol
  • Tree displays on the protocol decode enables you to collapse or expand the protocol layer (Ethernet, IP, TCP/UDP, industrial application protocol) details to look at the portion of the protocol that you are focused on.
  • Validates the protocol in each packet. In the protocol language, the NetAlert! protocol analyzer has a Verify statement: if condition not met, then flag it. Then in summary display, flagged elements will show up in RED; in the detailed tree display, an ERROR branch will be added to tell which field is bad and what is wrong with it. For example, if a three bit field (0-7) had a valid range of 0-5, a value of 6 would create an error message.

Most importantly, the NetAlert! protocol analyzer can act as one common protocol analyzer with one common user interface for environments containing mixes of Ethernet and serial busses.

NetAlert! can optionally deliver serial in one window and Ethernet in an identical format window to simplify analysis. Some of the serial protocols supported today include Modbus RTU, Modbus ASCII, AB DH485, DF1, PCCC, DH+ (co-axial cable), DNP3, and COMLI.

These simultaneous decodes are critical to troubleshooting gateways. Many companies have invested millions in legacy fieldbusses or serial busses for the plant floor. Usually much effort and care went into getting all the bugs out of the original legacy installation. Gateways provide a key transition to industrial Ethernet adoption. The NetAlert! protocol analyzer allows view of both the legacy side of the gateway and the Ethernet side simultaneously. For example, if a Modbus serial network gets converted to a Modbus over Ethernet using a gateway, then the NetAlert! protocol analyzer can display the Modbus frames in one window and the Modbus-TCP frames in a second window. The NetAlert! analyzer allows you to compare commands. When an error appears on the Ethernet side but not on the Modbus side of the gateway, it becomes clear that the gateway creates the error for that command or protocol. So it narrows the problem down to both the source and the details. With NetAlert!, the filtering, comparison and decoding takes only minutes, not days.

With previous analyzers, you could only look at data in bits or Hex. Now you can view data and protocols simultaneously in binary, hexadecimal, ASCII and local language (e.g. English). Any errors get highlighted in all screens for easy correlation. This extended decoding saves hours in correcting fault sources.

The NetAlert! protocol analyzer supports open protocols and can be extended to decode custom or proprietary protocols. Custom protocol decoders are occasionally needed to handle equipment vendor proprietary networks. Another type of proprietary network consists of a legacy protocol overlaid onto new transport mechanisms. Many companies are now developing EtherNet/IP carrying CIP messaging while others are developing EtherNet/IP carrying PCCC messaging. PCCC messaging started as an A-B proprietary Ethernet using CSP for transport. Other examples include PCCC messaging carried inside DF1 transport and Modbus messages carried inside TCP transport.


In summary, to completely isolate and troubleshoot industrial plant floor network faults, you need a minimum of two tools: a cable tester and an industrial protocol analyzer. For troubleshooting, the protocol analyzer must have decodes for all protocols in your serial and Ethernet portfolio, deep capture buffers, and filtering on protocol elements and data values. For gateway troubleshooting, choose a protocol analyzer with dual simultaneous capture functions and display windows. For new product development, choose a protocol analyzer with simultaneous local language, ASCII, hexadecimal and binary displays with protocol violation traps.

Steve Montogomery is VP, NetAlert! Uptime Tools, at Woodhead Connectivity

Startside ] Opp ] [Søk]

Copyright © 2002 Øyvind Haugland
Sist endret:  13 januar 2019

  Interested in this stuff? Please write to:

HTML Counter            stats counter