Studio delle soluzioni esistenti per il monitoraggio di sistemi real-time

Transcript

1 Scuola Politecnica e delle Scienze di Base Corso di Laurea in Ingegneria Informatica Elaborato finale in Sistemi Real Time Studio delle soluzioni esistenti per il monitoraggio Anno Accademico 2013 / 2014 Candidato: Andrea Caruso matr. N46 / 597

2

3 Indice Introduzione 4 Capitolo 1: Monitors - Panoramica generale..7 Capitolo 2: Runtime Monitoring Taxonomy Specification Language Monitor Event-Handler Operational Issues..17 Capitolo 3: Esempio - WDog Presentazione del progetto Analisi tassonomica Codice ed esempio di funzionamento.. 24 Conclusione Bibliografia.29

4 Introduzione L affidabilità di un sistema informatico viene fondata sulla qualità del sistema operativo che ne governa il funzionamento e garantisce l operatività di base di un calcolatore, coordinando e gestendo le risorse hardware di processing e memorizzazione, le periferiche, i processi e facendo da interfaccia con l utente. E dunque un componente essenziale del sistema di elaborazione che funge da intermediario tra l utente e la macchina ed è inoltre una base di appoggio per altri applicativi software, che dovranno quindi essere progettati e realizzati in modo da essere riconosciuti e supportati da quel particolare sistema operativo. Le diverse necessità in ambito industriale, commerciale, militare, medico, etc hanno portato alla realizzazione di differenti sistemi operativi, ognuno dei quali progettato e realizzato con degli obiettivi ben precisi, in grado di operare in particolari condizioni e garantire affidabilità e robustezza sotto vincoli di diversa natura 4

5 necessari al corretto funzionamento del sistema informatico. I Sistemi Operativi real-time nascono dall esigenza di rispettare determinati vincoli temporali (deadlines), violati i quali l intero sistema, o parte di esso, potrebbe non funzionare in maniera corretta o addirittura collassare causando problemi di differenti gravità. Diversamente dai Sistemi Operativi time sharing, nei quali i vari processi si contendono le risorse hardware, senza un ben preciso ordine, con lo scopo di offrire un esperienza all utente quanto più soddisfacente possibile in qualità di tempi di risposta, nei SO real-time, il cui obiettivo non è più la qualità dei tempi di risposta bensì garantire il rispetto delle deadlines, è possibile gerarchizzare i processi utilizzando dei particolari algoritmi di scheduling, i quali, in maniera del tutto automatica, assegnano dei gradi di priorità operativa in modo da garantire l esecuzione di ognuno di questi, rispettando le relative deadlines. I SO real-time sono generalmente classificati come soft real-time systems o hard real-time systems. Nei soft real-time systems non rispettare una deadline può causare un degrado delle prestazioni come ad esempio la perdita di un frame nella riproduzione di un video, il quale, per quanto segno di inefficienza e cattiva qualità, non è causa danni irreparabili. Nei hard real-time systems le deadlines non devono assolutamente essere violate in quanto potrebbero esserci conseguenze 5

6 anche catastrofiche: per esempio, lo sfondamento di una deadline in un sistema embedded di un automobile potrebbe causare la rottura del motore e quindi, successivamente, danni ben più gravi al conducente. In entrambi i sistemi, soft e hard, le deadlines devono essere rispettate anche in quello che viene chiamato worst-case ossia il caso peggiore di funzionamento. L estrema sensibilità alle deadlines e le potenziali conseguenze catastrofiche, hanno portato alla necessità di supporti software, detti monitors, dediti al monitoraggio continuo di questi sistemi real-time, grazie ai quali è possibile tenere sotto controllo l intera operatività e prevenire il verificarsi di danni irreparabili. 6

