PONTIFÍCIA UNIVERSIDADE CATÓLICA DO...

54
PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ ESCOLA POLITÉCNICA CURSO DE ENGENHARIA DA COMPUTAÇÃO CAIQUE SALES SIQUEIRA RAFAEL FERREIRA RIBEIRO DRIVER BEHAVIOR MONITOR (DBM) PROJETO FÍSICO PROFESSOR ORIENTADOR: AFONSO FERREIRA MIGUEL ________________________________ Afonso Ferreira Miguel SEGUNDO BIMESTRE Curitiba, 21 de novembro de 2018

Transcript of PONTIFÍCIA UNIVERSIDADE CATÓLICA DO...

PONTIFÍCIA UNIVERSIDADE CATÓLICA DO PARANÁ

ESCOLA POLITÉCNICA

CURSO DE ENGENHARIA DA COMPUTAÇÃO

CAIQUE SALES SIQUEIRA

RAFAEL FERREIRA RIBEIRO

DRIVER BEHAVIOR MONITOR (DBM)

PROJETO FÍSICO

PROFESSOR ORIENTADOR:

AFONSO FERREIRA MIGUEL

________________________________

Afonso Ferreira Miguel

SEGUNDO BIMESTRE

Curitiba, 21 de novembro de 2018

RESUMO

Muitas empresas de transporte sofrem por não ter um feedback claro da forma

com que seus motoristas conduzem os veículos da frota. Além de problemas

mecânicos, esta falta de informação pode causar problemas na imagem da empresa,

pois os condutores podem, além de diminuir a vida útil do veículo, se envolver em

acidentes ou apresentar um mau comportamento no trânsito.

Este projeto tem como objetivo a implementação de um perfil para o motorista,

a partir do tratamento de dados em SAS/SQL, obtidos de um sistema responsável por

monitorar os diferentes sinais dos veículos (via OBDII), identificando os que possam

classificar os motoristas quanto a qualidade de sua direção. O controlador a ser

utilizado será o Raspberry Pi 3 Model B, o qual receberá os sinais, via Bluetooth, do

OBDII e guardará os resultados em arquivos .TXT, até que possa se conectar com

uma rede wifi e transmiti-los para a nuvem, para serem integrados no database da

ferramenta SAS, o qual fará o tratamento gerando a informação necessária para

obtenção do perfil do motorista.

Palavras-chave: Projeto. Raspberry Pi. OBDII.

SUMÁRIO

1 INTRODUÇÃO ........................................................................................................ 4

1.1 PROBLEMA .......................................................................................................... 4

1.2 ESCOPO ............................................................................................................... 6

1.3 ESTRUTURA DO DOCUMENTO ......................................................................... 7

2 DETALHAMENTO DO PROJETO .......................................................................... 7

2.1 CENTRAL ELETRÔNICA ..................................................................................... 8

2.2 OBDII .................................................................................................................... 9

2.3 ACELERÔMETRO .............................................................................................. 10

2.4 RASPBERRY PI ................................................................................................. 12

2.5 NUVEM ............................................................................................................... 16

2.6 BANCO DE DADOS ........................................................................................... 17

3 CRONOGRAMA ................................................................................................... 21

4 PROCEDIMENTOS DE TESTE E VALIDAÇÃO DO PROJETO .......................... 24

4.1 TESTES DE CAIXA PRETA ............................................................................... 24

4.1.1 CARREGAMENTO DO SISTEMA ................................................................. 24

4.2 TESTES DE CAIXA BRANCA ............................................................................ 25

4.2.1 CONEXÃO COM O OBDII .............................................................................. 25

4.2.2 AQUISIÇÃO DOS DADOS DO AUTOMÓVEL ............................................... 25

4.2.3 CONEXÃO COM O SERVIDOR ..................................................................... 25

5 RISCOS ................................................................................................................ 26

6 RESULTADOS OBTIDOS .................................................................................... 26

7 CONCLUSÃO ....................................................................................................... 31

REFERÊNCIAS ......................................................................................................... 32

4

1 INTRODUÇÃO

1.1 PROBLEMA

A gestão de frotas de veículos está presente em inúmeros tipos de negócio,

bem como no âmbito pessoal, de modo que encontrar um padrão único e preciso, o

qual determina a atitude do usuário do automóvel, é uma tarefa difícil. Qualquer falha

recorrente, pode não ser verificada em tempo hábil, para que medidas cabíveis

possam ser tomadas com eficiência e eficácia (COBLI, 2017).

Desde 2010, no Brasil, os automóveis, por obrigação, devem sair de fábrica

com uma central eletrônica, na qual pode ser conectada o dispositivo OBDII (On Board

Diagnostics) para realizar o diagnóstico eletrônico, podendo ser mensurado, dentre

outras medidas, a velocidade, a pressão do óleo do motor, o torque, a tensão do

sistema elétrico, etc. A princípio o OBDII foi desenvolvido para contribuir com a

redução de poluentes no ambiente, mas com o passar do tempo questões como

segurança, economia e melhor aproveitamento do veículo também se tornaram

relevantes (CANALDAPECA, 2014).

Dentro deste contexto, o projeto tende a atuar para a otimização do processo

de gestão de frotas, contribuindo para a melhor utilização do veículo, a partir da

classificação dos motoristas.

No Quadro 1 a seguir estão representados variados fatores que contribuem

para o desgaste do veículo, bem como as consequências geradas em relação a cada

caso. Este quadro será a base para o tratamento dos dados que levará à formação da

classificação dos motoristas.

5

Quadro 1 – Fatores que contribuem para o desgaste do veículo.

OCORRÊNCIAS CONSEQUÊNCIAS

ENCHER O TANQUE QUANDO QUASE VAZIO

Quando o carro está parado, impurezas do combustível se precipitam para o filtro e para a bomba de combustível.

FRENAGEM COM FREQUÊNCIA

Promove desgaste excessivo do freio. Demonstra que o motorista não toma a devida distância de outros veículos, ou não está tomando a devida atenção.

FRENAGEM BRUSCA Promove desgaste excessivo do freio. Demonstra que o motorista não posiciona corretamente o pé para frear, ou está dirigindo de forma agressiva, ou não está tomando a devida atenção.

ACELERAR COM AUTOMÓVEL COM MOTOR GELADO

Temperatura do motor deve estar no mínimo em 50 graus C. Em dia de frio, deve-se deixar o automóvel ligado por pelo menos 1 min antes de começar a andar e não pode haver acelerações acentuadas até que a temperatura chegue na ideal.

ACELERAÇÃO BRUSCA Promove redução do rendimento do combustível e o desgaste precoce do motor quando a cima de 5250 rpm.

EXCEDER TORQUE MÁXIMO

Redução de rendimento do combustível.

DESVIO ACENTUADO (BRUSCO)

Acidente de trânsito. Indica agressividade no trânsito, ou falta de atenção.

PASSAR MARCHA ANTES DO TEMPO

Força a correia do motor, provocando seu desgaste precoce.

DESCANSAR A MÃO NO CÂMBIO

A pressão fornecida no câmbio danifica aos poucos o sistema de marcha do veículo.

TEMPERATURA ELEVADA ÓLEO

Pode provocar fundição do motor, além de demais avarias no sistema do automóvel.

FREAR EM DESCIDA Promove o desgaste excessivo do freio e põe em risco a segurança no trânsito. A recomendação é que se use o freio do motor.

