The Need for Model-Driven Metrology Software Engineering

I am going to try and take a huge concept in software engineering and design, break it down into its core functions, then show how it applies to metrology software in less than 850 words.

So let me start with a brief evolution of software engineering, where back in the 1950s through 1970s most of the software applications built were function-based applications. Programmers would create a “function int main(string args){…}” and call in from a command line or some other application. Then they would write a series of sub-functions inside the application and call them as needed to complete a defined task.

From the 1980s until 2000, most of these function-based applications were migrated into Object-Oriented-Programs (OOP), where the idea of objects containing both data and functions used with the data were mixed. This created more robust code in the applications and increased the code re-usability, as it was built around well-defined objects. Things like a textbox, found in a windows application or on a web page could be reused from application to application. This moved tasks like drawing the box, receiving keyboard input, displaying the data to the user, etc. from the application programmer to the operating system or browser code. All because of better code readability!

From the 1990s to today, many of the applications started using generics and/or annotation in their code. Usually, they are called decorator classes, because they add features to the objects, kind of like how a pine tree becomes a Christmas Tree because of how it is decorated. One great example of this is the serialization of an object, allowing the user to save it or load it to and from a file. This serialization of the object copies all the data into a stream allowing it to be moved or saved for another/future use.
In .NET, this task is as simple as adding “” to the top of the object; it now has all the code needed to save and create itself to and from a file. All the programmer has to do is tell it where to write or read the file from.

The difference between Function and OOP-based programming vs. the concept of generics is when and how the code is added that can serialize the object to and from a file. In the 80s, the programmer would have had to know about the requirement to serialize to a file and write the code to read and write the object to and from an I/O stream. But as generics came into use, the programmer just had to add the annotation to any existing class and all the work was done.

The object can be decorated just like the Christmas Tree. And not with just one decoration, as there are several generic decorations that can be added to an object: read and write to XML or JSON file, create a REST Interface, store in a data table, and tons of tools and more each day.

The above examples are based on data storage, because that is what most computers do, data storage and data access. How the data is persisted, created, read, and saved to the filing system is the largest part of what computers do.

The above examples work on Linux, Windows, Mac, Android, etc. They work on almost all databases, such as MS SQL Server, PostgreSQL, My-SQL, Oracle, etc. They have adaptations in .NET, Java, Pascal, C++, etc… and they can move data from and to any system.

This needs to be the focus for metrology software companies in the 21st century. We need to start focusing on models that work in tandem with each other. Building more reusable tools, sharing ideas, and reusing common ideas and metrology-based software models.

We have been working with the NCSLI 141 Committee to create better software models for metrology. Over the past few years, we have discovered commonalities and created tools that will help bring model-driven engineering to the world of metrology software.

The next few Automation Corners will be dedicated to creating better models for metrology. And if you are attending any of the metrology conferences this year, please look me up… I would love to chat about what is needed in a better data model.


Michael Schwartz (mschwartz@callabsolutions.com) is CEO of Cal Lab Solutions, Inc., a metrology software and consulting company located in Aurora, Colorado.