Operational telemetry
Your office can't see what the rig sees.
The Smart Logging System
An AZCY platform.
Live drilling data, streamed from the rig site to everyone who needs it — built for connections that fail, because rig connections do.
The rig site knows. The office finds out later — from a morning report, a phone call, or a number that has already gone stale. That delay is where operational decisions go wrong, and it is not a matter of distance.
The shape of it
What moves, and what happens to it.
The rig site
Sensor readings, gas levels, and rock data, taken straight from the systems already running at the wellsite.
Save first, send when possible
Every reading is saved at the rig, sent when the connection allows, and slotted into place on arrival. A dropped link is a normal event, not an incident.
Everyone who needs it
Your office sees what the rig site sees. Views by depth or by time, alarms that always reach a person, and a record that outlives the well.
Capabilities
The parts that carry the argument.
Store and forward, by design
The rig link drops. The data does not. It is saved on site and catches up when the link returns, with the gap clearly marked rather than papered over.
Remote witnessing
Your office sees what the rig site sees, at the same time. That is the entire point of the system.
Depth and time views of one dataset
The same data, viewed two ways, because a geologist and a driller ask different questions of it.
Alarms with escalation
When a reading crosses a limit, a person is alerted. If they do not respond, the next person is — an alarm nobody saw is not an alarm.
Historical playback
Replay the well as it happened, by depth or by time. Something a morning report cannot do.
How it fits
Into what you already run.
Nothing here replaces a system that works. These are the questions that decide whether a platform can be deployed at all, so they are answered before the specification.
Integrations
- WITSML 1.4.1.1 and 2.0 stores
- Wellsite information systems
- Existing mudlogging units
- Partner and regulator export formats
Deployment
- Edge component at the rig site
- Managed cloud or client-hosted for the town office
- On-premise where data custody requires it
Security and custody
- Data custody: the operator decides where well data lives and who may see it
- Per-well, per-organization access control
- Partner access scoped to a single well and revocable
- Full audit of who witnessed what, and when
Specification
Design facts and stated targets. Nothing we have not measured.
Technical specification
Protocol
- WITSML
- 1.4.1.1 · 2.0
- Transport model
- Streaming ingest, store and forward
- Link assumption
- Intermittent, high-latency
- Backfill
- Reconciled and marked, never silently merged
Data
- Parameters
- ROP · WOB · Hookload · Torque · RPM · SPP · Mud flow · Pit volumes
- Also carried
- Gas readings · Lithology
- Indexes
- Depth · Time
- Playback
- Historical, on either index
Deployment
- Edge
- Rig-site component
- Centre
- Managed cloud · Client-hosted · On-premise
- Access
- Per-well, per-organization, revocable
- Export
- Standard formats for partners and regulators
The hard problem
The link to a rig is not a network. It is a network that is sometimes there.
In plain terms: the connection to a rig drops all the time, so the system is built to keep every reading safe on site and catch up later — not to treat every outage as an emergency. Everything in this system follows from one fact: the connection between a rig site and everywhere else fails regularly, unpredictably, and for durations ranging from seconds to a day. A system that treats that as an error condition will spend most of its life in an error condition. So the link being down is designed as a normal operating state, not an incident.
That makes the rig-site component the real system and the cloud the consumer of it. Data is captured and durably buffered at the edge, at full resolution, whether or not anything can be sent. Transmission is a separate concern that drains the buffer when it can. This inversion matters more than it sounds: the common alternative — sending live and reconnecting on failure — quietly loses everything that happened while the link was down, and the loss is invisible, because the chart simply resumes. A geologist looking at that chart has no way to know they are looking at a hole.
Which is why backfill is marked rather than merged. When the link returns and hours of buffered data arrive, it lands at its correct depth and time — but the period is flagged as backfilled. The log tells you it was reconstructed. A system that invisibly heals its own gaps is a system that cannot tell you when it was blind, and on a well, when you were blind is exactly the question that gets asked afterwards.
The two indexes are the other structural decision. The same reading belongs at a depth and at a time, and the relationship between them is not fixed — during a connection, time passes and depth does not. Storing against one index and deriving the other is what produces logs where nothing lines up when drilling stops. Both indexes are first-class, which costs storage and complexity, and is the difference between a driller and a geologist reading the same well without arguing about the chart.
Alarms inherit all of it. A threshold trip that occurred during a link outage still occurred; it surfaces on reconciliation, timestamped when it happened rather than when it was received. And an alarm nobody acknowledged escalates, because in an operation spread across a rig site and a town office, the assumption that the right person is looking at the screen is the assumption that fails first.
The practices behind it
Where it runs
Questions
The ones we actually get asked.
Do we have to replace our existing mudlogging unit?
No. The system takes a live feed from the wellsite systems you already run. It is designed to sit alongside your unit, not replace it.
What happens to data while the rig link is down?
It is saved at the rig site, in full, and sent when the link returns. That period appears in the log marked as late-arriving, so anyone reading it can tell live data from data that caught up afterwards.
Will it work with the wellsite systems we already run?
Yes. It reads the industry-standard formats your wellsite systems already produce (WITSML 1.4.1.1 and 2.0).
Who can see our well data?
You decide, well by well and company by company, and access can be withdrawn at any time. A partner can be limited to a single well. Every viewing session is logged, so you can answer who saw what, and when.
Can we host it ourselves?
Yes. Where your rules on data custody require it, the office side runs on your own servers. The rig-site part runs at the rig either way.
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.