Using EtherNet/IP in process automation instead of fieldbus

EtherNet/IP takes advantage of Ethernet commercial technologies to surpass alternative solutions.


Figure 1: Process instrumentation with EtherNet/IP connections, such as the Coriolis flow meter shown in the photo, is becoming more common as users realize the benefits. Courtesy: Endress+HauserSince 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. 

Figure 2: The upper half of this diagram shows the CIP application library in blue and red, while the lower half shows various physical network architectures. The Ethernet physical architecture is shown in green. Courtesy: ODVAThe 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. 

Figure 3: The photo shows part of a process plant making hypoallergenic baby food using instrumentation, controllers, and industrial managed switches on a single EtherNet/IP network. Courtesy: Endress+HauserTypical 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

<< First < Previous 1 2 Next > Last >>

Rod , United States, 10/12/13 04:21 PM:

Thank you for this information. I really like your articles and website.

PERRY , NJ, UNITED STATES, 10/13/13 09:08 AM:

Thank you for another great article. Can't wait to hear more About OPC
Anonymous , 10/13/13 11:51 AM:

I agree Ethernet and IP are awesome technologies. Ethernet and IP have taken the place of proprietary DCS control networks (at level 2 in the Purdue reference model) as well of the MES (level 3) and business (level 4) networks. It makes these networks easier to manage.

I also agree that Ethernet is making major inroads to the remote-I/O networks (level 1-1/2 in the Purdue model).

I also agree process plants have started to transition from 4-20 mA (and on/off) devices (at level 1 of the Purdue reference model) to digital device communications.

So the real question is; will sensors/transmitters and positioners/actuators/valves use Ethernet instead of hardwired 4-20 mA and on/off signals as most of them do today?

The article refers to “fieldbus” but misses the very important point that there are two distinct fieldbuses in plant architecture:
- H2 fieldbus: at level 1-1/2 of the Purdue reference model, connecting remote-I/O, PLCs, MCC, variable speed drives, motor starters, and wireless gateways to the DCS; including e.g. DeviceNet, Modbus/RTU, and PROFIBUS-DP
- H1 fieldbus: at level 1 of the Purdue reference model, connecting sensors/transmitters and positioners/actuators/valves to the DCS; including FOUNDATION fieldbus H1, PROFIBUS-PA, CompoNet, ASI, IO-link, and to some extent HART – these are taking the place of 4-20 mA and on/off signals

Because H1 and H2 are distinctly different in many ways, they should not be lumped together.

Ethernet is making inroads at level 1-1/2 of the Purdue reference model, with EtherNet/IP, Modbus/TCP, PROFINET sometimes being used in applications which previously used DeviceNet, Modbus/RTU, or PROFIBUS-DP.

I hardly see any Ethernet used in field instruments.

I agree with using Ethernet to connect variable speed drives and other MCC equipment like motor starters as well as PLC to the DCS, but these equipment aren’t really in the field. I know there are magnetic flowmeters and Coriolis flowmeters using Ethernet, because these are separately powered devices, but I have not seen any pressure, temperature, level, vortex flow, interface level, pH, conductivity, or DO2 transmitter or control valve positioner or on/off valve using Ethernet, because these are generally two-wire loop powered devices. Sensors, actuators, and other field instruments traditionally use 4-20 mA and on/off signals, and I don’t see Ethernet in its present form ready to take the place of 4-20 mA and on/off signals.

Indeed Ethernet has some benefits, but Ethernet also has its limitations, which prohibits it from taking the place of 4-20 mA and on/off signals:
• Copper Ethernet is too short distance
• Fiber optic Ethernet provides no power
• Intrinsically safe Power over Ethernet (PoE) has not been standardized (i.e. entity parameters are not compatible between manufacturers for plug-‘n’-play interoperability)
• There are thousands of transmitters and valves in a plant so the number of LAN switches mounted in field junction boxes would be in the hundreds
• Fiber optic Ethernet makes device removal/connection for replacement and calibration etc. difficult
• TCP/IP requires IT department involvement for cyber security
• Redundant power of field UPS must be provided to the LAN switches in the field junction boxes
• LAN switches are active components that generate heat in enclosed field junction boxes; MTBF concern
• Copper to fiber media converters may have ambient temperature limitations
• Etc.

For this reason I see it as difficult for Ethernet to take the place of 4-20 mA and on/off signals.

I personally believe that to move forward indeed we do need some form of all-digital real-time networking from the very “first meter” starting from sensors and actuators. So what do we do?

Is Ethernet the only digital communication network we use in the office and home today? The answer of course is; no. Our mouse, keyboard, smart phone, digital camera, video camera, backup drive, memory stick and many other things use USB because Ethernet is not the best fit for these devices. Ethernet and USB complement each other.

Similarly, Ethernet is not the best fit for field instruments in process applications. Personally I see some H1 fieldbus protocol (not any of the H2 fieldbuses) as the best candidate to take the place of 4-20 mA and on/off signals. The key attributes of fieldbus which enables it to be used in place of 4-20 mA and on/off signals include:
• Fieldbus covers long distance
• Provides bus power
• Is intrinsically safe with standardized entity parameters enabling and device to connect to any barrier
• Simple low cost coupler in the field junction boxes enables thousands of devices to be deployed at low cost
• Easy device disconnection/connection for replacement and calibration etc.
• Requires no IT department involvement
• No separate power required to the field junction boxes
• Passive coupler generates no heat and is sealed for long MTBF
• No media converters required
• Etc.