Fonte: Adaptado de (howstuffworks, 2018; Oficina do G1, 2014; Diarionordeste, 2013; Bright Side, 2017

e Revistaautoesporte, 2015)

Sendo assim, com a implementação deste projeto, o motorista pode ser

orientado com mais precisão, a partir da detecção dessas situações.

6

1.2 ESCOPO

O sistema desenvolvido será composto dos seguintes módulos:

● Comunicação entre OBDII e Raspberry Pi: o Raspberry Pi fará as requisições,

via Bluetooth, ao OBDII para obtenção dos dados do automóvel ao qual estará

conectado.

● Comunicação entre Raspberry Pi e acelerômetro: o Raspberry Pi será

configurado para capturar, via acelerômetro conectado a ele, as variações de

aceleração do automóvel, as curvas durante a direção, bem como os declives

e as inclinações da via.

● Geração de arquivo: o Raspberry Pi guardará os dados coletados do automóvel

e do acelerômetro, em um arquivo .TXT, o qual deverá ser salvo em um

diretório no seu sistema operacional (Raspbian).

● Comunicação com a rede: o Raspberry Pi deverá se comunicar com uma rede

Wi-fi, ou rede móvel para transportar os arquivos, salvando-os na nuvem, a

qual estará sincronizada com servidor local (notebook).

● Banco de dados: será utilizado o SAS University Edition para tratamento dos

dados, de modo a traçar o perfil do motorista.

O projeto se limitará ao desenvolvimento e integração dos módulos citados acima,

dado que o foco se encontra no tratamento dos dados para geração da pontuação,

dessa forma não será desenvolvido.

● Comunicação com RFID: Configuração do Raspberry Pi para integração com

módulo RFID, de modo a autenticar usuário que conduzirá o veículo, por meio

da utilização de um token eletrônico.

● Frontend Web: Criação de página na Web contendo login e senha de usuário,

para verificação de informações de motoristas, geradas pelo sistema a ser

desenvolvido.

7

1.3 ESTRUTURA DO DOCUMENTO

Neste documento, o qual será a base para a defesa do projeto físico, serão

abordados o detalhamento do projeto, o cronograma revisado, os procedimentos de

teste e de validação do projeto, a análise dos riscos e a conclusão.

2 DETALHAMENTO DO PROJETO

O diagrama de blocos da visão geral do projeto, conforme a Figura 1,

demonstra o sistema que será desenvolvido.

Figura 1 - Diagrama de blocos do projeto - Fonte: Os autores, 2018.

O módulo OBDII será diretamente conectado à central eletrônica do automóvel,

pelo qual serão transmitidos os sinais elétricos emitidos pelo veículo. Esses sinais

serão transmitidos, via Bluetooth integrado no dispositivo, ao Raspberry Pi, que por

sua vez fará o controle das requisições ao OBDII e fará a conversão desses valores,

a partir de programação em Python.

Com a mesma frequência, o Raspberry Pi fará requisições ao acelerômetro

conectado a ele, afim de guardar informações da aceleração do automóvel, de forma

tridimensional.

Conforme realizará as coletas dos dados, o Raspberry Pi os guardará em um

arquivo .TXT, para que seja transmitido, via Wi-Fi ou rede móvel, assim que

estabelecer conexão.com a nuvem.

8

O arquivo transmitido será carregado pelo servidor em SAS, gerando assim

uma base de dados, a qual receberá tratamento neste ambiente para gerar a

pontuação do condutor.

As partes principais que compõem o projeto são:

• Automóvel: Peugeot 207 1.4 Flex, ano 2012-2013;

• Dispositivo de comunicação com automóvel: Elm327 (OBDII);

• Acelerômetro: Mpu-6050;

• Microcomputador: Raspberry Pi Model B;

• Database: SAS;

• Notebook com S.O. Windows;

• Dropbox for Developers.

2.1 CENTRAL ELETRÔNICA

A central eletrônica do automóvel utilizado, fisicamente falando, é padrão a

todos os carros, somente é alterado o protocolo de comunicação para acesso aos

dados. O Quadro 2 mostra qual protocolo pode ser utilizado no veículo.

Quadro 2 - Protocolo de comunicação do automóvel

Modelo Motor Ano Fuel Protocol

Peugeot 207 1.4 vti 2007 - 2009 Gas ISO 15765-4: CAN 11bit 500kb

Fonte: Adaptado de Outilsobdfacile,2018.

Apesar de estar indicado o tipo de protocolo a ser utilizado, pode ser inserido

código de leitura default: OBD(protocol= None):, o qual vai escolher automaticamente

o melhor protocolo de comunicação para o automóvel. (OBD Connections, 2018).

Os pinos a serem utilizados pelo protocolo serão os 6 e 14, conforme

demonstrado na Figura 2.

9

Figura 2 - Pinos central eletrônica - Fonte: Csselectronics, 2018.

2.2 OBDII

O dispositivo de leitura dos sinais do automóvel será o Elm327 (OBDII),

conforme a Figura 3, pois é um componente que um dos integrantes já tem posse.

Este dispositivo trabalha com comunicação via Bluetooth. Uma alternativa seria um

modelo com comunicação via USB.

Figura 3 - OBDII ELM327 - Fonte: DealExtreme, 2018.

O Elm327 realiza a comunicação conforme o protocolo corretamente

selecionado e conforme os comandos dados pelo Raspberry Pi, de tal forma que o

conversor A/D nele presente fará a conversão dos sinais elétricos do automóvel, para

valores em hexadecimal, os quais passarão pelo interpretador de comandos,

transformando-os para o valor solicitado devidamente formatado. O diagrama de

blocos do circuito do Elm327 está demonstrado pela Figura 4.

10

Figura 4 - Diagrama de blocos Elm327 - Fonte: ELM Eletronics, 2018.

2.3 ACELERÔMETRO

O acelerômetro a ser utilizado será o Mpu-6050, conforme a Figura 5, pois é

um componente barato e de fácil acesso, também não há grandes dificuldades para

sua utilização juntamente com o Raspberry Pi, tanto fisicamente quanto em sua

codificação. Uma alternativa a esse componente é o MMA8452.

Figura 5 - Mpu-6050 - Fonte: Fazer lab, 2018.

As conexões a serem feitas no Raspberry Pi seguem conforme Figura 6. Este

diagrama foi feito no endereço: https://www.digikey.com/schemeit/project/.

11

Figura 6 - Conexões do Mpu-6050 com o Raspberry Pi - Fonte: Os autores, 2018.

Tais conexões foram verificadas pela informação do diagrama dos pinos do

Raspberry Pi, conforme Figura 7.

Figura 7 - Diagrama de pinos Raspberry Pi 3 Model B - Fonte: Raspberry Pi – Schematics, 2018.

12

Com a conexão física devidamente feita, o pseudocódigo básico, para

funcionamento do acelerômetro, é feito da seguinte forma:

● Habilitar protocolo de comunicação I2C na Raspberry:

>raspi-config;

>Navegar pelo menu: Advanced Options > I2C > Enable.

● Instalação da Biblioteca WiringPI

> Confirmar instalação: i2cdetect -y 1.

> A resposta se dará pelo endereço 68.

● Amostragem dos dados do acelerômetro:

> from mpu6050 import mpu6050 - //importar biblioteca do mpu6050;

> sensor = mpu6050(0x68) - //definir variável;

> accelerometer_data = sensor.get_accel_data() //amostragem.

Tal código será desenvolvido na linguagem Python, no sistema operacional

