Segnalazione Emergenze Fiumi 25 Febbraio 2015 Progetto di Architettura del Software e dei Dati GRUPPO PRSZ Perego Riccardo, 748503 Re Depaolini Matteo,

Presentazione sul tema: "Segnalazione Emergenze Fiumi 25 Febbraio 2015 Progetto di Architettura del Software e dei Dati GRUPPO PRSZ Perego Riccardo, 748503 Re Depaolini Matteo,"— Transcript della presentazione:

1 Segnalazione Emergenze Fiumi 25 Febbraio 2015 Progetto di Architettura del Software e dei Dati GRUPPO PRSZ Perego Riccardo, 748503 Re Depaolini Matteo, 751446 Salvi Daniele, 748199 Zardoni Matteo, 745573

2 Il problema in esame (1 di 5) Si deve realizzare un sistema per l’osservazione della situazione idrogeologica del territorio e per la segnalazione di emergenze. Il sistema deve supportare: 1. L’acquisizione in tempo reale di dati idrometrici DI (livello dei corsi d’acqua) attraverso opportuni sensori e le serie storiche dei livelli osservati sono archiviati in una Base di Dati della rete Idrica (BRI) che fa parte del progetto 2

3 Il problema in esame (2 di 5) 2. L’acquisizione di segnalazioni di emergenze gravi SEG (esondazione in atto o a forte rischio) da parte di operatori a campo 3. L’acquisizione di previsioni meteo sul medio termine relative a una Regione accedendo a una Base Dati Meteo (BDM) esterna preesistente. Si assuma che BDM fornisca previsioni per ogni ora delle prossime 36 ore, articolate per celle spaziali di dimensione 10 x 10 chilometri 3

4 Il problema in esame (3 di 5) 4. L’identificazione di situazioni di emergenza potenziali SEP a medio termine (alcune ore), attraverso l’incrocio delle informazioni di BDM e DI. Le situazioni di emergenza potenziali devono esser rese visibili agli operatori di un Centro di Supervisione, ai Responsabili Territoriali della Protezione Civile e, in forma sintetica, a tutta la popolazione interessata 4

5 Il problema in esame (4 di 5) 5. La pianificazione degli spostamenti delle Squadre di Emergenza in base alle informazioni SEP. La pianificazione degli spostamenti delle squadre deve essere notificata ai Responsabili Territoriali della Protezione Civile e alle Squadre di Emergenza coinvolte. L’allocazione sul territorio delle Squadre di Emergenza deve essere memorizzata in una Base di Dati Segnalazione di Emergenza (BSE), che fa parte del progetto 5

6 Il problema in esame (5 di 5) 6. La notifica di emergenze gravi (SEG) alle squadre di emergenza più prossime 6

7 Assunzioni adottate (1 di 3) 1. Il sistema gestisce le possibili emergenze di una singola regione 2. Le rilevazioni vengono acquisite ogni ora tramite timestamp, espresso in millisecondi 3. Abbiamo supposto che non possa verificarsi un’emergenza in meno di un’ora 4. I dati che vengono forniti dal meteo sono i millimetri di pioggia che cadono nell’arco di un’ora in una cella 10 x 10 chilometri 7

8 Assunzioni adottate (2 di 3) 5. Il sensore è ancorato sul letto del fiume 6. Gli operatori a campo sono componenti delle Squadre di Emergenza 7. Gli operatori sono inviati sul posto dalle Squadre di Emergenza, e non dal sistema 8. Un operatore a campo si dirige in prossimità del sensore su indicazione della Squadra 9. Le Squadre si muovono nella zona di emergenza una volta effettuata una pianificazione 8

9 Assunzioni adottate (3 di 3) 10. Una situazione di emergenza potenziale non può diventare emergenza grave in meno di un’ora, in quanto supponiamo che il livello del fiume non possa aumentare in modo esagerato 11. Il sistema deve essere operativo 24 ore su 24 9

