Avoiding IIoT Alarm Floods: Configuring Hysteresis and Delay Correctly

→ Product category: IIoT solutions

 

A pressure sensor monitors a filter and is intended to trigger an alarm at a differential pressure of 2.0 bar. However, the actual measured value fluctuates between 1.98 and 2.03 bar. Without appropriate alarm configuration, this can result within just a few minutes in a sequence such as:

Alarm → Return to Normal → Alarm → Return to Normal

.

The problem is often neither the sensor nor the IIoT platform. Instead, the cause is an alarm limit without sufficient deadband or hysteresis, an unsuitable delay or a reset logic that does not match the dynamics of the monitored process.

In larger condition monitoring systems, this effect can multiply. When hundreds of measuring points monitor temperature, pressure, level, vibration or other condition variables, individual unstable sensors can generate thousands of events. If these are forwarded unfiltered via edge systems, MQTT, SCADA and cloud platforms, unnecessary messages, database entries and notifications are generated. Critical alarms can then become lost among insignificant messages.

Reliable alarming therefore requires more than a limit value. Alarm limit, hysteresis, on-delay, off-delay, reset condition, priority and escalation logic must be coordinated with the process dynamics and the required response.

ICS Schneider supports manufacturer-independent integration of sensor technology, edge gateways and IT/OT systems. The IIoT Solutions from ICS Schneider, for example, connect field devices via Modbus RTU, HART, IO-Link or Ethernet to edge systems and transfer data via MQTT or HTTPS to SCADA, historian or cloud applications.

Why alarm floods occur in condition monitoring

A modern sensor can provide a large number of measured values within a short period of time.

However, the number of measured values is not the same as the number of meaningful alarms.

Typical causes of unnecessarily high numbers of alarm messages include:

• alarm limit too close to the normal operating point,
• no deadband or a deadband that is too small,
• no time delay,
• strongly fluctuating measured signal,
• unsuitable sampling rate,
• unstable process,
• unsuitable sensor position,
• missing operating-state logic,
• multiple consequential alarms for the same cause,
• communication errors being treated like process alarms,
• alarm being immediately re-enabled after a brief return to normal.

A common misconception is

Every limit violation must immediately generate an alarm.

For certain safety-related functions, a very rapid response may be necessary.

In condition monitoring, however, the objective is often to identify a condition that is:

• relevant,
• persistent,
• reproducible and
• requires action.

A fluctuation lasting only a few milliseconds or a single outlier is not automatically a meaningful alarm.

Distinguishing between alarms, events and measured-value changes

For a clean IIoT architecture, different types of information should be distinguished from one another.

Information	Meaning	Typical response
Measured value	normal process value	store, visualize or aggregate
Event	relevant occurrence without necessarily requiring operator action	log
Warning	condition is developing unfavorably	monitor or plan maintenance
Alarm	abnormal condition requires a defined response	inform operator or responsible personnel
Fault	measurement or communication chain is not functioning correctly	diagnostics or maintenance

Not every piece of information that can technically be transmitted should be treated as an alarm.

This distinction is particularly important in IIoT systems because the sensor, edge gateway, broker, database, dashboard and notification service can each generate additional messages.

What does alarm flapping or chattering mean?

Alarm flapping or chattering describes behavior in which an alarm repeatedly switches within a short period of time between:

active

and:

normal

.

Typical example

Alarm limit:

80 °C

Measured values:

79.9 → 80.1 → 79.8 → 80.2 → 79.9 °C

Without hysteresis, this could result in:

Normal → Alarm → Normal → Alarm → Normal

A large number of events can therefore be generated within just a few seconds even though the actual condition of the system has hardly changed.

The problem does not only affect the display

Each state change can additionally:

• generate an MQTT alarm,
• write a historian entry,
• send an email,
• generate a push notification,
• create a ticket,
• start an escalation.

A small measured-value fluctuation can therefore result in an operational alarm flood.

Setting the alarm limit correctly

Before considering hysteresis or delays, the alarm limit itself must first be selected appropriately.

It should not simply be derived from the normal operating point.

For example, a distinction should be made between

normal operating range

permissible fluctuation

range with increased wear

action limit

technical or safety-related limit

Example: bearing temperature

Normal:

55 … 65 °C

temporarily permissible:

up to 70 °C

Maintenance indication:

75 °C

Alarm:

85 °C

An alarm limit of:

66 °C

might be technically measurable in this example, but it would continually classify normal process operation as abnormal.

Using hysteresis and deadband correctly

