Per garantire una maggior sicurezza di guida attualmente si utilizzano applicazioni basate su telecamere e radar. Inizialmente queste applicazioni di aiuto alla guida o Adas (Advanced driver assistance system), come ad esempio controllo adattativo della velocità di crociera e avviso di superamento della linea che delimita la corsia di marcia rivestivano essenzialmente un carattere di praticità. Col passare del tempo hanno iniziato a ricoprire un ruolo più attivo nel controllo di un autoveicolo, grazie allo sviluppo di applicazioni quali l'assistenza al mantenimento della corsia o Lka (Lane keep assist). Mentre fino a non molto tempo fa le Cpu a elevate prestazioni erano considerate i dispositivi più adatti per queste applicazioni, la necessità di individuare il miglior compromesso possibile tra potenza di calcolo e consumi di potenza ha portato i progettisti a iniziare a considerare l'impiego di dispositivi Fpga. Un sistema Adas deve soddisfare specifici requisiti di sicurezza funzionale. Lo standard Iso26262, introdotto nel 2011 per i veicoli passeggeri di peso fino a 3,5 tonnellate, si pone l'obiettivo di minimizzare il rischio che il malfunzionamento di un sistema possa creare situazioni pericolose. Questo standard cerca di risolvere il problema legato ai guasti sistematici sia con l'adozione di un processo di design rigoroso sia con il rilevamento di guasti dell'hardware di natura randomica durante l'esecuzione di un'applicazione.
Obiettivo sicurezza
Lo sviluppatore di un'applicazione definisce obiettivi di sicurezza specifici e attribuisce un determinato livello Asil (Automotive safety integrity level) a ciascuno di questi obiettivi. Il livello Asil più elevato per un'applicazione di solito definisce i requisiti ai quali lo sviluppo e il funzionamento di ogni componente devono conformarsi fino alla fine del ciclo di vita. Il livello richiesto più basso è Asil-B, anche se alcune applicazioni richiedono il livello Asil-D per determinate funzionalità. Quando si passa da un livello Asil più basso a quello superiore, i requisiti diventano più severi. L'adozione di un livello Asil generale (quindi unico) per un componente (o per un sistema) può introdurre complicazioni inutili in una specifica implementazione e avere un impatto negativo sui costi e sulla pianificazione dello sviluppo. Un'analisi del sistema e dei relativi requisiti di sicurezza permette di suddividere l'applicazione in differenti sezioni ciascuna delle quali caratterizzata da diversi livelli Asil, in modo da semplificare e garantire un maggior grado di efficienza alla sua implementazione. Una telecamera monocromatica frontale con un singolo sensore di immagine è spesso utilizzata in un sistema Adas. Un sensore di immagine è collegato al processore di immagine, che potrebbe essere un SoC della linea Cyclone V di Altera. La catena di elaborazione e il flusso di dati è suddiviso in quattro parti. Dapprima viene eseguita un'elaborazione di basso livello sui pixel trasformando l'immagine in una rappresentazione più utile. Con una successiva elaborazione di livello intermedio su una linea o un blocco dell'immagine si estraggono, tramite appropriati algoritmi, caratteristiche quali i contorni. Un'elaborazione di alto livello, infine, permette di estrarre i dati a livello di frame (fotogramma) per rilevare e classificare gli oggetti. Il sistema quindi deve essere in grado di rilevare gli oggetti e, nel caso sia necessario intraprendere qualche azione, comunicare con altri sistemi come ad esempio l'impianto frenante o l'unità di controllo elettronico dello sterzo. L'elaborazione di basso livello e quella di livello intermedio possono essere implementate in maniera molto efficiente su un Fpga, anche se gli utilizzatori possono decidere di eseguire alcune elaborazione intermedie su una Cpu come il processore Cortex-A9 utilizzato nel sistema Hps (Hard processor system) dei SoC della serie Cyclone V. L'elaborazione ad alto livello, che riguarda essenzialmente codice di controllo, può essere mappata su uno o entrambi i core Cortex-A9 presenti nel sistema Hps. L'ultima fase della catena di elaborazione, dove vengono rilevati gli oggetti e prese le decisioni, può essere implementata su un microcontrollore esterno. Nel corso dell'intero ciclo di elaborazione, l'insieme di dati di ingresso è ridotto dopo ogni fase a un insieme di dati più significativo e la criticità per la sicurezza aumenta in virtù proprio di questa riduzione. Ne consegue che l'elaborazione di basso livello può essere considerata come un processo QM (Quality managed) oppure come un processo di livello Asil basso (come ad esempio Asil-A). Ciò è dovuto al fatto che i malfunzionamenti introdotti durante l'elaborazione di un singolo pixel avranno un impatto modesto, se non trascurabile, sulle prestazioni del successivo algoritmo. Nell'esempio preso in considerazione, per l'elaborazione di livello intermedio si ipotizza la conformità ai livelli Asil-A o Asil-B, mentre per quella di alto livello l'ipotesi è che sia conforme al livello Asil-B. Una volta classificati gli oggetti, vengono generate le liste degli obbiettivi che sono trasmesse al microcontrollore, al quale sono assegnati i compiti di rilevare gli oggetti e prendere le decisioni più opportune. Trattandosi della fase più critica della catena del segnale, che può influenzare direttamente il comportamento della vettura, dovrà risultare conforme alle specifiche di livello più alto (Asil-D). In questo genere di applicazioni è sicuramente vantaggioso eseguire un'analisi ancora più completa del flusso di dati rispetto a quella fatta precedentemente perché la definizione della criticità della sicurezza per ciascuno stadio può avere un'influenza diretta sulle prestazioni dell'intero sistema. L'imposizione di requisiti di sicurezza troppo severi per le fasi iniziali del processo di elaborazione potrebbe complicare il raggiungimento delle prestazioni previste a livello di sistema, senza peraltro portare benefici significativi in termini di sicurezza complessiva. Naturalmente nelle prime fasi della catena di elaborazione vi potrebbero essere malfunzionamenti tali da pregiudicare anche in modo grave la funzionalità o la sicurezza del sistema. Un guasto permanente nell'elaborazione di basso livello potrebbe provocare un danneggiamento permanente dei dati utilizzati dai livelli superiori: in ogni caso un guasto di questo tipo può essere rilevato in maniera molto semplice con una verifica di attendibilità che ha un impatto di ridotta entità sulle prestazioni del sistema.
Una telecamera frontale
Un circuito di power management esterno fornisce la potenza richiesta al SoC della serie Cyclone V. Un circuito per il monitoraggio della tensione separato genererà un reset nel caso i valori delle tensioni di alimentazione superino il normale intervallo di funzionamento. È prevista la possibilità di collegare una memoria esterna di tipo non volatile a un modulo Spi (Serial peripheral interface) quadruplo (quad Spi) da utilizzare durante il processo di booting del sistema per caricare l'applicazione e configurare l'Fpga. Per l'esecuzione del codice applicativo e la memorizzazione dei dati e dei frame dell'immagine si utilizza una memoria Ddr. Al controllore esterno collegato mediante un'interfaccia Spi sono demandati i compiti di rilevare un oggetto, prendere le decisioni finali e comunicare con il resto dell'infrastruttura del veicolo attraverso l'interfaccia Can.I dati provenienti dal sensori di immagine sono ricevuti dalla porta video e trasferiti al blocco di pre-elaborazione dell'immagine. Questo blocco corrisponde allo stadio di elaborazione dell'immagine di basso livello. In questo esempio, i dati in uscita da questo blocco passano attraverso il bridge F2H (Fpga to HPS) e sono scritti nella memoria Ddr: per un'implementazione più efficiente i dati potrebbero essere invece trasferiti direttamente allo stadio successivo. L'elaborazione intermedia, corrispondente al secondo stadio, viene eseguita dal blocco per il trattamento dell'immagine. I dati in precedenza immagazzinati nella memoria Ddr sono recuperati e trasferiti attraverso il bridge H2F (Hps-to-Fpga) al blocco per il trattamento dell'immagine e quindi scritti nuovamente nella memoria Ddr. Nell'esempio preso in considerazione l'elaborazione di alto livello viene eseguita dal blocco Hps.
Funzioni diagnostiche
A questo punto è utile esaminare alcune delle funzioni diagnostiche che potrebbero essere utilizzate per rilevare eventuali guasti nelle differenti sezioni del progetto. Mentre alcune di esse sono in grado di rilevare guasti permanenti, altre possono rilevare solamente guasti transitori, oppure di entrambi i tipi. Un guasto si definisce transitorio quanto appare e scompare nel corso del tempo. Per eseguire l'analisi è necessario prendere in esame i guasti nella memoria utilizzata per una specifica funzione e i guasti potenziali nei circuiti logici preposti all'espletamento di tale funzione. Prima di essere impiegato dall'applicazione, il sensore di immagine deve essere configurato e la configurazione è modificata su base continua durante l'esecuzione dell'applicazione per consentirne l'adattamento alle differenti condizioni luminose. Poiché il sensore è un elemento critico per il corretto funzionamento dell'applicazione, è consigliabile la verifica della sua configurazione almeno una volta durante l'Ftti (Fault tolerant time interval). Ciò non permetterà di garantire la copertura di tutti i potenziali guasti del sensore, ma in ogni caso effettuerà il controllo del set di registri di configurazione. Alcuni dei sensori utilizzati in ambito automotive consentono la trasmissione di determinati dati del registro di configurazione in line ausiliarie di ciascun frame dell'immagine. Grazie a questa funzionalità è possibile verificare le impostazioni del sensore per ciascun frame senza dover leggere i registri attraverso l'interfaccia I2C. Una verifica di questo tipo potrebbe essere implementata nell'Fpga durante lo streaming dei dati del frame senza dar luogo a nessun sovraccarico sulla Cpu. Nel caso dell'elaborazione di basso livello, è estremamente improbabile che una variazione in un singolo pixel avrà un'influenza significativa sul comportamento dell'applicazione: per questo motivo in molti casi questo tipo di guasti può essere trascurato. In ogni caso è necessario analizzare i guasti che potrebbero produrre frame completamente danneggiati o mancanti. Parecchi sensori di immagine prevedono una funzionalità che permette di trasmettere un frame di test definito al posto dei dati dell'immagine normale. Poiché i dati di ingresso sono definiti, lo sono pure i dati di uscita del blocco di pre-elaborazione dell'immagine. Dopo questa pre-elaborazione è eseguito un test. Un collaudo di ridondanza ciclica o Crc (Cyclic redundancy check) dei dati di uscita, per esempio, consente di individuare qualsiasi guasto di natura permanente presente nel sistema. Un test di questo tipo potrebbe garantire la copertura completa dei guasti permanenti per tutto il percorso dati. Inoltre dovrebbe essere possibile rilevare le variazioni dei dati nel corso della trasmissione da un blocco al successivo nell'Fpga. Il test pattern o la metodologia che prevede la trasmissione di un frame di test appena menzionata, sebbene garantiscano la copertura della maggior parte dei guasti permanenti, non sono in grado di identificare i guasti transitori. Guasti di questo tipo potrebbero essere rilevati per mezzo di ridondanze a livello di trasmissione o di informazione. L'elaborazione dell'immagine di livello intermedio prevede l'esecuzione di algoritmi di rilevamento di contorni o angoli, come pure di algoritmi di estrazione delle caratteristiche. Il set di dati generato è quindi ridotto poiché sono analizzate solo le caratteristiche di interesse di un'immagine. A seguito della diminuzione dei dati aumenta il rischio che la perdita di una caratteristica, imputabile a un malfunzionamento, porti al mancato rilevamento di un oggetto nella fase di elaborazione successiva. Lo stadio di elaborazione dell'immagine di livello più alto prevede il rilevamento e la classificazione degli oggetti. In termini software, in questa fase è coinvolto principalmente codice di controllo, quindi particolarmente adatto a girare su una Cpu. Il blocco Hps integra diverse funzionalità hardware (come ad esempio Ecc, Mmu, watchdog) utili per eseguire operazioni di diagnostica dei guasti nell'Hps. Un altro aspetto importante della sicurezza funzionale è assicurare una riduzione dei guasti sistematici. Per conseguire tale obiettivo è necessario utilizzare processi di sviluppo e tool particolarmente "robusti". Lo standard ISO26262 specifica in maniera dettagliata i requisiti per la gestione della sicurezza funzionale, come ad esempio l'uso di verifiche (misure di conferma) per le differenti attività durante il ciclo di vita di sicurezza e i processi di supporto, come la gestione delle modifiche e della configurazione. È inoltre necessario verificare che i tool utilizzati non contribuiscano all'insorgere di potenziali malfunzionamenti dell'applicazione e adottare adeguate misure per ridurre il rischio che ciò accada.
I vantaggi della programmabilità
I sistemi Adas rappresentano rappresentano attualmente il mezzo più innovativo per aumentare la sicurezza della guida su strade sempre più congestionate dal traffico. Per sistemi di questo tipo, con requisiti in termini di prestazioni che rappresentano una sfida impegnativa per i prodotti Cots standard attuali e futuri, la programmabilità degli Fpga può garantire vantaggi significativi. L'implementazione di diagnosi specifiche per la particolare applicazione considerata può contribuire a incrementare la copertura diagnostica del sistema. Poiché numerosi prodotti Cots non sono stati progettati per soddisfare ai requisiti di sicurezza funzionale, l'adozione di una piattaforma e di un ambiente di sviluppo adeguati, unitamente alla collaborazione con partner con le competenze richieste nel campo della sicurezza funzionale, può portare significativi vantaggi nello sviluppo del sistema complessivo.
