Event Detection vs. Continuous Optimization: Two Different Drilling Analytics Problems

Detecting an abnormal event and continuously evaluating drilling performance may use many of the same sensor channels, but they require different timescales, thresholds, outputs, validation methods, and human workflows.

Consider two questions.

Question 1

Is a drillstring washout developing?

Question 2

Are the current WOB and RPM producing efficient drilling?

Both questions may use:

• ROP,
• WOB,
• RPM,
• torque,
• pressure,
• flow,
• rig state.

Both can be evaluated in real time.

Both may eventually lead to an operational change.

Yet analytically they are very different problems.

The first is event detection.

The objective is to determine whether a particular condition has emerged strongly enough that somebody should investigate or act.

The second is continuous optimization.

The objective is to evaluate the drilling process continuously and determine whether the current operating region could be improved.

These differences sound semantic.

They are not.

They influence:

• preprocessing,
• window length,
• threshold design,
• acceptable false-alarm rate,
• output format,
• user interaction,
• model validation.

A system designed well for one problem can perform poorly when applied unchanged to the other.

Published drilling work provides good examples.

IADC/SPE-189700 describes a washout and mud-pump-failure surveillance workflow in which streaming evidence is accumulated, short-lived spikes are suppressed, an alert is generated when evidence becomes sufficiently persistent, and an engineer then investigates the supporting pressure and flow trends.[1]

SPE-186166 describes a different problem: a drilling-efficiency assessment is updated continuously as drilling conditions change, allowing the driller to evaluate current performance and move toward better WOB/RPM operating regions.[2]

The first asks:

Has an event occurred?

The second asks:

How well are we operating right now?

Those questions deserve different analytical architectures.

The same rig data supports two different objectives: event detection asks whether an abnormal condition occurred, while continuous optimization asks whether a feasible operating alternative may perform better.

Event Detection Is Fundamentally a Classification Problem

At some level, an event detector asks:

$$Event = Yes \quad \text{or} \quad No$$

The implementation may be probabilistic.

For example:

$$P(Event)$$

may vary continuously from 0 to 1.

But eventually the operational system has to decide whether the evidence is strong enough to:

• create an event record,
• issue an alert,
• notify an engineer,
• trigger a workflow.

That creates a boundary.

Conceptually:

$$P(Event) > Threshold$$

may transition the system from:

monitoring

to:

event suspected.

The exact method can be much more sophisticated, but the underlying operational decision remains discrete.

Something happened strongly enough to matter—or it did not.

Continuous Optimization Does Not Naturally Have an Event Boundary

Now consider drilling efficiency.

Suppose performance improves gradually as WOB changes from:

30 klbf
to 32
to 34.

There may be no meaningful point where:

optimization event occurred.

Instead, performance exists on a continuum.

Conceptually:

$$Performance = f(WOB,RPM,Context)$$

The analytical question is:

Where are we on that performance surface?

and then:

Is there evidence that another nearby operating point would be better?

The output might be:

• current efficiency score,
• historical operating envelope,
• relative performance,
• suggested direction for parameter trial.

No alarm threshold is inherently required.

Event detection crosses a decision boundary; continuous optimization navigates a performance landscape.

False Positives Have Different Consequences

Suppose a washout detector generates false alarms repeatedly.

Each alarm may cause:

• engineers to stop other work,
• pressure trends to be reviewed,
• the rig to be contacted,
• confidence in the monitoring system to decline.

The cost of a false positive is therefore substantial.

This means event detectors often require:

• persistence,
• suppression,
• corroboration,
• cooldown periods.

IADC/SPE-189700 describes exactly this concern.

The alerting workflow intentionally smoothed event beliefs to suppress isolated spikes and limited repeated alerts so office personnel were not overwhelmed.[1]

Those implementation details were specific to the field system, but the principle is general:

An event alert should be rare enough that users continue to take it seriously.

Optimization Feedback Can Be Frequent Without Becoming an Alarm

A drilling-efficiency score may change:

every second.

That does not mean someone should be alerted every second.

Continuous optimization outputs are often better presented as:

• trend,
• operating region,
• score,
• roadmap,
• parameter envelope.

