Le auto sono sempre più dei computer: le conseguenze per l’industria. Parla McKinsey

di Nicodemo Angì ♦︎ Le automobili sono sempre più Big Data centriche e il sistema operativo a bordo auto si trova a dover gestire una quantità di codice impressionante fra centraline, sistemi di infotainment e Adas per la guida assistita. Per questo la case hanno iniziato a svilupparlo internamente. Il Volkswagen Automotive Cloud, sviluppato in collaborazione con Microsoft. Il sistema operativo Mb.Os di Mercedes-Benz. Ma c'è anche chi lo compra da terzi

Auto connesse

Le disruption che stanno interessando l’automotive sono diverse ma non tutte hanno la stessa “visibilità”: elettrificazione, connettività, car sharing e guida autonoma sono infatti in evidenza nei media e fra i consumatori. Non si parla invece molto del software delle automobili, un vero e proprio sistema operativo che, secondo McKinsey, non solo è abilitante per queste nuove tecnologie ma permette di ridurre i costi e aumentare i ricavi tramite servizi innovativi.

Si stratta di un settore in crescita tumultuosa: la ricerca McKinsey Automotive software and electronics 2030 stima che il passaggio a un’architettura software centralizzata contribuirà molto alla crescita prevista del mercato del software e dell’elettronica automotive: un tasso del 7% Cagr (tasso di crescita composto annuo) al 2030. L’elettronica di potenza – inverter, caricabatterie, convertitori – avrà la fascia alta della crescita con un Cagr del 15%. La crescita nei segmenti software e sensoristica, prevista rispettivamente al 9 e dell’8%, sarà alimentata dalla guida autonoma e dai sistemi di assistenza alla guida.







Il segmento delle Electronic Control Unit e delle Domanin Control Unit continuerà ad avere la quota maggiore del mercato ma con una crescita del ‘solo’ 5%. I veicoli elettrici rappresenteranno un nuovo mercato per i cablaggi ad alta tensione (Hv), mentre si prevede che la domanda di cablaggi a bassa tensione (Lv) si ridurrà, anche perché comprende quello dei segnali elettronici, che potrebbe decrescere con l’adozione di software centralizzati anche se i sensori aumenteranno di numero.

McKinsey prevede che il settore del software automotive e dei componenti elettrici ed elettronici cresceranno fortemente fino al 2030. Ecu: Electronic Control Unite, Dcu: Domain Control Unit. Fonte McKinsey

 

Il software è troppo frammentato

Il mercato complessivo del settore software/componenti elettrici/componenti elettronici automotive valeva 238 miliardi di dollari nel 2020 ed è stimato in crescita a 362 nel 2025 e a 469 miliardi nel 2030, un dato che è un quasi raddoppio in una decade. La concezione attuale delle automobili, a parte pochissime eccezioni, prevede una miriade di “centraline” specializzate che comunicano con i bus di dati, una soluzione mutuata dall’informatica. Queste centraline vengono però da molti fornitori diversi che ricevono dagli Oem delle specifiche, ad esempio per le prestazioni e i protocolli di comunicazione con la rete dati veicolare, ed entro queste specifiche sviluppano il componente con il loro software.

La complessità sempre crescente sta mettendo però in crisi questa concezione: i sistemi avanzati di assistenza alla guida – Adas, per esempio, sono ormai molto ‘trasversali’ perché interagiscono con freni, sterzo, motore, strumentazione e telaio. La gestione di questi sistemi con le architetture attuali è già impegnativa e una guida autonoma di Sae Level elevato – il Level 5 prevede nessun intervento umano in qualsiasi strada e condizione – non sarebbe in pratica implementabile con questa architettura.

Il software dei veicoli odierni vine da molti produttori diversi. Fonte McKinsey

Sistema operativo automotive, una necessità

Mercedes Maybach GLS 600

Gli Oem si stanno muovendo e hanno ben compreso che le automobili saranno sempre di più Big Data centriche (ne abbiamo parlato qui), una mutazione ben delineata nella ricerca McKinsey The case for an end-to-end automotive-software platform. Questo lavoro è stato pubblicato nel gennaio 2020 e ci siamo chiesti se e come la pandemia da Coronavirus potesse aver modificato le strategie dei costruttori.

