Is The Asset Framework Worthwhile?
OSIsoft’s summer release of PI Server 2010 has signaled a paradigm shift from Tag Centric to Asset Framework (or AF) Centric. OSIsoft has been operating under a paradigm where the PI tag and tag searching was the standard data access method since the company started in the 1970s. Now OSIsoft wants you to use the Asset Hierarchy to find data.
This isn’t the first time that OSIsoft has offered an object hierarchy and tag aliasing; the PI Module database has been around for years, but it was an alternative method to search and not the recommended standard method that the AF is designed to be. Thus OSIsoft is asking customers to make a major shift in the way users access the data.
Is this major change justified or just a change we have to put up with?
So often we see software manufacturers ‘changing’ their applications in an attempt to justify a price increase or to help them maintain cash flow. What year did Microsoft Word and Excel upgrades stop being useful to you and become a hassle instead?
This release of the Asset Framework is a long awaited significant improvement to the PI System; it is well worth the effort required. How important is it? The benefits of the AF are so important that we were willing to take the risk of putting a newly released PI Server 2010 into production in a validated environment only months after its release!
Are we insane? Were we committing suicide?
No, we are not insane and as it turned out, we didn’t commit suicide. We’ve been working with OSIsoft since 1996, so we have a good understanding PI upgrades and releases. We also did a complete cloning of the existing production PI system and upgraded it to PI Server 2010 with all of the modules and client tools using the production data, graphics, SharePoint, and RtReports. We prototyped all aspects of it and captured screen shots for all server and client software installations.
Were we guinea pigs discovering issues with the new software?
Although I logged 10 or so tech support calls with OSIsoft during this prototype period, the issues were mostly security based configuration issues with only 1 software bug (a column length in an SQL table). However, our switch to PI OLE DB for custom software development uncovered an issue with custom applications locking up from a problem recycling resources that we have to wait until January for the next release of the PI SDK to fully resolve. Until then, we have a registry entry extending the time before releasing resources. The decision to use PI Server 2010 forced us into this PI SDK.
When you consider the complexity of multiple servers, access of services and applications from multiple systems, and the synchronization of all the layers, it went smoothly.
What about the Synchronization of the MDB and the AF DB?
Our biggest concern was the interface of old with new; the co-existence of the older module database with the new Asset Framework database. We were planning this in the Spring before the software was out and we didn’t know how much we’d be strattling old vs. new. It turns out that PI Batch and the RtReports still use the Module database and a 2-way synchronization needed to happen between the two databases.
Our PI implementation was done in 2 phases. Phase 1 in 2009 was intentionally limited to raw I/O without PI batch. We followed the OSIsoft Engineering plan and chose to wait for the new AF and not attempt to utilize PI batch in the first phase. Thus, we didn’t have anything in the module database before the implementation of PI Server 2010.
Unfortunately, PI Batch and RtReports still use the Module Database even with PI Server 2010 and one has to rely on the 2-way synchronization service to keep everything flowing. I’ve been pleased with the service; I can create new batches in the Module Database and magically it appears in the AF configuration and visa-versa. There have been no issues with it.
We believe the synchronization of the 2 databases was the best possible juncture between old and new. The clients see only the new world and the remaining ‘under the hood’ applications of Batch and RtReports continues to operate until OSIsoft is ready to move them. We understand the value of phasing in a new architecture and OSIsoft chose a good implementation point.
What is the downside?
The PI System has become more complex and requires more server instances and more packages to work seamlessly together. Add the tighter, more complex security schemes of the latest Microsoft operating systems and you have some issues to overcome.
Our ‘biggest’ problem was setting up appropriate security. Is the AD account that’s running the application pool in SharePoint authorized to access the PI server and to access the AF SQL server database? How about RtReports that uses PI web services to talk to the AF? Don’t forget the Manual Logger access, the PI OLE DB access, etc, etc! Where do you set all that? The good news is that OSIsoft Tech Support knows even if I overlooked it in the installation procedures, so I wasn’t stuck very long.
Obviously, the downside is far less than the upside or I wouldn’t be writing this article!
So what benefits justify this risk?
The full implementation of the Asset Framework across the entire PI platform provided the following benefits:
1. Major time savings
2. Ease of use for end-users and PI administrators
3. Ease of maintenance
4. Increased accessibility to the data and data structures
5. Integrated end-user security
The use of AF templates and template-based graphics reduced 100 potential process unit graphics down to 9 equipment template graphics based on unique equipment types. As a result, the graphics are easier to maintain, easier to implement a standardized look and feel, and a tremendous time savings. As the company expands to additional buildings, areas, process units, and equipment, one simply uses the existing templates and graphics with the addition of more elements in the AF that reference the templates.
It solved an age old problem!
Every implementation of a data historian has faced the dilemma of what to call the data points; what is a good tag naming convention. Mostly because the instrument engineers were the first to work with a new PI system, the tags were typically named after the instrument tags on the P&ID diagrams, which is only helpful to a small subset of the ultimate PI users.
With the AF, you can have your cake and eat it too! Go ahead, name the tags based on the P&ID diagrams, but then create equipment templates with attributes that use English-like naming (ex. ‘Vessel Weight’ instead of WIT1312.PV). Now engineers can search by tag name and upper management can navigate an asset tree or equipment hierarchy to locate a data point with a nearly intuitive interface. That is a big deal!
But you say Tag Aliasing is nothing new!
Correct, it is not! OSIsoft has been offering some form of tag aliasing since the 1990s when the ISA industrial standards were defining Batch (S88) and Enterprise (S95) data access. I was a member of both committees and a heavy proponent of these standards and more universally accepted tag naming since the 1990s, but I’ve waited until August, 2010 to commit to it…. Why? The answer is SQL Server!
The partnership of Relational and Time Series data structures
Until now, the data storage mechanisms of the batch database and the module database were not robust enough to become the primary method for accessing information. Early on it was a proprietary database, then Microsoft Access, but now it is the industrial strength MS SQL Server that is the backbone which can handle the load.
In 1998, I was breaking a cardinal rule by presenting at the OSI conference: ‘Synergy of PI and SQL Server’, the concept of relational and time series data working together. Now OSIsoft has not only adopted that philosophy, but made it central to its design!
With the use of SQL Server, the doors swing wide open to let in a nearly infinite set of possibilities of how to better utilize time series data and the PI application.
Without the 15 year history with OSIsoft, the attention to detail that OSIsoft developers apply and their world-class Tech Support infrastructure, we would never have considered such an undertaking. OSIsoft was open and accurate in their recommendations throughout this process, which made all the difference.
With good planning and prototyping, the move to AF is worth your while. Each implementation phase with a PI system adds a new layer of functionality (instrument I/O -> Calculations -> Batch -> Analysis -> Integration -> etc), you realize a higher level of functioning capability that translates into a higher ROI for your long-term PI investment; even with the additional cost for PI Server 2010, you will see a good return on your investment. Don’t stop at the first implementation layer; take full advantage of PI Server 2010.
Thank you OSIsoft, keep it up!
Rich Winslow is a co-owner of Automated Results Computer Consulting, which is an OSIsoft PI Partner with 15+ years experience with OSIsoft PI and 30+ years manufacturing solutions experience. Learn how Automated Results can help you get a higher return for your PI investment.