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

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

May 02, 2015

Download

Documents

Thorello Pesce
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Middleware per il monitoraggio di flussi real-time Reti Di Calcolatori LS A.A. 2003/04 Alberto Mancini mat. 170363.

Middleware per il monitoraggio di flussi real-time

Reti Di Calcolatori LSA.A. 2003/04

Alberto Mancinimat. 170363

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

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

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

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-C6713 Livello automazione

Livello del campo

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

4

Obiettivi1 - Introduzione

Trasparenza rispetto all’hardware 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

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

5

Architettura sistema

L’architettura del middleware è organizzata secondo i seguenti livelli:

2 - Modello concettuale

SCHEDAHARDWARE

SERVIZIAPPLICATIVI

COMUNICAZIONE

canaleflusso dati

MONITOR STORAGE

MANAGEMENT

GESTIONE FLUSSO REAL-TIME

TRASPORTO

RETE

DATA LINK

FISICO

GESTIONECANALI

Scheda HS55-DSP-C6713

Storage

Manager

Configurator Archive

Monitor

Le diverse entità saranno distribuite sui nodi seguendo lo schema:

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

6

Servizi del middleware2 - 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 dall’archivio.

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.

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

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 l’elenco delle variabili che ha intenzione di monitorare.

Visualizza automa scheda

Visualizza automa stazione di monitoraggio

Visualizza automa manager

INIT SOFTWAREOKREGISTERED

CONFIGUREDREADYRUNNING

ATTESA REGISTRAZIONE

ATTESA SOFTWARE ATTESA RICHIESTA CONFIGURAZIONE

NODOREGISTRATO

SOFTWARECARICATO

AVVIOMANUALE

ARRESTOMANUALE

ATTESA ARRESTO

ATTESA AVVIO

STAZIONICONFIGURATE

RICHIESTACONFIGURAZIONE

ATTESA CONFIGURAZIONE

STAZIONI

Automa scheda

INIT CONFIGUREDREGISTERED

ATTESA REGISTRAZIONE

ATTESA CONFIGURAZIONE

NODOREGISTRATO

RICEZIONECONFIGURAZIONE

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

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

8

NOTIFICA ERRORI

MON. VITALITA’

CONFIGURAZIONE

REGISTRAZIONE

NOTIFICA ERRORI

CONFIGURAZIONE

Infrastruttura di comunicazione (1/2)

Dato l’elevato 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

ManagerStazioni

di Monitoraggio

Archive

REGISTRAZIONE

Scheda

In realtà questo canale viene implicitamente fornito dal linguaggio (file system remoto)

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

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 dell’ordinamento 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 dell’ordine 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

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

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

MCF5272Monitor / 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à

variables Elenco 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

receiveAlivePortremoteErrorPort

Indirizzo multicast (classe D) utilizzato per l’invio dei dati da monitorarePorta 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 dell’indirizzo IP del manager e della porta di registrazione.

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

11

Protocolli di comunicazione (2/3)2 - Modello concettuale

CONFIGURATION;variables

name,offset,length,period

varSpec;

varSpec; …

variables Elenco delle variabili di cui richiedere la configurazionereqConf

nameoffset

Nome della variabileOffset di inizio dei dati relativi alla variabilerespConf

lengthperiod

Lunghezza dei dati relativi alla variabilePeriodo di campionamento della variabile

resultnodeAck result OK se le risorse locali sono sufficienti al trattamento dei dati, altrimenti NO

READYmanAck Notifica alla scheda che la configurazione dei nodi di monitoraggio è terminata

Manager

nodeAck

MonitorStorage

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 all’istante in cui è stata richiesta la configurazione, attendendo una conferma di ricezione

4. Il Manager notifica alla scheda l’avvenuta configurazione dei nodi in modo che questa transiti in stato READY ed abiliti il comando di avvio

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

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

MonitorStorage

PROG_NUM

DATA

Numero progressivo che individua l’ultimo 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

varData …DATA

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

13

Gestione del flusso di dati

