I sistemi elettronici sono un universo oggettivamente complicato e complesso.
Quando un dispositivo elettronico smette di funzionare, la prima reazione è quasi sempre: “si è rotto”.
Si cambiano componenti, si controllano le alimentazioni, si rifanno le saldature. E spesso… non cambia nulla.
Perché in molti casi il problema non è nell’hardware. Che anzi appare ed è perfettamente integro.
Prendiamo una situazione tipica:
- la scheda si accende
- i segnali ci sono
- i componenti sono corretti
- i test di base passano
Eppure il sistema:
- si blocca dopo qualche ora
- smette di comunicare
- risponde in modo incoerente o anomalo
- funziona “quasi sempre”… ma non sempre
A quanto pare in questi casi il problema, a volte, è altrove: nel software o nel firmware.
Il problema non è il guasto, ma lo stato
Un sistema embedded non è altro che una macchina “a stati” di utilizzo:
- riceve input
- elabora condizioni
- cambia stato
- produce output
Se tutte le condizioni sono previste, il sistema funziona correttamente.
Ma potrebbe bastare un evento non gestito per creare un problema.
Ad esempio:
- un dato non valido
- una comunicazione interrotta
- un evento fuori sequenza
- un timeout non previsto
In questi casi il sistema non si rompe. Ma entra in uno “stato non gestito”. Ovvero che non è stato previsto e codificato, magari semplicemente con un riavvio.
Il punto critico: le condizioni reali
Molti di questi sistemi elettronici funzionano perfettamente… in laboratorio. Avendo magari sostenuto brillantemente ore ed ore di test di collaudo.
Poi arrivano sul campo e succede altro, tipo:
- disturbi elettrici
- utilizzi non previsti
- comunicazioni instabili
- cicli di lavoro continui h24
Se il software non è stato progettato anche per queste condizioni più “estreme” ma tutto sommato realistiche, il sistema entra in difficoltà. Non perché sia stato costruito male, ma perché non è stato pensato per un utilizzo costante ma con imprevisti.
Quando il firmware non sa cosa fare
Il punto critico è dunque questo: il firmware è progettato per gestire scenari previsti. Ma nella realtà succede a volte qualcosa di diverso, l’anomalia che irrompe nel funzionamento standard, come ad esempio:
- segnali sporchi
- condizioni borderline
- utilizzi non ideali
- interazioni impreviste tra moduli
Se queste situazioni non sono state considerate, il sistema:
si blocca- resta in loop
- smette di comunicare
- produce risultati errati
Non è stato ribadiamo progettato per gestire una “casualità” che si potrebbe concretizzare.
Il vero lavoro è far funzionare i sistemi elettronici in condizioni “non ideali”
Far funzionare un sistema in condizioni ideali è relativamente semplice.
Ma la qualità più importante, o comunque una delle più fondanti, è fare funzionare un dispositivo in condizioni irregolari e inconsuete, non ideali. Giusto per fare qualche esempio quando:
- i dati sono sbagliati
- le comunicazioni falliscono
- l’utente fa qualcosa di inatteso
- il sistema resta acceso per mesi
È soprattutto qui che si gioca la qualità di un progetto.
Affidabilità = gestione degli errori
Un sistema affidabile non è quello che “non ha problemi”. Non a caso la fase di debug è comunque importantissima in qualunque progetto, a testimonianza del fatto che occorrerà sempre “aggiustare il tiro” soprattutto nei primi periodi per addivenire ad un sistema stabile. Ma è molto importante che questo prodotto:
- gestisca anche gli errori
- recuperi dagli stati anomali (logiche di recovery)
- torni a funzionare senza intervento umano
Per questo, elementi come:
- watchdog
- gestione dei timeout
- validazione dei dati
- macchine a stati robuste
non sono dettagli, ma fondamenta stesse del progetto.
Dove nasce davvero il valore nei sistemi elettronici
Due dispositivi con lo stesso hardware possono comportarsi in modo completamente diverso. La differenza sta nel codice scritto dei sistemi elettronici. Per essere stabile occorre che sia stata valutata:
- gestione degli edge case (casi limite)
- robustezza della logica
- qualità dell’architettura software
Sono alcuni dei fondamentali per fare scaturire l’affidabilità reale del dispositivo.
Perché conviene investire nel software dei sistemi elettronici
Spesso il software viene visto come una parte “secondaria” del progetto. Ma in realtà è quello che:
- determina la stabilità del prodotto
- permette aggiornamenti futuri
- riduce drasticamente i problemi sul campo
- protegge l’investimento nel tempo
Una buona progettazione non è quindi un costo in più, anzi è un risparmio enorme già nel medio periodo.
Conclusione
A volte alcuni sistemi elettronici non si rompono nel senso classico del termine.
Semplicemente smettono di funzionare perché entrano in condizioni che il software ed il firmware non sono stati programmati a gestire.
Per questo, nella progettazione, la differenza non la fa solo l’hardware (che peraltro può essere individuato in fase progettuale anche con metodi molto efficienti, ad esempio utilizzando un MTBF).
Anzi molto insomma dipende dalla capacità di progettare sistemi elettronici a tutto tondo, che abbiano la facoltà di gestire anche funzionalità non ideali.