Demistificare il machine learning all'edge attraverso casi d'uso reali

Ripubblicato da Platone

Seguaci: 0

bordo è un termine che si riferisce a una posizione, lontana dal cloud o da un grande data center, in cui si dispone di un dispositivo informatico (dispositivo edge) in grado di eseguire applicazioni (edge). L'edge computing è l'atto di eseguire carichi di lavoro su questi dispositivi perimetrali. Machine learning at the edge (ML@Edge) è un concetto che offre la capacità di eseguire modelli ML localmente sui dispositivi edge. Questi modelli ML possono quindi essere richiamati dall'applicazione perimetrale. ML@Edge è importante per molti scenari in cui i dati grezzi vengono raccolti da origini lontane dal cloud. Questi scenari possono anche avere requisiti o restrizioni specifici:

Previsioni in tempo reale a bassa latenza
Connettività al cloud scarsa o inesistente
Restrizioni legali che non consentono l'invio di dati a servizi esterni
Set di dati di grandi dimensioni che devono essere preelaborati localmente prima di inviare le risposte al cloud

Di seguito sono riportati alcuni dei molti casi d'uso che possono trarre vantaggio dai modelli ML eseguiti vicino all'apparecchiatura che genera i dati utilizzati per le previsioni:

Sicurezza e sicurezza – Un'area riservata in cui operano macchine pesanti in un porto automatizzato è monitorata da una telecamera. Se una persona entra in quest'area per errore, viene attivato un meccanismo di sicurezza per fermare le macchine e proteggere l'uomo.
Manutenzione predittiva – I sensori di vibrazione e audio raccolgono dati da un cambio di una turbina eolica. Un modello di rilevamento delle anomalie elabora i dati del sensore e identifica eventuali anomalie con l'apparecchiatura. Se viene rilevata un'anomalia, il dispositivo periferico può avviare una misura di emergenza in tempo reale per evitare danni alle apparecchiature, come inserire le interruzioni o scollegare il generatore dalla rete.
Rilevamento dei difetti nelle linee di produzione – Una fotocamera acquisisce immagini di prodotti su un nastro trasportatore ed elabora i fotogrammi con un modello di classificazione delle immagini. Se viene rilevato un difetto, il prodotto può essere eliminato automaticamente senza intervento manuale.

Sebbene ML@Edge possa affrontare molti casi d'uso, ci sono complesse sfide architettoniche che devono essere risolte per avere un design sicuro, robusto e affidabile. In questo post, imparerai alcuni dettagli su ML@Edge, argomenti correlati e come utilizzare i servizi AWS per superare queste sfide e implementare una soluzione completa per il tuo ML al carico di lavoro perimetrale.

Panoramica di ML@Edge

Esiste una confusione comune quando si parla di ML@Edge e Internet of Things (IoT), quindi è importante chiarire in che modo ML@Edge è diverso dall'IoT e come entrambi potrebbero unirsi per fornire una soluzione efficace in determinati casi.

Una soluzione edge che utilizza ML@Edge ha due componenti principali: un'applicazione edge e un modello ML (richiamato dall'applicazione) in esecuzione sul dispositivo edge. ML@Edge riguarda il controllo del ciclo di vita di uno o più modelli ML distribuiti su una flotta di dispositivi edge. Il ciclo di vita del modello ML può iniziare sul lato cloud (on Amazon Sage Maker, ad esempio) ma normalmente termina con una distribuzione autonoma del modello sul dispositivo perimetrale. Ogni scenario richiede diversi cicli di vita del modello ML che possono essere composti da molte fasi, come la raccolta dei dati; preparazione dei dati; creazione, compilazione e distribuzione di modelli sul dispositivo perimetrale; caricamento e funzionamento del modello; e ripetere il ciclo di vita.

