How to Reduce Nuisance RECD Alerts Without Hiding Real Faults

An alert system that fires forty times a week teaches operators exactly one lesson: ignore it. Within a month, the RECD alarm on the BMS screen becomes background noise, the SMS group gets muted, and the one alert that actually matters (back-pressure climbing towards the engine maker’s limit, or a heater circuit that has quietly failed) is acknowledged without anyone reading it.

That is the real cost of nuisance RECD alerts. They do not just waste time. They erode trust in the whole monitoring system, and they make it more likely that a genuine fault goes unnoticed until it shows up as a sealed DG set, a failed inspection or an engine problem.

The fix is not to turn alerts off. It is to work in order: diagnose where the noise comes from using numbers rather than impressions, trace each source to its root cause, fix it with the right technique, and guard the result so that reducing noise never means hiding a real fault. This guide follows that sequence, and finishes with an illustrative before-and-after example from a typical site.

Why Nuisance Alerts Are a Safety Problem

Alarm-management practice in process industries, set out in ANSI/ISA-18.2, starts from a simple principle: every alarm should demand a response from an operator, and every alarm should be meaningful when it arrives. An alarm that fires when no action is needed is not “extra safety”. It is a defect, because it consumes attention that a real alarm needs.

For an RECD on a DG set, the consequences of alert fatigue are specific:

• A back-pressure trend that genuinely needs a cleaning or regeneration gets missed, and the engine runs against higher resistance than it should (see how exhaust back-pressure affects a DG set).
• During a GRAP period, when the site may need to show that its RECD is working, there is no clean record to point to, because the event log is full of noise.

So the goal is not “fewer alerts”. It is fewer alerts that do not need action, with no loss of alerts that do.

Stage 1: Diagnose

Do not start changing setpoints on gut feel. Before you touch anything, measure the alert load for at least two to four weeks of normal operation, ideally including both grid-outage runs and routine test runs. Your RECD controller’s event history, the BMS alarm journal, or the SMS/email gateway log will usually have what you need. If your records are patchy, the guide on what an RECD event log should record explains what to capture going forward.

Metric 1: Alerts per run-hour

Raw alert counts per week are misleading on a DG set, because run time varies enormously.

Divide the number of alerts by the DG run-hours in the same period. Separately, count alerts that occurred while the DG was stopped., because for most RECD measurements these should be close to zero.

Metric 2: Chattering and fleeting alarms

A chattering alarm is one that goes into alarm, clears, and returns repeatedly within a short time. A fleeting alarm is one that activates and clears within seconds, before anyone could have responded.

A practical test: flag any alarm that triggers three or more times within a few minutes, and any alarm whose active duration is shorter than, say, 10 seconds. These are almost always caused by a signal hovering around a setpoint, electrical noise, or a transient during start-up or load steps. They are the easiest wins.

Metric 3: Standing alarms

A standing (or stale) alarm stays active for hours or days. On RECD systems the usual culprits are a sensor fault left unrepaired, an alarm that is active whenever the DG is off, or a “service due” reminder configured as an alarm.

When a point is permanently red, operators stop looking at it, so a second, real condition on the same point becomes invisible.

Metric 4: Top contributors

Rank alarm tags by how many activations each produced. On almost every site, a small number of tags generate most of the noise. Fix those first.

Diagnostic summary table

Metric	How to calculate	What it usually tells you	Illustrative healthy target
Alerts per run-hour	Alerts ÷ DG run-hours in the period	Overall noise level, normalised for usage	Well under 1 per run-hour for RECD alerts
Alerts while DG stopped	Count of alerts with DG status “off”	Missing state-based suppression	Near zero, except genuine sensor or power faults
Chattering count	Tags with 3+ activations within a few minutes	No deadband or delay; noisy signal	Zero chattering tags
Fleeting count	Activations lasting under ~10 seconds	Transients during start or load steps	Very few
Standing alarms	Alarms active longer than 24 hours	Unrepaired faults or misclassified reminders	Zero, or each one has a dated action
Top-5 share	% of all activations from the 5 noisiest tags	Where to focus first	Falls sharply after fixes

These targets are illustrative, not taken from a standard. Set your own in the site’s alarm philosophy.

Build an alarm inventory

Alongside the numbers, list every RECD-related alarm point: its name, source (RECD controller, DG controller, BMS calculation), setpoint, delay, priority, who receives it, and what the operator is supposed to do. If you already have an RECD alarm response matrix for operators, start from that. If an alarm has no defined response, that is your first clue that it may not need to be an alarm at all.