Raspbian. (Raspberry PI com módulo MPU-6050, 2016 e GITHUB. MPU6050, 2017)

2.4 RASPBERRY PI

O Raspberry Pi 3 Model B, conforme a Figura 8, será utilizado pois pode ralizar

o controle dos módulos utilizados com estabilidade e pode conter memória de

armazenamento relativamente alta, neste caso, de 16gb, com cartão micro SD classe

10, porém outro dispositivo que também satisfaz às necessidades do projeto é o

Raspberry Pi Zero W, que custa a metade do preço do modelo utilizado no projeto.

Para este projeto não é aconselhável que se use Arduino, tanto o Uno quanto

o Mega, por conta da falta de memória para execução do código, geração de arquivo

e da instabilidade na integração dos módulos. (PCHDA - Plataforma para Coleta e

Habilitação da Análise de Dados Automotivos, 2015)

13

Figura 8 - Raspberry Pi 3 Model B

Fonte: Filipeflop - raspberry-pi-3-model-b, 2018.

O Respbarry Pi atuará de forma a se comunicar com o OBDII, via BLuetooth e

com o acelerômetro, fazendo as requisições dos sinais do automóvel numa frequência

de 10 HZ (uma requisição a cada 0,1 segundo), de tal forma que criará um arquivo

.TXT no qual serão salvos os dados requisitados. O fluxo da informação ocorrerá

conforme o fluxograma da Figura 9.

Figura 9 – Fluxograma - Fonte: Os autores.

14

Os comandos (PID) a serem chamados para obtenção dos dados do

automóvel, estão expressos conforme o Quadro 3.

Quadro 3 - Comandos OBDII

O QUE PODE SER MEDIDO PID

(Hexa) PID

(Binário) PID

SUPORT TIPO

STATUS DO COMBUSTÍVEL 3 3 PIDS_A SPECIAL

TEMPERATURA REFRIGERANTE 5 5 PIDS_A CELSIUS

PRESSÃO DO COMBUSTÍVEL 0A 10 PIDS_A KILOPASCAL

PRESSÃO DO COLETOR DE ADMISSÃO

0B 11 PIDS_A KILOPASCAL

RPM 0C 12 PIDS_A RPM

VELOCIDADE 0D 13 PIDS_A KPH

TAXA DE FLUXO DE AR 10 16 PIDS_A GRAMAS/S

DISTÂNCIA PERCORRIDA 21 33 PIDS_B KM

NÍVEL DE COMBUSTÍVEL 2F 47 PIDS_B PERCENT

DISTÂNCIA APÓS DTC LIMPADO 31 49 PIDS_B KM

PRESSÃO BAROMÉTRICA 33 51 PIDS_B KILOPASCAL

TEMPERATURA AMBIENTE DO AR 46 70 PIDS_C CELSIUS

TEMPO APÓS LIMPAR DTC 4E 78 PIDS_C MINUTO

TIPO DO COMBUSTÍVEL 51 81 PIDS_C STRING

% ÁLCOOL 52 82 PIDS_C PERCENT

PRESSÃO DO COMBUSTÍVEL 59 89 PIDS_C KILOPASCAL

POS RELAT PEDAL ACELERADOR 5A 90 PIDS_C PERCENT

TEMPERATURA ÓLEO MOTOR 5C 92 PIDS_C CELSIUS

TAXA DE CONSUMO MOTOR 5E 93 PIDS_C LITROS/HORA

TORQUE MOTOR 63 99 PIDS_C Nm

Fonte: Adaptado de Obdcon, 2018.

Deve ser feita instalação da biblioteca Python-OBD para obter comunicação

com o OBDII, da forma que segue:

$ pip install obd;

Sendo assim, pode-se obter a devida conexão entre os dispositivos realizando

a importação da biblioteca e em seguida chamando o comando de conexão:

import obd;

connection = obd.OBD();

Uma das formas pelas quais podem ser requisitados os valores dos sinais para

o OBDII é pelo próprio PID, conforme exemplo:

15

c = obd.commands[2][12];

O valor nos primeiros colchetes representa a forma com a qual o dado será

representado. Neste caso o PID 2 representa o dado congelado, ou seja, útil para

armazenamento. O valor seguinte representa o próprio comando a ser solicitado.

Neste caso 12 (ou 0C em hexa) é o valor de RPM. (Python-obd - Command Lookup,

2018).

Foi efetuado o cruzamento do Quadro 1, que indica os principais fatores que

contribuem para o desgaste do veículo, juntamente com o Quadro 3, referente aos

comandos do OBDII, de forma que foram combinados os parâmetros que podem ser

utilizados para detectar as situações mencionadas no Quadro 1, conforme segue no

Quadro 4.

Quadro 4 – Situações mensuráveis e seus respectivos parâmetros para obtenção

SITUAÇÕES MENSURÁVEIS PARÂMETRO (Vide Quadro 3)

ENCHER O TANQUE QUANDO QUASE VAZIO 2F, OD e 46

FRENAGEM COM FREQUÊNCIA OD e tempo ou acelerômetro

FRENAGEM BRUSCA OD e tempo ou acelerômetro

ACELERAR COM MOTOR GELADO 5 e 0C

ACELERAÇÃO BRUSCA OC, OD e tempo, ou acelerômetro

EXCEDER TORQUE MÁXIMO 63 ou OC

DESVIO ACENTUADO (BRUSCO) Acelerômetro (ou sensor de volante) e

tempo.

PASSAR MARCHA ANTES DO TEMPO 0C e tempo, ou acelerômetro

Fonte: Os autores, 2018.

Abaixo segue o Quadro 5, contendo as situações que não serão levadas em

consideração no projeto.

Quadro 5 - Situações não mensuradas

O QUE NÃO SERÁ MENSURADO

DESCANSAR A MÃO NO CÂMBIO Sem parâmetros para medida

TEMPERATURA ELEVADA ÓLEO O carro já tem meios de realizar alertas em relação à temperatura elevada.

FREAR EM DESCIDA Sem parâmetros para comprovação do uso do freio.

Fonte: Os autores, 2018.

16

Para serem calibrados corretamente os valores de torque e rotação ideais no

código de tratamento dos dados, buscando o melhor rendimento na condução do

automóvel, foi gerado o Quadro 6, conforme segue.

Quadro 6 - Dados técnicos do automóvel

CARRO UTILIZADO: PEUGEOT 207 1.4 FLEX

TIPO MOTOR: KFW/FF

GASOLINA OU ÁLCOOL

TORQUE (N.m) 126

RPM 3250

Fonte: Manual do meu carro, 2016.

2.5 NUVEM

Foi escolhido o Dropbox para repositório de arquivos, pois é uma ferramenta que

oferece suporte para desenvolvedores, de modo que pode ser configurado no S.O.

Raspbian. Dessa forma torna-se viável o salvamento de arquivos na nuvem, dado que

plataformas diferentes podem “enxergar” e trabalhar com o mesmo diretório.

Com os dados salvos e com a viagem do automóvel finalizada (carro desligado),

será feita a transferência dos arquivos gerados para o Dropbox, conforme o diagrama

da Figura 10.

Figura 10 - Fluxo de conexão com rede e transferência de arquivo - Fonte: Os autores, 2018.

17

2.6 BANCO DE DADOS

O ambiente a ser utilizado para tratamento dos dados incluídos nos arquivos

.TXTs, será o SAS pois os integrantes do projeto estão familiarizados com essa

ferramenta, pelo fato de admitir programação tanto em sua própria linguage, quanto

