On-premises deployment and drilling data sovereignty

Drilling data is commercially sensitive and, in many countries, subject to rules about where it may be stored and processed. Where a platform runs therefore decides whether it can be used at all. This article sets out the usual reasons for keeping data in-country or on-premises, what runs at the rig and what runs in the office, how much a rig must buffer when its link drops and how long it takes to catch up, and how updates and security work.

Why data residency comes up

Four pressures usually decide where drilling data may live.

• National rules. Several producing countries treat subsurface and well data as national property, or require approval before it is stored or processed abroad. The rules differ between countries and change over time, so treat residency as a question for your legal team, answered in writing for each country you drill in.
• Company policy. Exploration and appraisal data is often classified, because it shows what a company knows about its acreage before partners or competitors do. Policy may limit where it is stored and who outside the company can see it.
• Partners and contracts. Joint-venture agreements set what each partner may receive. Service contracts set who owns the data a provider records and where the provider may hold it.
• Network security. A rig network carries control systems. Security policy, often built on the IEC 62443 series, limits which connections may enter or leave it.

There is a practical reason too: rig links drop. A system that stops working when the satellite does can't be relied on at the rig. Together these come down to three questions for any platform. Where is the data stored? Who can reach it? What leaves each network, and when?

What runs where

Two parts of DrillIQ matter here: an agent at the rig, and a server that can sit wherever policy allows.

The server is the same software in either place: a Python backend and a web application, with its data held in local database files in one folder. On-premises, it runs on the operator's own hardware, in the operator's own country if policy requires. The web application can be built with only the licensed modules in it, and the server loads only the modules the licence lists, so the others neither ship to the browser nor run. The choice between on-premises and cloud is about where the machine sits and who looks after it; the software and its features are the same.

At the rig, Rig Connect reads WITS0 over TCP, UDP or a serial line, Modbus and OPC UA devices, a rig-site WITSML server, and LAS or CSV files dropped in a folder. It sends to one place only: the DrillIQ store it was enrolled with. Its settings page opens only on the rig PC itself, and its data folder is readable only by the system and administrators.

What leaves each network

For a residency review, list every connection that crosses a boundary. For DrillIQ the list is short:

• From the rig: the agent's signed writes to its enrolled store. Its reads of rig devices stay on the rig network.
• From the server: the connections you configure, such as the WITSML servers you add as sources, your mail server and an SMS gateway for alerts.
• Optional conveniences: when someone opens the Log Viewer's weather tab, the server asks a public forecast service for the forecast at the wellhead's coordinates, and the web pages load their fonts from a public font service. Without a route to the internet the weather tab stays empty and the browser uses its own fonts.
• The licence: a signed file checked against a public key held on the server, so there is no call to a licence server.
• Models: the trained models in KPI & Rig State and the advisory engines in ROP Optimisation and Drill Sight run inside the DrillIQ server, as do the physics engines. No well data goes to an outside AI service.

When the rig link drops

Rig Connect writes every row to an on-disk queue first and deletes it only when the store has confirmed it with a signed answer. Up to 1,000,000 rows wait in a local database. Past that, the oldest rows move 20,000 at a time into compressed files, still in order. Rows are dropped only if free disk falls below 2 GB, oldest first, and every drop is counted and shown. Take a rig sending five rows a second, each like a WITS record 1 with 33 values:

1. Bytes a row. Running the agent's own buffer code on rows like these gives 1,440 bytes a row in the queue and 181 bytes once a row is spilled to a compressed file.
2. Queue full. 1,000,000 rows ÷ 5 a second = 200,000 s, or 55.6 h, using 1.44 GB.
3. A week. 7 × 24 × 3,600 × 5 = 3,024,000 rows. The first million take 1.44 GB and the other 2,024,000 take 2,024,000 × 181 bytes = 0.37 GB: 1.81 GB in all.

A week offline needs less than 2 GB, so disk space doesn't limit a long outage on an ordinary rig PC. Once the queue is full the line flattens by a factor of about eight, because a compressed row takes an eighth of the space. What happens when the link comes back matters more.

After an outage the agent sends 1,000 rows a write instead of 50, oldest first, until the backlog is clear. Measured on the agent's own WITSML writes, a row costs 291 bytes in a 1,000-row write and 432 bytes in a 50-row live write, where the log header that every write carries is a larger share.