I personally believe these important characteristics make an H1 fieldbus the ideal candidate to take the place of 4-20 mA and on/off signals in a digital plant. Indeed FOUNDATION fieldbus is used in some of the largest refineries, petrochemical complexes, chemical plants, LNG processing plants, and FLNG vessels in the world for this reason.

Ethernet and H1 fieldbus has some characteristics which are mutually exclusive; therefore H1 fieldbus and Ethernet complement each other; just like Ethernet and USB in the home and office.

For instance, EtherNet/IP does not take the place of CompoNet. Indeed CompoNet was conceived long after EtherNet/IP to fill the gap left by EtherNet/IP and DeviceNet to achieve digital from the very “first meter”. Similarly PROFINET does not take the place of IO-link. IO-link was conceived long after PROFINET to fill the gap left by PROFINET and PROFIBUS.

From what I have heard, there are about three different Ethernet LAN switches available with intrinsically safe PoE. However, it appears they all have different entity parameters (I, U, P, C, and L) so it would be hard for device manufacturers to create intrinsically safe Ethernet devices that would work with all of them. What is needed is for IEC to standardize the entity parameters such that any device works with any barrier – just like what was done for FISCO for H1 fieldbus. Only then would intrinsically safe Ethernet be viable, and prices could drop. This could possibly make intrinsically safe Ethernet a possible alternative to 4-20 mA and on/off signals.

Just to be clear, fieldbus devices also deliver process variables and I/O at the requested interval, as fast as 150 ms or even faster so it is not unique to Ethernet. FOUNDATION fieldbus also provide multiple I/O data simultaneously to multiple subscribers. Device profile are used by both FOUNDATION fieldbus and PROFIBUS-PA

It is true that intelligent device management (IDM) software part of an asset management system (AMS) does communicate with the fieldbus devices through the DCS, although it is directly through the DCS interface cards not through the database or historian. Also note that the DCS needs these interface cards anyway for control and monitoring, so the interfaces are not an additional cost to access diagnostics. Also remember that Ethernet devices do not connect directly to the DCS control network even though the DCS control network is also Ethernet. Instead Ethernet devices connect to an Ethernet interface card in the DCS backplane where the data is mapped from whatever Ethernet protocol such as Modbus/TCP, PROFINET, EtherNet/IP, or FF-HSE etc. to the DCS database. Learn more about device diagnostics and intelligent device management software (IDM) architectures from the white paper and guideline found here:

Involving an IT technician or IT support engineer for field instrument signals may not necessarily be an advantage. Indeed I believe having to involve IT could be seen as a disadvantage by many instrument technicians. Every other month I see articles about the differences between IT and I&C with respect to cyber security philosophy etc. One refinery also pointed out to me that the IT department is 8/5 whereas the I&C department is 24/7.

Fieldbus technologies have now matured to a level where instrument technicians do not need be a network expert. For example, the Emerson DeltaV control system automatically detects and commission devices without the need for the technician to touch the system; they can do it using nothing but a screwdriver. Similarly the technician can replace a device without touching the system, using only a screwdriver.

While Ethernet and IP may be instantly familiar to process automation and IT professionals, these are not the guys replacing field instruments which have failed or need to be taken in for service, or commission them in a new plant being constructed. Field instruments are handled by technicians, and IP address, MAC address, subnet mask, gateway, and DHCP may not be familiar to them. You cannot send the IT guys into the field. IGMP snooping may not even be familiar to your average office IT professional.

Another clarification; FOUNDATION fieldbus does not require any code to be written in the DCS. It is entirely tag based, just point and click to the data in the device you need. They call it virtual marshalling:

All DCS today have Ethernet control networks, but no DCS permits you to connect third-party devices direct to the DCS control network. The DCS uses an Ethernet interface card which acts as a firewall and as a gateway to convert the various protocols to native DCS I/O points.

I do not agree “fieldbus installations expensive, cumbersome, difficult to support, and sometimes unappealing”. The per-signal cost of fieldbus is lower than for 4-20 mA and on/off signals. It doesn’t matter if the signal is fieldbus or Ethernet; both are different from 4-20 mA and on/off signals. Some technicians only want to use the multimeter; not a computer. Relcom has created a simple and easy to use fieldbus tester (FBT-6) which looks and feels like a multimeter which is well accepted by technicians. Something similar would have to be created to troubleshoot Ethernet – not everybody likes a laptop even though it has a powerful user interface.

The packet size doesn’t matter. If somebody retrieves lots of data from a fieldbus device it is simply sent in multiple packages. Any fieldbus gives access to all the information in the device. Size doesn’t matter.

In the home and business world Ethernet is not taking the place of USB, because Ethernet is not a the best fit for the “first meter” from the mouse and keyboard. Similarly I do not expect Ethernet to take the place of H1 fieldbus in process control applications, because Ethernet is not the best fit for the “first meter” from sensors and actuators.

Don’t get me wrong, I personally believe that the future is digital, and I welcome solutions that can take the industry beyond the limitations of 4-20 mA and on/off signals towards digital communication, including Ethernet if the necessary tweaks can be achieved.

Jonas Berge
Wilfried , United States, 10/17/13 09:24 AM:

Enjoyed reading the article, but I missed some critical insights. It is fair to state that, in the field of all Industrial Ethernet solutions, Ethernet/IP faces the greatest challenges when it comes to hard real-time control. See my article at
Anonymous , 11/21/13 10:59 AM:

I would like to see additional information about deploying Ethernet into electrically classified areas.
R , , 11/26/13 11:50 PM:

Yes this is a wonderful progress. Ethernet will definitely have a lot of advantages over Fieldbus. With more number of devices being connected over the network, network redundancy and determinism would be some points which need to be looked at.
click me