Il veicolo è ormai definito dal software? Architettura basata su domini e trasformazione SDV

Tecnologie per veicoli elettrici
Creazione: 14 Ottobre 2026

Un'architettura che riduce oltre cento unità di controllo a pochi controller zonali fa sì che l'identità dell'auto non venga più prodotta dall'acciaio, ma dal codice.

Condividi questa pagina

Sì: il comportamento, le caratteristiche e il carattere prestazionale dell'automobile moderna sono ormai definiti in primo luogo dal software. Questa trasformazione, denominata veicolo definito dal software (SDV), sposta l'architettura elettronica del veicolo dagli stack di ECU ai controllori di dominio e zonali, separando hardware e software e ridisegnando tutto, dal peso del cablaggio agli aggiornamenti OTA.

In evidenza

I veicoli odierni 100 e oltre possono contenere unità di controllo; le nuove architetture mirano a ridurre questo numero fino al 20% .
L'architettura a dominio si organizza per funzione, quella zonale per posizione fisica.
Nella topologia zonale si utilizzano CAN XL (fino a 20 Mbps) e backbone ad alta larghezza di banda come Ethernet gigabit.
L'aggiornamento OTA è una capacità fondamentale dell'SDV resa possibile dalla separazione hardware-software.
La transizione è graduale: il primo ambito è il dominio della carrozzeria (body); ADAS, powertrain e telaio possono rimanere più a lungo nella struttura esistente.

Cos'è Esattamente un Veicolo Definito dal Software?

La definizione è chiara: un veicolo definito dal software è un veicolo le cui funzionalità e il cui comportamento sono determinati in primo luogo dal software piuttosto che dall'hardware. Nell'automobile tradizionale una caratteristica era definita da un componente hardware prodotto appositamente per quella funzione; nell'SDV lo stesso hardware può assumere funzioni diverse grazie al software che vi viene eseguito. Anche dopo la vendita del veicolo è possibile aggiungere nuove funzionalità, calibrare il comportamento e correggere gli errori da remoto.

Le architetture E/E odierne sono costituite da 100 e più unità di controllo; le strutture di nuova generazione consentono un risparmio fino al 20% nel numero di unità di controllo e fino al 10% in materiali e hardware.
Bosch Mobility, valutazione dell'architettura E/E

Le cifre contenute in questa frase riassumono la scala della trasformazione. Il problema non è solo il numero di unità di controllo: ogni ECU porta con sé il proprio cablaggio, il proprio stack software e il proprio carico di validazione. La visione dell'SDV è trasformare questa struttura frammentata in un sistema in cui il software possa essere gestito come un unico livello coerente. Per questo è necessario ripensare da zero l'architettura elettronica.

Dagli ECU all'Architettura a Dominio: Raggruppamento per Funzione

L'epoca in cui ogni piccola funzione di un'automobile disponeva di una propria unità di controllo elettronico (ECU) ha reso ingestibili i fasci di cablaggio. L'architettura a dominio è stata la prima risposta sistematica a questo problema: organizza l'elettronica del veicolo in grandi aree funzionali come ADAS, infotainment, powertrain, elettronica della carrozzeria, telaio e sicurezza. Ogni dominio dispone in genere del proprio processore, del proprio stack software, della propria interfaccia di comunicazione, dei propri sensori e attuatori, ed è gestito da un controller di dominio.

Questa struttura ha fornito una significativa semplificazione rispetto al caos degli ECU. Tuttavia, man mano che l'obiettivo dell'SDV cresceva, sono emersi i limiti dell'architettura a dominio. In particolare, i dati dei sensori generati dalle funzioni autonome hanno spinto la larghezza di banda delle classiche reti CAN ai suoi limiti. Inoltre, il fatto che ogni dominio portasse con sé le proprie risorse di elaborazione ha lasciato il fascio di cablaggio complesso e ha reso difficile la scalabilità del software su tutto il veicolo.

Architettura Zonale: L'organizzazione passa dalla funzione alla posizione

La logica dell'architettura zonale rovescia il paradigma: raggruppa l'elettronica non in base alla funzione, ma in base alla posizione fisica nel veicolo. Il veicolo viene suddiviso in zone come anteriore sinistra, anteriore destra, posteriore sinistra, posteriore destra e abitacolo; in ogni zona un controllore zonale raccoglie i sensori, gli attuatori e la distribuzione di potenza di quella zona e li collega alle piattaforme di elaborazione centrali ad alte prestazioni.

