Real Time Drilling Data Platform: Why the Rig, the Tools and the Morning Report Never Agree

The 6am call where nobody agrees on what happened

The drilling manager has three sources open. The mudlogger report says the string got stuck at 09:40 and packed off at 09:52. The EDR trend on the rig contractor system shows hookload climbing from 09:31. The directional contractor downhole memory data, which arrived two days after the trip, shows torque oscillation building for twenty minutes before either of those. The daily drilling report, written by a night pusher at the end of tour, records one line: stuck pipe, four and a half hours, coded to hole problems.

Four sources, four clocks, two depth references, and one invoice arriving at the end of the month that assumes the contractor version. Nobody in the room is lying. They are reading different instruments that were never synchronised, at different sample rates, indexed differently, and the only narrative anyone wrote down was typed twelve hours after the event by someone who was managing a rig floor at the time.

This matters because non productive time is priced at spread rate, and spread rate is the number your drilling capital budget is actually measured in. Four and a half hours coded to hole problems sits with the operator. The same four and a half hours coded to equipment failure sits somewhere else. That coding decision is currently made by whoever writes the report, from memory, with no machine record attached to it. A platform that attaches the machine record to the report line is not an analytics project. It is a commercial instrument.

Why your feeds do not line up, and why that is not a bug you can patch

Start with names. Hookload arrives as HKLD from one contractor, HKLA from another, and a vendor specific mnemonic from a third, and the mapping between them lives in a spreadsheet that one drilling engineer maintains and nobody else can read. Every new rig contract adds a column to that spreadsheet. Every rig move breaks it.

Then sample rate. An EDR publishes at one second, a mudlogging unit at five, downhole memory at whatever the tool was programmed for, and none of those clocks are disciplined to the same source. Drift of a minute or two across a tour is normal and it is fatal to event analysis, because a minute is the difference between torque rising before flow dropped and torque rising after, and that difference is the whole diagnosis.

Then the index. Surface data is time based, geology is depth based, and bit depth and hole depth freeze in different ways during a connection. If you index the wrong channel you will produce a rate of penetration curve that shows drilling during a trip. WITSML, the Energistics standard most of this moves on, handles both indexes properly, but only if your ingestion respects which one a given log actually uses, and versions 1.4.1.1 and 2.x differ enough that treating them as one thing is a fortnight you will lose later.

Then late data. Satellite comms drop, the store backfills, and if your pipeline treats late arriving records as new records your rig state engine reprocesses history and fires alarms on a well that finished last month. Idempotent reprocessing with a watermark is not an optimisation here. It is the difference between a platform people trust and one they mute.

What Corva, Petrolink, NOV WellData and Pason DataHub actually deliver

Pason DataHub is excellent at exposing what a Pason EDR recorded, and it should be, because Pason owns the acquisition end to end. The limit is structural: it is very good at Pason data. If half your fleet runs a different EDR you are now operating two platforms and reconciling them by hand, which is the original problem with a subscription attached. NOV WellData has the same shape on the NOV side.

Corva is the strongest off the shelf answer for most operators and I would say that to a client without hesitating. The app ecosystem is real, it deploys in weeks not quarters, and for a small fleet on consistent equipment it will beat a build on time to value. Two things push operators off it. Its analytics run on its own data model, so your proprietary parameter roadmaps and your own event definitions become configuration inside somebody else product. And the platform is priced per rig or per well, so at fleet scale the arithmetic turns, and when the subscription ends the working data model goes with it even though your raw data comes back.

Petrolink is strong at what it set out to be, which is aggregation and a WITSML store that speaks properly to a lot of counterparties. It is deliberately lighter on the operator specific engineering logic, and the engineering logic is the part you were trying to buy.

None of these is bad software. The honest gap is the same in all four cases: your drilling parameter limits, your offset well library, your event taxonomy and your daily reporting format are the things that differentiate your drilling programme, and they are exactly the things a packaged product asks you to express in its vocabulary.

What a custom drilling data platform has to include

