Multiinstance Alarms

Assumptions / Behavior:

  1. The driver must generate a unique alertId and must be able to reconvert it into rational peripheral data, so that every alert instance can be clearly addressed in the PLC.

  2. The alertId is unique for each alarm instance (CAME/WENT). An alert pair consists of two alert instances.

  3. The mapping of the PLC alert type to WinCC OA alert classes is free-definable and it is up to the user / driver programmer.

  4. Ideally, the alarm time comes from the periphery and is sent to the Event. If the periphery does not provide a time, alternatively the time is inserted by the driver. The Event always gets an alert time from the driver. The Event provides the uniqueness of this time by setting the counter.

  5. The ComDrv provides the possibility of mapping between the PLC alertId (_alert_id) and the alert pair (two alertIdentifiers) on the part of WinCC OA.

  6. Data point elements that may be target of an alarm, are indicated by an attribute in the _address config (_mode = AM_Alarm). A detailed mapping can be stored in the address string.

  7. The alert class chosen for an alert reflects the behavior in the periphery (Alarm Handling State Machine).

  8. The subindex of the _address config is not evaluated for alarm addresses.

  9. The alert handling in the driver runs parallel to the data handling. This means that smoothing, conversion and low level old/new comparisons are not possible for this data point element (configs in the driver that are stored on the "data path").

  10. Possibly passed values are cast to the data point element type and simply set. If alarms from several sources are mapped to one data point element, it is the responsibility of the driver to set these values correctly.

  11. The previously used behavior of direct setting alarms remains unaffected by this implementation, because for distinction the AM_Alarm mode bit of the peripheral address config is used.

Making alert classes available

A data point of the type _DriverCommon has one node for the alert handling (AL). This includes the AClasses data point element of the type dyn_string. This element contains the available alert classes. The names match the data points that have the _alert_class config. The user is responsible for the definition of the right names.

The driver reads the content of this element and builds an internal list of the entries with name, dpIdentifier and priority. If a priority of an entry can not be determined (wrong name or no alert class at the DPE), this entry will be ignored (-> warning in the log file).

By changing the DPE, the list will be rebuilt at runtime.

Each time a new alert is set (CAME), an alert class (the name) must be passed. The resolution of names -> dpId takes place in the ComDrv. If no matching alert class is found, the alert will not be set (-> error in the log file).

Mapping a data point element

The _address config offers the AM_Alarm mode. This provides the identification of an alert peripheral address. The rest of the attributes is not relevant for the alert handling (polling, subindex, transformations, etc.) and is ignored in the course of the alert handling. Thus, it also has no influence on the data, which is transferred to the DPE during an alertSet() call.

Instead of a dpConnect, the ComDrv uses an alertConnectRetVisible for subscription for _alert_hdl configs to the specific dpIdentifier and the attributes _alert_id, _add_values, _ack_state, _ackable as well as _visible. The HL messages are used to generate the ACK call in periphery direction and to keep the local Map AlertId <-> AlertIdentifier up to date. A callback function for the driver provides the possibility to send a confirmation to the periphery once an alert has been set successfully in the Event.

AlertId Map

The periphery provides a unique identification for each alert. Coming and going of an alert is reported with different alertIds. On the part of WinCC OA an alert pair is created. The ComDrv manages alarm instanced as individual entries. The ComDrv defines the alerIdentifiers to the passed alertIds via the alertId map and vice versa. In addition to the alertIdentifier also the _ack state is stored.

The map is updated only by the HL messages. Only then, in the case of redundancy, it can be ensured that the maps of the both redundant drivers hold the same alertIdentifier entries. If the _visible attribute of an alert is set to FALSE, the corresponding entry is removed from the map. The driver is informed about changes in the map via a callback function. Thus, the driver can generate a possibly desired confirmation of the alert input to the periphery.

Redundancy analysis:

The alert time is generated by the driver while alert creation, the count in the alert time is set to (-1). The Event replaces this count by an appropriate one, which guarantees an unique mapping. As long as no HL has been received by the Event, this count is locally set to (-1). In the event of a redundancy switching, the driver that becomes active must send all new alerts with count (-1) to the Event again, because it is assumed that unconfirmed demands were not (more) processed by the Event. When an HL message is received the corresponding entry in the alertId map is searched by means of the unique alertId and the count parameter is synchronized.

The pending alerts are stored locally as AlertObjects. The following attributes are registered for updates:

  • _alert_id

  • _add_values

  • _ack_state

  • _ack_possible

  • _visible

  • _direction

If an alert cannot be created (error from the Event) a corresponding notification is issued and the AlertObject is removed from the local list. Thus, all buffered follow-up requests (ACK or WENT or MODIFY) are lost.

Generating new alerts (CAME)

To create a new alert, an AlertObject object is generated locally in the ComDrv. The time of this alert always comes from the driver (if the periphery provides the time, this is used; otherwise the local time is used).

