Logo Zephyrnet

L'interoperabilità e l'automazione producono un flusso di lavoro di sicurezza scalabile ed efficiente

Data:

Di Ann Keffer, Arun Gogineni e James Kim

Le automobili che implementano funzionalità ADAS e AV si affidano a complessi sistemi digitali e analogici per eseguire applicazioni critiche in tempo reale. L’elevato numero di guasti che devono essere testati in questi moderni progetti automobilistici rende impraticabile l’esecuzione della verifica di sicurezza utilizzando un’unica tecnologia.

Tuttavia, lo sviluppo di una metodologia di sicurezza ottimizzata con elenchi di guasti specifici indirizzati automaticamente alla simulazione, all’emulazione e alla formazione formale è impegnativo. Un'altra sfida è consolidare i risultati della risoluzione dei guasti da varie esecuzioni di iniezione dei guasti per il calcolo metrico finale.

La buona notizia è che l’interoperabilità dei motori di inserimento dei guasti, le tecniche di ottimizzazione e un flusso automatizzato possono ridurre efficacemente i tempi di esecuzione complessivi per chiudere rapidamente il ciclo dall’analisi della sicurezza alla certificazione della sicurezza.

La Figura 1 mostra alcune delle tecniche di ottimizzazione in un flusso di sicurezza. È possibile implementare metodologie avanzate come l'analisi della sicurezza per l'ottimizzazione e l'eliminazione dei guasti, la simulazione dei guasti simultanei, l'emulazione dei guasti e l'analisi formale per convalidare i requisiti di sicurezza per un SoC automobilistico.

Fig. 1: Guasto stratagemma ottimizzazione tecniche.

Prova di concetto: un SoC automobilistico

Utilizzando un caso di test a livello di SoC, dimostreremo come questo flusso automatizzato e multimotore gestisce il gran numero di guasti che devono essere testati nei progetti automobilistici avanzati. Il design del SoC che abbiamo utilizzato in questo caso di test aveva circa tre milioni di gate. Innanzitutto, abbiamo utilizzato motori di iniezione dei guasti sia di simulazione che di emulazione per completare in modo efficiente le campagne di guasto per le metriche finali. Quindi abbiamo eseguito un'analisi formale come parte del completamento dell'inserimento globale dei guasti.

Fig. 2: Automotive SoC di livello superiore bloccare diagramma.

La Figura 3 è una rappresentazione del blocco dell'isola di sicurezza della Figura 2. Le aree codificate a colori mostrano dove sono stati utilizzati la simulazione, l'emulazione e i motori formali per l'inserimento e la classificazione dei guasti.

Fig. 3: Dettagliato isola di sicurezza bloccare diagramma.

L'inserimento dei guasti tramite la simulazione richiedeva troppo tempo e risorse per il core della CPU e i blocchi di memoria cache. Questi blocchi erano destinati all'inserimento dei guasti con un motore di emulazione per garantire efficienza. Il core della CPU è protetto da una libreria di test software (STL) e la memoria cache è protetta da ECC. L'interfaccia del bus richiede una protezione end-to-end laddove l'inserimento dei guasti con simulazione è stato ritenuto efficiente. L'unità di gestione dei guasti non faceva parte di questo esperimento. L'inserimento dei guasti per l'unità di gestione dei guasti sarà completato utilizzando la tecnologia formale come passo successivo.

La Tabella 1 mostra il conteggio dei registri per i blocchi nell'isola di sicurezza.

Tabella 1: conteggio dei registri dei blocchi.

Gli elenchi dei guasti generati per ciascuno di questi blocchi sono stati ottimizzati per concentrarsi sui nodi critici per la sicurezza dotati di meccanismi/protezioni di sicurezza.

SafetyScope, uno strumento di analisi della sicurezza, è stato utilizzato per creare gli elenchi dei guasti per gli FM sia per l'app Veloce Fault (emulatore di guasti) che per il simulatore di guasti e ha scritto gli elenchi dei guasti nel database di sicurezza funzionale (FuSa).

Per i blocchi della CPU e della memoria cache, l'emulatore immette i blocchi sintetizzati e le reti di inserimento/rilevamento errori (FIN/FDN). Successivamente, ha eseguito lo stimolo e ha catturato gli stati di tutti gli FDN. Gli stati sono stati salvati e utilizzati come riferimento “gold” per il confronto con le esecuzioni di iniezione di errori. Per ciascun guasto elencato nell'elenco guasti ottimizzato, è stato emulato il comportamento difettoso e gli FDN sono stati confrontati con i valori di riferimento generati durante la golden run e i risultati sono stati classificati e aggiornati nel database dei guasti con attributi.

