6 Replies Latest reply on Jun 9, 2016 1:19 AM by RayHoward

    PI AF Design for LIMS data



      As a newbie to PI I have been thrown into the deep end to help setup PI to store our LIMS assay data. As a test I'm setting up tags in SMT as follows:

      L1CONAU - Holds the assay value

      L1CONAU.BATCHID - Holds the Sample BatchID (Not unique)

      L1CONAU.SAMPLEID - Holds the unique Sample ID

      L1CONAU.SAMPLEDATETIME - Holds the date and time of the original sample


      We have multiple elements (Au, Ag, SiO2 etc) for multiple lines (Line 1, Line 2) giving us results in the SQL LIMS table like this.

      L1CONAG - Holds the assay value

      L1CONAG.BATCHID - Holds the Sample BatchID (Not unique)

      L1CONAG.SAMPLEID - Holds the unique Sample ID

      L1CONAG.SAMPLEDATETIME - Holds the date and time of the original sample


      L1CONAU - Holds the assay value

      L1CONAU.BATCHID - Holds the Sample BatchID (Not unique)

      L1CONAU.SAMPLEID - Holds the unique Sample ID

      L2CONAU.SAMPLEDATETIME - Holds the date and time of the original sample


      I have created the 1st set of tags for L1CONSiO2 (in SMT) and was trying to figure out the best way to set them up in AF.

      Should I have an Element setup like this:



                Line 1

                     Line 1 Concentrate Grade Au

                     Line 1 Concentrate Grade Ag

                Line 2

                     Line 2 Concentrate Grade Au

                     Line 2 Concentrate Grade Ag


      Attributes for every element includes:

      Result - TagID is L1CONAU

      BatchID - TagID is L1CONAU.BatchID

      SampleDateTime - TagID is L1CONAU.SAMPLEDATETIME

      SampleID - TagID is L1CONAU.SAMPLEID


      Viewers of the data want to be able to see the results by BatchID, Element, Line Number and individual SampleId's.

      My current example is as below (missing the SampleID Attribute).



      Any suggestions, will this work or are there better ways to set it up?





        • Re: PI AF Design for LIMS data
          John Messinger

          Hi Ray,

          How you set up the asset structure will largely depend on how you anticipate your users wanting to search the data, as well as how you might use this in other applications/reports/screens etc. I did a similar project a couple of years back for a concentrator facility. We didn't go down to the level of creating separate AF Elements for each element being assayed. Using your sample structure as an example, we stopped at the Line 1 level as our end point, and then had multiple attributes within the AF Element, representing the various sampled element assay results - Cu, Fe, SiO, etc. From there, you could treat each data item (BatchID, Sample DateTime) as a child attribute. It largely depends on what kind of granularity you want at your endpoint level.


          This is what it would look like

          AF Element hierarchy:



                    Line 1

                    Line 2



          Attribute hierarchy within AF Element:

          Au (which references the Result tag)


               Sample DateTime


               Other attributes of the sample you want to include


          As I said earlier, what structure you decide upon will be driven in part by how you intend to use the data, as one format may suit a specific use case (or set of cases) better than another.

          2 of 2 people found this helpful
          • Re: PI AF Design for LIMS data

            Hello Ray,


            As you are in the process or creating an AF structure, you might be interested by the following resources:

            Asset Based PI Example Kits

            Building Asset Hierarchies with PI AF


            Let us know if you have questions,

            • Re: PI AF Design for LIMS data
              Dan Fishman

              I agree with John Messinger on this.  It really comes down to what do you want to do with the data.  If your end users want to easily view Au and Ag together it might make sense to put these concentrations on the same element.    If each line has different concentrations associated with it and you want to compare Au easily across all lines, then you want to use a child element to break out the line from the concentration.  A lot if it comes down to what do you want to compare and how similar are the  elements. Also, if the number of concentrations vary, it might make sense to split this out to avoid extremely complicated AF Element template hierarchy designs. 


              John mentions the use of child attributes, and of course there are some trade-offs.  It means one more thing for people to click on in DataLink and Coresight and it makes the data almost second class.  It does add nice structure and maybe the data should be more hidden as it is not significant data.   With the attributes arranged in a hierarchy, you can have multiple attributes called "BatchID", and the context is determined from the parent.  Without this, you would have to modify the names to be unique. Also use categories such as Au and Ag as well and these are easy to drag everything from the category onto a Coresight display.  A great conversation here, would be on design rules on when to apply child attributes hierarchies. My thoughts are usually for intermediate calculated data, summary data that is not used often and meta data that helps build the parent attribute.


              The fact that you have Batches makes me think PI Event Frames, where each batch is of course represented as an Event Frame.

                • Re: PI AF Design for LIMS data
                  John Messinger

                  I've done a couple of LIMS integration projects the past couple of years, and we found it difficult to really make a good use case for Event Frames in these. Largely because although you have things like sample IDs and Batch IDs for your assays, this is not really a classic Batch scenario. Whilst I can see a certain amount of logic to using EF for this type of data (it can be a very good fit), admittedly a key road block in the projects I worked on was the lack of visualisation for Event Frames in ProcesBook. A good number of the mining companies I've worked with in Australia are just not there yet with products like Coresight, and ProcessBook tends to be the key visualisation tool. And in the case of these two projects, the existing site shift reports in DataLink weren't able to be retrofitted to incorporate EF reporting for the lab data component. There can sometimes be a surprising amount of inertia to work against at some sites here The other part of the issue in the first project was at the time the limited options for EF generation (it was before Asset based Analytics was released).

                  I also think that in this particular scenario, the current hierarchical structure doesn't necessarily lend itself as well to wrapping the assay result batches in Event Frames. You would end up having a large element collection associated wit each Event Frame, or lots of 'smaller' Event Frames storing results for the same assay sample.

                • Re: PI AF Design for LIMS data

                  I would add these values in EF as attributes for two reasons:


                       1) If you add it in AF you a mixing up the equipment model with you laboratory model.

                       2) Your samples seem to have a time context (sampling time). So if you want at some point correlate your sample values with you process conditions, you already framed up you           analysis.


                  I would create event frames and use the sample time as start and end condition (last sample to current sample) and reference production line. The you can search your values by line and sample.



                  1 of 1 people found this helpful