visualização de dados em um contexto de veículos inteligentes€¦ · coisas (iot), internet de...

Gabriel Lucas Albuquerque Maia Signoretti

Visualização de Dados em um Contexto deVeículos Inteligentes

Natal – RN

Dezembro de 2018


Visualização de Dados em um Contexto de VeículosInteligentes

Trabalho de Conclusão de Curso de Engenha-ria de Computação da Universidade Federaldo Rio Grande do Norte, apresentado comorequisito parcial para a obtenção do grau deBacharel em Engenharia de Computação

Orientador: Ivanovitch Medeiros Dantas daSilva

Universidade Federal do Rio Grande do Norte – UFRN

Departamento de Engenharia de Computação e Automação - DCA

Curso de Engenharia de Computação

Natal – RNDezembro de 2018


Visualização de Dados em um Contexto de VeículosInteligentes

Trabalho de Conclusão de Curso de Engenha-ria de Computação da Universidade Federaldo Rio Grande do Norte, apresentado comorequisito parcial para a obtenção do grau deBacharel em Engenharia de Computação

Orientador: Ivanovitch Medeiros Dantas daSilva

Trabalho aprovado. Natal – RN, 30 de Novembro de 2018:

Prof. Dr. Ivanovitch Medeiros Dantas da Silva - OrientadorUFRN

MSc. Marianne Batista Diniz da Silva - Membro Externo

MSc. Aguinaldo Bezerra - Membro Externo

Natal – RNDezembro de 2018

Dedico este trabalho a minha família e amigos

AGRADECIMENTOS

A minha família, por todo apoio e incentivo que me deram durante a minha vida ejornada acadêmica.

Ao meu amor, Letícia, que além de namorada é meu porto seguro e melhor amigapara todos os momentos. Obrigado por todo o carinho, companheirismo, paciência e amorque me ajudaram a passar por esse ciclo, principalmente nos momentos mais difíceis. Semvocê esse processo não teria sido possível.

Aos meus grandes amigos Fernando, Bruno, Victor Hugo, Luiz, Lucas, Mozart,Karina, Raul, Yuri e Yago, com quem sei que posso contar em qualquer situação. Passamospor muitas coisas juntos desde o colégio, dividimos momentos de alegrias e angústias econtinuamos firmes durante o encerramento dessa nova fase de nossas vidas.

Ao meu orientador Prof. Dr. Ivanovitch Dantas da Silva e a minha co orientadoraMSc. Marianne Diniz pela oportunidade de trabalho, toda a orientação e estímulo quetornaram possível a realização deste trabalho.

Aos meus sócios e amigos Miguel e Álvaro pela paciência, suporte e encorajamentoque me levam a buscar fazer sempre um pouco mais.

A todos os demais que de alguma forma influenciaram minha vida acadêmica.

“Eu posso não ter ido aonde eu pretendia ir,mas eu acho que acabei onde eu precisava estar"

(Douglas Adams)

RESUMOTem-se observado um constante crescimento do mercado automotivo nos últimos anosimpulsionado principalmente pelo surgimento de novas tecnologias e tendências. A pardeste crescente reconhecimento, a chamada Internet dos Veículos Inteligentes (IoIV) surgecomo uma evolução da Internet das Coisas (IoT) aplicada ao setor automotivo. Diantedesse contexto, possibilita-se a criação de um ciclo de feedback ao cliente e à indústriaatravés da coleta e análise de dados, tornando viável a criação de valor durante todo o ciclode vida do produto. Aliado a isso, vem sendo cada vez mais necessário o uso de ferramentasespecializadas para a visualização e análise do grande volume de dados gerados por essessistemas. A ferramenta proposta no presente trabalho busca facilitar a tarefa de coleta,limpeza e formatação dos dados do veículo obtidos através da porta OBD-II (On-BoardDiagnostics). A partir desses dados são gerados gráficos e mapas a fim de obter um melhorentendimento sobre o funcionamento do veículo e insights em relação sua performance epossíveis problemas, tal como possibilitar que análises mobilidade urbana sejam realizadaseficientemente.

Palavras-chaves: Veículos Inteligentes, OBD-II, Visualização de Dados, Ciência de Dados.

ABSTRACTThere has been a steady growth in the automotive market in recent years driven mainlyby the emergence of new technologies and trends. Along with this growing recognition,the so-called Internet of Intelligent Vehicles (IoIV) emerges as an evolution of the Internetof Things (IoT) applied to the automotive sector. Given this context, it is possible tocreate a cycle of customer and industry feedback through the collection and analysis ofdata, making it feasible to create value throughout the product’s life cycle. Allied tothis, it is increasingly necessary to use specialized tools to view and analyze the largeamount of data generated by these systems. The tool proposed in the present work seeksto facilitate the task of collecting, cleaning and formatting vehicle data obtained throughthe OBD-II (On-Board Diagnostics) port. From these data, it is sought to generate graphsand maps in order to gain a better understanding of the vehicle’s operation and generateinsights regarding its performance and possible problems, as well as to allow urban mobilityanalyzes to be performed efficiently..

Keywords: Intelligent Vehicles. OBD-II. Data Visualization, Data Science.

LISTA DE ILUSTRAÇÕES

Figura 1 – Conexão Veicular. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18Figura 2 – Visão Geral da Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . 19Figura 3 – Arquivos da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Figura 4 – Árvore de Componentes . . . . . . . . . . . . . . . . . . . . . . . . . . 31Figura 5 – Fluxograma de funcionamento . . . . . . . . . . . . . . . . . . . . . . . 34Figura 6 – Interface da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . 35Figura 7 – Elementos da Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . 36Figura 8 – Trajetórias de diferentes carros e dias . . . . . . . . . . . . . . . . . . . 36Figura 9 – Camada de mapa de calor . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 10 – Estilos de Mapa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

LISTA DE TABELAS

Tabela 1 – Modos de Operação do OBD-II. . . . . . . . . . . . . . . . . . . . . . . 18Tabela 2 – Estados da aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

LISTA DE ABREVIATURAS E SIGLAS

IoT Internet of Things

IoIV Internet of Intelligent Vehicles

OBD-II On-Board Diagnostic II

ECU Engine Control Unit

CAN Controller Area Network

DLC Data Link Connector

PID Parameter ID

API Application Programming Interface

REST Representational State Transfer

GUI Graphical User Interface

JSON JavaScript Object Notation

SUMÁRIO

1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.1 Contextualização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3 Objetivos: Geral e Específicos . . . . . . . . . . . . . . . . . . . . . . 141.4 Estrutura do Trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2 REFERENCIAL TEÓRICO . . . . . . . . . . . . . . . . . . . . . . . 162.1 Internet das Coisas (IoT) . . . . . . . . . . . . . . . . . . . . . . . . . 162.2 Internet de Veículos Inteligentes (IoIV) . . . . . . . . . . . . . . . . . 162.3 OBD-II . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.4 SmartFleet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.5 Ciência de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.6 Trabalhos Relacionados . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3 METODOLOGIA . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223.1 Classificação da Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . 223.2 Instrumentação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.1 React.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233.2.2 Deck.gl . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.3 Mapbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253.2.4 React-Vis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4 DESENVOLVIMENTO . . . . . . . . . . . . . . . . . . . . . . . . . 274.1 Funcionamento da Aplicação . . . . . . . . . . . . . . . . . . . . . . . 284.1.1 Gráficos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314.1.2 Camadas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.1.3 Painel de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2 Fluxograma do Funcionamento . . . . . . . . . . . . . . . . . . . . . . 33

5 RESULTADOS E DISCUSSÕES . . . . . . . . . . . . . . . . . . . . 35

6 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.1 Dificuldades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.2 Trabalhos Futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 396.3 Contribuições Relacionadas ao Trabalho . . . . . . . . . . . . . . . . 406.3.1 Artigos Aprovados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

13

1 INTRODUÇÃO

