Analisi di soluzioni per il real-time monitoring

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Real-Time Analisi di soluzioni per il real-time monitoring Anno Accademico Candidato: Andrea Aletto matr. N

2 Indice Indice... II Introduzione... 3 Capitolo 1: Run-Time Monitoring of Real-Time Systems Eventi Tipo di monitoraggio Monitoraggio attivo Monitoraggio passivo Satisfiability Checker Capitolo 2: Momentics per QNX-Neutrino System Information SAT QNX System Profiler Capitolo 3: Monitoring per VxWorks Monitoring per Workbench CoverageScope MemScope Monitoring per Tornado WindView Spy Tracealyzer Conclusioni Bibliografia... 36

3 Introduzione Nella società odierna ricoprono un ruolo di primaria importanza i sistemi in tempo reale, che fondano la validità del calcolo effettuato sul concetto di esattezza logica (il sistema produce il risultato esatto) e di correttezza temporale (il risultato è ottenuto in tempo). Sebbene i sistemi real-time trovino utilizzo in un vastissimo campo applicativo, un fattore comune sempre presente e determinante è insito nel concetto di deadline, la cui caratterizzazione determina appieno la criticità del sistema: si parla infatti di sistemi soft, firm e hard real-time a seconda del danno provocato dallo sforamento di una deadline. Sarebbe, ad esempio, inaccettabile il ritardo di una segnalazione su un radar in ambito avionico, per cui è obbligatorio investire le dovute risorse per garantire sempre il corretto funzionamento in tempo reale dell intero sistema; è, viceversa, accettabile uno sforamento di deadline in ambito telefonico, in quanto ciò comporterebbe esclusivamente un degradamento della Quality of Service (QoS) fornita dal sistema. È, inoltre, possibile notare che un qualunque sistema multi-task è composto da almeno un processo il cui fallimento può portare in uno stato inconsistente l intero apparato: tali processi vengono definiti task hard RT ; a questi si contrappongono naturalmente i task soft RT, il cui fallimento porta, ancora una volta, soltanto un degradamento della QoS. Spesso, sbagliando, si associa il concetto di tempo reale con quello di velocità di esecuzione in termini di velocità media di completamento dei task. Risiede in questo un altra fondamentale differenza con i sistemi non real-time: non è importante che il 3

4 sistema sia nel complesso veloce e reattivo, ma soltanto che venga sforato il minor numero possibile di deadline (talvolta, un solo requisito temporale non rispettato può portare a conseguenze catastrofiche). È dunque di fondamentale importanza, fin dalla fase di sviluppo del software, la predicibilità dello stesso, chiedendosi, di conseguenza, quali siano le fonti di non-determinismo che minano una corretta analisi statica, trovando risposta in un insieme pressoché infinito di cause, che vanno dall incertezza strumentale nei dispositivi (periferiche di I/O) interfacciati al sistema da testare, fino a problemi interni allo stesso sistema operativo. Essendo impossibile modellare la realtà con cui dover interagire, risulta d obbligo analizzare le cause di non determinismo interne e provare, per quanto possibile, a predirle. È chiaro quindi che un sistema operativo time-sharing, costruito per garantire il massimo grado di parallelismo nell esperienza dell utente, che nella quasi totalità dei casi è umano, non può in nessun modo soddisfare le stringenti richieste temporali di un sistema in tempo reale: è necessaria l introduzione di un kernel specifico, che supporti system-calls che tengano conto dei task RT e che implementi delle apposite strutture dati per garantire i vincoli di priorità nella schedulazione del task. Un sistema operativo pensato e realizzato per l ambito del tempo reale è chiamato RTOS (Real-Time Operating System) e attualmente sul mercato ne esistono più di un centinaio tra kernel-rt commerciali e open-source, adattati per diverse piattaforme, dai pochi KB per le rom dei MCU di FreeRTOS, a dimensioni ben più sostenute di VxWorks o QNX. La quasi totalità di questi kernel fornisce anche dei meccanismi di scheduling basati di solito su priorità fisse con la possibilità di prelazione, dal momento che essa permette latenze più basse e una efficienza di risorse maggiore. Tipicamente, gli RTOS sono accompagnati da una suite software che implementa diverse funzionalità utili per lo sviluppo e per l analisi di applicazioni in tempo reale come ad esempio il tracer, per visualizzare le attività del kernel con un interfaccia tipicamente user-friendly, il performance profiler, per misurare le prestazioni del sistema, strumenti di monitoraggio per conoscere lo stato dei task e delle relative variabili a run-time. Essendoci, quindi, una criticità così forte sul concetto di tempo, sorge la necessità di poter 4

5 monitorare i processi attivi sul sistema, tramite un analisi che, sia essa manuale o automatica, permetta di capire se il sistema does the right thing on time. Verranno nel seguito considerate delle strategie per riuscire nell obiettivo di monitorare il sistema, in particolare verrà presentata dapprima una soluzione teorica che fonda le sue basi in uno studio universitario americano, il quale fa delle ipotesi sulla struttura che un task RT deve avere per poter agevolare l azione di monitoraggio; nel seguito di tale elaborato, invece, verranno mostrate delle soluzioni software (sia proprietario sia open source) per il monitoraggio specifico dei sistemi operativi real-time che dominano lo scenario commerciale dei sistemi embedded, ovvero QNX e VxWorks. 5

