2 Replies Latest reply on Dec 11, 2014 6:05 AM by VCampus-METCO

    AF Suitability as Unified Data Model




      I am working on an oil & gas project and the customer has a defined Unified Data Model document which is a corporate standard for how data from production and exploraration, surface and sub-surface is to be organised. Data consists of structured data (static information, live PI data of standard types), and unstructured (documents, video etc).


      The UDM is defined as a series of explicit data tables, with field names, data types and entity relationships with other tables. It is clearly aimed at implementation using ORACLE or SQL Server and I have seen products such as TietoEnator EC and Business Objects which have these structures or similar defined.


      The UDM will be the single place where data is accessed via applications such as SLB AVOCET, SAP, Asset Performance, Optimisation and Visualisation tools including ArcGIS and other non-PI products.


      I would like to position AF as the technology to implement this UDM, but have some basic questions:

      1. Can AF elements use relationship information directly? i.e. can an attribute be a well-id that can be used to reference other related elements with the same ID - some of which may be many to one (e.g. multiple well tests over time against one well). Or do I have to implement this as a TABLE DR, and use Views etc to stitch the lit together.
      2. How are the multiple records to one handled (e.g. well tests where these are multiple well data test data against a given well, but with different well test date? Is this by for example creating a new element, or using the check-in/out feature to save another 'record'.

      I am struggling to see how AF is adding value to implementing this as a native SQL database application or whether it is just another layer of complexity. 


      Any ideas would be appreciated.



        • Re: AF Suitability as Unified Data Model

          Hi Simon,


          I'll give you my 2 cents on what I think PI can do here, but we might want to seek insight from others who have experience implementing similar solutions.


          AF's main strengths are as a system to organize your PI data streams into an asset view model based on templates, and to capture and provide context for important events in those data streams. Its great that you're thinking about putting AF at the forefront of your data analysis activities. But I think it would be challenging, although not impossible, to try and use AF as your UDM implementation if you have to surface a lot of data that is not suited for PI (non-timeseries) and comes from many external sources. My opinion is its easiest to maintain and analyze a large set of complex relationships across heterogeneous data sources when working in a standard relational model implemented in an RDBMS. A BI software package like the ones you mentioned may work well too but I don't have experience in that area to say much further.


          In AF you can easily relate assets to other assets, event streams (PI Points), and event frames. But you have to rely on data references to relate anything that is outside of PI, most commonly using a AF Table data source against an OLEDB provider. If you have to use a lot of non-PI Point data references to get to your data, then generally the query performance will decrease as the system scales up.


          In regards to your questions about AF, the well test data sounds to be time series data related to a well asset. So for that you could either import the data to PI tags or if you want to maintain your existing system of record for the well data then use table lookup attributes associated with the well.


          So my gut feeling is that you may want to leverage AF for its strengths and integrate it with any non-PI systems using PI ODBC OR PI OLEDB Enterprise behind an RDBMS or BI system implementing the customer's desired UDM views.


          Hope that helps.



            • Re: AF Suitability as Unified Data Model



              Thanks for your reply. I think you are right about the suitability. I think we will implement the data structures in SQL Server directly in the format that the customer has already defined. We will have to implement a HMI to allow data to be entered into this database. Applications requiring access to this data could just query the SQL data directly. AF may come into its own if PI time-series data needs to be made available. In those cases we may be able to provide AF templates that will query the SQL database and PI server.