Arm: trasformare gli SDV in realtà

Panoramica

SANJAY: Ecco un altro episodio speciale del podcast “ Driving Innovation ”, registrato direttamente dalla fiera CES 2024 di Las Vegas. Nell’episodio di oggi abbiamo con noi Robert Day, direttore del reparto Automotive Go-to-Market di Arm. Robert ci illustrerà il coinvolgimento di Arm nel settore automobilistico, oltre all’iniziativa SOAFEE volta a favorire lo sviluppo di software cloud-native. Spero che la puntata vi piaccia.

Ordine del giorno

ROBERT: Grazie. Vorrei quindi ringraziare Sonatus per averci permesso di venire al loro fantastico stand al CES 2024 e parlare un po’ di come noi di Arm intendiamo trasformare in realtà il veicolo definito dal software. Si discute molto dei veicoli definiti dal software. Molte persone hanno cercato modi diversi per renderli davvero realtà. Ed è proprio di questo che parleremo oggi. Dando un’occhiata all’ordine del giorno, parleremo un po’ di chi è Arm e del ruolo di Arm nel settore automobilistico. Poi approfondiremo il concetto di veicolo definito dal software: perché si parla di veicolo definito dal software? Infine, illustreremo alcune delle nostre iniziative che, a nostro avviso, consentiranno di trasformare il veicolo definito dal software in una realtà. Allora, una breve presentazione su chi è Arm. Beh, siamo un’azienda tecnologica che produce fondamentalmente proprietà intellettuale (IP) destinata ai prodotti a semiconduttori. E abbiamo riscosso un discreto successo nei nostri 30 anni di attività. Come potete vedere, ci sono già moltissimi chip basati su Arm in circolazione. E stimiamo che il 70% della popolazione mondiale utilizzi prodotti che contengono tecnologia Arm. È interessante notare che ho iniziato a contare il numero di prodotti Arm che ho in casa e mi sono fermato perché la cosa si è fatta un po’ complicata. Quello che stiamo osservando è che questa tendenza sta accelerando, dato che Arm sta passando dai dispositivi di consumo presentati al Consumer Electronics Show al settore automobilistico. Ed è proprio di questo che parleremo oggi.

Arm nel settore automobilistico

ROBERT: Quindi Arm opera nel settore automobilistico già da 25 anni. Ok. Praticamente da sempre ci occupiamo di sistemi per veicoli. Ma in genere siamo rimasti un po’ “sotto il cofano”, se capisci cosa intendo. E quindi, se dai un’occhiata ad alcune di queste statistiche qui, oltre l’85% dei sistemi IVI funziona su Arm, il che è piuttosto naturale perché i sistemi IVI sono simili ai dispositivi di consumo. Semplicemente si trovano all’interno del tuo veicolo. Ma ora, con l’arrivo delle nuove funzionalità ADAS e dell’autonomia, anche molti dei processi applicativi sono basati sulla tecnologia Arm. Quello che abbiamo fatto in Arm è stato creare prodotti specifici per il settore automobilistico. Abbiamo quindi CPU, GPU e ISP, che vi mostrerò tra un attimo, la cui caratteristica chiave è la sicurezza funzionale. Abbiamo anche un fantastico ecosistema automobilistico, di cui Sonatus è uno dei nostri partner.

Perché un veicolo definito dal software

ROBERT: Allora, perché è importante un veicolo definito dal software? Innanzitutto, dal punto di vista degli OEM, permette loro di esplorare nuovi modelli di business, nuovi modelli di ricavo e nuove relazioni con i propri clienti. La particolarità dei veicoli definiti dal software, come suggerisce il nome stesso, è che lo sviluppo precoce del software è fondamentale. Ci sarà così tanto software in un’auto che non è possibile realizzarlo tutto in una volta sola. Ok? Ma stiamo constatando che il veicolo definito dal software rappresenta la chiave per la sopravvivenza dell’industria automobilistica. È interessante notare che questo percorso è già in atto. Ecco una citazione di Gartner dello scorso anno secondo cui, sostanzialmente, nel 2023, il 50% delle prime 10 case automobilistiche offrirà nuove funzionalità tramite aggiornamenti software. Ed è proprio questo il punto centrale del veicolo definito dal software: è possibile integrare queste funzionalità sotto forma di software e aggiornarle, potenziarle o aggiungerne di nuove. E questa è una delle parti fondamentali di tutto ciò.

Siamo pronti per l'SDV?

ROBERT: La domanda successiva è: siamo pronti, come consumatori, per un veicolo “software-defined”? E siamo disposti a pagare per questo? Aurora Labs e Strategy Analytics hanno condotto uno studio, credo nel 2022, in cui hanno chiesto ai consumatori se sarebbero stati disposti a pagare per funzionalità e servizi “software-defined”. E, come potete vedere, quasi il 50% delle persone ha dichiarato che pagherebbe 20 dollari al mese per servizi aggiuntivi nella propria auto. Si tratta di una cifra piuttosto consistente su base annua. E per l’intero ciclo di vita del veicolo. Alcuni sarebbero persino disposti a pagare fino a 50 dollari, il che è davvero incredibile. Non mi metto nemmeno a calcolare a quanto ammonterebbe in un anno.

Nuovi requisiti per l’SDV

ROBERT: Il punto è che i veicoli definiti dal software comportano nuovi requisiti rispetto al settore automobilistico tradizionale. Dobbiamo quindi essere in grado di fornire le funzioni definite dal software come caratteristiche avanzate. Dobbiamo favorire l’innovazione, ma dobbiamo anche garantire agilità. Si tratta quindi di un ambito più simile al mondo del software tradizionale che non necessariamente a quello automobilistico. Questi elementi devono essere aggiornabili e potenziabili. Devono essere sicuri. E devono garantire la sicurezza. Infine, devono essere scalabili. Uno degli aspetti fondamentali di un veicolo software-defined è la possibilità di scalare tali caratteristiche e funzioni su diversi modelli della propria auto. Sarà quindi davvero interessante vedere come si evolverà questa dinamica man mano che entriamo nell’era dei veicoli software-defined.

I prodotti Arm per il settore automobilistico

ROBERT: Allora, in Arm, come ho accennato, disponiamo di questi prodotti per il settore automobilistico; abbiamo una sorta di gamma di prodotti che chiamiamo AE, ovvero Automotive Enhanced. Abbiamo quindi un processore ad alte prestazioni chiamato Cortex-A78AE. Questo presenta una caratteristica interessante chiamata “split-lock”, che consente di bloccare insieme coppie di core per garantire livelli di sicurezza più elevati. Ma se si desiderano prestazioni elevate, è possibile sbloccarli. In questo modo si ottengono, in pratica, due core. Questa funzionalità è presente nelle nostre CPU AE. Abbiamo anche una GPU a sicurezza funzionale, la Mali-G78AE, dotata di un interessante meccanismo di partizionamento che garantisce un rendering sicuro. Abbiamo inoltre un ISP denominato Mali-C78AE. Tutti questi prodotti sono quindi fondamentali per l’esecuzione di funzioni software-defined e di applicazioni grafiche a bordo del veicolo, che faranno parte di tali funzioni. L’ISP, dal canto suo, garantisce immagini dalla telecamera di ottima fedeltà all’interno dell’abitacolo per tutte le funzionalità ADAS e altre applicazioni simili. Passiamo ora all’SDV.

I quattro pilastri dell’SDV

ROBERT: Quindi, parlando con gli operatori del settore, ci siamo resi conto che ci sono quattro pilastri fondamentali per realizzare il veicolo definito dal software (SDV) e garantirne l’implementazione. Da un lato e dall’altro, ovviamente, ci sono la sicurezza e la protezione; poi è necessario disporre di funzionalità in tempo reale. Sono elementi di cui il settore automobilistico ha comunque bisogno e di cui ha bisogno anche il veicolo definito dal software. Abbiamo bisogno di standard che vadano oltre quelli tradizionali del settore automobilistico. Per le funzioni definite dal software, devono esserci API e standard su cui poterle costruire. Dobbiamo adottare alcune nuove metodologie software. Ne parlerò più approfonditamente oggi, perché si tratta di un modo interessante per introdurre effettivamente queste metodologie software provenienti da altri settori nel settore automobilistico. Ebbene, ciò che è fondamentale – e ne parlerò tra poco – è avere la capacità di eseguire il software quando il veicolo e il sistema informatico di bordo non sono ancora disponibili. Bisogna poter iniziare presto e ricorrere a strumenti come la simulazione. E l’aspetto fondamentale, di cui parlerò alla fine, è la collaborazione all’interno del settore. Non possiamo più permetterci questi compartimenti stagni. Le persone devono lavorare insieme. Il problema è troppo grande perché una singola azienda possa affrontarlo da sola. Diamo quindi un’occhiata ad alcuni di questi aspetti. Una delle chiavi di cui abbiamo appena parlato era proprio quella delle nuove metodologie software.

Processi di sviluppo moderni

ROBERT: Quindi, ciò che dobbiamo fare ora nel settore automobilistico è introdurre processi di sviluppo moderni per accelerare sostanzialmente i tempi di sviluppo e di distribuzione del software. Dobbiamo anche essere in grado di garantire quella che viene definita “parità ambientale”: se si sviluppa nel cloud e si distribuisce sull’edge, è davvero ottimale che questi due ambienti condividano lo stesso set di istruzioni, in modo da poter eseguire il software sia nel cloud che nell’auto. Ne parleremo un po’ più approfonditamente. È molto importante anche poter contare su una facile implementabilità tra una vasta gamma di fornitori di chip. Ciò garantisce la portabilità del software quando si passa da una generazione di auto all’altra, o da un modello all’altro. E ciò che questo consente, in realtà, è anche una strategia di “shift-left”. Ve lo spiegherò nella prossima diapositiva.

Strategia "shift-left" nel settore automobilistico

ROBERT: Quindi, qui da noi lo sviluppo automobilistico tradizionale è piuttosto serializzato. In pratica, si progetta il software e il SoC, poi si realizza l’ECU e infine si sviluppano le applicazioni. È una sorta di processo seriale. Non è possibile avviare in modo significativo lo sviluppo delle applicazioni finché questi elementi non sono a posto. Quando puntiamo a un approccio cloud-native, introduciamo il cloud. E se si può iniziare a sviluppare le applicazioni sin dalle prime fasi nel cloud, che si trova a questo livello, allora è possibile iniziare a sviluppare qui mentre gli altri passaggi vengono completati. In questo modo si ottiene un processo parallelo. E poi, una volta ottenuta l’integrazione del sistema, è allora che si può trasferirlo sul veicolo e testarlo. Quello che stiamo effettivamente facendo è testarlo e svilupparlo prima qui in alto. Quando il veicolo è pronto, o il sistema informatico del veicolo è pronto, lo si trasferisce sul veicolo. L’altra cosa che questo rende possibile – ecco il vostro “shift-left”, in termini di tempistica – è la possibilità di aggiornamenti e upgrade continui, che sono un fattore importante per il veicolo definito dal software. In questo modo si è continuamente in grado di offrire servizi nuovi o aggiornati ai consumatori del proprio veicolo. Ciò comporta un cambiamento dinamico davvero interessante nelle possibili relazioni tra gli OEM e le persone che guidano le loro auto, perché attualmente, quando si acquista un’auto, la si guida via dal concessionario senza instaurare un vero e proprio rapporto con l’azienda che l’ha costruita. Al contrario, ora che vengono forniti aggiornamenti e servizi, il rapporto si instaura. E così il rapporto tra chi guida le auto e chi le costruisce inizia a cambiare. Ma come possiamo raggiungere questo obiettivo?

Iniziativa SOAFEE

ROBERT: Allora, un paio di anni fa abbiamo avviato un’iniziativa chiamata SOAFEE. Si tratta di un’iniziativa di settore pensata proprio per portare esperienze di sviluppo software cloud-native nei veicoli automobilistici definiti dal software. Ok? E lo abbiamo fatto dando vita al gruppo di interesse speciale SOAFEE. La prima cosa che volevamo fare con questo gruppo era cercare di definire un’architettura software che rendesse possibile tutto ciò. Quindi SOAFEE si occupa innanzitutto di definire un’architettura, piuttosto che del codice vero e proprio. Tuttavia, affinché le persone potessero davvero iniziare a utilizzare SOAFEE, sapevamo di aver bisogno di un’implementazione software di riferimento, in modo che potessero cominciare a sviluppare e sperimentare queste nuove metodologie per i carichi di lavoro del settore automobilistico. Come potete vedere, i membri fondatori e i membri del comitato direttivo di SOAFEE provengono da tutto l’ecosistema automobilistico. Abbiamo quindi OEM, fornitori di primo livello, operatori del cloud, noi stessi e infine alcuni esperti di software. Abbiamo Red Hat e SUSE, che conoscono davvero bene lo sviluppo software e come tutti questi elementi si integrino tra loro. Riteniamo quindi che, già solo all’interno degli organi direttivi, abbiamo una visione piuttosto chiara di ciò che vogliamo realizzare. Tra un attimo vi mostrerò anche un po’ più nel dettaglio i membri di SOAFEE.

Architettura cloud-native

ROBERT: Ma ti avevo detto che stavamo davvero cercando di definire un’architettura. E come puoi vedere qui, abbiamo questa architettura in cui ci sono alcune componenti nel cloud e altre a bordo del veicolo. L’idea, tuttavia, riguarda le applicazioni vere e proprie, e gran parte di ciò che vedi qui rimarrà costante, ovvero coerente tra il cloud e l’edge. Ciò significa che quando sviluppi cose come le tue applicazioni o i tuoi servizi nel cloud, quando sei pronto a portarli all’edge, questi dovrebbero semplicemente funzionare. Ed è qui che utilizziamo tecnologie come i container e strumenti come l’orchestrazione. Si tratta di concetti in qualche modo mutuati dal mondo del cloud, quindi sono già ben consolidati. Le persone ne hanno già familiarità. Quello che dobbiamo fare è adattarle al settore automobilistico. E ciò significa, in pratica, che dobbiamo considerare aspetti quali la sicurezza funzionale, il tempo reale e l’elaborazione eterogenea, che non sono necessariamente presenti nel cloud. Questa è quindi una delle sfide che SOAFEE si appresta ad affrontare.

Iscrizione a SOAFEE

ROBERT: Negli ultimi due anni, in realtà, abbiamo avuto un gruppo di membri piuttosto valido. Potete vedere di nuovo i membri dell’organo direttivo. Siamo arrivati, credo, a circa 115 membri adesso. E qui potete vedere, anche se probabilmente non si vede bene, il logo dell’ Sonatus . L’ Sonatus è membro della SOAFEE. Il che ha perfettamente senso, perché gran parte di ciò su cui si concentra l’ Sonatus riguarda proprio il veicolo definito dal software. Si tratta di una connessione dal cloud al veicolo. Sono quindi degli ottimi esperti in questo settore con cui possiamo collaborare.

Gruppi di lavoro SOAFEE

ROBERT: Allora, qualche parola sulla struttura di SOAFEE. Ribadisco, non sono del tutto sicuro di quanto possa risultare chiaro. Abbiamo quindi un organo direttivo presieduto da Bill di AWS. Abbiamo un comitato direttivo tecnico e un comitato direttivo di marketing. Il comitato direttivo tecnico si occupa proprio di tutti i gruppi di lavoro che svolgono l’attività operativa, e le aree su cui si concentrano riguardano l’architettura di sistema. Stiamo esaminando il cloud native. Ci stiamo occupando della criticità mista e stiamo esaminando tecnologie come quelle degli hypervisor che riteniamo saranno fondamentali. E poi tutto questo confluisce in questa implementazione di riferimento che pubblichiamo come soluzione open source per consentire un utilizzo precoce di SOAFEE. Quindi, altre cose che stiamo facendo. In realtà, se torniamo indietro, potete vedere qui che abbiamo un altro Tiger Team, ovvero il Blueprints Tiger Team.

Progetti SOAFEE

ROBERT: Insomma, rilasciare un’implementazione di riferimento open source va bene, ma in un certo senso si basa sul fatto che le persone dicano: “Ok, ora dobbiamo fare qualcosa”. Capito? Quindi abbiamo deciso di creare questi "blueprint" SOAFEE, ovvero applicazioni di riferimento, fondamentalmente per un caso d’uso nel settore automobilistico, che funzioneranno in un ambiente SOAFEE. Possono essere open source o closed source. Quello che volevamo fare era introdurre applicazioni di esempio nel mondo SOAFEE affinché le persone potessero utilizzarle e anche consentire agli OEM di diventare operativi rapidamente grazie agli esempi disponibili. Entrerò un po’ nel dettaglio di cosa fanno realmente questi blueprint. Un blueprint SOAFEE consiste essenzialmente nel dedicare parte del tempo all’implementazione di riferimento che gira, come sapete, sul firmware e sull’hardware. E poi abbiamo questi container. Come ho detto, parte dell’architettura SOAFEE punta proprio sulla containerizzazione dei carichi di lavoro. Quindi una sorta di approccio basato sui microservizi. E così abbiamo diversi carichi di lavoro in esecuzione in diversi container. Qui potete vedere i diversi elementi software: abbiamo carichi di lavoro specifici per le applicazioni, abbiamo lo stack di base, che include container, orchestrazione, potenzialmente hypervisor, strumenti e tutto il resto. E poi la piattaforma di calcolo alla base. Ecco come si presenta un blueprint generico. Ora vi farò un esempio.

Kit AD aperto

ROBERT: Il primo esempio era un progetto chiamato OpenAD Kit. Si tratta di una collaborazione con Autoware, un’azienda che sviluppa software open source per la guida autonoma. In pratica, abbiamo preso lo stack di Autoware e lo abbiamo suddiviso in diversi container. Questi container comunicano poi tra loro tramite una rete virtuale. Come potete vedere, in ciascuno di essi sono presenti diverse funzioni: mappatura, percezione, pianificazione e interfaccia del veicolo. All’inizio abbiamo un po’ “barato” per assicurarci che il sistema funzionasse. In realtà stiamo eseguendo quattro copie complete di Autoware in un unico container, ma in realtà abbiamo attivato solo la funzione di mappatura. Ecco cosa dovevamo fare per arrivare a un’architettura più simile a quella dei microservizi: fondamentalmente, abbiamo trasferito ciascuna di queste funzioni nel proprio container, in modo che non venga più eseguito l’intero stack autonomo, ma solo le singole funzioni. Ed è proprio quello che stiamo facendo ora con questo blueprint di OpenAD Kit. La cosa interessante dei blueprint, ed è proprio questo il motivo per cui li abbiamo realizzati, è che volevamo che il settore li adottasse e iniziasse a utilizzarli sia come esempi di ciò che è possibile fare se si è un OEM, sia se si è un’altra azienda tecnologica che vuole integrare la propria tecnologia per renderla ancora più interessante. E così, l’anno scorso, un’azienda chiamata Kern Concept ha detto: «Ok, tornerò a occuparmi di queste cose containerizzate». E so che una delle funzioni qui presenti, l’interfaccia del veicolo, è una funzione di sicurezza. Se non funziona, il veicolo non funziona. Ok? Quindi dovrebbe essere in esecuzione in un sistema di sicurezza. Quello che hanno fatto, se vado qui, è stato creare due sistemi. Ne avevano uno qui, che gestisce la maggior parte delle funzionalità di Autoware, e uno qui, che è la funzione di sicurezza, che gestisce fondamentalmente l’interfaccia del veicolo, collegati da una rete Ethernet, una vera e propria rete Ethernet fisica, anziché una rete Ethernet virtuale. Quindi si tratta dello stesso concetto dei microservizi containerizzati, ma ora lo stiamo applicando a una rete eterogenea, a un sistema eterogeneo. Quello che potete vedere è che la parte relativa alla sicurezza si trova qui, che in questo caso può essere gestita da un microprocessore di sicurezza, in questo caso un NXP. E poi qui ci sono i processi applicativi che non devono necessariamente avere lo stesso livello di sicurezza.

Piattaforme di destinazione SOAFEE

ROBERT: A proposito di piattaforme, l’altra cosa che dovevamo fare era disporre di alcune piattaforme hardware: non era visibile sulla mappa, ma molti dei nostri partner nel settore dei semiconduttori sono membri di SOAFEE. E quello che stiamo davvero cercando di fare ora è convincerli a portare le loro piattaforme Avere SOAFEE, l’implementazione di riferimento di SOAFEE, su quelle piattaforme. E quindi, come potete vedere, abbiamo aziende come Renesas, NXP e Marvell. Abbiamo anche un’istanza cloud nativa di AWS. Ciò significa che è possibile eseguire SOAFEE in modalità bare metal nel cloud su un Graviton, che è il processore basato su Arm. Inoltre, volevamo disporre anche di alcune piattaforme di sviluppo non destinate al settore automobilistico. Abbiamo quindi il Turing Pi e il Raspberry Pi. Infatti, all’evento COVESA di ieri sera, il Raspberry Pi era uno dei sistemi su cui girava SOAFEE. Ok, questo è SOAFEE.

