2 Replies Latest reply on May 16, 2018 6:50 PM by Rick Davin

    Business benefit of using PI AF?

    SinthanaiSirpiK

      What is the Business benefit of using PI AF?

      How AF is helping a manufacturing/process industry? Any body having a case study of the same. Whatever we get from PI Data Archive same we are getting in AF in the form of Assets. One benefit i am able to see is Notification.

        • Re: Business benefit of using PI AF?
          lmlcoch

          PI AF gives you completely different view on your data. Think of it as raw phone numbers (PI Data Archive) vs names (that point to raw phone numbers) in AF Server.

           

          We have two very nice videos showcasing the purpose of AF Server:

          OSIsoft: Describe the purpose of the AF server Part 1. v2010

          OSIsoft: Describe the purpose of the AF server Part 2. v2010

          https://www.youtube.com/watch?v=QixY_nkAw7o&index=1&list=PL4F21888928C06005

           

          For real use-cases, check out presentations from OSIsoft UCs:

          http://www.osisoft.com/templates/presentations-by-event.aspx?id=1673

           

          Two of my most favorite presentations:
          Syngenta Enogen Team - Process for Capturing and Sharing Ethanol Plant Data using PI Asset Framework

           

          Multiple Assets, Multiple Clients, Even More Owners, One Solution by juwi

          • Re: Business benefit of using PI AF?
            Rick Davin

            NOTE: I know I am answering a post that is over 3 years old that already has an accepted answer.  But I wanted to add my experiences as a former customer to anyone reading this in the future.

             

            REASON #1: WORKING WITH ASSETS

             

            The PI Data Archive is tag-based and uses a flat naming structure for tag names.  AF allows one to work in assets in hierarchies similar (and familiar) to their own plant.  Consider these rather cryptic tags based somewhat on ISA tag naming guidelines:

             

            1. 014-TI-219.PV
            2. 014-TI-236.PV

             

            Okay, so I see Unit 014 has a couple of Temperature Indicators.  Great.  Someone who works intimately with that process unit may know what those tags are for right off the top of their head.  Someone else, let's say oh ... the Plant Manager, doesn't.  If I say it's for a heat exchanger, can you easily tell me which tag is the Cold Side Inlet Temperature and which tag is the Cold Side Outlet Temperature?  Wrong.  It was a trick question.  The first tag is the Hot Side Inlet Temperature and the second tag is the Hot Side Outlet Temperature.

             

            My point being that tag names aren't very descriptive, be it associated with the instrument in the field or in the PI Data Archive.  But with AF, you can have an element template to model your "Heat Exchanger" asset, and it can have attributes clearly named:

             

            • Cold Side Inlet Temperature
            • Code Side Outlet Temperature
            • Hot Side Inlet Temperature
            • Hot Side Outlet Temperature

             

            And each of those attributes may be mapped back to the cryptic, non-descriptive PI tag name.  Not just for that one heat exchanger in Unit 014, but for all heat exchangers in Unit 014, plus all your other process units thanks to REASON #2: TEMPLATES.

             

            Plus, an element can attributes getting data from more than 1 PI Data Archive.

             

            REASON #3: ASSET ANALYTICS

             

            Notifications was previously mentioned.  Tag-based Performance Equations are limited to tags in one PI Data Archive, and require 1 line of "code".  I don't know about you, but I have seen some pretty long, ugly, hard-to-follow PE's in my life.  Multiple Expressions in Analytics can be used in a given analysis, and an expression may span multiple lines (thanks to shift+enter) as well as /* inline comments */ being allowed.  This makes creating an Analysis so much nicer.  And having a comment or 2 where you need it sure pays off 6 months later when you (or someone else) comes along to review the expression and try to figure out what you did 6 months ago.

             

            Plus, an analysis can be triggered or interact with data coming from more than 1 PI Data Archive.

             

            And thanks again to REASON #2: TEMPLATES, you can create an Analysis for the element template, which can then create the individual analyses for each element using that template.  Again, I can put my effort into the analysis for my heat exchanger template, and with virtually very minimal effort that analysis is now running for all heat exchangers in my database, not just Unit 014.

             

            REASON #4: UOM and UOM CONVERSIONS

             

            Nothing to add.

             

            REASON #5: PERFORMANCE OVER HUGE PI DATA ARCHIVES

             

            The original poster works in at a manufacturing plant.  But consider someone working in Power industry, where a PI Data Archive has 5 million to 20 million tags.  Let's say you have an application where you want to find a dozen tags belonging to a transformer.  Searching for a dozen tag names against 5 million tags is slow against the PI Data Archive because of the nature of a flat tag naming structure.  And if you switch to a different transformer, you get to experience the slow lookups again.

             

            But in AF, the search for a Transformer element with a given transformer name will be quite fast.  Plus the search is not limited by name but can first filter on only those elements based on your Transformer template.  And then that 1 element has attributes associated with the dozen tags, but since the data references were updated when you built the database, each attribute knows the PointID (lightning fast lookup compared to names) to fetch.  So with AF, I have an more optimized search to the Transformer element, followed by having reference to the tag's already stored in the database. 

             

            REASON #6: AF BEATS ModuleDB

             

            When we say PI Data Archive, let's allow it to include the ModuleDB.  So MDB doesn't scale well - you are advised not to go too many levels deep with the child modules, or to have 100's of thousands of modules.  It only works against a single PI Data Archive.  A module may have Aliases (tags) or Properties (static value), and they can be root level only.

             

            AF scales very well, as it sits on top of SQL Server.  I have seen element structures close to 20 levels deep, and others with over 1 million elements, and both work well.  It supports working with multiple PI Data Archives.  I don't know what's cooler - child attributes or data references to support things other than tags or static values.

             

            REASON #7: EVENT FRAMES

             

            Nothing to add.

             

            I can go on and on and on.  I'm going to stop there because I've hit the big ones.  Did I mention templates?

            1 of 1 people found this helpful