1 / 13

OR5 – Rete WP 5.1

Programma operativo nazionale RICERCA e COMPETIVITA’ per le regioni della convergenza - 2007/2013 - cci: 2007it161po006 Asse I “Sostegno ai mutamenti strutturali”

ima-rosales
Download Presentation

OR5 – Rete WP 5.1

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Programma operativo nazionale RICERCA e COMPETIVITA’ per le regioni della convergenza - 2007/2013 - cci: 2007it161po006 Asse I “Sostegno ai mutamenti strutturali” Obiettivo Operativo 4.1.1.1. “Aree scientifico-tecnologiche generatrici di processi di trasformazione del sistema produttivo e creatrici di nuovi settori” Azione II: “Interventi di sostegno della ricerca industriale” Progetto PON01_01503 Ambito/Settore AMBIENTE E SICUREZZA Titolo Progetto: Sistemi integrati per il monitoraggio, l’earlywarning e la mitigazione del rischio idrogeologico lungo le grandi vie di comunicazione cupB31H11000370005 OR5 – Rete WP 5.1

  2. ARCHITETTURA DELLA RETE DI COMUNICAZIONE L’architettura di riferimento, della rete EarlyWarning, di seguito indicata come EAWARNET presa in esame per l’implementazione della infrastruttura comprende : • Il Centro ServiziC A E D • Framework per l’Infrastruttura di rete • Livello Applicativo (Application Layer) • Livello Trasporto (TransportLayer) • LivelloFisico (Phisical Link Layer - PLL) (Definizionedettaglio in progress) • I Siti di Monitoraggiodella tipologia-2 (vedi slide succ)

  3. RETE DI COMUNICAZIONE –Scenari Connettività livello Fisico PHY-Layer Muovendo dai due possibili scenari operativi sono state definite le tipologie di Siti di Monitoraggio: • Sito con concentratoresono state previste 5 Tipologie: • Tipologia 1 - Prevede la presenzadiconcentratore per itresensori : • Sensori Radar (R) • Sensore/i - Strago (S) • Sensore/i - TD Group(Td) • Tipologia 2 - Prevede la presenza di sensori : • SensoreSDRadar (SDR) -> • Sensore/i – Strago (S) • Tipologia 3 - Prevede la presenzadiconcentratore per i due sensori : • Sensore/i - Strago (S) • Sensore/i - TD Group (Td) • Tipologia 4 - Prevede la presenzadiconcentratore per i due sensori : • Sensori Radar (R) • Sensore/i - TD Group(Td) • Tipologia 5 - Prevede la presenzadiconcentratore per ilsingolosensore : • Sensore/i - TD Group(Td)

  4. RETE DI COMUNICAZIONE –Scenari o Tipologia-2 Connettività livello Fisico PHY-Layer Framework per SDRadar

  5. RETE DI COMUNICAZIONE – FRAMEWORK -Strati ISO-OSI e Attività svolte Proiezione del FRAMEWORKApplicativo (SDRad) sull’infrastruttura di Comunicazione si traduce in componenti di due livelli : Livello Applicativo(AL) CAED AqServ MESSAGE PROTOCOL :Implementazione e Test componente middleware di protocolbridging(Sensore Radar-SDR ) Livello di Trasporto(TL) (SckStrmTCP) : Implementazione e Test componente frameworkAqServ-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 BackBoneverosimilmente 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 Direct Link Intranet Link

  6. ARCHITETTURA DEL FRAMEWORK “EWARNET” di Livello 3,4 AqServ Lo schema architetturale del framework, Implementazione e test dei tre macro componentiper il prototipo di comunicazione CAED<->SDRadar (impiego come linea guida) • CAED AqServ -Client • Componente Client per TrLP-SS_TCP lato CAED • ComponenteClient per ApLP-Message Protocol Manager • MiddleWare • MainProcess • Queue Manager • ApLPBridge-> ProtocolAdapter • SDR-Server • Componente Server\Listner per TrLP TCPIP/UDP per SDR-NIBoard • ComponenteServer UsrpProtocol Manager AqServCli SensSrv SDRadar

  7. ARCHITETTURA DEL FRAMEWORK “EWARNET”<AqServ client> AqServ AqServ Client • 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-DebugFeatures • Disconnect

  8. ARCHITETTURA DEL FRAMEWORK “EWARNET”<Middleware-SDRadar Server(4NI)> SDR Tipe1-NI Radar Sensors 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-DebugFeatures • Disconnect

  9. ARCHITETTURA DEL FRAMEWORK “EWARNET”<Middleware-Main Monitor> Il Framework implementa una architettura multi-threads, il processo principale del Middleware indicato come MainProcess Monitor, • Supervisiona i threads secondari quali : • AqServ-clientthread • SDR Serverthread • (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 MainProcess MONITOR

  10. Framework “EWARNET” Stack Protocol Layers – Middleware Bridging Sink CAED AqServ MiddleWare CaedAqServMProtocol TCP SockStreamAsync Direct-Link UMTS/GSM/GPRS ETHERNET MODULE (GW)

  11. Framework “EWARNET” - Middleware -Monitor Bridging test 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 - CrossOvercomponent • SDR-Srvcomponent • ComunicazioneAsincrona traSDR_SRV e AqS_CLIENT,in particolare CAED AqServ Message Protocol ->test sulle facilities di PROTOCOL Bridge • Process(Brdg\adapt) Connection request • Process(Brdg\adapt) LogINrequest(Encr-Rinjadel) • ComputeResponse • Notify_Status • Log-DebugFeatures • Process(Brdg\adapt) Disconnectionrequest

  12. SDRadar Sensor -State Machine 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

  13. In Progress: Framework Boostrap->Radar Sensor Client (4NI)Middleware ->adattamento , migrazione , istallaione su altri Sensori 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

More Related