Il ruolo del cloud nei veicoli di oggi (Parte 2)

Panoramica

JOHN: Oggi, in “ The Garage ”, vi presentiamo la seconda parte della nostra serie speciale in due puntate dedicata al cloud computing nel settore automobilistico, con il nostro ospite d’eccezione Stefano Marzani di AWS. Nella prima parte della nostra conversazione abbiamo parlato degli aspetti relativi ai dati e all’elaborazione nel cloud computing. Nella puntata di oggi proseguiamo la conversazione e parliamo di prototipazione, analisi dei dati, “ AI ” e delle applicazioni ADAS e di guida autonoma del cloud. Continuiamo la nostra conversazione con Stefano Marzani di AWS. Si parte!

Argomento 3: Prototipazione nel cloud e “parità ambientale”

JOHN: In effetti, questo è un passaggio perfetto al nostro terzo argomento, ovvero la prototipazione. Come ho accennato, recentemente abbiamo parlato con Robert Day, e Arm sta assistendo all’adozione dell’architettura Arm in un’ampia gamma di sottosistemi dell’auto. E, sapete, sono orgoglioso di aver lavorato in Arm per 14 anni. Quindi è una questione che mi sta particolarmente a cuore. Ma Robert ne ha parlato a lungo. Ma penso che ciò significhi anche – e credo che questo sia uno dei punti che volevi sottolineare – che la presenza di Graviton nel cloud, con istanze basate su Arm sia nel cloud che nelle auto, sblocchi alcune potenzialità davvero interessanti per la prototipazione.

STEFANO: Assolutamente sì. La chiamiamo "parità ambientale", giusto? Abbiamo iniziato a usare questo termine alla Dev Summit Conference del 2021, in un workshop che abbiamo presentato all’Arm Dev Summit Conference e che ha avuto una diffusione e una visibilità piuttosto importanti. Dato che era la prima volta che presentavamo questo concetto: perché non possiamo usare le architetture Arm nel cloud per eseguire lo stesso software che gira, per così dire, sulle auto con la stessa architettura Arm, giusto? Stessa architettura Arm, non gli stessi processori: non ne abbiamo idea, né abbiamo intenzione di mettere il Graviton in un’auto, giusto? Sono proprio le centraline elettroniche (ECU) delle auto a provenire da una varietà di fornitori come Qualcomm, Nvidia, NXP, tutte basate su core Arm. E, ancora una volta, il core Arm è esattamente lo stesso che abbiamo nel Graviton. Giusto? Per quanto riguarda Arm 64, ovviamente non si tratta della stessa CPU, perché il nostro Graviton si basa sull’architettura Neoverse, mentre nelle auto si usa spesso Cortex, ma la maggior parte del set di istruzioni è la stessa.

Esecuzione su Arm nel cloud e a bordo del veicolo

STEFANO: È proprio questo il motivo per cui riusciamo a caricarli, e una volta avuta questa idea l’abbiamo messa in pratica. Quindi ora disponiamo di una vastissima gamma di sistemi operativi embedded che tradizionalmente funzionavano solo in scenari emulati o su hardware fisico, giusto, e che ora girano in modo nativo nel cloud AWS su Graviton. Sistemi come QNX, VxWorks, Yocto Linux, AGL. E per gli sviluppatori embedded è un nuovo modo di lavorare; stiamo riscontrando una risposta incredibile, sai, quasi una sorpresa, se vuoi, del tipo: «No, aspetta, basta avviare questo processo nel cloud e mi ritrovo davanti un prompt di QNX, proprio come se stessi usando una sorta di centralina elettronica (ECU)». Sì, è esattamente ciò che intendiamo per “parità ambientale”. Puoi iniziare il tuo lavoro da lì. L’hardware serve comunque, ma non per avviare lo sviluppo.

Inizia a sviluppare software nel cloud

STEFANO: Questo rappresenta attualmente un enorme collo di bottiglia per il settore ed è un aspetto importante dal punto di vista della prototipazione, giusto? Si può ricorrere a soluzioni innovative di basso livello se si ha sempre bisogno che gli sviluppatori, e in particolare quelli più qualificati, dispongano di hardware su cui lavorare, giusto? Perché non c'è hardware in grado di soddisfare la domanda.

JOHN: Certo. E dal punto di vista dei test, i test di regressione. Ne abbiamo parlato in una puntata precedente: abbiamo iniziato a eseguire i nostri test anche in ambiente cloud. Quindi, invece di avere rack su rack di sistemi che si riavviano da remoto, è possibile utilizzare istanze virtuali ed EC2. Stiamo facendo anche questo. Ne vediamo i vantaggi e lo stiamo sfruttando molto.

Difficoltà di convalida nel settore automobilistico

STEFANO: Sì. Sì, assolutamente. È, è un vantaggio enorme, ancora una volta, per gli sviluppatori e per la fase di validazione, giusto? Pensateci. Ancora oggi, l’auto è letteralmente un sistema che non viene, come sapete, testato in modo approfondito. Questo per ragioni storiche. Come dicevamo all’inizio della puntata, l’auto sta subendo una profonda trasformazione: da un sistema composto da oltre 150 centraline (ECU) in un moderno veicolo con motore a combustione interna a un numero molto inferiore, diciamo 30 o 40, con computer consolidati. Ci saranno ancora le unità periferiche basate su microcontrollori per il rilevamento o l’attuazione. Ma l’elaborazione principale sarà svolta da architetture consolidate con molteplici core Arm al loro interno, 8, 12, 16, 40, giusto, in architetture super consolidate. E questo è estremamente importante, vero? È una tendenza estremamente importante.

Dare più strumenti agli sviluppatori grazie al cloud

STEFANO: E non ci si può aspettare che gli sviluppatori abbiano queste unità sulla propria scrivania per lavorare; bisogna offrire loro un ambiente, un ambiente cloud-native, per i motivi che abbiamo già visto. Perché lì abbiamo i dati. Lì abbiamo le opzioni di elaborazione. Lì abbiamo Graviton. Quindi quello è l’ambiente naturale in cui gli sviluppatori possono trovare i propri strumenti, lavorare, eseguire il deploy sull’hardware e continuare a testare sull’hardware, ma non viceversa.

Il software per veicoli triplicherà nei prossimi cinque anni

STEFANO: Perché se si parte dall’hardware, si soffoca l’innovazione. Sai, secondo alcuni analisti, nel settore SDV si prevede che la quantità di codice triplichi nei prossimi cinque anni, passando da 100 milioni a 300 milioni. Come si può arrivare a questo risultato se ci si aspetta ancora che gli sviluppatori dispongano di hardware per lavorare e produrre codice automobilistico?

JOHN: Wow, è una cifra incredibile. Non avevo mai sentito quella statistica: triplicherà nei prossimi tre anni?

STEFANO: Cinque anni.

JOHN: È incredibile. Sai, stavo pensando che mi sembra ci sia anche un circolo virtuoso, perché in una puntata precedente abbiamo parlato del consolidamento dei carichi di lavoro e tu ne hai accennato proprio un minuto fa. E penso che, come abbiamo già detto, sia importante la virtualizzazione e la possibilità di far girare queste applicazioni in parallelo senza che si interferiscano a vicenda. Mi sembra che ci sia una forte sinergia tra questo approccio di prototipazione nel cloud e la virtualizzazione, perché puoi prendere quegli stessi carichi di lavoro che hai testato lì e ora possono coesistere fianco a fianco. Ed è molto più simile, come hai detto tu, all’approccio della “parità ambientale”, di cui ti piace parlare.

STEFANO: Sì, assolutamente. Assolutamente. E poi, se ci pensi bene, quando inizi ad avere 12, 16 core, non li usi tutti per un unico sistema operativo; ciò significa che devi partizionare questi core ed eseguire più sistemi operativi. Ma questo è esattamente ciò che facciamo nel cloud: abbiamo un hypervisor che gestisce, su 64 core di un processore Graviton, più sistemi operativi, giusto? È esattamente la stessa cosa. È diverso, ovviamente, in termini di qualificazione elettronica e per molte, molte altre cose. Ma dal punto di vista dell’ingegneria del software, possiamo operare in modo tale che i due ambienti siano molto simili.

JOHN: Quindi, nella fase di prototipazione e collaudo, si sta praticamente verificando come funzionerà nell'implementazione finale: è davvero interessante. È... è qualcosa che trovo davvero affascinante, affascinante dal punto di vista tecnico, credo, e anche uno strumento molto potente nello sviluppo.

“Shift left” per accelerare il ciclo di progettazione

JOHN: E, sai, stiamo assistendo – e ne abbiamo parlato anche anni fa – al concetto di “shift left”, ovvero come utilizzare la prototipazione virtuale, il Cloud e così via per accelerare il ciclo di progettazione. E stiamo vedendo – ne abbiamo parlato anche in una delle nostre recenti puntate – che c’è una pressione sul ciclo di progettazione affinché si progetti più velocemente, e penso che il panorama competitivo per gli OEM e i fornitori di primo livello stia diventando sempre più difficile. E se questi strumenti riescono a comprimere il ciclo di progettazione, possono rendere le aziende più competitive, far risparmiare sui costi e, in realtà, credo, gestire l’enorme complessità; come hai detto tu, con l’aumento del numero di righe di codice, bisogna riuscire a tenerne il controllo. E penso che per far funzionare tutto ciò sia necessario applicare la strategia del “divide et impera”. Altrimenti, se lo si considera come un sistema gigante e monolitico, è impossibile da verificare.

40-50 miliardi di dollari persi a causa dei richiami nel settore automobilistico

STEFANO: Assolutamente sì. E ci sono anche altri vantaggi. Quindi “shift left”, senza dubbio. Aumento della qualità del codice, perché è possibile estendere maggiormente i test. Questo è davvero molto, molto importante. Pensateci nel settore automobilistico. Ancora oggi si registrano perdite pari a 40-50 miliardi di dollari ogni anno a causa dei richiami. Il 70% è dovuto a difetti del software. Il 70% dei casi registrati. Pensateci bene. È una qualità scadente. Possiamo dirlo?

JOHN: Sì.

STEFANO: Test inadeguati.

JOHN: Assolutamente sì.

STEFANO: Non spostare a sinistra.

JOHN: Sì.

STEFANO: Giusto? Quindi, spostandosi a sinistra, si riducono i costi e si aumenta la qualità. Ma vorrei considerare anche gli utenti finali. Perché quello che stiamo vedendo è che, se non si inviano queste ECU in giro per lo sviluppo, è possibile favorire la collaborazione nel cloud. E questo è estremamente importante. Anzi, è uno degli aspetti sorprendenti dell’SDV. Abbiamo parlato dei servizi ADAS/AV, basati sulla telematica, sui servizi telematici.

Sviluppo dell'interfaccia uomo-macchina (HMI) per veicoli tramite il cloud

STEFANO: Stiamo assistendo a un enorme aumento dello sviluppo delle HMI nel cloud, dell’interazione uomo-macchina, delle interfacce utente e dell’esperienza utente. E questo, secondo me, è fantastico. E si capisce subito il perché. Lo si capisce perché, per la prima volta, si dispone di un’ECU virtuale nel cloud che presenta un’interfaccia utente nel browser. Posso mostrarla immediatamente a tutta la mia rete di collaboratori in tutto il mondo, poiché il cloud ha una presenza globale. Così posso chiedere a un collega in Giappone, o a un collega in Sudafrica: «Cosa ne pensi della mia nuova interfaccia utente, in base alle preferenze locali del tuo Paese? Oppure, puoi adattarla? Oppure puoi lavorarci sopra?».

JOHN: E la localizzazione, la lingua.

STEFANO: Si tratta letteralmente di una rivoluzione nel modo di realizzare i sistemi HMI, se si pensa al fatto di non dover più ricorrere a tutto quell’hardware sparpagliato ovunque. Si tratta invece di un approccio allo sviluppo HMI “cloud-native” e “cloud-first”, come diciamo noi. E abbiamo già un cliente che sta cercando di adottarlo. Inoltre, di recente, in collaborazione con BMW, abbiamo presentato una relazione molto interessante sulle loro pratiche di sviluppo HMI nel cloud in occasione dell’ultimo AWS Summit a Berlino e, naturalmente, possiamo fornire il riferimento. È una bella dimostrazione. Ma non si tratta solo di parlare sempre di BMW: ad esempio, posso citare la demo che abbiamo realizzato al CES con Marelli. Marelli è un fornitore di primo livello. E lì, presso il nostro stand, hanno presentato il primo sistema HMI cloud-native. Ed è davvero interessante, perché lì si vede che stavamo sviluppando un’applicazione HMI nel cloud e poi implementandola a Milano, in Italia. C’era un ingegnere che lo stava facendo nel cloud e poi lo implementava a Las Vegas, nello stand, giusto? Ancora una volta, si parte dallo sviluppo nel cloud, per poi implementare e personalizzare su una soluzione hardware specifica, giusto? E questo è davvero, davvero potente, se ci pensate. Non è solo potente. È SDV, giusto? È definito dal software. Altrimenti, è definito dall’hardware: se si parte dall’hardware, è definito dall’hardware. Se è davvero definito dal software, bisogna partire dal software e, in un secondo momento, procedere alla distribuzione.

L'SDV può ridurre i costi dei richiami

JOHN: Esatto, esatto. Hai appena toccato tantissimi argomenti. E credo di non voler perdere di vista il punto che hai sollevato riguardo ai richiami. Spesso sentiamo le preoccupazioni degli OEM, che hanno un grosso carico di lavoro nello sviluppo del software – il che è vero – e dicono: «Oh, è troppo difficile integrare questa funzionalità software nel veicolo». Ma se si pensa a cifre come quelle che hai citato, 40 o 50 miliardi di dollari, di cui molti legati al software, sarebbe da pazzi non dotarsi delle capacità necessarie per affrontare la questione, perché non occorre un investimento molto elevato per risparmiare potenzialmente miliardi di dollari.

STEFANO: Sì, abbiamo registrato una puntata davvero interessante di “All Things Automotive” con Martin Stamm della Conti.

JOHN: Sì, ho visto quell’episodio.

STEFANO: Sì, l’hai visto? Dove spiega perché è così, vero?

Consolidamento delle centraline elettroniche

STEFANO: Quindi, tradizionalmente, i produttori, gli OEM, avevano l’esigenza di integrare una nuova funzionalità. Ciò significa: “Ok, dobbiamo integrare un’altra centralina, e poi un’altra ancora, e un’altra ancora, fino ad arrivare a 150”. Ma se si pensa all’effetto combinatorio di tutto ciò, non si riuscirà mai a testare tutti i casi possibili in cui si combinano tutte queste variabili. Ecco perché – ed è una cosa positiva per il settore – si sta assistendo a questa tendenza, spinta dall’elettrificazione e da altre tendenze. Il famoso CASE, giusto? Connected, Autonomous, Shared ed Electrified, oltre all’esperienza utente. Questo consolidamento sta avvenendo.

Consolidare il software in modo efficace senza appesantirlo

STEFANO: E, ad essere onesti, è una benedizione per il settore, dove il problema sta proprio nel trasformare il software presente in tutto questo sistema distribuito e integrarlo in queste unità consolidate. Ma – e qui c’è un “ma” – perché è molto importante non limitarsi a dire: “Ok, sapete una cosa? Ora che abbiamo il software in questa ECU, lo prendo e lo infilo nella mia unità consolidata”. Quello è bloatware. Insomma, è pronto a esplodere. Bisogna riprogettare il sistema perché l’unità consolidata è profondamente diversa da una singola centralina ottimizzata in termini di costi. E, in termini di risorse, il software è stato progettato specificamente per quell’hardware quasi su misura. Ecco perché vediamo così tanto – e ne siete consapevoli, vero? – il lavoro che abbiamo svolto, ad esempio, con l’Autoware Foundation sull’Open AD Kit per prendere il software che, in quel caso, per la guida autonoma, è classicamente monolitico – come diciamo noi, un “monolite” – e scomporlo in microservizi proprio per riprogettarlo in modo che sia supportato da una piattaforma hardware e software che richiede davvero maggiore modularità e flessibilità. Aggiornamenti differenziali, giusto? Standardizzazione delle interfacce. E tutti questi sono concetti estremamente importanti per riprogettare l’intero settore automobilistico.

SOAFEE e gli standard per il settore automobilistico

JOHN: Sai, quello che hai appena detto è perfettamente in linea con la conversazione che abbiamo avuto di recente con Robert Day riguardo a SOAFEE. E SOAFEE… so che Amazon è stata uno dei membri fondatori di SOAFEE, quindi tu ne sei decisamente un sostenitore. Gran parte di ciò che SOAFEE sta cercando di fare è fornire proprio alcuni di quegli standard e di quelle interfacce coerenti di cui parlavi. Ma forse questo è un argomento da affrontare in un’altra occasione.

STEFANO: Sì, assolutamente, è davvero, tra l’altro, una conversazione molto ricca; penso che SOAFEE sia un’iniziativa fantastica. E, se avete letto, SOAFEE ha lo scopo di fornire un’implementazione di riferimento basata su standard aperti e open source. Oh, cavolo, abbiamo davvero un gran bisogno di standard aperti e open source nel settore automobilistico, vero? Ecco perché iniziative come Yocto, COVESA, Eclipse SDV e AUTOSAR sono davvero, davvero importanti. E uno dei segnali molto positivi che stiamo notando in SOAFEE è che stiamo iniziando a collaborare insieme, giusto? E dobbiamo insistere su questo, vero? Davvero, perché gli standard aperti sono fondamentali: non si compete sugli standard. Questo è, questo è un no, giusto? Si compete – una volta definiti gli standard – si può iniziare a innovare per quelle cose di cui il cliente ha davvero, davvero bisogno e che desidera, che non rientrano nello standard. Chiunque dica: «Ah, sì, compro questa auto perché questo standard è implementato alla perfezione», non ha senso. Giusto?

JOHN: Esatto. Si tratta di consentire una differenziazione che apporti valore aggiunto rispetto agli standard, pur utilizzando questi ultimi come base.

STEFANO: Come base di partenza. Certo, anche in questo caso si tratta di un altro modo per ridurre i costi e ottimizzare. Perché dedicare tempo e denaro a differenziarsi su una caratteristica tipica dei prodotti di massa, giusto?

JOHN: A questo punto, se l'episodio vi sta piacendo, vi invito a mettere "Mi piace" e a iscrivervi al nostro canale su The Garage per non perdervi i nostri prossimi contenuti. Giriamo un episodio circa ogni due settimane e ci farebbe molto piacere rivedervi qui per il prossimo episodio.

Argomento 4: Apprendimento automatico e analisi dei dati

JOHN: Allora, Stefano, abbiamo parlato di tantissimi ambiti diversi; ora mi piacerebbe passare a discutere di intelligenza artificiale, apprendimento automatico e, più in generale, analisi dei dati, perché abbiamo parlato di questo incredibile data lake che raccogliamo, delle capacità di elaborazione nei servizi specializzati che offrite, dei diversi tipi di elaborazione e così via. E dell’importanza della prototipazione e così via. Ma l’intero ambito dell’apprendimento automatico e dell’analisi dei dati è forse uno dei più affascinanti: una combinazione di elementi in grado di realizzare qualcosa che prima non era mai stato possibile.

STEFANO: Assolutamente sì. E tutto questo va sempre considerato nella prospettiva di quello che chiamiamo il “grande ciclo”, giusto? È estremamente importante, perché, come hai giustamente osservato, gli scienziati sottolineano spesso che il set di dati è l’elemento fondamentale per costruire correttamente un modello, giusto? Quindi teniamo sempre presente questo aspetto come riferimento. Da qui l’importanza di selezionare i dati giusti da archiviare nel cloud.

Raccolta e annotazione dei dati con SageMaker

STEFANO: Quindi, abbiamo bisogno di un po' di intelligenza artificiale nelle auto per distinguere ciò che è rilevante in base alla situazione, giusto? Magari hai fatto una frenata brusca. Quindi perché, o c'è una combinazione di fattori. Oppure ci sono i test a bordo del veicolo; parleremo proprio ora di questa caratteristica super importante. Ma comunque, una volta selezionati i dati, c’è bisogno di un po’ di machine learning che va aggiornato, giusto? Inviamo i dati, li raccogliamo, li puliamo, organizziamo il data lake: perfetto. Poi usiamo parte di questi dati per annotarne una parte, giusto. I nostri clienti li annotano per i propri scopi; disponiamo di strumenti appositi, chiamati SageMaker Ground Truth. Una volta completata l’annotazione, utilizziamo i dati per addestrare e convalidare i modelli. A questo proposito disponiamo di una varietà di opzioni. SageMaker è la nostra piattaforma dedicata a questo scopo.

Altri framework per l'apprendimento automatico su AWS

STEFANO: Se sei davvero un esperto di machine learning, puoi utilizzare framework di base come PyTorch, ad esempio, e lavorare davvero a livello basso, oppure puoi utilizzare, dall’altra parte, quelli che chiamiamo servizi “ AI ”. Ad esempio, servizi di riconoscimento in cui basta inviare un’immagine per ottenere l’elenco degli oggetti presenti. Esatto, quindi servizi di trascrizione AI . Abbiamo quindi questi tre livelli.

Convalida a bordo dei nuovi modelli

STEFANO: Quando si addestra il modello tramite SageMaker, in genere lo si distribuisce sull’edge, ma, ancora una volta, si tratta di un ciclo lungo. Quindi è distribuito, ma non è ancora in produzione. È lì per i test a bordo dei veicoli. Esiste un’altra versione di quel software che è attualmente in produzione. Quindi la prima fase consiste nell’analizzare se questo modello ha prestazioni inferiori o superiori rispetto a quello in produzione, esponendolo a condizioni reali, potenzialmente su un gran numero di veicoli in circolazione, poiché siamo limitati dalla potenza di calcolo del computer. Abbiamo quindi un po’ più di margine, che ci permette di eseguire ulteriori elaborazioni.

Individuazione dei casi limite

STEFANO: Esatto, come hai detto prima, proprio per individuare quei casi particolari, i cosiddetti “casi limite”: è impossibile immaginarli in fase preliminare in modo astratto; bisogna davvero avere le auto, e tante auto, in circolazione per ottenere la convalida delle prestazioni di un modello di machine learning. E quando lo si valuta, e se si constata che il modello è migliore, che non c’è regressione, lo si sostituisce, lo si mette in produzione e il ciclo continua, giusto? Su un numero sempre maggiore di veicoli, esatto, quindi si capisce come l’apprendimento automatico non sia solo un modo magico per addestrare il modello. Ma è davvero questo ciclo intelligente. Ed è molto importante definire i flussi di lavoro. E abbiamo molti strumenti per gestire questi flussi di lavoro. Alcuni di essi si trovano proprio in SageMaker.

Strumenti per la gestione dei flussi di lavoro di ML

STEFANO: Per quanto riguarda altri aspetti, ad esempio la gestione dei dati, disponiamo di un’implementazione e di un’implementazione gestita di Airflow, denominata “Managed Workflow with Apache Airflow”. E la utilizziamo per comporre tutti questi flussi di lavoro, giusto? Io utilizzavo Airflow nel mio precedente lavoro: è uno strumento molto potente per comporre questo tipo di pipeline. Giusto? E questa è una parte davvero molto importante. Tutto questo, spesso i nostri clienti lo utilizzano nei cosiddetti “workbench”, giusto? Sempre più spesso, i nostri clienti ci chiedono di accedere a uno spazio nel browser dove possano trovare i propri strumenti. Questi strumenti possono essere pipeline di dati, flussi di lavoro, dati relativi al machine learning, accesso al data lake, accesso a strumenti settoriali; proprio di recente, ad esempio, abbiamo presentato all’evento dSPACE una collaborazione con MathWorks in questo ambito. Quindi potete trovare questi strumenti proprio in quell’ambiente. E così avete la possibilità di essere molto mirati, di avere un’uniformità di questo ambiente, una distribuzione globale di questo ambiente, un accesso globale a questi ambienti, l’integrazione e la possibilità di creare automazioni, giusto. Recentemente il nostro CEO ha pubblicato su LinkedIn che, utilizzando questo approccio, Toyota ha risparmiato 10 milioni di dollari all’anno. Niente male, vero? Basta organizzare gli strumenti e presentarli attraverso un’interfaccia comune con la possibilità di creare automazioni a partire da essi.

JOHN: Quello che trovo interessante in ciò che hai detto è che ci sono diversi aspetti: si parte dai dati, dai dati grezzi, e si ha la capacità di modellare, ottimizzare e migliorare i modelli. E poi, una volta fatto questo, nel cloud ci sono tutti questi diversi strumenti e moduli che possono collegarsi tra loro per eseguire la post-elaborazione e la post-analisi. E ce ne sono di molti tipi diversi. Quindi credo che l'intero ciclo sia davvero importante.

STEFANO: Assolutamente sì. Ed è per questo che, ad esempio, l’abbiamo organizzato e reso pubblico attraverso il nostro framework per i dati sulla guida autonoma, un’iniziativa open source volta a fornire ai nostri clienti un riferimento open source per creare questo tipo di strutture e flussi di lavoro. E, sì, i nostri clienti stanno onestamente adottando la maggior parte di questo strumento esattamente in questo modo nell’ambito di un flusso di lavoro: clienti come Toyota, ad esempio, utilizzano le nostre istanze P proprio per connettersi alla nostra piattaforma di elaborazione e analisi, giusto, per addestrare il modello su AWS. Ma, ripeto, non si tratta solo di una singola attività isolata. È solo una parte di un flusso di lavoro. Ed è molto importante tenerne conto.

Argomento 5: ADAS e guida autonoma

JOHN: E forse questo è il momento perfetto per passare all’ultimo dei nostri argomenti, ovvero l’ADAS e la guida autonoma, un ambito su cui abbiamo lavorato insieme per diversi anni e in cui abbiamo maturato una notevole esperienza. Parliamo di quanto il cloud sia importante, direi addirittura fondamentale, per l’evoluzione dell’ADAS e del potenziale di questo percorso che stiamo compiendo tutti insieme verso la guida autonoma: si tratta di un percorso piuttosto lungo, ma stiamo facendo passi da gigante.

STEFANO: Assolutamente sì. E, come ho già detto, sono molto appassionato di questo argomento – ne abbiamo già parlato – e mi sta molto a cuore proporre un approccio graduale alla guida autonoma, alle funzionalità autonome e all’autonomia nei veicoli in generale, giusto?

Vantaggi a breve termine derivanti dai sistemi ADAS

STEFANO: Perché oggi i sistemi ADAS, diciamo di livello 2 o 3, offrono un valore aggiunto enorme. E questo è molto importante perché, prima di tutto, salvano vite umane. È proprio così semplice. Giusto? Abbiamo recentemente provato l’auto con l’ADAS di ultima generazione ed è fantastica. È un’auto dotata di sistemi in grado di eseguire la frenata automatica di emergenza. Ad esempio, se sei distratto e c’è un ostacolo, l’auto frena. Semplice, ma se funziona, salva vite umane. Quindi per me è un aspetto estremamente importante. E sono sempre più convinto che l’autonomia sarà un insieme di queste funzioni che verranno progressivamente automatizzate, giusto? Quindi è importante considerare, oltre a tutto ciò, le funzionalità incrementali che verranno automatizzate nei veicoli. Questa è la mia prospettiva al riguardo. E il modo in cui stiamo gestendo il cloud, ancora una volta, utilizzando tutto ciò di cui abbiamo discusso – essenzialmente la varietà di opzioni di elaborazione, la possibilità di questi data lake, le strutture dei data lake e gli strumenti di machine learning – rappresenta la base necessaria per l’ADAS e lo sviluppo dei veicoli autonomi. C’è un altro aspetto relativo alle opzioni di elaborazione, per due ragioni specifiche dell’ADAS che sono molto, molto importanti: spesso si raccolgono dati sul campo e li si archivia in S3 nel data lake. E poi li si utilizza per la validazione, giusto? Quindi in genere si riproducono quei dati raccolti dai veicoli nei propri algoritmi in fase di sviluppo per valutare se siano migliori o peggiori rispetto a quelli della generazione precedente. Oppure si utilizza la potenza di calcolo per eseguire simulazioni sintetiche. Abbiamo un ottimo caso d’uso con Valeo che abbiamo presentato al CES, purtroppo annullato a causa del COVID, a cui nessuno ha partecipato, ma per il quale avevamo preparato questa fantastica demo: c’è un video su YouTube, di cui possiamo ovviamente fornire il link, in cui si vede Valeo utilizzare due tecnologie, una era IPG CarMaker e l’altra Foretellix, per, come sapete, moltiplicare gli scenari tramite simulazione sintetica, arrivando a migliaia di varianti diverse dello scenario su AWS, grazie alla scalabilità, all’elasticità e alla disponibilità della potenza di calcolo, per cercare davvero di coprire tutti questi casi limite, proprio per verificare se nella nostra analisi manca qualcosa, in sostanza, giusto?

Alla ricerca di casi limite

STEFANO: E cercare di anticipare, per così dire, esattamente come abbiamo discusso, la risoluzione di questo problema prima che il software arrivi ai veicoli stessi, giusto? Quindi, ancora una volta, si tratta di riorganizzare questi flussi di lavoro e, su AWS, disponiamo di tutti gli strumenti necessari per consentire ai nostri clienti di farlo. E, in caso contrario, siamo lieti di collaborare con i nostri clienti per crearli.

Analisi della guida autonoma

JOHN: Assolutamente. E credo che molte persone possano pensare che il compito della guida autonoma sia un unico, unico compito. Ma in realtà ci sono moltissimi sottocompiti. Mi piace scherzare dicendo che c’è il compito del riconoscimento delle biciclette e quello del mantenimento della corsia. Ma, scherzi a parte, ce ne sono molti diversi. Bisogna scomporlo, sai, il modo in cui guidiamo noi: noi guidiamo e basta. In realtà, però, il modo in cui il machine learning e l’intelligenza artificiale lo affrontano consiste proprio nel scomporlo in diverse parti. E quello che hai menzionato un minuto fa, secondo me, è molto interessante. Perché quando si pensa all’addestramento, sai, se si pensa alla guida da parte di una persona, la maggior parte delle volte è piuttosto noiosa: si continua semplicemente ad andare dritto, ed è noioso. Quindi, la difficoltà rispetto a ciò che bisogna esercitarsi a fare sta nel fatto che, mentre in realtà potrebbero esserci curve strette o ostacoli, ciò che hai menzionato è davvero interessante: è possibile accelerare i casi limite, fornendomi tantissimi casi limite per aiutare il modello ad apprendere molto più rapidamente di quanto sarebbe possibile in uno scenario di guida reale.

STEFANO: Assolutamente, assolutamente. È proprio vero. Ed è per questo che, ad esempio, come abbiamo discusso, i microservizi sono importanti in questa prospettiva, perché magari si vuole semplicemente sostituire il modello di percezione, lasciando il resto così com’è, giusto? Quindi avere team diversi con competenze diverse, che lavorino sulla loro piccola parte, giusto? Quindi questa è una parte estremamente importante: riconoscere i diversi ruoli coinvolti nello sviluppo dei sistemi ADAS o dei veicoli autonomi. Una parte estremamente importante, giusto? Quindi, in effetti, è uno scenario complesso. Ma, ripeto, abbiamo ottimi riferimenti in merito. Ancora una volta, il caso che stavo descrivendo con Continental riguardava lo sviluppo di sistemi ADAS, e potrete davvero vedere come hanno ottenuto vantaggi in termini di risparmio di tempo, riduzione dei costi e agilità. Adottando un approccio cloud-native, giusto? Era proprio questa l’intenzione dell’esercizio CAEDGE che abbiamo sviluppato con loro. Si trattava, tra l’altro, anche di un’esperienza di veicolo definito dal software. È quindi un ottimo riferimento. La nostra collaborazione con Conti è stata proprio il punto di partenza per riflettere sulla maggior parte di questi concetti. È stata davvero un’ottima collaborazione.

Collaborazione tra AWS e Sonatus

JOHN: Per concludere la nostra conversazione, pensavo che potremmo dedicare un minuto a parlare di alcuni dei settori in cui Sonatus e AWS stanno collaborando.

STEFANO: Sì, con piacere, perché, ripeto, ho visto su the garage alcune demo straordinarie — grazie mille, tra l’altro, per avermele mostrate. Ed è davvero incredibile: alcune delle funzionalità che ho visto, ad esempio il controllo della logica del veicolo e l’implementazione di una nuova logica in base alla situazione, sono esattamente in linea con ciò di cui abbiamo discusso in termini di SDV e aggiornamento del big loop. Si vede davvero che sta accadendo. È davvero fantastico da vedere. E, sì, è un’ottima collaborazione. Ed è un esempio perfetto. Vedi, non si tratta solo di inviare o raccogliere dati, ma si inizia a implementare questa visione di un piano dati: sì, dobbiamo raccogliere dati, ma anche per il piano di controllo. Quindi la possibilità di gestire questa micro-logica, dal cloud all’edge e viceversa, richiede di disporre di alcune di queste micro-logiche, magari un po’ di machine learning all’edge, e di applicare alcune di queste micro-logiche o il machine learning nel cloud. E se pensate al consolidamento, se pensate ai core Arm, sapete, è un sistema che definiamo un continuum tra il cloud e l’edge. E penso che stiate davvero facendo un ottimo lavoro nell’implementare questa visione con la vostra serie di prodotti.

