Professional Articles

Safety-Zertifizierung von COTS-basierten Systemen in Automotive-Anwendungen

Die Sicherheitsnorm ISO 26262 ist eine Spezialisierung der allgemeinen Norm IEC 61508 zur funktionalen Sicherheit und definiert generische (Software-) Anwendungen und generische (Hardware-) Produkte, die eine unabhängige Zertifizierung für Automotive-Anwendungen erhalten können. Beim Aufbau eines komplexen Sicherheitssystems können solche COTS-Produkte (Commercial off-the-Shelf) wiederverwendet werden, einschließlich ihrer bestehenden Zertifizierungsartefakte. Mit diesem Ansatz kann eine sicherheitsrelevante Elektronik aus vorzertifizierten Software- und Hardwaremodulen zusammengesetzt werden. Eine vorzertifizierte generische (Software-) Anwendung muss dabei den Regeln der ISO 26262 folgen.

Anders als bei Software können bei Hardware neben systematischen Ausfällen auch zufällige Ausfälle auftreten. Systematische Hardwarefehler müssen adressiert werden, indem die Regeln der ISO 26262 für den Entwicklungsprozess festgelegt werden. Zufällige Hardwarefehler werden durch die Berechnung der Wahrscheinlichkeit des Ausfalls unter Verwendung statistischer Maßnahmen und historisch belegter Gebrauchsdaten adressiert. Das funktioniert ganz gut für diskrete Hardwarekomponenten, aber je komplexer eine Hardware ist, umso schwerer wird es, den Ausfall von Hardwarekomponenten vorauszusehen. Eine praktikable Alternative besteht darin, den Ausfall extern zu registrieren und die Hardware innerhalb einer definierten Zeitspanne in einen sicheren Zustand (Safe State) zu überführen. Diese Alternative ermöglicht Entwicklern, auch komplexe Hardwarekomponenten wie etwa Multi-Core-Prozessoren zu verwenden, falls entsprechende Diagnosemethoden angewendet werden können.

SIL und ASIL

Die primäre Aufgabe einer sicherheitsrelevanten elektronischen Anlage ist es, eine Sicherheitsfunktion durchzuführen, die einen sicheren Zustand eines überwachten Gerätes erreichen oder aufrechterhalten muss, um die Folgen von gefährlichen Ereignissen zu verringern. Die Fähigkeit, die Sicherheitsfunktion auszuführen, wird in der IEC61508 durch die Sicherheitsintegrität (Safety Integrity) beschrieben, die ein Maß für die Wahrscheinlichkeit ist, dass ein sicherheitsrelevantes System die spezifizierten Sicherheitsfunktionen unter allen angegebenen Bedingungen innerhalb eines bestimmten Zeitraums durchführt. Dabei wird das höchste Sicherheitsintegritätsniveau (Safety Integrity Level - SIL) durch die Hardware definiert. Die Software erbt deren SIL und muss den Prozessen folgen, die in der zugehörigen Software-Sicherheitsnorm angegeben sind. Die IEC61508 kennt fünf Levels SIL 0 bis SIL 4, die ISO 26262 daran angelehnt vier Levels ASIL A bis ASIL D (ASIL = Automotive SIL). Mit steigendem Level steigen in beiden Normen die Anforderungen an die Sicherheit. Der niedrigste Level SIL 0 hat in der ISO 26262 keine Entsprechung; hier geht es um unkritische Systeme, bei denen keine Maßnahmen erforderlich sind, die über das normale Qualitätsmanagement (QM) des Herstellers hinausgehen.

Ziel eines sicherheitsrelevanten Systems ist es, das Risiko für eine bestimmte Situation in Bezug auf seine Wahrscheinlichkeit und ihre spezifischen Konsequenzen auf ein tolerierbares Niveau zu reduzieren. Um zu einem Urteil zu gelangen, was ein erträgliches Risiko für eine spezifische Anwendung darstellt, müssen mehrere Faktoren wie gesetzliche Anforderungen, Richtlinien, Industriestandards (z. B. IEC 61508, ISO 26262 usw.) berücksichtigt werden. Die Konformität eines sicherheitsrelevanten Systems mit einer zugewiesenen SIL-Ebene muss grundsätzlich mathematisch bewiesen werden. Jedoch gilt z.-B. im Falle von ASIL B/C im Mittel das Auftreten einer gefährlichen Situation alle 1142 Jahre als akzeptabel. Da elektronische Bauteile einen solchen Langzeitnachweis nicht zulassen, müssen architektonische Konzepte wie Hardware-Fehlertoleranz, Geräte-Diagnose, Inspektions- und Proof-Tests angewendet werden, um das Risiko für die Elektronik zu reduzieren.

