ODVA Introduces Process Device Profiles, Aids With Diagnostic and Process Variables

ODVA (formerly Open DeviceNet Vendors Association) is an organization made up of companies that develop and maintain standards for industrial protocols such as Ethernet/IP, CIP, and distinctive CIP services.

Founded in 1995, ODVA was originally formed to develop the DeviceNet protocol. The companies that comprise the organization are manufacturers of products or software that utilize the supported protocols. By standardizing the communication protocol, development time is reduced for other companies, such as machine builders or automation engineers, who use the interface.

 

Standardizing protocols helps reduce errors and allows for interchangeability between devices in the field. Image used courtesy of Unsplash

 

Standardization

Today, Ethernet/IP is a popular industrial protocol used throughout the world to communicate with devices in the field. Every day, more automation devices are using Ethernet/IP, and some of these devices are very similar. By standardizing the communication profile for similar devices, the time required to integrate these devices can be greatly reduced. Standardizing also helps reduce errors and allows for interchangeability between devices in the field.

ODVA had developed a standard protocol for industrial communication and, just recently, announced the addition of process automation device profiles. By developing a common set of variables and values for similar devices used in process automation, commissioning time can be reduced, and integration into PLCs and DCS systems can be made easier.

 

Process device profiles will help scale device values to useful measurements that can be easily displayed on SCADA systems or sent to third-party analytic software. Image used courtesy of ODVA

 

Process Device Profiles

Process device profiles are a set of predefined variables that manufacturers can use to build the communication protocol for their devices. These profiles support standard devices such as different types of flow meters, pressure sensors, and scaled pressure devices. The profiles provide the user with process values such as current flow, pressure, level, and totalized values, along with common diagnostic values that can be easily accessed to troubleshoot issues with the device.

The profiles will help scale device values to useful measurements that can be easily displayed on SCADA systems or sent to third-party analytic software. Some of the values provided by the process device profiles can even aid in preventing plant shutdowns by supplying the necessary information for preventive maintenance algorithms. With the device profiles being a controlled standard, the end users will be able to utilize Ethernet-APL, which is becoming a popular infrastructure with process automation companies.

 

With standard profiles, engineers can develop standard interface codes for specific devices, thus saving time and not having to re-develop interfaces with each manufacturer. Image used courtesy of Unsplash

 

Process Automation Application

With so many different types of process automation devices that all support different protocols, it makes it difficult for machine builders or process automation engineers to develop a standard interface for devices.

For example, a Coriolis flow meter is a common device used to measure material flow. To get the measured value into a control system, users need to determine what fieldbus technology it is using. It could be serial, HART, analog, or even Ethernet TCP/IP. Once the value is in the PLC or DCS, users then need to scale the value into engineering units. This will again depend on the fieldbus protocol used and could be a simple calculation or a more complex algorithm.

 

Process Variable and Diagnostic Standardization

ODVA is developing a standard profile consisting of pre-determined values for particular devices. These profiles will share common scaled values and include diagnostic values. With these standard profiles, engineers can develop standard interface codes for specific devices, thus saving time and not having to re-develop interfaces with each manufacturer.