What Happens When RECD Communication with the DG Controller Fails?

An RECD on a diesel generator is a fairly simple machine at its core. Exhaust gas flows through a filter, soot is captured, and cleaner gas leaves the stack. Around that core, most modern installations add a layer of electronics: a controller that reads pressure and temperature sensors, raises alarms, may manage heaters or regeneration, and shares data with the DG controller, the building management system (BMS) or a remote gateway.

That layer is where the questions arise. What if the cable to the DG controller is cut during maintenance, or the BMS gateway reboots mid-outage, or the serial link goes quiet and nobody notices for a week?

This post walks through an RECD communication failure one path at a time: what breaks, what keeps working and what is lost. We then cover hardwired versus serial signals, fail-safe defaults, detection, what operators see, and an illustrative outage timeline at a Delhi NCR site.

The short version: a well-designed system loses visibility, not filtration, and it tells you quickly that it has gone blind. A poorly designed system can lose both visibility and the warning that visibility has gone.

First, Separate the Filter from the Electronics

Before looking at failure modes, it helps to be clear about what the controller does and does not do. If you need a refresher on the basics, see what an RECD is and how it works.

The filter element works mechanically. Soot is trapped because of the filter’s structure and the gas flow through it, not because a controller instructs it to trap soot. If every wire to the controller were cut, exhaust would still pass through the filter and particulate matter would still be captured.

The controller typically handles four jobs:

1. Monitoring. Reading differential or inlet back-pressure, exhaust temperatures and sometimes run hours or status inputs.
2. Alarming. Comparing readings against thresholds and raising warnings when, for example, back-pressure climbs towards a limit.
3. Active functions (in some designs). Switching heaters, managing an active regeneration cycle or controlling a dosing or bypass function where the design includes one.
4. Reporting. Sharing values and alarm states with the DG controller, BMS, a data logger or a remote platform.

Communication failure affects job 4 directly. It affects jobs 1 to 3 only if the design makes them depend on data arriving from somewhere else. That distinction is the key to everything that follows.

The Three Communication Paths

Most sites have some combination of three paths. Not every site has all three, and the failure consequences differ for each.

Path	Typical medium	What usually travels on it	Who relies on it
A: RECD controller ↔ DG controller	Hardwired contacts, Modbus RTU over RS-485, or CAN in some packages	RECD alarm and shutdown request signals; sometimes DG running status, load or speed back to the RECD	DG controller logic, DG panel display, operators at the set
B: RECD controller ↔ BMS or gateway	Modbus RTU or Modbus TCP, BACnet via a converter, or volt-free contacts	Pressure, temperature, alarm states, run hours, event counters	Facility control room, EHS reporting, trend logs
C: Gateway ↔ remote platform or cloud	Ethernet, 4G router, VPN	Data summaries, alerts by SMS or email, dashboards	Off-site engineers, service vendor, management

A fourth link, the DG controller’s own feed to the BMS, often carries running status and kW. Lose it and you have RECD readings with no idea whether the set was loaded.

For the integration side in more detail, see our guide on integrating RECD monitoring with a building management system.

Failure Mode Walkthrough: Path A (RECD Controller to DG Controller)

This is the most sensitive link because it is the one that can influence whether the generator runs.

What breaks

If the RECD controller sends alarms or a shutdown request to the DG controller over a serial link and that link fails, the DG controller stops receiving updates. What it does next depends entirely on how its logic treats stale or missing data.

There are three common behaviours:

• Hold last value. The DG controller keeps showing the last value it received. If that was “no alarm”, it carries on as if all is well, indefinitely.
• Flag communication fault. The DG controller detects that no valid messages have arrived within a set timeout and raises a “RECD comms fail” warning on its display.
• Treat as fault and act. The DG controller treats missing data as a fault condition and initiates a shutdown or load reduction.

The third option sounds safe but is usually wrong for an emergency standby set. Tripping a hospital generator because a Modbus connector worked loose turns a monitoring fault into a power outage.

What keeps working

• The filter keeps filtering.
• The RECD controller, if it has its own power and sensors, keeps measuring, alarming locally and running any heater or regeneration logic that depends only on its own inputs.
• The engine keeps running under its own protection: oil pressure, coolant temperature, overspeed and other engine-maker protections are unaffected because they live inside the DG controller and engine ECU.

What is lost

• Visibility of RECD status at the DG panel.
• Any RECD-originated shutdown request sent by serial message.
• Any DG data the RECD controller was using, such as “engine running” or load percentage. If the RECD controller uses DG running status to decide when to arm alarms or start a regeneration sequence, it may now be guessing.

