Don’t get locked into an inflexible test program by building a monolithic architecture; instead plan ahead by building layers that perform separate test operations.
In a monolithic architecture the UUT test program includes code that manages test flow control, test execution, UUT stimulus, measurement analysis, limit checking, result logging, operator user interface, and instrument resource scheduling. This single source of functionality means that any new test requirements that arise due to an obsolescence event, require the entire test system to be revalidated.
Figure 1. A single code base to handle all test program tasks seems like a good way to develop until it becomes inflated and difficult to change or repair. Using smaller, modular code bases for different tasks keeps a test system more extensible.
Instead, create a modular software architecture that has separate code bases for all critical test system functions. Test management software like TestStand handles common test program tasks such as test flow control, test execution, result logging, limit checking, operator user interfaces, and instrument resource scheduling. Test code should be responsible for tasks specific to the UUT like stimulus, measurement, and analysis functionality.
See how test system experts, Bloomy Controls, implement a layered test system software architecture in this 30-minute webcast.
Perhaps the most significant software technique to protect a test system against inevitable hardware obsolescence events is using hardware abstraction layers (HALs) and measurement abstraction layers (MALs).
HALs help you to develop high-level code that calls a function that returns a value from an instrument without knowledge of the specific instrument and device configuration. The most common HALs are provided by instrument vendors and industry standards such as IVI. Building these layers into your code gives you the flexibility to change instruments without altering measurement analysis code, the tester’s user interface, or the overall test structure.
Figure 2. A MAL and HAL empower test engineers to choose the test result needed and allow the test system architect to maintain instrument driver and hardware operability.
A HAL alone does not protect a system from changes in hardware or instrument drivers. Some instruments have an overlap of functionality and could be used to complete tests in place of a busy or malfunctioning device. A good example of this is taking current measurements with a digital multimeter (DMM). A source measure unit (SMU) could be used even more effectively to take that measurement in many cases.
MALs allow a user to define a measurement or test type and gives the test system the ability to choose the correct and available resource to deliver that result. Test systems built with MALs are even more flexible and resistant to changes in instrument drivers and hardware.
Want to learn about implementing a HAL or MAL in LabVIEW object-oriented programming (OOP)? Watch a free online training video now.