Università Politecnica delle Marche
CORSO DI LAUREA SPECIALISTICA IN INGEGNERIA ELETTRONICA
ANNO ACCADEMICO 2005 – 2006
STUDIO COMPARATO DEI PRINCIPALI SISTEMI
OPERATIVI IN TEMPO REALE
Relatore: Chiar.mo
Prof. Aldo F. Dragoni
Tesi di Laurea di:
Colella Guido
SOMMARIO

Introduzione ai sistemi operativi real-time;

Passaggio dagli OS ai sistemi operativi di natura realtime;

Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI;

Un’estensione firm real-time di Linux: il KURT;

TinyOS e Mantis: uno sguardo all’immediato futuro
degli RTOS;

Conclusioni sullo studio dei sistemi operativi realtime;
2
EVOLUZIONE DEI CALCOLATORI
ELETTRONICI
Introduzione ai sistemi operativi real-time
3
APPLICAZIONI DEI SISTEMI OPERATIVI
REAL-TIME (1)
Introduzione ai sistemi operativi real-time
4
APPLICAZIONI DEI SISTEMI OPERATIVI
REAL-TIME (2)
…e ancora :








Controllo sismico
Controllo del microclima in edifici
“Sensing” per la sicurezza e strategico
Domotica & elettronica consumer
Musei interattivi
Agricoltura intelligente
Navigazione robotica
…….e tantissime altre
Introduzione ai sistemi operativi real-time
5
SCENARIO DI UN SISTEMA OPERATIVO
REAL-TIME

All’interno di tali contesti applicativi
gli RTOS (acronimo di Real-Time
Operative System) si collocano
come:
1. Sistemi operativi capaci di eseguire tutti i propri “tasks” senza violare specifici vincoli
temporali;
2. Il tempo di esecuzione dei tasks può essere calcolato a priori e in modo
deterministico sulla base della configurazione sia hardware che software del sistema;
3. Sistemi contraddistinti dal fatto che, la correttezza della risposta dipende non solo dai
valori che assume l’uscita dell’elaboratore ma anche dal tempo in cui questi vengono
prodotti; pertanto, il tempo del sistema deve essere necessariamente sincronizzato con il
tempo dell’ambiente circostante
Introduzione ai sistemi operativi real-time
6
OSSERVAZIONI SUL REAL-TIME

E’ importante sottolineare alcune caratteristiche che contraddistinguono un
RTOS che spesso possono dar luogo ad equivoci o ad interpretazioni errate
specie per chi si avvicina per la prima volta in tale contesto:
Anzitutto, un sistema in tempo reale non è necessariamente un sistema
veloce; ossia “real-time” non è sinonimo di “veloce” ;
Il concetto di velocità è sempre relativo ad uno specifico ambiente;
La velocità deve comunque garantire la correttezza;
L’obiettivo di un RTOS è quello di garantire la tempistica di ogni singolo
task, mentre l’obiettivo di un sistema veloce è quello di minimizzare il tempo
medio di risposta dei vari tasks;
Il tempo medio di risposta non può essere preso come un parametro
significativo nel real-time;
Introduzione ai sistemi operativi real-time
7
RTOS ALL’INTERNO DELLA SCALA
GERARCHICA DEGLI OS




Ha delle periferiche di I/O che sono
architetture di calcolatori diffuse in ambiente
industriale e biomedico;
La memoria di massa non è un disco fisso
bensì una memoria flash;
è un sistema “speciale” che deve solo
assolvere il compito specifico per cui è stato
programmato
i sistemi Real-time possono essere
considerati Embedded ma non viceversa
devono soddisfare precisi vincoli
temporali per quel che concerne
l’esecuzione dei propri tasks;
 devono essere caratterizzati non
dalla velocità di esecuzione
(parametro insignificante per il
real-time), ma dalla “predicibilità”
in quanto real-time non è sinonimo
di “veloce” ma di “predicibile”;
Introduzione ai sistemi operativi real-time
8
CAUSE DI INDETERMINISMO

Si nota che per realizzare un valido sistema real-time, bisogna cercare di
“emarginare”, nella maniera più efficace possibile, o quanto meno ridurre,
le cause di indeterminismo che affliggono l’esecuzione di ogni singolo task.
Queste ultime possono essere di diversa natura:
1. Architetturiale
- Cache, pipelining, interruptus, DMA;
2. Operativo
- Scheduling, sincronizzazione, comunicazione;
3. Linguaggio
- Non hanno esplicito supporto per il tempo;
4. Metodologie progettuali
- Mancanza di tecniche di analisi e verifica.
Introduzione ai sistemi operativi real-time
9
PREDICIBILITA’ IN FUNZIONE DELLA
TIPOLOGIA DI SCHEDULER

da un’analisi superficiale potrebbe risultare che solamente scheduler ciclici
garantirebbero un alto valore di predicibilità;

la scelta di uno scheduler diverso da quello ciclico, garantisce ancora
predicibilità
Scheduler ciclico: tasks attivati sempre in
maniera predefinita
Determinismo
Scheduler basato sulle priorità: tasks attivati in
base a priorità e ready queue, ma a livello
macroscopico il comportamento può essere
predetto
La predicibilità è un requisito di correttezza per le applicazioni real-time
Introduzione ai sistemi operativi real-time
10
SOMMARIO

Introduzione ai sistemi operativi real-time;

Passaggio dagli OS ai sistemi operativi di natura realtime;

Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI;

Un’estensione firm real-time di Linux: il KURT;

