segnalazione emergenze fiumi 25 febbraio 2015 progetto di architettura del software e dei dati...

Segnalazione Emergenze Fiumi25 Febbraio 2015

Progetto di Architettura del Software e dei Dati

GRUPPO PRSZPerego Riccardo, 748503Re Depaolini Matteo, 751446Salvi Daniele, 748199Zardoni Matteo, 745573

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

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

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

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

Il problema in esame(5 di 5)

6. La notifica di emergenze gravi (SEG) alle squadre di emergenza più prossime

6

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

Assunzioni adottate(2 di 3)

5. Il sensore è ancorato sul letto del fiume6. Gli operatori a campo sono componenti

delle Squadre di Emergenza7. Gli operatori sono inviati sul posto dalle

Squadre di Emergenza, e non dal sistema8. 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

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

ARCHITETTURA DEL SOFTWARE

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

11

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

12

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

13

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

14

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

15

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

16

ARCHITETTURA DEL PROBLEMA (7 di 12)WHY

17

ARCHITETTURA DEL PROBLEMA (8 di 12)WHY

18

ARCHITETTURA DEL PROBLEMA (9 di 12)WHY

19

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

20

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

21

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

22

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

23

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

24

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

25

FOOTPRINT ARCHITETTURA 1 (1 di 3) (Non adottata)

Componente Acquisizione Rilevazione

Abstract 10

Shared 33

Intraflow 0

Extraflow 14

Frequency 10

Complexity 10

Location 10

26

FOOTPRINT ARCHITETTURA 1 (2 di 3) (Non adottata)Componente IdentificazioneNotificaSEP

Abstract 50

Shared 41

Intraflow 0

Extraflow 71

Frequency 20

Complexity 50

Location 55

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

FOOTPRINT ARCHITETTURA 1 (3 di 3) (Non adottata)Componente Assistente SEG

Abstract 10

Shared 16

Intraflow 0

Extraflow 14

Frequency 10

Complexity 66

Location 10

28

ARCHITETTURA LOGICA 2 (1 di 2) (Adottata)

29

ARCHITETTURA LOGICA 2 (2 di 2) (Adottata)

30

FOOTPRINT ARCHITETTURA 2 (1 di 4) (Adottata)Componente Acquisizione Rilevazione

Abstract 10

Shared 33

Intraflow 0

Extraflow 14

Frequency 10

Complexity 10

Location 10

31

FOOTPRINT ARCHITETTURA 2 (2 di 4) (Adottata)Componente Identificazione SEP

Abstract 10

Shared 42

Intraflow 25

Extraflow 14

Frequency 10

Complexity 100

Location 10

32

FOOTPRINT ARCHITETTURA 2 (3 di 4) (Adottata)Componente Notifica

Abstract 10

Shared 25

Intraflow 25

Extraflow 57

Frequency 10

Complexity 10

Location 100

33

FOOTPRINT ARCHITETTURA 2 (4 di 4) (Adottata)Componente Assistente SEG

Abstract 10

Shared 16

Intraflow 0

Extraflow 14

Frequency 10

Complexity 66

Location 10

34

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

35

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

36

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

37

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

38

ARCHITETTURA CONCRETA (5 di 6) (Non adottata)

Deployment 1

39

ARCHITETTURA CONCRETA (6 di 6) (Adottata)

Deployment 2

40

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

41

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

42

PS-Light-2Intervallo di misurazione: 0-10 m, 0-20 m, 0-40 m, 0-70 mTemperatura di funzionamento: da -20C° a +50C°Output: RS 232 (seriale)Intervallo di misurazione: programmabile da 1 min in suSEBA - Data LoggerSalvataggio misurazione: nell’immediatoMemoria flash: 4MB per circa 280 000 misurazioniAlimentazione: batteria da 12VSlot SIM-CARD, modulo GPRS incluso

PREZZO: 1300€ per sensore

SCELTE TECNOLOGICHE (3 di 4)Server centrale: HP ProLiant BL460c

43

CPU: Intel Xeon E5-2650V2 2.6GHz 8 core Cache 20MBRAM: 32GB DDR3 SDRAM 1866MHz (espandibile fino a 256GB)Hard Disk: 3TB Serial ATA III 3,5” 6GB/sec