6 Capitolo 1: Run-Time Monitoring of Real-Time Systems Una prima soluzione analizzata è lo studio teorico, poi implementato al calcolatore, battezzato col nome di Run-Time Monitoring of Real-Time Systems, dei ricercatori Chodrow (University of Texas at Austin, TX), Jahanian e Donner (IBM Research Center, NY), la cui idea è stata quella di fare in modo che il sistema potesse in qualche modo auto-monitorarsi, in modo da avere un feedback affidabile dello stato corrente del sistema e potersi quindi autogestire, risolvendo bloccaggi, deadlock e ritardi in maniera estremamente dinamica e contestualizzata. L insieme dei task del sistema è diviso in 3 parti: tasks with embedded constraints, watchable tasks e un unico processo osservatore, denominato per questo monitor. L intero studio si basa sulla possibilità da parte dei task dei poter segnalare degli eventi, che chiaramente saranno diversificati a seconda del campo applicativo del modello, però è comunque possibile distinguere degli eventi fondamentali, i quali sono sempre presenti in ogni tipo di applicazione, come ad esempio l inizio o la fine di una procedura, la segnalazione di lock e unlock di una risorsa protetta, la lettura e la scrittura di un messaggio in una coda IPC, ecc. Tali eventi verranno registrati in un segmento di memoria. Una parte del sistema si occupa di tradurre le specifiche temporali dei task in vincoli logici e, dall analisi dei timestamp delle occorrenze del singolo evento, è possibile capire se il task sta funzionando nel modo corretto. Secondo la pubblicazione, il primo tipo di processo deve essere un vero e proprio task 6

7 auto-monitorante, nel senso che contiene, al suo interno, strutture dati e istruzioni tali da riuscire a implementare degli statement di verifica sul soddisfacimento dei vincoli temporali; il secondo, invece, deve essere un processo che, seppur a conoscenza dell azione di monitoraggio, deve lasciare tale procedura ad un altro sistema esterno, concepito esclusivamente per eseguire questo compito. 1.1 Eventi Lo progressione di un task RT si può vedere come una sequenza di occorrenze di eventi; in maniera informale si definisce come evento una serie di cose che accadono [2] in un sistema e l occorrenza di esso fissa l istante di tempo ben preciso in cui si verifica lo stesso. Gli eventi distinguibili sono di due categorie: la prima, gli eventi label, sono quelli che definiscono l inizio e la fine di una certa sequenza di istruzioni (una funzione, un task, un ciclo, ecc.) e vengono formalmente indicati con una freccia che punta verso l alto (inizio) o verso il basso (fine) posta affianco al nome scelto per l evento, e.g. E1 rappresenta la fine dello statement chiamato E1. A questi si contrappongono gli eventi transitori che catturano il valore di una determinata variabile (detta watchable variable ) dedita allo storage di informazioni riguardante lo stato del sistema e la sua integrità in termini di tempo reale. Un sistema real-time evolve mentre accadono questi due tipi di eventi, è dunque necessario esaminarli, tenerne traccia e trarre da essi informazioni; inoltre gli algoritmi per salvare le occorrenze di un evento sono molto semplici (si tratta solo di catturare un timestamp, salvare il numero delle occorrenze e dare un nome a questo record) e le informazioni ricavabili sono estremamente significative, per cui è ragionevole pensare di dedicarci un segmento di memoria. È verosimile uno scenario in cui, durante un esecuzione concorrente di più task RT, l occorrenza di un certo evento generico sia segnalata da più di un task e si sfrutti questo dato per effettuare delle operazioni logiche: ad esempio si definisca l evento E 1 è stata completata una transazione in un tempo t inferiore a 1ms, l evento E 2 non completare più di 10 transazioni entro un 1ms e l evento E 3 inviare una segnalazione se l ultima 7

8 transazione effettuata risale a più di 1s fa ; questi tre eventi sono generici e non fanno esplicitamente riferimento a un ben determinato task, per cui tutti i P i processi attivi (che supponiamo concorrenti) potrebbero invocare un occorrenza degli eventi. È, quindi, necessario poter tenere traccia non solo dell ultima occorrenza, ma di uno registro storico dell evento, che contiene sia il numero totale delle occorrenze chiamate, sia il timestamp della più recente. Viene quindi utilizzata la seguente struttura per l evento, contenente un identificativo univoco, un counter di quante occorrenze si sono verificate in totale, una coda circolare che conserva timestamp e valore dell eventuale variabile, un indice relativo che costituisce un puntatore alla testa della coda circolare ed infine, siccome la scelta della Figura 1.1: Record evento dimensione dello storico dell evento è lasciata al progettista, un puntatore alla fine della struct, come in figura 1.1. Parallelamente al formalismo teorico, è affiancata una proposta di implementazione, utilizzando funzioni RTL-like per l accesso sicuro, sequenziale ed esclusivo al record che caratterizza l evento. Funzioni di esempio che vengono proposte dove e=id_evento, i=index. Restituisce il timestamp della i-esima occorrenza dell evento richiesto, facendo la convenzione che le occorrenze vengano ordinate per timestamp crescenti. È possibile chiamare la funzione con un indice negativo, avendo come risultato la i-esima occorrenza più recente, ovvero una ricerca nello storico a partire dalla fine della dove v=nome_watchable_variable, i=index. Restituisce il timestamp della i-esima occorrenza della variabile v. Anche in questo caso si scorre la lista al contrario se viene richiesto un indice dove e=id_evento, i=index. Restituisce la posizione nella coda circolare dell occorrenza più recente dell evento considerato. 8

9 1.2 Tipo di monitoraggio Come già anticipato, i task si dividono in due gruppi: i tasks with embedded constraints che implementano al loro interno meccanismi di monitoraggio e i watchable tasks che vengono osservati dall azione di un processo esterno detto monitor. Verranno di seguito analizzate due diverse azioni di monitoraggio: il monitoring attivo, quando il task è strutturato in modo tale da auto monitorarsi e darsi autonomamente un feedback per capire che azione di controllo intraprendere e il monitoring passivo, quando il task dichiara i suoi vincoli temporali, ma lascia ad un altro processo (o talvolta un altro sistema) il compito di essere monitorato mediante appositi comandi di enable/disable Monitoraggio attivo Una struttura di questo tipo implica necessariamente che sia il programmatore a prevedere che il sistema debba essere monitorato e a gestire le diverse situazioni di soddisfacimento e violazione delle specifiche real-time del processo, pertanto è una soluzione che, se da un lato non è trasparente alle funzionalità del task, dall altro dà garanzie maggiori in termini di performance e affidabilità dell azione di monitoraggio, rispetto ad un processo ignaro dell ambiente in cui si trova (si rimanda ai cenni conclusivi per l analisi dei vantaggi e svantaggi di questa scelta). Questa soluzione è chiamata anche monitoraggio sincrono, poiché è presente all interno del sorgente dell applicazione una serie di istruzioni dedicata esclusivamente al testing a runtime del programma, che pertanto verrà effettuato ciclicamente ogniqualvolta il flusso di esecuzione attraversa quel blocco di statement. Ad esempio, si consideri questo particolare vincolo, legato al corrente flusso temporale, per la gestione di una caldaia: si vuole regolare la resistenza di una caldaia se la temperatura dell acqua ivi presente è salita o no troppo velocemente. Se si vuole utilizzare una soluzione di tipo embedded il feedback necessario all impianto (e quindi l azione di monitoraggio attivo) sarà del tipo 9

