Bare-metal, RTOS o Linux embedded? La risposta dipende dal prodotto, non dal team. In ambito industriale un dispositivo deve funzionare per anni, spesso decenni. La scelta della piattaforma software ha conseguenze su determinismo, aggiornabilità, sicurezza e costo di manutenzione che si vedono tardi, quando cambiarla costa troppo: al primo aggiornamento sul campo, alla prima certificazione, al primo cambio di fornitore hardware. Mettiamo a confronto le tre architetture con criteri concreti, per chi progetta sistemi embedded per l’automazione e l’IIoT.
Non esiste la scelta giusta. Esiste quella adatta
In automazione contano robustezza, ripetibilità e manutenibilità nel tempo. Non performance pura. Un sistema che fa tre cose in modo deterministico per vent’anni vale più di uno che fa tutto ma va aggiornato ogni sei mesi. È una decisione di sistema: ciclo di vita, determinismo, aggiornamento remoto, footprint, certificazione.
Serve davvero un kernel se il codice fa sempre la stessa cosa? E se un domani serve aggiornare il firmware via rete, il sistema è pronto?
Bare-metal: controllo totale, zero overhead
Quando ha senso
Il codice gira sull’hardware senza scheduler e senza astrazione. Tutto è polling o interrupt-driven. Nessun context switch, nessun overhead di kernel. Sai esattamente cosa esegue la CPU in ogni istante, e il boot si misura in microsecondi. Ha senso per dispositivi che fanno una cosa sola in modo ciclico con requisiti di latenza hard real-time: sensori con output digitale a ciclo fisso, attuatori dedicati, driver per convertitori A/D critici. Chi lavora con firmware embedded sa che il bare-metal è il punto di partenza naturale per molti progetti.
Dove si rompe
Non appena servono più periferiche, comunicazione, o una seconda funzione in parallelo, il super-loop scricchiola. Nessuna gestione task. Nessuna standardizzazione degli aggiornamenti. Debug spesso manuali. Il rischio concreto: ritrovarsi con uno scheduler scritto internamente, non documentato e impossibile da certificare. Molti progetti partono bare-metal e finiscono per reinventare metà di un RTOS, male.
RTOS: determinismo con struttura
Un RTOS è un kernel real-time: multitasking preemptive, priorità, IPC (code, semafori, mutex), watchdog. Non è un sistema operativo completo. È la struttura minima per gestire più task con garanzie di tempo.
Cosa offre in ambito industriale
Scheduling a priorità fisse con determinismo controllato. Footprint contenuto: FreeRTOS gira in circa 9 KB di Flash e 2 KB di RAM su un Cortex-M4; Zephyr parte da circa 18 KB di Flash e 4 KB di RAM ma include un sistema di build moderno (devicetree + Kconfig) che rende il firmware portabile tra MCU di vendor diversi senza riscrivere il layer hardware. Nel 2026, Zephyr è il progetto RTOS open-source più grande per commit e sviluppatori, con il supporto di Nordic, Intel, NXP, ST, TI. Il 65% dei progetti IoT usa un RTOS (dato Aspencore). Chi conosce i sistemi real-time e le criticità del determinismo sa che un RTOS ben configurato copre la maggior parte dei requisiti di timing industriali.
Cosa sapere prima di scegliere
Ogni RTOS ha le sue API, il suo stack, la sua toolchain. Non c’è uno standard unico. Aggiungere networking sicuro o OTA è possibile (MCUboot su Zephyr, AWS IoT OTA su FreeRTOS) ma non immediato. La certificazione safety (IEC 61508, ISO 26262) è più accessibile su RTOS che su Linux: il kernel è piccolo, il codice analizzabile, le toolchain di verifica consolidate. Per chi lavora su RTOS safety-critical, il processo è familiare.
Un vantaggio pratico di Zephyr che vale la pena conoscere: se il fornitore del SoC cambia (per problemi di supply chain, ad esempio), il porting su un altro vendor richiede la modifica di un overlay devicetree e un rebuild. Il codice applicativo non si tocca. Con FreeRTOS, il layer di astrazione hardware è specifico per vendor, e il porting significa riscrivere l’integrazione. Per prodotti con ciclo di vita lungo, questa differenza pesa.
Linux embedded: potenza e complessità
Dove è insostituibile
Networking avanzato (TCP/IP, TLS, OPC UA, MQTT). Aggiornamenti remoti con rollback (Mender, RAUC, SWUpdate). Container, logging strutturato, filesystem completo. Toolchain standardizzata (Yocto, Buildroot). Interfacce HMI con touchscreen. Se il dispositivo è un gateway edge, un HMI industriale o un nodo che deve essere aggiornabile da remoto, Linux embedded è la scelta razionale. L’ecosistema è maturo e la disponibilità di sviluppatori è superiore a qualsiasi RTOS.
I costi nascosti
Boot lento (tipicamente secondi, non millisecondi). Serve un Cortex-A con almeno 256 MB di RAM. Il determinismo real-time è limitato anche con PREEMPT_RT: latenze sotto il millisecondo sono raggiungibili con CPU isolation e IRQ affinity, ma servono tuning attento e test specifici per ogni piattaforma. Non è la stessa cosa di un RTOS dove lo scheduling è deterministico per design. La build di un’immagine Linux custom con Yocto ha una curva di apprendimento non banale. E una domanda che pochi si fanno all’inizio: il BSP del tuo SoC sarà ancora mantenuto tra 7 anni? Chi ha affrontato il tema degli approcci low-code per microcontrollori conosce il peso della complessità della toolchain embedded Linux.
Sei criteri per decidere
La scelta non si fa sulla CPU. Si fa su parametri che impattano il ciclo di vita del prodotto.
- Complessità software: bare-metal minima, RTOS media, Linux alta.
- Determinismo: bare-metal massimo, RTOS alto, Linux medio (migliorabile con PREEMPT_RT ma con limiti).
- Gestione rete: bare-metal minima o manuale, RTOS in crescita (lwIP, mbedTLS), Linux completa.
- Filesystem: bare-metal no, RTOS limitato (LittleFS), Linux completo.
- Boot time: bare-metal sotto il ms, RTOS sotto i 10 ms, Linux sopra i 100 ms.
- OTA: bare-metal assente, RTOS possibile (MCUboot), Linux standardizzabile (Mender, RAUC).
C’è un settimo parametro, spesso trascurato: la manutenibilità a lungo termine. Un RTOS con API proprietarie e senza LTS diventa debito tecnico. Un Linux con BSP non mantenuto idem. Il costo futuro della scelta supera quasi sempre il costo iniziale di sviluppo. Per chi ha affrontato il tema delle soluzioni software embedded real-time, la gestione del ciclo di vita è familiare.
La piattaforma software impatta manutenzione, sicurezza e ciclo di vita del dispositivo. Approfondisci: Bare Metal, RTOS, and Embedded Linux — Witekio
Aggiornamenti, certificazione, sicurezza
Una piattaforma perfetta per il prototipo può fallire quando serve aggiornarla o certificarla.
OTA con rollback: nativo su Linux (Mender, RAUC), in maturazione su RTOS (MCUboot su Zephyr, con schema A/B e firma crittografica), assente su bare-metal salvo implementazioni custom. Certificazione safety (IEC 61508, ISO 26262): l’RTOS è spesso la via più percorribile per kernel piccolo e codice analizzabile.
Linux richiede sforzo di hardening e timing analysis maggiore. Bare-metal è certificabile ma il costo scala con la complessità.
Cybersecurity: la superficie di attacco cresce con il software. Linux ha più superficie ma anche più strumenti (SELinux, AppArmor, namespace). Un RTOS ha meno superficie e meno strumenti. Bare-metal ha la superficie minima ma la sicurezza è tutta a carico dello sviluppatore. Dal 2024, la scoperta di una backdoor piantata da un contributore in un pacchetto core di Linux (xz-utils) ha dato ulteriore peso all’argomento: meno codice, meno superficie, meno rischio.
Con il Cyber Resilience Act europeo in vigore, la sicurezza del firmware non è più opzionale per nessuna architettura.
Quando scegliere cosa: casi d’uso industriali
Bare-metal
Sensore con output digitale a ciclo fisso. Driver per convertitore in real-time critico. Attuatore dedicato con latenza garantita sotto i 10 µs. Se il firmware non cambierà e non serve rete, il bare-metal è la scelta più efficiente.
RTOS
Sensore edge con logica locale e comunicazione. Attuatore intelligente con più modalità operative. Nodo con CANopen, Modbus o IO-Link. Controller per sistemi di monitoraggio industriale. Se servono più task, comunicazione e determinismo, l’RTOS è la risposta nella maggior parte dei casi.
Linux embedded
Gateway edge con OPC UA, MQTT, REST. HMI industriale con touchscreen. Nodo aggiornabile da remoto con logging e container. Edge AI con TensorFlow Lite o ONNX. Se il dispositivo deve essere un piccolo computer connesso e aggiornabile, Linux è l’unica opzione realistica.
La scelta come decisione di sistema
La tentazione è scegliere la piattaforma che il team conosce. Comprensibile, ma rischioso. Chi parte bare-metal e poi scopre di aver bisogno di OTA e multitasking finisce per costruire uno scheduler artigianale. Chi parte Linux per un dispositivo che fa tre cose semplici paga in boot time e complessità di manutenzione per tutta la vita del prodotto. La scelta parte dai requisiti, non dalla familiarità. E la risposta può essere ibrida: un Cortex-M con RTOS per il controllo critico, affiancato a un Cortex-A con Linux per connettività e interfaccia. L’approccio multicore asimmetrico è sempre più diffuso nei SoC industriali, e per chi progetta sistemi embedded per l’Industria 4.0 è spesso il compromesso migliore tra determinismo e flessibilità.
In definitiva, la piattaforma software è una decisione di ingegneria di sistema, non di preferenza personale. I vincoli del prodotto vengono prima delle abitudini del team. E nel dubbio, la domanda giusta non è “qual è la piattaforma migliore?” ma “quale piattaforma rende il prodotto mantenibile, aggiornabile e certificabile per tutto il suo ciclo di vita?”