Este Capítulo descreve o contexto e as principais motivações que levaram aodesenvolvimento deste trabalho. Na seção 1.1 a contextualização da temática desse estudoé apresentada. Na seção 1.2, a motivação que levou ao desenvolvimento dessa. Na seção 1.3,os objetivos, gerais e específicos. Por fim, na seção 1.4 é apresentada a estrutura definidapara a elaboração deste estudo.

1.1 ContextualizaçãoCom a rápida popularização dos carros na segunda metade do século XX, agências

como o Comitê de Gerenciamento de Recursos Aéreos da Califórnia (CARB) e a Agênciade Proteção Ambiental (EPA) começaram a estabelecer uma serie de normas e resoluçõespara o controle de emissão de poluentes. Com isso, foi impulsionado o desenvolvimentode um sistema automotivo capaz de realizar um autodiagnóstico no veículo e alertar omotorista sobre possíveis falhas em componentes eletrônicos ou em sistemas de controlede emissão de poluentes (OLIVEIRA et al., 2017).

Nasce assim o sistema OBD-II (do inglês, On-Board Diagnostic), que passou a serobrigatório em todos os veículos fabricados e vendidos nos Estados Unidos a partir de 1996.Posteriormente, em 2003, a União Europeia adotou uma medida semelhante, enquanto oBrasil, a Rússia e a China seguiram a tendência em 2010 (OLIVEIRA et al., 2017). Desdeentão os carros e o sistema tem evoluído constantemente, possibilitando a leitura de cadavez mais sensores.

Paralelamente a isso, observa-se um crescimento exponencial no volume de dadosgerados anualmente no mundo, e estima-se que em 2020 tenhamos gerado algo em tornode 35 trilhões de gigabytes de dados (GIACALONE; SCIPPACERCOLA, 2016). Essecrescimento tende a ficar cada vez mais acelerado com o surgimento de tecnologias comoInternet das Coisas (do inglês, Internet of Things (IoT)) , que prometem conectar milharesde dispositivos a Internet nos próximos anos.

É nesse contexto que a ideia de Internet de Veículos Inteligentes (do inglês, Internetof Intelligent Vehicles (IoIV)) começa a surgir como uma extensão do paradigma estabele-cido pelo IoT. Assim é possível observar o surgimento de carros conectados que podemenviar e receber informações pela Internet. Com auxilio de dispositivos como o OBD-II, épossível coletar os dados gerados pelos sensores embarcados e transmiti-los a um servidorremoto em tempo real.

Capítulo 1. Introdução 14

1.2 MotivaçãoDiante desse contexto progressivamente mais conectado, vem sendo necessário o

uso de ferramentas especializadas para a visualização e análise dos dados gerados por essessistemas de forma clara e eficiente. Somente os dados brutos analisados no formato detabela não fornecem todas as informações e muitas vezes uma análise mais aprofundada setorna inviável devido ao grande volume e quantidade de variáveis.

Dessa forma, a ferramenta proposta no presente trabalho busca facilitar a tarefa decoleta, limpeza e formatação dos dados do veículo obtidos através da porta OBD-II. A partirdesses dados busca-se gerar gráficos e mapas a fim de ganhar um melhor entendimentosobre o funcionamento do veículo e gerar insights em relação sua performance e possíveisproblemas.

1.3 Objetivos: Geral e EspecíficosEsta pesquisa tem como objetivo geral propor uma ferramenta de interface para

visualização de dados no contexto de IoIV.

Para atingir o objetivo geral, decorrem como necessários os seguintes objetivosespecíficos:

a) Coleta dos dados obtidos por meio de dispositivos OBD-II;

b) Limpeza e pré processamento dos dados para melhor manipulação;

c) Análise e visualização dos dados coletados por meio de ferramentas gráficas e demapeamento;

1.4 Estrutura do TrabalhoEste trabalho tem a estrutura dividida em capítulos, inicia-se com o Capítulo 1

abordando toda a parte introdutória da pesquisa, por meio da apresentação da introdução,contextualização, motivação, objetivos, e esta estrutura. O Capítulo 2 tem por objetivoapresentar e aprofundar um pouco mais os conceitos envolvidos no desenvolvimento dapesquisa. São eles: OBD-II, internet das coisas (IoT), internet de veículos inteligentes(IoIV), plataforma SmartFleet, ciência de dados e, por fim, trabalhos relacionados relevantesao nosso tema. O Capítulo 3 descreve a metodologia adotada para este trabalho de pesquisa,onde é apresentada a classificação da pesquisa quanto a sua natureza, quanto à abordagemdo problema, o objetivo e os procedimentos técnicos adotados no seu desenvolvimento. NoCapítulo 4 é apresentado o desenvolvimento desta pesquisa e todo o seu detalhamento.

Capítulo 1. Introdução 15

No Capítulo 5, apresenta-se a análise e interpretação dos resultados. Por fim, no Capítulo6 são apresentadas as conclusões deste estudo, incluindo as dificuldades encontradas epossíveis trabalhos futuros.

16

2 REFERENCIAL TEÓRICO

Neste capítulo são apresentados os principais conceitos relacionados a Internet dasCoisas (IoT), Internet de Veículos Inteligentes (IoIV), OBD-II, plataforma SmartFleete Ciência de Dados. Com isso, teremos um melhor entendimento sobre o contexto daelaboração deste trabalho.

2.1 Internet das Coisas (IoT)A Internet das Coisas surgiu por meio dos avanços tecnológicos em áreas como:

sistemas embarcados, microeletrônica, comunicação e sensoriamento. Atualmente a IoTtem recebido bastante atenção tanto da academia quanto da indústria devido ao seupotencial de uso nas mais diversas áreas de atividades humanas (ZANELLA et al., 2014).

A IoT possibilita a troca de informações entre objetos e plataformas (ATZORI;IERA; MORABITO, 2010; GUBBI et al., 2013; ZANELLA et al., 2014), promovendomodelos de negócios inovadores e novas experiencias de usuário por meio de forte conectivi-dade (SADEGHI; WACHSMANN; WAIDNER, 2015). Este paradigma emergente englobauma infra-estrutura de hardware, software e serviços que permitem a interconexão entregrandes volumes de "coisas"inteligentes distribuídas e heterogêneas, permitindo que elas secomuniquem de forma intuitiva com o usuário (ZANELLA et al., 2014; HROMIC et al.,2015; SHU et al., 2017; LI et al., 2017).

Sabe-se que a IoT é uma das tecnologias mais comuns e amplamente utilizada paraa formação de ambientes inteligentes baseados em sensores (GILL et al., 2018). Atualmente,a IoT vem sendo implementada nos mais variados setores, incluindo o monitoramentourbano e ambiental, produção, manufatura, saúde, automação residencial, transporte, entremuitos outros. A ideia chave por trás da IoT é a comunicação maquina a maquina, na qualcada dispositivo é conectado a rede e podem trocar informações como leitura de sensores,por exemplo (GILL et al., 2018; WU et al., 2018).

2.2 Internet de Veículos Inteligentes (IoIV)A Internet de Veículos Inteligentes é um novo paradigma de conexão de veículos

que integra muitos recursos importantes provenientes do paradigma introduzido por IoT(DANDALA; KRISHNAMURTHY; ALWAN, 2017; WU et al., 2018). Porém, somadoa esses recursos, pretende oferecer uma série de novos serviços, tais como: sistemas degestão de frota, melhoria da segurança veicular, consumo eficiente de energia e combustível,

Capítulo 2. Referencial Teórico 17

planejamento de tráfego, redução de acidentes e, em outra frente tecnológica, é umaimportante ferramenta para a operação de veículos autônomos (SUGAYAMA; NEGRELLI,2017).

