Av Ann Keffer, Arun Gogineni og James Kim

Biler som distribuerer ADAS- og AV-funksjoner er avhengige av komplekse digitale og analoge systemer for å utføre kritiske sanntidsapplikasjoner. Det store antallet feil som må testes i disse moderne bildesignene gjør det upraktisk å utføre sikkerhetsverifisering ved hjelp av en enkelt teknologi.

Likevel er det utfordrende å utvikle en optimalisert sikkerhetsmetodikk med spesifikke feillister automatisk målrettet for simulering, emulering og formell. En annen utfordring er å konsolidere feilløsningsresultater fra forskjellige feilinjeksjonskjøringer for endelig metrisk beregning.

Den gode nyheten er at interoperabilitet av feilinjeksjonsmotorer, optimaliseringsteknikker og en automatisert flyt effektivt kan redusere den totale utførelsestiden for raskt å lukke sløyfen fra sikkerhetsanalyse til sikkerhetssertifisering.

Figur 1 viser noen av optimaliseringsteknikkene i en sikkerhetsflyt. Avanserte metoder som sikkerhetsanalyse for optimalisering og feilbeskjæring, samtidig feilsimulering, feilemulering og formell basert analyse kan brukes for å validere sikkerhetskravene for en bil-SoC.

Fig. 1: Feil liste optimalisering teknikker.

Proof of concept: en SoC for biler

Ved å bruke en testcase på SoC-nivå vil vi demonstrere hvordan denne automatiserte flermotorsflyten håndterer det store antallet feil som må testes i avanserte bildesigner. SoC-designet vi brukte i denne testsaken hadde omtrent tre millioner porter. Først brukte vi både simulerings- og emuleringsfeilinjeksjonsmotorer for å effektivt fullføre feilkampanjene for endelige beregninger. Deretter utførte vi formell analyse som en del av å fullføre den totale feilinjeksjonen.

Fig. 2: Biler SoC øverste nivå blokkere diagram.

Figur 3 er en representasjon av sikkerhetsøyblokken fra figur 2. De fargekodede områdene viser hvor simulering, emulering og formelle motorer ble brukt for feilinjeksjon og feilklassifisering.

Fig. 3: Detaljert sikkerhetsøy blokkere diagram.

Felinjeksjon ved bruk av simulering var for tid- og ressurskrevende for CPU-kjernen og bufferminneblokkene. Disse blokkene ble målrettet for feilinjeksjon med en emuleringsmotor for effektivitet. CPU-kjernen er beskyttet av et programvaretestbibliotek (STL) og cache-minnet er beskyttet av ECC. Bussgrensesnittet krever ende-til-ende-beskyttelse der feilinjeksjon med simulering ble fastslått å være effektiv. Feilhåndteringsenheten var ikke en del av dette eksperimentet. Feilinjeksjon for feilhåndteringsenheten vil bli fullført ved bruk av formell teknologi som neste trinn.

Tabell 1 viser registertall for blokkene i sikkerhetsøya.

Tabell 1: Blokkregisterantall.

Feillistene generert for hver av disse blokkene ble optimalisert for å fokusere på de sikkerhetskritiske nodene som har sikkerhetsmekanismer/beskyttelse.

SafetyScope, et sikkerhetsanalyseverktøy, ble kjørt for å lage feillistene for FM-ene for både Veloce Fault App (feilemulator) og feilsimulatoren og skrev feillistene til databasen for funksjonell sikkerhet (FuSa).

For CPU- og cache-minneblokkene legger emulatoren inn de syntetiserte blokkene og feilinjeksjons-/feildeteksjonsnettene (FIN/FDN). Deretter utførte den stimulansen og fanget opp tilstandene til alle FDN-ene. Tilstandene ble lagret og brukt som en "gull"-referanse for sammenligning med feilinjeksjonskjøringer. For hver feil som er oppført i den optimaliserte feillisten, ble den feilaktige oppførselen emulert, og FDN-ene ble sammenlignet med referanseverdiene generert under den gylne kjøringen, og resultatene ble klassifisert og oppdatert i feildatabasen med attributter.

