Sistema di osservazione del comportamento degli automobilisti Progetto di Architetture del software e dei dati 2015/2016 Alessandro Banfi 743464 Camillo.

Presentazione sul tema: "Sistema di osservazione del comportamento degli automobilisti Progetto di Architetture del software e dei dati 2015/2016 Alessandro Banfi 743464 Camillo."— Transcript della presentazione:

1 Sistema di osservazione del comportamento degli automobilisti Progetto di Architetture del software e dei dati 2015/2016 Alessandro Banfi 743464 Camillo Ghelfi 742752 Cristian Narro Paredes 736193 Jorge Rodriguez Martinez 707431

2 Il problema Si deve realizzare un sistema di Osservazione del Comportamento degli Automobilisti (OCA) che consenta a una Compagnia di assicurazione di monitorare il comportamento degli automobilisti assicurati per ridefinire le polizze in base al livello di rischio di ciascun assicurato e per fornire assistenza in caso di sinistro. Sui veicoli degli assicurati sono presenti: Un sensore di accelerazione ACC (accelerometro). Un sensore di velocità TAC (tachimetro). Un sensore GPS. E’ possibile accedere a due Basi Dati esterne preesistenti: Una Base Dati Geografica (BDG) che contiene la descrizione della rete viaria e in particolare, per ciascuna strada, la tipologia T (urbano, extraurbano, autostrada) e l’eventuale limite di velocità. Per semplicità, si può (ma non è obbligatorio!) assumere che i limiti di velocità siano fissati per ciascun tipo di strada (esempio: 50, 90, 130). Una Base Dati Assicurati (BDA) che contiene l’anagrafica degli assicurati, le relative polizze e le denunce di sinistro. Si consideri che un assicurato può avere più polizze corrispondenti a veicoli diversi. Gli operatori della Compagnia svolgono due funzioni: Organizzazione dell’assistenza in caso d’incidente. Ridefinizione, ala scadenza di ogni polizza, del premio di assicurazione in base al livello di rischio dell’assicurato calcolato sull’ultimo anno. Questa attività deve poter essere svolta in remoto. 2

3 Requisiti funzionali Il sistema OCA deve essere in grado di: 1.Supportare l’assistenza immediata in caso di sinistri, svolgendo le seguenti funzioni: a.Riconoscimento di eventuali sinistri (collisioni); b.Notifica all’operatore competente delle informazioni necessarie per organizzare l’assistenza; c.Attivazione di una connessione telefonica tra operatore e assicurato coinvolto. 2.Determinare per ciascuna polizza su base annuale: a.Il chilometraggio totale K; b.La velocità media V per ciascuna tipologia T di tronco viario; c.Il livello di prudenza P, definito come la percentuale di chilometri percorsi rispettando i limiti di velocità con una tolleranza di 10 km/h. 3.Calcolare il livello di rischio R di ciascun assicurato come R = f(K, V, P, E, D, C), dove K, V, P sono cumulativi per tutte le polizze dell’assicurato, E è l’età dell’assicurato, D il numero di denunce sinistro nell’ultimo anno e C il Comune di residenza. Il livello di rischio R può assumere valori discreti da 1 a 10. Non si chiede di definire il dettaglio algoritmico della funzione f. 4.Consentire all’operatore competente di visualizzare, per ciascun assicurato e per ciascuna polizza, le attuali condizioni di polizza e il livello di rischio dell’assicurato. 3

4 Requisiti non funzionali In caso venga rilevata una collisione, il sistema deve dare massima priorità alla procedura di gestione delle emergenze. Dal momento in cui viene effettivamente rilevata una collisione, al momento in cui il sistema inizia la procedura di notifica all’operatore, non deve trascorrere un tempo superiore a 1 s. Il sistema deve mantenere in una memoria locale di ciascun veicolo (scatola nera) lo storico delle collisioni rilevate negli ultimi 4 anni. La stessa informazione deve essere mantenuta nello stesso periodo di tempo in una locazione centralizzata. I dati di telemetria ricevuti dai veicoli devono essere memorizzati in una locazione centralizzata per un periodo di tempo di 2 anni. È necessario ottenere un valore utile 1 di accelerazione (per effettuare il successivo rilevamento di collisione) ogni 500 ms. È necessario ottenere un valore utile di velocità (per effettuare il successivo rilevamento di collisione) ogni 1 s. L’algoritmo di rilevamento collisioni utilizzerà sia i dati accelerometrici sia quelle relativi alla velocità per ottenere massima precisione. Esso sarà eseguito ogni 1 s. I dati telemetrici verranno trasmessi dai veicoli ogni 30 s. La trasmissione dei dati telemetrici avverrà solo a veicolo in effettivo movimento (se un veicolo rimane per più di 30 secondi nella medesima posizione, al successivo ciclo di trasmissione i dati telemetrici non saranno trasmessi). 4 1. Con valore si intende un valore privo di rumore. Viene ottenuto eseguendo la media di una sequenza di campionamenti successivi.

