La complessità ampliata delle piattaforme automobilistiche

I veicoli moderni si sono evoluti da sistemi meccanici controllati da semplici microcontrollori in piattaforme di calcolo distribuite in esecuzione su decine di unità di controllo elettroniche (ECU). I veicoli di fascia alta contengono oggi oltre 100 milioni di linee di codice che spaziano da sistemi operativi multipli, pile middleware e strati di applicazione. Questo software funziona su hardware zona eterogeneo - da microcontrollori a basso costo che gestiscono gli ascensori di finestre a sistemi ad alte prestazioni (SoCs) essione

Domini di elaborazione eterogenei

Un'architettura del veicolo può integrare i microcontrollori (MCU) che eseguono AUTOSAR Classic, SoC ad alte prestazioni con GPU incorporati per l'inferenza dell'AI, e gli array di gate programmabili del campo (FPGA) per l'elaborazione del segnale a bassa latenza.

Stack software multi-strato

La complessità dei sistemi automobilistici si estende su più livelli di astrazione. Alla base, un sistema operativo in tempo reale (RTOS) o un ipervisor gestisce risorse hardware e applica gli strumenti di sicurezza e l'isolamento temporale.

Concorrenza e Funzionalità Distribuita

Un'unica manovra, come un cambio automatico della corsia, richiede il coordinamento tra i sensori di percezione, un'unità di pianificazione centrale, gli attuatori di sterzo di potenza e il controllo della stabilità elettronica.Questi componenti comunicano su sistemi di bus eterogenei tra cui CAN FD, FlexRay, e l'Ethernet automobilistico con Time-Sensitive Networking (TSN).

Le norme di sicurezza funzionale e di sicurezza informatica costituiscono la colonna portante della verifica integrata nel settore automobilistico. Norme come ISO 26262] per la sicurezza funzionale e ISO 21434] per la sicurezza informatica definiscono cicli di vita di sviluppo completi che richiedono analisi, progettazione e attività di verifica rigorose.

Profondità della verifica ASIL D

I sistemi assegnati al più alto livello di integrità della sicurezza automobilistica (ASIL D), come i modelli di sterzata o freno-by-wire, richiedono la verifica più rigorosa. Gli ingegneri devono dimostrare che le metriche di singolo punto e latente di errore superano le soglie definite (ad esempio, > 99% di copertura per i guasti a punto singolo).

Costruire un caso di sicurezza coerenti

Oltre ai test, ISO 26262 richiede la creazione di un caso di sicurezza, un argomento strutturato che il sistema è accettabile e sicuro. Questo argomento deve essere supportato da prove, tra cui analisi dei rischi, specifiche del sistema, documenti di progettazione e report di verifica.

Indirizzare la sicurezza della funzionalità intensa (SOTIF)

I sistemi di analisi dei rischi basati su Intended (SOTIF) si estende al di là dei guasti hardware per affrontare le limitazioni della funzionalità stessa. Ciò è particolarmente rilevante per i sistemi che si basano sull'apprendimento automatico o sull'elaborazione di sensori complessi. Ad esempio, un sistema di rilevamento pedonale può non rilevare una persona che indossa un abbigliamento insolito, non a causa di un guasto hardware, ma perché i dati di formazione non coprono tale scenario.

Integrazione hardware-software e Co-Verificazione

L'interfaccia tra hardware e software è una fonte persistente di bug sottili e catastrofici. Un registro del firmware non configurabile, un transiente di tensione non gestito che corrompere una lettura del sensore, o un evento di limitazione termica che sposta il tempo di esecuzione può portare a guasti che rimangono nascosti fino a quando il sistema non è operativo nel campo.

La catena di verifica MIL, SIL e HIL

Il software di controllo di HLT-in-the-Loop (MIL) si concentra sulla correttezza dell'algoritmo di controllo all'interno di un ambiente di impianto simulato. Il software di prova di software in-the-Loop (SIL) esegue il codice di produzione su un computer host, consentendo il test di regressione ad alta produttività.

Piattaforme virtuali per l'integrazione precoce

Per spostare la verifica in precedenza nel ciclo di sviluppo, gli OEM e i fornitori stanno adottando sempre più piattaforme virtuali. Questi sono modelli software della scheda hardware completa che possono eseguire il codice completo di destinazione prima che il silicio fisico è disponibile. Le piattaforme virtuali consentono il riplay deterministico delle interazioni complesse e supportano i test automatizzati su larga scala. La sfida è ottenere una sufficiente fedeltà nel modello, i modelli di temporizzazione inesatti dei controller di memoria, cache o arbiter di bus possono mascherare hardware.

Verifica dell'interfaccia e dell'integrità segnale

Le interfacce hardware-software sono definite dai registri mappati dalla memoria, dalle linee di interruttori e dalle regioni di memoria condivise. Le strutture di dati dismesse, le condizioni di gara sui buffer condivisi e la sincronizzazione improprio spesso solo la superficie in specifici interleaving di eventi hardware e software.

Garantire il comportamento in tempo reale deterministico

Le funzioni critiche alla sicurezza impongono requisiti di tempismo rigorosi, spesso misurati in microsecondi. Una scadenza mancante per un comando di intervento frenante è una violazione della sicurezza. Verificare che il sistema soddisfa tutti i vincoli di tempismo in condizioni peggiori è uno degli aspetti più impegnativi della verifica incorporata nel settore automobilistico. La tendenza verso processori multicore complica ulteriormente l'analisi dei tempi a causa della soddisfazione per le risorse condivise.

Tempo di esecuzione peggiore (WCET)

