Protocolos de Comunicação

“... conjunto de regras que regem o formato e significado dos pacotes ou men- sagens que são trocadas por uma camada e sua entidade par em outra máquina. A camada usa protocolos para implementar suas definições de serviço e está livre para alterá-los, desde que não mude o serviço visível para os seus usuários (camadas ad- jacentes) "

A Society of automotive Engineers (SAE), divide os protocolos de comunicação em grupos que variam de acordo com as características dos protocolos, principalmente taxa de transmissão. Os grupos existentes são: Classe A, Classe B, Classe C, Diagnóstico, Mobile Media, Safety Bus, Drive by-wire. A listagem abaixo apresenta estes grupos e informações sobre cada um deles:

• Classe A: É um protocolo que habitualmente está ligado às funções de conforto no veículo e possui taxa de transmissão inferior a 10Kbps. Podem ser citados como exemplos de protocolos dessa classe SINEBUS, 1C, SAE J1708, CCD, ACP, BEAN e LIN.

• Classe B: A classe apresenta uma taxa de transmissão que varia de 10kps até 125 Kbp, as aplicações dos protocolos geralmente estão ligadas aos serviços de entretenimento do veículo. Exemplos de protocolo desta área são: SAE J1939, J1859 (classe 2), J1850 SCP E J1850 PCI.

• Classe C: Esta está com mais frequência ligada à serviços de sistema de segurança, apre- senta taxa de transmissão de 125Kbps a 1 Mbps. Exemplos de protocolos desta classe são: CAN 2.0 ISO 11898, ISO 11519-2 e SAE J139.

• Diagnóstico: Protocolos que são utilizados pelos sistemas de On-Board Diagnose, os principais exemplos desta classe são: J1850 Class 2, J1850 SCP, J1850 PCI, ISO 9141 e Keyword 2000.

• Mobile Media: Neste caso, os protocolos são utilizados predominantemente em sistemas de multimídia. Exemplos de protocolos são: IDB-C, MOST, MML, USB, IEEE-1394 • Safety Bus: Utilizados para sistemas de airbag. São citados como exemplo: BST, Safe

By wire, DSI e Byte Fight.

• Drivee by-wire: Utilizados por sistemas eletrônicos que substituíram sistemas que ante- riormente eram apenas mecânicos (aceleração, direção, ignição). São exemplos de proto- colos desta classe: TTP, Flex Ray e TTCAN

Dentre estes protocolos apresentados acima, o protocolo CAN é o mais utilizado em diferentes tipos de serviço, devido à sua grande aplicação ele será estudado mais afundo na próxima seção deste capítulo.

Protocolo CAN - Controlled Area Network

O protocolo CAN, foi apresentado pela Bosh em 1986, em Detroit, em um congresso promovido pela SAE, sendo que os primeiros circuitos CAN começaram a ser comercializados pela Intel e Philips em 1987 (KIENCKE; DAIS; LITSCHEL, 1986).

O protocolo CAN é um padrão de comunicação serial síncrono, que opera com o paradigma de multi-mestres, no qual os nós (representados pelas ECUs) podem tanto exercer o papel de mestre, quanto de escravo (KIENCKE; DAIS; LITSCHEL, 1986).

É um protocolo baseado em mensagens que não necessita de um gerenciador, já que as mensagens são enviadas multicast (todos os nós existentes na rede recebem as mensagens) (KI- ENCKE; DAIS; LITSCHEL, 1986). Caso mensagens precisem ser enviadas simultaneamente, existe um identificador de prioridade, que apenas a mais prioritária continue sendo enviada para todos os módulos da rede.

O protocolo CAN buscava substituir as diversas redes de comunicação que existiam entre os componentes eletrônicos, por uma solução mais leve, simples, eficiente e barata. (COR- RIGAN, 2008). A figura 2.7 contém um diagrama que exemplifica a topologia CAN.

Figura 2.7: Sem Rede CAN / Com Rede CAN

(INSTRUMENTS, 2014)

No ano de 1991 a Bosch publicou as especificações do protocolo CAN 2.0. Devido à sua grande aplicabilidade, em 1992, diversas companhias criaram a “CAN in Automation", uma organização que busca promover a tecnologia, provendo informativos técnicos, de produto e marketing.

Especificação Técnica

A maior taxa de transmissão especificada para o protocolo CAN é de 1 Mbits com uma rede com comprimento inferior à 40 m (FARSI; RATCLIFF; BARBOSA, 1999). Porém a velocidade para se transmitir os dados é inversamente proporcional ao comprimento do barra- mento, nestes casos pode ser interessante abrir mão da alta taxa de transmissão em função de uma rede mais extensa. A Figura 2.8, relaciona a velocidade de transmissão com o comprimento do chicote elétrico.

Figura 2.8: Taxa de Transmissão X comprimento do chicote

(GUIMARÃES; SARAIVA, 2002)

Os protocolos CAN podem ser classificados de acordo com a taxa de construção e a composição física do chicote (este pode ser composto de um cabo de cobre, 2 cabos de cobre trançados, ou 4 cabos de cobre trançados, que além dos sinais CANHS e CANLS, também con- duzem a tensão de alimentação e o aterramento) (CULLER; ESTRIN; SRIVASTAVA, 2004):

• High Speed CAN - possui taxa de transmissão de 1Mbps, composto por um par de fios trançados.

• Low Speed CAN - possui taxa de transmissão de 40kbps a 125 kbps, composto por fio simples.

• Time-Triggered CAN - taxa de transmissão de 1Mbps, composto de par de fios trançados • High-Speed CAN - taxa de transmissão de 1 Mbps, composto de par de fios trançados • Frame CAN - O frame de mensagem CAN pode ser configurado com dois padrões dife-

rentes (BARBOSA, 2003), sendo eles:

• CAN 2.0A - O identificador possui comprimento de 11 bits, sendo possível ter até 2048 mensagens

• CAN 2.0B O identificador possui 29 bits de comprimento, podendo ter até 537 milhões de mensagens.

Figura 2.9: Frame CAN

(INSTRUMENTS, 2014)

• SOF (Start-of-frame): Início de uma mensagem, com valor de bit dominante 0.

• Arbitration ID: Identifica a mensagem e sua prioridade. 11 bits no formato CAN 2.0A e 29 bits no formato 2.0B.

• IDE (Identifier Extension): bit que diferencia entre modos padrão e extendido.

• RTR (Remote Transmission Request): Diferencia entre frames remotos ou de dados. Quando igual a 0, representa um frame de dados, e quando 1, um frame remoto.

• SRR (Substitute Remote Request): Substitui o RTR para no formato de 29 bits • DLC (Data Length Code): Número de bits contidos no campo de dados

• Data: Contém as informações que deseja se transmitir na mensagem

• CRC (Cicle Redundancy Check): Utilizado para se verificar a integridade na transmissão • ACK (Acknowledge): Contém a informação de que a mensagem foi recebida sem erros,

enviado para a ECU que gerou a mensagem.

• EOF (End of Frame): Delimita o fim da mensagem.