7 Capitolo 1: Monitors - Panoramica generale Il monitoraggio di software runtime viene utilizzato anche per diversi scopi come ad esempio l analisi delle prestazioni e l ottimizzazione del software stesso oltre che per la software faultdetection, la diagnosi e la recovery. La software fault-detection monitora costantemente l esecuzione del software assicurandosi che il comportamento di questo sia conforme alle caratteristiche previste. Mentre altre tecniche di verifica come il testing si occupano di assicurare l effettiva correttezza di un software, l intento del monitoraggio di fallimenti software in runtime è di determinare se la corrente esecuzione di questo preservi specifiche caratteristiche. chiave: In accordo con l uso comune [1], definiamo alcuni termini 7

8 Fallimento software ( software failure ): è la deviazione del comportamento osservato rispetto a quello richiesto del sistema software Errore ( error ): è una particolare condizione anomala dello stato del sistema che è responsabile di un possibile fallimento software. E il risultato di un guasto. Guasto ( fault ): avviene durante l esecuzione del software ed è il risultato di uno stato inaspettato del sistema che può causare un errore. Molti tools sono stati proposti per il monitoraggio runtime con lo scopo di identificare, diagnosticare e riparare guasti software. Lo studio più recente nel campo del runtime software monitoring è stato pubblicato nel 1981 da Plattner e Nievergelt [2], nel quale sono stati esaminati i concetti, gli obiettivi e le limitazioni di questi monitors. E possibile trovare diverse definizioni di runtime software-fault monitor, nel nostro caso la più adeguata è: Un monitor è un sistema che osserva il comportamento di un sistema e determina se è coerente con le specifiche date [3]. Esistono anche monitor più articolati di un comune 8

9 fault-detection monitor, i quali estendono la capacità di diagnosticare guasti, fornire informazioni più utili e dettagliate all utente e assisterlo durante la fase di system recovery portando il sistema o in uno stato stabile ( forward recovery ) o riportandolo indietro in uno stato già stabile in precedenza ( backward recovery ) [4]. La caratteristica software di cui monitorare il comportamento ha spesso la forma α " β dove α è una certa condizione la quale, una volta verificata, identifica lo stato in cui β deve essere a sua volta verificata. Tuttavia è possibile che il processo monitorato non contenga tutte le informazioni per valutare il corretto verificarsi di β successivamente ad α. Supponiamo per esempio di dover controllare che il numero di parentesi chiuse non sia mai maggiore al numero di parentesi aperte all interno di un flusso di caratteri in ingresso ad un processo di valutazione di una espressione matematica. In questo caso il vincolo potrebbe essere specificato T ( Nright Nleft ) dove Nright e Nleft sono i contatori del numero di parentesi aperte e chiuse. Il processo potrebbe non essere in possesso di queste due variabili e quindi non permettere al monitor di controllare il flusso di ingresso sotto queste condizioni se non andando a controllare tutti gli stati precedenti. Soluzione decisamente poco pratica. 9

10 Come mostrato in Fig. 1, un monitor è composto da due parti: un observer che si occupa di controllare il verificarsi della condizione α e un analyzer che controlla la condizione β. Supponiamo, per esempio, un programma che non deve mai permettere a due processi di accedere simultaneamente ad una regione critica. Questa caratteristica può essere specificata per un monitor come quando un processo entra nella regione critica deve essere assolutamente l unico. L observer controlla lo stato del programma per determinare se un processo è entrato nella zona critica. Una volta rilevato questo evento, l analyzer verifica che il processo sia unico. Se viene rilevata una violazione, il sistema di monitoraggio reagisce in funzione del tipo di violazione. La reazione può richiedere al sistema di iniziare un azione del tipo: arrestare il programma, avviare una routine di recovery, o inviare informazioni al log di sistema. L event-handler è il meccanismo che cattura e comunica al sistema o all utente i risultati dell apparato di monitoraggio e può o meno reagire in maniera automatica alla violazione. 10

11 Università degli studi di Napoli Federico II Fig. 1. High-level view of a runtime monitor. 11

