Die Entwicklung von fehlertoleranten Systemen auf dem Hardwaresektor (Fault Tolerant System) ist gegenüber fehlertoleranten Softwaresystemen erheblich weiter fortgeschritten. Einen hohen Bekanntheitsgrad haben die sogenannten "Redundanten Systeme" erzielt.

Dabei sind für den Systembetrieb relevante zentrale Systemkomponenten zwei- und mehrfach vorhanden. Bei Ausfall einer Systemkomponente wird die Ersatzkomponente ohne Beeinträchtigung des Anwendungsbetriebes aktiviert. Was die Ablaufsicherheit und Fehlertoleranz von Betriebssystemen betrifft, sind die entsprechenden Maßnahmen wesentlich komplexer angelegt und hinsichtlich ihrer Effizienz unterschiedlich wirksam.

Die Anforderungen an die Softwarequalität gewinnen angesichts des vielfältigen Angebotes immer mehr an Bedeutung. Dies gilt sowohl für das Betriebssystem als auch für Anwendungssoftware. Hierbei müssen zwei Hauptgruppen von Qualitätskriterien unterschieden werden:

- Ablaufsicherheitskriterien und

- Nutzwertkriterien.

Während unter dem Begriff Ablaufsicherheit Merkmale wie Software-Zuverlässigkeit, Verfügbarkeit, Wartungsfreundlichkeit und Fehlertoleranz zusammengefaßt werden, sind aus Sicht der Softwareanwendungen Nutzwertkriterien wie Flexibilität, Handhabung, Vollständigkeit, Laufzeitverhalten, Benutzerfreundlichkeit, Ausbaufähigkeit und vieles mehr zu verstehen. Die Ablaufsicherheit der Software ist eine unerläßliche Voraussetzung für eine weitergehende Qualitätsbeurteilung. Funktionalität und Benutzerkomfort der Software sind aus Sicht des Anwenders augenfällige Merkmale, deren Nutzen im Arbeitsablauf durch Systemstörungen und Ausfälle wesentlich beeinträchtigt werden können (Zeitverlust).

Rechner- und Betriebssystemqualität bilden somit eine wesentliche Grundlage für den DV-Anwendungsbetrieb. Von seiten des Herstellers wurden (und werden) umfangreiche Maßnahmen getroffen, um eine höchstmögliche Systemverfügbarkeit zu erzielen. Schon beim System- und Softwaredesign wurden Vorkehrungen zur Erhöhung der Verfügbarkeit integriert. Entwicklungskonzepte und -strategien verfolgen dabei das Ziel, sogenannte fehlertolerante Systeme hardware- und softwaremäßig bereitzustellen.

Ein System - bestehend aus Hard- und Software - verhält sich dann bis zu einem gewissen Grad fehlertolerant, wenn bei Auftreten vorhersehbarer Fehler das System durch eingeplante Maßnahmen weiterarbeiten kann, ohne den Verarbeitungsablauf zu stören. Die bisherige Basis für die Entwicklung fehlertoleranter Softwaresysteme stellt das sogenannte RAS- oder RAM-Konzept dar. Es umfaßt drei Softwarestrategien zur Ablaufsicherung:

- R = Reliability = Zuverlässigkeit

Damit wird bereits bei der System programmierung sichergestellt, daß die Betriebssystemfunktionen stetig und eindeutig gemäß Ablauflogik arbeiten (korrekte Arbeitsweise).

- A = Availability = Verfügbarkeit

Diese Strategie verfolgt eine permanente Systembereitschaft unter zeitkritischen Gesichtspunkten. Um beispielsweise eine nahezu 100prozentige Systemverfügbarkeit zu erzielen, muß selbst bei Softwarefehlern der Systembetrieb aufrecht erhalten bleiben (fehlertolerantes Systemverhalten).

- S/M = Serviceability/Maintainability = Wartungsfreundlichkeit

Die Vielzahl der bisher erkannten Fehlerarten im System macht es notwendig - über die bisherigen Ablaufsicherheitsstrategien hinausgehend - unvorhersehbare Fehler und solche, die vom System nicht unmittelbar umgangen werden können, durch externe, unverzügliche und wenig aufwendige Eingriffe zu beheben. Das heißt, der dann notwendige Wartungsaufwand soll durch entsprechend vorbereitete Maßnahmen minimiert werden.

