From Rig Data to Drilling Autonomy: What the Drilling Data Standards WITS, WITSML, ETP and OSDU Actually Do
Autonomy is a data-architecture achievement before it is an algorithmic one. Data moves from rig sensors through wellsite acquisition and edge systems before reaching enterprise platforms. Illustrative image, not a specific operation or physical architecture.
Drilling autonomy cannot scale if every rig, service, and data domain needs a custom connection. Standardized data is what lets one piece of software read many wells, from many vendors, without a person stitching the pieces together first. Three names come up whenever that foundation is discussed: WITSML, ETP, and OSDU. Each reduces integration friction in a different way, and none of them, alone or together, is the whole architecture.
Every conversation about autonomous and agentic drilling reaches for the same picture: software that senses the whole operation, reasons about it, and acts or advises faster and more consistently than a room full of people. That picture quietly assumes the software can read the operation, all of it, in a form it understands. Real-time rig data lives in one system and one vendor's format. Subsurface and reservoir models live somewhere else. Maintenance and cost records live in a third system with no notion of a wellbore at all. Before intelligence over the data is possible, the data needs shared structure, an efficient way to move, and consistent definitions and services that make it discoverable. This piece is about what WITSML, ETP, and OSDU each actually do toward that, and, just as important, what they do not.
📜 WITSML: the language of the wellsite
Start with the oldest and least glamorous piece. WITSML, the Wellsite Information Transfer Standard Markup Language, is an open, non-proprietary standard for structuring drilling, completion, and intervention data: the wellsite-to-office transfers, the well logs, the trajectories, the real-time drilling stream. It is maintained by Energistics and licensed free of charge. Its lineage runs back to WITS, a serial data specification from the 1980s; the markup-language version began around 2000 and passed to Energistics in 2003.
The governance detail matters because it signals where this is heading. Energistics became an affiliate of The Open Group effective January 1, 2022, placing the wellsite data standard under the same roof as the broader open-standards effort it now feeds. WITSML is not a vendor's format that happened to win. It is a genuinely open, neutrally governed standard, which is exactly the property an industry needs if it wants software from many suppliers to interoperate. For autonomy, that means an agent reasoning about a well can be written against a shared structure once, rather than against a dozen private schemas.
📡 From files to a live feed: WITSML 2.x and ETP
WITSML moved from v1.3.1 (2006) and v1.4.1.1 (2011) to v2.0 in 2016 and v2.1 in 2022, the current generation. The more important companion is the transport. Older WITSML exchanges leaned on a request-and-poll web-services interface: a client repeatedly asks "anything new?" The Energistics Transfer Protocol (ETP) replaces that pattern. ETP is a transfer protocol, not a data standard: it moves the data efficiently rather than defining what the data means. It provides a notification and discovery mechanism that pushes new data to subscribers as it arrives, and it was designed to replace the older WITSML web-services API. ETP v1.2 is the version paired with WITSML v2.1.
🔄 Why the transport model matters. Repeated polling is poorly suited to workflows that require low-latency, event-driven updates: the consumer is always a step behind, and it wastes effort asking when nothing has changed. ETP's subscription and discovery model, where new data is notified to subscribers as it lands, is a better fit for streaming and near-real-time use. That said, streaming transport is one enabler among several. Latency-critical control still lives closer to the rig, on a separate path, for reasons this piece returns to below.
🧩 A family of drilling data standards, plus a protocol
WITSML does not stand alone, and autonomy needs more than the wellsite. Energistics maintains a family, sometimes called the EnergyML family, on a shared technical architecture. It is worth separating what defines the data from what moves it:
WITSML (wells and drilling), RESQML (reservoir and subsurface earth models), and PRODML (production) are three domain data standards. They define structure and meaning within their domains.
ETP is the transfer protocol that streams them. It is not a fourth data standard; it is the mechanism the data standards travel over.
The interesting cross-domain decisions live at the seams. Staying in the best rock joins the real-time drilling stream (WITSML) to the subsurface model (RESQML). A shared standards family on one architecture makes that join tractable without a bespoke integration for every pair. The value is not any single standard; it is that they are designed to fit together, with a common protocol to move them.
🌐 OSDU: shared definitions, discovery, and services
Shared structure solves part of the problem. Data that is well structured but scattered across a dozen systems still forces an agent, or a person, to go hunting. That is the problem OSDU, the Open Subsurface Data Universe, was created to address.
The Open Group launched the OSDU Forum publicly on March 21, 2019, as a vendor-neutral consortium building an open, standards-based data platform. Its stated purpose is to bring exploration, development, and wells data together and reduce the silos that keep the industry's information trapped in incompatible systems, enabling "secure, reliable, global, and performant access to all subsurface data." The founding group included operators such as Equinor and Shell, and initial implementations were undertaken across the major cloud providers.
OSDU and the Energistics standards are not competitors. OSDU set out to build on existing standards rather than reinvent them, and Energistics' WITSML, RESQML, PRODML, and ETP standards form a critical component of the OSDU data platform. Energistics is aligning its standards to OSDU's encoding, including JSON schema definitions alongside the traditional XML. Practically, OSDU provides ingestion, mapping, indexing, and services so domain data can be discovered and used across workflows. It is a shared access and services layer, not necessarily one physical repository: real deployments may ingest, map, reference, or federate data rather than pool every byte in one store.
📌 The distinction that clears up the confusion. People treat WITSML and OSDU as competing buzzwords. They are not the same kind of thing, and they are not two halves of one thing either. WITSML defines structures for well data; ETP moves selected data efficiently; OSDU provides shared data definitions and platform services that can ingest, index, and serve domain data. They are complementary components of a broader data architecture, with distinct roles and separate implementation requirements.
🛠 The architecture, drawn correctly
The common mistake in these diagrams is to funnel everything through one box and imply a single pipe carries rig control, subsurface models, and enterprise records alike. It does not. Different data travels different paths, with different connectors, latencies, and owners. Figure 1 shows the paths side by side.
Figure 1. Conceptual architecture. Each domain reaches the shared context layer through its own connector, so maintenance and ERP data arrive by enterprise APIs, not by WITSML. Rig control runs on a separate, latency-critical path that does not pass through the platform. Illustrative schematic, WillCo, after the OSDU and Energistics architecture in the references.
Two errors this drawing is meant to prevent. First, enterprise records, maintenance, cost, and ERP, do not travel over WITSML; they arrive through enterprise integration such as APIs and master-data mapping, and are reconciled to well and equipment identities. Second, OSDU is not the control bus. Real-time, safety-critical actuation is a deterministic loop that lives at the edge, close to the rig, with its own interfaces and safety boundaries. An application or agent can draw on both the context layer and the control environment, but those are distinct paths with distinct latency and safety requirements. Figure 2 makes that split explicit.
Figure 2. Conceptual view. An agent draws context from OSDU and domain services on one path, and interacts with the rig through a separate, deterministic, safety-bounded control path. The two are governed by different latency and safety rules. Illustrative schematic, WillCo.
✅ What the stack solves, and what it does not
Held to what the sources support, the value is real and specific. WITSML gives well data a shared, openly governed structure. ETP moves selected data efficiently as an event-driven stream instead of a constant poll. RESQML and PRODML extend structure to the subsurface and production. OSDU adds shared definitions, discovery, and services so that domain data can be found and used across workflows. The combined effect is less custom, point-to-point integration between rigs, services, and domains.
What the stack does not do is just as important to state plainly. Standardized transport and a shared platform do not guarantee data quality, correct semantic mapping, aligned timestamps and depths, consistent units, or trustworthy provenance. They do not provide the low latency and determinism that closed-loop control requires. They do not deliver cybersecurity, model validity, actuation authority, fail-safe behavior, or the governance that decides who is accountable when something is wrong. Interoperability does not replace model quality; it determines whether models can use consistent context across systems. The honest summary is that this foundation is necessary but not sufficient. It is one of the load-bearing gates to scalable autonomy, not the whole gate.
The industry is not treating interoperability as solved, which is itself telling. The Drilling and Wells Interoperability Standards (D-WIS) effort, developed under the SPE Drilling Systems Automation Technical Section, targets machine-to-machine interoperability, semantics, and rig-side interfaces for drilling automation. Its existence is evidence that interoperability is a recognized, active, unfinished priority. It is not evidence that model quality matters less; both have to be right.
📊 The adoption picture in 2026: transition, not replacement
There is a temptation to treat these standards as already universal. The evidence says otherwise, and the gap matters for anyone planning autonomy on top of them. No organization publishes a verifiable worldwide inventory of rigs, servers, or endpoints by version, so any figure is an estimate. The numbers below are WillCo market-intelligence estimates as of September 2, 2026, built from Energistics version status, certified-product breadth, current vendor support, and public deployment signals. They are shown as ranges with an explicit denominator. They are not official market share, and they should not be attributed to Energistics or The Open Group.
Three plain questions cut through the version noise, and their answers matter more to an autonomy plan than any single share. What format does a source actually generate? How much of that is converted before software ever sees it? And what format does the data finally land in? Figure 3 sketches that journey as a concept, and Tables 1 to 3 give the numbers behind each stage separately.
Figure 3. The format journey, shown as a conceptual flow rather than a proportional funnel or mass balance. What a source emits (mostly legacy WITS Level 0, with native WITSML a minority), how much is transformed before software sees it (most feeds are converted or at least normalized), and which target version it lands in at the endpoint (mostly WITSML 1.4, with 2.1 still a minority). Each stage uses a different base and is a separate observation point, so the columns are not a single running total. Central values are shown; ranges and bases are in Tables 1 to 3. WillCo market-intelligence estimate, September 2, 2026.
📚 How to read the next three tables. Read them separately. Table 1 shows the format a producing system emits before any gateway. Table 2 shows what happens between that source and the application, both strict conversion and broader gateway handling. Table 3 shows the WITSML version visible at the standardized endpoint after conversion. The percentages answer different questions and must not be added across tables. Within Tables 1 and 3, the central values sum to about 100%; the ranges are independent uncertainty bands.
Table 1. What the source emits, before any gateway. WillCo market-intelligence estimate, September 2, 2026. How to read it: pick 100 primary real-time source feeds and classify each by the format it exposes before any intermediary; the Central column is one distribution that totals about 100%. Ranges are uncertainty bands.
Native source format | Range | Central | Interpretation |
WITS Level 0 (legacy ASCII) | 45 to 65% | ~55% | The largest legacy source across rigs and service systems. An acquisition format, not a WITSML version. |
WITSML 1.3.x | 5 to 12% | ~8% | Older native service and aggregation output. |
WITSML 1.4.x | 15 to 27% | ~21% | A meaningful native base, below its endpoint share. |
WITSML 2.0 | 0 to 2% | ~1% | Rare as native output. |
WITSML 2.1 | 1 to 5% | ~3% | Growing, but still small at the source. |
Proprietary / other | 8 to 18% | ~12% | Vendor APIs and non-WITS interfaces. |
The message of Table 1: legacy generation still dominates what sources emit. Native modern WITSML at the source, especially 2.1, is small. Whatever lands at the endpoint mostly did not start there.
Table 2. What happens to a feed between source and application. WillCo market-intelligence estimate, September 2, 2026. How to read it: pick 100 primary source feeds and classify each by what the gateway does to it; the Central column is one distribution that totals about 100%. Ranges are uncertainty bands.
What the gateway does | Range | Central | What it counts |
Format or version converted | 65 to 80% | ~72% | The format or version is actually changed on the way through. |
Normalized only, same version | 6 to 14% | ~10% | The version does not change, but units, names, identifiers, or timestamps are cleaned up. |
No gateway touch | 10 to 25% | ~18% | Reaches the application exactly as the source produced it. |
The message of Table 2: most feeds are transformed, or at least normalized, before software uses them. Converted plus normalized is about 82% that touch a gateway, so only about 18% reach an application exactly as the source produced it.
Table 3. The WITSML version visible at the standardized endpoint, after conversion. WillCo market-intelligence estimate, September 2, 2026. How to read it: pick 100 active WITSML endpoints after gateway processing and classify each by the version it exposes; the Central column is one distribution that totals about 100%. This is not native source output.
Target version | Range | Central | Interpretation |
WITSML 1.4.x / 1.4.1.1 | 70 to 82% | ~76% | The dominant landing and exchange target. |
WITSML 2.1 | 8 to 18% | ~13% | A growing target for new stores and modernization. |
WITSML 1.3.x | 6 to 12% | ~9% | Residual legacy endpoints. |
WITSML 2.0 | 1 to 3% | ~2% | A marginal target; no longer recommended by Energistics. |
The message of Table 3: WITSML 1.4 dominates the landing point, not necessarily the source. WITSML 2.1 is the clear direction for new builds but is still a minority of endpoints.
🔑 The one sentence to remember. A WITSML 1.4 endpoint does not mean the rig generated WITSML 1.4. Much of that endpoint traffic began as WITS Level 0, WITSML 1.3, or a proprietary feed, and reached 1.4 through a gateway.
ETP and OSDU sit outside that version pie on purpose, because they answer different questions. ETP is transport: an ETP connection still carries one of the WITSML versions in Table 3, and adoption of the ETP 1.2 transport is still a minority of active WITSML connections, roughly 8 to 18% overall, higher, around 25 to 45%, in projects started 2024 to 2026, with the older request-and-poll web-services API still carrying the rest. OSDU is a later, parallel platform and mapping layer: the OSDU Forum reports roughly 190 member organizations and 16 major operators, but membership is not production. WillCo estimates that only about 20 to 35% of major operators run any OSDU domain in production, and broad, company-wide deployment is lower still, roughly 5 to 15%. These are WillCo market-intelligence estimates, not an official census.
This is the adoption-side confirmation of the architectural point. The load-bearing work is not swapping in a single modern standard; it is the disciplined, multi-version integration, the gateways, the mapping rules, the preserved provenance, that keeps a mixed estate usable while it modernizes. A responsible autonomy plan assumes coexistence, not a clean cutover, and treats "compatible with 2.1" as a capability claim to be proven at scale, not evidence of a productive deployment.
📡 Two widely deployed examples of rig-site data generation: Pason and NOV
The flow above is easier to picture once you see who actually stands at stage 1. Pason and NOV are two widely deployed examples of surface data acquisition on North American land rigs, and both sit where the raw signal is born. Each builds an electronic drilling recorder (EDR): a rig-wide network of sensors, an acquisition unit, and floor displays that read hookload, weight on bit, block position, rate of penetration, rotary speed and torque, pump strokes and standpipe pressure, flow, and mud properties, then encode those channels for everything downstream. They are examples of where data originates and how it is exposed, not a proxy for the global market.
A surface data-acquisition environment collects and displays drilling channels while a separate interface prepares selected information for external delivery. The acquisition environment and the delivered data format are not necessarily the same. Illustrative image, not a specific Pason or NOV product.
Table 4. Two widely deployed rig-site data generators, from public product and certification documentation. Some cited evidence is historical (see the notes and References). Frequencies reflect standard WITS behavior these systems can be configured to follow, not a vendor-specific benchmark.
Provider and system | What it generates | Output formats | Frequency |
Pason Electronic Drilling Recorder (EDR) | Surface drilling channels from a rig-wide sensor network: hookload, weight on bit, differential pressure, rate of penetration, block position, rotary, pump output, drilling-line wear; also aggregates third-party gas and directional data. | WITS Level 0 and near-real-time WITSML delivery are publicly documented. Pason WITSML Service v2.1 was self-certified for WITSML 1.3.1 in 2010. Direct Saudi Aramco project experience reported by the author indicates that Pason also delivered WITSML 1.4.1 when contractually required. No public Pason WITSML 1.4.1.1 certification was found in the Energistics list reviewed September 3, 2026. | The WITS User Guide describes configurable transmission types and intervals (time-based, depth-based, and request-response). Around one-second time intervals are common where configured, not a guaranteed universal rate. |
NOV RigSense (M/D Totco), with NOVOS and WellData | Surface acquisition from NOV's sensor and instrumentation systems; integrates with NOV rig controls (NOVOS, Amphion) and the e-Wildcat auto driller, with WellData carrying data offsite. | WITS and WITSML; the referenced RigSense flyer also lists Modbus and OPC for controls and SCADA integration. The WITSML version depends on the deployment. | Configurable time-based and depth-based records, following the WITS convention; the cited documents do not establish a fixed universal rate. |
Two distinctions in that table matter for autonomy. First, an EDR may acquire or exchange surface channels internally through WITS Level 0 or proprietary mechanisms while exposing a different format to the operator. The richer WITSML feed is normally a delivery service or interface layered over the acquisition environment, rather than proof of the EDR's internal representation. Second, certification records should not be interpreted as the limit of a provider's delivery capability. Pason's public record establishes support for WITSML 1.3.1 in 2010. Direct project experience reported by the author indicates that Pason also delivered WITSML 1.4.1 to meet Saudi Aramco contractual requirements. The public material reviewed does not establish whether that capability was formally certified or whether the output was produced through a service or conversion layer. The important conclusion is that the format delivered to the operator may differ from the format generated or used inside the acquisition system.
The quality trap inside stage 2: where you convert affects the data gaps
There is a data-quality trap inside stage 2 that no version table shows. WITS Level 0 is a simple ASCII transfer format. It can carry date and time items, but the protocol does not by itself guarantee synchronized source timestamps, delivery, persistence, or replay, and it has no protocol-level retransmission. If the acquisition system or edge gateway does not buffer the stream locally, a communications interruption can therefore create gaps that an office-side converter cannot reconstruct. Edge buffering and controlled replay reduce that risk; the actual outcome depends on the EDR, the gateway configuration, and the recovery architecture. This is why where the conversion happens can matter as much as which version it targets: an agent reasoning over a record with silent gaps will still produce confident conclusions from incomplete data, so data-gap risk is a first-order quality problem.
A gateway can normalize the structure of surviving records, but it cannot recreate samples that were never buffered or replayed. Visible gaps must remain visible after conversion. Illustrative image, not a specific operation.
📋 A readiness test before the roadmap
The practical value of separating these paths is that it turns into questions a team can actually answer before committing to a closed-loop ambition. If a program cannot answer these, the intelligence layer is being planned ahead of the foundation it needs.
🔍 Six questions for an autonomy data layer
Identity. Can every critical channel be identified consistently across source, well, wellbore, run, and time-or-depth context?
Fidelity. Are units, timestamps, quality flags, provenance, and versioning preserved end to end?
Placement. Which data is streamed at the edge, which is ingested into the platform, and which stays in enterprise systems?
Latency. What are the latency, availability, and failover requirements for advisory use versus closed-loop use?
Access. How are identities and entitlements reconciled across the platform, ERP, maintenance, and rig systems?
Ownership. Who owns a bad mapping, a late feed, a schema change, or an unsafe recommendation?
⚖️ What is sourced, and what is analysis
Both belong in the piece; only one gets to sound like fact.
Table 5. Sourced facts versus WillCo interpretation. The left column is cited; the right column is labeled analysis.
Established by the sources | WillCo analysis (argument, not fact) |
WITSML is an open, Energistics-governed data standard for well data; v2.1 (2022) is current, paired with ETP v1.2. | Shared structure is a necessary precondition, not a convenience, for cross-vendor reasoning, but not sufficient on its own. |
ETP is a transfer protocol with a subscription and discovery model that replaces the older web-services API. | Its event-driven transport suits streaming and near-real-time use; latency-critical control still belongs on a separate edge path. |
OSDU is a vendor-neutral platform (Open Group, 2019); Energistics standards form a critical component of it. | OSDU is a shared context and services layer for discovery and use, not the control bus and not a single physical store. |
The OSDU Forum reports roughly 190 member organizations and 16 major operators. | Membership signals strategic reach, not productive use; broad corporate OSDU deployment remains a minority even among large operators. |
D-WIS exists as an SPE-affiliated interoperability effort for drilling automation. | Its existence shows interoperability is an active, unfinished industry priority, alongside, not instead of, model quality. |
The adoption figures in this piece are estimates, deliberately shown as ranges tied to a stated denominator, and never as official market share. WillCo does not publish a single headline number such as "13% of the industry uses WITSML 2.1," because "the industry" is ambiguous: it could mean rigs, operators, stores, connections, or projects, each of which yields a different answer. What WillCo does not claim at all, because no reliable public figure supports it, is any adoption dollar figure or any precise, auditable global count by version. The argument rests on the architecture and the direction of travel, both of which are public and clear.
🎯 The takeaway
Agentic drilling will be sold as an intelligence breakthrough. The engineering story is quieter. An agent can only reason across the rig, the reservoir, and the record if those worlds share structure, move efficiently, and land in consistent, discoverable services. WITSML gives well data a shared, openly governed vocabulary; ETP moves it efficiently as an event-driven stream; RESQML and PRODML extend the vocabulary to the subsurface and production; and OSDU provides common definitions and platform services that make the data discoverable and usable across workflows. Much of that foundation is built and neutrally governed, but its adoption is a transition, not a finished replacement: WITS Level 0 remains the largest source-format category while WITSML 1.4.1.1 remains the dominant standardized endpoint target, 2.1 and ETP are the direction, and OSDU is advancing at the corporate layer without displacing rig acquisition or control. What remains is disciplined integration, validation, governance, and adoption, together with the separate edge-control and enterprise-integration work these standards deliberately do not cover. The standards are load-bearing infrastructure. They are not, by themselves, autonomy.
Related WillCo analysis
Before the Dashboard: Why Drilling Data Problems Are Killing Your Digital Investment - the field-level version of this argument.
Why Pure Machine Learning Is Not Enough for Drilling Optimization - why intelligence cannot substitute for well-structured inputs.
Beyond the Marketing Hype: A Pragmatic Maturity Model for Automated Drilling Reports - where standardized, timely data sits in a realistic maturity picture.
References and further reading
Standards bodies and primary sources
Energistics (an affiliate of The Open Group), WITSML data standards. Source for WITSML as an open, non-proprietary standard for drilling, completions, and interventions data, its WITS lineage, and free licensing.
Energistics, Energistics Transfer Protocol (ETP). Source for ETP as a subscription-based transfer protocol, its role replacing the older WITSML web-services API, and its service to the WITSML, RESQML, and PRODML family. See also the ETP v1.2 specification.
The Open Group, "Energistics becomes an affiliate of The Open Group." Source for the January 1, 2022 affiliation, ETP v1.2 as the API paired with WITSML v2.1, and the statement that Energistics standards "form a critical component of the OSDU Data Platform."
The Open Group, "The Open Group launches Open Subsurface Data Universe Forum." Source for the OSDU Forum's March 21, 2019 public launch, its vendor-neutral open-platform purpose, the silo-reduction and "secure, reliable, global, and performant access" goals, and founding operators including Equinor and Shell.
Energistics, "Energistics collaboration with the OSDU Forum." Source for the standards-as-foundation relationship and Energistics adding JSON schema definitions to align with OSDU's encoding.
Society of Petroleum Engineers / IADC, "Demonstration of the Drilling and Wells Interoperability Standard Framework in a Multi-Company Context" (D-WIS). Source for the SPE-affiliated machine-to-machine interoperability effort for drilling automation.
Journal of Petroleum Technology / SPE, "Transforming the Oil and Gas Industry: The Rise of Digital Drilling Operations." Supporting commentary that correlating siloed subsurface, real-time, and maintenance data is a prerequisite for operational and AI insight.
The Open Group, OSDU Forum member organizations. Source for the approximate figures of 190 member organizations and 16 major operators, cited as an indicator of strategic reach, not of productive deployment.
Energistics, WITSML Developers and Users and the certified-products listings. Signals used to gauge version status (1.3 deprecated, 2.0 no longer recommended, 2.1 current) and the breadth of the commercial 1.4.1.1 ecosystem.
Rig-site data generation (Table 4)
Pason, Pason WITS User Guide (DOCU225). Source for the Pason EDR sensor network and surface channels, and for WITS Level 0 output used for local and rig-to-office transfer.
Energistics, Pason EDR WITSML product certification form (2010). Historical source for a documented Pason WITSML service targeting WITSML 1.3.1 for time logs, depth logs, and surveys as of 2010; it is not evidence that the current service still targets 1.3.1. See also the Pason products overview.
Pason, "Pason DataLink: a faster, more streamlined drilling data solution." Evidence that Pason provides near-real-time WITSML data delivery. The page does not identify the WITSML version.
Energistics, WITSML v1.3.1 Certified Products. Evidence that Pason WITSML Service v2.1 was self-certified for WITSML 1.3.1 in November 2010.
Energistics, WITSML v1.4.1.1 Certified Products. The current public certification list reviewed for this article; Pason was not found on that list.
M. Al-Gharbi and others, "The Integration of Drilling Sensor Real-Time Data with Drilling Reporting Data at Saudi Aramco using WITSML." Evidence that Saudi Aramco implemented WITSML 1.4.1 for the transfer and storage of real-time wellsite data; it is not direct evidence of Pason's implementation.
Journal of Petroleum Technology / SPE, "Saudi Aramco Initiative Simplifies Real-Time Data Processing." Evidence that Saudi Aramco required multiple service providers and vendor systems to follow a common WITSML-based data architecture.
NOV, RigSense rig-site information system and the RigSense flyer. Source for RigSense as an EDR, its WITS, WITSML, Modbus, and OPC output, and its integration with NOVOS, Amphion, the e-Wildcat auto driller, and WellData.
PTC Kepware, WITS Level 0 driver, and B. Borofka, "WITS0 at the well site." Source for WITS Level 0 record behavior: time-based records at intervals down to about one second and depth-based records triggered on depth change.
Facts are attributed to Energistics, The Open Group, and SPE/IADC documentation. The architectural interpretation, including the separation of context, enterprise, and edge-control paths and the "necessary but not sufficient" framing, is labeled as WillCo analysis. The adoption figures in "The adoption picture in 2026" are directional WillCo analytical estimates as of September 2, 2026, not survey results or an official census. They are derived from Energistics version status, certified-product breadth, current vendor support, and public deployment signals; each figure is a share of the base stated next to it (primary real-time source feeds for what a source emits and for how much is converted; active WITSML endpoints or connections for the version breakdown; major operators for OSDU), and the bases differ by row. Central values are illustrative scenario midpoints, not measured market share, and the ranges express uncertainty. They are not attributable to Energistics or The Open Group. Precise auditable global counts by version are omitted where no reliable public figure was available. Illustrative diagrams are labeled as such.
Glossary of Acronyms
Acronym | Definition |
AI | Artificial intelligence |
API | Application programming interface |
ASCII | American Standard Code for Information Interchange |
D-WIS | Drilling and Wells Interoperability Standards |
EDR | Electronic drilling recorder |
ERP | Enterprise resource planning |
ETP | Energistics Transfer Protocol |
IADC | International Association of Drilling Contractors |
JSON | JavaScript Object Notation |
MDM | Master data management |
MWD | Measurement while drilling |
OPC | Open Platform Communications |
OSDU | Open Subsurface Data Universe |
OT | Operational technology |
PRODML | Production Markup Language (Energistics) |
RESQML | Reservoir Markup Language (Energistics) |
SCADA | Supervisory control and data acquisition |
SPE | Society of Petroleum Engineers |
WITS | Wellsite Information Transfer Specification |
WITSML | Wellsite Information Transfer Standard Markup Language |
XML | Extensible Markup Language |
Comments