OPC UA Drivers
A few Ignition drivers are included on install in the form of modules that allow you to connect to specific types of devices over OPC UA. Each module provides the ability to connect to different types of devices.
Device Diagnostics Tags​
All drivers include built-in diagnostic tags that can be used to monitor the health of the device connection. Some of these metrics can also be found on the Device Connections page on the Gateway.
Root Diagnostic Tags​
| Tag | Description |
|---|---|
| Connected | A Boolean representing the connection between the device and the OPC UA server. Replaced the legacy "isConnected" tag, which was functionally the same. |
| Hostname | The hostname of the device, as configured in the device configuration on the Gateway. |
| Name | The name of the device, as configured in the device configuration on the Gateway. |
| Port | Represents the port used to communicate with the device. |
| State | A string representing the state of the device configuration. Example: "Connected", "Disconnected". |
| Status | A string representing the status of the device configuration. Generally provides more granular information than the State tag. |
Sampling Tags​
The Sampling folder contains metrics of the device connection's throughput. Each device contains an Aggregate folder, which represents overall performance of the device connection. The Aggregate folder is always present when browsing device connections that make use of one of Ignition's drivers.
Additional Sampling Group Folders are provided based on active subscriptions, and are grouped by sample rate. These folders contain tags that represent throughput of subscription items at set rates. For example, in the image of the Connected Devices window below we see several folders next to Aggregate: 250ms, 1000ms, and 2000ms . These folders exist because items in the device are being subscribed to at the rates specified.
This means there is at least one item in Micro_1 that is being subscribed to at a rate of 250ms. Thus, the driver has metrics for items that are being subscribed at that rate. Because there is a 1000ms folder, we know there is at least one item being subscribed at a 1000ms rate, and so on. Thus, every additional sampling folder signifies a different sampling group, and exists because something is being subscribed to at that rate.
Subscriptions are most commonly created by Tag Groups, but can be created by other means. For example, Transaction Groups that utilize OPC Items, or the Gateway's Quick Client page.
Each device contains a MonitoredItemCount tag, which represents the total number of items subscribed to on the gateway. Note that this count includes device diagnostic tags.
Requests​
When Ignition's drivers attempt to read values from a device, it does so with a grouping process. Updates for individual items are grouped up into requests. A request is a grouping of tags/items that need to be read at the same time. The number of items in a single request differs per driver, based mostly off of the protocol being used. Some drivers may have additional configurations options that impact how requests are grouped. Since requests have a fixed number of items to monitor, it's fairly common that there are more pending reads than can fit into a single request. As a result, multiple requests are often used to read values from the same device for the same sampling rate.
All requests are placed into a request queue and wait to execute. The Sampling Group Diagnostic Tags represent how well the device is able to respond to requests.
Sample Group Diagnostic Tags​
The table below describes the various diagnostic tags under the Aggregate and Sampling Group folders. Note that the structure for each type of folder is the same, save for several tags that are not available under the Aggregate folder; those exceptions are noted in the description column.
Tags in the Aggregates folder summarize all requests across all groups, whereas tags in sampling group folders represent metrics for that sample group. All metrics are based off the start of their group, unless specified otherwise. In the case of Aggregates, they're based off the last initialization of the device connection configuration on the host Ignition Gateway.
| Tag | Description | Available in Aggregate Folder |
|---|---|---|
| ActualSamplingInterval | Represents the actual interval the sample group was able to last execute at, in milliseconds. | No |
| ActualThroughput | A count representing the actual number of requests that were able to execute during the last sample interval. | Yes |
| IdealSamplingInterval | The ideal sample interval for the sample group in milliseconds. Generally, this will simply be the configured sample interval. | No |
| IdealThroughput | A count representing the ideal number of requests handled over a 1000ms period. Calculated with the following equation: RequestCount * 1000 / SamplingInterval | Yes |
| OverloadFactor | Represents how well the device is able to keep up with requests at the sample rate. Overload is calculated with the formula: 100 * (QueueDuration / ActualSamplingInterval) If overload exceeds 100%, then requests are being sampled at a slower than ideal rate. | No |
| QueueDuration | Represents the average amount of time a request has spent in the request queue. | No |
| RequestCount | The number of requests within the sampling group. | Yes |
Execution Timer Tags​
The tags in the table below represent how long the request process takes. Execution times are recorded in the following manner:
- A timer starts
- The request is sent off to the device
- A response from the device is received by the OPC server
- The timer stops
All of the following tags are available in both sample group folders, as well as the Aggregates folder. Like the Sample Group Diagnostics all metrics are based of the start of their group, unless specified otherwise. In the case of Aggregates, they're based off the last initialization of the device configuration.
| Tag(s) | Description |
|---|---|
| NthPercentile | N% of requests were able to execute at a number of milliseconds equal to or faster than the value on the tag. Example: If 75thPercentile shows a value of 50, then 75% of all requests were able to complete within 50 or fewer milliseconds. |
| Count | Represents the number of requests processed since the start of the sample group. |
| Max | The longest duration an execution took in the sampling group since the start of sampling. Reported in milliseconds. |
| Mean | The average duration for all executions in the sampling group since the start of sampling. Reported in milliseconds. |
| Min | The smallest duration an execution took to complete since the start of sampling. Reported in milliseconds. |
| MeanRate | An average of throughput, since the start of the sampling group. The MeanRate tag in the Aggregates folder represents an average since the last startup of the device connection. |
| OneMinuteRate | A rolling average of throughput over the last minute. |
| FiveMinuteRate | A rolling average of throughput over the last five minutes. |
Device Status​
The Device Connections page lists the current OPC UA devices configured through an Ignition device connection, and lets you know which are connected and which have a faulty connection. From here, you can drill into a device connection to see how many tags Ignition is requesting from the device, along with how often it is requesting them. This information can be used to determine if you are overloading the device with too many requests too quickly, or if you can request more from the device.
| Attribute | Description |
|---|---|
| Connected Devices | Number of devices connected out of configured devices. |
| Name | Name of the device. |
| Driver | Name of the device driver. |
| Enabled | True or false value whether the device connection is enabled. |
| Status | Current device status. |
Expanding the three dots menu and clicking View Details to the right of a device connection will display a Details panel that provides metrics for the device configuration. The panel contains an Aggregate Statistics table and lists additional statistics to help determine if the device is overloaded with requests. There are values for each subscription (such as those created by Tag Groups or Transaction Groups using OPC items) from the specified device, as well as aggregate statistics which pull from all subscriptions to get an average for the device.
Device Statistics​
The table below summarizes the statistics available on the device Details panel.
| Attribute | Description |
|---|---|
| Request Count | Tracks the number of requests that are coming in from the device, A request is a group of tags/items that the driver has grouped together to be read at the same time. Each driver forms these groups based on the protocol being used and occasionally configuration settings in the driver. |
| Throughput (Mean) | Represents the average amount of requests that come through per second since the device was last started. If the device connection is edited and saved, this will cause the device connection to reinitialize and this value will be reset. |
| Throughput (1 min) | Represents the amount of requests that come through per second, updated each minute. |
| Mean Response Time | The average time it takes for Ignition to get a response from the device. This number is an average based of the graph on the right of the page. |
| Monitored Item Count | Represents the total number of items that are subscribed to. Note that this count includes device diagnostic tags. However, other statistics on the device status page do not account for diagnostic tags. |
| Mean Queue Duration | Represents the average amount of time a request has spent in the request queue. Not available under aggregate statistics. |
| Actual Sampling Interval | Represents the actual rate the driver is sampling the device at. Used to determine Overload. Not available under aggregate statistics. |
Note that the metrics above have corresponding diagnostics tags available, allowing other areas of Ignition to access these values
In the image below, we see there are a total of 1068 items being monitored, which are optimized into 38 different requests.
Of those requests, five are being sampled at a 250ms rate. At this same rate, requests sit in a request queue for an average of 4.24ms before being processed. Thus the actual sampling interval for this sampling rate is 254.24ms.
Overload​
Overload represents how well the device is able to keep up with the requests at the sample rate. It is calculated using the formula:
100 * (Mean Queue Duration / Sampling Interval) = Overload
If overload exceeds 100% then the requests are sampling at a slower than ideal rate.
Based on the image above, overload for our 250ms sample group is determined by:
100 * (4.24 / 250) = 1.696
Our value of 1.696 can then be rounded up to 2%. In this case, it doesn't seem as if the device is having much trouble keeping up with our requests.