We have all heard this before: Think outside the box! But this is easier said than done. It is especially difficult to notice your own blinders because we all see things from our own point of view.
For example, I was in a meeting last week when the subject of standardizing measurement uncertainty equations came up, and I found myself arguing the difference between interface and implementation. It was then that I discovered many people don’t see things out of their box.
In-the-Box Thinking: As it applies to measurement uncertainty calculations, they are thinking about the specifics of how their software currently implements uncertainty calculations. There is a single point of view on how their software calculates uncertainties, how their business does business, and what their auditors want to see in their calculations.
Problem: The problem with In-the-Box thinking is the assumption the box will always stay the same, that the software will always stay the same, the auditors will always look for the same thing, or uncertainty calculation models will always remain the same.
But this is not true; change is inevitable! Requirements will change, standards will change, models will change, and the software will change.
Outside-the-Box Thinking: Calibration labs don’t all use the same software. Requirements change from lab to lab, country to country, and from one auditing body to the other; they are all different. It’s hard to standardize everything by putting it in a single box, so let’s accept and manage variation with Outside-the-Box thinking.
If we change the paradigm from a “How can my software do something?” to “How can my software interface with other software using an industry-standard model?” we are thinking outside of the “Our Software Box” and looking at the problem from a more extensive scope. This changes the focus from the specific implementation to the interface.
Modular Design: Modular software systems focus more on the interface used between different systems. It allows for different systems to employ vastly different implementations, as long as they adhere to the specified interface.
This changes the singular focus of “my software” into two parts: One, how can my software implement the interface? And, how can my software interface with different software solutions?
At first, it feels like double the work. But it’s not! These changes will make your software more flexible and potentially even future-proof.
Interface: Next, we need an interface that works for ALL uncertainty calculations. Working with the NCSLI 141-MII Committee, I think we have created the perfect abstract interface. It is simple, intuitive, and easily implemented.
It starts with a Metrology Taxon definition where the required parameters are defined. The taxon will list a set of required values, but the interface allows for an unlimited list of additional values, all passed in a name-value format.
Implementation: This example is just one implementation, and it is easy to follow.
When we look up Source.Voltage.AC.Sinewave, it shows there are two required parameters: Volts and frequency with other optional parameters.
We can send the implementation “Volts= 200, Frequency= 1E3” and the implementation either returns an uncertainty based on the inputs or returns “39E39,” indicating the calculation failed. A simple Excel-based implementation can be downloaded here. A Metrology.NET tab can be added to an existing uncertainty budget where the input values are set by name, and the Excel sheet calculates the uncertainty.1
In the spreadsheet, there is a bit of Excel-ology, but most metrologists can create any uncertainty calculation in Excel. The difference with this model-driven approach is the interface is simple; all we need to do is match the name-value pairs and read the result.
Conclusion: By thinking outside the current software box and how the software specifically implements measurement uncertainties, we can see there is a simpler model that works for all uncertainties by allowing modular implementation of the uncertainty calculation. We are not just limited to Excel files; we can interface with other systems using Taxon and name-value pairs.
- For further explanation of this example, see my NCSLI 2023 Paper. ↩︎
