Skip to content

Operational Context Without Extra Sensors

The Problem

In many pipeline monitoring setups you do not have real-time access to:

  • Pump RPM or status
  • Valve position or opening commands
  • Operator setpoint changes

So the natural question is: how can we tell a leak apart from a normal operational change (e.g. opening a valve or changing pump speed) using only the signals we have—typically pressure (PT) and flow (GT)?

This document describes the engineering philosophy and practical solutions we use: inferring operational context and transient type from PT/GT alone, so the model can learn “this looks like an operational change, not a leak.”

Key Idea: Signatures Are Different

  • Operational change: Often smooth, coordinated (pressure and flow move in a coherent way), and low in high-frequency oscillation.
  • Leak: Introduces turbulence and oscillations; pressure and flow can show chaotic, less coherent behavior and higher variability.

So we do not need a direct “valve open/closed” signal. We build features that capture:

  1. Oscillation — e.g. zero crossings of first/second derivative (leak → more oscillation).
  2. Coherence — e.g. correlation between PT and GT derivatives (operational change → more coherent).
  3. Baseline deviation — how far the current window is from “normal” operating profiles learned per operating level.

The model then learns: if the transient looks smooth and coherent, treat it as non-leak; if it looks oscillatory and chaotic, treat it as leak.

Solution 1: Infer Operational State from PT/GT

Concept: Operational state is already encoded in your signals.

  • Pressure level: Classify mean pressure into bands (e.g. low / medium / high) to represent “operating point”.
  • Flow level: Same for flow.
  • Transient type score: From existing features (e.g. energy ratio, PT–GT derivative correlation, spectral entropy, zero crossings), compute a score where:
  • 0.0 ≈ “clean operational change”
  • 1.0 ≈ “chaotic leak-like transient”
  • External command likelihood: If the transient is smooth and highly coherent (e.g. high PT–GT derivative correlation, few zero crossings), assign high probability that it is an intentional command rather than a leak.

Why it works: Operational changes have a smooth, coherent signature; leaks have a chaotic, oscillatory one. The model learns: “smooth + coherent → not leak.”

Solution 2: Adaptive Baseline

Concept: Learn a “normal” operating profile for different conditions (e.g. low/medium/high flow). At inference time, measure how far the current window is from these profiles.

  • Training: Build profiles (e.g. mean/std of PT, GT per operating level) from non-leak windows.
  • Inference: Compute deviation features (e.g. distance to nearest profile, or Mahalanobis-style deviation).
  • Use: A large deviation from “normal” can indicate an anomaly (leak or other fault); combined with oscillation/coherence, the model can separate leak from operational change.

Solution 3: Transient-Type Score (Single Composite)

Combine several features into one transient-type score that correlates with “leak vs operational”:

  • High oscillation (e.g. zero crossings), low PT–GT derivative correlation, high spectral entropy → score toward leak.
  • Low oscillation, high correlation, low entropy → score toward operational change.

Use this score as an input feature to the classifier so the model can learn a decision boundary in one place.

Implementation Notes

  • These ideas are reflected in the feature extraction (e.g. wavelet-based and derivative features) and in how we design labels (e.g. leak vs no-leak per window).
  • The exact feature names and formulas live in the feature extraction code and pipeline config; this document states the rationale so that future changes (e.g. new sensors or new pipelines) stay aligned with the same philosophy: operational context and transient type can be inferred from PT/GT alone.

Summary

Goal Approach
Distinguish leak vs operational change Use oscillation, coherence, and baseline-deviation features derived from PT/GT.
Avoid extra hardware Infer operational state and transient type from existing signals.
Keep the model interpretable Use explicit features (levels, scores, deviations) so behavior is auditable.

This operational-context philosophy is central to how we train and validate detection models in the platform.