Univesità di Siena

Corso di Laurea in Ingegneria Informatica

Studio e implementazione di un
sistema embedded adibito al controllo
del traffico

Gian Lorenzo Meocci

Relatore: Correlatore:
Chiar.mo Prof. Roberto Giorgi Chiar.mo Prof. Alessandro Mecocci

Anno Accademico 2004-2005

Alla mia famiglia
ii
Indice

1 Prefazione 1
1.1 Una panoramica d’insieme . . . . . . . . . . . . . . . . . . . . 1

2 Controllare il traffico 5
2.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2 Il sistema in breve . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3 Soluzioni esistenti . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1 Sistemi centralizzati e decentrallizati . . . . . . . . . . 6
2.3.2 Microsoft MapPoint . . . . . . . . . . . . . . . . . . . 7
2.3.3 S.T.A del comune di Roma . . . . . . . . . . . . . . . . 8
2.4 Conclusione introduttiva . . . . . . . . . . . . . . . . . . . . . 8

3 Tecnologie utilizzate 9
3.1 Il Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.1 Caratteristiche generali . . . . . . . . . . . . . . . . . . 9
3.1.2 L’ambiente di sviluppo . . . . . . . . . . . . . . . . . . 9
3.2 La Network camera . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Caratteristiche generali . . . . . . . . . . . . . . . . . . 10
3.3 Comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3.2 Inviare il livello del traffico . . . . . . . . . . . . . . . . 11
3.4 Elaborare un’immagine . . . . . . . . . . . . . . . . . . . . . . 13
3.4.1 Che cos’è un’immagine . . . . . . . . . . . . . . . . . . 13
3.4.2 Breve cenno al formato JPEG . . . . . . . . . . . . . . 13
3.4.3 Calcolare il livello del traffico . . . . . . . . . . . . . . 14
3.4.4 Determinazione dello sfondo . . . . . . . . . . . . . . . 19

iii
iv INDICE

4 Implementazione del sistema 23

4.1 Il Microcontroller . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.1.1 Il software di controllo . . . . . . . . . . . . . . . . . . 23
4.2 La Network camera . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2.1 Ottenere un’ immagine . . . . . . . . . . . . . . . . . . 24
4.2.2 Il decoder JPEG . . . . . . . . . . . . . . . . . . . . . 25
4.3 Comunicazione . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.3.1 Il modem GSM . . . . . . . . . . . . . . . . . . . . . . 26
4.3.2 Inviare il livello del traffico . . . . . . . . . . . . . . . . 26
4.4 L’interfaccia di controllo . . . . . . . . . . . . . . . . . . . . . 28

5 Valutazioni e test effettuati 31

5.1 Test effettuati . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.2 Risultati conseguiti . . . . . . . . . . . . . . . . . . . . . . . . 32

6 Conclusioni 33
6.1 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Conclusioni generali . . . . . . . . . . . . . . . . . . . . . . . . 34

A Codice 35
A.1 Alcuni importanti #define . . . . . . . . . . . . . . . . . . . . 35
A.2 La funzione per il download di una immagine . . . . . . . . . 35
A.3 Le funzioni per l’ inizializzazione del modem . . . . . . . . . . 36
A.4 La funzione per l’invio di un SMS . . . . . . . . . . . . . . . . 37

B Specifiche tecniche 39
B.1 Microcontroller Rabbit RCM3000 . . . . . . . . . . . . . . . . 39
B.2 Network Camera Axis2110 . . . . . . . . . . . . . . . . . . . . 39
B.3 Modem GSM Industrial Base . . . . . . . . . . . . . . . . . . 40
Capitolo 1

Prefazione

1.1 Una panoramica d’insieme

Questo lavoro di Tesi ha lo scopo di rilevare la densitá veicolare di un tratto
stradale utilizzando un sistema embedded composto da un microcontroller,
una telecamera e un modem GSM. Il sistema è stato progettato principal-
mente per consumare poca energia, occupare una banda ridotta ed utiliz-
zare componenti facilmente reperibili sul mercato e a costi contenuti. In
particolare in questo lavoro di tesi sono state realizzate:

1. Il software per la comunicazione tra microcontroller e telecamera.

2. Il software per la conversione di immagini dal formato JPEG al formato

PGM da utilizzare sulla Rabbit RCM3000.

3. Il software per il trattamento e l’analisi delle immagini.

4. Il software per la comunicazione (utilizzando un modem GSM) tra il

microcontroller e il Data Center utilizzando messaggi SMS.

5. Un interfaccia per la verifica e il controllo del sistema.

6. Vari tool per il test e la simulazione dei componenti del sistema.

Una prima fase del lavoro è stata dedicata all’analisi del problema e alla ri-
cerca dei componenti hardware adatti a risolvere il problema, seguita da una

1
2 CAPITOLO 1. PREFAZIONE

seconda fase di sperimentazione ed da una terza di implementazione.

Durante la fase di sperimentazione sono stati scritti vari tools per simu-
lare il comportamento dei componenti reali permettendo di progredire passo
dopo passo nella realizzazione di un prototipo finale, tenendo conto dello svi-
luppo complessivo.
Il primo modulo ad essere messo a punto è stato il modulo per l’elaborazio-
ne delle immagini scritto in Java. Questo tool ha permesso di comprendere i
vari problemi per l’elaborazione d’immagini riguardanti veicoli in movimento
a varie velocità. Utilizzando questo tool, sono stati definiti alcuni algoritmi
base da implementare in un microcontroller. Il microcontroller utilizzato è
un Rabbit RCM3000 che è basato su un processore Z80 ad 8 bit con un clock
da 30MHz il cui consumo complessivo risulta tipicamente intorno ai 495 mW.
Utilizzando questo microcontroller è stato fatto un primo porting del mo-
dulo d’elaborazione, simulando la produzione di immagini della telecamera
con un altro tool realizzato anch’esso in Java. La telecamera comunica con il
microcontroller attraverso un collegamento ethernet a 10Mbits, garantendo
un’adeguata ampiezza di banda per l’acquisizione delle immagini.
La fase d’acquisizione è seguita da quella di processing che consente di
calcolare i livelli di traffico da spedire al server utilizzando un modem GSM.
Il modem GSM (Industrial Base GSM) è stato scelto per la sua sempli-
ce integrazione nei sistemi embedded utilizzati sia in ambito industriale che
accademico. La comunicazione tra il microcontroller e il modem avviene at-
traverso una connessione seriale, attraverso la quale sono inviati i comandi
standard AT della ETSI. Il terzo tool sperimentale (utilizzato per testare
il modem) è stato realizzato in C per ambiente Linux e consente l’invio di
un SMS sulla rete GSM. Tale software imposta una connessione seriale con
il modem e successivamente imposta il modem per la registrazione sulla re-
te GSM. Si è scelto di comunicare attraverso messaggi SMS sfruttando reti
geografiche ampiamente diffuse per veicolare l’informazione al server centra-
le. A seguito di ciò e stato realizzato un porting sul microcontroller per
verificarne il corretto funzionamento. Da tenere presente che questa scelta
rispetta il secondo (e in parte terzo) requisito, in quanto senza alcun costo di
cablatura o installazione di ripetitori consente una comunicazione semplice
ed efficiente tra il sistema embedded e il server di controllo.
La telecamera utilizzata è la Axis 2110 (da cui dipendono molti fattori per
la corretta elaborazione delle immagini) che dispone di un interfaccia ether-
net grazie alle quale è possibile ottenere le immagini attraverso il protocollo
HTTP. E’ stato dunque scritto un tool, per il test, in grado di interfacciarsi
1.1. UNA PANORAMICA D’INSIEME 3

