Alarm Flood

What you can build

• Tune chattering alarms in Ignition

  alarm_events shows a tag going Active and Clear dozens of times an hour. The operator proposes a Deadband and a Clear Delay on that alarm as a configuration resource update, with the transitions it would have removed.

  With Ignition

• Count S7-1500 alarms per operator

  ProDiag and Program_Alarm events from S7-1500 CPUs are read over OPC UA Alarms and Conditions and counted per operator hour from your shift times. Bursts are reported with the first event and the points behind it.

  With SIMATIC S7-1500, OPC UA

• Trace a flood to a lost device

  When many tag alarms start inside the same minute, the KEPServerEX event log is checked for a device going offline. The proposed report names the device instead of listing every tag.

  With KEPServerEX, Ignition

• Open a work order for a faulty point

  A level switch alarm that toggles all shift is proposed as a Fiix work order rather than a deadband, so the field fault is fixed and the alarm keeps its meaning.

  With Fiix, Ignition

Requirements

• An alarm journal or event source: Ignition with the alarm journal enabled, or an OPC UA server with Alarms & Conditions
• Ignition 8.3 with an API key for reading and proposing configuration resources, if priority and deadband changes are to be proposed there
• A shift or operator roster, or fixed shift times, to count alarms per operator hour
• Optional: a CMMS such as Fiix for work orders on faulty points

Authentication

Journals, configurations, and work orders are read and changed through the Ignition, OPC UA, KEPServerEX, and Fiix connectors and the API keys, certificates, or sessions each holds; the operator carries none.

Limits

• Ignition warns that API use can lose configuration and that GET requests are not audit-logged; every proposed change is shown beside the current definition
• It counts and tunes. It never acknowledges, shelves, disables, or clears an alarm, and it proposes nothing on safety instrumented or fire alarms
• Where an OPC UA server exposes alarms but not their configuration, the operator can report chatter but cannot propose a deadband there
• Counting per operator hour depends on shift times you supply; without them the count is per hour of the day

Questions and answers

What does the alarm owner approve?

Each priority, deadband, or delay change, one alarm at a time, with the current setting, the proposed one, and the journal entries that justify it. Stale and flood reports are review lists; nothing in them changes an alarm. You approve, edit the value, or dismiss.

What is recorded for each change?

The journal rows counted, the alarm's definition before and after, who approved the change and when, the configuration write as the Gateway audit log records it, and how to restore the previous definition.

Does it acknowledge or silence alarms?

No. It reads transitions and acknowledgements and never sends an acknowledge, shelve, disable, or clear. Its writes are alarm configuration changes and work orders, each after approval. Safety and fire alarms are excluded from every proposal.