SlideShare ist ein Scribd-Unternehmen logo
1 von 31
Downloaden Sie, um offline zu lesen
Was Software-Entwickler von der Raumfahrt lernen können
Softwerkskammer Chemnitz, 12.01.2021
Photo by Bill Jelen on Unsplash
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
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)
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
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/
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
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
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
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
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
Sechs Dinge die Softwerker von der
Raumfahrt lernen können
• im weitesten Kontext Software- oder Softwarebedienfehler schauen
wir auf auf die „unbemannte“ Raumfahrt
Am wievielten Tag ihrer Mission gingen 81
Satelliten verloren?
http://flightsoftware.jhuapl.edu/files/2013/talks/FSW-13-
TALKS/TLYF_Apply2FSW_Dec2013r1.pdf
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
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
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
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
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)
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
Public Lessons Learned System - https://
llis.nasa.gov
Mars Global Surveyor: https://llis.nasa.gov/lesson/1805
Public Lessons Learned System - https://
llis.nasa.gov
Mars Global Surveyor: https://llis.nasa.gov/lesson/1805
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
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
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
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/
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
The left-overs
• Mars Climate Orbiter
• Mars Polar Lander
• Schiaparelli
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
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
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
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
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

Weitere ähnliche Inhalte

Mehr von Ramon Anger

Mehr von Ramon Anger (12)

Chaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps TeamsChaos Kata Fitnesstraining für DevOps Teams
Chaos Kata Fitnesstraining für DevOps Teams
 
How to kill (software) architecture?
How to kill (software) architecture?How to kill (software) architecture?
How to kill (software) architecture?
 
DWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture appliedDWX Developer Week 2015 - Microservice architecture applied
DWX Developer Week 2015 - Microservice architecture applied
 
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
Microservice architecture applied. 14 Praxis-Tipps für die Nutzung von Micros...
 
Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen
Geschnitten oder am Stück - Von der Produktvision zu guten AnforderungenGeschnitten oder am Stück - Von der Produktvision zu guten Anforderungen
Geschnitten oder am Stück - Von der Produktvision zu guten Anforderungen
 
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_istWhere are all transactions gone? Was in_der_cloud_alles_verboten_ist
Where are all transactions gone? Was in_der_cloud_alles_verboten_ist
 
Das Agile muss ins Klassische
Das Agile muss ins KlassischeDas Agile muss ins Klassische
Das Agile muss ins Klassische
 
Under pressure - Sozialer und Termindruck in agilen Teams
Under pressure - Sozialer und Termindruck in agilen TeamsUnder pressure - Sozialer und Termindruck in agilen Teams
Under pressure - Sozialer und Termindruck in agilen Teams
 
Vom Hybriden zu Scrum und zurück
Vom Hybriden zu Scrum und zurückVom Hybriden zu Scrum und zurück
Vom Hybriden zu Scrum und zurück
 
EAM im Spannungsfeld agiler Methoden oder Agiles EAM
EAM im Spannungsfeld agiler Methoden oder Agiles EAMEAM im Spannungsfeld agiler Methoden oder Agiles EAM
EAM im Spannungsfeld agiler Methoden oder Agiles EAM
 
Wer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
Wer braucht das schon - Unternehmensarchitektur im agilen ZeitalterWer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
Wer braucht das schon - Unternehmensarchitektur im agilen Zeitalter
 
Coderetreat Vorlage
Coderetreat VorlageCoderetreat Vorlage
Coderetreat Vorlage
 

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
  • 26. The left-overs • Mars Climate Orbiter • Mars Polar Lander • Schiaparelli
  • 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