con la telecamera e scaricare i vari frame. Le immagini restituite sono poi

convertite dal formato JPEG al formato PGM in modo da essere processate
dal software sul microcontroller. La fase che ha visto la realizzazione del
modulo di conversione da JPEG a PGM, sul microcontroller, è stata la più
delicata e complessa. Il problema principale scaturiva dalla complessa natu-
ra del JPEG che richiede molta memoria e potenza di calcolo. Il modulo di
conversione si è basato sul convertitore jpegdrc ed è stato riscritto per essere
utilizzato sulla Rabbit. Il lavoro principale è stato quello di minimizzare l’u-
tilizzo della memoria (portata da 265KB a poco più di 47KB) e di sostituire
l’interfaccia a file con quella a memoria estesa. E’ stato anche necessario, do-
po aver terminato il porting del modulo di conversione sul microcontroller,
interfacciare direttamente il microcontroller alla telecamera.
L’intero software sul microcontroller è stato scritto utilizzando il Dyna-
mic C, un ambiente di sviluppo progettato per le schede RCM3000 che si
basa su una versione leggermente modificata dello standard ANSI C.
Dato che nel sistema si prevede l’interazione con il Data Center (server
di controllo) si è resa anche necessaria la realizzazione, oltre a tutti i tool di
simulazione (di volta in volta sostituiti dai corrispettivi componenti reali), di
una interfaccia (anch’essa realizzata in Java) che permettesse la gestione e la
visualizzazione dei risultati elaborati dal sistema embedded.
Nei capitoli successivi si analizzerà in maggior dettaglio il problema for-
nendone una possibile soluzione.
4 CAPITOLO 1. PREFAZIONE
Capitolo 2

Controllare il traffico

2.1 Introduzione

Immaginiamo di voler attivare un servizio in grado di guidare ed informa-

re adeguatamente un utente sulle condizioni del traffico di una determinata
zona d’interesse. Tale servizio, basandosi su diverse informazioni, dovrà for-
mulare un percorso ottimale che consenta all’utente di evitare quelle strade
già intensamente trafficate e che dunque possa condurlo alla destinazione de-
siderata nel minor tempo possibile. Dovremo perció realizzare un sistema
che consenta a tale servizio di essere costantemente aggiornato sull’evolversi
del traffico nei diversi tratti stradali e garantisca al contempo un adeguato
aggiornamento dei dati medesimi.
Questa tesi fà parte del progetto IES [9] e si pone lo scopo di reperire
parte di quell’ informazione necessaria per determinare la corretta densità
veicolare di un tratto stradale.
La soluzione studiata ed implementata consiste nell’ utilizzare un siste-
ma embedded connesso ad una network camera e ad un modem GSM
in grado, come avremo modo di mostrare in seguito, di rispondere ai requi-
siti sopra citati e di preservare una flessibilità strutturale che gli consenta di
adattarsi a svariate soluzioni implementative.

5
6 CAPITOLO 2. CONTROLLARE IL TRAFFICO

2.2 Il sistema in breve

Il sistema embedded ha una duplice funzione: è parte attiva in quanto ha
il compito di elaborare le immagini estrapolandone il livello del traffico, ed
ha una funzione di collegamento in quanto attraverso esso si controlla sia la
telecamera che il modem.
La telecamera1 comunica con il microcontroller2 attraverso una connessio-
ne ethernet e grazie al webserver incorporato riesce a scambiare le immagini
con semplici richieste HTTP[2].
Il modem3 utilizza invece un collegamento seriale, attraverso il quale ri-
ceve i messaggi da inviare al server centrale(Data Center ).
Questo sistema rientra nella categoria dei sistemi decentralizzati, cioè
quei sistemi in cui l’elaborazione dell’informazione è contestuale all’ acquisi-
zione della medesima. Ciò che a noi interessa è calcolare approssimativamente
quanto traffico è presente, in un determinato istante, in un tratto stradale
che è ben diverso dal voler calcolare il numero di veicoli che vi transitano.
Sono problemi di natura diversa e come avremo modo di approfondire sono
risolvibili entrambi con approcci diversi.
Un’ultima precisazione, che vorrei fare, riguarda il fatto che difficilmente
si potrà fare a meno di riferirsi ad una specifica tecnologia, vista la natura
sperimentale della tesi, ma ciò che spesso diremo in particolare varrà an-
che in generale a patto di cambiare qualche protocollo o aggiornare qualche
componente.

2.3 Soluzioni esistenti

2.3.1 Sistemi centralizzati e decentrallizati

Un’importante distinzione deve essere fatta tra i sistemi centralizzati e quel-
li decentrallizati per l’elaborazione di immagini. E’ la natura del problema
a determinare quale soluzione implementare dal momento che problemi di-
versi richiedono diversi carichi computazionali e quindi diverse architetture
elaborative.
1
Axis Network Camera 2110, implementa il protocollo HTTP1.1.
2
Rabbit RCM3000.
3
Industrial Base GSM, implementa i comandi standard AT della ETSI.
2.3. SOLUZIONI ESISTENTI 7

Fino ad oggi gli sforzi maggiori (e la ricerca in generale) si sono maggior-

mente concentrati nell’ elaborazione di immagini utilizzando soluzioni cen-
tralizzate, cioè elaborando tali immagini con grossi sistemi di calcolo. Tali
architetture consentono infatti di eseguire un enorme mole di calcoli e hanno
dunque numerose applicazioni: tracking di oggetti in movimento, recupero di
informazioni (ad esempio le targhe dei veicoli in transito), riconoscimento di
volti e varie analisi statistiche.
Questo approccio ha successo se abbiamo gli strumenti necessari per ri-
solvere i problemi di comunicazione dovuti all’ elevata banda richiesta e alle
grandi distanze da coprire. Una soluzione wired (in base ai vincoli di proget-
to iniziali del progetto IES) è da escludersi a priori (problemi di protocollo e
costi di cablatura) mentre una soluzione wireless, anche se praticabile, com-
porterebbe comunque costi dovuti all’installazione di nuovi ripetitori e tutti
i problemi che potremo definire socio-politici. Nonchè da tenere presente che
un sistema cosı̀ progettato sarebbe comunque poco scalabile.
Un sistema decentralizzato (come il nostro) poichè non deve trasferire im-
magini ad alta definzione ma solo il risultato elaborato (e qualche immagine
ridotta in determinati casi) può sfruttare le reti telefoniche mobili già esi-
stenti(ad esempio la rete GSM[4]) con costi, dunque, irrisori. Tuttavia non
potremmo più disporre di un sistema complesso di calcolo (anche un comu-
ne PC rispetto a un microcontroller è un sistema complesso di calcolo) e la
profondità d’ analisi che potremmo raggiungere sarà strettamente legata alla
potenza di calcolo del microcontroller, ma guadagneremo notevolmente sulla
flessibilità del sistema.
Quindi possiamo affermare che questi due approcci sono uno il comple-
mentare dell’altro e affrontano problemi che sono anch’essi complementari
tra loro. In questa tesi si realizzerà un sistema embedded che permetta di
osservare direttamente le problematiche della realizzazione di un sistema de-
centralizzato.
Qui di seguito sono riportati alcuni servizi già attivi che tentano di
risolvere parti delle problematiche sopra esposte.

