Sistema di rilevazione transiti

Presentazione sul tema: "Sistema di rilevazione transiti"— Transcript della presentazione:

1 Sistema di rilevazione transiti
Bernardi – Bider – Bonetti

2 Il Problema Problem Architecture
Si deve modellare un Sistema di Rilevazione Transiti (SRT) che comprende una sede centrale ed alcune decine di Varchi di Rilevazione Transiti (VRT). Ogni VRT è costituito da due fotocellule a distanza di 1m e una fotocamera che riprende frontalmente un veicolo, collegate ad un nodo di elaborazione distante al massimo10m Il sistema SRT invia la contravvenzione ai proprietari dei veicoli che hanno commesso un’infrazione, ricavando le informazioni dal PRA (Pubblico Registro Automobilistico) oppure ai guidatori fermati dalla pattuglia. Inoltre il sistema SRT interagisce con una BDA (Base Dati Ambiente) che contiene i dati di inquinamento rilevati da centraline disposte sul territorio al fine di determinare correlazioni statistiche fra l’inquinamento rilevato dalle centraline e le intensità dei flussi di traffico rilevate dai VRT posti entro 200m dalle centraline stesse.

3 Assunzioni Problem Architecture I VRT sono fissi.
La rilevazione è effettuata su una singola corsia. La fotocamera è sempre accesa e scatta la foto solo in caso di superamento del limite di velocità. Se è presente una pattuglia di polizia, il sistema le notifica l’infrazione rilevata. Per effettuare analisi statistiche le centraline si devono trovare al più a 200m da un VRT. Poiché le centraline e i VRT sono gestiti da due società differenti non è necessario che vi sia una centralina in prossimità di un VRT e viceversa.

4 CHI e DOVE Problem Architecture
Sistema di rilevazione indica le 2 fotocellule e la fotocamera..potevano essere separati I casi d’uso potevano essere impostati in maniera diversa (e più coerente); Ad esempio: - Genera Contravvenzione «include» Verifica Correttezza Targa

5 La Contravvenzione dovrebbe essere associata direttamente alla Targa e al Sanzionato;
con questa modellazione le istanze di Sanzionato si ripetono se una certa persona ha subito 2 contravvenzioni con auto (targhe) diverse! COSA (Data Model) Problem Architecture RilevazioneVeicolo Infrazione Contravvenzione Sanzionato potevano essere tipi di dati sullo stesso piano concettuale, uniti da associazioni; non per forza sotto-tipi tra loro (specializzazione – relazione ISA)

6 COME Rilevazione Infrazioni
I due eventi di passaggio sulle fotocellule potevano essere modellati in modo più coerente con l’attesa di due eventi in sequenza (vedi soluzione mostrata a lezione) COME Rilevazione Infrazioni Problem Architecture

7 COME Notifica Pattuglia
Problem Architecture Il ramo «guidatore fermato» così com’è è scorretto; bisogna far vedere un evento che modella la ricezione dei dati del guidatore, a cui segue il dato guidatore fermato; non una notifica.

8 COME Notifica Contravvenzione
Problem Architecture Bisogna mostrare che il flusso a valle del dato Infrazione è ciclico, ossia si esplica per ogni istanza di Infrazione recuperata (che è più di una vista la frequenza!). Per fare questo: cardinalità «*» in uscita da Acquisizione Infrazione(i) il flusso a valle delle * Infrazioni va all’interno di una «loop region», vedete qui:

9 COME Statistiche Problem Architecture

10 QUANDO Problem Architecture
Al fine di stimare le frequenze delle attività principali, ipotizziamo che il sistema sia applicato a livello comuale (grossi comuni). Come ad esempio il comune di Milano che si estende per circa 184 km2 Ipotizziamo di disporre di circa 40 VRT, rilevando: Un passaggio di 0,8 veicoli/sec. Per un totale di veicoli/ora. 5 infrazioni/ora. Per un totale di 200 infrazioni/ora. In sede centrale arrivano quindi: 1 infrazione / 18 sec

11 Partizionamento (1) Logical Architecture

12 Partizionamento (2) Logical Architecture

13 Partizionamento (3) Logical Architecture

14 Partizionamento (4) Logical Architecture

15 Sequence Rilevazioni Infrazioni
ConcreteArchitecture Manca il componente Gestore Infrazioni: l’infrazione dovrebbe essere generata da questo componente (che poi notifica l’infrazione alla pattuglia). La slide successiva è corretta.

