Professional Articles

Im Gegensatz zu Software kann es bei Hardware neben systematischen Fehlern auch zu zufälligen Ausfällen kommen. Systematische Hardwareausfälle müssen durch die Festlegung der Regeln der ISO 26262 für den Entwicklungsprozess behandelt werden. Zufällige Hardwareausfälle werden durch die Berechnung der Ausfallwahrscheinlichkeit anhand statistischer Maße und historischer Nutzungsdaten berücksichtigt. Dies funktioniert recht gut für einzelne Hardwarekomponenten, aber je komplexer eine Hardware ist, desto schwieriger wird es, den Ausfall von Hardwarekomponenten vorherzusagen. Eine praktikable Alternative besteht darin, den Ausfall extern zu registrieren und die Hardware innerhalb einer bestimmten Zeitspanne in einen sicheren Zustand zu überführen. Diese Alternative ermöglicht es Entwicklern, auch komplexe Hardwarekomponenten wie Mehrkernprozessoren zu verwenden, wenn geeignete Diagnosemethoden angewandt werden können.

SIL und ASIL

Die primäre Aufgabe eines sicherheitsrelevanten elektronischen Systems besteht darin, eine Sicherheitsfunktion auszuführen, die einen sicheren Zustand eines überwachten Geräts erreichen oder aufrechterhalten muss, um die Folgen gefährlicher Ereignisse zu verringern. Die Fähigkeit, die Sicherheitsfunktion auszuführen, wird in der IEC 61508 durch die Sicherheitsintegrität beschrieben, die ein Maß für die Wahrscheinlichkeit ist, dass ein sicherheitsbezogenes System die spezifizierten Sicherheitsfunktionen unter allen spezifizierten Bedingungen innerhalb eines spezifizierten Zeitraums ausführen wird. Dabei wird die höchste Sicherheitsintegritätsstufe (SIL) durch die Hardware definiert. Die Software erbt ihren SIL und muss die in der zugehörigen Softwaresicherheitsnorm festgelegten Prozesse befolgen. Die IEC 61508 kennt fünf Stufen SIL 0 bis SIL 4, die ISO 26262 folgt mit vier Stufen ASIL A bis ASIL D (ASIL = Automotive SIL). Je höher die Stufe, desto strenger sind die Sicherheitsanforderungen in beiden Normen. Die niedrigste Stufe SIL 0 hat keine Entsprechung in der ISO 26262; es handelt sich um unkritische Systeme, für die keine über das normale Qualitätsmanagement (QM) des Herstellers hinausgehenden Maßnahmen erforderlich sind.

Ziel eines sicherheitsgerichteten Systems ist es, das Risiko für eine gegebene Situation auf ein tolerierbares Niveau in Bezug auf die Wahrscheinlichkeit und die spezifischen Folgen zu reduzieren. Um zu beurteilen, was ein tolerierbares Risikoniveau für eine bestimmte Anwendung darstellt, müssen verschiedene Faktoren wie gesetzliche Anforderungen, Richtlinien, Industrienormen (z.B. IEC 61508, ISO 26262, etc.) berücksichtigt werden. Die Konformität eines sicherheitsrelevanten Systems mit einem zugewiesenen SIL-Level muss im Prinzip mathematisch nachgewiesen werden. Allerdings wird z. B. bei ASIL B/C das Auftreten einer gefährlichen Situation im Durchschnitt alle 1142 Jahre als akzeptabel angesehen. Da elektronische Komponenten einen solchen Langzeitnachweis nicht erlauben, müssen Architekturkonzepte wie Hardware-Fehlertoleranz, Gerätediagnose, Inspektion und Proof-Tests angewendet werden, um das Risiko für die Elektronik zu reduzieren.

Zufällige und systematische Fehler

Bei der Sicherheitsintegrität für elektronische Systeme wird zwischen Hardware-Sicherheitsintegrität und systematischer Sicherheitsintegrität unterschieden. Die Hardware-Sicherheitsintegrität bezieht sich auf zufällige Hardware-Fehler, während sich die systematische Sicherheitsintegrität auf systematische Fehler bezieht, die in Hardware- und Software-Designs auftreten können. In diesem Zusammenhang beschreibt der Begriff Common Cause Failure (CCF) zufällige und systematische Ereignisse, die zum gleichzeitigen Ausfall mehrerer Geräte (in einem mehrkanaligen System) führen.

