Selbstfahrende Autos, Fahrerlose Autos, Autonomes Fahren, Straß

Selbstfahrende Autos, Autonomes Fahren, fahrerlos, Straßenverkehr, Autofahren, Fahrer, Autopilot, Autofahrer, Assistenzsystem, KfZ, hochautomatisiert, System, Assistenz, selbstfahrend, Auto, Autos, Einparkhilfe, Mobilität, autonome Mobilität, Spurhaltefunktion, Stau, Stauassistent, selbstfahrendes Kraftfahrzeug, autonom, Tempomat, Verkehrsschild, Schild, Achtung, Warnung, Gefahr, Unfall, Symbol, symbolisch, automatisches Fahren, automatisiertes Fahren, automatisch, Modus, automatisiert, Automatisierung, Roboter, LKW, PKW, Automobil, Fahrzeug, Autohersteller, Transport, Transportsystem, Fahrbetrieb, Fahrerassistenzsystem, Hamburg, Mai 2016, Bild Nr.: N53119I1 (Bild: nmann77 – Adobe Stock)

Um zu erkennen, warum Software-Lockstep eine interessante Lösung ist, sollte man die Problemfaktoren Physik und Komplexität näher betrachten. Stichwort Physik: Es gibt CPUs, die mit immer höheren Taktgeschwindigkeiten laufen und dabei mehr Wärme erzeugen, jedoch gleichzeitig mit kleineren Transistoren arbeiten, was sich mittlerweile über die Anzahl der Atome messen lässt. Wärme führt zu einem schnelleren Verschleiß, denn je heißer das Bauteil im Betrieb wird, desto früher fällt es aus. Verkleinerte Chips wiederum bedingen Transistoren, die extrem anfällig für Fehler sind, die durch elektromagnetische Störungen, die Auswirkungen von Alphateilchen und Neutronen sowie durch Übersprechen bei benachbarten Zellen hervorgerufen werden. Diese Probleme treten auch in DRAM-Systemen auf; bei modernen DRAMs mit mehreren Gigabyte gehen Experten dabei von Bitfehlern in einer Größenordnung von einem Fehler pro Stunde aus.

Software-Lockstep ermöglicht das Erkennen von Zufallsfehlern beim automatisiertes fahren.

Software-Lockstep ermöglicht das Erkennen von Zufallsfehlern. Fotolia

In Sachen Komplexität lässt sich konstatieren, dass die Hersteller immer mehr in Wechselbeziehung zueinander stehende Funktionen zu den einzelnen CPUs hinzugefügt haben. Leider enthalten CPUs Fehler, von denen viele erst gefunden werden, nachdem der Chip bereits in die Produktion gegangen ist; bekannte Fehler dokumentieren die Hersteller dabei in ihren Fehlerverzeichnissen. Solche Fehler können die Berechnungen beeinträchtigen und zu fehlerhaften Ergebnissen führen – und damit Sicherheitsschwachstellen schaffen. Die Wahrscheinlichkeit derartiger Fehler wirkt sich unmittelbar auf die ASIL-Einstufung gemäß ISO 26262 aus.

Überprüfung

Um solche Fehler zu erkennen und zu überwinden, müssen Systementwickler Kompensationsmechanismen implementieren. Ein möglicher Ansatz hierbei ist, dass das System jede Berechnung mindestens zweimal durchführt und dann die Ergebnisse vergleicht. Einige Mikrocontroller nutzen eine Technik, die unter dem Namen „Hardware Lockstep“ bekannt ist. Hierbei führen zwei CPUs gleichzeitig die gleichen Anweisungen aus, und eine spezielle Hardware vergleicht die Ergebnisse. Wenn die Hardware eine Abweichung entdeckt, ermittelt eine unabhängige Diagnose-Routine, welche CPU fehlerhaft war, und die Systemsoftware ergreift daraufhin Abhilfemaßnahmen. Leider unterstützt diese Technik in der Regel nur Repliken und keine verschiedenen Implementierungen. Zudem kann sie keine Softwarefehler erkennen – schließlich führen beide CPUs den fehlerhaften Code „korrekt“ aus – und sie ist nicht skalierbar, da die Anzahl der Repliken von der Hardware fest vorgegeben ist. Weiterhin ist diese Technik für die heutige Hochleistungshardware nicht sonderlich praktisch, da es bei einer Hardwareprüfung viel zu viele Informationen zum internen Status zu überprüfen gibt.

Eckdaten

Dieser Beitrag beschreibt eine Architektur, die eine äußerst flexible und dynamische Methode zum Erkennen von Zufallsfehlern darstellt, die die Sicherheit eines Systems beeinträchtigen. Dem liegt als tragendes Prinzip die feste Zuordnung von Ereignissen zu allen Mitgliedern einer Servergruppe zugrunde. Damit steht praktisch ein Software-Lockstep zur Verfügung, der nicht den Beschränkungen des Hardware-Lockstep unterliegt. Da die Serverinstanzen den Gruppen dynamisch beitreten und diese wieder verlassen können, kann der Grad der Widerstandsfähigkeit auf die Umgebung abgestimmt werden, in der das System aktiv ist. Wenn beispielsweise ein Fahrzeug auf einer Autobahn unterwegs ist, kann ein anderer Grad von Widerstandsfähigkeit erforderlich sein als bei einer Fahrt in einem Stadtzentrum.