Stage 2: Find the Root Causes

Cause 1: Thresholds that are not load-aware

Exhaust back-pressure and temperature both depend strongly on engine load. A fixed back-pressure alarm set at a value that makes sense at 80% load will either fire constantly during heavy runs, or never fire at light load even when the filter is substantially loaded.

Many sites set one number at a high-load commissioning point and never revisit it. The guide on comparing RECD pressure readings at different generator loads explains why a single reading means little without the load beside it.

Cause 2: No on-delay, no deadband

When a DG starts, picks up a block load, or sheds load, exhaust flow changes quickly and pressure spikes briefly. An alarm with no on-delay will catch every one of those spikes. And a signal that hovers near a setpoint without any deadband (hysteresis) will chatter in and out of alarm as it wobbles by a fraction of a unit.

Cause 3: Alarms active while the DG is stopped

Low exhaust temperature, low differential pressure and “no flow” type alarms will naturally be active whenever the engine is off. If the alarm logic does not know the DG’s run status, these become standing alarms for the 95% or more of the week that a standby set is idle.

Cause 4: Sensor and wiring faults

A failing pressure transmitter, a loose terminal, a damaged cable near the hot exhaust or a blocked sensing line can produce readings that jump, drift or sit at an impossible value. These generate noisy “process” alarms when the real problem is instrument health. The guide on how to separate a sensor fault from an RECD performance problem covers the diagnostic steps.

Cause 5: Duplicate alerts

On a typical Indian commercial site, one condition can produce four or five notifications: a local alarm on the RECD controller, a mapped alarm on the BMS, a separate BMS calculated alarm on the same value, an SMS from the gateway, and an email digest. The guide on integrating RECD monitoring with a BMS covers how to decide which system “owns” each alarm.

A related duplicate is the cascade: a communication loss between the RECD controller and the BMS makes every mapped point go “bad quality” at once, generating a flood. One root cause should produce one alert. See the sibling post on what happens when RECD communication with the DG controller fails.

Cause 6: Normal regeneration treated as a fault

In RECD designs that regenerate actively, temperature and pressure behave differently during a regeneration event. If the alarm logic does not recognise the event, it can raise “high temperature” or “pressure change” alerts for what is normal operation. The background in DieselNet’s overview of DPF regeneration helps explain why, and what to record during regeneration helps you document the expected pattern.

Stage 3: Fix

Each root cause has a matching technique. Read the “risk” column carefully: every one of these tools can hide a real fault if applied carelessly.

Technique	What it fixes	Typical use on an RECD	Risk if misapplied
On-delay timer	Fleeting alarms from transients	Back-pressure high must persist 30–120 s before alarming	Delay too long hides a fast-developing problem
Off-delay timer	Chattering on clear	Alarm stays active 30–60 s after the value returns to normal	Operator sees an alarm briefly after it has cleared
Deadband (hysteresis)	Chattering around a setpoint	Alarm at 100%, clear only below 95% of setpoint	Too wide a band delays a genuine clear
State-based suppression	Alarms that are meaningless when DG is off	Suppress low-temperature and low-ΔP alarms unless DG running and warmed up	Suppressing on the wrong condition hides alarms when they matter
Grouping / first-out	Cascades and duplicates	One “RECD comms lost” alert instead of 15 bad-quality points	Group hides which sub-condition is active, unless drill-down exists
Load-aware limits	Fixed thresholds that fit only one load	Back-pressure limit as a function of kW band	Wrong load signal makes limits wrong
Shelving with expiry	A known, temporary nuisance while repair is pending	Shelve a failed sensor’s alarm for 72 h until replacement	Shelving without expiry becomes permanent suppression

Delay timers

Use an on-delay where a condition must persist to be meaningful. A back-pressure excursion that lasts four seconds during a block load is not a filter problem. One that lasts three minutes at steady load may be.

Set the delay from data: find how long start-up and load-step spikes last in your traces, and set the on-delay comfortably longer, while keeping it short relative to how fast a real problem could develop. For soot loading, which builds over hours, a delay of one or two minutes costs nothing in safety. For something that could damage the engine quickly, a delay must be agreed with the DG maintainer.

Off-delays keep the alarm latched briefly after it clears, so it does not bounce off and on.

Deadband

