How to Build 3 Sigma Statistical Failure Detection for Pumps in Ladder Logic

3 Sigma pump failure detection uses rolling statistics inside the PLC to identify abnormal analog behavior before a fixed alarm threshold is crossed. By calculating a moving mean and standard deviation from recent pressure samples, ladder logic can trip on variance-based anomalies such as cavitation, leakage, or unstable flow conditions.

Static low-pressure alarms are a late defense, not an early warning system. By the time discharge pressure finally falls below a fixed trip point, the pump may already be running through cavitation, seal distress, or flow instability that has been visible in the signal for several seconds.

During validation of a centrifugal pump scenario in OLLA Lab, a 3 Sigma variance threshold on a simulated 4–20 mA discharge pressure signal detected flow-loss anomalies 4.2 seconds faster than a conventional static low-pressure alarm and triggered a safe shutdown before simulated seal damage occurred [Methodology: n=24 simulated fault runs in one centrifugal pump scenario; baseline comparator = fixed low-pressure trip only; time window = anomaly onset to alarm assertion over a 100 ms sampling regime]. This is an internal Ampergon Vallis benchmark, not a general industry performance claim.

The engineering point is straightforward: cloud analytics are useful for trend review, but deterministic interlocking belongs at the control edge. If the logic must act now, the PLC should not wait for a historian, a dashboard, or a network that may be unavailable.

PLC-level Statistical Process Control is valuable because it combines anomaly detection with deterministic action. The distinction matters: analytics can explain a failure later, but interlocks must prevent damage in real time.

Three practical advantages justify running bounded SPC logic in the PLC:

1. Deterministic interlocking The PLC can assert an alarm, stop a motor, or inhibit restart within the normal scan-and-output cycle. That is materially different from waiting for cloud-side evaluation and message return.
2. Network resilience The protection logic remains active even if the IT/OT link drops, the broker stalls, or the historian compresses the signal into something less useful for fast fault detection.
3. High-frequency signal visibility The PLC sees the analog input at the cadence of the control task. A historian often does not. Fast flutter, intermittent instability, and short-duration excursions are exactly the behaviors that fixed thresholds miss first.

This does not mean every predictive maintenance function belongs in ladder logic. Long-horizon diagnostics, fleet analytics, and model-based maintenance planning are usually better handled upstream. The PLC is the right place for bounded, deterministic statistical logic that must influence machine state immediately.

From a standards perspective, this separation is consistent with functional allocation discipline in industrial control systems: protective action should remain deterministic and testable, while advisory analytics can sit elsewhere (IEC, 2010; IEC, 2016). Different layers have different obligations.

3 Sigma logic is rolling standard deviation applied to a live process tag. The formula is familiar; the implementation details are where PLC projects become expensive.

For a sample window of N pressure readings:

μ = (1/N) × Σxᵢ

• Mean

σ² = (1/N) × Σ(xᵢ - μ)²

• Variance

σ = √σ²

• Standard deviation

UCL = μ + 3σ LCL = μ - 3σ

• 3 Sigma control limits

If the current pressure value falls outside that band, the logic asserts a statistical anomaly bit.

Required ladder logic math blocks

A practical implementation usually requires these instruction types:

• FIFO / FFL / array-shift logic to maintain a rolling sample window
• AVE or explicit ADD/DIV logic to calculate the rolling mean
• SUB to calculate deviation from the mean
• MUL to square the deviation
• ADD to accumulate squared deviations
• DIV to compute variance
• SQRT to calculate standard deviation
• MUL again to generate the 3 Sigma band
• CMP / LIM / GRT / LES to trigger the anomaly condition

The underlying assumption is that the baseline signal noise is approximately stable and sufficiently well-behaved for a standard deviation band to be meaningful. Real pump signals are not textbook-normal distributions, and no competent engineer should pretend otherwise. But for bounded anomaly detection on a stable operating regime, 3 Sigma logic is often useful because it is simple, transparent, and testable.

A rolling average starts with disciplined sampling and correct data types. If the analog pressure signal is stored as integers and then divided as though precision were optional, the math will be misleading.

### Step 1: Sample the analog input at a fixed interval

Use a timer or periodic task to sample the pressure input at a consistent rate. A common starting point is:

- Sample interval: 100 ms - Window size: 50 samples - Observation window: 5 seconds

That gives enough recent history to detect instability without making the control band too sluggish.

### Step 2: Store samples in a REAL array

Use REAL data types for:

• current pressure
• array elements
• rolling mean
• variance
• standard deviation
• upper and lower control limits

This avoids truncation during division and preserves analog resolution. Statistical logic built on integer math is often a quiet source of bad decisions.

### Step 3: Maintain the rolling window

Implement a FIFO or equivalent array-shift routine so that each new sample enters the window and the oldest sample is discarded. The key controls are:

• valid sample count
• array bounds
• initialization state
• behavior before the array is fully populated