Come partecipare

ROBERT: Se siete interessati e volete partecipare, su SOAFEE.io troverete molte informazioni. C'è un canale Slack e SOAFEE è presente su LinkedIn. E se volete unirvi a noi, probabilmente la cosa migliore da fare è contattarmi direttamente all'indirizzo Robert.Day@arm.com. Sarò lieto di aiutarvi a diventare membri. Ecco, questo è SOAFEE. Crediamo che sia un aspetto davvero interessante per rendere il veicolo software-defined una realtà. Se qualcuno di voi ha prestato attenzione, avrà notato che esistono altri consorzi che stanno contribuendo a rendere il veicolo definito dal software una realtà. Ma ognuno di noi è in un certo senso nel proprio mondo, dove si occupa della propria parte del lavoro. E quindi non è sempre ovvio. Beh, come si integrano tutte queste cose? Lo scorso marzo abbiamo deciso che avremmo cercato di dare un contributo anche in questo senso.

SDV Alliance

ROBERT: Abbiamo quindi costituito una nuova alleanza. Questa alleanza è stata lanciata ieri. Si tratta di una collaborazione – direi una collaborazione iniziale – tra quattro organizzazioni che stanno tutte cercando di rendere l’SDV una realtà. Abbiamo quindi Autosar, probabilmente il più antico dei… no, il più maturo dei consorzi. Abbiamo COVESA, che prima si chiamava GENIVI o GEN IVI. Abbiamo Eclipse SDV e abbiamo SOAFEE. Quello che stiamo facendo, quindi, è promuovere una collaborazione tra questi diversi consorzi. È come un consorzio di consorzi, o una collaborazione tra collaborazioni, se preferite. E solo considerando queste quattro organizzazioni, ci sono oltre 500 aziende dell’ecosistema automobilistico coinvolte in questi diversi consorzi. Ciò che questo comporta, e ciò che faremo come alleanza, è chiarire come questi elementi si integrino tra loro. E infatti, all’evento di lancio di ieri sera, abbiamo mostrato una demo di parti di ciascuno di questi sistemi che funzionavano insieme, proprio per dimostrare che ciò è possibile. Ma ciò che offre è un insieme che riunisce cloud-to-edge, auto connesse, open source, standard aperti, tempo reale e sicurezza, in un unico pacchetto. L’obiettivo è che, se riusciremo davvero a farlo nel modo giusto, questo dovrebbe rendere il lavoro degli OEM molto più semplice per sviluppare e implementare il veicolo definito dal software. Ma incoraggerà anche la collaborazione, una maggiore collaborazione. Non una collaborazione tra consorzi isolati, ma un vero lavoro di squadra. È stato un percorso davvero interessante negli ultimi nove mesi, dedicato proprio a lavorare su questa alleanza e a portare avanti la collaborazione. Ora che abbiamo dato il via, il lavoro ha inizio. Quindi quello che vi consiglio è semplicemente di tenere d’occhio, sapete, ciò che uscirà da questa alleanza. E, ripeto, se volete partecipare all’alleanza, potete contattare una qualsiasi di queste altre organizzazioni. L’ultima cosa che dirò è che si tratta di un’alleanza aperta. Ci aspettiamo che altri consorzi si uniscano a noi. Non siamo solo noi quattro. Abbiamo voluto dare il via a questa iniziativa, ma incoraggiamo altri consorzi a partecipare a questa alleanza e a questo sforzo congiunto del settore. Ne siamo davvero convinti e, come ho sentito ieri sera parlando con due OEM, questo è un aspetto che loro apprezzano. Speriamo quindi che questo sia un ottimo inizio, l’inizio vero e proprio del percorso verso il veicolo definito dal software. Ho detto che è già in corso, ma ciò che dobbiamo fare è renderlo una realtà su larga scala. E speriamo che tutti i membri di questo consorzio si uniscano e lavorino insieme per renderlo davvero realtà. Saltiamo questa diapositiva.

Conclusione

ROBERT: Detto questo, vorrei ringraziarvi. Grazie ancora a Sonatus per averci dato l’opportunità di venire qui a parlare di queste fantastiche novità relative ai veicoli definiti dal software. Spero che vi piaccia guardare questo video online. Grazie mille.