Secondo Michele Bertoncello, partner di McKinsey e Coleader nella Connected-car initiative del McKinsey Center for Future Mobility, i costruttori «hanno rallentato significativamente gli investimenti e iniziato a mettere in campo una serie di azioni per tutelare la loro “cash position”, non sapendo quanto sarebbe durata la crisi. Si è avuto un impatto sullo sviluppo di nuovi veicoli, con un forte rallentamento durato alcuni mesi. Le attività sono poi riprese privilegiando però la connettività, l’elettrificazione e lo sharing mentre la guida autonoma avanzata, Level 3 e 4, è stata temporaneamente deprioritizzata visto che la sua introduzione avverrà in un futuro più lontano. Gli investimenti nell’elettrificazione hanno risentito poco o nulla, anche perché sono funzionali alla diminuzione delle emissioni di flotta richieste dal regolatore. Sia l’ormai imprescindibile connettività sia l’elettrificazione richiedono comunque una significativa evoluzione dell’elettronica e del software dell’automobile». La pandemia non ha quindi rallentato gli investimenti sul software e l’elettronica del veicolo, propedeutici alle evoluzioni nei settori più promettenti e richiesti dai consumatori.

La crescente complessità dei veicoli indurrà una richiesta di software automotive non sostenibile con gli attuali ritmi produttivi, anche ricorrendo ai contributi dei player Hi-Tech. Fonte McKinsey

Architetture da ripensare e vantaggi importanti

In effetti passare da architettura simili a quelle finora in uso ad altre end-to-end, che definiscano con precisione un sistema operativo, i vari servizi e i vari domini, dà molti vantaggi. La configurazione attuale, secondo Bertoncello, «non è in grado di gestire un ulteriore aumento della complessità. Sono già evidenti i grandi problemi derivanti dal dover armonizzare software che arrivano da decine di sviluppatori diversi e che comportano l’aumento di tempi e costi di integrazione e debugging. Questa ‘macchinosità’ intacca anche la sicurezza e può rallentare il lancio di nuovi modelli. Le eventuali dilazioni nelle vendite di questi veicoli, a emissioni locali ridotte o nulle, non solo differiscono i ricavi ma deludono i clienti ed espongono ai rischi di sanzioni qualora fossero funzionali al raggiungimento dei target di emissioni del costruttore. La combinazione di mancati/ritardati guadagni, multe per emissioni e danno reputazionale, inconvenienti causati da un software non ottimizzato, potrebbe quindi generare conseguenze negative per i costruttori. I nostri studi evidenziano l’esplosione della complessità del software auto, che ci aspettiamo possa triplicarsi nei prossimi 10 anni».

Questioni gravi, quindi, che richiedono un notevole sforzo finanziario e di ricerca di personale qualificato ma anche un ripensamento dei processi aziendali. La posta in gioco è alta perché «i software integrati sono enabler di funzionalità – infotainment, esperienza di bordo, assistenza alla guida – per le quali i consumatori sono disposti a pagare. Una connettività evoluta, che affianchi queste piattaforme, permette inoltre all’Oem di monitorare il veicolo, ridurre i costi di garanzia, aumentare la sicurezza e così via».

Lo sviluppo del software automotive vede la crescita più forte nei settori dei Sistemi Operativi/Middleware e in quello Adas/Guida autonoma. Fonte McKinsey

Il software end-to-end? Ci lavorano le Case

Stellantis Foxconn

Il nostro interlocutore elenca altri vantaggi, che promettono di coprire molti settori: «Un software integrato porta con sé semplificazione delle interfacce fra vari domini, cybersecurity molto più efficace perché il software è centralizzato end-to-end e interfacce utente migliori e più intuitive. La gestione delle risorse hardware può essere ottimizzata in maniera quasi nativa e gli extra costi connessi al software frammentato sono minimizzati. Un software di questo tipo riduce costi e tempi di sviluppo, e contribuisce alla riduzione dei costi per unità prodotta». Le Case hanno preso coscienza della necessità di sviluppare il loro software, con il Gruppo Volkswagen che ha creato Cariad con Dirk Hilgenberg nel ruolo di ceo. Dal sito aziendale si evince che attualmente solo il 10% del software del Gruppo Volkswagen è prodotto internamente, una quota che dovrebbe arrivare al 60% entro il 2025. La forza lavoro attuale è di circa 4.500 sviluppatori con ingegneri software di 70 Paesi diversi che lavorano nei centri di competenza tedeschi (Wolfsburg, Ingolstadt, Stoccarda, Berlino e Monaco di Baviera) e in altri a Seattle, nella Silicon Valley e in Cina.