Hysteresis ensures that different measured values are used for activating and resetting an alarm.

For a high alarm, for example:

Alarm ON at ≥ 100 bar

and:

Alarm OFF only at ≤ 95 bar

The hysteresis is then:

5 bar

In simplified form

for a high alarm:

Reset limit = alarm limit − hysteresis

For a low alarm:

Reset limit = alarm limit + hysteresis

Hysteresis prevents chattering around the limit

After an alarm has been activated, the measured value may fluctuate within the deadband without immediately resetting the alarm.

This means that:

99.9 → 100.1 → 99.8 → 100.2 bar

does not necessarily result in a repeated sequence of alarm messages.

Deadband and hysteresis are often used synonymously

In many alarm functions, the alarm deadband describes the required signal change from the alarm limit back toward the normal range before the alarm returns to normal.

The exact configuration, however, depends on the PLC, edge platform or software being used.

Practical example of a high alarm with hysteresis

A hydraulic system has a high alarm at:

250 bar

Hysteresis:

10 bar

Alarm activation

As soon as the measured value reaches:

≥ 250 bar

the alarm becomes active.

Reset

The alarm only returns to normal when the pressure drops to:

≤ 240 bar

.

Between 240 and 250 bar

the most recently reached state remains active.

Small pressure fluctuations directly around the alarm limit therefore cannot cause continuous switching between states.

Delay-On: using an on-delay correctly

An on-delay means that the measured value must meet an alarm condition for a specified minimum period before an alarm is actually generated.

Example

Alarm limit:

80 °C

Delay-On:

10 s

An alarm is therefore not triggered immediately at:

80.1 °C

.

The value must first remain continuously in the alarm condition for:

10 s

.

A short excursion

of, for example:

3 s

is not output as an alarm.

Delay-On is useful

when short-term limit violations:

• occur as part of the process,
• do not require operator action,
• are not relevant to the monitored condition.

However, Delay-On must not be used

to artificially delay a required rapid response.

The delay must always be shorter than the period within which the necessary response can still be carried out effectively.

Delay-Off: using an off-delay correctly

With an off-delay, an alarm that is already active remains active for a defined period after the actual alarm condition is no longer fulfilled.

Example

Alarm:

Pressure > 10 bar

Delay-Off:

20 s

If the pressure briefly falls to:

9.9 bar

the alarm is not immediately reset.

It is only reset after the normal condition has remained stable for a sufficient period of time.

Delay-Off can be useful

when a detected condition is considered relevant even if the measured signal briefly returns to the normal range.

This can particularly prevent repeated clearing and reactivation of an already relevant alarm.

Comparing hysteresis, Delay-On and Delay-Off

Function	Acts on	Typical benefit
Hysteresis / Deadband	Measured value	prevents chattering around an analog limit
Delay-On	Time until alarm activation	ignores brief limit violations
Delay-Off	Time until alarm reset	prevents excessively fast resetting and re-alarming
Measured-value filter	Input signal	reduces high-frequency noise

The four functions are not interchangeable.

For example, a noisy sensor signal should not be masked solely by an alarm delay lasting several minutes.

Defining the reset logic

In addition to the activation condition, an alarm strategy always requires a clearly defined reset condition.

Possible variants include

• automatic reset when the value returns to the normal range,
• reset only after the hysteresis threshold has been reached,
• reset only after a minimum period has elapsed,
• manual reset,
• manual reset only after the cause has been eliminated.

Automatic reset

is suitable for many normal condition monitoring alarms.

Manual reset

can be useful if a condition that has occurred once should be deliberately checked even if the current measured value has already returned to normal.

For example:

• overspeed,
• extreme temperature exceedance,
• critical pressure surge,
• dry running,
• one-time protective shutdown.

Do not confuse acknowledgment and reset

Acknowledgment confirms:

The message has been noticed by the operator.

It does not mean:

The cause has been eliminated.

Example

A bearing exceeds the alarm temperature.

The operator acknowledges the alarm.

However, the temperature remains too high.

The condition should therefore continue to be displayed as:

Alarm active

.

The process state only returns to normal once the reset condition has been fulfilled.

When a latched alarm function is useful

With a latched alarm function, the alarm state remains stored even after the original trigger condition has disappeared.

This can be useful

when short-term critical events must remain traceable afterwards.

Example:

Speed > maximum permissible speed

The overspeed occurs for only:

0.5 s

.

The machine then comes to a stop.

A purely automatically resetting display might subsequently only show:

0 rpm

.

The relevant event might therefore no longer be immediately apparent to the operator.

Assigning alarm priorities appropriately

Not all alarms have the same urgency.

Appropriate prioritization is based particularly on:

• possible consequences,
• available response time,
• required operator action.

Example classification

Priority	Example	Response
Information	filter contamination beginning	check during next maintenance
Warning	trend shows significant deterioration	schedule maintenance
Alarm	operating limit exceeded	respond promptly
Critical	immediate risk to the system	immediate response required

If almost every message has the highest priority, prioritization loses its purpose.

Staggering escalation over time

Not every alarm needs to be sent immediately and simultaneously to:

• operator,
• shift supervisor,
• maintenance,
• plant manager,
• external service provider.

An escalation logic could, for example, be

Alarm occurs

→ local display

→ after 5 min without response, message to maintenance

→ after another 15 min, escalation if alarm is still active

The specific times must suit the application.

Important

An escalation delay is not an alarm delay.

The alarm may already be clearly active while only its forwarding to additional recipients is staggered over time.

Do not hide sensor noise with alarm parameters

If a sensor fluctuates strongly, it should first be checked whether the signal is physically plausible.

Possible causes of unstable signals include

• electrical interference,
• poor shielding,
• insufficient grounding,
• mechanical vibrations,
• pressure pulsations,
• unsuitable sensor position,
• air bubbles,
• turbulence,
• unstable process,
• incorrect measuring range.

A large hysteresis can reduce the resulting alarm chattering.

However, it does not eliminate the actual cause of the unstable measured value.

Alarm parameters should meaningfully evaluate a real process – not conceal faulty measurement technology.

Distinguishing between measured-value filtering and alarm hysteresis

A measured-value filter changes the signal on which an alarm may subsequently be calculated.

Hysteresis, on the other hand, only changes the switching conditions of the alarm.

Example of moving-average or low-pass-type smoothing

Raw signal:

49 → 55 → 48 → 52 → 50 bar

Filtered signal:

49 → 51 → 50 → 51 → 50 bar

The evaluated process value itself is therefore already smoothed.

Problem with excessive filtering

Real rapid changes can be displayed with a delay.

Therefore:

• sensor filters,
• PLC filters,
• edge filters,
• alarm delays

should not be connected in series without control.

The resulting total delay must be known.

Using rate-of-change alarms correctly

It is not only an absolute measured value that can indicate a critical condition.

The rate of change can also be relevant.

In simplified form:

Rate of change = Δmeasured value / Δtime

Example

A bearing temperature rises from:

55 °C

to:

70 °C

within:

5 min

The average change is therefore:

3 °C/min

The absolute alarm limit of:

85 °C

has not yet been reached.

Nevertheless, the steep temperature rise may indicate a developing problem.

Rate-of-change alarms also require debouncing

With noisy signals, the numerical derivative can fluctuate significantly.

The following are therefore particularly important:

• suitable time windows,
• plausibility limits,
• filtering,
• minimum duration.

Separating warnings, alarms and critical alarms

A single limit is often not sufficient for condition monitoring.

Example: differential pressure across a filter

< 1.5 bar → normal

≥ 1.5 bar → maintenance indication

≥ 1.8 bar → warning

≥ 2.0 bar → alarm

This allows maintenance to be planned before the process actually reaches a critical limit.

The individual levels do not necessarily require the same logic

A maintenance indication can, for example, use:

• a long delay,
• larger hysteresis,
• no immediate push notification.

A critical alarm, on the other hand, may require:

• little or no delay,
• clear escalation,
• latched notification.

State-dependent alarming

A sensor value should not be evaluated in the same way in every machine state.

Example: pump pressure

During normal operation:

Pressure < 3 bar → possible alarm

With the pump switched off:

Pressure = 0 bar → normal

An alarm rule that evaluates only:

Pressure < 3 bar

would generate an alarm every time the machine is regularly stopped.

An additional condition may therefore be required

Pump running AND pressure < 3 bar

only then:

Low-pressure alarm

Other relevant operating states can include

• startup,
• shutdown,
• production,
• cleaning,
• maintenance,
• standby,
• product changeover.

In complex systems, state-dependent alarming can prevent considerably more unnecessary messages than simply increasing the hysteresis further and further.

Using alarm suppression selectively

Certain alarms may be irrelevant in defined system states.

For example, a stopped machine does not require:

Speed too low

alarming.

Planned suppression can therefore be useful

Typical cases:

