Safety-kritische ASICs und SoCs für Automotive-Systeme entwickeln

Mit dem Aufkommen von ADAS und AD hat sich die Automobilelektronik zu einem der am schnellsten wachsenden Marktsegmente entwickelt. Hier haben diese fortschrittlichen Technologien zum Einsatz komplexer ICs und SoCs in großem Stil geführt, bei denen Digital-, Analog- und HF-Technik sowie Powermanagement in einem einzigen Chip enthalten sind. Dadurch werden kritische Sicherheitsfunktionen, die bei einem Ausfall beziehungsweise einer Fehlfunktion zu schweren Unfällen führen können, auf dem Chip verwaltet.

Bild 1: Bericht der Fahrzeugbehörde von Kalifornien 2018 über das Eingreifen bei autonomen Fahrzeugfunktionen Ensilica

ADAS erfordern ein hohes Maß an Sicherheit bei gleichzeitiger Integration grundlegender Techniken wie Radar, präziser Positionsbestimmung und/oder Funkkommunikation – bei beengten Platzverhältnissen und den Forderungen geringer Stromverbrauch sowie geringe Kosten. Aus diesem Grund müssen sich Fahrzeug- und Systemhersteller für SoCs entscheiden.

Schon vor dem Sicherheitsmanagement ist die Entwicklung von ICs, die Rechenleistung liefern und auf wenigen Quadratmillimetern Embedded-Software ausführen, eine große Herausforderung. Um zu gewährleisten, dass das Endprodukt neben der beabsichtigten Funktion auch die erforderlichen Sicherheitsstandards erfüllt, sind die Koordination verschiedener Fertigkeiten und ein sehr strenger Prozess erforderlich. Kurz gesagt, wenn ein Fehler katastrophale Folgen haben könnte, müssen herkömmliche Hard- und Software-Entwicklungsmethoden aktualisiert werden.

ISO 26262: jetzt mit Teil 11

Zu den wichtigsten Branchenstandards, die sich mit der Entwicklung sicherheitskritischer Elektronik befassen, gehören die Mehrzweck-Norm IEC 61508 und seit 2011 die anwendungsspezifische Automotive-Norm ISO 26262. Die Umstellung von IEC 61508 auf ISO 26262 resultierte aus der Natur des Automobilsektors: Serienfertigung und verteilte Entwicklung bei mehreren Zulieferern. Die ursprünglich in zehn Teile gegliederte ISO 26262 befasste sich mit den verschiedenen Aspekten des gesamten Produktlebenszyklus –  vom Konzept bis zum Teil 5 für die Hardwareentwicklung. Seit der Erstveröffentlichung gab es jedoch zahlreiche Kritiker aus der Elektronikbranche, die die IC-Entwicklung und Sicherheit der beabsichtigten Funktion (SOTIF; Safety of the Intended Function) als nicht ausreichend behandelt ansahen.

Als Reaktion darauf hat die ISO im vergangenen Jahr Teil 11 hinzugefügt, der sich der Halbleiterentwicklung widmet und eine umfassende Interpretation darüber bietet, wie das IC-Design im Rahmen der ISO 26262 interpretiert werden muss. Anfang 2019 erschien eine neue ergänzende Norm (ISO/PAS 21448), die sich mit SOTIF befasst und Themen wie den Missbrauch von Systemen aufgrund menschlicher Fehler abdeckt.

Zusammen geben diese beiden Aktualisierungen (mit jahrelangem Hinzulernen und Verfeinern) der Automobilindustrie einen umfassenden Satz an Normen für die Betriebssicherheit (Safety) von Elektroniksystemen (einschließlich SoCs), wobei die meisten Autohersteller festlegen, dass ihre Tier-1-Zulieferer von ECUs die ISO-26262-Bestimmungen für sicherheitsrelevante Systeme einhalten.

Status bei ADAS und autonomen Systemen

