Elaborato Rucco Gaetano N46001237

Scuola Politecnica e delle Scienze di Base
Corso di Laurea in Ingegneria Informatica
Elaborato finale in Sistemi Real-Time
Strumenti di monitoraggio delle
prestazioni in ambiente real-time:
confronto tra le piattaforme
VxWorks e QNX
Anno Accademico 2013/2014
Candidato:
Gaetano Rucco
matr. N46001237
A tutti quelli che mi hanno
sempre sostenuto e che mi fanno
sentire vivo ed importante.
Indice
Indice .................................................................................................................................................. III
Introduzione ......................................................................................................................................... 4
Capitolo 1: VxWorks ........................................................................................................................... 7
1.1 Caratteristiche generali .............................................................................................................. 8
1.2 Gestione delle interruzioni ....................................................................................................... 10
1.3 Componenti della piattaforma .................................................................................................. 10
1.4 VxWorks 7 ............................................................................................................................... 11
1.4.1 Virtualization Profile ........................................................................................................ 12
1.5 Strumenti di monitoraggio delle prestazioni ............................................................................ 15
1.5.1 Trace Recorder e Tracealyzer........................................................................................... 15
1.5.2 WindView .......................................................................................................................... 16
1.5.3 Spy ..................................................................................................................................... 18
1.5.4 Data Monitor..................................................................................................................... 19
Capitolo 2: QNX Neutrino ................................................................................................................. 20
2.1 Caratteristiche generali ............................................................................................................ 21
2.2 QNX Momentics ...................................................................................................................... 23
2.3 Monitoring tools ....................................................................................................................... 24
2.3.1 QNX System Profiler ........................................................................................................ 24
2.3.2 SAT (System Analysis Toolkit) ......................................................................................... 26
Capitolo 3: Tool suite a confronto ..................................................................................................... 29
Conclusioni ........................................................................................................................................ 34
Ringraziamenti ................................................................................................................................... 35
Bibliografia ........................................................................................................................................ 36
Introduzione
Il monitoraggio del comportamento di un sistema real-time è fondamentale per via
dei requisiti temporali che lo stesso deve soddisfare, i quali possono riferirsi ad
aspetti più o meno critici (infatti le attività real-time sono suddivise in soft, firm e
hard real-time). D’altronde i sistemi real-time sono quei sistemi di calcolo nei quali
si ha un doppio concetto di correttezza di funzionamento: logica (“it does the right
thing”) e temporale (“it does it on time”). Pertanto la bontà del sistema non
dipende solo dalla validità dei risultati ottenuti, ma anche dal tempo in cui questi
sono conseguiti: i task real-time devono infatti rispettare le proprie deadline, in
maniera più o meno stringente a seconda della loro classe di criticità. L’altro
concetto fondamentale riguarda la parola “reale”, la quale indica che la risposta del
sistema agli eventi esterni deve avvenire durante l’evolversi degli eventi stessi. E’
chiaro quindi che il concetto di “tempo reale” non è una proprietà intrinseca di un
sistema di controllo né tantomeno un concetto associato alla velocità di reazione del
sistema, bensì una caratteristica strettamente legata all’ambiente in cui esso opera,
giacchè il tempo interno di sistema e quello dell’ambiente devono essere misurati
con lo stesso riferimento temporale. Infatti è d’obbligo ricordare che, mentre
l’obiettivo generale di un’elaborazione veloce è quello di minimizzare il tempo di
risposta medio di un insieme di processi, il target di una elaborazione real-time è
quello di soddisfare i requisiti temporali individuali di ciascun task real-time [2].
Lo scopo principale del monitoring di un sistema è quello di fornire statistiche ed
aiutare lo sviluppatore nell’apportare miglioramenti al sistema: in tal senso il
4
monitoraggio di un sistema si diversifica dal debugging, il quale mira invece a
scoprire potenziali bug nel sistema che possono portare quest’ultimo al failure
(malfunzionamento, ossia l’incapacità del software di comportarsi secondo le
aspettative o le specifiche) a run-time. Esistono diversi tool commerciali per il
monitoraggio delle prestazioni di un sistema real-time e per il logging delle
informazioni ottenute; tuttavia non sempre è possibile adattare tali strumenti a tutti i
sistemi ed alcuni di essi possono essere usati solo in fase di sviluppo del sistema.
Al fine di offrire garanzie più robuste circa il funzionamento di un sistema
real-time, possono essere previsti dei meccanismi del kernel atti a gestire
esplicitamente la variabile “tempo”: infatti la maggior parte dei sistemi real-time si
avvale di sistemi operativi real-time (RTOS, Real-Time Operating System), i quali
introducono algoritmi di scheduling dei task, meccanismi di mutua esclusione e
sincronizzazione tra task, comunicazione con scambio di messaggi, gestione delle
interrupt e della memoria, virtualizzazione delle risorse hardware e cosi via. In tal
modo è possibile realizzare software di controllo con linguaggi di programmazione
di alto livello (cosi da avere una maggiore flessibilità e da semplificare lo sviluppo
dei programmi) e con maggiore robustezza rispetto al soddisfacimento dei vincoli
temporali. La maggior parte degli RTOS fornisce anche un supporto per la
programmazione concorrente attraverso processi e thread. Lo scheduler è
tipicamente di tipo preemptive (perché consente di avere latenze più basse ed una
maggiore efficienza nell’utilizzo di risorse) e basato su priorità fisse. Tuttavia la
qualità principale che deve avere un RTOS è la prevedibilità, ossia la capacità di
determinare in anticipo se uno o più task riusciranno a completare la loro
esecuzione entro le proprie deadline; pertanto l’obiettivo degli sviluppatori di
RTOS è quello di favorire tale proprietà fondamentale ed in generale di eliminare le
fonti di non determinismo dovute appunto alle politiche di gestione realizzate dai
SO general-purpose e ad altri fattori ad essi correlati (scheduling, system calls,
concorrenza e semafori, gestione delle periferiche, e cosi via), nonché a
meccanismi interni al processore (ad esempio interrupt, DMA, MMU e cache).
5
Attualmente esistono circa un centinaio di RTOS commerciali e la loro scelta
dipende anche dai tool software che gli fanno da corredo e che favoriscono lo
sviluppo di applicazioni real-time, quali performance profiler, schedulability
analyzer, memory analyzer, tracer, strumenti di monitoraggio real-time (per
visualizzare lo stato delle variabili durante l’esecuzione di un programma) e code
analyzer (per determinare i worst-case execution time (WCET) dei task su
architetture specifiche). Chiaramente nella scelta di un RTOS bisogna valutare i
vari trade-off (costi, efficienza, tempi di risposta, ecc.) e inoltre è bene ricordare
che l’utilizzo di un RTOS non è la soluzione a tutti i problemi relativi allo sviluppo
di sistemi real-time: nel progetto di sistemi critici bisogna fare sempre delle
assunzioni pessimistiche sull’ambiente nel quale questi operano (worst case
analysis), in modo da tenere in conto tutte le situazioni più gravose.
Questo elaborato va ad analizzare gli strumenti di monitoraggio più importanti nel
panorama real-time relativamente alle due piattaforme sotto analisi: VxWorks e
QNX Neutrino, che sono due tra i RTOS commerciali più utilizzati per lo sviluppo
di applicazioni real-time. In particolare, il primo è un RTOS Unix-like proprietario
progettato essenzialmente per sistemi embedded che richiedono performance
deterministiche e real-time, anche se nel corso degli anni sono stati sviluppati
diversi “profili” al fine di specializzare il prodotto su un vasto range di aree di
mercato: automotive, automazione industriale e robotica, area medica e networking,
elettronica di consumo, aerospaziale. Anche QNX è un RTOS proprietario
Unix-like, conforme allo standard POSIX 1003.1-2001 ed alla sua estensione
real-time (RT-POSIX). Esso è usato essenzialmente per progetti ed applicazioni
“mission critical” quali controllori industriali, apparecchiature mediche, router
internet, sistemi di controllo del traffico aereo e sistemi di difesa.
Nel seguito dell’elaborato saranno esposte le caratteristiche principali di questi due
importanti RTOS, e infine sarà sostenuto un confronto tra le tool suite prese in
considerazione per le due piattaforme, nonché un piccolo parallelo tra queste ultime
considerando alcuni parametri e studi sperimentali.
6
Capitolo 1: VxWorks
Installato su oltre 1,5 miliardi di dispositivi, VxWorks è il principale RTOS al
mondo. E’ stato scelto come RTOS da aziende ed agenzie leader nei relativi settori,
quali Alcatel, Boeing, Huawei, Mitsubishi e NASA. VxWorks è un RTOS
sviluppato come software proprietario dalla Wind River Systems di Alameda
(California) ed è commercializzato come il componente run-time della piattaforma
di sviluppo Tornado, la quale però è stata sostituita dall’IDE Eclipse-based Wind
River Workbench a partire da VxWorks 6.x. Esso supporta numerose architetture
hardware quali ARM, Intel, MIPS, Hitachi H8, PowerPC e altre. Le piattaforme
VxWorks forniscono il supporto a sistemi uniprocessore (UP) e multiprocessore,
comprese le architetture multiprocessore SMP (Symmetric MultiProcessing) e AMP
(Asymmetric MultiProcessing); inoltre il RTOS può essere installato anche in
modalità multi-boot. Il prodotto è fornito con un kernel multitasking, tecnologie
middleware, BSPs (Board Support Packages, cioè l’implementazione di uno
specifico codice di supporto per una determinata scheda che sia conforme al SO,
tipicamente costituito da un bootloader minimale per caricare il kernel del SO ed i
device driver per tutte le periferiche della scheda in questione), la suite di sviluppo
Wind River Workbench, software di terze parti e tecnologie hardware.
Nell’ultima versione (VxWorks 7) è stato fatto un lavoro di re-engineering (cioè il
processo attraverso il quale un sistema esistente subisce delle modifiche al fine di
essere ricostruito in una nuova forma) del RTOS per migliorare la modularità e
l’evolvibilità, cosi che il kernel possa essere separato da middleware, applicazioni
7
ed altri package: in questo modo è possibile aggiungere o effettuare l’upgrade di
diversi package senza dover modificare il kernel, consentendo quindi ai clienti di
correggere eventuali bug e di aggiornare prodotti senza dover revisionare o testare
nuovamente l’intero sistema [4]. Inoltre sono state migliorate scalabilità, safety,
security, grafica e connettività per adattare il RTOS all’ Internet of Things (IoT)
[7], vale a dire la possibile evoluzione dell’uso della rete che ha come fine quello di
collegare qualsiasi oggetto fisico a questa, fornendo ad esso un’identità elettronica
ed una certa “intelligenza” (si pensi ad esempio ad una sveglia che suona prima
dell’orario impostato se viene rilevato traffico o ad una pianta che comunica
all’innaffiatoio quando è il momento di essere annaffiata).
Infine è utile ricordare che VxWorks presenta anche un simulatore integrato
chiamato VxSim, il quale è appunto in grado di simulare un sistema target: tale
utility può essere utilizzata ad esempio nello sviluppo del prototipo di un sistema e
per il testing del sistema target.
Nel corso del capitolo verranno esposte le caratteristiche della piattaforma
VxWorks ed i tool software per le varie analisi in ambiente real-time.
1.1 Caratteristiche generali
VxWorks offre il supporto al multitasking; il suo kernel utilizza di default uno
scheduler preemptive a priorità fisse (in totale abbiamo 256 livelli di priorità), anche
se è possibile adottare una politica di tipo Round-Robin (RR); inoltre un task può
modificare la sua priorità a run-time a seconda di alcuni parametri. Per quanto
riguarda l’ IPC (Inter-Process Comunication) il kernel offre numerosi meccanismi,
fra i quali: shared memory, semafori per la mutua esclusione e per la
sincronizzazione, code di messaggi, socket e RPC (Remote Procedure Call). Al fine
di evitare il problema della priority inversion (un task ad alta priorità viene bloccato
per un tempo indefinito da un task a bassa priorità) nel caso di accesso a risorse
condivise con il classico meccanismo semaforico è possibile anche abilitare sui
8
semafori di mutua esclusione il protocollo di Priority Inheritance, che però non
previene problematiche rilevanti come il deadlock e le catene di bloccaggi.
Per quanto concerne i meccanismi di protezione, VxWorks si basa sugli stati
gerarchici di privilegio, consentendo la doppia modalità di esecuzione (kernel mode
e user mode). Storicamente VxWorks ha sempre fornito solo la modalità kernel;
poi, dalla versione 6, è stato introdotto il “modello RTP” (Real-Time Processes), il
quale definisce appunto la demarcazione tra task in user-mode (RTP) e task in
kernel-mode. Ad ogni modo gli RTP possono comunque beneficiare indirettamente
delle routine del kernel, il quale è protetto da applicazioni che eseguono in
user-mode e consente una allocazione affidabile delle risorse ai task.
Figura 1.1 : Diagramma a blocchi dell’architettura RTP
Come si vede infatti dalla figura 1.1, gli RTP eseguono in user-mode e possono
condividere opzionalmente delle shared libraries, le quali migliorano l’efficienza e
la riusabilità del codice, cosi come la velocità di sviluppo del codice ed il
debugging. Inoltre VxWorks 6.x consente ai produttori di aumentare l’affidabilità
dei loro device attraverso la protezione di memoria basata su MMU (Memory
Management Unit), supporto hardware che consente la rilocazione dinamica, ossia
ritarda l’associazione degli indirizzi logici agli indirizzi fisici alla fase di esecuzione
cosi che un processo (o meglio la sua immagine) possa essere spostato da un
9
segmento di memoria all’altro a run-time: la CPU, quindi, “vede” solo indirizzi
virtuali ed i processi possono accedere solo ai propri spazi di indirizzamento.
Nel 2004 Wind River ha annunciato la conformità allo standard POSIX ed a
RT-POSIX PSE54 [9]. Giacchè VxWorks è stato progettato essenzialmente per
sistemi embedded, è normale l’utilizzo della cross-compilazione, la quale viene
largamente usata per la compilazione di applicazioni per tali sistemi che, avendo
generalmente risorse molto limitate, non ne prevedono una normale. Lo sviluppo è
quindi fatto su una macchina “host” che esegue il cross-compiler per compilare il
codice sorgente, generando alla fine un file binario eseguibile su una macchina
“target” con architettura diversa dalla macchina “host”. Tra gli “host” supportati da
VxWorks abbiamo: Windows 8/7/Vista/XP, Ubuntu Desktop 9.04/8.04 e Solaris 10.
1.2 Gestione delle interruzioni
Per quanto riguarda le interrupt, queste vengono gestite da ISR (Interrupt Service
Routine) che hanno un livello di priorità maggiore di quello dei task del sistema ed
eseguono in un contesto diverso rispetto a quello di tutti i task. Essendo prevista la
preemption, anche le ISR possono essere interrotte a scapito di ISR relative ad
interrupt a priorità maggiore. Per implementare i meccanismi semaforici di mutua
esclusione, il supporto hardware è dato dalla disabilitazione delle interrupt: in
VxWorks è possibile disabilitare ed abilitare le interrupt rispettivamente con le API
proprietarie intLock() e intUnLock(), eseguibili chiaramente solo in kernel-mode.
1.3 Componenti della piattaforma
Come già detto nell’introduzione, le piattaforme VxWorks sono ottimizzate per
diversi settori applicativi. La piattaforma VxWorks general-purpose è composta da
componenti run-time e strumenti di sviluppo. I primi consistono in: un Sistema
Operativo, software per il supporto delle applicazioni (file system, stack di rete e
IPC) e supporto hardware (device drivers e BSP). Per quanto riguarda invece gli
10
strumenti di sviluppo abbiamo gli elementi di base per ogni RTOS, vale a dire i
compilatori (come GNU o Intel C++ Compiler), i debugger e gli editor. Abbiamo
infine diversi tool di produttività a corredo del RTOS, la maggior parte dei quali
sono integrati nella suite di sviluppo Wind River Workbench (in sostituzione alla
piattaforma di sviluppo Tornado prevista nelle versioni precedenti a VxWorks 6).
1.4 VxWorks 7
L’ultima versione di VxWorks consiste in una piattaforma modulare, configurabile
ed espandibile per dispositivi connessi, nata con lo scopo di aiutare le grandi
aziende a capitalizzare le opportunità offerte dall’Internet of Things (IoT). Il RTOS
è stato riprogettato, o meglio re-ingegnerizzato, cosi da separare il kernel dai vari
package che compongono il sistema: come visto prima, ciò consente di evitare
revisioni inutili dell’intero sistema, andando cosi ad aumentare la scalabilità e la
capacità di adattamento rapido ai mutamenti del mercato. Oltre alla modularità ed
alla scalabilità, un altro importante miglioramento introdotto è quello relativo alla
security: la connettività pervasiva dovuta all’ IoT espone chiaramente i dispositivi a
più rischi in termini di sicurezza. VxWorks 7 offre un insieme personalizzabile di
caratteristiche di sicurezza built-in per proteggere i dispositivi nelle fasi di
sviluppo, accensione, trasmissione/ricezione dati e spegnimento. Altro aspetto
soggetto al miglioramento è la safety (che, a differenza della security, è intesa
piuttosto come “incolumità” per persone e cose), per la quale è stato ideato un
“modulo di partizionamento della safety” che permette il partizionamento di tempo,
spazio e risorse richiesto per la certificazione ARINC 653 (che è uno standard di
interfacce software per applicazioni di avionica) ed altre certificazioni IEC. Altro
punto cardine è la connettività, che è appunto un requisito fondamentale per l’IoT:
VxWorks 7 offre il supporto per una vasta gamma di standard e protocolli leader
nei propri settori (come Bluetooth, USB e CAN), oltre che a funzionalità di rete ad
alte prestazioni. Inoltre è stata arricchita la tool suite Wind River Workbench con
11
un sistema di analisi “stato dell’arte” che consente l’accesso immediato al codice,
permettendo agli sviluppatori di ottimizzarlo e contemporaneamente rilevare bug e
memory leak. Infine, l’aspetto più interessante introdotto da VxWorks 7 è il
Virtualization Profile, il quale permette ai clienti di consolidare più piattaforme
hardware stand-alone su una singola piattaforma multi-core. Segue un focus su
questo aspetto, partendo da una panoramica sul concetto di virtualizzazione ed
approfondendo poi la descrizione del relativo profilo in VxWorks 7.
1.4.1 Virtualization Profile
La potenza di calcolo e la complessità degli attuali sistemi informatici implica la
ricerca di nuovi metodi per ottimizzarne la gestione e l’utilizzo. Questo vale
soprattutto per le macchine server che, per motivi di sicurezza e praticità, vengono
sottoutilizzate: di norma, infatti, viene installata una sola applicazione per sistema
operativo, vale a dire una sola applicazione per calcolatore! E’ evidente dunque
l’ingente spreco di spazio e di denaro, vista la necessaria presenza di un certo
numero di calcolatori quando si vuole realizzare un determinato sistema
informatico; bisogna considerare inoltre i costi dovuti alla gestione e soprattutto
alla manutenzione di questi calcolatori. Per questo motivo la maggior parte delle
aziende (in primis) ha deciso di virare sulla virtualizzazione, la quale permette ad
un server fisico ospitante (in gergo, macchina host) di gestire più SO, o meglio più
macchine virtuali (macchine guest), vale a dire l’insieme delle componenti
hardware virtuali (CPU, RAM, Hard Disk, scheda di rete) che vengono astratte
durante il processo di virtualization e sulle quali può essere installato il sistema
operativo guest e le relative applicazioni. In questo modo le componenti hardware
dei calcolatori vengono rese disponibili sotto forma di risorsa virtuale all’ host.
Uno dei vantaggi chiari della virtualizzazione è l’ottimizzazione delle risorse
hardware della macchina host grazie ai meccanismi di distribuzione delle risorse
disponibili di una piattaforma fisica: difatti le macchine virtuali che girano su una
macchina host condividono le risorse fisiche di quest’ultima e le eventuali contese
12
di risorse vengono gestite dai software di virtualizzazione (come ad esempio
VMware, VirtualBox, vSphere) che si occupano della gestione dell’ambiente. Il
componente centrale di un sistema basato su macchine virtuali è l’ hypervisor (o
VMM, Virtual Machine Monitor), il quale si occupa di creare ed eseguire le
macchine virtuali, ed in generale di eseguire attività di controllo e di allocazione di
risorse sul sistema host. In particolare possiamo avere un hypervisor di tipo 1
(anche detto nativo o bare-metal (da zero) in quanto viene eseguito direttamente
sull’hardware della macchina host), il quale ha il compito di controllare la
piattaforma hardware sul quale esso è eseguito e di gestire i sistemi operativi guest
che vengono eseguiti ad un livello superiore rispetto a quello dell’ hypervisor
stesso, ed un hypervisor di tipo 2: entrambi sono esemplificati in figura 1.2:
Figura 1.2 : Tipi di hypervisor
Il Virtualization Profile di VxWorks estende la scalabilità della piattaforma
VxWorks integrando un hypervisor real-time di tipo 1 nel kernel del RTOS. Tale
componente rende possibile la virtualizzazione, la quale permette ai clienti di
combinare più workloads su un unico processore multi-core, come è mostrato nella
figura 1.3 suggerita dagli sviluppatori del Virtualization Profile:
13
Figura 1.3 : Consolidamento di funzionalità e sistemi operativi eterogenei grazie al Virtualization Profile.
Secondo gli sviluppatori di tale RTOS questa soluzione è ottimale e rispetta il
principio ingegneristico dell’ “anticipazione del cambiamento”: un’architettura in
grado di adattarsi ed evolversi per soddisfare le mutevoli esigenze del mercato e dei
clienti, e per affrontare al meglio le innovazioni tecnologiche. Inoltre rappresenta
una struttura all’avanguardia per l’IoT, per il quale sono richieste essenzialmente
tre proprietà: connettività, scalabilità e sicurezza [10].
Tale profilo sviluppato dalla Wind River è parte dell’investimento fatto nelle
tecnologie multi-core (intrapreso dagli anni 2000 con la versione 6 di VxWorks)
per la safety e la security in tutti i mercati, dai controlli automatici alle
apparecchiature mediche ai sistemi di controllo avionici.
Tra le key features di questo profilo abbiamo un “throttling framework”
(“framework di strozzamento”) contenuto nell’hypervisor che permette di rallentare
i sistemi operativi general-purpose “guest” che stanno consumando troppe risorse
a livello di sistema (come ad esempio il bus di memoria e la PCI), in maniera tale
da preservare le attività real-time esegsuite dal RTOS di base: ciò è particolarmente
utile per sistemi o processi hard real-time. Inoltre l’hypervisor garantisce un
elevato throughput ed una bassa latenza per quanto riguarda l’IPC.
14
1.5 Strumenti di monitoraggio delle prestazioni
VxWorks è ricco di tool che consentono di fare system monitoring. In particolare
l’IDE Wind River Workbench 3.3 prevede sei tool per l’analisi a run-time di un
sistema real-time, i quali offrono una visualizzazione dinamica e molto dettagliata
dei componenti del sistema. Nel seguito della trattazione andremo ad analizzare gli
strumenti di monitoraggio più interessanti per la piattaforma VxWorks.
1.5.1 Trace Recorder e Tracealyzer
Questi tool nascono col fine di registrare dati rilevanti da un sistema real-time in
azione. Sono presentati dal progetto di ricerca “Remodel” [11] e possono essere
adattati manualmente su ogni sistema che utilizza la piattaforma VxWorks. Il Trace
Recorder memorizza il comportamento dei task nel sistema, andando a registrare
quale task è in esecuzione e quando lo fa. Tracealyzer è un tool offline che va
invece a caricare le informazioni nel log creato dal Trace Recorder, le analizza e le
mostra in un ambiente grafico all’utente.
Il primo tool è in grado di monitorare le interrupt ed i context-switch dei task, ma
anche delle “sonde” e/o dei “task virtuali” definiti dall’utente a seconda delle
necessità. Le sonde vengono definite dall’utente al fine di memorizzare delle
informazioni desiderate in un log che può essere analizzato offline. I task virtuali
invece sono utilizzati per misurare il tempo di esecuzione di un determinato blocco
di codice al fine di valutare il WCET per eventuali task da creare e lanciare o per
task e/o funzioni già esistenti. Quando un file di log viene creato a partire dal
tracing di determinate informazioni, questo può essere analizzato dal Tracealyzer:
un esempio di utilizzo è mostrato in figura 1.4, situata nella pagina successiva.
E’ possibile zoomare nella traccia (il file di log ha appunto estensione .trc),
osservare l’utilizzo della CPU da parte dei task, i loro execution time e response
time, il loro livello di priorità, mostrare la comunicazione tra processi (IPC events),
ricercare specifici task o eventi (ad esempio l’acquisizione/rilascio di semafori o
l’invio/ricezione di messaggi) e generare rapporti statistici su un insieme di task
15
(contenenti ad esempio il fattore di utilizzazione della CPU Ui, il WCET Ci, la
lateness Li e lo start time ri) in formato HTML. Infine è molto importante
sottolineare che il codice sorgente del Trace Recorder e del Tracealyzer è
disponibile ed è modificabile: tale aspetto è non banale e non usuale per i tool.
Figura 1.4: Execution view di un task in Tracealyzer
1.5.2 WindView
WindView è un tool grafico sviluppato dalla Wind River ed integrato nella
piattaforma di sviluppo Tornado, utilizzata da VxWorks 5.x. Questo tiene traccia di
diversi eventi: l’esecuzione dei task, i context-switch, l’acquisizione/rilascio di
semafori, l’utilizzo della memoria, le interrupt e cosi via. Il programma prevede
una finestra grafica ed è molto “user-friendly”: l’utente deve premere il pulsante
“GO” per far partire la registrazione delle informazioni del sistema real-time target
16
(l’utente può anche scegliere cosa loggare), e fermare l’analisi premendo il pulsante
“STOP”. Inoltre è anche possibile loggare gli eventi definiti dall’utente utilizzando
la funzione “wvEvent” della libreria C di VxWorks “wvLib”, la quale consente di
memorizzare le informazioni desiderate in un buffer. In figura 1.5 la semantica del
grafico è questa: il task “tNetTask” è nello stato “pronto” nell’intervallo compreso
tra i numeri 1 e 2; nell’intervallo compreso tra 3 e 4 il task viene prelazionato e
viene eseguita la ISR relativa alla interrupt “interrupt35”; la bandierina rossa nel
punto 5 indica che è stato rilasciato un semaforo.
Figura 1.5 : Esempio di file di log ottenuto con WindView
Si tratta dunque di uno strumento molto potente che consente di effettuare
un’analisi accurata dell’ambiente VxWorks con un’interfaccia utente molto
semplice da utilizzare. Il trade-off è che quando si effettua il logging di dati del
sistema target viene creato un nuovo task che va quindi ad incrementare l’overhead
sul sistema di una quantità sconosciuta (dipendente dalla dimensione del file di log
17
e dagli eventi da registrare selezionati dall’utente), anche per via del context-switch.
Infine un altro svantaggio è che l’analisi dei file di log può essere fatta solo
nell’ambiente Tornado, il quale ha una licenza molto costosa e che è stato sostituito
dall’ IDE Wind River Workbench dalla versione 6 di VxWorks.
1.5.3 Spy
Anche Spy è un tool di monitoraggio molto semplice ed intuitivo da usare; esso
stila dei rapporti ciclici sull’utilizzazione della CPU da parte dei task di un sistema
real-time.
Figura 1.6: Il rapporto grafico di Spy lanciato dalla piattaforma Tornado
Questo tool esiste sia sulla piattaforma Tornado (si lancia facilmente dalla toolbar)
sia come funzione della libreria C di VxWorks “spyLib”: in questo ultimo caso, per
lanciare il tool deve essere chiamata la funzione spy() o da un’applicazione o dalla
shell. Spy mostra periodicamente la quantità di tempo di CPU usata da ogni task, la
quantità di tempo spesa in interrupt level (cioè il contesto in cui vengono eseguite
le ISR), il tempo speso in kernel-mode ed il tempo in cui il task è nello stato “idle”.
Il vantaggio di Spy è che si tratta di un tool che mostra in maniera molto semplice
l’utilizzazione della CPU corrente. Gli svantaggi sono dovuti all’overhead
18
apportato dalla funzione che mostra il rapporto periodicamente e dal fatto che i
risultati non sono esatti al 100 % in quanto Spy effettua un campionamento delle
informazioni dal sistema e non una vera e propria osservazione di queste.
1.5.4 Data Monitor
Questo ultimo tool grafico in ambiente real-time fa parte dell’IDE Wind River
Workbench 3.3 ed è utilizzato per monitorare variabili, strutture dati e locazioni di
memoria nel sistema real-time di interesse. E’ possibile fare un’analisi “live”,
mentre il nostro programma è in esecuzione, andando a monitorare set specifici di
variabili ed i loro valori assunti nel corso dell’esecuzione, osservare valori di picco,
controllare eventuali errori del tipo out-of-range (grazie al focus sulle locazioni di
memoria accedute), modificare il valore delle variabili mentre il programma esegue
e salvare tutte le informazioni di interesse su un file. Il vantaggio più grande di
questo tool è che fornisce un’analisi “in tempo reale”, senza stoppare o comunque
rallentare l’applicazione real-time in esecuzione che stiamo monitorando. In figura
1.7 è mostrato un esempio di monitoraggio effettuato con Data Monitor.
.
Figura 1.7: Esempio di monitoraggio con Data Monitor
19
Capitolo 2: QNX Neutrino
QNX fu sviluppato nei primi anni ’80 dalla compagnia canadese Quantum Software
Systems, ma nel 2010 la società è stata acquisita dalla BlackBerry. Il prodotto è
indirizzato principalmente al mercato dei sistemi embedded, anche se ha trovato
ampia diffusione in altre aree di mercato, come il campo automobilistico e quello
dei cellulari. Molte importanti aziende come Cisco, Delphi, Siemens e General
Electric fanno ampio affidamento sulla piattaforma software costituita dal RTOS
QNX e dai tool di corredo. Negli anni recenti ha avuto un particolare successo
commerciale: nell’aprile 2011 infatti è stato lanciato sul mercato il BlackBerry
PlayBook, un tablet basato appunto sul sistema operativo QNX; qualche mese fa,
nel marzo 2014, è invece la Apple a rilasciare il sistema CarPlay per l’informatica
mobile su auto, basato anch’esso sul RTOS QNX Neutrino.
In realtà QNX e QNX Neutrino non sono proprio dei nomi interscambiabili:
quest’ultimo nome è relativo alla versione sviluppata nel 2001, quando il RTOS
viene esteso per il supporto nativo a sistemi SMP e quando viene ufficializzata la
conformità allo standard POSIX ed alla sua estensione real-time RT-POSIX. Quasi
contemporaneamente la QNX System divenne membro del consorzio Eclipse e
rilasciò QNX Momentics, un IDE Eclipse-based con plug-in dedicati allo sviluppo
di QNX Neutrino.
Sebbene in precedenza QNX forniva una licenza d’uso utilizzabile per scopi non
commerciali, oggi questa non è più prevista ed è possibile scaricare l’intero sistema
solo in versione di prova per 30 giorni; inoltre, nonostante la licenza proprietaria,
nel 2007 è stato rilasciato il codice sorgente di QNX sotto una licenza open-source
ibrida, nel senso che il codice è stato fornito solo parzialmente. Attualmente QNX
20
gira praticamente su ogni CPU moderna che è usata nel mercato embedded: oltre
alle CPU x86, esso supporta anche architetture hardware quali ARM, PowerPC,
Intel 8088, MIPS, SH-4 e altre. Il RTOS offre il supporto ad architetture
uniprocessore e multiprocessore, compresi sistemi SMP, AMP e BMP (Bound
MultiProcessing).
L’ultima versione (QNX Neutrino 6.6) offre una vasta gamma di nuove
funzionalità a livello di grafica, multimedia, sicurezza e gestione dei consumi
energetici. Inoltre supporta anche la nuova QNX SDK for Apps and Media, la quale
permette agli sviluppatori di creare delle GUI con le moderne tecnologie web
(HTML5, JavaScript, CSS) e di sviluppare delle applicazioni HTML5.
Nei paragrafi seguenti saranno mostrate le caratteristiche tecniche di questo RTOS
e i tool di monitoraggio delle performance in ambiente real-time.
2.1 Caratteristiche generali
QNX Neutrino prevede un’architettura a microkernel, dove il kernel è l’unico
componente a girare in stato privilegiato ed implementa solo quattro servizi
fondamentali: i timer (fondamentali in un sistema real-time), lo scheduling, la
comunicazione tra processi (IPC) e la gestione delle interrupt. In questo modo nel
kernel vengono implementati tutti i meccanismi di gestione delle risorse, e non le
strategie: il vantaggio è quello di avere una maggiore flessibilità e modularità,
consentendo all’utente di assemblare un proprio sistema utilizzando solo le parti
realmente necessarie e di disattivare le parti non desiderate, il tutto senza dover
modificare o ricompilare il kernel stesso. Dunque il sistema diventa altamente
estendibile, visto che l’utente ha la possibilità di aggiungere codice scritto da egli
stesso o software di terze parti, senza il pericolo di causare malfunzionamenti nel
kernel: infatti in un sistema microkernel tutti gli altri gestori delle varie risorse del
sistema (ad esempio il file system, i device drivers, i protocolli per la gestione di
risorse, lo stack di rete TCP/IP) sono dei processi gestore (tipicamente detti server)
che girano in spazio utente con protezione di memoria, e quindi un loro eventuale
failure non influisce sul kernel; questi possono essere riavviati successivamente per
21
riprendere ad eseguire le proprie routine nel sistema. Esiste poi un processo di
sistema (che gira comunque in modalità utente) denominato “proc” che è
affiancato al microkernel e che si occupa della gestione della memoria e della
creazione degli altri processi utente. Chiaramente lo svantaggio di un sistema
microkernel è che si ha una minore efficienza, visto che ogni system call si traduce
in una comunicazione tra processi e quindi in diversi context-switch, il che è
generalmente più oneroso di una semplice system call. Nella figura 2.1 è mostrata
in maniera molto semplificativa l’architettura a microkernel di QNX:
Figura 2.1: Microkernel di QNX
Per quanto riguarda i meccanismi di security, QNX offre delle funzionalità per
progettare dei device impenetrabili: file system criptati (con l’algoritmo di cifratura
AES) e permessi di root molto limitati sono le key feature di un RTOS
all’avanguardia dal punto di vista della sicurezza.
Per quanto concerne le caratteristiche real-time, abbiamo un kernel preemptible ed
uno scheduler preemptive priority-based con 256 livelli di priorità; è inoltre
supportato uno sporadic scheduler che consente di implementare appunto degli
sporadic server (SS) per la gestione di task aperiodici: un SS è un task periodico
caratterizzato tipicamente da un periodo T ed un tempo di calcolo C (detto budget o
capacità) che mira a migliorare il tempo di risposta medio dei task aperiodici.
Il RTOS presenta delle basse latenze per quanto riguarda la comunicazione tra
processi (IPC) e la gestione delle interrupt. Per eliminare il problema della priority
inversion, anche QNX prevede l’implementazione del protocollo di Priority
22
Inheritance; inoltre è prevista l’esecuzione preemptive dei driver per consentire la
gestione prioritaria dei device di I/O. Tutti i componenti del SO comunicano con un
meccanismo basato sullo scambio di messaggi: esiste un bus software che permette
di pluggare (aggiungere/eliminare) qualsiasi componente durante l’esecuzione.
Altro aspetto molto importante è il supporto per la grafica avanzata, la quale
utilizza tecniche di layering per creare applicazioni grafiche per il mercato
automobilistico, medicale, dei giochi interattivi e degli smartphone.
Altra novità è il modulo per la gestione della potenza integrato nel kernel, il quale
offre la possibilità di controllare la potenza consumata dai componenti di sistema al
fine di ridurre i consumi energetici di dispositivi mobili (ad esempio cellulari o
tablet) ed anche alimentati a corrente.
Aspetto molto importante ed assente in tutti gli altri RTOS è quello della possibilità
di usufruire di un livello di contenimento e recupero dai guasti, il che rende ancor
più affidabile e robusta la piattaforma QNX [13].
Infine è d’obbligo citare “Foundry27”, la web community promossa da QNX
System con lo scopo di rappresentare un fulcro per lo sviluppo del RTOS; qui gli
sviluppatori possono registrarsi, scegliere la licenza ed ottenere il codice sorgente
ed il relativo toolkit di QNX Neutrino. Tuttavia dall’aprile 2010, ossia dopo
l’acquisizione da parte della BlackBerry, l’intero codice sorgente del RTOS non è
più disponibile al pubblico.
2.2 QNX Momentics
QNX Momentics è un ambiente di sviluppo integrato Eclipse-based che offre le
caratteristiche di sviluppo e di debugging comunemente fornite dagli altri IDE
Eclipse-based, ma in più anche le funzionalità proprie di QNX Neutrino. Eclipse
fornisce a tale tool suite delle interfacce ben definite cosi da assicurare che gli
strumenti appartenenti a QNX Momentics lavorino assieme perfettamente. Sono
previsti, tra gli altri, dei tool multicore-specific che consentono agli sviluppatori di
“portare” il codice in maniera pulita da sistemi single-core a sistemi multi-core,
23
ottimizzando le prestazioni in modo sicuro. Gli sviluppatori possono beneficiare di
una piattaforma open ed estendibile per l’integrazione di tool, supportata da una
community di venditori e sviluppatori di tool in rapida crescita: è infatti possibile
aggiungere strumenti di terze parti oppure, per quanto riguarda i developers, creare
i propri plug-in utilizzando il framework Eclipse industry-standard.
2.3 Monitoring tools
Anche per QNX sono previsti diversi strumenti di monitoraggio delle prestazioni in
ambiente real-time, anche se in numero minore rispetto a VxWorks. In realtà la tool
suite QNX Momentics prevede appunto un ricco set di tools utili anche per l’analisi
del sistema, come gli strumenti di profiling per comprendere appieno il suo
comportamento. Nei successivi paragrafi andremo ad elencare ed analizzare quelli
che sono i tool più interessanti per la piattaforma QNX.
2.3.1 QNX System Profiler
Tale strumento è offerto dall’IDE QNX Momentics e rappresenta la punta di
diamante dell’intera tool suite. Il System Profiler è un tool che opera in accordo con
il kernel instrumentato al fine di fornire un certo livello di conoscenza delle attività
e degli eventi del sistema operativo (ad esempio le attività dei processi gestore, le
interrupt, i context-switch, le attività di scheduling o un set di informazioni scelte
dall’utente). Infatti la code instrumentation riguarda l’inserimento automatico di
codice in alcuni punti specifici al fine di misurare dei parametri relativi alle
performance del sistema; l’instrumentazione del kernel consiste nell’abilitare dei
moduli che effettuano il monitoraggio dello stato del nucleo e delle prestazioni del
sistema. QNX System Profiler può essere usato per risolvere problemi relativi a:
bottlenecks nella comunicazione tra processi (osservando il flusso di messaggi
scambiati tra i task real-time), contesa di risorse e cache coherence in un sistema
SMP. Esso include diversi componenti rilevanti per il profiling del sistema
24
real-time sotto monitoraggio: abbiamo la vista “Target Navigator” che consente di
avviare, quando si seleziona una macchina target e con il tasto destro del mouse si
sceglie la voce “Kernel Events Tracing…”, il wizard “Trace Logging”, il quale ci
permette di selezionare gli eventi di interesse da catturare, la durata del periodo di
cattura e il path relativo alla memorizzazione del file di log che tiene traccia delle
informazioni raccolte durante l’analisi. Un altro componente molto interessante è
l’editor del System Profiler, il quale rappresenta il fulcro di tutte le attività di
analisi e fornisce diverse opzioni di visualizzazione degli eventi nel file di log. Tale
editor è automaticamente associato ai file .kev (l’estensione dei log files), anche se
è possibile associarlo ad altri file che contengono dati utili per il profiling del SO.
Figura 2.2: System Profiler editor
25
Nella figura 2.2 della pagina precedente è mostrata la rappresentazione grafica di
un file di log: come è possibile osservare, l’editor è composto da diversi riquadri
raffiguranti informazioni circa il file di log. Il riquadro “System Activity” offre un
riepilogo delle attività nel sistema andando a mostrare quanto tempo è stato speso
per servire delle interrupt, quanto tempo si è eseguito codice in kernel-mode e in
user-mode, e quanto tempo il processore è stato idle. Nel riquadro “Process &
Thread Activity” è mostrata l’attività della CPU relativamente ad un particolare
thread o processo, nonché le azioni effettuate da questi ultimi a run-time: per un
thread l’attività della CPU è definita come il tempo di esecuzione di quel thread;
per un processo l’attività della CPU è definita come l’insieme dei tempi di
esecuzione di tutti i thread di quel processo. Esistono poi altri tipi di riquadri, come
ad esempio quelli relativi agli eventi (ad esempio delle send/receive di messaggi)
ed ai loro rispettivi “possessori” (cioè processi, thread e interrupt), che possono
essere selezionati premendo il tasto destro del mouse nell’editor e selezionando
“Display Toggle”. Inoltre è anche possibile ottenere una rappresentazione 3D
degli eventuali grafici nei riquadri disponibili nell’editor. Si tratta dunque di un
potentissimo tool che accorpa un po’ tutte le caratteristiche real-time che sono
oggetto del monitoring, offrendo delle rappresentazioni grafiche e delle statistiche
rilevanti per l’analisi del sistema.
2.3.2 SAT (System Analysis Toolkit)
In un sistema in esecuzione particolari eventi come ad esempio le system calls, le
interrupt, i context-switch, lo scambio di messaggi tra processi e le transizioni di
stato di questi ultimi, possono comportare delle variazioni dello stato del sistema
sotto analisi, variazioni che sono nascoste allo sviluppatore: il SAT punta alla
cattura di queste ed alla loro memorizzazione in file di log (ogni evento è loggato
con un timestamp e con l’ID della CPU che lo ha gestito), fornendo un “filmato”
(non una semplice snapshot) su quello che accade nel sistema. Infatti tale strumento
offre un potente aiuto allo sviluppatore nel localizzare eventuali deadlock e race
26
conditions,
mostrando
quali
circostanze
hanno
portato
al
problema.
Gli obiettivi del SAT sono: essere user-friendly, fornire la dovuta conoscenza delle
attività del sistema ed offrire alte prestazioni con basso overhead sul sistema stesso.
Tale toolkit possiede quattro componenti fondamentali: il kernel instrumentato, un
gestore del buffer del kernel, un programma di data-capture (tracelogger) ed un
programma di interpretazione dei dati (ad esempio il traceprinter). Il kernel
instrumentato è effettivamente il microkernel di QNX Neutrino, ma con l’aggiunta
di un piccolo modulo per la raccolta di eventi: esso intercetta continuamente
informazioni circa l’operato del microkernel, generando dati da memorizzare in una
lista linkata circolare di buffer, come è possibile anche vedere nella figura
esemplificativa sottostante.
Figura 2.3: Panoramica della struttura del SAT
La dimensione del buffer è chiaramente limitata dalla memoria del sistema: in
particolare, quando esso raggiunge il 70% della sua capacità, il kernel
instrumentato invia un segnale con l’indirizzo del buffer per consentire l’accesso
al tracelogger, il quale a sua volta salva il contenuto in una qualche posizione di
archiviazione oppure lo passa all’interprete dei dati per effettuare una
manipolazione dei dati in tempo reale. Una volta svuotato il buffer, questo torna
disponibile al kernel instrumentato. Il tracelogger è un demone che riceve gli
eventi dal kernel instrumentato e li scrive in determinati file oppure li inoltra verso
altri dispositivi o applicativi per effettuare altre elaborazioni. Esso necessita dei
permessi di root per allocare memoria o per usare determinate funzioni. Visto che
27
tipicamente esso opera a rate abbastanza elevati (tipicamente più di
20MB/minuto), se viene eseguito per lunghi periodi di tempo potrebbe usare
grosse quantità di spazio, e nel caso quest’ultimo fosse molto poco il tracelogger
va di default a sovrascrivere il precedente file di log: in tale situazione
bisognerebbe
liberare
(manualmente
o
modificando
opportunamente
il
tracelogger) lo spazio andando a cancellare i log files più vecchi. Infine il
traceprinter porta in output tutti gli eventi loggati in ordine di timestamp.
E’ possibile anche modificare il traceprinter per effettuare analisi real-time,
mostrare risultati o statistiche, debuggare applicazioni, mostrare lo stato dei task e
le relative transizioni di stato, mostrare i task attualmente in esecuzione. In teoria,
una volta che i dati sono stati catturati dal tracelogger, è possibile elaborarli con
diversi data interpreter: la migliore soluzione resta comunque quella offerta dal
QNX System Profiler visto prima, che ci consente di effettuare delle analisi più
accurate a costo però di un overhead relativamente maggiore sul sistema.
Figura 2.4: Possibili configurazioni del processo di data interpretation
28
Capitolo 3: Tool suite a confronto
Fino ad ora abbiamo delineato le caratteristiche fondamentali di questi due RTOS,
analizzando le piattaforme e concentrando l’attenzione sulle feature real-time di
queste; abbiamo descritto dei tool di monitoraggio delle prestazioni a corredo dei
SO, analizzandone le funzionalità offerte ed osservandone pregi e difetti.
Il monitoraggio delle prestazioni di un sistema real-time è di fondamentale
importanza: un esempio cruciale è il monitoring continuo sui vincoli temporali
(quali deadline e periodi) specificati dai processi. In alcuni sistemi hard real-time è
lo stesso kernel che viene progettato con lo scopo di monitorare determinate risorse
e variabili nel sistema; in altri casi è prevista invece l’instrumentazione del kernel.
Al fine di riassumere e confrontare le capacità dei tool di monitoraggio analizzati, è
stata costruita un’apposita tabella che va a prendere in considerazione i parametri
fondamentali sui quali dovrebbe vertere l’operato di tali strumenti.
WCET
Lateness
CPU
Monitoraggio
Interrupt
variabili
Context
Overhead
switch
Codice
sorgente
√
√
√
Ҳ
√
√
NO
√
WindView
√
√
√
Ҳ
√
√
SI
Ҳ
Spy
Ҳ
Ҳ
√
Ҳ
√
Ҳ
SI
Ҳ
Data Monitor
Ҳ
Ҳ
Ҳ
√
Ҳ
Ҳ
NO
Ҳ
QNX
√
√
√
Ҳ
√
√
minimo
Ҳ
√
√
√
Ҳ
√
√
minimo
possibile
Trace Recorder
& Tracealyzer
System
Profiler
SAT
modificare
tracelogger
e/o
traceprinter
Tabella 3.1: Confronto tra i tool delle due piattaforme analizzate
29
E’ chiaro che avere delle stime del tempo di esecuzione dei task nel caso peggiore
sia assai rilevante ai fini del corretto funzionamento del sistema: senza il WCET
sarebbe impossibile effettuare analisi di schedulabilità, adottare determinati
algoritmi di scheduling, eseguire certe analisi, utilizzare gran parte dei server per
attività aperiodiche e cosi via. In certi casi i tempi di calcolo possono essere
sconosciuti o caratterizzati da una elevata varianza (in relazione alle istanze che
compongono un task); inoltre i task possono generare un overrun se il loro tempo di
calcolo viene sottostimato, il che potrebbe causare un overload del sistema (che si
presenta quando la richiesta di calcolo inoltrata eccede la disponibilità effettiva del
processore). La lateness Li ci offre un metodo per localizzare delle deadline miss:
essendo definita come la differenza tra il tempo di terminazione del task e la sua
deadline assoluta, essa rappresenta il ritardo di completamento del task rispetto alla
sua deadline (se Li < 0 vuol dire che il task termina prima della sua deadline);
questa può essere banalmente calcolata a partire dalla deadline del task (conservata
nel descrittore di un task real-time) e dal suo tempo di risposta (misurato dagli
strumenti). Il fattore di utilizzazione della CPU rappresenta la frazione di tempo
usata da quest’ultima per eseguire un particolare set di task periodici (o anche un
singolo task): pertanto offre una misura del carico della CPU da parte di un insieme
di task periodici ed è fondamentale per garantire la fattibilità di una schedulazione.
Il monitoraggio delle interrupt e dei context-switch è essenziale perché entrambi
sono fonti di non determinismo in un sistema real-time: le interrupt hardware sono
asincrone
rispetto
all’elaborazione
e
possono
portare
ritardi
indefiniti
sull’esecuzione dei processi di controllo, mentre per la latenza dovuta ai secondi
deve essere definito un limite superiore noto, indipendente dal carico del sistema,
cosi da tenere in conto anche questo tipo di delay. Infatti tra tutti i fattori che
influenzano le prestazioni di un sistema real-time, il tempo impiegato per effettuare
un context-switch rappresenta un limite intrinseco del kernel, che non dipende
dall’algoritmo di scheduling utilizzato, né dalla struttura dei task del sistema.
Inoltre, in alcune applicazioni critiche, può essere utile monitorare lo stato di
variabili, strutture dati ed accessi a locazioni di memoria al fine -ad esempio- di
controllare il corretto operato di task hard real-time.
30
Chiaramente il “NO” nella voce “Overhead” sta a significare che questo è
trascurabile. La colonna “Codice sorgente” si riferisce al fatto che quest’ultimo è
disponibile ed eventualmente modificabile per adattare il tool alle proprie esigenze.
Ritornando al confronto, è d’obbligo menzionare il fatto che VxWorks è supportato
da un numero di tool decisamente superiore rispetto a QNX: d’altronde tenendo in
conto anche il costo del prodotto, è normale pensare ad una piattaforma migliore
sotto diversi aspetti. Inoltre VxWorks ha virato fortemente sull’IoT, dimostrando di
essere un RTOS all’avanguardia delle nuove tecnologie e dei nuovi paradigmi:
questo è fondamentale essendo il campo dell’informatica altamente evolvibile.
In secondo luogo, andando a focalizzare l’attenzione puramente sui tool analizzati,
si può notare che i tool a corredo di VxWorks non fanno uso di un kernel
instrumentato, anche se in fin dei conti questo causa un degrado delle performance
trascurabile. Inoltre questi strumenti sono più specifici, nel senso che permettono di
effettuare system monitoring in maniera esclusiva, focalizzandosi su un determinato
set di aspetti (a differenza dei tool a corredo di QNX che spaziano su un ampio
range di attività di analisi): riusciamo ad analizzare l’esecuzione real-time dei task,
osservarne il loro peso sulla CPU, monitorare le risorse richieste ed ottenute,
nonché il loro utilizzo, e possiamo osservare con diversi riquadri grafici
user-friendly le caratteristiche di nostro interesse. Il trade-off comune ad alcuni tool
analizzati è l’overhead sul sistema: WindView e Spy richiedono infatti la creazione
e l’esecuzione di task aggiuntivi al fine di poter monitorare il sistema in esame.
Data Monitor invece è molto limitato e si focalizza sul monitoraggio di variabili e
locazioni di memoria. Tra tutti il migliore è sicuramente l’accoppiata
Trace Recorder-Tracealyzer perché è possibile soddisfare tutte le necessità del
monitoring di un sistema real-time, registrando tutte le caratteristiche di interesse e
costruendo da queste una traccia dal quale è possibile valutare i parametri
caratteristici dei task real-time, nonché controllare il corretto soddisfacimento dei
vincoli temporali. Inoltre la feature fondamentale che contraddistingue tale duo da
uno strumento molto simile quale è WindView, è che il codice sorgente del primo è
31
disponibile e può essere soggetto ad eventuali modifiche in caso di necessità,
mentre lo stesso non vale per WindView, cosi come per molti altri tool.
Gli strumenti di analisi che fanno da corredo a QNX invece sono essenzialmente
quelli della tool suite QNX Momentics, e quelli relativi al monitoraggio delle
prestazioni sono ben pochi rispetto a quelli di analisi: in questo elaborato sono stati
considerati due tool che vanno ad analizzare il comportamento di un sistema
real-time, registrando quelli che sono gli eventi chiave per fornire statistiche ed
aiutare lo sviluppatore nell’apportare miglioramenti sul sistema. Il QNX System
Profiler ed il SAT fanno uso di un kernel instrumentato che va ad intercettare
continuamente informazioni sull’operato del microkernel QNX, e grazie a tali
informazioni questi due strumenti vanno a monitorare le attività e gli eventi che
occorrono nel sistema target, evidenziando le tipiche caratteristiche real-time.
QNX System Profiler è sicuramente il tool principe per QNX, in quanto ci consente
di analizzare ogni singolo aspetto in maniera dettagliata, permettendo un focus sulle
prestazioni del sistema assai rilevante ai fini pratici: ciò avviene a costo di un
overhead maggiore rispetto al SAT (ma pur sempre molto basso), che d’altro canto
non offre la stessa potenza del primo né tantomeno la stessa interfaccia grafica.
Dunque possiamo dire che gli strumenti di monitoraggio che eccellono sulle due
piattaforme sono l’accoppiata Trace Recorder-Tracealyzer per VxWorks e QNX
System Profiler per QNX Neutrino: quest’ultimo strumento è chiaramente più
completo perché affronta anche aspetti esterni al puro monitoraggio delle
prestazioni in ambiente real-time, però offre delle performance con un overhead sul
sistema maggiore rispetto al tool per VxWorks, che a sua volta è specifico per le
azioni di monitoring, offre all’utilizzatore la possibilità di definire oggetti (le sonde
ed i task virtuali) per determinate attività e, eventualmente, può essere modificato
per perseguire altri fini, essendo il codice sorgente disponibile: questa è una
caratteristica molto rara da trovare nei vari tool commerciali ed è chiaramente un
grosso punto a favore per i possessori di tale feature.
Infine può essere interessante mostrare un confronto tra i due RTOS: a tal fine è
stata riportata una tabella che riporta dei risultati sperimentali sulla base di una
32
worst-case analysis del comportamento dei due sistemi; nell’analisi è stato
considerato anche un sistema operativo general-purpose di riferimento quale
Windows XP, al fine di confrontare i valori misurati e di prendere coscienza delle
differenze tra un SO normale ed un RTOS. Nella tabella il “tempo di risposta” è
inteso come l’inverso della massima frequenza di gestione delle interrupt da parte
del sistema operativo in maniera affidabile; per “latenza di interrupt” si intende
l’intervallo di tempo che corre tra l’istante in cui viene generata una interrupt e
l’instante in cui la ISR relativa produce una risposta; per “jitter” è invece inteso il
più grande intervallo di tempo tra due latenze di interrupt consecutive.
Ecco dunque la tabella che mette a confronto questi tre SO:
Response time
Interrupt latency
Jitter
VxWorks
3,85 µs
13,4 µs
10,4 µs
QNX
20 µs
35,2 µs
32 µs
Windows XP
200 µs
848 µs
700 µs
Tabella 3.2: Confronto tra i due RTOS
Dunque, in base ai risultati di tale esperimento, si può notare che VxWorks offre
delle performance migliori in termini dei parametri analizzati.
Altri studi sperimentali eseguiti sulla base di determinati parametri hanno
dimostrato che la piattaforma VxWorks è eccellente relativamente all’architettura
generale ed alle performance come RTOS, ed è un gradino superiore rispetto a
QNX Neutrino; inoltre le applicazioni suggerite da tale studio per VxWorks sono
sistemi real-time e embedded complessi e navicelle spaziali, mentre per QNX
Neutrino sono consigliati sistemi embedded, server e workstation [14].
33
Conclusioni
Durante l’elaborato sono stati considerati due tra i più importanti RTOS
commerciali, i quali sono stati analizzati dal punto di vista dell’architettura, delle
caratteristiche generali e di quelle real-time, e degli strumenti di corredo. In
particolare, per VxWorks è stato fatto un focus sul Virtualization Profile essendo la
virtualizzazione un aspetto molto importante ed attuale, soprattutto nelle aziende e
nel campo dei server: virtualizzare tramite un opportuno hypervisor le macchine
hardware su cui gira il sistema informativo aziendale significa ridurre sensibilmente
i costi dell’hardware ed incrementare vertiginosamente i livelli di utilizzo. Per
quanto riguarda QNX Neutrino, è stata analizzata brevemente la tool suite QNX
Momentics in quanto perno fondamentale della piattaforma.
Monitorare un sistema real-time è indispensabile per il corretto funzionamento
dello stesso, al fine di evitare comportamenti indesiderati che possono essere più e
meno critici: se, ad esempio, il sistema di controllo di volo su un aereo o il sistema
di regolazione di un impianto nucleare non fossero monitorati, potremmo avere
delle conseguenze catastrofiche dovute anche al superamento della deadline di
un solo task in tutto il sistema.
Tuttavia i casi di incidente storici ci insegnano che non è sempre possibile
prevedere qualsiasi cosa in un sistema real-time, perché si possono sempre
presentare delle perturbazioni o delle incertezze tali da deviare il comportamento
del sistema da quello nominale, causando malfunzionamenti non previsti nemmeno
nel testing del sistema. E’ estremamente significativa a tal proposito la celebre frase
(oggi nota come Legge di Murphy) pronunciata dall’ingegnere aeronautico
dell’aviazione americana Ed Murphy: “se qualcosa può andar male, lo farà”.
34
Ringraziamenti
E dire che all’inizio né io né nessun altro avremmo scommesso un soldo bucato sul
raggiungimento di questo obiettivo. All’inizio neanche mi rendevo conto di cosa mi
aspettava, di quale percorso avrei seguito, degli eventi che sarebbero accaduti.
Diciamo che dalla mia vita ho avuto più spine che rose, sono caduto molte volte e mi sono
rialzato più o meno bene; poi dopo il liceo e dopo diversi tentennamenti, ho deciso di
intraprendere la strada dell’università. La mia unica certezza era quella di voler dare una
scossa alla mia vita e di provare qualcosa di nuovo, cercare di raggiungere un traguardo
importante. Oggi l’ho raggiunto, dopo aver trascorso tre anni intensi, pieni di cambiamenti
e di crescita, ricchi di nuove amicizie e tante esperienze.
Un primo ringraziamento va alla mia famiglia ed ai miei genitori che mi hanno concesso la
grande opportunità di poter frequentare l’università (anche se hanno avuto ben poche
notizie sul mio rendimento).
Non farò nomi, ma non ce n’è bisogno perché le persone speciali ed importanti per me
sono consapevoli di esserlo e di avermi aiutato –tra l’altro- in questo percorso.
Un grazie speciale va agli amici che ci sono sempre e che ci sono sempre stati: anche se
spesso inconsapevolmente, mi avete sempre aiutato a risollevare il mio animo e dato nuovi
stimoli ed energie per andare avanti e non mollare mai, non solo riguardo all’università.
Voglio dire grazie anche alle amicizie più recenti, ma non per questo meno importanti:
ogni momento passato con voi è stato condito da follie e tanto divertimento, mi avete reso
felice ed io mi sento molto fortunato di avervi conosciuto.
Grazie ai compagni di viaggio ed agli amici conosciuti durante questi tre anni, avete
sopportato le mie pazzie ma soprattutto siete stati molto importanti per me, anche se, a
causa del mio pessimo carattere, non ve l’ho mai dimostrato esplicitamente. Sono davvero
contento di aver stretto amicizia con voi.
35
Bibliografia
[1]
Giorgio C. Buttazzo, Sistemi in Tempo Reale, Pitagora Editrice, 2006
[2]
J. A. Stankovic, Misconceptions about real-time computing, IEEE Computer,
October 1988
[3]
VxWorks – Wikipedia, http://en.wikipedia.org/wiki/VxWorks, 09/09/14
[4]
VxWorks RTOS, http://www.windriver.com/products/vxworks/, 09/09/14
[5]
QNX – Wikipedia, http://en.wikipedia.org/wiki/QNX, 10/09/14
[6]
QNX operating system, http://www.qnx.com/, 10/09/14
[7]
Wind River reinvents the RTOS for IoT, http://itersnews.com/?p=70622, 11/09/14
[8]
Announcing VxWorks 7, http://www.windriver.com/vxworks/reinvented/, 12/09/14
[9]
Wind River Declares Commitment to POSIX and PSE54 Conformance,
http://www.windriver.com/news/press/pr.html?ID=26 , 12/09/14
[10] Virtualization Profile for VxWorks,
http://www.windriver.com/products/platforms/virtualization_profile/, 15/09/14
[11] Johan Andersson, Modeling the Temporal Behavior of Complex Embedded Systems
[12] D. Hildebrand, An architectural overview of QNX
[13] QNX
Neutrino
Benefits,
http://www.qnx.com/products/neutrino-rtos/neutrino-
rtos.html#benefits, 16/09/14
[14] N. Tiwari - J. Saraf – M. Agrawal – S. Jain, A User Friendly Classification &
Analysis of Real Time Operating System
[15] QNX Software System GmbH, System Analysis Toolkit: User’s Guide
36