SISTEMA DI RILEVAZIONE TRANSITI Bernardi 701857 – Bider 701784 – Bonetti 701156.
-
Upload
florentina-bucci -
Category
Documents
-
view
225 -
download
4
Transcript of SISTEMA DI RILEVAZIONE TRANSITI Bernardi 701857 – Bider 701784 – Bonetti 701156.
SISTEMA DI RILEVAZIONE TRANSITI
Bernardi 701857 – Bider 701784 – Bonetti 701156
Il Problema
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.
Problem Architecture
Assunzioni
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.
Problem Architecture
CHI e DOVEProblem Architecture
I casi d’uso potevano essereimpostati in maniera diversa (e più coerente); Ad esempio:- Genera Contravvenzione «include» Verifica Correttezza Targa
Sistema di rilevazione indica le 2 fotocellule e la fotocamera..potevano essere separati
COSA (Data Model)Problem Architecture
RilevazioneVeicoloInfrazioneContravvenzioneSanzionatopotevano essere tipi di dati sullo stesso piano concettuale, uniti da associazioni; non per forza sotto-tipi tra loro (specializzazione – relazione ISA)
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!
COME Rilevazione InfrazioniProblem Architecture
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 Notifica PattugliaProblem 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.
COME Notifica ContravvenzioneProblem 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:
http://stackoverflow.com/questions/15792687/loop-in-uml-activity-diagram-using-a-region
COME StatisticheProblem Architecture
QUANDOProblem 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 115.200 veicoli/ora. 5 infrazioni/ora. Per un totale di 200 infrazioni/ora.
In sede centrale arrivano quindi: 1 infrazione / 18 sec
Partizionamento (1)Logical Architecture
Partizionamento (2)Logical Architecture
Partizionamento (3)Logical Architecture
Partizionamento (4)Logical Architecture
Sequence Rilevazioni InfrazioniConcreteArchitecture
Manca il componente Gestore Infrazioni: l’infrazione dovrebbe essere generata da questo componente (che poi notifica l’infrazione alla pattuglia). La slide successiva è corretta.
Sequence PattugliaConcreteArchitecture
Sequence ContravvenzioneConcreteArchitecture
Sequence StatisticheConcreteArchitecture
Deployment – Soluzione 1DeploymentArchitect
ure
Deployment – Soluzione 2DeploymentArchitect
ure
Elaborazione dell’immagineDeploymentArchitect
ure
Distanza Camera dal Veicolo: 3mDistanza Focale Camera: 35mmRisoluzione Immagine: 1280x960x24Compressione Immagine: JPGDimensione 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)
EI : Possibili Soluzioni (1)DeploymentArchitect
ure
Distanza Camera dal Veicolo: 3mDistanza Focale Camera: 35mmRisoluzione Immagine: 2816x2112x24Compressione Immagine: JPGDimensione 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!)
Aumentare la risoluzione di acquisizione della came
EI : Possibili Soluzioni (2)DeploymentArchitect
ure
Aumentare la distanza focale della camera (zoom)
Distanza Camera dal Veicolo: 3mDistanza Focale Camera: 105mmRisoluzione Immagine: 1280x960x24Compressione Immagine: JPGDimensione 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
EI : Possibili Soluzioni (3)DeploymentArchitect
ure
Effettuare due scatti a diverse focali + compressione1280x960x24 1mb
640x480x24 287kb
1280x960x24 1mb
1280x960x8 330kb
EI : RiassumendoDeploymentArchitect
ure
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
ComunicazioneDeploymentArchitect
ure
WiMaxDeploymentArchitect
ure
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
UMTSDeploymentArchitect
ure
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
UMTS+WiFiDeploymentArchitect
ure
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
DevicesDeploymentArchitect
ure
Microprocessore (E.g. ARM7 architecture)
Camera con illuminatore IR
DevicesDeploymentArchitect
ure
Tablet/PDAcon connessione UMTS e WiFi
DevicesDeploymentArchitect
ure
Cluster di Server