Landfill Gas Collection Software Problems: The 7 That Cost Real Money, and How to Avoid Them

Why does the just capture the readings scope failure happen so often?

Almost every wellfield software project starts as a data capture project. Get the technician off paper, import the analyser file cleanly, produce the monthly report faster. That brief is easy to write and easy to approve, and it produces a system that stores readings beautifully and holds no obligations at all.

The distinction matters more here than in most categories. A workbook holds readings. It does not know that well GW-114 went positive on the twelfth, that a valve adjustment on the fifteenth counts as the initial corrective action, that the recheck on the nineteenth still failed, and that the well is now on a path toward a system expansion decision with its own timeline. That chain exists in a gas technician's memory and a folder of field notes, and a capture app that does not model it simply digitises the same gap.

The order that works is the well object, then the limit set, then the exceedance engine, then the field app. Once a reading is evaluated against the limits in force at the moment it was taken, and a failure creates an obligation with a due date, an owner and a required evidence type, everything else is presentation.

The practical test for any proposal: ask how a corrective action clock is modelled. If the answer is a status field on a reading, you are buying a capture app. The correct answer involves an obligation with its own timeline, independent of the reading that created it, so the chain from failed reading to action to recheck is provable to somebody who was not there.

What goes wrong with well identity and historical readings?

A landfill wellfield is not a stable set of assets. Wells get drilled, deepened, abandoned, converted from vertical to horizontal collection, taken offline during filling, and renumbered when a cell closes. In a spreadsheet, a column named after a well is not the same thing as the physical well, so trend history breaks every time a well is reworked. When a regulator asks for two years of readings at a location, you reconstruct it from tab names.

Migration is where this becomes expensive. Five years of readings across renamed wells in inconsistent workbooks is a week of engineering and several days of your gas manager's time, and the slow part is entirely human: deciding which historic column corresponds to which physical well after renumbering and rework. Nobody can automate that judgement, and getting it wrong poisons every trend built afterwards.

The design that prevents a repeat is to treat the well as a durable object with a status timeline. Construction changes, deepening, offline periods and abandonment become events on that object, and readings attach permanently. A renumbering is a label change, not a new asset.

Scope the history honestly. Decide how many years you genuinely need for trend and regulatory purposes, load and validate those with your gas manager confirming the ambiguous mappings, and mark older records as reference only rather than pretending they are comparable.

Why do the analyser imports and plant feeds break after launch?

Analyser imports break in the quietest way available. A firmware update changes a column order or adds a field, and the parser keeps running and maps values to the wrong parameters. Oxygen becomes balance gas. Nothing errors. The readings look plausible because they are real numbers, and the first sign of trouble is an exceedance that should have fired and did not.

Instrument mix makes it worse. Most sites accumulate analysers over years, so two models with different export formats are in the field simultaneously, and a technician who borrowed a unit from the sister site introduces a third format on a Tuesday.

Plant and control system feeds break differently. A historian tag gets renamed during a maintenance window, a flare controller is replaced, or a meter is recalibrated with a new scaling factor. The wellfield system keeps reading the tag and starts producing values that are wrong by a constant multiple.

Both problems have the same defence, which is validation on ingest rather than trust. Range check every parameter against physically plausible bounds and reject rather than store what fails. Compare each import against the previous round: how many wells reported, how many are new, how many disappeared, and how far the site average moved. Flag any file whose format signature does not match a known instrument profile. A parser that accepts anything will eventually accept something wrong, and in this category wrong data is a compliance record.

What happens when the correction clock and surface evidence are not covered?

The corrective action clock is measured in calendar days, not business days, and it does not pause because the technician who took the reading is on a different site this week. When it lives in a spreadsheet, three things go wrong in sequence. The exceedance is noticed late, so days are already gone. The initial action is taken but not recorded as an action against a specific obligation. And the recheck is scheduled by memory, which means it happens when somebody is next in that area.