10 Figura 1.2: Esempio gestione caldaia Questo snippet di codice deve essere incluso dal programmatore stesso all interno del codice sorgente dell applicazione real-time. Per quanto riguarda la struttura che il sistema dovrà avere, ci saranno un numero P di task differenti (intesi, qualora desiderato e supportato dal kernel, anche come thread appartenenti allo stesso processo) che devono poter accedere ad una memoria comune in cui risiedono i vari record con gli storici degli eventi. Poiché la memoria condivisa può essere causa di inconsistenza logica, se non correttamente usata, è necessario accedervi utilizzando il paradigma semaforico. A tale scopo viene instanziato un task di inizializzazione del sistema che si occupa appunto di svolgere, prima dello start delle attività che devono eseguire sul sistema, le attività preliminari di riservare lo spazio di memoria condivisa, inizializzare un semaforo per accedervi in maniera mutuamente esclusiva, far partire il sistema in maniere definitiva. Essendo una risorsa protetta essa può generare il ben noto problema dei deadlock, che affligge la maggioranza dei sistemi operativi (anche non real-time) che svolgono attività concorrenti e utilizzano risorse protette (tutti i sistemi operativi time-sharing dei comuni pc da ufficio ne costituiscono un esempio) obbligando i relativi processi ad aspettare indefinitamente per avere il controllo assoluto di una risorsa protetta. La soluzione a questo problema sta nell utilizzare un unica risorsa condivisa (la shared memory degli eventi per l appunto), oppure nell eliminare totalmente ogni forma di concorrenza e multitasking nel sistema; entrambi sono scenari piuttosto inverosimili, se non in applicazioni mission-critical, ma gli studiosi di cui Figura 1.3: Schema fondamentale del monitoraggio attivo 10

11 sopra, seppur citando il problema, focalizzandosi sull aspetto del monitoring piuttosto che quello della corretta gestione della concorrenza in un sistema operativo, non ne offrono una soluzione. In definitiva, uno schema complessivo del sistema è un insieme di task, tutti collegati all elemento centrale che è la shared memory, come desumibile dalla figura Monitoraggio passivo In questa architettura, il task chiede di essere verificato tramite una ben precisa richiesta di monitoring fatta ad un task esterno (talvolta esterno non solo al processo richiedente, ma addirittura all intero sistema). Il processo, in questo modo, non deve implementare nel proprio codice le funzioni e la relativa logica per capire se sta violando alcune delle proprie specifiche, perché questa attività è svolta da un entità concepita proprio per questo motivo; deve tuttavia essere a conoscenza dell esistenza del monitor, perché è il task stesso a richiedere l attivazione dell azione di monitoraggio, pertanto anche in questo caso, come nel precedente, non si ha un grado di accoppiamento nullo, però, di contro, il processo è alleggerito, perché può essere ottimizzato per le funzionalità che deve svolgere. La conoscenza del monitor, d altra parte, è d obbligo anche per una seconda motivazione, che risiede nel riuso delle informazioni catalogate sugli eventi: mentre nel monitoring attivo il task va a leggere tali informazioni autonomamente e in base ad esse regolava il proprio comportamento, stavolta il monitor conosce i vincoli del processo, si fa carico di controllarli ed eventualmente segnalare errori al task monitorato. Da questo si capisce facilmente che non si ha più la necessità di dedicare un area di memoria comune ai task, perché questi dovranno sempre e soltanto riferirsi al monitor. Dunque il processo monitor è composto da una struttura esterna che da un lato si comporta da interfaccia per i processi esterni e dall altro protegge automaticamente, senza l uso di ipc, le informazioni vitali per il funzionamento dell intero meccanismo analizzato, le quali saranno naturalmente posizionate in un area di memoria allocata al monitor, visto che in ogni caso è esso stesso l unica entità che può e deve accedere a tali informazioni. 11

12 Il meccanismo del feedback è realizzato sempre a mezzo del processo esterno, il quale si fa carico, nel caso in cui i vincoli siano violati, di segnalare il malfunzionamento al task monitorato; la successiva gestione di tale segnalazione è data al programmatore. Il paradigma di esecuzione-segnalazione-gestione ricorda il meccanismo delle interruzioni nella programmazione, le quali, essendo notoriamente eventi asincroni, danno l appellativo di asincrono come sinonimo di passivo in questo tipo di monitoraggio. Se si utilizza una soluzione di questo tipo, c è però un meccanismo da dover definire per la gestione concorrente dei salvataggi dei record degli eventi: il monitor può comunicare sequenzialmente ed esclusivamente con un solo processo alla volta, è pertanto necessario l utilizzo di una coda di messaggi in cui il singolo task deposita le informazioni riguardanti la singola occorrenza dell evento, informazioni che verranno poi processate dal monitor stesso. Si evita, per ragioni di indeterminazioni e bloccaggio, di utilizzare un unica coda che discrimina i processi tramite un identificativo, ma si preferisce usare la suddetta struttura di Inter Process Communication singolarmente per ogni task. La politica di processing delle singole code è chiaramente FCFS, perché l ordine in cui i messaggi sono depositati è cronologico, inoltre anche la scelta di quale coda schedulare tra tutte è di tipo FCFS, per garantire in ogni istante l integrità temporale e cronologica dello storico dell evento. Entrambe le scelte (della coda e del messaggio da consumare ) sono fisicamente realizzate tramite un confronto del timestamp dell occorrenza, la quale è in questo contesto rappresentata proprio da un messaggio; il timestamp, quindi, assume un duplice fondamentale ruolo, poiché se da un lato è utilizzato per capire se un task sta sforando le proprie deadline, dall altro è usato anche dallo stesso monitor per autogestirsi e fare in modo che il contenuto dei record degli eventi sia in ogni istante cronologicamente coerente con lo scorrere continuo del flusso temporale. In figura 1.4 è mostrato uno schema semplificativo della comunicazione tra i task del sistema e il processo/sistema monitor. Figura 1.4: Schema fondamentale monitoraggio passivo Un ultima importante questione da modellare è la maniera in cui il monitor viene a 12

