OPC UA Alarms and Conditions

Requirements and limitations

In order that the OPC UA client can receive alarms and conditions, the following requirements must be fulfilled:

• The config entry [driver] driverAckClassPrefix must be set. See Acknowledgement of alarms.
• An OPC UA connection data point to the server (see Configuration of the Servers) with a subscription of the type Alarms and Conditions was created (see Configuration of a subscription).
• OPC UA severities were mapped to WinCC OA alarm classes. See Mapping of alarm data.
• A peripheral address (_address) with the created subscription and the receive mode Alarm was created on the DPE which shall receive the alarms. The configured address must contain the node ID or the browse path of the alarm condition. See Configuration of a peripheral address.
• An alert handling for multiinstance alarms (_alert_hdl) was created on the same DPE. The alarm in WinCC OA will not be triggered by the value of the DPE, but directly. I.e. the driver sets the attribute _alert_hdl.._event. See Alert handling for multiinstance alarms.

This chapter provides a step by step example on how to receive and acknowledge alerts. The example shows the configuration of a discrete alert when using the WinCC OA OPC UA Servers.

Acknowledgement of alarms

In order that alarms are not acknowledged directly in WinCC OA but via the OPC UA server the following procedure is required:

1. Individual alarm classes with a unique prefix must be created in the project. Therefore, create the corresponding data points of type _AlertClass and configure the alarm class.
2. In the config file of the client project the following entry must be set.

[driver]
driverAckClassPrefix = "<prefix>" #e.g. "OPCUA" for the alert class OPCUA_Alarm

This entry is read from the UI. If set, the alarm is not acknowledged via the Event manager anymore but via the internal driver data point _ DriverCommon (see driverAckClassPrefix). Only if the server sends the confirmation of acknowledgment to the client, the alarms will be also acknowledged in WinCC OA.

Configuration of a subscription

If the server has a different type of alarm condition, you have to specify the node ID manually with the type “Manual ...”. You must consult the UA server documentation for this purpose.

Since you can only specify one alarm type in a subscription, you need one subscription per alarm.

• OffNormalAlarm
• ExclusiveLimitAlarm
• ExclusiveDeviationAlarm
• WinCCOADiscreteAlarm
• WinCCOAContinuousAlarm

The configured alarm condition type must be derived from the OPC UA standard AlarmConditionType, as this type contains all the fields required by the client to evaluate the status of the alarm (Active, Acknowledged, ect.).

For further information see also Supported alarm types and restrictions.

The fields of the panel are described in the chapter Configuration of a Subscription.

Event Notifier

When an alarm subscription is created, the monitored item is an event notifier.

This means that the client must subscribe to a notifier node that triggers the events for the configured alarm conditions.

Our UA client uses the "Server" object as the default notifier if the field in the subscription is empty.

This should be sufficient, because all events should be fired via this node. There are two reasons to change the notifier. The first is that the server does not use this node, although the OPC UA specification requires this. In this case, you need to consult the UA Server documentation to determine the correct node ID of the notifier. The second is the limitation of events, as the server node triggers all events, as mentioned above.

Mapping Table

Using the table in the middle of the panel the OPC UA alarm can be mapped on a specific alert range in WinCC OA, if this is desired. This is only useful if the receiving _alert_hdl is configured with more than two ranges. Usually only one Good and one Bad range is used for multiinstance alerts.

In the "Status" column of the table one can define a combination of UA condition attribute values and in the "Range" column the alert range, which should be set if the value matches, is defined.

Example

The attribute names must be valid for the selected condition type (or alarm type).

Mapping of alarm data

To trigger an alarm in WinCC OA an _alert_hdl config of the type multiinstance alarm must exist at the corresponding data point element.

The configured alert class (_alert_class) is irrelevant if the "UA Severity" checkbox is activated in the subscription and a mapping from OPC UA Serverity to WinCC OA alert class is configured.

The mapping of the OPC UA severity to the WinCC OA alert class can be defined in the panel OPC UA Alarm severity. This panel can be opened from the WinCC OA system management.

In WinCC OA, the priority and acknowledgement mode of the alert is determined by the alert class. This can either be the mapped alert class from the OPC UA Severity, if this mapping is configured, or the alert class that is configured in the multi-instance alert_hdl config. This means that the priority and the acknowledgement mode cannot be changed during the lifetime of the alert.

Driver

