Everton Nedel

Fazer download em pdf ou txt
Fazer download em pdf ou txt
Você está na página 1de 75

UNIVERSIDADE DO VALE DO RIO DOS SINOS - UNISINOS

UNIDADE ACADÊMICA DE GRADUAÇÃO


CURSO DE ENGENHARIA DA COMPUTAÇÃO

EVERTON NEDEL

SISTEMA DE RASTREAMENTO DO CIRCULAR DA UNISINOS UTILIZANDO


LoRaWAN®

São Leopoldo
2019
EVERTON NEDEL

SISTEMA DE RASTREAMENTO DO CIRCULAR DA UNISINOS UTILIZANDO


LoRaWAN®

Trabalho de Conclusão de Curso


apresentado como requisito parcial para
obtenção do título de Bacharel em
Engenharia da Computação, pelo Curso de
Engenharia da Computação da
Universidade do Vale do Rio dos Sinos -
UNISINOS

Orientador: Prof. Dr. Rodrigo Marques de Figueiredo

São Leopoldo
2019
AGRADECIMENTOS

Agradeço à minha família, em especial a minha mãe e meu pai por todo apoio
prestado em minha caminhada acadêmica.
A todos professores que contribuíram para a aquisição do conhecimento
obtidos nessa trajetória acadêmica, em especial ao meu orientador Prof. Dr. Rodrigo.
Ao grupo de amigos que se criou durante o curso, tornando a rotina acadêmica
muito mais descontraída e divertida.
3

RESUMO
Para facilitar o acesso dos usuários à informação e melhorar os serviços da
linha Circular da Unisinos, foi desenvolvido um sistema capaz de realizar o
monitoramento de localização em tempo real do ônibus. O sistema a partir de uma
rede LoRaWAN® (LoRa for Wide Area Network), utilizando a tecnologia LoRa® (Long
Range) de rádiofrequência, transmite os dados de localização adquiridos de um
modulo GPS (Global Position System) para um servidor, que torna os dados
disponíveis para o usuário em um mapa interativo. O diferencial deste sistema é ter
seu funcionamento sem custos periódicos, como, por exemplo, os gerados pelos
planos de telefonia móvel, que são exigidos em muito dos rastreadores presentes no
mercado. O sistema funcionou plenamente com base nos requisitos levantados,
porém a rede utilizada mostrou limitações quanto ao alcance do sinal, onde em alguns
pontos com distancias de 1 km, a comunicação se perdia. Dessa forma, foi identificado
que com somente um gateway LoRaWAN®, a rede não abrangeu toda a área da rota
do circular, sendo que em alguns pontos houve perda de alguns dados, e em alguns
outros pontos houve total perda de dados. Dessa forma, é necessário uma extensão
da rede com pelo menos mais um gateway, assim tendo toda a rota do circular
coberta.

Palavras-chaves: Internet das Coisas. LoRa®. LoRaWAN®. Rastreamento.


4

ABSTRACT
To facilitate user access to information and make better the services of the
Unisinos Circular Line, it was deployed a system able to make a real time bus
monitoring. The system, from a network LoRaWAN®, using radio frequency technology
LoRa® transmit the localization data acquired from a GPS module to a server, that
makes the data available in an interactive map. The system differential is work without
a periodically cost, for example the generated by mobile phone plans, that is required
by the GPS tracker founded in the market. The system worked perfectly but have
limitation about the signal reach, having some points on the route, where with 1 km the
communication got lost. On this way, it was identified that with only one LoRaWAN®
gateway, the network didn’t cover all the Unisinos Circular area, where in some places,
some data were lost, and, in some places, data were completely lost. So, it is needed
to get a network extension with at least one more gateway for having its fully operation.

Keywords: Internet of Things. LoRa®. LoRaWAN®. Tracking.


LISTA DE FIGURAS

Figura 1 – Defasagem do sinal recebido x sinal gerado............................................ 16


Figura 2 - Demonstrativo sinal Chirp com fatores de espelhamento do 7 ao 12 ....... 21
Figura 3 – Faixa de operação LoRa® no Brasil ......................................................... 22
Figura 4 – Topologia da rede LoRaWAN® ................................................................. 23
Figura 5 – Classes de operação LoRaWAN® ............................................................ 24
Figura 6 – Ilustração da arquitetura do sistema ........................................................ 35
Figura 7 - Fluxograma da função principal no dispositivo final .................................. 37
Figura 8 – Diagrama de blocos do sistema embarcado ............................................ 38
Figura 9 – Esquemático do circuito de acionamento dos módulos LoRa® e GPS ..... 41
Figura 10 – Fluxograma da lógica para ativação do circuito de baixo consumo. ...... 42
Figura 11 – Esquemático do circuito de acionamento da sinalização sonora ........... 43
Figura 12 – Dispositivo Final ..................................................................................... 44
Figura 13 – Modelagem do banco de dados ............................................................. 45
Figura 14 – Fluxograma do processo Integrador....................................................... 48
Figura 15 – Verificação de veículo dentro da rota ..................................................... 51
Figura 16 – Formulário para ativação do modo fora de operação ............................. 53
Figura 17 – Dados GPS plotados no mapa ............................................................... 58
Figura 18 – Consumo de energia do dispositivo fora de operação ........................... 59
Figura 19 – Aplicativo Android® demonstrando veículo fora de operação ................. 60
Figura 20 – Teste dispositivos simultâneos na página web ...................................... 61
Figura 21 - Teste dispositivos simultâneos na aplicativo Android ............................. 61
Figura 22 – Intervalo de máximos e mínimos entre envios ....................................... 62
Figura 23 – Teste da validação dos dados um .......................................................... 63
Figura 24 – Teste da validação dos dados dois ........................................................ 63
Figura 25 – Área de alcance rede LoRaWAN® com base na rota ............................. 64
Figura 26 – Dados do teste de fora de rota ............................................................... 66
Figura 27 – Funcionamento do sistema .................................................................... 67
Figura 28 – Localização dos envios no teste de operação final ................................ 68
LISTA DE QUADROS

Quadro 1 – Relação graus decimais x metros........................................................... 17


Quadro 2 – Comparativos do estado da arte............................................................. 29
LISTA DE SIGLAS

ADC Analog-to-Digital Converter


ADR Adaptative Data Rate
AES Advanced Encryption Standard
BW Bandwith
C/A Coarse Acquisition
CR Code Rate
CSS Chirp Spread Spectrum Modulation
DAC Digital-to-Analog Converter
dBm Decibel-miliwatt
FEC Forward Error Correction
FSK Frequency Shift Keying
GHz Gigahertz
GLONASS Sistema de Navegação Global por Satélite
GNSS Global Navigation Satellite System
GPIO General Purpose Input/Output
GPRS General Packet Radio Service
GPS Global Positioning System
GSM Global System for Mobile Communications
HAL Hardware Abstraction Layer
HTML Hypertext Markup Language
HTTP Hypertext Transfer Protoco
IoT Internet of Things
JSON Javascript Object Notation
kbps Kilobit per second
L1 Layer 1
L2 Layer 2
LMIC LoraWAN in C
LoRa® Long Range
LoRaWAN® LoRa for Wide Area Network
LPWAN Low-Power Wide-Area Network
MHz Megahertz
8

MQTT Message Queue Telemetry Transport


ORM Object Relational Mapper
P Precision
PCI Placa de Circuito Impressa
PHP Hypertext Prepocessor
PRN Pseudo Random Noise
Rb Rate bit
RF Rádio Frequência
RPMA Random Phase Multiple Acess
RSSI Received signal strength indication
SF Spreading Factor
SMS Short Message Service
SPI Serial Peripheral Interface
SQL Structured Query Language
SSP Spread Spectrum Modulation
TDOA Time Diference of Arrival
UART Universal Asynchronous Receiver/Transmitter
UDP User Datagram Protocol
USB Universal Serial Bus
UTC Coordinated Universal Time
WGS-84 World Geodetic System
SUMÁRIO

1 INTRODUÇÃO ....................................................................................................... 11
2 FUNDAMENTAÇÃO TEÓRICA ............................................................................. 14
2.1 NAVEGAÇÃO...................................................................................................... 14
2.1.1 GPS .................................................................................................................. 14
2.2 INTERNET DAS COISAS.................................................................................... 18
2.2.1 LPWAN ............................................................................................................ 18
2.2.2 LoRa®............................................................................................................... 20
2.2.2.1 LORAWAN® .................................................................................................. 23
2.2.3 Protocolo MQTT ............................................................................................. 26
2.3 TRABALHOS CORRELATOS ............................................................................. 26
3 METODOLOGIA .................................................................................................... 31
3.1 LEVANTAMENTO DE REQUISITOS .................................................................. 31
3.1.1 Requisito de alcance ...................................................................................... 31
3.1.2 Requisito de não haver custo periódico ...................................................... 31
3.1.3 Requisito de intervalo de envio .................................................................... 32
3.1.4 Requisito de tamanho .................................................................................... 32
3.1.5 Requisito de alimentação e consumo elétrico............................................. 32
3.1.6 Requisito de funcionalidade ininterrupta e permanente............................. 32
3.1.7 Requisito de interface com o usuário........................................................... 33
3.1.8 Requisito de histórico de dados ................................................................... 33
3.1.9 Requisito de sinalização de segurança ........................................................ 33
3.1.10 Requisito de validação dos dados .............................................................. 33
3.1.11 Requisito de funcionamento simultâneo de dispositivos finais .............. 34
3.2 SISTEMA PROPOSTO ....................................................................................... 34
3.3 DISPOSITIVO FINAL .......................................................................................... 35
3.4 BANCO DE DADOS ............................................................................................ 44
3.5 INTEGRADOR .................................................................................................... 46
3.6 APRESENTAÇÃO ............................................................................................... 52
3.7 TESTES DO SISTEMA ....................................................................................... 55
3.7.1 Teste do GPS .................................................................................................. 55
3.7.2 Teste de energia ............................................................................................. 55
3.7.3 Teste de dispositivos simultâneos ............................................................... 56
10

3.7.4 Teste de intervalo de envio ........................................................................... 56


3.7.5 Teste de validação dos dados....................................................................... 56
3.7.6 Teste de cobertura da rota ............................................................................ 57
3.7.7 Teste de fora de rota ...................................................................................... 57
3.7.8 Teste de funcionamento ................................................................................ 57
4 ANÁLISE DE RESULTADOS ................................................................................ 58
4.1 RESULTADOS DO TESTE DE GPS ................................................................... 58
4.2 RESULTADO DO TESTE DE ENERGIA............................................................. 59
4.3 RESULTADO DO TESTE DE DISPOSITIVOS SIMULTÂNEOS ......................... 60
4.4 RESULTADO DO TESTE DE INTERVALO DE ENVIO ...................................... 62
4.5 RESULTADO DO TESTE DE VALIDAÇÃO DOS DADOS .................................. 62
4.6 RESULTADO DO TESTE DE COBERTURA DA ROTA ..................................... 64
4.7 RESULTADO DO TESTE DE FORA DE ROTA .................................................. 65
4.8 RESULTADO DO TESTE DE FUNCIONAMENTO ............................................. 66
5 CONCLUSÃO ........................................................................................................ 69
REFERÊNCIAS ......................................................................................................... 71
11

1 INTRODUÇÃO

Na rotina diária das pessoas, cada vez mais é sentida a necessidade de estar
conectado e ter acesso instantâneo à informação. Com o avanço da IoT (Internet of
Things) e a conexão de objetos comuns à Internet, torna-se cada vez mais provável
que a informação desejada esteja disponível. A Unisinos - Universidade Vale do Rio
dos Sinos, disponibiliza de forma gratuita um ônibus que faz uma rota especifica
chamado de circular. O circular permite ao seus utilizadores realizarem o
deslocamento entre as periferias do campus da universidade e a estação do Trensurb
(Empresa de Trens Urbanos de Porto Alegre S.A.). O trabalho proposto terá como
objetivo fornecer ao usuário do circular da Unisinos um sistema que, informe a atual
localização do veículo. O sistema busca melhorar a experiência do usuário do circular,
assim como aprimorar questões de segurança.
Em uma rápida busca por relatos de usuários do circular, é possível encontrar
diversas histórias sobre más experiências ao utilizar esse serviço. Elas se intensificam
principalmente nos períodos de pico, horários das 19:00 às 19:30 e das 21:45 às
22:15, momentos em que há uma maior utilização em função dos horários de início e
fim das aulas noturnas que têm uma maior quantidade de alunos. Dentre os diversos
relatos, muitos estão relacionados à não chegada na parada do ônibus a tempo de
pegá-lo. Essa situação ainda pode se agravar fazendo com que o usuário perca o
próximo transporte, levando consideração que a tabela de horários do circular não
está vinculada a tabela de horários da Trensurb (TRENSURB, [2019?], UNISINOS,
2018.). Isso pode fazer com que se torne um problema em cascata, tendo todo um
planejamento de horário alterado por vários minutos, causado pelo atraso de alguns
segundos.
Ainda é possível citar como problema os dias de chuva, apesar de todas as
paradas da Unisinos terem coberturas, o espaço pode ser insuficiente em certas
ocasiões. O usuário contando com um mecanismo onde fosse possível fazer o
acompanhamento da posição do veículo em tempo real, poderia se deslocar para a
parada somente no momento em que o veículo estivesse muito próximo. Isto
preveniria o usuário de eventualmente ter que esperar o veículo por longos períodos
em lugares não cobertos. Ainda pode ser considerado o melhor aproveitamento do
tempo do aluno em sala de aula. Isto porque com o acompanhamento da
12

movimentação do veículo em tempo real, é possível que o estudante permaneça mais


alguns minutos em aula e não aguardando o ônibus na parada.
O desenvolvimento desse trabalho se justifica em vários aspectos, um deles
pode até mesmo influenciar na decisão de um aluno na escolha de sua universidade.
A escolha da Universidade por um aluno, está ligada a vários fatores. Um desses
fatores, o qual tem um grande peso para a decisão final do aluno, é a facilidade de
transporte (GALVÃO et al, 2017). Isso mostra a necessidade da preocupação em
fornecer a melhor experiência possível para o usuário nesse quesito, mesmo não se
tratando da atividade principal.
Outro ponto que pode ser considerado importante na justificativa para a
realização do trabalho é a segurança extra do veículo. No ano de 2017, São Leopoldo
foi a sétima cidade com maior número de roubos de veículos no estado do Rio Grande
do Sul (LOPES, 2018). Apesar do sistema não prevenir o roubo, ele poderia auxiliar
na recuperação do veículo. Com o monitoramento em tempo real, poderia ser
observada a correta localização do veículo, acionando as autoridades responsáveis.
Outro ponto extra que poderia ser benéfico com o uso do sistema referente à
segurança, seria o monitoramento de velocidade do veículo. Com o monitoramento
em tempo real e o envio da informação de velocidade, poderiam ser visualizados os
motoristas que não respeitam os limites, podendo assim tomar as medidas
necessárias para que o limite seja respeitado.
Para o cumprimento do proposto trabalho será necessário o desenvolvimento
de um sistema embarcado para a coleta de dados de localização do veículo. O sistema
embarcado utilizará um módulo GPS para coleta de dados da localização do veículo,
enviando os dados via uma rede LoRaWAN®. As informações recebidas serão salvas
em um banco de dados onde estarão disponíveis para ser acessadas por plataformas
que tornam os dados recebidos pelo sistema embarcado em algo intuitivo para o
usuário. Como ferramenta auxiliar, serão desenvolvidas duas plataformas para a
exibição dos dados para o usuário, são elas uma página web e um aplicativo para
smartphones Android®. As plataformas utilizarão os dados enviados pelo sistema
embarcado, que são latitude e longitude, inserindo-os em um mapa interativo.
Apresentados a introdução e objetivo do trabalho, é possível definir a
organização e ordem cronológica do documento. No capítulo dois será apresentado o
referencial teórico, onde serão abordados assuntos chaves para o entendimento do
trabalho e o seu desenvolvimento. No capítulo três será apresentada a metodologia
13

