EMB_90

EMBEDDED 90 • NOVEMBRE • 2023 59 DEBUG | SOFTWARE Da un lato si deve assicurare la FFI per quanto riguarda l’utilizzo della memoria. La componente QM non deve pertanto essere in grado di corrompere la memoria allo- cata alla componente ASIL. Il secondo aspetto è quello che riguarda il Timing & Execution (temporizzazione ed esecuzione). In questo caso, ad esempio, si deve garan- tire che l’esecuzione di un software QM non possa bloc- care l’esecuzione di un software ASIL. Il terzo aspetto, ovvero l’Information Exchange (scambio di informazio- ni), si riferisce all’interruzione della comunicazione dati fra emittente e ricevente, ad esempio inserendo dati non validi o bloccando un percorso di comunicazione. Analisi del codice sorgente Per il successo dello sviluppo delle applicazioni sa- fety-critical di una ECU, il compilatore deve essere qua- lificato di conseguenza. La certificazione del compilato- re, come quella in possesso del tool set di compilazione di TASKING , rappresenta un valido aiuto. Tuttavia, anche per un compilatore qualificato – così come per tutti gli strumenti usati – si deve eseguire la valutazione del rischio in conformità alla norma ISO 26262. Ogni compilatore presenta anche dei bug. Tutti quelli noti sono elencati nel cosiddetto errata sheet . Per applicazioni safety-critical , il codice sorgente deve esse- re analizzato e controllato per verificare se possa conte- nere bug del compilatore noti. Nella maggior parte dei casi questo processo viene effet- tuato manualmente. Tuttavia esistono tool come TriCore Inspector di TASKING che esaminano automaticamen- te il codice sorgente alla ricerca di tutti i problemi noti del compilatore e generano un report corrispondente. Report che può essere usato in seguito per correggere il codice sorgente o essere semplicemente allegato al re- port di valutazione del rischio. Dopo il compilatore, a questo punto anche il codice stesso deve essere controllato alla ricerca di errori, ri- guardanti fra l’altro i requisiti FFI. In questa fase sono di grande aiuto tool come Safety Checker di TASKING, equiparabile a un’analisi statica del codice completa- mente indipendente dal compilatore. Lo sviluppatore specifica nel tool i diritti di accesso desiderati di tutte le partizioni di sicurezza e QM nel sistema, ovvero di- ritti di lettura/scrittura e di esecuzione per specifiche aree di memoria. Dopo di che lo strumento esamina in ogni sua parte il codice sorgente e cerca di individuare potenziali falle, ovvero possibili interferenze fra le parti- zioni, provocate ad esempio da un uso non sicuro o non sufficientemente protetto di puntatori, variabili globali o memorie condivise. L’ipotesi qui è che la separazione fra le partizioni non sia ottenuta mediante hardware, che prevedono ad esem- pio un’unità di protezione della memoria (MPU, memory protection unit ) o un hypervisor . Tali metodi non sono progettati o disponibili, oppure non sono ancora abilita- ti. Nell’ultimo caso, lo strumento aiuta a risolvere i pro- blemi o a predisporre il software per una MPU. Invece di eseguire il debug delle eccezioni della MPU una dopo l’altra una volta che l’MPU è abilitata, il software può essere predisposto in anticipo. Tutto ciò senza dover ese- guire effettivamente il software su alcun hardware reale. Test unitario sull’hardware target La fase di test successiva nello sviluppo di ECU prevede il test unitario. Nella maggior parte dei casi i test unitari vengono eseguiti a livello di codice sorgente e su un PC host. Ciò significa che il codice sorgente da testare è in- serito in un framework di test. Qui è poi possibile aggiun- gere stub (si tratta di codici aggiuntivi che sostituiscono altri componenti di codici durante l’esecuzione di test, ad es. per simulare un componente che non è stato anco- ra implementato o componenti dipendenti dall’hardwa- re come gli I/O). Insieme ai casi di test, l’intero package è compilato ed eseguito sul computer host, come un PC Windows o Linux. Il risultato è un report di test che for- nisce sostanzialmente un risultato di tipo pass/fail per tutti i casi di test, solitamente insieme a un report di co- pertura del codice. Dal momento che l’esecuzione è fatta sul PC, l’esecuzione di base sull’hardware reale non è coperta. I test potrebbero non produrre risultati identici. Per questo la norma ISO 26262 raccomanda quanto se- gue: “L’ambiente di test per i test unitari del software do- Fig. 1 – Diverse applicazioni che girano su un’ECU possono avere requisiti di functional safety differenti