Reevaluating the RTOC: From Watching Screens to Intelligent Anomaly Detection
The real-time operations center was designed around a person watching sensor readings move. The tools now exist to invert that: let the system find the anomaly, and let the engineer do the analysis only a person can do.
Figure 1. The real-time operations center was built around a person watching screens. Its founding assumption, that a few engineers can hold steady attention across many wells at once, is the constraint this article reexamines. Illustrative.
🖥️ The center we built for the human eye
The real-time operations center is one of the clearest wins of the last two decades of drilling. It pulled expertise off the rig floor and into a room where a few experienced engineers could see live data from many wells at once, catch trouble early, and advise the rig before a small departure became an expensive one. The design assumption underneath it, though, has never really changed: a person sits in front of screens, watches the curves move, and is expected to notice when something is drifting toward a problem.
That assumption is where the model is now reaching its limit. The more wells assigned to a single watcher, and the more channels per well, the more the most important departures are not a single dramatic spike on one screen but a quiet correlation across several: hook load, torque, standpipe pressure, and flow, each still inside its own normal band, drifting together in a way no single trace makes obvious. The human eye was never a scalable anomaly detector. It was the best detector available when the center was built.
This is not a story about tired engineers. It is a measurable property of sustained monitoring. In the classic vigilance research, detection accuracy on a monitoring task drops most steeply in the first part of a watch and then keeps declining, and the effect is well documented across decades of study. The point is structural: asking a person to hold steady attention across many low-frequency, mostly-normal signals is asking the one part of the system that fatigues to do the part of the job that never should have depended on staying fresh.
The obvious shortcut does not rescue it either. Bolting threshold alarms onto individual variables trades one problem for another: a single parameter crossing its limit does not by itself mean the operation is abnormal. What counts as normal depends on what the rig is doing at that moment, and an alarm tied to a fixed line rather than to the operation cannot make that distinction. Untied to context, most of what those alarms produce is a false positive, which is why simply adding more of them has never been the answer.
None of this argues for closing the operations center. It argues for changing what the people inside it are asked to do. If the eye is the weak link in detection, the redesign is to take detection off the eye.
🔄 Invert the flow: the anomaly is the unit of work
The current model is "watch everything, and raise your hand when you see something." The next model inverts it: the system watches everything continuously, and what reaches the engineer is a flagged anomaly with its context attached, not a raw feed to be scanned. The engineer stops being the detector and becomes the responder. The unit of work is no longer the screen; it is the anomaly.
Figure 2. The inverted flow in four steps: the screens overflow, the system surfaces one contextual anomaly, the engineer adjudicates it against the evidence, and a governed advisory reaches the rig team, where operational authority stays. The shift is from continuous watching to informed judgment. Illustrative. WillCo analysis.
"Detection" here does not mean a threshold alarm on a single tag. A high-hook-load alarm that fires every time the string is picked up is noise, and noise is what trained people to ignore alarms in the first place. Detection means evaluating a signal in its operating context: the current bottom-hole assembly, hole geometry, fluid state, trajectory, and what the rig is actually doing at that moment. That is the same contextualization the earlier articles in this series argued has to happen at the edge before any number is decision-grade. An anomaly is a departure that survives context, not a value that crossed a line.
Where the detection runs follows directly from the two-loop fabric described in the previous article. Latency-sensitive evaluation should generally run close to the data, at the edge, when the required signals, compute, availability, and quality controls are present there; slower fleet-level analytics and model governance can stay in the office. Placement is a judgment about latency, bandwidth, compute, availability, data access, and cybersecurity zoning, not a fixed rule. Adjudication belongs where the deepest expertise sits, which may be the same operations center, now doing a different job. Detection near the data, judgment near the expertise: the fabric already carries both.
🌐 The edge detects, but the fleet still needs a center
Pushing detection to the edge sounds like an argument against a center at all. If each rig can evaluate its own signals in context, why route anything to a central room? Part of that challenge is right, and it deserves a precise answer. Monitoring a single rig from equipment on that rig is not a center; it is a local capability, better called a local monitoring node, or LMN, than anything that earns the word "center." If the whole model were one rig watching itself, the central room really would have little left to do.
But the value of a center was never that it sat between a rig and its own data. The value is that one group of engineers sees many rigs at once. A departure on one rig becomes useful the moment the next rig approaches the same formation, the same section, or the same operation, and a team watching the fleet stays primed for patterns a single-rig node would meet as if for the first time. That cross-rig awareness is a human and organizational effect, not only a software one: it is how a problem solved on one well quietly protects the next, and how a fleet accumulates judgment instead of relearning it rig by rig. The federated learning described later is the machine version of this idea; the staffed center is the human version, and the two reinforce each other.
So the real question is not edge versus center, and there is no single global answer. It is which job belongs where, and under what conditions. Latency-bound detection has to run close enough to the phenomenon to catch it in time. Where connectivity is poor, as it often is in remote locations, that closeness has to be physical, and the LMN on the rig becomes the way, because a distant center cannot see the signal soon enough to act. Where bandwidth and latency are good, a centralized RTOC can run the same detection and keep the fleet-level advantages in one place. Either way, fleet-level judgment, cross-rig learning, and governed model improvement belong to a center, now staffed by engineers who respond to findings instead of hunting for them. The choice between an LMN and the RTOC is set by latency and connectivity, not by fashion, and selling the edge as a universal answer would give up the fleet gains wherever the network never forced the trade.
Where each one fits. An LMN earns its place where latency, poor connectivity, or a need for high-frequency data rules out a distant center; the RTOC keeps the cross-rig learning and governance a single rig cannot. Conceptual comparison. WillCo analysis.
📈 The engineer moves up the stack
When the system does the detecting, the engineer's job moves up a level, from spotting the change to deciding what the change means and whether it is worth acting on. This is the part of the work that actually rewards experience, and it is the part a wall of screens has always crowded out.
Take a concrete, illustrative case. An alert fires: hook load is running high for the conditions the model knows about. In the old model, that alert competes for a watcher's attention against forty other traces and may never be seen. In the inverted model, it arrives as a discrete work item, already carrying the context that triggered it. The engineer opens a torque-and-drag analysis, at the edge or in the office, checks the alert against the modeled friction and the recent trend, and decides: is this a real anomaly worth highlighting to the rig, or an expected consequence of what the crew is doing right now? Automated torque-and-drag analysis on real-time data is an established workflow in the drilling engineering literature; what changes here is not the tool but the order of operations, the system raises the question and the engineer answers it, instead of the engineer having to notice the question first.
That is a better use of a scarce person. Detection is a task that degrades with time-on-watch and scales badly with the number of wells. Adjudication benefits from experience and lets attention be used more selectively, but it still depends on workload, alert quality, and situational awareness. The redesign succeeds only if the anomaly queue stays sparse, prioritized, explainable, and connected to the underlying evidence. It does not remove the human from the loop; it moves the human to the part of the loop where being human is an advantage.
Figure 3. An automated flag: the measured trend departs from the modeled envelope, and one point is raised for review. In the inverted model the system surfaces the departure with its context; the engineer decides whether it is a real anomaly worth highlighting to the rig. Illustrative, not a specific well.
The human-factors problem moves, it does not disappear
Moving detection from the engineer to software does not eliminate the human-factors problem. It changes it. Too many false positives recreate alarm fatigue; a highly trusted detector can create automation bias and a loss of situational awareness; and a false negative can be more consequential when the team assumes that silence means normal operation. The engineer has to be able to inspect the evidence: the data quality, the model's confidence, and the raw context behind the flag. Detection performance should therefore be governed through precision, recall, false-alarm rate, missed-event review, response time, and operating-envelope coverage, not accuracy alone.
⚡ The second center: real-time performance
Everything above supports earlier recognition of abnormal trends, including conditions associated with stuck pipe or wellbore instability. For well control specifically, primary detection, alarms, barriers, and response authority stay at the rig, inside the certified well-control and rig-control environment; any RTOC model is secondary advisory support. That earlier-recognition role is the operations mission, and it is worth keeping distinct. The same data foundation can serve a second mission with a different goal, and that mission deserves its own operating focus: the Real-Time Performance Center, or RTPC. Here, RTPC means a distinct mission, operating queue, and governance model. It does not necessarily require a separate building or team.
The RTPC's mandate is performance: connection times, on-bottom drilling speed, tripping times, and the operational KPIs that decide whether a well is being executed efficiently. Its unit of work is not "is something unsafe" but "is this as fast and consistent as it should be, and where is the recurring loss." Safety-critical conditions stay governed by the rig and operations systems, with explicit escalation when a performance signal and a safety signal overlap. Where the operations side asks whether the well is safe, the performance side asks whether the execution is sharp.
Getting a useful answer means measuring at the right resolution. A single connection time is a headline, not a diagnosis. The value comes from decomposing the connection cycle into three stages: weight to slips, as the string transitions from drilling into the slips; in slips, the work performed while the string is in the slips and the connection is made up; and slips to weight, as weight returns to the bit. That breakdown shows whether the time is being consumed entering the slips, completing the connection, or returning to bottom, which tells the crew the specific step to work on instead of just telling them the connection was slow. The event definitions and the start and stop rules for each phase have to stay consistent across wells and systems, because different systems can mark those boundaries differently. The same logic applies to tripping and to on-bottom performance: the signal that changes behavior is the decomposed step, not the aggregate number.
Those steps also have to be compared like for like. Connection type, hole section, pipe and BHA configuration, rig state, equipment, crew, depth, and the relevant operating conditions all move cycle times on their own, so they have to be accounted for before variation is attributed to execution. Otherwise a legitimate operational difference gets mistaken for inconsistent performance. Handled that way, a performance signal is exactly the kind of steady, comparable metric a system tracks better than a person scanning a shift report after the fact.
Consistency within technical constraints
The most important thing the RTPC measures is not raw speed. It is repeatable execution around a safe and technically sound target, not consistency at any cost and not one isolated fast cycle. One outstanding connection can be unrepresentative; a slightly slower connection that repeats can be the more useful capability. Consistency contributes to a shorter well, but total well duration also depends on ROP, flat time, equipment failures, geology, design, and other operations, so it is one factor and not the whole story. The real job of the RTPC is to measure both typical performance and its spread, identify the phase responsible for unwanted variation, and hand the rig team a specific item to review, subject to safety, equipment, well-integrity, and quality constraints. Reducing unwanted variation can improve the average cycle time and the reliability of the plan, but that effect has to be demonstrated rather than assumed.
A short illustrative case makes it concrete. Suppose a crew's slip-to-slip connection times look acceptable on average, so nothing on the shift report stands out. Decompose the cycle and a different picture can appear: weight to slips and in slips stay stable connection after connection, but slips to weight scatters from one stand to the next. The aggregate average hid the opportunity; the decomposition located it. The performance signal that matters is not "connections are a little slow," it is "this crew is inconsistent in one specific phase of the connection, and here is the phase." The RTPC can flag that phase, confirm the cycles are genuinely comparable, and give the crew the evidence for a focused review, rather than reporting a connection time that looked fine.
Figure 4. A connection whose aggregate time looks acceptable, decomposed into three phases. Weight to slips and in slips stay tight; the variation concentrates in slips to weight, which points the crew to the specific step to work on rather than to a slow connection in general. Illustrative decomposition following the phase model in SPE-212393-MS. WillCo analysis.
Rolled up, that is the metric the performance center is really chasing: a consistency index for each repeated operation. It answers one question, how tightly a crew or rig repeats a phase around its own sound target, and it is a statistical measure rather than a single time. The typical value comes from the median or mean of comparable cycles; the spread comes from the standard deviation or an equivalent measure of dispersion; and the trend shows whether that spread is tightening or drifting across a run. A histogram is the most useful single view, because it shows the whole distribution at once: a tall, narrow shape is a repeatable operation, a wide or two-humped shape usually means one label is hiding two different operations, and a long tail exposes the rare cycle that quietly inflates the average. The aim is to hand the rig team one honest number with the picture behind it, so consistency can be tracked and improved like any other KPI.
Reading consistency as a histogram. The same average can hide very different shapes: a repeatable operation forms a tall, narrow peak; one label covering two operations shows two humps; and a rare, slow cycle leaves a long tail that pulls the mean past the median. The consistency index tracks how tall and narrow that shape stays run after run. Illustrative shapes, not field data. WillCo analysis.
From the best rig to the rest of the fleet
Locating the phase that varies is only the first half of the work. The second half is asking why one rig holds that phase steady while another does not, because the data shows the gap without explaining its cause. On connection time, four elements tend to decide the answer, and each has to be examined on its own. The first is the procedure: whether the crew follows a defined sequence for the connection or improvises it stand by stand. The second is the tooling: a rig running hydraulic equipment such as an iron roughneck and powered slips will usually hold a tighter, more repeatable cycle than one working with manual tongs and hand slips, and that gap is physical rather than a matter of effort. The third is training: whether the people on the floor have performed the task often enough to do it the same way under fatigue and at night, not only on a good day. The fourth is supervision: whether someone on tour is holding the crew to the standard and correcting drift before it settles in. Scattered connection times usually trace back to one or more of these four, and naming which one is what turns a number into something a crew can act on.
This is where the RTPC's findings become a program rather than a report. Once the data points to the rig that is both fast and consistent on a given phase, the next step is to audit that rig in person: go to the floor and see what the crew actually does differently across procedure, tools, training, and supervision. Those confirmed practices are the ones worth documenting. The rigs that lag are then measured against the same four elements to find where they fall short, and the practices proven on the best rig are carried across to them, with follow-up on the data to confirm the change held. The aim of comparing rigs is not to rank them; it is to move the whole fleet toward what the best rig has already shown can be done safely and repeatably. That loop, measure, explain, transfer, and confirm, is the practical payoff of a performance center.
Figure 5. The whole picture: a traditional screen-heavy RTOC evolves into an intelligent one whose queue is prioritized anomalies with context; both the operations center (work the anomaly) and the performance center (close the variation) stand on one shared, edge-refined data foundation. Automation detects, engineers decide, and rig authority remains primary. Conceptual architecture. WillCo analysis.
✅ Why this is practical now
The idea of automated anomaly detection in drilling is not new. What is new is the foundation that makes it trustworthy, and that foundation is exactly what the earlier articles in this series were building. An automated flag is only as good as the data underneath it, and a flag built on raw, uncontextualized, differently-clocked signals will cry wolf until people stop listening. Decision-grade data at the edge is the precondition, not a nice-to-have.
The pieces line up with the two-loop fabric directly. The high-frequency edge analytics of the second article are what let a signal be evaluated in context at the rate the phenomenon actually moves. The first loop of the third article, refined information moving from rig to office, is what carries a flagged anomaly with its evidence to the person who will adjudicate it. And the second loop, federated learning across the fleet, can support controlled improvement without centralizing every rig's raw data: candidate updates from local models are validated across different rigs, sensors, drilling programs, and operating envelopes before they are accepted into a governed fleet model. Federated learning distributes the training; it does not by itself guarantee improvement, safe transfer, or freedom from drift, which is why the validation step matters. Detection that can improve across a fleet, on data that never had to leave the rig raw, was not available when the RTOC was designed.
The RTOC was the right answer to the question "how do we get expertise closer to many wells at once." Intelligent detection is the right answer to the question the first answer created: "how do we keep a person's attention from being the bottleneck."
🛠️ A path to get there without ripping out the RTOC
This is an evolution, not a teardown. The operations center that exists today is the right place to run the new model from, and the migration can be staged so the humans are never without a net. A workable sequence:
Figure 6. A staged migration: evolve the operations center rather than tear it out, keeping the human in the loop at every step. Every step runs on one shared foundation of data quality, cybersecurity, human factors, and change management. WillCo analysis.
At every stage the human stays in the loop. The goal is not to remove the person; it is to change what the person spends attention on, from noticing that something changed to deciding what the change means. That is the whole redesign in one sentence.
🎯 The takeaway
The monitoring center does not need to be defended or abandoned. It needs to evolve. Let the system carry detection, the part that scales badly with wells and degrades with time-on-watch. Let the engineer carry adjudication, the part that rewards experience. Split the mission cleanly: an operations center that supports operational-risk recognition and adjudication by working the anomaly, and a performance center that sharpens execution by driving every operation toward consistency. Both stand on the same decision-grade, edge-refined data foundation the earlier articles built. The eye is not the detector anymore. It never should have had to be.
This is the fourth article in the WillCo drilling-data-architecture series. Read the full series and more analysis at willcodrilling.com.
📚 The series so far
References and further reading
Human attention and monitoring
N. H. Mackworth, "The breakdown of vigilance during prolonged visual search," Quarterly Journal of Experimental Psychology 1(1), 1948. Source for the classic finding that detection accuracy on a sustained monitoring task declines most steeply in the early part of a watch (the vigilance decrement).
"Understanding vigilance and its decrement: theoretical, contextual, and neural insights," PMC13271136, 2025. Source for the modern confirmation that the vigilance decrement is a robust property of sustained attention, with a steep early drop followed by a steadier decline.
R. Parasuraman and D. H. Manzey, "Complacency and Bias in Human Use of Automation: An Attentional Integration," Human Factors 52(3), 2010. Source for automation bias, complacency, and loss of situational awareness when detection is delegated to a trusted automated system, and for governing such systems on performance rather than trust.
Real-time drilling engineering
P. Shahri et al., "Automated Real-Time Torque and Drag Analysis: A New Milestone Toward Drilling Optimization," SPE-191426-MS, 2018. Source for the use of real-time data in automated torque-and-drag workflows, the worked example referenced here. See also the readable summary by C. Carpenter, Journal of Petroleum Technology, 2019.
R. Fernandes et al., "Importance of Real-Time Data to Improve Operational Efficiency for Unconventional Drilling in Argentina," SPE-212393-MS, 2023. Source for the detailed connection-cycle decomposition into Weight to Slips, In Slips, and Slips to Weight, and for the value of consistent event definitions across wells and systems.
Automation governance and control authority
K. Stouffer et al., Guide to Operational Technology (OT) Security, NIST Special Publication 800-82 Revision 3, 2023. Source for the principle that operational-technology performance, reliability, and safety constraints govern where control authority may reside.
NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0), 2023. Source for treating model and system validation as lifecycle activities rather than one-time development tasks.
Sources: the vigilance decrement draws on Mackworth (1948) and the 2025 review cited above; automation bias and complacency on Parasuraman and Manzey (2010); the torque-and-drag workflow on SPE-191426-MS; the three-phase connection decomposition (weight to slips, in slips, slips to weight) on SPE-212393-MS; and the control-authority and validation principles on NIST SP 800-82r3 and the AI RMF, retrieved September 2026.
Acronyms
AI RMF: Artificial Intelligence Risk Management Framework (NIST)
BHA: Bottom-hole assembly
KPI: Key performance indicator
LMN: Local monitoring node
ML: Machine learning
NIST: National Institute of Standards and Technology
OT: Operational technology
RTOC: Real-Time Operations Center
RTPC: Real-Time Performance Center
SPE: Society of Petroleum Engineers
WITSML: Wellsite Information Transfer Standard Markup Language
Reuse and citation. This article may be reproduced in whole or in part, for any purpose, provided WillCo Drilling Consulting is credited as the source and a link to willcodrilling.com is included. Suggested citation: WillCo Drilling Consulting, "Reevaluating the RTOC: From Watching Screens to Intelligent Anomaly Detection," willcodrilling.com, September 2026.
Comments