Aggiornamenti OTA industriali: A/B, rollback e ridondanza

Ogni ingegnere che sviluppa e distribuisce dispositivi Linux industriali prima o poi si trova davanti alla stessa domanda: come aggiornare l’hardware installato in un quadro elettrico, in fabbrica o in una sede remota senza un’interruzione prolungata del servizio, un intervento sul posto o il rischio di bloccare il dispositivo (bricking)? Per una scheda di sviluppo sul banco di lavoro, aggiornare Linux può essere semplice come collegarsi via SSH ed eseguire apt upgrade. I dispositivi industriali sono diversi: possono essere difficili da raggiungere, collegati tramite reti inaffidabili o destinati a funzionare ininterrottamente per anni. Un aggiornamento fallito, un’interruzione imprevista dell’alimentazione o un’applicazione che non si avvia dopo il boot possono trasformare un normale rilascio software in un intervento di assistenza.

Un sistema di aggiornamento over-the-air (OTA) robusto deve quindi fare molto più che copiare file: deve installare in sicurezza un sistema completo, verificarne il corretto funzionamento e ripristinare automaticamente la versione precedente in caso di problemi. Un’architettura pratica combina aggiornamenti di sistema A/B, rollback assistito dall’hardware, bundle di aggiornamento firmati, Software Bill of Materials (SBOM) e build riproducibili. Questo articolo illustra questi concetti utilizzando come esempio lo Strato Pi Max di Sfera Labs e Rugix di Silitics. Insieme offrono un’efficace combinazione di hardware industriale con molteplici opzioni di storage fisico e uno stack software progettato per aggiornamenti robusti e riproducibili.

Perché gli aggiornamenti OTA industriali sono diversi

Un dispositivo Linux industriale non è "finito" quando si avvia correttamente sul banco di lavoro. Durante il suo ciclo di vita avrà bisogno di aggiornamenti di sicurezza del sistema operativo, aggiornamenti delle dipendenze, nuove versioni delle applicazioni e correzioni delle vulnerabilità. Questi aggiornamenti devono spesso essere distribuiti senza avere accesso fisico al dispositivo.

Un sistema di aggiornamento dovrebbe quindi:

• lasciare intatto il sistema in esecuzione durante l’installazione dell’aggiornamento;
• resistere a un’interruzione dell’alimentazione durante l’aggiornamento;
• verificare che il nuovo sistema sia in grado di avviarsi e funzionare;
• tornare automaticamente alla versione precedente se non riesce a farlo;
• impedire l’installazione di software non autorizzato;
• garantire la tracciabilità di ogni release.

Questo sta diventando sempre più importante anche dal punto di vista normativo. Il Cyber Resilience Act (CRA) dell’Unione Europea è entrato in vigore nel dicembre 2024, con i principali obblighi applicabili da dicembre 2027 e gli obblighi di segnalazione delle vulnerabilità a partire da settembre 2026. Il CRA non impone una specifica architettura OTA, ma stabilisce requisiti relativi alla gestione delle vulnerabilità, al mantenimento della sicurezza e al supporto durante l’intero ciclo di vita del prodotto. Un meccanismo OTA affidabile non rende di per sé un prodotto conforme, ma rappresenta una componente fondamentale dell’infrastruttura necessaria per mantenere sicuri i prodotti connessi durante tutto il loro ciclo di vita.

Aggiornamenti A/B: non sovrascrivere il sistema in esecuzione

L’idea fondamentale alla base di aggiornamenti OTA robusti è semplice: non sostituire direttamente il sistema operativo in esecuzione (in-place). Si mantengono invece due istanze di sistema avviabili, comunemente chiamate A e B. Mentre A è in esecuzione, l’aggiornamento viene installato su B. Il dispositivo viene quindi riavviato e tenta di avviare B. Se B si avvia correttamente e supera gli opportuni controlli di stato (health check), diventa il sistema attivo. Se invece fallisce, il dispositivo torna ad A. Questo evita uno dei maggiori rischi degli aggiornamenti effettuati sul sistema in uso: un’interruzione dell’alimentazione può rendere il sistema inutilizzabile. Con gli aggiornamenti A/B, il sistema precedente rimane disponibile mentre viene installato quello nuovo.

