In this part of OSISoft's
AMI infrastructure, we'll talk about what
happens when you add a meter and specifically how we add a tag to
the PI Server in the
AMI infrastructure. First off, we are going
to talk about the on demand mode which means creating
tags on demand versus the pre-created mode. We'll talk about that
in the second half of the video. So to start
off, we have meters and then we have areas
where we want to view the data. And so we need PI tags
to accept that data. So we have a data source, we have a
PI interface, and we have the PI Server which will ultimately
store that data.
We also have the PI AF Server and
the Enterprise Gateway machine on the side
here. We
will concentrate in this video on the PI Server and
how we create tags on that machine.
So we are drawing boxes, and each one of
these boxes represents a piece of hardware, a server
that houses the data source software or the PI Server
software. And data flows from left to right,
both usage data and in this case data that is
necessary to create a meter. So we get a
new meter. A new meter is added to the
system. And how do we go about now creating a
tag? So we have the head end software, that's
the stuff that will notice that there is a
new meter and interact with it and collect data
from it. And then on the far side, we have the PI Server
software. And to start with,
on here there is a tagged database. So this is
just a table that keeps track of all of the tags that this
PI Server has registered on it, or has created on
it. So if we have a million tags, then there will
be a million tags in that tag database. Then there is the
archive, and that just stores meter usage data. Now
the archive has a spot for every tag in the tag
database which is part of the challenge
here. Because if we suddenly create a lot of
tags, the archive might not have space for that many tags
available. But we'll talk about that later when we
get to pre-created. So PI SCC
has in its heart, it has meters.table. So this is
usually named according to the head end
software, then meters.table. And it
keeps track of all the meters that are registered with
PI SCC. And all the PI points that they
need to write too. We can call this the master table,
it's the central brain of the whole operation. So
when a new meter is added, the head end software will write an XML
file in one method, and it will write
an XML file which will be interpreted by the
meters.table. And that will create an
entry into the table to record that there is a new
meter available -- master.table
Now once a new
meter is added to the master table, it's going
to be put into a queue to be created on the PI
Server. There is also an edit queue in case
we need to edit tags. So upon a new meter coming
in, it's put into this create queue. And the reason we have
a queue is because 1000s of meters might be created all at once.
And if we lost connection to the PI Server, we want to be able to
pick up where we left off. Now these are
picked up by the PI Server and added to the tag database.
Now if there is an error, if there is
any reason that we weren't able to create that tag, it will
be reported to PI SCC which will then put that
command into a try again queue. So this will just attempt
to create the tag again, or edit that tag again if it didn't
work the first time. And it will
just keep trying until it succeeds. Now what
if we had lots
and lots of meters. Well we can get into a problem. Like
I said before, on demand might not be sufficient. We might need
to do something called pre-created. Now the
reason is that our archive usually only has space for a certain
number of tags. And if
we intended to put more tags in there, we would've made the archive
much much bigger to begin with. But we can make sure that
that problem won't be encountered if we just create a lot of tags
in the first place. So before we install and start running
PI SCC, we will run something called
AMITagCreate.exe. With this, we can
create a number of reserved tags. And these will
be named _reserved1, _reserved2.
And what they allow us to do is
have a bunch of empty reserved spaces in the tag database and in the
archive. So when we create those 100,000's of tags, we already have
spots for them. So let's talk about that
data source again. And we have the
PI interface.
And the PI
server machine.
OK, now
one important note about this
is if we use AMITagCreate, it will create a
file called the pre-cache file. Now what the pre-cache does is it
informs IP SCC about all of
these reserved tags that are there. Because PI SCC
otherwise wouldn't know about them. It's important that the
pre-cache file is never deleted. It's a permanent record
of all the tags that were reserved in the first place for
PI SCC to keep track of them. Once a
new meter is created and it is put into the
meters.table, the master
table, if there is a reserved tag available, it will consult
with the pre-cache file and then put a command into the
deploy queue to rename that reserved tag to
now match the new meter.
Also there is also an edit queue which allows
tags to be edited as well, just like the
on demand mode. OK, so we have a new
meter and it comes into the master table. Then it is sent to
the deploy queue. And then it is sent out to the tag database and the
PI Server which will take one of those reserved tags, and rename
it into a new name for the meter.
Similarly,
we can edit tags the same way. Now if
we run out of reserved tags, eventually we
can just create them just using the same methodology
as we did for the on demand mode using a create queue.
And similarly, if there are problems, there is a try again queue,
if there are any errors in editing or deleting or renaming tags.
Now say
we had a problem somewhere in this in creating a
tag or renaming a tag. You'll
want to troubleshoot, start on the right side of this
diagram and move to the left. Checking each one to
see if the tag command got that far. So troubleshooting.
For example, if we suspect the queues, we
could use the queuesclient.exe
which is available on the PIPC folder,
to look into those queues to see if the command is
in there. Similarly, if we want to just look at the PI
Server, we could use PISMT or the other array
of PI Server troubleshooting tools. If we want to check
if the meter made it into the table, we could
use tablesclient.exe. And to check if
the meter even made it to the head end software,
we have a client for that too. So this one will just be
named after whichever head end we are using.
So the head end, then test.exe. That will
allow you to look at the head end itself or the
XML file that is written to PI SCC sometimes
containing new meter structures. And lastly,
the pre-cache file. We
want to look into that cache file or any other file with
cache in the name, there is cacheclient.exe which will allow
you to look into there. While you can safely
browse any of these files with these client tools, you should
never edit or delete any of them without specific direction from OSISoft.
Doing so could cause serious headaches.
Thanks for watching the video.