Die praktischen Erfahrungen mit dem RAM-Konzept haben in der Vergangenheit bewiesen, daß "der Teufel im Detail sitzt". Eine weitere Differenzierung der Ablaufsicherheitsanforderungen in Richtung fehlertolerantes Systemverhalten wurde vorgenommen. Thomas Howell, Mitarbeiter der Honeywell-Produktentwicklung, hat ein erweitertes RAM-Modell entworfen, das die unterschiedlichen Anforderungen an fehlertolerante Softwaresysteme klassifiziert. Es werden fünf sich überlappende und ergänzende Kategorien genannt:

- immanente Programm-Zuverlässigkeit,

- Software-Integrität,

- fehlertolerantes Design,

- wartungsfreundliches Design,

- Wartungsstrategie.

Eine immanente Programm-Zuverlässigkeit läßt sich erzielen, wenn man bereits im Vorfeld der Programmentwicklung Verfahren, Methoden und Programmiersprachen verwendet, die unter der Prämisse logischer Korrektheit (Eindeutigkeit, Plausibilität) entworfen werden. Diese Programmierungsgrundlagen sorgen ferner dafür, daß die eigentliche Programmentwicklung korrekt erfolgt und unmittelbar verifizierbar ist.

Ein System gilt dann als zuverlässig, wenn seine Programme eine korrekte und vollständige Implementierung der gestellten Systemanforderungen sicherstellen. Für die Strategie der Software-Zuverlässigkeit wurden in der Vergangenheit bereits umfangreiche kostspielige und zeitaufwendige Investitionen getätigt. Folgende Ergebnisse dieser Anstrengungen liegen vor:

- formale Entwurfsmethoden und Anforderungsanalyse (requirements engineering),

- Techniken zur strukturierten Programmierung,

- formale und informale Programm-Verifikation (Korrektheitsbeweise),

- Programmiersprachen, die mit dem Hauptziel korrekter Programmlogik entwickelt wurden (zum Beispiel ADA),

- variabel wiederverwendbarer Programm-Code,

- umfassende Testverfahren,

- Verfahren zur Qualitätssicherung,

- nichtautomatische, extern initiierte Testmethoden (reviews, walkthroughs),

- Projektmanagement-Methoden,

- eine wissenschaftliche Theorie zur Software-Zuverlässigkeit.

Der Ansatz dieser Ablaufsicherheitsstrategie liegt im systemnahen oder maschinenorientierten Bereich zwischen Hardware und Software. Der Hersteller berücksichtigt bereits beim Rechner- und Systemsoftware-Entwurf Maßnahmen (eingebaute Funktionen) zur Überwachung und Verifizierung eines korrekten Programmablaufs.

Eine entsprechende Maßnahme auf Hardwareebene ist die Paritätsprüfung. Software-Integrität kann nur dann erreicht werden, wenn schon beim Systemdesign bestimmte Funktionen eingebaut werden; dies wären Prüfsummenverfahren, wie beispielsweise spezifische Datenredundanz, doppelt-verkettete Systemtabellen, obgleich für den verwendeten Algorithmus bereits eine einfache Verkettung genügen würde. Weiter zählen dazu Coderedundanz: Bestimmte Berechnungen und logische Operationen werden doppelt oder mehrfach mit verschiedenen Algorithmen ausgeführt, um die Ergebnisse auf Gleichheit zu überprüfen. Auch Plausibilitätsprüfungen (Grundregeln, mit denen die Korrektheit von Algorithmen verifizierbar ist) und Datenprüfungen (unter anderem Gültigkeitsprüfungen der Eingabedaten und Parameter) sind hier zu erwähnen.

Diese Integritätsprüfungen sind in Fachkreisen teilweise umstritten. Ihre Gegner sind der Meinung, daß eine ausreichende Software-Zuverlässigkeit bereits mit den erstgenannten Verfahren, Methoden und Programmiersprachen erzielt werden könne. Als weiteres Gegenargument wird die systemdurchsatzmindernde Verwendung von Integritätsprüfungen angeführt. Doch diese Gegenargumente berücksichtigen nicht das beobachtbare Phänomen der Fehlerausbreitung und -fortpflanzung, das durch hardwarenahe Integritätsprüfungen kontrolliert und begrenzt werden kann.

