I just got back from the 2019 A2LA Technical Forum in Reston, Virginia and I was uber impressed with the size of the show. If you saw me there, I am sure we talked about software. Since this is an Automation Corner, I am going to continue. I wanted to write about the conversations and how software has changed over the last 20-ish years.
I remember when I went to my first NCSLI show in San Diego, California. I was amazed at the number of people and technologies at the show. I remember asking the staff “Why was there nothing about software?” I was expecting to see a track or at least a session on software in metrology. After all, I was a metrologist who wrote code and there was software everywhere. I was quickly told this isn’t a software show, it’s a metrology show kid. I was surprised people didn’t see the connection.
Now roll the clock ahead to today and NCSLI has the 141 Measurement Information Infrastructure & Automation Committee. Software is viewed as having a more significant overlap with metrology, but most important, metrologists are actively learning about software and database technologies.
This was my personal highlight from the A2LA Tech Forum. Yes, I talked with several people about metrology and measurement uncertainties, even earned an Artel “Pipetting Gold Metal” with a 0.07% repeatability. But the best part of the show was the technical level of software knowledge held by many of the people at the Forum. We talked about everything from MET/CAL® 9.0 to R:Base—yes, people are still using R: Base!
People who know me know not to give me a beer and mention software. But this time it was me listening more than talking. I was impressed by the level of knowledge as we talked about loosely and tightly coupled software—how software that is tightly coupled has little to no flexibility. A Fluke MET/CAL® script is a good example of this, you have to have pretty much the exact standard called for in the procedure or the software doesn’t work, whereas loosely coupled software lets you make changes. Loosely coupled software means modules to the software can be changed or added without the need to recompile the software.
Many people confuse flexible standards as loosely coupled software, but it is really not. Having the ability to use standard A or standard B is not loosely coupled, because that feature “Was a Known” when the software was developed. Loosely coupled software will support drastic changes over greater amounts of time.
A good example of loose coupling is dynamic link libraries (DLLs). Many modern applications allow for DLLs to be created and added or updated to the application, without modifications to the main application. Over time, the operating systems have changed from Windows XP to today’s Windows 10. Yet, many applications still work because of the loose coupling between the application and the OS.
The hard part of creating loosely coupled software is creating a well-defined and flexible interface, while at the same time, keeping it generic will help it stand the test of time. This is the hardest part of my job as a metrology software architect. Often I have to rethink my design over and over again until I get it right. Then comes several hours of trial and error followed by pondering “why didn’t that work?”
But over the years, I have found small, simple blocks of code that come together like Legos work best. And it doesn’t matter what language they are written in. For example, back in 2011 we wrote a paper on “Using Fluke MET/CAL® to Implement a Flexible Measurement Driver Model with Expanded Measurement Uncertainties and Error Checking”; we still use that model today in several languages from C# to Java.
This is where I apply “Syntax is Semantics, Structure is Everything!” Meaning, it doesn’t matter what language (the syntax) is used, it is all about the structure of the software. Good software architecture, “The Structure,” can be written in any language.
This has been the mantra for our company. We have learned good design structure from LabView®, C#, Java, and implemented it into our MET/CAL procedures, where we perfected and tweaked it in a limited scripting language, only to bring it back into more powerful tools by creating things like Specialized Applications for Metrology (SAM) and Metrology.NET®.
Having great conversations with metrology engineers about advanced software concepts is what I enjoyed most about this year’s A2LA Tech Forum and the industry as a whole. We were talking about structure of code and the pros and cons of how the software is structured until wee hours of the morning.
