P ROGRAMMA OPERATIVO NAZIONALE RICERCA E COMPETIVITA PER LE REGIONI DELLA CONVERGENZA - 2007/2013 - CCI : 2007 IT 161 PO 006 A SSE I S OSTEGNO AI MUTAMENTI.

Presentazione sul tema: "P ROGRAMMA OPERATIVO NAZIONALE RICERCA E COMPETIVITA PER LE REGIONI DELLA CONVERGENZA - 2007/2013 - CCI : 2007 IT 161 PO 006 A SSE I S OSTEGNO AI MUTAMENTI."— Transcript della presentazione:

1 P ROGRAMMA OPERATIVO NAZIONALE RICERCA E COMPETIVITA PER LE REGIONI DELLA CONVERGENZA - 2007/2013 - CCI : 2007 IT 161 PO 006 A SSE I S OSTEGNO AI MUTAMENTI STRUTTURALI O BIETTIVO O PERATIVO 4.1.1.1. A REE SCIENTIFICO - TECNOLOGICHE GENERATRICI DI PROCESSI DI TRASFORMAZIONE DEL SISTEMA PRODUTTIVO E CREATRICI DI NUOVI SETTORI A ZIONE II: I NTERVENTI DI SOSTEGNO DELLA RICERCA INDUSTRIALE P ROGETTO PON01_01503 A MBITO /S ETTORE AMBIENTE E SICUREZZA T ITOLO P ROGETTO : S ISTEMI INTEGRATI PER IL MONITORAGGIO, L EARLY WARNING E LA MITIGAZIONE DEL RISCHIO IDROGEOLOGICO LUNGO LE GRANDI VIE DI COMUNICAZIONE CUP B31H11000370005 OR5 – Rete WP 5.1

2 Larchitettura di riferimento, della rete Early Warning, di seguito indicata come EAWARNET presa in esame per limplementazione della infrastruttura comprende : Il Centro Servizi C A E D Framework per lInfrastruttura di rete Livello Applicativo (Application Layer) Livello Trasporto (Transport Layer) Livello Fisico (Phisical Link Layer - PLL) ( Definizione dettaglio in progress) I Siti di Monitoraggio della tipologia-2 (vedi slide succ)

3 Muovendo dai due possibili scenari operativi sono state definite le tipologie di Siti di Monitoraggio: Sito con concentratore sono state previste 5 Tipologie: Tipologia 1 - Prevede la presenza di concentratore per i tre sensori : Sensori Radar (R) Sensore/i - Strago (S) Sensore/i - TD Group(Td) Tipologia 2 - Prevede la presenza di sensori : Sensore SDRadar (SDR) -> Sensore/i – Strago (S) Tipologia 3 - Prevede la presenza di concentratore per i due sensori : Sensore/i - Strago (S) Sensore/i - TD Group (Td) Tipologia 4 - Prevede la presenza di concentratore per i due sensori : Sensori Radar (R) Sensore/i - TD Group(Td) Tipologia 5 - Prevede la presenza di concentratore per il singolo sensore : Sensore/i - TD Group(Td)

4 Framework per SDRadar

5 Proiezione del FRAMEWORK Applicativo (SDRad) sullinfrastruttura di Comunicazione si traduce in componenti di due livelli : Livello Applicativo (AL) CAED AqServ MESSAGE PROTOCOL : Implementazione e Test componente middleware di protocol bridging (Sensore Radar-SDR ) Livello di Trasporto (TL) (SckStrmTCP) : Implementazione e Test componente framework AqServ-Client Implementazione e Test componente SDR -Server Livello Fisico (PL): Direct-Link: il collegamento tra CAED e Sensore\SubNet Sensori è di tipo M2M(Machine_to_Machine via Operatore di BackBone verosimilmente Gprs /Umts/HSDPA) IntraNet-Link: collegamento tra CAED e Sito di Monitoraggio attraverso Nodo Concentratore di sensori (Sink-Node via Local Site Network) (IntraSite :GbEth- FastEth-WiFi ) ed Border_Router|Gateway: Gprs/Umts/HSDPA) Le configurazioni verranno scelte nel dettaglio in base ai 6 scenari previsti,tenendo conto della dislocazione dei siti lungo i tronchi autostradali oggetto del monitoraggio, prevedendo per il PL configurazioni ibride. Il suddetto livello in questa fase ha un rilevante grado di libertà tenendo conto dei fattori: Scenario di appartenenza del sito distanza tra i sensori posizione tra i sensori non-LOS potenza in trasmissione/ricezione dei sensori non alimentati da rete 4 Application Layer 3 Transport Layer 1 Physical Layer

6 Lo schema architetturale del framework, Implementazione e test dei tre macro componenti per il prototipo di comunicazione CAED SDRadar (impiego come linea guida) CAED AqServ -Client Componente Client per TrLP-SS_TCP lato CAED Componente Client per ApLP-Message Protocol Manager MiddleWare Main Process Queue Manager ApLP Bridge -> Protocol Adapter SDR-Server Componente Server\Listner per TrLP TCPIP/UDP per SDR-NIBoard Componente Server Usrp Protocol Manager AqServ Cli Sens Srv

7 Il componente server già installato e configurato sul CAED denominato AqServ, adopera una comunicazione socketStream TCP/IP (porta 8123) con comunicazione Asincrona. Aqserv-Client : Nelle fasi di implementazione del Middleware si è tenuto conto delle specifiche del componente Server implementando le funzionalità Client: Connection LogIN ParseMessages Enqueue_Messages ComputeResponse Notify_Status Log-Debug Features Disconnect AqServ

8 Nelle fasi di implementazione del componente del Framework : SDRadar-Server Sono state sviluppate e testate le facilities di gestione della connessione e scambio Messaggi|Comandi tra EmbeddedPC (MXE) e board NI-USRP : Connection LogIN ParseMessages Enqueue_Messages ComputeResponse Notify_Status Log-Debug Features Disconnect Radar Sensors

9 Il Framework implementa una architettura multi-threads, il processo principale del Middleware indicato come Main Process Monitor, Supervisiona i threads secondari quali : AqServ-client thread SDR Server thread (work_in_prog. SCWR Server thread) Ed Implementa il protocol Bridge di livello applicativo tra componente Server del Sensore radar e componente client del CAED AqServ Main Process MONITOR

10 CAED AqServ Sink MiddleWare Caed AqServ MProtocol TCP SockStream Async UMTS/GSM/GPRS ETHERNET MODULE (GW) Direct-Link

11 A valle della scelta dei moduli del Framework SDR- Srv e AqServ-CLI come linea guida per la validazione dei protocolli di livello 3 e 4 sono stati effettuati test di validazione su: AcqServ Client component Protocols - CrossOver component SDR-Srv component Comunicazione Asincrona tra SDR_SRV e AqS_CLIENT,in particolare CAED AqServ Message Protocol ->test sulle facilities di PROTOCOL Bridge Process(Brdg\adapt) Connection request Process(Brdg\adapt) LogIN request(Encr- Rinjadel) ComputeResponse Notify_Status Log-Debug Features Process(Brdg\adapt) Disconnection request

12 Scenario di avvio da remoto: S0: SBC riceve comando di «ON» e alimenta i sistemi S1: Systems BootStrap S2: MXE-MW WarmUp S3: Radar|Board NI – WarmUp S4: Net Start, connect to CAED SDR - States StateDescriptionBehaviour AqServ ALy-MPtcl MAPPING ref. S0PowerONNA BootstrapGoto_S1 ||Goto_S5;NA S1WarmUP Legge configurazione di default; Calibrazione Out_Door; Goto_S2||Goto_S5; NA S2READY Acetta comandi dal MiddWare; Goto_S1||Goto_S3 ||Goto_S5; Incoming Commands|Message Mapping Table S3Start_ACQUISITION Acquisisce Capmioni; Goto_S4||Goto_S5; Notify Message Mapping Table S4End ACQUISITION Notifica Termine Acquisizione; Goto_S2||Goto_S5; S5Internal Error Notifica System Warning Notify error Message Mapping Table

13 Implementazione e test delle procedure di Bootstrap di cui dotare il Framework per lo scenario di avvio da remoto: CAED -> via Rete invia comando ad SBC (Gruppo Potenza) S0: SBC riceve comando di «ON» e alimenta i sistemi S1: Systems BootStrap S2: MXE-MW WarmUp S3: Radar|Board NI – WarmUp S4: Net Start, connect to CAED