Handling bad data in Atmos SIM Online models
A lot of what we do in Atmos SIM both in model development and as users is dealing with bad data in online models. If the model just blindly follows the meters it's often going to produce nonsense results, because meters often fail. Now, in any real pipeline, there are more meters than are strictly needed to run a model, so Atmos SIM can usually survive one or even a few meter failures without much degradation of model accuracy.
The meter failures that cause the worst problems are pressure and flow meters and valve position sensors. If a gas chromatograph on a gas pipeline goes bad it might create a gap in reliable composition tracking, but it won't generally do much damage to the rest of the model results, as long as some basic validation takes place. Temperature meters are similarly less critical, especially since on a typically buried pipeline the fluid temperature doesn't change much in most of the system.
When a meter fails, either the SCADA system or an operator marks it as bad quality so Atmos SIM realizes it's bad, or that process fails too - leaving Atmos SIM with a wrong value marked as good quality. This blog won't go into meters that are noisy or drifting as that's handled by Atmos SIM's automatic tuning, which is a much larger topic.
First, I will discuss what Atmos SIM does initially when it is told that the meter has failed.
If Atmos SIM knows a meter just failed, you might think it could just drop it from the model. There are two possible problems with this: first, if this is the only meter at the end of a pipe, the model won't be stable if there's not some sort of physical boundary condition there, either a known pressure or a known flow. So, in that case, Atmos SIM must keep the last good value and hope that the meter comes back. If the flow meter at the terminus of the pipeline fails but the pressure meter still seems good, the model can switch over to just use the pressure meter - but it's common for the pressure and flow meters at one location to fail simultaneously, so it still might have to fall back to the last good value.
If Atmos SIM does switch from using a flow meter to using a pressure meter when the flow meter fails, or vice versa, we run into the second problem: suddenly switching to follow a pressure reading that the model wasn't exactly matching before can cause a large flow surge. This surge isn't real and so we would like to avoid it. Atmos SIM does that by applying an offset to the meter it newly started using to avoid the surge and then gradually reducing that offset to zero over an hour.
What if the failed meter doesn’t get marked as bad quality, so the model is still being told it's valid? Atmos SIM needs to automatically catch that somehow. The data manager and Atmos SIM both have multiple types of validation they can do. For instance, if a meter suddenly reads an invalid value or suddenly jumps by a physically unreasonable amount, or doesn't get updated for a long time, Atmos SIM might decide it has failed. However, we have to be careful, because something like a rapidly dropping pressure meter might indicate a meter failure, or more often, that someone is in the field proving the meter. It might be correct, however, there could be a pipe rupture. One way the user can distinguish between these cases is by looking at the behavior of nearby meters and checking if those are more consistent with a rupture or with a meter failure.
This approach isn't something you can always do immediately though because if the nearest meter is fifty kilometers away, the rupture would take a while to show up there. Also, we’ve seen a pressure meter start dropping rapidly and then the other pressure meter at the same valve station did too, while both showed good quality. It looked just like a rupture but in reality, the engineer visiting that valve station had just decided to prove both meters at once and was running them through their full range. That news had not made it back to the model.
This leads to an idea for some applications. On a pipeline that is prone to that sort of problem, if a good-quality pressure meter starts dropping fast we could spin off a second online model - the main model assuming the meter has failed and ignoring the drop and the new model assuming the meter is accurate and simulating the drop. After a while, one or the other model will start to diverge from the other meters in the system and then we discard the inaccurate model and keep the accurate one. That way we can still get a leak signal and a leak location, for example, if there is a rupture.
Click here to find out more about the Atmos Simulation Suite and its range of tools and services.