5 Ulteriori assunzioni Il dispositivo di rilevazione al veicolo può essere sia integrato nel veicolo stesso oppure aggiunto in un secondo momento dall’utente come elemento esterno. In ogni caso l’alimentazione primaria del dispositivo è ottenuta dalla rete elettrica del veicolo (nel caso di elemento esterno sarà richiesta un installazione da personale autorizzato). Il dispositivo è in genere dotato di hardware per consentire una comunicazione vocale tra gli occupanti del veicolo e la centrale operativa per la gestione delle emergenze. Tuttavia tale funzione potrebbe essere svolta tramite lo smartphone dell’utente, anche se tale soluzione garantisce minore sicurezza. Il dispositivo è dotato di una batteria di backup che consente un funzionamento in autonomia per circa 15/20 minuti dal distacco dell’alimentazione principale; tale precauzione è necessaria in situazioni di emergenza (scontro violento, ecc.). Ogni dispositivo può essere dotato di un comando a pulsante che permette a un occupante del veicolo di mettersi in contatto telefonico con la centrale operativa in qualsiasi momento. La gestione delle emergenze può essere svolta da un ente terzo rispetto alla compagnia assicurativa (ma anche dalla stessa). Non necessariamente ad una collisione corrisponde l’avvio di una gestione di sinistro. Per dimensionare correttamente il sistema si presuppone che la compagnia di assicurazioni utilizzatrice (dimensioni medio/piccole) abbia le seguenti caratteristiche:  Mediamente 500.000 assicurati.  Una media di due veicoli (polizze) per assicurato.  500 addetti aventi a carico 1.000 assicurati ciascuno.  La compagnia è operante solo sul territorio nazionale italiano. 5

6 Architettura del problema 6

7 Attori 7 NomeDescrizione Occupante veicoloPersona fisica che si trova all’interno del veicolo (può essere anche il conducente ma non necessariamente). Apparato rilevazioneInsieme dei sensori (ACC, TAC, GPS) localizzati fisicamente sul veicolo CAInsieme delle competenze interne della compagnia assicurativa: gestione clienti, polizze e sinistri. Operatore emergenzeOperatore che viene notificato in caso di emergenza e si occupa della gestione della stessa. Non necessariamente direttamente collegato alla compagnia assicurativa. BDGBase Dati Geografica (sistema esterno) BDABase Dati Assicurati (sistema esterno)

8 Casi d’uso 8

9 Modello dei dati 9

10 Diagramma di attività rilevazione velocità 10

11 Diagramma di attività rilevazione accelerazione 11

12 Diagramma di attività trasmissione dati telemetrici 12

13 Diagramma di attività rilevazione collisione 13

14 Diagramma di attività richiesta soccorso 14

15 Diagramma di attività ricezione dati telemetrici 15

16 Diagramma di attività organizzazione assistenza collisione 16

17 Diagramma di attività visualizzazione dati assicurato 17

18 Diagramma di attività visualizzazione polizze in scadenza 18

19 Diagramma di attività ridefinizione premio assicurativo 19

20 Diagramma di attività calcoli annuali 20

21 Architettura logica 21

22 Organizzazione generale dei componenti 22 Sottosistema assicurazione Gestore dati assicurato Gestore scadenzario polizze Gestore calcolo livello di rischio Gestore premio assicurativo Sottosistema assicurazione Gestore dati assicurato Gestore scadenzario polizze Gestore calcolo livello di rischio Gestore premio assicurativo Sottosistema monitoraggio veicolo Gestore emergenze Gestore ricezione telemetria Sottosistema monitoraggio veicolo Gestore emergenze Gestore ricezione telemetria Sottosistema veicolo Gestore acquisizione accelerazione Gestore acquisizione velocità Gestore rilevazione collisioni Gestore trasmissione telemetria Gestore richieste assistenza Sottosistema veicolo Gestore acquisizione accelerazione Gestore acquisizione velocità Gestore rilevazione collisioni Gestore trasmissione telemetria Gestore richieste assistenza È stata assegnata una priorità di esecuzione ad ogni componente presente nel dispositivo ComponentePriorità Gestore rilevazione collisioni1 Gestore richieste assistenza2 Gestore acquisizione accelerazione3 Gestore acquisizione velocità4 Gestore trasmissione telemetria5

23 Diagramma dei componenti 23

24 Diagramma dei componenti 24

25 Diagramma dei componenti 25

26 Diagramma dei componenti 26

27 Diagramma dei componenti 27

28 Diagramma dei componenti 28

29 Diagramma dei componenti 29

30 Diagramma dei componenti 30

31 Diagramma dei componenti 31

32 Footprint gestore acquisizione accelerazione 32

33 Footprint gestore acquisizione velocità 33

34 Footprint gestore rilevazione collisioni 34

35 Footprint gestore trasmissione telemetria 35

36 Footprint gestore richieste assistenza 36

37 Footprint gestore emergenze 37

38 Footprint gestore ricezione telemetria 38

