Abbiamo già spiegato come pensa un’auto a guida autonoma — trasformando un modello percepito del mondo in un piano d’azione. Un piano, però, non è ancora un movimento: qualcosa deve trasformare “frena adesso” in una vera, fisica decelerazione dell’auto, in modo affidabile, ogni singola volta. Questo ultimo stadio della pipeline percepire, pensare, agire sembra, sulla carta, il più semplice dei tre — le auto hanno acceleratori elettronici e servosterzo elettrico da decenni — ma nasconde l’unico requisito che rende il Livello 4 fondamentalmente diverso da tutto ciò che è venuto prima: non c’è più un essere umano a correggere un errore.
Dal collegamento meccanico al comando elettronico
Abbiamo già raccontato come il servosterzo si sia evoluto dall’assistenza idraulica a un sistema completamente elettrico, e proprio quel passaggio è ciò che rende possibile l’attuazione automatizzata: una volta che sterzo, freno e accelerazione vengono comandati elettronicamente invece che tramite un collegamento meccanico o idraulico diretto agli input del guidatore, un computer può impartire gli stessi comandi che darebbero un piede o delle mani umane, senza alcuna modifica fisica all’architettura di base dell’auto. Questa famiglia di sistemi si chiama genericamente drive-by-wire, ed è lo strato di attuazione a cui arrivano davvero gli output del “pensare”.
Il fail-safe non basta più
In un’auto di Livello 2, se un attuatore di sterzo o freno ha un problema, il sistema può semplicemente restituire il controllo al guidatore, o portare l’auto a una fermata dolce con le mani del guidatore già sul volante — questo è un design fail-safe: quando qualcosa si rompe, si delega all’essere umano. Un’auto di Livello 4, per definizione, potrebbe non avere alcun essere umano attento disponibile nell’esatto momento in cui qualcosa si rompe. Questo singolo fatto impone uno standard ingegneristico completamente diverso, chiamato fail-operational: l’auto deve continuare a comportarsi in sicurezza, da sola, abbastanza a lungo da raggiungere una fermata, usando hardware degradato ma ancora funzionante, non un backup umano. In pratica, questo significa duplicare quasi tutto ciò che potrebbe mettere fuori uso l’auto se fallisse da solo: due alimentazioni elettriche indipendenti in modo che un guasto elettrico non accechi tutti gli attuatori in una volta, percorsi ridondanti di attuazione per sterzo e freno, e bus di calcolo e comunicazione ridondanti che eseguono il software di controllo stesso, in modo che un singolo componente guasto degradi la capacità dell’auto invece di eliminarla del tutto.
L’architettura conta quanto la ridondanza
Semplicemente affiancare un secondo componente al primo non basta se entrambi condividono un unico punto di guasto più a monte — un’alimentazione condivisa, un bug software condiviso, un canale di comunicazione compromesso condiviso. Questo è il motivo per cui l’architettura elettronica e software sotto l’attuazione è diventata essa stessa un problema di ricerca, non solo una distinta base hardware: come vengono partizionate le funzioni di controllo, quanto in sicurezza un sistema può essere aggiornato nel corso della sua vita senza introdurre nuovi guasti, e quanto resiste l’intera catena a un attacco informatico che altrimenti potrebbe trasformare la ridondanza in un’unica debolezza condivisa.
Dove punta lo stato dell’arte: la ricerca UE sull’architettura di controllo
La dimostrazione più completa fino ad oggi che percezione, decisione e controllo devono essere progettati come un unico sistema fail-operational connesso, non tre problemi separati assemblati insieme, è arrivata da NewControl (2019-2023, €10,91M, coordinato da AVL List in Austria, sotto la Joint Undertaking ECSEL): ha costruito piattaforme virtualizzate che coprono insieme percezione, cognizione e controllo per la guida altamente automatizzata, centrate deliberatamente sulla “sicurezza fin dalla progettazione” affinché l’intera catena, non solo i singoli componenti, potesse dimostrare di degradarsi con grazia invece di guastarsi del tutto. Due ulteriori progetti attualmente attivi affrontano la questione dell’architettura da direzioni opposte. EEA4CCAM (2025-2028, €5,99M, coordinato da Infineon Technologies in Germania, Horizon Europe partenariato CCAM) sta sviluppando un’architettura di controllo elettronico di bordo centralizzata e aggiornabile, integrando la co-progettazione di hardware e software specificamente per abilitare un funzionamento sicuro e cyber-sicuro e flussi di dati intelligenti attraverso i sistemi di controllo di un’auto. Shift2SDV (2025-2028, €19,24M — uno dei progetti singoli più grandi citati in tutta questa serie Focus — coordinato da Virtual Vehicle Research in Austria, finanziato tramite la Chips Joint Undertaking) sta costruendo lo strato software complementare su scala industriale: un framework comune di middleware e API pensato per permettere all’intera catena del valore automotive europea — costruttori, fornitori Tier-1 e specialisti software allo stesso modo — di sviluppare e aggiornare il software di controllo dei veicoli definiti dal software come moduli intercambiabili, invece che ogni azienda mantenga il proprio sistema chiuso e monolitico.
Perché conta più della scheda tecnica
Nulla della percezione o della decisione trattate nelle parti precedenti di questa serie conta se gli ultimi millisecondi — dal comando all’attuatore, dall’attuatore alla ruota — non possono essere considerati affidabili quando qualcos’altro nell’auto è già andato storto. Questo è esattamente il motivo per cui “agire” viene giudicato con uno standard diverso dal resto della pipeline: non quanto bene si comporta quando tutto funziona, ma con quanta grazia si degrada quando qualcosa non funziona, senza nessuno al volante che se ne accorga.
Foto: © Car-Shooters