Middleware per il monitoraggio di flussi real-time Reti Di Calcolatori LS A.A. 2003/04 Alberto Mancini mat. 170363.

Presentazione sul tema: "Middleware per il monitoraggio di flussi real-time Reti Di Calcolatori LS A.A. 2003/04 Alberto Mancini mat. 170363."— Transcript della presentazione:

1 Middleware per il monitoraggio di flussi real-time Reti Di Calcolatori LS A.A. 2003/04 Alberto Mancini mat. 170363

2 2 Organizzazione presentazione 1 - Introduzione 2 - Modello concettuale 3 - Qualità di servizio 4 - Implementazione 5 - Conclusioni Panoramica del problema esaminato con specifica degli obiettivi da conseguire Architettura sistema Infrastruttura di comunicazione Protocolli di comunicazione Trasferimento del software su scheda Verifica delle risorse locali Adattamento dinamico della risoluzione di visualizzazione Simulazione della scheda Stazioni di monitoraggio Componenti realizzati Considerazioni finali sul lavoro e possibili estensioni future

3 3 Descrizione del problema Il progetto consiste nella realizzazione di un middleware distribuito per il monitoraggio di flussi di dati real-time derivanti da dispositivi hardware, tipicamente adibiti al controllo di processi industriali. 1 - Introduzione Bus di campo Ethernet Livello supervisione HS55-DSP-C6713Livello automazione Livello del campo

4 4 Obiettivi 1 - Introduzione Trasparenza rispetto allhardware sorgente del flusso di dati real-time Efficienza del meccanismo di monitoraggio Qualità di servizio Avendo delle garanzie temporali locali sul nodo sorgente, comunque verificate dai moduli che si occupano della qualità di servizio, è possibile estrarre un flusso real-time da un flusso asincrono. Flusso asincrono contenente dati real-time Minimo overhead del protocollo di monitoraggio Trasferimento di datagrammi UDP Correttezza del trasferimento del software Verifica delle risorse locali Adattamento dinamico della risoluzione di visualizzazione Logging del sistema

5 5 Architettura sistema Larchitettura del middleware è organizzata secondo i seguenti livelli: 2 - Modello concettuale SCHEDA HARDWARE SERVIZI APPLICATIVI COMUNICAZIONE canale flusso dati MONITORSTORAGE MANAGEMENT GESTIONE FLUSSO REAL-TIME TRASPORTO RETE DATA LINK FISICO GESTIONE CANALI Scheda HS55-DSP-C6713 Storage Manager Configurator Archive Monitor Le diverse entità saranno distribuite sui nodi seguendo lo schema:

6 6 Servizi del middleware 2 - Modello concettuale Trasferimento del software su scheda Configurazione Monitoraggio dei dati operativi Trasferimento del sistema operativo e del programma operativo sulla scheda HS55-DSP-C6713, prelevandolo dallarchivio. Specifica delle grandezze da monitorare e/o rendere persistenti, con conseguente definizione della struttura del datagramma di base del flusso di monitoraggio. Visualizzazione e/o memorizzazione dei dati operativi di interesse su uno o più nodi realizzando di fatto degli oscilloscopi virtuali con persistenza dei dati.

7 7 Logica di funzionamento La logica di funzionamento delle stazioni di monitoraggio (visualizzazione o memorizzazione) e della scheda può essere descritta attraverso semplici automi a stati finiti; lo stesso discorso vale per il componente di management, che si dovrà occupare di: 2 - Modello concettuale Gestire la registrazione dei nodi Trasferire il software sulla scheda Gestire la configurazione della scheda e dei nodi di monitoraggio Nella fase di registrazione, oltre a segnalare al manager la propria presenza, la stazione invia anche lelenco delle variabili che ha intenzione di monitorare. Visualizza automa scheda Visualizza automa stazione di monitoraggio Visualizza automa manager INITSOFTWAREOKREGISTERED CONFIGUREDREADYRUNNING ATTESA REGISTRAZIONE ATTESA SOFTWARE ATTESA RICHIESTA CONFIGURAZIONE NODO REGISTRATO SOFTWARE CARICATO AVVIO MANUALE ARRESTO MANUALE ATTESA ARRESTO ATTESA AVVIO STAZIONI CONFIGURATE RICHIESTA CONFIGURAZIONE ATTESA CONFIGURAZIONE STAZIONI Automa scheda INITCONFIGUREDREGISTERED ATTESA REGISTRAZIONE ATTESA CONFIGURAZIONE NODO REGISTRATO RICEZIONE CONFIGURAZIONE Automa stazione di monitoraggio MCFACTIVEINIT SOFTWAREOKCONFIGURED ATTESA REGISTRAZIONE SCHEDA ATTESA RICHIESTA TRASFERIMENTO SOFTWARE SCHEDA REGISTRATA CONFIGURAZIONE TERMINATA SOFTWARE TRASFERITO CORRETTAMENTE ATTESA RICHIESTA CONFIGURAZIONE Automa manager