do trabalho. Serão analisados os componentes envolvidos no sistema e a forma como


será desenvolvido. Nesse capítulo também poderá ser analisado o fluxo de
desenvolvimento e de testes que foram realizados. No capítulo quatro serão
mostrados os resultados obtidos a partir do desenvolvimento e da aplicação dos
testes. O fechamento será feito no capítulo cinco, onde poderá ser conferida a
conclusão com as considerações finais do trabalho.
14

2 FUNDAMENTAÇÃO TEÓRICA

Considerando os objetivos do trabalho, neste capítulo serão abordados os


temas fundamentais para correto seu entendimento, sendo eles as tecnologias de
Navegação, IoT, LPWAN (Low Power Wide Area Network), LoRaWAN® e o protocolo
MQTT (Message Queue Telemetry Transport). Da mesma forma serão tratados os
tópicos de estudo mais recentes na área de rastreamento de objetos móveis, fazendo
um levantamento no estado da arte e comparando com a metodologia utilizada para
a solução do problema para o presente trabalho.

2.1 NAVEGAÇÃO

A Navegação é definida pela capacidade de conhecer a localização atual,


assim como saber para onde se está indo. A Navegação está presente em nosso dia
a dia desde orientações cotidianas até em situações mais complexas. Para realizar a
navegação, muitas vezes, apenas o senso de localização e sentidos do ser humano
são o suficiente, esses que são capazes de reconhecer lugares, ler placas, ver a
posição do sol, etc. Porém em situações que se faz necessário uma melhor precisão
de navegação, utiliza-se algum tipo de instrumentação para o auxílio, como bússolas
ou sistemas de rádio navegação. Dentre os sistemas de rádio navegação, temos o
GPS, sistema utilizado em todo mundo, capaz de trazer uma ótima capacidade de
navegação (FASCIONI, 2013). Suas características e funcionamento serão
explicados no tópico abaixo.

2.1.1 GPS

O GPS (Global Positioning System, do inglês Sistema de Posicionamento


Global) é um sistema global de rádio navegação desenvolvido pelo Departamento de
defesa dos Estados Unidos da América. Tinha como objetivo principal o uso militar e
posteriormente foi liberado para o uso civil. O GPS permite que seus utilizadores
obtenham informações tridimensionais de sua localização e velocidade em qualquer
lugar da superfície terrestre sob qualquer condição climática. O GPS também é capaz
de fornecer aos seus usuários o tempo universal coordenado UTC (Coordinated
15

Universal Time, do inglês Tempo Universal Coordenado) (KAPLAN; HEGARTY,


2006).
O funcionamento do GPS ocorre através do dimensionamento das distâncias
entre os satélites e o receptor. Para que seja possível fazer a triangulação e obter o
posicionamento terrestre em 3 dimensões, são necessários três satélites. Apesar de
todos os relógios do GPS estarem sincronizados, os relógios do satélite são muito
mais precisos do que os relógios dos receptores, logo as distâncias obtidas a partir de
três satélites possuem uma margem de erro e são chamadas de pseudo-distâncias.
Para resolver esse problema é utilizado um quarto satélite que, matematicamente,
consegue corrigir o erro gerado pela divergência de relógios e refração do sinal na
atmosfera terrestre (TIMBÓ, 2000).
Todos os satélites do GPS transmitem seus dados modulados em fase em duas
ondas senoidais portadoras simultâneas, L1 (Layer 1) e L2 (Layer 2). Os sinais são
gerados por osciladores atômicos de alta estabilidade, e todos são gerados a partir da
frequência fundamental de 10,23 MHz que é a base para todo o sistema. As ondas
portadoras L1 e L2 tem suas frequências definidas em 154 e 120 vezes a frequência
fundamental do sistema, tendo assim seus valores estipulados em 1572,42 MHz e
1227,60 MHz respectivamente (TIMBÓ, 2000).
Há dois códigos que são transmitidos no GPS responsáveis diretamente por
prover a informação necessária para a localização, são eles o código P (Precision
Code) e o código C/A (Coarse Acquistion Code). O código C/A é repetido a cada 1
ms, é modulado somente na onda portadora L1 e é a base para o uso civil do GPS. O
Código P é reservado para uso militar e usuário autorizados. Repetindo-se a cada
sete dias, código P traz melhor precisão na localização do sistema e é modulado nas
duas ondas portadoras L1 e L2. Atualmente Código P é criptografado, assim mudando
sua nomenclatura para código Y. Ambos os códigos C/A e P utilizam sinais PRN
(Pseudo-Random) com modulação binária de fase na portadora. O sinal PRN
aparenta ser uma sequência binária aleatória, porém podem ser determinados. Cada
satélite tem seu próprio PRN, assim o receptor pode identificar o satélite que está
enviando o sinal, já que todos operam na mesma frequência (KAPLA;.HEGARTY,
2006).
Como foi visto anteriormente, a base do funcionamento do GPS está em
encontrar as distâncias entre os transmissores e o receptor para realizar os cálculos
do correto posicionamento. Para que seja possível obter essa informação, é utilizada
16

a relação Distância = Velocidade x Tempo. Como a velocidade de propagação de um


sinal eletromagnético é uma constante física, adquirindo-se o tempo do sinal no ar é
possível calcular a distância. O cálculo do tempo é feito com base no código PRN,
onde cada receptor tem o código PRN de cada satélite. Considerando que os relógios
do receptor e dos transmissores estão em sincronia, o receptor assim como o emissor
emitem o PRN conhecido, o receptor então compara o sinal recebido com o emitido
por ele mesmo. Ao verificar a defasagem entre o sinal recebido e o gerado, é possível
obter o tempo que sinal percorreu entre a sua origem até o seu destino (KAPLAN;
HEGARTY, 2006).

Figura 1 – Defasagem do sinal recebido x sinal gerado

Fonte: Kaplan e Hegarty (2006)

Com as distâncias entre o receptor e os satélites, e o posicionamento do GPS


obtidos pelos receptores, é calculado a posição com base em seu sistema referencial
WGS-84 (World Geodetic System), que é o sistema base para toda a operação de
localização do GPS. O sistema WGS-84 traz informações de distâncias
tridimensionais com base no centro de massa da Terra. Os receptores são capazes
17

de realizarem uma conversão, trazendo os dados do sistema WGS-84 obtidos, para o


sistema de coordenadas esféricas, que consiste em Latitude, Longitude e Altitude.
Coordenadas esféricas trazem informações da superfície terrestre com base no
meridiano de Greenwich, linha do Equador e nível do mar (TIMBÓ, 2000).
• Latitude é a distância em graus, minutos e segundos em relação a linha
do Equador.
• Longitude é a distância em graus, minutos e segundos em relação ao
meridiano de Greenwich
• Altitude é a distância em relação ao nível do mar (KAPLAN; HEGARTY,
2006).
Os dados de latitude e longitude podem ser utilizados para mensurar distâncias.
Para que seja possível realizar essa tarefa, é necessário um fator de conversão de
metros para graus decimais de latitude e longitude. Como a Terra é uma esfera, a
relação entre graus decimais e metros varia conforme aumenta a distância da Linha
do Equador. Essa diferença na relação pode ser vista no Quadro 1, construído a partir
de DIP ([2019?]). Nela é apresentado os graus da linha do Equador (0) ao ponto mais
ao extremo sul da Terra (90). As distâncias foram tiradas com base na diferença de
exatamente um grau decimal de longitude, ou seja, de forma paralela a linha do
Equador.

Quadro 1 – Relação graus decimais x metros


Graus decimais Distancia (metros)
0 111319,892
10 109639,886
20 104647,931
30 96487,549
40 85.395,511
50 71.697,618
60 55.801,800
70 38.187,966
80 19.394,273
90 0,000

Fonte: Elaborado pelo autor, com base em DIP ([2019?])

Como citado anteriormente, o GPS é um sistema capaz de operar em qualquer


lugar da superfície terrestre. Sistemas com essa característica são denominados
GNSS (Global Navigation Satellite System). Atualmente os GNSS em operação são
18

os sistemas GPS dos Estados Unidos e GLONASS da Rússia, porém há previsão de


que até em 2020 os sistemas Galileo da União Europeia e Compass da China iniciarão
seus serviços para os usuários finais globalmente (USA GOV, 2017). Dentre as
diversas áreas de aplicações que utilizam o GPS, podemos citar a IoT, uma área que
vem crescendo muito nos últimos anos e que em muitas de suas aplicações, como
rastreamento veicular, necessitam de informações providas pelo GPS.

2.2 INTERNET DAS COISAS

A Internet das Coisas (Internet of Things) é a expansão da internet para


dispositivos de uso geral de nosso dia a dia. A conexão criada entre os objetos e a
internet permitem aos objetos a capacidade de se comportarem como atuadores ou
sensores, ou seja, controlar remotamente ou utilizar informações providas como
serviços (SANTOS, et al., 2016). A aplicação da internet das coisas está presente nas
mais diversas áreas de atuação, como eHealth, transporte inteligente, distribuição de
energia, casas inteligentes, segurança pública, distribuição e logística, indústrias,
agricultura de precisão e cidades inteligentes (MANCINI, 2018). A arquitetura básica
dos dispositivos IoT são: unidade de processamento, unidade de comunicação, fonte
de energia e unidade de sensores ou atuadores (SANTOS, et al., 2016).
Como apresentado nos tópicos anteriores, diversas aplicações e áreas
atualmente utilizam IoT, o que faz com que uma única tecnologia seja incapaz de
atender a todas as necessidades. Enquanto algumas necessitam de altas taxas de
transmissão de dados, outras demandam poucos bits por segundo. Também surgiram
diversas áreas que necessitam longas distâncias de aplicação e baixo consumo de
energia, e com isso surge um novo paradigma para a IoT, tecnologias LPWAN (Low-
Power Wide-Area Network) (GARCIA; KLEINSHCMIDT, 2017).

2.2.1 LPWAN

As redes LPWAN são conhecidas por redes de alto alcance e baixo consumo
de energia, surgindo para cobrir uma alta gama de aplicação IoT que necessitam
desses quesitos. Abaixo serão listados os itens principais que caracterizam uma
LPWAN.
19

• Baixíssima potência de operação: É uma necessidade para contornar


o problema de altos custos com trocas de baterias assim como a longa
duração de dispositivos, sem a necessidade de qualquer recarga
(BARDYN et al., 2016).
• Baixo custo de implementação: É requerido que o custo de
desenvolvimento do hardware seja baixo e haja pouca necessidade de
manutenção. Também é necessário que utilize arquitetura e protocolos
simples (BARDYN et al., 2016).
• Configuração da rede: As conexões dos dispositivos finais das redes
LPWANs são de modo geral feitas em um ou mais gateways, formando
assim uma topologia do tipo estrela, que se assemelha muito à rede de
telefonia móvel (CENTENARO et al., 2015). Também é desejável que a
rede tenha uma alta escalabilidade. A ação de adicionar novos
dispositivos à rede deve ser uma tarefa simples, podendo ser a rede
ampliada sem consequência para os demais dispositivos finais
(BARDYN et al., 2016).
• Longo alcance: As LPWANs devem dar suporte à comunicação de
longo alcance, podendo chegar a dezenas de quilômetros dependendo
da sua condição de operação. Porém devem manter o baixo consumo
de energia, para atender ao requisito de longa duração. O fator que
permite que o longo alcance e o baixo consumo de energia sejam
alcançados simultaneamente é a modulação do sinal utilizada,
permitindo que as redes LPWANs operem com sensibilidade em torno
de -150 dBm (BARDYN et al., 2016).
• Baixa taxa de transmissão de dados: As redes LPWAN em
contrapartida de seu longo alcance apresentam de forma geral uma
baixa taxa de transmissão de dados, na casa de poucos kbps. Muito
inferior quando comparado às redes de baixo alcance como Bluetooth
(CENTENARO et al., 2015). A maioria das LPWANs opera centralizadas
em frequências não licenciadas ISM (Industrial Sientific and Medical) são
elas 169 MHz, 433 MHz, 868 MHz, 915 MHz e 2.4 GHz.
A seguir serão visualizadas as principais tecnologias LPWAN do mercado que
trabalham nas frequências em questão: (CENTENARO et al, 2015)
20

SIGFOX®: Fundada em 2009, foi a primeira tecnologia LPWAN no mercado. A


SIGFOX tem uma característica de operadora, similar às operadoras de telefonia
móvel, tornando seu modelo de negócio uma operadora de serviço de IoT.
Inicialmente o projeto suportava somente comunicação unilateral de upload. Hoje
conta com comunicação bidirecional e garantia de área de cobertura de até 50 km em
áreas rurais e até 10 km em áreas urbanas (CENTENARO et al., 2015). Uma
característica relevante dos serviços prestados pela SIGFOX é a geolocalização
integrada. A partir de seus gateways e pela força do sinal recebido, o sistema é capaz
de definir a localização do dispositivo final, o que pode ser bastante oportuno para
aplicações que necessitem desses dados, já que geralmente módulos GPS
consomem energia e tem um custo extra de hardware (GARCIA; KLEINSHCMIDT,
2017).
Ingenu: Uma tecnologia emergente no ramo de LPWAN é a Ingenu, empresa
da companhia On-Ramp Wireless. A companhia criou e patenteou sua tecnologia
chamada RPMA (Random Phase Multiple Acess). Diferentemente de outras
modulações de LPWAN, a RPMA funciona na frequência não licenciada universal de
2,4G Hz e apesar dessa característica, a robustez do seu sinal na camada física
permite que se tenha um longo alcance (CENTENARO et al., 2015).
No próximo tópico será abordado a LPWAN focada na tecnologia LoRa®, a que
mais se destaca e vem crescendo entre as LPWAN. Também será a base tecnológica
LPWAN utilizada para cumprir os objetivos do presente trabalho.

2.2.2 LoRa®

LoRa® é uma técnica de modulação proprietária pertencente à SEMTECH.


Diferentemente da SIGFOX®, as redes utilizando tecnologia LoRa® não são
disponibilizadas por empresas como servidoras de IoT. Utilizá-la em um projeto
implicará na responsabilidade, gestão e manutenção da infraestrutura da rede
(GARCIA; KLEINSHCMIDT, 2017).
A modulação LoRa® utiliza a técnica de SSP (Spread Spectrum Modulation, do
inglês modulação de espalhamento espectral), que é derivada do CSS (Chirp Spread
Spectrum Modulation). Seu funcionamento, simplificadamente, consiste na geração
de um sinal chirp/símbolo, que é formado a partir da variação contínua da frequência
em relação ao tempo (SEMTECH, 2015). A tecnologia tem como característica uma
21