In der Praxis kann ein System mittels Software die Funktion der Hardware überprüfen. Hierbei implementiert der Entwickler eine replizierte Kopie der Software, und mithilfe der zwei oder mehr Repliken wird dann die Überprüfung vorgenommen. Jede Replik führt sicherheitskritische Berechnungen durch – zum Beispiel „Kann unter diesen Bedingungen beschleunigt werden?“ – und Middleware nimmt die Berechnungen mit für die Anwendung unsichtbaren Synchronisationspunkten vor.

Jedes Replikationsmodell hat seine Vor- und Nachteile. In dem Modell mit der identischen Replikation ergeben zwei identische Berechnungen auf unterschiedlichen Threads mit unterschiedlichem Speicher das gleiche korrekte Ergebnis – es sei denn, ein vorübergehender Hardware- oder zufälliger Softwarefehler tritt auf. In diesem Fall betrifft der Fehler nur eine der Instanzen, aber nicht beide. Wenn es nur zwei Repliken gibt, ist irgendeine Form der Fehlerbehebung erforderlich, da hier nicht ermittelt werden kann, welche Replik richtig arbeitet. Gibt es mehr als zwei Repliken, dann kann das Mehrheitsergebnis verwendet werden.

Natürlich lassen sich mit diesem Vorgehen zwar die schwer zu fassenden Heisenbugs in der Software erkennen und kompensieren, aber eine Behebung von Bohrbugs in der Software ist damit nicht möglich. Um dies zu ermöglichen, könnte ein System „Bruderrepliken“ (Fraternal Replicas) verwenden, die die gleichen Berechnungen durchführen, dabei aber unterschiedliche Algorithmen verwenden. Wenn diese Repliken zu dem gleichen Schluss kommen und sich zum Beispiel beide einig sind, dass beschleunigt werden kann, ist das allgemeine Vertrauen in die Richtigkeit des Ergebnisses größer.

Thema auf der nächsten Seite: Implementierung einer Replikation.

Implementierung einer Replikation

Autonomes Fahren

Automatisiertes Fahren benötigt funktionale Sicherheit, die sich mit einem replikbasierten System erzielen lässt. Fotolia

Ein Systementwickler kann die Replikationen mithilfe von Middleware, die in den Kommunikationspfad zwischen den Komponenten eingefügt wird, transparent implementieren. Bei einem Microkernel-Betriebssystem, in dem alle Softwarekomponenten über Nachrichtenweitergabe miteinander kommunizieren, kann der Entwickler die natürlich vorhandenen Synchronisationspunkte nutzen. Diese erleichtern das Einfügen der Middleware und deren Überprüfung des Subsystembetriebs. In einem typischen microkernel-basierten System erbringt ein Serverprozess Dienste für seine Clients.

Um sicherzustellen, dass der Dienst zuverlässig und verfügbar ist, verwendet ein replikbasiertes System mehrere Instanzen des Servers. Die Middleware soll dabei sicherstellen, dass Systemereignisse wie Anfragen von Clients an alle Serverinstanzen in genau derselben Reihenfolge weitergeleitet werden. Aus der Perspektive des Clients scheint es nur einen Server zu geben; aus der Perspektive des Servers wiederum sieht es so aus, als führe er allein die Prozesse aus. Die Middleware dupliziert die Nachrichten der Clients und verteilt diese an jede Serverinstanz. Anschließend erhält die Middleware die Antworten von jedem Server und vergleicht die Ergebnisse, um sicherzustellen, dass die Server innerhalb der zulässigen Toleranzen übereinstimmen. Der Anwendungsentwickler muss sich nicht um Replikationen beziehungsweise verschiedene Implementierungen kümmern.

Die Replikationspunkte – das sind die Stellen, an denen die Middleware eingefügt wird und mehrere Repliken unterstützt werden – müssen auf der richtigen Granularitätsebene gesetzt werden. So ist eine Duplizierung jeder mathematischen Berechnung oder jedes Funktionsaufrufs zu feinkörnig und führt zu höheren Entwicklungskosten und einem langsameren Laufzeitverhalten. Die perfekte Replikationsgranularität findet sich auf Komponentenebene. Die Implementierung von POSIX-API-Funktionen in einem Microkernel-Betriebssystem ist dabei ein gutes Modell für diesen Ansatz.

Als Beispiel sei eine Anwendung genannt, die eine Datei öffnet und einige Daten ausliest. Bei einer Entkopplung der Anwendung von dem Dateisystem ergibt sich ein hervorragender Einfügepunkt für die Middleware.

