PI System Architecture, Planning and Implementation Workbook

PI System Architecture, Planning and
Implementation
Version 2010
PI System Basics
OSIsoft, LLC
777 Davis St., Suite 250
San Leandro, CA 94577 USA
Tel: (01) 510-297-5800
Fax: (01) 510-357-8136
Web: http://learning.osisoft.com
OSIsoft Australia P/L Sydney, Australia
OSIsoft Europe GmbH Frankfurt, Germany
OSIsoft Asia Pte Ltd. Singapore
OSIsoft Canada ULC Montreal & Calgary, Canada
OSIsoft, LLC Representative Office Shanghai, Peoples Republic of China
OSIsoft Japan KK Tokyo, Japan
OSIsoft Mexico S. De R.L. De C.V. Mexico City, Mexico
OSIsoft do Brasil Sistemas Ltda. Sao Paulo, Brazil
OSIsoft France EURL Paris, France
Copyright: 1992-2012 OSIsoft, LLC. All rights reserved.

No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form or by any
means, mechanical, photocopying, recording, or otherwise, without the prior written permission of OSIsoft, LLC.
OSIsoft, the OSIsoft logo and logotype, PI Analytics, PI ProcessBook, PI DataLink, ProcessPoint, PI Asset
Framework (PI AF), IT Monitor, MCN Health Monitor, PI System, PI ActiveView, PI ACE, PI AlarmView, PI
BatchView, PI Data Services, PI Event Frames, PI Manual Logger, PI ProfileView, PI WebParts, ProTRAQ,
RLINK, RtAnalytics, RtBaseline, RtPortal, RtPM, RtReports and RtWebParts are all trademarks of OSIsoft, LLC.
All other trademarks or trade names used herein are the property of their respective owners.
U.S. GOVERNMENT RIGHTS
Use, duplication or disclosure by the U.S. Government is subject to restrictions set forth in the OSIsoft, LLC
license agreement and as provided in DFARS 227.7202, DFARS 252.227-7013, FAR 12.212, FAR 52.227, as
applicable. OSIsoft, LLC.
Page 1
PI System Architecture, Planning and Implementation
Table of Contents
1.
PI System Basics................................................................................................. 9
1.1
Course structure ........................................................................................ 9
1.2
Why PI? (What problem are you trying to solve?)................................... 9
1.3
What is a PI System? ............................................................................... 10
1.4
Assets and PI Points The Basic Building Blocks in the PI System .... 12
1.5
Directed Exercise Assets Defined ........................................................ 13
1.6
Directed Exercise Data Types .............................................................. 15
1.7
Data Flow through the PI Server ............................................................. 16
1.8
Data Flow: From The Source To The PI Archives................................... 18
1.9
Data Flow: Block Diagram From Interface To PI Server ......................... 19
1.10 Data Flow on the Interface Computers.................................................... 20

1.11 Reporting by Exception ........................................................................... 20
1.12 Directed Exercise PI Snapshot Values................................................. 22
1.13 Snapshot .................................................................................................. 24
1.14 Compression............................................................................................ 24
1.15 Cumulative Impact and Defaults ............................................................. 26
2.
PI System Environment Architecture ............................................................... 28

2.1
What is PI? ............................................................................................... 28
2.3
Group Exercise Categorize Your Users ............................................... 30
2.4
Data Sources............................................................................................ 31
2.5
Interface Computers ................................................................................ 31
2.6
Parts is Parts............................................................................................ 32
2.7
Group Exercise Discover the PI System .............................................. 32
2.8
PI Server + AF Server = PI System .......................................................... 34
2.9
Back to the Data - What Do Your Users Require? .................................. 36
2.10 Group Exercise Know Your Users, Their Data..................................... 37

2.11 Combining Different Types Of Data ........................................................ 38
2.12 Directed Activity Viewing Your Data .................................................... 40
2.13 Directed Activity Critical Data .............................................................. 42
2.14 Group Questions...................................................................................... 43
3.
Page 2
PI Server Requirements .................................................................................... 44

3.1
Minimum Operating System .................................................................... 44
3.2
Prerequisite Kits ...................................................................................... 44
3.3
Hardware Sizing ....................................................................................... 46
3.4
Virtualization ............................................................................................ 47
PI System Basics
4.
5.
6.
PI System Planning ........................................................................................... 49

4.1
PI Server High Availability ....................................................................... 49
4.2
Interface Failover ..................................................................................... 49
4.3
Routing Time-Series Data through a Firewall ......................................... 50
4.4
Security Part 1: Planning ......................................................................... 51
4.5
Securing the Environment and the Server.............................................. 52
4.6
Directed Activity Active Directory Roles.............................................. 53
4.7
What about Ports? ................................................................................... 54
4.8
Calculation Options ................................................................................. 55
PI System Combinations................................................................................... 57
5.1
A Simple PI System.................................................................................. 57
5.2
Adding components as needed............................................................... 58
5.3
When You Need To Bet Your Business On PI......................................... 59
5.4
Group Questions Planning and Preparation Stages: Wrap Up ............ 62
Installing the Servers ........................................................................................ 63

6.1
Pre-installation Checks............................................................................ 63
6.2
License File Activation ............................................................................ 64
6.3
PI Server Installation................................................................................ 65
6.4
Gathering.................................................................................................. 66
6.5
Group Exercise - HA Step 1: Planning and Hardware ............................ 67
6.6
Solo / Group Exercise Explore the AF documentation........................ 68
6.7
Solo / Group Exercise Install the PI AF Server .................................... 69
6.8
Solo / Group Exercise Install the PI Server .......................................... 70
6.9
Directed Exercise Explore the PI Server Directory Structure ............. 71
6.10 Solo / Group Exercise - An Exploration of the PI Server Subsystems .. 73

7.
PI System Navigation ........................................................................................ 78

7.1
PI System Navigation basics ................................................................... 78
7.2
Directed Exercise Connect to a PI Server ............................................ 79
7.3
Directed Exercise More PI SMT Plug-ins.............................................. 81
7.4
Time and the PI Server............................................................................. 82
7.5
Directed Activity Viewing Your Data .................................................... 82
7.6
Directed Activity PI ProcessBook ......................................................... 83
7.7
Daylight Savings Time ............................................................................. 84
7.8
Group Recap Questions .......................................................................... 87
7.9
Find Points using Tag Search ................................................................. 88
7.10 Directed Exercise Point Search........................................................... 90
Page 3
7.11 Exercise Data Section in the PI System Management Tools............... 93

7.12 What is the Event Queue? ....................................................................... 94
7.13 Directed Activity Examine the Event Queue ........................................ 95
7.14 PI Archives Defined ................................................................................. 96
7.15 Solo / Group Exercise Manage Archives ........................................... 100
7.16 The AF Link Mechanism. ....................................................................... 101
7.17 Directed Activity Validate the PI AFLink Mechanism ........................ 102
7.18 Common Tuning Parameters................................................................. 103
8.
9.
10.
Understanding the Common Setup of PI Interfaces ...................................... 107

8.1
The Interface Defined............................................................................. 107
8.2
Directed Activity Whats Installed ...................................................... 108
8.3
Interface Installation Considerations .................................................... 109
8.4
Directed Activity Interface Syntax Dissected..................................... 111
Creating and Managing Points ....................................................................... 112

9.1
PI Point Attributes and Interfaces ......................................................... 113
9.2
Point Edits Timing.................................................................................. 114
9.3
Digital State Sets.................................................................................... 114
9.4
Exercise Create a Digital State Set / Point ......................................... 116
9.5
PI Tag Configurator................................................................................ 117
9.6
Exercise PI Tag Configurator ............................................................. 119
9.7
Exercise Create IO Rate Tags (Optional/Time permitted).................. 120
PI Security ....................................................................................................... 122

10.1 The PI Server Conundrum ..................................................................... 123
10.2 PI Firewall ............................................................................................... 124
10.3 The PI License Subsystem .................................................................... 125
10.4 Connection Logic................................................................................... 125
10.5 Granting Access .................................................................................... 127
10.6 Managing PI Users, PI Groups and PI Identities and Mappings........... 128
10.7 PI Trust ................................................................................................... 129
10.8 Working on the PI Server....................................................................... 131
10.9 The Database Security Table................................................................. 131
10.10 The Security Slider ............................................................................. 132
11.
Installing and Configuring an OPC Interface ................................................. 133

11.1 A Word About Polling, Advise and Event Points.................................. 133
11.2 What is OPC? ......................................................................................... 135
11.3 Directed Activity Preparing to Install the OPC Interface ................... 136
Page 4
PI System Basics
11.4 Validating communication between the PI Server and the PI Interface138

11.5 Directed Activity PI OPC Interface Install & Configuration ............... 139
11.6 A Note About Load Balancing a Large Number of PI Tags .................. 141
11.7 PI Interface Configuration Utility ........................................................... 141
11.8 Directed Exercise Explore PI ICU ....................................................... 142
11.9 Exercise OPC Points........................................................................... 146
12.
Buffering .......................................................................................................... 148

12.1 What is PI Buffering? ............................................................................. 148
12.2 Directed Activity The Two Faces of Buffering ................................... 149
12.3 The Buffering Mechanism...................................................................... 150
12.4 Directed Activity Mapping Data in PI Buffering ................................. 151
12.5 Directed Activity Configure Buffering ................................................ 152
12.6 Validating Data Buffering....................................................................... 155
12.7 Solo / Group Exercise The PI Buffer Subsystem ............................... 156
13.
High Availability .............................................................................................. 158

13.1 High Availability Defined ....................................................................... 158
13.2 Directed Activity Components of PI High Availability ....................... 160
13.3 PI Server Replication ............................................................................. 161
13.4 Limitations.............................................................................................. 161
13.5 Directed Activity HA Pre-Installation Concerns................................. 162
13.6 Pre-Installation Concerns ...................................................................... 163
13.7 Group Exercise - HA Step 1: Revisit Planning and Hardware.............. 164
13.8 The Second Interface ............................................................................. 165
13.9 Group Exercise - HA Step 2: Second Interface Machine ...................... 166
13.10 Interface Failover Defined...................................................................... 167
13.11 Group Exercise - HA Step 3: Implement Interface Failover.................. 169
13.12 Collective Manager ................................................................................ 172
13.13 Group Exercise - HA Step 4: Form the Collective................................. 173
13.14 Buffering Mechanisms and Data Replication ....................................... 175
13.15 Group Exercise - HA Step 5: Configure N-Way Buffering .................... 178
13.16 Group Exercise - HA Final Step: The Road Test................................... 181
13.17 Group Recap Question - High Availability Debriefing .......................... 183
14.
High Availability and Complex Architectures ................................................ 184

14.1 Managing Archives on Replicated Servers........................................... 186
14.2 Disconnected Startup ............................................................................ 186
14.3 Changing the Collective Hierarchy ....................................................... 188
Page 5
14.4 Exercise Change the Primary PI Server ............................................. 189

14.5 Untrusted Domain Issues ...................................................................... 190
14.6 Exercise Add a Local User to a Secondary Node .............................. 193
15.
The PI to PI Interface ....................................................................................... 194

15.1 To Push or To Pull ................................................................................. 194
15.2 What Kind of Data Collection? .............................................................. 195
15.3 Identical Data, Identical Points?............................................................ 195
Appendix A Ports ............................................................................................................... 197
Page 6
PI System Basics
How to Use this Workbook

Each Main Heading describes a highlevel valuable learning topic.
Your objectives are skills you can

expect to learn in this segment.
New concepts are presented as

level 2 headings.
Throughout the class you will be

presented with questions and
challenges to help you learn.
The majority of your time will be
spent learning new skills via handson exercises, either in small groups
or on your own.
Icons help you identify themes, like

exercises, tools, tips, or
documentation references.
User manuals, Learning workbooks, and other materials used in class can be downloaded
from http://techsupport.osisoft.com . Login to an OSIsoft technical support account is
required.
Page 7
Software Versions Used in this Document

Described below are the software versions used in this version of the course.
Software
Version
PI Server
2010 SP1 (3.4.385.77)
PI OPC interface
2.3.17.18
SMT
2010 SP1
PI AF Server
2010 R3
ICU
1.4.8
Page 8
PI System Basics
1. PI System Basics
1.1
Course structure
The course consists of instructor lead training with individual student exercises. You will need to be
familiar with your own corporate network topology, and the real-time data environment; including where
the data originates and who can best take advantage of the dissemination of this data. During the course,
you will:
1.2
Sketch the PI System environment topology for your company,
Install and configure a simple PI System,
Modify this system to form a High Availability PI System architecture.
Why PI? (What problem are you trying to solve?)
With the continuing global financial crisis, many businesses have realised there is a need to take better
control of their production processes. Instead of weekly reports rolled up monthly, CEOs are now
requesting timely situation reports so that efficiencies can be introduced to ensure the profitability of the
company. You have been selected for the task of getting the key performance indicators and process data
to the CEO in a timelier manner than is currently the case. Your site will be used as a pilot and, when
proven, your solution will be rolled out across the enterprise. Any solution must address the needs of all
stakeholders - operators, process engineers, maintenance engineers, site management and enterprise
management as efficiently as possible. The current SCADA system operator stations are too expensive
to roll out to non-operations employees.
Before going too much further you must decide exactly what type of data the stakeholders need and just
where it can be found in your organisation. All too often, planning and analysis reports are created with
static and inconsistent sources of information commonly known as silos of information. Data may be
currently locked in spreadsheets or a customized application interface or is on the SCADA system and is
not easily accessible by mere mortals. You need to unlock the source of this data and present it to all,
easily, and in a timely manner.
This course will lead you into an examination of your users data requirements and will examine the
infrastructure required to meet those requirements. You will then install components of the PI system that
will demonstrate the way those pieces interact to provide you with a model for the way to proceed in your
own environment.
Page 9
1.3
What is a PI System?
Objectives
1.3.1
Define the components of a PI System

Draw a diagram of the architecture of a PI System
The PI System Described
The PI System collects, stores, and manages data from your plant or process. You connect
your data sources to one or more PI Interface Nodes. The Interface Nodes get the data from
your data sources and send it to the PI Server. Users get data from the PI Server and display it
with client tools.
These are generally the parts involved in a PI System:
Data is collected from the source by the PI Interface program hosted by the Interface Node.
The data is sent to the PI Server (Asset data can be contained in the PI AF Server). It is read
from the PI/AF Servers by the Client tools.
Page 10
PI System Basics
1.3.2
Architecture of a Typical PI System
Sometimes the architecture can be very simple. Some customers have as few as one or two
interfaces feeding data to a PI Server. Everyone reads that PI Server for their data.
The PI Server = PI Data Archive + PI Asset Framework
In many cases there are many PI Servers in an organization, aggregating data from lower
levels.
Page 11
1.4
Assets and PI Points The Basic Building Blocks in the PI System
Objectives
1.4.1
Define an AF Asset and its components - the element and the element attributes
Define the four attribute types: Static (None), PI Point, Formula, and Table Lookup
Define a Point and the attributes Tag Name, Descriptor, and Point Source.
Define the different data types that can be stored in PI Points
What is an Asset?
The PI Asset Framework (AF) Server is a part of the PI System. It contains asset or
metadata that is usually organized according to the assets containing the points being
monitored. Assets can be helpful to users of the PI System who do not know or are not
familiar with points. Using assets, they can find the data they need without understanding the
technical details of each piece of equipment. Assets are also helpful in finding all of the
points associated with a specific piece of equipment.
Points
Page 12
Assets
PI System Basics
1.5
Directed Exercise Assets Defined

You are invited to watch what the instructor is doing or perform the same
steps at the same time to explore the different concepts presented in this
chapter or section.
Problem Description
Identify the type of objects in the PI AF Server.
There are four types of Attributes, list them here:
Page 13
1.5.1
What is a PI point?
It is a unique storage point for data in the PI Data Archive. It is simply a single point of
measurement. It has been the traditional unit in the PI Server.
1.5.2
So What Types of Data Can PI Store? (Point Types)
The answer is pretty much everything. Below are the valid data types:
Digital
Discrete value (On/Off, Red/Black/Green)
Int16
Integer value, 16 bits (scaled, 0 to 32767, acc: 1/32767)
Int32
Integer value, 32 bits (-2147450880 to 2147483647)
Float16
Scaled Floating Point number, 16 bits (1/32767 times range)
Float32
Floating Point number, 32 bits (single precision); (7/8 Digits);

(Default)
Float64
Floating Point number, 64 bits (double precision)
String
Text value up to 976 characters
Blob
Binary large object up to 976 bytes
Timestamp
Any Time/Date in the range 1-Jan-1970 to 1-Jan-2038
Page 14
PI System Basics
1.6
Directed Exercise Data Types

You are invited to watch what the instructor is doing or perform the same
steps at the same time to explore the different concepts presented in this
chapter or section.
Problem Description
Identify the type of data that might be associated with each of the following:
Example: a Temperature Sensor ___a floating point value___
A switch position:
_____________________________________
A Batch ID:
_____________________________________
Operator comments:
_____________________________________
The results of a calculation:
_____________________________________
Memory available on a server: _____________________________________

Current phase of the reaction:
_____________________________________
Current product count:
_____________________________________
Page 15
1.7
Data Flow through the PI Server
As previously described, data moves from a data source, through an interface, and then into
the PI Server. Client tools are able to view the data from either the PI Server.
The first mechanism to be described is the data flow through the PI Server. This mechanism
is highlighted in the figure below.
Page 16
PI System Basics
The specific functions of each node is noted in the next figure, below.
The data gets passed from node to node on a per tag basis. The value of each specific tag is
taken from its data source. The raw value is assigned a time stamp by the interface and
exception, the first type of filtering, is applied. If the tag value passes exception, it then goes
into the buffer queues.
Under normal operation, that tag value is immediately sent to the PI server where it enters the
snapshot. From the snapshot, compression, the second type of filtering, is applied. If the tag
value passes compression, it then goes into an event queue and then right into the archive for
permanent storage.
The PI User is then able to retrieve either the snapshot value or the archive values for each
tag. A more in-depth look on this data flow, including details on exception and compression
are described later.
Page 17
1.8
Data Flow: From The Source To The PI Archives
In order to determine if you have installed and set everything up correctly (and in the future
to check for proper function), it is essential that you understand the various data structures or
touch points that the data encounters along the way.
This slide is a good illustration:
The PI Server stores data in the form of events. Each event has a value and a timestamp that
indicates what time the value was collected. The PI interfaces collect data from the data
sources and typically use exception reporting, meaning that they pass significant events on to
the PI Server and discard the rest. If the buffering service is configured on the interface node,
then the events go through the buffering service. If the interface node cannot connect to the PI
Server, the buffering service holds the data until the PI Server connection is restored.
Compression
Data
Source
Reporting by
Exception
Event Queue
PI Interface
Buffering
Snapshot
Archives
Page 18
PI System Basics
1.9
Data Flow: Block Diagram From Interface To PI Server
Page 19
1.10 Data Flow on the Interface Computers

As described earlier, the PI Interface has three basic functions:
1.
2.
3.
Collect data
Timestamp the data (or validate that a timestamp is provided by the device)
Apply the Exception Deviation
Applying the exception parameters is referred to as Reporting by Exception.
1.11 Reporting by Exception
The object of exception reporting is to simply reduce noise. In other words, for the interface
to send you the data you are interested in, rather than taxing the network connection by
sending a lot of data that is not meaningful.
Exception reporting uses a simple dead band algorithm to determine whether to send events
to the PI Server. For each point, you can set exception reporting specifications that create the
dead band. The interface ignores values that fall inside the dead band.
The width of the dead band can either be defined by explicitly specifying a number (ExcDev)
or by setting a percentage of the span attribute (ExcDevPercent) of the tag. This is normally
based on what the user considers a significant change.
A maximum elapsed time to run without sending a new value is also specified to be sure the
tags current value updates even if it not encountering a significant change. This is set in the
ExcMax tag attribute.
Page 20
Temperature
PI System Basics
ExMax
ExDev
C
A
ExDev
F
Time
In the preceding illustration, values A, E, and F are reported to the PI Server. Value A is the
last reported value, values B, C, D and E fall within the exception dead band, but value F falls
outside the dead band, so the interface reports value F and the previous value, in this case,
value E.
All Exception Attributes are set on a per tag basis.
Note 1: Some interfaces do not support exception reporting. See the documentation for your interface to
determine whether it supports this capability.
Note 2: ExcMin is by default set to 0. It is very rarely used.
Page 21
1.12 Directed Exercise PI Snapshot Values