técnica de espalhamento capaz de diminuir a relação sinal ruído no receptor, para que
ainda consiga capturar o sinal recebido corretamente. Há três parâmetros básicos
para geração desse sinal (GARCIA; KLEINSHCMIDT, 2017):
• Spreading Factor (SF): Define o número de bits enviados a cada chirp,
podem ser configurados entre 7 a 12.
• Bandwidth (BW): É a largura do canal de comunicação, pode ser
definido nas frequências de 125 kHz, 250 kHz e 500 kHz.
• Forward Error Correction (FEC / Code Rate (CR)): Fator de correção
de erro que auxilia na robustez do sinal a ser transmitido, seu valor pode
ser estipulado entre 1 e 4 (BARDYN et al., 2016).
Estes três parâmetros são responsáveis diretos pela determinação da taxa de
dados a serem transmitidas. Abaixo pode ser visualizada a equação referente a
determinação do Rb (Rate bit), que é dada em bits por segundo.
𝐵𝐵𝐵𝐵 4
𝑅𝑅𝑅𝑅 = 𝑆𝑆𝑆𝑆 ∗ 2𝑆𝑆𝑆𝑆 ∗ 4+𝐶𝐶𝐶𝐶 (1)

Na Figura 2 é possível visualizar o comportamento do sinal, em uma análise


Tempo x Frequência. É possível visualizar que quanto maior o SF, maior o tempo para
a transmissão do símbolo.

Figura 2 - Demonstrativo sinal Chirp com fatores de espelhamento do 7 ao 12

Fonte: GHOSLYA (2013)


22

Uma das características da modulação LoRa® que auxiliam no aumento da


distância da comunicação é a maneira na qual é realizada a recepção do sinal no
dispositivo. A coerência de demodulação do espalhamento de símbolos é capaz de
aumentar de 6 dB à 10 dB quando comparado a modulação FSK (Frequency Shift
Keying) para a mesma taxa de dados. Usando valores mais altos para o SF, a rede
LoRa® é capaz de atingir sua sensibilidade em -137 dBm (BARDYN et al., 2016).
Outra característica importante da modulação LoRa® é a ortogonalidade entre
os fatores de espelhamento. Diferentes fatores de espelhamento são ortogonais, e
quando recebidos simultaneamente são considerados ruídos entre eles, fazendo com
que seja possível que um gateway consiga receber mais de uma transmissão em um
mesmo canal ao mesmo tempo (BARDYN et al., 2016).
A tecnologia LoRa® é capaz de alcançar distâncias de até 15 km em áreas
rurais e até 5 km em áreas urbanas. Pode operar nas frequências de 169 MHz, 433
MHz, 868 MHz e 915 MHz (CENTENARO et al., 2015). No Brasil, a rede opera
seguindo a mesma configuração da norma australiana AU915-928 que opera entre as
frequências de 915 MHz até 928 MHz com um intervalo de não operação entre as
frequências de 917 MHz a 923 MHz, conforme pode ser visualizado na Figura 3 (LORA
ALLIANCE, 2018).

Figura 3 – Faixa de operação LoRa® no Brasil

Fonte: Lora Aliance (2018)

Como visto no presente tópico, LoRa® é uma técnica de modulação


independente atuando na camada física. Sua utilização de modo geral está associada
ao uso de protocolos de camadas superiores. A escolha dos protocolos e a arquitetura
da rede são de extrema importância, pois são eles que têm a maior influência quando
considerados os quesitos de duração de bateria do dispositivo final, capacidade da
23

rede, qualidade do serviço, segurança e variedade de aplicações (LORA ALLIANCE,


2015).

2.2.2.1 LORAWAN®

LoRaWAN® (Long-Range Wide Area Networks) é um conjunto de


especificações de protocolos para uma rede LPWAN, modelada com o objetivo de ser
a chave para a IoT. É mantido pela LoRa® Alliance, uma associação aberta liderada
pelas companhias IBM, Actility, Semtech e Microchip (LORA ALLIANCE, 2015). Na
Figura 4 é possível verificar a arquitetura de uma rede LoRaWAN® e todos os
elementos envolvidos.

Figura 4 – Topologia da rede LoRaWAN®

Fonte: Lora Alliance (2015)

Com base na Figura 4, podemos visualizar 4 grupos de dispositivos na rede


LoRaWAN®. São eles os dispositivos finais, gateway, servidor de rede e servidor de
aplicação. Os itens listados serão detalhados individualmente nos parágrafos que
seguem.
Como o uso de LoRaWAN® está fortemente relacionado à IoT, dispositivos
finais frequentemente operam como sensores ou atuadores. Uma das características
da rede é que dispositivos finais de uma rede LoRaWAN® não estão associados a um
24

único gateway, assim mais de um gateway pode receber informação de um mesmo


dispositivo. Regularmente utilizam a modulação LoRa® para realizar comunicação,
porém podem utilizar outras tecnologias como FSK (LORA ALLIANCE, 2015).
Gateways concentram as informações recebidas pelos dispositivos finais,
retransmitindo-as para um servidor de rede LoRaWAN® via protocolo UDP. São
capazes de receber dados em diversos canais ao mesmo tempo, cobrindo uma
grande gama de dispositivos finais. Geralmente a comunicação com o servidor de
rede ocorre via interface de rede de banda larga ou tecnologias de telefonia móvel
(SILVA et al, 2017).
Servidores de rede recebem os dados do gateway. São responsáveis por
conferirem a integridade das informações, gerando os pacotes que devem ser
enviados para o devido servidor de aplicação, assim como realizar a filtragem de
pacotes redundantes e enviar os pacotes que devem ser transmitidos de volta para os
dispositivos finais via gateway (LORA ALLIANCE, 2015).
Os servidores de aplicação são uma forma de agrupar os dispositivos com
aplicação semelhantes, a fim de processá-los e utilizá-los da forma que é desejada
(SILVA et al, 2017). Os dispositivos finais de uma rede LoRaWAN® podem ter as mais
diversas finalidades e requisitos. Com base nisso, dispositivos finais podem operar
em 3 diferentes classes da rede LoRaWAN®, são elas classe A, B e C, e suas
características de operação pode ser visto na Figura 5.

Figura 5 – Classes de operação LoRaWAN®


25

Fonte: Lora Alliance (2015)

Classe A – O dispositivo final é responsável por iniciar a transmissão, sendo


que somente ele pode realizar essa operação. Após a transmissão dos dados pelo
dispositivo final, o gateway terá um intervalo de tempo para responder e poderá
realizar a resposta exclusivamente nesse intervalo. Após o intervalo de tempo de
resposta, será necessário aguardar outra transmissão iniciada pelo dispositivo final
para que possa realizar a comunicação. Dispositivos classe A são os que consomem
menos energia entre as três classes (LORA ALLIANCE, 2018).
Classe B – Comparados com os dispositivos classe A, os dispositivos classe B
podem ter janelas de recebimento de dados programadas. Em intervalos de tempo
definidos serão abertas as janelas de recebimento nos dispositivos finais. O intervalo
de tempo será sincronizado com o servidor, permitindo assim que o mesmo seja capaz
de saber o momento em que o dispositivo final estará com a janela de recebimento
aberta (LORA ALLIANCE, 2018).
Classe C – Os dispositivos classe C têm sua janela de recebimento
continuamente aberta, somente será fechada no momento em que estiver
transmitindo. Dispositivos classe C utilizam mais energia quando comparados a
dispositivos classe A e B, porém é capaz de oferecer uma latência menor entre a
comunicação com o servidor de rede (LORA ALLIANCE, 2018). A definição das
classes está diretamente relacionada ao consumo de energia dos dispositivos finais.
Outra característica que está diretamente relacionada ao consumo de energia dos
dispositivos finais da rede LoRaWAN® é o ADR (Adaptative Data Rate). O ADR é um
mecanismo que atua individualmente na transmissão de dados de cada dispositivo
final. Varia a potência de transmissão e a taxa de dados conforme a necessidade,
desta forma busca diminuir o consumo de energia dos dispositivos finais, assim como
melhorar a capacidade da rede. A capacidade de transmissão entre dispositivos finais
e gateways está entre 0,3 a 50 kbps (LORA ALLIANCE, 2018)
Outra característica que é exigida quando se trata de LPWANs é a segurança
da rede. A LoRaWAN® utiliza duas camadas de segurança, uma atuando a nível da
camada de rede e outra atuando a nível da camada de aplicação. A camada de
segurança de rede garante a autenticidade dos dados entre o dispositivo final e o
servidor de rede, enquanto a camada de segurança de aplicação assegura a
integridade dos dados entre o dispositivo final e a aplicação. Ambas camadas de
26

segurança utilizam a criptografia AES-128 (Advanced Encryption Standard) (LAVRIC;


POPA, 2017).

2.2.3 Protocolo MQTT

Com a necessidade de realizar a integração entre o servidor de rede


LoRaWAN® e o servidor de aplicação que dará visibilidade e funcionalidade à
aplicação desenvolvida, é necessário a utilização de um protocolo de Ethernet
responsável por essa comunicação. Dentre os diversos servidores de rede
LoRaWAN® disponíveis no mercado, todos dispõe entre outras, realizar a integração
com o servidor de aplicação via protocolo MQTT (Message Queue Telemetry
Transport, do português Enfileiramento de Mensagens de Transporte de Telemetria).
O protocolo MQTT, é um protocolo que se tornou padrão na utilização na IoT.
Desenvolvido pela IBM no final dos anos 90, o protocolo funciona com base em
publicação e assinatura em tópicos, onde todos os dispositivos assinados em um certo
tópico receberão os dados assim que algum dispositivo publicar no tópico em questão
(YUAN, 2017).
O protocolo MQTT traz características ideais para a utilização em conjunto com
o IoT, já que é um protocolo leve, capaz de operar em redes com largura de banda
limitada e alta latência. Quando comparado a padrões de internet mais utilizados como
o HTTP, por exemplo, são consideradas desvantagens para aplicações na IoT:
(YUAN, 2017)
• Um protocolo síncrono, onde a cada requisição é esperada uma resposta;
• Um protocolo com comunicação unidirecional, fazendo com que o cliente
sempre tenha que iniciar a comunicação;
• Um protocolo com comunicação um para um, tornando difícil o envio de dados
para diversos dispositivos;
• Um protocolo pesado, com um cabeçalho grande.

2.3 TRABALHOS CORRELATOS

Com a evolução das LPWAN novas abordagens para o rastreamento e


monitoramento de objetos móveis se tornaram possíveis. Diversos trabalhos dos
27

últimos cinco anos com o tema em questão foram encontrados e serão trazidos a
seguir com o objetivo de analisar as diferentes tecnologias e metodologias aplicadas.
Uma grande gama de trabalhos foi dedicada ao rastreamento de animais de
pequeno porte. Nesses trabalhos a preocupação com o peso e tempo de vida do
dispositivo eram cruciais, pois, normas regulamentam o peso máximo de um objeto
que pode ser acoplado em um animal com base no seu peso. Um exemplo é o trabalho
de Bouten et al (2012), que criaram um dispositivo capaz de monitorar a migração de
pássaros de pequeno porte. Os três requisitos mínimos para esse sistema eram: a
não necessidade de recapturar os pássaros para aquisição dos dados, obtenção da
localização 3D do animal e um dispositivo com peso máximo de doze gramas. Para
atingir o requisito do peso, uma das abordagens necessárias foi a utilização de uma
antena fractal para o módulo GPS, que tem um peso muito menor quando comparado
a antenas de cerâmica padrões de módulos GPS. O dispositivo ainda conta com uma
placa solar para o carregamento da bateria e uma memória flash de 4 MB, capaz de
armazenar os dados obtidos. Ainda contava com um transceptor ZigBee que com os
testes aplicados alcançava até 8,5 km em céu aberto sem obstáculos e uma altitude
considerável, porém tinha desempenho bastante limitado quando submetido a
ambientes com relevos e obstáculos. Para a situação mais crítica foram necessários
seis concentradores para cobrir a área de estudo de 50 km².
Ainda foi encontrado outro trabalho em que a preocupação com o baixo
consumo de energia estava em foco, buscando trazer alternativas para aquisição da
localização via módulos GPS, que consomem uma quantidade considerável de
energia. Um exemplo é Fargas e Petersen (2017) que em seu trabalho propuseram
um método que consiste em realizar a comunicação a partir de uma rede LoRaWAN®
e que fosse capaz de fornecer a localização sem um módulo GPS. A metodologia
aplicada consistia em criar uma área de cobertura que em qualquer lugar os sinais
transmitidos pelos dispositivos finais fossem recebidos por 4 gateways. Com os
relógios do gateway sincronizados, utilizou-se a técnica de TDOA (Time Diference of
Arrival, do inglês tempo diferencial de recebimento). Esta técnica tem como
fundamento comparar a variação do tempo em que cada gateway recebeu o mesmo
sinal e que, segundo o autor, estudos recentes confirmam que TDOA traz um melhor
desempenho para aquisição da localização quando comparado ao RSSI (Received
signal strength indication). Após a aplicação da metodologia se observou uma
precisão de até 100 metros na obtenção da localização com um consumo médio de
28

12,9 mA, valor de extrema eficiência quando comparado a módulos comuns de GPS
e GSM (Global System for Mobile Communications) que tem um consumo de 400-600
mA durante a transmissão.
Já em outros trabalhos que não havia muita preocupação com o consumo de
energia, foram utilizadas soluções similares à proposta pelo presente trabalho, que
consiste na utilização do módulo GPS e comunicação via LoRAWAN®. Baharudin e
Yan (2016) tinham como objetivo criar um dispositivo capaz de enviar em tempo real
a sua localização via uma rede LPWAN. A arquitetura do projeto consistia em um
número indeterminado de dispositivos finais, que deveriam enviar sua localização para
um concentrador. A arquitetura dos dispositivos finais contava com um
microcontrolador Arduino Uno em conjunto com Dragino Lora Shield, que tem uma
interface dedicada para a comunicação com o microcontrolador utilizado. O dispositivo
final ainda tinha uma bateria de lítio de 9 V responsável por fornecer energia para o
dispositivo e um módulo GPS para aquisição dos dados a serem enviados, que são:
UTC, latitude, longitude, velocidade e curso. O concentrador era composto por um
Galileo Gen 2 da Intel e utilizava a mesma placa Dragino LoRa Shield do dispositivo
final para a comunicação. Após desenvolvimento dos protótipos, foi feita uma análise
na capacidade de alcance do sinal de comunicação, em um estudo comparando o
número de dispositivos realizando a comunicação simultaneamente e o RSSI no
receptor. Com base nos dados coletados, foi possível visualizar que o aumento dos
dispositivos diminui a intensidade do sinal na recepção.
Já San-Um et al (2017) tinham como objetivo em seu trabalho criar um
dispositivo LoRaWAN® chamado U-LoRa para utilização em conjunto de tropas
táticas. Seu dispositivo final contava com um microcontrolador Arduino pro-mini,
módulo GPS neo-6m, um módulo LoRa® e uma bateria de lítio. O gateway era
composto por um módulo LoRa® e uma Raspberry Pi 3 Modelo B+, esse era conectado
a um computador via interface de rede. Os módulos LoRa® tinham uma potência de
transmissão de 2 dBi operando a uma frequência de 433 MHz. Foram capazes de
alcançar distâncias de até 500 metros, após isso o sinal era perdido. O autor ainda
cita que em aplicações onde há necessidade de maiores distâncias, é possível
modificar a potência de saída e as antenas para que o alcance seja maior.
Ao que se trata de trabalhos recentes envolvendo rastreamento de veículos,
poucos foram encontrados. Em geral os trabalhos têm mais que 5 anos e utilizam
outras tecnologias que não envolvam comunicação através de LPWANs. É possível
29

