Decodificador de Dados Usando Protocolo CAN Padrao SAE J1939 PDF

1
UNIVERSIDADE DE PASSO FUNDO
Emanuel Nunes Baldissera
DECODIFICADOR DE DADOS USANDO PROTOCOLO

CAN – PADRÃO SAE J1939
Passo Fundo
2011
2
DECODIFICADOR DE DADOS USANDO PROTOCOLO

CAN – PADRÃO SAE J1939
Projeto de Graduação apresentado ao curso de

Engenharia Elétrica, com Ênfase em Eletrônica -
Telecomunicações, da Faculdade de Engenharia e
Arquitetura, da Universidade de Passo Fundo, como
requisito parcial para obtenção do grau de Engenheiro
Eletricista sob a orientação do prof. Dr. Eduardo Appel.
Passo Fundo
2011
3
DECODIFICADOR DE DADOS USANDO PROTOCOLO CAN – PADRÃO SAE J1939
Projeto de Graduação apresentado ao curso de

Engenharia Elétrica, com Ênfase em Eletrônica -
Telecomunicações, da Faculdade de Engenharia e
Arquitetura, da Universidade de Passo Fundo, como
requisito parcial para obtenção do grau de Engenheiro
Eletricista sob a orientação do prof. Dr. Eduardo Appel.
Aprovado em ___ de ________________ de ________.
BANCA EXAMINADORA
_____________________________________
Prof. Dr. Eduardo Appel.
_____________________________________
Prof. Dr. Carlos Allan Caballero Petersen
_____________________________________
Prof. Dr. Paulo Sergio Correa Molina
4
Dedico este trabalho a quem possa encontrar nestas

páginas qualquer auxílio, esclarecimento ou direção
rumo ao desenvolvimento de soluções baseadas no
Protocolo CAN.
5
Agradeço a Deus e a minha família em primeiro lugar.

Especialmente às figuras mais importantes de minha
vida, responsáveis por me tornarem aquilo que sou :Pai
e Mãe. Pelo suporte e companhia durante os últimos
anos, agradeço a minha noiva Itamara. Agradeço à Cielo
Indústria Mecatrônica, em especial ao Sr. Círio Kolberg e
ao Eng. Eletr. Emiliano Ferreira por todo o suporte e
assistência prestados no decorrer deste projeto.
Agradeço também ao prof. Dr. Eduardo Appel, pela sua
orientação e confiança em mim depositada. E por fim,
agradeço a minha pátria pela atual política de
viabilização de acesso ao Ensino Superior.
6
“Yes, we CAN!”
(Slogan de campanha do presidente norte-americano

Barack Obama - 2008).
7
RESUMO
Os sistemas de rastreamento de veículos disponibilizados comercialmente no Brasil,

atualmente, necessitam oferecer a seus clientes um arranjo de dados que vai além de informações
básicas como seu posicionamento geográfico e abertura ou fechamento de portas. Empresas com
sistemas de gerenciamento de frota mais desenvolvidos requerem, dos fabricantes de rastreadores,
sistemas avançados que possibilitem a aquisição de uma variedade de dados cada vez maior.
No cenário nacional, a grande parte dos rastreadores comercializados ainda é acompanhada

por sensores e equipamentos de medição individuais para aquisição de leituras de parâmetros como
velocímetro, odômetro e giros do motor. O uso destes dispositivos traz consigo uma série de fatores
negativos como, por exemplo, o aumento da complexidade e tamanho do cabeamento, custos com
manutenção, necessidade de calibração e erros de medição, entre outros.
Em 2002, seis dos maiores fabricantes europeus de veículos pesados acordaram em

disponibilizar diversas informações de bordo a terceiros através da chamada Interface FMS. Esta
interface possibilita a leitura de uma série de dados codificados conforme especificações do Padrão
SAE J1939 o qual, por sua vez, roda sobre o Protocolo CAN 2.0B.
A fim de aproveitar a tecnologia embarcada ao veículo, este projeto trata do desenvolvimento

e construção de um protótipo capaz de ser conectado à Interface FMS. O dispositivo, então, efetua a
leitura e realiza a decodificação de até vinte parâmetros de bordo do veículo. Os parâmetros lidos são
disponibilizados ao rastreador e este, por fim, faz a transmissão dos dados recebidos à central de
monitoramento.
A solução projetada neste trabalho compreende dois dispositivos dotados de hardware e

software formando uma espécie de “kit de desenvolvimento SAE J1939”. Um dispositivo é
responsável por simular os sinais existentes no barramento CAN de um veículo comercial enquanto o
outro dispositivo compreende o próprio decodificador de dados, em conformidade com as
especificações da Cielo Indústria Mecatrônica Ltda.
Palavras-Chave: Decodificador, Rastreador, Protocolo CAN, SAE J1939, Interface FMS.

8
SUMÁRIO
1.0 INTRODUÇÃO ................................................................................................................................ 14
2.0 SISTEMAS DE MONITORAMENTO E SEGURANÇA VEICULAR ................................................ 15
3.0 MÓDULOS ELETRÔNICOS ........................................................................................................... 17
3.1 Comunicação entre as ECUs ...................................................................................................... 17
3.2 Rastreadores comerciais ............................................................................................................. 17
3.2 Atualização remota ...................................................................................................................... 18
4.0 REDES DE DADOS ........................................................................................................................ 19
4.1 Topologias de Redes de Dados .................................................................................................. 19
4.2 Modelo OSI para Protocolos de Comunicação ........................................................................... 20
4.3 Protocolo de Comunicação de Dados ......................................................................................... 21
4.4 Uso de Protocolos em Redes Automotivas ................................................................................. 22
5.0 CONTROLLER AREA NETWORK (CAN) ...................................................................................... 23
5.1 Conceituação básica ................................................................................................................... 24
5.1.1 Características Físicas .......................................................................................................... 24
5.1.2 Características lógicas .......................................................................................................... 26
5.1.2.1 Formato das mensagens ................................................................................................ 26
5.1.2.2 Arbitração ....................................................................................................................... 27
5.1.3 Padrões Existentes ............................................................................................................... 28
6.0 PADRÃO SAE J1939 ...................................................................................................................... 29
6.1 Grupos de Parâmetros (PG) ........................................................................................................ 29
6.1 Formato das Mensagens ............................................................................................................. 29
6.2 Campo de Dados ......................................................................................................................... 31
6.3 FMS (Fleet Management System) Standard ............................................................................... 32
7.0 PROJETO DO DECODIFICADOR DE DADOS .............................................................................. 34
7.1 Especificações do Projeto ........................................................................................................... 34
7.2 Componentes de Hardware ......................................................................................................... 35
7.2.1 Composição do Nó TX .......................................................................................................... 35
7.2.2 Composição do Nó RX ......................................................................................................... 36
7.2.3 Displays LCD e botões de comando..................................................................................... 36

9
7.2.4 Simuladores de Acionamentos e Medição da Temperatura ................................................. 37
7.2.5 Interface de Comunicação Serial .......................................................................................... 37
7.2.6 Interface CAN ........................................................................................................................ 37
7.2.6.1 Controlador MCP 2510 ................................................................................................... 38
7.2.6.2 Controlador MCP 2515 ................................................................................................... 38
7.2.6.3 Transceptor MCP 2551 .................................................................................................. 38
7.2.6.4 Escolha da Interface CAN .............................................................................................. 38
7.2.7 Microcontroladores................................................................................................................ 39
7.2.7.1 Microcontrolador AT91SAM7A3-AU.............................................................................. 39
7.2.7.2 Microcontrolador DsPic33FJ64GP804 ........................................................................... 39
7.2.7.3 Microcontrolador PIC18F2580 ....................................................................................... 40
7.2.7.4 Escolha do Microcontrolador .......................................................................................... 40
7.2.8 Memória I²C .......................................................................................................................... 40
7.2.9 Fonte de Alimentação ........................................................................................................... 41
7.2.10 Esquemático de Hardware .................................................................................................. 41
7.2.11 DESENVOLVIMENTO DO FIRMWARE ............................................................................. 44
7.2.11.1 NÓ TX ........................................................................................................................... 44
7.2.11.2 NÓ RX .......................................................................................................................... 47
8.0 TESTES E RESULTADOS.............................................................................................................. 50
8.1 Teste de comunicação entre os nós TX e RX ............................................................................. 50
8.2 Teste de comunicação entre o nó TX e o módulo Teltonika FM4200 ......................................... 50
8.3 Teste de comunicação entre o nó RX e veículos comerciais ...................................................... 51
CONSIDERAÇÕES ............................................................................................................................... 52
REFERÊNCIAS ..................................................................................................................................... 53
APÊNDICE A – MANUAIS DE OPERAÇÃO ......................................................................................... 55
ANEXO A – Lista de Materiais do Circuito Elétrico ............................................................................... 60
ANEXO B – Descrição da Interface FMS em conformidade com SAE J1939 ...................................... 62

10
LISTA DE FIGURAS
Figura 1 – Esquema genérico de um rastreador comercial .................................................................. 18

Figura 2 – Comparativo entre uma rede sem CAN e uma rede com CAN ........................................... 23
Figura 3 – Mensagem transmitida via barramento CAN ....................................................................... 24
Figura 4 – Relação entre comprimento da rede e taxa de transmissão ............................................... 25
Figura 5 – CAN - Barramento diferencial .............................................................................................. 25
Figura 6 – Comparativo entre os formatos CAN 2.0A e CAN 2.0B ...................................................... 26
Figura 7 – Arbitração CAN .................................................................................................................... 28
Figura 8 – Formato de Mensagem do J1939 ........................................................................................ 30
Figura 9 – Divisão entre PGN Global e PGN Específico ...................................................................... 31
Figura 10 – Contextualização do Projeto .............................................................................................. 34
Figura 11 – Diagrama do kit de desenvolvimento ................................................................................. 35
Figura 12 – Esquema genérico de hardware do Nó TX ........................................................................ 35
Figura 13 – Esquema genérico de hardware do Nó RX ....................................................................... 36
Figura 14 – Circuito da Fonte de Alimentação ...................................................................................... 41
Figura 15 – Esquemático de Hardware para o Nó TX .......................................................................... 42
Figura 16 – Esquemático de Hardware para o Nó RX .......................................................................... 43
Figura 17 – Fluxograma do Firmware do Nó TX (Parte 1 de 3) ............................................................ 44
Figura 20 – Fluxograma do Firmware do Nó RX (Parte 1 de 3) ........................................................... 47
Figura 23 – Protótipos TX (esquerda) e RX (direita)............................................................................. 50
11
LISTA DE TABELAS
Tabela 1 – Descrição das topologias de rede ....................................................................................... 19

Tabela 2 – Modelo de Referência OSI .................................................................................................. 20
Tabela 3 – Alguns protocolos de comunicação Classe B ..................................................................... 22
Tabela 4 – Leituras efetuadas em veículos comerciais ........................................................................ 51
12
LISTA DE ABREVIATURAS E SIGLAS E UNIDADES
Abreviatura
Sigla ou Significado Literal Significado Traduzido
Unidade
°C Graus Celsius -
A Ampère -
ABS Anti-lock Braking System Sistema de frenagem anti-travante
ACK Acknowledgement Reconhecimento
AG Aktiengesellschaft Sociedade de ações
American Standard Code for Information Código Padrão Americano para o
ASCII
Interchange Intercâmbio de Informações
Bit Binary digit Dígito binário
CA Controller Application Aplicação controladora
CAN Controller Area Network Controlador de rede de área
CRC Cyclic redundancy check Verificação Cíclica de Redundância
DAF Van Doorne’s Automobiel Fabriek -
DIN Deutsche Institut für Normung Instituto Alemão para Normatização
DLC Data Length Code Código de Comprimento de Dado
ECM Engine Control Module Módulo de Controle do Motor
ECU Electronic Control Unit Unidade de Controle Eletrônico
EIA Electronic Industries Alliance Aliança das Indústrias Eletrônicas
EOF End of Frame Fim de Quadro
FMS Fleet Management System Sistema de Gerenciamento de Frota
GE Group Extension Extensão de Grupo
GM General Motors -
GmbH Gesellschaft mit beschränkter Haftung Sociedade de Responsabilidade Limitada
H Hora -
I/O Input/Output Entrada/Saída
I²C Inter Integrated Circuits Circuitos interintegrados
ID Identificator Identificador
IDE Identifier Extension Identificador de Extensão
IFS Inter-Frame Space Espaço entre quadros
ISSO International Standards Organization Organização Internacional de Padrões
IVECO Industrial Vehicles Corporation Corporação de Veículos Industriais
Kbps Kilobits per second Kilobits por Segundo
Km Quilômetro -
L Litro -
13
LCD Liquid Crystal Display Tela de Cristal Líquido

