Most drilling analytics platforms look alike in a demonstration: live curves, a rig-state band, a KPI dashboard. The differences that matter show up later, on your rig's data, at 3 a.m., when the satellite link drops or a model disagrees with an engineer's hand calculation. This guide sets out the questions and tests that separate platforms, how to run a trial that produces evidence, and a worked scoring example that shows why gates come before points.
Start from the decisions
Write down, before any vendor meeting, which decisions the platform must support and who makes them. A drilling engineer planning casing and torque and drag, a superintendent watching connection times across a fleet, a cost engineer tracking an AFE and a rig team on night shift need different things. List the wells and rigs it must cover, the data you already have (WITSML servers, WITS feeds, daily reports, historical logs) and the rules that apply to that data. Everything below is scored against that list.
Then split the requirements in two. Gates are pass or fail: a platform that cannot read your rigs' data, cannot run where your data rules require, or cannot reproduce a hand check is out, whatever else it does well. Scored criteria are the ones where more is better: latency, workflow fit, the licence model. Agree the gates and the weights in writing before the trial starts, so the evidence decides.
Data in: ingestion and WITSML
Every other capability depends on getting clean data in. Ask which WITSML versions the platform reads (1.3.1.1, 1.4.1.1, 2.0 over ETP), whether it takes WITS0 directly from the rig, and how it imports LAS and CSV for historical wells. Ask how source curves are mapped to standard channels and units, and whether a mapping with the wrong unit class is refused or silently accepted. Ask what happens after a link outage: does it re-read the gap, and how do you know it did?
Then test it on your own servers. Connect to one rig's WITSML server during the trial, ingest a finished well, and compare row counts, time ranges and gaps against the server. Unplug the link for an hour and check that the gap fills. What WITSML is and WITSML 1.4.1 against 2.0 cover the standard itself.
Physics you can check by hand
Engineering results are only useful if engineers trust them, and trust comes from being able to check them. For each engineering module, ask for the method in writing: the equations, the assumptions, the standard it follows, and a worked example with a hand calculation. Then bring your own checks to the trial. A good set takes an afternoon:
- Torque and drag: one stand of drill pipe lying in a horizontal lateral. Buoyed weight times friction gives the drag per stand, and the model's rise in pick-up over the lateral should agree within a few per cent. The torque and drag worked example shows the calculation.
- Hydraulics: the pressure loss across the bit nozzles at one flow rate, from the nozzle equation.
- Well control: kick tolerance at the shoe for one kick volume and intensity.
- Cost: the estimate at completion at one report, rebuilt from spent, the daily rate, the days left and the one-off lines, as in the AFE worked example.
Agree the tolerance first, typically 5 %. A difference is acceptable if the vendor can explain it, for example a model that includes the BHA's extra contact where the hand check does not. A difference nobody can explain fails the gate.
Rig-state accuracy on your own wells
Rig-state detection underpins every KPI: connection times, tripping speeds, on-bottom ROP, invisible lost time. Accuracy claims made on the vendor's data mean little, because rigs differ in their sensors, block heights, slips practice and pump schedules. Take three or four days from two of your own wells, covering drilling, connections, trips and circulating, and have an engineer label the states by hand from the curves. Then score the platform's states against the labels, minute by minute and state by state, and compare connection times stand by stand.
Ask how corrections work. Engineers will disagree with the detector sometimes; the platform should let them correct a period, keep the correction on record and recompute the KPIs, without overwriting the raw states. Ask too whether it can reconcile the daily drilling report against the detected states: that is where hidden lost time shows up, as the daily reports worked example shows.
Latency, sensor to screen
Treat real time as a measured number. Latency is the sum of a chain: the sampling interval at the rig, how often the acquisition system writes to its WITSML server, the link, how often the platform polls, and the push to the screen. Ask each candidate to fill in that chain with its own settings. Then measure it: note the rig clock time of a clear event, such as pumps off, twenty times during the trial and record when each one appears on screen. Report the median and the 95th percentile, not a best case.
Check how the platform marks old data. A screen that shows a value without its age invites decisions on stale numbers. Fresh, stale and dead should be judged from each reading's own time stamp.
Offline, on-premises and security
Ask where the platform can run: on your own servers, in a cloud region of your choice, at the rig. Ask what keeps working when the rig's link drops, how much the rig side buffers, and how long it takes to catch up afterwards. Data residency rules in many countries require drilling data to stay in-country; that is usually a gate. The on-premises deployment guide works through the buffering and catch-up.
For security, ask for specifics: single sign-on, two-step sign-in, access per module and per well, an audit log of account and access events, encryption of stored credentials, and whether anything the platform does can send commands to rig equipment. Ask for the latest independent penetration test summary and the information-security standard the vendor works to.
The licence model
Drilling platforms are licensed in a few common ways: by the rig-day, by the rig-month, per well, or as an annual licence for a fleet, sometimes per module and sometimes per named user. None is better in general; the right one follows your activity. The questions are about the edges:
- What starts and stops a rig-day: rig on contract, spud, rig release? Are standby and moving days charged?
- Are historical wells, read-only users and office engineers included?
- Which modules are in the licence, and what does adding one later involve?
- What happens at the end: in which formats can you export all your data, and how quickly?
Model the total cost over two or three years on your real rig schedule, including the internal effort to connect and maintain data sources, which is often larger than the licence.
Designing the trial
A trial produces evidence when it is designed like a test. Four to eight weeks is usually enough. Give every candidate the same data: two finished wells to replay and one live well. Fix the success criteria, the gates and the weights in writing before it starts, name an owner on each side, and keep a shared log of every issue and how long it took to resolve. Score at the end, with the evidence attached to each score.
A worked scoring example
The example below is hypothetical. Two unnamed candidates, A and B, are scored from 1 to 5 on eight criteria whose weights add up to 100. Each criterion's points are its weight times the score, divided by 5, so a perfect platform scores 100. The scores are invented to show the method; they describe no real product.
- Candidate A: 77 points, passes every gate
- Candidate B: 80 points, fails the hand-check gate
Illustrative only: two hypothetical candidates with invented scores (1 to 5) on weights that add up to 100, to show the method. The weight is in brackets after each criterion.
Show the data
| Candidate A | Candidate B | |
|---|---|---|
| WITSML and data ingestion (15) | 12 | 15 |
| Physics vs hand checks (15) | 12 | 6 |
| Rig states on your wells (15) | 12 | 12 |
| Latency to the screen (10) | 6 | 10 |
| Offline and on-premises (10) | 10 | 6 |
| Security and access (10) | 8 | 8 |
| Workflow and report fit (15) | 9 | 15 |
| Licence and total cost (10) | 8 | 8 |
On points, B wins: 80 against 77. B ingests data better, is faster and fits the workflows better; A runs offline and its physics matched the hand checks. But B failed a gate: its torque and drag results disagreed with the trial's hand checks by more than the agreed tolerance, and the difference could not be explained. Under the method agreed at the start, B is out before the points are added up.
The arithmetic carries a second lesson. One score step on a criterion weighted 15 is worth 3 points. B's whole lead is 3 points, so a single changed judgement on any of the four criteria weighted 15 ties or reverses the ranking. A lead that small is within the noise of a scoring panel. When totals are that close, decide on the gates and the evidence, and treat the points as a tie.
A checklist for the evaluation team
- Write down the decisions, users, wells and data rules before meeting any vendor.
- Agree gates and weights in writing before the trial, and score with the evidence attached.
- Connect to your own rig's WITSML server and check row counts, gaps and gap filling after an outage.
- Bring hand checks for each engineering module and a tolerance; fail any difference nobody can explain.
- Label a few days of your own data by hand and score the rig states and connection times against it.
- Measure latency from a rig event to the screen twenty times; report the median and the 95th percentile.
- Test the link outage, the data residency, the access controls and the data export.
- Treat totals within one score step of a heavy criterion as a tie.
How DrillIQ handles it
DrillIQ is built to be tested this way. Its WITSML module reads 1.3.1.1 and 1.4.1.1 servers, WITS0 and LAS or CSV files, maps channels with unit checks, and re-reads gaps after outages. Its engineering engines document their methods, and the worked examples on this site were run with them, with hand checks. KPI & Rig State detects rig states from surface sensors, keeps engineers' corrections on record and reconciles daily reports against the detected states. DrillIQ runs as one server on-premises or on a cloud server, with an agent at each rig that buffers through link outages; access is set per module and per well with an audit log, and licences are signed files for the modules you use, by the rig-day, by the month or yearly.
Book a demo See all capabilities
References
- Energistics. WITSML Data Schema, version 1.4.1.1.
- ISO/IEC 25010:2011. Systems and software engineering: systems and software quality requirements and evaluation (SQuaRE), system and software quality models.
- ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection: information security management systems, requirements.