UM ROTEIRO DE IMPLEMENTAÇÃO DE UMA REDE CAN (CONTROLLER AREA NETWORK), PROFº DR. ANTÔNIO MAURO SARAIVA

Transcrição

1 UM ROTEIRO DE IMPLEMENTAÇÃO DE UMA REDE CAN (CONTROLLER AREA NETWORK) 1,2 2 ALEXANDRE DE ALMEIDA GUIMARÃES, PROFº DR. ANTÔNIO MAURO SARAIVA 1 GENERAL MOTORS DO BRASIL LTDA 2 ESCOLA POLITÉCNICA DA USP RESUMO O protocolo CAN (Controller Area Network) tem sido amplamente utilizado na implementação de diversos sistemas eletrônicos embarcados. Pode-se encontrar, com relativa facilidade, diversas publicações relacionadas, especialmente, aos conceitos fundamentais do protocolo, suas normas e componentes eletrônicos existentes. Entretanto, experiências objetivas sobre o desenvolvimento de uma rede completa não estão ao alcance de todos os interessados nesta tecnologia, especialmente no Brasil. Considerando-se este cenário, este artigo procura relacionar as informações que devem ser observadas durante a implementação de uma rede CAN genérica, possível de ser utilizada, por exemplo, em aplicações experimentais ou de pesquisa e desenvolvimento. Considerando-se uma aplicação hipotética, serão explicados os passos necessários para o desenvolvimento do hardware e do software requeridos por sua rede de comunicação de dados. 1. INTRODUÇÃO: ELETRÔNICA EMBARCADA E ARQUITETURAS ELETRO-ELETRÔNICAS O termo Eletrônica Embarcada representa todo e qualquer sistema eletro-eletrônico montado em uma aplicação móvel, seja ela um automóvel, um navio ou um avião. Há muitos anos, a indústria automotiva tem feito uso de sistemas eletro-eletrônicos no controle das várias funções existentes em automóveis de passeio e comerciais. Observa-se nos veículos atualmente comercializados, que boa parte destes sistemas de controle foi desenvolvida de forma independente e isolada, de forma que cada um passa a ser responsável por um determinado tipo de função no veículo. Por outro lado, o verdadeiro domínio e maximização da utilização dos diversos dados eletrônicos disponíveis em um automóvel, só é conseguida através da utilização de sistemas eletro-eletrônicos interligados, cada qual responsável por uma parte do veículo, mas compartilhando informações entre si. A partir destas duas condições, pode-se definir os dois principais conceitos de arquiteturas eletro-eletrônicas existentes: Arquitetura Centralizada e Arquitetura Distribuída. Vale reforçar que, as formas como os diversos sistemas de controle são implementados e interconectados em uma aplicação embarcada são chamadas de Arquiteturas Eletro- Eletrônicas (ou simplesmente Arquiteturas Elétricas) Arquitetura Centralizada Quando se analisa uma determinada aplicação e se encontra uma única ECU (Electronic Control Unit) responsável por receber todos os sinais de entrada (como os sensores e chaves de comando), processá-los e comandar as respectivas saídas de controle do sistema (como as válvulas e relés), classifica-se seu conceito de Arquitetura Elétrica como Centralizado. A figura 1 representa este conceito de arquitetura. Figura 1 Arquitetura Centralizada

2 Como vantagens desta arquitetura podem-se destacar: Simplicidade do Hardware utilizado na implementação do sistema, sendo constituído basicamente pelos sensores e atuadores, uma ECU para o devido controle do sistema e, obviamente, o cabeamento que os conecta. Todos os dados de entrada estarão disponíveis à ECU durante toda a operação do sistema, não sendo crítica a lógica de varredura e coleta de informações de cada um dos sensores existentes. Como desvantagens podem-se destacar: Grande quantidade de cabeamento requerido para conectar os sensores e atuadores à ECU, especialmente em grandes aplicações, o que dificulta a manufatura do veículo e a sua eventual manutenção. Limitação das possibilidades de expansão do sistema, uma vez que qualquer alteração na ECU significará a modificação de seu Hardware e/ou Software e, eventualmente, na condição de trabalho das funções originais do sistema Arquitetura Distribuída Existe a possibilidade de se utilizar, em um mesmo sistema de controle, várias ECU s interligadas, dividindo entre si a execução das diversas funções existentes no veículo. A figura 2 representa este conceito de arquitetura. Figura 2 Arquitetura Distribuída As ECU s 1, 2 e 3 são responsáveis pela leitura direta das entradas do sistema, enquanto que as ECU s 4 e 5 são responsáveis pelo comando das saídas. Além disso, no diagrama apresentado, qualquer uma das ECU s, dependendo das funções existentes neste sistema de controle, poderá participar do processamento dos dados e da atuação das saídas. Como vantagens desta arquitetura podem-se destacar: Quantidade reduzida de cabeamento do sistema, uma vez que, tendo-se várias ECU s disponíveis, pode-se instalá-las bem próximas aos sensores e atuadores, reduzindo o cabeamento mais pesado da implementação, formado basicamente por pares e pares de fios utilizados na conexão das entradas e saídas nas ECU s. Menor tempo de manufatura do veículo (exatamente pela menor quantidade de cabeamento necessário). Maior robustez do sistema de controle, por se ter reduzido as possibilidades de quebra de um dos circuitos ou o aparecimento de mal contato em determinado conector (novamente pela menor quantidade de cabeamento necessário).