8 8 NOTIFICA ERRORI MON. VITALITA CONFIGURAZIONE REGISTRAZIONE NOTIFICA ERRORI CONFIGURAZIONE Infrastruttura di comunicazione (1/2) Dato lelevato numero di interazioni (non critiche dal punto di vista delle prestazioni) necessarie prima della fase di monitoraggio del flusso real-time, si è deciso di realizzare molteplici canali di comunicazione ad-hoc: 2 - Modello concettuale Manager Stazioni di Monitoraggio Archive REGISTRAZIONE Scheda In realtà questo canale viene implicitamente fornito dal linguaggio (file system remoto)

9 9 Infrastruttura di comunicazione (2/2) Sarà richiesto il trasferimento di datagrammi UDP con le relative implicazioni: 2 - Modello concettuale La fase di monitoraggio sfrutta la tecnica del multicast, in modo che uno stesso dato possa essere ricevuto (ed utilizzato) da tutti i nodi in ascolto: Possibile perdita di datagrammi Il problema dellordinamento dovrà invece essere risolto prevedendo un apposito modulo di riordino, che si avvalga di un certo numero di buffer opportunamente dimensionati. Non garantito il mantenimento dellordine di invio dei datagrammi Il problema della perdita di datagrammi potrà essere unicamente risolto introducendo ridondanza. Se ciò non fosse possibile, dato che per il target applicativo è impensabile richiedere una ritrasmissione (la scheda probabilmente non dispone più dei dati mancanti), andrà semplicemente notificata la mancanza di un certo intervallo di dati. Stazione di Monitoraggio Scheda CANALE Stazione di Monitoraggio

10 10 Protocolli di comunicazione (1/3) Sia la scheda che le stazioni di monitoraggio utilizzano lo stesso protocollo di registrazione caratterizzato da una semplice comunicazione: 2 - Modello concettuale Manager reqReg MCF5272 Monitor / Storage respReg reqReg:name;type;hostIP;configPort;alivePort;variables respReg:multicastAddress;receiveAlivePort;remoteErrorPort name type hostIP configPort alivePort Nome del nodo Tipo del nodo (MCF5272, Monitor, Station) Indirizzo IP del nodo Porta su cui il nodo attende il messaggio di configurazione Porta da cui verrà inviato il messaggio di vitalità variablesElenco delle variabili di interesse, separate da virgole Notare che la scheda non prevede il parametro alivePort in quanto, per ragioni di efficienza, non invia al Manager il messaggio di vitalità. Anche il campo variables sarà vuoto multicastAddress receiveAlivePort remoteErrorPort Indirizzo multicast (classe D) utilizzato per linvio dei dati da monitorare Porta su cui ricevere i messaggi di vitalità Porta su cui ricevere messaggi di errore Nota: Tutti i nodi di monitoraggio e la scheda dovranno avere solo la conoscenza dellindirizzo IP del manager e della porta di registrazione.

11 11 Protocolli di comunicazione (2/3) 2 - Modello concettuale CONFIGURATION;variables name,offset,length,period varSpec; … variables Elenco delle variabili di cui richiedere la configurazione reqConf name offset Nome della variabile Offset di inizio dei dati relativi alla variabile respConf length period Lunghezza dei dati relativi alla variabile Periodo di campionamento della variabile result nodeAck resultOK se le risorse locali sono sufficienti al trattamento dei dati, altrimenti NO READY manAck Notifica alla scheda che la configurazione dei nodi di monitoraggio è terminata Manager nodeAck Monitor Storage respConf Scheda reqConf respConf manAck Protocollo di configurazione 1.Il Manager richiede alla scheda i dati di configurazione di tutte le variabili di interesse 2.La scheda invia i dati richiesti al Manager 3.Il Manager invia i dati ricevuti a tutti i nodi che erano attivi allistante in cui è stata richiesta la configurazione, attendendo una conferma di ricezione 4.Il Manager notifica alla scheda lavvenuta configurazione dei nodi in modo che questa transiti in stato READY ed abiliti il comando di avvio