LFE Liquid Fuel Economy Economia Líquida de Combustível
M Metro -
MAN Maschinenfabrik Augsburg-Nürnberg -
Mbps Megabits per second Megabits por Segundo
MT Multitimer Múltiplos Temporizadores
Associação Nacional de Eletrônica da
NMEA National Marine Electronics Association
Marinha
NRZ Non-Return to Zero Não retorna a zero
OSI Open Systems Interconnection Interconexão de Sistemas Abertos
PDU Protocol Data Unit Unidade de Protocolo de Dado
PG Parameter Group Parâmetro de Grupo
PGN Parameter Group Number Número de Parâmetro de Grupo
PWM Pulse-Width Modulation Modulação por Largura de Pulso
RPM Rotations per Minute Rotações por Minuto
RTR Remote Transmission Request Requisição de Transmissão Remota
SAE Society of Automotive Engineers Sociedade de Engenheiros Automotivos
SPI Serial Peripherical Interface Interface Periférica Serial
SPN Suspect Parameter Number Número de Parâmetro Suspeito
SRR Substitute Remote Request Substituto de Requisição Remota
TTL Transistor-Transistor Logic Lógica Transistor-Transistor
V Volt -
VPW Variable Pulse Width Largura de Pulso Variável
14
1.0 INTRODUÇÃO
Um sistema de rastreamento e monitoramento veicular básico, usualmente, é constituído

por um dispositivo que periodicamente envia a posição geográfica e alguns eventos, como abertura e
fechamento de portas a uma central de monitoramento. Geralmente estes sistemas também incluem
a opção de bloqueio do veículo sob determinadas condições. Todavia empresas com sistemas de
gerenciamento de frotas desenvolvidos requerem, dos fabricantes de rastreadores, dispositivos
avançados que possibilitem a aquisição de uma gama de dados cada vez mais ampla em um
intervalo de tempo cada vez menor.
Embora praticamente todos os ônibus e caminhões fabricados na atualidade, já possuam

quase todos os parâmetros de rodagem adquiridos de forma eletrônica ocorre que a grande parte dos
rastreadores comercializados no país ainda é acompanhada por sensores e equipamentos de
medição individuais para aquisição de leituras de parâmetros como velocímetro, odômetro, e giros do
motor. O uso destes equipamentos traz consigo uma série de fatores negativos como, por exemplo, o
aumento da complexidade e tamanho do cabeamento, custos com manutenção, necessidade de
calibração e erros de medição, entre outros. Tomando por exemplo o caso do odômetro, tem-se que
atualmente, se um caminhoneiro fizer uma viagem de Passo Fundo, no Rio Grande do Sul a
Fortaleza, no Ceará, ao longo dos 3.890 km que separam estas duas cidades um sistema individual
de medição pode apresentar uma diferença média de até 4% com relação à leitura do odômetro
informada pelo caminhão.
Em 2002, seis dos maiores fabricantes europeus de veículos pesados acordaram em

disponibilizar diversas informações de bordo a terceiros através da chamada Interface FMS. Esta
interface possibilita a leitura de uma série de dados codificados conforme especificações do Padrão
SAE J1939 o qual, por sua vez, roda sobre o Protocolo CAN 2.0B. Visando minimizar a quantidade de
sensores e instrumentos individuais bem como aproveitar melhor a tecnologia embarcada
disponibilizada pelo fabricante, este projeto descreve o desenvolvimento e implementação de um
protótipo composto de hardware e software capaz de interpretar os dados presentes no barramento
CAN de veículos pesados (ônibus e caminhões), decodificá-los e transmitir suas leituras diretamente
ao dispositivo responsável pelo rastreamento através de comunicação serial.
Em linhas gerais, constitui-se como objetivo deste projeto a redução de custos na construção
e manutenção de um aparelho rastreador, através da redução da necessidade de utilização de
dispositivos à parte para leitura de parâmetros. De igual modo o projeto visa proporcionar total
correspondência entre os dados recebidos pela central de monitoramento com o que é mostrado no
painel do veículo, uma vez que ambas as informações possuirão a mesma origem: os recursos
embarcados no veículo.
Em seus primeiros capítulos, este trabalho apresentará conceitos teóricos básicos sobre
dispositivos de rastreamento e monitoramento, eletrônica automotiva, redes de dados e os Protocolos
CAN e SAE J1939, necessários ao correto entendimento do projeto. Posteriormente serão
apresentados os critérios de projeto, bem como seu desenvolvimento e testes realizados. Finalmente
serão apresentados os resultados definitivos e considerações.
15
2.0 SISTEMAS DE MONITORAMENTO E SEGURANÇA VEICULAR
Um sistema sofisticado de gerenciamento de frotas veiculares é um sistema que possibilita a

coleta de uma vasta gama de dados de um veículo, como por exemplo, sua localização geográfica
exata, assim como o acionamento de travas e dispositivos de segurança [11]. No Brasil, os sistemas
de monitoramento de frotas começaram a ser implantados na década de 90 e, na ocasião, estes
sistemas possuíam um custo consideravelmente elevado visto que todas as transmissões eram feitas
exclusivamente por satélite [12].
A partir de 2003, quando o celular e a internet banda larga se tornaram mais acessíveis
verificou-se uma crescente demanda neste nicho de mercado. Para se ter uma idéia do crescimento,
hoje conta-se com cerca de 20% da frota nacional monitorada, enquanto em 1998 esse número era
de apenas 1,2% [12].
Em um veículo, na prática, o sistema de rastreamento é constituído por um módulo eletrônico,

o qual coleta dados através de sensores e os transmite para a central de monitoramento [11]. É
importante salientar que a maioria dos rastreadores disponibilizados comercialmente no Brasil vale-se
de sensores próprios para efetuar medições.
A utilização de sensores próprios é, sem dúvida, um problema. Estes demandam um tempo

considerável para a instalação e calibração, exigem diversos tipos de conexões para alimentação e
comunicação, consomem mais energia e são passíveis de divergências com relação às leituras do
painel do veículo além dos custos relacionados à manutenção.
Usualmente um Sistema de Rastreamento comercial provê:
 Atualização da posição geográfica do veículo em curtos intervalos de tempo;

 Estado da ignição do veículo (ligada ou desligada);
 Indicação da abertura de portas e do baú;
 Alarme de botão de pânico acionado pelo motorista em caso de assalto;
 Possibilidade de envio e recepção de mensagens de texto para o motorista;
 Bloqueio de combustível e travamento das portas feito remotamente pela central;
(KOURI, 2007, Definição de Requisistos para um Sistema de
Monitoramento do Veículos no Transporte Rodoviário de Cargas, p. 32).
Sistemas mais avançados são capazes de prover à central uma gama de dados ainda maior,
as quais podem incluir:
 Controle de velocidade programável;

 Horímetro;
 Nível de combustível;
 Número de vezes em que o motorista tentou ultrapassar os limites pré-estabelecidos;
 Odômetro;
 Sensor de chuva;
 Sensor de movimento;
16
 Sensor de marcha;
 Situação do veículo (em movimento ou parado);
 Temperatura do motor;
 Giros do motor;
(CIELO INDÚSTRIA MECATRÔNICA, 2011)
A implementação de um sistema de gerenciamento de frotas é de relevante importância à

medida que este provê não apenas recursos de segurança, como o bloqueio do veículo agregado à
possibilidade de localização em caso de roubo, mas também uma série de informações acerca do
trajeto do veículo e daquele que o conduz.
Verifica-se que as empresas que adotam um sistema de rastreamento podem visualizar

quase que em tempo real o que acontece com cada um de seus veículos, de forma a aumentar a
segurança de seu patrimônio e a vigilância incidente sobre o mesmo. Este conjunto de informações
pode ter um papel decisivo permitindo tomadas de decisões com antecedência. Estratégias logísticas
podem ser mais bem elaboradas, com a clareza das rotas a serem traçadas, problemas de operação
podem ser detectados com antecedência e inclusive a qualidade de seus recursos humanos poderá
ter um perfil traçado alicerçado sobre dados reais.
17
3.0 MÓDULOS ELETRÔNICOS
De acordo com Guimarães (2007), os módulos eletrônicos nada mais são do que dispositivos
responsáveis pela leitura das entradas, acionamento de saídas e gerenciamento dos protocolos de
comunicação utilizados nos veículos. Estes são como um computador, dotados de uma estrutura de
hardware com um microprocessador ou microcontrolador e têm como tarefa a decisão de como
utilizar suas saídas em função do que está sendo lido nas entradas.
Módulos eletrônicos podem ter inúmeras aplicações, indo desde um controle MT (Multitimer)
responsável pelo controle de temporizações, como setas, limpador de pára-brisas, etc., até um
controle do tipo ECM (Engine Control Module) responsável pelo controle do próprio motor. Todos os
tipos de módulos eletrônicos podem ser denominados ECU (Electronic Control Unit) Unidade de
Controle Eletrônico [8].
3.1 Comunicação entre as ECUs
À medida que os veículos foram evoluindo, incorporaram novas tecnologias e o número de

dispositivos de bordo que passaram a ser controlados de forma eletrônica multiplicou-se
consideravelmente. Na atualidade, um carro de passageiros mediano, pode sair de fábrica contendo
cerca de trinta ECUs. Já um veículo top de linha pode ultrapassar a marca de duzentas ECUs
implementadas [26].
Em diversas ocasiões, uma ECU necessita comunicar-se com outra ECU. Um exemplo disso
é o painel, que constantemente necessita saber o estado dos mais variados periféricos do veículo
para informar ao condutor. Esta comunicação notoriamente mesmo em veículos mais antigos tem se
dado predominantemente de forma serial.
3.2 Rastreadores comerciais
A grande parte dos rastreadores comerciais, disponíveis no mercado, geralmente caracteriza-

se por possuir um módulo GPS, que periodicamente envia posições ao microcontrolador. Este, por
sua vez processa as informações recebidas e interage com a central de monitoramento através de
um módulo GSM ou GPRS, estando apto tanto a receber quanto enviar informações.
Contudo, equipamentos mais modernos vêm oferecendo opções de expansão e interação

com o usuário, como a presença de entradas e saídas digitais e analógicas de uso geral, assim como
um conjunto de entradas e saídas específicas para acessórios com funções mais elaboradas. Alguns
são capazes de efetuar o bloqueio do veículo em determinadas ocasiões, disparar alarmes, limitar
velocidade e, como é o caso deste projeto, desempenhar funções de telemetria informando à central
de monitoramento a leitura de diversos parâmetros de rodagem do veículo.
18
A Figura 1 apresenta um diagrama de blocos bastante simplificado que ilustra, de uma forma
genérica, como estão organizados a maioria dos rastreadores comerciais disponíveis no mercado.
RASTREADOR
MÓDULO GPS
MÓDULO GSM/GPRS
MICROCONTROLADOR
ACESSÓRIOS ENTRADAS SAÍDAS
Figura 1 – Esquema genérico de um rastreador comercial
3.2 Atualização remota
Um assunto que merece ser brevemente abordado é a questão da atualização remota. Esta
atualização nada mais é do que a capacidade do microcontrolador receber uma nova versão do
firmware sem que seja necessária a intervenção direta no hardware do dispositivo através de uma
rotina chamada bootloader. O bootloader fica alocado em uma parte específica da memória de
programção e normalmente é gravado uma única vez. Seu funcionamento restringe-se a verificar em
uma dada condição se existe uma nova versão do firmware disponível, caso positivo a nova versão é
gravada na memória de programa, caso negativo a rotina principal é inicializada [29].
19
4.0 REDES DE DADOS
Adaptando o conceito de redes de computadores do autor Sousa (1999), pode-se definir uma
rede de dados automotiva como um conjunto de ECUs interligadas de maneira a trocarem
informações e compartilharem recursos entre si. Em suma, uma rede é composta por uma parte física
e uma parte lógica, podendo variar em sua arquitetura, isto é, os caminhos físicos através dos quais
equipamentos interligam-se e interagem entre si.
4.1 Topologias de Redes de Dados
De acordo com Lopes (2007, apud TITTEL, 2003, p. 14) em uma rede de computadores, os
dados precisam trafegar por um caminho físico que interliga os dispositivos da rede. Os diferentes
tipos de caminhos são chamados de topologias. A Tabela 1, de uma forma resumida, elenca e
descreve as diferentes topologias sobre as quais uma rede pode ser montada.
Tabela 1 – Descrição das topologias de rede

Topologias de Rede
Topologia Descrição
Barramento Similar a arquitetura de barramento que conecta a memória principal à CPU.
Consiste num caminho simples de dados que conecta a ele mesmo todos os
dispositivos da rede, de modo que somente um dispositivo por vez pode usar o
barramento.
Anel É uma rede onde cada dispositivo da rede transmite somente para seu vizinho
posterior e recebe dados somente de seu vizinho anterior. Caso um dispositivo
queira receber dados do seu vizinho posterior mais próximo, estes dados terão que
trafegar todo o anel, passando por todos os outros dispositivos até recebê-los.
Ponto-a-Ponto A rede ponto-a-ponto é o tipo mais simples, para poucos dispositivos. Esta rede é
formada por um único enlace entre dois dispositivos. Quando muitos dispositivos
precisam se conectar com vários outros dispositivos, várias redes ponto-a-ponto
são combinadas, configurando uma estrela ou malha.
Estrela Nesta configuração, um dispositivo central é conectado a todos os outros
dispositivos da rede para realizar a comunicação entre eles.
Malha Para conectar todos os dispositivos entre si, é necessário 𝑛(𝑛– 1)/2 conexões
(onde n é o número de dispositivos da rede). Esta rede, apesar de complexa e de
custo elevado, tem a vantagem de ser muito rápida, pois um dispositivo na rede
tem conexão ponto-a-ponto com qualquer outro dispositivo, transmitindo os dados
diretamente. Existem redes chamadas de malha parciais, que eliminam os enlaces
raramente usados.
20
Híbrida É a combinação de uma ou mais topologias, tentando tirar o melhor proveito de