The _event attribute is set to DPATTR_ALERTEVENT_CAME. The alert class is passed as a string. The name must be configured in the driver data point. _alert_id and _add_values are filled according to the peripheral information. Accordingly, the message to the Event is generated by a call of alertSet(). A special mapping to which DPE the alert should be sent is defined by the peripheral address. A HWObhject holds the information and can be used for driver-specific decoding of the peripheral address in hardware address components.

When selecting the alert class, it has to be assumed that the selected class reflects the behavior of the peripheral state machine.

The AlertObject object has also an optional variable element. If this is set (!= 0), the variable is converted to the corresponding data point element type and is sent with the alert message to the DPE. The driver is responsible for the sensuous use of the multiinstance extension (setting values, if alarms from different sources are connected to the same DPE).

If the ComDrv receives an additional request for an alertId, which is not contained in the alert list, a check must be performed whether a corresponding request was already forwarded to the Event. If yes, the new request will be delayed and executed after Event HL, if no -> error message!

When adding additional values the variables are encapsulated into an anytype variable, if they are not of the anytype type.

Alarm goes (WENT)

If a "WENT" message is received from the periphery, an AlertObject object is generated and the _event attribute is set to DPATTR_ALERTEVENT_WENT. The new alertId as well as the new additional values are initialized in the AlertObject. Furthermore the CAME alertId must be passed. This needs to be reconstructed by the driver. A possibly passed alert class will be ignored, a possibly passed value will be sent to the DPE like in a CAME event.

Afterwards, the message is sent to the Event using alertSet().

Alarm is acknowledged (WinCC OA)

If an alarm is acknowledged in WinCC OA, this is communicated to the driver by setting the data point elements AL.AckDps and AL.AckData in the driver-internal data point. The ComDrv calls for each entry the ackAlertInHW() function, whereby the corresponding HWObject (peripheral address) and AlertObject (alertId) is passed. This function is used to send a message to the periphery with the command to acknowledge an alarm. The actual acknowledgement in WinCC OA must be triggered by a response telegram from the periphery.

If an _ack event on a driver-handled data point is received on the regular HL way, this is ignored by the ComDrv, i.e. the local status of the AlertObject is updated, but a transmission of a acknowledge telegram in periphery direction does not take place.

Alarm is acknowledged (PLC)

If the alarm is acknowledged on the hardware (by a message from WinCC OA or local interaction), this will be communicated to the driver. Then, this calls the ackAlertInPVSS() function, whereby the appropriate alertId (in the AlertObject) and PeriphAddr (in HWObject) are passed. The _event attribute is set to DPATTR_ALERTEVENT_SINGLE_ACK and sent to the Event.

Alarm becomes invalid

If the _visible attribute is set to FALSE for both AlertIdentifier of an alarm pair, this entry can be removed from the alertId map. The alarm is then no longer maintained in the driver. Prior to deletion of the alarm a callback function for the special driver is called, in which the respective alertId is passed.

Further information

The Overload (OV) element at the internal driver data point is used to display a driver overload. Currently only the mode "Overwrite by current value" is shown in the value handling queue. Prospective, also sending of alarms will be controlled by a queue. This has to parameters: how many AlertVCs may be outstanding (reported by hotlinks) and how long the alert queue maximum may be, before alerts will not being sent anymore. In the second case also the Overload element is set. The both values can be set in the config file:

  • maxAlertQueueSize, default: 10000

  • maxOpenAlertMsg, default: 30

The alert queue is regularly checked in the workProc of the DrvManager and pending messages are sent, as long as the not confirmed number is not lesser than the given limit.

While start-up all (according to the Event) pending alarms are inserted into the alert list (no call of the callback function!). The special driver can later go through the list using an iterator and perform a synchronization with the PLC. The driver is responsible for the synchronization.

In the event of a redundancy switch it has to be assumed that all pending alerts between driver and Event are lost. Thus, the counter for open messages is reset on each switch. As it can not be lesser than 0, additional received responses are ignored.

The buffering of requests to not yet created alarms is limited to one request per type (WENT, ACK, MODIFY). The task of a new request of the same type overwrites the previous one. The incoming of a hotlink for a specific type (e.g. ACK) deletes the pending request, independent whether the hotlink was received due to the local telegram or another telegram (the state of the alarm should be mapped / reached and this takes place independent of the transmitter).

In the event of a redundancy switch, the outstanding alarm instances will be sent by the current active driver once again. In case of positive confirmation a re-sending of the additionally buffered requests takes place. These will be removed after the performed change (and only if received as HL).

Recommendations

  • First entry (alert_hdl..add_value_1) should be the trigger value.

  • Second entry (alert_hdl..add_value_2) should contain the alarm text provided by the periphery.

  • Third entry (alert_hdl..add_value_3) contains the priority provided by the periphery.

  • Fourth entry (alert_hdl..add_value_4) contains the quality code.

For these entries constants are defined in the AlertService to access the particular predefined positions via constants.