Learn what normal looks like from the plant's own history, then measure everything else against it — and show the working, including the parts that do not hold up.
Is the data good enough to trust, when did the plant leave normal operation, and which of those departures are worth acting on?
A five-step pipeline that reads a plant's own historian export. Nothing comes from a model of how the plant should behave — normal is learned from a stretch of the plant's own history, and everything else is measured against it.
The raw export becomes one clean, regular table. Merged files, normalised timestamps, bad-value strings, gaps, frozen sensors and spikes — every repair recorded.
Tags grouped by how they move together, and the scope chosen: which tags, which period, and which window counts as normal.
A PCA model of normal, then the whole period scored against it with T² and SPE, plus oscillation and control-loop metrics.
Every finding challenged before anyone acts on it: does it rest on repaired data, is the reference window long enough, was the behaviour already there?
What survives becomes the assessment, with a prioritised action list and the questions only the plant can answer.
Where it has been run. Validated against the Tennessee Eastman benchmark, where the faults are known in advance: all three injected faults reported and all three non-faults set aside.
Which batches did not run like a good one, where in the batch did they diverge, and which tag took them there?
A batch cannot be judged the way a continuous plant is. Every batch is a different length and nothing about it is steady, so normal is not a window of time but a set of good batches.
Every batch stretched onto a common 0–100% progress axis, because comparing hour 10 of a short batch with hour 10 of a long one compares different things.
A mean trajectory with a corridor around it, learned from the batches known to be good.
Every batch against that corridor: how much of it sits outside, which tags, and at what point of the batch it first left.
The batch × tag × time array unfolded and modelled, giving one T² and one SPE per batch rather than per sample.
Batches banded by how far they strayed, worst first, each with the tags that put it there.
Where it has been run. Run on IndPenSim, 100 industrial-scale penicillin batches: all ten faulty batches caught and ranked as the ten worst, with one false alarm in ninety.
This loop is cycling — is the cause inside it, or is it only passing on someone else's problem?
The distinction decides the work. Inside means the controller or the valve is making the cycle, and the fix is a re-tune or a valve job. Outside means something upstream is cycling, and re-tuning this loop will not help and may make it worse.
Does the measurement cycle at all, once drift is removed?
Does the controller output cycle at the same period? If it does, the controller is part of the cycle. If not, the loop is receiving it.
Horch's test on the cross-correlation: a sticking valve makes it odd about zero lag, an outside disturbance makes it even.
Loops sharing one period point outside all of them. Lags say which turns first, and therefore where to walk upstream.
Every loop rated with the CDL Control Index, and the work ordered by what each fix buys.
Where it has been run. Run on 70 real plant loops: 48 cycling, 12 from inside the loop with 10 showing a valve signature, 21 from outside, and seven groups of loops sharing one period.
| IPA | BPA | CLA | |
|---|---|---|---|
| Process | continuous | batch | any, with loop data |
| Normal is | a window of time | a set of good batches | the loop's own setpoint |
| Needs a reference period | yes | yes, as batches | no |
| Answers | when did it leave normal | which batch, and where in it | inside the loop or outside |
| Typical data | days to weeks, all tags | tens of batches | days, PV/SP/output per loop |
How much data. IPA and BPA both learn normal from your history, so they need enough of it: roughly twenty samples per tag inside the reference window, and the window must span the slowest cycle in the plant. CLA has no such requirement, because each loop is measured against its own setpoint — which makes it the fastest of the three to get a result from.
Tell us what you are trying to settle and what data you can export. If none of the three can answer it from the data you have, that is worth knowing early.