I would like to get
started with talked about
PINet. What is PINet?
PINet is a
super-set of the PI PI functionality that runs on
OpenVMS. It makes it possible for us to
run interfaces and some
locally developed or third
party applications on a VMS machine. And
have those applications be able to send data to,
or get data from the PI 3 Server.
Why do people do PINet?
One of the main motivations for
doing PINet was to distribute
the collection of data. The
idea being to minimize
the machines
needed to run a distributed PI
System and the pricing and licensing of VMS.
Customers were looking for OSI
to provide a way to use small and medium sized
computers to collect the
data. So we are distributing
the processing load.
In many cases your plan is distributed. So it makes sense
to distribute the data collection the same way.
And in some cases you have got special hardware
requirements from the instrument vendor in order to
collect data for PI. So it allows us to put
the hardware in a dedicated box and avoid problems there.
One of the things that we know
is that redundant hardware does not help
you very often. Redundant hardware is harder
to maintain, it's very expensive
and our technical
support experience suggests that somewhere in the
neighbourhood of 5-7% of data loss situations are solved by
redundant hardware. What we have learned though is that taking the interfaces
off the PI Server and putting them into a separate
box-- for example a PINet node or an API
node-- improves data availability by as much as
80%. In many cases you have got advanced
controllers or other sensitive applications that you'd like to put in a box and
separate or isolate them from the users.
This is another reason for PINet.
An optional component that we will talk about toward the end of
the of the course is PIonPINet
which makes it possible to run PI 2 Server applications
on a PINet node and have the PI 3
Server provide the data to the users of those applications.
Not everything works on an a PIonPINet but lots of
things do such as reports and trends
and unit summaries and so on.
PINet
has event queues. Every
node of PINet has its own event
queue. An event queue is similar to data buffering that you may
be familiar with fro PI 3. But it's a much more
robust function and can
buffer data for longer periods of
time. I would never recommend this as an operating practice
but I have helped customers that for some reason
or another did not notice that there was something wrong with
their network or their PI Server for
periods of time ranging from days, to weeks,
to months, recover their data because of PINet's
very robust event queue.
What are the requirements for PINet?
Platforms.
Need for TCPIP.
PI Server requirement and also a OpenVMS requirement.
PINet runs only
on VAX and Alpha processors running the
OpenVMS Operating System.
So there is not a PINet for Windows.
There is not a PINet for UNIX.
None of the platforms that we run PI 3
on, the Server software, supports
DECNet. So you are going to have to provide a
TCPIP software
network for the PINet node. There are
four vendors making products for
TCPIP for OpenVMS. There is
Digital or Compaq TCPIP
Services-- that used to be called UCX.
There is TCPWare that comes from a company called
Process Software. There is a company
called Process Systems and they formally were
TGV-- Cisco and their product is MultiNet
and that is supported. And AttachMate, formerly
Wollongong has a product called PathWay. So you need to choose one of these.
You can refer to the manual to see which
versions of TCPIP
are going to be your minimum starting point.
The PI 3 Server needs to be
running at least version 3.2 or later.
So PI Server
Versions 3.0, 3.1 did not provide support necessary
to support PINet nodes.
OpenVMS--
OSI has a policy to support the last two major
versions of OpenVMS. At the present time we are actually
quite a bit more generous than that. We
are supporting OpenVMS version
6.1, 6.2, 7.1,
7.2 and later. We do not support
VMS 7.0. Also
Compaq and OSI do not recommend using 7.3 on the
Alpha. On the Alpha the newest Operating
System we are recommending is 7.2-2.
I would like to take a moment to talk about
design changes and
limits. One of the things that you may not be aware of is
every PINet is custom compiled for the PI Server it runs against.
So it's quite likely that
no two PI Servers have PINets with the same
parameter settings. There is something like 140
interfaces for VMS and there are 20 or so
server applications that may or may not be enabled for a PINet node.
Plus there are database specific parameters
that may be unique to a given PINet node.
When you upgrade
from one version of PI to another version of
PI, there may be an opportunity
to change things such as the point
license limit. The VMS platform-- maybe move from VAX to
Alpha. Another thing that I would like you to have some comfort
level with is the cost of memory and disks for running PINet.
One of the things to be aware of is if you change
the license of the PI 3 Server
you are going to need in many
cases to upgrade the PINet node to accommodate that change.
The point database and other structures
which are localized to the PINet
node are hard coded to be
particular sizes
and the point database is one of those things that affects those sizes.
So for example if you have a
10,000 point PI 3 Server and
you increase to 20,000 points, you are going to have to
also upgrade the PINet node so that it has a
database large enough to see all of the tags that
the PI 3 Server is capable of supporting.
Changing from VAX to
Alpha platform change is pretty straight forward.
There is not much on a PINet node that is localized
to that PINet node
in terms of configuration.
The easiest way to move from VAX to
Alpha is to acquire a new Alpha
computer, setup the Operating System with user accounts and other
layer products as needed. Get it connected to the
network. Establish a trust for that machine with the PI 3 Server.
And then install a new copy of
PINet on that machine. There is not really anything that you want to
backup from the PINet on
VAX and move to the PINet for Alpha.
There are about six files and we will talk about those later,
that may be site specific
and may have information that you want to bring forward to the next system.
What I normally do is make listings of those
or list the old and new files on the screen
at the same time and edit the new files.
Memory and disk estimates. One of the things
you can download from OSI's website is a
system design questionnaire.
If you have trouble finding that on our website, use our
search engine. So go to support.osisoft.com and
use the search engine there and
type in, either "memory and disk
estimates" or "design questionnaire" and you will find an Excel spreadsheet that you can
download to help you calculate disk and memory requirements.
[inaudible] for PI 3 gives you formulas
that you can use to estimate disk and
memory. But what I thought I would do is explain the minimum memory
requirements. For VAX, the minimum for PINet
is 16MB. For typically that is
24MB or 32MB,
depending on the size of the databases and so on.
Notice for the Alpha things get to be
much bigger. Part of that is because programs
and data images on the Alpha are so much larger.
So we need a minimum of 96MB
for Alpha. Disk space-- PINet
has a pretty small foot-print
given other applications in the VMS
world. Including the Operating System, the
network and PINet, on a VAX
we need at least 360MB
of disk. More may be required depending on what interfaces you are running and so on.
In many cases the vendor
of the other software that you are working with, for example Honeywell
CM50, will have recommendations for disk and memory requirements.
On the Alpha, we are needing 1GB
of disk space and more may be required
depending on your interfaces and other applications.
Again things on the Alpha tend to be
2.5-4x larger. Also things such as
virtual memory on the Alpha tend to be
very large compared to the requirements for a
VAX-based application.
Before we install PINet
software, what I like to do is talk about the
preparation before the installation begins.
I would like to take a look at some pre-installation
steps. I would like to talk about a new installation
-- there are some things that are different about a new installation of PINet
versus doing an upgrade.
And then like many things, when the
install program finishes, not everything is done yet.
So there are a few I's to dot and T's to cross.
So we are going to take a look at the post-VMS installation steps.
And finally, after we have got our PINet node running,
we will come back and take a look at upgrades. It turns out upgrades are
very similar to new installations.
There are a couple of questions that you do not see during an upgrade.
Generally upgrades take about the same amount of
time than an installation takes. So once we have seen how an installation
works, we will have a good basis on which to understand how
upgrades work.
I would like to review the
requirements for disk
and memory for our PINet node. This is a spreadsheet that I downloaded
from OSI's website-- it's the design questionnaire that I mentioned.
This spreadsheet allows me to
guesstimate my disk and memory requirements.
If you do not already have a PINet node,
and you have got questions about what your disk
and memory requirements are, you can contact either your
OSI sales rep or tech support for help with this.
If you have got a PINet node out there,
the shipping documents for the PINet
software should give you the information necessary to fill in this
spreadsheet.
For our class we are going to be using a PINet node that is licensed for 5000
tags. So I am going to come here to the ultimate number of
tags and ensure that it is set to 5000
as well as the license number of tags.
For some PINet
nodes, we may have built the ultimate number of tags
for a larger parameter than the license number of tags. And in that case
you want to make sure that those are set appropriately.
License number of tags are set to match the license of your PI 3
Server.
The number of real time tags is not
a fill in the blank box, so that one automatically calculates so there is nothing for us to do there.
For archive file size, we set this
to be 2MB. 2MB is a dummy
parameter. Archive file size matters if it's
a PI 2 Server. If it's a PI 3 Server, we just need to put a
dummy parameter there for
calculations and the system to work out.
The number of user accounts. The PINet node normally does not have
user accounts unless it is running our
[inaudible] add-in. So we are going to set the
user accounts, displays and menus to dummy parameters
of 80-80-10 respectively.
The number of digital
states and engineering units needs to be set to
32704-- that's the parameter that we use
for PINet.
Totalization period is set to daily. PI 3 only
knows daily totalization periods.
The number of block processors is a dummy value.
We set that to 500 just so the
calculations and the software hangs together. The
next window is terminal sessions-- I usually leave these as the
defaults which are 2-2 here.
The only time I would think about
changing these if I had
[inaudible] and I would want to make sure that these numbers
are set, so I get good disk and memory estimates based on the number of users
I am going to be supporting.
If I scroll down through my spreadsheet
here, we get a chance to see what the
disk and memory requirements are for the PINet node.
If I am on the VAX, I can see that
I need 16MB of memory;
96MB of memory for the Alpha.
For disk space, it says 300MB here, but
I know from my documentation that I need
360MB as a minimum for versions of
PINet that are current today such as 2.4
On the Alpha, it shows 342MB, but I also know
from my documentation that 1GB is minimum for the Alpha.
Just for comparison purposes, if we look at
PIonPINet this is a
PINet node that has server applications enabled for it.
We can see that the memory requirements are slightly larger on the VAX.
But on the Alpha, it's the same as
the non PIonPINet machine.
Disk space is
larger, about 50% larger to
accommodate the display system.
And for the Alpha, again we are looking at 1GB
of disk space. One of the things I should point out
is that for disk space, OSI is
recommending that you have 20-80% free disk space in
order to accommodate the growth of
configuration and logs and other things that are on the machine.
And we are recommending about 20% free memory
for VAX and Alpha on your PINet
nodes in order to accommodate the growth of the system
and allow adequate space for the
programs to work freely.