CENTRO PAULA SOUZA DE EDUCAÇÃO TECNOLÓGICA
FACULDADE DE TECNOLOGIA RUBENS LARA
Claudio Gomes Gobbetti
Robson Louro legramante
Integração de Dispositivo Móvel com a computação embarcada automotiva
Trabalho de Conclusão de Curso
apresentado À Faculdade de Tecnologia
Rubens Lara como parte dos requisitos
para obtenção do título de Tecnólogo em
Análise e Desenvolvimento de Sistemas.
Orientador
Ms. Ciro Cirne Trindade
Santos
2012
CLAUDIO GOMES GOBBETTI
ROBSON LOURO LEGRAMANTE
Integração de Dispositivo Móvel com a
computação embarcada automotiva.
Banca Examinadora:
Orientador:
Ms. Ciro Cirne Trindade
Membro:
<>
Membro:
<>
Santos
2012
RESUMO
Todo veículo automotor moderno possui um Sistema Computacional Distribuído que trabalha
visando à segurança e bem estar dos ocupantes. Este Sistema possui um sistema de diagnose
definido como On-Board Diagnostic (OBD) que permite que sejam coletadas informações de
seu estado atual, falhas registradas anteriormente e identificação do veículo e seus
componentes. O CONAMA inclui nas ações governamentais de controle de poluição o
sistema OBD, gerando a obrigatoriedade das montadoras de que sejam registrados dados que
permitam verificar o estado do veículo para prevenção e controle de poluição. O acesso ao
sistema OBD eram disponibilizado apenas à especialista do meio automobilístico e seus
equipamentos eram dispendiosos. Visando tornar acessível efetuou-se o estudo referente a
integrar o Sistema OBD a um dispositivo móvel dotado de Sistema Operacional Android
através de um dispositivo Bluetooth. O estudo gerou um aplicativo que possibilita a obtenção
das informações contidas no veículo e sua interpretação.
Palavras-chave: On-Board Diagnostic, OBD, Bluetooth, Veículo automotor, Poluição,
Identificação veicular.
ABSTRACT
Every motor vehicle has a modern Distributed Computer System that works to the safety and
welfare of the occupants. This system has a system of diagnosis defined as On-Board
Diagnostic (OBD) system that allows information to be collected from its current state,
recorded earlier failures and identify the vehicle and its components. The CONAMA includes
government actions in pollution control OBD, generated the requirement the automakers that
are registered data to check the status of the vehicle to prevent and control pollution. Access
to the OBD system was only available through the specialist automobile and its equipment
was costly. Aiming make it accessible was made the study concerning the OBD system
integration with a mobile device equipped with Android operating system via a Bluetooth
device. The study generated an application that enables the collection of information
contained in the vehicle and its interpretation.
Keywords: On-Board Diagnostics, OBD, Bluetooth, Automotive vehicle, Pollution, Vehicle
identification.


SUMÁRIO
INTRODUÇÃO ................................................................................................................ 10
COMPUTAÇÃO EMBARCADA AUTOMOTIVA ....................................................... 15
2.1
Definição................................................................................................................ 15
2.1.1
Unidade Eletrônica de Controle – ECU ............................................................ 15
2.1.2
Redes de Comunicação Automotivas ............................................................... 16
2.2
Diagnóstico Automotivo........................................................................................ 17
2.2.1
Definição ........................................................................................................... 17
2.2.2
Evolução do OBD ............................................................................................. 18
2.2.3
Padrão OBD-II .................................................................................................. 18
2.2.3.1 Diagnostic Troube Code - DTC ................................................................... 20
2.2.4
Padrão OBDBr-2 ............................................................................................... 21
2.2.5
Conector do OBD-II ......................................................................................... 22
2.2.6
Protocolos de Comunicação .............................................................................. 23
 TECNOLOGIA ................................................................................................................ 25
3.1
Android .................................................................................................................. 25
3.2
Arquitetura Android............................................................................................... 25
3.3
Aplicações.............................................................................................................. 27
 DO SISTEMA .................................................................................................................. 30
4.1
Arquitetura Geral do Sistema ................................................................................ 30
4.2
Do desenvolvimento do Sistema ........................................................................... 30
4.2.1
Da Conexão BLUETOOTH .............................................................................. 33
4.2.2
Das funcionalidades .......................................................................................... 36
4.3
Da Aplicação Android ........................................................................................... 37
 CONSIDERAÇÕES FINAIS ........................................................................................... 41
REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 42
LISTA DE ILUSTRAÇÕES
Ilustração 1 - Comparação de Vendas entre PC’s e dispositivos móveis. ................................ 11
Ilustração 2 - Market Share e Previsão de Vendas ................................................................... 11
Ilustração 3 - Conector fêmea OBD-II com indicação de pinagem ......................................... 22
Ilustração 4 - Dispositivo ELM 327 - Bluetooth ...................................................................... 24
Ilustração 5 - Arquitetura Android ........................................................................................... 26
Ilustração 6 - Solicitação de permissões ao instalar ................................................................. 28
Ilustração 7 - Instalação dos Pacotes através do SDK Android Manager ................................ 31
Ilustração 8 - Distribuição atual das versões da Plataforma Android....................................... 33
Ilustração 9 - Fluxograma da conexão Bluetooth ..................................................................... 35
Ilustração 10 - Tela de linha de comando ................................................................................. 38
Ilustração 11 - Tela com linhas de Comando AT ..................................................................... 39
Ilustração 12 - Tela de Comandos no modo gráfico ................................................................. 40
LISTA DE TABELAS
Tabela 1 - Códigos de solicitação SERVICE ........................................................................... 19
Tabela 2 - Pinagem do conector OBD-II .................................................................................. 23
LISTA DE ABREVIAÇÕES
ADB
ANATEL
ANFAVEA
API
AOSP
AVD
BCM
CALID
CAN
CONAMA
CPU
DTC
DVM
ECM
ECU
EOBD
GPS
ISO
KW2000
MAC Adress
MIL
OBD
OBDBr
OICA
OSI
PCM
PC
PID
PWM
SAE
SDK
SMS
TCM
UTF-16
UTF-8
VIN
VPW
Android Device Bridge
Agência Nacional de Telecomunicações
Associação Nacional de Fabricantes de Veículos Automotores
Application Programming Interface
Android Open Source Project
Android Virtual Device
Body Control Module
Calibration Identifications
Controller Area Network
Conselho Nacional de Meio Ambiente
Central Processing Unit
Diagnostic Trouble Codes
Dalvik Virutal Machine
Engine Control Module
Eletronic Control Unit
European On-Board Diagnostics System
Global Positioning System
International Organization for Standardization
Keyword 2000
Media Access Control Adress
Malfunction Indication Lamp
On-Board Diagnostic System
On-Board Diagnostic System - Brasil
Organisation Internationale des Constructeurs d’Automobiles
Open Systems Interconnection
Powertrain Control Module
Pocket Computer
Parameter Identification
Pulse Width Modulation
Society of Automobile Engineers
Software Development Kit
Short Message Service
Transmission Control Module
16-bit Unicode Transformation Format
8-bit Unicode Transformation Format
Vehicle Identification Number
Variable Pulse Width
 INTRODUÇÃO
