Decodificador de dados usando Protocolo CAN - Padrão SAE J1939

1

UNIVERSIDADE DE PASSO FUNDO

Emanuel Nunes Baldissera

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

Passo Fundo 2011

2

Emanuel Nunes Baldissera

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

Emanuel Nunes Baldissera

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!” 

de campanha do presidente norte-americano Barack Obama - 2008). (Slogan 

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 I nterface 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 en tre as ECUs ...................................................................................................... ...................................................................................................... 17 3.2 Rastreadores R astreadores comerciais .................................................................................. ............................................................................................................. ........................... 17 3.2 Atualização remota rem ota ........................................................................................... ...................................................................................................................... ........................... 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 For mato das mensagens m ensagens ..................................................................... ................................................................................................ ........................... 26 5.1.2.2 Arbitração ....................................................................................................................... ....................................................................................................................... 27 5.1.3 Padrões Existentes ............................................................................................................ ............................................................................................................... ... 28 6.0 PADRÃO SAE J1939 J1 939 ...................................................................................................................... ...................................................................................................................... 29 6.1 Grupos de Parâmetros Parâm etros (PG) ............................................................... ........................................................................................................ ......................................... 29 6.1 Formato Form ato das Mensagens .................................................................................. ............................................................................................................. ........................... 29 6.2 Campo C ampo de Dados .......................................................... ......................................................................................................................... ............................................................... 31 6.3 FMS (Fleet Management System ) Standard ............................................................... ............................................................................... ................ 32 7.0 PROJETO DO DECODIFICADOR DE DADOS D ADOS .............................................................. .............................................................................. ................ 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 Tem peratura ................................................. 37 7.2.5 Interface de Comunicação Serial ............................................................ .......................................................................................... .............................. 37 7.2.6 Interface CAN......................................................... ........................................................................................................................ ............................................................... 37 7.2.6.1 Controlador MCP 2510 2 510 .......................................................... ................................................................................................... ......................................... 38 7.2.6.2 Controlador MCP 2515 2 515 .......................................................... ................................................................................................... ......................................... 38 7.2.6.3 Transceptor MCP 2551 .................................................................................................. .................................................................................................. 38 7.2.6.4 Escolha da Interface Interf ace CAN .............................................................................................. .............................................................................................. 38 7.2.7 Microcontroladores ............................................................ ................................................................................................................ .................................................... 39 7.2.7.1 Microcontrolador AT91SAM7A3-AU................................................... AT91SAM7A3-AU.............................................................................. ........................... 39 7.2.7.2 Microcontrolador M icrocontrolador 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 c omunicação entre os nós TX e RX ............................................................. ............................................................................. ................ 50 8.2 Teste de comunicação c omunicação entre o nó TX e o módulo Teltonika T eltonika FM4200 ......................................... 50 8.3 Teste de comunicação c omunicaçã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 I nterface FMS em conformidade com SAE J1939 ...................................... 62

10

LISTA DE FIGURAS

Figura 1 – Esquema genérico de um rastreador comercial com ercial ............................................................. .................................................................. ..... 18 Figura 2 – Comparativo entre uma um a rede sem CAN e uma rede com CAN ........................................... 23 Figura 3 – Mensagem transmitida transm itida 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 ( Parte 1 de 3) ............................................................ 44 Figura 18 – Fluxograma do Firmware do Nó TX (Parte ( Parte 2 de 3) ............................................................ 45 Figura 19 – Fluxograma do Firmware do Nó TX (Parte ( Parte 3 de 3) ............................................................ 46 Figura 20 – Fluxograma do Firmware do Nó RX (Parte 1 de 3) ........................................................... 47 Figura 21 – Fluxograma do Firmware do Nó RX (Parte 2 de 3) ........................................................... 48 Figura 22 – Fluxograma do Firmware do Nó RX (Parte 3 de 3) ........................................................... 49 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 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 Unidade

Significado Literal

Significado Traduzido

°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

ASCII

American Standard Code for Information  Interchange 

Código Padrão Americano para o 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

NMEA

National Marine Electronics Association 

Associação Nacional de Eletrônica da 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 caracterizase 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

Topologia Barramento

Topologias de Rede Descrição 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

Camada 7 - Aplicação

Camadas do Modelo de Referência OSI 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 computador, permitindo que estes sejam escritos apenas uma vez e utilizados em diferentes tipos de redes.

6 - Apresentação

Esta camada é a responsável pela tradução dos dados para um formato padrã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.

5 - Sessão

Esta é a camada responsável por estabelecer, manter e encerrar sessões na rede. É ela quem administra o reconhecimento de nomes e algumas características de acesso, como quando e por quanto tempo um dispositivo pode transmitir.

4 - Transporte

Esta camada é responsável pela preparação dos dados a serem transferidos. É 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

3 – Rede

2 – Enlace

os dispositivos conectados nesta e prover direções de qualquer ponto a 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 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).

1 – Física

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 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, ISO11592 (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 ISO 11898 & ISO 11519-2

CAN 2.0 SAE J1939

J1859 Class 2

J1850 SCP

J1850 PCI

Instituição diretamente relacionada

SAE & ISO

SAE

GM

Ford

Chrysler

Aplicação principal

Controle e diagnóstico

Controle e diagnóstico

Controle e diagnóstico

Controle e diagnóstico

Tipo de barramento

Par trançado

Par trançado

Fio único

Codificação dos sinais Detecção de erros

NRZ CRC 10 kbps – 1 Mbps

NRZ CRC

VPW CRC

Controle e diagnóstico Par trançado PWM CRC

250 kbps

10,4 kbps

41,6 kbps

10,4 kbps

Taxa de transmissão

Fio único VPW CRC

Quantidade de dados

0 – 8 Bytes

8 Bytes

0 – 8 Bytes

0 – 8 Bytes

0 – 10 Bytes

Comprimento máximo do barramento

40 metros (p/ 1 Mbps)

40 metros (p/ 1 Mbps)

35 metros

35 metros

35 metros

Quantidade máxima de nós na rede

32

32

32

32

32

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  – utilizados em sistemas de airbag  e ainda Drive-  do conceito “computador sobre rodas”, Safety Bus  –  – aplicados a sistemas eletromecânicos que substituíram os sistemas puramente mecânicos, by-wire  – 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 nava is 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-  ), o campo então recebe o nome de PDU2 [10]. peer ), 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 

SPN 184

Economia Instantânea 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

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 1-2 3-4 5-6 7

Comprimento 2 bytes 2 bytes 2 bytes 1 byte

Nome do Parâmetro Taxa de Consumo de Combustível do Motor Ec. Instantânea de Combustível do Motor Economia Média de Combustível Posição do Acelerador do Motor

SPN 183 184 185 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 devese 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 16x2

MICROCONTROLADOR

CAN TRANSCEPTOR

BOTÕES DE NAVEGAÇÃO

CHAVE PEDAL DO FREIO

BARRAMENTO 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 CAN

INTERFACE CAN

MEMÓRIA I²C

MICROCONTROLADOR

INTERFACE SERIAL

COMPUTADOR

DISPLAY LCD 16x4

BOTÕES DE NAVEGAÇÃO

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  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, ). Possui três buffers  dedicados à transmissão com Enhanded Legacy e  FIFO (First Input First Output ). 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 IN 12~24 ENTRADA

