Voriges Kapitel Inhaltsverzeichnis Nächstes Kapitel



4. Kapitel



        4.      Der Spezialist

Rodrigo stößt mich an. Der Softwaretechniker ist erschienen - ich habe es nicht bemerkt. War wohl in Gedanken. Die Begrüßung ist knapp. Sein Name ist Miesner, und er ist Informatiker, etwa so alt wie ich, hochgewachsen und schlank und Kompetenz austrahlend. Er hat Stapel von Listings mitgebracht und setzt sich sofort in den Kontrollsitz vor der Hauptkonsole. Die Listings läßt er neben sich auf die Konsolenablage plumpsen. Es ist mir etwas unklar, warum er solche Datenmengen auf Papier ausgedruckt mit sich herumschleppt, wo es doch elegantere Möglichkeiten für so etwas gibt, aber ich sage nichts.

Er will sich zunächst vorführen lassen, was wir beobachtet haben. Diesen Wunsch können wir ihm erfüllen. Zum vierten Male erscheint die geheimnisvolle Meldung.

"Das schaut nicht gut aus," sagt er sachlich, so, als ob er eine Bemerkung über zuviel Zucker im Kaffe macht, "Der Runtimesystemfehler 093942, Status urgent, eine nicht-identifizierbare exception TASKING_ERROR. Nicht identifizierbar vom Ursprung aus. Es ist ein Rendezvous-Fehler."

"Aha." sage ich. Es scheint im Moment das gescheiteste zu sein.

"Ich habe hier eine Liste mit allen Punkten, wo eine vordefinierte exception generiert werden könnte. Allerdings würde sich das RTS dann nicht mit 'unidentified' melden. Also kommt alles, was in dieser Liste steht, nicht in Frage. Es ist kein gewöhnlicher Deadlock. Das haben wir im Design auch durchgehend umgangen, es sollte also nicht vorkommen, grobe Denkfehler mal außen vor. Können Sie mal vormachen, was sie alles getan haben, bis es zu dieser Situation gekommen ist?"

Schon wieder. Ich erkläre ihm, daß das nicht geht. Da ich das Einlaufen des Wassers in die Auftriebszellen nicht abstellen kann, kann ich auch nicht vormachen, wie ich es heute morgen um vier Uhr angestellt habe. Er muß sich mit einer verbalen Beschreibung begnügen.

"Also noch einmal," sagte er, "damit wir uns da richtig verstehen, Fräulein Pemberton."

"Frau Pemberton." berichtige ich, mit einem Tonfall deutlich unter Zimmertemperatur. Peinliche Pause. Nicht meine Schuld - habe ich diese alberne Bezeichnung verwendet?

"Frau Pemberton. Sie haben die Reaktoren angestellt. Alle?"

"Ja."

"Und dann haben Sie die Vortriebsmaschinen angeschaltet, obwohl die Reaktoren zu dem Zeitpunkt noch keine Energie geliefert haben?"

"Ja."

"Und das geht? Reaktortechnisch, meine ich."

"Ja, warum nicht? Die Generatoren sind beim Anlaufen eben gleich belastet. Das ist vorgesehen. Ist sogar günstiger als erst bei voller Drehzahl die Last zuzuschalten, weil die plötzliche Stromentnahme schlagartig große Kräfte in den Ankerwicklungen der Generatoren entfaltet. Diese Turbinen sind sogar naßdampffest, was immer das bedeuten mag, aber es wurde für den Fall des langsamen Hochfahrens in den technischen Unterlagen als wesentliche Eigenschaft beschrieben."

"Und durch das plötzliche Zuschalten der Last können die Generatoren Schaden nehmen?"

"Natürlich nicht, das können sie ab. Dafür sind sie konstruiert. Wenn man sie nicht gerade bei maximaler Drehzahl kurzschließt, dann gehen sie eben nicht kaputt. Man kann mit dem Zuschalten der Last warten, bis die Reaktoren voll da sind, oder man kann es früher machen. Es bleibt sich eigentlich gleich."

"Für die Reaktoren und die Antriebsmaschinen vielleicht," denkt Miesner laut nach, "aber nicht für die Steuer- und Lastverteilungsalgorithmen."

"Wieso denn nicht?"

"Weil sie versuchen, eine Lastverteilung mit nicht laufenden Antriebsmaschinen zu erreichen. Das geht nicht."

"Na und?"

"Wenn das System merkt, daß die Lastverteilung offenbar wirkungslos bleibt, dann legt es andere Modelle der Stadt an als es der Fall wäre, wenn diese Situation nicht einträte."

"Aber das System experimentiert doch am laufenden Band mit alternativen Stadtmodellen?"