Esiste tuttavia un’importante differenza tra le diverse implementazioni A/B: due partizioni sullo stesso disco forniscono ridondanza software; due dispositivi di storage fisicamente indipendenti offrono un ulteriore livello di resilienza.

Anche la ridondanza hardware è importante

È qui che l’architettura hardware diventa parte integrante del sistema OTA. Strato Pi Max è una piattaforma industriale modulare basata su Raspberry Pi Compute Module. Offre molteplici interfacce di comunicazione, schede di espansione, funzionalità di hardware watchdog e diverse opzioni di archiviazione, tra cui schede SD, eMMC e SSD. Per le applicazioni OTA, una delle caratteristiche più interessanti è la possibilità di utilizzare dispositivi di storage fisicamente separati.

La configurazione dual-SD consente di ospitare due sistemi completi su due schede SD indipendenti. Il microcontrollore di Strato Pi Max gestisce il routing dello storage e può commutare tra le due schede. Ciò significa che il concetto A/B non è limitato a due partizioni su un singolo dispositivo di memoria. Ciascuna copia del sistema può risiedere su un supporto fisico distinto, mantenendo disponibile un sistema di ripristino anche nel caso in cui uno dei due dispositivi si guasti. Strato Pi Max supporta anche altre combinazioni di storage, consentendo di creare ridondanza tra le memorie SSD e la eMMC del Compute Module.

Uno stack hardware/software progettato per questo problema

È qui che la collaborazione tra Sfera Labs e Silitics ha portato alla realizzazione di uno stack hardware e software particolarmente efficace. Strato Pi Max fornisce la base hardware, inclusi storage indipendenti e supervisione hardware. Rugix fornisce il livello software per immagini Linux riproducibili, aggiornamenti, rollback e gestione controllata dello stato del sistema. Rugix è costituito principalmente da Rugix Bakery, che crea le immagini di sistema e i bundle di aggiornamento, e Rugix Ctrl, che viene eseguito sul dispositivo target e gestisce aggiornamenti, slot A/B e rollback.

Per Strato Pi Max, l’esempio open source di Rugix mette a disposizione due configurazioni:

• rpi-tryboot: utilizza il meccanismo tryboot di Raspberry Pi su un singolo supporto di avvio;
• stratopi-dual-sd: utilizza le due schede SD fisiche insieme alle funzionalità di Strato Pi Max per fornire commutazione e rollback assistiti dall’hardware.

Questo articolo si concentra sul secondo approccio perché dimostra la maggiore resilienza ottenuta combinando aggiornamenti software A/B con la ridondanza fisica dello storage.

Costruire un sistema realmente aggiornabile

L’esempio si basa sul template open source di Rugix per Strato Pi Max: https://github.com/rugix/rugix-example-stratopi. Il repository può essere clonato con:

git clone https://github.com/rugix/rugix-example-stratopi.git
cd rugix-example-stratopi

La build viene eseguita all’interno di un container utilizzando Docker o Podman. L’immagine dual-SD e il bundle di aggiornamento vengono generati con:

./run-bakery bake bundle stratopi-dual-sd

L’immagine risultante viene scritta su entrambe le schede SD, in modo che il dispositivo possa avviarsi da una qualsiasi delle due. A scopo dimostrativo, l’immagine contiene un servizio che controlla il LED verde sul pannello frontale. Inizialmente, il LED cambia stato ogni 500 ms. Il LED non è importante in sé: serve semplicemente a fornire un’indicazione visibile del fatto che l’intero sistema Linux è stato aggiornato.

Distribuire il primo aggiornamento

Per dimostrare un aggiornamento, l’intervallo del LED viene modificato da 500 ms a 100 ms e l’immagine viene ricompilata:

./run-bakery bake bundle stratopi-dual-sd

Il bundle .rugixb risultante viene trasferito sul dispositivo e installato utilizzando Rugix Ctrl:

rugix-ctrl update install \
  --insecure-skip-bundle-verification \
  /root/system.rugixb