TinyOS e Mantis: uno sguardo all’immediato futuro
degli RTOS;

Conclusioni sullo studio dei sistemi operativi realtime;
11
PREMESSA

Per un’analisi più prolifica delle numerose famiglie di RTOS è opportuno
scindere il problema alla base diversificando anzitutto almeno due tipologie
implementative:
 Sistemi RTOS progettati appositamente che non
si basano su OS già esistenti sul mercato;
 Sistemi RTOS ottenuti mediante l’adattamento
di OS originari già esistenti sul mercato;

Per la realizzazione di tale elaborato si è fatto riferimento quasi
esclusivamente alla prima tipologia implementativa, ed in particolar modo
a sistemi derivanti dalla piattaforma Linux consentendo quest’ultima
risorse di tipo “Open Source” ed un ottima documentazione di base.
Passaggio dagli OS ai sistemi operativi di natura
real-time
12
CARATERISTICHE STRUTTURALI DI LINUX
OS : LO SCHEDULING

la politica del Time-sharing letteralmente “uccide” il real-time perché in
quest’ultimo il tempo di esecuzione deve essere conosciuto a priori, mentre
in Time-sharing non è affatto predicibile.
Passaggio dagli OS ai sistemi operativi di natura
real-time
13
PROBLEMATICHE PER IMPLEMENTAZIONE DI
LINUX IN REAL-TIME
Dati relativi al kernel 2.4

Lo scheduler di Linux ha un taglio “general purpose”.Ciò sostanzialmente è fatto per
distribuire equamente le risorse ai tasks in esecuzione;

Attualmente Linux non fornisce alcuna interfaccia per comunicare allo scheduler la
possibile natura real-time di un task o dati specifici circa il suo timing (deadlines,
computational times…);

Il kernel non è preemptable (ciò significa sostanzialmente alta latenza di scheduling
per scenari real time);

Kernel Control Path non interrompibili( ma piuttosto reentrant, quindi annidabili)
introducono in determinismo nel sistema;

Kernel non ancora 100% reentrant(alcune funzioni disabilitano gli interrupt
globalmente sulla CPU corrente per preservare strutture dati condivise). Tali
funzioni sono interrompibili solo attraverso un NMI;

La frequenza massima di richiamo della schedule() di Linux è 10ms(corrispondente
al minimo time-quantum) che non risulta sufficiente per scenari real-time e
oltretutto non vi è alcuna garanzia su tale periodo.
Passaggio dagli OS ai sistemi operativi di natura
real-time
14
LA LATENZA IN LINUX

Latenza di scheduling : distanza temporale tra il segnale (stimolo) di
wakeup che un evento è accaduto e l’istante in cui lo scheduter lancia il
thread che è in attesa che quel segnale arrivi (risposta).
 Interrupt latency;
aumentano
 Interrupt Handler duration;
 Scheduler Latency;
 Scheduling duration;
Response Time
riducono
 Preemption patches
lanciare
più frequentemente la schedule();
 Low latency patches
introduzione di punti di prelazione
nel codice del kernel
Passagio dagli OS ai sistemi operativi di natura
real-time
15
CON KERNEL 2.6 SI VA VERSO IL REAL
TIME
 Punti salienti:

Modifica della struttura generale dello scheduler (ad esempio, invece di
un’unica coda per tutti i task del sistema esiste una coda per ognuno dei 140
livelli di priorità su ogni CPU);

Frequenza interna del clock portata da 100 Hz (kernel 2.4) a 1000 Hz;

Parte del kernel è divenuta preemptable;

Eliminati numerosi “Big Locks”;

Compatibilità con Preemption e Low Latency Patches;

Migliorato il sistema di gestione di I/O.
 risultati:
Linux 2.6.9
without
Preemption
patch
Passaggio dagli OS ai sistemi operativi di natura
real-time
Linux 2.6.9
with
Preemption
patch
16
PREDISPOSIZIONE DI LINUX AD UNA
POLITICA REAL-TIME

Linux è un sistema operativo di alto livello ed è Open Source;

E’ molto ben documentato;

Nasce nell’ambiente universitario ed è naturalmente inserito in svariati
contesti di ricerca;

E’ compatibile con i maggiori standard relativi al software (POSIX etc…);

Ha buone prestazioni già in versioni base (senza modifiche strutturali);

La struttura monolitica lo rende adatto ad essere utilizzato in scenari
Embedded;

Il mondo dell’industria è interessato ad applicazioni di Linux in svariati
settori: GPS (Global Positioning System), HDTV (High Definition TV), DVBRCS, cellulari, PDA, space segment, signal processing, radar system,
robotica…

Sono attualmente disponibili numerose implementazioni di architetture
software Open Source per modificare Linux dotandolo di funzionalità realtime da cui attingere spunto…
Passaggio dagli OS ai sistemi operativi di natura
real-time
17
STRATEGIE PER IL REAL-TIME IN LINUX