em SQL. Poderia ser utilizado também o MySQL.

Na ferramenta serão configurados scripts para importação dos arquivos vindo

da nuvem (Dropbox), para o processamento dos dados contidos nesses arquivos,

envolvendo a implementação de regras para geração de flags que indicam a conduta

do motorista e para a automação dessas ações, realizando a importação, execução e

gerando resultados de forma automática. O código dos scripts utilizados para

configuração do banco de dados, segue em anexo.

Com os arquivos presentes na nuvem, serão importados por meio de rotina do

SAS, de forma a ser gerada uma base de entrada a qual conterá os campos definidos

conforme segue no Quadro 7.

Quadro 7 - Variáveis da tabela

VARIÁVEL TAMANHO (BYTES)

TEMPERATURA_REFRIGERANTE 4

RPM 4

VELOCIDADE 4

ACELERACAO 4

DISTANCIA_PERCORRIDA 4

NIVEL_COMBUSTIVEL 4

TORQUE 4

TOTAL 32

Fonte: Os autores, 2018.

Sendo assim, percebe-se que cada linha terá, no máximo 32 bytes de tamanho,

considerando um caso em que todos os campos contêm valores de 4 bytes, cada,

sendo o tamanho máximo dos valores dos sinais interpretados pelo Raspberry Pi.

Portanto, realizadando 4 requisições/ segundo, em média (formando 4 linhas por

segundo), o tamanho do arquivo se dará conforme o Quadro 8 a segui

18

Quadro 8 - Tamanho do arquivo

Tempo Bytes MB

1 s 360 0,00036

1 min 21600 0,0216

1h 1.296.000 1,296

1 dia (24h) 31.104.000 31,104

Fonte: Os autores, 2018.

Verifica-se que um tamanho de menos de 50 MB de arquivo, pode ser

carregado em base de dados sem dificuldades, visto que a taxa de leitura e escrita do

cartão micro SD utilizado é de 10mb/s, mesmo considerando um caso em que todos

os dados têm tamanho de 4 bytes (para cada variável de uma linha) e que o carro

ficou rodando por 24h ininterruptas.

Após geração dos dados na tabela de entrada, serão aplicadas regras de

tratamento para geração das variáveis de flag, as quais serão utilizadas para formação

da pontuação do motorista, conforme expressas no Quadro 9.

Quadro 9 - Regras de tratamento

VARIAVEL GERADA PARÂMETRO TRATAMENTO PARA GERAÇÃO DE FLAGS

FLAG_TANQUE_BAIXO 2F, OD e 46

Verificar se carro estava em movimento com nível de combustível abaixo de 20% se temperatura ambiente > 20 graus, ou abaixo de 40% se temperatura ambiente < 8 graus. Se sim, gera flag.

FLAG_FRENAGEM_FREQUENTE OD e tempo

ou acelerômetro

Verificar se velocidade lida <= 3/5 da velocidade anterior em intervalo de tempo <= 1 segundo. Se sim e se situação ocorrer por pelo menos 5 vezes em 600 registros (um minuto), então gera flag.

FLAG_FRENAGEM_BRUSCA OD e tempo

ou acelerômetro

Verificar se velocidade lida <= 1/5 da velocidade anterior em intervalo de tempo <= 2 segundos. Se sim, gera flag.

FLAG_MOTOR_GELADO 5 e 0C Se temperatura do líquido de arrefecimento < 50 graus e velocidade do carro > 0, gera flag.

FLAG_ACELERAÇÃO_BRUSCA OC, OD e tempo, ou

acelerômetro

Verificar blocos de 20 em 20 registros (2 em 2 segundos). Se velocidade atual - velocidade anterior !=0 e RPM > 3250, então gera flag.

FLAG_TORQUE 63 ou OC

Se 3250 < RPM < 3500, então gera flag com peso baixo. Se 3500 < RPM < 4500, então gera flag com peso médio. Se RPM > 4500, então gera flag com peso alto.

FLAG_DESVIO_BRUSCO

Acelerômetro (ou sensor de

volante) e tempo.

Verificar a cada 15 registros (1,5 segundos) se ocorreu variação de ângulo do volante de + ou - 30 graus em relação ao estado anterior, ou se ocorreu variação brusca no eixo x do

19

acelerômetro (valor a ser definido em teste empírico). Se sim, gera flag.

FLAG_MARCHA_ANTES_TEMPO 0C e tempo,

ou acelerômetro

Verificar a cada 50 registros (5 segundos) se moda do RPM <=1500 (será verificado em teste empírico), se sim, gera flag.

Fonte: Os autores, 2018.

Por meio das flags será possível traçar o perfil do motorista, o qual estará

representado também por variáveis de tabela, cujos registros serão somados, de

modo que o montante será subtraído de um valor previamente estabelecido, o qual

consiste na melhor pontuação possível. Não somente o score, mas também os dados

representativos das flags poderão ser utilizados para traçar um perfil único do

condutor.

No Quadro 10 está exemplificada uma situação possível de conduta de

motorista, pela qual será feita a construção do seu perfil.

Quadro 10 – Situação exemplo.

Classificação problema Tempo _recorrido (segundos) 463 Peso

Motor gelado (baixa penalidade)

Manutenção F_COLD_LOW 1

2,0

Motor gelado (alta penalidade)

Manutenção F_COLD_HIGH 0

5,0

RPM baixo Manutenção F_LOW_RPM 22 3,0

Aceleração brusca Dirigibilidade F_AC_BRUSC 2 3,0

Frenagem brusca Dirigibilidade F_FR_BRUSC 3 2,0

Frenagem com frequência Dirigibilidade F_FR_FREQ 2 1,5

RPM alto (penalidade baixa)

Manutenção F_RPM_LOW 13

1,5

RPM alto (penalidade média)

Manutenção F_RPM_MED 15

3,0

RPM alto (penalidade alta) Manutenção F_RPM_HIGH 1 5,0

Fonte: Os autores.

A partir desses dados, é possível visualizar, conforme Gráfico 1, quais são os

maiores desvios de conduta do motorista, sendo evidenciado seu perfil. Neste caso,

a troca de marcha antes do momento certo é a ação que exerce por mais tempo

durante a direção do automóvel, pois a pontuação é a maior dentre as elencadas.

20

Gráfico 1 – Pontuação do motorista. Fonte: Os autores.

A soma das classificações dos problemas, vista no Quadro11, pode evidenciar

o quanto o motorista contribui para uma boa direção no trânsito e para a manutenção

do veículo. Neste caso, quanto maior a pontuação, menor a contribuição.

Quadro 11 – Somatório de pontuações.

SOMA PONTUAÇÃO

DIRIGIBILIDADE 15

MANUTENÇÃO 138 Fonte: Os autores.

No Gráfico 2 é possível visualizar o nível de contribuição do motorista. Neste

caso a orientação deve ser focada na manutenção do veículo.

10

22

23

2

13

15

1

0

2

4

6

8

10

12

14

16

18

20

22

24

Pontuação do motorista

21

Gráfico 2 – Pontuação da Contribuição do motorista. Fonte: Os autores.

3 CRONOGRAMA

Abaixo se encontra a Figura 11 – Cronograma do projeto, contemplando todas

as datas de desenvolvimento do projeto, incluindo as do segundo semestre, logo em

seguida, a Figura 12 – Gráfico de Gantt, demonstra graficamente as divisões das

tarefas em relação ao tempo decorrido.

