You need two things:
1. Rather than overriding the Name property, you need to specify the name and description in the "Description" Attribute. This allows AF to query the name and description without having to instantiate. The Description Attribute is part of the System.ComponentModel namespace.
2. All PlugIns (and Assemblies) must provide a GUID. The GUID is specified via the Guid attribute, which is part of the System.Runtime.InteropServices namespace. Here is your code modified:
[Description("GlobalAnalysisRule; This is my Analysis Rule")]
public class GlobalAnalysisRule : AFAnalysisRule
public override bool CollectElements()
public override bool CollectInputs()
public override bool Run()
Thank you very much!
I have noticed that here are not a lot of examples and documentation regarding the creation of analysisrules. Am I looking in the wrong places? Can you maybe point me to examples ?
No, you are not looking in the wrong place - this is intentional. Really, your ahead of the game - I should have warned you in the last post.
We are basically mid-stream with Analytics. We have Analysis from AF 1.x, which only supported "Model Analysis". These remain supported in AF 2.x, but the UI for them is not currently exposed except within the upcoming Sigmafine 4.5 PIMSOFT product. Model Analytics are often run manually, and if automated, require an independent scheduler.
We also have Analysis for Notifications, which are using the same basic underlying classes but at this point, they are limited to using only OSI defined Analysis Rules. These are scheduled and run by the Notification Scheduler.
General purpose Analytics, without Notifications, is an effort that is underway. This includes supplying a scheduler as well as support for executing "Data Reference based Analytics" on a scheduled basis (Attribute's with Calculation based Data References can be be scheduled and executed by the Analytics scheduler with outputs written back to PI)
As for execution of 3rd party written Analysis Rules - this is still a way out. Essentially, for those types of analytics, the short term solution is to write your own Analytic Engine that sits "outside" of AF - uses the features of AF to query for elements and attributes of interest - and executes logic against them.
Allright, always good to hear that my post here was not for nothing. Allright, but is there any other way to do scheduled analysis of an model in AF 2.x ?
Would you please consider the following situation and my proposed solution, and tell me if I'm in the good direction?
The PI system of the client needs a lot of Future Data. So, we use the COM connector to store the future timestamps with values into SQL server. We then have to calculate 'bussiness rules' every 5 minutes (for a few thousand tags). As the COM connector performance is not good, I have written a small data access component, which gets the time series data directly from SQL server (if it's a 'COM Connector tag'), and with PISDK if it's a normal PI tag.
I am creating a datareference, which uses this data access component to query values (and write them) to replace the provided 'PI Point' datareference.
I then created a small scheduler application, which needs to calculate the bussiness rules (from AF elements) every <interval>. I create a case with my custom AFAnalysisRule, and run it.
The model itself is not like a traditional 'asset' based model. It's more of a set of calculations, which need aggregations based on meta-data (in custom PI Point attributes). I'm thinking of viewing every 'bussiness rule' as an AFElement. This element has multiple attributes which will be used by the custom AFAnalysisRule to create an output value. This outputvalue will then also be written to an attribute with the custom data reference.
I don't know if this is enough (coherent) information, but as an AF newb I could use some guidance
Thank you in advance!
The only mechanism from OSI currently available for automatically running Analysis Rules is via AF 1.x Compatibility Layer and the associated ACE Module. I would not recommend that for what your doing. Too many layers and you are restricted to 1.x functionality. So that leaves you with writing your own scheduler.
Given that you have now have created your own scheduler application, the question is whether there is sufficient value of running through the AFCase/AFAnalysisRule's interfaces. The advantages are you have a mechanism for delivering your rules to your scheduler, a well known interface for running analysis, the capabilities of a case - which include a placeholder for context (timerange), the ability to do what-if analysis, the ability to discard the results if the analysis proves unsuccessful, and finally, a mechanism to publish results back to PI and your data references. Additionally, when the AF Analytic Scheduler(s) is released, you could migrate to it.
The disadvantages are you have to live within the rules defined by AFCase/AFAnalysisRule. For example, the current implementation does not allow you to write more than one output to one attribute.