During the installation, we install
a series of services. These services make up all the
subsystems in the PI, PI Server. So,
I can look at these the way I would look at any other set of
services in Windows. And, if I can demonstrate, I will go into
the Start Menu and just choose Run.
Well, there's -- I can choose Run and then services.msc.
Of, if you are
more into the Graphical User Interface, just choose Start
and you may find Services in a couple of different places.
If you go into Administrative Tools, you will find it under Services.
Also, if you go into Control Panel, you will
also find Administrative Tools, and you will find
Services there. So, one way
or another, go ahead and launch Services. I will go ahead and make
this bigger. If you scroll down, you will see the Services
that we just installed. Here are all the different PI
Services or we also call them the PI Subsystems.
Now you will notice that almost all of these are set to Automatic.
I had that choice when I did the install.
And also, almost all of them are currently shut down.
PI Network Manager is running because I have been running
some Local Clients that use that as a
communications mechanism. We will talk more about that later.
But the, the different Subsystems
or the different Services can be seen in the traditional Tools, but
you can also see 'em in the
Tools that we ship with our PI System Management Tools.
And I will demonstrate. I will go ahead and choose Start.
And from within the Start Menu, All Programs,
I will choose PI System. And within PI System, I will choose
PI System Management Tools. Now, when this launches,
what we will see is, this is a
set of System Management Tools that allow us to do
various System Management Tasks, using a Graphical User
Interface. Now, since the PI Server has not been started yet,
if I try to look at the different processes
right now, the PI Services, I will not see anything.
It's just going to come up with a blank because PI Server's not running
at this point. But to recap,
basically the PI System is going to install
a series of services that make up how the
PI System gets it's job done.
I am going to describe now the core subsystems that make up the
PI Server. There -- first of all, there's the Snapshot
Subsystem. This is the subsystem responsible for
looking at current data, handling current data.
Snapshot Data is passed on to the Archive
and the Archive Subsystem takes care of it at that
point, storing it at --to disc. It's also responsible for
retrieving data back off of disc, so if one day
somebody says, I cannot see any data in PI -- well,
chances are you need to go look at the Archive Subsystem.
The Update Manager is a subsystem
for allowing different subsystems do what we call
a sign-up for updates,
being able to keep
apprised of any changes to the other parts of the system like, for example,
somebody creates new Points. The Update Manager will
allow the interfaces to pick that up without
having to stop and start the interfaces. Now, again, we will
talk a lot more about that a little later on. The
Base Subsystem is in control of the Point
Database, creating Points, etc.
The Message Subsystem is simply a message logger.
And PI SQL Subsystem
is our -- I, I suppose the best way
to describe it is to call it an OBDC Driver.
It is a subsystem that allows
the PI Server to
share its data with OBDC-compliant
Client Applications like Relational Database Clients
like Crystal Reports and things like that.
PI is not a Relational Database, but thanks
to the PI SQL Subsystem, it can imitate one.
The Redirector is
what we are using for facilitating
communication between com connectors
and external archives. This would be
third-party historians. We will talk more about that a little
later on. We can also get data from Relational Databases
using com connectors. And then, finally, we have a
Backup Subsystem and a License Subsystem for handling
those two functions. And,
in addition to these we also have -- these subsystems -- we have
Utilities. Of course, any system like PI has Utilities
for doing various system management chores, and we
do as well. We have looked
so far in our discussion is the PI Network Manager Subsystem.
The PI Network Manager is kind of the
master system that allows all the different subsystems to communicate
with each other. So, all of these -- for example,
when the Archive Subsystem
needs to write a message to the Message Log
saying that the Archive has just shifted, it sends that
message to PI Network Manager. PI Network Manager tells
the Message Log that it's supposed to write a message. And that's
how the communication works. It's all doing it through
what you will sometimes hear described
as RPCs or Remote Procedure Calls.
In any event, back to the list of,
of systems.
The Interfaces are those
components that will gather data.
Typically, Interfaces are getting data from live
sources. We do have a couple of exceptions to the rule.
The Random and RampSoak Interface are all just random
number generators, and we use that for training purposes.
Now we do have these Interfaces right here, PI Ping,
Perfmon and PI SNMP. They do not
retrieve data externally so much
as just kind of measure things that are either
internal to the computer or some
local things. For example, the PI Ping Interface
is going to measure the ping rate between
wherever it's currently installed and
external computers. So, it's a good measure of latency,
for example, within your system. Now PI Perfmon
can be used for monitoring the
Windows Counters, the Performance Counters --
things like network usage,
CPU usage, that type of thing,
Network IO. All that can be monitored by Perfmon
and stored in PI Tags. And then, for SNMP devices
like routers or switches or even printers,
anything that publishes its process data
or its, it's information performance data
using the SNMP Protocol, well, the SNMP
Interface can read that. So, these three things, we
call these, well, these are, these are basically demo interfaces
They are not the
full-licensed version, so there are some restrictions
which we will more a little later on. But those are fairly
useful interfaces to have for diagnosing problems
on your local machines.
These Server Applications here
include various things, while not critical to the operation
of PI, still give great value. So, for example, this
is a simple calculation engine. And this
is a recalculator, so that if you change the historical
data, we can recalculate those calculations.
These two subsystems are in support of our Event Tracking
or Batch System, so that we can measure
repeated Events, comparing, for example,
shift to shift or comparing one batch of
product to another batch of product made months or weeks later.
Totalizer System simply does
kind of a post-processing, doing typically
totalizations, but it can also do other things like averages,
standard deviations, etc. We have an Alarm
Subsystem to generate alarms. We have an
SQC Alarm Subsystem for doing statistical quality control
alarms. And we have something called Analysis Framework.
Analysis Framework really is our Asset Database
Tool. And by Asset Database, we mean a,
a mechanism to allow people to find
things in reference to assets,
not necessarily by doing tag searches
using kind of a naming convention. Instead of that,
building an Asset Database and then making the PI Server
more asset-centered than
tag-centered. Again, we will discuss a lot more of that later
on. So, in summary, all these subsystems, these
make up what we call the PI Server.