LDAR Software Problems: The 7 That Turn Into Findings, and How to Avoid Them

Why does the component register get scoped last?

Almost every leak detection and repair project starts with the interesting part. Operators want the dashboard that reconciles optical gas imaging findings with continuous monitor alerts and aerial screening, because that is the visible pain. The register, meaning the authoritative list of sites, equipment and monitored components with tags, service, monitoring designations and the rule basis that applies, gets pushed to a later phase because it looks like data entry.

It is not data entry. It is the object every other feature hangs from, and the reason projects stall in month four is that the reconciliation engine has nothing to reconcile against. A detection can only be attributed to a component that exists in a structured record. Coverage can only be computed against a known population. A repair clock can only start against a finding tied to a tagged component under a known rule.

The reason this bites in upstream and midstream oil and gas is that the register usually does not exist in your systems. It sits with the survey contractor, in a spreadsheet from an audit two years ago, or is derived from site drawings each time. That means phase one is a field data collection programme, and no software shortens it.

Scope it honestly. Build the register first, area by area, and stand the system up on one asset area while verification continues elsewhere. Operators who wait for a complete register before deploying anything are still waiting a year later.

What goes wrong when contractor tag schemes are migrated into your register?

You will migrate at least two years of survey findings and repair records, and they will reference the contractor's tag scheme, not yours. That mismatch is where migrations quietly fail.

The obvious problem is that the same physical valve carries different identifiers in two contractors' deliverables, so a component's history arrives split across two records and its survey coverage looks worse than it was. The less obvious problem is that contractor tags are frequently positional rather than persistent. A tag that means the third connector on the header will point at a different piece of steel after a retrofit, and the history you migrate is therefore attached to the wrong component with complete confidence.

The second trap is monitoring designation. Components marked difficult or unsafe to monitor need a documented basis, and in inherited records that basis is usually absent or buried in a comment field. Migrating the designation without the basis creates a population of exempt components you cannot defend.

Handle it the way you would any multi source reconciliation. Keep every source identifier on the component rather than overwriting it, make the matching rules explicit and adjustable rather than burying them in a one time script, and turn unresolved matches into a work queue with the original deliverable attached. Then accept that some history will land as site level rather than component level, and label it that way. An honest gap beats a confident wrong attribution, because the confident version is what an inspector will test.

Why do detection feeds break after launch?

Three technologies feed the same programme and none describe the same thing. Optical gas imaging gives a component level finding with a video clip. Continuous monitors give a concentration time series with a wind derived source bearing, pointing at a pad rather than a valve. Aerial and satellite screening gives a geolocated plume with an estimated rate.

The integrations break predictably. Imaging deliverables arrive as PDF reports plus a folder of clips, and the format changes when the contractor updates their software or when you change contractors. Continuous monitor vendors change their interfaces and their alert semantics, so a threshold that meant one thing last quarter means another this quarter. Aerial providers deliver coordinates and confidence bands, and the confidence definition is theirs, not yours.

The reconciliation logic is what actually decays. How close a plume centroid has to sit to a site boundary before you attribute it, when a monitor alert converts into a survey task, what happens when an aerial detection arrives for a site an imaging crew walked clean two days earlier. These are operator specific decisions driven by your site density, your terrain and your monitoring mix, and they need tuning as your estate changes.

The design rule that prevents the worst outcome is simple. Unattributed must be a legitimate, tracked state with an investigation task attached. A system that forces every detection onto the nearest tag so the record looks tidy corrupts the register you are paying to build, and the corruption is invisible until the day it matters.

What happens when the repair clock is not modelled properly?

The rule gives you a small number of days to make a first repair attempt, a short window to complete the repair, and a requirement to verify it with a follow up survey. Every one of those steps has to be evidenced. Most operators can produce a PDF, an email chain and a field ticket that says repaired hatch.

The failure mode is that the leak stays a document while the work moves between parties. Found by contractor A, scheduled by your operations group, repaired by contractor B or a lease operator, verified by contractor A on their next rotation which may be a month out. Four handoffs, four systems, one clock, and the clock is not held anywhere.

