Quando NVIDIA ha presentato il suo concetto “Guardian Angel” per le auto a guida autonoma, l’idea sembrava quasi troppo semplice: accanto all’intelligenza artificiale potente e complessa che guida davvero l’auto, far girare un secondo software, molto più piccolo e molto più prevedibile, il cui unico compito è sorvegliare il primo e frenare bruscamente se inizia a fare qualcosa di pericoloso. Non è un’idea esclusiva di NVIDIA — con nomi diversi, questa struttura a due livelli è vicina al modo in cui la maggior parte dei sistemi seri di guida automatizzata e assistita avanzata affronta il problema che terrorizza gli ingegneri più di qualsiasi singolo guasto a un sensore: un’intelligenza artificiale che prende una decisione sicura di sé, netta, e sbagliata.
Perché un solo sistema, per quanto intelligente, non basta
Lo stack di intelligenza artificiale che percepisce la strada, prevede cosa farà il traffico circostante e pianifica un percorso — la stessa pipeline “sense, think, act” che abbiamo trattato in una serie dedicata — è necessariamente complesso: reti neurali profonde addestrate su enormi quantità di dati, che prendono decisioni probabilistiche in situazioni che nessun ingegnere ha programmato esplicitamente. Quella complessità è esattamente ciò che lo rende potente, ed esattamente ciò che lo rende difficile da certificare come sicuro con i metodi tradizionali. Un sistema di sicurezza classico (ad esempio il pilota automatico di un aereo) può spesso essere testato in modo esaustivo e dimostrato formalmente corretto perché la sua logica è esplicita e limitata. Un sistema di percezione o pianificazione basato su deep learning, al contrario, è una scatola nera addestrata su esempi — brillante nel generalizzare a situazioni simili a quelle imparate, imprevedibile nelle situazioni rare che cadono fuori da quell’insieme. Regolatori e ingegneri sono arrivati alla stessa risposta: non cercare di rendere l’intelligenza artificiale principale dimostrabilmente perfetta. Al contrario, avvolgerla in un secondo strato indipendente — volutamente abbastanza semplice da poter essere verificato formalmente — il cui unico compito è decidere, momento per momento, se l’output del sistema principale sia sicuro da eseguire.
Come funziona davvero il supervisore
Uno strato di supervisione della sicurezza in genere non cerca di guidare meglio dell’intelligenza artificiale principale — cerca di sapere meno, di proposito, e di avere ragione su quel poco. Verifica l’azione proposta dal sistema principale (un angolo di sterzata, una richiesta di frenata, un cambio di corsia) rispetto a un insieme di regole rigide e spiegabili e a limiti fisici: l’auto sta per superare una distanza di sicurezza dal veicolo che precede, invadere una corsia occupata, superare l’aderenza disponibile su quella strada, o ignorare un sensore appena diventato cieco? Se la risposta è sì, il supervisore non cerca di aggirare astutamente il problema — costringe l’auto a una manovra a rischio minimo: una decelerazione controllata, un raddrizzamento dello sterzo, una sosta sicura in corsia d’emergenza. È anche per questo che le architetture di supervisione della sicurezza si appoggiano così tanto sulla ridondanza hardware e software, lo stesso principio fail-operational dietro i percorsi sterzo e frenata doppi e fisicamente separati di cui parliamo nel nostro articolo sul servosterzo — un supervisore che condivide un’alimentazione o un processore con il sistema che dovrebbe controllare non è davvero indipendente.
Niente di tutto questo è esclusivo di un singolo marchio. È la risposta pratica a un problema di certificazione che l’intero settore condivide: come si dimostra che un’auto è sicura da vendere quando il suo principale sistema decisionale è, per natura, non dimostrabile nel senso tradizionale? Non si cerca di dimostrare che l’intelligenza artificiale è perfetta — si dimostra che il cane da guardia lo è, e si lascia che il cane da guardia faccia l’unica cosa che è abbastanza semplice da poter garantire: fermare l’auto in sicurezza quando non è sicuro di sé.
La ricerca UE: dall’hardware fail-operational all’IA certificabile
La ricerca finanziata dall’UE su questo esatto problema copre due generazioni, distanti circa un decennio, perché la sfida di fondo è cambiata insieme ai sistemi di intelligenza artificiale principali — dal software di controllo embedded convenzionale al deep learning.
- AutoDrive (2017-2020, €16,16M di contributo UE, coordinato dalla tedesca Infineon Technologies, nell’ambito della Joint Undertaking ECSEL — la partnership UE/stati/industria sui componenti e sistemi elettronici, non un progetto CCAM o 2Zero) ha posto le basi hardware e di architettura di sistema su cui poggia tutto questo approccio. Ha riunito i principali produttori europei di semiconduttori, fornitori Tier-1, case automobilistiche e istituti di ricerca per progettare componenti e architetture elettroniche fail-aware, fail-safe e fail-operational — gli strati ridondanti di hardware e software, comuni ai livelli SAE 3-5, che permettono a un’auto di mantenere abbastanza controllo dopo il guasto di un componente da raggiungere uno stato a rischio minimo invece di perdere semplicemente ogni funzione.
- SAFEXPLAIN (2022-2025, €3,89M, coordinato dal Barcelona Supercomputing Center nell’ambito del Cluster 4 di Horizon Europe per Digitale, Industria e Spazio — una destinazione generalista, non una partnership specifica per l’automotive) affronta direttamente la metà più recente del problema: come si certifica un sistema di deep learning rispetto agli standard di Sicurezza Funzionale (FUSA) quando la sua logica non è codice esplicito da leggere, ma pesi appresi dai dati? Il progetto ha sviluppato metodi per rendere il software di deep learning spiegabile e tracciabile abbastanza da dimostrare, a soddisfazione di un ente di certificazione, che soddisfa realmente i propri requisiti di sicurezza — con l’automotive come uno dei tre casi di studio industriali insieme a spazio e ferrovia, lavorato assieme allo specialista di sicurezza funzionale IKR e al partner di piattaforma BSC stesso.
Insieme, i due progetti racchiudono l’intero problema: AutoDrive ha costruito l’hardware ridondante e l’architettura di sistema di cui uno strato di supervisione ha bisogno per agire fisicamente in modo indipendente dall’intelligenza artificiale principale; SAFEXPLAIN sta costruendo i metodi per certificare che l’IA sorvegliata, e la logica che la sorveglia, si comportino davvero come i loro progettisti dichiarano. Nessuno dei due progetti riguarda il rendere più intelligente l’IA principale dell’auto — entrambi riguardano il dimostrare, formalmente e a soddisfazione di un regolatore, cosa succede quando non lo è.
Foto: © Car-Shooters