Zufällige Hard- und Softwarefehler in sicherheitskritischen Systemen

Zufällige Fehler lassen sich in Tests schwer finden – und können die Stabilität oder Security sicherheitskritischer Systeme massiv gefährden. Mit LCLS gibt es aber eine bewährte Software-Architektur, mit der das zunehmend wichtige Problem von zufälligen Hardware- und Software-Fehlern gelindert werden kann.

Anbieter zum Thema

Axivion GmbH

RTI Real-Time Innovations

QNX Software Systems GmbH

Zum ersten Mal in der Geschichte nimmt die Zuverlässigkeit neuer, integrierter Hardware ab. Es ist heute zu erwarten, dass ein typisches Embedded-System etwa 20 Hardware-Fehlern pro Tag ausgesetzt ist. Es wäre unerträglich, so oft in den sicheren Zustand des Systems überzugehen. Deshalb muss man statt der Frage „Hat das Gerät einen zufälligen Fehler erlebt?” die Frage stellen: „Hat ein zufälliger Fehler die Sicherheit unseres Systems gefährdet?“

Seit den frühen 1990er Jahren hat die Datenspeicherindustrie ähnliche Probleme durch „Virtual Synchrony” (d.h. virtuelle Synchronität) gelöst. Dieser Beitrag beschreibt die Frage, inwiefern man die darunter liegenden Virtual Synchrony Algorithmen als Middlewarekomponente im Embedded-Bereich nutzen kann, um zufällige Fehler zu erkennen und zu behandeln. Obwohl die Frage im Rahmen der ISO 26262 beantwortet wird, so gilt die Antwort auch für andere sicherheitskritische Systeme.

Bildergalerie

Bildergalerie mit 5 Bildern

Die Bilder 1 und 2 zeigen ein abstrahiertes Embedded-System, z.B. für ein Auto. Der Unterschied zwischen den beiden liegt nur beim Standort des Überwachers. Verschiedene Sensoren sammeln externe Informationen (Geschwindigkeit, Ort, usw.) und der Berechnungskern nutzt diese Informationen, um die richtige Systemreaktion (Bremse betätigen, links abbiegen, Geschwindigkeit erhöhen, usw.) zu kalkulieren und die Aktoren zu steuern. Oft ist diese Berechnung mathematisch kompliziert und oft ist es unmöglich, das Berechnungsprogramm gemäß den Anforderungen von ISO 26262 zu entwickeln — vor allem wenn es aus schon existierendem Code besteht.

Um die Anforderungen von ISO 26262 zu erfüllen, benutzt man einen Überwacher (sog. „Safety Bag“ oder „Aktiv-Monitor“, siehe z.B. IEC 61508-3 (zweite Edition), 7.4.2.11). Dieses Programm ist viel einfacher als der Berechnungskern und kann z.B. gemäß ASIL C entwickelt werden. Wie in Bild 1 gezeigt, überwacht das Safety Bag die Eingabe der Sensoren und die Ausgabe des Berechnungskerns und entscheidet, ob die Ausgabe sicher ist. Natürlich kann der Überwacher die optimale Ausgabe nicht berechnen (dafür ist er zu einfach aufgebaut), aber er kann einen gültigen Wertebereich bestimmen und die Ausgabe des Berechnungskerns damit vergleichen.

In Bild 2 befindet sich der Überwacher zwischen dem Berechnungskern und den Aktoren. Liefert der Berechnungskern Werte, die der Überwacher als ungültig einstuft, ersetzt er die aktuellen Werte nicht durch optimale, sondern durch sichere Werte.

Probleme mit der heutigen Architektur

Die in den Bildern 1 und 2 gezeichneten Systeme sind bezüglich Hard- und Software-Fehlern sehr empfindlich, und um ein sicherheitskritisches System zu entwerfen, ist es wahrscheinlich notwendig, den Berechnungskern zu replizieren und deren Ausgaben zu vergleichen („voting“). Das erhöht die Komplexität des Systems - vielleicht müssen die Repliken sich synchronisieren und Informationen austauschen, vielleicht ist das Abstimmungssystem eine einzelne Fehlerstelle.

Aber das größte Problem ist, dass zwei unabhängige Aspekte des Systems miteinander verwoben werden: der Programmierer des Berechnungskerns muss die Zuverlässigkeit des Systems einkalkulieren und der Statistiker, der die Zuverlässigkeit betrachtet, muss die komplexen Algorithmen des Berechnungskerns verstehen.