citar Lien, Chen e Bai (2008), que em seu trabalho desenvolveram um rastreador
veicular em tempo real. O rastreador consiste em um módulo GPS e um módulo
GSM/GPRS, capazes de enviar informações referentes à localização do veículo para
um servidor através da internet via rede de dados móveis. Também conta com
sensores que auxiliam na identificação de roubos, enviando um alerta via SMS para o
proprietário do veículo. O sistema ainda permitia a possibilidade de configuração do
intervalo de envio da localização para o servidor.
Mais recentemente Li, Cheng e Zhang (2016) trazem uma abordagem parecida
com o trabalho descrito anteriormente. O sistema contém os mesmos módulos GPS
e GPRS, porém traz algumas novas funcionalidades como captura de imagens em
tempo real a partir de uma câmera integrada e a quantia de gasolina presente no
tanque de combustível. O trabalho também trouxe evoluções referentes a
apresentação para o usuário final, que a partir de um aplicativo de celular consegue
ter a visualização das informações e solicitar a captura de uma foto instantaneamente.
Para os últimos trabalhos apresentados anteriormente, verificou-se que apesar
da eficiência em atingir seus objetivos de rastrear veículos, para cada rastreador era
necessário um plano de telefonia móvel para que a comunicação fosse possível,
planos que acrescentam custos periódicos e que dependo da aplicação podem tornar
o projeto inviável. Com a evolução das LPWANs e seu longo alcance, é possível
analisar uma abordagem diferente para rastreamento de veículos, visando eliminar os
custos periódicos e ainda sim ter o mesmo desempenho. No Quadro 2 é possível
visualizar o comparativo entre o estado da arte e o presente trabalho.

Quadro 2 – Comparativos do estado da arte


BAHARUDIN, LEKBUNYASIN,
BOUTEN, 2013 FARGAS, 2017 LIEN, 2008 LI, 2016 NEDEL, 2019
2016 2017
Tecnologia de
ZigBee LoRaWAN LoRaWAN LoRaWAN SMS/GPRS GPRS LoRaWAN
comunicação
Chip de Dragino Lora
não especificado não especificado não especificado não especificado A GPRS 1090 E19-915M30S
comunicação Shield v95-868
Aquisição da mecanismo
módulo GPS módulo GPS módulo GPS módulo GPS módulo GPS módulo GPS
localização próprio
Chip de
não especificado X GMS7-CR6 NEO-6M não especificado não especificado NEO-6M
localização
Alimentação do bateria do bateria do bateria do
bateria propria bateria propria bateria propria bateria propria
sistema veiculo veiculo veiculo
UTC, Latitude, Latitude,
Latitude, Latitude, Latitude,
Longitude, Longitude,
Dados enviados Longitude e não especificado não especificado Longitude e Longitude e
Velocidade e Combustivel,
Altura distancia Velocidade
Curso Velocidade
Distâncias Operadora de Operadora de
8,5 km não especificado não testado 500 metros 950 metros
Máxima celular celular
Intervalo de
Variável 5 segundos 2 não especificado 10 a 60 minutos não especificado Até 15 segundo
envios
30

Fonte: Elaborado pelo autor

Com as informações essenciais apresentadas para o correto entendimento do


trabalho, assim como a análise de trabalhos correlatos, é possível avançar na
elaboração da plataforma a ser proposta, buscando encontrar a melhor solução para
o problema em questão.
31

3 METODOLOGIA

Neste capítulo será apresentado o sistema proposto e o seu desenvolvimento.


Inicialmente será feito uma avaliação dos requisitos do sistema. Em uma segunda
etapa serão apresentadas as partes que compõem o sistema proposto, dividindo a
metodologia em processos específicos, apresentadas individualmente. E para a
conclusão do capítulo, será apresentado o fluxo de testes a serem realizados.

3.1 LEVANTAMENTO DE REQUISITOS

Nesta seção é realizado o levantamento dos requisitos do sistema proposto.


Os requisitos são restrições que o sistema deve atender, ou seja, basicamente
definem seu funcionamento e suas condições e limitações de funcionamento. Para
cada requisito levantado no presente parágrafo, pelo menos um teste será
responsável por garantir sua funcionalidade. As descrições dos testes estão presentes
no tópico 3.7 e os seus resultados no capítulo 4.

3.1.1 Requisito de alcance

O ponto mais distante da rota do circular em relação ao gateway da rede


LoRaWAN® da Unisinos que receberá o sinal do dispositivo, está a aproximadamente
1,5 km de distância, próximo à estação do Trensurb. Nesse caso será necessário um
mínimo de 2 km de alcance do ponto onde o concentrador está, dessa forma tendo
uma margem de segurança de 0,5 km.

3.1.2 Requisito de não haver custo periódico

Como já citado na introdução do trabalho, o objetivo do sistema será realizar o


rastreamento do veículo sem a geração de custos periódicos. O sistema, somente
com o seu investimento inicial, deverá funcionar sem qualquer tipo de custo extra para
mantê-lo, somente poderá haver custos em uma suposta necessidade de manutenção
do dispositivo.
32

3.1.3 Requisito de intervalo de envio

Para que seja possível ter um acompanhamento com uma noção razoável de
monitoramento em tempo real, entende-se que seja enviado os dados de localização
e velocidade do veículo a cada 15 segundos, no máximo. Caso contrário, distâncias
muito longas poderão ser percorridas sem que o veículo atualize sua posição atual.

3.1.4 Requisito de tamanho

O dispositivo que realizar a coleta dos dados deverá ter um tamanho


relativamente pequeno comparado ao veículo, para, assim, ter disponibilidade de ser
colocado em qualquer lugar dentro do ônibus. Também deverá ter capacidade para
que sua antena alcance a parte superior do veículo, fazendo com que o dispositivo
consiga transmitir e receber os dados com um maior alcance.

3.1.5 Requisito de alimentação e consumo elétrico

Veículos de grande porte como caminhões e ônibus de modo geral contam com
um sistema elétrico de 24 V (Volts) (OLIVEIRA, 2010). Enquanto o veículo está ligado,
essas baterias são recarregadas pelo seu alternador, mantendo assim as baterias
carregadas para quando o veículo for novamente desligado. Dessa forma, quando
estiver desligado, o veículo consegue acionar seu motor de partida, que irá liga-lo. Em
uma suposta situação em que ocorra o término da carga das baterias enquanto estiver
desligado, o veículo não conseguirá dar partida sozinho (DIAS, 2015). Analisando esta
situação, é necessário atentar para a utilização do dispositivo quando o veículo estiver
desligado por longos períodos, pois provavelmente o dispositivo será instalado em
local de difícil acesso, prejudicando o desligamento manual. O dispositivo deverá
possibilitar o corte ou a limitação de consumo de energia, para que não haja
comprometimento no restante do veículo.

3.1.6 Requisito de funcionalidade ininterrupta e permanente

O sistema deve operar de forma ininterrupta, sem nenhuma ação do usuário


para essa ocasião. Esta é uma preocupação para que o dispositivo que envia os dados
permaneça ativo, e não funcione por alguns minutos e depois seja interrompido
33

inesperadamente por um erro imprevisto, como estourar a memória do


microcontrolador, por exemplo.

3.1.7 Requisito de interface com o usuário

O sistema deverá contar com um mecanismo de apresentação dos dados de


localização do veículo, assim com uma identificação na ocorrência de algum erro,
como por exemplo a perda de conexão com o dispositivo. Esse mecanismo poderá
ser utilizado por qualquer usuário que tenha acesso a internet, e a localização dos
veículos deverá ser apresentada em um mapa de forma que fique intuitivo para o
usuário conhecer a sua localização.

3.1.8 Requisito de histórico de dados

O sistema deverá armazenar por tempo indeterminado os dados de localização


assim como a qual veículo eles pertencem, sua data de obtenção e qual a resposta
enviada para o dispositivo.

3.1.9 Requisito de sinalização de segurança

O sistema deverá contar com um mecanismo de sinalização indicando que o


veículo saiu da rota programada. Sempre que for identificado que o veículo não está
na rota pré-programada, o dispositivo deverá sinalizar para o motorista e os
passageiros.

3.1.10 Requisito de validação dos dados

Como o sistema utilizará o GPS para a coleta dos dados de localização e


velocidade, com um hardware de terceiros próprio para essa finalidade, deve ser
previsto o não funcionamento correto do item citado, assim como problemas de
captura do sinal em algum ponto específico da rota. Neste caso, deverá ser realizada
a validação dos dados recebidos, verificando se estão corretos.
34

3.1.11 Requisito de funcionamento simultâneo de dispositivos finais

O sistema desenvolvido deve funcionar para mais de um dispositivo ao mesmo


tempo. Como há mais de um ônibus que deverá ser monitorado, o sistema deve
permitir suporte para que todos funcionem simultaneamente.
Com o levantamento dos requisitos realizados neste tópico, será apresentado
na próxima sessão a caracterização do sistema proposto, que demonstrará os
componentes que integram o sistema e seu funcionamento resumido.

3.2 SISTEMA PROPOSTO

O sistema proposto para o monitoramento e rastreamento do ônibus circular da


Unisinos será dividido em três processos independentes que utilizam algum
mecanismo para se comunicar, são eles definidos pelos nomes de dispositivo final,
integrador e apresentação. Uma das formas de comunicação será o banco de dados.
Ela que fará o armazenamento e a comunicação entre os processos Integrador e
Apresentação. A comunicação entre os processos de dispositivo final e do integrador
será feita através de uma rede LoRaWAN®.
O dispositivo final será um sistema embarcado que enviará periodicamente
dados GPS de localização e velocidade através de uma rede LoRaWAN®. O
integrador por sua vez será responsável por receber os dados pela rede LoRaWAN®
enviados pelo dispositivo final a fim de processá-los e armazená-los em um banco de
dados, também definindo uma resposta para o dispositivo final. Essa reposta será
composta por comandos que podem acionar alguma funcionalidade extra no
dispositivo final. A apresentação será responsável por verificar as informações
armazenadas pelo integrador no banco de dados e exibir a localização do veículo em
um mapa para o usuário. Essa exibição ocorrerá de duas formas, são elas uma página
web e um aplicativo para smartphones rodando em um sistema operacional Android®.
Os componentes e a arquitetura do sistema poderão ser visualizados na Figura 6.
35

Figura 6 – Ilustração da arquitetura do sistema

Fonte: Elaborado pelo autor

3.3 DISPOSITIVO FINAL

Como já apresentado resumidamente no tópico 3.2, o dispositivo final tem como


finalidade enviar os dados GPS via uma rede LoRaWAN®, operando como classe C.
Os dados a serem enviados tem exatamente 12 bytes, que são compostos por 3
36

números de pontos flutuantes, os quais representam latitude, longitude e velocidade.


Além de enviar os dados adquiridos pelo GPS, o dispositivo tem a capacidade de ter
certas funcionalidades acionadas de acordo com a resposta recebida pela rede. São
elas: confirmação de recebimento, que mantém o funcionamento natural do dispositivo
final; fora de operação deixando-o com baixo consumo de energia por um tempo
determinado; e fora de rota, que será responsável por sinalizar que o veículo está fora
da rota programada, acionando o um alarme sonoro. Todas respostas terão sempre o
tamanho estipulado de 1 byte e suas definições serão apresentadas nos próximos
parágrafos.
A confirmação de recebimento somente irá sinalizar ao dispositivo que nada
diferente da operação normal deve ser feito. Ela será representada pelo valor 0x00.
Também poderão ocorrer situações em que nenhuma resposta seja recebida, nesse
caso também será considerado pelo dispositivo final que o mesmo deve manter sua
operação normal.
O modo fora de rota tem como objetivo cumprir o requisito de sinalização caso
do veículo esteja fora da rota programada. Sempre que o dispositivo final tiver como
retorno ao seu envio o valor 0x01, ele irá acionar o modo fora de rota. O modo fora de
rota apenas acionará um alarme sonoro que estará junto com o dispositivo. Após o
acionamento, o dispositivo final irá manter seu funcionamento normal enviando os
dados. O alarme sonoro somente será desligado quando o dispositivo final receber
uma confirmação de resposta, indicando que o veículo está em operação normal
dentro da rota.
O objetivo do modo fora de operação é atender ao requisito de consumo de
energia quando o veículo estiver desligado. O modo fora de operação fará com que o
microcontrolador entre em modo de baixo consumo de energia. Também desligará os
módulos a fim de consumir o mínimo possível de energia do veículo. Quando recebido
o modo fora de operação, junto será recebido a informação de intervalo de tempo. O
intervalo de tempo recebido será referente ao número de minutos na qual o dispositivo
irá manter o modo fora de operação, logo sempre que o dispositivo final receber algum
dado que não seja os já mencionados 0x00 e 0x01, será considerado que o valor é o
tempo em minutos que o dispositivo deve ter seu modo fora de operação ativado. Na
Figura 7 pode ser visualizado todo o fluxograma comportamental do dispositivo final.
37

Figura 7 - Fluxograma da função principal no dispositivo final

Fonte: Elaborado pelo autor

Para atender às funcionalidades do dispositivo final, serão necessários


hardwares específicos para o recebimento do sinal GPS e para a comunicação via
LoRaWAN®. Para o recebimento e processamento do sinal GPS, será utilizado um
módulo GPS que irá se comunicar com o microcontrolador via protocolo UART
(Universal Asynchrounous Receiver/Transmiter). A transmissão via LoRaWAN® será
feita utilizado um módulo LoRa® que se comunicará com o microcontrolador via
protocolo SPI (Serial Peripheral Interface). Ambos os módulos necessitam de uma
antena dedicada para realizar o envio e recebimento de sinais de RF (Rádio
Frequência).
38

Analisando todos os tópicos acima, é possível definir os componentes e


características para a escolha do microcontrolador, que será o responsável por
realizar todo o processamento do dispositivo final. Inicialmente deve ter uma interface
USB, para servir como fonte de alimentação. Deve conter interfaces UART e SPI,
assim como GPIO (General Purpose Input Output) para utilização em conjunto com
os módulos LoRa® e GPS. Os GPIO também serão responsáveis por acionar o alarme
sonoro e ligar e desligar os módulos GPS e LoRa®. O diagrama completo de todos os
itens que consiste o dispositivo final pode ser encontrado na Figura 8.

Figura 8 – Diagrama de blocos do sistema embarcado

Fonte: Elaborado pelo autor

Analisando os componentes mínimos necessários para o hardware, se optou


