Essentially, OPC UA “wraps” the Modbus message. 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).
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. Not as nice for the OPC UA Client device, but adequate and quicker to do. And just like the previous mechanism, a client uses UA Read and UA Write requests to access the new data space. 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. We map each register and coil by the current register and coil number and don’t add any meta data. Instead of building an entire OPC UA address space, we have a single object with Modbus registers and coils as attributes. Modbus Native Representation – This is similar to the previous representation but simpler. Unfortunately, this sort of conversion requires the most development. In this mechanism, the client uses standard UA Read and UA Write requests to access the OPC UA data space. 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. 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. The registers and variables are given descriptive names that make more sense to the application. 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. OPC UA Native Representation – In this approach, the entire Modbus data space is remapped as objects. There are several approaches to that, and each one has its advantages and disadvantages:
OPC MODBUS SERVER HOW TO
The more significant question is how to represent the registers and coils of the Modbus device in OPC UA. Modbus devices are generally RS485, and OPC UA devices are Ethernet, so there has to be some hardware conversion: new processor, gateway, daughter card, etc. 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. OPC UA is one of the better ways for these Modbus devices to send data that integrates in the typical Ethernet automation architecture.
It can be a nightmare to configure these systems to do that. 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. They are expensive, complex, and require continual maintenance. The ways to do that are currently very inadequate. But to do that, that data needs to be moved to an information system in the Cloud. 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. 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. Many of them have less than ten data bytes. And most of these devices aren’t handling a lot of data. There probably isn’t a facility in the world that doesn’t have some Modbus device handling data.
OPC MODBUS SERVER WINDOWS
Fastwel Modbus OPC Server is a Windows application providing OPC Data Access interface for Modbus RTU/ASCII and Modbus TCP networks.
0 kommentar(er)