"Schon. Aber es ist immer eines dieser Modelle als das aktuell gültige definiert. Von diesem werden neue Variationen erzeugt. Wenn nun eine Inkonsistenz zwischen dem, was das System tatsächlich tut, und dem, was das System glaubt zu tun entsteht, dann wird es völlig unvorhersehbar, wie das aktuelle Stadtmodell aussieht. Wenn Sie also schon häufiger den Antrieb der Stadt auf diese Weise gestartet haben, dann läßt das darauf schließen, daß dieses inkonsistente Modell der Stadt wieder korrigiert wird, wenn die Antriebsmaschinen beginnen, Wirkung zu zeigen. Gewissermaßen spürt das System seine Kraft und die Wirkung der Kraft und findet damit zur Realität zurück."

Der Miesner redet schon so, als wäre er auf diesem Arbeitsplatz zu Hause. Jedenfalls weiß er, wovon er spricht. Es ist vertrauenerweckend, obwohl er noch nicht zu erkennen gegeben hat, ob er das Problem nun lösen kann oder nicht.

"Sie können sich das vielleicht so vorstellen, als ob ein Mensch, dessen Beine sich gerade von einer großen, örtlichen Betäubung erholen, versucht, wieder laufen zu lernen. Die zunächst fehlende Wirkung der Willensentscheidung zum Laufen auf die Muskeln führt tatsächlich dazu, daß man versucht, sehr viele sinnlose Muskelbewegungen zu machen. Erst mit Wiederkehren des Gefühls in den Beinen lernt man wieder, sinnvolle Nervenimpulse an die Beine zu schicken. - Das Beispiel hinkt natürlich etwas, weil wir es im Stadtrechner nicht mit neuronalen Strukturen zu tun haben."

"Das habe ich ungefähr verstanden," unterbricht Rodrigo, "Es ist also so, daß, wenn die Vortriebsmaschinen nicht laufen, das System sich Illusionen über die mechanische Natur der Stadt macht. Aber eben weil die Vortriebsmaschinen nicht oder noch nicht laufen, hat das keine Auswirkungen."

"So kann man es auch ausdrücken." sagt Miesner.

"Was ist denn mit den Vortriebsmaschinen, die schon eingeschaltet waren?"

"Bei einem zu geringen Antrieb wird auf die Lastregelung verzichtet. Erst, wenn alle Antriebsmaschinen und die zugehörigen Reaktoren vergleichbare Leistungen liefern können, dann werden die Antriebsmaschinen, die schon in Betrieb waren, ebenfalls von dem Lastverteilungsalgorithmus mit übernommen."

"Aber dann verstehe ich nicht, wieso die Flutung der Auftriebszellen gestört wird."

"Das ist auch noch keine Erklärung. Ich stelle nur gerade fest, daß Sie im Dienst gelegentlich Dinge machen, die wir im Design des Systems nicht vorgesehen haben. Ob das nun relevant für ihr Problem ist, das weiß ich noch nicht. Ich halte nur folgendes fest: Die numerischen Stadtmodelle waren in einem vielleicht nicht wirklichkeitskonformen Zustand. Das kann etwas bedeuten, muß aber nicht. Ich nehme fast an, daß es etwas bedeutet."

"Warum?" frage ich.

"Weil, wie Sie sagen, Ihre nächste Aktion war, die Flutung der Auftriebszellen zu stoppen. Auch dies ist rechnergestützt, wie Sie wissen. Auch für die Flutung der Auftriebszellen wird das numerische Modell der Stadt benötigt."

"Und?"

"Ich nehme an, daß es bei dem Zugriff auf dieses Modell der Stadt zu einem Deadlock gekommen ist. Die Steuerung der Flutung der Auftriebszellen und die Steuerung der Antriebsmaschinen werden nämlich von verschiedenen Tasks verwaltet."

"Das glaube ich nicht," sagt Rodrigo, "wenn es so wäre, dann würden diese Deadlocks ja schon im Normalbetrieb auftauchen. Wir haben mit dem System aber nie Schwierigkeiten gehabt."

"Der Unterschied" vermutet Miesner "liegt in der Vielzahl neuer, experimentell generierter numerischer Stadtmodelle. Das muß, irgendwie, diesen Deadlock oder was immer es ist, verursacht haben."



Voriges Kapitel Inhaltsverzeichnis Nächstes Kapitel



Voriges Kapitel Inhaltsverzeichnis Nächstes Kapitel


Zurück zu meiner Hauptseite

Sie sind Leserin dieser Seite Nummer


This page hosted by GeoCities Get your own Free Home Page