What a PI System Health Audit Actually Finds
A PI System almost never fails all at once. It degrades, quietly, over years, and the first symptom is usually social rather than technical: an engineer stops trusting a trend and starts keeping their own spreadsheet.
Having audited a number of these estates, the findings are remarkably consistent. Here is what tends to turn up.
Interfaces that have not buffered in years
Buffering is the mechanism that protects data when the network between an interface node and the Data Archive is interrupted. It is also the thing most commonly misconfigured, disabled during a troubleshooting session in 2019, or quietly broken by a server rebuild.
The tell is not an alarm. It is a pattern of small gaps in history that correlate with network events nobody logged. The data is simply gone, and because the loss is small and distributed, nobody notices until someone tries to train a model on it.
Compression settings inherited from a hardware constraint that no longer exists
Exception and compression deviations were often set when disk was genuinely expensive. Those settings are frequently still in place on hardware with a thousand times the capacity, throwing away resolution nobody needs to discard any more.
The opposite is also common: compression effectively disabled on tags where it should apply, producing archives full of noise that slow every query made against them.
Tags nobody owns
Every long-lived estate accumulates them. Tags for equipment that was decommissioned. Tags created for a trial that ended. Tags duplicated during a migration where both copies were kept in case. They cost storage, they pollute search, and they make any attempt at an inventory a manual exercise.
An Asset Framework model that stopped matching the plant
AF models are usually built once, carefully, during a project with a budget. Then the plant changes and the model does not. Elements remain for equipment that is gone, attributes resolve to PI points that no longer update, and analyses fail silently — AF does not generally shout when a calculation stops producing output.
Silent analysis failure is the single finding that most often surprises people, because the dashboards built on those analyses continue to display a number. It is just the last number.
Backups that have never been restored
Almost everyone backs up. Far fewer have restored a backup into a test environment and confirmed that what came back was complete and usable. Until that has been done, a backup is a belief rather than a control.
One person who understands the whole thing
The most serious finding is rarely technical. It is that the system runs on institutional knowledge held by one engineer who configured it, has never documented it, and is within a few years of retirement. No audit finding has a worse risk-to-effort ratio, and none is easier to fix if you start before they leave.
Why the order matters
The reason to audit before a migration, an upgrade or an analytics programme is simple: every one of these findings propagates. Migrate without auditing and you faithfully reproduce the defects on new infrastructure at considerable expense. Build models on unverified data and the models inherit every flaw in it.
An audit is the cheapest engagement we run and the one that most often changes the scope of everything that follows. More on how we run them.