Der ISO 26262-Zertifizierungsprozeß für Funktionale Sicherheit ist kein Hindernis mehr

Der ISO 26262-Zertifizierungsprozeß für Funktionale Sicherheit ist kein Hindernis mehr

Verfasser:

Jacob Lunn Lassen, Technischer Mitarbeiter, Funktionale Sicherheit bei Microchip Technology

Datum: 5. Februar 2022

In den heutigen Automobilen werden Hunderte bis Tausende von Halbleitern und anderen Komponenten in einer wachsenden Vielfalt von Anwendungen eingesetzt.

Abbildung 1: Zertifizierte Ressourcen für Funktionale Sicherheit und Entwicklungsökosystem

Die strengen Spezifikationen der International Organization for Standardization (ISO) 26262 für funktionale Sicherheit gewährleisten, daß die immer komplexeren und anspruchsvolleren Automobilanwendungen sicher funktionieren. Die Entwicklung konformer Designs und die Erlangung der Zertifizierung können jedoch ein zeitaufwändiger und teurer Prozeß sein. Die Halbleiterindustrie bietet Automobilherstellern (OEMs) und -zulieferern komplette Ökosysteme für Funktionale Sicherheit, die die Kosten, das Risiko und die Entwicklungszeit für diesen Zertifizierungsprozeß minimieren.

ISO 26262 verstehen

Die Norm ISO 26262 umfaßt Spezifikationen für die Funktionale Sicherheit elektrischer und/oder elektronischer Systeme, die in serienmäßig hergestellten Straßenfahrzeugen (außer Mopeds) eingebaut sind. Diese 2011 veröffentlichte und 2018 überarbeitete ISO-Norm, die einen Abschnitt über Halbleiter enthält, schreibt einen Entwicklungsprozeß von der Spezifikation bis zur Produktionsfreigabe vor. Automobilhersteller und -zulieferer müssen diesen Prozeß befolgen und dokumentieren, wenn sie Geräte für den Betrieb in Straßenfahrzeugen qualifizieren, die Funktionale Sicherheit erfordern.

Die Zertifizierung von Systemen erfolgt durch die Bestätigung eines unabhängigen Gutachters, daß sie die Anforderungen der ISO-Norm 26262 erfüllen. Die Anwendungen im Fahrzeug werden je nach dem Grad ihrer Sicherheitskritikalität in verschiedene Automotive Safety Integrity Levels (ASILs) “eingestuft”. Einige Anwendungen haben ein höheres inhärentes Sicherheitsrisiko, wenn ein elektrisches oder elektronisches System ausfällt. Die Stufen, von A bis D, basieren auf der Schwere und Wahrscheinlichkeit möglicher Verletzungen und dem Ausmaß, in dem diese kontrolliert werden können, und es gibt entsprechende Sicherheitsanforderungen für die zugrunde liegenden Komponenten. ASIL D ist die höchste Gefahrenstufe für Anwendungen wie Airbags, Antiblockiersysteme und Servolenkungen. Komponenten wie Rückleuchten werden als ASIL-A eingestuft. Scheinwerfer und Bremslichter werden im Allgemeinen als ASIL-B eingestuft. Ein System wie der Tempomat wird als ASIL-C eingestuft. Je höher die ASIL-Stufe, desto höher sind in der Regel die Anforderungen an die Hardware-Redundanz.

Es gibt mehrere Möglichkeiten, wie Komponentenlieferanten die Entwicklung einer Sicherheitsanwendung und deren ISO 26262-Zertifizierung beschleunigen können. Diese Ressourcen für die Funktionale Sicherheit sind in Abbildung 1 dargestellt. Zunächst müssen die Geräte sorgfältig ausgewählt werden, damit sie die erforderlichen Ressourcen für die Funktionale Sicherheit enthalten. Zu diesen Ressourcen gehören Berichte zur Fehlermöglichkeits- und Diagnoseanalyse (FMEDA) und Sicherheitshandbücher. Die Geräte müssen außerdem von einem Entwicklungssystem unterstützt werden, das für die Erstellung sicherheitskritischer Anwendungen qualifiziert ist.

Bereitschaft zur Funktionalen Sicherheit

