Beyond WITSML: Turning High-Frequency Rig Data into Edge Decisions
How Modbus, OPC UA, and edge platforms connect measurement, analytics, and control, and why drilling still lacks a common control-layer contract. The last piece explained the standards that move well data to the office: WITSML, ETP, and OSDU. This one goes the other direction, down to the control floor, where signals are sampled far faster than the office ever sees, where Modbus and OPC UA do the talking, and where no shared, openly governed standard yet plays the role WITSML plays upstairs. That gap is where much of the value in high-frequency drilling data is lost.
The previous WillCo article, From Rig Data to Drilling Autonomy, made a point in passing that deserves its own piece. An application reasoning about a well draws on two very different data paths. One is a read-oriented context path: structured, discoverable well data assembled for analysis and decision support, the path WITSML, ETP, and OSDU are built to serve. The other is a low-latency edge-control path: the fast, noisy, high-volume signal traffic between sensors, controllers, and machinery on the rig itself. The first article followed the context path all the way to the office. This one follows the edge-control path down to where the data is actually generated.
The distinction matters because the two paths have opposite priorities. The context path optimizes for shared structure, discoverability, and openly governed meaning, and it can tolerate latency measured in seconds or minutes. The edge-control path optimizes for speed, determinism, and volume, and it tolerates almost no latency at all. A closed-loop control action that has to wait on an office round trip is not control. So the industry solved the two problems with two different technology stacks, and the stack at the edge never received the equivalent of a WITSML: a single, neutrally governed data standard that gives high-frequency rig data shared structure and meaning. Understanding why, and what to do about it, is the difference between capturing the value in high-frequency data and paying to generate it and then throwing it away. The two-path model and the architectural recommendations that follow are an engineering interpretation of the cited standards, product documentation, and drilling-dynamics literature
🔊 Where high-frequency data is born, and the many clocks in between
The phrase "real-time drilling data" usually describes the surface stream: hook load, block position, standpipe pressure, rotary speed, torque, flow, and the rest, delivered to the office through WITS Level 0 and, increasingly, WITSML. Office-facing surface feeds are commonly configured around one sample per second, although WITS and WITSML do not prescribe a universal one-hertz rate and implementations vary. That surface picture is the resolution many office systems, dashboards, and analytics ever see. It is also a small fraction of what the rig actually measures.
It helps to be precise about what "frequency" even means here, because one quoted number hides a chain of very different clocks. A measurement passes through at least six of them, and each can throttle the one after it:
The single "sampling rate" people quote is usually just the first clock, while the value that reaches an office dashboard is gated by the slowest link in the chain. Treating one frequency as a proxy for the whole system is the first mistake that wrecks a high-frequency data plan. The rate that matters depends on which clock you mean and where in the chain you are standing.
Downhole, the physics moves far faster than the surface report. Drillstring vibration, a recognized contributor to downhole tool failures and inefficient drilling, lives in frequency bands that a once-per-second report cannot represent. Published drilling-dynamics literature groups the main destructive modes into axial bit bounce in the low single-digit-hertz range, torsional stick-slip oscillation from a fraction of a hertz up to a few hertz, and lateral whirl reaching into the tens and low hundreds of hertz; the exact band edges vary by drilling system, study, and author and are best read as approximate. And at the bit itself, purpose-built downhole tools have captured dynamics far above anything the surface sees. One documented drill-bit and motor system embedded three-axis acceleration sensors that recorded continuously at 1,600 hertz, an example of a specific in-bit measurement system rather than a resolution that is continuously available at surface.
The gap between those two rates is the whole subject of this article. High-frequency signals exist and they can carry information needed to detect these dysfunctions and, when combined with validated control logic and appropriate authority, support mitigation of the very failures that cost rig time, but much of it is generated only intermittently or held in downhole memory rather than streamed live. The reason it often does not drive decisions is seldom a single missing sensor. It is that the resolution is reduced or delayed on the way up, that some of it never leaves downhole memory, and that the data which does stay at the edge is spoken in languages built for machine control, not for analysis. To capitalize on it, you have to meet the data where it lives, and that means understanding two of the most consequential and widely encountered protocols at the control floor.
🔧 Modbus: the workhorse that does not describe itself
If you open the panel on a piece of rig equipment and ask how it exchanges data, the answer is very often Modbus. Introduced by Modicon in 1979 for its programmable logic controllers and later placed in the public domain, Modbus is one of the oldest and most widely deployed industrial protocols in existence. It is simple, it is free, and it remains widely supported across the controllers, sensor packages, and instruments found on a rig, whether serial (Modbus RTU) or over Ethernet (Modbus TCP); its actual presence and configuration are equipment- and vendor-specific. That broad support is exactly why it still matters. It is a common language of the equipment layer.
Its strengths are also its limits. Modbus organizes everything into a flat map of numbered registers: coils and discrete inputs for single bits, input and holding registers for sixteen-bit values. A client reads or writes a register by its address, and that is essentially the entire model. Nothing in the protocol tells you what register 40521 means, what engineering units it carries, how it should be scaled, or whether it is standpipe pressure or a motor temperature. The protocol is not self-describing. That knowledge lives in a separate register map, typically a vendor document, sometimes a spreadsheet, and it has to be applied correctly by whoever integrates the device. Modbus also has no built-in security, no authentication or encryption in the base protocol, and it follows a polling model in which a client must repeatedly ask each device for its current values.
None of this makes Modbus wrong. For simple, low-level machine communication it is proven and appropriate. Its timing, though, is not fixed by the protocol: how deterministic a Modbus exchange actually is depends on the implementation, the device, the polling scheme, the size of the register block, the transport, and the network load. And it means the raw edge signal arrives as anonymous numbers whose meaning is external to the data itself. Any attempt to capitalize on high-frequency Modbus data at scale runs straight into the same wall the office side hit before WITSML: without shared, machine-readable meaning, every integration is a bespoke translation, and every translation is a place for the meaning to be lost or applied wrong.
🔒 OPC UA: semantics, security, and streaming
The protocol built to answer that problem is OPC UA, OPC Unified Architecture, released by the OPC Foundation in 2008 and standardized internationally as IEC 62541. OPC UA is the modern successor to the older, Windows-bound OPC Classic, and it was designed for the job Modbus cannot do: carrying not just values but their meaning. Its core is an object-oriented information model that can be self-describing. A temperature on an OPC UA server can be exposed not as a bare number at an address but as a node carrying a data type, engineering units, a timestamp, a quality flag, and defined relationships to the asset it belongs to. How much of that is actually present depends on how the server's information model was built: a browsable address space is an enabler, not a guarantee. Industry groups publish OPC UA companion specifications that standardize these models for particular domains, so a class of equipment can expose its data the same way across vendors, but only where those vendors implement the same companion specification. Without a shared, governed information model, OPC UA moves the mapping problem rather than eliminating it.
OPC UA also closes Modbus's other gaps. Security is built into the architecture, with authentication, encryption, and signing available at the session level rather than bolted on afterward. It supports both the traditional client-server pattern and a publish-subscribe model, so data can be pushed to subscribers as it changes instead of polled for. And recent work extends the standard toward the deterministic, real-time controller-to-controller traffic that used to require dedicated fieldbuses. OPC UA Field eXchange, or UA FX, extends OPC UA toward field-level and controller-to-controller communication. Implementations may use TSN-enabled Ethernet where deterministic networking is required, but UA FX and "OPC UA over TSN" should not be treated as exact synonyms. The work is still maturing and depends on the right network profile and hardware. The direction of travel is clear: OPC UA is positioning itself as a semantic, secure layer for operational-technology data, the kind of role WITSML fills upstream.
🏭 The control stack: PLCs, DCS, SCADA, and the Purdue model
Protocols do not float in space; they connect layers of a control system. This article uses a Purdue and ISA-95-inspired hierarchy as a reference model. It stacks an operation into levels: physical sensors and actuators at Level 0; the programmable logic controllers (PLCs) and distributed control systems (DCS) that run fast, deterministic control loops at Level 1; the supervisory control and data acquisition (SCADA) and human-machine interfaces that monitor and coordinate at Level 2; manufacturing or operations management at Level 3; and enterprise business systems at Level 4. Actual rig architectures vary, and the placement of the operational-technology to information-technology boundary, commonly drawn between Levels 2 and 3, is an engineering and governance decision rather than a universal physical line. That boundary is the pivotal divide in this discussion.
On a rig, this is not an abstraction. Modern rig control systems sit squarely in the lower Purdue levels: NOV's Amphion and Cyberbase control platforms and the NOVOS process-automation layer that runs on top of them, and Nabors' SmartROS rig operating system with its RigCLOUD edge-computing hardware, all operate at the machine and supervisory levels where control loops actually close. Their electronic drilling recorders and rig-site information systems, such as NOV's RigSense, connect to the office through the protocols discussed above. NOV describes RigSense as an electronic drilling recorder for rig-site data; a separate NOV Connect product flyer lists WITS, WITSML, OPC, and Modbus interfaces, so that specific capability is best attributed to that document and configuration rather than to RigSense in general. The high-frequency data is generated and consumed down in Levels 0 through 2, at millisecond scan rates, for control. What escapes upward to Levels 3 and 4, the office, the historian, the cloud, is deliberately reduced, because moving everything at full rate across the OT-IT boundary is neither necessary for control nor, historically, practical.
📡 Orchestration at the edge: MQTT, the Unified Namespace, and the historian
Between the raw protocols and the office sits a fast-growing orchestration layer, and this is where the practical opportunity is. Rather than pushing high-frequency data straight to the cloud or leaving it stranded in a controller, operators often land it first on an edge platform that can filter, contextualize, and route it. Three ideas recur at that layer.
The first is MQTT with Sparkplug. MQTT is a lightweight publish-subscribe messaging protocol; Sparkplug, governed by the Eclipse Foundation, is an open specification that adds industrial structure on top of it, including a report-by-exception model that transmits values only when they change, and birth messages that announce the metrics and state of participating nodes and devices, together with death certificates that notify consumers when a node goes offline, reducing the need for polling. It is efficient for state, events, and contextualized industrial metrics, making it useful in an edge orchestration layer. It should not automatically be treated as the transport for lossless raw kilohertz waveforms; those streams may require local buffering, specialized acquisition paths, or separate time-series transport before selected features and events are published through MQTT/Sparkplug. The second is the Unified Namespace (UNS). In this article, Unified Namespace refers to an event-driven, structured operational-data hierarchy through which authorized producers and consumers exchange current state, so that data is organized by what it represents rather than by which system produced it. UNS is an architectural pattern, not a single formally governed standard. The third is the historian, the time-series database that has anchored industrial data for decades, of which the AVEVA PI System (formerly OSIsoft PI, acquired by AVEVA in 2021) is a long-established and widely used example in oil and gas.
Put together, these give the edge something the raw protocols do not: a place to turn anonymous samples into contextualized, structured, subscribable information before anything decides what is worth sending upstairs. That is the mechanism by which high-frequency data becomes usable rather than merely voluminous.
One boundary has to stay fixed as this layer grows, and it is a safety boundary as much as an architectural one. An edge platform can observe a signal, compute a metric, advise an operator, and even request a bounded change of intent, for example a target set-point inside a pre-approved envelope. It should not become the thing that arbitrates the final command. Interlocks, limit enforcement, and last-word control belong in the certified control system, where they can be tested and held accountable. The distinction between observe, advise, request an intent, and issue a command is not pedantic; it is the line that keeps an analytics layer from quietly becoming an untested controller. This recommendation is consistent with NIST guidance to protect operational-technology performance, reliability, and safety constraints: analytics may observe, advise, or request bounded intent, while final command authority should remain in the tested control architecture, and high-rate measurement does not by itself justify closing a control loop without synchronized time, state, authority, safety limits, and testing.
⚠️ The missing layer: there is no WITSML for the control floor
Here is the uncomfortable part, and it is the reason this article exists. Upstream, the industry has a single, openly governed, vendor-neutral standard for well data, WITSML, plus a transfer protocol, ETP, and a shared platform, OSDU. Downstream, at the edge, it does not have the equivalent. It has Modbus, which does not describe itself. It has OPC UA, which does, and which is a strong candidate for that role, but which coexists with Modbus, proprietary controller protocols, MQTT and Sparkplug, and a long tail of legacy fieldbuses rather than replacing them. There is no neutrally governed, universally adopted data standard that guarantees a high-frequency drilling signal means the same thing across every vendor's equipment. That absence is the core finding of this piece, offered as analysis rather than a cited figure: by way of an analogy to the upstream world, the control layer of drilling has no single WITSML-equivalent standard the way the office side does.
The industry is aware of the gap and is working several angles at once, though none is finished. OPC UA companion specifications extend semantic models to more equipment classes. The Open Group's Open Process Automation Standard (O-PAS), developed through the OPAF forum, aims at a standards-based, interoperable control architecture and builds on OPC UA. The NAMUR Open Architecture (NOA) offers a way to extract monitoring and optimization data from control systems without disturbing the certified control path. And IEEE Time-Sensitive Networking (TSN, the 802.1 family) supplies the deterministic Ethernet foundation that OPC UA over TSN needs. These are the right ingredients, but they are converging slowly, they compete and overlap, and much of this work is driven by the process industries at large rather than by drilling.
🧩 D-WIS: drilling's own answer to the gap
Drilling does have an effort aimed squarely at this problem: D-WIS, the Drilling and Wells Interoperability Standards workgroup, an SPE-affiliated group developing an interoperability framework for well-construction systems, including reference architecture, shared semantics, contextual data, process protection, and interfaces between advisory applications and automated drilling control systems. D-WIS is where the lessons of the WITSML era are being turned toward the next problem: not just structuring well data for the office, but building shared structure across the systems that run the well. That matters for this article, because the edge-control path runs in two directions. One direction reads high-frequency data up from sensors, the subject of most of this piece. The other sends commands down to actuators and downhole tools. The command direction has been every bit as fragmented as the sensor direction, typically requiring a custom integration for each vendor's tool. Standardizing that command interface, not the algorithm behind it, is the change that matters most: a rig control system that can command whichever tool is downhole, without a bespoke build per tool, is an important precondition for scalable closed-loop steering, just as a self-describing sensor feed is a precondition for reasoning over high-frequency data.
The honest summary for anyone planning to build on this layer: design for a heterogeneous, standard-poor environment, because that is what it will be for years, while treating efforts like D-WIS as the direction of travel worth tracking and, where you can, shaping.
📈 How to capitalize: process at the edge, then bridge up
The practical strategy follows directly from the architecture. For most high-frequency data, shipping complete raw streams to the cloud should not be the default; bandwidth, cost, and latency make that the wrong starting point, and the office rarely needs every sample. Process the data where it is generated and send upward the information that carries decision value, while retaining or transferring raw streams when a defined requirement such as reprocessing, investigation, model development, or long-term retention justifies it.
In practice that means four moves, in order. First, acquire at the right rate. If you need to see stick-slip or whirl, you have to sample fast enough to represent them, which means capturing at the edge, not settling for the one-hertz surface stream. Second, contextualize at the edge. Attach meaning, units, quality, and asset identity to the raw values as early as possible, using OPC UA information models or a Unified Namespace where you can, and disciplined register mapping where you cannot. This is the step that turns anonymous Modbus registers into data an analytics layer can trust. Third, compute and reduce locally. Detect the event, compute its severity, calculate a response recommendation or pass a bounded request to the certified control system, and forward the result and the relevant data window rather than the entire raw stream. Where governance, system certification, safety logic, and control ownership permit, the edge application may also support closed-loop execution through the certified control system rather than bypassing it. Fourth, bridge the reduced, contextualized results into the office data path, using WITSML where a suitable object and agreed mapping exist, ETP where its streaming protocols fit the exchange, and an OSDU-aligned platform after ingestion, mapping, access control, and provenance are defined. Where its channel-streaming or notification protocols fit the use case, ETP can carry reduced, contextualized application data above the immediate control loop. It is therefore best seen as one possible seam between the edge and the office, not as a PLC control bus or deterministic command interface, and it does not belong inside the real-time control loop; the hand-off it serves sits above that loop.
Done this way, the two data paths stop competing and start reinforcing each other. Processing at the edge can preserve the latency and determinism required by the certified control architecture when synchronization, networking, scheduling, safety logic, and control ownership are designed to support it. The office gets contextualized, standardized data it can actually reason over. And the high-frequency signal that used to be generated and discarded becomes the input that makes real drilling optimization and, eventually, autonomy possible. In many cases the limiting condition has not been the algorithm at all but data fidelity and integration: the richest data never made it out of the basement in a form anything could use, at a rate and quality it could trust.
📚 References and further reading
Edge and control protocols (primary sources)
Modbus Organization, Modbus specifications and implementation guides. Source for Modbus origin at Modicon in 1979, its public-domain status, the register-based data model (coils, discrete inputs, input and holding registers), the polling model, and the absence of security in the base protocol (with security added separately via the Modbus Security specification).
OPC Foundation, Unified Architecture (OPC UA). Source for OPC UA's 2008 release, its self-describing information model, built-in security, client-server and publish-subscribe communication, and companion specifications. Its international designation as IEC 62541 is confirmed by the OPC Foundation's IEC 62541 publication notice.
OPC Foundation, OPC UA Field eXchange (UAFX) specifications (released November 2022). Source for the extension of OPC UA toward deterministic controller-to-controller communication over Time-Sensitive Networking.
OASIS, MQTT Version 5.0 OASIS Standard (approved March 2019). Source for MQTT as a lightweight publish-subscribe messaging protocol governed as an open standard.
Eclipse Foundation, Eclipse Sparkplug specification. Source for Sparkplug as an open MQTT-based specification with report-by-exception and birth/death certificate mechanisms for industrial data.
IEEE 802.1, Time-Sensitive Networking (TSN) Task Group. Source for TSN as the deterministic Ethernet foundation underlying OPC UA over TSN.
Control architecture and rig systems
International Society of Automation, ISA-95 standard, related to the Purdue Enterprise Reference Architecture. Source for the level model (Levels 0 to 4) used here as a reference hierarchy and for the operational-technology to information-technology boundary, which this article treats as an engineering and governance convention rather than a universal physical line.
NOV, NOVOS process-automation platform and the Amphion and Cyberbase control systems. Source for rig control platforms operating at the lower control levels.
NOV, RigSense rig-site information system. Source for RigSense as an electronic drilling recorder and rig-site information system. The WITS, WITSML, OPC, and Modbus interfaces are listed in NOV's separate Connect rig-site data-aggregation flyer and are attributed to that specific document and configuration.
Nabors Industries, SmartROS rig operating system and the RigCLOUD edge-computing platform and Corva alliance. Source for a rig operating system with edge-computing infrastructure at the rig site.
AVEVA, PI System (formerly OSIsoft PI). Source for the historian as an established industrial time-series data store. AVEVA completed its acquisition of OSIsoft in 2021, as documented in the Schneider Electric / AVEVA acquisition release.
K. Stouffer et al., Guide to Operational Technology (OT) Security, NIST Special Publication 800-82 Revision 3, September 2023. Source for the principle that operational-technology performance, reliability, and safety constraints govern where control authority may reside.
Standardization efforts and the bridge upstream
The Open Group, Open Process Automation Forum (O-PAS). Source for the standards-based, interoperable control-architecture effort that builds on OPC UA.
NAMUR, NAMUR Open Architecture (NOA). Source for extracting monitoring and optimization data from control systems without disturbing the certified control path.
Society of Petroleum Engineers / IADC, "Demonstration of the Drilling and Wells Interoperability Standard Framework in a Multi-Company Context" (D-WIS). Source for D-WIS as the SPE-affiliated machine-to-machine interoperability effort for well construction.
Energistics (an affiliate of The Open Group), Energistics Transfer Protocol (ETP). Source for ETP as a data-transfer specification supporting real-time streaming, asynchronous exchange, discovery, notifications, and data-object operations. Its possible use as a bridge between edge applications and the standardized office data path is WillCo analysis. See also the ETP v1.2 specification.
The Open Group, OSDU Forum. Source for OSDU as an open subsurface and wells data platform; discoverability through OSDU depends on prior ingestion, mapping, access control, and provenance rather than following automatically from an edge feed.
High-frequency drilling dynamics
J. Sugiura and S. Jones, "A Drill Bit and a Drilling Motor with Embedded High-Frequency (1600 Hz) Drilling Dynamics Sensors Provide New Insights into Challenging Downhole Drilling Conditions," SPE Drilling & Completion 34(3): 223-247, 2019 (SPE-194138-PA; conference version SPE-194138-MS). Source for downhole three-axis acceleration recorded continuously at 1,600 Hz by an in-bit and in-motor sensor system.
A. Bowler, R. Harmer, L. Logesparan, J. Sugiura, B. Jeffryes, and M. Ignova, "Continuous High-Frequency Measurements of the Drilling Process Provide New Insights into Drilling-System Response and Transitions Between Vibration Modes," SPE Drilling & Completion 31(2): 106-118, 2016 (SPE-170713-PA). Source for the axial (bit bounce), torsional (stick-slip), and lateral (whirl) vibration-mode taxonomy and for continuous high-frequency measurement of the drilling process, with the measurement system capturing roughly 50 to 2,000 Hz. The specific band edges shown in this article's figure are representative approximate ranges; see Zhang et al. below.
L. Tang, B. Guo, X. Zhu, C. Shi, and Y. Zhou, "Stick-slip vibrations in oil well drillstring: A review," Journal of Low Frequency Noise, Vibration and Active Control 39(4), 2020. Source for the stick-slip taxonomy and its characterization as a recognized, well-studied drilling-dynamics problem; reported share-of-drilling-time figures vary by study and are not asserted in this article.
Y. Zhang, H. Zhang, D. Chen, P. Ashok, and E. van Oort, "Comprehensive review of high frequency torsional oscillations (HFTOs) while drilling," Journal of Petroleum Science and Engineering 220: 111161, 2023. Source for representative drilling-vibration frequency ranges, including bit bounce, stick-slip, and whirl. The ranges remain approximate and system-dependent.
Energistics, WITSML data standards, with PTC Kepware, WITS Level 0 driver (supplemental). Source for surface real-time drilling data being reported on configurable time or depth intervals, commonly on the order of seconds rather than at downhole dynamics rates. No primary source fixes an exact one-second surface specification.
Source note: Technical claims are based on the standards, peer-reviewed publications, and vendor documentation listed above. Architectural frameworks and recommendations are WillCo analysis. Frequency ranges are approximate and system-dependent; diagrams are illustrative.
Comments