Soluzioni basate su stack per l’elaborazione delle immagini su rete Edge e su Cloud Nick Ni & Adam Taylor


Uno degli aspetti positivi dell’elaborazione delle immagini è l’ampia gamma di applicazioni, dai droni, alle auto autonome, all’imaging scientifico e medico. La gamma variegata di applicazioni porta con sé una serie eterogenea di requisiti e di soluzioni, dall’integrazione dell’intelligenza alla periferia della rete all’utilizzo della potenza del cloud. In entrambi i casi gli utenti si troveranno di fronte a numerose sfide relative al proprio sistema di elaborazione. Questo articolo considera quali sono tali sfide e in che modo possono essere affrontate usando un approccio basato su stack di accelerazione.

 

 

Figure 1 e 2 – Diversi esempi di Imaging Medicale basato su Cloud e un Drone basato su tecnologia Edge usato in campo Agricolo

 

Le sfide

Le applicazioni che effettuano elaborazioni su rete sia di tipo Edge, sia Cloud si trovano inizialmente di fronte a un problema comune, che consiste nell’esecuzione dell’algoritmo di elaborazione delle immagini in modo da soddisfare i propri requisiti complessivi a livello di sistema. Nella maggior parte dei casi, ci sarà una differenza su quale debba essere il requisito determinante per il sistema. Per un’implementazione basata su tecnologia Edge potrebbe essere la latenza dell’algoritmo, potendo essere necessario prendere decisioni in base alle informazioni contenute al suo interno. Mentre per una soluzione basata su Cloud potrebbe essere determinante il requisito di un’accuratezza eccezionale, dato che questa tecnologia potrebbe essere usata per prendere decisioni in campo scientifico o medico.

Entrambe le implementazioni si baseranno inoltre in modo massiccio sull’apprendimento automatico approfondito e sull’intelligenza artificiale, anche se in modi diversi. L’elaborazione alla periferia della rete userà i classificatori generati dall’apprendimento artificiale approfondito all’interno del cloud per implementare i propri algoritmi di rilevamento degli oggetti. Mentre la soluzione basata su cloud userà l’apprendimento automatico approfondito e le Reti Neurali sia per generare i classificatori sia per usarli in seguito all’interno della propria applicazione.

Si può osservare quindi che entrambe le implementazioni richiedono la capacità di operare con infrastrutture moderne come OpenCV, OpenVX, Caffe e FFmpeg, per soddisfare i propri requisiti di elaborazione delle immagini. Ma riguardo ad altri requisiti che sono determinanti in queste diverse implementazioni, essi devono in seguito essere presi in considerazione e risolti.

L’elaborazione alla periferia della rete porta con sé non solo l’esigenza di elaborare e di prendere decisioni in tempo reale, ma anche il fatto che le sue applicazioni sono spesso autonome, il che introduce altre sfide. Il funzionamento autonomo genera la necessità sia di un sistema sicuro, sia di canali di comunicazione sicuri (quando sono disponibili) presso il proprio centro operativo. I sistemi autonomi sono anche spesso alimentati a batterie, e per questo motivo l’efficienza energetica costituisce anch’essa un requisito determinante. Ciò porta a una soluzione strettamente integrata che, oltre ad eseguire algoritmi di elaborazione delle immagini, è anche in grado di comunicare con altri sottosistemi o persino di controllarli. Questo è il caso in particolare dei droni, in cui i vincoli di Dimensioni, Peso e Potenza (SWaP) spesso spingono a combinare il sistema di elaborazione delle immagini con altre funzioni, come ad esempio il controllo dei motori, per creare una soluzione ottimale.

