Você está na página 1de 38

ARQUITETURAS ELETRO-ELETRÔNICAS

“CONCEITUAÇÃO”

ELETRÔNICA EMBARCADA EM AUTOMÓVEIS

Antes de explorarmos as mais variadas alternativas tecnológicas para arquiteturas


elétricas, devemos ter em mente o que significa a expressão “Eletrônica Embarcada”.
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.

Observamos nos veículos atualmente comercializados, que boa parte destes sistemas
de controle foi desenvolvida de forma independente, no sentido que cada um é
responsável por um determinado tipo de função no veículo.

Em contra-partida, o real domínio sobre os diversos dados eletrônicos disponíveis em


um automóvel é mais facilmente conseguido 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.

Sistemas desenvolvidos dentro deste contexto têm sido disponibilizados pelos mais
variados fornecedores de componentes automotivos e empresas montadoras de
veículos, dando a impressão ao motorista e passageiros de que o controle do
automóvel é totalmente integrado, muitas vezes deixando a sensação de existência de
uma única unidade de controle inteligente – uma espécie de cérebro.

A figura 1 mostra a relação entre algumas informações disponíveis em um automóvel e


algumas funções afetadas por elas.
Figura 1

Perceba que, enquanto o sinal da Chave de Ignição é importante no funcionamento dos


cinco sistemas apresentados, o sinal de Velocidade do Motor importa apenas ao Painel
de instrumentos.

ALTERNATIVAS TECNOLÓGICAS À ARQUITETURA ELÉTRICA

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

No setor automotivo, dentre os diversos conceitos de arquitetura elétrica atualmente


utilizados, podemos destacar dois: Arquitetura Centralizada e Arquitetura
Distribuída.

Arquitetura Centralizada

Quando analizamos determinadas aplicações, encontramos uma única ECU


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

O que é uma ECU ?

ECU é a abreviação de Unidade Eletrônica de Controle (Electronic Control Unit) e,


fisicamente, nada mais é que um módulo eletrônico responsável por realizar um
determinado controle. No caso da Arquitetura Centralizada, uma única ECU é
responsável por todo o tipo de controle existente no sistema.

Figura 2

O diagrama esquemático que representa este conceito de arquitetura é apresentado na


Figura 2.

Dentro da chamada “ECU Central” são encontrados Hardware e Software que


permitem a leitura das entradas, seu processamento e a atuação das saídas.

Como vantagens desta arquitetura podemos 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 podemos 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 elas a execução das diversas funções existentes no
veículo.

O diagrama esquemático que representa este conceito de arquitetura é apresentado na


Figura 3.
Figura 3

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 podemos destacar:

  Quantidade reduzida de cabeamento do sistema, uma vez que, tendo várias


ECU´s disponíveis, poderemos 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 termos 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).

  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 podemos 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, devemos 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 podemos 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


eletro-magné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 os fatores anteriormente colocados, considerando-se uma


determinada aplicação móvel, é 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.

Uma das maiores dificuldades da engenharia de produtos de uma montadora é


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.

Normalmente, os produtos têm seu desenvolvimento iniciado com três ou quatro anos
de antecedência ao seu lançamento, o que dificulta ainda mais a tomada de decisão
sobre qual seria a melhor solução de engenharia para determinado projeto. Tal trabalho
precisa relacionar as visões de Engenharia Avançada (tecnologia), Marketing
Estratégico (mercado) e Político-Econônica (orçamento) da região à que se destina o
novo produto.
De todo modo, a Figura 4 ilustra a tendência da relação entre a responsabilidade de
cada ECU de um determinado sistema de controle e a complexidade deste sistema
como um todo, nessas duas alternativas – Centralizada e Distribuída.

Figura 4

Analisando friamente cada um dos conceitos de arquitetura apresentados, não só do


