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.
914/5000
There is already a product to do this used worldwide which is the IBA PDA that uses a distributed tool gratuitously that is the IBA ANALYSER. IBA software stores the data exactly the way you want, and most technicians already have experience in using the analysis tools. To connect IBA to LABVIEW, just use one of the available UDP, TCP / IP, OPC etc drivers … For an unlimited number of variables you will have to pay about $ 10,000 for a license. For smaller sets the price drops. One of the biggest problems with IBA is that during the registration of the variables you can not configure a dead band or a filter. I’ve looked at how they compact and store the data and it’s ridiculous. I think National Instruments could do something much better, but IBA has become a standard in industries with processes that need high sampling rates. IBA is becoming a standart industry tool.
@valdimir
That’s interesting to know such a tool exists for so expensive price. Thanks for writing up that info here.
Two more comments:
1. Those logged data are also very valuable for production process surveilance, e.g. to find out what is ‘typically’ and something might have changed. Also changed lots etc. can be found.
2. This kind of logging can also be achieved (as mentioned) with database servers. It is quite easy to connect to such a DB and store data as they have been acquired.
We use mySQL and some LabVIEW interface VIs that are placed into the code where-ever new data have to be logged.