NASA safety panel raises more questions about Boeing and Starliner

In its quarterly meeting yesterday, NASA’s safety panel raised more questions about the software problems during the unmanned demo mission of Boeing’s Starliner manned capsule in December.

NASA’s Aerospace Safety Advisory Panel (ASAP) revealed today that a second software error was discovered during the uncrewed Boeing Starliner flight test in December. Had it gone undetected during the flight, it had the potential to cause “catastrophic spacecraft failure” during reentry. The panel wants a complete review of Boeing’s software verification processes before NASA decides whether a second uncrewed flight test is needed. In an email this evening, Boeing said it appreciates the input and is working on a plan with NASA to address all the issues and decide what comes next.

In that Boeing email it noted that it was “unclear” what the consequences would have been if this second software issue had not been fixed.

The safety panel also called for an overall organizational review of the entire Boeing company, similar to the review done to SpaceX after Elon Musk was videoed taking a toke on a joint during a podcast interview.

The decision on whether Boeing will be required to fly another unmanned demo mission is targeted for before the end of February.

One comment: While there is clear evidence here that Boeing had issues on that demo flight that must be resolved before humans fly on Starliner, we must also recognize that NASA’s safety panel has an unfortunate tendency to overstate risk, demanding margins of safety that are frequently unrealistic for an endeavor pushing the envelope of exploration. That panel has also exhibited an almost corrupt bias against private commercial space, while looking past much more serious safety issues in the NASA-built SLS and Orion programs.

At the same time, the larger corporate issues here with Boeing do appear far more systemic and concerning that those that occurred with SpaceX. A cold independent audit of the company by NASA could actually do Boeing a lot of good.


  • Diane Wilson

    From what I’ve read on this latest software issue, there’s not much question that it would have caused mission loss. The thruster firing in this issue would have caused the service module to ‘re-impact’ the capsule after service module separation. And the obvious impact area would have been the heat shield.

    Unlike the “yeah, astronauts on board could have fixed this” response to the timing-related thruster problem, there would have been no warning, and no control interface to the service module after separation.

    One of the scary aspects of this issue is that the problem was corrected by a software update uploaded two hours before re-entry. Rather than take the easy – and also correct – route of blaming Boeing, this kind of cowboy-coding seems to be endemic in industrial control development. One commenter over at Ars Technica said that he’d worked in exactly that kind of environment, and only after he left industrial control programming and went to work for a gaming company, he then learned about all the software practices that lead to quality and reliable software.

  • Edward

    From the Space Policy Online article: “The panel wants a complete review of Boeing’s software verification processes before NASA decides whether a second uncrewed flight test is needed.

    Well, now we know why Beoing put aside $400 million for a possible second unmanned flight. It looks like there is not yet enough confidence in the system and the company.

    However, the article does not say whether this second software problem was related to or independent of the overuse of the thrusters or the thruster that was not returned to service.

    From the article: “We are no longer building hardware into which we install a modicum of enabling software, we are actually building software systems which we wrap up in enabling hardware. Yet we have not matured to where we are uniformly applying rigorous systems engineering principles to the design of that software. These are serious and pervasive issues that NASA will need to address in all of its programs and certainly will be critical to space exploration endeavors.

    Isn’t this a problem that we have with a whole host of consumer goods, too? For example:


    From the Space Policy Online article: “McErlean emphasized that NASA must be ‘absolutely clear’ on its hardware performance requirements and not just tell contractors what the hardware must do, but ‘how are you going to prove to me that your hardware does it.’

    Well, that does not sound new, to me. When I was in the verification part of space engineering, that was what I had to do during our Preliminary Design Review for NOAA’s Solar X-ray Telescopes, which flew on GOES 12 through 15. (This was back in my days with a solar astrophysics laboratory.) I am getting two different impressions from this section of the article.

    First, the ASAP is not impressed with how NASA’s contractors are performing. They have long had problems with both SpaceX and Boeing on their Commercial Crew Transportation Capability project. Both had parachute problems, and Boeing’s recent software problem is disturbing to more than just the ASAP, especially since Boeing is the more experienced company.

    Second, the article said that “McErlean noted that there is almost no one in the workforce today with experience building these types of systems and it is ‘very much a breathtaking level of responsibility from an engineering perspective.[‘] ” This suggests to me that our decades-long hiatus from building manned spacecraft and relying solely on the Space Shuttle is now coming back to bite us. ASAP is now complaining that we lack experienced design people. This is not just across the United States, but even the Soyuz and the Chinese variant, Shenzhou, were originally designed before the Space Shuttle. Boeing’s Starliner, Lockheed Martin’s Orion, and SpaceX’s Crew Dragon are the first manned spacecraft to be designed in the past four decades. That is the length of the usual career, so there are few people left who are experienced with design of maneuverable, manned, reentry spacecraft.

    ASAP seems to be worried that we now face the tripple threat of lack of experience in designing such manned systems, lack of experience designing and testing software/hardware systems, and that those with the most experience are not doing it right.

    This may be the challenge of the next decade, and it seems to me to be a big deal. If ASAP is right then we may have to learn lessons that we had already learned before, with the added problem that software engineering is still a fairly new field that has yet to learn many lessons.

    A major part of the solution, as I see it, is to get as serious and dedicated as the U.S. Airlines did, back in the late 1970s or early 1980s, when they realized that if they kept having fatal accidents at the per-flight rate that they had back then, then with the rapidly rising number of daily flights they would be making headlines every week, and that could destroy the industry. Boeing was a major airliner manufacturer that understood this. At least they did until recently. The U.S. manned space industry must get serious sooner rather than later and dedicate itself to safety before losing crews and passengers at the rate that the airlines did in the last century.

    We need to not make mistakes with the parts of spaceflight that we already know, including lessons learned during the last century or so from aircraft flight. However, we will certainly continue to lose people during spaceflight, because there is plenty that we still don’t know, and we need to learn those parts as quickly as we can. As Bill Whittle put it, “That’s the deal.” (Bill Whittle, “The Deal,” 7 minutes)

  • Scott M.

    NASA and Boeing had a press conference today (Friday the 7th) at 3:30 PM Eastern to address this whole mess. I missed it, did anybody happen to catch it?

  • Scott M: I was just writing up a post on that press conference when you posted your comment.

Leave a Reply

Your email address will not be published. Required fields are marked *