The Use of Hardware Abstraction Layers in Automated Calibration Software

Transcription

1 The Use of Hardware Abstraction Layers in Automated Calibration Software Speaker: Logan Kunitz Author: Rishee Bhatt National Instruments N. Mopac Expwy. Austin, TX (512) Abstract Today s automated calibration tests systems depend greatly on interaction between the automation software and the physical instrumentation being controlled. This interaction creates dependencies between the software and the hardware, which can be compromised when an instrument needs to be replaced due to failure, obsolescence, or external calibration. Developing a Hardware Abstraction Layer (HAL) is a proactive method of mitigating the risks of planned or unplanned instrument replacement. A HAL decouples automated test software from the underlying hardware, facilitating instrument interchangeability. This paper will introduce the concept of industry-standard, vendor-defined, and user-defined HALs, describe their benefits and uses, and present a use case for implementing a HAL for a given set of instruments. Learning Objectives This paper will give the reader a basic understanding of what a Hardware Abstraction Layer is and why it is useful in automated calibration systems. The reader will have the knowledge necessary to apply these concepts to a system that they are developing or maintaining. 1. Introduction Calibration routines utilize software in a variety ways. Sometimes software is used simply for data entry and analysis, such as for storage in a database and calculation of measurement uncertainties. Often times, though, calibration routines utilize a full calibration software suite, which serves as a framework for procedure development and execution. Calibration software suites provide an interface for users to execute automated calibration procedures. The software handles all aspects of the calibration, including configuration, user interaction, data management, and report generation. One of the most critical aspects handled by automated calibration software is interfacing with the instruments used to calibrate the device under test.

2 2. Instrument Control In order to interface with the instruments in an automated calibration system, calibration procedures often utilize instrument I/O libraries, or drivers. An instrument driver is written in the Application Development Environment (ADE) of the calibration procedure, and provides an interface for configuring and reading from the instrument. An instrument driver is itself a software abstraction, in that it hides away the low-level implementation details of the communication with the instrument. Depending on the type of instrument being used, these low-level details could include Virtual Instrument Software Architecture (VISA) communication, Standard Commands for Programmable Instruments (SCPI), or calls to a Dynamically Loaded Library (DLL). The instrument driver wraps these lowlevel calls into a an Application Programming Interface (API), or a set of discrete, organized functions, each of which performs a specific task related to the instrument under control. Figure 1 shows the function tree for a benchtop DMM. The API is divided into six general categories based on function type. Each function sends a command to the instrument, receives data from the instrument, or performs some combination of the two. In addition, the function may catch and handle errors associated with the communication. While an instrument driver greatly simplifies instrument control, the driver is usually limited to a specific type of instrument or family of instruments. HALs provide greater instrument flexibility by further decoupling the calibration software from the instrument hardware in the automated calibration system. Their goal is to increase instrument interchangeability, allowing the calibration software to be used with any type of instrument. Figure 1. Instrument driver function tree.

3 3. HALs Instruments in an automated calibration system may need to be replaced at any time. Sometimes these replacements are planned, such as when an instrument must be sent out for external calibration or an instrument becomes obsolete. Other times, these replacements are unexpected, such as when hardware fails. In either case, a contingency plan must be developed for dealing with these situations. There are numerous strategies for dealing with replacement of instruments. Purchasing spare instrumentation ensures that a drop-in replacement is available if the instrument in service ever goes out of commission. While this is a proactive strategy that minimizes downtime, it also entails high upfront capital costs. Purchasing the drop-in replacement at the time of failure is a risk as well, especially if there is a long-lead time associated with the instrument, or there is a possibility that a replacement might not be available at all. Modifying the calibration software to support a readily-available replacement instrument also involves long downtimes, as code migration and validation can be time-consuming tasks. Developing a HAL is a proactive method of mitigating the risks of instrument replacement. A HAL can minimize the downtime required by such replacements by facilitating instrument interchangeability. Most HALs fall into one of three groups: industry-standard, vendor-defined, and user-defined Industry-Standard The most well-know industry-standard HAL is Interchangeable Virtual Instruments (IVI). The IVI standard was developed by an industry consortium in order to provide interchangeability between different instruments in specific sets of instrument classes, including digital multimeters, oscilloscopes, power meters, and more. Interchangeability is achieved by standardizing the API used to communicate with instruments in a given instrument class. If a user wishes to utilize a function that is not supported by the IVI API, though, he or she must use the instrument-specific driver. For instance, the IVI-DMM API provides functionality for setting various triggering and configuration properties, as well as performing common DMM measurements, but does not provide functionality for setting input impedance, which is configurable on many DMM instruments. If an industry-standard HAL meets the needs of a calibration application, it is usually the best option. The design, development, and maintenance of the HAL has already been taken care of, so the user can confidently integrate the HAL into his or her application with little additional effort Vendor-Defined Many instrument vendors create plug-in type drivers that support their full spectrum of instrument types and models. These can be a useful for quickly implementing a HAL in a calibration procedure, but limit the user s ability to troubleshoot source code or add new

4 instrument functionality. They also lock the user into using that vendor s platform and instrument offerings User-Defined Building a HAL from the ground up allows a developer to tailor the architecture and design of the HAL to the meet the needs of his or her application. Instrument coverage can be added proactively, and is not limited to only the instruments that are supported by the industry-standard or vendor-defined HAL. The tradeoff for this coverage is that, unlike industry-standard or vendor-defined HALs where instrument interchangeability requires no additional effort other than instrument validation, a user-defined HAL requires some design and development upfront. Taking the time to develop a well-designed HAL will ensure that adding future instrument support will be a simple, pain-free process. 4. HAL Architecture A well-designed HAL decouples the calibration application from the code used to control instrumentation. Figure 2 shows how a HAL fits into the overall architecture of an application. Figure 2. HAL in application architecture.

