EMB_90

EMBEDDED 90 • NOVEMBRE • 2023 61 Fig. 4 – Gli errori inseriti possono essere utilizzati per controllare gli effetti su un sistema vengono generati risultati di test simili: risultati pass/ fail per ogni caso di test e un report di copertura del codice. Tuttavia, qui la copertura del codice viene mi- surata sulla base di un record di tracciamento hardwa- re e, così come descritto in precedenza, senza alcuna instrumentazione per il codice sorgente. Per comprendere meglio come viene eseguito il test unitario su un target reale senza instrumentazione del codice, si consideri come esempio specifico il test unitario per la funzione C “calculateFuelEfficiency” (Fig. 3). Usando un debugger non è necessario esegui- re l’intera applicazione fino alla chiamata di funzio- ne. Il debugger può posizionare l’ instruction pointer (puntatore dell’istruzione) della CPU direttamente sul punto di ingresso della funzione (function entry). Se- guendo le convenzioni di chiamata del linguaggio C, il debugger imposta lo stack frame per la funzione e av- via la CPU. Il debugger arresta la CPU quando viene richiesto l’uso di stub o l’immissione di dati, ad esem- pio quando vi sono chiamate a sottofunzioni. Invece di chiamare queste sottofunzioni, la CPU salta entrambe le funzioni e immette invece il valore restituito ( return value ) direttamente nel registro CPU designato. La CPU continua l’esecuzione fino al ritorno della funzio- ne, a questo punto il debugger legge il valore risultan- te, che può essere confrontato con alcuni criteri pass/ fail . Tutto ciò funziona con un codice di produzione non modificato. Inserimento di errori Dopo il test unitario, il passo successivo è il test a livel- lo di sistema, ad esempio all’interno di una configura- zione HIL ( Hardware-in-the-Loop ). In questo caso, un debugger può risultare molto utile per l’inserimento di errori nel sistema al fine di testare l’effetto sulla FFI in termini di danneggiamento della memoria, esecuzione e anche condivisione delle informazioni. Il debugger viene usato per eseguire modifiche “al volo” su risorse on-chip come registri del core della CPU e memoria e successivamente per esaminare gli effetti (Fig. 4). Ma gli errori possono essere inseriti anche con interfacce esterne, mediante i moduli add-on per CAN/LIN e i segnali analogici/digitali collegati direttamente all’har- dware del debugger e al sistema target, che possono essere usati per inserire dati errati in un convertitore analogico-digitale (ADC) oppure con sensori esterni collegati via CAN o SPI. Ad esempio, si ipotizzi di voler controllare se il malfun- zionamento di un software QM possa avere conseguen- ze sull’esecuzione di una funzionalità ASIL. A questo punto, si osserva la reazione del sistema a una manipo- lazione di questo tipo, ad esempio con tracciamento on- chip, la registrazione di processi nel software in tempo reale attraverso il log dei tempi di esecuzione nell’inter- vallo dei cicli di clock. Il collegamento del debugger fra PC e hardware di destinazione reale è fondamentale in questo caso. Ciò significa che deve essere disponibile e DEBUG | SOFTWARE