Os Sistemas de Informações e o controle de processos baseados em CPU1s passaram a
ser instrumento indispensável na vida profissional e particular das pessoas. Entretanto, mais
de 90 por cento das CPUs em utilização no mundo não estão em PCs desktops e notebooks
(TANENBAUM, 2009). Eles estão em aparelhos comuns como telefones celulares, tablets,
roteadores sem fio, modens, aparelhos GPS, televisores e veículos automotivos entre outros.
Quando tais Sistemas de Informações e o controle de processos são completamente
encapsulados ou dedicados ao dispositivo ou sistema que ele controla é considerado um
Sistema Embarcado. Com mais de 40 milhões de veículos produzidos e registrados no Brasil
nos últimos 10 anos (ANFAVEA, 2012) e aproximadamente 60 milhões de veículos
produzidos no mundo apenas em 2011 (OICA, 2012), a computação embarcada
automobilística tornou-se um assunto de relevante importância.
Nos
últimos
anos
presenciamos
uma
evolução
tecnológica
na
indústria
automobilística, e um dos maiores avanço foi a padronização de um sistema de comunicação,
diagnóstico e aviso de erros de todos os componentes de um veículo conhecido por OBD (OnBoard Diagnostic System).
O modelo foi introduzido ao mercado pela Volkswagen em 1969, quando incluiu em
seus carros um sistema computadorizado com capacidade de escaneamento de erros em seus
primeiros modelos de carros equipados com injeção eletrônica, e desde então tem sido
evoluído até chegar ao modelo usado nos dias de hoje, conhecido como OBD-II.
Com a evolução tecnológica, outras áreas acabam se destacando, como é o caso da
área móvel, formada por Smartphones e Tablets, tendo sido vendido no ano passado mais
unidades de tais dispositivos móveis do que PC’s comuns, conforme mostra estudo realizado
pela empresa especializada em TI Canalys (CANALYS, 2012), visto na Ilustração 1.
1
1
CPU – Unidade Central de Processamento (Central Processing Unit)
Ilustração 1 - Comparação de Vendas entre PC’s e dispositivos móveis.
Outro estudo, realizado pelo instituto Gartner (GARTNER, 2012), indica a explosão
do Sistema Android, mostrando a evolução do Sistema em Market Share, durante os últimos
anos e prevendo uma participação próxima a 50% nos Sistemas Operacionais instalados em
dispositivos móveis, como mostra a Ilustração 2.
Ilustração 2 - Market Share e Previsão de Vendas
A utilização do OBD-II sempre esbarrou em um problema, sua utilização era apenas
visando técnicos de manutenção manuseando equipamentos caros e restritos. Para uma
verificação apurada era necessário que o veículo estivesse ligado por cabos a uma estação de
checagem, normalmente um desktop, sendo tais cabos e programas específicos a cada modelo
de veículo. Estes empecilhos geram descrença de proprietários de veículos, visto que, em
muitos lugares o lucro do estabelecimento ainda é feito em cima de pessoas sem
conhecimento avançado de mecânica e sem acesso as informações do Sistema de Diagnóstico
do veículo.
Existe também certa dificuldade de órgãos públicos em fiscalizar veículos
automotores de procedência duvidosa, não existindo métodos que possam identificar o
veículo e assegurar a autenticidade das informações contidas no sistema embarcado.
O surgimento de conectores de diagnóstico OBD-II utilizando a tecnologia Bluetooth
o qual, em tese, eliminaria a necessidade de cabos e estações de checagem e como um grande
número de dispositivos móveis tais, como Smartphones e Tablets, possuem incorporados tal
protocolo de comunicação, surgem então as questões:
Como integrar dispositivos móveis baseados em Sistema Operacional Android com
sistemas embarcados automotivos, mais especificamente com o OBD-II, através do protocolo
de comunicação Bluetooth?
Como utilizar tal integração para coletar dados do veículo tanto para uso de
manutenção e prevenção como para identificação do veículo?
Tais perguntas levam a este Trabalho de Conclusão de Curso.
Este Trabalho teve como objetivo o aprendizado das técnicas e desenvolvimento de
uma aplicação em linguagem Java, compatível com dispositivos móveis que utilizam Sistema
Operacional Android, para que, através de uma conexão Bluetooth com um adaptador
compatível com OBD-II, todas as informações obtidas através dos sensores instalados em um
veículo possam ser mostradas para o usuário, sejam essas informações referentes a erros e
defeitos, identificação veicular ou apenas informações simples, como velocidade de rotação e
temperatura do motor.
Para validar o desenvolvimento da aplicação e sua confiabilidade na coleta de
informações referentes oa status do veículo e sua identificação, planejamos testes com os
seguintes objetivos:

Realizar ensaios para coleta de informações em diversos veículos;Realizar os
mesmos ensaios alterando condições, tais como, simulando defeitos (testes não
realizado por motivos alheios a nossa vontade);

Verificar confiabilidade da identificação do veículo tanto através do numeral
VIN2, bem como por números de autenticação do sistema coletados utilizando
o OBD-II.
Na loja de aplicativos do Google, a Play Store, existem poucos aplicativos
compatíveis com o protocolo OBD-II, sendo que os poucos existentes são falhos ou com
funções que não ajudariam uma gama maior de usuários.
O desenvolvimento do aplicativo, devido às facilidades da plataforma escolhida, o
número de usuários e suas previsões de vendas atingirão três tipos de usuário:

O cliente de uma oficina ou concessionária que deseja saber se o seu
veículo, por exemplo, está com aquela peça realmente quebrada ou apenas
saber se o carro usado que está comprando tem realmente aquela
quilometragem mostrada.

Órgãos públicos que necessitam de informações detalhadas de veículos,
como se o número de chassi que consta gravado no módulo do carro
corresponde com o chassi do veículo.

Seguradoras/vistoriadoras de veículos, as quais precisam de informações
que podem ser omitidas por clientes.
No intuito de desenvolver o aplicativo utilizamos “Pesquisa Bibliográfica” onde foram
utilizados livros, artigos científicos publicados e artigos técnicos relacionados com os
assuntos. Consultados também manuais técnicos dos equipamentos utilizados (B&B
ELETRONIC MANUFECTURING COMPANY, 2012; ELM ELECTRONICS, 2012) e
material de cursos de habilitação em tais equipamentos; realizamos “Estudo de Ferramenta”
2
VIN – Número de identificação do veículo (Vehicle Identification Number).
utilizando ferramentas de interface para comunicação entre o veículo e o dispositivo móvel,
ferramentas de desenvolvimento para dispositivos móveis e ferramentas de teste e finalmente
efetuamos “Pesquisa Exploratória” onde realizamos levantamento das instruções utilizadas
pelo Sistema OBD-II e os padrões de dados recebidos e suas conversões. Também fez parte
da pesquisa exploratória o desenvolvimento do sistema e os testes de campo. Quanto ao
desenvolvimento do sistema este foi desenvolvido utilizando conhecimentos em Linguagem
de Programação Java, voltada para o Sistema Operacional Android. Foi realizado estudo
específico das classes que permitem a utilização de dispositivos Bluetooth na plataforma
Android. Os testes de campo foram realizados aquém do nosso desejo, pois a dificuldade de
conseguir veículos de diversas marcas e ano de fabricação precisa ser levado em relevância
quanto à consistência da massa de teste.
 COMPUTAÇÃO EMBARCADA AUTOMOTIVA