por utilizar o microcontrolador STM32F103C8, com processador Arm Cortex M3. O
microcontrolador é capaz de atender todos os requisitos necessários para o
dispositivo final. O microcontrolador tem interfaces SPI e UART, necessárias para o
interfaceamento com os módulos LoRa® e GPS. Tem a sua disposição 51 GPIO,
frequência de operação de até 72 MHz e 64 kB de memória flash. Além dos itens
essenciais para o projeto, o hardware ainda possui diversas outras funcionalidades
como ADC (Analogue-to-Digital Converter), DAC (Digital-to-Analogue-Converter),
timmers, etc (ST, 2018).
Como o sistema exige a necessidade de transmissão de longa distâncias em
perímetros urbanos, há necessidade de utilizar um módulo LoRa® com uma boa
potência de transmissão. O módulo LoRa® escolhido foi o E19-915M30S da empresa
39

EBYTE. O módulo tem como base o chip LoRa® SX1276 da SEMTECH. Dentre das
suas principais características podem ser citados: interface para antena IPX embutida,
potência de transmissão de 30 dBm, sensibilidade de recebimento de -148 dBm,
interface de comunicação SPI e frequência de operação 900 a 931 MHz (CHENGDU
EBYTE ELETRONIC TECHNOLOGY CO., LTDA., 2018). Como o módulo já conta
com a interface de antena IPX, será necessária ainda uma antena que possua essa
conexão, com dimensões específicas para a frequência de operação no Brasil de 915
MHz.
O módulo GPS escolhido foi o GY-GPS6MV2, com base no chip NEO-6 da
empresa U-BLOX. Muito utilizado, o módulo tem uma interface de comunicação
através do protocolo UART. Esse módulo conta com uma antena cerâmica dedicada,
especifica para o sinal do GPS. Sua tensão de alimentação é de 3 a 5 V (U-BLOX,
2011).
Para o protótipo a ser criado, a energia provida pelo ônibus será obtida através
de uma tomada veicular, disponível no veículo. A escolha da tomada se dá pela
vantagem de não ser necessário mexer na estrutura elétrica do veículo. Será acoplado
à tomada, um circuito elétrico que irá transformar os 24 V fornecidos pelo veículo em
5 V para ser a fonte de alimentação do microcontrolador. A saída de 5 V do circuito
será dada via interface USB, essa que é suportada pelo microcontrolador que
distribuirá a energia para os demais componentes.
Com foco nos componentes de software para desenvolvimento do dispositivo
final, será demonstrado as bibliotecas a serem utilizadas pelo dispositivo. As
bibliotecas facilitam a integração entre o programa objetivo com o hardware utilizado.
Além da biblioteca HAL (Hardware Abstration Library), obtida pelo software
STMCube32MX, que realiza a abstração dos componentes de hardware do
microcontrolador tornando seu uso mais simples (ST, 2017), serão utilizadas duas
bibliotecas externas para facilitar a integração entre os módulos e o microcontrolador.
A biblioteca para utilização em conjunto com o módulo LoRa® será a LMIC
(LoRaMAC in C) da IBM. A biblioteca LMIC é responsável por criar camada MAC
(Media Access Control) para redes LoRaWAN®. Utiliza linguagem de programação C,
tendo seu código aberto. Atualmente está na versão 1.0.5 (IBM CORPORATION,
2015).
Para o módulo GPS a biblioteca utilizada foi a TinyGPS. Biblioteca muito
utilizada, conta com mecanismos para manter o consumo de recursos baixo. TinyGPS
40

também fornece ao seus utilizadores, suporte a NMEA GPS que é uma padronização
de dados suportada por todos os dispositivos GPS (HART, 2013). Seu propósito é
padronizar a comunicação com dispositivos, a fim de que não seja necessário para o
desenvolvedor criar códigos customizados para cada receptor diferente
(GAKSTATTER, 2015).
Para atender ao correto funcionamento do modo fora de operação, foi
desenvolvido um hardware extra, o qual desliga momentaneamente o os módulos
LoRa® e GPS. O módulo LoRa®, por padrão, consome pouca energia quando não está
trocando dados, no entanto o GPS não conta com a mesma capacidade. Seria
necessário um circuito extra para desabilitar o GPS, então se optou por desligar os
dois, com o hardware sendo capaz de atender ambos módulos, contando que gastar
nada é melhor que gastar pouca energia.
Para a ativação e desativação dos módulos foi utilizado um relé em conjunto
com um transistor. O transistor foi necessário pois o consumo de corrente utilizado
para acionar o relé é maior que a capacidade fornecida pelo microcontrolador, que é
limitado em 20 mA por GPIO. Logo o GPIO com uma corrente muito baixa acionará a
base do transistor que por sua vez acionará o relé. O esquemático do circuito pode
ser visualizado na Figura 9.
41

Figura 9 – Esquemático do circuito de acionamento dos módulos LoRa® e GPS

Fonte: Elaborado pelo autor

O circuito que liga e desliga os módulos é ativado logo que o microcontrolador


é inicializado. Ele somente será desativado assim que o dispositivo receber a
instrução via LoRaWAN®. Como já visto, a instrução de desligamento do circuito
ocorre através do recebimento de um tempo específico, que é dado em minutos. Para
controlar o tempo específico, foi utilizado o timmer1 do microcontrolador para realizar
a contagem do tempo em que o circuito deve ficar desligado e então realizar uma
interrupção, assim instruindo o software a ligar novamente o sistema.
O timmer1 do microcontrolador é um timmer de precisão de 16 bits, com
contador de 16 bits, dando assim capacidade para o mesmo de contar até 59,65
segundos na frequência de operação do microcontrolador que é de 72 MHz. Com o
fato do timmer não ser capaz de alcançar o tempo máximo permitido pelo projeto em
que o circuito deve ficar desligado, foi implementado uma função que conta as
interrupções do timmer até que o tempo necessário seja alcançado. Sempre que a
42

instrução de modo de fora de operação é recebida pelo dispositivo, seu valor em


segundos é divido pelo tempo programado do timmer que no caso é de 10 segundos.
O valor da divisão é utilizado pela função para saber quantas interrupções o timmer
terá que fazer para que seja atingido o tempo desejado. Na Figura 10 é possível
visualizar o fluxograma da lógica implementada descrita no presente parágrafo.

Figura 10 – Fluxograma da lógica para ativação do circuito de baixo consumo.

Fonte: Elaborado pelo autor

Como pode ser visto na Figura 10, sempre que inicia a contagem do timmer é
acionado uma função específica do microcontrolador. Essa função tem como objetivo
diminuir todo o consumo de recursos por parte do microcontrolador, como GPIO,
interface UART, interface SPI etc. O microcontrolador somente sai desse modo de
baixa economia de energia quando há uma interrupção. Essa interrupção é
justamente o timmer programado para gera-la a cada dez segundos. Caso a contagem
das interrupções não tenha chegado ao valor definido para que o tempo em modo fora
de operação esteja completo, novamente será executado a função de baixo consumo
de energia do microcontrolador, repetindo até que o número de interrupções definido
seja alcançado.
Outro circuito extra desenvolvido foi o circuito para acionar a sinalização
sonora, que é responsável por ativar um buzzer de 5 V. O circuito foi necessário pois
o buzzer consome uma correte maior que a capacidade do GPIO do microcontrolador.
Para sua confecção foi utilizado um transistor, que a partir de uma corrente de base
acionado por um GPIO do microcontrolador irá acionar o buzzer. O transistor utilizado
43

foi o TIP142, é um transistor NPN Darlington com um ganho de 1000. Foi escolhido
justamente para que tivesse o menor consumo possível para o pino do
microcontrolador, assim como a facilidade de obtê-lo já que é disponibilizado pelo
laboratório da Unisinos. Na Figura 11 é possível visualizar o esquemático do circuito
responsável por acionar o buzzer.

Figura 11 – Esquemático do circuito de acionamento da sinalização sonora

Fonte: Elaborado pelo autor

Com o circuito extra dimensionado, foi realizada a montagem do circuito


completo. O circuito completo conta com o microcontrolador, módulo LoRa®, módulo
GPS, circuitos de acionamento dos módulos, circuito de acionamento do buzzer e as
antenas para o módulo GPS e módulo LoRa®. Para testar o correto funcionamento do
circuito e do dispositivo final, primeiramente foi realizada a montagem do mesmo em
uma placa de testes. Com os ajustes feitos e a verificação do correto funcionamento
foi desenvolvido uma PCI (Placa de Circuito Impressa), com o objetivo de diminuir os
espaços e melhorar a mobilidade do dispositivo final. O dispositivo final pode ser visto
na Figura 12.
44

Figura 12 – Dispositivo Final

Fonte: Elaborado pelo autor

3.4 BANCO DE DADOS

O banco de dados é a estrutura base de como os dados serão armazenados e


utilizados, assim como o mecanismo de troca de dados entre os processos integrador
e apresentação. O banco de dados foi modelado em um esquema nomeado como
“lorawan”, onde estão presentes 4 tabelas. Na Figura 13 é possível visualizar a
modelagem do banco de dados MySQL criada a partir do aplicativo MySQL
Workbench.
45

Figura 13 – Modelagem do banco de dados

Fonte: Elaborado pelo autor

A tabela “dispositivo” é a tabela onde é cadastrado cada dispositivo utilizado


pelo sistema. Ela armazena alguns dados importantes referente aos dispositivos,
como chave AES para a rede LoRaWAN® a nível de rede e de aplicação,
representadas pelas colunas “aesrede” e “aesaplicação”. Armazena a potência do chip
LoRa® utilizado pelo dispositivo na coluna “potência” e o endereço único do dispositivo
na rede pela coluna “enderecoderede”. A coluna “devEUI” representa o dispositivo a
um nível de aplicação no servidor LoRaWAN®, ou seja, esse será o identificador único
para identificar de qual dispositivos os dados estão sendo recebidos. A tabela
“dispositivo” está ligada com chave estrangeira à tabela “veiculo”.
A tabela “veiculo” representa cada veículo que está sendo rastreado pelo
sistema. Somente dados de veículos previamente cadastrados serão considerados
pelo processo integrador. A coluna “placa”, “modelo” e “marca” da tabela representam
as respectivas características do veículo. A coluna “ativo” representa a informação
referente a consideração daquele veículo pelo processo integrador. A coluna
“foradeoperacao” representa uma data na qual, até aquele momento, o veículo deverá
estar em modo fora de operação. As colunas “latitudeforaoperacao” e
“longitudeforaoperacao” representam as coordenadas de latitude e longitude na qual,
46

o veículo será exibido no mapa no processo de apresentação caso estejam fora de


operação. A coluna “foraderotaativado” é um indicador para ativar o modo fora de
operação caso o veículo esteja fora da rota pré-definida. Ela se torna muito oportuna
em uma situação onde o veículo precisa sair da rota programada e ainda assim
precisa ser monitorado. Nesse caso pode ser indicado a partir da coluna que a
sinalização sonora dentro do veículo não deverá ser acionada, não causando
incômodo ao motorista e aos passageiros.
A tabela “dadosrecebidos” tem como principal característica salvar todos os
dados recebidos pela aplicação integradora do dispositivo final. Nas colunas
“dadosrecebidosjson” e “respostaenviadajson” são salvos os dados recebidos e os
dados a serem enviados para os dispositivos, respectivamente, ambos em formato
JSON (JavaScript Object Notation) seguindo protocolo do servidor de rede. A coluna
“timestamprecebimento” representa a data e o horário em que os dados foram
recebidos com base na data e horário do computador em que o aplicativo da
integração está sendo executado. A coluna “veiculoid” representa de qual veículo
previamente cadastrado os dados foram originados. As colunas “latitude”, “longitude”
e “velocidade”, são as colunas que representam os dados enviados pelo dispositivo.
Para obtê-las, é necessário extraí-las a partir dos dados recebidos pelo servidor de
rede, que acompanha outras informações em conjunto. A coluna “localizacaoemrota”
sinaliza se os dados recebidos de localização do dispositivo estão dentro da rota. A
coluna “valorvalido” representa a sinalização de um cálculo que é realizado,
representado se o dispositivo final enviou dados de leitura GPS válidos.
A tabela “rotagpssmartphone” contém os dados de latitude e longitude referente
a rota que o ônibus circular realiza. Os dados foram recolhidos a partir de um
smartphone, com um aplicativo que a cada 1 segundo, capturava a localização e
salvava os dados de latitude e longitude no banco. Os dados da tabela são utilizados
para verificar se o veículo está dentro da rota programada ou não. Essa tabela também
foi utilizada para a realização do teste unitário do módulo GPS, validando se o módulo
funcionava corretamente e captava os dados esperados.

3.5 INTEGRADOR

A aplicação Integradora é o cérebro do sistema desenvolvido. De forma


resumida, seu funcionamento consiste em receber os dados do servidor de aplicação
47

enviados pelo dispositivo, processar os dados, verificando se são dados válidos, se


estão dentro da rota marcada, se o veículo está fora de operação e assim definindo a
resposta a ser enviada de volta para o dispositivo.
O servidor de rede e aplicação utilizado pela Unisinos, como parte da
infraestrutura da rede LoRaWAN® foi o loraserver. O servidor de aplicação do
loraserver possibilita ao usuário os 3 tipos de integração, são elas HTTP, MQTT e via
banco de dados. Foi optado pela utilização da integração MQTT, essa que traz
vantagens em relação as integrações HTTP e banco de dados. Quando comparado à
integração HTTP, pode ser citado a realização de um filtro dos dados a serem
processados. Na integração MQTT somente serão recebidos os dados nos tópicos
cuja aplicação está inscrita, diferentemente da integração HTTP, onde esse filtro
deverá ser realizado no código, pois receberá do servidor de aplicação todos os dados
sem um filtro prévio. Também pode ser considerado a maior facilidade no
desenvolvimento, já que o próprio loraserver indica sua utilização. Quando
comparado, a integração via banco de dados, traz a vantagem de realizar o
processamento dos dados, assim como a modelagem do banco conforme necessário
para a aplicação. A integração MQTT utiliza a formatação JSON, que é a abstração
de objetos e arrays em forma de texto, sendo independente de linguagem de
programação (INTRODUÇÃO AO JSON, [2019?]).
Por familiaridade, foi utilizado para desenvolver o processo integrador a
linguagem de programação C#. Ao ser iniciado, a aplicação Integradora realiza duas
conexões principais necessárias para o seu funcionamento, que são elas o servidor
de aplicação LoRaWAN® através do protocolo MQTT e o banco de dados. Para
realizar a conexão com o banco de dados, foi utilizado o Entity Framework. O Entity
Framework é um framework de ORM (Object Relational Mapper), que permite realizar
uma modelagem e mapeamento do banco de dados na forma de objetos (CADU,
[2011?]). O framework utilizado para conexão com o MQTT escolhido foi o
M2MqttDotnetCore. A sua escolha foi feita pelos critérios de ter as funcionalidades
necessárias e ter o maior número de utilizadores assim como maior comunidade na
Internet.
Após as devidas conexões terem sido realizadas com sucesso, o aplicativo se
inscreve no tópico MQTT do servidor de aplicação. A partir de uma função que é
engatilhada sempre que o tópico do MQTT tiver alguma publicação, a aplicação
48