PREZZO: 3414€

SCELTE TECNOLOGICHE (4 di 4)Dispositivo Operatori a campo: Moto G 2014

44

CPU: Qualcomm Snapdragon Quadcore 1,2GHzRAM: 1GB LPDDR3 RAMStorage: 8GB (espandibile con microSD)Batteria: 2070 mAh Li-ionDisplay: 5” 1280x720 (294 ppi)Rete: GSM, GPRS + EDGE, UMTS, HSPA+Camera: 8MPOperating System: Android 5 Lollipop

PREZZO: 199€

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 circa2: 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.

Prezzo Quantità Totale

Sensore 1300 € 1001 130000 €

Costi installazione 3502 € 100 35000 €

Server 3414 € 1 3414 €

Sviluppo Server

30 €/h5 persone,

8 ore al giorno, 5 mesi

132000 €

Mobile 199 € 50 9950 €

Sviluppo App Mobile 40 €/h 2 persone, 8 h al

giorno, 2 settimane 6400 €

Totale 316764* €

RIEPILOGO COSTI (2 di 3)Costi eventuali e mensili

46

PrezzoQuantit

à Dettagli Totale

Traffico Dati

Sensore9 € 1001 1GB (Vodafone Micro) 900 €

Traffico Operatori a

Campo22,9 € 50

400 min, 400 SMS, 1GB (Vodafone RAM

Mini)1145 €

Manutenzione

Sensori40 €/h

8 h x 5 giorni

20€ a persona, ogni 3-4 mesi 1600 €

Manutenzione

Sistema30 € 3

Costo relativo a un eventuale guasto 90 €

Totale 3735 €

RIEPILOGO COSTI (3 di 3)Costo Software

Prezzo Descrizione

Sistema Operativo Server 279 € Windows 8.1 Enterprise 64 Bit

Licenza DataBase 5000€/annoMySQL Enterprise

Edition1

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

ARCHITETTURA DEI DATI

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

REVERSE ENGENEERING (2 di 4)BRI: Modello Concettuale

50

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

REVERSE ENGINEERING (4 di 4)BDM: Modello Concettuale

52

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

DATA INTEGRATION (2 di 15)Eterogeneità e Corrispondenza Interschema

Durante l’attività di Data Integration sono sorte le seguenti eterogeneità:

Tipo Eterogenei

tà

Relazioni Coinvolte

Attributo 1 Attributo 2 Dettagli

Omonimia BDM.VentoBRI.Rilevazione

VelocitaAttuale

VelocitaAttuale

Unità di misura

SinonimiaBDM.Postazione

BRI.Area-Quadrata

Latitudine LatNEStesso

concetto, nomi diversi

SinonimiaBDM.Postazione

BRI.Area-Quadrata

Latitudine LatSOStesso

concetto, nomi diversi

SinonimiaBDM.Postazione

BRI.Area-Quadrata

Longitudine LongNEStesso

concetto, nomi diversi

54

DATA INTEGRATION (3 di 15)Eterogeneità e Corrispondenza Interschema

Durante l’attività di Data Integration sono sorte le seguenti eterogeneità:

Tipo Eterogenei

tà

Relazioni Coinvolte

Attributo 1 Attributo 2 Dettagli

SinonimiaBDM.VentoBRI.Rilevazione Longitudine LongSO

Stesso concetto,

nomi diversi

55

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 1 Attributo 2

Dettagli

Corrispondenza Funzionale

BDM.PrevisioneBRI.Rilevazione Data_Ora

TimeStamp

Data_Ora = TimeStamp + 20 * 60 *

1000

AggregazioneBDM.Area-Quadrata

BRI.Postazione- -

Area-Quadrata è un’aggregazione di Postazione

56

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

57

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

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.LatNE AND P.Longitudine < AQ.LongNE AND P.Latitudine > AQ.LatSO AND P.Longitudine > AQ.LongSO

59

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.LatNE AND S.Longitudine < AQ.LongNE AND S.Latitudine > AQ.LatSO AND S.Longitudine > AQ.LongSO)

60

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

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

compatibile

62

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

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

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 PercentualeFROM BRI.GrafoFiumi AS GF

65

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

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 LongitudineFROM BDM.AreaQuadrata AS AQWHERE 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

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

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

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

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