Av Ann Keffer, Arun Gogineni och James Kim

Bilar som använder ADAS- och AV-funktioner förlitar sig på komplexa digitala och analoga system för att utföra kritiska realtidsapplikationer. Det stora antalet fel som måste testas i dessa moderna fordonskonstruktioner gör det opraktiskt att utföra säkerhetsverifiering med en enda teknik.

Ändå är det utmanande att utveckla en optimerad säkerhetsmetodik med specifika fellistor som automatiskt är inriktade på simulering, emulering och formell. En annan utmaning är att konsolidera fellösningsresultat från olika felinsprutningskörningar för slutlig metrisk beräkning.

Den goda nyheten är att driftskompatibilitet mellan felinsprutningsmotorer, optimeringstekniker och ett automatiserat flöde effektivt kan minska den totala utförandetiden för att snabbt stänga kretsen från säkerhetsanalys till säkerhetscertifiering.

Figur 1 visar några av optimeringsteknikerna i ett säkerhetsflöde. Avancerade metoder som säkerhetsanalys för optimering och felbeskärning, samtidig felsimulering, felemulering och formell baserad analys kan användas för att validera säkerhetskraven för en fordons-SoC.

Fig. 1: Fel lista optimering tekniker.

Proof of concept: en SoC för fordon

Med hjälp av ett testfall på SoC-nivå kommer vi att visa hur detta automatiserade, flermotoriga flöde hanterar det stora antalet fel som måste testas i avancerade fordonskonstruktioner. SoC-designen som vi använde i detta testfall hade cirka tre miljoner grindar. Först använde vi både simulerings- och emuleringsfelinsprutningsmotorer för att effektivt slutföra felkampanjerna för slutliga mätvärden. Sedan utförde vi formell analys som en del av att avsluta den övergripande felinjektionen.

Fig. 2: Bil SoC toppnivå blockera schema.

Figur 3 är en representation av säkerhetsöblocket från figur 2. De färgkodade områdena visar var simulering, emulering och formella motorer användes för felinsprutning och felklassificering.

Fig. 3: Detaljerad säkerhetsö blockera schema.

Felinjektion med simulering var för tid- och resurskrävande för CPU-kärnan och cacheminnesblocken. Dessa block var inriktade på felinsprutning med en emuleringsmotor för effektivitet. CPU-kärnan är skyddad av ett mjukvarutestbibliotek (STL) och cacheminnet skyddas av ECC. Bussgränssnittet kräver end-to-end-skydd där felinjektion med simulering bedömdes vara effektiv. Felhanteringsenheten var inte en del av detta experiment. Felinjektion för felhanteringsenheten kommer att slutföras med formell teknik som nästa steg.

Tabell 1 visar registerantalet för blocken i säkerhetsön.

Tabell 1: Blockregisterantal.

Fellistorna som genererades för vart och ett av dessa block har optimerats för att fokusera på de säkerhetskritiska noderna som har säkerhetsmekanismer/skydd.

SafetyScope, ett säkerhetsanalysverktyg, kördes för att skapa fellistor för FM:erna för både Veloce Fault App (felemulator) och felsimulatorn och skrev fellistorna till databasen för funktionell säkerhet (FuSa).

För CPU- och cacheminnesblocken matar emulatorn in de syntetiserade blocken och felinjektion/feldetekteringsnät (FIN/FDN). Därefter utförde den stimulansen och fångade tillstånden för alla FDN. Tillstånden sparades och användes som en "guld" referens för jämförelse med felinsprutningskörningar. För varje fel listat i den optimerade fellistan emulerades det felaktiga beteendet, och FDN jämfördes med referensvärdena som genererades under den gyllene körningen, och resultaten klassificerades och uppdaterades i feldatabasen med attribut.