Esistono due possibili approcci:
Il PREEMPTABLE
KERNEL sostituisce
gran parte del kernel
di Linux
Il RESURCE KERNEL
gestisce il kernel di Linux
come un normale task a
bassa priorità
Passaggio dagli OS ai sistemi operativi di natura
real-time
18
PANORAMICA DEI SISTEMI OPERATIVI
REAL-TIME PRESENTI SUL MERCATO:
DISTRIBUZIONI COMMERCIALI
RTLinuxPro(FSMLabs). RTCore fornisce un ambiente real-time POSIX in
cui Linux gira come task a bassa priorità. Limiti prestazionali: quelli dell’
hardware. Latenza di scheduling sotto 20 microsecondi sulla maggior parte
delle piattaforme.
MontaVista RTLinux. Basato su miglioramenti a MontaVista Linux.
Preemptable kernel + real-time scheduler + frameworks.
BlueCat RT (LynuxWorks). Microsistema operativo real-time (non Linuxbased) che gira Linux come processo a bassa priorità. BlueCat RT è
incentrato sulle basse latenze di interrupt raggiunte grazie al core
ridottissimo e altamente performante.
uLinux (Lineo Solutions). Footprint ridottissimo, tempi di startup e
shutdown minimi, prestazioni real-time rendono adatto questo OS made in
Japan per l’utilizzo nell’elettronica (dispositivi embedded).
FlightLinux (NASA). Versione real-time di Linux adattata ad applicazioni
spaziali al Goddard Space Flight Center e testata sullo Space Shuttle
(progetto nato come Open Source ma i sorgenti non sono attualmente
pubblicati).
Passaggio dagli OS ai sistemi operativi di natura
real-time
19
PANORAMICA DEI SISTEMI OPERATIVI
REAL-TIME PRESENTI SUL MERCATO:
DISTRIBUZIONI OPEN SOURCE

RTLinux. Hard Real Time mini sistema operativo che gira Linux come
processo a minima priorità rendendolo totalmente preemptable. L’ultima
versione supporta user-space RT programming. La versione MiniRTL è
adatta ad utilizzi embedded.

RTAI (Dipartimento di Ingegneria Aerospaziale del Politecnico di
Milano). Simile ad RTLinux ma con varie funzionalità in più tra cui LXRT
Layer che permette di controllare task real-time dallo user-space memoryprotected di Linux . AtomicRTAI è la versione a ridotto footprint.

KURT. The Kansas University RealTime Linux. Implementazione realtime di Linux che permette lo scheduling degli eventi con periodo di 10
microsecondi.

RED-Linux. Ridotti kernel blocking times, rapidi tempi di risposta,
scheduler modularizzato “modificabile” a runtime. Università della California,
Irvine.

QLinux. Implementazione tagliata per garantire caratteristiche di QoS per
task soft real-time. Tagliata per l’utilizzo in applicazioni multimediali,
telefonia mobile…
Passaggio dagli OS ai sistemi operativi di natura
real-time
20
SOMMARIO

Introduzione ai sistemi operativi real-time;

Passaggio dagli OS ai sistemi operativi di natura realtime;

Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI;

Un’estensione firm real-time di Linux: il KURT;

TinyOS e Mantis: uno sguardo all’immediato futuro
degli RTOS;

Conclusioni sullo studio dei sistemi operativi realtime;
21
RTLINUX : UN’AGGIUNTA HARD REAL-TIME
A LINUX (1)
RTLinux, sviluppato originariamente nell’Istituto di Tecnologia del New Mexico, si
pone in commercio come un prodotto “open-source”. Componenti specifici di
RTLinux vengono rilasciati sotto licenza GPL, mentre i componenti di Linux vengono
rilasciati sotto la licenza di Linux standard. Il codice sorgente viene liberamente
distribuito. Le versioni non a licenza GPL dei componenti di RTLinux sono disponibili
tramite gli FSMLabs.
RTLinux è un sistema operativo hard real-time che gira in Linux come il suo thread
di esecuzione a più bassa priorità.
 Il thread di Linux è reso completamente prelazionabile così che i threads real-time
ed i gestori di interrupts non possano venir mai ritardati da operazioni non real-time.
 Le
applicazioni real-time consistono in tasks real-time che sono incorporati in moduli
caricabili del kernel ed in processi di Linux/Unix che si occupano dei registri dati, del
display, dell’accesso alla rete, e di altre funzioni che non sono vincolate da una
caratterizzazione del comportamento nel caso peggiore (worst case).
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
22
RTLINUX : UN’AGGIUNTA HARD REALTIME A LINUX (2)

I threads real-time in RTLinux possono comunicare con i processi Linux
attraverso una memoria condivisa oppure mediante una particolare interfaccia
simile ad un file
in tal modo le applicazioni real-time possono far uso di tutti
i potenti servizi non real-time di Linux (incluso Networking, Grafica, Sistemi
Windowing, Packages per l’analisi dei dati, Drivers per Linux, standard POSIX
API).

Per esempio è piuttosto semplice comporre uno script che visualizzi dati in
Xwindows, risponda a comandi trasmessi da rete e collezioni dati da un task
real-time.

In pratica, l’approccio ad RT-Linux ha avuto molto successo in quanto si è
dimostrato essere un approccio vincente. La latenza di interrupt nel caso
peggiore su un PC 486 a 33 MHz si assesta ben sotto i 30 µs, vicino al limite
dell’hardware.

Molte applicazioni sembrano trarre beneficio da una “sinergia” tra il sistema
real-time ed il sistema operativo standard ottimizzato (average case). Per
esempio, le applicazioni di acquisizione dati sono spesso composte da un
semplice polling o un task real-time di tipo interrupt-driven che conduce i dati
attraverso una coda al processo Linux che si occupa di gestire il logging ed il
display.
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
23
VERSIONI…
 RTLinux V3
Beta. E’ stato
immesso sul
mercato il 3
Gennaio del 2000
e rispetto alle
precedenti versioni
essa aggiunge il
supporto PowerPC
 RTLinux V1. Si tratta di un