Die Folgen eines Ausfalls von autonomen Fahrfunktionen beziehungsweise von ADAS sind bereits gut dokumentiert. Letztes Jahr kam es zum ersten Mal zu einem Todesfall mit einem (bedingt autonomen) Level-3-Fahrzeug, bei dem ein Fußgänger von einem selbstfahrenden Uber-Fahrzeug getötet wurde. Hinzu kommen fünf weitere Todesfälle seit 2016, die durch (teilautonome) Level-2-Fahrzeuge zu beklagen sind, die alle einen Tesla-Autopiloten beinhalten.

Betrachtet man zunächst Systeme der Stufe 1 (Level 1), so deutet eine Analyse von 5000 Unfällen in den USA im Jahr 2017 darauf hin, dass ADAS-Funktionen wie Spurhalte- und Toter-Winkel-Warnungen die Unfallrate um 11 Prozent und die Verletzungsrate um 21 Prozent verringert haben.

Bezüglich der Stufe 2 gab es zwar Todesfälle, aber diese fünf Todesfälle lassen sich nur im Kontext umfassend erklären. Erstens schreibt Tesla vor, dass eine Person jederzeit die Kontrolle über den Autopiloten haben muss, und zweitens berichtete Tesla im November 2018, dass ihre Autopilot-Technik für halb selbstfahrende Autos bereits 1 Mrd. Meilen (1,6 Mrd. Kilometer) im Einsatz ist. Zu dieser Zeit gab es nur drei Todesfälle (was 0,3 Todesfällen pro 100 Mio. Meilen entspricht). Dies steht im Vergleich zu 1,18 Todesfällen pro 100 Mio. Meilen (160 Mio. Kilometer), die in den USA von menschengesteuerten Autos verursacht wurden (Daten von 2016). Ähnlich berichtete Tesla im April 2019, dass für Autos mit Autopilot im ersten Quartal 2019 ein Unfall pro 2,87 Mio.  Meilen (4,59 Mio. Kilometer) verzeichnet wurde – gegenüber einem Unfall pro 1,76 Mio. Meilen (2,82 Mio. Kilometer), die ohne Autopilot gefahren wurden.

Um den Stand der Software für autonomes Fahren der Stufe 3+ zu messen, lohnt ein Blick nach Kalifornien, das Herstellern autonomer Fahrzeuge vorschreibt, die Anzahl der manuellen Eingriffe auf den Straßen pro Jahr sowie die zurückgelegte Strecke zu erfassen und zu veröffentlichen. Das führende Unternehmen Waymo (Googles ehemalige Abteilung für autonomes Fahren) verzeichnete dabei einen Eingriff pro 11.000 Meilen (17.600 Kilometer). Zwischen den Entwicklungen besteht jedoch eine hohe Bandbreite, wobei das schlechteste Unternehmen drei Eingriffe pro Meile (zwei pro Kilometer) verzeichnete.

Sind Änderungen an sicherheitskritischen Systemen erforderlich?

Bild 2: Wie universell ist die Ethik hinter den Entscheidungen autonomer Fahrzeuge? Laut veröffentlichten Daten von Nature 2018. Ensilica/Nature

Im Vergleich zu Consumer-Produkten erfordert die Entwicklung sicherheitskritischer ICs einen erheblichen zusätzlichen Aufwand in Bezug auf Projektmanagement, Entwicklung, Dokumentation und Tools. Ein sicherheitskritisches Design muss sowohl eine optimale Lösung für die geforderte Systemfunktion bieten als auch dokumentieren, wie diese Lösung fehlschlagen beziehungsweise ausfallen kann. Außerdem gilt es, sowohl die Folgen eines Ausfalls aufzuzeigen als auch, wie sich das Risiko auf ein akzeptables Maß reduzieren lässt.

Die ISO 26262 ermöglicht (wie alle Sicherheitsnormen) die Analyse eines Systems und dessen mögliche Störungen. Die Norm zeigt auf, dass ausreichende Maßnahmen getroffen wurden, um die Systemsicherheit zu gewährleisten, und bietet einen konsistenten Prozess mit angemessener Dokumentation und Rückverfolgbarkeit.