0 20 40 60 80 100 120 140 160

Dirigibilidade

Manutenção

Contribuição do motorista

22

Figura 11 – Cronograma do projeto - Fonte: Os autores, 2018.

23

Figura 12 – Gráfico de Gantt - Fonte: Os autores, 2018.

24

4 PROCEDIMENTOS DE TESTE E VALIDAÇÃO DO PROJETO

Nesta seção listamos os módulos do projeto que serão testados e validados,

desde a aquisição de dados do automóvel pelo microcontrolador até o processamento

dos mesmos. Para ajudar a entender melhor os procedimentos, segue o Quadro 12 –

Estados dos LEDs.

Quadro 12 – Estados do LEDs

ESTADO AMARELO VERDE LARANJA

IGNIÇÃO ACIONADA Pisca intermitentemente

Apagado Apagado

AUTENTICAÇÃO SUCEDIDA Apagado Aceso Apagado

PAREAMENTO SUCEDIDO ENTRE OBDII E O RASPBERRY

Apagado Aceso Apagado

TRANSFERÊNCIA DOS DADOS DO AUTOMÓVEL PARA O RASPBERRY

Apagado Aceso Pisca intermitentemente

Fonte: Autores do projeto, 2018.

4.1 TESTES DE CAIXA PRETA

Esta seção aborda os testes do ponto de vista do usuário final, com os

módulos que o mesmo irá interagir.

4.1.1 CARREGAMENTO DO SISTEMA

Quando o condutor ligar a ignição do automóvel, um led amarelo ficará

piscando intermitentemente, indicando que o sistema está carregando. Caso o

sistema tenha carregado corretamente, LED verde acende, caso contrário, LED

amarelo continua piscando intermintente.

25

4.2 TESTES DE CAIXA BRANCA

Esta seção aborda os testes do ponto de vista do sistema, ou seja, testes de

mais baixo nível, realizados na camada mais abstrata do projeto.

4.2.1 CONEXÃO COM O OBDII

Após carregado o sistema, tentará fazer o pareamento com o OBDII conectado

ao carro, caso a conexão tenha sucesso e esteja estável, o LED verde é apenas

mantido aceso, caso contrário, o LED vermelho acenderá.

4.2.2 AQUISIÇÃO DOS DADOS DO AUTOMÓVEL

Nesse procedimento de teste, será analisado no dispositivo se um LED laranja

ficará piscando enquanto a transferência dos dados é feita do OBDII para o Raspberry

Pi. Também será analisado, após a finalização da corrida do condutor, se os dados

do automóvel foram armazenados no SD Card.

Quando o automóvel for desligado, o mesmo encerra a transmissão de dados

do OBDII para o Raspberry Pi, e os dados coletados do condutor são salvos no SD

Card, para que estes sejam transferidos para o servidor do Dropbox.

4.2.3 CONEXÃO COM O SERVIDOR

Nesse procedimento de teste, será testado se o servidor do Dropbox

configurado está disponível para realizar a conexão. Quando disponível, o módulo Wi-

Fi deverá realizar a conexão com o mesmo para fazer a transferência dos dados

disponíveis no SD Card.

26

5 RISCOS

Nesta seção disponibilizamos no Quadro 13, os possíveis riscos que podem

ocorrer durante o desenvolvimento do projeto.

Quadro 13 – Plano de riscos

Priorização Evento de Risco Ação/Contingência Responsável

2 Desistência de

integrante do grupo

Análise das tarefas definidas para o projeto, e definir o que será possível fazer no prazo

estipulado.

Todos os integrantes

1 Problemas com a análise profunda

dos dados

Realizar estudo para melhorar a classificação dos condutores

Todos os integrantes

1 Problemas com o

uso do Raspberry Pi Procurar ajudar do professor orientar e de

cursos disponíveis na internet. Todos os

integrantes

Fonte: Os autores, 2018.

6 RESULTADOS OBTIDOS

Nesta seção serão dispostos os resultados obtidos em relação aos testes

efetuados com o protótipo do projeto.

A tabela de dados gerada, com as principais variáveis, juntamente com a

descrição de cada uma, está disposta conforme o Quadro 14.

Quadro 14 – Variáveis

Variáveis Descrição

ANOMESDIA Data completa da utlização do veículo.

TIME_FULL Tempo em segundos.

RPM Rotação por minuto do motor do automóvel.

SPEED Velocidade do automóvel.

TEMP Temperatura do líquido de arrefecimento.

FLAG_ACEL_BRUSC Flag de aceleração brusca.

FLAG_COLD_HIGH Flag de líquido de arrefecimento gelado. Alta penalidade.

FLAG_COLD_LOW Flag de líquido de arrefecimento gelado. Penalidade baixa.

FLAG_FREN_BRUSC Flag de frenagem brusca.

PREV_FREN_FREQ Flag prévia de frenagem frequênte.

FLAG_FREN_FREQ Flag de frenagem frequênte.

FLAG_LOW_RPM Flag de rotação baixa.

FLAG_RPM_HIGH Flag de rotação alta. Penalidade baixa.

FLAG_RPM_LOW Flag de rotação alta. Penalidade média.

FLAG_RPM_MED Flag de rotação alta. Penalidade alta. Fonte: Os autores, 2018.

27

Esta é a tabela final gerada, pela qual são feitas as consultas que vão

evidenciar o perfil do motorista. Foi escolhido o Excel para serem realizadas as

consultas, de modo que os dados são atualizados automaticamente a partir da base

de dados localizada em diretório padrão, no Dropbox.

O código que gera a base final tem como saída um arquivo .CSV, o qual é

utilizado como carga para formar a tabela dinâmica no Excel.

O Gráfico 3 demonstra o resultado obtido em das rotações do motor do

automóvel em relação à velocidade com a qual se encontrava, em um tempo de 30

segundos.

Gráfico 3 – Velocidade x Rotações. Fonte: Os autores.

As linhas de cores alaranjada (inferior) e preta (superior), respectivamente,

representam a rotação do motor do automóvel e a velocidade. O trinângulo separado

dos demais, de cor azul escuro, representa a FLAG_LOW_RPM. Pode-se perceber

que neste momento, há aumento de velocidade de 22 para 25 km/h ao mesmo tempo

que as rotações reduzem de 978 para 878 RPM, em um período de 2 segundos,

caracterizando assim um momento em que a marcha do automóvel está a cima da

que deveria.

28

As três formas agrupadas, à direita da imagem, representam, respectivamente,

FLAG_RPM_LOW (amarelo), FLAG_RPM_MED (azul claro) e FLAG_RPM_HIGH

(verde). Tais indicadores representam o momento em que o motorista ultrapassou a

rotação máxima recomendada do automóvel, 3260 RPM (representada pela linha

constante de cor vermelha). Os valores reais das rotações foram divididos por 100,

para poder se adequar à escala do gráfico.

O Quadro 15 a seguir contém as faixas de valores de rotações em relação ao

peso que essas flags oferecem para compor a pontuação final do motorista.

Quadro 15 – Faixas de valores de rotações, acossiadas aos pesos.

PESO FAIXA

LOW 3267 < RPM <= 3496

MED 3496 < RPM <= 4492

HIGH RPM > 4492 Fonte: Os autores, 2018.

Verificando tais informações em relação ao Gráfico 3, pode-se evidenciar os

pontos de distribuição das flags e dos pesos.

Outras variações testadas foram a aceleração brusca (FLAG_ACEL_BRUSC) , a

