Fahrzeuge werden durch Fahrerassistenzsysteme (ADAS, Advanced Driver Assistance Systems), Echtzeit-Informationen, Vernetzung (Car-2-X) und Sensoren immer intelligenter. Entwickler müssen deshalb ständig neue Anforderungen hinsichtlich der Ausfall- und Daten-Sicherheit und der Systemintegration berücksichtigen. Gleichzeitig sind Gesetzesvorgaben hinsichtlich der Sicherheit (Euro NCAP, European New Car Assessment Programme) und strengere Emissionsrichtlinien Folge zu beachten.
Um all diese Innovationen auch im Fahrzeug umzusetzen, müssen mehrere Fahrzeugfunktionen in integrierte Steuergeräte zusammengefasst werden. Das hat vor allem für den OEM Vorteile, wie zum Beispiel eine höhere Integration verbunden mit niedrigeren Kosten, eine höhere Performance und einen besserer IP-Schutz. Außerdem ergibt sich daraus eine geringere Leistungsaufnahme, was die Emissionen reduziert, eine höhere Ausfallsicherheit, die zu einer erhöhten Fahrzeug-
sicherheit führt und ein kleinerer Formfaktor für niedrigeres Gewicht und eine bessere Bauraumausnutzung. Damit verschiebt sich der Integrationspunkt von der ECU-Leiterplatte mit diskreten Bauelementen in den Chip hinein. Erschwerend kommt hinzu, dass die Entwicklung über eine komplexe Zulieferkette von Anbietern verteilt ist. IP-Entwickler interagieren mit Tier-2 Halbleiter- und Software-Entwickler, die ihrerseits Produkte an Tier-1-Systemintegratoren liefern, welche dann Steuergeräte an die Fahrzeughersteller liefern.
Verifikation der Funktionalität
Bei der Entwicklung eines System-on-Chip (SoC) kann es durchaus ein bis zwei Jahre dauern, bis ein Test-Chip vorliegt. Die System-Entwickler wollen aber bereits zu einem frühen Zeitpunkt mit der Software-Entwicklung und deren Absicherung beginnen. Die Tools, die bei einem OEM zum Einsatz kommen, eignen sich allerdings nicht, um Funktionen in einem SoC zu validieren. Es zeichnet sich bereits jetzt ab, dass eine größere Anpassung (Re-Tooling) der Werkzeuge innerhalb der Zulieferkette von Nöten ist.
Die Chip-Entwicklung selbst kann in Verifikation
(Simulation) und Implementierung (Layout) aufgeteilt werden. Verifikation ist der Prozess, der die korrekte Umsetzung von funktionalen Anforderungen des Designs in verifizierte Hardware-Beschreibungssprachen wie zum Beispiel Verilog oder VHDL (Very High Speed Integrated Circuit Hardware Description Language) überprüft. Die Umsetzung der Systembeschreibung von SystemC oder Matlab/Simulink in VHDL oder Verilog erfolgt entweder manuell, automatisiert mittels eines High-Level Synthese Tools oder direkt aus Simulink. Das verifizierte Design ist der Startpunkt für die Implementierung bis zu den finalen Chipdaten (GDSII-Format, Graphic Data System II) für die Chipproduktion.
In der Chip-Entwicklung für die Automobilindustrie gehen Verifikation der Funktion und der Sicherheit Hand in Hand. Neben der Funktionalität, müssen auch Sicherheitsanforderungen spezifiziert werden. Für die Verifikation des Chips können Entwickler vier wichtige Entwicklungswerkzeuge nutzen: die formale Verifikation, die softwarebasierte Simulation auf Transaktions- (SystemC) oder auf der Registerebene (RTL, Register Transfer Level), die hardwarebasierte Ausführung inklusive HW/SW-Verifikation mittels Emulation und das
FPGA-basierte Prototyping. Abbildung 1 zeigt die Hauptkomponenten mit ihrer Verifikations-Infrastruktur sowie einige der Integrationspunkte zwischen den Entwicklungswerkzeugen. Darunter fallen zum Beispiel die Simulationsbeschleunigung – eine Kombination von RTL-Simulation und Emulation – und die hybride Kombination von virtuellen Prototypen und RTL-Simulation oder Emulation, um die Software-Entwicklung und virtuelle Hardware-in-the-Loop(HIL)-Ausführung zu ermöglichen.
Zur Infrastruktur der Verifikation gehören Verifikation-IPs, um IP-Blöcke und ihre korrekte Integration in die Systemumgebung zu verifizieren, eine hardwaregetriebene Verifikation, die Ergebnisse aus allen Entwicklungswerkzeugen kombiniert, sowie softwaregetriebene Tests zum Überprüfen der Systemintegration. Des Weiteren wird eine gemeinsame Benutzerschnittstelle für alle Entwicklungswerkzeuge für das Debuggen von Fehlern und deren Beseitigung benötigt. Mit der optimalen Kombination von Entwicklungswerkzeugen, können die Anwender den Gesamtdurchsatz der Verifikation verbessern und so schneller das System absichern.
Verifikation der Sicherheitsanforderungen
Neben der funktionalen Verifikation ist die Verifikation der Sicherheitsanforderungen für Standards wie ISO 26262 ein zentrales Thema. Unter Berücksichtigung der Anforderungen auf Systemebene müssen „Failures-in-Time“ (FIT) auf der Chip-Ebene reduziert werden. Ausfallarten aus der Failure Mode, Effects and Diagnostic Analysis (FMEDA) müssen in Sicherheitsanforderungen umgewandelt werden. Funktionsprüfungen bestätigen, dass die funktionalen Vorgaben erreicht wurden. Darüber hinaus bestätigen Analysen, basierend auf statistischen Fehlern und zulässigen Fehlerraten, dass auch
Sicherheitsanforderungen erfüllt wurden.
Abbildung 2 zeigt einen Design-Flow für die dynamische Verifikation der funktionalen Sicherheit. Die Eingangsdaten umfassen das Design mit seiner Testumgebung, eine Liste der zu injizierenden Fehler und entsprechende Beobachtungspunkte. Das Design wird anschließend instrumentiert, sprich Referenzergebnisse werden von einer bekannten guten Simulation an den Beobachtungspunkten ermittelt. Anschließend werden innerhalb des Simulations- oder Emulationsprozesses Fehler injiziert und die Ergebnisse an den Beobachtungspunkten verglichen. Unterscheiden sich die Ergebnisse an den Beobachtungspunkten, wurde der injizierte Fehler erkannt. In den resultierenden Berichten sind entsprechende Fehlerstatistiken aufgeführt, die detailliert zeigen, welche und wie viele der Fehler erkannt wurden. Der Design-Flow für die dynamische Fehlererkennung ist Teil einer komplexeren Entwicklungsumgebung, die mit einer Sicherheitsspezifikation inklusive Sicherheitsziele beginnt und mittels Fehlersimulation frühzeitig Probleme in der funktionalen Spezifikation detektiert. Die statische, formale Verifikation wird auch dazu verwendet, um Fehler vorzuqualifizieren und nicht testbare Fehler aus der Datenbank zu entfernen, und damit unnötige Fehlersimulationen zu vermeiden.
Für die Entwicklung von Infotainment- oder Fahrerassistenz-Systemen wird ein großer Teil der Funktionalität in Software ausgeführt, die sowohl in der Verifikation der Funktionalität als auch der Sicherheitsanforderungen berücksichtigt werden muss. Dazu sollte die Software so früh wie möglich mit der Hardware integriert werden.
Schneller mit virtuellen Prototypen
Virtuelle Prototypen auf Transaktionsebene erlauben es wenige Wochen nachdem die Spezifikation verfügbar ist, mit der Software-Entwicklung zu beginnen. Sie ermöglichen gutes Software-Debuggen und die Kontrolle der Simulation und oft der schnellste Weg, um Software für einen neuen SoC zu entwickeln. Sie erlauben aber keine detaillierte Beschreibung oder Debugging der Hardware, welches die Stärke der RTL-Simulation und Emulation ist. Die Entwicklungsumgebungen für die Automobilindustrie müssen sich den neuesten Entwicklungen entsprechend anpassen beziehungsweise erweitert werden. Dazu gehört, sowohl die Software-Entwicklung vor der Verfügbarkeit des Siliziums zu ermöglichen als auch die Überprüfung der funktionalen Sicherheitsanforderungen per Simulation.
Hinzu kommt die Möglichkeit, verschiedene Entwicklungswerkzeuge zu kombinieren. Hierbei können hardwareunterstützte Entwicklungswerkzeuge wie Emulation und FPGA-basiertes Prototyping eingesetzt werden, die die Verifikation der Funktionalität und der Sicherheitsanforderungen beschleunigen, und damit den Entwicklern wertvolle Entwicklungszeit zurückgeben.
