One of the important criteria to consider while designing the data logging is the traceability of the data in future, in relative to the device/product under test. Some logging is required only for temporary purpose but some data are required even till the end of the device life cycle. A traceable data is required if you think you’re logging product level details and and it needs to be persistent till the death of that product.
Few scenarios where you would need traceable data are…
- When the product is out to end customers and end customers logs you with some defects with the product, you would need to trace back what exactly happened to the product during the testing phase using the traceable data. Or whether there is similar pattern of defects in the whole lot which went through the same time.
- When you’re going to release a new version of the product, how it’s better compared to the earlier releases? The traceable data will give you insights on analysis. Or when you are rolling out a firmware to the product, the same traceable data can help to determine the update requirement for the devices from support team end even if the customer is unaware of the details.
Okay Fine.! What is traceable data? A traceable data is the one which has the tractability can go way back to give info about relative instruments or other components which were used in the system while testing the product, so that the tractability can yield effective information even to the dead corners of the product. Sometimes even the device unique ID can have the information about the tractability.
So, how can it be achieved?
- Through assigning each device/product with unique identification. An identification could be a serial number, or timestamp with the some combination of other data like device type (A or B type), test git or production machine details, locality of testing/production (in case the product is produced in multi geo-locations), or in any other format with which the uniqueness can be achieved with the device details in the same UID
For example, an UID can be like 14022018091623456 . This is a simple timestamp format where the devices is produced at least a millisecond time gap between.
14 Day 02 Month 2018 Year 09 Hour 16 Minutes 23 Seconds 456 MilliSeconds
- A reliable database which is readable even after years. From simple CSV to complex SQL can help on this. But it depends on the expertise of the team which is going to use these data.
Related External Link: Incidentally I came across the Argenta Blog where there tractability importance is highlighted too.
Ajay is a professional developer and architect of NI-LabVIEW applications with extreme interest in getting the hardware connected to LabVIEW and automating the stuff. Recently he is also putting his hands in NI-TestStand to get very dirty on it. He is also a good mentor for the various interns in his career. He is ready to help the people in techie roles.