sistema eccezionalmente stabile
che viene utilizzato sia in
prodotti commerciale che in
ambienti di laboratorio. Fornisce
inoltre una semplice libreria API
per eseguire, iniziare, e fermare
lo scheduling dei tasks realtime.
 RTLinux V2. Offre una versione semplificata dell’ API dei
pthreads POSIX ed è conforme allo standard “Minimal Realtime” di POSIX (all’interno del quale un componente realtime è considerato un processo POSIX singolo e
multithread). L’obiettivo del kernel V2 è senza dubbio quello
di accostarsi il più possibile allo standard POSIX, senza
attuare alcun sacrificio dal punto di vista della semplicità e
velocità del sistema, ma al tempo stesso fornendo spunti ed
aggiunte per realizzare una piena compatibilità con POSIX.
V2, messo sul mercato nel Novembre del 1999, è un sistema
x86 capace di SMP.
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
24
STORIA DI RTAI

Al fine di rendere Linux utilizzabile per applicazioni hard real-time, i membri
del Dipartimento di Ingegneria Aerospaziale del Politecnico di Milano
(DIAPM) crearono un livello di astrazione hardware real-time (RTHAL) sul
quale poter implementare un interfaccia per applicazioni real-time RTAI.

Sfortunatamente, ulteriori indagini rivelarono che il kernel di Linux
disponibile nel vicino 1996, ovvero il 2.0.25, non era ancora pronto ad
accogliere tale innovazione.

Nello stesso periodo, un gruppo capeggiato da Victor Yodaiken all’Istituto
del New Mexico of Minino and Technology (NMT) , introdusse la sua
versione real-time di Linux (RTLinux) che fornì al team DIAPM l’opportunità
di apprendere ulteriori nozioni sul kernel di Linux, sull’ hardware e sulle
modifiche necessarie a rendere prelazionabile e deterministico lo
scheduling.

Il punto di svolta ci fu poi nel 1998 quando fu sviluppato il kernel di Linux
2.2.x che ebbe come punto di forza i noti miglioramenti proposti
dall’RTLinux, incluso le molte e necessarie modifiche architetturiali
all’interfaccia Linux/hardware.

Tali modifiche, combinate con l’esperienza acquisita dal team DIAPM
durante il loro lavoro di evoluzione dell’NMT-RTLinux kernel, e con le nozioni
informatiche del 1996, sfociarono nella creazione della piattaforma RTAI.
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
25
CARATTERISTICHE DI RTAI

RTAI è un sistema operativo “guaranteed-based” che assicura uno scheduling
hard real-time ed inoltre conserva tutte le caratteristiche ed i servizi del Linux
standard.

In aggiunta, RTAI fornisce un supporto sia per UP che per SMP con la capacità
di assegnare sia tasks che IRQs alle specifiche CPUs, x486 e Pentiums,
schedulers one-shot e periodici, sia inter-Linux che intra-Linux shared memory,
compatibilità con lo standard POSIX, supporto FPU, sincronizzazione tra tasks,
semafori, sincronizzazione mutua, code per messaggi, RPCs, mailboxes, la
possibilità di utilizzare le system call RTAI direttamente da dentro lo user-space
standard, e tante altre funzionalità.
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
26
RTAI: REAL-TIME APPLICATION INTERFACE

RTAI supporta ben 5 moduli caricabili del core che conferiscono al
sistema le proprietà real-time desiderate “a richiesta”(on-demand)
 rtai, che fornisce la struttura base rtai;
 rtai_fifos, che altro non è che un adattamento di NMT RTLinux FIFOs (file
in, file out);
 rtai_sched, che fornisce al sistema uno scheduling one-shot oppure periodico;
 rtai_mups, che consente l’uso simultaneo degli schedulers one-shot e periodico
oppure di due schedulers periodici, ognuno avente il proprio clock di base
differente;
 rtai_shm, che alloca la memoria propria di inter-Linux tra i tasks real-time ed i
tradizionali processi di Linux, ed anche intra-Linux come sostituto per UNIX V
IPC;

Come tutti i moduli del kernel, questi possono essere caricati in memoria e
deallocati da essa (usando rispettivamente i comandi standard di Linux insmod
ed rmmod) quando le loro rispettive funzionalità sono richieste o meno
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
27
SCHEMA ARCHITETTURIALE

Per ogni implementazione, il sistema operativo
Linux è eseguito come il task a più bassa priorità
di un piccolo sistema operativo real-time.

Pertanto Linux non apporta cambiamenti alle sue
operazioni sia dal punto di vista utente che dal
punto di vista kernel, eccetto quello di permettere
l’esecuzione solo quando non ci sono già tasks
real-time che devono essere eseguiti.
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
28
ARCHITETTURA INTERNA
riduce i cambiamenti al kernel
file di source del kernel che si manifestano standard di Linux mediante l’aggiunta di un
in modifiche ed aggiunte ai numerosissimi livello di astrazione hardware (HAL) composto
da una struttura di puntatori a vettori di
files sorgenti del kernel di Linux
interrupt e da funzioni che permettono di
aumento del codice da memorizzare
abilitare/disabilitare gli interruptus
 RTLinux applica molti cambiamenti ai
 RTAI
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
29
STRUTTURA COMPLETA DI RTAI

L’HAL viene implementato modificando meno di 20 linee di codice esistente, ed
aggiungendo circa 50 linee di nuovo codice. Questo approccio è sicuramente
più elegante in quanto minimizza l’investigazione del kernel standard di Linux e
localizza più facilmente il codice di gestione degli interrupt.