The user can inspect them continuously without being interrupted every time the value moves.

This is a critical human-factors difference.

Event detector

Designed to interrupt when necessary.

Optimization system

Designed to inform an ongoing control decision.

Treating every efficiency fluctuation as an alert would quickly create alarm fatigue.

Event Detection Often Needs Persistence

Suppose standpipe pressure drops briefly because the pumps are being staged.

The pressure trace changes substantially.

Is that a washout?

Probably not.

Now suppose:

• pump rate remains stable,
• pressure remains below expected,
• the discrepancy grows over time.

The persistent evidence is more meaningful.

Event detection therefore frequently asks:

$$Condition + Duration$$

rather than:

$$Condition\ at\ one\ instant$$

This is why moving windows appear so often in surveillance systems.

A short-lived spike may not deserve the same interpretation as a condition that remains present for several minutes or several hours.

But Some Events Should Not Require Long Persistence

A severe mechanical overpull may matter immediately.

A motor stall may occur rapidly.

A sharp pressure loss may warrant attention quickly.

Therefore even inside event detection there are different event classes.

Transient event

High magnitude
Short duration

Developing event

Moderate initial signal
Increasing persistence

Long-horizon condition

Evidence accumulated across hours of operation

The event's physics should determine the temporal logic.

There is no universal persistence period.

Optimization Needs Stability for a Different Reason

Suppose the driller changes WOB.

ROP immediately rises.

For ten seconds.

Then it returns to the previous level.

Was the parameter change beneficial?

Probably not enough evidence exists yet.

Continuous optimization therefore also uses windows and smoothing—but for a different purpose.

The question is not:

Did an event persist long enough to deserve an alert?

It is:

Has the operating response stabilized enough to evaluate the new parameter setting fairly?

That is a different statistical objective.

Persistence supports event confidence, while response stabilization supports fair evaluation of a changed operating point.

Event Detection Looks for Departure from Normal

Many event detectors can be conceptualized as:

$$Observed - Expected$$

For example:

$$Pressure_{measured} - Pressure_{modeled}$$

If the difference becomes unusually large and other hydraulic evidence agrees, a process abnormality becomes more likely.

The event detector therefore needs a model of:

normal behavior.

That model might be:

• physics-based,
• statistical,
• rule-based,
• historical.

The analytical objective is to recognize when reality has departed sufficiently from expectation.

Optimization Looks for Relative Improvement

Optimization asks a slightly different question.

Instead of:

Is the current point abnormal?

it asks:

Is another feasible point better?

Conceptually:

$$Performance(WOB_2,RPM_2) > Performance(WOB_1,RPM_1)$$

under comparable conditions.

The current operating point may be perfectly healthy.

There may simply be evidence that another point provides:

• better ROP,
• lower MSE,
• less dysfunction,
• better total efficiency.

Optimization does not require something to be wrong.

It requires an opportunity to improve.

This Is a Crucial Distinction

A drilling system can be:

healthy but suboptimal.

It can also be:

high-performing but dysfunctional.

Those two cases show why event detection and optimization should not be collapsed.

Healthy but suboptimal

No event alert required.

Optimization may still recommend exploring a better operating region.

High ROP but severe stick-slip

ROP appears excellent.

Dysfunction surveillance may indicate a mechanical problem.

The optimization objective should therefore incorporate the dysfunction evidence rather than simply chasing rate.

Mechanical health and drilling performance are separate properties: a healthy state can remain suboptimal, while high ROP can coexist with dysfunction.

Event Detection Usually Has a Defined Event Family

Examples include:

• washout,
• pump failure,
• overpull,
• sensor fault,
• bit failure.

The analytical design begins with:

What event are we trying to recognize?

Then engineers identify:

• relevant signals,
• expected signatures,
• confounding conditions.

The output maps back to the event family.

Optimization is different.

The output may not be a named event at all.

It may be:

Current operating region is inefficient relative to nearby historical observations.

That is a performance statement rather than an event diagnosis.

Optimization Requires an Objective Function

The phrase:

optimize drilling

is incomplete.

Optimize what?

Possible objectives include:

• ROP,
• MSE,
• mechanical efficiency,
• dysfunction avoidance,
• bit life,
• wellbore quality,
• section time.

Those objectives can conflict.

For example:

higher WOB may increase ROP.

It may also increase:

• stick-slip,
• bit loading,
• trajectory problems.

Therefore continuous optimization requires an explicit or implicit objective.

Conceptually:

$$Objective = f( ROP, Efficiency, Dysfunction, Constraints )$$

The definition of good performance must be established before an operating point can be called better.

Event Detection Requires a Loss Function Too—But a Different One

A detector also has tradeoffs.

Consider:

False negative

A real washout is missed.

False positive

The engineer is interrupted for an event that does not exist.

The detector threshold represents a balance between those costs.

For a high-consequence event:

the system may tolerate more false positives.

For a low-consequence condition:

it may require stronger evidence before alerting.

Therefore an alert threshold is not purely statistical.

It embeds an operational tradeoff.

Optimization Does Not Necessarily Need a Hard Threshold

Suppose drilling efficiency is:

0.72.

Is that poor?

What about:

0.74?

A hard boundary at:

0.73

may create artificial behavior:

0.72 → bad
0.74 → good

when the actual difference is negligible.

Continuous optimization is often better represented with:

• gradients,
• ranges,
• percentiles,
• operating envelopes,
• relative rankings.

Thresholds can still be useful for:

• hard equipment limits,
• dysfunction limits,
• minimum acceptable conditions.

But they do not need to define the entire optimization problem.

The Data Preprocessing Can Be Different

Consider torque.

For event detection, we may care about:

• maximum excursion,
• rapid oscillation,
• sudden step.

For optimization, we may care more about:

• stable average,
• median,
• variability over a representative interval.

If both workflows consume the same heavily smoothed torque trace:

the event detector may miss important dynamics.

If both consume raw high-frequency torque:

the optimization model may become unnecessarily noisy.

The correct architecture branches the source data.

$$Raw\ Data \rightarrow \begin{cases} Event\ Processing \ Optimization\ Processing \end{cases}$$

Preprocessing follows the engineering question: event surveillance preserves signatures, while performance evaluation isolates stable, comparable operation.

Rig State Matters Differently Too

For an event detector:

rig state helps determine whether a signature is physically plausible.

A pressure drop during:

pumps off

means something very different from a pressure drop while:

rotary drilling at constant flow.

For optimization:

rig state defines the population being optimized.

A WOB–RPM roadmap should normally evaluate:

rotary drilling observations

against other comparable rotary observations.

So rig state plays two roles.

Event detection

Contextual gating

Optimization

Population definition

The same classifier supports both, but for different reasons.

Event Detectors Often Need an Event Lifecycle

A mature event is not just:

on/off.

It may have stages.

For example:

1. normal,
2. evidence developing,
3. event suspected,
4. event confirmed,
5. event resolved.

That lifecycle matters operationally.

Without it, a detector can generate repeated notifications every time the probability moves around a threshold.

The system needs to remember:

We already told the user about this event.

That is why alert suppression and cooldown logic matter.

Lifecycle memory lets a detector issue one alert, retain the active event state, and suppress duplicate notifications until the condition resolves.

Optimization Has a Different Kind of Memory

Continuous optimization needs to remember:

• which operating point was tried,
• what the response was,
• whether the response stabilized,
• which formation was being drilled,
• whether the bit/BHA condition has changed.

Without that memory, the system can oscillate:

increase WOB
decrease WOB
increase WOB

without learning from the previous trial.

Optimization memory is therefore more about:

response history

than:

event lifecycle.

Optimization learns from controlled response: stable evidence updates the preferred region or guides the next feasible trial.

Historical Data Plays Different Roles

For event detection, historical data may help define:

• normal ranges,
• event signatures,
• model priors,
• training examples.

But the operational question remains:

Is an event occurring now?

For optimization, historical data is often directly used to define the initial operating landscape.

For example:

What WOB/RPM combinations performed well on comparable offsets?

The historical evidence provides a starting point.

Then the current well updates that knowledge.

Optimization Should Become More Local as Current-Well Evidence Accumulates