3 Permite a ampliação do sistema com significativa facilidade, garantindo que alterações em uma determinada função do veículo, impactem somente em uma ou em parte das ECU s. Facilita a criação do software de aplicação de cada ECU, uma vez que possibilita a sua modularização e distribuição de responsabilidades entre elas. Possibilita a modularização do projeto do sistema e da execução dos testes de validação, aumentando a confiabilidade da implementação e reduzindo os prazos envolvidos no desenvolvimento. Como desvantagens podem-se destacar: Obriga a utilização de um meio de comunicação entre as ECU s, meio este comumente chamado de Protocolo de Comunicação. Implica na existência de um software de controle para a rede de comunicação que interliga as ECU s, cuja dificuldade de desenvolvimento depende diretamente da escolha do protocolo de comunicação. Difícil determinação da taxa de transmissão ideal para uma dada aplicação, o que impacta diretamente nos tempos internos do software de controle e na escolha dos componentes eletrônicos a serem utilizados no projeto das ECU s. Explicadas as vantagens e desvantagens fundamentais dos dois conceitos de arquitetura normalmente utilizados, deve-se acrescentar que a decisão de escolha de uma delas para uma dada aplicação móvel, depende da ponderação de diversos fatores. Dentre eles podem-se destacar: A complexidade do sistema a ser controlado (quantidade de variáveis de entrada e saída e o tamanho físico do sistema). A disponibilidade dos componentes eletrônicos requeridos à montagem das ECU s e à medição e atuação no sistema. A robustez, mecânica (como às vibrações) e elétrica (como às interferências eletromagnéticas), requerida pelo sistema a ser controlado. O tempo necessário à implantação da arquitetura (projeto, construção de protótipos e validação). O custo desejado do sistema final (limitações inerentes ao orçamento). O relacionamento entre estes fatores é que determinará o conceito de arquitetura mais apropriado ao sistema a ser controlado. Tal desafio é enfrentado quase que diariamente pelas empresas montadoras de veículos, onde uma das maiores dificuldades do seu corpo de engenheiros é determinar a arquitetura elétrica de um novo modelo; garantindo o mínimo de funções desejadas pelos futuros clientes, dentro dos limites de custo de projeto e produto final determinados pela empresa. As figuras 3 e 4 ilustram, respectivamente, um exemplo de aplicação automotiva para a Arquitetura Centralizada e um exemplo para a Arquitetura Distribuída. No exemplo que trata da Arquitetura Centralizada (figura 3), pode-se perceber o fato de não existirem redes de comunicação de dados entre os diversos módulos eletrônicos de controle mostrados. Por outro lado, no exemplo que ilustra a Arquitetura Distribuída (figura 4), pode-se visualizar a existência de três redes de comunicação de dados interligando as cinco ECUs mencionadas no

4 diagrama. Fica evidente neste caso o compartilhamento das informações lidas, por exemplo, pelo BCM1, com os demais módulos do sistema. Figura 3 Exemplo de Aplicação: Arquitetura Centralizada Figura 4 Exemplo de Aplicação: Arquitetura Distribuída