Un altro vantaggio della tecnica HAL è che mediante essa è possibile far tornare
Linux al suo ruolo standard (general-purpose) cambiando semplicemente la
posizione dei suoi puntatori dalla struttura RTHAL (real-time) a quella originale.
Ciò si è dimostrato abbastanza utile quando le operazioni real-time sono inattive
o quando si prova ad isolare virus di natura oscura.
“…Molti studiosi
suppongono che il livello
HAL possa causare
inaccettabili ritardi e latenze
per via del percorso di
analisi e monitoraggio dei
tasks real-time. In realtà
negli ultimi anni l’impatto
dell’HAL sulle performances
del kernel è divenuto
trascurabile per via della
maturità e del progetto del
kernel di Linux…”
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
30
RTAI: SCHEDULERS E TIMERS SUPPORTATI

Si nota che dal momento che il MUP utilizza l’APIC
(advanced programmable interrupt controller) timer,
esso non può operare sotto SMP e richiede pertanto
che ogni task scedulato MUP sia eseguito all’interno di
una specifica CPU (da qui la designazione
MultiUniProcessor). Comunque il MUP conserva tutte
le coordinate ed i servizi IPC in modo che le altre
proprietà non vengano perse
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
31
RTLinux vs RTAI

La seguente tabella riassume in maniera alquanto semplice le principali differenze
risultanti dall’analisi svolta dei due RTOS. Ovviamente non vengono incluse le
caratteristiche che caratterizzano entrambi i sistemi:
RTLinux
RTAI
Company
FSM Labs
DENX Software Engineering,
Pengutronix and
Sysgo Realtime Solutions
Arch
i386, PPC, ARM
i386, MIPS, PPC, ARM, m68k-nommu
License
GPL - Comercial
LGPL - GPL
API
POSIX
custom
Memory
shared
dynamic and shared
Debug
GDB, Event tracer
Cross GDB, LTT
IPC
FIFO's
FIFO's, Named FIFO's, Mailboxes, messages, PQueues, net_rpc
User space Real Time
Signal handlers
LXRT soft, LXRT hard, Mini LXRT
Misc
RT-Lab
Octave, proc, Watchdog, Scripting, Xenomai
Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI
32
SOMMARIO

Introduzione ai sistemi operativi real-time;

Passaggio dagli OS ai sistemi operativi di natura realtime;

Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI;

Un’estensione firm real-time di Linux: il KURT;

TinyOS e Mantis: uno sguardo all’immediato futuro
degli RTOS;

Conclusioni sullo studio dei sistemi operativi realtime;
33
L’RTOS KURT

Il KURT (acronimo di Kansas University Real Time Linux) altro non è che una
modifica real-time (firm) al sistema operativo Linux, che consente lo scheduling di
eventi real-time alla risoluzione di 10µs.

Piuttosto che contare su uno scheduling basato su priorità o su “rigidi” schedules
periodici, schedules del sistema operativo KURT sono esplicitamente specificati dal
programmatore dell’applicazione.

KURT può tuttavia funzionare in due modi: “focussed mode”, dove solo ad i processi
real-time è permessa l’esecuzione; ed il “mixed mode”, dove l’esecuzione dei processi
real-time ha ancora la precedenza, ma è consentito a tutti i processi non real-time di
essere eseguiti purchè all’interno dei “buchi” dello schedule real-time.

Una semplice system call permette il passaggio tra le due modalità.

Il KURT “gira” su una piattaforma compatibile x86 con un contatore di tipo “timestamp” (ossia i processori Pentium o i loro equivalenti).

Effettuare il “porting” di KURT ad altre architetture, richiede tuttavia solo minime
aggiunte.
Un'estensione firm real-time di Linux : il KURT
34
KURT: CONCETTI CHIAVE

Real time framework
il KURT si compone di una struttura real-time
(framework) che si preoccupa di realizzare lo scheduling di eventi real-time. Quando
un evento real-time sta per essere eseguito, la struttura real-time chiama il gestore
degli eventi (event handler) dell’ RTmod associato.

RTMods
moduli real time, ovvero moduli del kernel che possono essere caricati
a “runtime” ottimizzando così certe azioni quando vengono invocati. Gli sviluppatori
della piattaforma KURT hanno scritto un RTMod che cambia il contesto al processo
utente specificato non appena è invocato.

Lo schedule real-time
è un file che specifica come ed in che momento
l’RTMod necessiti di essere invocato. Questo schedule viene poi passato al
framework real-time che si prende cura dello scheduling di ogni evento invocando,
nel momento giusto, l’appropriato gestore degli eventi. Gli sviluppatori del KURT
hanno realizzato un semplice programma che genera questo schedule;

rt-id
altro non è che il numero identificativo associato ad ogni processo del
KURT. Ogni processo del KURT può infatti richiedere (o essere dato da) un rt-id non
appena esso viene registrato nel modulo di processo settando set_rtparams. Un
processo KURT può modificare il suo rt_id utilizzandola medesima system call;

Registrazione degli RTMods
un RTMod registra se stesso all’interno del
framework real-time provvedendo ad un nome, a dei puntatori a funzione per i
gestori degli eventi, all’inizializzazione, ed alla sua eventuale ripulitura(clean up).
Quando un modulo real-time viene registrato, gli viene assegnato un numero
identificativo che viene utilizzato per schedulare i suoi eventi;
Un'estensione firm real-time di Linux : il KURT
35
KURT: LO SCHEDULING
Scheduling Modes
modalità:
il framework real-time può schedulare eventi secondo due
 FROM_MEM : Nella seguente
