Process Device Profiles Come to Life

Dawn Kelsch, Emerson
Michaël Voegel, Endress + Hauser Digital Solutions
Rizwan Mohammed, Honeywell
Winfried Ernst, KROHNE
Carsten Fuchs, KROHNE
Arnold Offner, Phoenix Contact
Carl Schumaker, Rockwell Automation
Vivek Hajarnavis, Rockwell Automation
Presented at the ODVA
2023 Industry Conference & 22nd Annual Meeting
October 18, 2023
El Vendrell, Spain
Abstract
The value of EtherNet/IP in the process industries is well recognized and is also a recommended
Ethernet-based standard that is specified in NAMUR NE168 in 2018. However, the adoption has faced anumber of challenges. A review of the state of the art was conducted in 2021 and identified areas such as
the standardization of diagnostics, the ability to deploy instrumentation in hazardous environments, theneed for long cables and the integration of legacy HART-based instrumentation into EtherNet/IPinstallations. Since then, some of these challenges have been addressed with vendors starting to bringnew functionality to the market.
This paper provides an update to the framework presented in 2022, with an emphasis on theenhancements that have taken place since the last ODVA Annual Meeting and Conference. It highlights
how recently published functionality has been realized in a multi-vendor environment. The focus is on ause-case in which an operator is informed of an error and able to take action, leading to resolution of theproblem through replacement of the instrument with an alternative from another supplier.

2023 ODVA Industry Conference

1©2023 ODVA, Inc.

A real-life scenario in a process plant
Isabelle, our instrumentation technician featured at the 2023 ODVA annual meeting, works in a large
plant experiencing the industry-wide shortage of skilled technicians. Edward, the instrumentationengineer, tries to have multiple sources of instrument suppliers for each device technology (Flow,Pressure, Temperature, Level) to keep the process running if a problem arises. This creates a lot ofextra work for Cassie, the control engineer, for device integration and configuration.
Friday, June 30th a nice summer day, Isabelle is starting her work after a shift change at the tank farm.
Everything points to a pleasant working day before the upcoming long weekend. Suddenly the calm isbroken by an annoying alarm, indicating that one of the flowmeters at tank 13 has stopped measuring.
Diagnostic information on the Asset Management display shows that measuring hasn't stopped due tomissing flow but due to a flowmeter malfunction. To get more information about the root cause of theproblem, Isabelle asks Edward, the instrument engineer, to look at the faulty flowmeter.
Edward determines that something has crashed into the flowmeter’s transmitter, the component of theflowmeter which is in charge of the communication. Fortunately, the pipe has not been damaged so theoil is still flowing into the tank and not onto the ground, but the flowmeter has to be replaced. Edwardinforms Isabelle about the situation and asks her if she can get a new device from stock for the exchange.
Looking at the stock inventory list, Isabelle finds out that there is one flowmeter left but its vendor isdifferent from the damaged one. Fortunately, it has the same device dimensions and should fit.
This story has two versions, one without the Process flow device profile (left column) and the other with a
Process flow device profile (right column).
Without the Process Flow Device ProfileA call to the vendor of the damaged device shows that
due to the upcoming long weekend, a replacement
device cannot be delivered before the end of nextweek. Since the tank farm is massively dependent ontank 13, the damaged device must be replaced as
quickly as possible. Therefore, Isabelle removes thedamaged device and replaces it with the one fromstock.
After Isabelle has finished replacing the device andmade the device connections correctly, the controller
was not able to receive measurement data, because
the data assemblies are completely different from theformer, damaged device. For this reason, the program
within the controller must be adapted to thecommunication structure of the new device.
Isabelle calls Cassie, the Control Engineer, to inform
her about the situation and to ask her to reprogram thecontroller. Cassie is understandably upset, but if shedoesn’t follow Isabelle’s request, the tank farm would
have to be taken offline for the long weekend.
This would result in financial loss and angry
management so there is no alternative solution; Cassie
must interrupt her long weekend break to get the plant
producing again.

With the Process Flow Device ProfileIsabelle had such a situation years ago and sheremembers that replacing a device by one of adifferent vendor resulted in lots of problems
reprogramming the controller. In addition,
Cassie is the only one who can change thecontrol program and she has already left for her
long weekend tour.
But wait! Last year Isabelle had an invitation tothe ODVA Annual Meeting and she remembersthat in a presentation someone introduced theProcess Device Profiles. That means, twodevices from different vendors supporting thesame Process Device Profile may beinterchanged without the need of adapting thecontrol program. From the controller’s point ofview, nothing has to be modified.
Cassie showed Isabelle how to do this sometime ago and it is quite easy. Hoping that thetwo devices support the same Process Device
Profile, she has a look at the device’s datasheets. Fortunately, both devices support theODVA-defined Flow Profile, so Isabelle removes
the damaged device and replaces it with theone from stock.
Even though the presenters from the ODVA
meeting last year were totally convinced that2023 ODVA Industry Conference2©2023 ODVA, Inc.

