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