Introduction
In modern SCADA and historian environments like AVEVA PI System, data reliability isn't optional — it's a core requirement. Even a few minutes of lost process data can affect operational decisions, regulatory compliance, and long-term production analysis. That's why redundancy is one of the most critical design considerations when implementing PI System in industries such as oil & gas, geothermal, power generation, and manufacturing.
Redundancy in PI System is applied in layers: at the data source (OPC Server), the acquisition path (PI Interface), and the storage layer (PI Data Archive). This article summarizes each layer, along with key design considerations and best practices.
1. OPC Server Redundancy
OPC Server bridges field devices (PLC, DCS, RTU) with upstream systems. Since it's often the sole gateway for data, its failure can cut off data flow entirely — not just to PI System, but to any dependent application (HMI, SCADA, alarms).
Common approaches:
- Hot standby (active-passive): the primary server handles all traffic while the secondary stays synced and ready to take over on heartbeat failure.
- Redundant pair with shared subscription: both servers connect to the same source in parallel; the client (PI Interface) switches based on data quality/health status.
Key considerations: OPC UA has a more standardized redundancy model (Redundant Server Set, Part 5) than classic OPC DA, which relies on vendor-specific implementations. Failover detection timing must be tuned to avoid false failovers from brief network jitter, and both servers must have identical tag/scan-rate configuration to keep data consistent after a switch.
2. PI Interface Failover
PI Interface pulls data from the OPC Server and sends it to PI Data Archive. If it fails — due to a process crash, host failure, or network issue — acquisition stops even if the OPC Server and PI Server are healthy.
AVEVA's standard mechanism is UniInt Interface Failover, with three schemes:
Implementation notes: configure the failover pair via the Interface Configuration Utility (ICU), using dedicated failover control and heartbeat tags. Primary and backup interfaces should run on separate physical/VM hosts to avoid a shared single point of failure, and PI Buffer Subsystem (PIBufss) should remain active on each node to prevent data loss during transitions.
3. PI Server High Availability (PI Data Archive Collective)
At the storage layer, PI System uses a PI Data Archive Collective — a set of PI Servers (members) holding synchronized, identical copies of data. One member is primary; the rest are secondary.
Key characteristics:
- Automatic replication of incoming data from primary to all secondary members, near real-time.
- Automatic client failover — PI SDK/AF SDK/PI Web API clients (PI Vision, DataLink, ProcessBook) reconnect to another member automatically if the primary becomes unreachable.
- Built-in disaster recovery, especially when members are placed at geographically separate sites.
Design considerations: at least two members (primary + one secondary) for basic redundancy, three or more for tolerance against multiple failures. PI Web API High Availability requires its own licensing consideration separate from the PI Data Archive Collective license — worth confirming with AVEVA/reseller early in the design phase. All members need precise time sync (NTP), and where data is replicated via OMF into a PI Collective, Kerberos Constrained Delegation must be configured correctly to avoid authentication failures.
4. Designing Redundancy as One End-to-End Chain
These three layers should never be designed in isolation — a failure at any single point shouldn't compromise the whole system:
Best practices: eliminate single points of failure in supporting infrastructure (network, power, virtualization hosts), not just applications; test failover regularly, not just during FAT/SAT; document failover procedures with clear real-time health indicators in HMI/PI Vision; and weigh the licensing/cost of full redundancy against the criticality of the process being monitored.
5. Business Benefits
- Higher monitoring uptime and continuous visibility for operators and engineers
- Preserved historical data integrity for production analysis, root cause analysis, and regulatory reporting
- Reduced risk of unplanned downtime affecting process safety and efficiency
- Better alignment with standards like IEC 62443, which treats availability as part of the CIA triad
Conclusion
PI System redundancy is a layered architecture spanning OPC Server, PI Interface, and PI Data Archive Collective. A solid implementation requires careful network design, the right failover scheme (cold/warm/hot), and disciplined testing and documentation — ensuring continuous, reliable process data with minimal risk to productivity and safety.