ponto de vista da evolução tecnológica, mas também das possibilidades futuras de
expansão de funções com o mínimo de alteração no sistema de controle do veículo
como um todo, podemos considerar a Arquitetura Distribuída a mais interessante.

Diante deste posicionamento, faz-se necessária a utilização de um protocolo de


comunicação que permita a interconexão das ECU´s e a troca dos dados pertinentes a
cada uma das funções controladas pelo sistema. Nesta linha de raciocínio, dentre os
diversos protocolos de comunicação existentes, os de comunicação serial mostram-
se tecnicamente mais adequados e, mais adiante, dentro desta classe de protocolos, o
CAN (Controller Area Network) tem grande destaque.
EXEMPLOS DE SISTEMAS EXISTENTES

Após definirmos as arquiteturas normalmente utilizadas em veículos automotores, nada


como colocar um exemplo prático de cada uma delas para fiquem claras suas
diferenças principais.

A figura 5 mostra um veículo cuja Arquitetura Elétrica é fundamentada no conceito


Centralizado. Perceba que são ilustrados, além de dois sistemas de controle (o de
Iluminação Externa e o Levantador Elétrico dos Vidros), quatro módulos principais: O
ECM (Módulo de Controle do Motor); o Rádio; o IPC (Instrumentos do Painel) e o BCM
(Módulo de Controle da Carroçaria).

Neste exemplo, o BCM recebe, de forma discreta, os sinais de entrada (interruptores


de comando) dos respectivos sistemas e, após trabalhar internamente com estas
informações, atua, também de forma discreta, nas saídas (lâmpadas e motores
elétricos). O BCM centraliza o controle destes sistemas, sendo totalmente
independente dos demais módulos existentes no veículo.

Da mesma forma, o ECM, o Rádio e o IPC, recebem seus sinais de entrada,


processam cada um deles e atuam sobre as respectivas saídas. Como exemplo, o
ECM recebe, dentre vários sinais, a Posição do Pedal do Acelerador, atuando em
seguida na Borboleta, alterando sua posição. O Rádio, recebe o sinal da Chave de
Ignição, atuando no controle Liga / Desliga do sistema. Já o IPC, recebe o sinal de
Velocidade do veículo e atua no Ponteiro de Indicação da Velocidade.

Para realizar os controles dentro deste conceito de arquitetura, note que nenhum
protocolo de comunicação é necessário. Basta que as ECU´s possuam portas de
Entrada e Saída discretas e um algoritmo interno de controle, muitas vezes de
concepção simples.
Figura 5

A figura 6 mostra um veículo cuja Arquitetura Elétrica é fundamentada no conceito


Distribuído. Perceba que são ilustrados neste exemplo, os mesmos módulos
considerados na ilustração anterior. Entretanto, neste caso, as ECU´s estão
interconectadas por três Redes de Comunicação de Dados diferentes:

REDE 1: Responsável pela troca de dados entre o ECM e o BCM 1, esta rede trabalha
com taxa de transmissão de dados de alta velocidade.

REDE 2: Responsável pela comunicação entre o Rádio e o IPC, esta rede trabalha
com taxa de transmissão de dados de média velocidade.

REDE 3: Responsável pela interconexão dos BCM´s 1 e 2 e o IPC, esta rede de


comunicação de dados trabalha com taxa de transmissão de baixa velocidade.
Neste conceito de arquitetura, um sinal recebido por uma das ECU´s poderá ser
enviado, através das redes de comunicação, para qualquer uma das demais ECU´s.

Como exemplo, o Sinal de Velocidade do Motor poderia ser medido pelo BCM 1 (por
este estar mais próximo do Sensor da Roda Dianteira), colocado por este módulo nas
redes 1 e 3, de onde seria coletado respectivamente pelo ECM e pelo IPC que,
respectivamente, o utilizariam nos Cálculos do Sistema de Injeção e na Indicação da
Rotação do Motor ao motorista.