Do not calculate variance on an empty or partially undefined buffer unless the logic explicitly handles that condition. Divide-by-zero faults are not evidence of advanced analytics.

### Step 4: Calculate the rolling mean

Once the array is populated:

• sum all sample values
• divide by the number of valid samples
• store the result as `Rolling_Mean`

If your platform supports an average instruction, use it. If not, explicit summation is fine, provided the execution cost is acceptable for the task period.

Practical implementation notes

A robust rung set usually includes:

• a Data_Ready bit once the sample window is full
• a Stats_Enable permissive tied to pump running state
• a Bad_Input_Quality inhibit if the analog signal is invalid, out of range, or stale
• a Startup_Mask_Timer to prevent nuisance alarms during transients

This is where commissioning judgment matters. A pump starting, stopping, or switching duty modes is not statistically anomalous by itself; it is simply changing state. The logic should know the difference.

Where OLLA Lab becomes operationally useful

OLLA Lab provides a bounded environment to test this array logic before it reaches a live controller. In the browser-based ladder editor, engineers can build the FIFO structure, run the logic in simulation mode, and use the Variables Panel to watch the array populate in real time.

That matters because “simulation-ready” should mean something observable. Operationally, it means an engineer can prove, observe, diagnose, and harden control logic against realistic process behavior before it reaches a live process. Syntax is only part of that. Deployability is the harder part.

The standard deviation rung sequence should be explicit, bounded, and easy to test. If the logic is too clever to review, it is too clever to trust.

Step-by-step ladder sequence

After the rolling mean has been calculated:

1. Iterate through each sample in the array.
2. Subtract the mean from the sample.
3. Square the deviation.
4. Accumulate the squared deviations.
5. Divide by N to get variance.
6. Apply SQRT to get standard deviation.
7. Multiply standard deviation by 3.0.
8. Add and subtract that value from the mean to create upper and lower control limits.
9. Compare the current pressure against those limits.
10. Latch a statistical anomaly alarm if the signal is outside the band.

Example ladder-style logic

// Calculate 3 Sigma band MUL Standard_Deviation 3.0 Sigma_Band ADD Rolling_Mean Sigma_Band Upper_Control_Limit SUB Rolling_Mean Sigma_Band Lower_Control_Limit

// Trigger anomaly alarm GRT Current_Pressure Upper_Control_Limit OTL Pump_Stat_Anomaly LES Current_Pressure Lower_Control_Limit OTL Pump_Stat_Anomaly

Interlock design considerations

A usable interlock usually needs more than a single compare instruction. Consider adding:

• persistence timing so one noisy sample does not trip the pump
• alarm versus trip separation
• auto-reset inhibition until operator review
• mode-based permissives so maintenance or manual mode does not trigger false trips
• event logging for mean, sigma, current value, and operating state at trip time

A clean pattern is:

• first breach → set Stat_Alarm
• sustained breach for defined time → set Trip_Request
• confirmed stop → latch Pump_Faulted

That sequence is easier to troubleshoot than a single rung that does everything badly.

A correction worth making

3 Sigma logic is not a substitute for process limits. It complements them. You still need hard low-pressure, dry-run, overload, and permissive logic. Statistical detection catches abnormal behavior early; fixed protection limits still guard the edge of safe operation.

Variance logic detects instability before absolute value collapse. That is the main advantage.

A small seal leak, suction problem, or early cavitation event may produce:

• pressure flutter
• oscillation amplitude growth
• intermittent dips and recoveries
• unstable flow behavior around an otherwise acceptable average value

A fixed alarm such as “Trip if pressure < 50 PSI” ignores all of that until the signal finally crosses the line. By then, the mechanical condition may already be degrading.

A 3 Sigma band reacts to the signal’s behavior relative to its recent baseline. If the pump normally runs at 72 PSI with low dispersion and suddenly begins oscillating between 66 and 78 PSI, the standard deviation rises even if the average remains above the static trip point. That is often the first useful warning.

This is not magic, and it is not universal. If the process itself is naturally unstable, a variance alarm may simply tell you that the process is variable. The method works best when applied to a stable operating regime with known normal behavior, proper mode gating, and a validated sample window.

Research in condition monitoring and anomaly detection supports the value of variance-sensitive features for rotating equipment and process systems, particularly when combined with domain-specific thresholds and operating context (Jardine et al., 2006; Lei et al., 2020; Yin et al., 2014). The implementation in a PLC is simpler than many model-based approaches, but the engineering discipline requirement does not disappear.

The sample window should match the process dynamics, not the engineer’s patience. A 50-sample window at 100 ms may be reasonable for one pump and ineffective for another.

Window selection factors

Choose the rolling window based on:

• sensor response time
• pump and piping dynamics
• expected disturbance frequency
• scan time and controller loading
• nuisance alarm tolerance
• required response speed

A short window reacts faster but is noisier. A long window is smoother but slower. The right answer is usually found by testing fault cases, not by arguing over round numbers.

