 Hallo, herzlich willkommen zusammen. Ich habe ja doch einige von der Vise und dem Chunk weggeloggt. Das freut mich ganz besonders, dass ihr da seid. Ich erzähle heute ein bisschen was über disintegrating Rockets. Genauer Softwarefehler in der Raumfahrt und wie wir versuchen sie zu vermeiden. Ich habe irgendwie bei dem Einreich nicht so genau auf die Zeit geachtet, aber es dauerte eine halbe Stunde, dann ist mir ein Gefallen irgendwie oh, Q&A. Das heißt, der letzte Teil ist relativ knapp geworden, wie wir versuchen es zu vermeiden, aber ihr wollt doch nur wissen, warum Raketen explodieren. Warum stehe ich eigentlich hier und erzähle den Kram? Was qualifiziert mich dazu? Also erst mal gar nicht so viel. Ich arbeite fürs Deutsche Zentrum für Luft und Raumfahrt, mache der Softwareentwicklung und beschäftige mich vor allem mit Softwareengineering. Und das ist halt, wie ich auch auf diese Probleme drauf gucke. Also, wo genau ist denn was schief gegangen und warum und wie hätte man das vor allem vermeiden können? Ja, und dann kommen wir zu dem, wofür ihr da seid, nämlich die Geschichte der Space Fails. Was ist da so ein bisschen schlossgegangen und da kommen wir auch direkt zum Allerallerersten. Und allererste ist wirklich, das ist noch ein bisschen in den früheren Zeiten der Raumfahrt, 1962, die Marina 1. Das war, wie die 1 vermuten lässt, die erste Marina Sonde. Und das Ziel war schon ganz ambitioniert. Wir wollten nämlich an der Venus vorbeifliegen und mal so einen Blick drauf werfen. Spoiler Alert hat nicht geklappt. Das Problem, was aufgetreten ist, ist ja so einfach, wie es heute immer noch passieren kann und alt ist. Und zwar, man hat halt irgendwie spezifiziert, wie das Ganze denn so funktioniert. Da gab es eine schöne Formel. Ah, guck mal. Und bei der manuellen Abschrift in den Code wurde eine sogenannte Überstrich vergessen. Wer weiß, was ein Überstrich ist oder im englischen Overbar? 2, 3 melden sich. Ich wette, ihr wisst es alle. Wenn ihr nämlich 2,33333, da gab es diesen Periodenstrich. Das ist der Überstrich. Musste ich auch erst mal lernen. Naja, also der wurde vergessen. Dementsprech gab es eine inkorrekte Formel im Steuerungsprogramm. Wäre jetzt nicht ganz so schlimm gewesen, weil eigentlich sollte die Steuerung von Ground Control ausgehen. Da war aber auch ein Back, das hat auch nicht funktioniert. Also hat der Autopilot übernommen. Und ja, das tat halt nicht. Der hat beschlossen, wir fliegen jetzt in eine Angerichtung. Also es gab eine relativ starke Kursabweichung. Und dann musste man sich so ein bisschen entscheiden, was man tut. Weil Kursabweichung, der Autopilot war, Kommando von unten ging nicht mehr. Wir hatten also keine Kontrolle. Man konnte nicht mehr sagen, mach mal was anderes. Und dann wurde die Selbstzerstörung aktiviert. Also richtig, da gibt es diesen Kill Switch nach 294,5 Sekunden. Wer rechnen kann, es sind fast 5 Minuten. Warum fast? Nach 5 Minuten hätte sich die obere Stage getrennt. Und eine Selbstzerstörung wäre nicht mehr möglich gewesen. Und was man ganz schnell ausgerechnet hat, wäre der Crash von dem oberen Teil oder so. Das wäre halt entweder zwar in einem größtenteils unbewohntem Gebiet passiert oder in einer nordatlantischen Schiffsverbindung. Ja, man hat sich dann halt beschlossen, das Ganze hoch zu jagen. Und ja, gekostet hat das den Steuerzahler 18,5 Millionen Dollar. Und man fragt sich, warum zur Hölle gab es denn dafür keinen Test? Heutzutage würde man ja einfach so eine Funktion mal durchrechnen lassen und einen Test schreiben. Naja, ich verweise auf das Jahr 1962. Das war bevor der Begriff Software-Engineering überhaupt geprägt wurde. Das passierte irgendwie 68 auf einer Naturtagung in Garmisch-Partenkirchen, falls wer interessiert. Das heißt bis dato war so der Entwicklungsprozess, das war ein Code in Fix. Das heißt, ich schreibe meinen Code, pack ihn in Production und wenn was kaputt geht fix ich ihn. Gut, die Software-Entwicklung hat Fortschritte gemacht. Wir sind im Jahr 1988 mit FOBUS 1. FOBUS 1 hatte wieder ein weites Ziel. Diesmal geht es nicht um die Rakete. Also der Start hat schon mal funktioniert, das sage ich schon mal. Und die Sonde war dann munter unterwegs. Hier gibt es eine künstlerische Darstellung, weil Fotos, ja, also da waren noch nicht so viele unterwegs, aber das Ziel war, Mars sowie die Monde von Mars, FOBUS und Daimus zu erforschen. Man war schon ein bisschen schlauer. Man hat gesagt, okay, wir haben so Kommandos, die die Techniker hoch schicken. Und er hat aber so ein Techniker ein Bindestrich vergessen. Also mal wieder, ah, Übertragungsfehler kennen wir schon. Also jemand hat nicht aufgepasst. Aber man war schlauer, man hatte ein System, ein Computer, der checken sollte, ob die Kommandos richtig sind. Der war jetzt aber kaputt. Was macht der Techniker? Experte, YOLO, dies passt schon. Leider nicht. Dadurch wurde automatisch das End-of-Mission-Kommando ausgeführt, was eigentlich weiter hinten kam. End-of-Mission heißt, alle Systemen fahren runter, keine Kommunikation oder Kontrolle mehr möglich. Das war zwei Monate in die Mission. Ups. Es ist halt, also so als Software-Engineer ist das auch so ganz typisch. Ey, ich hab Tests gebaut, da ist eine Sicherheitsding, aber keiner benutzt es. Kennen wir heute auch noch, machen die Leute heute immer noch gerne. Wieder ein kleiner Sprung, 1996, eine der etwas bekannteren Missionen, die schief gegangen ist, Ariane 5, sollte Satelliten in die Magnetusferde der Erde bringen, also gar nicht so ein großweites Ziel, nur da hoch. Es war der Jungfernflug, der Ariane 5. Und der Fehler ist besonders schön. Es ist ein Overflow. Klingt, ich hör da vorne schon jemand, der weiß es, genau. Also es war irgendwie eine 64-Bit Floating Point und die wurde gecastet zu 60-Bit Signed Integer. Da kommt man schon so, hey, wie kann sich so was einschleichen? Na ja, man war eigentlich ganz clever, man dachte sich, hey, bei der Ariane 4 hat dieses Modul, das war ein, ich muss mal nachlesen, Initial Reference Platform, also so eine Navigationshilfe, hat super funktioniert, wir sparen Geld, wir benutzen die wieder. Also eingebaut, losgeflogen, hat nicht so geklappt. Das Problem, was passiert ist, ist wirklich eine schöne Kette. Also diese Navigationshilfe hat halt, also die Ariane 5 ist halt eine neuere Rakete als die Ariane 4 und damit auch schneller. Neuer ist ja immer schneller. Dadurch ist diese Beschleunigungszahl, also da, wo da gerechnet wird, größer geworden. Deswegen hat die plötzlich den 16-Bit Raum verloren, also verlassen und deswegen kam es zum Overflow. Das ist, wie gesagt, in der Ariane 4 nicht aufgetreten, sondern aufgefallen, sagen wir es eigentlich. Also weil die Rakete schneller war, hatten wir den Overflow. Der Computer hat, naja, ist halt ausgestiegen, aber da waren ja gute Entwickler drin, die haben gesagt, hey, wenn was schief geht, dann geben wir Diagnostik-Daten aus, damit wir nachvollziehen können, was zur Hölle ist da eigentlich schiefgegangen. Ja, das müssen aber auch die anderen Systeme wissen, dass das Daten für die Diagnose ist. Der Autopilot wusste das nicht. Der hat den einen Teil für die Position, den anderen als die Beschleunigung gesehen, hat den Kurs entsprechend angepasst. Da kam es dann zu einer ziemlich drastischen Winkeländerung und ich sag mal, das hat nicht funktioniert. Also wenn man so fliegt und dann beschließt, hey, rüber, das hält dann auch so eine Rakete nicht aus. Und hier kommt mein Lieblingswort, der Launcher, desintegrierte nach 39 Sekunden. Dazu muss man sagen, also das ist so auch so ESA-Sprech und allgemeine der Raumfahrt, ja, so eine Rakete explodiert nicht oder crashed, die desintegriert. Das Ganze hat gekostet 370 Millionen und ist bis heute einer der teuersten Software-Bugs der Welt. Also kann sie Epsilon kommen, nicht mehr teilen. Und man hätte das Ganze vermeiden können, indem man den Integrations-Test gemacht hätte, also einfach mal die Systeme zusammenstecken. Also alles bisher waren immer so Vermutungen, natürlich, ja klar, ein Test hat geholfen oder so, hier ist es. Die haben das mal nachgebaut, so, ja, wir machen jetzt mein Integrations-Test und zu gucken, ist es wirklich daran gelegen? Ja, es ist genauso schief gegangen, hätte man vorher wissen können. So, kommen wir zurück zu Mars und 1998. Der Mars-Climate Orbiter sollte zu Mars fliegen, drumrum, bisschen den Mars erforschen und auch noch als Kommunikations-Relay-Dean für spätere Missionen. Ja, also man sollte sich schon einigen, in welchen Einheiten man arbeitet. Die einen haben Pound Force genommen, die anderen Newton. Das Ganze ist dann schief gegangen. Also wir hatten auf dem Ground Control Software A, die hat halt schön gerechnet, das Ganze in Pound Force ran gegeben an Software Tai B. Teil A war von Lockheed Martin entwickelt, Teil B von der NASA. Die NASA hat halt, wie es in der Spezifikation erwartet, dass da jetzt Newton kommen, war halt nicht so. Und dann kam es halt zu einer kleinen Abweichung und geplant war halt auf 226 Kilometer Höhe anzukommen, jetzt waren es nur 57, bis 180, da gibt es so verschiedene, wäre es noch gut gegangen, aber so disintegrierte das Ganze mal wieder in der oberen Atmosphäre und hat 327,6 Millionen Dollar gekostet. Man musste zu sagen, die Schuld wurde nicht an Lockheed Martin gesetzt, weil die haben zwar die Spezifikation nicht aufgepasst, aber NASA hat gesagt, wir haben auch nicht getestet. Also, also das ist ein Doppel-Fay. Zu dieser Zahl, die ist jetzt natürlich sehr groß, möchte ich sagen, das sind nicht nur die Kosten für diesen Orbiter, sondern auch nur noch für den Polar Lender, der mit in diese Mission gehört und den ganzen Betrieb. Aber es ist jetzt nicht so, als wäre der Polar Lender gelandet. Also, den haben Sie halt kurz hinterhergeschickt, also, 98, 99, die Schritte wären kleiner. Und der sollte halt auf Maße landen und ein bisschen wie die Steine und das Klima erforschen, also so ein bisschen rumgucken. Auch hier wieder mal eine künstlerische Darstellung. Der Fehler hier war ein bisschen einfacher. Der ist nämlich im Land gewesen. Und dann hat es halt, weil, ja, das ist halt so Atmosphäre. Also, da gab es ein bisschen Turbulenzen, es hat vibriert. Und dann dachte die Software, oh, das ist das Signal, wir sind da. Alle Stopp. Triebwerke abgeschaltet und aus 40 Metern Höhen aufgeschlagen. Damals hat man diese Landung immer versucht, sehr filigran zu machen und sehr kratziös, also hat er nicht überlebt. Und so kommen wir zu den 327,6 Millionen. Aber Maas ist wirklich schwierig. Wir kommen so ein bisschen in die jüngere Zeit, der eine oder andere kennt, die Sonne, die keiner gut aussprechen kann, Scherparelli, sollte auf Maas landen, sollte da auch ein bisschen forschen. Nummer drei von denen, die es nicht geschafft haben, es gab nämlich einen unerwarteten negativen Wert. Und das ist eine meiner Lieblingsgeschichten, weil egal, was wir mit dem Software-Engineering, mit Tests und Co. machen, es passieren immer unvorgesehene Dinge. Hier ist es folgendes passiert. Diese wunderschöne Box, die wir da gesehen haben, dieses flache Ding, ist runtergekommen. Paratute, also hier der Fallschirm auf, alles super. Pendelt darunter, ja, das ist so ein bisschen wackelt. Turbulenzen kennen wir ja jetzt schon, das Problem hatten wir schon mal, dass das was wackelt. Ja, und dann hat sich das aufgeschockt und ist über 90 Grad gegangen. Ja, ja, genau, da kommt der negative Wert her. Für wirklich nur tausends eine Millisekunde, also ganz, ganz kurz war der der Meinung, 36 Kilometer über die Erde, nee, nee, unter. Fuck, wir sind schon längst gelandet. Fallschirm weg, Rückschale weg, Bremstriebwerke aus nach 3 Sekunden statt 30. Oh, 3,7, ich glaube, das stimmt nicht, egal. Also auf jeden Fall aus diversen Kilometern Höhe ist das Ding dann eingeschlagen. Und alles, was wir sehen, ist den Krater, also hier in dem linken, was ich ding, ihr seht, dieser kleine schwarze Punkt, das ist er. Und wenn wir rechts gucken, so, jetzt Kamera, Achtung, ich laufe mal rum, ne? Hier sehen wir verschiedene Dinge, also hier das, das ist die Einschlagstelle des Schwarzes, also man sieht ja auch schön so ein bisschen den Winkel und wie das noch so diese schwarze Linie, das ist so, weil es schräg eingeschlagen ist. Hier unten, da sehen wir den Fallschirm und die untere Schale und da oben sehen wir die obere Schale, die es abgehauen hat. Also die ist noch ein Stück weitergeflogen, wie man sieht. Naja, also welche auf Maas, ich würde mich echt beschweren, dass wir da immer Müll hinschmeißen. Aber ja, jeder, also so unterlassen wir auch unser Zeichen, kaputte Roboter und zerschälte Sachen auf Maas. Also 2017, also wir haben jetzt gerade gelernt so, es passiert immer vorhergesehene Dinge, klar, da kann man nichts machen. Aber manchmal, also egal wie gut man ist, unvorhergesehen ist, aber es kann auch ganz, ganz blöd sein. Und das ist die Soyuz 2.1B. 19 Satelliten, also hatte richtig schön viel Zeug dabei, sollte es in Orbit bringen. Ja, der Techniker wusste nicht so richtig, wo er ist. Das Ganze sollte eigentlich in Baikonur starten. Das ging da nicht, dann hat man es verlegt nach Wostochny und keiner hat die Koordinaten geändert. Mal so zu Verdeutlichung, das sind so fast 6.500 Kilometer beim Auto. Ja, kann man sich mal vertun. Also ich fahre auch schon mal zum falschen Arbeitsweg so, ja, puh, gut. Also was ist passiert, die obere Stufe konnte sich nicht ausrichten, das war halt irgendwie schon in eine andere Richtung. Die Triebwerke feuerten dann in die falsche Richtung, also Richtung Erde. Und das Ganze ist dann in der Atmosphäre verbrannt. Ja, also warum Zölle geht eigentlich so viel schief? Und das möchte ich so ein bisschen beleuchten. Der einfachste Grund ist, ja, it's rocket science. Den Ausdruck gibt's nicht ganz so ohne Grund. Aber kommen wir zu den wahren Gründen. Wenn wir Sachen ins All schicken, gerade zu Mars, zu Venus oder irgendwohin, was da alles geplant ist. Wir haben zwar eine grobe Idee, was uns da so wartet, aber so richtig genau wissen wir es nicht. Es sind irgendwelche Winde, von denen wir nicht gerechnet haben. Wir wissen nicht, wie die Atmosphäre genau ist. Das heißt, egal was wir machen, es wird weiter Fails geben. Es werden Dinge schief gehen. Weil Raumfahrt ist ganz schön schwer. Es gibt ganz schön viel, was man da reinbauen muss. Und zwar das auch noch in alte Technik. Also so ein paar Satelliten, die haben da so Speicher. Ja, was glaubt ihr, was so ein Satellit so ein einfacher hat an Speicher? Hat da jemand eine Idee? Irgendwer, was ruhig reinrufen. Okay, das waren zu viele gleichzeitig. Wer an GIG oder MB denkt, ihr seid zu groß. Wir sind so ein Bereich von paar KB teilweise. Der Grund ist, die Strahlung, die da oben unterwegs ist, die haut halt da einfach durch, also normale Chips und Co. Diese ganzen Zellen ist einfach viel zu klein. Da fällt viel zu viel aus. Das geht nicht. Das ist alte verlässliche Technik. Einfach mal gerne aus dem letzten oder vorletzten Jahrzehntes, mit der da gebaut wird. Vieles von dem, was ich gezeigt habe, ist eine ganze Weile weg. Also das ist jetzt so, irgendwie war Anfang der 60er oder aus den 80er, 90er. Bei vielen, was wir heute haben, Testframeworks, Continuous Integration und Co. Das gab es damals nur im bedingten Umfang. Also am Anfang gab es nicht mal Editorien richtig, die einem Sintax Highlighting gemacht haben. Da wurde der Kram auf irgendwelchen wirklich schlechten Thermodruckern ausgedruckt. Und dann sollten alle nachlesen, ob der Code stimmt. Ich will sehen, wer das von euch kann. Ich kann nach zwei Wochen meine Kassenzettel nicht mehr lesen. Geschweige denn irgendwie übersehen, ob da jetzt auf diesem Shitty Drucker ein Doppelpunkt oder ein Simikolon war. Und dazu muss man sagen, dieser Code wird geschrieben, nicht von Informatikern, sondern natürlich von Experten in ihren Bereichen, die irgendwie so ein Kram zusammenschrauben, aber natürlich keine Ausbildung in Software-Engineering haben oder irgendwas. Das heißt, die geben ihr Bestes. Und fachlich sind die Top, aber das mit dem Software schreiben ist nicht immer ganz so einfach. Den Disclaimer, den ich dazu sagen will, das hier war natürlich kein repräsentativer Auszug. Also alle haben ja mitbekommen. Ganz, ganz, ganz viel hat funktioniert. Ganz viel ist da oben unterwegs. Wir haben auch Folkstories wie Curiosity, der seine Originallaufzeit bei Weitem überschritten hat. Jedes Jahr sein Geburtstag-Ständchen singt und immer noch rumfährt und Dinge für uns erforscht. Also, es gibt auch Sachen, die funktionieren. Und wie ESA-Sprech ist, wir scheitern nicht, wir lernen. Das ist noch nicht das Ende des Talks. Aber danke. Meine Liebling-Story zu Bescheitern nicht, sondern wir lernen es. Die Reaktion von der ESA war bei Rosetta und Philae, wo der Läner ja auf dem Komet vor allem alle gesagt, wenn der landet, also wenn der runterkommt, wir müssen uns sofort festhalten. Wenn der einmal baut, dann springt der ins All. Dann gibt das nichts. Das kann nicht sein. Alle Experten in jede Kamera, immer nein, nein, wenn das nicht beim ersten Mal klappt, der ist weg. Er ist ja dann gebaut zweimal. ESA-Presse-Mitteilung. Wir sind nicht nur einmal gelandet, wir sind dreimal gelandet. Ich mag die Jungs. Was können wir ändern? Was haben wir getan, damit es besser wird? Natürlich hat sich Softwareentwicklung weiterentwickelt. Es gab einfach eine Menge Methoden, die eingeführt werden und da wird wirklich hart dran gearbeitet. Es gibt Schulungen, wo die Leute hingeschickt werden. Es ist nicht mehr okay, dass Forscher sich hier nicht schreiben. Wir machen Schulungen, wir helfen denen bei, das ist Teil meines Jobs, den zu sagen, so macht man das richtig, so macht man das ordentlich. Es gibt mittlerweile einen kompletten eigenen Job Bezeichnungen, die RSE nennt sich Research Software Engineers. Das sind eben Leute, die Software Engineering können und Forscher unterstützen bei ihrem Code, um das Ganze alles besser zu machen, nicht nur in der Raumfahrt, sondern komplett. Das Ganze ist ein relativ neues Konzept, also hat ein Name erst so seit zwei, drei Jahren. Und natürlich, ich meine, wir sind hier in Deutschland, es gibt Standards. Zugegeben, ECSS ist ein europäischer Standard, in dem es kleinsten definiert, was muss dokumentiert werden, wie muss getestet werden, was muss alles gemacht werden. Und ich kann euch sagen, es ist kein Spaß. Also jeder, der in der Raumfahrt arbeiten will, treffe ich immer, ja, total geil, ja, ja, dann musst du ECSS Standards machen, es ist kein Spaß, also es ist alles andere, was ihr an Standards hier gelesen habt. Vergesset, ECSS, da wird spannend. Und wir machen es natürlich uns einfach, denn es gibt schon so ein paar Sachen, wie man sich behelfen kann. Zum Beispiel kann man sein, Sachen, die man los schickt, wie Curiosity, oder auch Filai, oder so. Na ja, man schickt die los mit dem Code, den sie brauchen, für den Flug oder bei Filar und so, zum Aufwachen. Aber der muss ja noch nicht wissen, wie er landet. Der ist ja zehn Jahre unterwegs. Er hat ganz schön viel Zeit, um den Code zu schreiben. Und ja, es klingt, es klingt albern, aber es wird gemacht aus guten Gründen, denn zehn Jahre sind eine Menge Zeit, der Werden, Softwaretechniken besser, der Testing besser. Man kann das Ganze optimieren, man hat viel, viel Zeit, und das wird genutzt. Und ja, deswegen, also manchmal, wenn ihr so mitbekommt, da landet so ein Curiosity, der ist gelandet, und dann hieß es so, ja, zwei Tage haben alle nichts dafür gehört, von dem Ding gehört, weil, ja, Software Update. Und die Verbindung da hoch ist nicht so geil. Also haben wir es hier besser. Sprich, wir versuchen unser Bestes zu ändern, menschliche Fehler, also so, ja, wo bin ich hier eigentlich? Das passiert weiterhin, und es wird weiter Fails geben, weil wir nicht wissen, was uns erwartet. Aber generell kann ich sagen, es funktioniert, wir machen vieles, es ist schön, wir lernen aus allem. Also ja, ESA sprecht nicht falsch, wir versuchen aus allem zu lernen. Wir sind immer froh, wenn was schiefgegangen ist, bevor es sozusagen kritisch ist. Und ja, hoffen wir, dass das alles weitergeht, und dass wir demnächst endlich auch wirklich auf dem Mars sind, und dann auch wieder wegkommen. Damit, vielen Dank. Das war's, und ich wünsche euch noch einen schönen Abend. Ja, ich denke, wir haben genug Zeit für Fragen. Wer möchte, Mikrofon habe ich in der Hand. Gibt es Fragen in Karina? Einfach Handhäben, dann husche ich hier durch. Ja gut, diese Ring-Cann-Speicher, werden die eigentlich immer noch eingesetzt, oder hat da mittlerweile doch einen Weg gefunden, diese ICs abzuschämen? Das ist ja schon eine sehr adäquate Technik. Die müssen ja immer noch von Hand gehäkelt werden. Also gut, die, die ich da gezeigt habe, das sind jetzt nicht ganz die, die noch eingesetzt werden. Aber es kommt wirklich darauf an auf die Mission. Also alles, was so in der Erdbeereich ist, also das ist jetzt nicht so wild, oder auch was da auf der ISS läuft, das ist ja geschirmt. Das sind immer noch die größeren, also mit größeren Zellen und Co., was da unterwegs ist. Aber wenn es so in Deep Space über lange, lange Zeiten geht, da wird noch relativ alte Technik bis heute verbaut, weil es einfach anders nicht möglich ist. Sonst hast du einen Ausfall, weil ja zu viel Rammbereiche, Speicherbereiche wechseln und es hilft dir dann auch nichts, oder auch von anderen Speichermedien. Also das ist, dies bleibt noch eine Weile, glaube ich so. Also es gibt ja natürlich immer ein bisschen weiter Entwicklung, aber es ist noch eine Herausforderung, dafür Code zu schreiben. Okay, super. Vielen Dank. Könntest du vielleicht einen Bug erzählen, ob du es dir auch ein bisschen überlegen kannst? Aus der Raumfahrt habe ich jetzt nicht ganz ein Beispiel, aber aus der Luftfahrt. Da gab es mal, ich glaube es war der F-15, das ist nicht so mein Lieblingsbeispiel, aber da haben sie in der Simulation mitbekommen, dass wenn der, ich glaube die Datumskräze überfliegt, sich über den Kopf dreht. Also glücklicherweise, bevor er da drin saß, wie sagt er in der Simulation, haben sie dann gefixt? Bevor wir am ersten Testflug, also ja, da gibt es ganz viel, was gefunden wird, aber das wird nicht immer öffentlich gemacht, weil ja, also es gibt auch ein paar Sachen, die wurden dann gefunden, also das sind aber eher bei anderen Tragönen, die ich jetzt hier nicht vorgestellt habe, wo man sagt so Alter, wieso ist das Thema gut gegangen? Also auch das gibt es, die findet man dann plötzlich, also Raumfahrt ist schon so ein heikles Ding. Bei so einer Mission gibt es ja extrem viele Systeme, sehr viele Hardwarehersteller, Softwareentwickler, wie viel Kontrolle hat man denn als DLR, ESA oder überhaupt dann noch über die Komplexität des Systems? Also das macht also vor allem die ESA, es ist wirklich, viele denken immer, die ESA macht so viel selbst, aber eigentlich gerade Softwareentwicklung machen die relativ wenig, das geben die alles raus an externe Firmen und die machen das wirklich über Standards und Dokumente, also das ist ein wahnsinnig trockener Job. Also im Sinne von, dass man wirklich sagt, man macht Spezifikationen, Requirements, Testing, das ist ganz, ganz genau definiert, wie sich alles verhalten muss, weil es die einzige Möglichkeit, so komplexe Sachen ans Laufen zu kriegen und das zu machen. Also da ist einfach eine Menge Bürokratie hinter, muss man sagen und sehr rigorose Vorgaben eben in diesen Standards, was das Testing angeht. Der Standard hat auch nochmal verschiedene Ebenen, je nachdem, was für Raumfahrt man betreibt. Also die oberste Ebene, das ist was, was wir in Deutschland gar nicht machen. Also dafür schreiben wir gar keine Software, auf der es nämlich die, also Raumfahrt mit Leuten, also bemannte Raumfahrt, dafür machen wir gar nichts, weil wir gar nicht die Zerifizierung und Co. haben, dass wir, dass wir so hoch zum Beispiel schreiben. Ich bin da auch ganz froh darum, um ehrlich zu sein, das fühle ich gar nicht so richtig. Ich kann mir vorstellen, dass ein Weg gegen diese Probleme ist, dass man Redundanzen einbaut. Wie viele verschiedenen Quarters, bei denen der das Gleiche tut? Also Redundanzsysteme, also im Sinne von verschiedene Folgen, also Rollbacks oder so gibt es, also haben wir ja gesehen, im einen Beispiel hatten wir ja eigentlich sozusagen, sollte eigentlich Ground Control, aber wenn dann halt die Kommunikation fällt, dass dann das nächste einsetzt, da gibt es schon Redundanzen. Aber es kommt da auch darauf an, auf die Mission. Also bei bemannte Raumfahrt gibt es viel, viel mehr Redundanz, weil da ist einfach ein ganz anderes Risiko, aber bei anderen Sachen, das ist alles Gewicht. Also alles, was du ja reinbaust, ist wieder Gewicht und jedes Gramm oder jedes Kilo, was du sparsst, spart wiederum Treibstoff und Co., was wieder das ganze Ding, die wieder möglich andere Sachen mitzunehmen. Also es ist eine richtig krasse Kette. Jedes 100 Gramm halbes Kilo, was gespart wird, wird gespart. Das heißt bei Redundanzen versucht man, auf das zu gehen, was muss, aber auch nicht mehr. Und ja, da kommt es dann auf die Mission an und die Kritik halt. Naja, wenn da nun ein paar Satelliten drin sind, ist so eine BWL-Abrechnung, ne? So. Okay. Ansonsten bin ich mir sicher, Karina steht noch zur Verfügung, draußen auf der Wiese. Auf der Wiese bei Junk? Genau. Ja, herzlichen Dank. Gerne.