5 2. PROTOCOLO DE COMUNICAÇÃO: O CAN BUS Considerando, a partir deste momento, o conceito de Arquitetura Distribuída para a continuidade das discussões neste artigo, pode-se afirmar com segurança que boa parte das dificuldades de implementação existentes estão relacionadas ao chamado Protocolo de Comunicação. Um Protocolo de Comunicação é um conjunto de regras que orienta a comunicação entre duas ou mais ECUs. O CAN Bus, barramento Controller Area Network, considerando-se uma aplicação móvel, é o que tem as melhores características técnicas e as mais robustas condições de operação. Foi desenvolvido pela empresa alemã Robert BOSCH e disponibilizado em meados dos anos 80. Sua aplicação inicial foi realizada em ônibus e caminhões. Atualmente, é utilizado na indústria, em veículos automotivos, navios e tratores, entre outros Conceituação O CAN é um protocolo de comunicação serial síncrono. O sincronismo entre os módulos conectados a rede é feito em relação ao início de cada mensagem lançada ao barramento (evento que ocorre em intervalos de tempo conhecidos e regulares). Trabalha baseado no conceito multi-mestre, onde todos os módulos podem se tornar mestre em determinado momento e escravo em outro, além de suas mensagens serem enviadas em regime multicast, caracterizado pelo envio de toda e qualquer mensagem para todos os módulos existentes na rede. Além disso, é fundamentado no conceito CSMA/CD com NDA (Carrier Sense Multiple Access / Collision Detection with Non-Destructive Arbitration), o que significa que todos os módulos verificam o estado do barramento, analisando se outro módulo está ou não enviando mensagens com maior prioridade. Caso isto seja percebido, o módulo cuja mensagem tiver menor prioridade cessará sua transmissão e o de maior prioridade continuará enviando sua mensagem deste ponto, sem ter que reiniciá-la. Como mencionado anteriormente, todos os módulos podem ser mestre e enviar suas mensagens. Para tanto, o protocolo utiliza-se de uma arbitragem bit a bit não destrutiva, a qual pode ser exemplificada analisando o comportamento de dois módulos enviando, ao mesmo tempo, mensagens diferentes. Após enviar um bit, cada módulo analisa o barramento e verifica se outro módulo na rede o sobrescreveu (vale acrescentar que um bit Dominante sobrescreve eletricamente um Recessivo). Um módulo interromperá imediatamente sua transmissão, caso perceba que existe outro módulo transmitindo uma mensagem com maior prioridade (quando seu bit recessivo é sobrescrito por um dominante). Este módulo, com maior prioridade, continuará normalmente sua transmissão. Outro conceito bastante interessante é o NRZ (Non Return to Zero), onde cada bit (0 ou 1) é transmitido por um valor de tensão específico e constante. Considerando-se fios elétricos como meio de transmissão dos dados, existem três formas de se constituir um barramento CAN, dependentes diretamente da quantidade de fios utilizada: através de 1, 2 ou 4 fios. As redes com 2 e 4 fios trabalham com os sinais de dados CAN_H (CAN High) e CAN_L (CAN Low). No caso dos barramentos com 4 fios, além dos sinais de dados, um fio com o VCC (alimentação) e outro com o GND (referência) fazem parte do barramento, levando a alimentação às duas terminações ativas da rede. As redes com apenas 1 fio têm este, o fio de dados, chamado exclusivamente de linha CAN. Considerando o CAN fundamentado em 2 e 4 fios, seus condutores elétricos devem ser trançados e não necessariamente blindados. Os dados enviados através da rede devem ser interpretados pela análise da diferença de potencial entre os fios CAN_H e CAN_L. Por isso, o barramento CAN é classificado como Par Trançado Diferencial. Este conceito atenua fortemente os efeitos causados por interferências eletro-magnéticas, uma vez que qualquer ação sobre um dos fios será sentida também pelo outro, causando flutuação em ambos os sinais para o mesmo

6 sentido e com a mesma intensidade. Como o que vale para os módulos que recebem as mensagens é a diferença de potencial entre os condutores CAN_H e CAN_L (e esta permanecerá inalterada), a comunicação não é prejudicada. No protocolo CAN, os dados não são representados por bits em nível 0 ou nível 1. São representados por bits Dominantes e bits Recessivos, criados em função da condição presente nos fios CAN_H e CAN_L. A figura 5 ilustra os níveis de tensão em uma rede CAN, assim como os bits Dominantes e Recessivos. Figura 5 Bits Dominantes e Recessivos A velocidade de transmissão dos dados em uma rede CAN é inversamente proporcional ao comprimento do barramento. A maior taxa de transmissão especificada é de 1Mbps considerando-se um barramento de 40 metros. A figura 6 representa a relação entre o comprimento da rede (barramento) e a taxa de transmissão dos dados. Figura 6 Relação entre o Comprimento da Rede e a Velocidade de Transmissão 2.2. Formatos das Mensagens Existem dois formatos de mensagens no protocolo CAN: CAN 2.0A Mensagens com identificador de 11 bits, com os quais pode-se ter até 2048 mensagens.