This is often overlooked. If your RECD controller suppresses alarms while the engine is stopped using a running signal received by serial message, a dead link can make it misread the engine state. Ask how it behaves when that input goes missing.

Failure Mode Walkthrough: Path B (RECD Controller to BMS or Gateway)

What breaks

The BMS stops receiving fresh values. Depending on the BMS configuration, the graphic may freeze at the last value, show a grey “offline” tag, or show zero. The zero case is the most misleading because a back-pressure of zero can look like “all clear” to an untrained eye.

Trend logs develop a gap. Alarm states stop updating. If the BMS was relaying RECD alarms to the control room or to mobile phones, those notifications stop.

What keeps working

Everything at the generator itself. The RECD controller and DG controller continue as before. If Path A is healthy, the DG panel still shows RECD alarms and any hardwired shutdown request still functions.

What is lost

• Central visibility and remote alerting.
• Historical data for the gap period, unless the RECD controller stores data locally and the BMS can backfill it, which few do.
• Evidence for compliance discussions during a GRAP period.

Our post on detecting missing data in RECD monitoring records covers how to spot and annotate these gaps so they do not look like hidden problems later.

Failure Mode Walkthrough: Path C (Gateway to Remote Platform)

Local monitoring, alarms, BMS graphics and DG panel indications all keep working, but nobody off site can see them and remote alerts stop. Typical causes are weak 4G signal in basements, expired SIM data packs or unannounced firewall changes. For staffed buildings this is a nuisance; at unattended telecom shelters a developing blockage can go unnoticed for days. See remote RECD alerts for unattended sites and whether an RECD needs internet access for how to reduce dependence on this path.

Summary Table: What Fails, What Survives

Failure	Filtration	Local RECD alarms	DG panel RECD indication	Engine protection	BMS view	Remote alerts	Data history
Path A serial link lost	Continues	Continues (if self-powered)	Lost or frozen	Unaffected	Unaffected if Path B direct	Unaffected	Kept locally if controller logs
Path A hardwired signal broken	Continues	Continues	Depends on contact logic (see below)	Unaffected	Unaffected	Unaffected	Kept
Path B lost	Continues	Continues	Continues	Unaffected	Lost or frozen	Lost if relayed via BMS	Gap in BMS trend
Path C lost	Continues	Continues	Continues	Unaffected	Continues	Lost	Gap in cloud data
RECD controller unpowered	Continues	Lost	Lost	Unaffected	Lost	Lost	Gap everywhere

Communication failures remove visibility and alerting, never filtration or engine protection. A design that ties either to a data link needs review.

Note the last row: an unpowered controller looks exactly like a communication failure from outside. See RECD monitoring during power failure for why the controller’s supply source matters during outages.

Hardwired vs Serial Interlocks

Where a signal from the RECD needs to affect the generator at all, the choice between a hardwired contact and a serial message decides how a fault behaves.

Serial (Modbus, CAN)

Serial links carry many values over one cheap cable. Their weakness is that one break, a wrong address, a baud rate change after a firmware update or electrical noise can silence everything at once, and software must notice when messages stop. The Modbus Organization specifications define message framing, not what your DG controller does when messages stop. That is a configuration decision. For register detail, see RECD Modbus data units, scaling and register mapping.

Hardwired (volt-free contacts)

A hardwired contact is one signal on its own pair of wires, easy to test with a multimeter and independent of polling. Its failure behaviour depends on wiring:

• Normally open, closes on alarm. A cut wire looks like “no alarm”. The fault is hidden.
• Normally closed, opens on alarm. A cut wire looks like “alarm”. The fault announces itself.

Normally closed is generally better for alarms because a broken wire becomes visible. But wired to a trip, a broken wire would stop the set, so keep any genuine engine-protection trip on a separately engineered circuit decided with the DG maintainer.

A practical combination

• Hardwired, normally closed “RECD common alarm” contact into a DG controller warning input.
• Hardwired, normally closed “RECD controller healthy” contact (a watchdog relay that drops out if the controller loses power or crashes) into another warning input.
• Serial link for detailed values, used for display and trends only, not for protective action.
• Any back-pressure protection that could stop the engine treated as an engine-protection function, with limits set from the engine maker’s data, not as a serial message from the RECD.

The question of when an RECD condition should do more than raise an alarm is covered in our companion post on RECD alarm vs generator trip and how to define the control response.

Fail-Safe Defaults: What Should Happen When Data Goes Missing

