Nessa palestra irei apresentar como você poderá acessar o computador de bordo do seu carro e coletar informações em tempo real, realizar detecção de falhas, e como enviar esses dados para nuvem para realizar análises. Você irá se surpreender em quais carros é possível fazer isso !! Vídeo e complemento: https://youtu.be/PYu6LimVcJI https://ricardojlrufino.wordpress.com/2017/07/29/que-tal-hackear-seu-carro-e-pluga-lo-na-nuvem-tdc2017-sp/ Irei apresentar também a plataforma de IoT OpenDevice.

1. Que tal hackear seu carro e plugá-lo na nuvem ?!
Ricardo JL Rufino

2. Agenda

Introdução;

Um pouco sobre a parte elétrica (sensores) do carro;

Protocolos;

Demonstração das aplicações desenvolvida;

Engenharia reversa de um sensor de estacionamento.

3. Sobre min
Ricardo JL Rufino

Esp. em Engenharia de Software

Mestrado em Gestão de TI (UFPE)

Sócio fundador da CriativaSoft (Teresina / PI)

Sócio fundador da Edu3 ( São Bernardo / SP ) * Nova
etapa !

Atuo no desenvolvimento de Software desde 2007,
focado em soluções empresariais sobre plataforma
JavaEE. Desenvolvedor de softwares open-source
como Framework Web MVC Mentawai, Arduino IDE

4. Sobre min

5. Introdução

Motivação
− Com a crescente evolução tecnológica dos carros,
principalmente no ramo de entretenimento e
conforto, abre-se novas oportunidades;
− Existe também uma aposta forte na área de Apps
para carros;
− E a análise dos dados gerados, o “Big Data”, pode
possibilitar a criação de vários serviços.

6. Introdução

Motivação / Pessoal
− Desafio (gabiarras) !
− Mais uma coisa para conectar na IoT !
− Ficar aberto a oportunidades !

7. Sensores do Carro (alguns)
Em carros comuns (à injeção eletrônica)
possuem vários sensores que são utilizados
para controlar as válvulas injetoras de
combustível.

8. Sensores / RPM

Função: Rotação do motor e rodas (ABS)

Tipos: Indutivo ( 2/3 pinos) e Hall (3 pinos)
Fonte: https://www.flightsystems.com

9. Sensores / Pedal

Função: Detectara posição do pedal de acel.

Tipos: Resistência e PWM
Fonte: http://www.ds.ind.br

10. Sensores / Detonação

Função: Detectar a presença das detonações e
ajustes do tempo de injeção.

Tipos: Piezo-elétrico / Resistivo
Fonte: http://www.cursosonlinemte.com.br

11. Sensores / Borboleta / TPS

Função: Determinar a posição da borboleta (que
controla o fluxo de ar para o motor) e é
influenciada pelo pedal de aceleração.

Tipo: Resistivo
Fonte:http://www.autodaewoospark.com

12. Sensores / Combustível

Função: Detectar o nível de gasolina no tanque.
– Existem outros sensores para calcular o
consumo de combustível.

Tipo: Resistivo
Fonte:http://www.autodaewoospark.com

13. Sensores de Oxigênio (Sonda Lâmbda)
Função: Determinar se a mistura está pobre ou
rica, para ajustar a quantidade de ar/combustível.
Carac. Elétricas: 1...1000mV
Fonte:https://www.soinjecaoeletronica.com.b

14. Prontos ?!

15. Calma !!!!
É mais simples e existem padrões para
coletar dados de vários sensores;
O protocolo: OBD ( On-Board Diagnostic );
Veículos produzidos desde 1996 (USA,
Europa), e no Brasil a partir de 2010
(ODBII), porém a introdução da tecnologia
foi em 1980;
Em 2008 (USA), entra a regulamentação da
rede CAN ( ISO 15765-4 ), referente ao
padrão de transmissão de dados.

16. Protocolos

SAE J1850 PWM (41.6 kbit/s)

SAE J1850 VPW (10.4 kbit/s)

ISO 9141-2 (5 baud init, 10.4 kbit/s)

ISO 14230-4 KWP (5 baud init, 10.4kbit/s)

ISO 14230-4 KWP (fast init, 10.4 kbit/s)

ISO 15765-4 CAN (11 bit ID, 500 kbit/s)

ISO 15765-4 CAN (29 bit ID, 500 kbit/s)

ISO 15765-4 CAN (11 bit ID, 250 kbit/s)
Female OBD-II connector pinout – front
view
Consulte demais pinos: https://en.wikipedia.org/wiki/On-board_diagnostics

17. Protocolos / ELM327
ELM327 – Abstrai o padrão OBD/II para
vários protocolos de comunicação.

É configurado através de comandos AT.

Baseado no microcontrolador PIC.

Existem muitos clones na versão v1, e
reportam ser uma versão mais nova.