qual promove a redução do rendimento do combustível juntamente com o desgaste

precoce do motor e a frenagem brusca (FLAG_FREN_BRUSC), que pode indicar

desgaste excessivo do freio, demonstrando que o motorista não posiciona

corretamente o pé para frear, ou está dirigindo de forma agressiva, ou não está

tomando a devida atenção no trânsito, segundo o Quadro 1 presente no início do

documento.

29

No Gráfico 4 se encontram essas flags, sendo encontradas em um período de

um minuto.

Gráfico 4 – Aceleração e frenagem bruscas. Fonte: Os autores

Da esqueda para a direita, a primeira, a terceira e a quarta barra, em cor

alaranjada, representam a FLAG_ACEL_BRUSC, ao mesmo passo que a segunda e

a quinta barra, de cor cinza, representam a FLAG_FREN_BRUSC. Tais barras

evidenciam as curvas acentuadas das acelerações e frenagens, nos momentos

indicados. Por exemplo, a primeira barra representa a variação de velocidade de 32

para 47 km/h em 2 segundos, ou seja, uma variação média de 7,5 km/h em 1 segundo.

A segunda barra demontra que, em 2 segundos, o motorista executou uma

frenagem que resultou em uma redução de velocidade de 57 para 33 km/h, ou seja,

redução média de 12 km/h em 1 segundo, configurando frenagem brusca.

A partir dos dados apresentados, dentre outros, como frenagem frequente e

temperatura do líquido de arrefecimento do mortor, pode-se gerar uma classificação

do motorista, de acordo com a necessidade da aplicação. Pode-se também ser

realizada uma comparação entre dois motoristas, por exemplo, sendo verificada suas

pontuações na mesma faixa de período de condução do automóvel.

30

O Gráfico 5 demonstra essa comparação entre o motorista 1 (M1), à esquerda,

em azul e o motorista 2 (M2), à direita, em laranja, durante um período de condução

de 6 minutos de cada um.

Gráfico 5 – Comparação entre M1 e M2. Fonte: Os autores.

O Gráfico 5 demonstra essa comparação entre o motorista 1 (M1), à esquerda,

em azul e o motorista 2 (M2), à direita, em laranja, durante um período de condução

de 6 minutos de cada um.

A pontuação presente é referente à quantidade de vezes que ocorreu cada flag,

por motorista. Desta forma, quanto maior a pontuação total, pior é o motorista. Neste

caso, o motorista 1 (M1) precisa de uma orientação mais acentuada em relação a

necessidade de dirigir presando pelo rendimento do combustível e à preservação da

integridade do motor, enquanto o motorista 2 (M2), além de precisar cuidar da

integridade do automóvel, também precisa dirigir com mais cautela e atenção, pois

costuma executar ações de frenagem bruscas.

31

7 CONCLUSÃO

Este documento tratou da explicação do problema da gestão da frota de

veículos, a qual está intimamente ligada com a preservação dos automóveis e com a

imagem das empresas.

Este projeto tem como objetivo a implementação de uma pontuação de

motorista, a partir do tratamento de dados em SAS/SQL, obtidos de um sistema

responsável por monitorar os diferentes sinais dos veículos (via OBDII), identificando

os que possam classificar os motoristas quanto a qualidade de sua direção. O

controlador receberá os sinais, via Bluetooth, do OBDII e guardará os resultados em

arquivos .TXT, até que possa se conectar com uma rede wifi ou móvel e transmiti-los

para compor a base de dados na ferramenta SAS, o qual fará seu tratamento gerando

a informação necessária para obtenção da pontuação, de modo que a empresa

gestora da frota poderá traçar um perfil único do motorista e trabalhar seus defeitos

de forma mais eficiente e eficaz.

O sistema a ser trabalhado conta com os módulos: Central eletrônica do

automóvel, OBDII (Elm327), Raspberry Pi Model B, Bluetooth integrado, acelerômetro

(Mpu-6050) e repositório de arquivos na nuvem, pelo Dropbox, os quais devem operar

com estabilidade, visto que o Raspberry Pi tem ótimas qualidades para

desenvolvimento.

Todos os módulos foram trabalhados e testados individualmente, com

situações mais genéricas e depois adaptados às necessidades do projeto, de modo

que a integração fosse menos turbulenta o possível. Foi dada atenção especial para

o desenvolvimento dos testes com o servidor e principalmente com a mineração dos

dados, de modo que não houve tempo hábil para implementação do acelerômetro no

sistema, o qual permitiria que fosse filtrado melhor a flag de aceleração brusca,

verificado um desvio brusco (direção perigosa) e verificado a execução de frenagem

em descida.

32

REFERÊNCIAS

CANAL DA PECA. Tudo o que você precisa saber sobre o OBD-II. Disponível em: <https://www.canaldapeca.com.br/blog/o-que-e-obd-ii/>. Acesso em: 15 jun. 2018.

CIRCUIT CRUSH. How OBD-II vehicle diagnostics work, part 2: a closer look. Disponível em: <https://circuitcrush.com/how-obd-ii-works-part-2/>. Acesso em: 15 jun. 2018.

COBLI. Principais problemas na gestão de frotas e como enfrentá-los. Disponível em: <https://cobli.co/blog/problemas-na-gestao-de-frotas/>. Acesso em: 17 jun. 2018.

CSSELECTRONICS. OBDII Explained: a simple intro (2018). Disponível em: <https://www.csselectronics.com/screen/page/simple-intro-OBDII-explained/language/en>. Acesso em: 29 abr. 2018.

DEAL EXTREME. Mini ELM327 Bluetooth OBDII. Disponível em: <http://www.dx.com/pt/p/super-mini-elm327-bluetooth-odb2-v1-5-car-diagnostic-interface-tool-blue-142679?tc=brl&ta=br&gclid=cjwkcajww6xxbrbyeiwam-zuidpsbgwhcrddedqigoocl1dn_v8xs5x8r5uaekz6lzrkkmoolz6nmhocotqqavd_bwe#.wuqkmogvyuk>. Acesso em: 29 abr. 2018.

DIARIO DO NORDESTE. Vícios que danificam o câmbio. Disponível em: < http://diariodonordeste.verdesmares.com.br/suplementos/auto/vicios-que-danificam-o-cambio-1.470908>. Acesso em: 15 jun. 2018.

ELM Eletronics. ELM327 v2.2. Disponível em: <https://www.elmelectronics.com/ic/elm327/>. Acesso em: 15 jun. 2018.

FAZER LAB. Raspberry PI com módulo MPU-6050. Disponível em: <https://fazerlab.wordpress.com/2016/09/19/raspberry-pi-com-modulo-mpu-6050/>. Acesso em: 15 jun. 2018.

FILIPE FLOP. Acelerômetro e Giroscópio 3 Eixos 6 DOF MPU-6050. Disponível em: <https://www.filipeflop.com/produto/acelerometro-e-giroscopio-3-eixos-6-dof-mpu-6050/>. Acesso em: 15 jun. 2018.

FILIPE FLOP. Controle de acesso usando leitor RFID com arduino. Disponível em: <https://www.filipeflop.com/blog/controle-acesso-leitor-rfid-arduino/>. Acesso em: 03 mai. 2018.

FILIPE FLOP. Raspberry Pi 3 Model B. Disponível em: <https://www.filipeflop.com/produto/raspberry-pi-3-model-b/>. Acesso em: 29 abr. 2018.

GITHUB. MPU6050. Disponível em: <https://github.com/Tijndagamer/mpu6050>. Acesso em: 15 jun. 2018.