You are invited to watch what the instructor is doing or perform the same steps at the
same time to explore the different concepts presented in this chapter or section.
Activity Objectives
Determine which events for a PI interface will make it to the PI Server.
Approach
Consider the following attribute values for a PI tag:
ExcDevPercent: 2
ExcMax: 180
Span: 200
The current snapshot received in the PI Server for this tag is:
Value: 70.3
Timestamp: 10:00:00
Which of the following values collected by the PI interface pass the exception test?
Page 22
PI System Basics
PI Interface Node
Time
Value
10:00:00
70.3
10:01:00
67.1
10:02:00
71.4
10:03:00
70.1
10:04:00
68.2
10:05:00
66.0
10:06:00
65.8
10:07:00
64.2
10:08:00
60.0
10:09:00
63.1
PI Server Node
Snapshot Time
10:00:00
Current Snapshot
70.3
Page 23
1.13 Snapshot
The Snapshot Table is simply the Current or most recent value for each tag in the PI
Server.
The Snapshot subsystem populates this table and also performs the Compression Algorithm
Calculation.
When a new value is received it is compared to the previous value.
If that value indicates that the previous value passes compression then the previous
value is sent on and the new value is retained as the new current value.
If that value indicates that the previous value fails compression then the previous
value is discarded and the new value is retained as the new current value.
1.14 Compression
The point of Compression Testing is to remove extraneous data and keep only what is needed
to reproduce the original data from the data source, within the limits of accuracy required.
The Compression process applies a deviation in a similar manner to exception except that it
takes into account he slope of the trending data.
In the following illustration all the events fall on the same straight line. In a simple case like
this, there is no need to store all the points on the line. If you store just two points, you can
exactly recreate the point value for any other time.
Page 24
PI System Basics
C
E
Temperature
v
De
p
om
v
De
p
m
Co
F
B
A
CompMax
Time
The same principle applies to compressing real-world data. The PI Server uses a sophisticated
compression algorithm to determine which events it needs to keep in order to provide an
accurate data history. The CompDev and CompMax attributes allow you to control the
granularity of the compression algorithm.
All Compression Attributes are set on a per tag basis.
An animation explains the process:
Page 25
1.15 Cumulative Impact and Defaults

There is a cumulative impact of the exception and compression process. This is illustrated in
the slide shown below:
Tip
If you create a tag in the PI Server and do not specify values for
exception and compression, the default values will be used. This should
be avoided because the exception and compression values for each tag
should correctly reflect the desired tag values.
The default values for exception and compression are as follow:

ExcDevPercent = 1 (% of span)
ExcMax = 600 (10 minutes)
CompDevPercent = 2 (% of span)
CompMax = 28800 (8 hours)
Zero = 0
Span = 100
It is not advisable to use the tag defaults for excdev and compdev. If left to the defaults, and if
the tag normally moves through a very small range of values, it is possible to miss significant
changes due to the exception test removing these events. An example might be a frequency
sensor, where a change of 0.2 would be missed because it does not meet the default threshold
of 1 engineering unit (or 1 percent of a span set to 100). An exception value of 0.1 might be
more appropriate (or an adjustment to the span).
It is just as bad to turn exception and compression off, as you will adversely affect the
performance of the system by archiving many more values than are necessary. An example of
this would be a valve scanned every few seconds. With no exception or compression, we
would record the value of OPEN to disk thousands and thousands of times unnecessarily.
While hard disk space is become cheaper, the more limiting factor is the speed of retrieval.
The latency due to spinning of the hard disk and network bandwidth limitations can impede
performance.
Page 26
PI System Basics
As a starting point recommendation for these settings, we recommend setting the

compression deviation (CompDev) to the minimum change measurable by the instrument.
The exception deviation (ExcDev) should be set to half of the compression deviation. It is
important to note that these are only starting point recommendations and you should be sure
to inspect your data for the desired resolution. In some cases, it is advisable to turn off
exception and compression entirely. To do this, set the exception deviation (ExcDev) and the
exception maximum (ExcMax) to 0. You can turn off compression directly, although it is
recommend leaving compression on, by setting the Compressing attribute to 0 (Off). If set
properly, the PI Server will archive values that reflect an accurate change in the device,
without wasting space on duplicating values or losing meaningful values.
Tip
An easy-to-use starting point for exception and compression can be found below:
Span
CompDevPercent
100
0.2
CompDev
100 to 500
0.2
> 500
0.5
ExcDev(percent) = 50% of CompDev(percent)
Page 27
2. PI System Environment Architecture

Objectives
Categorize your users
Describe the PI System components
Compare and contrast the PI Server and the PI AF Server
Explain where each component can fit into your Enterprise
List the pros and cons of the various client tools
In this section, you will investigate your users and the data they require, and develop an
understanding of the IT network topology required to support them.
2.1
What is PI?
At its simplest, PI is a data infrastructure. A simple PI system consists of the data source, the
data collector for that data source (they may be on the same computer), a PI Historian
combined with its Asset Framework server, and an appropriate visualization tool on a PC.
Page 28
PI System Environment Architecture
The PI environment may be expanded to become a system represented below:
However, the PI environment doesnt start with the system it starts with people, and what
they need from their data.
Page 29
2.3
Group Exercise Categorize Your Users

This group activity is designed to maximize learning in a specific topic area. Your
instructor will have instructions, and will coach you if you need assistance during the
activity.
Activity Objectives
Users are a diverse group of individuals with differing requirements from the same set of
data. There are operations managers, engineering managers, CEOs, engineers, chemists,
operators and accountants who all require data from the various databases within the
organisation. These people may exist in different places to each other necessitating a
multiplicity of methods of communicating data around the network.
Approach
Your instructor will ask you to list potential users of PI Data, and where they live in the
Enterprise. Write some answers here:
Page 30
2.4
Data Sources
Data sources can be the any measuring devices generating asset data. They can be almost
anything, and they can connect to the interface data collection computers in a variety of ways.
Examples of data sources are:
Distributed Control Systems (DCSs)
Programmable Logic Controllers (PLCs)
Laboratory information systems (LIMs)
Supervisory Control and Data Acquisition systems (SCADA)
Manual loggers
EPA data loggers
Network devices
Business Information (BI) systems.
To acquire data from these sources it is necessary to utilize a PI interface. The interface may
be simple such as a file reader or complex such as the interface that uses the OPC protocol.
For more information on OPC, see www.opcfoundation.org.
PI Performance Equations, PI ACE, and the Totalizer subsystem (discussed later) are also
considered data sources, even though they may be hosted on the PI Server computer.
2.5
Interface Computers
Interface computers (also known as nodes or data collectors) run one or more PI interfaces. PI
interfaces collect data from the targeted data source and send it to the PI Server. Each
different data source needs a PI interface that can interpret the protocol used by the source.
OSIsoft has over 450 different interfaces. To collect data from a source, the PI System must
be configured appropriately. The interface itself must be configured, as must the points where
the data is going to be stored in the PI Server, i.e. the data point, aka point, or more properly,
the data stream. There is a correspondence between the metadata (attributes) of the point in
the PI Server database and the points attributes in the data source. Matching the two sets of
point attributes is crucial to sustainable and timely data collection by the interface.
Necessary steps in collecting data are:
ensure the network between the data source to the PI server is configured
ensure the data source is working
install and configure the appropriate PI interface
create and configure points as required on the PI server
check that the points are receiving data
This will be covered in detail tomorrow.
Page 31
2.6
Parts is Parts
The PI System is not just one application. It is a collection of many applications that makeup the infrastructure we call the PI System. It is important in your planning phases that you
understand what these parts are and what they do.
2.7
Group Exercise Discover the PI System

activity.
Exercise Objectives
Describe the PI System components
Define the purpose of each component
Problem Description
You need to understand the function of each of the main PI System Application Components.
Approach
From the discussion so far, do your best to answer the name of the product according to each
of their description.
For example:
This graphics package allows users to create dynamic, interactive trends featuring realtime PI data.
Answer: PI ProcessBook
This powerful, easy-to-use spreadsheet add-in is used for gathering, analyzing, and
reporting PI data.
Answer:
Page 32
This web-based application allows users to build and share views of data for reporting and
analysis.
Answer:
This intuitive, web-based tool delivers fast, easy, and secure access to all your PI System
data.
Answer:
This real-time data collection, archiving, and distribution engine powers the PI System.
Answer:
This robust tool lets you define a consistent representation of your assets and provide a
structure for your information.
Answer:
This programmatic, powerful analytic tool allows users to write equations, which are
reusable on similar sets of data, with minimal effort.
Answer:
These applications provide high-speed links to external data sources, providing real-time,
fault-tolerant data to the PI System.
Answer:
Page 33
2.8
PI Server + AF Server = PI System
Why does the PI System have, at its core, two server database applications?
Because of the truth:
Use the right tool for the right job.

We have two servers not only because the PI System is based on access to real-time and
historical data, but also because data is only useful if it is seen in some sort of context.
To understand this better, we will look at the database technologies in our servers.
Note: This information is not required to be memorized in detail, only to provide an explanation of why
we use each technology to store data.
2.8.1
PI AF Server Core Technology
The PI AF Server is based on Microsoft SQL Server, one of the worlds most advanced
relational databases. It is called a relational database because the data is stored in flexible
small pieces (tables) that can be assembled in many ways to give different results.
In a relational database, all data are stored and accessed via relations. Relations that store
data are called "base relations", and in implementations are called "tables". Other relations
do not store data, but are computed by applying relational operations to other relations.
These relations are sometimes called "derived relations". In implementations these are called
"views" or "queries". Derived relations are convenient in that though they may grab
information from several relations, they act as a single relation.
-source: Wikipedia
This type of database is perfect for storing hierarchies and metadata. Data can be indexed in
many ways, and large structures can be stored efficiently. This is why we base our PI Asset
Framework Server on this application.
Page 34
The only problem with a relational database is that it is an awful structure for time series
data.
2.8.2
PI Data Server Core Technology
When the PI Server was first developed, we used our own design for the database because we
wanted the best performance. This design is still the most powerful in the world for time
series data.
Each database table in the PI Server is called an Archive. This archive is broken into 1K
records. Each 1K record at the beginning is associated with the Record Number of each
point. When a user asks for point data, the system translates that into the RecNo and can find
the data start without searching it knows exactly where in the file to start reading. These
are called Primary Records and serve as a natural index.
RecNo
Overflow
Each record contains a pointer to the next record. The records are small so we can pack the
archive efficiently, as some points will fill quickly and some may not change often at all.
When a primary record fills, we write the next record at the end of the archive file and
move backwards. Why? So we can maintain a contiguous Primary Record range.
At a higher level, each archive is a fixed size and therefore contains a finite time span. These
times are stored in an Archive Index.
Start
End
Start
End
Start
End
Start
End
To respond to a data request, the PI Server knows exactly what archive file to jump to, and
exactly where in that file to start reading data.
Page 35
2.8.3
Where Do the Servers Belong in Your Enterprise?
The storage of this data may be disseminated throughout your company.
2.9
Back to the Data - What Do Your Users Require?
Users data is any data associated with the diverse equipment required found in the modern
business environment. This can be data such as the speed of a pump, the serial number of the
pump, the date the pump had its impellor changed, running hours of the pump, or efficiency
of the pump. It can also record the ping time between two computers in corporate network,
the CPU temperature of a server, or the memory requirements of a monitored business
application. Users may also require mill shutdown time, in-stream analysis, shift production
limits, production totals and cost of production to name a few types of data.
This data can be categorised as real-time data, derived (calculated) data or grouped
(relational) data. Because of the differences in the rate of change of data, it is appropriate to
store the data in different ways. Real time data is best stored in a database that allows for fast
storage, fast retrieval and automatic compression such as the PI time series archives. Slow
changing or static data may be better stored in relational databases structures, or the asset
centric elements found in the Asset Framework (AF) database. Calculated data may be stored
in the PI Server, or derived as required in the AF database.
Both the AF and PI servers can store numeric (floating point or integer), text or enumerated
data. Numeric data stored in the PI Server may be compressed to compact the historian and to
facilitate data retrieval. All data stored in the PI Server is kept in archives. When the CEO
requests data, the structure of the archives facilitates the rapid retrieval of data. AF data can
be stored in the associated relational database, derived as required from attributes and
elements or passed through from the PI Server.
Page 36
2.10 Group Exercise Know Your Users, Their Data.

activity.
Activity Objectives
To understand who the users are and what their data requirements may be.
Approach
As a group create a list of the types (e.g. CEO, engineer, operator, IT network engineer, etc.)
of user that will need PI.
For each of these groups produce a list of the types of data they need.
Classify whether this data as real-time or not.
Page 37
2.11 Combining Different Types Of Data

The AF server provides a number of functions that are useful for building applications upon
PI data and other data. The most significant is asset centric and allows users to organise and
structure PI data, as well as other, non-real time data according to objects with which the
users are familiar. These can be physical objects in their production processes like pumps,
transformers, grinding mills, even CPU temperatures. These asset elements are flexible and
allow hierarchical modes. An important aspect of AF asset elements is that their data can
span PI servers, allowing users to organise and search for PI information across multiple PI
servers. The element is a user-oriented object that contains attributes, which reference PI
data, configured data, and data from other, disparate systems. Other features of AF that allow
users to leverage PI data include object-level security, searches, access to data from systems
other than PI, and the ability to scale to 100 million element attributes or more.
The AF also provides an underlying infrastructure for OSIsoft products such as PI
Notifications, PI WebParts, PI OLEDB Enterprise and PI Web Services.
You do not have to configure your entire AF installation at once. Start with a manageable
area, such as a particular type of equipment, or part of a process, and expand the model over
time.
When planning an AF installation, consider the following questions:
How will you map your companys assets to AF elements?
What attributes are required for each element?
Are these attributes PI data, constants, or calculations?
Will you use templates to speed definition of these elements?
How will the asset hierarchy be structured?
Do you need data from other databases as well as real-time (PI) data?
What security is required?
Are alerts (PI Notifications) needed?
PI System Explorer is one tool used to see AF data and connects to one AF database at a
time. In most cases, OSIsoft recommends the use of one PI AF database for your entire asset
framework. However, depending on your application, you may need multiple databases:
Within a single company, different departments may prefer to have their own unique
databases to handle their needs.
A company with a database that handles current operations may have a second
database for staging purposes. Modifications to be implemented in the future are
made and tested on a staging database before transferring the structure to the
operational database.
AF requires Microsoft SQL Server and that there is a SQL Server instance available at the
time of installation. AF supports SQL Server Express editions, which can be installed on a
shared computer, together with AF and/or PI Server software. SQL Express comes with a free
license, but scalability limitations make it more suitable for small to medium-size
installations.
Page 38
Please consult the PI Server Installation and Upgrade Guide for details.
AF 2010 is a required component of PI Server 2010, and must be installed and available prior to the PI
Server installation. The PI Server automatically installs AF Client binaries but the PI Server 2010 setup
kit does not include AF Server.
Page 39
2.12 Directed Activity Viewing Your Data

In this part of the class, you will perform a learning activity to explore the different
concepts presented in this chapter or section. You may be invited to watch what the
instructor is doing or perform the same steps at the same time. Your instructor will
have directions.
Activity Objectives
Discover the best ways to view data under different circumstances.
Approach
Discuss with the instructor, the pros and cons of the 4 major client tools.
Use the table on the next page to record your ideas:
Page 40
Pros
Cons
Page 41
2.13 Directed Activity Critical Data

have directions.
Activity Objectives
To understand the places data can be stored in the PI System environment.
Approach
Previously you listed types of data real-time and otherwise. Decide where this data will be stored and
why. How big a part will AF play in your environment?
The instructor will facilitate the discussion.
Page 42
2.14 Group Questions

The following questions are intended to reinforce key information, or to discover a
new insight.
Questions
1.
What is the difference between a PI System and a PI Server?
2.
What is the difference between a smart client and thin client?
Page 43
3. PI Server Requirements
Objectives:
Describe the Prerequisite Kits
Define the hardware requirements of the PI Server
Define the hardware requirements of the PI AF Server
Describe the virtualization support for the PI System
List the steps required to obtain the PI Server license file
3.1
Minimum Operating System
PI Server 2010 runs on the following versions of Microsoft Windows.
64-bit (recommended for production environments):

o Windows Server 2008 R2
o Windows Server 2008 SP2
o Windows Server 2003 SP2 or later
32-bit:
o Windows Server 2008 SP2
o Windows Server 2003 SP2 or later
PI Server 2010 is supported on both the Full and Server Core installations of Windows Server 2008 64bit, Windows Server 2008, and Windows Server 2008 R2.
Note: While Microsoft client operating systems such as Windows XP and Microsoft Windows 7 may be
employed to test and evaluate PI Server, OSIsoft does not support these operating systems for production
environments.
Most companies have some form of Standard Operating Environment (SOE) that is applied to
a computer as the operating system is installed. Be aware that the SOE may interfere with the
installation of PI. If this occurs, install a standard windows system, then apply the SOE post
PI install, testing as you go.
3.2
Prerequisite Kits
OSIsoft has removed Microsoft Windows redistributables from the OSIsoft installation kits in
order to reduce installation kit size, and eliminate download of distributed files common
across setup kits. OSIsoft products verify that the minimum operating system components are
Page 44
PI Server Requirements
installed; however if the requirements are missing from the operating system, the setup kit
will no longer automatically install the missing components. The Microsoft operating system
requirements are available as separate Prerequisite Kits.
There are different prerequisite install kits available for download and only one should be used for
installation depending on the environment and preference:
Online: For installation on a computer connected to the internet. This kit connects to
Microsoft sites in order to download .NET Framework 3.5 for the operating system
on which it is run. This is a bootstrapper kit that is much smaller than the Standalone
kit.
Standalone (Recommended): For installation on a computer that cannot connect to

Microsoft sites, or if such connection is not desirable. This is a full redistributable kit
that is much larger than the Online kit.
Legacy: This kit should only be used for installation on older operating systems
where the OSIsoft products do not require .NET Framework 3.5.
Page 45
3.3
Hardware Sizing
Included in the files distributed with the course is the Hardware and Systems Sizing
Recommendations Spreadsheet, also downloadable from the OSIsoft Technical Support web
site.
The amount of disk space required depends primarily on the number of PI points that the PI
system will collect. below to calculate the necessary disk space.
PI Server Component
Space Requirement
Notes
PI Server 2010 and PI Software

Development Kit (PI SDK)
160 MB
100 MB temporary disk space for
installation
PI SDK includes the PI API.
PI Server databases
11 MB per 1000 points + 1 MB
Located on the same computer as the

PI Server.
Message log files
10 MB
Located on the same computer as PI

Server, in the pi\log directory.
PI Archive files
10 MB per 1000 points
PI event queue
5 MB per 1000 points
OSIsoft recommends that you place the

event queue on a different physical
drive from the PI archive files.
Rollback backup (upgrade only)
Size of PI Server databases +

primary archive
The PI Server setup program performs

a minimal backup during the upgrade.
For PI Server, PI AF server, and Microsoft SQL Server, one or more Microsoft Windows compatible
computers, preferably with a 64-bit operating system is required. It is possible to install a 32-bit version
of Windows on a 64-bit computer. However, the computer would not have the benefits of 64-bit Windows
operating systems, such as more than 2GB of RAM per process.
For best performance and improved security, OSIsoft recommends that you install SQL
Server on a different computer from PI Server.
OSIsoft recommends at least two physical drives on the PI Server computer.
The PI AF server and PI Server must be installed on different computers if:
PI AF server will use time-series data from multiple PI Servers or PI AF collectives (a

distributed system).
PI AF server is configured for high availability (such as a PI AF collective, load balanced
PI AF servers, PI AF servers connected to a mirrored SQL Server, or PI AF servers
connected to clustered SQL Servers).
The number of required computers depends on the size and complexity of the PI System. The size of a PI
System depends on the number of PI points and the number of units (elements) of equipment (such as
mixers, tanks, or meters or whatever else you have added into the asset database).
A simple, small system will have the PI Server, the PI AF Server and SQL Server (the free SQL Server
Express may be used) installed on the same hardware (or virtualised) server, as shown below.
Page 46
PI Server Requirements
For distributed systems with large workloads and point counts, and with multiple PI Servers or PI Server
collectives that link to a central AF database, OSIsoft recommends that you install PI Server collectives,
PI AF collectives, and Microsoft SQL Server on separate, redundant computers to achieve the best level
of performance and scalability. This type of system is depicted below.
3.4
Virtualization
OSIsoft supports the virtualisation of the PI System on the virtualization platforms of Microsoft Hyper-V
and VMWare ESX Server. A PI System that is sized using the PI Server Installation and Upgrade
Guide and Hardware and System Sizing Recommendations Spreadsheet will operate on a virtualized
platform when using the recommended configurations.
In addition to the recommended architectures, there are five core principles that should be noted when
implementing the PI System on a virtualized platform.
Page 47
Principle 1 A Virtual Machine is just another brand of machine.

