How to Mitigate Hardware Obsolescence in Next-Generation Test Systems

Publish Date: Nov 10, 2014 | 29 Ratings | 3.97 out of 5 | Print | 1 Customer Review | Submit your review

Overview

This example program and white paper describe how to design and use a user-defined hardware abstraction layer (HAL) in LabVIEW and C-based ADEs.

The problem with many test systems is that the overall system must be in operation longer than the individual system components are supported. Sometimes the device being tested has an active service life measured in decades, while many test instruments are obsolete and no longer supported after five years or less. Other times, the device being tested has an active service life measured in months. Both of these are examples of life-cycle mismatch.

A life-cycle mismatch creates a need to upgrade obsolete instruments without changing test applications, test fixtures, and devices under test (DUTs) or a need to modify the test application software without changing any of the hardware or hardware-specific software. Updating test systems requires new test software development, revalidation, and redocumentation that are costly, resource-intensive, and time-consuming. To minimize the time and costs associated with migrating or upgrading test systems, you can use hardware abstraction layers (HALs) in test systems to separate the test application from the instrument hardware. This paper covers HAL architecture, best practices, features, and benefits as well as outlines examples of LabVIEW and C-based implementations.

Back to Top

Customer Reviews
1 Review | Submit your review

Add tests, metrics, ESF and logic abstraction  - Aug 18, 2011

Hi, in order to make this design complete could you add tests from NI/JKI (instead of the regular tests that you wrote in order to get a parallel abstraction of the tests with those OOP tools), metrics for code efficiency and some ESF classes that will add both singleton access to the hardware and an abstraction of both the driver and communication protocols? Besides that, I think there should also be some way to abstract the ASL's logic. My goal is to be able to choose which logic to use over which device with which protocol. However, the only way I can think of doing it is by configuration files since otherwise I would have to tell the main vi which logic+device+protocol to work with and that will break the idea behind the abstraction. Since we have just one dynamic dispatch input we can't apply a true OOP and send a general 3 parameters in main vi. Do you have a solution? Thanks in advance, Dror.

Bookmark & Share


Downloads

Attachments:

Mitigate Hardware Obsolescence

Hardware Abstraction Layer – C
Example

Requirements

Hardware Abstraction Layer – L
abVIEW Example

Requirements


Ratings

Rate this document

Answered Your Question?
Yes No

Submit