FU1

7805

D1 1

5VDC

VI

VO

VCC

3

      D       N       G

1N4007

D2

C9

C10

1N4007

100uF

100nF

      2

R6 C11 10u

C12

PIN

560R

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

    %     0     5

RV3

    1    2    3     4    5    6      D     C    2    2     2      N     C     E     C      D      G      V     V     G      G      P      P

VPP2 VCC GND PGD2 PGC2

1 2 3 4 5

     S     D      E     0    1    2    3    4    5    6    7      S     D      E      S     W      V     V     V      R     R     E      D     D     D     D     D     D     D     D

VCC

VCC

J3

RV4

VCC

VCC

S3

SPEED

    %     0     5

5k

VCC

RV2

S4      H      C      T      U      L      C

     E      K      A      R      B

TBLOCK-I5

    7    8    9    0    1    2    3    4     1    1    1    1    1     0    1    2    3      T     T     T     T      D     D      D     D

VCC

S5      E      S      I      U      R      C

R13

R14

R15

10k

10k

10k

VE2 ACCEL

    %     0     5

5k 11 12 13 14 SDAB 15 16 17 18 VPP2 1

5k

U4 RC0/T1OSO/T13CKI RA0/AN0 RC1/T1OSI RA1/AN1 RC2/CCP1 RA2/AN2/VREFRC3/SCK/SCL RA3/AN3/VREF+ RC4/SDI/SDA RA4/T0CKI RC5/SDO RA5/AN4/SS/HLVDIN RC6/TX/CK RA6/CLKO/OSC2 RC7/RX/DT RA7/CLKI/OSC1