1. The backlog. A 24-hour outage at 5 rows a second is 432,000 rows × 291 bytes = 126 MB.
2. Live data keeps coming. 5 rows a second × 432 bytes = 2,160 bytes a second, about 17 kbit/s.
3. On a 64 kbit/s link (8,000 bytes a second), 5,840 bytes a second are left for the backlog: 126 MB ÷ 5,840 = 21,600 s, or 6.0 h.
4. On faster links the same backlog takes 1.2 h at 256 kbit/s and 17 minutes at 1 Mbit/s.

Catch-up time grows in proportion to the outage, and its slope depends on the link's spare capacity. On a narrow link a day offline costs six hours of catching up. Rows go out oldest first, so during those hours the office sees history arriving in order while the newest readings wait at the back of the queue. Anything that must be watched live, such as pit volume on a connection, has to be watched on the rig's own screens through an outage and its catch-up.

Updates

The DrillIQ server is updated by whoever runs it, when they choose. A new release means a restart. During it, rig agents keep buffering and replay when the store returns, and because the store keys rows by their index, a row sent twice is stored once. Sources that were running before the restart start again by themselves. Licence renewals and changes to the licensed modules apply without a restart, except for a module the server hadn't loaded, which the licence screen names.

Rig Connect is upgraded by running the new installer at the rig. It stops the service, replaces the program and starts it again, keeping the settings, the buffer and the enrolment. Uninstalling keeps the data folder as well, because it may hold rows not yet sent.

Security

• Rig agents enrol. An administrator issues a one-time code. The agent creates a key pair, with its private key sealed to that PC, and pins the store's key. The code itself never crosses the network.
• Every request is signed, with the time and a one-time nonce, so replays and clocks more than 5 minutes out are refused. Every answer is signed as well, so an agent pointed at a different server sends nothing.
• The store can refuse other writes. With "accept writes only from enrolled rig agents" on, any other write is turned away. It is off by default so that existing WITSML tools keep working. Revoking an agent stops it at once, and its rows keep buffering.
• Encryption is a deployment choice. The agent protocol authenticates both ends but doesn't encrypt the body, so where the link isn't trusted, put the store behind HTTPS.
• Accounts. Passwords of at least 12 characters, a 15-minute lock after five failed attempts, 8-hour sessions with a 60-minute idle time-out, and two-step sign-in required for administrators by default. Access is set per module (none, view, edit or approve) and per well, and an audit log records account, session and access events.
• Stored secrets. Passwords for WITSML sources and two-step sign-in keys are encrypted at rest.
• Read-only towards the rig. DrillIQ's live views receive telemetry, and nothing in them sends commands to rig equipment.

A checklist for the rig team

• Get a written answer on where well data may be stored and processed, from your legal team and from each partner.
• List every connection that leaves the rig network and the office network, and why it is there.
• Size the rig PC's disk for the longest outage you plan for, plus the 2 GB floor.
• Work out catch-up time on the real link, and keep live monitoring on the rig's own screens through an outage.
• Keep the rig PC's clock synchronised; the store refuses an agent more than 5 minutes out.
• Enrol each rig agent with a one-time code, and turn on "accept writes only from enrolled rig agents".
• Put the store behind HTTPS wherever the link isn't trusted.
• Back up the server's data folder, including the store's identity key, without which every rig must enrol again.

How DrillIQ handles it

DrillIQ runs as one server, on-premises or on a cloud server, with a Rig Connect agent at each rig. The agent reads the rig's feeds, buffers them on disk through outages and sends them, signed, only to the store it enrolled with. The server sets up each rig's well, follows its logs, and re-reads any gap filled after an outage, so the modules see the complete record. Licences are signed files checked on the server, models run on the server, and only the licensed modules load. WITSML explained follows the data path from sensor to screen in more detail.

Book a demo → See all capabilities

References

1. IEC 62443-3-3:2013. Industrial communication networks: Network and system security, Part 3-3: System security requirements and security levels.
2. ISO/IEC 27001:2022. Information security, cybersecurity and privacy protection: Information security management systems: Requirements.
3. NIST SP 800-82 Rev. 3. Guide to Operational Technology (OT) Security. National Institute of Standards and Technology, 2023.
4. Energistics. WITSML Store Application Program Interface (API), version 1.4.1.