Lab automation: Some buy, some build

Most calibration labs use computers to fully or partially automate instrument calibrations. Some organizations use off-the-shelf automation software and prewritten procedures, while others develop their own software from the ground up. Two vastly different organizations—semiconductor maker Analog Devices and the US Air Force—took automation paths that are as different as their sizes and their missions.

To find out why these organizations chose the paths they did, I interviewed members of their engineering staffs. I met with Tony Giannasca, metrology manager at Analog Devices, at his Wilmington, MA, lab. I also spoke by telephone with Marc Monnin, automation programmer for the Air Force’s Metrology and Calibration (AFMETCAL) program in Heath, OH.

Figure 1. A calibration station at Analog Devices calibrates RF instruments under software control. Courtesy of Analog Devices.

In the early 1990s, Giannasca needed to improve lab throughput. He and his technicians knew how to calibrate instruments but not how to write software. So, he chose an off-the-shelf calibration software package that would minimize their having to learn programming.

“The technicians took to automation right away,” said Giannasca. “They saw it as a way to grow with their jobs.” Because all of the stations are automated, technicians are free to tackle other jobs, such as instrument repair, while running a calibration.

Because of the automation, technicians in the Wilmington facility can distribute automated calibration procedures to the company’s labs in North Carolina, California, Ireland, and the Philippines. Engineers at the company’s design centers worldwide send their instruments to Wilmington for calibration.

For the company’s production facility in the Philippines, the Wilmington technicians built a calibration rack that calibrates DMMs and signal generators used in production. Prior to having the rack, engineers in the Philippines would send equipment to Wilmington for calibration. After receiving the rack, they continued to send oscilloscopes and spectrum analyzers to a local third-party lab.

“After six to nine months,” said Giannasca, “we started receiving equipment from the Philippines that had been going to the third-party lab.” Because of automation, the Wilmington lab could calibrate equipment at a lower price and with a faster turnaround than the third-party facility.

Future plans for the technicians in Wilmington include building a calibration rack for a company facility in San Jose, CA, to calibrate DMMs, function generators, electronic loads, power supplies, and oscilloscopes. Periodically, a technician from Wilmington will spend a week in San Jose, performing about 150 calibrations with the same automated procedures used in Wilmington.

Although Analog Devices is a relatively large company, the number of calibrations needed to support engineering and manufacturing pales in comparison to the number needed by the US Air Force. The Air Force has some 77 calibration labs at bases around the world that must calibrate more than 900,000 instruments with more than 90,000 part numbers. The software used by the Air Force, and how it is developed, reflects the differences between a commercial organization performing calibrations on a few thousand pieces of equipment and a large organization that must calibrate more than 100 times as many instruments.

Figure 2. The US Air Force NextGen automation consists of three independent software layers.

Over the last several years, engineers at the AFMETCAL program have developed a software architecture to automate calibrations. Software engineer Marc Monnin was one of several automation programmers who developed code for the NextGen Calibration Automation System (Ref. 1).

Because of the project’s large scale, Air Force engineers wanted a flexible software architecture that would outlive any PC technology or operating system. “Typically,” said Monnin, “automation software would work until a PC, operating system, or instrument changed.”

To provide cross-platform compatibility, Air Force engineers developed a three-tier software architecture that consists of a sequencer, measurement modules, and a hardware-abstraction layer (Figure 2). Each layer is independent of the others. They communicate through an application-programming interface.

The sequencer is essentially a test executive. It reads information on the type of instrument to calibrate (DMM, oscilloscope, etc.), the test parameters, and the test limits from an instrument-specific XML file. The XML file also contains the test logic.

A separate measurement module contains the details about how the system must perform the calibration, including the measurement methodology and the steps that must be performed. Because some instruments can be calibrated in more than one way, the measurement module can handle more than one procedure.

Below the measurement module resides the hardware abstraction layer. This layer knows which instruments are under calibration and which instruments provide the calibration signal sources and measurements. It also contains hooks to instrument drivers.

Figure 3. A software tool creates XML scripts from entries in a table.

The development of a calibration procedure at AFMETCAL involves three groups of people: calibration engineers, software engineers, and technical order writers. Calibration engineers understand the metrology involved in a calibration. They provide input to the technical order writers, who write detailed procedures for performing a calibration. The calibration engineers then review each calibration procedure (called a technical order), looking at it from a metrology perspective. Finally, software engineers write the actual programming code.

Technical order writers need to know the specifications for each instrument setting. (To the Air Force, a calibration involves checking an instrument to verify that it’s within the manufacturer’s specifications. It doesn’t involve adjustments to bring an in-tolerance piece of equipment closer to its nominal operation.) To streamline the writer’s job, software developers created a tool that generates the XML code used in the sequencer. A technical-order writer enters test data into a table, and the tool produces the XML script (Figure 3).

Managing the automation of so many instruments requires a central database. From the data, the engineers and technicians at Air Force calibration labs can find which XML script to use for calibrating a given instrument. When the AFMETCAL program developers issue a new XML script, measurement module, or hardware-abstraction layer, engineers and technicians around the world simply replace the previous version of that module only. Monnin is now confident that the AFMETCAL program has a software architecture that will outlive computers, operating systems, and even instruments.