Stai viaggiando in autostrada a 130 km/h. L’asfalto scorre rapido sotto le ruote, la musica è sottofondo, il cruise control adattivo mantiene la distanza di sicurezza. All’improvviso, il display centrale si spegne. Lo schermo diventa nero, o magari mostra un logo di caricamento. Per un secondo, il cuore salta un battito: l’auto è ancora guidabile? I freni risponderanno? Lo sterzo si bloccherà?

Nell’era delle cosiddette Software-Defined Vehicles (SDV) — veicoli il cui funzionamento è gestito prevalentemente da codice — la paura che un “crash” del software si traduca in un “crash” fisico è una delle fobie automobilistiche più diffuse. La percezione comune è che le auto moderne siano grandi smartphone con le ruote e che, se il software si blocca, l’auto smetta di funzionare.

La realtà ingegneristica, fortunatamente, è molto più complessa e decisamente più sicura. Per capire cosa succede davvero a 130 km/h quando un sistema software fallisce, dobbiamo addentrarci nell’architettura informatica delle vetture moderne, scoprendo come l’ingegneria automotive gestisce il rischio e la ridondanza per evitare la catastrofe.

L’equivoco dello “schermo nero”

Il motivo principale per cui gli automobilisti vanno in panico di fronte a un malfunzionamento software è l’incapacità di distinguere tra ciò che vedono e ciò che fa muovere l’auto. In un veicolo moderno coesistono due mondi informatici completamente separati, con compiti, risorse e livelli di affidabilità totalmente differenti:

• il mondo dell’Infotainment (IVI – In-Vehicle Infotainment): è il sistema che gestisce il navigatore, la radio, l’integrazione con Apple CarPlay o Android Auto, la climatizzazione e le schermate grafiche. Questo sistema gira su sistemi operativi complessi come Android Automotive, Linux o QNX, ed è paragonabile in tutto e per tutto al software di un tablet. Se questo software va in crash o si riavvia mentre viaggi ai 130 km/h, la mappa scompare e la musica tace. È un evento fastidioso, ma non ha alcun impatto diretto sulla meccanica del veicolo;
• il mondo dei sistemi critici (domain controllers e ECU): è la rete invisibile di centraline elettroniche che gestisce motore, trasmissione, sistema frenante (ABS/ESP), sterzo e airbag. Questi sistemi utilizzano software in tempo reale (Real-Time Operating Systems o RTOS), basati su standard industriali rigidi come AUTOSAR. Sono programmi essenziali, ridotti all’osso, progettati per non bloccarsi mai e per rispondere a ogni comando entro una finestra di millisecondi matematicamente predeterminata.

Se lo schermo al centro della plancia si spegne a 130 km/h, il motore, i freni e lo sterzo continuano a funzionare esattamente come prima, perché la centralina dell’infotainment e la centralina dell’ABS non condividono la stessa memoria né la stessa capacità elaborativa.

Software in crash: differenza fra Can bus e Ethernet

Per evitare che un bug nella gestione dello Spotify di bordo possa compromettere la risposta del pedale del freno, i costruttori utilizzano una rigorosa segregazione dei canali di comunicazione interni dell’auto. Un’auto moderna è attraversata da diverse reti dati:

• CAN bus (Controller Area Network): è lo standard storico dell’automotive. Semplice, robusto e incredibilmente affidabile, connette le centraline fondamentali. Funziona a frequenze basse ed è progettato per garantire che un messaggio ad alta priorità (come, ad esempio, quello di attivare l’ABS) arrivi sempre a destinazione, sovrascrivendo qualsiasi altra comunicazione;
• FlexRay e Automotive Ethernet: reti ad alta velocità utilizzate per i flussi di dati più pesanti, come quelli delle telecamere dei sistemi ADAS (guida assistita) o i flussi multimediali dell’infotainment.

L’isolamento tra il sistema di infotainment e la rete di controllo dinamico avviene attraverso un componente chiave chiamato gateway di sicurezza (Hardware Security Module/Gateway). Il gateway agisce come un firewall insuperabile: consente il passaggio di dati di sola lettura (ad esempio, la velocità attuale dell’auto inviata dal CAN bus allo schermo per mostrare il tachimetro), ma impedisce rigorosamente all’infotainment di inviare comandi di scrittura o controllo verso la rete dinamica dell’auto.

Anche se il software dell’infotainment venisse infettato da un virus o entrasse in un ciclo infinito (bootloop), il gateway impedirebbe a questo guasto di propagarsi verso il motore o i freni.

Sistemi ADAS e guida autonoma: cosa accade ai sensori a 130 km/h

C’è un contesto in cui il software gestisce direttamente il movimento dell’auto: la guida assistita di livello 2 (e superiore), come il mantenimento attivo della corsia e il cruise control adattivo. A 130 km/h, l’auto sta calcolando costantemente la traiettoria tramite telecamere, radar e centraline dedicate. Cosa succede se il software che gestisce l’ADAS subisce un crash improvviso?