7 Percebe-se que esta quantidade limitada de mensagens pode caracterizar uma limitação em determinadas aplicações. A figura 7 apresenta o quadro de mensagem do CAN 2.0A. Figura 7 Quadro de Mensagens: CAN 2.0A CAN 2.0B Mensagens com identificador de 29 bits, com os quais pode-se ter, aproximadamente, 537 milhões de mensagens. Percebe-se neste caso que a limitação em virtude da quantidade de mensagens não mais existe. Por outro lado, o que pode ser observado em alguns casos é que, os 18 bits adicionais no identificador aumentam o overhead da mensagem, o que pode caracterizar um problema em determinadas aplicações que trabalhem em tempo-real. A figura 8 apresenta o quadro de mensagem do formato CAN 2.0B. Figura 8 Quadro de Mensagens: CAN 2.0B 2.3. Padrões Existentes Os fundamentos do CAN são especificados por duas normas: a ISO11898 e a ISO A primeira, ISO11898, determina as características de uma rede trabalhando com alta velocidade de transmissão de dados (de 125Kbps a 1Mbps). A segunda, ISO , determina as características de uma rede trabalhando com baixa velocidade (de 10Kbps a 125Kbps). Ambos os padrões especificam as camadas Física e de Dados, respectivamente 1 e 2 se considerado o padrão de comunicação OSI de 7 camadas (ISO7498). As demais camadas, da 3 a 7, são especificadas por outros padrões, cada qual relacionado a uma aplicação específica. Existem diversos padrões fundamentados no CAN, dentre os quais podem-se destacar: NMEA 2000: Baseado no CAN 2.0B e utilizado em aplicações navais e aéreas. SAE J1939: Baseado no CAN 2.0B e utilizado em aplicações automotivas, especialmente ônibus e caminhões. DIN 9684 LBS: Baseado no CAN 2.0A e utilizado em aplicações agrícolas. ISO11783: Baseado no CAN 2.0B e também utilizado em aplicações agrícolas. Estes padrões especificam o equivalente às camadas de Rede (3), Transporte (4), Sessão (5), Apresentação (6) e Aplicação (7), do padrão OSI, incluindo-se as mensagens pertinentes ao Dicionário de Dados de cada aplicação em especial.

8 3. IMPLEMENTAÇÃO DE UMA REDE CAN Considerando-se uma determinada aplicação, a primeira atividade que deve ser realizada durante o projeto de sua rede de comunicação de dados é a determinação da sua arquitetura Determinação da Arquitetura Eletro-Eletrônica Neste momento pode-se enfrentar duas situações: ter que estabelecer uma rede de comunicação entre ECUs prontas e que não trabalhem em rede ou, ter que projetar totalmente as ECUs, considerando a leitura das entradas, seus devidos processamentos e atuações nas saídas, além da troca de dados através da rede propriamente dita. Tomando-se como ponto de partida uma aplicação onde as ECUs estejam prontas, a responsabilidade o engenheiro será, fundamentalmente, disponibilizar as informações de cada ECU no formato determinado pelo Protocolo CAN, além de estabelecer as conexões necessárias à comunicação de dados entre as próprias ECUs. Este cenário pode ser complexo de se lidar uma vez que nem todas as ECUs, da forma como foram originalmente projetadas, serão capazes de, facilmente, fornecer as informações sob sua responsabilidade para que o devido empacotamento no formato CAN seja realizado. De qualquer forma o trabalho é possível. Considerando-se uma aplicação onde somente o escopo do sistema que se deseja controlar esteja disponível, pode-se projetar as ECUs já considerando os controladores capazes de, facilmente, estabelecer uma comunicação fundamentada no protocolo CAN. Este artigo, a partir deste ponto, considera esta condição: o projeto das ECUs e a sua interligação através do CAN. A aplicação sobre a qual este estudo tratará é simples. A figura 9 apresenta a arquitetura proposta. Figura 9 Diagrama Esquemático da Aplicação: Arquitetura Proposta Esta arquitetura mostra-se extremamente simples, uma vez que considera duas ECUs conectadas por uma rede de comunicação CAN Bus, ambas com as mesmas responsabilidades: Ler algumas entradas digitais; Empacotar estes dados no formato determinado pelo CAN; Transmitir estes dados pela rede CAN à outra ECU; Receber dados da outra ECU, enviados pela rede CAN, e Processar estes dados, comandando as saídas necessárias. Através de uma linha de comunicação serial RS232 e um PC, pode-se programar e monitorar o funcionamento de cada ECU.