• machine out of operation,
• sensor under maintenance,
• startup phase,
• known test operation,
• higher-level fault renders consequential alarms irrelevant.

Suppression must not become a permanent way of hiding problematic alarms

A suppressed alarm should be traceably:

• justified,
• defined by time or operating state,
• logged.

Why alarms should be processed as close to the process as possible

In a typical IIoT architecture, data may follow this path:

Sensor → fieldbus → edge gateway → MQTT → broker → cloud → alarm service

If a critical alarm decision is only made in the cloud, the response time additionally depends on:

• fieldbus cycle,
• gateway processing,
• network connection,
• broker,
• cloud processing.

For time-critical functions

local alarm processing in the:

• sensor,
• IO-Link master,
• PLC or controller, or
• edge gateway

is therefore often useful.

The cloud can subsequently be used for:

• visualization,
• history,
• analysis,
• reporting,
• escalation.

Safety-related shutdowns must not depend on an ordinary cloud connection if a dedicated local protective function is required for this purpose.

Handling timestamps correctly in IIoT systems

For subsequent root-cause analysis, it is not only the alarm itself that is important.

It is also essential to know:

When did the condition actually occur?

Problem

A network connection fails for ten minutes.

The edge gateway buffers measured values locally.

Once the connection is restored, all values are transmitted.

If the cloud were to use only the time of receipt, events that actually occurred ten minutes earlier could appear to have occurred simultaneously.

A data record should therefore preferably contain a clear measurement timestamp

For example:

timestamp = time of acquisition at the edge

and additionally, if required:

received_at = time of receipt in the target system

A synchronized time base is important for multiple devices

This makes it possible, for example, to determine:

Pump fails → pressure drops → flow decreases → temperature rises

rather than merely the order in which the data happened to arrive over the network.

Do not treat communication failures as process alarms

A missing measured value can have various causes:

• sensor defective,
• cable break,
• fieldbus fault,
• gateway offline,
• cellular connection failed,
• broker unavailable.

This is not automatically the same as

Process value = 0

.

A failed level sensor must not automatically be interpreted as:

Tank empty

.

Measured value and quality status should therefore be transmitted separately

For example:

value = 62.3

quality = good

or:

quality = bad

This allows separate alarms to be generated

Level too low

and:

Level measurement unavailable

These two messages have completely different causes and require different responses.

Separating MQTT events and alarms appropriately

In MQTT-based systems, a clear data structure can significantly simplify subsequent evaluation.

For example

site/plant1/line1/device/pump01/pressure/value

site/plant1/line1/device/pump01/status

site/plant1/line1/device/pump01/alarm

Measured-value messages

can be transmitted periodically or when a relevant change occurs.

Alarm events

should instead document a clear change of state.

For example:

alarm_state = active

alarm_state = acknowledged

alarm_state = cleared

This means that the cloud does not have to reconstruct the alarm state that existed at the edge from every individual raw measured value.

Reducing event rate and data volume

A high sampling rate does not automatically mean that every measured value must be transmitted.

Example

Sensor sampling:

10 Hz

This corresponds to:

864,000 measured values per day

per measuring point.

For a slowly changing tank level, this amount of data would often be unnecessary.

Possible strategies include

• longer sampling interval,
• publish-on-change,
• delta threshold,
• periodic heartbeat,
• min/max/average aggregation,
• local trend calculation.

Example: publish-on-change

A measured value is transmitted when:

|xnew − xlast| ≥ Δx

or when:

maximum transmission interval reached

.

This keeps changes visible without continually transmitting identical or almost identical values.

Monitoring alarm quality using key metrics

An alarm concept is not complete after commissioning.

The messages that actually occur should be evaluated.

Useful key metrics can include

• alarms per hour or shift,
• number of recurring alarms,
• most frequent alarm sources,
• number of short-duration alarms,
• average alarm duration,
• number of unacknowledged alarms,
• number of suppressed alarms,
• alarm rate during plant disturbances.

So-called bad actors are particularly interesting

If, for example:

5 out of 500 measuring points

generate more than half of all alarm events, it should first be investigated why these specific measuring points are causing problems.

The cause may be:

• poor configuration,
• unstable process,
• sensor problem,
• missing operating-state logic.

Practical example: differential pressure across a filter

A filter is monitored using a differential pressure sensor.

Normal operation

0.4 … 1.4 bar

Maintenance limit

1.6 bar

Alarm limit

2.0 bar

Problem

Due to pulsating volume flow, the measured value briefly fluctuates by:

