Reopening this suggestion to collect additional feedback.
An error occurred while saving the commentDave Johnson commented
In my opinion, the lack of a robust calculation engine is the largest gap in OSIsoft's current product offering. There is a huge opportunity for OSIsoft to add significant value to what is already otherwise an excellent platform.
Please read the background information below to get up to speed on the incredible usefulness of this feature and then be sure to upvote this user voice idea!
The PI AF/MATLAB architecture (now deprecated) was elegantly designed and provided a glimpse into the possibilities of PI AF extensible analytics. While few companies expressed interest in MATLAB integration per se, many customers would petition for a more generic offering that would enable the integration of PI AF with a server hosting a catalog of functions using ASP.NET, Python Flask, etc. if they truly understood the value proposition.
Here are the benefits PI AF extensible analytics would provide:
People can leverage PI System Explorer, the standard OSIsoft tool for creating AF templates and elements, to:
- Invoke functions that reside in external DLLs and libraries beyond the built-in PI AF analytics functions.
- Overcome the inherent limitations of PI AF analytics which do not support programming loops and generally lacks the expressiveness to construct and maintain complex calculations.
- Use external functions residing in DLLs as first-class citizens just like the built-in AF functions. This brings full IntelliSense/autocomplete capabilities so people can create their calculations as AF analyses.
- Manage calculation code using robust software engineering tools including unit testing, source control, etc. (since the code resides in an external DLL)
This PI AF extensibility point would unlock other scenarios that could add value to companies with JSON/HTTP as the lingua franca. For example, a Python Flask server hosting various Python data science packages, R function hosting, etc.
Extensible analytics would provide a decoupled architecture resulting in these benefits:
- Externally hosted ASP.NET calculation server (or other technology platform) makes it less likely that the PI Analysis service will crash and burn if something goes awry in the calculations.
- Clearer separation of responsibilities for OSIsoft to pinpoint the problem as residing with customer code rather than custom data references, PI ACE, etc.
- Easier to maintain and update calculations through a pure functions DLL and a published catalog/manifest on an external calculation server.
- Local hosting of calculations for critical operations so facilities can function as islands rather than relying on a third-party calculation engine in the cloud.
- Happy, productive customers! People can accomplish their complex calculation objectives using one tool (PI System Explorer).
Why not just use a Custom Data Reference (CDR)?
- The CDR and PETools functions run in the same memory space as the PI AF analytics engine which increases the likelihood of crashing the AF analytics service if something goes awry with the calculations versus the decoupled extensible analytics design.
- If nested functions are needed (i.e. calling one function inside another function), using the CDR will be challenging. It will require some advanced knowledge for people building calculations to ensure the correct function execution order. This contrasts with the extensible analytics option which enables IntelliSense and nesting of functions in AF analyses just like built-in AF functions.
- Utilizing the functions via the CDR in PI AF templates will be more clunky for the end users who are building AF structures, leading to a suboptimal UX versus extensible analytics.
- When using PI System Explorer (PSE) to build PI AF templates/elements, PSE will download the CDR/engineering functions DLL file to the user’s local machine behind the scenes, presenting an opportunity to reverse engineer the DLL code. This is a concern if the functions in the DLLs contain "secret sauce" and particularly a concern if the DLLs are .NET-based which can be trivially decompiled.
- Calculations are more costly to build and maintain since one must build and deploy CDR .NET “glue” code on the PI AF server versus updating a catalog of functions on a decoupled server.Dave Johnson supported this idea ·