EMBEDDED
53 • SETTEMBRE • 2014
62
SOFTWARE
IoT
Un altro aspetto della scalabilità dell’hardware scelto è il sup-
porto alla robustezza del software e del sistema; man mano
che i dispositivi IoT diventano più complessi, l’unità di memo-
ry management (MMU), la memoria virtuale e il supporto per
la virtualizzazione dell’hardware assumeranno un’importanza
sempre maggiore.
Ancora a titolo di esempio, la nuova architettura ARMv8-R
è stata la prima a offrire tutte e tre queste funzionalità in un
design adatto a sistemi di elaborazione embedded e real-time.
Esecuzione run-time
Un RoT di livello hardware sarà del tutto inutile se convalida
un sistema operativo insicuro. Per diverse ragioni, la scelta di
una piattaforma di esecuzione run-time è fondamentale per la
strategia del firmware IoT.
Il kernel è responsabile per la gestione efficiente e sicura di
tutte le risorse del dispositivo. Esistono molti kernel – CMX,
FreeRTOS, uc/OS, MQX, RTXC, T-Kernel, tanto per citarne
alcuni – che offrono servizi di schedulazione, multithreading
e sincronizzazione, sui quali si possono realizzare sistemi IoT
di base.
Ciò che hanno in comune è però l’uso di API proprietarie e l’in-
capacità di sfruttare al massimo l’elevata robustezza hardware
di cui si è parlato.
All’altra estremità della scala c’è Linux. Con la sua licenza
open-source e la diffusa disponibilità di sviluppatori, middle-
ware e applicazioni, Linux ha una posizione innegabilmente
importante nella strategia run-time per l’IoT. Tuttavia, Linux
ha problemi di scalabilità per i sistemi di più ridotte dimensio-
ni, un’elevata interrupt-latency per il real-time e chiare limita-
zioni per l’avvio istantaneo, mancando inoltre di un “pedigree”
che ne garantisca la sicurezza che si vorrebbe avere in una
strategia IoT a lungo termine.
Tra questi due estremi dell’IoT c’è un punto intermedio ideale:
i microkernel. Sistemi operativi monolitici universali, come
Linux, contengono programmi di sistema – ad esempio stack
di networking, file-system e driver per le periferiche – che
condividono un unico spazio di memoria e sono eseguiti in
modalità privilegiata. Ciò si traduce in un’elevata occupazione
di memoria e in notevoli problemi di robustezza, come dimo-
strato dalle diverse vulnerabilità presenti negli smartphone.
Al contrario, un microkernel gestisce un insieme minimo
di servizi e può operare su microcontrollori anche di basso
costo, senza la necessità di MMU e con una ridotta occu-
pazione dello spazio di memoria. Il microkernel supporta
anche processi snelli di memoria virtuale che sono il futuro
dell’IoT. L’esecuzione di middleware e di componenti appli-
cativi in spazi protetti fornisce poi agli sviluppatori dell’IoT un
ambiente molto più robusto e scalabile. La figura 1 illustra la
differenza tra i due approcci, microkernel e monolitico. Per lo
più, i recenti e principali sistemi operativi sono realizzati con
architettura a microkernel e sono alla base praticamente di
qualsiasi dispositivo elettronico, come ad esempio smartpho-
ne, apparecchiature per l’avionica, dispositivi di rete e sistemi
di controllo dei processi. Esempi di sistemi operativi basati su
microkernel comprendono INTEGRITY, Neutrino e PikeOS.
Difficilmente Linux oggi sarebbe monolitico, se fosse stato
creato ai giorni nostri. Come Linus Torvalds dichiarò, più di
20 anni fa: “È vero, Linux è monolitico, e sono d’accordo che
i microkernel sono più belli. Dal punto di vista teorico (ed
estetico) Linux perde la gara”.
Ma la decisione di utilizzare un microkernel piuttosto che
Linux non deve per forza
essere esclusiva; una strate-
gia firmware IoT ben fatta
può sfruttare il real-time, l’in-
gombro e la robustezza del
microkernel, nonché i driver
delle periferiche, il middle-
ware e le applicazioni che
Linux mette a disposizione.
Questa felice coesistenza è
possibile grazie a un sistema
di virtualizzazione, illustrato
in figura 2, come un ser-
vizio messo a disposizione
dal microkernel. Esempi
di hypervisor microker-
nel includono INTEGRITY
Multivisor di Green Hills
Software e alcune varianti
del microkernel L4.
Fig. 3 – Popolarità di WS - * e di RESTful Web Services a confronto