12 Capitolo 2: Runtime Monitoring taxonomy La Fig.2 mostra una tassonomia generale [5] dei sistemi di monitoraggio per la fault detection. Andiamo ora ad analizzare ramo per ramo tutte le classificazioni. 2.1 Specification Language Il ramo Specification-Language nella tassonomia dei sistemi di monitoraggio si divide a sua volta in: Language type, Abstraction level, Property tipe e Monitoring Directives. Language type. Si riferisce al tipo di linguaggio utilizzato per definire le caratteristiche che devono essere monitorate, il quale può ad esempio, basarsi sull algebra, sulla logica o su un linguaggio objectoriented. 12

13 Fig. 2. Runtime Monitoring Taxonomy. 13

14 Abstraction level. Si riferisce al supporto che il linguaggio fornisce per specificare le proprietà relative al dominio, al progetto o all implementazione. Ad esempio un linguaggio domain-based fornisce costrutti di supporto per un determinato dominio in cui è coinvolto il monitor (servizi web) diversamente da un linguaggio implementationbased il quale fornisce costrutti per la definizione di proprietà a livello di implementazione come la definizione di una variabile o di un array. Property type. Ci sono due tipi di proprietà: quelle che definiscono una certa sequenza di eventi o il semplice controllo su una variabile (safety properties) [6] e quelle che definiscono delle caratteristiche temporali: l evento A deve manifestarsi prima dell evento B. Monitoring directives. Una proprietà che deve essere monitorata può essere valutata su livelli differenti ossia program ( in relazione tra più threads ), module ( funzioni, procedure, metodi ), statement e event ( sequenze o cambiamento di stati ). 14

15 2.2 Monitor Ci sono numerosi approcci per l implementazione di un monitor. Le caratteristiche riassunte nella tassonomia in Fig. 2 sono: Monitoring points, placement, platform e implementation. Monitoring points. I punti del programma in cui il codice del monitoraggio viene eseguito vengono detti monitoring points e questi possono essere manuali, ossia scelti dall utente in fase di progettazione, o determinati automaticamente da particolari tools. Placement. Si riferisce a dove viene eseguito il codice di monitoraggio. Esso può essere inline ossia presente direttamente nel codice del programma monitorato e quindi utilizzare le risorse di questo, oppure può essere offline ossia presente su un thread o su un processo a parte, e qualche volta addirittura su una macchina diversa. A seconda se l applicazione deve attendere o meno il controllo da parte dell analyzer per poter continuare la propria esecuzione, viene detto offline asincrono o offline sincrono. Platform. I monitor sono comunemente differenziati per software monitor e hardware monitor [7]. Mentre i software monitors utilizzano il codice per osservare ed analizzare il comportamento del sistema monitorato, un hardware monitors può ad esempio essere un 15

16 microprocessore collegato con particolari connettori al bus del sistema monitorato in modo da poter rilevare eventi di interesse e dati necessari al corretto monitoraggio [7]. Implementation. Ci sono tre modi diversi in cui un monitor può eseguire la sua funzione: in single process ossia monitor e programma monitorato vengono eseguiti dallo stesso processo; multiprogramming in cui il monitor e il programma target eseguono su due processi ( o threads ) separati; il multiprocessor in cui vengono addirittura eseguiti su due processori diversi. 2.3 Event-Handler Un monitor può reagire alla violazione di una specifica in un particolare stato. L event-handler nella tassonomia in Fig. 2 classifica i monitor in funzione di come questo reagisce. Control level. E una classificazione che separa i monitors che possono solo reagire in maniera universale ad una violazione, da quelli che permettono all utente di specificare l azione che l event-handler deve intraprendere al verificarsi della violazione stessa. I tools vengono quindi classificati come universal application o individual application. 16

