Il concetto di veicolo autonomo o drone senza pilota ha generato recentemente molto interesse nel pubblico. Anche se l'idea appare tecnicamente plausibile, i team di sviluppo devono affrontare un compito arduo per poterla concretizzare e gli sviluppatori devono essere a conoscenza degli standard e dei passi che devono prendere per garantire la sicurezza nelle applicazioni automotive sia autonome che di altro tipo.
Gli standard in campo
Buona parte della metodologia di sviluppo per la sicurezza di autoveicoli è fortunatamente già stata formalizzata con lo standard Iso26262. Intitolato "Standard di sicurezza funzionale per veicoli su strada", questo standard è parte del più ampio standard Iso61508 "Sicurezza funzionale di sistemi Elettrici/Elettronici/Elettronici Programmabili". Pubblicato originariamente nel 2011, l'Iso26262 intende affrontare i potenziali pericoli associati ai malfunzionamenti dei sistemi elettrici ed elettronici di un veicolo. Questo standard si applica già alle funzionalità safety-critical di tutti gli attuali modelli di autovetture, non solo ai veicoli autonomi, fin da quando sono apparsi i sistemi Adas (Advanced Driver Assist System) come i rilevatori del salto di corsia che possono assumere il controllo delle principali funzioni di guida come lo sterzo e i freni.
Analisi di sicurezza e classificazione del rischio
Cosa deve fare quindi uno sviluppatore alle prese con un nuovo progetto per il software di veicoli autonomi? L'aspetto più importante del processo di sviluppo riguarda l'identificazione di tutti i requisiti progettuali e l'evidenziazione di quelli che presentano un impatto potenziale sulla sicurezza. In base a questa analisi di sicurezza si esegue quindi una mappatura che valuta la piattaforma hardware e software assegnando una classificazione di rischio Asil (Automotive safety integrity level) A, B, C o D. Asil D indica, in caso di guasto, la possibilità di conseguenze gravi o mortali che richiedono quindi il più alto grado di sicurezza. È altamente consigliabile che gli sviluppatori che non siano stati mai direttamente coinvolti nella sicurezza funzionale siano sottoposti a training specifico in modo da sapere come valutare tutti gli aspetti della sicurezza software.
Il Piano di Sicurezza Software
Il documento formale che aggrega tutte queste informazioni prende il nome di Piano di Sicurezza Software o Ssp (Software safety plan). In genere questo documento viene rivisto durante una riunione che ha lo scopo di definire una prova concettuale del sistema o Poc (Proof of concept). Architettura di sistema, moduli, requisiti e funzioni di sicurezza, critical path e diagnostica sono gli elementi delineati nel documento. La diagnostica è una parte fondamentale di qualsiasi certificazione Iso26262 e viene utilizzata per ridurre il tasso di malfunzionamento. Il Piano di Sicurezza Software non entra nei dettagli del funzionamento del software, lasciando al Documento dei Requisiti Software o Srd (Software Requirement Document) il compito di identificare le unità funzionali che gli sviluppatori dovranno creare via software. Il Piano di Sicurezza Software delinea i vari componenti software necessari. Nella maggior parte dei casi un componente fondamentale è un Rtos (Real-time operating system), la cui scelta richiede un'attenta disamina. Per esempio, gli sviluppatori devono accertarsi che l'Rtos sia conforme alla norma Iec61508. L'adozione di un software così certificato permette agli sviluppatori di fare leva sulla certificazione fornita dal produttore dell'Rtos. Il passo successivo è quello di mappare i requisiti della sicurezza del software. Come già accennato, Iec61508 è uno standard quadro mentre Iso26262 è uno standard applicativo; nel contempo, Iso26262 non eredita automaticamente la certificazione Iec61508. Un requisito minimo è quello di fornire una matrice di conformità da Iec61508 a Iso26262, ma si tratta di una soluzione non ideale quando l'obiettivo dovrebbe essere quello di ottenere formalmente la conformità Iso26262. Per fare questo occorre considerare l'intero sistema, non solo il software, e identificare tutte le funzioni (di sicurezza e non) che sono coinvolte.
Partizionamento e virtualizzazione
Un metodo basilare per ottenere un determinato livello di sicurezza è quello di stabilire una separazione temporale e spaziale delle varie funzioni per proteggere le applicazioni safety-critical dagli effetti negativi causati dalle applicazioni non critiche. Il partizionamento spaziale impedisce che i dati di una partizione possano alterare i dati o il codice di programma di un'altra partizione. Questo evita per esempio che il codice che gira nella partizione 1 possa accedere ai dispositivi di output utilizzati da un'applicazione maggiormente critica residente nella partizione 2. Le attuali Cpu a 32 e 64 bit sono dotate di Mmu (Memory management unit) capaci di supportare queste funzionalità in software. Il partizionamento temporale invece fa in modo che un'applicazione safety-critical disponga di una certa finestra di tempo garantita per eseguire ad esempio l'accesso a un processore, a una risorsa condivisa o a un dispositivo fisico mentre le applicazioni a minor criticità ne sono impedite nello stesso istante. Un modo per implementare il partizionamento temporale e spaziale è quello di utilizzare la tecnologia di virtualizzazione. La virtualizzazione, implementata su chip single-core o multi-core, permette a più applicazioni di girare all'interno di partizioni sicure e protette, separate le une dalle altre e controllate da un hypervisor. La virtualizzazione aiuta a ridurre i tempi, la complessità e i costi dello sviluppo di un sistema accelerando le procedure di test e certificazione. La virtualizzazione embedded consente inoltre agli sviluppatori di implementare il consolidamento delle Ecu (Electronic control unit) per ridurre i costi e gli ingombri dei sistemi. I normali processori embedded semplificano la combinazione di più applicazioni su un unico processore evitando l'impiego di più circuiti distinti. Eliminando più schede custom si semplifica inoltre la manutenzione. Il partizionamento aiuta ad aumentare la sicurezza di un sistema e la protezione del software dalle minacce esterne, siano esse dovute a un aggiornamento intempestivo piuttosto che a un attacco appositamente orchestrato. Ciascuna partizione può far girare il proprio firewall anziché avvalersi di un unico firewall principale che, se violato, offrirebbe all'attaccante l'accesso all'intero sistema. Se un'applicazione dovesse essere compromessa, l'intrusione si limiterebbe a un'unica partizione nella quale potrebbe essere facilmente rilevata e neutralizzata facendo così risparmiare tempo e denaro e riducendo i rischi di sicurezza. Questo evita anche che un'intrusione possa diffondersi tra i vari componenti del sistema, in particolare in caso di malware, e impedisce che gli hacker possano accedere allo stack di rete per lanciare altri attacchi o assumere il controllo remoto del veicolo. Scegliere un Rtos capace di supportare da subito il partizionamento e la virtualizzazione facilita enormemente il processo di certificazione. Per esempio, il VxWorks di Wind River è un Rtos che supporta la virtualizzazione e il partizionamento spaziale, temporale e delle risorse, ed è certificato Iec61508.
Ottenere la certificazione
Con l'avanzamento del progetto, e come accade in qualunque altro progetto software, l'intera applicazione sarà soggetta a valutazioni, test, verifiche e convalide. Una volta che tutto è stato collaudato internamente, occorre rivolgersi a un soggetto terzo indipendente per ottenere le certificazioni Iso26262 e Iec61508. Agenzie di certificazione come TÜV-Nord, Bureau Veritas e Lloyds sono alcuni esempi di questi soggetti che prendono tutti i risultati dei test, i report e gli altri documenti di supporto per Iso26262 effettuando quindi le proprie analisi dell'applicazione per decidere se il software e il relativo processo di sviluppo abbiano seguito le procedure corrette e siano quindi certificabili. L'intero processo di certificazione può richiedere diverse settimane e numerose verifiche sulla piattaforma del veicolo autonomo interessato ai test. Il percorso che conduce ai veicoli autonomi è ancora lungo. I team di sviluppo possono tuttavia iniziare già ora ad approntare le loro strategie e analizzare le considerazioni progettuali e le numerose esigenze di certificazione che li attendono. Viste le complessità delle autovetture a guida autonoma e il ruolo essenziale del software, sarà sempre più importante per i produttori automobilistici riuscire a trovare i partner adatti dotati delle competenze appropriate per aiutarli a rimanere sulla giusta strada.
