Diese Herausforderungen werden bewältigt, indem die Halbleiterindustrie Erstausrüstern (OEMs) und Automobilzulieferern komplette Ökosysteme für funktionale Sicherheit zur Verfügung stellt, die die Kosten, das Risiko und die Entwicklungszeit minimieren, die für den Abschluss dieses Zertifizierungsprozesses erforderlich sind
Erläuterung der ISO 26262:
Die ISO 26262 legt die Spezifikationen für die funktionale Sicherheit elektrischer und/oder elektronischer Systeme in Serienfahrzeugen (ausgenommen Mopeds) fest. Die 2011 veröffentlichte und 2018 um einen Abschnitt zu Halbleitern erweiterte Norm schreibt einen Entwicklungsprozess von der Spezifikation bis zur Serienanlaufphase vor. Erstausrüster (OEMs) und Automobilzulieferer müssen diesen Prozess befolgen und dokumentieren, wenn sie Geräte für den Einsatz in Fahrzeugen mit Anforderungen an die funktionale Sicherheit zertifizieren.
Die Systemzertifizierung erfolgt durch die Bestätigung eines unabhängigen Auditors, dass das System die Anforderungen der ISO 26262 erfüllt. Anwendungen in einem Fahrzeug werden anhand ihrer Sicherheitskritikalität in verschiedene Automotive Safety Integrity Levels (ASILs) eingeteilt. Einige Anwendungen bergen ein höheres inhärentes Sicherheitsrisiko bei einem Ausfall eines elektrischen oder elektronischen Systems. Die Stufen von A bis D basieren auf der Schwere und Wahrscheinlichkeit potenzieller Verletzungen sowie dem Grad ihrer Kontrollierbarkeit. Entsprechende Sicherheitsanforderungen gelten für die zugrunde liegenden Komponenten. ASIL D stellt die höchste Gefahrenstufe in Automobilanwendungen wie Airbags, Antiblockiersystemen (ABS) und Servolenkungen dar. Komponenten wie Rückleuchten werden als ASIL-A klassifiziert. Scheinwerfer und Bremsleuchten werden typischerweise als ASIL-B eingestuft. Systeme wie Geschwindigkeitsregelanlagen werden als ASIL-C klassifiziert. Generell gilt: Je höher die ASIL-Stufe, desto höher die Anforderungen an die Hardware-Redundanz.
Komponentenlieferanten können auf vielfältige Weise dazu beitragen, die Entwicklung einer Sicherheitsanwendung und deren ISO-26262-Zertifizierung zu beschleunigen. Diese Ressourcen für funktionale Sicherheit sind in Abbildung 1 dargestellt. Zunächst müssen die Geräte sorgfältig ausgewählt werden, um die notwendigen Ressourcen für funktionale Sicherheit abzudecken. Zu diesen Ressourcen gehören Fehlermöglichkeits- und Einflussanalysen (FMEA) sowie Sicherheitshandbücher. Die Geräte benötigen außerdem die Unterstützung eines qualifizierten Entwicklungsumfelds, um sicherheitskritische Anwendungen zu erstellen.
Abbildung 1: Zertifizierte Ressourcen für funktionale Sicherheit und Entwicklungsökosystem
Vorbereitung auf funktionale Sicherheit:
Moderne Automobile verwenden eine Vielzahl integrierter Schaltungen. Mikrocontroller (MCUs) sind in unterschiedlichsten Ausführungen weit verbreitet. Sie sind für alle elektronischen Steuergeräte (ECUs) erforderlich und werden im gesamten Fahrzeug eingesetzt, um Komfortfunktionen wie autonomes Fahren und viele weitere anspruchsvolle Funktionen zu ermöglichen. Das Spektrum reicht von 8-Bit-MCUs, die für Leistung, Energieeffizienz und Echtzeitsteuerung optimiert sind und über zusätzliche hardwarebasierte Touch-Schnittstellen verfügen, bis hin zu 32-Bit-MCUs, die Multithread-Anwendungen ausführen können und über Grafik-, Konnektivitäts- und Sicherheitsfunktionen verfügen. Darüber hinaus gibt es digitale Signalcontroller (DSCs), die eine MCU mit einem DSP kombinieren, um eine deterministische, robuste und schnelle Leistung für Sensoren, Motoren oder die Leistungswandlung zu gewährleisten. Jede dieser integrierten Schaltungen muss zunächst die vom Automotive Electronics Council (AEC) festgelegten Qualifizierungsstandards für Fertigung und Leistung in der Automobilindustrie erfüllen. Die AEC-Q100-Normen definieren ein Qualifizierungsverfahren, das auf Widerstandstests gegen Ausfallmechanismen in verschiedenen Temperaturbereichen basiert. Je nach Anwendung muss ein Mikrocontroller (MCU) die Anforderungen der AEC Q100-Klasse 2, 1 oder 0 erfüllen. Klasse 0 entspricht 150 °C, Klasse 1 125 °C und Klasse 2 105 °C.
Neben der AEC-Qualifizierung gelten je nach Gerät und Anwendung zusätzliche Anforderungen an spezifische funktionale Sicherheitsmerkmale. Beispielsweise verfügen 8-Bit-MCUs häufig über einen CAN-Bus für die Anbindung an Fahrzeugsysteme und intelligente Sensornetzwerke und werden häufig als Benutzerschnittstellen-Controller (UI-Controller) für mechanische und kapazitive Tasten im Fahrgastraum, am Lenkrad, in der Mittelkonsole oder als Teil eines schlüssellosen Zugangssystems eingesetzt. Die von diesen MCUs geforderten eingebetteten Hardware-Sicherheitsfunktionen beziehen sich typischerweise auf Speicher, Systemreset, sichere Codeausführung, sichere Kommunikation und den Schutz von Allzweck-Ein- und Ausgängen (GPIOs). Diese werden durch die Integration dedizierter, kernelunabhängiger Peripheriegeräte (CIPs) und anderer Funktionen wie Power-On-Reset (POR), Partial Power-Off-Reset (BOR), Windowed Watchdog Timer (WWDT) und Cyclic Redundancy Check (CRC) hinzugefügt, um die Betriebssicherheit und Zuverlässigkeit zu verbessern (siehe Abbildung 2).
Abbildung 2: 8-Bit-Mikrocontroller mit Hardwarefunktionen für funktionale Sicherheit.
Bei funktional sicheren 16-Bit-DSCs umfassen die erforderlichen Hardware-Sicherheitsfunktionen typischerweise einen Speicher mit Fehlererkennung und -korrektur, speicherintegrierte Selbstdiagnose (MBIST), redundante Takt- und Oszillatorsteuerung sowie weitere Funktionen zur Fehlererkennung, Selbstdiagnose, Systemdiagnose und Fehlerbehebung. Diese funktional sicheren Bausteine ermöglichen die Entwicklung leistungsstarker, sicherheitskritischer eingebetteter Anwendungen, Sensorverbindungen, digitaler Stromversorgungen und Motorsteuerungen. Typische Anwendungen sind DC/DC-Wandler, On-Board-Ladegeräte (OBCs), Aktoren und Sensoren (Position, Druck), Touch-Einheiten und andere Steuereinheiten, die den ASIL-B- oder ASIL-C-Standards entsprechen. Abbildung 3 zeigt ein Beispiel für die Merkmale eines funktional sicheren DSC.
Abbildung 3: Beispiel eines 16-Bit-DSC mit funktionaler Sicherheit.
Wie alle funktional sicheren Mikrocontroller benötigen auch 32-Bit-Mikrocontroller Hardwarefunktionen wie Fehlerkorrekturcode (ECC) im Speicher und Fehlereinspeisung, einen speicherintegrierten Selbsttest (MBIST), Timersysteme mit Backup-Oszillatoren und Taktfehlererkennung sowie GPIO-Pins mit ESD-Schutz (siehe Abbildung 4). Systemmonitore sind ebenfalls wichtig, darunter Hardware-Funktionalität für POR, BOR, WDT und CRC sowie eine Speicherschutzeinheit. 32-Bit-Mikrocontroller werden aufgrund ihrer funktionalen Sicherheit in einer Vielzahl von Anwendungen eingesetzt, von Fahrgastraumsystemen bis hin zu Fahrerassistenzsystemen (ADAS).
Abbildung 4: Beispiel eines für funktionale Sicherheit vorbereiteten 32-Bit-Mikrocontrollers.
Mit Standard-Mikrocontrollern und DSCs lassen sich sogar ASIL-C/D-Sicherheitsstufen erreichen, indem der Haupt-Mikrocontroller bzw. DSC mit einem sekundären oder Sicherheits-Coprozessor kombiniert wird. Dies geschieht mithilfe des ASIL-Dekompositionsprinzips: Durch die Kombination zweier ASIL-B-konformer Subsysteme kann eine höhere ASIL-Stufe wie ASIL C/D erreicht werden:
ASIL C = ASIL B (C) + ASIL A (C)
ASIL D = ASIL B (D) + ASIL B (D) = ASIL C (D) + ASIL A (D)
Die Aufteilung erfolgt durch die Segmentierung der Sicherheitsanforderungen auf die einzelnen Geräte.
Entwicklungswerkzeuge und Zertifizierungsunterstützung:
Design-Toolpakete, die im Rahmen eines umfassenden Entwicklungsökosystems für funktionale Sicherheit zertifiziert sind, erleichtern die Einhaltung der in ISO 26262 festgelegten Verifizierungs- und Validierungsanforderungen. Dies gilt insbesondere für MCU- und DSC-basierte Designs. Tool-Anbieter arbeiten mit unabhängigen Prüf- und Zertifizierungsstellen zusammen, um Compiler für funktionale Sicherheit zu zertifizieren. Dazu gehören in der Regel zusätzliche Dokumente wie ein Zertifikat, ein Handbuch zur funktionalen Sicherheit, ein Sicherheitsplan sowie Klassifizierungs- und Qualifizierungsberichte für Compiler, die integrierte Entwicklungsumgebung (IDE) und Debugger und Programmierer. Dieses Dokumentationspaket vereinfacht die Tool-Qualifizierung und die abschließende Anwendungszertifizierung.
Idealerweise sollte im Designprozess auch ein Code-Coverage-Tool eingesetzt werden, um zu messen, wie gut der Code getestet wurde und welche Teile der Software ausgeführt wurden. Das Code-Coverage-Tool sollte ebenfalls in den Klassifizierungs- und Qualifizierungsberichten enthalten sein. Achten Sie auf ein Tool, das Tests in einem einzigen Durchlauf durchführen kann, ohne den Code in Blöcke zu zerlegen und umfangreiche Hardware-Modifikationen, teure Software oder einen erheblichen Aufwand für die Suche nach relevanten Informationen in großen Datendateien zu erfordern. Die Zertifizierung von Anwendungen erfordert Code-Testdaten. Daher spielen Tools zur Codeabdeckung in einem Durchgang eine entscheidende Rolle, um den Prozess zu optimieren und die Markteinführungszeit zu verkürzen.
Um eine Automobilanwendung gemäß ISO 26262 zu entwickeln, benötigt ein Ingenieur neben dem Datenblatt des Bauteils weitere Ressourcen vom Halbleiterlieferanten. Die Verfügbarkeit von Paketen für funktionale Sicherheit bietet OEMs und Automobilzulieferern die benötigten Ressourcen in verschiedenen Phasen des Evaluierungs- und Entwicklungszyklus. Diese Pakete sollten zertifizierte Sicherheitshandbücher, FMEDA-Berichte und gegebenenfalls Diagnosesoftware wie zertifizierte Selbsttestbibliotheken für die relevanten ASILs enthalten.
Der FMEDA-Bericht quantifiziert die Fehlermodi des Bauteils, seine Ausfallratenverteilung über die Zeit (FIT) und die entsprechenden Erkennungsmethoden, um die Erstellung eines Abdeckungsplans zu unterstützen. Eine weitere wichtige Ressource ist das Sicherheitshandbuch (SM). Es enthält detaillierte Informationen zu den im FMEDA-Bericht genannten Fehlererkennungsmethoden und gibt Empfehlungen für einen sichereren Betrieb des Bauteils. Es beschreibt abhängige Fehler und Hardwarefunktionen zur Erkennung systematischer Fehler, die zur Entwicklung von Diagnosebibliotheken genutzt werden können. Funktionale Sicherheitsdiagnosebibliotheken helfen bei der Beurteilung des Betriebszustands eines Systems unter Fehlerbedingungen, der Erkennung zufälliger Systemausfälle und der Erreichung funktionaler Sicherheitsziele. Die Auswahl eines Geräts mit einem von einem Drittanbieter zertifizierten FMEDA-Bericht und Sicherheitshandbuch sowie Diagnosebibliotheken vereinfacht die Zertifizierung sicherheitskritischer Anwendungen.
Die Entwicklung einer solchen Anwendung beginnt mit der Definition der Sicherheitsziele und des gewünschten Sicherheitsniveaus. Ein Basispaket für funktionale Sicherheit stellt wichtige Ressourcen wie FMEDA, ein Sicherheitshandbuch und Zertifizierungen bereit, um die angestrebten funktionalen Sicherheitsniveaus zu bewerten und eine sicherheitskritische Automobilanwendung zu entwickeln.
Ein solches Basispaket für ein MCU-basiertes Design sollte idealerweise einen ASIL B Ready-zertifizierten FMEDA-Bericht, ein Sicherheitshandbuch und ASIL B/C-konforme Diagnosebibliotheken sowie eine Referenzanwendung enthalten. Diese hilft Entwicklern zu verstehen, wie diese Ressourcen zur Entwicklung einer sicherheitskritischen Anwendung gemäß ISO 26262 eingesetzt werden können. Ein Starterpaket beschleunigt den Entwicklungszyklus und ermöglicht die Entwicklung einer ASIL B- oder C-konformen Anwendung.
Ein umfassendes Paket für funktionale Sicherheit erweitert das Angebot um zertifizierte Diagnosebibliotheken mit Quellcode und Sicherheitsanalysen für Designs bis ASIL B/C. Da viele Endkunden die Zertifizierung sicherheitskritischer Anwendungen fordern, beschleunigt dieses Paket den Zertifizierungsprozess.
Automobile werden immer komplexer und ihr Elektronikanteil steigt stetig. Daher ist es zunehmend wichtig, dass funktional sichere Produkte für Automobilanwendungen Entwicklungsökosysteme unterstützen, die zertifizierte Ressourcen für funktionale Sicherheit gemäß ISO 26262 bereitstellen. Hersteller integrierter Schaltungen können Automobilkunden zudem helfen, ihre langfristigen Investitionen in diesen anspruchsvollen Entwicklungs- und Zertifizierungsprozess zu schützen. Sie garantieren die Lieferung von Bauteilen für zertifizierte Systeme, solange der Kunde diese bestellt. So wird das Risiko einer erzwungenen Neuentwicklung aufgrund des unerwarteten Lebensendes eines Bauteils (EOL) vermieden. Dies stärkt das Vertrauen, dass die Zertifizierung nicht nur schnell und einfach, sondern auch nur einmalig durchgeführt werden muss.
AUTOR: Jacob Lunn Lassen, Technischer Ingenieur, Funktionale Sicherheit bei Microchip Technology
Microchip Technology Incorporated