I processori moderni con le tubazioni profonde, la previsione di branch e le cache condivise rendono estremamente difficile l'esecuzione del tempo strettamente. L'analisi dei tempi basati sulla misurazione dipende dalla qualità dei vettori di prova utilizzati; i casi patologici possono essere mancati.

Verificare il tempo e la partizione dello spazio

Le architetture integrate che combinano funzioni di criticità diverse sullo stesso hardware si basano su un solido partizionamento. L'hypervisor o il sistema operativo deve garantire che un'attività non critica non possa ritardare o corrompere un'attività critica alla sicurezza. La verifica del partizionamento comporta la dimostrazione di risorse condivise, memoria, tempo della CPU, cache e larghezza di banda del bus, sono adeguatamente assegnate e verificate.

Verifica del temporizzazione formale

I metodi formali come i timed automata e il controllo dei modelli sono sempre più applicati alla verifica in tempo reale. Strumenti come UPPAAL] consentono agli ingegneri di modellare i modelli di attivazione delle attività, la condivisione delle risorse e le latencies di comunicazione. Il modello può quindi essere controllato esaustivamente per verificare che le proprietà di scadenza siano in possesso di tutti i possibili percorsi di esecuzione.

Verifica della sicurezza informatica per veicoli collegati

L'integrazione della comunicazione V2X (V2X) del veicolo a tutto tondo, gli aggiornamenti over-the-air (OTA) e i servizi basati su cloud hanno notevolmente ampliato la superficie di attacco dei veicoli moderni. La verifica della sicurezza informatica è ora un'attività obbligatoria guidata da standard quali ISO 21434 e Regolamento delle Nazioni Unite R155.

Modellazione e valutazione del rischio

La verifica inizia con un'analisi sistematica delle minacce e della valutazione del rischio (TARA). Questo processo identifica i beni, gli attori delle minacce e i vettori di attacco, che portano alla specifica dei requisiti di sicurezza. I requisiti comuni includono avvio sicuro, aggiornamento firmware sicuro con la protezione del rollback, monitoraggio dell'integrità del runtime e canali di comunicazione sicuri.

Modulo di sicurezza hardware Co-Verificazione

Molti sistemi automobilistici si affidano a un modulo di sicurezza hardware (HSM) per gestire le chiavi crittografiche e fornire servizi sicuri. La verifica di HSM non è mai esposta al di fuori del confine HSM, che le operazioni crittografiche vengono eseguite correttamente e che il HSM risponde adeguatamente agli attacchi di iniezione di errori. Ciò richiede un coordinamento stretto tra la verifica hardware (assicurando che il HSM sia correttamente progettato) e la verifica del software (permettendo i driver e il codice di applicazione HSM).

Convalida della sicurezza del ciclo di vita

A differenza della sicurezza funzionale, la sicurezza informatica non è una proprietà statica. Le nuove vulnerabilità vengono scoperte continuamente e il veicolo deve essere protetto durante tutta la sua vita. Ciò significa che la verifica non è un evento di una volta. Ogni aggiornamento OTA deve essere verificato per garantire che non introduca nuove vulnerabilità e che non rompe i meccanismi di sicurezza o di sicurezza esistenti.

Sfide di verifica incrociate

Oltre alle sfide specifiche del dominio, diverse questioni di taglio trasversale riguardano tutti gli aspetti della verifica integrata nel settore automobilistico, che richiedono strategie olistiche che abbracciano discipline ingegneristiche e confini organizzativi.

Qualifica e fiducia degli strumenti

Gli strumenti di verifica possono introdurre errori. Un bug compilatore, uno strumento di analisi statica che manca una violazione, o un'imbracatura di prova HIL che interpreta male un segnale può tutti portare a conclusioni errate sulla correttezza del sistema. ISO 26262 richiede che gli strumenti siano classificati per il loro impatto potenziale (Tool Confidence Level) e che gli strumenti classificati come TCL1 richiedono la qualifica per i livelli più elevati di ASIL.

Interferenza del sistema di criticalità mista

L'integrazione di funzioni di diverse criticità sull'hardware condiviso introduce il rischio di interferenze. Una funzione non critica che genera una banda di memoria elevata può causare un compito critico della sicurezza per perdere il suo termine a causa di eviczioni della cache o di conteggio del bus. La verifica deve dimostrare, attraverso una combinazione di analisi e test dei tempi, che l'interferenza non compromette le garanzie di sicurezza.

Verifica dell'intelligenza artificiale e dell'apprendimento automatico

L'uso crescente di reti neurali profonde per la percezione e il processo decisionale presenta una sfida fondamentale di verifica. La verifica basata sui requisiti tradizionali non si applica bene alle reti apprese. Invece, gli ingegneri si affidano a database di scenari di massa, test guidati dalla copertura e metriche di robustezza.

Supply Chain e integrazione legacy

I sistemi di verifica e di verifica sono frammentati in tutta la catena di fornitura, che richiedono chiare definizioni contrattuali di attività di verifica e interfacce. I test di integrazione rivelano spesso ipotesi erronee su tempi, formati di dati o gestione degli errori. L'uso di componenti software legacy, mentre economicamente vantaggioso, porta il debito di sicurezza.

Conclusioni

La verifica dei sistemi integrati nel settore automobilistico richiede un approccio disciplinato che integra diverse metodologie tecniche e procedurali. Le sfide riguardano la complessità dell'hardware, la convalutazione in tempo reale, la sicurezza e la sicurezza, e le frontiere emergenti della funzionalità basata sull'intelligenza artificiale. Queste sfide sono profondamente interconnesse: una soluzione di sicurezza può alterare il comportamento in tempo reale, un cambiamento hardware può invalidare un caso di sicurezza e un aggiornamento software può introdurre nuove condizioni di attivazione per SOTIF