HIL MIL SIL testing: come validare sistemi automotive ed aerospace

Lo sviluppo di sistemi automotive e aerospace richiede oggi una quantità sempre maggiore di attività di verifica e validazione. Software, elettronica e sistemi di controllo sono parte integrante del prodotto e testarli esclusivamente attraverso prototipi risulta costoso e poco efficiente, soprattutto nelle fasi preliminari del progetto. Per questo motivo vengono utilizzati approcci di simulazione e testing quali Model in the Loop (MIL), Software in the Loop (SIL) e Hardware in the Loop (HIL).

L’obiettivo è anticipare il più possibile le attività di verifica e validazione dei sistemi, individuando problemi prima che arrivino alle fasi di integrazione e ai test sul sistema reale.

MIL, SIL e HIL rappresentano tre livelli di verifica distinti, soprattutto per ciò che viene simulato durante il test.

Partiamo dalle definizioni che, nella pratica quotidiana, vengono spesso date per scontate.

Il model in the loop è il livello di test in cui viene verificato il modello matematico dell’algoritmo di controllo, senza che esista ancora una riga di codice e senza alcun hardware coinvolto.

Il software in the loop è il livello di test in cui viene eseguito il codice di produzione vero e proprio su una macchina host, mantenendo simulato il sistema fisico.

L’hardware in the loop è il metodo di test in cui il software viene eseguito sulla centralina reale, collegata a un simulatore che riproduce in tempo reale il comportamento del resto del sistema.

Il Model in the Loop viene generalmente utilizzato nelle prime fasi dello sviluppo. L’obiettivo è verificare il comportamento dell’algoritmo senza avere un SW definitivo o l’HW di riferimento (algoritmo che spesso viene realizzato tramite suite di MathWorks, permette tramite il MBD di generare complesse logiche con la semplicità di Simulink).

Nel caso di un Battery Management System (BMS), attraverso un modello è possibile simulare diverse condizioni operative della batteria, variando parametri quali temperatura, stato di carica (SOC), stato di salute (SOH) e condizioni di guasto. In questo modo si può verificare, per esempio, se la logica di controllo reagisce correttamente a una condizione anomala. Variando per esempio gli input di temperatura e richiesta di controllo contattori HV, si può verificare se il BMS decide di chiudere o tenere aperto il circuito HV per sicurezza.

C’è però un elemento da non trascurare. L’affidabilità del MIL dipende interamente dalla fedeltà del plant model: se il modello del sistema fisico non riproduce con sufficiente accuratezza dinamiche, tempi di risposta e condizioni ambientali, i risultati del test rischiano di essere poco significativi.

Il vantaggio principale del MIL è la rapidità. Se emerge un errore nella logica dell’algoritmo, è possibile correggerlo direttamente nel modello.

Ti starai chiedendo quali problemi si riescano concretamente a intercettare a questo livello. Tipicamente errori nella logica delle macchine a stati, soglie di intervento calibrate male, transizioni mancanti tra uno stato e l’altro e assunzioni temporali che non reggono quando gli ingressi assumono valori limite. Tutto ciò che nasce invece dalla generazione del codice o dal comportamento dell’hardware, in MIL resta invisibile per definizione: non perché il test sia fatto male, ma perché quegli elementi semplicemente non esistono ancora.

Con il Software in the Loop si passa dal modello all’implementazione software dell’algoritmo. Il codice viene eseguito su un computer mentre il sistema fisico continua ad essere rappresentato da un modello simulato. È quindi possibile verificare se l’implementazione produca risultati coerenti con il modello di riferimento.

Il SIL mette in evidenza una classe di problemi che in MIL non può emergere. Tra questi rientrano le differenze introdotte dall’implementazione, le anomalie nella tool-chain e nella cosiddetta code-gen, gli overflow e underflow su variabili intere, gli errori di casting tra tipi di dato e le imprecisioni legate all’aritmetica in virgola fissa.

Il metodo di riferimento a questo livello è il back to back testing. In pratica si confrontano gli input e gli output registrati durante il MIL con quelli prodotti dal codice, verificando che esista equivalenza numerica tra modello e implementazione. Se i risultati divergono oltre una tolleranza definita, il messaggio è chiaro: si torna al modello e si ripete il ciclo.

L’Hardware in the Loop introduce nel test una parte reale del sistema, tipicamente il modulo in progettazione e differenti sensori ed attuatori (in automotive potrebbe essere un modulo PCM con relativi attuatori VGT, wastegate e valvola a farfalla).

Il resto del sistema viene rappresentato da un modello eseguito su un simulatore real-time, spesso indicato come plant. Il simulatore genera i segnali che la ECU riceverebbe dal sistema reale e acquisisce le risposte prodotte dall’hardware (tipicamente tramite segnali digitali, analogici o comunicazioni CAN/LIN/Ethernet). In questo modo è possibile verificare non solo la logica del software, ma anche aspetti legati all’hardware, alle interfacce, agli I/O e al comportamento real-time (l’analisi dei reali ritardi di rete qui può evidenziare problemi di robustezza del SW/HW).

Ci sono difetti che semplicemente non puoi trovare da nessun’altra parte. Le violazioni dei vincoli temporali, la latenza degli interrupt, i bug nei driver hardware, il comportamento del watchdog sotto carico e gli errori nella configurazione delle periferiche emergono soltanto quando il software gira sull’hardware definitivo, con la sua memoria, i suoi tempi e i suoi vincoli. Lo stesso vale per la comunicazione a livello bus: solo in HIL puoi iniettare un messaggio CAN e osservare come reagisce la centralina reale, nei tempi reali, con il resto della rete che continua a trasmettere.