±0.08 bar

Unsuitable configuration

Alarm ON at 2.00 bar

Alarm OFF at 1.99 bar

no delay

The alarm can therefore change state several times per minute.

More robust strategy

For example:

Alarm ON at ≥ 2.00 bar

Delay-On = 10 s

Hysteresis = 0.15 bar

Alarm OFF at ≤ 1.85 bar

This means

brief pressure peaks are ignored and an active alarm is only reset once the filter condition has improved significantly.

The specific values must be determined based on the actual process dynamics, permissible filter loading and required response time.

Practical example: temperature monitoring

An electric motor is monitored using a temperature sensor.

Normal:

60 … 75 °C

Warning:

≥ 85 °C

Alarm:

≥ 95 °C

Temperature has comparatively slow dynamics

A single brief measured value of:

95.1 °C

could, for example, be caused by an electrical interference pulse.

An alarm condition such as:

Temperature ≥ 95 °C for 15 s

may be more robust in a corresponding application.

An additional trend warning can also be useful

if, for example, the temperature rises unusually quickly even though the absolute alarm limit has not yet been reached.

Practical example: level measurement with an unstable surface

A radar or ultrasonic sensor measures the level in a vessel.

The measured value can fluctuate due to:

• agitator operation,
• wave movement,
• filling jet,
• foam.

High-level alarm

90 %

Without a deadband:

89.8 → 90.2 → 89.7 → 90.1 %

could result in repeated alarms.

Possible strategy

Alarm ON ≥ 90 %

Alarm OFF ≤ 88 %

and additionally, for example:

Delay-On = 5 s

The values are examples only and must be adapted to the permissible filling level and dynamics of the tank.

Practical example: condition monitoring on a machine

During vibration monitoring, individual peaks can be caused by:

• load changes,
• startup,
• shutdown,
• mechanical impact.

A purely instantaneous limit

can therefore generate a very large number of warnings.

Depending on the measured quantity, the following may instead be relevant

• RMS value,
• peak value,
• trend over several measurements,
• rate of change,
• machine operating state.

A limit violation during normal machine acceleration can, for example, be assessed differently from the same vibration amplitude at a steady rotational speed.

Condition monitoring therefore frequently requires a combination of measured value, time and machine state.

Typical faults in IIoT alarm systems

Observation	Possible cause	Recommended check
Alarm continuously switches on and off	hysteresis too small	analyze measured-value scatter around the limit
Very short alarms occur frequently	missing Delay-On	evaluate duration of actual limit violations
Alarm returns immediately after reset	missing deadband or Delay-Off	check reset logic
Alarm appears significantly too late	excessive filtering or delay	determine total response time of the measurement chain
Many alarms occur during machine startup	operating state not taken into account	use state-dependent enable logic
Process alarms appear during communication failure	missing quality status	separate measured value and communication status
Many alarms arrive simultaneously after a network failure	timestamp generated only in the cloud	generate timestamp at the sensor or edge
One sensor generates a very large number of messages	bad actor	check signal, limit, hysteresis and sensor condition
All messages have high priority	missing alarm rationalization	evaluate consequence and response time for each alarm
Alarm is acknowledged and disappears despite the fault still being present	acknowledgment and reset are linked	separate alarm state and acknowledgment status
Cloud shows a different event sequence than the PLC	different time bases	check NTP/PTP or timestamp concept
Measured value appears stable but alarm still responds late	multiple filters and delays in series	analyze the complete signal chain
Alarm limit constantly needs adjustment	different operating states	check state-dependent alarm limits

Systematically configuring alarm parameters

1. Define the measured quantity: Clearly specify pressure, temperature, level, vibration or another condition variable.
2. Determine the normal range: Evaluate measured data from stable plant operation.
3. Determine measured-value scatter: Distinguish between noise and normal process fluctuation.
4. Define the condition requiring action: Do not classify every deviation as an alarm.
5. Define the alarm limit: Derive the limit from process and plant requirements.
6. Define the response time: Determine how quickly a response to the alarm is required.
7. Dimension the hysteresis: Select it larger than typical small fluctuations around the limit without concealing relevant changes in condition.
8. Check Delay-On: Use only if short-term limit violations do not require action.
9. Check Delay-Off: Prevent excessively rapid resetting and repeated alarming where appropriate for the application.
10. Define the reset condition: Automatic, time-delayed or manual.
11. Define acknowledgment logic: Treat acknowledgment and process state separately.
12. Assign priority: Evaluate consequences and available response time.
13. Consider operating states: Evaluate startup, shutdown, maintenance and production separately.
14. Integrate quality status: Record sensor and communication faults separately.
15. Define timestamps: Generate the event time as close to the source as possible.
16. Define notification: Use dashboard, email, push, SMS or ticket only where they provide a clear benefit.
17. Define escalation levels: Do not notify every person about every alarm at the same time.
18. Evaluate alarm history: Identify frequent and chattering alarms.
19. Eliminate bad actors: Address causes rather than symptoms.
20. Document changes: Keep limits, hysteresis values, times and responsibilities traceable.