18. Protocolos / ELM327
https://www.elmelectronics.com/wp-content/uploads/2017/01/ELM327DS.pdf

19. Protocolos / ELM327

20. Protocolos / ELM327
Conexão (Bluetooth)

Localizar o MAC do dispositivo
# hcitool scan

Pareamento
# bluetooth-wizard

Conectar e criar uma porta serial
# rfcomm connect 1 00:1D:A5:68:98:XX
Connected /dev/rfcomm0 to 00:07:80:93:54:1C on
channel 1
Press CTRL-C for hangup
http://www.janosgyerik.com/how-to-communicate-with-bluetooth-devices-in-
linux/

21. Protocolos / ELM327

22. Protocolos / ELM327
Configuração / Comandos AT:

ATZ – Reset

ATE0 – Desabilitar o ECHO

ATS0 – Desabilitar impressão de espaços.

ATAT1 – Ajusta tempos de resposta.

ATSP0 – Selecionar protocolo automático.
Lista de Comandos:https://www.sparkfun.com/datasheets/Widgets/ELM327_AT_Commands.pd
f

23. Protocolos / OBD2
A consulta de parâmetros do veículo, como:
RPM, velocidade e etc, é feita através dos
PIDs.
Os PIDs são padronizados em modos:

Mode 01 – Exibir dados atuais;

Mode 02 – Exibe dados capturados;

Mode 03 – Exibe códigos de erros (se
houver);

Mode 04 – Limpar os códigos de erro;https://en.wikipedia.org/wiki/OBD-II_PIDs

24. Protocolos / OBD2
PID – Modo 01 (resumido)

0100 – Lista os PIDs suportados (01-20);

0101 – Status dos erros que foram limpos;

0102 – Congela os dados para o modo 02;

0103 – Status do sistema de combustível;

0104 – Carga do Motor;

0105 – Temp. liquido de arrefecimento ?!;

010C – RPM (Rotação do Motor);

25. Protocolos / OBD2
PID – Modo 03 – Requisitar Códigos de Erros
Exemplo de erro: P2119
Pesquisar Erros: https://www.obd-codes.com/

26. OBD2 / Simulador
ObdsimObdsim - Permite simular alguns sensores, podendo criar
uma porta serial ou um emulador bluetooth.
Instalação: # apt-get install obdgpslogger
Site: http://icculus.org/obdgpslogger/obdsim.html

27. OBD2 / Simulador
Comandos

Abrir a interface (porta serial)
# obdsim -p 8 -g gui_fltk

Criar adaptador virtual bluetooth
# sudo rfcomm bind 0 48:5A:B6:F4:D9:XX 1
# sudo sdptool add SP
# obdsim -p 8 -b
DO SEU PC
Em seguida é possível parear usando seu celular

28. OBD2 / APPs
Torque Lite DashCommand

29. OBD2 / API Java

Foi desenvolvida uma extensão para o
OpenDevice[1] que permite se comunicar via USB
/ Bluetooth / Wi-Fi*;

OpenDevice: Ferramenta para construção de
projetos de IoT;

Perite desenvolver aplicações Arduino, Web /
Desktop / Android, para visualização e análise
dos dados.
[1] http://opendevice.io
[*] Não testado

30. OBD2 / API Java
Instalação / Android
Adicionar as dependências no app/build.gradle
Compilar os fontes - Opcional (e recomentado)
Fontes: https://github.com/OpenDevice/opendevice-extensions
Pré-requisitos: Maven + Java
Basicamente: mvn install (na pasta obd-connection)
Guia: https://opendevice.atlassian.net/wiki/display/DOC/Building+from+source
dependencies {
compile 'br.com.criativasoft.opendevice:opendevice-android-stream:0.1.4-SNAPSHOT'
compile 'io.opendevice.ext:obd-connection:0.1.4-SNAPSHOT'
compile 'com.noveogroup.android:android-logger:1.3.5'
}

31. OBD2 / API Java
Java / Maven: <dependency>
<groupId>br.com.criativasoft.opendevice</groupId>
<artifactId>opendevice-wasync-client</artifactId>
<version>${opendevice-version}</version>
</dependency>
<dependency>
<groupId>br.com.criativasoft.opendevice</groupId>
<artifactId>opendevice-connection-stream</artifactId>
<version>${opendevice-version}</version>
</dependency>
<dependency>
<groupId>io.opendevice.ext</groupId>
<artifactId>obd-connection</artifactId>
<version>${opendevice-version}</version>
<type>jar</type>
</dependency>
// Conexão remota com servidor / websocket
// USB / Serial / TCP / Bluetooh
// Extensão OBD2

32. OBD2 / API Java

Exemplo:
Configurações para usar um servidor
remoto
Habilitar sensores individuais...
Conectar todos, e definir o servidor

33. OBD2 / API Java
O servidor remoto aqui é “opcional”!