HOWSTUFFWORKS. How Engine Brakes Work. Disponível em: < https://auto.howstuffworks.com/auto-parts/brakes/brake-types/engine-brakes.htm>. Acesso em: 20 jun. 2018.

33

INSTRUCTABLES. OBD-PI. Disponível em: <http://www.instructables.com/id/OBD-Pi/>. Acesso em: 29 abr. 2018.

INFOWESTER. Tecnologia Bluetooth: o que é e como funciona?. Disponível em: <https://www.infowester.com/Bluetooth.php>. Acesso em: 29 abr. 2018.

MANUAL DO MEU CARRO. Manual do proprietário Peugeot 207 hatch, sedan e SW. Disponível em: <http://manualdomeucarro.blogspot.com/2016/12/manual-do-proprietario-peugeot-207.html>. Acesso em: 15 jun. 2018.

OBDCON. OBD-II PIDs. Disponível em: <http://obdcon.sourceforge.net/2010/06/obd-ii-pids/>. Acesso em: 15 jun. 2018.

G1. Oficina do G1 Disponível em: <http://g1.globo.com/carros/blog/oficina-do-g1/post/andar-com-o-carro-frio-e-uma-gelada.html> Acesso em: 20 jun. 2018.

OUTLIST OBD FACILE. Peugeot compatible OBDII and elm 327. Disponível em: <https://www.outilsobdfacile.com/vehicle-list-compatible-OBDII/peugeot>. Acesso em: 15 jun. 2018.

PPGIA. PCHDA - Plataforma para Coleta e Habilitação da Análise de Dados Automotivos. Disponível em: www.ppgia.pucpr.br/~laplima/ensino/pf/concluidos/2015/PCHDA.pdf>. Acesso em: 15 jun. 2018.

PYTHON-OBD. Command Lookup. Disponível em: <https://python-obd.readthedocs.io/en/latest/Command%20Lookup/>. Acesso em: 15 jun. 2018.

PYTHON-OBD. OBD connections. Disponível em: <https://python-obd.readthedocs.io/en/latest/Connections/>. Acesso em: 15 jun. 2018.

RASPBERRY PI. Schematics. Disponível em: <https://www.raspberrypi.org/documentation/hardware/raspberrypi/schematics/>. Acesso em: 15 jun. 2018.

REVISTA AUTO ESPORTE. Dicas para economizar combustível. Disponível em: <https://revistaautoesporte.globo.com/Servico/noticia/2013/02/dicas-para-economizar-combustivel.html>. Acesso em: 15 jun. 2018.

TOM GERSIC. Connecting your raspberry PI to a bluetooth OBD-II adapter. Disponível em: <http://gersic.com/connecting-your-raspberry-pi-to-a-Bluetooth-obd-ii-adapter/>. Acesso em: 29 abr. 2018.

BRIGHT SIDE. 8 Driving Habits That Ruin Your Car and Drain Your Wallet. Disponível em: < https://www.youtube.com/watch?v=Ivkiks3wypY>. Acesso em: 15 jun. 2018.

34

ANEXOS

ANEXO 1

O código abaixo implementado na linguagem de programação Python, é

executado internamente pelo Raspberry Pi para realizar a conexão com o OBDll, fazer

a coleta dos dados do automóvel e enviá-los para o servidor do Dropbox.

IMPORT RPI.GPIO AS GPIO IMPORT DROPBOX IMPORT OS IMPORT TIME IMPORT DATETIME IMPORT RE IMPORT OBD IMPORT LOG IMPORT ASYNCIO FROM MULTIPROCESSING IMPORT PROCESS, VALUE

# GLOBAL DATA_COLLECTED = VALUE('I', 0) READY_TO_SEND = VALUE('I', 0) ENGINE_RPM = VALUE('D', 0.0) CAR_CONNECTION_STATUS = VALUE('I', 0) OBD_CONNECTION = ''

# CONSTANTS YELLOW_LED = 22 GREEN_LED = 27 ORANGE_LED = 17 RED_LED = 4

LOGGER = LOG.FUNCTION_LOGGER()

# GPIO CONFIG GPIO.SETMODE(GPIO.BCM) GPIO.SETWARNINGS(FALSE) # LEDS CONFIG GPIO.SETUP(YELLOW_LED, GPIO.OUT) GPIO.SETUP(GREEN_LED, GPIO.OUT) GPIO.SETUP(ORANGE_LED, GPIO.OUT) GPIO.SETUP(RED_LED, GPIO.OUT) # TURN OFF THE LEDS GPIO.OUTPUT(YELLOW_LED, GPIO.LOW) GPIO.OUTPUT(GREEN_LED, GPIO.LOW) GPIO.OUTPUT(ORANGE_LED, GPIO.LOW) GPIO.OUTPUT(RED_LED, GPIO.LOW)

DEF SEND_FILES_TO_DROPBOX(): # DROPBOX CONNECTION LOGGER.INFO('SENDING FILES TO DROPBOX') DBX = DROPBOX.DROPBOX('DROPBOX_KEY', TIMEOUT=NONE) TRY: RPM_FILE = OPEN("/HOME/PI/PYTHONPROJECTS/PYOBD/RPM.TXT", "RB") SPEED_FILE = OPEN("/HOME/PI/PYTHONPROJECTS/PYOBD/SPEED.TXT", "RB") COOLANT_TEMP_FILE = OPEN("/HOME/PI/PYTHONPROJECTS/PYOBD/COOLANT_TEMP.TXT", "RB")

35

