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

Why does the build get scoped as a polling project?

The biggest scope failure in electronic flow measurement (EFM) work is treating the project as data collection. It is the part everyone can picture: reach the devices in the field, pull the hourly and daily records, land them in a database. Vendors demonstrate it, developers understand it, and it can be shown working within weeks.

Polling is also the part that is closest to solved. Reading a wide range of device formats is genuinely hard engineering that packaged tools already do well, and rebuilding it is a poor use of your budget.

The expensive part is what happens after the records land. A good measurement tech can tell you exactly why they estimated a particular meter-day: static pressure tracked fine, differential pressure looked frozen against a well that should have been flowing, the neighbouring meter on the same pad showed the expected decline, so they backfilled from the seven day average. That reasoning is correct and it is completely undocumented. When the tech leaves, the operation loses its validation logic and inherits a backlog.

So scope release one around policy rather than plumbing: validation rules you can read and version, named estimation methods stored on the record, and an append only edit trail. Expect two to four weeks of discovery sitting with the tech, because writing the rules down is the work. A team that quotes this category without booking that time has not understood where the schedule risk lives.

What goes wrong when historical meter data is migrated?

Migration in measurement is unusual because the thing you are migrating has already been edited, and the edits are often the part you need.

A closed month in a spreadsheet based process is a set of final volumes. The raw device record, the estimate that replaced a gap, the composition applied, the calibration certificate that justified a correction and the person who made each decision are scattered across a shared drive, an email thread and a workbook tab named BACKUP. Loading only the final volumes gives you a tidy history that cannot answer a single audit question about how any of it was derived.

The device side adds its own traps. Records with a partial day where a tech was on site, hours duplicated or lost when a clock was set backward, and a rollover where a device overwrote its own buffer all arrive looking like ordinary rows. Load them without interpretation and you have imported known bad data as fact.

The fixes are unglamorous but decisive. Migrate raw records where they still exist and rebuild the computed values from them, so the lineage starts at the device rather than at your cutover. Where only final volumes survive, load them explicitly marked as unreconstructable and say so in writing, because an honest boundary is defensible and a silent one is not. Decide with your counsel and your accounting lead how far back transaction level detail is genuinely required, and never cut over cold: run the new close alongside the spreadsheet for two full months.

Why do the flow computer and laboratory integrations break after launch?

Field integrations in measurement break for reasons that have nothing to do with your code quality.

A field with any history carries ABB Totalflow devices, Emerson ROC and FloBoss units, Thermo Fisher AutoPILOT and whatever the last acquisition brought in. Each stores records with its own field names, event log format and behaviour around clock changes and partial days. Then firmware gets updated on a subset of devices, and the record shape changes for those and not the others. An acquisition adds a make you have never polled. A field tech swaps a device and the new one starts a fresh record sequence that your gap detection reads as missing data.

Communications are worse. Serial radio and cellular links to remote pads fail partially and intermittently, so a poll returns some hours and not others, and naive retry logic either hammers a marginal link or gives up silently.

Chromatograph and laboratory results drift differently. A method changes, an instrument is replaced and reports to a different precision, or a spot sample arrives against an identifier that no longer matches how the meter is keyed.

The controls are a device profile per make and firmware generation holding the known quirks, configuration events treated as first class objects so a plate change flags its own affected hours, gap detection that distinguishes a communications failure from genuine missing data, and provenance on every quality value carrying its source, method and timestamp so a change of instrument is visible rather than absorbed.

What happens when the audit trail and calibration records are not covered?

Two gaps recur, and both surface at the worst possible moment.

The audit trail is the first. API MPMS Chapter 21.1 covers electronic gas measurement and expects original unedited data to be retained with edits traceable to who made them and why. In practice a counterparty auditor wants the before, the after, the reason and the supporting document for every change in the contested period. A system that stores the current value and a reason code cannot supply that, and assembling a defence by hand takes weeks you do not have.

