Thursday, November 21, 2019

SpaceX Blows Their First Starship Apart in Texas

On Wednesday at SpaceX' Boca Chica Beach facility, where the first Starship stainless steel ship was the backdrop for a dramatic conference, that very rocket failed during a tank pressurization test according to coverage in Ars Technica.
About halfway during the process, however, some sort of failure occurred as the top bulkhead of the vehicle broke apart and went flying away. This was followed by a large, white cloud of smoke and vapor emanating from the interior of the vehicle, which eventually cleared to reveal a dented, but still shiny Starship. This was the same vehicle the company revealed in late September.

SpaceX sought to play down the accident, noting this was a "max" pressurization test to stress the system. No one was hurt, the company said, and it was not a serious setback in the development of the ambitious vehicle. The company's founder and lead technical designer, Elon Musk, later said on Twitter that this prototype had "some value as a manufacturing pathfinder," but that the flight design of the vehicle would be "quite different."

So what's the deal? Is this a catastrophe for SpaceX that dooms its Starship program? Or just a minor setback as the company suggests? The answer is probably closer to the latter.
Never lose sight of the fact that Musk and the higher level managers in his companies come from the Silicon Valley mindset.  A common idea in the high tech world, is to “fail early”; that is, don't hold development back until you're 100% positive the design is optimal.  Do your computer simulations and math analysis, but (1) prototype as soon as possible, (2) fail early and (3) correct quickly.  That's what SpaceX is doing.  Even more aggressively: they're iterating the design in Texas and here on the Space Coast, bouncing back and forth, incorporating everything they can learn at breakneck speed.
The key to grasping why SpaceX can afford an accident like this is to understand its iterative design philosophy. Under this approach to the design of spaceflight hardware, the company builds vehicles, tests them, and flies them as quickly as possible. And if they fail, as often happens, SpaceX fixes them. This is especially true of the Starship program in which teams of SpaceX engineers in Texas and Florida are separately building prototypes of Starship to learn from them and then improve the design in subsequent versions.

The nomenclature SpaceX uses is "Mark," as in the vehicle the that was severely damaged Wednesday was Mark 1, with Mark 2 being built in Florida, and work already beginning on Mark 3 in Texas. It is possible this "Mark 3" vehicle will fly into orbit sometime in 2020.
Go read that Twitter stream from Musk; you don't need a twitter account (I don't have one) and you can watch some videos of the accident.   You'll also see speculation from people who follow SpaceX closely that the real action is likely to be Mark 3 or Mark 4, and one or both could be built here in Florida. 

This is completely the opposite of how the major contractors and NASA itself have together developed spacecraft.
For casual observers of spaceflight, this "iterative" design philosophy is very different from the much slower, linear design process used by traditional aerospace partners for large development projects. Under this more traditional process, a company—or, historically, NASA—seeks to avoid the risk of a rocket failing before it is perfected. Years are spent designing and testing every component of a vehicle before it is assembled for a full-scale test. As a result the process is much slower and more costly.
The reason SpaceX can do this is that this is self-funded and that means they're not answering to congressional hearings like NASA does. NASA chief Jim Bridenstine said he's glad some contractors are working this way; saying “I like it being a part of the mix of our contract capabilities.”
It is easier for a company like SpaceX working on a self-funded project like Starship to do this than a government agency, noted Phil Metzger, a planetary scientist at the University of Central Florida. "You have to let people see you fail, and you have to push back when the critics use your early failures as an excuse to shut you down," he recently said. "This is why it is hard for national space agencies to adopt it. The geopolitics and domestic politics are brutal."
During design, we frequently run into situations where two slightly different analyses of a design get drastically different results, or one camp gets set up thinking an approach will work and another camp says it won't.  It gives rise to the cliche' that “one lab experiment decides six months of arguing theories.”  The essence of the iterative design approach is to get to that lab experiment as fast as possible and not spend six months arguing.