replacing one profile device by another is quite
easy, Isabelle is skeptical.
Isabelle starts some standard systems tests thatcheck the consistency of the plant’s control
program. And voilà: Each of the test pass; themeasurement values and the status are visuallyverified.
The story on the right side was showing that the Process Device Profiles are working, and they delivered
what was promised: easily replacing one device with another of a different vendor supporting the same
Process Device Profile. It saved a lot of money and more importantly: No one was angry due toemergency operations during personal time.
More than just another technical improvement, this story shows that devices with Process Device Profiles
also reduce stress in daily activities in the process industry.
Prerequisites for Ease-of-Use
Prior to the availability of networking technologies, connecting instrumentation to a control system wasstraightforward. The extensive use of 4-20mA transducers, and a single process value from an instrument
made it very easy to connect devices. Once configured, exchanging a device was very straightforward.
Whilst flexible, 4-20mA signals connected through I/O modules have limitations. Today’s more advanced
field devices include many diagnostic capabilities, error-reporting and a multitude of variables that can beused in more complex applications. However, each device works in its own way, making an exchangevery difficult. Engineering effort is needed to add or configure the replacement instrument in a fault
scenario.
The need for Standardization is therefore clear and needs to address the following areas:• Commissioning• Data exchange• Diagnostics• Compute Connectivity• SupportThe NAMUR NE 131 standard addresses some of these areas, and it follows that an instrument on
EtherNet/IP should also follow this standard.
Commissioning
Prior to the definition of Process Device profiles, DCS systems typically offered configuration methods
that were based on selecting the vendor of a device based on the presence of an EDS file, custom code,or other configuration mechanism such as a DTM or FDI package.

2023 ODVA Industry Conference

3©2023 ODVA, Inc.

Figure 1: Device Selection in Logix Designer
Figure 1 highlights the challenge of selecting a process instrument. Whilst it is clear that there is amechanism for achieving connectivity, it remains heavily vendor dependent. Devices of the same classhave different names and characteristics and it is not clear whether these devices are similar – nor can
one identify the differences. In addition, the functions that are visible in the DCS are a result of what has
been presented by the device vendor, or which is exposed by the supplier of the DCS. As aconsequence, every device looks different, complicating the configuration process. Furthermore, it limits
the ability to exchange a device with one from another vendor.
Data Exchange
After selecting a device, the DCS creates input, output and configuration data structures based on how
the DCS vendor chooses to present the data. In some cases, this is taking a structure that is provided in
the EDS file and creating tags that are in line with the information that has been provided in the EDS. In
other cases, this is achieved using custom code. Regardless of the mechanism used, the tag structuresthat are created are not consistent between vendors. Different devices will have different tag structures,making it difficult to identify the information needed. This in turn can make it challenging to identify theinformation needed for diagnostic purposes.
Configuring devices that do not have a pre-defined or standardized interface can also be difficult. Some
device vendors may choose not to implement an EtherNet/IP Configuration Assembly. Other vendors
may opt for their own design. In both cases, this adds an additional burden on the user who has tounderstand how to configure multiple devices by studying documentation and then to implement aconfiguration schema to meet the needs of their plant strategy.

2023 ODVA Industry Conference

4©2023 ODVA, Inc.

Diagnostics
A standardized method to ensure that device diagnostics are easily accessible, understood, and easy tomonitor is desirable. The simple traffic light system is used in the NAMUR NE107 standard to indicate thestatus of a device and aims to draw the attention of an operator when required. With the NE107
recommendations having broad adoption and acceptance across the industry, it makes sense for aprocess instrument on EtherNet/IP to align with this standard.

Figure 2: NE107 Icons
Compute Connectivity
A broadly accepted standard for interfacing devices to PC's, servers and the cloud is OPC-UA. This
includes the support for data models and defines a wide range of companion specifications for achieving
connectivity to a wide range of applications. The data model of interest to the Process industries is thePA-DIM model. It follows that any EtherNet/IP device that wishes to provide information outside the DCS
should include the ability to align with the constructs defined in this standard.
SupportThe variability that exists in terms of configuring and setting up devices today means that supportpersonnel have to have awareness of multiple techniques for diagnosing and solving problems. Thisscenario exists not just with CIP devices, but also with legacy technologies such as HART, Profibus andFoundation Fieldbus. A Process device profile therefore can simplify the learning process for amaintenance technician because he will have to learn and understand the capabilities of just one profile
per class of device.
The Process Device Profile to the rescue
The Process Device Profiles are a collection of CIP objects to standardize the data and services provided
for a process measurement. To date, Process Device Profiles have been published for Coriolis Flow,
Electromagnetic Flow, Vortex Flow, Standard Pressure and Scaled Pressure. Figure 1 is an example
object model for a Process Device Profile and will be described in the following paragraphs.

2023 ODVA Industry Conference

5©2023 ODVA, Inc.

Process Totalized
Value Object

Process
Measurement
Value Object

Assembly Object

Process Device
Diagnostics
ObjectMessage Router

Identity Object

File Object

Explicit
Msg.

I/O

Network Specific
Link Objects

Connection Manager orConnection Object

CIP NetworkFigure 1 - Example Process Device Profile Object Model

