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
For real use-cases, check out presentations from OSIsoft UCs:
Two of my most favorite presentations:
Syngenta Enogen Team - Process for Capturing and Sharing Ethanol Plant Data using PI Asset Framework
1 of 1 people found this helpful
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:
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?