Operational telemetry
Designing for a link that is only sometimes there.
Getting drilling data from the rig site to the office over a connection that fails routinely — without losing the gaps or disguising them.
The problem
The Smart Logging System
The rig site knows what is happening. The town office finds out from a morning report, a phone call, or a number that has already stopped being true.
Remote witnessing solves that on paper. In practice every system that tried assumed a network, and the connection to a rig is not a network — it is a network that is sometimes there.
A system that treats link failure as an error spends most of its life in an error state, and quietly loses everything that happened while it was down.
The constraints
Fixed before anything was drawn.
Not requirements, which move. These are the facts of the problem that no amount of engineering was going to change, and every decision downstream had to survive them.
The link fails regularly and unpredictably
Outages range from seconds to a day, with no pattern to design around. This is the input to every other decision.
You must be able to know when you were blind
On a well, 'what was happening at this depth' gets asked afterwards, by people with consequences attached. A log that cannot distinguish streamed data from reconstructed data cannot answer honestly.
Depth and time are both real indexes
The relationship between them is not fixed — during a connection, time passes and depth does not.
Data custody is a legal input, not a preference
Who may hold well data, where, and which partner may see it decides the deployment before anything is drawn.
The architecture
What the constraints forced.
The edge is the system; the cloud is a consumer
Data is captured and durably buffered at the rig site at full resolution whether or not anything can be sent. Transmission is a separate concern that drains the buffer when the link allows. The common alternative — send live, reconnect on failure — loses the outage invisibly, because the chart simply resumes.
Backfill is marked, never merged
Reconciled data lands at its correct depth and time, and the period stays flagged as backfilled. The log tells you it was reconstructed.
Both indexes are first-class
Storing one and deriving the other produces logs that go wrong exactly where drilling stopped. Carrying both costs storage and is the difference between a driller and a geologist reading the same well without arguing.
Alarms timestamped when they happened
A threshold trip during an outage still occurred. It surfaces on reconciliation, dated to the event rather than to its arrival — and escalates if unacknowledged, because the assumption that someone is watching is the one that fails first.
The decisions
Each one cost something.
A decision presented without its cost is a decision nobody had to make. These are the ones we would defend, and what we gave up to take them.
Make the link being down a normal state
It is the actual operating condition. Designing for the good link and handling the bad one as an exception inverts the real distribution.
The trade-off
There is a real component at the rig site to deploy, maintain, and update — infrastructure a pure-cloud product does not have. That is the cost of not losing data.
Keep backfilled periods visibly marked
A seamlessly healed gap is a system that cannot tell you when it was blind.
The trade-off
The log looks worse. A competitor's chart is smooth and ours has a marked band across it — and we have to explain, every time, that the smooth one is not better, it is less honest.
Carry depth and time as separate first-class indexes
Two roles ask different questions of the same reading, and neither should have to convert.
The trade-off
More storage, more complexity, more to keep consistent.
Where it stands
The platform is built and running: WITSML 1.4.1.1 and 2.0 streaming from the rig site, buffered at the edge, reconciled on arrival, with the town office seeing what the rig site sees.
The store-and-forward design is the reusable part. It is the same shape as every problem where information originates somewhere the network does not reliably reach — which is most operational work in this region, and not only in oil and gas.
We build systems like this for other organizations.
The Smart Logging System exists because we met the same operational failure enough times to engineer it properly. Yours is probably a different failure. That is the conversation we want, and you will have it with an engineer.