In heutigen Automobilen wird eine Vielzahl von ICs verwendet. Mikrocontrollereinheiten (MCUs) sind in verschiedenen Formen besonders weit verbreitet. Sie sind für alle elektronischen Steuergeräte (ECUs) erforderlich und werden im gesamten Fahrzeug verwendet, um Komfortfunktionen wie selbstfahrendes Fahren und eine Vielzahl anderer anspruchsvoller Funktionen zu ermöglichen. Sie reichen von 8-Bit-MCUs, die für Leistung, Energieeffizienz und Echtzeitsteuerung optimiert sind und gleichzeitig hardwarebasierte Touch-Schnittstellen bieten, bis hin zu 32-Bit-MCUs, die Multithreading-Anwendungen ausführen können und über Grafik-, Konnektivitäts- und Sicherheitsfunktionen verfügen. Darüber hinaus gibt es Digital Signal Controllers (DSCs), die eine MCU mit einer DSP-Engine kombinieren, um eine robuste und schnelle deterministische Leistung für Sensoren, Motoren oder Energieumwandlung zu bieten.

Jeder dieser ICs muß zunächst die vom Automotive Electronics Council (AEC) festgelegten Qualifikationsstandards für die Herstellung und Leistung erfüllen. Die AEC-Q100-Standards definieren einen auf Ausfallmechanismen basierenden Streßtest-Qualifizierungsprozeß für verschiedene Temperaturklassen. Je nach Anwendung muß eine MCU nach AEC Q100 Grade 2, Grade 1 oder Grade 0 qualifiziert sein. Grad 0 = 150°C, Grad 1 = 125°C und Grad 2 = 105°C.

Über die AEC-Qualifikation hinaus hängen die zusätzlichen Anforderungen für spezielle funktionssichere Merkmale vom Gerät und der Anwendung ab. 8-Bit-MCUs enthalten beispielsweise häufig CAN FD für Automobilschnittstellen und intelligente Sensornetzwerke und werden typischerweise als Benutzerschnittstellen-Controller für mechanische und kapazitive Tasten im Innenraum, am Lenkrad, in der Mittelkonsole oder als Teil eines schlüssellosen Zugangssystems verwendet. Die integrierten Hardware-Sicherheitsfunktionen, die diese MCUs benötigen, beziehen sich in der Regel auf Speicher, Systemreset, sichere Codeausführung, sichere Kommunikation und GPIO-Schutz (General-Purpose Input/Output). Diese werden durch die Integration dedizierter Core Independent Peripherals (CIPs) und anderer Funktionen wie Power-On-Reset (POR), Brown-Out-Reset (BOR), Windowed Watch-Dog Timer (WWDT) und Cyclic Redundancy Check (CRC) ergänzt, um die Betriebssicherheit und Zuverlässigkeit zu verbessern (siehe Abbildung 2).

Abbildung 2: 8-Bit-MCU mit Hardwarefunktionen für Funktionale Sicherheit

Wenn man die Leiter zu den 16-Bit-DSCs mit Funktionaler Sicherheit hinaufsteigt, umfassen die erforderlichen Hardware-Sicherheitsfunktionen im Allgemeinen Speicher mit Fehlererkennung und -korrektur, Memory Built-In Self-Test (MBIST), Taktüberwachung und redundanten Oszillator und vieles mehr für die Fehlererkennung, Selbstdiagnose und Systemdiagnosefähigkeiten sowie Fehlerbegrenzung. Diese Functional-Safety-ready-Bausteine ermöglichen die Entwicklung von sicherheitskritischen Hochleistungs-Embedded-, Sensor-Interfacing-, digitalen Leistungs- und Motorsteuerungsanwendungen. Typische Anwendungen sind DC/DC-Systeme, On-Board-Ladegeräte (OBCs), Aktoren und Sensoren (Position, Druck), Touch- und andere Steuereinheiten, die ASIL B oder ASIL C erfüllen sollen. Abbildung 3 zeigt ein Beispiel für die Merkmale einer funktionssicheren DSC.

Abbildung 3: Beispiel für einen funktionssicheren 16-Bit-DSC