9 3.2. Determinação do Dicionário de Dados O Dicionário de Dados (ou D.D.) de uma aplicação pode ser descrito como uma tabela que relaciona as mensagens existentes nesta aplicação (seus identificadores e dados) e as ECUs responsáveis por sua transmissão e recepção. A tabela 1 mostra as informações necessárias ao Dicionário de Dados da aplicação tratada por este artigo. Tabela 1 Dicionário de Dados da Aplicação Analisando-se a tabela 1 percebe-se que, neste Dicionário de Dados: A mensagem 1 é chamada de Estado das Entradas da ECU #1 ; Ela é transmitida pela ECU #1 (TX) e recebida pela ECU #2 (RX); Seu Identificador (ID) tem valor igual a hex ; Seus Bytes de Dados, excluindo-se o Byte D #1, são iguais a 00 hex ; Seu Byte de Dados D #1 depende de algumas regras específicas, onde:! XX será 31 hex caso uma determinada entrada digital seja igual a 1! XX será 30 hex caso esta determinada entrada digital seja igual a 0 Para as demais mensagens, vale a mesma análise. A única observação que deve ser feita é que cada Byte de Dados da tabela que tiver seu valor igual a XX, possuirá uma regra específica, assim como explicado para o Byte de Dados D #1 da mensagem 1. Apesar deste D.D. parecer simples, e realmente é, ele demonstra o que efetivamente ocorre em uma aplicação real. Analisando-se uma aplicação automotiva por exemplo, percebe-se a existência de mensagens relacionadas ao funcionamento do motor, dos freios ABS e dos sistemas de travamento das portas e alarme, entre outras. Além disso, pela complexidade dos sistemas envolvidos no controle das funções do automóvel, não somente um byte de dados por mensagem será utilizado (como feito na aplicação tratada por este artigo, onde é indicada apenas a alteração do estado de uma determinada entrada) e sim, todos os 8 bytes existentes. Estabelecido o Dicionário de Dados pertinente à esta aplicação, resta agora a sua implementação efetiva, que se dá através de um software instalado dentro de cada ECU. Este software é conhecido como firmware. Antes de tratar do firmware necessário, deve-se considerar o projeto do hardware das ECUs Projeto do Hardware das ECUs Este artigo considera ambas as ECUs sendo baseadas no mesmo projeto de hardware, contendo a mesma quantidade de Entradas e Saídas, uma porta de comunicação serial RS232 e uma porta de comunicação CAN Bus. Quando se projeta uma ECU para a sua utilização em uma rede de comunicação de dados baseada no Protocolo CAN Bus, tem-se duas alternativas tecnológicas em relação à execução do processamento. A primeira, mais antiga, utilizando-se um Micro-Controlador (sem CAN) conectado a um Controlador CAN (o que caracteriza dois CIs distintos e interligados). A segunda, tecnologicamente mais atual, utilizando-se um Micro-Controlador com CAN incorporado.

10 Quando se utiliza um Micro-Controlador sem CAN (conectando-o a um Controlador CAN específico), este fica responsável pelo tratamento das entradas e saídas, trocando informações por portas de comunicação específicas com o Controlador CAN, responsável pelo empacotamento dos dados no formato do Protocolo (além da sua transmissão e recepção). Quando se utiliza um Micro-Controlador com CAN incorporado, este CI passa a ser responsável não só pela leitura e tratamento das entradas e o acionamento das saídas, como também pelo empacotamento dos dados no formato CAN (além da sua transmissão e recepção). O que determina a utilização de um conceito ou do outro é, basicamente, a disponibilidade e o custo dos componentes envolvidos. Do ponto de vista da implementação, acredita-se que a utilização de um Micro-Controlador com CAN incorporado seja mais simples, rápida e segura do ponto de vista técnico (especialmente em relação à Compatibilidade Eletro-Magnética). Além do Micro-Controlador, uma ECU com capacidade de comunicação via CAN precisa ter o chamado Transceiver ou Transmissor-Receptor. Este componente é responsável pela compatibilização dos níveis elétricos requeridos pela rede CAN com os níveis elétricos necessários ao trabalho do Micro-Controlador e vice-versa. O projeto apresentado neste artigo considera o Micro-Controlador com CAN incorporado P87C591 (Philips) e o Transceiver PCA82C250 (Philips). Obviamente, na implementação efetiva de cada uma das ECUs, serão necessários outros componentes eletrônicos além dos dois anteriormente mencionados Micro-Controlador e Transceiver. A figura 10 mostra o diagrama elétrico das ECUs. Figura 10 Diagrama Elétrico das ECUs Por se tratarem de ECUs destinadas ao aprendizado do Protocolo CAN, optou-se pelo projeto onde a execução de seus programas ocorre nas memórias EPROM e RAM, ao invés da memória interna do Micro-Controlador (neste caso um OTP). Na memória EPROM grava-se um programa de uma categoria conhecida como Monitor, enquanto que, na memória RAM, gravam-se os programas Principais de cada uma das ECUs.