Fig. 4: CPU-kluster. (Källa från https://developer.arm.com/Processors/Cortex-R52)

För var och en av underdelarna som visas i blockschemat genererade vi en optimerad fellista med hjälp av analysmotorn. Fellistorna sparas i en individuell session i FuSa-databasen. Vi använde det statistiska slumpmässiga urvalet på de övergripande felen för att generera det slumpmässiga urvalet från FuSa-databasen.

Låt oss nu titta på vad som händer när vi tar ett slumpmässigt prov hela vägen genom felinjektionen med emulering. Men för att detta skulle sluta helt på felinjektionen bearbetade vi N prover.

Bord 2: upptäckta fel by säkerhet mekanismer.

Tabell 3 visar att den totala felfördelningen för totala fel är i linje med felfördelningen för de slumpmässigt uttagna felen. Tabellen fångar vidare det totala antalet upptäckta fel på 3125 av 4782 totala fel. Vi kunde också modellera de upptäckta felen per underdel och ge en total detekterad felkvot på 65.35 %. Baserat på felen i det slumpmässiga urvalet och vårt täckningsmål på 90 % beräknade vi att felmarginalen (MOE) är ±1.19 %.

Bord 3: Resultat av felinjektion i CPU och cacheminne.

Det totala antalet upptäckta (observerade + ej observerade) 3125 fel ger en tydlig felklassificering. De oupptäckta som observerats ger också en tydlig klassificering för kvarstående fel. Vi gjorde ytterligare analys av oupptäckta oobserverade och inte injicerade fel.

Bord 4: Fel klassificering efter fel injektion.

Vi använde många felsökningstekniker för att analysera de 616 oupptäckta oobserverade felen. Först använde vi formell analys för att kontrollera inflytandekonen (COI) för dessa UU-fel. Felen som låg utanför COI ansågs säkra, och det fanns fem fel som ytterligare släpptes från analysen. För felen som fanns inuti COI använde vi teknisk bedömning med motivering av olika konfigurationer som, ECC, timer, flash mem relaterade etc. Slutligen, med hjälp av formell och teknisk bedömning kunde vi ytterligare klassificera 616 UU fel i säkra fel och kvarvarande fel. UU-fel till konservativt kvarvarande fel. Vi granskade också de 79 kvarvarande felen och kunde klassificera 10 fel i säkra fel. De ej injicerade felen testades också mot simuleringsmodellen för att kontrollera om någon ytterligare stimulans kan injicera dessa fel. Eftersom ingen stimulans kunde injicera dessa fel, beslutade vi att ta bort dessa fel från vår övervägande och mot felmarginalen i enlighet därmed. Med denna förändring är vår nya MOE ±1.293%.

Parallellt drog felsimulatorn de optimerade fellistorna för busblockets fellägen och körde felsimuleringar med hjälp av stimulans från funktionsverifiering. Den initiala uppsättningen av stimuli gav inte tillräcklig täckning, så stimuli av högre kvalitet (testvektorer) förbereddes och ytterligare felkampanjer kördes på de nya stimulierna. Alla felklassificeringar skrevs in i FuSa-databasen. Alla körningar var parallella och samtidiga för övergripande effektivitet och hög prestanda.

Säkerhetsanalyser med SafetyScope bidrog till att ge mer noggrannhet och minska upprepningen av felsimulering. CPU och cacheminne efter emulering i olika tester resulterade i en total SPFM på över 90 % som visas i Tabell 5.

Bord 5: Övergripande resultat.

Vid denna tidpunkt hade inte alla tester för BUS-block (änd-till-änd-skydd) som utförde felsimuleringen slutförts. Tabell 6 visar att det första initiala testet kunde lösa de 9.8 % felen mycket snabbt.

Bord 6: Procentandel av upptäckta fel för BUS-block av E2E SM.

Vi integrerar fler tester som har hög trafik på BUS för att efterlikna drifttillståndet för SoC. Resultaten av dessa oberoende felinjektioner (simulering och emulering) kombinerades för att beräkna de slutliga måtten på ovanstående block, med resultaten som visas i Tabell 7.

Bord 7: Slutlig felklassificering efter analys.

Slutsats

I den här artikeln delade vi detaljerna om en ny funktionell säkerhetsmetod som används i ett fordonstestfall på SoC-nivå, och vi visade hur vår metodik producerar ett skalbart, effektivt säkerhetsarbetsflöde med hjälp av optimeringstekniker för felinjektion med formella, simulerings- och emuleringsmotorer . Att utföra säkerhetsanalyser innan felinsprutningen kördes var mycket kritiskt och tidsbesparande. Därför är interoperabiliteten för att använda flera motorer och läsa resultaten från en gemensam FuSa-databas nödvändig för ett projekt av denna skala.

För mer information om detta mycket effektiva funktionella säkerhetsflöde för ADAS- och AV-fordonsdesigner, ladda ner Siemens EDA whitepaper Komplexa säkerhetsmekanismer kräver interoperabilitet och automatisering för validering och metrisk stängning.

Arun Gogineni är ingenjörschef och arkitekt för IC funktionell säkerhet på Siemens EDA.

James Kim är teknisk ledare på Siemens EDA.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://semiengineering.com/interoperability-and-automation-yield-a-scalable-and-efficient-safety-workflow/