Using EtherNet/IP in process automation instead of fieldbus
EtherNet/IP takes advantage of Ethernet commercial technologies to surpass alternative solutions.
Since its invention in 1973, Ethernet has changed the world. It will continue to deliver the fastest data throughput, improve the architectures upon which it is delivered, evolve into varying electromechanical spectrums to meet the next industry trend, and penetrate down into the tiniest of microprocessors. Our world of process and factory automation is no exception to the ever-reaching technological advancements of this network.
Around 20 years ago, the process automation market had proprietary ways to meet the demands of remote I/O peer-to-peer communications. These approaches were successful and supportable, but users began to demand that their automation systems interface and share more data automatically with their front office systems over Ethernet.
Automation vendors began connecting their control systems via Ethernet, but there was no workable way to deploy device control requirements over a non-deterministic network infrastructure like Ethernet. As process users started to transition from traditional 4-20 mA analog devices and demanded digital device communications, fieldbus networks emerged to meet the demands that Ethernet couldn’t.
Today, Ethernet communication has overcome many of the disadvantages of previous years and established its presence in field device communications.
In factory automation, Ethernet-based networks are being used to connect robots, variable speed drives, and actuators to automation controllers. In the process control world, EtherNet/IP now connects flow meters, pressure instrumentation, and similar field devices to distributed control systems, programmable controllers, and hybrid programmable automation controllers (see Figure 1).
While there is no network panacea, EtherNet/IP has benefits that some fieldbus architectures cannot deliver. EtherNet/IP:
- Is easier to connect to a variety of host systems
- Can communicate with multiple hosts simultaneously
- Is instantly familiar to anyone with Ethernet experience
- Can use all available Ethernet tools and technologies
- Can use quality of service (QoS) to prioritize network traffic
- Can use simple network management protocol (SNMP) to monitor and manage the network
- Has more network topology options when switches are deployed
- Provides better support for wireless data transmission
- Provides better security through the use of standard Ethernet tools
- Offers economies of scale that promise future gains that are outpacing fieldbus.
This article explores these benefits.
Industrial Ethernet protocols
Within the Ethernet frame, one can place almost any application protocol. There is no one particular protocol that serves all the needs of industry. Instead, application protocols are like a tool chest, with users picking the ones that support the demands of their particular automation applications to provide the required performance, security, and safety.
The focus for this article is on EtherNet/IP, the industrial Ethernet protocol supported by the Open Device Vendor Association (ODVA). EtherNet/IP uses the standard Ethernet frame as defined by IEEE 802.3 and uses ODVA’s and ControlNet International’s Common Industrial Protocol (CIP) application protocol library of objects.
Figure 2 shows how the CIP application library can be deployed upon several different physical network architectures. This is a unique benefit to users because there are no physical application interfaces between the layers. This gives the CIP library almost seamless bridging and routing among different physical networks—both Ethernet-based and others, such as CAN-based networks.
Ethernet and EtherNet/IP
EtherNet/IP in the process industry is definitely a developing technology—unlike fieldbus, which has enjoyed 20 years of refinement. However, recent developments and technology breakthroughs are making EtherNet/IP a viable alternative to fieldbus.
Ethernet IEEE 802.3 can currently support data transmissions up to 10 Gbit/sec. Although EtherNet/IP-enabled devices deployed over the 802.3 standard currently support only 10/100 Mbit/sec transmission rates over copper and fiber, traffic through the network can still use the higher transmission rates if the network architecture supports it. And future variants of EtherNet/IP will advance along with Ethernet to support even higher transmission rates.
One advantage of EtherNet/IP is that it can support wireless transmission by using industry standard devices. When deploying EtherNet/IP over wireless, the user must consider how wireless system deployment creates latency in the EtherNet/IP message timing. Note that the same latency problems exist with wireless fieldbus, but without the advantages of the latest technological developments from the Ethernet wireless world.
Cabling distances depend on the 802.3 standard; i.e., 100 meters for device-to-device when deploying over copper and 2,000 meters when using fiber deployments. Power over Ethernet (PoE) is available so that power supplies may not be needed in the field. However, product availability varies by vendor.
Ethernet switches are also available for use in hazardous locations. Some switches use intrinsically safe PoE for connecting to field instruments in Zones 1 and 2. Unlike fieldbus, which can handle multiple devices in hazardous areas, one switch vendor recommends putting only one device on a single cable, which is becoming less of an expense as Ethernet switch prices rapidly decline. Again, product availability varies by vendor.
Typical Ethernet network topology is trunk-star. However, device manufactures are starting to embed micro Ethernet switches into their devices—allowing for linear and ring topologies—which reduce the need to create star network topologies. Redundancy can be achieved through the appropriate switch architecture and in some instances by adding a communication interface to allow a single fiber or copper port to be a node on a redundant ring infrastructure. In other words, it is possible to put multiple instruments and devices on the same cable and to provide redundancy when needed (see Figure 3).
Process instrument perspective
Looking at the EtherNet/IP protocol from the process instrument perspective, to whom and to what does an instrument have to report? The primary responsibility is to the automation or host system. Historically, this has involved the primary process variable. Secondary responsibility is instrument diagnostics, and last is instrument configuration data.
Each of the users or consumers of the data that the instrument produces has different tools and mechanisms to acquire the data. Each has its own unique requirements for the use of the data. Considering each of these areas—and how EtherNet/IP not only serves their unique requirements, but also creates commonality and convergence in the process—will help us understand how EtherNet/IP is not only a very capable fieldbus-type network, but also provides benefits beyond what typical-level fieldbuses deliver today and in the future.
Process variables: EtherNet/IP communicates process variables or I/O data back to the host system at a requested packet interval rate (RPI). This RPI is defined by the user. Typically, RPI is set based on application requirements. RPI rates for EtherNet/IP-enabled devices will vary based on the manufacturer of the device and the applications they serve.
Typical RPI times for process instruments, such as Coriolis and electromagnetic flow meters, on EtherNet/IP networks are from 5 msec to 10 sec. The device will communicate I/O data to the automation system at the RPI rate established when the device is configured in the system. This variability in selection of the RPI data rate enables the user to optimize the flow of I/O data through the process and optimize the data crunch through the microprocessors in the data chain without relying on the actual network bus rate or frame size specifications.
I/O data can also be provided simultaneously to multiple consumers (processors, devices, etc.) in the architecture. In addition to the primary process variable, multivariable devices, such as mass flow meters, can transmit multiple variables such as flow, volume, and temperature simultaneously, similar to traditional fieldbus architectures.
Configuration of what variables will be transmitted in the I/O data structure is typically determined by the manufacturer of the devices. Some manufacturers allow user configuration of the I/O data structure. Device vendors deploy device profiles that will interface with the automation system and define what these variables are.
If profiles are well defined, the process control engineer has very little work to do to get devices online and communicating data throughout the system. Typically, just verifying the actual device, revision of device, RPI, and the Ethernet address of the device is all that is required to get a device up and running.
See next page for more about diagnostics and additional graphics
Case Study Database
Get more exposure for your case study by uploading it to the Control Engineering case study database, where end-users can identify relevant solutions and explore what the experts are doing to effectively implement a variety of technology and productivity related projects.
These case studies provide examples of how knowledgeable solution providers have used technology, processes and people to create effective and successful implementations in real-world situations. Case studies can be completed by filling out a simple online form where you can outline the project title, abstract, and full story in 1500 words or less; upload photos, videos and a logo.
Click here to visit the Case Study Database and upload your case study.