EMB 91

EMBEDDED 91 • FEBBRAIO • 2024 60 SOFTWARE | FUNCTIONAL SAFETY 3. Se il file JSON è vuoto, il processo di creazione è completo. 4. Se il file JSON non è vuoto, il codice sorgente deve essere strumentato nelle posizioni in cui sono sta- ti rilevati i gap di osservabilità. Questo è un altro compito svolto da t32cast. Il processo di creazione viene completato con la creazione di un file ELF per i file sorgenti strumentati. Prima di procedere alla fase “Test e reportistica” è oppor- tuno spendere qualche parola sulla strumentazione ese- guita da t32cast. Per garantire che TRACE32 possa rileva- re se una condizione risulta vera o falsa in qualsiasi punto del flusso del programma registrato, il codice sorgente è strumentato con due hook di strumentazione t32__alpha() e t32__beta() per i gap di osservabilità rilevati (vedere fi- gura 5). Entrambi gli hook consistono solo in chiamate a funzione con un corpo della funzione vuoto. In aggiunta ai salti/istruzioni condizionali, TRACE32 valuta anche que- ste chiamate per l’analisi della copertura MC/DC. Il costo per la strumentazione è molto basso poiché, per la strumentazione mirata, TRACE32 non richiede alcuna interfaccia aggiuntiva verso la memoria. Inoltre, dal mo- mento che non vengono generate ulteriori righe di codice sorgente, il codice sorgente originale può essere utilizza- to nella fase “Test e reportistica”. Test e reportistica Riguardo al test, i file sorgenti C/C++, i corrispondenti dati “.eca” e il corrispondente file ELF devono essere ca- ricati nel debugger o nel simulatore del set di istruzioni TRACE32 che esegue l’analisi della copertura MC/DC (vedere figura 6). Sono disponibili due opzioni per la re- gistrazione della traccia: 1. La registrazione della traccia e l’esecuzione dell’a- nalisi della copertura MC/DC vengono svolte come attività sequenziali. L’analisi della copertura MC/DC viene effettuata direttamente per i dati della traccia registrati nel debugger. 2. La registrazione della traccia e l’esecuzione dell’a- nalisi della copertura MC/DC sono attività separate, svolte da due diversi team di test. In questo caso i dati tracciati devono essere salvati in un file dopo la regi- strazione e ricaricati in TRACE32 per effettuare in un secondo momento l’analisi della copertura MC/DC. Workflow consigliato per progetti con requisiti di sicurezza Come descritto sopra, l’analisi MC/DC basata sul trac- ciamento richiede un’ottimizzazione ridotta e potrebbe anche richiedere una certa strumentazione del codice. È fondamentale che il software embedded realizzato ap- positamente per finalità di test di copertura si comporti esattamente allo stesso modo del software di produzione che alla fine controllerà il sistema embedded. Pertanto, è necessario testare entrambe le varianti software fianco a fianco per l’intero ciclo di vita del test. La figura 7 mostra il flusso di lavoro consigliato per il test di progetti con re- quisiti di sicurezza. La copertura del codice multimodale di TRACE32 per- mette di raggiungere l’obiettivo di supportare la coper- tura MC/DC per un’ampia gamma di architetture di core, protocolli di tracciamento e compilatori. In molti casi sarà possibile ottenere questo risultato senza stru- mentazione. La strumentazione mirata eventualmente necessaria non richiede mai più del 10% di memoria ag- giuntiva per l’intero codice oggetto e ha un sovraccarico temporale minimo. Fig. 6 – Test e reportistica per la copertura multimodale in TRACE32 Fig. 7 – Workflow per il test di progetti con requisiti di sicurezza