39 Footprint gestore dati assicurato 39

40 Footprint gestore scadenzario polizze 40

41 Footprint gestore calcolo livello di rischio 41

42 Footprint gestore premio assicurativo 42

43 Architettura concreta 43

44 Interazione tra componenti 44

45 Interazione tra componenti 45

46 Interazione tra componenti 46

47 Design interno componenti 47

48 Gestore acquisizione accelerazione 48 Stateful sequential executor (single instance): il componente è eseguito in un loop infinito. Durante la sua esecuzione mantiene uno stato interno osservabile nel tempo. Inoltre, esiste una singola copia del componente per ogni dispositivo di rilevazione.

49 Gestore acquisizione velocità 49 Stateful sequential executor (single instance): il componente è eseguito in un loop infinito. Durante la sua esecuzione mantiene uno stato interno osservabile nel tempo. Inoltre, esiste una singola copia del componente per ogni dispositivo di rilevazione.

50 Gestore rilevazione collisione 50 Stateful sequential executor (single instance): il componente è eseguito in un loop infinito. Durante la sua esecuzione mantiene uno stato interno osservabile nel tempo. Inoltre esiste una singola copia del componente per ogni dispositivo di rilevazione. Siccome la frequenza di esecuzione del componente è elevata, sarebbe computazionalmente costoso istanziare un nuovo thread ogni volta che l’esecuzione è richiesta.

51 Gestore trasmissione telemetria 51 Stateful sequential executor (single instance): il componente è eseguito in un loop infinito. Durante la sua esecuzione mantiene uno stato interno osservabile nel tempo. Inoltre esiste una singola copia del componente per ogni dispositivo di rilevazione. Siccome la frequenza di esecuzione del componente è elevata, sarebbe computazionalmente costoso istanziare un nuovo thread ogni volta che l’esecuzione è richiesta.

52 Gestore richieste assistenza 52 One-shot stateless: è una operazione che viene eseguita su richiesta dell’utente con frequenza molto bassa. È quindi sensato istanziare un nuovo thread ogni qualvolta è necessario.

53 Gestore emergenze 53 Concurrent executor stateless: il processo di ricezione dei messaggi è sempre attivo e crea un nuovo thread di esecuzione per ogni richiesta di emergenza. Questo consente di non dover istanziare un nuovo processo a ogni richiesta (maggiore latenza di esecuzione).

54 Gestore ricezione telemetria 54 Farm concurrent executor: Dimensionando correttamente il numero di istanze nella Farm si ottiene un corretto throughput di sistema. Tuttavia anche se in un dato istante tutte le istanze dovessero essere occupate, è accettabile che una richiesta di archiviazione dati telemetrici sia accodata e successivamente gestita entro un massimo di poche decine di secondi.

55 Gestore dati assicurato 55 Concurrent executor stateless: il processo di ricezione dei messaggi è sempre attivo e crea un nuovo thread di esecuzione per ogni richiesta di emergenza. Questo consente di non dover istanziare un nuovo processo a ogni richiesta (maggiore latenza di esecuzione).

56 Gestore scadenzario polizze 56 Concurrent executor stateless: il processo di ricezione dei messaggi è sempre attivo e crea un nuovo thread di esecuzione per ogni richiesta di emergenza. Questo consente di non dover istanziare un nuovo processo a ogni richiesta (maggiore latenza di esecuzione).

57 Gestore calcolo livello di rischio 57 Farm concurrent executor: Dimensionando correttamente il numero di istanze nella Farm si ottiene un corretto throughput di sistema. Tuttavia anche se in un dato istante tutte le istanze dovessero essere occupate, è accettabile che una richiesta di calcolo sia accodata e successivamente gestita entro un massimo di poche decine di secondi.

58 Gestore premio assicurativo 58 Farm concurrent executor: Dimensionando correttamente il numero di istanze nella Farm si ottiene un corretto throughput di sistema. Tuttavia anche se in un dato istante tutte le istanze dovessero essere occupate, è accettabile che una richiesta di calcolo sia accodata e successivamente gestita entro un massimo di poche decine di secondi.

59 Architettura di deployment 59

60 Diagramma di deployment Soluzione in cloud (quella scelta) 60

61 Diagramma di deployment Soluzione on premises 61

62 Diagramma di deployment Device veicolo 2 62 La suddivisione in componenti distinti di rilevazione velocità, rilevazione accelerazione, rilevamento collisione e trasmissione dati telemetrici consente di distribuire anche a livello fisico questa attività su differenti nodi di computazione, tutti situati nel contesto del device veicolo. In tal modo è possibile utilizzare microcontrollori più microcontrollori semplici (quindi meno costosi) interconnessi tra loro tramite BUS. Tuttavia per il caso in questione non è stata effettuata tale scelta.

63 Scelte tecnologiche 63