Principle 2 Enterprise solutions must use enterprise class virtualization and hardware.
Principle 3 Do not mix virtual and physical implementations on the same host.
Principle 4 Ensure qualified support of the virtual environment.
Principle 5 Thorough testing of the PI System on both physical and virtual platforms, using a custom
configuration should be undertaken.
For more information see Virtualization and the PI System 1.2.
Page 48
PI System Planning
4. PI System Planning
Objectives:
Discuss Highly Available Systems
How to get through firewalls
Understand your calculation options
To ensure the integrity of your PI environment steps must be taken to implement backups, redundancy
and high availability of the all components.
4.1
PI Server High Availability
PI Server High Availability (HA) enhances the reliability of the PI Server by providing
alternate sources of the same time-series data for users. PI Server Replication enables
alternate data sources by synchronizing the configuration of multiple servers. This allows
interfaces to buffer data to multiple servers with the same point configuration. PI clients can
retrieve data from any of the servers without changing data references. Depending on the
pace of the course, you will be implementing a highly available architecture on Day 3 or Day
4.
Please consult the PI Server Installation and Upgrade Guide for details.
4.2
Interface Failover
PI Interfaces based on standard interface template (UniInt) can potentially support interface
failover. Depending on the data source, an interface can automatically switch between
redundant copies of the interface run on separate interface computers. This provides
uninterrupted collection of process data even when one of the interfaces is unable to collect
data for any reason. When maintenance, hardware failure, or network failure causes one
interface to become unavailable, the redundant interface automatically starts collecting and
buffering data to send to the PI Server.
UniInt interfaces can also restart without a connection to the PI Server. As the interface runs,
it receives updates to the list of points and their parameters and writes the information
including the point scan listto a local disk file. Subsequent starts of the interface can use
the local copy of the point information to start up without a connection to the PI Server.
Each interface manual has comprehensive details of how to implement interface failover.
Page 49
4.3
Routing Time-Series Data through a Firewall
A firewall that isolates the PI Servers on a protected LAN from a large number of users on a
widely available LAN may be deemed necessary. You may employ a primary PI Server on
the protected LAN inside the firewall and a secondary server(s) with a large group of users
outside the firewall on the widely available LAN. The client workstations on the widely
available LAN are configured to connect only to the PI Server(s) on the widely available
LAN. Any client workstations on the protected LAN are configured to connect to the PI
Servers on the protected LAN, and could be configured to connect to the PI Servers on the
widely available LAN as well. The primary PI Server receives all configuration changes. The
interfaces receive configuration information from the primary PI Server. The interfaces send
time-series data to the PI Servers on the protected LAN via n-way buffering. One or more PI
to PI interfaces running on the protected LAN may forward time-series data from the primary
server to the PI Servers on the widely available LAN. This reduces the diversity of traffic and
number of data sources that would flow through the firewall from the protected LAN to the
widely available LAN if n-way buffering sent time-series data to all of the secondary PI
Servers.
The PItoPI interface copies point data from one PI server to another. Data is moved in one
direction, meaning data is copied from the source to the receiving PI server.
Page 50
PI System Planning
4.4
Security Part 1: Planning
Objectives
Introduce PI security
Understand how network and environment affect PI Security.
Discuss Mappings
Discuss the applicability of Trusts
4.4.1
What is Security?
Computer security has two parts:
Authentication
Authorization
Who is the user, and how do we confirm that the

user is really whom he or she says?
What is that user allowed to do?
Security is always a balance.
You want to use what is most secure, easy to configure, and provide for minimal
Maintenance. That is why we suggest using Windows Active Directory security. Its
something that you probably have now in your domains, and can easily accommodate the PI
System. We call this Windows Integrated Security.
In order to connect to the AF database OSIsoft recommends that you use Windows
authentication because it is more secure than SQL Server authentication. Objects and their
effective permissions are based on the Windows user identity. The permission sets for all
users are stored as Windows security descriptors associated with certain types of objects and
collections within AF.
Page 51
4.5
Securing the Environment and the Server
PI is consistent with, and best supported by, implementation in a corporate network secured computing
environment. This usually includes:
Domain security for users, directories, and applications

Router security including router based firewalls
Antivirus programs and regular operating system patches
Controlled access by remote parties
Fixed IP addresses are usually applied to interface computers and server computers, while DHCP IP
addresses is the norm for user clients. Although PI is usually implemented in domains and all data
communications to PI are through TCP/IP response packets, PI can be implemented without joining the
domain since, file access to the PI Server from any remote computer is unnecessary. PIs lookup server
name can be entered into the Domain Name Server associated with its fixed IP address. PI can stand
alone, sharing no files and inaccessible by anyone except the local computer administrator and users. This
access can be provided by remote terminal client services.
Install the server in a secured area with a locked door, uninterruptible power supply and air conditioning.
Have unique passwords for both the local administrator and the piadmin PI user. Have a screen saver,
which locks out idle sessions and requires password re-entry. Do not use the PI Server computer to access
the Internet via a browser. Instead, download the required files on another computer and transfer them by
flash drive or other media. Do not put client software (Microsoft Office, PI ProcessBook, etc.) on your
server. This will encourage the servers use as a client.
Page 52
PI System Planning
4.6
Directed Activity Active Directory Roles

have directions.
Activity Objectives
Create your roles you might find useful.
Approach
Spend two minutes listing the benefits of a good security model using Windows Integrated
Security and Active Directory:
List the roles you would find useful in your organization.
Tip
You should take this list to your IT Department a good deal of time
before an installation of the PI System in order for you to take advantage
of the best security from Day One.
Page 53
4.7
What about Ports?
You cannot discuss security without talking about network ports. A complete list of ports
that may need configuring can be found in Appendix A.
A common misconception is that port 5450 should be opened bi-directionally. Ideally, a
firewall has holes only in the server-bound direction; in the opposite direction, nothing is
allowed to pass except return connections on ephemeral ports. The return connection is on an
arbitrarily selected ephemeral, or temporary, port.
See http://en.wikipedia.org/wiki/Ephemeral_port
The default ephemeral port range for Windows is 1024-5000. The old school way to do this
is to leave the entire range open for the return connection, but in the 21st century this is
normally handled automatically by the firewall. Many firewall software packages just do it
whether you want it or not, but others have configuration were the automatic reversedirection port opening is called keeping state or a stateful firewall, and may be optional.
Note: There is a list of the Ports the PI System uses in Appendix A.
Page 54
PI System Planning
4.8
Calculation Options
There are varied options for performing calculations in the PI environment.

4.8.1
ACE
The PI Advanced Computing Engine (ACE) allows programming of complex calculations (for example,
heat and material balances, data reconciliation, and real-time cost accounting); communication
applications (for example, alarming, emailing, and paging); data transfer programs; and any other
application that does not require user intervention. ACE provides a fault-tolerant and redundant
architecture to ensure these real time calculations.
Please consult the PI ACE 2010 User Guide for Visual Basic .Net for
details.
4.8.2
Performance Equations
The Performance Equation (PE) Subsystem provides an equation syntax and library of built-in functions
that allow you to perform a wide variety of calculations on the data stored in PI points. Each PE is
associated with a PI point, and the calculation results are stored in the PI Archive as a PE point. You can
configure a PE point to be evaluated periodically by the Performance Equation Scheduler on a time-based
basis; or when an event is received on a specified trigger point, called event-based scheduling. For those
people interested in Steam Functions there is also an applicable section in the manual mentioned below.
Please consult the PI Performance Equations Syntax and Functions

Reference section in the PI Server Applications User Guide for details.
4.8.3
Totalizer
The PI Totalizer Subsystem performs common calculations such as totals, averages, minimum and
maximum values, standard deviations, and counting. Output of a calculation is stored in a PI point. The
main difference between a Performance Equations point and a Totalizer point calculating the same
summary is that Totalizer calculates based on Snapshot events while the Performance Equation Scheduler
calculates based on Archive events; consequently Totalizer points may have more accurate results.
Page 55
Please consult the PI Totalizer Subsystem section in the PI Server

Applications User Guide for details.
4.8.4
AF Calculations
As indicated previously the Asset Framework can be used for asset-based calculations. In the
AF Help file is a list of Data Reference Functions that can be utilised. The calculations can be
one formula or a sequence of calculations and can have many input attributes. Calculations
may be derived that use PI point data, and both internal and external table data, as well as
static attribute data.
For more information see the PI System Explorer section of

%PIHOME%\pipc\help\AF.chm, or type calculation in the Search tab.
You should review the PI Server Applications User Guide for material on PI Real-Time SQC
and the PI Alarm Subsystem.
Page 56
PI System Combinations
5. PI System Combinations
Further information on complex systems.
Objectives
Reiterate the components of a small PI system
Develop complex PI environments
5.1
A Simple PI System
In addition to the users PCs, the simplest recommended PI System consists of just two
computers:
a computer for the AF and PI Servers,
a computer to run the PI interface collecting the real time data
CEOs desk
PI Interface
with data
source
AF Server
with PI
Server
Above, the PI interface is running as a service on the same computer as the source of the data.
As the data is collected, it is transferred in a timely manner to the PI Server. The users then
request data from the AF and/or PI Server as required. Tools such as ProcessBook, PI
WebParts or Coresight will sign up for updates so that any new data arriving at the PI server
is displayed on the client as it is received. There is no need for manual refreshing of the
displays.
Page 57
5.2
Adding components as needed
As the needs of the PI environment grow, multiple components are added to expand the
capabilities of the systems. If the AF server becomes a bottleneck for the system because of
its extensive size, the AF server may be moved to a separate server. When sophisticated
calculations (requiring programming) become necessary, an Advanced Calculation Engine
(ACE) can be added to the existing server or may be located on a separate server. This may
result in a PI system configuration as shown below. The arrows indicate the direction of data
flow.
PI ACE
PI Server
PI Interface
with data
source
Page 58
CEO
AF Server
5.3
When You Need To Bet Your Business On PI
There may come a time when the PI environment is vital to the running of the company. At
such a time, it may be necessary to evaluate a Highly Available PI system. The PI System
includes features that facilitate making data highly available. These include the ability to
conduct online backups, compatibility with Microsoft Clustering technology; the distributed
nature of data collection within the PI System, and the availability of fault-tolerant third-party
solutions that provide redundant hardware solutions. The PI environment has been designed
to provide fault tolerance via server replication and interface failover.
5.3.1
PI Server Replication
The PI High Availability (HA) design provides for multiple PI Servers, each acting as an
independent storage for the time series data. These PI Servers function as a unit called a
collective. A collective has two types of servers:
Primary - the main server in a collective where configuration changes are made.
Secondary - the remaining servers in a collective. These servers automatically adopt

configuration changes made on the primary, but receive data from the data source
individually via a technique called n-way buffering that will be explained later.
5.3.2
PI AF Collective
A PI AF collective is a set of PI AF servers that acts as the logical PI AF server in a PI System to provide
high availability (HA), disaster recovery, load distribution, and increased scalability.
The high availability (HA) feature, implemented with PI AF, uses a PI AF collective. The failover and
load balancing logic is implemented at the level of the PI AF SDK. On failure, the PI AF SDK will select
the appropriate PI AF server, and switch to the next appropriate PI AF server.
Each PI AF server / PI AF SQL database pair can be on the same computer or on different computers.
Each PI AF server must know its server role (primary or secondary), each primary server must know
where the secondary servers are located to allow for replication, and each secondary server must know
where the primary server is located in order to send its status to the primary. SQL Server replication
enables the secondary database server(s) to contact the primary database server and replicate metadata
and data.
Please consult the PI AF 2010 R3 Overview Guide for details.
Page 59
5.3.3
Interface Buffering and Failover
The interface buffering service writes time-series data directly to all members of the
collective, buffering data temporarily for those unable to receive data for a period. This
mechanism assures that time-series data stored in each current archive is an exact duplicate of
the other current archives in the collective. Many interfaces incorporate failover mechanisms
that allow for redundant data collectors. If one copy of the interface shuts down then another
will take over the data collection. On day 2 you will be exploring interface buffering, and on
day 3 you will explore implementing interface failover.
5.3.4
Clients
PI clients (for example, PI ProcessBook, PI DataLink) can automatically switch from the
primary PI Server to any of the replicated servers in the event connection to the primary is
unavailable, assuring that all clients always have read-access to PI data.
5.3.5
Other Components
The remaining major components in the PI environment such as PI ACE, PI WebParts, PI

OPC Server, and PI AF are all capable of redundancy or replication. By adding the necessary
components to satisfy the users requirements for redundancy and replication you may end up
with a PI environment as shown below.
Process Control Network

Primary
PI AF Server
ACE
Secondary
PI AF Server
Primary
PI Server
Secondary
PI Server
ACE
Interface
Interface
SharePoint with PI WebParts
data source
Page 60
In addition to the complex scenario presented above, it is possible to combine data from
widely distributed PI sites to a corporate PI System. This allows corporate access to
designated data on the distributed site PI collectives without interfering with the site servers.
The PItoPI interface allows the rollup of this data by copying data from one server and
making it available on another server. When a corporate PI server is connected via the PItoPI
interface to remote site PI Servers, then required site data (such as KPIs) can be presented
(with history) at the corporate level. Dissemination of selected data from the remote sites via
the corporate PI system to the corporate users becomes possible.
5.3.6
Various Historical Options
Please take a few moments to review Fault Tolerant Platforms for Manufacturing Applications (filename
\DVD\Documentation\2001-038M&E.pdf). This paper was published by the ARC Advisory
Group in September 2001. The ARC Advisory Group is a leading research and advisory firm for
automation technology in industry, infrastructure and enterprise solutions.
The file can be found in the training materials or obtained from the ARC Advisory Group.
Page 61
5.4
Group Questions Planning and Preparation Stages: Wrap Up

new insight. Your instructor may choose to have you try to answer the questions on
your own or have the group answer them together out loud.
Questions
1.
What software platforms are supported?
2.
List the PI software components that make up the PI System 2010 server.
3.
When do you use 64bit vs. 32bit kits?
4.
What method of visualization is NOT recommended?
5.
When would you install the PI Server and PI AF Server on different computers?
Page 62
Installing the Servers
6. Installing the Servers

Objectives
6.1
Review pre-installation check list

Describe the steps to obtain a License File
Know the steps for installation the PI/AF servers
Identify the directory structure of PI
Start and stop the PI Server
Pre-installation Checks
It is critical that you perform the pre-installation checks. In some cases you will get an error,
and in others the installation will stop.
Log on as Administrator (or with administrative privileges). The installer must be

either the administrator or member of the local administrators group. In addition, the
account must have write permission on the AF server. Validate that the user has the
correct permissions.
Always check the PI Server operating system clock when installing any PI Server.
Ensure the clock on each machine has the correct time and it is in the correct time
zone. In your work environment, all clocks should be synchronised from a network
time source. Changing the clock after installation will cause problems.
Update Windows. A properly updated Windows Operating System will have the
prerequisites. If you require any prerequisite applications, you will need to install
them before the installation proceeds. The appropriate OSI pre-requisites file must be
installed on the computer before the AF server is installed
Install Microsoft SQL Server. The version you use is up to you. You now should
know the pros and cons of each.
Obtain your PI Server License File. You get this from the tech support site.
Page 63
6.2
License File Activation
A license activation file must be generated before the PI Server is installed. The OSIsoft Technical
Support Web site provides an online tool called My License Activations (MLA) that allows you to
generate your site-specific PI Server license activation file. This license file controls which applications
can run on the PI Server and displays running parameters, such as the point count limit.
1 Download
Generator Utility
3
Upload MSF
4 License File
Download
2 - Machine Signature
File (MSF) generated
When the license activation file is generated, view the PI Server Manifest to verify the server details and
then download the Machine Signature File (MSF) Generator Utility to create a signature file that
identifies some characteristics of the computer for licensing purposes.
To generate the Machine Signature File (MSF), you must copy the generator utility (MSFWinGen.exe
or MSCmdGen.exe) to a local disk on the PI Server computer and then run the utility.
If the PI Server is on a virtual machine (VM), run the utility on the VM. If you generate the MSF on the
wrong computer (on your laptop, for example) then the license activation file will match the laptop
Page 64
computer. If you install PI Server on a different computer or VM, the server will not run as expected. The
license file must be present during the installation. It can be on a flash drive, CD, or any media that can be
read by PI Server during installation. The setup program copies the license file to the PI\dat directory
during installation and the original file will no longer be used.
Consult the PI Server License Activation Files section of the PI Server

2010 SP1 Installation and Upgrade Guide for full details.
6.3
PI Server Installation
The OSI prerequisite software needs to be installed first. This conditions the server ready
for installation of the PI software. The SQLexpress software has been installed ready for the
AF Server.
The general steps involved in the PI System installation and configuration are as follows.
You will of course, refer to the various installation and user manuals for the specifics.
Page 65
6.4
Gathering
The following information will be requested during the installation:
Location of the PI server license file ask your instructor.

User, or site, and company name
PI SDK path (default: c:\Program Files\PIPC)
PI server path (default: c:\Program Files\PI)
Data archive path (default: c:\Program Files\PI\dat use
C:\Program Files\PI\ARCHIVES)
Default archive size (see below).
It is important to note that the defaults are rarely used in a typical installation, since most
installations are not on the C drive.
6.4.1
Archive Sizing
Your archives must be sized with at least 2KB for each point in the system, and an archive
size cannot exceed 2 TB. However, if your PI Server will have 5,000 points or less then you
can safely use the default value (currently 256MB).
If you have more than 50,000 points, run the 64-bit PI Server on 64-bit Windows OS and set
the archive size to 4-8 KB x the total number of points, with the following consideration on
memory resources.
You should select a size so that at least 2 archive files can fit in the Windows File System
Cache (FSC). This is because at most times, the PI Server will write to and/or read from the
2-3 most recent archive files. The FSC is capped at approximately 1GB on 32-bit systems,
but can use all of the RAM on 64-bit systems. Therefore, 256MB for 32-bit systems, and
(RAM / 3) for 64-bit is a safe upper limit for archive files.
Tip
Many people size their archives based on a size that is convenient to use
with their desired backup media.
As a rule is thumb your Snapshot Event Queue should be set to half of
the archive size.
Page 66
6.5
Group Exercise - HA Step 1: Planning and Hardware

This solo or group activity is designed to maximize learning in a specific topic area.
Your instructor will have instructions, and will coach you if you need assistance
during the activity.
Exercise Objectives
Understand the computers involved in the Collective.
Problem Description
You need to organise your Collective.
Approach
This exercise makes use of four (4) computers, so you will need to work in pairs. Depending on the size
of the class, the students may be divided into teams. Two (2) computers will be used to establish the PI
Server collective and two (2) computers will be used as the data collector computers. The PI OPC DA
Interface will be configured on two interface computers and an OPC Simulator will be installed on one of
the interface machines.
The AF server used will be the one installed on the same computer as the primary PI Server.
In the table below, please take a few moments to note the computer names for each computer.
Primary:
Secondary:
PI Servers:
Note:For the purposes of this

course the AF will be installed
here.
OPC
Interfaces:
OPC
Simulator:
Page 67
6.6
Solo / Group Exercise Explore the AF documentation

Exercise Objective
To read the AF installation manual in preparation for its installation.
Problem Description
Find the necessary information in order to install PI AF Server.
Approach
The AF manuals are
PI Asset Framework 2010 R3 Installation and Maintenance Guide
PI Asset Framework 2010 R3 Overview Guide
These guides are available in the documentation folder of the supplied files.
One of the guides contains the answers to the following questions. Find the correct guide and
answer the following questions.
1. List the supported SQL Server versions.
2. Can the AF SQL database be created manually?
3. Do end users connect to the SQL Server?
Page 68
6.7
Solo / Group Exercise Install the PI AF Server

Exercise Objectives
Install the PI AF Server
Problem Description
You are ready to begin the PI System installation. You should have validated the
prerequisites and Microsoft SQL Server, gathered the install kits and license file, and done all
of the computer checks (clock, etc.)
Approach
In the installation folder you will find the PI AF Server installation kit. Install the PI AF
Server.
Note: The installation process may install .Net Framework 4 then require a reboot.
You may have to use " Run the PI AF Server Setup Program" in PI AF
2010 R3 Installation Guide.
Make sure the SQL Server is started after installation (some people reboot after running
installation kits as a matter of practice).
Page 69
6.8
Solo / Group Exercise Install the PI Server

