Updating a test system can be costly and time consuming. 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 lifetime with minimal additional costs. You may want to ask yourself some simple questions before designing, developing, maintaining, and updating a test system:
How many generations of test instrumentation will your products live through?
How many generations of products will be tested using the same instrumentation?
Does making a change to a test instrument require revalidation of the test code?
It can be difficult to update or maintain a test system that does not implement a layered and modular design, which leads to increased costs in redevelopment, revalidation, and re-documentation. A hardware abstraction layer (HAL) is vital to a layered and modular test system. This mechanism abstracts the test code from the test instrumentation in a test system. When properly implemented, a HAL can reduce much of the risk, cost, and time associated with developing, maintaining, and updating a test system.Many devices, one interface
A HAL is analogous to a universal remote control for a home entertainment system with multiple components. Previously, before using your entertainment system, you would have to have understood how to operate each device and its control. Unfortunately, every component you added to or replaced in the entertainment system increased the time spent learning how to use the dedicated remote control that came with that device.
The remote controls for your entertainment system, however, have similar interfaces that can be exploited to simplify the operation of the devices. A universal remote takes similar functions among your electronics and incorporates them into a single interface, thus controlling all your devices with one unit. A HAL behaves in a similar manner: Its purpose is to provide one interface to work with regardless of the test instruments you are using.Mismatched product & test instrumentation lifecycles
Problems manifest themselves in a test system when mismatches exist between the product lifecycle and the test instrumentation lifecycle. These lifecycle mismatches put the most strain on a test system containing 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 product lifecycles that can span decades. Consequently, the device under test has a good chance of outliving the 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 instrumentation used to test it. 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 result in test instrumentation being too closely coupled to the test code. Whenever a tightly coupled test system undergoes a lifecycle mismatch, a substantial amount of time and energy is needed to update the test system.