What a difference a decade makes. During the past 10 years, calibration practices for industrial instruments have changed.What a difference a decade makes. During the past 10 years, calibration practices for industrial instruments have changed.
Driven by a quest for better quality, the need for lower production costs, and an increase in government regulations, companies have adopted in situ (field) calibration. Equipment manufacturers have responded by reducing calibrators' size and weight and increasing their capabilities.
Some of the newer field calibrators can store information and communicate electronically. When used with calibration management system (CMS) software, the calibration process becomes easier to schedule, the calibration practices become more uniform, and the recorded data is more accurate.
It works like this. The CMS software downloads a list of instruments and their test procedures into the calibrator. A technician then travels to each instrument on the list and uses its procedure to test and adjust the instrument. The test results are automatically stored in the calibrator for later retrieval (upload) by the CMS software.
TerminologyASCII American standard code for information interchange |
Unfortunately, the calibrator manufacturers and calibration management software developers never established any standards to achieve this common goal of downloading procedures and uploading results.
Every calibrator vendor created its own communication protocol and its own data set that can transfer with the protocol. Every CMS software developer created its own calibrator support and data management systems.
The result is that every CMS developer that wants to support multiple calibrators must write a different driver for each one. Every calibrator manufacturer that wants its hardware supported by a calibration management system must provide individual support to the developer. This is expensive for every-one involved.
Wouldn't it be nice if . . .
Field calibrator manufacturers want as many software packages as possible to use their calibrators. To reduce the development and support burden, developers need a way to write a single driver that can be used by anyone who wants to communicate with their calibrator.
CMS developers face the problem from the other side. They want to support as many calibrators as possible. It is a daunting task to learn dozens of proprietary interfaces and design a product that can extend to whatever new calibrator arrives on the market.
Users don't want their CMS product choices to be limited by the number and type of supported calibrators. They don't want to wait months for functionality that should be available today.
For those who worked with software in the old DOS days, this problem is familiar. Remember when every software application provided its own printer support? This was a nightmare for printer manufacturers, application developers, and computer users. Microsoft Windows, with its defined printer driver interface, brought a semblance of order to that madness.
Developing this type of specification is not a trivial task. The designers must consider a number of factors:
The Southwest Research Institute has extensive experience in instrumentation, calibration, and software development. The engineers at the institute developed the field calibrator interface (FCINTF) specification. Let's examine how this specification addresses the design questions.
At this time, the most common deployment platform for CMS software is Microsoft Windows 95/98/NT. While there are several ways to design and build interfaces in this environment, the most universally applicable is Microsoft's component object model (COM). It provides an application-independent interface that can be programmed in a variety of languages.
Selecting the common functions, data fields, and procedures was the hardest task. The institute reviewed the communication protocols of 16 field calibrators from eight different manufacturers. It then combed through demos, literature, and reports from six different CMS applications.
Combining this research with review work by members of the ISA Field CalibrationTech-nology Committee (FCTC) yielded a very reasonable set of functions and data fields.
The unambiguous data format problem isn't familiar to most people, vendors included. Consider the simple case of calibrating a temperature transmitter. Something must tell the field calibrator what type of probe the transmitter is using.
Let's say it is a type K thermocouple. For one calibrator, the driver must send the ASCII string "TC K," for another it is the string "TYPE K," and for another, it might be the number 7 (taken from a table of supported probes). None of these match the internal data representation the CMS applications use.
Rather than inventing a new solution to this problem, the institute decided to adopt the Hart Communication Foundation's common tables for unit codes, temperature probes, and the like. The institute presented the specification's first draft to the FCTC in May 1998. There was significant interest expressed, and several committee members volunteered to review it.
A design for the world's greatest mousetrap is worthless until someone builds one. At the same time developers were working on FCINTF, Fisher-Rosemount implemented a new calibration management addition to its asset management system product.
Rather than designing yet another proprietary interface, the company decided to use this new field calibrator interface. Fluke joined in and developed drivers for its 702, 743, and 744 calibrators. Druck also participated by developing drivers for its DPI605 and TRXII products.
Rosemount's software works with these three drivers. The user selects a calibrator from a list, much like selecting a printer driver. Each calibrator driver looks the same to managing software because the driver hides all of the implementation details, including communication protocols, data ordering, storage, and retrieval.
As with any specification, FCINTF will evolve over time. However, the strict versioning rules of COM ensure that future enhancements will remain backward compatible. This first version of FCINTF works easily with high-level languages that have sophisticated COM support, such as C++ and Java.
There is growing interest among end users to have an interface they could use in Visual Basic. This would offer an opportunity for companies to develop specialized applications that could exchange data with a variety of calibrators without having to learn all of the proprietary communication protocols. IT
Kenneth Holladay is a principal engineer with Southwest Research Institute. He has 18 years' experience in instrumentation, software design, and system implementation. He is active in the Hart Communication Foundation and on the ISA Field Calibration Technology Committee. Holladay has a B.S. in chemical engineering from the University of Florida and is a registered Professional Engineer. His address is kholladay@swri.edu.
Danny Lents is a research engineer with Southwest Research Institute. During a 20-year military career, he gained advanced metrology, calibration, and measurement equipment repair and calibration experience. He has spent the past four years developing software for automated testing and calibration applications. Lents has a master's degree in computer engineering from Saint Mary's University in San Antonio, Texas. E-mail him at dlents@swri.edu.
They get in your faceAn interface can be described in many ways. Primarily, it is a "contract" between the client and the server. The contract specifies the complete details for a set of functions you can call to get the object to do something. This effectively defines the object's behavior. The only way to access a COM object is through one of its interfaces. Documentation of the contract has to occur outside of the code because users of the COM object don't receive documented source code. Documentation of the FCINTF component goes through descriptive function names and detailed comments in its interface definition language file and by a document titled Specification for Field Calibrator Interface. To obtain the documentation, go to ftp.swri.edu/pub/fctc in the file FCINTF.ZIP. |
Build with binary blocksThe field calibrator interface, or FCINTF, is based on Microsoft's COM technology. Because COM is a specification detailing a language-independent, binary standard for building components, a COM interface contains no code. It is a specification written on paper that defines how a client and a server can communicate with each other. COM isolates the interface from the implementation details. This means a client can use an interface on a COM object without knowing anything about how the object was built or what programming language was used. Interfaces on COM objects are represented as lines with a circle, so a driver that supports the FCINTF looks like the figure on the right. This architecture allows a client, such as a CMS, to communicate with COM calibrator drivers from different manufacturers using the defined interfaces and methods. The client has a single view of the interface and doesn't care that the implementations may be radically different. |