5 4.1. Application-Separation Layer For most calibration applications, the application-separation layer will be tied to an instrument type or class. This layer will implement various functions commonly associated with the instrument class. For instance, for a calibration procedure which utilizes a DMM, the application-separation layer would be a generic DMM driver that implements many common DMM functions, such as initialization, range configuration, and measurement. This layer would be called from the calibration procedure, so that the calibration procedure would not make any direct calls to device-specific instrument drivers Device-Specific Software Plug-In The device-specific software plug-in contains the driver calls specific to the instrument that is being used in the calibration system. This is the software layer that will be switched out if the instrument under test needs to be replaced by a new instrument type. 5. Decoupling Separating the HAL into two layers facilitates decoupling of the calibration procedure from the instrument driver. The application-separation layer serves as a buffer, ensuring that the procedure-level code does not need to be modified in order for the instrument type to be replaced. This is especially beneficial with large applications, where many calibration procedures are utilizing shared instrument control code. This decoupling also facilitates dynamic interchangeability of instrumentation, where the instrument to be used is selected by the operator at run-time. In this case, a configuration file or user prompt is used to identify the hardware resource to be used. This configuration can be passed to the application-separation layer, which dynamically loads the appropriate instrumentspecific layer to be used with the selected instrument. Figure 3 shows an implementation where the operator can select whether to use DMM1 or DMM2 during the configuration phase. These are two DMM types utilizing different instrument drivers. The application-separation layer calls the appropriate instrument-specific driver dynamically during execution.

6 Figure 3. Dynamic loading of instrument-specific driver. Dynamic loading of the device-specific software layer is achieved using a plug-in software architecture. One very powerful way of implementing software plug-ins is through objectoriented software design. 6. Object-Oriented Design In an object-oriented design, the various entities in the software are implemented as objects, or classes. Each class has certain properties, or data values, associated with, as well as certain methods, or functions, which can be performed on the class to modify its properties. A classic example of an object-oriented design is a card game, which could include classes for the deck of cards, the players, and the table, among others. The player class may contain properties for the player s score, the cards in his or her hand, etc. When the player plays a card from his or hand to the table, a method could be called which removes the card from the hand in the player s properties. In calibration software, each instrument type would be implemented as a different class. There are two key principles of object-oriented design that lend to its effectiveness in a HAL: inheritance and polymorphism Inheritance When a class inherits from another class, it automatically acquires all of its properties and methods. In addition, this subclass can have extended functionality that the base class does not have.

7 In the case of a HAL, our base class could be a generic DMM. It would have a defined set of properties and methods that are common across all types of DMMs. Properties could include range and number of channels, while methods could include functions to get or set these properties, as well as functions to initialize, close, and perform measurements. In addition, it could contain properties related to an instrument s Type A uncertainty, such as absolute accuracy and linearity. This class would serve as the application-separation layer in the HAL, and would be called directly from the calibration procedures. When support is added for a specific type of benchtop DMM, it is created as a subclass that inherits from the DMM base class. It inherits the properties and methods of its parent class, although the values of those properties need not be the same, since range, number of channels, etc. vary between different DMMs. The instrument-specific DMM class can be extended to include properties and methods that are not supported by the base DMM class. For instances, methods could be added to get and set the instrument s input impedance, if it is configurable. Figure 4 shows the class hierarchy for a base DMM class and its instrument-specific child classes. Figure 4. Example DMM class hierarchy.

8 Each of the instrument-specific DMM classes inherits the properties and methods of the generic DMM base class, while extending the functionality by adding their own properties and methods. At run-time, the instrument-control code can be loaded dynamically using the property of polymorphism Polymorphism Polymorphism allows a method to be called by many different types of classes, each applying its own type-specific behavior. In this case, we define three methods in the base class: Initialize(), Set Range(), and Close(). Each child class can override these methods, applying their own specific behavior for when the method is called on them. For instance, the Initialize() method for DMM Type 1 would call the initialization function from its instrument-specific driver. At run-time, when the calibration procedure calls the generic DMM Initialize() method from the application-separation layer, the compiler would determine the class type and run the appropriate Initialize() method for that specific type of instrument. There are different ways to handle methods that are supported by some instruments but not by others. One way of doing this is to add the method to the parent class and all other child classes for instruments of that type. For classes where the method is not supported by all instruments, such as the Set Impedance() method in the example shown, those classes which do not support that method should instead throw an error or exception. This will ensure that an unsupported instrument is never used in a calibration application. 7. Summary Utilizing a HAL is a proactive method for mitigating the inevitable risk of instrument downtime or replacement in an automated calibration system. Industry-standard and vendor-defined HALs provide instrument interchangeability with very little effort on the part of the user, but may be limited in their scope of supported instruments. A user-defined HAL, while requiring initial development and design, has the added benefit of greater adaptability, allowing the user to design the HAL to meet his or her needs, and add support for more instruments as necessary. An object-oriented design is an excellent choice when architecting a user-defined HAL, due to its intrinsic support for inheritance and polymorphism.

9 References 1. Zone.ni.com (2011) How to Mitigate Hardware Obsolescence in Next-Generation Test Systems. [online] Available at: [Accessed: 13 May 2012] 2. Decible.ni.com (2010) Achieve Hardware Independence with an Object-Oriented Hardware Abstraction Layer. Available at: [Accessed: 14 May 2012] 3. Codeproject.com (2011) Introduction to Object Oriented Programming Concepts (OOP) and More. [online] Available at: Object-Oriented-Programming-Concep#OOP [Accessed: 16 May 2012]