Published December 2, 2020

This article is part of the Flight Test series:

The data processing needs of any flight test organization are fairly similar. Analog and Digital data will need to be acquired. Calibrations will be needed. Digital data must be decoded. Derived Parameters will need to be calculated. At least some level of digital filtering will likely be needed. Limit checking will be needed. Plots will have to be made by the hundreds. Batch processing will be needed. Data will have to be reviewed quickly, prior to the next flight during envelope expansion.

Data Processing Performance

Reducing the time to process and review data increases the flight rate, and flight test programs succeed or fail based on flight rate. The fastest data processing servers will be purchased, but the best processors at the time of this writing are designed to have 1-2 dozen cores running at a moderate speed. There is simply little to no market for a single core processor running 1-2 dozen times faster. What this means is that your data processing must be multi-threaded and parallelized to the highest extent possible to take advantage of modern processors. Consider this reality when selecting your programming language of choice. Multi-threading in LabVIEW is the standard, not the exception, and parallelized loops are trivial to implement.

Calibrations

You will need to apply calibrations to much of your analog data. Most organizations use linear calibrations for the bulk of their data and use Derived Parameters to implement the occasional polynomial or piecewise calibration. Some organizations also implement pre- and post-flight ambient calibration bias corrections. Whatever your needs, you must be able to take a new calibration post-flight and apply it to the recorded data.

NI MAX and the TDMS file have built in support for calibrating data that meets this standard should a client wish to make use of these tools with little to no development effort.

Derived Parameters and Expression Parsing

Every Flight Test organization will need to compute Derived Parameters which are engineering calculations based on acquired data inputs. These cannot be hard-coded into built code as the formulas or constants often need to change, sometimes as often as daily. The test team must also maintain an archive of the equations in use for every flight. These requirements lend themselves well to a text-based expression file listing the Derived Parameters. Derived Parameter equations can then be copied into the test data file for archiving, or stored in a configuration database.

An expression parser is a program that parses and compiles text-based equations at runtime. Expression parsers are a significant development challenge taking as much as 6 months of coding time to develop from scratch. There are now excellent expression parsers available for most languages as a paid add-on or an open source library. When given the option, use code that is well-vetted for bugs. Generally, widely used paid or open source shared code is preferred to eliminate the chance that your expression parser has a critical bug.

At MGI, we have successfully used the GPower Expression parser which is available as a paid add-on to LabVIEW. Performance is acceptable with one use case evaluating 60,000 expressions per second onboard aircraft without excessive CPU utilization. The GPower expression parser also has an extensive list of supported functions, sufficient for most flight test applications, however that list is not extensible by the end developer. The cost of the GPower expression parser is negligible and should be considered as a well-proven option.

There are also open source expression parsers available such as mXparser and muParser, both of which have very few built in functions, but both are easily extendable by the developer and allow for the addition of user defined functions. The mXparser and muParser libraries can be called from nearly any modern programming language. At MGI, we have used mXparser within LabVIEW, but it has not been evaluated for CPU performance, and we have not yet used it in a flight test application. However, both will receive consideration for our next flight test development project.

Frequency Spectrum Analysis

Flight test organizations typically need at least some digital filtering to clean up noisy measurements, and will use bandpass filters and point frequency tracking (extracting the amplitude at a specific frequency) for the purpose of amplitude evaluation against limits. Butterworth filters are simple to use, but the steeper the cutoff frequency, the more the data is shifted in time. This becomes a problem if you need to use the output of a Butterworth filter as a derived parameter input since the filtered data is no longer time synced to the unfiltered data. An inverse FFT offers vertical cutoff frequencies, but it has a tendency to time average the computed result over the period of the FFT window. Basically, all frequency spectrum processing will be a trade-off between CPU usage, amplitude accuracy, and time accuracy.

FFT Processing

You can’t make good decisions about how to filter your data unless you know what the energy looks like across the spectrum. Do you have driving frequencies near the end of a band of interest? Are the frequencies changing rapidly? The ability to visualize the frequency spectrum is important. For that, nothing beats an FFT driving a 2D color map or 3D waterfall. Both consume RAM, but the LabVIEW 3D plots also consume massive amounts of CPU. Use 2D color maps, but watch your RAM utilization. Either avoid or limit the use of 3D plots in LabVIEW.

Your FFT looks good, but will it give you meaningful amplitudes? If you are using a Hanning window, it will provide very crisp lines in frequency, but amplitudes will be under-reported by up to 15%. This error is generally unacceptable as an input to a fatigue analysis or for regulatory compliance. For best amplitude accuracy, we need to use a Flat Top window. A modified peak detection algorithm can be used to resolve precise peak frequencies. Our best efforts to date result in less than 0.5% amplitude error and about 0.1% frequency error for typical real signals.

Analysis Standardization

There is nothing more frustrating than when you abort a flight for a DNE, then you post-process your data and the post-processing analysis software puts you a fraction of a percent under the limit. This can happen with any limit if you are applying post-flight ambient calibration bias corrections to your data, but this is especially common in the frequency spectrum where various well-configured processing methods can vary in result by up to 15%. The best option is to use the same software to process your real time limits as you use to process your post-flight limits.

MATLAB is pretty good for post-flight data processing, and certainly the best affordable option for great data visualization. That is where it excels, but it doesn’t come close to LabVIEW in computational performance or as a comprehensive programming environment. IADS is pretty good as a telemetry display software, but it does not perform post-flight data processing, review, or reporting. Would we then use IADS for real time monitoring plus MATLAB for analysis and reporting? That is a possibility, but there are issues with this plan that must be considered. IADS has some negatives. It is expensive, can be expensive to integrate, and if used for heavy processing, it will require expensive hardware purchases to handle the workload. It is a good 90% telemetry solution, but how do you innovate when locked in to an off-the-shelf product? How do you tailor your software tools for your projects? Using MATLAB as a data processing and reporting backbone would be very expensive when you consider the labor hours consumed in repetitive tasks.

We recommend a common data processing library that would be called and used in telemetry and in the post-flight processing and reporting work flow. You can use C++, C#, JAVA, Python, or LabVIEW. C++, C#, and JAVA will allow you to make any UI you could possibly imagine. Python is free and known by most young engineers. What do we recommend, every time without question? LabVIEW, because when those developers quote a project the time to completion is 6 to 10 times higher than when quoted by a LabVIEW developer. LabVIEW doesn’t work for everything, but when it does work, it is far cheaper. Don’t use LabVIEW to make web applications, but do use it to process and visualize engineering data. The places where LabVIEW is inappropriate are shrinking now too as Object Oriented Programming and Actor Framework come into regular use amongst LabVIEW developers. LabVIEW still has its limitations, but for the cost savings we think it’s the best choice.