È opinione comune che sia più difficoltoso sviluppare software per sistemi con più processori rispetto a sistemi a processore singolo, ma in realtà non è sempre così. Il nostro gruppo di progettazione a TRW Conekt, il ramo di consulenza di TRW Automotive, di recente ha portato avanti un progetto che dimostra come il partizionamento dell'hardware per affrontare con successo il problema in questione consente di sviluppare sistemi molto efficienti usando più processori. Avevamo il compito di fornire l'elettronica per l'elaborazione embedded da usare all'interno delle autovetture per un progetto noto come “Foot-LITE” (condotto da MIRA e sostenuto dalla Direzione Strategie Tecnologiche, finanziato dal governo del Regno Unito, dal Dipartimento dei Trasporti e dal Consiglio delle Ricerche sulle Scienze Fisiche ed Applicate). Questo progetto fornisce un feedback ai conducenti riguardo alle abitudini di guida dal punto di vista sia della sicurezza, sia della riduzione dei consumi.
Il feedback al conducente avviene in due modi:
- un sistema di visualizzazione su smartphone, montato sul cruscotto - ideato dall'Università Brunel e sviluppato da HW Communications - che assicura la comunicazione in tempo reale con il conducente in merito ad eventi che richiedono un'attenzione immediata;
- il sistema raccoglie in continuazione i dati di viaggio, inclusi i flussi video di “eventi” particolari, e li carica su un server basato su internet che permette agli utenti di guardarli con comodo.
La decisione su quali siano gli eventi da segnalare all'utente è data da un algoritmo sviluppato dal partner Ricardo UK, in base ai consigli sulla guida forniti da un altro partner, l'Istituto degli Automobilisti Avanzati.
Il progetto adatterà questo sistema a una flotta di 30 veicoli. I piloti collaudatori saranno degli impiegati statali del Consiglio della Contea di Hampshire, un altro partner del progetto. Il progetto ha incorporato gradualmente i risultati di ricerca ottenuti dalla collaborazione di 12 partner industriali, governativi ed accademici: abbiamo avuto l'esigenza di una soluzione molto flessibile per le nostre sfide di elaborazione.
Il sistema di base
Per eseguire le funzioni di elaborazione delle immagini, abbiamo avuto a disposizione un sistema di elaborazione, già in fase di sviluppo all'interno di un altro progetto. Questo sistema è basato su un singolo dispositivo Spartan-3A XC3SD3400A di Xilinx, collegato a quattro blocchi di memoria Ddr indipendenti, un'architettura che consente agli utenti di mettere a punto diverse configurazioni processore/logica. Ad esempio, è possibile usare l'intera matrice Fpga sottoforma di risorse puramente logiche realizzate interamente in Hdl. In alternativa, si possono usare i tool ad alto livello come Xilinx Edk per realizzare quattro (o più) blocchi microcontrollore sintetizzabili. Ciascuno dei quattro blocchi avrebbe accesso al proprio dispositivo di memoria Ddr dedicato, proteggendo i dati dall'interferenza degli altri microcontrollori. Per altre funzioni semplici, è possibile includere ulteriori processori facendo uso di blocchi Bram incorporati. Inoltre, l'I/O verso il mondo esterno è configurabile usando delle piccole schede figlie, che consentono di ottenere un tempo di risposta rapido per insiemi di I/O personalizzati per progetti diversi.
I partner del progetto hanno deciso molto presto che sarebbe stato necessario disporre di un'interfaccia Usb, poiché essa consente di aggiungere un'ampia varietà di periferiche al sistema. Questo ha richiesto un tipo di pila Usb - ne abbiamo ottenuta una usando la realizzazione Petalinux di ucLinux — e una scheda figlia con un dispositivo Usb host.
L'uso di Linux ci semplifica la gestione dei dispositivi flash SPI che il sistema fornisce per la sequenza di bit dell'Fpga e per la memorizzazione del codice applicativo. Abbiamo installato un semplice file system JFFS2 per consentire gli aggiornamenti sul campo degli applicativi, sia attraverso rete Ethernet (usando l'Ftp), sia avviando il sistema con una chiave di memoria Usb che contiene uno script per caricare nuovo codice sulla flash interna. In un sistema embedded tradizionale, tutto ciò richiederebbe la stesura di codice applicativo a basso livello da parte del gruppo software. Tuttavia, con Linux a nostra disposizione, possiamo agevolmente scrivere dei semplici script Bash per controllare questi processi.
Algoritmi Foot-LITE
Ricardo ha sviluppato gli algoritmi fondamentali che valutano le azioni del conducente e li ha eseguiti sul proprio sistema rCube di prototipazione rapida. Abbiamo adottato questo approccio per le prove iniziali al simulatore e per tre veicoli di test. In questi ultimi, un sistema di visione incorporato (basato su un progetto esistente di TRW - contenente anch'esso un Fpga) misurava la distanza dal veicolo di fronte e stabiliva la posizione del veicolo all'interno della corsia. Un sistema radar forniva una sorgente alternativa di informazioni sulla distanza all'interno dei veicoli di test. Inoltre, abbiamo eliminato il sistema radar per le prove su scala più ampia, dato che il sistema di visione forniva informazioni sufficienti per l'applicazione. Abbiamo dotato il veicolo di una videocamera anteriore e di un sottosistema di elaborazione, che sono combinati all'interno di una piccola unità collocata vicino allo specchietto retrovisore. Gli algoritmi residenti in questo sottosistema elaborano le immagini video per misurare la distanza fra l'auto e il margine della corsia. Inoltre, un algoritmo parallelo individua i veicoli che si trovano di fronte al veicolo Foot-LITE e fornisce una misura della distanza da questi ultimi. Il sottosistema trasmette i propri dati all'unità del sistema Foot-LITE usando il bus standard Can (Controller area network) per applicazioni automotive. Abbiamo integrato un accelerometro a tre assi e un package sensibile alla velocità di oscillazione all'interno dell'unità Foot-LITE, fornendo potenzialmente, quando necessario, l'accesso ad informazioni dinamiche ad alta velocità e a latenza ridotta sul veicolo. Gli algoritmi Foot-LITE fondono tutti questi dati per fornire in uscita un insieme di risultati semplici per il conducente, in relazione al suo stile di guida.
Realizzazione dell'algoritmo
All'inizio abbiamo pensato di prevedere un sistema a singolo processore. Tuttavia, è stato subito chiaro che un processore dedicato avrebbe semplificato l'operazione di integrazione per ciascuna iterazione dello sviluppo dell'algoritmo. Abbiamo isolato il processore host principale ed il processore con l'algoritmo Foot-LITE realizzando le comunicazioni attraverso il sistema bus MicroBlaze Fast Simplex Link (Fls). Questo rende possibile un isolamento completo delle memorie dei processori (diversamente dalle comuni metodologie a memoria condivisa), il che semplifica enormemente l'operazione di integrazione, dato che i bachi non possono “migrare” da un processore ad un altro attraverso alterazioni della memoria. In più, non c'è competizione per i cicli del processore, e ciò significa che i nostri partner possono essere sicuri che qualsiasi modifica che noi effettuiamo all'applicazione host non influirà sulle prestazioni dell'applicazione stessa. Abbiamo sviluppato un gruppo di funzioni esterne che ci consentono di aggiungere direttamente il codice generato in linguaggio C dal compilatore Simulink, senza dover apportare grandi modifiche all'interfaccia. Forniamo una piccola quantità di memoria non volatile su scheda attraverso un bus I2C, che è necessaria per memorizzare vari parametri di regolazione all'interno degli algoritmi Foot-LITE. Questo ha richiesto un semplice adattatore per fornire agli algoritmi un accesso semplice dall'ambiente Simulink per leggere questa memoria all'accensione e per scrivere nuovamente sulla memoria in fase di spegnimento. Il sistema doveva essere in grado di misurare le accelerazioni e la velocità di oscillazione, oltre a comunicare attraverso il bus Can con il sistema di localizzazione della corsia e dei veicoli. Dato che disponevamo già di driver Can a basso livello ed eravamo preoccupati sulla velocità di risposta di un'applicazione Linux per misurare le informazioni dinamiche di un veicolo a intervalli di 40 millisecondi, abbiamo deciso di inserire un terzo MicroBlaze all'interno del sistema.
Questo ha evitato la necessità di trasferire i driver Can su Linux, e ha consentito di ottenere prestazioni deterministiche per mezzo di un ulteriore nodo processore isolato - aspetto questo critico per gli algoritmi - che faceva uso di misure dinamiche. In più, questo approccio ci ha consentito di suddividere l'operazione di scrittura del software per consentire lo sviluppo parallelo. Ancora una volta, abbiamo usato Fls come interfaccia fra il processore dinamico e il processore con l'algoritmo Foot-LITE.
Cattura e compressione video
Il sistema, come concepito inizialmente, forniva misure semplici della larghezza e dello spostamento dalla corsia, della distanza dal veicolo di fronte e così via provenienti dal sistema di visione, che erano trasmesse attraverso protocollo Can all'unità che esegue l'algoritmo Foot-LITE.
I partner del progetto hanno deciso di migliorare questa idea catturando fotogrammi video per la trasmissione al server, allo scopo di offrire assistenza contestuale non in linea per interpretare i consigli forniti dal sistema. Dato che il requisito era solo per video di “qualità internet” (300 x 200 pixel a 5 Hz), abbiamo pensato di poter assegnare facilmente ad un quarto MicroBlaze la funzione di compressione del flusso video per un insieme semplice di immagini Jpeg in tempo reale. L'immagine proveniente dalla videocamera era un fotogramma video di tipo wide-Vga (720 x 480 a 30 Hz). Chiaramente, il sottocampionamento dell'immagine era un'operazione da eseguire su hardware. Abbiamo ideato una semplice periferica per gestire l'operazione di sottocampionamento, semplicemente lasciando un pixel su due e una linea su due per produrre un'immagine da 360 x 240. Questa periferica lascia anche quattro fotogrammi su cinque per ottenere la velocità di trama richiesta. Non è necessario niente di più complesso per produrre risultati visibilmente accettabili, dato che l'elaborazione Jpeg rende invisibili gli artefatti prodotti dalla distorsione da intermodulazione. Per sviluppare questa periferica abbiamo usato System Generator, dato che quest'ultimo rende l'esportazione verso l'Edk molto semplice e immediata, e avevamo già avuto esperienza dell'uso di System Generator per compiti più complessi di elaborazione delle immagini. Il bus periferico usato per il sottocampionamento convoglia i dati all'interno della Sdram connessa all'unità di elaborazione Jpeg, che in seguito comprime ciascun fotogramma, al suo arrivo, all'interno di un buffer circolare, fino a quando l'algoritmo Foot-LITE invia un segnale di indicazione. L'unità di elaborazione Jpeg invia i fotogrammi video compressi (ancora su Fls) al MicroBlaze host. Abbiamo usato una libreria di codice fornita dall'Independent Jpeg Group e ci siamo resi conto che aveva bisogno di pochissime ottimizzazioni per operare a 5 Hz. Di nuovo, il fatto di avere un processore isolato ha consentito a un altro ingegnere software di lavorare in parallelo su questo aspetto del sistema da un'altra sede.
Il bluetooth verso lo smartphone e la diagnostica su scheda
La semplicità di installazione era un fattore critico per il progetto. Un altro aspetto importante da considerare era la riduzione del numero dei fili di connessione richiesti sistema. Abbiamo scelto Bluetooth come interfaccia verso lo smartphone. I driver per le chiavi standard Usb Bluetooth sono presenti normalmente all'interno del kernel ucLinux, anche se abbiamo dovuto realizzare noi stessi i tool per lo spazio utente. Questi hanno alcune dipendenze su altri elementi di codice, che sono anche cross-compilati con il pacchetto di tool Petalinux e sono aggiunti al file system ucLinux. Una volta che abbiamo optato per Bluetooth come interfaccia verso lo smartphone, è stato naturale scegliere Bluetooth per l'interfaccia verso il Sistema di Diagnostica su Scheda. Abbiamo fatto uso di un modulo di interfaccia Bluetooth-OBD standard disponibile sul mercato, rimuovendo così un'altra connessione cablata dal sistema.
La ricerca di errori è semplificata
Mettere a punto un sistema con più ramificazioni parallele di esecuzione è sempre sfidante. Tuttavia, la suddivisione del sistema fra più processori rende le cose più semplici. Non è necessario un debugger in grado di tenere conto della presenza di più ramificazioni (come sarebbe invece richiesto quando si cerca di mettere a punto più processori all'interno dell'ambiente Linux). Il debugger di Xilinx (XMD) si può connettere a più processori, e usando il Tcl (il linguaggio comandi, che l'XMD comprende), possiamo automatizzare l'impostazione e il download del codice da testare per più processori. Naturalmente, era disponibile anche l'approccio comune alla ricerca errori in un sistema embedded attraverso l'istruzione printf, dato che ogni processore dispone della propria porta seriale. Un altro tool di grande valore quando si esegue la ricerca errori sulle comunicazioni interprocessore è stato ChipScope Pro. Questo analizzatore logico dedicato, realizzato all'interno della matrice Fpga, ci ha consentito di catturare i dati evitando le connessioni Fls e restringendo il numero dei possibili bachi difficili da individuare sia per il trasmettitore, sia per il ricevitore, e quindi delle linee di codice che contengono l'errore. L'isolamento fornito usando quattro processori implica che una volta che viene messo a punto un particolare elemento, questo (in larga misura) non dovrà essere più ricontrollato. Non vi é alcuna delle interazioni poco chiare che causano sempre problemi quando si integra del codice eterogeneo all'interno di una grande applicazione monolitica, o quando si fanno girare più processi su un unico processore.
La realizzazione su Fpga
In questo progetto, non c'è pressoché Hdl - semplicemente un adattatore ad alto livello che integra il progetto basato sull'Edk con un una piccola parte di codice per la temporizzazione di supervisore, allo scopo di garantire che il sistema si spenga dopo che il conducente abbia spento il motore. L'Edk genera la vasta maggior parte dell'Fpga (il file MHS è lungo più di 1.300 linee!), mentre System Generator produce il sottocampionatore video. Abbiamo configurato tutti e quattro i microcontrollori con cache e con unità a virgola mobile. Con quattro processori, quattro interfacce di memoria Ddr e un insieme di periferiche (che includono interfacce Ethernet, Spi, IIC, Can, Uart, temporizzatori e GPIO), viene occupato circa il 70 per cento delle lookup table del dispositivo (approssimativamente 28.000 Lut). Come avviene generalmente con gli Fpga basati su microcontrollore, le memorie a blocchi sono molto utilizzate, anche di oltre il 90 per cento, che corrisponde a 119 Bram, ma i blocchi Dsp sono relativamente poco usati. Solo le unità a virgola mobile in ogni processore (otto in ciascuno di essi, per un totale di 32) li richiedono.
Come assemblare il tutto
Il microcontrollore host avvia il kernel Linux dalla flash interna e quindi monta il proprio file system locale. I processori slave sono dotati ciascuno di un programma basato su Fls per il caricamento del kernel e per l'avvio del sistema operativo, che accetta un S-record standard, lo analizza, lo copia nella memoria locale e lo esegue. Il processore Linux trasmette semplicemente l'Srecord dal file system direttamente al pseudo-file Fls (usando l'utilità interna dd). Come già descritto, tutta la comunicazione interprocessore ha luogo su una griglia di comunicazione interamente connessa di collegamenti Fls. Questi sono tutti ampi 32 bit e operano a 60 MHz, fornendo un'ampia banda di comunicazione a latenza ridotta. Malgrado possa sembrare limitante evitare di ricorrere alla memoria condivisa, il lato positivo è che questo sistema fornisce i vantaggi di isolamento già discussi. L'architettura hardware corrisponde bene ai requisiti hardware, il che produce un partizionamento intuitivo del software. Il microprocessore con l'algoritmo Foot-LITE invia i segnali di attivazione al compressore Jpeg quando richiesto e comunica con il display smartphone. Il processore Linux è interposto fra le comunicazioni Bluetooth e il resto del sistema (Fig. 3). Oltre ai segnali immediati verso il driver, questo invia un flusso continuo di informazioni sullo stato del veicolo e flussi occasionali di video attraverso lo smartphone per la trasmissione a valle verso un server centrale. Alla fine del viaggio, quando il conducente spegne il motore, il processore principale informa i processori slave, i quali possono quindi effettuare le proprie procedure di spegnimento (come la scrittura di parametri aggiornati in una memoria non volatile per la regolazione) prima di informare il processore principale che essi si trovano in uno stato sicuro per lo spegnimento. A questo punto, il processore host invia segnali all'alimentazione e il sistema entra in una modalità di sleep con consumi molto ridotti, in attesa dell'accensione successiva del motore. Nel caso improbabile in cui il software non invii il segnale di spegnimento, a distanza di un paio di minuti dallo spegnimento del motore, un temporizzatore hardware all'interno della matrice Fpga fa scendere l'alimentazione, per evitare di scaricare la batteria del veicolo. Nella fase finale del progetto, due membri accademici del consorzio (l'Università di Newcastle e l'Università di Southampton) analizzeranno i dati trasmessi in uscita dal veicolo nel caso di utilizzo reale in autostrada, per valutare l'efficacia del sistema nel modificare il comportamento del conducente.
