SECS-II equipment alarms

Alarms are sent via S5F1 message from the equipment to the host.

The reception of the alarm data is acknowledged by the driver automatically via S5F2 when the config entry “sendAutoAck” is enabled. If “sendAutoAck” is disabled, the S5F2 message must be sent by the user application for example by a CTRL-script.

Alarm configuration

Alarms are not acknowledgeable on the equipment and therefore should not be acknowledgeable in WinCC OA. They must be configured as multi-instance alarms with a _alert_class which is not acknowledgeable.

For the driver to be able to map the SECS-II alarms to WinCC OA alarms, SECS-II alarms must be captured on an unsigned integer, integer, float or bool DPE which also holds a “_alert_hdl” config with a multi-instance alarm configured. These unsigned integer, integer, float or bool DPEs must be used with an according address configuration (e.g.: “ALID_A.1000”). The driver uses these DPEs to map the SECS-II alarms to WinCC OA alarms. If no unsigned integer, integer, float or bool alarm address is configured, the fallback alarm DPE, which can be set in the config file with the entry „alarmFallbackAddress“ will be used.

The SECS-II alarms can also be captured in the form of the E5 JSON-message on a string DPE with a corresponding address (e.g.: “ALID.1000”).

For further information on the address configuration of alarms refer to the section Defining the Peripheral Address.

Alarm Mapping

The body of a received E5 alarm message looks like the following example:

[
  {
    "doc": "<ALCD> Alarm code byte",
    "format": "B",
    "value": 0
  },
  {
    "doc": "<ALID> Alarm identification",
    "format": "U4",
    "value": 1002
  },
  {
    "doc": "<ALTX> Alarm text limited to 120 characters",
    "format": "A",
    "value": "Software test alarm 1002"
  }
]

These JSON-Objects are mapped by the driver to the WinCC OA alarm according to the following table:

_alert_hdl attribute Corresponding SECS-II object and information
_add_values[1] Value of <ALCD> (Alarm code byte) object
_add_values[2] Value of <ALTX> (Alarm text) object
_alert_id

Value of <ALID> like the following:

  • Came: ALERT_<ConnDpId>_<ALID>_C
  • Went: ALERT_<ConnDpId>_<ALID>_W
_comment

Values of <ALTX> and <ALID> combined like the following:

  • Came: <ALTX>-ALERT_<ALID>_C
  • Went: <ALTX>-ALERT_<ALID>_W

The “set” state of the alarm on the equipment corresponds with the state “came” in WinCC OA and the “clear” state on the equipment corresponds to the state “went” in WinCC OA. For further information on the alarms in SECS-II, refer to the standards SEMI E5 section 10.9 and E30 7.4.

Reconnection

On reconnection or driver start the following procedure is done to gain the current alarm state of the equipment:

  1. Remove existing alerts for connection.
  2. Check connection with Select.req and Select.res
  3. Send S5F7R to request current alarm information about all enabled alarms.
  4. Receive S5F8 answer to S5F7R request
  5. Set actual WinCC OA alarms with current timestamp
Note:
It must be taken into account that SECS-II alarms have no source time. Therefore SECS-II alarms which are in the “set” (came) state on the establishment of the connection will receive the connection timestamp for the WinCC OA alarm. Furthermore, an alarm that stays in the “set” state (came) on the equipment while a connection loss and reestablishment happened, causes two “came” alarms in the historical alarm view in WinCC OA. First, the alarm before the connection was lost and second, a new one which is created when the connection is reestablished as described in the table above. The driver sets the “_alert_hdl.._obsolete” attribute to true on reconnection for the alarm which was active in WinCC OA before the connection loss.