Omettere la verifica della firma (–insecure-skip-bundle-verification) è accettabile per questa dimostrazione, ma nei sistemi di produzione i bundle di aggiornamento dovrebbero essere sempre firmati crittograficamente prima dell’installazione. Una volta installato l’aggiornamento, il dispositivo si riavvia nel nuovo sistema e il LED cambia visibilmente la propria frequenza di lampeggio.

Cosa succede quando un aggiornamento fallisce?

È quando qualcosa va storto che emerge il vero valore di questa architettura. Con la configurazione dual-SD, il sistema attivo continua a funzionare mentre Rugix prepara la scheda inattiva:

• L’aggiornamento viene scritto sulla scheda SD inattiva.
• Viene attivato un meccanismo di rollback basato sul watchdog.
• Il sistema viene riavviato eseguendo la commutazione tra le schede.
• Il sistema aggiornato si avvia.
• Se segnala un funzionamento corretto, rimane attivo.
• Se fallisce ripetutamente, il sistema torna alla scheda SD precedente.

Il watchdog è particolarmente importante in questo contesto. Un avvio di Linux completato con successo non significa necessariamente che il prodotto sia operativo. Nei sistemi di produzione, l’heartbeat del watchdog dovrebbe riflettere lo stato di salute dell’applicazione, anziché limitarsi a dimostrare che lo spazio utente (userspace) sia attivo. Il risultato è un meccanismo di ripristino che non dipende dalla connettività di rete. Anche se l’aggiornamento fallisce, il sistema precedente rimane disponibile localmente.

Aggiornamenti firmati e SBOM

Il rollback protegge da un aggiornamento difettoso, ma non da uno non autorizzato. I bundle di aggiornamento destinati alla produzione dovrebbero quindi essere firmati crittograficamente, stabilendo una catena di fiducia (chain of trust) tra il processo di rilascio e il dispositivo installato. La pipeline di aggiornamento dovrebbe inoltre fornire visibilità sui contenuti di ciascuna release. Un SBOM (Software Bill of Materials) registra i componenti software e le dipendenze inclusi in una release. Quando viene scoperta una vulnerabilità, aiuta a identificare i prodotti e le versioni interessati. Rugix Bakery può generare gli SBOM e gli artefatti di build insieme all’immagine di sistema e al bundle di aggiornamento. Questi artefatti forniscono una preziosa tracciabilità durante tutto il ciclo di vita del prodotto.

Dall’esempio alla produzione

La dimostrazione mantiene volutamente semplice l’applicazione, ma la stessa architettura può essere adattata a sistemi di produzione. Le considerazioni principali sono:

• sostituire le credenziali utilizzate nella dimostrazione con i meccanismi di autenticazione e provisioning propri del prodotto;
• predisporre un’infrastruttura di firma per la produzione;
• fare in modo che il watchdog rifletta lo stato di salute dell’applicazione;
• definire se lo storage inattivo debba conservare la release precedente o essere sincronizzato con quella nuova;
• assicurarsi che i dati rimangano compatibili con un eventuale rollback;
• integrare il meccanismo di aggiornamento con l’infrastruttura di gestione della flotta (fleet management).

Il template di esempio include un’integrazione con Nexigon, ma Rugix non richiede uno specifico backend. Gli aggiornamenti possono essere distribuiti tramite piattaforme personalizzate o meccanismi controllati dall’operatore.

Conclusione

Gli aggiornamenti OTA affidabili sono un problema di progettazione del sistema, non una semplice funzionalità software. La combinazione di aggiornamenti A/B, ridondanza fisica dello storage, rollback assistito dall’hardware, distribuzione con firma digitale e generazione di SBOM fornisce una solida base per la manutenzione dei dispositivi Linux industriali durante l’intero ciclo operativo. Strato Pi Max e Rugix dimostrano questo approccio su una piattaforma industriale reale, offrendo un esempio particolarmente chiaro di come hardware e software possano lavorare insieme per rendere recuperabile un aggiornamento fallito, senza richiedere un intervento di assistenza sul posto.