82 / 86
EMBEDDED
54 • NOVEMBRE • 2014
82
SOFTWARE
CRITICAL OS
container, sottosistemi, spazi di elaborazione partizionati,
e isolati gli uni dagli altri, in cui possono girare diversi SO.
Ciascun sottosistema dispone di una certa quantità di me-
moria allocata e protetta, di risorse di elaborazione e di
I/O. Attraverso un’architettura di questo tipo, l’obiettivo è
assicurare che il software e i processi che girano in una
zona non condizionino il funzionamento e le prestazioni del
software e dei processi attivi in un’altra. E soprattutto che
il malfunzionamento o il crash dei processi di un sottosiste-
ma non provochi l’arresto del software che gira negli altri
container.
Grazie a queste caratteristiche, il concetto di consolidamen-
to in uno stesso apparato di diverse applicazioni e sistemi,
più o meno critici, può trasformarsi in realtà. Un concetto
che da un lato risponde all’esigenza di soddisfare i crescen-
ti requisiti SWaP (size, weight and power) richiesti alle va-
rie applicazioni embedded o ‘deeply embedded’ e, dall’al-
tro, alla necessità di evitare il più possibile la lievitazione di
costi che deriverebbe dall’acquisizione e manutenzione di
piattaforme separate.
Inoltre, sulla stessa piattaforma, sistemi real-time con di-
verso grado di criticità (hard-real-time, o soft-real-time)
sono in grado di girare accanto a sistemi e applicazioni non
real-time, senza rischiare che un’avaria nel funzionamento
di queste ultime possa compromettere l’operatività delle
prime.
I vantaggi di tale approccio si possono riscontrare in diver-
se applicazioni e casi d’uso. Ad esempio, in un’automobile,
il medesimo sistema operativo, su un solo apparato, diventa
in grado di gestire sia le funzionalità safe-
ty-critical (controllo motore, stabilità, im-
pianto frenante e così via), sia l’impianto
di infotainment. Lo stesso può valere per
un aereo di linea, in cui un solo sistema
operativo embedded può amministrare
sia i sistemi e i processi di controllo del
volo, sia la distribuzione dei programmi
e contenuti di intrattenimento per i pas-
seggeri, naturalmente isolandoli in spazi
e ambienti di elaborazione separati e pro-
tetti.
Sicurezza di rete contro safety.
In am-
bito medicale, industriale, automotive o
avionico, i requisiti di safety del SO ser-
vono a garantire il mantenimento della
sicurezza fisica per le applicazioni, impe-
dendo che malfunzionamenti del softwa-
re causino lesioni o addirittura la morte
dell’utente. I sistemi operativi e il sof-
tware embedded safety-critical vengono
tradizionalmente sottoposti a lunghi e scrupolosi processi
di validazione, e possono ottenere diversi livelli di certifi-
cazione, ciascuno atto a garantire determinate funzionalità
(ARINC 653, DO-178 Level A, DO-178 Level B e così via).
Il problema però è che con applicazioni IoT sempre più in-
terconnesse, aumentano i casi d’uso in cui questi sistemi
critici finiscono per interagire in modo indefinito e impre-
vedibile con dispositivi e applicazioni che non sempre han-
no seguito lo stesso, severo percorso di regolamentazione
e certificazione.
La realtà è, ad esempio, che oggi i costruttori del mondo
automotive devono ‘difendersi’ dall’ingresso dirompente
nell’autovettura di dispositivi di elettronica di consumo di
varia natura (smartphone, lettori mp3, console videogio-
chi e così via). È vero, come prima accennato, che esiste
un netta linea di demarcazione fra l’ambiente software di
entertainment e quello dei sistemi critici (freni, sterzo,
controllo stabilità vettura), ma è anche vero che fra i due
ambienti vi sono pur sempre connessioni fisiche. Fra l’al-
tro, per rispondere alla domanda di maggior connettività
e multimedialità da parte dei consumatori, in questi anni i
car maker hanno arricchito diverse categorie di veicoli con
funzionalità Wi-Fi, Bluetooth o connessione a reti cellulari.
E queste feature possono rappresentare potenziali punti di
debolezza e d’ingresso per attacchi di hacking.
Un altro esempio è la proliferazione di accessori e appa-
recchi medicali indossabili (pulsossimetri, cardiofrequen-
zimetri, holter wearable) collegabili in modalità wireless a
smartphone o tablet, unita alla diffusione di altri dispositivi
Fig. 3 – Uno schema delle tecnologie di separation kernel e hypervi-
sor in un SO per applicazioni embedded critiche