16 Sequence Pattuglia ConcreteArchitecture

17 Sequence Contravvenzione
ConcreteArchitecture

18 Sequence Statistiche ConcreteArchitecture

19 Deployment – Soluzione 1
DeploymentArchitecture

20 Deployment – Soluzione 2
DeploymentArchitecture

21 Elaborazione dell’immagine
DeploymentArchitecture Distanza Camera dal Veicolo: 3m Distanza Focale Camera: 35mm Risoluzione Immagine: 1280x960x24 Compressione Immagine: JPG Dimensione Immagine: 1mb La targa risulta leggibile all’occhio umano ma di difficile discriminazione da parte di un sistema automatizzato a causa della scarsezza di pixel che caratterizza lo spessore di ogni singolo carattere (~ 5 px)

22 EI : Possibili Soluzioni (1)
DeploymentArchitecture Aumentare la risoluzione di acquisizione della came Distanza Camera dal Veicolo: 3m Distanza Focale Camera: 35mm Risoluzione Immagine: 2816x2112x24 Compressione Immagine: JPG Dimensione Immagine: 2mb PRO agevola la pattuglia che riceve la foto nell’identificazione del veicolo da fermare CONTRO aumento notevole peso immagini -> possibile congestionamento rete quantità pixel (~ 9) non ancora ottimale! (15-20px necessari -> 5000+px di risoluzione!)

23 EI : Possibili Soluzioni (2)
DeploymentArchitecture Aumentare la distanza focale della camera (zoom) Distanza Camera dal Veicolo: 3m Distanza Focale Camera: 105mm Risoluzione Immagine: 1280x960x24 Compressione Immagine: JPG Dimensione Immagine: 1mb PRO facilita il processo di riconoscimento automatico da parte del sistema (20px!) CONTRO difficoltà da parte della pattuglia di identificare immediatamente il veicolo necessità di un setup accurato della camera

24 EI : Possibili Soluzioni (3)
DeploymentArchitecture Effettuare due scatti a diverse focali + compressione 1280x960x24 1mb 640x480x24 287kb 1280x960x8 330kb

25 EI : Riassumendo DeploymentArchitecture Camera PRO CONTRO
Fotocamera HighRes con focale 35mm Immagine completa della scena Facilità di riconoscimento vettura per la pattuglia Peso immagine alto (> 3MB) Possibile difficoltà di trasmissione HW costoso Fotocamera LowRes con focale >80mm Peso immagine basso Lo zoom sulla regione di interesse facilita il riconoscimento automatico HW economico Difficoltà da parte della pattuglia di identificare facilmente il veicolo Necessità di un posizionamento e setup accurato della camera 2 Scatti a diverse focali (35mm e 100mm) con 1 o 2 fotocamere LowRes Peso immagini basso Possibilità di compressione ulteriore per alleggerire la banda Aumento costo HW Setup camere necessario

26 Comunicazione DeploymentArchitecture

27 WiMax DeploymentArchitecture PRO CONTRO
Copertura teorica ~50km per antenna Sensibile alle situazioni ambientali (atmosferiche e urbanistiche) Ampia banda (~128Mbps down e ~56Mbps up teorici) Tecnologia poco diffusa e costosa Utilizzo di un’unica tecnologia di comunicazione per l’intero sistema Impossibilità di connessione ad hoc tra pattuglia e varco

28 UMTS DeploymentArchitecture PRO CONTRO Tecnologia ampiamente diffusa
Ampiezza banda limitata (~ 300kbs) Costi contenuti Rischi di congestione rete in aree densamente popolate Utilizzo di un’unica tecnologia di comunicazione per l’intero sistema Impossibilità di creare reti ad hoc fra pattuglia e varco

29 UMTS+WiFi DeploymentArchitecture PRO CONTRO
Possibilità di stabilire connessioni ad hoc (pattuglia - varco) Copertura (varco – pattuglia) limitata Velocità di trasmissione migliore fra tutte le tecnologie analizzate Utilizzo di due tecnologie -> aumento costi Assenza di congestione

30 Devices DeploymentArchitecture Microprocessore
(E.g. ARM7 architecture) Camera con illuminatore IR

31 con connessione UMTS e WiFi
Devices DeploymentArchitecture Tablet/PDA con connessione UMTS e WiFi

32 Devices DeploymentArchitecture Cluster di Server