Caratteristica	Architettura a domini	Architettura zonale
Principio di organizzazione	In base alla funzione (powertrain, ADAS, carrozzeria...)	In base alla posizione fisica (anteriore sinistra, posteriore destra...)
Risorse di elaborazione	Elaborazione specifica per dominio	Elaborazione centrale consolidata/distribuita
Cablaggio	Fascio di cavi complesso e lungo	Cablaggio e peso ridotti
Numero di ECU	Numerose ECU	Pochi controllori zonali + computer centrale
Flessibilità software	Difficile da scalare per le SDV	Elevata flessibilità software

I vantaggi sono concreti e misurabili: il peso del fascio di cavi diminuisce, le connessioni punto-punto si riducono e gli sforzi di verifica dell'architettura del veicolo e dei sistemi si semplificano. Soprattutto, le progettazioni di sensori e attuatori diventano indipendenti dal nodo di elaborazione centrale; così i cicli di aggiornamento di hardware e software si separano e una progettazione di sensore può essere utilizzata su più generazioni di veicoli.

Che cosa fa il Controllore Zonale? Ripartizione dei compiti e relazione con l'hardware

Zonal mimaride kablolar kısaldıkça araç hafifler, sigortalar yerini yarı iletken anahtarlara bırakır ve güç artık bölge bölge yönetilir.

La chiave dell'architettura zonale è il controllore zonale, responsabile del collegamento di numerosi attuatori e sensori all'ECU di elaborazione centrale. Questo controllore non è solo una scatola di raccolta dati; può eseguire al proprio interno cicli di controllo in tempo reale, gestire i dispositivi della propria zona e inviare al backbone traffico filtrato e prioritizzato. Secondo una valutazione ingegneristica di fonte TI, l'MCU del modulo zonale deve offrire elevate prestazioni in tempo reale, ampia memoria, supporto alla virtualizzazione per diversi livelli ASIL, comunicazione ad alta velocità verso il backbone e numerose interfacce periferiche a basso costo come CAN FD e LIN.

Come si decentralizza la distribuzione di potenza?

Nell'architettura a domini la potenza viene distribuita da scatole centrali di distribuzione contenenti fusibili e relè. Nella struttura zonale la distribuzione si decentralizza: un unico fascio di potenza viene tratto dalla batteria verso la zona e il modulo zonale ripartisce la potenza ai moduli di quella zona. Cavi di potenza corti significano direttamente risparmio di peso e costi. Inoltre ai fusibili subentrano fusibili intelligenti a semiconduttore; gli switch del lato alto con caratteristica I²t garantiscono minore variabilità dei fusibili e sezioni dei cavi più ottimizzate. La scatola intelligente di distribuzione di potenza, composta da MCU, switch del lato alto e transceiver, diventa un'unità la cui configurazione si effettua via software: la stessa scatola può essere utilizzata in ogni zona, adattandola al carico.

Separazione dell'I/O fisico e logico

Il modulo zonal riduce la complessità del cablaggio unendo le funzioni logiche di ingresso/uscita di più ECU in un unico punto, mentre le posizioni fisiche di sensori e attuatori restano invariate. Un passo avanti, i dispositivi periferici diventano "intelligenti": il circuito locale conserva le informazioni di stato ed esegue la diagnosi dei guasti. Protocolli semplificati come CAN FD Light possono addirittura eliminare la necessità di una MCU separata in alcuni nodi periferici. Questa separazione, in cui l'hardware resta fisso e il compito è definito dal software, è la spina dorsale ingegneristica dell'SDV.

Bus di dati nel veicolo zonal: larghezza di banda, temporizzazione e sicurezza informatica

La fusione dei sensori e i carichi di lavoro dell'AI rendono obbligatorio costruire la topologia zonal su dorsali ad alta larghezza di banda: PCIe, fino a 20 Mbps CAN XL, che raggiunge velocità di dati di e mantiene la compatibilità con il CAN esistente, ed Ethernet gigabit. La vera sfida va oltre la larghezza di banda: riguarda la temporizzazione; i brevi messaggi di controllo, i dati dei sensori ADAS e il traffico dell'infotainment hanno requisiti di latenza, jitter e sincronizzazione molto diversi tra loro. In termini indicativi: obiettivi di latenza a livello di millisecondo per l'audio e a livello di microsecondo per la trasmissione di potenza e il controllo del telaio.

