# Un'interfaccia rugged che si aggiorna sul campo e non si blocca mai | OneStack > Caso studio: unità portatile a batteria con canali isolati, affidabile sul campo. Il firmware si aggiorna OTA e torna da solo all'ultima versione funzionante. URL: https://www.onestack.it/casi-studio/interfaccia-rugged-ota [← Tutti i casi studio](/casi-studio)Sistemi per ambienti gravosi # Un'interfaccia rugged che si aggiorna sul campo e non si blocca mai Un'unità portatile a batteria che alimenta e controlla due dispositivi remoti su canali isolati. La difficoltà era renderla affidabile lontano dal laboratorio. Il firmware si aggiorna sul campo e, se qualcosa va storto, torna da solo all'ultima versione funzionante. ![Render 3D della scheda di controllo: microcontrollore al centro, connettori dei due canali isolati sul lato, morsettiere estraibili e connettori di alimentazione e servizio](/_astro/interfaccia-rugged.CkQk4iYb_1A6Ozp.webp)![](/_astro/interfaccia-rugged-xray.CZb6dpZZ_Z1kxhOu.webp) 23 test in ~75 s collaudo funzionale automatico, superato al 100% 3 copie del firmware in memoria: in uso, in arrivo e di fabbrica 5 avvii falliti, poi il bootloader torna da solo alla versione buona Architettura del sistema **PC dell'operatore**USB, software di servizio **Unità di controllo**STM32U5 · ThreadX · bootloader a 3 partizioni **Alimentazione**smart battery + caricatore su SMBus **Canale isolato 1**RS-485 fino a 10 Mbaud + alimentazione isolata **Canale isolato 2**RS-485 fino a 10 Mbaud + alimentazione isolata **Dispositivi remoti**alimentati e monitorati dall'unità ## 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](/sicurezza-embedded), e un collaudo automatico pronto per la produzione. ## Servizi - Progettazione PCB - Sviluppo firmware ## Tecnologie - STM32U5 - ThreadX - RS-485 isolata - Alimentazione isolata - USB CDC - SMBus - Smart battery - Bootloader - OTA - Unity ## Altri casi studio [ ![Render 3D del banco di misura: il sensore sotto test e tre schede dentro un involucro in alluminio anodizzato nero, con due connettori BNC e un connettore M12](/_astro/banco-sensore-capacitivo.DpjM9RDJ_2dpT9y.webp)![](/_astro/banco-sensore-capacitivo-xray.CdoncSBR_Z1LXalp.webp) ~1,4% Collaudo per sistemi ad alta affidabilità ### Il metodo di collaudo non avrebbe funzionato. Lo abbiamo scoperto prima di costruirlo Un banco che dice in pochi secondi se un sensore di campo elettrico funziona, misurando in aria capacità di pochi picofarad. Il metodo previsto all'inizio è stato scartato con le misure, prima di spendere in hardware. Leggi il caso → ](/casi-studio/collaudo-sensore-capacitivo)[ ![Render 3D della scheda dell'ancora Bluetooth Channel Sounding: SoC nRF54L15 con antenna chip, accelerometro, alimentazione da USB-C o da morsetto 12–24 V](/_astro/ancora-ble.Ckke5SRn_1319HC.webp)![](/_astro/ancora-ble-xray.yah8tbey_Z2nf2oG.webp) 3 livelli Retail e grandi spazi pubblici ### Localizzazione indoor nei centri commerciali, senza raccogliere dati personali Contare e seguire i flussi di persone in grandi spazi aperti al pubblico, e localizzare con precisione centimetrica solo ciò che serve. Un'architettura a tre livelli, ognuno con la tecnologia radio giusta. Leggi il caso → ](/casi-studio/localizzazione-indoor)[ ![Render 3D del banco di misura: due lastre d'acciaio serrate da tiranti con i dischi e le schede all'interno, maniglie ai lati e l'attuatore sopra](/_astro/banco-mems.BVjo7je3_Z2tCAuW.webp)![](/_astro/banco-mems-xray.CArss8sQ_Z1wwNRX.webp) \> 40 dB Collaudo per sistemi ad alta affidabilità ### Dieci secondi per sapere se un accelerometro MEMS funziona davvero Un banco e un firmware che dicono con un sì o un no se un accelerometro MEMS è presente e ben accoppiato alla struttura, anche nelle mani di un operatore non specialista e con la macchina accesa. Leggi il caso → ](/casi-studio/collaudo-sensore-mems) ## Hai una scadenza? Raccontaci il progetto: entro 48 ore ricevi un’offerta con fasi e date. Se serve, firmiamo l’NDA prima di vedere i tuoi file. [Chiedi un’offerta](/contatti)[Urgente? Chiama +39 030 535 7183](tel:+390305357183)