11 A figura 11 mostra a foto de uma ECU construída considerando-se o projeto de hardware apresentado anteriormente. Figura 11 Foto de uma ECU baseada no projeto descrito neste artigo 3.4. Projeto do Firmware (Software das ECUs) São dois os tipos de firmware utilizados neste projeto: O primeiro é chamado de Monitor É gravado na memória EPROM a partir do endereço 0000hex e passa a ser executado toda vez que a ECU é reinicializada. A função principal deste programa Monitor é possibilitar a gravação e a operação do programa Principal da ECU em sua memória RAM. Isto é possível através da operação de comandos do programa Monitor. Para tanto, a ECU precisa estar conectada a um PC via RS232 e, por R exemplo, utilizando o aplicativo Hyper Terminal do MS Windows, pode-se transferir o programa Principal da ECU para a sua memória RAM. Qualquer programa Monitor para Micro-Controladores similares ao 8051 pode ser utilizado neste projeto. Os testes neste desenvolvimento específico consideraram o monitor PAULMON, disponível na internet ( - acesso em: 20 Out 2001). O segundo é chamado de Principal. É gravado na memória RAM pelo processo descrito anteriormente e passa a ser executado por um dos comandos existentes no programa Monitor, (este comando desvia a execução do Micro-Controlador para a primeira posição de memória ocupada pelo programa Principal neste caso, o endereço 8000hex). Este programa Principal é responsável pela leitura e o processamento das entradas, ativação das saídas, controle da linha de comunicação serial RS232 e da linha de comunicação CAN Bus. A figura 12 mostra a distribuição dos vários programas mencionados e os endereços de início e término das memórias EPROM e RAM. Figura 12 Memórias RAM e EPROM e seus respectivos Programas

12 Ainda sobre o programa Principal, é necessário o desenvolvimento de algumas rotinas que responderão pelas seguintes operações: Inicialização da Porta de Comunicação Serial RS232; Inicialização da Porta de Comunicação CAN Bus (Baud Rate e os Filtros de Aceitação de Mensagens); Rotinas de Transmissão e Recepção via RS232; Rotinas de Transmissão e Recepção via CAN Bus; Rotina de leitura de uma Entrada Digital; Rotina de acionamento de uma Saída Digital. As rotinas acima mencionadas podem ser escritas em linguagem C e o programa final que as contêm, pode ser compilado com o auxílio de qualquer compilador C para micro-controladores similares ao Neste projeto utilizou-se o SDCC Small Device C Compiler, disponível na internet ( - acesso em: 21 Nov 2001). Alguns exemplos de rotinas programadas em C são mostradas a seguir: Início do Programa: #include "87C591.h" #define BYTE unsigned char #define WORD unsigned int #define IN P1_2 #define OUT P3_2 Definição da estrutura da mensagem CAN: typedef struct { BYTE INFO; /* Byte com informações relacionadas a mensagem CAN */ BYTE ID[4]; /* 4 bytes de Identificador */ BYTE BUF[8]; /* 8 bytes de dados */ } PDU; Inicialização da Porta RS232: void init_serial() { PCON = 0x80; /* SMOD1=1 e SMOD0=0 => Baud Rate dobrado */ TMOD = 0x20; /* Timer 1 autoload */ TCON = 0x40; /* Inicia o Timer 1 */ TH1 = 0x0FD; /* Taxa de transmissão: 19200*2=38400 */ SCON = 0x52; /* SM0=0 e SM1=1 => Modo 1 */ } Transmissão via CAN Bus: void TX_CAN (PDU *ptxb) { BYTE length; /* CAN Data Length Code */ BYTE i; /* index */ length = ptxb->info; while (!(CANSTA & 0x04)); CANADR = 0x70; /* Aponta para o TX Frame Information */ CANDAT = length; /* Coloca o DLC no CANDAT */ for (i=0;i<4;i++)