12 12 Protocolli di comunicazione (3/3) Come già accennato precedentemente, tale protocollo prevede il solo trasferimento di dati dalla scheda a tutti i nodi di monitoraggio in ascolto. Per realizzare una comunicazione uno a molti, si utilizza un multicast, cioè la scheda invia i datagrammi verso un indirizzo di classe D (range da 224.0.0.0 a 239.255.255.255 incluso), in modo che tutti i nodi preventivamente registrati li possano ricevere. 2 - Modello concettuale Scheda dataPacket Monitor Storage PROG_NUM DATA Numero progressivo che individua lultimo valore valido trasmesso Dati (float a 32 bit) relativi alla variabile. Notare che la lunghezza del campo è pari a quella del buffer circolare definito sulla scheda dataPacket : PROG_NUM varData … DATA

13 13 Gestione del flusso di dati Ciascuna stazione, attraverso un modulo di gestione del flusso, dovrà estrarre i dati di interesse ricostruendo lordine corretto degli stessi, eventualmente gestendo opportunamente omissioni o ritardi inaccettabili di datagrammi. 2 - Modello concettuale RETE pacchetto sottopacchetto ESTRAZIONE SOTTOPACCHETTI RIORDINO E GESTIONE OMISSIONI FLUSSI ORDINATI Tutto il meccanismo di gestione si basa sul progressivo (assoluto) associato a ciascun sottopacchetto di dati, assieme alla presenza di un certo numero di buffer di riordino per ciascuna variabile di interesse.

14 14 Trasferimento del software su scheda La fase di trasferimento del software sulla scheda, o meglio nelle memorie RAM dei processori, è particolarmente critica in quanto preclude l'operatività dell'intero sistema (hardware e, di conseguenza, software). 3 – Qualità di servizio Scheda Manager Archive RAM Il canale TCP garantisce il mantenimento dellordine dei pacchetti inviati. CANALE VIRTUALE TCP TRASFERIMENTO VERIFICA Date le scarse risorse del dispositivo fisico sulla scheda che si occupa della gestione della comunicazione ethernet, la verifica consiste nella ritrasmissione al manager del contenuto della memoria. In tal modo è possibile rilevare anche eventuali malfunzionamenti nelle fasi di scrittura/lettura della memoria.

15 15 Verifica risorse locali (1/2) 3 – Qualità di servizio Fino a quando il software non è stato trasferito sulla scheda, le specifiche delle variabili (dimensione buffer circolari, periodi di campionamento) non sono note; quindi a priori non è possibile sapere se le risorse locali delle singole stazioni di monitoraggio siano sufficienti per osservare le variabili di interesse. La verifica delle risorse locali può essere eseguita solo dopo la ricezione delle configurazioni da parte delle stazioni; questa consisterà in una simulazione locale per verificare se le risorse disponibili siano o meno adeguate. 3 - specVars 2 - specVars 1 - Richiesta configurazione Manager Stazione Scheda Stazione.. - specVars

16 16 Verifica risorse locali (2/2) 3 – Qualità di servizio La verifica delle risorse locali viene eseguita su tutti i nodi di monitoraggio e sulla scheda; in ciascuna simulazione, della durata di circa 3 secondi, viene anche calcolato approssimativamente il carico del nodo: Stazione di visualizzazione (Monitor) Stazione di memorizzazione (Storage) Simulazione scheda (MCF5272) 1.Rilevamento render rate 2.Impostazione automatica del fattore di ris. per visualizzare tutti i dati. 1.Rilevamento transfer rate 2.Impostazione automatica del fattore di ris. per memorizzare tutti i dati. 1.Simulazione delle capacità di trasmissione Un transfer rate troppo elevato (non sostenibile) deriva da richieste di monitoraggio di troppe variabili o da periodi di campionamento bassi.

17 17 Adattamento dinamico della risoluzione Dato che lutilizzo principale del middleware è quello di realizzare applicazioni mirate allosservazione di variabili attraverso loscilloscopio virtuale fornito dalle stazioni di visualizzazione, si è deciso di prevedere un adattamento dinamico del fattore di risoluzione che automaticamente intervenga nel momento in cui le risorse locali non fossero più sufficienti alla visualizzazione. 3 – Qualità di servizio Per quanto riguarda leventuale aumento del fattore di risoluzione, volendo introdurre un overhead minimo (principio di minima intrusione), si è adottato un semplice algoritmo che, se necessario, tenta un aumento della risoluzione di visualizzazione dopo aver ricevuto correttamente un certo numero di dati. Se laumento di risoluzione attuato è sostenibile, non succede nulla, altrimenti si avrà una diminuzione della stessa riportandosi al caso precedente al tentativo. Variato automaticamente durante il funzionamento