integradora irá processar os dados recebidos. Os processamentos que são realizados


pela aplicação são:
• Verificar se veículo está na rota;
• Verificar se os dados recebidos pelo GPS são dados válidos;
• Verificar se o dispositivo foi previamente cadastrado no sistema.
Toda lógica e funcionalidade do servidor de aplicação pode ser visualizado na
Figura 14.

Figura 14 – Fluxograma do processo Integrador

Fonte: Elaborado pelo autor


49

Como pode ser observado na Figura 14, o processo será um aplicativo que fica
rodando como um serviço. Ao iniciar, ele realiza a conexão com o banco de dados e
com o servidor MQTT, no qual irá receber os dados via LoRaWAN®. Com a conexão
bem-sucedida, uma thread vinculada ao evento de recebimento de publicações via
MQTT será iniciada. Sempre que uma publicação via MQTT for recebida, será
realizado o processamento apresentado no fluxograma na Figura 14 como evento de
recebimento. A sua explicação detalhada será apresentada nos parágrafos que
seguem.
Ao receber um dado, a primeira verificação que é realizada busca validar se o
dispositivo do qual os dados foram recebidos está cadastrado no banco de dados, se
o dispositivo está vinculado a um veículo e se o veículo está definido como ativo no
banco de dados. Caso todas as exigências sejam atendidas, os dados serão
processados, caso contrário os dados serão descartados e a operação vinculada
àquela mensagem será encerrada.
O processamento inicial consiste em verificar se os dados recebidos são dados
válidos. Essa validação dos dados é necessária para que os processos de
apresentação mostrem somente dados consistentes para o usuário, ignorando os que
tiveram algum tipo de erro na leitura. Também é necessária para que não seja ativado
o modo de fora de rota, assim causando distúrbio em função do sinal sonoro.
Conforme será visualizado nos testes aplicados, nem sempre os dados GPS e de
velocidade são obtidos com precisão. A validação dos dados ocorre de duas formas
distintas. Uma utiliza o histórico do veículo, para verificar se a distância percorrida está
dentro de uma situação fisicamente possível enquanto a outra verifica se os dados de
localização estão corretos com base na distância máxima que o dispositivo pode se
ficar do gateway. Nos próximos parágrafos essas duas validações serão apresentadas
com mais detalhes.
O primeiro teste a ser aplicado é o da distância máxima entre o dispositivo e o
gateway. Caso seja identificado que a distância de localização recebida pelo
dispositivo final seja maior que a estipulada, diretamente será definido como um dado
inválido, pois não seria possível um dado ser recebido de uma distância tão grande.
A distância em questão é de 3000 metros, valor estipulado a partir dos testes de
distância realizados, onde foi verificado que em nenhum ponto poderia ter um alcance
maior que esse. Caso os dados sejam validados por esse teste, terão que passar pelo
outro teste para serem considerados válidos.
50

A validação através do histórico consiste em verificar, com base na distância e


no intervalo de tempo dos dados recebidos, se o veículo teve a velocidade média de
acordo com a uma situação possível, com base nos limites de velocidade e de
condições da estrada. Com base na sinalização de trânsito por placas da rota, em
nenhum ponto a velocidade máxima permitida é maior que 60 km/h. Considerando
uma margem de segurança, foi utilizado 80 km/h para a realização desse
processamento, contando que 80 km/h é uma velocidade atingível e nem sempre as
leis de trânsito são respeitadas. Será carregado no banco de dados os últimos 5 dados
salvos do veículo em questão, por ordem decrescente de recebimento. Caso pelo
menos um dos cinco dados salvos for um dado válido, será feito o cálculo da
velocidade média realizada pelo veículo com base na distância percorrida e no
intervalo de tempo entre os dois. Se a velocidade média encontrada a partir do cálculo
for maior que 80 km/h, será considerado que a localização é inválida. O motivo pelo
qual são selecionados valores válidos somente com base nos últimos cinco dados, se
dá pelo fato de que se entre os últimos cinco dados não houver nenhum dado cuja
localização foi coletada como válida, será reiniciado o controle, pensando que podem
haver situações que dados inválidos sejam considerados como válidos, assim
causando erros em cascata.
Com a validação dos dados, será feita a definição da resposta para o dispositivo
final. Como já definido e apresentado anteriormente, os valores de resposta vão de
0x00 a 0xFF, ou seja, a resposta sempre será de um byte. São três os tipos de
respostas possíveis, onde cada um dos tipos será responsável por sinalizar o que o
dispositivo final deve fazer. Para definir a resposta, o primeiro processamento a ser
feito é verificar se o veículo deve entrar em modo fora de operação. Será consultado
o banco para verificar a coluna “veiculoforaoperacao”, validando se o valor da mesma
contém uma data maior do que a data atual com uma diferença maior que um minuto.
Caso isso se confirme, a resposta será definida como o número de minutos entre a
diferença da data no banco com o horário atual. Como somente pode ser enviado um
byte, caso a diferença entre as datas em minutos seja maior que o limite que pode ser
transmitido, o valor máximo de 0xFF minutos será enviado.
Caso o veículo não esteja fora de operação, será validado se ele está dentro
da rota indicada. Três confirmações devem ocorrer para que a resposta seja definida
como veículo fora de rota, garantindo que não há erros na validação desse modo para
não haver incomodo ao motorista e passageiros em caso de um acionamento sonoro
51

equivocado. Primeiro será verificado se a coluna “foraderotaativado” no banco de


dados para o veículo em questão está com o valor igual a 1. A segunda validação será
verificar se os dados recebidos de localização foram definidos como dados válidos,
caso contrário se entende que a leitura de localização foi equivocada e dessa forma
não deve ser acionado o alarme sonoro. O terceiro teste será verificar de fato se a
localização recebida está dentro da rota indicada. O funcionamento dessa validação
em forma de fluxograma pode ser visto na Figura 15, tendo sua explicação mais
detalhada nos próximos parágrafos.

Figura 15 – Verificação de veículo dentro da rota

Fonte: Elaborado pelo autor


52

Conforme o fluxograma apresentado na Figura 15, o primeiro passo para


verificar se o veículo está dentro da rota é carregar dados de localização da rota.
Como já apresentado, a tabela “dadosrotagps” contém a localização de todos os
pontos da rota do ônibus. Por definição, será considerado uma margem de distância
de 250 metros, dessa forma somente em casos onde o veículo seja identificado com
uma distância maior que a de 250 metros longe da rota definida, o alarme deverá ser
acionado. Com as informações carregadas do banco de dados, é feito um loop,
percorrendo cada um dos pontos de latitude e longitude da rota. Para cada ponto da
rota será verificado se a distância entre o dado recebido comparado com o ponto
analisado é menor que a distância de 250 metros. Caso um dos pontos atenda essa
condição, será definido que o veículo está em rota. Somente será definido que o
veículo não está em rota caso a distância de 250 metros seja maior para todos os
pontos analisados.
Feita a verificação se o veículo está fora de rota, pode enfim ser definida a
resposta. Caso se confirme que o veículo está fora de rota, a resposta será definida
como 0x01, indicando que o dispositivo final deve acionar o alarme, caso contrário a
resposta será 0x00, indicando que o dispositivo final deve manter sua operação
normalmente e deve desligar o alarme caso o mesmo esteja ligado. Com as respostas
definidas e enviadas via MQTT para o servidor de aplicação, o processo integrador irá
salvar os dados recebidos no banco de dados e encerrar sua execução, esperando
uma nova publicação no tópico.

3.6 APRESENTAÇÃO

Tanto o aplicativo como a página web tem seu funcionamento de forma similar,
ambos têm um mapa que ocupa toda a área disponível da tela. Poderá ser aplicado
no mapa as funcionalidades de zoom e movimentações, porém sempre será
inicializado como ponto central do mapa o centro administrativo da Unisinos, com o
zoom aplicado de forma que seja possível visualizar toda a rota realizada pelo circular.
Sempre que iniciadas, ambas apresentações carregam as informações de todos os
veículos ativos do banco de dados, tendo cada veículo representado por um pino no
mapa. Após carregados, cada pino terá sua localização atualizada no mapa
periodicamente. Há três tipos diferentes de cores para cada pino presente no mapa,
onde cada uma representa um status diferente.
53

• Vermelho: representa que o veículo não teve seus dados de localização


enviados recentemente, ou seja, se o último dado recebido do veículo
válido for a mais de 15 segundos;
• Azul: representa que a última localização do veículo é recente, recebidas
a menos que 15 segundos;
• Amarelo: representa o veículo quando fora de operação. Nesse caso o
pino de representação do veículo será apresentado no mapa utilizando
as coordenadas salvas nas colunas “latitudeforaoperacao” e
“longitudeforaoperacao”.
Na apresentação para o usuário ainda há uma funcionalidade extra na página
web. Nela poderá ser definido que o veículo está fora de operação. Isso pode ser feito
através de um formulário onde é disponibilizado para o usuário a seleção dos veículos
previamente carregados no início e um campo de seleção de data o qual indicará até
que momento o veículo deverá ficar fora de operação. Na Figura 16 é possível
visualizar o formulário descrito no presente parágrafo.

Figura 16 – Formulário para ativação do modo fora de operação

Fonte: Elaborado pelo autor

O desenvolvimento do servidor do processo de apresentação foi feito utilizando


linguagem de programação PHP (Hypertext Processos), rodando em um servidor
apache. A comunicação entre o back-end e o front-end do processo de apresentação
da página web e do aplicativo Android® acontece utilizando o protocolo HTTP. O
servidor conta com 4 funções que servem como interface de troca de dados para o
aplicativo Android® e a página web. São elas:
54

• Página Inicial – Utilizada somente pela página web, consistem em


carregar a página inicial em formato HTML, que contém o mapa e suas
funções;
• Carrega veículos ativos – Tem como função carregar todos os veículos
que estão ativos. Retorna os dados em formato JSON;
• Carrega dados do veículo – Com base em um parâmetro de identificação
única do veículo, serão carregados os últimos dados de localização e
velocidade válidos recebidos pelo veículo. Os dados são retornados em
formato JSON;
• Definir veículo fora de rota – Utilizado somente pela página web, com
base em dois parâmetros enviados, irá fazer alteração do veículo no
banco de dados, sinalizando que ele deverá estar fora de operação até
uma data determinada.
A página web como já descrito, foi desenvolvido utilizando HTML e javascript.
Como dependência a página web utiliza o framework bootstrap, com a finalidade de
deixar a página com um design responsivo e com uma aparência mais agradável para
o usuário. Para a inclusão de um mapa, foi utilizado a biblioteca javascript Leaflet para
interação com mapas em conjunto com os mapas de OpenStreetMap, ambas são
open-source e gratuitas.
O aplicativo Android® foi desenvolvido utilizando o framework Xamarin, no IDE
do Visual Studio. O framework Xamarin foi escolhido pois permite ao seus utilizadores
o desenvolvimento de aplicativos para Android, IOS e Windows Phone, fazendo assim
com que possíveis evoluções, criando aplicativos para outras plataformas, sejam
feitas com maior facilidade. Outro critério para escolha foi a familiaridade com a
linguagem utilizada pelo Xamarin, que é a linguagem de programação C#.
Com a apresentação de todo desenvolvimento do sistema, mostrando seus
componentes de forma individual, foram desenvolvidos e aplicados diversos teste a
fim de validar seu funcionamento. Além de validar o funcionamento, os testes também
validaram os requisitos apresentados nesse capítulo. Nos próximos tópicos serão
apresentados os testes que foram feitos, mostrando como foram aplicados e a forma
como validaram o funcionamento e os requisitos na qual eles têm vínculos.
55

3.7 TESTES DO SISTEMA

Nesse tópico serão apresentados todos os testes que foram empregados. Os


primeiros testes foram feitos de forma individual, validando um ou mais requisitos, sem
estarem relacionados com outros testes. Por último foi feito um teste geral de
funcionamento, onde se verificou o funcionamento de ponta a ponta do sistema. Os
testes serão apresentados individualmente, na forma de subtópicos.

3.7.1 Teste do GPS

O teste da aquisição de dados GPS tem como objetivo verificar se o modulo


GPS é capaz de capturar os dados corretamente em toda a rota do circular. O teste
do módulo GPS foi feito a partir da comparação dos dados adquiridos de latitude e
longitude pelo módulo utilizado no protótipo, com os dados adquiridos por um
smartphone. Inicialmente foi desenvolvido um aplicativo para smartphone Android®
que coleta os dados GPS de localização e velocidade a cada 1s. Com o aplicativo
desenvolvido foi percorrido a rota que o ônibus circular realiza, a fim de coletar os
dados obtidos pelo GPS do smartphone. Foi desenvolvido igualmente um firmware
para o microcontrolador STM32F113, que captura os dados GPS seguindo os
mesmos critérios do smartphone. Com o software desenvolvido, novamente foi
realizada a rota do circular para que os dados fossem capturados pelo módulo a ser
utilizado no dispositivo final. Com os dados adquiridos foi possível analisar
visualmente os dados obtido pelo módulo e pelo smartphone.

3.7.2 Teste de energia

O teste de energia foi realizado analisando duas situações. Primeiro se o


dispositivo final seria capaz de entrar em modo fora de operação por um tempo
determinado e, após voltar para sua operação normal. Segundo realizando uma
análise do valor da corrente elétrica consumida pelo dispositivo final, quando em modo
fora de operação, afim de avaliar se o dispositivo final poderia causar algum prejuízo
para a bateria do veículo, quando estiver desligado.
Para aplicar o teste foi definido na página web desenvolvida, um tempo de
operação no modo fora de operação de 10 minutos. O dispositivo foi monitorado para
56

identificar o momento exato que o dispositivo recebeu a instrução, para, assim,


cronometrar e verificar se o tempo em modo fora de operação acompanha o previsto.
Também verificar se quando o dispositivo sair do modo de fora de operação, o
dispositivo final continuou a transmitir os dados de localização.

3.7.3 Teste de dispositivos simultâneos

O teste de dispositivos simultâneo foi utilizado para verificar se o sistema como


um todo funciona com diversos veículos sendo monitorados simultaneamente. Como
somente foi desenvolvido um protótipo, esse teste ocorreu a partir de simulação de
dispositivos finais. Um programa desenvolvido em nodejs, simula o envio de dados de
um número determinável de veículos. Os dados de GPS enviados pelo simulador de
dispositivo final são obtidos da mesma tabela do banco de dados utilizada para
verificar se os dispositivos estão em rota. Para realizar o teste, foram simulados 5
dispositivos. Cada dispositivos enviará os mesmos dados da rota, porém iniciando em
pontos diferentes, de forma a simular uma situação real de operação.

3.7.4 Teste de intervalo de envio

O teste de intervalo de envio tem como objetivo validar o funcionamento do


dispositivo por longos períodos sem interrupção, garantindo também que em nenhum
momento o intervalo de envio dos dados seja maior que 15 segundos estipulados pelo
requisito. Para realizar esse teste foi iniciado o dispositivo final, deixando-o
funcionando por uma hora ininterrupta. Com as informações salvas no banco de
dados, foi feita as validações entre o maior e o menor intervalo entre envios.

3.7.5 Teste de validação dos dados

O teste de validação de dados serviu para verificar o funcionamento que o