Fig. 4: CPU-klynge. (Kilde fra https://developer.arm.com/Processors/Cortex-R52)

For hver av underdelene vist i blokkskjemaet genererte vi en optimalisert feilliste ved hjelp av analysemotoren. Feillistene lagres i individuell sesjon i FuSa-databasen. Vi brukte den statistiske stikkprøven på de generelle feilene for å generere stikkprøven fra FuSa-databasen.

La oss nå se på hva som skjer når vi tar én tilfeldig prøve hele veien gjennom feilinjeksjonen ved hjelp av emulering. For at dette skulle stenge helt på feilinjeksjonen, behandlet vi imidlertid N prøver.

Bord 2: oppdaget feil by sikkerhet mekanismer.

Tabell 3 viser at den samlede feilfordelingen for totale feil er på linje med feilfordelingen til de tilfeldig utvalgte feilene. Tabellen fanger videre opp de totale oppdagede feilene på 3125 av 4782 totale feil. Vi var også i stand til å modellere de oppdagede feilene per underdel og gi et samlet detektert feilforhold på 65.35 %. Basert på feilene i stikkprøven og vårt dekningsmål på 90 %, beregnet vi at feilmarginen (MOE) er ±1.19 %.

Bord 3: Resultater av feilinjeksjon i CPU og cache-minne.

Totalt påviste (observerte + uobserverte) 3125 feil gir en klar feilklassifisering. De uoppdagede observerte gir også en klar klassifisering for gjenværende feil. Vi gjorde ytterligere analyser av uoppdagede uobserverte og ikke injiserte feil.

Bord 4: Feil klassifisering etter feil injeksjon.

Vi brukte mange feilsøkingsteknikker for å analysere 616 uoppdagede uobserverte feil. Først brukte vi formell analyse for å sjekke innflytelseskjeglen (COI) til disse UU-feilene. Feilene som var utenfor COI ble ansett som sikre, og det var fem feil som ble fjernet fra analysen. For feilene som var inne i COI, brukte vi teknisk vurdering med begrunnelse av ulike konfigurasjoner som ECC, timer, flash mem relatert osv. Til slutt, ved å bruke formell og teknisk vurdering, var vi i stand til å klassifisere 616 UU feil i sikre feil og gjenværende. UU-feil til konservativt restfeil. Vi gjennomgikk også de 79 gjenværende feilene og kunne klassifisere 10 feil i sikre feil. De ikke-injiserte feilene ble også testet mot simuleringsmodellen for å sjekke om ytterligere stimulus er i stand til å injisere disse feilene. Siden ingen stimulans var i stand til å injisere disse feilene, bestemte vi oss for å droppe disse feilene fra vår vurdering og mot feilmarginen tilsvarende. Med denne endringen er vår nye MOE ±1.293 %.

Parallelt trakk feilsimulatoren de optimaliserte feillistene for feilmodusene til bussblokken og kjørte feilsimuleringer ved bruk av stimulus fra funksjonell verifisering. Det første settet med stimuli ga ikke nok dekning, så stimuli av høyere kvalitet (testvektorer) ble forberedt, og ytterligere feilkampanjer ble kjørt på de nye stimuli. Alle feilklassifiseringene ble skrevet inn i FuSa-databasen. Alle kjøringer var parallelle og samtidige for generell effektivitet og høy ytelse.

Sikkerhetsanalyse ved bruk av SafetyScope bidro til å gi mer nøyaktighet og redusere gjentakelsen av feilsimulering. CPU og cache-minne etter emulering på forskjellige tester resulterte i en total SPFM på over 90 % som vist i tabell 5.

Bord 5: Alt i alt resultater.

På dette tidspunktet var ikke alle testene for BUS-blokk (ende-til-ende-beskyttelse) som gjorde feilsimuleringen fullført. Tabell 6 viser at den første innledende testen var i stand til å løse 9.8 % feil veldig raskt.

Bord 6: Prosentandel av oppdagede feil for BUS-blokk av E2E SM.

Vi integrerer flere tester som har høy trafikk på BUS-en for å etterligne kjøretidstilstanden til SoC. Resultatene av disse uavhengige feilinjeksjonene (simulering og emulering) ble kombinert for å beregne de endelige beregningene på blokkene ovenfor, med resultatene vist i tabell 7.

Bord 7: Endelig feilklassifisering etter analyse.

konklusjonen

I denne artikkelen delte vi detaljene om en ny funksjonell sikkerhetsmetodikk brukt i en testcase på SoC-nivå i bilindustrien, og vi viste hvordan metodikken vår produserer en skalerbar, effektiv sikkerhetsarbeidsflyt ved bruk av optimaliseringsteknikker for feilinjeksjon ved bruk av formelle, simulerings- og emuleringsverifiseringsmotorer . Å utføre sikkerhetsanalyse før feilinjeksjonen var svært kritisk og tidsbesparende. Derfor er interoperabiliteten for bruk av flere motorer og lesing av resultatene fra en felles FuSa-database nødvendig for et prosjekt av denne skalaen.

For mer informasjon om denne svært effektive funksjonelle sikkerhetsflyten for ADAS og AV-bildesign, vennligst last ned Siemens EDA whitepaper Komplekse sikkerhetsmekanismer krever interoperabilitet og automatisering for validering og metrisk lukking.

Arun Gogineni er ingeniørsjef og arkitekt for IC funksjonell sikkerhet hos Siemens EDA.

James Kim er teknisk leder i Siemens EDA.

• SEO-drevet innhold og PR-distribusjon. Bli forsterket i dag.
• PlatoData.Network Vertical Generative Ai. Styrk deg selv. Tilgang her.
• PlatoAiStream. Web3 Intelligence. Kunnskap forsterket. Tilgang her.
• PlatoESG. Karbon, CleanTech, Energi, Miljø, Solenergi, Avfallshåndtering. Tilgang her.
• PlatoHelse. Bioteknologisk og klinisk etterretning. Tilgang her.
• kilde: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/