Catena watchdog
Nei dispositivi optiMEAS viene posta grande attenzione alla tolleranza ai guasti, all'elevata disponibilità e all'affidabilità in esercizio. Un elemento essenziale è una catena watchdog continua che va dall'hardware ai componenti software.
Principio di base
La catena watchdog nei dispositivi optiMEAS è composta da una combinazione di componenti hardware e software che insieme formano una linea di monitoraggio. In questa linea il corretto funzionamento di ogni singolo componente viene monitorato in modo continuo. Se un componente si guasta, vengono avviate automaticamente misure per garantire il regolare funzionamento. Le misure comprendono diversi approcci, tra cui il riavvio mirato di singoli processi, il riavvio software completo del sistema Linux nonché lo spegnimento selettivo e il successivo riavvio di singoli componenti hardware o addirittura dell'intero sistema.
La catena watchdog è rappresentata schematicamente nella figura seguente.
I singoli livelli di monitoraggio
Il livello più basso è costituito dall'hardware watchdog (power controller). Si tratta di un microcontrollore in grado di togliere l'alimentazione in modo mirato a tutti gli altri componenti hardware (processore principale con sistema Linux, modem, ecc.) e di riavviarli. Esso stesso dispone di un watchdog interno che lo riavvia in caso di errore.
Questo hardware watchdog si aspetta dal livello superiore, il Device-Manager, un segnale di vita ciclico. Il Device-Manager è un componente software centrale che invia un segnale di vita all'hardware watchdog tramite il bus I2C. Monitora tutti i processi software specifici delle applicazioni (app) ed è a sua volta avviato e monitorato dal processo Linux "systemd". In caso di errore, systemd tenta di riavviare il Device-Manager fino a cinque volte prima di eseguire un riavvio software completo.
Tutti i processi software specifici delle applicazioni (app) formano il livello al di sopra del Device-Manager. Il DeviceManager monitora le app (ad es. lo smartCORE) tramite un software watchdog. L'elenco delle app da monitorare è già definito nella configurazione del sistema, in modo che il DeviceManager possa monitorare già l'avvio dei processi. In questo modo sono coperti anche i casi in cui il processo si interrompe durante l'avvio. In assenza del segnale watchdog, il processo viene terminato in modo mirato e riavviato. I riavvii dei processi vengono conteggiati e, al superamento di determinati limiti, si ha un riavvio del sistema. Un funzionamento stabile per un periodo prolungato azzera il contatore.
Cosa accade in caso di errore
Vediamo cosa accade in caso di guasto dei singoli componenti: se un'app "si blocca", il suo segnale di vita al Device-Manager viene a mancare. Il Device-Manager riavvia quindi l'app e conta i riavvii dell'app nel tempo. Se il problema non può essere risolto con un riavvio dell'app, ovvero se i componenti si guastano ripetutamente, viene riavviato l'intero sistema.
Se è il Device-Manager stesso a bloccarsi, interviene dapprima il processo systemd di Linux, che riavvia il Device-Manager fino a cinque volte. Se nonostante ciò non si ottiene un funzionamento stabile, viene riavviato l'intero sistema Linux.
Se si guastano sia il Device-Manager sia systemd, il segnale watchdog verso l'hardware watchdog viene a mancare. Questo riavvierebbe quindi l'intero sistema tramite un power cycle.
Semplice test del sistema
Si sconsiglia di intervenire manualmente sul sistema. Se l'utente esperto desidera comunque eseguire un test del sistema, è consigliabile la procedura seguente. Dopo l'autenticazione e l'accesso al sistema, un processo monitorato viene terminato tramite la console Linux, ad esempio con
killall smartcore
Dopo breve tempo il Device-Manager rileverà l'assenza del segnale di vita e quindi il guasto del processo. Il processo viene quindi riavviato dal Device-Manager.
L'assenza del segnale di vita e il riavvio del processo vengono registrati nei logfile del Device-Manager. Dando un'occhiata al logfile è possibile riconoscere la sequenza.
