Selv om Space Shuttle-programvaren var av enestående kvalitet, er det helt feil å tro at det bare var en feil. Det var mange kjente feil i flyprogramvaren (FSW). Her er tre jeg kan tenke på fra toppen av hodet mitt som påvirket oppdrag.

1. Flykampanjen til Shuttle-programmet startet med en pinlig programvarefeil! Det aller første lanseringsforsøket ble skrubbet da Backup Flight Software (BFS) datamaskinen nektet å synkronisere med de fire Primary Avionics Software System (PASS) datamaskiner. Detaljer i "The Bug Heard Round the World" her.

2. Romfergen Endeavours første flytur (STS-49) var actionfylt av mange grunner. Det ene var at det ble funnet en feil i Lambert-målrettingsprogramvaren som ble brukt til å beregne møteparametere. Beregningen klarte ikke å konvergere

   på grunn av et misforhold mellom presisjonen til tilstandsvektorvariablene, som beskriver plasseringen og hastigheten til skyttelen, og grensene som ble brukt for å binde beregningen

   ( kilde) (Denne artikkelen snakker om ekstra shuttle FSW-feil)

   Ytterligere detaljer om misjonseffekter av Lambert-programvareproblemet, og diskusjon av andre FSW feil som påvirker møteoppdrag her

3. Så sent som STS-126 i 2008, dukket det opp en ny feil i programvareutgivelsen OI-33. Etter Main Engine Cutoff, gjorde ikke to kommunikasjonssystemer som skulle overgå automatisk fra lansering til bane-konfigurasjon, på grunn av en kodefeil. de burde ha overført til det kraftigere Ku-bandet. Koblingen mellom skyttelbussen og dens nyttelast - Payload Signal Processor (PSP) - forblir konfigurert for en radiokobling i stedet for å bytte automatisk til den fastkoblede navlestrengstilkoblingen. dette problemet er her.

Flere andre feil dukket opp i Shuttle Mission Simulator-trening. De ble avdekket der på grunn av den ekstreme naturen til treningsscenariene sammenlignet med faktisk flytur eller FSW-verifiseringsanlegg. De påvirket aldri oppdrag, men de var bugs som fløy. Det er en presentasjon om disse feilene (de som var alvorlige nok til å krasje kjøretøyet) her. Her er en morsom presentasjon - PASS hang helt opp på en Transoceanic Abort Landing (TAL). Mannskapet måtte engasjere BFS.

Med tillatelse fra Tristan, her er et lysbilde fra en annen presentasjon av James Orr viser ~ 425 fløyne FSW-bugs (oppført som DRs - Discrepancy Reports) på toppen rundt 1983.

Kilde

TL; DR: Hvis noen forteller deg at romfergen bare hadde en FSW-feil, må du ikke kjøpe noen eiendom fra dem.

Som forfatter av 1 av innleggene du refererer til om antall feil som er funnet, har du misforstått ordene. Vennligst les dem på nytt.

På STS er en "feil" når programvaren ikke oppfyller kravene. Det betydde ikke nødvendigvis at noe ille ville skje, bare at koden ikke samsvarte med kravene. Utviklerne klassifiserte ikke feilene. For altfor komplekse feil kan en utvikler bli bedt om analyse. Ingenting ble kalt "en funksjon" hvis det ikke var i kravene. Det ville også være en feil.

I tillegg fikk utviklerne ikke fikse feil uten formell autorisasjon. Vi fikk ikke endre noen linje i kilden som ikke var direkte relatert til endringsautorisasjonen vi jobbet under. Vi fikk ikke endre innrykk for å gjøre koden mer lesbar, med mindre endringene i nærheten var betydelige nok. Disse begrensningene skulle forhindre utilsiktede endringer, noe som ville føre til utilsiktet introduksjon av feil. Hver linje som ble endret ble merket til en bestemt person og CR / DR-autorisasjon.

Spesielt med veiledningsberegninger, kunne ikke kravene noen ganger implementeres på grunn av datamaskinens begrensninger. I sanntidskoding er et sent svar like ille som et feil svar. Minst én gang måtte kravene endres for å matche koden.

Ingen vet det virkelige antall feil i hvilken som helst programvare når som helst, men Jim Orr skrev bokstavelig talt boka om Space Shuttle-programvareproblemer og feil . Han fikk alle dataene om kravgjennomganger, designanmeldelser, testplangjennomganger, kodegjennomgang og testresultater da jeg jobbet der for GN&C FSW

Det var definitivt hundrevis av bugs i FSW, veldig få var betraktet SEV-1. Ingen vil føre til at datamaskinen låser seg opp eller andre typiske feil som folk tåler i livet i dag. GN&C-koden hadde ikke problemer som vanlig desktop- eller serverkode gjør. Det var ingen dynamisk minnetildeling. Bruk av pekere krevde en skriftlig, godkjent avvik fra SW-standardkortet. All koden ble formelt fagfellevurdert av minst 6 personer. Mer komplisert kode vil bli gjennomgått av mer enn 20 personer - i samme rom. I løpet av flere tiår forbedret prosessen som ble brukt til å lage programvaren. Prosessen ble satt opp på en slik måte at den ikke stolte på superprogrammerere for å lage relativt feilfri programvare. Det handlet egentlig om prosessen.

I løpet av mine tiår med å skrive programvare hos mange forskjellige selskaper, har jeg sett at overalt ellers er avhengig / håp om superprogrammerer -ideen for å gi bedre resultater. Problemet med dette er at superprogrammerer ikke er lett reproduserbar. Jeg har sett det fungere ett sted, og bare fordi hver programmerer betraktet enhver feil som en personlig feil. Overalt ellers sitter fast med gode, gjennomsnittlige og dårlige programmerere. Spesielt i større organisasjoner ser skalaen ut til å skifte mot dårlig mer enn andre steder. Det er alltid unntak, og selv om jeg har jobbet direkte med 3000 programmerere profesjonelt, er det ikke alle programmerere overalt.

Håper dette avklares og er nyttig.