With the rise of industrial fieldbus technologies during the early to middle 1990s, one of the key benefits realized was the simplification of machine wiring. Devices were most commonly organized into a linear topology with status, control, and diagnostics communicated between device and machine controller. They moved along a single cable, making troubleshooting and maintenance a much simpler process.
Many of the controllers that supported fieldbus implementations either supported, or began supporting, Ethernet. With Ethernet being viewed as an information-only network at the time, these interfaces were limited in their use. Typically Ethernet was used for machine visualization using HMI connectivity, and PC connectivity for programming and troubleshooting.
Towards the end of the 20th century and into the early years of the 21st century, this began to change as industrial network organizations and controls vendors started to develop ways in which Ethernet could be used for machine control and information. This led to the development of control-optimized industrial Ethernet protocols such as EtherNet/IP™, PROFINET®, EtherCAT®, Ethernet POWERLINK®, CC-Link IE® and Modbus TCP.
With the increased use of Industrial Ethernet, one of the questions that need to be discussed is how to best address network topology. Ethernet can support a wide variety of network topologies, with star topology being the most commonly used variant. This works well for plant applications but can pose challenges down at the machine level when networked devices are distributed across the machine.
Multiple physical connections propagating from a central switch adds cost, creates a potentially catastrophic single point of failure, and defeats the original intention of using machine networks to simplify cabling and maintenance.
To simplify networks and maintain high availability, organizations have developed linear and star topologies into their standards to better support the needs of the machine builder. In the first part of our Industrial Ethernet Rings series we will discuss the use of Device Level Ring in conjunction with EtherNet/IP™.
Device Level Ring (DLR) enables the use of ring topologies on EtherNet/IP networks and has built-in mechanisms for media redundancy, network fault detection, and network fault resolution. As with star topologies, these networks still use switched Ethernet.
However, it is common for two-port switches to be embedded into the individual network devices themselves. These embedded switches allow for messages to be passed along ports and enable the construction of the physical ring.
On a network consisting entirely of DLR devices, there are two types of devices: ring supervisors and ring nodes. There must be one active ring supervisor on the network, though it is considered best practice to have at least one backup ring supervisor as well.
A straightforward way to think of the ring supervisor is that it serves as the traffic cop of the network. It sends out special-purpose frames to determine the status of the network and sends out additional frames to reconfigure the network in the event of a device failure or break in physical media.
As previously stated, it is best practice to have another device on the network acting as a backup ring supervisor. While in a backup state, this device behaves like other ring nodes on the network. In networks with multiple ring supervisors, the active supervisor is determined by the precedence assigned to the device through an attribute in an EtherNet/IP DLR Object. The device with the highest precedence acts as the active ring supervisor and if two ring supervisors share the same precedence, the device with the highest numerical MAC ID becomes the active ring supervisor.
The remaining participants on the network are the ring nodes and consist of two types: beacon-based and announce-based. The terms beacon-based and announce-based indicate the type of frames a device can generate, process or respond to.
Ring nodes that support beacon frames are capable of being active participants in maintaining the network. They are capable of actively reporting faults to the ring supervisor and conducting checks on neighboring nodes. This provides an additional layer of error checking as the supervisor does not have to wait for its beacon frames to traverse the entire network before determining fault states.
It ultimately leads to faster recovery times as a network of 50 nodes, configured to default beacon settings, can recover within 3 ms. With a typical high-performance connection having an RPI (Requested Packet Interval) of 1 ms and connection timeout of 4 ms, this means that the network will recover before there is a connection timeout.
Ring nodes that support announce frames, due to performance limitations, cannot process beacon frames but must be able to pass them along. They lack the additional diagnostic support but can receive status messages from the ring supervisor and network reconfiguration instructions. Due to the slower propagation of announce frames, recovery times are slower with a 4ms recovery time for a 50-node ring.
During a normal operation with no loss of connectivity, as shown in Figure 2, the active ring supervisor issues beacon frames from both of its ports at a specific interval. The default interval for beacon-based devices is 400 µs, though this interval may be configured as low as 100 µs.
Additionally, the ring supervisor issues announce frames out of a single port at a much slower rate, with a normal interval of 1s. These frames are then processed, or simply passed along, by the ring nodes depending on which capabilities they natively support.
Additionally, the ring supervisor blocks normal data traffic on its second port, save for some specific network status frames, and does not pass normal traffic across this port. This is done to prevent the formation of an infinite network loop where messages would traverse infinitely and flood the network with traffic.
In the event of a lost node connection, as shown in figure 3, or a break in the physical media, the ring supervisor opens its second port to data traffic, reconfigures the network through a beacon, and announces messages issued through each port. This has the effect of “healing” the network and creating a single line topology until the device recovers or the cable is replaced.
In closing, it makes sense to comment briefly on implementing networks with DLR and non-DLR nodes. It is possible to connect non-DLR nodes into a DLR network, but special requirements must be met. See the DLR specification for more detail. Also, there are special 3-port adapter devices (Etap) that allow single-port devices to attach to the network.
Additionally, it is important to deploy devices on the network correctly. A recommended best practice is that non-DLR nodes should be deployed between DLR nodes, and not clustered, to facilitate detection of network faults. This is shown in Figure 4.