Was ist aber, wenn ein Kollege während des realen Marsflug stirbt? Oder ein Körperteil verliert? Oder wie in jeden tollen Kriegsfilm zu sehen: Opfere einen Soldaten um den Rest der Mannschaft zu retten? Plötzlich haben einige Kabinen des Shuttles keinen Sauerstoff mehr und die Leichen schweben schwerelos im Raum herum…

Ich will das garnicht lächerlich machen und finde das auch nicht makaber – vielmehr befürchte ich, dass eine zukünftige Mars-Mannschaft genau solchen Situationen ausgesetzt sein könnte und dann ist die Frage, ob eine 500Tage-Simulation in einen Container lehrreich war!

Ich denke, dass es wie mit der Erschaffung des Feuers durch die Menschheit laufen wird: In dem Moment, war der einzelne Mensch froh, als er die zwei Steine zusammen schlug und durch einen Funkenregen im Stroh das erste Feuer schuf, die Höhle damit wärmte, aber erst viel, viel später wird der Menschheit bewußt mit welcher Schlüsselerfindung sie es zutun hat. Irgendwie wird die Menschheit im Container  und den Flug zum Mars überleben – kommen sie aber zurück, ist es eine andere Menschheit.

500Tage Fußball? Daraus ist kaum zu lernen …

An Ihren Schreibtisch im Büro sieht alles wie am Vortag aus. Wieso auch nicht? Sie haben der Putzfrau untersagt, auf Ihren Schreibtisch zu putzen und so finden Sie alles griffgünstig – eben wie gewohnt. Und so schalten sie den PC ein und starten Ihr Eclipse oder Visual Studio und legen ein neues Projekt an. Die Tee-Kanne duftet auf dem kleinen Tischchen neben dem PC. In der Email vom Vortag versuchen Sie nochmals den Arbeitsauftrag herauszulesen.

“Hallo Hr.X,

wir haben in verschiedenen Simulationen festgestellt, dass der Landeprozess einer deutlichen Absicherung bedarf! Durch die Konstruktion als Nurflügler ist bei voller Beladung im Erdbereich (wie in der Zielvorgabe wird mit 5000 Tonnen (ohne Eigengewicht) simuliert) mit enormen Unsicherheiten für Last, Maschine und Pilot zu rechnen. Entwerfen Sie eine Notfall-Routine, die in das Lande-Programm eingepflegt werden kann und dem Pilot im kritischen Fall verschiedene Berechnungen und Entscheidungen abnimmt. MfG K.L.”

Na gut, für einen einigermaßen geübten Programmierer ist das erstmal kein großes Ding. Man sammelt erstmal verschiedene “mögliche Störfälle” (mS). So könnte z.B. der Seitenwind bis zu einer bestimmten Stärke unvermittelt zu nehmen oder der Treibstoff-Zufluss könnte bei der Landung abnehmen (Immerhin sind bei den Mars-Flügen keine Zwischentankstopps geplant!). Vielleicht sollte man auch nochmal in Erwägung ziehen, dass sich die Last verschoben hat. Ganz ignorieren kann man auch die mechanischen Beschädigungen nicht: vielleicht ist die Kardanwelle, die das Landefahrwerk ausfährt, aufgrund der enormen Hitze bei Eintritt in die Erdatmosphäre in den Führungslagern fest gegangen. Der Szenarien gibt es viele und so muss natürlich auch die Kombination der mS berücksichtigt werden – Was soll das Programm machen, wenn beim Landeanflug die Last verschoben ist, abrupt ein Seitenwind aufkommt (durch die enorme Hitze der Triebwerke initiiert) und der Treibstofffluss nicht mehr mit 5000 bar sichergestellt ist? Und so stellt man erstmal tabellarisch die Szenarien zusammen, überprüft ihre Kombinationen, ermittelt die “möglichen Lösungs-Aktionen” (mLA).

Hr.X schrieb viele Monate an diesen Programm, es wurde auch implementiert und nach der ersten Landung des Mars-Nurflüglers (MNur) wieder aus dem Bord-Computer gelöscht – Was war geschehen?