At the beginning of a section, offset data may provide the strongest evidence.

After several thousand feet, the current well has created substantial local information.

The hierarchy can shift:

$$Offset\ Knowledge \rightarrow Current\ Well\ Evidence$$

SPE-186166 cautions that historical drilling parameters should be treated as useful starting points because real-time data reflects current conditions more directly.[2]

That principle is central to adaptive optimization.

Event Detection May Need to Ignore Historical Success

Suppose the previous ten wells had no washouts.

Does that mean the current pressure anomaly should be ignored?

No.

The event detector evaluates the evidence currently present.

Historical frequency may affect:

• priors,
• thresholds,
• expected likelihood.

It should not override strong current evidence.

This is another distinction between:

benchmarking

and:

surveillance.

The Output Should Look Different to the User

A good event alert might say:

Hydraulic Abnormality Detected

Observed:

• pressure below modeled expectation,
• pump rate stable,
• evidence persistent.

Next step:

• inspect flow behavior and circulating system.

That is interruptive and focused.

A good optimization output might say:

Current Rotary Operating Region

WOB:

34–36 klbf

RPM:

120–125

Current response:

• stable,
• moderate-to-high efficiency.

Historical nearby region:

• slightly higher RPM has shown improved response under comparable conditions.

That output is exploratory.

It does not need the visual urgency of an alarm.

Event Detection Needs Explainability

When a system interrupts an engineer, the first question is:

Why did this alert fire?

The answer should expose:

• relevant signals,
• trends,
• model residuals,
• missing evidence.

SPE/IADC-184743 emphasizes that automated monitoring only adds value when users understand and act on the information, and that false or missed alarms must be minimized before deploying analytical outputs broadly.[3]

Explainability is therefore part of alert credibility.

Optimization Needs Explainability for Another Reason

When a system suggests:

Increase RPM

the engineer wants to know:

Why?

The evidence may include:

• current WOB/RPM location,
• nearby historical points,
• dysfunction state,
• current MSE/ROP response.

The issue is not merely trust.

It is constraint checking.

The driller or engineer may know something the analytical system does not:

• motor limit,
• vibration concern,
• directional requirement.

An optimization recommendation should therefore support human review rather than appear as an unexplained command.

Optimization Must Explicitly Respect Constraints

Suppose the historical map suggests better ROP at:

150 RPM.

But:

• motor limits,
• surface equipment,
• vibration,
• directional requirements

make that operating point undesirable.

The optimization problem is not:

$$\max Performance$$

It is:

$$\max Performance$$

subject to:

$$Equipment\ Constraints$$

$$Wellbore\ Constraints$$

$$Dysfunction\ Constraints$$

That makes continuous optimization a constrained decision problem.

Event Detection Can Create Constraints for Optimization

This is where the two analytical systems should interact.

Suppose the optimization layer finds that increasing WOB improves ROP.

Meanwhile, the dysfunction detector shows rapidly increasing stick-slip evidence.

The event/dysfunction layer should constrain the optimizer.

Conceptually:

$$Optimization$$

operates inside:

$$Safe\ / Acceptable\ State$$

This creates a hierarchy:

$$Surveillance \rightarrow Constraints \rightarrow Optimization$$

The highest ROP point is irrelevant if the mechanical state is unacceptable.

Surveillance defines the acceptable operating envelope; optimization searches for stronger performance only inside those constraints.

The Fastest Analytics Is Not Necessarily the Most Useful

Event detection sometimes needs:

• low latency.

If an event evolves quickly, waiting too long reduces value.

Optimization often benefits from:

• patience.

A parameter change needs enough stable response to evaluate properly.

Thus:

Event detector

May favor:

speed of recognition

Optimizer

May favor:

quality of response estimate

Those objectives can compete.

This is another reason one generic “real-time AI model” is usually too simplistic.

Real Time Does Not Mean Instantaneous

Both problems demonstrate this.

An event detector may deliberately wait for persistence before alerting.

An optimizer may wait for a representative drilling interval before evaluating a parameter change.

Therefore:

real time

should not be interpreted as:

respond to every individual sensor sample immediately.

A better definition is:

Process the information quickly enough to support the operational decision at the timescale on which that decision matters.

A Practical Example

Consider a hypothetical lateral.

Current operation:

• WOB = 34 klbf,
• RPM = 120,
• rotary ROP = 205 ft/hr.

The optimization layer sees historical and current-well evidence suggesting that:

125–130 RPM

may provide slightly better efficiency.

It recommends a controlled trial at:

128 RPM.

The driller makes the change.

ROP rises to:

220 ft/hr.

MSE improves.

So far, the optimization result appears favorable.

Then torque begins developing strong oscillation.

Now the dysfunction surveillance layer detects a persistent mechanical change.

At this point:

the optimization objective should not continue chasing higher ROP.

Instead:

the new dysfunction evidence modifies the feasible operating region.

The system may conclude:

the higher-RPM operating point is not currently acceptable despite its higher ROP.

This demonstrates the relationship between the two systems.

The optimizer asked:

Can performance improve?

The surveillance system asked:

Did an undesirable mechanical condition emerge?

Both answers matter.

The higher-RPM trial improves ROP and MSE, but later torque variability changes the acceptable operating region. All values are illustrative.

Another Example: Developing Washout

Now consider a hydraulic problem.

Pump rate remains stable.

Pressure begins slowly declining.

The continuous drilling optimizer might see:

• ROP still acceptable,
• WOB/RPM still efficient.

There may be no optimization problem at all.

The event detector sees something different:

• pressure departing from physical expectation,
• persistence increasing,
• hydraulic evidence becoming abnormal.

The correct response is not:

change WOB/RPM to recover efficiency.

It is:

investigate the circulating system.

This demonstrates why a generalized performance score cannot substitute for event surveillance.

One KPI Cannot Represent the Entire Well

There is a recurring temptation to compress:

• performance,
• equipment condition,
• hydraulics,
• dysfunction,
• hole condition

into one score.

A composite index can be useful.

But operationally, the system should still preserve the distinction between:

how well we are drilling

and:

whether something abnormal is happening.

A high composite score should not hide a critical event.

A low score should not automatically imply a failure.

Validation Metrics Should Differ

A washout detector can be evaluated using:

• detected events,
• missed events,
• false alerts,
• time to detection.

Those are classification/event metrics.

An optimizer requires different evaluation.

Possible questions include:

• Did recommended trials improve ROP?
• Did MSE improve?
• Was dysfunction reduced?
• Were constraints respected?
• Did section performance improve relative to comparable operation?

There may be no meaningful:

true positive

for a WOB optimization recommendation.

The validation problem is different because the output type is different.

Offline Backtesting Is Easier for Detection Than Optimization

For an event detector, historical data can often be replayed.

We know:

• washout occurred,
• event time,
• sensor history.

We can ask:

Would the algorithm have detected it?

Optimization is harder.

Suppose historical data shows:

WOB = 35
RPM = 120
ROP = 200.

What would ROP have been at:

WOB = 37
RPM = 130

at that same instant?

We do not know.

That alternative was never tried.

This is a counterfactual problem.

Historical drilling data contains:

what happened under the parameter choices actually made.

It does not directly contain:

what would have happened under every alternative parameter choice.

That makes optimization validation fundamentally difficult.

Correlation Is Especially Dangerous in Optimization

Suppose high RPM correlates with high ROP historically.

Did high RPM cause high ROP?

Maybe.

Or perhaps high RPM was used preferentially:

• in softer formation,
• with a newer bit,
• in cleaner hole conditions.

An event detector also faces confounding, but optimization turns correlation directly into a possible control action.

That raises the standard of evidence.

Before recommending:

increase RPM,

the system should have evidence that the relationship is sufficiently:

• comparable,
• local,
• physically plausible.

This naturally leads into a later article on correlation versus actionable drilling relationships.

Event Detection Can Be Useful Without Recommending an Action

An event system may say:

Hydraulic abnormality detected.

That alone can be valuable.

The engineer can investigate.

Optimization is different.

A performance score without a path toward improvement may have limited operational value.

If the objective is decision support, the optimizer eventually needs to answer something like:

What should we test next?

