Im Bereich der Prozeßautomation ist Fehlertoleranz eine vielfach absolut unverzichtbare Forderung an ein Rechnersystem. Doch weil auf der anderen Seite Kostenaspekte dem Aufwand, der noch gerechtfertigt werden kann, Grenzen setzen, ist es beim Implementieren fehlertoleranter Rechner wichtig, wirtschaftliche Lösungen anzustreben - so, wie das beispielsweise im Rahmen eines Forschungsprojektes geschah, das an der Technischen Universität München realisiert worden ist: das Projekt "Future".
Future, so erläutert Dr. Franz Demmelmeier vom Lehrstuhl für Prozeßrechner der Münchner TU, ist das Akronym für "Fault-tolerant and User-friendly-system with Taskspecific Utilization of Redundancy", und eines seiner besonderen Kennzeichen liegt darin, daß es nicht nur Hardwareausfälle toleriert und den technischen Prozeß im Falle eines Fehlers ohne Unterbrechung fortführt, sondern daß Future auch eine "optimale Anpassung der redundanten Hardware an die Aufgabenstellung erlaubt". Außerdem ist Future laut Demmelmeier "anwenderfreundlich", denn hierbei werden die Fehlertoleranzfunktionen "vollständig durch das Betriebssystem verwaltet," ohne daß etwa der Programmierer noch mühevoll selber "Aufsetzpunkte" festlegen mußte.
Befaßt man sich mit dem System Future näher - seine Entwicklung wurde übrigens von der Deutschen Forschungsgemeinschaft (DFG) gefördert -, so bemerkt man, daß es sich zunächst um eine Struktur handelt, die auf sogenannte "Q-Bus"-Modulen sowie auf Standard-Modulen der "LSl-11"-Familie basiert; also auf Produkten von Digital Equipment. Doch diese Grundbausteine wurden an der Münchner TU um ein leistungsfähiges Nachrichten-Transportsystem erweitert, das es erlaubt, Informationen zwischen den Mikrorechnern hin- und herzuschaufeln. Außerdem wurde noch ein besonderes Prozeßein- und -ausgabesystem vorgesehen; die Entwickler des Systems Future haben es voll in die Fehlertoleranzmechanismen mit einbezogen. Will man sich zunächst einen großen Überblick verschaffen, so stellt man fest, daß Future in seiner Wirkungsweise auf der automatischen Erkennung von transienten und auch permanenten Fehlern basiert. Dabei werden diese Fehler dadurch erkannt, daß immer wieder in kurzen Abständen auf geeignete Weise im Sinne von Zwei-aus-drei-Entscheidungen festgestellt (votiert) wird, ob ein Zwischenergebnis, das ein im System ablaufendes Programm (eine Task) liefert, von den gleichzeitig gelieferten Zwischenergebnissen der anderen, gleichartigen und parallel bearbeiteten Tasks abweicht. Man geht davon aus, daß dann, wenn zwei Tasks ein Resultat A liefern, mit der dritten Task, die das Resultat B liefert, irgend etwas nicht in Ordnung ist.
Wie reagiert Future aber nun, Iiegt einmal ein derartiger Fall vor? - Was genau geschieht, hängt zunächst einmal davon ab, welche Art Fehler diagnostiziert wurde. Es kann sich nämlich um einen transienten (vorübergehenden) Fehler handeln - dann werden vom System nur automatisch die entsprechenden Datenbestände restauriert. Es kann aber auch ein permanenter Fehler vorliegen, und dann wird automatisch eine System-Rekonfiguration durchgeführt, wobei ein Ersatzrechner eingeschaltet wird. Denn das System Future baut sich aus vier oder mehr parallel arbeitenden Mikrorechnern auf, von denen für das Zwei-aus-drei-Votieren lediglich drei gebraucht werden. Der Votiermechanismus der Münchner Entwicklung ist laut Demmelmeier "durch Software realisiert", und sein Wirken stellt sicher, daß Fehler keine Auswirkungen auf die technischen Prozeß, den die Future-Rechner überwachen und steuern, haben - es sei denn, natürlich, das Gesamtsystem würde etwa plötzlich zerstört werden. Doch speziell am Konzept Future ist hierbei nun wichtig, daß nicht alle Teilprogramme stets auf mindestens drei Rechner gleichzeitig und parallel laufen: denn das würde ja bedeuten, im Falle unwichtiger, unkritischer Teilprogramme werden Ressourcen unnötig vergeudet. Deshalb erlaubt das Future-System, den einzelnen Teilprogrammen jeweils eine von insgesamt fünf "Zuverlässigkeitsklassen" zuzuordnen und damit "die für die Fehlertoleranz nötige Redundanz der Hardware kostenoptimal auf die verschiedenen Teilaufgaben innerhalb einer komplexen Prozeßsteuerung zu verteilen", wie Demmelmeier hervorhebt. Praktisch läuft das darauf hinaus, daß nur die wirklich kritischen Teilprogramme im oben skizzierten Sinne auf drei Rechnern gleichzeitig laufen, weniger kritische hingegen bloß auf zwei Maschinen und die "unwichtigsten" sogar nur auf einer. Die restlichen Rechner bleiben derweil frei für andere Tasks. Was bringt nun ein System wie das Future der Münchner Prozeßrechner-Experten unterm Strich? - Nach Unterlagen aus der TU München erreicht jeder der vier Einzelrechner eine MTBF (Mean Time Between Failures oder auch mittlere Zeit zwischen je zwei Ausfällen) von 4200 Stunden. Dabei werden der Prozessor samt Speicher, Nachrichtentransportsystem und Prozeßein- und -ausgabesystem jeweils als ein "Einzelrechner" betrachtet.
Schaut man nun auf das Rechner-Quartett als ganzes, so ergeben sich, wobei hier nun auch der Einfluß, des spezifischen Future-Betriebssystems zum Tragen kommt, MTBP-Zahlen von 200 000 Stunden, also rund das 48fache. Oder, in sogenannte Ausfallraten umgerechnet: das Einzelsystem arbeitet mit durchschnittlich 2,3 mal 10-4 Fehlern pro Stunde, das Quartett aber mit nur noch 5 mal 10-6 Fehlern pro Stunde.
Anzumerken ist hierbei, daß diese Zahlen auf der Annahme basieren, das Verhältnis zwischen transienten und permanenten Fehlern liege bei 5:1. Sollte es sich hingegen auf 1:1 belaufen, so ergäbe sich für das Quartett eine Ausfallrate von 2,7 mal 10-5, und bei einem Verhältnis von 10:1 würde die Ausfallrate nur noch 1,1 mal 10-6 betragen.
Mit solchen Zahlen ist Future nicht; nur vordergründig, unter dem Aspekt der Zuverlässigkeit, ein interessantes Konzept, sondern, schaut man näher hin, zum Beispiel auch unter dem Aspekt, die Wartungskosten möglichst niedrig zu halten. Denn man könne nun "die Reaktionszeit des Wartungsdienstes verlängern, ohne einen Rechnerausfall zu riskieren - ganz einfach deshalb, weil Future ja auch nach einem erkannten (und vom System dokumentierten) Fehler weiterarbeitet." Und so könne man nun kostengünstige Wartungsverträge abschließen, bei denen der Service-Ingenieur bloß binnen einiger Tage vorbeikommt, um den Fehler zu beseitigen. Teure Wartungsvereinbarungen mit Sofort-Reaktion der Service-Mannschaft hingegen erübrigen sich.
In diesem Zusammenhang liegt aus der TU eine Rechnung vor, aus der folgendes hervorgeht: Sollte die mittlere Reaktionszeit des Wartungsdienstes eine Woche beitragen, BO würde das bedeuten, die Ausfallrate des Gesamtsystems liege bei 4,6 mal 10-6. Geht man hingegen von einer mittleren Reaktionszeit von einem Monat aus - das muß dann; aber schon eine sehr verbummelte Organisation sein - , so steigt die Ausfallrate des Gesamtsystems auf 1,7 mal 10-5 an. Wobei auch hier stets wieder davon ausgegangen wurde, das Verhältnis der transienten zu den permanenten Fehlern liege bei 5:1.
Keine Festlegung auf Vier-Rechner-System
An der Münchner TU wurde -Future konkret als Vier-Rechner System implementiert, doch das ist keine starre Festlegung, denn man kann dieses System laut Demmelmeier mit zwischen drei und acht Rechnern beliebig konfigurieren. Und man kann es auch insofern noch modifizieren, als es durchaus möglich sein soll; "Intelligenz" Prozeß-Peripherie hineinzuverlagen. Das sei nämlich dank des Modul-Kontzepts, das der ganzen Sache zugrunde liege, durchaus möglich.
Während Future, wie skizziert, beeindruckende Zuverlässigkeitswerte erreicht, warnen seine Väter dennoch davor, das System mit Aufgaben zu betrauen, die es überfordern müssen. Denn die taksspezifische Nutzung der von der Hardware gebotenen Redundanz biete im Falle des Systems Future zwar hinreichend viel Zuverlässigkeit, um damit solche Prozeßautomatisierungs-Aufgaben zu bewältigen, bei denen ein Ausfall nichts Schlimmeres als "hohe Kosten" verursachen würde. Hingegen sei Future keinesfalls für Aufgaben im Bereich von Kernkraftwerken oder für Systeme für die Weltraumfahrt geeignet, denn dort sei eine noch weitaus höhere Zuverlässigkeit erforderlich.
Nimmt man das Konzept Future genauer unter die Lupe, so fallt auf, daß das in München implementierte Gesamtsystem dem Anwendungsprogrammierer sehr entgegenkommt. Denn man hat darauf geachtet, daß jener seine Programme ganz so wie für ein konventionelles Echtzeit-System ohne Fehlertoleranz entwickeln kann; die Schnittstelle zu den die Fehlertoleranz sicherstellenden Instanzen des Systems ist, von den Anwendungsprogrammen her gesehen, also völlig transparent. Denn, so erläutert Demmelmeier, die der Fehlererkennung und der Fehlerbehebung dienenden Mechanismen sind in Systemaufrufen verborgen, die beispielsweise die Kommunikation zwischen den Tasks oder den Ein- und Ausgaben vom und zum zu kontrollierenden Prozeß dienen.
Zur näheren Beleuchtung der Technik, die hinter diesen Eigenschaften steckt, kurz ein Blick auf die Architektur des Systems. Bei ihrer Festlegung galt es, erinnert sich Demmelmeier, ein bekanntes Hauptproblem aller fehlertoleranten Konzepte zu lösen; nämlich die Frage, welche Instanz denn eigentlich Fehler erkennen und isolieren soll und welche sich mit der Restaurierung der Datenbestände sowie mit der Rekonfigurierung des Systems befassen soll.
Problem verlagert
Oft, so bemerkt Demmelmeier, werden für diese Funktionen neue Module hinzugefügt, doch verlagerte dies ja nur das Problem. Denn nun müsse wieder geklärt werden, welche Instanz beispielsweise den Überwacher überwache.
Man muß also nach Wegen suchen, diese Hierarchie von Überwachern zu vermeiden und an ihre Stelle zum Beispiel eine "zyklische Lösung" setzen, bei der ein und dieselbe Hardware nicht nur die Tasks abarbeitet, sondern gleich auch die Überwachungsfunktionen wahrnimmt. Dabei können diese Funktionen wiederum als Software implementiert werken, zu deren Unterstützung dann allerdings noch gewisse besondere Hardware-Leistungen treten müssen.
Demmelmeier und sein Team kamen bei ihren konzeptionellen Überlegungen zu der Auffassung, nur ein kompletter Computer (ein Mikroprozessor samt Speicher, Ein-Ausgabe-Steuerung und weiteren Komponenten) biete "genügend Verarbeitungsfähigkeit", um sowohl Tasks abarbeiten als auch die geforderte Fehlertoleranz gewährleistenden Funktionen bieten zu können. Und deshalb ist die "kleinste (als Ganzes) ersetzbare Einheit" (smallest replacable unit, SRU) bei Future eben so ein Computer.
Bei Future gehört zu jedem dieser Computer ein sie alle miteinander verbindendes Message Transport System (MTS) sowie ein Prozeß-Input-Output-System (IOS). Dabei verfügen diese Erweiterungen noch über Vorkehrungen zur Unterstützung der Funktionen, die die Fehlertoleranz sicherstellen sollen; und man hat besonders darauf geachtet, sogenannte Fehlertoleranz-Flaschenhälse zu vermeiden. Es gibt also nicht etwa zum Beispiel Busse, die "weniger fehlertolerant" wären.
Die Computer, im konkreten Implementierungsfall der Münchner TU sind es ja vier, werden mit Hilfe von MTS daher über ein redundantes, serielles Bus-System gekoppelt das mit Glasfasern arbeitet und eine Datenrate von 16 MBit pro Sekunde gewährleistet. In die spezielle MTS-Hardware wurden dabei auch die Funktionen zum Votieren und zum Vergleich von Daten integriert und auch Einrichtungen zur Unterstützung der Synchronisation aller Mikrocomputer sowie zum Betrieb eines Nachrichtenaustausch-Netzes finden sich hier.
Laut Demmelmeier haben die Betriebserfahrungen mit Future gezeigt, daß ein höchst leistungsfähiges MTS erforderlich ist, soll die Echtzeit-Kontrolle eines technischen Prozesses (ohne jegliche Unterbrechung im Fehlerfall) sichergestellt werden.
Beim Ein-/Ausgabesystem IOS findet man pro Rechner eine Unterteilung in jeweils einen I/O-Controller und ein l/O-Modul vor, wobei die ersteren zu den Mikrocomputer-Einheiten gehören, die letzteren hingegen (logisch) zu dem Prozeß, der kontrolliert werden soll. Muß das System infolge eines Fehlers rekonfiguriert werden, so können die Verbindungen von den Modulen zu den Controllern neu arrangiert, also der neuen Sachlage angepaßt werden. Fällt ein Modul aus, so bedeutet das, der entsprechende "Prozeßpunkt" geht verloren, doch dieses Risiko erscheint tragbar: Denn die Module weisen dank ihrer simplen Struktur einen Grad an Zuverlässigkeit auf, der etwa um zwei Größenordnungen über dem des Gesamtsystems liegt. Und da die Modulfunktionen ja während des Betriebs vom Future-Betriebssystem getestet werden, können in jedem Falle fehlende Ein-/ Ausgabeoperationen garantiert werden.
Future arbeitet mit einem global verteilten Speicher, der, so Demmelmeier, "vom Standpunkt der Fehlertoleranz rückwirkungsfrei arbeitet und keine Zuverlässigkeitsengpässe, wie sie oft in Übertragungssystemen (Bussen) zu finden sind, beinhaltet." Von der Größe des Speichers hängt es entscheidend ab, wie schnell zum Beispiel eine Task im Fehlerfalle restauriert werden kann oder auch, wie lange eine Rekonfiguration des Systems dauert. Hingegen sind die reinen Datenübertragungs-Zeiten innerhalb von MTS minimal; hier liegt also kein Engpaß vor.
Da die Einteilung der Tasks in verschiedene Klassen praktisch der Grundgedanke des Systems Future ist, muß gefragt werden, wie man sich diese Task-Klassen denn nun eigentlich genau vorzustellen hat; und auch, wie sie sich im Fehlerfall denn nun eigentlich verhalten?
Die erste Gruppe bilden die Tasks der Klasse 3; also Tasks, die nicht ausfallen dürfen, die für den technischen Prozeß korrekte Ergebnisse liefern und die Prozeßsignale sicher und richtig verarbeiten. Hier werden Zwischenergebnisse (2-aus-3) votiert, und für die Bearbeitung jeder Teilaufgabe sind stets drei unabhängig voneinander laufende Tasks aktiv; also drei "Co-Tasks".
Bei diesen Klasse-3-Tasks werden von einem Fehler betroffene Datenbestände im Falle transienter Fehler restauriert oder, im Falle permanenter Fehler, die drei Co-Tasks neu verteilt und die Daten abgeglichen.
Klasse-3-Tasks belasten jeden Rechner statisch mit den für den Code und den reservierten Datenbereich benötigten Speicherplätzen. Hingegen bleibt die dynamische Belastung auf die drei Rechner beschränkt, die jeweils gerade für die drei Co-Tasks aktiv sind, bemerkt Demmelmeier.
Die zweite Gruppe wird von den Tasks der Klasse 2 dargestellt. Für sie ist typisch, daß sie zwar auch konkrete Ergebnisse liefern und Prozeßsignale sicher und richtig verarbeiten, daß sie aber immerhin ausfallen können.
Bei diesen Tasks werden Zwischenergebnisse nicht votiert, sondern nur verglichen. Die Fehlerquelle ist daher nicht eindeutig bestimmbar. Muß einmal eine Fehlerbehandlung vorgenommen werden, so gilt es bei diesen Tasks, mehrere Fälle voneinander zu unterscheiden.
Es kann einmal vorkommen, daß eine Datenrestaurierung vorgenommen wird, die einen ganzen Rechner und nicht nur eine spezifische Task betrifft; dann, so schreibt Demmelmeier, "sind die an diesem Rechner aktiven Klasse-2-Tasks miteinbezogen."
Kommt es hingegen zu einer Rekonfiguration des Systems, so wird die ausfallende Co-Task am Ersatzrechner aktiviert und der Datenbestand abgeglichen.
Wenn beim Vergleich von Zwischenergebnissen bemerkt wird, daß diese nicht miteinander übereinstimmen, so kann jeder der beiden beteiligten Rechner die Quelle des Fehlers sein, doch läßt sich nicht sagen, welcher wirklich defekt ist. In so einem Falle werden beide Co-Tasks abgebrochen und eine vielleicht fällige Ausgabe gegebenenfalls unterdrückt. Doch gilt es hier, wiederum zwei Fälle zu unterscheiden.
Liegt nämlich eine Task der Klasse 2a vor - übrigens: zu welcher Klasse eine Task gehört, muß der Programmierer schon bei Erstellen der Software explizit festlegen - , so wird ein Neustart durchgeführt. Bei einer Task der Klasse 2b hingegen wird die Task einfach als ausgefallen betrachtet. Übrigens der Neustart erfolgt auch nur, wenn der Code an einer Einheit (an einem Rechner) noch verfügbar ist.
Bei Tasks der Klasse 2 belasten Code und der reservierte Datenbereich jeden Rechner, der diese Klasse-2-Tasks tragen kann, statisch, während die dynamische Belastung allein auf die zwei Rechner beschränkt bleibt, die gerade für diese Task aktiv sind.
Die letzte Gruppe schließlich bilden die Tasks der Klasse 1, die dynamisch nicht-redundant laufen, die falsche Ergebnisse liefern können und die Prozeßsignale falsch verarbeiten können. Außerdem können sie ausfallen.
Diese Tasks sind in keine Datenrestaurierung einbezogen, und das hat natürlich zur Folge, daß eine Einheit, die unter Fehlerverdacht steht und bei der (für deren Tasks der Klassen 2 und 3) eine Datenrestaurierung vorgenommen wird, Tasks der Klasse 1 unter Umständen mit fehlerhaften; Daten weiterführt. Kommt es zu einer Rekonfiguration des, System, so muß man noch zwischen Tasks der Klassen 1a und 1b unterscheiden. Bei den ersteren wird ein Neustart durchgeführt, die letzteren hingegen fallen einfach aus; wobei der Neustart auch hier nur dann erfolgen kann, wenn der benötigte Code im Ersatzrechner vorhanden ist.
Bei Klasse-1-Tasks werden alle Einheiten, die den Start der Task überhaupt erlauben, statisch mit dem Code und dem Datenbereich belastet. Die dynamische Belastung hingegen beschränkt sich auf jene Einheit, die für die gegebene Task gerade aktiv ist.
Zwar ist hier bei weitem nicht genug Platz, um die konkrete Realisierung des Future-Systems mit seinen Task-Klassen in all ihren Details zu beschreiben, doch wenigstens das Verfahren der Prozessor-Zuteilung lohnt noch eine etwas genauere Darstellung. Denn es muß ja vor allem zwei Zielsetzungen gerecht werden: erstens soll es dafür sorgen, daß das Gesamtsystem sich sowohl für den Anwendungsprogrammierer als auch für den technischen Prozeß wie ein normaler, nicht-redundanter Prozeßrechner darstellt. Und zweitens muß die Fehlerbehandlung "stoßfrei" und mithin in äußerst kurzer Zeit erfolgen.
Diese erste Zielsetzung führt dazu, daß das Taskklassen-Konzept bei der Vergabe von Taskprioritäten keine Rolle spielen darf, denn beides sind voneinander logisch völlig unabhängige Dinge, beziehungsweise dazu, daß beim "Task-Scheduling" mit einer Strategie zu arbeiten ist, die sicherstellt, daß zum Beispiel eine mit hoher Priorität ausgestattete Task der - quasi "unsicheren" - Klasse 1 stets vor einer "sicheren" Task der Klasse 3, die aber von geringerer Priorität ist, bearbeitet wird.
Daneben besagt die zweite Zielsetzung im Effekt, man muß vermeiden, daß Co-Tasks, sollte ein Fehler bemerkt werden, erst noch langwierig synchronisiert werden müssen, ehe man die Restaurierung der Daten in Angriff nehmen kann. Da aber die Restaurierung der Daten synchronisierte Co-Tasks erfordert, ist es sinnvoll, von vornherein stets sicherzustellen, daß die Co-Tasks stets synchron laufen.
Das alles führt nun praktisch von selber zu einem Konzept, bei dem Tasks nur immer als vollständige Co-Task-Gruppen (synchron) gestartet beziehungsweise, kam es zu Unterbrechungen, fortgesetzt werden und bei dem, das sei hier noch ergänzt, der Scheduling-Mechanismus für die Prozessorzuteilung selber redundant auf allen (vier) Rechnern abläuft - mit anschließendem Votieren des Ergebnisses. Denn dieses Verfahren bewirkt automatisch eine regelmäßige, systemweite Überprüfung aller Rechner und sichert die Zuverlässigkeit des - im Zeitscheibenverfahren arbeitenden - Scheduling.
Außerdem bietet dieses Verfahren noch den Vorteil, daß die Fehlerlatenzzeit für Rechnerzusammenbrüche oder für andere leicht zu entdeckende Fehler auf eine Zeitscheibenlänge begrenzt ist. (Zur Erinnerung: Zeitscheibenverfahren bedeutet, daß die Prozessoren der Reihe nach allen "rechenwilligen" Tasks für eine bestimmte, von vornherein festgelegte Zeit, eben die "Zeitscheibe", zugeteilt werden. Dabei erfolgt die Zeitscheiben-Zuteilung reihum unter den Tasks gleicher Priorität; erst wenn die alle abgearbeitet sind, kommen die Tasks niedrigerer Priorität an die Reihe.
Demmelmeier umreißt die Aufgabe des synchronen Scheduling kurz so: Es diene dazu, "das Taskvorrangverhalten" eines Einrechnersystems nachzubilden und dabei dem Ziel des Taskklassen-Konzepts gerecht zu werden: bessere Nutzung der Systemleistung durch Parallelbearbeitung von Tasks." Denn das ergebe Vorteile in Form "kürzerer Verweildauern der Tasks beziehungsweise einer größeren Gesamtkapazität".
In der Praxis, und ganz besonders in der Praxis eines realen Systems mit nur vier Computern, treten allerdings Probleme auf, die hier nur noch knapp skizziert werden können und die damit zu tun haben, daß zum Beispiel dann, wenn gerade eine Task der Klasse 3 läuft, nur noch ein Rechner frei ist. Allenfalls paßt dann noch eine Task der Klasse 1 ins System, nicht aber noch eine der Klasse 3 oder auch 2.
Dieser Effekt kann dazu führen, daß die niederklassigen Tasks unbeabsichtigt mit einem gewissen "Vorrang" behandelt werden, was, so Demmelmeier, "einer indirekten Prioritätserhöhung gleichkommt".
Man kann diesem Effekt auf mehrerlei Weise begegnen, doch würde es hier zu weit führen, alle Möglichkeiten voll darzustellen. Die Forscher an der Münchner TU jedenfalls haben eine Lösung implementiert, die dafür sorgt, daß innerhalb aller Tasks gleicher Priorität die Tasks der höheren Klassen bevorzugt werden. Wie das hier beschriebene, übrigens in Modula-2 zu programmierende System Future praktisch genutzt werden kann, schildert Demmelmeier am Beispiel der Steuerung eines Hochregallagers, bei dem eine Task beispielsweise die Koordinierung aller Teilabläufe vornimmt, andere Tasks den Lagerbestand verwalten oder auch einen Roboter steuern und eine die Geschehen grafisch am Bildschirm darstellt. Dabei gehören in diesem Beispiel die erste und die zweite Task zur Klasse 3, die Robotersteuerung zur Task-Klasse 2b und die Bildschirm-Ansteuerung zur Klasse 1a. Letztere ist ja nur eine Komfort-Funktion, die getrost auch kurz einmal ausfallen kann.