CURSO DE ENGENHARIA DE COMPUTAÇÃO
MATHEUS RODRIGUES LINO
SISTEMA DE TELEMETRIA E RASTREAMENTO DE VEÍCULOS
TRABALHO DE CONCLUSÃO DE CURSO
TOLEDO
2019
SISTEMA DE TELEMETRIA E RASTREAMENTO DE VEÍCULOS
Trabalho de Conclusão de Curso apresentado ao Curso de Engenharia de Computação da Universidade Tecnológica Federal do Paraná - UTFPR Campus Toledo, como requisito parcial para a obtenção do título de Bacharel em Engenharia de Computação.
Orientador: Prof. Dr. Elder Elisandro Schemberger Universidade Tecnológica Federal do Paraná
TOLEDO
2019
Campus Toledo
Coordenação do Curso de Engenharia Eletrônica
TERMO DE APROVAÇÃO
Título do Trabalho de Conclusão de Curso No01
Sistema de Telemetria e Rastreamento de Veículos
por
Matheus Rodrigues Lino
Esse Trabalho de Conclusão de Curso foi apresentado às 08h30 do dia 25 de Novembro de 2019 como requisito parcial para a obtenção do título de Bacharel em Engenharia de Computação. Após deliberação da Banca Examinadora, composta pelos professores abaixo assinados, o trabalho foi considerado APROVADO.
Prof. Dr. Elder Elisandro Schemberger Orientador - UTFPR-TD
Prof. Dr. Luis Carlos Mathias UTFPR-TD
Prof. Dr. Tiago Piovesan Vendruscolo UTFPR-TD
Prof. Dr. Wesley Klewerton Guez Assunção UTFPR-TD
O termo de aprovação assinado encontra-se na coordenação do curso
gem durante toda esta longa caminhada, pois este caminho seria impossível sem Ele. À mi-nha família, por sua capacidade de acreditar em mim e investir em mim. Mãe, seu cuidado e de-dicação foi o que deram, em alguns momentos, a esperança para seguir. Pai, sua presença sig-nificou segurança e certeza de que não estou sozinho nessa caminhada. E o que dizer a você Jaine? Obrigado pela paciência, pelo incentivo, pela força e principalmente pelo carinho. Valeu a pena toda distância, todo sofrimento, todas as renúncias. Hoje estamos colhendo, juntos, os frutos do nosso empenho, esta vitória é nossa.
Agradeço a Deus, que foi minha maior força nos momentos em que mais precisei. Sem Ele, nada disso seria possível. Obrigado, senhor, por colocar esperança, amor e fé no meu coração.
Agradeço a minha mãe Marilene Paulino Rodrigues Lino, que encheu meu coração de amor e esperança. Também sou eternamente grato ao meu pai Nilson Lino, que me proporcionou a tranquilidade e o conforto que tanto precisava para vencer esta etapa. Sem a força de vocês eu não conseguiria seguir em frente.
Obrigado meu irmão Miguel Rodrigues Lino, que nos momentos de minha ausência dedicados ao estudo, sempre fez entender que o futuro é feito a partir da constante dedicação no presente. Obrigado meu irmão por ser meu eterno companheiro.
Agradeço a todos meus familiares que diretamente ou indiretamente contribuíram para a minha graduação. Em especial a minha tia Mariluce Aparecida Rodrigues de Moura, eu jamais serei capaz de retribuir todo carinho, amor e incentivo que recebi da senhora.
Agradeço à minha namorada Jaine Rocha Jenuário que sempre esteve ao meu lado durante o meu percurso acadêmico. Obrigado por ser tão atenciosa e por entender minha ausência em diferentes momentos. Você foi essencial nesta minha jornada.
A todos os amigos, especialmente Luís Augusto Moromisato de Oliveira e Thales Ryu Ito, meu muito obrigado. Vocês foram fundamentais para minha formação, por isso merecem o meu eterno agradecimento.
Agradeço a todos os professores, especialmente ao orientador Elder Elisandro Schember-ger. Obrigado, por exigir de mim muito mais do que eu imaginava ser capaz de fazer. Manifesto aqui minha gratidão eterna por compartilhar sua sabedoria, o seu tempo e sua experiência.
Agradeço a Universidade Tecnológica Federal do Paraná Campus Toledo por financiar parte deste trabalho de conclusão de curso e oferecer professores incríveis, um ambiente de estudo saudável e muitos estímulos para participar de atividades acadêmicas. Sou grato não só aos professores, mas também à direção, ao pessoal do administrativo, da limpeza e demais colaboradores da instituição.
o que deveria ser, mas Graças a Deus, não sou o que era antes".(Marthin Luther King).
LINO, Matheus Rodrigues. Sistema de Telemetria e Rastreamento de Veículos. 2019. 121 f. Tra-balho de Conclusão de Curso – Curso de Engenharia de Computação, Universidade Tecnológica Federal do Paraná. Toledo, 2019.
O atual crescimento tecnológico tem gerado, por meio de quem o consome, uma grande demanda por novas aplicações e serviços. Este cenário cresce na proporção de que as pessoas carecem de novas possibilidades para resolução de problemas cotidianos. Um atual desafio no controle de frotas automotivas é realizar a obtenção de dados de telemetria e rastreamento em tempo real, a fim de proporcionar maior controle gerencial sobre os veículos monitorados. Esse cenário é decorrente do fato que motoristas, em geral, ficam longos períodos ausentes das empresas, dificultando o monitoramento e a prevenção de falhas, somado ao fato da impossibilidade de identificação das rotas escolhidas por seus motoristas. Neste contexto, este projeto apresenta uma solução por meio do desenvolvimento de um hardware e um software especialistas, promovendo uma alternativa para que empresas responsáveis por estes veículos possam gerenciá-los e toma-rem as melhores decisões em termos de manutenção e de estilos de direção de seus motoristas. Os dados são obtidos via scanner OBDII, módulo GPS e armazenados em um módulo cartão micro SD, centralizados por um Arduino que os gerencia. Para a transmissão destes dados, foi proposta uma solução via rede de celulares GSM/GPRS. Também é composto por um software web, responsável por receber e permitir a visualização e análise dos dados coletados. Para os testes foram utilizados dez veículos de sete fabricantes diferentes, os quais apresentaram resultados con-dizentes com o esperado. O software front-end permitiu análises dos dados coletados por meio de mapas, gráficos e tabelas. Além dos resultados de funcionamento do projeto, foi possível identi-ficar problemas em dois dos veículos utilizados para os testes, corroborando a eficácia do sistema. Palavras-chave: OBDII. Monitoramento. Diagnóstico Veicular. Software. Transmissão via GSM/GPRS.
LINO, Matheus Rodrigues. Telemetry and Vehicle Tracking System. 2019. 121 f. Trabalho de Conclusão de Curso – Curso de Engenharia de Computação, Universidade Tecnológica Federal do Paraná. Toledo, 2019.
The current technological growth has generated, through those who consume it, a great demand for new applications and services. This scenario grows as people need new possibilities for solving everyday problems. A current challenge in automotive fleet control is to obtain real-time telemetry and tracking data to provide greater management control over monitored vehicles. This scenario happens because drivers, in general, stay far away from companies for long periods of time, making monitoring and prevention of failures harder to identify, in addition the companies cannot identify the routes chosen by their drivers. In this context, this project presents a solu-tion through the development of specialist hardware and software, providing an alternative for companies responsible for these vehicles to manage them and make the best maintenance and driving style decisions for the drivers of their vehicles. Data are obtained via an OBDII scanner, GPS module, stored in a micro SD card module, centralized by an Arduino that manages them. For the transmission of these data, a solution via GSM/GPRS cellular network was proposed. It is also composed of software web, responsible for receiving and allowing the visualization and analysis of the collected data. For the tests were used ten vehicles from seven different manufacturers, which presented consistent results. The front-end software allowed analysis of the collected data through maps, graphs, and tables. In addition to the project’s operating results, it was possible to identify problems in two of the vehicles used for the tests, corroborating the system’s effectiveness.
Figura 2.1 – Pontos de um sistema de telemetria geral . . . 5
Figura 2.2 – Rastreamento veicular . . . 6
Figura 2.3 – Diagrama de blocos de um módulo eletrônico genérico . . . 7
Figura 2.4 – Formato dos quadros de bits do modelo CAN . . . 10
Figura 2.5 – Topologias de rede sem e com CAN . . . 10
Figura 2.6 – Canal OBDII . . . 11
Figura 2.7 – Modelo de microcontrolador com arquitetura de Von Neumann . . . 13
Figura 2.8 – Imagem do microcontrolador Atmega328p . . . 14
Figura 2.9 – Diversos modelos de Arduino . . . 15
Figura 2.10–Imagem de um módulo GPS . . . 17
Figura 2.11–Aplicações Bluetooth . . . 18
Figura 2.12–Exemplo de módulo Bluetooth . . . 18
Figura 2.13–Shield GSM/GPRS . . . 20
Figura 2.14–Camadas do modelo TCP/IP . . . 21
Figura 2.15–Exemplo de código XML . . . 22
Figura 2.16–Exemplo de código JSON . . . 22
Figura 2.17–Modelo simples Cliente-Servidor . . . 23
Figura 2.18–Camadas do modelo Cliente-Servidor . . . 24
Figura 2.19–Diversos sistemas Cliente-Servidor . . . 24
Figura 2.20–Servidor de Banco de Dados . . . 25
Figura 2.21–Paradigmas de Linguagem de Programação . . . 26
Figura 2.22–Exemplo de modelo Conceitual . . . 28
Figura 2.23–Exemplo de modelo Lógico . . . 28
Figura 2.24–Exemplo de modelo Físico . . . 29
Figura 2.25–Descrição de trabalhos correlatos . . . 33
Figura 3.1 – Esquemático do sistema, sub-dividido em três partes . . . 34
Figura 3.2 – Fluxo de dados do sistema proposto . . . 35
Figura 3.3 – Esquemático do hardware do sistema . . . 37
Figura 3.4 – Configuração e emparelhamento HC05 com scanner OBDII . . . 38
Figura 3.5 – Arquitetura conceitual de transmissão de dados . . . 42
Figura 4.1 – Sistema proposto realizando coleta e apresentando dados . . . 46
Figura 4.2 – Protótipo do hardware desenvolvido . . . 48
Figura 4.3 – Diferentes posições do canal OBDII em diferentes carros . . . 49
Figura 4.4 – Exemplo de arquivo com os dados coletados . . . 50
Figura 4.5 – Rotação por minuto instável . . . 52
Figura 4.8 – Plataforma pgAdmin 4 para gerenciamento do banco de dados . . . 54
Figura 4.9 – Script para inserção dos dados coletados pelo hardware . . . 55
Figura 4.10–Template inicial . . . 56
Figura 4.11–Template de login do software web . . . 57
Figura 4.12–Template gerencial . . . 57
Figura 4.13–Template gerencial de veículos . . . 58
Figura 4.14–Template inserção de novo veículo . . . 58
Figura 4.15–Template gerencial de viagens . . . 59
Figura 4.16–Template inserção de nova viagem . . . 59
Figura 4.17–Template gerencial de motoristas . . . 60
Figura 4.18–Template inserção de novo motorista . . . 60
Figura 4.19–Template gerencial de combustível . . . 61
Figura 4.20–Template inserção de novo valor de combustível . . . 61
Figura 4.21–Template listagem de telemetrias . . . 62
Figura 4.22–Template listagem de viagens . . . 63
Figura 4.23–Template listagem de veículos . . . 64
Figura 4.24–Template listagem de motoristas . . . 65
Figura 4.25–Template de visualização de telemetria . . . 66
Figura 4.26–Template de visualização de viagem . . . 67
Figura 4.27–Template de visualização de veículo . . . 68
Figura 4.28–Gráfico anual de consumo de combustível . . . 69
Figura 4.29–Gráfico estilo de direção dos motoristas . . . 69
Figura 4.30–Últimas viagens e rota . . . 70
Figura 4.31–Comparação com trabalhos correlatos . . . 71
Figura E.1 – Diagrama de casos de uso do sistema . . . 98
Figura G.1 – Diagrama de classe e diagrama entidade relacionamento parte 1 . . . 106
Quadro 1 – Vantagens e Desvantagens GPS. . . 16
Quadro 2 – Protocolos OBD disponíveis. . . 39
Quadro 3 – Comandos utilizados no scanner. . . 40
Quadro 4 – Exemplo de resposta ELM327. . . 40
Quadro 5 – Conversão dos dados. . . 41
Quadro 6 – Veículos utilizados. . . 47
Quadro 7 – Custo do projeto de hardware . . . 48
Quadro 8 – Requisito Gerenciar Viagens. . . 93
Quadro 9 – Requisito Gerenciar Veículos. . . 93
Quadro 10 – Requisito Gerenciar Motoristas. . . 94
Quadro 11 – Requisito Gerenciar Telemetria. . . 95
Quadro 12 – Requisito Gerenciar Rastreamento. . . 95
Quadro 13 – Requisito Implementação. . . 96
Quadro 14 – Requisito Interface. . . 96
Quadro 15 – Requisito Segurança. . . 96
Quadro 16 – Casos de Uso. . . 97
Quadro 17 – Caso de Uso: Visualizar e Analisar Dados coletados dos veículos. . . 99
Quadro 18 – Caso de Uso: Visualizar e Analisar o local em que os dados foram coletados. 99 Quadro 19 – Caso de Uso: Cadastrar Viagens. . . 100
Quadro 20 – Caso de Uso: Visualizar Rotas da Viagem. . . 100
Quadro 21 – Caso de Uso: Visualizar Telemetrias da Viagem. . . 101
Quadro 22 – Caso de Uso: Visualizar Veiculo e Motorista da Viagem. . . 101
Quadro 23 – Caso de Uso: Cadastrar Veículos. . . 102
Quadro 24 – Caso de Uso: Visualizar Rotas do Veículo. . . 102
Quadro 25 – Caso de Uso: Visualizar Telemetrias do Veículo. . . 103
Quadro 26 – Caso de Uso: Visualizar Motorista do Veículo. . . 103
Quadro 27 – Caso de Uso: Cadastrar Motoristas. . . 104
Quadro 28 – Caso de Uso: Visualizar Rotas do Motorista. . . 104
Quadro 29 – Caso de Uso: Visualizar Telemetrias do Motorista. . . 105
Quadro 30 – Caso de Uso: Visualizar Veiculo do Motorista. . . 105
ADAS Advanced Driver Assistance Systems, ou Sistemas Avançados de Auxílio ao Motorista
API Application Programming Interface, ou Interface de Programação de Apli-cações
BCM Body Control Module, ou Módulo de Controle de Carroçaria
BEC Body Eletronic Controller, ou Controlador Eletrônico de Carroçaria BSS Base Station System, ou Sistema de Estação Base
BSC Base Station Controller, ou Controlador de Estação Base BTS Base Transceiver Station, ou Antena Transceptora
CAN Controller Area Network, ou Rede da Área do Controlador CPU Central Processing Unit, ou Unidade Central de Processamento CIM Column Integration Module, ou Módulo de Integração da Coluna
CISC Complex Instruction Set Computer, ou Computador com um Conjunto Com-plexo de Instruções
CS Chip Selection, ou Seleção de Chip
CSS Cascading Style Sheets, Folhas de estilo em cascata
CSMA/CD Carrier Sense Multiple Access with Collision Detection, ou Acesso Múltiplo com Detecção de Portadora e com Detecção de Colisão
DLC Data Connector Link, ou Link do Conector de Dados
DTC Diagnostic Trouble Codes, ou Códigos de Diagnóstico de Falhas
DZM Door Zone Module, ou Módulo da Área de Portas
ECM Engine Control Module, ou Módulo de Controle do Motor
ECU Eletronic Control Unit, ou Unidade de Controle Eletrônico
ETSI European Telecommunications Standards Institute, ou Instituto Europeu de Normas de Telecomunicações
GNSS Global Navigation Satellite System, ou Sistema de Navegação por Satélite GPRS General Packet Radio Services, ou Serviços Gerais de Pacote por Rádio GPS Global Positioning System, ou Sistema de Posicionamento Global
GSM Global System for Mobile Communications, ou Sistema Global para Comu-nicações Móveis
HTML HyperText Markup Language, ou Linguagem de Marcação de Hipertexto
IP Internet Protocol, ou Protocolo de Internet
JSON JavaScript Object Notation, ou Notação de Objetos JavaScript LIN Local Interconnect Network, ou Rede de Interconexão Local
MISO Master IN Slave OUT, ou Dados do Escravo para Mestre
MOSI Master OUT Slave IN, ou Dados do Mestre para Escravo
MS Mobile Station, ou Estação Móvel
MSC Mobile Switching Center, ou Centro de Comutação Móvel
MT Multitimer
NS Network Subsystem, ou Subsistema de Rede
OBD On-Board Diagnostic, ou Diagnóstico a Bordo
PCM Power train Control Module, ou Módulo de Controle Motor - Transmissão
PL Procedural Language, ou Linguagem Procedural
RAM Random Access Memory, ou Memória de Acesso Aleatório
RISC Reduced Instruction Set Computer, ou Computador com um Conjunto Redu-zido de Instruções
ROM Read Only Memory, ou Memória Somente para Leitura
RPM Rotações por Minutos
RX Receive, ou Recepção
RZM Rear Zone Module, ou Módulo da Área Traseira
SDI Serial Digital Interface, ou Interface Digital Serial
SGBD Sistema Gerenciador de Banco de Dados
SGML Standard Generalized Markup Language, ou Linguagem de Marcação
Ge-neralizada Padrão
SIG Sistema de Informação Geográfica
SIM Subscriber Identity Module, ou Módulo de Identidade do Assinante
SMS Short Message Service, ou Serviço de Mensagens Curtas
SQL Structured Query Language, ou Linguagem de Consulta Estruturada TCM Trasmission Control Module, ou Módulo de Controle da Transmissão TCP Transmission Control Protocol, ou Protocolo de Controle de Transmissão TCU Telematics Control Unit, ou Unidade de Controle de Telemática
TX Transmit, ou Transmissão
ULA Unidade Lógica e Aritmética
USB Universal Serial Bus, ou Barramento Serial Universal
W3C World Wide Web Consortium
Algoritmo 1 – Código exemplo de envio de informações por meio do shield GSM/GPRS
SIM900 . . . 43
Algoritmo 2 – Código de configuração do Bluetooth com o scanner ELM327 . . . 82
Algoritmo 3 – Código de configuração inicial . . . 83
Algoritmo 4 – Código de envio de comando simples ao scanner OBDII . . . 84
Algoritmo 5 – Código do loop principal do firmware . . . 85
Algoritmo 6 – Código de solicitação e recebimento de RPM do scanner OBDII . . . . 86
Algoritmo 7 – Código de conversão e cálculo de RPM fornecido pelo scanner OBDII . 87 Algoritmo 8 – Código de solicitação, recebimento, conversão e cálculo de velocidade do scanner OBDII . . . 88
Algoritmo 9 – Código de solicitação, recebimento, conversão e cálculo de temperatura do motor do scanner OBDII . . . 89
Algoritmo 10 – Código de solicitação, recebimento, conversão e cálculo de posição do acelerador do scanner OBDII . . . 90
Algoritmo 11 – Código de solicitação, recebimento, conversão e cálculo de nível de combustível do scanner OBDII . . . 91
Algoritmo 12 – Códigos de armazenamento em arquivo e solicitação e recebimento do módulo GPS . . . 92
1 INTRODUÇÃO . . . 1 1.1 OBJETIVOS . . . 2 1.1.1 OBJETIVO GERAL . . . 2 1.1.2 OBJETIVOS ESPECÍFICOS . . . 2 1.2 JUSTIFICATIVA . . . 3 2 REVISÃO DA LITERATURA . . . 4
2.1 TELEMETRIA, RASTREAMENTO E GEOPROCESSAMENTO . . . 4
2.2 ELETRÔNICA AUTOMOTIVA . . . 7 2.2.1 ECU . . . 7 2.2.2 CAN . . . 9 2.2.3 OBDII . . . 10 2.3 COMPONENTES DE HARDWARE . . . 12 2.3.1 MICROCONTROLADORES . . . 12 2.3.2 ARDUINO . . . 14
2.3.3 MÓDULOS E SHIELDS PARA ARDUINO . . . 15
2.3.4 GPS . . . 16
2.3.5 BLUETOOTH . . . 17
2.3.6 REDES GSM . . . 19
2.4 COMPONENTES DE SOFTWARE . . . 20
2.4.1 PROTOCOLOS DE COMUNICAÇÃO E TRANSMISSÃO . . . 20
2.4.2 FORMATOS DE TRANSMISSÃO DE DADOS . . . 21
2.4.3 ARQUITETURA CLIENTE-SERVIDOR . . . 22
2.4.4 LINGUAGENS DE PROGRAMAÇÃO . . . 25
2.4.5 SISTEMA GERENCIADOR DE BANCO DE DADOS . . . 27
2.5 TRABALHOS RELACIONADOS . . . 30
2.5.1 TELEMETRIA DE UM VEÍCULO BAJA SAE ATRAVÉS DE REDE CAN . . . 30
2.5.2 TELEMETRIA AUTOMOTIVA VIA INTERNET MÓVEL . . . 31
2.5.3 UMA ABORDAGEM INTERATIVA PARA AUXILIAR NO DIAG-NÓSTICO AUTOMOTIVO . . . 31
2.5.4 ANÁLISE DOS TRABALHOS CORRELATOS . . . 32
3 MATERIAIS E MÉTODOS . . . 34
ÇÕES . . . 42
3.3 DESENVOLVIMENTO DA CAMADA DE SOFTWARE . . . 43
4 ANÁLISE E DISCUSSÃO DOS RESULTADOS . . . 46
4.1 HARDWAREINSTALADO NO VEÍCULO PARA COLETA DOS DADOS . . 48
4.2 CAMADA DE TRANSMISSÃO DOS DADOS COLETADOS . . . 53
4.3 SERVIDOR DE ARMAZENAMENTO E PROCESSAMENTO DOS DADOS PARA VISUALIZAÇÃO . . . 54
4.4 COMPARAÇÃO DE RESULTADOS COM TRABALHOS CORRELATOS . . 70
5 CONCLUSÃO . . . 73
5.1 TRABALHOS FUTUROS . . . 74
Referências . . . 75
Apêndices
80
APÊNDICE A Apoio à Execução de Trabalhos de Conclusão de Cursos . . . 81APÊNDICE B Códigos Fontes Desenvolvidos . . . 82
APÊNDICE C Quadros de Requisitos . . . 93
APÊNDICE D Quadro de Casos de Uso . . . 97
APÊNDICE E Diagrama de Casos de Uso . . . 98
APÊNDICE F Quadros Expansões dos Casos de Uso . . . 99
APÊNDICE G Diagrama de Classe e Diagrama Entidade Relacionamento . . . 106
Anexos
108
ANEXO A Comandos AT do Módulo Bluetooth HC-05 . . . 1091 INTRODUÇÃO
A frota de veículos aumentou 1,2% em 2017 no Brasil, comparado ao ano anterior. Após dois anos (2015 e 2016) de estabilidade, a quantidade de carros, caminhões e ônibus que circulam no país cresceu, e chegou a 43,371 milhões (SINDIPEÇAS, 2018). Com isso a utilização de um sistema de controle à distância dos recursos de um veículo, pode ser um diferencial para diversas empresas que tem o automóvel como sua principal ferramenta de trabalho (HELLENO, 2014). Fato maximizado se esse tipo de monitoramento ocorrer a custos atrativos. O controle e monitoramento de dados em qualquer área de negócios, traz excelentes resultados em logística, gerenciamento e prevenções, otimizando a atividade e gerando lucros (SILVA, 2015). Empresas de diversos ramos cada vez mais aderem a inovações tecnológicas, que se mostram como uma ótima alternativa para a obtenção de melhores resultados.
Soluções de rastreamento em geral focam principalmente na segurança, mas também podem ser utilizadas para melhoria de logística. Há ainda neste contexto o monitoramento da telemetria veicular, a qual se dá por meio de um processo de comunicação automatizado no qual as aferições e demais dados são coletados e transmitidos ao equipamento receptor para monitoramento em tempo real e análise dos dados objetivando tomada de decisões.
Ao aliar essa evolução tecnológica ao crescimento das frotas veiculares, uma das áreas de interesse se refere à telemetria e rastreamento em veículos, visando diagnosticar e/ou prevenir problemas de forma antecipada em atividades primárias, especialmente em veículos usados em frotas empresariais. Este cenário pode trazer para empresas a possibilidade de monitorar o veículo em tempo real, de forma a instruir o motorista em certos cuidados com relação a manutenção do veículo, auxiliando-o na decisão por rotas melhores para trajetos já conhecidos.
No contexto deste mercado, empresas de telemetria e rastreamento apresentam equi-pamentos inovadores, capazes de monitorar, gerenciar e permitir tomadas de decisões sobre inúmeros parâmetros do veículo. Entretanto ainda há poucas maneiras para monitorar e coletar dados em tempo real de um veículo, o que diminui a possibilidade de gerenciamento pelas empresas de frotas, além de que o gerenciamento dos motoristas e as soluções existentes em geral apresentam custos elevados.
Neste âmbito, este projeto objetiva desenvolver uma solução que tem como principal função obter informações a bordo em tempo real de veículos com datas de fabricação menor que o ano de 2016 e transmiti-las para um software no qual tais dados serão analisados, permitindo o gerenciamento da frota de veículos de forma remota. A proposta é coletar em tempo real os dados do automóvel para que ao serem analisados a empresa possa tomar decisões e orientar melhor sua equipe, visando melhorar o estilo de direção de seus motoristas, e a geração de dados para elaboração de estratégias de redução de custos.
1.1 OBJETIVOS
1.1.1 OBJETIVO GERAL
Desenvolvimento de um sistema de coleta e análise de dados de telemetria e rastrea-mento veicular.
1.1.2 OBJETIVOS ESPECÍFICOS
Para alcançar o objetivo principal, os seguintes objetivos específicos foram delineados: • Pesquisar sistemas de monitoramento eletrônico automotivo;
• Definir um protocolo para coleta, comunicação e tratamento de dados para sistemas automotivos;
• Implementar o protocolo definido;
• Desenvolver um hardware compatível com o protocolo implementado, para coletar dados de veículos e transmitir estes dados;
• Desenvolver um software para manipulação e gerenciamento dos dados coletados e cadastrados de veículos, que possibilite o diagnóstico de problemas e identificação do estilo de direção de seus motoristas.
• Realizar testes com o sistema desenvolvido e comparar seus resultados com imple-mentações relacionadas.
1.2 JUSTIFICATIVA
Empresas que possuem veículos em suas frotas tem dificuldade em gerenciar o uso e a otimização das rotas de seus veículos, especificamente prevendo falhas que ocorrem nos veículos pelo uso inadequado, além de verificar e otimizar a rota de deslocamento. Este problema é dado ao fato em que os motoristas passam muito tempo longe das empresas. Assim, o monitoramento sem o sistema em tempo real dificulta a prevenção, por não possibilitar saber se o motorista está tomando as melhores rotas e os cuidados adequados com o veículo.
Levando em conta também o aumento do comércio eletrônico, o grande território nacional, a exigência em entrega/distribuição eficiente de produtos e a eficiência em logística, a aplicação do monitoramento das telemetrias coletadas traz otimização de processos, informações e produtos no tempo certo e ao menor custo, pontos estes, importantes para a competitividade levantados por PÊGO (2016).
Desta forma, este projeto visa contribuir no sentido de apresentar uma solução para o problema de coletar, analisar e monitorar os dados dos veículos para que as empresas respon-sáveis, possam gerenciar e tomar as melhores decisões em tempo real, independentemente da localização geográfica dos veículos de interesse.
O sistema proposto é de grande importância para gerar um diagnóstico, monitorar e gerenciar os veículos e seus motoristas. Com o monitoramento em tempo real é possível realizar a manutenção do veículo de maneira mais hábil, além de conseguir prever futuras falhas orientando o motorista a tomar melhores cuidados através das informações coletadas.
Com o hardware e o software propostos, aliado ao monitoramento que se faz possível através do módulo GPS, pode-se obter: maior segurança do veículo, análise de melhores rotas e orientações de postos de combustíveis, concessionária e/ou oficinas mais próximas, dentre outros.
Com os benefícios citados, este projeto além da economia que a melhoria em logística traz, após desenvolvido, ele apresentará um custo menor se tratando aos existentes por ser desenvolvido em sua maior parte por hardware e software livres.
2 REVISÃO DA LITERATURA
Na primeira seção da revisão da literatura são apresentados e descritos os conceitos relacionados à telemetria, rastreamento e ao geoprocessamento. Após, é apresentada a teoria ligada a eletrônica automotiva com o intuito de orientar a definição do protocolo de coleta e transmissão de dados obtidos do automóvel.
Na sequência são apresentadas tecnologias (componentes e conceitos de hardware) ligadas ao tratamento, comunicação e recepção dos dados extraídos, a fim de orientar quanto ao desenvolvimento do sistema (microcontroladores, módulos, redes entre outros).
Ficou reservado para a parte de conceitos e componentes de software a penúltima seção da revisão da literatura, onde são apresentadas definições de arquiteturas de sistemas, banco de dados, linguagens de programação e as tecnologias responsáveis por comunicação e tratamento de dados.
Por fim, na última seção, é apresentado o estado da arte (trabalhos e pesquisas aca-dêmicas na área de telemetria e rastreamento automotivo). O propósito desta seção é analisar, relacionar e comentar os trabalhos já realizados pelos pesquisadores sobre a área abordada.
2.1 TELEMETRIA, RASTREAMENTO E GEOPROCESSAMENTO
Conceito que surgiu por volta de 1845, cuja a palavra possui origem grega, onde tele significa “remoto”, e metron significa “medida”, ou seja, a telemetria é a transmissão e recepção automatizadas, onde informações são coletadas em pontos remotos ou inacessíveis. Toda essa comunicação é feita através de rede sem fio, os dados são transmitidos a um equipamento receptor onde é feito o monitoramento. Esse monitoramento permite a análise e manipulação de dados a distância (FERREIRA; ZULLINO; BRIANEZ, 2018).
A telemetria também pode ser definida como um sistema de monitoramento que é utilizado para rastrear, medir e enviar informações de algum equipamento que esteja distante ou inacessível. Um sistema de telemetria geral é composto pelos seguintes pontos: componente a ser analisado, sensores para extração dos dados, meio de comunicação dos dados, receptor e software para análise dos dados (FERREIRA; ZULLINO; BRIANEZ, 2018). A Figura 2.1 ilustra um sistema de telemetria geral e seus pontos.
Figura 2.1 – Pontos de um sistema de telemetria geral
Fonte: O autor.
O intuito principal da telemetria é agilizar e melhorar os objetivos de uma aplicação, com a análise e tomadas de decisões feitas de forma remota, tendo assim o controle da aplicação de qualquer lugar e não somente de onde se localiza a aplicação (SICHONANY et al., 2012). Esta é uma tecnologia muito empregada em diversas áreas, tais como: telemetria residencial, industrial, logística, gerenciamento de produção, entretenimento entre outras. Existem diversas formas de executar a coleta e transmissão dos dados, sendo função do projetista analisar as características da aplicação para identificar qual forma de comunicação será utilizada, neste projeto será analisado uma delas que é a rede celular (GSM - Sistema Global para Comunicações Móveisou / GPRS - Serviços Gerais de Pacote por Rádio ) (SICHONANY et al., 2012).
Segundo Trekken (2018), entre as diversas aplicações da telemetria, o uso em veículos é uma das principais aplicações. Com a principal finalidade de garantir segurança e qualidade do veículo, o sistema de telemetria tem ajudado a minimizar riscos com acidentes de trânsito e a reduzir custos com manutenção veicular e com combustível, alcançando até 25% de redução.
Um dos dados que são coletados em telemetria aplicada a veículos é os dados de rastreamento. Rastreamento refere-se à função de monitorar a localização de algo em tempo real e, assim como o sistema de telemetria, se faz necessária uma comunicação para transmitir essa localização, embora seja menos complexo pois utiliza-se apenas de um sensor GPS - Sistema de Posicionamento Global. Pode-se classificar o rastreamento como uma informação do conjunto de informações do sistema de telemetrias (POZZO, 2017).
Sistemas de rastreamento aplicados a veículos surgiram juntamente com a tecnologia GPS. Tais sistemas dependem desta tecnologia para coletar as informações transmitidas pelos módulos e hardwares instalados no veículo, informações estas como localização, velocidade e direção do veículo, todas coletadas sem a interação ou intervenção do motorista (CHAGAS, 2016). A Figura 2.2 ilustra de forma genérica um sistema de rastreamento veicular.
Figura 2.2 – Rastreamento veicular
Fonte: Silva (2019)
Para se concretizar o rastreamento existe diversas tecnologias a serem estudadas, uma delas é a geoinformática. A geoinformática é uma tecnologia responsável por desenvolver, capturar, armazenar, processar, mapear e disseminar informações geográficas. Sua análise é baseada na análise de dados geográficos (EHLERS, 2008).
Alinhado a geoinformática, o geoprocessamento é responsável por processar os dados de geometria: mapas, imagens ou objetos mapeados. Esses dados devem ter suas referências (longitude, latitude e altitude). A informação geográfica é a área de referência para geoinformação (COSTA, 2012).
Para analisar, capturar e processar os dados são utilizados sistemas de navegação por satélite. O Sistema global por satélite (GNSS) desempenha um papel importante nas questões científicas de navegação de alta precisão, posicionamento e sincronização (EHLERS, 2008).
O GNSS fornece informações tridimensionais de posição e velocidade precisas, contí-nuas, em todo o mundo para os usuários com o equipamento receptor apropriado. Existem as constelações globais dentro do GNSS, às vezes referidas como constelações centrais, consistem em 24 ou mais satélites em órbita terrestre dispostos em 3 ou 6 planos orbitais com 4 ou mais satélites por plano. Uma rede de controle/monitoramento monitora a estabilidade e o status dos satélites. Esta rede também envia dados de navegação e outros dados para os satélites (KAPLAN; HEGARTY, 2017).
2.2 ELETRÔNICA AUTOMOTIVA
Nesta seção serão apresentados conceitos acerca da tecnologia eletrônica embarcada em automóveis.
2.2.1 ECU
Atualmente todos veículos fabricados contam com módulos eletrônicos microprocessa-dos conhecimicroprocessa-dos como ECU – Eletronic Control Unit, ou UCE – Unidade de Controle Eletrônico (PEREIRA, 2013). Essa unidade tem como responsabilidade monitorar, controlar e permitir a realização de diagnósticos do veículo.
Dentre outras funções importantes, os sistemas eletrônicos presentes nos veículos automotivos são responsáveis pela aceleração, injeção eletrônica, computador de bordo, “infotainment” (Palavra originada da junção de “Information” (Informação) e “entreteniment” (Entretenimento)), e assim como os sistemas ADAS (Advanced Driver Assistance Systems – Sistemas Avançados de Auxílio ao Motorista: ex: sistema eletrônico de estabilidade, sistema que auxilia na mudança de faixa dentre outros), garantir um aumento na segurança dos ocupantes do veículo.(OLIVEIRA, 2017, p. 24)
As ECUs controlam entradas e saídas do sistema embarcado. Dessa forma são capazes de receber dados de entrada, processar as informações obtidas, e determinar uma saída específica. Além disto, são responsáveis pelo gerenciamento dos protocolos de comunicação utilizados no veículo que permitem a sinergia entre os módulos do veículo (ANJOS, 2011). A Figura 2.3 apresenta o diagrama de blocos de um módulo eletrônico genérico.
Figura 2.3 – Diagrama de blocos de um módulo eletrônico genérico
Os módulos são formados por um microcontrolador central, responsável pela coorde-nação do processamento e controle das atividades desenvolvidas. As portas de comunicação CAN - Rede da Área do Controlador, LIN - Rede de Interconexão Local e SDI - Interface Digital Serial, se comunicam cada um com seu protocolo de comunicação. Entradas e saídas são responsáveis por receber sinais (digitais ou analógicos) vindos dos sensores e emitir sinais (digitais ou analógicos) controlados pelo módulo eletrônico. Por fim a memória está presente para guardar o software do módulo eletrônico (GUIMARÃES, 2007).
O software do módulo é responsável para que a ECU funcione, e é dividido em três partes: calibração básica, firmware e parâmetros programáveis cada uma delas definidas por (PEREIRA, 2013):
• Firmware: de responsabilidade do fornecedor, grava na memória rotinas básicas do módulo;
• Calibração básica: de responsabilidade do fornecedor, local no qual os engenheiros das montadoras inserem instruções especificas para o funcionamento da ECU; • Parâmetros programáveis: são valores referentes a cada ECU Ex:(velocidade,
com-bustível, temperatura) determinados e gravados em cada módulo.
Nos veículos atuais existem dezenas de módulos, que são denominados de ECUs. Quando se trata de um módulo isolado, há particularidades que denominam cada um deles. Esses módulos são descritos por Oliveira (2017) da seguinte forma:
• MT - Multitimer: módulo responsável pela temporização das funções do veículo (setas, pisca alerta, entre outros);
• BCM – Body Control Module (Modulo de Controle de Carroçaria) ou BEC - Body Eletronic Controller(Controlador Eletrônico de Carroçaria): responsável por diversas funções do veículo, funções estas como controle de seta, farol, sistema de alarme e travas elétricas;
• FZM – Front Zone Module (Módulo da Área Frontal): utilizado para separar as funções do BCM;
• RZM – Rear Zone Module (Módulo da Área Traseira): assim como o FZM, utilizado para separar as funções do BCM;
• DZM – Door Zone Module (Módulo da Área de Portas): assim como o FZM e o RZM, utilizado para separar as funções do BCM;
• CIM Column Integration Module (Módulo de Integração da Coluna): assim como o FZM, o RZM e o DZM, utilizado para separar as funções do BCM;
• ECM – Engine Control Module (Módulo de Controle do Motor): módulo responsável por todas as funções do motor;
• TCM – Trasmission Control Module (Módulo de Controle da Transmissão): respon-sável pelas funções de transmissão;
• PCM – Powertrain Control Module (Módulo de Controle Motor - Transmissão): módulo que controla a interação entre motor e transmissão;
• TCU – Telematics Control Unit (Unidade de Controle de Telemática): controla funções de navegação do veículo;
2.2.2 CAN
O sistema ou protocolo CAN é um padrão de comunicação que permite que os vários módulos e computadores conversem entre si, este padrão é muito utilizado em veículos. Essa comunicação é dada através de um barramento de dados e um sistema de fiação que liga os módulos. Isso permite que todos os módulos e dezenas de outros sistemas sejam interconectados eletronicamente (PEREIRA, 2013).
Os sistemas elétricos de rede CAN surgiram nos veículos em 2003. Desde então, cada vez mais veículos foram equipados com sistemas CAN. A partir de 2008 praticamente todos os carros e caminhões leves possuíam o sistema de rede CAN (SOUZA; CAMPOS, 2017).
O sistema de barramento CAN tornou-se padrão para a aplicação do veículo. As unidades de controle eletrônico dos vários sistemas de veículos não são mais integradas por uma pluralidade de linhas individuais, mas conectadas através de um barramento de dados em uma rede. Isso elimina a variedade de conexões elétricas e leva a erros reduzidos (SOUZA; CAMPOS, 2017).
O protocolo CAN funciona de acordo com o princípio de conexão multi-mestre, no qual várias unidades de controle eletrônico da mesma prioridade são conectadas umas às outras através de uma estrutura linear. A vantagem deste tipo de princípio multi-mestre é que um erro em um dos membros da rede não impede o acesso aos outros. Em comparação com outras redes, a probabilidade de uma falha total é reduzida. Na rede circular ou estrela, o erro de um dos membros ou na unidade central é suficiente para causar uma falha geral do sistema (TEIXEIRA; TOURNIER, 2015).
CAN é um protocolo de comunicação digital serial, no qual a transmissão de dados é baseada nas mensagens geradas pelos quadros de bits cada um com uma função específica. Nestes quadros de bits, o campo de identificação identifica a prioridade de cada mensagem. O valor do identificador de mensagem na rede CAN é único. Este valor também caracteriza a prioridade da mensagem, quanto menor o valor maior é a prioridade de mensagem (BOSCH, 2006).
O sinal CAN digital é representado por um bit dominante e um bit recessivo que varia entre os dois fios da rede, onde um bit dominante sobrescreve eletricamente um recessivo. O mecanismo de acesso intermediário é baseado no conceito de CSMA/CD (Acesso Múltiplo com Detecção de Portadora e com Detecção de Colisão). Ao verificar o status do barramento, os primeiros módulos enviam suas mensagens. Com base no valor de identificação, o módulo com uma indicação de baixa prioridade conclui a transmissão e continua sua mensagem a partir desse ponto. Isso ocorre sem reiniciar o módulo com a mensagem de prioridade mais alta, arbitrariamente por um destruidor aleatório ou “lógico”, que atua quando dois ou mais módulos realizam uma transmissão (GODOY et al., 2010). A Figura 2.4 apresenta o formato dos quadros
de bits no formato padrão e no formato estendido.
Figura 2.4 – Formato dos quadros de bits do modelo CAN
Fonte: O autor.
Como supracitado, o protocolo CAN é baseado em mensagens que não necessitam de um gerenciador, já que as mensagens são enviadas multicast (todos os nós existentes na rede recebem as mensagens). O protocolo CAN busca readequar as diversas redes de comunicação já existentes, com uma solução mais leve, simples, eficiente e de menor custo. (CORRIGAN, 2008). A Figura 2.5 contém um diagrama que exemplifica a topologia CAN.
Figura 2.5 – Topologias de rede sem e com CAN
Fonte: O autor.
2.2.3 OBDII
Por volta dos anos 60 as montadoras dos EUA foram obrigadas a tomar medidas para amenizar a emissão de poluentes, pois a legislação na época determinou limites máximos de emissão de gases poluentes no veículo. Com isso as fabricantes introduziram diversos dispositivos
eletrônicos que precisavam ser supervisionados e diagnosticados. Assim surge o padrão OBD (On-Board Diagnostic - Diagnóstico a Bordo), um padrão responsável pelo diagnóstico destes novos dispositivos (ZALDIVAR et al., 2011).
Os principais objetivos do OBD são reduzir as emissões de gás do veículo, reduzir o tempo entre a ocorrência de um erro, reconhecê-lo e auxiliar na correção do problema. Para atingir esses objetivos, determinou-se que os testes deveriam ser realizados nas unidades de controle eletrônico e que a padronização também deveria ocorrer entre as ECUs e os scanners (equipamento de teste OBD), o que levou esses scanners se tornarem “genéricos” (COX, 2006).
O primeiro padrão OBD foi o OBDI criado em 1988. Tinha a função de detectar altas taxas de emissão dos gases. Passado o tempo alguns automóveis mais novos estavam passando pelo teste, mesmo que não estivessem aptos, neste cenário surge o OBDII, atualizando as especificações da primeira versão. Esse padrão de diagnóstico é utilizado até hoje (MACHADO; OLIVEIRA, 2008).
Atualmente existem scanners para que o usuário tenha possibilidade de acessar diversas informações específicas do veículo. A interação do scanner com o veículo é feita por meio do DLC (Data Connector Link - Link do Conector de Dados). A sua posição no veículo pode variar de montadora, porém este geralmente se encontra em algum ponto do painel. A Figura 2.6 apresenta o conector padrão OBDII, sua posição em alguns veículos e sua conexão.
Figura 2.6 – Canal OBDII
Fonte: Nefor (2010)
A partir da última revisão do padrão, ampliou-se as exigências para um monitoramento mais detalhado. Segundo Oliveira (2017), atualmente é exigido que o padrão OBDII garanta acesso aos seguintes componentes.
• Controle
– Distance MilOn (distância percorrida com avisos luminosos ligados); – DTC Number (número identificador do DTC);
– Trouble Code (código da falha, atua em conjunto com o código do DTC). • Motor
– RPM (rotações por minuto) ;
– Run Time (tempo em funcionamento); – Mass Air Flow (fluxo de ar em massa); – Throttle Position (posição do acelerador). • Combustível
– Fuel Type (tipo de combustível); – Consumption Rate (taxa de consumo); – Fuel Level (nível de combustível);
– Air Fuel Ratio (relação do combustível de ar); – Oil Temp (temperatura do óleo).
• Pressão
– Barometric Pressure (pressão barométrica); – Fuel Pressure (pressão de combustível);
– Fuel Rail Pressure (pressão do trilho de combustível); – Intanke Mainfold Pressure (pressão do coletor de admissão). • Temperatura
– Air Intanke Temperature (temperatura de admissão de ar); – Ambient Air Temperature (temperatura ambiente);
– Engine Coolant Temperature (temperatura do líquido de arrefecimento do motor).
• Velocidade
2.3 COMPONENTES DE HARDWARE
Nesta seção serão apresentados, teorias, conceitos e tecnologias inerente ao desenvolvi-mento de hardware.
2.3.1 MICROCONTROLADORES
O microcontrolador é um pequeno computador montado em um circuito integrado, o qual contém um núcleo de processador, memórias e periféricos programáveis de entrada e saída (RODRIGUES, 2011). Basicamente é um hardware que possui uma enorme versatilidade, além de possuir flexibilidade de programação, reúnem neste circuito vários sistemas independentes como contadores, CPU, memórias RAM, memória ROM entre outros.
Os microcontroladores surgiram após os circuitos digitais, como uma evolução devido ao aumento da complexidade dos circuitos. Onde ocorreu a substituição da lógica das portas
digitais por um conjunto de processador e software que apresentou além de eficiência menor custo (PENIDO; TRINDADE, 2013).
Os microcontroladores possuem diversas características que divergem um modelo do outro, alguns possuem arquitetura CISC(Computador com um Conjunto Complexo de Instru-ções), estes recebem instruções complexas em relação a arquitetura RISC(Computador com um Conjunto Reduzido de Instruções) (TANENBAUM, 2013).
Existe uma outra classificação quanto às arquiteturas que definem o modelo do micro-controlador, as arquiteturas de Von Neumann e Havard (TANENBAUM, 2013). Para representar uma das arquiteturas e exemplificar um modelo de microcontrolador, a Figura 2.7 ilustra a arquitetura de Von Neumann.
Figura 2.7 – Modelo de microcontrolador com arquitetura de Von Neumann
Fonte: O autor.
Como supracitado o microcontrolador possui diversos sistemas independentes cada um deles pode ser definido da seguinte maneira segundo (VALDÉS; ARENY, 2007).
• CPU ou microprocessador é o cérebro do microcontrolador e atua sob a unidade de controle do programa armazenado na memória. A CPU está basicamente encarregada em trazer as instruções do programa da memória, interpretá-las e executá-las. A CPU também inclui os circuitos para realizar operações lógicas aritméticas e elementares com os dados binários, na chamada Unidade Lógica e Aritmética (ULA).
• O acumulador é o registrador associado às operações aritméticas e lógicas que podem ser executadas na ULA. Em qualquer operação, um dos dados deve estar no acumulador e o resultado é obtido no acumulador;
• A memória do microcontrolador é o local onde as instruções do programa e os dados que manipula são armazenadas.
• A entrada e saída é particularmente importante em microcontroladores, porque através dele o microcontrolador interage com o exterior.
Conhecido também como computador de um chip, este hardware é ideal para sistemas compactos e aplicações especificas. Para atender a todas as necessidades de desenvolvimento é necessário utilizar um microcontrolador que apresente as características necessárias, ser um componente de baixo custo, fácil acesso e de conhecimento do desenvolvedor (RODRIGUES, 2011).
2.3.2 ARDUINO
O Arduino é uma plataforma de hardware livre. Este hardware pode ser copiado, modificado e redistribuído por qualquer usuário gratuitamente. Os usuários possuem livre acesso e fazem alterações conforme as suas necessidades (MCROBERTS, 2018).
O Arduino não caracteriza-se como um microcontrolador, mas sua sua arquitetura geral inclui um microcontrolador, que em geral é o Atmega328p (MCROBERTS, 2011). A Figura 2.8 apresenta um exemplo do microcontrolador Atmega328p.
Figura 2.8 – Imagem do microcontrolador Atmega328p
Fonte: Microchip (2018)
Produzido com o intuito acadêmico, essa plataforma suporta a conexão de diversos dispositivos, nele é capaz de se processar entradas e saídas para estes dispositivos. O Arduino além de se comunicar com estes dispositivos também é capaz de se comunicar com computadores e diversos outros hardwares. Os possíveis componentes que podem ser conectados ao Arduino são: sensores de pressão, sensores de presença, sensores de distância, sensores de temperatura, sensores em geral, interruptores, motores, módulos Ethernet, LEDs, displays de matriz de pontos ou qualquer outro dispositivo que possa emitir dados ou possa ser controlado (RODRIGUES, 2011).
O Arduino possui uma arquitetura de entrada e saída para controlar esses dispositivos, existe também um cristal oscilador usado para o clock, um regulador linear de cinco volts, uma
saída USB dentre outros recursos que podem variar dependendo de cada modelo do Arduino. Há dois componentes que se destacam do Arduino, a saber: o microprocessador e o microcontrolador, e que apresentam variação entre cada modelo do Arduino (RODRIGUES, 2011). A Figura 2.9, apresenta diversos modelos de Arduinos.
Figura 2.9 – Diversos modelos de Arduino
Fonte: Quora (2013)
2.3.3 MÓDULOS E SHIELDS PARA ARDUINO
O Arduino trabalha com soluções especificas, para melhorar, agilizar e otimizar toda criação de hardware. Utilizando-se da plataforma Arduino, existem os módulos que na maioria de suas aplicações se dão em sensores, meios de comunicação dentre outros.
Existem também expansões de hardware chamadas Shields, são módulos especifica-mente projetados para encaixar no Arduino. Uma vez conectado ao Arduino mantém todas as portas e possibilidades de usar a plataforma adicionando alguma especialização ao microcon-trolador. A proposta destas expansões é bem parecida com a ideia de frameworks em software, é uma abstração que une funções comuns entre vários projetos provendo uma funcionalidade genérica, possibilitando a realização de atividades especificas. Existem Shields e módulos para as mais diversas aplicações como apresentado por Bentes (2013).
• Conectividade em rede Ethernet; • Conectividade em rede Zigbee;
• Conectividade em rede Wireless 802.11; • Controle de motores;
• Funcionalidade GPS; • Middleware Android; • Controle de Relés; • Bluetooth; • Sintetizador de Voz. 2.3.4 GPS
Existem diversos tipos de GNSS, o mais conhecido por usuários comuns é o GPS. Com o seu projeto iniciado em 1973, teve sua criação por meio de fundos do Departamento de Defesa dos Estados Unidos para se obter a posição instantânea e a velocidade de um ponto sobre a superfície terrestre. Seu funcionamento é considerado estável desde 1995 (ASSIS, 2010).
O GPS é composto por três segmentos, estes segmentos são: constelação de satélites, rede de controle/monitoramento de solo e equipamento de recepção de usuários. A constelação de satélites é o conjunto de satélites em órbita que fornece os sinais de alcance e as mensagens de dados ao equipamento do usuário. O segmento de controle rastreia e mantém os satélites no espaço. O segmento de controle também monitora a saúde do satélite e a integridade do sinal e mantém a configuração orbital dos satélites. Além disso, o segmento de controle atualiza as correções do relógio de satélite, além de vários outros parâmetros essenciais para determinar a posição, a velocidade e o tempo do usuário (KAPLAN; HEGARTY, 2017).
O GPS consiste em até 32 satélites que transmitem sinais de micro-ondas para receptores GPS individuais. Esses satélites orbitam continuamente a Terra, permitindo que o sistema GPS calcule com precisão sua posição na superfície da Terra. Assim, o receptor GPS consiste de uma antena sintonizada na frequência desses satélites e um relógio de alta precisão (POZZO, 2017). O Quadro 1 apresenta as vantagens e desvantagens mais significativas de se utilizar a tecnologia GPS.
Quadro 1 – Vantagens e Desvantagens GPS.
Vantagens Desvantagens
Abrangência mundial. Não funciona em ambientes fechados (túneis,
garagens, etc.). Adotado em 80% dos sistemas que
utilizam GNSS.
Os sinais dos satélites podem ser obstruídos por pontes, viadutos, edifícios e matas.
Precisão de metros. A geometria desfavorável dos satélites pode
di-minuir a precisão do posicionamento. Não há custo de implantação e
ope-ração.
O multicaminhamento, ou seja, a reflexão do si-nal em algum objeto (como um prédio) interfere na precisão das coordenadas.
O preço dos equipamentos recepto-res vem diminuindo.
Os receptores, ao serem ligados ou após perde-rem a comunicação com o satélite, levam certo tempo para reiniciar a aquisição de dados. Fonte: Assis (2010)
Em razão da confiabilidade proporcionada pelo GPS, após ser liberada, cresceu expo-nencialmente o número de usuários dos mais variados seguimentos e aplicações, quer seja em navegações, posicionamento geográfico, agricultura e no controle de frotas. Esse crescimento fez com que fosse desenvolvido ferramentas que auxiliasse no recebimento e tratamento dos dados, os chamados módulos e shields que facilitam qualquer aplicação, por tornar menos dispendioso o projeto e desenvolvimento de hardware e software.
O módulo GPS atua coletando informações de satélites realizando monitoramento na localização, tempo e velocidade. Quando acoplado com o Arduino permite a coleta da localização em tempo real, se comunicando direto com Arduino. O tratamento dessas informações é dado via programação no Arduino (ORTH et al., 2004). A Figura 2.10 ilustra um exemplo de módulo GPS.
Figura 2.10 – Imagem de um módulo GPS
Fonte: FILIPEFLOP (2018)
2.3.5 BLUETOOTH
Dada a constante evolução da tecnologia sem fio durante os últimos anos, fabricantes observaram uma oportunidade de mercado com a necessidade do consumidor em remover fios, melhorar o visual e facilitar o uso de diversos dispositivos como impressoras, telefones, mouses, teclados entre outros. Com isso a tecnologia Bluetooth surge como um padrão aberto que permite que vários dispositivos se comuniquem um com o outro em uma faixa nominal de distância (RAPPAPORT, 2009).
A tecnologia Bluetooth, também conhecida como uma tecnologia de substituição de cabos opera sobre uma curta faixa (curta distância), baixa potência e a um custo baixo. Opera na faixa de 2,4 GHz utilizando multiplexação por divisão de tempo com intervalos de 625 microssegundos. Não exige uma infraestrutura de rede (por exemplo, um ponto de acesso) para comunicação entre os dispositivos (KUROSE; ROSS, 2014). A Figura 2.11 apresenta um exemplo de aplicações do Bluetooth.
Figura 2.11 – Aplicações Bluetooth
Fonte: Teleco (2018)
Para realizar a comunicação Bluetooth, um dos dispositivos é dado como mestre, ele é responsável pela comunicação entre os dispositivos denominados escravos. Esse dispositivo é quem controla o tempo e os tamanhos de arquivos para a comunicação (KUROSE; ROSS, 2014).
As aplicações do padrão Bluetooth se expandiram na última década. Diversas soluções utilizam desta tecnologia onde exige-se uma comunicação de baixo custo e sem fio. Com isso, módulos entre outros dispositivos foram criados para facilitar a implementação desta comunicação.
O módulo Bluetooth possibilita a conexão entre o Arduino e dispositivos com Bluetooth. Desse modo, é possível controlar sensores e outros dispositivos ligados ao Arduino à distância, usando um smartphone ou tablet, sem necessidade do Arduino estar conectado com cabos ao sensor (ALVAREZ; ANTUNES, 2014). Ressalta-se que a comunicação entre o módulo e o Arduino se dá pela comunicação serial, sendo os dados apenas transmitidos pelo Bluetooth. A Figura 2.12 apresenta um exemplo de módulo Bluetooth.
Figura 2.12 – Exemplo de módulo Bluetooth
2.3.6 REDES GSM
A rede GSM é um padrão internacional que foi desenvolvido na intenção de uniformizar os sistemas celulares, ou seja, unificar os padrões de telefonia celular. Desenvolvido pela ETSI (European Telecommunications Standards Institute), este padrão veio como solução pois os padrões existentes divergiam muito um para com os outros. O GSM foi o primeiro padrão digital a ser utilizado comercialmente, ele provê transferência de voz e de dados através de comutação por circuito, a rede GSM é composta por várias entidades, as quais estão agrupadas em três subsistemas: Estação móvel (MS - Mobile Station), sistema de estação base (BSS - Base Station System) e subsistema de rede (NS - Network Subsystem) (GADDO, 2007).
A MS consiste em um equipamento móvel ou hospedeiro. Neste contexto a estação móvel é um smartcard chamado SIM (Subscriber Identity Module - módulo de identificação do assinante). O SIM provê ao usuário acesso a serviços específicos, de acordo com o perfil do usuário, independentemente de como é utilizado (GADDO, 2007).
BSS é formado por dois componentes, a saber: BSC (Base Station Controller - Contro-lador de Estação Base) e BTS (Base Transceiver Station - Antena Transceptora). A BTS define uma célula e controla os protocolos de links de rádio com a MS. O BSC gerencia os recursos de rádio para uma ou mais BTSs, sendo responsável pelo estabelecimento de chamadas e saltos de frequência (GADDO, 2007).
O principal componente do NS é o MSC (Mobile Switching Center - Centro de Comu-tação Móvel). Este funciona como um switch, decidindo qual caminho o tráfego de informações deve seguir, e provê funções necessárias para o gerenciamento de um usuário, como registro, autenticação e atualização de localização (GADDO, 2007).
O Shield GSM/GPRS é responsável pela comunicação dos dados com qualquer opera-dora telefônica, o shield possui todos os componentes necessários para realizar a interface entre o Arduino e o módulo de celular. Permitindo realizar os serviços de SMS (Serviço de Mensagens Curtas), GSM/GPRS, TCP/IP (Protocolo de Controle de Transmissão/Protocolo de Internet) no projeto com o Arduino. Adicional ao shield é necessário o uso de um chip de qualquer operadora SIM e uma antena (ZAGHLOUL, 2014). A Figura 2.13 ilustra um shield GSM/GPRS.
Figura 2.13 – Shield GSM/GPRS
Fonte: Waveshare (2017)
2.4 COMPONENTES DE SOFTWARE
Nesta seção serão apresentados, teorias, conceitos e tecnologias inerente ao desenvolvi-mento de software.
2.4.1 PROTOCOLOS DE COMUNICAÇÃO E TRANSMISSÃO
Protocolos de comunicação são como uma linguagem usada pelos membros de uma rede, um conjunto de procedimentos, regras ou especificações estabelecidos ou aceitos de forma que especifiquem e realizem uma comunicação. Estes protocolos definem formatação, integridade e transmissão de dados. Resumindo, um protocolo de rede especifica o vocabulário e regras para comunicação de dados (GALLO, 2003).
É também possível afirmar que protocolos permitem especificar a comunicação sem conhecer os detalhes de hardware de uma rede. Exemplos de protocolos considerando uma rede Ethernetsão os detalhes do formato do quadro Ethernet, o significado de campos de cabeçalho, a ordem como os bits são transmitidos, entre outros (COMER, 2014).
Os protocolos além de especificar, cuidam de possíveis problemas em uma comunicação. Eles podem lidar com os seguintes problemas segundo Comer (2014): falhas de hardware (os nós específicos em uma comunicação podem falhar e os protocolos podem detectar e recuperar essas falhas), congestionamento de rede (o protocolo precisa identificar o congestionamento de tráfego e controla-lo), atraso de pacotes ou perda de pacotes (os pacotes podem sofrer atrasos ou se perderem na comunicação, o protocolo precisa garantir que isso não aconteça).
Um exemplo muito utilizado de protocolos são os protocolos individuais que fazem parte do protocolo de transmissão TCP/IP. O TCP/IP é a base da internet. Embora o TCP/IP especifique dois protocolos em particular (TCP e IP), ele é usado para um conjunto de protocolos (GALLO, 2003).
de cinco camadas chamado de modelo de referência de TCP/IP. Cada camada tem seu protocolo e sua responsabilidade em uma transmissão. As quatro camadas definem o processamento de pacotes e uma quinta camada responsável por definir o hardware de rede convencional (COMER, 2014). A Figura 2.14 especifica as camadas, suas funcionalidades mostrando o tipo dos objetos que passam entre as camadas.
Figura 2.14 – Camadas do modelo TCP/IP
Fonte: adaptada de Comer (2014)
2.4.2 FORMATOS DE TRANSMISSÃO DE DADOS
Importante na transmissão de dados, o formato de dados é uma forma de representar o dado que será transmitido. Um dos formatos mais antigos é o XML (Linguagem Extensível de Marcação) ele apresenta-se como forma tradicional de solicitar e receber dados por meio de uma comunicação. No entanto existem outros formatos que podem representar os dados de forma estruturada. Um deles é o JSON (Notação de Objetos JavaScript) (EULÁLIO; SOUZA, 2015). O XML é um formato de texto simples e bem flexível derivado de SGML (Standard Generalized Markup Language ou Linguagem padrão de marcação generalizada). O XML começou em 1995, foi proposto para o W3C no mesmo ano, e em fevereiro de 1998 foi reconhecido como um padrão W3C (World Wide Web Consortium) (XML 1.0). Ele é uma linguagem padronizada que usa elementos e atributos para descrever dados (LIN et al., 2012).
A especificação da linguagem XML garante que a forma de dados em série de XML tenha boa segurança. Ao mesmo tempo, a escalabilidade das tags da linguagem XML permite que os desenvolvedores configurem dependendo das características da aplicação. Os dados organizados por XML são uma estrutura em árvore. No processo de transferência de dados, o XML sempre manteve relações de hierarquia dos elementos. Isso o torna lento em comparação aos outros tipos (WANG, 2011).
A Figura 2.15 mostra um exemplo simples de como o XML descreve os elementos de dados. O dado enviado nesse exemplo é uma lista de classes que dão uma descrição de uma rota. Esta classe tem apenas três atributos: ID, DESCRICAO E COORDENADA.
Figura 2.15 – Exemplo de código XML
Fonte: O autor.
JSON foi baseado em um subconjunto de JavaScript. Ele é um formato de dados leve principalmente em relação ao XML, é mais simples e fácil para as máquinas analisarem e gerarem, seu formato é diferente do XML que usa tags fechadas (WANG, 2011).
O JSON usa um formato de texto completamente independente, os objetos são analisa-dos como matrizes de string, isso o torna mais rápido. Em comparação com XML, JSON tem maior eficiência de análise e vantagens de fácil implementação, menos seguro mas tem bom suporte da linguagem de programação JavaScript (LIN et al., 2012).
A Figura 2.16 mostra um exemplo simples de como o JSON descreve os elementos de dados. O dado enviado nesse exemplo é o mesmo do exemplo do XML.
Figura 2.16 – Exemplo de código JSON
Fonte: O autor.
2.4.3 ARQUITETURA CLIENTE-SERVIDOR
A arquitetura de sistemas diz respeito principalmente as atividades e ao processamento de programas de aplicação, assim como a comunicação entre eles. É um requisito fundamental se tratando de sistemas em geral. Suas particularidades exercem grande impacto nas arquiteturas de rede e de hardware. (ENGLANDER, 2011). A forma em que os dados dos sistemas são organizados tanto quanto ao cenário e ao fluxo do processamento dos dados entre organizações e ambientes é de responsabilidade da arquitetura de sistemas (TANENBAUM; STEEN, 2007).
Existem diversas arquiteturas de sistemas, contudo a maioria se baseia no modelo simples cliente-servidor. A Figura 2.17 apresenta um exemplo do modelo simples cliente-servidor.
Figura 2.17 – Modelo simples Cliente-Servidor
Fonte: O autor.
A arquitetura cliente-servidor é uma infraestrutura modular, versátil e baseada em serviços que foi projetada para melhorar a usabilidade, flexibilidade, interoperabilidade e es-calabilidade, em comparação com a antiga arquitetura centralizada (comum dos anos 70) dos mainframese timeshares. A arquitetura cliente-servidor é um conceito para descrever as comuni-cações entre consumidores de serviços (clientes) e provedores de serviços (servidores) (UMAR, 1993).
Em um modelo cliente-servidor, um sistema em um computador cliente aceita serviços e recursos de um sistema em um computador servidor, estes serviços e recursos podem ser programas de aplicação, serviços de processamento, serviços de banco de dados, serviços web, serviços de arquivos entre outros, até mesmo serviços de inicialização do sistema computacional (ENGLANDER, 2011).
Um cliente é quem requisita um serviço de um servidor enviando uma requisição e esperando pela resposta do servidor. Já o servidor é quem implementa um serviço especifico, por exemplo, um serviço de sistema de arquivo ou um serviço de banco de dados. (TANENBAUM; STEEN, 2007).
O modelo cliente-servidor é dividido em três camadas básicas, como ilustra a Figura 2.18. As três camadas são aplicação, serviços de sistemas e hardware. A camada de aplicação é responsável pelos processos da aplicação do sistema. Ela é responsável por garantir o processo cliente-servidor. A camada de serviços de sistemas engloba o sistema operacional e o sistema operacional de rede, é nesta camada que se é feito o controle do hardware. Para finalizar a camada de hardware, onde estão localizados os periféricos ligados aos clientes e servidores (CRUZ, 2004).
Figura 2.18 – Camadas do modelo Cliente-Servidor
Fonte: O autor.
A arquitetura cliente-servidor além de descrever a relação e o comportamento de um ou mais computadores em aplicações especificas, ela não depende de hardware específico ou especial para isso, pois o software de comunicação encapsulado no sistema operacional de cada computador fornece os recursos para a comunicação (ENGLANDER, 2011).
Como supracitado existem vários sistemas que utilizam da estrutura cliente-servidor. A aplicação geralmente mais utilizada é a de banco de dados usando processos SQL (Linguagem de Consulta Estruturada) de front-end, para acessar remotamente as bases de dados. A Figura 2.19 mostra diversos sistemas que utilizam a arquitetura cliente-servidor (CRUZ, 2004)
Figura 2.19 – Diversos sistemas Cliente-Servidor
Os servidores web possibilitam trabalhar com os serviços web onde os mesmos podem ser publicados, localizados e invocados através da Internet. Eles são independentes de linguagem de programação e de sistema operacional. Os serviços web são de fáceis implementação e integração com os sistemas. Utilizam protocolos padrões para comunicação e sua arquitetura é o de cliente-servidor (TANENBAUM; STEEN, 2007).
Existe nas aplicações mais utilizadas uma aplicação do cliente-servidor onde existem servidores de banco de dados dedicados juntos com o servidor de arquivos. Essa alternativa, diminui o fluxo de informações trafegadas na rede, pois somente a resposta da consulta é retornada ao cliente, ao invés de transferir todo o arquivo como era feito no sistema com somente servidor de arquivo. Além do ganho em performance, este tipo de estrutura possibilita um número maior de ligações simultâneas de diversos clientes com diversos servidores (RENAUD, 1994). A Figura 2.20 ilustra como funciona um dos processos mais utilizados quando se trata de aplicações de cliente-servidor.
Figura 2.20 – Servidor de Banco de Dados
Fonte: Cruz (2004)
2.4.4 LINGUAGENS DE PROGRAMAÇÃO
Linguagens de programação são um conjunto de palavras predefinidas, combinadas em um programa de acordo com regras definidas. Essas regras são chamadas de sintaxe. As linguagens de programação facilitam a expressão e comunicação de ideias entre pessoas e o computador. Comparado às linguagens naturais elas tem expressões reduzidas (TUCKER; NOONAN, 2009).
É importante para um desenvolvedor conhecer as particularidades da linguagem em qual ele trabalha. Mas se tratando de um contexto mais amplo, considerando a maioria das linguagens de programações, é interessante entender que elas possuem três princípios. São eles, sintaxe, nomes e tipos e semântica. Tucker e Noonan (2009) os descrevem da seguinte maneira:
• Sintaxe - a sintaxe de uma linguagem descreve o que forma um programa estrutural-mente correto, nela é definido gramática da linguagem, conjunto básico de palavras e símbolos entre outras regras;
• Nomes e tipos - o vocabulário de uma linguagem de programação tem o conjunto de regras e definições de como nomear entidades, variáveis, funções, classes, parâmetros, etc;
• Semântica - semântica é o sentido, o significado de um programa, cada linguagem lida com um sentido diferente. O significado é referente ao efeito de cada comando sobre os valores dos nomes e tipos.
Atualmente as linguagens de programação possuem uma classificação de acordo com o método em que ela é utilizada para ser aplicada. Podemos dizer então que um paradigma de programação é a maneira de se classificar as linguagens de programação de acordo com suas funcionalidades. As linguagens de programação são divididas em quatro paradigmas: procedural ou imperativo, orientado a objetos, funcional e declarativo (FOROUZAN; MOSHARRAF, 2007). A Figura 2.21 ilustra os quatro paradigmas citados e lista alguns exemplos para cada qual.
Figura 2.21 – Paradigmas de Linguagem de Programação
Fonte: adaptada de Forouzan e Mosharraf (2007)
Um exemplo de linguagem de programação procedural que está entre as três mais utilizadas é a linguagem de programação C. Ela é muito utilizada didaticamente e também para o desenvolvimento de sistemas embarcados. É considerada uma linguagem de nível médio, não tão próxima da linguagem de máquina para ser considerada de baixo nível, nem tão distante para ser considerada de alto nível. Como uma linguagem de nível médio, a linguagem C permite manipulação de endereços, bits e bytes (SCHILDT; MAYER, 1996).
Existem linguagens que suportam mais de um paradigma. São chamadas de multi-paradigmas. Um exemplo de linguagem multi-paradigmas é o PHP ou pela tradução livre da abreviação “Pré-processador de Hipertexto”. O PHP é uma linguagem de script de código aberto