Il meccanismo ML@Edge non è responsabile del ciclo di vita dell'applicazione. A tal fine dovrebbe essere adottato un approccio diverso. Il disaccoppiamento del ciclo di vita del modello ML e del ciclo di vita dell'applicazione ti dà la libertà e la flessibilità per continuare a evolverli a ritmi diversi. Immagina un'applicazione mobile che incorpora un modello ML come risorsa come un'immagine o un file XML. In questo caso, ogni volta che si addestra un nuovo modello e si desidera distribuirlo ai telefoni cellulari, è necessario ridistribuire l'intera applicazione. Ciò consuma tempo e denaro e può introdurre bug nella tua applicazione. Disaccoppiando il ciclo di vita del modello ML, pubblichi l'app mobile una sola volta e distribuisci tutte le versioni del modello ML di cui hai bisogno.

Ma come si correla IoT a ML@Edge? L'IoT si riferisce a oggetti fisici incorporati con tecnologie come sensori, capacità di elaborazione e software. Questi oggetti sono collegati ad altri dispositivi e sistemi su Internet o altre reti di comunicazione, al fine di scambiare dati. La figura seguente illustra questa architettura. Il concetto è stato inizialmente creato pensando a dispositivi semplici che raccolgono semplicemente i dati dall'edge, eseguono una semplice elaborazione locale e inviano il risultato a un'unità di elaborazione più potente che esegue processi di analisi che aiutano le persone e le aziende nel processo decisionale. La soluzione IoT è responsabile del controllo del ciclo di vita dell'applicazione perimetrale. Per ulteriori informazioni sull'IoT, fare riferimento a Internet delle cose.

Se disponi già di un'applicazione IoT, puoi aggiungere funzionalità ML@Edge per rendere il prodotto più efficiente, come mostrato nella figura seguente. Tieni presente che ML@Edge non dipende dall'IoT, ma puoi combinarli per creare una soluzione più potente. Quando lo fai, migliori il potenziale del tuo semplice dispositivo per generare informazioni in tempo reale per la tua azienda più velocemente del semplice invio di dati al cloud per l'elaborazione successiva.

Se stai creando una nuova soluzione edge da zero con funzionalità ML@Edge, è importante progettare un'architettura flessibile che supporti sia l'applicazione che i cicli di vita del modello ML. Forniamo alcune architetture di riferimento per le applicazioni edge con ML@Edge più avanti in questo post. Ma prima, approfondiamo l'edge computing e impariamo come scegliere il dispositivo edge corretto per la tua soluzione, in base alle restrizioni dell'ambiente.

Edge computing

A seconda della distanza del dispositivo dal cloud o da un grande data center (base), è necessario considerare tre caratteristiche principali dei dispositivi perimetrali per massimizzare le prestazioni e la longevità del sistema: capacità di elaborazione e storage, connettività e consumo energetico. Il diagramma seguente mostra tre gruppi di dispositivi perimetrali che combinano specifiche diverse di queste caratteristiche, a seconda della distanza dalla base.

I gruppi sono i seguenti:

MEC (Edge Computing multiaccesso) – I MEC o i piccoli data center, caratterizzati da latenza bassa o ultrabassa e larghezza di banda elevata, sono ambienti comuni in cui ML@Edge può apportare vantaggi senza grandi restrizioni rispetto ai carichi di lavoro cloud. Le antenne e i server 5G in fabbriche, magazzini, laboratori e così via con vincoli energetici minimi e con una buona connettività Internet offrono diversi modi per eseguire modelli ML su GPU e CPU, macchine virtuali, container e server bare-metal.
Bordo vicino – Questo è quando la mobilità o l'aggregazione dei dati sono requisiti e i dispositivi hanno alcuni vincoli per quanto riguarda il consumo energetico e la potenza di elaborazione, ma hanno ancora una connettività affidabile, sebbene con una latenza maggiore, con un throughput limitato e più costosi rispetto a quelli "vicini all'edge". In questo gruppo sono incluse applicazioni mobili, schede specifiche per accelerare i modelli ML o semplici dispositivi con capacità di eseguire modelli ML coperti da reti wireless.
Bordo lontano – In questo scenario estremo, i dispositivi perimetrali hanno un forte consumo di energia o vincoli di connettività. Di conseguenza, anche la potenza di elaborazione è limitata in molti scenari estremi. Agricoltura, estrazione mineraria, sorveglianza e sicurezza e trasporto marittimo sono alcune aree in cui i dispositivi estremi svolgono un ruolo importante. Le schede semplici, normalmente senza GPU o altri acceleratori di intelligenza artificiale, sono comuni. Sono progettati per caricare ed eseguire semplici modelli ML, salvare le previsioni in un database locale e rimanere in sospeso fino al successivo ciclo di previsione. I dispositivi che devono elaborare i dati in tempo reale possono disporre di grandi archivi locali per evitare la perdita di dati.

