Most drilling contractors already have the data an AI optimization platform needs — it is sitting inside the WITS (Wellsite Information Transfer Specification) stream flowing off the rig's data acquisition system every second, unused beyond a driller's screen and a paper depth log. Connecting AI to that existing stream does not require new sensors, a rig modification, or a change to the driller's workflow — it requires correctly mapping and consuming a data format the rig is already producing. This is a practical walkthrough of what that connection actually involves, channel by channel, so you know exactly what to ask your rig contractor for before booking a session with our drilling integration team.
Drilling AI · Rig Data Connectivity
Integrating AI With Your Drilling Contractor's Rig WITS Data
A field-level guide to connecting AI optimization to the WITS0 or WITSML stream already running off the rig floor — no new instrumentation, no rig downtime, no change to existing drilling operations.
Foundations
What WITS Actually Is, and Why the Format Matters
WITS was created decades ago as a standard so that any rig contractor's data acquisition system could hand off drilling parameters to any third-party monitoring system without a custom interface for every combination of rig and software vendor — the format itself is the reason AI integration is usually a configuration task rather than an engineering project. WITS0 transmits fixed-width ASCII records over a serial or TCP connection, organized into numbered records and item codes that each correspond to a specific drilling parameter, while WITSML is the newer XML-based standard that carries the same underlying parameters with richer metadata and easier validation. Almost every rig built or retrofitted with a modern data acquisition system outputs one or both formats as a standard feature, which means the AI connection point already exists on your rig today — it simply needs to be identified, opened, and mapped.
Channel Mapping
The WITS Parameters an AI Drilling Model Actually Uses
Not every WITS channel matters equally to an optimization model — a handful of parameters, updated at high frequency, drive most of the analysis, while dozens of secondary channels provide supporting context.
| WITS Record | Parameter | Typical Update Rate | Why AI Needs It |
|---|---|---|---|
| 01 | Bit Depth / Hole Depth | 1 second | Anchors every other parameter to a physical location in the wellbore |
| 01 | Rate of Penetration (ROP) | 1-5 seconds | Primary efficiency metric the optimization model is trying to maximize |
| 01 | Weight on Bit (WOB) | 1-5 seconds | Direct control input correlated with ROP and bit wear |
| 01 | Rotary RPM / Torque | 1-5 seconds | Detects stick-slip, bit whirl, and downhole vibration risk |
| 02 | Standpipe Pressure / Flow Rate | 1-5 seconds | Feeds hydraulics modeling and early kick/loss detection |
| 03 | Mud Density / Gas Units | 15-60 seconds | Supports well control and formation change detection |
Connection Process
Five Steps to a Working AI Data Feed
1
Identify the Output Port
Confirm with the rig contractor's data acquisition provider whether the rig exposes WITS0 over serial (RS-232/RS-485) or TCP/IP, and request the port, baud rate, or IP address and port number for the live feed.
2
Request the Item Code Map
Every rig configures which WITS records and item codes it populates slightly differently — get the specific mapping document for this rig rather than assuming a generic template applies.
3
Establish a Read-Only Connection
The AI platform connects as a passive listener on the WITS feed — it never writes back to rig control systems, which keeps the integration outside the rig's safety-critical control loop entirely.
4
Validate Against the Driller's Screen
Cross-check incoming depth, ROP, and WOB values against the driller's console over a short window before trusting the feed for optimization output, catching any channel mismatch early.
5
Enable the Optimization Model
Once the feed is validated, the AI model begins processing the live stream continuously, surfacing drilling parameter recommendations without any further manual data handling.
Format Comparison
WITS0 vs WITSML: Which One Is Your Rig Actually Sending
WITS0
The original fixed-width ASCII standard, transmitted over a raw serial or TCP socket. Still the most common format on older and mid-generation land rigs, and it remains fully sufficient for AI integration since the parameters carried are identical to WITSML's — only the wrapper format differs.
WITSML
An XML-based standard delivered via a web service, more common on newer rigs and offshore units. It carries richer metadata (units, timestamps, log context) alongside the same core parameters, which can simplify validation but is not required for a working integration.
What Actually Goes Wrong
Common Integration Issues and How They Get Resolved
Inconsistent Item Code Population
Some rigs populate a channel intermittently rather than continuously. The fix is confirming update behavior during validation rather than assuming every configured channel streams at a fixed rate.
Contractor Network Restrictions
Rig networks are often locked down for cybersecurity reasons. A read-only, outbound-only connection request is typically far easier for a contractor's IT team to approve than a bidirectional one.
Time Zone and Clock Drift
WITS timestamps can drift from actual rig-floor time on older acquisition systems. Synchronizing against a reliable reference during setup avoids misaligned depth-time correlation later.
Multiple Rigs, Different Vendors
A fleet running rigs from different data acquisition vendors will see minor formatting differences between rigs. A per-rig mapping profile, built once, resolves this permanently for that unit.
Confirm Your Rig's Output Format First
Not Every Rig Exposes the Same Channels the Same Way
Rig contractor data acquisition systems vary in which item codes they populate and how consistently they update them. Our team can review your specific rig's WITS output before any integration work begins, so nothing gets built against assumptions.
Security & Governance
Why a Read-Only Feed Passes Contractor IT Review Faster
Rig contractor IT and cybersecurity teams have become far more cautious about any third-party connection to rig systems over the past several years, and rightly so — a rig's control network sits close to safety-critical equipment, and any request that looks like it could write commands back into that environment tends to trigger a lengthy security review before approval. A WITS integration built as a passive, outbound-only listener sidesteps most of that review, because it is architecturally incapable of sending anything back to the rig regardless of how the request is configured. Framing the request this way to the contractor's IT team from the outset — not as a general "data connection" but specifically as a one-way, read-only WITS listener — is usually the single biggest factor in how quickly approval comes back.
Network Segmentation
The integration connects to the WITS output port specifically, not the broader rig control network, keeping the AI platform's access scoped to a single, well-defined data stream.
Outbound-Only Traffic
Data flows one direction, from rig to platform, with no return channel available for commands, configuration changes, or control signals of any kind.
Encrypted Transport
Where the connection leaves the rig's local network, transport-level encryption protects the WITS stream in transit, satisfying most contractor data-handling policies without additional custom configuration.
Auditable Access
Connection logs provide a clear record of when the feed was accessed and by what system, giving the contractor's security team a straightforward audit trail if one is ever requested.
Scaling Beyond One Rig
Sequencing a Fleet-Wide WITS Rollout Without Repeating the Same Delays
A single-rig WITS integration is mostly a matter of waiting on one contractor's approval and mapping one item code set, but a multi-rig rollout across a fleet introduces a coordination problem that catches many operators off guard the first time they attempt it — different contractors, different data acquisition vendors, and different internal approval processes running in parallel rather than in sequence. The operators who scale fastest treat the first rig as a template-building exercise rather than a one-off task, documenting the exact request language, port details, and item code mapping process that worked, then reusing that documentation to accelerate every subsequent contractor conversation instead of starting the security review conversation from scratch each time.
| Rollout Stage | Typical Activity | Common Bottleneck |
|---|---|---|
| Rig 1 (Pilot) | Full port identification, item code mapping, and validation from scratch | Contractor IT review turnaround time |
| Rigs 2-5 | Reuse pilot documentation, adjust for vendor-specific item code differences | Coordinating multiple contractor contacts in parallel |
| Fleet-Wide | Standardized request template sent to every contractor simultaneously | Rigs with older acquisition systems lacking a modern WITS output |
Applied Example
What a First-Week Integration Typically Looks Like
Consider a land rig running a mid-generation data acquisition system already outputting WITS0 over a TCP connection for a third-party mud logging unit — a common setup on rigs that have been in service for several years. The integration conversation starts with a request to the contractor's data acquisition provider for the existing TCP endpoint details and the item code map already in use by the mud logging connection, since a second read-only listener can typically share the same output port without requiring any change to the rig's existing configuration. Once the port and item codes are confirmed, validation against the driller's console usually takes less than a day, because the mud logging unit's own display provides an immediate cross-check for depth, ROP, and WOB values. Where the process stretches out is almost always the contractor's internal approval timeline rather than the technical work itself, which is why starting that conversation early and framing it clearly as read-only access matters more than any other single factor in how quickly the rig goes live.
"
The most common misconception I run into is that connecting AI to a rig means adding hardware or asking the contractor to change how they operate. In reality, the WITS feed has been sitting there the whole time, and the integration conversation is almost always a data-mapping conversation, not an engineering one. The rigs where this goes smoothly are the ones where the operator gets the item code map from the contractor upfront instead of discovering channel gaps mid-well. Once the read-only feed is validated against the driller's own screen, the rest of the connection is routine.
Marguerite Okonkwo-Feldstein
Drilling Data Systems Consultant · 14 years in rig data acquisition and real-time drilling optimization · Former Rig Data Coordinator, land drilling operations
Rig Data Questions
WITS Integration — Frequently Asked
Does connecting AI to WITS data require the rig contractor to install anything new?
No new hardware is typically required on a rig with a modern data acquisition system — the WITS output already exists, and the integration only needs the contractor to open or share access to an existing port or service. Book a session to confirm what your specific rig setup requires before any work begins.
Can the AI platform accidentally interfere with rig control systems through this connection?
The integration is built as a read-only, passive listener on the WITS stream, meaning it never writes commands back into rig control or safety systems and sits entirely outside that control loop. Book a demo to review the exact connection architecture for your rig.
What if our rig only outputs WITS0 and not WITSML?
WITS0 carries the same core drilling parameters as WITSML and is fully sufficient for AI optimization — the majority of rigs we integrate with run WITS0 over serial or TCP without any issue. Contact support if you are unsure which format your rig currently outputs.
How long does a typical single-rig WITS integration take?
Once the item code map and port details are confirmed with the contractor, most single-rig integrations are validated and streaming within a few days, with the bulk of the time spent waiting on contractor IT approval rather than technical setup. Book a call to scope a timeline for your fleet.
Does this work across a fleet of rigs from different contractors?
Yes — each rig gets its own mapping profile since item code population varies by vendor and configuration, and once built that profile is reused for every well drilled on that specific rig going forward. Talk to our team about fleet-wide rollout sequencing.
Your Rig Is Already Producing the Data
Connect AI to the WITS Feed You Already Have
iFactory maps your rig's WITS0 or WITSML output, validates the feed against your driller's own console, and enables real-time drilling optimization without new hardware or a change to rig-floor operations.