Choose here the driver data point _OPCUA<num> of the type _OPCUA for which the alert severity mapping should be used. <num> corresponds to the manager number, with which the OPC UA client is started.

Areas

Enter here the number of areas on which the total severities of 1000 should be split. The maximum number of definable areas is 30.

Mapping of the OPC UA severity to the WinCC OA alert class

The severity in OPC UA ranges from 1 to 1000, whereas 1 is the smallest severity and 1000 the highest. The alarm concept of WinCC OA is defined by priorities from 1 to 255, whereas also here 1 is the smallest priority. Consequently, big severity areas which cover together the entire severity area must be mapped to WinCC OA alert classes. These alert classes can be either already defined WinCC OA alert classes or can be created by the user, if the alarm should also be acknowledged at the periphery (for further information see Acknowledgement of alarms.

The mapping is written to the internal data point element _OPCUA.Config.AlarmPrioMapping. This DPE is of the type dyn_string and stores the mapping in the following format "<start severity> <alert class>" as shown in the example below.

1 OPCUA_Info
75 OPCUA_Warning
125 OPCUA_Alarm
175 OPCUA_Danger
...

This means that the alert class OPCUA_Info is used for OPC UA severity 1 to 74, OPCUA_Warning from 75 to 124 and so on. The last entry OPCUA_Danger is used from 175 to the highest OPC UA severity (1000).

Configuration of a peripheral address

Add an _address config to the data point element which shall receive the alarms and select the OPC UA server in the peripheral address panel. Select the appropriate subscription of type Alarms & Conditions.

In the peripheral address the corresponding condition (node ID) must be selected. Depending on the alarm type in the subscription configuration panel the browsing is carried out (Get Item ID button in the Peripheral address panel) in the corresponding mode.

Like for data and events also for alarms and conditions it is possible to use either the node Id or the browse path.

As an item, you must select the alarm condition ID that is used for the mapping of UA alarms to DPEs in WinCC OA.

Getting the correct condition ID can sometimes be difficult and there are several possibilities:

1. It is possible to search for the condition IDs using the WinCC OA UA client. Browsing for alarm condition IDs may or may not work, as it is not mandatory that alarm conditions must be in the OPC UA address space. If they are not, they cannot be browsed. Even if they are in the address space, they may not be accessible via the Server object central notifier, which is required by the WinCC OA client.
2. You get the Condition ID from the UA Server documentation.
3. Neither option 1 nor 2 are applicable. It may happen that the condition IDs are not known in advance or are dynamic. In this case, you cannot configure them in the address config. In this case, the alarmFallbackAddress condition ID must be used (see Dynamic alarm condition below).

Configuration of the the alert handling

Add an alert_hdl config for multi instance alerts to the same data point element. In this case the alert is not triggered via the value of the data point element but directly via the driver.

See the section Mapping of alarm data above.

Contents of additional values for OPC UA

With the help of the alert handling for multiinstance alarms it is possible to write different event parameters to additional values (for general information on additional values see Additional values). and for information on the config attributes for additional values see _alert_hdl). The following table shows the current mapping:

Sorting equal time alerts in the Alert and Event panel

An alert counter which is incremented for equal time alerts can be stored on an additional value. Therefore, the user can use this additional value as sorting option in the Alert and Event panel for alerts with the same time. The storage of this alert counter must be enabled by the config file entry "alertCounterAddValue" in the [opcua] section.

After creating a new row for the alert count in the Table configuration of the Alert and Event panel, the additional value can be used for sorting. Then you can sort alarms by time and if it's equal, by the alert count.

Supported alarm types and restrictions

The correct processing of alarms of an OPC UA server with the WinCC OA OPC UA client depends on some factors. Whereby correct processing means, that the cycle of an alarm on the server is reflected correctly on the client.

On the one hand this depends on the used alarm types, on the other hand also on the form how the alarm attributes change on the server. As OPC UA alarms are defined very flexible and in WinCC OA only fixed alarm concepts exist, only limited concepts of the client can be mapped to WinCC OA.

For this, the following restrictions should be taken into account:

• The alarm severity must not change on the server from the time up the alarm is active until it disappears.
• Each alarm can have only one good range and one alarm range.
• The acknowledge state of an alarm must nut change from "Acknowledged" to "Not Acknowledged" without that this alarm was triggered once again on the server.

The following matrix shows the supported combinations for the configuration of the WinCC OA OPC UA client (this applies only for the client - the matrix for the sever is described in the chapter Supported types of alarms and acknowledge).