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.
How instruments communicate with software
Over the past decade, instrumentation systems have evolved and grown more complex. Today’s test systems often mix communication buses and different instruments from a variety of vendors. This trend has led to an industry term: hybrid test systems. The instruments in these systems need compatible software interfaces that maintain backward compatibility with existing equipment while staying flexible enough for future expansion.
To help solve the problem of bus and instrument vendor interoperability, the VXIplug&play Systems Alliance developed a specification for input-output (I/O) software: Virtual Instrumentation Software Architecture (VISA). When the alliance was founded in 1993, many nonstandard commercial implementations of I/O software for VXI, GPIB, and serial interfaces were used. VISA provided a common foundation for the development, delivery, and interoperability of high-level multivendor system software components, such as instrument drivers, soft front panels, and application software.
“VISA simplifies instrument communication and makes the application programming interface (API) independent so you can focus on the task at hand, rather than the low-level details of a given bus communication 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 message-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 important.
NI has leveraged this independence to build software 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.
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 Network (IDNet), the largest online database of free instrument drivers. Driver downloads for LabVIEW, NI LabWindows/CVI, and Microsoft Visual Studio .NET are available, covering buses including GPIB, USB, PXI, PCI, Ethernet, LXI, and RS232. New drivers are being developed constantly as test hardware evolves. NI has also addressed this changing landscape with a building tool, the LabVIEW Instrument Driver Development Studio, which uses SCPI command templates for common instrument types to help accelerate driver development.
Accommodating changes in operating systems
Highlighting the need for smart software choices in the test environment is the increasing pace of operating system changes. Once limited to Windows and some Unix-based architecture, test platforms must now accommodate a variety of other operating systems, such as Macintosh and Linux, that are updated each year. This leaves the user with the daunting task of upgrading while maintaining the integrity of the existing test system. “VISA manages the low-level communication to the operating system (OS) and the hardware device, so you can freely move to new OSs without changing your application,” says Kruger. This is particularly important as portable computing devices are increasingly leveraged to help develop or augment applications.
To address this rapidly growing segment NI has built a mobile extension to its DataDashboard tool, which allows users to create a custom interface to LabView applications. The interface includes swipeable screens and values of network published shared variables.
“The idea is to let people control and communicate with their devices,” and add further value to the LabView environment, says Kruger. “As automated test solutions take over we have seen several of our accounts asking to connect to multiple systems over wireless networks.”
NI has designed its systems to extract the bus—Wi-Fi, Ethernet, GPIB—and port that to whatever applications happen to be calling on the bus. These capabilities streamline what NI anticipates to be a strong market in mobile test and measurement in the next few years, both on tablets and smartphones.
Despite these developments in software, hardware still plays crucial role in connectivity and data collection. One important factor is the microprocessing architecture. Multicore processors are now commonplace, offering system performance gains if a test platform is able to exploit parallel execution. NI has been careful, says Kruger, to ensure that LabVIEW seamlessly integrates with VISA, and is able to utilize multicore processing routines.
Buses are another factor. According to Kruger, GPIB is no longer the primary bus in use for test and measurement tasks; USB and Ethernet have taken over this role.
“Those could also change 10 or 20 years down the line. The key is to have a solid foundation in software infrastructure and a framework that makes connectivity concerns trivial,” says Kruger.