Toward a Measurement Information Infrastructure

Instrument Specifications, Part 3

Mark Kuster, Pantex Metrology

Welcome to spring and hopefully some friendlier weather than many of you have seen over the last few months. In our Measurement Information Infrastructure column, the fall and winter installments fleshed out a high-level data model for electronic instrument specifications to facilitate automated instrument selection, calibration, uncertainty propagation, and use. Drawing on the VIM and common measurement practices, we worked down from the measuring system level through measuring instruments and measuring functions to measurement ranges, MPE specifications and instrument uncertainty models.

We omitted a number of properties that might prove valuable, as well as some identification and nomenclature detail. For example, if you examine a modern instrument’s documentation set, you will likely realize that our MII model ignored an entire technical manual or section on programming commands. So, let’s march out into the more luxurious weather and spruce things up.

System & Instrument Properties

As previously mentioned, we would like to include the human-readable OEM spec sheet at the measuring system level, in a PDF, HTML, or other universal format. OEMs will probably want to control anything issued under their name so this data element might equate to a locked read-only file. Figure 1 illustrates the idea. Alternatively, the PDF file might embed the electronic data instead.

Figure 1. Generating MII specifications. The OEM would create the electronic data with a MII spec sheet editor and combine that with its formatting template and cryptographic signature to generate a human-readable version as typically found on vendor web sites. Instrument users might use the OEM MII spec sheet(s) directly, reformat it per their own template, merge them into a larger system, or derive their own version for limited calibrations or special applications.

As for other properties, quality spec sheets normally include the operating conditions that govern system accuracy, performance, and function. The VIM defines steady state, rated, limiting, and reference operating conditions, respectively, as those influence and measured quantity ranges (VIM: intervals) under which the calibration remains valid, the instrument performs as designed, the instrument avoids permanent degradation or damage, and the instrument achieves its smallest uncertainty. The measuring intervals in our Range Measurement Model for the measured, input and influence quantities already express the steady state operating conditions. We therefore will add rated, limiting, and reference operating conditions to the model.

Let’s also add serial number restrictions and firmware and software versions to the identification and nomenclature elements at this level. We may also want to list legal and safety registrations such as UL, CE, etc. listings.
The instruments forming a system may vary in specification detail or perhaps exist as independent entities and not overlap each other at all. So, all the system-level elements optionally apply at the instrument level also.

Function & Range Properties

The VIM speaks of resolution, resolution of a displaying device, sensitivity, selectivity, discrimination threshold, dead band, detection limit, stability, drift, variation due to influence quantities, and step response time, all of which we assume may vary from range to range. To determine which of those we lack, we first identify those redundant to our existing model:

  • Quantities subject to calibration or measurement such as step response time fit into our model more closely as ordinary measuring functions and ranges rather than as special explicit entities.
  • The Range Measurement Model element discussed last time (with time as an influence quantity) should offer the information from which to calculate variation due to influence quantities, sensitivity, selectivity, detection limit, stability, and drift.
  • The VIM perhaps fails to fully clarify and distinguish resolution, discrimination threshold, and dead band. If required, we might calculate those properties from the Range Measurement Model and display resolution they likely depend on.
  • Our Standard Modeling Uncertainty section addresses instrument modeling and behavior deficiencies such as hysteresis, linearity, etc.

As a first approximation then, that leaves only something akin to display resolution to add to the measuring range data elements. We call it Indication Resolution so as to include material measures. For good measure, we insert Accuracy Class into the function-range nomenclature.

Other Loose Ends

Many commercial spec sheets present data in tables and diagrams. The computers we intend to read and write MII spec sheets have no use for tables and graphs because the specification model provides the information required to calculate everything directly. We humans, however, appreciate intuitive visuals, so the model should have facilities to generate them in the human-readable document. For that, we rely on scripting features at every model level similar to that discussed last time for MPE and Measurement Model definitions.
The wide variety of spec sheets encountered in metrology leads us to believe we will want other features not yet considered. So, an extensible data model will likely behoove us when we consider our data format choices. XML, for one, facilitates this.

Automation Commands