IIoT solutions at ICS Schneider

ICS Schneider offers IIoT Solutions ranging from field measurement through to integration into IT and cloud systems.

Typical architecture

Sensor → Edge Gateway → MQTT/HTTPS → SCADA / Cloud / BI

Depending on the measuring point, field devices can be integrated via:

• RS-485 / Modbus RTU,
• HART,
• IO-Link,
• OPC UA,
• Ethernet.

For wireless or remote applications, depending on the architecture, technologies such as:

• LoRaWAN,
• Wi-Fi,
• LTE,
• 5G

can be used.

Edge processing is particularly useful for alarm management

An edge system can, for example:

• scale measured values,
• add timestamps,
• filter data,
• perform plausibility checks,
• generate local alarms,
• buffer data during communication failures.

This means that not every individual raw measured value has to be transmitted unfiltered to the cloud.

IIoT pressure monitoring

Under IIoT Pressure Monitoring, ICS Schneider offers solutions for integrating pressure and differential pressure sensors into edge, SCADA and cloud systems.

Typical applications include:

• filter monitoring,
• pump monitoring,
• compressed-air monitoring,
• process pressure,
• differential pressure.

IIoT temperature monitoring

IIoT Temperature Monitoring connects, for example, RTD, thermocouple and transmitter solutions with edge or cloud systems.

Particularly for:

• motors,
• bearings,
• oils,
• control cabinets,
• process plants

combinations of absolute limits and trend evaluation can be useful for condition monitoring.

IIoT level monitoring

For tank and vessel applications, continuous level values, limits and status information can be integrated into a higher-level IIoT architecture.

Here too, measured value, warning, alarm and sensor status should be clearly separated from one another.

Conclusion

Alarm floods often occur not because too many sensors are installed, but because too many changes in measured values are converted into alarms without appropriate filtering or logic.

The alarm limit alone is not sufficient

A robust alarm function additionally takes into account:

• hysteresis,
• delay,
• reset logic,
• operating state,
• priority.

Hysteresis prevents chattering around the alarm limit

For a high alarm, for example:

Alarm ON at 100

and:

Alarm OFF only at 95

Small fluctuations therefore do not continually generate new alarm state changes.

Delay-On suppresses brief, irrelevant limit violations

The alarm is only activated if the condition remains present for a sufficient period of time.

Delay-Off prevents excessively rapid resetting

An alarm that has already been detected remains active until the normal condition has been stable for a sufficient period.

Acknowledgment and reset are different functions

Acknowledgment confirms that the alarm has been noticed. Reset, on the other hand, confirms that the alarm condition is no longer present or that the defined reset condition has been fulfilled.

In IIoT systems, the data architecture is also part of alarm management

Timestamps, data quality, measured-value status, communication errors and operating states must be modeled correctly so that a sensor message becomes reliable information.

Alarm processing should take place as close to the process as possible

Edge gateways can process measured values locally, evaluate alarm conditions and buffer data during communication failures. Cloud and SCADA systems can then provide history, visualization and escalation based on this information.

For practical applications

Analyze normal operation → determine measured-value scatter → define the condition requiring action → define the alarm limit → determine the required response time → select hysteresis to suit process fluctuations → use Delay-On only for irrelevant short-term violations → define Delay-Off or reset logic → separate acknowledgment and reset → take operating states into account → treat sensor and communication status separately → evaluate alarms locally or at the edge → generate timestamps at the source → define priority and escalation → evaluate alarm history → systematically eliminate frequent bad actors.

FAQ: Avoiding Alarm Floods in Condition Monitoring

What is an alarm flood?

An alarm flood is a situation in which so many alarm messages occur within a short period of time that meaningful processing and prioritization become difficult.

What does alarm flapping mean?

Alarm flapping describes the repeated rapid switching of an alarm between active and normal.

What does chattering alarm mean?

The term describes an alarm that frequently switches on and off due to small signal changes or unsuitable configuration.

