OPC-UA Server Component
The OPC-UA Server Component provides a single entry point through which connected applications can access device and sensor data. Data from a device is read (or written) via Xrt Device Service components (for example Modbus Device Service) and automatically used to populate a representation of the corresponding connected device's resources in the OPC UA Server namespace.
The server acts as an interface to a Device Service by mapping reads and writes on resource nodes through to operations on a Device Service. A Device Service's topics are monitored by the server for changes, for example to detect a device being added, so that an accurate state of Device Services and their devices can be maintained.
OPC-UA client applications can read the normalized device data via the OPC-UA server or alternatively an OPC-UA client application can write data back into the server which is then automatically mapped through to the connected device.
OPC-UA Server Service Set
The server supoprts the following Security Policies:
The server supports the following User Authentication methods:
The server can monitor a Device Service's Telemetry topic to utilize
Auto-Events. This can be used to improve performance as the server can reduce the number of requests it needs to make to a Device Service.
When the server receives a resource value update from a telemetry message, it will use this value for a set period of time for any incoming read requests on the resource. If a new telemetry message is received for the same resource in this time period, the server will use this new value and the duration timer is reset. Once the duration has passed, the server will default to performing requests on the device service for each read request until a new telemetry message is received.
To configure the time the server uses a telemetry value, see StaleTelemetryValueTime.
||String||The shared library implementing the OPC-UA Server component||libxrt-opc-ua-server.so||Y - When using dynamic linking|
||String||The name of the C function used to instantiate the component||xrt_opc_ua_server_factory||Y - When using dynamic linking|
||String||The name of the bus component to use||The name of an existing bus component||Y|
||String||The name of the Logger component to use||The name of an existing Logger component||N|
||Integer||The port to run the server on. Defaults to
||Object||Array of Configurations for the Device services that the server will represent||See DeviceServices Configuration||N|
||Object||Array of Configurations for the server's Security Policies. Defaults to the None policy.||See SecurityPolicy Configuration||N|
||Object||Array of Configurations for the server's Endpoints. Defaults to one endpoint with a None security policy.||See Endpoints Configuration||N|
||Object||Configuration for the server's certificate authentication and verification||See CertificateVerification Configuration||N|
||Object||Configuration for the server's Access Control||See AccessControl Configuration||N|
Device Service configuration is required for the server to add a Device Service into its namespace. It also provides specific configuration options for interaction with a Device Service.
||String||The name of a Device Service to be added to the server||The name of an existing Device Service component||Y|
||UInt32||The time (in milliseconds) for the server to consider a request to the Device Service to have timed out. Defaults to
||Any positive integer value||N|
||Float64||The minimum interval (in milliseconds) that the server can sample a resource on the device service. Defaults to
||Any positive Float value||N|
||Bool||Determines if the device service should use telemetry readings.||
||UInt64||The duration (in milliseconds) for the OPC-UA server to use a telemetry value. See Telemetry Monitoring for more details.
||Any positive integer value||N|
A SecurityPolicy configuration defines a security policy available for use by the server.
||String||The name of the security policy being configured||See SecurityPolicies||Y|
||String||The Certificate to be used with the respective policy||A valid path to the certificate||Y - Unless using policy
||String||The private key that corresponds to the certificate||A valid path to the private key||Y - Unless using policy
An Endpoint configuration is used to define endpoints which are provided by the Server. The configuration options provides the ability to create multiple endpoints for a single SecurityPolicy, each using a different MessageSecurityMode.
||String||The Security Policy of the Endpoint(s). This Policy must have been created in the SecurityPolicies Configuration||See SecurityPolicies||Y|
||String||A list of MessageSecurityModes to configure the available security modes that can be used with the
||String||Overrides the Security Policy that is used with the X509 Certificate AccessControl for this endpoint.||See SecurityPolicies||N, unless using X509 authentication with a
||String||Overrides the Security Policy that is used with the UserPass AccessControl for this endpoint.||See SecurityPolicies||N|
The configuration for the server's access control. This is used by the server to authenticate sessions and grant access rights.
||Boolean||Allow Anonymous login to the server||
||Boolean||Enables X509 certificate authentication. Defaults to
||Object||An access control list||A map of
Certificate Verification Configuration
The Certificate Verification configuration is used to configure certificate verification used with X509 certificate authentication access control.
||String||A list of Certificates to determine trust||A list of certifcate file paths||N|
||String||A list of CA Certificates required for chain validation that are not in the
||A list of certifcate file paths||N|
||String||A list of Certificates that have been revoked||A list of certifcate file paths||N|
Interacting with the OPC-UA Server
Any OPC-UA client can be used to connect to the server. By default the server runs on port
Xrt on the server
The Xrt instance is represented by an Xrt object node. This object can be found under the root server node's objects folder. The Xrt object will have a folder object named
DeviceServices, which organises all the device services that have been added to the server.
An example of the structuring of the nodes of an Xrt instance's device services can be seen below:
objects └── XRT └── DeviceServices ├── s7 │ └── Devices │ ├── s7-simulator │ │ └── Resources │ │ ├── Counter │ │ ├── Sawtooth │ │ ├── Square │ │ └── Status │ └── s7-server │ └── Resources │ ├── Counter │ ├── Sawtooth │ ├── Square │ └── Status └── bacnet └── Devices └── bacnet-server └── Resources ├── Resource1 ├── Resource2 └── Status
All nodes relating to Xrt will be on namespace index 1. The node identifiers of Device Service, Device, and Device Resource nodes use string identifiers and are named using the following method:
For example, an s7 Device service's identifier will be:
For example, a Device added to the s7 device service called simulator will have the string identifier:
For example, a resource Counter for the above s7 Device will have the string identifier:
Device Resource Interaction
When a read or a write request on a Device Resource from an OPC-UA client is received, the server will map that request through to the appropriate Device Service and Device. In the case that a Schedule is running for that particular resource, the server can use recently received values when processing the read request, see Telemetry monitoring for more details.
OPC-UA Server component example
An example configuration of the OPC-UA Server component can be found on the Xrt Examples repository. The example consists of an OPC-UA Server component and an S7 Device Service component with an added simulated S7 device.