Le sfide

È comune avere scenari ML@Edge in cui hai centinaia o migliaia (forse anche milioni) di dispositivi che eseguono gli stessi modelli e applicazioni edge. Quando si ridimensiona il sistema, è importante disporre di una soluzione solida in grado di gestire il numero di dispositivi che è necessario supportare. Questo è un compito complesso e per questi scenari è necessario porre molte domande:

Come faccio a utilizzare i modelli ML su una flotta di dispositivi periferici?
Come faccio a creare, ottimizzare e distribuire modelli ML su più dispositivi perimetrali?
Come posso proteggere il mio modello mentre lo distribuisco e lo eseguo all'edge?
Come posso monitorare le prestazioni del mio modello e riqualificarlo, se necessario?
Come posso eliminare la necessità di installare un framework di grandi dimensioni come TensorFlow o PyTorch sul mio dispositivo limitato?
Come faccio a esporre uno o più modelli con la mia applicazione perimetrale come semplice API?
Come faccio a creare un nuovo set di dati con i payload e le previsioni acquisiti dai dispositivi perimetrali?
Come faccio a eseguire tutte queste attività automaticamente (MLOps più ML@Edge)?

Nella sezione successiva, forniremo risposte a tutte queste domande attraverso casi d'uso di esempio e architetture di riferimento. Discutiamo anche di quali servizi AWS puoi combinare per creare soluzioni complete per ciascuno degli scenari esplorati. Tuttavia, se vuoi iniziare con un flusso molto semplice che descrive come utilizzare alcuni dei servizi forniti da AWS per creare la tua soluzione ML@Edge, questo è un esempio:

Con SageMaker, puoi facilmente preparare un set di dati e creare i modelli ML che vengono distribuiti ai dispositivi perimetrali. Insieme a Amazon Sage Maker Neo, puoi compilare e ottimizzare il modello che hai addestrato per il dispositivo perimetrale specifico che hai scelto. Dopo aver compilato il modello, è necessario solo un runtime leggero per eseguirlo (fornito dal servizio). Gestore perimetrale di Amazon SageMaker è responsabile della gestione del ciclo di vita di tutti i modelli ML distribuiti sul tuo parco dispositivi perimetrali. Edge Manager può gestire flotte fino a milioni di dispositivi. Un agente, installato su ciascuno dei dispositivi perimetrali, espone i modelli ML distribuiti come API all'applicazione. L'agente è anche responsabile della raccolta di metriche, carichi utili e previsioni che è possibile utilizzare per il monitoraggio o la creazione di un nuovo set di dati per riqualificare il modello, se necessario. Infine, con Pipeline di Amazon SageMaker, puoi creare una pipeline automatizzata con tutti i passaggi necessari per creare, ottimizzare e distribuire modelli ML al tuo parco dispositivi. Questa pipeline automatizzata può quindi essere attivata da semplici eventi definiti dall'utente, senza l'intervento umano.

Caso d'uso 1

Diciamo che un produttore di aeroplani vuole rilevare e tracciare parti e strumenti nell'hangar di produzione. Per migliorare la produttività, tutti i componenti necessari e gli strumenti corretti devono essere disponibili per gli ingegneri in ogni fase della produzione. Vogliamo essere in grado di rispondere a domande del tipo: Dov'è la parte A? o Dov'è lo strumento B? Abbiamo più telecamere IP già installate e collegate a una rete locale. Le telecamere coprono l'intero hangar e possono trasmettere video HD in tempo reale attraverso la rete.

