9s Monografia

QUILA NEVES CHAVES
FERNANDO CONSTANTINO BARCELINI

LUCAS WENG
SISTEMA DE MONITORAMENTO DE TRFEGO POR MEIO DE RFID
Projeto de Formatura
Escola Politcnica da Universidade de
So Paulo.
So Paulo
2008
2
QUILA NEVES CHAVES
FERNANDO CONSTANTINO BARCELINI
LUCAS WENG
SISTEMA DE MONITORAMENTO DE TRFEGO POR MEIO DE RFID
Projeto de Formatura
Escola Politcnica da Universidade de
So Paulo.
Curso:
Engenharia Eltrica
Computao
nfase
Orientador:
Prof. Dr. Carlos Eduardo Cugnasca
So Paulo
2008
em
FICHA CATALOGRFICA
Chaves, A. N.; Weng, L.; Barcelini, F. C.

Sistema de monitoramento de trfego atravs de RFID / quila Neves
Chaves, Fernando Constantino Barcelini, Lucas Weng So Paulo,
2008
Projeto de formatura apresentado Escola Politcnica da
Universidade de So Paulo Poli-USP, Campus da Capital, 2008
Orientador: Carlos Eduardo Cugnasca
1. Identificao de veculos. 2. Trnsito. 3. Redes. 4. Sistemas de

informao. I. Sistema de Monitoramento de Trfego atravs de RFID.
II. Universidade de So Paulo. Escola Politcnica. Departamento de
Engenharia de Computao e Sistemas Digitais
DEDICATRIA
Dedicamos este trabalhado a nossos familiares, que tm nos dado suporte
durante nossa graduao na Escola Politcnica da USP, aos professores que se
esforaram em nos oferecer ensino de qualidade e a todos os nossos amigos e
colegas que nos acompanharam nesse rduo trajeto at a concluso do curso.
AGRADECIMENTOS
Agradecemos Escola Politcnica da Universidade de So Paulo pela
formao que adquirimos e sociedade que, por meio de impostos, custeou nossa
Universidade.
Agradecemos
ao
nosso
professor-orientador
Carlos
Cugnasca
do
Departamento de Engenharia de Computao e Sistemas Digitais pelo apoio e pelas

primeiras orientaes no projeto. E ao professor Hugo Pietrantoni do Departamento
de Engenharia de Transportes pelas conversas e reunies sobre conceitos de
trfego urbano. Ambos da Escola Politcnica da Universidade de So Paulo.
Agradecemos Renata Sena e ao Luiz Antonio da empresa Q-Free que
ajudaram a viabilizar o emprstimo dos equipamentos (duas antenas do modelo
MD5850M, dois kits para teste que incluem conversores e cabos conectores e
dez TAGs) para a realizao dos testes.
"Se consegui enxergar

mais longe porque
estava apoiado sobre
ombros de gigantes."
Newton
RESUMO
Esse projeto de formatura envolveu a concepo e implementao de um
prottipo de um sistema que visa prover ferramentas para gesto de trfego de
veculos, auxiliando no seu monitoramento. Ele torna disponveis informaes sobre
o trnsito tanto aos rgos envolvidos na gesto do trfego urbano quanto a
usurios finais como motoristas. A coleta dos dados ser realizada por meio de uma
infra-estrutura de comunicao constituda por etiquetas eletrnicas (ou tags) de
identificao rdio freqncia (RFID) instaladas nos veculos e por antenas leitoras
das mesmas. O sistema proposto envolve uma aplicao web que tem como
produtos principais a recepo dos dados das etiquetas do veculos e respectivo
processamento, gerando informaes sobre a posio a cada instante de cada
veculo nas vias de interesse, atualizao de banco de dados e a exibio das
informaes sobre o trnsito em mapas, por meio de um website. Acredita-se que o
projeto proposto em breve poder se constituir em uma alternativa real, uma vez que
existe a resoluo 212/2006 do CONTRAN que prev a implantao de etiquetas
eletrnicas em todos os veculos da frota brasileira.
Palavras-chave: Engenharia. Engenharia Eltrica. Engenharia de Computao.
RFID. Trnsito. Monitoramento de Trfego.
ABSTRACT
This graduation project involved the conception and implementation of a
system prototype which intends to provide tools to vehicle traffic management,
supporting its monitoring. It makes information about traffic available to institution
involved in urban traffic management as well as to final users as drivers. The data
collection is made by a communication infrastructure consisting of electronic tags of
radio frequency identification (RFID) assembled in the vehicles and readers. The
suggested system consists of an web application that has as main results the data
reception from vehicle tags and correspondent processing, providing information
abou the real time position from each vehicle along interesting roadway, updating
data base and the information display about traffic on maps, via website. It is
probable that the suggested project soon will be able to become a real alternative,
once theres the regulation 212/2006 of CONTRAN, which specifies tha implantation
of electronic tags in all vehicle of Brazilian fleet.
Keywords: Engineering. Electrical Engineering. Computer Engineering. RFID.
Transit. Traffic monitoring.
LISTA DE ILUSTRAO
Figura 1 - Reportagem da Veja So Paulo ................................................................ 17
Figura 2 - Reportagem no ESTADO DE SO PAULO .............................................. 18
Figura 3 - Reportagem na VEJA ............................................................................... 18
Figura 4 - Chip para colocar em pessoas (Langley, 2007) ........................................ 22
Figura 5 - Bilhete nico ............................................................................................. 24
Figura 6 - TAG passivo ............................................................................................. 24
Figura 7 - TAG ativo .................................................................................................. 24
Figura 8 - Arquitetura Cliente-Servidor ...................................................................... 27
Figura 9 - Comportamento Velocidade x Fluxo[3] ...................................................... 30
Figura 10 - Simplificao Velocidade x Fluxo[10] ........................................................ 30
Figura 11 - Classificao adotada de status de via ................................................... 31
Figura 12 - Classificao atravs de densidade de trfego ....................................... 32
Figura 13 - Fluxo de Dados ....................................................................................... 41
Figura 14 - Arquitetura do sistema ............................................................................ 41
Figura 15 - Exemplo de apresentao do trnsito na Sada da USP ........................ 43
Figura 16 - Web Servers Market Share (Web Server Survey, 2008)......................... 46
Figura 17 - Diagrama ER .......................................................................................... 49
Figura 18 Processo bsico de gesto de projeto ................................................... 50
Figura 19 EAP ........................................................................................................ 51
Figura 20 - Diagrama de Ishikawa (Causa e Efeito) .................................................. 53
Figura 21 Cronograma Inicial ................................................................................. 54
Figura 22 Diviso de responsabilidades macro no projeto ..................................... 55
Figura 23 - Arquitetura do Sistema Desenvolvido ..................................................... 56
Figura 24 - Modularizao do Software ..................................................................... 57
Figura 25 - Fluxo de Dados do Software ................................................................... 58
Figura 26 - Mdulo Monitor - Fluxograma ................................................................. 59
Figura 27 - Mdulo Monitor - Diagrama de Classes Simplificado .............................. 60
Figura 28 - Mdulo Adaptador - Diagrama de Classes Simplificado ......................... 66
Figura 29 Fluxo bsico do modulo calculadora ...................................................... 67
10
Figura 30 - Exemplo de pontos possveis de sada e entrada de veculos em trecho
AB monitorado........................................................................................................... 68
Figura 31 Dados para clculo da velocidade de um veculo .................................. 69
Figura 32 Diagrama de Classes do Mdulo Calculadora ....................................... 71
Figura 33 - Pgina inicial do Web Site do Projeto de Formatura ............................... 72
Figura 34 - Portal do Trnsito .................................................................................... 73
Figura 35 - Arquitetura do Portal ............................................................................... 75
Figura 36 - Arquitetura Proposta pelo SINIAV (antena em cima da faixa) ................ 76
Figura 37 - Antena postada na lateral da via ............................................................. 76
Figura 38 - Equipamentos Q-Free ............................................................................. 77
Figura 39 - Primeira tela ............................................................................................ 90
Figura 40 - Tela inicial do Portal aps a insero de nova rea ................................ 91
Figura 41 - Escola Politcnica da USP ...................................................................... 91
Figura 42 - Jockey Clube de So Paulo .................................................................... 92
Figura 43 - Sada da USP pela portaria 1 ................................................................. 92
Figura 44 - Sada da USP com zoom aumentado ..................................................... 93
Figura 45 - Fim do teste ............................................................................................ 95
Figura 46 - III ENEEEL ............................................................................................ 102
Figura 47 - III ENEEEL (equipamentos) .................................................................. 102
Figura 48 - III ENEEEL (fechamento) ...................................................................... 103
Figura 49 Tela principal do mdulo monitor ......................................................... 107
Figura 50 Tela de configurao de formato de string do mdulo monitor ............ 108
Figura 51 Tela de configurao de parmetros de servidor e banco de dados .... 109
Figura 52 - Mdulo Adaptador - Tela Principal ........................................................ 110
Figura 53 Tela do Mdulo Calculadora ................................................................ 112
Figura 54 Rotina Principal do Mdulo Calculadora .............................................. 113
Figura 55 - Sub-rotina Clculo de Fluxo ............................................................... 114
Figura 56 - Sub-rotina Clculo de Velocidade ...................................................... 114
Figura 57 Parmetros de conexo do Banco ....................................................... 115
Figura 58 - Configurao da Google Maps API Key................................................ 115
11
LISTA DE TABELAS
Tabela 1 - Combinaes que classificam o status de via .......................................... 31
Tabela 2 Matriz de Requisitos Funcionais x Casos de Usos .................................. 39
Tabela 3 Exemplos de vias e parmetros .............................................................. 86
Tabela 4 Cadastro de trechos teste ....................................................................... 87
Tabela 5 Resultado na tabela status ...................................................................... 87
Tabela 6 Resultado no cadastro de trechos teste .................................................. 87
Tabela 8 Resultado no cadastro de trechos teste .................................................. 88
Tabela 10 Resultado no cadastro de trechos teste ................................................ 88
Tabela 11 Resultado na tabela status .................................................................... 88
Tabela 12 Resultado no cadastro de trechos teste ................................................ 89
Tabela 13 - Carga inicial na tabela AREA ................................................................. 90
Tabela 14 - Tabela AREA aps a insero de uma rea .......................................... 90
Tabela 15 - Carga inicial na Tabela TRACK.............................................................. 93
Tabela 16 - Insero de novos trechos para novo teste............................................ 94
12
LISTA DE ABREVIATURAS E SIGLAS

API
Application Programming Interface
CET
Companhia de Engenharia de Trfego
CSS
Cascading Style Sheets
EAP
Estrutura Analtica de Projeto
ER
Entidade Relacionamento
HTTP
Hypertext Transfer Protocol
HTTPS
Hypertext Transfer Protocol Secure
IP
Internet Protocol
RFID
Radio Frequency Identification
SINIAV
Sistema Nacional de Identificao Automtica de Veculos
SQL
Structured Query Language
TCP
Transmission Control Protocol
WBS
Workdown Breakdown Structure
13
LISTA DE SMBOLOS
C ou qMAX
capacidade ou fluxo mximo de veculos
Densidade de trfego
Kj
Densidade de saturao
Fluxo de veculos
Vf
Velocidade de fluxo livre
Vs
Velocidade mdia da via
14
SUMRIO
1
INTRODUO ................................................................................................... 17
1.1
Motivao ..................................................................................................... 17
1.2
Objetivo ........................................................................................................ 19
1.3
Organizao ................................................................................................. 19
1.4
Questes ticas ........................................................................................... 20
ASPECTOS CONCEITUAIS .............................................................................. 22

2.1
Tecnologia RFID .......................................................................................... 22
2.2
Linguagens de Programao ....................................................................... 24
2.2.1
Java ....................................................................................................... 24
2.2.2
PHP ....................................................................................................... 25
2.2.3
Google Maps API................................................................................... 25
2.3
Redes ........................................................................................................... 26
2.4
Servidor Web ............................................................................................... 26
2.5
Arquitetura Cliente-Servidor ......................................................................... 27
2.6
Engenharia de Trfego................................................................................. 28
2.6.1
Fluxo de veculos ................................................................................... 28
2.6.2
Velocidade mdia de trfego ................................................................. 28
2.6.3
Status de via .......................................................................................... 29
ESPECIFICAO DO PROJETO DE FORMATURA ........................................ 33

3.1
Funcionalidades do Projeto .......................................................................... 33
3.1.1
Monitoramento e Auxlio no planejamento do Trfego Urbano .............. 33
3.1.2
Apoio Segurana Pblica ................................................................... 34
3.2
Requisitos de Software ................................................................................ 34
3.3
Casos de Uso ............................................................................................... 35
3.4
Tecnologia.................................................................................................... 39
15
3.4.1
Arquitetura proposta .............................................................................. 40
3.4.2
Mapa...................................................................................................... 42
3.4.3
Linguagem de Programao ................................................................. 44
3.4.4
Servidor Web ......................................................................................... 46
3.4.5
Banco de Dados .................................................................................... 46
3.5
4
Modelagem de Dados .................................................................................. 47
METODOLOGIA ................................................................................................ 50
4.1
EAP .............................................................................................................. 50
4.2
Gesto de Riscos ......................................................................................... 52
4.3
Cronograma ................................................................................................. 53
4.4
Desenvolvimento e documentao .............................................................. 54
PROJETO E IMPLEMENTAO ....................................................................... 56

5.1
Arquitetura do Sistema Implementado ......................................................... 56
5.1.1
5.2
Modularizao .............................................................................................. 57
5.2.1
Mdulo Monitor: ..................................................................................... 58
5.2.2
Mdulo Calculadora ............................................................................... 66
5.3
Interface com Usurio .................................................................................. 72
5.3.1
5.4
Funcionamento Geral ............................................................................ 56
Portal do Trnsito .................................................................................. 73
Antenas e Tags ............................................................................................ 75
5.4.1
Processo de Aquisio .......................................................................... 77
5.4.2
Especificaes ....................................................................................... 78
TESTES ............................................................................................................. 80
6.1
Testes do Mdulo Monitor ............................................................................ 80
6.1.1
String com Separador ............................................................................ 80
6.2
Testes do Mdulo de Adaptao .................................................................. 85
6.3
Testes do Mdulo Calculadora..................................................................... 86
16
Trfego Livre ...................................................................................................... 87
Trfego Intenso .................................................................................................. 88
Trfego Lento ..................................................................................................... 88
Trfego Congestionado ...................................................................................... 88
6.4
6.4.1
Primeira parte ........................................................................................ 89
6.4.2
Segunda parte ....................................................................................... 93
6.5
7
Testes do Portal ........................................................................................... 89
Testes Integrados ........................................................................................ 95
CONSIDERAES FINAIS ............................................................................... 97

7.1
Histrico ....................................................................................................... 97
7.2
Balano dos resultados ................................................................................ 99
7.3
Perspectivas de Continuidade.................................................................... 100
7.4
III ENEEEL ................................................................................................. 101
7.5
Comentrio individual de cada aluno ......................................................... 103
Bibliografia ....................................................................................................... 105
APNDICE A - MDULO MONITOR ...................................................................... 107

APNDICE B - MDULO ADAPTADOR ................................................................ 110
APNDICE C - MDULO CALCULADORA ............................................................ 112
APNDICE D Portal ............................................................................................. 115
APNDICE E Instalao dos Softwares de Apoio................................................ 116
APNDICE F CONTEDO DO CD ...................................................................... 131
ANEXO A Resoluo 212 do CONTRAN ............................................................. 132
ANEXO B Proposta para a Q-Free....................................................................... 139
17
1 INTRODUO
A idia central deste projeto surgiu aps o conhecimento da resoluo 212
(ver ANEXO A Resoluo 212 do CONTRAN) do CONTRAN. Os prximos
captulos deixaro claro como foi todo o processo de especificao, de
planejamento, de desenvolvimento e de divulgao.
1.1 Motivao
O projeto foi motivado pela vontade de resolver um problema real que

necessitasse de uma soluo tecnolgica de engenharia: o trnsito. Segundo uma
pesquisa da Fundao Dom Cabral, a mdia anual do crescimento do tempo gasto
nos congestionamento tem aumentado 16% ao ano (desde 2004). A falta de
investimentos em infra-estrutura e transporte pblico aliados ao crescimento do
nmero de veculos so as causas desses congestionamentos caticos. Algumas
reportagens foram essenciais para a nossa motivao e para a definio da
tecnologia a ser usada.
Figura 1 - Reportagem da Veja So Paulo
18
Figura 2 - Reportagem no ESTADO DE SO PAULO
Figura 3 - Reportagem na VEJA

O CONTRAN (Conselho Nacional de Trnsito) baixou a resoluo 212 que
exige a instalao de etiquetas identificadoras em todos os veculos do Brasil
(aproximadamente 46 milhes de carros, motos, caminhes e nibus) at maio de
20081. Esses identificadores so etiquetas RFID similares as etiquetas da empresa
SEM PARAR usadas para identificar veculos nos pedgios de algumas rodovias
brasileiras. A resoluo trouxe a oportunidade de realizar um projeto que teria um
grande impacto positivo na sociedade aproveitando uma infraestrutura que j estaria
pronta e que ainda teramos alguns desafios para resolver, tais como a modelagem
de dados, o clculo e a modelagem do trnsito, a apresentao dos dados, a
simulao e os testes.
No se sabe o motivo mas o projeto do CONTRAN est bastante atrasado e sem previses de
iniciar.
19
1.2 Objetivo
O projeto visa propor uma soluo que atue no monitoramento e,

conseqentemente, apie o gerenciamento, planejamento e fiscalizao de um dos
piores problemas da cidade de So Paulo e de muitas outras cidades grandes do
Brasil e do mundo: o trnsito. A soluo, assim como ser demonstrado mais
adiante, cumpre a sua misso.
1.3 Organizao
Este documento requer uma organizao eficiente para que o leitor possa
entender o projeto desde sua concepo at a implementao, sem perder a linha
de raciocnio. Alm disso, contribui para que o leitor no perca os detalhes
conseguindo estruturar seus pensamentos para um melhor entendimento do
trabalho.
Dessa forma, esta documentao foi dividida em anexos, apndices, lista de
ilustraes, lista de tabelas, lista de abreviaturas e siglas, listas de smbolos e seis
sees alm desta. As seis sees so listadas abaixo:
Seo 2: Aspectos Conceituais
Nesta seo abordamos as tecnologias adotadas para o desenvolvimento do
projeto e suas caractersticas tcnicas.
Seo 3: Especificao do Projeto de Formatura
Aqui est detalhado todo o Projeto de Formatura. Esta seo fruto de um
semestre de trabalho, no qual discutimos as funcionalidades do projeto e
documentamos as questes relacionadas engenharia de software.
20
Seo 4: Metodologia
Na seo de metodologia, o leitor pode encontrar o detalhamento do
planejamento e entender como foi o trabalho do grupo ao longo do desenvolvimento
do projeto.
Seo 5: Projeto e Implementao
Esta seo explica a estrutura do software e suas funcionalidades, alm de
detalhar aspectos do hardware (antenas).
Seo 6: Testes
Documentao de todos os testes realizados com o sistema.
Seo 7: Consideraes Finais
Nesta seo, conclumos o documento mostrando os resultados, perspectivas
de evoluo e opinio dos integrantes a respeito do projeto.
1.4 Questes ticas
Desde o comeo do projeto, fomos muito perguntados quanto privacidade

dos motoristas que estaro sendo identificados constantemente onde houver
antenas monitorando o trnsito. Em apresentaes de andamento do projeto, em
discusses com o professor Hugo Pietrantonio, docente do departamento de
engenharia de transportes, que nos deu grande ajuda neste projeto, e at no III
ENEEEL. Todas essas vezes a pergunta era a mesma: E se algum reclamar que
est sendo monitorado?. Para responder esta pergunta, gostaramos de propor dois
tipos de reflexo: uma tcnica e outra sobre o que j acontece hoje.
Quanto privacidade dos dados e do posicionamento de cada motorista em
determinado momento, importante deixar claro que absolutamente ningum ter
acesso localizao de qualquer pessoa. Isso nunca esteve em discusso.
Continuando, como muitos sistemas de informao, o sistema proposto estar
sob normas de confidencialidade. Se algum ainda no estiver confortvel, dizemos
que para atingir nosso objetivo de monitorar o trfego urbano, no necessrio
21
identificar um motorista. preciso apenas saber que um veculo passou num
instante numa antena e o mesmo passou em outro instante em outra antena. Isso
pode ser resolvido pelo identificador nico que est presente no TAG. Se, mesmo
assim algum no se sentir confortvel, podemos propor que os dados sejam
armazenados
no
Banco
de
Dados
apenas
at
clculo
do
grau
de
congestionamento. Depois estes dados sero eliminados. Mas, definitivamente, no

acreditamos que esta uma boa soluo. Pois estes dados possuem grande valor.
Com um histrico do trnsito, possvel gerar relatrios de tendncias e identificar
gargalos mais facilmente.
O outro lado da discusso que hoje j existem, na cidade de So Paulo,
centenas de cmeras espalhadas pelas vias. Portanto, nosso projeto prope um
monitoramento mais distante das pessoas, pois no capta a imagem de ningum.
Apesar de compreendermos este incmodo com relao invaso de
privacidade que algumas pessoas podem sentir, acreditamos que monitoramento na
dose certa pode ajudar muito na segurana das pessoas. O sistema proposto pode
ser til na aplicao de multas (tanto de velocidade como de rodzio) e os dados
histricos podem ser usados at para traar rotas mais comuns de fuga de veculos
roubados. No o nosso caso, mas um exemplo de que a monitorao pode ajudar
no combate violncia Vinhedo, a primeira cidade brasileira a iniciar o combate a
violncia com o auxilio das cmeras em 2000. Durante os primeiros quatro anos o
resultado foi surpreendente. Os ndices de violncia e criminalidade se reduziram a
praticamente zero. O municpio tem o mais baixo nmero de homicdios e
ocorrncias anuais do Estado de So Paulo e um dos mais baixos do pas (Paoli,
2005).
22
2 ASPECTOS CONCEITUAIS
Neste captulo, iremos apresentar os aspectos conceituais de forma que fique
claro ao leitor o motivo de escolha das tecnologias utilizadas.
2.1 Tecnologia RFID
RFID o acrnimo da expresso Radio-Frequency IDentification. Esta

tecnologia funciona com o par antena-etiqueta (mais conhecida como tag) e
utilizada quando se quer identificar um objeto de maneira nica e a certa distncia. A
etiqueta basicamente um indutor que ao imergir num campo magntico
(proveniente da antena leitora) induz corrente e gera outro campo magntico em
resposta ao sinal emitido pela antena.
O uso desta tecnologia vem se tornando mais comum devido a sua enorme
aplicabilidade. possvel identificar equipamentos, embalagens, produtos, animais,
pessoas, passaporte, etc. Um exemplo de aplicao na rea mdica a
identificao do paciente atravs de RFID (um chip colocado na sua pele) para
que assim o mdico possa identific-lo de maneira mais segura, evitando, assim, a
troca de pronturios por engano. As figuras abaixo mostram o quanto pequeno os
chips podem ser.
Figura 4 - Chip para colocar em pessoas (Langley, 2007)
23
Outro exemplo bastante interessante de implantes de chips RFID em
humanos o uso desta tecnologia para controlar o acesso a determinados locais.
Dessa forma, apenas a pessoa que possui o chip que poder entrar numa
determinada rea de acesso restrito. Algumas aplicaes no varejo tambm esto
sendo estudadas e implantadas. Como por exemplo, o mapeamento de um
estacionamento de um shopping ou supermercado atravs de leitores RFID onde
todos os carros possuem uma TAG. Assim, a gesto do estacionamento pode
informar ao usurio onde h vagas livres. O Wal-Mart usa essa tecnologia para fazer
o controle de estoque. Os produtos possuem identificadores RFID e quando o
mesmo sai de seu estoque, o sistema identifica esta sada e dispara imediatamente
uma ordem de compra para o fornecedor responsvel por aquele produto. Um
sistema que identifica bagagens por RFID e encaminha cada uma automaticamente
ao seu destino tambm seria muito interessante. Reduzindo a interveno humana
neste processo, a probabilidade de erro (bagagens extraviadas) tambm reduzir.
Hoje em dia, possvel citar algumas aplicaes que esto presentes no nosso diaa-dia: pedgio SEM PARAR, bilhete nico, identificao de livros em bibliotecas e de
alguns produtos em supermercados para evitar roubo. Quando um livro ou algum
produto no supermercado passa pela sada sem dar baixa no sistema, escutamos
um aviso sonoro.
H basicamente dois tipos de tag, ativos e passivos. Os tags passivos so os
mais simples e em geral precisam ser lidos a uma distncia curta e s respondem
informando o seu identificador nico. Um exemplo o bilhete nico e etiquetas que
alguns supermercados colocam em CDs. Os tags ativos possuem uma bateria
interna que possibilitam comunicao a uma distncia maior e gravar informaes
internamente. Um exemplo de aplicao de tags ativos o uso do SEM PARAR para
pagar pedgio. O usurio possui um TAG no veculo e ao aproximar-se da cancela a
antena l o TAG, identifica o veculo e a empresa manda a fatura no final do ms.
24
Figura 5 - Bilhete nico
Figura 6 - TAG passivo
Figura 7 - TAG ativo
2.2 Linguagens de Programao
2.2.1 Java
Java uma linguagem de programao orientada a objetos desenvolvida pela
Sun Microsystems na dcada de 90. A diferena tcnica bsica para linguagens
convencionais que o cdigo em JAVA compilado para um bytecode que
executado por uma mquina virtual. Enquanto nas linguagens convencionais, os
programas so compilados para o cdigo nativo da mquina. As suas principais
caractersticas so:
Orientao a objeto;
Portabilidade: um programa em JAVA pode ser executado em qualquer
plataforma que tenha uma Mquina Virtual Java instalada;
Recursos de Rede: possui extensa biblioteca de rotinas que facilitam a
cooperao com protocolos TCP/IP, como, por exemplo, HTTP e FTP;
Segurana: pode executar programas via rede com restries de execuo;
Facilidades de Internacionalizao, pois suporta nativamente caracteres
Unicode2;
distribuda com um vasto conjunto de bibliotecas (ou APIs);
Unicode um padro que permite aos computadores representar e manipular, de forma consistente,
texto de qualquer sistema de escrita existente. Publicado no livro The Unicode Standard, o padro
consiste de um repertrio de cerca de cem mil caracteres.
25
Possui facilidades para criao de programas distribudos e multitarefa, ou
seja, mltiplas linhas de execuo num mesmo programa;
Desalocao de memria automtica por processo de coletor de lixo (garbage
collector). Ou seja, o programador no precisa se preocupar tanto com o
gerenciamento de memria;
Carga Dinmica de Cdigo: os programas em Java so formados por uma
coleo de classes armazenadas independentemente e que podem ser
carregados no momento de utilizao. Assim, a memria utilizada mais
eficientemente.
2.2.2 PHP
A linguagem PHP (Hypertext Preprocessor) tambm uma linguagem
orientada a objetos onde ao invs do cdigo ser compilado, ele interpretado. O
PHP uma linguagem livre e atualmente muito utilizada para gerar contedo
dinmico. Seu escopo o desenvolvimento Web buscando velocidade, simplicidade
e eficincia. Suas principais caractersticas so:
Velocidade;
Robustez;
Estruturao e Orientao a Objetos;
Portabilidade;
Tipagem fraca: no h diferenciao, para o programador, dos tipos de
variveis;
Sintaxe similar a linguagem C/C++ e o Perl.
2.2.3 Google Maps API

A API do Google Maps est totalmente baseada em Java Script e livre.
Caso voc a use para fins comerciais ou o seu site gere mais de 500 mil requisies
por dia, eles recomendam o contato com eles. Para disponibilizar o seu site,
contendo mapa(s) do Google, na Web voc precisa gerar uma chave (Google Maps
API Key). Este processo muito simples, basta digitar a url do site, fazer a
requisio
pronto.
Para
maiores
informaes
acesse
endereo
26
http://code.google.com/apis/maps/.
Neste
endereo
possvel
encontrar
informaes sobre termos de uso, exemplo de cdigos e toda a API.
2.3 Redes
inegvel a importncia de comunicao distncia hoje em dia. Seja ela

atravs da internet, num ambiente empresarial ou domstico.
No projeto a troca de informaes distncia se d de duas formas:
Servidor Web
Arquitetura Cliente-Servidor
2.4 Servidor Web
Partindo da principal idia do projeto de disponibilizar um portal onde qualquer

usurio possa acessar as informaes sobre trnsito, fez-se necessrio um meio
para atingir usurios em massa: a internet.
O servidor web vai servir de apoio para que disponibilizemos as informaes
aos usurios atravs de pginas da web na internet. A funo dele escutar
requisies HTTP ou HTTPS, em portas especficas (80 para HTTP e 443 para
HTTPS).
Abaixo h uma lista de servidores web. O escolhido para o projeto foi o
Apache HTTP Server, cuja escolha justificada no captulo 3 (Especificao do
Projeto de Formatura):
Apache HTTP Server
BadBlue
Caudium
Covalent Enterprise Ready Server
Fnord
IBM HTTP Server
27
Internet Information Services (IIS) da Microsoft
Light HTTP Server (lighttpd)
Oracle HTTP Server
Roxen
Sun Java System Web Server da Sun Microsystems,
thttpd da ACME Laboratories
Zeus Web Server
2.5 Arquitetura Cliente-Servidor
A arquitetura cliente-servidor uma forma de comunicao em que o servidor

espera por requisies dos clientes que, uma vez requisitado, comea uma troca de
mensagens com o cliente. Em um nico servidor podemos ter vrios clientes. A
figura abaixo exemplifica a arquitetura cliente-servidor.
Troca de Mensagens
Troca de Mensagens
Servidor
Troca de Mensagens
Cliente
Cliente
Cliente
Figura 8 - Arquitetura Cliente-Servidor
Os servidores web so exemplos de arquitetura cliente-servidor, onde as

requisies so mensagens de protocolo HTTP.
28
2.6 Engenharia de Trfego
O objetivo deste tpico definir os conceitos bsicos de medio fluxo,

velocidade e tratamento das informaes das vias para o sistema de
monitoramento de trnsito. Para tanto, baseou-se em conceito de engenharia de
trfego explicitados a seguir[10].
2.6.1 Fluxo de veculos

O fluxo (q) de veculos em uma via definido como a razo entre nmero de
veculos em uma determinada faixa de uma via e um intervalo de tempo. Geralmente
considerada como a taxa por hora no qual os veculos atravessam um ponto ou
sesso de uma faixa ou via durante um determinado intervalo de tempo, usualmente
15 minutos, medida em veculos/h[10].
q=
N
T
(1)
Sendo N a quantidade de veculos em um determinado perodo de tempo T.
2.6.2 Velocidade mdia de trfego

Como a velocidade medida do sistema a espacial, ou seja, a mdia ao
longo de um trecho e no em um nico ponto. Por isso a velocidade mdia (Vs) de
uma via dada como a mdia harmnica das velocidades individuais dos
veculos[10]:
Vs =
N
1
i vi
(2)
sendo N o nmero de veculos da amostragem e vi a velocidade mdia do veculo,

dada como a diviso da distncia do trecho percorrido pelo tempo do percurso.
29
2.6.3 Status de via

O objetivo do clculo a partir das definies acima estipular o status de uma
via, categorizando o trnsito em livre, intenso, lento e congestionado.
Diversos fatores caracterizam a complexidade do trfego de uma via, por
exemplo:
O espaamento entre veculos de diferentes dimenses e tipos;
Deve-se considerar a freqncia com que os veculos so encontrados
no trfego;
H a dificuldade de ultrapassagem dos veculos mais lentos;
Possibilidade de escolher a prpria velocidade assim como as
limitaes impostas tanto pela via quanto pelas condies de trfego;
Variaes devido segurana adotada por cada condutor;
Incidentes isolados como acidentes e problemas mecnicos diversos.
Na prtica, a velocidade pontual pode variar de acordo com fatores diversos,
como tipo de veculo (tecnologia, relao peso/potncia), tipo de motorista (motivo
da viagem, perfil individual), via e geometria (desnivelamento, curvatura), volume e
composio do trfego, condies de trfego (clima, visibilidade, controle do
veculo), entre outros fatores que compem a complexidade de uma rede viria.
Ao nvel macroscpico, podemos adotar simplificaes e consideraes para
a modelagem das informaes. Ento, para definir o status de uma via a partir do
fluxo de veculos (q) como a velocidade de trfego (Vs), primeiramente pode-se
observar o comportamento emprico de uma curva de velocidade x fluxo.
30
Figura 9 - Comportamento Velocidade x Fluxo[3]
Simplificando o resultado acima, temos a seguinte curva:
Figura 10 - Simplificao Velocidade x Fluxo[10]
A partir da idia acima ilustrada acima, adotou-se para a classificao da

situao de uma via (status de via) de acordo com quatro combinaes de trnsito
abaixo:
31
Figura 11 - Classificao adotada de status de via
Ou seja, em caso de:

Tabela 1 - Combinaes que classificam o status de via
ALTA
DE VIA
VELOCIDADE
FLUXO DE VECULOS
BAIXA
ALTA
LIVRE
INTENSO
BAIXA CONGESTIONADO
LENTO
A segunda alternativa de modelagem dos dados utilizar outra grandeza

derivada das grandezas explicadas acima: densidade de trfego (K). Para esta
alternativa necessrio a estipulao emprica da densidade de saturao (Kj) e a
partir disso, as faixas de classificao em trnsito livre, intenso, lento e
congestionado.
q = Vs K
(3)
32
Hiptese geral:
K

Vs = Vf 1
Kj
(5)
Os coeficientes e definem a curvatura da curva. Para aspectos prticos, a

simplificao linear (hiptese linear de Greenshields) abaixo j suficiente para a
classificao.
K
Vs = Vf 1
Kj
(4)
Figura 12 - Classificao atravs de densidade de trfego
Ambos os mtodos podem ser refinados devido variao da curva de cada

via em situaes onde ocorrem variaes do tipo dia da semana, situao climtica,
etc. Portanto, previsvel a necessidade de atualizao da capacidade de
atualizao de acordo com estas situaes e o histrico da prpria via.
Na aplicao do prottipo desenvolvido, adotou-se o primeiro mtodo
(velocidade x fluxo) em de maneira simplificada. No entanto, para possveis
evolues, esses mtodos podem ser refinados e melhorados atravs de algoritmos
mais poderosos e dinmicos, visando assim uma melhor eficincia e realidade na
aplicao
real.
33
3 ESPECIFICAO DO PROJETO DE FORMATURA

Este captulo visa demonstrar ao leitor como foi o processo de especificao
do Projeto e os motivos das escolhas de tecnologias.
3.1 Funcionalidades do Projeto
As funcionalidades do Sistema de Monitoramento de Trfego Atravs de RFID

podem ser divididas em dois tipos: Monitoramento e Auxlio no planejamento do
Trfego Urbano e Apoio Segurana Pblica.
3.1.1 Monitoramento e Auxlio no planejamento do Trfego Urbano

A partir do instante de leitura de cada veculo possvel obter a velocidade
mdia numa via por meio de duas antenas leitoras (fazendo a diferena de tempo
entre elas). Aliando esta informao com o fluxo de veculos (nmero de veculos
que passam pela antena por unidade de tempo) pode-se usar modelos matemticos
de Engenharia de Trfego e modelar de maneira precisa o congestionamento na via.
Essas informaes so teis para quem deseja desviar do trnsito e, tendo uma
viso precisa e abrangente do trnsito, para instituies interessadas em gerenci-lo
e planejar maneiras de solucion-lo. O usurio comum (que deseja apenas desviar
do trnsito) visualizar essas informaes atravs de um mapa da regio desejada
acessando o Portal do Trnsito atravs de um computador ou qualquer dispositivo
mvel (veja o exemplo na Figura 14 - Arquitetura do sistema). E rgos e instituies
responsveis pelo planejamento urbano podero visualizar as informaes tambm
a partir de relatrios extrados dos registros histricos que estaro armazenados no
Banco de Dados.
Como j falado anteriormente, a CET no possui um monitoramente eficaz do
trnsito. De acordo com o senhor Luis Molist Vilanova do grupo de desenvolvimento
de trnsito (GDT) da companhia, hoje o monitoramento feito pelos agentes de
34
trnsito e s vezes com o auxlio de cmeras espalhadas pela cidade. Sendo assim,
nosso sistema se torna uma soluo inovadora no monitoramento de trfego.
3.1.2 Apoio Segurana Pblica

Como a etiqueta RFID permite a identificao do veculo de maneira nica e
rpida, ser possvel ter uma fiscalizao constante de carros irregulares numa
determinada via, tais como irregularidades por atraso no pagamento de impostos,
infraes de trnsito (velocidade ou trnsito em rea proibida rodzio de
automveis e de caminhes) ou furto de veculos. Alm disso, persistindo
informaes do veculo e do instante da leitura num banco de dados, ser possvel
se obter:
Relatrios e, com isso, realizar estudos com pontos de maior origem,
destino e a respectiva trajetria, provendo mais ferramentas de deciso
grandes reformas de vias;
Relatrios de rotas mais comuns de fuga de veculos roubados;
ndice de vias com maior incidncia de veculos irregulares e de excesso
de velocidade e de avano de sinal vermelho;
Indicadores de gargalos da cidade.
3.2 Requisitos de Software
Requisitos Funcionais
Uma dos primeiros produtos de reunies do Projeto, aps a definio do
tema, foi o levantamento dos requisitos.
RF1: O sistema deve calcular e apresentar o grau de ocupao das vias
monitoradas.
RF2: O sistema deve calcular, armazenar e apresentar o estado do trnsito,
dos locais onde houver antenas, e a velocidade mdia da via.
RF3: O sistema deve calcular e armazenar a velocidade individual dos
veculos que excederem a velocidade da via para a aplicao de multas de
velocidade, alm da data, hora e via.
35
RF4: O sistema deve adicionar ao cadastro de informaes do veculo as
multas aplicadas.
RF5: O sistema deve identificar e cadastrar veculos que estejam circulando
em dias e horrios proibidos (automveis em dias de rodzio, caminhes em vias
proibidas, caminhes com cargas especiais).
RF6: O sistema deve gerar relatrios de acordo com a demanda. Tais
relatrios devem conter o histrico do fluxo da via, velocidade mdia, quantidade de
carros ao longo do dia, apresentando grficos.
RF7: O sistema deve possuir um perfil de administrador protegido por senha.
RF8: O sistema deve permitir o cadastro de antenas
RF9: O sistema deve permitir o cadastro de vias
RF10: O sistema deve possuir uma interface web de apresentao dos dados.
Requisitos No Funcionais
Para garantir uma preciso nos clculos de fluxo e velocidade, as antenas
devem estar com os relgios sincronizados. Alm disso, as antenas devem ter
conexo com o sistema de forma a enviar os registros lidos com velocidade na
ordem milissegundos e o sistema suport-los na ordem de milhares de antenas.
Para um monitoramento 24 x 7, o sistema deve estar funcionando sem
interrupes, sendo que a central apresentando alta disponibilidade (um dia de
manuteno por ano).
3.3 Casos de Uso
Aps o levantamento dos requisitos, o passo seguinte foi a elaborao dos

casos de uso de forma a atender os requisitos do sistema. Seguem abaixo os casos
de uso elaborados.
Caso de Uso 001
Nome: Cadastro de Antena
Descrio: Responsveis dos rgos de trnsito cadastram uma antena em uma
determinada via.
36
Atores: Responsveis dos rgos de trnsito.
Pr-condio: usurio deve estar logado no sistema.
Curso Normal dos Eventos:
1. Usurio escolhe a opo de cadastro.
2. Sistema apresenta opes de cadastro.
3. Usurio escolhe a opo "Antena".
4. Sistema requisita informaes sobre a antena.
5. Usurio fornece os seguintes dados: identificao da antena, latitude/longitude,
nmero.
6. Sistema consulta o CEP e oferece opes de escolha de endereo ao usurio.
7. Usurio escolhe o endereo.
8. Sistema valida as informaes e atualiza o banco de dados.
Ps-Condio: antena cadastrada.
Caso de Uso 002
Nome: Consulta do Grau de Ocupao da Via
Descrio: Mostra um indicador de ocupao da via.
Atores: Motoristas ou Responsveis dos rgos de trnsito.
Pr-condio: Usurio conectado internet, ferramenta web disponvel e via
previamente cadastrada.
1. Usurio entra no site onde os dados sero apresentados.
2. Sistema apresenta um mapa.
3. Usurio escolhe a via.
4. Sistema consulta o banco de dado e calcula o grau de ocupao.
5. Sistema apresenta o grau de ocupao da via.
Ps-Condio: grau de ocupao da via disponvel na tela do usurio.
Caso de Uso 003
Nome: Consulta da velocidade mdia da via.
Descrio: Mostra a velocidade mdia da via.
Casos de Uso Relacionados:
Atores: Motoristas ou Responsveis dos rgos de trnsito.
37
Pr-condio: Usurio conectado internet, ferramenta web disponvel e via
previamente cadastrada.
1. Usurio entra no site onde os dados sero apresentados.
2. Sistema apresenta um mapa.
3. Usurio escolhe a via.
4. Sistema consulta o banco de dados e calcula a velocidade mdia da via.
5. Sistema apresenta a velocidade da via.
Ps-Condio: velocidade mdia da via disponvel na tela do usurio.
Caso de Uso 004
Nome: Gerao de Relatrio
Descrio: Gera um relatrio com os dados da via consolidados, de acordo com a
data escolhida.
Casos de Uso Relacionados:
Pr-condio: Usurio logado no sistema.
1. Usurio escolhe opo de gerar relatrios.
2. Sistema apresenta dois campos para que seja colocado o intervalo de datas para
a gerao do relatrio.
3. Usurio coloca as datas.
4. Sistema valida datas e apresenta o relatrio.
Ps-Condio: relatrio apresentado na tela do usurio.
Caso de Uso 005
Nome: Aplicao de Multa de velocidade
Descrio: Registra uma infrao se a velocidade mdia do carro for maior que a
velocidade permitida na via.
1. Sistema calcula a velocidade mdia individual dos carros.
2. Sistema verifica se velocidade mdia maior que a permitida
38
2.1. Se velocidade individual maior que velocidade permitida, grava uma multa
associada a esse veculo junto com sua velocidade, via, data e hora da
infrao.
2.2. Se a velocidade no excede a velocidade permitida, nada faz.
Ps-Condio: multa aplicada se velocidade mdia for maior que a permitida.
Caso de Uso 006
Nome: Aplicao de Multa de Permisso de Trfego
Descrio: Gera um relatrio com os dados da via consolidados, de acordo com a
data escolhida.
Pr-condio: Usurio logado no sistema.
1. Sistema verifica se veculo tem permisso para trafegar no dia e horrio atuais.
1.1. Se veculo no tiver permisso para trafegar naquele dia e horrio, registrar
infrao.
Ps-Condio: multa aplicada se veculo no tiver permisso para trafegar na via
naquele dia e horrio.
Caso de Uso 007
Nome: Visualizao do Mapa
Descrio: Fornece a visualizao do mapa mostrando o congestionamento da via
atravs de uma legenda de cores.
Atores: Responsveis dos rgos de trnsito e motoristas.
Pr-condio: Usurio conectado na internet.
1. Usurio entra no site
2. Sistema oferece opes de vias para mostrar o trfego
3. Usurio escolhe a via
4. Sistema apresenta o mapa
Ps-Condio: mapa na tela do usurio com a via escolhida pintada de acordo com
o trfego naquele instante.
Caso de Uso 008
39
Nome: Coleta de dados
Descrio: Armazenamento dos dados do trnsito no sistema.
Atores: Veculos e Antenas
Pr-condio: Antena conectada ao sistema.
1. O veculo (com tag) passa por uma antena
2. A antena l a tag e envia para o sistema
3. O sistema utiliza as informaes geradas pela massa de dados gerada pelas
etapas acima e calcula o ndices e status da via.
Ps-Condio: registro das tags no banco de dados e status da via atualizado.
Tabela 2 Matriz de Requisitos Funcionais x Casos de Usos
RF1
RF2
RF3
RF4
RF5
RF6
CU1
CU2
CU3
RF7
RF8
RF9
X
X
CU4
CU5
CU6
X
X
CU7
CU8
RF10
X
X
3.4 Tecnologia
O escopo do projeto desenvolver um sistema integrado por plataforma web

que coleta informaes em tempo real das vias urbanas, executa clculos em cima
destas informaes e apresenta as informaes obtidas atravs de um mapa. Alm
disso, atravs das informaes coletadas e mantidas ao longo do tempo, permite a
gerao de relatrios e aplicaes de infraes de trnsito como ultrapassar o limite
de velocidade ou circulao no permitida em determinada rea, dia e horrio.
40
Para atingir os requisitos do sistema, foi feito um levantamento de quais
mdulos seriam necessrio para construir uma arquitetura que atendesse as
necessidades. A concluso foi que seria necessrio um banco de dados para gravar
as informaes captadas pelas antenas leitoras RFID, servidor web com suporte a
linguagem de programao escolhida para trabalhar no portal web e uma tecnologia
ou um novo projeto que desenvolvesse uma maneira de desenhar mapas.
As tecnologias foram definidas baseadas no conhecimento das suas
respectivas vantagens (citadas adiante), no atual conhecimento do grupo nessas
tecnologias, no custo da aquisio de eventuais licenas e na facilidade de
desenvolvimento, que implica diretamente no tempo de desenvolvimento. Como o
servidor web depende diretamente da linguagem de programao, primeiro foi
definida a linguagem e depois o servidor.
3.4.1 Arquitetura proposta

A idia inicial era utilizar a arquitetura proposta pelo SINIAV (Sistema
Nacional de Identificao Automtica de Veculos). Porm, at o momento da
especificao do projeto (junho de 2008) a especificao oficial do SINIAV no
estava totalmente finalizada. Por isso, com base nela propusemos nossa prpria
arquitetura.
Antenas estaro espalhadas pela nas vias da cidade lendo os tags dos
veculos que passam e gravando no Banco de Dados o identificador do veculo e o
momento exato em que ele passou. A comunicao entre antena e o Banco de
Dados feita atravs de uma infra-estrutura de comunicao. Nos nossos testes, a
infra-estrutura usada foi a prpria internet. Tambm conectado ao Banco de Dados,
h um servidor dedicado exclusivamente aos clculos que devem ser feitos para
encontrar o grau de congestionamento.
Depois que os dados so coletados e calculados, o Portal do Trnsito
acessa as informaes do Banco de Dados e apresenta ao usurio. O diagrama
abaixo mostra de maneira mais clara como o fluxo de dados do sistema.
41
Figura 13 - Fluxo de Dados
A figura abaixo descreve a arquitetura do sistema no nvel do hardware.
Figura 14 - Arquitetura do sistema
42
O nmero de antenas e o posicionamento de cada uma delas devero ser
proporcionais ao quo detalhado se deseja coletar as informaes do trfego. Ou
seja, quanto mais antenas numa mesma via, mais trechos esto sendo monitorados.
E quanto mais ruas e avenidas possurem antenas instaladas, mais vias estaro
sendo monitoradas na cidade. Mas importante ressaltar que para no necessrio
monitorar o trfego em ruas e avenidas pequenas que no causam impacto
significativo no trnsito de So Paulo ou at mesmo raramente apresentam nvel alto
de congestionamento.
3.4.2 Mapa
A parte mais crtica da especificao da tecnologia foi como mostrar as
informaes atravs de um mapa. O desenvolvimento de uma aplicao ou de uma
inteligncia para desenhar mapas dinamicamente foi considerado algo invivel por
dois motivos: a equipe tem pouca experincia com programao grfica e haveria
um enorme esforo tanto pela complexidade quanto pelo tamanho (se quisssemos
fazer algo para pelos menos uma parte de So Paulo). Portanto, essa tarefa seria
um projeto a parte e foi logo descartada.
Ento, foi adotado o uso de APIs3 do Google Maps. Fazendo uso desta API,
as vantagens so:
Mapas de quase o mundo todo j esto disponveis para o uso (mais do que o
necessrio para o projeto);
Esta API apresenta velocidade de aprendizado e de desenvolvimento
razoavelmente curta, pois um dos membros da equipe j possua experincia
prvia;
No necessrio adquirir licena para uso acadmico.
Porm, as desvantagens so:
Se quisermos vender o projeto para algum interessado, seria preciso negociar
os direitos de utilizao desta API;
Application Programming Interface (ou Interface de Programao de Aplicativos) um conjunto de

rotinas e padres estabelecidos por um software para a utilizao das suas funcionalidades por
programas aplicativos -- isto : programas que no querem envolver-se em detalhes da
implementao do software, mas apenas usar seus servios.
43
Esta API toda baseada em coordenadas, ento ser preciso realizar um
trabalhoso levantamento inicial de coordenadas.
Este levantamento pode ser feito com o auxlio de GPS ou ajustando no
prprio mapa at encontrarmos o ponto exato.
As classes que podem ser usadas para trabalhar com coordenadas so:
Geodesic Polyline;
Ecoded Polylines.
E para trabalhar com endereos:
GDirections.
Para diferenciar o trfego de carros so usadas cores. Essas cores podem
ser configuradas no arquivo de configurao do portal. Um via pintada de vermelho
caracteriza um trnsito congestionado, de laranja um trnsito lento, de azul um
trnsito intenso (est fluindo, mas com grande volume de veculos) e de verde um
trnsito livre. A figura abaixo mostra um exemplo de apresentao do trfego na
sada da USP (porto 1).
Figura 15 - Exemplo de apresentao do trnsito na Sada da USP
44
3.4.3 Linguagem de Programao

A escolha da linguagem de programao foi dividida em duas partes:
programao do portal e programao dos mdulos Monitor e Calculadora.
Quanto ao portal web, foram listadas algumas linguagens que so capazes de
atender a nossa necessidade. As linguagens levantadas foram: ASP, JSP e JAVA.
Como ASP da Microsoft, esta foi logo descartada por motivos de eventuais custos.
Em relao experincia, os membros tm experincia acadmica em JAVA, na
construo de aplicativos e programas, pouca em JAVA para web (JSP e Java
Servlets) e alguma experincia em PHP. Abaixo esto os prs e contras das
linguagens:
Vantagens do PHP
Facilidade de programao;
Por ser uma linguagem mais antiga, a comunidade desenvolvedora em PHP
maior que a do JSP e por isso existem mais fruns, tutorias e ajuda na web;
No preciso fazer o deployment da pgina.
Desvantagens do PHP
Um erro de digitao ou de lgica deve ser testado na pgina para ser
descoberto;
No existe nenhuma ferramenta de teste e de desenvolvimento como,
respectivamente, JUnit e o NetBeans;
Com o PHP no se tem noo de sistema baseado em web, porque cada
pgina um script executado.
Vantagens do JAVA
Facilidade
de
encontrar
erros
desenvolvimento;
Possui frameworks de testes (JUnit);
Tem suporte a Multithread.
Desvantagens do JAVA
pelo
suporte
das
ferramentas
de
45
A programao mais complexa;
A edio e a compilao das pginas so mais lentas;
Principalmente devido ao nmero de APIs, o JAVA consome mais memria.
Balanceando os prs e contras, estvamos certos de que o PHP seria a
linguagem mais indicada para atender eficientemente a nossa necessidade. Mas, o
que nos deixava receosos baixa escalabilidade do PHP que diziam muitos
respeitveis artigos na internet. Ou seja, diziam que o PHP no recomendado para
sites que precisam ser robustos e sero muito acessados, que o nosso objetivo.
Caso o projeto d certo, queremos ver milhes de pessoas e centenas de empresas
de logstica acessando ele todos os dias antes de ir para o trabalho e antes de sair
para realizar uma entrega, respectivamente. Mas as provas vivas de que isso no
verdade so os portais www.facebook.com e o www.myheritage.com. Ambos so
escritos em PHP e possuem milhes de usurios cadastrados e so acessados
constante e diariamente pelo mundo todo. Portanto, aps este impasse, conclumos
que o PHP a linguagem mais adequada ao nosso projeto. Quanto s ferramentas
de teste, pelo grau de integrao e de complexidade do nosso sistema no
consideramos que ferramentas especializadas em teste so de extrema importncia.
Em relao aos ambientes de desenvolvimento, no so de extrema importncia
para desenvolvimento web e tm a desvantagem de alguns serem pesados (como
por exemplo, o NetBeans). Alm disso, se algum achar necessrio um ambiente de
desenvolvimento, j existem alguns plug-ins que esto sendo criados e que logo
estaro disponveis.
Alm do PHP, as APIs do Google Maps esto em Java Script. Portanto ser
usado Java Script para a manipulao e apresentao do mapa. Tambm
estudamos CSS4 para deixar os layouts das pginas do portal e do Projeto mais
amigveis.
Finalmente, devido familiaridade dos membros com conexo a Banco de Dados
nesta linguagem e pela rapidez para se trabalhar com clculos, a linguagem JAVA
foi escolhida para programar os mdulos Monitor e Calculadora.
4
Cascading Style Sheets (ou simplesmente CSS) uma linguagem de estilo utilizada para definir a
apresentao de documentos escritos em uma linguagem de marcao, como HTML ou XML. Seu
principal benefcio prover a separao entre o formato e o contedo de um documento. Ao invs de
colocar a formatao dentro do documento, o desenvolvedor cria um link (ligao) para uma pgina
que contm os estilos, procedendo de forma idntica para todas as pginas de um portal. Quando
quiser alterar a aparncia do portal basta portanto modificar apenas um arquivo.
46
3.4.4 Servidor Web

O servidor web escolhido foi o Apache. Este servidor gratuito, robusto e
existem vrios tutoriais na internet mostrando como integr-lo com o PHP e o Banco
de Dados escolhido (MySQL). Como a figura abaixo mostra, o Apache usado por
quase dos desenvolvedores. Isso gera um grande nmero de informaes em
fruns e tutoriais na internet e melhorias constantes.
Figura 16 - Web Servers Market Share (Web Server Survey, 2008)
3.4.5 Banco de Dados

Para o nosso projeto acadmico, o Banco de Dados no ser nenhum ponto
crtico. Mas pensando em viabilizar o projeto num produto, buscamos usar um
Banco de Dados gratuito e robusto. Portanto foram levantados os candidatos
MySQL e PostgreSQL pelos seguintes motivos:
So os Bancos de Dados livres mais populares;
So os projetos mais antigos e maduros;
Compatveis com praticamente qualquer sistema operacional.
Vantagens do MySQL
Otimizado para aplicaes Web, isto , focado na agilidade;
47
Trabalha muito bem em conjunto com o PHP;
muito comum encontrar servios de hospedagem de sites que oferecem o
MySQL e a linguagem PHP;
Possui uma licena comercial que permite obter suporte diferenciado aos
desenvolvedores.
Vantagens do PostgreSQL
Possuir recursos comuns a banco de dados de grande porte, o que o deixa
apto a trabalhar com operaes de misso crtica;
Otimizado para aplicaes complexas, que envolvem grandes volumes de
dados ou que tratam de informaes crticas;
Alm dos pontos citados a cima, importante citar que o grupo j possui
experincia com o gerenciador MySQL Control Center e o phpMyAdmin. Este
ltimo permite o gerenciamento do Banco de Dados utilizando somente um browser
qualquer.
Concluindo, para a nossa necessidade, o Banco de Dados MySQL se encaixa
melhor. Mas isso no quer dizer que o MySQL melhor que o PostgreSQL. Nossa
deciso foi baseada principalmente na agilidade para aplicaes Web simples que o
MySQL apresenta, pois imaginamos que o nosso Portal seria acessado
constantemente por milhes de pessoas, e no excelente relacionamento com a
linguagem PHP.
3.5 Modelagem de Dados
O diagrama ER (Entidade Relacionamento) foi desenvolvido no primeiro ms

do projeto, logo aps o levantamento dos requisitos. Porm, ele passou por
pequenas modificaes at meados de julho de 2008. O objetivo de um diagrama
ER , alm de fornecer uma viso geral do projeto, evitar modificaes bruscas e
retrabalho futuramente. Portanto, ao constru-lo, a equipe passou muitas horas
discutindo e alterando este diagrama. Como o diagrama no foi alterado nos ltimos
trs meses, pico do desenvolvimento, o objetivo foi cumprido.
48
As principais entidades so o trecho (tabela TRACK), o ponto (tabela POINT),
a rea ou regio (tabela AREA) e os tags lidos (tabela READ_TAG). Um ponto
uma coordenada geogrfica (latitude e longitude) necessria para traar uma linha
no mapa. Uma linha uma ligao de pontos. Por isso, antes de tudo, necessrio
cadastrar os pontos do trecho que pretendemos medir. E numa via que faz curva,
sero necessrios vrios pontos para formar a curva.
No ponto, pode ter ou no uma antena leitora de tags. Um trecho um
intervalo entre uma antena e outra, ou seja, entre um ponto que tem antena e outro
ponto que tem antena. Entre esses dois pontos pode haver um ou mais pontos,
depende do tamanho do trecho e da preciso requerida do traado. S para dar uma
noo desta proporo de pontos para os trechos, o exemplo da Figura 15 possui
cinco trechos e vinte e oito pontos.
O trecho est relacionado com a rea de visualizao no mapa. Uma rea
pode conter um ou mais trechos. A tabela READ_TAG registra os tags lidos que
passaram por determinado ponto. Obviamente neste ponto existe uma antena. Alm
dessas entidades citadas, temos a tabela de endereos (ADDRESS), usada para
cadastrar o endereo de uma antena instalada, a tabela de multas (FINE) usada
para registrar as multas aplicadas, a tabela STATUS que usada para armazenar
os ltimos valores das variveis velocidade e fluxo de veculos e as chamadas
tabelas administrativas (USER, VEHICLE, TAGS e DRIVER). Estas ltimas no
fazem parte do escopo do projeto, pois numa implantao real, as tabelas dentro no
retngulo deveriam ser as mesmas das instituies responsveis por manter essas
informaes (como o DETRAN, CONTRAN, etc.). E a tabela de usurio deveria estar
sob responsabilidade de quem administraria o sistema. Todas essas informaes
citadas anteriormente podem ser observadas na Figura 17.
49
Figura 17 - Diagrama ER
50
4 METODOLOGIA
O objetivo desta seo apresentar a metodologia de gesto de projeto,

assim como as ferramentas utilizadas na especificao, fase inicial do projeto.
Figura 18 Processo bsico de gesto de projeto
4.1 EAP
Depois de definir o escopo do projeto, a tarefa seguinte foi trabalhar a EAP

(Estrutura Analtica de Projeto) ou WBS (Work Breakdown Structure). Assim,
identificando os resultados do projeto e decompondo-os em componentes tangveis
e verificveis, sendo possvel acompanhar claramente o progresso do projeto e
comprometer cada membro da equipe com suas respectivas responsabilidades.
51
Sistema de
Monitoramento de
Trfego
Sistema RFID
Antena
Arquitetura
Transponder
Interface Grfica
Pginas e
Formulrios
Simulao
Banco de
Dados
Simulao e Testes de
aceitao
Aplicativo
Mdulo
Monitor
Recepo e
Tratamento
da String
Mdulo
Calculadora
Armazename
nto no BD
Clculo de fluxo
de veculos
Mapa
Clculo de
Velocidade
Mdia da Via
Fiscalizao
Rastreamento de
veculos
irregulares
Permisso de
trnsito/rodzio
Excesso de
velocidade
Documentao
irregular
Figura 19 EAP
Como ilustrado acima, o projeto se decompe em trs grandes blocos: o

sistema RFID, a arquitetura do sistema e a interface grfica.
O primeiro basicamente suprido pelo emprstimo de antenas e tags da
aplicao em pedgios, pelo qual se pode verificar viabilidade da tecnologia para tal
fim, necessitando eventualmente adaptaes para grande escala para cobertura
metropolitana.
O segundo bloco engloba uma parte importante do trabalho, a arquitetura
visando s funcionalidades propostas. Contm um sistema de banco de dados
comum e a modularizao principal: monitor e calculadora. O mdulo de fiscalizao
no foi tomado como foco do sistema por motivos diversos como regulamentaes
governamentais, acesso a dados e necessidade de maior interao com rgos de
trnsito para obter requisitos reais para tal fim. No entanto, dada a estrutura de
dados construda pelos outros dois mdulos e a base de dados, o esforo para
implantar tal funcionalidade pequeno.
Por fim, o terceiro bloco trata da interao de usurios com os dados, alm da
interface do mapa destacado como diferencial do sistema para apresentao dos
dados.
52
4.2 Gesto de Riscos
Com o objetivo de aumentar a probabilidade de ocorrncia de eventos

benficos ao projeto e, principalmente, reduzir a probabilidade de eventos adversos,
utilizou-se a tcnica do Diagrama de Causa e Efeito (Espinha de Peixe) figura
abaixo para identificar as possveis causas do fracasso do projeto.
As possveis causas de um eventual fracasso no projeto so:
1. Impossibilidade Tcnica:
Devido a no compatibilidade do leitor RFID com o PC, necessitando a
construo de uma interface complexa e assim fugindo do escopo do projeto ou a
performance pode ser muito abaixo para a escalabilidade desejada. Isto pode
acontecer por motivos de infra-estrutura (rede de comunicao entre cada antena), o
banco de dados pode no suportar o volume de dados necessrio, ou at mesmo o
leitor RFID conseguido pode ser lento em relao velocidade que precisamos dos
dados.
2. Indisponibilidade de leitores/antenas e/ou etiquetas:
Podemos no conseguir esses equipamentos por simplesmente no estarem
disponveis no fornecedor, por apresentarem um custo muito alto que inviabilize a
sua utilizao ou por at falta de planejamento e/ou comprometimento na procura de
emprstimos, compras ou acordos com fornecedores ou com a prpria universidade.
3. No concluso no prazo estabelecido
Mesmo que o projeto esteja progredindo com sucesso, se ele no estiver
concludo na data estabelecida, isto implicar em fracasso do projeto. Isto pode
acontecer principalmente por falta de planejamento ou do comprometimento. Por
este motivo muito importante o planejamento que est sendo feito nesta primeira
etapa do projeto. Para tentar inibir a falta de comprometimento de qualquer membro
da equipe a atribuio de responsabilidades muito til.
Tambm
importante
esforo
inicial
para
definir
especificar
detalhadamente o projeto para que se evite a escolha de solues complexas que

demande muito mais tempo do que outras ou at mesmo que se defina o quanto
antes as tecnologias a serem usadas para possibilitar o estudo e o aprofundamento
nestas tecnologias.
53
Aumentando nosso conhecimento nestas tecnologias tambm poderemos
planejar o esforo necessrio para a concluso do projeto. Alm disso, o
planejamento importante para evitar o aparecimento de novas variveis que no
foram previstas. Quanto mais planejamento e estudo houver nesta primeira fase,
menos provveis sero os eventos adversos. Todo o planejamento tambm deve ser
constantemente revisto.
Impossibilidade Tcnica
Necessidade de
Criar um aplicao
Complexa para ler
O ID do hardware/leitor
Infra
BD lento
insuficiente
Leitor RFID
No compatvel com PC
Leitor
RFID
Lento
Performance ser
Muito abaixa do
necessrio
Fracasso do Projeto
Inexistncia de
Atribuio de
responsabilidades
Surgimento de
Novas Variveis
Planejamento
Insuficiente
Falta de comprometimento
No disponvel no
fornecedor
Escolha de
Tecnologias
complexas
Demora na escolha
das tecnologias a serem usados
Falta de
Planejamento
Dificuldade
De simulao
Falta de Planejamento
Da construo
Da simulao
Falta de planejamento
Para a procura
No conseguir
Leitor e Etiquetas
No Concluso
No prazo
Figura 20 - Diagrama de Ishikawa (Causa e Efeito)
4.3 Cronograma
A partir do escopo especificado na EAP, puderam-se definir facilmente os

prazos, interdependncias e recursos para a implementao. A figura abaixo
representa o cronograma inicial do projeto que deu base s atividades, discusses
peridicas de andamento e lista de atividades. As atividades foram divididas em
conjuntos: Sistema RFID, Interface Grfica, Banco de Dados, Aplicativo, Simulao
e Documentao Final.
54
Figura 21 Cronograma Inicial
A meta inicial foi finalizar todas as funcionalidades at metade de novembro,

restando atividades de concluso como documentao e outros ajustes adicionais.
4.4 Desenvolvimento e documentao
Para a parte de especificao, baseou-se nas tcnicas de engenharia de

software para detalhar os requisitos e casos de usos. No caso de hardware, os
equipamentos foram fornecidos com suas prprias especificaes e, com isso,
integrados a computadores e rede de internet.
O projeto foi executado por um grupo de trs pessoas, o que d margem
documentao falha e desencontrada. Para melhorar a qualidade da documentao,
pde-se separar nitidamente atravs da implementao por mdulos e, para
documentao comum, o controle de verses, definindo para cada item
responsabilidades bem definidas.
55
Figura 22 Diviso de responsabilidades macro no projeto
56
5 PROJETO E IMPLEMENTAO
Neste captulo esto os detalhes inerentes ao projeto e implementao do
sistema especificado no captulo 3. O leitor conhecer toda a lgica de
desenvolvimento e detalhes importantes para entender como foi feito para que
fossem atendidos os requisitos funcionais e no-funcionais do sistema.
5.1 Arquitetura do Sistema Implementado
Observe abaixo a arquitetura do sistema desenvolvido durante o projeto:
Figura 23 - Arquitetura do Sistema Desenvolvido
A figura acima ir auxiliar o entendimento do leitor na prxima seo.
5.1.1 Funcionamento Geral

Numa viso geral, que ser detalhada nas sees seguintes, um carro
equipado com uma tag RFID passa por uma antena instalada em alguma via. A
antena grava algumas informaes na tag e gera um registro com data, hora,
identificador da tag entre outros. Tal registro enviado pela porta serial (RS-232) ao
Mdulo Adaptador que, por sua vez, envia o registro atravs da internet ao servidor
onde esto os outros mdulos.
Quem recebe esse registro o Mdulo Monitor, que deve tratar a string,
retirando os campos de interesse e enviar ao banco de dados. O Mdulo
Calculadora vai utilizar os dados gravados pelo mdulo anterior para fazer os
57
clculos e classificar o trnsito. Feito isto, grava seus resultados no banco de dados,
disponibilizando ao website as informaes a serem apresentadas ao usurio.
5.2 Modularizao
Inicialmente, a idia era fazer um nico software que tivesse todas as funes
necessrias para atender os requisitos do projeto. Portanto, utilizando-se do lema
dividir para conquistar, dividiu-se o software em dois mdulos: Mdulo Monitor e
Mdulo Calculadora. Mais tarde fez-se necessria a adio de mais um mdulo, o
Mdulo Adaptador.
As vantagens dessa diviso foram enormes. Em primeiro lugar, o
desenvolvimento pde ser dividido, no havendo dependncia entre a concluso dos
mdulos. Isso foi possvel porque se usou o banco de dados como conexo. Sendo
assim, o Mdulo Calculadora, por exemplo, s precisava que houvesse dados
colocados manualmente no banco de dados, para que seus testes pudessem ser
feitos.
Outro ponto importante que o processamento pode ser distribudo, os
mdulos no necessitam estar na mesma mquina, nem os mdulos, nem o banco
de dados e nem o website. por isso que o Mdulo Adaptador, que mais leve que
os demais, pode rodar num thin client reduzindo os custos, pois cada antena
precisa de um Mdulo Adaptador, e apenas um Mdulo Monitor e um Mdulo
Calculadora so suficientes.
Abaixo h um diagrama da modularizao do software:
Figura 24 - Modularizao do Software
58
Nas sees que seguem, sero detalhados cada um destes mdulos.
Primeiro os Mdulos Monitor e Calculadora, depois o Mdulo Adaptador, j que sua
idia e desenvolvimento vieram depois.
5.2.1 Mdulo Monitor:

Nesta seo, so detalhadas questes tcnicas e funcionais a respeito do
Mdulo Monitor. Antes de comear, interessante situar o leitor a respeito do
ambiente onde este mdulo est inserido.
Concepo
Quando se comeou a pensar na implementao do programa que manipula
os dados, foi decidido dividi-lo em dois mdulos: mdulo monitor e mdulo
calculadora, como j mencionado anteriormente.
Para melhor entendimento, segue a figura abaixo com o fluxo de dados entre
os mdulos, o banco de dados e o website:
Figura 25 - Fluxo de Dados do Software
O mdulo monitor tem a funo de receber os dados da rede e manipul-los

para formar a string a ser enviada ao banco de dados.
Basicamente, este mdulo um servidor TCP/IP que permite a conexo de
mltiplas antenas para o recebimento de dados. Ao receber o dado, o Monitor deve
tratar a string recebida e gravar os dados recebidos no banco de dados, para que o
Mdulo Calculadora possa utiliz-los. Confira abaixo o fluxograma do Monitor:
59
Figura 26 - Mdulo Monitor - Fluxograma
De modo a facilitar o estudo deste mdulo, dividi-lo-emos em trs etapas,

indicadas em tracejado na figura acima. A cada uma destas etapas podemos atribuir
as seguintes funes:
Etapa 1 - Servidor;
Etapa 2 - Tratamento de string;
Etapa 3 - Gravao no banco de dados.
Etapa 1:
Na primeira etapa, a funo prover um servio numa porta TCP/IP para que
as antenas possam se conectar ao mdulo e enviar os dados coletados. Para isso,
foi criado um ServerSocket na classe IniciaServico, que como o nome j diz,
60
responsvel por iniciar a escuta por requisies de clientes e aceit-las. Alm disso,
ao iniciar o servio e aceitar conexes, exibe na tela informaes de IP, hostname e
porta, do servidor e do cliente.
Quando um cliente aceito pelo servidor, o mdulo dispara uma thread que
trocar mensagens com o cliente, at que uma das duas pontas desconecte.
Para um melhor entendimento, abaixo esto as classes e os relacionamentos
referentes ao mdulo monitor.
Figura 27 - Mdulo Monitor - Diagrama de Classes Simplificado
Etapa 2:
A etapa dois foi a mais trabalhosa e complexa das trs. Tal etapa se fez
necessria para que fosse satisfeito um dos requisitos do projeto: compatibilidade.
Compatibilidade, neste contexto, se entende por capacidade de comunicao do
software com qualquer antena de radio freqncia. Antes de explicar como fizemos
61
o software ser compatvel com a maioria dos equipamentos, vamos mostrar quais
informaes preciso receber das antenas.
De modo a atender o Mdulo Calculadora, o Mdulo Monitor deve popular o
banco de dados com as seguintes informaes:
Identificador da Antena (no cdigo chamado de idAnt);
Identificador do Automvel (no cdigo chamado de idTag);
Data da leitura (no cdigo chamado de data);
Horrio da leitura (no cdigo chamado de hora).
Pelo conhecimento prvio da equipe de equipamentos que gravam registros e
depois os transmite (seja para outros dispositivos ou para uma planilha de dados),
concluiu-se que a string de dados recebida pela antena poderia assumir um dos dois
formatos abaixo:
String com campos de tamanho fixo;
String com campos separados por um separador (caractere).
String com campos de tamanho fixo
Para se trabalhar com strings deste tipo, duas informaes so necessrias e
suficientes: o tamanho e o offset de cada campo.
Tendo estas duas informaes em mos, ao receber uma string, o software
se utiliza da funo substring do Java, que retira um trecho de uma string a partir
das informaes citadas acima.
Desta string, essencialmente sairo quatro campos: identificador da antena,
identificador da tag, data e hora. Data e hora requerem tratamento especial que ser
detalhado adiante.
Exemplo de string com campos de tamanho fixo:
1234567890098765432115102008113255
Identificador da Antena:
62
o Tamanho = 10
o Offset = 1
Identificador da Tag:
o Tamanho = 10
o Offset = 11
Data:
o Tamanho = 8
o Offset = 21
Hora:
o Tamanho = 6
o Offset = 29
O tratamento da string acima gera os seguintes resultado:
Identificador da Antena: 1234567890
Identificador da Tag: 0987654321
Data: 15102008
Hora: 113255
String com campos separados por um separador (caractere).
Strings separadas por caracteres so mais flexveis e fceis de trabalhar. As
informaes necessrias para este tipo de string so o caractere separador e a
ordem dos campos na string, no software chamado de nmero de campo.
Para tratar este tipo de string, primeiramente a string recebida separada em
campos (de acordo com o caractere separador) e depois armazenada num vetor.
Com o nmero de campo e o vetor, conseguimos extrair os campos de interesse.
Exemplo de string com campos de tamanho fixo:
923874#4y2i3#171008#200559 (IDANTENA#IDTAG#DATA#HORA)
o Nmero de Campo = 1
63
Data:
Hora:
O tratamento da string acima resulta em:
Identificador da Tag: 4y2i3
Data: 171008
Hora: 200559
Tratamento da data
O campo data possui trs questes que devem ser tratadas. A primeira delas
diz respeito separao de dia, ms e ano, na qual camos no mesmo dilema da
string: com separador ou campos de tamanho fixo? A segunda a ordem entre
essas informaes: dia, ms e ano ou ano, ms e dia, e assim por diante. Por ltimo,
o formato do ano, que pode possuir com dois ou quatro dgitos (yy ou yyyy
respectivamente).
Cada uma destas questes deve ser configurada e tratada corretamente,
caso contrrio, o registro pode ser gravado com a data errada.
Tratamento da hora
O tratamento da hora idntico ao da data, a menos da questo do ano .
Temos as duas situaes: utilizando separador entre hora, minuto e segundo ou
utilizando com campos fixos. importante saber tambm qual a ordem desses
argumentos na string: hora, minuto e segundo ou segundo, minuto e hora, e assim
por diante.
Data e Hora
64
Cabe neste momento uma observao. Data e hora podem ser registrados,
em alguns equipamentos, em um nico campo em forma de tempo. Uma forma
comum milissegundo. Fixa-se uma data zero e os segundos so contados a partir
desta data. De acordo com o nmero de milissegundos passados, pode-se obter a
data e a hora correspondente. Nosso equipamento (antenas) grava data e hora num
nico campo, em forma de segundos. A data zero fixada 01 de janeiro de 1970 e
0h00, o que nos pareceu ser padro j que o Java possui uma API que transforma
milissegundos em data e hora com a mesma data zero.
Exemplo:
Data e hora recebido do equipamento: 1227384962671
Transformado para data e hora: 2008-11-22 17:16:02
Explicados os tratamento de string, deve-se gravar os dados tratados no
banco de dados, pulemos, ento, para a Etapa 3.
Etapa 3:
Agora, aps recebida e tratada a string, o momento de gravar os dados no
banco de dados. A funo de gravao do banco de dados chamada passando-se
os seguintes parmetros: identificador da antena, identificador do tag, data e hora.
Data e hora devem ser agrupadas num nico campo com o seguinte formato:
2008-11-01 19:07:23
Nessa funo, gerada a string SQL, exemplificada abaixo:
INSERT INTO TRAFFIC VALUES(0658 , 20082008-1111-01 19:07:23,
"0155)
Onde,
Data e Hora: 2008-11-01 19:07:23
Identificador da Tag: 0155
Neste ponto, termina a funo do Mdulo Monitor, que aps disponibilizar os
dados no banco de dados, passa a responsabilidade para o Mdulo Calculadora.
65
5.2.1.1 Mdulo de Adaptao de Comunicao
Inicialmente, o software foi projetado para se comunicar com o meio externo
(antenas) atravs da internet. Por isso, toda comunicao no que diz respeito
recepo de dados, foi baseada no protocolo TCP/IP.
De fato, quando se obtiveram as antenas, percebeu-se que estas tinham
porta RJ-45 o que permitiria a comunicao atravs da internet. Porm, toda
configurao deste hardware deve ser feita atravs da porta serial (RS-232). Por
isso, construiu-se um mdulo de adaptao para trabalhar em conjunto com a
antena, assim toda comunicao com a antena, desde configurao at recepo de
dados, feita atravs de comunicao serial.
Para fins de projeto, estamos usando um PC para rodar tal mdulo, mas num
projeto real, um thin client (que possui um custo bem menor do que um PC) daria
conta do recado.
Detalhes do Mdulo Adaptador
Inicialmente, o usurio informa ao programa, assim como em grande parte
dos programas de comunicao serial, em qual porta o dispositivo est conectado. O
usurio deve tambm fornecer informaes como velocidade da porta, bits de
parada, bits de dados e paridade. Estas informaes servem para conectar o mdulo
porta serial.
Entrando um pouco mais no detalhe da antena escolhida para o projeto,
modelo MD 5850M da Q-Free (que ser detalhada mais a frente), esta necessita de
algumas configuraes iniciais, como por exemplo seu identificador, cuja varivel na
antena chama-se Plaza; a data e a hora, ajustados em milissegundos passados
entre a data atual e 01/01/1970 s 0h00, como j mencionado na seo anterior.
Alm disso, preciso, periodicamente, enviar um comando, o StepId, para que a
antena leia novamente um tag j lido.
Para leitura de dados, foi implementada uma classe que espera eventos toda
vez que h dados na serial. Uma vez detectados dados na serial, estes so retirados
e analisados. Se forem dados vindos das tags (esses dados comeam com *I),
envia-os para a classe de cliente que por sua vez, envia para o servidor (mdulo
monitor).
Como pde se observar, apesar da manipulao da porta serial ser um pouco
complexa (no existe API de serial da Sun para Windows, foi usada uma alternativa,
66
RxTx), o mdulo no possui muitas funes, apenas envia os registros recebidos
atravs da serial ao Mdulo Monitor.
Segue abaixo o diagrama de classes simplificado deste mdulo:
Figura 28 - Mdulo Adaptador - Diagrama de Classes Simplificado
5.2.2 Mdulo Calculadora

O objetivo desta seo definir o papel de automatizao pelo sistema do
clculo das grandezas definidas na seo 2.6.
A fonte dos dados a serem trabalhado so os registros fornecidos pela antena
em tempo real. O armazenamento dos dados papel do Banco de Dados,
basicamente concentrada numa tabela com os dados de cada trecho.
67
A cada Intervalo de
Amostragem,
executa
Conexo ao BD
Para trecho antena cadastrado:
Clculo de
Fluxo
STATUS
READ_TAG (Registros)
Clculo de
Velocidade
ID_READ_TAG
READ_AT
READ_ON
Registro de
Status de Via
ID_TRACK
V
Q
CALC_AT
TRACK
ID_TRACK
STATUS
Figura 29 Fluxo bsico do modulo calculadora
Fluxo de veculos
Na aplicao real, a preciso da medio depende de diversos fatores como:
O comprimento do trecho (macroscopicamente como densidade de
antenas distribudas);
A possibilidade dos veculos trafegarem para fora e para dentro do
trecho;
68
Partida e estacionamento para o interior do trecho monitorado alm de

outras possibilidades.
Figura 30 - Exemplo de pontos possveis de sada e entrada de veculos em trecho AB monitorado
Portanto, adotou-se como estimativa do fluxo de veculos (q) de um trecho

como a mdia do fluxo do das duas antenas que o definem. Ou seja:
qAB =
qA + q B
2
(1)
Ni
T
(2)
Sendo[10]
qi =
calculado com a quantidade Ni de veculos (tags) registrados pela respectiva

antena i no tempo de amostragem T.
A consulta utilizada para contagem dos registros lidos pelas antenas A e B
dentro do ltimo intervalo de amostragem simples, exemplificado no exemplo
abaixo (nomes das tabelas conforme item 3.5):
SELECT Count(ID_READ_TAG) FROM read_tag WHERE READ_ON LIKE A
OR B AND READ_AT > <DATAHORA>
<DATAHORA>
sendo <DATAHORA> = AGORA intervalo de amostragem, no formato aaaamm-dd hh:mm:ss
69
Finalmente, dividindo o resultado da operao por 2, obtm-se a mdia de
veculos registrados por ambas as antenas do trecho, ou seja, o fluxo qAB.
Velocidade de trfego
A velocidade mdia de trfego, por sua vez, contm mais fatores
complicadores alm das mencionadas para o fluxo de veculos, pois se pode
considerar para o clculo apenas a velocidade dos veculos que trafegaram
necessariamente pelas duas antenas. Apesar disso, os veculos que adotam trafegar
em vias paralelas ou estacionar no interior do trecho e voltam ao trecho podem
distorcer a mdia real. O tratamento adotado a adoo de um fator de corte
utilizado para desconsiderar casos muito fora da curva para a velocidade, isto ,
caso a velocidade individual do veculo seja muito inferior mdia do trecho, este
descartado do clculo.
(3)
Figura 31 Dados para clculo da velocidade de um veculo
Clculo da velocidade de cada veculo considerado, com Vi a velocidade de

cada veculo, relacionado pelo ID_READ_TAG.
Finalmente, a velocidade considerada como a mdia harmnica das
velocidades Vi.
70
Vs =
N
N
(4)
Para se obter a velocidade de cada veculo, a consulta SQL um pouco mais

elaborada. Exemplo simplificado:
Obtendo a lista das tags lidas na antena B e seu respectivo instante de leitura:
SELECT ID_READ_TAG, READ_AT FROM read_tag WHERE READ_ON LIKE
B AND READ_AT > <DATAHORA>
DATAHORA>
sendo <DATAHORA> = AGORA intervalo de amostragem, no formato aaaamm-dd hh:mm:ss.
Para cada ID_READ_TAG da lista, obter o registro do mesmo tag na antena A:
SELECT ID_READ_TAG, READ_AT FROM read_tag WHERE READ_ON LIKE
A AND ID_READ_TAG LIKE <tag_i>
<tag_i> AND READ_AT > <
<DATAHORA>
DATAHORA>
GROUP BY READ_AT DESC
sendo <DATAHORA> = AGORA distncia/velocidade mnima considerada,
no formato aaaa-mm-dd hh:mm:ss. A ordem decrescente apenas garante que seja
o ltimo registro.
Para gravar os resultados de volta ao banco de dados, usa-se o comando
INSERT. Exemplo:
INSERT INTO status (
(`ID_TRACK`,
`ID_TRACK`, `q`, `v`, `calc_at`)
`calc_at`) VALUES
(<id do trecho>, <fluxo>, <velocidade>, <DATAHORA>)
onde calc_at o instante do respectivo clculo.
71
Figura 32 Diagrama de Classes do Mdulo Calculadora
Os fluxogramas das rotinas do mdulo se encontram no APNDICE C

Mdulo Calculadora.
72
5.3 Interface com Usurio
Para a apresentao das informaes ao usurio, foi desenvolvido o Portal do

Trnsito (h um link para o Portal no site do nosso Projeto de Formatura que foi
disponibilizado no site do departamento PCS).
Figura 33 - Pgina inicial do Web Site do Projeto de Formatura
Toda a interface foi desenvolvida de maneira simples e intuitiva. No Porto do

Trnsito, o usurio visualiza o trfego de uma regio com apenas um clique. De
maneira que o usurio que sai de casa atrasado se sinta encorajado a investir um
tempinho a mais para saber como esto as ruas que ele vai percorrer.
A imagem superior, presente em todas as pginas do portal e do site, aliada a
cor verde de tonalidade suave, tenta passar a idia de sustentabilidade. Pois, afinal,
ajuda a pelo menos controlar o trnsito, uns dos maiores emissores de poluentes.
73
Um arquivo CSS foi criado para desvincular o layout com o contedo. Dessa
forma, o desenvolvimento se tornou muito mais gil do que se no utilizssemos o
CSS.
5.3.1 Portal do Trnsito

Como j foi dito, o Portal simples e intuitivo. A figura abaixo mostra a pgina
inicial, onde o usurio precisa somente escolher qual a regio que ele deseja
visualizar o trnsito.
Figura 34 - Portal do Trnsito
Ao clicar no boto Mostrar Trfego, o Portal abre uma pgina com o mapa
da regio solicitada e com os trechos pintados de acordo com o grau de
congestionamento. A Figura 15 mostra mostra um exemplo de trechos sendo
monitoradas na sada da USP. Apesar de haver apenas duas pginas de
navegao, arquitetura do portal envolve dezenas de arquivos de funes.
O processo de desenvolvimento se baseou na seguinte cronologia:
1. Desenvolvimento de funes que acessam o banco de dados;
74
2. Desenvolvimento de funes para agilizar o desenvolvimento e a depurao
de erros;
3. Ligao de uma pgina HTML simples com o arquivo CSS style.css;
4. Insero, na pgina inicial, da lgica de buscar e disponibilizar para escolha
as reas disponveis;
5. Insero do insero do mapa proveniente de Google Maps dentro da tag
div na pgina byarea.php, responsvel por buscar os trechos do mapa
solicitado da pgina map.php;
6. Insero da chave do Google Maps necessria para a disponibilizao do site
na internet;
7. Criao da lgica que pinta os trechos de acordo com o grau de
congestionamento na pgina byarea.php;
8. Criao de mecanismos que tornam o portal mais flexvel. Como por exemplo,
possibilidade de mudar a cor de um determinado grau de congestionamento;
9. Criao de mecanismo que bloqueia o acesso direto pgina byarea.php.
75
Figura 35 - Arquitetura do Portal
5.4 Antenas e Tags
Para o funcionamento do Sistema de Monitoramento de Trfego atravs de

RFID so necessrias antenas capazes de ler tags RFID a certa distncia. Existem
duas possveis posies para a instalao dessas antenas, em cima de cada faixa
ou na lateral da via. As figuras abaixo ilustram essas duas formas.
76
Figura 36 - Arquitetura Proposta pelo SINIAV (antena em cima da faixa)
Figura 37 - Antena postada na lateral da via
A forma de instalao e os requisitos do projeto podem ser determinantes na

escolha do modelo da antena. H inmeros modelos de antenas que variam em
relao a potencia, confiabilidade na leitura, alcance e funcionalidades. A resoluo
do CONTRAN d algumas diretrizes de como deve ser a antenas, mas ainda deixa
alguns pontos em aberto (ver ANEXO A Resoluo 212 do CONTRAN). Portanto,
o Sistema de Monitoramento de Trfego atravs de RFID foi projetado e construdo
de maneira que haja dependncia mnima em relao antena. Para realizar os
testes de leitura e manipulao dos tags, o grupo conseguiu um emprstimo de
77
equipamentos5 com a empresa Q-Free. Maiores detalhes sobre os equipamentos
sero abordados mais adiante.
Figura 38 - Equipamentos Q-Free
5.4.1 Processo de Aquisio

O processo de aquisio foi rduo. Primeiramente, a equipe procurou atravs
de algum contato do orientador, que informou no ser possvel devido ao valor dos
equipamentos. Ento, pensou-se em construir uma maquete e simular um trnsito
com carrinhos de brinquedo. Neste caso, devido s dimenses reduzidas, poderiam
ser usados TAG passivos mesmo, que existiam no laboratrio e seriam de fcil
acesso. Mas isso no era muito motivador para um projeto de formatura deste porte.
Ento, ao dividir as tarefas do semestre, um dos membros da equipe ficou
encarregado de ir atrs de emprstimos de antenas ou de patrocnio. Ento, no dia
01/08/2008 foi feio contato por telefone com as empresas Q-Free, Sem Parar e
Acura.
A empresa que mais se mostrou interessada foi a Acura e a senhora
Luciana Tocheto pediu para nosso professor orientador mandar um e-mail formal
5
Duas antenas do modelo MD5850M, dois kits para teste (incluem conversores e cabos conectores)
e dez TAGs.
78
solicitando o emprstimo ou doao. Passaram-se dois meses e no ficamos
sabendo sobre o paradeiro deste e-mail.
Ento, ao saber que haveria o III Encontro Nacional de Estudantes de
Engenharia Eltrica, tivemos a idia de mandar uma proposta formal de
emprstimos de antena as trs empresas citadas. Mas desta vez tnhamos mais
poder de troca. Oferecemos a exposio do logo da empresa no pster do projeto,
na apresentao que ser feita banca avaliadora, no site do projeto de formatura e
na exposio no III ENEEEL (ver ANEXO B Proposta para a Q-Free). Desta vez
conseguimos muito mais frutos. O Senhor Lucas Rodrigues da empresa SEM
PARAR nos informou que o nosso projeto foi encaminhado para a presidncia e
estava aguardando o retorno deles.
Como a empresa Q-Free nos retornou positivamente primeiro, no fizemos
mais contato com a empresa SEM PARAR e ficamos sem saber a resposta. Aps o
envio da proposta a Q-Free fizemos contato com a Renata Sena por telefone para
saber da resposta. Ela nos pediu um documento formal comprovando a ocorrncia
do Encontro a que nos referimos. Este processo demorou um pouco, pois os
organizadores estavam muito ocupados na organizao do evento. Depois de
receber a documento, a Renata j nos procurou para marcar uma reunio com o
Luiz Fernando, responsvel tcnico. Ento, realizamos duas visitas Q-Free para
conversar com o Luiz Fernando, onde na segunda assinamos os contratos de
emprstimo e de confidencialidade do equipamento.
5.4.2 Especificaes
Principais caractersticas das antenas e tags6 envolvidas no projeto.
Tag:
Modelo: MD5888
Fabricante: Q-Free
Caractersticas relevantes:
6
IMPORTANTE:
Na seo abaixo temos especificaes simplificadas dos equipamentos da Q-Free. Apesar de
possuirmos a documentao completa de todo o hardware, no podemos divulg-lo, devido ao
contrato de confidencialidade firmado entre o grupo e a empresa. Entretanto, a omisso dessas
informaes no ir prejudicar, de forma alguma , o entendimento do projeto pelo leitor. Concluindo,
abaixo esto divulgadas informaes que so de domnio pblico (esto no site da Q-Free, www.qfree.com ), que inclusive obtivemos na fase de especificao do projeto, quando ainda nem tnhamos
contato com a empresa.
79
Freqncias de Operao:
o
5,7975 GHz
5,8025 GHz
5,8075 GHz
5,8125 GHz
Permite leitura e escrita
Links:
o
Download: 500 kbps
Upload: 250 kbps
Distncia de at 10m numa comunicao segura de dados.
Vida til da bateria: no mnimo 5 anos.
Mecanismos de autenticao atravs de certificados de tempo real DES MAC.
Transferncia de dados em alta velocidade (at 250 Km/h)
Deteco de bateria fraca.
O modelo de antena MD5850M da Q-Free foi escolhido para trabalhar em

conjunto com a tag descrita acima.
Antena:
Modelo: MD5850M
Fabricante: Q-Free
Rede para conexo de dados: Ethernet (10 Base-T, coaxial ou fibra ptica).
Dados seriais: RS422
Configurao serial do terminal: RS232
Funes de auto-diagnstico (importante visto que invivel verificar uma a

uma se todas as antenas esto funcionando)
Buffer de 10000 transaes
Links:
o
Download: 500 kbps
Upload: 250 kbps
Funes de leitura e escrita.
Distncia mxima de comunicao segura de dados: 10 m.
80
6 TESTES
Esta seo tem o objetivo de apresentar verificar as funcionalidades dos
mdulos funcionais do projeto Monitor, Calculadora e Portal , apresentando as
entradas esperadas e a verificao dos resultados obtidos.
6.1 Testes do Mdulo Monitor
Os tipos de testes do Mdulo Monitor so trs: String com Separador, String com
Campos de Tamanho Fixo e Data e Hora em milissegundos (que ser testado em conjunto
com o Mdulo de Adaptao, na prxima seo)
6.1.1 String com Separador

Teste 1:
Separador de Campos: /
Nmero do Campo: 1
Identificador do Tag:
Nmero do Campo: 2
Hora:
Formato: Hora, Minuto, Segundo
Separador de Hora: no separado
Nmero do Campo: 3
Data:
Formato: Dia, Ms, Ano
Separador de Data: no separado
Nmero do Campo: 4
Formato do Ano: AAAA
81
String Recebida pelo Monitor:
antena23/carro15/194755/30112008
Resultado esperado:
Identificador Antena: antena23
Identificador Tag: carro15
Hora: 19:47:55
Data: 2008-11-30
Resultado Obtido:
Hora: 19:47:55
Data: 2008-11-30
Registro no banco de dados:

ID_READ_TAG
READ_AT
READ_ON
carro15
2008-11-30 19:47:55
antena23
Teste 1 OK
Teste 2:
Separador de Campos: /
Nmero do Campo: 1
Identificador do Tag:
Nmero do Campo: 2
Hora:
Formato: Segundo, Minuto, Hora
Separador de Hora: :
Nmero do Campo: 3
Data:
82
Formato: Ano, Ms, Dia
Separador de Data: Nmero do Campo: 4
Formato do Ano: AA
antena23/carro15/01:02:20/08-11-30
Resultado esperado:
Hora: 20:02:01
Data: 2008-11-30
Resultado Obtido:
Hora: 20:02:01
Data: 2008-11-30

ID_READ_TAG
READ_AT
READ_ON
carro15
2008-11-30 20:02:01
antena23
Teste 2 OK
String com Campos de Tamanho Fixo
Teste 3:
Tamanho do Campo: 8
Offset: 1
83
Tamanho do Campo: 7
Offset: 9
Hora:
Tamanho do Campo: 6
Offset: 16
Separador de Hora: no separado
Data:
Tamanho do Campo: 8
Offset: 22
Formato de Data: Dia, Ms, Ano
Separador de Data: no separado
Formato do Ano: AAAA
antena23carro1520101130112008
Resultado esperado:
Hora: 20:10:11
Data: 2008-11-30
Resultado Obtido:
Hora: 20:10:11
Data: 2008-11-30

ID_READ_TAG
READ_AT
READ_ON
carro15
2008-11-30 20:10:11
antena23
Teste 3 OK
84
Teste 4:
Tamanho do Campo: 8
Offset: 1
Tamanho do Campo: 7
Offset: 9
Hora:
Tamanho do Campo: 8
Offset: 16
Separador de Hora: :
Data:
Tamanho do Campo: 8
Offset: 24
Formato de Data: Dia, Ms, Ano
Separador de Data: /
Formato do Ano: AA
antena23carro1520:12:1930/11/08
Resultado esperado:
Hora: 20:12:19
Data: 2008-11-30
Resultado Obtido:
85
Hora: 20:12:19
Data: 2008-11-30

ID_READ_TAG
READ_AT
READ_ON
carro15
2008-11-30 20:12:19
antena23
Teste 4 OK
6.2 Testes do Mdulo de Adaptao
O Mdulo de Adaptao testar a comunicao entre Antena e software e o

tratamento de data e hora pelo Monitor, quando em milissegundos.
Antes de tudo vlido observar que no faz sentido termos campos com tamanho
fixos quando a data e a hora vierem em milissegundos, pois esse nmero varivel.
Teste 5:
Separador: (espao)
Nmero do Campo: 1
Nmero do Campo: 2
Data e Hora:
Nmero do Campo: 4
String enviada pelo Mdulo Adaptador
100 42 1228088423843
Resultado esperado:
Identificador Antena: 100
86
Identificador Tag: 42
Hora: 20:40:23
Data: 2008-11-30
Resultado Obtido:
Identificador Antena: 100
Identificador Tag: 42
Hora: 20:40:23
Data: 2008-11-30

ID_READ_TAG
READ_AT
READ_ON
42
2008-11-30 20:40:23
100
Teste 5 OK
6.3 Testes do Mdulo Calculadora
Para testes conceituais, ser considerada uma via arterial e outra via urbana
de menor capacidade de trnsito com exemplo de So Paulo e sua respectiva
velocidade de fluxo livre7 e capacidade (fluxo mximo). Alguns parmetros iniciais
podem ser estimados da seguinte forma:
Via arterial: 6 faixas, distncia entre veculos + comprimento do veculo 16
metros. Ou seja: 6 faixas x (0,016km / 80km/h)-1 / 60min/h 500 veculos por
minuto; e
Via urbana: 2 faixas, velocidade estimada como mdia entre uma via de
50km/h e paradas em faris. Ou seja: 2 faixas x (0,010km / 40 km/h)-1 /
60min/h 130 veculos por minuto.
Tabela 3 Exemplos de vias e parmetros
7
No necessariamente o limite de velocidade da via, mas em condies reais deve ser refinado
com anlises estatsticas coerentes
87
Tipo de via
Velocidade de fluxo livre
(km/h)
Capacidade
(veculos por minuto)
Exemplos
Arterial
Urbana
80
40
500
130
Av. 23 de Maio, Av.

Juscelino Kubitschek e
marginais
R. Vergueiro, ruas na regio

dos Jardins (Al. Santos, Al.
Ja, etc.)
Para os seguintes testes, as vias acima sero denominadas respectivamente

testeTrecho1 e testeTrecho2, ambos com 1km de distncia, conforme registros
abaixo:
ID_TRACK
TESTECalculadora1
TESTECalculadora2
Tabela 4 Cadastro de trechos teste

ID_READER1 ID_READER2 DIST V_F Q_MAX
AntenaTeste1 AntenaTeste2
1
80
500
1
40
130
CURRENT_STATUS
desconhecido
desconhecido
Para as entradas dos testes, deve ser utilizado registros manualmente

carregados ou um mini-programa gerador de informao para a tabela read_tag no
banco de dados.
Os parmetros de intervalo de amostragem adotados para os testes ser de
60 segundos, com fator 1,0 para efeitos de simplificao.
Trfego Livre
Na tabela de registros (read_tag), so registrados 30 veculos lido pela
AntenaTeste1 e os mesmo 30 pela AnenaTeste2 com diferena de horrio de 1
minuto (60 km/h), lidas pelas antenas do primeiro trecho. Ao executar o mdulo
calculadora com os parmetros citados acima, temos os resultados na tabela status
e track. As cargas anlogas so executadas para o segundo trecho (AntenaTeste3 e
AntenaTeste4), 15 veculos/min a 35 km/h. Resultado:
Tabela 5 Resultado na tabela status
ID_TRACK
V
Q
CALC_AT
TESTECalculadora1 60
30
2008-11-25 13:59:01
15
2008-11-25 13:59:02
ID_TRACK
TESTECalculadora1
TESTECalculadora2
Tabela 6 Resultado no cadastro de trechos teste

1
80
500
1
40
130
CURRENT_STATUS
livre
livre
Em casos de nenhum veculo trafegando, o mdulo adota a velocidade de

fluxo livre (Vf) do trecho como a velocidade mdia, obtendo assim trfego livre.
88
Trfego Intenso
Na tabela de registros (read_tag), so registrados 300 veculos/min a 60 km/h,
lidas pelas antenas do primeiro trecho e 120 veculos/min a 35 km/h no segundo
trecho, temos:
ID_TRACK
V
Q
CALC_AT
300
2008-11-25 14:30:23
120
2008-11-25 14:30:23
ID_TRACK
TESTECalculadora1
TESTECalculadora2

1
80
500
1
40
130
CURRENT_STATUS
Intenso
Intenso
Em casos de velocidade e fluxos superiores aos parmetros da via, alm de

ser considerado trfego intenso, deve ser e analisado estatisticamente e, ento, os
mesmos parmetros devem ser redefinidos.
Trfego Lento
trecho, temos:
ID_TRACK
V
Q
CALC_AT
300
2008-11-25 14:45:13
120
2008-11-25 14:45:13
ID_TRACK
TESTECalculadora1
TESTECalculadora2

1
80
500
1
40
130
CURRENT_STATUS
lento
lento
Trfego Congestionado
trecho, temos:
ID_TRACK
V
Q
CALC_AT
30
2008-11-25 15:23:29
15
2008-11-25 15:23:29
89
ID_TRACK
TESTECalculadora1
TESTECalculadora2

1
80
500
1
40
130
CURRENT_STATUS
lento
lento
Para casos de congestionamento crtico, vale ressaltar o alto ndice de

veculos no considerados na mdia de velocidade por no terem alcanado a
antena final.
Em casos de velocidade e fluxos superiores aos parmetros da via, alm de
ser considerado trfego intenso, deve ser e analisado estatisticamente e, ento, os
mesmos parmetros devem ser redefinidos.
Como se pode perceber, o campo CURRENT_STATUS da tabela de trechos
(track) modificado a cada rotina de caulo. Com esses resultados, a interface
grfica pode atualizar em tempo real no mapa apenas com essa leitura por trecho.
importante citar que relevante instalar antenas de monitoramento para
vias que tenham significativa relevncia ao fluxo urbano. Ou seja, para vias locais de
circulao, como de bairros residenciais e outras pequenas ruas, os mtodos acima
no tm a mesma eficcia e necessidade.
6.4 Testes do Portal
Como j mostrado anteriormente, a interface com o Portal do Trnsito bem

simples e envolve apenas duas pginas. A primeira o usurio escolhe a rea que
deseja ver e a segunda apresenta a situao do congestionamento no mapa dos
trechos cadastrados previamente. Portanto, o teste ser foi dividido em duas partes:
a primeira pgina, que interage apenas com a tabela AREA, e a segunda pgina que
interage com a pgina anterior e as tabelas TRACK e POINT.
6.4.1 Primeira parte

Na tabela AREA, devem ser cadastradas as reas que se pretende
disponibilizar para a visualizao no Portal. Para o cadastro, necessrio o nome da
90
rea, o nvel de zoom e as coordenadas geogrficas8 (latitude e longitude) do centro
do mapa. A tabela abaixo mostra uma carga inicial na tabela AREA.
Tabela 13 - Carga inicial na tabela AREA
Nome
Zoom Latitude
Longitude
Escola Politecnica da USP
15
-23.557418 -46.724424
Saida da USP
14
-23.565541 -46.711957
Acessando a pgina inicial do portal, tem-se a seguinte tela:
Figura 39 - Primeira tela
Repare que a caixa de seleo mostra todas as reas cadastradas.

O primeiro teste foi a insero de mais um registro na tabela AREA. Foi
adicionando a rea do Jockey Clube de So Paulo. Conseqentemente, a caixa de
seleo deveria mostrar este novo registro entre as opes.
Tabela 14 - Tabela AREA aps a insero de uma rea
Nome
Zoom Latitude
Longitude
15
-23.557418 -46.724424
Jockey Clube de Sao
Paulo
15
-23.579249 -46.699405
Saida da USP
14
-23.565541 -46.711957
As coordenadas geogrficas
http://itouchmap.com/latlong.html.
podem
ser
obtidas
por
uso
de
GPS
ou
pelo
site
91
Figura 40 - Tela inicial do Portal aps a insero de nova rea
Portanto, o primeiro teste obteve sucesso. O teste seguinte foi a verificao

da visualizao das reas na transio para a segunda pgina, ou seja, se a
segunda pgina abre com a mapa centrado corretamente no ponto e com o nvel de
zoom cadastrados.
As figuras abaixo mostram a realizao com sucesso (a apresentao
corresponde ao nvel de zoom e as coordenadas cadastradas) do teste para as trs
reas listadas na Tabela 14. Observe que o nvel de zoom na Sada da USP
menor que os das outras reas.
Figura 41 - Escola Politcnica da USP
92
Figura 42 - Jockey Clube de So Paulo
Figura 43 - Sada da USP pela portaria 1
93
S para finalizar os testes desta primeira parte, foi alterado o zoom na Sada
da USP para 15. Novamente, obteve-se sucesso. A figura abaixo mostra o
resultado:
Figura 44 - Sada da USP com zoom aumentado
6.4.2 Segunda parte

Nesta outra fase do teste, foi dado nfase marcao do grau de
congestionamento nas vias. Para marcar as cores nas vias, a aplicao buscar na
tabela TRACK todos os trechos da rea escolhida na pgina anterior e todos os
pontos que compem esses trechos na tabela POINT. Portanto, como este mdulo
l os dados j calculados, o teste foi realizado apenas cadastrando pontos e trechos
como se tivessem sido calculados9. Inicialmente, foram cadastrados cinco trechos na
rea da Sada da USP e trs trechos na rea da Escola Politcnica. A tabela abaixo
mostra um cadastro inicial na tabela TRACK10.
Tabela 15 - Carga inicial na Tabela TRACK
ID_TRACK
NOME_AREA
ID_READER1 ID_READER2 CURRENT_STATUS WIDTH
Av.Alfranio
Saida da USP
13
15
lento
Av.Uni_entrada
Saida da USP
27
31
livre
Os testes integrados esto descritos mais adiante.

A tabela mostra apenas os campos necessrios ao teste.
10
94
Av.Uni_saida
Saida da USP
16
26
congestionado
R.Alvarenga
Saida da USP
12
intenso
R.Alvarenga-2
Saida da USP
32
36
livre
ID_Teste1
Testpoint1
Testpoint2
livre
Luciano GualbertoFAU
60
67
lento
Raia Sentido P2
55
58
lento
A Figura 41 e a Figura 43 mostram a apresentao desses dados. Note que

h cinco trechos na sada da USP e trs trechos na Escola Politcnica que
correspondem, respectivamente, aos cinco primeiros registros e aos trs ltimos da
Tabela 15.
Prosseguindo nos testes, pensou-se em adicionar novos trechos numa
mesma via (dentro no bolso da Escola Politcnica) onde a antena que fosse o fim
de um trecho fosse ao mesmo temo o incio do trecho seguinte. Neste momento
descobriram-se dois erros. A coluna ID_TRACK da tabela TRACK corresponde ao
nome do trecho ou da via. A coluna TRACK da tabela POINT tambm. Portanto, um
ponto que pertence a dois trechos ao mesmo tempo s poderia ser cadastrado em
um. Para resolver isso, os campos ID_TRACK (tabela TRACK) e TRACK (tabela
POINT) adquiriram o significado de via e a chave da tabela TRACK, que antes era
apenas o campo ID_TRACK, passou a ser a combinao (ID_TRACK, ID_READER1
e ID_READER2). Logo, o que diferencia um trecho so esses trs campos.
Alm disso, o portal, que antes pintava todos os pontos daquele trecho,
passou a pintar apenas o pedao da via entre os pontos correspondentes a
ID_READER1 e ID_READER2. Para testar foram inseridos mais trs trechos
conseqentes (ver Tabela 16). A figura abaixo mostra que se obteve sucesso.
Tabela 16 - Insero de novos trechos para novo teste
ID_TRACK
NOME_AREA
ID_READER1
ID_READER2
CURRENT_STATUS
WIDTH
Av.Alfranio
Saida da USP
13
15
lento
Av.Uni_entrada
Saida da USP
27
31
livre
Av.Uni_saida
Saida da USP
16
26
congestionado
R.Alvarenga
Saida da USP
12
intenso
R.Alvarenga-2
Saida da USP
32
36
livre
ID_Teste1
Testpoint1
Testpoint2
livre
Luciano GualbertoFAU
60
67
lento
Raia Sentido P2
55
58
lento
TravessaEPEL2ADM
50
51
livre
TravessaEPEL2ADM
51
52
congestionado
TravessaEPEL2ADM
52
53
lento
95
Figura 45 - Fim do teste
6.5 Testes Integrados
Para os testes integrados, a equipe se posicionou distribuidamente (cada um

em sua casa) e foram cadastrados no trecho ID_Teste1 (correspondente a Travessa
Luciano Gualberto no sentido FFLCH para a POLI) os seguintes parmetros:
Distncia: 500 metros;
Velocidade de fluxo livre: 50 Km/h, velocidade alcanada ao trafegar 36
segundos entre as duas antenas;
Fluxo Mximo: 10 veculos/minuto, pois quantidade disponibilizada de tags.
Um dos membros da equipe ficou passando os tags pelas antenas simulando
passagens de veculos por antenas. Os outros membros ficaram executando o
mdulo calculadora e monitorando os dados no Banco de Dados e o resultado
obtido no mapa.
Teste 1 - 4 tags com intervalo de 3 s entre cada tag e 36 entre antenas...
Teste 2 - 10 tags intervalo de 3 s entre tags e 36 entre antenas
96
Teste 3 - 10 tags intervalo de 3 s entre tags e 1min e 12 entre antenas
Teste 4 - 4 tags intervalo de 3 s entre tags e 1min e 12 entre antenas
Resultados:
Teste 1- LIVRE --> Vm = 50km/h
Teste 2 - INTENSO - Vm 50km/h
Teste 3 - LENTO - Vm - 25km/h
Teste 4 - CONGESTIONADO - Vm - 25 km/h
97
7 CONSIDERAES FINAIS
7.1 Histrico
O projeto foi iniciado em fevereiro de 2008 para atender as disciplinas Projeto

de Formatura I e Projeto de Formatura II. Devido convivncia na graduao, a
equipe foi formada naturalmente. Antes de decidir o tema, o grupo j tinha como
objetivo, alm de exercitar a prtica da Engenharia (sendo essencial na formao),
propor uma soluo que resolva um problema real. Assim, de alguma forma, dar
retorno sociedade que sustenta a Universidade por meio de impostos e,
conseqentemente, foi e ser fundamental na nossa formao como engenheiro.
Para decidir o tema, o grupo passou algumas semanas estudando alguns
temas como, por exemplo, TV Digital e Aplicao Mobile. Neste processo, muitas
leituras em revistas especializadas on line e conversas com alguns professores do
Departamento de Computao e Sistemas Digitais se fizeram necessrias.
Como j dito, o projeto desenvolvido permite que usurios domsticos tenham
informaes sobre o trnsito em tempo real e instituies interessadas estudarem e
trabalharem no planejamento, gerenciamento e fiscalizao do trfego urbano.
Assim, por se tratar de um projeto que poder ser til em nvel nacional, estamos
abertos, e achamos necessria, a discusso
O primeiro semestre de 2008 foi dedicado a especificao e planejamento.
Assim, no segundo semestre, o grupo se dedicou ao desenvolvimento, contatos
empresarias, divulgao e testes.
importante citar que se procurou divulgar o projeto apresentando-o no III
Encontro Nacional de Estudantes de Engenharia Eltrica. O projeto foi bem recebido
e despertou a curiosidade dos alunos. O evento aconteceu em Vitria / ES, foi
organizado pela Universidade Federal do Esprito Santo (UFES) e contou com a
presena das melhores Universidades Federais e Estaduais do Brasil. Ao apresentar
o projeto neste evento, o grupo representou muito bem a Escola Politcnica e a
98
Universidade de So Paulo e certamente este evento (III ENEEEL 2008) ficou
marcado pela presena da USP representada pelos integrantes quila e Lucas.
Alm disso, o grupo ganhou fora na negociao por emprstimo com
empresas fornecedoras de antenas de TAGs RFID ativos, que sero supostamente
usados na implantao real deste projeto. Aps apresentar o projeto e nossas
realizaes empresa Q-Free, esta concordou em fazer o emprstimo das antenas
e TAGs ativas para que pudssemos sofisticar os testes.
O processo de deciso foi longo e acredita-se que foi decisivo para o sucesso
do projeto. Inicialmente, nossa motivao era fazer um projeto que futuramente
alavancasse a abertura de uma empresa.
Nossa primeira idia foi um sistema para chamar taxi via mensagem de
celular. Todos os veculos seriam acompanhados em tempo real atravs de GPS
(acrnimo de Global Positioning System) e quando o usurio quisesse chamar um
taxi, ele mandaria uma mensagem de texto para a central informando o seu
endereo. Ento, a central encontraria o taxi livre mais prximo e o mandaria at o
usurio. Muitas vezes, o taxi leva um passageiro at o seu destino e retorna at o
ponto de taxi vazio. Fazendo este percurso de volta sozinho, o taxista est perdendo
um tempo precioso no trnsito em que ele poderia estar ganhando dinheiro em outra
corrida. Portanto, este projeto seria muito interessante no s para empresas de
rdio taxi, que poderiam atender os seus clientes mais rapidamente e como tambm
para os taxistas, que aumentariam a sua produtividade. Certamente, encontraramos
algum que tivesse interesse neste projeto.
Mas, como era a nossa primeira idia, decidimos seguir em frente na
investigao de temas e de problemas que poderiam ser resolvidos com o nosso
conhecimento. Fomos conversar com outro professor. Mas desta vez ns j levamos
uma idia: TV Digital. A TV Digital est chegando agora no Brasil e com certeza
haver muito que aprender e pesquisar nesta rea. Alm disso, algo que tornar
possvel, atravs de um canal de retorno11, a interao do usurio com a
programao.
Com a exploso das ponto-com, a internet possibilitou um novo canal de
negcios que movimenta 8,5 bilhes de reais (estimativa para 2008) por ano com
11
Canal de Retorno um canal que permite o usurio da TV Digital enviar dados. Desta forma,
recebendo e enviando dados possvel a interatividade. Hoje, os aparelhos televisores apenas
recebem.
99
comrcio (IDGNOW, 2008) e 517 milhes de reais somente com publicidade (Melo,
2008). Porm, hoje no Brasil a internet no atinge a maioria da populao, ou seja,
h um nmero de telespectadores muito maior do que o nmero de internautas.
Portanto, o potencial da televiso digital aliada ao canal de retorno se tornar o novo
canal de negcios do futuro, assim como a internet hoje ou at mais muito
grande. Imagine estas cifras aplicadas audincia alcanada por alguns programas
de televiso. Baseado nisso, tivemos a idia de fazer um projeto para criar e testar
uma aplicao que permitisse o usurio interagir com a programao usando
somente o controle remoto da televiso e o canal de retorno. Nosso foco seria a
venda de produtos e servios pela televiso. Chegamos a estudar um projeto da
USP em parceria com universidades europias busca implementar o canal de
retorno pela prpria rede eltrica, tornando a incluso digital ainda mais abrangente.
Pois o acesso internet ainda reduzido em muitas cidades do Brasil.
Apesar da excelente idia, no ficamos suficientemente motivados a nos
engajar neste projeto porque basicamente toda a idia j estava pronta e o projeto
se resumiria em desenvolvimento. Continuando o processo de pesquisa e leituras,
fomos nos envolvendo e nos motivando cada vez mais pelo assunto em questo.
claro que problemas sociais e educacionais so muito mais graves, mas o trnsito
algo que qualquer paulistano listaria como problema e est mais visvel a todos.
7.2 Balano dos resultados
Os mdulos apresentados neste projeto representam funcionalidades iniciais

e bsicas do sistema de monitoramento proposto, ou seja, recepo e tratamento
dos registros, processamento e clculos e apresentao de resultados em interface.
Esse mtodo de desenvolvimento por mdulos contribuiu para o bom andamento do
projeto.
Por parte da tecnologia estudada, como as especificaes da tecnologia dos
equipamentos ainda no foram detalhadas no contexto do SINIAV e a resoluo 212
do CONTRAN, foi necessria a adoo de equipamentos que se aproximam das
especificaes conceituais estipuladas. No caso, a aquisio dos equipamentos da
aplicao de pedgios e contato com empresa especializada deu o diferencial para o
100
projeto, que tendia ser qualitativo e conceitual, para uma demonstrao da
viabilidade tcnica da aplicao.
Para as funcionalidades de fiscalizao acabou no sendo foco do
desenvolvimento devido baixa interao com rgos de governo para
levantamento da sua necessidade real, requisitos e restries da informao.
7.3 Perspectivas de Continuidade
Como j foi dito anteriormente, o sistema proposto criar um histrico de

dados sobre o trnsito da cidade. Essa massa de dados pode ser trabalhada de
tantas maneiras quanto se possa imaginar. Usando Business Intelligence12 e Data
Mining13, pode-se gerar quaisquer relatrios que se queira.
Relatrios que indicam padres do comportamento do trnsito so teis para
auxiliar no estudo do trfego urbano ou simplesmente para pessoas que desejam
planejar a sua sada (ou chegada) de casa no horrio de menor congestionamento.
Como resultado desse estudo, possvel pesquisar a interao de variveis e
identificar gargalos na cidade. Um servio Web que fornea a situao do
congestionamento na cidade, numa cidade como So Paulo, por exemplo,
certamente teria um elevado nmero de visitas. Isso poderia se converter em
grandes receitas com publicidade.
Funcionalidades de fiscalizao, como rodzio de veculos e de caminhes,
velocidade e de circulao de veculos com documentos atrasados, podero ser
realizadas com eficcia e a um custo muito mais baixo do que hoje. Pois no
haver a necessidade da fiscalizao por agentes de trnsito.
Caso a monitorao seja densa o suficiente, o sistema pode ser um
importante suporte segurana pblica. Por exemplo, uma blitz policial posicionada
12
O termo Business Intelligence (BI), pode ser traduzido como Inteligncia de negcios, refere-se ao
processo de coleta, organizao, anlise, compartilhamento e monitoramento de informaes que
oferecem suporte a gesto de negcios.
13
Data Mining, ou Minerao de Dados o processo de explorar grandes quantidades de dados para
procurar padres consistentes, como regras de associao ou seqncias temporais, para detectar
relacionamentos sistemticos entre variveis, detectando assim novos subconjuntos de dados. A
tecnologia utiliza conceitos de estatstica, recuperao de informao, inteligncia artificial e
reconhecimento de padres.
101
estrategicamente aps uma antena pode se antecipar aos veculos que passaro
por ela. Assim, caso um veculo roubado ou que esteja sendo procurado seja lido
pela antena, os policias sabero que em breve este veculo passar pela blitz.
Eliminando o elemento surpresa, aumentaro as chances de sucesso da ao
policial. Alm disso, sabendo o horrio que um veculo foi roubado, possvel
verificar, no histrico do sistema, em quais pontos o veculo passou aps o roubo.
Associando os dados dos casos de roubo tecnologia de mapas, pode-se observar
facilmente, e visualmente, os destinos mais comuns dos carros roubados, rotas
comuns de fuga e regies com maiores ndices de roubo de veculos.
7.4 III ENEEEL
O III Encontro Nacional de Estudantes de Engenharia Eltrica (ENEEEL 2008)

aconteceu do dia 29/10/2008 ao dia 02/11/2008 em Vitria-ES e foi organizado pela
Universidade Federal do Esprito Santo (UFES) e pelo IEEE-ES (Filiao do Institute
of Electrical and Electronics Engineers). Atravs de submisso de artigo, o grupo
esteve presente no evento representando a Escola Politcnica e a Universidade de
So Paulo. O encontro aconteceu durante cinco dias e a programao envolveu
palestras e mesas redondas.
Temas das Palestras:
Gerenciamento de Projetos
Como se preparar para as melhores vagas do Mercado de Trabalho
Comunicaes sem fio em Indstrias
Robtica
Apresentao da cadeira de rodas desenvolvida pela UFES que se move

atravs de sinais provenientes do crebro do cadeirante. como se o
cadeirante movesse controlasse a cadeira apenas por pensamento.
Temas das mesas Redondas
O Engenheiro do Futuro
Executiva Nacional
102
Instituies de Ensino - A grade curricular da UFES foi apresentada aos

estudantes e tendncias de ensino, entre elas a formao generalista do
engenheiro que est se tornando cada vez mais necessria. Tambm se falou
sobre a necessidade de uma formao mais Humanas do engenheiro.
A manh de sbado foi reservada a apresentaes de Projetos dos estudantes.

Dividimos o auditrio com mais dois outros projetos da Universidade Federal do
Cear (UFC). Foi uma experincia muito enriquecedora. Alm de expor nosso
trabalho e nossas idias, tivemos a oportunidade de fazer contatos com estudantes
de cinco estados diferentes e conhecer Vitria, capital do Esprito Santo e uma das
cidades mais antigas do Brasil.
Figura 46 - III ENEEEL
Figura 47 - III ENEEEL (equipamentos)
O ltimo dia foi marcado pela apresentao das propostas das instituies presentes
para sediar o ENEEEL 2009. Aderbal, estudante da Universidade Federal do Cear
(UFC) apresentou sua proposta e foi escolhido para liderar a organizao do IV
ENEEEL que acontecer em 2009 na cidade de Fortaleza-CE. Aps a definio da
prxima sede foram distribudos os certificados de participao aos participantes a
foi tirada a foto abaixo que certamente ficar para a histria e nos permitiu concluir a
graduao com chave de ouro.
103
Figura 48 - III ENEEEL (fechamento)
7.5 Comentrio individual de cada aluno
muito gratificante, depois de um longo ano dividindo o tempo entre a faculdade,

estgio, projetos pessoais, vida pessoal e este projeto de formatura, ver que
chegamos num resultado satisfatrio. O contato realizado com sucesso com uma
empresa privada, que de certa forma depositou confiana em ns e no projeto, e a
apresentao no III Encontro Nacional de Engenharia Eltrica foram as provas de
um bom trabalho. Tudo isso fez valer a pena todo o esforo e deu um gs a mais
para finalizar o projeto. E, com certeza, todas as noites mal dormidas devido
dedicao ao projeto, que j nos saturaram, sero lembradas com muito saudosismo
daqui muitos anos.
quila N. Chaves
"O interessante de se realizar um projeto de formatura perceber o quanto somos
ingnuos ao achar no primeiro ano de faculdade que a matria X no serviria para
nada. A variedade de assuntos que se aborda na confeco um projeto deste porte
104
realmente impressionante. Alm disso, somos constantemente desafiados pelos
obstculos que aparecem, sejam de tempo, financeiro ou tecnolgico, os quais
nossa excelente formao nos ajuda a transpor, buscando sempre a melhor sada."
Fernando C. Barcelini
Todo final de uma etapa da vida, temos o costume de olhar para trs e recordar
tudo que nos fez o que somos hoje. Aps tantos anos de experincias indescritveis,
desafios superados e conquistas notveis antes inimaginveis, podemos-se chegar
concluso que o maior sabotador dos projetos somos ns mesmos e que a fator
decisivo para o sucesso de um projeto, seja a da rea que for, depende em
acreditarmos e, com isso, motivarmo-nos a atingir o alvo. O que nos cabe, portanto,
fechar esta fase com orgulho de ter feito um bom trabalho e buscar enfrentar as
prximas etapas humilde e corajosamente, cientes que temos a escolha de ser
capazes a venc-los.
Lucas Weng
105
8 Bibliografia
[1]. Alecrim, E. (2008, Abril 20). Banco de dados MySQL e PostgreSQL. Retrieved
Novembro
21,
2008,
from
Info
Wester:
http://www.infowester.com/postgremysql.php
[2]. E-commerce brasileiro deve movimentar R$ 8,5 bilhes em 2008. (2008, Outubro
15).
Retrieved
Novembro
21,
2008,
from
IDG
NOW!:
http://idgnow.uol.com.br/internet/2008/10/15/e-commerce-brasileiro-devemovimentar-r-8-5-bilhoes-em-2008/
[3]. FHWA. (n.d.). Traffic Flow Theory. Federal Highway Administration .
[4]. Kanitz, S. (2008, Junho 18). A cidade de So Paulo vai parar definitivamente em
2012. Revista VEJA , 18.
[5]. Langley, B. (2007, Novembro 01). Radio Frequency Identification (RFID) Stores
and Retrieves Data. Retrieved Outubro 17, 2008, from AC ASSOCIATED
CONTENT:
http://www.associatedcontent.com/article/429001/radio_frequency_identification_r
fid.html?cat=9
[6]. Manir, M. (31 de Maro de 2008). A cidade vai parar, diz Cndido Malta ao
Estado . Acesso em 08 de Agosto de 2008, disponvel em Veja So Paulo:
http://vejasaopaulo.abril.com.br/red/blogs/paulistania/2008/03/cidade-vai-parardiz-cndido-malta-ao.shtml
[7]. Melo, J. (2008, Novembro 20). Internet j movimenta R$ 519 milhes em
publicidade no Brasil. Retrieved Novembro 21, 2008, from Blog do Jamildo:
http://jc.uol.com.br/blogs/blogjamildo/canais/noticias/2008/11/20/internet_ja_movi
menta_r_519_milhoes_em_publicidade_no_brasil_36619.php
[8]. NetBeans.org. (s.d.). Acesso em 15 de Maio de 2008, disponvel em
http://www.netbeans.org/features/web/web-app.html#php
[9]. Oscar, N. (19 de Maio de 2008). Em cinco anos, lentido em SP ser contnua.
Acesso em 08 de Agosto de 2008, disponvel em O ESTADO DE SO PAULO:
http://www.estado.com.br/editorias/2008/05/19/cid-1.93.3.20080519.16.1.xml
106
[10]. Pietrantonio, H. Apostila de Engenharia de Trfego, Introduo Teoria do
Fluxo de Trfego. Departamento de Engenharia de Trfego, Escola Politcnica
da Universidade de So Paulo.
[11]. Web Server Survey. (1 de Novembro de 2008). Acesso em 21 de Novembro
de
2008,
disponvel
em
Security
Space:
http://www.securityspace.com/s_survey/data/200810/index.html
[12]. RxTx Wiki. (20 de Novembro de 2008). Acesso em 20 de Novembro de 2008,
disponvel em http://rxtx.qbang.org/wiki/index.php/Main_Page
107
APNDICE A - MDULO MONITOR

A seguir esto os passos para colocar o Mdulo Monitor em funcionamento.
Antes de tudo, vamos explicar sobre suas janelas e funes.
TELA PRINCIPAL:
Figura 49 Tela principal do mdulo monitor
Confira abaixo a utilidade de cada um dos elementos da tela acima:

Informaes do Servidor: exibe informaes do computador onde o Mdulo
Monitor est sendo executado.
Informaes do Cliente:
exibe as informaes sobre o cliente (antena)

que est conectada ao Mdulo Monitor.
Comunicao:
exibe a string enviada pelo cliente.
Servir:
Inicia o servidor
108
Parar Servio:
Interrompe o servidor
Configuraes:
abre a janela de Configuraes, onde podem ser

configuradas opes de formato de string e opes
do servidor e do banco de dados.
CONFIGURAES:
Clique no boto Configuraes... e a janela a seguir abrir:
Figura 50 Tela de configurao de formato de string do mdulo monitor
String:
Nesta tela esto todas as configuraes referentes string. Dependendo do
tipo de string escolhido, alguns campos ficaro desabilitados. extremamente
recomendvel que o leitor leia a seo referente ao Mdulo Monitor para configurar
corretamente est aba.
Conexo:
A tela de conexo mais simples.
Servidor:
coloque a porta em que o Mdulo Monitor vai esperar por
109
requisies.
Banco de Dados:
coloque o endereo e a porta do servidor onde est o

banco de dados.
Figura 51 Tela de configurao de parmetros de servidor e banco de dados
importante que antes de iniciar o servidor, as configuraes sejam feitas,

pois caso as configuraes de string estejam erradas, por exemplo, o cliente ser
desconectado do servidor.
110
APNDICE B - MDULO ADAPTADOR

A seguir esto os passos para colocar o Mdulo Adaptador em
funcionamento.
Antes de tudo, vamos explicar sobre suas configuraes.
Figura 52 - Mdulo Adaptador - Tela Principal
HyperTerminal:
mostra mensagens trocadas com o servidor e com a porta

serial.
Endereo do Servidor:
o endereo do servidor onde o Mdulo Monitor est

sendo executado.
Porta:
a porta em que o Mdulo Monitor est servindo.
Configuraes da Serial: escolha a velocidade da porta.
111
Bits de Dados:
escolha o nmero de bits de dados.
Paridade:
escolha a paridade.
Bits de Parada:
escolha o nmero de bits de parada.
Porta Serial:
nome da porta onde a antena est conectada.
NOTA IMPORTANTE: conecte no servidor ANTES de conectar na serial.
112
APNDICE C - MDULO CALCULADORA

TELA DO PROGRAMA
Figura 53 Tela do Mdulo Calculadora
Os parmetros bsicos para a execuo da rotina so:

Dados do banco de dados
o endereo (IP + porta);
o nome;
o acesso (login e senha);
Parmetros de execuo
o Intervalo de amostragem;
o Fator de amostragem;
o Fator de velocidade mnima.
A rotina de clculo executada a cada intervalo de amostragem, com os
horrios de incio, trmino e tempo de execuo de cada ciclo so indicados na
caixa de texto direita (Status). Para o clculo de fluxo, o espao amostral (e
denominador do resultado) o intervalo de amostragem x fator de amostragem.
Para o clculo de velocidade mdia, o fator de velocidade mnima determina quais
velocidades abaixo da mdia da via devem ser ignoradas da mdia harmnica a fim
de reduzir pontos fora da curva (como carros estacionados por um tempo, por
exemplo).
113
A seguir so apresentados os fluxogramas das rotinas e sub-rotinas
executadas.
DIAGRAMAS
Figura 54 Rotina Principal do Mdulo Calculadora
114
Figura 55 - Sub-rotina Clculo de Fluxo
Figura 56 - Sub-rotina Clculo de Velocidade
115
APNDICE D Portal
Os arquivos do Portal esto na raiz do CD que acompanha esta monografia
(dentro do diretrio Portal do Trnsito). Primeiramente, para coloc-lo no ar,
preciso instalar o Banco de Dados, um servidor e o PHP. Depois, colocar as pginas
no servidor. A referncia as pginas so feitas de maneira relativa, portanto basta
copiar as pginas para o diretrio onde ficaro hospedadas. Aps isso, preciso
fazer algumas configuraes.
Abra o arquivo config.php (contido dentro do diretrio Util e preencha os
parmetros de conexo com o banco de dados.
Figura 57 Parmetros de conexo do Banco
Se o Banco de Dados no for MySQL, ajuste o arquivo database.php para o

banco de dados correspondente.
Para usar o servio do Google Maps, necessrio gerar uma chave para o
endereo
que
Portal
ficar
hospedado.
Acesse
endereo
http://code.google.com/apis/maps/signup.html e gere a chave para o endereo

deseja e cole no parmetro src na pgina byarea.php (veja a figura abaixo):
Figura 58 - Configurao da Google Maps API Key
Finalmente, basta cadastrar reas, pontos / antenas e trechos para fazer uso
do Portal.
116
APNDICE E Instalao dos Softwares de Apoio

Antes da instalao e utilizao do software desenvolvido no projeto,
necessrio instalar softwares de apoio ao projeto. Veja abaixo quais so e quais
verses que o grupo escolheu:
APACHE 2.2.9
PHP 5.2.6
MYSQL 5.0.51b
Instalao APACHE 2.2.9 (Windows XP e 2000)
Antes de tudo, necessrio fazer o download do arquivo de instalao do
APACHE 2.2.9 no seguinte link:
http://www.apache.org/dist/httpd/binaries/win32/apache_2.2.9-win32-x86-no_sslr2.msi
Ao trmino do download, executar o arquivo baixado.
Clique em NEXT
117
Selecione a primeira opo e clique em NEXT
Clique em NEXT
118
Preencha os campos "Network Domain" e "Server Name" com os nomes que

desejar. No campo "Administrator's Email Address", coloque seu endereo. Escolhe
a opo for All Users.... Clique em NEXT.
Escolha "Typical" e clique em NEXT.
119
Clique em NEXT
Clique em INSTALL
120
Aguarde a instalao
Clique em FINISH
121
Agora, abra seu browser (Internet Explorer, Mozilla Firefox, Opera, etc) e
digite na barra de endereos: http://localhost, se a pgina abaixo aparecer, a
instalao do APACHE foi bem sucedida.
Instalao PHP 5.2.6 (Windows XP e 2000)

Assim como na instalao do APACHE, preciso baixar o arquivo de
instalao do PHP 5.2.6.
Link: http://www.php.net/get/php-5.2.6-win32-installer.msi/from/a/mirror.
Terminado o download, comece a instalao:
122
Clique em NEXT
Clique em NEXT
123
Escolha como servidor Web o Apache 2.2.x Module. Clique em NEXT
Clique em NEXT e na prxima tela em FINISH

Agora a hora de verificar se o PHP foi instalado corretamente. Crie um
arquivo texto e salve com o nome info.php. O contedo do arquivo deve ser:
<html><head><title>Informaes do meu servidor</title></head>
<body>
<? phpinfo(); ?>
</body></html>
124
Salve este arquivo na pasta htdocs do Apache, que est no seguinte caminho:
C:\Arquivos de programas\Apache Software Foundation\Apache2.2\htdocs
Feito isso, abra seu browser e digite: http://localhost/info.php.
Se voc visualizar a tela abaixo, porque a instalao e a configurao foram
bem sucedidas. Algumas vezes o instalador do PHP j configura o Apache
automaticamente, outras preciso fazer essa configurao manualmente. Portanto,
caso voc no visualize a pgina abaixo, configuraes manuais devero ser feitas.
Configuraes Manuais
Vamos comear pela configurao do Apache. Abra o arquivo "httpd.conf", da pasta
"conf", que est dentro da pasta do Apache. No final do arquivo devero existir estas
linhas:
PHPIniDir "C:/Arquivos de programas/PHP/"
LoadModule php5_module "C:/Arquivos de programas/PHP/php5apache2_2.dll"
Se elas no estiverem no arquivo httpd.conf, adicione-as e salve o arquivo.
125
Na mesma pasta do httpd.conf, abra o arquivo mime.types num editor de
texto.
As seguintes linhas devero estar presentes. Caso no estejam, adicione-as.
application/x-httpd-php
php
application/x-httpd-php-source phps
Vamos arrumar as variveis de ambiente. V em Meu Computador
Propriedades Avanado Variveis de Ambiente. Voc ver o seguinte:
Se na varivel PATH j tiver o caminho C:\Arquivos de Programas\PHP, nada

precisa ser feito. Do contrrio clique em nova e adicione-o.
Agora, vamos configurar o arquivo php.ini, que est na pasta:
C:\Arquivos de programas\PHP
No php.ini localize a linha que comea com "short_open_tag", e troque o Off
por On (cuidado com as letras maisculas e minsculas!). Ela dever ficar:
short_open_tag = On
126
Instalao MySQL 5.0.51b (Windows XP e 2000)
Para instalar o MySQL v at o link:
http://dev.mysql.com/get/Downloads/MySQL-5.0/mysql-essential-5.0.67win32.msi/from/pick?done=0bdc81285a99f1 e baixe o arquivo de instalao.
Execute o arquivo e assim como nas outras instalaes v clicando em NEXT
e deixando as opes nos valores padro, at que se chegue na tela abaixo:
Clique no checkbox "Configure the MySQL Server Now" e em seguida, FINISH
127
Escolha "Server Machine" e clique em NEXT.

Nas telas seguintes v clicando em NEXT. Na tela abaixo, seleciona a opo
Include BIN directory in Windows PATH.
Selecione o checkbox e clique em NEXT
128
Escolha uma senha para o usurio root
Clique em EXECUTE e depois FINISH
129
preciso agora configurar o PHP para funcionar com o MySQL, para isso,
execute de novo o arquivo de instalao do PHP.
Clique em CHANGE
Clique em NEXT at chegar na seguinte tela:
130
Escolha o MySQL e clique em "Will be intalled on local hard drive". Clique em NEXT
e em seguida CHANGE.
Alteraes no arquivo php.ini
Localize as linhas abaixo no php.ini e preencha com os valores abaixo, caso
estejam diferentes:
short_open_tag = On
asp_tags = On
display_errors = On
register_globals = On
register_long_arrays = On
register_argc_argv = On
auto_globals_jit = On
file_uploads = On
upload_max_filesize = 2M
Termina aqui a instalao do APACHE, MySQL e PHP.
131
APNDICE F CONTEDO DO CD
Na diretrio raiz encontram-se as pastas:
INSTALL, com os arquivos de instalao dos programas mencionados
no APNDICE E Instalao dos Softwares de Apoio;
MONITOR, com o projeto (formato para NetBeans) com arquivos-fonte
e executvel JAR do mdulo monitor;
ADAPTADOR, com o projeto (formato para NetBeans) com arquivosfonte e executvel JAR do mdulo de adaptao;
CALCULADORA, com o projeto (formato para NetBeans) com
arquivos-fonte e executvel JAR do mdulo calculadora;
PORTAL, arquivos do website (PHP);
MONOGRAFIA, formato digital deste documento.
132
ANEXO A Resoluo 212 do CONTRAN
MINISTRIO DAS CIDADES

CONSELHO NACIONAL DE TRNSITO
RESOLUAO No 212 DE 13 DE NOVEMBRO DE 2006.
Dispe sobre a implantao do Sistema de Identificao Automtica de Veculos SINIAV
em todo o territrio nacional
O CONSELHO NACIONAL DE TRNSITO CONTRAN, no uso das
atribuies que lhe so conferidas pelo art. 12, da Lei n 9.503, de 23 de setembro de 1997,
que instituiu o Cdigo de Trnsito Brasileiro CTB, e conforme o Decreto n 4.711, de 29 de
maio de 2003, que trata da coordenao do Sistema Nacional de Trnsito;
Considerando o disposto no art. 114, do CTB, que atribui ao CONTRAN
dispor sobre a identificao de veculos;
Considerando as atribuies conferidas ao CONTRAN pela Lei Complementar
n 121, de 9 de fevereiro de 2006, que cria o Sistema Nacional de Preveno, Fiscalizao e
Represso ao Furto e Roubo de Veculos e Cargas e d outras providncias;
Considerando a necessidade de empreender a modernizao e a adequao
tecnolgica dos equipamentos e procedimentos empregados nas atividades de preveno,
fiscalizao e represso ao furto e roubo de veculos e cargas;
Considerando a necessidade de dotar os rgos executivos de trnsito de
instrumentos modernos e interoperveis para planejamento, fiscalizao e gesto do trnsito e
da frota de veculos;
Considerando as concluses do Grupo de Trabalho institudo pela Portaria n
379, de 28 de julho de 2006, do Ministro de Estado das Cidades, publicada no D.O.U. n 145,
seo 2, de 31 de julho de 2006, e o que consta no processo 80000.014980/2006-61
RESOLVE:
133
Art. 1 Fica institudo em todo o territrio Nacional o Sistema Nacional de
Identificao Automtica de Veculos - SINIAV, baseado em tecnologia de identificao por
rdio-freqncia, cujas caractersticas esto definidas no anexo II desta Resoluo.
Pargrafo nico. O SINIAV composto por placas eletrnicas instaladas nos
veculos, antenas leitoras, centrais de processamento e sistemas informatizados.
Art. 2 Nenhum veculo automotor, eltrico, reboque e semi-reboque poder
ser licenciado e transitar pelas vias terrestres abertas circulao sem estar equipado com a
placa eletrnica de que trata esta Resoluo.
1 A placa eletrnica ser individualizada e ter um nmero de srie nico e
inaltervel para cada veculo.
2 Os veculos de uso blico esto isentos desta obrigatoriedade.
Art. 3 Cada placa eletrnica dever conter, obrigatoriamente, as seguintes
informaes que, uma vez gravadas, no podero ser alteradas:
I - Nmero serial nico;
II - Nmero da placa do veculo;
III - Nmero do chassi; e
IV - Cdigo RENAVAM.
Pargrafo nico A placa eletrnica de que trata este artigo dever obedecer
tambm o mapa de utilizao de memria constante do Anexo II desta Resoluo.
Art. 4 O SINIAV dever estar implantado em todo o territrio nacional
conforme o cronograma constante do Anexo I desta Resoluo.
Art. 5 Cabe aos rgos Executivos de Trnsito dos Estados e do Distrito
Federal a responsabilidade pela implantao e operao do SINIAV no mbito do seu
territrio.
Pargrafo nico. Fica facultado aos rgos Executivos de Trnsito dos Estados
estabelecerem convnios com os Municpios visando implantao do SINIAV.
Art. 6 - As antenas leitoras e as placas eletrnicas devero ser homologadas
pelo DENATRAN, de acordo com as caractersticas tcnicas especificadas no Anexo II desta
Resoluo.
Art. 7 As informaes obtidas atravs do SINIAV e que requeiram sigilo
sero preservadas nos termos da Constituio Federal e das leis que regulamentam a matria.
Art. 8 O descumprimento do disposto no artigo 2 desta Resoluo sujeitar o
infrator aplicao das sanes previstas no Art. 237, do Cdigo de Trnsito Brasileiro .
Art. 9 Esta Resoluo entra em vigor na data de sua publicao, observado o
cronograma fixado no artigo 4.
134
Alfredo Peres da Silva

Presidente
Fernando Marques de Freitas
Ministrio da Defesa Suplente
Rodrigo Lamego de Teixeira Soares
Ministrio da Educao Titular
Carlos Alberto Ferreira dos Santos
Ministrio do Meio Ambiente Suplente
Valter Chaves Costa
Ministrio da Sade Titular
Edson Dias Gonalves
Ministrio dos Transportes Titular
135
Anexo I Cronograma de implantao do SINIAV
1. O processo de implantao do Sistema Nacional de Identificao Automtica de Veculos
SINIAV dever estar iniciado em todo o territrio Nacional, dentro do prazo de at 18
(dezoito) meses da publicao desta Resoluo e ser concludo no prazo de at 42
(quarenta e dois) meses, aps o inicio da implantao.
1.1. Findo o prazo determinado neste item, nenhum veculo poder circular se no forem
atendidas as condies fixadas nesta Resoluo e em seus Anexos.
2. Para efeito do cumprimento desta Resoluo, ser considerada que a implantao do
SINIAV estar iniciada em determinado Estado ou no Distrito Federal quando forem
cumpridas, as trs condies abaixo:
2.1. Quando somente ocorrer o primeiro licenciamento de veculos novos com a colocao
do equipamento descrito no artigo 2 desta Resoluo.
2.2. Quando ocorrer novo registro ou licenciamento dos veculos em circulao com a
colocao do equipamento descrito no artigo 2 desta Resoluo.
2.3. Quando existir, no mnimo, uma antena leitora instalada em cada unidade do
DETRAN ou Circunscrio Regional onde seja realizada a vistoria de que trata a
Resoluo n 05/98 do CONTRAN;
3. Para efeito do cumprimento desta Resoluo, ser considerado que a implantao do
SINIAV estar concluda em determinado Estado ou no Distrito Federal quando:
3.1. Todos os veculos registrados no Estado ou no Distrito Federal s puderem ser
licenciados se efetuada a colocao do equipamento descrito no artigo 2 desta
Resoluo;
3.2. Existirem, no mnimo, antenas leitoras instaladas, operantes e conectadas a um
sistema informatizado de registro dos dados da placa eletrnica, por sua vez
conectado ao Sistema RENAVAM, em todas as unidades do DETRAN ou
Circunscrio Regional onde seja realizada a vistoria de que trata a Resoluo n
05/98 do CONTRAN;
136
ANEXO II Especificaes Tcnicas
1. O Sistema Nacional de Identificao Automtica de Veculos - SINIAV, baseado em
tecnologia de identificao por rdio-freqncia (RFID), composto por placas
eletrnicas instaladas nos veculos, antenas que recebem e transmitem dados s placas
eletrnicas instaladas nos veculos no momento da passagem dos mesmos pela rea de
abrangncia das antenas e por sistemas de apoio como transmisso e processamento de
dados.
2. Entende-se por antena, para fins desta Resoluo, o dispositivo responsvel e capaz de ler
e escrever informaes na placa eletrnica com as seguintes caractersticas:
2.1. Deve possibilitar a operao integrada com outros equipamentos de campo, atravs de
interface aberta e conhecida como interface serial, paralela, USB ou ethernet.
2.2. Deve ter desempenho de leitura de pelo menos 99,90% (noventa e nove vrgula
noventa por cento) das passagens dos veculos equipados com as placas eletrnicas.
2.3. Deve ter capacidade de leitura e gravao de dados nas placas eletrnicas a uma
distncia mnima de 5 metros.
2.4. Deve permitir a leitura de dados nas placas instaladas em veculos que estejam
trafegando at 160 km/h, no mnimo.
2.5. Deve permitir a gravao de dados nas placas instaladas em veculos que estejam
trafegando at 80 km/h, no mnimo.
2.6. Deve resistir a intempries climticas e poder funcionar a cu aberto, com proteo
fsica mnima de IP 65 conforme a norma NBR 9883 da ABNT (Associao
Brasileira de Normas Tcnicas).
3. Caractersticas das Placas Eletrnicas:
3.1. Devem ter capacidade mnima de armazenamento de 1024 bits de informao, sem
limite mximo de memria;
3.2. Devem possibilitar sua fixao nos veculos de tal forma que se tornem fisicamente
inoperantes quando removidas da sua localizao original;
3.3. Devem ser fixadas no lado interno do pra-brisa dianteiro dos veculos, conforme
janela de comunicao de dados informada pelo fabricante do veiculo;
3.3.1. Na ausncia desta informao, devero ser fixadas no lado interno do prabrisa dianteiro dos veculos, conforme determinaes do rgo executivo de
trnsito do Estado, ou do Distrito Federal, onde estiver registrado o veculo;
3.3.2. No caso de veculos que no possuam pra-brisa, a placa eletrnica dever ser
fixada em local que garanta o seu pleno funcionamento.
3.4. Devem ter capacidade de serem lidas em qualquer condio climtica, sem prejuzo
da confiabilidade de 99,90% (noventa e nove vrgula noventa cento) de identificao
do veculo;
3.5. A unicidade numrica das placas eletrnicas fornecidas deve ser garantida atravs de
processo controlado pelo DENATRAN;
3.6. Devem ter capacidade de atender, no mnimo, aos requisitos do mapa de memria
constante da tabela 1 a seguir:
137
TABELA 1 Mapa de Utilizao de Memria
APLICAO
DADO
BASE\FABRICANTE
NUMERO SERIAL NICO

CONTROLE DE MANUFATURA
MEMRIA PROGRAMVEL
TOTAL (MNIMO)
Tag
Tag
Tag
64
32
928
1024
APLICAO
DADO
PLACA ELETRONICA
IDENTIFICAO
DO
EMISSOR
(Pais,Estado)
NUMERO DE MATRICULA DO AGENTE
DATA HORA DA APLICAO
PLACA
NMERO DO CHASSI
RENAVAM
CODIGO DA MARCA MODELO DO
VEICULO
Aplicaes Governamentais
Sub Total
TAG
BITS
Tag
64
Tag
Tag
Tag
Tag
Tag
32
16
88
128
36
Tag
16
Tag
164
544
Tag
64
Tag
64
Tag
64
Tag
64
Tag
64
Tag
64
PLACA ELETRONICA
BITS
Bloco 1
CONTROLE
VEICULO
DO
CONTROLE
VEICULO
DO
Uso pela Iniciativa Privada

Bloco 2
Bloco 3
CONTROLE
VEICULO
DO
CONTROLE
VEICULO
DO

Bloco 4
Bloco 5
CONTROLE
VEICULO
DO

Bloco 6
CONTROLE
VEICULO
DO

SUB TOTAL 2
384
138
4. O SINIAV ter as seguintes caractersticas de segurana:
4.1. Segurana de integridade de dados da placa eletrnica: os dados de identificao da
placa eletrnica nela gravados por seu fabricante, bem como os dados de identificao
do veculo gravados pelo rgo executivo de trnsito do Estado ou do Distrito
Federal, onde estiver registrado o veculo, conforme determina o Artigo 3 desta
Resoluo, devem possuir caractersticas de gravao tais que seja impossvel alterlos.
4.2. Segurana dos dados entre a placa eletrnica e antena leitora: devem ser utilizadas
chaves de criptografia para autenticao da comunicao entre as placas eletrnicas e
as antenas leitoras, ou outro meio que garanta a segurana necessria destes dados.
4.3. A arquitetura do SINIAV deve garantir a segurana das informaes protegidas pelo
sigilo de dados, nos termos da Constituio Federal e das leis que regulamentam a
matria.
5. O SINIAV ter as seguintes caractersticas gerais:
5.1. A faixa de potncia e a freqncia utilizada pelas antenas leitoras e placas eletrnicas,
devem estar de acordo com a regulamentao brasileira descrita no plano de
canalizao da ANATEL.
5.2. As caractersticas tcnicas de funcionamento das placas eletrnicas e antenas leitoras
devem garantir a interoperabilidade dos diversos equipamentos integrantes do
sistema.
5.3. O protocolo utilizado para comunicao entre as placas eletrnicas e as antenas deve
ser aberto e de domnio pblico, a fim de atender ao disposto no artigo 6 desta
Resoluo e garantir a interoperabilidade do Sistema em todo Territrio Nacional.
5.4. O sistema a ser adotado pelo SINIAV deve ter aproveitamento nas operaes de
leitura e/ou gravao de, pelo menos, 99,85% (noventa e nove vrgula oitenta e cinco
por cento) dos veculos equipados com a placa eletrnica que passarem sobre a rea
de abrangncia das antenas.
5.5. Os dados contidos no SINIAV, assim como as formas de comunicao para leitura
e/ou gravao de dados, devem ser garantidos atravs de cdigos criptogrficos que
possibilitem a integridade, sigilo e confiabilidade das informaes nele armazenadas.
139
ANEXO B Proposta para a Q-Free

Ol Renata,
Conforme conversado hoje por telefone, sou aluno da Escola Politcnica da Universidade de So
Paulo e estamos fazendo um projeto de formatura do curso de Engenharia Eltrica com nfase em
Computao cujo tema Sistema de monitoramento de vias.
Contexto
A CET tem um projeto de lei de colocar at maio de 2008 (eles no conseguiram cumprir os prazos)
um TAG RFID em todos os veculos da cidade de So Paulo numa fase inicial e posteriormente
expandir o projeto para todo o territrio nacional. O objetivo deste projeto fiscalizar veculos com
documentao irregular e infraes de trnsito.
Projeto
Aproveitando esta oportunidade estamos desenvolvendo um projeto que alm de contemplar a
fiscalizao de irregularidades de trnsito, vai monitorar o trfego veicular urbano. Assim, utilizando
uma tecnologia Google e Modelos Matemticos de Engenharia de Trfego, as informaes sero
colhidas das vias e processadas. Ento disponibilizaremos em tempo real informaes de
congestionamento atravs de mapas.
Atualmente, apenas uma pequena porcentagem do trfego urbano monitorado e de maneira
muito imprecisa (visualmente). Portanto, como o trnsito de So Paulo se encontra cada vez mais
catico, acreditamos que este servio seria extremamente til para os cidados paulistanos. Alm
disso, empresas de transporte e logstica podero se beneficiar economicamente utilizando o servio
(informaes reais e atualizadas) para planejar rotas mais eficientes.
E, com certeza, outros servios surgiro a partir deste e outras cidades (que a inteno da CET)
podero se beneficiar.
Proposta
O que ns estamos propondo o patrocnio do projeto atravs da doao de equipamentos (antena
e TAGs ativas) para realizarmos os testes. O que podemos dar em troca a visibilidade da Empresa
Q-Free nos seguintes meios:
Pster que ficar exposto a partir da metade do ms de Novembro at o ms de Janeiro no

prdio da Engenharia Eltrica da POLI.
Apresentao do projeto para banca avaliadora. Estaro presentes professores, convidados e

alunos;
Site de projetos de Formatura 2008 que ter link direto no site do Departamento de
Engenharia de Computao e Sistemas Digitais da POLI.
140
Exposio no III Encontro Nacional de Estudantes de Engenharia Eltrica que acontecer

entre os dias 28/10/2008 a 02/11/2008 em Vitria-ES.
Acreditamos que para ns ser muito til pois poderemos sofisticar nosso Projeto de Formatura e
para a Q-Free ser muito conveniente associar a imagem da empresa a um projeto inovador de uma
faculdade de ponta. Assim, quando os futuros engenheiros (que assitiro as nossas apresentaes ou
acessaro o site do projeto - tambm haver um vdeo no site) precisarem trabalhar em suas
empresas ou em seus laboratrios com tecnologias como essa, certamente a Q-Free ser a primeira
empresa a ser procurada. Num caso mais extremo de a CET se interessar pelo projeto, a Q-Free
tambm ter maior visibilidade perante as outras empresas na implantao real do projeto.
Segue abaixo os dados da equipe de alunos (inclusive os meus dados para contato) e do nosso
professor orientador.
Equipe
quila Neves Chaves
Fernando Constantino Barcelini
Lucas Weng
Professor Orientador
Carlos Eduardo Cugnasca
Currculo Lattes: http://sistemas.usp.br/atena/atnCurriculoLattesMostrar?codpes=54891
Como voc pediu um documento do evento, eu entrei em contato com a Comisso Organizadora e
solicitei uma carta com o carimbo da UFES (Universidade Federal do Esprito Santo), onde ocorrer o
evento. Acredito estar com este documento em mos at o fim dessa semana. Mas de qualquer
forma entro em contato de novo na sexta-feira.
Agradeo desde j pela ateno e qualquer dvida estou disposio
Obrigado
quila Neves Chaves
Escola Politcnica da USP - BRASIL
Celular: +55 11 8265-5339
e-mails:
aquila.chaves@gmail.com
aquila.chaves@poli.usp.br

9s Monografia

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

9s Monografia

Încărcat de

Drepturi de autor:

Formate disponibile

QUILA NEVES CHAVES

FERNANDO CONSTANTINO BARCELINI

SISTEMA DE MONITORAMENTO DE TRFEGO POR MEIO DE RFID

SISTEMA DE MONITORAMENTO DE TRFEGO POR MEIO DE RFID

Chaves, A. N.; Weng, L.; Barcelini, F. C.

1. Identificao de veculos. 2. Trnsito. 3. Redes. 4. Sistemas de

Departamento de Engenharia de Computao e Sistemas Digitais pelo apoio e pelas

"Se consegui enxergar

LISTA DE ABREVIATURAS E SIGLAS

Application Programming Interface

Companhia de Engenharia de Trfego

Cascading Style Sheets

Estrutura Analtica de Projeto

Hypertext Transfer Protocol

Hypertext Transfer Protocol Secure

Radio Frequency Identification

Sistema Nacional de Identificao Automtica de Veculos

Structured Query Language

Transmission Control Protocol

Workdown Breakdown Structure

capacidade ou fluxo mximo de veculos

Velocidade de fluxo livre

Velocidade mdia da via

Questes ticas ........................................................................................... 20

ASPECTOS CONCEITUAIS .............................................................................. 22

Tecnologia RFID .......................................................................................... 22

Linguagens de Programao ....................................................................... 24

Google Maps API................................................................................... 25

Servidor Web ............................................................................................... 26

Arquitetura Cliente-Servidor ......................................................................... 27

Fluxo de veculos ................................................................................... 28

Velocidade mdia de trfego ................................................................. 28

Status de via .......................................................................................... 29

ESPECIFICAO DO PROJETO DE FORMATURA ........................................ 33

Funcionalidades do Projeto .......................................................................... 33

Monitoramento e Auxlio no planejamento do Trfego Urbano .............. 33

Apoio Segurana Pblica ................................................................... 34

Requisitos de Software ................................................................................ 34

Casos de Uso ............................................................................................... 35

Arquitetura proposta .............................................................................. 40

Linguagem de Programao ................................................................. 44

Servidor Web ......................................................................................... 46

Banco de Dados .................................................................................... 46

Modelagem de Dados .................................................................................. 47

Gesto de Riscos ......................................................................................... 52

Desenvolvimento e documentao .............................................................. 54

PROJETO E IMPLEMENTAO ....................................................................... 56

Arquitetura do Sistema Implementado ......................................................... 56

Mdulo Monitor: ..................................................................................... 58

Mdulo Calculadora ............................................................................... 66

Interface com Usurio .................................................................................. 72

Funcionamento Geral ............................................................................ 56

Portal do Trnsito .................................................................................. 73

Antenas e Tags ............................................................................................ 75

Processo de Aquisio .......................................................................... 77

Testes do Mdulo Monitor ............................................................................ 80

String com Separador ............................................................................ 80

Testes do Mdulo de Adaptao .................................................................. 85

Testes do Mdulo Calculadora..................................................................... 86

Primeira parte ........................................................................................ 89

Segunda parte ....................................................................................... 93

Testes do Portal ........................................................................................... 89

Testes Integrados ........................................................................................ 95