64 Device veicolo La scelta principale da compiere consiste nel utilizzare un prodotto del mercato già costruito per lo scopo (rilevazione/trasmissione dati telemetrici da veicolo) oppure realizzare una soluzione custom. Per quanto riguarda il nostro caso di studio, si è optato per la seconda scelta in quanto garantisce maggiore flessibilità nella scelta dei componenti HW/SW. Tuttavia segnaliamo la presenza del dispositivo TBOX di Magneti Marelli. (Non sono reperibili informazioni su Internet relativamente ai costi). 64

65 Device veicolo (HW) Per l’unità di elaborazione centrale del dispositivo si è scelta l’unità Intel Quark X1000 SoC (System on Chip), ovvero un intero sistema di elaborazione completo incluso in un singolo chip: CPU x86 compatibile con set di istruzioni IA-32 Pentium Clock 400 Mhz Memoria centrale RAM DDR3 fino a 2G (256 MB potrebbero essere sufficienti per il nostro scenario) Interfacce di comunicazione integrate GPIO/I2C/UART/SPI/PCIe/Ethernetx2/USB/SDIO Basso consumo (ideale per applicazioni IoT) RTC (Real Time Clock) Prototipazione tramite scheda di sviluppo Intel Galileo (Gen2) Sistema operativo ed applicazioni saranno caricati da una memoria di massa di tipo SD (dimensione 2 GB). Costo unitario : 10 Dollari circa per grandi volumi. 65

66 Device veicolo (HW) La comunicazione fisica tra device e sistemi server avverrà mediante tecnologia 2G/3G. Per dotare il sistema di questa possibilità è possibile utilizzare un scheda adattatore. Esistono svariati modelli di differenti produttori. Per il nostro sistema è stato individuato il chip AirPrime HL8548 di Sierra Wireless che consente comunicazione 2G/3G globale (five-band) ed inoltre include un ricevitore GNSS per poter ricevere i dati di posizione via satellite in tutto il globo. La comunicazione con il SoC Quark avviene mediante interfaccia UART/USB. In questo modo la comunicazione cellulare e la ricezione dei dati di geolocalizzazione sono effettuati da un unico dispositivo fisico. Costo unitario : 30 Dollari su grandi volumi. 66

67 Device veicolo (HW) Il sensore accelerometrico scelto è l'NXP FXLS8471Q, accelerometro digitale a 3 assi, 14 bit risoluzione, interfacce I2C/SPI, fino a +- 8g. ODC (Output Data Rate) massimo di 800Hz (un nuovo valore ogni 1,25 ms). Costo unitario: 0,50 Dollari per grandi volumi. 67

68 Device veicolo (HW) Per quanto riguarda il sensore di velocità è possibile impiegare tre soluzioni differenti: È possibile emulare il sensore in software utilizzando i dati accelerometrici (alta precisione ma richiede ulteriore computazione algoritmica). È possibile ottenere la velocità dai dati direttamente da satellite GNSS (scarsa precisione e bassa frequenza di aggiornamento). È possibile ottenere la velocità direttamente dalla centralina del veicolo (richiede adattatore hardware/software per protocollo CAN). Costo unitario adattatore seriale: 30 Dollari per grandi volumi. 68

69 Device veicolo (SW) Il sistema operativo scelto è Wind River Rocket: Hard real-time core Pieno supporto per Intel Quark SoC Supporto per networking TCP/IP Free software Sviluppata appositamente per soluzioni IoT (Internet of Things) 69

70 Costo produzione singolo device DeviceCosto Intel Quark X1000 SoC10,00 $ AirPrime HL8548 di Sierra Wireless30,00 $ NXP FXLS8471Q (accelerometro)0,50 $ Adattatore seriale CAN (opzionale)30,00 $ Costi di stampaggio e assemblaggio5,00 $ Totale (senza opzionali)45,50 $ Totale (con opzionali)75,50 $ 70 Per volumi più grandi probabilmente è consentito un risparmio fino a 10/15 $. Costo totale produzione (500.000 unità) 22.750.000 $

71 Device veicolo (SW) Il protocollo di comunicazione applicativo utilizzato per l’interazione tra device e server è MQTT (Message Queue Telemetry Transport) Ottimizzato per device con scarse capacità computazionali. Supporta i livelli di QoS (Quality of Service) per la consegna affidabile di dati. Stack TCP/IP Ottimizzato per applicazioni IoT. Ampia disponibilità di librerie client per dispositivi embedded. Possibilità di cifrare la comunicazione con protocollo TLS/SSL. 71

72 Ricezione dati telemetrici Esistono svariate piattaforme cloud per la gestione/comunicazione con dispositivi IoT. Per l’applicazione in questione è stata scelta Amazon AWS IoT Gateway: Gestisce fino a milioni di dispositivi. Supporta protocollo MQTT (lato server). Integrato nell’ecosistema cloud AWS di Amazon. Costo stimato: 5 Dollari per milioni di messaggi/mese 72

