Over the years, I’ve stated that OPC UA flexibility is both a blessing and a curse. It’s a curse because there is a lot of thought that needs to go into implementing it. It’s not like Modbus. With Modbus, you can spend 10 minutes assigning registers and then go to implementation. With OPC UA, the choices are almost infinite starting with the profile you want to use (Nano, Micro, Micro Embedded, Standard), which security you implement and what transports you will support. Supporting everything that OPC UA offers is a support and maintenance headache.
Of course, on the other hand, OPC UA is a blessing. You can use it in any application to move any kind of data, from I/O to peer-peer applications to Cloud communications and Internet of Things (IoT) applications. There are few limitations, though I have cataloged some.
OPC UA Native Representation – Map the entire Modbus data space to objects in the OPC UA data space with registers and variables having descriptive names that make more sense to the application. You can read that article by clicking here.
Modbus Native Representation – Similar but simpler representation than the OPC UA Native representation.
Modbus Data Transport – A way to convert a Modbus device to an OPC UA device using OPC UA as a 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).
The last of these is a mechanism that I think will grow over time because it inherently lets the device live as a Modbus device. Essentially, in this mechanism, you tack an OPC UA Server onto the front end of the device, and though the device looks like an OPC UA server, it is really still a Modbus device. Here’s how that works.
In this kind of system, the OPC UA server doesn’t really function as an OPC UA server. It is simply a mechanism to make a secure and reliable connection between a Modbus Client and a Modbus Server. Modbus is an unsecured protocol and, in its serial implementation, performance bound. If you simply add an OPC UA Server to the front end of that serial Modbus device, you can transport those Modbus messages over a secure connection and do it faster and more reliably.
There are a number of ways to configure such a system. One way is to expose a single attribute in the OPC UA server. That attribute would be a string attribute that contains the entire Modbus message. A Modbus RTU Client device would use an OPC UA Client device to write the send attribute in the destination device and read back the receive attribute. Nothing changes for the Modbus devices except that messages are handed off to OPC UA instead of being put on a wire. This kind of implementation is pretty standard, and most OPC UA Clients and Servers could be configured to use it.
Another way is to build a data provider/manager to handle the Modbus message. This operates very similarly. Once a message is processed by the low level transport, security and everything else (OPC UA stack), the application services look at the attribute. The application service manager would notice that the namespace index points to a dedicated application process. That could be the standard Modbus application or an intermediary. In either case, it would work the same as processing a “Modbus attribute” described above.
The advantage to this sort of scenario is that Modbus devices can be converted to OPC UA without actually changing any of the internals of the Modbus device. It’s an easy way to convert from Modbus to UA without really converting your device.
To learn more about Modbus and OPC UA, head on over to another one of my blogs right here.