2 3 4 5 6 7 10 9

ACCEL SPEED BRAKE CLUTCH CRUISE

RE3/VPP/MCLR

21 22 23 24 25 26 27 28

INTOB

RB0/INT0/AN10 RB1/INT1/AN8 RB2/INT2/CANTX RB3/CANRX RB4/KI0/AN9 RB5/KBI1/PGM RB6//KBI2/PGC RB7/KBI3/PGD

VCC

VCC



S8

R10

R11

R12

10k

10k

10k

PIC18F2580 VCC

U5

3 CANTX 1 CANRX 4 RS

8

VCC TXD RXD RS

R7 J8

120R

CANH

7

CANL

6

J5

VREF

5

PIN

VCC

U8

PIN

VCC DQ GND

25.5

3 2 1

SDAB

DS1822

GND MCP2551 2

R5 10k

J10

FU1 CHAVE

ENTRADA

150mA

U9

D4

7805 1

VI

1N4007

D6

C5

1N4007

1000uF

     D      N      G     2

VO

VCC

3

R18 C6 100u

C7 100nF

J11

D5

TERRA

LED

Figura 15  – Esquemático de Hardware para o Nó TX 

560R

43

VCC

RV1 VEE

    %     0     5

LCD1 LM041L

VCC

VCC



INT0

S9

RIGHT

S10

S11

R2

R3

R4

10k

10k

10k

     S     D      E     0    1    2    3    4    5    6    7      S     D      E      S     W      V     V     V      R      R      E      D     D      D      D      D      D     D      D     1    2    3

    4    5    6

     D      C     E      C      D      N      C     E      G      G      G      V     V      P      P

    7    8    9    0    1    2    3    4     1    1    1    1    1     0    1    2    3      D     D      D      D

VCC

C1 U1

INT0 INT1 TXD RXD LEFT RIGHT PGC PGD

2 3 4 5 6 7 10 9

RA0/AN0 RC0/T1OSO/T13CKI RA1/AN1 RC1/T1OSI RA2/AN2/VREFRC2/CCP1 RA3/AN3/VREF+ RC3/SCK/SCL RA4/T0CKI RC4/SDI/SDA RA5/AN4/SS/HLVDIN RC5/SDO RA6/CLKO/OSC2 RC6/TX/CK RA7/CLKI/OSC1 RC7/RX/DT

21 22 23 24 25 26 27 28

RB0/INT0/AN10 RE3/VPP/MCLR RB1/INT1/AN8 RB2/INT2/CANTX RB3/CANRX RB4/KI0/AN9 RB5/KBI1/PGM RB6//KBI2/PGC RB7/KBI3/PGD

11 12 13 14 15 16 17 18

1

D0 D1 D2 SCK SDA D3 TX RX

C1+ TX 11 RX 12 10 9

U2

3

1uF

14 13 7 8

T1OUT R1IN T2OUT R2IN

1 VPP

CONN-D9F 1uF

C2-

C2

4

C4

2 6

VS+ VSC2+

5

1 6 2 7 3 8 4 9 5

1uF

C1-

T1IN R1OUT T2IN R2OUT

J1

C3

R9 10k

MAX232

1uF

PIC18F2580 VCC

J4

120R

PIN

J9

7 6

PIN

U3

3

R8

5

R16

VCC CANH CANL

TXD

1 TXD

RXD

4 RXD

RS

8 SLP

VREF

R17 U7

10k

10k

SCK SDA

6 5 7

GND MCP2551

2

J2

SCK SDA WP

A0 A1 A2

1 2 3

5 4 3 2 1

24LC512

R1

PGC PGD GND VCC VPP

TBLOCK-I5

10k

J6

S1 CHAVE

ENTRADA

FU2 150mA

U6

D1

7805 1

VI

1N4007

D2

C9

1N4007

1000uF

     D      N      G     2

VO

VCC

3

R6 C11 100uF

C12 100nF

J7

D3

TERRA

LED

Figura 16  – Esquemático de Hardware para o Nó RX 

