The attached code serves as a reference architecture for the core architecture of large-scale test and measurement systems, especially long-running tests that are commonly associated with the characterization and validation of a physical system.
The Measurement Abstraction Framework demonstrates solutions that address the following common requirements:
Hardware Abstraction Layer(s): The de-coupling of hardware and instrumentation through a class interface that allows tests to be easily reconfigured to utilize different devices or vendors without modifying test code
Measurement Abstraction Layer(s): The ability to change and override the default behavior and display of a measurement based on a class interface without modifying test code
Channel and DUT Abstraction: The ability to map IO for a specific device to sensors or a DUT in a way that can be stored and referenced without specific knowledge of the device in use
Factory patterns for plugins: Dynamic loading of new capabilities and functionality without modifying or even restarting the main framework
Simplified test definition: How to enable the creation of tests by users who are not experts on the framework or advanced programming concepts like OOP
Logging heterogenous data: How to stream data from multiple devices at multiple rates in a way that can easily be correlated and analyzed offline
Storing/aggregating data in a central location: How to upload the data from tests to NI SystemLink for visualization and offline analysis
Asynchronous actors: Usage of Actor Framework for a highly asynchronous system that allows multiple sub-systems to communicate while acting independently
Configuration storage: how to store device and measurement configuration to disk for later reference, as well as how to pass this information to TestStand
Simplification of TestStand: simplify test definition in TestStand through configuration-based workflows that employ custom step types
Reusable across validation or production: the framework is designed to execute the same measurements and devices purely from LabVIEW or they can be sequenced and the channel names can be referenced from TestStand tests
Remote execution of tests on RT targets: How to sequence the execution of tests running on a Linux Real-Time target from a Window Host running TestStand. Note: this functionality was available in previous versions but is not in the 5.3 release yet. It will be re-added after NIWeek
Version 5.0 has been used to build an EV Powertrain Validation test demonstration, which will appear on the Expo floor of NIWeek, as well as various locations around then world. The attached code includes the device plugins that were used for this particular application. Once installed, it can be run, but will almost certainly generate an error unless you happen to have the same hardware at your disposal. The primary reason these were included is to serve as helpful examples for how driver plugins should be written.
To run the example without hardware, we recommend simulating one or more DAQ devices for use with the Standard Measurement.
Setup and Installation
Written and designed for LabVIEW 2017 SP1. Will be tested against LabVIEW 2018 after NIWeek
The attached VIPC contains all of the necessary libraries required to run the framework, as well as one sample measurement plugin and device plugin examples for: DAQ, CAN, RMX Power Supply, Anderson Load, and a Thermotron thermal chamber.
One installed, navigate in VIPM to the TestStand Interface for MAF package and click "Show Examples"
Open the project in that directory and launch and run "TestStand Interface Test Harness.vi." Clicking the buttons in order will allow you to configure the controller, the measurement, apply system properties to the file and ultimately launch a and long a measurement
Once this is working, launch the sample TestStand sequence file to call then framework from TestStand using custom step types
Extending or Customizing Measurements
The example measurement is installed by default to C:\ProgramData\Measurements
The included example only features one measurement, "Standard Measurement," which his a very basic implementation. However, it is possible to instantiate N instances of this type of measurement, which should cover most basic use-cases.
Reasons to override this measurement include:
A custom measurement display is required when it is running
A different interface is required for specific devices (all acquisition in this example uses "read N samples from N channels" for acquisition and "write N samples for N channels" for generation
A specific measurement or enrichment operation is desired to be added to the data as it is acquired and included within the log
A safety-critical measurement needs to be performed on the data (perhaps on an RT system) that is responsible for closed-loop control (ie: safe shut down)
Measurement requires that a specific type of device be specified, which can be defined by overriding the method to request hardware
Extending or Customizing Hardware
The example measurement is installed by default to C:\ProgramData\Hardware
Unlike previous versions, all devices inherit directly from the base Hardware.lvclass object. The measurement device implements the acquisition and generation interfaces. Device plugins wrap specific drivers and are called used a basic "Configure --> Acquire --> Generate --> Measure --> Repeat until Close" sequence. A device can specify specific interfaces that they implement if requested by the framework, but the default is for a device to support "all" interfaces.
All devices have both common and unique configuration options. The common capabilities are stored in the base "HW Configuration.lvclass," but extended by their own implementation for unique properties
Future Updates / Known Issues
Remote execution of measurements on RT target (available in previous 3.0 version)
The ability to launch one central logger instead of a logger per measurement
The ability to launch the results from the measurement window
Distribution of plugins with SystemLink as NIPM packages
Devices have to be selected in error or then framework returns an error
The path to store logs has to be valid, or framework return an error
Various performance improvements when acquiring
The following articles describe core design decisions of the original framework: