Category Archives: Test Engineering

PMI San Diego Chapter Lunch – February 13, 2014

Someone Has To Turn This Great Idea Into Dollars

I am presenting at the San Diego Chapter of the Project Management Institute’s monthly chapter lunch.

The ad is here:

My presentation slides are available.  You are welcome to use them, but please credit greenroom if you do.  Before you download, please use a comment.

Robert Gordon PMI-SD Chapter Lunch 20140213

Tangible Results of Process Automation & Test Engineering

In the previous post, I described a production testing system where I was able to re-engineer an existing test setup. Along the way, we added a great number of automated efficiencies. So what were the results of this effort? The production line had been up and running three years before I got involved. In years 1, 2 & 3, the organization was able to ship almost exactly the same number of units per year. The problem was that the product was in high demand and units were stacking up awaiting test and calibration. Have a look at the graph below. In year four, I was able to implement the new automated process and ship the backlog of devices at a rate of 700% of the first the years’ shipments. Now in year five, we are on pace to exceed year four deliveries. The result? The organization cut prices by 20%. And the test technicians love the new setup. They hook the radios up for an overnight test and go home. In the morning, they update the test logs and go do other productive things for the rest of the day.


An Example of Process Automation and Test Engineering at Work

Update: Here is a discussion of the results of this effort.

Here is an example of where I was able to successfully apply process automation and test engineering to improve the throughput, effectiveness and profitability in a manufacturing process. The organization produces radios that require require quality control and calibration. The process in use prior to my involvement was very labor intensive and somewhat error prone. This is a theme that comes up again and again: Let the computers do the repetitive stuff to free up the humans to do the thinking stuff. This is why we make computers!

The solution involves quite a bit of software development. I wrote an application that

  • Controls the devices while under test.
  • Dynamically discovers the presence and type of environmental test chambers from among several dissimilar models.
  • Dynamically discovers the presence and type of spectrum analyzers.
  • Sets the temperature of the environmental test chambers at various points across an industrial temperature range (normally -30°C to +75°C).
  • Monitors and controls the environmental test chambers to ensure they are at the intended temperature.
  • Applies spectrum analyzer settings pertinent to a particular test step and takes measurements.
  • Calibrates and tests the radios at the various temperature set points. Calibration is handled via a measurement and adjustment feedback loop.
  • Dynamically detects a failing radio and automatically bypasses it to continue testing on remaining systems.
  • Creates Microsoft Excel formatted test reports.
  • Archives test reports and calibration tables to a central server.

So here is a picture of the setup:


Here is a block diagram for the organization of the testing application. What you can see is a formed-based application with classes that represent the calibration as an object, the devices under test, the environmental test chambers and the spectrum analyzer. I implemented the device under test and environmental test chamber classes as “abstract base classes”. An abstract base class is used to enforce a standard interface which “child classes” must implement. This setup can dynamically discover the type of environmental test chamber and create the appropriate child class that can talk to that model of chamber while presenting a standard interface to the main form. I used the same design to allow the discovery of the specific model of device under test while presenting a standard interface to the calibration object.


Next we have a flowchart of the overall test process.  Here is a description of the test steps.

  • Discover the environmental test chamber, devices under test and the spectrum analyzer.
  • Once all discovery is successful, enter a top-level loop to step through the temperature setpoints.
  • At each temperature setpoint, loop through each device under test to perform calibration and testing for each device.
  • Select device frequency and spectrum analyzer settings.
  • Calibrate each device.
  • When done with the current device move on to the next.
  • When done with all devices, move to the next frequency.
  • When done with all devices at all frequencies, move to the next temperature setpoint.
  • When done at all temperature setpoints, archive the test reports and calibration files.

Here is a flowchart of the test and calibration process.


OK, now we are getting into the details.  Next is a flowchart of the environmental test chamber (often referred to as an “oven”) discovery process.  What is shown is an object oriented approach to process automation.  Prior to implementing this test application, the technician had to select the correct software version to match a specific oven.  This process is fully plug and play.


And finally, another flowchart that describes the process to discover the devices under test.  This is also a plug and play setup where each device is detected when plugged into the test computer.  The test software probes the device to determine the specific model and creates the right object to communicate with the specific device type.


We can do this for your business too.  We’ll even write the documentation!

Hello world!

Hello, world!

— More to follow soon!