Un'interfaccia rugged che si aggiorna sul campo e non si blocca mai

Il contesto

Il cliente lavora con sistemi installati in ambienti gravosi, lontano da qualsiasi laboratorio. Gli serviva un’unità portatile, in valigia rugged e a batteria, con cui un operatore collega il proprio PC a due dispositivi remoti per alimentarli, comunicare con loro e tenerli sotto controllo.

Sulla carta è un’interfaccia. In pratica mette insieme problemi che di solito si affrontano uno alla volta: potenza isolata, comunicazione in ambienti rumorosi, batteria e aggiornamenti sul campo. E all’orizzonte c’era una qualifica EMC severa.

Perché è difficile

• Due canali che non devono “toccarsi”. Ognuno porta potenza e dati a un dispositivo diverso: un guasto o un disturbo su un cavo non deve arrivare all’altro canale né al PC dell’operatore.
• Linee lunghe in ambienti elettricamente rumorosi, dove un bit sbagliato diventa un comando sbagliato.
• La batteria alimenta tutto, l’unità e i dispositivi remoti, e l’operatore deve sapere quanta autonomia gli resta.
• Un aggiornamento fallito significa un’unità ferma. Sul campo non ci sono programmatori né tecnici: se il firmware si blocca a metà aggiornamento, l’unità torna in laboratorio.
• La qualifica EMC si prepara dal primo schema, non quando il prototipo è finito.

Le accortezze, e perché

Un’architettura divisa in blocchi già nello studio di fattibilità. Alimentazione, unità di controllo e interfaccia di linea sono blocchi separati, con confini chiari. Ogni blocco si progetta e si prova da solo, e una modifica in uno non si propaga agli altri.

Isolamento galvanico su ogni canale, per i dati e per la potenza. Ogni canale ha la propria alimentazione isolata e la propria RS-485 isolata. I due dispositivi remoti, l’unità e il PC restano separati elettricamente, e un disturbo su un cavo resta su quel cavo.

Consumi misurati canale per canale. Tensione e corrente di ogni uscita sono misurate in continuo, così l’operatore vede subito se un dispositivo assorbe più del previsto.

Una batteria che dice da sola quanto le resta. Batteria e caricatore dialogano con il firmware su SMBus, con controllo d’errore su ogni messaggio. Lo stato di carica arriva dalla batteria stessa, non da una stima sulla tensione.

RS-485 a 10 Mbaud con DMA e timeout di ricezione. La RS-485 differenziale regge il rumore sulle linee lunghe. Il DMA riceve i dati senza impegnare la CPU, e il timeout hardware del ricevitore individua la fine di ogni trama senza interpretare i dati byte per byte. Il protocollo binario porta un CRC su ogni messaggio.

STM32U5 e ThreadX. Il microcontrollore consuma poco quando l’unità è in attesa a batteria, ma ha memoria sufficiente per tre immagini del firmware e acceleratori hardware per CRC e hash, quindi la verifica degli aggiornamenti non pesa sulla CPU. ThreadX è deterministico, lavora con memoria allocata staticamente e ha una storia di certificazioni in ambito safety: il comportamento è prevedibile e la qualifica è più semplice.

Un bootloader con tre partizioni. L’aggiornamento arriva a blocchi in una partizione di staging, mentre l’applicazione in uso continua a girare. Si passa alla nuova versione solo dopo averne verificato l’integrità completa. Se la nuova versione non riesce ad avviarsi per cinque volte di seguito, il bootloader torna da solo all’ultima versione buona. Come ultima risorsa resta un’immagine di fabbrica che non viene mai sovrascritta.

La norma EMC letta requisito per requisito. Invece di rimandare tutto al laboratorio di prova, abbiamo esaminato la norma voce per voce, isolato i requisiti che si applicano a questo sistema e li abbiamo raggruppati in due campagne di prova, per contenere costi e tempi d’attesa.

Come l’abbiamo verificato

• Unit test sui moduli del firmware, con ogni modulo specificato prima di essere scritto.
• Trasferimenti ad alta velocità verificati byte per byte: blocchi da 512 kB in DMA a 20 Mbps senza un errore.
• Loopback RS-485 a 10 Mbaud, in half e full duplex.
• Un software di collaudo multipiattaforma con una sequenza automatica di test e un log per ogni unità.

Il risultato

Il prototipo funzionale è stato rilasciato con un collaudo automatico di 23 test in circa 75 secondi, superati al 100% nelle ultime campagne. L’unità si aggiorna sul campo dal PC dell’operatore e, se un aggiornamento non va a buon fine, torna da sola a funzionare: un firmware andato male non costa un rientro in laboratorio.

Cosa portiamo nei vostri progetti

Sistemi con canali isolati e alimentazione verso dispositivi remoti, batterie intelligenti, comunicazione robusta su bus industriali, firmware su RTOS progettato per la qualifica, bootloader e aggiornamenti sicuri, e un collaudo automatico pronto per la produzione.