Toward a Measurement Information Infrastructure Déjà Vu

Mark Kuster, Pantex Metrology

Welcome to your conference, the 2014 NCSL International Workshop & Symposium. We hope it proves productive for you in many ways.
The previous Measurement Information Infrastructure installment wrapped up a three-part series outlining a high-level data model for electronic instrument specifications. We have other metrology information vehicles to move on to (test and calibration certificates, accreditation scopes, etc.) as well as topics to cover on web communication services, software, and data formats to make it all happen. This time though, we take a break from data modeling to discuss the conference and some interesting MII-related endeavors.

Exploring the Wilderness

A while back, I drove through a parking lot hunting an unfamiliar vehicle–my sister’s black Jeep. Practically the last thing I remember about jeeps before that involved US Army doctors cavorting around in the TV series M*A*S*H, but now I see Jeeps everywhere. Black Jeeps. You know the phenomenon: Something once relegated to subconsciously processed and ignored background information intrudes into your sphere of awareness and suddenly, what didn’t seem to exist the day before stares at you from all sides. Thankfully, this MII column has begun to work that way.

Though we knew of few concrete examples, we began this column with the assumption that existing technology provides us more than enough resources to build a measurement information infrastructure to seamlessly move test and measurement data between laboratories and their customers, manufacturers and accrediting bodies–without paper and with minimal human intervention. Now, past work seems to appear out of the luminiferous aether. Last time, we mentioned Robin Barker and Graeme Parkin’s work at NPL to process calibration data and generate certificates using XML–a lovely proof-of-concept demonstration from 2006 that didn’t impinge upon our awareness here until 2014. Without the internet, we might never have learned of their efforts.

That last article spurred Jerry Hayes, one of Metrology’s pioneers, to write us. He described CATS, a one-time US Navy project for finding global metrology laboratories with capabilities suiting US military customers. It apparently involved electronic datasheets and uncertainty statements and probably much more. In a similar vein, the MII envisions machine-readable accreditation scopes and instrument spec sheets that would enable the automatic matching that CATS sought. We also note PMSC’s AssetSmart® and SMART ENCATS® enterprise management software, which offers structured instrument cataloging and flexible searches by performance attributes (specs) with connectivity among its users, though perhaps no standard format for exchange with other software. So, we see our ideas have already long stewed in metrologists’ thoughts and we suggest their time has now come. Indeed, yet another development seems to have it moving already.

XML pervades the interoperable data industry, having bred a plethora of data schemas for divergent purposes by virtue of its inherent extensibility. The NIST has developed UnitsML to represent measurement units and quantity values. MathML exists to encode symbolic and numeric equations of arbitrary complexity. Someday we may have a complete MetrologyML or MeasurementsML, perhaps encompassing the VIM and all other relevant terminologies. But, as it turns out, the aether just revealed another choice tidbit: Automatic Test Markup Language (ATML).

A joint industry-DoD working group created and published ATML from 2007 to 2010 as the IEEE 1671 base standard and several addendums and promoted it at conferences such as the IEEE AutoTestCon. Committee participants include

  1. Agilent-Vektrex
  2. Boeing
  3. Diagnosys
  4. EADS
  5. Geotest-Marvin Test Systems, Inc.
  6. Lockheed Martin
  7. National Instruments
  8. Northrop Grumman
  9. Rohde & Schwarz
  10. Summit Test Solutions
  11. Teradyne
  12. US Air Force
  13. US Army
  14. US Navy.

So what does it do? ATML defines XML schemas that standardize testing and maintenance data for exchange between automatic test systems, with a secondary intention to generate feedback for procurement decisions. ATML encodes data on tests, test systems, instruments, UUTs, interfaces, and test results. A manufacturer may describe a UUT in ATML down to its connectors, specs, and input-output signals and also write a separate ATML test protocol. The manufacturer or its customers use the test protocol to test the associated UUT on any system with the required equipment. Software knows the equipment requirements and may verify a test system using the system’s own ATML description. Theoretically, ATML files supply all the information required to identify equipment, make connections, handle communications, run tests, and generate results, all in a way that anyone’s software will understand. It seems just the thing upon which to build our MII!

Looking a little deeper, we see that ATML delineates a formidable array of simple and complex data structures as well as test actions and results. Editors exist to generate ATML for UUTs, test requirements, instruments and systems (test stations). It characterizes input and output signals per predefined IEEE 1641 models and matches those signals to ATML-encoded instruments and their connection ports. Products such as National Instruments’ TestStand™ and LabWindows CVI™ understand how to import ATML test protocols and generate test code. The instrument files seem versatile and include mappings between function specifications and the available instrument options. Several companies supply software interfaces for visualizing and analyzing the test results.

On the minus side, the working group appears to have targeted ATML strictly at the testing industry and so it includes data items that may not concern us immediately, such as power requirements, fault isolation, diagnostics, etc. More importantly, ATML lacks predefined structures for much of the metrology information we would like in our MII vehicles. Also, though aware of SCPI and many hardware interfaces, it apparently does not capture enough instrument nuances to completely avoid manual test code changes. Warnings also state that vendors may sometimes interpret the (ambiguous?) ATML standard differently, thus creating ATML files incompatible with other vendors’ products.
All in all, though, ATML appears to represent a significant step toward our MII. Perhaps we might write another international standard that extends it to our wish list. For further information, visit http://grouper.ieee.org/groups/scc20/ATML/Demonstrations/index.htm. You may also join as an interested party or participant at http://grouper.ieee.org/groups/scc20/bluesheet.html.

Conference Tidbits

As always, we like to highlight MII-related conference events. This year’s conference features a number of poster presentations, including many that may pertain to MII development. Examples may include

  1. 1318 “File Abstraction Layers for Data Storage”–Damien Gray, National Instruments
  2. 1342 “Considerations when Choosing Automated Calibration Software”–Michael Bailey, Transmille
  3. 1414 “Hosted Calibration Management Systems”–Thomas P. Pessa, Exelon PowerLabs
  4. 1485 “An Enterprise Resource View of Metrology Software Systems”–Michael Schwartz, Cal Lab Solutions
  5. 1486 “Calibrating a UUT on a Remote Computer Using Fluke MET/CAL”–Michael Schwartz, Cal Lab Solutions
  6. 1501 “The Intelligent Automated RF Measurement System”–Nghiem Ngun, Raytheon Co.

Among the conference papers, the agenda has Marcus Flack of Fluke Calibration scheduled to present “Selection and Implementation of Metrological Automation Systems” and we happily credit Suresh Ramachandran from National Instruments, whose presentation “Lab2Lab Electronic Exchange of Information using ATML” sounds especially interesting. Perhaps Suresh will show us how to extend or use ATML for metrology.

Networking

The MII and previous efforts envision a measurement world all about networking, specifically, machine-to-machine communication to improve measurement quality and make life easier for metrologists and other measurement professionals. Your conference has obvious potential for personal networking and getting involved–vendor exhibits, committees, tutorials, and interactive sessions. As you take advantage, think a little about the MII. See you there!
mjk@ieee.org