What Should an RECD Event Log Record?

When something goes wrong with a Retrofit Emission Control Device, such as a cracked substrate, a run of failed regenerations or back-pressure creeping towards the engine limit, the first question is always the same: what happened, and when?

Trend charts help, but they show continuous values, not events. A chart can show that differential pressure dropped sharply on 12 March. It can’t tell you that a technician cleaned the device that morning, that a firmware update was installed the week before, or that the heater breaker tripped twice during a long outage.

That’s the job of an event log: a time-ordered record of discrete things that happened to the RECD, its controller, the DG set and the people working on them. This article explains what an RECD event log should record, the fields each entry needs, how to keep the log trustworthy, and how to use it.

Event Log vs Data Log: What’s the Difference?

	Data (trend) log	Event log
What it records	Sampled values at regular intervals (e.g. ΔP every minute)	Discrete occurrences (e.g. “regeneration started”)
Volume	Large, continuous	Smaller, irregular
Typical question	“How did ΔP change over the month?”	“What happened just before ΔP dropped?”
Source	Sensors, controller	Controller, BMS, gateway, people

You need both. The event log explains the trend log. Together, they give a complete history. For guidance on displaying both, see what should a useful RECD operating dashboard show.

The Anatomy of a Good Event Log Entry

Every entry, whether generated automatically or typed by a person, should contain the same core fields:

Field	Example	Why it matters
Timestamp, with time zone	2026-10-14 03:12:45 +05:30	Sequencing; matching with other logs
Source	RECD-DG2 controller / BMS / gateway / technician R. Sharma	Who or what generated the entry
Equipment ID	DG2 / RECD serial 12345	Unambiguous identification
Event category	Alarm / Regeneration / Operator action / Configuration / Maintenance / Power / Communication / System	Filtering and analysis
Event type	High back-pressure – raised	What happened
State	Raised / acknowledged / cleared; started / completed / failed	Lifecycle of the event
Key values at the time	Back-pressure 62 mbar; load 118 kW; ΔP 74 mbar	Context for later diagnosis
Reference	Alarm matrix row 4; work order WO-2291	Links to procedures and records
Comment	“Heater breaker found tripped; reset after insulation check”	Human explanation, where relevant

The timestamp with time zone is the most important field and the one most often done badly. If different systems record time differently, the log can’t be lined up with generator runtime records. See how to align RECD sensor timestamps with generator runtime logs. The internationally recognised date and time format, ISO 8601, avoids ambiguity such as whether 03/04 means 3 April or 4 March.

What Events to Record: A Catalogue

The list below covers most RECD installations. Not every device generates every event. Record what your system can produce, and add manual entries for the rest.

1. DG and RECD operating state

• DG start and stop, with reason if known (grid failure, test run, manual)
• Changes of supply mode (on grid, on DG, transfer)
• Major load steps, if logged by the DG controller
• RECD controller start-up and shut-down

These give context to everything else. Most RECD questions start with “was the DG running?”

2. Alarms

• Every alarm raised, acknowledged and cleared, with values at each moment
• Who acknowledged it
• Shelving or suppression of any alarm, with reason, duration and approver

See how to design an RECD alarm response matrix for operators.

3. Regeneration

• Regeneration requested, started, completed or failed
• ΔP and temperatures at start and end
• Duration and peak temperature
• Heater operation, for heater-assisted devices
• Reason for failure, if the controller reports one

Regeneration history is one of the best indicators of device health. See RECD testing during regeneration: what should be recorded.

4. Operator and remote actions

• Manual regeneration started or stopped
• Load changes made in response to an alarm
• Remote commands, if the system allows them
• Log-ins to the controller or platform with change permissions

5. Configuration changes

• Any change to alarm limits, regeneration parameters, scaling, time settings or communication settings
• Old value and new value, who made the change and why
• Firmware or software updates, with version numbers before and after

