Modbus and OPC UA – How do we make that marriage work?

Tens of millions of Modbus devices have been shipped all over the world. There probably isn’t a facility in the world that doesn’t have some Modbus device handling data. And most of these devices aren’t handling a lot of data. Many of them have less than ten data bytes.

We live in an age where data and information are critical to providing the efficiencies that allow a factory to compete in a global economy. In a lot of cases, it is no longer acceptable to have a Modbus device holding data that could be combined with other data to provide insight into a manufacturing process. But to do that, that data needs to be moved to an information system in the cloud.

The ways to do that are currently very inadequate. They are expensive, complex, and require continual maintenance. One of the problems is that these systems have to provide the mapping from the native Modbus register and coil format to some other format that is more compatible with cloud-based systems. It can be a nightmare to configure these systems to do that.

OPC UA is one of the better ways for these Modbus devices to send data that integrates in the typical Ethernet automation architecture. In this article I am going to discuss some of the ways to make Modbus data available as OPC UA data, but I am not going to discuss the hardware issues of making a Modbus device an OPC UA device. Modbus devices are generally RS-485, and OPC UA devices are Ethernet, so there has to be some hardware conversion: new processor, gateway, daughter card, etc. I’ll leave that for another time.

The more significant question is how to represent the registers and coils of the Modbus device in OPC UA. There are several approaches to that, and each one has its advantages and disadvantages.

OPC UA Native Representation In this approach, the entire Modbus data space is remapped as objects. Each Modbus register and coil is represented as a variable attribute in the OPC UA data space using one of the OPC UA standard data types. The registers and variables are given descriptive names that make more sense to the application. Register 40100 becomes “core temperature” and coil 10200 becomes “valve on.” This representation provides the most flexibility and information to OPC UA clients as the new OPC UA variables can have meta data attached to them. Meta data attributes can include data type, last update, maximum value, minimum value, and an unlimited amount of other data about the register and coil. In this mechanism, the client uses standard UA read and UA write requests to access the OPC UA data space. Unfortunately, this sort of conversion requires the most development.

Modbus Native Representation This is similar to the previous representation but simpler. Instead of building an entire OPC UA address space, we have a single object with Modbus registers and coils as attributes. We map each register and coil by the current register and coil number and don’t add any meta data. So, register 40100 becomes an OPC UA variable type attribute named “40100.” We map every register and coil used in the application in this fashion. And just like the previous mechanism, a client uses UA read and UA write requests to access the new data space. Not as nice for the OPC UA client device, but adequate and quicker to do.

Modbus Data Transport Another way to convert a Modbus device to an OPC UA device is to simply use OPC UA as a data transport. Instead of a client using OPC UA read and write attribute functionality to read an OPC UA address space, the actual Modbus message packet is sent across the network embedded in the OPC UA transport (whichever one is used). Essentially, OPC UA wraps the Modbus message. By wrapping the standard Modbus message, OPC UA adds standard encoding and a security layer to make the transmission more secure and reliable. This is usually a good first step and the kind of functionality that a Modbus gateway can provide.

This requires that the OPC UA server recognizes that the content of a message is not a standard read or write of OPC UA attributes but is actually a Modbus message. Not many OPC UA applications are able to do this.

Getting the millions of Modbus devices OPC UA-enabled is a tall order, but it is something that we will have to work on as we move forward.