Applying wireless to EtherNet/IP automation systems — Part 2

ProSoft Technology Inc
By Gary Enstad and Jim Ralston*
Sunday, 14 February, 2010


The ODVA EtherNet/IP network standard is gaining popularity as an industrial protocol, but while EtherNet/IP has many advantages, cable installation is often expensive and communications to remote sites or moving platforms may not be reliable or cost effective. Wireless ethernet technologies have emerged that can now reliably reduce network costs while improving plant production.

In Part 1 of this article we looked at the available wireless technologies that could be used with EtherNet/IP automation networks. In this part we look at what needs to be considered for running EtherNet/IP over a wireless network.

Designing wireless EtherNet/IP for reliability and performance

Many factors impact designing reliable wireless EtherNet/IP systems that will meet the performance requirements of automation systems. We have explored many of these factors in Part 1 of this article, but perhaps the most important consideration is selecting (and correctly implementing) the best technology for the automation network.

Industrial wireless applications can be divided into two broad categories: those requiring high-speed, low-latency performance and those permitting slower speed with longer packet latency. Wireless technologies are available to accommodate both.

A common error, though, is assuming that faster technologies are better. If the application can handle slower speeds, then using relatively slower frequency-hopping technology may be the best approach. Frequency hopping is the most robust technology, especially regarding communications in high RF noise areas, and is easier to implement. As applications demand higher speeds then more considerations and engineering challenges are typically encountered.

Wireless for explicit messaging between PLCs

One of the most popular uses of wireless is in sharing I/O information between PLCs. As previously discussed, EtherNet/IP explicit messaging uses TCP-based communication. Because these messages are unscheduled at the protocol layer, slower wireless ethernet technologies may be used. MSG blocks in PLC ladder code may be programmed to accept long delays in transmission. If the application (process) is not time critical, then a slower (but robust) frequency-hopping technology may be the best choice.

There are many factors influencing how fast an explicit MSG may be executed. Generally, applications requiring 200 ms response time or slower are a good candidate for FHSS. Faster response times may require faster technologies such as OFDM, available in the IEEE 802.11a and 802.11g standards.


Figure 1: Wireless TCP/IP system using explicit messaging for data exchange.

Wireless for HMI networks

Another popular application for wireless is connecting HMIs to plant networks or machines. HMIs use TCP communications and are not time critical other than to meet the needs of the process and, most importantly, the operator.

While HMI screens may look very complex and data intensive, usually the actual data being transmitted (updated) is minimal. The key consideration is update times and the amount of information actually being transmitted.

FHSS may be the best choice, if appropriate. However, if portable computers or PDAs are used, then the industrial wireless network must support the standard built into these portable devices. 802.11b and 802.11g (Wi-Fi) are the most common. This technology supports mobile operators while providing high-speed, low-latency communications.


Figure 2: Wireless TCP/IP system for HMI connectivity.

Remote SCADA systems

One of the most popular industrial uses of RF is for remote SCADA communications. Utilities extensively use remote SCADA networks where remote pump stations, tanks, substations and pipelines are controlled and monitored from a central site.

Wireless is a very good alternative to leasing phones lines for these purposes. The main challenge with remote SCADA is distance and terrain between the sites. Wireless technologies that support EtherNet/IP speeds require unobstructed line-of-sight (LOS) and adherence to the Fresnel zone for optimal performance. Analysing the terrain and LOS obstructions is vital in determining the feasibility of wireless EtherNet/IP. Fortunately, repeater sites are often available to achieve LOS and many FHSS radios have store-and-forward repeating capabilities.

Most EtherNet/IP SCADA systems do not require very fast communications, as explicit messaging is used to communicate from the remote PLCs back to the central plant. Frequency hopping is often the best choice here because FHSS offers the longest range due to excellent receiver sensitivity and support of the 900 MHz frequency band.