What causes alarm flapping?

Typical causes include hysteresis that is too small, a noisy measured signal, an unsuitable alarm limit or missing time delays.

What is alarm hysteresis?

Hysteresis defines the difference between the alarm limit and the value at which an active alarm returns to the normal state.

What is an alarm deadband?

The alarm deadband describes the range within which a small signal change after reaching the alarm limit does not immediately cause another change of state.

Are deadband and hysteresis the same?

In many analog alarm functions, the two terms are used very similarly. However, the exact implementation depends on the respective control or software system.

How does hysteresis work with a high alarm?

The alarm can, for example, be activated at 100 but only reset at 95. The range from 95 to 100 then forms the reset deadband.

How does hysteresis work with a low alarm?

A low alarm becomes active when the measured value falls below the alarm limit and is only reset when the value rises above the alarm limit by the defined hysteresis.

How large should the hysteresis be?

It should sufficiently exceed the normal small measured-value fluctuations, but must not unnecessarily conceal relevant process changes. A universal percentage value is therefore not appropriate.

What does Delay-On mean?

Delay-On is an on-delay. The alarm condition must remain continuously present for a defined period before the alarm is activated.

When is Delay-On useful?

When short-term limit violations occur as part of the process and do not require operator or maintenance action.

Can a long on-delay be dangerous?

Yes. If a rapid response is required, an excessively long delay can cause a relevant alarm to be issued too late.

What does Delay-Off mean?

Delay-Off keeps an already active alarm active for a defined period after the actual alarm condition is no longer fulfilled.

When is Delay-Off useful?

When a detected condition should not immediately be considered normal simply because the measured value briefly moves back beyond the reset limit.

Which is better: hysteresis or Delay-On?

They solve different problems. Hysteresis evaluates the signal level, whereas Delay-On evaluates the duration of a limit violation. They are often used together.

Can I use hysteresis and a delay at the same time?

Yes. For many condition monitoring tasks, a combination of a suitable alarm limit, hysteresis and time persistence is particularly robust.

What does alarm persistence mean?

It describes the requirement that an alarm condition must remain present for a certain period before it is treated as a valid alarm.

What is a latched alarm function?

A latched alarm remains stored even if the original limit violation has already disappeared.

When is a latched alarm useful?

For relevant one-time events that must remain clearly visible after they have ended, such as an overspeed condition.

What is the difference between acknowledging and resetting an alarm?

Acknowledging means that the message has been noticed. Resetting means that the defined condition for returning to the normal state has been fulfilled.

Should an alarm disappear after acknowledgment?

Not if the actual alarm condition is still present. Acknowledgment status and process state should be treated separately.

Why are alarm priorities important?

They help operators recognize which messages are particularly urgent or have particularly serious consequences.

Should every alarm have a high priority?

No. If almost every alarm is assigned the highest priority, prioritization loses its purpose.

What is alarm escalation?

Alarm escalation means that an alarm that remains active or has not been acted upon is forwarded to additional people or systems according to defined criteria.

Is escalation time the same as alarm delay?

No. During escalation, the alarm is already active. Only its forwarding to additional recipients is staggered over time.

What is a bad actor in alarm management?

The term is commonly used for an alarm source that generates a disproportionately large number of messages and should therefore be specifically investigated.

Why should I evaluate the most frequent alarms?

A small number of problematic measuring points often generate a large proportion of all alarm events. Optimizing these points can significantly reduce the alarm rate.

Should I simply increase the hysteresis if a sensor is noisy?

Not without investigating the cause. Strong signal fluctuations can, for example, be caused by EMC problems, installation, pulsations or an unsuitable measuring range.

What is the difference between a measured-value filter and alarm hysteresis?

A filter changes or smooths the input signal. Hysteresis only changes the switching conditions of the alarm.

Can excessive filtering be problematic?

Yes. It can delay real rapid process changes and thereby increase the actual alarm response time.

Why must the complete delay chain be considered?

Sensor filters, PLC cycle time, edge processing, alarm delay and network latency can add together.

What is a rate-of-change alarm?

It monitors not only the absolute measured value but also how quickly the value changes within a defined period.

When is a rate-of-change alarm useful?

When an unusually rapid change already indicates a fault even though the absolute alarm limit has not yet been reached.

Why are rate-of-change alarms sensitive to noise?

Because small rapid measured-value changes can result in large calculated rates of change. Suitable time windows and filters are therefore particularly important.