13 CANDAT = ptxb->id[i]; /* Coloca os 4 bytes do ID no CANDAT */ for (i=0;i<length;i++) CANDAT = ptxb->buf[i]; /* Coloca os 8 bytes de Dados no CANDAT */ } CANCON = 0x01; /* Solicita transmissão */ Recepção via CAN Bus: int RX_CAN (PDU *prxb) { BYTE length; /* CAN Data Length Code */ BYTE i; /* index */ if (CANSTA & 0x01) /* Analisa o RBS - Receive Buffer Status */ { CANADR = 0x60; /* Aponta para o RX Frame Information */ length = CANDAT & 0x0F; /* Coloca o DLC na variável length */ prxb->info = length; /* Coloca o DLC no prxb */ for (i=0;i<4;i++) prxb->id[i] = CANDAT; /* Coloca os 4 bytes do ID no prxb */ for (i=0;i<length;i++) prxb->buf[i] = CANDAT; /* Coloca os 8 bytes de Dados no prxb */ CANCON = 0x0C; } } else return (1); return (0); 3.5. Montagem da Rede CAN Bus: Barramento e Terminadores Barramento é o termo técnico que representa os condutores elétricos das linhas de comunicação e a forma como eles são montados. Apesar de parecer simples, o ato de interligar os módulos requer bastante atenção. Sobre o cabeamento necessário, considerando-se uma aplicação CAN de dois fios, deve-se utilizar par trançado onde a secção transversal de cada um dos fios deve ser de no mínimo 0,35mm². As duas terminações (resistores de aproximadamente 120 ohms), do ponto de vista teórico, podem ser instaladas nas extremidades do chicote, diretamente nos fios de dados CAN_H e CAN_L. Do ponto de vista prático isto é extremamente complexo. O que deve ser feito é adicionar as terminações nas duas ECUs conectadas aos extremos da rede. Se as ECUs forem montadas dependendo dos opcionais do veículo, deve-se procurar instalar as terminações nas ECUs que sempre estiverem presentes nele (veículo). As terminações são mandatórias numa rede CAN. No momento de se projetar o roteamento do barramento, algumas regras em relação ao comprimento dos chicotes devem ser observadas pois, o sincronismo das operações das ECUs no CAN é fundamentado no tempo de propagação física das mensagens dentro dos condutores elétricos. Assim, a relação do comprimento de determinados intervalos do chicote no barramento são fundamentais ao bom funcionamento da rede. A figura 13 mostra um diagrama que ilustra as medidas que devem ser observadas no desenvolvimento do chicote.

14 Figura 13 Geometria do Barramento Destaca-se que, após o barramento ter sido montado, caso seja necessário qualquer retrabalho no mesmo, é aconselhável a troca do chicote elétrico danificado. Emendas poderão alterar a impedância característica da rede e com isso afetar o seu funcionamento. CONCLUSÕES Este artigo procurou explicar, de maneira simplificada, todos os conceitos relacionados a aplicação do protocolo CAN Bus. Foram abordados aspectos ligados à determinação da Arquitetura, Centralizada ou Distribuída, explicados os conceitos fundamentais do protocolo CAN Bus e relacionados os passos importantes no momento de se implementar efetivamente uma rede de comunicação de dados baseada no CAN. Como pôde ser observado, a implementação de um barramento CAN envolve conceitos de hardware e software. O primeiro, hardware, é fortemente dependente da estratégia de utilização do microcontrolador pelo engenheiro projetista. O segundo, software, agrega o controle das operações realizadas pelas ECUs. Sobre a montagem do barramento físico de uma rede CAN, percebeu-se que não deve ser desconsiderada e tratada como uma etapa simples da implementação do sistema. Existem regras e boas práticas que garantem o bom funcionamento da rede. LISTA DE ABREVIAÇÕES ACK: Acknowledgement. CAN Bus: Barramento Controller Area Network. CI: Circuito Integrado. CD: Collision Detection. CRC: Cyclic Redundant Check. CSMA/CD: Carrier Sense Multiple Access. EA: External Access. ECU: Electronic Control Unit. EEPROM: Electrical Erasable and Programmable ROM.

