From WITS to WITSML
Before WITSML there was WITS (Wellsite Information Transfer Specification) — a 1980s serial-port format that streamed fixed records of rig-sensor values. It worked, but it was rigid, binary, and painful to extend. WITSML replaced it in the early 2000s with an XML-based standard maintained by Energistics (now part of The Open Group), giving the industry a vendor-neutral way to describe wells, wellbores, logs, and the activity around them.
The practical result: a mud-logging unit, an MWD service, and an operator's office in another country can all read and write the same data without custom point-to-point integrations.
What data moves over WITSML
WITSML defines data objects for most of what happens at the wellsite. The ones drilling teams touch every day:
| Object | What it carries |
|---|---|
| log | Time- or depth-indexed curves — ROP, WOB, hookload, torque, standpipe pressure, flow, gas, and any other channel the rig instrumentation produces |
| trajectory | Directional survey stations — MD, inclination, azimuth, TVD |
| mudLog | Lithology descriptions, gas shows, drilling-break notes |
| well / wellbore | The identity and hierarchy everything else hangs from |
| bhaRun, tubular | BHA components and drill-string configuration per run |
| fluidsReport | Daily mud-check properties from the fluids engineer |
| opsReport | Daily operations summaries and activity breakdowns |
Versions you'll meet in the field
| Version | Status | How data moves |
|---|---|---|
| 1.3.1 | Legacy, still alive on older servers | SOAP API — clients poll the server for new data |
| 1.4.1 / 1.4.1.1 | The most widely deployed version today | Same SOAP store interface, richer objects |
| 2.0 / 2.1 | Current generation, growing adoption | ETP 1.2 — a WebSocket protocol with binary Avro encoding that streams changes in real time instead of polling |
The version split matters operationally. A 1.4.1 connection means your software asks the server “anything new?” every few seconds. An ETP 1.2 connection means the server pushes each new data point the moment it exists — the difference between near-real-time and actually real-time monitoring.
Why WITSML data is still hard to use
The standard solves transport, not meaning. Real-world feeds arrive with problems the spec doesn't fix:
- Mnemonic drift — the same channel arrives as ROP, ROPA, RopAvg, or a contractor-specific name, varying by rig, vendor, and even by section of the same well
- Unit inconsistency— ft/hr on one well, m/hr on the next, with unit metadata that isn't always trustworthy
- Gaps and restarts — sensor dropouts, server restarts, and backfilled intervals that silently corrupt simple averages
- Context lives elsewhere — the WITSML feed shows what happened; the reason is usually in a daily drilling report, a tour sheet, or a vendor email that never touches the feed
This is why most drilling teams have WITSML data and still rebuild yesterday by hand every morning.
How TallyBook uses WITSML
TallyBook connects to WITSML servers across versions — SOAP polling for 1.3.1/1.4.1 stores and ETP 1.2 WebSocket streaming for 2.x — then does the unglamorous work the standard leaves open: normalizing mnemonics and units, validating data quality, and correlating the live feed with daily drilling reports, mud reports, directional surveys, and offset wells.
The result is that a drilling engineer can ask “why did ROP drop overnight?” in plain English and get an answer tied to the WITSML intervals, report entries, and offset wells that support it — instead of opening five systems to reconstruct the story.