Perceba que, com apenas uma medição, um determinado sinal pôde ser utilizado por
duas ECU´s distintas. Esta é uma das grandes vantagens de uma Arquitetura
Distribuída – a maximização da utilização dos dados disponíveis no veículo.

Figura 6
A pergunta que deve ser respondida agora é: Como realizar a comunicação entre as
ECU´s ?

Ou melhor: Qual protocolo utilizar em aplicações automotivas, garantindo que


todos os critérios de desempenho e segurança estejam presentes ?

CAN BUS
BARRAMENTO CONTROLLER AREA NETWORK
“CONCEITUAÇÃO”

INTRODUÇÃO

A primeira parte deste artigo procurou explicar os dois principais conceitos de


Arquitetura Eletro-Eletrônica existentes – o Centralizado e o Distribuído. Além de
destacadas as vantagens e desvantagens de ambos os conceitos, foram mencionados
dois exemplos de aplicação, um fundamentado no sistema Centralizado e outro no
Distribuído.

Percebemos que, para a viabilização do sistema, especialmente no conceito


Distribuído, é extremamente necessária a utilização de um Protocolo de
Comunicação. Neste sentido, o CAN Bus mostra-se o mais adequado se considerada
a aplicação em questão: Eletrônica Embarcada em veículos automotivos.

Vamos então ao Protocolo !

HISTÓRICO
O CAN Bus (ou Barramento Controller Area Network) 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 BÁSICA

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.

Outro ponto forte deste protocolo é o fato de ser fundamentado no conceito CSMA/CD
with NDA (Carrier Sense Multiple Access / Collision Detection with Non-Destructive
Arbitration). Isto 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.

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.

A velocidade de transmissão dos dados é inversamente proporcional ao


comprimento do barramento. A maior taxa de transmissão especificada é de 1Mbps
considerando-se um barramento de 40 metros. A Figura 1 representa a relação entre o
comprimento da rede (barramento) e a taxa de transmissão dos dados.
Figura 1

Considerando-se fios elétricos como o meio de transmissão dos dados, existem três
formas de se constituir um barramento CAN, dependentes diretamente da quantidade
de fios utilizada. Existem redes baseadas em 1, 2 e 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 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 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 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 2 ilustra os níveis de tensão em
uma rede CAN, assim como os bits Dominantes e Recessivos.

Figura 2

Como mencionado no início, todos os módulos podem ser mestre e enviar suas
mensagens. Para tanto, o protocolo é suficientemente robusto para evitar a colisão
entre mensagens, utilizando-se de uma arbitragem bit a bit não destrutiva. Podemos
exemplificar esta situação, 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 prioridade maior (quando seu bit recessivo é sobrescrito por um
dominante). Este módulo, com maior prioridade, continuará normalmente sua
transmissão.

FORMATOS DAS MENSAGENS


Existem dois formatos de mensagens no protocolo CAN:

CAN 2.0A – Mensagens com identificador de 11 bits. É possível ter até 2048
mensagens em uma rede constituída sob este formato, o que pode caracterizar uma
limitação em determinadas aplicações. A Figura 3 apresenta o quadro de mensagem do
CAN 2.0A.

Figura 3

CAN 2.0B – Mensagens com identificador de 29 bits. É possível ter, aproximadamente,


537 milhões de mensagens em uma rede constituída sob este formato. Percebe-se 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 tempo de transmissão de cada mensagem, o que pode caracterizar um
problema em determinadas aplicações que trabalhem em tempo-real (problema
conhecido como overhead). A Figura 4 apresenta o quadro de mensagem do formato
CAN 2.0B.

Figura 4

PADRÕES EXISTENTES
Os fundamentos do CAN são especificados por duas normas: a ISO11898 e a
ISO11519-2. 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, ISO11519-2, 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 à 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 podemos 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.

  ISO 11783: 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.

DETECÇÃO DE FALHAS

Algumas das maiores vantagens do CAN é a sua robustez e a capacidade de se