10 ARCHITETTURA DEL SOFTWARE

11 ARCHITETTURA DEL PROBLEMA (1 di 12) Modello dei Casi d’Uso (WHO) 11

12 ARCHITETTURA DEL PROBLEMA (2 di 12) Modello dei Casi d’Uso (WHO, WHERE) 12

13 ARCHITETTURA DEL PROBLEMA (3 di 12) Modello delle informazioni (WHAT) 13

14 ARCHITETTURA DEL PROBLEMA (4 di 12) Flussi informativi (HOW) 14

15 ARCHITETTURA DEL PROBLEMA (5 di 12) Flussi informativi (HOW) 15

16 ARCHITETTURA DEL PROBLEMA (6 di 12) Flussi informativi (HOW) 16

17 ARCHITETTURA DEL PROBLEMA (7 di 12) WHY 17

18 ARCHITETTURA DEL PROBLEMA (8 di 12) WHY 18

19 ARCHITETTURA DEL PROBLEMA (9 di 12) WHY 19

20 ARCHITETTURA DEL PROBLEMA (10 di 12) Frequenze e vincoli di tempo (WHEN) 20

21 ARCHITETTURA DEL PROBLEMA (11 di 12) Frequenze e vincoli di tempo (WHEN) 21

22 ARCHITETTURA DEL PROBLEMA (12 di 12) Frequenze e vincoli di tempo (WHEN) 22

23 ARCHITETTURA LOGICA 1 (1 di 3) (Non adottata) 23

24 ARCHITETTURA LOGICA 1 (2 di 3) (Non adottata) 24

25 ARCHITETTURA LOGICA 1 (3 di 3) (Non adottata) 25

26 FOOTPRINT ARCHITETTURA 1 (1 di 3) (Non adottata) Componente Acquisizione Rilevazione Abstract10 Shared33 Intraflow0 Extraflow14 Frequency10 Complexity10 Location10 26

27 FOOTPRINT ARCHITETTURA 1 (2 di 3) (Non adottata) Componente IdentificazioneNotificaSEP Abstract50 Shared41 Intraflow0 Extraflow71 Frequency20 Complexity50 Location55 Supponendo di integrare i componenti IdentificazioneSEP e Notifica, ci si accorge dal footprint che non è una soluzione ottimale: per questo abbiamo deciso di separarli 27

28 FOOTPRINT ARCHITETTURA 1 (3 di 3) (Non adottata) Componente Assistente SEG Abstract10 Shared16 Intraflow0 Extraflow14 Frequency10 Complexity66 Location10 28

29 ARCHITETTURA LOGICA 2 (1 di 2) (Adottata) 29

30 ARCHITETTURA LOGICA 2 (2 di 2) ARCHITETTURA LOGICA 2 (2 di 2) (Adottata) 30

31 FOOTPRINT ARCHITETTURA 2 (1 di 4) (Adottata) Componente Acquisizione Rilevazione Abstract10 Shared33 Intraflow0 Extraflow14 Frequency10 Complexity10 Location10 31

32 FOOTPRINT ARCHITETTURA 2 (2 di 4) (Adottata) Componente Identificazione SEP Abstract10 Shared42 Intraflow25 Extraflow14 Frequency10 Complexity100 Location10 32

33 FOOTPRINT ARCHITETTURA 2 (3 di 4) (Adottata) Componente Notifica Abstract10 Shared25 Intraflow25 Extraflow57 Frequency10 Complexity10 Location100 33

34 FOOTPRINT ARCHITETTURA 2 (4 di 4) (Adottata) Componente Assistente SEG Abstract10 Shared16 Intraflow0 Extraflow14 Frequency10 Complexity66 Location10 34

35 ARCHITETTURA CONCRETA (1 di 6) Modalità di interazione fra componenti 35

36 ARCHITETTURA CONCRETA (2 di 6) Modalità di interazione fra componenti 36

