PLC connectivity towards superior systems is important for remote monitoring or control, but also for integration into applications that are used for production control or planning. One of the popular communication interfaces is OPC (Object Linking and Embedding for Process Control). This is mainly used in industry - OPC servers are provided by practically all manufacturers of industrial programmable automata. The OPC client communicates with the OPC server, which is usually a visualization program, a database connector or other software for evaluating process data. The OPC interface thus represents a "neutral" layer that quickly and easily connects sources and consumers of data from different manufacturers without the need to write communication drivers for each combination of client and server.
The OPC standard has historically taken two forms: OPC DA and OPC UA. OPC DA (OPC Data Access) is an original concept that is built on Microsoft's DCOM data model. It uses Windows OS technology, so it is dependent on this platform, and if the OPC server and client run on different computers, it is necessary to set mutual access rights in a complicated manner. However, it is a classic solution that is available in many visualization programs and, especially for older systems, OPC DA is offered as the only option.
OPC UA (OPC Unified Architecture) uses a binary protocol (opc.tcp://) or a web service (http://) for data transfer. It is a platform-independent standard, preferred today.
The OPC server is also available for PLC Domat. It supports both OPC DA and OPC UA and is therefore suitable for integrating PLCs into older visualization or control systems that cannot use OPC UA. The required standards are selected during installation.
When programming a PLC, we can mark each variable as Writable in OPC Export and further enable its export for the respective PLC (it could happen that the same program is used in several PLCs - and it is therefore necessary to determine for which PLC in the report the variable is to OPC server export). It is unnecessary to offer all variables in the PLC in the OPC server, it reduces clarity and poses a security risk.
For OPC DA, it is recommended to run the OPC server on the same computer on which the OPC client is running, so that it is not necessary to solve the access rights settings in the Windows DCOM model. The topology then looks like this:
The function of the OPC server can be easily verified using one of the freely available clients, e.g. Matrikon OPC Explorer:
In the case of OPC UA, the situation is more interesting, because in order to access the service, it is necessary to know the TCP port in addition to the server address. The default is 4840. If this number is used by another third-party OPC server, a different TCP port number can be selected when installing the server. The advantage is that both the OPC client and the OPC server can run on different machines without problems, it is only necessary to check and possibly enable the firewall for the respective port on the computer with the server.
After the server is configured (see Domat IDE Help), we can verify that the service is up and running:
To check on which TCP port the OPC server listens, we list the occupied ports with the netstat -aon command and check which port the process with the OPC server's PID (here 6816) occupied:
We see that the OPC UA server here is listening on TCP port 60000. This value was selected during installation and must also be entered in the OPC server address parameter in the OPC client program:
Checking the function using a generic OPC client is a good help: it will show whether any problems are on the OPC server or OPC client side (visualization).
The OPC server is software supplied free of charge, and therefore represents a simple and low-cost way to make process data from Domat substations available to foreign systems - both from the point of view of investment and in terms of engineering complexity. Just for the record, we remind you that other options for sharing data with superior systems are Modbus RTU or TCP server, BACnet server, or web API. For tighter integration, we provide an SDK to implement the native SSCP protocol or its full description. In case of any questions, contact our technical support, support@domat.cz.