L’implementazione degli algoritmi di elaborazione all’interno del cloud dà luogo a una serie diversa di sfide, ed è all’interno del cloud che sono implementati gli algoritmi ad alta intensità di calcolo, come l’apprendimento automatico approfondito, l’analisi dei dati e l’elaborazione delle immagini. Questi algoritmi inoltre sono soggetti a colli di bottiglia nella memoria, nello storage e nella connettività all’interno del data centre, i quali limitano le prestazioni. Malgrado le applicazioni implementate sul cloud possano non essere in tempo reale, spesso esse richiedono la capacità di inviare flussi di dati elaborati pressoché in tempo reale e senza perdita di informazioni per il cliente. Questo è il caso delle soluzioni di imaging medicale e scientifico, che deve essere in grado di condividere la stessa immagine su più client, cosa che non può essere limitata da colli di bottiglia nel sistema.

Stack Based Solution

Per far fronte a queste sfide, si ricorre alla logica programmabile, nella forma di FPGA e System on Chip Interamente Programmabili. Tuttavia, per sfruttare appieno le funzionalità fornite dalla logica programmabile, abbiamo bisogno non solo del dispositivo, ma anche di un ecosistema che consenta lo sviluppo usando le attuali infrastrutture e le librerie standard presenti sul mercato. Qui è dove lo Stack di Accelerazione Riconfigurabile (RAS) e lo Stack reVISION di Xilinx entrano in gioco, progettati rispettivamente per fornire l’accelerazione al Cloud e alla periferia della rete. Entrambi gli stack si basano ampiamente sul nuovo paradigma di sviluppo della logica programmabile che consiste nel ricorso alla Sintesi ad Alto LIvello (HLS), che consente lo sviluppo in ambienti C/C++/OpenCL e System C. Combinando tale funzionalità HLS con il supporto in libreria alle infrastrutture e alle librerie standard come OpenCV, OpenVX, Caffe, FFmpeg e SQL, è possibile ottenere l’ecosistema necessario.

Sia lo stack RAS, sia lo stack reVISION sono organizzati in tre strati separati, con uno schema molto simile al modello OSI a sette strati, familiare a molti ingegneri. Lo strato più basso dello stack è lo strato di piattaforma ed è comune sia allo stack RAS, sia allo stack reVISION. Questa è la piattaforma hardware vera e propria che contiene l’FPGA o il SoC selezionato, sul quale deve essere implementato il resto dello stack, sebbene la tecnologia sottostante sia sostanzialmente diversa nei due stack. Quando si sviluppa usando reVISION, il dispositivo in questione proviene dalle famiglie di system on chip Interamente Programmabili Zynq®-7000 SoC o Zynq® UltraScale+ MPSoC. Mentre la piattaforma RAS è basata sull’uso di FPGA UltraScale+ Interamente Programmabili, e come tale esiste una differenza sui due ultimi livelli dello stack. 

 

Figura 3 – Stack di Accelerazione Riconfigurabile

 

Quando gli utenti sviluppano la propria applicazione usando lo stack reVISION, il secondo stack è definito come strato dell’algoritmo ed è a questo livello che essi utilizzano il tool di progettazione SDSoC , combinato con le librerie open source comunemente usate come ad esempio OpenCV, per implementare gli algoritmi richiesti. Usando l’SDSoC, essi possono partizionare la funzionalità fra il sistema di elaborazione e la logica programmabile del dispositivo selezionato per ottenere le prestazioni di sistema ottimali. Mentre il livello finale dello Stack reVISION è lo strato applicativo, il quale a sua volta si avvale di infrastrutture standard per creare l’applicazione complessiva richiesta per la soluzione.

 

Figura 4 – Lo stack reVISION

 

Il secondo livello del RAS è lo strato applicativo, e questo usa anch’esso il tool SDAccel, che di nuovo sfrutta la HLS per implementare la propria applicazione, con il supporto a piattaforme di apprendimento automatico come Caffe, l’integrazione con ambienti SQL e il supporto all’elaborazione MPEG usando FFmpeg. Naturalmente, le stesse librerie e le piattaforme OpenCV usate all’interno dello stack reVISION possono essere usate anche su questo livello, se richiesto. Il livello finale consente l’integrazione all’interno del data centre ed è il livello di disposizione, e quest’ultimo si avvale OpenStack per garantire l’integrazione richiesta.