37 ARCHITETTURA CONCRETA (3 di 6) Modalità di interazione fra componenti 37

38 ARCHITETTURA CONCRETA (4 di 6) Modalità di interazione fra componenti 38

39 ARCHITETTURA CONCRETA (5 di 6) (Non adottata) Deployment 1 39

40 ARCHITETTURA CONCRETA (6 di 6) (Adottata) Deployment 2 40

41 SCELTE TECNOLOGICHE (1 di 4) Sistema di rilevazione dei livelli: PS-Light-2 41

42 SCELTE TECNOLOGICHE (2 di 4) Sistema di rilevazione dei livelli: PS-Light-2 42 PS-Light-2 Intervallo di misurazione: 0-10 m, 0-20 m, 0-40 m, 0-70 m Temperatura di funzionamento: da -20C° a +50C° Output: RS 232 (seriale) Intervallo di misurazione: programmabile da 1 min in su SEBA - Data Logger Salvataggio misurazione: nell’immediato Memoria flash: 4MB per circa 280 000 misurazioni Alimentazione: batteria da 12V Slot SIM-CARD, modulo GPRS incluso PREZZO: 1300€ per sensore

43 SCELTE TECNOLOGICHE (3 di 4) Server centrale: HP ProLiant BL460c 43 CPU: Intel Xeon E5-2650V2 2.6GHz 8 core Cache 20MB RAM: 32GB DDR3 SDRAM 1866MHz (espandibile fino a 256GB) Hard Disk: 3TB Serial ATA III 3,5” 6GB/sec PREZZO: 3414€

44 SCELTE TECNOLOGICHE (4 di 4) Dispositivo Operatori a campo: Moto G 2014 44 CPU: Qualcomm Snapdragon Quadcore 1,2GHz RAM: 1GB LPDDR3 RAM Storage: 8GB (espandibile con microSD) Batteria: 2070 mAh Li-ion Display: 5” 1280x720 (294 ppi) Rete: GSM, GPRS + EDGE, UMTS, HSPA+ Camera: 8MP Operating System: Android 5 Lollipop PREZZO: 199€

45 RIEPILOGO COSTI (1 di 3) Costi fissi 45 1 : 16 fiumi regione Lombardia. Un sensore in ogni porzione di fiume priva di emissari e affluenti. Ogni fiume 6 emissari (affluenti), si necessitano circa 16 x 6 sensori = 100 circa 2 : 35€/h per 2 persone per 5 ore di lavoro = 350€. * Tutti i prezzi orari e relativi a materiali sono lordi, e non sono considerati eventuali sconti applicabili in seguito all’accettazione del preventivo. PrezzoQuantitàTotale Sensore1300 €100 1 130000 € Costi installazione350 2 €10035000 € Server3414 €1 Sviluppo Server 30 €/h 5 persone, 8 ore al giorno, 5 mesi 132000 € Mobile199 €509950 € Sviluppo App Mobile 40 €/h 2 persone, 8 h al giorno, 2 settimane 6400 € Totale316764* €

46 RIEPILOGO COSTI (2 di 3) Costi eventuali e mensili 46 PrezzoQuantitàDettagliTotale Traffico Dati Sensore 9 €100 1 1GB (Vodafone Micro)900 € Traffico Operatori a Campo 22,9 €50 400 min, 400 SMS, 1GB (Vodafone RAM Mini) 1145 € Manutenzion e Sensori 40 €/h 8 h x 5 giorni 20€ a persona, ogni 3-4 mesi 1600 € Manutenzion e Sistema 30 €3 Costo relativo a un eventuale guasto 90 € Totale3735 €

47 RIEPILOGO COSTI (3 di 3) Costo Software PrezzoDescrizione Sistema Operativo Server 279 € Windows 8.1 Enterprise 64 Bit Licenza DataBase 5000€/anno MySQL Enterprise Edition 1 1 : Tale licenza rispetta le regole ACID delle transazioni, le operazioni di Commit, Rollback, Chiavi esterne, Livelli di insolazione tramite lock personalizzabili e prevede un ottimizzatore di query 47

