Section 7.1 -- How
Clients Connect to PI. First of all, as a
user, you are going to need simple network access.
So you are going to have to be able to see your PI
Server and the specific port-- 5450 that the
Server uses using TCPIP. So you need a network connection
to your PI Server. You as a user, need to have the right tools
and you need to know how to use them. By tools, we
mean a PI client application like
ProcessBook or DataLink or an interface or something like that.
You need to have enough knowledge to understand your tags.
You may have 100,000 or 200,000 PI
tags on the system, and if you do not really know what you are
looking for... If you do not know any of the tag naming conventions, it's
going to be very difficult for you to make any sense of what you see in PI. So
obviously the more you know about tags, the better. And then finally
you have to be able to pass through PI security. That's
not really saying much. We have not discussed PI security at all.
What do we mean by PI security? Well that is the
topic of the next few slides.
First of all, let's talk about some of the underpinnings.
Some of the low level applications that
actually allow us to connect to the PI Server.
The first of these is the PI and the
PI SDK. The PI API and the PI SDK,
they are defined as you can
see here, as dynamically linked
libraries that represent platforms
on which programmatic access to PI is implemented.
In other words, we have a couple
of different methods, a couple of DLLs
that allow us programmatic
access to the PI Server. And it's
upon these two different sets of DLLs that
we have built all the client applications.
Some of the older stuff uses the PI API.
API stands for application programming
interface. The SDK stands for the
software development kit. It's a much more recent
version. And I guess a good way to
differentiate the two, the API
is more kind of a C-styled function library.
This is a low level set of programming
tools. So we build some of the older clients like ProcessBook
2.0 etc. And most of our current
interface is using this application programming interface.
This C style function library.
Now we have a newer, more recent one called the PI Software
Developer Kit. And it's more object oriented. It's more of
a COM-based object oriented model
where we involve a lot of properties and methods instead of
just functions and returning values etc. But it's
the same type of thing. Both of these are two of the same types of things.
One is just more recent than another. Both
are low level software that we wrote initially
to allow an application to get
access to the PI Server. To both read data from and write
data to that PI Server. Now
as it is described here, a good way to describe the difference
between the two at this point in time, is any
of the older version 2
of the PI client and most of our
current interfaces were built using the API.
The API has its own set of little utilities
and files that you would
have to know about in order to do troubleshooting. And
we will discuss those in just a few minutes. The
SDK is used to build all the system management tools,
which are relatively modern tools. And also all the
client tools, versions 3+. So if you look at ProcessBook
version 3, that's been built using primarily the SDK.
Well that is all I was prepared to say about
this. But I do want to admit one thing.
At some point, some of you may be saying, why in the world
do you have two different ways of doing it? Why did not
you just do it one way and just get rid of these two methods?
It has a lot to do with the history of the software.
Originally we developed everything using
this older methodology, this API based methodology.
And then as we moved forward, we started supporting newer
techniques. And unfortunately as a manager, sometimes
you do have to deal with supporting things that are kind of legacy.