Die SoC-Entwicklung erfordert daher verschiedene Fertigkeiten von der Systemarchitektur über die Hardware-/Software-Partitionierung und -Entwicklung bis hin zur Verifizierung und Fertigung – und jede hat spezielle Auswirkungen auf ein sicherheitskritisches Produkt.

Für die Hardwareentwicklung ist neben dem herkömmlichen simulationsbasierenden Ansatz (anhand von RTL-Beschreibungen oder Schaltplänen) auch eine Bewertung erforderlich. Diese zeigt auf, wie sich fehlerhafte beziehungsweise ausfallende Teilblöcke kombinieren lassen, um ein Sicherheitsziel zu verletzen, wobei die erforderlichen Abhilfemaßnahmen vorgeschlagen werden. Die Quantifizierung von Zufalls- und Softfehlern und deren Auswirkung auf die verschiedenen Chipstrukturen muss daher durchgeführt werden – eine herausfordernde Aufgabe in einem Baustein mit mehreren Millionen Gattern.

Auch die Softwareentwicklung ist eine Herausforderung für alle sicherheitskritischen Anwendungen. Das wohl auffälligste Beispiel der jüngsten Zeit stammt aus der Luftfahrt, wo die Abstürze der Boeing 737 Max auf Softwarefehler zurückzuführen sind. In ADAS-Anwendungen müssen Entwickler nicht nur Fehler minimieren: der erste Todesfall in den USA wurde durch einen Softwarefehler verursacht, der sowohl die Bilddaten (ein weißer Anhänger, der die Straße überquerte, wurde als Himmel erkannt) als auch die Radardaten falsch interpretiert hatte. Entwickler müssen auch komplexere ethische Überlegungen anstellen, die durch moralische Entscheidungen erschwert werden, die zwischen den Regionen variieren (Bild 2).

Soll ein Software-Image in ein SoC-ROM integriert werden, wird die Aufgabe besonders schwierig. Zum Erfüllen der Sicherheitsnormen ist ein robuster Prozess unerlässlich, um die Software zu spezifizieren, zu codieren, zu dokumentieren und zu verifizieren. Die empfohlenen Software-Codierungsmethoden weisen auf einige Einschränkungen bei bestimmten Sprachen wie beispielsweise MISRA-C hin. Qualitätskennwerte wie Code- oder Bedingungsabdeckung oder die Notwendigkeit, jede Softwareeinheit (einzeln) auf ihre Anforderungen zu testen, sind häufig erforderlich. Alle diese Schritte werden für die Einhaltung der ISO 26262 und IEC 61508 verlangt.

Bild 3: Der Prozess der Sicherheitsanalyse beschreibt den Arbeitsablauf und führt zu einer unabhängigen Bestätigung durch Dritte, wie dies in den einschlägigen Normen gefordert wird. Ensilica

Sicherheitsnormen berühren auch bestimmte organisatorische Aspekte. Das Prinzip, dass „für jede Arbeit der Prüfer unabhängig vom Autor sein muss“, ist in allen Sicherheitsnormen festgelegt. Der Grad an Unabhängigkeit variiert jedoch zwischen diesen beiden Normen – und anderen wie DO-167 für Luftfahrtelektronik sowie ISO 62304 für medizintechnische Systeme. Der letzte Schritt in diesem Prozess besteht darin, einem Kunden/Projektpartner zu demonstrieren, dass ein SoC sicher ist.

Sicherheitsnormen verlangen, dass die beteiligten Projekte einer unabhängigen Bewertung unterzogen werden, wobei je nach Sicherheitsniveau spezifische Varianten möglich sind. Zur Überprüfung des Sicherheitsnachweises ist ein unabhängiger Prüfer erforderlich: die Sammlung von Dokumenten und Arbeitsergebnissen, aus denen hervorgeht, dass ein Projekt gemäß der geltenden Norm ordnungsgemäß durchgeführt wurde.

