La sicurezza funzionale è un aspetto critico per i System on Chip utilizzati in applicazioni automotive che rappresentano la base dei sistemi Adas (Advanced Driver Assistance System), delle apparecchiature di infotainment e di numerosi altri sistemi presenti a bordo degli odierni autoveicoli. Garantire la conformità ai vari standard di sicurezza può essere un compito oneroso in termini sia di tempo sia di risorse impiegate in quanto prevede l'esame di un'ingente mole di dati che variano in funzione dell'evoluzione degli standard stessi. Alcune metodologie permettono di adottare un approccio più efficiente per garantire che un sistema progettato per applicazioni automotive si comporti come previsto anche in presenza di eventi non pianificati o imprevisti. Inoltre, un insieme di tecnologie di progetto e verifica aiutano ad automatizzare l’iniezione di guasti e l'analisi dei risultati per progetti di blocchi IP, SoC e sistemi. L'adozione di questa soluzione per la sicurezza funzionale può contribuire a dimezzare tempo e sforzi richiesti per garantire la conformità allo standard Iso 26262 che disciplina la sicurezza funzionale nel settore automotive.
Le implicazioni della sicurezza funzionale
Il concetto di sicurezza funzionale prevede che un sistema garantisca l'affidabilità e continui a funzionare come previsto anche in presenza di un evento non pianificato o imprevisto. Se un sistema è sicuro da punto di vista funzionale, lo stesso è in grado di evitare rischi non accettabili di danni o lesioni fisiche. Esistono due requisiti fondamentali perché un sistema si possa definire sicuro dal punto di vista funzionale: la ridondanza che prevede l'esistenza di più percorsi di elaborazione in grado di limitare il rischio che un qualsiasi errore possa perturbare il sistema; la presenza di dispositivi di controllo che eseguono il monitoraggio del sistema e innescano, quando richiesto, un'azione di risposta all'errore e funzionalità di ripristino. Poiché i dispositivi SoC sono realizzati sfruttando le tecnologie più avanzate, e sono caratterizzati quindi da geometrie sempre più ridotte, risultano più soggetti agli errori. Per esempio, fenomeni che vedono coinvolte sorgenti di radiazioni, campi magnetici e usura interna possono avere effetti di notevole entità su un SoC realizzato con i più recenti nodi tecnologici. Per garantire la sicurezza funzionale di un SoC è necessario predisporre un ambiente di verifica funzionale che permetta di iniettare errori (ovvero guasti) all'interno del sistema. La logica ridondante deciderà i dati corretti per eliminare gli errori e garantire la continuità di funzionamento mentre i dispositivi di controllo effettueranno il monitoraggio dei dati all'interno di periodi di tempo prestabiliti e applicheranno la correzione degli errori.
Conformità allo standard di sicurezza Iso 26262
Lo standard Iso 26262 è un insieme di norme che affrontano il problema della sicurezza funzionale dei sistemi elettrici ed elettronici installati nelle autovetture. Come adattamento dello standard Iec 61508, Iso 26262 riguarda tutti i sistemi che integrano componenti elettrici, elettronici o elettromeccanici sia per la parte hardware sia per quella software. Lo standard copre molti aspetti della produzione del software per applicazioni automotive collegate alla sicurezza, compresa la qualificazione dei tool utilizzati nel processo di sviluppo. La conformità con i livelli di integrità della sicurezza Asil (Automotive Safety Integrity Level) delineati nello standard Iso 26262 prevede l'acquisizione e l'analisi di una mole enorme di dati. Per dare un'idea della quantità di dati, si pensi che il ciclo di sviluppo di una linea di prodotti automotive prevede il coinvolgimento di decine di persone/anno. Il crescente livello di competitività e la necessità di comprimere al massimo il time-to-market non permettono di dedicare anni alla valutazione degli aspetti legati alla sicurezza funzionale. D'altra parte, per la sicurezza e la salvaguardia degli utilizzatori, non è possibile “prendere scorciatoie” per cercare di economizzare, correndo il rischio di tralasciare alcuni aspetti di fondamentale importanza. Di seguito saranno analizzate alcune metodologie che permettono di garantire in maniera più efficiente la conformità agli standard di sicurezza funzionale.
Classificazione dei guasti per impostare il livello Asil
Il processo di verifica della sicurezza prevede la classificazione dei guasti nelle categorie sicuri (guasti che si verificano in porzioni non critiche del sistema), pericolosi (guasti che si verificano in una porzione critica del sistema) e pericolosi ma rilevabili (guasti che possono essere rilevati dai monitor di sicurezza e corretti successivamente); la codifica di questa classificazione all’interno di un piano di sicurezza e l’attuazione di un programma di verifica per determinare il rapporto tra guasti pericolosi non rilevati e guasti pericolosi. Il risultato determina il livello di integrità della sicurezza Asil. Sotto molti aspetti la verifica della sicurezza funzionale rispecchia la verifica funzionale. La classica metodologia di verifica funzionale prevede che il Design Under Test sia tenuto sotto controllo mentre viene applicata un’ampia varietà di stimoli. Per contro nella metodologia di verifica della sicurezza lo stimolo è controllato per mezzo di alcune sequenze tipiche mentre al Dut è applicata un’ampia gamma di guasti. La sfida più impegnativa per quel che riguarda la verifica della sicurezza è rappresentata dal fatto che la logica del Dut non può essere cambiata; ciò porterebbe infatti a invalidare il concetto di verifica dei guasti nel progetto effettivo. Questo tipo di cambiamento sarebbe anche tale da inficiare la valutazione Tcl (Tool Confidence Level) prevista dallo standard Iso 26262 relativa ai tool di valutazione utilizzati. Con queste considerazioni, la verifica di sicurezza deve condividere sia il codice del Dut che quello del testbench e il flusso deve essere eseguito simultaneamente con quello della verifica funzionale. L’insieme di punti di monitoraggio per i circuiti di rilevazione del guasto rappresentano il punto di partenza per la verifica della sicurezza. Tali punti sono abilitati nel corso dello sviluppo del progetto effettivo, per cui il medesimo effetto deve essere modellato nella verifica della sicurezza. Durante la verifica della sicurezza il Dut è stimolato mediante un numero ridotto di sequenze di test funzionali. Una volta creato un ambiente di questo tipo, i nodi di progetto devono essere automaticamente individuati e quindi raggruppati al fine di generare un dizionario dei guasti per la verifica di sicurezza. La metodologia di verifica della sicurezza esegue l’iterazione sulla base di questo dizionario, iniettando guasti sia di tipo permanente sia di tipo Seu (Single Event Upset). Con questo processo per ciascun guasto è riportata una condizione di rilevamento. I guasti segnalati come non rilevati o potenzialmente rilevati richiedono una ulteriore fase di debug prima che procedere al loro raggruppamento in quanto potrebbero risultare pericolosi.
Integrare la verifica di sicurezza nel flusso di verifica funzionale
Nel caso di progetti di piccole dimensioni, si potrebbe pensare di far girare la verifica di sicurezza utilizzando un ingresso campionato per il testbench e procedere quindi all’analisi manuale dei risultati. Nel caso di sistemi più complessi sarebbe opportuno integrare la verifica della sicurezza all’interno del flusso della verifica funzionale. Grazie a un approccio di questo tipo è possibile ricorrere a testbench sofisticati per controllare l’iniezione del guasto e supportare il processo di debug. Per le stesse ragioni ha senso utilizzare il medesimo simulatore per entrambi i processi. Così facendo è possibile eliminare le perdite di efficienza imputabili al debugging di differenti risultati provocate dall’uso di un Dut modificato o di un diverso engine di simulazione. Un processo di simulazione della sicurezza potrebbe riguardare un numero di guasti temporali stimabili nell'ordine delle centinaia di migliaia se non addirittura milioni. Per questo motivo la verifica di regressione automatizzata e basata su verifica metric-driven, può rendere più efficiente l’identificazione delle simulazioni di guasti non rilevati o potenzialmente rilevati e classificare automaticamente gli stessi. Grazie a un approccio di questo tipo è possibile ridurre del 50% gli oneri legati alla verifica della sicurezza. Una soluzione completa per la sicurezza funzionale che permette di ridurre fino al 50% tempo e sforzi richiesti per garantire la conformità allo standard Iso 26262 è stata di recente introdotta da Cadence. Basata sulla piattaforma per la verifica funzionale Incisive, questa soluzione comprende il simulatore per la sicurezza funzionale Incisive Functional Safety Simulator e una funzione di regressione per la sicurezza funzionale integrata in Incisive vManager. Grazie a Incisive vManager è possibile evidenziare esecuzioni di simulazioni di guasti potenziali e non rilevati per il debugging. Complessivamente questa soluzione per la sicurezza funzionale automatizza l’iniezione di guasti e l’analisi dei risultati per i progetti di IP, SoC e sistemi. Per il tracciamento dei requisiti di sicurezza, la soluzione integra la simulazione dei guasti transitori e permanenti. Il simulatore per la sicurezza funzionale Incisive simula il Dut non modificato. I guasti sono iniettati durante la simulazione e possono propagarsi attraverso SystemC, transistor analogici o modelli comportamentali e asserzioni. I progettisti possono riutilizzare i loro ambienti di verifica funzionale mixed-signal per ridurre il tempo necessario per lo sviluppo della verifica di sicurezza. La funzione di analisi della sicurezza funzionale integrata in Incisive vManager permette di generare automaticamente una regressione della verifica di sicurezza a partire dal dizionario dei guasti creato per mezzo del simulatore. La soluzione è quindi in grado di rilevare milioni di guasti (rilevati, potenzialmente rilevati o non rilevati) introdotti nel corso della simulazione per verificare i sistemi di sicurezza del progetto.