Configuration changes are a frequent hidden cause of “the alarms stopped working” or “the trend suddenly shifted.” See RECD Modbus data: units, scaling and register mapping explained.

6. Maintenance and inspection

• Cleaning (ash removal), substrate or catalyst replacement
• Sensor checks, calibrations and replacements
• Gasket, bellows and clamp work in the exhaust
• Engine work that affects the exhaust, such as injector replacement, turbo work or overhaul. See when should an RECD be retested after changes to the DG set
• Visual inspection findings

7. Tests and measurements

• Formal emission tests: date, lab, result and report reference
• Routine checks at the standard condition: opacity, ΔP, back-pressure. See why RECD test results may differ from day-to-day site readings
• Alert chain tests and blackout tests

8. Power and communication

• Controller power lost and restored
• Communication lost and restored between controller, gateway, BMS and platform
• Heartbeat failures
• Clock corrections or time resynchronisation

These events are essential for judging data completeness. See detecting missing data in RECD monitoring records.

9. External and compliance events

• Pollution Control Board inspections, findings and actions
• Consent renewals
• GRAP-related operating restrictions in Delhi NCR. See how GRAP restrictions affect businesses using DG sets
• Complaints received about smoke or odour, and the response

A Sample Event Log Extract

The extract below is illustrative and shows how automatic and manual entries combine into a readable story.

Timestamp (IST, +05:30)	Source	Category	Event	Values / details	Ref
2026-10-11 22:38:05	DG2 controller	State	Grid fail; DG2 start	—	—
2026-10-11 22:38:19	ATS	State	Load transferred to DG	—	—
2026-10-12 00:41:10	RECD-DG2	Regeneration	Requested	ΔP 68 mbar; load 104 kW	—
2026-10-12 00:41:12	RECD-DG2	Regeneration	Start failed: heater no current	Heater supply fault	—
2026-10-12 00:41:12	RECD-DG2	Alarm	Heater fault – raised	—	Matrix 8
2026-10-12 00:52:30	BMS	Alarm	Heater fault – acknowledged	By: night operator A. Khan	—
2026-10-12 01:55:02	RECD-DG2	Alarm	High ΔP critical – raised	ΔP 81 mbar; load 110 kW	Matrix 2
2026-10-12 02:30:44	RECD-DG2	Alarm	High back-pressure – raised	BP 61 mbar (limit 60)	Matrix 4
2026-10-12 02:41:00	Operator	Action	Non-critical load shed	Load 110 → 86 kW	—
2026-10-12 02:58:15	RECD-DG2	Alarm	High back-pressure – cleared	BP 54 mbar	—
2026-10-12 04:12:30	ATS	State	Load transferred to grid	—	—
2026-10-12 04:17:35	DG2 controller	State	DG2 stop (cool-down complete)	Run 5 h 39 m	—
2026-10-12 09:40:00	Technician R. Sharma	Maintenance	Heater breaker found tripped; insulation test OK; reset	—	WO-2291
2026-10-12 10:25:00	Technician R. Sharma	Regeneration	Supervised regeneration completed	ΔP 79 → 47 mbar	WO-2291
2026-10-12 10:30:00	Technician R. Sharma	Configuration	Heater supply moved to essential board (approved change)	—	CR-0087

Anyone reading this later, whether a manager, auditor or supplier, can follow the sequence without having been there.

Keeping Event Codes and Categories Consistent

When events come from several sources (the RECD controller, the DG controller, the BMS, the gateway and people), each may describe the same thing differently. One says “HI_DP_ALM”, another says “RECD DP High”, and a technician writes “filter choked”. Searching the log later becomes guesswork.

Agree a simple, consistent scheme:

