La sicurezza su strada ha ottenuto vantaggi consistenti dalla legge di Moore, dagli aumenti di capacità di elaborazione e dallo sviluppo dei sensori di immagine Cmos che hanno consentito ai produttori di veicoli di introdurre i sistemi avanzati di assistenza al conducente. Un sistema Adas migliora la conoscenza del conducente dell’ambiente circostante, riducendo le probabilità di collisione. Alcuni sistemi sono anche in grado di monitorare il conducente e di allertarlo in caso quest’ultimo, ad esempio, si assopisca. Il sistema Adas prende il controllo del veicolo in misura sempre maggiore e fornisce assistenza al conducente con funzionalità quali il parcheggio assistito, l’indicatore di corsia e il controllo adattativo di crociera. Non sorprende il fatto che, secondo le previsioni, il mercato dei sistemi Adas varrà 42 miliardi di dollari all’anno entro il 2021 ed è attualmente interessato da un tasso annuo di crescita del 10%.
L’elaborazione delle immagini
Nell’ambito della visione embedded, gli Adas possono essere suddivisi in due categorie, con i sistemi a monitoraggio esterno che gestiscono funzioni come l’abbandono di corsia, il rilevamento di oggetti, il rilevamento di punti ciechi e il riconoscimento della segnaletica stradale. I sistemi interni per contro monitorano aspetti come la sonnolenza del conducente e la rilevazione dell’occhio. Sia le applicazioni interne dei sistemi Adas, sia quelle esterne portano con sé sfide da affrontare nell’implementare gli algoritmi di elaborazione delle immagini. Queste sfide vanno dalla capacità di realizzare gli algoritmi richiesti per l’applicazione, alla conformità verso gli standard automotive più appropriati. Molte applicazioni Adas inoltre richiedono un approccio “sensor fusion” che combina gli ingressi provenienti da diversi sensori, aumentando così in modo significativo la potenza di elaborazione richiesta. La combinazione dei sensori può essere omogenea laddove siano usati più sensori dello stesso tipo, o eterogenea laddove siano usati diversi tipi di sensore per estrarre le informazioni richieste. Molte applicazioni utilizzano un SoC Interamente Programmabile o un Fpga per implementare il sistema, in virtù della flessibilità fornita. Entrambi sono usati per eseguire gli algoritmi richiesti, ma anche perché sono in grado di interfacciarsi con diversi tipi di sensori e di rete. Accanto alle prestazioni, le applicazioni Adas comportano inoltre numerose problematiche a livello di sistema che potrebbero non essere ovvie a prima vista, e i produttori di autoveicoli devono raggiungere livelli stringenti di emissioni standard di inquinanti, e di conseguenza il peso e il consumo di potenza della soluzione complessiva è importante. Anche il costo della soluzione è critico per via delle numerose decine/centinaia di migliaia di veicoli che sono prodotti. Essendo la sicurezza del sistema un fattore cruciale regolato da numerosi standard, l’uso di un SoC o di un Fpga può aiutarci ad affrontare molti di questi aspetti.
L’architettura di un sistema Adas
Lo sviluppo di un sistema di visione Adas embedded che monitora sia le videocamere esterne, sia quelle interne, può essere visto come una delle operazioni più difficoltose in un sistema Adas. Questo sistema deve essere in grado di interfacciarsi con diverse videocamere posizionate attorno al veicolo, elaborare le immagini e fornire le informazioni agli occupanti. Molte tipologie di videocamere si avvalgono di connessioni cablate Lvds punto-punto per trasferire i dati, tuttavia ciò comporta un costo e un peso aggiuntivo in termini di cablaggio richiesto. Esistono però degli approcci alternativi che stanno sempre più prendendo piede, e ciò sposta alcune funzionalità all’interno della videocamera stessa. Se l’immagine prodotta dalla videocamera è un’immagine compressa e non grezza, allora è possibile adottare delle architetture su rete. Tali reti potrebbero essere basate attorno a bus usati comunemente, quali: Most, una rete ad alta velocità che può essere realizzata su strati fisici di tipo ottico o elettrico; Idb-1394, una rete ad alta velocità realizzata su uno strato fisico elettrico, che a sua volta è implementato in una topologia daisy chain; Ethernet Avb che fornisce la possibilità di instradare dati di immagine e altri dati lungo il veicolo quando necessario. Qualora si optasse per l’uso di una di tali reti, l’architetto di sistema dovrà assicurare che la banda necessaria sia disponibile per trasferire i dati di immagine fra la videocamera e l’unità Adas con la latenza richiesta per la propria applicazione. Potrebbe essere necessario condividere i dati generati dal sistema Adas con altri sistemi all’interno del veicolo, ad esempio con le unità per il controllo adattativo di crociera o per il parcheggio assistito. Di conseguenza, l’Adas deve essere in grado di interfacciarsi ad altre interfacce automotive comunemente usate come Can o FlexRay.
L’approccio basato su SoC
A livello di architettura, l’uso di un approccio basato sull’uso del SoC Zynq Interamente Programmabile di Xilinx offre numerosi vantaggi e, se si usano connessioni punto a punto per interfacciarsi alle videocamere, i ricevitori di queste ultime possono essere implementati in logica programmabile a monte della catena di elaborazione delle immagini. Usando un SoC interamente programmabile, la flessibilità del sistema di elaborazione permetterebbe la semplice inclusione di un’interfaccia Can, Ethernet e di altri protocolli come FlexRay, combinati con i circuiti logici all’interno della logica programmabile e con uno strato fisico esterno se necessario. La combinazione dei processori dual core e della logica programmabile consente di ottenere consumi molto ridotti per ciascun pixel, essendo il sistema strettamente integrato.
L’architettura dei SoC Interamente Programmabili
L’uso della logica programmabile per implementare l’interfaccia delle videocamere e la catena di elaborazione delle immagini è là dove l’uso del SoC risulta più indicato. Al contempo il sistema di elaborazione del SoC è in grado di assicurare la comunicazione, il controllo e le ulteriori operazioni richieste per l’elaborazione algoritmica. La sequenza di elaborazione delle immagini può essere generata usando le numerose librerie di blocchi Ip forniti e i core Ip più specifici forniti da produttori specializzati, riducendo così il time-to-market. Se volessimo sviluppare ulteriori algoritmi, potremmo utilizzare la gamma di tool di sintesi ad alto livello come Vivado Hls, SDSoC e Matlab per accelerare lo sviluppo. Piuttosto che sviluppare l’Ip usando un linguaggio di descrizione hardware tradizionale come Vhdl o Verilog, possiamo usare un linguaggio di livello superiore come il C o il C++, riducendo il time-to-market. È possibile ottenere un’ulteriore accelerazione dell’algoritmo ricorrendo ad ambienti open source come OpenCV, e gli algoritmi sviluppati usando questo ambiente possono essere mappati in una libreria video Hls supportata sia da Vivado Hls, sia da SDSoC. Questo semplifica la transizione dal prototipo per uno studio di fattibilità agli algoritmi che girano sull’hardware finale per la caratterizzazione e la qualifica. Molte architetture implementate faranno uso della memoria Ddr del processore come frame buffer, e ciò consente al processore di accedere alle immagini quando necessario, per la successiva trasmissione a valle, se si usa ad esempio un sistema basato su Ethernet o PCIe. Possiamo anche usare la potenza di calcolo del sistema di elaborazione per eseguire ulteriori algoritmi di elaborazione delle immagini sulle immagini archiviate all’interno della memoria Ddr, prima che sia necessario il loro reinserimento all’interno della catena di elaborazione delle immagini. Questo fornisce una funzionalità molto interessante, che consiste nella possibilità per il SoC stesso di costituire il proprio prototipo e la propria piattaforma dimostrativa. Il ricorso ad ambienti di sviluppo comuni per le applicazioni di visione embedded, come OpenCV, che girano sulle unità di elaborazione all’interno del processore, fornisce un prototipo su misura. Questo sistema può quindi essere ottimizzato per le prestazioni, usando il lato in logica programmabile del SoC.
L’importanza della sicurezza
La natura stessa dell’Adas è di contribuire alla sicurezza automobilistica. Poiché tale sistema, come molti altri sistemi in alta affidabilità, deve essere sviluppato in conformità ad uno standard, si applica all’Adas l’Iso26262. Questo standard definisce numerosi livelli di integrità della sicurezza automobilistica, che specificano la durata di funzionamento prima del guasto, durata espressa in ore. Vi sono quattro livelli di Asil a partire da D che è il più alto e il più difficile da raggiungere fino ad A, il più basso. Il raggiungimento di tali requisiti richiede un ciclo di vita integrato di progettazione e di realizzazione, per assicurare non solo l’ottenimento del livello desiderato di Asil, ma anche che il pacchetto di dati generato lo confermi contenendone la prova necessaria. Le applicazioni automotive operano in ambienti ostili, perciò gli sviluppatori devono assicurare l’uso di componenti di classe automotive, ed esempio quelli certificati Aec-Q100, che sono stati fabbricati e qualificati per uno standard di livello superiore rispetto ai componenti commerciali. Questi devono anche considerare la sicurezza del sistema, ossia devono impedire a persone non autorizzate di apportare modifiche al sistema. L’uso di un SoC interamente programmabile offre la possibilità di usare le funzionalità di avvio sicuro per evitare che programmi e sequenze di bit non autorizzati vengano configurati all’interno del sistema. Per ottenere ciò, è possibile ricorrere agli algoritmi crittografici Aes, Hmac e alla verifica Rsa combinata con la capacità di usare la tecnologia TrustZone. Quest’ultima consente ai progettisti di sistema di mettere a punto ambienti ortogonali per il software che limitano l’accesso alle funzioni hardware all’interno del SoC, incluse le periferiche in logica programmabile. La salute del sistema può essere monitorata usando il core Xadc, che permette di controllare le tensioni di alimentazione del SoC e la temperatura del die. È anche possibile usare i pin esterni del SoC per monitorare altri segnali analogici all’interno del più ampio sistema, fornendo ulteriori funzioni di monitoraggio dello stato di salute e dell’utilizzo del sistema stesso. Dato che il SoC fornisce processori strettamente integrati e la logica programmabile accoppiata con un Adc interno, ne deriva un beneficio notevole in termini di una riduzione del numero dei componenti. A sua volta quest’ultima contribuisce anche in modo significativo all’ottenimento del tasso di guasto da noi desiderato.
