EON
ews
n.
572
-
febbraio
2014
25
chi medicali portatili) devono
naturalmente trasmettere e ri-
cevere informazioni. Relativa-
mente a tale aspetto, si rivela
importante garantire ai pro-
gettisti dei sistemi embedded
un facile accesso a molteplici
protocolli di comunicazione,
come quelli relativi al Blue-
tooth low-energy oppure al
WiFi, come anche la possibili-
tà di proteggere la trasmissio-
ne dei dati mediante il suppor-
to delle librerie crittografiche e
della connessione via SSL.
Quando funzioni come la
connettività o l’interfaccia
utente vengono introdotte
all’interno di apparecchiature
dedicate allo svolgimento di
attività particolarmente criti-
che (come, ad esempio, un
apparecchio medicale porta-
tile), è estremamente impor-
tante poter isolare tale nuova
funzionalità desiderata dalla
funzionalità base indispen-
sabile, come il monitoraggio
o il controllo di un parametro
vitale. Tra i possibili metodi
utilizzabili vi è ad esempio
l’uso, anch’esso mediato dal
RTOS, di hypervisors. È inol-
tre importante che il RTOS
fornisca un process model,
una modalità di esecuzione
dei processi, in grado di sup-
portare l’isolamento dei task
e delle librerie, come anche
la protezione della memoria.
Utilizzando un’infrastruttura a
supporto del modello a pro-
cessi, gli sviluppatori possono
isolare tra di loro le diverse
funzioni dell’apparecchiatu-
ra connessa, migliorando la
stabilità dell’intero sistema. È
necessario anche che tutte le
funzionalità dell’apparecchio
possano essere aggiornate e
validate senza che sia neces-
sario ricompilare l’intero stack
software presente a bordo del
dispositivo.
Un’ultima fondamentale ca-
ratteristica delle apparecchia-
ture appartenenti alla IoT è
la necessità di minimizzare i
consumi energetici. Indipen-
dentemente dal fatto che l’og-
getto sia alimentato a batterie
(ricaricabili o non) o funzioni
allacciato alla rete elettrica, la
minimizzazione dei consumi è
sempre importante. Limitando
i requisiti energetici e la cor-
rispondente generazione di
calore, i progettisti sono infatti
in grado di migliorare anche
l’affidabilità del sistema, ridu-
cendo al contempo i consumi.
I produttori di semiconduttori
hanno da tempo introdotto
numerose funzionalità a sup-
porto di tale obiettivo, come
lo scaling dinamico delle fre-
quenze e delle tensioni, o
modalità di risparmio ener-
getico come l’ibernazione e
lo standby, o ancora la capa-
cità di accendere e spegnere
le periferiche. Tuttavia, una
gestione avanzata di queste
caratteristiche
rappresenta
un compito complesso ed
oltretutto dipendente dallo
specifico chip utilizzato. Sfrut-
tando un framework di power
management, con le relative
API, messi a disposizione
da un RTOS, gli sviluppatori
possono invece focalizzarsi
sui requisiti dell’applicazione
finale, demandando al RTOS
evoluto l’onere di eseguire le
molteplici attività necessarie
per ottenere la minimizzazio-
ne dei consumi.
A partire dalle funzioni di con-
nettività intelligente delle ap-
parecchiature, fino ai process
models e alle funzioni di power
management, i sistemi opera-
tivi RTOS hanno certamente
fatto molta strada rispetto al
ruolo di semplici schedulatori
di applicazioni; già oggi essi
consentono di affrontare le
sfide introdotte dalla Internet
of Things, ma subiranno sen-
za dubbio ulteriori importanti
evoluzioni nel prossimo futuro.
I
sistemi operativi real-time
o RTOS (Real-Time Opera-
ting Systems) costituiscono
un elemento chiave per la
piena realizzazione del po-
tenziale insito nella cosiddet-
ta Internet of Things (IoT),
costituita da una
ampia varietà di ap-
parecchiature – og-
gi anche portable o
addirittura weara-
ble – connesse alla
rete e sempre più
presenti nelle case,
nelle automobili e
nelle aziende. Molte
di queste apparec-
chiature presentano
alcuni requisiti fon-
damentali che sono
validamente soddisfatti dai
RTOS, come ad esempio
di
.
Tra i tipici requisiti delle appa-
recchiature della IoT vi sono:
1. Utilizzo di soluzioni sy-
stem-on-chip (SoC) di ridotte
dimensioni e dotate di memo-
ria limitata, quali i microcon-
trollori a 32 bit.
2. Connettività di rete robusta
e che non richieda interventi
da parte dell’utente.
3. Supporto di connessioni
protette, tramite collegamenti
Bluetooth low-energy o WiFi.
4. Isolamento dei processi
chiave e delle funzionalità di
sistema dalle altre funzionalità
non critiche per la sicurezza.
5. Bassi consumi, per con-
sentire il funzionamento a bat-
teria e garantire una maggiore
affidabilità.
Una prima caratteristica ri-
chiesta al RTOS è quella di
presentare una impronta di
memoria minima, ma scala-
bile in funzione delle diverse
necessità di ogni apparec-
chiatura. Il kernel del RTOS
Nucleus, ad esempio, può
partire da una dimensione di 3
kb, progressivamente aumen-
tabile in base alla specifica
applicazione. Man mano che
vengono aggiunte funzionalità
come una interfaccia
utente, delle capaci-
tà di memorizzazio-
ne, o la connettività
sicura via SSL, è
inoltre
importante
che l’impronta del
RTOS cresca solo
del minimo neces-
sario. Ciò assicura al
progettista una mag-
giore flessibilità nella
selezione del SoC,
oltre ad aumentare la
memoria residua resa dispo-
nibile all’applicazione e ai dati
dell’utente.
Apparecchiature come i con-
tatori elettronici evoluti, i co-
siddetti smart meters, devono
essere in grado di collegarsi
automaticamente alla rete
senza alcuna attività di confi-
gurazione, mediante l’uso di
appositi servizi come il mDNS
(Multicast Domain Name Ser-
vice), come anche di descri-
vere le proprie funzionalità
agli altri apparecchi tramite il
protocollo DNS-SD (Domain
Name System Service Disco-
very). Grazie alla disponibilità
di librerie a supporto di tali
standard, un RTOS robusto
può semplificare significativa-
mente una parte dello svilup-
po del sistema.
Dopo essersi connesse a una
rete, le apparecchiature (sia
che si tratti di smart meter, sia
di dispositivi indossabili di mo-
nitoraggio, oppure di apparec-
P
arola
alle
A
ziende
rtos
RTOS: un elemento chiave
per lo sviluppo
del concetto di Internet of Things
Da semplici schedulatori di applicazioni gli RTOS
hanno fatto molta strada
K
amran
S
hah
Kamran
Shah,
director
marketing for
embedded
software di
Mentor Graphics