“Fail-safe” means different things for different functions. For an emergency standby generator, the safe state is usually “keep supplying power and tell someone”. For an RECD’s monitoring function, the safe state is “assume nothing, raise a visible fault”.

Function	Recommended default on lost communication	Why
DG start and run permission	Unaffected	Power availability should not depend on a data link
RECD alarm display on DG panel	Show “RECD comms fault”, do not show “healthy”	Avoid false reassurance
BMS graphic values	Mark as stale or offline, never substitute zero	Zero looks like a valid reading
Remote alerts	Send a “communication lost” alert after timeout	The silence itself is information
RECD heater or regeneration logic	Run on local inputs only, or hold off safely	Avoid acting on stale DG status
Data logging	Continue locally if the controller supports it	Preserves evidence for later
Engine trips	Driven only by engine protection inputs, not RECD data	Keeps engine safety independent

These are configuration choices, not automatic behaviours. Agree and record them at commissioning, then test them.

Detection: Heartbeat, Timeouts and Watchdogs

Detected in two minutes, a communication failure is minor. Detected in two weeks, it is a data integrity and compliance problem.

Heartbeat

A heartbeat is a value that changes regularly, such as a counter that increments every second or a status bit that toggles. The receiving system checks that the value keeps changing. If it stops, the link or the sending device has a problem, even if the last values received look perfectly normal.

Heartbeats catch what timeouts miss: a gateway still answering with cached values after losing the RECD controller behind it.

Timeouts

A timeout defines how long the receiver waits without a valid message before declaring a fault. Setting it is a balance:

• Too short (say 2 seconds on a busy RS-485 network) and you will get nuisance alerts from normal polling delays.
• Too long (say 30 minutes) and a failure goes unnoticed through most of a short outage.

For a typical site, a timeout in the range of 30 to 120 seconds for the BMS and a few minutes for remote platforms is a reasonable starting point, but this depends on polling rates and network design. Nuisance alarm risk is real, and our post on reducing nuisance RECD alerts without hiding real faults covers how to tune these.

Watchdog relays

A watchdog relay is a hardwired output that the controller keeps energised while it is healthy. If the controller loses power, freezes or reboots, the relay drops out. Wired normally closed into the DG controller or BMS, it provides a “controller healthy” signal that does not depend on any data link.

The broader principle, that alarm systems need their own health monitoring, is part of standard alarm management practice described in the ANSI overview of ISA-18.2.

What Operators Actually See

Operators see symptoms, not “Modbus timeout”. Training should map one to the other.

What the operator sees	Likely cause	First check
BMS back-pressure value flat for hours while DG is on load	Frozen value from lost link, or gateway returning cache	Compare with RECD controller local display
BMS shows back-pressure 0 with DG running	Link lost and BMS substituting zero, or sensor fault	Check comms status tag, then sensor
DG panel shows “RECD comms fault”	Path A serial link broken	Inspect connector and cable at both ends
DG panel shows “RECD alarm” with no matching local alarm	Normally closed contact circuit open (cut wire or loose terminal)	Check continuity of alarm circuit
No remote alerts during a long outage	Path C lost, or gateway unpowered	Check router and gateway power and signal
RECD local display blank	Controller unpowered	Check supply breaker and source

The first row is the most dangerous because nothing looks wrong, yet real back-pressure always moves with load and temperature. See separating a sensor fault from an RECD performance problem.

Give communication faults their own row in your RECD alarm response matrix for operators.

Worked Example: A Communication Failure During a Grid Outage (Illustrative)

The following timeline is illustrative. It describes a hypothetical commercial office building in Gurugram with one 750 kVA DG set fitted with an RECD. The RECD controller sends values to a BMS gateway over Modbus RTU and has two hardwired, normally closed contacts to the DG controller: “RECD common alarm” and “RECD controller healthy”. Remote alerts go via a 4G router.

Site setup (illustrative):

• BMS comms timeout: 60 seconds
• Remote platform offline alert: 5 minutes
• RECD controller supply: from DG-backed UPS distribution board
• Typical back-pressure at 60% load: around 6–8 kPa (illustrative figure; actual values depend on engine and RECD size)
• Engine maker’s maximum exhaust back-pressure: assumed 10 kPa for this example

Timeline (IST):