adaptar às condições de falha, temporárias e/ou permanentes. Podemos classificar as
falhas de uma rede CAN em três categorias ou níveis: Nível de Bit, Nível de Mensagem
e Nível Físico.

Nível de Bit – Possui dois tipos de erro possíveis:

Bit Monitoring: Após a escrita de um bit dominante, o módulo transmissor verifica o


estado do barramento. Se o bit lido for recessivo, significará que existe um erro no
barramento.

Bit Stuffing: Apenas cinco bits consecutivos podem ter o mesmo valor (dominante ou
recessivo). Caso seja necessário transmitir seqüencialmente seis ou mais bits de
mesmo valor, o módulo transmissor inserirá, imediatamente após cada grupo de cinco
bits consecutivos iguais, um bit de valor contrário. O módulo receptor ficará
encarregado de, durante a leitura, retirar este bit, chamado de Stuff Bit. Caso uma
mensagem seja recebida com pelo menos seis bits consecutivos iguais, algo de errado
terá ocorrido no barramento.

Nível de Mensagem – São três os tipos de erro possíveis:

CRC ou Cyclic Redundancy Check: Funciona como um checksum. O módulo


transmissor calcula um valor em função dos bits da mensagem e o transmite
juntamente com ela. Os módulos receptores recalculam este CRC e verificam se este é
igual ao transmitido com a mensagem.

Frame Check: Os módulos receptores analisam o conteúdo de alguns bits da


mensagem recebida. Estes bits (seus valores) não mudam de mensagem para
mensagem e são determinados pelo padrão CAN.

Acknowledgment Error Check: Os módulos receptores respondem a cada mensagem


íntegra recebida, escrevendo um bit dominante no campo ACK de uma mensagem
resposta que é enviada ao módulo transmissor. Caso esta mensagem resposta não
seja recebida (pelo transmissor original da mensagem), significará que, ou a
mensagem de dados transmitida estava corrompida, ou nenhum módulo a recebeu.

Toda e qualquer falha acima mencionada, quando detectada por um ou mais módulos
receptores, fará com que estes coloquem uma mensagem de erro no barramento,
avisando toda a rede de que aquela mensagem continha um erro e que o transmissor
deverá reenviá-la.

Além disso, a cada mensagem erroneamente transmitida ou recebida, um contador de


erros é incrementado em uma unidade nos módulos receptores, e em oito unidades no
transmissor. Módulos com estes contadores iguais a zero são considerados Normais.
Para os casos em que os contadores contêm valores entre 1 e 127, os módulos são
considerados Error Active. Contadores contendo valores entre 128 e 255 colocam os
módulos em condição de Error Passive. Finalmente, para contadores contendo valores
superiores a 255, os módulos serão considerados em Bus Off e passarão a não mais
atuar no barramento. Estes contadores também são decrementados a medida que
mensagens corretas são recebidas, o que reduz o grau de incerteza em relação a
atividade dos módulos ora com contadores contendo valores diferentes de zero e
possibilita novamente a plena participação deles no barramento.

Nível Físico – Para os barramentos com 2 e 4 fios, caso algo de errado venha a
ocorrer com os fios de dados CAN_H e CAN_L, a rede continuará operando sob uma
espécie de modo de segurança. Seguem abaixo algumas das condições de falha nas
linhas de comunicação que permitem a continuidade das atividades da rede:

  Curto do CAN_H (ou CAN_L) para GND (ou VCC);


  Curto entre os fios de dados CAN_H e CAN_L;

  Ruptura do CAN_H (ou CAN_L);


ASPECTOS DE IMPLEMENTAÇÃO: DICIONÁRIO DE DADOS

É a parte mais dedicada à aplicação quando se trabalha com um protocolo como o


CAN. O Dicionário de Dados (ou Data Dictionary) é o conjunto de mensagens que
podem ser transmitidas naquela determinada rede.