Os veículos fabricados hoje em dia contam com diversos sensores embarcadosque podem ser utilizados para monitorar dados como velocidade, temperatura de motor,funcionamento de freios, e uma série de outras variáveis. Além disso, a maioria dessesveículos pode ser conectado a vários tipos de dispositivos (sensores, telefones, câmeras)por meio de protocolos de comunicação sem fio e mídias de transmissão (CONTRERAS-CASTILLO; ZEADALLY; IBáñEZ, 2017; GANTI; YE; LEI, 2011).

A comunicação do veículo em IoIV está sendo derivada através de redes ad-hocveiculares (VANETs) (TALIB; HUSSIN; HASSAN, 2017; CHOWDHARY; KAUR, 2017),que são redes móveis destinadas a comunicação entre carros e o meio externo (CHENet al., 2009; PU et al., 2016). Assim, usando essa abordagem, os servidores remotos decontrole de IoT podem monitorar qualquer um dos veículos em movimento em tempo reale o rastreamento pode ser feito em vários parâmetros (GILL et al., 2018).

2.3 OBD-IIO OBD-II é um sistema conectado à Unidade de Controle do Motor (do inglês

Engine Control Unit (ECU)) do veículo, provendo uma interface de comunicação com oveículo que permite a leitura e transmissão em tempo real dos dados aferidos pelos sensorese atuadores embarcados.

Essa interface permite conexão com veículo por meio de diferentes protocolos, noentanto, em geral, cada veículo implementa apenas um deles. No momento o protocolo maisutilizado é o CAN (do inglês, Controller Area Network), que foi criado pela Bosh em 1980.Sua criação teve como principal objetivo permitir a comunicação entre diferentes ECUs.No entanto, além desse protocolo, existem muitos outros que são utilizados atualmente,como: SAE J1850 PWM, SAE J1850 VPW, ISO 9141-2 e ISO 14230 KWP2000 porexemplo (BAEK; JANG, 2015).

Para acessar os dados fornecidos pelo veículo utiliza-se um conector de interfaceOBD-II conhecido como DLC (do inglês, Data Link Connector). Um DLC possui 16pinos e é utilizado em praticamente todos os veículos produzidos a partir de 1996. Dessaforma, podem ser utilizados scanners OBD (também referidos por “adaptadores”), que sãodiretamente conectados ao DLC e agem como intermediários, permitindo a comunicaçãode aplicações externas com o veículo, conforme mostrado na Figura 1 (a,b) .


(a) Comunicação do OBD-II com a ECU. (b) OBD-II conectado ao veículo.

Figura 1 – Conexão Veicular.

Fonte – (SILVA et al., 2018)

A tecnologia OBD-II conta com 10 modos de operação, em que cada um é destinadoa uma finalidade específica. Cada um deles possui uma série específica de comandosdisponíveis para retornar os dados dos sensores e atuadores presentes no veículo (OLIVEIRAet al., 2017). Para requisitar esses dados são utilizados códigos denominados PIDs (do inglês,Parameter IDs). No entanto, as montadoras não são obrigadas a disponibilizar suportepara todos os modos de operação em seus veículos, fazendo-se necessária a decodificaçãodos comandos suportados pelo automóvel em questão. A Tabela 1 sintetiza a finalidade decada um dos modos de operação do OBD-II.

Tabela 1 – Modos de Operação do OBD-II.

Modo Descrição01 Retorna os dados da ECU tempo real.02 Requisita os dados da ECU correspondentes à última falha.03 Exibe os códigos de erro armazenados no veículo.04 Limpa os códigos de erro armazenados.05 Retorna os resultados dos testes dos sensores de oxigênio presentes no veículo.06 Retorna os resultados dos testes relacionados ao monitoramento não-contínuo.07 Retorna os resultados dos testes relacionados ao monitoramento contínuo.08 Requer o controle dos sistemas de bordo.09 Obtém informações do veículo.10 Exibe os códigos de erro com status permanente.



2.4 SmartFleetA plataforma de IoIV SmartFleet permite que, a partir da integração com disposi-

tivos externos, seja possível conectar veículos à Internet, fornecendo funcionalidades dearmazenamento, visualização e análise de dados em tempo real (SILVA et al., 2018).

A arquitetura dessa plataforma conta com os seguintes módulos, ilustrados naFigura 2:

Figura 2 – Visão Geral da Arquitetura


a) Módulo de conexão veicular: visa conectar a ECU do veículo aos outros disposi-tivos da plataforma através de um adaptador OBD-II;

b) Módulo de captura de dados: aplicativo móvel que conecta-se via Bluetooth aohardware OBD-II, obtém os dados dos sensores veiculares e os envia para o servidorremoto. Isso é feito através de conexão GPRS (General Packet Radio Service) ouWi-Fi com o módulo de armazenamento de dados. É possível combinar os dadosobtidos da ECU com dados do próprio smartphone, como leituras de acelerômetro egeolocalização, por exemplo.

c) Módulo de armazenamento de dados: possui a responsabilidade de armazenaros dados e tornar-los disponíveis para as aplicações de análise por intermédio deuma API REST (do inglês, Representational State Transfer).

No contexto deste trabalho foi usado o módulo de armazenamento de dados, apartir do qual foram obtidos os dados necessários para o desenvolvimento do sistema pormeio de requisições à API.

2.5 Ciência de DadosCiência de Dados (do inglês Data Science) é uma junção de estatística e ciência da

computação, buscando unir conhecimentos desses dois campos para abordar as necessidadesatuais de análise de grandes conjuntos de dados (BLEI; SMYTH, 2017). Atualmentecientistas das mais diversas áreas se deparam com grandes conjuntos de dados e, mesmo


confiantes que há valor a ser explorado, ainda não conseguem tomar proveito total devidoa limitações técnicas ou conceituais (BLEI; SMYTH, 2017).

Esse vasto volume de dados tem gerado uma grande reformulação e mudança deparadigma nas mais diversas áreas da ciência. Essa mudança não é somente impulsionadapelos dados em si, mas pela perspectiva de tudo que pode ser criado ou melhor entendidopor meio de sua exploração e análise, podendo gerar grande valor econômico e social (CAO,2017).

Entretanto, trabalhar com esses dados gera novos desafios, entre eles podemos citara necessidade de novos mecanismos para visualização de dados. A visualização de dados,por sua vez, é a área de estudo que busca gerar representações visuais significativas deconjuntos de dados, possibilitando obter novos insights e a descoberta de novos padrões(BRIGHAM, 2016).

2.6 Trabalhos RelacionadosAtualmente foram encontrados poucos trabalhos que unissem visualização de dados

com IoIV e OBD-II. Porém, dentre os trabalhos encontrados no campo de visualização dedados veiculares, apresentamos alguns nos próximos parágrafos.

Em (MALEKIAN et al., 2017) os autores descrevem um sistema de gerenciamentode frota que visa medir velocidade, distância, consumo de combustível e dados de geolocalização por meio de um OBD-II. Esses dados são enviados a um servidor que implementauma interface de usuário básica para ajudar na visualização e análise.

Já (BRöRING et al., 2015) propõe uma interface web especificamente voltada paramanipulação de dados veiculares de forma colaborativa para monitoramento de trafego ede fatores ambientais. o Sistema, chamado de enviroCar, é composto de um aplicativo queconecta-se a um OBD-II para coletar os dados e os enviar para um servidor. Posteriormenteesses dados são processados e disponibilizados em aplicativos de mapeamento acessíveispor meio de uma interface de usuário interativa.

Em outra frente, (CHEN et al., 2015) sugerem um método de visualização de dadosde tráfego independente de dados coletados a partir de sistemas de GPS veiculares. Em vezdisso, os autores sugerem que o monitoramento seja feito a partir de estações detectorasde veículos. Com isso, os dados temporais estáticos coletados em pontos chave da cidadepodem ser muito úteis, ajudando analistas a preverem fluxos de tráfego, examinar a eficáciade um controle de tráfego e avaliar a taxa de utilidade de segmentos rodoviários.