Daher sind die Software-Integritätsprüfungen wichtige Voraussetzungen für die beiden folgenden Kriterien zur Ablaufsicherung des Systems: fehlertolerantes und wartungsfreundliches Design.

Unter Fehlertoleranz versteht man eine Systemeigenschaft, bei der mit dem Auftreten eines Hardware- oder Softwarefehlers der Systemablauf nicht gestört wird und somit die laufenden Anforderungen an das System vollständig erfüllt werden. Softwarefehler können bereits durch die Integritätsprüfungen entdeckt werden, doch für die Entdeckung und Tolerierung von Hardwarefehlern sind andere Maßnahmen erforderlich, die hier der Vollständigkeit halber kurz genannt werden sollen.

Hardwarefehlertolerante oder ausfallsichere Computer sind gegenüber fehlertoleranten Softwaresystemen wesentlich weiter entwickelt. Die Strategie besteht prinzipiell darin, das fehlerhafte Bauteil zu identifizieren, es stillzulegen und statt dessen mit einer redundanten Hardwarekomponente weiterzuarbeiten. Bei der Verwichlichung solcher Alternativmaßnahmen oder Umgehungslösungen mit Hilfe redundant angelegter Hardware müssen allerdings entsprechende Routinen bereits im Systemsoftwaredesign vorgesehen sein, die die Hardwarefehler systemtopologisch identifizieren und eine Rekonfigurierung des Systems unter Verwendung der entsprechenden redundanten Komponente durchführen.

Daß dies unter Umständen ein sehr komplexes Ablaufgeschehen ist, kann man sich leicht bei Ausfall eines Prozessors vorstellen. Der aktuelle Systemstatus mit allen Registern, Verwaltungstabellen und so weiter muß gerettet werden, damit auf dem redundanten Prozessor der Systembetrieb fehlerfrei fortgesetzt werden kann.

Zur theoretisch angestrebten Fehlertoleranz von Softwaresystemen fehlen bislang noch eine allgemeingültige, vollständige Systemtheorie und weitere Techniken, die alle vorhersehbaren Fehlertypen behandeln und Systemstörungen ausfallsicher überbrücken. Die theoretische Grenze eines absolut ausfallsicheren Systems wird sicherlich nicht in der Praxis erreicht, wenn auch externe Störfaktoren wie versehentliches Auslösen von Brandschutzanlagen und ähnliches berücksichtigt werden. Doch schon heute können mit den vorhandenen und implementierten Verfahren und Techniken eine Ausfallsicherheit oder Systemverfügbarkeit von mehr als 99 Prozent erreicht werden.

Aufgrund umfangreicher Fehlerstatistiken und -analysen des gesamten Systemverhaltens sind bestimmte Fehlerarten bis zu einem gewissen Grad vorher bestimmbar. Basierend auf diesen Erkenntnissen werden bei der Systemsoftwareentwicklung, also schon in der Design-Phase, Fehlerbehandlungsroutinen vorgesehen. Soweit wie möglich wird geprüft, ob im Fehlerfalle Umgehungsmöglichkeiten gefunden werden können, damit der Betrieb aufrecht erhalten bleibt. Wenn dies nicht möglich ist, werden ohnehin alle für die Fehlerbehebung notwendigen Systemdaten in Fehlerprotokollen festgehalten und das System mit entsprechenden Fehlermeldungen unterbrochen.

Immer wieder auftretende Ausnahmesituationen sind bekannt und können von zentralen Fehlerbehandlungsroutinen abgefangen werden. Dazu zählen unter anderem Division durch Null, Adressierungsfehler, Abschalten von Terminals. Viele Betriebssysteme und Programmiersprachen unterstützen diese Art der fehlertoleranten Programmierung durch spezielle Sprachelemente; als Beispiel sei die "ON-condition"-Klausel in PL/1 genannt. Dies ist natürlich nicht möglich bei Fehlern, die individuell behandelt werden müssen, aber die Fehlerhinweise von der Systemsoftware (wie Compiler) können soweit präzisiert werden, daß aufgrund einer Fehlerlokalisierung eine zügige Fehlerbehebung möglich wird.