Exercise Objectives
Install the PI Server
Problem Description
Your PI AF Server is installed. Its time to install your PI Server.
Approach
In the installation folder, you will find the PI Server installation kit. Install the PI Server.
You may have to use "Install PI Server on a Single Computer" in PI Server

2010 Installation and Upgrade Guide.
Note: The PI Server install is not complete until the PI Server is started for the first time!
Some run-once functions are accomplished on the first start.
If the PI server is not running, start the PI Server using the following batch file:
\PI\adm\pisrvstart.bat
Tip
Page 70
This file calls the script pisrvsitestart.bat, which contains

commands for all of the interfaces and other site-specific applications.
Edit this file to include your interfaces on the PI Server and any other
commands you want to execute on start.
6.9
Directed Exercise Explore the PI Server Directory Structure

have directions.
Activity Objectives
Become familiar with the PI directory structure.
Approach
Examine the directories under \PI, \PIPC x(86) and \PIPC.
ADM - administration tools
BIN - program files
DAT - data files (point DB, etc.)
LOG - message log files
SETUP -additional install kits
1. Where are the start and stop files for the PI Server?
2. Where is the license file?
3. Where is piartool.exe (a most useful command line tool)?
Page 71
Within the PI SDK Installation Paths, there will be many of the following directories in
both the 64-bit directory and the 32-bit directory. Which ones you have specifically will
depend on what is installed on the machine and the license details.
INTERFACES - PI interfaces
DAT - configuration and log files
BIN - PI API program files and tools
ProcessBook, DataLink, etc.
4. What is in the \SMT directory?
The following PI interfaces (data collectors) are installed on the PI Server:

PI Random data simulator interface.
PI Ramp Soak data simulator interface.
PI Performance Monitor interface (basic version is limited to 512 points).
PI SNMP interface (basic version is limited to 32 points).
PI Ping interface (basic version is limited to 32 points).
The last three are not configured.
Page 72
6.10 Solo / Group Exercise - An Exploration of the PI Server Subsystems

instructor will lead you through an explanation of the services, as well as your first
look at SMT.
Exercise Objectives
Become familiar with the PI services.
Problem Description
You want to discover the make-up of the PI Server. Remember, the PI Server is not one
application running, but a concatenation of many applications that all operate in harmony.
Use SMT to check the PI system services.
Approach
Navigate to Start > All Programs > PI System > PI System Management Tools
Then select PI Services as shown above. This will show:
Page 73
Some the subsystems have a red icon. Why?
Tip
An alternative way of checking the subsystems is Start Run.. then

type services.msc and press Enter.
Under normal operation of the PI Server, The PI Shutdown Subsystem should not be started
even if the start-up type is set to automatic. This service automatically starts and stops when
the PI server is launched and when it is shutdown.
What other services installed by default with a manual start-up type and not started?
Page 74
In the space below, describe the function of the subsystems.
You will have to reference "Introduction to the PI Server" in PI Server

2010 Introduction to System Management.
PI Network Manager
PI Message Subsystem
PI License Manager
Page 75
PI Update Manager
PI Base Subsystem
PI Snapshot Subsystem
PI Archive Subsystem
Page 76
PI Backup Subsystem
Page 77
7. PI System Navigation
7.1
PI System Navigation basics
Objectives
7.1.1
Understand how to connect to different PI Servers

Become familiar with the PI SMT console
Understand PI Time Format
Find PI Points using the Tag (Point) Search
View and edit data
Connect to PI and Manage the SDK Known Servers Table
Now that we have confirmed that PI is started, test the connection to the PI Server.
The PI Connection Manager is included in the PI SDK and as such is common to most
applications that connect to a PI Server. It maintains a list of known PI Server(s) with which
the machine can communicate.
Page 78
PI System Navigation
7.2
Directed Exercise Connect to a PI Server

have directions.
Activity Objectives
Show new users a method of connecting to the corporate PI Server.
Approach
Navigate to Start > All Programs > PI System > About PI-SDK
Click on Connections in the PI-SDK branch.
When the dialogue box is invoked, it will display all of the PI Servers that have been
configured in the Known Servers Table (KST). Click in the checkbox next to your PI Server
to connect and validate your connection.
Note: The first time the PI SDK is installed a default PI Server is requested. This is why, even if you have
never configured a PI Server, at least one should appear in your PI Connection Manager.
In this dialogue box you can add and remove connections to PI Servers, change your default
server, or change the PI user you are trying to log in as. To add a PI Server, select Server >
Add Server
Page 79
You will need to know the following when creating a new PI Server connection:
Network Path: either the PI Server IP address or hostname
Confirm: validates the connection at creation time
Connection Type: PI3
Port Number: 5450.
7.2.1
More on PI System Management Tools (PI SMT)
The PI System Management Tools (PI SMT) are a set of Microsoft Windows-based graphical
applications used to manage the PI System from client PCs, and are included with every PI
Server. It is recommended that your download the current version of the tools as they change
regularly and are included with your OSIsoft Software Reliability Program (SRP).
Although most PI SMT plug-ins can be run remotely and will perform these server functions
from any authorized, connected PI client, some PI SMT plug-ins require local access to the
servers registry and some will require an access to the Windows services of the remote PI
Server.
Page 80
7.3
Directed Exercise More PI SMT Plug-ins

have directions.
Activity Objectives
Check the version of the PI Server.

Verify the license file.
View the server logs for the first time.
Approach
Check the version of your PI Server by using the PI Version SMT plug-in. Find the number
of PI Points you are licensed for using the Licensing SMT plug-in. Browse the recent PI
Server message logs using the Message Logs plug-in.
The Message Logs plug-in shows messages written by the PI Server subsystems and
messages specifically written back to the server by PI API and PI SDK applications. Use this
to view start-ups and shutdowns of the whole PI Server and parts of the PI Server, to identify
systems, interfaces, and users connecting to the PI Servers PI Network Manager, security
related messages and other server level activity.
The PI Servers pipc.log includes messages from any PI interfaces running locally on the
PI server machine as well as the PI Server applications. These include messages from the PI
Performance Equation Scheduler, PI Performance Monitor, PI Ping, PI Random Simulator
and PI Ramp Soak Simulator interfaces.
Page 81
7.4
Time and the PI Server
The PI Server stores data in the form of events. Each event has a value and a timestamp that
indicates the collection time of the value.
7.5
Directed Activity Viewing Your Data

You are invited to perform the same steps at the same time. Your instructor will have
directions.
Activity Objectives
Observer current values in SMT
Approach
In SMT, go to the Data Current Values area and show all point values and time stamps.
Page 82
7.6
Directed Activity PI ProcessBook

You are invited to perform the same steps at the same time. Your instructor will have
directions.
Activity Objectives
Install PI ProcessBook
Create a simple trend to examine a tags data
Approach
In the same location that your instructor directed you to earlier, you should find the installation kit for PI
ProcessBook. PI ProcessBook is an easy-to-use graphics package that allows users to create dynamic,
interactive graphical displays featuring real-time PI data. It is often used in control rooms to monitor a
process in real-time.
In this and later activities / exercises we will use PI ProcessBook to examine our tags for proper
function.
During the installation, you may be prompted for the default PI Server. If you install the application on
the PI Server, you will not have to configure security.
After the installation, your instructor will show you how to validate a connection to the PI Server, discuss
PI time and perform a tag search, as discussed in the next few sections. You will create a simple trend
with a Random tag.
Page 83
7.7
Daylight Savings Time
The PI Server stores all values with a time that is converted to UTC
(Universal Coordinated Time), (was Greenwich Mean Time (GMT)).
PI stores timestamps as the number of seconds expired since January 1,
1970 GMT. This means that each day of the year has exactly 24 hours.
Any adjustments for time, such as time zone or Daylight Saving Time
(DST), are made by the local machine clock of the user looking at the
data. Interfaces normally synchronize their timestamps to the server
time basis and then post the time as UTC when stored. Display
sequencing and math operations are performed on the UTC basis. The
displayed time is interpreted by looking at the time zone on the client
or server and re-converting this data time into a local time.
PI servers, interface computers, and client computers should all have their time zones and
times set correctly and synchronized. As the PI clients and PI Server know what time zone
they are in, so data can be viewed in either Server Time or Client Time. This is determined
by a setting in the client tool.
Note: It is important that all of the computers involved in collecting data (PI Server, interface computers,
etc.) have their operating system clocks set correctly.
For most current interfaces, events are sent to the server with UTC timestamps. As a result,
DST and time zone differences are properly considered when storing data on the PI Server. If
the PI interface time is more than ten minutes ahead of the PI Server, the PI Server cannot
handle the time difference and discards the data, as it is considered a future event.
Automatic DST changes will not cause a problem when all computers observe the same rules.
That is, all computers either change their clocks twice a year at the same time or they do not.
Note: Situations where some computers change their clocks when others do not can cause data loss.
The PI Server automatically adjusts data according to daylight

savings time transitions. By default, only the current DST
transitions are known. They are provided by the operating system.
To make sure that past transitions between daylight savings times
are correct, you need to update the localhost.tz file on your
PI Server.
Page 84
To verify that the DST rules, run pidiag -tz in the \PI\adm folder to check the time
zone and DST transitions table of your PI Server. You can also run pidiag -tz -dump
-brief in the \PI\dat folder to list all transition times.
7.7.1
PI Time Syntax
Absolute Time (a specific point in time)

* : (NOW)
t : 00:00:00 on the current day (TODAY)
18-Jun-12 16:00:00
Using the full PI Time format (dd-mmm-yy HH:mm:ss.0000), if the date part is omitted, it
will default to the current day. If the time part is omitted, it will default to midnight. Midnight
is at the start of the day.
Expression
Meaning
13
00:00:00 on the 13th of the current month of the current year
13-Aug-12
00:00:00 on that date
8:
08:00:00 on the current date
25 8
08:00:00 on the 25th of the current month of the current year
21:30:01.02
9:30:01.0200 PM on the current date
Page 85
Common Abbreviations:
Symbol
Meaning
Current time (NOW)
00:00:00 on the current day (TODAY)
00:00:00 on the previous day (YESTERDAY)
Monday, Tuesday, Wednesday,

Thursday, Friday, Saturday, Sunday
00:00:00 on the most recent occurrence of that

day of the week
Relative Time (time is offset from another time)

+ 11h : + 11 hours
Combined Time (using Absolute and Relative Times together)
t + 11h : today + 11 hours
Relative Time Units of Measure
Hours (h)
Minutes (m)
Seconds (s)
Weeks (w)
Days (d)
Years (y)
Months (mo)
There is no default time unit. Only Hour, Minute and Second intervals can use fractions. For
example +2.5h or -0.5m.
For more information on time and PI, see the PI Server 2010 Reference
Guide. For more information on DST, go to techsupport.osisoft.com and
look for Daylight Saving Time under the System Managers Resources
section.
Page 86
7.8
Group Recap Questions

new insight. Your instructor may choose to have you try to answer the questions on
your own or have the group answer them together aloud.
Questions
1. Determine the real dates and times indicated by the PI Times:
a. Wednesday-2d
b. 1 6:
c. y+8h
d. *-30m
2. Express the following times in valid PI combined time:
a. Today at 6:00 AM
b. The 4th of the current month at 16:00
c. 12 hours ago
Page 87
7.9
Find Points using Tag Search
Perhaps the best way to verify that the PI Server is working is to look at data. In order to be
sure that all parts of the server are working correctly we would like to see both current and
historical data. When we installed the PI Server, we opted to install the default points.
The following 10 simulator points were then created during the install.
BA:Active.1, BA:Conc.1, BA:Level.1, BA:Phase.1, BA:Temp.1,
CDEP158, CDM158, CDT158, SINUSOID, SINUSOIDU
We can use these points to test PI and not affect any real data. Look at data from these points
to verify that the server is up and running correctly. First, however, we will need to learn to
find points using the Tag Search tool.
7.9.1
Basic Search
A point search is one of the most common functions that users will perform. Most data that is
displayed in a display, report or web part will come from a PI point.
Most of the point searches will be filtered in one of three ways:

Tag Mask
This is a mask for the point name. If your organization has a convenient naming convention
or you are very familiar with the points in your plant, then you are all set. However, people
unfamiliar with the point nomenclature may not have that luxury. These people will have to
use some other way of finding the required points.
Page 88
Descriptor
Descriptor is not a required point attribute, but it is a most useful attribute for finding the
appropriate points when used. Hopefully a descriptive phrase has been used in the point
descriptor attribute when defining the point. For example, a temperature point might be
named TC365674A.PV but the descriptor might helpfully be Reactor 65 Operating Temp.
The downside to searching by descriptor is that it compares text strings and can be compute
intensive.
Point Source
PointSource can be helpful, but it requires some knowledge of the PI System and how the
interfaces have been set up. Each PI interface will be labelled with a specific point source. So
if you know what PI interface you want data from, but you are not sure what the point names
are, you can bring up a list of all of the points that are associated with that PI interface. You
can find the point source of a specific PI interface by looking at the start up script file (.bat
file) of an interface, in the PI ICU, or in the interfaces section of %OSI in the module
database. This is of more use to the PI System Manager.
7.9.2
Tag Search Strategies
Wildcards can be used in any of the above searches. Use * to replace any number of
characters like in this example using the point mask search criteria:
flow* will return points flow_meter1, flow_meter2 and flow_down_under.
Use ? to replace one character as in this example using the point mask search criteria:
flow_meter? will return points flow_meter1 and flow_meter2, but not flow_down_under.
Note 1: Search criteria are not case sensitive.
Note 2: Search criteria can be combined. E.g., searching with tag mask = flow* and point source = OPC.
Page 89
7.10 Directed Exercise Point Search

have directions.
Activity Objectives
You need to familiarize yourself with the principles of point searching.
Approach
Try some point searches using different criteria (e.g., all point names that begin with BA, all
points with point source of R, etc.).
Use Advanced Search to find any points with the attributes Zero > 0 and Span > 100.
Page 90
7.10.1 Point Attributes / Point Values

All of the information that is required to gather data from
a particular data source is stored within the context of a
PI point by means of point attributes. Certain point
attributes can be used to define data type information
such as integers and floating-point numbers, and other
attributes can be used to store character string
information, such as the name (or tag) of the point. For
example, if a measurement needs to be read from a
particular device in a network, the IP address may be
stored in a point attribute. From the Tag Search window,
you can access all the attributes of a point as well as the
current value by clicking the Pt Attr button.
You can also get the current values of any point by clicking the Pt. Values button. This
brings up a window updated in real time with the current values of the selected points in the
Tag Search windows.
7.10.2 Use PI SMT to View and Edit Data

To look at point data you may use PI SMT. The Data section in the PI SMT console contains
3 plug-ins to view the data from PI points and identify points that are not working properly.
Current Values: displays the snapshot value of multiple points in a real time screen.
Archive Editor: displays and allows you to edit historical data for a point.
Stale and Bad Points: displays points that have not received updates in a specified time
range or are in an error state.
Page 91
The Current Value plug-in allows the system manager to look at the current value for any
points they have access to on any PI Server to which they can connect. The plug-in also
allows the user to choose whether they will have those values updated as new values come in
to the PI Server.
The Stale and Bad Points plug-in allows you to identify points that are not working
properly. You can search for points that have not received any snapshot values for a certain
period of time and points that have a bad snapshot value, such as any states from the System
digital state set (PtCreated, Shutdown, I/O Timeout, Calc Failed, etc.).
Page 92
7.11 Exercise Data Section in the PI System Management Tools

Exercise Objectives
Display the current value for the point CDT158, and the archived values for the last 3
hours.
Problem Description
You want to look at the values for a production point and you have no client tools (PI
ProcessBook or PI DataLink) available on your machine.
Approach
Use the PI SMT data plug-ins section to examine point values. Find the current value for
point CDT158.
Page 93
7.12 What is the Event Queue?

The Snapshot Event Queue is located logically after the Snapshot and before the Archive. It
performs a similar action as a clutch in an automobile, separating the engine and transmission
when they are at odds. In the case of the PI Server, when the Archive is busy or cannot
accept data for any reason, the Snapshot Event Queue preserves that data.
It is analogous to the Buffering mechanism.
Tip
The files created by the PI Buffer Subsystem are the same format, and
can even be moved manually to the PI Server and processed like an
Event Queue.
Under normal operation, the Snapshot Event Queue will contain data at any time but it should
not slowly build. This indicates a problem with the Archives.
There is no tool for viewing the contents of the file, only that there are events present.
The Event Queue is a rolling file, meaning that when one fills another is created. This
behavior repeats until the available drive space is exhausted.
Tip
Page 94
Because it is a buffer, it is a good idea to configure the Event Queue to

reside on a different physical drive than the Archives.
7.13 Directed Activity Examine the Event Queue

have directions.
Activity Objectives
Monitor the Event Queue for problems
Approach
Open PI SMT.
Stop the Archive Subsystem simulating a failure. Observe the changes.
Page 95
7.14 PI Archives Defined

The data tables that the PI System stored data within are called Archives. Archives have
the following characteristics:
They are fixed sized files

The PI Server only writes current values to one file at a time
Each archive has an associated Annotation file
7.14.1 Fixed Files

When you create archives, they are created at a fixed size and the entire file is allocated upon
creation to minimize the potential of fragmentation on disk.
You have the option of creating dynamic archives. Dynamic archives are files that grow as
they are filled. Dynamic Archives should only be used for troubleshooting and
reprocessing of archives.
7.14.2 There is only one Primary Archive

Each archive has a start and an end time. All of the data between those two points in time is
contained in that file. When an archive is initialized the timestamp of the first value sets the
start time. When it is approximately 98% full, a new file is initialised (in case some data
comes in late). Therefore, the archives are separated by time seams. These seams are
transparent to the user.
Tip
The Primary Archive should always live on the PI Server. Older full
archive files are used less frequently and can be migrated to a storage
device.
The process of initializing a new primary archive is called shifting.

The next primary archive is determined by:
If automatic archive creation is enabled, the PI Server will create a new PI archive and use it as the
new primary archive.
When automatic archive creation is disabled:
If it exists, an empty archive will be selected to be the new primary.
If no empty archive exists, then the oldest archive will become the primary and its existing data
will be overwritten.
In the example shown below, you will notice that this means your data will be overwritten if you do not
create sufficient new archives or enable automatic archive creation.
Page 96
Using the PI SMT Archive Manager, you can set an archive to not be shiftable.
Tip
To prevent overwriting archives:
Turn on automatic archive creation or keep adding new, empty

archives.
Have plenty of disk space.
Set the archive as non-shiftable
7.14.3 The Annotation File

Each Archive has an associated annotation file. This file is important to keep with the
archive file. It contains non-time series data.
7.14.4 Setting Up An Archiving Strategy

The most important rule about Archives is to have a strategy for how you manage your data.
Since the PI System will either create an archive file as needed, or use an existing empty
archive, you have to determine which method you will use:
Auto Archive Creation

Create Empty Reserves
You can use PI SMT to create and manage archive files.
Page 97
Piartool is a command line tool to manage archives in the PI system.
7.14.5 Automatic Archive Creation

Archives can be created automatically. They will be the same size as the primary archive. This feature is
not enabled by default. You enable automatic archive creation with the Archive_AutoArchiveFileRoot
parameter in the Archive tab of the Tuning Parameters PI SMT plug-in. You simply enter a valid file
path and file name prefix and the parameter is turned on.
Page 98
Once this parameter is set, the PI Server will no longer use any empty, fixed size archives that have been
created. To disable the automatic archive creation, clear the value and save the entry. Do not set to the
default value of zero (0), as this will keep the function enabled.
To change the size of the automatic archives that are created, you need to:
1. Disable automatic archive creation by setting the Archive_AutoArchiveFileRoot parameter to a
blank value
2. Create a new empty PI archive with the desired size.
3. Force an archive shift. This will shift into the newly created archive with the desired size.
4. Re-enable automatic archive creation by resetting the Archive_AutoArchiveFileRoot parameter.
You must monitor your disk space if you use this feature. The system will return to the old behaviour if
you run out of available disk space or if the path does not exist for the automatic file creation.
The extension of the archive file can be changed with the Archive_AutoArchiveFileExt tuning
parameter. The default is .arc.
The format of the archive file suffix can also be changed with the Archive_AutoArchiveFileFormat
tuning parameter.
The default value is 1. Possible values are:
0: [root]_D_Mon_YY_H_M_S[.ext]
Ex: auto_8_May_08_11_23_17.arc
1: [root]_YYYY-MM-DD_HH-MM-SS[.ext]
Ex: auto_2008-05-08_11-03-52.arc
2: [root]_UTCSECONDS[.ext]
Ex: auto_1210260306.arc
Page 99
7.15 Solo / Group Exercise Manage Archives