73 Ricezione dati telemetrici costi 1 veicolo produce 1 messaggio telemetrico ogni 30 secondi. 120 messaggi / ora. Mediamente 1 veicolo funziona per 2 ore / giorno. 240 messaggi al giorno prodotti da ciascun veicolo. 7.200 messaggi al messaggi al mese prodotti da ciascun veicolo. 5 $ per millioni di messaggi al mese. Costo mensile per veicolo: (7.200 * 5) / 10 6 = 0.036 $ Ipotizzando di avere mediamente 2 veicoli per assicurato il costo totale mensile è di 36.000 $. 73 Costo annuale ricezione dati telemetrici 432.000 $

74 Sistema centrale Nodi di computazione servizio cloud: IaaS (Infrastracture as a Service) AWS (Amazon Web Services). Se non vi sono particolari esigenze o vincoli sulla locazione fisica dei dati l’architettura cloud comporta una serie di vantaggi: possibilità di utilizzare la futura piattaforma di produzione a partire dalle prime fasi di sviluppo; possibilità di disporre di una vasta serie di tecnologie hardware e software basate sul paradigma pay-as-you-go (bassi costi di adozione commisurati all’utilizzo); disponibilità di utilizzare tecnologie già ottimizzate all’ambito applicativo richiesto, diminuendo in tal modo per gli addetti ai lavori le possibili fonti di incertezza iniziale/barriere all’entrata (miglioramento della curva di apprendimento); presenza di meccanismi impliciti di ridondanza dei dati; possibilità di scalare più facilmente, senza vincoli di tempo o di costo dell’infrastruttura hardware; radicale diminuzione dei costi di manutenzione dell’hardware e ricollocazione del personale preposto a tali operazioni di gestione. Per la gestione della base di dati la scelta è ricaduta sul sistema NoSQL documentale MongoDB; disposto secondo un replica set di 3 nodi (un nodo master gestore di scritture e letture e due nodi slave) istanziata su macchina EC2 c3.4xlarge consente di gestire una mole di dati di circa 2 TB in totale. Periodo di conservazione di dati telemetria dei veicoli: 2 anni dall’inserimento (nell’ordine di circa 620 GB annuali). Periodo di conservazione di dati collisioni: 4 anni (nell’ordine di 270 MB annuali). 74

75 Sistema centrale La successiva tabella mostra i costi per mese/anno delle macchine EC2 indicate a regime (nella situazione in cui, a seguito di 4 anni dalla messa in produzione, i dati telemetrici relativi alla base di dati più vecchi risalgano a due anni prima di quelli di nuovo inserimento). Per quanto riguarda la parte di gestione del calcolo del livello di rischio sulla base dei dati telemetrici archiviati nell’anno di decorrenza della polizza, le scelte tecnologiche effettuate risultano essere le seguenti: un’istanza di m3.xlarge (equipaggiata di 4 CPU, 15 GB di RAM, 2 x 40 GB SSD, sistema operativo linux con server ngnix): server web in grado di fornire il livello di rischio ed il relativo premio assicurativo sulla base dei dati telemetrici archiviati per un dato veicolo; 2 istanze di m3.large (equipaggiata di 2 CPU, 7.5 GB di RAM, 1 x32 GB SSD, sistema operativo linux con server ngnix quale reverse proxy) il cui funzionamento, come per i precedenti nodi dello stesso tipo, è quello di reverse proxy per favorire una più veloce erogazione del servizio relativamente alle richieste di fruizione di informazioni e calcolo valori per l’applicazione di tipo CRM ad uso degli assicuratori (circa 5000 agenti sul suolo italiano ognuno dei quali con un portafoglio di 1000 clienti). 75 Costo mensileCosto annuale 2.827 $33.930 $ Tipologia istanzaCosto orarioCosto mensileCosto annuale M3.xlarge0,315 $226,80 $2759,40 $ 2 x M3.large0,158 $227,52 $2768,16 $

76 Sistema centrale La seguente tabella riassume i costi totali mensili e annuali: 76 Costo totale mensileCosto totale annuale 39.282 $471.460 $

77 Architettura dei dati 77

78 Virtual Data Integration 78 OCB SLL BDASLL OCB SCL BDASCL OCB Reverse Engineering SCG SLG Progettazione Logica Integrazione Schemi BDV

79 Schema logico locale BDA Assicurato (idAssicurato, nome, cognome, dataNascita, cf, sesso, indirizzoResidenza, comuneResidenza, provinciaResidenza, comuneNascita, provinciaNascita, livelloRischio) MezzoDiTrasporto (targa, categoria, marca, modello, dataImmatricolazione, alimentazione, cilindrata, potenzaCv, potenzaKw) Polizza (idPolizza, dataSottoscrizione, dataScadenza, periodoValidità, classe, premio, livelloPrudenza, targaVeicolo, idAssicurato) Sinistro (idSinistro, targa, data, ora, indirizzo, comune) 79

80 Schema concettuale locale BDA 80

81 Schema logico locale OCB Comune (nome, provincia) Veicolo (targa, categoria, tipoCarburante) Collisione (timestamp, targa, classeGravità, comune, codiceStrada, km) DatiTelemetriaArchiviati (timestamp, targa, velocità, latitudine, longitudine, altitudine, tipologiaStrada) 81