Wenn die Anwendung nicht mit dem Dateisystem spricht, sondern stattdessen mit der Middleware, und die Middleware wiederum mit den replizierten Dateisystemservern, dann können Redundanz und Überprüfung an diesem natürlichen Entkopplungspunkt erfolgen – und das auf eine Art und Weise, die für die Anwendung selbst sowie für die Implementierung des Dateisystems vollkommen transparent ist. Mit der Entwicklung weiterer Komponenten in dem System mit gleicher Granularität kann der Systementwickler Repliken an den zwischen den Prozessen bestehenden Kommunikationsgrenzen einfügen. Hier kommt es auf die vom Betriebssystem gebotene Flexibilität an: Wenn das Betriebssystem die nahtlose Partition von Repliken oder verschiedenen Anwendungen über Prozessorkerne hinweg ermöglicht, wird die Implementierung einer Replikationsstrategie einfacher.

Servermodelle

Wenn ein Fahrzeug beispielsweise auf einer Autobahn unterwegs ist, kann ein anderer Grad von Widerstandsfähigkeit im Rahmen der Safety erforderlich sein als bei einer Fahrt in einem Stadtzentrum.

Wenn ein automatisiertes Fahrzeug beispielsweise auf einer Autobahn unterwegs ist, kann ein anderer Grad von Widerstandsfähigkeit im Rahmen der Safety erforderlich sein als bei einer Fahrt in einem Stadtzentrum. Blackberry-QNX/iStock

Wie bereits erwähnt, kann der Systementwickler zwischen zwei Hauptservermodellen wählen – das identische und das Brudermodell (Fraternal Model), wobei letzteres weiter in Peer Fraternal und Monitor Fraternal unterteilt werden kann.

Bei dem identischen Modell können die Server auf derselben CPU, auf verschiedenen Prozessoren in einem Mehrprozessorsystem oder auch auf verschiedenen Systemen laufen, die über ein Netzwerk miteinander verbunden sind. Dieses Modell bietet Skalierbarkeit und potenzielle Redundanz bei einem Hardwarefehler: Die gleiche Software muss die gleichen Ergebnisse produzieren; tut sie das nicht, dann gibt es ein Problem mit der Hardware oder einen Softwarefehler des Typs Heisenbug.

Beim Peer-Fraternal-Model verwendet das System verschiedene, aber voll funktionale Versionen der Server, zum Beispiel den gleichen Quellcode, den unterschiedliche Compilern umwandeln. Die Erwartung lautet, dass eventuell auftretende Fehler im Implementierungsbereich auftreten würden, es also letztlich Fehler in der Implementierung wären.

Beim Monitor-Fraternal-Model nutzt das System ebenfalls verschiedene Server, aber hier verfügen einige Serverinstanzen über die gesamte Funktionalität, während andere eine reduzierte Überwachungsfunktionalität aufweisen.

Thema auf der nächsten Seite: Kosteneinsparung per Software-Lockstep

Kosteneinsparung per Software-Lockstep

Alle drei Modelle sind nützlich und lassen sich vermischen, aber das Monitor-Fraternal-Model bietet interessante Kosteneinsparungen. Man betrachte hierbei die Zertifizierungskosten des jeweiligen Modells:

  • Das identische Modell weist keine Diversifizierung auf, sodass der volle Entwicklungs- und Zertifizierungsprozess und die damit verbundenen Kosten für die ASIL-Einstufung von der Software geschultert werden müssen.
  • Beim Peer-Fraternal-Model gibt es eine Diversifizierung, sodass die Kombination mehrerer verschiedener Instanzen sowohl zu Zuverlässigkeit als auch zu Verfügbarkeit beiträgt, aber die Softwarekosten sind mindestens doppelt so hoch – je nachdem, wie viele verschiedene Implementierungen es gibt.
  • Das Monitor-Fraternal-Model kam bereits in anderen Branchen erfolgreich zum Einsatz. Dieses Konzept ist auch als Safety Bag bekannt, ein weitaus einfacheres Software-Element, das sicherstellt, dass die getroffenen allgemeinen Entscheidungen vernünftig und sicher sind. Unter dem Blickwinkel der Zertifizierungskosten kann die ASIL-Einstufung gemäß ISO 2662 zerlegt werden, wenn die Software für den Hauptserver und die weitaus einfachere Monitor-Software zertifiziert werden; der Zertifizierungsaufwand ist dabei geringer. Tatsächlich sorgt der Monitor für eine ASIL-Bereicherung, da er eine weitere der verschiedenen Instanzen darstellt.

Chris Hobbs

Spezialist für Software-Sicherheit bei Blackberry QNX

Kerry Johnson

Leitender Produktmanager bei Blackberry QNX

(av)

Sie möchten gerne weiterlesen?

Unternehmen

QNX Software Systems GmbH

Am Listholze 76
30177 Hannover
Germany