OPC UA Alarms and Conditions

This chapter deals with the function of the OPC UA Alarms & Conditions (A&C) implementation for the WinCC OA OPC UA client. This allows receiving and acknowledging alarms from an OPC UA alarm server.

The alarm is mapped to a data point element in the WinCC OA OPC UA client project via a corresponding peripheral address. To trigger an alarm on the WinCC OA client system, an alert handling for multiinstance alarms (_alert_hdl config) must be configured at this data point element. Multiinstance alarms have the advantage that an alarm action like came, acknowledge, went can be triggered externally and are not calculated by the Event manager. In addition, for this alarm type additional information can be stored in so-called additional values (see Contents of additional values for OPC UA). Furthermore, a special alert class can be passed for each alarm, i.e. not the specified alert class will be used.

Important notes and restrictions on OPC UA AC you can find in the chapters Supported alarm types and restrictions and Alarms and Conditions (AC).

Requirements and limitations

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

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

To receive alarms a subscription must be configured. In the subscription the alarm type needs to be selected. This alarm type defines the mapping of the OPC UA attributes to WinCC OA alert ranges. Currently the following alarm types are supported by the WinCC OA OPC UA client:

  • OffNormalAlarm
  • ExclusiveLimitAlarm
  • ExclusiveDeviationAlarm
  • WinCCOADiscreteAlarm
  • WinCCOAContinuousAlarm

These types already contain the basic conditions like Enabled, Active and Acknowledged. OPC UA alarm types must always be mapped to multiinstance alarms with the appropriate alert range in WinCC OA.

In addition, the alarm type Manual can be selected to specify a node Id manually.

For further information see also Supported alarm types and restrictions.

Figure 1. Example of a Subscription configuration of type Alarms & Conditions

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 rage 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

Status Range
ActiveState=false 1
ActiveState=true;Range2=true 2
ActiveState=true;Range3=true 3

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, as the actual alert class results from the OPC UA severity. 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.

Figure 2. Drivers tab in the WinCC OA system management

In WinCC OA the priority of an alarm results from the priority of the alert class. I.e. the priority for an alarm is defined by the mapping of the OPC UA alarm severity. This means that an acknowledge concept and the WinCC OA alarm priority arise from the WinCC OA alert class, from which the OPC UA severity arises. These can not be changed anymore for the lifetime of the alarm.

Figure 3. Mapping of the OPC UA alert severity

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:

Severity1 AlertClass1
Severity2 AlertClass2
Severity3 AlertClass3
...

This means that the alert class 1 (AlertClass1) is used for the OPC UA Severity1 to Severity2-1. The last alert area is ranged to the highest OPC UA severity value (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 (state) 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.

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.

The alert class has no meaning and must only be defined to enable the alert handling. The actual alert class is determined by the previously defined severity. For example, according to this example's severity, a server alert with severity 75 would trigger an alert with class OPCUA_Warning on the client. A severity of 175 or more would trigger an alert with alert class OPCUA_Danger on the client.

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:

Attribute (of the config _alert_hdl) OPC UA event data
_add_value_1 empty
_add_value_2 OPC UA alert text
_add_value_3 OPC UA severity
_add_value_4 OPC UA quality information from Event
_add_value_5 Selected Event fields as JSON string (see subscription configuration ).

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).

Note:
  • The acknowledge setting Acknowledge old alarms is not supported.

  • The acknowledgement type CAME and WENT must be acknowledged is not supported for impulse alarms.

  • The alert screen only displays the values of the _alert_hdl.._event attribute, i.e. the value 0 for "Alert CAME" and 2 for "Alert WENT".

  • When using "CAME and WENT must be acknowledged separately in the AES screen, the client can not disable not acknowledgeable alerts (set background gray and disable clicking) due to the necessary information beeing only available on the server. This leads to multiple acknowledged alerts on the client but they will not be acknowledged on the server until they are acknowledgeable on the server.

Not acknowledge-able Acknowledge deletes CAME is acknowledgeable CAME or WENT must be acknowledged CAME and WENT must be acknowledged
Binary alarm
Binary alarm (discrete)
Binary alarm (impulse) N/A
Binary alarm (discrete, impulse) N/A
Alarm of continuous values (2 ranges)
Alarm of discrete values (2 ranges)
Alarm of discrete values (impulse, 2 ranges)
Alarm of continuous values (n ranges)
Alarm of discrete values (n ranges)
Alarm of discrete values (impulse, n ranges)

Dynamic Alarm Conditions

The OPC UA client can receive alarms only if the NodeId of the alarm condition is configured in the peripheral address. This is a limitation of WinCC OA, because some servers do not export the ConditionId in the address space or even use dynamic ConditionsIds.

Such alarms are very hard to configure in WinCC OA because it is almost impossible to determine the ConditionId in advance.

For example the S7 1500 OPC UA server uses dynamic conditions and therefore WinCC OA could not receive alarms from this device up until now.

Configuration

In order to support also the reception of alarms without configuration of the ConditionId the concept of a fallback address is used. This allows that all alarms, which are received via an alarm subscription and which are not mapped to an explicit configured ConditionId are mapped to an arbitrary fallback alarm address.

This fallback address can be configured with the config entry [opcua] alarmFallbackAddress. In such a case the receiving DPE might have many active alarm instances, which is possible because the _alert_hdl used a multi-instance alarm.

If more than one condition is mapped to a DPE you should always select UA Alarm text and UA Severity in the subscription, because different conditions might have difference alarm text and severity.