13 conoscenza dei vincoli temporali dei task che esso analizza. Il task deve contenere un blocco nel proprio codice in cui dichiara i propri vincoli temporali tramite delle formule logiche (come la condizione dell if nel precedente paragrafo), le quali verranno lette dal monitor e convertite in un linguaggio ad esso compatibile, ottimizzate per essere indicizzate e controllate da una componente separata del monitor detta Satisfiability Checker, analizzata nel seguito. Riassumendo, il monitoring passivo o asincrono avviene nel modo seguente: il task chiede al monitor di essere controllato, quest ultimo legge e converte i vincoli temporali del task e inizia l analisi sfruttando le regole e gli algoritmi di controllo del Satisfiability Checker; talora i vincoli siano stati violati, sarà immediatamente mandata una notifica al task, il quale dovrà implementare un handler per gestire tale segnalazione. Parallelamente al lavoro di controllo del monitor, dovrà essere svolto il lavoro di raccolta dei dati sulle occorrenze degli eventi che accadono nell ambiente Figura 1.5: Interazione Monitor-Task circostante al sistema. 1.3 Satisfiability Checker È il cuore della logica di controllo del monitor, per questo motivo si è scelto di dedicare ad esso una sezione intera, analizzando nel dettaglio il modo di conversione suggerito e l algoritmo di checking dei requisiti dei task richiedenti, tramite un esempio esaustivo, oltre che presentando le regole formali su cui si fonda la componente software in esame. Come anticipato, i vincoli vengono espressi tramite funzioni RTL-like, che è un meccanismo semplice, ma di difficile controllo perché richiede numerose chiamate innestate a funzioni e comparazioni, in quanto si tratta di funzioni che per loro natura sono 13

14 estremamente basilari e lavorano ad un livello di astrazione piuttosto basso. Ad esempio, si consideri il seguente vincolo temporale: l evento RESPONSE, caratterizzato da un inizio e una fine, deve essere completato prima di una certa deadline, indicata dall occorrenza dell evento SIGNAL ; lo snippet che identifica tale vincolo è Figura 1.6: Requisito in forma RTL-like che utilizza 9 chiamate a funzione, 3 confronti e una AND logica. Per vincoli più complessi, in cui compaiono anche delle OR e dei confronti condizionali, la complessità del calcolo del vincolo a run-time cresce, introducendo ritardi sempre maggiori. Si dimostra che una possibile soluzione è quella di tradurre la formula in una struttura ad albero in cui gli OR sono le radici, gli AND i nodi intermedi e i confronti le foglie. Tale albero verrà poi trasformato in un grafo direzionato e pesato secondo le seguenti regole: Il nodo di arrivo è quello che nel confronto sta dalla parte del minore Il nodo di partenza è quello che nel confronto sta dalla parte del maggiore Le costanti vengono sempre portate dal lato del nodo di partenza e costituiscono il peso della connessione Una AND logica indica la connessione dei grafi, una OR invece una disgiunzione dei grafi Qualora ci dovesse essere soltanto una costante e non un nodo di partenza/arrivo, questo viene sostituito da un nodo detto zero 14

15 Da questi 5 semplici regole si traduce il vincolo prima in albero, poi in grafo. Ad esempio: Figura 1.7: Esempio di conversione RTL grafo orientato Questo grafo è desumibile a tempo 0 dalle specifiche temporale del processo, serve quindi un algoritmo di analisi di tale task in riferimento ad una sequenza di occorrenze: Quando si verifica un occorrenza di un evento, il nodo del grafo corrispettivo viene sostituito da un nodo zero Se il nodo tolto è un nodo di arrivo con ramo di peso P, allora il nuovo peso del ramo sarà P-T, dove T è il tempo corrente. Se il nodo tolto è, viceversa, un nodo di partenza con ramo di peso P, allora il nuovo peso del ramo sarà P+T. Il vincolo è violato si crea un ciclo con peso negativo È facile verificare che i vincoli dell esempio sono violati a fronte della seguente sequenza temporale di eventi: Figura 1.8: Sequenza cronologica di eventi 15

16 a tempo t = 2, si ha il grafo orientato con ciclo negativo mostrato in figura: Figura 1.9: Esempio di deadline sforata che mostra evidentemente la violazione di almeno uno dei vincoli temporali. 16

17 Capitolo 2: Momentics per QNX-Neutrino QNX è un RTOS Unix-like, che mira principalmente al mercato dei sistemi embedded. Il sistema fu creato nei primi anni 80 da G.Bell e D.Dodge, allora due studenti canadesi durante la frequentazione del corso di Sistemi Operativi all Univerisità di Waterloo in Ontario. Alla fine degli anni 80 il sistema si muove verso una direzione che si sarebbe poi rivelata la scelta giusta: l adattamento allo standard POSIX nella major release QNX 4. La successiva major release, fu rilasciata nel 2001 ed è di fatto la stessa base utilizzata ancora oggi, QNX Neutrino, la cui differenza risiede principalmente nel completamento dell implementazione delle API POSIX e l incorporamento nel proprio kernel anche dell implementazione dello standard RT-POSIX. Tuttavia, nel suo sviluppo e nella sua storia, si vede una svolta decisiva nel momento in cui, nel 2010, QNX Neutrino fu acquisito da Research In Motion (RIM), famosa per il brand mobile BlackBerry, facendo di fatto approdare il sistema anche nel mercato mobile tramite il tablet Playbook che monta proprio il RTOS canadese. Contando già su un microkernel molto robusto ed affidabile, compatibile con numerose architetture hardware (x86, ARM, PowerPC, MIPS, ecc.), i successivi aggiornamenti, fino alla versione QNX Neutrino 6.6 del 2010, hanno offerto all utente soltanto un miglioramento prestazionale e l aggiunta di funzionalità di grafica, di sicurezza, di multimedialità, di sviluppo ed infine di monitoring, senza variare in maniera troppo spinta 17