48 ARCHITETTURA DEI DATI

49 Postazione(Latitudine, Longitudine, Rischio, CapienzaMax, Localita) Sensore(idSensore, Latitudine, Longitudine) GrafoFiumi(idSensore1, idSensore2, Percentuale, Distanza) Rilevazione(idSensore, PortataAttuale, VelocitaAttuale, TimeStamp) REVERSE ENGENEERING (1 di 4) BRI: Modello Logico 49

50 REVERSE ENGENEERING (2 di 4) BRI: Modello Concettuale 50

51 REVERSE ENGENEERING (3 di 4) BDM: Modello Logico Area-Quadrata(idCella, LatNE, LongNE, LatSO, LongSO) Previsione(Data_Ora, idCella, Pioggia, Temperatura, idVento) Vento(Nome, Classificazione, VelocitaAttuale, Quota, idVento) 51

52 REVERSE ENGINEERING (4 di 4) BDM: Modello Concettuale 52

53 DATA INTEGRATION (1 di 15) Integrazione di BDM e BRI L’integrazione virtuale delle due basi di dati fisiche produce uno schema globale virtuale mappato sugli schemi locali. Tuttavia questa operazione porta a problemi di integrazione concettuale fra gli schemi locali fisici. 53

54 DATA INTEGRATION (2 di 15) Eterogeneità e Corrispondenza Interschema Durante l’attività di Data Integration sono sorte le seguenti eterogeneità: Tipo Eterogeneità Relazioni Coinvolte Attributo 1Attributo 2Dettagli Omonimia BDM.Vento BRI.Rilevazione VelocitaAttuale Unità di misura Sinonimia BDM.Postazione BRI.Area-Quadrata LatitudineLatNE Stesso concetto, nomi diversi Sinonimia BDM.Postazione BRI.Area-Quadrata LatitudineLatSO Stesso concetto, nomi diversi Sinonimia BDM.Postazione BRI.Area-Quadrata LongitudineLongNE Stesso concetto, nomi diversi 54

55 DATA INTEGRATION (3 di 15) Eterogeneità e Corrispondenza Interschema Durante l’attività di Data Integration sono sorte le seguenti eterogeneità: Tipo Eterogeneità Relazioni Coinvolte Attributo 1Attributo 2Dettagli Sinonimia BDM.Vento BRI.Rilevazione LongitudineLongSO Stesso concetto, nomi diversi 55

56 DATA INTEGRATION (4 di 15) Eterogeneità e Corrispondenza Interschema Durante l’attività di Data Integration sono sorte le seguenti corrispondenze interschema: Tipo Corrispondenza Interschema Relazioni Coinvolte Attributo 1Attributo 2Dettagli Corrispondenza Funzionale BDM.Previsione BRI.Rilevazione Data_OraTimeStamp Data_Ora = TimeStamp + 20 * 60 * 1000 Aggregazione BDM.Area-Quadrata BRI.Postazione -- Area-Quadrata è un’aggregazione di Postazione 56

57 DATA INTEGRATION (5 di 15) Schema Globale: Modello Concettuale 57

58 DATA INTEGRATION (6 di 15) Schema Globale: Progettazione logica RilevazioneEPrevisione(idSensore, TimeStamp, Pioggia, Rischio, LivelloAttuale, VelocitaAttuale, idVento, Latitudine, Longitudine) GrafoFiumi(idSensore1, idSensore2, Distanza, Percentuale) Vento(idVento, VelocitaAttuale, Quota, Nome, Classificazione) Postazione(Latitudine, Longitudine, Rischio, CapienzaMax, Localita) Area-Quadrata(idCella, LatNE, LongNE, LatSO, LongSO) 58

