Viewpoint News, February 2010

Platform Choices

by James Campbell - jac@viewpointusa.com

Last month, we discussed resource limitations This month’s topic continues with steps and considerations on building or upgrading a test system. This month concerns selection of hardware and software components to construct your test system. What criteria do you use to select hardware and software platforms? I discuss those that Viewpoint considers in this issue.

Too Many Choices!

The multitude of HW and SW options can overwhelm many people. It’s like going to the grocery store to buy spaghetti only to find 16 varieties based on type and manufacturer. There you are standing in the pasta aisle, hungry, and all you want is some spaghetti. Why should this be so hard!

The proliferation of choices is a direct consequence of the maturation of the PC-based product test market. This proliferation is a proxy for perhaps the more pertinent puzzle: which of the purveyors and platforms will persist as long as your test system needs to perform.

Mix and Match vs. One Vendor

One of the most common choices stems from consideration of price for performance versus integration compatibility. In one approach, the test engineer purchases less-expensive hardware from a multitude of vendors and then integrates it all together with the application software. In another approach, the test engineer purchases more expensive hardware from the same vendor that supplies the application software thus reducing the integration effort.

In the experience of our engineers at Viewpoint, the multi-vendor approach works best if:

1. One has already written a driver for a similar hardware device from the same vendor (with, presumably, similar driver architecture).
2. The hardware devices follow a standard style of command language and mode of communications, such as is typical of devices from a similar class (i.e., DMM, oscilloscope, and so on) using IVI or SCPI-based GPIB (in other words, in the ideal, a hardware abstraction layer).

Note that the devices defined in item 2 are typically bench top or rack & stack instruments. Since PC-based test systems use many plug-in devices that attach directly to the backplane of the PC, other than IVI-supported devices, most PC-plug-ins don’t satisfy item 2. Thus, for PC plug-ins, the multi-vendor approach works best only if you’ve already overcome the struggle of supporting a similar piece of hardware from the same vendor.

Contrast this approach with the one-stop-shop of a vendor that supplies both hardware and application development software. Drivers are already available for the hardware and they integrate cleanly into the development environment. The increased cost of the hardware is directly related to the time-savings of this easier integration. In our experience, this approach produces a lower overall development costs, unless some hardware driver reuse leverage can be found in the multi-vendor approach. Even with the best driver reuse, the application development costs are at best about the same as the one-stop-shop approach. However, driver reuse is generally not optimal, and the one-stop-shop approach is usually less expensive.

Lifetime of the Test Systems

In addition to this integration effort during test system development, the longevity of the test system must be considered. At our Best Practices for Effective Test seminar last year, we discussed the importance of planning for obsolescence. Clearly, any new or refurbished test system design needs to address the duration for which the equipment is intended to be used. Platform selection sits right in the middle of this question.

Considerations include stability of the hardware platform, vendor longevity, standards surrounding the platform, upgradability of the hardware, validation efforts for hardware change, and operating system. Of course, if the product being tested will have a shorter lifetime than the test equipment, than consideration of the test system equipment is less important than otherwise.

Stability
If the vendor has a history of abandoning prior designs in favor of the next technology, avoid them.

Vendor longevity
Clearly a history of growth and/or stability tends to imply survival over the duration of your test system. A vendor that is the sole source for application development software needs to be considered carefully for their sustainability. For example, I am encouraged that LabVIEW is one of the longest surviving languages in the world, nearly as long as C has survived.

Standards
Hardware designed to a standard will be available longer than otherwise. The PXI platform, for example, will be available long after desktop PCs abandon the PCI bus in favor of PCIe. Similarly, the LXI platform will survive for many years. Look at GPIB by comparison and the lowly RS-232 as another example. However, pay attention to how the standard arose. I doubt USB will be used as long as LXI since USB was promoted by consumer equipment manufacturers whereas LXI was promoted by measurement equipment vendors.

Likewise, for the application software, standards help, but don’t seem to have the effectiveness of hardware standards. (For example, compiler and language upgrades leapfrog the ongoing standards committee review.) In my opinion, more important is the de facto standardization of a language. C will survive merely because of the huge base of users. LabVIEW is also a standard in the test world. LabVIEW is a hugely valuable asset in NI’s possession with many users. It will not disappear on a whim.

Validation efforts
Some regulated industries have an enormous incentive to keep the test system exactly as it was validated during commissioning. These test systems tend to have the longest life. Fifteen years is not unusual. Ten is very common. Companies with these restrictions need to be especially careful in hardware selection.

Operating system
The hardware platform certainly includes the measurement hardware, but it also includes the PC and its operating system (OS). Even if the measurement hardware lasts or is available for 20 years, if the PC backplane or OS changes 5 times in that period, in all likelihood you will not be able to use the measurement hardware in 20 years. It is hard to forecast how this will play out, but already we have seen some influence by the test community on the availability of an OS. For example, Microsoft is continuing to offer XP for “embedded” (i.e., not desktop) systems, thus allowing National Instruments to offer XP on PXI platforms. The OS area is perhaps the most concerning to me when we select components for clients that request 10 or more years of longevity.

Conclusion

It is very important to select hardware and application development software to match the life expectancy of your test system. Include in your scoring considerations both platform standards, whether de jure or de facto, and vendor stability.