or:

Which nearby operating region appears stronger?

Thus the outputs differ in purpose.

A Practical System Architecture

A mature real-time drilling architecture might separate four layers.

1. State Recognition

What is the rig doing?

2. Surveillance

Are there:

• faults,
• dysfunctions,
• abnormal events?

3. Performance Evaluation

How efficient is the current operation?

4. Optimization

Is there a better feasible operating region?

Conceptually:

$$State \rightarrow Surveillance \rightarrow Performance \rightarrow Optimization$$

Not every application needs all four.

But separating the responsibilities makes the system easier to:

• validate,
• explain,
• maintain.

State recognition, surveillance, performance evaluation, and optimization share information while retaining distinct analytical responsibilities.

DrillingMetrics Surveillance Evidence and Event Record

The time-based view preserves the operational evidence, while the event table records PACK_OFF detections without exposing event dates.

The right-most pack-off belief track increases during the operational change, while the event log preserves BHA, mud-property, critical-flow-rate, and duration context with event dates withheld.

A Useful Design Checklist

Before building a real-time drilling analytic, ask:

Is the target a discrete event?

If yes, consider:

• persistence,
• false positives,
• event lifecycle,
• alert workflow.

Is the target continuous performance?

If yes, consider:

• objective function,
• comparable population,
• stable response window,
• feasible operating envelope.

Does the user need to be interrupted?

If yes:

this is likely an alerting problem.

Does the user need to compare and adjust?

If yes:

this is likely a decision-support or optimization problem.

Does one system constrain the other?

Often yes.

Dysfunction and equipment surveillance should normally bound the optimization space.

The Difference Matters More as AI Becomes More Capable

An AI system connected to drilling data may be capable of:

• detecting anomalies,
• summarizing events,
• comparing offsets,
• suggesting parameter changes.

That does not mean one generic reasoning process should perform all those tasks identically.

The distinction should remain explicit.

Event evidence

asks:

Is an abnormal condition developing?

Performance evidence

asks:

Is current operation efficient?

Optimization evidence

asks:

Which feasible alternative appears better?

An AI assistant can coordinate these layers.

It should not blur them.

Conclusion

Event detection and continuous optimization both belong inside modern drilling intelligence.

They are not the same analytical problem.

Event detection asks:

Has something happened that requires attention?

Continuous optimization asks:

Can the current operating condition be improved?

The first emphasizes:

• anomaly evidence,
• persistence,
• false-alarm control,
• event lifecycle,
• timely escalation.

The second emphasizes:

• performance objectives,
• stable response,
• operating envelopes,
• historical comparability,
• constraints,
• controlled experimentation.

They can share:

• sensors,
• rig state,
• physics models,
• contextual data.

But sharing inputs does not mean they should share identical:

• preprocessing,
• thresholds,
• validation,
• user interfaces.

The strongest real-time drilling architecture allows the two systems to complement one another.

Surveillance identifies the conditions that should not be ignored.

Optimization searches for better performance inside the operating region that remains acceptable.

That creates a much more useful hierarchy:

first understand what the rig is doing, then determine whether anything is wrong, then evaluate how well it is performing, and only then decide how the operating point might be improved.

---

References

1. Ambrus, A., Ashok, P., Thetford, T., Behounek, M., and collaborators. Real-Time Detection of Drillstring Washouts and Mud-Pump Failures. IADC/SPE-189700-MS, 2018.

2. Ambrus, A., Ashok, P., Chintapalli, A., Ramos, D., Behounek, M., Thetford, T. S., and Nelson, B. A Novel Probabilistic Rig Based Drilling Optimization Index to Improve Drilling Performance. SPE-186166-MS, SPE Offshore Europe Conference & Exhibition, Aberdeen, United Kingdom, 2017.

3. Behounek, M., Thetford, T., Yang, L., Hofer, E., White, M., Ashok, P., Ambrus, A., and Ramos, D. Human Factors Engineering in the Design and Deployment of a Novel Data Aggregation and Distribution System for Drilling Operations. SPE/IADC-184743-MS, SPE/IADC Drilling Conference and Exhibition, The Hague, Netherlands, 2017.