Die Hauptsätze der System-Zuverlässigkeit

Uptime Engineering > Blog > Die Hauptsätze der System-Zuverlässigkeit

Im Gegensatz zu Lebewesen reparieren sich technische Systeme nicht selbst. Vielmehr gehen sie kaputt, und zwar um so wahrscheinlicher je komplizierter sie sind und je unterschiedlicher sie verwendet werden.

Alles, was existiert, kann kaputt gehen.

Das klingt trivial.

Wenn es das wäre, dann wären technische Systeme möglichst einfach. Wenn man aber aktuelle Systemarchitekturen analysiert, stellt man fest, dass sie das ganz und gar nicht sind. Systemarchitekturen sollten in Hardware und Software schlank, einfach und modular sein. Dagegen sehen wir einen generellen Trend zu integrierten Funktionsmonstern mit entsprechender Komplexität. Jedes zusätzliche Element eines Systems bringt aber Ausfallsrisiken und zusätzliche Wechselwirkungen mit sich.

Je komplizierter ein System ist, desto aufwändiger wird die Identifikation, Bewertung und Beseitigung dieser Risiken. Wir sehen das z.B. am exponentiellen Anstieg der Software-Fehlerhäufigkeit in der Auto-Industrie. Für komplexe Systeme ist die Beseitigung aller Risken prinzipiell unmöglich. Daher stammen wohl viele der Probleme beim autonomen Betrieb von Anlagen und Fahrzeugen.

Hierher gehört auch das Raketenproblem.

Selbst wenn ein System nicht in Betrieb ist, kann es kaputt gehen, z.B. durch Korrosion oder Alterung. Solange es aber stillsteht, lässt sich kaum ermitteln, ob es funktionieren wird. Vom elektrischen Kontakt am Startschalter bis zur Navigationssoftware muss eine Serie von Mechanismen beim Raketenstart funktionieren. Das Produkt auch nur geringer Unzuverlässigkeiten in dieser Kette führt zu den bekannten Problemen der Raumfahrt.

Die Sensorik ist Teil des Systems.

Das muss bei Sensorik-Konzepten zur System-Überwachung mitberücksichtigt werden. Viel von der System-Charakterisierung ist ohnehin aus der System-Regelung verfügbar. Sensor-Ergänzungen müssen sich jeweils rechtfertigen, primär durch die Überdeckung von Risiken.

Sensoren müssen jedenfalls deutlich zuverlässiger sein als das überwachte System. Weil das aber oftmals nicht der Fall ist, tragen Sensorfehler erheblich zu Fehlalarmen bei und erodieren die Nutzerakzeptanz. Redundanz löst dieses Problem nur mit hohen Kosten und Wartungsaufwänden.

Alles, was kaputt gehen kann, geht auch kaputt.

Man kann Entwicklungsprojekte als systematischen Prozess zur Risiko-Beseitigung betrachten. Trotz hoher Aufwände entlang der Absicherungskette überleben aber stets einige der Risiken. Sie führen erst bei den repräsentativen Tests am Gesamtsystem zu Ausfällen und geben darüber Auskunft, was bisher unbekannt war oder fehlbewertet wurde. Wenn dieser Lernimpuls zeitgerecht kommt, ist das ist trotzdem der günstige Fall. Ansonsten treten a-priori unbekannte Fehlermechanismen erstmals beim Kunden auf, im schlimmsten Fall als Serienschaden. Auch dafür gibt es vielfältige Beispiele.

Konsequenzen:

  • Man sollte keine unbeaufsichtigten Anlagen mit Gefährdungspotenzial anlegen, also z.B. keine Atommüll-Endlager ohne permanente Überwachung.
  • Reparierbarkeit und Testbarkeit muss im System mitkonstruiert werden.
  • Modularität ist für die Beseitigung von Schwachpunkten anzustreben.
  • Die Risiko-fokussierte Systemüberwachung sollte Teil der Produkt-Architektur sein.
  • Es kann technisch-wirtschaftlich vernünftig sein, Teile vorsorglich zu tauschen, statt sie auf maximale Zuverlässigkeit und Lebensdauer zu optimieren.

Zuverlässigkeit ist eine Systemeigenschaft.

Die Systemzuverlässigkeit lässt sich nicht modularisieren.

Die Komplexität von Systemen wird in der Regel durch ihre Zerlegung in Sub-Systeme oder Module adressiert. Jedes Modul wird auf die vorgegebenen Anforderungen hin konstruiert, entwickelt, gefertigt und montiert.

Auch die Zuverlässigkeit der Module lässt sich bis zu einem gewissen Grad so nachweisen. Wechselwirkungen lassen sich auf den adäquaten Integrationsstufen eines Systems behandeln.

Die Systemzerlegung erzwingt aber technische und organisatorische Schnittstellen. Letztere entstehen an den Phasengrenzen des Produkt-Lebenszyklus. Diese Schnittstellen wirken als Informationssenken. Sie bilden daher die Brennpunkte der Unzuverlässigkeit.

Der Mensch ist ein Teil des Systems.

Wenn Experten ihr System bedienen, läuft alles „wie geschmiert“. Allerdings nur so lange, wie sie nicht glauben, klüger zu sein als das System. Sonst wäre die Tschernobyl-Katastrophe nicht passiert.

Praktisch jede Begrenzung des Nutzungsraums eines Systems lässt sich überlisten, denn die Sicherheitsarchitektur wurde ja nicht von einer überlegenen Superintelligenz geschaffen. Es braucht in der Regel gar keine kriminelle Energie. Normale Wartungstätigkeiten erzeugen relativ häufig einen Systemzustand, der nicht dem Soll entspricht. Das führt zu Folgeschäden oder zu wiederkehrenden Ausfällen mitunter aber auch zu Katastrophen, wie z.B. beim Reaktorunfall Three Mile Island.

Nutzer machen mit dem System etwas, woran der Konstrukteur nicht dachte, oder sie machen es so, wie er es nicht dachte. Dann geht auf Dauer etwas schief:

Luxus-Autos werden vor Luxus-Hotels im Leerlauf betrieben, damit die Klimaanlage permanent kühlt. Das versottet das Ölsystem und ruiniert den Motor. Die Leute steigen hauptsächlich vorne oder hinten in die U-Bahn. Diese Türen öffnen deutlich häufiger, sind daher unzuverlässiger als ihre Nachbarn. Schmutzwäsche wird auf der offenen Tür der Waschmaschine gestapelt. Sie wird dadurch undicht.

Größere, langlebige technische Systeme funktionieren nur mit einem professionellen Instandhaltungs-Prozess. Wenn Experten ein Instandhaltungs-Team verlassen, nehmen sie ihr implizites Wissen mit. Deswegen treten danach Probleme auf, die vorher unbekannt waren.

Konsequenzen:

Uptime Pfeil Icon

Ein System ist mehr als die Summe seiner Teile. Es muss daher auch als Ganzes im ganzen Lebenszyklus entwickelt und behandelt werden.

Uptime Pfeil Icon

Organisatorische Schnittstellen im Lebenszyklus müssen organisatorisch verklammert werden.

Uptime Pfeil Icon

Ein System ist aus verschiedenen Nutzer-Perspektiven zu denken.

Uptime Pfeil Icon

Risiken durch unbeabsichtigte Nebenwirkungen von Eingriffen ins System müssen strukturiert behandelt werden.

Uptime Pfeil Icon

Der Instandhaltungsprozess sollte als Generator für Systemwissen behandelt werden.