cada uma delas.
Fonte: (Lopes, 2007, apud TITTEL, 2003, p. 15).
4.2 Modelo OSI para Protocolos de Comunicação
O modelo OSI (Open Systems Interconnection) é baseado em uma proposta desenvolvida

pela ISO (International Standards Organization) como um primeiro passo em direção à padronização
internacional dos protocolos usados nas várias camadas (Tanenbaum 2011 apud Day et
Zimmermann, 1983, p. 25). Embora os protocolos associados a este modelo raramente sejam usados
nos dias de hoje, o modelo em si é de fato bastante geral e ainda válido [24]. Este modelo é
composto por sete camadas, as quais se encontram elencadas e descritas na Tabela 2.
Tabela 2 – Modelo de Referência OSI
Camadas do Modelo de Referência OSI

Camada Descrição
Esta camada contém uma série de protocolos comumente necessários aos
usuários. Ela é responsável por fornecer uma interface aos softwares de
7 - Aplicação
computador, permitindo que estes sejam escritos apenas uma vez e utilizados
em diferentes tipos de redes.
Esta camada é a responsável pela tradução dos dados para um formato padrão.
6 - Apresentação ASCII, JPEG e MP3 são alguns exemplos. Ela também é responsável pela
compressão, criptografia e decifração dos dados com objetivos de segurança.
Esta é a camada responsável por estabelecer, manter e encerrar sessões na
rede. É ela quem administra o reconhecimento de nomes e algumas
5 - Sessão
características de acesso, como quando e por quanto tempo um dispositivo
pode transmitir.
Esta camada é responsável pela preparação dos dados a serem transferidos. É
4 - Transporte ela quem gerencia o controle de fluxo, a correção de erros e divide os dados
trafegados em blocos de tamanhos adequados para a rede.
A camada de rede é responsável por atribuir um endereço único e global para
os dispositivos conectados nesta e prover direções de qualquer ponto a
3 – Rede qualquer outro ponto da rede. De modo geral, a qualidade do serviço fornecido
(retardo, tempo em transito, instabilidade etc.) também é uma questão da
camada de rede.
A principal tarefa da camada de enlace é transformar um canal de transmissão
bruto numa linha que pareça livre de erros para a camada de rede. Ela faz com
2 – Enlace
que o transmissor divida os dados em quadros de dados (em geral, algumas
centenas ou milhares de bytes) e os transmita seqüencialmente. Também é a
21
camada de enlace que realiza os controles de erro e fluxo, além da atribuição

de endereços físicos a cada um dos dispositivos de enlace. Para estes fins a
camada de enlace é subdividida em duas outras camadas: LLC (Controle
Lógico de enlace) e MAC (Controle de acesso ao meio).
Esta é a camada mais baixa, responsável pela definição e reconhecimento de
um bit (dígito binário 0 ou 1), o projeto de rede deve garantir que quando um
lado enviar um bit 1, ele seja recebido pelo outro lado como um bit 1, não como
1 – Física
um bit 0. Esta também é a camada onde estão definidos os meios de
transmissão, inclusive o tamanho dos cabos, interfaces de conexões
(terminações de cabos) e tensão.
Fonte: Tanenbaum (2003) p. 37
Esta divisão, em camadas, tem por objetivo tornar as funções tão discretas e independentes
quanto possível, de forma que qualquer alteração realizada em uma única camada não implique na
necessidade de adaptação de qualquer outra. No modelo OSI cada camada utiliza os serviços das
camadas inferiores, assim como disponibiliza dados e serviços às camadas superiores a sua posição
[13].
É importante salientar que uma tecnologia que adote o modelo OSI, não necessariamente
deverá utilizar todas as suas camadas. Existem tecnologias que as utilizam de forma parcial como o
Protocolo CAN, o qual possui definido por suas especificações apenas a camada física e a camada
de enlace [13].
4.3 Protocolo de Comunicação de Dados
Os protocolos de comunicação de dados exercem uma função vital na troca de dados entre
dispositivos eletrônicos. De uma forma simples, podem ser definidos como um conjunto de regras que
controla e sincroniza a comunicação visando que esta seja eficiente e sem erros e assegurando que
a mensagem transmitida chegue ao destino da mesma forma que foi transmitida de maneira a
preservar a integridade dos dados [22].
Sua composição é feita, basicamente, de um software agregado às duas interfaces de

comunicação. A garantia de integridade dos dados deve ser mantida não dependendo do meio pelo
qual são transmitidos, uma vez que o controle é feito nas pontas do meio de transmissão. Este
software insere caracteres de controle no início e no final de cada bloco a ser transmitido. Na
chegada do bloco no receptor, estes caracteres são checados e caso algum erro seja detectado, o
protocolo deverá enviar o mesmo bloco novamente até que este chegue corretamente [22].
22
4.4 Uso de Protocolos em Redes Automotivas
Quando se fala em comunicação entre as diversas ECUs presentes em um veículo, diversos

são os protocolos utilizados na atualidade. Estes variam de acordo com Associações de Montadoras,
montadoras e às vezes até mesmo conforme o modelo do veículo. Também pode ocorrer que em um
mesmo veículo sejam encontrados protocolos diferentes de acordo com a aplicação.
Em redes automotivas os protocolos dividem-se em grupos seguindo os critérios da Society of

Automotive Engineers (SAE). Protocolos de Classe A, possuem uma taxa de transmissão de até 10
kbps e são geralmente relacionados às funções de conforto de um veículo. Os protocolos Classe C
possuem uma taxa de transmissão compreendida entre 125 kbps a 1 Mbps e são relacionados aos
sistemas de segurança [8].
Os Protocolos Classe B, objeto de interesse deste projeto, são protocolos com taxa de
transmissão compreendida entre 10 kbps a 125 kbps, a exceção dos protocolos ISO11898, ISO1159-
2 (os quais podem assumir velocidades superiores) e do SAE J1939, o qual possui velocidade fixada
em 250 kbps.
Tabela 3 – Alguns protocolos de comunicação Classe B

CAN 2.0 CAN 2.0 J1859 J1850 J1850
ISO 11898 & SAE J1939 Class 2 SCP PCI
ISO 11519-2
Instituição diretamente
SAE & ISO SAE GM Ford Chrysler
relacionada
Controle e Controle e Controle e Controle e Controle e
Aplicação principal
diagnóstico diagnóstico diagnóstico diagnóstico diagnóstico
Par
Tipo de barramento Par trançado Par trançado Fio único Fio único
trançado
Codificação dos sinais NRZ NRZ VPW PWM VPW
Detecção de erros CRC CRC CRC CRC CRC
10 kbps –
Taxa de transmissão 250 kbps 10,4 kbps 41,6 kbps 10,4 kbps
1 Mbps
0–8 0–8 0 – 10
Quantidade de dados 0 – 8 Bytes 8 Bytes
Bytes Bytes Bytes
Comprimento máximo 40 metros 40 metros
35 metros 35 metros 35 metros
do barramento (p/ 1 Mbps) (p/ 1 Mbps)
Quantidade máxima
32 32 32 32 32
de nós na rede
Fonte: Guimarães, 2007, p. 212
É interessante lembrar que além destas classes mencionadas, ainda existem classes de
protocolos de: diagnóstico embarcado, protocolos do tipo Mobile Media – utilizados na implementação
do conceito “computador sobre rodas”, Safety Bus – utilizados em sistemas de airbag e ainda Drive-
by-wire – aplicados a sistemas eletromecânicos que substituíram os sistemas puramente mecânicos,
tais como freio, direção, aceleração, etc. [8].
23
5.0 CONTROLLER AREA NETWORK (CAN)
À medida que os veículos foram se modernizando e incorporando novas tecnologias,

observou-se uma demanda cada vez maior por um sistema de comunicação prático e confiável, que
interligasse o crescente número de ECUs instaladas a bordo [13]. O desenvolvimento do Protocolo
CAN possibilitou uma enorme redução na complexidade do cabeamento e, adicionalmente, tornou
possível conectar diversos dispositivos usando um único par de fios, permitindo uma troca simultânea
de dados entre os nós da rede (Lopes, apud Farsi et al, 2007, p. 20).
O Protocolo CAN é um protocolo de comunicação serial síncrona voltado, sobretudo, às

aplicações automotivas. Seu desenvolvimento deu-se pela empresa automotiva alemã Robert Bosch
GmbH e sua apresentação oficial ocorreu em um congresso da Sociedade de Engenheiros
Automotivos (SAE) realizado em Detroit no ano de 1986 [30]. Sua aplicação inicial envolvia ônibus e
caminhões. Atualmente é utilizado na indústria, em veículos automotivos, navios tratores e aviões,
entre outros [8].
Anteriormente ao surgimento do CAN a maioria das conexões automotivas era do tipo híbrida,
em uma combinação de topologias Ponto-a-Ponto e Malha [4]. Uma rede com CAN provê uma rede
de custo não muito elevado onde as ECUs podem ter uma interface simples ao invés de diversas
entradas analógicas e digitais em cada dispositivo, o que diminui, sobretudo, custos com cabeamento
e peso nos automóveis [14]. A Figura 2 esboça um comparativo entre uma rede sem CAN e uma rede
com CAN.
Figura 2 – Comparativo entre uma rede sem CAN e uma rede com CAN
Fonte: (NATIONAL INSTRUMENTS, 2011)
24
5.1 Conceituação básica
O Protocolo CAN implementa as duas camadas mais inferiores do modelo de referência OSI:
física e de enlace. A parte referente ao meio de comunicação, em si, foi deixada de fora da
especificação CAN da Bosch, propositalmente, com a finalidade de flexibilizar aos projetistas a
possibilidade de adaptação e otimização do protocolo de comunicação de diversas maneiras.
Contudo, com esta flexibilização vem a possibilidade do surgimento de problemas com questões
relacionadas à interoperabilidade [15].
Visando amenizar possíveis problemas com interoperabilidade a ISO e a SAE definiram

protocolos que incluíam interfaces dependentes de um meio de transmissão de forma que as duas
camadas mais inferiores passaram a ser definidas em sua totalidade. Como exemplos, podem-se
citar os protocolos ISO11898, ISO11519 e SAE J1939. Estes três protocolos especificam um
barramento diferencial de 5 volts como interface física. As camadas restantes do modelo OSI, são
deixadas em aberto para serem implementadas pelos desenvolvedores de software [15].
Uma rede utilizando o Protocolo CAN trabalha no conceito multimestre, onde qualquer
módulo pode tornar-se mestre em um dado momento e escravo no outro. Suas mensagens são
enviadas em regime multicast, o que significa que qualquer mensagem enviada ao barramento é
transmitida a todos os módulos existentes na rede [8], cabendo aos receptores a filtragem de
mensagens indesejadas ou desejadas, conforme ilustra a Figura 3 [3].
Figura 3 – Mensagem transmitida via barramento CAN

Fonte: CAN in Automation, 2011
5.1.1 Características Físicas
O Protocolo CAN, define sua codificação de bit como sendo do tipo Non-Return to Zero
(NRZ), onde o nível de sinal pode permanecer constante durante todo o tempo de bit. Desta forma,
medições devem ser feitas para assegurar o tempo máximo permitido entre duas bordas de sinal, o
que vem a ser importante para propósitos de sincronismo [3].
25
A velocidade de transmissão de dados é inversamente proporcional ao comprimento do

barramento. A norma ISO11898 especifica que um transceiver deve ser capaz de prover uma
velocidade de 1 Mbps em um barramento de 40 metros [16]. A Figura 4 ilustra a relação entre
comprimento e taxa de transmissão de dados.
Figura 4 – Relação entre comprimento da rede e taxa de transmissão

Fonte: (GUIMARÃES, 2007).
Considerando-se fios elétricos como meio de transmissão, os mesmos deverão ser trançados
e não blindados. Os dados transmitidos através do barramento não são caracterizados por possuírem
nível lógico alto “1” ou nível lógico baixo “0”, mas sim por uma representação denominada bits
dominantes “0” e bits recessivos “1”, em virtude de que as informações são interpretadas pela
diferença de potencial entre os fios CAN High (CAN_H) e CAN Low (CAN_L), ilustrado através da
Figura 5. Por esta razão o barramento CAN é classificado como par trançado diferencial [8].
Figura 5 – CAN - Barramento diferencial

Fonte: (RICHARDS, 2002)
26
Este par trançado diferencial atenua fortemente efeitos causados por interferências
eletromagnéticas, uma vez que, qualquer ação sobre um dos fios será sentida também pelo outro.
Desta forma, ambos os sinais irão flutuar para o mesmo sentido e com a mesma intensidade não
alterando a tensão diferencial entre CAN_H e CAN_L, a qual é a única referência para distinção de
estados lógicos no transceiver [8].
5.1.2 Características lógicas
5.1.2.1 Formato das mensagens
No protocolo CAN, as mensagens podem possuir dois formatos: CAN 2.0A, ou standard, e
CAN2.0B, também conhecido como formato estendido. O formato 2.0A, é caracterizado por possuir
um identificador de 11 bits possibilitando apenas 2.048 mensagens que utilizam esta formatação.
Esta limitação levou ao desenvolvimento do formato CAN 2.0B, o qual possui um identificador de 29
bits. A Figura 6 apresenta os quadros de mensagens para ambos os formatos vigentes.
CAN 2.0A
CAN 2.0B
Figura 6 – Comparativo entre os formatos CAN 2.0A e CAN 2.0B