2.1 Definição
Os veículos automotivos atualmente podem ser considerados complexos Sistemas
Computacionais Distribuídos Embarcados (NOLTE, HANSSON, LO BELLO, 2005). Um
Sistema Computacional pode ser definido como distribuído se atender as seguintes
características: diversas unidades de processamento próprias e com memórias individuais que
compartilham informações através de uma rede de dados com o objetivo de concluir uma
tarefa em comum (TANENBAUM, 2009). No mesmo princípio um sistema é dito embarcado
quando se dedica a uma única tarefa e interage continuamente com o ambiente à sua volta por
meio de sensores e atuadores (SANTOS, 2010).
2.1.1 Unidade Eletrônica de Controle – ECU
As Unidades Eletrônicas de Controle (Eletronic Control Unit – ECU) são dispostas
em módulos eletrônicos, os quais são responsáveis pela leitura das entradas, acionamento das
saídas e pelo gerenciamento dos protocolos de comunicação utilizados nos veículos
(GUIMARÃES, 2011). Um módulo ECU é tipicamente constituído por um microprocessador,
uma memória que armazena o software3 do módulo, portas para os controladores de
comunicação, portas de entrada de sinais medidos por sensores e portas de saída dos sinais
controlados pelo módulo.
Conforme a finalidade da ECU são utilizadas siglas padronizadas como forma de
identificar os diversos sistemas e os seus controles. Seguem alguns dos principais módulos e
suas siglas:

Body Control Module (BCM): Módulo de Controle da Carroceria. Quando
esta denominação é utilizada, significa que todas as funções básicas e até
algumas funções opcionais são realizadas por essa ECU. Em caso de mais de
3
Software da ECU: Constituído de um Firmware (programa gravado em uma memória EEPROM), área
de memória para calibração e parâmetros programáveis. O Firmware é gravado pelo fornecedor do módulo, os
dados de calibração são gravados pela montadora do veículo conforme a aplicação do módulo.
uma rede de comunicação de dados geralmente a BCM tem a função de
compatibilizar os níveis de sinais de tais redes.

Engine Control Module (ECM): Módulo de Controle do Motor.

Transmission Control Module (TCM): Módulo de Controle da Transmissão.

Powertrain Control Module (PCM):
Módulo de Controle do Motor e
Transmissão, módulo que controla o conjunto motor e transmissão.
2.1.2 Redes de Comunicação Automotivas
No setor automotivo a utilização de um maior número de ECU por veículo, sendo que
em alguns casos ultrapassam 60 módulos em um único veículo, gerou a necessidade da
criação de Protocolos de Comunicação Automotivos. Como toda rede de comunicação
computacional tais protocolos seguem o padrão de comunicação OSI de sete camadas (ISO
7498).

Camada 1: Física – Define as especificações elétricas e físicas dos
dispositivos, sendo responsável pela codificação e decodificação de símbolos
em sinais elétricos que serão lançados no meio físico. Efetua transmissões de
bits (0 e 1).

Camada 2: Enlace de dados - Detecta e corrige erros encontrados na Camada
1. Responsável pela conexão confiável e controla a taxa de transmissão
evitando que o sistema transmissor envie dados em uma taxa maior do que o
receptor consegue processar.

Camada 3: Rede - Controla as operações da rede efetuando o roteamento na
rede e garante o endereçamento.

Camada 4: Transporte - Parte central de toda a hierarquia de protocolos. Sua
tarefa é prover o transporte confiável de dados, independente da rede física.
Segmenta a mensagem no transmissor e monta no receptor.

Camada 5: Sessão – Estabelece, gerencia e finaliza as conexões entre
módulos ligados a rede de comunicação de dados.

Camada 6: Apresentação – Assegura que a informação seja transmitida de tal
forma que possa ser entendida e utilizada pelo receptor.

Camada 7: Aplicação – Camada superior do modelo OSI, responsável por
prover serviços para as aplicações superiores de forma a abstrair a existência
de comunicação entre processos de diferentes computadores.
As tecnologias de redes automotivas podem ser classificadas quanto à funcionalidade
e satisfação de requisitos operacionais entre outras características. Em um veículo podem
existir diversas tecnologias de redes de comunicações, porém tal detalhamento não faz parte
do escopo deste trabalho. Como exemplo, temos a classificação de redes automotivas da SAE4
que agrupa protocolos de comunicação em classes e utiliza as denominações Classe A
(sensores e controles não críticos e alguns diagnósticos), Classe B (utilizado para
comunicação entre ECUs) e Classe C (Comunicação de alta velocidade para sistemas que
envolvam segurança do veículo) que diferem quanto ao barramento de comunicação, a taxa de
transmissão e utilização. Também utiliza as classes Mobile Media (Entretenimento), Safety
Bus (Airbag), Drive by-wire (Substituição de acionamentos mecânicos, tais como freio e
acelerado, por acionamento elétrico) e a Classe Diagnóstico que faz parte do escopo deste
trabalho.
2.2
Diagnóstico Automotivo
2.2.1 Definição
O Diagnóstico Automotivo surgiu da necessidade de verificar possíveis falhas de
sistemas na Computação Embarcada Automotiva, bem como efetuar a telemetria do veículo.
Criaram-se requisitos para a troca de informação entre os módulos ECU, armazenamento de
códigos de falhas DTC5, identificação dos módulos e do veículo. Tal sistema recebeu a
designação OBD (On-board diagnostics) que compreende toda a aquisição de dados
disponíveis através de um equipamento externo. Evoluiu de uma simples luz indicadora que
avisava sobre uma falha no motor ou painel até um controle total que permite que problemas
sejam detectados, identificados e resolvidos rapidamente.
4
SAE: Society of Automobile Engineers - Associação global de engenheiros e técnicos que visa
desenvolver padrões para os mercados aeroespacial, automotivo e comercial do veículo.
5
DTC: Diagnostic Trouble Codes, definidos no item 2.2.3.1.
2.2.2 Evolução do OBD
No final da década de 60 e início da década de 70 veículos começaram a utilizar ECUs
para monitorar e ajustar sistema de injeção eletrônicas, dando início às primeiras
implementações de OBD, mas sem um padrão definido. Na década de 80 cria-se o primeiro
padrão para conectores e sinais de diagnóstico que foi definido como OBD-I. Na década de
90 cria-se o padrão OBD-II com conectores e protocolos de comunicação, padrão este
adotado por todos os carros vendidos nos Estados Unidos. A União Europeia toma como base
o OBD-II e cria o EOBD para todos os veículos vendidos em sua região.
No Brasil o grande marco em relação à telemetria automotiva adveio do Conselho
Nacional de Meio Ambiente - CONAMA que estabeleceu, através da Resolução 354 de 13 de
dezembro de 2004, a criação dos Sistemas OBDBr-1 e OBDBr-2 para o controle de poluição
do ar por veículos automotores, sistemas estes baseados no OBD-II. Tal resolução teve sua
implementação gradativa, sendo a primeira fase o sistema OBDBr-1 e progredindo para o
sistema OBDBr-2. Desde o início de 2011 tornou-se obrigatório que o Sistema de Diagnose
OBDBr-2 esteja presente e acessível em todos os veículos leves de passageiro e leves
comerciais, nacionais e importados destinados ao mercado brasileiro.
2.2.3 Padrão OBD-II
O padrão OBD-II para solicitação e recebimento de telemetria dos módulos segue a
ISO 15031-5:2006 que define todas as requisições de serviços padrão, independente dos
protocolos de comunicação ou do emissor da norma. Tal diferenciação será explicada mais a
frente quando exemplificarmos os métodos de conexão com o ODB-II.
São padronizados os códigos de solicitação de informação a partir de um par definido
como SERVICE e PID. Uma requisição de SERVICE é definida pela ISO 15031-5:2006
como “troca de informações iniciada por um cliente (equipamento de teste externo) a fim de
exigir informações de diagnóstico a partir de um módulo (ECU) e / ou para modificar o seu
comportamento para fins de diagnóstico6”. Um código PID (Parameter Identification)
completa o par da solicitação de informação sendo que seus valores variam de $01 a $FF (em
hexadecimal), porém nem todos os valores de PID são utilizados em todos os SERVICE.
Exceção feita ao SERVICE $01 PID $00 que é definido como mensagem universal de
6
Tradução livre.
“inicialization/keep alive/ping” entre todas as emissões que relacione o OBD com uma ECU.
Os códigos de solicitação SERVICE são definidos conforme a tabela 1.
Cabe ressaltar que a ISO 15031-5:2006 define os códigos PID mínimos utilizados e
que estes são reservados em comum a todas as montadoras de veículos, sendo possível a
utilização pelas montadoras de PID próprios para controle de funções exclusivas.
Tabela 1 - Códigos de solicitação SERVICE
SERVICE
$01
$02
$03
$04
$05
$06
$07
$08
$09
ISO 15031-5:2006
Request current powertrain diagnostic data
Request powertrain freeze frame data
Request emission-related diagnostic trouble codes
Clear/reset emission-related diagnostic information
Request oxygen sensor monitoring test results
Request on-board monitoring test results for specific monitored
systems
Request emission-related diagnostic trouble codes detected during
current or last completed driving cycle
Request control of on-board system, test or component
Request vehicle information
Como tradução livre e resumo dos SERVICE (Tabela 1) temos:

SERVICE $01: Requisição de dados correntes presentes na memória RAM da
ECU sobre o Sistema Powertrain (motor e transmissão).

SERVICE $02: Serviço responsável pela aquisição de parâmetros instantâneos
(QIP), sendo que fornece a condição do veículo no exato momento de uma
falha registrada através da lâmpada MIL7.

SERVICE $03: Requisição dos códigos de falha (DTC8).

SERVICE $04: Reseta os códigos de falha existentes no veículo.

SERVICE $05: Requisição para visualizar os resultados dos testes no sensor
de oxigênio.
MIL: Malfunction Indicator Lamp – Lâmpada instalada no painel do veículo que informa um mau
funcionamento do sistema de controle de emissões. Descrita na Instrução Normativa nº 24/2009 IBAMA.
8
DTC: Diagnostic Trouble Codes, definidos no item 2.2.3.1.
7

SERVICE $06: Requisição para visualizar resultados dos testes on-board em
componentes específicos, como catalisador (PID $21).

SERVICE $07: Similar ao SERVICE $03, porém apresenta os últimos DTCs
que ocorreram mas não necessariamente acenderam a MIL.
2.2.3.1

SERVICE $08: Requisição para testes específicos nas ECUs.

SERVICE $09: Fornece informações gerais sobre a identificação do veículo.
Diagnostic Troube Code - DTC
Toda vez que uma ECU reconhece uma falha ou mau funcionamento em algum
sistema do veículo, módulo eletrônico, ou ainda perda de comunicação entre ECUs fica
registrado na memória dos módulos eletrônicos um código DTC. Este código é registrado
automaticamente e pode ser recuperado através de um equipamento externo utilizando as
solicitações de SERVICE $03 e $07. Os códigos de falha, definidos na ISO 15031-6,
possuem um conjunto de cinco dígitos sendo o primeiro dígito sempre será representado por
uma letra (B / C / P / U) e define o sistema que está sofrendo a falha. O segundo dígito, de
valor numérico 0 a 3, define se este código de erro é genérico (ISO/SAE) ou trata-se de uma
DTC específica da montadora. O terceiro dígito alfanumérico (0 a 9, A, B, C) indica o
subsistema que onde está acontecendo a falha. O quatro e quinto dígitos correspondem ao
número serial da falha diagnóstica para aquele grupo, variando de 00 a 99. Tais códigos
seguem o seguinte padrão:
1º Dígito – Grupo Sistema:
P – Motor (Powertrain)
B – Carroceria (Body)
C – Chassi (Chassi)
U – Rede (Network)
2º Dígito – Tipo de DTC9:
0 – Descrição ISO/SAE
1 – Descrição Montadora
9
Códigos 0 e 1 são padrões para todos os Grupos de Sistema, valores 2 e 3 assumem padrões próprios
dependendo do Grupo de Sistema.
3º Dígito – Indicação Subsistema:
1 – Medição de combustível e ar
2 – Medição de combustível e ar (injetor)
3 – Sistema de Ignição
4 – Controle Auxiliar de Emissões
5 – Controle de Velocidade veículo/Rotação
6 - Circuitos de Entrada/Saída Computador
7 – Transmissão
8 – Transmissão
2.2.4 Padrão OBDBr-2
Conselho Nacional de Meio Ambiente - CONAMA estabeleceu, através da Resolução
354 de 13 de dezembro de 2004, padrões de controle de poluição do ar por veículos
automotores os quais nomeou como OBDBr (BRASIL, 2004). Definiu controles obrigatórios
através do diagnóstico de bordo (OBD) e estipulou duas etapas consecutivas e
complementares denominadas por OBDBr-1 e OBDBr-2, esta última totalmente
implementada desde janeiro de
2011. Posteriormente o IBAMA estabeleceu, em suas
Instruções Normativas nº 126/2006 e nº 24/2009, especificações e critérios de verificação dos
sistemas OBDBr-2 (BRASIL, 2006 e 2009). Determinou que a norma técnica a ser seguida
para verificação dos dispositivos mínimos, seria a ISO 15031 – parte 3, 4, 5 e 6. A parte 3 da
norma define o conector que deve estar disponível no veículo e a parte 4 os protocolos de
comunicação. A parte 5 da ISO 15031 trata da aquisição de dados através dos serviços
SERVICE e PID e a Instruções Normativas definem os serviços mínimos ativos no veículo
como:
Service $01 – Request current powertrain diagnostic data:
PID $01: Números de relatos DTC e status da MIL;
PID $21: Distância percorrida desde o acionamento da MIL.
Service $03 – Request emission-related diagnostic trouble codes: completo.
Service $04 – Clear/reset emission-related diagnostic information: completo.
Service $09 – Request vehicle information:
PID $01: Número de mensagens para reportar o VIN.
PID $02: VIN (Vehicle Identification Number).
PID $03: Número de mensagens para reportar o CALID.
PID $04: CALID10 – Calibration Identifications.
Todos os códigos DTC definidos na ISO 15031-6 devem ser integralmente acessíveis
por meio do equipamento de diagnóstico normalizado.
2.2.5 Conector do OBD-II
A ISO 15031-3 especifica os requisitos pra o conector OBD-II para comunicação
entre um veículo e um equipamento de diagnóstico. Determina que o conector instalado no
veículo (tipo fêmea) deve ter fácil acesso e sempre instalado ao alcance do motorista. O
conector de diagnóstico (tipo macho) possui 16 pinos (2X8). Basicamente permite a conexão
com todos os protocolos de comunicação através da seleção dos pinos correspondentes. Sua
pinagem (Tabela 2) e formato (Ilustração 3) são apresentados a seguir.
Ilustração 3 - Conector fêmea OBD-II com indicação de pinagem
10
CALID: Identifica o software instalado na ECU e suas calibrações.
Tabela 2 - Pinagem do conector OBD-II
Pino
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Descrição
Fabricante
J1850 Bus+
Fabricante
Chassi Terra (GND)
Sinal Terra (GND)
CAN high (ISO 15765-4/SAE J2284)
K line (ISO 9141-2 ou ISO 14230-4)
Fabricante
Fabricante
J1850 BusFabricante
Fabricante
Fabricante
CAN low (ISO 15765-4/SAE J2284)
L line (ISO 9141-2 ou ISO 14230-4)
Voltage Positiva Permanente
2.2.6 Protocolos de Comunicação
Existem cinco protocolos de sinais possíveis em sistema OBD-II, que diferem quando
taxa de transferência, utilização de pinagem do conector OBD-II, sistema de detecção de erro
de transmissão e método de estabelecer contato. O protocolo mais utilizado ultimamente é o
ISO 15765 também conhecido como Controller Area Network (CAN). Os outros protocolos
são SAE J1850 PWM (Pulse Width Modulation), SAE J1850 VPW (Variable Pulse Width),
ISO
9141-2 e o ISO 14230, também conhecido como KW2000 (Keyword 2000). Tais
protocolos não fazem parte do detalhamento do escopo deste trabalho, pois a ferramenta que
será utilizada para a conexão entre OBD-II e os dispositivos móveis será a ELM 327 –
Interface Bluetooth (vide a Ilustração 4), ferramenta esta que através de comandos identifica
os protocolos de comunicação estabelecendo uma conexão.
Ilustração 4 - Dispositivo ELM 327 - Bluetooth
Fonte: Captado pelos Autores
O dispositivo ELM 327 – Interface Bluetooth uma vez instalado no conector OBD – II
do veículo conseguirá estabelecer uma conexão entre o sistema OBD – II do veículo e o
Sistema a ser desenvolvido, executar as solicitações SERVICE e PID e retransmitir
informações do veículo e as DTC.
as
 TECNOLOGIA