Exercise Objectives
Determine the predicted date for the next regular archive shift
Create a new, empty archive
Configure Auto Archiving
Force an archive shift
Problem Description
You need to learn to use the PI SMT Archive manager to manage your archive files.
Approach
Open PI SMT and connect to your PI Server. Examine the archive statistics for the existing
archives and answer the following questions:
1.
How many archives are there?
2.
What is the name of the current Primary?
3.
What are the start and the end times?
4.
Which will be the next archive to be Primary?
Create a new, empty archive of the same size as the current primary.
Configure Auto Archiving in the Tuning Parameters to automatically create new archive files
in the C:\PI_Data\Archives\ folder (remember to create the folder first). Force a shift to test.
Page 100
7.16 The AF Link Mechanism.

The AF Link mechanism keeps the PI Module Database and the PI AF data structures in sync
with each other. There is one main reason for this:
Applications that use the PI Module Database for structure but we want people to build
those structures in PI AF (not to use the PI Module Database anymore)
This is sometimes and issue for two reasons:
7.16.1 Security
The security models may be different. PI AF uses the Active Directory objects and the
security roles as defined in the Microsoft SQL Server. The PI Server has piusers and
pigroups and can have mappings to the Active Directory.
It is possible for someone in a role on the SQL Server, not to be identified as having write
access in the PI Module Database.
7.16.2 Data Types

The PI AF has data structures that do not exist in the PI Module Database. It is possible to
create an Element Attribute in PI AF that is not valid in the PI MDB (only in the sync-ed
Element). These cannot be used in applications that use the PI MDB.
In these cases they are labeled as such:
Tip
The PI Module Database is being deprecated. You should get into the
habit of using the PI AF database only.
Page 101
7.17 Directed Activity Validate the PI AFLink Mechanism

have directions.
Activity Objectives
Check your functioning of the PI Module Database - AF Link
Approach
Open PI SMT.
Determine if the servers are currently in sync.
From the information displayed in the tool, determine how often the sync check is made.
Page 102
7.18 Common Tuning Parameters

Tuning Parameters are similar to adjustment dials for the PI System. The defaults are all set
to the most common PI System but in most cases, yours will be unique in some way. What
follows are the most common tuning parameters, what they do, and how they are often
adjusted.
If you have any questions please contact OSIsoft Technical Support!
The Tuning Parameters are found and can be adjusted in PI SMT. You
must have write access to the PI TUNING table.
Tip
In general you should not lower or reduce a value unless you have a
good reason. This could negatively impact user access.
The tuning parameters in this section are defined in PI Server 2010 System
Management Guide, version 2010.
7.18.1 EnableAudit
The PI Server has a robust audit mechanism, but it is not enabled automatically. It is not
enabled because the process does take a certain amount of computer resources, and most of
our early customers did not need the feature. If you want auditing you have to turn it ON.
Turning Auditing ON is as easy as setting the EnableAudit value to a negative one (-1) and
then restarting the following subsystems:
Snapshot
Archive
Base
7.18.2 Archive_LowDiskSpaceMB
If your PI Server is installed on the same drive as your Operating System or you have a very
limited drive space available for your archives, you can protect your system from running out
of hard drive space by setting this parameter.
Page 103
In a PI Server with ample disk space, this is not necessary.

This is the minimum amount of free disk space to leave on the volume of the primary archive.
This parameter prevents automatic archive creation when free space is less than the specified
value. In that case, the PI Server will begin writing data to queues.
The calculation is as follows:
Archive_LowDiskSpaceMB = (Archive Size x 3 ) + 2,000
Where the result reserves 3 times the archive size plus 2GB
Tip
This parameter is not shown by default in System Management Tools, it

must be added manually.
7.18.3 Archive_AutoArchiveFileRoot
This tuning parameter does two things: it enables Auto Archive Creation and defines the path
for the archives. You must specify a valid path where the archives will be created and the file
name prefix.
Tip
We recommend you use a name that identifies the PI server name and
primary or secondary (if HA).
Example: E:\PIArchives\SYD_PRI (where SYD is the site abbreviation
and this was the primary of the collective).
There are also tuning parameters to set the file name and extension but these are not often
used.
7.18.4 Archive_MaxQueryExecutionSec and ArcMaxCollect

If you have very expensive queries you may need to limit either, the time allowed for a query
to execute, or the amount of data that can be returned to the user. You would only use these
if you were having performance problems due to excessive or expensive queries.
Archive_MaxQueryExecutionSec has no default value. The integer value set is the number
of seconds allowed for a query.
For example:
Archive_MaxQueryExecutionSec = 300
Page 104
would limit a query to 5 minutes.
Tip
Instead of limiting queries try to work with your users to write more
efficient or better queries!
ArcMaxCollect has a default value of 1.5 million events (this was lower in earlier versions).
This does not prevent the more expensive queries, but truncates them.
7.18.5 MaxConnIdleTime
By default, there is no limit to how long an idle connection will be kept open. This parameter
determines if that idle connections are closed after a specific time in seconds. This can be
dangerous, because dropped connections will stay open the on the server indefinitely. It is
best to set this to something reasonable.
For example:
MaxConnIdleTime = 86,400
would disconnect idle connections after 24 hours.
7.18.6 Snapshot_EventQueuePath
By default, the Snapshot Event Queue is installed in the same folder as your archives. It will
be easier to manage the files if they are not mixed in with the many archive files.
7.18.7 Snapshot_EventQueueSize
The recommended size is one-half of your archive size. If you change your archive size you
should change your Queue size as well.
Tip
The Snapshot Event Queue setting only takes effect on startup. You will
have to restart the Snaphot Subsystem to change the location or size.
7.18.8 TotalUpdateQueue and MaxUpdateQueue

These are common parameters adjusted when the PI Server is the source server for a PItoPI
interface. In this situation the source PI Server can queue up a great number of events,
especially if the scan time is longer. This number can be far greater than other applications
like PI ProcessBook or other client tool.
Page 105
This parameter adjusts the maximum number of events in Update Manager for each and all
consumers.
Adjust the MaxUpdateQueue if think you will have more than 50,000 events queued up
between interface reads.
Adjust the TotalUpdateQueue if think you will have more than one million events queued
up at any time.
Tip
Page 106
Some have used the following formula:

(20 + 2 * Number of Interfaces ) * (MaxUpdateQueue)
Understanding the Common Setup of PI Interfaces
8. Understanding the Common Setup of PI Interfaces

Objectives:
8.1
Define a PI Interface
Identify the basic components of an interface installation
Discuss the variety of architecture possibilities
Describe how to connect interfaces in a secure way
Install and configure an interface
Configure the basic interface parameters
The Interface Defined
The PI Interface plays a critical role in the PI System. It performs the following tasks:
1.
2.
3.
4.
Connects to the data source

Timestamps the data (or ensures the data received is stamped at the source)
Formats the data correctly
Send the data to the PI Server
PI ICU
Data Source
Interface
Buffer
PI SMT
Tag Configurator
PI Server
Page 107
8.2
Directed Activity Whats Installed

have directions.
Activity Objectives
Identify the PI interface components.
Approach
Every Interface has at least four components that are installed on the interface computer
(many interfaces have additional files refer to the manual for details).
The image below illustrates the basic components for the PI Random Interface. Write the
functions next to the icons.
Page 108
8.3
Interface Installation Considerations
8.3.1
Where do you install the Interface?
Several architectures are possible with interfaces. Examples are shown below:
Having seen the above recommendations, what would you say was the least difficult
configuration?
Page 109
8.3.2
Interface Node Clock
Before you install and configure the interface, make sure that the clocks on the Interface
machine and PI Server machine are relatively close. They do not have to be exact.
Tip
8.3.3
An interface that is more than 30 minutes off the server clock will not
run, and data that is sent more than 10 minutes into the future will be
discarded!
DST Rules
It does not matter so much that your computers obey DST, as long as the servers and your
interfaces are configured the same way and observe the same rules!
Page 110
8.4
Directed Activity Interface Syntax Dissected

have directions.
Activity Objectives
Learn the interface startup file syntaxes
Approach
As a class, navigate to one of the startup batch files for the default Random interface. Edit
the file to open it. The elements in the startup file are called switches.
You are allowed and encouraged to open an interface manual to answer the
questions.
Parse the file to answer the following questions:

1.
What does /HOST mean? What formats are acceptable?
2.
What does the switch /ID do?
3.
What does the switch /PS refer to?
4.
What is the connection between /ID and /PS?
5.
What is the /F switch used for? What formats are acceptable? What is an offset and what is it
used for?
Page 111
9. Creating and Managing Points

Objectives
Build and edit points with Point Builder

Describe a digital state set
Create a digital state set
Create digital state points
Build and edit points with the PI Tag Configurator add-in to Excel.
Understand use and building of IO Rate Tags
Earlier in the course, we defined a PI Point. Now we will dive deeper into them.
There are many ways to create points in the PI Server. Throughout the course, we will show you the most
common.
One tool often used to build and edit tags is Point Builder in PI SMT.
The Point Builder plug-in for PI SMT is a graphical tool that allows the user to create and edit PI points.
This tool allows the system manager to set the attributes for each point individually during PI point
creation, and allows you to edit them afterward. Some attributes are system assigned and cannot be
changed.
It is possible to rename a point while preserving the historical data associated with it. It is also possible to
delete a point, in which case archived data is no longer accessible.
Page 112
Creating and Managing Points
9.1
PI Point Attributes and Interfaces
Do you remember what was said about always reading the documentation manual? Each interface can use
point attributes in a different manner. That is why each interface documentation notes what point
attributes are used and how.
Tip
It is a good idea to print out the interface manual and keep it as a hard
copy. It is a Microsoft Word document and it is likely you will have to
configure an interface on a machine that does not have that application
installed!
Listed below are the common point attributes and how they are commonly used. ALAWAYS consult the
interface manual.
Instrument Tag
Name of the point/location in the source data system.

Often it must match the data source exactly!
Extended Descriptor
Place for detailed query instructions (uncommon).
Exception Specifications
Defines a significant change in value.
Point Source
Must match the value set in the interface configuration.

See the /PS parameter in the interface start-up file.
Location 1
Typically, the Location1 field is used for the interface

instance number (/ID)
Location4
Typically the field is the scan class number.
Tip
Instrument Tags are sometimes case sensitive! Copy and paste this
information directly into PI SMT or PI point Configurator from the PI
OPC Client Tool if possible.
Page 113
9.2
Point Edits Timing
Every 2 minutes, interfaces check for point updates. If points were added, modified or deleted, the
interface will reload points at a rate of 25 points per 30 second. This is a preventative measure so as to not
overload an interface. This means that depending on the scan class and the number of points that are
affected, it could be some time to reload the points. The log will indicate if the points were loaded by the
interface with or without error.
If the points are not loaded, check the Point Source and Location1 point attributes, to make sure they are
set according to the parameters in the interface start-up file. If those do check out, double check that you
have a valid PI Trust to the PI Server and that it grants write privileges to the desired point(s).
9.3
Digital State Sets
9.3.1
Usage of digital state sets
Digital points are used to store data sources that have discrete states as can be seen above. These are
typically states such as Open/Closed for a valve or On/Off for a switch. While the user is interested in the
actual state, PI stores this information as an integer. This integer is then associated with a Digital State
Set, which is a grouping of these states. Whenever the value is requested, PI retrieves the integer value,
does a lookup in the Digital State Set, and then presents the text value.
Digital Sets are kept in a common table for multiple points to access. For example, a Digital Set
containing the states of On and Off can be accessed by multiple points in the PI Server. The Digital State
Set must exist prior to the creation of the digital point. You will then use the DigitalSet attribute to store
the associated Digital Set name. The digital states are case preserving, but not case sensitive, so you can
refer to them with upper and lower case, but it will display the configured upper or lower case. There is a
large default set called System, which contains the system error messages and other information. All
points, including non-digital points, can receive from the PI Server and archive a state from the System
Page 114
digital states set (Shutdown, PtCreated, Over Range, Under Range, I/O Timeout, etc.). It is not
recommended to use or edit the System Digital Set on your PI Server.
9.3.2
Creating digital state sets
You can create Digital States with the Digital

States plug-in under the Points section in PI
SMT. This allows you to create new Digital
States, copy and paste existing Digital states,
and edit or delete existing Digital States. Digital
Sets are local to the PI Server, so if you would
like to have the same Digital Sets on multiple PI
Servers, you will need to export and import the
list of sets and states as a .csv file or copy /
paste the state sets from one server to another by
opening multiple PI Servers connection inside
the plug-in.
To create a new Digital Set, select the New icon in the menu bar. You can also right click and select Add
Set from the pop-up menu. A new table will appear with two columns. These columns are State Number
and State Name. The State Name field corresponds to the states of the data source and is manually
entered, although is a facility for importing digital states. The State Number field corresponds to the
integer that PI will store in the archive for that digital state. This field is populated automatically, starting
at a value of 0 and increasing by 1 from there. Once you have fully entered all of your digital states, save
the new digital states by clicking on the Save icon in the toolbar.
Additions and edits to Digital Sets are immediately available on the PI Server. However, most client
applications, including PI SMT, will cache the Digital Sets. This means that you may have to exit and
restart for any changes to be visible.
Page 115
9.4
Exercise Create a Digital State Set / Point

concepts presented in this chapter or section. You are invited to perform the same
steps at the same time.
Exercise Objectives
Create a digital state set and point based on the data source.
Problem Description
In one of your plants, you are producing paint of different colors. A set point in your DCS holds the
information regarding which color at a particular point in time should be produced. That information is in
the form of digital status and you want to capture it in the PI Server.
You are given the following translations:
Red
Green
Yellow
Black
Blue
Use the above information above to build the point with the proper attributes.
Approach
Open the PI SMT Digital States plug-in and create a Digital State Set on your PI Server.
Then use PI SMT Point Builder to create an appropriate digital point for the set point
information.
Note the important tag attributes and use the following values:
Tag, Descriptor, Digitalset, Location2=3, Location4=1, Location5=1, Pointsource=R, Pointtype=Digital
Page 116
9.5
PI Tag Configurator
PI Tag Configurator is an add-in to Microsoft Excel. The spreadsheet format is convenient

when viewing and editing in bulk, with a row for each tag and a column for each attribute.
The tool best suited to bulk build and edit tags is PI Tag Configurator.
PI Tag Configurator requires the spreadsheet to have the following layout:
The attributes are listed in the top row.

The point names are listed in the second column.
Each point has its attributes listed under the headings in the top row, one point per row.
Select a point row by putting X in the first column. Import or export operations are
performed on these selected points only.
Tip
9.5.1
Like every powerful tool, Tag Configurator can save you a lot of time or
do a lot of damage if not used carefully. Be Careful!
Enabling Delete
You may notice that the Delete action is not enabled by default. That is because there is no
undelete for a tag. If you delete a tag(s) by accident, you cant get them back. All of the
history is inaccessible or lost. People have accidentally wiped out their entire systems by
accident.
It is recommended that you only enable Delete when you need it and be extremely careful
when using it.
9.5.2
Export only What Matters
OSIsoft recommends that you build templates, which include only the necessary attributes for that type of
tag. In addition, you may need such a set of templates for each interface type.
Your instructor will show you examples.
Moreover, only export the tags (rows) that you actually changed or are new.
Page 117
9.5.3
The Deviation versus Percent Issue
The compression / exception deviation is actually determined by the following logic:
Deviation Percent/100 * Span = Deviation

So the following three are true:
If you change the CompDevPercent attribute, the CompDev will be reset

accordingly.
If you change the CompDev attribute, the CompDevPercent will be reset
accordingly.
If you change the Span, the CompDev will be reset accordingly.
If you export a line where two or three are changed or one is changed but you export all of the fields then
the system has to make a guess as to which change you really want. In that case, the CompDevPercent
(and the Span if it changes) will take precedence.
Page 118
9.6
Exercise PI Tag Configurator

Exercise Objectives
Create points from a spreadsheet with the PI Tag Configurator

How to work with the Interface Manuals
Configure Interface startup files
Problem Description
You should create two sinusoidal tags for the random interface without doing so individually in the PI
SMT Point Builder Tool.
The first tag should show a one-hour Sinus wave with a scan class of 5 seconds, which
starts on the full minute.
The second tag should show a ten-minute Sinus wave with a scan class of 1 second.
Both tags have a scale from zero to 100. Please build useful tags.
Approach
Use the Tag Configurator to build one line for each new tag and export the definitions to the
PI Server.
In PI ProcessBook, validate that the tags are working properly (collecting data).
Tip
Usually, when creating new tags, you might to create new scan classes in
the interface startup file to accommodate new scan frequencies.
Also, when configuring each new tags, take note of the tag attributes
whose purposes are unique to each interface (Location 2, 3 and 5, for
instance).
Page 119
9.7
Exercise Create IO Rate Tags (Optional/Time permitted)

Page 120
Page 121
10. PI Security
Objectives
Describe the function of the PI Firewall in the connecting logic

Describe the function of the PI License in the connecting logic
Describe how users connect
Describe the security implications of working on the server box
Describe pisusers and pigroups (pre 3.4.380.XX security)
Describe the ACL syntax and how access is granted
Create and manage PI identities
Configure PI mappings
Configure PI point security
Create and configure PI Trusts
Configure PI database security
Configure PI security settings slider
Tip
OSIsoft recommends you reserve Trusts for unattended applications like

Interfaces. You should NOT use them for user access for PI Servers
version3.4.380.XX and later.
For the PI System to be useful, people have to be able to get critical data to make decisions.
In this chapter, we will address the methods and best practices for allowing users proper access to their
data.
Page 122
PI Security
10.1 The PI Server Conundrum

The PI System has two parts: PI Server and PI AF Server. In the PI AF Server, you can tie
Active Directory entities to objects.
PI AF
Server
Active
Directory
PI Server
However, the PI Server does not have the ability to tie Active Directory entities directly to
objects like points or data tables. In the PI Server, we create mappings to objects for which
we want to control access. We call these mapped things PI Identities.
PI AF
Server
Active
Directory
Mapping
PI Server
Page 123
Tip
Caution: We do not recommend using native PI Server security (piusers

and pigroups) as they are, by definition, less secure.
Having logged into the computer via her corporate windows account, the user is
automatically authenticated on the PI server. This is accomplished by the PI system manager
mapping the users active directory group to a PI Identity. The identity specifies the
read/write permissions for accessing the database.
10.2 PI Firewall
The PI Firewall is the first level of access security to your PI Server. It
provides a rudimentary control based on the incoming IP Address or
hostname.
There are only two functions:
ALLOW
DISALLOW
HostMask
Tip
Value
192.168.149.55
Disallow
192.168.177.*
Allow
Bobcat.somewhere.com
Disallow
Although the PI Firewall can be very useful for a few customers, the
maintenance of a separate firewall database in PI is rarely advisable.
Most implementations control access through network infrastructure.
By default, the PI Firewall contains one entry configured with an IP address mask of *.*.*.* and a value
of Allow. This provides access to all incoming connections. Corporate firewalls and routers protect most
PI installations.
Use the Firewall PI SMT plug-in in the security section to configure the PI Firewall. Any IP address or
subnet may be allowed or disallowed access.
Page 124
PI Security
Tip
More specific host masks will override ones that are more general.
10.3 The PI License Subsystem

The PI License subsystem has the capability to determine what applications are allowed.
However, as of the current version the only element that is actually metered is the point
count.
Applications may generate messages such as:
0 pinetmgr 20-Oct-05 11:34:07
>> License Warning (non-fatal): [-12221] Not licensed to use this client application.
Level: 3 Process name: PointBuilder.exe(5676) ID: 51
You do not need to respond in any way these are informational.
You can use the License plug in in PI SMT to view your license statistics.
10.4 Connection Logic

The diagram on the following page illustrates the connection logic.
Tip
You should avoid using the native piusers and pigroups in your security
scheme. They are inherently insecure and are included for legacy
systems.
Page 125
PI User
Firewall
License
Not Often Used
Trust
Windows Users
piuser/ pigroup
Mapping to PI Identity
PI Point
Page 126
DBSecurity
PI Security
10.5 Granting Access

Each connecting user is associated with a PI Identity (or piuser or pigroup) and that PI
Identity has permissions explicitly granted by an ACL.
10.5.1 Granting Access the ACL
An Access Control List (ACL) string defines the access permissions for that entry.
Choices are read and/or write.
The syntax is:
Identity1:A(r,w) | Identity2:A(r)
Where Identity1 can read and write and Identity2 can only read.
Tip
You can give only write permissions but it is not recommended for
users.
10.5.2 Granting Access - Application