Fonte: Adaptado de Guimarães (2007)
A partir da Figura 6, percebe-se que ambos os formatos começam com um bit de início,
imediatamente sucedido por um identificador de 11 bits. Este identificador estabelece a prioridade da
mensagem para os demais nós da rede. Quanto menor é o seu valor binário, maior é a prioridade.
Em seguida o bit RTR (Remote Transmission Request), para o formato CAN, 2.0A é um bit
que indica que a informação está sendo solicitada. Este bit é seguido de mais dois bits em estado
dominante. O bit SRR (Substitute Remote Request), para o formato CAN 2.0B apenas cumpre função
de substituir este bit por um estado sempre dominante [23].
O marco da divisão entre CAN 2.0A e CAN2.0B encontra-se no bit IDE (Identifier Extension).
Caso este bit encontre-se em estado recessivo, indica que os próximos dezoito bits serão a
27
continuação do identificador para constituir o formato estendido, caso contrário significa que a
mensagem será uma mensagem no formato standard [23].
Para o formato estendido, após o complemento do endereço vem o bit de RTR, funcionando
exatamente da mesma maneira do modo standard. E após os dois bits recessivos que o sucedem,
ambos os formatos apresentam as mesmas características, sendo seguidos pelos bits de DLC (Data
Length Code) que informam ao receptor de quantos bytes de dados a mensagem se constitui.
Embora seja composto por quatro bits, este campo pode assumir o valor máximo de oito [23].
A quantia de bytes informada pelo campo DLC é transmitida e em seguida tem-se o campo
de CRC (Cyclic Redundancy Check). Este campo contém o checksum para a detecção de erros e é
sucedido pelo bit ACK (Acknowledgement), o qual é lançado em estado recessivo e qualquer nó da
rede que tenha recebido a mensagem corretamente deverá acusar o correto recebimento desta
mensagem sobrescrevendo este bit. Caso o transmissor não detecte esta sobrescrição, a mensagem
é novamente enviada [23].
Por fim, as mensagens possuem sete bits todos em estado recessivo. O primeiro bit é
denominado EOF (End of Frame), cuja função seria indicar o final da transmissão e os bits restantes
são denominados IFS (Inter-Frame Space) cuja função é dar o tempo necessário ao microcontrolador
mover corretamente os dados para um buffer de recepção de mensagem [23].
5.1.2.2 Arbitração
De acordo com Guimarães (2011) um dos pontos fortes do Protocolo CAN é a sua
fundamentação no conceito Carrier Sense Multiple Access/Collision Detection with Non-Destructive
Arbitration (CSMA/CD with NDA), o que significa que todos os módulos verificam o estado do
barramento, analisando se outro módulo com prioridade maior está tentando transmitir alguma
mensagem. Caso esta situação seja detectada, o módulo de menor prioridade imediatamente
interrompe sua transmissão e o de maior prioridade segue a transmissão normalmente.
Quanto menor é o valor binário do identificador de uma mensagem, maior é a sua prioridade.
Um identificador consistindo apenas de zeros é o que possui maior prioridade de mensagem na rede,
pois se dois nós iniciam uma transmissão simultaneamente, o nó que envia um bit dominante
enquanto o outro envia um bit recessivo fica com o controle do barramento e envia sua mensagem. E
o cancelamento da mensagem, feita pelo nó que perdeu a arbitração, só é possível porque um nó
monitora constantemente sua própria transmissão [23]. A Figura 7 ilustra a fase de arbitração.
28
Figura 7 – Arbitração CAN

Fonte: (NATIONAL INSTRUMENTS, 2011)
5.1.3 Padrões Existentes
Guimarães, (2007), afirma que o Protocolo CAN tem seus fundamentos especificados por
duas normas: ISO 11898, que determina as características para redes de alta velocidade de
transmissão de dados (de 125 kpbs a 1 Mbps) e ISO 11519-2, a qual determina características para
redes de baixa velocidade de transmissão de dados (de 10 kbps a 125 kbps). Ambos os padrões
especificam apenas as camadas 1 e 2 do modelo de referência OSI.
As demais camadas são especificadas por outros padrões onde cada um possui uma
aplicação específica. Como exemplo, pode-se citar os padrões [8]:
 NMEA 2000: Baseado no CAN 2.0B, aplicações navais e aéreas;

 DIN 9684 – LBS: Baseado no CAN 2.0A, aplicação agrícola;
 ISO 11783: Baseado no CAN 2.0B, aplicação agrícola;
 SAE J1939: Baseado no CAN 2.0B, aplicação automotiva, principalmente ônibus e
caminhões.
Dentre os padrões exemplificados, o padrão SAE J1939 é objeto de interesse deste projeto
uma vez que o decodificador de dados a ser projetado será o elo entre as leituras do caminhão com
os dispositivos de monitoramento instalados em ônibus e caminhões.
29
6.0 PADRÃO SAE J1939
O Padrão SAE J1939 é um protocolo de alto nível o qual roda sobre o Protocolo CAN2.0B.
Nos dias atuais, este Padrão é utilizado como barramento de comunicação padrão para veículos
comerciais, sobretudo em ônibus e caminhões, em aplicações de diagnóstico e controle. Devido à
sua popularidade passou também a ser adotado em aplicações agrícolas (ISO 11789), navais e
aéreas (NMEA 2000) [17].
É chamado de Protocolo de Alto Nível porque faz a ligação entre as camadas de Enlace e
Aplicação, cabendo lembrar que o Protocolo CAN implementa apenas as duas camadas mais
inferiores do modelo de referência OSI. O Padrão J1939 define as camadas, de rede, transporte,
sessão e apresentação, deixando a camada de aplicação para outros desenvolvedores [28].
Este Protocolo especifica exatamente como a informação será intercambeada entre as ECUs
de um veículo, ou seja, define a prioridade, tamanho, escala e offset das mensagens. Tomando por
exemplo o tacômetro, é definido por este Padrão que sempre terá uma prioridade 3, um tamanho de
16 bits, uma resolução de 0.125 RPM/bit e um offset de 0 [17].
6.1 Grupos de Parâmetros (PG)
Um Grupo de Parâmetro é um conjunto de informações transmitidas em uma mensagem

J1939. Estes parâmetros podem incluir comandos, dados, requisições, e reconhecimentos positivos e
negativos [21]. O comprimento de um Grupo de Parâmetro não está limitado ao comprimento do
quadro de mensagens do CAN. Comumente um Grupo de Parâmetro possui um comprimento mínimo
de oito bytes, podendo atingir até 1785 bytes. Grupos de Parâmetros com mais de oito bytes
requerem um protocolo de transporte para sua transmissão [10].
6.1 Formato das Mensagens
Dado ao fato que o J1939 roda sobre o Protocolo CAN 2.0B, suas mensagens utilizam
sempre um identificador de 29 bits. Este campo, como o próprio nome diz, destina-se à identificação
do dispositivo transmissor, e em alguns casos, endereçar o destino de informações no barramento
[28]. A Figura 8 ilustra o formato de mensagens do Protocolo J1939.
30
Figura 8 – Formato de Mensagem do J1939

Fonte: Voss (2008)
Analisando a Figura 8, percebe-se que o campo do identificador é dividido em três blocos:

prioridade, PGN (Parameter Group Number) e endereço de origem. A prioridade de uma mensagem
no J1939 é fundamental na fase de arbitração. Quanto menor for o seu valor binário, mais alta será a
prioridade de uma mensagem. Este campo possui a dimensão de três bits, ficando limitado a oito
valores de prioridade [20].
O bloco denominado PGN, posteriormente é dividido em quatro blocos menores: Reservado,

Página de Dados, Formato PDU (Protocol Data Unit) e Especificidade do PDU. Os bits Reservado e
Página de Dados (Data Page) ainda não possuem funções especificadas para o J1939. Neste bloco,
estes dois primeiros bits destinam-se a aplicações futuras que ainda serão definidas pela SAE e são
sempre lidos como zero [28].
Existem dois tipos de PGN: Global e Específico. Um PGN global identifica Grupos de
Parâmetros que são enviados para todos sob a forma de broadcast de informações, enquanto um
PGN específico indica que Grupos de Parâmetros são enviados a dispositivos particulares ou peer-to-
peer e, desta forma, também pode ser utilizado como endereço de destino. O Formato da Unidade de
Protocolo de Dados (PDU Format) é o subconjunto de bits responsável pela identificação do tipo de
PGN [10].
Um broadcast é definido quando o bloco PDU Format possui um valor igual ou superior a
F016, neste caso este campo recebe a denominação de PDU1. Quando este bloco possuir valor
inferior, significa que Grupos de Parâmetros serão enviados a um dispositivo específico (peer-to-
peer), o campo então recebe o nome de PDU2 [10].
Seguindo adiante, na composição do PGN, vem o bloco chamado PDU Specific. Este bloco,
de acordo com Junger (2010), é utilizado apenas quando a mensagem é global. Neste caso, o bloco
é chamado de Extensão de Grupo (GE), caso contrário é sempre zero [10]. A Figura 9, facilita a
compreensão desta divisão.
31
Figura 9 – Divisão entre PGN Global e PGN Específico

Fonte: (JUNGER, 2010)
Por fim, o identificador de uma mensagem J1939 possui um bloco de oito bits o qual contém o
endereço da Aplicação de Controle (CA). Cabe salientar que uma ECU pode conter uma ou mais
CAs, porém cada CA contém um único endereço associado com o nome do dispositivo [10].
6.2 Campo de Dados
Em uma rede J1939, todos os parâmetros utilizados são descritos por suas especificações e
são identificados por um número denominado SPN (Suspect Parameter Valor). Para cada SPN
atribuído pelo Comitê da SAE, a norma SAE J1939-71, são estabelecidos os seguintes critérios:
comprimento de dado (em bytes), tipo de dado, resolução, offset, faixa de dado, e um rótulo para
identificação. Os SPNs que compartilham uma mesma característica são agrupados em um mesmo
Grupo de Parâmetros (PG), e por sua vez, são transmitidos pela rede utilizando o mesmo PGN [1].
Para uma melhor compreensão, pode-se tomar como exemplo a taxa de consumo de
combustível (SPN=183) e a economia instantânea de combustível (SPN=184). De acordo com a
Norma SAE J1939-71 tem-se:
SPN 183 Taxa de Combustível do Motor

Quantidade de combustível consumida pelo motor por unidade de tempo.
Comprimento de dado: 2 bytes
Resolução: 0.05 L/h por bit, 0 offset
Faixa de Dado: 0 a 3.212,75 L/h
Faixa operacional: igual à faixa de dado
Tipo: Medido
Informação de Apoio:
Referência PGN: 65266
SPN 184 Economia Instantânea de Combustível do Motor

Economia atual de combustível na velocidade atual.
Comprimento de dado: 2 bytes
Resolução: 1/512 km/L por bit, 0 offset
Faixa de Dado: 0 to 125.5 km/L
Faixa operacional: igual à faixa de dado
Tipo: Medido
Informação de Apoio:
Referência PGN: 65266
(SAE J1939-71, 2006, p. 39-40).

32
Para estes dois parâmetros, consultando a Referência PGN indicada pelos SPNs 183 e 184
encontra-se a definição:
PGN 65266 Economia de Combustível (Líquido) - LFE

Taxa de Repetição de Transmissão: 100 ms
Comprimento de dado: 8
Página de dados estendida: 0
Data Page: 0
Formato PDU: 254
Especificidade PDU: 242
Informação de Suporte PGN:
Prioridade Padrão: 6
Parameter Group Number: 65266 (0xFEF2)
Início Comprimento Nome do Parâmetro SPN

1-2 2 bytes Taxa de Consumo de Combustível do Motor 183
3-4 2 bytes Ec. Instantânea de Combustível do Motor 184
5-6 2 bytes Economia Média de Combustível 185
7 1 byte Posição do Acelerador do Motor 51
(SAE J1939-71, 2006, p. 627).
Uma análise destas duas citações leva à conclusão de que para efetuar uma leitura dos
parâmetros Taxa de Combustível do Motor e Economia Instantânea de Combustível no Motor deve-
se esperar uma mensagem identificada pelo PGN=FEF216. Ambas são compostas por dois bytes de
dados, com resolução, offset, e faixa de valores definidas. Uma vez recebida uma mensagem
contendo o PGN desejado, basta efetuar a leitura dos Bytes 1 e 2 para o SPN 183 e os bytes 2 e 4
para o SPN 184. No entanto observa-se que o PGN=FEF216 ainda poderá conter duas informações
adicionais: Economia Média de Combustível e Posição do Acelerador do Motor, onde estes dados,
não sendo desejados, devem ser ignorados.
Para um melhor entendimento pode-se consultar a tabela contida no Anexo C deste projeto, a
qual versa sobre o exemplo do PGN=FEF216, para a Interface FMS (seção 6.2). O leitor irá notar que
para esta interface não se utilizam os SPNs 185 e 51. SPNs não implementados, via de regra
possuem seus bytes preenchidos com FF16.
6.3 FMS (Fleet Management System) Standard
O FMS-Standard (Sistema de Gerenciamento de Frota) é uma interface aberta e padronizada