Exemplo de como trabalhar com os dados localmente:

34. OpenDevice

Instalação do servidor OpenDevice:
− https://opendevice.atlassian.net/wiki/display/DOC/

Pré-requisitos: Java

Login: admin / admin

Serviços:
− Banco Embarcado, HTTP(8181), Rest(8181),
WebSocket(8181) e MQTT(1883).

35. OpenDevice

36. OpenDevice

37. OpenDevice

38. Demo / IoTCar
Código: https://github.com/OpenDevice/opendevice-examples/tree/master/IoTCar

39. Demo / IoTCar
https://youtu.be/PYu6LimVcJI

40. E as GAMBIARRAS ?

41. Engenharia Reversa – Sensor de Estacionamento

42. Engenharia Reversa

43. Engenharia Reversa – Sensor de Estacionamento
Componentes Identificados:

NE5532 - Dual Low-Noise High-Speed Audio Operational
Amplifier

74HC4052 - Dual 4-channel analog
multiplexer/demultiplexer

EM78P156E - 8-bit microprocessor
http://www.xinpian.net/EMC/EM78P/EM78P156.pdf

44. Engenharia Reversa

O foco dá análise será na saída no
microcontrolador que vai para o display.

A análise foi feita utilizando as
ferramentas:

Analisado lógico: USBee AX PRO (~R$ 50)

Sigrok[1] – Suíte de ferramentas de
analisadores lógicos e osciloscópios, com
suporte a vários hardwares.

PulseView – Ferramenta visual que
acompanha o Sigrok

[1] https://sigrok.org/
[2] https://lxtreme.nl/projects/ols/

45. Engenharia Reversa

USBee AX PRO

46. Engenharia Reversa

Sigrok / PulseView

47. Engenharia Reversa
Erros cometidos:

Utilizar um Arduino para ler os dados como
se fosse Serial/UART.

Os dados “pareciam” alguma coisa, muito
tempo perdido !!

Queima de um módulo, após dar partida.

48. Identificação do Padrão de Comunicação

Procedimento: Foram realizadas medidas
dos 4 sensores individualmente (usando o
PulseView), usando a saída que vai para
o display.

As leituras foram feitas e identificadas em
intervalos de 10cm.

A analise preliminar identificou que os
sensores tem a relação: A = B, e C = D

E que o módulo envia os dados para o
display em intervalos de 400ms a 500ms.

49. Identificação do Padrão de Comunicação

Análise do SINAL
Inicio da transmissão: Sinal de nível baixo, em seguida nível alto por 1000uS = 1ms
Captura na configuração de 25Khz, identificados os pacotes em intervalos de ~450ms

A seguir os detalhes de um pacote:

50. Identificação do Padrão de Comunicação

Análise dos Dados
Foram considerados vários padrões de transmissão em [1],
porém não foi identificado inicialmente nenhuma similaridade.
A codificação dos 0 e 1, é feita através da largura/tempo dos
pulsos em alta (5v), algo similar à transmissão IR[2].
[1] https://pt.slideshare.net/RathoreRavindra/line-coding-37072941
[2] https://www.vishay.com/docs/80071/dataform.pdf

51. Identificação do Padrão de Comunicação

Análise dos Dados

Os 8 bits iniciais são do conjunto sensores A e B, ou seja, é
uma única medida (Esquerda). O 8bits seguintes são do C e
D (Direita);

O valor convertido em decimal varia de : 19 (distância de
0cm) até 4 (distância de 1.7m);

As leituras individuais apresentaram a mesma correlação.

52. Arduino / Código

A leitura é feita usando as interrupções externas e
calculado o tempo do pulso em alta. Usando as
interrupções ao invés de pulseIn(), permitimos o arduino
executar outras tarefas.

No Arduino UNO (328p) – Pinos 2, 3

No ESP8266 – Todos os pinos GPIO ( - GPIO16 )
O código desenvolvido está disponibilizado em:
https://github.com/OpenDevice/opendevice-examples/tree/master/IoTCar/firmware

53. Arduino / Demo

Setup

ESP8266 – Captura os dados vindos da central de
controle, faz a decodificação e envia para o Arduino via
Serial/UART;

O ESP8266 também disponibilizará os dados para o
App (usando a lib OpenDevice), e permite um sistema
de detecção automática no App.

Arduino UNO – Responsável pelo display LCD (usando
a lib Tvout).

54. Demo / Esquemático
NÃO ESQUEÇA , TODOS OS GNDs DEVEM SER CONECTADOS !

55. Demo / Video

56. Demo / App

57. Demo / Esquemático

58. Dúvidas ?

59. Contatos
E-mail:

ricardo.jl.rufino@gmail.cm

ricardo@criativasoft.com.br
Facebook:

/ricardojlrufino

/opendevice

60. Obrigado pela sua atenção.