3.1 Android
Segundo a Anatel, em 2007 existiam 160,4 milhões de aparelhos móveis no Brasil,
uma média de 0,84 aparelhos por habitante, e chegando em 2011 com 285,2 milhões de
aparelhos, aumentando esta média para 1,45 por habitante, nos dá uma idéia do crescimento
comercial deste tipo de dispositivo.
Por suas previsões comerciais e de market-share, a plataforma usada neste projeto será
o Android, um sistema operacional móvel aberto baseado em Linux.
O Android foi criado em 2003, pela empresa chamada Android, Inc., que, nas palavras
de um de seus fundadores, Andy Rubin, foi criada para desenvolver "dispositivos inteligentes
móveis que, dentre outras coisas, estão mais cientes da localização de seu dono e
preferências".
Em 2005 a empresa foi adquirida pelo Google, e seus fundadores contratados pela
empresa. Andy hoje é Vice-Presidente de Móveis do Google.
Em 2007, o Google anuncia a primeira distribuição do Android, junto com a fundação
da Open Handset Alliance, um consórcio de 86 empresas de hardware, software e
telecomunicações. Encarregado de discutir, planejar e desenvolver novos padrões e
tecnologias para dispositivos móveis, o consórcio é liderada pelo Google.
Atualmente, o código-fonte do Android é disponibilizado em Open-Source, sob a
licença Apache.
O projeto de código aberto do Android (Android Open Source Project, ou AOSP) é
liderado pelo Google, que é encarregado principalmente da manutenção do código e futuros
desenvolvimentos.
3.2 Arquitetura Android
A arquitetura do sistema operacional Android é uma pilha agrupada em camadas
divididas em quatro níveis, normalmente chamados de níveis zero, um, dois e três, conforme
figura abaixo:
Ilustração 5 - Arquitetura Android
Fonte: http://developer.android.com/guide/basics/what-is-android.htm
No Nível Zero temos o Kernel, também chamado de base da pilha. Foi desenvolvido
utilizando-se a versão 26 do SO Linux.
É onde se encontram os programas de gerenciamento de memória, configurações de
segurança e alguns dos drivers de hardware.
No Nível Um encontram-se as camadas de biblioteca (libraries e de tempo de
execução - Android RunTime).
A camada de biblioteca é responsável por tratar diferentes tipos de dados, incluindo
uma biblioteca C/C++ usada por componentes do sistema.
A camada de tempo de execução é formada por um conjunto de bibliotecas do núcleo
Java e a Máquina Virtual Dalvik (DVM), usada para a compilação de aplicações do
dispositivo. A DVM é otimizada para trabalhar com baixa memória e permite várias
instancias rodando ao mesmo tempo.
A estrutura do Android usa a máquina virtual para que nenhuma aplicação fique
dependente de outra, e simplifica o gerenciamento da memória.
No Nível Dois temos a camada de framework de aplicação (Application Framework),
onde residem programas que gerenciam as aplicações básicas do telefone.
No Nível Três estão as camadas de aplicações e funções especificas do dispositivo,
onde são fornecidas as funções do telefone, tais como fazer uma ligação, enviar um SMS, etc.
3.3 Aplicações
O Android conta com uma vasta biblioteca de API's, facilitando o desenvolvimento de
aplicações e permitindo que suas funções sejam mais bem gerenciadas, tanto do ponto de vista
do usuário quanto do desenvolvedor.
Uma das maiores diferenças na plataforma Android é que não existem privilégios
entre as aplicações embarcadas no dispositivo e aplicações criadas por desenvolvedores.
Ambas são desenvolvidas com o mesmo SDK (Kit de desenvolvimento de software),
mostrando que é possível criar aplicações que utilizem todos os recursos do aparelho.
Aplicativos de terceiros, também conhecidos como third-party têm a mesma prioridade para
serem executados que aplicativos de núcleo.
O SDK do Android é bem completo e dá acessos a qualquer função que o sistema
operacional tenha, permitindo ao desenvolvedor uma liberdade maior ao adicionar funções, ao
contrário de outras plataformas móveis onde, por exemplo, a funcionalidade de bluetooth é
disponível apenas para atividades relacionadas ao player de música, como fones de ouvidos.
Após a fase de pesquisa bibliográfica e durante a fase de estudo de ferramentas,
optamos por usar a IDE Eclipse para o desenvolvimento, utilizando um plugin não oficial,
porém indicado na página oficial do Android Developer (ANDROID), que irá possibilitar o
uso do vasto conjunto de bibliotecas existentes no SDK, conhecidas como API. A instalação
de todos os componentes necessários também foi seguida de acordo com as recomendações
disponíveis no mesmo site.
Dentre essas API's está o conjunto de classes e métodos disponíveis para o uso do
Bluetooth. Este conjunto abrange desde tarefas mais simples, como verificar se o existe um
adaptador Bluetooth no aparelho, descobrir outros aparelhos e ser descoberto por esses
mesmos aparelhos, solicitar conexões com outros dispositivos, podendo estas conexões serem
seguras, através de uma senha solicitada pelos dois aparelhos ou sem segurança.
Para toda e qualquer funcionalidade que seja inserida dentro de uma aplicação e que
possa envolver a segurança do usuário, a plataforma exige que sejam solicitadas permissões.
Estas permissões devem ser declaradas no AndroidManifest.xml e devem estar
condizentes com as funcionalidades da aplicação. A segurança para o usuário se dá quando a
aplicação é instalada, onde uma tela aparece mostrando quais permissões o aplicativo
necessita e se o usuário aceita estas permissões. Caso o usuário não concorde com as
permissões à instalação do programa é abortada (Ilustração 6).
Ilustração 6 - Solicitação de permissões ao instalar
Fonte: Elaborado pelos Autores
Dentro das permissões que deverão ser solicitadas, deve-se usar os dois tipos de
permissão existentes relacionados ao Bluetooth: BLUETOOTH, para obter permissão de
comunicação através do adaptador Bluetooth e BLUETOOTH ADMIN, para manipular
configurações dos dispositivos, como por exemplo, ativar o adaptador caso o mesmo esteja
desativado.
 DO SISTEMA
