Das ist das Slidedeck aus dem Meetup der Softwerkskammer Chemnitz vom 12.01.2021 zum Thema "Was Software-Entwickler von der Raumfahrt lernen können". Die Slides setzen sich mit Software-, Prozess- und Bedienfehlern in der Raumfahrt auseinander und zeigen Berührungspunkte zur Software-Entwicklung auf.
Was Software-Entwickler von der Raumfahrt lernen können
1. Was Software-Entwickler von der Raumfahrt lernen können
Softwerkskammer Chemnitz, 12.01.2021
Photo by Bill Jelen on Unsplash
2. Wieso jetzt Raumfahrt?
• 1979 (7 Jahre) Sigmund Jähn auf der Straße
zugejubelt (der war 1978 im All)
• 1986 (14 Jahre) im Winter, später Nachmittag
live im Fernsehen die Explosion der Challenger
verfolgt
…
• Heute
• 8-Jähriger Sohn mit regem Interesse an Weltall /
Raumfahrt
• gern einmal pro in die Raumfahrt-Ausstellung
nach Morgenröthe-Rautenkranz (26 km Dist.)
• gemeinsame Beschäftigung
• Und dann entdeckt/liest man Dinge, die für
Software-Entwickler relevant sind … Photo by ASHLEY EDWARDS on Unsplash
3. Quelle: meistens NASA
• Seit dem Mercury Programm1 untersucht und dokumentiert die NASA
genau, was bei Weltraum-Missionen und deren Vorbereitung schief
gegangen ist
1 erstes „bemanntes“ Raumfahrtprogramm der USA (1958 – 1963)
4. Sechs Beispiele für Fehler bei Raumfahrt
Missionen
• Wir schauen im weitesten Kontext auf Software- oder
Softwarebedienfehler der „unbemannten“ Raumfahrt
• Disclaimer: Wer Geduld/Interesse hat kann gaaaanz am Ende noch drei
schöne Beispiele für Fehler anschauen
5. SOHO (SOlar Heliospheric Observatory, seit 1995)
am 02.12.1995 mit Atlas-II Rakete
Mission: Erforschung der Sonne (NASA + ESA)
1,5 Millionen km in Richtung Sonne geflogen
05/1996 Funktion aufgenommen
Kontakt zu SOHO am 25.06. 1998 verloren
Prozesse/Systeme der Bodenkontrolle wurden zur Kosteneinsparung und
Verringerung von Ausfallzeiten umstrukturiert und modernisiert
Einige der Modernisierungen wurden ohne explizite Anforderungen
vorgenommen
Zusammen mit Fehlern bei
• der Einstellung der drei SOHO Gyroskope
• einer Kurskorrektur
• Wiederherstellung nach Notfall aus abgesichertem Modus
Nach vier Monaten (patching) war SOHO wieder einsatzbereit
SOHO arbeitet heute noch und wird das potentiell noch fünf weitere Jahre tun
https://soho.nascom.nasa.gov/hotshots/2020_12_02/
Gemeinfrei, https://commons.wikimedia.org/wiki/
File:Soho_photo3_lg.jpg
Quelle: https://sohowww.nascom.nasa.gov/hotshots/
2020_12_02/
6. Ariane 5 Flight 501 (1996)
Neue Rakete, stärkerer Antrieb ggü. Ariane 4
• … aber Ariane 4 Software eingesetzt
• Viel stärkere Beschleunigung
Beschleunigung als 16-bit-signed-int abgebildet
• Nach 32768 kommt -32767 ! Überlauf ! führt in
Ada zur Beendigung der Laufzeitumgebung
• Trägheitsnavigationssystem abgestürzt
• Steuerraketen verharrten in letzter Position
37 s nach dem Start Selbstzerstörung ausgelöst
4 Cluster-Satelliten zerstört, 370 Mio $ Schaden
Das „Programm“ war für die Steuerung der Ariane 501 gar nicht
nötig, wurde aber im System belassen, um nicht zu viele SW-
Änderungen vorzunehmen
https://esamultimedia.esa.int/docs/esa-x-1819eng.pdf
A model of an European rocket Ariane 5 in the Museum of Air and Space(Musée de
l'air et de l'espace, Le Bourget, France) under Creative Commons Attribution-Share Alike
3.0 Unported license by Ignis
Quelle: https://www.youtube.com/watch?
v=gp_D8r-2hwk
7. Delta-3 / Galaxy 10 (1998)
Wie Vorgänger Delta-2 Rakete, aber steuerbare Feststoff-
Booster, mit 50 % mehr Schub
Steuersoftware aus Delta-2 übernommen
75 s nach Start gerät Delta-2 in Schräglage und zerstört
sich selbst
Eigenschwingung durch Korrekturbewegung der
Feststoff-Booster verstärkt
https://www.golem.de/news/softwarefehler-in-der-
raumfahrt-in-den-neunzigern-stuerzte-alles-
ab-1511-117537-2.html
Gemeinfrei, https://commons.wikimedia.org/wiki/
File:Delta_II_Dawn_liftoff_1.jpg
Quelle:
https://space.skyrocket.de/doc_sdat/galaxy-10.htm
8. Titan IV B-32/Centaur TC-14/Milstar-3 (1999)
Milstar (Military Strategic and Tactical Relay), Serie von
Kommunikationssatelliten der US Air Force
Falsch eingetragene Konstante für Eigendrehungsfilter in
Trägheitsnavigationssystem sorgt dafür dass die Messdaten
für die Eigendrehung auf 0 gesetzt wurden
• Achsenkontrolle für Steigungs- und Seitensteuerung
nicht mehr nutzbar
• hoher Treibstoffverbrauch beim RCS (Reaction
Control System, Lageregelungstriebwerke außerhalb
Atmosphäre)
• nicht genug Treibstoff um die Zielhöhe für das
Aussetzen des Satelliten zu erreichen
• Ursache: Software-Entwicklung, Test und QS-Prozess für
obere Raketenstufe nicht angemessen
• Kosten nur für Satellit: 800 Mio $
Gemeinfrei, https://de.wikipedia.org/wiki/Milstar#/media/
Datei:Milstar.jpg
Gemeinfrei, https://commons.wikimedia.org/wiki/
File:Titan4B_on_Launch_Complex_40.jpg
9. Mars Global Surveyor (2006)
Ersatz für gescheiterte Mars Observer Mission (1993)
1996 in Richtung mit Delta-II-Rakete Mars gestartet
1997 Mars erreicht, Ziel-Umlaufbahn wg. Fehler in Solarmodulen ein Jahr
später erreicht
ab 1999 240.000 hochauflösende Fotos der Oberfläche für Vermessung/
Kartierung des Mars
2006 ging Kontakt zu MGS unwiederbringlich verloren
fünf Monate vorher hatte Bodenpersonal fehlerhafte Kommandos zur
Ausrichtung von Antennenverstärker übermittelt, die führten zu
1. Out of Memory
2. falscher Sondenausrichtung
3. Überhitzung der Akkus (Sonneneinstrahlung)
4. Ladeabschaltung
5. vollständiger Entladung
https://llis.nasa.gov/lesson/1805
Gemeinfrei, https://commons.wikimedia.org/wiki/
File:Mars_Global_Surveyor_before_launch.jpg
Gemeinfrei, https://commons.wikimedia.org/wiki/
File:Mars_Global_Surveyor_2.jpg
10. Mars Science Laboratory (2012)
26.11. 2011 mit Atlas 5 (Centaur Oberstufe) gestartet
Rover soll Eignung der Mars-Oberfläche als Biosphäre untersuchen
1.12. 2011: geplantes Bahnmanöver später durchführen
Grund: Fehler im Sternen-Navi (Sternensensor) Software
9. Februar 2012: Sternen-Navi repariert
Ursache:
1. Software-Fehler beim Speichermanagement
2. Führt zu Fehler beim Zugriff auf den Befehlscache des Prozessors
3. einige Kommandos gehen verloren
4. Sonde wird in sicheren Modus versetzt
überarbeitete Software im Wartungsmodus aufgespielt -> Fehler dauerhaft
behoben
Am 08.08.2012 gelandet
Kommt später nochmal …
Gemeinfrei, https://commons.wikimedia.org/w/index.php?
curid=147418
Gemeinfrei, https://commons.wikimedia.org/w/index.php?
curid=22538554
11. Sechs Dinge die Softwerker von der
Raumfahrt lernen können
• im weitesten Kontext Software- oder Softwarebedienfehler schauen
wir auf auf die „unbemannte“ Raumfahrt
12. Am wievielten Tag ihrer Mission gingen 81
Satelliten verloren?
http://flightsoftware.jhuapl.edu/files/2013/talks/FSW-13-
TALKS/TLYF_Apply2FSW_Dec2013r1.pdf
13. Test Like You Fly, Fly Like You Test!
• Raketen-Antrieb ist das kritischste Element jeder Rakete
• wird (jetzt) am intensivsten getestet/simuliert … so nahe wie möglich an
Realität
• Lessons Learned
• Software-Fehler
• Software-Hardware Kommunikationsfehler
• Software-Software Kommunikationsfehler
• Bedien- oder Prozessfehler
• TLYF-Prozess
• z.B. Zusammenspiel von Hardware und Software oberhalb der beim Flug
erwarteten Betriebstemparatur testen
https://www.gantner-instruments.com/blog/test-like-you-fly-fly-like-you-test/
https://www.nasa.gov/exploration/systems/sls/what-qualification-means-for-sls-rocket.html
http://flightsoftware.jhuapl.edu/files/2013/talks/FSW-13-TALKS/TLYF_Apply2FSW_Dec2013r1.pdf
Photo by Bill Jelen on Unsplash
14. Test Like You Fly, Fly Like You Test!
Was können wir lernen?
• Wir haben in unseren Projekten/Produkten häufig den Vorteil, dass
beim einem Fehler wenig passiert ! nicht so kritisch
• Das verleitet uns zu …
• Unter sehr echtzeitnahen Bedingungen zu testen tut jedem Team,
Projekt, Produkt gut
• Unterschied: Tabelle 1000 Datensätze oder 1 Mrd. Datensätze
• Teste ich Happy Path oder die Ausnahmefälle, die potentiell weh tun können?
Photo by Bill Jelen on Unsplash
15. Die Kunst des negativen Denkens
• Deine nächste Entscheidung kann dich umbringen!
• Von wo droht als nächstes (Lebens-)Gefahr?
• Astronauten werden dazu ausgebildet jedes Gerät im Raumschiff / auf der Station
grundsätzlich bedienen und reparieren zu können
• Einen großen Teil der Ausbildung nehmen Notfall-Simulationen ein, in denen Astronauten
darauf trainiert werden in Sekunden-Bruchteilen die „richtige“ Entscheidung treffen zu
können
• Nachbereitung von Raumflügen für Astronauten bei NASA ca. vier bis sechs Monate
• Reflektion
• Verhalten
• Verbesserungspotentiale
• Fehler
16. Die Kunst des negativen Denkens
Was können wir lernen?
• Paranoia hilft!
• Was kann bei unseren Produkten/Umgebungen schief
gehen?
• „normale“ Software Entwicklung
• DevOps
• Resilience Engineering
• Chaos Engineering
17. Power of Ten – Rules for Developing Safety-
Critical Code (2006)
1. Restrict all code to very simple control flow constructs - do
not use goto statements, setjmp or longjmp constructs, or
direct or indirect recursion
2. Give all loops a fixed upper bound
3. Do not use dynamic memory allocation after initialization
4. No function should be longer than what can be printed on a
single sheet of paper in a standard format with one line per
statement and one line per declaration
5. The code’s assertion density should average to minimally two
assertions per function
6. Declare all data objects at the smallest possible level of scope.
Each calling function must check the return value of nonvoid
functions, and each called function must check the validity of
all parameters provided by the caller
7. Each calling function must check the return value of nonvoid
functions, and each called function must check the validity of
all parameters provided by the caller
8. The use of the preprocessor must be limited to the inclusion
of header files and simple macro definitions
9. The use of pointers must be restricted. Specifically, no more
than one level of dereferencing should be used
10. All code must be compiled, from the first day of development,
with all compiler warnings enabled at the most pedantic
setting
http://spinroot.com/gerard/pdf/Power_of_Ten.pdf
https://www.geeksforgeeks.org/g-fact22-concept-of-setjump-and-longjump/
To put an upper bound on the number of rules, I will argue that
restricting the set to no more than 10 rules will provide an effective
guideline (Gerard Holzmann, Jet Propulsion Laboratory for Reliable
Software)
18. Power of Ten – Rules for Developing Safety-
Critical Code (2006)
Was können wir lernen?
• Einfachheit betrifft nicht nur Code, Architektur oder Design, sondern auch
Prozesse, Regeln und Kommunikation
• Grenzen von Einfachheit
• immer kontextabhängig
• persönlicher Rekord: Kodierrichtlinien mit 155 Elementen
19. Public Lessons Learned System - https://
llis.nasa.gov
Mars Global Surveyor: https://llis.nasa.gov/lesson/1805
20. Public Lessons Learned System - https://
llis.nasa.gov
Mars Global Surveyor: https://llis.nasa.gov/lesson/1805
21. Public Lessons Learned System - https://
llis.nasa.gov
Was können wir lernen?
• Eine „blaming-freie“ Fehlerkultur die auf Verbesserung bzw.
Vermeidung von Fehlerwiederholungen ausgelegt ist, schadet keine
Organisation
• Feedback-Schleife nach “bemannter“ Weltraum-Mission dauert
mehrere Monate
• Bei jedem Fehler, jedem „Vorfall“ hinterfragen, was wir daraus lernen
können
• Daran kann jede Organisation nur wachsen
22. Bemühe dich, eine Null zu sein!
Man befindet sich in jeder
Situation in einer der drei
folgenden Kategorien
-1
• aktiv schädlich
• schafft Probleme
0
• Auswirkungen neutral
• keinen Ausschlag in die
eine oder die andere
Richtung
+1
• aktiv ein Gewinn
• jeder möchte +1 eins sein
• das eigene +1-Sein von
Anfang an zu verkünden
stellt sicher, als -1
wahrgenommen zu werden
• ohne Kenntnis des Kontext
kann niemand eine +1 sein
• 0 sein ist erreichbares Ziel,
Voraussetzung dafür +1 zu
werden
23. Bemühe dich, eine Null zu sein!
Was können wir lernen?
• Ego ist nicht alles
• Lernsituation in der IT
• Gehört mit der Raum oder lasse ich den Kollegen lieber
Spielraum für deren eigene Entwicklung?
• Ist es eine gute Idee dafür zu sorgen, dass sie in Ruhe
arbeiten können? ! Scrum Master
24. NASA scrubbed Mars Rover code clean —
over and over
• Entwicklung des Mars Science Laboratory (Curiosity) kostete 2,5 Mrd. $
• Software für Mars Rover Curiosity besteht aus ca. 2 Millionen LoC
• Embedded
• Strategie: Belt and Braces
• NASA hat den Code (die letzten) 2 Jahre lang durch statische Code-Analyse
prüfen lassen
• Tools von Coverity, Grammatech, Semmle, Uno, gcc Compiler + Eigenentwicklung
• z.B. Array Overflow (C)
If you put software through three code reviews you’ll find stuff, and then
if you put it through a fourth review, you’ll find something else. All these
products all have their own strengths (Gerard Holzmann, Jet Propulsion
Laboratory for Reliable Software)
Photo by Christine Sandu on Unsplash
https://gigaom.com/2012/08/20/nasa-scrubbed-mars-rover-code-clean-over-and-over/
25. NASA scrubbed Mars Rover code clean —
over and over
Was können wir lernen?
• Es gibt nicht die eine Wahrheit
• „Wir nutzen Tool X, weil …“
• „Aber wir nutzen Tool Y, weil …“
• Perspektive ist wichtig
Photo by Christine Sandu on Unsplash
27. Mars Climate Orbiter (1999)
Star Wars/Star Trek
Gemeinfrei,
https://commons.wikimedia.org/wiki/File:Mars_Climate_Orbiter_-_artist_depiction_-_climate-orbiter-browse.jpg
11.12. 1998 mit Delta II Rakete gestartet
Mission: Marsoberfläche, Wetter, Atmosphäre untersuchen,
Kommunikationsrelay für Mars Polar Lander
Am 23.09. 1999 in zu niedriger Höhe in Mars-Umlaufbahn eingeschwenkt …
von Atmosphäre abgeprallt … auseinander gefallen
Ursache:
• Umrechnungsfehler bei der Steuerung von der Erde aus
• Impuls (mechanischer Bewegungszustand eines Objekts)
• internationaler Standard/NASA: Newton Seconds
• Hersteller Navigations Software: Pounds per Second (imperialer
Standard)
• Problem während des Fluges zum Mars aufgefallen
• Statt einen Problem/Failure Report (PFR) wurde eMail geschrieben
• Untersuchung wegen zu geringer Priorität beendet, weil sich das
“Fehlverhalten“ durch entsprechende Steuerkorrekturen beseitigen
lies.
Mars Polar Lander war zur Absturzzeit unterwegs ! Untersuchung
eingeleitet, ob MPL das selbe Problem haben könnte
https://solarsystem.nasa.gov/missions/mars-climate-orbiter/in-depth/
Gemeinfrei, https://commons.wikimedia.org/wiki/File:Delta_II_7925_(2925)_rocket_with_Deep_Impact.jpg
28. Mars Polar Lander (1999)
Am 03.01.1999 mit Delta II Rakete gestartet
Mission: Mars-Oberfläche in der Nähe des Südpols untersuchen
(Mars-Eis)
03.12.1999 Landung auf dem Mars geplant
In Atmosphäre eingetreten, kurz vor der Landung Kontakt verloren
Wahrscheinliche Ursache:
1. Beine für Landung ausgefahren
2. Hat zu Erschütterung geführt
3. Erschütterung wurde als Bodenkontakt interpretiert
4. Bremsraketen wurden abgeschalten
5. aus 40 Metern Höhe abgestürzt
Absturzstelle wurde nicht gefunden
https://solarsystem.nasa.gov/missions/mars-polar-lander-deep-
space-2/in-depth/
gemeinfrei, https://commons.wikimedia.org/wiki/File:Mars_Polar_Lander_prelaunch.jpg
Gemeinfrei, https://commons.wikimedia.org/wiki/File:Delta_II_7925_(2925)_rocket_with_Deep_Impact.jpg
29. Mars Polar Lander (1999)
gemeinfrei, https://de.wikipedia.org/wiki/Mars_Polar_Lander#/media/Datei:Mars-polar-lander_back.jpg
Es war bekannt, dass
• das Ausfahren der Beine, Vibrationen
erzeugt
• Touchdown-Sensoren in diesem Moment
falsche Signale erzeugten
Das Wissen hat keinen ausreichenden
Einfluss in Anforderungen/Tests gefunden,
siehe https://llis.nasa.gov/lesson/938
Ein Lessons Learned aus dem Verlust von
MPL war die Etablierung des Prinzips „ Test
as You Fly, Fly as You Test“, Siehe https://
llis.nasa.gov/lesson/1196
30. Schiaparelli (2016, ESA/Roskosmos)
Gemeinfrei,
https://de.wikipedia.org/wiki/Schiaparelli_(Marslander)#/media/
Datei:PIA21131_Closer_Look_at_Schiaparelli_Impact_Site_on_Mars.jpg
14.03.2014 mit PROTON Rakete gestartet
Mission: Erprobung von Technologien für Mars-
Landungen
19.10.2016 bei der Landung abgestürzt
• Nach Öffnung des Bremsfallschirms starke
Turbulenzen ! stark geschwankt ! über 90°
• Trägheitsnavigationssystem hatte Fehlfunktion !
Höhe -3.700 statt +3.700 Meter
• Schiaparelli war also schon „gelandet“
• Fallschirm + Hitzeschilde abgeworfen
• Bremsraketen abgeschalten
aus 3,7 km Höhe mit ca. 540 km/h auf Oberfläche
aufgeschlagen
https://de.wikipedia.org/wiki/Schiaparelli_(Marslander)
Gemeinfrei, https://commons.wikimedia.org/wiki/File:Proton-K-Zarya.jpg
31. Hunger nach mehr?
• Carina Haupt (DLR): Softwarefehler in der Raumfahrt - missglückte
Raketenstarts und Bruchlandungen https://www.youtube.com/watch?
v=6oXtGMBS2ho&feature=emb_logo
• Chris Hadfield: Anleitung zur Schwerelosigkeit- Was wir im All fürs
Leben lernen können https://www.thalia.de/shop/home/
artikeldetails/ID38776364.html