Deadband means the alarm activates at one value and only clears at a slightly lower (for a high alarm) value. Look at the normal fluctuation of the signal in steady running, and set the deadband a little wider than that.

State-based suppression

This is often the single biggest improvement on standby DG sets. Tie the RECD alarms to the DG’s run status and, where relevant, to a warm-up timer. For example: “Exhaust temperature low” is only evaluated when the DG has been running for more than 10 minutes and is above a minimum load.

Critically, suppression should apply only to alarms that are genuinely meaningless in that state. A heater circuit fault, a controller power failure or a sensor open-circuit is still worth knowing about when the DG is off, because you want to find out before the next grid outage, not during it.

Grouping and first-out

Where many points share a root cause, raise one alert for the cause and keep the detail available on the dashboard. A communication loss is the clearest case: one high-priority “RECD data link lost” alert, with individual points shown as bad quality on screen but not sent as separate notifications.

“First-out” logic is useful where one fault triggers others. If back-pressure rises and then a derived “filter efficiency estimate” alarm follows, the first event is the one the operator needs. Display design matters here; ISA-101 HMI guidance and the post on what an RECD operating dashboard should show cover how to present grouped alarms clearly.

Load-aware limits

If your DG controller or BMS can read kW, use it. Instead of one back-pressure limit, define limits by load band, for example under 40% load, 40–70% and above 70%. Each band gets a limit based on the clean-filter baseline at that load plus an agreed margin. This makes the alarm fire on the condition of the filter rather than on the size of the load.

Two cautions. First, the absolute engine-protection limit (the back-pressure the engine maker allows) does not scale down at light load. Keep it as a separate, fixed alarm. Second, if the kW signal is lost, the logic must fall back to the most conservative limit rather than silently disabling the alarm.

Shelving with expiry

Shelving lets an operator temporarily remove a specific known nuisance from the active list, for example while waiting for a replacement transmitter. ISA-18.2 treats shelving as a controlled action, and the important features are:

• It applies to one named alarm, not a whole group.
• It has a mandatory expiry (for example 8, 24 or 72 hours), after which the alarm returns automatically.
• It records who shelved it, when, and why.
• It cannot be applied to engine-protection alarms.

If your RECD controller or BMS cannot do timed shelving, a paper or spreadsheet shelving register with a daily review is a reasonable substitute. What is not acceptable is disabling the alarm in configuration and relying on someone to remember to re-enable it.

Stage 4: Guard

Every technique above trades some sensitivity for less noise. The guard stage stops that trade from hiding real faults.

Rule 1: Never suppress engine-protection alarms

Some limits exist to protect the engine: typically back-pressure at or near the engine maker’s maximum, and in some designs a very high exhaust temperature. These alarms should have no state-based suppression beyond “DG running”, no shelving, and only the minimum delay agreed with the DG maintainer and engine maker. Whether they also trigger a shutdown or only a high-priority alarm is a separate decision, covered in the sibling post on RECD alarm vs generator trip.

Mark these alarms clearly in the alarm inventory as “protected”, so that nobody rationalises them away during a noise-reduction exercise.

Rule 2: Keep a written alarm philosophy

Write a short document (two or three pages is enough for one site) that states what qualifies as an alarm, how priorities are assigned, who receives each priority, what delays and deadbands are permitted, and which alarms are protected. This is the core of the ISA-18.2 approach, scaled down to a DG room.

Rule 3: Review shelved and suppressed alarms on a schedule

Weekly, someone responsible should check the shelving register and any alarms with active suppression. For each one: is the reason still valid, is the repair on track, and has the expiry been respected? Monthly, look again at the diagnostic metrics from Stage 1 to make sure the noise has not crept back.

Rule 4: Test that real faults still get through

After any change, prove it. Practical tests on an RECD system include:

• Simulate a high back-pressure signal (using a calibrator on the transmitter loop, or a test input on the controller) at steady load and confirm the alarm arrives after the expected delay, at the right priority, to the right people.
• Disconnect a sensor and confirm a sensor-fault alert is raised even with the DG stopped.
• Interrupt the controller-to-BMS link and confirm one grouped alert is received, not a flood and not silence.
• Start the DG and confirm that start-up transients no longer produce fleeting alarms.

Record the results with date, time and who witnessed the test. The guide on installed RECD sensor calibration documentation suggests a suitable record format.

Worked Example: Before and After (Illustrative)