17 Response effect. Questa categoria classifica i monitor in base a come l esecuzione del programma possa risentire o meno dell azione intrapresa dopo aver registrato una violazione. Distinguiamo tre casi: no effect ossia il comportamento del programma non viene alterato; user control in cui possiamo trovare per esempio dei breakpoints che richiedono l interazione dell utente; automated systems i quali alterano completamente l esecuzione corretta del programma per ovviare in maniera automatica alla violazione rilevata. 2.4 Operational Issues Nella scelta di un monitor ci sono una serie di considerazioni da fare. Alcune tra queste tengono conto di aspetti esterni al monitor stesso, come ad esempio l ambiente in cui il monitor viene coinvolto. Source Program Type. Descrive il tipo di programma a cui il monitor è applicato. Può essere General-purpose, ossia scritto in un linguaggio di programmazione general-purpose adattabile a qualsiasi tipo di dominio; domain-specific il quale indica che il monitor è stato progettato e realizzato per un tipo specifico di ambientazione e quindi contiene regole specifiche per il dominio a cui viene applicato,; 17

18 category-specific il quale classifica il monitor in base al tipo di sistema monitorato, ad esempio real-time o distribuito. Dependencies. Alcuni monitor possono lavorare solo sotto determinate condizioni definite come dipendenze, che possono ad esempio, richiedere un particolare supporto hardware, un sistema operativo specifico o addirittura che il programma target sia scritto in un determinato linguaggio di programmazione. 18

19 Capitolo 3: Esempio - Wdog Andiamo adesso a studiare ed a realizzare un esempio di sistema di monitoraggio applicato ad un impianto industriale simulato da un software, classificandolo secondo la tassonomia presentata nel capitolo 2. Il progetto è stato realizzato per eseguire sul sistema operativo Linux RTAI [8]. 3.1 Presentazione del progetto Un impianto industriale lavora correttamente ad una certa temperatura operativa. Per assicurare il corretto funzionamento di questo, un sistema di controllo si occupa di raffreddare o riscaldare l impianto, affidandosi alle rilevazioni effettuate da un sistema di acquisizione. Un addetto alla sicurezza può tranquillamente osservare il corretto funzionamento del sistema di controllo tramite importanti dati elaborati e mostrati a video da un sistema di monitoraggio. Quest ultimo 19

20 oltre ad interfacciarsi con l utente, verifica costantemente che il sistema di acquisizione non sia soggetto a guasti, eseguendo specifiche azioni di prevenzione in caso di malfunzionamenti. Fig. 3. Schema di funzionamento. Come mostrato in Fig. 3, ci sono 4 punti chiave nel progetto: l impianto con i relativi sensori e attuatori, grazie ai quali è possibile interagire con esso; il sistema di acquisizione, il quale attraverso i sensori acquisisce dati dall impianto; il sistema di controllo che in 20

21 funzioni dei dati ricevuti agisce sugli attuatori dell impianto; infine il sistema di monitoraggio. Acquisizione. Il Task Acquire preleva con un periodo T/N i dati relativi alla temperatura attuale dell impianto dai sensori e li deposita in un buffer condiviso con il task Filter il quale preleva gli N campioni e calcola la temperatura media comunicandola al sistema di controllo. Controllo. Il task Control riceve la temperatura media dell impianto nel periodo T, la confronta con la temperatura di riferimento e in funzione di questa fornisce il comando di aumentare o diminuire la temperatura di un grado al task actuator il quale agisce sugli attuatori. Monitoraggio. Agisce su due punti fondamentali: il task collect colleziona i dati relativi alla temperatura ricevuti dal sistema di controllo e li fornisce su schermo ad un utente addetto alla sicurezza; il task wdog si assicura che il sistema di acquisizione non sia guasto e che rispetti le deadline di funzionamento, ricevendo in loop da questo un valore hbt entro 10 secondi da ciclo del task acquire. Come emerge dalla descrizione del progetto, il sistema di monitoraggio svolge un compito essenziale all interno dell impianto. 21

