by Michael Schwartz
Automation has its own quality system automatically built in. When software performs the same test, the same way over and over again, it can’t be wrong. There is no fake it till you make it. You can’t just put a sticker on it and hope nobody checks. The life of automation is longer than a single calibration. Users can always look at the measurements made by automation and question the results. Especially if something looks wrong or they are getting contradicting manual measurements.
My old boss told me a story of when his company sent him and a colleague to the Fluke MET/CAL® programming course. After the training, he was writing one procedure every couple of weeks while his colleague was writing ten or more in a week. The difference was my boss was writing the test process into his code, while his colleague was banging the code out. You can bang out a lot of procedures in a very short amount of time if all the procedures do is ask “Enter a value,” then “Print it,” followed by the word “PASS.”
Good automation has some very interesting side effects. First and foremost, the automation engineer has to learn the measurement process. I mean really learn it! This is why it is very hard to find good automation engineers. They need to be able to see the test in their heads in order to build the procedure.
After that, the engineer must overcome obstacles. Things like the equipment idiosyncrasies have to be a known quantity for the test process—settings and commands of how the equipment behaves. The smallest detail can mess up your measurement process, like the input impedance on the 3458A can cause the calibrator to trip. Setting up a calibrator for say 1,000 V, then resetting the 3458A, and putting it into auto range; that trips the calibrator. That breaks the automation!
It is helpful when the manufacturer has a well-defined RESET state of the hardware with all of the default settings. The worst is when a manufacturer allows the end user to configure a custom default state because now the state is largely an unknown. And when the equipment state is unknown, the only resolution is to set every setting on the instrument.
I hate when I miss something, because if I miss it, it means the customer found it. I really don’t like saying “I didn’t know that.” And after 30 years in this field, there is a lot I still don’t know! I have learned to pay attention and listen to the technicians who work with the equipment every day, because in most cases, the technicians know the equipment better than the engineers who designed it. They know all the tricks, quarks and idiosyncrasies of the equipment and measurement process.
The second obstacle for engineers is learning the test process. To code it, the automation engineer has to know the test process inside and out. Often that means cracking the books and learning a new measurement theory. Even if you have detailed step by step instructions, it’s difficult to code anything without understanding the measurement process and the metrology behind the test.
The hardest part is when there is no written test procedure (our company charges more for this because we have to first write some sort of test process). If there is no known procedure, or something similar, then the automation needs to be written based on the calibration results from the factory or from the equipment specifications. In cases like this, I have found Google and Wikipedia are a great resource. A few months ago, while I was working on the IFR6000s, I was amazed at the level of detail I found on Wikipedia related to aviation guidance systems. It gave me some insight on how landing systems operated and I was fortunate enough to be seated next to a pilot on my last trip to Detroit, but that is a story for another time.
The thing I find most frustrating is when I am working on an automation project where the customer has been calibrating a device for years manually. I am using the same hardware, the same UUT, but I can’t get the test to work. So I ask the tech “What am I doing wrong here?” only to get that dreaded answer of “I don’t remember!” Now I have to figure it out, or tell the managers that not only do they not have the hardware to test this correctly, but this test they’ve been doing manually can’t be done with this hardware.
Because automation remembers, it remembers the process every single time. As an automation engineer, we have to figure it out! And, it has to be right, because our name is attached to that calibration.