Je nachdem, ob es sich um einen zufälligen oder systematischen Fehler handelt, werden unterschiedliche Strategien zur Fehlerbewältigung angewandt. Zufällige Ausfälle können durch interne Gerätediagnose, externe Diagnose, Inspektion und Proof-Tests identifiziert werden. Während zufällige Hardwareausfälle in erster Linie durch Verschleiß verursacht werden, sind systematische Ausfälle eine direkte Folge der Systemkomplexität. Sie werden oft während der Spezifikations- und Entwurfs- oder Implementierungsphase eingeführt, können aber auch durch Fehler bei der Herstellung oder Integration sowie durch Betriebs- oder Wartungsfehler verursacht werden. Systematische Ausfälle gelten im mathematischen Sinne als vorhersehbar und können durch strikte Anwendung korrekter Prozesse während des Lebenszyklus der elektronischen Komponente und der implementierten Software beherrscht werden.

Die Risiken systematischer Ausfälle können durch Redundanz und/oder einen strikten Lebenszyklusprozess minimiert werden. Redundanz kann durch Diversität erreicht werden, z. B. durch die Verwendung unterschiedlicher Technologien oder Produkte verschiedener Hersteller. Bei Software kann derselbe Algorithmus z.B. in verschiedenen Programmiersprachen implementiert werden und/oder in verschiedenen Laufzeitumgebungen laufen. Höhere Zuverlässigkeit durch Diversität basiert dabei auf der Annahme, dass unterschiedliche Geräte unterschiedliche Fehlerursachen und Fehlermodi haben.

Zufällige Hardware-Ausfälle

Zufällige Hardwareausfälle treten - nomen est omen - zu einem zufälligen Zeitpunkt auf und resultieren aus der physischen Degradation der Hardware. Physikalische Degradation kann durch Fertigungstoleranzen, anormale Prozessbedingungen (Überspannung und Temperatur), elektrostatische Entladung, Geräteverschleiß usw. verursacht werden. Solche Ausfälle treten mit vorhersehbarer Wahrscheinlichkeit, aber zu unvorhersehbaren (d. h. zufälligen) Zeitpunkten auf. Je nachdem, wie sich ein Fehler auf die Hardware auswirkt, spricht man von einem "weichen Fehler" oder einem "harten Fehler". Ein weicher Fehler ist vorübergehend und hat keine dauerhaften Folgen, während ein harter Fehler die Hardware beschädigt. Mit zunehmender Komplexität der Hardware steigt auch die Wahrscheinlichkeit von Soft- und Hard-Fehlern aufgrund von Umwelt- und Betriebsbedingungen. Dies wird durch den Trend zur Verkleinerung der Hardwaregeometrie und zur Erhöhung der Transistordichte auf Silizium verstärkt. Insbesondere Speicherkomponenten, ob diskret oder in Form von Registerbänken oder Caches in CPUs eingebettet, sind anfällig für Crosstalk und elektromagnetische Felder.

ASIL-Abhängigkeiten

Bei komplexen Systemen, die nicht auf der Grundlage vorhandener realer Daten validiert werden können, hängt das ASIL-Niveau von der Single Point Faults Metric (SPFM) und der Latent Fault Metric (LFM) gemäß ISO 26262 ab. Die Metriken berechnen den Prozentsatz der erkannten sicheren und gefährlichen Fehler im Verhältnis zu allen Fehlern. Beides sind Metriken für die Hardwarearchitektur, die anzeigen, ob die Abdeckung durch die Sicherheitsmechanismen ausreicht, um das Risiko von Einzelpunkt- oder latenten Fehlern in der Hardwarearchitektur zu vermeiden.

• Metrik für Einzelpunktfehler
  Single Point Faults sind Fehler in einem Element, die nicht durch einen Sicherheitsmechanismus abgedeckt sind und direkt zur Verletzung eines Sicherheitsziels führen.
