Using a real-time OS with PXI
By Richard A. Quinnell, Contributing Technical Editor -- Test & Measurement World, 9/1/2009 2:00:00 AM
Given PXI's roots in the PC field, it is no wonder that Windows is the dominant operating system for PXI system software. For some applications, however, Windows is not a good match to system requirements, and developers must employ another OS. Development teams seeking to move beyond Windows face challenges both in software availability and system programming, but new developments may offer a way past such problems. In fact, an evolving virtualization technology may permit a single test system to run more than one OS.
The drawbacks of Windows
One of the strengths of PXI is that the architecture is able to fully leverage technology advances coming from the fast-moving PC field. New processors, advanced interfaces, and development tools that arise in support of PCs can quickly be incorporated into PXI modules and systems. The same is true of advances in system software such as Windows.
But Windows is a double-edged sword when it comes to system control. It enjoys wide support in terms of tools, applications, and developer expertise, but it also has key drawbacks. Two of the most critical for equipment developers are reliability and determinism.
Windows can have unpredictable timing and sometimes will crash for no readily apparent reason, a failing that is not tolerable in critical applications. “There is nothing mission critical about most manufacturing test systems,” said Wyatt Meek, director of business development at VI Engineering, “so they can run Windows, and if it crashes, they can simply reboot. But where operation is mission critical or there is critical control timing, you'll want something else.”
| Read more articles from our September 2009 PXI Test Report. |
As an example, Meek pointed to the JRETS (Jet and Rocket Engine Test System) that VI Engineering developed for Wyle Laboratories using multiple PXI systems to handle data acquisition and control. The system was designed to facilitate hot-fire testing of engines with as much as 50,000 lb of thrust, making consistent operation and well-controlled timing essential.
VI Engineering used the Phar Lap ETS RTOS (real-time operating system) instead of Windows, and used National Instruments' LabView with the LabView Real-Time module as the programming environment. Reliability was a key reason for this choice.
“You won't have a system crash with an RTOS if you implement it correctly,” said Meek. “The fear with Windows is getting the 'blue screen of death' in the middle of a test.” Meek also pointed to the maturity of LabView Real-Time, now at version 7, as a factor ensuring stable system operation.
In addition to reliability, the JRETS needed deterministic timing in its control paths. The variation in timing, or OS jitter, that Windows exhibits is typically 500 ms, and even when Windows is optimized for timing, the jitter can be more than 10 ms, according to Meek. An RTOS achieves jitter in the 1-to-10-ms range, making the system quicker to respond to errors, resulting in increased safety.
Developers want reliability
Even for systems that do not have such mission-critical requirements, however, some developers are looking for an alternative to Windows, according to Matthew Friedman, senior PXI platform manager at National Instruments. “A lot of users simply want more confidence in the reliability of their systems,” said Friedman. “They may also be looking for a higher degree of synchronization between the controls driving the test and the measurement.” Other reasons for choosing an alternative OS include vendor independence, version stability, and freedom from licensing fees.
 For some developers of PXI systems, the reliability and functional stability of operating systems such as Linux offer an appealing alternative to Windows. Courtesy of Sekas. |
