Park My Ride: Um sistema inteligente para - iMobilis

Transcrição

Universidade Federal de Ouro Preto
Departamento de Computação e Sistemas de
Informação
Colegiado de Engenharia de Computação
Park My Ride: Um sistema inteligente para
monitoramento e gerenciamento de vagas em
estacionamentos públicos e privados
Leandro Gomes da Silva
Trabalho de Conclusão
de Curso
ORIENTAÇÃO:
Prof. Vicente J. Peixoto Amorim
Julho, 2015
João Monlevade/MG
Orientador: Prof. Vicente J. Peixoto Amorim
Monografia apresentada ao curso de Engenharia de
Computação do Departamento de Computação e Sistemas de Informação da Universidade Federal de Ouro
Preto como requisito parcial para obtenção do grau
de Bacharel em Engenharia de Computação
Universidade Federal de Ouro Preto
João Monlevade
Julho de 2015
Park My Ride: Um sistema inteligente para monitoramento e gerenciamento
de vagas em estacionamentos públicos e privados/ Leandro Gomes da Silva. – João
Monlevade, 07 de julho de 201580 p. : il. (algumas color.) ; 30 cm.
Orientador: Prof. Vicente J. Peixoto Amorim
Monografia (graduação) – Universidade Federal de Ouro Preto, 07 de julho de
2015.
1. Internet of Things. 2. Embarcados. 3. Smart Parking. 4. WSN. I. Vicente
J. Peixoto Amorim. II. Universidade Federal de Ouro Preto. III. Instituto de
Ciências Exatas e Aplicadas. IV. Park My Ride: Um sistema inteligente para
monitoramento e gerenciamento de vagas em estacionamentos públicos e privados
CDU 02:141:005.7
FOLHA DE APROVAÇÃO DA BANCA EXAMINADORA
Monografia apresentada ao curso de Engenharia de Computação do
Departamento de Computação e Sistemas de Informação da Universidade Federal de Ouro Preto como requisito parcial para obtenção do
grau de Bacharel em Engenharia de Computação aprovada pela Banca
Examinadora abaixo assinada:
Prof. Vicente J. Peixoto Amorim
Mestre em Ciência da Computação
Orientador
DECSI - UFOP
João Monlevade, 07 de julho de 2015
A Deus, que me deu forças para continuar, que ouviu minhas orações.
Agradecimentos
Agradeço a Deus pelas portas abertas e fechadas, por me mostrar o melhor caminho
até aqui, pelas orações ouvidas e pelas respostas transmitidas. Agradeço também aos meus
pais, José Geraldo e Márcia, e a minha irmã, Gisele, pelos incentivos e pela paciência nos
meus momentos de tensão.
Obrigado também ao meu orientador, Prof. Vicente J. Peixoto Amorim, e ao meu
Coorientador Prof. Filipe Nunes Ribeiro, pelas sugestões e orientações dadas para alcançar
meus objetivos acadêmicos, pelos materiais fornecidos para a execução deste projeto e por
todo suporte. Agradeço também ao Prof. Igor Muzetti pela ajuda na gerência do projeto.
Não posso deixar de agradecer também aos meus amigos e colegas de todos os dias
do laboratório iMobilis pela amizade e suporte no projeto. Aos meus irmãos da República
Diretoria, meu muito obrigado pelas conversas diárias, pelos churrascos, pelas risadas e
principalmente pela amizade.
Aos professores que de alguma forma me ajudaram a chegar aqui, meu muito
obrigado. O conhecimento repassado por vocês foi fundamental para meu crescimento
profissional e pessoal. Agradeço também ao Prof. Tiago Lima e a pesquisadora Raquel
Martins Lana pelas primeiras orientações em iniciação científica, vocês foram fundamentais
para minha base acadêmica.
"O esforço só é expresso em recompensa, quando uma pessoa se recusa a desistir"
Napoleon Hill
Resumo
Encontrar vagas de estacionamento tem sido cada vez mais difícil em grandes centros
comerciais e pouco investimento tem sido feito em tecnologias visando mitigar esse problema
em comparação com os investimentos em amplas rodovias e avenidas. Estudos já mostram
que existe uma relação entre intensidade de tráfego e a busca por estacionamento. Este
trabalho apresenta então o Park My Ride, um sistema inteligente para monitoramento e
gerenciamento de vagas em estacionamentos públicos e privados. Através de um algoritmo
de detecção veicular baseado em variações de campo magnético o Park My Ride monitora
o estado de uma vaga de estacionamento (vazia ou ocupada) e exibe as informações aos
usuários através de uma interface web intuitiva. Com esse sistema implementado em larga
escala espera-se que os usuários consigam identificar rapidamente locais para estacionar
antes e durante seu deslocamento reduzindo assim congestionamentos, poluição e gastos
com combustíveis. Também é esperado que estacionamentos privados possam otimizar
recursos e maximizar lucros através dos dados gerados pelo sistema Park My Ride.
Palavras-chaves: Internet of Things. Embarcados. Smart Parking. WSN.
Abstract
Find parking spots have become difficult by the years in large commercial zones and
few investments has been made on technologies to mitigate such problem in comparison
with what is spent in freeways and large avenues. Studies already shows relation between
traffic intensity and search for a parking spot. This work presents “Park My Ride”, an
intelligent system to monitor and manage both public and private parking places. Through
a vehicular detection algorithm based on magnetic field variation, “Park My Ride” can
monitor parking spaces status (empty or occupied) and display this information to the
user by an intuitive web interface. With this system implemented in large scale it is
expected that users can quickly identify empty parking spots nearby before and during
his displacement reducing then congestion, pollution and fuel costs. It is also expected
that parking managers optimize resources and increases profit using data created by the
system “Park My Ride”.
Key-words: Internet of Things. Embedded. Smart Parking. WSN.
Lista de ilustrações
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
Figura
1 –
2 –
3 –
4 –
5 –
6 –
7 –
8 –
9 –
10 –
11 –
12 –
13 –
14 –
15 –
16 –
17 –
18 –
Aplicabilidade de sistemas embarcados . . . . . . .
Arquitetura geral de uma rede de sensores sem fio .
Otimizações em WSN . . . . . . . . . . . . . . . .
Aplicações para IoT e seus domínios . . . . . . . .
Arduino Uno Rev.3 . . . . . . . . . . . . . . . . . .
CuHead WiFi V1 . . . . . . . . . . . . . . . . . . .
HMC5883L . . . . . . . . . . . . . . . . . . . . . .
ESP8266 . . . . . . . . . . . . . . . . . . . . . . . .
Antena Ubiquiti NanoStation locoM2 . . . . . . . .
Arduino IDE . . . . . . . . . . . . . . . . . . . . .
Arquitetura da primeira etapa do projeto . . . . . .
Arquitetura invertida da segunda etapa do projeto
Arquitetura final do projeto . . . . . . . . . . . . .
Fluxo de execução do nó sensor . . . . . . . . . . .
Página web de interação com usuário . . . . . . . .
Fluxograma do algoritmo de detecção . . . . . . . .
Fluxograma do algoritmo de detecção . . . . . . . .
Sinal de referência para o algoritmo . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
31
32
33
41
42
42
43
43
44
50
50
51
52
53
56
57
57
Lista de tabelas
Tabela 1 – Camadas da arquitetura IoT proposta por (MA, 2011) . . . . . . . . . 32
Tabela 2 – Camadas do servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Tabela 3 – Diferentes colorações de marcadores e seus significados . . . . . . . . . 53
Lista de abreviaturas e siglas
CI
Circuito Integrado
GPIO
Entrada/Saída de Propósito Geral
IDE
Ambiente Integrado de Desenvolvimento
IoT
Internet das Coisas
RF
Rádio Frequência
PGI
Parking Guidance Information System
PtMP
Ponto-a-Multiponto
SGBD
Sistema Gerenciador de Banco de Dados
WSN
Wireless Sensor Network
Lista de símbolos
Sumário
Introdução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
I
REFERENCIAIS TEÓRICOS
27
1
REVISÃO BIBLIOGRÁFICA . . . . . . . . . . . . . . . . . . . . . . 29
1.1
Sistemas embarcados . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.2
Rede de sensores sem fio . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.3
Internet das Coisas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2
PESQUISAS RELACIONADAS . . . . . . . . . . . . . . . . . . . . . 35
II
PREPARAÇÃO DA PESQUISA
3
MOTIVAÇÃO E OBJETIVOS . . . . . . . . . . . . . . . . . . . . . 39
3.1
Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2
Objetivos
4
MATERIAIS E MÉTODOS . . . . . . . . . . . . . . . . . . . . . . . 41
4.1
Hardwares utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1
Arduino Uno Rev.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2
CuHead WiFi V1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.3
HMC5883l . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.1.4
ESP8266 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.5
Antena Ubiquiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.1.6
Máquina servidora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2
Softwares utilizados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.1
Arduino IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.2.2
ESPTool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.3
Linguagens de programação . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2.4
Banco de dados MySQL . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3
Metodologia de desenvolvimento . . . . . . . . . . . . . . . . . . . . . 46
III
RESULTADOS
5
ARQUITETURA DO SISTEMA . . . . . . . . . . . . . . . . . . . . 49
37
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
47
5.1
5.1.1
5.1.2
5.2
Visão geral . . . . . .
Protótipo 1 . . . . . . .
Protótip 2 . . . . . . . .
A arquitetura a fundo
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
49
49
50
51
6
6.1
6.2
6.3
IMPLEMENTAÇÃO . .
Requisitos . . . . . . . .
Banco de dados . . . . .
Algoritmo de detecção .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
. . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
55
55
55
7
TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . 59
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Conclusão . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
APÊNDICES
67
APÊNDICE A – REQUISITOS DO SISTEMA . . . . . . . . . . . . 69
ANEXOS
ANEXO A – ESTÓRIAS DE USUÁRIO
75
. . . . . . . . . . . . . . . 77
25
Introdução
É cada vez mais comum em grandes centros perceber investimentos em amplas vias
de escoamento de tráfego e pouco, ou quase nenhum, em tecnologias que visam otimizar
a infraestrutura existente. Estudos mostram que existe uma relação entre intensidade
de tráfego e busca por estacionamento (MERRIMAN, 1998). Sistemas dos chamados
estacionamentos inteligentes (Smart Parking) vêm para auxiliar os usuários na busca por
estas vagas ao fornecerem informações em tempo real como: melhor caminho até a vaga,
trânsito em determinada região, quantidades de vagas livres em estacionamentos pagos
e gratuitos e até a possibilidade de reserva de vagas e pagamento antes mesmo de sair
de casa. Estudos em Smart Parking são possíveis graças aos avanços nas pesquisas em
embarcados e redes de sensores sem fio (Wireless Sensor Networks - WSN).
Hoje, aplicações baseadas em microprocessadores são bem complexas e de tamanho
muito reduzido. Podem chegar a possuir diversos sistemas embarcados interagindo entre sí.
Mas, a algumas décadas atrás tais sistemas eram muito simples. Como exemplo é possível
referenciar o “sistema embarcado” de navegação da nave Apollo era baseado em chaves,
lâmpadas e displays de 7 segmentos (JIMÉNEZ; PALOMERA; COUVERTIER, 2013).
Os avanços nos estudos em microprocessadores trouxe a necessidade de comunicação entre dispositivos. Já é conhecido que boa parte do consumo energético vem da
transmissão/recepção de dados. Portanto, pesquisas na área de WSN propõem melhorias
em consumo energético e desempenho dos dispositivos desta rede (HUI; CULLER, 2010)
(POPOVICI; MAGNO; MARINKOVIC, 2013).
Uma possível aplicação dos sistemas embarcados é a minimização de um problema
dos grandes centros: o trânsito. Como já mencionado, a busca por uma vaga de estacionamento pode ser longa e isso acaba agravando os engarrafamentos e a lentidão no
trânsito de centros comerciais. A proposta deste trabalho é justamente minimizar este
problema através do sensoriamento de vagas de estacionamentos públicos e privados. Com
isso, os usuários deste serviço poderão saber o atual estado de uma determinada região
com relação a ocupação dos locais de estacionamento.
O uso de microprocessadores e WSN é de fundamental importância para a evolução
do sistema aqui proposto. Os protótipos foram desenvolvidos baseando-se na plataforma
Arduino(ARDUINO, 2015b) e a detecção dos automóveis é feita através de um sensor de
campo magnético (EMARTEE, 2015). As informações sobre o estado da vaga são enviadas
através de uma rede sem fio a um servidor, que faz o processamento das informações
compilando-as em um banco de dados para disponibilização aos usuários através de uma
interface web.
26
Introdução
O sistema proposto neste trabalho é apresentado nos próximos capítulos como se
segue: a parte I, que abrange os capítulos 1 e 2 trazem a contextualização dos principais
assuntos aqui tratados e o estado da arte. A parte II apresenta a motivação do trabalho e
seus objetivos no capítulo 3, enquanto que o capítulo 4 apresenta os principais materiais e
metodologias utilizadas. A terceira e última parte abrange vários capítulos (do 5 ao 7) que
apresentam a arquitetura do sistema e uma visão geral do algoritmo de detecção e testes.
Parte I
Referenciais teóricos
29
1 Revisão bibliográfica
Este trabalhou abordou diferentes áreas e tecnologias da computação, por isso
faz-se necessário apresentá-las nesta seção como forma de introduzir o leitor aos assuntos.
1.1 Sistemas embarcados
Os sistemas embarcados começaram a aparecer na década de 1960 (JIMÉNEZ;
PALOMERA; COUVERTIER, 2013). Naquela época, o primeiro sistema embarcado
produzido em larga escala, o Autonetics D-17, não utilizava circuitos integrados (CIs) e isso
o tornou muito caro. Com a adoção da produção dos CIs em larga escala os preços caíram
drasticamente passando dos US$3000 a meros US$3 a unidade. Porém, a popularização
destes sistemas chegou apenas na década de 1990, quando, a partir da formação do
consórcio PC/104, ficou estabelecido um padrão para microprocessadores Intel baseados
em uma placa mãe. Essa padronização possibilitou a produção de computadores muito
potentes. Hoje, sistemas embarcados possuem grande aplicabilidade no cotidiano (Figura 1)
sendo utilizados em videogames, eletrodomésticos, smartphones, carros e sistemas de voo.
Figura 1 – Aplicabilidade de sistemas embarcados (SADA, 2010)
A literatura fornece diversas definições para este tipo de sistema (PARAB, 2008),
onde cada uma se adapta melhor em uma dada situação. Oshana e Kraeling (2013) utilizam
em seu livro a definição de que um sistema embarcado é um sistema computacional
especializado que, através do conjunto de hardware e software, executa funções específicas.
No desenvolvimento de um sistema embarcado, algumas características do sistema
como restrições de energia e memória, baixa intervenção humana, confiabilidade e segurança
devem ser trabalhadas com atenção por serem críticas. Grande parte dos sistemas interagem
diretamente com o meio e requerem respostas rápidas. Para se obter essa agilidade, o
processamento é executado on the fly, ou seja, dinamicamente de acordo com a entrada
vinda de algum tipo de sensor.
30
Capítulo 1. Revisão bibliográfica
O livro Introduction to Embedded Systems: Using Microcontrollers and the MSP430
(JIMÉNEZ; PALOMERA; COUVERTIER, 2013) traz uma seção introdutória sobre energia
em dispositivos embarcados onde descreve que a energia pode interferir em diversas coisas
além da duração da bateria. Por ser uma das partes mais críticas do sistema, muitas
otimizações devem ser realizadas em software e hardware para se atingir uma eficiência
aceitável. Deve-se obedecer as normas quanto a separação mínima dos componentes
eletrônicos estabelecidas pelo fabricante a fim de reduzir a geração de calor e inclusive
protegê-los contra possíveis danos causados pela elevação da temperatura. Um software
embarcado que realiza operações excessivas também pode (e vai) consumir mais energia
do que o necessário, reduzindo assim a duração da bateria.
Assim como em softwares desenvolvidos para rodar em desktops e smartphones, os
sistemas embarcados também possuem suas respectivas arquiteturas. Oshana e Kraeling
(2013) chamam de “arquitetura super loop” a arquitetura mais simples de um software
embarcado. Ela roda em um loop infinito. Diferente dos softwares comuns, que executam
uma tarefa e encerram aquela parte do código, esta arquitetura é muito útil para completar
tarefas chave em um dado tempo e na ordem correta.
1.2 Rede de sensores sem fio
Johnson et al. (2009) define, em seu artigo, que uma rede de sensores sem fio
(WSN - Wireless Sensor Network) é uma rede de dispositivos autônomos distribuídos
espacialmente que fazem uso de sensores para monitorar condições físicas ou ambientais
(temperatura, som, vibração, pressão, movimento ou poluentes) em diferentes locais. Ele
ainda afirma que os nós dessa rede usualmente possuem três atividades principais, sendo
elas: data-logging (salva um dado a cada determinado intervalo de tempo), processamento
de dados e gateway para a rede adhoc formada por todos os sensores.
É um pouco difícil definir a topologia de uma rede de sensores sem fio, pois ela
deve se reorganizar automaticamente sempre que necessário. Para entender essa questão, é
necessário considerar que os recursos disponíveis a essa rede são muito limitados, então
o roteamento do tráfego de dados precisa escolher o melhor caminho, da origem até o
destino, evitando congestionamento de dados e sobrecarga de processamento nos nós.
Para exemplificar esta dificuldade relacionada a definição da topologia, o seguinte
cenário apresenta um sistema WSN onde deseja-se monitorar o deslocamento da areia
do deserto do Saara. Inicialmente, um avião sobrevoa determinada área liberando vários
nós sensores, capazes de detectar seu próprio movimento e sua posição geográfica, de
forma aleatória. Com o passar do tempo, o vento vai carregando cada elemento da rede
distanciando alguns e aproximando outros. Dessa forma, não é possível manter a topologia
inicial e os sensores precisam reorganizar a comunicação automaticamente, sem qualquer
1.3. Internet das Coisas
31
intervenção humana.
A arquitetura de uma rede de sensores sem fio é vista na Figura 2. A comunicação
entre os sensores é feita através de algum protocolo responsável por criar um túnel no
roteador de borda a fim de realizar a conversão de protocolos e comunicação com o
ambiente externo (HUI; CULLER, 2010).
Figura 2 – Arquitetura geral de uma rede de sensores sem fio (HUI; CULLER, 2010)
Em uma WSN, os transmissores de Rádio Frequência (RF) são a principal unidade
consumidora de energia (POPOVICI; MAGNO; MARINKOVIC, 2013). Esse consumo
ocorre principalmente durante a transmissão de dados. Neste trabalho, é essencial que
os nós sensores consigam se manter por um longo período de tempo (meses ou até anos)
com a mesma bateria. Hui e Culler (2010) fala de três diferentes técnicas utilizadas para
minimizar o consumo energético através da otimização da comunicação, são elas:
• Sampled Listening: uma sequência de wake-up é enviada e o receptor detecta a
tentativa de envio de transmissão - a detecção é realizada em intervalos de tempo.
• Scheduling: o transmissor “aprende” os intervalos de escuta do receptor e envia uma
sequência de wake-up menor do que no método sampled listening.
• Streaming: são transmitidos múltiplas janelas (frames) de dados durante um único
período de amostragem.
1.3 Internet das Coisas
O conceito de Internet das Coisas (IoT - Internet of Things) é definido na literatura
como sendo um rede de objetos conectados a internet, onde esses objetos são integrados
32
Capítulo 1. Revisão bibliográfica
Figura 3 – Otimizações em WSN (HUI; CULLER, 2010)
com o propósito de oferecer serviços inteligentes (MA, 2011) (CARRETERO; GARCÍA,
2013) (XIA et al., 2012).
(GILL, 2013) escreve que a IoT vai mudar nossa qualidade de vida assim como
aconteceu com a Internet, que mudou de diversas formas a segurança, economia de energia,
negócios, entre outros. É apenas uma questão de tempo até que os objetos domésticos
comecem a perceber o ambiente gerando dados para algum serviço inteligente.
(MA, 2011) divide a arquitetura de um sistema IoT em quatro camadas (Tabela 1):
• Camada de detecção: é a camada mais baixa, responsável por realizar a “leitura” do
ambiente e obter os dados.
• Camada de troca de dados: simplesmente trata a transmissão das informações.
• Camada de integração da informação: ocorre a recombinação, limpeza e fusão dos
dados integrando-os em conhecimento útil.
• Camada de serviços de aplicação: é a camada mais alta, responsável por prover o
serviço aos diversos usuários.
Tabela 1 – Camadas da arquitetura IoT proposta por (MA, 2011)
Serviços de aplicação
Integração da informação
Troca de dados
Detecção
As aplicações para IoT são inúmeras, mas (GUBBI et al., 2013) as classifica
em quatro domínios: (i) Pessoal e Casa; (ii) Empresarial; (iii) Utilidades; e (iv) Mobile.
A figura 4 ilustra as aplicações dentro de seus domínios. Por exemplo no domínio (i),
1.3. Internet das Coisas
33
representado por um indivíduo ou home na figura, normalmente as informações são
coletadas e utilizadas apenas pelo dono da rede podendo controlar eletrodomésticos e
medidores de sinais vitais. O domínio (ii), representado na figura por community, pode
tratar de questões como mobilidade urbana e poluição, por exemplo. O domínio (iii),
representado na figura por national, é voltado a otimização de serviços como o Smart Grid
e redes de monitoramento da qualidade da água. Um exemplo de fácil compreensão para o
domínio (iv), representado na figura por transport, é o de controle de logística, onde uma
grande WSN é necessária para monitorar veículos de cargas em grandes áreas.
Figura 4 – Aplicações para IoT e seus domínios (GUBBI et al., 2013)
O conceito de IoT tem se tornado cada vez mais popular através de iniciativas
de empresas como IBM(IBM, 2015), Cisco(CISCO, 2015), Intel(INTEL, 2015) e Microsoft(MICROSOFT, 2015) que têm realizado, grandes investimentos nesta área. Mesmo com
essa popularização, ainda existe muito trabalho a ser realizado. Segurança, computação
em nuvem e análise de dados são apenas alguns dos fatores que merecem mais estudos
(GUBBI et al., 2013). Pesquisas nas áreas de embarcados e WSN também precisam ser
desenvolvidas pois são parte fundamentais de um conjunto de áreas e tecnologias para a
IoT.
35
2 Pesquisas relacionadas
O conceito Smart Parking tem sido amplamente estudado nas áreas da computação.
(SHAHEEN; RODIER; EAKEN, 2005) o classifica em cinco categorias:
1. Sistemas de orientação de estacionamento (PGI - Parking Guidance Information
System): Este tipo de sistema procura ofecerer uma orientação ao motorista para
que a busca por uma vaga não demande um grande tempo. Sistemas de Smart
Parking projetados nesta categoria conseguem localizar uma ou um grupo de vagas, direcionando o usuário a fim de reduzir o tempo de busca por um local de
estacionamento.
2. Sistemas baseados em trânsito: Os principais objetivos desta categoria de sistema
Smart Parking são: fornecer informações em tempo real sobre as vagas, reduzir gastos
dos usuários com combustível e otimizar o uso dos estacionamentos. Esses objetivos
são, muitas vezes, alcançados ao se combinar esta categoria com PGIS para prover
informações mais relevantes como trânsito na região e localização precisa da vaga.
Com esses dados, o sistema é capaz de indicar a melhor rota até o destino.
3. Sistemas inteligentes de pagamento: Fornecem meios mais rápidos, seguros e econômicos aos estacionamentos de realizar cobrança e verificação das vagas. Utilizam
tecnologias comuns como smartphones, cartões de contato e de média distância.
4. E-parking: Esta categoria cria um ambiente virtual para o usuário, onde o mesmo
pode visualizar a disponibilidade dos estacionamentos, reservar uma vaga e inclusive
efetuar o pagamento antes mesmo de sair de casa.
5. Estacionamentos automatizados: Engloba a automatização de valets com robôs de
transporte que, através de movimentos horizontais e verticais, conseguem levar o
veículo a uma vaga disponível sem intervenção humana. Estes robôs ainda otimizam
o estacionamento ao eliminar zonas de manobra e fazendo o empilhamento dos
automóveis.
Este conceito depende ainda de tecnologias que realizem a detecção de automóveis.
(IDRIS et al., 2009b) faz uma revisão destas tecnologias e suas aplicações de acordo com
as categorias de (SHAHEEN; RODIER; EAKEN, 2005).
Com base nisso, (IDRIS et al., 2009a) desenvolveu um sistema de Smart Parking
abrangendo a categoria PGI onde, através de sensores ultrassônicos, identifica vagas livres.
Em um estacionamento fechado indica ainda a vaga livre mais próxima e o caminho mais
36
Capítulo 2. Pesquisas relacionadas
curto até ela. Outros estudos foram realizados neste sentido, (NARMADA; RAO, 2012)
utilizou sensores ultrassônicos para contabilizar as vagas disponíveis em cada andar de um
estacionamento. O estudo realizado por (SRIKANTH et al., 2009) fornece aos usuários em
tempo real a rota da entrada até a vaga escolhida.
A detecção de automóveis não é realizada apenas através de sensores ultrassônicos
(YOO et al., 2008)(MARSHALL, 1978). O uso de magnetômetros têm-se mostrado mais
eficaz e preciso por conseguir criar uma assinatura magnética para diferentes modelos de
automóveis (SIFUENTES; CASAS; PALLAS-ARENY, 2011). Estudos em Smart Parking
utilizando magnetômetros na detecção de automóveis conseguem, ainda, uma projeção de
5 anos na duração da bateria dos nós sensores (ZHANG et al., 2013)(YOO et al., 2008).
Parte II
Preparação da pesquisa
39
3 Motivação e objetivos
3.1 Motivação
Atualmente, encontrar uma vaga de estacionamento em centros urbanos é um
grande problema devido a aglomeração humana e, consequentemente, a quantidade de
automóveis em circulação. Tal problema é cada vez mais agravado devido a incentivos fiscais
para a compra de carros – principalmente os de passeio. É comum que em dias de semana
não se encontre vagas de estacionamento em regiões executivas das principais cidades
brasileiras como: São Paulo, Rio de Janeiro, Belo Horizonte, etc. Ainda, tal cenário pode
se repetir mesmo em feriados e finais de semana quando a demanda por estacionamentos
cresce em regiões e/ou cidades turísticas.
Analisando apenas veículos leves, sejam eles comerciais ou de passeio, apenas em
março de 2015 foram emplacados 225.981 carros enquanto que o acumulado do ano ficou
em 648.677 veículos leves emplacados (FENABRAVE, 2015).
Mesmo em grandes centros onde existem bolsões de estacionamento não há uma
sinalização clara e eficaz dos locais onde se encontram as vagas fisicamente disponíveis.
Aliado ao pensamento acima, nota-se ainda uma lacuna na implementação de sistemas
(automatizados ou não) para o auxílio dos usuários na busca por vagas disponíveis. Um
motorista pode chegar a gastar vários minutos no esforço de encontrar um local para
estacionar seu automóvel.
Complementando os cenários acima, que ocorrem principalmente em ambientes
e logradouros públicos, existe ainda o mesmo problema - possivelmente em escala um
pouco menor - no campo privado. É comum que motoristas transitem por um longo tempo
entre os vários andares de estacionamentos de shopping centers em busca de um local para
estacionar. Além da perda de tempo, há ainda o custo de combustível ao se dirigir durante
esse tempo adicional – algumas vezes maior que o tempo no qual se fica estacionado.
Os cenários acima caracterizam a necessidade do usuário. Ainda, outro ponto que
contribui para uma larga utilização do sistema, é a grande quantidade e abrangência de
dispositivos móveis – smartphones e tablets – sendo utilizados atualmente no país. Até
2013 eram 271,1 milhões de aparelhos no Brasil (ANATEL, 2013).
O uso de tais dispositivos para monitorar à distância a situação das vagas de
estacionamento pode facilitar a etapa de busca além de reduzir o esforço necessário para
se conseguir uma vaga disponível.
Dessa forma, facilitar a vida do motorista ao permiti-lo saber de antemão a
40
Capítulo 3. Motivação e objetivos
localização das vagas livres de estacionamento tornará esse serviço indispensável. Ou seja,
fazer um bom uso ou otimização no uso das vagas é primordial para aumentar a qualidade
e eficiência dos estacionamentos como um todo, sejam eles públicos ou privados.
É possível afirmar ainda que no Brasil atualmente não existe um sistema dessa
natureza sendo utilizado em larga escala. Uma solução encontrada hoje são pequenas luzes
(verdes/vermelhas) que internas ao estacionamento (de shopping centers, por exemplo)
caracterizam, respectivamente, os locais das vagas de estacionamento livres ou ocupadas.
Ademais, tal modelo não permite que os usuários tenham tal noção antes de entrarem
fisicamente com seus automóveis nos estacionamentos.
3.2 Objetivos
O principal objetivo desta pesquisa foi o desenvolvimento de uma arquitetura e
um ambiente funcional que permitisse o sensoriamento de vagas de estacionamento em
tempo-real. Em termos funcionais, o sistema permite em alto nível que:
1. Vagas de estacionamento disponíveis sejam monitoradas quanto a sua disponibilidade
(ocupada ou livre);
2. O estado de uma vaga seja notificado a um servidor remoto na web;
3. Informações a respeito das vagas (públicas ou privadas) possam ser acessadas pelos
usuários finais através de uma interface web.
Para se atingir estes requisitos funcionais, alguns objetivos específicos foram cumpridos:
1. Elaboração de protótipos de nós sensores com a finalidade de monitorar a entrada e
saída de veículos da vaga de estacionamento;
2. Desenvolvimento de um algoritmo de detecção de veículos automotores; e
3. Construção de uma arquitetura cliente-servidor para suportar a entrada e exibição
dos dados.
41
4 Materiais e métodos
Para o desenvolvimento deste trabalho, diversos recursos tanto de hardware quanto
de software foram utilizados. Este capítulo é destinado a apresentar estes recursos assim
como exibir a abordagem adotada no desenvolvimento da pesquisa e obtenção dos resultados
finais.
4.1 Hardwares utilizados
4.1.1 Arduino Uno Rev.3
O Arduino Uno Rev.3 (Figura 5) é uma plataforma em hardware open-source de
desenvolvimento baseado em um microcontrolador. Pode ser utilizado para realizar uma
grande variedade de tarefas, desde a leitura de sensores até o controle de saídas físicas
como lâmpadas e motores (ARDUINO, 2015b).
Figura 5 – Arduino Uno Rev.3 (ARDUINO, 2015a)
Dada a sua grande popularidade na montagem de protótipos, existem diversos
shields (módulos complementares de hardware) que podem ser acoplados ao Arduino
visando ampliar suas funcionalidades.
O Arduino Uno Rev.3 possui configurações que o torna bem versátil. Ele pode ser
alimentado através da porta USB ou ainda através de baterias. Possui 14 entradas/saídas
digitais e 6 analógicas, um ressonador cerâmico de 16MHz e memória flash de 32KB
(ARDUINO, 2015a).
42
Capítulo 4. Materiais e métodos
4.1.2 CuHead WiFi V1
CuHead (LINKSPRITE, 2015) é um shield (Figura 6) para Arduino que provê acesso
a rede WiFi através de um módulo transmissor de baixo consumo que está embarcado na
placa. É compatível com o padrão IEEE 802.11b de 2.4GHz, muito comum em roteadores
sem fio residenciais. As aplicações para este shield são muitas, podendo desde transformar
o Arduino em um servidor web até realizar comunicação por socket TCP/UDP.
Figura 6 – CuHead WiFi V1
4.1.3 HMC5883l
Sensores são amplamente utilizados em conjunto com o Arduino. O HMC5883l
(Figura 7) é um sensor de campo magnético (magnetômetro) de três eixos para campos
magnéticos baixos, ideal para a leitura do campo magnético da terra. Possui uma taxa
máxima de saída de 160MHz, interface I 2 C e ainda uma precisão de 1o a 2o no compasso
(HONEYWELL, 2013).
Figura 7 – HMC5883L (EMARTEE, 2015)
Este sensor faz a leitura do campo magnético e envia as informações ao microcontrolador através da interface I 2 C. Por sua vez, o microcontrolador processa estas leituras
4.1. Hardwares utilizados
43
e, através de um algoritmo, identifica as anomalias no campo magnético causadas pelo
deslocamento de um automóvel.
4.1.4 ESP8266
O ESP8266 (Figura 8) é uma solução completa para infraestrutura WiFi de baixo
consumo energético e baixo custo (aproximadamente US$5). Possui um microprocessador
de 32bits de baixíssimo consumo que permite a execução de códigos assim como o Arduino.
Além disso, possui duas portas de entrada e saída de propósito geral (GPIO - General
Purpose Input/Output) que podem ser conectadas a sensores (NURDSPACE, 2013).
Figura 8 – ESP8266 (NURDSPACE, 2013)
4.1.5 Antena Ubiquiti
A recepção dos dados enviados pelos nós sensores é intermediada pela antena
Ubiquiti NanoStation locoM2 (Figura 9) (NETWORKS, 2015). Com uma frequência de
2.4GHz, throughput de 150Mbps e alcance de aproximadamente 5km, é uma antena bem
versátil. Ideal para aplicações ponto-a-multiponto (PtMP - Point-to-MultiPoint).
Figura 9 – Antena Ubiquiti NanoStation locoM2 (NETWORKS, 2015)
44
4.1.6 Máquina servidora
Os ambientes de teste e produção foram configurados em uma máquina servidora
HP Compaq Elite 8300 SFF com um processador Intel(R) Core(TM) i5-3570 de 3.40GHz e
8GB de memória RAM DDR3 rodando o Ubuntu Server 12.04LTS de 64bits. A arquitetura
do servidor é definida no capítulo 5, seção 5.2.
4.2 Softwares utilizados
4.2.1 Arduino IDE
Arduino IDE é o ambiente de programação para o Arduino. Consiste de um editor
de texto, área de log e uma barra de ferramentas. A IDE fornece maior suporte aos
desenvolvedores ao facilitar a compilação e upload do código fonte ao microcontrolador.
Ela também faz a gerência das bibliotecas utilizadas, por exemplo, pelo HMC5883l e pelo
CuHead que fazem parte deste trabalho.
Figura 10 – Arduino IDE
Esta é uma IDE open-source podendo ter o código-fonte baixado e alterado conforme
as necessidades do desenvolvedor.
4.2. Softwares utilizados
45
4.2.2 ESPTool
É uma ferramenta escrita em Python para auxiliar na comunicação com o ESP8266.
Funciona de forma similar ao Arduino IDE quanto ao apoio ao desenvolvedor no upload do
código-fonte ao microcontrolador. É executado através de linha de comando, onde dado a
porta de conexão do ESP8266, faz o envio do código-fonte compilado ao microprocessador
do dispositivo (AHLBERG, 2014).
4.2.3 Linguagens de programação
O uso de hardwares para controlar dispositivos e realizar leitura de sensores está
diretamente relacionado a programação. Este trabalho fez uso de algumas linguagens
específicas que foram escolhidas levando em consideração a aplicabilidade na área, o
conhecimento por parte do autor e a facilidade de escrita.
Na comunicação e operação dos hardwares utilizando o Arduino, foi utilizada
a linguagem própria baseada em C/C++ assim como algumas de suas bibliotecas. O
ESP8266 também foi programado através do Arduino IDE, o que proporcinou uma maior
adaptabilidade ao código por não ter sido necessário realizar muitas alterações.
A arquitetura do servidor foi dividida em três camadas (Tabela 2), onde na mais
baixa consta a comunicação com o gateway implementada em Python, a camada do meio
trata o banco de dados e a mais alta faz a comunicação com o nó sensor e com o cliente.
Essa última foi escrita em PHP.
Por último, entram as linguagens utilizadas no cliente da aplicação (Figura 15) que
é aquele “visto” (ou “percebido”) pelo usuário final. O Javascript foi amplamente utilizado
juntamente com a API do Google Maps (GOOGLE, 2015) para exibir as informações do
banco de dados.
4.2.4 Banco de dados MySQL
O MySQL é o sistema gerenciador de banco de dados (SGBD) open-source mais
popular do mercado (MYSQL, 2015). Ele faz uso da linguagem SQL como interface, possui
compatibilidade com as linguagens de programação mais utilizadas e suporta diversas
funcionalidades.
Neste trabalho, o banco de dados MySQL armazena capacidade do estacionamento,
localização e estado atual das vagas (livre ou ocupado). Além disso, faz um registro de
toda a atividade do sistema que pode ser consultado para otimizar preços e vagas.
46
4.3 Metodologia de desenvolvimento
Este trabalho foi desenvolvido dentro do laboratório de pesquisa em computação
móvel iMobilis (IMOBILIS, 2015) em João Monlevade. O laboratório segue a metodologia
de gerenciamento ágil de projetos BOPE (PEREIRA; Senna Carneiro; PEREIRA, 2013)
voltado para laboratórios de pesquisa em universidades brasileiras. O BOPE prevê a
elaboração de alguns artefatos na etapa de planejamento, os quais são apresentados no
capítulo de resultados, Apêndice A e Anexo A.
O desenvolvimento dos protótipos e do algoritmo de detecção veicular partiu de
um caso base (detecção de um automóvel em um estacionamento vazio) para casos mais
complexos (detecção de um automóvel em um estacionamento cheio).
Parte III
Resultados
49
5 Arquitetura do sistema
Este capítulo apresenta a arquitetura desenvolvida para o sistema. As próximas
seções tratam o protótipo 1 separadamente dos protótipos 2 e 3 pois esse possui uma
lógica invertida dos demais.
Definir a arquitetura do sistema é importante para maior clareza do funcionamento
do mesmo. É com essa arquitetura que todo o sistema é construído e testado. Pensando
nisso, este trabalho foi dividido em três etapas principais, sendo elas:
• Primeira etapa: Desenvolvimento de uma versão incial do algoritmo;
• Segunda etapa: Definição da arquitetura inicial do sistema, e;
• Terceira etapa: Aprimoramento da arquitetura e do algoritmo de deteção.
5.1 Visão geral
5.1.1 Protótipo 1
Inicialmente não havia a necessidade de se definir uma arquitetura, pois o protótipo
1 era utilizado inicialmente para coleta de dados do sensor para posterior análise na
máquina de desenvolvimento.
Esse primeiro protótipo consiste de um shield CuHead WiFi V1 acoplado a um
Arduino Uno Rev.3 e de um sensor de campo magnético HMC5883l. Na etapa inicial do
projeto, o protótipo foi colocado em uma vaga de estacionamento onde, ligado através
de um cabo USB a um notebook, transferia as informações que seriam utilizadas no
desenvolvimento do algoritmo de detecção (Figura 11).
Em uma etapa seguinte, passou-se a utilizar o protótipo conectado a bateria,
eliminando assim ruídos no sensor gerados pela variação no campo magnético causada
pela movimentação do cabo USB. Nesta segunda etapa, a arquitetura do sistema foi
definida, porém, devido a uma limitação da biblioteca do shield CuHead WiFi V1, a lógica
cliente-servidor precisou ser invertida, pois o shield não conseguia conectar ao servidor
e enviar dados. A solução encontrada foi transformar o sensor em um servidor, onde os
dados eram enviados como um broadcast permitindo a “máquina servidora” capturar estas
informações do sensor através do gateway (antena Ubiquiti) (Figura 12).
50
Capítulo 5. Arquitetura do sistema
Figura 11 – Arquitetura da primeira etapa do projeto
Figura 12 – Arquitetura invertida da segunda etapa do projeto
5.1.2 Protótip 2
O protótipo 2 foi desenvolvido na terceira etapa do projeto. Com ele foi possível
obter uma maior flexibilidade quanto a arquitetura do sistema, permitindo a melhoria da
mesma.
O protótipo 2 pode ser considerado como uma melhoria do protótipo 1. A diferença
entre eles está no dispositivo responsável pela transmissão dos dados via rede sem fio.
O ESP8266 foi utilizado em detrimento do shield CuHead para realizar a comunicação.
Com uma documentação melhor elaborada e mais completa, foi possível implementar
corretamente a arquitetura pensada inicialmente e, assim, fazer a correta distribuição das
informações.
Sendo assim, a arquitetura do sistema nesta etapa final do projeto fica definida
como mostrado na Figura 13.
5.2. A arquitetura a fundo
51
Figura 13 – Arquitetura final do projeto
No protótipo 1, devido a algumas limitações como o longo período para se conectar
ao gateway (aproximadamente 30s), não foi possível realizar otimizações na conexão para
reduzir o consumo energético. O protótipos 2 já fornece essa flexibilidade e, portanto, foi
possível implementar uma pequena otimização que já é o suficiente para conseguir uma
economia significativa no consumo energético. A otimização realizada no código faz com
que o protótipo conecte ao gateway apenas quando se fizer necessário transmitir alguma
informação. De acordo com o Datasheet do ESP8266 (NURDSPACE, 2013), seu consumo
energético enquanto conectado em uma rede sem fio é de 135 mA a 215 mA, enquanto que
em stand by, o consumo é de 0.9 mA.
5.2 A arquitetura a fundo
Examinando mais a fundo a arquitetura apresentada, é possível compreender o
funcionamento exato de todo o sistema, assim como suas limitações atuais.
A começar pelos nós sensores, que possuem um fluxo de trabalho bem simples
(Figura 14). Coletam dados, processam e transmitem o resultado ao gateway.
A função do gateway é de apenas repassar ao servidor os dados recebidos dos
sensores. Ele estabelece a conexão com o nó sensor e direciona o fluxo de dados ao servidor.
O servidor possui um grau de complexidade um pouco mais alto, visto que está
52
Capítulo 5. Arquitetura do sistema
Figura 14 – Fluxo de execução do nó sensor
dividido em três camadas (Tabela 2).
Tabela 2 – Camadas do servidor
3 - Camada de aplicação
2 - Camada de banco de dados
1 - Camada de troca de dados
A camada 1, troca de dados, é a mais baixa. Através de um código implementado
em Python, é responsável pelo recebimento dos dados direcionados pelo gateway. Após os
dados serem recebidos e tratados, são enviados a camada 2, banco de dados, para serem
armazenadas no SGBD MySQL e ficarem a disposição dos usuários do sistema através
da camada 3, aplicação. A camada de aplicação consta de um servidor web que exibe as
informações solicitadas pelo usuário (Figura 15) de forma simplificada.
A Figura 15 mostra um mapa da região próxima ao campus do Instituto de Ciências
Exatas e Aplicadas da Universidade Federal de Ouro Preto em João Monlevade, onde o
marcador verde simboliza um estacionamento mapeado dentro do campus. Os marcadores
possuem diferentes colorações para facilitar a rápida visualização da disponibilidade de
vagas (Tabela 3). Ao clicar em um marcador, um “balão” de informações é aberto com
detalhes sobre o estacionamento em questão como a porcentagem de vagas livres e o total
de vagas no estacionamento.
Esta terceira camada possui um lado backend e outro frontend. O primeiro se
comunica diretamente com a camada de banco de dados, esta foi implementada utilizandose a linguagem PHP. O segundo interage diretamente com o usuário e foi implementado
utilizando a biblioteca do Google Maps utilizando a linguagem javascript.
5.2. A arquitetura a fundo
53
Figura 15 – Página web de interação com usuário.
Tabela 3 – Diferentes colorações de marcadores e seus significados
Pelo menos 50% de vagas livres
Entre 20% e 50% de vagas livres
No máximo 20% de vagas livres
Todas as vagas ocupadas
55
6 Implementação
Neste capítulo são apresentadas todas as informações pertinentes para a continuidade do trabalho. Manter estes documentos em dia é de suma importância para a
elabaroação de futuras melhorias, já que as principais informações estão reunidas aqui.
6.1 Requisitos
O fluxo de trabalho do BOPE(PEREIRA; Senna Carneiro; PEREIRA, 2013)
determina que alguns artefatos de documentação precisam ser gerados. Dentre esses
documentos, as estórias de usuário e os requisitos do sistema são fundamentais para
entender as limitações e funcionalidades do mesmo.
Sendo assim, foram elaborados diversos requisitos funcionais e não funcionais
(Apêndice A) onde, a partir dos mesmos, diversas estórias puderam ser criadas (Anexo A)
facilitando a definição das tarefas e atividades a serem concluídas durante o desenvolvimento
deste projeto.
6.2 Banco de dados
Parte de grande importância ao projeto, o banco de dados é responsável por
armazenar e organizar todos os dados relevantes aos usuários e administradores do sistema.
O banco de dados foi desenvolvido através do SGBD MySQL(MYSQL, 2015). O
diagrama apresentado na Figura 16 mostra como o sistema está organizado. A tabela
parking_spaces armazena informações sobre as vagas de estacionamento como localização,
estado atual, orientação da vaga (horizontal, paralela ou 45 graus) e a antena utilizada
como gateway representada pela tabela antennas. Também é feita uma associação (tabela
pLot_has_pSpace) “um para muitos” onde um estacionamento (parking_lots) possui várias
vagas para se estacionar (parking_spaces).
A tabela status_log é responsável por armazenar toda atividade das vagas cadastradas no sistema. Esse registro é feito, automaticamente, sempre que o estado de uma
vaga é alterado.
6.3 Algoritmo de detecção
Pode-se dizer que o “coração” do projeto é o algoritmo de detecção apresentado no
fluxograma da Figura 17. Este algoritmo é responsável por, através das leituras do sensor,
56
Capítulo 6. Implementação
Figura 16 – Fluxograma do algoritmo de detecção
compilar, analisar e calcular o resultado do sinal obtido.
A execução do algoritmo começa ao definir o início das três iterações do teste de
verificação de presença de um automóvel. As três iterações são necessárias para eliminar
possíveis interferências externas como um automóvel passando nas proximidades do sensor.
Seguindo o fluxo de execução, é realizada a coleta de dados (algumas amostras) do
sensor de campo magnético HMC5883l nos três eixos X, Y e Z, obtendo-se algo similar
a Figura 18a quando todas as amostras forem reunidas após a saída da vaga pelo carro.
Realizada a coleta, os dados precisam passar por um processo de eliminação de ruído e
suavização para só então ser calculado a amplitude que será “estudada” pelo resto do
algoritmo. Ao final de todo o processo, o sinal tratado ficará como na Figura 18b.
Durante cada uma das três iterações de teste realizadas, o algoritmo verifica se a
amplitude do sinal de entrada é crescente através de uma janela amostral de tamanho três.
Cada amostra do teste é uma média de outras 15 amostras coletadas para a iteração. Ao
final das três rodadas de teste, se em todas as verificações o sinal for crescente e atingir
um nível acima do valor do limite previamente definido, então o retorno do algoritmo será
de vaga ocupada. Caso contrário, se os valores forem menores que o limite, o retorno do
algoritmo será de vaga livre.
O valor limite sofre variação de acordo com o tipo de ambiente em que o sistema
está sendo instalado (estacionamento fechado, via de grande movimento, etc), devendo ser
estudado antes da instalação dos sensores.
6.3. Algoritmo de detecção
57
Figura 17 – Fluxograma do algoritmo de detecção
(a) Leitura nos eixos X, Y e Z
(b) Amplitude do sinal
Figura 18 – Sinal de referência para o algoritmo
59
7 Trabalhos futuros
Este estudo envolve diversas áreas da computação como redes de sensores sem fio
e desenvolvimento de hardware embarcado. Durante o desenvolvimento do projeto não
houve tempo hábil para se trabalhar amplamente em todas essas áreas.
Aplicando este sistema em larga escala, seria necessário considerar as questões
energéticas do projeto. É inviável utilizar os protótipos atuais sem realizar otimizações
em hardware e software para se atingir uma vida útil de pelo menos 2 anos de bateria. A
redução da quantidade de componentes de hardware utilizados consequentemente reduziria
o desperdício de energia gerado pelo grande número de componetes em uso. Outro ponto a
ser adotado para economizar energia seria a utilização de recursos de software para alterar
o clock do microcontrolador em alguns momentos onde não se faz necessário tanto poder
de processamento assim como aumentar o intervalo de coleta de dados pelo sensor quando
a variação no campo magnético é mínima.
O custo de se utilizar hardware proprietário não está somente na parte financeira.
Além de ser mais caro, também pode acabar consumindo mais energia por utilizar componentes não necessários ao projeto. Então, o desenvolvimento de um dispositivo próprio
poderá ajudar tanto no consumo energético quanto na redução de custos.
Apesar da arquitetura da rede já estar definida, um ponto que ainda traz preocupações é a segurança dos dados que estão sendo transmitidos. Nenhuma informação de
usuário é transmitida ou armazenada em servidor, mas o sistema atualmente está passível
de interferências caso um usuário mal intencionado se conecte ao gateway. Isolar a rede e
criptografar as informações são apenas algumas das soluções disponíveis.
61
Conclusão
Com a facilidade em financiar um automóvel, as ruas têm ganhado cada vez mais
veículos. Nos centros comerciais das grandes cidades - e até das pequenas - é cada vez
mais comum o motorista se deparar com engarrafamentos e com a falta de vagas para
estacionar. Muito tem sido feito em ampliação de vias de acesso, mas pouco é investido
em tecnologias que viabilizem a redução do tráfego nesses centros.
Estudos já indicam que existe uma relação entre o aumento do trânsito e a busca por
lugares para estacionar. Então, a proposta deste trabalho foi apresentar uma arquitetura
de um sistema que permita ao motorista visualizar o atual estado dos estacionamentos
públicos ou privados antes mesmo de sair de casa.
Ao final da elaboração deste trabalho, artefatos de software, hardware e documentação foram criados. Um algoritmo adaptativo, que consegue identificar a presença de
automóveis ignorando interferências de temperatura e proximidade de outros materiais
ferrosos foi desenvolvido, assim como uma interface web para o acompanhamento das
vagas. Protótipos de hardware também foram criados a fim de validar o sistema e sua
arquitetura.
O sistema como um todo - software e hardware - apresenta grande potencial de
mercado, uma vez que ainda não existe tal sistema implantado em larga escala e existe
uma demanda dos usuários por tecnologias que auxiliem na busca por vagas. Espera-se
então que, com esta arquitetura e alguns estudos a serem realizados posteriormente, o
tempo de busca por uma vaga de estacionamento possa ser reduzido consideravelmente
uma vez que o sistema permite aos usuários a visualização das vagas antes de chegar ao
destino.
63
Referências
AHLBERG, F. esptool. 2014. Disponível em: <https://github.com/themadinventor/
esptool>. Acesso em: 29 abr 2015. Citado na página 45.
ANATEL. Relatório Anual 2013. 2013. Disponível em: <http://www.anatel.gov.br/
Portal/verificaDocumentos/documento.asp?numeroPublicacao=312603&pub=original&
filtro=1&documentoPath=312603.pdf>. Acesso em: 15 abr 2015. Citado na página 39.
ARDUINO. Arduino - ArduinoBoardUno. 2015. Disponível em: <http://www.arduino.cc/
en/Main/arduinoBoardUno>. Acesso em: 29 abr 2015. Citado na página 41.
ARDUINO. Arduino - Introduction. 2015. Disponível em: <http://www.arduino.cc/en/
Guide/Introduction>. Acesso em: 23 Abr 2015. Citado 2 vezes nas páginas 25 e 41.
CARRETERO, J.; GARCÍA, J. D. The internet of things: connecting the world. Personal
and Ubiquitous Computing, v. 18, p. 445–447, 2013. ISSN 1617-4909. Disponível em:
<http://link.springer.com/10.1007/s00779-013-0665-z>. Citado na página 32.
CISCO. Internet of Things (IoT). 2015. Disponível em: <http://www.cisco.com/web/
solutions/trends/iot/overview.html>. Acesso em: 26 mai 2015. Citado na página 33.
EMARTEE. HMC5883L 3-Axis Digital Compass Module. 2015. Disponível em:
<http://www.emartee.com/product/42254/HMC5883L%203%20Axis%20Digital%
20Compass%20Module>. Acesso em: 29 abr 2015. Citado 2 vezes nas páginas 25 e 42.
FENABRAVE. FENABRAVE Emplacamentos. 2015. Disponível em: <http:
//www3.fenabrave.org.br:8082/plus/modulos/listas/index.php?tac=indices-e-numeros&
idtipo=1&layout=indices-e-numeros>. Acesso em: 15 abr 2015. Citado na página 39.
GILL, K. S. The internet of things! then what? Ai & Society, v. 28, p. 367–371, 2013.
ISSN 0951-5666. Disponível em: <http://link.springer.com/10.1007/s00146-013-0520-9>.
Citado na página 32.
GOOGLE. API do Google Maps - Google Developers. 2015. Disponível em:
<https://developers.google.com/maps/?hl=pt-br>. Acesso em: 29 abr 2015. Citado na
página 45.
GUBBI, J. et al. Internet of things (iot): A vision, architectural elements, and future
directions. Future Generation Computer Systems, Elsevier B.V., v. 29, n. 7, p. 1645–1660,
2013. ISSN 0167739X. Disponível em: <http://dx.doi.org/10.1016/j.future.2013.01.010>.
Citado 2 vezes nas páginas 32 e 33.
HONEYWELL. Datasheet - HMC5883L 3-Axis Digital Compass IC. 2013.
Disponível em: <http://www51.honeywell.com/aero/common/documents/
myaerospacecatalog-documents/Defense_Brochures-documents/HMC5883L_
3-Axis_Digital_Compass_IC.pdf>. Acesso em: 29 abr 2015. Citado na página 42.
HUI, J. W.; CULLER, D. E. Ipv6 in low-power wireless networks. Proceedings of the IEEE,
v. 98, n. 11, p. 1865–1878, 2010. ISSN 0018-9219. Citado 3 vezes nas páginas 25, 31 e 32.
64
Referências
IBM. IBM Internet of Things Foundation (IoT Foundation). 2015. Disponível em:
<https://internetofthings.ibmcloud.com/>. Acesso em: 26 mais 2015. Citado na página
33.
IDRIS, M. et al. Parking Guidance System Utilizing Wireless Sensor Network and
Ultrasonic Sensor. Information Technology Journal, v. 8, n. 2, p. 138–146, fev. 2009. ISSN
18125638. Disponível em: <http://www.scialert.net/abstract/?doi=itj.2009.138.146>.
IDRIS, M. Y. I. et al. Car park system: A review of smart parking system and its
technology. Information Technology Journal, v. 8, n. 2, p. 101–113, fev. 2009. ISSN
18125638. Disponível em: <http://www.scialert.net/abstract/?doi=itj.2009.101.113>.
IMOBILIS. Laboratório iMobilis. 2015. Disponível em: <http://www.decom.ufop.br/
imobilis/>. Acesso em: 14 mai 2015. Citado na página 46.
INTEL. A Internet das coisas começa com Intel Inside. 2015. Disponível em:
<http://www.intel.com.br/content/www/br/pt/internet-of-things/overview.html>.
Acesso em: 26 mais 2015. Citado na página 33.
JIMÉNEZ, M.; PALOMERA, R.; COUVERTIER, I. Introduction to Embedded Systems:
Using Microcontrollers and the MSP430. Springer New York, 2013. (SpringerLink :
Bücher). ISBN 9781461431435. Disponível em: <https://books.google.com.br/books?id=
kcHBAAAAQBAJ>. Citado 3 vezes nas páginas 25, 29 e 30.
JOHNSON, M. et al. A comparative review of wireless sensor network mote technologies.
In: Proceedings of IEEE Sensors. [S.l.: s.n.], 2009. p. 1439–1442. ISBN 9781424445486.
ISSN 1930-0395. Citado na página 30.
LINKSPRITE. LinkSprite: Home of pcDuino, developer’s new choice. 2015. Disponível
em: <http://www.linksprite.com/>. Acesso em: 7 mai 2015. Citado na página 42.
MA, H. D. Internet of things: Objectives and scientific challenges. Journal of Computer
Science and Technology, v. 26, p. 919–924, 2011. ISSN 10009000. Citado 2 vezes nas
páginas 17 e 32.
MARSHALL, S. Vehicle detection using a magnetic field sensor. IEEE Transactions on
Vehicular Technology, v. 27, n. 2, p. 65–68, maio 1978. ISSN 0018-9545. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=1622466>. Citado na
página 36.
MERRIMAN, D. How many parking spaces does it take to create one additional transit
passenger? Regional Science and Urban Economics, v. 28, n. 5, p. 565–584, 1998. ISSN
01660462. Citado na página 25.
MICROSOFT. Internet of Things | Microsoft. 2015. Disponível em: <http:
//www.microsoft.com/en-us/server-cloud/internet-of-things.aspx>. Acesso em: 26 mai
2015. Citado na página 33.
MYSQL. MySQL::MySQL Editions. 2015. Disponível em: <https://www.mysql.com/
products/>. Acesso em: 23 abr 2015. Citado 2 vezes nas páginas 45 e 55.
Referências
65
NARMADA, A.; RAO, P. S. WSN and IP based parking management system. In: 2012
Sixth International Conference on Sensing Technology (ICST). IEEE, 2012. p. 434–438.
ISBN 978-1-4673-2248-5. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/
wrapper.htm?arnumber=6461716>. Citado na página 36.
NETWORKS, U. Ubiquiti Networks - Wireless networking products for broadband and
enterprise. 2015. Disponível em: <https://www.ubnt.com/>. Acesso em: 7 mai 2015.
NURDSPACE. ESP8266 - NURDspace. 2013. Disponível em: <https://nurdspace.nl/
ESP8266>. Acesso em: 23 Abr 2015. Citado 2 vezes nas páginas 43 e 51.
OSHANA, R.; KRAELING, M. Software Engineering for Embedded Systems: Methods,
Practical Techniques, and Applications. Elsevier Science, 2013. ISBN 9780124159419.
Disponível em: <https://books.google.com.br/books?id=qNrl7xV2nxkC>. Citado 2
vezes nas páginas 29 e 30.
PARAB, J. Practical Aspects of Embedded System Design using Microcontrollers. Springer,
2008. ISBN 9781402083938. Disponível em: <https://books.google.com.br/books?id=
mk9FCZHB5jwC>. Citado na página 29.
PEREIRA, I. M.; Senna Carneiro, T. G. de; PEREIRA, R. R. Developing Innovative
Software in Brazilian Public Universities: Tailoring Agile Processes to the Reality of
Research and Development Laboratories. In: Proceeding for the 4th Annual International
Conference on Software Engineering & Applications (SEA 2013). [s.n.], 2013. p. 115–124.
Disponível em: <https://www.dropbox.com/s/80vs1o8efabst1k/SEA2013\_Paper9.pdf>.
Citado 2 vezes nas páginas 46 e 55.
POPOVICI, E.; MAGNO, M.; MARINKOVIC, S. Power management techniques
for wireless sensor networks: A review. 5th IEEE International Workshop on
Advances in Sensors and Interfaces IWASI, p. 194–198, 2013. Disponível em:
<http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=6576090>. Citado 2
vezes nas páginas 25 e 31.
SADA. Some basics about Embedded Systems. 2010. Disponível em: <http:
//www.wittysparks.com/some-basics-about-embedded-systems>. Acesso em: 12 mar 2015.
SHAHEEN, S.; RODIER, C.; EAKEN, A. Smart Parking Management Field Test: A Bay
Area Rapid Transit (BART) District Parking Demonstration. [S.l.], 2005. Disponível em:
<http://escholarship.org/uc/item/6d58554x>. Citado na página 35.
SIFUENTES, E.; CASAS, O.; PALLAS-ARENY, R. Wireless Magnetic Sensor
Node for Vehicle Detection With Optical Wake-Up. IEEE Sensors Journal,
v. 11, n. 8, p. 1669–1676, ago. 2011. ISSN 1530-437X. Disponível em: <http:
//ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=5680571>. Citado na
página 36.
SRIKANTH, S. et al. Design and Implementation of a Prototype Smart PARKing (SPARK)
System Using Wireless Sensor Networks. In: 2009 International Conference on Advanced
Information Networking and Applications Workshops. IEEE, 2009. p. 401–406. ISBN 9781-4244-3999-7. Disponível em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?
66
Referências
arnumber=5136681http://ieeexplore.ieee.org/xpls/abs\_all.jsp?arnumber=5136681>.
XIA, F. et al. Internet of things. International Journal of Communication Systems, v. 25,
p. 1101–1102, 2012. ISSN 10745351. Citado na página 32.
YOO, S. E. et al. PGS: Parking guidance system based on wireless sensor network.
In: 3rd International Symposium on Wireless Pervasive Computing, ISWPC 2008,
Proceedings. IEEE, 2008. p. 218–222. ISBN 9781424416530. ISSN 1550445X. Disponível
em: <http://ieeexplore.ieee.org/lpdocs/epic03/wrapper.htm?arnumber=4556200>.
ZHANG, Z. et al. A street parking system using wireless sensor networks. International
Journal of Distributed Sensor Networks, v. 2013, n. c, p. 1–10, 2013. ISSN 15501329.
Disponível em: <http://www.hindawi.com/journals/ijdsn/2013/107975/>. Citado na
página 36.
Apêndices
69
APÊNDICE A – Requisitos do sistema
Objetivo do documento
Este documento visa descrever as informações referentes às funções que o sistema abaixo identificado deve executar bem como às restrições sobre as quais o sistema deve operar.
Termos e definições
São adotados os seguintes termos e definições:
Tipo de requisito
•
Funcional: são aqueles que expressam funções ou serviços que o sistema deve ser capaz de
executar sem levar em consideração restrições. Os requisitos funcionais especificam o
comportamento de entrada e saída de dados no sistema e suas relações;
•
•
Descrevem explicitamente as funcionalidades e serviços do sistema.
Nãofuncional: os requisitos não funcionais são aqueles relacionados ao uso da aplicação em
termos de performance, usabilidade, confiabilidade, segurança, disponibilidade,
manutenibilidade e tecnologias envolvidas.
•
Definem propriedades e restrições do sistema quanto a:
•
•
•
•
•
•
•
Desempenho;
Usabilidade/Navegabilidade;
Confiabilidade;
Segurança;
Disponibilidade;
Manutenibilidade; e
Tecnologias envolvidas.
Prioridade de requisito
•
Essencial: os requisitos essenciais são aqueles imprescindíveis, sem os quais o sistema não entra
em funcionamento e, portanto, devem ser implementados impreterivelmente; •
Importante: os requisitos importantes são aqueles que sem os quais o sistema entra em
funcionamento, mas não de forma satisfatória. Os requisitos considerados importantes, devem
ser implementados, mas se não forem o sistema poderá funcionar mesmo assim;
•
Desejável: os requisitos desejáveis são aqueles que não comprometem as necessidades básicas
do sistema. Caso não haja tempo hábil para implementação, esses requisitos podem ser
deixados para versões posteriores.
Lista de requisitos não funcionais – Interface web
Título
Descrição
ACID (Atomicidade, O sistema deve utilizar sempre que aplicável o Consistência, Isolamento conceito de ACID nas transações.
e Durabilidade)
Atomicidade: todas as suas operações executadas em caso de sucesso ou nenhum resultado refletido sobre a base de dados em caso de falha. Ou seja, após o término de uma transação (commit ou abort).
Tipo
Prioridade
Não
funcional
Essencial
Consistência: respeitar as regras de integridade dos dados (como unicidade de chaves, restrições de integridade lógica, etc...).
Isolamento: evitar que transações paralelas interfiram umas nas outras.
Durabilidade: As transações em caso de sucesso (commit) devem persistir no banco de dados mesmo em presença de falhas.
Reaproveitamento de código
O sistema deve, sempre que possível, fazer o reaproveitamento de códigos preferencialmente
Não funcional
Importante
Aparência
Deve fazer uso das tecnologias CSS e Javascript
Não funcional
Essencial
Ambiente de operação
O sistema deve rodar em ambiente web sob o web Não server apache e em linguagem de programação php funcional
Essencial
Performance de exibição O sistema deve exibir informações apenas da região Não das informações
do mapa mostrada em tela.
funcional
Importante
Tempo de exibição das informações
Essencial
O sistema deve ser capaz de carregar as Não informações em até 3 segundos para conexões com funcional
largura de banda maiores que 5Mbps e 5 segundos para conexões com largura de banda entre 1Mbps e 5Mbps, não podendo ultrapassar esse tempo.
Lista de requisitos funcionais – Interface web
Título
Descrição
Tipo
Prioridade
Exibição de estacionamentos
O sistema deve ser capaz de exibir os estacionamentos no mapa
Funcional
Essencial
Exibição de vagas em estacionamentos
O sistema deve ser capaz de exibir a quantidade Funcional
de vagas disponíveis em um estacionamento
Essencial
Cadastro de usuário
O sistema deve permitir que um usuário se cadastre fornecendo, pelo menos, os seguintes dados:
• Nome;
• Email;
• Senha.
O sistema deve permitir, também, o cadastro através de redes sociais
Funcional
Desejável
Autenticação do Usuário
O acesso ao sistema deverá ser controlado via login e senha ou redes sociais.
Funcional
Desejável
Recuperação de senhas
Deverá ser permitido ao usuário recuperar sua senha desde que confirmada sua identidade. Essa recuperação de senha deve ocorrer por meio de token enviado ao email cadastrado.
Funcional
Desejável
Logout do sistema
O sistema deverá permitir ao usuário poder sair Funcional
(logout) a qualquer momento.
Desejável
Lista de requisitos não funcionais – Dispositivo
Título
Descrição
Tipo
Prioridade
Identificação de mudança de estado de uma vaga
O dispositivo deve ser capaz de identificar Não Funcional Essencial
quando um carro entra e sai de uma vaga de
estacionamento em, no máximo, 10 segundos
Otimização de tráfego de dados
O dispositivo deve enviar ao servidor apenas o status da vaga, além dos dados necessários para identificação do dispositivo.
Não Funcional Importante
Consumo de bateria
O dispositivo deve ser capaz de se manter com a mesma bateria por pelo menos 6 meses
Não funcional Importante
Segurança da informação
O dispositivo deve ser capaz de realizar transmissões de dados de forma segura
Proteção contra agentes O dispositivo deve ser capaz de funcionar externos
durante alterações do clima (chuva, vento, descargas elétricas, sol, …) e deve ter proteção contra impactos e vandalismo
Anexos
77
ANEXO A – Estórias de usuário
Mostrar Mapa  O sistema deve exibir informações apenas da região do
mapa mostrada em tela.
Estória de usuário:
COMO usuário
EU GOSTARIA de visualizar a região do mapa mostrada em tela
PARA CONSEGUIR visualizar as informações
Critérios de aceitação
Cenário principal:
DADO que o usuário abra uma área do mapa
QUANDO o sistema exibir a região do mapa mostrada em tela
ENTÃO as informações daquela região serão mostradas
Mostrar Estacionamento  O sistema deve ser capaz de exibir os
estacionamentos no mapa
COMO usuário
EU GOSTARIA de visualizar o mapa
PARA CONSEGUIR visualizar os estacionamentos no mapa
Cenário principal:
DADO que o usuário acesse a interface web
QUANDO o acesso for realizado
ENTÃO o mapa exibe os estacionamentos
Exibir Vagas  O sistema deve ser capaz de exibir a quantidade de vagas
disponíveis em um estacionamento
COMO usuário
EU GOSTARIA de visualizar detalhes um estacionamento
PARA CONSEGUIR saber a quantidade de vagas disponíveis em um
estacionamento
Cenário principal:
DADO que o usuário clique em um marcador no mapa
QUANDO o marcador for acionado
ENTÃO o sistema exibe a quantidade de vagas disponíveis naquele
estacionamento
Cadastrar Usuário  O sistema deve permitir que um usuário se cadastre
fornecendo, pelo menos, os seguintes dados: • Nome; • E-mail; • Senha
COMO usuário
EU GOSTARIA de fornecer Nome, E-mail e senha
PARA CONSEGUIR me cadastrar
Cenário principal:
DADO que usuário queira se cadastrar
QUANDO ele fornecer nome, e-mail e senha
ENTÃO o usuário será cadastrado
Cenário alternativo 1:
DADO que o usuário insira um e-mail já existente
QUANDO sistema identificar dois e-mails iguais
ENTÃO (i) o sistema informa que o e-mail já existe; (ii) o sistema não
realizada o cadastro
DADO que o usuário insira um e-mail incorreto
QUANDO o sistema identificar um e-mail sem arroba
ENTÃO (i) o sistema informa que o e-mail está incorreto; (ii) o sistema não
realizada o cadastro
Autenticar Usuário  O acesso ao sistema deverá ser controlado via
login e senha ou redes sociais.
COMO usuário
EU GOSTARIA de realizar o login
PARA CONSEGUIR acessar o sistema
Cenário principal:
DADO que o usuário realize o login
QUANDO o login for realizado
ENTÃO o usuário acessa o sistema
DADO que o usuário insira uma senha incorreta
QUANDO sistema identificar o erro
ENTÃO (i) o sistema informa que o acesso não foi permitido; (ii) o sistema
não realizada o acesso
DADO que o usuário insira um e-mail incorreto
QUANDO sistema identificar o erro
ENTÃO (i) o sistema informa que o acesso não foi permitido; (ii) o sistema
não realizada o acesso
Recuperar Senha  Deverá ser permitido ao usuário recuperar sua senha
desde que confirmada sua identidade. Essa recuperação de senha deve
ocorrer por meio de token enviado ao e-mail cadastrado.
COMO usuário
EU GOSTARIA de confirmar minha identidade através de um token recebido
no e-mail cadastrado
PARA CONSEGUIR recuperar minha senha
Cenário principal:
DADO que o usuário esqueceu a senha
QUANDO solicitar a recuperação de senha
ENTÃO o sistema envia ao e-mail cadastrado um token para recuperação
Logout  O sistema deverá permitir ao usuário poder sair (logout) a
qualquer momento.
COMO usuário
EU GOSTARIA de realizar o logout
PARA CONSEGUIR sair do sistema
Cenário principal:
DADO que o usuário acesse o logout
QUANDO o logout for acionado
ENTÃO o usuário sai do sistema

Park My Ride: Um sistema inteligente para - iMobilis

Transcrição

Documentos relacionados

SMRH/DTA. DRS, 13/11/2012. Concursos em andamento: Edital nº

CLARICE CORBELLA CASTELO BRANCO FERNANDA SILVEIRA

Ciclos e ondas

Visualizar - Fundação Ajuri

Ford Mustang 3.7 V6

MARAVILHA

H21-001 - Logger de dados da estação de tempo

Renault Master Fourgon 2.3 dCi L2H2 3.5T Confort

Crescer no valor, valorizando a vida.

Volante 6 SK - MTE