GENARO ANTONIO MAURO RANGEL
MONITORAMENTO DE ROTAS DE UMA FROTA VEICULAR POR MEIO DE APLICAÇÃO MÓVEL E COMPUTAÇÃO EM NUVEM
Vitória 2021
MONITORAMENTO DE ROTAS DE UMA FROTA VEICULAR POR MEIO DE APLICAÇÃO MÓVEL E COMPUTAÇÃO EM NUVEM
Trabalho de Conclusão de Curso apresentado à Coordenadoria de Engenharia Elétrica do Instituto Federal do Espírito Santo, como requisito parcial para aprovação na Disciplina de Metodologia de Pesquisa.
Orientador: Prof. Me. Danilo Cesar Azeredo Silva Coorientador: Prof. Me. Renato B. Cabelino Ribeiro
Vitória 2021
Dados Internacionais de Catalogação-na-Publicação (CIP) (Biblioteca Nilo Peçanha do Instituto Federal do Espírito Santo)
R196m Rangel, Genaro Antonio Mauro.
Monitoramento de rotas de uma frota veicular por meio de aplicação móvel e computação em nuvem / Genaro Antonio Mauro Rangel – 2021.
93 f. : il. ; 30 cm
Orientador: Danilo Cesar Azeredo Silva.
Coorientador: Renato Benezath Cabelino Ribeiro.
Monografia (graduação) – Instituto Federal do Espírito Santo, Coordenadoria de Engenharia Elétrica, Curso Superior de Engenharia Elétrica, 2021.
1. Engenharia Elétrica. 2. Computação em nuvem. 3. Smartphones. 4. Sistemas de controle inteligente. 5. Controladores programáveis. 6. Transportes – Administração. I. Silva, Danilo Cesar Azeredo. II. Ribeiro, Renato Benezath Cabelino. III. Instituto Federal do Espírito Santo. IV. Título.
CDD 21 – 621.3 Elaborada por Marcileia Seibert de Barcellos – CRB-6/ES - 656
! ! ! 021,725$0(172)'()527$6)'()80$))527$)9(,&8/$5)325)0(,2)'() $3/,&$232)049(/)()&20387$232)(0)189(0! ! ! 7UDEDOKR!GH!&RQFOXV£R!GH!&XUVR!DSUHVHQWDGR! !&RRUGHQDGRULD!GH! (QJHQKDULD!(O©WULFD!GR!,QVWLWXWR!)HGHUDO!GR!(VSULWR!6DQWRD!FRPR! UHTXLVLWR!SDUFLDO!SDUD!REWHQ§£R!GR!WWXOR!GH!%DFKDUHO!HP! (QJHQKDULD!(O©WULFDI!! ! ! ! ! $SURYDGR!HP!!!KL!GH!DEULO!GH!MKMN! ! ! &20,6632)(;$0,1$'25$! ! ! 3URII!0HIQ!'$1,/2!&(6$5!$=(5('2!6,/9$! ,QVWLWXWR!)HGHUDO!GR!(VSULWR!6DQWR!! 2ULHQWDGRU! ! 3URII!'UQ!5(1$72!%(1(=$7+!&$%(/,12!5,%(,52! ,QVWLWXWR!)HGHUDO!GR!(VSULWR!6DQWR! 2ULHQWDGRU! ! 3URII!'UQ!/($1'52!%8(12!! ,QVWLWXWR!)HGHUDO!GR!(VSULWR!6DQWR! 0HPEUR!,QWHUQR! ! 3URII!'UQ!-26W!('8$5'2!0(1'21X$!;$9,(5!! ,QVWLWXWR!)HGHUDO!GR!(VSULWR!6DQWR! 0HPEUR!,QWHUQR! ! !
Emitido em 07/04/2021
FOLHA DE APROVAÇÃO-TCC Nº 3/2021 - VIT-CCTE (11.02.35.01.09.02.19) NÃO PROTOCOLADO)
(Nº do Protocolo:
(Assinado digitalmente em 07/04/2021 12:24 ) DANILO CESAR AZEREDO SILVA
PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO VIT-CCTE (11.02.35.01.09.02.19)
Matrícula: 270274
(Assinado digitalmente em 07/04/2021 14:50 ) JOSE EDUARDO MENDONCA XAVIER
PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO VIT-CCTE (11.02.35.01.09.02.19)
Matrícula: 1168384
(Assinado digitalmente em 07/04/2021 13:36 ) LEANDRO BUENO
PROFESSOR DO ENSINO BASICO TECNICO E TECNOLOGICO VIT-CCEE (11.02.35.01.09.02.11)
Matrícula: 1361682
(Assinado digitalmente em 07/04/2021 13:43 ) RENATO BENEZATH CABELINO RIBEIRO
COORDENADOR DE COORDENADORIA VIT-CTI (11.02.35.01.03)
Matrícula: 1341061
Para verificar a autenticidade deste documento entre em https://sipac.ifes.edu.br/documentos/ informando seu número: , ano: 3 2021, tipo: FOLHA DE APROVAÇÃO-TCC, data de emissão: 07/04/2021 e o código de
recursos operacionais e materiais pode ser alcançada por um sistema inteligente de monitoramento de ativos. A Internet das Coisas configura uma era em que dispositivos se comunicam por redes sem fios com uma alta taxa de transmissão de dados. Hoje, celulares inteligentes proporcionam uma alta capacidade de processamento de dados e comunicação em uma plataforma móvel. Este trabalho apresenta um sistema de monitoramento de frota veicular com telemática veicular baseada em smartphones, com objetivo de realizar o monitoramento de rotas transcorridas por operadores de uma frota de uma empresa de pequeno porte. Para tanto, um aplicativo móvel foi desenvolvido para, com auxílio de GPS e redes móveis, aferir a localização em tempo real e realizar esse monitoramento. Além disso, tecnologias de computação em nuvem são empregadas para armazenamento de dados e acesso a serviços de roteamento, mapeamento e navegação. O sistema desenvolvido possui viabilidade de aplicação para gerenciamento de frotas com foco no mapeamento e seleção ótima de rotas, que pode ser aplicado a economia de combustível, controle de operações e levantamento de informações de navegação veicular.
Palavras-chave: Sistema de Gerenciamento de Frota. Telemática veicular baseada em smartphones. Aplicativo móvel.
Achieving energy efficiency is an urgent demand for humanity. Significant operational and material resources savings can be achieved by utilizing intelligent asset monitoring systems. The Internet of Things represents an era in which devices communicate over wireless networks with a high data transmission rate. Today, smartphones provide high data processing and communication capabilities on a mobile platform. This work presents a smartphone-based vehicle fleet monitoring system that utilizes vehicle telematics, aiming to monitor routes traveled by operators of a small company car fleet. Hence, a mobile application was developed to monitor vehicle’s real-time location using GPS and mobile networks. Additionally, cloud computing technologies were employed for data storage and access to routing, mapping, and navigation services. This monitoring system is a viable solution for fleet management that focus on mapping and selection of optimal routes, improving fuel economy, operations, and evaluation of vehicles routes.
Keywords: Fleet Management System. Vehicle telematics based on smartphones. Mobile application.
Figura 2 – Elipsoide de revolução: a referência geométrica da Terra ... 17
Figura 3 – As camadas do OS Android ... 19
Figura 4 – Diagrama de um projeto multiplataforma utilizando Xamarin ... 21
Figura 5 – Esquema básico de um Web API ... 22
Figura 6 – Um array com dois objetos representados em JSON ... 23
Figura 7 – Expectativa de mercado de telemática veicular em 2019 e de telemática e IoT em 2020 ... 25
Figura 8 – Esquema básico da telemática veicular baseada em smartphone ... 26
Figura 9 – DER para o banco de dados construído para este trabalho ... 37
Figura 10 – Resposta característica de uma requisição ao API Distance Matrix ... 42
Figura 11 – Página principal do app para efetuar login no sistema ... 57
Figura 12 – Página de entrada de dados de serviço pelo usuário ... 58
Figura 13 – Página de navegação do usuário ... 60
Figura 14 – Página do gerente da frota ... 61
Figura 15 – ServicePage, contendo as informações da rota de um serviço especificado ... 62
Figura 16 – DisplayRoutePage, que exibe a rota percorrida para um determinado serviço ... 63
Figura 17 – Página de acesso ao sistema (login) durante teste ... 64
Figura 18 – Página de entrada de serviço durante teste ... 65
Figura 19 – Página de navegação do usuário durante teste ... 66
Figura 20 – Página de navegação ao finalizar a rota ... 66
Figura 21 – Informações da rota do serviço 2130701 ... 69
Quadro 2 – Etapas do método ... 30 Quadro 3 – Estrutura da tabela de serviços ... 38
API – Application Program Interface App – Aplicativo móvel
ASCII – American Standard Code for Information Interchange BDS – BeiDou Navigation Satellite System
CO2 – Dióxido de carbono
DER – Diagrama Entidade Relacionamento ETA – Estimated Time of Arrival
FMS – Fleet Management System
GLONASS – Global Navigation Satellite System GNSS – Global Navigation Satellite System GPS – Global Positioning System
HTTP – HyperText Transfer Protocol
IBGE – Instituto Brasileiro de Geografia e Estatística ID – Identificação
IDE – Integrated Development Environment IHM – Interface Homem-máquina
IoT – Internet of Things
JSON – JavaScript Object Notation Km – Quilômetros
MCC – Mobile Cloud Computing
MIT – Massachusetts Institute of Technology OBD – On-Board Diagnostics
OBU – On-Board Unit OS – Operating System
REST – Representational State Transfer RFC – Request for Comments
SDK – Software Development Kit
SIG – Sistemas de Informações Geográficas UI – User Interface
URI – Uniform Resource Identifier VTS – Vehicle Tracking System WS – Web Service
OBJETIVO GERAL ... 13
OBJETIVOS ESPECÍFICOS ... 14
ESTRUTURA GERAL DO TRABALHO ... 14
2 REFERENCIAL TEÓRICO ... 16
SISTEMAS DE GEOLOCALIZAÇÃO NA SUPERFÍCIE DA TERRA ... 16
2.1.1 Referenciais geodésicos da Terra ... 16
2.1.2 Sistema Global de Navegação por Satélite ... 17
TECNOLOGIAS PARA DESENVOLVIMENTO DE APLICAÇÕES MÓVEIS .. 18
2.2.1 Sistemas operacionais de smartphones ... 18
2.2.2 Frameworks para desenvolvimento de apps ... 19
COMPUTAÇÃO EM NUVEM ... 21
ARQUITETURA REST ... 22
PLATAFORMA GOOGLE MAPS ... 23
2.5.1 Polilinha Codificada... 24
TELEMÁTICA VEICULAR BASEADA EM SMARTPHONES ... 24
REVISÃO DE TRABALHOS RELACIONADOS ... 26
3 MÉTODO ... 30
TIPO DE PESQUISA ... 31
DEFINIR O CENÁRIO DE APLICAÇÃO DO FMS ... 31
DEFINIR A FUNCIONALIDADE DO APP ... 32
DEFINIR A PLATAFORMA DE DESENVOLVIMENTO DO APP ... 33
CRIAR UM BANCO DE DADOS EM NUVEM PARA A ARMAZENAR AS INFORMAÇÕES DE FUNCIONÁRIOS E SERVIÇOS ... 33
CRIAR UMA WEB APP PARA ADICIONAR A FUNCIONALIDADE BACKEND AO PROJETO ... 33
CRIAR UM PROJETO EM PLATAFORMA DE COMPUTAÇÃO EM NUVEM PARA CONSUMIR SERVIÇOS DE ROTEAMENTO E MAPEAMENTO ... 34
DESENVOLVER UM SERVIÇO DE SMARTPHONE PARA AFERIR LOCALIZAÇÃO EM SEGUNDO PLANO ... 34
4 DESENVOLVIMENTO ... 37
BANCO DE DADOS EM NUVEM COM INFORMAÇÕES DE INFORMAÇÕES DE FUNCIONÁRIOS E SERVIÇOS ... 37
WEB APP PARA COM FUNCIONALIDADE BACKEND DO PROJETO ... 39
CONSUMO DE SERVIÇOS DE MAPEAMENTO E ROTEAMENTO POR MEIO DE APIS DA PLATAFORMA GOOGLE MAPS ... 41
SERVIÇO DE LOCALIZAÇÃO EM SEGUNDO PLANO ... 50
UI E LÓGICA DO APP PARA SMARTPHONE ... 56
4.5.1 Página inicial de login do sistema... 56
4.5.2 Página de entrada de serviço pelo funcionário ... 57
4.5.3 Página de navegação do funcionário ... 59
RELATÓRIOS PARA O GERENTE DA FROTA ... 60
4.6.1 Página do gerente da frota ... 61
4.6.2 Página com informações de rota de serviço ... 61
4.6.3 Página de exibição de rota ... 62
5 RESULTADOS ... 64 ANÁLISE DE RESULTADOS ... 67 5.1.1 Análise quantitativa ... 67 5.1.2 Análise qualitativa ... 67 6 CONCLUSÃO ... 70 REFERÊNCIAS ... 72
APÊNDICE A – Página principal e lógica de validação de acesso ao sistema ... 77
APÊNDICE B – Lógica e códigos utilizados para implementar a página de inserção de dados de serviço pelo usuário ... 79
APÊNDICE C – Lógica e códigos utilizados para implementar a página de navegação do usuário... 82
APÊNDICE D – Lógica e códigos utilizados para implementar as páginas desenvolvidas para o gerente da frota ... 89
1 INTRODUÇÃO
A preocupação global com economia de recursos naturais e eficiência energética define novos panoramas no desenvolvimento e utilização de tecnologias. A Global
Footprint Network (2020) estima que a humanidade exceda a utilização de recursos
naturais em 60% da capacidade máxima que o planeta consegue regenerar anualmente. Por isso, o desenvolvimento econômico e a preservação do meio ambiente se tornaram desafios para a humanidade. Nesse sentido, uma grande preocupação de países desenvolvidos e em desenvolvimento é a acumulação de gases de efeito estufa na atmosfera (UDDIN et al., 2017). Segundo o Parlamento Europeu (2019), quase 30% das emissões de CO2,um importante gás causador do efeito estufa, da Europa são provenientes dos transportes, sendo 72% destes dos transportes rodoviários.
Neste contexto, nota-se a importância do desenvolvimento de tecnologias capazes de otimizar o uso de veículos. Diversas tecnologias têm sido desenvolvidas a fim de realizar essa tarefa, tais como Sistema de Rastreamento de Veículos (Vehicle
Tracking Systems – VTS) e Sistema de Gerenciamento de Frotas (Fleet Management Systems – FMS). O mercado de FMS “[...] deve crescer de US$ 19,9 bilhões em 2020
para US$ 34,0 bilhões até 2025” (MARKETSANDMARKETS, 2020, não paginado, tradução nossa). OS VTSs foram primeiramente implantados nas indústrias de logística. Porém, com o rápido avanço da tecnologia, esses sistemas foram empregados nas mais variadas áreas de atuação em que se tenha necessidade de saber a localização de veículos em tempo real (LEE; TEWOLDE; KWON, 2014). Whalstrom, Skog e Handel (2017) dizem que a Internet das Coisas (Internet of Things – IoT) torna real a possibilidade de serviços de monitoramento, devido a conexão de dispositivos com capacidade de mandar e receber informações com uma enorme quantidade dados, que podem ser utilizados em diversas análises e tomadas de decisão. Afirmam ainda, que os smartphones uniram a portabilidade do celular com a capacidade de processamento de computadores, além de possuírem diversos sensores e capacidade de comunicação sem fio, tornando-os uma ferramenta viável para navegação de veículos. Por isso, é possível, e muitas vezes preferível, que se utilize apenas o smartphone como meio de telemática veicular. Nesses dispositivos, aplicativos móveis (apps), com tecnologias incluindo comunicação em tempo real,
viabilizaram vários produtos na indústria de transportes (RINCON-GARCIA; WATERSON; CHERRETT, 2018). De acordo com Siuhi e Mwakalonge (2016), os apps podem reduzir tempo de trajeto e custo, e essas escolhas inteligentes de viagem promovem eficiência nos transportes, gerando benefícios ambientais. Para o usuário, um simples aplicativo é suficiente para implantação desse tipo de solução (WAHLSTROM; SKOG; HANDEL, 2017), incluindo a Interface Homem-Máquina (IHM). Aparte do usuário, esse tipo de aplicação só é possível com a utilização de computação em nuvem, para que os dados sejam processados e armazenados na internet e que serviços externos sejam utilizados. A computação em nuvem promove segurança, disponibilidade, portabilidade e sincronização de diversos dispositivos (SANAEI et al., 2014).
Além da capacidade de realização de projetos na área de telemática veicular, os celulares são amplamente difundidos. A Agência Nacional de Telecomunicações (2020) mostra em sua base de dados que existem mais de 225 milhões de acessos de telefonia móvel no Brasil. O aumento da penetração dos smartphones no cotidiano das pessoas aumenta a influência dos mesmos na sociedade, principalmente pelo fato de possuírem uma enorme gama de aplicações para diferentes tipos de necessidades (LEE; TEWOLDE; KWON, 2014).
Por todos esses fatores explicitados, “um grande número de projetos acadêmicos e industriais relacionados à telemática de veículos baseados em smartphones foram realizados” (WAHLSTROM; SKOG; HANDEL, 2017, p. 2805, tradução nossa), sendo que esses se diferenciam bastante em função do tipo de aplicação e complexidade dos sensores utilizados.
Diante desse cenário, este trabalho visa o desenvolvimento e implantação de um sistema de monitoramento de frota para empresas de pequeno porte, utilizando o rastreamento e armazenamento de rotas como função principal, por meio de serviços de nuvem e uma aplicação móvel.
OBJETIVO GERAL
Este trabalho tem como objetivo geral desenvolver um sistema de monitoramento de rotas de uma frota veicular para empresas de pequeno porte, com o objetivo de reduzir
o custo operacional através da determinação mais precisa dos trajetos percorridos pelos operadores.
OBJETIVOS ESPECÍFICOS
• Desenvolver um sistema de monitoramento de rotas baseado em aplicação móvel, para realizar o monitoramento de rotas percorridas por operadores de veículos em uma empresa de pequeno porte;
• Desenvolver um serviço de localização em tempo real para execução no
smartphone em segundo plano;
• Criar um banco de dados para armazenar informações dos operadores da frota e suas rotas desenvolvidas;
• Configurar acesso a serviços de nuvem de mapeamento, roteamento e navegação veicular;
• Elaborar suíte de relatórios para gerenciamento de informações das rotas percorridas pelos operadores da frota;
• Testar o sistema e realizar as análises pertinentes para validação do aplicativo e a viabilidade de utilização do sistema desenvolvido.
ESTRUTURA GERAL DO TRABALHO
Este trabalho foi divido em 6 capítulos, que podem ser definidos como:
I. Este capítulo apresenta a introdução, que contém o contexto geral e a motivação deste trabalho, objetivo geral e objetivos específicos, além da estrutura geral do trabalho, representado na seção atual;
II. O segundo capítulo corresponde à revisão de literatura, que apresenta o referencial teórico acerca dos tópicos principais relacionados ao trabalho e
seus conceitos. Também está contida nesse capítulo a revisão de trabalhos similares ao proposto neste trabalho;
III. Este consiste no capítulo relacionado à metodologia aplicada no desenvolvimento do projeto como um todo, ao cenário de desenvolvimento e principais técnicas e tecnologias utilizadas;
IV. Este capítulo contém o aprofundamento do desenvolvimento das técnicas e tecnologias empregadas neste trabalho;
V. O quinto capítulo corresponde aos resultados obtidos ao testar-se o sistema ao colocá-lo a prova em uma situação real;
VI. O sexto e último capítulo busca discutir sobre o trabalho como um todo e propor melhorias e indicações de possíveis trabalhos futuros englobando a solução desenvolvida neste trabalho.
2 REFERENCIAL TEÓRICO
SISTEMAS DE GEOLOCALIZAÇÃO NA SUPERFÍCIE DA TERRA
2.1.1 Referenciais geodésicos da Terra
A representação da Terra mudou conforme as teorias e as tecnologias de aferimento do formato do planeta evoluíram. Inicialmente, acreditava-se que a Terra era um disco cercado pelo oceano, mas pensadores da antiguidade como Homero, Pitágoras e Aristóteles já expressavam opinião sobre o formato esférico do planeta (ORGANIZAÇÃO DA AVIAÇÃO CIVIL INTERNACIONAL, 2002). Esses estudos encontram-se no campo da Geodésia, que pode ser definida como “[...] a ciência de medir e mapear o campo de geometria, rotação e gravidade da Terra, incluindo suas variações com o tempo” (PLAG et al., 2010, p. 126, tradução nossa).
Segundo o Instituto Brasileiro de Geografia e Estatística (IBGE), existem três representações da superfície da Terra: física, representada pelo geoide, matemática, representada pelo elipsoide e, por último, a superfície real da Terra, onde são aferidas as medições (INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA, 2019). 2.1.1.1 Referência física da Terra
Figura 1 – Geoide: o formato da Terra
Fonte: Plag et al. (2010, p. 138)
Atualmente, assume-se que a melhor representação para a Terra é o geoide que, como pode ser observado na Figura 1, “[...] tem formato levemente irregular que acompanha as variações de distribuição de massa da Terra” (INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA, 2019, p. 20).
2.1.1.2 Referência matemática e localização na Terra
Figura 2 – Elipsoide de revolução: a referência geométrica da Terra
Fonte: Instituto Brasileiro de Geografia e Estatística (2019, p. 22)
O melhor modelo matemático para representação geométrica da Terra é o elipsoide de revolução, visto na Figura 2. Nesse modelo, é possível determinar latitude e longitude, que formam o sistema de coordenadas geodésicas:
• Latitude: “é o ângulo entre o plano equatorial e a normal ao elipsoide que passa pelo ponto considerado, contado ao longo do meridiano do ponto, variando de 0º a +/- 90º entre o Equador e os Polos” (INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA, 2019, p. 22);
• Longitude: “é o ângulo entre o plano do meridiano de referência (Greenwich) e o do meridiano do ponto considerado, contato no plano do equador, variando de 0º a 360º ou de -180º a +180º” (INSTITUTO BRASILEIRO DE GEOGRAFIA E ESTATÍSTICA, 2019, p. 22).
2.1.2 Sistema Global de Navegação por Satélite
A European Global Navigation Satellite Systems Agency (2020) define o Sistema Global de Navegação por Satélite (Global Navigation Satellite System – GNSS) como nome genérico dado para sistemas que possuem uma constelação de satélites e que provêm dados de posição e tempo usados para localização. Existem alguns GNSSs em operação no mundo, nos quais se destacam o GPS, dos Estados Unidos, o
GLONASS, da Rússia, o BDS, da China e o Galileo, da Europa. Os parâmetros de avaliação de desempenho de GNSS são: precisão, integridade, continuidade e disponibilidade.
TECNOLOGIAS PARA DESENVOLVIMENTO DE APLICAÇÕES MÓVEIS
2.2.1 Sistemas operacionais de smartphones
Segundo Siuhi e Mwakalonge (2016), a popularidade dos smartphones criou uma dependência do uso desse tipo de dispositivo entre as pessoas, por conta da onipresença dos serviços de comunicação e informação disponíveis. Dizem ainda que, diferentemente dos celulares convencionais, os smartphones possuem um Sistema Operacional (Operating System – OS) que possibilita o desenvolvimento de programas por terceiros. Isso motivou o surgimento de várias empresas, que introduziram no mercado aplicações atrativas ao consumidor.
Segundo Jindal e Jain (2012), um OS gerencia hardware e software para realizar tarefas nos dispositivos, além de permitir que mais de um programa seja utilizado ao mesmo tempo sem que um interfira em outro. Além disso, os OSs interagem com usuário através da interface de usuário (User Interface – UI). A UI disponibiliza as informações estritamente necessárias para a comunicação com usuário, enquanto oculta propositalmente diversas informações referentes aos processos realizados pelas tarefas dos apps. Afirmam ainda que, através de interfaces de programação (Application Program Interfaces – APIs), são realizadas as conexões entre OS e app que garantem ao desenvolvedor que uma aplicação seja compatível entre dispositivos com mesmo OS.
As indústrias do setor mobile, termo genérico em inglês utilizado para caracterizar tecnologias móveis, tornaram-se cada vez mais competitivas, desenvolvendo diferentes OSs (JINDAL; JAIN, 2012). Dentre estes, destacam-se mundialmente, os sistemas Android® e iOS.
2.2.1.1 Android
O OS Android foi desenvolvido baseado no OS Linux® e pertence a Google LLC, que adquiriu a startup Android Inc., em 2005. O primeiro smartphone com Android,
introduzido no mercado em 2008, foi o HTC Dream (JINDAL; JAIN, 2012). Hoje o sistema é um projeto de Código Aberto (Open Source) e é desenvolvido continuamente através do Android Open Source Project (AOSP) (GOOGLE LLC, 2020a). Para desenvolver aplicações para esse OS é preciso utilizar um Software Development Kit (SDK), que é disponibilizado gratuitamente na internet (JINDAL; JAIN, 2012). A Figura 3 mostra a estrutura do OS Android, desde o núcleo (kernel) do OS Linux até o app.
Figura 3 – As camadas do OS Android
Fonte: Google LLC (2020a, não paginado)
2.2.2 Frameworks para desenvolvimento de apps
Cada OS possui ambientes integrados de desenvolvimento (Integrated Development Environment – IDE) específicos para sua plataforma. Destacam-se, entre eles, Android Studio e Xcode®. Android Studio é o principal IDE utilizado para desenvolver apps do OS Android e utiliza linguagem de programação Java como base. Xcode é o principal IDE utilizado para desenvolvimento de aplicações para diferentes sistemas da Apple e tem foco na linguagem Swift.
Além dos IDEs específicas para cada OS, existem frameworks para desenvolvimento multiplataforma de apps. Esses frameworks são atrativos para aqueles que precisam desenvolver apps para várias plataformas diferentes. Além disso, por serem geralmente baseados em uma linguagem de programação única, a manutenção dos códigos torna-se mais simples e menos onerosa. Entretanto, mesmo com a evolução desses frameworks, ainda há uma superioridade de performance dos apps nativos das plataformas. Ademais, existem problemas de compatibilidade e acessibilidade dos programas multiplataforma com recursos dos OSs. Mesmo assim, as tecnologias multiplataforma de hoje permitem o desenvolvimento de aplicações com qualidade e com economia de recursos operacionais (YATSENKO; OBODIAK; YATSENKO, 2019).
2.2.2.1 Xamarin®
A Microsoft® diz que “O Xamarin é uma plataforma de software livre para a criação de aplicativos modernos e de alto desempenho para iOS, Android e Windows com o .NET®” (MICROSOFT CORPORATION, 2020c, não paginado, tradução nossa). Diz ainda, que é possível compartilhar em média 90% do código do app desenvolvido entre as diferentes plataformas, utilizando o IDE Visual Studio® e a linguagem de programação C# (EUROPEAN COMPUTER MACHINERY ASSOCIATION, 2005). O Xamariné baseado em .NET, plataforma integrada da Microsoft para desenvolvimento de aplicações, que é responsável pela interoperabilidade entre diferentes plataformas. Os apps para Android e iOS desenvolvidos em Xamarin são chamados de Xamarin.Android e Xamarin.iOs, respectivamente. O Xamarin.Android realiza a compilação de C# para uma linguagem intermediária, seguido de um assembly nativo no momento em que o app é inicializado. Já o Xamarin.iOS compila o código em C# diretamente para assembly nativo, realizando associações entre C# e Objective-C através de seletores e registradores (MICROSOFT CORPORATION, 2020c). Um diagrama de uma aplicação multiplataforma com código compartilhado para iOS e Android pode ser observada na Figura 4. Ressalta-se que os apps desenvolvidos com Xamarin possuem implantação nativa, o que gera grande desempenho e confiabilidade.
Figura 4 – Diagrama de um projeto multiplataforma utilizando Xamarin
Fonte: Microsoft (2020c, não paginado)
Pode-se, ainda, utilizar a tecnologia Xamarin.Forms para criar uma estrutura de UI compartilhada para iOS e Android codificada em Extensible Application Markup
Language (XAML) aliada à programação em C#. A UI é renderizada nativamente para
cada plataforma (MICROSOFT CORPORATION, 2020c). A XAML é uma linguagem de marcação utilizada para criar UIs para apps baseados em .NET. (MICROSOFT CORPORATION, 2019a) e é baseada na linguagem XML (WORLD WIDE WEB CONSORTIUM, 2008).
COMPUTAÇÃO EM NUVEM
[...] a computação em nuvem é o fornecimento de serviços de computação, incluindo servidores, armazenamento, bancos de dados, rede, software, análise e inteligência, pela Internet (“a nuvem”) para oferecer inovações mais rápidas, recursos flexíveis e economias de escala (MICROSOFT CORPORATION, 2020a, não paginado).
Sanaei et al. (2014) apontam que apesar da portabilidade, os smartphones possuem capacidade limitada de duração de bateria, processamento e armazenamento. A Microsoft relata que computação em nuvem permite ao dispositivo acessar serviços terceirizados a fim de reduzir custos operacionais, pagando por esses serviços sob demanda. Isso permite que as aplicações desenvolvidas tenham maior eficiência e poder de escalonamento, aumentando a estrutura empregada conforme a necessidade (MICROSOFT CORPORATION, 2020a). Para facilitar o acesso a diferentes soluções de computação em nuvem, a Microsoft criou o Azure®, que é um conjunto de serviços, aplicativos e produtos que podem ser reunidos para uma mesma solução, com suporte a mais de 90 ferramentas de desenvolvimento, banco de dados, IoT, entre outros (MICROSOFT CORPORATION, 2020b).
Para sistemas de dispositivos móveis, há a convergência de três tipos de tecnologia: computação em nuvem, computação móvel e networking, que definem a computação móvel em nuvem (Mobile Cloud Computing – MCC). MCC é um paradigma tecnológico recente que implica em recursos elásticos de computação em nuvem disponíveis a qualquer momento e em qualquer lugar, por redes de comunicação de dados e para uma infinidade de dispositivos móveis (SANAEI et al., 2014).
ARQUITETURA REST
Para acessar serviços da Internet, é preciso estabelecer comunicação entre aplicações por meio de Web Service (WS). Uma das soluções desenvolvidas para esse fim é a arquitetura Representational State Transfer (REST). A arquitetura REST é comumente utilizada em APIs que escutam e respondem às requisições dos clientes de um WS. Um REST API é uma API que tem como base essa arquitetura. Além disso, um WS que utiliza REST API é chamado de RESTful (MASSÉ, 2012). A Figura 5 representa um esquema básico da comunicação entre um WS e um cliente por um
Web API.
Figura 5 – Esquema básico de um Web API
Fonte: Massé (2012, p. 6)
Massé (2012, p. 11, tradução nossa) afirma que “REST APIs usam Uniform Resource
Identifiers (URIs) para endereçar recursos”. Berners-Lee (2020) aponta que URI é
parte do padrão universal de referenciamento de endereços. Em uma REST API, a URI utiliza o protocolo HyperText Transfer Protocol (HTTP) versão 1.1 (THE INTERNET SOCIETY, 1999) para requisições e respostas, como no exemplo a seguir: “http://api.example.restapi.org/france/paris/louvre/leonardo-da-vinci/mona-lisa”
(MASSÉ, 2012, p. 11)
Segundo Massé (2012), o corpo das respostas de um REST API utilizam algum tipo de texto estruturado como o JavaScript Object Notation (JSON), padronizado pela norma Request for Comments (RFC) 8259. A norma descreve JSON como “[...] um
formato de intercâmbio de dados leve, baseado em texto e independente de linguagem” (INTERNET ENGINEERING TASK FORCE, 2017, p. 1, tradução nossa). O padrão JSON foi criado para ser facilmente entendido tanto por máquinas quanto por seres humanos e é baseado em duas estruturas principais: objeto, formado por um conjunto de pares de nomes e valores, e array, formado por uma lista ordenada de valores. Na codificação, o objeto situa-se entre chaves em que cada nome é seguido por dois pontos e os pares seguidos por vírgulas. Já o array fica entre colchetes e seus valores separados por vírgula (JSON.ORG, 2020). A Figura 6 exemplifica uma estrutura em JSON contendo a codificação supracitada.
Figura 6 – Um array com dois objetos representados em JSON
Fonte: Internet Engineering Task Force (2017, p. 13)
PLATAFORMA GOOGLE MAPS
A Plataforma Google Maps® faz parte da plataforma de computação em nuvem da Google (Google Cloud®) e oferece APIs e SDKs necessários para desenvolvimento de aplicações com a tecnologia de mapas da Google. Google Maps possui 99% de cobertura no mundo e cerca de um bilhão de usuários ativos (GOOGLE LLC, 2020b). Dentre os vários produtos oferecidos pela Plataforma Google Maps, destacam-se
Maps, Routes e Places. O produto Maps engloba os serviços de mapeamento
produto Routes oferece serviços de roteamento através da API Directions, usados
para verificar rotas para diferentes meios de transporte. O produto Distance Matrix calcula a distância e tempo de viagens. O produto Roads permite determinar um trajeto percorrido por um veículo por meio de pontos de localização fornecidos pelo usuário. Por fim, o produto Places disponibiliza informações completas de um local específico, a partir de dados do mesmo, como endereço ou número de telefone (GOOGLE LLC, 2020c).
2.5.1 Polilinha Codificada
Uma forma inteligente de armazenar pontos de posicionamento de uma rota é realizar a formatação de codificação de polilinha, utilizada pela Plataforma Google Maps. Para isso, um algoritmo empregado realiza a conversão de pontos de coordenadas geodésicas em números binários, e então, para um caractere em formato American
Standard Code for Information Interchange - ASCII (HIERONYMUS, 1993). Por
exemplo, a coordenada -179,9832104 é codificada como `~oia@ no formato ASCII. Além disso, pensando na economia de recursos, são armazenadas apenas as compensações de deslocamento entre pontos, visto que em uma rota, geralmente, os valores de longitude e latitude não mudam bruscamente (GOOGLE LLC, 2021a).
TELEMÁTICA VEICULAR BASEADA EM SMARTPHONES
FMSs e VTSs são empregados para gerenciar veículos e motoristas de uma determinada frota. Esses sistemas são utilizados para diferentes fins como: monitoramento de veículos em tempo real, gerenciamento de combustível e sistemas antifurto. Segundo Mason, Mitchel e Morris (2015), através da UI, um usuário do sistema pode obter informações sobre operações de veículos de uma frota, incluindo o monitoramento de rotas. Essas informações devem incluir a identificação (ID) do veículo, definição da rota a ser percorrida e a duração do trajeto até o destino. Além disso, o sistema deve conter um mapa para auxiliar o motorista, com sua localização atual e tempo estimado até o fim do percurso (FATIMA et al., 2019). Segundo Bear et al. (2019), mapas geográficos interativos provenientes de WSs e Sistemas de Informações Geográficas (SIGs) podem ser usados para procurar, visualizar locais e determinar direções entre duas localizações, além de exibir imagens de satélite ou genéricas, geradas por software, das rotas.
No veículo, a aplicação de um VTS é realizada por meio de um dispositivo eletrônico (LEE; TEWOLDE; KWON, 2014). Um smartphone possui mobilidade, capacidade de processamento, sensores, acesso a serviços de nuvem e capacidade de comunicação sem fio. Por isso, esse tipo de dispositivo é utilizado para coletar dados, manipulá-los e transmiti-los, ou seja, realizar telemática (WAHLSTROM; SKOG; HANDEL, 2017). Nota-se, na Figura 7, que o valor de mercado da telemática veicular estimado, em 2017 para 2019 foi de 45 bilhões de dólares, sendo a telemática veicular baseada em
smartphones uma parte importante desse campo.
Figura 7 – Expectativa de mercado de telemática veicular em 2019 e de telemática e IoT em 2020
Fonte: Adaptado pelo Autor com base em Wahlstrom, Skog e Handel (2017, p. 208, tradução nossa)
A telemática veicular baseada em smartphones, vista na Figura 8, pode ser auxiliada por sensores complementares ou não. As vantagens da utilização de sensores de um
smartphone ao invés dos sensores fixos dos veículos incluem: maior potencial para
atualizações e escalabilidade e menor preço e resposta instantânea ao usuário através da IHM. Em contrapartida, há desvantagens, como: sensores de baixa qualidade e limitação da capacidade de duração da bateria embutida (WAHLSTROM; SKOG; HANDEL, 2017).
Figura 8 – Esquema básico da telemática veicular baseada em smartphone
Fonte: Adaptado pelo Autor baseado em Wahlstrom, Skog e Handel (2017, p. 2803, tradução nossa)
Nota-se, na Figura 8, a central de armazenamento e computação. Vale ressaltar que essas operações podem ser inteiramente baseadas em computação em nuvem.
REVISÃO DE TRABALHOS RELACIONADOS
A grande difusão dos smartphones no mundo proporcionou novos meios de telemática para navegação, beneficiando motoristas e proprietários de veículos de modo geral. O grande número de projetos, tanto na área acadêmica, quanto na área comercial, que utilizam o smartphone como parte fundamental da telemática veicular, reafirma o potencial do desenvolvimento de projetos na área (WAHLSTROM; SKOG; HANDEL, 2017). Nesta seção, vários trabalhos relacionados à área são revisados.
Lin et al. (2014) desenvolveram um projeto de FMS, incluindo rastreamento, serviços de informação e histórico de rotas. Neste projeto, veículos foram equipados com um
smartphone embarcado para aferimento de posição via GPS e comunicação sem fio.
Um app foi criado para ser aplicado ao smartphone com a tecnologia Google App Inventor, hoje MIT App Inventor®, mantida pelo Instituto de Tecnologia de Massachusetts (Massachusetts Institute of Technology – MIT). O App Inventor utiliza programação de blocos, sendo visualmente simples e intuitiva (MASSACHUSETTS INSTITUTE OF TECHNOLOGY, 2020). Nessa plataforma, foram desenvolvidas tanto a lógica quanto a UI do app. O app possui quatro funções básicas: registro de um novo veículo, envio e recebimento de mensagens através de uma central de monitoramento, consulta a serviços de navegação via Google Maps e registro de informações em nuvem. A Google App Engine®, plataforma integrada de serviços de nuvem da Google, foi empregada para esse propósito. Ainda, essa plataforma foi
utilizada para acessar APIs e criar um servidor para armazenar a central de monitoramento, cuja função principal é monitorar veículos em tempo real e comunicar-se com os mesmos. Essa central foi decomunicar-senvolvida via IDE Eclipcomunicar-se® e podia ser acessada via URL na web.
Fatima et al. (2019) desenvolveram um FMS voltado para ônibus escolares. Desenvolveram, também, um app para Android e utilizaram o serviço de computação em nuvem da Amazon®. Este app é dividido em três módulos: um para o usuário de ônibus (estudante), um para o motorista e um para o administrador da frota. Uma aplicação web foi criada para o administrador registrar novos motoristas, gerenciar rotas, comunicar-se com o motorista e visualizar informações dos estudantes cadastrados. O usuário e o motorista utilizam o sistema por meio de app para Android. O usuário pode procurar por um ônibus no app, visualizá-lo em um mapa e receber notificações quando o ônibus estiver próximo ao ponto de parada mais próximo. Para o motorista, o app mostra a rota em um mapa. Ao sinalizar a partida, o app inicia o rastreamento do ônibus até o ponto final ser atingido, cessando o rastreamento. Outro FMS para transporte coletivo foi proposto por Ogbonna et al. (2016). O sistema também utilizou o GPS de um smartphone para aferir localização do veículo. No app desenvolvido, o motorista seleciona uma rota programada e, ao sinalizar a partida via botão digital, o app começa a aferir sua localização a cada 30 segundos, armazenando os dados num servidor web. Cada localização é testada por uma rotina para verificar se a mesma estava prevista na rota programada. Essas rotas foram geradas através de conexões entre os pontos de um trajeto previamente percorrido. Esse trajeto também é utilizado para calcular o tempo estimado de chegada (Estimated Time of
Arrival – ETA) do ônibus a todos os pontos de parada através de um algoritmo criado
pelos autores. As localizações em tempo real de todos os ônibus, histórico de rotas e estimativa de tempo de chegada podem ser observadas por WS ou app.
Mini (2013) propôs um FMS base que pode ser empregado para diferentes frotas com pequenas modificações. Essas frotas podem ser de ônibus, táxis ou veículos particulares. Para todos estes fins, a aplicação se dá por meio de dois apps distintos: um para o usuário e um instalado no veículo, que consiste em um VTS. O autor utilizou a plataforma Microsoft Azure para banco de dados e o GPS do smartphone para
desenvolver o sistema. Com o app, o usuário precisa entrar com um número de ID do veículo e selecionar um botão virtual na tela do smartphone para receber a localização. No caso da solução para ônibus, a ID corresponde a uma linha de ônibus, que pode conter mais de um veículo operando. Os ônibus são exibidos em mapa e, ao selecionar um ônibus específico, o usuário recebe informações de rota e tempo estimado do veículo até a posição do usuário. Para táxis, quando o usuário requisita o serviço, uma ID específica é criada e disponibilizada para o usuário rastrear o veículo somente durante a utilização do serviço. Para veículos particulares, diferentemente do app para táxis, a ID é única para o veículo do proprietário.
Chen et al. (2016) desenvolveram um FMS para uma frota de caminhões de coleta de lixo. Cada caminhão é equipado com uma unidade de bordo (On-Board Unit – OBU) que possui um módulo de GPS e um módulo GSM. A OBU reporta a localização a um WS para acusar a chegada a um ponto de coleta através de rede sem fio. Quando o ponto de coleta é alcançado, o FMS é comunicado pelo WS. O FMS é uma aplicação
web que provê dados de localização, ETA dos pontos de coleta dos veículos e um
mapa. O app foi desenvolvido para os residentes locais, clientes do sistema de coleta, poderem acessar dados de pontos de coleta e o ETA dos caminhões a esses pontos, baseada em histórico de dados.
Bobay et al. (2019) patentearam um método de pareamento entre smartphone e OBU para sistema antifurto. Uma OBU é implantada em um veículo e um dispositivo móvel permanece com o proprietário. Os equipamentos comunicam-se com um servidor central. A principal função do servidor é comunicar ao proprietário caso o veículo ultrapasse uma distância limite predeterminada. Outros eventos podem ser comunicados como: detecção de operação da ignição, tentativa de abertura de portas, quebramento de vidros, dependendo da disponibilidade de sensores utilizados e comunicação configurada com a OBU.
Lee e Ghalib (2017) patentearam um aparato e método para FMS voltado para serviços de compartilhamento de carros. Para isso, uma OBU é conectada à porta On-Board Diagnostics (OBD) II do veículo, que é um sistema de diagnóstico presente em grande parte dos veículos da atualidade. Os autores desenvolveram servidores específicos para clientes e veículos que se comunicam por rede celular sem fio com
um servidor central de reserva e aluguel de veículos. Desenvolveram, também, métodos de validação de acesso aos veículos. A OBU se comunica com o smartphone do cliente ou valida o acesso através de um leitor de cartões. Se o acesso for garantido, a OBU destrava a tranca da porta e a ignição, permitindo o uso do veículo. Ao término do serviço, o tempo inicial, final e a distância do trajeto são enviados para o servidor central.
Martin et al. (2019) patentearam um VTS para pagamentos de pedágios automáticos. Nesse sistema, o usuário da via com pedágio precisa de um dispositivo móvel para aferimento da localização, informações do veículo, ID do cliente e/ou veículo e data/hora. Os dispositivos móveis se comunicam com um servidor de telemática, e recebem informações de um servidor central sobre tarifas e localização das estações de pedágio. O servidor de telemática, então, calcula o pagamento a ser realizado pelo cliente com base nas estações cruzadas pelo veículo. Por fim, há um servidor dedicado a pagamentos que se comunica com o servidor central e com o dispositivo do cliente.
Outro VTS, que pode ser empregado para cobrança de pedágio e para controle de acesso, foi desenvolvido e patenteado por Elson et al. (2019). Nesse sistema, transceptores (beacons) são empregados nas laterais da via para comunicar-se com o smartphone do usuário através de um app desenvolvido, obtendo a ID e posicionamento do veículo. Para acesso à via, um cartão com QR code, previamente disponibilizado, é escaneado pelo smartphone, que se comunica com uma unidade de processamento do portão de entrada, responsável pela validação do acesso. A localização do veículo é baseada no GPS ativo do smartphone, que é aferida pelos transceptores na via. Os transceptores enviam informações de ID e data/hora para um servidor, que realiza o processamento para cobrança devida de pedágio ao usuário. Metlo et al. (2019) propuseram um sistema colaborativo de VTS para transportes coletivos. Nessa solução, um app instalado nos smartphones dos usuários envia informações de localização, velocidade e altitude para um servidor. Este, então, compara os dados de diferentes usuários para determinar a localização do veículo, e a exibe em um mapa no app. Essa solução tem a finalidade de proporcionar uma economia de recursos operacionais quando comparada a VTSs tradicionais.
A relação entre as soluções supracitadas pode ser vista no Quadro 1. Nota-se que a maioria das soluções utilizaram somente as tecnologias de interface gráfica, comunicação sem fio e GPS para implementação do FMS. Adicionalmente, a grande maioria das soluções foram desenvolvidas para OS Android. Todas as soluções possuem servidores web com WS e banco de dados.
Quadro 1 – Comparativo dos diferentes FMSs estudados (continua) Autor Tipo de documento Tecnologias de smarthphones
Tecnologias auxiliares OS mobile empregado
Finalidade
Lin et al. (2014) Artigo GPS; comunicação sem fio; UI
Google App Engine; MIT App Inventor; WS
Android VTS; histórico de rotas; mapeamento Fatima et al. (2019) Artigo GPS; comunicação sem fio; UI Amazon Cloud Computing; WS
Android Transporte coletivo; VTS; comunicação por mensagem; mapeamento
Ogbonna et al. (2016)
Artigo GPS; comunicação sem fio; UI
WS Android Transporte coletivo; histórico
de rotas; ETA
Mini (2013) Artigo GPS; comunicação sem fio; UI
Web app; Microsoft
Azure (base de dados)
Windows Phone
VTSs para diferentes tipos de frotas
Chen et al. (2016)
Artigo GPS; comunicação sem fio; UI
OBU (GPS + GSM); WS Android VTS; ETA; comunicação por mensagem; mapeamento Bobay et al. (2019) Patente GPS; comunicação sem fio; UI OBU; WS Não especificado VTS; sistema antifurto; sistema de alertas
Quadro 1 – Comparativo dos diferentes FMSs estudados (conclusão) Lee e Ghalib (2017) Patente GPS; comunicação sem fio; UI
OBU; OBD II; WS Não
especificado Compartilhamento de veículos; sistema de pagamentos e reservas Martin et al. (2019) Patente GPS; comunicação sem fio; UI; biometria; voz
OBU; OBD II; WS; unidade eletrônica nas estações de pedágio
Não
especificado
Pagamento de pedágios; cálculo de distância percorrida pelo veículo
Elson et al. (2019)
Patente GPS; comunicação sem fio (incluindo
bluetooth); UI; câmera Beacons; unidade eletrônica de controle de acesso; WS Não especificado Pagamento de pedágios; VTS; cálculo de distância percorrida e controle de entrada e saída de veículos
Metlo et al. (2019)
Artigo GPS; comunicação sem fio; UI; acelerômetro e magnetômetro
WS Android Transporte coletivo; sistema
colaborativo de VTS
3 MÉTODO
O método desenvolvido para este trabalho foi dividido em 11 partes, como pode ser observado no Quadro 2.
Quadro 2 – Etapas do método
Etapa Descrição Página
1 Tipo de Pesquisa 31
2 Definir o cenário de aplicação do FMS 31
3 Definir a funcionalidade do app 32
4 Definir a plataforma de desenvolvimento do app 33 5 Criar um banco de dados em nuvem para a armazenar as
informações de funcionários e serviços
33
6 Criar uma web app para adicionar a funcionalidade backend ao projeto
33
7 Criar um projeto em plataforma de computação em nuvem para consumir serviços de roteamento e mapeamento
34
8 Desenvolver um serviço de smartphone para aferir localização em segundo plano
34
9 Desenvolver UI e lógica do app para smartphone 35 10 Gerar relatórios para o administrador do FMS 35 11 Testar e avaliar a eficácia do FMS desenvolvido 35 Fonte: Elaborado pelo Autor (2021)
TIPO DE PESQUISA
De acordo com o as classificações propostas por Gil (2002), este trabalho configura-se como pesquisa exploratória e experimental, no qual busca-configura-se explorar o desenvolvimento de tecnologia através de um experimento. Trata-se, também, de uma pesquisa aplicada e com abordagem quantitativa, em que a análise dos dados coletados na pesquisa foi representada numericamente (PROVDANOV; FREITAS, 2013). Como um protótipo foi desenvolvido para este trabalho, aplica-se a definição metodológica Design Science, cunhada por Fuller (1957). Além disso, esse protótipo visa solucionar um problema real identificado e foi avaliado por meio de critérios científicos. Para tanto, artefatos existentes foram estudados para auxiliar a compreensão do problema de pesquisa e como resolvê-lo. Portanto, este trabalho enquadra-se na definição de Design Science Research (CAUCHICK-MIGUEL et al., 2019).
DEFINIR O CENÁRIO DE APLICAÇÃO DO FMS
O FMS desenvolvido busca atender à frotas veiculares de empresas de pequeno porte. Considerou-se, hipoteticamente, uma empresa que realiza operações de reparos residenciais, entregas, ou serviços similares, em locais específicos.
Os serviços prestados, bem com os integrantes da empresa possuem ID única. Cada serviço possui uma rota com local de partida e de chegada. Ao chegar no local de serviço, o operador da frota pode atender a um novo serviço ou voltar para a base da frota, sendo que a volta também é considerada como parte integral da rota. Ainda, a empresa recebe um valor em dinheiro pela distância percorrida, sendo uma tarifa especial para cada quilômetro excedente de quarenta quilômetros.
A frota desta empresa transita em uma região metropolitana. No caso deste trabalho, considerou-se a região metropolitana da Grande Vitória, composta dos municípios de Cariacica, Fundão, Guarapari, Serra, Viana, Vila Velha e Vitória. A região possui períodos de trânsito congestionado consideravelmente intensos, proporcionando diferentes cenários para predição de duração de trajetos e de opções de rotas. Optou-se por utilizar somente o smartphone como aparato para telemática veicular, a fim de
obter-se o menor custo possível para o sistema. Neste smartphone, um app desenvolvido conta com as funcionalidades pertinentes para o projeto.
DEFINIR A FUNCIONALIDADE DO APP
O app desenvolvido foi instalado em smartphones portados pelos operadores dos veículos. Baseando-se nos trabalhos relacionados, observados na seção 2.7, além de decisões de projeto do Autor, definiu-se as funcionalidades e capacidades do app como:
I. Permitir ao operador informar seu ID e senha para acessar o sistema;
II. Ser capaz de realizar a autenticação do acesso através de correspondência com base de dados em nuvem;
III. Permitir ao operador informar o ID do serviço, endereço de destino e possibilitar a partida através de botão virtual;
IV. Ser capaz de acessar serviços de mapeamento e roteamento em nuvem para adquirir estimativas de duração e distância do trajeto, dadas as condições de trânsito no momento da consulta;
V. Disponibilizar visualmente a rota a ser percorrida através de mapa interativo;
VI. Efetuar a aferição periódica de localização através do GPS do smartphone;
VII. Efetuar o cálculo da distância real percorrida pelo operador através da somatória da distância entres os pontos de localização aferidos do início ao fim da rota percorrida;
VIII. Permitir ao operador sinalizar a chegada ao destino através de botão virtual;
IX. Armazenar em nuvem as informações de ID do serviço, ID do operador, endereço de origem, endereço de destino, distância esperada do trajeto até o local de serviço, duração esperada do trajeto até o local de serviço, distância
total do trajeto, duração medida do trajeto, distância medida até o local de serviço, data/hora da partida e data/hora da chegada.
DEFINIR A PLATAFORMA DE DESENVOLVIMENTO DO APP
Devido a familiaridade do Autor e seu professor orientador com a linguagem C# e sistemas da Microsoft, optou-se por utilizar a plataforma Xamarin, integrada a IDE Visual Studio (versão gratuita para desenvolvedor). Além disso, Xamarin possui acesso a diversas bibliotecas e códigos compartilhados através dos pacotes NuGet (MICROSOFT CORPORATION, 2019b).
CRIAR UM BANCO DE DADOS EM NUVEM PARA A ARMAZENAR AS INFORMAÇÕES DE FUNCIONÁRIOS E SERVIÇOS
Uma base de dados foi criada para armazenar informações utilizadas pelo FMS. O banco de dados contém duas tabelas principais. A primeira contém os dados dos funcionários, já a segunda, contém os registros dos serviços realizados pelos funcionários com suas respectivas informações sobre as rotas desenvolvidas.
Para implementar essa base de dados, foram considerados os seguintes fatores: a base de dados deve estar armazenada de forma segura em nuvem e ser acessível a qualquer momento por todos os dispositivos empregados pelo sistema. Por isso, e pela facilidade de acesso a outros serviços integrados na nuvem, optou-se por utilizar um banco de dados SQL Azure.
CRIAR UMA WEB APP PARA ADICIONAR A FUNCIONALIDADE BACKEND AO PROJETO
Para realizar a leitura e escrita no banco de dados de forma segura, evitando-se expô-lo à Internet, um serviço na forma de web app foi criado, a fim de prover as funcionalidades backend. A Azure promove a criação de web apps e sua integração com o banco de dados através de Serviço de Aplicativo (MICROSOFT CORPORATION, 2020d). Este oferece a opção de realizar conexão com um projeto em repositório online. Rosas (2020) desenvolveu um template que aplica a leitura e escrita de banco de dados em JavaScript, que foi adaptado para a web app proposto para esse projeto. O Serviço de Aplicativo criado no Azure, em seu centro de
implantação, foi conectado à solução backend adaptada pelo autor. A utilização da
web app pelo sistema é de fácil acesso com auxílio o namespace Microsoft.WindowsAzure.MobileServices (MICROSOFT CORPORATION, 2020e).
CRIAR UM PROJETO EM PLATAFORMA DE COMPUTAÇÃO EM NUVEM PARA CONSUMIR SERVIÇOS DE ROTEAMENTO E MAPEAMENTO
Devido à alta disponibilidade e cobertura mundial, a Plataforma Google Maps foi escolhida para acessar serviços de roteamento e mapeamento para as aplicações propostas neste trabalho. Na plataforma, ao criar um projeto, o desenvolvedor recebe uma chave de acesso às diversas APIs disponíveis (API key). Para funcionalidade do app, os seguintes APIs foram utilizados:
• Distance Matrix API: utilizado para requisitar a distância esperada e duração esperada dos trajetos percorridos pelos operadores, considerando as condições de trânsito no momento da operação;
• Places API: a função Place Autocomplete foi utilizada para sugestão de endereço de destino ao operador, a fim de reduzir o tempo dessa operação, bem como a ocorrência de erros de entrada induzidos por digitação;
• Directions API: Utilizado para obtenção dos pontos de posicionamento da rota esperada no formato de polilinha codificada;
• Maps SDK para Android: utilizado para exibir um mapa interativo no app baseado no Google Maps.
As requisições feitas aos serviços da Plataforma Google Maps são realizadas a partir de um cliente HTTP configurado com auxílio do namespace System.Net.Http (MICROSOFT CORPORATION, 2020f). As respostas, em JSON, são desserializadas com auxílio da biblioteca Newtonsoft.json (NEWTONSOFT, 2020) para classes modelo em C#.
DESENVOLVER UM SERVIÇO DE SMARTPHONE PARA AFERIR LOCALIZAÇÃO EM SEGUNDO PLANO
Um app comumente não tem acesso permanente a localização via GPS a menos que esteja sempre sendo executado no plano principal do smartphone. Desta forma, para que o monitoramento de rotas não seja interrompido pelo sistema operacional do
smartphone, ou mesmo inadvertidamente pelo operador, um serviço para aquisição
de dados de localização quando o aplicativo se encontra em segundo plano foi desenvolvido. O mesmo utiliza GPS do smartphone, redes de celular e/ou redes WiFi (MICROSOFT CORPORATION, 2018a). Portanto, um serviço do tipo Foreground
Service (MICROSOFT CORPORATION, 2018b) foi desenvolvido, o qual realiza
tarefas em primeiro plano mesmo que o app esteja em segundo plano, com alta prioridade, e deve exibir notificações para o usuário. Esse serviço é iniciado quando um trajeto começa a ser percorrido e encerrado sempre que o trajeto é finalizado ou interrompido.
DESENVOLVER UI E LÓGICA DO APP PARA SMARTPHONE
O app foi desenvolvido como um projeto Xamrarin.Forms, de forma a atender todos os requisitos necessários para implementação do sistema. A UI foi criada em linguagem XAML e pode ser empregada em apps para Android e iOS. Propôs-se uma UI clara e intuitiva, com foco no minimalismo e na objetividade.
GERAR RELATÓRIOS PARA O ADMINISTRADOR DO FMS
Uma suíte de relatórios de informações foi criada a partir dos dados das rotas dos serviços armazenados na base dados. Esses relatórios são disponibilizados com o intuito de fornecer informações precisas para o gerente sobre as rotas percorridas por sua frota. Essa parte representa a função de gerenciamento do FMS.
Para implementação de relatórios de serviço, preferiu-se utilizar o próprio app desenvolvido. Ao requisitar acesso ao sistema, na página de login, o sistema busca no banco de dados informações do usuário. Caso este possua a função “Adm”, o acesso a página do gerente da frota (ManagerPage) é garantido.
TESTAR E AVALIAR A EFICÁCIA DO FMS DESENVOLVIDO
Para determinar a eficácia do sistema desenvolvido, trajetos similares àqueles desenvolvidos por potenciais operadores do app foram realizados pelo Autor em um automóvel de passeio típico. O app foi executado em um smartphone com OS Android. O hodômetro do veículo foi utilizado para aferir a distância real percorrida em um trajeto, com precisão típica de 0,1 km. Essa distância foi, então, comparada à distância
computada pelo app, bem como a distância esperada dada pelo serviço de nuvem da Google. Além disso, o tempo esperado do trajeto, fornecido pelo serviço em nuvem, foi comparado com o tempo real de viagem.
Para calcular o erro (𝑒) do sistema, foi calculada a média da porcentagem da diferença entre a distância medida entre o hodômetro do veículo (dhodo) e a distância medida pelo app (dapp) para n trajetos aferidos, vista na equação (1).
𝑒% = ∑ (|𝑑ℎ𝑜𝑑𝑜− 𝑑𝑎𝑝𝑝 𝑑ℎ𝑜𝑑𝑜 | ∙ 100) 𝑛 1 𝑛 (1) Além disso, realizou-se uma análise qualitativa, em que se observou se as informações sobre as rotas estão sendo armazenadas e disponíveis ao gerente da frota corretamente.
4 DESENVOLVIMENTO
BANCO DE DADOS EM NUVEM COM INFORMAÇÕES DE INFORMAÇÕES DE FUNCIONÁRIOS E SERVIÇOS
O banco de dados foi construído de acordo com as especificações da seção 3.5, e possui duas tabelas, observadas na Figura 9. A primeira tabela refere-se aos funcionários da empresa dona da frota e armazena dados pessoais, tais estes: CPF, função, nome, QRA (ID do funcionário), senha, status (se está operando ou não) e número de telefone. A segunda tabela abarca as informações de serviços e suas rotas, e sua estrutura de dados pode ser observada no Quadro 3 – Estrutura da tabela de serviços.
Figura 9 – DER para o banco de dados construído para este trabalho
Fonte: Elaborado pelo Autor (2021)
Duas classes espelho das tabelas do banco de dados implementado foram construídas para o projeto, e podem ser observadas na Listagem 1 e na Listagem 2. As classes espelho devem conter os mesmos nomes e tipos correspondentes às tabelas a qual se referem.
Quadro 3 – Estrutura da tabela de serviços
Informação do serviço Nome da coluna no
banco de dados Tipo de dado
Data/hora de chegada ao local do serviço
DATAHORA_CHEGADA Datetime
Data/hora de partida DATAHORA_SAIDA Datetime Duração esperada do trajeto
até o local de serviço
DURACAO_ESPERADA Nvarchar
Distância até o local de serviço KM_ATE_SERVICO Nvarchar Distância excedente de 40 km KM_CALCULADO Float Distância total percorrida KM_TOTAL Float Endereço do local de serviço LOCAL_CHEGADA Nvarchar
Endereço do local de partida LOCAL_SAIDA Nvarchar Endereço do local de volta LOCAL_VOLTA Nvarchar
ID do serviço NUMERO Int; Primary key
ID do operador do veículo QRA Int
Rota no formato de polilinha codificada
Rota Nvarchar
Ocorrência de volta VOLTA Nvarchar
Listagem 1 – Classe espelho da tabela Pessoa do banco de dados namespace RouteTrackerApp.Model
{
public class Pessoa {
//Classe espelho da tabela Pessoa no banco de dados
public string id { get; set; } public int QRA { get; set; } public string NOME { get; set; } public string CPF { get; set; } public string TELEFONE { get; set; } public string FUNCAO { get; set; } public int SENHA { get; set; } }
}
Fonte: Elaborado pelo Autor (2021)
Listagem 2 – Classe espelho da tabela Servico do banco de dados namespace RouteTrackerApp.Model
{
public class Servico {
//Classe espelho da tabela Servico no banco de dados
public string id { get; set; } public int NUMERO { get; set; }
public string DATAHORA_SAIDA { get; set; } public string DATAHORA_CHEGADA { get; set; } public string LOCAL_SAIDA { get; set; } public string LOCAL_CHEGADA { get; set; } public string VOLTA { get; set; }
public double KM_TOTAL { get; set; } public double KM_CALCULADO { get; set; } public int QRA { get; set; }
public string LOCAL_VOLTA { get; set; } public string DURACAO_ESPERADA { get; set; } public string DURACAO_CALCULADA { get; set; } public string Rota { get; set; }
public string KM_ESPERADO { get; set;} public string KM_ATE_SERVICO { get; set; } }
}
Fonte: Elaborado pelo Autor (2021)
WEB APP COM FUNCIONALIDADE BACKEND DO PROJETO
Uma web app foi criada a fim de realizar a comunicação entre o banco de dados e o app desenvolvido. Essa web app realiza quatro funções básicas pertinentes a manipulação de dados em banco de dados: inserir, deletar, atualizar e ler. Cada tabela do banco de dados possui um arquivo que implementa as funções supracitadas. No caso, têm-se Pessoa.js e Servico.js, ambas com o código observado na Listagem 3.
Listagem 3 – Código que implementa as funções básicas para manipular informações em banco de dados
var table = module.exports = require('azure-mobile-apps').table();
table.read(function (context) { return context.execute(); }); table.insert(function (context) { return context.execute(); }); table.update(function (context) { return context.execute(); }); table.delete(function (context) { return context.execute(); });
Fonte: Elaborado pelo Autor (2021)
Além disso, a Listagem 4 comporta o código com as configurações do servidor
server.js para implementação da funcionalidade backend do projeto. Neste, são
criadas as instâncias de aplicação Azure e as tabelas do banco de dados, além de estabelecer-se a comunicação entre eles.
No app desenvolvido, o namespace Microsoft.WindowsAzure.MobileServices é utilizado pra implementação da web app na solução. Na classe principal do app (App.xaml.cs), uma instância de cliente de serviço móvel (MobileServiceClient) é criada, em que se passa como parâmetro a URL da web app, como visto na Listagem 5. Observa-se, também, um exemplo de consulta empregando cliente instanciado ao utilizar o método GetTable para ler dados da tabela Pessoa.
Listagem 4 – Arquivo server.js com as configurações de servidor para a finalidade
backend do projeto
var app = require('express')(); // Create an instance of an Express app
var mobileApp = require('azure-mobile-apps')(); // Create an instance of a Mobile App with default settings
mobileApp.tables.add('Pessoa'); // Create a table for 'Pessoa' with default settings mobileApp.tables.add('Servico'); // Create a table for 'Servico' with default settings app.use(mobileApp);
app.listen(process.env.PORT || 3000); Fonte: Elaborado pelo Autor (2021)
Listagem 5 – Exemplo de utilização da web app no código do app desenvolvido //na arquivo App.xaml.cs
public static MobileServiceClient client = new
MobileServiceClient("https://routetracker.azurewebsites.net");
//exemplo de consulta utilizando o cliente configurado
await App.client.GetTable<Pessoa>().Where(u => u.QRA == qra).ToListAsync()).FirstOrDefault()
Fonte: Elaborado pelo Autor (2021)
CONSUMO DE SERVIÇOS DE MAPEAMENTO E ROTEAMENTO POR MEIO DE APIS DA PLATAFORMA GOOGLE MAPS
Os REST APIs da Plataforma Google Maps utilizados foram Distance Matrix, Places e Directions.
Primeiramente, para requisitar dados do API Distance Matrix, deve-se observar o formato da URI necessária, como no exemplo:
https://maps.googleapis.com/maps/api/distancematrix/json?&origins=IFES+Vitória&d estinations=IFES+Cariacica&language=pt-BR&departure_time=now&key={chave} Neste, deseja-se obter as informações de distância e duração de um trajeto entre o IFES Campus Vitória e o IFES Campus Cariacica, partindo no momento da requisição e inserindo a chave de desenvolvedor, omitida no exemplo propositalmente. A
resposta obtida, em JSON, encontra-se na Figura 10 – Resposta característica de uma requisição ao API Distance Matrix.
Figura 10 – Resposta característica de uma requisição ao API Distance Matrix
Fonte: Elaborado pelo Autor (2021)
Assim como para as tabelas do banco de dados, para armazenar as respostas das requisições ao Distance Matrix API, uma classe modelo foi construída. Utilizando a ferramenta JSON Utils, é possível obter a classe modelo em C# a partir de um código em formato JSON (“JSON Utils”, 2021). A Listagem 6 mostra a classe em C# obtida, além do objeto currentRoute utilizado para armazenar as informações da rota atual. Listagem 6 – Classe Routes criada para armazenar as respostas em JSON obtidas do Distance Matrix API
(continua) using System.Collections.Generic;
namespace RouteTrackerApp.Model {
public class Routes {
private static RouteInformation currentRoute = new RouteInformation(); public static RouteInformation CurrentRoute { get => currentRoute; set => currentRoute = value; }