• Latent Fault Metric
  Latente Fehler sind Mehrpunktfehler, deren Vorhandensein nicht durch einen Sicherheitsmechanismus abgedeckt ist oder vom Fahrer innerhalb des Mehrpunktfehler-Erkennungsintervalls (MPFDI) erkannt wird.

Hardware-Fehlertoleranz

Redundante Architekturen werden häufig eingesetzt, um die Wahrscheinlichkeit von Ausfällen zu verringern. Dabei beschreibt die in der IEC 61508 eingeführte Hardware-Fehlertoleranz (HFT) die Fähigkeit einer Komponente oder eines Teilsystems, die geforderte Sicherheitsfunktion auch bei Hardware-Fehlern zu erfüllen. Eine Hardware-Fehlertoleranz von 1 bedeutet, dass z. B. zwei Geräte vorhanden sind und der gefährliche Ausfall eines dieser Geräte die Sicherheitsfunktion nicht beeinträchtigt. Ein dreikanaliges System, bei dem ein einziger Kanal die Sicherheitsfunktion im Falle eines Ausfalls eines der beiden anderen Kanäle fortsetzen kann, gilt als System mit einer Hardware-Fehlertoleranz von 2. Die HFT lässt sich leicht berechnen, wenn die Architektur als M aus N (MooN) ausgedrückt wird. In diesem Fall wird die HFT als N-M berechnet. Mit anderen Worten: Eine 1oo3-Architektur hat eine HFT von 2. Das bedeutet, dass ein solches System 2 Ausfälle tolerieren kann und trotzdem funktioniert. Durch die Implementierung einer Architektur mit einer HFT> 0 kann ein solches Sicherheitssystem auch Standard-Mikroprozessoren wie Intel Core-i oder ARM verwenden.

Weitere Sicherheitsanwendungen

Darüber hinaus können weitere Sicherheitsanwendungen in den Partitionen implementiert werden. Dazu gehört zum Beispiel eine Firewall, die den Netzwerkverkehr auf Transportebene überwacht und gegebenenfalls nach IP-Adressen und Ports filtern kann. Darüber hinaus kann eine Partition auch die Terminierung eines VPN-Tunnels übernehmen, so dass keine zusätzliche Hardware für diese Funktionalität aufgebaut werden muss.

Eine wesentliche Sicherheitsanwendung dient der Sicherung von Software-Updates. Das verwendete SK bietet die Möglichkeit, Partitionen zur Laufzeit durch andere zu ersetzen. In der HASELNUSS-Architektur basiert der sichere Update-Prozess auf dem TPM. Updates werden durch das MDM verschlüsselt und integritätsgeschützt, so dass nur das TPM mit den darin gespeicherten Schlüsseln die Integrität prüfen und das Update entschlüsseln kann. Das Update wird in einer neuen Partition installiert, und der Partitionslader beendet die alte Partition und aktiviert die neue Partition, so dass für Updates kein Neustart erforderlich ist.

Die Zertifizierung von Software

Bei einer CPU oder Standardplatine in einem Sicherheitssystem wird Software definitiv ein wesentlicher Bestandteil des Sicherheitspfads sein. Bei der frühen Initialisierung des Geräts wird Software als Bootloader verwendet. Später kann ein Betriebssystem (OS) verwendet werden, um die Nutzung der Hardware zu erleichtern. Auf dem Betriebssystem kann eine Softwareanwendung die (Sicherheits-)Funktion einschließlich Diagnosetests ausführen, die den Systemstatus kontinuierlich überwachen.

Software erkennt keine zufälligen Fehler, sondern nur systematische Fehler, die in der Regel durch Konstruktionsfehler verursacht werden. Die ISO 26262 beschreibt Entwurfsmethoden, um die Risiken dieser Fehler zu minimieren und dies durch einen Wert, ausgedrückt durch den jeweiligen Sicherheitsintegritätslevel, darzustellen. Die Methoden umfassen kurz die folgenden Phasen:

• Spezifikation der Anforderungen
• Software-Entwurf und Entwicklungsprozess
• Verifikations- und Validierungsprozess