Bandwidth is limited in FHSS systems, so careful examination of network traffic is prudent. There is sometimes a temptation to add in other types of communication (such as VoIP, surveillance video, internet connectivity, etc) which will quickly exceed the capabilities of an FHSS wireless system.


Figure 3: Remote wireless SCADA system using EtherNet/IP with TCP/IP.

Wireless for ethernet I/O (implicit messaging)

An emerging application for wireless is communications to distributed I/O blocks using EtherNet/IP. Wireless offers many advantages in these applications, including elimination of mechanical coupling methods used in moving systems (such as rails or slip rings) and general cost savings due to the reduction of ethernet infrastructure.

Communication to EtherNet/IP I/O blocks can also reduce automation costs compared to using remote PLCs. Programming is simpler using I/O instead of remote PLCs because MSG blocks are not required in the main controller’s ladder program. But remember that implicit messaging is UDP based. Wireless networks must be carefully designed and the plant RF environment more closely managed to ensure reliable communications.

Several factors should be carefully considered before choosing this architecture, including:

  • The lack of remote PLC control (intelligence) in case of communication failure;
  • The amount of I/O and required scan times (network traffic);
  • The packet-handling ability of wireless technology;
  • The efficiency of the RF technology with multicast UDP packets;
  • 802.11 clear channel availability.

However if circumstances are right, wireless EtherNet/IP I/O can be a significant cost saver and actually improve system reliability when correctly implemented, especially in moving systems.

Predicting wireless I/O performance

The following information is provided only as a guideline for predicting wireless performance. Field testing is always recommended to confirm wireless performance and reliability.

Because EtherNet/IP I/O messages are scheduled, it is possible to predict scan time performance over industrial wireless systems if the following conditions are met:

  • Packets per second performance of wireless technology
  • Wireless behaviour in multipoint systems (handling of UDP multicasts)
  • Number of CIP connections

The first step in designing a wireless EtherNet/IP system is calculating the required packets per second, which determines the minimum wireless bandwidth requirements. Start by counting the number of CIP connections.

To calculate how many connections are in an I/O system, sum up all direct connections and rack optimised connections. To determine how many packets per second the system will be using, multiply each connection by two. It is multiplied by two because each CIP connection is bidirectional.

For example, if there are five direct connections and two rack-optimised connections (with six digital modules in each) then there are seven total CIP connections. The total number of packets is therefore 14 packets.

Note that the six modules in each rack that are rack optimised only count as one connection.

We then need to multiply the packets by the scan time (derived from the RPI setting) to calculate packets per second. Let’s assume that, in the above example, the required RPI time is 20 ms (actual RPI time is application dependent), then we know that there are 50 packets per second at an RPI time of 20 ms. We then multiply the 14 packets by the 50 packets per second to get the over all packets per second rate:

14 packets x 50 per second = 700 pps.

The overall packets per second rate for 802.11a/g radios can be in the thousands. However it is best practice to not operate the radio network at maximum capacity. For example, Rockwell Automation suggests reserving 10% of each adapter’s bandwidth so it is possible to use its RSLogix 5000 software for remote programming.

It is also suggested that 30% of the radio’s packet per second rate be reserved for RF overhead. In a congested RF environment, a radio contending for the RF medium will use valuable time if the radio determines the channel is busy by using its carrier sense mechanism. If the radios determine the medium is busy, the radio will not send any packets while it runs its back-off algorithm and then re-accesses the channel. All this accounts for time when the radio could be sending packets, but cannot. A radio network that is in a highly congested RF environment can easily use 10% of its packets sending RF retries. RF retries can occur if a packet is lost or corrupt due to poor signal-to-noise ratio, antenna placement or multipath fading problems. Point-to-multipoint systems also consume higher amounts of bandwidth. Selecting a clear channel is important in designing wireless EtherNet/IP I/O networks.

The next step is to determine a reliable packet per second rate that the wireless technology will reliably support, while keeping in mind that at least 40% should be reserved for other applications and RF overhead.

Impact of multicast UDP packets on 802.11 systems