Das resultierende System ist außerdem starr: Es ist unmöglich, die Zuverlässigkeitsstufe des Systems dynamisch zu ändern. Vielleicht sollte der Ausgleich zwischen Verfügbarkeit (1ooN - eins aus N) und Zuverlässigkeit (NooN - N aus N) vom Betriebszustand abhängen. Befindet sich ein Auto auf der Autobahn, ist die Verfügbarkeit des Systems wahrscheinlich wichtiger, als wenn es durch das Stadtzentrum fährt, wo die Zuverlässigkeit wichtiger ist.

Hardware „Lock-Step“ Prozessoren (d.h. im Gleichschritt) können solche Replikation unterstützen, aber sie bringen verschiedene Nachteile mit:

• Die Anzahl von Repliken ist von der Hardware festgelegt. Es ist unmöglich, diese Anzahl dynamisch zu ändern oder bei der Entwicklung zu wählen.

• Es ist unmöglich, diversifizierte Systeme zu implementieren: Hardware Locked-Step unterstützt nur Repliken. Wie in Bild 1 gezeigt, ist Diversifikation sehr nützlich: der Überwacher und der Berechnungskern behandeln identische Eingaben und können als diversifizierte Systeme betrachtet werden.

• Hardware-Gleichschritt schützt nicht gegen zufällige Softwarefehler (die sog. „Heisenbugs“). Solche Fehler werden in Multithreading-Architekturen immer wichtiger, aber wenn eine Instanz des Programms einem Heisenbug unterliegt, so fallen die anderen Instanzen gleichzeitig aus.

Es ist aber anzumerken, dass Gleichschrittverarbeitung für eines geeignet ist: der Entwickler muss nur eine Instanz der Applikation einplanen und braucht sich mit Replikation nicht zu beschäftigen. In diesem Beitrag geht es um die Frage, ob es möglich ist, die Vorteile des Gleichschritts zu behalten, aber die Nachteile zu vermeiden.

Überblick Virtual Synchrony (Virtuelle Synchronität)

Bild 3 zeigt im Überblick, wie sich Virtual Synchrony dem Entwickler präsentiert. Virtual Synchrony wurde 1987 von Ken Birman (Cornell Universität) eingeführt [1] und ist für viele unternehmenskritische Serverfarm-Applikationen benutzt worden. Virtual Synchrony wurde in [1] so beschrieben:

"In a virtually synchronous environment, routines can be programmed and will behave as if distributed actions were performed instantaneously and in lock-step. …. It will appear to any observer -- any process using the system -- that all processes observed the same events in the same order."

Das heißt, Virtual Synchrony bietet aus Sicht eines externen Beobachters einen Gleichschritt („Lock-Step“) Betrieb. Aber dieser virtuelle Gleichstritt leidet nicht unter den oben beschriebenen Nachteilen des echten (Hardware-)Gleichschritts. QNX nennt dieses Verfahren „Loosely-Coupled Lock-Step“ (LCLS) Verarbeitung (d.h. lose gekoppelter Gleichschritt).

Als LCLS-Komponente werden die Server (hier Berechnungskerne) in verschiedene Gruppen gelegt. Obwohl Leistungsverbesserungen daraus resultieren können, ist es nicht notwendig, dass die Server ihre Gruppenzugehörigkeit kennen. Ist diese unbekannt, so bietet diese Architektur die gesuchte Trennung zwischen der Entwicklung der Zuverlässigkeit und des Algorithmus.

Die Clients (Sensoren und Aktoren) kommunizieren nur mit der Gruppe: sie wissen nichts von den einzelnen Servern. Die LCLS-Middleware gewährleistet, dass alle Gruppenmitglieder mit dem aktuellen Zustand beginnen, und alle Client-Mitteilungen in der gleichen Reihenfolge geliefert werden.

Die heutigen Implementationen von Virtual Synchrony (z.B. Derecho von der Cornell Universität) können eine Riesenmenge von Daten über unzuverlässige Netzwerke behandeln. Aber in der Embedded-Welt hat man weit weniger Daten (von Sensoren), die über kurze Verbindungen (z.B. innerhalb eines Autos) übertragen werden müssen. QNX hat diese hierin beschriebene Entwicklung durchgeführt, um zu bestimmen, ob die Virtual Synchrony Algorithmen für die Embedded-Welt gelten.

Die Architektur mit LCLS erweitert