que visa à disponibilização dos dados veiculares a terceiros, objetivando tornar aplicações de
telemetria independentes de fabricantes. Esta interface aplica-se a ônibus e caminhões, sendo
desenvolvida em 2002, por seis dos principais fabricantes europeus: Daimler AG, MAN AG, Scania,
Volvo (incluindo Renault), DAF Trucks e IVECO [7].
33
Uma interface FMS-Standard, usualmente, provê:
 Velocidade do Veículo (baseada na roda);

 Velocidade do Veículo (do tacógrafo);
 Chavel da Embreagem (ligada/desligada);
 Chave do Freio (ligada/desligada);
 Controle de Cruzeiro (Ligado/Desligado);
 Tomada de Força (PTO) (Estado/Modo);
 Posição do Pedal do Acelerador (0–100 %);
 Total de Combustível Usado (Em litros, desde o tempo de vida);
 Nível de Combustível (0–100 %);
 Giros do Motor;
 Peso nos Eixos (kg);
 Total de Horas do Motor (h);
 FMS-Standard Versão do Software (modos suportados);
 Número de Identificação do Veículo (ASCII);
 Informação do Tacógrafo;
 Distância do Veículo em Alta Resolução;
 Serviço de Distância;
 Temperatura Refrigerante do Motor.
(Wikipedia, 2011, Fleet Management System)
Estas informações seguem a codificação em conformidade com as especificações da Norma

SAE J1939 em todos os aspectos descritos pelo documento SAE J1939-71. Embora esta interface
possibilite a independência de fabricantes, no tocante às aplicações, a quantidade de dados
disponibilizados é dependente não apenas do fabricante, como também do modelo dos veículos. Não
necessariamente todos os dados listados acima estarão disponíveis em um mesmo veículo [30].
A interface FMS é de grande importância por ser descrita como o único local para uma
conexão de dados segura para a rede interna do veículo [7]. Pois, de acordo com a carta intitulada
Letter to the European Institutes, ligações feitas diretamente ao barramento não são permitidas,
devido aos grandes riscos de interferências em sistemas de controle, como motor e freios. Caso tais
ligações sejam encontradas em um veículo, Hodac (2004) declara que os fabricantes reservam-se ao
direito de retirar qualquer garantia sobre o produto.
34
7.0 PROJETO DO DECODIFICADOR DE DADOS
Este projeto surge da necessidade da empresa CIELO INDÚSTRIA MECATRÔNICA, para o

desenvolvimento de um novo aparelho rastreador, capaz de extrair informações de bordo de um
veículo a partir de todos os sensores que o fabricante disponibilizar. Com isso, espera-se reduzir os
custos de um sistema de rastreamento, através da diminuição do número de sensores próprios a
serem instalados e despesas relacionadas a estes, bem como eliminar divergências entre as leituras
recebidas pela central de monitoramento e as apresentadas ao condutor no painel do veículo.
7.1 Especificações do Projeto
O decodificador de dados necessita conectar-se ao barramento CAN de veículos pesados,

isto é, ônibus e caminhões, dotados de informações codificadas conforme especificações da norma
SAE J1939 e disponibilizados através da Interface FMS. Os dados lidos devem ser decodificados e
disponibilizados a outros dispositivos através comunicação serial. A Figura 10, ilustra onde o projeto
estará inserido dentro de um sistema de rastreamento.
Figura 10 – Contextualização do Projeto
É importante que o decodificador seja um dispositivo de baixo custo e realize apenas

operações de leitura do barramento CAN, não enviando informação alguma ao barramento, nem
mesmo bits de acknowledgement. O protocolo de comunicação serial a ser utilizado é o RS-232.
Também é necessário que o dispositivo esteja apto a receber novas versões do Firmware em um
sistema de atualização remota via serial.
35
7.2 Componentes de Hardware
Partindo do ponto de que não é possível fazer testes com o barramento CAN sem a
existência de pelo menos dois nós de rede, e não é possível contar com um ônibus ou caminhão
sempre à disposição, faz-se necessária a construção de um pequeno kit de desenvolvimento J1939,
em uma disposição ilustrada pelo diagrama da Figura 11. Neste esquema, o bloco denominado Nó
TX assumirá o papel do veículo enquanto o Nó RX constitui o objetivo geral deste projeto.
Figura 11 – Diagrama do kit de desenvolvimento
7.2.1 Composição do Nó TX
O Nó TX é a parte do kit de desenvolvimento responsável por simular acionamentos captados

e sinais emitidos a bordo de um veículo pesado. Seu funcionamento consiste da leitura periódica de
quatro entradas digitais e duas entradas analógicas acionadas pelo usuário e disponibilizadas a cada
segundo por um display para fins de acompanhamento. O diagrama da Figura 12 ilustra sua
composição genérica.
SINAL DO SENSOR
DE TEMPERATURA
SINAL DO PEDAL DO
ACELERADOR
SINAL DO
VELOCÍMETRO
DISPLAY LCD CAN

MICROCONTROLADOR
16x2 TRANSCEPTOR
BOTÕES DE NAVEGAÇÃO
CHAVE
BARRAMENTO
PEDAL DO FREIO
CAN
CHAVE
PEDAL DA EMBREAGEM
CHAVE
PILOTO AUTOMÁTICO
Figura 12 - Esquema genérico de hardware do Nó TX

36
7.2.2 Composição do Nó RX
Este nó representa o projeto do decodificador de dados. Seu objetivo inicial é receber as

mensagens do barramento CAN, decodificá-las e disponibilizá-las através da porta serial. No entanto,
para fins de demonstração o nó também oferece a possibilidade de visualização dos dados recebidos
através de um display, de maneira periódica. Seu esquema genérico é mostrado na Figura 13.
BARRAMENTO
MEMÓRIA I²C
CAN
INTERFACE DISPLAY LCD

MICROCONTROLADOR
CAN 16x4
INTERFACE BOTÕES DE NAVEGAÇÃO

SERIAL
COMPUTADOR COMPUTADOR
Figura 13 - Esquema genérico de hardware do Nó RX
7.2.3 Displays LCD e botões de comando
Ambos os nós utilizam um display LCD individual para um melhor acompanhamento dos
sinais gerados e recebidos. Para o Nó TX é adotado um display LCD 2x16 ao passo que para o Nó
RX será utilizado um display LCD 4x16.
A navegação através dos menus de configuração e dados exibidos é dada por três botões de
comando para cada nó, dispostos na configuração Seta à Esquerda, Enter e Seta à Direita. Estes são
botões de ação momentânea, isto é, retornam à posição original após seu pressionamento.
37
7.2.4 Simuladores de Acionamentos e Medição da Temperatura
O Nó TX contém duas entradas analógicas, as quais são utilizadas para que o usuário possa
simular diferentes valores para a posição do pedal do acelerador e para velocidade do veículo.
Fisicamente estão constituídos por dois potenciômetros conectados a dois canais A/D do
microcontrolador. A simulação dos sinais de acionamento de pedais do freio e embreagem, bem
como o piloto automático será feita através de chaves de ação permanente.
Outro sinal a ser enviado ao microcontrolador é a leitura da temperatura ambiente. Para a

realização desta leitura, utilizou-se o sensor de temperatura DS1820, escolhido por estar disponível
tanto no estoque da Cielo Indústria quanto no almoxarifado da UPF. Este é um sensor de temperatura
digital que requer uma única porta para comunicação, podendo medir temperaturas compreendidas
entre -55°C e +125°C
7.2.5 Interface de Comunicação Serial
Conforme especificação do projeto, a transmissão dos dados decodificados deverá ocorrer

através de comunicação serial RS-232. Embora para o rastreador a presença de uma interface serial
não seja necessária em virtude de que a comunicação entre este e seus acessórios ocorre
diretamente entre seus microcontroladores, sua presença é necessária para fins de testes e
demonstrações no computador.
O hardware desta interface é composto por um circuito integrado MAX232, escolhido por ser
um CI relativamente comum e disponível no Almoxarifado de Eletrônica da UPF, ligado a um conector
DB9 (padrão para este tipo de comunicação).
7.2.6 Interface CAN
Presente nos dois nós do kit de desenvolvimento esta interface realiza a conversão entre as
configurações físicas do sinal no formato TTL, para um sinal no formato CAN e vice versa. Para
desempenhar esta função foram analisados três circuitos integrados: MCP 2510, MCP 2515 e MCP
2551.
38
7.2.6.1 Controlador MCP 2510
É caracterizado por ser um controlador CAN com interface embarcada SPI que implementa
por completo CAN 2.0A e CAN 2.0B. Possui uma taxa de transmissão programável de até 1 MBPS,
dois buffers de recepção com armazenamento priorizado, seis filtros de aceitação completos, duas
máscaras de filtro de aceitação e três buffers de transmissão com priorização. É oferecido em
encapsulamentos de 18 e 20 pinos.
7.2.6.2 Controlador MCP 2515
O circuito integrado MCP 2510, é um controlador CAN que implementa o protocolo CAN
formato 2.0B. É capaz de transmitir e receber ambos os formatos. Possui duas máscaras de
aceitação e seis filtros de aceitação, os quais são utilizados para rejeitar mensagens não desejadas.
Sua comunicação com microcontroladores é dada através da interface embarcada SPI. É oferecido
em encapsulamentos de 18 e 20 pinos.
7.2.6.3 Transceptor MCP 2551
Este dispositivo é um transceptor de alta velocidade que suporta até 1 MBPS de taxa de
transmissão, recomendável para sistemas de 12 V e 24 V. Opera em baixa corrente quando em
standby, possui proteção contra condições de curto-circuito e proteções contra transientes de tensão
até ±250 V no barramento. Também apresenta proteção contra condições térmicas, entrando em
desligamento automático quando a temperatura limite for ultrapassada. É oferecido em
encapsulamentos de 4 pinos.
7.2.6.4 Escolha da Interface CAN
Diante das opções analisadas optou-se pela utilização do transceptor MCP 2551. Entende-se
que a interface CAN deva ser responsável apenas pela conversão entre um formato de sinal e outro.
Esta escolha permite que funções mais complexas como aplicação de filtros e máscaras,
programação da taxa de transmissão e seleção de padrões A ou B fiquem sob o gerenciamento do
microcontrolador, sem a necessidade da criação de um código fonte específico para a Interface CAN.
39
7.2.7 Microcontroladores
Para os dois nós do kit de desenvolvimento utilizou-se o mesmo microcontrolador que

deveria, obrigatoriamente, ser dotado de um módulo CAN capaz de trocar mensagens nos formatos
CAN 2.0A e CAN 2.0B, uma vez que o dispositivo utilizado como interface CAN apenas realiza a
conversão de um tipo de sinal físico para outro.
Analisando o esquema das Figura 12 e Figura 13 verificou-se que para a construção de

ambos os nós seria necessário um microcontrolador com pelo menos quatorze portas de I/O digitais
e, no caso especial do Nó TX, também necesssitaria possuir ao menos duas entradas digitais. Três
modelos de microcontroladores foram avaliados: AT91SAM7A3-AU, DsPic33FJ64GP804 e
PIC18F2580.
7.2.7.1 Microcontrolador AT91SAM7A3-AU
Também chamado de ARM7, é um microcontrolador de 32-bits de alto desempenho. Possui

dois controladores CAN 2.0B ativos, suportando mensagens tanto CAN 2.0A quanto CAN 2.0B. Seus
módulos suportam taxas de transmissão de até 1 Mbps, podendo ser setada automaticamente
quando em modo listen. Oferece também gerenciamento de prioridades entre as caixas de saída de
transmissão. O tamanho do buffer de transmissão pode ser programado para até 16 caixas de
entrada. Possui modos sleep e wake-up programáveis pela atividade do barramento ou pela
aplicação. É dotado de 60 pinos de I/O digitais e dois conversores AD contendo 8 canais cada um,
com resolução de 10 bits.
7.2.7.2 Microcontrolador DsPic33FJ64GP804
É um microcontrolador de 16-bits com um módulo ECAN 2.0B ativo, o qual oferece suporte a
taxas de transmissão de até 1 Mbps. Este módulo é capaz de implementar até 8 buffers de
transmissão e 32 buffers de recepção nas configurações normal, loopback e listen only. Possui 16
filtros de aceitação e três máscaras, assim como distintos modos de operação para diagnóstico e
monitoramento do barramento. O dispositivo também pode processar automaticamente requisições
remotas e quando em modo sleep o dispositivo pode ser despertado automaticamente ao detectar
uma mensagem CAN. Possui 35 pinos de I/O digitais e um conversor AD com 13 canais com
resolução de 12 bits.
40
7.2.7.3 Microcontrolador PIC18F2580
Trata-se de um microcontrolador de 16-bits com um módulo ECAN 2.0B ativo. Seu módulo
suporta taxas de transmissão de até 1 Mbps passíveis de operar em três modos distintos: Legacy,
Enhanded Legacy e FIFO (First Input First Output). Possui três buffers dedicados à transmissão com
priorização e dois buffers dedicados à recepção, além de seis buffers programáveis, dentro das
configurações normal, loopback e listen only. Possui três máscaras de aceitação e 16 filtros com
associação dinâmica. Quando em sleep é capaz de despertar quando for detectada uma mensagem
no barramento CAN. Possui um conversor AD com 8 canais a uma resolução de 10 bits e 25 pinos de
I/O.
7.2.7.4 Escolha do Microcontrolador
Conforme especificação do projeto e em conformidade com o padrão J1939 o projeto irá

