Sicheres Systemdesign
Zuverlässigkeit
und Verfügbarkeit
Über sichere Systeme nachzudenken, ohne die Umgebung zu berücksichtigen, in der diese betrieben werden, kann fatale Folgen haben. In diesem Beitrag betrachten wir am Beispiel eines hypothetischen Steuerungssystems für Zugführerstände die Balance zwischen Verfügbarkeit und Zuverlässigkeit der Sicherheitskomponente des Systems.
Eine Londoner U-Bahn fuhr vor einigen Jahren trotz geöffneter Türen ab, obwohl alle Systeme korrekt arbeiteten. Solche riskanten Zwischenfälle, die oft auf Bedienfehler zurückgehen, gilt es zu vermeiden. (Bild: sxc.hu)
Am 11. Juli 2011 fuhr ein U-Bahn-Zug der Victoria Line in London mit offenen Türen ab. Alle Systeme arbeiteten korrekt, aber der Zugführer hatte die Systeme in einer Weise bedient, die die Entwickler nicht vorhergesehen hatten. Jedes System interagiert auf zweierlei Art und Weise mit seiner Umgebung: Die Umgebung belastet das System mit unvorhergesehenen Anforderungen, und das System belastet mit seiner Reaktion seine Umgebung. Dieser Fachartikel untersucht solche Interaktionen und betrachtet die gegensätzlichen Ziele Zuverlässigkeit und Verfügbarkeit beim Systemdesign.
Eine Sicherheitsfunktion überwacht die Plausibilität des Hauptsystems. (Bild: QNX Software Systems Limited)
Verlässlichkeit
Bei einem softwarebasierten System ist Verlässlichkeit eine Kombination aus Verfügbarkeit (wie oft das System rechtzeitig auf einen Reiz reagiert) und Zuverlässigkeit (wie oft die Reaktion korrekt ist). Bei manchen Systemen ist Zuverlässigkeit wichtiger als Verfügbarkeit – keine Aktion ist besser als die falsche Aktion, während bei anderen Systemen Verfügbarkeit wichtiger ist – jede plausible Reaktion ist besser als gar keine Reaktion.
Das 1oo2-System: Solange eines der Subsysteme keine Betriebsfreigabe erteilt, verbleibt das Steuerungssystem in seinem Design Safe State. (Bild: QNX Software Systems Limited)
Design Safe States
Unabhängig davon, ob für ein gegebenes System Verfügbarkeit oder Zuverlässigkeit wichtiger ist, muss das System auf jeden Fall in gefährlichen Situationen auf definierte Weise agieren. In der Regel muss es in seinen Design Safe State wechseln. Dabei handelt es sich um einen klar definierten Zustand eines Systems, in den es wechselt, wenn es seine vorgesehenen normalen Funktionen nicht mehr korrekt ausführen kann, oder es nicht bestätigen kann, dass es dies gerade tut. Für die Sicherheit ist der Design Safe State also enorm wichtig. Leider vernachlässigen Entwickler jedoch zu oft die Auswirkungen, die ein Wechsel ihres Systems in den Design Safe State auf die weitere Umgebung hat, in der ihr System betrieben wird. Die meisten komplexen Systeme sind aus integrierten Subsystemen aufgebaut. Die einzelnen Subsysteme werden oft ohne tiefere Kenntnis der übergeordneten Systeme entwickelt, in die sie später integriert werden. Datenbanken, Betriebssysteme, Protokoll-Stacks und ähnliche Komponenten werden nicht im Hinblick auf ein konkretes System entwickelt. Dr. Martyn Thomas machte auf dem Safety-Critical Systems Symposium 2012 auf sogenannte Accidental Systems aufmerksam – Systeme, deren Entwickler sich nicht über versteckte Abhängigkeiten zwischen Komponenten aus unterschiedlichen Quellen bewusst waren, bei denen diese Abhängigkeiten also unbeabsichtigt (accidentally) entstanden sind. Das Verhalten eines solchen Gesamtsystems in unvorhergesehenen Situationen ist sehr schwer zu berechnen, da es abhängig ist von vielen, größtenteils voneinander unabhängigen Komponenten, die ggf. in ihren jeweiligen Design Safe State wechseln. Und selbst wenn unser komplettes System reibungslos in seinen Design Safe State wechselt, so ist es doch wahrscheinlich Teil eines übergeordneten Systems, welches nun zusätzlich belastet wird.
