Case Studies

All Categories

Streamline Hardware Configuration with the Hardware Abstraction Layer

Posted in LabVIEW, Test & Measurement Automation

Summary

The Hardware Abstraction Layer is a powerful part of the Device-Module hierarchy present in DMC's Flex Framework. It allows developers to easily integrate new pieces of hardware, and users to switch between hardware configurations on-the-fly.

Solution

LabVIEW Hardware Abstraction

The Hardware Abstraction Layer (HAL) works by grouping together devices that perform similar functions or require the same configurations from the user, and grouping them under a single API. With this HAL, adding a new device model only requires writing the lowest level drivers specific to that device.  All the higher-level interaction with the rest of the application is taken care of by the hardware abstraction layer.

As a result, the cost of upgrading and maintaining test systems over time can be greatly reduced. New test devices can be easily added, and deprecated ones can be easily removed.

Another important feature this standardization provides us is any user or engineer can have the capability to select or configure the hardware to be used for a given test. This hardware can be hot-swapped with other supported units of the same family, and no programming team is needed for the change! 

What Does it Look Like?

Pictured below is an example of the settings configuration tab. This interface allows any user with appropriate credentials to make all necessary hardware and software setting changes. This menu can be tailored to contain settings particular to each customer.

Hardware extraction configuration settings

How is it Done?

DMC establishes the hardware abstraction layer in LabVIEW using object oriented techniques.  Each unit within a family of devices (a National Instruments Power Supply [PS] within the PS family) can inherit from a common ancestor.  The common ancestor defines an application-programming interface (API) and an interface which is typically shared by all children classes.  For the purpose of exploring the concept, we will examine the hardware abstraction layer of a power supply.

Hardware extraction for power supply

The abstract power supply class, _Power Supply.lvclass, defines the set of interactions a user or piece of code can have with a generic Power Supply (e.g. Command Voltage, Command Output State, etc.).  These API calls point to blank pieces of code, with the intention that a child class will override these stubbed out API implementations.

DMC makes use of LabVIEW’s dynamic dispatch functionality to call the correct child class’s implementation of an API at runtime.  This allows for the programmer to drop in a ‘Command Voltage – API’ and not worry about which device type is implementing the call at runtime.

In addition to a standard set of API calls, devices which inherit from the _Power Supply.lvclass can take advantage of a standardized control interface (shared and implemented at the parent _Power Supply.lvclass level).  

The _Power Supply.lvclass’s Interface
The _Power Supply.lvclass’s Interface

Each button on the interface makes an API call, allowing the children classes to push data to the interface for users to view.  This shared interface allows for users to interact with a variety of Power Supply types without needing to know which exact type of Power Supply is connected, providing for a familiar user experience while maximizing code reuse across an application.

This architecture has proven useful for customers who have multiple units of devices within a family of instruments by allowing programmers to program to an abstract class’s API instead of to a specific class’s implementation, enabling programmers to develop faster and more efficiently.

These features are part of a powerful suite of tools called the DMC Flex Framework. Find out more about all of these tools here.

Learn more about DMC's LabVIEW programming expertise. 

Customer Benefits

  • Common API’s: Similar devices are integrated under the same API (Application Programming Interface), simplifying integration into existing software.
  • Reduced Development Time: Since a new API doesn't need to be written for each new device, new devices can be added with lower engineering effort.
  • Hot-Swappable: Just as pieces of hardware can be easily swapped due to standardized connectors and cables, the standardized API’s allow for quick and easy software swapping of device driver layers.
  • DMCquencer Integration: Test sequences take advantage of hardware abstraction, allowing users to write a test sequence once and run it on different hardware configurations.
  • Interface Simplicity: The software can easily execute the behind-the-scenes operations needed to switch to a new piece of hardware. For the user, choosing a new device to use is as simple as selecting an item from a drop-down menu.