operar a uma faixa de transmissão de 250 kbps, apenas em modo listen. Embora os
microcontroladores AT91SAM7A3-AU e DsPic33FJ64GP804 possuam recursos bastante avançados
e numerosos, tanto em seus módulos CAN quanto nas suas entradas analógicas e pinos de I/O, para
implementação deste projeto optou-se pela utilização do microcontrolador PIC18F2580. Além de
estar disponível em boa quantidade no estoque da empresa Cielo, seus recursos são suficientes para
atender a todas as necessidades dos dois nós do kit de desenvolvimento.
7.2.8 Memória I²C
Quando uma atualização remota de firmware for iniciada, todo o arquivo hexadecimal será
descarregado previamente nesta memória I²C, de forma a assegurar que o microcontrolador só inicie
o processo de gravação na memória de programa após todos os dados já terem sido recebidos pelo
circuito. Uma vez completada a descarga de uma nova versão, o microcontrolador sinaliza o
recebimento de um novo firmware ao bootloader, e se reinicia. O bootloader, por fim, grava o arquivo
hexadecimal na memória de programa, limpa a sinalização e reinicia novamente o microcontrolador.
Dentre as opções de memória disponíveis tanto na Cielo, quanto no almoxarifado da UPF,

optou-se por utilizar a memória 24LC512, por ser a maior memória disponível com 64 kB sendo
suficiente aos arquivos hexadecimais para esta aplicação.
41
7.2.9 Fonte de Alimentação
Partindo do ponto de que em um veículo pesado comercial encontram-se saídas de tensão de

12 V e 24 V e que o consumo típico dos circuitos em funcionamento com backlight ligado é de 120
mA para cada nó, projetou-se uma fonte utilizando o regulador de tensão 7805, o qual além de operar
na faixa de tensão de entrada desejada fornece uma tensão de saída de 5 V [6], necessária ao
correto funcionamento dos circuitos. A topologia da fonte de alimentação é descrita pela Figura 14, a
seguir.
U6
7805
IN 12~24 FU1 D1 5VDC
1 3 VCC
VI VO
GND
1N4007 PIN
ENTRADA
R6
560R
2
D2 C9 C10 C11 C12
1N4007 100uF 100nF 10u
100nF
GND D3
TERRA LED
Figura 14 – Circuito da Fonte de Alimentação
No circuito da Figura 14, os diodos D1 e D2 atuam como proteção contra inversão da

alimentação, o fusível FU1 atua como proteção contra sobrecorrente e os capacitores de C10 e C12
atuam como filtro para sinais de alta freqüência. No momento da partida, a queda de tensão da
bateria de um veículo é em média de 3 V. Esta queda não representa problemas para o regulador de
tensão 7805, o qual necessita de apenas 7 V de alimentação para funcionar, de qualquer forma foram
acrescentados os capacitores C9 e C11 para minimizar efeitos de transientes que possam levar a
tensão de alimentação abaixo dos 7 V.
7.2.10 Esquemático de Hardware
O modelo esquemático do hardware projetado para os dois nós encontra-se ilustrado através
da Figura 15, para o nó TX e pela Figura 16, para o nó RX. A lista dos materiais utilizados pode ser
visualizada no Anexo A, deste projeto.
42
LCD2
LM016L VCC
J3 RV4 VCC VCC VCC
1 VPP2
2 VCC
3 GND
SPEED S3 S4 S5
50%
4 PGD2
5 PGC2 5k
VDD
VSS
VEE
CLUTCH
RW
RS
CRUISE
D0
D1
D2
D3
D4
D5
D6
D7
BRAKE
E
TBLOCK-I5
1
GND 2
VCC 3
PGC2 4
5
PGD2 6
7
8
9
10
11
12
13
14
VCC
VE2
DT0
DT1
DT2
DT3
RV3 VCC
RV2 R13 R14 R15
10k 10k 10k
VE2
50%
ACCEL
50%
5k
U4
5k ACCEL
11 2
RC0/T1OSO/T13CKI RA0/AN0
12 3 SPEED
RC1/T1OSI RA1/AN1
13 4 BRAKE
RC2/CCP1 RA2/AN2/VREF-
14 5 CLUTCH
RC3/SCK/SCL RA3/AN3/VREF+
SDAB 15 6 CRUISE VCC <- LEFT VCC ENTER VCC RIGHT ->
RC4/SDI/SDA RA4/T0CKI
16 7
RC5/SDO RA5/AN4/SS/HLVDIN
17 10
RC6/TX/CK RA6/CLKO/OSC2 LEFTB INT0B RIGHTB
18 9
RC7/RX/DT RA7/CLKI/OSC1
S6 S7 S8
VPP2 1 21 INTOB
RE3/VPP/MCLR RB0/INT0/AN10
22
RB1/INT1/AN8
23 CANTX R10 R11 R12
RB2/INT2/CANTX 10k 10k 10k
24 CANRX
RB3/CANRX
25 LEFTB
RB4/KI0/AN9
26 RIGHTB
RB5/KBI1/PGM
27 PGC2
RB6//KBI2/PGC
28 PGD2
RB7/KBI3/PGD
PIC18F2580
VCC
3 U5
R7 VCC
VCC J8 U8
CANTX 1 7 120R
TXD CANH 3
PIN VCC
25.5 2 SDAB
CANRX 4 6 DQ
RXD CANL J5 1
GND
RS 8 5 PIN
RS VREF DS1822
GND
MCP2551
2
R5
10k
U9
J10 FU1 D4 7805
VCC
1 3
VI VO
GND
CHAVE 150mA
1N4007
ENTRADA
R18
C6 C7 560R
2
D6 C5
100u 100nF
1N4007 1000uF
J11 D5
TERRA LED
Figura 15 – Esquemático de Hardware para o Nó TX

43
VCC
RV1
VEE
50% LCD1
LM041L
VCC <- LEFT VCC ENTER VCC RIGHT ->
5k
LEFT INT0 RIGHT
S9 S10 S11
R2 R3 R4
10k 10k 10k
VDD
VSS
VEE
RW
RS
D0
D1
D2
D3
D4
D5
D6
D7
E
GND 1
VCC 2
VEE 3
PGC 4
5
PGD 6
7
8
9
10
11
12
13
14
D0
D1
D2
D3
VCC
C1
U1 U2 J1
1 1uF 3
2 11 D0
3
RA0/AN0 RC0/T1OSO/T13CKI
12 D1 C3 1
RA1/AN1 RC1/T1OSI 1uF 6
4 13 D2 C1+ C1-
RA2/AN2/VREF- RC2/CCP1 2
5 14 SCK
RA3/AN3/VREF+ RC3/SCK/SCL TX 11 14 7
6 15 SDA T1IN T1OUT
RA4/T0CKI RC4/SDI/SDA RX 12 13 3
7 16 D3 R1OUT R1IN
RA5/AN4/SS/HLVDIN RC5/SDO 10 7 8
10 17 TX T2IN T2OUT
RA6/CLKO/OSC2 RC6/TX/CK 9 8 4
9 18 RX R2OUT R2IN
RA7/CLKI/OSC1 RC7/RX/DT 9
2 C4 5
INT0 21 1 VPP VS+
RB0/INT0/AN10 RE3/VPP/MCLR 6
INT1 22 VS-
RB1/INT1/AN8 CONN-D9F
TXD 23
RB2/INT2/CANTX 1uF
RXD 24 C2+ C2-
LEFT 25
RB3/CANRX R9
RB4/KI0/AN9 C2 10k
RIGHT 26
RB5/KBI1/PGM 4 5 MAX232
PGC 27
RB6//KBI2/PGC
PGD 28
RB7/KBI3/PGD
1uF
PIC18F2580
VCC
3 U3
R8
J4 R16 R17
VCC 10k 10k
PIN 120R 7 1 TXD
CANH TXD U7 J2
J9 6 4 RXD SCK 6 1 5
CANL RXD SCK A0
SDA 5 2 4 PGC
PIN SDA A1
5 8 SLP 7 3 3 PGD
VREF RS WP A2
2 GND
GND
24LC512 1 VCC
MCP2551 VPP
2 TBLOCK-I5
R1
10k
U6
J6 S1 D1 7805
FU2 VCC
1 3
VI VO
GND
CHAVE 150mA 1N4007

ENTRADA
R6
C11 C12 560R
2
D2 C9
100uF 100nF
1N4007 1000uF
J7 D3
TERRA LED
Figura 16 – Esquemático de Hardware para o Nó RX

44
7.2.11 DESENVOLVIMENTO DO FIRMWARE
7.2.11.1 NÓ TX
Esta parte do projeto é a responsável pela simulação dos dados emitidos por um veículo, seu
funcionamento, de uma forma geral, é descrito pelo fluxograma das Figura 17 e 18.
Início Configuração
TX Buffer disponível Transmite dados

e Horímetro setado? SIM do Horímetro
NÃO
Incrementa 1 ms #INT_TIMER2
Transmite dados TX Buffer

do Nível do disponível e Nível do Comustível
SIM setado?
Combustível
NÃO Atingiu 1000 ms? Reseta contador

SIM
Transmite dados de
TX Buffer disponível
pedais, cruise control,
C. Control / Velocidade Inverte estado
setado? SIM e velocidade baseada
na roda do LED e incrementa
contador
NÃO
Contador atingiu
Transmite dados TX Buffer disponível
180?
da velocidade do e Engine Controller #2
motor SIM setado?
NÃO SIM
NÃO Calcula consumo,

Incrementa Horímetro
distância percorrida,
e sinaliza flag
e sinaliza flags
TX Buffer disponível Transmite dados
consumo de combustível do consumo de
setado? SIM combustível
NÃO
Figura 17 – Fluxograma do Firmware do Nó TX (Parte 1 de 3)

NÃO
45
Transmite leitura TX Buffer disponível

da velocidade e Engine Controller #1
do motor SIM setado?
NÃO
Calcula taxa consumo
O valor de "ms" possui de combustível e
TX Buffer disponível divisão exata por 100? SIM adquire referência

Transmite leitura de velocidade
Distância Percorrida
SIM do odômetro
setado?
NÃO
NÃO
Adquire referência
de posição do O valor de "ms" possui
acelerador e calcula SIM divisão exata por 50?
Transmite dados TX Buffer disponível dados do tacógrafo
do Tacógrafo SIM e Tacógrafo setado?
NÃO
NÃO
O valor de "ms" possui Calcula velocidade

divisão exata por 20? SIM do motor
TX Buffer disponível Transmite leitura
e Condições Ambiente da temperatura
setado? SIM ambiente
NÃO
NÃO
FIM
Transmite dados TX Buffer Disponível

da economia de e Economia de Comb.
combustível SIM setado?
NÃO
TX Buffer disponível
Transmite leitura
e Desconhecido
SIM desconhecida
setado?
NÃO
NÃO
46
NÃO
NÃO Existe solicitação

de menu?
SIM
Qual menu
foi solicitado? Taxa de Transmissão
Modo de Operação
Enquanto não for Configura

pressionado ENTER ENTER Taxa
pressionado ENTER ENTER Modo
Pressionado
Pressionado
Tecla Pressionada?
Tecla Pressionada? NÃO
NÃO
LEFT RIGHT ENTER

LEFT RIGHT ENTER
Decrementa Incrementa Sinaliza ENTER

taxa taxa Pressionado
modo modo Pressionado
Delay 200 ms
Delay 200 ms
#INT_EXT
Seta solicitação
de menu
Enquanto ENTER
estiver sendo pressionado
Usuário Pressionou Usuário Pressionou

LEFT ou RIGHT? SIM LEFT ou RIGHT?
NÃO
Reseta Flags
Define solicitação de
menu Saída
FIM

47
7.2.11.2 NÓ RX
O nó RX é o responsável pela recepção, decodificação e transmissão dos dados lidos, em

conformidade com o fluxograma mostrado nas Figuras 19, 20 e 21, a seguir.
Início
Flag de nova Grava nova versão

versão setado? na memória de programa
Limpa memória I²C,

Inicia Firmware instalado
reseta Flags
Configuração
Recebeu Msg
CAN? NÃO
SIM
Verifica ID
O ID é válido? O modo é DEBUG?

NÃO NÃO
SIM
SIM
Decodifica Envia dados CSV

pela Serial
A Saída é
Display Serial ou Display?
Serial
Figura 20 – Fluxograma do Firmware do Nó RX (Parte 1 de 3)

Display 48
Serial
Usuário Pressionou Ativa Frame Usuário Pressionou

LEFT ou RIGHT? SIM Seguinte ou Anterior LEFT ou RIGHT? NÃO
NÃO SIM
Alterna entre dados

NÃO O tempo é maior Brutos e Formatados
ou igual a 1s?
SIM
Dados Brutos
ou Formatados?
Atualiza
visualização Formatados
Brutos
Envia dados Envia dados CSV

Formatados pela Serial pela Serial
Existe solicitação
de menu? SIM
NÃO

49
SIM
NÃO
Saída Qual menu

foi solicitado? Taxa de Transmissão
Modo de Operação