Adicionalmente, (FERREIRA et al., 2013) faz um estudo em relação a conjuntosde dados contendo origens e destinos de viagens. Esse tipo de dado é bastante complexo,pois contem informações geográficas e temporais, além de múltiplas variáveis associadas


a cada viagem. O estudo foca em dados relacionados a viagens de táxi em Nova York ebusca criar um modelo que permita aos usuários consultar visualmente esses dados. Dessaforma, além de consultas analíticas, o sistema suporta consultas de origem e destino quepodem tornar mais fácil a realização de estudos de mobilidade urbana em toda a cidade.

Por fim, temos (TOMINSKI et al., 2012), onde os autores propões uma solução paravisualizações de trajetórias em seu contexto espaço-temporal. Esse tipo de visualizaçãoé complexa pois, além de lidar com dados espaciais e temporais, tem-se que observar osvalores individuais dos atributos em cada ponto do percurso. No modelo proposto pelosautores, os pontos das trajetórias podem ser empilhados tridimensionalmente em cima deum mapa 2D de acordo com a temporalidade, ao longo das quais os valores dos atributosde interesse são codificados por cor.

Dentre os trabalhos apresentados, nenhum engloba todas as características daferramenta proposta nesta pesquisa. Os trabalhos (CHEN et al., 2015; FERREIRA et al.,2013; TOMINSKI et al., 2012) propõem interfaces de visualização complexas, porém nãoutilizam diretamente dados provenientes do OBD-II; Já em (MALEKIAN et al., 2017)os autores fazem uso do sistema OBD-II mas disponibilizam uma interface de usuáriosimples e sem presença de um mapa; Por fim, em (BRöRING et al., 2015) é apresentadaa plataforma mais completa e similar a proposta nesta pesquisa: os autores tanto fazemuso do OBD-II para coletar os dados quanto disponibilizam uma interface de visualizaçãobastante completa. A diferença neste caso vem do fato da plataforma ser voltada paraanálise de fatores ambientais, o que não se caracteriza como foco primário do presentetrabalho.

22

3 METODOLOGIA

Este Capítulo apresenta a descrição da metodologia adotada para este trabalho depesquisa. Na Seção 3.1, apresenta-se a classificação da pesquisa quanto a sua natureza, abor-dagem do problema, objetivo e procedimentos técnicos adotados no seu desenvolvimento.Na Seção 3.2, descreve-se a instrumentação utilizada na pesquisa.

3.1 Classificação da PesquisaEste trabalho pesquisa tem como objetivo propor uma interface para visualização

de dados no contexto de IoIV. A coleta de dados para visualização foi feita a partir de umdispositivo OBD-II conectado ao veículo, com informações em tempo real. Neste contextobuscou-se obter uma melhor compreensão dos dados disponibilizados pelo veículo.

Quanto à natureza da pesquisa, podemos classificá-la como básica ou aplicada.Para Silva e Menezes (2005), pesquisa básica objetiva gerar conhecimentos novos úteispara o avanço da ciência sem aplicação prática prevista. Envolve verdades e interessesuniversais. Enquanto que, pesquisa aplicada objetiva gerar conhecimentos para aplicaçãoprática e dirigidos à solução de problemas específicos. Envolve verdades e interesses locais.Com base nisso, a nossa pesquisa é classificada como aplicada, ou seja, é voltada para aresolução de um problema específico, que tem como finalidade uma melhor visualizaçãodos dados capturados.

Quanto aos tipos de abordagem dos dados, Silva e Menezes (2005) classificamoscomo pesquisa quantitativa ou qualitativa. Eles definem como quantitativa a pesquisaque pode ser quantificável, ou seja, que pode ser traduzida em números e que podeutilizar de alguma forma análises estatísticas, para análises e classificações. Silveira eCórdova (2009) definem pesquisa qualitativa como uma pesquisa que não se preocupa comrepresentatividade numérica, mas sim com a compreensão profunda de uma organização.A nossa pesquisa se classifica como qualitativa e quantitativa, pois analisamos em primeiromomento quantitativamente os dados coletados pelo veículo, e depois, a partir dos resultadosobtidos com a visualização obteve-se um melhor entendimento sobre o comportamento doscondutores e utilização das vias.

Quanto aos objetivos, uma pesquisa pode ser classificada como exploratória descri-tiva ou explicativa. A presente pesquisa é caracterizada como explicativa, pois segundoGil(2007), este tipo de pesquisa preocupa-se em identificar os fatores que determinam ouque contribuem para a ocorrência dos fenômenos. Como nesta pesquisa, em que busca-seestudar os dados capturados e definir padrões ou até mesmo prevenções e mitigação de

Capítulo 3. Metodologia 23

diferentes problemas que possam ocorrer no veículo.

Quanto aos procedimentos técnicos utilizados para desenvolver a pesquisa, estetrabalho é caracterizado como pesquisa de campo. Segundo Gil (2007), este tipo de pesquisapretende buscar a informação diretamente com a população pesquisada, ou seja, exige dopesquisador um encontro mais direto. Nesse caso, o pesquisador precisa ir ao espaço onde ofenômeno ocorre, ou ocorreu e reunir um conjunto de informações a serem documentadas.

3.2 InstrumentaçãoNesta seção são apresentadas as ferramentas e tecnologias utilizadas para a cons-

trução desta pesquisa, sendo elas:

a) React.js

b) Deck.gl

c) Mapbox

d) React-Vis

O funcionamento de cada uma dessas ferramentas será discutido com mais detalhesnas subseções a seguir.

3.2.1 React.js

React.js 1 é uma biblioteca para a linguagem JavaScript usada para o desenvolvi-mento de interfaces de usuário dinâmicas e aplicações web. Atualmente é mantido peloFacebook e por uma vasta comunidade de desenvolvedores, além de ser amplamente usadana indústria da tecnologia.

Aplicações construídas com esse framework são baseadas em componentes isolados ereutilizáveis que, quando combinados, podem formar interfaces de usuário mais complexas.Todos os elementos que são renderizados na tela são componentes, como botões, camposde texto, listas, etc.

Esses componentes são classes ou funções escritas em JavaScript que contém tantoo código necessário para sua renderização quanto a lógica usada para reagir a interaçõesdo usuário e mostrar conteúdo dinamicamente e de forma responsiva.

Cada aplicação React tem pelo menos um componente, chamado de root compo-nent, ou componente raiz, em tradução livre. Esse componente contém todos os outros

1https://reactjs.org/


componentes como filhos, formando uma árvore cujo a profundidade aumenta com acomplexidade da aplicação e a quantidade de componentes necessários para formá-la.

Os componentes são criados de maneira declarativa, definindo-se como os mesmosdevem reagir a um conjunto de estados, alterado a forma como são renderizados a cadamudança. Por isso a biblioteca se chama React (que pode ser traduzido como Reagir), poisos elementos reagem a mudanças de estados.

Para que seja possível unir a lógica de renderização com os demais elementos doscomponentes em um único arquivo JavaScript, deve-se usar de uma extensão de sintaxechamada JSX. Com ela é possível utilizar tags similares as usadas em HTML, porémdentro do próprio código JavaScript.

Além disso, os componentes possuem alguns elementos que merecem destaque,como por exemplo:

a) Props: propriedades (ou parâmetros) que são passados ao componente na hora desua chamada. Podem ser estados, variáveis, funções, outros componentes ou qualqueroutro elemento que seja necessário;

b) Callbacks: funções do componente pai que são passadas ao componente filho naforma de props para serem chamadas caso algum evento específico aconteça dentrodo componente, como por exemplo o apertar de um botão;

c) Filhos: outros componentes que são passados na forma de props para serem rende-rizados dentro do componente, possibilitando que criemos componentes cada vezmais complexos compostos de diversos sub componentes mais simples;

d) Estado: variável de classe que define os parâmetros que compõem uma espécie decontexto atual do componente, como por exemplo o texto sendo digitada em umcomponente de entrada. O estado é a forma que o componente guarda informaçãodurante seu ciclo vida. Sempre que o estado é alterado, o método render é chamadopara que o componente seja re renderizado na tela em resposta a essa mudança.

