Stellen Sie sich vor, Sie wären ein Programmierer bei der NASA. Wahrscheinlich ein Traum vieler Programmierer. Sie arbeiten dort schon seit ein paar Jahren und wissen, dass alle Routinen 5mal überprüft werden müssen. Sicherlich beginnt Ihr Morgen ganz normal: nach dem aufstehen schauen Sie erst einmal in Ihren Outlook nach der ToDo-Liste für den heutigen Tag, danach gehen Sie langsam in das Bad und während Sie sich die Zähne putzen, betrachten Sie ihre Tuben und Fläschchen auf der Ablage vor dem Spiegel – aber – jetzt kommt es! -: Sie können es sich nicht verkneifen, die Borsten des Rasierpinsels zum Fenster auszurichten. Was sollte daran schlimm sein? Erstmal nichts!
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 die Rakete im unentschlossenen Zustand ungebremst in die Katastrophe fliegen ließ.
Kein technischer Defekt, sondern alleine die umfassenden Prüfroutinen, die mit der Pedanterie eines Menschen – in Form des Programmierers – arbeiteten, verursachte die Katastrophe. Seitdem wird bei NASA-Neueinstellungen auch die persönliche Fragmentierung des Kandidaten überprüft. (in Respekt für Stanislaw Lem)
[UPDATE,25.07.2009] Oh Wunder, man schaue sich diesen Artikel an!
Kommentare “Programmierung: zu Tode geprüft”