Der MNur war nach einen 12monatigen Flug vom Mars auf Landeanflug Erde. Man implementierte das Programm des Hr.X’s mit den mLA während der Flugzeit zur Erde und wollte diese Landung gleich als erste Test-Landung auf der Erde nutzen. Bisher wurden die MNur über eine Station auf dem Mond umgeladen und so versprach man sich enorme Kostenersparnisse, wenn die MNur direkt auf der Erde starten und Landen könnten.

Aber es kam zur Katastrophe! Beim Landeanflug flog der MNur ungebremst in die Erde, die komplette Landebasis wurde zerstört (ausgenommen der Teile, die in einen Bunker unter der Erde lagen), etwa 200 Mitarbeiter (Piloten, Wartungspersonal, Sicherheitskräfte) fanden den Tod. Warum?

Jahrelang beschäftigte sich eine Kommission mit dieser Katastrophe. Es ging nicht nur um die finanziellen und menschlichen Verluste – vielmehr galt es zu klären, was den nun der eigentliche Fehler war, dass ein MNur, trotz des implementierten Sicherheitsprogramms und dem durchspielen aller möglichen Szenarien, so eine Katastrophe fabrizierte.

Die Lösung? Monate nach dem Unglückstag fand man in der Erde noch einen kleinen Teil eines Racks in dem noch Blades steckten, die der MNur als SAN für seine Kurzzeit-Berechnungen nutzte – quasi als Erweiterung des RAM’s. Und da diese Blades Batterien auf der Platine hatten, gingen die letzten Überlegungen des Computers zu seinen Berechnungen nicht verloren. Es war, als könnte man bei einen toten Menschen, die letzten Überlegungen, Sekunden vor dem Tod, aus dem Gehirn schneiden. Und damit stellte man die letzten Berechnungen des Computers nach und es ergab sich ein, naja, – wie soll man sagen? – ein ungewöhnliches Ergebnis!

Wie sich herausstellte, war Hr.X ein sehr pedantischer Mensch, alles mußte genau an seinen Platz liegen, oder auch bei täglichen Entscheidungen im Alltag, versuchte er alle möglichen Einflüsse dieser Entscheidung auf seinen weiteren Tag voraus zu bestimmen. An sich war das nichts schlechtes! In Gegenteil! Hr.X galt als sehr gewissenhaft, seine Vorgesetzten trauten Ihm blind und wenn er für die Belegschaft die Weihnachtsfeier plante, konnte man sicher sein, dass alles 100% organisiert war. Aber das war das Problem!

Was Hr.X im Alltag auszeichnete übertrug er mit seinen Programm auf den Computer des MNur’s. Wie sich aus den Blades rekonstruieren ließ, gab es beim Landeanflug einen geringen Seitenwind. Dem Seitenwind hätte über eine einfache Aktion geantwortet werden können (einen kurzen Schub an der linken 90″-Düse) aber der Impuls des auftreffenden Seitenwindes löste das Programm für mS aus. Und anstelle einer einfachen mechanischen Antwort – eben einen kurzen Gasschub – startete das mS die Hilfsroutinen des mLA. Wie sich später rekonstruieren ließ, war die Entscheidung, WAS die Störung ist, vom Computer schnell erkannt, aber die wertvolle Reaktionszeit verschenkte er, bei der Auswahl der mLA. Das Programm war so geschrieben, dass es wie ein Schachprogramm, die verschiedenen Gegenzüge in jeweils 24 Varianten berechnete und so im unentschlossenen Zustand ungebremst in die Katastrophe flog.

Kein technischer Defekt war der Auslöser, sondern alleine die pedantischen Prüfroutinen, die aus der Unentschlossenheit eines Menschen (in Form des Programmierers) kamen, verursachte die Katastrophe. Seitdem wird bei NASA-Neueinstellungen auch die persönliche Fragmentierung des Kandidaten überprüft. (in Respekt für SL)

[UPDATE]

Oh Wunder! Man schaue sich mal diesen Artikel an.