modalità , il file di schedule viene
completamente letto nella memoria
del kernel e solo poi lo scheduling di
ogni evento ha luogo. E’ possibile
ripetere questo schedule per un
numero di volte in maniera ciclica. Lo
svantaggio di questa modalità è che
richiede abbastanza memoria per
occupare il file di schedule completo.
Si pensi infatti che ogni evento occupa
circa 24 bytes di memoria.
 FROM_DISK : In questa modalità, il
file di schedule viene letto nella
memoria del kernel una pagina per
volta. Arbitrariamente, lunghi schedules
possono essere presentati al framework
real-time per lo scheduling. Lo
svantaggio di questa modalità è che ci
potrebbero essere alcune distorsioni
nello scheduling degli eventi a causa
dell’operazione di lettura intermittente
da disco.
UTIME
il KURT utilizza un sistema “utime” per schedulare gli eventi con una
risoluzione in termini di microsecondi (µs). Gli eventi possono anche esser schedulati
con una risoluzione di 10 ms se UTIME non è installato.
Un'estensione firm real-time di Linux : il KURT
36
PERFORMANCES: DISPATCH TIME PER I MODULI
DEL KERNEL E PER I PROCESSI REAL-TIME

Per testare il tempo richiesto ad invocare un modulo del kernel ed un processo realtime, basta un semplice processo real-time KURT che viene eseguito ogni 10ms
(nella modalità periodica).

Ogni volta che cicla, il programma restituisce il tempo corrente e lo immagazzina in
memoria. Dopo che il programma ha terminato la sua esecuzione, i tempi vengono
stampati al fine di permettere un immediato confronto.

Le informazioni temporali, inoltre, sono
state anche conservate per valutare la
differenza tra quando un evento
occorre nel tempo e quando l’RTMod
inizia realmente la sua esecuzione.
Un'estensione firm real-time di Linux : il KURT
37
PERFORMANCES: KURT vs
SCHED FIFO SOFT REAL TIME
…efficienza di scheduling


SCHED_KURT_PROCS
(modalità focus )
SCED_FIFO
Un'estensione firm real-time di Linux : il KURT

SCHED_ALL_PROCS
(modalità mixed)
38

SCHED_FIFO: performances all’aumentare del
numero dei processi (interrupts dell’hardware VALUTAZIONE DELLE
esterno
considerevole numero di contex
switch prelazionabili
affligge le prestazioni); PERFORMANCES(1)

SCHED_KURT: le performances sostanzialmente
restano invariate quando viene aumentato il
numero dei processi (c’è un minimo contex
switch tra queste applicazioni);

SCHED_KURT: non c’è quasi differenza tra la
modalità SCHED_KURT_PROCS e
SCHED_ALL_PROCS (Ciò si verifica perché il
sistema è essenzialmente idle eccetto per i
processi da testare);

SCHED_KURT: non c’è un vero e proprio
meccanismo di controllo dell’ ingresso che
previene l’overloading della CPU. Dal momento
che ogni processo setta le sue richieste di
processamento a 300µs (è l’attuale tempo di
CPU richiesto dal processo per completare
un’iterazione del suo ciclo), non sono permessi
più di 30 processi all’interno del sistema.
SCHED_FIFO: qualsiasi numero dei processi
dovrebbe essere permesso all’interno del
sistema. Questo dovrebbe portare ad un
ulteriore degradazione delle performances;
quindi…
 A prescindere dal numero dei
processi, il KURT schedula ogni
applicazione al tempo
appropriato (in rosso).
 KURT con o senza focalizzazione
è un’alternativa fattibile per lo
scheduling firm real-time dei
Un'estensione firm real-time di Linux : il KURT
39
processi.
VALUTAZIONE DELLE PERFORMANCES (2)
… ed inoltre…
 Se un sistema è caricato, le performances dello scheduler esplicito nella modalità
SCHED_ALL_PROCS potrebbero essere distorte nel momento in cui gli interrupts
vengono disabilitati da altre parti del sistema operativo.

Worst case: interrupts disabilitati dall’attività di backgraund del disco (infatti in Linux
disabilita gli interruptus per la massima durata del tempo)
effetto sulle
performances degli
schedulers FIFO e
KURT

Si può notare che persino in presenza di “background disk activity”, lo SCHED_KURT
funziona ancora molto meglio dello SCED_FIFO.
Un'estensione firm real-time di Linux : il KURT
40
SOMMARIO

Introduzione ai sistemi operativi real-time;

Passaggio dagli OS ai sistemi operativi di natura realtime;

Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI;

Un’estensione firm real-time di Linux: il KURT;

TinyOS e Mantis: uno sguardo all’immediato futuro
degli RTOS;

Conclusioni sullo studio dei sistemi operativi realtime;
41
OS PER APPLICAZIONI EMBEDDED

 Sviluppare un sistema i cui
componenti vengono
compilati insieme
all’applicazione (come
TinyOS e BTnode system
software)
Un sistema operativo realizzato
per un ambito embedded, deve
avere alcune caratteristiche di
base:
 Ridotte dimensioni
 Basso consumo durante l’elaborazione
 Consumo pressoché nullo in stato di “idle”
 Deve gestire la concorrenza
 Implementare protocolli di rete a seconda