18 18 Logging del sistema Per un sistema complesso (nel caso distribuito), è buona norma prevedere il salvataggio (logging) di tutti gli eventi di particolare interesse (messaggi ed errori), al fine di poter verificare a posteriori il corretto funzionamento o le cause di eventuali errori. 3 – Qualità di servizio Dato che lelemento di management di tutto il sistema è il Manager, sarà proprio questo componente ad occuparsi del logging degli eventi di interesse. Questa scelta è anche motivata dal fatto che, durante losservazione delle variabili, il Manager non deve fare nulla di particolare, se non verificare la vitalità delle stazioni di monitoraggio. Affinché sia possibile la memorizzazione di tutti gli errori che avvengono allinterno dellintero sistema, è necessario che tutti i nodi partecipanti, oltre a visualizzarli localmente, li reindirizzino verso il Manager utilizzando il canale di comunicazione preposto.

19 19 Simulazione della scheda In memoria comune sono presenti i dati operativi di interesse così organizzati: 4 - Implementazione NUM PROG BUFFER 32 bit variabile 1 NUM PROG BUFFER 32 bit variabile 2 … NUM_PROG conterrà il numero progressivo (intero a 32 bit) del valore più aggiornato. 1.Scrittura del nuovo valore della variabile nella cella OFFSET(NUM_PROG+1) 2.Incremento di NUM_PROG Il Coldfire (MCF5272) eseguirà degli invii asincroni del contenuto dei buffer; la garanzia di consistenza dei dati la si ha adottando il seguente protocollo: Molto sommariamente, larchitettura della scheda è la seguente: MEM. LOCALE MCF5272 Coldfire C6713 F2407A MEM. LOCALE MEMORIA COMUNE FPGA EP1C6 Supervisione scheda (interfaccia ethernet) Algoritmi di controllo Interfaccia con il campo

20 20 Stazioni di monitoraggio La stazione di monitoraggio è unastrazione che racchiude in se tutti i meccanismi che consentono la registrazione, configurazione e gestione del flusso di un nodo di visualizzazione o memorizzazione. Architetturalmente, il componente è stato così realizzato: 4 - Implementazione Sinteticamente, le macrofasi operative sono le seguenti: Registrazione della stazione Implementativamente, ogni macrofase viene gestita da un apposito thread. Configurazione della stazione Ricezione del flusso di dati

21 21 Componenti realizzati Di seguito è riportato lelenco dei principali componenti che costituiscono il middleware; per ciascuno di essi è visualizzabile linterfaccia grafica associata e larchitettura logica che ne definisce la struttura statica: 4 - Implementazione Interfaccia grafica Simulazione della scheda Architettura logica Interfaccia grafica Componente di management Architettura logica Interfaccia grafica Stazione di visualizzazione Architettura logica Interfaccia grafica Stazione di memorizzazione Architettura logica Interfaccia Grafica Architettura Logica Interfaccia Grafica Architettura Logica Interfaccia Grafica Architettura Logica Interfaccia Grafica Architettura Logica

22 22 Estensioni future 5 - Conclusioni Indicazione dei valori massimi e minimi delle forme donda Impostazione di soglie di sicurezza con notifica del loro superamento Possibilità di variare le dimensioni dello schermo di visualizzazione (oscilloscopio virtuale), introducendo anche strumenti di analisi quali: Analisi frequenziale semplificata (FFT) che, individuando larmonica fondamentale della forma donda, ottenga laggancio di fase automatico, con conseguente impostazione della scala dei tempi ottimale. Analizzatore di spettro del flusso di dati; dato lelevato carico computazionale, è realistica una implementazione che operi off-line su dati precedentemente memorizzati. Virtualizzazione del sistema rispetto allinfrastruttura di comunicazione, cioè riorganizzazione modulare dei livelli di comunicazione al fine di prevedere supporti fisici diversi (porte seriali, parallele, USB, proprietarie). A tal scopo si rende necessario lutilizzo di JNI (Java Native Interface).

23 23 Conclusioni In conclusione, per quanto il middleware sia completamente funzionante, sarà realmente utilizzabile solamente nel momento in cui sia disponibile il sistema operativo sulla scheda che implementi i protocolli attualmente simulati dal componente software MCF5272. 5 - Conclusioni Si tratterà quindi solo di attendere che io mi laurei, dato che lo sviluppo del suddetto sistema operativo è il tema della mia tesi…