PI System Collectives Across Security Boundaries: Data Synchronization, Security, and Best Practices

Managing PI System collectives that span disjointed network zones—such as a Business Network (BN) and a Control Network (CN) separated by firewalls—presents unique challenges. Data synchronization, network security, and fault tolerance must be balanced to ensure reliable operations and compliance. This article explores the key considerations, possible solutions, and best practices for architecting PI System collectives across such environments.

Scenario Overview

Consider a PI System collective where:

• Primary PI server resides on the CN (highly secured zone)
• Secondary PI servers reside on the BN (corporate or enterprise zone)
• Firewall allows limited routes from specific BN PI servers to the CN, but most BN PI clients cannot directly access the CN primary
• HA-SDK clients on BN must connect to secondary PI servers; direct writes to the primary are often blocked

This architecture is common in critical infrastructure where strict security policies restrict communication between business and control environments.

Key Challenges and Considerations

1. Data Synchronization Across Collectives

When applications on the BN write to secondary PI servers (due to firewall limitations), those writes may not be automatically propagated to the primary server on the CN. To prevent data divergence:

• PItoPI Interface can be configured to replicate new writes or updates between PI servers in both directions as required
• Synchronization strategies must account for bidirectional data flows if both BN and CN sites can originate data

2. Security Policy Implications

Security policies may prohibit most connections from BN to CN, making the standard collective model (where data is posted to all members) infeasible. Options include:

• Designating a BN PI server as Primary: Allow direct writes from BN applications and sync the CN as a secondary.
• Role-Based Access Controls: Accepting certain configuration tasks on the BN as an acceptable risk.
• Trusted Application Servers: Instrument select BN servers to bridge data and manage queuing for all collective members, potentially leveraging PI SDK/API with buffering.
• Middleware Approaches: Implementing solutions via PI-ACE, OLEDB, or custom logic to ensure integrity.

3. PI HA-SDK Limitations and Workarounds

By default, the PI SDK blocks data writes to secondary servers in a collective. This can be overridden using the Replication_EnableSDKWriteValues parameter—however, doing so carries the risk of data inconsistencies if writes occur on a secondary not visible to the primary.

Best Practice: Use the RequirePrimary SDK setting for most client applications, ensuring that data is only written to the collective primary, and rely on PItoPI for fanning data to secondaries.

4. PItoPI Replication

PItoPI becomes critical in cross-network layouts:

• Configure PItoPI to pull from BN servers (using outbound connections from CN or DMZ) to minimize firewall openings
• Properly design failover logic with redundant PItoPI interfaces and status point heartbeats
• Be aware of feature limitations (such as event annotation handling and configuration propagation)

5. Server Side Buffering (SSB)

Future features under PI server development, like Server Side Buffering (SSB), are expected to improve the ability to queue and replay writes across collective members and survive failover events. Ensure your architecture plans for these enhancements if available in your PI System version.

6. Handling Failover and Application Writes

If the primary fails and applications continue to write to a secondary, data synchronization becomes complex and manual intervention may be needed to ensure the entire collective remains consistent. Automatic reconfiguration of PItoPI or similar mechanisms can help but may require custom scripting or orchestration.

7. Alternative Architectures

In some environments, security and data flow requirements may be balanced by:

• Flipping roles: Making a BN PI server primary, CN as secondary
• Using middleware to manage cross-network writes
• Clearly delineating which network zone is the “system of record” for various data sources

Recommendations & Best Practices

• Understand and enforce security policy boundaries—don’t open unnecessary routes or rely on clients in insecure zones for critical writes
• Use PItoPI interfaces to replicate across network boundaries where collectives can’t directly communicate
• Leverage the RequirePrimary setting for all critical applications
• Design failover procedures ahead of time—plan for the possibility of extended split-brain data scenarios
• Keep abreast of PI System development—features like SSB may soon provide more elegant solutions
• Review point configuration and event annotation settings in all replicated points
• Document your architecture and failover scenarios to ensure operators and support teams know how to restore data consistency if required

Conclusion

Operating a PI System collective across security zones is a challenging but manageable scenario with careful planning. Prioritize system security, data integrity, and operational clarity in your architecture. Use tried-and-true mechanisms—such as PItoPI, failover logic, and role-based access—while keeping an eye on future enhancements like SSB for even greater flexibility.

Have you encountered similar scenarios? Share your successes and lessons learned in the comments!