Migrating from PI SDK to AF SDK: What You Need to Know

Updating legacy PI System applications to use modern technology stacks is a common challenge faced by many PI system engineers. If you have a solution in production using PI SDK and are considering migrating to AF SDK, understanding the risks, tradeoffs, and best practices is critical. Here’s a professional overview based on real-world experience and community insights.

Running PI SDK and AF SDK in Parallel: Is It Safe?

Yes, technically you can install and use both PI SDK and AF SDK within the same application. Many legacy tools—including PI Processbook and PI ACE—have done just that. However, keep in mind:

• Separate Connections: Each SDK establishes its own connection to the PI Data Archive, which can lead to redundant resource usage and potential confusion in troubleshooting.
• Code Complexity: Maintaining both SDKs increases code maintenance, potential for memory leaks (especially due to PI SDK’s reliance on COM), and overall application bloat.
• Historic Precedent: Hybrid approaches were common when AF SDK did not support certain PI namespace features, but today, direct tag access via AF SDK removes much of this need.

Special Considerations for PI ACE Users

Many legacy PI ACE calculations utilized both PI SDK and AF SDK. However, compatibility issues have arisen with newer versions of Visual Studio (post-2013) and .NET Framework (AF SDK requires 4.6.x or higher), while PI ACE tends to work best with older environments (e.g., .NET 3.5). If you must still use PI ACE:

• Consider isolating AF SDK code in a separate, external process you call from PI ACE, instead of embedding AF SDK directly.

Why Prefer AF SDK Over PI SDK Today?

Modern guidance from OSIsoft (now part of AVEVA) and experienced engineers is clear: favor AF SDK wherever possible.

Advantages:

• Performance: AF SDK is faster and better designed for managed .NET applications.
• Maintainability: Cleaner APIs, less code required, fewer COM headaches, and easier troubleshooting.
• Breadth: AF SDK now supports most PI namespace operations directly, removing many old blockers.

Remaining Gaps:

AF SDK does not natively support:

• PIModule objects or direct MDB (Module Database) operations (unless you link MDB as an AFDatabase).
• PI Message Logs access (this is now handled via PI PowerShell tools).

Debunking a Common Myth

A persistent misconception is that AF SDK requires you to use an AFDatabase (asset-based approach). Not true! You can perform traditional tag (PI Point) operations directly against the PI Data Archive using only AF SDK, with no AF Database involved.

Best Practices and Recommendations

• Consider going AF SDK-only: Unless you must use PIModule or PI Message Log features, migrate all PI SDK usage to AF SDK. This makes codebase more modern, faster, and easier to support.
• Test in Dev Environments: Validate parallel SDK operation thoroughly before production deployment, especially if you must maintain hybrid approaches.
• Refactor in Phases: Migrate modules or subsystems incrementally to reduce risk.

In Summary

Migrating from PI SDK to AF SDK is both feasible and advisable for most modern PI System applications. Running both SDKs in parallel is supported but introduces complexity that should be minimized over time. The AF SDK offers cleaner, faster, and easier development for both tag and asset-based applications.

Resources

• PI Developers Club: AF SDK Documentation
• PI System Migration Guidelines

Have you performed a PI SDK to AF SDK migration? Share your experiences and lessons learned in the comments below!