SISTEMA DI
RILEVAZIONE TRANSITI
Bernardi 701857 – Bider 701784 – Bonetti 701156
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.
Assunzioni

I VRT sono fissi.

La rilevazione è effettuata su una singola corsia.



Problem Architecture
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.
CHI e DOVE
Problem Architecture
vazione
cellule e
otevano
i
I casi d’uso
potevano essere
impostati in
maniera diversa (e
più coerente);
Ad esempio:
- Genera
Contravvenzione
«include» Verifica
Correttezza Targa
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
I due eventi di passaggio
sulle fotocellule potevano
Rilevazione
essere modellati in modo
più coerente con l’attesa
di due eventi in sequenza
(vedi soluzione mostrata a
lezione)
COME
Infrazioni
Problem Architecture
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.
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:
http://stackoverflow.com/questions/1579268
7/loop-in-uml-activity-diagram-using-aregion
COME Statistiche
Problem Architecture
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 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 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.
Sequence Pattuglia
ConcreteArchitecture
Sequence Contravvenzione
ConcreteArchitecture
Sequence Statistiche
ConcreteArchitecture
Deployment – Soluzione
1
DeploymentArchitectur
e
Deployment – Soluzione
2
DeploymentArchitectur
e
Elaborazione dell’immagine
DeploymentArchitectur
e
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)
EI : Possibili Soluzioni (1)
DeploymentArchitectur
e
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!)
EI : Possibili Soluzioni (2)
DeploymentArchitectur
e
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
EI : Possibili Soluzioni (3)
DeploymentArchitectur
e
Effettuare due scatti a diverse focali + compressione
1280x960x24
1mb
640x480x24
287kb
1280x960x24
1mb
1280x960x8
330kb
EI : Riassumendo
DeploymentArchitectur
e
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
Comunicazione
DeploymentArchitectur
e
WiMax
DeploymentArchitectur
e
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
UMTS
DeploymentArchitectur
e
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+WiFi
DeploymentArchitectur
e
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
Devices
DeploymentArchitectur
e
Microprocessore
(E.g. ARM7 architecture)
Camera con illuminatore IR
Devices
DeploymentArchitectur
e
Tablet/PDA
con connessione UMTS e WiFi
Devices
DeploymentArchitectur
e
Cluster di Server