NOW = DATETIME.DATETIME.NOW() DBX.FILES_UPLOAD(RPM_FILE.READ(), '/SAS_FOLDER/ARQUIVOS/RPM-%S.TXT' % (NOW.STRFTIME('%Y-%M-%D-%H-

%M-%S'))) DBX.FILES_UPLOAD(SPEED_FILE.READ(), '/SAS_FOLDER/ARQUIVOS/SPEED-%S.TXT' % (NOW.STRFTIME('%Y-%M-%D-%H-%M-%S'))) DBX.FILES_UPLOAD(COOLANT_TEMP_FILE.READ(), '/SAS_FOLDER/ARQUIVOS/COOLANT_TEMP-%S.TXT' %

(NOW.STRFTIME('%Y-%M-%D-%H-%M-%S')))

RPM_FILE.CLOSE() SPEED_FILE.CLOSE() COOLANT_TEMP_FILE.CLOSE()

# REMOVE UPLOADED FILES OS.REMOVE("/HOME/PI/PYTHONPROJECTS/PYOBD/RPM.TXT") OS.REMOVE("/HOME/PI/PYTHONPROJECTS/PYOBD/SPEED.TXT") OS.REMOVE("/HOME/PI/PYTHONPROJECTS/PYOBD/COOLANT_TEMP.TXT") EXCEPT EXCEPTION AS ERR: LOGGER.INFO('DROPBOX ERROR: %S' %(ERR))

DEF BLINK_YELLOW_LED(CAR_CONNECTION_STATUS): WHILE 1: IF CAR_CONNECTION_STATUS.VALUE == 0: GPIO.OUTPUT(YELLOW_LED, GPIO.HIGH) TIME.SLEEP(0.2) GPIO.OUTPUT(YELLOW_LED, GPIO.LOW) TIME.SLEEP(0.2)

DEF BLINK_ORANGE_LED(DATA_COLLECTED): WHILE 1: IF DATA_COLLECTED.VALUE == 1 AND READY_TO_SEND.VALUE == 0: GPIO.OUTPUT(ORANGE_LED, GPIO.HIGH) TIME.SLEEP(0.2) GPIO.OUTPUT(ORANGE_LED, GPIO.LOW) TIME.SLEEP(0.2)

ASYNC DEF COLLECT_RPM_DATA(CONN): RPM_FILE = OPEN("/HOME/PI/PYTHONPROJECTS/PYOBD/RPM.TXT", "A+") NOW = DATETIME.DATETIME.NOW() AWAIT ASYNCIO.SLEEP(0.1) RESPONSE = CONN.QUERY(OBD.COMMANDS.RPM, FORCE=TRUE) LOGGER.INFO(RESPONSE) TRY: IF NOT RESPONSE.IS_NULL(): ENGINE_RPM.VALUE = FLOAT(RE.SUB('[^\D.]+', '', STR(RESPONSE))) IF ENGINE_RPM.VALUE > 0: DATA_COLLECTED.VALUE = 1 RPM_FILE.WRITE('%F;%S \N' % (ENGINE_RPM.VALUE, NOW)) RPM_FILE.CLOSE() ELSE: RPM_FILE.CLOSE() GPIO.OUTPUT(GREEN_LED, GPIO.LOW) CAR_CONNECTION_STATUS.VALUE = 0 READY_TO_SEND.VALUE = 1 EXCEPT ATTRIBUTEERROR AS ERR: LOGGER.INFO("IT WAS NOT POSSIBLE CONVERT THE RPM DATA: %S" %(ERR))

36

ASYNC DEF COLLECT_SPEED_DATA(CONN): IF ENGINE_RPM.VALUE > 0: SPEED_FILE = OPEN("/HOME/PI/PYTHONPROJECTS/PYOBD/SPEED.TXT", "A+") NOW = DATETIME.DATETIME.NOW() AWAIT ASYNCIO.SLEEP(0.1) RESPONSE = CONN.QUERY(OBD.COMMANDS.SPEED, FORCE=TRUE) LOGGER.INFO(RESPONSE) TRY: IF NOT RESPONSE.IS_NULL(): MY_VALUE = RE.SUB('[^\D.]+', '', STR(RESPONSE)) SPEED_FILE.WRITE('%S;%S \N' %(MY_VALUE, NOW)) SPEED_FILE.CLOSE() ELSE: SPEED_FILE.CLOSE() GPIO.OUTPUT(GREEN_LED, GPIO.LOW) READY_TO_SEND.VALUE = 1 CAR_CONNECTION_STATUS.VALUE = 0 EXCEPT ATTRIBUTEERROR AS ERR: LOGGER.INFO("IT WAS NOT POSSIBLE CONVERT THE SPEED DATA: %S" %(ERR))

ASYNC DEF COLLECT_COOLANT_TEMP_DATA(CONN): IF ENGINE_RPM.VALUE > 0: COOLANT_TEMP_FILE = OPEN("/HOME/PI/PYTHONPROJECTS/PYOBD/COOLANT_TEMP.TXT", "A+") NOW = DATETIME.DATETIME.NOW() AWAIT ASYNCIO.SLEEP(0.1) RESPONSE = CONN.QUERY(OBD.COMMANDS.COOLANT_TEMP, FORCE=TRUE) LOGGER.INFO(RESPONSE) TRY: IF NOT RESPONSE.IS_NULL(): MY_VALUE = RE.SUB('[^\D.]+', '', STR(RESPONSE)) COOLANT_TEMP_FILE.WRITE('%S;%S \N' %(MY_VALUE, NOW)) COOLANT_TEMP_FILE.CLOSE() ELSE: COOLANT_TEMP_FILE.CLOSE() GPIO.OUTPUT(GREEN_LED, GPIO.LOW) READY_TO_SEND.VALUE = 1 CAR_CONNECTION_STATUS.VALUE = 0 EXCEPT ATTRIBUTEERROR AS ERR: LOGGER.INFO("IT WAS NOT POSSIBLE CONVERT THE COOLANT TEMP DATA: %S" %(ERR))

ASYNC DEF COLLECT_DATA(CONN): AWAIT ASYNCIO.WAIT([ COLLECT_RPM_DATA(CONN), COLLECT_SPEED_DATA(CONN), COLLECT_COOLANT_TEMP_DATA(CONN), ])

DEF MAIN(CAR_CONNECTION_STATUS, READY_TO_SEND): GLOBAL OBD_CONNECTION LOGGER.INFO("CONNECTING TO OBD") WHILE 1: IF DATA_COLLECTED.VALUE == 1 AND READY_TO_SEND.VALUE == 1: DATA_COLLECTED.VALUE = 0 READY_TO_SEND.VALUE = 0 LOGGER.INFO('INIT PROCESS TO SEND DATA TO DROPBOX') P_DROPBOX = PROCESS(TARGET=SEND_FILES_TO_DROPBOX) P_DROPBOX.START()

37

IF CAR_CONNECTION_STATUS.VALUE == 0: TRY: OBD_CONNECTION = OBD.OBD() RESPONSE = OBD_CONNECTION.QUERY(OBD.COMMANDS.RPM, FORCE=TRUE) IF RESPONSE.IS_NULL(): LOGGER.INFO("RECONNECTING TO OBD") OBD_CONNECTION.CLOSE() OBD_CONNECTION = OBD.OBD() TIME.SLEEP(2) ELSE: # THE GREEN LED LIGHTS UP, RASPBERRY AND OBD2 ARE CONNECTED CAR_CONNECTION_STATUS.VALUE = 1 GPIO.OUTPUT(GREEN_LED, GPIO.HIGH) LOGGER.INFO("CONNECTED SUCCESSFULLY") EXCEPT EXCEPTION: LOGGER.INFO('IT WAS NOT POSSIBLE CONNECT TO OBD') ELSE: LOOP = ASYNCIO.GET_EVENT_LOOP() LOOP.RUN_UNTIL_COMPLETE(COLLECT_DATA(OBD_CONNECTION))

JOBS = [] P_MAIN = PROCESS(TARGET=MAIN, ARGS=(CAR_CONNECTION_STATUS, READY_TO_SEND,)) P_BLINK_YELLOW_LED = PROCESS(TARGET=BLINK_YELLOW_LED, ARGS=(CAR_CONNECTION_STATUS,)) P_BLINK_ORANGE_LED = PROCESS(TARGET=BLINK_ORANGE_LED, ARGS=(DATA_COLLECTED,))

JOBS.APPEND(P_MAIN) JOBS.APPEND(P_BLINK_YELLOW_LED) JOBS.APPEND(P_BLINK_ORANGE_LED)

FOR J IN JOBS: J.START() FOR J IN JOBS: J.JOIN()

38

ANEXO 2

O código abaixo foi construído para realizar a leitura do diretório que sincroniza

com o Dropbox, no Windows, o qual deve conter os arquivos .txts que servem de carga

para o processo. Encontrando arquivos, realiza uma comparação com diretório local,

de modo são importados quando não existem neste diretório, ou quando existem,

porém, a data de modificação da origem é superior à data de modificação do destino.

39

40

41

42

43

44

O código abaixo foi construído para realizar o tratamento dos arquivos

carregados, sendo aplicadas as regras de negócio para gerar as flags que constituirão

no comportamento do motorista enquanto dirige, podendo assim ser traçado um perfil.

45

46

.

47

48

49

50

51

52

53

54