7 Replies Latest reply on Jun 15, 2014 6:52 AM by mhalhead

    AF Development road map




      Now that Abacus (aka Asset Based Analytics - ABA) is out (very happy) I thought that I would try and bait OSIsoft into giving a bit more info on the AF roadmap (the techsupport roadmap is a bit light). Below is my wish list:

      1. Flexible output times for ABA. The current ABA implementation is limited to outputs at the time of execution. I would like to have more flexibility over the output time:
        1. The ability to specify a relative output time e.g. t+6h
        2. I would like to ability to be able to have multiple outputs. The same value is written to the PI archives at two different times e.g. y+6h+1s and t+6h. This would allow us to mimic the behaviour of a totalizer (we typically use the two point totalizers)
        3. I would like the output to be the result of a logical operation (i.e. an analysis template) or an attribute which could be static or calculated (Custom DR, Formula DR, Analysis, ...)
      2. Custom ABA routines. In other words a replacement for ACE.I do accept that the code will have to be re-written although the hard part being the business logic will remain the same.
      3. Future data - yes this is more an PI Archive feature but AF needs to support it. 
      4. On premise replication of AF template libraries - yes we are trialing PI CC for this already.
      5. Reference elements between different AF servers. Basically the same idea as having a referenced element but the elements are on different servers. E.g. you have an enterprise server with all the sites, then each operations has its own AF server with their detailed model. I would love to be able to reference the site's detailed model into the enterprise server with seamless navigation.
      6. The ability to "hide" attributes from users. We have a fair number of attributes that are infrastructure related and the bulk of the users don't need to see these; all they do is clutter up the interface for the normal users. 
        1. An extension to this would be to have more control over which attributes PI CC sends.
      7. The ability to add a "script" (or custom logic) to the create, update and delete of elements. The easiest use case I have is when I delete an element I would like it to go and clean up after its self; e.g. remove points (or set them to scan off) that it created.
      8. Overhaul of the Formula DR. Even with ABA Formulas in AF are still useful particularly as they are calculated on the fly with the inputs from the client. The UI could definitely do with a bit of a spruce up; I land up writing a number of them in notepad. 
      9. Models and connections. I would really like to see models and connections return to AF as a first class citizen rather than the only for SigmaFine status they currently have. I would also like to be able to reason over the models. A connectivity model gives another layer of context. 
      10. PI Notifications should be integrated into ABA and Event Frames. I know that this is already on the cards but I thought I should mention it anyway.
      11. I should probably mention more on EventFrames but the biggest thing for me on EF at the moment would be back filling events over an extended period; e.g. go and generate an EF for this condition over the past 5 years, 
      12. Last but not least a OLE-DB or ODBC interface into AF that is writable. 
      This is just a list of the top of my head; I would say up to item 4 is in order of priority. Steve you shouldn't be out of a job in the near future. 
        • Re: AF Development road map
          Roger Palmen

          To provide some support to the wish-list:

          1. Flexible output times! Yes, definate top priority for Abacus to replace ACE.
          2. Would like too, but unsure if custom routines are the way to solve this, or that we just need Custom DRs. There is a great need to be able to store advanced business logic in the middle tier.
          3. There is no limitation in AF nor Abacus regarding future data as far as i'm aware of... E.g. Table DR already supports future data. Imho just limited to the PI Archive, but we have just gained access to the CTP.
          4. I think CC is great for that, but for replication e.g. between two databases in the same AF box it's a bit overkill...
          5. An AF DataReference? Never thought of that... Should not be too complicated to create an AF Attribute DR, similar to the PI Point DR.
          6. Familiar discussion... I think this is a requirement for PI System Explorer, more than AF. As PI System Explorer was not intended to be used as an end-user tool, we do see increased use of PSE by knowledgeable users. And for that reason, one would like to have a toggle switch to view / hide objects from PSE that have a 'hidden' flag set.
          7. This is quite complicated, and all i've ever seen is that there are custom programs built to maintain an AF structure based on and external definition. And the AFSDK lets you do everything you would like to do. Never seen a repeating scenario here... (yet). This would be easier with item #12 though.
          8. Not my biggest headache, but support for string datatypes would be...
          9. Never found a good example or reason to use models.
          10. Agree. Now Notifications are a bit of a side-step, while a lot is shared between Abacus and Notifications.
          11. Isn't backfill of EventFrames supported by the backfilling of Abacus? While we're backfilling, let's add backfilling of Notifications too.
          12. Yes! Would make life easier to create and maintain models.
          So my main support would go out to items #1 and #12.
          Ofcourse can think of a million other things, but let's keep focus. Thanks for starting this thread Michael! Always nice to get me thinking...
            • Re: AF Development road map

              Guess I have lots more work to do.  Thanks for the feedback, keep them coming.

                • Re: AF Development road map
                  Robert Raesemann



                  4. On premise replication of AF template libraries - yes we are trialing PI CC for this already.




                  I'm interested in being able to replicate AF template libraries between server. I saw some posts from the 2011 time frame that mention this capability being planned, but I have not seen or heard anything about it. I see from this discussion a mention of a PI CC trial being used for this, but I'm not sure what that is. 


                  What is the current status of replication development? If there is a trial available, I have a good use case to test and would be interested in participating as well.

                    • Re: AF Development road map



                      PICC = PI Cloud Connect.  It currently supports replicating AF templates across two (or more) PI Systems.

                        • Re: AF Development road map
                          Robert Raesemann

                          I should have caught that one, I just was thinking of something native on the AF server, and didn't even think about Cloud Connect.


                          In my particular case, I have a client who has a fleet/rollup up server collecting data from numerous site servers via PI to PI. We want to have AF server onsite to make site usage faster and more robust, but I want to avoid having to manually make sure that all of the AF templates are synchronized. What are my options? It sure would be nice to have everything replicate out from the fleet side to all of the site servers. Are you guys still planning to implement something like this?

                          • Re: AF Development road map

                            Hi Rob,


                            As Steve mentioned above, PI Cloud Connect will replicate your PI AF Template libraries between PI Systems. You can sign up for a 6 month free trial at www.picloudservices.com


                            There are also some guidelines for using template replication posted on the OSIsoft Community forum here:




                            The 1st part of the article would be pertinent from what I can understand about your use case from above. OSIsoft would be very interested in your feedback, and to see if the product fits your use case.


                            Mike Jarvis


                            Product Manager

                              • Re: AF Development road map

                                Hi Robert,


                                We are in a similar situation where we have a central AF server which is the master of the templates and then an AF servers per site. The sites are the master of the elements. The reason we don't use a single central AF server is largely related to the networks.


                                The biggest headache of managing multiple AF servers is keep the templates in sync. There is nothing in AF itself that assists with this. PI CC does quite a nice job of keeping the templates synchronized; with limitations. The data still resides on premise and all the normal AF functionality works; from the AF usage point of view the cloud portion is irrelevant.


                                There are some limitations with PI CC for template synchronization:

                                • It doesn't handle custom data references. What I've discovered is that it does nothing with them. It does replicates the configuration string so all you need to do is deploy your custom DR's to all the servers. It is remarkable easy to remotely deploy custom DR's; we are using a little bat file that does this on a release build.
                                • It doesn't handle EventFrame templates. I would guess that Notification templates are the same but I haven't tested.
                                • It doesn't handle tables both static (internal tables) and linked tables. The lack of support for static tables is the biggest limitation for me at the moment as a number of our templates make use of the tables for configuration.

                                Other than these limitations it works well and is pretty fast; in my very limited testing it takes under a minute to replicate the changes to multiple servers.