AF is considered part of the PI System.
As you can see here we describe it as an integral part.
What's not pictured here, though, is the activity
of SQL Server. As we'll discuss in more
detail later, SQL Server ends up being an
important component, primarily just for storage purposes,
but SQL Server is a component that we
require with AF. Now let's take a look
at what this looks like if we actually look at a typical
PI System that's using AF.
Now in this case we've got three
components described in this diagram, and it's the three
major components of AF. They're the AF
Client Applications, the AF Server,
and a copy of SQL Server that contains
the AF information. We've got
it labeled there AF SQL Database, but this is just regular
Microsoft SQL Server. We're not talking about
anything that comes from OSI here. That's a copy of SQL
Server that happens to have an,
a database on it that we use in AF.
So here's how it works. The Clients are those
Applications that use our AF SDK,
our Software Development Kit, to make requests
for that AF structure that we saw
in our, our PI System Explorer. So, if I can go
back, bounce back here, you see these structures here.
This is an AF Client right here. This AF Client is
presenting to me this list of structures
and from here I can drill down and find the
Tanks, Pumps, etc., that I'm interested in.
Now, that AF Client
was making requests for information
that is, in fact, stored in
SQL Server. We use SQL Server as a mechanism
for storing that structure that we just saw
in the PI System Explorer.
The AF Server's job is to handle all the security
requests, or all the security for the requests
between this Client and this Server, and also
all the security and communication that goes on between
this AF Server and your SQL Server
Database, whether it's on this computer or some other computer.
You can think of it like this. The AF Server
is the engine that's handling all the requests,
all the security requirements, you know, when a client
requires information about that
AF structure that's been already defined. Now the structure's
been defined by those AF clients, like PI System Explorer,
or by the other Applications that may be
using our AFS Decay, to create that structure.
The structure's stored in SQL Server,
plain vanilla Microsoft SQL Server, but it's
the AF Server that's handling all
that communication, all the security requirements, etc.
Now, there's a big gap in what we've discussed so
far. Okay, so we've got a client that's making requests
to get data, or to, to navigate to
specific nodes within that Tree
Structure that we just discussed. Where's PI come into
all this? When, when do we actually see some PI Data? As you can
see, the PI Servers are represented down here.
Well, as I mentioned earlier, when a user finally
gets to the part of the system he's navigating to,
either using this Tree Structure or using
one of the search mechanisms we have available in
ProcessBook and our other clients that are AF aware,
when he get to that data, that's,
that's the point, and that's the only point
at which there's really a need
to get to the PI System. So, as a user
is traversing through this Tree Structure, he's really just
dealing with this AFS Decay,
the AF Server, and SQL Server. It's only when he
starts, you know, grabbing those PI Tags
that the PI gets involved
at all. Once he gets those PI Tags and starts
retrieving their Attributes, etc., and their
data, that's when PI gets involved. Now,
I don't want to leave out the fact that the destination
of a user who's traversing through this Tree Structure
to find data, that destination may actually be
data that comes from some other data source, so
it can be some Non Time Series Data Source like a Relational
Database, or a Manufacturing Execution System,
or some other, you know, some other
Relational Database type data.
Okay, well, this was an illustration in which we have both the
AF Server and SQL Server running on the same computer.
Let's take a look at a structure in which we
have the AF Server on a different computer
than the SQL Server Database. It's not
very different here. All you're really noticing is that this
copy of SQL Server is on a different machine.
This can be, you know, in the same room or it can
be half a continent away. All we need is
access to some copy of SQL Server because that
SQL Server serves as the repository. That's
what this little disc icon means. It's a repository
for the things that are being
organized within AF.
So all those structures that are defined, all the relationships
being defined between the different elements in AF,
that information's stored in SQL Server.
Now technically it's actually possible to put
all of this on one computer: the PI System,
the AF Server and the copy of SQL Server.
We don't recommend that for anybody that has more than,
say hundreds of Elements in AF, maybe
up to a thousand. But there is no, other than
the resource constraint, there's really no problem with
organizing all of this onto one computer.
So, what types of things does this design allow
us to do? Well, one of the things that happens is that
these AF Clients here you will notice when
they connect to this AF Server, they're not
connecting to PI at that point. They're just connecting
to this AF Server. The communication between
this AF Client here, like PI System Explorer
or ProcessBook, the communication between that and your AF
Server is all handled through Windows Communication
Foundation, so this is actually a Windows Username and Password
you're going to be prompted for when you connect to this AF
Server. Also, you'll notice the
AF Server, it handles all of the
communication with SQL Server, so this AF
Client it does not need credentials to
connect to the SQL Server. All that's being handled by the
AF Server. We just need to connect to that. The AF Server
does all the communication with this copy of SQL Server.
Another thing is is you'll notice that
these AF Clients can connect to more than one
AF Server at a time. I'd like to demonstrate this
right now. I've actually got two AF Servers available
to me in my current network. If
I look at this Database Option here under PI
System Explorer, you'll see that I currently
am connected to that Server right there. That is a
Server called, it's NICKGX280.
It is an AF Server. Did you notice the bullet,
err, the balloon help there. It showed that I was connected
as my Windows User.
No, I can't show you that now. Let's see if I can show you that again.
, see it says connected as OSI-NICK.
That is, those are Windows credentials. Those have nothing
to do with PI. So I'm connected with this Client to
AF using Windows credentials. Now,
as you can see, there is a 2nd defined Server,
an AF Server. If I didn't know where that is
I could go ahead and, and actually create that
by adding a new System and then typing the name of my
other Server. I can actually add another Server
but in this case I just want to make the point that here is
a 2nd Server. So, on my first server I
have 3 Tables including this one called Training
Sample. Look at this copy of
AF. This is a different AF Server entirely.
Now, remember the communication that we're going to see
here -- let me go ahead and connect --
the communication we're going to see now between my
AF Client and this AF Server
is a Windows Communication, so
sure enough, I'm being prompted for my Windows Username
and Password.
And look what I have here.
This is a whole different set of
AF Databases. There's Training Sample again, but these,
all these other things are all from a different
AF Database. So, as you can see,
this AF Client can connect to more than one
AF Server at a time. , there we go.
Another interesting
result of the design is that because SQL
Server is really just used as a repository for the
data that is, that is configured in AF,
this copy of SQL Server can host
the information stored by many different AF Servers.
So it's not just one AF Server per SQL Server that's
just going to be creating Tables in SQL Server after all,
so you can hook as many AF Servers to
that copy of SQL Server as are required. Now,
if you're interested in building in redundancy to any
of the components here that's entirely possible.
The AF Servers can make use of Microsoft's
Load Balancing Software, so if you have multiple AF Servers
configured using Microsoft for load balancing
that's perfectly acceptable.
We also support all the different Options
for SQL Server Clustering, SQL Server Mirroring,
SQL Server Replication, also Load Balancing.
So, all the different tricks you know from Load Balancing
in SQL Server you can exploit in this case as well.
You can also, of course, make use of High
Availability to make the PI Servers redundant.
If some of this is still not making any sense, here's a real quick
analogy I'd like to offer. It's an overly-simplistic analogy
and it kind of falls apart in places. But, imagine this. Imagine
for a second, instead of making software for the last
25 years, let's say OSIsoft was in the business
of making something else people like to consume
instead of real-time data. Let's say we were making
food. We were in the restaurant business. We had all
these wonderful restaurants and they were doing great.
Everybody loved it. The problem was it was very difficult
sometimes for people out here to find
what they were really interested in. You know, maybe
it didn't go across from restaurant to another, maybe it was just
difficult. For whatever reason, they couldn't get there.
Well, we took it on ourselves to address
this issue. We said, you know what we need? We need some
kind of a map, something that will allow
people to find this great stuff that they really like.
They just do it easier. But it'll be more than a map.
And sometimes people just want to look for things by category, so we'll
build some kind of a search into this. We'll make it like a GPS
so that people can search for certain types of food.
Okay, we want Mexican food or Chinese food or what have you.
So, we'll make this a very
wonderful index into those things that people want
and, and even into the things that we don't
make. I mean we know that sometimes people go to other restaurants and they don't
necessarily want to get everything from us. And, we'll allow
this map here, this wonderful
super GPS, to find whatever it is
that you want to consume, whether it's
our stuff, whether it's somebody else's stuff.
Now that's what the AF Server is like. It's this wonderful
mechanism the AF Clients can use to find exactly
what you're interested in consuming. So now
what role does SQL Server have to play in this environment?
Well, SQL Server is the repository
where we store all that map information.
So, for example, you know, when I have a list
of addresses, and the types of food that's
served, and all the other things that are associated with that,
what the store hours are, etc., all that needs to be
stored somewhere, so we're storing that in SQL Server.
Now I hate to make it sound like this is just, you know, like a memory
card or something, but we are treating SQL Server like a black
box. The AF Server is handling all
the communication, all the security between the Clients and the
AF Server, and AF Server's also handling all the communications
to this, our storage mechanism.
So we are treating that, or you can treat that like a black
box. You, as the user.
Now to me the greatest value of this analogy
is when you think about the relationship between
this super GPS here, you know, this thing we've
constructed to help you find what you want to
consume -- think of the relationship between that super
GPS and the restaurants themselves.
Is there a relationship there? Well,
this super GPS knows about these restaurants,
but they're a completely separate
entity. The restaurants don't even need to know
that this AF Server is
directing people to this PI Server
to consume. This is really just
about completely separated from this. And that's
why, that explains why, for example, there is
an AF SDK, an AF Software
Development Kit, and a PI SDK, two
separate entirely different development environments
because when it comes down to it, you know the AF
Clients are always talking to the AF Server,
and it's only once that AF Client
has delivered some information about this PI
Server that now the PI SDK has to get
involved. So, to wrap up this analogy,
let's go back to what we're actually doing. No, we haven't been
in the restaurant business for the last 25 years. We've been
in the real-time data business for the last 25 years.
And we think we're the best darn, you know,
manufacturer of Real-Time Data Systems there is.
But, trying to get to that data, well, we'd
like to make it as easy as possible, so what we've done
is we've created this, AF. AF
is a mechanism to make it easier for you,
as a user, to create structures that will
easily allow people to find what they're looking for,
or create categories that will allow
people to search what they're looking for without the navigation
through the Tree Structure. Either way, we just want it
to be easier for people to get to this great stuff
that we've been, you know, serving up, we think, better than anybody else
for years and years. Now, again,
SQL Server, that's where we store all the stuff
that you configure in here on the AF Server.
That gets stored over here. So, that's
my analogy. I hope it might be of some help.