2.3.2 Microsoft MapPoint

L’idea che stà dietro a questo prodotto è quella di offrire un servizio, che
attraverso il GPS ed un palmare, possa consentire all’ utente di localizzarsi
facilmente su una mappa cittadina. Su tale mappa verranno inserite varie
8 CAPITOLO 2. CONTROLLARE IL TRAFFICO

tipologie di informazioni (dai ristoranti ai servizi di trasporto) ma tali infor-

mazioni non saranno aggiornate automaticamente e perciò tale prodotto non
potrà sostituire il nostro sistema di acquisizione ed elaborazione dei flussi
stradali, ma semmai potrà esserne una comoda interfaccia.

2.3.3 S.T.A del comune di Roma

Il sistema centralizzato per il controllo del traffico del comune di Roma, è
indubbiamente uno dei sistemi di monitoraggio e controllo più avanzati in
Italia e in Europa. E’ composto da oltre 60 telecamere connesse ad una
dorsale in fibra ottica che costantemente monitorizzano i centri nevralgici
della Città. Un cluster composto da 35 PC in parallelo elabora le numerose
informazioni che costantemente raggiungono la centrale di controllo.
Inoltre numerosi semafori e segnalatori luminosi sono direttamente gestiti
da un sistema di controllo che si basa su un DSS(Decision Support System)
in grado di minimizzare i rallentamenti e gli ingorghi.
Tuttavia monitorare automaticamente aree più distanti dal centro (ad
esempio aree periferiche) resta ancora una questione in parte aperta, che
potrebbe essere risolta integrando la nostra soluzione nel sistema di controllo.

2.4 Conclusione introduttiva

Da quanto è stato illustrato possiamo dedurre che una possibile soluzione alla
gestione e al controllo del traffico sia quella di integrare più sistemi tra loro in
modo da formare un unico sistema in grado di gestire il traffico sia all’interno
della città che nelle zone limitrofe, offrendo inoltre un servizio fruibile dal
cittadino attraverso strumenti (palmari e cellulari) oggi ampiamente diffusi.
Capitolo 3

Tecnologie utilizzate

3.1 Il Microcontroller

3.1.1 Caratteristiche generali

Poichè le caratteristiche tecniche del microntroller influiscono sul tipo di ela-
borazione che può essere svolta su di esso è necessario a questo punto intro-
durre almeno gli aspetti principali di tale sistema. Innanzitutto si è utilizzato
il Rabbit RCM3000 basato su un processore Z80 a 8 bit con una frequenza
di clock pari a 30MHz e con una memoria complessiva di 512K. Tale sistema
è dotato inoltre di varie porte seriali e di una scheda ethernet a 10MBits che
ho utilizzato per connettere tra loro i tre componenti.

3.1.2 L’ambiente di sviluppo

L’ambiente di sviluppo fornito è il Dynamic C, che oltre al compilatore, mette
a disposizione un IDE progettato per integrarsi con il microcontroller (molto
utile nella fase di debug). Il linguaggio utilizzato è un dialetto dell’ANSI C[7]
modificato per sfruttare la multiprogrammazione (cofunction e codata) e per
semplificare la programmazione di rete.
Tale ambiente fornisce anche molte librerie che vanno dalla gestione della
memoria estesa a quella delle porte seriali comprimendo i tempi di sviluppo.
Tuttavia la programmazione sui sistemi embedded (di questo tipo) richiede

9
10 CAPITOLO 3. TECNOLOGIE UTILIZZATE

un approccio sostanzialmente diverso alla tipica programmazione su ambienti

workstation o desktop in quanto costringe il programmatore a fare i conti con
poca memoria a disposizione, con una ridotta potenza di calcolo e con ridotti
strumenti per il debug dell’applicazione.

3.2 La Network camera

3.2.1 Caratteristiche generali

Una network camera è una telecamera che, attraverso un webserver in-
tegrato, è in grado di comunicare attraverso il protocollo HTTP con un col-
legamento ethernet. Tali telecamere vengono utilizzate principalmente per
sistemi di videosorveglianza remota, sia outdoor che indoor, vista la semplice
realizzazione di complesse reti di controllo. La telecamera da noi utilizzata
per le provi sperimentali è la Axis 2110 adatta sia ad ambienti indoor che
outdoor. Ad ogni telecamera deve essere associato un indirizzo IP (si può
utilizzare anche quello di default) per consentirle di dialogare attraverso i
normali protocolli (TCP[6], HTTP, FTP) e di scambiare immagini.
Il formato utilizzato nella Axis 2110 per codificare le immagini è il JPEG,
con la possibilità di specificare la qualità nella richiesta HTTP, mentre altri
modelli consentono la richiesta di immagini in formato BMP.

3.3 Comunicazione

3.3.1 Introduzione
Si è già illustrato come un’ importante requisito per il sistema sia quello di
occupare poca banda per poter essere utilizzato anche in luoghi non raggiun-
gibili da tecnologia a banda larga (fibra ottica, xDSL, etc.). La nostra scelta
si è dunque focalizzata nelle reti di telecomunicazioni esistenti e largamente
utilizzate nel territorio nazionale e internazionale. Grazie all’utilizzo di pro-
tocolli ormai standard ed ampiamente diffusi (GSM, GPRS, EDGE, UMTS)
possiamo scegliere tra svariati servizi con costi e prestazioni diversificate.
Possiamo, in definitiva, adattare ed ampliare il nostro sistema embedded
in base alle risorse di cui disponiamo garantendo un’ elevata flessibilità e
3.3. COMUNICAZIONE 11

personalizzazione.
Per la realizzazione del prototipo abbiamo optato per utilizzare la rete
GSM (e in particolare gli SMS) per veicolare l’informazione tra il sistema
embedded e il Data Center. Questa scelta è stata dettata dalla semplice
interfaccia offerta dal modem GSM e dai bassi costi richiesti.

3.3.2 Inviare il livello del traffico