18 il cuore del sistema. Tralasciando la trattazione nel dettaglio delle caratteristiche fondamentali del sistema QNX, la quale esula dallo scopo di tale elaborato, si analizzeranno adesso i meccanismi software messi a disposizione da RIM per il monitoraggio del sistema. L idea di RIM è stata quella di voler integrare tutti i servizi per lo sviluppatore in un unico tool di sviluppo, debugging e monitoraggio tramite un IDE Eclipse-based denominato Momentics. Per quanto concerne l aspetto del monitoring di sistema, in Momentics sono implementati tre tool estremamente utili e potenti per l analisi a run-time dei task attivi; essi sono il System Information, il System Profiler e il System Analysis Toolkit (SAT). 2.1 System Information Un primo set di tools per il monitoraggio è chiamato System Information. Si tratta di una soluzione molto potente a causa della moltitudine di informazioni eterogenee che riesce a Figura 2.1: System information 18

19 dare all utente, pur rimanendo nel contesto di analisi di un unico processo alla volta. La sua forza sta nell estrema modularità, infatti è composto da tools che sono completamente indipendenti tra loro, che ricavano un quadro informativo completo del task, fornendo addirittura un meccanismo all utente per poter inviare dei comandi a run-time al processo selezionato oppure ad un suo thread. In riferimento allo screenshot, è possibile notare la sua interfaccia estremamente userfriendly, infatti basta selezionare nella scheda target navigator dapprima la macchina target, poi il processo da monitorare, per avere un set di informazioni (sulla destra) riguardanti l impatto del task sul sistema intero. Analizzando nel dettaglio lo strumento, le informazioni fornite sono ripartite cinque schede: Target Navigator, mostra la lista di tutte le macchine (reali o simulate) connesse all IDE e, di queste, ogni processo attivo. Tramite una voce del menu contestuale è possibile mandare un signal al processo, che verrà poi gestito a seconda dell override (se presente) dell handler dei segnali del task stesso. System Summary, è diviso in 3 schede; contiene informazioni riguardanti il sistema in generale, quindi versione del RTOS, tipo di architettura e clock della CPU nella prima sezione, un prospetto generale sia grafico che testuale della memoria nella seconda sezione ed infine una lista dettagliata di tutti i processi del sistema, divisi in locali e remoti, nella terza sezione. Process Information, è anch esso diviso in tre schede; conserva informazioni generali riguardo il processo selezionato. Nella prima sezione ci sono riferimenti ai thread instanziati dal processo, con una moltitudine di informazioni a disposizione, ad esempio è possibile vedere la priorità nella schedulazione, lo stato del thread (quindi se è in attesa su una risorsa, se è in coda di schedulazione o se è attivo e sta eseguendo), l eventuale risorsa che il thread sta aspettando di ottenere, il quantitativo di memoria stack utilizzata e tante altre. Nella seconda e terza sezione, invece, le informazioni sono più orientate al sistema operativo, in quanto è possibile vedere l insieme delle variabili d ambiente utilizzate e il descrittore del 19

20 processo. Memory Information, contiene informazioni dettagliate sulla memoria virtuale assegnata al processo e le mostra a video in due modi: il primo è una raffigurazione segmentale della memoria, divisa in parti di diverso colore per indicare le diverse funzioni assunte dallo spazio di indirizzamento assegnato al task, in particolare vengono mostrati lo stack, l area codice, l area heap, le shared library (cioè le librerie caricate a runtime) e la memoria inutilizzata. Al di sotto di questa raffigurazione, la stessa memoria viene mostrata anche testualmente, tramite l utilizzo di una tabella che mostra dettagliatamente ogni segmento di memoria virtuale assegnata al processo come viene da questi utilizzato, mostrandone, tra le altre cose, anche le dimensioni e il posizionamento all interno dello spazio di indirizzamento disponibile. Questa sezione è particolarmente utile per trovare i cosiddetti errori di stack, cioè quegli errori derivanti da un cattivo utilizzo della memoria stack che causa il malfunzionamento del programma per il salvataggio di troppi record di attivazione e funzioni ricorsive troppo onerose in relazione alla memoria disponibile. Malloc Information, è l ultima scheda di monitoring del set di tools analizzato e si focalizza sullo stato della memoria heap (il nome malloc rimanda proprio alla system-call in C che alloca spazio in memoria heap). Una prima sezione riguarda lo stato attuale della suddetta memoria, che viene visualizzata in forma grafica; segue poi un contatore di quante volte sono state chiamate le funzioni di gestione della memoria (cioè la malloc(), free(), realloc()), dati da cui si può desumere se il processo sta effettivamente utilizzando troppa memoria senza rilasciarla, o sta effettuando troppe system calls che rallentano l esecuzione del task. Segue poi un grafico, campionato in istanti di tempo richiesti, della situazione della heap, in modo da capire il trend d utilizzo della stessa. Infine è stata introdotta una tabella, che analizza in dettaglio per un dato range di bytes quante malloc, free, realloc sono state chiamate (se ad esempio il task richiede una malloc da x bit con x tra 65 e 128 bytes, allora il contatore relativo a questa fascia verrà incrementato di uno). 20