processo Integrador faz para confirmar se os dados recebidos pelo dispositivo final
são válidos. Esse teste foi feito utilizando o mesmo simulador utilizado no teste de
dispositivos simultâneos. Foram simulados dados de um dispositivo final com
velocidades médias maiores que 80 km/h e com distâncias maiores que 3 km do
gateway. Os dados foram salvos no banco como se estivessem em operação normal
57

para então serem avaliados, verificando se a validação dos dados feita pelo processo
Integrador está correta.

3.7.6 Teste de cobertura da rota

O teste de alcance tem como objetivo validar a cobertura de sinal da rede


LoRaWAN® na rota que o circular realiza. Foi percorrido toda a rota do circular
utilizando o dispositivo final, a fim de setorizar no mapa áreas da rota que se obteve
total recebimento dos dados, algum recebimento de dados e nenhum recebimento de
dados, tanto para uplink como para downlink. Também foi feita a avaliação do
recebimento de dados pelo dispositivo, essa que será feita com menos precisão já
que não há um registro de logs dos dados recebidos pelo dispositivo final, somente
um LED (Light Emitting Diode) que piscava sinalizando que dados foram recebidos.

3.7.7 Teste de fora de rota

O teste de fora de rota tem como objetivo validar o funcionamento do


processamento que busca verificar quando o veículo está fora de rota. Ele foi feito
através do dispositivo final, que se distanciando da rota do ônibus circular em pouco
mais de 250 metros para validar se o mecanismo de sinalização implementado foi
acionado com sucesso, assim como ao voltar para a rota, o dispositivo final tivesse o
mecanismo desativado, assim voltando para sua operação normal.

3.7.8 Teste de funcionamento

O teste de funcionamento é o teste final de produção e verificação do


funcionamento do sistema de forma geral de ponta a ponta. O dispositivo foi colocado
no interior de um veículo, que percorreu a rota do circular da Unisinos, monitorando o
seu funcionamento a partir dos processos de apresentação. Esse teste foi feito com
finalidade em agrupar a maioria dos testes realizados de forma individual, validando o
funcionamento do sistema como um todo.
58

4 ANÁLIS E DE RES ULTADOS

Nesse capítulo serão apresentados os resultados obtidos dos testes aplicados


descritos no tópico 3.7. Da mesma forma que foram apresentados em suas
descrições, esse capítulo apresentará os resultados dos testes divididos em tópicos,
encerrando o capítulo com parágrafos de análise geral dos resultados obtidos dos
testes e do funcionamento do sistema. Os testes serão apresentados na mesma
ordem em que foram apresentados no tópico 3.7.

4.1 RESULTADOS DO TESTE DE GPS

Como já descrito, o teste GPS foi feito de forma visual com base nos pontos
adquiridos por diferentes dispositivos. Na Figura 17 é possível visualizar os dados
coletados por ambos os dispositivos apresentados no mapa.

Figura 17 – Dados GPS plotados no mapa

Fonte: Elaborado pelo autor

Na Figura 17 é possível ver duas cores distintas de ícones, os pontos vermelhos


representam os dados adquiridos pelo smartphone, enquanto os pontos azuis
59

representam os dados obtidos pelo módulo GPS. A aquisição dos dados se mostrou
bastante parecida, os dados GPS adquiridos pelo smartphone foram muito concretos
e regulares, não apresentando desvios e distorções, mantendo-se sempre na rota
especificada. O módulo GPS também apresentou um bom resultado, tendo seus
dados muito parecidos com os do smartphone. A única distorção apresentada na
comparação foi uma pequena repetição do local de pontos, onde o módulo GPS que,
por perda de sinal, acabou repetindo alguns pontos no mesmo local. Esse evento pode
ser visto na parte mais superior da imagem, no lado direito.

4.2 RESULTADO DO TESTE DE ENERGIA

O resultado do teste mostrou que o dispositivo foi capaz de entrar e sair do


modo fora de operação, se mantendo no modo um tempo muito aproximado do
programado, com variação de apenas alguns segundos. Após sair do modo fora de
operação, também apresentou voltar para suas funcionalidades normalmente,
transmitindo os dados de localização e velocidade periodicamente.
A análise de consumo de energia também se mostrou dentro do esperado. Foi
inserido na alimentação do dispositivo um medidor de corrente elétrica a fim de
monitorar a quantidade de corrente que era consumida no momento em que o
dispositivo final estava no modo fora de operação. Na Figura 18 é possível visualizar
os valores de medição no momento em que o dispositivo final estava em modo fora
de operação.

Figura 18 – Consumo de energia do dispositivo fora de operação

Fonte: Elaborado pelo autor

Conforme a Figura 18, o dispositivo final tem um consumo de 0,01 A, dessa


forma o dispositivo funcionaria por mais de 2000 horas até descarregar
completamente a bateria do veículo, que é equivalente a mais de 83 dias. No entanto
60

esse valor não está exato, considerando que existe um conversor de 24 V para 5 V,
que, se levado em consideração, aumentaria mais o tempo de duração. Porém como
não havia equipamento para a medição do consumo da tomada veicular, se utilizou o
consumo na alimentação 5 V do dispositivo. Ainda é possível observar na Figura 19
como o veículo é apresentado no mapa quando em modo fora de operação, tendo a
cor de seu pino diferente para identificar ao usuário o status atual do veículo.

Figura 19 – Aplicativo Android® demonstrando veículo fora de operação

Fonte: Elaborado pelo autor

4.3 RESULTADO DO TESTE DE DISPOSITIVOS SIMULTÂNEOS

Com o teste de dispositivos simultâneos, feitos a partir de simulações, foi


possível analisar que o sistema é capaz de funcionar com mais de um dispositivo
enviando dados ao mesmo tempo. Para o teste com 5 dispositivos enviando dados
diferentes da rota que o ônibus circular realiza, todos foram apresentados nos
processos de aplicação página web e aplicativo Android®, não causando lentidão ou
problemas na exibição. O integrador também foi capaz de processar todos os dados.
Nas Figura 20 eFigura 21 é possível visualizar a página web e o aplicativo Android®
apresentando cinco veículos simulados no mapa.
61

Figura 20 – Teste dispositivos simultâneos na página web

Fonte: Elaborado pelo autor

Figura 21 - Teste dispositivos simultâneos na aplicativo Android

Fonte: Elaborado pelo autor

O teste apesar de válido, não é completo. Idealmente deveria se avaliar o


sistema de ponta a ponta nesse teste, já que diversas situações poderiam acontecer
na comunicação entre o dispositivo final e o gateway LoRaWAN®. Porém, como há
somente um protótipo, o teste completo não pôde ser realizado nesse trabalho.
62

4.4 RESULTADO DO TESTE DE INTERVALO DE ENVIO

O resultado de teste de intervalo de envio, assim como funcionamento


ininterrupto, teve o resultado esperado. Durante uma hora de envio consecutivo, o
dispositivo se manteve enviando dados sem interrupção para o gateway durante todo
o tempo, sem que entre nenhum intervalo de envio o tempo fosse maior que os 15
segundos estipulados pelos requisitos. Conforme pode ser visto na Figura 22, os
dados, como o funcionamento previsto define, foram salvos no banco, assim podendo
ser observado os maiores e menores intervalos entre os seguidos envios. Foi feito um
script SQL (Structured Query Language) que comparava os dois valores consecutivos
de envio, verificando a diferença entre os tempos em segundos dos dados. Como
pode ser visto, a diferença entre o intervalo de envio ficou entre os valores de 9, 10 e
11 segundos.

Figura 22 – Intervalo de máximos e mínimos entre envios

Fonte: Elaborado pelo autor

4.5 RESULTADO DO TESTE DE VALIDAÇÃO DOS DADOS

A partir do teste de validação dos dados, o processamento realizado para


validá-los se mostrou eficaz. No primeiro teste, que foi feito simulando dois pontos
distantes enviados imediatamente um após o outro, simulando um trajeto percorrido
com uma velocidade maior que 80 km/h, o dado foi definido como não válido pelos
mecanismos. As coordenadas utilizadas nesse teste, assim como os pontos que as
mesmas representam no mapa, podem ser vistas na Figura 23. Também é possível
ver na mesma Figura 23 os dados sendo recebidos no integrador, apresentando a não
validação dos mesmos.
63

Figura 23 – Teste da validação dos dados um

Fonte: Elaborado pelo autor

No segundo teste, foram feitas duas análises. A primeira análise verificou um


valor muito próximo do limite, a fim de verificar o correto funcionamento do
processamento que calcula a distância pelas coordenadas. O teste teve o resultado
esperado, definindo o dado recebido como válido, como pode ser visto na Figura 24,
na primeira linha do Integrador. A segunda análise verificou o processamento de um
ponto com distância maior que o limite definido. Foi utilizado um ponto do mapa com
distância de 3005 metros distante do gateway, dessa forma extrapolando o limite
permitido de 3000 metros. O dado foi definido como inválido pelo Integrador, conforme
pode ser visto na última linha da Figura 24. Assim pode-se concluir que o mecanismo
de validação foi aprovado por completo pelos testes aplicados.

Figura 24 – Teste da validação dos dados dois

Fonte: Elaborado pelo autor


64

4.6 RESULTADO DO TESTE DE COBERTURA DA ROTA

Para apresentar o resultado do teste de alcance, foi feito um mapa que, a partir
de áreas demarcadas com diferentes cores, classifica o desempenho da comunicação
através da rede LoRaWAN®. Foram definidas 3 classificações onde: as áreas verdes
representam os locais onde o sinal é recebido pela sua totalidade, com um número de
perda de dados desprezível ou inexistente; as áreas amarelas representam os locais
que haviam perdas de dados consideráveis; e as áreas em vermelho, que são locais
da rota do circular da Unisinos, na qual houve perda total da comunicação. Na Figura
25 é possível visualizar o mapa com suas respectivas áreas testadas e demarcadas.

Figura 25 – Área de alcance rede LoRaWAN® com base na rota

Fonte: Elaborado pelo autor

Como é possível ver, a rede LoRaWAN® conseguiu realizar a cobertura de todo


o campus da universidade. Em contrapartida se mostrou limitada em outros locais da
rota do ônibus circular, com alguns pontos havendo uma perda considerável de sinal
e outros pontos que nem mesmo um dado foi recebido com sucesso pela rede.
Quando analisado o downlink, o resultado foi pior. A partir de uma análise visual, no
LED que pisca toda vez que o dispositivo final recebe um dado de resposta, foi
65

constatado que houve uma grande quantidade de envios com sucesso, que não
receberam nenhuma resposta.
Dessa forma foi avaliado que a rede LoRaWAN® não alcançou as distâncias
esperadas indicadas na revisão bibliográfica, sendo assim foram verificados alguns
aspectos que justifiquem esse acontecimento. Analisando o relevo ao redor da
universidade, é possível observar que a Unisinos está localizada em uma baixada,
cercada por morros, apesar da foto não deixar isso claro. Nos extremos da área verde,
olhando em uma linha horizontal, há os picos dos morros que cercam a Unisinos. É
claramente perceptível que conforme se passava os picos dos morros e entrava em
novas baixadas, o sinal decaia consideravelmente. Outro aspecto que pode ter
interferido no baixo alcance da rede foi a antena de telefonia móvel próxima ao local
onde o gateway está localizado.

4.7 RESULTADO DO TESTE DE FORA DE ROTA

Os resultados do teste de fora de rota foram adequados aos esperados, onde


seu funcionamento idealizado foi pleno, porém, como já previsto, dependia da área de
cobertura da rede LoRaWAN®. Ao sair da rota em um local onde a havia cobertura do
sinal da rede, foi possível ver o buzzer sendo acionado e gerando o barulho esperado,
assim como quando retornado para próximo da rota, o buzzer foi desligado.
Consequente da não cobertura de toda a rota por parte da rede LoRaWAN®, houve
poucos lugares que pode ser testado e comprovado seu funcionamento para esse
modo de operação. Na Figura 26 pode ser observado o integrador processando
corretamente três dados recebidos pelo dispositivo, assim como os pontos do mapa
referente a esses locais, onde o primeiro e último representam dados dentro da rota
segundo critérios já definidos e o segundo representa um dado fora de rota.
66

Figura 26 – Dados do teste de fora de rota

Fonte: Elaborado pelo autor

4.8 RESULTADO DO TESTE DE FUNCIONAMENTO

Os resultados apresentados pelo teste geral de funcionamento se mostraram


compatíveis com o resultado esperados, assim como a integração de todos os
processos funcionando juntos. O dispositivo final conseguiu enviar a cada exatos dez
segundos a sua localização, de forma que fosse visível no mapa em um smartphone
Android® conectado na Internet. Na Figura 27 é possível ver o dispositivo final em
pleno funcionamento no interior de um veículo, sendo filmado pelo mesmo celular que
o monitorava através do aplicativo.
67

Figura 27 – Funcionamento do sistema

Fonte: Elaborado pelo autor

Na Figura 28 é possível ver todos os pontos recebidos corretamente pelo


dispositivo final, mostrando o local exato do veículo quando os dados foram recebidos.
Essa mesma Figura pode ser comparada com os dados apresentados no teste de
cobertura da rota na Figura 25, confirmando as áreas onde os dados são recebidos
na sua totalidade, onde apenas alguns dados são recebidos e onde nenhum dado é
recebido.
68

Figura 28 – Localização dos envios no teste de operação final

Fonte: Elaborado pelo autor

Como resumo de todos os testes aplicados, o único que apresentou limitações


para o correto funcionamento do sistema foi o alcance da rede, situação decorrente
do relevo no qual a rota do circular se encontra. No próximo capítulo será apresentada
a conclusão do trabalho. Serão retomados os objetivos do sistema proposto de forma
resumida, realizando uma análise com base nos resultados obtidos. Nessa análise
será feita a verificação se o sistema atendeu a necessidade e a proposta, os
problemas, limitações e possíveis alterações e melhorias. Também serão analisados
possíveis trabalhos futuros que poderão utilizar como base o presente trabalho.
69

5 CONCLUS ÃO