Ciascuna stazione, attraverso un modulo di gestione del flusso, dovrà estrarre i dati di interesse ricostruendo l’ordine corretto degli stessi, eventualmente gestendo opportunamente omissioni o ritardi inaccettabili di datagrammi.

2 - Modello concettuale

RETE

pacchetto

sottopacchetto

sottopacchetto

ESTRAZIONESOTTOPACCHETTI

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.

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

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 RAM Il canale TCP garantisce il mantenimento dell’ordine 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.

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

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

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

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 rate2. Impostazione automatica

del fattore di ris. per visualizzare tutti i dati.

1. Rilevamento transfer rate2. 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.

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

17

Adattamento dinamico della risoluzione

Dato che l’utilizzo principale del middleware è quello di realizzare applicazioni

mirate all’osservazione di variabili attraverso l’oscilloscopio 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 l’eventuale 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 l’aumento 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

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

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 l’elemento 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 l’osservazione 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 all’interno dell’intero sistema, è necessario che tutti i nodi partecipanti, oltre a visualizzarli localmente, li reindirizzino verso il Manager utilizzando il canale di comunicazione preposto.

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

19

Simulazione della scheda

In memoria comune sono presenti i dati operativi di interesse così organizzati:

4 - Implementazione

NUMPROG

BUFFER

32 bit

variabile 1

NUMPROG

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, l’architettura della scheda è la seguente:

MEM. LOCALEMCF5272Coldfire

C6713

F2407A

MEM. LOCALE

MEM. LOCALE

MEMORIACOMUNE

FPGAEP1C6

Supervisione scheda (interfaccia ethernet)

Algoritmi di controllo

Interfaccia con il campo

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

20

Stazioni di monitoraggio

La stazione di monitoraggio è un’astrazione 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

Station Configurator

Registration

SendAlive

ThreadThread

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

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

21

Componenti realizzati

Di seguito è riportato l’elenco dei principali componenti che costituiscono il

middleware; per ciascuno di essi è visualizzabile l’interfaccia grafica associata

e l’architettura logica che ne definisce la struttura statica:

4 - Implementazione

Interfaccia graficaInterfaccia graficaSimulazione della scheda Architettura logicaArchitettura logica

Interfaccia graficaInterfaccia graficaComponente di management Architettura logicaArchitettura logica

Interfaccia graficaInterfaccia graficaStazione di visualizzazione Architettura logicaArchitettura logica

Interfaccia graficaInterfaccia graficaStazione di memorizzazione Architettura logicaArchitettura logica

Interfaccia GraficaInterfaccia GraficaArchitettura LogicaArchitettura Logica

MCF5272Interface

InterfaceFrame

Configurator

Thread

Registration

JFrame

MCF5272

CheckResource

Interfaccia GraficaInterfaccia GraficaArchitettura LogicaArchitettura Logica

Manager

Thread

NodeList JPanel

InterfaceFrame JFrame

Logging

ManagerInterface

Nodes

Node

2

*

Registration

RequestConfig

ReceiveAlive

CheckAlive

RemoteError

Interfaccia GraficaInterfaccia GraficaArchitettura LogicaArchitettura Logica

StationThread

CheckResource

JPanel

InterfaceFrame

JFrame

Monitor

ScreenMonitor

Interfaccia GraficaInterfaccia GraficaArchitettura LogicaArchitettura Logica

StationThread

CheckResource

FileManager

InterfaceFrame

JFrame

Storage

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

22

Estensioni future5 - Conclusioni

Indicazione dei valori massimi e minimi delle forme d’onda 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 l’armonica

fondamentale della forma d’onda, ottenga l’aggancio di fase automatico,

con conseguente impostazione della scala dei tempi ottimale.

• Analizzatore di spettro del flusso di dati; dato l’elevato carico

computazionale, è realistica una implementazione che operi off-line su dati

precedentemente memorizzati.

• Virtualizzazione del sistema rispetto all’infrastruttura 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 l’utilizzo di JNI (Java Native Interface).

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

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…