Don’t be alarmed

And that’s going to become unmanageable.

To the breached threshold alarms of old, we at i2O can already add detected events and detected transients. We already have an algorithm that infers PRV condition. We’d like to add customer calls, pipe condition risk, turned valves and social media insights into the mix.

And when we have all these, we will need a new way to turn them into something that’s actionable. It just won’t be possible to have people monitoring all these variables all of the time.

We suggest the probabilistic model.

Today, action may only be taken once there are 3 customer calls from the same area as it then becomes pretty certain that there is a network, rather than an isolated, issue. But in future it should be possible to act on the first customer call, knowing that it is likely to be a network issue, if it can also be correlated with a detected event, for example. Perhaps action could be taken even before customers start calling.

In any case it will allow action to be taken more quickly and with a greater degree of confidence.

Instead of receiving an alarm, we will receive a notification. It will be based on the probabilistic model which defines how likely it is that we have a particular type of issue based on the status of all the insights.

If the accuracy of this system proves to be high, and people come to trust it, it could automatically schedule resources through the Work and Asset Management system.

But that lies further in the future.

In the meantime, i2O will be changing its nomenclature from ‘alarms’ to ‘threshold breaches’ to clear the path to a better and more useful future in which there will be no need to be alarmed.