Un ambiente di esecuzione condiviso a bordo del veicolo può gestire quali modelli rimangono attivi e quali vengono eseguiti solo quando le condizioni operative lo richiedono
I veicoli commerciali devono affrontare un problema di risorse man mano che le loro capacità di " AI " si ampliano: l'esecuzione continua di ogni modello comporta un carico crescente su risorse di calcolo e memoria limitate, rendendo più difficile l'integrazione, la convalida e il funzionamento delle nuove funzioni. La sfida architettonica consiste nel trovare il modo di supportare una maggiore intelligenza nell'ambito delle risorse disponibili sul veicolo.
Ogni modello aggiuntivo può richiedere risorse di CPU o dell’acceleratore, memoria, attività di integrazione e validazione. Tuttavia, un modello necessario durante un evento diagnostico o un flusso di lavoro di manutenzione potrebbe non avere motivo di essere eseguito durante ogni viaggio. Mantenere attivo quel modello anche quando la sua funzione non è richiesta comporta un consumo inutile di risorse di esecuzione.
Per i produttori, ciò rappresenta una sfida progettuale che va ben oltre la fase iniziale di produzione. I veicoli commerciali hanno cicli di vita molto lunghi e, secondo quanto riportato da FleetOwner, “le flotte non utilizzano mezzi così vecchi da oltre un decennio.» La potenza di calcolo e la memoria installate al momento della produzione rimangono sostanzialmente fisse, mentre le aspettative relative al software e all’ AI e in esecuzione su tali veicoli continuano a crescere. I team di ingegneri devono determinare in che modo i nuovi carichi di lavoro si integrino con le funzioni esistenti e come questi saranno implementati, aggiornati e monitorati all’interno di una flotta.
Per gli operatori e i team di assistenza, gli stessi vincoli si riflettono nei dati. Lo spazio di archiviazione, la larghezza di banda e la connettività limitano la quantità di dati telemetrici che possono essere trasferiti al cloud, e la raccolta di grandi volumi di dati costringe i team a cercare gli eventi e i segnali rilevanti ai fini della diagnosi. Il compromesso è difficile da evitare: inviare tutto al cloud e accollarsi i costi e il rumore, oppure inviare meno dati e rischiare di perdere l’evento chiave.
Entrambi i problemi portano alla stessa soluzione: trasferire l’intelligenza al veicolo e gestirla come infrastruttura condivisa del veicolo piuttosto che come un insieme di modelli separati e sempre attivi. Un runtime comune può gestire un portafoglio di modelli, allocando le risorse di esecuzione in base ai requisiti di ciascuna funzione.
Separare l'implementazione dall'esecuzione
L'idea fondamentale è quella di separare il concetto di "implementato" da quello di "in esecuzione". La disponibilità di un modello sul veicolo e la sua esecuzione sono decisioni distinte. I modelli implementati occupano comunque spazio di archiviazione, ma la loro esecuzione può essere gestita in base alle esigenze operative.
Questa distinzione consente la coesistenza di due categorie di intelligenza periferica. L’intelligenza persistente comprende modelli che devono rimanere attivi per supportare funzioni continue o critiche per la sicurezza. Un esempio di intelligenza persistente è un modello ADAS di rilevamento di oggetti stradali che elabora le immagini delle telecamere durante la guida per identificare veicoli, pedoni e ciclisti al fine di evitare collisioni.
L’intelligenza on-demand comprende modelli che si attivano solo quando il contesto del veicolo o le condizioni operative lo richiedono. Un esempio di intelligenza on-demand potrebbe essere un modello di valutazione dello stato di salute della batteria che si attiva durante una sessione di ricarica o in deposito per valutare il degrado della batteria e segnalare la necessità di manutenzione. Supportare entrambe le funzionalità sullo stesso hardware significa che qualcosa deve decidere cosa eseguire, quando e con quali risorse, senza interferire con le funzioni che non possono essere interrotte.
Un ambiente di esecuzione condiviso a bordo del veicolo è in grado di prendere tali decisioni. Può gestire l’implementazione, l’attivazione, la disattivazione, le versioni dei modelli, l’accesso ai segnali del veicolo, le uscite e il monitoraggio, allocando al contempo CPU, memoria e altre risorse in base alle esigenze di ciascuna funzione.
Tali decisioni devono rispettare i requisiti di ciascuna funzione, comprese la convalida e la disponibilità delle risorse. L'esecuzione su richiesta non elimina il lavoro di integrazione o di convalida, ma offre un modo per gestire i carichi di lavoro che non devono operare contemporaneamente.
Lasciamo che sia il contesto del veicolo a determinare quando i modelli vengono eseguiti
I segnali del veicolo, gli eventi diagnostici, la modalità operativa, i dati geografici, il contesto di servizio e altri output del modello possono fornire input per l'attivazione. Una condizione del veicolo genera un trigger, la piattaforma attiva un modello, il modello esegue il proprio compito e la piattaforma lo disattiva una volta completato il compito. Il modello consuma risorse solo mentre la sua funzione è necessaria.
Poiché un modello attivato compete con le funzioni persistenti per le stesse risorse, per rendere tutto ciò fattibile è necessario avere una visione d’insieme dell’utilizzo della CPU e della RAM, dello spazio di archiviazione, dell’ingombro del modello e dei modelli in esecuzione simultanea. I team di ingegneria e operazioni hanno inoltre bisogno di una visione d’insieme dell’implementazione a livello di flotta: cosa è installato, cosa è in esecuzione e se le risorse disponibili sono in grado di supportare il carico di lavoro richiesto.
Un livello di orchestrazione condiviso è in grado di gestire in modo coerente una vasta gamma di applicazioni, senza richiedere un'architettura separata per ciascuna di esse. Tra queste figurano la diagnostica remota, l'analisi dei log perimetrali, il monitoraggio della configurazione, le modalità di servizio o di prova, la valutazione dei modelli e i flussi di lavoro ingegneristici mirati, ciascuno con esigenze di esecuzione diverse.
Rilevare a livello locale e raccogliere in modo selettivo
La raccolta dei dati relativi ai veicoli illustra quali cambiamenti comporta questa architettura nella pratica. In un flusso di lavoro incentrato sull'analisi nel cloud, i team raccolgono i dati, li caricano, ricercano le anomalie, identificano gli eventi rilevanti, estraggono i segnali significativi e infine diagnosticano il problema.
Un flusso di lavoro basato sull’intelligenza periferica ribalta questa sequenza: rileva un’anomalia a livello locale, avvia una raccolta mirata, carica il contesto pertinente e formula una diagnosi. Le decisioni su quali dati siano rilevanti possono ora essere prese direttamente a bordo del veicolo.
Sonatus’s Fastlane™ Edge è un esempio concreto. Smart Triggers collega un modello di AI in esecuzione nell’ambiente di runtime edge di bordo con Fastlane™ Collector. Un modello leggero di rilevamento delle anomalie o una funzione matematica a livello di edge può monitorare le soglie di comportamento del motore. Quando rileva una condizione anomala, attiva una Fastlane Collector politica che acquisisce i segnali rilevanti del motore relativi all’evento. La raccolta mirata dei dati avviene solo quando viene rilevata un’anomalia del motore.
Questo approccio può generare set di dati diagnostici più pertinenti e ridurre il trasferimento superfluo di dati dal veicolo al cloud e la ricerca manuale nei registri. Il fatto che ciò comporti un miglioramento nell’utilizzo della connettività, dello spazio di archiviazione o dei tempi di indagine dipende dalla qualità del rilevamento e dalla politica di raccolta dei dati.
In definitiva, l’implicazione architettonica più ampia è che l’implementazione, l’esecuzione, le risorse e la gestione del ciclo di vita devono essere considerate nel loro insieme. Un veicolo può supportare un portafoglio sempre più ampio di funzionalità di “ AI ” senza che sia necessario che ogni modello installato funzioni in modo continuo. L’ AI e edge diventa scalabile quando l’intelligenza diventa una funzionalità gestita del veicolo.