Panorama AWS si adatta bene in questo caso. AWS Panorama fornisce un'appliance ML e un servizio gestito che ti consente di aggiungere computer vision (CV) al tuo parco esistente di telecamere IP e automatizzare. AWS Panorama ti dà la possibilità di aggiungere CV alle tue telecamere IP (Internet Protocol) esistenti e automatizzare le attività che tradizionalmente richiedono l'ispezione e il monitoraggio umano.

Nella seguente architettura di riferimento, mostriamo i componenti principali dell'applicazione in esecuzione su un AWS Panorama Appliance. Panorama Application SDK semplifica l'acquisizione di video dai flussi di telecamere, l'esecuzione di inferenze con una pipeline di più modelli ML ed l'elaborazione dei risultati utilizzando il codice Python in esecuzione all'interno di un container. Puoi eseguire modelli da qualsiasi libreria ML popolare come TensorFlow, PyTorch o TensorRT. I risultati del modello possono essere integrati con i sistemi aziendali sulla rete locale, consentendo di rispondere agli eventi in tempo reale.

La soluzione consiste nei seguenti passaggi:

Connetti e configura un dispositivo AWS Panorama alla stessa rete locale.
Addestra un modello ML (rilevamento di oggetti) per identificare parti e strumenti in ogni frame.
Crea un'applicazione AWS Panorama che ottenga le previsioni dal modello ML, applichi un meccanismo di tracciamento a ciascun oggetto e invii i risultati a un database in tempo reale.
Gli operatori possono inviare query al database per individuare le parti e gli strumenti.

Caso d'uso 2

Per il nostro prossimo caso d'uso, immagina di creare una dashcam per veicoli in grado di supportare il conducente in molte situazioni, come evitare i pedoni, sulla base di un Scheda CV25 di Ambaralla. L'hosting di modelli ML su un dispositivo con risorse di sistema limitate può essere difficile. In questo caso, supponiamo di disporre già di un meccanismo di distribuzione OTA (over-the-air) consolidato per distribuire i componenti dell'applicazione necessari sul dispositivo perimetrale. Tuttavia, trarremmo comunque vantaggio dalla possibilità di eseguire la distribuzione OTA del modello stesso, isolando così il ciclo di vita dell'applicazione e il ciclo di vita del modello.

Gestore perimetrale di Amazon SageMaker ed Amazon Sage Maker Neo si adatta bene a questo caso d'uso.

Edge Manager consente agli sviluppatori edge ML di utilizzare facilmente gli stessi strumenti familiari nel cloud o sui dispositivi edge. Riduce il tempo e lo sforzo necessari per portare i modelli in produzione, consentendoti al contempo di monitorare e migliorare continuamente la qualità dei modelli in tutto il parco dispositivi. SageMaker Edge include un meccanismo di distribuzione OTA che consente di distribuire i modelli sulla flotta indipendentemente dall'applicazione o dal firmware del dispositivo. Il Agente Edge Manager consente di eseguire più modelli sullo stesso dispositivo. L'agente raccoglie i dati di previsione in base alla logica che controlli, ad esempio gli intervalli, e li carica nel cloud in modo che tu possa riqualificare periodicamente i tuoi modelli nel tempo. SageMaker Edge firma crittograficamente i tuoi modelli in modo da poter verificare che non siano stati manomessi mentre si sposta dal cloud al dispositivo edge.