Uno dei vantaggi più importanti dell’HIL è la possibilità di riprodurre condizioni difficili o rischiose da creare durante un test fisico. È possibile, infatti, simulare guasti e condizioni limite che sarebbero difficili da riprodurre in sicurezza su un veicolo o su un sistema reale (i.e. impatti, condizioni di Over Voltage, Over Current e simili).

MIL, SIL e HIL non sono dunque alternative, ma tecniche ed approcci complementari di testing, utili in diversi steps processuali.

Un buon metodo è quello di leggerli anche come strumento diagnostico, oltre che come fasi di un processo. Se un test passa in MIL ma fallisce in SIL, il problema è quasi sempre nella generazione del codice o nella tool-chain. Se passa in SIL ma fallisce in HIL, stai guardando un problema di integrazione hardware, di timing o di gestione degli I/O. Mantenere lo stesso caso di test attraverso i tre livelli, cambiando soltanto l’ambiente di esecuzione, ti restituisce quindi un’informazione in più rispetto al semplice esito positivo o negativo: ti dice dove cercare.

Nel settore automotive il riferimento normativo per la sicurezza funzionale è la ISO 26262, che struttura le attività di verifica del software lungo il V-model. La parte 6 dello standard associa a ciascuna fase attività di verifica specifiche: MIL e SIL trovano collocazione naturale nella verifica a livello di unità software, prima sul modello e poi sul codice generato, mentre l’HIL si colloca sull’integrazione software e, a seconda della configurazione del banco, sulla qualificazione del software. Per i componenti classificati ASIL C e ASIL D entrano in gioco requisiti di copertura strutturale progressivamente più stringenti, fino al criterio MC/DC. Chiaramente lo standard non ti dice quale strumento comprare, ma definisce con precisione quale evidenza devi essere in grado di produrre.

Il settore automotive, come anticipato, da anni utilizza questi strumenti per velocizzare e migliorare il workflow generale. Esempi di ambiti automotive fortemente caratterizzati da questo approccio sono sicuramente ADAS e Powertrain.

• ADAS (Advanced Driver Assistance Systems): un algoritmo di LKA (mantenimento di corsia) può essere testato tramite MIL a diverse velocità, curvature e condizioni stradali. Il software viene poi verificato su SIL ed infine su HIL (tramite strumenti di simulazione è possibile anche introdurre stimoli esterni quali ad esempio la presenza di altri attori su strada). Quando entrano in gioco sistemi di computer vision, poi, il banco deve generare anche i flussi video sintetici che la centralina elaborerà, e la fedeltà della scena diventa un requisito di test a tutti gli effetti. Lo stesso discorso vale per le architetture di sensor fusion, dove la coerenza tra sorgenti diverse è proprio l’oggetto della verifica.
• Powertrain: MIL e SIL permettono lo sviluppo di tutti gli algoritmi di controllo; l’HIL permette poi di integrare le differenti ECU tra loro e ad un modello real-time in grado di simulare le più disparate condizioni di utilizzo (avendo reali PCM e TCM si possono vedere le interazioni tra i due moduli reali e il plant).

Magari lavori su un progetto di elettrificazione, e allora il discorso si fa ancora più concreto. In un intervento di retrofit come quello che abbiamo sviluppato con il sistema e-RSS, le logiche di gestione della trazione vanno progettate e verificate molto prima che il veicolo esista nella sua configurazione elettrica definitiva. In casi come questo la catena MIL e SIL non è un lusso metodologico: è l’unico modo per arrivare al banco con un software già sensato.

Nel settore aerospace, le attività di verifica assumono un’importanza particolare per le funzioni safety-critical e sono dunque soggette a processi di certificazione rigorosi.

Un esempio pratico rende l’idea meglio di qualsiasi definizione. Gli algoritmi di data fusion nei sistemi avionici si prestano particolarmente bene alla verifica in MIL, perché in simulazione puoi iniettare combinazioni di input sensoriali discordanti, degradati o palesemente incoerenti che sarebbe impossibile generare in volo senza mettere a rischio la piattaforma.

Uno dei principali riferimenti per il settore aerospace è il DO-178C.

Il documento definisce i principali criteri per lo sviluppo e la verifica del software destinato a sistemi del settore. Lo standard DO-178C non obbliga all’uso di MIL, SIL e HIL: la scelta delle tecniche e degli strumenti di verifica dipende dal sistema e dal livello di assurance richiesto. In questo contesto, MIL, SIL e HIL possono contribuire a costruire un processo di verifica strutturato e ripetibile, fornendo inoltre materiale documentabile utile alle diverse fasi dello sviluppo.

Il tema diventa particolarmente sentito sulle piattaforme di nuova generazione. Gli aeromobili eVTOL, per fare l’esempio più discusso degli ultimi anni, integrano controllo di volo, gestione dell’energia e strategie di ridondanza in architetture software che non hanno equivalenti nell’aviazione tradizionale. Vanno quindi validate senza poter contare su decenni di dati operativi alle spalle, e questo sposta ancora più a monte il baricentro delle attività di verifica.

Riassumiamo i punti chiave:

• MIL, SIL e HIL non sono alternative ma livelli complementari, distinti da ciò che viene realmente eseguito e da ciò che resta simulato.
• Ogni livello intercetta una classe di difetti diversa e nessuno può sostituire gli altri: la logica si valida sul modello, la generazione del codice sul software, il comportamento real-time sull’hardware.
• Il processo produce evidenza, ed è questo che lo rende compatibile con i requisiti di ISO 26262 in ambito automotive e DO-178C in ambito aerospace.

Non ci resta che passare dalla teoria al tuo progetto. Confrontarsi con chi progetta ogni giorno strategie di test e architetture di banco è spesso il modo più rapido per capire dove investire davvero.