Toward a Measurement Information Infrastructure
Mark Kuster, Pantex Metrology
Hello, one and all. We return again to continue discussing this Measurement Information Infrastructure (MII) proposal. Please note the alternative terms “Metrology” and “Measurement” Information Infrastructure. The ideas, standards, and software we develop should benefit test & measurement customers as much as metrology laboratories, so we may as well open up to the whole measurement spectrum early on. Yes, the term metrology already envelopes all measurement by definition, but the wider testing world often considers metrology something separate.
Speaking of inclusiveness and cooperation, we hope everyone who attended this year’s NCSLI 2013 Workshop & Symposium in Nashville enjoyed the conference and received a great return on their investment. Hopefully you also noticed ways the ideas, proposals and discussions might fit into an MII. Likely, few if any of the developers, authors, or Conference Committee members had an MII in mind when they considered their contributions, but nevertheless, many interesting topics connected to the concept.
The theme, ‘’Metrology in a Fast-Paced Society,’’ spoke to economic competitiveness in a world-wide economy, a consideration near and dear to our MII. In his keynote address, Peter Unger outlined the past and future of accreditation in a world already (manually) verifying accreditation scopes, authenticating traceability, modeling uncertainty on smart phones, and exchanging data over the internet 24/7. That fortuitous topic melds perfectly with MII concepts from previous articles; perhaps it sparked further interest in an information infrastructure for measurement quality that would automate those activities.
The conference’s automation topics included a LabVIEWTM tutorial and dedicated software sessions. Several tutorials, papers and discussion panels covered specific instruments, measurement disciplines, specifications and test point selection. That work will augment the knowledge we will draw on for MII instrument models. Other events addressed traceability, accreditation, uncertainty, the SI and other MII-linked topics. Bob Stern, Agilent Technologies, drew parallels between the MII and the “Vision 2020” topic that one panel session considered. If you attended committee meetings, you may have participated in discussions on calibration intervals, equipment specifications, Z540, measurement risk, uncertainty, ILCs, calibration procedures, metrology practices and other topics overlapping MII interests. The vendors–many offer products and services that will play key roles in building a measurement information infrastructure–also provided food–um, for thought. NAPT, in one particular example, unveiled a sweet web-based ILC-PT management system that allows all participants appropriate access to shared data, analysis and mechanisms for automatic report generation in your own format. John Wilson, Agilent Technologies, presented an impressive world-wide data sharing and calibration process monitoring system.
Okay, back to the matter at hand. Our first MII article identified a few important measurement communication vehicles; namely, test and calibration certificates, instrument specifications, and accreditation scopes, with ILC results as another possibility. To solidify the MII we should begin collecting ideas for software and standards to address the three main MII elements that will handle those documents: measurement data models, web services, and the low-level data formats for both. Let’s ignore formats for now–we have several choices there, including YAML, JSON, HDF5, XSIL, XBC, NetCDF, XML and its kin, a custom-designed structure, and plenty of other alphabet soup. We would likely want to use the same storage format(s) for all MII vehicles, so we will postpone exploring the options until we know more about what data the vehicles will encapsulate. Web services include all those B2B-type communication protocols that would enable computer networks to advertise, discover, and transfer measurement information. Again, we postpone that until we have something solid to communicate. That leaves data models (content and high-level structure). The previous article touched on certificates to motivate and illustrate the MII concept, but before we calibrate equipment or even search for accredited bodies, we would like to have a measuring instrument in mind.
So, in this installment, let’s begin to consider instrument specifications–how we might encode them electronically so that any measurement-related software package may read, interpret and use those specifications to our advantage. We mentioned in previous articles the potential for MII-enabled software to automatically locate and identify test equipment on the market that meets specific functional, range, and accuracy requirements. We also floated the notion that MII-based instrument spec sheets might include an instrument performance model that allows MII-aware software to rigorously determine instrument-dependent measurement uncertainties without waving hands and casting spells to guess them from the warranted specifications. Such software might also identify optimal calibration test points, evaluate logistical deviations from the optimal points, and generate automated calibration procedures.
How do we translate our normal human-readable specifications into a machine-readable MII spec sheets? First off, without endorsing any specific products, we should mention that folks have already accomplished that to various degrees. Fluke’s MET/CAL® has long had accuracy files to store basic measurement standard specifications. My own laboratory used in-house software for storing, linking, calculating, and using UUT and measurement standard specifications starting in the mid-90s. Edison ESI’s SpecTrack, part of its MudcatsTM Metrology Suite, serves up a particularly sophisticated example. At the conference, Karen Semer, AFMETCAL, mentioned the USAF’s efforts to collect electronic specifications in SpecTrack. Other systems no doubt exist, like the Navy’s METBENCH. However, I know of no two systems that will share or interchange specifications–we lack a standard data model and storage format. Even that idea arose years ago–Kevin Sullivan and Alex Lepek suggested such an initiative at NCSLI 2005–but the measurement community has yet to accept that challenge. However, don’t despair; electronic data in any format puts you ahead of the game–you may use software to convert it one and all to any other format that comes along.
A Specification Data Model
We won’t have space here to completely flesh out a specification data model in one shot, but we will sketch enough of the skeleton to see how it might work and continue from there next time. Essentially, the above mentioned software systems define unambiguous data elements (kind of quantity, qualifiers, nominal value, floor, fraction of full scale, resolution, etc.) to capture relevant human-readable spec information so that software may process it in a defined way. We suggest here that we may capture all such descriptors in a machine-comprehensible structure. For example, the specification
- Measurand: Voltage Indication, RMS, Channels 1-4, 1 V, 10 V, and 100 V Ranges, 20 Hz to 1000 Hz, -1 V to 1 V Voltage Offset
- MPE: (0.01 % of stimulus + 1 µV + 1 LSD)
has obvious numeric attributes to which we might attach semantic meaning to enable automatic tolerance calculations, matching measurands to specifications, automated calibration quality checks, etc. We may extend such formats indefinitely to handle measurand qualifiers regarding any influence quantity: temperature, pressure, humidity, power quality, noise, vibration, etc. But let’s start at the top and work our way down to that detail.
Ideally, a consensus data model would describe not just simple specifications but also arbitrarily complex specifications for instruments, accreditation scopes and measurands of all types. Enter the VIM. Chuck Ehrlich’s papers and presentations have stimulated many of us to appreciate the VIM’s potential for standardizing measurement science. Some would no doubt say that it already did so by its very existence, but much of the measurement world has yet to adopt it in practice. Indeed, as the VIM prefers precise and unambiguous definitions, its language comes across more academic and lofty than the jargon many of us normally use. However, international scientific and engineering organizations from metrology, physics, instrumentation, chemistry, and medicine created and agreed upon the VIM. We do call our field measurement science, so let us see what the VIM offers.
The VIM does not define specifications, but does define the kinds of things we might specify, e.g., measuring systems, and the concepts we might use to do so, e.g., MPE. So, beginning at the measuring system level, the VIM gives us
set of one or more measuring instruments …used to generate measured quantity
values within specified intervals for quantities of specified kinds
device used for making measurements …
Already, we see some concepts the data model should allow us to specify: intervals (ranges) and quantity kinds (voltage, length, pressure, etc. with appropriate qualifiers). SpecTrack, for example, organizes instrument features into measurement functions of multiple ranges, each with multiple ranges with multiple parametric qualifiers and error limits. If we at least temporarily use that nomenclature and extend the upper hierarchy outward to cover measuring systems, we have the high-level data model.
- System Identifier
- Other System Properties
- Measuring Instrument 1
- Measuring Instrument 2
- Measuring Instrument
This system has instruments, the first of which has measurement functions that we will associate with the VIM’s “quantity kinds” and the first function has separate ranges. We will allow the system to include any number of instruments, functions, and ranges.
The model may imply a hierarchical structure but the (future) data format may not take that form; two instruments with the same range or function might simply reference the same predefined entity in a flat format. The model’s identifiers will distinguish similar entities, and more important, help this (MII-aware) instrument specification, as an innate feature, to wrap itself inside a human readable (pdf) spec sheet formatted per the manufacturer’s own document template; in other words, generate a pdf file that looks like a normal, but fully developed spec sheet, yet contains all the structured machine-readable data regarding the measuring system. The identifiers may appear like.
System or Instrument Identifier
- Unique ID (GUID, hash, URL, DOI, etc.)
- Specification Document Title
- Specification Document Date
- Nominal Physical Size
- Nominal Weight
- Etc., Etc.
Function or Range Identifier
- Unique ID
Looking at other high-level equipment characteristics, we recognize that artifact-type instruments (resistors, gage blocks, mass standards, etc.) embody quantities, whereas other instruments indicate or display quantity values. The VIM designates these categories “material measures,” “indicating measuring instruments” and “displaying measuring instruments,” respectively. Material measures have assigned quantity values, indicating measuring instruments output signals representing quantity values, visual, audible, or otherwise, and displaying measuring instruments display quantity values visually. For the moment, we call this property the indication method and we let it vary function by function. Regardless of method and by definition, all instruments provide quantity values (also VIM: “indications”) by some means.
The ranges come in different flavors also. A spec sheet may list a “200 mV Range” but specify the actual range as ± (0.0 mV to 199.9 mV), and then later (in the fine print?) we find out that the warranted specification only applies at or above of full scale, or ± (10.0 mV to 199.9 mV). The VIM folks understood that, so it supplies us the respective terms “nominal indication interval”, “indication interval” and “measuring interval”. Any quoted measurement uncertainty and conditions apply to the measuring interval. If our instrument also has, say, a disjoint transducer with a specified calibration curve, then the measuring interval may involve some other quantity, such as the force range ± (13.2 N to 207.8 N).
Taking what we have so far then, a single measurement function looks like
- Function Identifier
- Indication Method
- Quantity Kind
- Other Function Properties
- Range .1
- Range .2
- Range .
For material measures, we simply specify ranges with equal interval end points so that the intervals effectively collapse to single indications or quantity values. We have many more instrument model properties to handle, but that lays out a basic specification structure to think about until next time. We will pick up where we left off then.
Some folks, after having observed analysis practices not to their expectation, would have us restrict exposure to advanced measurement science concepts until everyone reaches the same competence level. I disagree, to say the least; let everyone freely choose what to use. Perchance the fault, if any exists, lies not in personnel, training, complex tasks, etc., but instead in job assignments and wasting our resources. Maybe we should consider what humans and machines each do effectively and divide tasks accordingly. We might take another look at those things with keyboards and mice sitting in our offices, or those tablets, or that phone in our pocket. They don’t look like an abacus but they will actually compute, not just send email and show YouTube videos. Let us banish our calculators and spreadsheets to museums and create a computing infrastructure that will handle the complicated detail we so humanly avoid. Substantive, quality “metrology made easy” will arrive through automation, not shortcuts.
If we examine the electronic design automation (EDA) field, we find manufacturers that provide accurate mathematical models for their electronic components, consensus standards that define model structure and parameters, and standards-aware software that not only simulates circuits of modeled components to predict performance, but at the next level, has the intelligence to select the appropriate components and automatically design the circuits. Why not do the same for metrology? If measurement professionals insert an instrument into the traceability chain, it should come with an MII model that enables MII-aware software to seamlessly propagate quantity values and uncertainties through the model and hence down the traceability chain just like EDA and simulation software will propagate signals through a component. Beyond that, MII software should automatically select the calibration points and design the instrument’s calibration procedure to meet local requirements.
Truth lies in the detail, and a rigorous instrument specification vehicle will require miniscule rigorous detail before we finish, but the payoff will come. We will continue our efforts in the next issue. Meanwhile, thanks for your time and keep the ideas flowing.