Calibration and proving records are the second. A meter proving report showing a device read two percent high for a month is worth real money, and in most operations it is a scanned document in a folder. Nothing connects it to the affected meter-days, so the correction either does not happen or happens as an untraceable adjustment. The same applies to composition: a spot sample taken on the fourteenth when the gas clearly changed on the third needs an effective date rule, not a judgement made once and forgotten.

The fix for both is structural. Make the meter-day a raw record plus an ordered list of events, where every event carries who, when, why, the supporting document and the prior value, and nothing is ever overwritten. Make proving and calibration reports structured records so a discovered bias automatically proposes a correction over the affected period with the certificate attached. Reproducing what the system believed on any past date then becomes one query.

Should you build custom or configure what you already own?

If you run under roughly 100 meters, mostly one device make, on simple contracts, do not build. Flow-Cal plus a competent gas accountant will handle that, and a custom platform would be an expensive way to feel modern. The same applies if nearly all your measurement is custody transfer at a handful of large points with third party witnessing, because the volume of judgement calls is low.

Before assuming custom at larger scale, audit what you already pay for. Flow-Cal and Quorum PGAS both recalculate competently against the standards and both read a broad range of device formats, and a lot of operators use a fraction of that. Your hosting or supervisory control provider may already retain raw records you have never queried. Your laboratory may be able to send structured results instead of the reports somebody currently re-keys. Configuration and better use of existing licences is always cheaper than construction where it genuinely fits.

The build case appears when meter count runs into the hundreds, when acquisitions have left a mixed device population, when the close depends on one person's workbook, when prior period adjustments are a normal monthly event rather than an exception, or when a counterparty has already disputed a volume and your defence was a story rather than a record. At that point measurement is not data entry, it is revenue recognition wearing a hard hat.

How do hidden costs get into the quote?

Measurement quotes go wrong in five recognisable places.

• Device make and firmware count. Every additional make is a real integration measured in weeks, not a configuration toggle, and acquisitions add them mid project.
• Legacy communications. Serial radio and marginal cellular links need retry and gap fill logic that holds up under partial failure, which is more engineering than it sounds.
• Liquids alongside gas. A separate standards family with its own calculations, and frequently assumed to be included.
• Keeping an incumbent in the picture. Integrating with a system you do not control costs more than owning both sides, because you inherit their data model and their upgrade schedule.
• Undocumented validation policy. The largest driver and the least technical. Every rule that exists only in a tech's judgement is discovery work before it is code.

Digital Heroes delivery experience puts a focused first release covering multi vendor polling and normalisation, rule driven validation with an append only edit trail and a closeable volume statement at $70,000 to $150,000 over 12 to 18 weeks. A full platform adding standards based recalculation, composition and calibration management, allocation, counterparty statements and downstream revision propagation runs $180,000 to $450,000 across 6 to 12 months.

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

Working builds can reproduce a number from two years ago exactly. Every recomputed value stores the standard applied, the method options chosen, the inputs used and the version of the calculation that produced it. If a developer describes a meter-day as a table of volumes, they are building a reporting tool. If they describe a raw record plus an ordered event list plus a computed result with method metadata, they know what an auditor will ask for.

They propagate revisions instead of announcing them. A corrected composition in July should raise the affected allocation, revenue detail and state report as tasks with the delta attached, rather than being discovered as a strange variance in a quarterly review. Publishing volumes as a versioned dataset that downstream consumers subscribe to is what makes that automatic.

They use machine learning for one narrow job and only after a year of clean history: flagging meters whose behaviour has drifted from their own established pattern, which catches plugged taps and drifting transmitters mid month. Anything sold as volume prediction is a guess with a chart on it and should not touch a number you bill on.

And they settle ownership before kickoff, covering the repository, the cloud accounts and the right to hire another firm. Measurement software computes what you get paid, and a vendor holding your repository is holding your ability to defend an audit.