Transonic Wind Tunnel Test System Upgrade

Challenge

Calspan operates a transonic wind tunnel capable of continuous Mach-speed testing a wide range of aircraft designs.

The overall test system was comprised of three subsystems that were all state of art at the time of design, over 20 years ago, but components were either obsolete or soon becoming so.

Calspan contacted us, and others in a competitive bid, to design, reuse, replace, and build a new test system to maintain and even upgrade the test capabilities. At a high level, the requirements were to provide similar signal conditioning, hardware functionality, and software user experience.

Working together

Collaboration between our teams was key to success for this upgraded test system.

From the start, we all agreed that we’d have to do some reverse engineering to extract the details and nuances of the existing test system. This task was accomplished by reviewing existing items such as documentation and C++ code. As anyone who has done obsolescence upgrades knows, sometimes the source code is the best source for system requirements due to the wealth of details inherent in source code. Also, some aspects of system operation could not be easily documented, and Calspan personnel helped with defining the desired user interface  and user experience.

The reverse engineering effort was enlightening and critical to assure that we all knew where we were headed.

Some highlights of design topics on which we collaborated:

The balance between full automation and manual operation was also discussed during initial collaboration. Calspan felt more comfortable with, and was familiar with, operating in a semi-manual mode, where walking through a test sequence was best handled semi-automatically with a set of operators at their stations. Nevertheless, we were able to suggest some improvements to the system useability and extensibility. For example:

Overall, we followed an iterative, Agile-like approach to design while using the technical details of the existing hardware and source code from the three subsystems to dictate the requirements necessary to reproduce, and even extend, the existing functionality.

Solution

The data acquisition part of the test system was implemented in two parts:

1. a Precision Filters, Inc. (PFI) signal conditioning front end and,
2. a National Instruments PXIe data acquisition chassis and modules. The PXIe chassis is connected to a server-class PC with MXI to handle all the acquired data and communication messaging between this test system and other special instruments and subsystems.

The signal conditioning was implemented with 128 channels of Precision Filters, Inc. 28124 transducer conditioner. This hardware is the only equipment on the market that met the needs of the client due to its capabilities for voltage and current excitation and a slew of gain and analog filtering options. PFI equipment is used extensively in wind tunnel and other critical measurement applications where performance, stability, and reliability are crucial, so the fit made a lot of sense. Also worth noting, although PFI offers an API to their chassis to enable automated or interfaced calibration, we chose to use their native calibration application because it just works and our interface would have been just a thin shell talking to their software.

The PXIe data acquisition is comprised of 128 channels of 24-bit, 200 kS/s digitizer analog input and additional 24-bit, 5 kS/s digitizer analog inputs. The PXI equipment is connected to a server-class PC via an MXI interface. The MXI interface offered the required bandwidth, and the server-class PC had plenty of processing power to manage the data flow from A/D to file storage while tending to the user displays. This arrangement is capable of simultaneous processing, alarming, visualization, and storage to disk at full rate.

Software was implemented almost entirely using Visual Studio C# and .NET 8.0. A small, but important, signal transformation portion was developed in LabVIEW Real Time on a Compact RIO.

User interface, test and sensor configuration, data acquisition, data processing, data storage, force balance calibration and alarming are all implemented in .NET.

Another overall goal was Calspan’s desire to maintain the application software. We tackled this goal in two ways:

1. First, the original software spanned 4 code bases: 3 for the 3 subsystems mentioned above and 1 for calibration measurements. Not an ideal arrangement for software maintenance. When we rewrote in C#, the code base was refactored so that common software classes could be shared, such as data acquisition functionality.
2. Second, it is very typical that Calspan’s customers have some unique measurement requirement such as specific sensor selection or additional measurement or control equipment. These requests are more easily accommodated by Calspan now, as compared to the previous system, because the refactoring and combining of the apps simplifies code edits.

Benefits

The main benefits of this obsolete test system upgrade were:

Also important to mention is the benefit of working with a collaborative team. The existing system, composed of the multiple subsystems, was complex with many subtleties. As with many older systems, the existing documentation was missing some important requirements – it’s just plain hard writing requirements. Without Calspan and Viewpoint having an open dialog and willingness to spend the time to understand options and make appropriate tradeoffs, the benefits of this upgrade project would not have been realized as cleanly. The collaboration was especially important in the design and acceptance testing phases of the project.

How we helped

System Overview