Zufällige und systematische Fehler

Bei der Safety Integrity für elektronische Systeme wird zwischen Hardware-Sicherheitsintegrität und systematischer Sicherheitsintegrität unterschieden. Hardware-Sicherheitsintegrität bezieht sich auf zufällige Hardware-Fehler, während die systematische Sicherheitsintegrität mit systematischen Fehlern zusammenhängt, die in Hardware- und Software-Designs auftreten können. Der Begriff Common Cause Failure (CCF) beschreibt dabei zufällige und systematische Ereignisse, die dazu führen, dass mehrere Geräte (in einem Mehrkanal-System) gleichzeitig ausfallen.

Fehler werden mit unterschiedlichen Strategien verwaltet, je nachdem, ob sie zufällig oder systematisch sind. Zufallsfehler können durch interne Geräte-Diagnose, externe Diagnose, Inspektion und Proof-Tests identifiziert werden. Während zufällige Hardwarefehler vor allem durch Abnutzung verursacht werden, sind systematische Ausfälle eine direkte Konsequenz der Systemkomplexität. Sie werden oft während der Spezifikation und der Entwurfs- oder Implementierungsphase eingeführt, können aber durch Fehler während der Fertigung oder Integration sowie Bedienungs- oder Wartungsfehler verursacht werden. Systematische Ausfälle gelten im mathematischen Sinne als vorhersehbar und lassen sich durch die strikte Anwendung korrekter Prozesse während des Lebenszyklus der elektronischen Komponente und der implementierten Software in den Griff bekommen.

Die Risiken systematischer Ausfälle können durch Redundanz und/oder durch einen strengen Lebenszyklusprozess minimiert werden. Redundanz kann etwa durch Vielfalt erreicht werden, indem unterschiedliche Technologien oder Produkte unterschiedlicher Hersteller eingesetzt werden. Zudem kann man ggf. unterschiedliche Hardwarearchitekturen von verschiedenen Anbietern verwenden Im Falle von Software kann der gleiche Algorithmus beispielsweise in unterschiedlichen Programmiersprachen implementiert werden und/oder in verschiedenen Laufzeitumgebungen laufen. Höhere Zuverlässigkeit durch Vielfalt basiert dabei auf der Annahme, dass verschiedene Geräte unterschiedliche Ausfallursachen und Ausfallmodi haben.

Zufällige Hardwarefehler

Zufällige Hardwarefehler treten - nomen est omen - zu einer zufälligen Zeit auf und resultieren aus einer physischen Verschlechterung der Hardware. Die physikalische Verschlechterung kann durch Fertigungstoleranzen, abnormale Prozessbedingungen (Überspannung und Temperatur), elektrostatische Entladung, Geräteverschleiß usw. verursacht werden. Solche Ausfälle treten zwar mit vorhersagbarer Wahrscheinlichkeit auf, aber zu unvorhersehbaren (d.h. zufälligen) Zeiten. Abhängig von der Auswirkung eines Fehlers auf die Hardware wird dieser entweder als "weicher Fehler" oder "harter Fehler" bezeichnet. Ein weicher Fehler (Soft Error) ist vorübergehend und ohne dauerhafte Folgen, während ein schwerer Fehler (Hard Error) die Hardware beschädigt. Mit der zunehmenden Komplexität der Hardware steigt auch die Wahrscheinlichkeit von weichen und harten Fehlern aufgrund von Umwelt- und Betriebsbedingungen. Dies wird durch den Trend begünstigt, die Geometrie der Hardware zu schrumpfen und die Dichte von Transistoren auf dem Silizium zu erhöhen. Insbesondere Speicherkomponenten, ob nun diskret oder in Form von Registerbänken oder Caches in CPUs eingebettet, sind anfällig für Übersprechen und gegenüber elektromagnetischen Feldern.

ASIL Abhängigkeiten