Time	Event	What the systems show
14:02	Grid fails. DG starts, takes load at about 55%	All normal. Back-pressure rising from 1 to 6 kPa as load and temperature build
14:20	An electrician working in the BMS panel disturbs the RS-485 connector on the gateway	Gateway stops receiving from RECD controller
14:21	BMS timeout expires	BMS graphic shows RECD values as “stale”; comms fault alarm in BMS
14:21	Gateway continues forwarding cached values to remote platform	Remote dashboard still shows 6.4 kPa, apparently healthy
14:25	Remote platform has no heartbeat change for 5 minutes	Remote “RECD data stale” alert sent to the facility engineer’s phone
14:26	DG panel	Both hardwired contacts healthy; no RECD alarm. Operator confirms RECD local display shows 6.6 kPa
14:40	Facility engineer calls control room; operator records reading from local display every 15 minutes in log book	Manual readings: 6.7, 6.9, 7.0 kPa
15:55	Back-pressure reaches 8.2 kPa as load rises to 70%	RECD controller raises local high back-pressure warning; normally closed alarm contact opens; DG panel shows “RECD alarm”
15:57	Operator checks response matrix: warning level, not engine limit. Reduces non-essential load (chillers on staged shutdown)	Back-pressure stabilises around 7.8 kPa
16:30	Grid returns. Load transferred back. DG runs cool-down and stops
16:50	Technician reseats connector; BMS data resumes	Trend shows gap 14:20 to 16:50, annotated with manual log readings

What went right:

• The filter kept working throughout. No filtration was lost.
• The hardwired contacts did not depend on the serial link, so the developing high back-pressure was still reported to the DG panel.
• The heartbeat check caught the gateway’s cached values within five minutes. Without it, the remote dashboard would have shown a reassuring but false 6.4 kPa for the rest of the outage.
• The operator had a written response and a manual logging fallback.

With a weaker design, a normally open contact on a disturbed cable would have hidden the 15:55 warning, and a DG controller set to trip on comms loss would have dropped the building’s backup power at 14:21.

Data gap (illustrative): the BMS gap of 2 hours 30 minutes was covered by 9 manual readings, enough to show the trend and the warning. Record the cause, duration and manual source in the RECD event log.

How to Test a Communication Failure Safely

Testing is the only way to know the defaults behave as written. Use operational technology good practice, such as NIST SP 800-82 Rev. 3, to keep test and remote access paths controlled.

1. Agree the window. Grid available, DG on a planned test run, control room informed.
2. Record baseline on the RECD display, DG panel and BMS.
3. Break Path B. Disconnect the gateway’s RS-485 connector. Time the BMS stale flag and comms alarm; confirm no zero substitution.
4. Check Path C. Confirm the remote stale data alert arrives on time.
5. Break Path A serial (if used). Confirm the DG panel shows a comms fault and does not trip or block the set.
6. Lift one wire of the hardwired alarm circuit. Confirm an alarm is shown.
7. Remove controller power. Confirm the “controller healthy” signal drops out and is announced.
8. Restore everything. Confirm values resume, and note whether any backfill occurs.
9. Record results and repeat annually and after any controller, BMS, firmware or network change.

FAQ

Does the RECD stop reducing emissions if communication with the DG controller fails?

No. The filter captures particulate matter mechanically. Only monitoring, alarms and reporting are affected, plus any active function that depends on DG data.

Should the generator trip if it loses communication with the RECD controller?

For emergency standby sets, generally no. A data link fault is not an engine fault. Engine-protection trips, such as excessive back-pressure above the engine maker’s limit, should be decided with the DG maintainer and engine maker and engineered independently of serial data.

Why does my BMS show zero back-pressure when the DG is running?

Often because the BMS substitutes zero when it loses communication. It can also indicate a sensor fault. Check the comms status first, then the RECD controller’s local display, then the sensor.

How quickly should a communication failure be detected?

For most sites, within one or two minutes at the BMS and within five to ten minutes for remote platforms. Unattended sites may justify shorter remote timeouts. Balance speed against nuisance alerts from normal polling delays.

Related Reading

• RECD Alarm vs Generator Trip: How to Define the Control Response
• How to Reduce Nuisance RECD Alerts Without Hiding Real Faults
• How to Preserve RECD Data When Replacing a Controller
• Who Should Have Access to RECD Controller Settings?
• How Exhaust Backpressure Affects a DG Set

Talk to Aceget About Your RECD Integration

Aceget supplies CPCB type-approved Retrofit Emission Control Devices for DG sets from 25 kVA to 2500 kVA. If you are planning how your RECD will connect to the DG controller, BMS or remote monitoring, and want to agree fail-safe behaviour before installation, review our certifications and contact our team to discuss your site.