Let's go a bit deeper into how an interface works and what we mean by loading points
and stick our toe into data compression.
In this video we'll cover the different actions an interface takes and how everything fits together.
Little disclaimer before we start I'm going to use the terms tag and point interchangeably.
In general the PI System calls them points and the OPC Server calls them tags or even
items. Things get a little bit messy in between. Are the concepts the same for all though? They're
essentially named streams of data coming from sensors. Right so here's what we have
now. We'll just concentrate on the interface and the Data Archive parts in this video.
So let's simplify this a little bit;
we've created one point, the point for our bearing temperature. Let's take a closer look at that.
We configured a few attributes for it: the name, point source, location 1 through location 5
and the instrument tag and the data security. I'll also add a few attributes for
exception and compression that we've kept at defaults. We'll talk about these in a little bit.
Now that's just one of our points, the first point we created, later in the course we're going to
create more points so we'll build up a big list of them. Now let's take a look at the interface. I'm
going to talk through what an interface actually does when it starts up, but before we do that
let's talk about our interface configuration. It runs under the account PISchool SVC PIINT,
we gave it a point source of OPC and an id of one, we accepted the default of one.
And it had a few scan frequencies set up; we got these from the template as well, so we have three
frequencies of one second and one frequency of two seconds.
Okay when our interface starts up it connects to the Data Archive. The Data Archive authenticates
it and maps it to an identity, then the interface asks the Data Archive a question: give me all the
points you have with a point source matching my configured point source. In this case it's OPC.
The data archive filters out the list of points and gives the interface the whole list
of everything matching the point source of OPC. Including all of their attributes and settings
and moves it over. So let's make a little bit more space here.
Now the interface asks another question and queries its own list which of these points
has a location 1 equal to my id? In this case the id is one. So our list is whittled down a little
and as an aside from this point onwards we're getting into OPC interface specific operation,
everything I've set up until now regarding interface functionality
would hold true for most other interfaces too.
For information on the interface type you're using check the manual for that interface.
Then our OPC interface checks each point in the lists location 3 and location 4. Location 3
controls the processing type of the tag: a 1 would indicate that it's an advise tag and a 0
indicates the poll tag. Our bearing temp tag has a location 3 of 1 indicating it's an advise tag;
this means that when the interface first makes a connection to the OPC server
it lets the server be in charge of when it sends data. If it was a poll tag the interface would
constantly poll for an update from the server at whatever we set the scan frequency to.
Speaking of scan frequency in the case of our bearing temp tag it has a location 4 of 1.
The interface matches this up with a list of scan frequencies.
It finds the first scan frequency, because the location 4 is 1 and it sees that it's 1 second.
Now it has all it needs to know to load the ta, it gets its instrument tag value
and then asks the OPC server please load the tag with the item id
sample process slash pump one slash bearing temp as a one second advise point. Because it's
an advise tag this effectively means that the interface connects and says hi OPC server send
me through any update you've got for the bearing temp tag but no more often than every one second.
Now in real life if we had multiple tags with the same class it would load them all in bulk.
These scan classes corresponding to location 4 on the tags give you flexibility on how they're
loaded on the OPC server. If your server has limitations on how many tags can be
loaded in a single OPC group the server will call these groups, you can split up your tags
into different groups by assigning them to different scan classes. This is why we've
got three scan classes all of them being one. So you can split up your tags there and it'll make
them assigned to different groups on the server. The exception to that is the first scan class,
if tags have a location 4 equal to 1, they must be advise tags so the location three also must be one
and they're automatically allocated to groups on the server.
In most cases this will be just fine; if you have if you're having trouble with the OPC
server you can check the documentation for more details on how you can split these up.
So after everything is loaded and the OPC server is sending through data of the interface
the interface will send it to the buffer and the buffer will send it to the Data Archive.
Note that while this is all happening the interface still maintains its connection
to the Data Archive and watches for any changes to its points.
Let's take a little look at how data is handled here, the Data Archive has a spot in memory and
a memory map file for the current value of every tag, it's called the snapshot.
It also has the files on disk for historical data for tags called archives. Te OPC server
has a new value for bearing temperature: it's 8.4, we call this value an event. The OPC server
sends this through to the interface the interface tests this value using a test called exception,
if it passes it sends the event through to the buffer which in turn sends it through to the
Data Archive. It gets stored to the snapshot ready to be read by reports and dashboards
and it will automatically be fed through to users that are looking at a real-time trend.
When the interface gets another reading: in this case 9.2,
it picks it up tests it for exception and then sends it through the buffer to the Data
Archive. The old 8.4 value in the snapshot gets tested using another test called compression;
if it passes the test it gets stored in an archive value ready for historical queries and reports.
The new 9.2 value replaces the old value in the snapshot, this is the most up-to-date value the
Data Archive has now and it'll automatically be fed through to users with active trends open.
So in this video we went into more depth on how an interface works and the interface settings that
correspond with point attributes. Another note on the specific interface we've been
discussing the PI Interface for OPCDA read-only. The way most interfaces work is similar but each
interface will be slightly different because it has to connect to a different data source Always
take a look at the interface user manual for specifics on tag configuration for any interface.
We also mentioned exception and compression as tests that new data events are run through
before the interface decides to send them through to the Data Archive in the case of exception or
before the Data Archive decides to save the event to disk in the case of compression.
We'll look at these in more detail in the next lesson.