Episode Summary:
65 years ago, the Eisenhower Administration authorized a number one priority missile program to develop an ICBM as fast as humanly possible. That program, Atlas, combined R&D, design, development and manufacturing into one process, compressing a decade of engineering into a couple of years. It worked, but was very expensive and the prime contractor, Convair, blew up a lot of equipment getting there.
Today, SpaceX is using a similar doctrine of concurrency, engineering, testing, building and flying rockets almost before the dust settles on the company’s Texas launch pad. It’s fast, but the last four test flights have ended in explosions. Can this build fast, break fast, iterate fast methodology turn out to be the best way forward? Jim Anderton comments.
Access all episodes of End of the Line on Engineering TV along with all of our other series.
Transcript of this week's show:
Well, the dust has settled at the SpaceX Boca Chica Texas launch site, dust that spends more than a little time bouncing around. The company’s large Starship test vehicles are launching almost weekly these days, and last week’s catastrophic failure of serial number 11 is the fourth consecutive explosion of a Starship vehicle. Now, for most engineering programs, loss of four large test vehicles in consecutive flights would result in a pink slip for a program manager, but one of the beauties of running your own business is that no one’s looking over your shoulder when you decide to do things radically differently. Elon Musk’s strategy is simple: all-up system testing, by building a lot of hardware, launching it frequently and iterating their way to success.
The traditional aerospace way is to build components, test, screw components into assemblies, test again, then bolt the assemblies into vehicles, test again. Then test some more, and launch. This belt-and-suspenders approach does reduce risk and increases overall system reliability, but it’s slow, and expensive. What SpaceX does is something that actually has its origins in the mid-1950s. It’s called concurrency, and the idea is that the program runs research and development, prototyping, testing and manufacturing all at the same time, saving years in a complex program like a space launch booster.
This is done in the mid-1950s with the General Dynamics Atlas missile program, where the need for speed and the Cold War meant throwing away the highly conservative development methodologies of the airplane industry in favour of a build it, break it, modify it process. In the Atlas program, the result was a bunch of catastrophic failures, so many those congressional inquiries, the news media and even stand-up comedians began to question the competence of the American aerospace industry. In the end, Atlas worked, and worked well enough that it became a major satellite launch system for 50 years. During development however, the General Dynamics team faced an unhappy U.S. Air Force customer, politicians circling like sharks, and nervous shareholders. In the meantime, the USAF had contracted a rival company Martin, to build a second missile system as a backup plan. The pressure was on and there was no guarantee that the Atlas program would succeed, and if it hadn’t, it likely would have driven General Dynamics out of the rocket business altogether.
More than a few engineers that I talked to in aerospace and other disciplines do wonder why SpaceX expends expensive test vehicles this way. Advanced simulation should be reducing the need for risky all-up system testing, and the failures so far are engine related, and in the atmosphere, so test stand work would seem to be easier on equipment. The most remarkable thing about the SpaceX development process is that the normal bureaucracy in the form of an accident review board, followed by a report, recommendations and a formal engineering change process is either so fast that the company rolls out the next rocket before the cause of a previous failure is known, or that the amount and quality of telemetry is now so large that postflight analysis of hardware just isn’t necessary anymore.
And if the hardware itself is evolving quickly, it’s also possible that every test flight represents an obsolete configuration, so there’s a lot to learn and little to lose by turning those boosters into stainless steel confetti. But it doesn’t look good, and like Atlas, a big string of catastrophic failures early in a program means that the mature system had better be reliable, like the company’s other rocket program Falcon. It worked in the 50s, so it should work today.