Un grande sforzo che comprende collaborazioni quali quella con Microsoft per creare il Volkswagen Automotive Cloud e il futuro Automated Driving Platform, un framework di sviluppo per le funzioni di guida automatizzata. Cariad sta creando una piattaforma software unificata, Vw.Os, per tutti i marchi del Gruppo Volkswagen, cosa che comporta poi la sua distribuzione su 10 milioni di veicoli l’anno. Il Volkswagen Automotive Cloud è invece un ecosistema in rete sul cloud che, insieme all’intelligenza artificiale e al machine learning, consentirà di elaborare la grande quantità di dati creata e inviata dalle auto connesse per migliorare e rendere più sicura e sostenibile la mobilità. Lo scopo, secondo l’azienda, è «offrire servizi avanzati di mobilità, dalle soluzioni di E-Commerce, allo sviluppo di frontend e backend, nonché alla gestione e all’analisi dell’esperienza del cliente». Volkswagen sembra quindi aver fatto alcune delle mosse che Michele Bertoncello elenca come opportune per fronteggiare le sfide del nuovo automotive, cogliendo anche le opportunità connesse a questi cambiamenti.

Secondo McKinsey lo sviluppo dei nuovi sistemi operativi automotive richiede cambiamenti in diverse aree. Fonte McKinsey

Nuove competenze per sostenere le sfide

Tesla Model 3

Anche Mercedes-Benz si sta muovendo con determinazione per lo sviluppo del suo sistema operativo Mb.Os. Nell’evento online Mercedes-Benz Strategy Update: electric drive si è infatti detto che «MB.OS sarà il backbone digitale per le future Mercedes. Stiamo reclutando 3.000 esperti di software per lo sviluppo del nostro software per le automobili Mb.Os e 1.000 di questi posti di lavoro saranno creati in Germania. Offriamo a questa nuova generazione di esperti un quadro contrattuale interessante che consente condizioni di lavoro innovative». Nell’evento si è anche parlato di cambiamenti nei modelli di business e di produzione: «L’aumento dei ricavi dai servizi digitali supporterà i nostri ricavo complessivi. Il passaggio al modello di vendita diretta è il cambiamento più importante nella nostra gestione delle vendite: elimina molti costi, aumenta la trasparenza dei prezzi e ci consente di controllarli meglio. Il cambiamento implica anche metodi di produzione digitali, una maggiore integrazione verticale nella produzione di batterie e un maggiore utilizzo di materiali riciclati». Il fatto che le competenze richieste siano molto nuove è dimostrato ad esempio da un profilo professionale ricercato da Cariad: l’Engineer specializzato in Gpu-Computing Machine Learning. Fra le competenze richieste troviamo almeno 3 anni di esperienza in scrittura e ottimizzazione di codice per inferenza e machine learning efficiente in C++ e Cuda (è la piattaforma di programmazione e calcolo sviluppata da Nvida per i suoi processori grafici) ed esperienza con strumenti di sviluppo di reti neurali e deep learning.

Il parcheggio a guida autonoma Bosch Daimler

Tesla, che da costruttore nato nella Silicon Valley ha un suo sistema operativo da sempre, ha attualmente posizioni aperte per ‘Embedded Software Engineer, Linux Platforms’ e “Software Manager – Software Technical Lead, Linux Software Platforms’. Daimler sta cercando per Mb.Os anche dei Software Architect con laurea in informatica o simile, conoscenze di Linux, QNX (un sistema operativo real-time per i sistemi embedded basato su Unix e sviluppato da BlackBerry), Autosar (è una piattaforma software aperta e standardizzata per le ECU automobilistiche) e deve avere esperienza in Security e On Board Diagnosis. Si tratta di competenze molto diverse da quelle tradizionali degli Oem e indicano una delle strade – un team/divisione interno – che si possono percorrere per creare in-house un software automotive. Un’altra possibilità è stata esplicitata da Michele Bertoncello citando il fatto che «c’è un grande movimento di partnership e M&A, che vede le software house automotive ‘scandagliate’ dagli Oem e anche dai componentisti auto Tier 1 perché dispongono di soluzioni tecniche e/o competenze necessarie, portate da profili professionali altamente qualificati e valuable. Estremizzando, se un tempo si cercavano i migliori telaisti e motoristi, oggi si cercano i migliori sviluppatori software per creare vera differenziazione. Il software dei costruttori ”attackers” ha contribuito a creare un’esperienza rivoluzionaria per i guidatori e i passeggeri, diventando un vero fattore critico di successo».

 

Sviluppare il software o acquistarlo?

Mercedes Benz cockpit interior details cabin

