Door Ann Keffer, Arun Gogineni en James Kim

Auto's die ADAS- en AV-functies inzetten, zijn afhankelijk van complexe digitale en analoge systemen om kritische realtime toepassingen uit te voeren. Het grote aantal fouten dat moet worden getest in deze moderne auto-ontwerpen maakt het uitvoeren van veiligheidsverificatie met behulp van één enkele technologie onpraktisch.

Toch is het een uitdaging om een ​​geoptimaliseerde veiligheidsmethodologie te ontwikkelen met specifieke foutlijsten die automatisch gericht zijn op simulatie, emulatie en formeel. Een andere uitdaging is het consolideren van de foutresolutieresultaten van verschillende foutinjectieruns voor de uiteindelijke metrische berekening.

Het goede nieuws is dat de interoperabiliteit van foutinjectiemotoren, optimalisatietechnieken en een geautomatiseerde stroom de totale uitvoeringstijd effectief kunnen verkorten, zodat de cirkel van veiligheidsanalyse naar veiligheidscertificering snel kan worden gesloten.

Figuur 1 toont enkele optimalisatietechnieken in een veiligheidsstroom. Geavanceerde methodologieën zoals veiligheidsanalyse voor optimalisatie en het opsporen van fouten, gelijktijdige foutsimulatie, foutemulatie en formeel gebaseerde analyse kunnen worden ingezet om de veiligheidseisen voor een auto-SoC te valideren.

Vijg 1: Fout lijst optimalisatie technieken.

Proof of concept: een auto-SoC

Met behulp van een testcase op SoC-niveau zullen we demonstreren hoe deze geautomatiseerde stroom met meerdere motoren omgaat met het grote aantal fouten dat moet worden getest in geavanceerde auto-ontwerpen. Het SoC-ontwerp dat we in deze testcase gebruikten, had ongeveer drie miljoen poorten. Ten eerste hebben we zowel simulatie- als emulatie-foutinjectiemotoren gebruikt om de foutcampagnes voor de uiteindelijke statistieken efficiënt te voltooien. Vervolgens voerden we een formele analyse uit als onderdeel van het voltooien van de algehele foutinjectie.

Vijg 2: Automotive SoC hoogste niveau blok diagram.

Figuur 3 is een weergave van het veiligheidseilandblok uit figuur 2. De kleurgecodeerde gebieden laten zien waar simulatie, emulatie en formele motoren werden gebruikt voor foutinjectie en foutclassificatie.

Vijg 3: Gedetailleerd veiligheids eiland blok diagram.

Foutinjectie met behulp van simulatie kostte te veel tijd en middelen voor de CPU-kern en cachegeheugenblokken. Die blokken waren bedoeld voor foutinjectie met een emulatie-engine voor efficiëntie. De CPU-kern wordt beschermd door een softwaretestbibliotheek (STL) en het cachegeheugen wordt beschermd door ECC. De businterface vereist end-to-end-bescherming waarbij is vastgesteld dat foutinjectie met simulatie efficiënt is. De storingsbeheereenheid maakte geen deel uit van dit experiment. Als volgende stap zal de foutinjectie voor de foutbeheereenheid worden voltooid met behulp van formele technologie.

Tabel 1 toont het registeraantal voor de blokken op het veiligheidseiland.

Tabel 1: Aantal blokregisters.

De foutlijsten die voor elk van deze blokken zijn gegenereerd, zijn geoptimaliseerd om zich te concentreren op de veiligheidskritische knooppunten die veiligheidsmechanismen/bescherming hebben.

SafetyScope, een veiligheidsanalysetool, werd gebruikt om de foutlijsten voor de FM's te maken voor zowel de Veloce Fault App (foutemulator) als de foutsimulator en schreef de foutlijsten naar de functionele veiligheidsdatabase (FuSa).

Voor de CPU- en cachegeheugenblokken voert de emulator de gesynthetiseerde blokken en foutinjectie/foutdetectienetten (FIN/FDN) in. Vervolgens voerde het de stimulus uit en registreerde het de toestanden van alle FDN's. De staten werden opgeslagen en gebruikt als een “gouden” referentie voor vergelijking met foutinjectieruns. Voor elke fout die in de geoptimaliseerde foutenlijst staat, werd het foutieve gedrag geëmuleerd en werden de FDN's vergeleken met de referentiewaarden die tijdens de gouden run waren gegenereerd, en de resultaten werden geclassificeerd en bijgewerkt in de foutendatabase met attributen.

