Ometa.System.OpcUa System Object
The main purpose of the Ometa.System.OpcUa system object is to enable the functionality of the OPC UA Wizard but also to provide access to subscription information and monitoring actions for use on portals.
Following methods and views are available for public use:
| Name | Type | Description |
|---|---|---|
| Ensure Monitoring | Method | Adds a sensor to the monitoring list of the OPC UA service. |
| Get All Enabled Subscriptions | Method | Returns a list of all available and enabled subscription definitions. |
| Stop Monitoring | Method | Removes a sensor from the monitoring list of the OPC UA service. |
| Get All Enabled Subscriptions | View | A view on top of the Get All Enabled Subscriptions method. |
Important
The listed methods and views above will remain backwards compatible in future releases.
Any other method or view currently present in the system object is subject to change in upcoming releases. Using those methods or views in a portal solution is at your own risk as an update to a later version of the Framework may cause breaking changes.
Ensure Monitoring Method
This method can be called directly from a portal and adds a sensor according the provided monitoring options to the subscription maintained by the OPC UA service.
The following input fields are present:
| Field | Required | Description |
|---|---|---|
| Subscription Id | Mandatory (*) | Direct reference to the subscription definition. (* = see note) |
| Subscription Name | Optional (*) | Name of the subscription definition. (* = see note) |
| Profile Name | Mandatory | First part of the sensor key. This field contains the name of the profile the service uses to connect to the OPC UA server. |
| Object Node Id | Mandatory | Second part of the sensor key. In here, the node Id reference, as defined on the OPC UA server, is passed in. |
| Data Change Trigger Type | Mandatory | States on which data change events the OPC UA server should sent the sensor data to the service. |
| Dead Band Type | Mandatory | Selects the type of dead band range to use, or none at all, during monitoring of a sensor. |
| Dead Band Value | Optional | Provides the size of the dead band range, if enabled. |
| Variable Browse Name | Optional | Name of a specific variable of the sensor object. If set, it overrules the subscription monitoring variable. |
Note
When the Subscription Id is provided, the Subscription Name can remain empty. However, if the Id is not known, the Subscription Name can be used instead and leave the Subscription Id empty.
Warning
The Ometa OPCUA Service Windows service must be running without any startup problems. Refer to the Configuring the Interface article for more information about the Windows service.
No result information is returned, except only for error messages.
Data Change Trigger Types
Sensor changes come in various types and it is important to select the proper trigger type to avoid getting too much data. The Data Change Trigger Type field expects only an integer value of one of these:
- 1: Status only changes. Occurs when the status of a sensor, e.g. the OPC UA server temporarily loses connection to the sensor, changes.
- 2: Status and value only changes. Alongside the status changes, in this case also updated sensor value measurements are sent by the OPC UA server.
- 3: Status, value and timestamp changes. This is the same as for type 2 but now everytime the OPC UA server checks the sensor (= measuring), data is sent back even when the value itself hasn't changed.
Passing in any other value will result in error messages.
Dead Band Types
To avoid receiving too much data from an OPC UA server for a certain sensor, a dead band range can be defined so that the server will only send data back when the last measured value of the sensor compared with the previous sent value, falls outside the given dead band range. When defining a dead band range, the dead band value is used for both the lower and upper boundary of that range.
The Dead Band Type field expects only an integer value of one of these:
- 1: None. No dead band range will be used, any value change during sensor measurement will be sent.
- 2: Absolute value range.
- 3: Percent value range.
Passing in any other value will result in error messages.
An example of dead band range calculation: the dead band value is 5 and the previously sent value is 10, this means that all measured values between 5 and 15 (subtract from and add to 10) will not be sent to the service. Any measured value outside that range will be sent. In case a value was sent, the dead band range is recalculated according to that last value. E.g. when the new value was 16, the new dead band range will be between 11 and 21 (16 - 5 and 16 + 5). The same procedure is used for percentages, only the dead band value will be used as a percentage instead of an absolute value.
Overruling Monitoring Variable
When starting the monitoring of a sensor, the OPC UA service will specifically look for one of the monitoring variables, as defined in the subscription, in the OPC UA sensor object. Although this makes it easy to setup sensor monitoring, it will not handle all possible scenarios. For example, tracking multiple variables on one sensor object is not possible with a single subscription because the monitoring setup will use the first monitoring variable it finds on a sensor object and stop searching for others.
Setting the input context field Variable Browse Name to the name of a variable that exists on the sensor object, the Ensure Monitoring method will search for only that variable.
This way multiple variable monitorings on a sensor can be set up on the same subscription.
Keep in mind that when the variable set to Variable Browse Name is not found, there is no fallback and an error will be returned. This behaviour exists to avoid that issues may arise
when a monitoring already exists on a sensor variable, and at the same time to let the users know that the provided name is wrong and needs to be checked.
Get All Enabled Subscriptions Method and View
With the help of the Get All Enabled Subscriptions method and view, it is possible to show the subscription definition information on a portal, e.g. as a data source, to allow any portal users to select which subscription to use for sensor monitoring.
There are no input fields, the method only returns subscription information:
| Field | Description |
|---|---|
| Subscription Id | Direct reference to the subscription definition. |
| Subscription Name | Name of the subscription definition. |
| Subscription Description | User provided description information during subscription definition creation. |
The returned Id can be used in the Ensure Monitoring and Stop Monitoring methods for subscription definition selection.
Note
To make sure the method returns any data, complete the Framework ODBC profile by either creating a FrameworkDB ODBC data source or change the connection string in the profile itself.
Stop Monitoring Method
Where the Ensure Monitoring method adds a sensor to the monitoring list, this one removes the sensor from the monitoring list. Stop Monitoring can also be called directly from a portal.
The following input fields are present:
| Field | Required | Description |
|---|---|---|
| Subscription Id | Mandatory (*) | Direct reference to the subscription definition. (* = see note) |
| Subscription Name | Optional (*) | Name of the subscription definition. (* = see note) |
| Profile Name | Mandatory | First part of the sensor key. This field contains the name of profile the service uses to connect to the OPC UA server. |
| Object Node Id | Mandatory | Second part of the sensor key. In here, the node Id reference, as defined on the OPC UA server, is passed in. |
| Variable Browse Name | Optional | Name of specific variable of the sensor object. Is used to overrule the subscription monitoring variable. |
Note
When the Subscription Id is provided, the Subscription Name can remain empty. However, if the Id is not known, the Subscription Name can be used instead and leave the Subscription Id empty.
No result information is returned, except only for error messages.
Overruling Monitoring Variable
Stopping the monitoring of a sensor, the OPC UA service will specifically look for one of the monitoring variables, as defined in the subscription, in the OPC UA sensor object to know which tracking session must be stopped.
However, when the monitoring was started with a custom variable name, the service will not find that monitoring session automatically. In that case it is mandatory to set the Variable Browse Name
to the proper value. This is especially important when more than one monitoring session is enabled on different variables of a single sensor object.
Keep in mind that when the variable name set to Variable Browse Name is not found, there is no fallback and an error will be returned. This behaviour is consistent
with the error handling of the Ensure Monitoring method.