L’implementazione di questi stack all’interno delle proprie soluzioni può apportare numerosi vantaggi, molti dei quali saranno ovvi, accanto a molti che potrebbero non essere ovvi ad una prima analisi.

I vantaggi dello Stack

Il vantaggio più ovvio che giunge con l’implementazione di entrambi gli stack è l’aumento delle prestazioni, che è ottenuto eseguendo gli algoritmi di elaborazione delle immagini all’interno della logica programmabile.

Rispetto alla realizzazione della stessa funzione all’interno di un’architettura basata su processore, il RAS assicura un miglioramento di 40 volte nell’esecuzione degli algoritmi di elaborazione delle immagini e di 11 volte quando si effettua l’apprendimento automatico approfondito. Mentre l’uso dello stack reVISION fornisce un’accelerazione fra 40 e 400 volte, in relazione all’algoritmo e al SoC selezionato.

Questi miglioramenti significativi di prestazioni forniti dal RAS all’interno del cloud consentono non solo di ottenere le stesse prestazioni con requisiti hardware ridotti, ma mantengono anche i costi di gestione e di funzionamento più bassi, essendo inoltre il consumo di potenza ridotto significativamente. Il cloud può anche sfruttare la natura riconfigurabile degli FPGA durante il funzionamento e riconfigurare la logica programmabile per diversi algoritmi, qualora ne sia richiesta l’esecuzione.

L’uso dello stack reVISION sul perimetro della rete non solo fa ottenere lo stesso aumento di prestazioni, ma consente anche di sfruttare le funzionalità di interfacciamento any to any fornite dalla logica programmabile. Ciò è importante in particolare in soluzioni basate su tecnologia Edge, in cui esse si devono interfacciare con numerosi tipi diversi di sensori che usano entrambi gli standard e le relative interfacce.

Gli utenti inoltre traggono vantaggio dal rapporto potenza per watt in assoluto più efficiente, e laddove queste applicazioni sono spesso alimentate a batteria, ciò consente di ottenere una maggiore durata dell’applicazione con le batterie e quindi una maggiore operatività. Essi possono anche sfruttare le funzionalità di gestione dell’alimentazione dei dispositivi system on chip programmabili per scalare il consumo di potenza, in linea con i requisiti delle condizioni operative, ad esempio rilevando che una cuffia intelligente per la realtà aumentata non è più indossata ed entrando in modalità sleep per preservare la durata delle batterie.

Sia il SoC Interamente Programmabile, sia l’FPGA forniscono inoltre funzionalità intrinseche per la sicurezza, come la configurazione sicura e la capacità di monitorare le tensioni e le temperature interne per individuare tentativi di accessi non autorizzati al dispositivo.

Infine, essi devono anche considerare il percorso di aggiornamenti futuri e la necessità di supportare nuovi standard, piattaforme e interfacce non appena esse sono rilasciate. L’uso della logica programmabile assicura una roadmap di prodotto che può facilmente scalare, grazie alla capacità di interfacciamento any to any.

 

Conclusione

Come qui illustrato, l’elaborazione delle immagini è onnipresente, con applicazioni sia alla periferia della rete sia su cloud, che si trovano a dover fronteggiare in gran parte le stesse sfide. Il ricorso ad approcci basati su stack di accelerazione che supportano lo sviluppo di sistemi di elaborazione delle immagini in entrambe le applicazioni, consente allo sviluppatore di sistemi di sfruttare i vantaggi a livello sia di sistema, sia di prestazioni che giungono con l’uso della logica programmabile.

Entrambi gli stack presentati sono inoltre molto flessibili e saranno sviluppati nel tempo per fornire ulteriore supporto a nuovi ambienti e standard non appena essi saranno introdotti.

Per maggiori informazioni visitate: http://www.xilinx.com/products/design-tools/embedded-vision-zone.html

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *

Ricevi un avviso se ci sono nuovi commenti. Oppure iscriviti senza commentare.