Category code	Category	Example event types
ST	State	DG start, DG stop, transfer to DG, transfer to grid
AL	Alarm	High ΔP warning, high ΔP critical, high back-pressure, high outlet temp
RG	Regeneration	Requested, started, completed, failed
OP	Operator action	Load shed, manual regeneration, alarm shelved
CF	Configuration	Limit changed, firmware updated, time corrected
MN	Maintenance	Cleaning, sensor replaced, gasket replaced, inspection
TS	Test	Emission test, routine check, alert test, blackout test
PW	Power	Controller power lost, restored
CM	Communication	Link lost, restored, heartbeat failure
EX	External	Inspection, consent renewal, complaint

Map each system’s native messages to these categories in the BMS or platform, and use the same terms in manual entries. A consistent scheme also makes monthly reviews and dashboards much simpler.

Combining Logs From Several Systems

Most sites end up with several partial logs: the RECD controller’s internal log, the DG controller’s event history, the BMS alarm journal, the gateway’s connection log and a paper or digital maintenance log. To build a single readable history:

1. Export each log for the period of interest, with full timestamps and time zones
2. Correct any clock offsets first. See how to align RECD sensor timestamps with generator runtime logs
3. Map events to the common categories above
4. Merge and sort by timestamp
5. Remove exact duplicates, where two systems recorded the same alarm, but keep both sources noted
6. Add manual entries for maintenance and observations

For investigations, this merged timeline is usually the single most useful document.

Event Log Questions for Your RECD Supplier

• What events does the controller log, and with what fields?
• How many events can it store before overwriting the oldest?
• Does it record configuration changes with old and new values, and who made them?
• Is the clock backed up during power loss? Can it be synchronised?
• How can the log be exported, and in what format?
• Can the log be cleared, and if so, is that action itself logged?

Ask these at the ordering stage. See how to write a technical RFQ for an RECD project.

Good Entries vs Poor Entries

Poor entry	Better entry
“RECD alarm”	“High back-pressure – raised; BP 61 mbar (limit 60); load 110 kW”
“Fixed”	“Heater breaker tripped; insulation test OK; reset; supervised regeneration ΔP 79 → 47 mbar”
“Settings changed”	“High ΔP critical limit changed 75 → 80 mbar by S. Iyer; reason: reference value updated after cleaning; approved by FM”
“Serviced”	“Ash cleaning per supplier procedure; ΔP at 50% load before 63 mbar, after 42 mbar; gasket replaced”
Date only, no time	“2026-10-12 09:40 +05:30”

The difference is values, causes and actions. A future reader needs to know what was observed, why and what was done.

Keeping the Log Trustworthy

An event log is only as useful as it is reliable. Apply these integrity rules:

Append, don’t overwrite

Entries should be added, never edited or deleted. If an entry is wrong, add a correction entry that references the original. This keeps a full audit trail.

Protect automatic logs

• Controller and BMS logs should be read-only for ordinary users
• Access to change or clear logs should be restricted and itself logged
• Regular exports or backups should be kept somewhere separate from the controller

General guidance on log management, such as the NIST guide to computer security log management (SP 800-92), sets out principles like protecting log integrity and planning retention. These apply well to equipment logs too.

Synchronise clocks

All sources (RECD controller, DG controller, BMS and gateway) should use a common, synchronised time source. Otherwise events from different systems appear in the wrong order. See how to align RECD sensor timestamps with generator runtime logs.

Make manual entries easy

If logging a maintenance visit takes ten minutes of form-filling, people skip it. Use a simple template, a mobile form or a structured paper log that is later transcribed, whatever your team will actually use.

Check controller memory limits

Many controllers keep only a limited number of events, after which the oldest are overwritten. Find out the limit, and export the log often enough that nothing is lost, especially after long outages with many events.

Event Logging During Long Outages

Long grid outages put the most strain on event logging. The DG may run for many hours, regenerations and alarms may occur repeatedly, and controller memory can fill up. Networks may be congested, so events can’t be sent to the BMS or cloud straight away.

Plan for this:

• Know the controller’s event capacity, and estimate how many events a long outage could generate
• Export or synchronise logs promptly after any long outage, before older events are overwritten
• Make sure gateways buffer events, not just analogue data, during communication loss
• Record manual observations made during the outage, such as visible smoke, unusual noise or load shedding, with the time, as soon as possible afterwards

After a major outage, a short review of the event log is one of the most useful things a facility team can do. It often reveals issues that live screens didn’t make obvious at the time.

How Long to Keep Event Records

Retention depends on your consent conditions, contracts and internal policy. As a practical guide:

• At least the life of the RECD, for maintenance, regeneration, configuration and test records, which together form the device’s history
• At least as long as any warranty period, for anything that might support a claim. See RECD warranty terms: parts, labour and exclusions
• In line with compliance record requirements for anything related to inspections, consents or complaints

Keep exported logs in a format that will still be readable in years: a simple CSV or PDF rather than a proprietary file only one software version can open.

How the Event Log Gets Used

Diagnosis

When a problem appears, the log shows what preceded it: a configuration change, a missed cleaning, a run of failed regenerations, an engine repair. Many root causes are found in the log within minutes.

Maintenance planning

Regeneration frequency, alarm counts and time since cleaning help schedule work before problems occur. See the RECD maintenance guide.

Warranty and supplier discussions

A clear log of operation, maintenance and alarms supports warranty claims and makes discussions with the supplier factual instead of anecdotal.

Inspections and audits

During a Pollution Control Board inspection, a well-kept log shows that the RECD is actively monitored and maintained. It sits alongside certification and test reports in your compliance file. See the environmental compliance checklist for generator owners.

Learning and improvement

Quarterly reviews of the log reveal patterns: repeated nuisance alarms, a recurring heater issue, regeneration failures linked to light-load running. Fixing those patterns improves reliability.

A Monthly Event Log Review: 15 Minutes

Once a month, someone responsible for the DG set should:

1. Filter the log for alarms, and check each was acknowledged, cleared and explained
2. Check regeneration success and failure counts
3. Check for any configuration changes, and confirm each was approved
4. Check power and communication events for gaps in monitoring
5. Confirm maintenance entries match the work orders actually completed
6. Note any patterns and assign actions
7. Export and back up the month’s log

Record that the review was done. That record is itself a useful compliance entry.

Related Reading

• How to set up remote RECD alerts for an unattended site
• What should a useful RECD operating dashboard show?
• How to align RECD sensor timestamps with generator runtime logs
• Detecting missing data in RECD monitoring records
• Integrating RECD monitoring with a building management system

Frequently Asked Questions

My RECD has no controller. Do I still need an event log?

Yes. A simple manual log of DG runs, routine readings, maintenance, cleaning and tests is valuable even for a passive device. It’s often the only history the device has.

Should the event log be on paper or electronic?

Either works if it’s kept consistently. Electronic logs are easier to search, back up and combine with controller data. Paper logs work if they use a fixed template and are reviewed regularly. Many sites use both: automatic electronic logs from the controller, and a paper or mobile form for maintenance.

Who is allowed to write in the event log?

Automatic entries come from the controller, BMS and gateway. Manual entries should be made by trained staff and contractors, identified by name. Editing or deleting entries shouldn’t be allowed. Corrections are added as new entries.

How detailed should maintenance entries be?

Enough for someone else to understand what was found, what was done and what changed. Include key readings before and after, parts replaced and any follow-up needed.

Can the event log help with estimating PM avoided?

Indirectly. DG running hours and periods when the RECD was out of service, both recorded in the log, are key inputs. See estimating kilograms of PM avoided after an RECD retrofit.

A Good Log Is a Good Memory

People change jobs, contractors rotate and memories fade. A well-kept event log keeps the RECD’s history available for anyone who needs it. Aceget supplies CPCB type-approved Retrofit Emission Control Devices for DG sets from 25 kVA to 2500 kVA, and we can provide log templates and guidance on what to record for your device. See our certifications, or contact our team.