The BHA Static-Data Timing Gap: Why Your Real-Time Models Are Running Blind
- William B. Contreras
- 1 hour ago
- 9 min read
Every real-time drilling model, from torque and drag to hydraulics to the rig-state classifiers feeding the digital stack, needs to know exactly what is in the hole. That answer lives in the bottomhole-assembly record, and on most rigs it does not arrive until the company man closes the morning report, hours after the string is already downhole. The models run anyway, on assumptions, and every answer inherits the uncertainty.
Real-time drilling analytics has a quiet dependency almost nobody puts on the diagram: the model has to know what is in the hole. Torque and drag, hydraulics, hole cleaning, and the rig-state classifiers that label every second of the day all take the drill-string and bottomhole-assembly (BHA) geometry as a direct input. Not as background, not as metadata, as a coefficient in the physics. Feed them the wrong string and they are solving the wrong problem, confidently.
Here is the awkward part. That string is fully known before it ever goes in the hole. It is made up on the rig floor, component by component, in front of the crew. Yet on most rigs the record of it is captured on paper or in a separate system and finalized by the company man at the end of the tour, so the one input every real-time model needs at run-in does not land until the morning report closes. The data is not missing. It is late. And late, for a real-time model, is worse than missing.
This is the BHA static-data timing gap. It is a companion to a distinction WillCo drew in Reaming Is Not Washing: surface data alone cannot tell reaming from hole enlargement, only the BHA record can. That piece said join the BHA data. This one is about the harder, more practical half of the same problem: the BHA data has to arrive in time to be joined. Below is what the gap breaks, and the concrete fix, publishing the BHA as a real-time standards-based feed before the pipe goes down.
🔧 Section 1: What "BHA static data" actually is
Start with the object, precisely. The BHA static data is the ordered make-up of the bottomhole assembly and drill string, plus the geometry of every component in it:
The ordered string: bit, mud motor or rotary steerable system (RSS), measurement-while-drilling and logging-while-drilling (MWD/LWD) subs, stabilizers, underreamers and hole openers, subs, drill collars, heavy-weight drill pipe (HWDP), and drill pipe.
Per-component geometry: outer diameter, inner diameter, length, weight, connection, and position in the string.
The detail the models live on: bit size and nozzle or total flow area (TFA), stabilizer and reamer blade outer diameter, and the depth at which each tool sits.
It is called "static" because it does not change second to second the way a sensor channel does. It is set at make-up and changes only at the next trip. But static is not the same as unimportant. It is the backbone that every real-time model hangs its physics on, and it is exactly the input a surface sensor stream cannot supply on its own.
🧭 Section 2: The real-time processes that depend on it
This is the heart of the matter. Name the models, and show where the BHA physically enters each one. In every case it is an input, not a report field.
Torque and drag
The soft-string and stiff-string torque-and-drag (T&D) models compute expected hookload and torque from string weight, geometry, and friction along the wellbore. The string definition, component weights, outer diameters, stiffness, and stabilizer stand-off, is a direct model input. Real-time T&D works by comparing the measured hookload and torque against the modeled values and watching the difference for a rising friction trend. If the modeled side is built on the wrong BHA, the baseline is off, and the friction signal you are watching for, the early warning of poor hole cleaning or an impending stuck-pipe event, is corrupted before you start.
Hydraulics and ECD
Pressure-loss, equivalent-circulating-density (ECD), and hole-cleaning models need the flow-path geometry: bit nozzles or TFA, tool inner diameters for internal losses, and component outer diameters for annular velocities and cuttings transport. A wrong or assumed BHA shifts the entire hydraulic picture, including the ECD you are trying to keep inside a narrow mud window. In a managed-pressure or narrow-margin well, that is not an academic error.
Rig-state and operation recognition
Surface channels can separate washing from reaming, because bit rotation is a surface signal. They cannot separate reaming from hole enlargement, because both rotate the bit, both circulate, and both traverse an existing interval with identical surface signatures. The discriminator is whether an underreamer or hole opener is in the BHA and active, and that lives only in the BHA record. A rig-state classifier without the BHA join is structurally blind on that call. (This is the direct handoff from Reaming Is Not Washing: that piece proved the join is necessary; the timing gap is why it so often is not available when the event happens.)
Positioning and trajectory projection
above all the distance from the bit to the MWD sensor package. Anti-collision itself is driven mainly by survey and tool-face data, not by component geometry, so the BHA enters through that projection rather than directly. Get the offset wrong and the projected bit position, and the clearance to an offset well computed from it, inherits the error.
🔁 Section 3: How the data flows today, and why it is late
The traditional path is straightforward, and that is exactly the problem. The BHA is made up on the rig floor. The details are captured on the daily report and finalized by the company man at the end of the tour, and the morning report carries them, after the run.
For the hours between running in the hole and the report closing, every real-time model either waits or runs on an assumed or prior BHA. Analysis is delayed, and when it does run it carries a layer of uncertainty that no one flagged. This is a timeliness gap, not an existence gap. The failure is not sensor blindness and it is not missing data. It is a piece of information that was fully known before the pipe ever went down, arriving after the very activity it would have explained.
That distinction matters because it changes the fix. You do not need a new sensor, a new tool, or a research program. You need to move a known fact from the end of the tour to the start of the run.
The plan is not the string: a worse failure than a gap
There is a subtlety here that decides whether the gap is merely inconvenient or genuinely dangerous. When the verified BHA has not arrived, a real-time model does not simply stop. It falls back on the best estimate available, which is almost always the planned BHA, the string as designed in the well program. Used honestly, that is a legitimate approximation: if the system knows it is running on the plan and labels the result as an estimate, it stays cautious, and the uncertainty is visible.
The dangerous case is different, and sharper. It is when the planned BHA is ingested as if it were the actual, verified string. The plan and the reality are not the same thing. A stabilizer gets substituted on the rig floor, a different motor goes in the hole, a reamer is added or dropped, a sub is left out. Any of these makes the as-built string diverge from the program. A model that trusts the plan as reality is not merely uncertain, it is confidently wrong, and it does not know it, which is the worst state a real-time system can be in.
🔧 Section 4: The fix, a real-time WITSML BHA feed
The fix is to publish the BHA as structured data before running in the hole, on the same real-time basis as the sensor channels, rather than finalizing it hours later. The good news is that the standard to do this already exists and is already how surface data is streamed. No new schema is required.
The Wellsite Information Transfer Standard Markup Language (WITSML), published by Energistics, already carries the drill-string and BHA definition in two linked data objects:
Tubular captures the configuration of a string of pipe, drill strings, coiled tubing, or casing. The per-component geometry, outer diameter, inner diameter, length, weight, and position, is carried in its TubularComponent children. This is the string definition every model needs.
BhaRun captures information about one run of that string into and out of the hole. Per the Energistics definition, a run begins when the first component of the string, typically the BHA, is lowered below the rotary table, and one Tubular configuration can be used across many runs.
All of the information in both objects is fully known at make-up, and, critically, it is the as-built string, not the plan. It is captured from what actually went in the hole, on the rig floor, which is exactly what resolves the plan-versus-reality trap above. Emitting the Tubular and BhaRun objects as a real-time feed makes the verified string definition available to every model at the moment the string enters the hole, not at end of tour. The design target is simple: the BHA feed is live and time-synced with the surface channels before run-in, so torque and drag, hydraulics, and the rig-state classifier initialize on the real string rather than a placeholder or a program that may no longer match. Because it lands in the same standardized, timestamped stream as the sensor data, the join to the surface channels is native. No separate integration, no after-the-fact reconciliation.
Who is responsible for generating it
A feed only closes the gap if someone owns it. The ownership follows the data:
The directional-drilling contractor owns BHA make-up and the tool data, and is the natural source. The WITSML BHA feed should be generated by the directional company as part of the service, alongside the MWD and steering data it already streams.
When no directional company is on the job, on simpler or vertical wells, or intervals run without a directional service, the responsibility falls to the rig manager to capture and publish the BHA record on the same real-time basis. The point is that the responsibility is assigned, explicitly, rather than left to whoever closes the report.
Looking ahead: when the BHA generates itself
Today this feed still depends on a person publishing it. The industry is already experimenting with removing even that step. Some companies embed electronic identification tags, commonly radio-frequency identification (RFID), in the drill-string and BHA components, with a reader mounted at the rotary table that logs each component automatically as it trips into and out of the hole. Because the tag is read at the rotary table, it reports the actual component crossing into the well, so the record is as-built by construction, never transcribed from a plan. This is real but niche today: tagging every component, hardening the readers for the rig-floor environment, and integrating the output are expensive and hard to implement, so most operations still rely on the manually entered record. (WillCo covers this hardware approach in Beyond the Marketing Hype.)
Push that idea to its conclusion and it becomes the automation endgame for the BHA. If every tubular component carried a tag, and if there were a universal, industry-wide component database that each tag resolved to, with registration required so no component entered service untagged, then reading the tags at the rotary table would populate the Tubular and BhaRun objects on its own. The BHA feed would no longer be something a person generates. It would be generated by the act of running the string. The timing gap would not be closed by discipline, it would be closed by construction, because the as-built string would be captured the instant it crossed the rotary table. That universal registry does not exist yet, and the tagging is not universal, so this is a direction, not today's reality. But it is the natural destination of the same principle: put the string definition on the same real-time clock as everything else.
📈 Section 5: What closing the gap unlocks
Move the BHA from end of tour to run-in and the downstream effects are immediate and compounding:
Torque and drag and hydraulics that initialize on the true string from the first stand, so the measured-versus-modeled comparison is trustworthy from run-in rather than from the next morning.
Rig-state classifiers that can finally resolve reaming versus hole enlargement in real time, because the BHA join is present when the event happens, not the next day when the record catches up.
Cleaner machine-learning labels and KPIs, because the physics upstream started from the right configuration instead of an assumed one. Uncertain in becomes certain in.
A concrete data-readiness gate: confirm a real-time BHA feed, and who owns it, before you trust any real-time model output. It becomes a checkable item, not a hope.
That last point connects directly to the maturity argument WillCo makes in Beyond the Marketing Hype: the timeliness gap in static data is one of the specific things that keeps automated drilling reporting stuck below its top level. It is also a clean example of the point in Before the Dashboard: the data problem has to be solved before the dashboard on top of it means anything.
🎯 The takeaway
The BHA is the clearest case of a known fact delivered late. It is fully defined before the string goes in the hole, needed by every real-time model the instant it does, and traditionally not delivered until the report closes. In the meantime the models run on assumptions, and uncertain in becomes uncertain out, quietly, across torque and drag, hydraulics, and every rig-state call. Publish the BHA as a real-time WITSML feed, using the Tubular and BhaRun objects the standard already provides, assign the ownership to the directional contractor or the rig manager when there is none, and the models stop running blind. It is not a new tool or a new sensor. It is moving a fact you already have to the moment you already need it.
Comments