.. _user/protocols/opcua: ****** OPC UA ****** **O**\pen **P**\latform **C**\ommunications **- U**\nified **A**\rchitecture, or OPC UA for short, describes a machine-to-machine (M2M) communication protocol developed by the `OPC Foundation `_. It is widely used for communication with industrial equipment and systems for data collection and control. This page describes how the Connectware can act as an OPC UA client. The Connectware can also act as a :ref:`OPC UA server `. Subscription Strategies ======================= OPC UA distinguishes between *subscriptions* and *monitors*. A subscription carries parameters like `publishInterval` and `maxNotificationsPerPublish` so that it controls the data flow between server and client. Multiple monitors can be added to each subscription, with parameters like `nodeId`, `attributeId`, `samplingInterval`, so monitors control the *gathering* of the data by the server. The Connectware tries to abstract this complexity away and automatically combines monitors to as few subscriptions as possible. *Important*: As of today, subscriptions are combined only by the `publishInterval` parameter. Other subscription parameters such as `maxNotificationsPerPublish` will be taken only from the first mapping, and subsequently ignored. Security Settings ================= For production use, the connection to the OPC UA server should only be established using the security profile ``SignAndEncrypt``. Any other security profile bears the risk that the communication between client and server can easily get manipulated or compromised. Per default, the built-in OPC UA server only allows connections with ``SignAndEncrypt`` security setting enabled (in the property ``securityModes``). Please use your Connectware credentials when authenticating to the OPC UA server by Connectware username and password user token. Example: .. code-block:: yaml :linenos: resources: spindleSpeed: type: Cybus::Endpoint properties: protocol: Opcua connection: !ref opcuaConnection subscribe: nodeId: "ns=1;s=spindleSpeed" publishInterval: 1000 samplingInterval: 100 maxNotificationsPerPublish: 100 powerConsumption: type: Cybus::Endpoint properties: protocol: Opcua connection: !ref opcuaConnection subscribe: nodeId: "ns=1;s=powerConsumption" publishInterval: 1000 maxNotificationsPerPublish: 50 samplingInterval: 1000 temperature: type: Cybus::Endpoint properties: protocol: Opcua connection: !ref opcuaConnection subscribe: nodeId: "ns=1;s=temperature" publishInterval: 15000 samplingInterval: 15000 In the above example, two subscriptions will be created, one with `publishInterval` set to `1000ms` and `maxNotificationsPerPublish` set to 100, the other one with `publishInterval` set to `15.000ms`. The sampling of the individual source values will be set as expected, but remember that OPC UA does not offer a fixed data sampling but rather applies a change-of-value filter to each particular data point automatically. .. _user/protocols/opcua_connection: .. include:: ../protocolSchemas/OpcuaConnection.rst .. _user/protocols/opcua_endpoint: .. include:: ../protocolSchemas/OpcuaEndpoint.rst .. _user/protocols/opcua/examples: Example Commissioning Files =========================== Simple example -------------- This is a simple OPC UA connectivity example that only subscribes to the "Server Status" node of an OPC UA server. The proposed node (endpoint) can also be used if the server would otherwise close the connection, which has been observed for some specific versions of OPC UA servers on a S7 PLC. The example will need some OPC UA server available in your network: .. literalinclude:: opcua-simple-example.yml :language: yaml :linenos: Download: :download:`opcua-simple-example.yml` More complex example -------------------- More complex example including an OPC UA server container from public docker hub: .. literalinclude:: opcua-example.yml :language: yaml :linenos: Download: :download:`opcua-example.yml` Output Format ============= If data is read from OPC UA the output will be provided as JSON object with value and timestamp. The given timestamp is the OPC UA "Source Timestamp" which was set on the data source side, see https://reference.opcfoundation.org/v104/Core/docs/Part4/7.7.3/ .. code:: json { "timestamp": "", "value": "value" } Note: If 64-bit integers are being used (which are unsupported in JSON, but are supported in Javascript by the BigInt class), the value is returned as a string that contains the decimal number. Input Format ============ If data is written to OPC UA it must be provided as JSON object .. code:: json { "value": "" } .. _user/protocols/opcua/reconnection: Reconnection Behaviour ====================== In OPC UA connections -- just with any network connections -- it can happen that the connection is lost. In that case the Connectware's OpcuaConnection will automatically switch into `reconnecting` state and repeatedly try to re-establish the connection. The exact behaviour on how often this is tried can be controlled by the optional ``connectionStrategy`` properties, see :ref:`user/protocols/opcua_connection`. The important property is ``maxDelay`` which sets the maximum waiting time (delay) between consecutive re-tries, in milliseconds. The waiting time will start with the value ``initialDelay``, then be increased step by step, until the ``maxDelay`` value. Example with initially 500ms waiting time, increasing up to 10 seconds: .. code-block:: yaml :linenos: resources: myConnection: type: Cybus::Connection properties: protocol: Opcua connection: host: !ref opcuaHost port: !ref opcuaPort options: connectionStrategy: initialDelay: 500 maxDelay: 10000 For further details see also the documentation of the internally used package `backoff`, https://www.npmjs.com/package/backoff