560R

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 e Horímetro setado?

SIM

Transmite dados do Horímetro

NÃO Transmite dados do Nível do Combustível

SIM

Incrementa 1 ms

#INT_TIMER2

TX Buffer disponível e Nível do Comustível setado? Atingiu 1000 ms?

NÃO TX Buffer disponível C. Control / Velocidade setado?

Reseta contador SIM

Transmite dados de pedais, cruise control, SIM e velocidade baseada na roda

Inverte estado do LED e incrementa contador

NÃO

Transmite dados da velocidade do motor

SIM

Contador atingiu 180?

TX Buffer disponível e Engine Controller #2 setado? NÃO NÃO

TX Buffer disponível consumo de combustível setado?

SIM

Transmite dados do consumo de combustível

Calcula consumo, distância percorrida, e sinaliza flags

NÃO

Figura 17  – Fluxograma do Firmware do Nó TX (Parte 1 de 3)

SIM Incrementa Horímetro e sinaliza flag

45

Transmite leitura da velocidade SIM do motor

TX Buffer disponível e Engine Controller #1 setado?

NÃO

TX Buffer disponível Distância Percorrida setado?

O valor de "ms" possui divisão exata por 100? SIM

Transmite leitura do odômetro

Calcula taxa consumo de combustível e SIM adquire referência de velocidade

NÃO NÃO

Transmite dados do Tacógrafo SIM

Adquire referência de posição do acelerador e calcula dados do tacógrafo

TX Buffer disponível e Tacógrafo setado?

SIM

O valor de "ms" possui divisão exata por 50?

NÃO NÃO

TX Buffer disponível e Condições Ambiente setado?

SIM

Transmite leitura da temperatura ambiente

O valor de "ms" possui divisão exata por 20?

NÃO NÃO FIM Transmite dados da economia de combustível SIM

TX Buffer Disponível e Economia de Comb. setado?

NÃO

TX Buffer disponível e Desconhecido setado?

Transmite leitura desconhecida SIM

NÃO

Figura 18  – Fluxograma do Firmware do Nó TX (Parte 2 de 3)

Calcula velocidade do motor SIM

46

NÃO

Existe solicitação de menu?

SIM

Qual menu foi solicitado?

Taxa de Transmissão

Modo de Operação

Enquanto não for pressionado ENTER

ENTER Pressionado

Enquanto não for pressionado ENTER

Configura Modo

NÃO

NÃO

Decrementa modo

Configura Taxa

Tecla Pressionada?

Tecla Pressionada?

LEFT

ENTER Pressionado

RIGHT Incrementa modo

RIGHT

LEFT

ENTER

Decrementa taxa

Sinaliza ENTER Pressionado

Incrementa taxa

ENTER Sinaliza ENTER Pressionado

Delay 200 ms Delay 200 ms

#INT_EXT Seta solicitação de menu

Enquanto ENTER estiver sendo pressionado

Usuário Pressionou LEFT ou RIGHT? RIGHT?

Reseta Flags

NÃO Define solicitação de menu Saída

FIM

Figura 19  – Fluxograma do Firmware do Nó TX (Parte 3 de 3)

SIM

Usuário Pressionou LEFT ou RIGHT? RIGHT?

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 versão setado?

Grava nova versão na memória de programa

Inicia Firmware instalado

Limpa memória I²C, reseta Flags

Configuração

Recebeu Msg CAN?

NÃO

SIM Verifica ID

O ID é válido?

O modo é DEBUG? NÃO

NÃO

SIM Decodifica

Display

SIM Envia dados CSV pela Serial

A Saída é Serial ou Display?

Serial

Figura 20  – Fluxograma do Firmware do Nó RX (Parte 1 de 3)

48

Usuário Pressionou LEFT ou RIGHT?

Ativa Frame Seguinte ou Anterior SIM

NÃO

NÃO

Usuário Pressionou LEFT ou RIGHT?

NÃO

SIM Alterna entre dados Brutos e Formatados

O tempo é maior ou igual a 1s?

SIM Dados Brutos ou Formatados? Atualiza visualização

Formatados Brutos Envia dados Formatados pela Serial

Envia dados CSV pela Serial

Existe solicitação de menu?

SIM

NÃO

Figura 21  – Fluxograma do Firmware do Nó RX (Parte 2 de 3)

49

Saída

Qual menu foi solicitado?