Nesse trabalho foi desenvolvido um sistema cujo objetivo principal era melhorar
a experiência do usuário do ônibus circular da Unisinos que, de forma prática, pudesse
acompanhar em tempo real a localização do veículo. Como objetivo secundário estaria
o aumento da segurança do veículo, que em caso de possíveis roubos o veículo
poderia ser rastreado para uma rápida recuperação do mesmo. Além disso, ainda com
relação à segurança, tornaria possível ser verificado se os motoristas estão seguindo
as normas de trânsito. Dentre os principais diferenciais do trabalho, estava a utilização
de uma tecnologia que não gerasse custo periódico, diferente dos vários sistemas de
rastreamento já existentes que utilizam planos de telefonia móvel.
Olhando de forma isolada para o sistema desenvolvido, é possível definir que
teve o desempenho esperado, passando em todos os testes aplicados com exceção
de um, que está diretamente relacionado a tecnologia escolhida para o envio de sinal.
A tecnologia LoRa®, conforme visto no referencial teórico, é capaz de conseguir
comunicação em distancias de até 5 km em áreas urbanas em situações ideais. No
local de utilização da rede para o presente trabalho houve uma considerável
diminuição comparado ao valor máximo que, conforme os testes de cobertura
mostraram, ocorreu principalmente em função do relevo em que o campus da Unisinos
e, consequentemente, a rota do circular estão localizados. Ainda há como
especulação outros fatores, como por exemplo a antena de telefonia móvel muito
próximas ao local. O completo e ideal funcionamento do sistema desenvolvido
ocorrerá certamente com a simples extensão da rede LoRaWAN®, com a adição de
mais um gateway próximo da estação da Trensurb.
Em outro aspecto foi identificado, após os testes, que poderia haver uma
melhoria: a frequência de envio dos dados de localização. Apesar de ter tido uma boa
noção de localização com o intervalo de envio em 10 segundos, diminuindo o tempo
entre envios poderia se obter uma melhor sensação de tempo real por parte do
usuário. Porém não foi possível realizar essa melhoria em função das especificações
LoRaWAN®, que em sua estrutura de envio e resposta não permitem o envio de dados
com intervalos muito menores, sem considerar que poderia congestionar a rede
LoRaWAN®, fazendo com que em caso de mais dispositivos operando
simultaneamente, o sistema não funcionasse. A fim de melhorar ainda mais a
apresentação para o usuário, poderia ser desenvolvido um mecanismo que fizesse
70

com base no histórico, análises estatísticas ou Inteligência Artificial, prever a


localização do veículo entre os intervalos de 10 segundos, assim como a previsão de
chegada para a parada em que o usuário se encontra.
Para finalizar, ainda há algumas melhorias e complementos que poderiam ser
aplicados no presente trabalho, fora as já descritas. Uma delas seria a implementação
de um sistema de corta-corrente no veículo que pudesse ser acionado remotamente.
Poderia ser substituído a sinalização sonora presente hoje no dispositivo final por um
corta-corrente, de forma que em vez de sinalizar o desvio da rota, o veículo se
desligasse, de forma automática, podendo impedir um furto ou roubo. Ainda seria
possível a aquisição e transferência de mais informações a partir da mesma rede,
como por exemplo um contador de passageiros, que informaria aos usuários a
quantidade de passageiros dentro do veículo, fazendo com que o usuário possa evitar
viagens com uma lotação muito grande.
Por último é valido fazer uma análise sobre a biblioteca utilizada para enviar
dados via LoRaWAN®. A biblioteca LMIC se mostrou bastante limitada quando
operando em classe A. Muitos dados de downlink não foram recebidos utilizando a
biblioteca LMIC. Para que fosse possível receber todos os dados enviados pelo
gateway, teve que ser modificada a biblioteca LMIC, de forma que a mesma
começasse a operar em estilo classe C, porém já não mais seguindo todas as
especificações de uma rede LoRaWAN®.
71

REFERÊNCIAS

BAHARUDIN, A. M. bin; YAN, W.. Long-Range Wireless Sensor Networks for Geo-
location Tracking: Design and Evaluation. International Electronics Symposium
(IES). Yokohama, Japan. 2016.

BARDYN, J.P.et al, IoT : The Era of LPWAN is starting now. ESSCIRC Conference.
Suíça. n 42, 2016. DOI: 10.1109/ESSCIRC.2016.7598235 Disponível em:
https://ieeexplore.ieee.org/document/7598235. Acesso em: 22 ago. 2018

BOUTEN, W. et al. . A flexible GPS tracking system for studying bird behaviour at
multiple scales. Electronic supplementary material. [S.l.], 2012. DOI:
10.1007/s10336-012-0908-1. Disponível em:
https://link.springer.com/article/10.1007/s10336-012-0908-1. Acesso em: 8 set. 2018

CADU. ORM: Object Relational Mapper. Retrieved. In: DEVMEDIA [S.l.], [2011?].
Disponível em: https://www.devmedia.com.br/orm-object-relational-mapper/19056.
Acesso em: 30 abr. 2019

CENTENARO, M. et al.. Long-range communications in unlicensed bands: the rising


stars in the iot and smart city scenarios. IEEE Wireless Communications. Itália, 2015.
Disponível em: https://arxiv.org/abs/1510.00620. Acesso em: 22 ago. 2018

CHENGDU EBYTE ELETRONIC TECHNOLOGY CO.,LTDA. E19-915M30S User


Manual. 1.20 ed. China, 2018. Disponível em:
http://www.ebyte.com/en/downpdf.aspx?id=223. Acesso em: 30 out. 2018

DIAS, A Funcionamento e Detalhes do Sistema Elétrico Automotivo. In: Carros Infoco.


[S.l.], 2015. Disponível em:
http://www.carrosinfoco.com.br/carros/2015/08/funcionamento-e-detalhes-do-
sistema-eletrico-automotivo/. Acesso em: 25 out. 2018

DIVISÃO DE PROCESSAMENTO DE IMAGENS (DIP). Coordenação Geral de


Observação da Terra. In: DPI. São Paulo. [2019?]. Disponível em:
http://www.dpi.inpe.br/DPI/. Acesso em: 13 mai. 2019

EMPRESA DE TRENS URBANOS DE PORTO ALEGRE S.A. (TRENSURB) Horários


TRENSURB In: TRENSURB, Porto Alegre, [2019?]. Disponível em:
http://www.trensurb.gov.br/paginas/paginas_detalhe.php?codigo_sitemap=18&l=es-
ES. Acesso em: 20 out. 2018

FARGAS, B. C., PETERSEN, M. N. GPS-free Geolocation using LoRa in Low-Power


WANs. Global Internet of Things Summit. Dinamarca, 2017. DOI:
10.1109/GIOTS.2017.8016251. Disponível em:
https://ieeexplore.ieee.org/document/8016251. Acesso em: 6 set. 2018

FASCIONI, L. GPS para curiosos. [S.l.], Ligia Fascioni. E-book. 2013. Disponível em:
http://www.ligiafascioni.com.br/wp-content/uploads/2013/04/GPS_Book.pdf. Acesso
em: 06 set. 2018
72

GAKSTATTER E. What Exactly Is GPS NMEA. In: GPS World. 2015 Disponível em:
http://gpsworld.com/what-exactly-is-gps-nmea-data/. Acesso em: 15 jan. 2019

GALVÃO, N. M., et al. Critérios Relevantes Na Escolha Da Instituição De Ensino.


Revista de Gestão e Contabilidade da UFPI.Piauí, v. 4 n. 1, 2017.

GARCIA, P. S R.., KLEINSHCMIDT, J. H.. Tecnologias emergentes de conectividade


na IoT: estudo de redes LPWAN. Simpósio Brasileiro De Telecomunicações E
Processamento De Sinais. São Paulo, 2017. Disponível em:
https://www.researchgate.net/publication/319762405_Tecnologias_Emergentes_de_
Conectividade_na_IoT_Estudo_de_Redes_LPWAN. Acesso em: 21 ago. 2018

GHOSLYA, S. All about LoRa and LoRaWAN. In: sghoslya, 2013. Disponível em:
https://www.sghoslya.com/. Acesso em: 15 ago. 2018

HART, M. A compact Arduino GPS/NMEA parser. In: Arduiniana, 2013. Disponível em:
http://arduiniana.org/libraries/tinygps/. Acesso em: 26 set. 2018

IBM CORPORATION. IBM LoRaWAN in C (LMiC). Suíça, 2015. Disponível em:


https://github.com/matthijskooijman/arduino-lmic-v1.5/raw/master/doc/LMiC-v1.5.pdf.
Acesso em: 26 set. 2018

INSTITUTO CEUB DE PESQUISA E DESENVOLVIMENTO (ICPD). Curso de GPS e


cartografia básica. Brasília. [2019?]. Disponível em: https://1f33f6c6-a-62cb3a1a-s-
sites.googlegroups.com/site/andersonmedeiros01/clickgeo/Apostila_de_Curso_de_G
PS_e_Cartografia_Basica.pdf?attachauth=ANoY7cq8OOlHv15-
qyuZeCFRaxczMjhA6Z9Ea9ZoRcy4gPmJl3BdvCoYDlALOoUtGYZWNNsrm9gsuxCp
cXc-Pnjv6RK4fXFHKxwdu6gas-GEV8sWysCu66426A-Hkb-mvOHYkytlkj-
rz3AXEVdLUBKEM4czt1Eo-
T1vJqy1O7yLX1bXtevRN9y8IvBI1faQjJU49x58Zut6bhMfZlP9kgHH4fYhNS-
QMFGyS5MwUZ8zImUXbBHzw3iLxGRoxAnuMchRv87KSU0lm5dSR0Xw0J_HB5a6
4gKxWQ%3D%3D&attredirects=0. Acesso em: 4 jul. 2018

INTRODUÇÃO ao JSON. In: JSON org. [2019?]. Disponível em:


https://www.json.org/json-pt.html. Acesso em: 24 set. 2018

KAPLAN, E. D., HEGARTY, C. J.. Understanding GPS. 2 ed. Massachusetts: Artech


House, 2006.

LAVRIC, A., POPA, V. (2017). LoRa wide-area networks from an internet of things
perspective. International Conference on Electronics, Computers and Artificial
Intelligence (ECAI), Romênia, 2017. DOI: 10.1109/ECAI.2017.8166397 Disponível
em:. https://ieeexplore.ieee.org/document/8166397. Acesso em: 29 ago. 2018

LAVRIC, A., POPA, V.. Internet of things and LoRa low-power wide-area networks: a
survey. International Symposium on Signals, Circuits and Systems (ISSCS).
Romênia, 2017. DOI: 10.1109/ISSCS.2017.8034915. Disponível em:
https://ieeexplore.ieee.org/document/8034915. Acesso em: 24 ago. 2018
73

LI, D., CHENG, C., ZHANG, B.. Vehicle Remote Monitoring System Based on Android.
International Conference on Software Engineering and Service Science
(ICSESS). China, 2016. DOI: 10.1109/ICSESS.2016.7883169. Disponível em:
https://ieeexplore.ieee.org/document/7883169. Acesso em: 10 set. 2018

LIEN, C.H., CHEN, P.T., BAI, Y.W. Software/hardware co-design of a vehicle


trajectory monitoring system. International Symposium on Consumer Electronics.
Portugal, 2008. DOI: 10.1109/ISCE.2008.4559498. Disponível em:
https://ieeexplore.ieee.org/document/4559498. Acesso em: 10 set. 2018

LOPES, C.. 10 cidades concentram 80% dos roubos de veículos no RS In:


GAÚCHAZH, Porto Alegre, 2018. Disponível em:
https://gauchazh.clicrbs.com.br/seguranca/noticia/2018/01/10-cidades-concentram-
80-dos-roubos-de-veiculos-no-rs-cjcgsid9d01o001kef5xuis97.html. Acesso em: 10
out. 2018

LORA ALLIANCE TECHNICAL COMMITTEE REGIONAL PARAMETERS


WORKGROUP. LoRaWAN™ 1.0.3 Regional Parameters. California, USA, 2018.
LORA ALLIANCE TECHNICAL COMMITTEE. LoRaWAN™ 1.0.3 Specification.
California, USA, 2018.

LORA ALLIANCE TECHNICAL MARKETING WORKGROUP. LoRaWAN What is it?


California, USA, 2015.

LORA: Symbol Generation, In: ALL about LoRa and LoRaWAN, [S.l.], [2018?].
Disponível em: https://www.sghoslya.com/p/lora-is-chirp-spread-spectrum.html.
Acesso em: 20 ago. 2018

MANCINI, M. Internet das coisas: história, conceitos, aplicações e desafios. [S.l.],


2018. Disponível em:
https://www.researchgate.net/publication/326065859_Internet_das_Coisas_Historia_
Conceitos_Aplicacoes_e_Desafios. Acesso em: 21 ago. 2018

OLIVEIRA, A.. Porque descarrega a bateria nos caminhões e ônibus. In:


Eletroeletrônica automotiva, 2010. Disponível em:
http://aparecidooliveira.blogspot.com/2010/01/sistema-eletrico-1224-v.html. Acesso
em: 15 out. 2018

SANTOS, B. P., et al. Internet das coisas: da teoria à prática. Belo Horizonte:
Departamento de Ciência da Computação Universidade Federal de Minas Gerais
(UFMG), 2016. Disponível em:
https://homepages.dcc.ufmg.br/~mmvieira/cc/papers/internet-das-coisas.pdf. Acesso
em: 21 ago. 2018

SAN-UM, W. et al A Long-Range Low-Power Wireless Sensor Network Based on U-


LoRa Technology for Tactical Troops Tracking Systems. Third Asian Conference on
Defence Technology. Tailândia, 2017. DOI: 10.1109/ACDT.2017.7886152
Disponível em: https://ieeexplore.ieee.org/document/7886152. Acesso em: 29 ago.
2018
74

SEMTECH CORPORATION, AN1200.22 LoRa™ Modulation Basics.2 ed. [S.l.],


2015.

SILVA, J. D., et al. LoRaWAN - a low power WAN protocol for internet of things: a
review and opportunities. International Multidisciplinary Conference on Computer
and Energy Science (SpliTech). Croácia, 2017. Disponível em:
https://ieeexplore.ieee.org/abstract/document/8019271. Acesso em: 29 ago. 2018

ST MICROELETRONICS (ST). STM32F103x8 & STM32F103xB [S.l.], 2015.


Disponível em: https://www.st.com/resource/en/datasheet/stm32f103c8.pdf. Acesso
em: 12 set. 2018

ST MICROELETRONICS (ST). STM32F334R8 [S.l.], 2018. Disponível em:


https://www.st.com/en/microcontrollers/stm32f334r8.html#samplebuy-scroll. Acesso
em: 12 set. 2018

ST MICROELETRONICS (ST). STM32Cube MCU Package for STM32F4 Series


with HAL, low-layer drivers and dedicated middleware. 6 ed. [S.l.], 2017.
Disponível em: https://www.st.com/resource/en/data_brief/stm32cubef4.pdf. Acesso
em: 12 set. dez

TIMBÓ, M. A.. Levantamentos através do sistema GPS. Minas Gerais:


Departamento De Cartografia UFMG, 2000.

U-BLOX AG. NEO-6: u-blox 6 GPS Modules Data Sheet. Suíça, 20011. Disponível
em: https://www.u-blox.com/sites/default/files/products/documents/NEO-
6_DataSheet_%28GPS.G6-HW-09005%29.pdf. Acesso em: 15 set. 2018

UNITED ESTATES OF AMERICA GOVERNMENT (USA GOV). Other Global


Navigation Satellite Systems (GNSS) In: GPS. 2017: Disponível em:
https://www.gps.gov/systems/gnss/. Acesso em: 20 ago. 2018

UNIVERSIDADE DO VALE DO RIO DOS SINOS (UNISINOS) Circular Unisinos, In:


Unisinos, São Leopoldo, 2018. Disponível em:
http://www.unisinos.br/servicos/transporte/circular-unisinos. Acesso em: 10 out. 2018

YUAN, M. Conhecendo o MQTT: Por que o MQTT é um dos melhores protocolos de


rede para a Internet das Coisas? In: IBM developer: [S.l.], 2017. Disponível em:
https://www.ibm.com/developerworks/br/library/iot-mqtt-why-good-for-iot/index.html.
Acesso em: 01 fev. 2019

Você também pode gostar