JOHN: Sai, grazie mille. Prima abbiamo parlato di dati e, come sai, il nostro prodotto Collector è altamente ottimizzato: raccoglie dati selezionati con cura, dati di alto valore, e li invia al cloud, e stiamo lavorando con te su questo. E poi il prodotto Automator che hai appena menzionato, che abbiamo lanciato di recente, ci permette di prendere quell’idea di dati intelligenti e di agire di conseguenza, sia all’interno che all’esterno del veicolo. Non abbiamo approfondito molto il tema dei test sui veicoli, ma anche questo aspetto sta diventando molto più complesso. Siamo quindi entusiasti di poter utilizzare questa tecnologia in modi nuovi per, ad esempio, migliorare il flusso di lavoro di produzione, oltre a fornire servizi a valle di qualità superiore. Prima hai menzionato i veicoli connessi in relazione alle funzionalità a valle per l’utente e persino per i fornitori di servizi a valore aggiunto nel settore.

L'importanza di utilizzare centraline originali

STEFANO: Sì, ed è davvero interessante. Ed è un altro punto davvero importante che ho notato, perché lo stai facendo su vere e proprie centraline. E credimi, è una differenza enorme, perché come dico sempre, sai, bisogna tenere presente che quando si sviluppano nuovi componenti software o hardware per il settore automobilistico, il 50% è sviluppo e il 50% è V e V [verifica e convalida]. Nel caso dell’ADAS e dei veicoli autonomi (AV), facciamo qualche ipotesi. Per l’ADAS, penso che il rapporto sia probabilmente 20-80. Per gli AV, il rapporto è 1 a 99. Giusto? Quindi, proprio per via della V e V, quando si inizia a vedere il codice in esecuzione su vere CPU, la situazione cambia, giusto? Non si tratta più solo di un prototipo sulla scrivania basato su un kit di valutazione, ma di qualcosa che verrà installato su un milione, due milioni, dieci milioni di veicoli. Questo fa davvero tutta la differenza.

JOHN: Hai ragione. E siamo davvero contenti di essere presenti, sai, entro quest'anno saremo su decine di modelli e, entro la fine del prossimo anno, su milioni di veicoli. È davvero emozionante vedere che non si tratta di un prototipo, né di un progetto scientifico, ma di vera e propria produzione. E si impara molto dalla produzione vera e propria, dove, per così dire, la teoria incontra la pratica. Questo rende tutto molto più difficile.

STEFANO: Sì. E chiunque operi nel settore automobilistico sa bene quanto sia impegnativo garantire la conformità alle normative. È una parte fondamentale di questo settore, giusto? Quindi non si può semplicemente distribuire il codice come si fa con i telefoni. Giusto? Non si tratta di un dispositivo di consumo, nel senso che è un prodotto regolamentato: ci sono la sicurezza funzionale e la sicurezza informatica. E questi sono aspetti fondamentali. E davvero importanti per noi. È una priorità assoluta, la priorità numero zero.

Sintesi

JOHN: Sì, oggi abbiamo toccato così tanti argomenti che potremmo dedicare molte altre conversazioni di un’ora ciascuna ai vari sottoargomenti di cui abbiamo parlato, ma per oggi dobbiamo concludere. Quindi, innanzitutto, voglio ringraziarti tantissimo per essere qui, Stefano. È stato un piacere averti con noi. Ho imparato tantissimo dalla conversazione di oggi, mi fa sempre piacere parlare con te e spero che tornerai a trovarci.

STEFANO: Anch’io, grazie per avermi invitato. È sempre un piacere. Anch’io ho imparato tantissimo. È stato fantastico.

JOHN: Grazie, Stefano. Nella puntata di oggi abbiamo parlato di ogni aspetto del cloud, in particolare di AWS, concentrandoci sui modi in cui il cloud può apportare benefici e migliorare il settore automobilistico e il flusso di lavoro relativo ai veicoli, partendo dai dati e dalla loro importanza, nonché dai molti modi diversi in cui è possibile utilizzarli; abbiamo parlato di Compute e della necessità di diversi tipi di servizi di elaborazione per risolvere diversi tipi di problemi. Abbiamo parlato di prototipazione, e in particolare della possibilità di realizzare prototipi di funzioni del veicolo nel cloud e di implementarli su un veicolo reale, il che è davvero interessante. Abbiamo parlato di machine learning e analisi dei dati, e di come l’analisi dei dati possa essere utilizzata per aggiungere valore in molti modi diversi. Infine, abbiamo accennato molto brevemente alla guida autonoma e all’ADAS, e a quanto sia importante migliorarle e ottimizzarne il flusso. È stata una conversazione di ampio respiro. Spero che vi sia piaciuta e non vediamo l’ora di rivedervi molto presto in un’altra puntata di “ The Garage ”. Grazie mille.