A forma mais interessante de se organizar um dicionário de dados é criando uma matriz


com todos os módulos da rede. Esta matriz mostrará cada mensagem sob a
responsabilidade de cada módulo, relacionando quem a transmite e quem a recebe.
Outros dados importantes nesta matriz são: o tempo de atualização dos valores da
mensagem, o intervalo de transmissão da mesma e o valor relativo ao seu identificador.
Além desta matriz, a documentação referente ao Dicionário de Dados deverá conter
uma descrição detalhada de cada mensagem, bit a bit.

O Dicionário de Dados é implementado numa rede CAN via software e deverá ser o
mesmo (ter a mesma versão de atualização, inclusive) em todos os módulos
conectados à rede. Isto garantirá total compatibilidade entre os participantes do
barramento.

ASPECTOS DE IMPLEMENTAÇÃO: EXEMPLO DE REDE

Uma rede CAN, dependendo da sua aplicação, poderá ter até centenas de módulos
conectados. O valor máximo para a conexão de módulos em um barramento depende
da norma que se utiliza na dada aplicação.

Toda rede CAN possui 2 Terminadores. Estes terminadores nada mais são que
resistores com valores entre 120 e 124 ohms, conectados à rede para garantir a
perfeita propagação dos sinais elétricos pelos fios da mesma. Estes resistores, um em
cada ponta da rede, garantem a reflexão dos sinais no barramento e o correto
funcionamento da rede CAN.
Outra característica de determinadas aplicações fundamentadas no CAN é que estas
poderão ter duas ou mais sub-redes trabalhando, cada qual, em uma velocidade
diferente. Os dados são transferidos de uma sub-rede para a outra através de módulos
que atuam nas duas sub-redes. Estes módulos são chamados de Gateways.

A Figura 5 ilustra a rede CAN de um sistema automotivo, com duas sub-redes e dois
terminadores. O Gateway desta aplicação é o Painel de Instrumentos.

Figura 5

ASPECTOS DE IMPLEMENTAÇÃO: MONTAGEM DA REDE

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 (Unidades Eletrônicas de
Controle) 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 estarão 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. O sincronismo das operações
das ECUs no CAN é fundamentado no tempo de propagação física das mensagens no
barramento. Assim, a relação do comprimento de determinados intervalos do chicote no
barramento são fundamentais ao bom funcionamento da rede.

A Figura 6 mostra um diagrama que ilustra as medidas que devem ser observadas no
desenvolvimento do chicote.

Figura 6

Destacamos que, após o barramento ser 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.

Estas foram algumas informações técnicas de um dos protocolos de comunicação mais


utilizados atualmente em aplicações embarcadas.

CAN BUS
BARRAMENTO CONTROLLER AREA NETWORK
“IMPLEMENTAÇÃO”

por Alexandre de A. Guimarães, MSc

INTRODUÇÃO

A segunda parte deste artigo detalhou os principais conceitos do Protocolo CAN.


Abordamos a forma de transmissão dos dados, explicamos a lógica de arbitragem não
destrutiva e os formatos das mensagens, destacamos as diversas normas existentes e
baseadas no CAN Bus e relacionamos os diversos mecanismos de detecção de falhas
– por software e hardware – disponíveis no protocolo. Citamos ainda alguns aspectos
da implementação de uma rede CAN, destacando o Dicionário de Dados,
exemplificando uma rede atualmente aplicada em sistemas automotivos e fornecendo
algumas dicas sobre a montagem do cabeamento e terminadores da rede.

Para a terceira e última parte, que aborda a eletrônica embarcada e a sua relação com
o Protocolo CAN Bus, reservamos a discussão dos pontos mais relevantes no
momento de se projetar e implementar uma rede de comunicação de dados.

Vamos lá !
DETERMINAÇÃO DA ARQUITETURA

Considerando uma determinada aplicação, a primeira tarefa que devemos considerar