To support Process device profiles, two new objects were introduced in the April 2023 CIP specification:• The Process Measurement Value Object (Class Code 0x112) contains the measurement values
and status along with common configuration attributes such as engineering units, damping, cutoff
and zero point. The Process Measurement Value Object also allows for the measurement values
and status to be simulated. All Process Device Profiles will contain at least one instance of aProcess Measurement Value Object.
•The Process Totalized Value Object (Class Code 0x113) is a companion object that is associatedwith a Process Measurement Value instance and accumulates that measurement value to report
it as a total. The Process Totalized Value Object also provides attributes to start, stop and reset
the totalized value. Not all Process Device Profiles will contain an instance of a Process
Totalized Value Object.

Each Process Device Profile specifies which measurement and totalizer instances are to be supported
and what data is to be included in the input, output, and configuration assemblies. Because the CIP Spec
has created separate assembly number ranges for profile specific assemblies (ID 1-99) and vendor
specific assemblies (ID 100 – 199), there is no danger in the profile and vendor assembly numbers toconflict with each other.

2023 ODVA Industry Conference

6©2023 ODVA, Inc.

Each Process Device Profile also specifies which instances of the previously published Process Device
Diagnostics Object (Class Code 0x108) are to be supported. The supported instances were obtained
from the NE 107 guidelines. An improvement was made to the Process Device Diagnostics Object in theApril 2023 CIP specification that allows for the diagnostic instances to be simulated.
Each Process Device Profile specifies which Identity Object attributes are required to be supported toensure alignment with the device representation in PA-DIM. The Process Measurement Value Object
and the Process Totalized Value Object were also designed to be compatible with PA-DIM.
Each Process Device Profile may contain the File Object so that an end user can download the supported
EDS file(s) from the device.
Device Interchangeability
To achieve device interchangeability between vendors with ease of use in mind, a new Profile Vendor ID(0xFFFB) was introduced. A device that implements a Process Device Profile will accept a
Forward_Open service targeting the Profile Vendor ID or the manufacturer’s Vendor ID. This segregationof the two vendor IDs allows for the implementation of profile specific EDS files that are maintained by
ODVA and makes it clear to the end user that their system is only using profile specific features. This
gives the end user confidence that devices of the same profile can be interchanged.
With the addition of the new objects and Process Device Profiles, users can easily interchange devices
from different vendors and controller manufacturers can assist with the ease of use.
Conclusion - “pièce de résistance”
The definition of profile-based connection mechanisms simplifies the experience of the end-user.
At system design time, they can now choose an ODVA profile that provides standard connections anddiagnostics, or a vendor-defined implementation that allows additional capability specific to a vendor'sdevice.
All Profile EDS files will use the Profile Vendor ID. They will be created and maintained by ODVA in theProcess Industries SIG and should not be modified by vendors or users.
Both end users and vendors of controllers can benefit from the approach outlined in this paper. User
application logic should be easily re-usable, due to the use of identical data assemblies for each vendor’sdevice. Additionally, DCS/PLC suppliers can develop and provide to customers one set of user interfaces,such as for device configuration and HMI faceplates. These features will drastically reduce the timerequired by Control Systems Engineer Cassie during the system development phase.

References[1] ODVA, The CIP Networks Library, Volume 1: Common Industrial Protocol, PUB00001, Ann Arbor:ODVA, Inc., 2001-2023.
[2] OPC Foundation, OPC UA for Process Automation Devices – PA-DIM, Scottsdale: OPC Foundation,Inc., 2020-2023.
[3] NAMUR, Self-Monitoring and Diagnosis of Field Devices, NE 107, Leverkusen: NAMUR –Interessengemeninschaft Automatisierungstechnik der Prozessindustrie e.V., 2005-2023[4] NAMUR, Field Devices for standard applications, NE 131, Leverkusen: NAMUR –Interessengemeninschaft Automatisierungstechnik der Prozessindustrie e.V., 2009-2023******************************************************************************************************************************************************2023 ODVA Industry Conference

7©2023 ODVA, Inc.

The ideas, opinions, and recommendations expressed herein are intended to describe concepts of the author(s) for the possible useof ODVA technologies and do not reflect the ideas, opinions, and recommendation of ODVA per se. Because ODVA technologies
may be applied in many diverse situations and in conjunction with products and systems from multiple vendors, the reader andthose responsible for specifying ODVA networks must determine for themselves the suitability and the suitability of ideas, opinions,and recommendations expressed herein for intended use. Copyright ©2023 ODVA, Inc. All rights reserved. For permission toreproduce excerpts of this material, with appropriate attribution to the author(s), please contact ODVA on: TEL +1 734-975-8840
FAX +1 734-922-0027 EMAIL odva@odva.org WEB www.odva.org. CIP, Common Industrial Protocol, CIP Energy, CIP Motion, CIP
Safety, CIP Sync, CIP Security, CompoNet, ControlNet, DeviceNet, and EtherNet/IP are trademarks of ODVA, Inc. All othertrademarks are property of their respective owners.

2023 ODVA Industry Conference8©2023 ODVA, Inc.