22 Senza di esso non sarebbe possibile prevenire o rimediare in tempo a possibili malfunzionamenti di alcune importanti funzioni di questo. 3.3 Analisi tassonomica Andiamo quindi a realizzare un monitor con le seguenti caratteristiche riferendoci alla tassonomia presentata nel capitolo 2. Come primo ramo nella tassonomia abbiamo specification language. Realizziamo il monitor utilizzando il linguaggio di programmazione C assieme al software di simulazione dell impianto rendendolo di tipo implementation-based in quanto realizzato e implementato con il software target e quindi dipendente dai suoi costrutti specifici. Il monitor in questione agisce su due livelli: program e module in quanto verifica la corretta comunicazione tra i diversi threads e che, specifiche funzioni dei diversi task, non siano soggette a malfunzionamenti. Per quanto riguarda il ramo Monitor scegliamo i monitoring points manualmente in fase di progettazione e facciamo si che il 22

23 monitoraggio avvenga sia inline in quanto implementato direttamente nel codice dell impianto, sia offline asincrono in quanto monitora i valori della temperatura in un thread separato e asincrono dal software target. Vogliamo quindi realizzare un software monitor implementato in multiprogramming. In Event-Handler possiamo dire che si tratta di un monitor individual application in quanto viene realizzato in maniera specifica per il software target che ne fa uso, e che è di tipo no effect poiché non può reagire in maniera automatica ad una violazione ma si occupa semplicemente di comunicare all utente il malfunzionamento, senza interferire con l esecuzione del software. Per quanto riguarda l ultimo ramo della tassonomia possiamo dire che il monitor in questione è di tipo domain-specific e categoryspecific in quanto viene realizzato in maniera specifica per monitorare l impianto ed esclusivamente su un sistema-real time dipendendo quindi sia dal sistema operativo sia dal linguaggio di programmazione utilizzato dal software target. 23

24 3.2 Codice ed esempio di funzionamento Il programma è strutturato in 5 file: parameters.h che contiene alcuni parametri fondamentali in uso tra i diversi threads, controller.c, plant.c e reference.c che contengono il codice dell intero impianto compreso il monitoraggio del sistema di acquisizione, e monitor.c che contiene il codice del processo che fornisce i dati relativi all andamento dell impianto all utente. Fig. 4. Distribuzione del codice sorgente 24

25 In Fig.5 è riportato il codice del task wdog il quale monitora il corretto funzionamento del sistema di acquisizione. Fig. 5. Codice del task WDog. 25

26 Fig. 6. Esempio di esecuzione corretta. 26

27 Fig. 7. Esempio di malfunzionamento del task acquire. 27

28 Conclusioni Il monitor ricopre oramai un ruolo fondamentale in quasi tutti i settori che fanno uso di sistemi informatici. Ad oggi esistono innumerevoli tools dediti al monitoraggio continuo del software, adattabili a qualsiasi tipo di sistema e per qualsiasi tipo di condizione, come ad esempio, il monitoraggio di sistemi hard real-time, di sistemi distribuiti, monitoraggio online etc. La ricerca e l innovazione per questi monitor è in continua evoluzione per potersi adattare a sistemi software che anno dopo anno diventano sempre più pesanti e complessi. 28

29 Bibliografia [1] A. Avizienis and J. Laprie, Dependable Computing: From Concepts to Design Diversity, Proc. IEEE, vol. 74, no. 5, pp , May [2] B. Plattner and J. Nievergelt, Monitoring Program Execution: A Survey, Computer, vol. 14, pp , [3] D. Peters, Automated Testing of Real-Time Systems, technical report, Memorial Univ. of Newfoundland, Nov [4] M. Barbacci, Quality Attributes, Technical Report CMU/SEI- 95-TR-021, Software Eng. Inst., Carnegie Mellon Univ., Dec [5] N. Delgrado, A. Q. Gates and S. Roach, A Taxonomy and Catalog of Runtime Software-Fault Monitoring Tools proc. IEEE vol. 30, no. 12, Dec 2004 [6] B. Berard and M. Bidoit, Systems and Software Verification: Model- Checking Techniques and Tools. Springer Verlag, [7] J. Tsai, Y. Bi, S. Yang, and R. Smith, Distributed Real-Time Systems: Monitoring, Visualization, Debugging and Analysis. John Wiley and Sons, [8] RTAI - the RealTime Application Interface for Linux 29