21 In definitiva, il tool System Information, fornisce delle informazioni riguardante lo stato del sistema dal punto di vista del RTOS. Le informazioni ricavabili, sono di grossa rilevanza, ma non sempre sono utili per la caratterizzazione completa di un malfunzionamento o di una situazione ai limiti della criticità, proprio perché si osserva il task dal di fuori, guardando solamente alle informazioni esterne che il task deve obbligatoriamente (per ragioni di sicurezza ed adattamento al sistema globale) comunicare al RTOS. Ciò che manca in questa suite è quindi un modo per poter accedere ai meccanismi interni del task, dove risiedono, tra le altre cose, anche i requisiti temporali che l applicazione deve rispettare; infatti è bene notare che lo strumento appena analizzato non fornisce in alcun modo un aiuto nel monitoraggio della componente temporale del processo, ma soltanto per quella logica e sistemistica. Essendo QNX un RTOS, non potevano non essere rilasciati dei meccanismi per poter affrontare la questione appena proposta. Essi risiedono nelle componente software System Profiler (SP) e System Analysis Toolkit (SAT). 2.2 SAT Il System Analysis Toolkit è definito dagli sviluppatori di QNX come uno strumento che va oltre il semplice debugger. Il progetto mira a fornire un quadro complessivo del sistema senza tralasciare i meccanismi del RTOS a livello più basso. Un semplice debugger è in grado di analizzare e registrare solo gli eventi riguardante il contesto in cui viene eseguito, cioè ad esempio, se si sta effettuando il debug di un processo, che, in un ben determinato istante di tempo chiama una funzione del kernel (un allocazione di memoria ad esempio), non si riesce a vedere oltre il punto di vista del processo analizzato: i meccanismi interni del sistema operativo sono trasparenti al debugger, che quindi non potrà calcolare l impatto che l azione ha avuto sul sistema. Ciò che gli ingegneri RIM decidono di offrire è un tool di analisi che permetta allo sviluppatore di poter guardare il sistema dal livello del RTOS, ma mantenendo la possibilità di capire come stia evolvendo al suo interno il task analizzato. Ironicamente, gli 21

22 sviluppatori del SAT affermano che questo strumento può fornire un movie (cioè un filmato), laddove invece un semplice debugger può generare solo uno snapshot (cioè una fotografia). Risulta quasi evidente, che per poter offrire un campo di informazione così ampio e dettagliato è necessaria una modifica del microkernel di QNX; parallelamente allo sviluppo del kernel da utilizzare regolarmente (detto release ), viene sviluppata una sua versione modificata (detta instrumentato ), che contiene alcuni moduli specifici per la raccolta di informazioni, che verrà poi realmente effettuata da una componente software separata. Il kernel instrumentato, pertanto, intercetta informazioni riguardante i processi e li scrive in un buffer, implementato come lista linkata circolare, da cui verranno prese e salvate da una componente detta Data Capture ed interpretati da un ulteriore modulo detto di Data Interpretation In dettaglio, il SAT è composto di quattro blocchi principali: Figura 2.2: System Analysis Toolkit Il primo è proprio il kernel instrumentato, di fatto indistinguibile dal kernel release, se non per la presenza dei moduli di raccolta di informazioni. Un ampio testing su questo insieme di moduli ha dato come risultato che, in rapporto al kernel release, l impatto sul sistema provoca una perdita di velocità di esecuzione di circa il 2%. Il secondo blocco è il buffer del kernel, che, come detto, è realizzato mediante una lista linkata circolare: il modulo di raccolta dati si occupa di scrivere le 22

23 informazioni all interno di tale buffer, sovrascrivendo gli elementi più vecchi, nel caso in cui esso dovesse essere saturo. Un gestore del buffer, infine, si fa carico di segnalare alla componente successiva quando il livello dei dati è in prossimità di saturazione (circa il 70% di occupazione di spazio disponibile). Il terzo blocco è il Data Capture (o anche tracelogger ), un demone che riceve un segnale dal gestore del buffer, che lo abilita al salvataggio delle informazioni scritte in memoria. Il log che questo blocco andrà a comporre può essere scritto su file o passato ad un device esterno, ma sarà in ogni caso un file binario che, in questa fase, non ha un ben preciso significato. Lo stream di bit contenuti nel log deve essere, a questo punto del processo di monitoraggio, interpretato. Il quarto e ultimo blocco che compone il SAT è proprio l interprete del file binario generato al punto precedente, detto anche traceprinter. Esso produce un vero e proprio log, analizzabile dall utente in cui sono riportati tutti gli eventi di sistema ordinati per timestamp crescenti. Per quanto riguarda questo componente, RIM dà allo sviluppatore la possibilità di poter effettuare un override delle sue funzioni, in modo da definire le proprie originali funzioni di monitoring. È pertanto possibile, grazie a questa flessibilità, trasformare il traceprinter in uno strumento per analizzare in tempo reale i task, per mostrare risultati e statistiche globali del sistema e altro ancora. Dunque, in conclusione, il SAT è uno strumento di analisi del sistema che riesce, a discapito di un piccolo overhead di sistema, penetrare nei meccanismi più interni del sistema operativo e trarre informazioni utili all azione di debug, come ad esempio il tempo di servizio di una system-call, l analisi della contesa delle risorse tra i vari task attivi (la cosiddetta race condition, che può portare il sistema ad uno stato di attesa indefinita), l osservazione dello scambio di messaggi tra i thread e i processi, ecc. Queste informazioni, non sono di norma facili da reperire, per cui è chiaro il grande contributo al monitor che questo tool riesce a dare. 23