pressionado ENTER ENTER Taxa
pressionado ENTER ENTER Modo
Pressionado
Pressionado
Tecla Pressionada?
Tecla Pressionada? NÃO
NÃO
LEFT
LEFT RIGHT ENTER
RIGHT ENTER

taxa taxa Pressionado
modo modo Pressionado
Delay 200 ms
Enquanto não for

Delay 200 ms Delay 200 ms
pressionado ENTER ENTER
Pressionado
#INT_EXT
Tecla Pressionada?
NÃO Seta solicitação
de menu
LEFT
RIGHT ENTER
Enquanto ENTER
estiver sendo pressionado
menu menu Pressionado
Usuário Pressionou Usuário Pressionou

LEFT ou RIGHT? SIM LEFT ou RIGHT?
Reseta Flags
NÃO
Define solicitação de
menu Saída
FIM

50
8.0 TESTES E RESULTADOS
O projeto montado pode ser visualizado através da Figura 23, abaixo e os procedimentos de
ligação e operação encontram-se descritos no Apêndice A, deste trabalho. Optou-se por construir os
nós TX e RX em caixas separadas por ser mais fácil efetuar testes distintos em simultâneo. Enquanto
um aparelho é testado a bordo de um veículo, o outro pode ser testado com dispositivos capazes de
ler informações em um barramento com protocolo J1939. Os testes executados foram basicamente
três: comunicação entre os nós TX e RX, comunicação entre o nó TX com o módulo Teltonika
FM4200, e comunicação do nó RX com veículos comerciais.
Figura 23 - Protótipos TX (esquerda) e RX (direita)
8.1 Teste de comunicação entre os nós TX e RX
Este teste consistiu em ligar os dois aparelhos com o objetivo de verificar o funcionamento do
kit como um todo. Verificou-se que todos os sinais gerados pelo nó TX foram recebidos, e
decodificados pelo nó RX. Ao mesmo tempo, também se testou a capacidade do nó RX de transmitir
os dados recebidos através do canal serial. Todas as leituras recebidas foram transmitidas ao
computador com sucesso.
8.2 Teste de comunicação entre o nó TX e o módulo Teltonika FM4200
O módulo Teltonika FM4200 é um rastreador comercial, importado da Lituânia, com a

funcionalidade de leitura e decodificação CAN – J1939 embarcada. O teste consistiu em ligar o nó TX
neste módulo visando verificar sua capacidade de interação com dispositivos fabricados por terceiros.
Neste teste, configurou-se o rastreador da Teltonika para receber os parâmetros de Velocidade do
Veículo, Giros do Motor e Distância percorrida. Todos os sinais gerados foram corretamente lidos
pelo módulo da Teltonika, o que permite afirmar que o teste foi bem sucedido.
51
8.3 Teste de comunicação entre o nó RX e veículos comerciais
O teste de comunicação do nó RX, com veículos comerciais foi realizado a bordo dos
veículos Volvo FH 440, IVECO Stralis 380, Scania G380 e Mercedes Axor e consistiu na ligação do
nó TX ao conector da interface FMS ou junto ao conector do tacógrafo quando esta interface não
estava presente. Os resultados obtidos encontram-se listados na Tabela 4.
LEGENDA PGN VOLVO IVECO SCANIA MERCEDES

PARÂMETRO
NO DISPLAY (Hex) FH 440 Stralis 380 G380 Axor
Velocidade baseada na roda WBS FEF1  
Odômetro ODO FEC1    
Giros do motor ENS F004    
Velocidade no tacógrafo TGS FE6C    
Chave do Freio BRS FEF1  
Chave da Embreagem CLS FEF1  
Piloto Automático CCA FEF1 
Detector de Movimento VMD FE6C  
Carga Percentual do Motor EPL F003 
Posição do Acelerador AAP F003  
Temperatura do refrigerante
ECT FEEE  
do motor
Temperatura ambiente do ar AAT FEF5
Combustível total consumido ETF FEE9 
Taxa de Consumo de
FRT FEF2  
Combustível
Economia Instantânea de
IFE FEF2  
Combustível
Nível do Combustível FLV FEFC 
Consumo de Combustível em
HFC FD09
Alta Resolução
Detector de Excesso de
OVS FE6C   
Velocidade
Horímetro ERT FEE5
 - Leitura efetuada com sucesso.
Tabela 4 - Leituras efetuadas em veículos comerciais
Enquanto os modelos da Scania e IVECO mostraram-se bastante completos no sentido de

disponibilizar informações a terceiros, nos caminhões Volvo e Mercedes, verificou-se que apesar de
possuírem computadores de bordo capazes de mostrar a maioria dos parâmetros listados acima
poucos parâmetros encontravam-se codificados segundo o protocolo J1939. Nestes veículos efetuou-
se a leitura de diferentes PGNs, os quais não se encontram descritos pela norma SAE J1939-71. Isto
permite concluir que, ao menos, estes modelos possuem uma mescla entre a norma da Sociedade de
Engenheiros Automotivos e um protocolo próprio desenvolvido por estes fabricantes.
52
CONSIDERAÇÕES
O desenvolvimento deste projeto permitiu que se chegasse a um protótipo que atende todas
as especificações requisitadas pela Empresa Cielo Indústria Mecatrônica LTDA os quais incluem:
leitura e decodificação dos dados presentes no Barramento CAN conforme especificações da norma
SAE J1939, operação em modo listen e capacidade de receber novas versões de firmware e envio
das informações decodificadas através da conexão serial. De forma indireta, os meios utilizados para
a resolução do problema acabaram por desenvolver um segundo protótipo também de aplicação. O
nó TX agora é chamado de “Simulador J1939”, e tem sido utilizado para realização de testes tanto
com novos protótipos quanto com dispositivos de terceiros a utilizar o Protocolo J1939.
Os testes realizados mostraram que, no momento, apenas três parâmetros são unanimidade
entre os fabricantes testados: velocidade do veículo, odômetro e giros do motor. Ainda é necessário
efetuar testes de bordo em veículos de outros fabricantes. Todavia, nos veículos testados pode-se
concluir que ao menos três parâmetros já podem ser adquiridos diretamente dos instrumentos
embarcados ao veículo.
O dispositivo projetado, com relação aos parâmetros lidos, possibilitou uma série de
vantagens verificadas na prática as quais incluem:
 Eliminação de dispositivos de aquisição de dados a parte, bem como sua calibração e

manutenção;
 Eliminação de divergências entre as leituras do veículo e da central de monitoramento;
 Redução nos custos do equipamento, proporcional ao número de dispositivos
secundários eliminados;
 Facilidade e rapidez na instalação, uma vez que além da alimentação apenas dois fios
adicionais necessitam ser conectados ao veículo;
 Capacidade de atualização remota de firmware.
No entanto, o decodificador de dados desenvolvido ainda possui uma demanda para

expansão. Por esta razão sugere-se que futuros projetos possam incluir também o Protocolo ISO
11898, utilizado em veículos de passeio, assim como protocolos próprios de montadoras como a
Mercedes e a Volvo, podendo inclusive detectar automaticamente o tipo de linguagem a circular em
um barramento qualquer quando conectado.
53
REFERÊNCIAS
[1] AXIOMATIC. Q&A - What is SAE J1939. Missauga, Canada. 2006.
[2] BAKER, B. C. Ease into the Flexible CANbus Network. [S.l.], Application Note. Microchip Technology
Inc. 2003.
[3] CAN IN AUTOMATION (CIA). CAN in Automation. Disponível em:

<http://www.can-cia.org/index.php?id=systemdesign-can>. Acesso em: 23 ago. 2011.
[4] CANNEWSLETTER.COM. J1939 Referências. Disponível em:

<http://www.copperhillmedia.com/cannewsletter/j1939Referências1.html>. Acesso em: 23 ago. 2011.
[5] CIELO INDÚSTRIA MECATRÔNICA. Catálogo de Produtos, 2011. Disponível em:

<http://www.cielo.ind.br/~grupocielo/br/industria/produtos.php>. Acesso em: 08 set. 2011.
[6] FAIRCHILD SEMICONDUCTOR. 3-Terminal 1A Positive Voltage Regulator. Datasheet Catalog,

2011. Disponível em: <http://www.datasheetcatalog.org/datasheets/228/390068_DS.pdf>. Acesso em:
2011 set. 15.
[7] FMS-STANDARD. FMS-Standard Interface Description, 2011. Disponível em:

<http://www.fms-standard.com/>. Acesso em: 03 set. 2011.
[8] GUIMARÃES, A. D. A. Eletrônica Automotiva Embarcada. São Paulo: Érica, 2007.
[9] HODAC, I. Letter to the European Institutes. FMS-Standards, 2004. Disponível em:
<http://www.fms-standard.com/down_load/letter_acea.pdf>. Acesso em: 03 set. 2011.
[10] JUNGER, M. Introduction to J1939. Stuttgart, Alemanha. 2010.
[11] KOURI, M. G. Definição de requisitos para um sistema de monitoramento de veículos no transporte

rodoviário de cargas. Escola Politécnica da Universidade de São Paulo. São Paulo. 2007.
[12] LOIOLA, R. Como Funciona o Rastreamento de Caminhões Via Satélite? Revista Mundo Estranho,
Editora Abril, 2011.
[13] LOPES, C. A. C. CAN - Controller Area Network. Universidade Estadual de Londrina. Londrina-PR.
2009.
[14] NATIONAL INSTRUMENTS. Controller Area Network (CAN) Overview. National Instruments, 2011.
Disponível em: <http://zone.ni.com/devzone/cda/tut/p/id/2732>. Acesso em: 25 ago. 2011.
[15] PAZUL, K. AN713 - Controller Area Network (CAN) Basics. Microchip Technology Inc., 2002.
[16] RICHARDS, P. AN228 - A CAN Physical Layer Discussion. Microchip Technology Inc., 2002.
[17] SIMMA SOFTWARE. Introduction to SAE J1939. Terre Haute, EUA. 2009.
[18] SOCIETY OF AUTOMOTIVE ENGINEERS. SAE J1939-21 - Data Link Layer. [S.l.]. 2001.
[19] SOCIETY OF AUTOMOTIVE ENGINEERS. SAE J1939-81 - Network Management. [S.l.]. 2003.
54
[20] SOCIETY OF AUTOMOTIVE ENGINEERS. SAE J1939 - Recommended Practice for a Serial Control
and Communications Vehicle Network. [S.l.]. 2005.
[21] SOCIETY OF AUTOMOTIVE ENGINEERS. SAE J1939-71 - Vehicle Application Layer. [S.l.]. 2006.
[22] SOUSA, L. B. D. Redes de Computadores, Dadoz, Voz e Imagem. In: SOUSA, L. B. D. Redes de
Computadores, Dadoz, Voz e Imagem. São Paulo: Érica, 1999. p. 60.
[23] SOUZA, V. A. Introdução ao CAN. Cerne Tecnologia, 2011. Disponível em:

<http://www.cerne-tec.com.br/Intro_CAN.pdf>. Acesso em: 25 ago. 2011.
[24] TANENBAUM, A. S. Redes de Computadores. São Paulo: Pearson Prentice Hall, 2011.
[25] TECHTARGET. What is Transceiver?, 2011. Disponível em:

<http://searchnetworking.techtarget.com/definition/transceiver>. Acesso em: 17 set. 2011.
[26] TISBURY MOTORS LTD. Modern Vehicles. Disponível em:

<http://www.tisburymotors.co.uk/Modern_Vehicles.html>. Acesso em: 18 ago. 2011.
[27] VARGAS, M. T. Computador de Bordo Automotivo. Universidade de Passo Fundo. Passo Fundo, RS.
2007.
[28] VOSS, W. A Comprehensible Guide to J1939. Greenfield, EUA. 2008.
[29] YOUR ELECTRONICS OPEN SOURCE. What a microcontroller Bootloader is and how it works?,
2008. Disponível em: <http://dev.emcelettronica.com/what-microcontroller-bootloader-and-how-it-
works>. Acesso em: 03 dez. 2011.
[30] WIKIPEDIA. Fleet Management System, 2011. Disponível em:

<http://en.wikipedia.org/wiki/Fleet_Management_System>. Acesso em: 03 set. 2011.
55
APÊNDICE A
MANUAIS DE OPERAÇÃO
SIMULADOR J1939 (NÓ TX)
1 - Ligando o aparelho
Com a chave localizada na parte traseira na posição „O‟ alimente o protótipo de

demonstração com uma tensão de 12 Volts, através do plugue padrão ou através dos bornes de
alimentação na parte traseira. Depois de alimentado a chave localizada na parte traseira do aparelho
deverá ser posicionada para a posição „I‟.
2 – Conectando a uma rede CAN
Para conectar o Simulador a uma rede CAN, ligue os bornes CANH e CANL, localizados na
parte frontal do aparelho, respectivamente aos conectores CANH e CANL da rede de destino. Por
padrão, este dispositivo trabalha apenas no modo NORMAL, enviando mensagens continuamente ao
barramento.
3 – Lista de abreviaturas utilizadas no dispositivo
ABREVIATURA SIGNIFICADO LITERAL SIGNIFICADO TRADUZIDO

