Research · Faults in sensor history ·
Watching historian data by its shape
Utilities already record years of readings from every transformer, pump and meter. We are testing whether reading that record by its shape rather than its value can warn of some slow faults sooner than an alarm limit does, recognise a fault from other assets in the fleet, and say what is likely to happen next.
Every utility already owns a record of how its assets behave. Transformer temperatures, zone flows, pump currents and valve positions are logged, reading by reading, in a system called a process historian, often going back a decade. A large network logs hundreds of thousands to millions of these signals.
Most of that record is only looked at when something has already gone wrong. Day to day, utilities watch it through alarm limits: a temperature above a set point, a flow above a threshold. On a fault that develops slowly, a limit can fire late, because the value takes time to reach it. On a sudden fault a limit is quick, and nothing here claims to beat it. And set tight enough to fire earlier, limits fire constantly, which is how control rooms end up with more alarms than anyone can act on.
Some early signs show in the shape of the signal rather than its value: a transformer that cools down more slowly after the evening peak, a water zone whose overnight low creeps up, a pump whose current starts to flicker. An experienced engineer can spot these on a trend chart. Nobody can watch a million trend charts.
Why this is harder than it sounds
A historian does not keep every reading. To save space it keeps a value only when the signal has moved enough to matter: a busy signal keeps a reading every few minutes, a steady one may keep nothing for hours. The record is deliberately uneven.
Most analytics and AI tools cannot use it that way. They first fill it back in to a fixed interval, one value every minute or every fifteen minutes, inventing the readings in between. That smooths away the timing that makes a shape recognisable, and our early work (not yet on historian data, and not yet reviewed) suggests it costs forecasting accuracy, more so the sparser the data. A steady, heavily compressed signal is exactly that kind of data.
Patternode reads the record as the historian kept it, and compares shapes directly.
Level of detail comes from the data
Nobody should have to choose a tolerance before the watch can run, or tune one for each signal or each asset. The aim is for the level of detail to come from the data: sized from each signal’s own history, so a hot transformer and a cool one, a large zone and a small one, each get detail to match without anyone deciding it, and read at several timescales at once rather than one. Our benchmarks so far use one fixed rule, a tolerance in proportion to each signal’s normal range, which is the simplest version of that aim.
That matters at scale. An approach that has to be configured signal by signal struggles to reach the hundreds of thousands of signals a utility holds. One that sets its own level of detail can be pointed at a whole fleet.
A tree of shapes
Comparing whole days is the simplest version. The method we are now testing goes further, and reads the record the way the historian cut it. Each stretch between two kept readings is a segment; segments that follow one trend are grouped into a larger shape, and those into larger ones, so a day becomes a tree of shapes measured without units. As each new segment arrives, it and the shapes above it are compared with trees from normal operation. A shape far from anything normal raises an alert, which can come while the values themselves are still in range.
How the value would be realised
This figure shows where the method would sit in a utility’s week: from the historian it already runs, through an offline export and a watch across the fleet, to an alert that explains itself and a repair planned before anything fails. Click a step to pick it out.
Why it matters to a utility
Earlier warning, where it can be had. Catching a failing transformer or a growing leak days sooner is the difference between a planned repair and an outage or a burst. The industry’s best-known predictive maintenance successes are single early catches worth millions. Whether shape reading gets there sooner on real utility faults is what a pilot would show; it is not yet shown.
Fewer, better alarms. An alert that explains itself, and that is judged against the asset’s own normal, is one an operator can act on rather than acknowledge and ignore.
The fleet learns. A fault seen once, on any asset of a kind, becomes something every other asset of that kind is checked against, whatever its size or rating.
Built on what they already own. It reads the historian a utility already has, with no new sensors and no replacement system, and it can start from an offline export before it is ever connected to operational networks.
Decisions stay with people. Every alert shows the days it was compared with, which suits a sector where regulators expect operators, not models, to make the operating call.
What it does not do
This is an illustration on made-up data. The assets, faults, alarms and lead times are invented to show the idea, and the detector is a simplified version written for this page, not the platform itself. Nothing on this page is a measured result, and it does not claim to warn sooner than an alarm in general: on sudden faults an alarm limit is usually as quick or quicker.
It reads one signal at a time. A fault that shows only in how several signals move together needs a model of those signals alongside it. Normal also changes with the seasons, so a real deployment learns from at least a year of history, not ten days.
Next
The next step is to prove it on real historian data: a year of readings for one class of asset, exported offline, checked against failures the utility already knows about. If you run a historian and would like to try this on an export of your own, see Work with Patternode.