Este capítulo descreve o Sistema desenvolvido e como este foi concebido a partir do
problema inicial: como integrar dispositivos móveis baseados em Sistema Operacional
Android com sistemas embarcados automotivos, mais especificamente com o OBD-II, através
do protocolo de comunicação Bluetooth?
4.1 Arquitetura Geral do Sistema
O Sistema XXX utilizará as funcionalidades de um dispositivo móvel para realizar a
conexão com o dispositivo ELM 327 – Interface Bluetooth o qual servirá de intermediário
para obtenção de informações do Sistema Computacional Embarcado do veículo que utiliza o
Sistema OBD-II.
Realizada a conexão o Sistema apresentará as seguintes funcionalidades que serão
obtidas referentes ao dispositivo ELM 327 (E) ou do Sistema OBD-II (O):

Apresentar a versão do dispositivo ELM 327 (E);

Apresentar o protocolo de comunicação existente no veículo (E);

Informar se existe falha registrada (lâmpada MIL acionada) (O);

Informar se existiu e quais falhas foram registradas (DTCs) (O);

Informar condições gerais do veículo tais como velocidade, rotações por
minuto, temperatura da água do radiador, aceleração, temperatura de entrada
de ar no sistema de arrefecimento, etc. (O);

Informar se está disponível a identificação do veículo e seu VIN (O).
4.2 Do desenvolvimento do Sistema
Inicialmente definido e instalado nas máquinas estações de trabalho os seguintes
softwares recomendados:

Maquina virtual JAVA versão 1.6.0_37;

Eclipse JUNO versão 4.2.0;

SDK Android Revisão 20.0.1;

Plugin ADT 20.0.3.
O SDK do Android separa ferramentas, componentes e APIs em pacotes (Packages) e
estes podem ser escolhidos para download conforme a faixa de versão que deseja-se
implementar (Ilustração 7).
Ilustração 7 - Instalação dos Pacotes através do SDK Android Manager
Fonte: Elaborado pelos Autores
Instalados os softwares que nos permitem a programação para dispositivos móveis
baseados em Android definimos um Android Virtual Device (AVD). Um AVD é um
emulador de características de smartphone, para que possamos testar nosso Sistema em versão
específica ou grupos de versões do Android. Foi definido que o emulador AVD seria
compatível a smartphones que suportassem as versões 2.2 até 4.1. Tal escolha gera
compatibilidade do Sistema desenvolvido a todos os aparelhos desta faixa de versões.
Após os primeiros testes com as funções de Bluetooth da aplicação, percebeu-se que o
aplicativo quando instalado no emulador não executava a aplicação. Todas as vezes que o
aplicativo solicitava ao emulador a verificação da existência de um adaptador Bluetooth
presente, o aplicativo fechava e exibia um erro. Consultada a documentação oficial do
Android descobriu-se que o emulador não tem capacidade de lidar com algumas funções,
dentre elas o Bluetooth.
O ADB é uma ferramenta em linha de comando que faz a comunicação (uma ponte)
entre a plataforma de desenvolvimento e o emulador ou um dispositivo conectado através
deste modo. Consiste em um programa cliente-servidor que inclui três componentes:
 Um cliente, que instala e executa a aplicação no dispositivo, seja ele um
emulador ou um dispositivo Android real;
 Um servidor, que cria um processo em plano de fundo na máquina;
Um daemon11, que também roda um processo de fundo, controlando o acesso de
portas necessárias para a execução do ADB em dispositivos físicos.Foi utilizada na grande
maioria dos testes, através do ADB um aparelho Samsung Galaxy Tab modelo GT-P1010
rodando uma versão modificada do Android 2.3.3 chamada Cyanogen 7.2.
Testes foram efetuados também em aparelhos de outras marcas, tais como Motorola,
LG e Sony-Ericsson, englobando versões desde a 2.2 até a mais recente, 4.1.
Optou-se por desenvolver a aplicação compatível com esta faixa de mercado e
baseando o desenvolvimento na 2.3.3 por esta ser a maior parcela ativa no mercado segundo
11
Daemon: acrônimo de Disk And Execution MONitor (Monitor de Execução e de Disco), é um programa
de computador que roda de forma independente em background, ao invés de ser controlado diretamente por um
usuário.
página informativa sobre dispositivos em uso no site Android Developer (ANDROID)
conforme visto na Ilustração 8.
A soma das parcelas de todas as versões compatíveis com nossa aplicação chega a
96,5% segundo esta pesquisa.
Ilustração 8 - Distribuição atual das versões da Plataforma Android
Fonte: http://developer.android.com/about/dashboards/index.html
4.2.1 Da Conexão BLUETOOTH
No site oficial da plataforma Android, mais especificamente no tópico APIs
Bluetooth utilizadas por desenvolvedores, é descrito que utilizando as APIs Bluetooth uma
aplicação Android pode, entre outras funcionalidades, executar:

Consultar se existe adaptador Bluetooth no dispositivo onde a aplicação
está funcionando;

Verificar se existem outros dispositivos Bluetooth acessíveis;

Conectar a outros dispositivos que foram descobertos;

Transferir dados para e de outros dispositivos.
Todas as APIs Bluetooth encontram-se disponíveis no pacote android.bluetooth
sendo que na aplicação utilizou-se as classes:

BluetoothAdapter – Classe que permite executar tarefas fundamentais no
Bluetooth, como localizar o adaptador Bluetooth e identificar seu MAC
Address, iniciar a descoberta de dispositivos disponíveis para conexão,
consultar lista de
aparelhos já conectados (emparelhados) e instanciar um
BluetoothDevice usando o MAC Address obtido;

BluetoothDevice – Representa um dispositivo Bluetooth remoto. Esta classe é
um invólucro para o MAC Address sendo que as operações desta classe são
executadas utilizando o BluetoothAdapter que a criou;

BluetoothServerSocket – Classe responsável em criar um socket tipo servidor
de escuta. Quando a conexão é aceita a classe irá gerar um BluetoothSocket
para gerencia a conexão;