e) Funções de Ciclo de Vida: métodos da classe que são chamados sempre queeventos relacionados ao ciclo de vida do componente acontecem e.g. o componentefoi montado, ou o componente irá receber novas props;

f) Função Render: método da classe onde é definido a estrutura do componente quedeve ser renderizada na tela. Aqui são usadas as tags JSX mencionadas anteriormente

Em resumo, podemos dizer que componentes são como funções JavaScript arbitrárias:recebem props como inputs, reagem a esses inputs, alterando seu estado de alguma forma


e retornam um conjunto de tags JSX contendo os elementos que devem ser renderizadosna tela.

Tanto o Deck.gl quanto React-Vis foram desenvolvidos baseados em React.js, deforma que se torna mais fácil a sua integração com páginas e aplicativos web desenvolvidosno mesmo framework. Por essa razão foi decidido por usar essas tecnologias para odesenvolvimento da interface de visualização de dados.

3.2.2 Deck.gl

O Deck.gl 2 é uma ferramenta de alto desempenho baseada em WebGL usada paraanálise visual e exploratória de grandes conjuntos de dados que contenham informaçõesgeo espaciais. Essa é uma de muitas bibliotecas que compõem um ecossistema de códigoaberto desenvolvido pelo time de engenharia da Uber, chamado de vis.gl 3.

Usado em conjunto com Mapbox, possibilita a criação de mapas interativos comvisualizações de dados complexas. Para isso o Deck.gl faz uso de uma abordagem na formade camadas de visualizações que ficam sobrepostas e empilhadas em um único mapa. Dessaforma, viabiliza a geração de diversas visualizações customizadas em um único mapa deforma otimizada e eficiente.

Cada uma dessas camadas tem uma série de parâmetros que podem ser configu-rados para customizar as visualizações geradas. Dentre as camadas já existentes pode-sedestacar as duas utilizadas para o desenvolvimento da aplicação proposta: A camadaScatterplotLayer, que permite plotar pontos individuais no mapa e a HexagonLayer, quepermite a agregação de pontos nas diferentes regiões do mapa. Além disso, as camadaspodem ser combinadas e modificadas em uma infinidade de maneiras, possibilitando acriação de visualizações únicas e impressionantes.

Por fim, a ferramenta pode ser facilmente incorporada em aplicações React, bastaque o modulo Deck.gl seja importado e usado como um componente dentro da aplicaçãoem questão.

3.2.3 Mapbox

Mapbox 4 é uma plataforma usada para auxiliar na criação de aplicativos queutilizem dados e análise espacial, fornecendo mapas estáticos que podem ser usados comobase nas visualizações. Assim como as demais ferramentas usadas nesse trabalho, mapasfornecidos pelo Mapbox são facilmente integrados a aplicações React, bastando importaros módulos necessários e realizar um cadastro para receber um token de acesso a API.

2http://deck.gl3http://vis.gl/4https://www.mapbox.com/


Além disso, é possível selecionar entre uma variedade de designs disponibilizadospela plataforma, assim como customizar e criar novos estilos personalizados com o MapboxStudio 5.

3.2.4 React-Vis

Por fim, o React-Vis 6 é outra biblioteca de código aberto do ecossistema desenvol-vido pelo time vis.gl. Ela pode ser usada para renderizar gráficos interativos e, assim comoo Deck.gl, também segue os mesmos paradigmas usados pelo React, disponibilizando umasérie de componentes para geração de gráficos customizados facilmente integrados a umaaplicação React como qualquer outro componente.

O ponto alto do uso dessa biblioteca é a possibilidade de gerar interações dinâmicasentre os gráficos e outros componentes do ecossistema, como as camadas do Deck.gl. Épossível, por exemplo, selecionar elementos nos gráficos e filtrar dinamicamente os pontosmostrados no mapa, fazendo com que o uso dessas duas ferramentas em conjunto seja degrande valor.

5https://www.mapbox.com/studio6https://uber.github.io/react-vis/

27

4 DESENVOLVIMENTO

Para a realização deste estudo, foi desenvolvido uma aplicação que consiste emum mapa interativo para visualização de dados geo espaciais, com o intuito de facilitar avisualização e entendimento dos mesmos.

Os dados coletados pelos OBDs dos carros são transmitidos a um servidor remotoatravés de um aplicativo instalado nos celulares dos participantes. O servidor, por sua vez,se encarrega de disponibilizar acesso a esses recursos por meio de uma API (SILVA et al.,2018).

Nossa aplicação, então, faz uma requisição a esse servidor para receber esses dadose realiza um tratamento para gerar algumas agregações úteis. Após o término desseprocessamento, a aplicação exibe essas informações no formato de gráficos e camadas devisualizações interativas sobre o mapa.

Além do mapa, a aplicação é composta pelos seguintes elementos de interface:

a) Dois gráficos interativos que exibem a quantidade de pontos coletados por cadacarro e em cada dia;

b) Uma camada de visualização das trajetórias geradas pelos pontos. As cores e ta-manhos de cada um dos pontos são determinadas pela velocidade do carro naqueledeterminado instante, de forma que podemos observar em quais trechos os motoristascostumam dirigir com mais ou menos velocidade;

c) Uma camada de visualização com um mapa de calor tridimensional gerado pelaconcentração de pontos em diferentes regiões do mapa. Com isso podemos ver quaisregiões da cidade foram mais frequentadas durante o período de teste.

d) Um painel de controle onde é possível selecionar diferentes estilos de mapa e alterarconfigurações para a renderização das camadas, como por exemplo o tamanho dospontos, opacidade das células e etc.

A qualquer instante o usuário pode exibir ou ocultar camadas, mudar configuraçõese filtrar os pontos exibidos nas camadas dinamicamente selecionando elementos dos gráficos(carros e/ou dia), tornando possível a realização de uma variedade de análises.

Nesta parte do trabalho será explicada em detalhes a composição e o funcionamentoda aplicação. No fim do Capítulo é apresentado um fluxograma representando as etapas defuncionamento da aplicação, a fim de tornar mais claro o entendimento do ciclo completode funcionamento da mesma.

Capítulo 4. Desenvolvimento 28

4.1 Funcionamento da AplicaçãoA aplicação obd-vis foi desenvolvida usando as 3 bibliotecas explanadas no Capítulo

3, gerando um mapa interativo com duas camadas de visualização independentes, gráficose controles.

Alguns carros usados no estudo disponibilizam acesso a uma vasta gama de sensores.Entretanto, principalmente em modelos mais antigos, esse número se mostrou bastantelimitado. Dessa forma, por razões de simplicidade e com o intuito de poder usar todos oscarros disponíveis, optou-se por utilizar apenas dados de sensores disponibilizados por todoseles, sendo estes: geo localização (latitude e longitude), tempo e velocidade de cada amostra.Apesar dessa limitação, esse comportamento pode ser facilmente alterado no futuro paraincorporar mais parâmetros, possibilitando uma maior variedade de visualizações.

O código fonte da aplicação foi estruturado no seguinte formato exibido na Figura 3.O arquivo app.js contém o componente raiz que é renderizado quando a aplicação écarregada. Esse componente é o pai de todos os demais componentes e é responsávelpor armazenar o estado da aplicação tal como a implementação da lógica básica para ofuncionamento da mesma.

Figura 3 – Arquivos da aplicação

Fonte – Elaborada pelo autor

Dentro da pasta charts existem dois arquivos, DateChart.js e PlateChart.js, estescontêm os componentes criados com a biblioteca React-Vis e que representam os gráficosgerados a partir dos dados obtidos. O primeiro deles define um gráfico com a quantidadede pontos por carro enquanto o segundo um gráfico com a quantidade de pontos por dia.