Per l’invio dell’informazione si è utilizzato il servizio SMS (Short Message
Service) previsto nello standard GSM. Questo servizio rende possibile l’invio
del livello del traffico a bassi costi e con poca banda rendendone molto sem-
plice la ricezione al Data Center. Infatti è sufficiente un solo processo, per
tutte le telecamere, che faccia il pool dei messaggi SMS in arrivo discrimi-
nandoli attraverso il SysID del messaggio. Un messaggio SMS è composto
da tre campi:

Tabella 3.1: Struttura di un messaggio SMS

SysID Type Body

- Il SysID è l’identificativo del sistema embedded e serve per tenere

traccia di tutti i messaggi inviati al Data Center.

- Il Type indica la tipologia del messaggio. Può assumere tre valori

{ALERT, TIME, IMAGE }. Il valore di ALERT indica al Data Center
che si è in presenza di un possibile congestionamento del traffico. Il va-
lore TIME indica invece che il messaggio è stato inviato per mantenere
aggiornata la base di dati. Infine il valore IMAGE, indica che si stà per
ricevere una serie di messaggi che costituiscono un’immagine.

- Il Body è il corpo del messaggio.

Un tipico messaggio assumerà dunque la seguente forma:

SysID: 1001,ALERT, Traffic: 3

12 CAPITOLO 3. TECNOLOGIE UTILIZZATE

Se invece il messaggio è un IMAGE non basterà inviare un solo messaggio

dal momento che vengono trasmesse immagini 80x60 pixel in bianco e nero.
Per codificare un pixel viene utilizzato un bit (0=nero e 1=bianco). Facendo
un semplice conto, e sapendo che un messaggio SMS può contenere 140 byte,
ricaviamo che il numero di messaggi necessari per inviare un’immagine sarà:
80 ∗ 60 600
#Byte = = 600; =⇒ ∼ 5 messaggi SMS;
8 140
Per ridurre il numero dei messaggi necessari possiamo applicare l’algoritmo
di compressione CCITT group 3 divenuto famoso per la sua applicazione ai
fax.

Figura 3.1: La codifica CCITT applicata ad un’immagine 80x60 a due colori

=⇒ (b0 ,`0 )(b1 ,`1 ) . . . (bn ,`n )

L’immagine viene rappresentata da un’insieme di coppie (bx ,`x ) in cui il primo