durante o projeto de sua rede de comunicação de dados é a determinação da sua
arquitetura. Neste ponto podemos 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.

Se tomarmos como ponto de partida uma aplicação onde as ECUs já estiverem


prontas, nossa responsabilidade 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.

Se considerarmos uma aplicação onde somente o escopo do sistema que se deseja


controlar estiver disponível, apesar de “partir do zero”, poderemos projetar as ECUs já
considerando os controladores capazes de, facilmente, estabelecer comunicação
fundamentada no protocolo CAN. Seguiremos então por esta linha de raciocínio.

A aplicação sobre a qual trabalharemos será simples. A Figura 1 apresenta a


arquitetura proposta.
Figura 1

Esta arquitetura mostra-se extremamente simples. De qualquer forma vale destacar:

  Serão duas ECUs conectadas por uma rede de comunicação CAN Bus, onde
ambas terão 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, poderemos


programar e monitorar o funcionamento de cada ECU.

ANÁLISE DA NORMA RELACIONADA À APLICAÇÃO


Como mencionado na segunda parte desta matéria, existem diversas normas
baseadas no protocolo CAN Bus, cada qual relacionada a uma classe de aplicações.
Vamos recordar algumas destas normas:

  NMEA 2000: Utilizada em aplicações navais e aéreas.


  SAE J1939: Utilizada em aplicações automotivas.

  DIN 9684 – LBS: Utilizada em aplicações agrícolas.

  ISO 11783: Utilizada em aplicações agrícolas.

Estas normas trazem informações específicas de cada classe de aplicações, como o


tipo de cabeamento e conectores necessários e os tipos de mensagens requeridas,
entre outras.

Neste nosso desenvolvimento, não nos preocuparemos com uma norma específica.
Trataremos simplesmente de projetar uma rede CAN considerando seu padrão de
empacotamente de dados e transmissão e, quando necessário, estabelecendo alguns
conceitos específicos para a nossa aplicação. O primeiro conceito que deveremos
estabelecer é o chamado Dicionário de Dados, já explicado na segunda parte desta
matéria.

DETERMINAÇÃO DO DICIONÁRIO DE DADOS


O Dicionário de Dados (D.D.) de uma aplicação pode ser resumidamente 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.

Vamos então estabelecer um D.D. para a nossa aplicação. A Tabela 1 traz as


informações importantes ao nosso trabalho.

Matriz TX - RX Bytes do Bytes de dados


Nome da Mensagem Identificador (ID)
ECU #1 ECU #2 D #1 D #2 D #3 D #4 D #5 D #6 D #7 D #8
1 Estado das Entradas da ECU #1 TX RX 12 34 56 78 XX 00 00 00 00 00 00 00
2 Estado das Saídas da ECU #1 TX RX 11 22 33 44 00 00 XX 00 00 00 00 00
3 Estado das Entradas da ECU #2 RX TX 87 65 43 21 XX 00 00 00 00 00 00 00
4 Estado das Saídas da ECU #2 RX TX 55 66 77 88 00 00 00 00 00 XX 00 00

Tabela 1

Analisando a Tabela 1 percebemos que, no nosso 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 “12345678 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
gostaríamos de fazer é 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 do nosso D.D. parecer simples, e realmente é, ele demonstra o que


efetivamente ocorre em uma aplicação real. Se analisarmos uma aplicação automotiva
por exemplo, teremos para ela, mensagens relacionadas ao funcionamento do motor,
dos freios ABS e dos sistemas de travamento e alarme, entre outras. Além disso, pela
complexidade dos sistemas envolvidos, não somente um byte de dados por mensagem
será utilizado (indicando a alteração do estado de uma determinada entrada). Teremos
a utilização de todos os oito bytes existentes.

Estabelecido o Dicionário de Dados pertinente à nossa 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 (exatamente por trabalhar dentro da
ECU).