Die Bilder 4 und 5 erweitern die Bilder 1 und 2, um zu zeigen, wie diese Architekturen mit LCLS realisiert werden können. LCLS unterstützt mehrere Versionen der Berechnungskerne: entweder mehrere Instanzen oder diversifiziert entworfene Programme (z.B. derselbe Quellcode, aber mit verschiedenen Compilern kompiliert). In Bild 4 gehören nicht nur die Berechnungskerne, sondern auch die Überwacher, zu einer Gruppe. Sie empfangen genau dieselben Client- (Sensoren- und Aktoren-) Mitteilungen in der identischen Reihenfolge.

Bildergalerie

Bildergalerie mit 5 Bildern

Vielleicht geben die Berechnungskerne die optimale Antwort von 145.356 Newton als Bremsdruck aus. Die Überwacher sind viel einfacher aufgebaut und können so eine präzise Antwort nicht berechnen. Sie wissen aber, dass, angesichts der Sensoreneingaben jeder beliebige Wert zwischen 135 und 150 Newton sicher ist. Die Stimmenauszähler vergleichen die optimalen Werte und die sicheren Wertebereiche und betätigen bei einem sicheren Druckwert die Bremse.

Bild 5 zeigt, wie es möglich ist, die Berechnungskerne und Überwacher in verschiedenen Gruppen zu implementieren (um das Bild zu vereinfachen, sind der Kommunikationskanal und die verwandten Linien entfernt worden — sie sind Bild 4 ähnlich). In Bild 5 fungierten die Berechnungskerne nicht nur als Server (zu den Sensoren), sondern auch als Clients (zu den Überwachern). Eine solche Konfiguration wird durch Virtual Synchrony unterstützt. Die Überwacher treiben die Aktoren und liefern nur sichere Werte.

Es ist anzumerken, dass die in Bild 4 und 5 gezeichneten Komponenten aus Bild 1 und 2 fast unverändert bleiben. Die LCLS Architektur kann rückwirkend eingeführt werden. Weil Berechnungskerne und Überwacher sich jederzeit einer Gruppe anschließen oder eine Gruppe verlassen können, ist es möglich die Zuverlässigkeits- und Verfügbarkeitsstufen dynamisch zu ändern.

Zusammenfassung

Wir erwarten zufällige Software- und Hardware-Fehler in unseren Embedded-Systemen und die wichtige Frage ist nicht, ob ein solcher Fehler eingetreten ist, sondern ob er die Sicherheit beeinträchtigt hat. In der Einführung zu diesem Beitrag wurde die Frage gestellt: „Hat ein zufälliger Fehler die Sicherheit unseres Systems gefährdet?“.

Die Loosely-Coupled Lock-Step (LCLS) Architektur, basierend auf den Virtual Synchrony Algorithmen, adressiert diese wichtige Frage. Man kann die Anzahl von Instanzen der Server dynamisch wählen und es ist höchst unwahrscheinlich, dass ein zufälliger Fehler jeden Server zugleich stören würde. Weil LCLS nur „virtuellen“ Gleichschritt bietet, kann es gegen Software- sowie Hardware-Fehler schützen.

Um LCLS zu benutzen, wären wenige Änderungen des Codes nötig. Insbesondere trennt LCLS die Bereiche der zwei beteiligten Experten sauber: denjenigen des Entwicklers, der die mathematischen Algorithmen entwirft, und denjenigen des Entwicklers, der die ausreichende Zuverlässigkeit und Verfügbarkeit des Systems analysiert.

Zertifizierung: Ein Ansatz für ein modernes funktionales Sicherheitskonzept

Absicherung von Testsystemen nach ISO 26262

Dieser Beitrag wurde mit freundlicher Genehmigung des Autors dem Tagungsband des Embedded Software Engineering Kongress 2016 entnommen.

Literatur

[1] Birman K, Joseph T (1987) Exploiting Virtual Synchrony in Distributed Systems. ACM SIGOPS Operating Systems Review: Volume 21 Issue 5, November 1987.

​

* Chris Hobbs ist Kernel-Entwickler bei QNX Software Systems. Sein Fachgebiet ist „ausreichend verfügbare” Software: Software, in die mindestens so viel Entwicklungsaufwand gesteckt wurde, dass sie den Ansprüchen bezüglich Ausfallsicherheit und Zuverlässigkeit des Kunden gerecht wird.

(ID:44852435)