Toward a Measurement Information Infrastructure
Instrument Specifications, Part 2
Mark Kuster, Pantex Metrology
Greetings again, friends and colleagues. We hope you track our thoughts on the Measurement Information Infrastructure. The last installment began sketching a high-level data model for instrument specifications, based on the idea that we would like our software to know every important thing about candidate instruments in order to help us select the most appropriate one, calibrate it, and use it. We started at the measuring system level and worked our way down through measuring instruments and measuring functions to measurement ranges. Our loose data model has holes to patch throughout, but for now let’s home in on the measurement range where the most interesting things happen.
Bones to Pick
We left off last time with the skeleton range model
- Range Identifier
- Nominal Indication Interval
- Indication Interval
- Measuring Interval
- Other Range Properties
Recall that the VIM, which we reference to build our model, uses “interval” to mean a range between two values.
For one particular instrument, the actual data in text form might look like
- Range ID XXXXXXXX
- (0 mV to 200 mV)
- (0.0 mV to 199.9 mV)
- (10.0 mV to 199.9 mV)
- More data…
We often describe the range by its nominal indication interval, but it also has an actual indication interval that more exactly delineates the indications it may produce and a measuring interval that further refines the indications to which the specifications apply. The indication interval would interest us in a purchase decision, whereas the measuring interval would dominate the instrument’s use as test equipment or a measurement standard.
Many instruments have multidimensional ranges. For instance, an impedance meter’s inductance measurement function might have a primary nominal range, with additional qualifying ranges such as test signal frequency, impedance magnitude, quality factor, test cable length, ambient temperature, etc. Each qualifying range would include nominal, indication, and measuring intervals. The specifications apply when all influence and input quantities lie within their measuring intervals.
For single-valued artifacts (VIM: material measures), the intervals collapse to single values. So, for example, we would store to in the nominal indication interval to define a nominally mass. The indication interval might correspond to its accuracy class, say, for ASTM Class 1 and the measuring interval might store its assigned quantity value, say, , as both endpoints.
Some properties we would likely calculate from others. For example, the VIM’s range of the nominal indication interval (nominal span) comes to 200 mV - (-200 mV) = 400 mV; similarly, the indication range equals 398.8 mV. The specifications apply to the two (negative and positive indication) spans computed from the measuring interval, both 189.9 mV.
What other range properties might we want? Quite a few actually. The VIM mentions resolution, sensitivity, selectivity, discrimination threshold, dead band, detection limit, stability, drift, variation due to influence quantities, and step response time. Inexperienced users often highly prize one or more of the preceding properties when selecting a measuring instrument. Though important, we will postpone addressing those properties to a future article and first emphasize measurement accuracy and uncertainty, probably the most critical data after measuring interval.
We hope everyone would want to know the instrument’s “accuracy.” For strict computation though, we avoid that term because the VIM defines measurement accuracy as a general “closeness of agreement” concept without any quantified value. So instead, we speak of MPE, something we will put a number (and unit) to. For comparisons and conformance tests, we would like to compute the instrument’s MPE on demand for any legitimate measurand. As we mentioned last time, the community has long since established straightforward methods to do so.
Most instruments specify MPE via one or more of the following simple formats: units, LSD, of full scale, of stimulus. A data element collection such as the following would handle those MPE formats: Floor, Digits, Counts, FS, pFS, pStimulus. For example, we would store the MPE as pStimulus = 0.01 %, Floor = 1 , Counts = 1. Once entered in a database, software may easily calculate MPE for any indication on any such instrument range. Occasionally the manufacturer defines full scale or range differently; for example, the indication interval may go up to 1.2 units, but for purposes of specifying MPE, the manufacturer defines full scale as 1.0 unit. Therefore, each range might have a separate data element for the full scale value.
The above scheme only handles straight-line specifications and piecewise combinations thereof. For human digestion, manufacturers almost always simplify their specifications to fit that format, drawing straight lines over the tighter, but unruly, specifications that engineering analysis and type testing discover. If we incorporate algorithms in the MII to handle more complex specifications, that would allow manufacturers more freedom to specify closer to actual performance. Furthermore, many instrument specifications do not fit such a rigid structure, either outright, or due to modifiers in the footnotes. Temperature and other influence quantities may either restrict the specification to some range of the influence quantity or alter the MPE directly as a function of the influence quantity. So, consider the following more versatile model:
- Specification Interval
- Quantity Function
- Condition Equation 1
- Condition Equation 2
- Condition Equation
- Calculation Script
- Quantity Symbol
- Default Value
A range might well have multiple MPE specifications, one for each Specification Interval, the calibration interval over which the manufacturer guarantees the MPE. We therefore include that data element here. The quantity function would define the relationship between the MPE and the range’s influence and input quantities as an equation. For the example above, the electronic specification file would contain a function similar to, where and represent the input voltage measurand and range resolution, respectively. Each measuring interval would have an associated quantity definition to link the instrument’s input and influence quantity values to their respective variables in the MPE function. Thus, an equation interpreter replaces the inflexible hard-coded calculator and simple database fields. The interpreter evaluates the MPE equation based on the variable values, with default values for any quantity value not otherwise supplied. This model supports any specification a mathematical function will represent. By defining the measurement error , or referencing the measurand symbol, an equation format also naturally supports asymmetric, e.g., +4 , -6 , and one-sided specifications, e.g., : The optional condition equations would supplement the primary, influence, and input quantity measuring intervals for more complex conditions involving combinations of quantities, such as frequency-amplitude restrictions on calibrator outputs. Such a combined condition might take the form , where the primary (voltage) and secondary (frequency) measuring intervals assign the variables and , respectively.
As an alternative to the equation interpreter, MPE equation, and condition equations, a general purpose scripting language with a parameter interface to the quantity values and access to the other specification data would also fit the bill. The script attached to each set of measuring ranges would provide unlimited flexibility for electronic specifications. Scripting languages abound and typically run on many platforms. Python, for example, a free open-source language designed with mathematics in mind, runs under Unix, Linux, Mac OS, Windows, OS/2, Solaris, Android, iOS, and many others. Deploying scripted spec sheets, however, will require security protocols to guard against malicious code.
Whether MII spec sheets use the equation interpreter or scripting option, a Renderer object would provide the information MII software would use to render the specification for human consumption according to an OEM - or user-designated template. The spec sheet will include the OEM version, in a pdf, html, or other universal format, at the measuring system level.
That grafts a few more bones to our framework. As mentioned in the last installment, some software already exists along these lines; we only lack the extensions discussed here and a standard data model for exchanging and sharing the specification files between metrology systems. The MudcatsTM SpecTrack module allows the user to define input parameters, intermediate variables and a script-like variable assignment sequence. That strategy provides powerful calculated specifications, but as of yet has no standardized or shared data format. Currently, SpecTrack scripts also lack access to some specification data the script author might want to use. SpecTrack will also generate human-readable files but requires third party software to change the format.
We have not yet considered instrumental measurement uncertainty, something quite different from MPE. Below the NMI level, many laboratories derive measurement uncertainty estimates for instruments they use as measurement standards from the MPE. Many practitioners, especially outside the United States, avoid this practice, due perhaps to the VIM’s traceability definition, and maybe because the derivation involves a bit of black magic. Though manufacturers consider measurement uncertainties when setting specifications, the warranted MPE represents a legal contract between the vendor and buyer and confidence proportional to the manufacturer’s reputability that the instrument will perform accordingly. In other words, the specs typically bury uncertainty under prudence.
Though we may choose to take the MPE as a coverage interval, an instrument owner rarely has the MPE’s corresponding coverage probability or probability distribution for the specific instrument at hand and therefore makes somewhat arbitrary and typically conservative assignments. The GUM certainly allows estimates in the uncertainty evaluation process, but we would like more rigorous information. Overestimated uncertainties incur higher expenditures for equipment and maintenance plus lost marketplace opportunities. Underestimated uncertainties (based on imprudent manufacturers’ specifications) increase the risk of consequence costs. Either way, we lose value.
The calibration process assigns uncertainties to a given measuring system, so our specification data model will not likely include assigned uncertainty elements; the calibration certificate would carry that responsibility. However, to propagate uncertainties through a measuring system, we would like the spec sheet to include the system’s parameterized measurement model, a quantity equation relating the system indications to measurement results based on calibration corrections. The VIM’s calibration definition sheds some light here: calibration operation that …establishes a relation between …measurement standards and corresponding indications with associated measurement uncertainties …to establish a relation for obtaining a measurement result from an indication The specification details a measuring system’s designed performance; calibration not only assesses an instrument’s conformance to that design, but also estimates the instrument model parameter values, the instrument’s actual performance. Calibration transforms the specification’s model into a relation for obtaining traceable measurement results from the measuring system’s indications. When we use the measuring system as a measurement standard, the calibrated model then provides a true uncertainty component for the uncertainty analysis without recourse to MPE and questionable cookbook recipes. To implement seamless uncertainty propagation through measuring systems we add the data elements
- Quantity Function
- Auxiliary Variable Definitions
- Parameter Definitions
- Standard Modeling Uncertainty
- Calculation Script
A typical linear range model’s quantity function would appear like showing a measurement result or output quantity equal to an indication multiplied by a gain factor , nominally , plus an offset , nominally . Calibration would estimate the actual parameter values for and.
Again, as with the MPE equation, the MII spec sheet might use an equation for a mathematics-aware interpreter, a script, or both, with hooks to each measuring interval’s defined quantity variables. The designer might include Auxiliary Variable Definitions for intermediate computed quantities of interest. Parameter Definitions define the model quantities subject to calibration and would include nominal values for the model’s designed performance, i.e., for zero measurement error. Finally, the manufacturer or another entity would supply the standard modeling uncertainty determined by type testing, a typical residual or other uncertainty component that quantifies the model’s variance from reality.
To harden things a bit, let’s examine a simplified model for an arbitrary length standard.
Example Model Data
- Auxiliary Variable Definitions
- Parameter Definitions
- 500 nm
Examining the data item by item, we first assume that the spec sheet defined a nominal length indication interval 25 mm to 25 mm, having the assigned symbol and an appropriate influence quantity measuring interval with symbol (mean instrument temperature). The quantity function produces a length measurement result given the indication, temperature, and model parameter values. The quantity function has two parts in order to make available a defined auxiliary variable, the certified length. The parameter definitions list the remaining quantities and their nominal values, all subject to variation and untraceable without calibration: length deviation from nominal, certification temperature, and expansion coefficient. The 500 nm modeling uncertainty (within the defined measuring intervals) accounts for ignoring nonlinear expansion, contact force and geometry, oxidation and handling over the specification interval, and other modeling deficiencies.
We have implied that each measurement range includes its own measurement model. Some instruments may follow that arrangement: those with entirely independent measurement functions and ranges. However, in the family of ranges, functions, and instruments comprising a system, some measurements will often depend on others and therefore we should account for the uncertainty deductions and penalties arising from those correlations. The measurement model would then default to the system level, as a vector equation or set of scalar equations, to capture all the interactions. For example, a DMM’s resistance and voltage measurement accuracy may influence its electrical current accuracy. A hygrometer’s ambient temperature accuracy likely affects its relative humidity accuracy. Therefore, the specification model should allow measurement models at any level. If a range lacks a model, the function model will define the range behavior, if a function lacks a model, it will use the instrument model, and so on.
Home on the Range
In summary, we now have the following preliminary draft specification model at the measurement range level:
- Range Identifier
- Full Scale Value
- Other Range Properties
- Influence or Input Quantity 1
- Influence or Input Quantity 2
- Influence or Input Quantity
- MPE 1
- MPE 2
- Range Measurement Model
All that for just one measurement range! Of course, with the right software, computers count that much data as child’s play. To maintain our focus and motivation for all this work, let’s consider the benefits from an MII-aware process flow involving specifications.
- Manufacturers create MII spec sheets for their instruments.
- Instrument vendors post the MII spec sheets on their web sites.
- You have a new measurement application and enter your measurement range and MPE requirements into your MII lab management software.
- Your software locates all vendors hosting MII specifications, reads their spec sheets and lists the vendors and instruments matching your criteria.
- Your software also searches MII-compatible accreditation scopes and locates calibration service vendors accredited to calibrate the instruments.
- You select an instrument, vendor, and lab.
- The first time the lab calibrated the model you chose, they downloaded the MII spec sheet. The lab’s MII-aware calibration software analyzed the spec sheet, selected the optimum test points using the MII measurement model to predict uncertainty and risk throughout the measurement space, created an automated calibration procedure, and set the MPE for each test point.
- In fact, the lab previously downloaded MII spec sheets for its own instruments to lower costs, and used the modeling features to tighten up its uncertainty estimates and accreditation scopes, thus capturing your business.
- When the lab calibrates your instrument, its MII lab management software creates an MII calibration certificate that includes certified parameter values for the instrument measurement model.
- Your software receives the calibration certificate, combines the spec sheet measurement model with the certified parameter values and propagates the resulting instrumental measurement uncertainties to uncertainty analyses in your calibration workload that use your new measurement standard.
- If you use the instrument for product testing, your MII testing software uses the spec sheet and certificate to correct for instrument bias, estimate false accept and reject risk on your production line, calculate measurement reliability, and determine when to return the instrument for recalibration.
- You admire the clear skies and watch the data roam …or finally accomplish some creative work that computers won’t do.
Sing Along, Please
We have begun to frame in our first MII communication vehicle, instrument specifications. When complete, the specification model will outline how an MII spec sheet might work, subject to community input and standardization agreements. We still have “other properties” to specify at all levels, including a gaping hole (automation commands), so we will flesh out more details next time.
Meanwhile, we fast approach the 2014 Measurement Science Conference in Long Beach, CA. As with many conferences these days, its theme, “Achieving Competitive Advantage through Measurement Innovation,” coincidentally speaks to our MII goals. If you attend the seminars, tutorials, conference sessions, or committee meetings, keep the MII in mind and consider how what we explore now may seed new capabilities and efficiencies down the road.
A couple MII-related software developments also come to mind. ATS Metrology recently offered third-party support services for Edison ESI’s Mudcatswith an eye toward a long-term migration to a new product. Hopefully the measurement community has an opportunity there to see some MII concepts implemented in the future. New software functionality often has long lead times, so whether you use MudcatsTM, IndySoft’s Management Software, Fluke’s MET/TEAMTM, ATS’s METBENCH, or another product, begin asking your vendor about MII features now.
In the second development, along a parallel line, Mike Schwartz presented the Metrology Services BusTM concept from Cal Lab Solutions at the August NCSLI New England Region Meeting. Mike proposes a modular software solution architecture to flexibly integrate metrology systems. In the process, Cal Lab Solutions develops APIs for communicating metrology information between computers. If our industry standardizes such communication protocols, then everyone may adapt their software to them, taking us far down the MII road.
As always, we welcome your MII-related news, thoughts, ideas, and feedback. Until next time.