59 DATA INTEGRATION (7 di 15) Mapping GAV: View Postazione CREATE VIEW Postazione(Latitudine, Longitudine, Rischio, CapienzaMax, idCella) AS SELECT P.Latitudine AS Latitudine, P.Longitudine AS Longitudine, P.Rischio, P.CapienzaMax, AQ.idCella FROM BRI.Postazione AS P, BDM.Area_Quadrata AS AQ WHERE P.Latitudine AQ.LatSO AND P.Longitudine > AQ.LongSO 59

60 DATA INTEGRATION (8 di 15) Mapping GAV: View RilevazioneEPrevisione CREATE VIEW RilevazioneEPrevisione(idSensore, Timestamp, Pioggia, PortataAttuale, VelocitaAttuale, idVento, Latitudine, Longitudine) AS SELECT S.idSensore AS idSensore, R.TimeStamp AS TimeStamp, P.Pioggia AS Pioggia, R.PortataAttuale AS PortataAttuale, R.VelocitaAttuale AS VelocitaAttuale, P.idVento AS idVento, S.Latitudine AS Latitudine, S.Longitudine AS Longitudine FROM (BDM.Area_Quadrata AS AQ INNER JOIN BDM.Previsione AS P ON P.cella = AQ.idCella) LEFT OUTER JOIN (BRI.Sensore AS S INNER JOIN BRI.Rilevazione AS R ON R.idSensore = S.idSensore) ON R.Timestamp = P.Data_Ora WHERE S.idSensore is Null OR (S.Latitudine AQ.LatSO AND S.Longitudine > AQ.LongSO) 60

61 DATA INTEGRATION (9 di 15) Mapping GAV: Precisazione su RilevazioneEPrevisione Per poter fare l’integrazione, il Wrapper relativo allo schema locale ha l’obbligo di trasformare il dato in un formato compatibile al Mediatore. Il Wrapper inoltre trasforma Timestamp e Data_Ora in un formato opportuno per un confronto tra i due (come ad esempio due interi). Trasforma anche le coordinate latitudine e longitudine in interi confrontabili. Ogni rilevazione viene effettuata a cadenza oraria. Nell’arco orario, il sensore al minuto :40 effettua la rilevazione, e all’ora precisa (:00) il sistema riceve le nuove previsioni meteorologiche. Il Wrapper è in grado di associarle trasformandole in un intero per poter effettuare il Join. 61

62 DATA INTEGRATION (10 di 15) Conversione Timestamp - Data_Ora in formato compatibile 62

63 DATA INTEGRATION (11 di 15) Mapping GAV: View Area-Quadrata CREATE VIEW Area-Quadrata(idCella, LatNE, LongNE, LatSO, LongSO) AS SELECT AQ.idCella AS idCella, AQ.LatNE AS LatNE, AQ.LongNE AS LongNE, AQ.LatSO AS LatSE, AQ.LongSO AS LongSO FROM BDM.Area-Quadrata AS AQ 63

64 DATA INTEGRATION (12 di 15) Mapping GAV: View Vento CREATE VIEW Vento(idVento, VelocitaVento, Quota, Nome, Classificazione) AS SELECT V.idVento AS idVento, V.VelocitaAttuale AS VelocitaVento, V.Quota AS Quota, V.Nome AS Nome, V.Classificazione AS Classificazione FROM BDM.Vento AS V 64

65 DATA INTEGRATION (13 di 15) Mapping GAV: View GrafoFiumi CREATE VIEW GrafoFiumi(idSensore1, idSensore2, Distanza, Percentuale) AS SELECT GF.idSensore1 AS idSensore1, GF.idSensore2 AS idSensore2, GF.Distanza AS Distanza, GF.Percentuale AS Percentuale FROM BRI.GrafoFiumi AS GF 65