Why should a condition monitoring system distinguish between warnings and alarms?

A warning can indicate deterioration at an early stage, while an alarm identifies a condition that already requires action.

What does state-dependent alarming mean?

The alarm condition additionally depends on the current machine or process state.

Why is this important when a machine is stopped?

A pressure or speed value that would be abnormal during operation can be completely normal when the machine is switched off.

What does alarm suppression mean?

It describes the defined suppression of an alarm message when it is not relevant in the current plant state.

When can alarm suppression be useful?

For example during maintenance, machine shutdown or certain startup conditions, provided the suppression is deliberately defined and documented.

Can a problematic alarm simply be permanently suppressed?

This should not be used as a substitute for eliminating the cause. Recurring unnecessary alarms should be analyzed and technically corrected.

Why should an alarm preferably be processed at the edge?

Local evaluation reduces dependence on network and cloud connections and can provide clearer timestamps and faster response times.

Does every IIoT alarm have to be calculated in the cloud?

No. Depending on the application, alarm limits can already be evaluated in the sensor, PLC or edge gateway.

Can cloud alarm logic replace a safety-related shutdown?

Not automatically. Required safety-related functions must be independently assessed and implemented in accordance with their intended safety architecture.

Why are timestamps important in condition monitoring?

Only a consistent time base allows reliable reconstruction of which process condition occurred first.

Should the timestamp be generated at the sensor or in the cloud?

For an accurate event sequence, it is useful to generate the timestamp as close as possible to the actual acquisition point. The exact architecture depends on the devices involved.

What does Store-and-Forward mean?

Data is stored locally during an interrupted connection and forwarded with its original time reference once communication has been restored.

Why should a communication error not be interpreted as a measured value of zero?

Because a missing measured value provides no information about the actual process value. Communication status and measured value must be treated separately.

What is a Quality Flag?

A Quality Flag indicates whether a measured value is, for example, valid, uncertain or faulty.

Which protocols are typically used for IIoT?

At field level, Modbus RTU, HART and IO-Link are used, for example. MQTT, HTTPS and OPC UA are among the protocols used for IT or cloud connectivity.

Why is MQTT suitable for IIoT?

MQTT uses a publish/subscribe principle and enables lightweight, decoupled transmission of telemetry and status information.

Does every sensor value have to be transmitted via MQTT?

No. Depending on the process dynamics, publish-on-change, delta thresholds or local aggregation can reduce the data volume.

What does Publish-on-Change mean?

A new value is transmitted only when the measured value changes by at least a defined amount compared with the last transmitted value.

Why should a heartbeat also be transmitted?

So that it remains possible to verify that the device and communication path are still functioning even when the measured value does not change.

What is the difference between sensor sampling frequency and transmission rate?

A sensor can measure internally at a very high frequency while only a portion of those values is transmitted to the cloud. This keeps local responses fast without generating unnecessarily large data volumes.

How can I determine whether my alarm hysteresis is too small?

If many alarm state changes occur even though the measured value only moves slightly around the limit, the measured-value scatter should be analyzed and the hysteresis checked.

How can I recognize excessively large hysteresis?

If an alarm remains active for an unusually long time despite the process having clearly returned to an acceptable condition, the reset limit may be too far away.

How can I recognize an excessively long Delay-On?

If relevant process conditions have already existed for a significant period before the alarm appears, the on-delay should be checked.

How can I recognize a Delay-On that is too short?

If many brief limit violations that do not require action are being alarmed, an appropriate minimum duration may be missing.

Should I use the same hysteresis for all sensors?

No. Pressure, temperature, level and vibration have different dynamics, measurement uncertainties and process fluctuations.

Should I define hysteresis as a fixed value or as a percentage?

This depends on the measuring range and application. The decisive factor is that the resulting deadband matches the actual measured-value scatter and process requirements.

Why should alarm history be reviewed regularly?

Only actual operation shows which alarm sources occur frequently, chatter or provide no practical benefit to the operator.

Which IIoT solutions does ICS Schneider offer?

ICS Schneider offers solutions for integrating sensor technology, edge gateways and IT/OT systems, including pressure, temperature and level monitoring.

Where can I find the IIoT solutions from ICS Schneider?

An overview is available under IIoT Solutions at ICS Schneider.

Where can I find solutions for IIoT pressure monitoring?

Further information is available under IIoT Pressure Monitoring at ICS Schneider.

Where can I find solutions for IIoT temperature monitoring?

Further information is available under IIoT Temperature Monitoring at ICS Schneider.