Fig. 4: CPU-cluster. (Bron oppompen van https://developer.arm.com/Processors/Cortex-R52)

Voor elk van de subonderdelen die in het blokdiagram worden weergegeven, hebben we met behulp van de analyse-engine een geoptimaliseerde foutenlijst gegenereerd. De foutlijsten worden in individuele sessies in de FuSa-database opgeslagen. We hebben de statistische willekeurige steekproef van de totale fouten gebruikt om de willekeurige steekproef uit de FuSa-database te genereren.

Laten we nu eens kijken wat er gebeurt als we met behulp van emulatie één willekeurig monster nemen, helemaal door de foutinjectie. Om dit echter volledig af te sluiten bij de foutinjectie, hebben we N monsters verwerkt.

tafel 2: Gedetecteerd fouten by veiligheid mechanismen.

Tabel 3 laat zien dat de algehele foutverdeling voor de totale fouten in lijn is met de foutverdeling van de willekeurig bemonsterde fouten. De tabel geeft verder het totaal aantal gedetecteerde fouten weer van 3125 van de in totaal 4782 fouten. Ook konden we de gedetecteerde fouten per subonderdeel modelleren en een totaal gedetecteerd foutpercentage van 65.35% opleveren. Op basis van de fouten in de willekeurige steekproef en ons dekkingsdoel van 90% hebben we berekend dat de foutmarge (MOE) ±1.19% bedraagt.

tafel 3: Resultaten van foutinjectie in CPU en cachegeheugen.

Het totaal van 3125 gedetecteerde (waargenomen + niet-waargenomen) fouten zorgt voor een duidelijke foutclassificatie. De niet-gedetecteerde waarnemingen bieden ook een duidelijke classificatie voor restfouten. We hebben verdere analyses uitgevoerd van niet-gedetecteerde, niet-geobserveerde en niet-geïnjecteerde fouten.

tafel 4: Fout classificatie na fout injectie.

We hebben veel debugtechnieken gebruikt om de 616 niet-gedetecteerde, niet-geobserveerde fouten te analyseren. Ten eerste hebben we formele analyse gebruikt om de kegel van invloed (COI) van deze UU-fouten te controleren. De fouten die buiten de COI lagen, werden als veilig beschouwd en er waren vijf fouten die verder uit de analyse werden verwijderd. Voor de fouten die zich binnen de COI bevonden, gebruikten we technisch oordeel met rechtvaardiging van verschillende configuraties zoals ECC, timer, flash-mem-gerelateerd enz. Ten slotte konden we, met behulp van formeel en technisch oordeel, 616 UU-fouten verder classificeren in veilige fouten en resterende fouten. UU-fouten naar conservatief restfouten. Daarnaast hebben we de 79 restfouten beoordeeld en hebben we 10 fouten kunnen classificeren als veilige fouten. De niet-geïnjecteerde fouten werden ook getest aan de hand van het simulatiemodel om te controleren of een verdere stimulus deze fouten kan injecteren. Omdat geen enkele stimulus deze fouten kon injecteren, hebben we besloten deze fouten buiten beschouwing te laten en dienovereenkomstig tegen de foutmarge in. Met deze wijziging bedraagt ​​onze nieuwe MOE ±1.293%.

Tegelijkertijd haalde de foutsimulator de geoptimaliseerde foutlijsten op voor de foutmodi van het busblok en voerde foutsimulaties uit met behulp van stimuli uit functionele verificatie. De aanvankelijke reeks stimuli bood niet voldoende dekking, dus werden stimuli van hogere kwaliteit (testvectoren) voorbereid en werden aanvullende foutcampagnes uitgevoerd op de nieuwe stimuli. Alle foutclassificaties zijn in de FuSa-database geschreven. Alle runs waren parallel en gelijktijdig voor algehele efficiëntie en hoge prestaties.

Veiligheidsanalyse met behulp van SafetyScope hielp om meer nauwkeurigheid te bieden en de herhaling van foutsimulatie te verminderen. CPU en cachegeheugen na emulatie bij verschillende tests resulteerden in een algehele SPFM van meer dan 90%, zoals weergegeven in Tabel 5.

tafel 5: globaal resultaten.

Op dat moment waren nog niet alle tests voor het BUS-blok (end-to-end-beveiliging) die de foutsimulatie uitvoerden voltooid. Tabel 6 laat zien dat de eerste eerste test de fouten van 9.8% zeer snel kon oplossen.

tafel 6: Percentage gedetecteerde fouten voor BUS-blok door E2E SM.

We integreren meer tests met veel verkeer op de BUS om de runtime-werkingsstatus van de SoC na te bootsen. De resultaten van deze onafhankelijke foutinjecties (simulatie en emulatie) werden gecombineerd voor het berekenen van de uiteindelijke metrieken voor de bovenstaande blokken, waarbij de resultaten worden weergegeven in Tabel 7.

tafel 7: Definitieve foutclassificatie na analyse.

Conclusie

In dit artikel hebben we de details gedeeld van een nieuwe functionele veiligheidsmethodologie die wordt gebruikt in een autotestcase op SoC-niveau, en we hebben laten zien hoe onze methodologie een schaalbare, efficiënte veiligheidsworkflow oplevert met behulp van optimalisatietechnieken voor foutinjectie met behulp van formele, simulatie- en emulatieverificatie-engines. . Het uitvoeren van een veiligheidsanalyse voorafgaand aan het uitvoeren van de foutinjectie was zeer kritisch en tijdbesparend. Daarom is de interoperabiliteit voor het gebruik van meerdere motoren en het lezen van de resultaten uit een gemeenschappelijke FuSa-database noodzakelijk voor een project van deze omvang.

Voor meer informatie over deze zeer effectieve functionele veiligheidsstroom voor ADAS- en AV-auto-ontwerpen kunt u de Siemens EDA-whitepaper downloaden Complexe veiligheidsmechanismen vereisen interoperabiliteit en automatisering voor validatie en metrische afsluiting.

Arun Gogineni is technisch manager en architect voor functionele IC-veiligheid bij Siemens EDA.

James Kim is technisch leider bij Siemens EDA.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/