You will apply the ACL in general in one of two places: the DBSecurity or PI Point attributes (point
configuration access and point data access).
In the DBSecurity Table you grant access to data structures on a global level. You can also apply access
permissions on a tag by tag basis.
Page 127
10.6 Managing PI Users, PI Groups and PI Identities and Mappings

The Identities, Users, & Groups plug-in in PI SMT allows you to create and manage PI Identities, PI
Users and PI Groups. Several entries are created by default during installation. When configured, you can
use the security entries to specify security settings throughout the PI Server, including PI databases
security and PI point security.
Tip
Page 128
Ideally you will have one Identity for each Active Directory Group you
will use to access the PI System. It is more flexible to use AD Groups
and not try to micro-manage AD User mappings.
PI Security
10.7
PI Trust
For obvious reasons, the interface needs to connect to the PI Server. The application cannot log in so it
must rely on a mechanism called a trust to gain access. A trust simply maps a connecting application
to a user. The PI Server checks all incoming connections for a trust as a first step.
Tip
PI Interfaces almost all use a protocol that only sends the IP Address and
an encoded application name in it communication (PI API), so it is best
to base trusts only on those parameters.
You will probably have to create three trusts:
PI Interface
PI Buffer (Subsystem or Server)
PI ICU (if you are using this tool to configure)
A good tool to view connections on the PI Server is the PI Network

Manager Statistics plug in in the PI SMT.
The application name used in the connection for most interfaces is an encoded phrase that
takes the first four letters of the interface name and the capital letter E. For example, the
Random interface will use the phrase RandE.
The best way to verify this is to start the interface and watch the connection that is denied on
the PI Server using the Message Log plug in of the PI SMT. Then look at the PI Server
Message Logs in PI SMT for the denied connection. The message for the connection will
have the information you need to form a trust.
10.7.1
Create Trusts
Trusts are easy to create. Use the PI SMT Mappings and Trusts plug in.
Tip
You can map an application to the piadmins group for convenience in

setting up the trusts, but do not leave that trust in place. Always use
specific Identities in your trusts that have only the necessary
permissions.
You can use either the Wizard or the Advanced options to create a trust they perform the
exact same function.
Page 129
Tip
Trusts should follow the 2+ Convention. That is, a trust to the

interface based on IP Address AND the executable name.
You want to create Trusts SPECIFIC to the executable that is connecting
to PI. Do not map trusts to the piadmin user.
Some people find the Wizard confusing because understanding when to use a PI API
Application or PI SDK application on a Windows NT based OS might not be intuitive.
Most people should simply select Advanced. This simply presents all of the options in one dialog box.
Page 130
PI Security
10.8 Working on the PI Server

A default loopback PI Trust exists on the PI Server that grants piadmin access to all applications running
locally on the PI Server machine.
By default, no login is required to use the command prompt utilities on the PI Server (piconfig, piartool,
pidiag, etc.). You can force a login by modifying the CheckUtilitylogin tuning parameter on the PI
Server. For the change to take effect, the PI Server must be restarted.
10.9
The Database Security Table
In other applications, like Microsoft SQL Server, each object has their own security control settings.
There is the same concept in the PI Server, and all of the database tables are collected in one place. These
are shown in the Database Security plugin in PI SMT.
Note: You must have write access to the PIPOINT database to create new points. You do not need this
privilege to edit the configuration or data of the points once created. That access is controlled by PI point
security.
The table below lists the common database tables used for user access:
Database
Controls
PIDS
Access to Digital States and Digital Sets.
PIModules
Access to the Modules. This is an important option as many programs and users
may require PI Module Database access.
PIPOINT
top-level access to Points, Points Classes and Attribute Sets. Editing existing PI
points can be provided through the PI point security configuration on a point-bypoint basis.
For more information see PI Server 2010 Configuring Security, version

2010.
Page 131
10.10 The Security Slider

You have the ability to disallow types of logins to your PI Sever. This is controlled by the Security
Settings plug-in in PI SMT.
In a good security environment you will set the slider to a minimum of explicit logins
disabled. This should not impact you at all if you avoid using piusers and pigroups.
Tip
Page 132
While it may seem ideal to set the slider to the top level of security this
is not a possibility in todays PI System. Most of your interfaces will fail
to connect if you disable API Trusts.
Installing and Configuring an OPC Interface
11. Installing and Configuring an OPC Interface

Objectives
Discuss polling, advise and event retrieval

Discuss OPC
Tasks to install an OPC Interface
Learn how to work with ICU
Configure OPC Tags
11.1 A Word About Polling, Advise and Event Points

Many interfaces have different methods of retrieving data. All three read types of points are read
asynchronously by the interface and the same data routines process all updates. The method is often set
in a Location Code.
These are described below:
Polled
For polled points, the interface sends an asynchronous refresh call for the group (tags of the
same scan class). This is often the most common method for reading data, and is supported
by virtually every interface..
Advise
Advise tags listen for new events. For advise points (referred to as read on change in the
OPC Standard), the data source sends data whenever a new value is read into the servers
cache. Not all interfaces support the Advise method.
Tip
Often the Advise method of reading data is the most efficient and best
performing.
Event (Trigger)
For event reads, the PI Server informs the interface when the trigger point has a new event
(not necessarily a change in value) and the interface sends an asynchronous read call for the
event points attached to that trigger.
Output
Output tags read a separate PI Tag and write the value out to the data source. These often reference
Performance Equation (calculation) tags that are performing a calculation that cannot be performed on the
data source. Not all interfaces support bi-directional data.
Page 133
Caution: Do not mix advised points and polled points in the same group (i.e. scan class). Some
interfaces do not tolerate and will not function correctly.
Page 134
11.2 What is OPC?

From http://www.opcfoundation.org
OPC is a series of standards specifications. The first standard (originally called
simply the OPC Specification and now called the Data Access Specification) resulted
from the collaboration of a number of leading worldwide automation suppliers
working in cooperation with Microsoft. Originally based on Microsoft's OLE COM
(component object model) and DCOM (distributed component object model)
technologies, the specification defined a standard set of objects, interfaces and
methods for use in process control and manufacturing automation applications to
facilitate interoperability. The COM/DCOM technologies provided the framework for
software products to be developed. There are now hundreds of OPC Data Access
servers and clients.
The PI OPC Interface is like any other interface, with one notable exception: it provides a layer of
abstraction between the interface and data source. Most OSIsoft Interfaces connect directly to the data
source, where the OPC Interface connects to an OPC Server which in turn is connected to a data source.
Because of this abstraction, you must be mindful of the Update Rate. Some OPC Servers use a separate
switch for that, and some use one for the scan classes. Check your OPC Server documentation for details.
Scan Rate
PI Server
Tip
Interface
Update Rate
OPC Server
Device
You never want to set your update rate slower than the fastest scan class!
Page 135
11.3 Directed Activity Preparing to Install the OPC Interface

Activity Objectives
Prepare to install an interface
Approach
Normally before you begin an interface installation you would identify your data source.
Since we are in a training environment we will use an OPC Simulator. It has been configured
to generate a set of sample data such as a wind farm or pumps.
In this situation we will install the Interface on the same computer as the data source in this
case the OPC Server Simulator.
.
Process
Controls
DCS / PLC
OPC
Server and
PI Interface
PI Server
The OPC server we use is made available by the OPC Foundation as the
download "OPC Data Access 3.00 Binaries". These files are available at
http://www.opcfoundation.org/. Search for "OPC DA Sample Binaries." Please
consult the OPC Foundation web site for details if you wish to obtain a copy.
Page 136
Fill in the following architecture diagram with the Hostnames and IP Addresses of your machines:
Tip
It is a good idea to stick with the same configuration credential when

setting up the interface and buffering. If you use IP Address in the
interface hostname then make sure to use IP Address in the PI Buffering
configuration, and vice versa.
If using hostname, it is recommended to use the FQDN whenever
possible.
Page 137
11.4 Validating communication between the PI Server and the PI Interface

Verify that the data collector computer can communicate with the PI Server. The apisnap (\pipc\bin)
utility validates the PI Interface connection to the PI server (remember PI Interfaces use the PI API to
connect). Once connected, you can display the snapshot, status and the last archived value for a point as
shown below.
The PI Connection Manager validates the PI SDK connection to a PI Server. It is accessible with the
PISDKUtility in Start -> All Programs -> PI System.
If these tests do not work, you may need to try simpler tests such as pinging the PI Server from the
interface computer. You will need to get them working before proceeding.
Page 138
11.5 Directed Activity PI OPC Interface Install & Configuration

Exercise Objectives
Install the PI OPC Interface on the data collector computer.

Configure the PI OPC Interface with PI ICU.
Start the PI OPC Interface as a Windows service.
Problem Description
You need to set up the OPC Interface to collect data. An OPC Data Simulator will be
installed on your computers.
Approach
Install
Log into the computer designated as the PI Interface Computer. Install the software:
Install the OSIsoft prerequisites kit.

Install the PI ICU.
Install the PI OPC interface.
Get it Going
Setup your trusts. On the PI Server, use PI System Management Tools (PI SMT) to:
Build a PI Trust for the PI ICU application (PI-ICU.exe) granting it access as the
piadmin PI User.
Build the three PI Trust for the PI OPC interface computer with IP address, Host
name and FQDN granting it access as the piadmin PI User.
Tip
Why use the piadmin User when we earlier said that was bad
practice?!? Because it is often simpler to use that all-powerful group to
get the interface running, then look at the connection characteristics, and
build the appropriate security models.
Use PI Interface Configuration Utility to configure the PI OPC interface:
Set the host PI server to the PI server to which you will send data.
Set the OPC server name to the OPC Data Access server simulator.
Page 139
Tip
You can get the name of the OPC Server Name by using the PI OPC
Tool. The PI OPC Tool is installed with the OPC Interface. It will not
be in the Programs menu, but you have to navigate to the OPC Interface
folder and run it.
Use PI Interface Configuration Utility (PI ICU) to create the Windows service for
the interface.
Start the interface interactively to confirm operation. Look for connection to both the
PI Server and the OPC server.
Start the interface as a Windows service and confirm proper start-up by using the
PISDKUtility to monitor the message log.
Tighten Security
Page 140
In PI SMT, use the Network Manager Statistics plug-in to validate that the
interface is connected to the PI Server.
Create a new new PI Identity called PI OPC Interface.
Create a new trust with the PI OPC Interface PI Identity.
Restart the Interface and validate that the interface is using the correct trust and PI
Identity (not the piadmin User).
11.6 A Note About Load Balancing a Large Number of PI Tags

Most PI interface will allow you to put large number of PI tags per scan class. The amount of
tags per scan class depends how often the tags are getting updated. If the interface is under a
large load, then some scans may occur late or be skipped entirely. OSIsoft recommends
putting the tags into another scan class with an offset. An alternative would be to create
multiple instances of the PI Interface to split the tag load.
11.7 PI Interface Configuration Utility

PI ICU allows system managers to easily configure and maintain interfaces. It automatically stores
needed information in the PI Module Database on the server, and in the interface start-up file (.bat). The
ICU can only configure interfaces that run on the same computer as the ICU.
The PI Interface Configuration Utility (PI ICU) is simply a GUI for editing
the startup batch file!
The one thing you must keep in mind is that the PI ICU READS from the PI Module Database but
WRITES to the interface startup batch file.
PI Interface
Configuration
Utility
READ
IT
WR
PI Module
Database
Interface Computer
Interface.bat
Tip
If you use the PI ICU to edit an interface startup file do not edit it
manually again your changes will be lost the next time someone uses
the PI ICU.
Page 141
This also means you will need a trust to the PI Server for the PI ICU because it needs write access to the
PI Module Database.
11.8 Directed Exercise Explore PI ICU

You are invited to watch what the instructor is doing or perform the same steps at the
same time.
Activity Description
Use the PI ICU to import the sample batch file that comes with the interface.
Approach
Open PI ICU.
Import a new interface start-up file (for instance, OPC interface) into PI ICU. The PI ICU
should open the appropriate folder by default. All OSIsoft Interfaces are installed in a single
local folder labeled Interfaces. If the person running the installation kit selected a different
location, you may have to browse your file system.
Tip
Import the .bat.new file into PI ICU and then save the file. Note the new
.bat file in the appropriate interface folder.
11.8.1 The PI ICU General Section

Once the .bat_new file has been imported, the General section of PI ICU allows the user to configure the
main start-up parameters of an interface, such as the point source (/PS), the interface id number (/ID), and
scan classes (/f).
Note the features on the General tab. Add 2 new scan classes, one scanning every 1 minute
with a 15-second offset and a second one scanning every minute with a 45 second offset.
11.8.2 The PI ICU UniInt Section

UniInt is short for Universal Interface. It is reusable code integrated in many of OSIsofts interfaces to
include generic functions such as establishing a connection to the PI Server computer and monitoring the
PI Point database for changes.
Page 142
For more information see the UniInt Interface User Manual
This section presents the UniInt-based interfaces parameters, such as scan performance summary, debug
level, stop time, and more. You can configure the interface to write a shutdown state when the interface
stops by using the Write status to points on shutdown option. Doing will provide a clear indication of a
gap in the data collection.
Note: The PI OPC interface does not use this Write status to points on shutdown option in the UniInt
section of ICU. It uses a separate switch in the interface specific section (opcint) of the ICU.
Page 143
11.8.3 The PI ICU Interface Specific Section

In addition to generic parameters, interfaces have interface-specific parameters. The contents of this
section of the PI ICU will change according to the interface. The interface section will display either an
interface specific PI ICU control that aids in configuring parameters specific to the current interface or be
blank.
11.8.4 The PI ICU Service Section
The Service section allows the user to configure the interface as a service. Configuration of a service
includes display name, log on as a specific user, start-up type and dependencies.
Before you click the Create button, configure:
Display name: name displayed in the Services window populated by default
Start-up type: recommended automatic - default
Dependencies: recommended PIBufss when buffering runs tcpip is default
Log on as: some interfaces require the service to run as a specific account (consult interface-specific
documentation) , but especially useful in getting services to work in Workgroup environments.
On buffered interface computers, you will want the interface to be dependent on the PI Buffer Subsystem
(PIBuffss). This will assure that the buffer starts before the interface. You do not need to buffer
interfaces running locally on the PI Server.
Page 144
11.8.5 Start the Interface

There are two ways to start the interface:
Interactive (you run the interface manually as your currently logged in Windows
user)
Non-Interactive (you start the Windows Service)
Tip
You must validate that the interface can be started by the Windows service before
you consider your configuration complete. It is possible that you can start the
interface interactively using your permissions but the Windows service not have the
correct permissions and fail.
Start your Interface. Validate in the log file there are no errors.
There are two ways to view the log file:
Interactively (run pigetmsg f)

View the log file (the pipc.log file or the PI SDK logs)
You will create points collected by this interface in the next chapter.
The most common cause of malfunctioning new tags is some incorrect mapping of PI tag attributes to the
data source or the interface configuration.
Page 145
11.9 Exercise OPC Points

Exercise Objectives
Build PI OPC Points.

Validate PI OPC points are collecting data from an OPC server.
Problem Description
You have a set of pumps connected to your PI OPC Server and generating data. (You have
already configured your PI OPC Interface).
You need to create tags in the PI System.
Approach
Use the PI OPC Tool (installed with the PI OPC Interface) to examine your OPC Server.
You should notice that there are a series of pumps. These pumps each have some tags
associated with them, and they should be generating data.
Use the PI OPC Manual and the information contained in the PI ICU to configure tags. Pay
particular attention to the Location Codes and the ItemID.
For more information see "PI Point Configuration" in PI OPC DA

Interface Manual.
Tip
Open a command prompt and run pigetmsg f

It will show if the tag was picked up properly by the Interface.
Stop after building the tags for ONE PUMP only!
Page 146
Page 147
12. Buffering
Objectives
Describe PI Buffering
Define the two different buffering mechanisms and pros / cons of each
Configure PI Buffering
Validate the function of the buffer
Throughout this section you will refer to various sections in the PI Buffer
Subsystem User Guide, version 3.4.375/PR1. Please open this document.
12.1 What is PI Buffering?

Data sent from the interface to the PI Server is redirected to the buffering process, which stores and
forwards events to the home node.
Data is stored initially in memory until the allocated buffers are filled. Data is then stored in a file. The
size of the file and the memory buffers are configurable. When the buffering process is shut down, the
memory buffers and file buffers are combined into a new file that contains all data not yet sent to the
server, using FIFO (first-in, first-out).
When buffering is on, all calls that send data to the default home computer are buffered. Multiple
interfaces on a single data acquisition computer share the same buffering process and store data in the
same buffer.
Tip
Unless you have a specific reason why you do not want to preserve your
data, you should always configure buffering for an interface!
Normally buffering is run as an automatic system service to ensure it is always running.
Page 148
Buffering
12.2 Directed Activity The Two Faces of Buffering

have directions.
Activity Objectives
Describe the pros / cons of each buffering mechanism
Approach
The instructor will divide the room in half. Each side of the room will be given one of the
buffering mechanisms.
Each team will use the Buffering user guide to research their buffer. The room will have 5
minutes.
The instructor will then ask each team to present why you would want to use their
mechanism.
See " PI Buffer Subsystem vs. BufServ in PI Buffer Subsystem User

Guide, version 3.4.375/PR1. .
Element
API Buffer Server
PI Buffer Subsystem
Supported Platforms
Supported PI Servers
Compression Algorithm
Maximum Buffering
Capacity
Maximum Throughput
Page 149
12.3 The Buffering Mechanism

How does it work?
Very simply, the buffering mechanism intercepts the data as the interface sends it and the buffering
application manages the communication between the interface computer and the PI Server.
There are three buffers used to process events: two memory buffers and a file buffer.
Depending on the amount of data being buffered, the buffering process can be in one of three
states. Initially, it uses a single memory buffer. When that fills, it switches to using dual
memory buffers. When these buffers become full, it switches to using dual memory buffers
and a file.
12.3.1 Buffer File
Data is copied into shared memory buffers, or if already full, overflows to the buffer file on disk
(APIBUF_<servername>.dat). The PI Buffer Subsystem consumes data from the buffers as soon
as they are detected. Timestamps and values are validated and if point-level compression is enabled,
events are marked as Snapshot Only or To Be Archived. Once validated and marked for compression,
all events are stored in as many queues as there are replicated nodes in the target PI Collective
(pibufq_<servername>.dat). A non-replicated PI Server requires only a single queue.
Page 150
Buffering
12.4 Directed Activity Mapping Data in PI Buffering

have directions.
Activity Objectives
Describe the path complexities data takes when buffered.
Approach
The group will track data as it leaves the interface and finishes up in the Snapshot on the PI Server. Your
instructor has instructions.
You can monitor the status of your buffer in real-time, whether it is currently able to pass data to
the PI Server, or not. To do this, in a command prompt, use the \pipc\bin\pibufss.
Page 151
12.5 Directed Activity Configure Buffering

have directions.
Activity Objectives
Configure Buffering
Validate data is being buffered
Approach
There are a couple of ways to configure buffering, but in this course we will use the PI
Interface Configuration Utility.
The PI Interface Configuration Utility (PI ICU) is the preferred way to

configure both the Interface and PI Buffering.
Tip
Remember you will need a trust to use the PI ICU. You will need write
access to the PI Module Database.
To enable buffering on a data collector, follow these steps in PI ICU. (Buffering is configured through
entries in the piclient.ini file.) Select Buffering from the Tools menu in PI ICU.
Page 152
Buffering
Select your desired buffer from Choose Buffer Type.
Change the default settings as necessary in Buffering Settings.

Select the buffered and replicated PI Servers in the Buffered Servers list.
Configure, create, and start the buffer service in Service.
Page 153
Tip
Caution: the Buffering mechanism will NOT collect data unless it starts
BEFORE the interface. Make sure you set the dependency.
Make sure the PI Interface is dependent

on the buffer service. The PI ICU will
recognise if an interface does not have a
dependency set for the buffering service
when it is enabled, and it will prompt you
to set the dependency.
Page 154
Buffering
12.6 Validating Data Buffering

It is critical that you not only check the buffering when you configure it but it is
recommended that you periodically check the buffering to make sure it remains doing its job.
The only way to validate buffering is to run a command prompt on the interface machine.
To validate the PI API Buffer Service:
Open a command prompt window and navigate to the pipc\bin folder:
Bufutil
To validate the PI Buffer Subsystem:
Open a command prompt window and navigate to the pipc\bin folder. Run the PI Buffer Subsystem in
interactive mode to see the queue statistics:
pibufss -qs
The image above shows a non-working buffer notice all of the zeros in the columns.
Page 155
12.7 Solo / Group Exercise The PI Buffer Subsystem