Taxa de Transmissão

Modo de Operação Enquanto não for pressionado ENTER

Enquanto não for pressionado ENTER

Configura Modo

ENTER Pressionado

Tecla Pressionada?

Tecla Pressionada?

NÃO

NÃO

LEFT

Decrementa modo

ENTER Pressionado

Configura Taxa

LEFT RIGHT Incrementa modo

RIGHT

E NT E R Decrementa taxa

Sinaliza ENTER Pressionado

Incrementa taxa

E NT E R Sinaliza ENTER Pressionado

Delay 200 ms Enquanto não for pressionado ENTER

Delay 200 ms

Delay 200 ms

ENTER Pressionado

#INT_EXT Tecla Pressionada? NÃO

Seta solicitação solicitação de menu LEFT

Decrementa menu

RIG HT Incrementa menu

ENTER Enquanto ENTER estiver sendo pressionado

Sinaliza ENTER Pressionado

Usuário Pressionou LEFT ou RIGHT? Reseta Flags

SIM

NÃO Define solicitação de menu Saída

FIM

Figura 22  – Fluxograma do Firmware do Nó RX (Parte 3 de 3)

Usuário Pressionou LEFT ou RIGHT?

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 NO DISPLAY

PGN (Hex)

Velocidade baseada na roda Odômetro Giros do motor Velocidade no tacógrafo

WBS ODO ENS TGS

FEF1 FEC1 F004 FE6C

Chave do Freio Chave da Embreagem Piloto Automático Detector de Movimento

BRS CLS CCA VMD

FEF1 FEF1 FEF1 FE6C

Carga Percentual do Motor Posição do Acelerador Temperatura do refrigerante refrigerante do motor Temperatura ambiente do ar

EPL AAP

F003 F003





ECT

FEEE





AAT

FEF5

ETF

FEE9

FRT

FEF2





IFE

FEF2





FLV

FEFC

HFC

FD09

OVS

FE6C

ERT

FEE5

PARÂMETRO

Combustível total consumido Taxa de Consumo de Combustível Economia Instantânea de Combustível Nível do Combustível Consumo de Combustível em Alta Resolução Detector de Excesso de Velocidade Horímetro

VOLVO FH 440

IVECO Stralis 380

SCANIA G380

MERCEDES Axor



































 



 











- 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 efetuouse 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: . Acesso em: 23 ago. 2011. [4] CANNEWSLETTER.COM. J1939 Referências . Disponível em: . Acesso em: 23 ago. 2011. [5] CIELO INDÚSTRIA MECATRÔNICA. Catálogo de Produtos, 2011. Disponível em: . Acesso em: 08 set. 2011. [6] FAIRCHILD SEMICONDUCTOR. 3-Terminal 1A Positive Voltage Regulator. Datasheet Catalog, 2011. Disponível em: . Acesso em: 2011 set. 15. [7] FMS-STANDARD. FMS-Standard Interface Description, 2011. Disponível em: . 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: . 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: . 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. ENGINEERS. SAE J1939-21 - Data Link Layer. [S.l.]. 2001. [19] SOCIETY OF AUTOMOTIVE ENGINEERS. ENGINEERS. SAE J1939-81 - Network Management. [S.l.]. 2003.

54

[20] SOCIETY OF AUTOMOTIVE ENGINEERS. ENGINEERS. SAE J1939 - Recommended Practice for a Serial Control  and Communications Vehicle Network. [S.l.]. 2005. [21] SOCIETY OF AUTOMOTIVE ENGINEERS. 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: . 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: . Acesso em: 17 set. 2011. [26] TISBURY MOTORS LTD. Modern Vehicles . Disponível em: . 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. SOURCE. What a microcontroller Bootloader is and how it works? , 2008. Disponível em: . Acesso em: 03 dez. 2011. [30] WIKIPEDIA. Fleet Management System, 2011. Disponível em: . 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‟.

 – Conectando a uma rede CAN  2  –

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.

 – Lista de abreviaturas utilizadas no dispositivo  3  –

ABREVIATURA WBS ODO ENS TGS BRS CLS CCA VMD APP ECT AAT ETF FRT IFE FLV