Bei komplexen Systemen, die nicht aufgrund vorhandener Realdaten validiert werden können, hängt der ASIL-Level laut ISO 26262 von der Single Point Faults Metric (SPFM) und der Latent Fault Metrik (LFM) ab. Die Metriken berechnen der Anteil der sicheren Fehler und der gefährlichen detektierten Fehler im Verhältnis zu allen Fehlern. Beide sind Hardwarearchitektur-Metriken, die angeben, ob die Abdeckung durch die Sicherheitsmechanismen ausreichend ist oder nicht, um das Risiko von Single Point bzw. Latent Faults in der Hardwarearchitektur zu vermeiden.

  • Single Point Faults Metric
    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 Metrik
    Latente Fehler sind Mehrpunktfehler, deren Anwesenheit nicht von einem Sicherheitsmechanismus erfasst oder vom Fahrer innerhalb des Mehrpunkt-Fehlererkennungsintervalls (MPFDI) wahrgenommen wird.

Hardware-Fehlertoleranz

Um die Wahrscheinlichkeit von Ausfällen zu reduzieren, werden häufig redundante Architekturen verwendet. Dabei beschreibt die in der IEC 61508 eingeführte Hardwarefehlertoleranz (HFT) die Fähigkeit eines Bauteils oder Teilsystems, auch bei Hardwarefehlern die erforderliche Sicherheitsfunktion zu übernehmen. Eine Hardwarefehlertoleranz von 1 bedeutet, dass es z. B. zwei Geräte gibt und der gefährliche Ausfall eines der beiden die Sicherheitsfunktion nicht beeinträchtigt. Ein Drei-Kanal-System, bei dem ein einzelner Kanal die Sicherheitsfunktion im Falle eines Fehlers in jedem der anderen 2 Kanäle fortsetzen kann, gilt als Hardware-Fehlertoleranz von 2. Der HFT kann leicht berechnet werden, 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. Dies bedeutet, dass ein solches System 2 Ausfälle tolerieren kann und immer noch funktioniert. Durch die Implementierung einer Architektur mit einem HFT> 0 kann so ein 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 z. B. eine Firewall, die den Netzwerkverkehr auf der Transportebene überwacht und ggf. nach IP-Adressen und Ports filtern kann. Außerdem kann eine Partition auch die Terminierung eines VPN-Tunnels übernehmen, so dass für eine solche Funktionalität keine zusätzliche Hardware 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 Partitionsloader beendet die alte Partition und aktiviert die neue, so dass für Updates kein Neustart erforderlich ist.

Die Zertifizierung von Software

Bei einer CPU bzw. eines Standard-Boards in einem Sicherheitssystem wird Software definitiv ein wesentlicher Teil des Sicherheitspfades sein. In der frühen Geräteinitialisierung wird Software als Bootloader verwendet. Später kann ein Betriebssystem (OS) eingesetzt werden, um die Nutzung der Hardware zu erleichtern. Auf dem Betriebssystem kann eine Software-Anwendung die (Sicherheits-) Funktion einschließlich der Diagnosetests durchführen, die den Systemstatus fortlaufend überwachen.

Software kennt keine zufälligen Fehler, sondern nur systematische, die in der Regel durch Designfehler verursacht werden. Die ISO 26262 beschreibt Konstruktionsmethoden, um die Risiken dieser Fehler zu minimieren und dies durch einen Wert abzubilden, der sich durch das jeweilige Safety Integrity Level ausdrückt. Die Methoden beinhalten kurz die folgenden Phasen:

  • Anforderungsspezifikation
  • Software-Design und Entwicklungsprozess
  • Verifizierungs- und Validierungsverfahren

Detaillierte Unterlagen und Nachweise müssen vorbereitet werden, um nachzuweisen, dass ein angemessenes Niveau der vorgegebenen Regeln angewandt wurde. Dabei ist der Validierungstest in hohem Maße abhängig vom Umfang des Quellcodes (Source Lines of Code - SLOC), der getestet werden muss. Ein schlanker Quellcode reduziert den Zertifizierungsaufwand erheblich. Dies gilt natürlich auch für alle Softwarekomponenten wie den Bootloader, das Betriebssystem, den Applikationscode und die eingebauten Diagnosefunktionen. Die Verwendung des richtigen Technologie- und Validierungsansatzes wird daher einen erheblichen Einfluss auf die Gesamtkosten haben.

