Updating a test system can be a costly and time-consuming affair. What initially might seem like a simple change to a test system can lead to a considerable amount of redevelopment, re-verification, and re-documentation. Consequently, having a test system that is easy to maintain and update is important to ensuring a long life time with minimal additional costs. How can you gauge how easily your test system can be maintained or updated? You may want to ask yourself some simple questions like,
Questions like these are important to ask yourself before designing, developing, maintaining, and updating a test system. It can be difficult to update or maintain a test system that does not implement a layered and modular design. This leads to increased costs in redevelopment, revalidation, and re-documentation. A vital element to a layered and modular test system is a hardware abstraction layer (HAL). A HAL is a mechanism for abstracting the test code from the test instrumentation in a test system. When properly implemented, a HAL can reduce many of the risks, costs, and time associated with developing, maintaining, and updating a test system.
A HAL is analogous to a universal remote control for a home entertainment system. A home entertainment system may include devices such as a TV, VCR, and DVD player. Before being able to enjoy your entertainment system you would have to understand how to operate each device. Unfortunately, every device you add to or replace in the entertainment system adds additional time spent relearning how to use the new remote control that comes with that device.
However, the remote controls for your entertainment system have similar interfaces which can be exploited to simplify the operation of the devices. For example, the VCR and DVD both have a play, stop, and pause function. A universal remote takes these similar functions and incorporates them into one interface. With a universal remote you only need one remote control for all your devices. You can use the same universal remote even if you replace your DVD or add an HDTV.
A universal remote abstracts the device dependent interfaces to each device in the entertainment system. A HAL behaves in a similar manner. Its purpose is to provide one interface for you to work with regardless of the test instruments you are using.
Problems manifest themselves in a test system when mismatches exist between the product life cycle and the test instrumentation life cycle. These mismatches between life cycles put the most strain on a test system that contains test code that is tightly coupled with the test instrumentation. Consider the following two RF examples that illustrate a mismatch between the test instrumentation and the product under test.
Military radios have long product life cycles that can span decades. Consequently, the device under test has a good chance of outliving the test instrumentation used to test it. Replacing the test instrument in a tightly coupled test system leads to more substantial rewrites of the test code although the functional objective of the test code has not changed.
Conversely, the product life of a cell phone is rarely longer than a year, quite short when compared to the life of the test instrumentation used to test the cell phone. If a tightly-coupled test system is used on a cell phone then considerable redevelopment to the system may occur every time a new generation of the cell phone becomes available for testing. In this case, frequent revisions and changes to the product put a strain on the test system to accommodate the changes in the product.
Both examples show that unnecessary redevelopment, revalidation, and re-documentation in the test system is the result of test instrumentation being too closely coupled to the test code. Whenever a tightly coupled test system undergoes a lifecycle mismatch then a substantial amount of time and energy is needed to update the test system.
To reduce the impact of out-of-synch life cycles on a test system, the test instrumentation as well as the test code must be modifiable without affecting each other. One way to think about this desirable setup is view the test instrumentation and test code as blocks that fit loosely together. If one block were to fail or become outdated, another block could easily replace it. Loosely coupled layers are an effective way to increase the modularity of a system. Inserting a HAL between the test code and the test instrumentation reduces dependencies between those two layers. Consequently, a properly designed HAL can directly address the pains caused by life cycle mismatches on a test system with tightly coupled test code.
A HAL has a very specific role and should implement specific items to be effective. The following ten features make a HAL effective.
Separation between the Test Code and the Test Instrumentation. Weak points susceptible to life cycle mismatches form anytime the test code directly interacts with the test instrument. The HAL’s primary focus is to prevent these points from forming even if the HAL provides only a simple pass-through interface between the test code and the test instrument.
API Translation. A key benefit to a HAL is a unified interface for different test instruments that perform similar functions. For instance, a test system might use two different types of DMMs that use two different drivers with different APIs. A HAL should be responsible for implementing a unified API that maps to the individual drivers. This ability simplifies and reduces test code development and validation.
Extensible and Backwards Compatible API. An effective HAL must be able to support existing test instrumentation but also allow for new instruments to be introduced to the system with minimal effort. A well planned and clearly defined interface will allow a HAL to effectively expose the functionality of existing test instruments as well as extend future instruments to test code.
Support for a Variety of Drivers. As its name implies a HAL abstracts the details of the test instruments from the test code. A HAL should be intelligent enough to handle different types of drivers and hide the driver specific conventions from the test code.
Scaling. Test instruments often operate across various scales of data. For example, a replacement instrument may have a different offset and gain in measurements. These differences can be addressed by the HAL. The measurement results can be made consistent when being passed through the HAL to the test code ensuring the test code gets the "same answer."
Timing Differences. Test systems often have a range of test instruments that function on different timings or have different timing requirements. A HAL can assist in synchronization or timing of test instruments as well as oversee data transfers on buses that have different speeds.
Data Formatting Changes. As with API translation, different test instruments may require different data formats as both inputs and outputs (e.g. V or mV, H3 or MH3). A successful HAL will take the data formats from the test code and dynamically format them to the correct type for the specified test instrument being used.
Error Checking. When error checking is implemented, the HAL can be used to enforce tighter runtime control over the test instrumentation. The HAL may also be used to insulate test instrumentation level errors from the test code when appropriate.
Instrument Simulation. Developers may want to test parts of their test system even though some of the test instruments are not available. Providing instrument I/O simulation in the HAL allows developers to test their code without the need of the physical hardware.
Fault Insertion. Developers can insert known faults to make sure the test code will catch DUT errors. Fault insertion can speed up the development of a test system by providing developers with known pass and fail states. Fault insertion in the HAL can also be useful in revalidating test systems with new test instrumentation.
A HAL is a proven method to develop and maintain a loosely coupled test system. It better addresses mismatches between product and test instrumentation life cycles and avoids tightly coupled test code with test instrumentation. Loosely coupling test code and the test instrumentation improves the overall design of a test system making it more maintainable and extensible over its lifetime.
If you are interested in learning more, an example HAL implemented in LabVIEW and a whitepaper that presents the best practices for design and implementation can be found here.