Those familiar with PI programming in the 1990s have become accustomed to the PI Application Programming Interface (PI-API). The PI-API is a library of routines that provides programmatic access to PI Servers running on any of the supported server platforms. It can be called from UNIX, VMS, 32-bit
and 64-bit Windows platforms. There are versions of the PI-API available for other less popular or older operating systems as well.
Historically the PI-API has been a key middle-tier product enabling consistent communication between OSI's client programs (instrument system interfaces and client applications) and the PI Servers.
In choosing to develop another programmatic interface to PI Systems, there were several driving factors:
The development of the PI3 Server introduced new features that were not factored into the original API design. These features included new archived data types, higher precision time formats, user-defined point classes, user-defined attributes, and long attribute strings.
With larger numbers of smaller systems being installed, there was an increasing need for easy-to-use graphical PI System management applications that could be run remotely.
Embedding VBA in PI ProcessBook and many other end-user tools has expanded the ability of users to customize their application environments. Straightforward access to a system's features through Visual Basic
for Applications (VBA) and common programming languages is expected behavior.
The growing number of components and features of the PI Server added to the complexity of determining the proper PI-API calls to make. Extensions to existing calls created confusion and added to the complexity.
Legacy code prevented the correction of questionable PI-API behaviors. For example, functions returning non-unique error codes made interpretation and documentation difficult.
The PI-API was built to be used in a single-threaded environment and did not consider thread safety or reentrancy. Programs intended to run on multi-processor systems or designed to support multiple concurrent threads of execution had to be programmed to prevent calling the PI-API simultaneously from different threads.
Emerging programming environments and interaction models were demanding consideration: component programming using ActiveX controls;
event driven programming; and components designed for access through the World Wide Web.
The market for programs and program development is increasingly focused on Microsoft platforms.
These factors led to designing a new programmatic access tool with the following objectives:
Provide an easy-to-understand model for accessing PI Systems
Tailor the tool for use with the most common and accessible programming environments
Provide access to new features and capabilities
Expose functionality to support administrative tools
Provide a tool with documentation and examples instantly available during the programming process using an integrated help facility
Provide a tool that works well with new programming models: controls, events, and Web access
Address legacy problems with the PI-API: threading issues; error codes
Support the Microsoft 32-bit and 64-bit platforms
Eventually replace the PI-API as the core PI data access tool for OSIsoft products and interfaces