The channel normalisation layer comes first and it has to be data, not code. Mapping tables per rig and per contractor, versioned, with unit handling for the places field and metric collide, and a validation gate that refuses to promote a rig into production until every required channel maps and reads a plausible value. Drilling engineers should be able to fix a mapping without a deployment, because rigs move on a Friday.

Then the rig state engine. In slips, tripping in, tripping out, rotary drilling, sliding, circulating, reaming, 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 this: connection time, tripping speed by stand, on bottom drilling hours, and the time slices that become NPT. Build it as an explainable rule set first. You will be asked to defend a state classification in a commercial conversation, and a model that cannot show its reasoning loses that conversation regardless of accuracy.

Then the time model. Store raw at source resolution with the source clock preserved, and hold a reconciled well clock alongside it. Never overwrite the raw record. This 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.

Then the operator specific layer: formation tops and offset wells from your own history, parameter roadmaps and limits from the well plan rather than generic thresholds, alarms that know an ECD window is different in the twelve and a quarter section than in the eight and a half, and a daily report screen where the pusher line item arrives with candidate time slices already attached from the machine record. The human confirms or overrides the coding. The override reason is captured. That single workflow is what turns a data platform into something the contract administrator uses.

Cost, timeline and what moves the number

A first release covering multi vendor ingestion, normalisation, the rig state engine, replay and daily report reconciliation runs $100,000 to $220,000 and ships in 14 to 20 weeks. A full platform adding downhole memory merge, well plan driven alerting with on call routing, the offset well library, edge collection on the rig and integration to your cost and AFE tracking runs $300,000 to $700,000 phased over 9 to 18 months.

What pushes it up in drilling specifically: the number of EDR and mudlogging vendors in the fleet, because each one is a parser, a mapping exercise and a support relationship. Whether you need to run a WITSML store rather than only a client, which is a materially bigger build. Offshore and remote land comms, which force edge collection that buffers locally and survives a two hour outage without losing a second. Downhole memory merge, because aligning memory data to surface time after a trip is genuine engineering. And historic backload, since twelve years of wells across three previous vendors is its own project.

What keeps it down: start with one rig class on one EDR vendor, ship the state engine and the report reconciliation, and prove the NPT coding loop on live wells before extending to the fleet. That is roughly a third of the total scope and it carries most of the commercial value.

When you should buy instead

Buy if you run one to three rigs on a single EDR vendor and the questions you ask are the questions everybody asks. Corva will answer them next month and a build will answer them next quarter. Buy if you hold non operated working interest and mainly need visibility, because you are consuming somebody else data on somebody else rig and building a platform for that is misplaced capital. Buy if your drilling programme is short, funded to a fixed well count and winding down, since the payback needs wells ahead of it.

Build when the fleet is mixed across contractors and reconciliation is already someone job. Build when you run a real time operations centre and your parameter roadmaps are a practice you consider a genuine advantage, because putting that practice inside a vendor product is both a leak and a lock in. Build when NPT coding disputes with contractors carry real money and you keep losing them on evidence. Build when you are a service company whose product is built on this data, in which case renting the platform underneath your own product is not a viable position.

How to choose a developer for this

Ask them to describe rig state detection before they quote. If the first answer is a machine learning model, push back. The first version should be deterministic rules over hookload, block position, rotary speed, flow and depth, because you will be asked to justify a classification in front of a contractor. Models earn their place later, on the genuinely ambiguous slices, sitting behind a rule set that can still explain itself.

Ask how they handle backfilled and late arriving data. If the answer does not include idempotent reprocessing and a watermark, your alarms will fire on completed wells within the first month and the crews will stop reading them.

Ask what they have actually done with WITSML, which version, and whether they wrote a client, a store or both. Those are different projects with different costs, and a developer who has only consumed a vendor REST API has not met the standard yet.

Ask about the edge. Some of this has to run on the rig with intermittent VSAT, buffering locally and reconciling on reconnect. Ask for the specific project where they shipped that, not the framework.

Ask who owns the code, the cloud accounts and the raw data, and get it in writing before kickoff. Raw drilling data is the asset that outlives every service contract you will sign. At Digital Heroes the client owns all three from the first commit, and any developer who wants your rig telemetry landing in their own account is building leverage, not a platform.