I sistemi di assistenza alla guida sono progettati secondo la filosofia del Fail-Safe (fallimento sicuro). In presenza di un errore di calcolo, della perdita di un fotogramma dalla telecamera o di un blocco improvviso dell’algoritmo di visione artificiale, il sistema reagisce nel seguente modo:

• segnalazione immediata: il sistema emette un segnale acustico ad alta intensità e un avviso visivo (spesso una spia rossa sul quadro strumenti o sull’Head-Up Display);
• disattivazione graduale: il software non “inchioda” improvvisamente l’auto né sterza bruscamente. Al contrario, rilascia istantaneamente il controllo del motore e della sterzata al guidatore, mantenendo l’inerzia del veicolo;
• transizione al controllo manuale: il guidatore avverte un leggero cambio di resistenza sul volante e deve riprendere immediatamente il controllo attivo.

In termini di fisica del veicolo, a 130 km/h un disimpegno improvviso dell’ADAS equivale a disinserire il cruise control: l’auto continua a proseguire dritta per inerzia mentre la velocità inizia lentamente a scendere per via dell’attrito dell’aria e del freno motore, dando al conducente tutto il tempo di rimettere le mani sul volante e i piedi sui pedali.

Nulla nel software di un’automobile è lasciato al caso o alla sensibilità dello sviluppatore. L’intero processo di progettazione informatica automotive è regolato dallo standard internazionale ISO 26262 (Functional Safety). Questa normativa definisce i livelli ASIL (Automotive Safety Integrity Level), classificando ogni funzione software da un livello A (rischio minimo) a un livello D (rischio massimo/mortale).

Il software classificato come ASIL D deve rispettare tassi di tolleranza all’errore infinitesimali. Per certificare un software ASIL D, i codice deve essere scritto con linguaggi e sottoinsiemi di regole rigidi (come MISRA C/C++), che vietano funzioni matematiche indefinite, allocazione dinamica della memoria e qualsiasi elemento che possa causare un memory leak o un crash improvviso.

Inoltre, il software ASIL D è affiancato da un componente hardware chiamato Watchdog Timer. Si tratta di un contatore elettronico indipendente: il software di bordo deve inviargli un segnale continuo ogni pochissimi millisecondi. Se il software si blocca e smette di inviare il segnale, il Watchdog rileva l’anomalia e forza un reset hardware istantaneo della centralina o attiva una modalità di emergenza trasparente per l’utente.

Ridondanza meccanica e “fail-operational”

L’evoluzione tecnologica ci sta portando verso vetture Drive-by-Wire o Steer-by-Wire, dove i collegamenti meccanici rigidi tra pedali, volante e ruote vengono progressivamente sostituiti o integrati da attuatori elettrici gestiti da software. A 130 km/h, se la centralina che controlla il servosterzo elettrico subisce un guasto irreversibile, entra in gioco la ridondanza, che si suddivide in:

• ridondanza meccanica (backup passivo): nella stragrande maggioranza delle auto attuali, esiste ancora un albero di sterzo fisico che collega il volante alle ruote. Se il servosterzo software smette di funzionare, lo sterzo non si blocca affatto. Diventa semplicemente “pesante”, poiché richiede l’applicazione di pura forza muscolare da parte del guidatore, identica a quella necessaria sulle auto d’epoca prive di servosterzo;
• ridondanza elettronica (Fail-Operational): Nei veicoli di fascia alta e in quelli predisposti per la guida autonoma, i sistemi critici sono doppi. Ci sono due centraline sterzo e due linee di alimentazione separate. Se la Centralina A va in crash a 130 km/h, la Centralina B prende il controllo in meno di 10 millisecondi, senza che il guidatore percepisca alcuna interruzione.

Lo stesso principio vale per l’impianto frenante: la pressione del pedale muove un circuito idraulico primario. Se il software dell’ABS/ESP crasha, l’assistenza elettronica si disattiva (accendendo le relative spie sul cruscotto), ma la pressione idraulica diretta sulle pinze dei freni rimane perfettamente attiva. L’auto frenerà esattamente come un veicolo degli anni ’80.

In sintesi, quindi, un crash software a 130 km/h è un evento indubbiamente spiacevole, ma le probabilità che si trasformi in un incidente grave dovuto alla perdita dei controlli dinamici sono estremamente ridotte. La rigida suddivisione tra infotainment e sistemi di controllo, l’isolamento della rete dati, la conformità agli standard ISO 26262 e la presenza di backup meccanici ed elettronici rendono le automobili moderne tra i macchinari più sicuri e controllati al mondo.

Ciò non significa che il passaggio al Software-Defined Vehicle sia privo di sfide. Con l’aumentare delle righe di codice — che su una vettura moderna superano ormai i 100 milioni, molto più di un Boeing 787 o di un caccia militare — la gestione dei bug diventa la priorità assoluta delle case automobilistiche.

L’introduzione degli aggiornamenti OTA (Over-The-Air) consente oggi di correggere errori del codice a distanza, migliorando costantemente la sicurezza. Ma la regola aurea dell’ingegneria automotive rimane invariata: la fisica e la meccanica avranno sempre l’ultima parola sulla protezione della vita umana.