Dentro da pasta controls tem-se os arquivos LayerControl.js e MapStylePicker.js quecontém os componentes React referentes ao painel de controle das camadas e o selecionadorde estilo do mapa respectivamente.


Além disso existem mais dois outros arquivos dentro dessa mesma pasta: overlay-layers.js, no qual define-se as funções necessárias para renderizar as camadas de acordocom as opções selecionadas pelo usuário; e layer-controls-settings.js, no qual define-se alista de controles e configurações disponíveis que devem ser exibidas no painel de controle.

Com a inicialização da aplicação, o componente definido no arquivo app.js érenderizado na tela e os estados da aplicação são definidos com seus valores iniciais, comopode ser visto na Tabela 2.

Estado Valor Inicial DescriçãomapStyle ’mapbox://styles/mapbox/dark-v9’ Estilo do mapastatus ’STARTED’ Estado atual de execução da aplicação

highlightedPlate null Carro destacado ao passar o mouse pelo gráficoselectedPlate null Carro selecionado pelo usuário

highlightedDate null Data destacada ao passar o mouse pelo gráficoselectedDate null Data selecionada pelo usuáriocountByPlate [ ] Lista com a contagem de pontos agrupados por placacountByDate [ ] Lista com a contagem de pontos agrupados por data

points [ ] Lista de objetos que armazena os pontos retornados pelo servidorsettings Objeto com os valores das configurações selecionadas no painel de controle

Tabela 2 – Estados da aplicação


Após a inicialização do estado, o primeiro método chamado é a função de Ciclo deVida, componentDidMount, invocada automaticamente pelo React quando o componenteacaba de ser montado. Dentro desse método executam-se duas funções: a primeira delas,getLayerControlSettings, é importada do módulo layer-control-settings.js e retorna umobjeto com as configurações iniciais das camadas definidas no mesmo módulo, posteri-ormente salvando esse valor no estado do componente; a segunda função, fetchData, éresponsável pela requisição e tratamento dos dados da API.

Ao ser chamada, a função fetchData realiza uma requisição de forma assíncronaà API para receber os dados coletados. Ao receber resposta do servidor, a mesma seencarrega de formatar e limpar esses dados para gerar uma estrutura mais simples de setrabalhar.

Caso não hajam problemas com a conexão e disponibilidade do servidor, a respostaesperada é um JSON contendo uma lista de objetos, no qual cada elemento representa aleitura de um OBD em um determinado instante de tempo. Dentro de cada um dos objetostemos informações como a placa do carro, dia e hora da leitura e os dados coletados pelossensores que, por sua vez, é um outro objeto contendo as leituras individuais dos sensoresdisponíveis naquele carro para aquele determinado instante.

Verificou-se que alguns carros disponibilizam acesso a um número de sensores bemsuperior ao de outros, o que dificultaria uma análise mais aprofundada envolvendo todosos veículos. Com isso em mente, é feito um mapeamento da lista recebida para gerar umanova lista simplificada. Os elementos dessa lista preservam os dados referentes a placa


do veículo, dia e hora da leitura, e o valor registrado pelo sensor de velocidade. Durantea realização desse mapeamento também são feitas as contagens de pontos por data epor placa, armazenadas no estado do componente como countByDate e countByPlaterespectivamente.

Após a finalização da execução da função componentDidMount, a aplicação érenderizada na tela quando o React executa a função render. Em um primeiro momento,o mapa e os gráficos são renderizados vazios. Isto se dá pelo fato da chamada a APIacontecer assincronamente, de forma que a função render é chamada a primeira vez antesque possamos obter uma resposta do servidor.

Por esse motivo temos um estado status, que é alterado ao receber resposta positivado servidor, de forma que é possível verificar rapidamente em que ponto da execução doaplicativo se encontra em um determinado momento.

Dentro da função render chamamos a função getLayers, importada do módulooverlay-layers.js, que retorna uma lista com as camadas a serem renderizadas pelo compo-nente DeckGL. Finalmente, no retorno da função render definimos as tags JSX referentesaos componentes que compõem a aplicação, sendo eles:

a) PlateChart: gráfico com a contagem de pontos por placa

b) DateChart: gráfico com a contagem de pontos por dia

c) MapStylePicker : selecionador do estilo do mapa

d) LayerControls: painel de controle referente as configurações das camadas renderi-zadas pelo Deck.gl

e) DeckGL: componente responsável por renderizar as camadas de visualização

f) StaticMap: componente filho do componente DeckGL, renderiza o mapa estáticoem cima das quais as camadas de visualização devem ser renderizadas

A árvore de componentes da aplicação pode ser vista mais claramente na Figura 4,na qual é possível ver a estrutura formada por todos os componentes listados acima.

Além dessas funções discutidas até o momento, dentro do arquivo app.js são definidosalguns outros métodos que serão passadas como callbacks aos demais componentes com ointuito de realizar as alterações necessárias nos estados da aplicação.

O funcionamento dos diferentes componentes que compõem a aplicação será discu-tida em mais detalhes nas subseções seguintes.


Figura 4 – Árvore de Componentes


4.1.1 Gráficos

Os gráficos PlateChart e DateChart são componentes muito similares. Foramconstruídos usando os componentes XYPlot, XAxis, YAxis e VerticalBarSeries da bibliotecaReact-Vis, o que nos garantiu grande flexibilidade de customização. Ambos os componentesrecebem as seguintes props:

a) Bins: um array com os dados que dever ser plotados. Cada item do array deveser um objeto que contenha como chaves ‘x’ e ‘y’. Obtidos a partir dos estadoscountByPlate e countByDate

b) onHightlight: função callback que deve ser acionada no componente pai quando ousuário passar o mouse sobre alguma barra no gráfico;

c) onSelect: função callback que deve ser acionada no componente pai quando ousuário selecionar alguma barra no gráfico;

d) highlightedItem: ultima barra destacada pelo usuário (estados highlightedPlate ouhighlightedDate)

e) selectedItem: ultima barra selecionada pelo usuário (estados selectedPlate ouselectedDate)


Esses são componentes simples que apenas renderizam esses dados de maneiraformatada. Por esse motivo não precisam de estado interno. Dessa forma não é necessárioque seja usada uma classe para declará-los, substituindo então por uma simples funçãocujo os parâmetros são as props e o retorno são as tags JSX.

4.1.2 Camadas

As camadas, diferentemente dos outros elementos discutidos até agora, não sãocomponentes React. Em vez disso, são classes próprias da biblioteca Deck.gl que sãoimportadas pela aplicação. As instâncias dessas classes devem ser passadas em forma delista como prop para o componente DeckGL, importado da mesma biblioteca.

No módulo overlay-layers.js temos as funções necessárias para filtrar os pontose gerar essa lista de camadas com as configurações atuais. Para isso é usada a funçãoexportada getLayes, que é chamada na função render do componente contido em app.js.

Essa função recebe como parâmetro um objeto contendo os seguintes estados daaplicação: points, settings, displayPlate e displayDate.

Usando displayPate e displayDate é possivel filtrar os dados a serem exibidos nascamadas de acordo com o que se encontra selecionado nos gráficos. Em seguida, as camadasde visualização são instanciadas: uma ScatterplotLayer, para a camada das trajetórias, euma HexagonLayer, para a camada do mapa de calor. Ao instanciar essas classes um objetocontendo os parâmetros necessários é passado para o construtor. Entre esses parâmetrosencontram-se os dados filtrados e as configurações selecionadas pelo usuário, passadas paraa função pelo estado settings. Por fim, verifica-se quais das camadas devem estar ativas ea lista é construída para ser retornada.

4.1.3 Painel de Controle

O painel de controle é definido no módulo LayerControls.js e recebe duas props:settings e onChange, a primeira referente ao estado da aplicação em que se encontram asconfigurações das camadas e a segunda uma função callback que define o que deve ser feitoapós uma interação do usuário. No nosso caso, a função passada altera o estado settingsno componente App.

