Manned Developmental Flight Testing

Flight test - Manned developmental flight testing

I started my engineering career doing flight test... at least that's how I see it.

My first actual engineering job was doing chip verification at Hewlett-Packard (now HP) on a cache coherency chip being developed for some of their high-end servers. This was around 2001, when HP was still a household name, although its decline into irrelevance had arguably already begun. In any case, I was only an engineering co-op, and my time at HP was short.

My first full-time engineering role was as a flight systems engineer at NASA Dryden Flight Research Center in Edwards, California, starting in 2006.

Dryden (now NASA Armstrong, renamed after Neil Armstrong, who worked there early in his career) is NASA Aeronautics' primary flight test facility. It is located on the grounds of Edwards Air Force Base in the Mojave Desert of Southern California. Edwards, for its part, is the U.S. Air Force's primary developmental flight test facility and home to countless first flights, X-planes, and aviation records.

The NASA-Air Force partnership at Edwards has a long history, beginning with the first supersonic flights of the X-1 and X-2 and continuing through the flights of the X-15, perhaps the most famous high-speed, high-altitude, rocket-powered spaceplane ever built.

As a side note, Neil Armstrong flew the X-15 at Dryden, along with many other notable aircraft. His experience as a test pilot was a major factor in his selection to the astronaut corps.

Anyways, as I mentioned, I started as a flight systems engineer, a role that sits somewhere between a traditional systems engineer and an aviation computer engineer. My responsibilities included systems engineering tasks such as requirements development, process design, and verification planning, but also computer engineering work such as software development, hardware design, and system integration.

It was a great introduction to aviation research, systems development, and aircraft systems integration.

After a while, I also began working as a flight test engineer. Among other responsibilities, that meant flying in the back seats of F-18s, F-15s, F-16s, T-34s, and other aircraft while conducting and monitoring flight experiments. Being a NASA flight test engineer was a tremendous honor and gave me firsthand exposure to the operational side of flight testing.

As a result, I feel I have a fairly well-rounded perspective on the discipline. This post covers some of the high-level lessons I've learned throughout my flight test career, along with a few thoughts on how engineers can find their way into the field.

First, let's discuss what I am not going to talk about.

There are two fundamentally different forms of flight testing: operational flight testing and developmental flight testing.

In operational flight testing, a system is introduced into an aircraft configured as closely as possible to its intended operational state. The pilot's job is to perform normal mission activities and evaluate how the system integrates into real-world operations, as well as identify where it may fail or create challenges. Operational testing typically occurs near the end of the system development lifecycle and is often one of the final steps before a system is fielded across a fleet of aircraft.

We are not going to discuss operational flight testing here. Instead, we are going to focus on developmental flight testing.

In developmental flight testing, a system is integrated into a specialized test aircraft and evaluated under highly controlled conditions. Maintaining precise control of the aircraft's state during a test point is one of the hallmarks of a great developmental test pilot.

In developmental flight testing, a system is integrated into a specialized test aircraft and evaluated under highly controlled conditions. Maintaining precise control of the aircraft's state during a test point is one of the hallmarks of a great developmental test pilot.

For example, a test point might require the aircraft to be at 33,500 feet, traveling at 520 knots, in a 10-degree right-wing-down bank, at full standard power, with full wing fuel tanks when the system under test is activated. Achieving all of these conditions simultaneously is known as being "on condition," and it can be surprisingly challenging.

Fortunately for us, NASA employs some of the best pilots in the world. As engineers, we could dream up demanding test conditions, and they would consistently deliver.

Another useful way to categorize flight testing is by whether the aircraft is manned or unmanned.

For unmanned aircraft, many of the support systems and safety constraints associated with protecting a pilot simply do not exist. Experimental systems can often be integrated more freely because there is no onboard crew at risk if something goes wrong. Manned flight testing is very different.

In manned flight testing, great care must be taken to ensure the safety of the test pilot and to make certain that the system under test can be bounded, overridden, or easily disconnected if necessary. This is because, in developmental flight test, you never assume that a system will work as expected. In fact, the opposite is true. You must assume the system could fail spectacularly and design the test approach so that such failures can be handled safely. In general, this philosophy is referred to as being fail-safe.

Of course, this does not mean that engineers simply install a system in an aircraft and hope for the best. Before a system ever reaches flight test, it must mature through a series of increasingly realistic simulation environments.

The first level of simulation is typically Software-in-the-Loop (SITL) batch simulation testing. At this stage, an approximation of the aircraft's flight dynamics is incorporated into a simulation environment where engineers can manually set aircraft conditions and execute hundreds or even thousands of pre-programmed test cases. The system itself exists only as a software module connected to the simulator. This type of testing is particularly useful for unit-level verification and early system-level testing.

The next level is Hardware-in-the-Loop (HITL) batch simulation testing. In this environment, the software is loaded onto the actual hardware that will eventually fly in the aircraft. Interfaces are developed to replicate the timing and data the hardware will receive in flight. Moving to real hardware often uncovers timing issues, interface mismatches, and integration problems that are difficult or impossible to identify in a purely software-based environment. Because debugging on target hardware can be more difficult, HITL testing is generally performed only after SITL testing has stabilized and most major software defects have been resolved.

The final stage before flight test is piloted simulation. In many ways, this is a rehearsal for the real thing.

Piloted simulations can be conducted using either SITL or HITL configurations, although HITL is generally preferred. This stage serves two important purposes. First, it introduces a human pilot into the system. Human pilots are exceptional software testers because they rarely interact with systems exactly as engineers expect. The timing, coordination, and variability of human actions often reveal issues that never appear during automated batch testing.

Second, piloted simulations allow the flight test team to practice the actual test points that will eventually be flown in the aircraft. At NASA, our rule was that every flight test point had to be successfully flown in simulation before it could be attempted in the airplane.

‍

The Ultimate Validation

After nearly two decades around flight test, one lesson stands out above all others. The purpose of flight testing is not to prove that a system works. The purpose is to learn how it behaves, understand its limitations, and build the confidence required to safely move aviation forward.

As the old Dryden motto reminds us, flight testing exists “to separate the real from the imagined.”