EMB_90

EMBEDDED 90 • NOVEMBRE • 2023 62 SOFTWARE | DEBUG Fig. 5 – È possibile usare il tracciamento hardware per misurare le condizioni di temporizzazione di diversi task Bibliografia Markt & Technik Trend Guide “Industriecomputer & Embedded-Systeme”, aprile 2022, stampa: https://wfm-publish.blaetterkatalog.de/frontend/ mvc/catalog/by-name/MUT?catalogName=MUT- SH2202D (pp. 38-41) Design & Elektronik 08-09/21, ottobre 2021, stam- pa: https://wfm-publish.blaetterkatalog.de/fron- tend/mvc/catalog/by-name/DUE?catalogName=- DUE2108D (pp. 6-11) collegata nel processore installato nell’ECU una corri- spondente interfaccia per il debug del tracciamento on- chip. Analisi della temporizzazione Ma il tracciamento on-chip non consente solo il moni- toraggio del comportamento del software. Dal momento che il tracciamento hardware è assolutamente non-in- trusivo, ossia non ha alcuna influenza sul runtime (tempo di esecuzione), è anche ideale per l’analisi della temporizzazione. Si dovrebbe senza dubbio procedere ai test della temporizzazione quale parte dei test di in- tegrazione del sistema. Il carico crescente sui task del sistema operativo ha naturalmente delle conseguenze sull’intero programma di temporizzazione e requisiti di temporizzazione critici successivi non possono essere più rispettati. Nelle analisi della temporizzazione che riguardano sicu- rezza e FFI è utile anche analizzare i margini di tempo- rizzazione: fondamentalmente è possibile verificare la robustezza dell’intera temporizzazione del software. Un caso d’uso mostra cosa può fare un tool di debug e tracciamento combinato: su una CPU sono in esecuzio- ne tre task, uno con tempi di 100 ms, un altro di 50 ms e il terzo di 10 ms. Il task con tempi di 10 ms ha la mas- sima priorità. Vengono aggiunte sempre più funzioni al runnable (eseguibile) del task con tempi di 10 ms e viene misurato l’effetto sul tempo di risposta del task con tem- pi di 100 ms. Un test di questo tipo può essere eseguito senza difficol- tà aggiungendo codice instrumentato al runnable per aumentare il runtime. Un debugger può cambiare que- sto codice di instrumentazione durante l’esecuzione del test. Quindi il runtime del runnable può essere modifica- to senza dover “ricostruire” il software. Nella figura 5 è possibile vedere un esempio di risultato. La curva verde mostra il tempo di risposta del task con tempi di 100 ms messo a confronto con il runtime dell’e- seguibile del task di 10 ms. Si supponga che il task con tempi di 100 ms abbia un limite che prevede un tempo di risposta non superiore a 85 ms: questo limite di tem- po può essere raggiunto a condizione che il runtime del runnable di 10 ms resti inferiore a 4,5 ms. È interessante notare anche come a un certo punto il tempo di risposta aumenti in modo praticamente esponenziale e da questo momento anche il carico della CPU smetta di aumenta- re. Si tratta di una chiara indicazione che lo scheduling del sistema operativo non funziona in modo affidabile, dal momento che il sistema è già sovraccarico. Il debugger hardware è sempre più un tool di processo – le funzioni di base di un debugger trovano la loro ap- plicazione usuale e sono integrate con potenti funzioni di analisi. Tutti i casi d’uso e i tool illustrati possono essere combi- nati in una pipeline di integrazione continua che si con- centra espressamente sul test di sicurezza del software. Pertanto è possibile creare un flusso di test, dall’analisi statica del codice ai test unitari sul sistema di destina- zione fino ai test di debug e tracciamento (temporizza- zione). Ovviamente non ha senso eseguire tutti questi test su ogni commit . Ad esempio, una strategia potrebbe essere quella di eseguire test a livello di codice solo di notte o solo su rilasci del software e test di integrazione ogni vol- ta che si procede all’unione ( merge ) di branch di software nel trunk principale.