Fig. 4: Cluster della CPU. (Fonte da https://developer.arm.com/Processors/Cortex-R52)

Per ciascuna delle sottoparti mostrate nello schema a blocchi, abbiamo generato un elenco dei guasti ottimizzato utilizzando il motore di analisi. Gli elenchi dei guasti vengono salvati in singole sessioni nel database FuSa. Abbiamo utilizzato il campionamento casuale statistico sui difetti complessivi per generare il campione casuale dal database FuSa.

Ora diamo un'occhiata a cosa succede quando prendiamo un campione casuale durante tutta l'iniezione di guasto utilizzando l'emulazione. Tuttavia, affinché questo si chiudesse completamente durante l'inserimento del guasto, abbiamo elaborato N campioni.

Table 2: Rilevato guasti by sicurezza meccanismi.

La tabella 3 mostra che la distribuzione complessiva dei guasti per il totale dei guasti è in linea con la distribuzione dei guasti campionati casualmente. La tabella cattura inoltre il totale dei guasti rilevati di 3125 su 4782 guasti totali. Siamo stati anche in grado di modellare i difetti rilevati per sottoparte e fornire un rapporto di difetti rilevati complessivi del 65.35%. Sulla base dei difetti nel campione casuale e del nostro obiettivo di copertura del 90%, abbiamo calcolato che il margine di errore (MOE) è ±1.19%.

Table 3: Risultati dell'inserimento di errori nella CPU e nella memoria cache.

Il totale dei 3125 guasti rilevati (osservati + non osservati) fornisce una chiara classificazione dei guasti. Le osservazioni non rilevate forniscono anche una chiara classificazione per i difetti residui. Abbiamo effettuato ulteriori analisi dei difetti non rilevati, non osservati e non iniettati.

Table 4: Guasto classificazione dopo guasto iniezione.

Abbiamo utilizzato molte tecniche di debug per analizzare i 616 errori non rilevati e non osservati. Innanzitutto, abbiamo utilizzato l'analisi formale per verificare il cono di influenza (COI) di questi difetti UU. I difetti esterni al COI sono stati ritenuti sicuri e cinque difetti sono stati ulteriormente esclusi dall'analisi. Per i guasti che erano all'interno del COI, abbiamo utilizzato il giudizio ingegneristico giustificando varie configurazioni come ECC, timer, flash mem, ecc. Infine, utilizzando il giudizio formale e ingegneristico siamo stati in grado di classificare ulteriormente 616 guasti UU in guasti sicuri e guasti rimanenti. faglie UU in faglie residue conservativamente. Abbiamo inoltre esaminato i 79 guasti residui e siamo riusciti a classificare 10 guasti come guasti sicuri. I difetti non iniettati sono stati testati anche rispetto al modello di simulazione per verificare se eventuali ulteriori stimoli sono in grado di iniettare tali difetti. Poiché nessuno stimolo è stato in grado di iniettare questi difetti, abbiamo deciso di eliminare questi difetti dalla nostra considerazione e di conseguenza contro il margine di errore. Con questa modifica il nostro nuovo MOE è ±1.293%.

Parallelamente, il simulatore di guasti ha estratto elenchi di guasti ottimizzati per le modalità di guasto del blocco bus ed ha eseguito simulazioni di guasti utilizzando lo stimolo della verifica funzionale. La serie iniziale di stimoli non forniva una copertura sufficiente, quindi sono stati preparati stimoli di qualità superiore (vettori di test) e sono state eseguite ulteriori campagne di guasto sui nuovi stimoli. Tutte le classificazioni dei guasti sono state scritte nel database FuSa. Tutte le corse erano parallele e simultanee per garantire efficienza complessiva e prestazioni elevate.

L'analisi della sicurezza utilizzando SafetyScope ha contribuito a fornire maggiore precisione e a ridurre l'iterazione della simulazione dei guasti. La memoria della CPU e della cache dopo l'emulazione in vari test ha prodotto un SPFM complessivo superiore al 90%, come mostrato nella Tabella 5.

Table 5: Totale risultati.

In questo momento non sono stati completati tutti i test per il blocco del BUS (protezione end-to-end) che effettuano la simulazione del guasto. La tabella 6 mostra che il primo test iniziale è stato in grado di risolvere molto rapidamente il 9.8% dei guasti.

Table 6: Percentuale di guasti rilevati per blocco BUS da E2E SM.

Stiamo integrando più test che hanno un traffico elevato sul BUS per imitare lo stato operativo di runtime del SoC. I risultati di queste iniezioni di guasti indipendenti (simulazione ed emulazione) sono stati combinati per il calcolo delle metriche finali sui blocchi di cui sopra, con i risultati mostrati nella Tabella 7.

Table 7: Analisi finale della classificazione dei guasti.

Conclusione

In questo articolo abbiamo condiviso i dettagli di una nuova metodologia di sicurezza funzionale utilizzata in un caso di test automobilistico a livello SoC e abbiamo mostrato come la nostra metodologia produce un flusso di lavoro di sicurezza scalabile ed efficiente utilizzando tecniche di ottimizzazione per l'inserimento dei guasti utilizzando motori di verifica formale, di simulazione e di emulazione . L'esecuzione dell'analisi della sicurezza prima di eseguire l'inserimento dei guasti è stata molto critica e ha consentito di risparmiare tempo. Pertanto, per un progetto di questa portata è necessaria l’interoperabilità per l’utilizzo di più motori e la lettura dei risultati da un database FuSa comune.

Per ulteriori informazioni su questo flusso di sicurezza funzionale altamente efficace per i progetti automobilistici ADAS e AV, scarica il whitepaper EDA di Siemens Meccanismi di sicurezza complessi richiedono interoperabilità e automazione per la convalida e la chiusura delle metriche.

Arun Gogineni è un responsabile tecnico e architetto per la sicurezza funzionale dei circuiti integrati presso Siemens EDA.

James Kim è un leader tecnico presso Siemens EDA.

spot_img

L'ultima intelligenza

spot_img