General Interface Principles

For the most part, this section discusses general interface principles that apply to interfaces running on Windows, UNIX, and VMS. If a particular topic in this section applies to a particular operating system, then this is mentioned up front. For example, interfaces can only use the PI Software Development Kit (PI-SDK) on Windows, but the PI-SDK is such a fundamental part of the PI System that it is discussed under general principles.

5.2.1 About PI Interfaces

PI interfaces are software modules for collecting data from any computing device with measurements that change over time. Typical data sources are Distributed Control Systems (DCSs), Programmable Logic Controllers (PLCs), OPC Servers, lab systems, and process models. However, the data source could be as simple as a text file. Most interfaces can also send data in the reverse direction, from PI to the foreign system.

Typically, interfaces use the PI Application Programming interface (PI API) to retrieve configuration information from the PI Server and to write data to the PI Server. Many interfaces also use the PI Software Development Kit (PI-SDK) to retrieve configuration information from the PI Server and to create PI Points, Digital States, etc. A handful of interfaces use the PI-SDK to write batch data to PI, the most notable of which is the PI Batch Generator interface (PIBaGen). The PI API and the PI-SDK are described in more detail below.

Most interfaces written by OSISoft are written using UniInt, OSISoft’s so-called Universal Interface. UniInt performs many tasks that need to be performed by most interfaces such as loading points, parsing command line, arguments, scheduling scans for data, etc. As a result, most OSISoft interfaces have a common set of features that are configured in the same way. UniInt uses the standard PI API and the PI-SDK to write and read data from the PI Server. Although UniInt itself is not publicly available, customers could use the PI-SDK and PI API to write their own custom interfaces that do the same tasks as UniInt.

5.2.2 About PI Interface Nodes

A PI Interface Node is a computer that runs one or more interfaces to collect data from a foreign system and send that data to a PI Server. The Interface Node might be a computer that is a part of the foreign data system, such as a Foxboro AW51 workstation; it might be a stand-alone dedicated interface computer; or it might be the PI Server itself.

Typically, you should avoid running interfaces on the PI Server node. Running interfaces on a separate node allows the PI Server to be taken down for maintenance while data is still collected and buffered on the Interface Node. Also, you do not want interfaces competing for computer resources with the PI Server. As discussed later in this document, there are a few interfaces that are intended to run on the PI Server, but these interfaces are the exception. From an administrative standpoint, the best thing about PI Interface Nodes is that they are typically configured once, backed up, and then left to run indefinitely without human intervention. Exceptions to this include software upgrades, security patches, network infrastructure changes, and some configuration changes driven by a change in the foreign data system. Interface nodes are the first line focus for data reliability and availability, so user interaction with interface nodes is usually restricted to PI system administration only.

5.2 - General Interface Principles

Interface Nodes on VMS

An Interface Node on an OpenVMS-based VAX or Alpha computer is also known as a PINet

Node. PINet is a stripped-down version of a PI 2 server. PINet does not contain a data

archive, but it does contain a local Snapshot Subsystem and a local point database. In addition, PINet provides utilities to access the point configuration information and data that reside on the PI Server. PINet automatically buffers data when it cannot connect to the PI Server. PINet sends data to PI over a TCP/IP connection.

PIonPINet is similar to PINet in that it is a subset of PI that runs on OpenVMS. PIonPINet includes all of the functionality of PINet. In addition, it includes analysis, reporting and graphical display utilities.

5.2.3 About Data Buffering

Data flow from a typical interface to the PI Server can be summarized by the following diagram.

When buffering is enabled, the data flows through the interface to the buffering service and from there to the Snapshot Subsystem on the PI Server. On Windows and UNIX interface nodes, data is buffered with the bufserv service, which must be installed and configured separately from the interface. On VMS, data buffering comes built-in with the interface node. The above diagram shows the buffering application sending data to only one PI Server node. As of PI API version 1.6, buffering supports collecting data from one interface and

distributing the data to multiple PI Servers. On VMS Interface Nodes, buffering supports data sends to one PI Server only.

Some interfaces do not require buffering because the data source itself is buffered. For example, the Batch File Interface and the Event File interface do not require buffering. The interface-specific documentation should be consulted to see if your interfaces require buffering.

If the PI Server is not available for some reason (such as an upgrade on the Server) then the data is stored in a file buffer on the Interface Node. The size of the file buffer is configurable (up to nearly 2GB on Windows and UNIX). When the PI Server becomes available again, the buffering application sends all the stored data from the buffer, in chronological order, back to

the PI Server. If you then look ProcessBook, for example, your data appears as a continuous flow of data, with no gaps.

5.2.4 About the PI API

The PI Application Programming Interface (PI API) is a library of functions that allow you to read and write values from the PI Server, and also let you retrieve point configuration information. OSIsoft has used the API to create interfaces that run on a variety of platforms. The PI API also provides the ability to buffer data that is being sent to PI. This allows PI to be taken offline for software or hardware upgrades without compromising data collection. When PI becomes available again, the buffered data are then forwarded to PI.

API Nodes are UNIX or Windows workstations that run programs such as interfaces that are

based on the PI API. In practice, the term “API Node” is sometimes used as a synonym for “Interface Node”, because historically, most interfaces are API based. This document does not use the term “API Node”.

You can call PI API from C, Visual Basic, or other languages. A complete list of supported platforms and functions is available in the PI API Manual.

5.2.5 About the PI SDK

The PI Software Development Kit, (PI-SDK), is an ActiveX in-process server that provides COM access to OSI historians. The product provides an object-oriented approach to interacting with PI systems in contrast to the procedural methods used in the PI API. The PI-SDK can only be installed on Windows. Only interfaces that run on Windows can take advantage of the functionality provided by the PI-SDK. All interfaces written for UNIX or VMS must use the PI API exclusively for all communication with the PI Server.

Some interfaces use the PI-SDK because certain functionality is not provided via the PI API. For example, the PI-SDK allows interfaces to create points, digital sets. Also, any interface that writes batch data to PI, such as the PI Batch Generator Interface (PIBaGen), must use the PI-SDK to write its data.

Any data that is written to PI via the PI-SDK is not buffered via the bufserv service. For this reason all interfaces write time-series data to the PI Server via the PI API.

Interfaces that connect to the PI Server with both the PI-SDK and the PI API must maintain two separate connections to the PI Server.

5.2.6 About UniInt-Based Interfaces

There are hundreds of different PI interfaces and each interface is fully documented in its own dedicated manual. However, most interfaces are based on UniInt therefore share a common set of features.

UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an OSIsoft- developed template used by the OSI developers, and is integrated into many interfaces. The purpose of UniInt is to keep a consistent feature set and behavior across as many of our interfaces as possible. It also allows for the very rapid development of new interfaces. In any UniInt based interface, the interface uses some of the UniInt supplied configuration