15 EPROM: Electrical Programmable ROM. I/O: Input/Output. ISO: International Organization for Standardization. Kbps: Kilo bits por segundo. Mbps: Mega bits por segundo. NDA: Non-Destructive Arbitration. NRZ: Non-Return to Zero. OSI: Open System Interconnection. OTP: One Time Programmable. PC: Personal Computer. RAM: Random Access Memory. ROM: Ready Only Memory. SAE: Society of Automotive Engineers. REFERÊNCIAS Guimarães, A.A. Eletrônica Embarcada em Automóveis Parte 1, Revista SABER Eletrônica N 363, Abril 2003, ISSN , São Paulo, 2003, pg Guimarães, A.A. Eletrônica Embarcada em Automóveis Parte 2, Revista SABER Eletrônica N 364, Maio 2003, ISSN , São Paulo, 2003, pg Guimarães, A.A. Eletrônica Embarcada em Automóveis Parte Final, Revista SABER Eletrônica N 365, Junho 2003, ISSN , São Paulo, 2003, pg Guimarães, A.A.; Saraiva, A.M. O Protocolo CAN: Entendendo e Implementando uma Rede de Comunicação Serial de Dados baseada no Barramento Controller Area Network, SAE paper nº São Paulo, Guimarães, A.A. O Protocolo CAN Bus nas Aplicações Off-Road: Uma Análise Comparativa entre os Padrões Existentes, SAE paper nº São Paulo, Guimarães, A.A. Análise da norma ISO11783 e sua utilização na implementação do barramento do implemento de um monitor de semeadora p. Dissertação (Mestrado) Escola Politécnica, Universidade de São Paulo. São Paulo, Fredriksson, L.B. Controller Area Networks and the protocol CAN for machine control systems, Mechatronics, v.4 n.2, p , Zuberi K.M.; Shin K.G. Real-time decentralized control with CAN. In: IEEE Conference on Emerging Technologies and Factory Automation, Proceedings. IEEE, p Controller Area Network (CAN) - Module 6., BOSCH - Powertrain University, ISO Road vehicles-interchange of digital information-controller area network (CAN) for high-speed communication, Data Dictionary for V-Bus applications, Issue 1.3, 2001, GM proprietary documentation. Phillips Web Site, consultado em Março de Strauss, C. Implementação e Avaliação de uma Rede Experimental baseada em CAN para Aplicações Agrícolas, Dissertação de Mestrado, EPUSP, 2001.

16 REFERÊNCIAS ADICIONAIS Guimarães, A.A.; Saraiva, A.M. As Aplicações Agrícolas e o Protocolo CAN: Uma Aplicação a um Monitor de Semeadora. In: 3º Congresso da SBI-Agro, Foz do Iguaçu. Anais. SBI Agro. Lavras p Hofstee, J.W.; Goense, D. Simulation of a Controller Area Network-based Tractor-Implement Data Bus according to ISO 11783, J. Agric. Engng Res. (1999) 73, Sigrimis, N.; Hashimoto, Y.; Munack, A.; De Baerdemaeker, J. Prospects in Agricultural Engineering in the Information Age, CIGR-Ejournal, invited paper, Strauss, C.; Cugnasca, C.E.; Saraiva, A.M. Protocolos de Comunicação para Equipamentos Agrícolas, CONAI, ISO11783 Workshop, Agrithecnica 99, Fredriksson, L.B. Distributed Embedded Control Systems in Robotics Ten Years of Development, KVASER AB, Stone, M.L. Dynamic Address Configuration in SAE J1939, Biosystems and Agricultural Engineering, Oklahoma State University. Stone, M.L. High Speed Networking in Construction and Agricultural Equipments, Department of Biosystems and Agricultural Eng'g, 1994, Axelson, J. Serial Port Complete, ISBN , Lakeview Research, Why CAN, KVASER Web Site, HLPs: SAE J1939, KVASER AB, Stone, M.L.; Zachos, M. Application of J1939 Networks in Agricultural Equipments, Oklahoma State University Dearborn Group. Controller Area Network Background Information, How CAN works, Implementation, Application Layer Stepper, M. R. J1939 High Speed Serial Communications, The Next Generation Network for Heavy Duty Vehicles, SAE paper nº , Alvarenga, C. Multiplexing in Automobiles An Application Example of the CAN Protocol, SAE paper, Multiplexing and Networking pág Dietmayer, K.; Overberg, K. W. CAN Bit Timing Requirements, SAE paper nº , Buehring, P. CAN Controller Architecture Optimized for SAE-J1939 Applications, SAE paper nº , Samuel, J. Developing Diagnostics on KWP 2000 and CAN, SAE paper nº , 1998.