WBS Wheel Based Speed Velocidade baseada na roda
ODO Odometer Odômetro
ENS Engine Speed Giros do motor
TGS Tachograph Speed Velocidade lida pelo tacógrafo
BRS Brake Switch Chave do pedal do freio
CLS Clutch Switch Chave do pedal da embreagem
CCA Cruise Control Active Acionamento do piloto automático
VMD Vehicle Motion Detect Detecção de movimento do veículo
APP Accelerator Pedal Position Posição do pedal do acelerador
ECT Engine Coolant Temperature Temperatura do refrigerante do motor
AAT Ambient Air Temperature Temperatura ambiente
ETF Engine Total Fuel Total de combustível consumido
FRT Fuel Rate Taxa de consumo de combustível
IFE Instantaneous Fuel Economy Economia instantânea de combustível
FLV Fuel Level Nível do combustível
56
Consumo de combustível em alta

HFC High Resolution Fuel Consumption
resolução
OVS Overspeed Excesso de velocidade
ERT Engine Running Time Horímetro
4 – Visualizando e ajustando parâmetros
Para visualizar os diferentes parâmetros gerados pelo dispositivo, navegue através dos
botões esquerda () e direita () no topo do aparelho. Apesar de apenas dois parâmetros serem
mostrados a cada vez, o dispositivo envia continuamente todos os parâmetros gerados através do
barramento.
Para ajustar:
a) Velocidade: gire o potenciômetro „VEL‟ localizado à direita da parte frontal;
b) Posição do Pedal do Acelerador: gire o potenciômetro „ACEL‟ localizado à esquerda no
painel frontal;
c) Piloto automático: mude o estado da chave „CCA‟ na parte superior do dispositivo.
„O‟ – Desligado „I‟ - Ligado
d) Pedal do Freio: mude o estado da chave „BRS‟ na parte superior do dispositivo.
„O‟ – Desligado „I‟ - Ligado
e) Pedal da Embreagem: mude o estado da chave „CLS‟ na parte superior do dispositivo.
„O‟ – Desligado „I‟ – Ligado
f) Demais Parâmetros: As alterações em outros parâmetros, que não estão incluídos, nos
itens anteriores ocorrem de maneira indireta, como por exemplo, para alterar o número de
giros do motor por minuto, é necessário alterar a posição do pedal do acelerador.
5 – Acendendo o Backlight
Para acender ou apagar o backlight do display apenas mude o estado da chave „BCKL‟,
localizada na parte superior do dispositivo.
6 – Gravando um novo Firmware
Para gravar um novo Firmware, insira o cabo de seu gravador na entrada localizada na parte
frontal do aparelho. Observando a pinagem:
1 2 3 4 5
PGC PGD GND VCC VPP

57
DECODIFICADOR J1939 (NÓ RX)
1 - Ligando o aparelho
Com a chave localizada na parte traseira na posição „O‟ alimente o protótipo de

demonstração com uma tensão de 12 Volts, através do plugue padrão ou através dos bornes de
alimentação na parte traseira. Depois de alimentado a chave localizada na parte traseira do aparelho
deverá ser posicionada para a posição „I‟.
2 – Conectando a uma rede CAN
Para conectar o Simulador a uma rede CAN, ligue os bornes CANH e CANL, localizados na
parte frontal do aparelho, respectivamente aos conectores CANH e CANL da rede de destino. Por
padrão, este dispositivo trabalha apenas no modo NORMAL, enviando mensagens continuamente ao
barramento.
3 – Lista de abreviaturas utilizadas no dispositivo
ABREVIATURA SIGNIFICADO LITERAL SIGNIFICADO TRADUZIDO

WBS Wheel Based Speed Velocidade baseada na roda
ODO Odometer Odômetro
ENS Engine Speed Giros do motor
TGS Tachograph Speed Velocidade lida pelo tacógrafo
BRS Brake Switch Chave do pedal do freio
CLS Clutch Switch Chave do pedal da embreagem
CCA Cruise Control Active Acionamento do piloto automático
VMD Vehicle Motion Detect Detecção de movimento do veículo
APP Accelerator Pedal Position Posição do pedal do acelerador
ECT Engine Coolant Temperature Temperatura do refrigerante do motor
AAT Ambient Air Temperature Temperatura ambiente
ETF Engine Total Fuel Total de combustível consumido
FRT Fuel Rate Taxa de consumo de combustível
IFE Instantaneous Fuel Economy Economia instantânea de combustível
FLV Fuel Level Nível do combustível
Consumo de combustível em alta
HFC High Resolution Fuel Consumption
resolução
OVS Overspeed Excesso de velocidade
ERT Engine Running Time Horímetro
58
5 – Acendendo o Backlight
Para acender ou apagar o backlight do display apenas mude o estado da chave „BCKL‟,
localizada na parte superior do dispositivo.
6 – Gravando um novo Firmware
Para gravar um novo Firmware, insira o cabo de seu gravador na entrada localizada na parte
frontal do aparelho. Observando a pinagem:
1 2 3 4 5
PGC PGD GND VCC VPP
7 – Alterando as configurações de saída
Para alterar as configurações de saída, pressione e solte o botão ENTER, localizado na parte
superior do aparelho. Selecione o modo através das demais teclas de navegação e novamente
pressione ENTER.
O dispositivo pode fornecer três tipos distintos de saída.
a) Serial: Quando este modo estiver selecionado, a saída dos dados decodificados será
dada através do conector DB-9, localizado na parte frontal do aparelho a uma taxa de
transmissão de 57,600 kbps. Neste modo, se as teclas DIREITA, ou ESQUERDA forem
pressionadas, os dados enviados serão alternados entre DADOS FORMATADOS, isto é,
decodificados ou DADOS BRUTOS, que representam a leitura literal do barramento cujo
formato de saída obedece ao padrão CSV (comma separated values);
b) Display: Este é o modo padrão de saída do aparelho. Os dados lidos são mostrados
diretamente no display 4x16, localizado na parte superior do aparelho;
c) Debug: Neste modo, todas as mensagens elencadas na tabela do item 3 são

decodificadas e mostradas diretamente no display. Qualquer mensagem detectada no
barramento que não faça parte daquela tabela é enviada via porta serial obedecendo à
formatação CSV.
8 – Alterando a configuração da taxa de transmissão
Para alterar a velocidade de transmissão, segure o botão DIREITA pressionado e dê um

toque no botão ENTER. O menu de configuração da taxa de transmissão irá se abrir. Selecione a
taxa desejada movimentando o cursor com as teclas ESQUERDA e DIREITA. E pressione ENTER.
59
9 – Alterando o modo de operação do barramento

Para alterar a velocidade de transmissão, segure o botão ESQUERDA pressionado e dê um
toque no botão ENTER. O dispositivo possui três opções de configuração do barramento, selecione a
opção desejada e novamente pressione ENTER.
Os modos possíveis são:
a) Desligado: O dispositivo não está apto a receber mensagens do barramento;

b) Normal: O dispositivo é capaz de receber mensagens e confirmar o recebimento através
do envio de bits de acknowledgement;
c) Listen Only: o dispositivo apenas recebe mensagens do barramento, porém opera sem
enviar dado algum, nem mesmo bits de acknowledgement, e por esta razão este modo
apenas pode ser usado em uma rede onde já existam pelo menos dois em operação.
60
ANEXO A
Lista de Materiais do Circuito Elétrico
Lista de Materiais para Decodificador CAN.DSN
Título do Projeto : DecodificadorCAN.DSN

Autor : Emanuel Nunes Baldissera
Projeto criado em : terça-feira, 13 de setembro de 2011
Última modificação em : domingo, 4 de dezembro de 2011
Total de Partes no Projeto : 72
18 Resistores
Qtd: Referências Valor Observações
14 R1-R5, R9-R17 10k
2 R6, R18 560R
2 R7, R8 120R
10 Capacitores
4 C1-C4 1uF
2 C5, C9 1000uF/35V
2 C6, C11 100u
2 C7, C12 100nF
9 Circuitos Integrados
2 U1, U4 PIC18F2580 Microcontrolador
1 U2 MAX232 Transceptor RS-232
2 U3, U5 MCP2551 Transceptor CAN
2 U6, U9 7805 Regulador de Tensão
1 U7 24LC512 Memória I²C
1 U8 DS1822 Sensor de Temperatura
6 Diodes
4 D1, D2, D4, D6 1N4007
2 D3, D5 LED
61
29 Outros
2 FU1, FU2 150mA
1 J1 CONN-D9F
2 J2, J3 TBLOCK-I5
4 J4, J5, J8, J9 PIN
2 J6, J10 ENTRADA
2 J7, J11 TERRA
1 LCD1 LM041L Display 4x16
1 LCD2 LM016L Dispay 2x16
4 RV1-RV4 5k
10 S1, S3-S11
Domingo, 4 de dezembro de 2011 19:31:04

62
ANEXO B
Descrição da Interface FMS em conformidade com SAE J1939
63

Decodificador de Dados Usando Protocolo CAN Padrao SAE J1939 PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Decodificador de Dados Usando Protocolo CAN Padrao SAE J1939 PDF

Enviado por

Direitos autorais:

Formatos disponíveis

1

UNIVERSIDADE DE PASSO FUNDO

Emanuel Nunes Baldissera

DECODIFICADOR DE DADOS USANDO PROTOCOLO

Emanuel Nunes Baldissera

DECODIFICADOR DE DADOS USANDO PROTOCOLO

Projeto de Graduação apresentado ao curso de

Emanuel Nunes Baldissera

DECODIFICADOR DE DADOS USANDO PROTOCOLO CAN – PADRÃO SAE J1939

Projeto de Graduação apresentado ao curso de

Aprovado em ___ de ________________ de ________.

Dedico este trabalho a quem possa encontrar nestas

Agradeço a Deus e a minha família em primeiro lugar.

(Slogan de campanha do presidente norte-americano

Os sistemas de rastreamento de veículos disponibilizados comercialmente no Brasil,

No cenário nacional, a grande parte dos rastreadores comercializados ainda é acompanhada

Em 2002, seis dos maiores fabricantes europeus de veículos pesados acordaram em

A fim de aproveitar a tecnologia embarcada ao veículo, este projeto trata do desenvolvimento

A solução projetada neste trabalho compreende dois dispositivos dotados de hardware e

Palavras-Chave: Decodificador, Rastreador, Protocolo CAN, SAE J1939, Interface FMS.

1.0 INTRODUÇÃO ................................................................................................................................ 14

2.0 SISTEMAS DE MONITORAMENTO E SEGURANÇA VEICULAR ................................................ 15

3.0 MÓDULOS ELETRÔNICOS ........................................................................................................... 17

3.1 Comunicação entre as ECUs ...................................................................................................... 17

3.2 Rastreadores comerciais ............................................................................................................. 17

3.2 Atualização remota ...................................................................................................................... 18

4.0 REDES DE DADOS ........................................................................................................................ 19

4.1 Topologias de Redes de Dados .................................................................................................. 19

4.2 Modelo OSI para Protocolos de Comunicação ........................................................................... 20

4.3 Protocolo de Comunicação de Dados ......................................................................................... 21

4.4 Uso de Protocolos em Redes Automotivas ................................................................................. 22

5.0 CONTROLLER AREA NETWORK (CAN) ...................................................................................... 23

5.1 Conceituação básica ................................................................................................................... 24

5.1.1 Características Físicas .......................................................................................................... 24

5.1.2 Características lógicas .......................................................................................................... 26

5.1.2.1 Formato das mensagens ................................................................................................ 26

5.1.2.2 Arbitração ....................................................................................................................... 27

5.1.3 Padrões Existentes ............................................................................................................... 28

6.0 PADRÃO SAE J1939 ...................................................................................................................... 29

6.1 Grupos de Parâmetros (PG) ........................................................................................................ 29

6.1 Formato das Mensagens ............................................................................................................. 29

6.2 Campo de Dados ......................................................................................................................... 31

6.3 FMS (Fleet Management System) Standard ............................................................................... 32

7.0 PROJETO DO DECODIFICADOR DE DADOS .............................................................................. 34

7.1 Especificações do Projeto ........................................................................................................... 34

7.2 Componentes de Hardware ......................................................................................................... 35

7.2.1 Composição do Nó TX .......................................................................................................... 35

7.2.2 Composição do Nó RX ......................................................................................................... 36

7.2.3 Displays LCD e botões de comando..................................................................................... 36

7.2.4 Simuladores de Acionamentos e Medição da Temperatura ................................................. 37

7.2.5 Interface de Comunicação Serial .......................................................................................... 37

7.2.6 Interface CAN ........................................................................................................................ 37

7.2.6.1 Controlador MCP 2510 ................................................................................................... 38

7.2.6.2 Controlador MCP 2515 ................................................................................................... 38

7.2.6.3 Transceptor MCP 2551 .................................................................................................. 38

7.2.6.4 Escolha da Interface CAN .............................................................................................. 38

7.2.7.1 Microcontrolador AT91SAM7A3-AU.............................................................................. 39

7.2.7.2 Microcontrolador DsPic33FJ64GP804 ........................................................................... 39

7.2.7.3 Microcontrolador PIC18F2580 ....................................................................................... 40

7.2.7.4 Escolha do Microcontrolador .......................................................................................... 40

7.2.8 Memória I²C .......................................................................................................................... 40

7.2.9 Fonte de Alimentação ........................................................................................................... 41

7.2.10 Esquemático de Hardware .................................................................................................. 41

Aprovado em _ de ______ de .