If a PXI test system uses an external computer as the system controller, that computer can be running Windows, MacOS, Linux, or nearly any other OS that can send the appropriate commands. If the controller is embedded, however, off-the-shelf alternatives narrow.
Only a handful of manufacturers of PXI controllers support alternatives to Windows. Keithley Instruments, for instance, offers Linux for its controllers. NI has controllers with an embedded RTOS. MEN Mikro Electronik supports Linux, QNX, or VxWorks, depending on the controller model. Adlink has a Linux API (application programming interface) and driver library for its controllers and data-acquisition cards, and Team Solutions offers Linux drivers for the GPIB and PXI trigger functions built into its modular-CPU controller. Because the controller utilizes industry-standard plug-in CPU modules, however, OS support must come from the CPU module vendor.
If the controller is running an alternative OS, other system modules will require drivers appropriate to that OS. This can present developers with a challenge. “Not a lot of vendors have nonWindows drivers,” said Meek, “so there is a smaller range of resources available for developers.” Even when drivers are available, Meek noted, they may not support some of the module functions that the Windows drivers do.
Embracing a Windows alternative can also limit your options for application software. “Developers should look at which programs support their OS,” said Meek, and he explained that if the test-control software does not run under the desired RTOS, developers will need to create their own test-sequencing engines.
There has been some industry activity to fill the gaps, at least for specific system configurations. LabView Real-Time, for instance, supports VISA (virtual instrumentation software architecture) drivers. So, if a module's driver is VISA-compliant, it will work under LabView Real-Time.
The German company Sekas is offering software that makes the Rohde & Schwarz CompactTSVP (test system versatile platform), which is used in automotive and telecommunications test, compatible with Linux. The Sekas software—TSVP-LXLib—replicates the software infrastructure that IVI (Interchangeable Virtual Instrument) drivers need, making it easier for developers to port the drivers to Linux.
Evaluate system needs
For the most part, however, PXI developers seeking an alternative to Windows must evaluate their choice carefully. “Survey your current needs to ensure that you have support for the new OS,” said Gerardo Garcia, group manager for real-time software at NI. “Also, check to see if you are using OS-specific features such as ActiveX, which is only available under Windows. You need to make a full audit of what you are actually doing in your system.”
Developers who are seeking to use an RTOS should also think twice about simply making the change on their own. “Bringing up a controller board under a new OS can be painful,” said Garcia. “So, having out-of-the-box support for an RTOS from the board vendor is important.”
VI Engineering's Meek also pointed out that moving a traditional PXI test application to a real-time system may require a learning curve. “You can't just take normal LabView code and have it work in real-time,” said Meek. “You need to architect your program to allow independent threads, set priorities, and the like. This might not be difficult for a specific test, but it gets tricky if you are trying to design a generic system with looping and such. This adds cost and complexity to the development effort. You have to ask if the advantages of an RTOS are worth it.”
Virtualization is on the horizon
Developers may not be facing an “either…or” OS choice in PXI system design for long, however. NI's Friedman said the industry is on the verge of supporting the best of both worlds by embracing technology from the IT field.
 Virtualization may soon offer PXI developers a way of obtaining RTOS determinism for their systems without giving up the rich support of Windows. Courtesy of National Instruments. |
“Virtualization is an abstraction of hardware resources that allows multiple operating systems to run concurrently on a processor,” said Friedman. “It employs a hypervisor software layer underneath the OSes that keeps them separate.”
Virtualization technology takes advantage of the fact that all digital computing engines (processors) are Turing machines, which means that any processor can be programmed to mimic the behavior of any another processor regardless of structural and machine code differences. In virtualization, the hypervisor, also called the virtual machine monitor, runs at the processor's foundation level to mimic multiple copies of system resources to higher-level software, creating VMs (virtual machines) that can each execute an OS and application code.
A hypervisor can provide a high degree of separation between VMs. An OS on one VM can crash, for instance, without affecting the operation of the others. The hypervisor can also coordinate access to system hardware resources such as memory and I/O so that each VM can function as though it has dedicated resources even if the resources are actually shared. Hypervisors can thus “split” a single processor into several functionally independent ones.
Many of the latest generation of Intel and AMD processors now have hardware features that help them efficiently run such hypervisors, and more such features are added with each generation, according to Friedman. Multicore processors, which are becoming the standard approach for attaining the highest CPU performance, are also good candidates for virtualization techniques. Thus, the technology is on the edge of being available for PXI.
The advantage of using virtualization in a PXI system is that it gives developers the ability to segment a controller's functionality into multiple, independent parts. “You can keep the connectivity of Windows with one VM and use an RTOS for determinism in another VM,” said Friedman. “This allows you to keep what you have under one OS but add more [functions] under another. It will allow for very innovative test system design.”
At the very least, virtualization can help developers seeking to adopt Windows alternatives. By keeping only the most critical functions under RTOS control and the rest under Windows, developers reduce their need for alternative drivers and other support. Such an arrangement also restricts the need for new software development for the real-time portions of the system. Developers thus may not need to move entirely beyond Windows to achieve their goals. They may simply be able to stretch their system's reach a little.
No related content found.
- 0 rated items found.
Datasheets.com Electronic Parts & Inventory Search
185 million searchable parts
- Part Number
- Description
- Inventory
- Products
- Manufacturers
View All Webcasts