elemento rappresenta il bit e l’altro campo ci dice di quanto dobbiamo saltare
per trovare un bit diverso. Poichè in un segmento di 80 pixel ci sono in media
10 variazioni e `x occupa ln(80) = 4.3 ∼ 5 bit ci riportiamo ad un’immagine di
50x60=3000 bit che sono 3 messaggi SMS. La struttura di un tale messaggio
sarà dunque:

SysID: 1001,IMAGE, nmex:3, dim: # of bit,id1 id2 id3

id1 image data

id2 image data
id3 image data
| {z } .......................
.......... | {z }
8 1112
3.4. ELABORARE UN’IMMAGINE 13

Una volta che il messaggio è stato preparato lo si invia attraverso la funzione

send sms che utilizza i comandi AT per comunicare con il modem GSM
(vedere appendice per il codice).

3.4 Elaborare un’immagine

3.4.1 Che cos’è un’immagine

Per trattare le immagini su un sistema con poca memoria disponibile, si deve
necessariamente utilizzare immagini ridotte e possibilmente in scala di grigio.
Si è percio scelto di convertire le immagini JPEG che provengono dalla tele-
camera dal formato 320x240 al formato 160x120, eliminando l’informazione
sul colore. Quello che otteniamo è una matrice di 160x120 byte. Ogni pixel
è codificato con un byte rappresentante la luminanza dell’imagine in quel
punto.
Le considerazioni sopra fatte sono lecite in quanto è ampiamente dimo-
strato che il contenuto informativo di un immagine rimane sostanzialmente
invariato se eliminiamo le informazioni sul colore, mantenendo solo quelle
sulla luminanza.

3.4.2 Breve cenno al formato JPEG

Il formato JPEG (Joint Picture Expert Group) nasce agli inizi degli anni ’90
con l’ intento di trovare un formato in grado di ottenere buone prestazioni
con immagini fotografiche. Tale formato doveva sostanzialmente occupare
poca memoria garantendo livelli di qualità differenti. Lo schema di principio
che stà dietro alla conversione JPEG lo possiamo osservare in figura 3.2.
Come possiamo notare ci sono varie fasi che trasformano una matrice
multidimensionale di byte nell’imaggine compressa. La fase maggiormente
significativa è quella che trasforma in frequenza un blocco di pixel 8x8 uti-
lizzando la DCT(Discrete Cosine Transform). L’ idea di base è quella di
eliminare il contenuto informativo alle alte frequenze (non significative per
gli esseri umani) applicando un filtro che è definito nella fase di quantizza-
zione.
Dopo la fase di quantizzazione si ottiene una matrice simile alla seguente:
14 CAPITOLO 3. TECNOLOGIE UTILIZZATE

 
64 15 . . . 0
 7 0 ... 0 
 
M= .. .. . . 
 . . . 0 
0 0 0 0

In questa matrice compaiono molti zeri che consentono un’ulteriore fase di

compressione denominata RLE (Run Length Encode). Tale tecnica consiste
nel codificare una serie di dati attraverso una coppia (skip,value) dove skip è
il numero di valori uguali a zero e value è il successivo valore diverso da zero.
Nel formato JPEG tale compressione viene applicata dopo aver riordina-
to, con un andamento a Zig-Zag, la matrice 8x8 in un vettore di 64 elementi.
In questo formato si codificano in maniera diversa le componenti DC (com-
ponenti continue) da quelle AC (componenti variabili). La componente DC
non è altro che il primo elemento della matrice M (nel esempio è 64) e viene
compressa utilizzando il DPCM, che si basa su informazioni statistiche dei
blocchi (in pratica si codifica la variazione tra una componente DC e la suc-
cessiva).
Infine viene applicato Huffman, che consente di aumentare il grado com-
plessivo di compressione.

3.4.3 Calcolare il livello del traffico

Conoscere il livello del traffico significa calcolare la funzione diff . Il valore
restituito da tale funzione ci dice qual è la distanza tra l’immagine di sfondo
ed il frame corrente. Questo ci permette di controllare il flusso del traffico
in un determinato periodo. Infatti se il valore rimane costantemente alto
per un certo ∆t possiamo ipotizzare che si stà formando una colonna o che
comunque il traffico in quel periodo è elevato.
L’idea di base è dunque semplice: contiamo il numero di pixel del frame
corrente che differiscono dallo sfondo rispetto ad una certa soglia predeter-
minata.
La funzione diff , sotto riportata, è colei che svolge tale operazione, la
soglia durante il test è stata posta a 25.
3.4. ELABORARE UN’IMMAGINE 15

Figura 3.2: Le fasi per convertire un’ immagine in formato JPEG

int diff() {
int i,j,r;
byte b1[WIDTH2],b2[WIDTH2];
r=0;j=0;
for(j=0;j<HEIGHT2;j++){
xmem2root(&b1[0],(unsigned long)(sfondo+j*WIDTH2),WIDTH2);
xmem2root(&b2[0],(unsigned long)(Image+j*WIDTH2),WIDTH2);
for(i=0;i<WIDTH2;i++)if (abs(b1[i] − b2[i]) > 25)r++;
}
return r;
}
Il valore della soglia è stato calcolato considerando che la massima variazione
di un pixel codificato con un byte è di 255 e che generalmente si conside-
ra accettabile una variazione del 10% sull’immagine di ingresso. Abbiamo
16 CAPITOLO 3. TECNOLOGIE UTILIZZATE

dunque:
255 ∗ 10
soglia = = 25.5 ≈ 25
100
Un’altro parametro che sarebbe utile stimare è il numero di pixel sopra la
soglia del 10% ma sotto quella del 15%. Il valore di questa soglia è facilmente
calcolabile:
255 ∗ 15
soglia0 = = 38.25 ≈ 38
100
Se indichiamo con N il numero di pixel sopra la soglia e con N 0 quelli compresi
tra le due soglie si può notare come sia sempre vero che vale la relazione:
N ≥ N 0 . Possiamo dunque esprimere N con:

N = α + N 0; α ∈ N+
0;

Se di tale relazione N 0 fosse una componente significativa potremmo ritenere

che non siamo in presenza di un traffico reale, ma probabilmente stiamo va-
lutando variazione che dipendono da altri fattori (illuminazione, vibrazioni
della telecamera, variazione di temperatura, etc.).
In un caso reale tale parametro potrebbe essere significativo per deter-
minare quando riaggiornare lo sfondo di riferimento riducendo l’errore com-
messo nell’analisi del traffico.
Un’ ulteriore tecnica che si potrebbe implementare (uso il condizionale in
quanto non è stata sperimentata sul nostro prototipo) consiste nell’ analizza-
re la distribuzione delle variazioni dei pixel tra lo sfondo e il frame corrente,
estrapolando una coppia (ηx , ηy ) che rappresenti il baricentro di tale distri-
buzione. Quello che si prevede di ottenere è un indice (γ) che indichi la
variazione della distribuzione nel tempo. Con questo ulteriore indice si può
costruire la tabella 3.2.
Analizziamo adesso un possibile metodo per ottenere tale indice, definendo
due matrici (S, F) che rappresentino lo sfondo e il frame corrente. Ipotizzia-
mo ad esempio che si abbia una situazione simile (ovviamente S ed M sono
matrici 160x120):
   
0 1 3 0 1 0 0 0 0 1
S =  2 0 1 0 1 ; F =  2 0 0 0 1 ;
3 2 1 0 3 3 0 0 0 3
3.4. ELABORARE UN’IMMAGINE 17

Tabella 3.2: Tabella riassuntiva

N γ Traffico
alto alto normale
alto basso alto
basso alto basso
basso basso basso

La matrice differenza (in valore assoluto) è la seguente:

 
0 1 3 0 0
T = |S − F| =  0 0 1 0 0 ;
0 2 1 0 0

In questo caso si avrebbe (con soglia = 1) N = 2. L’idea di base consiste

nel sommare tutte le righe della matrice T e tutte le sue colonne ottenendo
due vettori:
Tr = [0 3 5 0 0]; Tc = [4 1 3];
Questi due vettori rappresentano lungo gli assi x ed y la distribuzione della
matrice T . Qui di seguito sono riportati i relativi grafici. Si puo dunque
calcolare ηx come:
P
k (Tr (k) ∗ k) 0∗0+1∗3+2∗5+3∗0+4∗0
ηx = P = = 1.625;
k Tr (k) 8

Stessa cosa per ηy .

P
k (Tc (k) ∗ k) 4∗0+1∗1+2∗3
ηy = P = = 0.875;
k Tc (k) 8
18 CAPITOLO 3. TECNOLOGIE UTILIZZATE

Figura 3.3: La rappresentazione del vettore Tr

4.5

3.5

2.5

1.5

0.5

0
0 0.5 1 1.5 2 2.5 3 3.5 4

Figura 3.4: La rappresentazione del vettore Tc

3.5

2.5

1.5

0.5

0
0 0.2 0.4 0.6 0.8 1 1.2 1.4 1.6 1.8 2
3.4. ELABORARE UN’IMMAGINE 19

Abbiamo determinato la coppia (ηx , ηy ) che rappresenta le coordinate del

baricentro della distribuzione T . A questi punti possiamo calcolare il para-
metro γ. Ipotizzando che all’istante t0 il baricentro di T sia (µx , µy ) mentre
all’ istante t1 sia (ηx , ηy ) si avrà che:
q
γ = (ηx − µx )2 + (ηy − µy )2 ;

che è la distanza tra i due punti.

Calcolare γ sul microcontroller di riferimento comporta un carico compu-
tazionale notevole. Per fare due conti:
1. Tr : 120 somme per tutte le 160 colonne ⇒ 120*160=19200 somme

2. Tc : 160 somme per tutte le 120 righe ⇒ 120*160=19200 somme

Complessivamente avremo 38400 somme da eseguire (con relativi accessi alla
memoria estesa) oltre al calcolo della coppia (ηx , ηy ). Per questi motivi è
necessario utilizzare un microcontroller con sufficiente potenza di calcolo.

3.4.4 Determinazione dello sfondo

Un’ importante passaggio consiste nel definire un algoritmo per determinare
automaticamente lo sfondo di riferimento. Questo è importante sia perchè il
sistema può eseguire un reboot generale in qualsiasi momento, sia perchè il
sistema nel normale corso di funzionamento deve essere in grado di riaggior-
nare il proprio sfondo indipendentemente dal Data Center.
Dopo la fase di inizializzazione (registrazione sulla rete GSM e inizializ-
zazione delle variabili globali) il sistema inizia una fase nella quale cerca di
determinare uno sfondo. Lo schema degli stati che descrivono questo proces-
so sono riportati figura 3.5.
Tale schema non garantisce, tuttavia, che l’immagine acquisita non contenga
veicoli, dal momento che tali veicoli potrebbero essere fermi durante l’intero
ciclo di ricerca (B → C). Per ridurre ulteriormente l’incertezza si potrebbe
eseguire un’ulteriore controllo basandosi su come dovrebbe essere fatto uno
sfondo tipico.
Poichè il manto stradale è sufficientemente regolare si può assumere che
un buono sfondo non dovrà presentare forti discontinuità per qualsiasi con-
dizione climatica si voglia considerare. Se riteniamo ragionevole tale criterio
possiamo, senza commettere un grossolano errore, considerare l’uniformità
20 CAPITOLO 3. TECNOLOGIE UTILIZZATE

Figura 3.5: Il grafo degli stati per l’acquisizione dello sfondo

dell’immagine, candidata ad essere lo sfondo, come un parametro qualitati-

vo. Ovviamente maggiore è l’uniformità di tale immagine maggiore sarà la
probabilità di aver scelto un giusto candidato.
Si è detto, poco sopra, che un buon sistema deve essere in grado di riag-
giornare autonomamente lo sfondo durante l’intero arco del funzionamento
per ridurre il disturbo dato principalmente dalla variazione della temperatura
e luminosità esterna, dalla formazione di ombre e dai cambiamenti climatici.
Quello che dunque si propone è di riapplicare il procedimento sopra visto
durante la fase di elaborazione. Cioè se dopo quattro frame non si sono veri-
ficate variazioni significative dallo sfondo noi riaggiorniamo il medesimo con
il frame corrente.
In questo modo possiamo evitare ulteriori controlli sui valori da assegnare
alle soglie di filtraggio (soglia, soglia0 ) dal momento che filtrano sufficiente-
3.4. ELABORARE UN’IMMAGINE 21

mente il rumore se viene utilizzato uno sfondo “recente”.

In realtà il rumore non è né uniforme nel tempo né uniforme nello spa-
zio. Questo comporterà sicuramente dei risultati soddisfacenti in alcuni casi
e meno soddisfacenti in altri. Ma come è doveroso ricordare sarà comun-
que il Data Center ha soppesare correttamente l’informazione che arriva dal
sistema embedded, inquadrandola in un contesto generale e maggiormente
informato.
22 CAPITOLO 3. TECNOLOGIE UTILIZZATE
Capitolo 4

Implementazione del sistema

4.1 Il Microcontroller

4.1.1 Il software di controllo

Figura 4.1: Lo schema complessivo del software di controllo

Lo schema precedente illustra, anche se in modo parziale, la sequenza delle

23
24 CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA

operazioni che vengono eseguite sul microcontroller. Se in qualsiasi istante

viene rilevato un’ errore critico il sistema si reinizializza utilizzando una chia-
mata alla funzione forceSoftReset.
Un aspetto fondamentale, ed essenziale per le prestazioni del sistema,
riguarda il formato delle immagini acquisite dalla telecamera. In molte tele-
camere l’unico formato disponibile è il JPEG[8] e dunque, per non perdere
di completezza, si è realizzato (in software) un decoder per tale formato.
In seguito, nel capitolo finale, valuteremo le prestazioni tra un sistema con
decoder sw uno con decoder hw.

4.2 La Network camera

4.2.1 Ottenere un’ immagine

Per ottenere un immagine si costruisce una richiesta HTTP e la si invia al

webserver della telecamera.
GET /axis-cgi/jpg/image.cgi?resolution=320x240&compression=50 HTTP/1.1
Host: 192.168.99.7 Authorization: Basic cm9vdDpwYXNz

Innanzitutto notiamo che si tratta di una richiesta GET per il protocollo

HTTP v. 1.1 con autorizzazione di tipo Basic. La richiesta è inoltrata verso
l’ host 192.168.99.7 che è l’indirizzo assegnato alla telecamera. Ciò che segue
dopo Basic è la stringa root:pass (username=root, password=pass) codi-
ficata in BASE64[3].
Una tipica risposta data dalla telecamera è la seguente:
HTTP/1.0 200 OK
Content-type: image/jpeg
hJPEG image datai

Che oltre ad indicare la corretta interpretazione della richiesta invia an-

che l’ immagine (320x240) compressa con fattore di qualità 50 con una
dimensione media di 7KB.
4.2. LA NETWORK CAMERA 25

4.2.2 Il decoder JPEG

Introduzione
Il decoder JPEG che si è realizzato si basa sul jpegdrc progettato da Pierre
Guerrier nel ’98 e successivamente aggiornato da Koen van Eijk nel ’99. Tale
software, scritto in C, è stato realizzato per piattaforme x86 non dunque ot-
timizzato per sistemi embedded ma sufficientemente compatto per renderne
possibile il porting sul nostro microcontroller di riferimento.
Il porting ha attraversato essenzialmente 5 fasi. Una prima fase ha vi-
sto la riduzione del codice non strettamente necessario e la fusione di tutti
i file sorgente (compresi gli header) in un unico file. Nella seconda fase si
sono eliminate le chiamate al filesystem, sostituendole con analoghe funzioni
per la memoria estesa (il file da convertire viene infatti memorizzato nella
memoria estesa del microcontroller). La terza fase ha visto la riscrittura di
alcune parti del decoder per non occupare più di 47KB. Per ottenere questo
risultato (ottimo se si considera che la versione basse occupa piu di 265KB) è
stato necessario ridurre l’immagine ogni volta che si decomprimeva il blocco
base (MCU). La quarta e quinta fase (integrazione e ottimizzazione) sono
state quelle maggiormente impegnative vista la differenza di architettura e
gli scarsi strumenti di debugging.
Poichè architetture e compilatori diversi codificano spesso differentemen-
te i tipi di base (int, long , float) si sono dovuti correggere tutti i cast in
quelle parti di codice dove venivano eseguite operazioni matematiche per la
conversione di un immagine.
E’ stato dunque realizzato un decoder JPEG in grado di convertire un’im-
magine 320x240 a colori in un’immagine 160x120 in scala di grigio, in tempi
ragionevoli, per il microcontroller Rabbit RCM3000.

Altri possibili approcci: un’implementazione HW

La realizzazione software di un decoder consente sicuramente una semplice
realizzazione a bassi costi ma rende difficile ottenere delle buone prestazioni.
Tuttavia esistono sul mercato svariate soluzioni hardware in grado di con-
vertire immagini JPEG in poche frazioni di secondo. Una soluzione tipica è
quella che vede l’utilizzo di FPGA collegate ad un microcontroller. Ovvia-
mente tali soluzioni aumentano sensibilmente le prestazioni ma anche i costi
ed i costumi complessivi.
26 CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA

4.3 Comunicazione

4.3.1 Il modem GSM

Il modem GSM è un modem Dual Band (900-1800MHz) controllabile attra-
verso comandi AT (standard GSM ETSI 07.05 e 07.07) con potenza d’uscita
da 1W per GSM1800 a 2W per GSM900. Il collegamento tra il modem e il
microcontroller è realizzato attraverso l’interfaccia seriale (connettore DB9
per RS232) presente sul microcontroller Rabbit.
Si è resa necessaria la realizzazione di un cavo apposito per connette-
re il modem al microcontroller, in quanto sul connettore DB9 della Rabbit
vengono mappate due porte seriali (B,C). Lo schema del connettore DB9 è
mostrato in figura 4.2.

Figura 4.2: Schema del connettore DB9 del modem

Nel microcontroller Tx è connesso al RxB mentre Rx viene connesso al TxB.

4.3.2 Inviare il livello del traffico

Per poter inviare un messaggio SMS vengono utilizzati, come precedentemen-
te detto, i comandi AT. Tali comandi vengono incapsulati in normali stringhe
ed inviati via seriale al modem. Lo schema che rappresenta l’insieme dei passi
per inviare un SMS lo possiamo riassumere nello schema 4.3.
Gli stati A, B e C vengono percorsi una sola volta durante la fase di ini-
zializzazione dell’intero sistema. In particolare abbiamo che nello stato A la
funzione init modem setta i parametri fondamentali della porta seriale sul
4.3. COMUNICAZIONE 27

microcontroller. Nello stato B si interroga il modem per determinare se si è

registrato sulla rete GSM. Se cosı̀ non fosse se permane in tale stato. Nello
stato C si invia al modem i comandi necessari per l’invio di un SMS e per il
controllo sugli errori.
Infine negli stati D ed E viene costruito il messaggio da inviare attraverso
la funzione sendSerial .

Figura 4.3: Schema per l’invio di un SMS

Qui di seguito viene riportato ciò che appare su un comune cellulare facente
funzione di modem ricevente. Si può notare come il messaggio SMS rispetti
le specifiche definite nel precedente capitolo e come sia semplice l’intera fase
di ricezione dei messaggi sul Data Center.
28 CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA

Figura 4.4: Il messaggio inviato su un cellulare

4.4 L’interfaccia di controllo

Per poter controllare i risultati ed il comportamento de sistema embedded
si è realizzata un’ interfaccia utilizzando Java [5] che potesse comunicare at-
traverso una connessione ethernet con il microcontroller. L’ interfaccia si
compone essenzialmente di tre parti: un box nel quale viene visualizzato (in
percentuale) il livello del traffico, un zona nella quale viene visualizzata l’
immagine che stà analizzando il microcontroller ed infine un barra verticale
che proietta il livello del traffico (la densità veicolare istantanea) su una scala
di valori che variano da “very low” a “very hight”.
Questa scala di valori indica la percentuale di variazione del frame corren-
te rispetto allo sfondo, tale valore lo si è definito un pò impropriamente livello
del traffico dal momento che per noi viene utilizzato proprio per determinare
tale livello. Tuttavia, come si può vedere dall’immagine, ciò che realmente
interessa è la media di questi valori un determinato arco temporale.
E’ quindi compito del Data Center fornire tale risultato. Questa sem-
plice interfaccia ci mostra solo quello che accade istante per istante durante
l’intero arco di funzionamento.
4.4. L’INTERFACCIA DI CONTROLLO 29

Figura 4.5: L’ interfaccia di controllo

30 CAPITOLO 4. IMPLEMENTAZIONE DEL SISTEMA
Capitolo 5

Valutazioni e test effettuati

5.1 Test effettuati

Per testare il sistema complessivamente si è utilizzato un filmato di una te-
lecamera posta su un cavalcavia autostradale. Questo filmato ci è servito
in molte fasi dello sviluppo. Durante la fase di progettazione è stato uti-
lizzato per testare il programma capture (realizzato dal sottoscritto). Tale
programma mi è servito come banco di prova per studiare ed implementare
alcuni algoritmi di elaborazione e per studiarne il relativo carico computa-
zionale.
Successivamente è stato utilizzato per testare il vero e proprio algoritmo
di elaborazione sul microcontroller. Dopo il test di ogni singola componente
si è eseguito un test complessivo durante il quale è stato fatto scorrere il
filmato su un monitor ripreso dalla telecamera Axis. La telecamera è stata,
ovviamente, posta sullo stesso segmento di rete del microcontroller e del-
l’interfaccia per consentire al microcontroller il download delle immagini e la
relativa elaborazione. I risultati sono stati fatti pervenire sia all’interfaccia di
controllo sia (se il livello del traffico era notevole) ad un cellulare attraverso
un SMS.
Come detto sopra sono stati testati tutti i componenti singolarmente.
Si è testato il modem scrivendo prima un’ applicazione per ambiente Linux
in grado di inviare un SMS e successivamente collegandolo direttamente al
microcontroller. E’ stata poi scritta un’ applicazione per connettersi alla te-
lecamera e convertire le immagini da Jpeg a PGM e poi ne è stato fatto il

31
32 CAPITOLO 5. VALUTAZIONI E TEST EFFETTUATI

porting sul microcontroller.

Durante la fase di sviluppo si è testato il sistema anche per scenari di-
versi, come ad’esempio la videosorveglianza per ambienti indoor. Le prove
effettuate in ambienti esterni sono state limitate dai numerosi problemi logi-
stici, ma tuttavia sono state comunque sufficienti per consentirci una buona
generalizzazione del problema.

5.2 Risultati conseguiti

Dalle prove effettuate è sempre emerso una forte correlazione tra ciò che veni-
va ripreso dalla telecamera e quello che veniva elaborato dal microcontroller.
Quello che ci eravamo proposti di ottenere, cioè un’ indice che misurasse l’in-
tesità del traffico, lo abbiamo ottenuto senza la pretesa che esso rappresenti
con precisione ciò che realmente stà succedendo nel tratto stradale. Il fatto
che i risultati possano essere affetti da rumore non pregiudica necessaria-
mente la validità di questo approccio. Infatti da un test eseguito è emerso
come un cambio repentino della luminosità impatti solamente per il 15% sul
risultato finale. Tale valore, anche se elevato, và necessariamente inquadrato
in ottica generale del sistema, nel quale è il Data Center ha dover soppesare
i singoli risultati comparandoli tra loro e con le loro medie.
Quello che il sistema riesce a fornire da una serie di dati è un’ altra serie
di dati maggiormente informativi dei precedenti, ma pur sempre dei dati. In
tale ottica và visto questo progetto, ed è per questo che l’ indice del traffico
che riusciamo ad estrapolare è in realtà sufficiente per lo scopo che ci siamo
posti.
Da alcuni test effettuati ho notato come (sotto determinate condizioni)
aumentando il numero di frame al secondo analizzati si potrebbe riuscire a de-
terminare (con un basso margine d’errore) il numero di autoveicoli transitati
nell’ arco del tempo preso in considerazione.
Capitolo 6

Conclusioni

6.1 Sviluppi futuri

Il sistema embedded utilizzato per realizzare questo prototipo è sistema a
basse prestazioni e non del tutto adatto a questa tipologia di problemi (è
infatti progettato per la realizzazione di controllori automatici). Quello che
si propone di utilizzare è un sistema maggiormente ottimizzato per questa
tipologia di applicazioni, in particolare mi riferisco all’utilizzo di sistemi co-
me XS400 della Xilix.
Per quello che riguarda il decoder Jpeg un possibile upgrade potrebbe es-
sere rappresentato dalla realizzazione in hardware del medesimo utilizzando
delle FPGA opportune come precedentemente detto.
Per la telecamera si potrebbero prevedere due scenari opposti tra loro. Il
primo sarebbe quello di passare ad utilizzare una versione notturna con la
possibilità di autoadattamento alla luminosità esterna. Il secondo approc-
cio sarebbe quello di utilizzare due piccole webcam seriali per produrre una
visione stereo del tratto stradale aumentando tuttavia la capacità computa-
zionale del microcontroller.
Un’ interessante upgrade potrebbe essere quello che riguarda il modulo
di comunicazione. Si potrebbe infatti adottare un modem GPRS con stack
TCP/IP in grado di offrire una comoda interfaccia programmativa e ovvia-
mente una maggiore banda.
Si aumenterebbe, cosı̀ facendo, la robustezza e l’affidabilità del siste-
ma con tecnologie già presenti e sufficientemente testate e standarizzate dai

33
34 CAPITOLO 6. CONCLUSIONI

relativi enti e mantenendo un basso costo complessivo.

6.2 Conclusioni generali

Per risolvere il problema dell’analisi e del controllo del traffico attraverso l’uti-
lizzo di calcolatori elettronici sono state adottate molte tecniche[1] che hanno
esaurientemente affrontato questo problema. Tuttavia quello che ancora non
è stato concretamente realizzato è un sistema che integri varie tipologie di
controllori (sia centralizzati che decentralizzati) in modo che si riesca a copri-
re una vasta area geografica per offrire un servizio completo al cittadino.
I servizi attuali si sono spesso concentrati ed evoluti in quelle aree in cui
erano già presenti reti e strutture adeguate alle analisi che si volevano com-
piere. Mi riferisco in particolare ai servizi per le autostrade o per i grandi
raccordi, in cui sono già presenti telecamere e collegamenti in fibra ottica o
wireless.
Ma in tutte quelle situazioni in cui non è possibile ricorrere a tali strutture
dobbiamo per forza di cose ricorrere ad una elaborazione locale dell’immagi-
ne utilizzando dei sistemi embedded. Nel nostro caso abbiamo fatto vedere
come ciò sia effettivamente possibile utilizzando a valle un Data Center, che
conoscendo tutti i dati di tutte le telecamere, sia in grado di dare informati-
vità ai dati inviati dai sistemi embedded sparsi lungo i vari tratti stradali.
Maggiore sarà la base di dati in possesso del Data Center maggiore sarà
l’accuratezza e l’efficienza dei risultati calcolati, dunque maggiore sarà l’in-
tegrazione delle varie soluzioni oggi esistenti (anche quella proposta in questa
tesi) più efficacemente potremmo controllare e gestire situazioni di traffico
intenso o di pericolo.
Appendice A

Codice

A.1 Alcuni importanti #define

#define SYS ID 1001 // Siena tangenziale
#define SID “SysID: 1001,ALERT, Traffic: ”
#define PORT A 80 // Telecamera Axis
#define PORT B 1755 // DataCenter
#define WIDTH 320
#define WIDTH2 160
#define HEIGHT 240
#define HEIGHT2 120
#define ADDRESS “192.168.99.7”
#define NUMBER “3334009570”

A.2 La funzione per il download di una im-

magine
void getimage() {
char buffer[1024];
int i,n;
unsigned long k;

35
36 APPENDICE A. CODICE

longword host;
tcp Socket axis;
n=0;jsize=0;
host=resolve(ADDRESS);
tcp open(&axis,0,host,PORT A,NULL);
while(!sock established(&axis) && sock bytesready(&axis)==-1)tcp tick(NULL);
sock write(&axis,&auth[0],strlen(&auth[0]));
while(n<3){
sock read(&axis,&buffer[0],1);
if(buffer[0]==0x0a)n++;
}
while(1)
{
memset(&buffer[0],0x00,1024);
n=sock read(&axis,&buffer[0],1024);
if(n<= 0)break;
k=(unsigned long)(ImageSRC+jsize);
root2xmem(k,&buffer[0],n);
jsize+=n;
}
sock close(&axis);
}

A.3 Le funzioni per l’ inizializzazione del mo-

dem
void init modem()
{
serBopen(9600);
serBflowcontrolOff();
serBdatabits(PARAM 8BIT);
serBparity(PARAM NOPARITY);
}
void init com()
{
sendSerial(“AT+CMGF=1\r”);recSerial(&p gsm[0]);
A.4. LA FUNZIONE PER L’INVIO DI UN SMS 37

sendSerial(“AT+CMEE=1\r”);recSerial(&p gsm[0]);
sendSerial(“AT+CSQ\r”);recSerial(&p gsm[0]);
}

A.4 La funzione per l’invio di un SMS

void send SMS(char *mex)
{
memset(t gsm,0,255);
memcpy(t gsm,SID,29);
strncat(t gsm,mex,1);
t gsm[strlen(t gsm)]=0x1a;
sendSerial(t gsm);msDelay(11500);
recSerial(&p gsm[0]);
printf(“%s\n”,p gsm);
}
38 APPENDICE A. CODICE
Appendice B

Specifiche tecniche

B.1 Microcontroller Rabbit RCM3000

Microprocessore: Rabbit3000
Clock: 29.4MHz
Flash Memory: 512K
Static RAM: 512K
Alimentazione: 3.15 - 3.45 V (145 mA)
Temperature: da −40◦ C a 70◦ C
Network: 10BaseT Ethernet networks (RJ-45)

B.2 Network Camera Axis2110

Microprocessore: AXIS ETRAX 100LX 32bit RISC CPU
Flash Memory: 4 MB
Static RAM: 16 MB
OS: Linux 2.4 kernel
Alimentazione: 9 VDC / 9 W
Lens: F 1.0 Varifocal (3.0 - 8.0 mm) automatic DC-Iris
Focus range: 0.5 mm to infinity
Illumination: 0.75 - 500 000 Lux
Network: 10BaseT/100BaseTX Ethernet networks (RJ-45)

39
40 APPENDICE B. SPECIFICHE TECNICHE

B.3 Modem GSM Industrial Base

Tecnologia: Dual Band (900-1800MHz)
Servizi: Voce, Fax, SMS, Dati
Potenza d’uscita: 2W per GSM900, 1W per GSM1800
Alimentazione: 8V
Assorbimento: 140 mA
Temperature: da −20◦ C a 55◦ C
Bibliografia

[1] Bruni, E. Analisi della velocità del flusso veicolare in un sistema di

controllo del traffico basato su elaborazione di immagini. Univerità di
Siena, Tesi di Laurea, 1999.
[2] Fielding, R. Hypertext transfer protocol – http/1.1. RFC 2616,
Network Working Group, June 1999. http://ds.internic.net/rfc/
rfc2616.txt;.
[3] Freed, N. Multipurpose internet mail extensions. RFC 2045, Network
Working Group, Nov. 1996. http://ds.internic.net/rfc/rfc2045.
txt;.
[4] Harte, L. Introduction to GSM: Physical Channels, Logical Channels,
Network, and Operation. Althos, 2004.
[5] Hekel, B. Thinking in Java. Apogeo, 2000.
[6] Institute, I. S. Transmission control protocol. RFC 793, Universi-
ty of Southern California, Sept. 1981. http://ds.internic.net/rfc/
rfc793.txt;.
[7] Kernighan, B. W., and Ritchie, D. M. The C Programming
Language, Second Edition. Prentice Hall, Inc., 1988.
[8] Tinku Acharya, P.-S. T. JPEG2000 Standard for Image Compres-
sion: Concepts, Algorithms and VLSI Architectures. Wiley-Interscience,
2004.
[9] Yusef Maali, Gian Lorenzo Meocci, Luca Paolini. IES (In-
telligent Evacuation System). Rapporto tecnico, Univerità di Siena
(http://lnx.programmo.net/ies.pdf), 2004.

41