SISTEMA DI RILEVAZIONE TRANSITI Bernardi 701857 – Bider 701784 – Bonetti 701156.

transcript

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

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

Deployment – Soluzione 2DeploymentArchitect

Elaborazione dell’immagineDeploymentArchitect

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

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

Aumentare la distanza focale della camera (zoom)

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

Effettuare due scatti a diverse focali + compressione1280x960x24 1mb

640x480x24 287kb

1280x960x24 1mb

1280x960x8 330kb

EI : RiassumendoDeploymentArchitect

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

WiMaxDeploymentArchitect

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

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

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

Microprocessore (E.g. ARM7 architecture)

Camera con illuminatore IR

Tablet/PDAcon connessione UMTS e WiFi

Cluster di Server

SISTEMA DI RILEVAZIONE TRANSITI Bernardi 701857 – Bider 701784 – Bonetti 701156.

Documents