Exercise Objectives
Configure and verify buffering on a data acquisition node.
Problem Description
In the event that the PI server is shut down or disconnected from the network, you need to have data
buffering installed and configured on the data acquisition computer to avoid data loss.
Approach
On the PI Server:
Create a PI ProcessBook display showing the data from one of your OPC points for
the last one hour.
On the data collector:
Validate that you are buffering data from the previous Directed Activity.
Disconnect the interface computer from the network.
Watch the command prompt as it builds values.
Wait a couple minutes (you can check your PI ProcessBook display for a flat line)
Reconnect the interface.
On the PI Server:
Page 156
Verify the data is recovered from the buffer.
Buffering
Page 157
13. High Availability

Objectives:
Describe the purpose of High Availability

Describe the components of High Availability
Create a High Availability PI Collective
Implement PI Interface Failover
List the limitations of PI High Availability
Discuss complex architecture scenarios
13.1 High Availability Defined

High Availability (HA) is not designed specifically to prevent data loss. In the stand-alone PI System
there are already precautions against data loss, most notably the Buffering process.
What High Availability does give you are the following:
Reliability
Less urgent downtime
Sustainable calculations
Disaster recovery
13.1.1 Reliability
When you have multiple data paths between the data source and the user, the data is more likely to be
available when it is critically needed. If one component fails, the data is available via an alternate path. If
a situation is critical to your business, the fact that data will get to you sometime soon is of no help in real
time decision making. When you need data to make a decision today and you cannot get your data until
tomorrow, the system has failed you, even though there was no data loss.
High Availability ensures the data is there when you need it.
13.1.2 Less Urgent Downtime
If you have redundant systems, the urgency to repair a failed system is reduced. When repairs or upgrades
are required, they can be performed with the proper planning and care. There is no need to rush to get
your only source of data up and running. Your professionals have the time they need to properly diagnose
and implement a solution for a problem.
13.1.3 Important Calculations Remain Current
If you have calculations being performed constantly and your system is down, your calculations are not
getting the data required. The calculations may fail, or worse, run with the wrong data, leading to
Page 158
High Availability
inaccurate results. When data that is always available, your applications that use PI data run
uninterrupted.
13.1.4 Disaster Recovery
When one of your redundant servers fails, it is easy to replicate it using one of the working partners.
There is no need for a complete rebuild and migration of data.
Page 159
13.2 Directed Activity Components of PI High Availability

have directions.
Activity Objectives
Define the components of PI High Availability
Approach
High Availability requires three (3) components all working together to function properly.
These components are:
Interface failover and/or N-Way buffering;

PI Server collective;
PI Client application failover.
13.2.1 Interface Failover coupled with N-Way Buffering

One interface of the set is always running, feeding all PI servers with the same data.
13.2.2 PI Server Collective (redundancy)
Redundant PI Servers are together replicating configurations, receiving data from interfaces, and
providing identical data to analysis and client tools.
13.2.3 PI AF Server HA
AF supports multiple High Availability options, including the use of AF Collectives for the AF Server
and Clustered or Mirrored SQL Servers for the AF SQL Database. These options can be combined to use
AF Collectives with Clustered and / or Mirrored SQL Servers. We will not discuss AF collectives in this
class.
For more information, see "AF Deployment Scenarios" in PI AF 2010

User's Guide, version 2.2, pp. 06-16.
13.2.4 Client Application Failover

Clients can connect to any PI Server in the Collective and seamlessly failover to another
server if necessary.
Page 160
High Availability
13.3 PI Server Replication

PI Servers replicate by initially cloning the primary source server. All server metadata is
replicated except:
The Tuning Parameters Table

Message Logs
PI Firewall
Tuning parameters are not replicated because they have configurations that can vary by server
machine and thus are not appropriate to propagate. Message logs are not replicated because
the messages are inherent to the specific machine. Firewall settings are not replicated because
Collective members can be in separate domains and require separate settings.
PI HA has separate paths for the same time series data for true replication. This is
accomplished by replicating the data as it is collected and distributing the data to each server
in the collective. Data replication is achieved in the buffering mechanism.
A replication service keeps static, configuration data (point definitions, digital state sets, and
so on.) synchronized between the primary and the clones (referred to as secondary nodes).
13.4 Limitations
The PI HA mechanism was designed to function in a situation where the servers and
interfaces are all contained within the same domain, and that the domain has a coherent
structure. By coherent structure, we are implying a functioning domain controller with
reliable DNS resolution.
In addition, to have proper initialization of the secondary nodes, there needs to be Windows
file copy access between the servers. Open the related TCP ports. Consult Appendix A to get
more details.
At the buffering level, data is replicated. Any data sent to the PI Server from a source other
than a buffer mechanism is not replicated, only written to a single server. The same situation
arises with applications designed to read and write to a single server. Currently these include:
Performance Equations,
Totalizer points,
PI Batch Generator,
Any Custom manual data entry applications that do not use the PI SDK. PI SDK
applications can take advantage of PI SDK buffering.
Page 161
13.5 Directed Activity HA Pre-Installation Concerns

have directions.
Activity Objectives
Describe the specifics of the HA Installation
Approach
You have many of the same installation concerns as you would a stand-alone PI System.
However, there are differences. Review the section on pre-installation and discuss the
differences for the Secondary PI Servers.
Open the book to "Checklist for Installing PI Collectives" in PI Server

2010 Installation and Upgrade Guide, version 2010.
Your instructor will give you a couple minutes to scan the docs. Answer the following
questions:
Do you need another PI AF Server install?
How do you get a License file for the Secondary?
What version of the PI Server do I use?
Page 162
High Availability
13.6 Pre-Installation Concerns

13.6.1 PI AF Server
PI Server 2010 requires an AF server to be available before the installation. It can be installed on the
same machine as the primary PI server or on a different machine. Only the primary PI server will be
synchronized with AF server.
13.6.2 License
A license file will be required. The license file will have to acknowledge at least one secondary server.
The license must be obtained against the Primary PI Server.
Make sure the PI license supports collectives. Validate this be checking the license information in PI
SMT under Operation > License > Resources. The Amount Left should be greater than 0.
Install the same version of the PI Server software on the secondary PI Server machine. Start the
secondary server, then add the secondary to primary servers PI Connection Manager. Use the PI
Collective Manager to initialize each secondary.
Page 163
13.7 Group Exercise - HA Step 1: Revisit Planning and Hardware

Exercise Objectives
Understand the computers involved in the Collective.
Problem Description
You need to organise your Collective.
Approach
This exercise makes use of four (4) computers, so you will need to work in pairs. Depending on the size
of the class, the students may be divided into teams. Two (2) computers will be used to establish the PI
Server collective and two (2) computers will be used as the data collector computers. The PI OPC DA
Interface will be configured on two interface computers and an OPC Simulator will be installed on one of
the interface machines.
The AF server used will be the one installed on the same computer as the primary PI Server.
In the table below, please take a few moments to note the computer names or IP addresses for each
computer.
Primary:
PI Servers:
Note:For the purposes of this

course the AF will be installed
here.
OPC
Interfaces:
OPC
Simulator:
Page 164
Secondary:
High Availability
13.8 The Second Interface

The primary interface will be the one originally used by the person with the Primary server. Ensure it is
working and that data is going to the primary server before proceeding any further.
Configure the second interface (on the other persons interface machine) exactly as the first interface,
using the same data source. This will require the configuration of DCOM.
13.8.1 What is DCOM?
From What is DCOM? By Rosemary Rock-Evans
Microsoft's DCOM (Distributed Component Object Model) is based on Microsoft's own COM
(Component Object Model). COM defines how components interact and is an architecture for
simple interprocess communication. It defines a basic model of communication using Microsoft's
equivalent of objects components. DCOM supports the same model of component interaction, but
supports distributed interprocess communication. Thus DCOM is an architecture that enables
components (processes) to communicate across a network.
The PI OPC Interface, like many applications, is a COM application. The OPC Interface
communicates with the OPC Server (data source) through the COM layer. So when the
applications are running on different machines they must use DCOM in this instance COM
over TCP/IP.
Tip
Many people feel that DCOM is inherently unsecure. Because of these

security concerns OSIsoft recommends installing the OPC Interface on
the same computer as the OPC Server. Of course you cannot avoid this
in an HA situation.
Page 165
13.9 Group Exercise - HA Step 2: Second Interface Machine

Exercise Objectives
Preparation for failover exercise.
Problem Description
You need a second, identical interface for the failover scenario.
Approach
Repeat the process with identical settings for the second interface machine (of course you will not have to
build trusts or points as they are already built). The configuration will be identical except for the OPC
Server input on the opcint tab. On the second interface, you will use:
the name of the first interface computer.

On the second interface machine, you will need to configure DCOM. For this, you may need to configure
the identity OPC Simulator process and the logon rights of each interface.
Note: This often involves the following two steps:
1. On the interface machine without the OPC Server: change the log on user for the Interface Service.
Open the Properties of the interface service and set the user to be the administrator.
2. On the interface machine with the OPC Server: Open Start > Administrative Tools > Component
Services and browse to your DCOM Config. In that list will be the OPC Sample Server
(OPCSample.OpcDa20Server). Change the Authentication Level to Connect on the General tab.
On the identity tab configure to use the administrator user as you did on the remote interface.
Use a client tool to verify that you are collecting data for all of the OPC points (Hint: search for points
with a pointsource of OPC).
Once you verify that data is being transmitted to the PI Server STOP THE INTERFACE.
Note that DCOM configuration can get rather complicated. The two steps listed above work in some
cases, but as networks become complicated and security gets tighter more care needs to be taken in
configuration. There is an extensive manual on setting up DCOM that you may refer to:
See the DCOM Configuration Guide for more information on DCOM setup.
Page 166
High Availability
13.10 Interface Failover Defined

To minimise data loss during a single point of failure within a system, many OSIsoft interfaces provide
two failover schemes:
Phase One: synchronization through the data source

Phase Two: synchronization through a shared file.
Tip
Phase 1 is appropriate in two situations: (1) if performance degradation

occurs using the shared file or (2) read/write permissions for the shared
file cannot be granted to both interfaces.
13.10.1 Phase One

Phase 1 UniInt Failover uses the data source itself to synchronize failover operations and provides a hot
failover, no data loss solution when a single point of failure occurs.
For this option, the data source must be able to communicate with and provide data to two interfaces
simultaneously. Additionally, the failover configuration requires the interface to support outputs data is
written back to the data source. This is something that many SCADA people view with apprehension.
Page 167
13.10.2 Phase 2
Phase 2 UniInt Failover uses a shared file to synchronize failover operations and provides for
hot, warm, or cold failover.
The Phase 2 hot failover configuration provides a no data loss solution for a single point of failure similar
to Phase 1. However, in warm and cold failover configurations, you can expect a small period of data loss
during a single point of failure transition.
Page 168
High Availability
13.11 Group Exercise - HA Step 3: Implement Interface Failover

Exercise Objectives
Implement interface failover.
Exercise Description
You have a working interface and a backup interface. You need to make them work together so when one
fails the other takes over.
Approach
Note: There are multiple steps in this approach.
Configure the Shared File
1.
2.
Choose a location for the shared file. The file can reside on one of the interface nodes but OSIsoft
strongly recommends that you put the file on a dedicated file server that has no other role in data
collection. In this classroom, it will be simplest to put it on one of the interface computers.
Setup a file share folder and assign the permissions so that both primary and backup interfaces have
read and write access to the file.
Configure The Interface Parameters

1.
Use the Failover section of the Interface Configuration Utility (ICU) to enable failover and create
two (2) parameters for each interface:
A Failover ID number for the interface.
The Failover ID number for its backup interface.
2. The Failover ID for each interface must be unique and each interface must know the Failover ID of
its backup interface.
Select The Synchronization File Path And File To Use For Failover.
1.
2.
Select the HOT type of failover.

Ensure that the user name assigned in the Log on as: parameter in the Service section of the ICU is a
user that has read and write access to the folder where the shared file will reside.
Note: The first interface to start will create the file.

1.
All other command line parameters for the primary and secondary interfaces must be identical.
Page 169
2.
If you use a PI Collective, you must point the primary and secondary interfaces to different members
of the collective by setting the SDK Member under the PI Host Information section of the ICU.
Configure the Digital State Set / PI points

1.
2.
Right-click on the Digital State point and select Create UFO_State Digital State Set on Server
to create the required digital state set.
Right-click on the points and select Create all points (UFO Phase 2) to create seven (7) PI points
for the interface: the Active ID, Heartbeat1, Heartbeat2, Device Status 1, Device Status 2,
Interface 1 State, and Interface 2 State.
Repeat for the second interface. You will not have to recreate the digital state set or failover points.
Test it
Before you start testing start the Interactive message logging:

pigetmsg f
This file is in \PIPC\ADM folder.
Page 170
High Availability
In order to test that failover is working correctly you will have to have a properly running
interface and then start the second. You should see that interface start and become the
Backup.
Then you can stop the primary interface and you should see the change reflected in each
log file.
Tip
If you have PI ProcessBook you can watch the data on each server and
see that it should not get interrupted.
Page 171
13.12 Collective Manager

Use the Collective Manager to create new PI collectives, configure existing collectives and their servers,
and view the status of collectives.
An icon in the diagram represents each server in the collective. A green check mark on the icon indicates
that the server is communicating properly. A red X indicates that the server is unavailable. A yellow
warning icon indicates that the server is available but has errors. Status and Connection Status show the
associated errors.
Page 172
High Availability
13.13 Group Exercise - HA Step 4: Form the Collective

Exercise Objectives
Learn how to create a collective using the PI Collective Manager
You need to form a Collective by combining two existing PI Servers.
Approach
Install the same version of the PI Server software on the secondary PI Server machine. Start the
secondary server, then add the secondary to primary servers PI Connection Manager. Use the PI
Collective Manager to initialize the secondary.
On each PI Server, use Connection Manager in the PISDKUtility tool to add the PI Servers by their
hostnames or IP Addresses. When you are finished, each PI Server should have both PI Servers in their
respective Connection Manager. Make sure you can see both servers in the SMT and use your PI SMT to
validate that the servers are running.
Once the PI Servers are established, open the PI Collective Manager and establish the collective based
upon your two PI Servers. Run the Collective Manager in Start, All Programs, PI System. Go to File,
Create New Collective, and answer the questions. When asked if the primary is an existing server or a
newly installed server, select A newly installed PI Server.
Whichever PI Server is to become the secondary server will lose all its data and databases.
You will have to perform the following:
Name your collective.

Select the secondary server from the list the collective manager displays.
Select the archives from the primary that you want to replicate to the secondary.
Collective creation may take some time depending on how many archives you elected to copy, and how
fast the network is.
The Collective Manager will:
code the collective formation

backup the primary server
shutdown the secondary server
replicate to the secondary server from the primary server backup
and then restart the secondary server.
When this process is complete, you should see two PI Servers with green check icons.
Page 173
If you do not see these icons, try to Reinitialize the Collective.

You should use the PI Connection Manager to verify that you have a Collective and not two individual
PI Servers.
Tip
Page 174
Create trusts for both primary and secondary PI Server to be able to use
PI-SMT from both machines. Build the trusts on the primary PI Server.
High Availability
13.14 Buffering Mechanisms and Data Replication

Earlier in the course, we learned about the two buffering mechanisms. Buffering is critical to
the HA process because it is the mechanism that fans or replicates the data for each PI
Server in the PI Collective.
The configuration parameters for both buffering mechanisms are shared in a single file and
use similar formats. The PI Buffer Subsystem configuration is achieved through entries in
the file:
\PIPC\DAT\PICLIENT.INI
The most important parameter is the list of PI Servers that need PI API buffering. The server
names must comply with the following rules:
All strings must represent a valid network path. If forward name lookups are
provided by a DNS, use Fully Qualified Domain Names (FQDN). Otherwise, IP
addresses are accepted.
The strings must exactly match the string specified in the /HOST= command-line
parameter of PI Interfaces (usually found in a batch command file). The strings are
case insensitive.
In the case of PI Buffer Subsystem, the PI Servers must all be part of the same PI
Collective. The PI Buffer Subsystem does not support buffering to multiple PI
Collectives and only a single Pibufss instance can run on one machine.
The easiest way to configure the buffering is to use the PI ICU. The PI ICU is simply
configuring the piclient.ini file, so it does not matter if you choose to use that tool or
manually edit the file. All changes require a restart of the buffering subsystem.
13.14.1 PI Buffer Subsystem
These server strings are entered as a numbered list in the PICLIENT.INI file under the
[BUFFEREDSERVERLIST] section. The entries are of the form:
BUFSERVN = PIServerName
where N is an integer starting at 1. The list must be in numerical order (that is, if there is a BUFSERV2,
there must be a BUFSERV1). The exact order of the entries does not matter as long as the numbers are
continuous.
Note: Pibufss does not require the [REPLICATEDSERVERLIST] section in PICLIENT.INI file.
Regardless of settings, the Buffer Subsystem automatically detects the PI Collective configuration. If a
section [REPLICATEDSERVERLIST] exists in the PICLIENT.INI file, Pibufss renames it to
[REPLICATEDSERVERLIST_SAVED] the first time it runs.
The Buffer Subsystem does not need all PI Servers to be specified in the [BUFFEREDSERVERLIST]
section. The minimum number of entries necessary depends on how many different PI Servers are defined
Page 175
after the /HOST= parameter of PI Interfaces (or PI API applications) that require buffering. PI ICU
automates this key step of API buffering configuration.
With the default settings, Pibufss detects the PI Collective configuration and sets up N-Way
buffering to all replicated PI Servers, regardless of how many are defined in the
[BUFFEREDSERVERLIST] section. This behavior is accomplished by setting AUTOCONFIG to
1 in the PIBUFSS section of the .ini file.
Below is an example:
[APIBUFFER]
BUFFERING= 1
[PIBUFSS]
AUTOCONFIG= 1
[BUFFEREDSERVERLIST]
BUFSERV1= S1.DOMAIN.INT
BUFSERV2= S2.DOMAIN.INT
For a complete list of the switches used in each section consult the PI
Buffer Subsystem User Guide.
Caution: Specifying extra PI Servers in the [BUFFEREDSERVERLIST] that are not part of the target PI
Collective results in a fatal error from Pibufss and prevents proper startup. The error is: -11419
Buffering is supported for only one PI Server or Collective.
13.14.2 Testing
Run the command: pibufss -cfg from the PI ICU or from a command prompt window. In PI ICU,
select Tools > Buffering and in the Buffering dialog, select Tools > Buffer Subsystem > Run pibufss
-cfg.
The following output shows the activity on each buffering queue:
--- PIbufss Interactive Mode, Time: 20-Nov-08 15:54:06
Configuration Query, status: [0] Success
*** Validated API servers (bufferedserverlist), count: 2
1 S1.DOMAIN.INT
2 S2.DOMAIN.INT
*** Cached PI server configuration, count: 1
server/collective: HASRV (last update: 20-Nov-08 15:47:05)
serverid: dbe4d7ca-7a9c-4d5d-9b35-14618c0127fe - replicated hosts: 2
1 hostname: s1 (bsl: S1.DOMAIN.INT), role: 1 fqdn: s1.domain.int, id: 209d6f49-8d3d-470d-
Page 176
High Availability
a23e-18a3ebcbb92b
2 hostname: s2 (bsl: S2.DOMAIN.INT), role: 2 fqdn: s2.domain.int, id: 98a80524-9d57-48e48b0e-be9abc28df1d
*** Current buffer sessions, count: 2
1 [s1] state: Registered, successful connections: 1
firstcon: 20-Nov-08 15:46:51, lastreg: 20-Nov-08 15:46:52, regid: 1
events sent: 0, snapshot posts: 0, queued events: 0
2 [s2] state: Registered, successful connections: 1 firstcon: 20-Nov-08 15:46:54, lastreg:
20-Nov-08 15:46:55, regid: 1
events sent: 0, snapshot posts: 0, queued events: 0
Each buffer session should be in the Registered state, which indicates the PI Buffer Subsystem is
connected, authenticated, and successfully registered with the PI Snapshot Subsystem.
A state of Disconnected indicates a failure to connect. A state of Connected could be a transient, or most
likely, a failure to authenticate. Check the PI Trust definition if necessary.
Page 177
13.15 Group Exercise - HA Step 5: Configure N-Way Buffering

