I'd like to start the discussion of the PI AF Database
by showing you what you can do with it. Here's a
display in ProcessBook that is designed to be
element-relative, and what that means is as I
choose these different elements, these are elements in
what's know as AF, when I choose
these different elements we change the display
to show what's appropriate for that particular
context. So, that's what you can do
with it. Now, let's take a look at what the actual structure is.
If you've worked with the PI System for a long time and you
haven't seen AF before, I think this is a,
a huge difference, this is a huge change from what you would normally
expect to see with PI. What we're looking at is a
hierarchy. This is something called the PI System
Explorer. PI System Explorer's our primary
view into something called AF, our Asset Data Base.
It's a view into a system that's, as you can
see, hierarchically-based, and what it represents
for the PI System is a
fundamental change of how people will be able to find things
in the PI System. Up until AF we
would take, I guess what you would call the Rolodex approach to
finding PI Tags. Let me give you an example.
You know, typically, if I wanted to build something in ProcessBook
I would go and do a Tag Search
and use the Tag Search to find whatever
it is I'm interested in by
typing in either a Tag Name Mask or
maybe the name of the Engineering Units, or the -- a partial
descriptor. In any case, it was a simple
look-up. It's like going through a Rolodex and saying well, what
was, you know, what's that plumber's name again? We would
organize things simply in a big long
list from A through Z, and that
might work with maybe 2,000, 5,000
Tags. Even then it gets kind of clumsy. But when you're
talking about 150,000 point systems,
1, 1.5 million point systems, then the
Rolodex approach doesn't really work very well. And, besides,
when you're just simply searching for things,
once you find those things you may
want to find related objects, objects related
to the thing that you're looking for. And, if all you have
is something that's the equivalent of a Rolodex, well, there's really no
structure there that tells you what might be related, and unless
you were extremely clever when you first came up with your naming
convention, then there's going to be some things that you've probably missed
in your naming convention where, you know, somebody creates a
calculation or an aggregation that you just
forget about, and the person who comes and takes over
managing the system doesn't know it's there. So, for example,
here is a Tag Search,
looking for _int, and it's showing these different
Energy Usage. We have three different
Energy Usage Tags that have that Tag Mask.
Now, I know for a fact that there's a fourth Tag
that is related to these three Tags.
Unfortunately, that fourth Tag doesn't fit the naming convention.
It was created a few months later, and it was a
totalization, so, for me to find that
particular Tag I would have to know that it begins with
the letters _tot and then I would
go out and I would find, you know, that particular
process value. So,
anyway, because we find there are so many customers
that would have, have these large systems, and they would like a better
mechanism for navigating, what we've created
is more of a hierarchical view
of looking at your PI Data. So what we're
looking at here, ultimately, is exactly the same
set of PI Tags that we saw before. As I
switch between these different, what we call Elements, within
AF, you can take a look down here and find
those are the actual, those are, they're pointers
that are pointing to those same Tags that we found
in our Tag Search, and you can see
that over here, if I, as I switch from one Element to the
next, you'll see that each of these is a reference
to a PI Tag.
So, instead of having to search for them using this
Tag Search, you know, in which I
supplied a specific Tag Mask,
instead of that, what I
can do is simply drill down through the AF
Explorer. And, in this case, I'm drilling down geographically.
I said OK, within the San Leandro office,
within our Power Distribution, you know, within this
particular component under Inputs,
these are the four things organized underneath that particular
structure, that element structure there.
Now the beauty of this, as I said,
we're grouping these together in some way that
makes sense logically, in this case, geographically.
So, do you remember earlier when I searched and I found these
three measures of Temperature Use,
or, excuse me, of Energy Use, but I didn't find the totalization?
Well, now, you can't miss it. It's sitting right here in
this list. So, if you're the person that inherits this PI System,
from some previous System Manager, you're going to see right
away, oh, he's already done an aggregation that totalizes
this. You don't need to know what that naming convention
is. I like the analogy
that Buck Bard, our Training Manager, uses when he teaches this
class. You know, he says, if we're going to go out and meet at a
restaurant, I could sit down and say okay,
it's a restaurant, it's Chinese food, it's got,
you know, two stories, there's parking in the back. He can do all
this and then you'd have to go out and look through all
the restaurants in town for that restaurant, or, he
can just give you the address. And, if he gives you the street
address, then you'll just go right there and find it.
Now, I like to build on that analogy one more.
Within that, you know, if you do go out to that restaurant, that
restaurant's going to have a menu. You can look at it, right?
If you were to go to a different restaurant, that restaurant
would also have an object that we call a menu.
In fact, almost every restaurant you're going to go to is going to have
a menu. Well, one of the things that you can do
with these, these elements,
is, if there are objects that are common between the
elements, like, for example, a menu is common
among restaurants, then you can make element-relative
displays. In other words, you can say, hey, go to
that restaurant and open that menu, or, in the case of
working within, oh, for example, an
Equipment List when we're talking about Flow Meters, you can
say, go to the Montreal, you know,
Equipment List, go to Flow Meter 01, and look at
the Flow Rate. Or, you can say, let's go to a different,
you know, a different geographical location. Instead of
Montreal let's go to Houston.
Within that same structure, let's go to
Flow Meter 01 within Houston and look at Flow Rate.
Both of them represent
Flows, and both of them have a Flow Rate, just like
each restaurant has a menu. Now, these things we call attributes,
and when they're in common like that, when they're attributes in common,
then you can make what we call
these Element Relative Displays. Now in
the case of this Element Relative Display, what we're
looking at is a series of tanks. Each one of these
tanks has two variables. Let me just hover over
this so you can see it. It has a Level which is Blue,
and it has an Inside Temperature. These are
tanks. As I switch from one tank to the next,
each one of those tanks has an Inside
Temperature in Red and a Level in Blue.
There we go. Yeah, the E dot that you see there,
that's our indication that this is element
relative, and as I keep switching, you know,
one to the next, each one of these tanks,
just like each restaurant has a menu, each one of these tanks
has a Level and an Inside Temperature, and we're going to
look at whatever is the appropriate
Level and Inside Temperature given the current
context. And, context is the other
concept we need to go over. As I hover, or as I switch
from one to the next, I'm looking at these three different
tanks here. Let's go to Houston. Take a look at the
little balloon help that just appeared in yellow there.
You notice the context, big long context. It's telling me --
let me go back there -- it's telling me it's under
OSIsoft Enterprises, Geography --
yeah, here we go -- OSIsoft Enterprises,
Geography, Houston, Chemicals Division, etc.,
Mixing Room, Houston Tank 001.
That is the current context.
It's a very important technical term that we use all
throughout our discussions of AF, so please,
keep in mind when we talk about
context, we're simply talking about the address.
It's like saying which restaurant am I looking at?
You know if I'm sitting in a Chinese restaurant
and I say the word menu, it's going to show me
a menu. But, if I'm sitting in a Mexican restaurant, and I
see a menu, it's going to show me a different menu. It
depends on the context. So,
if I switch over now to Montreal, let's
take a look at that context. Yeah. By selecting this,
now take a look at
the context here. Now, this context,
OSIsoft, Geography, Montreal, Chemicals
Production Mixing Room, etc. Different context
because we're at a different part of your plan.
Now, one final thing about AF
is that, so far, we've been talking about assets
as though they exist solely in
the real world. You know there is a city called
Houston. In the city called Houston we have a
Chemicals Division, there's an Equipment List, etc., etc.
Well, that's only one of the many ways we
could have organized this. In fact, that's probably the way,
I would guess, the engineers would want to look at it -
organizing it by location, and then within
specific different parts of your organization
where you would find that particular Production Value.
Well, that's not necessarily going to be the
same way the Yield Accountants want to look at it.
The Yield Accountants may say, well, we need to divide things
by Division. So, they have all the different
tanks underneath the Chemicals Division,
all the different, different
Power Consumption under the Power Division, etc. They don't really care --
I mean they do break it down eventually, but, for them
it's more important that they group these at that level.
And so, when we talk about this hierarchy
here, it's a hierarchy that can be
using any kind of a structure that you want.
So, for example, other types of
organizations you might want would be the
E&I Technicians, the Instrument Technicians. They
may organize this, not, neither by division nor by
geography, but by the manufacturer
of that particular piece of equipment. So if there's some kind of a
recall, or some kind of an issue of recalibration
problems, you can go through and immediately find
all those, all those pieces of
equipment based on the manufacturer, or based
on the install date, or based on who installed it.
So, that's a different way that you could organize this
structure. I mentioned it one more time but I just want to
reiterate this technical term that we use
when we get down to the actual point at which we're going to be
looking at data. That level of organization
we call an Attribute. See each of these
that we're look at here so far, Houston, Chemicals,
Equipment, Flow Meters, etc. - those are all Elements. Elements
are organizational structures. Once
you actually need to get access to some
actual data of interest,
something that actually shows you either the Real Time Value
or a look-up in a table, or perhaps
an installation date, once you need to get to that
actual information, we call that structure an
Attribute. And, you'll notice, especially if we
go into Tanks here, you'll notice when we get the specific
Tanks, those Attributes,
there's not just going to be a one-for-one relationship between
Elements and Attributes. There are some Elements,
like in, for example, this Tank here that has
many different Attributes. It's got an Inside Temperature,
a Level, Outside Temperature, a Product that
you're making, the Current Diameter of that Tank,
etc. So, these are all the different things,
we call them Attributes, and the Attributes can be
things such as, as you can see right here, this
is just a simple string reference. It could
be some type of a calculation
or it can be -- yeah, here's a calculation --
or it can be a reference to a PI Tag.
We also have the ability to do look-ups to
relational data bases.
Now, in this class we don't go into much more detail about AF
than that. What we are going to do, however, in this
class, is we're going to ask you go build not
an AF structure, but we're going to ask you to use an AF
structure to create an AF Element-
Relative Display. And what we're going to be doing is
exploiting the fact that
within an AF structure
you may have many different contexts, like
Reactor 1, 2, 3, etc. Within those
contexts, if you have Attributes
that are identical, like, for example, if all
of those contexts have an Attribute called Temperature,
then you can build an Element-Relative Display
such that, instead of having the user
require to remember the names of these Tags,
instead of that, all he has to know
is what the Name of the Attribute is and then
supply the proper context, and we will
translate that into showing the right PI Tag.