25
$\begingroup$

It's been claimed or suggested in other posts that during the entire history of the Space Shuttle, only one software bug actually survived the development and review process, making it to flight. Even if the claim of only one bug is an urban legend, the number of bugs was far less than what occurs in commercial software, and that's a testament to the care taken by the shuttle software developers.

What was the nature of the bug(s) in the Shuttle software?

  • Which phase of flight (e.g. launch, re-entry) was affected?
  • What Shuttle systems were involved?
  • What was the normal behavior supposed to be?
  • What did the bug do?
  • Did any undesired behavior actually occur during a mission?
Improve this question
$\endgroup$
7
  • 3
    $\begingroup$ False premise. More than one bug flew. There was a FSW problem experienced in flight in one of the last 10 missions. (Not at home so can't be more specific right now) Also a Lambert targeting error. I can think of several w/o research. $\endgroup$
    – Organic Marble
    Jul 5, 2019 at 1:38
  • 1
    $\begingroup$ @OrganicMarble: What would be a better way to phrase the question, then? $\endgroup$
    – DrSheldon
    Jul 5, 2019 at 2:28
  • 1
    $\begingroup$ Don't make it sound like there was only one, $\endgroup$
    – Organic Marble
    Jul 5, 2019 at 3:52
  • 3
    $\begingroup$ In one of the linked answers I said "The total bug count hovers around 1. At one point around 1996, they built 11 versions of the code with a total of 17 bugs. " i.e. one known bug at a time, not one in total for the whole program. $\endgroup$
    – Hobbes
    Jul 5, 2019 at 7:03
  • $\begingroup$ The first linked answer never says there was only one bug flown. It says they believe there was only one SEV-1 bug. And it says they they know they personally introduced one bug. $\endgroup$
    – OrangeDog
    Jul 5, 2019 at 9:56

2 Answers 2

Reset to default
40
$\begingroup$

Although the Space Shuttle flight software was of outstanding quality, it's completely incorrect to think that there was only one bug. There were many known bugs in the flight software (FSW). Here are three I can think of off the top of my head that impacted missions.

  1. The flight campaign of the Shuttle program started out with an embarrassing software bug! The very first launch attempt was scrubbed when the Backup Flight Software (BFS) computer refused to synchronize with the four Primary Avionics Software System (PASS) computers. Details in "The Bug Heard Round the World" here.

  2. Space shuttle Endeavour's first flight (STS-49) was action packed for many reasons. One was that a bug was found in the Lambert targeting software used to calculate rendezvous parameters. The calculation failed to converge

    due to a mismatch between the precision of the state vector variables, which describe the position and velocity of the Shuttle, and the limits used to bound the calculation

    (source) (This paper talks about additional shuttle FSW bugs)

    Additional detail on mission impacts of the Lambert software problem, and discussion of other FSW errors impacting rendezvous missions here

  3. As late as STS-126 in 2008, a new bug surfaced in the OI-33 software release. After Main Engine Cutoff, two communications systems that were supposed to automatically transition from their launch to orbit configuration didn't, because of a coding error.

    Primary communications continued to use S-band frequencies after they should have transferred to the more powerful Ku-band. The link between the shuttle and its payload—the Payload Signal Processor (PSP)—remained configured for a radio link rather than switching automatically to the hardwired umbilical connection.

    All the detail you want on this problem is here.

Several other bugs showed up in Shuttle Mission Simulator training. They were uncovered there because of the extreme nature of the training scenarios compared to actual flight or the FSW verification facilities. They never impacted missions, but they were bugs that flew. There's a presentation about these bugs (the ones that were serious enough to crash the vehicle) here. Here's a fun one from that presentation - the PASS completely hung up on a Transoceanic Abort Landing (TAL). The crew had to engage the BFS.

Courtesy of Tristan, here's a slide from another presentation by James Orr showing ~425 flown FSW bugs (listed as DRs - Discrepancy Reports) at the peak around 1983.

enter image description here

Source

TL;DR: If someone tells you the Space Shuttle had only one FSW bug, don't buy any real estate from them.

Improve this answer
$\endgroup$
13
  • 3
    $\begingroup$ IMO, a bug with a workaround is still a bug. But you weigh up the probability of it manifesting, the severity when it does, and the complication of the workaround; and you compare that with the risk of introducing other bugs when attempting to fix it. $\endgroup$
    – Roger Lipscombe
    Jul 5, 2019 at 10:46
  • 2
    $\begingroup$ @RogerLipscombe concur. The fix for the Lambert targeting problem introduced another bug (this one was found in the Shuttle Mission Simulator right before flight. Good times.) $\endgroup$
    – Organic Marble
    Jul 5, 2019 at 13:02
  • 6
    $\begingroup$ @DavidHammen: I disagree with the definition. A bug only becomes a feature when what was originally an undesirable (side) effect becomes a desirable (side) effect. A workaround does not make a bug's effect desirable, it just makes it manageable. $\endgroup$
    – Flater
    Jul 5, 2019 at 14:05
  • 1
    $\begingroup$ @Flater Absolutely correct. The term feature is explained in "The Hacker's Dictionary" by a little dialogue. It also says: `Undocumented feature' is a common, allegedly humorous euphemism for a bug. A known bug never becomes a "feature" unless you apply heavy marketing magic. $\endgroup$
    – David Tonhofer
    Jul 5, 2019 at 14:52
  • 3
    $\begingroup$ The downward trend of this graph seems really encouraging until you realize that 25 years is almost as long as the graph and many newer bugs might yet still be undiscovered if it takes that long to find them. $\endgroup$
    – candied_orange
    Jul 6, 2019 at 15:59
7
$\begingroup$

As the author of 1 of the posts you reference about the number of bugs found, you've misunderstood the words. Please re-read them.

On the STS, a "bug" is when the software did not meet the requirements. It didn't necessarily mean something bad would happen, just that the code didn't match the requirements. The developers didn't classify the bugs. For overly complex bugs, a developer might be asked for analysis. Nothing was called "a feature" if it wasn't in the requirements. That would be a bug too.

Additionally, the developers weren't allowed to fix bugs without formal authorization. We weren't allowed to change any line in the source that wasn't directly related to the change authorization we were working under. We weren't allowed to change indentation to make the code more readable, unless our changes nearby were significant enough. These restrictions were to prevent accidental changes, which would lead to accidental bug introduction. Every line changed was tagged to a specific individual and CR/DR authorization.

Especially with guidance calculations, sometimes the requirements couldn't be implemented due to limitations of the computers. In real-time coding, a late answer is just as bad as a wrong answer. At least once, the requirements needed to be changed to match the code.

Nobody knows the real number of bugs in any software at any time, but Jim Orr literally wrote the book on Space Shuttle software issues and errors. He was provided all the data on requirement reviews, design reviews, testing plan reviews, code review and test results when I worked there for the GN&C FSW

There were definitely hundreds of bugs in the FSW, very few were considered SEV-1. None would cause a computer lock up or other typical error people put up with in their lives today. The GN&C code didn't have issues like typical desktop or server code does. There wasn't any dynamic memory allocation. Use of pointers required a written, approved, variance from the SW standards board. All the code was formally peer reviewed by at least 6 people. More complicated code would be reviewed by 20+ people - in the same room. Over the decades, the process used to create the software was always improving. The process was setup in such a way that it didn't rely on super programmers to create relatively bug free software. It really was all about the process.

Over my decades writing software at many different companies, I've seen that everywhere else depends/hopes on the super programmer idea to produce better results. The problem with this is that super programmer isn't easily reproducible. I've seen it work 1 place and only because each programmer considered any bug a personal failure. Everywhere else is stuck with good, average, and bad programmers. Especially in larger organizations, the scale seems to shift towards bad more than other places. There are always exceptions and obviously, even if I've worked directly with 3000 programmers professionally, that isn't all programmers everywhere.

Hope this clarifies and is helpful.

Improve this answer
$\endgroup$
1

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.