Von Ann Keffer, Arun Gogineni und James Kim
Autos, die ADAS- und AV-Funktionen einsetzen, sind auf komplexe digitale und analoge Systeme angewiesen, um kritische Echtzeitanwendungen auszuführen. Die große Anzahl an Fehlern, die in diesen modernen Automobilkonstruktionen getestet werden müssen, macht die Durchführung einer Sicherheitsüberprüfung mit einer einzigen Technologie unpraktisch.
Dennoch ist die Entwicklung einer optimierten Sicherheitsmethodik mit spezifischen Fehlerlisten, die automatisch für Simulation, Emulation und formale Zwecke vorgesehen sind, eine Herausforderung. Eine weitere Herausforderung besteht darin, Fehlerlösungsergebnisse aus verschiedenen Fehlerinjektionsläufen für die endgültige Metrikberechnung zu konsolidieren.
Die gute Nachricht ist, dass die Interoperabilität von Fault-Injection-Engines, Optimierungstechniken und einem automatisierten Ablauf die Gesamtausführungszeit effektiv reduzieren kann, um den Kreis von der Sicherheitsanalyse bis zur Sicherheitszertifizierung schnell zu schließen.
Abbildung 1 zeigt einige der Optimierungstechniken in einem Sicherheitsfluss. Fortschrittliche Methoden wie Sicherheitsanalyse zur Optimierung und Fehlerbereinigung, gleichzeitige Fehlersimulation, Fehleremulation und formalbasierte Analyse können eingesetzt werden, um die Sicherheitsanforderungen für ein Automobil-SoC zu validieren.
Feige. 1: Fehler Liste Optimierung Techniken.
Proof of Concept: ein Automotive-SoC
Anhand eines Testfalls auf SoC-Ebene werden wir demonstrieren, wie dieser automatisierte, mehrmotorige Ablauf die große Anzahl von Fehlern bewältigt, die in fortschrittlichen Automobildesigns getestet werden müssen. Das in diesem Testfall verwendete SoC-Design hatte etwa drei Millionen Gates. Zunächst verwendeten wir sowohl Simulations- als auch Emulations-Fehlerinjektions-Engines, um die Fehlerkampagnen für endgültige Metriken effizient abzuschließen. Anschließend führten wir im Rahmen der Fertigstellung der gesamten Fehlerinjektion eine formale Analyse durch.
Feige. 2: Automotive SoC Top-Level Schutzmassnahmen bei Diagramm.
Abbildung 3 ist eine Darstellung des Sicherheitsinselblocks aus Abbildung 2. Die farbcodierten Bereiche zeigen, wo Simulation, Emulation und formale Engines für die Fehlerinjektion und Fehlerklassifizierung verwendet wurden.
Feige. 3: Detailliert Sicherheitsinsel Schutzmassnahmen bei Diagramm.
Die Fehlerinjektion mittels Simulation war für den CPU-Kern und die Cache-Speicherblöcke zu zeit- und ressourcenintensiv. Aus Effizienzgründen wurden diese Blöcke für die Fehlerinjektion mit einer Emulations-Engine vorgesehen. Der CPU-Kern ist durch eine Softwaretestbibliothek (STL) geschützt und der Cache-Speicher ist durch ECC geschützt. Die Busschnittstelle erfordert einen End-to-End-Schutz, bei dem sich die Fehlerinjektion mit Simulation als effizient erwiesen hat. Die Fehlermanagementeinheit war nicht Teil dieses Experiments. Als nächster Schritt wird die Fehlerinjektion für die Fehlermanagementeinheit mithilfe formaler Technologie abgeschlossen.
Tabelle 1 zeigt die Registeranzahl für die Blöcke in der Sicherheitsinsel.
Tabelle 1: Anzahl der Blockregister.
Die für jeden dieser Blöcke generierten Fehlerlisten wurden optimiert, um sich auf die sicherheitskritischen Knoten zu konzentrieren, die über Sicherheitsmechanismen/Schutz verfügen.
SafetyScope, ein Sicherheitsanalysetool, wurde ausgeführt, um die Fehlerlisten für die FMs sowohl für die Veloce Fault App (Fehleremulator) als auch für den Fehlersimulator zu erstellen, und schrieb die Fehlerlisten in die Datenbank für funktionale Sicherheit (FuSa).
Für die CPU- und Cache-Speicherblöcke gibt der Emulator die synthetisierten Blöcke und Fehlerinjektions-/Fehlererkennungsnetze (FIN/FDN) ein. Als nächstes führte es den Stimulus aus und erfasste die Zustände aller FDNs. Die Zustände wurden gespeichert und als „Gold“-Referenz zum Vergleich mit Fehlerinjektionsläufen verwendet. Für jeden in der optimierten Fehlerliste aufgeführten Fehler wurde das fehlerhafte Verhalten emuliert, die FDNs mit den während des Golden Run generierten Referenzwerten verglichen und die Ergebnisse klassifiziert und in der Fehlerdatenbank mit Attributen aktualisiert.
Abb. 4: CPU-Cluster. (Quelle für https://developer.arm.com/Processors/Cortex-R52)
Für jedes der im Blockdiagramm dargestellten Unterteile haben wir mithilfe der Analyse-Engine eine optimierte Fehlerliste erstellt. Die Fehlerlisten werden sitzungsspezifisch in der FuSa-Datenbank gespeichert. Zur Generierung der Zufallsstichprobe aus der FuSa-Datenbank haben wir die statistische Zufallsstichprobe der gesamten Störungen genutzt.
Schauen wir uns nun an, was passiert, wenn wir mithilfe der Emulation eine Zufallsstichprobe während der gesamten Fehlerinjektion ziehen. Damit dies jedoch die Fehlerinjektion vollständig abschließt, haben wir N Proben verarbeitet.
Tisch 2: Erkannte Fehler by Sicherheit Mechanismen.
Tabelle 3 zeigt, dass die Gesamtfehlerverteilung für alle Fehler mit der Fehlerverteilung der zufällig ausgewählten Fehler übereinstimmt. Die Tabelle erfasst außerdem die insgesamt erkannten Fehler von 3125 von insgesamt 4782 Fehlern. Wir konnten auch die erkannten Fehler pro Unterteil modellieren und eine Gesamtquote der erkannten Fehler von 65.35 % liefern. Basierend auf den Fehlern in der Zufallsstichprobe und unserem Abdeckungsziel von 90 % haben wir berechnet, dass die Fehlermarge (MOE) ±1.19 % beträgt.
Tisch 3: Ergebnisse der Fehlerinjektion in CPU und Cache-Speicher.
Die insgesamt erkannten (beobachteten + unbeobachteten) 3125 Fehler ermöglichen eine eindeutige Fehlerklassifizierung. Die unerkannt beobachteten Fehler liefern auch eine eindeutige Klassifizierung für Restfehler. Wir führten eine weitere Analyse unerkannter, unbeobachteter und nicht injizierter Fehler durch.
Tisch 4: Fehler Einstufung nachdem Fehler Injektion.
Wir haben viele Debug-Techniken verwendet, um die 616 nicht erkannten, nicht beobachteten Fehler zu analysieren. Zunächst verwendeten wir eine formale Analyse, um den Einflusskegel (COI) dieser UU-Verwerfungen zu überprüfen. Die Verwerfungen, die außerhalb des COI lagen, wurden als sicher eingestuft, und es gab fünf Verwerfungen, die weiter aus der Analyse ausgeschlossen wurden. Für die Fehler, die sich innerhalb des COI befanden, verwendeten wir technisches Urteilsvermögen mit Begründung verschiedener Konfigurationen wie ECC, Timer, Flash-Speicher usw. Schließlich konnten wir mithilfe formaler und technischer Urteilsvermögen 616 UU-Fehler weiter in sichere Fehler und verbleibende Fehler klassifizieren UU-Störungen in konservativ verbleibende Störungen. Wir haben auch die 79 Restfehler überprüft und konnten 10 Fehler als sichere Fehler klassifizieren. Die nicht injizierten Fehler wurden auch mit dem Simulationsmodell verglichen, um zu prüfen, ob ein weiterer Stimulus in der Lage ist, diese Fehler zu injizieren. Da kein Anreiz in der Lage war, diese Fehler einzuschleusen, haben wir beschlossen, diese Fehler aus unserer Betrachtung und entsprechend gegen die Fehlerquote auszuschließen. Mit dieser Änderung beträgt unser neues MOE ±1.293 %.
Parallel dazu rief der Fehlersimulator die optimierten Fehlerlisten für die Fehlermodi des Busblocks ab und führte Fehlersimulationen unter Verwendung von Stimuli aus der Funktionsüberprüfung durch. Der ursprüngliche Satz an Reizen bot keine ausreichende Abdeckung, daher wurden höherwertige Reize (Testvektoren) vorbereitet und zusätzliche Fehlerkampagnen für die neuen Reize durchgeführt. Sämtliche Fehlerklassifizierungen wurden in die FuSa-Datenbank geschrieben. Alle Läufe erfolgten parallel und gleichzeitig, um eine Gesamteffizienz und hohe Leistung zu gewährleisten.
Die Sicherheitsanalyse mit SafetyScope trug dazu bei, die Genauigkeit zu erhöhen und die Iteration der Fehlersimulation zu reduzieren. CPU und Cache-Speicher führten nach der Emulation in verschiedenen Tests zu einem Gesamt-SPFM von über 90 %, wie in Tabelle 5 gezeigt.
Tisch 5: Insgesamt: Ergebnisse angezeigt
Zu diesem Zeitpunkt waren noch nicht alle Tests für den BUS-Block (End-to-End-Schutz) zur Fehlersimulation abgeschlossen. Tabelle 6 zeigt, dass der erste erste Test die 9.8 % der Fehler sehr schnell beheben konnte.
Tisch 6: Prozentsatz der erkannten Fehler für den BUS-Block durch E2E SM.
Wir integrieren weitere Tests mit hohem Datenverkehr auf dem BUS, um den Laufzeitbetriebszustand des SoC nachzuahmen. Die Ergebnisse dieser unabhängigen Fehlerinjektionen (Simulation und Emulation) wurden zur Berechnung der endgültigen Metriken für die oben genannten Blöcke kombiniert. Die Ergebnisse sind in Tabelle 7 aufgeführt.
Tisch 7: Endgültige Fehlerklassifizierung nach der Analyse.
Zusammenfassung
In diesem Artikel haben wir die Details einer neuen funktionalen Sicherheitsmethodik vorgestellt, die in einem Automobiltestfall auf SoC-Ebene verwendet wird, und wir haben gezeigt, wie unsere Methodik einen skalierbaren, effizienten Sicherheitsworkflow erzeugt, indem wir Optimierungstechniken für die Fehlerinjektion mithilfe von formalen, Simulations- und Emulationsverifizierungs-Engines verwenden . Die Durchführung einer Sicherheitsanalyse vor der Fehlerinjektion war sehr wichtig und zeitsparend. Daher ist für ein Projekt dieser Größenordnung die Interoperabilität zur Nutzung mehrerer Engines und zum Auslesen der Ergebnisse aus einer gemeinsamen FuSa-Datenbank erforderlich.
Für weitere Informationen zu diesem hochwirksamen funktionalen Sicherheitsfluss für ADAS- und AV-Automobildesigns laden Sie bitte das Siemens EDA-Whitepaper herunter Komplexe Sicherheitsmechanismen erfordern Interoperabilität und Automatisierung für die Validierung und den Abschluss von Metriken.
Arun Gogineni ist Engineering Manager und Architekt für IC-Funktionssicherheit bei Siemens EDA.
James Kim ist technischer Leiter bei Siemens EDA.
- SEO-gestützte Content- und PR-Distribution. Holen Sie sich noch heute Verstärkung.
- PlatoData.Network Vertikale generative KI. Motiviere dich selbst. Hier zugreifen.
- PlatoAiStream. Web3-Intelligenz. Wissen verstärkt. Hier zugreifen.
- PlatoESG. Kohlenstoff, CleanTech, Energie, Umwelt, Solar, Abfallwirtschaft. Hier zugreifen.
- PlatoHealth. Informationen zu Biotechnologie und klinischen Studien. Hier zugreifen.
- Quelle: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/