Neo è un compilatore come servizio e si adatta particolarmente bene in questo caso d'uso. Neo ottimizza automaticamente i modelli ML per l'inferenza su istanze cloud e dispositivi edge per funzionare più velocemente senza perdita di precisione. Inizi con un modello ML creato con uno di framework supportati e addestrato in SageMaker o altrove. Quindi scegli la tua piattaforma hardware di destinazione, (fare riferimento all'elenco di dispositivi supportati). Con un solo clic, Neo ottimizza il modello addestrato e lo compila in un pacchetto che può essere eseguito utilizzando il runtime leggero di SageMaker Edge. Il compilatore usa un modello ML per applicare le ottimizzazioni delle prestazioni che estraggono le migliori prestazioni disponibili per il tuo modello sull'istanza cloud o sul dispositivo perimetrale. Quindi distribuisci il modello come endpoint SageMaker o su dispositivi perimetrali supportati e inizi a fare previsioni.

Il diagramma seguente illustra questa architettura.

Il flusso di lavoro della soluzione consiste nei seguenti passaggi:

Lo sviluppatore costruisce, addestra, convalida e crea l'artefatto del modello finale che deve essere distribuito sulla dashcam.
Richiama Neo per compilare il modello addestrato.
L'agente SageMaker Edge è installato e configurato sul dispositivo Edge, in questo caso la dashcam.
Crea un pacchetto di distribuzione con un modello firmato e il runtime utilizzato dall'agente SageMaker Edge per caricare e richiamare il modello ottimizzato.
Distribuire il pacchetto utilizzando il meccanismo di distribuzione OTA esistente.
L'applicazione perimetrale interagisce con l'agente SageMaker Edge per eseguire l'inferenza.
L'agente può essere configurato (se necessario) per inviare dati di input campione in tempo reale dall'applicazione per scopi di monitoraggio e perfezionamento del modello.

Caso d'uso 3

Supponiamo che il tuo cliente stia sviluppando un'applicazione che rileva le anomalie nei meccanismi di una turbina eolica (come il cambio, il generatore o il rotore). L'obiettivo è ridurre al minimo i danni alle apparecchiature eseguendo al volo le procedure di protezione locale. Queste turbine sono molto costose e si trovano in luoghi non facilmente accessibili. Ogni turbina può essere dotata di un dispositivo NVIDIA Jetson per monitorare i dati dei sensori dalla turbina. Abbiamo quindi bisogno di una soluzione per acquisire i dati e utilizzare un algoritmo ML per rilevare le anomalie. Abbiamo anche bisogno di un meccanismo OTA per mantenere aggiornati i modelli software e ML sul dispositivo.

AWS IoT Greengrass V2 insieme a Edge Manager si adattano bene a questo caso d'uso. AWS IoT Greengrass è un servizio cloud e runtime perimetrale IoT open source che ti aiuta a creare, distribuire e gestire applicazioni IoT sui tuoi dispositivi. Puoi utilizzare AWS IoT Greengrass per creare applicazioni perimetrali utilizzando moduli software predefiniti, chiamati componenti, che può connettere i tuoi dispositivi perimetrali a servizi AWS o servizi di terze parti. Questa capacità di AWS IoT Greengrass semplifica la distribuzione delle risorse sui dispositivi, incluso un agente SageMaker Edge. AWS IoT Greengrass è responsabile della gestione del ciclo di vita dell'applicazione, mentre Edge Manager disaccoppia il ciclo di vita del modello ML. Questo ti dà la flessibilità di continuare a far evolvere l'intera soluzione distribuendo le nuove versioni dell'applicazione perimetrale e dei modelli ML in modo indipendente. Il diagramma seguente illustra questa architettura.

La soluzione consiste nei seguenti passaggi:

Lo sviluppatore costruisce, addestra, convalida e crea il manufatto del modello finale che deve essere distribuito nella turbina eolica.
Richiama Neo per compilare il modello addestrato.
Crea un componente del modello utilizzando Edge Manager con l'integrazione di AWS IoT Greengrass V2.
Configura AWS IoT Greengrass V2.
Crea un componente di inferenza utilizzando AWS IoT Greengrass V2.
L'applicazione perimetrale interagisce con l'agente SageMaker Edge per eseguire l'inferenza.
L'agente può essere configurato (se necessario) per inviare dati di input campione in tempo reale dall'applicazione per scopi di monitoraggio e perfezionamento del modello.

Caso d'uso 4

Per il nostro caso d'uso finale, diamo un'occhiata a una nave che trasporta container, in cui ogni container ha un paio di sensori e trasmette un segnale all'infrastruttura di elaborazione e archiviazione distribuita localmente. La sfida è che vogliamo conoscere il contenuto di ogni container e le condizioni delle merci in base a temperatura, umidità e gas all'interno di ogni container. Vogliamo anche tracciare tutte le merci in ciascuno dei container. Non c'è connettività Internet durante il viaggio e il viaggio può richiedere mesi. I modelli ML in esecuzione su questa infrastruttura dovrebbero preelaborare i dati e generare informazioni per rispondere a tutte le nostre domande. I dati generati devono essere conservati localmente per mesi. L'applicazione perimetrale archivia tutte le inferenze in un database locale e quindi sincronizza i risultati con il cloud quando la nave si avvicina al porto.

Cono di neve AWS ed Palla di neve AWS dal Famiglia AWS Snow potrebbe adattarsi molto bene in questo caso d'uso.

AWS Snowcone è un dispositivo per la migrazione dei dati e l'edge computing piccolo, robusto e sicuro. Snowcone è progettato secondo lo standard OSHA per un dispositivo sollevabile da una sola persona. Snowcone ti consente di eseguire carichi di lavoro edge utilizzando Cloud di calcolo elastico di Amazon (Amazon EC2) e archiviazione locale in ambienti difficili e disconnessi come piattaforme petrolifere, veicoli di ricerca e soccorso, siti militari o stabilimenti, nonché uffici remoti, ospedali e cinema.

Snowball aggiunge più capacità di elaborazione rispetto a Snowcone e quindi può essere perfetto per le applicazioni più impegnative. La funzione Compute Optimized fornisce una GPU NVIDIA Tesla V100 opzionale insieme a istanze EC2 per accelerare le prestazioni di un'applicazione in ambienti disconnessi. Con l'opzione GPU, puoi eseguire applicazioni come ML avanzato e analisi video full motion in ambienti con connettività scarsa o assente.

Oltre all'istanza EC2, hai la libertà di creare e distribuire qualsiasi tipo di soluzione perimetrale. Ad esempio: puoi usare AmazonECS o un altro gestore di contenitori per distribuire l'applicazione perimetrale, l'agente Edge Manager e il modello ML come contenitori individuali. Questa architettura sarebbe simile al caso d'uso 2 (tranne per il fatto che funzionerà offline per la maggior parte del tempo), con l'aggiunta di uno strumento di gestione dei contenitori.

Il diagramma seguente illustra questa architettura della soluzione.

Per implementare questa soluzione, è sufficiente ordinare il tuo dispositivo Snow da Console di gestione AWS e lancia le tue risorse.

Conclusione

In questo post, abbiamo discusso i diversi aspetti di edge con cui potresti scegliere di lavorare in base al tuo caso d'uso. Abbiamo anche discusso alcuni dei concetti chiave su ML@Edge e come disaccoppiare il ciclo di vita dell'applicazione e il ciclo di vita del modello ML ti dà la libertà di evolverli senza alcuna dipendenza l'uno dall'altro. Abbiamo sottolineato come la scelta del dispositivo perimetrale giusto per il tuo carico di lavoro e porre le domande giuste durante il processo di soluzione può aiutarti a lavorare a ritroso e restringere i servizi AWS giusti. Abbiamo anche presentato diversi casi d'uso insieme ad architetture di riferimento per ispirarti a creare le tue soluzioni che funzioneranno per il tuo carico di lavoro.

Informazioni sugli autori

Dinesh Kumar Subramani è un Senior Solutions Architect con il team UKIR SMB, con sede a Edimburgo, in Scozia. È specializzato in intelligenza artificiale e machine learning. A Dinesh piace lavorare con i clienti di tutti i settori per aiutarli a risolvere i loro problemi con i servizi AWS. Al di fuori del lavoro, ama passare il tempo con la sua famiglia, giocare a scacchi e ascoltare musica di tutti i generi.

Samir Araújo è un AI / ML Solutions Architect presso AWS. Aiuta i clienti a creare soluzioni AI / ML che risolvono le loro sfide aziendali utilizzando AWS. Ha lavorato a diversi progetti AI / ML relativi a visione artificiale, elaborazione del linguaggio naturale, previsioni, ML at the edge e altro ancora. Gli piace giocare con i progetti hardware e di automazione nel tempo libero e ha un interesse particolare per la robotica.