Using EtherNet/IP in process automation instead of fieldbus


Diagnostic data: Diagnostic data can be a very general term and is defined by the task that is being performed by the technician or operator requiring it. From the device perspective, the device can provide diagnostic data to the automation system, operations personnel, maintenance personnel, reliability personnel, and IT personnel, to name a few. 

Some of this diagnostic data can be included in the I/O data structure. For example, diagnostic data for a Coriolis flow meter includes empty pipe detection, sensor drift, sensor error, electronics error, inhomogeneous mixture error, ambient and process temperature errors, and other information. Whatever data are considered critical can be included in the I/O data during configuration. 

Figure 4: With EtherNet/IP, multiple devices can have access to an instrument’s process variable and diagnostic data including PLCs, PACs, DCSs, and HMIs. These devices can also access software running on PC workstations including asset management, ERP, mDevices also need to provide diagnostic data to technicians operating outside the control area and the automation system’s operator interface tools. One example is an electrical and instrumentation technician using device configuration software to reference the voltage delta between the measuring electrodes in an electromagnetic flow meter. With appropriate software, the technician can access the necessary data without interfering with process control operations. 

Devices on EtherNet/IP can also be polled by a condition monitoring system to determine if there are any diagnostic messages that need to be sent to maintenance personnel as an alert. An industrial PC equipped with asset management, maintenance, condition monitoring, or HMI/SCADA software can access all the I/O and diagnostic information it needs directly from the devices via the Ethernet interface (see Figure 4). With fieldbus, the same software has to access the information from the process historian or database in a DCS—at considerable extra cost. 

Most EtherNet/IP-enabled devices support SNMP. This enables IT technicians to monitor, troubleshoot, and administer network devices using standard network management tools. For example, suppose that IT is monitoring network traffic using an SNMP-enabled tool. The software tool reports that an EtherNet/IP device has exceeded its normalized packet transmission rate, and an e-mail alert is created and sent to a technician. The technician can then use the internal Web server of the device for troubleshooting. 

This leverages the investments a company has made in its IT support infrastructure, and minimizes the burden on the process control engineer from having to also be an IT support engineer. 

Fieldbus, on the other hand, requires detailed knowledge of the fieldbus architecture and cannot leverage a company’s IT infrastructure; the burden is still placed on the process control engineer to be a network expert. Fieldbus requires specialized training and knowledge, while EtherNet/IP is instantly familiar to process automation and other professionals who have worked with Ethernet. 

Figure 5: Two messaging connections—I/O data and explicit messaging (TCP and UDP)—allow an instrument to send regular I/O data to the automation system and simultaneously respond to data requests from condition monitoring or asset management software. CouEtherNet/IP has two main messaging connections: I/O data and explicit connections (see Figure 5). Explicit connections are messages that are not scheduled as with I/O data, but are delivered on demand. While the device is handling I/O data requests, it can simultaneously handle on-demand requests. Figure 5 illustrates the mechanism—UDP/TCP in the TCP/IP suite of Ethernet—to simultaneously deploy the I/O data and messaging data for the CIP library. 

These examples demonstrate a few of the various requirements of device diagnostic data and the varied locations to which these data are sent. The ability of Ethernet to allow this simultaneous collection of data from the devices is a key benefit. 

Compared to traditional fieldbuses, EtherNet/IP has minimal need to create additional configuration code in the host system. This reduces the footprint of the process configuration on the host. There is no need to have an additional software configuration package for the network or to add additional network interfaces, thus reducing hardware and software costs. 

Some of these benefits are derived from the mere use of Ethernet and cannot be wholly attributed to the EtherNet/IP protocol. However, implanting these functions often makes fieldbus installations expensive, cumbersome, difficult to support, and sometimes unappealing. Deploying an Ethernet-based protocol is thus useful in overcoming fieldbus difficulties and objections. 