66 DATA INTEGRATION (14 di 15) Query applicazione e Unfolding “Trovare tutte le latitudini e longitudini dell’area di previsioni con id 764” Query sullo schema globale: SELECT AQ.latitudine AS latitudine, AQ.longitudine AS longitudine FROM AreaQuadrata AS AQ WHERE AQ.idCella = 764 La seguente query non è supportata da tutti i database: SELECT Latitudine, Longitudine FROM ( SELECT AQ.idCella AS idCella, AQ.LatNE AS LatNE, AQ.LongNE AS LongNE, AQ.LatSO AS LatSE, AQ.LongSO AS LongSO FROM BDM.Area_Quadrata AS AQ ) WHERE idCella = 764 66

67 DATA INTEGRATION (15 di 15) Query applicazione e Unfolding La seguente query è supportata dalla maggior parte dei database: SELECT AQ.Latitudine AS Latitudine, AQ.Longitudine AS Longitudine FROM BDM.AreaQuadrata AS AQ WHERE AQ.idCella = 764 67 La seguente query è supportata dalla maggior parte dei database: SELECT AQ.Latitudine AS Latitudine, AQ.Longitudine AS Longitudine FROM BDM.AreaQuadrata AS AQ WHERE AQ.idCella = 764

68 FORMATO APERTO (1 di 4) Scelta del formato aperto da usare: CSV Consideriamo questa porzione di un documento CSV. Tale documento contiene tutti i dati delle rilevazioni svolte coi relativi timestamp. Una porzione del contenuto potrebbe essere la seguente: Timestamp;Pioggia;LivelloAttuale;VelocitaAttuale;Latitudine;Longitudine;Localita; ; 1424788517290;0;3;2;45.400114;8.848202;Abbiategrasso;; 1424794517290;2;4;1;45.542967;9.526951;Groppello D’Adda;; 1424796917290;1;2;2;45.666327;9.255565;Triuggio;; Abbiamo scelto di utilizzare come formato il CSV in quanto è un formato aperto, ed è machine-readable quindi leggibile da macchine programmabili. 68

69 FORMATO APERTO (2 di 4) Scelta della licenza Visto che il sistema deve prevedere il rilascio dei dati in formato aperto, abbiamo pensato di rendere la distribuzione gratuita di una parte dei dati contenuti nei CSV, ad esempio tramite la pubblicazione di tali file sui relativi siti della Regione. Timestamp;Pioggia;LivelloAttuale;VelocitaAttuale;Localita; ; 1424788517290;0;3;2;Abbiategrasso;; 1424794517290;2;4;1;Groppello D’Adda;; 1424796917290;1;2;2;Triuggio;; 69

70 FORMATO APERTO (3 di 4) In merito alla privacy… Per quanto riguarda le questioni della privacy, i file CSV contenenti le rilevazioni non contengono dati sensibili. Tuttavia, visto che abbiamo supposto che la localizzazione dei sensori è precisa, i valori di latitudine e longitudine potrebbero essere utilizzati da malintenzionati per danneggiare i sensori. Infatti, i dati che sono pubblicati ad esempio sui siti delle regioni non contengono tali valori. 70

71 FORMATO APERTO (4 di 4) IODL 2.0 Per il rilascio abbiamo deciso di utilizzare una licenza IODL v2.0. La "Italian Open Data License" (IODL) è un contratto di licenza che ha lo scopo di consentire agli utenti di condividere, modificare, usare e riusare liberamente la banca di dati, i dati e le informazioni con essa rilasciati, garantendo al contempo la stessa libertà per altri. La presente licenza mira a facilitare il riutilizzo delle informazioni pubbliche nel contesto dello sviluppo della società dell’informazione. Con la licenza IODL 2.0 è possibile riprodurre, distribuire al pubblico, concedere in locazione, presentare e dimostrare in pubblico, comunicare al pubblico (messa a disposizione del pubblico inclusa), trasmettere e ritrasmettere in qualunque modo, eseguire, recitare, rappresentare, includere in opere collettive e/o composte pubblicare, estrarre e reimpiegare le Informazioni. 71