Antes de abordarmos os softwares relacionados, falaremos sobre o projeto do


hardware das ECUs.

PROJETO DO HARDWARE DAS ECUs

Consideraremos ambas as ECUs baseadas no mesmo projeto de hardware - com a


mesma quantidade de Entradas e Saídas e uma porta de comunicação serial RS232.

Quando projetamos uma ECU para a sua utilização em uma rede de comunicação de
dados baseada no Protocolo CAN Bus, temos duas alternativas tecnológicas em
relação à execução do processamento: utilizar um Micro-Controlador (sem CAN)
conectado a um Controlador CAN (o que caracteriza dois CIs distintos e interligados)
ou utilizar um Micro-Controlador com CAN incorporado.
Quando utilizamos 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).

Quando utilizamos um Micro-Controlador sem CAN (conectando-o a um Controlador


CAN específico), este ficará 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).

O que determina a utilização de um conceito ou do outro é, basicamente, a


disponibilidade e o custo dos componentes. Do ponto de vista da implementação,
acreditamos 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).

Existem diversos fabricantes de CIs com vários tipos de Micro-Controladores


disponíveis (com CAN e sem CAN incorporado). As Tabelas 2 e 3 mostram alguns
fabricantes e seus componentes disponíveis. (ver data sheets para maiores informações)

Micro-Controladores com Controlador CAN


Fabricante Componente

Infineon C167CR-LM
Intel 87C196CA
Microchip 18Fxx8
Motorola 68376
Philips P8xC591

Tabela 2
Controladores CAN
Fabricante Componente

Infineon 81C90
Intel 82527
Microchip MCP2510
Philips SJA1000

Tabela 3

Nosso projeto do hardware considerará o Micro-Controlador com CAN incorporado


P87C591 (Philips).

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.

Existem diversos fabricantes de Transceivers CAN. A Tabela 4 mostra alguns


fabricantes e seus componentes disponíveis. (ver data sheets para maiores informações)

Transceivers CAN
Fabricante Componente

Bosch CF151
Infineon TLE6252G
PCA82C250
Philips
TJA1050

Tabela 4

Nosso projeto do hardware considerará o Transceiver PCA82C250 (Philips).


Definidos os dois componentes principais das nossas ECUs, passemos ao
entendimento de como conectá-los. A Figura 2 ilustra esta tarefa:

Figura 2

Através de dois fios conseguimos conector o Micro-Controlador ao Transceiver. Além


disso, a ECU é conectada à rede CAN por outros dois fios, CAN_H e CAN_L, já
mencionados na segunda parte desta matéria. Perceba também, na Figura 2, os dois
Terminadores de 124 Ohms. Eles podem estar conectados diretamente ao chicote ou,
no nosso caso, onde a aplicação possui somente duas ECUs, um em cada ECU.

Obviamente, na implementação efetiva de cada uma das ECUs, serão necessários


outros componentes além dos dois anteriormente mencionados – Micro-Controlador e
Transceiver. A Figura 3 mostra o diagrama elétrico das nossas ECUs, agora completas
(lembre-se de que o projeto de hardware de ambas é o mesmo !!!).
Figura 3

Por se tratarem de ECUs destinadas ao aprendizado do Protocolo CAN, optamos pelo


projeto apresentado, 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 – “Gravável somente uma vez”). Na memória EPROM gravamos um programa de
uma categoria conhecida como Monitor, enquanto que, na memória RAM, gravamos os
programas Principais das ECUs.

Vamos agora falar um pouco mais sobre as memórias, suas responsabilidades e os


diversos programas envolvidos.

PROJETO DO SOFTWARE DAS ECUs


São dois os tipos de firmware (software executado dentro das ECUs) utilizados no
nosso projeto:

  O primeiro é chamado de Monitor. É gravado na memória EPROM, a partir do