Pad explosion, seconds after the top of the pressure vessel decided it wanted to get a closer look at some other place.  SpaceX photo.


  1. Smart, corporate, bold, not at all NASA of the 2000's

  2. This is how Aerospace companies used to do prototyping and first production runs.

    "Um, wings fell off." Make stronger wing attachments.

    "Um, engine caught on fire and burned plane." Fix engines, fix fuel lines, install engine fire extinguisher.

    "Um, plane crashed after pilot took it up really high." Well, fix engines and fuel systems to handle high altitude, or check to see what happens to people at high altitude, or both (this really happened, though on Zeppelins in WWI, really...)


    1. A latter example that goes along with what you noted was the development of the F-102. The original design had straight fuselage sides. When the YF-102 tried to go supersonic the transonic drag was so high that the plane could not achieve supersonic speeds. After analysis it was found that the "area rule" was causing this; a principle discovered by German aerospace engineers just before or during WW II. They changed to the shape to the now classic "wasp waist" and the problems was solved.

      We don't have to do it quite that crudely anymore. There are design tools that make it so that the problems encountered are generally just refinements and not major re-dos.

    2. It was the way NASA worked in the 50s and early 60s. No one knew how to do much of what they were trying to do. The only way to learn some of it was by experimentation.

      No one accepts that idea now.

    3. Please read around my spelling and grammatical screw ups!! It is late for me today.

  3. I would say that SpaceX is doing their development more along the lines of some of the software development models. The first that came to my mind was the Agile model. However, looking software development models up on the Internet gave a few others. SpaceX's process seems to be a mash up amongst these.

    As to the comments about the "classic" way that space flight hardware has been developed, I made a similar observation a few years ago at the lunch table when discussing SpaceX. I worked for a major aerospace/defense contractor that has a hand in the space launch business. I told a co-worker that SpaceX and our company were not really competitors because of our methodologies and need to work under contract.

  4. What I like about SpaceX is when they screw up, they don't try to hide it. They celebrate it. And crow about how this time x part lasted 10 seconds longer than last time, whooooo!!!!

    Like their 'Ooops, bad landing' video compilation of missed landings.

    Or like when they blew their first super-super-cooled O2 tank on a Falcon 9. Their take was basically, "Well, we thought the current parts would hold, but we weren't sure, but, hey, we tried. So now we fixed that part and got 120% improvement on range and payload lift and the insurance company paid out for the blown satellite, so, well, life's good, right?"

    Musk even admits they were one more Falcon 9 failure from closing down, before they got it right.

    But the key in all their mistakes is they didn't cover up, they exposed what happened, how it happened, how they'd fix it, and do it all in the open. That takes serious chutpah.

    If only some of the early work on the Apollo capsule had been done so openly, we might not have lost 3 pioneers. Or maybe we would. But we as a nation possibly would not have been as shocked.

    Or the coverup over both Shuttle accidents, when engineers had been trying to get the word out about both conditions (bad o-ring design not able to handle cold temperatures, ice and crappy insulation falling off of main tank and impacting the orbiter.) Both known faults, both had evidence before the fatal accidents that the accidents would happen. But it was cover-up, cover-up, oh, crap.

    Maybe it's just the difference between the secretive military-industrial complex (ooohhh, conspiracy talk.... ooooohhh...) and a privately-funded company.

    Makes me wish a lot of those little space startup companies that seem to have fallen away would have kept up so open communication with the world, rather than hiding their 'preciousess' from us space-geeks and groupies.

    1. Maybe SeaLaunch would have lasted longer with better public exposure. Really. I kept my ear open to a lot of stuff about space but never heard of them until reading drjim's website and doing backtracking. What a cool concept. What an opportunity. What a colossal loss.

      The way to space looks to be paved by the skeletons of thousands of aeropspace companies.... Sigh....

    2. I'm not sure "public exposure" would have helped. There were many, many restrictions placed on us by ITAR, the State Department, and even Congress. The launch vehicle was considered a "State Secret", there were legally required "firewalls" and "cut-outs" all over the place between the partners to prevent the exchange of certain technical information, and while it was cumbersome, we made it work.

      Sea Launch was well-known in the industry, had a "good" launch success rate, and was well-liked by the customers when Boeing ran things.

      Then the Chapter 11 event happened, the Rooskies took over, and things really changed, but not for the better.

      We were flat-out LIED to about a lot of things, had many promises to us broken, and after they finished the five launches still "on the books" from before Chapter 11, they found out that their management style made it very hard to book new launches.

      The Russian and Ukrainian guys I worked with were great people, but their middle and upper lever management absolutely, completely, and utterly didn't know how to do business in the industry, -OR- in the United States.

      Long, long story. It really was one of those "You Had To Be There" experiences.

  5. I have worked in construction engineering almost all of my life. Testing to failure is not at all uncommon. Even the mundane task of breaking cylinders tells us more than just compressing to design.

    1. My dad worked on a project where they actually got some enlisted to finger-fork the stuff in an 'enlisted man-destruction trial.'

      Making stuff enlisted-proof is, apparently, a rather difficult thing. But necessary.

      And... what Air Force enlisted can break is different from Navy or Army. Marine enlisted can break everything, apparently.

    2. Don't enlisted Marines exist for the sole purpose of breaking things?

    3. I always heard it was to kill people and break things. So, yeah, but not just breaking things.

    4. Marines use "tools" to break things and kill people with. Marines respect their tools the way a fine furniture craftsman respects his tools. But the tools need to be up to Marines standards. therefore, test to failure and then make it better so it won't fail in use. hence the "enlisted finger-forking testing" down at Quantico.
      the USAF on the other hand, don't allow the enlisted to have input on design and testing of equipment; only the officers do that. of course, officers don't have a clue why something breaks and less idea of how to fix what's broken. they depend on the enlisted guys and gals to take care of the nuts and bolts. so who breaks what how often really depends on who your talking to. unless your talking about that designed by committee winged turd, the F-35. way too many oars on that particular canoe.

  6. Considering the "shatterproof glass" in his Tesla truck, I am not one bit surprized...

  7. It seems to me that SpaceX is following the "release early, release often" or "fail faster" approach common to software development on the Bazaar model. That model doesn't map perfectly to aerospace R&D, unless you cool videos as part of the version release process. It does keep eyeballs coming back, so maybe both successful launches and disastrous misfires do count as a product release. NASA is stuck in the Cathedral model, and consequently in the past.

    1. After about 2005, the company I've called Major Avionics Corporation went to the "fail fast" development model. I heard the saying at some point that if it works the first time, it isn't innovative enough, which might be taking it a bit too far.