Software Takes Driver’s Seat in
The emergence of hybrid test systems, which operate on a blend of hardware architectures,
has highlighted the importance of the underlying software.
For over 50 years, test engineers have taken a PC-based approach to automating standalone instrumentation. With
so much investment tied up
in capital assets for test equipment, engineers and management teams need reassurance
that they can satisfy current
and future testing needs. This
is why engineers and scientists
often stay with a known software platform for many years,
even after it’s become obsolete.
Why? They don’t want hiccups in their test protocol. This
can cost weeks or months in
rewriting the application.
Despite the importance of software investments, many laboratories associate the heaviest costs with capital expenditure on hardware. But even more
damaging, costs can result in loss of time, which most often results from
incompatibility from sudden changes in a test platform. These incidents
shed more light on the heart of the instrument control system: software.
munication protocol,” says
Adri Kruger, applications
engineer at National Instruments (NI), Austin, Texas.
For example, she says, the
VISA command to write
an ASCII string to a mes-sage-based instrument is the
same whether the instrument
is GPIB, USB, or Ethernet.
VISA provides a single interface for communicating over
any bus, and also streamlines
switching interfaces, which
is becoming increasingly
NI has leveraged this
independence to build soft-
ware that can allow users to
add support for new buses with making changes to the interfaces. Called
NI-VISA, the driver software is flexible enough to accommodate modern
multipurpose buses, as well as the established standards.
This chart shows the implementation of an input-output software specification developed
in the early 1990s to solve the problem of bus and instrument vendor interoperability.
Called Virtual Instrumentation Software Architecture, or VISA, the standard has created
an environment for the growth of hybrid test systems, which can include different bus and
instrument types connected through customized drivers. Image: National Instruments
How instruments communicate with software
A healthy environment for drivers
After the development of VISA, developers could write instrument drivers
that simplify communication with devices by abstracting low-level programming protocols that may be specific to one instrument.
Typically instrument drivers expose an API that is used within a programming environment to build application software, says Kruger. Selecting the correct instrument driver is crucial for those developing an instrument control system, especially when implementing a custom hardware
abstraction layer (HAL) within the test system.
For NI, this means instrument drivers for applications within LabView,
the company’s suite of application design software, integrate directly into
the NI LabVIEW development environment. “These native instrument
drivers, based on VISA, provide an additional layer of abstraction from
the hardware so you don’t have to worry about communication details
across a given bus,” says Kruger.
NI was founded to provide instrument controls and connectivity interfaces. Initially, those solutions depended heavily on hardware. As the basis
for instrument drivers was standardized, the company shifted gears and
began to invest time and value into the drivers themselves.
As a result, NI now has more than 10,000 instrument drivers from
more than 350 instrument vendors, all archived on its Instrument Driver