2 of 2 people found this helpful
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:
Attribute hierarchy within AF Element:
Au (which references the Result tag)
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.
This structure is probably closer to what I was after for our users needs. I will give it a shot and see what they think. Many thanks for the replies.
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.
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.
1 of 1 people found this helpful
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.