Software architecture

Previous versions of the TwinCAT OPC UA Client (versions 1.x.x) consisted of several components that were closely interlinked. These were:

• A process in the operating system (TcOpcUaClient.exe)
• A communication driver in real-time (TcIoOpcUa.sys)
• An extension for the TwinCAT XAE

The interaction of these components is illustrated in the following diagram:

Process in the operating system

The process in the operating system (TcOpcUaClient.exe) takes care of the OPC UA protocol functions and makes them available via an ADS server so that the TwinCAT real-time components (e.g. the driver or the PLC library) can access them.

Communication driver in real-time

The driver in real-time is responsible for the communication of the I/O device with the process in the operating system. It converts the configured process data into ADS telegrams, which are exchanged with the process in order to be converted into OPC UA commands. There is an engineering component in TwinCAT XAE for the configuration of the communication connection and the choice of data points.

TwinCAT XAE Extension

The engineering component in TwinCAT XAE provides a graphical configuration interface for the I/O device. This means that variables can be read from OPC UA servers and added to the process image so that they can be processed later at runtime.

PLC library

The PLC library provides the OPC UA functions of the process in the operating system for the PLC logic. Similar to the driver, the PLC library communicates with the process via ADS in order to access the OPC UA functions.

TwinCAT OPC UA Client as of version 2.x.x

Newer versions of the TwinCAT OPC UA Client only consist of an engineering component and a runtime component (the so-called "driver"). The process in the operating system (TcOpcUaClient.exe) is omitted.

The driver provides the complete OPC UA communication stack, which is then used by both the engineering and TwinCAT runtime. This not only reduces complexity, but also enables the use of a standardized and centralized communication connection with the server. The engineering no longer establishes its own communication connection with the OPC UA server, but instead uses the driver of the selected target device. (Of course, the target device can also be the local system.)

The following diagram illustrates this relationship once again.

This procedure reduces the complexity of certificate management, as there is only one certificate store to be managed - that of the driver. In addition, network environments are also supported in which the OPC UA server can be reached from the runtime system but not from the engineering system. This is typically the case in operating environments in which the controller splits different network segments onto dedicated network interface cards, e.g. a "Machine" segment and a "Maintenance" segment - the latter for connecting an engineering laptop in the event of maintenance. This relationship is illustrated once again in the following diagram.

The following diagram illustrates this relationship once again in a slightly different form.