BluetoothSocket – Classe responsável em criar um socket que gerenciará a
conexão e o fluxo de entrada e saída dos dados.
Para utilização das classes descritas é necessário declarar as permissões Bluetooth no
manifesto do aplicativo conforme exemplo:
<manifest ...>
<uses-permission android:name=”android.permission.BLUETOOTH” />
...
</manifest>
Com as classes descritas o Sistema irá realizar a sequência de tarefas mostrada na
Ilustração 9.
Ilustração 9 - Fluxograma da conexão Bluetooth
Iniciar Conexão
Existe
adaptador
Bluetooth?
N
Encerrar Aplicativo
S
N
Bluetooth
ligado?
Ligar
Bluetooth.
S
Verificar
dispositivo.
N
ELM 327
visível?
S
Solicitar
conexão.
N
Conexão
aceita?
S
Fonte: Elaborado
pelos Autores
Iniciar solicitações
de Comandos.
Nas classes desenvolvidas para o Sistema utilizando as Classes Bluetooth descritas
utilizou-se como base os exemplos de programação disponíveis no Android Developers –
Guia de APIs – Bluetooth (ANDROID).
4.2.2 Das funcionalidades
Realizada a conexão passou-se a analisar os dados obtidos através da conexão.
Inicialmente foram necessárias correções no Sistema para que a comunicação com o ELM
327 fosse aceita e retornasse dados legíveis. Como era recebido de retorno para qualquer
solicitação efetuada através da conexão Bluetooth caracteres estranhos (símbolos e letras de
outros alfabetos) foi efetuado nova consulta à documentação do ELM 327.
Em tal
documentação (ELM ELECTRONICS, p.5) verificou-se que era necessário definir a
comunicação para 8 bits. A informação levou a depuração da classe de conexão e foi
localizado um método que utilizava como um dos parâmetros o Formato de Transformação
Unicode12 de 16 bits (UTF-16) na conversão dos dados transmitidos em bytes do dispositivo
ELM 327 para uma string.
Realizada a alteração para UTF-8, default no Android, o aplicativo-teste passou a
receber caracteres corretos, porém o ELM 327 informava que não entendia a solicitação
retornando (‘?’).
Tal erro foi facilmente corrigido, pois em sua documentação (ELM
ELECTRONICS, p.5) informava que toda solicitação efetuada deveria ser finalizada com um
caractere de retorno de carro, isto é, hexadecimal ‘0D’ ou ‘\r’, ou seria entendido pelo
dispositivo que a informação solicitada está incompleta. Realizado o acréscimo da string ‘\r’
ao conjunto de dados a serem transmitidos ao ELM 327 passou-se a receber as informações
corretas do OBD-II.
Com o Sistema desenvolvido enviando e recebendo dados legíveis passou-se a testar
os grupos de comandos suportados pelo dispositivo ELM 327 – Interface Bluetooth utilizando
linhas de comando para enviar e receber dados não tratados. O dispositivo suporta comandos
internos, que são iniciados pelos caracteres ‘AT’, e comandos OBD relacionados na ISO
15031-5:2006 sendo que o dispositivo somente aceita comando OBD que contenham os
códigos ASCII para dígitos hexadecimais (‘0’ a ‘9’ e ‘A’ a ‘F’) .
Com referência aos Comandos AT testou-se e obtive-se êxito na obtenção da
informação dos seguintes comandos:

AT Z – Executa uma redefinição completa do dispositivo, retornando as
configurações do dispositivo aos valores padrões ;
12
Unicode: é um padrão que permite aos computadores representar e manipular, de forma consistente,
texto de qualquer sistema de escrita existente.

AT DP – Informa o Protocolo de comunicação que esta sendo utilizado. O
dispositivo detecta automaticamente o Protocolo OBD, mas não relata.
Utiliza-se este comando para saber que Protocolo esta sendo utilizado e se
o protocolo foi escolhido automaticamente informa a palavra ‘AUTO’
antes do Protocolo;

AT RV – Informa a tensão em volts.
Com referência aos Comandos OBD testou-se e obtive-se êxito nos Comandos
relacionados aos serviços:
Service $01 – Request current powertrain diagnostic data:
PID $01: Números de relatos DTC e status da MIL;
PID $21: Distância percorrida desde o acionamento da MIL.
Service $03 – Request emission-related diagnostic trouble codes: completo.
Service $04 – Clear/reset emission-related diagnostic information: completo.
Service $09 – Request vehicle information:
PID $01: Número de mensagens para reportar o VIN.
PID $02: VIN (Vehicle Identification Number).
PID $03: Número de mensagens para reportar o CALID.
PID $04: CALID – Calibration Identifications.
4.3 Da Aplicação Android
Esta seção consiste na descrição da aplicação Android desenvolvida, sendo explicadas
suas telas, seu modo de funcionamento e, quando houver, as conversões e adequações dos
dados recebidos do OBD-II para visualização final.
O aplicativo exibirá uma tela inicial, informando ao usuário sobre como proceder e a
necessidade de um adaptador bluetooth compatível com o sistema OBD. Durante as pesquisas
percebeu-se que esse é um dos muitos pontos em que usuários qualificam o aplicativo
negativamente na loja de aplicativos do Android por terem informações suficientes sobre o
funcionamento do OBD.
Nesta tela inicial ainda haverá um botão que fará a verificação do Bluetooth: se existe;
caso exista, se está ativado; e se estiver ativado se está disponível ou em uso.
Ao pressionar o botão de menu do dispositivo, o usuário poderá escolher entre as telas
de linha de comando ou gráfica.
Na tela de linha de comandos (Ilustração 10), o usuário poderá digitar o código OBD
ou AT, obtendo respostas diretamente do Adaptador ou da DCU, sem nenhum tipo de
tratamento, ou seja, para, por exemplo, mostrar a RPM do motor, o usuário deverá digitar
010C, recebendo a resposta 41 0C 0B E4. Ao converter os dados em Hexa para Decimal, o
usuário irá obter o valor de 3044, que, dividido por 4, resultará em 761 RPM.
Ilustração 10 - Tela de linha de comando
Fonte: Elaborado pelos Autores
Na Ilustração 11 são mostrados os Comandos AT sendo utilizados. Com a solicitação
AT Z o dispositivo resetou e informou sua versão – ELM327 v1.4. O Comando AT RV
retornou a voltagem da bateria e o Comando AT DP informou o Protocolo de comunicação
do veículo – ISO 14230-4(KWP FAST).
Ilustração 11 - Tela com linhas de Comando AT
Fonte: Elaborado pelos Autores
Na tela de modo gráfico o usuário terá a disposição vários botões do tipo Toogle, que
são botões que têm um funcionamento parecido com o de Liga/desliga. Na Ilustração 12 o
botão RPM encontra-se ligado e a informação das rotações por minutos (RPM) desta
disponível.
Ilustração 12 - Tela de Comandos no modo gráfico
Fonte: Elaborado pelos Autores
Enquanto um dos botões estiver ativado, todos os outros estarão desativados e as
informações que constantemente estão sendo atualizadas serão mostradas em tempo real, com
um laço de repetição repetindo o comando, recebendo a resposta e mostrando na tela o
resultado. Informações como VIN, erros na MIL que não necessitam de atualização, apenas
serão mostradas uma vez na tela.
 CONSIDERAÇÕES FINAIS