Configuration data: Configuring and documenting a process device in an automation system can be a very time intensive task. EtherNet/IP gives users of these devices several options for configuration and documentation by giving them different access points and letting them use different tools to configure and maintain device configurations. 

Ethernet 802.3 provides a large data packet—up to 1,500 bytes—that opens up a large chunk of data in a frame, enabling device vendors to serve up more device attributes than can be communicated over typical fieldbus protocols. This configuration data for a process device is communicated at the I/O data level to the automation system. 

This gives the automation system access to the configuration parameters of a process device, allowing the user to determine which, if any, configuration parameters can be accessible to system programmers or operators at the operator workstations. This provides flexibility during start-up and commissioning for personnel to monitor or change parameters while working from within their system configuration programs. 

Using EtherNet/IP does not require all users to use the same set of tools. Most devices on Ethernet have a built-in Web server that gives users access to device parameters. This is useful for the IT technician who may not have access to, or training for, process control software or device configuration software tools. 

Because the Ethernet/IP protocol uses the standard OSI model, other toolsets become available, and can coexist and function synchronously throughout the architecture. 

Maintenance personnel also have at their disposal their own tools, such as asset configuration software and asset management software, for documentation and change management requirements. All this software can reach devices throughout the EtherNet/IP network. 

Network optimization

EtherNet/IP provides network access beyond the local area network (LAN) to a wide area network. I/O data can now traverse from one network to the other through standard IT hardware. This gives support personnel access from virtually anywhere in the world, allowing manufacturers and vendors to support their customers remotely.

It also provides segmentation and optimization of networks using tools that IT companies commonly provide to the marketplace. Traditional fieldbus implementations constrain data to their physical network; that data must be accessed through the host or a third-party communication interface. 

The volume of data on the network is increasing as users begin to merge their business/financial networks with the plant automation system network. This creates an ever increasing need to segregate, constrain, and secure the traffic so that it does not impact the data throughput of the automation networks. IT suppliers have been providing the hardware and tools to support these needs, and that technology is now employed on industrially hardened Ethernet-based devices. 

Some IT vendors are also providing switch diagnostic data as I/O data in the CIP library. This commercially available technology allows the engineer to segregate network traffic inside the common hardware appliances, allowing for even faster propagation of critical data inside the network topology. 

There will be some applications where a user may not be able to completely segregate or constrain the data to a virtual LAN or local subnet. The issue now becomes being able to compete for the data packets to be processed in the switches throughout the network. EtherNet/IP has identifiers in the CIP library to allow a switch, configured for QoS, to prioritize these packets over the voice, data, and media packets on the network. Being able to perform these QoS tasks within the network provides the best optimization of the network for the automation network data. 

Security is a wide and deep topic and is not addressed in this article, other than to note that EtherNet/IP is able to leverage all of the commercially available security features that are delivered in the IT market today for Ethernet-based networks. There are several publicly available documents for securing converged networks, and the ODVA website has a publication that discusses securing Ethernet networks. 

Looking ahead

Ethernet has been the dominant commercial network for the past 40 years, and will continue to be in the future. As the convergence of the plant floor to the front office continues its progress, leveraging this future in automation devices will be essential. Process devices will get more intelligent—the past and present demonstrate this. A process device will have a lot of information to share, and will need ever more network capacity and capabilities. 

EtherNet/IP will meet these needs by leveraging Ethernet advances, taking advantage of Ethernet’s huge economies of scale. More Ethernet nodes will be connected this—or any other—month than have been connected in the entire history of fieldbus. This economy of scale and the tremendous technological advancements that go along with it is what makes EtherNet/IP more capable than a fieldbus network, now and especially in the future.

Michael Robinson is director of solutions for the Endress+Hauser Sales Center, US. He has 18 years of experience in factory and process automation as a project engineer, product manager, and business development manager. Robinson has a BS in agricultural engineering technology from California Polytechnic State University, San Luis Obispo, Calif.

This article appears in the Applied Automation supplement for Control Engineering and Plant Engineering

<< 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