Per trasportare queste diverse classi di traffico su un'unica rete si impone il Time-Sensitive Networking (TSN) basato su Ethernet. Standard come la sincronizzazione del tempo (IEEE 802.1AS), lo shaping del traffico sensibile al tempo (802.1Qbv), il traffico express (802.3br), il frame pre-emption (802.1Qbu) e la ridondanza (802.1CB) garantiscono latenza deterministica per i dati critici. Sul fronte della sicurezza contano il supporto a ISO 26262, i percorsi di comunicazione ridondanti, la partizione di sicurezza e il rilevamento dei guasti; sul fronte della sicurezza informatica sono determinanti lo standard ISO/SAE 21434, le normative UNECE e meccanismi di crittografia-autenticazione di basso livello come MACsec. Poiché l'architettura zonal centralizza le reti, anche i metodi di attacco basati su Ethernet diventano attuabili; il collasso del concetto di separazione I/O-elaborazione in caso di violazione della sicurezza è un rischio da valutare singolarmente.

In che modo la separazione hardware-software rende possibile l'aggiornamento OTA?

L'aggiornamento OTA è la prima caratteristica che viene in mente nella maggior parte delle discussioni sull'SDV, ma non è di per sé una capacità: è il risultato di un'architettura. Non è possibile fornire aggiornamenti continui senza che il software sia disaccoppiato da chip specifici tramite il livello di astrazione hardware (HAL) e senza che le funzioni del veicolo siano suddivise in servizi indipendenti, riutilizzabili e a basso accoppiamento (architettura orientata ai servizi, SOA). La separazione comprende anche l'isolamento reciproco di software con diversi livelli di sicurezza.

Il significato concreto è il seguente: l'architettura a zone, con gli aggiornamenti OTA/FOTA e la connessione cloud continua, affida il controllo della manutenzione software di alto livello al produttore, spostando al contempo i cicli di controllo in tempo reale nei moduli di zona. In questo struttura si semplificano anche le messa a punto fini, come il potenziamento dei moduli non utilizzati nei veicoli elettrici. In definitiva, il software dei veicoli elettrici, al di là di essere un canale di aggiornamento, è lo strato di definizione che determina le caratteristiche del veicolo, i sistemi di sicurezza e il carattere delle prestazioni. Il veicolo comincia a assomigliare a un data center distribuito su ruote; la catena del valore si basa sul software, sulla potenza di calcolo e sull'architettura dei sistemi.

Quanto Sarà Rapida la Transizione e Basterà l'Architettura Zonale da Sola?

La transizione sarà graduale. Il dominio della carrozzeria (body), poiché contiene numerose ECU distribuite di attuatori e sensori, sarà la prima area a passare all'architettura a zone; la transizione del controllo ADAS, powertrain e telaio potrebbe richiedere più tempo a causa della sua natura critica per la sicurezza. L'evoluzione avvenuta dal 2017 nei livelli MCAL, BSW e applicativo mostra che non si tratta di un progetto tecnico, ma di un cambio di mentalità a livello di settore.

Serve anche una lettura equilibrata. L'architettura zonale riorganizza fisicamente il veicolo; il lato logico e software (SOA, HAL, sicurezza informatica) deve essere risolto separatamente - riorganizzare solo i cavi non rende un veicolo definito dal software. Anche le stime delle dimensioni del mercato cambiano sensibilmente in base alle definizioni di perimetro; le diverse cifre relative al mercato dell'architettura E/E derivano dal fatto che il mercato viene misurato in modo diverso a seconda di cosa si conteggia (solo le piattaforme di calcolo, oppure tutta l'elettronica distribuita). Inoltre, non va dimenticato che i produttori di semiconduttori e i fornitori di soluzioni, parti della transizione, sono naturalmente interessati a questa trasformazione.

Il risultato è un chiaro equilibrio ingegneristico: la definizione del veicolo tramite software è possibile solo con la coesistenza simultanea di una nuova organizzazione hardware basata su controllori di dominio e zonali, livelli software scomposti e un backbone dati deterministico e sicuro. L'aggiornamento OTA è il frutto più visibile di questa struttura integrata; la vera rivoluzione sta nel fatto che l'hardware del veicolo delega la propria definizione di missione al software.