O desenvolvimento do Aplicativo, tanto nos parte de linha de comando como na tela
gráfica, atendeu nosso objetivo inicial de integrar um dispositivo móvel ao sistema de
diagnóstico veicular OBD-II. O objetivo secundário de efetuar testes com simulação de
defeitos não pode ser realizado por ausência de veículos para tais testes. Quanto à
identificação veicular podemos constatar que veículos fabricados depois de janeiro de 2011
possuem a numeração VIN gravado em seu Sistema embarcado. Este Trabalho de Conclusão
de Curso será base para trabalhos futuros de Perícia Computacional Forense na área veicular
visaram identificar quais veículos de anos anteriores a 2011 possuem identificação
embarcada; efetuando a análise da possibilidade de adulteração dos dados identificadores e
caso positivo sua recuperação. Estudos sobre a coleta de dados em veículos apresentando
códigos de DTC relacionados à poluição, a precisão13 e acurácia14 de tais dados coletados em
Sistema Android baseado neste Trabalho também fazem parte de futuros trabalhos para
habilitar seu uso como auxiliar do Programa de Controle de Poluição do Ar por Veículos
Automotores (BRASIL, 2011).
“O termo precisão relaciona-se com a variação do valor, medido repetidamente sob mesmas
condições experimentais, em torno de um valor médio observado.” (CAPPELLI et al., 2006, p.65).
14
“[...] o termo acurácia refere-se à exatidão da medida, ou seja, refere-se a quão próximo está o
valor medido do valor real.” (Ibid., p.65).
13
REFERÊNCIAS BIBLIOGRÁFICAS
ANDROID: Developer Announcements. Disponível em: <http://www.android.com/>. Acesso
em: 21 mar. 2012.
ANFAVEA - ASSOCIAÇÃO NACIONAL DOS FABRICANTES DE VEÍCULOS
AUTOMOTORES (Brasil) (Org.). Estatísticas: Dados relativos à produção de Autoveículos.
Disponível em: <http://www.anfavea.com.br/tabelas.html>. Acesso em: 21 mar. 2012.
BRASIL. Conselho Nacional do Meio Ambiente - CONAMA. Ministério do Meio Ambiente
(Org.). RESOLUÇÃO Nº 354, DE 13 DE DEZEMBRO DE 2004. Disponível em:
<http://www.ibama.gov.br/phocadownload/category/4?download=4792%3Amanualportugues>. Acesso em: 13 jul. 2012.
BRASIL. Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais Renováveis –
Ibama. Ministério do Meio Ambiente (Org.). INSTRUÇÃO NORMATIVA IBAMA nº
24/2009. Disponível
em:
<http://www.ibama.gov.br/phocadownload/category/4?
download=4792%3Amanual-portugues>. Acesso em: 13 jul. 2012.
BRASIL. Instituto Brasileiro do Meio Ambiente e dos Recursos Naturais Renováveis –
Ibama. Ministério do Meio Ambiente (Org.). INSTRUÇÃO NORMATIVA IBAMA nº
126/2006. Disponível
em:
<http://www.ibama.gov.br/phocadownload/category/4?
download=4792%3Amanual-portugues>. Acesso em: 13 jul. 2012.
BRASIL. Instituto Brasileiro do Meio Ambiente e Dos Recursos Naturais Renováveis Ibama. Ministério do Meio Ambiente (Org.). Programa de controle da poluição do ar por
veículos automotores: Proconve/Promot. 3. ed. Brasília: Ibama, 2011. 584 p. (Série
Diretrizes - Gestão Ambiental). Coleção Meio Ambiente. Disponível em:
<http://www.ibama.gov.br/phocadownload/category/4?download=4792%3Amanualportugues>. Acesso em: 12 jun. 2012.
B&B ELETRONIC MANUFECTURING COMPANY (EUA) (Org.). OBDII STREAMER
FAMILY: Commnad and Response Document. Ottawa, Il, 2012. 61 p. (V 2.07).
CANALYS (Eua) (Org.). Smart phones overtake client PCs in 2011. Disponível em:
<http://www.canalys.com/newsroom/smart-phones-overtake-client-pcs-2011#>. Acesso em:
23 mar. 2012.
CAPPELLI, Nelson Luis et al. Desempenho Comparativo entre Receptores GPS. Revista
Brasileira De Agroinformática, São Paulo, v. 1, n. 8, p.63-77, 2006. Semestral.
ELM ELECTRONICS (Canadá). ELM327: OBD to RS232 Interpreter. Disponível em:
<www.elmelectronics.com>. Acesso em: 13 jul. 2012.
GARTNER INC. (Eua) (Org.). Gartner Says Android to Command Nearly Half of
Worldwide Smartphone Operating System Market by Year-End 2012. Disponível em:
<http://www.gartner.com/it/page.jsp?id=1622614>. Acesso em: 23 mar. 2012.
GUIMARÃES, Alexandre de Almeida. Eletrônica Embarcada Automotiva. 1ª Edição São
Paulo: Editora Érica, 2011. 328 p.
ISO - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (Org.). Technical
Committee ISO/TC 22 - Road Vehicles / Subcommittee SC 3 - Electrical And Electronic
Equipment. (Comp.). ISO 9141: Road vehicles -- Diagnostic systems -- Requirements for
interchange of digital information. Switzerland, 1998. 3 v.
ISO - INTERNATIONAL ORGANIZATION FOR STANDARDIZATION (Org.). Technical
Committee ISO/TC 22 - Road Vehicles / Subcommittee SC 3 - Electrical And Electronic
Equipment. (Comp.). ISO 15031: Road vehicles — Communication between vehicle and
external equipment for emissions-related diagnostics. Switzerland, 2006. 7 v.
NOLTE, Thomas; HANSSON, Hans; LO BELLO, Lucia. Automotive Communications Past, Current and Future. Conference On Emerging Technologies And Factory
Automation, Catania - It., v. 1, pp. 985-992, 2005.
OICA
ORGANISATION
INTERNATIONALE
DES
CONSTRUCTEURS
D'AUTOMOBILES (Paris) (Org.). 2011 PRODUCTION STATISTICS. Disponível em:
<http://oica.net/category/production-statistics/>. Acesso em: 21 mar. 2012.
SANTOS, Max Mauro Dias. Redes de Comunicação Automotivas. 1ª edição São Paulo:
Editora Érica, 2010. 220 p.
TANENBAUM, Andrew S.. Sistemas Operacionais Modernos. 3ª Edição São Paulo:
Pearson Prentice Hall, 2009. 654 p.
THOMPSON, Timothy J.; KLINE, Paul J.; KUMAR, C Bala. Bluetooth Application
programming with Java APIs: Essentials Edition. Usa: Morgan Kauffmann Publishers,
2008. 286 p.
ANEXOS
Figura 1: informação ao usuario sobre as
Permissões à serem utilizadas.
Figura 2: Aplicativo instalado.
Figura 3: Tela inicial do aplicativo. Ao pressionar o botão de menu do aparelho o usario verá as opções
conforme figura 4.
Figura 4: Opções disponiveis ao usuario. O botão conecte a um dispositivo mostra ao usuario dispositivos
já pareados, conforme figura 5. O botão fazer a descoberta realiza todo o procedimento de parear um
novo dispositivo, conforme figura 6.
Figura 5: Solicitação de permissão para ativar a descoberta de novos dispositivos.
Figura 6: Pedido de permissão para ativar o Bluetooth, caso esteja desativado. Caso o bluetooth esteja
ativado, o dispositivo mostrará a tela 8.
Figura 6:Bluetooth sendo ativado.
Figura 7: Tela de seleção de dispositivos já pareados.
Figura 8:Dispositivo conectado ao OBD-II.
Figura 9:Comandos do leitor OBD-II Elm 327. O comando AT Z mostra a versão de software do
aparelho, o comando AT RV a voltagem da bateria do automóvel e o comando AT DP mostra o protocolo
usado pelo módulo do vepiculo.
Figura 10: Comandos OBD-II. O comando 01 0C solicita o numero de rotações por minuto (rpm). A
resposta é enviada confirmando a solicitação (41 0C) e a rpm aumentada em 4vezes (hexadecimal).
Figura 11:Comandos OBD-II. O comando 09 01 retorna a quantidade de linhas em que o VIN será
enviado ao solicitar o comando 09 02. No veículo testado o VIN não estava disponível.
Figura 12: O comando 01 01 monitora se houve mudança no status de algum dos DTC's desde que foi
resetado. O comando 03 retorna erros na DTC com acendimento da MIL e o comando 07 mostra erros em
que não foi necessario o acendimento da MIL.
Figura 13: O comando 01 05 mostra a temperatura do sistema de arrefecimento (radiador). A resposta 7D
é convertida da base hexadecimal para a base decimal e subtraido 20. O resultado é informado em graus
Celsius.