Das Betriebssystem (OS) ermöglicht es dem Anwendungsprogrammierer, die zugrunde liegenden Hardwareressourcen optimal zu nutzen. Der OS-Kernel bietet Dienste für Applikationen (Threads, Tasks, Prozesse) Management und Kommunikation. Die zugrunde liegende Hardware wird in der Regel mit einem Board Support Package (BSP) beschrieben, das aus Initialisierungscode und Gerätetreibern besteht. Wenn ein Ausfall im Betriebssystem vorliegt, können der BSP oder der Anwendungscode das Sicherheitssystem beeinflussen, da ihre Entwicklung den von der Norm vorgeschriebenen Regeln folgen muss. Speziell Applikationen können eine sehr große Anzahl von Codezeilen haben, was die Kosten für die Software-Zertifizierung enorm erhöht. Daher schlagen die Sicherheitsnormen eine Trennung von sicherheitsrelevanter und nicht sicherheitsrelevanter Software vor, so dass nur die sicherheitsrelevanten Teile zertifiziert werden müssen.

Trennung von Anwendungen durch Separation Kernel

Die Verwendung unabhängiger Hardwarekomponenten für sicherheitsrelevante und andere Anwendungen sorgt für eine sichere Trennung, führt aber auch zu erhöhten Hardwarekosten. Ein auf einem Separation Kernel basierendes Betriebssystem wie etwa PikeOS von SYSGO ermöglicht dagegen die Trennung von Applikationscode auf derselben Hardwareplattform durch die Aufteilung der physikalischen und zeitlichen Ressourcen der Hardware. Die Trennung von physikalischen Ressourcen wird als räumliche Trennung oder Ressourcenpartitionierung bezeichnet, während die Trennung der verfügbaren Ausführungszeit als zeitliche Trennung oder Zeitpartitionierung bekannt ist. Das Trennungsprinzip kann mit einem Hypervisor verglichen werden, doch der Hauptunterschied besteht darin, dass ein Separation Kernel die folgenden Fähigkeiten bietet:

  • Unumgehbar: Eine Komponente kann den Kommunikationsweg nicht umgehen, auch nicht mit Lower-Level-Mechanismen
  • Manipulationssicher: Vermeidung von unbefugten Änderungen durch die Überwachung  der Änderungsrechte für den Sicherheitsmonitor-Code, die Konfiguration und die Daten
  • Immer aktiv: Jeder Zugriff und jede Message wird von den entsprechenden Sicherheitsmonitoren überprüft
  • Evaluierbar: Vertrauenswürdige Komponenten können hinsichtlich der Sicherheit daraufhin evaluiert werden, ob sie modular, gut entworfen, gut spezifiziert, gut umgesetzt, klein, wenig komplex etc. sind.

In der Nomenklatur eines Separation Kernels werden die isolierten Anwendungsbereiche als Partitionen bezeichnet. Die Trennung von Applikationen in Partitionen sorgt dafür, dass sich die Applikationen nicht gegenseitig stören können, so dass jede Applikation auf ihrem zugeordneten ASIL arbeiten kann. So kann eine Hardwareplattform Anwendungen gemischter Kritikalitätsstufen verarbeiten. Ein Kommunikations-Stack (z. B. TCP / IP, Web-Server, OPC-US usw.) kann in einer QM-Partition gehostet werden, während eine sicherheitsrelevante AUTOSAR-Anwendung in einer ASIL D-Partition läuft. Jeder Partitionsinhalt muss in einem solchen Fall für seine jeweilige ASIL-Ebene zertifiziert werden.

Fazit

Durch die Trennung von Anwendungen unterschiedlicher Kritikalität können auch in Automotive-Anwendungen die Kosten für die Zertifizierung erheblich reduziert werden, da nicht mehr das Gesamtsystem nach dem höchsten benötigten ASIL-Level zertifiziert werden muss. Zudem können zertifizierte Softwarekomponenten als COTS-Komponenten angeboten und ohne erneute Zertifizierung in unterschiedlichen Projekten eingesetzt werden. Bei Hardware funktioniert dieser Ansatz jedoch nicht, da diese in der Regel aus unterschiedlichen Komponenten aufgebaut wird, die gerade nicht voneinander zu trennen sind. Dennoch führt auch hier der Einsatz einer gemeinsamen Hardware-Plattform zu deutlichen Einsparungen in Beschaffung, Entwicklung und Betrieb.

Get connected with SYSGO

Our team is ready to help.

Contact us