OPC UA Server

OPC UA

OPC UA is the next generation of OPC technology. OPC UA is a more secure, open, and reliable mechanism for transferring information between servers and clients. It provides more open transports, better security and a more complete information model than the original OPC, “OPC Classic.” OPC UA provides a very flexible and adaptable mechanism for moving data between enterprise-type systems and various kinds of controls, monitoring devices and sensors that interact with real-world data.

OPC UA Server component in Typhoon HIL toolchain

OPC UA is supported by the following Typhoon HIL devices: HIL402, HIL404, HIL602+, HIL604, HIL606, and VHIL.

The OPC UA Server component has two ports, nodes_in and nodes_out, shown in Figure 1.

After opening a components dialog window (OPC UA Server dialog window), two parts of the server can be defined: configuration part and the execution rate part.

The basic configuration for OPC UA Server needs to have a defined IP address, port and netmask. Multiple servers can have the same IP address but different ports.

Additionally, login options can be defined. Currently, anonymous login and username/password are supported. If a username and password are present, then username/password login will be selected; otherwise, anonymous login will be used.

Apart from server configuration, there is also an option for choosing which ethernet port on the back of the HIL device will be used by the application. For 4th generation devices (HIL404 and HIL606), any available port can be used for communication, while older devices only support communication over port 1.

Encrypted communication

Encrypted communication provides security for transported information by keeping information safe from eavesdropping. It can be chosen alongside username/password login protection in the OPC UA Server component.

OPC UA uses certificates generated by OpenSSL to provide encrypted communication. The basic formats for these certificates are *.der and *.pem. If a 'certificate' dict with relative paths of the certificates (shown in the OPC UA example model) are not provided, the OPC UA Server component will not use encrypted communications.

If encryption is desired, the 'certificate' dict must have at least three elements: 'server_certificate', 'server_key', and 'client_certificate'. If multiple clients should be connected to an OPC UA Server while using encryption, separate certificates for each client must be added in the 'client_certificate' list (ex. 'client_certificate': ['certs\\uaexpert.der, 'certs\\client_cert.der']).

A default server certificate is provided in the THCC installation at 'communication protocols/opc ua/certs/server_cert.der'. Additionally, a client certificate has been placed in the same filepath with the name 'uaexpert.der'. When using other certificates, it is important to add the IP address of the application to the certificate for that application (ex. server ip address: 192.168.20.200, ip addresses in certificate: 127.0.0.1,192.168.20.200).

OPC UA Server node configuration

OPC UA Server Nodes can be defined with nodes_in and nodes_out Python dictionaries or single nodes dictionary. The dictionary key (OPC UA Node) is a signal name which users can name arbitrarily. The value of the OPC UA node is Python tuple. The first element of a tuple is the index of the component input vector and the second element is the type of the variable. Types can be 'int', 'uint', 'bool' and 'real'. If the nodes configuration is used, third parameter is required that defines if the variable is input or output to the component and value can be 'in' or 'out'.

Only one method of nodes configuration can be used. If the configuration has nodes_in, nodes_out, and nodes dictionaries defined, validation will fail.

The scalar node is defined by a single index value and signal type. The array node is defined by a pair of indexes and signal type. For the array node, the first index is the start index from the input vector and the second one is the end index of the input vector. The size of the array is calculated as: end index - start index (ex. [3, 5] this is array of 3 nodes).

The configuration has to be defined in the Model->Model Initialization as Python dictionary type, and set into configuration property (OPC UA configuration). The name of configuration is freely defined by the user (see Figure 3).

config1 = {
    'ip_addr': '192.168.42.200',
    'port': 16664,
    'netmask': '255.255.255.0',
    'username': 'username',
    'password': 'password',
    'certificate': {
                'server_certificate': 'certs\\server_cert.der',
                'server_key': 'certs\\server_key.pem',
                'client_certificate': ['certs\\uaexpert.der']
       },
    'nodes_in' : {
        'current_in': (0, 'real'),
        'voltage_in': (1, 'real'),
        'current_voltage':([0,1], 'real')
    },
    'nodes_out' : {
        'cmd_out': (0, 'int'),
    },
}

In the above configuration example (config1), nodes_in has one input scalar value (index 0 from input vector) and two input arrays: the first one with two elements (index 1 and 2 from input vector) and the second one with three elements (index 3 and 5 from input vector). Nodes in nodes_out are configured the same way, but appear as outputs instead.

Dictionary keys for nodes_in and nodes_out (voltage0_in, array_int_inputs, etc) have to be unique because they are used as the OPC UA NodeId string identifier. Dictionary keys in nodes_in can have the same name, but, in that case, the last one defined with the same name will be used (also applies to nodes_out). Nodes defined in nodes_in are read-only for the client, while nodes_out values are also writeable.

The second way of nodes configuration is shown in Figure 4.

config2 = {
    'ip_addr': '192.168.42.200',
    'port': 16665,
    'netmask': '255.255.255.0',
    'username': 'username',
    'password': 'password',
    'certificate': {
                'server_certificate': 'certs\\server_cert.der',
                'server_key': 'certs\\server_key.pem',
                'client_certificate': ['certs\\uaexpert.der']
       },
    'nodes': {
        'Measurements': {
            'Current in': (0, 'real', 'in'),
            'Voltage in': (1, 'real', 'in'),
            'Current and voltage': ([0, 1], 'real', 'in'),
        },
        'Outputs':{
            'Cmd out': (0, 'int', 'out'),
        }
    }
}

In the above configuration example (config2), single nodes configuration dictionary is used. The structure of this dictionary is mirrored to the OPC UA server. In the example above, Two OPC UA folders are created (Measurements and Outputs) each with their own variables. These folders can contain more folders with variables, so the user can freely define the folder structure and sort the variables accordingly.

All types are inherited. Node descriptions are automatically generated.

Time synchronization

If there is a need for time synchronization, please take a look at Time synchronization.

Virtual HIL support

Since the Virtual HIL environment runs on the HOST PC machine, the IP address will be the same for all OPC UA Server applications. Unique PORT numbers are used to connect to a particular OPC Server. The HOST IP address is used for OPC Server application. To access the OPC Server application, use this url: opc.tcp://HOST PC NAME:PORT NUMBER

Generating x509 certificates

The Python script "create_self-signed.py" has been provided in the "communication protocols/opc ua/certs" directory to help with generating self-signed x509 certificates. A brief user manual is located in the top section of the script.