seu endereço 0000 hex, e passa a ser executado toda vez que a ECU é
reinicializada. A função principal deste programa Monitor é possibilitar a gravação e
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 exemplo, utilizando o aplicativo Hyper
Terminal do MS Windows, poderemos transferir o programa Principal da ECU para
a sua memória RAM. Qualquer programa Monitor para Micro-Controladores
similares ao 8051 poderá ser utilizado neste nosso projeto. Nós utilizamos um dos
vários Monitores disponíveis na internet ( PAULMON – www.pjrc.com/tech/8051/ - 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
– endereço 8000 hex). Este programa Principal é responsável pela leitura e
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 4 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 4

Ainda sobre o programa Principal, é necessário o desenvolvimento de algumas rotinas


que devem realizar as 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


pode ser compilado com o auxílio de qualquer compilador disponível na internet ( por
exemplo, o SDCC – Small Device C Compiler – www.sdcc.sourceforge.com - acesso em: 21 Nov 2001 ).

Alguns exemplos de rotinas programadas em C são mostradas a seguir:


  Início do Programa em C:

#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 */
}

  Inicialização do CAN Bus:

void init_can (void) /* Baud Rate de 125kbps e XTAL de 11,0592 */


/* Assumindo CAN2.0B (ID de 29bits) e DLC = 8 bytes */
{
BYTE i;
CANMOD = 0x01; /* Força o Modo Reset para inicialização */
P1M2 = P1M2 | 0x02; /* TXDC Port (P1.1) Configuração: */
/* Pin TXDC para push-pull */
/* P1M2.1='1', P1M1.1 = '0' (default) */

CANSTA = 0x03; /* Interrupções de Recepção e Transmissão habilitadas */

/* BTR0 e BTR1 determinam o Baud Rate e o Sample Point Position */


CANADR = BTR0;
CANDAT = 0x85;
CANADR = BTR1;
CANDAT = 0x2A;

/* Limpa as Máscaras e Filtros */


CANADR = ACR0;

for (i=1;i<=32;i++)
CANDAT = 0;

/* Configura os filtros para Extended Frame e Single Acceptance Filter */


CANADR = ACFMODE;
CANDAT = 0xFF; /* EFF e Single Long Filter */

CANADR = ACFENA;
CANDAT = 0xFF; /* Todos os Bancos e Filtros habilitados */

CANADR = ACFPRIO;
CANDAT = 0xFF; /* Mensagem aceita pelo filtro gera Interrupção */

CANADR = ACR0; /* ECU#1 - Receber somente o ID = 87654321 */


CANDAT = 0x87; /* Este valor vale p/ o programa Principal da ECU#1 */
CANDAT = 0x65; /* Para a ECU#2, alterar valores para 12345678 */
CANDAT = 0x43;
CANDAT = 0x21;

CANADR = AMR0; /* Todos os bits são verificados */


CANDAT = 0x00;
CANDAT = 0x00;
CANDAT = 0x00;
CANDAT = 0x00;

CANMOD = 0x00; /* Sai do Modo Reset */

while (CANSTA & 0x80); /* Monitora o Status do Barramento */


}

  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++)
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; /* CDO-Clr Data Overrun, AT-Abort Tx, TR-Tx Rqst */

return (1);
} else
return (0);
}

MONTAGEM DA REDE CAN

Na segunda parte desta matéria foram abordados vários aspectos relacionados à


montagem de uma rede CAN. De qualquer forma, preste muita atenção na bitola dos
cabos (secção transversal de cada um dos fios deve ser de no mínimo 0,35mm²), e na
geometria da rede (medidas que devem ser observadas no desenvolvimento do
chicote).

Para a realização de testes de comunicação CAN entre as ECUs descritas neste artigo,
sugerimos a utilização de conectores RJ45, facilmente encontrados no mercado.
Para que você tenha uma idéia da aparência de uma ECU montada a partir do projeto
aqui apresentado, veja sua foto na Figura 5.

Figura 5

Você também pode gostar