Proper abstraction layers of standardised test system

[Paulius]

Hello, I am working on a Standardtised test system intended for functional testing of manufactured products.

Hardware part of the system consinsts of:

1. Test system unit, which power supplies, loads, scopes, function generators, etc. and a PXI chassis with some devices.

2. Everything is connected to a test fixture through a standard mass interconnect interface.

3. Test fixture contains all the custom hardware for the DUT.

The goal is to have multiple test system units that could be easily interchangeable and that could accept any test fixture. Any test ficture must be plug-and-play capable on any test system unit. Furthermore, any system component must be replaceable with an identical component without modification to SW and with different component (different vendor, different series, different interface etc.) with least modification to SW. This calls for a hardware abstraction layer. What is not clear to me, what is the recommended strategy and how should the software layers be distributed between TestStand and LabView.

Assuming the usual layers of Test Application -> Application Specific Layer -> Device-Specific Software Plug-In -> Drivers, what should go where and how it should be implemented?

Currently all the layers are implemented in TestStand with ASL and DSSP layers mostly interleaved. TestStand sequences directly access LV hardware drivers. Adding new hardware requires editing these two layers, but allows leaving Test Application intact, but it is clear that such approach will not scale well.

Plase advice.

Thanks in advance!

[Dennis_Knutson]

It sounds like a perfect application for IVI drivers. You have all of the class drivers available in TestStand. There would be no need to modify any code if you were able to use them and you would not be calling any LabVIEW drivers. Another approach would be LVOOP.

[Paulius]

Thank you for your input.

Some of the devices do not have IVI drivers, for example, Hameg HMP4000 series power supply. It only has LabView intrument driver. LVOOP then?

[Dennis_Knutson]

It's not that difficult to write your own IVI drivers. You just need LabWindows/CVI.

[Paulius]

Thank you.

How IVI is superior to LVOOP for this particular application? I could do everything using LVOOP, mixed IVI/LVOOP or everything IVI. The last option seems to be the most complex to implement.

And what about application-specific layer? TestStand sequency library or LabView classes?

[Dennis_Knutson · Accepted solution]

IVI is a well established and documented standard. You would have less design decisions to make and less code to write. It's easy to use MAX to assign specific drivers to classes. You have existing steps on TestStand for IVI. I don't see where that is more complex than starting from scratch.

I would use the TestStand step types instead of the class functions in LabVIEW if you went with IVI. If it was me and using lvoop, I would create a custom step type for each class.

[Paulius]

Thank you for your input. Those are great arguments for IVI. Now it seems to me that IVI is the way to go.

But what about application-specific layer? For example, I want to have a step response measurement function. It has to simultaneously output a pulse using DAC in a DAQ board and read two ADC's in same/different DAQ board. What would be the proper way to separate Test Program from Application specific layer? Custom step types, sequence templates or something else?

[Dennis_Knutson]

That is completely different. DAQ devices are not programmed with IVI at all. Only with the DAQmx driver.