Esistono però esempi di operating system automobilistici sviluppati da aziende specializzate, ad esempio Apex.Os sviluppato da Apex.Ai, azienda con sedi a Monaco di Baviera e Palo Alto. Apex.Ai ha avuto finanziamenti da Volvo Trucks e Jaguar Land Rover, ha stretto accordi con Toyota e notiamo che Apex.Os deriva, con gli adattamenti per impieghi safety critical, da Ros, un software open source dedicato alla robotica. Un altro produttore è Green Hill Software, che però sviluppa soluzioni più settoriali, come i domain controller, gateway sicuri e strumentazione virtuale su display. Allo stesso modo segnaliamo Nvidia Drive Os, un sistema operativo studiato per applicazioni di guida autonoma; ricordiamo che alcuni profili cercati da Cariad implicavano la conoscenza delle librerie Cuda di Nvidia. Anche il gruppo Continental è della partita tramite la controllata Elektrobit, che propone diverse suite di software compresa EB xelor, una piattaforma di sviluppo pensata per architetture con pochi processori potenti che possono sostituire le tante “centraline” delle architetture odierne. Una soluzione del genere, ossia l’acquisto di software automotive da un fornitore esterno, può essere praticabile per un Oem?

Secondo Bertoncello «un Oem può pensare di avere un suo software automobilistico facendo accordi con una software house. La natura del software automobilistico, molto complesso, enfatizza quella che è la struttura dei costi del software in generale: sviluppo e integrazione molto onerosi e costo di deployment piuttosto basso. Una simile technology cost structure permetterebbe a un player di avere successo in queste applicazioni solo a patto di avere una scala molto grande e la capacità di proporre soluzioni a costi competitivi e con la flessibilità richiesta dall’Oem». In generale è importante prendere tempestivamente una decisione make-or-buy riguardo al software automobilistico. Un grande costruttore può pensare di sviluppare tutto in casa, anche con acquisizioni. Una realtà meno strutturata può invece trarre vantaggio da accordi con sviluppatori esterni, avendo cura di mantenere ‘punti di controllo’, comprese eventuali proprietà intellettuali. Volvo, per esempio, non è un costruttore di grandi dimensioni ma alla fine di giugno ha annunciato di star sviluppando un suo operating system, il VolvoCars.Os. È studiato per le Volvo elettriche e incorporerà i sistemi operativi già presenti, anche sul cloud, quali Android Automotive Os, Qnx, Autosar e Linux. In parallelo si procede allo sviluppo di una piattaforma computazionale centralizzata, basata su hardware Nvidia, dotata di tre computer che si supportano a vicenda in caso di errore. Normalmente si dividono i compiti dell’elaborazione della visione e dell’intelligenza artificiale, dell’infotelematica e dell’infotainment. Volvo probabilmente può fare questo passo, i cui primi frutti si vedranno nel 2022, perché fa parte del grande gruppo cinese Geely.

L’architettura elettrica ed elettronica dei veicoli cambierà profondamente. Fonte McKinsey

Fronteggiare la scarsità della ‘risorsa’ software

Notiamo come anche i fornitori Tier 1 stiano entrando in partita. ZF, per esempio, propone un middleware, ossia un “mediatore” controllato dal sistema operativo che si occupa della comunicazione delle funzioni software, come la app, ai componenti hardware. Il noto componentista auto promette così di ridurre lo sforzo che le case automobilistiche devono fare per integrare sistemi sempre più complessi nel veicolo. A proposito di Tech Giant, Michele Bertoncello si è detto scettico sulla possibilità che possano acquisire qualche Oem e ritiene che essi abbiano “forse non del tutto considerato le difficoltà del mettere in strada i veicoli, oggetti safety critical e che devono quindi sottostare a requisiti stringenti. I player tecnologici, abituati alla maggiore dinamicità del loro segmento, si sono trovati di fronte a requisiti di sicurezza ben diversi. Software e cybersecurity saranno sempre più importanti: già oggi la sicurezza dei veicoli autonomi con Sae Level 2 e 3 dipende direttamente dal software”. Nella ricerca The case for an end-to-end automotive software platform McKinsey aveva previsto uno shortage del software perché le capacità degli sviluppatori erano previste essere non corrispondenti alle richieste dettate dalla complessità.

Zf, importante componentista auto Tier 1, propone un suo Middleware, una sorta di ‘mediatore’ fra hardware e software. È un prodotto decisamente nuovo per un fornitore tradizionale. Fonte McKinsey