By combining a UUT’s MII instrument specification’s MPE and uncertainty model with those of a test or calibration laboratory’s available standards and their calibration certificates, we may imagine MII-aware software automatically selecting the optimum test point set and crafting a procedure, or at least a datasheet, to conform to the laboratory’s measurement quality requirements. The resulting test points would include all the secondary parameters required to qualify the measurement properly because we have included that detail in the data model. See Fig. 2.

Figure 2. Using MII specifications. An MII-aware lab management system would read UUT and measurement standard data and select test points to meet local measurement quality metrics (MQMs). From that and the original data, an MII-aware automation environment might create low-level instrument drivers and an automated calibration procedure per a metrologist's measurement method choices.

Ultimately however, as Fig. 2 also depicts, we would like our automation systems (METBENCH, MET/CAL, SureCal, TestStand, etc.) to interpret programming specifications in the MII spec sheet, add the appropriate instrument commands, allow a metrologist to select the measurement methods, and seamlessly build an automated measurement program for its own environment. So far our data model has nothing to enable this.

In the final analysis, beefing up the data model to accomplish this may take considerable effort and industry participation. The data model should know nothing of specific automation environments because we would like to give any vendor the flexibility to incorporate MII features into their software. At first glance, it appears we face the challenge to develop a command model general enough to handle any instrument and translate into any automation language.

Not so. First of all, IEEE Std. 488.2 already defined a standard instrument command language, SCPI, which the IVI Foundation now controls along with VISA, a standard for communication hardware and protocol independence. Theoretically, the two standards allow a program to use the same command to perform the same function using any appropriate instrument connected through any supported hardware interface. Actual results vary.

More to the point, a common command language doesn’t come into play here, because each MII spec sheet would contain its own instrument’s commands, whatever form they may take. For automation purposes, the MII spec sheet would simply embody the OEM’s programming reference. We seek only to communicate instrument specifications automatically to MII-aware software, so we appropriately leave issues like code reuse and instrument interchangeability to others. We might note though, that the SCPI and VISA standards do not claim instrument interchangeability because they do not delineate all the required instrumentation detail. Since MII spec sheets would cover that hole, they might engender interchangeability or automated reconfiguration as a side effect.

One MII implementation alternative might associate each OEM-defined command sequence with the appropriate MII data element and embed place holders for the test point quantity values. For instance, the measuring function and range levels might specify :SOURce- and :MEASure-type commands, whereas the input and influence quantity data elements might specify instrument state setting commands like :TRIGger and :FREQuency. The instrument-level automation commands would include initialization commands like *RST. Command parameter values for specific mode settings in those commands would correspond to the qualifiers describing the linked function or range. We adopt this approach in the data model as a first strike attempt.

An automation environment might then link back from a test point value to the correct UUT and measurement standard ranges and extract the commands required to set up and perform the measurements. Alternatively, the automation system might scan an MII spec sheet and then compile and install a low-level instrument driver to plug into a layered automation architecture.

As an example, suppose that a MII spec sheet defines a measuring function and range to source a peak-to-peak signal amplitude, A, into a 50 Ω load. Suppose further that the range defines an influence quantity, f as the signal frequency. If MII software chose the test point

Output Amplitude, peak-to-peak, into 50 Ω
A = 5 V, f = 1 MHz

then the software might discover command formats connected to the linked UUT range such as
:SOURce:FREQquency {f/MHz}MHz
:SOURce:VOLTage {A/V}V
and substitute the test point values to form the actual commands
Some environments might insert those commands directly into an automated procedure; others might use the parameter structure to build a new driver.
We have no reason to limit Automation Commands to SCPI or anything else. A CMM spec sheet might tie a measurement command such as “Measure circle Chebychev” to a specification to make it available for use as a measurement standard or a test on the CMM itself. Mechanical drawings adhering to Geometric Dimensioning and Tolerancing standards perhaps represent the ultimate dimensional spec sheet. Software already exists to generate CMM programs from CAD drawings to compare parts to specifications, so in a sense, we have special-purpose MII spec sheets right now.

This brief section on automation commands obviously leaves much detail to finalize, not to mention the choice of approach, but hopefully casts some light on the possibilities. In the meantime, we add Automation Commands data elements to our budding model.

All Together Now

Augmenting our previous model with the data elements from this article, we have the following more complete instrument specification data model:

Measuring System

  • System Identifier
  • Human-Readable Document
  • Visual Aids Script
  • Operating Conditions
  • Measuring Instrument 1
  • Measuring Instrument 2
  • Measuring Instrument NI

Measuring Instrument

  • Instrument Identifier
  • Human-Readable Document
  • Visual Aids Script
  • Operating Conditions
  • Initialization Commands
  • Measuring Function 1
  • Measuring Function 2
  • Measuring Function NF

System or Instrument Identifier

  • Unique ID
  • Nomenclature
  • Manufacturer
  • Model
  • Applicable Serial Numbers
  • Firmware Version
  • Software Version
  • Specification Document Title
  • Specification Document Date
  • Nominal Physical Size
  • Nominal Weight
  • Registrations & Listings

Operating Conditions

  • Rated Conditions
  • Limiting Storage Conditions
  • Limiting Transportation Conditions
  • Limiting Operation Conditions
  • Reference Conditions


  • Quantity Value Interval 1
  • Quantity Value Interval 2
  • Quantity Value Interval NC

Measuring Function

  • Function Identifier
  • Visual Aids Script
  • Indication Method
  • Quantity Kind
  • Function-Level Commands
  • Range 1
  • Range 2
  • Range NR

Function or Range Identifier

  • Unique ID
  • Nomenclature
  • Accuracy Class

Measuring Range

  • Range Identifier
  • Visual Aids Script
  • Full Scale Value
  • Indication
  • Range-Level Commands
  • Influence or Input Quantity 1
  • Influence or Input Quantity 2
  • Influence or Input Quantity Nq
  • MPE 1
  • MPE 2
  • MPE Ns
  • Range Measurement Model

We will no doubt find existing and future spec sheets that contain information this model does not address, so without becoming politicians, we do reserve the right to revise and extend our remarks, including some terminology changes between traditional and VIM-compliant usage. For example we borrowed the term Measuring “Function” from SpecTrack™ for an instrument feature, but that tends to conflict with the VIM’s “measurement function,” which means a mathematical function such as our “Quantity Function.”

MII Front Lines

That does it for a first draft of our MII instrument specifications data model. We haven’t defined exactly what kind of binary or textual data each element represents, but we postpone that until after we model each of our MII communication vehicles (certificates, accreditation scopes, etc.). To actually field MII spec sheets, we lack only explicit standards and software, each driving the other in chicken-and-egg fashion. If standards or recommended practice writing bodies and software vendors put troops on the ground to attack those obstacles, we should accomplish our MII quality and effectiveness objectives. But truth lies in the detail that we will refine as we receive the battlefield reports.
Speaking of action reports, two previous MII-related software developments came to our attention since the last installment. We previously noted the Mudcats SpecTrack™ application, but overlooked the SpecMaster Worksheet in the UncertaintyAnalyzer™ product from Integrated Sciences Group. The worksheet creates and saves electronic instrument specifications and includes an equation scripting editor with access to defined parameter values. So, we have at least two systems in the field progressing toward MII specifications.

Secondly, the author recently downloaded and lately read two NPL reports: One describes NPL experience and lessons learned from remote calibration over the internet, something we haven’t discussed here other than mentioning Cal Lab Solution’s recent undertaking along that line, but definitely of interest.
The other details an exciting experiment in creating an example pdf calibration certificate from structured measurement data. Exciting? Yes, not because its plot thrills, but rather because someone undertook that already and developed an elegant solution that we might extend and standardize for our MII test and calibration certificates, an upcoming topic. Their strategy constructs XSD and DTD files to describe data and document formats. With those definitions, software digests, validates, and processes raw XML-formatted measurement data to output intermediate curve-fitting results and a final calibration table, both XML files themselves. It then combines all the data with an XML customer file and a certificate template to render a nicely formatted pdf certificate. The process works much like what Fig. 2 envisions for spec sheets.
We might generate MII certificates similarly, but also would imbed the electronic data in the certificate for direct machine-to-machine transmission and consumption. Kudos and thanks to Robin Barker, Graeme Parkin and colleagues for their prescient contributions from 2006. We will watch NPL for further MII advances. You may download the reports and other goodies at
As always, we welcome news, thoughts, ideas, and feedback from the MII campaign. Don’t forget the upcoming NCSLI Workshop & Symposium mentioned elsewhere in this issue–more on that next time.