della periferica di rete utilizzata
 Protocolli poco dispendiosi in termini di
energia(TCP/IP è in genere inapplicabile)
 Deve inoltre fornire un’astrazione per i
dispositivi hardware (sensori e attuatori)
TinyOS e Mantis: uno sguardo all'immediato
montati sul sensore
futuro degli RTOS
.…si distinguono generalmente
due approcci:
 Sviluppare un sistema
che includa i tradizionali
strati di software dei
sistemi general purpose
in versione ridotta (ad
es. BerthaOS e MANTIS)
42
IL PRIMO APPROCCIO: IL TINYOS

OS di tipo “open source” specificamente ideato per
reti “embedded” di sensori wireless (attualmente è il
più affermato) sviluppato dall’università di Berkeley in
California per la tecnologia motes

Modello di programmazione tagliato per applicazioni
attivate da eventi e con una occupazione ridottissima
(il core richiede solo 400 byte di dati) essendo
realmente inserite nel sistema solo le funzionalità
richieste

Appartiene al primo approccio, dunque i componenti
vengono montati assieme all’applicazione: ciò
consente una singola applicazione in esecuzione in
un dato momento

Tuttavia tale sistema permette di avere bassissimi
consumi (non esistendo in genere context switch dal
momento che gli scheduler seguono una politica
FIFO run to completion, ovvero un task non può
interrompere un altro task)

Lo svantaggio derivante da tale approccio è la
limitata versatilità e i seri vincoli di riconfigurabilità
TinyOS e Mantis: uno sguardo all'immediato
dell’applicazione
futuro degli RTOS
Mica Mote (Berkeley 2001)
43
IL MODELLO A COMPONENTI DEL TINYOS


Scambia dati per mezzo di una rete di componenti che comunicano tra loro mediante
un’interfaccia per gli “eventi” (asincroni) e per i “comandi” (sincroni)
Utilizza il nesC, ovvero un linguaggio di programmazione evoluto(derivato dal C) per
sistemi embedded connessi in rete (per es. Mote)
Mica Mote: 128KB di codice, 4KB
di dati, ed una flash di 512KB
Hardware abstraction mappa le
funzionalità sw su quelle hw creando …3 possibili categorie
di componenti…
un’astrazione dello stesso
utilizzabile dai moduli superiori(ad TinyOS e Mantis: uno sguardo all'immediato
futuro degli RTOS
es. un componente che legge/ scrive
1bit sul canale radio)
High level software
component sono quelli
di livello più alto e si
occupano di eseguire
algoritmi che
prescindono dal
particolare
hardware(ad es. il
componente che
implementa il
protocollo di routing)
Synthetic hardware simulano
il comportamento di
hardware più sofisticato di
quello realmente presente sul
sensore(ad es un componente
che compone 8 bit e li invia a
quelli di livello superiore)
44
MIGLIORAMENTO DELLO SCHEDULER DELLA
VERSIONE 1.0
CONCETTO DI PRIORITA’

TinyOS 1.0. (curva in blue): si nota come la resa dei pacchetti (throughput) si riduca
in presenza di un task locale ad 8Hz (125 ms) con tempi di esecuzione variabili
all’interno di una piattaforma TinyOS 1.0. Non appena il tempo di esecuzione di un
task locale aumenta (overload del sistema), il throughput dei pacchetti radio
diminuisce sensibilmente (scheduler FIFO per tutti i tasks).

TinyOS 2.0. (curva in viola): l’aggiunta della priorità per i tasks, per differenziare i
tasks real-time dai tasks ordinari, migliora sostanzialmente il throughput in caso di
overload del sistema (perché magari è in esecuzione un task locale, e quindi il
processamento di tale pacchetto bloccherebbe completamente un nodo sensore),
 Attualmente presenta
uno scheduler FIFO run to
completion con due livelli
di priorità: quello normale
per i task e quello più alto
per gli eventi, che possono
interrompere i task
(preemption).
TinyOS e Mantis: uno sguardo all'immediato
futuro degli RTOS
45
UNO SGUARDO AL SECONDO APPROCCIO:
MANTIS OS

Mantis OS è il sistema operativo della piattaforma MANTIS che si basa sui sensori
nymph.

Appartiene al secondo approccio, quindi include i tradizionali strati di software dei
sistemi general purpose in versione “ridotta”

Concettualmente è opposto a TinyOS, infatti esso ha la struttura di un OS general
purpose, è organizzato in livelli, è multithread e contiene uno scheduler preemptive
con time slicing, meccanismi di sincronizzazione attraverso sezioni in mutua
esclusione, uno stack protocollare standard per la rete e device drivers

Questo approccio accelera l’apprendimento della nuova tecnologia e aumenta la
versatilità (potendo eseguire più applicazioni in contemporanea), ma pone seri
problemi di prestazioni e di consumi.
 Il componente “command server” permette
di amministrare da remoto il singolo sensore
attraverso una shell UNIX-like
...si nota la somiglianza dell’architettura
con i sistemi UNIX …
TinyOS e Mantis: uno sguardo all'immediato
futuro degli RTOS
46
MANTIS: KERNEL, SCHEDULER & STACK

Le funzionalità offerte dal kernel di MANTIS OS sono un sottoinsieme
dell’interfaccia POSIX, in particolare lo scheduler priority-based (secondo l’algoritmo
round-robin)

Per la sincronizzazione e la concorrenza il sistema supporta semafori sempre
secondo lo standard posix.

