Drilling Rig Data Platform Problems: The 7 That Lose You the NPT Argument, and How to Avoid Them

Why does a drilling data project get scoped as a dashboard so often?

Because dashboards are what everyone asks for and what every vendor demos. The brief describes trends, a rig fleet view, some drilling performance charts and an alert or two, and all of that is buildable in weeks against a single vendor feed. It looks like progress and it changes nothing, because the numbers on those charts inherit whatever assumptions the ingestion made.

The parts that decide whether the platform is trusted are the channel normalisation layer, the rig state engine and the time model, and none of them appear on a screen. Hookload arrives as one mnemonic from one contractor and a different one from another, sample rates differ across the EDR, the mudlogging unit and the memory tool, and the index is time based at surface and depth based in geology. Get those wrong and you produce a rate of penetration curve that shows drilling during a trip, on a very attractive chart.

The scoping defence is to make the developer describe rig state detection before they quote anything visual. In slips, tripping in, tripping out, rotary drilling, sliding, circulating, reaming and connection, derived from hookload, block position, rotary speed, flow and the relationship between bit depth and hole depth. Every number anyone actually wants sits downstream of that. If the first answer is a machine learning model, push back, because you will be asked to justify a classification in front of a contractor and a model that cannot show its reasoning loses that conversation regardless of accuracy.

What goes wrong when you normalise channels across EDR and mudlogging vendors?

This is the workstream that quietly sets your schedule, and it is people work as much as engineering.

The mapping between vendor mnemonics and your canonical channel names usually lives in a spreadsheet one drilling engineer maintains and nobody else can read. Every new rig contract adds a column. Every rig move breaks it. Units collide where field and metric conventions meet, and a hookload in the wrong unit produces a rig state engine that thinks the string is always in slips.

Worse are the channels that look right and are not. A flow channel that is actually pump stroke rate. A depth channel that freezes during connections on one vendor and interpolates on another. A torque reading taken at a different point in the drive train, so two rigs report numbers that are not comparable even after mapping.

The design that survives treats mapping as versioned data rather than code, per rig and per contractor, with a validation gate that refuses to promote a rig into production until every required channel maps and reads a plausible value. Drilling engineers must be able to fix a mapping without a deployment, because rigs move on a Friday. Then budget the agreement work separately: drilling engineering, operations and the contract administrator usually define an event differently and have never had to write it down, and that conversation is where the weeks go.

Why do the WITSML feeds break after launch?

They rarely stop. They degrade, which is harder to notice.

• Late and backfilled data. Satellite comms drop, the store backfills, and if the pipeline treats late arriving records as new records the rig state engine reprocesses history and fires alarms on a well that finished last month. Crews mute the alerts within a fortnight and never turn them back on.
• Version differences. Versions 1.4.1.1 and 2.x differ enough that treating them as one thing costs you a fortnight later. So does the distinction between writing a client and running a store, which are different projects with different costs.
• Clock drift. None of the source clocks are disciplined to a common source, and a minute or two of drift across a tour is normal. A minute is the difference between torque rising before flow dropped and after, which is the entire diagnosis.
• Contractor changes. A new rig, a firmware update or a reconfigured acquisition system changes what arrives, and nobody tells the data team.

What to require: idempotent reprocessing with a watermark so backfill cannot fire alarms on completed wells, raw stored at source resolution with the source clock preserved and never overwritten, a reconciled well clock held alongside it, and continuous plausibility monitoring so a channel that goes flat or implausible raises an exception rather than feeding a chart.

What happens when NPT coding and the daily report are left out of scope?

This is the gap that decides whether the platform is an engineering toy or a commercial instrument, and it is left out more often than not because it looks like a reporting feature.

Without it, the daily drilling report is still written by a night pusher at the end of tour, from memory, twelve hours after the event, and the coding decision that determines who carries the cost is made with no machine record attached. Your data platform then sits alongside that report disagreeing with it, which is worse than not having one, because now you have a fourth source at the 6am call.

What to require instead is the loop. The report line item arrives with candidate time slices already attached from the machine record, derived from the rig state engine. The human confirms or overrides the coding, and the override reason is captured. When the contractor disputes the coding weeks later, you replay the exact channel data for that window rather than arguing from two different trend screenshots.

The same design carries the audit properties you will want later: who classified what, when, on what evidence, and what changed. Build it into the first release rather than phase two, because it is the piece that makes the contract administrator a user, and a platform with no commercial user rarely survives the next budget cycle.

Should you build custom or configure what you already own?

Subscribe, and spend the capital on the rig, if you run one to three rigs on a single EDR vendor and the questions you ask are the questions everyone asks. Corva is the strongest off the shelf answer for most operators, the app ecosystem is real, and it deploys in weeks rather than quarters. We say that to clients without hesitating.

The same applies if you hold non operated working interest and mainly need visibility, because you are consuming someone else's data from someone else's rig, or if your drilling programme is funded to a fixed well count and winding down, since payback needs wells ahead of it.

Pason DataHub is excellent at exposing what a Pason EDR recorded, and NOV WellData has the same shape on the NOV side. Both are the right answer when your fleet is genuinely standardised on that vendor. Where they stop is structural rather than a criticism: if half your fleet runs a different EDR you are operating two platforms and reconciling them by hand, which is the original problem with a subscription attached. Petrolink is strong as an aggregator and a WITSML store and is deliberately lighter on operator specific engineering logic, which is the part you were trying to buy.

Build when the fleet is mixed and reconciliation is already someone's job, when your parameter roadmaps are a practice you consider an advantage, or when NPT disputes carry real money and you keep losing them on evidence.

How do hidden costs get into the quote?

Five reliably in drilling.

• Vendor count. Each EDR and mudlogging vendor is a parser, a mapping exercise and a support relationship. A quote written against one is not a quote for four.
• Store versus client. Running a WITSML store rather than only consuming as a client is a materially bigger build. Get which one is in scope written down.
• Edge collection. Offshore and remote land comms force local buffering that survives an outage of hours without losing a second. Ask for the specific project where they shipped it, not the architecture diagram.
• Downhole memory merge. Aligning memory data to surface time and depth after a trip is genuine engineering, not a file import, and it deserves its own line.
• Historic backload. Twelve years of wells across three previous vendors is its own project, and it is the line most often assumed to be free.

What holds the number down is starting with one rig class on one EDR vendor, shipping the state engine and the report reconciliation, and proving the coding loop on live wells before extending to the fleet.

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

The builds that work are explainable. The rig state engine is a deterministic rule set first, so a classification can be defended line by line in a commercial conversation. Models earn their place later, on genuinely ambiguous slices, sitting behind rules that still explain themselves. An operator who cannot show why the system called a state has bought a very expensive opinion.

They preserve raw at source resolution with source clocks intact and never overwrite it. That single property is what lets you replay any moment of any well exactly as it was observed, which is the capability that ends the 6am argument permanently rather than shifting it.

They put the operator specific layer where the differentiation is: your formation tops and offset wells from your own history, parameter roadmaps and limits from the well plan rather than generic thresholds, and alarms that know an equivalent circulating density window differs between hole sections. That layer is the reason you are building rather than subscribing, and a project that defers it to phase three has inverted its own justification.

And they settle ownership before kickoff. You should own the repository, the cloud accounts and the raw telemetry, in writing. At Digital Heroes the client owns all three from the first commit. Raw drilling data outlives every service contract you will sign and it is what your offset well library is built from, so a developer who wants your rig telemetry landing in their own account is building a hold over you rather than a platform for you.