How Baggage Claim at SEA-TAC Almost Delayed X-32 First Flight

FIFTH GEN FIGHTER FLY-OFF

 My wife and I traveled back to Seattle recently. It was the first time I had been in the SEA-TAC airport in about 25 years. One of the few details I remember from the airport was that the luggage conveyor belts in baggage claim deliver your bags from above. They are not at ground level like most airports. This was a critical detail on the path to first flight of the Boeing X-32 https://en.wikipedia.org/wiki/Boeing_X-32

X-32B at Takeoff

The X-32 was a demonstrator in a fly-off with the Lockheed X-35. That competition was captured in the NOVA program Battle of the X-Planes https://www.pbs.org/wgbh/nova/xplanes/about.html. The winner of the competition would be awarded a decades-long, trillion-dollar contract to build the fifth-generation fighter for the entire allied Western world. As we all know now, the Lockheed F-35 would eventually win this battle.

X-32 FLIGHT CONTROLS TEAM

I was part of the flight control system design team for the X-32 (one of the ugliest fighter aircraft ever designed). I was in charge of control system architecture. The flight control system design team’s job was to design and test the aircraft’s control system. A control system in a modern aircraft includes the hydraulic or electric pistons that move the parts of the wings that steer the aircraft in flight, along with the computers, sensors, and software that control those hydraulic pistons. We (Boeing) had decided to use a computer called the Integrated Flight Propulsion Computer (IFPC) to be the center of our control system.

The IFPC was good at a lot of things, but high-speed processing was not one of them. The X-32 was two aircraft with two different roles. A Conventional Take Off and Landing (CTOL) variant and a Vertical Take Off and Landing (VTOL) variant. There was no time or money to design separate control systems for each variant, so all the processing for both versions of the X-32 had to fit into the same operational flight program (OFP), inside the same IFPC. My job on the X-32 was to architect the software and hardware of the IFPC, and the sensor interfaces in the aircraft, so that we could stuff all the CTOL and VTOL controls into the same overcrowded system.

Experimental fighter jets are not held to the same safety standards as commercial transport aircraft. There is no FAA certification process like there is for a 787 or an A350. However, there is still an airworthiness process that must be completed. There is still a human life at stake, and I always felt a responsibility to the pilots that flew the aircraft I helped design - and to their families. This was especially true for the X-32 program.

 The X-32’s flight control system was fly-by-wire. This means it is completely dependent on its computer - the IFPC - to fly.  It was my job to see that the IFPCs would never shut down in flight. A blue screen of death (BSOD) on your laptop means you have to rewrite your report. A BSOD on your flight control computer means you are not coming home today.

MOVING FROM DESIGN TO TEST

 By 1999, the X-32 program was transitioning from design to test. Our name for the test team was the Box Level IFPC Verification team - or BLIVers. Engineers love acronyms - and this was one of the favorites from my career. We knew we had arrived when the X-32 VP used that term in a town hall meeting.

 It was my job on the BLIV team to stress the IFPCs in all manners of the flight envelope, and in all failure scenarios to prove they would continue to properly control the aircraft. I needed a special type of high-speed data acquisition system (DAS) that as far as I could tell did not exist. I hired an outside company to help me. They had some test hardware that was sort of close to what I needed, but I would need to write all of the test software. They said their test hardware was in “beta”. I came to learn that “beta” hardware really just meant I got to be a key member of their development team - not just the BLIV team. 

After several months of development, I had a test system that worked. This system was two large data input cards inside a PC chassis. One analog and one digital card. It also had a large number of cables. With that system, and some special sauce we added to our flight software, I could build a map of the data flow and the timing of every task across all four CPUs in each of the three IFPC channels. 

First flight of the X-32 was planned for September of 2000. We thought we were ahead of Lockheed, and we believed that flying first could help us win the competition. One of the last hurdles to clear the flight control system for flight was a series of tests I would run with my DAS in the hardware integration lab in Seattle.

WHAT WAS I THINKING?

We were just a few weeks from first flight. I had to travel from St. Louis to Seattle with my DAS. I decided to check this one-of-a-kind, priceless test system inside the cardboard box the PC was shipped in. Looking back 25 years later, it still sounds like a bad idea. I used all the antistatic bags and packing material I could find, taped them all inside this box, and headed to the airport. 

I can still remember standing at SEA-TAC baggage claim waiting for the box to arrive. If TWA lost that box, the X-32 would not fly in September. I was very relieved as I saw the box appear at the top of the luggage conveyor. Then something unbelievable happened: the box did not ride peacefully down the conveyor belt; it tumbled and bounced all the way down and landed with a big THUD. There was a collective GASP from everyone standing in the luggage area.

I was horrified. I did not think there was any way the fragile PC components could survive that crash landing. How could I ever explain to the director of flight controls and the program VP that I caused an indefinite slip to the first flight of a potential trillion-dollar program because I was too cheap to buy a Pelican case for my test equipment? 

I grabbed the box, went to the lab, and to my surprise, the test equipment survived the crash landing in the baggage claim area. I ran a whole series of tests that afternoon and found a serious flight control software flaw. I worked through the night, found the root cause, sent the data to the software team in St. Louis, and they had a fix sent back to me by the next evening. That new software build was good and became the version we used for first flight on September 18, 2000. It was a pretty good days work for a BLIVer.

We did it, we beat Lockheed to first flight by 36 days! Unfortunately, an earlier first flight was not enough to overcome the bad looks of the X-32, and the incredible design of the X-35. The X-35 won the fly-off and became the fighter we now know as the F-35 Lightning II on October 26, 2001.