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
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.
3.
L’acquisizione di segnalazioni di emergenze gravi SEG
(esondazione in atto o a forte rischio) da parte di
operatori a campo
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
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
possa
verificarsi
Assunzioni adottate
(2 di 3)
5.
6.
7.
8.
9.
Il sensore è ancorato sul letto del fiume
Gli operatori a campo sono componenti delle
Squadre di Emergenza
Gli operatori sono inviati sul posto dalle Squadre
di Emergenza, e non dal sistema
Un operatore a campo si dirige in prossimità del
sensore su indicazione della Squadra
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
Supponendo di integrare i componenti IdentificazioneSEP e Notifica, ci si
accorge dal footprint che non è una soluzione ottimale: per questo abbiamo
deciso di separarli
Abstract
50
Shared
41
Intraflow
0
Extraflow
71
Frequency
20
Complexity
50
Location
55
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
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
42
SCELTE TECNOLOGICHE (3 di 4)
Server centrale: HP ProLiant BL460c
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€
43
SCELTE TECNOLOGICHE (4 di 4)
Dispositivo Operatori a campo: Moto G 2014
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€
44
RIEPILOGO COSTI (1 di 3)
Costi fissi
Prezzo
Quantità
Totale
Sensore
1300 €
1001
130000 €
Costi installazione
3502 €
100
35000 €
Server
3414 €
1
3414 €
Sviluppo Server
30 €/h
5 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 €
316764* €
Totale
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.
45
RIEPILOGO COSTI (2 di 3)
Costi eventuali e mensili
Prezzo Quantità
Traffico Dati
Sensore
Traffico
Operatori a
Campo
9€
22,9 €
Manutenzion
40 €/h
e Sensori
Manutenzion
e
Sistema
30 €
Dettagli
Totale
1001
1GB (Vodafone Micro)
900 €
50
400 min, 400 SMS, 1GB
(Vodafone RAM Mini)
1145 €
8hx5
giorni
20€ a persona, ogni
3-4 mesi
1600 €
3
Costo relativo a un
eventuale guasto
90 €
3735 €
Totale
46
RIEPILOGO COSTI (3 di 3)
Costo Software
Prezzo
Descrizione
279 €
Windows 8.1
Enterprise 64 Bit
5000€/anno
MySQL Enterprise
Edition1
Sistema Operativo Server
Licenza DataBase
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
REVERSE ENGENEERING (1 di 4)
BRI: Modello Logico
Postazione(Latitudine, Longitudine, Rischio,
CapienzaMax, Localita)
Sensore(idSensore, Latitudine, Longitudine)
GrafoFiumi(idSensore1, idSensore2, Percentuale,
Distanza)
Rilevazione(idSensore, PortataAttuale, VelocitaAttuale,
TimeStamp)
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
Eterogeneità
Relazioni
Coinvolte
Omonimia
BDM.Vento
BRI.Rilevazione
Sinonimia
Sinonimia
Sinonimia
BDM.Postazione
BRI.Area-Quadrata
BDM.Postazione
BRI.Area-Quadrata
BDM.Postazione
BRI.Area-Quadrata
Attributo 1
Attributo 2
VelocitaAttuale VelocitaAttuale
Latitudine
Latitudine
Longitudine
54
Dettagli
Unità di
misura
LatNE
Stesso
concetto, nomi
diversi
LatSO
Stesso
concetto, nomi
diversi
LongNE
Stesso
concetto, nomi
diversi
DATA INTEGRATION (3 di 15)
Eterogeneità e Corrispondenza Interschema
Durante l’attività di Data Integration sono sorte le seguenti eterogeneità:
Tipo
Eterogeneità
Sinonimia
Relazioni
Coinvolte
BDM.Vento
BRI.Rilevazione
Attributo 1
Longitudine
55
Attributo 2
Dettagli
LongSO
Stesso
concetto, nomi
diversi
DATA INTEGRATION (4 di 15)
Eterogeneità e Corrispondenza Interschema
Durante l’attività di Data Integration sono sorte le seguenti corrispondenze interschema:
Tipo
Corrispondenza
Interschema
Corrispondenza
Funzionale
Aggregazione
Relazioni
Coinvolte
Attributo 1
BDM.Previsione
BRI.Rilevazione
Data_Ora
BDM.Area-Quadrata
BRI.Postazione
56
-
Attributo 2
Dettagli
Data_Ora =
TimeStamp TimeStamp +
20 * 60 * 1000
-
Area-Quadrata
è
un’aggregazione
di Postazione
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,
Distanza, Percentuale) AS
idSensore2,
SELECT GF.idSensore1 AS idSensore1, GF.idSensore2
AS idSensore2, GF.Distanza AS Distanza, GF.Percentuale
AS
Percentuale
FROM 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
queryèèsupportata
supportatadalla
dalla
maggior
parte
database:
La seguente
seguente query
maggior
parte
dei dei
database:
SELECT AQ.Latitudine AS Latitudine, AQ.Longitudine AS
SELECT AQ.Latitudine AS Latitudine, AQ.Longitudine AS
Longitudine
FROM
BDM.AreaQuadrata AS AQ
Longitudine
WHERE AQ.idCella = 764
FROM BDM.AreaQuadrata AS AQ
WHERE AQ.idCella = 764
67
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