La memoria RAM è divisa in due sezioni:
statica
dove vengono allocate al momento della compilazione le varabili
globali;
heap
dove vengono allocati i thread al momento dell’esecuzione.

Non è possibile allocare manualmente memoria dinamica al momento.

Per quanto riguarda la comunicazione di rete, MANTIS OS prevede uno stack
protocollare strutturato su quattro livelli: fisico, MAC, network e applicazione. Il
sistema è molto più sofisticato e versatile di quello di TinyOS, infatti possono
coesistere meccanismi di routing diversi (unicast, flooding, multicast).

Di contro questo sistema è prestazionalmente più scadente dell’ Active Messages
utilizzato dal TinyOS, essendo l’elaborazione del singolo pacchetto più lunga, e
comportando un continuo scambio di contesto di esecuzione al momento della
comunicazione di rete. Questo causa consumi maggiori.
TinyOS e Mantis: uno sguardo all'immediato
futuro degli RTOS
47
SOMMARIO

Introduzione ai sistemi operativi real-time;

Passaggio dagli OS ai sistemi operativi di natura realtime;

Le più diffuse alternative hard real-time oggi sul
mercato: RTLinux ed RTAI;

Un’estensione firm real-time di Linux: il KURT;

TinyOS e Mantis: uno sguardo all’immediato futuro
degli RTOS;

Conclusioni sullo studio dei sistemi operativi realtime;
48
CONSIDERAZIONI FINALI:PANORAMICA COMPLETA


Fare un confronto tra sistemi hard, soft e firm real-time è alquanto difficile
Tabella finalizzata a permettere un immediato confronto all’interno di un contesto
specificatamente “real-time”

aggiunge funzionalità al
sistema per mezzo di un
“resurce kernel” implementato
come un modulo caricabile

proprietà fornita ai tasks che fa
uso della API RK, ma che non
può far uso di RK(e della sua
API) se si sta gia utilizzando
RTAI, vista la mutua esclusività
tra i due
..Conclusione..

non c’è un singolo prodotto che offra un set “all-inclusive” di proprietà RT, pertanto
molte società offrono tecnologie alternative mutiple (come più miglioramenti per lo
scheduler di RTLinux ed RTAI) in modo da soddisfare un range sicuramente più ampio
Conclusioni sullo studio dei sistemi operativi
49
di esigenze real-time
real-time
CONSIDERAZIONI FINALI: OS vs EVENT-DRIVEN
Caratteristiche
General purpose OS
Event-driven OS
Models of Computation(MOC)
Multi-tasking
Comunicazione tra
macchine a stati
finiti estese (EFSM)
Scopo d’uso
Generale
Rivolto a sistemi eventdriven
Costi di comunicazione
Alti
Bassi
Frequenza di comunicazione
Bassa
Alta
Richiesta di memoria
Ampia
Bassa
OS type
Processore
General
Purpose
ARM7 thumb
Event-driven
Event-driven


Memoria
totale
istruzioni
Memoria dati
10.096
22324
54988
ARM7 thumb
5312
8000
2800
8 bit RISC
2740
3176
709
 confronto tra la diversa
richiesta di memoria tra
le due differenti politiche
di OS
quindi..
Con la medesima scelta del processore(ARM7 a 16 bit), TinyOS necessita di metà
memoria istruzioni e di circa 1/30 di memoria dati. Gli studi dimostrano che il
consumo di potenza di una SRAM scala approssimativamente con la capacità
Questo significa che in TinyOS la potenza della memoria istruzioni può essere ridotta
di 1.6x   22324 e quella della memoria dati rispettivamente di 4.2x   54988 



Applicazione
 confronto generale tra le
caratteristiche degli OS
“general purpose” e
quelle degli “eventdriven”
8000 



2800 

Utilizzando un più semplice processore come quello RISC a 8-bit, si potrebbe
ulteriormente ridurre la dimensione della memoria ed il consumo di potenza.
Conclusioni sullo studio dei sistemi operativi
real-time
50
CONSIDERAZIONI SULLE PERFORMANCE:
OS vs EVENT-DRIVEN

confronta il conteggio dei cicli totali del processore: ben
16365 del general purpose contro i 2554 del TinyOS.

quest’ultimo mostra un fattore di ben 8 miglioramenti, che si
traduce in un fattore di 8 riduzioni nel consumo di potenza
del processore.

confronta i costi dei due OS (le porzioni piu basse della
barra) in termini di percentuale dei cicli totali.

come indicazione della propria inefficienza, il sistema
operativo general- purpose presenta un costo di OS pari
all’86% mentre TinyOS circa del 10%.
 Esempio: stima di potenza realmente
risparmiata da un processore e da i suoi
blocchi di memoria:

Con tecnologia di 0.18µm e tensione di 1.8V, un ARM7 consuma circa 0.25mW/MHz. Per una
memoria di dimensione pari a 64KB per l’acceso alla lettura si consuma circa 0.407mW/MHz
mentre per l’accesso alla scrittura circa 0.447mW/MHz. Se si suppone che il 10% delle
istruzioni coinvolgono le operazioni di lettura da memoria ed il 10% quelle di scrittura e di
allocazione della memoria, oltre alla scalatura del conteggio del ciclo del processore, il consumo
di potenza dei due OSs sono rispettivamente: 0.608mW/MHz e 0.053mW/MHz.

Cioè, in altri termini, TinyOS presenta un fattore di miglioramento di potenza pari a 12.
Conclusioni sullo studio dei sistemi operativi
real-time
51