EMB_80

L’autotest nei sistemi embedded PUBBLIREDAZIONALE A meno che la memoria disponibile non sia completamente esaurita, in un progetto embedded vale la pena considerare l’implementazione di alcune capacità di auto-test. L’elettronica moderna tende ad ! À - bile, ma i guasti sono ancora possibili. In un sistema integrato 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 pos- sa monitorare l’integrità del sistema. Le periferiche possono guastarsi in vari modi, ma molti guasti ! À! ? ! - À! trap ; è essenzia- le includere un gestore di trap per elaborare questo errore. Altrimenti, i dispositivi di comunicazione includono comune- mente una modalità ‘ loopback ’ che consente di testare la tra- smissione e la ricezione e gli interrupt associati. L’errore di memoria è sempre possibile. Questo failure può es- sere transitorio, cioè un singolo bit viene capovolto. In genere non è possibile rilevare un tale errore e questo potrebbe cau- sare un arresto anomalo del software. Pertanto, è essenziale consentire il ripristino di emergenza. Un errore grave può es- sere una mancanza di risposta dell’indirizzo o bit bloccati su 0 o 1. Un gestore di trap si occupa del primo, ma il secondo !( ! ! À! / ! può essere eseguito solo all’avvio del dispositivo. Un test Mo- ving Ones À! ! Mentre il dispositivo è 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 software. Sebbene il software non sia soggetto ad un deterioramento per usura, la sua elevata complessità può generare dei malfunzio- À! . ; ! !( ! À! - cipare 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 im- !( À! può anche essere il risultato di un della struttura di dati, come un array o uno stack . L’inserimento di ‘ guard words ’ può aiutare a rilevare l’ 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. Colin Walls Siemens Embedded Moving Ones Test Stack Guard Words