Wie alle funktionssicheren MCUs benötigen auch 32-Bit-MCUs Hardware-Merkmale wie Speicher mit Fehlerkorrekturcode (ECC) und Fehlerinjektion, Memory Built-in Self Test (MBIST), Taktsysteme einschließlich Backup-Oszillatoren und Taktausfallerkennung sowie GPIO mit ESD-Schutz (Electro-Static Discharge) (siehe Abbildung 4). Wichtig sind auch Systemüberwachungen wie POR, BOR, WDT und Hardware-CRC-Funktionalität sowie eine Speicherschutzeinheit. 32-Bit-MCUs werden in einer Reihe von Anwendungen eingesetzt, von Systemen in der Kabine bis hin zu fortschrittlichen Fahrerassistenzsystemen (ADAS) für die Funktionale Sicherheit.

Abbildung 4: Beispiel einer 32-Bit-MCU, die für die Funktionale Sicherheit geeignet ist

Es ist möglich, die ASIL C/D-Sicherheitsstufen auch mit Standard-MCUs und DSCs zu erreichen, indem die primäre MCU oder DSC mit einer sekundären MCU oder einem Sicherheits-Coprozessor kombiniert wird. Dies wird durch das Prinzip der ASIL-Dekomposition erreicht: Die Kombination von zwei ASIL B-konformen Teilsystemen kann verwendet werden, um ein höheres ASIL-Niveau wie ASIL C/D zu erreichen:

ASIL C = ASIL B (C) + ASIL A (C)

ASIL D = ASIL B (D) + ASIL B (D) = ASIL C (D) + ASIL A (D)

Die Zerlegung wird durch die Aufteilung der Sicherheitsanforderungen auf die einzelnen Geräte erreicht.

Entwicklungswerkzeuge und Zertifizierungsunterstützung

Entwicklungswerkzeugpakete, die als Teil eines kompletten Entwicklungssystems für Funktionale Sicherheit zertifiziert sind, können die Erfüllung der in der Norm ISO 26262 festgelegten Verifizierungs- und Validierungsanforderungen erleichtern. Dies gilt insbesondere für MCU- und DSC-basierte Designs. Tool-Lieferanten arbeiten mit unabhängigen Bewertungs- und Zertifizierungsstellen zusammen, um Compiler für die Funktionale Sicherheit zu zertifizieren. Dazu gehören in der Regel zusätzliche Unterlagen wie ein Zertifikat, ein Handbuch zur Funktionalen Sicherheit, ein Sicherheitsplan sowie Klassifizierungs- und Qualifizierungsberichte für die Compiler, die Integrierte Entwicklungsumgebung (IDE), die Debugger und Programmierer. Dieses Dokumentationspaket zur Funktionalen Sicherheit vereinfacht die Qualifizierung der Werkzeuge und die Zertifizierung der Endanwendung.

Idealerweise sollte ein Codeabdeckungswerkzeug auch im Entwurfsprozeß verwendet werden, um zu messen, wie gut der Code getestet wurde, und um festzustellen, welche Teile der Software ausgeführt wurden und welche nicht. Das Code Coverage Tool sollte auch in die Klassifizierungs- und Qualifizierungsberichte aufgenommen werden. Achten Sie auf ein Tool, das in einem einzigen Durchgang testen kann, ohne den Code in Blöcke aufzuteilen, was umfangreiche Hardwareänderungen, teure Software und einen erheblichen Aufwand für die Suche nach relevanten Informationen in großen Datendateien erfordert. Für die Zertifizierung von Anwendungen sind Code-Testdaten erforderlich, so daß Single-Pass-Code-Coverage-Tools eine wichtige Rolle bei der Rationalisierung des Prozesses und der Verkürzung der Markteinführungszeit spielen.

Um eine Automobilanwendung zu entwickeln, die der ISO 26262 entspricht, benötigt ein Ingenieur neben dem Datenblatt des Geräts mehrere zusätzliche Ressourcen vom Halbleiterlieferanten. Die Verfügbarkeit von Paketen zur Funktionalen Sicherheit gibt Automobil-OEMs und -Zulieferern Alles, was sie in den verschiedenen Phasen des Evaluierungs- und Entwicklungszyklus benötigen. Diese Pakete sollten zertifizierte Sicherheitshandbücher, FMEDA-Berichte und in einigen Fällen Diagnosesoftware wie zertifizierte Selbsttestbibliotheken für relevante ASILs umfassen.

