Search capabilities deliver new levels of quality analysis
In the world of microscopy image analysis, we have really begun to create more images than ever imagined. For example, while visiting an automotive plant this year I noticed that weld inspections were being done all over the vehicle to help ensure that automated welding machines were doing their job correctly. At this facility I saw well over 50 images in a single report and began to realize why setting up an imaging database was so critical to the usage of images like these.
So let’s take a step back...
Today, many people still have not realized the value of an imaging database and what it can do for them. We feel that we can simply utilize our computer’s operating system and its capability of files and folders to neatly store data in an organized way. What this gives us are just basic ways to break down the data. In an automotive example, the highest-level folder could be the vehicle model, the next level the location on the vehicle, and the last level the date the test was performed. The critical measurement taken is then overlaid on the image stored in that location. This structure is fine if we always want to look at a specific-date test on a known location of a vehicle. The story changes if we need to look at trunk welds in March—now we must go in and out of every folder with a March date to look at the images. Then, when a detailed analysis is needed of failed trunk welds, you may need to open every image in every dated folder just to look at the measurement value on the image. All of this can be simplified with a single database flag pass/fail measurement.
Back to today...
When creating an imaging database it is still a good idea to do a basic breakup of the data to help keep you organized, so we could have a structure for vehicle models and another level for vehicle locations, but the similarities would end there. The date of the test is straightforward because it is the date the image is originally stored and completely automatic. After performing the measurements, the database flag of pass/fail can be set by the operator. Now, without opening any folders, a date search range could be put in, and the database would return all images taken on that date. In failure analysis mode, the database search can be set to return trunks that had the database field fail set. This is a pretty simple example, so let’s next try and take a more advanced look.
Here’s a hypothetical example...
Management hears that a lot of trunk welds have failed and despite constant adjustment to the welding machines they continue to have high levels of weld failures. As the supervisor of the QA lab, you have looked at some of the reports and you now see that some images that look good were marked as failures. What can you do next? Utilizing database search capabilities you find all the tests that failed. The database can also show you the time the sample was tested. With the addition of a few fields to the database, you can also track the time the vehicle was removed from the assembly line, at what time the components were cut for testing, who cut the vehicle, who performed the test, and even who is going back to the assembly line to adjust the welding machines. With all this data you can then really start to find exactly when things went wrong and how it was fixed.
Additional situations may then be exposed: The vehicle could have sat for a day before it was cut and then tested. The name of the user who incorrectly measured and identified failures would now be available. More answers would be revealed (e.g., after a legitimate failure a user incorrectly adjusted the welding equipment showing as repeated failures; samples cut by a specific technician were damaged by the cut, causing bad measurements). The list of possibilities that could be identified is only limited by the data you enter.
Imaging databases don’t have to be scary...
Databases can be quite simple, starting with something as basic as a document storage (flat) database. This type of database would be for a single computer and would provide a single-folder level with database fields to track failures, users, etc. and then search that data.
Workgroup databases now allow up to five computers to access a single database, allowing multiple image stations and analysis-only stations to access the same images. In this case, one user could create an image and store it in the database, another user could pull it to a different computer and perform the analysis, and finally a third user could write the finished report. Here we could also store in the database the raw measurement data and the finished Word report. More advanced filters could be created to search more complex scenarios of data and results. These types of databases do require some IT expertise but internal company resources and the vendor’s application specialist should be able to get you on your way.
Enterprise databases can get complex, but if data security is a critical part of your project this is the level you may need to be at. At this level, you can synchronize with your company’s user directory and pass that security on to your microscope system database. You can prevent users from deleting data and even prevent them from seeing other users’ data. This level includes all the functionality already described, with this added level of integration. Make sure you are prepared for this type of project as it may be a large undertaking for your IT department but the value may be well worth it.
