EO_496

35 - ELETTRONICA OGGI 496 - SETTEMBRE 2021 PUBBLIREDAZIONALE SIEMENS A meno che la memoria disponibile non sia completamente esaurita, in un progetto embedded vale la pena considera- re l’implementazione di alcune capacità di auto-test. L’elettronica moderna tende ad essere incredibilmente af- fidabile, ma i guasti sono ancora possibili. In un sistema in- tegrato ci sono sostanzialmente quattro categorie di failure : - CPU - Periferico - Memoria - Errori di software Se una CPU si guasta, tende ad essere un guasto serio. Non offre alcuna possibilità di autotest. Un guasto parziale di una CPU è molto improbabile. In un sistema multicore, è buona norma assegnare uno dei core come ‘master’ in modo che possa monitorare l’integrità del sistema. Le periferiche possono guastarsi in vari modi, ma molti gua- sti sono specifici del dispositivo/applicazione. Se un dispo- sitivo non risponde al suo indirizzo, si verifica il trap ; è es- senziale includere un gestore di trap per elaborare questo errore. Altrimenti, i dispositivi di comunicazione includono comunemente una modalità ‘ loopback ’ che consente di te- stare la trasmissione e la ricezione e gli interrupt associati. L’errore di memoria è sempre possibile. Questo failure può essere transitorio, cioè un singolo bit viene capovolto. In genere non è possibile rilevare un tale errore e questo po- trebbe causare un arresto anomalo del software. Pertanto, è essenziale consentire il ripristino di emergenza. Un errore grave può essere una mancanza di risposta dell’indi- rizzo o bit bloccati su 0 o 1. Un gesto- re di trap si occu- pa del primo, ma il secondo richiede alcuni test specifi- ci. Il test completo della memoria può essere eseguito solo all’avvio del dispositivo. Un test Moving Ones è efficace. Mentre il dispositi- vo è in funzione, è possibile eseguire il test del pattern su singoli bytes/ words , che può evidenziare alcuni tipi di errore. La parte più complessa dei dispositivi moderni è il softwa- re. Sebbene il software non sia soggetto ad un deteriora- mento per usura, la sua elevata complessità può generare dei malfunzionamenti molto difficili da individuare in fase di sviluppo. Buone tecniche di codifica difensive possono aiutare ad anticipare alcuni problemi. In generale, ci sono due tipi di errori software: danneggiamento dei dati e loop del codice. Il danneggiamento dei dati può essere causato da un uso improprio del puntatore, che è difficile da rilevare o preve- nire, ma può anche essere il risultato di un overflow della struttura di dati, come un array o uno stack . L’inserimento di ‘ guard words ’ può aiutare a rilevare l’ overflow prima che causi alcun danno. Il looping del codice può essere risolto mediante un’attenta progettazione: precauzioni come i timeout in attesa dei di- spositivi o un qualche tipo di funzione watchdog (hardware o software) che intercetti il codice che non risponde. Siemens - www.sw.siemens.com/embedded-software/ Autotest in sistemi embedded Moving Ones Test Stack Guard Words Colin Walls Siemens Embedded