Der FMEDA-Bericht quantifiziert die Fehlermodi des Geräts, seine FIT-Ratenverteilung (Failure-In-Time) und die entsprechenden Erkennungsmethoden, um die Erstellung eines Abdeckungsplans zu unterstützen. Eine weitere wichtige Ressource ist das Sicherheitshandbuch (SM). Es enthält Einzelheiten zu den im FMEDA-Bericht genannten Fehlererkennungsmethoden und gibt Empfehlungen, wie das Gerät für einen möglichst sicheren Betrieb eingesetzt werden sollte. Sie enthält eine Beschreibung abhängiger Fehler und Hardware-Merkmale zur Erkennung systematischer Fehler, die für die Entwicklung von Diagnosebibliotheken verwendet werden können. Die Diagnosebibliotheken für Funktionale Sicherheit können dabei helfen, den Betriebszustand eines Systems unter Fehlerbedingungen zu bewerten, zufällige Systemausfälle zu erkennen und die Ziele der Funktionalen Sicherheit zu erreichen. Die Auswahl eines Geräts, das einen von einem Drittanbieter zertifizierten FMEDA-Bericht und ein Sicherheitshandbuch sowie Diagnosebibliotheken bietet, vereinfacht die Zertifizierungsbemühungen für eine sicherheitskritische Anwendung.

Die Entwicklung einer sicherheitskritischen Anwendung beginnt mit der Definition der Sicherheitsziele und des zu erreichenden Sicherheitsniveaus. Ein Basispaket für Funktionale Sicherheit bietet grundlegende Ressourcen wie FMEDA, Sicherheitshandbuch und Zertifizierung, um mit der Bewertung der angestrebten Funktionalen Sicherheitsniveaus und dem Design einer sicherheitskritischen Automobilanwendung zu beginnen.

Ein Starterpaket für Funktionale Sicherheit für ein MCU-basiertes Design würde idealerweise eine ASIL B Ready-zertifizierte FMEDA, ein Sicherheitshandbuch und ASIL B/C-konforme Diagnosebibliotheken in Kombination mit einer Referenzanwendung enthalten, die Entwicklern hilft zu verstehen, wie diese Ressourcen zur Entwicklung einer sicherheitskritischen Anwendung unter Einhaltung des ISO 26262-Prozesses eingesetzt werden können. Ein Starterpaket hilft, den Designzyklus zu beschleunigen und eine Anwendung gemäß ASIL B oder C zu entwickeln.

Ein Komplettpaket für Funktionale Sicherheit kann das Angebot um zertifizierte Diagnosebibliotheken mit Quellcode und relevanten Sicherheitsanalyseberichten für Designs bis ASIL B/C erweitern. Da viele Endkunden die Zertifizierung einer sicherheitskritischen Anwendung verlangen, beschleunigt das Komplettpaket den Zertifizierungsprozeß.

Automobile werden immer anspruchsvoller, und ihr Elektronikanteil nimmt zu. Es wird immer wichtiger, daß die heutigen, auf Funktionale Sicherheit ausgerichteten Produkte für Automobilanwendungen Entwicklungs-Ökosysteme unterstützen, die zertifizierte Funktionale Sicherheitsressourcen zur Erfüllung der ISO 26262-Anforderungen bieten. IC-Lieferanten können Automobilkunden auch dabei helfen, ihre langfristigen Investitionen in diesen strengen Entwicklungs- und Zertifizierungsprozeß zu schützen. Sie können sicherstellen, daß die in einem zertifizierten System verwendeten Teile so lange geliefert werden, wie der Kunde sie bestellen möchte, und so das Risiko eines erzwungenen Redesigns aufgrund des unerwarteten Erreichens des End-Of-Life (EOL) eines Teils ausschließen. Dies erhöht das Vertrauen, daß die Zertifizierung nicht nur schnell und einfach abgeschlossen werden kann, sondern auch nur einmal durchgeführt werden muß.