Svelare i problemi nascosti: reali

Giacobbe del Benin | 30 agosto 2023

Oggi, una delle funzionalità più sottovalutate nello sviluppo di software embedded è il tracciamento di un'applicazione del sistema operativo in tempo reale (RTOS). Gli RTOS si sono fatti strada in quasi tutti i dispositivi IoT e in molti dispositivi disconnessi. Quando gli sviluppatori testano i propri sistemi, spesso esaminano i comportamenti del sistema esterno per valutare se funziona correttamente. Il problema con questo approccio è che molti sistemi hanno comportamenti che devono verificarsi in modo deterministico su scale temporali inferiori a 50 millisecondi. Senza tracciamento, potresti credere che il sistema funzioni, solo per scoprire quando è nelle mani dei tuoi clienti che è difettoso e non funziona correttamente in tutte le circostanze. In questo post ti guiderò attraverso alcune funzionalità di tracciamento e condividerò esempi di come ho individuato problemi che potrebbero non essere stati scoperti finché i dispositivi non erano sul campo.

Prima di esaminare alcuni esempi specifici, è utile comprendere come tracciare un'applicazione RTOS. Solitamente sono costituite da due parti: una libreria di registratori che tiene traccia degli eventi nell'applicazione RTOS sulla destinazione e una GUI di visualizzazione che riceve e visualizza i dati degli eventi. Diversi strumenti consentono agli sviluppatori di acquisire questi dati, come Percepio Tracealyzer, SEGGER SystemView e Microsoft Azure RTOS TraceX. Ce ne sono molti altri, ma lo strumento che utilizzerai dipenderà dall'RTOS che stai utilizzando e dalle tue esigenze di visualizzazione.

In genere si installa la libreria del registratore di traccia degli strumenti, che spesso crea un'attività di traccia. Questa attività a bassa priorità prende i dati degli eventi registrati e li trasmette all'applicazione host (almeno in modalità streaming). Ne parlo perché quando strumenti il ​​tuo codice in questo modo, è importante notare che cicli aggiuntivi della CPU saranno dedicati alla registrazione dei dati di traccia. Nella mia esperienza con questi strumenti, il sovraccarico è così minimo che non te ne accorgi (almeno in qualsiasi applicazione su cui ho lavorato). È importante saperlo per decidere se lascerai il registratore di traccia nel firmware di rilascio. In caso contrario, testa e convalida la tua applicazione con il firmware di rilascio!

Recentemente ho allenato un team di ingegneri che avevano iniziato i test di validazione sul loro prodotto. Hanno eseguito i test e hanno creduto che il loro sistema funzionasse perfettamente. Mi hanno detto che il loro sistema era pronto per la spedizione; hanno riscontrato un piccolo problema con i tempi di telemetria del loro sistema: nessun grosso problema. Nella mia esperienza, non esiste un problema minore. I problemi minori sono solitamente la punta dell'iceberg che si trasformano in problemi titanici quando finiscono nelle mani del cliente. Quindi, abbiamo configurato Percepio Tracealyzer per tracciare l'applicazione e vedere come il loro sistema funzionava perfettamente.

Se si osserva la Figura 1 di seguito, è possibile vedere una rappresentazione dell'utilizzo della CPU del sistema. Ogni colore nel diagramma rappresenta un compito diverso. L'asse x è il tempo e l'asse y è l'utilizzo della CPU. Vi sembra un sistema validato e pronto per andare nelle mani dei clienti?

Figura 1. Un esempio di grafico di utilizzo della CPU in cui il carico della CPU raggiunge il 100% per tutto il tempo.

Sfortunatamente, il sistema in questione utilizzava il 100% della CPU. Ad un esame più attento, non rispettava le scadenze critiche e non operava in modo deterministico. L'osservazione umana è stata inutile per scoprire questi problemi tracciandone l'applicazione. Se il prodotto fosse stato spedito in questo modo, i clienti avrebbero avuto problemi. Prendendo alcune semplici tracce, potremmo vedere un problema e porre rimedio alla situazione. Andando un po' più a fondo, abbiamo identificato alcune piccole cause che hanno richiesto meno di mezza giornata per essere risolte e l'utilizzo della CPU risultante è passato dalla Figura 1 a qualcosa di simile alla Figura 2.

Figura 2. Un esempio di grafico di utilizzo della CPU più adatto a un sistema di produzione.

Il miglioramento dell'utilizzo della CPU è molto inferiore e lascia spazio per l'aggiunta di funzionalità future e per garantire al cliente un sistema in grado di rispondere e rispettare le scadenze.

Il tracciamento RTOS non rileva solo i problemi relativi alle prestazioni della CPU. Funziona come un oscilloscopio per il software! Quando i thread vengono visualizzati, puoi individuare modelli diversi nel tuo sistema e identificare incoerenze. Il risultato è che puoi trovare problemi come inversioni di priorità, deadlock e carenza di attività. Diamo un'occhiata a un esempio.