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 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.

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

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)

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

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/15792687/loop-in-uml-activity-diagram-using-a-region

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 DeploymentArchitecture

Deployment – Soluzione 2 DeploymentArchitecture

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)

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!)

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

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

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

Comunicazione DeploymentArchitecture

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

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

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

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

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

Devices DeploymentArchitecture Cluster di Server