Cloud, edge, and hybrid are deployment choices tied to responsibility and failure consequence. A function that directly controls equipment or must survive loss of wide-area communications belongs near the rig. Fleet comparison, historical analytics, and rapidly changing decision support often benefit from a centralized runtime.
Start with failure consequence and authority
A surprisingly effective architecture test is:
What happens if the internet connection disappears?
For a closed-loop drilling-control system, a poor answer would be:
The controller stops functioning.
That would make remote dependence difficult to justify. For a cloud-based engineering analytics platform, the answer may instead be:
Live analytics temporarily stop updating until the rig-data connection returns, while the rig continues operating through its existing rig-control and safety systems.
Those are very different failure consequences.
A WAN outage is unacceptable when it removes control, but may be tolerable when it only interrupts cloud decision support and local rig control continues.
The cloud architecture may be entirely acceptable for the second system because the software is decision support rather than a required component of physical rig operation. This distinction is foundational.
| System role | Examples | Connectivity implication |
|---|---|---|
| Control | PLC logic, autodriller, MPD control loop, equipment protection | Directly influences the physical process; local independence is normally required. |
| Decision support | Benchmarking, engineering models, surveillance, reports, AI-assisted analysis | Informs people who remain responsible for the operational decision; delayed availability may be tolerable. |
The closer software moves toward control, the stricter its requirements become for:
- latency,
- availability,
- deterministic behavior,
- fail-safe design.
Decision support can tolerate different tradeoffs.
Use edge where independence is required
There are several cases where running software close to the rig is compelling.
- Direct control: Software inside a control loop should not depend on wide-area communications.
- Connectivity-independent surveillance: A critical function that must survive external communications loss benefits from local execution.
- High-frequency local acquisition: Direct PLC, EDR, mudlogger, and rig-control connections may be easier to acquire locally before transmission.
- Very low latency: Some mechanical and control problems operate on timescales where remote round trips are undesirable.
Published field systems have demonstrated these advantages. SPE-191797 described a rig-centered architecture where acquisition and physical models could operate without internet or remote server connectivity.[1] SPE-204125 later described a hole-condition surveillance model running continuously on an edge device.[2] Those are legitimate choices for those applications, not universal requirements for every drilling analytics platform. Installing computation at the rig creates a distributed system: hardware must be deployed, powered, networked, and maintained, while software must be installed, updated, version controlled, and troubleshot at multiple locations. The challenge grows with the fleet. A published rig-based advisory deployment provides a useful real-world example. Field engineers installed:
- hardware,
- local communications,
and trained personnel across multiple rigs. Software updates then had to be validated on the distributed installations. The system succeeded, but the deployment illustrates an important architecture reality:
Edge capability is not free simply because the computer is physically small.
Use cloud for shared analytical context
In a cloud-based platform, users access the same deployed analytical logic. When MSE v4 is released centrally, the organization can maintain one canonical calculation instead of distributing executable software to every rig. The same applies to:
- rig-state logic,
- KPI definitions,
- benchmarking rules,
- hydraulic calculations.
This reduces a subtle but important risk:
- Rig A: calculates a KPI one way.
- Rig B: calculates it another way.
- Office analysis: calculates it a third way.
The organization otherwise has multiple versions of the same engineering truth. The value of centralized data rises with analytical scope:
| Question | Scope |
|---|---|
| What is current surface RPM? | One sensor, one rig, now |
| How does rotary ROP compare with the last 500 ft? | Current well and recent history |
| How does this BHA's Formation B performance compare with similar motor BHAs used during the last two years? | Many wells, BHAs, and historical metadata |
The value of centralized data increases as the question expands from one sample to the current well and then to the fleet.
Make the connectivity boundary explicit
If the rig continues drilling but its data feed stops, a cloud-only engineering platform cannot analyze measurements it has not received. Therefore:
- live dashboards stop updating,
- real-time calculations pause,
- live AI analysis loses current evidence.
This is a genuine limitation. It should not be hidden. The important architectural question is:
Does that limitation violate the responsibility assigned to the software?
If the platform is responsible for safely controlling the rig, then yes. If the platform is responsible for engineering monitoring and decision support, it may be an acceptable availability tradeoff. That distinction should be documented clearly. If an analytical platform depends on remote connectivity, it should not be implicitly positioned as:
- the rig's safety interlock,
- required control path,
- sole means of recognizing a condition whose safe handling requires uninterrupted local detection.
The rig should remain capable of operating safely through:
- its rig systems,
- field procedures,
- local personnel
if the analytical service becomes temporarily unavailable. This separation of responsibility is healthy architecture. Centralization has its own downside: one service failure can affect many users or rigs simultaneously. A cloud platform therefore needs engineering around:
- redundancy,
- availability,
- database resilience,
- monitoring,
- recovery.
Edge deployments distribute failures geographically; cloud deployments centralize them. Neither topology eliminates reliability engineering. It only changes where failure modes live. A stream can be connected but delayed, so the cloud may hold the most recent value it received without knowing the rig's actual current state.
A mature cloud analytics platform should therefore preserve the value, timestamp, and freshness. This supports answers such as:
Latest available torque is 14.2 kft-lbf, posted 47 seconds ago.
rather than simply:
Torque is 14.2 kft-lbf.
That distinction becomes more important as network distance increases. Suppose one required channel stops updating. A useful platform should not simply fail silently. It may instead report:
- channel stale,
- analysis unavailable,
- calculation based on last valid context.
This connects directly with the earlier article: When “Unable to Determine” Is the Correct Output in Drilling Analytics. Architecture and analytical uncertainty interact.
Assign each responsibility deliberately
The same drilling organization may reasonably use all three patterns.
- Edge: Rig-control and equipment systems.
- Cloud: Engineering intelligence platform.
- Hybrid: Specialized advisory or surveillance application requiring local independence plus centralized history.
There is no contradiction. Different systems occupy different layers of the drilling technology stack.
| Software Responsibility | Cloud | Edge | Hybrid |
|---|---|---|---|
| Closed-loop equipment control | Weak fit | Strong fit | Strong |
| Safety-critical local interlock | Weak fit | Strong fit | Strong |
| Connectivity-independent alerting | Weak | Strong | Strong |
| Real-time engineering dashboard | Strong | Strong | Strong |
| MSE / ROP / KPI analytics | Strong | Strong | Strong |
| Offset benchmarking | Very strong | Limited | Strong |
| Fleet performance analytics | Very strong | Weak | Strong |
| Historical BHA analysis | Very strong | Weak | Strong |
| Multi-well surveillance | Very strong | Weak | Strong |
| Management reporting | Very strong | Weak | Strong |
| LLM / RAG engineering assistant | Very strong | Possible | Strong |
Cloud, edge, and hybrid each fit different responsibilities; none wins every workload.
The table is not a universal specification. It illustrates why asking simply:
Is cloud or edge better?
usually produces the wrong discussion. An application that must detect a high-consequence event locally through communications loss and compare it with hundreds of historical wells has a strong hybrid case: the edge detects current condition while the cloud supplies historical intelligence. Architecture should follow responsibility rather than ideology.
DrillingMetrics as a bounded cloud role
DrillingMetrics is architected as a cloud-based drilling intelligence platform. It does not replace the rig PLC, autodriller, or local safety systems. Its role sits primarily in the engineering-intelligence layer, including:
- real-time drilling analytics,
- offset benchmarking,
- engineering models,
- historical analysis,
- multi-well operational review,
- reporting,
- AI-assisted engineering workflows.
Those workloads benefit from current and historical information in one shared analytical environment. The tradeoff is explicit: if the live rig-data path is interrupted, current analytics cannot remain current until it returns. DrillingMetrics is therefore real-time engineering decision support when live data is available, not a connectivity-independent rig-control or safety system.
The rig supplies the current physical evidence; the cloud product combines it with broader engineering context without creating a rig-control command path.
Related technical resources
- The Hidden Data-Engineering Work Behind Real-Time Drilling Analytics
- Why Drilling Data Is Not Just Time-Series Data
- Engineering Context in Drilling RAG: Why Semantic Similarity Is Not Enough
References
-
Shahri, M., Kutlu, B., Thetford, T., Nelson, B., Wilson, T., Behounek, M., Ambrus, A., and Ashok, P. Adopting Physical Models in Real-Time Drilling Application: Wellbore Hydraulics. SPE-191797-MS, SPE Liquids-Rich Basins Conference, North America, Midland, Texas, 2018.
-
Ashok, P., D'Angelo, J., Ramos, D., Yi, M., Thetford, T., Younk, N., Bohlander, S., Shahri, M., and Behounek, M. A Probabilistic Belief System to Track the Cleanliness of a Hole in Real-time. SPE-204125-MS, SPE/IADC International Drilling Conference and Exhibition, 2021.