Two design mistakes make it worse. The first is hardcoding day counts. Federal requirements, state plans and any approved alternative programme define different frequencies and deadlines, and they change. Deadlines must derive from the rule basis attached to the site, held as effective dated configuration, or a rule change becomes a redeployment.

The second is treating delay of repair as a comment. Where a repair genuinely requires a shutdown, the justification needs its own structured path with an approver and a documented basis, because that is exactly the record an inspector will pull.

Build the leak as the object that moves. It carries its original clip or reading, its tag, its site and the technician who found it, through first attempt, parts on order, delay with justification, completion, and an automatically scheduled verification survey. Every state change timestamped with a named person. Confirm the specific deadlines that apply to your sites with your environmental counsel, then hold them as settings.

Should you build custom or configure what you already own?

Plenty of operators should not build this. If you run a few dozen well sites with one survey contractor and no continuous monitoring, the contractor portal plus a consultant who knows the rule is proportionate, and the money is better spent on repairs. That is a real answer, not a hedge.

LDARtools is strong in the instrument based tag and monitor world that grew up around refineries and chemical plants. If your estate looks like that, configuring it properly will serve you and a custom build would duplicate mature capability. Project Canary does continuous monitoring well, so if your programme is anchored on their hardware and you have no third party feeds to reconcile, their platform covers the ground. Highwood Emissions Management is genuinely expert on measurement programme design, and engaging them is often better value than any software purchase.

The case for building starts when the register has to be yours because three vendors feed it, when you sit under more than one rule set so deadlines and frequencies diverge by site, or when you cannot today prove a repair closed inside its window without weeks of assembly. Note what those have in common. None of them is a complaint about a product. They are all consequences of being the party that owns the compliance obligation while the data sits with parties who do not.

How do hidden costs get into the quote?

A first release covering the register, survey coverage, the repair workflow with rule derived clocks and offline field capture runs 70,000 to 150,000 dollars over 12 to 18 weeks in Digital Heroes delivery experience. The full platform adding multi technology reconciliation, greenhouse gas reporting roll up, fee scenarios and work management integration runs 180,000 to 400,000 dollars over 6 to 12 months. Four things reliably arrive later than the quote.

Building the initial register through field verification is the largest, and it is a services cost rather than a software one. If it is not a separate line in your budget, it will be a surprise in your schedule.

Distinct rule sets are the second. Every additional regime you sit under is real logic and real test cases, not a configuration flag, because the frequencies, the deadlines and the recordkeeping obligations differ.

Vendor feeds are the third. Each continuous monitor and aerial provider has its own interface and its own idea of what constitutes a detection, so each is an integration with its own maintenance tail.

Work management integration is the fourth and the most underestimated. If repairs must execute as work orders in Maximo or SAP rather than in your new tool, that is a two way synchronisation with status mapping and failure handling, and it deserves its own scoping conversation.

What separates an LDAR build that works from one that fails?

The builds that work are honest about the field. Ask any developer what happens when a technician has no signal for six hours. If the answer is anything other than offline capture with conflict safe synchronisation, your evidence will be written on paper and typed in later, which defeats the entire purpose. Geotagged photos, readings and clip references have to be captured at the point of work, because evidence assembled afterwards from memory is what turns a compliance question into a compliance finding.

The builds that work also refuse to force attribution. Ask how a detection that cannot be tied to a component is handled. If the design puts it on the nearest tag, walk away.

Ask how the repair deadline is computed, and listen for rule basis held as configuration with effective dates rather than day counts in code. Ask whether the reporting roll up for Subpart W and any fee model is configurable, because methodology decisions belong to your environmental team and the applicability and rates have been the subject of both rulemaking and legislative challenge.

Then run one test before you sign anything. Export a quarter of survey findings and repair records from your current contractors and ask whoever you are evaluating to reconcile them into one component level history. Whoever can do that has understood the problem. Settle ownership of the code, the cloud accounts and the register data in writing before kickoff. At Digital Heroes the client owns the code from the first commit.