Scan and execution considerations

Statistical logic consumes controller resources. In a sequential PLC scan, repeated array math and floating-point operations can become expensive, especially on smaller CPUs or crowded tasks.

Watch for:

• scan time growth
• periodic task overruns
• array index errors
• divide-by-zero conditions
• uninitialized REAL values
• excessive recalculation frequency

A sensible pattern is to:

• sample at a fixed interval
• calculate statistics only when a new sample arrives
• separate high-priority interlocks from lower-priority analytics
• benchmark scan impact during validation

This is one reason simulation matters. It is cheaper to discover a math routine is abusive in a virtual environment than during startup with operations waiting.

Alarm persistence

Use a persistence timer or count-based confirmation before tripping. Common patterns include:

• anomaly present for 500 ms
• 3 out of 5 consecutive samples outside the band
• repeated breaches within a rolling time bucket

That reduces nuisance trips while preserving early detection. The exact value should be justified against process risk and pump vulnerability, not copied without validation.

Variance logic must be tested against dynamic disturbance, not static forcing. A forced constant value proves very little beyond the fact that the simulator can hold a number.

In OLLA Lab, engineers can validate this logic in a web-based rehearsal environment that combines ladder execution, live variable inspection, and simulated equipment behavior. The relevant workflow is bounded and practical:

• build the ladder logic in the browser-based editor
• run the program in simulation mode
• monitor the pressure tag, mean, sigma, and alarm bits in the Variables Panel
• inject analog disturbance into the pressure signal
• observe the simulated pump state and fault response

Useful disturbance patterns to inject

For pump anomaly testing, the most informative cases are:

• analog drift to simulate gradual degradation
• square-wave disturbance to simulate unstable process behavior
• noise amplitude increase to simulate cavitation onset or pressure flutter
• step change plus oscillation to test recovery logic and persistence timing

The point is not to create theatrical faults. The point is to create repeatable, bounded fault signatures and verify that the logic responds as designed.

What digital twin validation means here

“Digital twin validation” should be used carefully. In this context, it means validating control logic against a realistic simulated equipment model and observable process behavior before deployment. It does not mean the simulation is a certified substitute for site acceptance testing, SIL verification, or plant commissioning.

That boundary matters. A simulator can expose logic defects, sequencing mistakes, and poor fault handling early. It cannot certify field wiring, instrument installation quality, hydraulic reality, or operator response under actual plant conditions. Anyone who blurs those categories is selling comfort rather than engineering evidence.

A credible project record is a compact body of engineering evidence, not a screenshot gallery. If you want the work to be reviewable by a lead engineer, instructor, or hiring manager, document the logic the way a control system deserves to be documented.

Use this structure:

State what counts as successful behavior. Example: “The PLC shall assert a statistical anomaly alarm within 1.0 second of sustained pressure instability and trip the pump if the anomaly persists for 2.0 seconds while in Auto and Run state.”

Specify the disturbance applied: drift, oscillation, amplitude increase, dropout, or mixed fault.

Document what changed after testing: window size, persistence timer, startup mask, compare threshold, or mode permissive.

1. System Description Define the pump system, the monitored analog tag, operating modes, and the intended protective action.
2. Operational definition of “correct”
3. Ladder logic and simulated equipment state Record the relevant rungs, tag list, sample interval, array length, and the simulated pump operating condition during the test.
4. The injected fault case
5. The revision made
6. Lessons learned State what the test exposed. Good examples include false positives during startup, excessive scan cost, or poor behavior during partial buffer fill.

This is the kind of evidence that supports engineering review. It shows cause, effect, revision, and judgment. A screenshot alone usually shows only that someone captured a screen.

Statistical anomaly logic should be treated as a diagnostic or protective enhancement unless formally engineered otherwise. It is not automatically a safety function merely because it trips equipment.

Three boundaries are worth stating clearly:

If the function is part of a safety instrumented system, it must be designed, validated, and maintained under the relevant safety lifecycle requirements. Statistical novelty does not exempt anyone from IEC 61508 or IEC 61511 discipline (IEC, 2010; IEC, 2016).

• A variance alarm is not a SIL claim.

Simulation can validate logic behavior and expose defects early, but it does not replace FAT, SAT, loop checks, or commissioning on the actual process.

• Simulation is not field proof.

A startup transient, valve stroke, or duty transfer can resemble a fault if the logic is not gated by process state.

• Abnormal detection requires mode context.

For broader reliability practice, condition monitoring literature consistently emphasizes that fault detection quality depends on signal quality, operating context, and validation against known fault signatures, not on the mere presence of an algorithm (Jardine et al., 2006; Lei et al., 2020). In other words, a formula is not yet a method.

- IEC 61131-3: Programmable controllers — Part 3 - IEC 61508 functional safety standards family - exida functional safety and validation resources - NAMUR NE 107 status signaling recommendation - Digital twin in industry: state-of-the-art (DOI)