- October 19, 2026
- Posted by: editor
- Category: RECD & Emission Control Devices
At an unattended site, there’s no operator to notice a strange smell, hear a change in exhaust note or glance at the Retrofit Emission Control Device’s display. Water pumping stations, telecom towers, warehouses at night, rural bank branches and solar-hybrid sites all fit this pattern. The diesel generator may run for hours with nobody within kilometres.
If the RECD develops a problem, such as rising back-pressure, failed regeneration or a cracked substrate, the only way anyone finds out in time is a remote alert. And a remote alert is only useful if it reaches the right person, through a channel that works, with enough information to act, and with a fallback if that person doesn’t respond.
This guide walks through setting up remote RECD alerts for an unattended site, from choosing what to alert on to testing the whole chain end to end.
Why Unattended Sites Need a Different Approach
At a staffed building, an RECD alarm appears on a Building Management System screen and someone in the control room sees it within minutes. At an unattended site:
- Nobody is watching. Every alert has to be pushed to a person.
- Travel time is long. A technician may be an hour or more away, so remote diagnosis matters.
- Communication can fail. Mobile networks drop, power fails and gateways freeze. Silence can mean “all is well” or “nothing is working.”
- The DG often runs during wider outages, when networks are busiest and people are already dealing with other problems.
The design goal is simple to state: the right person learns about a real problem quickly, and also learns if the alerting system itself has stopped working.
Step 1: Decide What Deserves a Remote Alert
Not every RECD alarm should wake someone at 3 a.m. Start from your alarm response matrix (see how to design an RECD alarm response matrix for operators) and sort each item into one of three groups:
| Group | Examples | Remote handling |
|---|---|---|
| Immediate | High engine back-pressure; high RECD outlet temperature; DG running with RECD controller offline | Push alert to on-call person at any hour, with escalation |
| Same day | High ΔP critical; regeneration failed; low ΔP (possible crack); heater fault | Push alert during working hours; batch at night unless repeated |
| Report only | High ΔP warning; regeneration overdue; minor sensor drift | Daily or weekly summary email |
At an unattended site, add two alert types that a staffed site might not need:
- DG running notification, so someone knows the set has started and the RECD is now working. This is useful for correlating any later alerts.
- Monitoring system health, meaning loss of communication, gateway power loss or a stale heartbeat (see Step 5).
Step 2: Choose the Alert Channels
Common options, with their strengths and weaknesses:
| Channel | Strengths | Weaknesses | Best for |
|---|---|---|---|
| SMS | Works on basic phones; doesn’t need data; reliable in most areas | Limited text length; delivery can be delayed when networks are congested | Immediate alerts to on-call staff |
| Automated voice call | Hard to ignore; can request acknowledgement by keypress | Needs a voice-calling service; intrusive | Critical alerts at night |
| Mobile app push | Rich detail; easy acknowledgement | Needs data connection and app; notifications can be silenced | Teams with smartphones and a platform |
| Detailed; good for records | Easily missed; slow to notice | Same-day and summary alerts | |
| Messaging-app groups | Fast and familiar | Hard to track acknowledgement; risk of alert fatigue in busy groups | Supplementary awareness, not primary alerting |
| Network operations centre (NOC) | Staffed around the clock; integrates with other site alarms | Needs an existing NOC | Telecom, utilities, multi-site portfolios |
Use at least two channels for immediate alerts, for example SMS plus a voice call, or app push plus SMS. If one fails, the other gets through.
Step 3: Choose How Alerts Leave the Site
The alert has to get from the RECD controller to the outside world. Typical paths:
- A cellular gateway reads the RECD controller (often by Modbus or dry contacts) and sends alerts through the mobile network, either directly as SMS or through a cloud platform
- An existing site telemetry unit, as used on telecom towers and water utility sites, with RECD signals added to its inputs
- The site’s internet connection, through a gateway or controller that sends alerts to a cloud service
Each has security and reliability trade-offs. We compare them in does an RECD need internet access to operate. At unattended sites, an outbound-only cellular gateway or an existing, already-secured telemetry system is often the most practical.
Signal strength matters
DG rooms and enclosures are often metal boxes, sometimes in basements. Check mobile signal at the gateway location before installation. If it’s weak:
- Mount an external antenna outside the enclosure
- Consider a gateway that supports more than one network operator (dual SIM)
- Place the gateway where signal is good and run a cable back to the controller. See RECD cable routing near hot exhaust lines
Power for the alerting equipment
The gateway must be powered whenever the DG runs, which at an unattended site usually means during a grid outage. Feed it from the DG-backed supply with battery backup, so it can still report if the DG itself fails. See RECD monitoring during a power failure: what should stay available.
Step 4: Build an Escalation Ladder
An alert that reaches one person who’s asleep, on leave or out of signal isn’t an alert. Build an escalation ladder with timers:
| Time after alert | Action |
|---|---|
| 0 min | SMS and app push to on-call technician |
| 10 min (if not acknowledged) | Automated voice call to on-call technician |
| 20 min (if not acknowledged) | SMS and voice call to backup technician |
| 40 min (if not acknowledged) | Call to maintenance supervisor or site manager |
| 60 min (if not acknowledged) | Alert to RECD supplier service line and NOC (if any) |
Timings depend on how critical the site is. A hospital’s remote annexe needs a faster ladder than a rural warehouse.
Acknowledgement and closing the loop
The system should let the recipient acknowledge an alert, by replying to an SMS, pressing a key on a voice call or tapping a button in an app. Acknowledgement:
- Stops further escalation
- Records who took responsibility and when
Acknowledgement isn’t resolution. Add a “cleared” message when the condition returns to normal, and require the responder to record what was done, either in the platform or in a simple log. That record becomes part of the device’s event history. See what should an RECD event log record.
On-call rosters
Escalation ladders fail when the roster is out of date. Assign someone to update it whenever staff change, go on leave or change phone numbers. Many alert platforms support rosters directly. For simpler set-ups, a monthly check of the contact list is essential.
Step 5: Watch the Watcher (Heartbeat Alerts)
The most dangerous failure at an unattended site is silence: no alerts, because the alerting system itself has stopped working. A dead gateway, an expired SIM, a tripped breaker or a frozen controller all look exactly like “no problems.”
Guard against this with heartbeat or “dead-man” monitoring:
- The gateway sends a regular “I’m alive” message to the platform, for example every 15 or 30 minutes.
- If the platform doesn’t receive a heartbeat within the expected time, plus a margin, it raises a “site not reporting” alert.
- The controller itself can provide a heartbeat counter that the gateway checks, so a frozen controller is detected even if the gateway is fine. See RECD Modbus data: units, scaling and register mapping explained.
Also set an alert for “DG running but RECD data not received”. This catches the case where the gateway is alive but the RECD controller has lost power or communication.
Step 6: Write Alert Messages That Help Remote Diagnosis
At an unattended site, the first responder decides whether to travel based on the alert message alone. Make every message count.
A poor alert:
RECD ALARM
A useful alert:
[PUMP STN 7 – DG1] RECD back-pressure HIGH: 68 mbar (limit 60). DG running 2h 14m, load 85 kW. ΔP 74 mbar. Outlet 420 °C. Regen: not active. 14 Oct 03:12 IST. Ack: reply 1. Matrix ref: row 4.
A good message includes:
- Site and equipment in plain words
- The condition and its value, with the limit
- Context: DG running time, load and related readings
- Time, with time zone (see how to align RECD sensor timestamps with generator runtime logs)
- How to acknowledge
- A pointer to the response guidance
Keep it within SMS length limits, or send a short SMS with a link to the full details in the platform.
Step 7: Prevent Alert Storms
A single fault can trigger many alarms at once. A blocked RECD, for example, can raise high ΔP, high back-pressure, high outlet temperature and regeneration failure within minutes. At an unattended site, a burst of twenty SMS messages is confusing and expensive, and it trains people to ignore alerts.
Techniques to reduce noise:
- Delays: only alert if a condition persists for a set time, such as 2 minutes
- Grouping: combine related alarms into one message with all values
- Rate limits: no more than one alert per condition per set period, unless it worsens
- Suppression when the DG is stopped: many RECD alarms are meaningless when the engine isn’t running
- Priority filtering at night: send only immediate-group alerts outside working hours
Step 8: Give Responders a Remote Diagnosis Checklist
Before driving to site, a responder can often narrow the problem down remotely, if the platform shows recent data. A short checklist:
- Is the DG running, and at what load?
- When did the condition start, and has it got worse?
- What are ΔP, back-pressure, inlet and outlet temperatures now, compared with normal at this load? See what should a useful RECD operating dashboard show.
- Is a regeneration active, requested or failed?
- Is this a sensor fault (frozen value, out-of-range reading)?
- Is the grid back? Can the DG be stopped safely?
- Following the alarm matrix, does this need a site visit now, today or at the next planned visit?
Record the decision and the reasoning.
Step 9: Test the Whole Chain
Alerts that have never been tested will fail when needed. Test:
| Test | How | How often |
|---|---|---|
| End-to-end alert | Simulate an alarm at the controller, or use a test function; confirm every recipient receives it on every channel | Monthly |
| Escalation | Don’t acknowledge the test alert; confirm escalation steps fire on time | Quarterly |
| Heartbeat loss | Power off the gateway; confirm “site not reporting” alert arrives | Quarterly |
| Controller loss | Disconnect controller power while the gateway runs; confirm alert | Quarterly |
| Power failure | During a planned outage, confirm gateway and alerts survive DG start and transfer | Annually or after electrical changes |
| Roster check | Call each number on the list | Monthly |
Many sites combine alert tests with their routine DG test runs. See the monthly maintenance checklist for diesel generators.
A Worked Example: Rural Water Pumping Station
The scenario is illustrative. A municipal water utility runs a 160 kVA DG with an RECD at an unattended pumping station 45 km from its depot. The DG runs during grid outages, often for several hours in summer.
Set-up:
- Cellular gateway with dual SIM and external antenna, reading the RECD controller over Modbus and two hardwired contacts (common alarm, DG running)
- Gateway on the DG-backed supply with an internal battery for about 4 hours
- Heartbeat every 15 minutes; “site not reporting” after 45 minutes
- Immediate alerts: high back-pressure, high outlet temperature, DG running with no RECD data
- Escalation ladder: on-call technician → backup → depot supervisor → RECD supplier
- Daily summary email: DG hours, peak ΔP and back-pressure, regenerations, alarms
What happened one night:
| Time (IST) | Event |
|---|---|
| 22:40 | Grid fails; DG starts; “DG running” notification sent |
| 01:55 | High ΔP critical (same-day group); held for morning batch |
| 02:30 | Back-pressure reaches limit; immediate alert by SMS and push to on-call technician |
| 02:40 | Not acknowledged; voice call to on-call technician; acknowledged |
| 02:45 | Technician checks platform remotely: load 118 kW, regeneration failed twice, heater current zero |
| 02:50 | Technician reduces load remotely by switching a non-critical pump to standby (per site procedure) |
| 03:05 | Back-pressure falls below limit; “cleared” message sent |
| 08:30 | Technician visits; finds heater supply breaker tripped; resets after checks; supplier supervises regeneration |
Without the alerting chain, the RECD would have run at the back-pressure limit until morning, risking engine damage. The heater supply issue also prompted a review of how the heater is protected.
Where Remote Alerting Chains Usually Break
Experience at unattended sites shows the same weak points again and again:
| Weak point | What happens | Prevention |
|---|---|---|
| SIM data plan expires | Gateway goes silent; looks like “no problems” | Auto-renewing plans; heartbeat alert; renewal dates in the maintenance calendar |
| Gateway on grid-only supply | Silent exactly when the DG runs | DG-backed supply plus battery |
| Roster out of date | Alerts go to someone who has left | Monthly roster check; named owner |
| Phone on silent / do-not-disturb | Night alerts missed | Voice call escalation; allow-list the alert number |
| Alert text unclear | Responder doesn’t know whether to travel | Structured messages with values and context |
| Too many low-priority alerts | Real alerts ignored | Group, delay, rate-limit; summaries for low priority |
| Platform subscription lapses | Alerts stop without warning | Track renewals; test monthly |
| Firmware or configuration change | Alert mapping silently broken | Change control; re-test after any change |
Most of these are administrative rather than technical. A named person responsible for the alerting chain, with a monthly checklist, prevents most of them.
Matching Alert Content to the Recipient
Different recipients need different information:
- On-call technician: values, context, response guidance, and a link to the live dashboard
- Supervisor (on escalation): what happened, who was alerted, how long without acknowledgement
- RECD supplier: equipment details, recent trends, regeneration history, alarm sequence
- Management (summary): counts, response times and outstanding actions, usually weekly or monthly
Many platforms can send different message templates to different recipients for the same event. Use this to keep each message short and relevant.
What It Costs, Roughly
Costs vary widely, but typically include:
- Hardware: gateway, antenna, cabling, backup battery
- Connectivity: SIM data and SMS plans, possibly dual SIMs
- Platform: subscription for a cloud alerting service, or configuration of an existing telemetry system
- People: on-call allowances and roster management
For a site where the DG supplies an essential service, these are modest compared with the cost of engine damage from undetected back-pressure, a failed compliance inspection, or a site visit wasted on a false alarm.
Security Basics for Remote Alerting
- Use outbound-only connections from site to platform where possible
- Change default passwords; use unique credentials per gateway
- Restrict who can change alert settings and who can send commands, if commands are allowed at all
- Keep alerting gateways separate from corporate networks
- Review user access when staff change
See ISA/IEC 62443 for broader guidance on securing control systems, and does an RECD need internet access to operate for connection options.
Related Reading
- What should a useful RECD operating dashboard show?
- What should an RECD event log record?
- How to align RECD sensor timestamps with generator runtime logs
- Detecting missing data in RECD monitoring records
- RECD for telecom sites: remote unattended operation
- RECD for water treatment plants: humidity and corrosion
Frequently Asked Questions
Is SMS reliable enough for critical RECD alerts?
SMS is widely available and works on basic phones, but delivery can be delayed during network congestion, which often coincides with wide power outages. For critical alerts, use SMS plus a second channel, such as a voice call or app push, and an escalation ladder.
How do I know the alert system itself is working?
Use heartbeat monitoring. The gateway sends regular “alive” messages, and the platform raises an alert if they stop. Also run monthly end-to-end tests that send a simulated alarm through to every recipient.
Should remote users be able to change RECD settings?
Usually not. Remote alerting and read-only monitoring cover most needs. If remote commands are allowed, such as acknowledging alarms or starting a supervised regeneration, restrict them to trained, named people, and log every action.
What if there’s no mobile signal at the site?
Use an external antenna, a dual-SIM gateway, or place the gateway where signal is available and cable back to the controller. Where none of these is possible, consider satellite or wired telemetry, or a local alarm that a periodic visitor checks.
Should the DG start itself trigger an alert?
At unattended sites, a short “DG running” notification is useful, because it tells responders that the RECD is now operating and helps them interpret any later alerts. Send it as a low-priority message, or to a log, so it doesn’t wake people unnecessarily.
How many people should be on the escalation list?
At least three levels, such as on-call technician, backup and supervisor, plus the RECD supplier for unresolved technical alarms. Fewer than that creates single points of failure.
Make Silence Mean Something
At an unattended site, the best alerting system is one where silence genuinely means everything is fine, because the system would tell you if it weren’t. Aceget supplies CPCB type-approved Retrofit Emission Control Devices for DG sets from 25 kVA to 2500 kVA. We can advise on the monitoring outputs and alert design that suit remote sites. See our certifications, or contact our team.