Supported features

The following features are supported in the PI to PI Interface:

* See paragraphs below for further explanation.

** For more information, see the "OMF Health Messaging" topic in the Introduction to PI Universal Interface.

APS Connector

AutoPointSync is an AVEVA product that synchronizes the point configuration of PI Data Archives. The PI to PI APS Connector is required to use APS with this interface.

Note: The PI to PI APS Connector contains a separate implementation of the procedure to identify the source point for an interface point. If an interface instance is registered with APS, consult the PI to PI APS Connector manual to confirm that the PI to PI APS Connector version implements the same procedure as the interface, which is required to ensure that the PI to PI APS Connector synchronizes with the same source point as the interface. For a detailed explanation of how the interface identifies source points, see How the PI to PI Interface finds source points.

Supports questionable bit

The interface copies questionable bit data for a given source point from one PI Data Archive to another.

Maximum point count

The interface does not enforce a hard-coded maximum for the number of points it can maintain, but it is a single-threaded process and its performance is affected by hardware, network conditions, and workload. For recommendations about optimizing interface performance, see Performance considerations. For details about monitoring interface performance, refer to the Introduction to PI Universal Interface.

Source of time stamps

The source PI Data Archive provides a time stamp for each data event. The interface can also adjust time stamps for clock drift, which is the time offset between PI Data Archives after accounting for time zone differences. An offset of 15 minutes or less is considered clock drift. Adjusting for clock drift means the time offset is added to the source time stamp, adjusting it to target PI Data Archive time. Time stamp adjustment for individual points is configured using the Location2 point attribute. Interface nodes and the source and target Data Archives must have the correct system time for their time zone.

History recovery

History recovery enables you to recover archive data for time periods when the interface was not running or otherwise unable to collect data. History recovery is performed on startup, after restoring a lost Data Archive connection and after a disruption in exception data collection. In addition, when a new point is added to the interface, history recovery is performed on that point. The history recovery period is configurable. The default is to recover data for the previous 8 hours. To disable history recovery, set the time Maximum hours of history to recover /RH command line parameter equal to 0. You can also recover data for a specified time period. If you specify a start and end time, the interface recovers data for the specified period, then exits.

UniInt-based

UniInt stands for Universal Interface. UniInt is not a separate product or file; it is an AVEVA-developed template used by developers and is integrated into many interfaces, including this interface. The purpose of UniInt is to keep a consistent feature set and behavior across as many of AVEVA's 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 parameters and some interface-specific parameters. UniInt is constantly being upgraded with new options and features.

For more information, see the Introduction to PI Universal Interface on our documentation portal.

Disconnected Start-Up

The PI to PI interface is built with a version of UniInt that supports disconnected start-up. Disconnected start-up is the ability to start the interface without a connection to the Data Archive. This functionality is enabled by adding /cachemode to the list of start-up parameters or by enabling disconnected startup using the ICU. Refer to the Introduction to PI Universal Interface for more details on UniInt disconnected startup.

Enabling disconnected start-up not only creates cache files for the target PI server, but also for the source PI server with the following format: exename_hostname_id_dgcache.dat and exename_hostname_id_ptcache.dat

Note: If you are running multiple instances of the pitopi interfaces, We recommend that you use individual folders to create cache files for each instance to enable the various instances to access the cache files exclusively without any access violations.

SetDeviceStatus

The health point with the point attribute ExDesc = [UI_DEVSTAT] represents the status of the source device. The following events can be written into this point:

• 1 | Starting: The interface is starting.

• Good: The interface is properly communicating and reading data from the server. The following events indicate a failure to communicate with the server:

• 3 | 1 device(s) in error | Network communication error to source PI server

• 3 | 1 device(s) in error | Unable to get archive data from source PI server

• 3 | 1 device(s) in error | Unable to obtain snapshot events from source PI server

• 3 | 1 device(s) in error | Unable to register for snapshot updates on source PI server

• 4 | Intf Shutdown: The interface is stopped.

Refer to the Introduction to PI Universal Interface for more information about how to configure health points.

Failover

• Source PI Data Archive-level Failover Support

  Source PI Data Archive-level failover maximizes interface data availability on the target Data Archive(s). It enables the interface to obtain data from one of two source Data Archives. Each source server must have identical point definitions and data streams for interface source points. The interface initiates failover if the active source data becomes stale or is not available due to network issues.

• UniInt Failover Support

  UniInt Phase 2 failover provides support for cold, warm, or hot failover configurations. The PI to PI Interface only supports warm failover. In warm failover configurations, you can expect a small period of data loss during a single point of failure transition. This failover solution requires that two copies of the interface be installed on different interface nodes with the primary collecting data and the backup interface available on failure. Phase 2 failover requires each interface have access to a shared data file. Failover operation is automatic and operates with no user interaction. Each interface participating in failover has the ability to monitor and determine liveliness and failover status. To assist in administering system operations, the ability to manually trigger failover to a desired interface is also supported by the failover scheme. The failover scheme is described in detail in the Introduction to PI Universal Interface.