Michele Bertoncello vede «sforzi rinnovati, sia nel riuscire a trovare talenti per aumentare le capabilities interne sia nell’attivare partnership con aziende specializzate. C’è una richiesta di talenti senza precedenti nel settore automotive, la maggior parte dei quali attinenti al software piuttosto che ai domini tecnologici tradizionali. Vediamo università e centri ricerca predisporre borse di studio, corsi di laurea e dottorati in software automotive. Il problema della scarsità non si è certo risolto, ma importanti Oem si stanno attrezzando, imparando anche dai loro errori. Ogni nuova tecnologia implica una fase di apprendimento e questo è inevitabile in ogni settore industriale». La progressiva adozione di software centralizzato può comunque aiutare a superare il già citato gap fra richiesta e produzione di software. Infatti «la creazione di un software stack integrato può limitare la complessità anche se la quantità di elettronica aumenterà – basti pensare alla guida autonoma – e quindi la soluzione è da una parte ridurre strutturalmente la complessità, dall’altra è condividere i costi di sviluppo. Sappiamo infatti che se lo sviluppo di un software è costoso, il costo marginale del suo trasferimento a un dispositivo è limitato ai soli costi di integrazione».

 

Integrazione verticale? Qualcuno ci pensa

La scheda di controllo dell’Autopilot con, in evidenza, i processori marchiati Tesla e, sulla destra, gli ingressi per i molti sensori necessari per il suo funzionamento. È un esempio dell’intgerazione verticale voluta da Elon Musk

Abbiamo visto che è possibile, almeno in linea di principio, acquistare un sistema operativo automotive da un fornitore, come si può fare per un qualsiasi componente meccanico. Michele Bertoncello ha però evidenziato come alcuni costruttori stiano intraprendendo una strada diversa: «’Integrazione verticale, disegno “in house” del software proprietario, minimizzazione degli extracosti (armonizzazione, debugging e simili), offerta al consumatore di interfacce e funzionalità migliori con standard di cybersecurity superiori. In effetti, partendo da un disegno complessivo, i costi – materie prime, ricerca e sviluppo, di hardware e software – diminuiscono in maniera sensibile. Grazie a queste architetture, alcuni costruttori stanno ottenendo risparmi estremamente rilevanti da riduzione di cablaggi in vettura, e un risparmio in questo settore è molto importante in un momento denso di breakthrough tecnologici e di rincari nelle materie prime». Nella ricerca When code is king: Mastering automotive software excellence i ricercatori di McKinsey hanno creato uno schema operativo per lo sviluppo del software, basato su 4 dimensioni: Quale software è sviluppato, Dove è sviluppato, Come è abilitato il suo sviluppo e Come è sviluppato.

Ci chiediamo: è questa l’unica ricetta possibile? Per Bertoncello la questione «parte da alcune domande: Come definiamo un Oem? Quali sono le sue capabilities più critiche? Il software automotive ha ormai un peso rilevante sulla bill of material della vettura ed è così importante che può persino ritardare il lancio di un modello. Da questo punto di vista è indubbiamente una core capability dell’Oem, che deve quindi possedere e gestire in maniera proattiva, una concezione alla quale ci si sta avvicinando da poco. Che lo si sviluppi in casa o tramite alleanze con software house esterne, il software determinerà la competitività dei costruttori. Definirà inoltre la qualità dell’esperienza “on-board”, un aspetto che nelle nostre ricerche emerge come molto importante per gli automobilisti. È una capability che sarà critico possedere e i costruttori che non la svilupperanno soffriranno di uno svantaggio competitivo strategico». La posta in gioco è alta: secondo le stime della ricerca Automotive software and electronics 2030 al 2030 il valore del software auto dovrebbe raggiungere i 34 miliardi di dollari, un valore doppio rispetto al 2020. I vari Cagr della decade sono molto differenti, con quello di powertrain e chassis pari all’1% e quello del gruppo infotainment, connettività, servizi connessi e cybersecurity stimato al 9%. Il software legato al body control e alla gestione energetica crescerà del 10% mentre i gruppi Adas/guida autonoma e Sistemi operativi e middleware avranno incrementi composti annui dell11%. Scorporando il mercato complessivo del software auto nelle componenti integrazione, e sviluppo delle funzioni vediamo che il Cagr maggiore – 10% – spetta alle ultime 2 voci ma anche l’integrazione crescerà con un tasso annuo composto del 9%. Al 2030 su un totale di 84 miliardi di dollari 50 deriveranno dallo sviluppo delle funzioni, 24 da validazione/verifica e i restanti 10 dall’integrazione.

[Ripubblicazione dell’articolo pubblicato il 30 luglio 2021]














Articolo precedenteTutto sul piano industriale da 60 miliardi di Mercedes. Parla il ceo Italia
Articolo successivoAgrati si trasforma per cogliere l’opportunità dell’elettrificazione






LASCIA UN COMMENTO

Per favore inserisci il tuo commento!
Per favore inserisci il tuo nome qui