The numbers below are illustrative, based on a typical pattern rather than a specific site.

Site: A commercial office building in Gurugram with one 750 kVA standby DG set fitted with an RECD. RECD alarms are mapped to the BMS, which sends SMS alerts to the facility team and the DG maintainer.

Diagnostic period: Four weeks in late summer. The DG ran 62 hours in total: 4 weekly test runs of about 30 minutes each and a series of grid outages making up the rest.

Before: 412 RECD-related alerts in four weeks, about 6.6 per run-hour. Of these, 188 occurred while the DG was stopped. The team had muted the SMS group by week two.

Alarm tag	Activations (4 weeks)	Root cause found	Fix applied	Activations after (4 weeks)
Exhaust temp low	151	Active whenever DG stopped and during warm-up	State-based suppression: evaluate only when DG running > 10 min and load > 25%	2
Back-pressure high (warning)	96	Fixed limit set at a full-load test point; spikes on block loads	Load-aware limits in three bands; 60 s on-delay; 4% deadband	3
BMS comms bad quality (per point)	84	Gateway dropped link briefly; 14 points each raised an alert	Grouped into one “RECD data link lost” alert with 30 s delay	4
ΔP sensor fault	37	Intermittent loose terminal at the transmitter	Terminal re-made and cable re-routed away from hot pipe; alarm shelved for 48 h during repair	0
Back-pressure high (BMS calculated duplicate)	29	Second alarm on the same value created by BMS integrator	Removed; RECD controller alarm is the single source	0
Heater circuit fault	9	Genuine: heater contactor failing	No change; contactor replaced	1 (the genuine test after repair)
Back-pressure engine-protection limit	0	Protected alarm	No change; tested by simulation	0 (test confirmed it works)
Other	6	Mixed	Reviewed individually	4
Total	412			14

After: In the next four-week period, with a similar 58 run-hours, the site recorded 14 alerts, about 0.24 per run-hour. Alerts with the DG stopped fell from 188 to 3, and all three were genuine (two link-loss events and one heater check during maintenance).

What did not change: The heater circuit fault, which was a real problem, still came through. The engine-protection back-pressure alarm kept its original setpoint and minimal delay, and a simulated test confirmed it reached the BMS and the SMS group within the expected time. The SMS group was unmuted, and in the following weeks the team responded to every alert.

The point: The 97% reduction came from fixing alarms evaluated in the wrong state, a threshold that ignored load, and duplication, not from making the system less sensitive to faults.

Frequently Asked Questions

Can I just raise all the alarm setpoints to stop the noise?

No. Raising setpoints across the board reduces noise by reducing sensitivity, which is exactly how real faults get hidden. Most nuisance alerts come from timing, state and duplication problems, not from setpoints that are too low. Fix those first, and only adjust a setpoint when the data shows it was wrong for the operating conditions.

How long should an on-delay be for an RECD back-pressure alarm?

It depends on how long normal transients last on your set. Look at the pressure traces during starts and load steps, and set the delay a little longer than the longest normal spike. For warning-level soot loading alarms, delays of 30 to 120 seconds are common. For engine-protection limits, agree the delay with the DG maintainer and engine maker and keep it as short as practical.

Should RECD alarms be suppressed completely when the DG is off?

Only the ones that are meaningless when the engine is stopped, such as low exhaust temperature or low differential pressure. Alarms about the health of the system itself, such as sensor faults, controller power loss, heater circuit faults or communication loss, should remain active, so you find out before the next outage.

What is the difference between shelving and disabling an alarm?

Shelving is temporary, logged and time-limited: the alarm returns automatically after a set period. Disabling is a configuration change that stays in place until someone reverses it. Shelving is a controlled tool for known nuisances during repair. Disabling should be rare, approved, and recorded under change control.

Related Reading

• RECD Alarm vs Generator Trip: How to Define the Control Response
• RECD Alarm Response Matrix for Operators
• How to Separate a Sensor Fault from an RECD Performance Problem
• What Happens When RECD Communication with the DG Controller Fails?
• Who Should Have Access to RECD Controller Settings?

Get Reliable RECD Monitoring from the Start

Good alarm behaviour is easier to build in at specification and commissioning than to fix later. Aceget supplies CPCB type-approved Retrofit Emission Control Devices for DG sets from 25 kVA to 2500 kVA, and can help you plan monitoring and alarm points around your site’s operating pattern. Review our certifications or contact our team to discuss your DG set.