SIGNIFICADO LITERAL Wheel Based Speed  Odometer  Engine Speed  Tachograph Speed  Brake Switch  Clutch Switch  Cruise Control Active  Vehicle Motion Detect  Accelerator Pedal Position  Engine Coolant Temperature  Ambient Air Temperature  Engine Total Fuel  Fuel Rate  Instantaneous Fuel Economy  Fuel Level 

SIGNIFICADO TRADUZIDO Velocidade baseada na roda Odômetro Giros do motor Velocidade lida pelo tacógrafo Chave do pedal do freio Chave do pedal da embreagem Acionamento do piloto automático Detecção de movimento do veículo Posição do pedal do acelerador Temperatura do refrigerante do motor Temperatura ambiente Total de combustível consumido Taxa de consumo de combustível Economia instantânea de combustível Nível do combustível

56

HFC

High Resolution Fuel Consumption 

OVS ERT

Overspeed 

Consumo de combustível em alta resolução Excesso de velocidade Horímetro

Engine Running Time 

 – Visualizando e ajustando parâmetros  4  –

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.  – Acendendo o Backlight  5  –

Para acender ou apagar o backlight  do display  apenas mude o estado da chave „BCKL‟, localizada na parte superior do dispositivo.  – Gravando um novo Firmware  6  –

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‟.

 – Conectando a uma rede CAN  2  –

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.

 – Lista de abreviaturas utilizadas no dispositivo  3  –

ABREVIATURA WBS ODO ENS TGS BRS CLS CCA VMD APP ECT AAT ETF FRT IFE FLV

SIGNIFICADO LITERAL

HFC

High Resolution Fuel Consumption 

OVS ERT

Overspeed 

Wheel Based Speed  Odometer  Engine Speed  Tachograph Speed  Brake Switch  Clutch Switch  Cruise Control Active  Vehicle Motion Detect  Accelerator Pedal Position  Engine Coolant Temperature  Ambient Air Temperature  Engine Total Fuel  Fuel Rate  Instantaneous Fuel Economy  Fuel Level 

Engine Running Time 

SIGNIFICADO TRADUZIDO Velocidade baseada na roda Odômetro Giros do motor Velocidade lida pelo tacógrafo Chave do pedal do freio Chave do pedal da embreagem Acionamento do piloto automático Detecção de movimento do veículo Posição do pedal do acelerador Temperatura do refrigerante do motor Temperatura ambiente Total de combustível consumido Taxa de consumo de combustível Economia instantânea de combustível Nível do combustível Consumo de combustível em alta resolução Excesso de velocidade Horímetro

58

 – Acendendo o Backlight  5  –

Para acender ou apagar o backlight  do display  apenas mude o estado da chave „BCKL‟, localizada na parte superior do dispositivo.  – Gravando um novo Firmware  6  –

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  – Alterando as configurações de saída  7  –

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, FORMATADOS, isto é, decodificados ou DADOS BRUTOS, 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.

 – Alterando a configuração da taxa de transmissão  8  –

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

 – Alterando o modo de operação do barramento  9  –

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 Autor Projeto criado em Última modificação em Total de Partes no Projeto

: DecodificadorCAN.DSN : Emanuel Nunes Baldissera : terça-feira, 13 de setembro de 2011 2 011 : domingo, 4 de dezembro de 2011 20 11 : 72

18 Resistores Qtd:

Referências

Valor

14

R1-R5, R9-R17

10k

2

R6, R18

560R

2

R7, R8

120R

10 Capacitores Qtd: Referências

Valor

4 2

C1-C4 C5, C9

1uF 1000uF/35V

2

C6, C11

100u

2

C7, C12

100nF

Observações

Observações

9 Circuitos Integrados Qtd:

Referências

Valor

Observações

2

U1, U4

PIC18F2580

Microcontrolador

1 2 2

U2 U3, U5 U6, U9

MAX232 MCP2551 7805

Transceptor RS-232 Transceptor CAN Regulador de Tensão

1

U7

24LC512

Memória I²C

1

U8

DS1822

Sensor de Temperatura

Referências

Valor

Observações

D1, D2, D4, D6 D3, D5

1N4007 LED

6 Diodes Qtd: 4 2

61

29 Outros Qtd:

Referências

Valor

2

FU1, FU2

150mA

1 2

J1 J2, J3

CONN-D9F TBLOCK-I5

4

J4, J5, J8, J9

PIN

2 2 1

J6, J10 J7, J11 LCD1

ENTRADA TERRA 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 

Observações

62

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

63