82 Schema concettuale locale OCB 82

83 Eterogeneità – Corrispondenza Interschema 83 Schema 1 Schema 2 Concetto 1Concetto 2Tipo BDAOCBBDA.Assicurato.comuneResidenza BDA.Assicurato.comuneNascita BDA.Sinistro.comune OCB.ComuneEterogeneità di tipo: coppie di informazioni, rappresentano lo stesso concetto ma hanno forme diverse, nella BDA come attributo e in OCB come entità. Questa eterogeneità si risolve rappresentando l’attributo attraverso l’entità. BDAOCBBDA.MezzoDiTrasporto.alimentazioneOCB.Veicolo.tipoCarburanteEterogeneità di sinonimia: stesso concetto ma nomi diversi. Si risolve rinominando in “alimentazione”. BDAOCBBDA.Sinistro.data BDA.Sinistro.ora OCB.Collisione.timestamp OCB.DatiTelemetriaArchiviati.t imestamp Eterogeneità di tipo: gli attibuti “timestamp” e “data”/”ora” rappresentano la stessa informazione ma hanno forme diverse. Si risolve rappresentano il “timestamp” in due attributi: “data” e “ora” BDAOCBBDA.MezzoDiTrasportoOCB.VeicoloCorrispondenza interschema: il set di attributi di Veicolo è un sottoinsieme del set di attributi di MezzoDiTrasporto e viene risolto unificando gli attributi delle due entità.

84 84 Schema concettuale globale

85 85 Parte relativa alle base dati BDA Parte relativa alla base dati OCB

86 Schema logico globale Comune (nome, provincia) Assicurato (idAssicurato, nome, cognome, dataNascita, cf, sesso, indirizzoResidenza, comuneResidenza, comuneNascita, livelloRischio) Polizza (idPolizza, dataSottoscrizione, dataScadenza, periodoValidità, classe, premio, livelloPrudenza, idAssicurato, targa) Veicolo (targa, categoria, marca, modello, dataImmatricolazione, alimentazione, cilindrata, potenzaCv, potenzaKw) DatiTelemetriaArchiviati (targa, data, ora, velocità, latitudine, longitudine, altitudine, tipologiaStrada) Collisione (targa, data, ora, classeGravità, comune, codiceStrada, km) Sinistro (idSinistro, targa, data, ora, indirizzo, comune) 86

87 CREATE VIEW Comune(nome, provincia) AS SELECT comuneResidenza,provinciaResidenza FROM BDA.Assicurato UNION SELECT comuneNascita, provinciaNascita FROM BDA.Assicurato UNION SELECT comune, provincia FROM OCB.Comune CREATE VIEW Assicurato(idAssicurato, nome, cognome, dataNascita, cf, sesso, indirizzoResidenza, comuneResidenza, comuneNascita, livelloRischio) AS SELECT idAssicurato, nome, cognome, dataNascita, cf, sesso, indirizzoResidenza, comuneResidenza, comuneNascita, livelloRischio FROM BDA.Assicurato CREATE VIEW Polizza(idPolizza, dataSottoscrizione, dataScadenza, periodoValidità, classe, premio, livelloPrudenza, idAssicurato, targa) AS SELECT idPolizza, dataSottoscrizione, dataScadenza, periodoValidità, classe, premio, livelloPrudenza, idAssicurato, targaVeicolo FROM BDA.Polizza 87 Mapping GAV

88 CREATE VIEW Veicolo(targa, categoria, marca, modello, dataImmatricolazione, alimentazione, cilindrata, potenzaCv, potenzaKw) AS SELECT BDA.MezzoDiTrasporto.targa, BDA.MezzoDiTrasporto.categoria, BDA.MezzoDiTrasporto.marca, BDA.MezzoDiTrasporto.modello, BDA.MezzoDiTrasporto.dataImmatricolazione, BDA.MezzoDiTrasporto.alimentazione, BDA.MezzoDiTrasporto.cilindrata, BDA.MezzoDiTrasporto.potenzaCv, BDA.MezzoDiTrasporto.potenzaKw FROM BDA.MezzoDiTrasporto JOIN OCB.Veicolo ON BDA.MezzoDiTrasporto.targa = OCB.Veicolo.targa CREATE VIEW DatiTelemetriaArchiviati(targa, data, ora, velocità, latitudine, longitudine, altitudine, tipologiaStrada) AS SELECT targa, DATE(FROM_UNIXTIME(timestamp)), HOUR(FROM_UNIXTIME(timestamp)), velocità, latitudine, longitudine, altitudine, tipologiaStrada FROM OCB.DatiTelemetriaArchiviati CREATE VIEW Collisione(targa, data, ora, classeGravità, comune, codiceStrada, km) AS SELECT targa, DATE(FROM_UNIXTIME(timestamp)), HOUR(FROM_UNIXTIME(timestamp)), classeGravità, comune, codiceStrada, km FROM OCB.Collisione CREATE VIEW Sinistro(idSinistro, targa, data, ora, indirizzo, comune) AS SELECT idSinistro, targa, data, ora, indirizzo, comune FROM BDA.Sinistro 88