Esse é um padrão bastante comum em React: é passado ao componente o valoratual do estado que deve ser alterado (para que o mesmo possa exibir esse valor ao serrenderizado) em conjunto com uma função callback definida no componente pai paraalterar o estado caso algum evento seja disparado pelo componente filho.

Dentro do componente LayerControls, são renderizados os componentes filhosnecessários para a exibição dos controles, como sliders e checkboxes. Para cada um desses


componentes são repassados o callback e o estado, de forma que qualquer alteração nocomponente filho chama LayerSetings, que por sua vez chama a função callback definidaem app.js para, enfim, alterar o estado da aplicação.

O outro módulo é o layer-controls-settings.js, no qual define-se a lista objetos quedeterminam cada uma das configurações das camadas. Cada objeto contém os seguinteselementos, usados para guiar o processo de renderização:

a) displayName: nome da configuração que deve ser renderizado na tela

b) Type: tipo de configuração e.g. booleana ou escala

c) Value: Valor inicial da configuração

d) Min: apenas para configurações do tipo range, define o valor mínimo do slider

e) Max: apenas para configurações do tipo range, define o valor máximo do slider

f) Step: apenas para configurações do tipo range, define o valor do passo para amovimentação do slider

Além disso, esse módulo exporta a função getLayerControlSettings, que transformaesse objeto em um formato mais simples para ser salvo no estado da aplicação e passado ascamadas do deck.gl, já que para ambos só é necessário ter um objeto cujo as chaves são osnomes da configurações e os valores são os selecionados pelo usuário no painel de controle.

4.2 Fluxograma do FuncionamentoNa Figura 5 é possível ver um fluxograma com as etapas de funcionamento da

aplicação, apresentado com o intuito de tornar mais claro o entendimento.


Figura 5 – Fluxograma de funcionamento


35

5 RESULTADOS E DISCUSSÕES

A interface final da aplicação desenvolvida pode ser vista na Figura 6. Do ladodireito da interface temos o painel de controle onde podemos definir as configurações derenderização das camadas do Deck.gl, como ligar ou desligar as camadas individualmente,alterar o tamanho de pontos, a opacidade das células do mapa de calor e etc (Figura 7(b)).Também do lado direito temos o selecionador de estilos, que nos permite selecionar entrealguns estilos de mapa disponibilizados pelo Mapbox. Já ao lado esquerdo podemos ver osgráficos interativos construídos com a biblioteca React-Vis (Figura 7(a)).

Figura 6 – Interface da aplicação


No mapa mostrado na Figura 6 está exibida a camada de visualização das trajetórias.Nessa camada são usados os valores registrados pelo sensor de velocidade para determinara cor e o tamanho de cada um dos pontos: quanto mais elevado o valor, maior e maisvermelho será o ponto correspondente aquele instante.

Com ajuda do gráficos é possível visualizar a quantidade de pontos registrados porcada carro tal como em cada um dos dias. Porém, além de poder visualizar graficamenteesses dados, podemos selecionar tanto o carro quanto o dia no próprio gráfico, o quefiltra dinamicamente os dados mostrados na tela pelas camadas do Deck.gl, atualizando omapa em tempo real. Na Figura 8 é possível ver alguns exemplos dessa funcionalidade: naFigura 8(a) temos um trajeto urbano e em Figura 8(b) uma viagem em rodovia. Podemosver claramente uma diferença nas cores e tamanho dos pontos, dado que o segundo trajetotende a ser feito em uma maior velocidade. Também é possível observar trechos no segundotrajeto onde o celular ficou sem sinal e, portanto, não enviou os dados ao servidor.

Capítulo 5. Resultados e Discussões 36

(a) Gráficos (b) Painel de Controle

Figura 7 – Elementos da Interface


(a) Trajetória urbana

(b) Trajetória em rodovia

Figura 8 – Trajetórias de diferentes carros e dias



Além da camada de trajetórias, temos a camada de mapa de calor que pode serativada marcando a opção disponível no painel de controle. Como pode ser observado naFigura 9, o mapa de calor é formado por colunas hexagonais tridimensionais, com cores etamanhos proporcionais à densidade de pontos registrados em cada região da cidade. Épossível perceber, por exemplo, uma grande densidade de pontos próximo a região onde seencontra a UFRN, pois a maioria dos participantes deste estudo frequentam a instituiçãodiariamente. Além disso, temos na mesma figura exemplos de diferentes configuraçõespossíveis para essa camada, como diferentes tamanhos, opacidade e e cobertura das células.

(a) Camada nas configurações padrão (b) Camada exibida com células maiores e maistransparentes

(c) Camada exibida com células menores e com menoscobertura

Figura 9 – Camada de mapa de calor


Por fim, é disponibilizada a opção de selecionar entre vários estilos de mapa paraauxiliar em diferentes visualizações, sendo possível até mesmo criar novos estilos com aferramenta do Mapbox Studio. Na Figura 10 é possível ver 3 dos diferentes estilos básicosdisponíveis e selecionáveis na aplicação.


(a) Estilo ’Streets V10’ (b) Estilo ’Navigation Guidance Night V4’

(c) Estilo ’Satellite Streets V10’

Figura 10 – Estilos de Mapa


39

6 CONCLUSÃO

Neste Capítulo são apresentadas as conclusões sobre este trabalho de pesquisa apartir da visão dos objetivos e proposta do método e limitações de seus resultados, assimcomo as possibilidades de trabalhos futuros.

Este trabalho teve como objetivo o desenvolvimento de uma plataforma paravisualização de dados em um contexto de carros inteligentes (IoIV), a fim de facilitar oentendimento do funcionamento dos veículos e auxiliar na análise de possíveis padrões nautilização dos mesmos.

Para atingir esse objetivo geral, foram implementadas soluções para os objetivosespecíficos citados anteriormente, desenvolvendo um software capaz de coletar os dadosdisponibilizados pela plataforma SmartFleet; processar e filtrar esses dados, possibilitandoa sua visualização no mapa e gráficos interativos; e, por fim, interagir com comandos dousuário, alterando o mapa dinamicamente.

A aplicação final possibilitou a realização de algumas análises preliminares emrelação as trajetórias e distribuição dos pontos ao redor da cidade. Analises que não seriampráticas sem uma ferramenta de visualização adequada.

6.1 DificuldadesPara realizar a pesquisa houveram algumas dificuldades e limitações. A biblioteca

Deck.gl tem algumas particularidades que levaram a alguns entraves e, por não haver umadocumentação extremamente clara, gerou uma lentidão no processo de desenvolvimentoda aplicação.

Outra dificuldade foi gerada por parte da integração com a API disponibilizadapelo sistema SmartFleet. Por ser uma plataforma que foi recentemente desenvolvida, aindaé necessário que sejam realizados alguns polimentos na formatação dos dados enviados.Além disso, seria interessante a adição de outros endpoints que permitam uma requisiçãocustomizada, de forma que parte do processamento e filtragem dos dados possa ser feitono lado do servidor e não da aplicação cliente.

6.2 Trabalhos FuturosNesta Seção são apresentadas algumas sugestões para trabalhos futuros que com-

plementam a pesquisa realizada nesse trabalho. São elas:

Capítulo 6. Conclusão 40

a) Acrescentar novas funcionalidades e melhorar as já disponibilizadas através dainterface Web, assim como a aplicação de uma re estilização dos componentes paratornar a experiência mais intuitiva para o usuário;

b) Ampliar a amostra de dados realizando mais coletas, tornando possível análises maisaprofundadas;

c) Aplicar soluções de Inteligência Artificial a fim de gerar visualizações úteis paraações de planejamento urbano. Pode ser citado como exemplo a detecção de falhas eburacos na pavimentação por meio de anomalias registradas pelos sensores veicularese dos smartphones, permitindo uma visualização mais clara do problema por partedas autoridades responsáveis;

6.3 Contribuições Relacionadas ao TrabalhoNesta Seção são apresentadas as contribuições relacionadas ao trabalho.

