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

4

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

5

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).

6

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.

7

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

8

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

9

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

10

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

11

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

12

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

13

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:

14

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.

15

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

16

(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

17

(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

18

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

19

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

20

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

21

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

22

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

23

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,

24

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

25

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

26

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

27

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

28

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

29

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

variabili

Interrupt Context

switch

Overhead Codice

sorgente

Trace Recorder

& Tracealyzer

√ √ √ Ҳ √ √ NO √

WindView √ √ √ Ҳ √ √ SI Ҳ

Spy Ҳ Ҳ √ Ҳ √ Ҳ SI Ҳ

Data Monitor Ҳ Ҳ Ҳ √ Ҳ Ҳ NO Ҳ

QNX System

Profiler

√ √ √ Ҳ √ √ minimo Ҳ

SAT √ √ √ Ҳ √ √ minimo possibile

modificare

tracelogger

e/o

traceprinter

Tabella 3.1: Confronto tra i tool delle due piattaforme analizzate

30

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.

31

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 è

32

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

33

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].

34

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à”.

35

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.

36

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