In solchen Fällen erlangen Dienstprogramme große Bedeutung, die den Benutzer bei der Fehlerdiagnose und der Fortsetzung seiner Arbeit unterstützen. Dazu werden beispielsweise Speicherauszüge (Dumps) sowie alle Wiederherstellungs- und Neustarteinrichtungen (Recovery and Restart) gezählt. Die letztgenannten, bereits weit verbreiteten Dienstprogramme können sicherlich nicht als Merkmale fehlertoleranter Systeme im engeren Sinne gezählt werden. Sie leisten jedoch einen wichtigen Beitrag für ein wartungsfreundliches Design - eben aufgrund systemunterstützter Problemanalyse eine schnelle Fehlerbehebung.

Ein wartungsfreundlich entworfenes Softwaresystem ist mit Eigenschaften und Einrichtungen ausgestattet, die die Fehlerdiagnose und -behebung wesentlich erleichtern.

Sie können in die fehlertolerante Zielsoftware selbst eingebettet oder als unabhängige Dienstprogramme vorhanden sein. Wartungsfreundlichkeit ist gleichermaßen eng mit den Merkmalen Software-Integrität und fehlertolerantes Design verknüpft. Das bedeutet, daß ein aufgrund einer Integritätsfunktion entdeckter Fehler idealerweise zum Abruf eines Fehlerdiagnoseprogramms führt. Daneben gibt es auch präventiv arbeitende Werkzeuge zur. Fehlerdiagnose; sie werden nicht beim Auftreten eines Fehlers aktiviert, sondern sammeln während des Systembetriebs kontinuierlich bestimmte Daten, die man bei Bedarf abruft.

Wartungsstrategien werden durch die verfügbaren Wartungsfunktionen zwar unterstützt, aber nicht umfassend bestimmt. Diese Konzepte sind im Unterschied zu den anderen Kategorien keine Angelegenheit des Software-Designs. Eine solche Strategie für ein Softwaresystem besteht aus Vorschriften und Verfahrensweisen, die man festschreibt, um Fehlerdiagnose, Fehlerbehebung und Softwareaustausch einheitlich durchzuführen. Zu den typischen Elementen einer Wartungsstrategie gehören:

- Festlegung einer Meldeprozedur von Softwareproblemen durch die Benutzer;

- Validierung, Klassifizierung, Protokollierung und Verfolgung von Softwareproblemen;

- Festlegung von Medium und Format für Fehlerkorrekturen;

- Häufigkeit von Korrekturen/neuen Versionen;

- geographische Verteilung der Softwarespezialisten

- Grad der Unterstützung eines Produkts;

- Festlegung des Kostenanteils für die Benutzer an der Softwarewartung und -pflege.

An die Festlegung der Wartungsstrategie wird im Softwareentwicklungszyklus häufig viel zu spät gedacht. Im schlimmsten Fall kann dieses Versäumnis ein ansonsten reifes Produkt in Mißkredit bringen.

Das in Richtung Software-Fehlertoleranz erweiterte RAS/RAM-Konzept hat sicherlich noch nicht den Realisierungsgrad erreicht, wie er von Praktikern und Anwendern in Zukunft erwartet wird. Doch wichtige Entwicklungsschritte in Richtung fehlertoleranter oder ausfallsicherer Softwaresysteme sind bereits heute getan, auf deren Grundlage erst eine Weiterentwicklung möglich wird. Die Softwareentwickler - insbesondere von Betriebssystemen - müssen heute die genannten Software-Entwicklungsstrategien für fehlertolerante Softwaresysteme ohne Einschränkung in ihr Entwicklungskonzept einbeziehen, wenn sie nicht Gefahr laufen wollen, daß ihre Software eines Tages nicht mehr diesem wachsenden Anspruch genügt.

Volker Zdunnek ist leitender Marketing-Spezialist für Großrechnersysteme bei Honeywell Bull in Köln-Porz.