6.3.1 Artigos Aprovados

• A Customer Feedback Platform for Vehicle Manufacturing Compliant with Industry4.0 Vision, Sensors - Qualis A1

41

REFERÊNCIAS

ATZORI, L.; IERA, A.; MORABITO, G. The internet of things: A survey. ComputerNetworks, v. 54, n. 15, p. 2787 – 2805, 2010. 16

BAEK, S.-h.; JANG, J.-W. Implementation of integrated obd-ii connector with externalnetwork. Information Systems, Elsevier, v. 50, p. 69–75, 2015. 17

BLEI, D. M.; SMYTH, P. Science and data science. Proceedings of the National Academyof Sciences, National Academy of Sciences, 2017. ISSN 0027-8424. Disponível em:<http://www.pnas.org/content/early/2017/08/04/1702076114>. 19, 20

BRIGHAM, T. J. Feast for the eyes: An introduction to data visualization. MedicalReference Services Quarterly, Routledge, v. 35, n. 2, p. 215–223, 2016. PMID: 27054537.Disponível em: <https://doi.org/10.1080/02763869.2016.1152146>. 20

BRöRING, A. et al. envirocar: A citizen science platform for analyzing and mappingcrowd-sourced car sensor data. Transactions in GIS, v. 19, n. 3, p. 362–376, 2015.Disponível em: <https://onlinelibrary.wiley.com/doi/abs/10.1111/tgis.12155>. 20, 21

CAO, L. Data science: A comprehensive overview. ACM Comput. Surv., ACM, NewYork, NY, USA, v. 50, n. 3, p. 43:1–43:42, jun. 2017. ISSN 0360-0300. Disponível em:<http://doi-acm-org.ez18.periodicos.capes.gov.br/10.1145/3076253>. 20

CHEN, Y. et al. An improved aomdv routing protocol for v2v communication. In: . [S.l.:s.n.], 2009. p. 1115–1120. 17

CHEN, Y.-C. et al. Interactive visual analysis for vehicle detector data. ComputerGraphics Forum, v. 34, n. 3, p. 171–180, 2015. Disponível em: <https://onlinelibrary-.wiley.com/doi/abs/10.1111/cgf.12629>. 20, 21

CHOWDHARY, N.; KAUR, P. D. Addressing the characteristics of mobility models in iovfor smart city. In: . [S.l.: s.n.], 2017. p. 1298–1303. 17

CONTRERAS-CASTILLO, J.; ZEADALLY, S.; IBáñEZ, J. A. G. A seven-layered modelarchitecture for internet of vehicles. Journal of Information and Telecommunication,Taylor Francis, v. 1, n. 1, p. 4–22, 2017. 17

DANDALA, T. T.; KRISHNAMURTHY, V.; ALWAN, R. Internet of vehicles (iov) fortraffic management. In: International Conference on Computer, Communication andSignal Processing (ICCCSP). [S.l.: s.n.], 2017. p. 1–4. 16

FERREIRA, N. et al. Visual exploration of big spatio-temporal urban data: A study ofnew york city taxi trips. IEEE Transactions on Visualization and Computer Graphics,v. 19, n. 12, p. 2149–2158, Dec 2013. ISSN 1077-2626. 20, 21

GANTI, R. K.; YE, F.; LEI, H. Mobile crowdsensing: current state and future challenges.IEEE Communications Magazine, v. 49, n. 11, p. 32–39, 2011. 17

http://www.pnas.org/content/early/2017/08/04/1702076114

https://doi.org/10.1080/02763869.2016.1152146

https://onlinelibrary.wiley.com/doi/abs/10.1111/tgis.12155

http://doi-acm-org.ez18.periodicos.capes.gov.br/10.1145/3076253

https://onlinelibrary.wiley.com/doi/abs/10.1111/cgf.12629

https://onlinelibrary.wiley.com/doi/abs/10.1111/cgf.12629

Referências 42

GIACALONE, M.; SCIPPACERCOLA, S. Big data: Issues and an overview in somestrategic sectors. Journal of Applied Quantitative Methods, v. 11, n. 3, p. 1 – 17, 2016.ISSN 18424562. Disponível em: <http://search-ebscohost-com.ez18.periodicos.capes-.gov.br/login.aspx?direct=true&db=aph&AN=122035330&lang=pt-br&site=ehost-live&authtype=ip,cookie,uid>. 13

GILL, S. et al. An effective and empirical review on internet of things and real-timeapplications. In: Advances in Computer and Computational Sciences. [S.l.]: SpringerSingapore, 2018. p. 159–167. ISBN 978-981-10-3773-3. 16, 17

GUBBI, J. et al. Internet of things (iot): A vision, architectural elements, and futuredirections. Future generation computer systems, Elsevier, v. 29, n. 7, p. 1645–1660, 2013.16

HROMIC, H. et al. Real time analysis of sensor data for the internet of things by meansof clustering and event processing. In: International Conference on Communications(ICC). [S.l.: s.n.], 2015. p. 685–691. ISSN 1550-3607. 16

LI, Y. et al. Efficient spatial keyword query processing in the internet of industrialvehicles. Mobile Networks and Applications, 2017. ISSN 1572-8153. 16

MALEKIAN, R. et al. Design and implementation of a wireless OBD II fleet managementsystem. CoRR, abs/1701.02160, 2017. Disponível em: <http://arxiv.org/abs/1701.02160>.20, 21

OLIVEIRA, J. et al. Co2catcher: A platform for monitoring of vehicular pollution insmart cities. In: 2017 IEEE First Summer School on Smart Cities. [S.l.]: IEEE, 2017. p.37–42. 13, 18

PU, L. et al. Implementing on-board diagnostic and gps on vanet to safe the vehicle. In: .[S.l.: s.n.], 2016. p. 13–18. 17

SADEGHI, A.-R.; WACHSMANN, C.; WAIDNER, M. Security and privacy challenges inindustrial internet of things. In: . [S.l.: s.n.], 2015. v. 2015-July. 16

SHU, L. et al. Releasing network isolation problem in group-based industrial wirelesssensor networks. IEEE Systems Journal, v. 11, n. 3, p. 1340–1350, 2017. ISSN 1932-8184.16

SILVA, M. et al. A customer feedback platform for vehicle manufacturing compliantwith industry 4.0 vision. Sensors, v. 18, n. 10, 2018. ISSN 1424-8220. Disponível em:<http://www.mdpi.com/1424-8220/18/10/3298>. 18, 19, 27

SUGAYAMA, R.; NEGRELLI, E. Connected vehicle on the way of Industry 4.0. 2017. 17

TALIB, M.; HUSSIN, B.; HASSAN, A. Converging vanet with vehicular cloud networksto reduce the traffic congestions: A review. International Journal of Applied EngineeringResearch, v. 12, n. 21, p. 10646–10654, 2017. 17

TOMINSKI, C. et al. Stacking-based visualization of trajectory attribute data. IEEETransactions on Visualization and Computer Graphics, v. 18, n. 12, p. 2565–2574, Dec2012. ISSN 1077-2626. 21

http://search-ebscohost-com.ez18.periodicos.capes.gov.br/login.aspx?direct=true&db=aph&AN=122035330&lang=pt-br&site=ehost-live&authtype=ip,cookie,uid



http://arxiv.org/abs/1701.02160

http://www.mdpi.com/1424-8220/18/10/3298

Referências 43

WU, W.-C. et al. The next generation of internet of things: Internet of vehicles. In:Frontier Computing. [S.l.]: Springer Singapore, 2018. p. 278–282. ISBN 978-981-10-7398-4.16

ZANELLA, A. et al. Internet of things for smart cities. IEEE Internet of Things journal,IEEE, v. 1, n. 1, p. 22–32, 2014. 16

visualização de dados em um contexto de veículos inteligentes€¦ · coisas (iot), internet de...

Documents