Überlegungen zur Entwicklung Safety-kritischer ASICs/SoCs

Viele Unternehmen halten sich an internationale Qualitätsstandards mit einem Zertifikat nach ISO 9001:2015, das garantiert, dass alle Geschäftsaktivitäten im Einklang mit strengen Prozessen ausgeführt werden. Die Einhaltung von Sicherheitsstandards wie ISO 26262 oder IEC 61508 erfordert jedoch etwas mehr.

Ein wichtiger Schritt in jedem sicherheitskritischen ASIC oder SoC ist die Auswahl der EDA-Tools für die Logiksynthese, Simulation, physikalische Implementierung und Verifikation, die den von den beteiligten Normen geforderten Validierungsprozess bereits bestanden haben sollten.

In ähnlicher Weise sollte während des gesamten Prozesses ein Prozess auf Basis des V-Modells zur Entwicklung sicherheitskritischer SoCs zur Anwendung kommen – vom Konzept bis zur endgültigen Fertigung. Dies sorgt für robuste Prozesse beim Dokumentations- und Konfigurationsmanagement sowie bei der Rückverfolgbarkeit und stellt sicher, dass strenge Hardware- und Software-Verifikationsprozesse in speziellen Genehmigungssitzungen mit allen Projektbeteiligten durchgeführt werden.

Jedes sicherheitskritische Projekt erfordert einen Sicherheitsanalyseprozess. Hierbei spielt das Fachwissen der Entwickler eine entscheidende Rolle, um zu verstehen, was in einem Schaltkreis oder IP-Block (et cetera) schiefgehen kann, damit sich die notwendigen Schadensbegrenzungsmaßnahmen umsetzen lassen (Bild 3).

Um die Wirksamkeit der ausgewählten Sicherheitsmaßnahmen zu überprüfen, ist gemäß ISO 26262 (und allen Sicherheitsnormen) ein zusätzlicher Schritt erforderlich. Im Fall eines komplexen SoC sind spezielle Softwaretools für die Fehlerinjektion erforderlich. Diese ermöglichen die Simulation häufig auftretender Fehler (sowohl zufällige als auch Softfehler) und prüfen, ob sie ordnungsgemäß erkannt und/oder korrigiert werden, sodass ein sicheres Systemverhalten gewährleistet ist.

Co-Simulation statt Debugging

Natürlich können komplexe SoCs die Verarbeitung von IP wie MCUs oder DSPs beinhalten, und ihr Verhalten hängt oft von einem Software-Image ab, das in Form von ROM, OTP et cetera im Chip codiert ist. Das Debuggen von Embedded-Software war schon immer eine Herausforderung und diese nimmt erheblich zu, wenn sich das Code-Image in einem Chip befindet, was herkömmliche Debugging-Tools unbrauchbar macht. Stattdessen sind Co-Simulationsmodelle für die Hardware und Software erforderlich, die eine ganzheitliche Betrachtung des gesamten Systemverhaltens ermöglichen – noch bevor der eigentliche Chip zur Verfügung steht.

Ein letzter entscheidender Aspekt bei der Entwicklung sicherheitskritischer Systeme sowohl bei Zulieferern als auch intern besteht darin, dass Halbleiterhersteller und Zulieferer nachweislich in der Lage sein müssen, Bauteile gemäß den Automotive-Sicherheitsstandards herzustellen. Dabei sollte ein Kommunikationsfluss zwischen Lieferanten und Kunden etabliert werden, der die strengen Regeln für Sicherheitspläne und Entwicklungsschnittstellen-Vereinbarungen (DIA; Development Interface Agreements) einhält.

Für die interne Organisation ist eine projektunabhängige Managementstruktur im Rahmen der funktionalen Sicherheit (FuSa; Functional Safety)  erforderlich, die die notwendige Unabhängigkeit beim Einrichten von FuSa-Prozessen schafft und allen an sicherheitskritischen Produkten beteiligten Entwicklern die erforderliche Schulung und Unterstützung bietet.

(av)