24 2.3 QNX System Profiler Per QNX Neutrino, però, è stato sviluppato un ulteriore tool di analisi in tempo reale oltre a SAT, che costituisce la punta di diamante della suite Momentics: il System Profiler (SP). Come il tool precedente, anche il SP utilizza il kernel instrumentato nella raccolta di informazioni di sistema come le chiamate al kernel, le interruzioni, i context-switch e le variazioni alla coda di schedulazione. La forza di questo strumento sta nell unire i vantaggi del System Information (interfaccia user-friendly, vasta gamma di informazioni anche in tempo reale) a quelli del SAT (utilizzo del kernel instrumentato per ottenere informazioni che un semplice debugger come SI non potrebbe ottenere). Nella vista principale, denominata target navigator, è possibile selezionare la macchina target e dal menu contestuale selezionare la voce Kernel Event Tracing, per iniziare, per mezzo del modulo kernel dedicato, la fase di raccolta dati, i cui campi d interesse vengono selezionati grazie al wizard che accompagna l utente nella configurazione delle azioni di monitoring desiderate. Gli eventi che il kernel può intercettare sono molto numerosi, tanto da spingere gli sviluppatori di questo strumento a dividerli in macroclassi. Per ogni singolo evento, l utente può scegliere il livello di monitoraggio, infatti sono stati pensati ben 3 livelli di dettaglio di informazioni: None (monitoraggio disattivato), Fast (monitoraggio informativo, per una rapida segnalazione degli eventi, serve all utente per capire che un certo evento si è verificato, senza però fornirne i dettagli del contesto), Wide (monitoraggio completo, per un set di informazioni il più dettagliato possibile, orientato al debugging e alla ricerca di errori di sistema). Le informazioni raccolte dopo l avvio di questa procedura, vengono salvate in un file di estensione.kev, associato al programma Momentics stesso in fase di installazione della suite. Il log viene visualizzato ed analizzato tramite il SP editor, che fornisce dati, tempi di esecuzione, statistiche, grafici e proiezioni dei task analizzati. Una funzione sicuramente molto utile in fase di monitoraggio di sistema è la CPU Activity Presentation, che centra appieno l obiettivo di fornire una GUI tanto semplice, quanto potente dal punto di vista dei dati di analisi presentati, infatti mostra una timeline 24

25 segmentata dell esecuzione globale dei task schedulati, disponibile in forma lineare (come in figura 2.3), di unica barra divisa per colori, di grafico a torta o istogramma, sia in due che in tre dimensioni. Figura 2.3: CPU Activity Presentation Il SP è, per concludere, un insieme piuttosto vasto di funzioni dedite al monitoring, che vanno dalla ricerca dei richiedenti e degli utilizzatori delle strutture IPC, al calcolo tempi di esecuzione di ogni task, da moduli di ricerca avanzata per trovare in modo agevole un particolare evento in un log anche piuttosto complesso, fino ad una tabella delle proprietà e dello stato di ogni singolo thread di ogni task in tempo reale; questo potentissimo strumento col proseguire degli aggiornamenti delle suite Momentics migliora in maniera esponenziale, facilitando estremamente il compito dell utente che si riduce (nei casi più semplici) ad una semplice osservazione di una tabella. 25

26 Capitolo 3: Monitoring per VxWorks VxWorks è il RTOS commerciale più diffuso al mondo ed è sviluppato dalla compagnia software Wind River di Alameda, California. Esso è utilizzato per gestire in tempo reale molti tra i dispositivi hardware più complessi mai creati dall uomo, basta infatti pensare che, per portare un unico esempio, VxWorks è il RTOS utilizzato su Curiosity, il laboratorio spaziale inviato su Marte. È pertanto ritenuto, oltre che soddisfacente in termini prestazionali, anche estremamente sicuro e robusto a disturbi ed imprevisti che di certo sono presenti in un progetto da inviare su un altro pianeta. La sua introduzione sul mercato ha una storia meno lineare rispetto al concorrente QNX: nasce nei primi anni 80 come un set di migliorie per il già esistente sistema operativo VRTX di Ready Systems (di cui Wind River aveva acquisito i diritti di distribuzione), il quale, anche se era venduto come un RTOS, non riusciva a soddisfare nei suoi 4KB di kernel i requisiti che un sistema operativo in tempo reale deve avere; forniva cioè solamente un abbozzo di quello che sarebbero poi diventati i RTOS. Da questa mancanza nasce il nome VxWorks, che si pensa sia un acronimo per indicare il gioco di parole VrtX that WORKS, ovvero una rivisitazione di VRTX, ma che stavolta funzioni davvero. Rotti, in seguito, gli accordi commerciali tra Ready Systems e Wind River, la casa californiana decide di continuare a battere il sentiero già intrapreso, sviluppando di fatto un microkernel che avrebbe poi sostituito VRTX e vendendo un sistema operativo realtime comprensivo di microkernel e applicazioni di sistema e di sviluppo tutte prodotte da Wind River. 26

27 La grandezza di questo RTOS sta nell aver anticipato i suoi concorrenti nell offrire all utente finale delle funzionalità che altri sistemi operativi stavano ancora ricercando, infatti, ad esempio, VxWorks è stato il primo RTOS a introdurre il supporto real-time allo stack di rete ed implementare, nella loro versione in tempo reale, protocolli di comunicazione come CAN, Bluetooth e Firewire. Le funzionalità offerte, rimanendo in una descrizione introduttiva generale ad ampio raggio, lo rendono sicuramente un sistema molto completo, infatti per quanto riguarda lo scheduler, implementa un Round-Robin a 256 priorità fisse preemptive, per avere la giusta predicibilità dell invarianza di priorità e al tempo stesso la dinamicità della schedulazione RR; per quanto riguarda, invece, il kernel, esso divide i task in tre categorie fondamentali, riuscendo ad isolare i task RT, da quelli non RT e dalle routine di sistema; per quanto riguarda, infine, le strutture messe a disposizione per la comunicazione dei task (IPC), sono fornite tutte le tipologie di semafori, persino con il protocollo Priority Inheritance, di solito scartato nelle applicazioni real-time, data la sua complessità, inoltre ci sono anche code di messaggi, tra thread, tra task e anche tra sistemi operativi, poiché VxWorks offre il supporto alla virtualizzazione dell hardware, così da poter installare più sistemi operativi (anche non real-time) sulla stessa macchina. Essendo un sistema così diffuso ed utilizzato, negli ambiti più disparati, Wind River ha dovuto provvedere a fornire un corredo software al RTOS, per lo sviluppo e l analisi dei task attivi nel sistema. Come per la soluzione QNX già analizzata, anche Wind River ha optato per un IDE all-in-one, che permetta all utente di ricoprire il ruolo di sviluppatore, debugger e analizzatore di sistema in un unico programma, battezzato col nome di Tornado per VxWorks fino alla versione 5 e poi di Wind River Workbench a partire dalla versione 6. I tool di monitoraggio per VxWorks sono davvero tantissimi, quindi, a titolo esemplificativo, verranno adesso mostrati solo alcuni di essi, andando ad effettuare una analisi a campione tra tools dell odierna suite Workbench, altri della precedente piattaforma Tornado ed infine altri ancora che non sono sviluppati da Wind River, bensì da compagnie satellite, in partnership con la casa produttrice del RTOS. 27