As previously discussed, CIP packets are multicast over the ethernet network to accommodate multiple consumers. In wired systems, managed switches with IGMP querying are recommended to direct multicast UDP traffic to only the segments that need them. This ensures that high-speed I/O data does not reduce performance of the plant ethernet network, a major concern of IT managers.

Similarly, 802.11-based access points will rebroadcast multicast UDP packets to all active wireless clients. This represents a major problem, because the unnecessary broadcast of high-speed UDP packets will quickly clog an 802.11 channel, significantly reducing performance and even dropping UDP packets.

One way to correct this problem and optimise wireless performance is to invoke IGMP snooping and multicast packet filtering at the RF layer. By determining which devices are actually consuming the packets, the radio can build a consumption table and eliminate needless rebroadcasts. In point-to-multipoint systems, this feature can improve throughput by as much as 30% while significantly reducing dropped packets.

By applying multicast filtering to the 802.11 standards, it is possible to predict packet per second performance even in multipoint systems. For example, ProSoft Technology’s 802.11abg industrial hotspot has been determined to support 1800 packets per second. This equates to a little over 1000 packets per second available for EtherNet/IP CIP packets after subtracting 40% for RF overhead and other applications.

Table 1 shows how to calculate packets per second and highlights in green where an 802.11a or 802.11g wireless system may be used.


Table 1: Calculating packets per second (PPS = CIP connections x [1/RPI]).

Wireless I/O design steps summary

  1. Calculate the required packets per second for the application.
  2. Select wireless technology capable of meeting pps requirement (with 40% reserve capacity).
  3. Ensure good line-of-sight antenna placement.
  4. Select a clear channel - perhaps consider 802.11a 5 GHz band if the 2.47nbsp;GHz band is crowded.
  5. Utilise IGMP snooping/multicast filtering at the RF layer to optimise performance.
  6. Test system performance before commissioning.

Emerging wireless technologies

While this article focused on widely available FHSS and IEEE standards such as 802.11a and 802.11g, there are several wireless standards on the horizon that promise higher performance and connectivity options for EtherNet/IP networks.

IEEE 802.11n

802.11n promises several features that are attractive for EtherNet/IP communications, including dual band (2.4 GHz, 5 GHz) support, significantly faster packet transfer rates with a reported throughput up to 300 Mbps and RF propagation that actually takes advantage of reflected signals using multi-input, multi-output (MIMO) antenna systems.

IEEE 802.16 (WiMAX)

While popularly known as an emerging cellular technology, WiMAX technology will soon be available in the spread spectrum bands, including 2.4 GHz. WiMAX offers high speed (up to 70 Mbps) at potentially long range. WiMAX technologies may dramatically improve data rates to remote industrial sites and SCADA systems.

ISA100.11a

The ISA100.11a standard for wireless-enabled devices, such as sensors, operates in the 2.4 GHz band and the technology senses existing 802.11b/g systems and works around them. While designed primarily for embedded devices, EtherNet/IP adapters and gateways will likely be supported in the future.

* Gary Enstad has a BS in Electrical Engineering and has been involved in wireless design and technical support for over nine years. His current role is Wireless Application Development Engineer for ProSoft Technology.
Jim Ralston has been involved with the design and support of industrial wireless systems for over 12 years. He is currently the Northeast Regional Sales Manager for ProSoft Technology.

Prosoft Technology
www.prosoft-technology.com

 

Related Articles

Industrial wireless networks — comparing the standards: Part 2

In Part 1 of this article, we reviewed the history of wireless sensor networks (WSNs) and defined...

Industrial wireless networks - comparing the standards: Part 1

Today wireless instrumentation is becoming more commonplace in process plants and is a more...

Modernise and maintain: implementing wireless to monitor beyond the P&ID

Many operational and maintenance problems around a plant can be solved by deploying WirelessHART...


  • All content Copyright © 2024 Westwick-Farrow Pty Ltd