Exception reporting, compression
testing offer you the opportunity for maximum efficiency with your PI
points. The idea is to only store and deliver
meaningful data in the PI archives while discarding all the
noise. Now although PI is capable of storing an enormous amount of
data, it is still important to store only meaningful data
to make our PI servers run the most efficiently and
effectively as they can. Have you ever refreshed a
trend only to see some data points
disappear? What you are seeing is the effect of exception and
compression. The first test
of exception and compressions is exceptions. Exception
reporting takes place in the PI interface node before the values are
ever sent to the PI server. So here I have thermal couple measuring
temperature. And it has a certain
inscript precision. And successive values
come in however many of them are within the instrument precision.
So we would call these
values -- we would say that they don't really have meaning. They aren't
significant and we shouldn't base decisions on them.
Fortunately the PI system gives us an option through
exception to filter these out and not burn in our network traffic
or our PI service performance with them.
We do that with two settings -- exception deviation which
defines the width of this dead-band and
with exception maximum which defines the maximum length of
time to go before reporting a new value.
So to see
this, it easiest to see this in action. Here we have some
raw values that were scanned at a data source and
we are willing to apply an exception to them. So we'll start off
with our first value and values that come
in. Now as they come in, we see that their width is
the dead-band and they'll drop off.
One other note to
make, we've kept the previous value here. This is important
so that we can preserve the fidelity of the data later on.
But here we have all the raw values that pass the
exception algorithm and were sent to the Snapshot
table. OSISoft's recommendations for exceptions
are to set the exception deviation a little less than the
instrument precision. Or perhaps about half of the compression deviation.
For more details you can consult this KB article,
3226OSI8@techsupport.osisoft.com
The next test
is the compression test. This is a
more thorough test that defines which data is actually
stored in the PI archives. What is special about this
test compared to the exception is it has a slope. This is why
we sometimes call it the swinging door algorithm. It's like a door
viewed from above. It has a thickness and a
length and it swings so that it can be at many different
slopes. Again, like exceptions, there are deviation
settings and a maximum setting.
Again this is easy to see in action
so we are going to see a compression test applied to all of those raw values
from before. We start with the most
recent archive value that has made it into the PI
archives. Next we compare it to a
Snapshot value and we apply the
compression deviation to define one angle.
And then we compare future values to see if they
fall in that angle or outside of it.
So we see the raw values scanned at the
data source. What passed exception.. What
passed compression.. The trend that will be drawn in PI ProcessBook
or PI CoreSight. And we can see that all the raw
values fall within the dead-band setup by
compression deviation.
For more information check out
techsupport.osisoft.com or look at the more thorough
exception and compression video.