Overview

Hardware Engineers have a long, tedious process called validation and verification (V&V). There is a lot of data that must be stored and manipulated in order to guarantee that the hardware will work as expected. I've seen engineers store this data in everything from a spiral notebook to a series of flat files to very complicated spreadsheets. This section describes how a database was implemented to help make sense of all this data.

Determining the Need

When I first encountered the problem of the V&V datalogging, I was recently promoted to a new group. The hardware engineer that I worked with recognized that the idea of storing the data from all the V&V test is overwhelming. Even worse, was trying to manipulate that data into a series of reports for status meetings.

Someone came up with the idea of storing the data in a database, but would dynamically create a new table every time a test was run. Mining the data across a population of boards would be next to impossible. It was necessary to setup a serious database schema to conquer this huge task. From the schema, the reports could be generated in a predictable manner.

I went to nearly every group in the company to get an understanding of how people were overcoming this problem. There were several solutions, but they were all specific to each product. They would work for one product, but could not be migrated to another. It was time develop a broader solution before spending yet another year in a data rut.

Beginning with the End in Mind

After doing some rough concepts a database schema, I started to interview some of the user's of the data. I would get some rough drawings of what the engineers would like to see after the tests are completed. I came up with a list of use cases for the system.

Building the Schema

Then I designed the schema to make it easy to enter the data into the system and simple to pull the data out of the system. It was important for both to be extremely flexible. Every piece of hardware had its own set of attributes that would greatly effect the output of each test. It was necessary to store the inputs and outputs of every test.

Building the Code

After having a fairly solid schema, I started to write the code for the storage mechanism. It was a simple function that would run at the end of every test. The engineers only knew LabVIEW, so I was forced to only use the LabVIEW language. It has no pointers and I discovered many faults in the language itself. It was never designed for such an application, but it was still possible.

After the storage mechanism was solid. I started on the mining and reporting aspects. I kept the interface so flexible that the user could actually select one or more inputs to each of the features of the hardware and see the minimum, maximum and standard deviation for each setting along with a scatter chart.

Pushing it forward

The system was then used as a basis for an inter-departmental database solution. I became part of a committee to design the next generation of data storage throughout the entire company. Many of the components of the original database design were incorporated. The solution was broad enough to store data from both hardware and software tests. It was used from everywhere from the manufacturing floor doing a Final Verification Test to the software engineers doing an Automated Build Test.