89 Query Q su SLG 89 Query OCB SLL BDA SLL OCB SLG BDV Mediatore Wrapper 1 Wrapper 2 Mapping

90 Query “Ottenere per ogni categoria di veicolo, nome e cognome dell’assicurato che ha riportato più collisioni nella provincia di Milano nell’anno 2014” 90

91 Query non ottimizzata SELECT Assicurato.nome AS nome, Assicurato.cognome AS cognome, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM Assicurato INNER JOIN Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN Collisione ON Veicolo.targa = Collisione.targa INNER JOIN Comune ON Collisione.comune = Comune.nome WHERE Comune.provincia = 'MI' AND (Collisione.data BETWEEN '2014-01-01' AND '2014-12-31') GROUP BY Assicurato.idAssicurato, categoria HAVING (Veicolo.categoria, collisioni) IN ( SELECT conteggio.categoria, MAX(conteggio.collisioni) FROM ( SELECT Assicurato.idAssicurato AS idAssicurato, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM Assicurato INNER JOIN Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN Collisione ON Veicolo.targa = Collisione.targa GROUP BY idAssicurato, categoria ) AS conteggio GROUP BY conteggio.categoria ) 91

92 Unfolding SELECT Assicurato.nome AS nome, Assicurato.cognome AS cognome, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM (SELECT * FROM BDA.Assicurato) AS Assicurato INNER JOIN (SELECT * FROM BDA.Polizza) AS Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN (SELECT BDA.MezzoDiTrasporto.* FROM BDA.MezzoDiTrasporto JOIN OCB.Veicolo ON BDA.MezzoDiTrasporto.targa = OCB.Veicolo.targa) AS Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN ( SELECT targa, DATE(FROM_UNIXTIME(timestamp)) AS data, HOUR(FROM_UNIXTIME(timestamp)) AS ora, classeGravità, comune, codiceStrada, km FROM OCB.Collisione ) AS Collisione ON Veicolo.targa = Collisione.targa INNER JOIN ( SELECT comuneResidenza AS nome, provinciaResidenza AS provincia FROM BDA.Assicurato UNION SELECT comuneNascita AS nome, provinciaNascita AS provincia FROM BDA.Assicurato UNION SELECT comune AS nome, provincia FROM OCB.Comune) AS Comune ON Collisione.comune = Comune.nome WHERE Comune.provincia = 'MI' AND (Collisione.data BETWEEN '2014-01-01' AND '2014-12-31') GROUP BY Assicurato.idAssicurato, categoria HAVING (Veicolo.categoria, collisioni) IN 92

93 Unfolding (cont.) ( SELECT conteggio.categoria, MAX(conteggio.collisioni) FROM ( SELECT Assicurato.idAssicurato AS idAssicurato, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM (SELECT * FROM BDA.Assicurato) AS Assicurato INNER JOIN (SELECT * FROM BDA.Polizza) AS Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN (SELECT BDA.MezzoDiTrasporto.* FROM BDA.MezzoDiTrasporto JOIN OCB.Veicolo ON BDA.MezzoDiTrasporto.targa = OCB.Veicolo.targa) AS Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN ( SELECT targa, DATE(FROM_UNIXTIME(timestamp)) AS data, HOUR(FROM_UNIXTIME(timestamp)) AS ora, classeGravità, comune, codiceStrada, km FROM OCB.Collisione ) AS Collisione ON Veicolo.targa = Collisione.targa GROUP BY idAssicurato, categoria ) AS conteggio GROUP BY categoria ) 93

94 Query ottimizzata SELECT Assicurato.nome AS nome, Assicurato.cognome AS cognome, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM Assicurato INNER JOIN Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN Collisione ON Veicolo.targa = Collisione.targa GROUP BY Assicurato.idAssicurato, categoria HAVING (Veicolo.categoria, collisioni) IN ( SELECT conteggio.categoria, MAX(conteggio.collisioni) FROM ( SELECT Assicurato.idAssicurato AS idAssicurato, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM Assicurato INNER JOIN Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN Collisione ON Veicolo.targa = Collisione.targa INNER JOIN Comune ON Collisione.comune = Comune.nome WHERE Comune.provincia = 'MI' AND (Collisione.data BETWEEN '2014-01-01' AND '2014-12-31') GROUP BY idAssicurato, categoria ) AS conteggio GROUP BY conteggio.categoria ) 94

95 Unfolding ottimizzato SELECT Assicurato.nome AS nome, Assicurato.cognome AS cognome, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM (SELECT * FROM BDA.Assicurato) AS Assicurato INNER JOIN (SELECT * FROM BDA.Polizza) AS Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN (SELECT BDA.MezzoDiTrasporto.* FROM BDA.MezzoDiTrasporto JOIN OCB.Veicolo ON BDA.MezzoDiTrasporto.targa = OCB.Veicolo.targa) AS Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN ( SELECT targa, DATE(FROM_UNIXTIME(timestamp)) AS data, HOUR(FROM_UNIXTIME(timestamp)) AS ora, classeGravità, comune, codiceStrada, km FROM OCB.Collisione ) AS Collisione ON Veicolo.targa = Collisione.targa GROUP BY Assicurato.idAssicurato, categoria HAVING (Veicolo.categoria, collisioni) IN 95