28 I tools scelti CoverageScope e MemScope per Workbench, poi Spy e WindView di Tornado ed infine Tracealyzer sviluppato dalla software house Percepio (che ha sviluppato lo stesso tool anche per altri RTOS, come ad esempio RTLinux e FreeRTOS). 3.1 Monitoring per Workbench CoverageScope CoverageScope è uno strumento di analisi dinamica appartenente all ambiente Workbench, che permette al programmatore di verificare la copertura del codice nei casi di test previsti e sviluppati. Ciò che lo rende diverso da un semplice analizzatore ti copertura del codice è il suo orientamento al real-time: è infatti possibile gestire i dati forniti in uscita da CoverageScope in tempo reale, durante la stessa esecuzione del caso di test. Nella view principale viene mostrato il file oggetto analizzato con affianco un riepilogo (in forma percentuale) delle chiamate a funzioni, segnalazione di ingresso e uscita dai blocchi monitorati e hit-ratio per la condizione degli if. Dal menu contestuale si possono ricavare delle informazioni più dettagliate, avendo a disposizione una lista di tutte le funzioni e i blocchi presenti nell oggetto. È possibile inoltre controllare il codice a run-time, che sarà evidenziato per indicare un eventuale copertura degli statement. L unica operazione non possibile è la modifica run-time del codice, perché servirebbe una ricompilazione del sorgente. Per dare, infine, un ulteriore aiuto all interpretazione dei dati, queste statistiche sono visualizzabili anche in forma di istogramma o di trend-graph. Figura 3.1: CoverageScope 28

29 3.1.2 MemScope Il MemScope è uno strumento di analisi in tempo reale integrato nella suite Workbench per vedere l evoluzione della memoria centrale del sistema target e come essa viene utilizzata, alla ricerca di memory-leaks o di eccessiva occupazione della stessa. È abilitato di default nel simulatore di VxWorks, per cui in fase di testing delle applicazioni real-time, la configurazione dello strumento è totalmente trasparente all utente che dovrà solo selezionare il MemScope e utilizzarlo. Questo strumento fornisce una visione estremamente dettagliata della memoria, facendo riferimento anche al codice sorgente (se disponibile), infatti, in fase di running del task, MemScope riesce ad intercettare tutti gli eventi e le system-calls relative alla gestione della memoria, come ad esempio malloc, free, realloc, new e delete. Registrate per ogni thread del task tali informazioni, riesce a dare un quadro informativo completo sia nel generale che nel particolare dell utilizzo della memoria: presenta una tabella con il numero di allocazioni e de-allocazioni chiamate, il numero di byte allocati in area heap per il thread, quanti byte sono stati rilasciati ed infine un rapporto (espresso sottoforma di percentuale) della memoria rilasciata rispetto a quella richiesta. MemScope, però, non si limita ad analizzare nel complesso l utilizzo di memoria del task e dei relativi thread, infatti riesce a registrare anche il nome di ogni funzione chiamante, la sua posizione nel codice sorgente (sia file vero e proprio.c,.cpp, ecc, sia numero di linea), i byte richiesti dal blocco e se e quando essi sono stati rilasciati. In questo modo, a valle di funzionamenti non previsti, con un semplice doppio-click sulla linea del log che segna l allocazione indesiderata, l utente può risalire all esatta linea di codice che ha generato la situazione anomala e risolvere il problema. 3.2 Monitoring per Tornado Tornado è la piattaforma di analisi e sviluppo che è stata soppiantata da Wind River Workbench. La migrazione alla nuova piattaforma, ha obbligato Wind River ad un refactoring di tutti gli strumenti utilizzati da tornado per questioni di retro compatibilità, per 29

30 cui è bene ricordare che gli strumenti che saranno ora analizzati sono presenti come plugin nel Workbench, anche se i tool non sono esattamente gli stessi, ma degli adattamenti, che li rendono sicuramente meno performanti rispetto gli originali su Tornado WindView Il WindWiew è il tool su cui Wind River punta per l analisi dinamica del sistema target, infatti è anche quello più documentato, nonché quello più pubblicizzato ed esaltato dalla stessa casa americana, che nella nuova versione presente in Workbenh ha ribattezzato come System Viewer. Si tratta di un monitor a 360, utilizzato per monitorare i più svariati tipi di eventi in corso nel sistema. Consiste di due azioni fondamentali, nella prima parte tramite il tasto di start/stop si abilita/disabilita la raccolta di dati in un file di log. In questa fase, c è bisogno di scegliere quali eventi devono essere selezionati ed è un azione fortemente consigliata dalla documentazione stessa, in quanto la fitta varietà di eventi disponibili può creare confusione nel file di log. Eseguita la raccolta dei dati, in maniera totalmente offline può essere visualizzato e studiato il log, sempre per mezzo dello strumento WindView, che dà all utente la possibilità di analisi sia in forma grafica sia in forma testuale. La schermata presentata è molto intuitiva, in quanto è disegnata una linea in corrispondenza del task schedulato. Come detto, gli eventi sono molteplici e in ugual numero i simboli corrispondenti che vengono posizionati su tale grafico, la cui semantica viene specificata da una legenda ottenibile da una semplice scorciatoia nel menu. Se però la forma grafica fosse scomoda, o di difficile interpretazione (a causa dei molti task in esecuzione o dei troppi simboli visualizzati, ad esempio) è sempre possibile ottenere le stesse informazioni in forma tabellare, con delle entry in tabella contrassegnate dai timestamp, le quali indicheranno gli eventi corrispondenti a quale task afferiscono, il tempo di esecuzione e il contesto in cui eseguono. Lo strumento presenta anche un ottimo modulo di ricerca, che permette di trovare un particolare evento sia tra tutti i task sia relativamente ad un solo processo, contare le occorrenze dell evento considerato e, qualora possa essere di interessa, anche salvarlo e dare ad esso un nome per poterlo facilmente ritrovare nel seguito. 30