Es müssen detaillierte Unterlagen und Nachweise erstellt werden, um zu zeigen, dass ein angemessenes Niveau der festgelegten Regeln angewandt wurde. In diesem Zusammenhang ist der Validierungstest stark vom Umfang des zu prüfenden Quellcodes (Source Lines of Code - SLOC) abhängig. Ein schlanker Quellcode reduziert den Zertifizierungsaufwand erheblich. Dies gilt natürlich auch für alle Softwarekomponenten wie den Bootloader, das Betriebssystem, den Anwendungscode und die eingebauten Diagnosefunktionen. Die Verwendung der richtigen Technologie und des richtigen Validierungsansatzes wirkt sich daher erheblich auf die Gesamtkosten aus.

Das Betriebssystem (OS) ermöglicht es dem Anwendungsprogrammierer, die zugrunde liegenden Hardwareressourcen optimal zu nutzen. Der Kernel des Betriebssystems stellt Dienste für die Verwaltung und Kommunikation von Anwendungen (Threads, Tasks, Prozesse) bereit. Die zugrunde liegende Hardware wird in der Regel durch ein Board Support Package (BSP) beschrieben, das aus Initialisierungscode und Gerätetreibern besteht. Bei einem Ausfall des Betriebssystems können das BSP oder der Anwendungscode das Sicherheitssystem beeinträchtigen, da ihre Entwicklung den von der Norm vorgeschriebenen Regeln folgen muss. Insbesondere Anwendungen können eine sehr große Anzahl von Codezeilen aufweisen, was die Kosten für die Softwarezertifizierung stark erhöht. Daher schlagen die Sicherheitsnormen vor, sicherheitsbezogene und nicht sicherheitsbezogene Software zu trennen, so dass nur die sicherheitsbezogenen Teile zertifiziert werden müssen.

Trennung von Anwendungen durch Separation Kernels

Die Verwendung unabhängiger Hardwarekomponenten für sicherheitsrelevante und andere Anwendungen gewährleistet eine sichere Trennung, führt aber auch zu erhöhten Hardwarekosten. Im Gegensatz dazu ermöglicht ein auf einem Separation Kernel basierendes Betriebssystem, wie z.B. PikeOS von SYSGO, die Trennung von Anwendungscode auf derselben Hardwareplattform durch die gemeinsame Nutzung der physikalischen und zeitlichen Ressourcen der Hardware. Die Trennung der physischen Ressourcen wird als räumliche Trennung oder Ressourcenpartitionierung bezeichnet, während die Trennung der verfügbaren Ausführungszeit als zeitliche Trennung oder Zeitpartitionierung bezeichnet wird. Das Separationsprinzip kann mit einem Hypervisor verglichen werden, der Hauptunterschied besteht jedoch darin, dass ein Separationskernel die folgenden Fähigkeiten bietet:

• Unumgehbar: Eine Komponente kann den Kommunikationspfad nicht umgehen, auch nicht mit Mechanismen auf niedrigerer Ebene.
• Manipulationssicher: Verhinderung von unbefugten Änderungen durch Überwachung der Änderungsrechte für den Sicherheitsmonitor-Code, die Konfiguration und die Daten
• Immer aktiv: Jeder Zugriff und jede Nachricht wird von den entsprechenden Sicherheitsmonitoren überprüft
• Bewertbar: Vertrauenswürdige Komponenten können auf ihre Sicherheit hin bewertet werden, indem man sie als modular, gut entworfen, gut spezifiziert, gut implementiert, klein, mit geringer Komplexität usw. einstuft.

In der Nomenklatur eines Separationskerns werden die isolierten Anwendungsbereiche als Partitionen bezeichnet. Durch die Aufteilung der Anwendungen in Partitionen wird sichergestellt, dass sich die Anwendungen nicht gegenseitig stören, so dass jede Anwendung mit der ihr zugewiesenen ASIL arbeiten kann. Auf diese Weise kann eine Hardwareplattform Anwendungen mit unterschiedlichen Kritikalitätsstufen verarbeiten. Ein Kommunikationsstack (z. B. TCP/IP, Webserver, OPC-US usw.) kann in einer QM-Partition untergebracht werden, während eine sicherheitsrelevante AUTOSAR-Anwendung in einer ASIL-D-Partition läuft. Jeder Partitionsinhalt muss in einem solchen Fall für den jeweiligen ASIL-Level zertifiziert sein.