Exercise Objectives
Learn how to configure and test n-way buffering.
You have a working interface writing data to a single PI Server. You need to have the data replicated
across your PI Servers in the Collective.
Approach
1. Start the interface on the first machine. Does it connect to the collective?
2. Verify that data is being collected.
3. On this interface machine, configure the PI Buffer Subsystem, using the PI ICU and
selecting Tools>Buffering.
4. Enable buffering with the PI Buffer Subsystem.
Once the mechanism has restarted the service and finished, select Buffered Servers, and then
select your collective from the drop-down menu. Make sure all the servers in your collective are
Page 178
High Availability
listed and checked.
5. If either the PI Buffer Subsystem or the interface is running, stop them. At this point make sure
that the PI OPC Interface has a dependency set for Pibufss. Start the PI Buffer Subsystem and
then start the PI OPC interface
Note: Remember, the buffer mechanism must start before the interface.
6. Check the log files for any errors or problems.
7. The points should be generating data. Open a command prompt and navigate to the
\PIPC\bin\ folder and enter: pibufss -qs
This will give you statistics on the Buffer Subsystem.
8. Stop the interface and repeat the process on the second interface machine.
Only proceed once you can validate that each PI OPC

Interface and PI Buffer Subsystem combination are working
correctly.
Page 179
Page 180
High Availability
13.16 Group Exercise - HA Final Step: The Road Test

Exercise Objectives
Test your High Availability PI System.
You think you have everything running correctly. Prove it. Test the system to make sure all
of the failover and redundancy solutions are working.
Approach
Perform any or all of the following actions:
1.
Install PI ProcessBook (if it is not already installed) and create a trend against the collective. Be sure
to use your OPC points. Force a failover in the Connection Manager in PI Processbook. Verify that
both PI Servers are broadcasting live data for the same point.
2.
One of the interface active points (INTF_1_State) should have a value of primary and the other
(INTF_2_State) should have a value of backup. Create another trend and add these points to it.
You may also want to add the heartbeat points.
3.
Using the PI SMT tool, add a random point to the collective by copying CDT158 to CDT69 on the
primary server. Returning to PI ProcessBook, failover as necessary until you are connected to the
secondary server. Use PI Tag search to verify that CDT69 exists on your secondary server. Using
the connections box reset your PI ProcessBook session to use the Primary PI server.
4.
Shut down the Primary PI Server (using \pi\adm\pisrvstop.bat).

Is your PI ProcessBook trend active? Did it switch connections?
Check \PIPC\bin\pibufss -qs on the primary interface computer (the one that has that
status in the active points) is the data for the Primary Server queuing?
Try to add another Random point. Can you do it?
Check your Collective Manager on the secondary server what does it show?
Restart the Primary PI Server
5.
Shutdown the Secondary PI Server

Is your PI ProcessBook trend active? Did it switch connections again? Did the Primary PI Server
lose data while it was down, or did the buffer work?
Check \PIPC\bin\pibufss -qs on the primary interface computer (the one that has that
status in the active points) is the data for the Secondary Server queuing?
Try to add another Random point. Can you do it?
Page 181
Check the Collective Manager on the primary server what does it show?
Restart the Secondary PI Server
Switch PI ProcessBook back to the secondary server or use PI SMT did the Secondary Server
pickup your new Random point? Did the buffer work for the Secondary PI server such that you
did not lose data?
6.
Stop the Primary Interface (with the ICU or System Services Applet)
Did the other interface pick up data collection properly? Do you have updates in PI ProcessBook?
Do the Interface Status and Heartbeat points look appropriate?
Check the PI Message logs on the interface computers using the PISDKUtility
Check pibufss -qs on the secondary Interface (now with the primary status). Is it processing
data for both servers?
Restart the Primary Interface and check for a good start.
7.
Stop the Backup Interface (with the ICU or System Services Applet)
Did the other interface pick up data collection properly?
Do you have updates in PI ProcessBook?
Do the Interface Status and Heartbeat points look appropriate?
Lastly, restart the Backup Interface. Validate that both PI Servers and both interfaces are running
correctly.
Page 182
High Availability
13.17 Group Recap Question - High Availability Debriefing

The following questions are intended to reinforce key information presented in this
chapter or section.
Review the components of High Availability.

Answer the following:
1.
Using PI ProcessBook, how would you determine if all PI Servers in your collective are up and
functioning properly?
2.
On the PI Server, how would you validate that replication is occurring?
3.
How would you test that N-Way buffering is working?
4.
Explain the difference between UniInt Failover Phase 1 and Phase 2.
Page 183
14. High Availability and Complex Architectures

Servers in a collective can reside on different networks and communicate through firewalls.
Some scenarios are:
Server Farms
Process Control Network / Corporate Network
Geographical
PI AF Server
Secondary
PI Server
Primary
PI Server
`
Client PC
Interface
Interface
Active
Directory
The ideal situation is where there is one domain (or trusted domains) where all of the machines in the
domain, including the PI Server and interfaces, can see each other. There are no issues with name
resolution or security authentication. If PI AF Server is in the office/corporate network, both domains
trust each other.
Page 184
High Availability and Complex Architectures
Secondary
PI Server
Primary
PI Server
Client PC
PI AF Server
Interface
Interface
Active
Directory
In a more complex example, the Secondary PI Server and the Interfaces are in a Process Control Domain /
Workgroup. The PI System uses N-Way buffering to send data outside that structure to a Primary PI
Server on a Corporate Domain. The users can see the Primary PI Server and PI AF but cannot see the
Secondary PI Server or interfaces.
This situation will present issues of authentication between the PI Servers for replication and issues for
the interfaces and N-way buffering. The firewalls will have to be set correctly and perhaps host files set
in the Process Control network so the machines can access the Primary PI Server.
Users may not be able to be resolved across PI Server members.
Page 185

`
Primary
PI AF Server
Secondary
PI AF Server
`
Client PC
Client PC
Primary
PI Server
Secondary
PI Server
Interface
Interface
Active
Directory
Active
Directory
Above, in the more complex example, there are multiple domains involved, and none of them can see
each other. This will present significant routing and security challenges. It is maybe required to have PI
AF Collective so that every client will have access. In the worst-case scenario, the PI Servers will have to
be synchronized manually. These topics are discussed below.
14.1 Managing Archives on Replicated Servers

Secondary PI Servers that have archives in the same directory structure as the Primary PI Server are easy
to manage. The registration of the archives moves with the files that are part of the initializing or reinitializing. However when a Secondary PI Server has archives in a different location, you must register
them manually to make them available.
It is possible to place archive files on a Storage-Area Network (SAN) drive. If multiple PI Servers mount
the archives, they should be on a read-only partition. This can be useful if you have many old archives
and you wish to allow multiple servers in the collective access to them. Archive shifts on different PI
Servers are not synchronized. Archive Shifts can and do happen at different times on each PI Server in the
collective. This increases the availability of the archive data because a shift that takes a long time or fails
on one PI Server still leaves the other servers available to receive and serve data. One side effect of this is
that an archive cannot be moved from one server to another server easily.
14.2 Disconnected Startup

UniInt Interfaces include the functionality to take advantage of the Disconnected Startup operation.
Disconnected startup allows the interface to start from a local cache file with or without a valid
Page 186
connection to the host PI Server. This prevents data loss when an interface needs to start up and it does
not have a connection to the PI Server.
Using the disconnected startup feature when a PI Server connection is available bypasses potentially long
delays caused by the latency in network calls required to gather point information from the PI Server,
which in turn delays the ability of the interface to begin data collection from the Data Source. Using
disconnected startup will improve interface startup time, especially when large point counts are being
used.
The first time the interface is started with the disconnected startup parameter set, a connection to the PI
Server is required to populate the cache files with the necessary data to support the disconnected startup
feature on subsequent interface restarts. The time to startup will be delayed while the cache files are
created. They contain the required PI Server version, PI point configuration, and Digital State information
needed to start the interface. Once started, the interface can actively collect and buffer data retrieved from
the Data Source when no connection to the host PI Server is available.
Page 187
14.3 Changing the Collective Hierarchy

The PI Collective hierarchy is simply an entry in the PISERVER and PICOLLECTIVE tables within each
of the PI Server internal databases forming the collective.
Each server knows of its place in a collective because of its role. There are three possible roles:
0 = stand-alone PI Server;
1 = Primary PI Server;
2 = Secondary PI Server.
The PI Collective Manager is used to write these parameters into the internal databases of each PI Server
in the collective.
Page 188
14.4 Exercise Change the Primary PI Server

Exercise Objectives
Learn to reconfigure the Collective
Problem Description
You want to be prepared if you Primary PI Server is ever destroyed. You need to be able to
promote a secondary computer to Primary.
Approach
Note: You cannot do this exercise using Collective Manager. You must use the command line utility
piartool.exe on each server.
1. Stop the Primary PI Server by running pisrvstop.bat. DO NOT shutdown the machine, since PI AF
Server lives on the same machine.
2. Promote the secondary computer with the console command:
piartool -sys -promote
3. In the Collective Manager on the new Primary, confirm the new configuration.
Page 189
Start you old Primary PI Server and re-initialise from the new Primary PI Server.
Note: You will need to clear your Know Servers table. What is the best way to do this?
Hint: Recreate?
14.5 Untrusted Domain Issues

The PI HA Collective is designed to operate with a single domain or trusted domains where fully
qualified name resolution functions across domains.
Issues arise when PI Collective members are in different, untrusted domains.
14.5.1 Collective Creation and Initialization
The Collective Manager has to have Windows file copy access and FQDN resolution between members
of a Collective to function. For the case of untrusted domains, form the collective manually on each PI
Server manually by using the piconfig command.
To initialize manually:
1. Backup the Primary PI Server.
2. Copy all of the files to the Secondary.
3. Restore the Secondary.
Page 190
This process must be repeated each time a change is made to the Primary PI Server.
14.5.2 Security
Usually all Collective members have a common user database the domain(s) Active Directory. In some
cases, users may be desired on a PI Server in a Collective that are not exposed to all members of the
Collective. This commonly occurs when one of the PI Servers has a local user or the Collective members
are in different domains.
One solution is to create the user on the Primary PI Server; then tell the server and the members that
cannot resolve the name to ignore that user. Tell the members to ignore that user by setting the tuning
parameter Base_AllowSIDLookupFailureForMapping to 1 on each Collective member. This change
requires restarting the PI Base Subsystems on each member.
Note: This must be done on each member because tuning parameters are not replicated between servers.
Note: This tuning parameter is not exposed by default. You will have to enter it into the name field. It
will show an error (yellow text box background) until you get the full name complete and correct.
If the user is known to the Primary PI Server, then simply add that user and let it replicate. If you set the
tuning parameters correctly, then the only behavior you will observe is that a User SID will appear in the
Security tables on secondary nodes.
Page 191
If the user is not known to the Primary PI Server, determine the User SID on the Secondary. This can be
accomplished in a number of ways; perhaps the easiest is to use the Sysinternals command line utility
psGetSID.
Note: Windows Sysinternals suite of tools is a free Microsoft Technet suite of utilities that can be
downloaded from the technet site. Visit http://technet.microsoft.com and search for the phrase
sysinternals.
Once you have the SID for the user or group, you must add an identity to the Primary PI Server that is
that SID. When this is replicated to the proper secondary node, the user or group name should appear in
the list of identities.
Page 192
14.6 Exercise Add a Local User to a Secondary Node

Exercise Objectives
Learn to add local (non-domain or cross-domain) users.
Problem Description
Your servers are in different domains. You need to add users to a secondary server, but
adding users to the secondary server in a Collective is not allowed. Add the user to the
Primary and let it replicate. Handle the fact that the primary computer will complain that is it
not a valid or irresolvable user.
Approach
1. Set your tuning parameters to ignore name lookup failure
(Base_AllowSIDLookupFailureforMapping). Restart pibasess on the servers.
2. Add a local Windows user account to your secondary PI Server. Use the Sysinternals psGetSID.exe
application to determine the SID of that user on the secondary PI Server.
3. Do one of the following:
On the Primary PI Server, add that SID to the PIIdentMap table using piconfig:
@mode create
@tabl PIIdentMap
@istr IdentMap, Principal, PIIdent
<<Data goes here>>

Where IdentMap is the name of the mapping (example: MyMapping1), the Principal is the User SID, and
PIIdent is the name of the PI Identity you want to map to.
- OR On the Secondary PI Server, add the mapping for the local user to the Primary Security
Configuration in PI SMT.
4. Validate on the secondary PI Server that the Identity is resolved correctly.
Page 193
15. The PI to PI Interface

The PI to PI interface copies point data from one PI Server to another. Data is moved in one
direction, meaning data is copied from the source to the receiving PI Server (also referred to
as target PI Server).
15.1 To Push or To Pull

The PI to PI interface is said to push or to pull data based on whether you run the
interface on the Source PI Server or the Target PI Server.
Interface
Source
PI Server
Target
PI Server
The PI to PI Interface in a Pull configuration.
Source Interface
PI Server
The PI to PI Interface in a Push configuration.
Page 194
Target
PI Server
The PI to PI Interface
15.2 What Kind of Data Collection?

The PI to PI Interface has the capability of running in a history recovery only mode (Archive
Data) or the live tag data as it is received on the Source PI Server (Snapshot Data).
Whats the big difference between the two? Compression.
In normal (Snapshot) mode, the interface acts much like PI ProcessBook or any other client
would, and signs up with the Source PI Server, and all new values are queued and sent to the
Target PI Server.
In history recovery only mode (Archive), the interface will periodically (based on the scan
rate) read the values for the points from the archive on the Source PI Server and send those
values to the Target PI Server.
For more information, see "Data Collection" in PI to PI TCP/IP Interface,

version 3.8.5.
15.3 Identical Data, Identical Points?

While the data is identical for the points, the Source PI Server is collecting the data from the
device and the Target is not. This means that any of the interface specific point attributes will
have to be adjusted accordingly.
This is primarily:
Point Source
Location Codes
InstrumentTag
For more information, see "PI Point Configuration" in PI to PI TCP/IP

Interface, version 3.8.5.
Page 195
This page intentionally left blank.
Page 196
Appendix A Ports
Appendix A Ports
You will of course, have to open certain network ports for the applications to communicate.
The following ports may need to be opened on a firewall to allow access to PI or other
associated services. This information is found under OSIsoft Technical Support
Knowledge Base article # 2820OSI8.
Port: Service - Comments:
---------------------------------------------------------------------------------------44: WINS - Windows name resolution
---------------------------------------------------------------------------------------53: DNS - Name resolution
---------------------------------------------------------------------------------------80: HTTP, HTTPS, SharePoint - for PI WebParts, iViews, PI Coresight
---------------------------------------------------------------------------------------88: Kerberos - Windows 2000, XP authentication
---------------------------------------------------------------------------------------123: NTPNetwork - Time protocol, for clock synchronization
---------------------------------------------------------------------------------------135: DCOM port mapper - Windows authentication, DCOM applications including OPC.
Port is high risk and is usually blocked
---------------------------------------------------------------------------------------137: NETBIOS Name Service - NetBIOS name resolution. Ports 137:139 are considered
high-risk and are usually blocked.
---------------------------------------------------------------------------------------138: NETBIOS Datagram Service - Ports 137:139 are considered high-risk and are usually
blocked.
---------------------------------------------------------------------------------------139: NETBIOS Session Service - Ports 137:139 are considered high-risk and are usually
blocked.
---------------------------------------------------------------------------------------389: LDAP
---------------------------------------------------------------------------------------443: HTTPS and SSL for websites running for PI WebParts
---------------------------------------------------------------------------------------445: MS Windows port for accessing administration shares, services, other Microsoft
resources, and for initialising a collective.
---------------------------------------------------------------------------------------636: LDAP SSL.
---------------------------------------------------------------------------------------1433, 1434: MS SQL Server (From: http://technet.microsoft.com/enus/library/ms175483.aspx
and see Configuring the Windows Firewall to Allow SQL Server Access from:
http://msdn.microsoft.com/en-us/library/cc646023.aspx.), possibly for iViews and PI
Page 197
WebParts.
---------------------------------------------------------------------------------------1521: Oracle SQL*Net, for iViews and PI WebParts
---------------------------------------------------------------------------------------3268: LDAP GC
---------------------------------------------------------------------------------------3268: LDAP GC SSL
---------------------------------------------------------------------------------------3389: Windows Remote desktop - Remote desktop for PI server administration
---------------------------------------------------------------------------------------5450: PI Network Manager (subsystem of the PI Server)
---------------------------------------------------------------------------------------5454, 5455: PI Analysis Framework (PI AF 1.x)
---------------------------------------------------------------------------------------5456: PI ACE - Used by PI ACE 2 scheduler to allow connections from the PI ACE Web
Service
---------------------------------------------------------------------------------------5457: PI PI Asset Framework (PI AF)
---------------------------------------------------------------------------------------5458: PI Notifications
---------------------------------------------------------------------------------------5459: PI OLEDB Enterprise, PI JDBC Driver
---------------------------------------------------------------------------------------5459: PI AF 2.x HA Collective status, PI WebParts, and PI Web Services, PI Coresight
---------------------------------------------------------------------------------------5461: PI JDBC Driver - Used by to allow connections to the PI SQL Data Access Server
April 2012
Page 198

PI System Architecture, Planning and Implementation Workbook

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

PI System Architecture, Planning and Implementation Workbook

Uploaded by

Copyright:

Available Formats

PI System Architecture, Planning and

Copyright: 1992-2012 OSIsoft, LLC. All rights reserved.

PI System Architecture, Planning and Implementation

Course structure ........................................................................................ 9

Why PI? (What problem are you trying to solve?)................................... 9

What is a PI System? ............................................................................... 10

Directed Exercise Assets Defined ........................................................ 13

Directed Exercise Data Types .............................................................. 15

Data Flow through the PI Server ............................................................. 16

Data Flow: From The Source To The PI Archives................................... 18

Data Flow: Block Diagram From Interface To PI Server ......................... 19

1.10 Data Flow on the Interface Computers.................................................... 20

PI System Environment Architecture ............................................................... 28

What is PI? ............................................................................................... 28

Group Exercise Categorize Your Users ............................................... 30

Interface Computers ................................................................................ 31

Group Exercise Discover the PI System .............................................. 32

PI Server + AF Server = PI System .......................................................... 34

Back to the Data - What Do Your Users Require? .................................. 36

2.10 Group Exercise Know Your Users, Their Data..................................... 37

PI Server Requirements .................................................................................... 44

Minimum Operating System .................................................................... 44

Prerequisite Kits ...................................................................................... 44

Hardware Sizing ....................................................................................... 46

PI System Planning ........................................................................................... 49

PI Server High Availability ....................................................................... 49

Interface Failover ..................................................................................... 49

Routing Time-Series Data through a Firewall ......................................... 50

Security Part 1: Planning ......................................................................... 51

Securing the Environment and the Server.............................................. 52

Directed Activity Active Directory Roles.............................................. 53

What about Ports? ................................................................................... 54

Calculation Options ................................................................................. 55

Adding components as needed............................................................... 58

When You Need To Bet Your Business On PI......................................... 59

Group Questions Planning and Preparation Stages: Wrap Up ............ 62

Installing the Servers ........................................................................................ 63

License File Activation ............................................................................ 64

Group Exercise - HA Step 1: Planning and Hardware ............................ 67

Solo / Group Exercise Explore the AF documentation........................ 68

Solo / Group Exercise Install the PI AF Server .................................... 69

Solo / Group Exercise Install the PI Server .......................................... 70

Directed Exercise Explore the PI Server Directory Structure ............. 71

6.10 Solo / Group Exercise - An Exploration of the PI Server Subsystems .. 73

PI System Navigation ........................................................................................ 78

PI System Navigation basics ................................................................... 78

Directed Exercise Connect to a PI Server ............................................ 79

Directed Exercise More PI SMT Plug-ins.............................................. 81

Time and the PI Server............................................................................. 82

Directed Activity Viewing Your Data .................................................... 82

Directed Activity PI ProcessBook ......................................................... 83

Daylight Savings Time ............................................................................. 84

Group Recap Questions .......................................................................... 87

Find Points using Tag Search ................................................................. 88

7.10 Directed Exercise Point Search........................................................... 90

PI System Architecture, Planning and Implementation

7.11 Exercise Data Section in the PI System Management Tools............... 93

Understanding the Common Setup of PI Interfaces ...................................... 107

The Interface Defined............................................................................. 107

Directed Activity Whats Installed ...................................................... 108

Interface Installation Considerations .................................................... 109

Directed Activity Interface Syntax Dissected..................................... 111

Creating and Managing Points ....................................................................... 112

PI Point Attributes and Interfaces ......................................................... 113