96 Unfolding ottimizzato (cont.) ( SELECT conteggio.categoria, MAX(conteggio.collisioni) FROM ( SELECT Assicurato.idAssicurato AS idAssicurato, Veicolo.categoria AS categoria, COUNT(Collisione.data) AS collisioni FROM (SELECT * FROM BDA.Assicurato) AS Assicurato INNER JOIN (SELECT * FROM BDA.Polizza) AS Polizza ON Assicurato.idAssicurato = Polizza.idAssicurato INNER JOIN (SELECT BDA.MezzoDiTrasporto.* FROM BDA.MezzoDiTrasporto JOIN OCB.Veicolo ON BDA.MezzoDiTrasporto.targa = OCB.Veicolo.targa) AS Veicolo ON Polizza.targa = Veicolo.targa INNER JOIN ( SELECT targa, DATE(FROM_UNIXTIME(timestamp)) AS data, HOUR(FROM_UNIXTIME(timestamp)) AS ora, classeGravità, comune, codiceStrada, km FROM OCB.Collisione ) AS Collisione ON Veicolo.targa = Collisione.targa INNER JOIN ( SELECT comuneResidenza AS nome, provinciaResidenza AS provincia FROM BDA.Assicurato UNION SELECT comuneNascita AS nome, provinciaNascita AS provincia FROM BDA.Assicurato UNION SELECT comune AS nome, provincia FROM OCB.Comune) AS Comune ON Collisione.comune = Comune.nome WHERE Comune.provincia = 'MI' AND (Collisione.data BETWEEN '2014-01-01' AND '2014-12-31') GROUP BY idAssicurato, categoria ) AS conteggio GROUP BY categoria ) 96

97 NoSQL La base di dati OCB è destinata a contenere oltre ad una serie di dati utili all'identificazione del veicolo i dati relativi ai rilevamenti effettuati dal dispositivo preposto su di esso installato. Tra questi, una prima distinzione può essere fatta basandosi sul TTL delle informazioni coinvolte (nello specifico sulla loro validità ed utilità al passare del tempo): i dati relativi alle collisioni: dati per i quali si ritiene adeguato un tempo di conservazione di 4 anni; i dati relativi al rilevamento della velocità: per i quali si ritiene adeguato un tempo di conservazione di 2 anni. I dati relativi alle collisioni sono dati utili agli operatori dell'assicurazione per organizzare l'assistenza verso un eventuale sinistro; essi vengono in seguito archiviati ma non sono soggetti ad alcuna procedura periodica di calcolo/revisione. I dati relativi alla velocità sono inoltre oggetto di valutazione per il calcolo del livello di rischio di una data polizza alla scadenza. Caratteristiche quali la presenza di uno schema dei dati e di un sistema di gestione delle transazioni, forniti da un RDBMS risultano essere superflue al contesto applicativo analizzato. Viene pertanto scelto di utilizzare un database non relazionale documentale. 97

98 NoSQL Tra i vantaggi utili al caso in oggetto si evidenziano: la possibilità di usufruire di un modello di memorizzazione dei dati flessibile (aggiornabile e estraneo ai comuni problemi di retrocompatibilità); l'inserimento di dati relativi a telemetria e veicolo in strutture dati aggregate, possibilmente con l'uso dell'embedding, il cui accesso ottimizzato, più fedele alla realtà rappresentata, non necessiti dell'uso di operatori quali quello di JOIN, applicati all'intero dominio dei campionamenti in fase di lettura; un modello di distribuzione fondato sulla disponibilità (availability) più incline a scalare. Per quanto riguarda l'architettura di replicazione si valuta ragionevole una replicazione di ogni istanza della base dati su 3 nodi. I nodi seguono il modello di replicazione e distribuzione master-slave che consente di ottenere buone prestazioni sulle letture, accentrando nel solo nodo primario i controlli sulle scritture, permettendo nel contempo una replicazione istantanea delle stesse sui nodi ad esso collegati. Al fine di migliorare le prestazioni all'incremento delle operazioni di scrittura con l'aumento dei veicoli coinvolti, l'architettura scelta predisporrà uno sharding bilanciato in grado di aggiungere all'efficienza delle letture su più nodi quella delle scritture su due o più partizionamenti del nodo primario. Infine, l'operazione di lettura, effettuata con dominio la totalità dei veicoli, sfrutta il paradigma map-reduce per individuare quelli in scadenza distribuendo in parallelo la computazione a tutti i nodi, usufruendo in tal caso dell'accesso in lettura ai nodi di replicazione (slave o secondari). 98