Documentação de Desenvolvimento

Capítulo
1
Relatório do desenvolvimento da aplicação de
coleta e disseminação dos dados de tráfego
Meta CDT
Resumo
Este entregável descreve as aplicações em desenvolvimento pela equipe da meta, como
prova de conceito das pesquisas realizadas nesta meta. Três aplicações são propostas
nesta meta: uma aplicação mais ampla, de coleta e disseminação de dados de tráfego
que pode receber qualquer tipo de evento e tem por objetivo disseminar essa
informação de forma irrestrita; outra aplicação para localização de vagas em
estacionamentos e uma terceira aplicação para monitoramento de tráfego usando
RFID. Ambas as aplicações utilizam os mesmos conceitos, de instrumentalização do
trânsito, visando aumentar os serviços oferecidos ao motorista pela rede veicular.
1.1 Introdução
Aparelhos para traçar rotas urbanas, baseados em mapas e sinal GPS de satélites,
abriram espaço para a utilização de recursos computacionais para auxiliar a navegação
dos motoristas em centros urbanos. Nesses casos, a única informação obtida pelo
equipamento é localização geográfica, que atende ao propósito único de traçar a rota
mais curta entre o ponto onde se encontra o veículo e seu destino.
No entanto, a tecnologia disponível é capaz de fornecer outras informações úteis
ao motorista, como informações meteorológicas, eventos do trânsito como
congestionamentos, mudanças em sentido de direção, desvios, barreiras e obstáculos,
vagas para estacionamento, descontos e localização de postos de combustíveis e até
informações sobre o veículo, como autonomia de combustível, velocidade, consumo,
problemas mecânicos, etc. As aplicações que utilizam essas informações são inúmeras e
diversificadas. Podem levar à economia de tempo, otimização de recursos, redução de
consumo, previsão de problemas e diversas outras vantagens.
Algumas aplicações estão previstas neste trabalho. Elas visam facilitar a
disseminação de informações sobre eventos de trânsito e sobre a disponibilidade de
vagas para estacionamento. Outras aplicações poderão ser desenvolvidas usando os
conceitos apresentados aqui e a instrumentação proposta para as redes veiculares.
Este documento apresenta os requisitos definidos para as aplicações e seu
processo de desenvolvimento. Essas aplicações estão sendo desenvolvidas pela equipe
do projeto. Foram definidos cenários e restrições para as quais foram possíveis
desenvolver a aplicação.
1.2 Aplicação de Coleta e Disseminação de Dados de Tráfego
1.2.1 Visão Geral
Pretendemos desenvolver uma aplicação sensível ao contexto para Redes
Veiculares (VANETS) [Hartenstein and Laberteaux, 2008] com informações úteis sobre
o trânsito urbano e sobre autoestradas. O objetivo da aplicação será coletar ou receber
informações sobre pontos estratégicos da cidade ou estradas e repassar essas
informações para outros usuários da rede de acordo com o seu interesse e contexto em
que estiverem inseridos.
É importante que a aplicação seja sensível a contexto. Já existem aplicações que
enviam mensagens sobre condições das vias urbanas ou estradas. Mas como as
informações são enviadas sem levar em consideração o contexto do motorista, muitas
delas são transmitidos desnecessariamente.
A coleta de informações via sensores é outro requisito essencial. Atualmente há
diversas aplicações que recebem informações de usuários sejam eles agentes públicos,
cidadãos comuns ou funcionários da iniciativa privada como, por exemplo, jornalistas.
Mas com as tecnologias de RSSF, RFID e Câmaras/Visão Computacional, é possível
coletar de forma automática e em tempo real diversas informações.
Conforme resumido no diagrama de casos de uso (Figura 1), a aplicação será
capaz de coletar e disseminar três tipos de informações: (i) congestionamento em via
urbana, (ii) acidentes, congestionamento, animais na pista ou outros incidentes em
autoestradas e (iii) vagas em estacionamento. A coleta de informações de
congestionamento em via urbana será feito pelo processamento de imagens usando
técnicas de visão computacional. As informações de acidentes, congestionamento,
animais na pista e outros acidentes nas autoestradas será informado manualmente via
smartphone. Já as informações sobre vagas em estacionamento serão coletadas via
Redes de Sensores Sem Fio e RFID.
Figura 1: Diagrama de Casos de Uso da Aplicação de Coleta e Disseminação de Informações de Trânsito. Versões básicas dos casos de
uso em cinza serão alvo do protótipo desse projeto. Os demais serão desenvolvidos em projetos paralelos ou futuros.
Este projeto contempla o desenvolvimento de uma aplicação de Smart Cities
utilizando as tecnologias de redes e dispositivos móveis disponíveis atualmente
aplicando estas tecnologias para ajudar a resolver problemas de trânsito.
A aplicação exemplo será usada em um cidade dividida em duas partes através de
uma linha férrea. Para interligar as duas partes há um viaduto e duas passagens de nível
(travessia de trem). A maioria dos veículos passa pelo viaduto o que faz com o que o
trânsito fique congestionado nesse ponto. As passagens de nível são muito utilizadas
como alternativa para evitar o congestionamento ou como pontos de passagem para
veículos que não precisam ter acesso ao centro da cidade. Mas quando a travessia do
trem precisa ser fechada, muitos motoristas deviam sua rota para o viaduto provocando
ou intensificando o congestionamento nesse ponto. Outros motoristas ficam parados
esperando a locomotiva passar provocando grandes filas de carros e congestionamentos
em cruzamentos próximos.
A aplicação que será desenvolvida permitirá aos motoristas terem acesso em
tempo real sobre as condições de trânsito do viaduto e do estado da travessia. Dessa
maneira o motorista poderá tomar a decisão por onde passar equilibrando o volume de
tráfego entre os canais existentes ou evitando deslocamentos desnecessários para pontos
obstruídos ou congestionados. As informações sobre as condições do viaduto e das
travessias serão coletadas via câmaras. As imagens serão processadas usando técnicas
de visão computacional e as informações extraídas serão armazenadas em um banco de
dados central. Um sistema de alerta enviará as informações para os smartphones dos
motoristas que possuirão uma aplicação local. A aplicação local processará a
informação recebida verificando, por exemplo, o local do alerta recebido e verificará o
contexto atual para decidir se avisa ou não ao motorista sobre o ocorrido. Na avaliação
do contexto será verificado, por exemplo, a posição atual, a velocidade do motorista e a
direção. O objetivo será verificar se o usuário está dirigindo, se está próximo da região
do alerta e se está indo em direção ao local afetado.
A aplicação fará uso de tecnologias localização, acelerômetros, conversão de
texto em voz, entre outros recursos presentes em smartphones Android. A definição do
contexto com precisão exigirá um vasto trabalho de pesquisa e desenvolvimento. Além
disso, será necessário estudar formas de interagir com o motorista sem atrapalhá-lo na
direção. Nesse sentido pretende-se utilizar comunicação via push messages e interfaces
hápticas e sonoras como forma de alertar o motorista sem que seja necessário que o
mesmo tenha de digitar ou acione algum botão no smartphone. No protótipo do projeto
versões básicas destes requisitos serão implementados. Em relação ao contexto será
analisada a posição e velocidade do motorista. Além da exibição das mensagens na tela,
as mensagens serão pronunciadas para alertar o motorista sobre eventos importantes
como acidentes, animais na pista ou congestionamentos que estejam próximos do
motorista. A disseminação das informações será feita utilizando uma rede metropolitana
sem fio, via redes celulares 3G/4G ou em modo ad hoc com transmissão de veículos
para veículos.
A seguir listaremos os principais atores e respectivos casos de uso do sistema.
1.2.2 Atores, Requisitos e Casos de Uso
Ator Sensor
O ator Sensor representa os diversos sensores que serão usados pela aplicação
como: nó sensor, sistema RFID e Câmara. Através dos sensores será possível detectar se
as travessias estão abertas, se as vias estão congestionadas e se há vagas em
estacionamentos.
Ator geral
Ator específico
Requisito/Caso de Uso
Protótipo
Sensor
Câmara
Detectar estado da via
Sim
Sensor
Câmara, Nó
Sensor e RFID
Detectar vagas
Sim
Sensor
Câmara
Detectar estado da Travessia
Não
Ator Usuário
O ator Usuário representa pessoas que podem utilizar um smartphone ou um
navegador web convencional para interagir com o sistema e enviar informações sobre o
trânsito. Os usuários poderão enviar alertas sobre estado da via, tanto urbana quanto
autoestradas, informa vagas, estado de travessias e outras informações tratadas pela
aplicação. O objetivo é que os usuários possam interagir com o sistema fornecendo
informações que não são coletadas automaticamente ou complementando informações
são coletadas. No protótipo não faremos coleta de informações de trânsito de
autoestradas, mas será possível que um usuário forneça informações sobre esse tipo de
via. Os demais casos de uso serão alvo de versões futuras da aplicação.
Ator geral
Ator específico
Requisito/Caso de Uso
Protótipo
Usuário
Não se aplica.
Informar estado da via urbana.
Não
Usuário
Não se aplica.
Informar estado da autoestrada.
Sim
Usuário
Não se aplica.
Informar estado da travessia.
Não
Usuário
Não se aplica.
Informar vagas.
Não
Ator Emissor
O ator Emissor será um processo responsável por verificar para quem as
informações devem ser enviadas. A ideia é que o motorista não precise solicitar a
informação, evitando a necessidade de interagir com o sistema enquanto dirige. Uma
vez registrado no sistema, as informações serão enviadas para o motorista seguindo o
padrão de projeto Publish–subscribe [Wikipedia, 2012a] e tecnologia Push [Wikipedia,
2012b]. O processo Emissor irá consultar periodicamente os alertas na fila de
mensagens a enviar e os alertas aos motoristas interessados.
Ator geral
Ator específico
Requisito/Caso de Uso
Protótipo
Emissor
Não se aplica.
Selecionar Interessados.
Sim.
Emissor
Não se aplica.
Enviar alertas.
Sim
Ator Receptor
O ator Receptor é responsável por receber os alertas, interagir com o motorista e
repassar os alertas em modo ad hoc. Os alertas serão recebidos em um dispositivo
móvel presente no veículo. Uma vez recebido o alerta, será analisado o contexto do
motorista a fim de verificar se é pertinente ou não exibir o alerta naquele momento. Se
fizer sentido exibir o alerta, ele será exibido e falado ao motorista. Caso contrário ele
será descartado.Se o alerta for sobre riscos eminentes de segurança, o receptor tentará
propagá-lo em modo ad hoc usando algoritmos de roteamento ou disseminação de
dados em Vanets [Li and Wang, 2007].
Ator geral
Ator específico
Requisito/Caso de Uso
Protótipo
Receptor
Não se aplica.
Receber Alerta.
Sim.
Receptor
Não se aplica.
Avaliar contexto.
Sim
Receptor
Não se aplica.
Exibir alerta.
Sim
Receptor
Não se aplica.
Falar alerta.
Sim
Receptor
Não se aplica.
Descartar alerta.
Sim
Receptor
Não se aplica.
Propagar alerta em modo ad hoc.
Sim
Ator Monitor
O ator Monitor será responsável por integrar a aplicação com sistemas de
agências municipais de trânsito (como a BHTrans) ou com canais de trânsito de redes
sociais como Facebook e Twitter. Os requisitos referentes a este ator não serão
implementados no protótipo, mas serão documentados a fim de já serem previstos no
modelo de domínio e arquitetura do sistema.
Ator geral
Ator específico
Requisito/Caso de Uso
Monitor
Não se aplica.
Monitorar
públicos.
Monitor
Não se aplica.
Monitorar informações de redes sociais.
informações
Protótipo
de
órgãos Não.
Não.
Ator Processo Gestor
O Processo Gestor será responsável por integrar as diversas informações
recebidas via sensores, usuários ou fontes externas monitoradas. A partir dessas
informações serão definidos quais alertas precisam ser enviados no momento. Uma vez
definidos, os alertas entrarão na fila de mensagens do processo Emissor para serem
enviados aos motoristas interessados.
Ator geral
Ator
específico
Requisito/Caso de Uso
Protótipo
Processo Gestor
Não se aplica.
Processar informações dos sensores.
Sim.
Processo Gestor
Não se aplica.
Processar informações recebidas via Sim.
usuários.
Processo Gestor
Não se aplica.
Processar
externas.
informações
recebidas Não.
Processo Gestor
Não se aplica.
Definir estado das vias.
Sim.
Processo Gestor
Não se aplica.
Definir disponibilidade de vagas.
Sim.
Processo Gestor
Não se aplica.
Definir estado das travessias.
Sim.
1.3 Sistema de Localização de Vagas em Estacionamentos
1.3.1 Descrição do Sistema
A aplicação consiste de um sistema localizador de vagas em estacionamentos
através do reconhecimento de imagens de câmeras de seguranças oriundas do local.
O objetivo do sistema é que o usuário através de uma aplicação para seu
dispositivo móvel possa localizar vagas de estacionamento nos locais onde a aplicação
tenha acesso sobre as câmeras do local.
Uma grande aplicação por exemplo é a utilização para localização de vagas no
centro das cidades, que em geral, são lugares onde encontrar vagas pode levar bastante
tempo já que o fluxo de pessoas é muito grande e as vagas são escassas.
Na seção sobre o funcionamento da aplicação será melhor detalhado o
funcionamento do sistema em sua completude e será mostrado alguns problemas que
poderão ser encontrados em sua implementação.
1.3.2 Requisitos Gerais do Sistema
Os seguintes requisitos são gerais e serão desenvolvidos para a aplicação:
 GUI para busca de vagas de estacionamento pelos usuários;
 Distinção entre usuário e administrador do sistema;
 Administrador tem função de gerenciamento do sistema;
 Cadastro (nome, login, senha) de usuários no sistema;
 Cadastro (local) de estacionamentos monitorados;
 Cadastro (identificador, ip) das câmeras de seguranças que podem ser
acessadas;
 Geração de relatórios de utilização e eficácia;
 Possibilidade do usuário escolher estacionamentos favoritos;
 Enviar feedback sobre o funcionamento para o sistema;
 Tempo de resposta hábil;
Os requisitos apresentados podem ser visualizados através do diagrama de casos
de uso apresentado na figura seguinte.
Figura 2 - Casos de Uso - Aplicação Estacionamento
1.3.3 Funcionamento do Sistema
O funcionamento do sistema pode ser descrito como a sequência de passos a
seguir:
1. O usuário ao chegar em uma área atuada pelo sistema deverá acessar via
seu dispositivo móvel e enviar uma requisição de localização de vaga no
local determinado;
2. Ao receber a requisição, o servidor irá requisitar as câmeras do local que
enviem snapshots dos locais do estacionamento;
3. Ao receber os snapshots, o servidor irá compará-los com uma imagem
inicial do local (com todas as vagas livres), para assim poder verificar
quais vagas estão livres no momento;
4. Com a lista de vagas disponíveis, o servidor enviará a listava para o cliente
para que o mesmo possa escolher a melhor vaga para estacionar o seu
veiculo;
5. Ao fim o usuário enviará um feedback para o sistema avaliando se a vaga
disponibilizada foi válida ou não.
O funcionamento do sistema pode ser melhor representado através do diagrama de
atividades apresentado na figura seguinte.
Figura 3 - Diagrama de sequência
A distribuição das câmeras será realizada da seguinte maneira:
Figura 4 - Distribuição das câmeras
É válido realizar algumas ressalvas sobre o procedimento:
 É necessário que o sistema possua acesso as câmeras de seguranças
disponíveis nos locais e que para um melhor resultado a quantidade de
câmeras disponíveis não seja mínima;
 Para reconhecimento das vagas é necessário possuir uma imagem inicial
do local de estacionamento vazio;
 É preciso que a câmera seja fixa, ou seja, que não seja possível
movimentá-la para que o reconhecimento das vagas seja preciso;
 Para que o sistema acesse as câmeras é necessário que exista uma conexão
com a internet ou com algum servidor de imagens;
 O ideal é realizar o processamento distribuído, ou seja, que o
processamento das imagens seja realizado na própria câmera, porém a
versão inicial será centralizada;
 O tempo de execução é um requisito crítico do sistema, pois se o tempo
para o processamento for relativamente grande, a utilização do sistema
será inviável;
No momento está sendo realizado um levantamento de possíveis filtros para
eliminação de ruídos (mancha, granulação etc) das imagens capturadas, para assim
termos uma imagem mais nítida para realizar o processamento.
Para verificar a existência de vagas, a técnica utilizada é a subtração das imagens
do momento pela original, com isso obtemos uma imagem com os objetos que não
existem na imagem original, porém esta técnica não tem uma grande eficácia aplicada
sozinha, pois questões como luminosidade ou sombreamento alteram bastante o
resultado, por isso o estudo de filtros é necessário.
1.3.4 Arquitetura do Sistema
A arquitetura do sistema é baseada na abordagem Cliente-Servidor, porém com
algumas modificações.
Na imagem a seguir podemos ver os módulos da aplicação.
Figura 5 - Arquitetura da aplicação
Na aplicação existem dois módulos principais, o módulo Cliente e o módulo
Servidor. O módulo cliente é responsável por informar ao usuário quais vagas estão
disponíveis nos estacionamentos monitorados. Sua implementação será feita para o
sistema operacional Android. Através de sua GUI o usuário poderá determinar em quais
áreas deseja realizar a busca por vagas de estacionamento. Após realizar a busca o
usuário recebe em seu dispositivo as vagas disponíveis.
O módulo servidor possui duas camadas: lógica e persistência. A camada lógica é
responsável pelo funcionamento do sistema em si, é neste camada onde os dados serão
processados e a comunicação com o cliente e com as câmeras será realizada.
Para comunicação com as câmeras deverá ser implementado um componente que
utilize os drivers das câmeras ou utilizar alguma API já existente. A camada de
persistência é responsável por gerenciar o banco de dados da aplicação.
1.3.5 Ferramentas
Para o desenvolvimento do sistema serão necessárias as seguintes ferramentas:
 IDE Eclipse: Será utilizada para o desenvolvimento da aplicação do lado
cliente e do lado servidor. Versão: Helius.
 JDK: Kit de desenvolvimento para a linguagem Java. Versão: 7
 Android SDK: Kit de desenvolvimento para o sistema operacional
Android. Versão: r18
 Apache Tomcat: Servidor Web para aplicações Java. Versão: 7.0.27
 R: Linguagem responsável pelo processamento das imagens capturas
através das câmeras de segurança. Versão: 2.0.15
 Câmeras D-Link DCS2130: Câmeras responsáveis por capturar imagens
para realizar testes para o sistema, ao todo serão utilizadas 10 câmeras
distribuídas nos estacionamentos que serão utilizados para realização dos
testes.
 Dispositivo com Sistema Operacional Android: Qualquer dispositivo
(celular ou tablet) para testar a aplicação.
 API para Acesso as Câmeras: API responsável pelo acesso as câmeras
pelo servidor. Versão: Ainda não foi encontrada tal API
 Banco de Dados MySQL: Responsável por armazenar os dados
provenientes da aplicação.
 Componente para Comunicação Java e R: Componente responsável pela
comunicação entre as linguagens utilizadas na aplicação. Será utilizado o
componente JRI ou RJava, necessitando ainda um levantamento das
vantagens e desvantagens de cada um para assim realizar a escolha de qual
será utilizado.
1.4 Aplicação de Monitoração de Trânsito Usando RFID
A ideia desta aplicação é equipar os veículos com etiquetas RFID e espalhar
leitores destas etiquetas ao longo dos principais pontos da malha viária das grandes
cidades. À medida que os veículos passam por estes leitores, informações como
quantidade de automóveis lidos, horário das leituras e as coordenadas geográficas em
que o leitor está situado, são enviadas para um Servidor de banco de dados. Uma vez
que as informações de fluxo de veículos estão salvas, um aplicativo Android as busca e
disponibiliza para os motoristas e usuários através de mapas. Desta forma, os motoristas
podem visualizar em tempo real o fluxo de trânsito em diversos pontos da cidade e
então optar por caminhos alternativos para chegar ao seu destino, evitando assim as vias
com trânsito intenso ou lento.
Esta aplicação, desenvolvida no modelo Cliente-Servidor. O servidor é
responsável por fazer a comunicação com os leitores RFID, recebendo periodicamente
de cada leitor as informações sobre as etiquetas lidas, que são enviadas através de uma
rede ethernet. Depois de recebidas estas informações, o servidor as persiste em um
banco de dados, onde elas ficam disponíveis para consultas futuras.
O Cliente é um aplicativo Android que busca as informações no banco de dados
e as disponibiliza para o usuário. Para buscar com maior facilidade as informações no
banco de dados já que não existe um conector MySQL para Android, um script PHP foi
utilizado.
1.4.1 Tecnologia RFID
As etiquetas RFID, são pequenos dispositivos que se constituem basicamente de
uma antena em forma de espiral, um capacitor e um chip que é capaz de guardar
informações.
Figura 6 - Etiqueta RFID
Estas etiquetas quando expostas a um campo eletromagnético, sofrem uma
indução através da antena, assim gerando uma corrente elétrica que é armazenada no
capacitor. Quando o capacitor está com carga máxima, ele libera uma descarga elétrica
que inicia o funcionamento do circuito. Dessa forma os dados contidos no chip são
emitidos em sinais de radio frequência, podendo ser lidos por leitores de RFID.
Leitores RFID, ou também chamados de coletores, são os dispositivos
responsáveis por fazer a leitura e gravação das etiquetas RFID. Seu funcionamento é
basicamente induzir um campo eletromagnético sobre as etiquetas de forma que estas
adquiram carga e sejam capazes de realizar uma comunicação sem fio com o leitor
utilizando um protocolo específico (RFID SPEC).
Neste trabalho nós utilizamos leitores produzidos pela Alien, o Alien ALR-9900 e
Alien ALR-9650, que possuem interface de comunicação através de rede ethernet e
também possuem uma biblioteca que disponibiliza várias funcionalidades, suprindo
todas as necessidades para este projeto.
Figura 7 Leitores Alien. Alien ALR-9900 e ALR-9650.
Para se utilizar os leitores disponíveis, empregamos a biblioteca java fornecida
pelo fabricante. Esta biblioteca nos fornece várias classes e funções que podemos
utilizar para fazer a comunicação e configuração dos leitores.
A classe AlienClass1Reader é basicamente a classe que representa o leitor. Toda
vez que desejamos nos comunicar com o leitor nós criamos uma instância desta classe:
AlienClass1Reader reader = new AlienClass1Reader();
Dessa forma, com uma instância da classe leitor criada, podemos facilmente
estabelecer uma conexão com o leitor. Esta conexão pode ser feita tanto utilizando a
rede através do protocolo TCP/IP ou também através da porta serial do computador.
Um dos principais comandos que podemos utilizar é o que devolve uma lista de
elementos da classe Tag, que representa as etiquetas que foram lidas pelo leitor no
instante em que o comando é executado. Através da classe Tag, podemos ler todos os
valores contidos em uma determinada etiqueta.
Outro comando importante é o que permite modificar o identificador de qualquer
etiqueta que esteja no alcance do leitor naquele instante, assim podemos definir os
valores que melhor nos convenham para identificar cada etiqueta.
Para fazer a aplicação, ao invés do servidor a todo instante pedir a lista de
etiquetas ao leitor, é o leitor que de tempos em tempos envia automaticamente para o
servidor a lista de etiquetas, assim evitando muito processamento do leitor e diminuindo
o congestionamento da rede. Para fazer isto, nós configuramos o leitor para funcionar
em modo autônomo e informamos ao leitor a quem ele deve notificar sobre quais
etiquetas foram lidas. Assim de tempos em tempos o leitor envia uma mensagem ao
servidor, contendo todas as etiquetas que foram lidas e uma série de informações extras.
No servidor, para tratar as mensagens que chegam a todo instante, instalamos um
serviço na máquina. Este serviço recebe as mensagens dos diferentes leitores contendo
todas as etiquetas lidas em um determinado período.
1.4.2 Aplicação Servidor
A aplicação servidor foi desenvolvida utilizando a biblioteca responsável por
fazer a comunicação com os leitores. O servidor possui uma base de dados com todos os
leitores cadastrados e com suas informações de conexão como IP, usuário e senha. Para
isto, criamos uma base de dados com o MySQL com tabelas para armazenar
informações sobre os leitores, sobre as etiquetas e sobre as leituras realizadas.
Para preencher o banco com informações, foi criada uma aplicação com as
funcionalidades de cadastro de leitores, cadastro de etiquetas e modificação dos dados
das etiquetas.
O aplicativo então podia abrir conexões com os leitores com as informações
contidas na base de dados, porém queríamos que a aplicação funcionasse sem que o
servidor a todo instante pedisse as informações de leituras para os coletores. Dessa
forma, o aplicativo servidor se conecta com cada leitor e os configura para que eles
funcionem em modo autônomo, coletando as informações de etiquetas (veículos) e as
enviando de tempos em tempos para o servidor.
Para receber informações enviadas pelos leitores, o servidor possui um serviço
que trata as mensagens recebidas, colocando os dados de leituras na base de dados, bem
como o horário em que as leituras foram recebidas e as coordenadas do leitor.
Figura 8 Funcionamento da Aplicação
Uma última funcionalidade que o aplicativo possui é o de desligar os leitores do
modo autônomo. Essa funcionalidade é útil quando se tem certeza que em certos
momentos não haverá leituras de etiquetas, assim o leitor pode ser desligado,
diminuindo o fluxo de dados na rede e o processamento do servidor.
Com estas informações temos o suficiente para definirmos o fluxo nos pontos
onde estão localizados os leitores, e assim darmos continuidade com a próxima parte do
projeto.
1.4.3 Aplicativos Android
Uma das grandes vantagens de se utilizar o Android consiste na facilidade de
desenvolvimento dos seus aplicativos, que são feitos através da linguagem de
programação Java que é bastante difundida e conhecida. Outra vantagem consiste na
quantidade de documentação e Bibliotecas disponíveis, APIs bem definidas e
completas, possuindo também a facilidade de se realizar testes através das várias
versões de emulador existentes.
Outra vantagem consiste na facilidade de construção das interfaces gráficas dos
aplicativos, que podem ser feitas através de código propriamente dito ou através de
arquivos XML, permitindo muita flexibilidade e separação da interface da lógica. As
IDEs de desenvolvimento também são um ponto forte dos aplicativos Android, podendo
ser desenvolvidos com o Eclipse, Netbeans.
Os aplicativos Android podem ser facilmente internacionalizados através da
estrutura XML que possui, permitindo informar telas específicas para cada língua, bem
como variáveis e componentes.
Por fim, outra grande vantagem, é a de se escolher qual a resolução dos
aplicativos e como a aplicação será visualizada em cada um dos diferentes tipos de
dispositivo e também para qual a versão de Android o aplicativo foi feito, desta forma,
permitindo que uma única versão do aplicativo possa ser instalada e funcionar
corretamente em diversos dispositivos Android.
Figura 9 Emulador Android
Figura 10 Desenvolvimento Tela Principal em XML, através do Eclipse, onde é
mostrado a versão do Android, a resolução da tela e para qual dispositivo está
sendo desenvolvido.
Uma das dificuldades encontradas neste projeto consistiu basicamente em como
recuperar as informações de um banco de dados através de uma aplicação Android
devido à falta de conectores para se comunicar entre o Android a uma base de dados em
MySQL.
Para se resolver este problema, uma abordagem nova teve de ser seguida, ao
invés de se utilizar um conector, ou utilizar soquetes para a comunicação, foi
desenvolvida uma interface em PHP, uma página web que roda no servidor. Este script
tem a função básica de fazer consultas no banco de dados, armazenar o resultado destas
consultas em um objeto chamado de JSON (Introdução ao JSON), e assim imprimir
estes objetos na tela, resultando em algo como o mostrado na figura abaixo.
Figura 11 Página gerada pelo script em PHP.
No aplicativo Android, estas informações são recuperadas, através de um
método que recupera objetos JSON de uma fonte na Web, e assim obtendo as
informações necessárias, como coordenadas, fluxo de veículos nas coordenadas, horário
entre outras.
Figura 12 Informação recuperada no Dispositivo Android.
1.4.4 Desenvolvimento do Aplicativo Android de Visualização das Informações.
Depois que os problemas de comunicação e recuperação das informações no
banco foram solucionados, demos inicio ao desenvolvimento do aplicativo
propriamente dito. Nesta etapa definimos como seria a sua estrutura e também a forma
como o usuário iria acessar e visualizar as informações.
Definimos a página principal do aplicativo como descrito na figura acima, onde o
usuário pode visualizar as informações através de um mapa ou através de uma lista com
as informações.
O menu configuração serve para indicar em qual o servidor está localizado o
banco de dados com as informações. Esta opção é útil quando se tem diversos banco de
dados, e se deseja distribuir a carga entre eles, ou quando são definidos diferentes
bancos para diferentes regiões.
Os menus Sobre e Ajuda são apenas para mostrar informações referentes ao
aplicativo, e onde o usuário pode tirar dúvidas sobre o seu funcionamento, mostrando
apenas textos com links, não realizando nenhum processamento ou consultas ao banco.
No menu Mapa, é onde o usuário pode visualizar as informações através de
mapas. Para utilizar mapas no Android, nos utilizamos a Google Maps API (Google
Maps Android API), onde antes de tudo é preciso obter uma licença de utilização
gratuita, Google API Key, e então esta chave precisa ser declarada no aplicativo para
assim ter acesso a API. Uma vez que o aplicativo esteja com a licença, várias
Bibliotecas podem ser utilizadas, e assim informações podem ser colocadas em
diferentes coordenadas no Mapa para poderem ser visualizas.
Figura 13 Interface principal do Aplicativo
Figura 14 Google Maps API Key. Key sendo gerada, sendo mostrado também
um exemplo de como deve ser declarada no projeto da aplicação
Assim, de tempos em tempos, consultas são feitas ao banco de dados, com auxílio
do script PHP, e os dados obtidos são atualizados no Mapa, desta forma, o usuário tem
acesso às informações em tempo real.
1.4.5 Implementação de um protocolo DTN.
Queríamos também implementar um protocolo DTN para que os dispositivos
móveis Android que executam esta aplicação pudessem, mesmo sem acesso à internet,
disponibilizar informações atualizadas para os usuários.
Para conseguir tal feito, planejamos usar a tecnologia Wi-Fi Direct que faria a
comunicação entre os dispositivos móveis, fornecendo o meio para trocas de
informação.
Cada um dos dispositivos funcionaria como um nó da rede DTN, quando um nó
solicitasse novas informações porem não tivesse conexão com a internet, essa
solicitação seria feita para seus vizinhos que estão ao alcance do Wi-Fi Direct. Essa
solicitação é então passada de nó para nó, até que algum dispositivo tenha acesso à
internet e seja capaz de buscar estas informações, devolvendo então a resposta para o nó
que fez inicialmente a solicitação.
Figura 15 Exemplo de funcionamento do protocolo DTN.
Porém, devido à demora do lançamento do Android 4.0 para os Smartphones e
Tablets que tivessem a funcionalidade do Wi-Fi Direct liberada, nós não pudemos
desenvolver esta parte da aplicação. Realizamos apenas alguns testes para comprovar e
observar o comportamento do Wi-Fi Direct.
1.5 Referências
H. Hartenstein and K. P. Laberteaux (2008), “A tutorial survey on vehicular ad hoc
networks,” IEEE Communications Magazine, vol. 46, no. 6, pp. 164 –171, june 2008.
Fan Li and Yu Wang (2007) “Routing in Vehicular Ad Hoc Networks: A Survey. IEEE
Vehicular Technology Magazine”. June 2007
Wikipedia
(2012a)
Publish–subscribe
pattern
–
disponível
em
http://en.wikipedia.org/wiki/Publish%E2%80%93subscribe_pattern. Acesso em 1º de
julho de 2012.
Wikipedia
(2012b)
Push
technology
disponível
http://en.wikipedia.org/wiki/Push_technology. Acesso em 1º de julho de 2012.
em