The fix is an obligation queue with the clock visible, an owner on every item, an escalation when it ages, and a recheck that either resolves the obligation or advances it. The technician should see the flag on the handheld before leaving the wellhead, not a week later in an office.

Surface emission monitoring is a separate evidence problem. The walk has to follow a grid pattern across the cover, and increasingly what is asked for is proof of coverage rather than a statement that it happened. That means a recorded position track showing the route walked, exceedance points pinned with the instrument reading and a photograph, remonitoring scheduled automatically after cover repair, and an export producing the map and table your report needs.

Sites that do not build this end up with a signed form and a technician's recollection. That is fine until the day an inspector asks to see the track, and it is the same day you discover the walk missed a corner of a closed cell.

Should you build custom or configure what you already own?

Do not build if you run one closed site with a small passive system and no energy project. The compliance load is real and it is a spreadsheet sized problem, with a consultant handling the reporting. Put the money into cover repair. Equally, do not build if your monitoring is fully outsourced to an engineering firm that carries the obligation contractually and you have no plan to bring it in house, because you would be paying to duplicate their system.

Understand what the incumbents are for. QED LandTec sits closest to the instrument and handles capture from its analysers well, which is a genuine capability and not the same thing as being your compliance system of record. SCS eTools is a sensible fit when your monitoring programme is delivered by that engineering practice and your reporting matches their standard forms, and a weaker fit when you want your own workflow, your own escalation rules and your data in your own warehouse. LoCI Controls is hardware led, and automated wellhead control changes the labour model on the wells it instruments, but it is a tuning layer rather than the record proving your monthly obligation was met across every well including the uninstrumented ones.

The build case appears when two or more hold. You operate more than one wellfield under more than one permit. Your gas feeds an energy or renewable natural gas plant where oxygen and nitrogen have revenue consequences. You have taken a finding on corrective action documentation or surface evidence in the last three years. Your wellfield knowledge lives in one person. Or a plant partner or attribute programme asks for data you assemble by hand each quarter.

How do hidden costs get into the quote?

• Each additional permit. A second site is not a copy. It is another limit set, another applicable subpart, another report format and another round of testing, and proposals routinely price sites as duplicates.
• Wellhead controllers. Reconciling controller telemetry against manual readings is real integration work, including deciding which source wins when they disagree, and that is a policy question before it is a technical one.
• Historical migration. The engineering is parsing. The cost is your gas manager's time confirming which historic column is which physical well after years of renumbering.
• State submission portals. Any requirement to file through an electronic reporting portal adds format work and a validation cycle that rarely appears in a first estimate.

The item most often absent is offline conflict handling. Half a landfill has no signal, two technicians can work overlapping routes, and deciding what happens when the same well is read twice on the same day is design work. If a quote does not mention it, the developer has not built for this environment.

What separates a build that works from one that fails here?

The working ones treat limits as configuration rather than code. Temperature, pressure, oxygen and balance gas criteria, the parameters your permit sets and any higher operating value approval you hold live in a versioned limit set with effective dates. Historic readings stay evaluated under the rules in force on the day they were taken, so a permit renewal updates a limit set instead of triggering a rebuild. That single decision is the difference between a system that survives ten years and one that gets replaced at the next renewal.

They also work with no signal. Offline first capture with route sequencing, the previous reading and previous adjustment visible at each well so the technician has context, photograph capture for wellhead condition, and a sync that reconciles cleanly when two people worked the same route.

The failing ones are recognisable at the proposal stage. They open with a screen mockup instead of asking which subpart applies. They model corrective action as a status field. They assume one analyser format. They treat surface emission monitoring as a form rather than an evidence trail. And they price a second site as a copy of the first.

When you choose a developer, ask them to model your permit before they quote, ask what analyser files they have actually parsed, and ask what the system does when a technician records a reading twice by mistake in the field. Then settle ownership in writing before kickoff. Your monitoring history is a regulatory record with a retention obligation and it should never sit inside a vendor account you cannot reach. At Digital Heroes the client owns the repository and the database from the first commit.