For years, I have been advocating and teaching the advantages of Object Oriented Programming (OOP) and why we, in the metrology industry, need to move away from script-based programming for automation. This often involves explaining to managers and other software developers the costs associated with maintaining multiple procedures for a given Unit Under Test (UUT) and how approaching the development problem from an OOP perspective will save time and money.
The conversation would go something like this: If you write each procedure based on the standards used, you would need six procedures for a given DMM. A typical DMM would have 5700A, 5720A, 5730A, 5500A, 5520A, and 5522A versions – and those are just the Fluke calibrators; there are also the Wavetek, Transmille, and Meatest calibrators. The response I usually get is, “We only have one 5720A and two 5520As.”
The problem most labs don’t understand is the question is not “What do you currently have in your lab?” The real question is, “What are your current and projected software development costs?” Do you understand how costs can increase exponentially?
Now, there are some new calibrators on the market. Last year, Fluke, Transmille, and Meatest introduced new calibrators to the market. And to support them in a scripting language like Fluke MET/CAL®, a new calibration procedure for each calibrator will need to be created.
Fluke introduced the Fluke 5560A, 5550A, and 5540A; three new procedures for each DMM. Not to mention oscilloscopes because there is also a scope option available for these new calibrators. Transmille has the 4010A, while Meatest has the 9010, and the 9010+. That is a total of six new calibrators your calibration lab may need to support.
No lab has all the calibrators, but every lab has some subset of the above-mentioned calibrators. Most labs have at least two different calibrators in their labs now. And in the next 5 to 10 years, they will replace one or more of them with one of the above new models introduced this year. Meaning they will have to expand their library of procedures!
There are thousands of procedures that will need to be modified. Then tested, validated, and QA approved, equivalent to hundreds of thousands of man-hours in procedure development and testing for each new calibrator.
Every calibration procedure that uses a multi-function calibrator now needs to be updated. Yes, for many, it will only take a few minutes. But those minutes add up to months of work. Not to mention, new procedures will require a new calibrator version plus one or more legacy calibrator versions, again requiring more man-hours!
So the question is not, “What calibrators do you have in your lab now?” The question is “Does your software support the Hardware of the Future?” Is the software Future Proof?
Having that same conversation with the same managers, now they are understanding the software development cost of adding new hardware. Now they understand the hidden cost of software development is three times or more than the cost of the hardware.
This is one of the reasons why I created Metrology.NET®. It is truly future-proof. It allows the operator to choose the standard being used at the time of calibration. Simply add a driver for a new calibrator like the Fluke 5560A 9010 or Transmille 4010 and use them in place of a Fluke 55xx calibrator with zero code rewrites.
This is one of the advantages of any well-modeled Object Oriented Programming application. Using the “Prototype” pattern, the programming language allows the developer to create a prototype of a multi-function calibrator that works with any hardware; allowing the operator of the software to choose the specific hardware at the time of calibration, as long as it matches the prototypes’ requirements.
How the prototype pattern works in Metrology.NET®, is really quite simple. First, a driver is created and tested for the new calibrator. The driver is written to comply with the prototype patterns requirements for a multi-function calibrator. Once the software is tested, the new driver is added to the workstation’s driver directory. It’s really that simple.
There will always be a software cost when adding new hardware to a calibration lab, but that cost doesn’t have to be outrageously expensive. You don’t need to rewrite your entire library, run every procedure, then QA every UUT. The process can be as simple as testing the new driver, double-checking the uncertainties, and adding the driver to the workstation. This can all be done with zero changes to the UUT’s Test Procedure.
