CONTROLLER AREA NETWORK - FUNDAMENTOS

Pedro Venda Instituto Superior Técnico, Universidade Técnica de Lisboa

Portugal pjlv@mega.ist.utl.pt

Resumo Conceitos fundamentais, arquitectura, descrição do funcionamento e aplicações de uma rede do tipo fieldbus denominada CAN, numa perspectiva bottom-up. Palavras chave fieldbus, CAN, Sistemas distribuídos, CANOpen, CiA, Controller Area Network; 1. Introdução Foi após 3 anos de desenvolvimento que, no mês de Fevereiro de 1986 em Detroit, Robert Bosch apresentou um sistema de interligação de dispositivos numa rede de acesso múltiplo a um meio partilhado, denominado Controller Area Network (CAN). A primeira implementação do sistema surgiu um ano depois pela Intel® e desde então tem-se observado uma evolução significativa do hardware e do software que suportam o funcionamento da rede. 2. Motivação O sistema foi desenhado com vista na aplicação directa na indústria automóvel, dado que, na altura, nenhum dos outros sistemas de comunicação do tipo fieldbus cumpria por si só os requisitos dos engenheiros da Bosch®. As características essenciais da rede CAN, que no seu todo tornaram necessário o seu desenvolvimento, são [1]:

• Difusão de mensagens transmitidas; • Identificação de mensagens e não de nós; • Acesso múltiplo ao bus (partilhado); • Acordo mútuo, não destrutivo e sem atrasos de

acesso de escrita no bus (evita colisões); • Definição de prioridades nas mensagens; • Múltipla detecção de erros (confinamento de

faltas); • Retransmissão automática de mensagens

corrompidas; Um fieldbus é uma ligação múltipla de duas vias entre dispositivos de medida e/ou de controlo. É uma rede de área local - Local Area Network (LAN) – geralmente utilizada para processos de controlo, entradas/saídas

remotas e para aplicações de automação industrial de alta velocidade [2]. A rede CAN é um caso particular de um fieldbus. Em geral, uma rede CAN serve para qualquer aplicação onde diversos dispositivos controlados por um micro controlador precisam de comunicar, de forma a completar uma tarefa comum – sistemas distribuídos. Nas aplicações distribuídas críticas, os requisitos de elevada fiabilidade, tempo-real e confinamento de faltas tornam a utilização de CAN uma alternativa viável de comunicação entre os diversos dispositivos do sistema, tanto em termos de segurança na utilização como em termos de fornecimento fiável de serviços críticos a humanos. Exemplos dos casos mais críticos incluem dispositivos de segurança activa em automóveis ou aplicações de sistemas distribuídos na medicina [3]. Actualmente as redes CAN são utilizadas nos mais diversos ramos da tecnologia [3,4]:

• Indústria automóvel (In-Vehicle Network (IVN) para aplicações de funcionamento interno e, por exemplo, para comunicação com reboques);

• Transportes públicos e controlo de tráfego; • Indústria aeronáutica; • Maquinaria móvel (controlo remoto e

comunicação entre subsistemas internos); • Automação e controlo de sistemas industriais; • Dispositivos de gestão de edifícios (controlo de

temperatura, portas, ventilação, elevadores, escadas rolantes, etc.);

• Equipamento e dispositivos utilizados em medicina;

• Sistemas não industriais (máquinas de vendas e de jogos, fotocopiadoras e impressoras de alta qualidade, subsistemas de máquinas de interacção bancária, comunicação entre microscópios, etc)

3. Arquitectura do sistema de comunicação Face ao modelo ISO – Open Systems Interconnection (OSI), a especificação da rede CAN descreve apenas a camada física e a camada de ligação de dados (figura 1), ambas implementadas em hardware. Para facilitar a programação, e devido aos diferentes cenários de utilização, foram desenvolvidas diversas camadas de software que se posicionam na camada de aplicação.

Figura 1 – Modelo de camadas OSI e CAN.

4. Camada física A camada física de um sistema de comunicação cobre os aspectos da transmissão física dos dados (bits) entre os nós da rede. Desta camada destacam-se três sub-camadas [5]: • Physical signaling (PLS), implementada no

controlador CAN o Codificação/descodificação de bits; o Timing dos bits; o Sincronização entre nós;

• Physical Medium Attachment (PMA) o Características do transceiver;

• Medium Dependent Interface (MDI) o Características do meio de transmissão

(cabo, fichas, etc); Codificação: Uma stream (figura 2) de bits num bus CAN é codificada em non return to zero (NRZ), ou seja, na banda de base. Durante o tempo em que um nó transmite um bit, o bus pode estar num estado recessivo ou dominante, de acordo com o bit a ser transmitido. De facto, o bus tem três níveis lógicos: o estado dominante, o estado recessivo e o estado idle, onde nenhum nó está a transmitir [5].

Figura 2 – Exemplo de stream de bits transmitidos, codificados

em NRZ. A não implicação de uma mudança de estado no bus para cada bit transmitido dificulta a sincronização entre os nós, devido à codificação utilizada. No caso de uma sequência de bits iguais (recessivos ou dominantes), os nós podem ter dificuldades na sincronização entre si – podem não reconhecer os limites

dos bits. Para ultrapassar este problema, recorre-se ao bit stuffing. Durante a utilização do bus, são permitidos no máximo cinco bits consecutivos da mesma polaridade. Caso o nó pretenda transmitir mais do que o permitido, são introduzidos stuff-bits de polaridade inversa (pela camada de ligação de dados), de forma a garantir que de facto não existam mais do que cinco bits com a mesma polaridade1 no bus (figura 3). No pior caso, o stuffing adiciona bits não informativos num rácio de um stuff-bit para quatro bits de informação [5].

Figura 3 – Exemplo de bit stuffing numa stream de bits [5].

Timing: Cada nó CAN opera em sincronia com um oscilador que gera um sinal de frequência pré-programada. A cada conjunto de n períodos dessa frequência dá-se o nome de time-quantum (Tq), sendo o tempo de transmissão de cada bit (bit-time) definido como múltiplo de Tq. De facto, o bit-time subdivide-se em quatro segmentos distintos, cada um deles com duração múltipla de Tq. Existe um segmento de sincronização com duração de 1 Tq, um segmento de propagação com 1 a 8 Tq e dois segmentos de fase com 1 a 8 Tq cada (figura 4) [5,6].

Figura 4 – Esquema do timing de um bit.

O comprimento dos segmentos de propagação e de fase é programável, onde o dos segmentos de fase pode ser reajustado durante resincronizações. No total o bit-time dura entre 8 a 25 Tq. Finalmente, o transceiver do nó CAN amostra o nível do bus aproximadamente a ¾ do bit-time [5,6]. Sincronização de nós: Um nó sincronizado com o bus está dessincronizado com o emissor devido aos tempos de propagação. Numa rede CAN, um transmissor que envia um bit recessivo tem que ter a possibilidade de receber um bit dominante enviado por um nó sincronizado com o bus (e.g. ACK bit). Para tal, é necessário estender o bit-time ao longo destes quatro segmentos para garantir a coerência entre todos os nós da rede [7]. 1 Existem partes da trama, que vem da camada superior (ligação de dados), que não têm de obedecer à regra de stuffing.

Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6

Nivel recessivo

Nivel dominante

5V

0V t

V

Camadas do Modelo OSI

7 - Aplicação

6 - Apresentação

5 - Sessão

4 - Transporte

3 - Rede

2 – Ligação de dados

1 – Física

Camadas implementadas em

redes CAN

7 - Aplicação

2 – Ligação de dados

1 – Física

O segmento de sincronização é utilizado pelos vários nós para uma sincronização inicial – se existirem, as variações de estado do bus ocorrem durante este segmento. O segmento de propagação prevê a existência de um atraso de propagação e de processamento entre os vários nós da rede, que medeia a chegada do bit a cada um dos nós, e é usado para compensar esses atrasos. O instante entre os dois segmentos de fase (segmentos finais) define o instante de amostragem do bus [7]. Este elaborado esquema de timing serve para cada um dos nós esperar pelos atrasos dos sinais e pela estabilização do bit antes de amostrar o bus e determinar que tipo de bit está no canal [6]. No caso de um nó detectar uma variação do nível do bus fora do segmento de sincronização, as durações dos segmentos de fase são reprogramadas na altura, de forma a variar o instante de amostragem e garantir uma amostragem mais fiável. Em caso de avanço do bit, a duração do primeiro segmento de fase é encurtada num valor programado Resyncronization Jump Width (RJW), e no caso de um atraso da transição, a duração do segundo segmento de sincronização é alargada em RJW. A este mecanismo chama-se soft-syncronization e só ocorre uma vez em cada bit [5]. Em qualquer caso, a soma de todos os atrasos (processamento e propagação) do nó mais distante tem que ser menor do que o segmento de propagação. Este detalhe de sincronização vem limitar a relação ritmo de transmissão/comprimento do bus (figura 5) [5].

Figura 5 – Limitação da relação ritmo de transferência/comprimento do bus [5].

Quanto maior for o bus, mais significativos são os atrasos de propagação e maior tem que ser o bit-time, reduzindo o ritmo de transmissão máximo. É ainda possível a utilização de bridges e repetidores para estender o comprimento máximo do bus imposto [5]. O standard ISO 11898-2 define o bus como uma linha bifilar simples para minimizar as reflexões, terminada nas extremidades com resistências (figura 6). A linha tem três

estados de actividade: idle, bit recessivo e bit dominante. Estes estados são definidos pelas tensões diferenciais introduzidas/medidas na linha (VCAN_H – VCAN_L) pelos nós. Esta natureza diferencial da medida minimiza interferências electromagnéticas, dado que os dois fios do bus estarão fisicamente perto um do outro e, na presença de interferência, os efeitos sentidos em ambos serão semelhantes. Como a tensão é medida diferencialmente, o valor dessa interferência desaparece [5].

Figura 6 – Topologia de uma rede CAN [6]. Dentro de um nó CAN, o transceiver (figura 7) é responsável pela detecção e sinalização ao controlador de vários tipos de falhas no bus. Existem transceivers tolerantes a falhas que permitem um modo de operação single-wire a uma relação sinal-ruído reduzida, de forma a tolerar várias faltas do bus, como curto-circuitos entre as linhas CAN_H e CAN_L, entre as tensões de alimentação e as linhas ou ainda circuitos abertos em alguma linha [5].

Figura 7 – Nó CAN [5].

Finalmente, e para terminar a descrição da camada física, existe a possibilidade de que o bus seja ligado a transmissores RF ou infra-vermelhos como meio de estabelecimento de ligações de/ou para outras redes CAN [5]. 5. Implementação em hardware: A implementação de um nó CAN em hardware cobre a camada física, como já foi referido, e também a camada de ligação de dados. O hardware presente em cada nó pode ser dividido em três blocos funcionais (figura 8): o transceiver, o controlador CAN e o micro-processador.

Figura 8 – Blocos funcionais de um nó CAN [8].

Em particular, a camada física é implementada no transceiver e no exterior do nó (tomada, ficha, cabo, etc) e a camada de ligação de dados está no controlador. O papel do micro-controlador no protocolo de comunicações é a implementação das camadas superiores pretendidas pelo utilizador através da programação do software adequado. Este bloco (micro-controlador) pode ser dedicado ao interface de comunicação do nó ou partilhado por outros periféricos, enquanto que todos os outros blocos se dedicam exclusivamente às suas funções no protocolo de comunicação. Um nó CAN pode ter os três blocos funcionais implementados separadamente ou integrados em diversas formas. Cada solução de integração tem vantagens e desvantagens face às outras, mas a que parece ser mais popular é aquela em que o controlador CAN está integrado no micro-controlador, com o transceiver independente [8]. 6. Camada de ligação de dados A camada de ligação de dados - Data Link Layer (DLL) - impõe o formato das mensagens que viajam no bus e fornece mecanismos de detecção e prevenção de falhas. Existe uma subdivisão desta camada de forma a distinguir níveis de serviço fornecidos [9]: • Logical Link Control (LLC)

o Filtro de aceitação de mensagens; o Notificação de overload; o Gestão de recuperação de mensagens ou de

situações de erro; • Medium Access Control (MAC)

o Encapsulamento/desencapsulamento dos dados nas mensagens;

o Codificação das mensagens (stuffing/de-stuffing);

o Gestão de acesso ao meio; o Detecção e sinalização de erros; o Confirmação da integridade das mensagens

(acknowledge); o Serialização/Desserialização da informação;

Versões: Actualmente existem duas versões de mensagens especificadas: mensagens standard e extended. Por este motivo, o hardware pode eventualmente ser implementado tendo em conta as duas

versões. Para isso foram diferenciadas três especificações do protocolo da ligação de dados: protocolo 2.0A, 2.0B passivo e 2.0B activo. Destes, apenas o protocolo 2.0B activo consegue receber e transmitir de forma transparente as mensagens das duas versões. O protocolo 2.0B passivo consegue receber as mensagens das duas versões mas apenas transmite mensagens standard, enquanto que o protocolo 2.0A descarta todas as mensagens extended recebidas porque as reconhece como erros [9]. Filtro de aceitação de mensagens: Na subcamada LLC da DLL existe um mecanismo que filtra as mensagens que recebe, ou seja, existe uma ou várias máscaras de bits de comprimento variável que são sobrepostas (AND) com os n primeiros bits do identificador da mensagem, de forma a decidir se a mensagem é entregue à camada acima ou descartada. Este mecanismo é programável pelas camadas superiores ou, em ultima análise, pelo utilizador [9]. Funcionalidades adicionais: Na implementação do controlador, existe a possibilidade de incluir funções não previstas na espeficicação, tais como: contadores (adicionais) de erros, timestamps nas mensagens, limites de aviso programáveis, geração de pedidos de interrupção, estado de consumo reduzido e contadores de mensagens sem erros [9]. Serialização/encapsulamento, desserialização/desencapsulamento: Ao receber informação da camada superior, a subcamada MAC da DLL tem que serializar e encapsular a informação, ou seja, é preciso transformar cada byte recebido numa sequência de bits, para possibilitar a transmissão em série no bus. Essa sequência de bits é então segmentada e cada segmento é inserido numa mensagem criada para o receber [9]. Stuffing/destuffing: Sempre que o transmissor detectar a presença de 5 bits consecutivos da mesma polaridade numa stream de bits (após a serialização), introduz um bit de polaridade inversa que vai ser automaticamente removido pelos receptores (figura 3) [9]. Esta regra de stuffing pode ser utilizada para uma verificação de integridade. Na construção de uma mensagem, o nó transmissor preenche o cabeçalho e a terminação, executa o processo de stuffing em determinadas zonas da mensagem e calcula o CRC (referido mais tarde). Nesta altura, a mensagem está pronta para ser enviada. Nos nós receptores o processo é inverso. Após a recepção da mensagem sem erros detectados no bus, ela é destuffed, os campos de correcção de erros são verificados, passa pelo filtro de aceitação e, caso seja essa a decisão, os bits podem ser novamente agrupados em bytes e enviados à camada acima.

Difusão: O conceito de difusão da rede CAN significa que todos os nós vêem as mensagens transmitidas por qualquer um deles (figura 9). Após a recepção de cada mensagem, cabe aos nós a decisão de descarte ou entrega da mensagem [9].

Figura 9 – Difusão de mensagens [9]. Remote frame handling: A maioria das implementações com armazenamento de objectos transmitidos (FullCAN) integra um mecanismo de retransmissão de mensagens - Remote Transmission Request (RTR) - por pedido de outros nós. Dependendo da arquitectura do controlador, esta retransmissão pode ser feita por autorização do CPU, sem conhecimento do CPU ou com conhecimento/autorização opcional do CPU [9]. O método utilizado para a retransmissão é semelhante a um processo de pergunta/resposta: o nó interessado envia uma trama do tipo remote frame request (pergunta) onde especifica a mensagem em que está interessado. Esta trama será eventualmente recebida por algum nó que ainda tenha a mensagem. Este nó responde então com a mensagem pretendida. A mensagem reenviada pode também ser recebida por outros nós interessados. Os remote frame requests são claramente distinguíveis das mensagens de dados por uma flag explicitamente assinalada e pelo facto de não conterem dados [9]. Acesso múltiplo: Um dos requisitos de uma rede CAN é a possibilidade de acesso múltiplo ao bus, ou seja, vários nós podem ler do bus ao mesmo tempo mas, para evitar colisões (dois ou mais nós a enviar ao mesmo tempo uma mensagem diferente, o que resultaria numa mensagem inválida), é preciso um mecanismo de prioridades. O mecanismo utilizado é o Carrier Sense Multiple Access/Deterministic Collision Resolution (CSMA/DCR) [9]. Cada mensagem leva consigo um identificador, uma identidade que é atríbuida pelo nó. Quando o bus está em estado idle, vários nós podem iniciar as suas transmissões ao mesmo tempo. Cada nó lê do bus a cada bit que envia e compara os valores. Caso o bit que o nó tenha tentado escrever seja recessivo, será lido do bus um bit recessivo se e só se todos os nós que estão a transmitir na altura estiverem a enviar um bit recessivo. Por definição, o

transceiver garante que um bit dominante permanece no bus em detrimento de um bit recessivo [9] (figura 10).

Figura 10 – Ausência de colisões por utilização de CSMA/DCR [6].

Durante a transmissão do identificador da mensagem, o algoritmo CSMA/DCR decide de forma unívoca, não destrutiva e sem atrasos ou retransmissões quem transmite ou não a mensagem. No funcionamento do algoritmo CSMA/DCR em que n nós tentam escrever no bus, e assumindo que todos tentam enviar mensagens diferentes, n-1 nós vão desistir de transmitir a mensagem para que o restante nó possa transmitir a dele. Depois da transmissão da mensagem do nó que “ganhou” o bus, os outros nós tentam novamente transmitir as suas mensagens. Com a utilização do algoritmo CSMA/DCR, é possível estabelecer ordens de prioridade nas mensagens, porque estas têm identificadores programáveis [6,9]. A figura 10 mostra um exemplo de funcionamento do algoritmo CSMA/DCR. O caso descrito mostra três nós (1,k,n) a tentar enviar uma mensagem a dada altura. No bit 7, o nó 1 percebe que enviou um bit recessivo mas leu do bus um bit dominante e desiste de enviar a sua mensagem – fica em modo de escuta apenas. No bit 3, o nó n também entende que enviou um bit recessivo mas leu um bit dominante. Também este nó desiste de transmitir a mensagem. Desta forma, o nó k prevalece e transmite a sua mensagem. Serviços de comunicação fornecidos pelo protocolo CAN: O protocolo CAN especifica dois serviços de comunicação: o serviço write-object e o serviço read-object. O serviço write-object é o serviço que escreve uma mensagem de um nó (emissor) para o bus e, consequentemente, para todos os nós a ele ligados (serviço básico do protocolo). Este serviço não implica que algum nó esteja interessado na mensagem [9]. O serviço read-object é o complementar do anterior e é iniciado pelo facto de um receptor interessado numa trama transmitir uma mensagem de RTR com a identificação dessa trama. Se algum nó tiver os dados pretendidos, envia de volta a trama correspondente [9].

Data frame: Até agora referenciadas genericamente como mensagens, as tramas de dados (data frames) são as unidades de comunicação entre as camadas de ligação de dados dos vários nós [9] (figura 11).

Figura 11 – Trama de dados [9].

Sempre que um nó pretende enviar dados para o bus, fá-lo através do encapsulamento da informação em uma ou mais tramas, em que cada uma pode transportar 1 a 8 bytes de informação. O data frame começa com um bit Start of Frame (SoF) para hard synchronization em todos os nós. Depois do SoF está o campo de identificação (arbitration field) que identifica a prioridade e o conteúdo da mensagem. O campo de controlo (control field) especifica o comprimento em bytes da mensagem. O campo de dados (data field) contém a informação propriamente dita e o campo de CRC (cyclic redundancy check) guarda informação redundante para detecção de erros em determinadas zonas da trama. O campo de confirmação (Acknowledge field - ACK) é utilizado para o transmissor entender se pelo menos um nó recebeu a mensagem sem erros de bus. A mensagem é terminada pelo End of Frame (EoF). Actualmente, existem dois tipos de tramas: standard data frames e extended data frames. Os dois tipos diferem no significado de algumas flags e no comprimento do campo de identificação. Entre duas mensagens sequenciais existe um conjunto de três bits recessivos a que se chama Intermission Frame Space [9]. O bit SoF foi em tempos utilizado para uma sincronização forçada, mas as especificações mais recentes tornam essa sincronização desnecessária. O campo de identificação (figura 12) é utilizado pelo algoritmo CSMA/DCR para determinar o nó a transmitir a mensagem. O bit final do campo de identificação – Remote Transmission Request (RTR) – é utilizado no estado recessivo para marcar as mensagens como RTRs. O bit seguinte – Identifier Extension (IDE) – serve para distinguir mensagens standard de extended. A mensagem standard tem o bit IDE dominante para que, em caso de transmissão simultânea, a mensagem standard prevaleça [9].

Figura 12 – Diferença entre tramas de dados standard e extended.

Até à ocorrência do bit IDE, o nó não sabe ainda se a trama é extended ou standard. Se o bit IDE for

dominante, o nó entende-o como o bit rv1 do campo de controlo de uma mensagem standard. Se o bit for recessivo, então a trama é extended e o bit é o bit IDE do arbitration field após o Substitute Remote Request (SRR), que é transmitido recessivo. Para terminar o campo de identificação das mensagens extended, existe ainda um campo de identificação extra de 18 bits e 1 bit RTR (verdadeiro), totalizando 32 bits de comprimento para este campo (11+SRR+IDE+18+RTR). O campo de controlo (figura 13) é semelhante nos dois tipos de mensagem. Os dois primeiros bits são dominantes e os últimos quatro especificam o comprimento do campo de dados (em bytes) – Data Length Code (DLC). Dado que o campo de dados tem de 1 a 8 bytes, os restantes valores do DLC (9-F) podem ser usados livremente (como o controlador for programado) [9].

Figura 13 – Campo de controlo.

O campo de dados – Data Field – leva a informação na mensagem num comprimento entre 0 e 8 bytes (64 bits). O campo de CRC é composto por uma sequência CRC de 15 bits e um bit limitador recessivo (CRC delimiter). A sequência CRC usada provém de um código de hamming de distância mínima de 6, o que significa que possibilita a detecção de 15 erros no máximo ou a correcção de 1 a 5 erros espalhados aleatoriamente dentro dos bits protegidos pelo CRC [9]. O campo de ACK (figura 14) é utilizado para que o emissor saiba se pelo menos um nó na rede recebeu a mensagem livre de erros até ao momento. Este é composto por dois bits: ACK Slot e ACK delimiter. O transmissor envia ambos os bits recessivos e cada receptor que tenha recebido a mensagem correctamente até ao campo de ACK, envia um ACK slot dominante. Se o transmissor percebe que enviou um ACK delimiter recessivo mas detectou um bit dominante no bus, sabe que pelo menos um nó enviou um ACK delimiter dominante – esse nó recebeu a mensagem correctamente até aí. Finalmente, o campo EoF é composto por sete bits recessivos e foi introduzido para garantir que, se algum nó enviar uma error flag, essa flag fica contida dentro da mensagem [9].

Figura 14 – Campo de CRC.

Tratamento de erros: Cabe aos dispositivos físicos e às camadas de hardware a introdução de mecanismos de tolerância a falhas na comunicação. Num dado nó (nó k), o tratamento de erros processa-se da seguinte forma [9]:

1. o nó k detecta o erro local; 2. é enviada uma error flag para globalizar o erro –

6 bits da mesma polaridade para forçar um erro de stuffing nos outros nós;

Base identifier

11 bit

RTR

1 bit

Arbitration Field

12 bit

Arbitration Field

32 bit

Base Identifier

11 bit

SRR

1 bit

IDE

1 bit

Identifier extension

18 bit

RTR

1 bit

Trama standard

Trama extended

Control Field

6 bit

rv1 DLC rv0

1 bit 1 bit 4 bit

CRC Field

16 bit

CRC Sequence

15 bit

CRC Delimiter

1 bit

3. depois da error flag é enviada uma overlapping error flag, seguida de um error delimiter;

4. a mensagem é descartada em todos os nós; 5. os contadores de erro são incrementados em

todos os nós; 6. a transmissão é repetida automaticamente;

Os erros são portanto assinalados e globalizados assim que são detectados. Através deste processo de tratamento de erros, caso nenhum nó esteja em estado passivo ou em bus off, a coerência dos dados é garantida, à parte de um efeito pernicioso no bit final da mensagem [6]. Na ocorrência de um erro, é enviada uma trama de erro activa (active error frame) (figura 15). A error flag é uma sequência de 6 bits dominantes (para um nó no estado activo) e é seguida de sobreposições de error flags dos outros nós, pois é possível que nem todos detectem o erro exactamente no mesmo bit. Finalmente, existe o delimitador do erro – error delimiter – que é composto por 8 bits recessivos e permite aos nós recomeçar a transmissão após a ocorrência de um erro. Depois da active error frame, é esperado um interframe space de 3 bits como se a trama de erro fosse uma mensagem [9].

Figura 15 – Trama de erro activa [9]. Os erros que podem surgir e que causar a geração de uma trama de erro são:

• erros de stuffing: quando um receptor detecta uma sequência de mais do que 5 bits da mesma polaridade nas zonas da mensagem protegidas pela regra de stuffing [9] (figura 16);

Figura 16 – Área da trama a ser stuffed [9].

• erros de bit: quando um nó escreve uma sequência de bits no bus, ele lê o estado do bus ao mesmo tempo. Quando o nó lê do bus um estado diferente do estado do bit que ele tenta transmitir, detecta um erro de bit. Se este erro de bit ocorrer nas zonas da mensagem em que não podem haver “colisões”, o erro é assinalado e globalizado no bus [9] (figura 17);

Figura 17 – Área da trama em que ocorre monitorização de bits [9].

• erro de CRC: o transmissor calcula o campo de

CRC sobre as zonas da trama protegidas e envia essa informação na mensagem. Os receptores voltam a calcular o CRC e comparam o resultado com o campo que receberam. Nos nós em o resultado não corresponda ao CRC recebido na mensagem, esta é descartada (não há correcção de erros) e uma trama de erro activa é gerada a seguir ao ACK delimiter (figura 18) [9];

Figura 18 – Área da trama protegida pelo campo de CRC [9].

• erro de ACK: quando o transmissor envia a mensagem e monitoriza o bus, envia um bit recessivo no ACK delimiter e espera receber um bit dominante do bus (no mesmo bit-time), pois qualquer receptor que tenha recebido a mensagem correctamente envia um bit dominante. Caso o transmissor não detecte este bit recessivo, nenhum receptor recebeu a mensagem sem erros e é gerada uma trama de erro activa a seguir ao ACK delimiter [9];

• erro de forma (form error): Se o transmissor encontra um bit dominante no CRC delimiter, um bit recessivo no ACK delimiter ou um bit dominante ao longo de todo o EoF, ocorreu um erro que viola o formato da trama em bits cujo estado não varia entre mensagens. Também neste caso é gerada uma trama de erro activa [9];

Apesar destes métodos de detecção de erros, é possível que existam erros não detectados no bus. Estima-se que a probabilidade da ocorrência de erros não detectados em tramas standard seja dada pela seguinte fórmula empírica:

. Por exemplo, com um erro a cada 0.7s e um ritmo de transmissão de 500kbps, obtém-se um erro não detectado por cada mil anos. Esta probabilidade aumenta para tramas extended [9].

rateerror _107.4 11 ××< −ρ

Para distinguir entre falhas temporárias (interferências ou outros erros temporários) e falhas permanentes (nó defeituoso ou ligação defeituosa ao nó, etc), são utilizados os contadores de erro (Transmit Error Counter (TEC) e Receive Error Counter (REC)) para alterar o estado do nó [9] (figura 19):

• Todos os nós iniciam a actividade no estado activo;

• Os contadores são incrementados e decrementados respectivamente na detecção de erros e nas transmissões ou recepções correctas;

• Quando um dos contadores passa por um threshold (programado ou não), muda para o estado passivo;

• No estado passivo, os contadores continuam a ser incrementados ou decrementados e, se forem novamente inferiores ao threshold, o nó volta a estar no estado activo. Neste caso existe uma elevada taxa de erros, mas aparentemente o nó em questão consegue enviar e receber correctamente as mensagens. Neste estado passivo, os nós apenas conseguem enviar tramas de erro passivas (passive error frames), em que os bits da error flag e sobreposições são recessivos, e portanto não conseguem interromper outras transmissões. Além disso, os nós em estado passivo têm que esperar um tempo adicional de 8 bits entre transmissões sucessivas. Quando um nó entra em estado passivo, a coerência dos dados deixa de ser garantida;

• No caso de falha da ligação ao bus ou de falha do controlador CAN, ou até no caso de acumulação extrema de erros, os contadores aumentam acima de um outro threshold e aí entram num estado de bus off em que apenas conseguem receber informação. Para sair deste estado, é preciso impor um reset e receber uma sequência de 128 × 11 bits recessivos;

Figura 19 – Diagrama de estados de um nó CAN, face à ocorrência de erros temporários ou permanentes [9].

Overload flag: A trama de overload é em tudo igual à trama de erro activa, mas não incrementa os contadores de erro e é enviada quando um nó não está pronto para iniciar a recepção da próxima mensagem, ou se durante o intermission space um dos primeiros dois bits é dominante. A outra condição de overload é quando um receptor recebe um bit dominante na sétima posição do EoF; este bit não é considerado um erro mas o receptor pode ter perdido a sincronização e inicia a transmissão de uma trama de overload. Neste caso, um transmissor que

se prepare para enviar uma mensagem tem que atrasar o início da sua transmissão [9]. Erros locais no EoF: Na ocorrência de erros durante a transmissão/recepção do EoF (neste campo da mensagem apenas podem ocorrer erros de bit), os nós procedem da seguinte forma:

• O transmissor considera a mensagem válida se não houver erros de bit até ao fim do EoF.

• O receptor considera a mensagem válida se não encontrar erros de bit até ao penúltimo bit do EoF (inclusive). Um receptor que tenha detectado um erro no sétimo bit do EoF não transmite a trama de erro nem incrementa os contadores de erro (não considera o erro), mas envia uma trama de overload que começa no interframe space [9].

Duplicação de mensagens: No caso da ocorrência de um erro local no último bit do EoF no transmissor ou no penúltimo bit do EoF num receptor, existe a possibilidade da duplicação da mensagem. Em particular, existe um caso pernicioso em que num nó receptor k existe de facto um erro local no penúltmo bit do EoF. No último bit do EoF, este nó inicia a transmissão de uma trama de erro activa que é vista pelo transmissor t como tal. Entretanto, um outro receptor n não sofreu a interferência que deu origem ao erro no penúltimo bit do EoF e vê este bit recessivo (como devia ser), embora receba no último bit do EoF o início da trama de erro activa, iniciada pelo nó k. Como este erro é ignorado (pelo receptor n), o nó acaba por ficar com a mensagem intacta e inicia a transmissão de uma trama de overload. No cenário final, o nó t transmite duas vezes a mensagem, o nó n recebe a mensagem duas vezes e o nó k recebe-a uma vez. Para evitar problemas relacionados com a duplicação de mensagens, a especificação da CiA aconselha a não utilização de mensagens do tipo toggle (“muda de estado”), a não utilização de mensagens de comando relativas (“varia 10 graus”,”avança 10 metros”, etc) e, para prevenir inversões de ordem, aconselha também a utilização de números de sequência nas mensagens [9]. Estes conselhos terão que ser postos em prática nas camadas superiores do protocolo e podem vir a garantir, por exemplo, difusão FIFO (FIFO broadcasting). 7. Camada de aplicação A família de protocolos CANOpen especifica standards para mecanismos de comunicação e funcionalidades dos dispositivos. A especificação cobre na sua maior parte a camada de aplicação, definindo aí um perfil de comunicações e frameworks para a programação dos dispositivos, mas define também recomendações para as camadas física (cabos e fichas) e ligação de dados [10]. Desenvolvida pela CiA, a camada CANOpen foi implementada originalmente para utilização em sistemas de controlo industrial. Neste momento, CANOpen tem

um leque variado de campos de aplicação, como equipamento médico, automação de edifícios, electrónica na aeronáutica, etc [10]. O sistema de comunicação definido pela sigla CANOpen pode ser descrito de forma semelhante ao modelo OSI, em que existe uma camada de aplicação e um perfil de comunicações standard, apoiada nas camadas física e de ligação de dados de uma rede CAN [10]. Ao nível da camada de aplicação, o protocolo CANOpen troca entre si objectos de comunicação e aplicação (figura 20) [10].

Figura 20 – Topologia dos dados trocados na camada de aplicação [10].

Um dispositivo CANOpen está dividido em três blocos fundamentais (figura 21): [10]

• Protocolo e interface de comunicação; • Dicionário de objectos; • Interface e programa de aplicação;

O interface de comunicação fornece os serviços de transmissão e recepção de objectos entre nós do bus. O dicionário de objectos descreve todos os tipos de dados, objectos de comunicação e objectos de aplicação utilizados numa implementação. O programa de aplicação disponibiliza a funcionalidade de controlo interno e o interface com o hardware dos dispositivos [10].

Figura 21 – Blocos funcionais da camada CANOpen [10].

Interface de comunicação: Os vários tipos de objectos de comunicação utilizados estão classificados por funcionalidade [10]:

• Process Data Objects (PDO): transferência de dados em tempo real;

• Service Data Objects (SDO): acesso de leitura e escrita em dicionários remotos;

• Objectos de função específica: mensagens de sincronização, de temporização e de emergência;

• Network Management Objects (NMT): fornecem serviços para a inicialização da rede, controlo de erros e controlo de status dos nós;

A comunicação por PDOs é do tipo difusão (figura 22) em que, por decisão própria ou por pedido de outro nó, o transmissor difunde um PDO para o bus. O PDO consiste numa só trama de dados da DLL (pode transportar até 8 bytes de informação) e não disponibiliza confirmação de entrega [10].

Figura 22 – Esquema de transmissão de um PDO [10].

O SDO é utilizado para o acesso remoto de entradas do dicionário de objectos. A topologia da comunicação é do tipo cliente-servidor, em que o cliente pede o acesso (de leitura e/ou escrita) ao dicionário remoto com um SDO e o servidor responde com outro SDO (figura 23). Um SDO pode transferir dados de qualquer tamanho através de sequências de segmentos [10].

Figura 23 – Esquema de transmissão de um SDO [10].

O objecto de sincronização (SYNC) é difundido por um nó sincronizador com o fim de conseguir realizar tarefas periodicamente ou em instantes definidos. Para garantir a sincronização, o SYNC é difundido numa trama de ligação de dados com uma prioridade muito alta. Uma aplicação que envolve a utilização de SYNCs é, por exemplo, a transmissão periódica de PDOs de um nó que recolhe dados de um sensor (polling) [10]. O timestamp é um objecto transmitido em difusão e também é utilizado para obter sincronização entre nós. Em redes grandes com ritmos de transmissão reduzidos, algumas aplicações críticas requerem sincronizações muito precisas, necessitando então de timestamps. A prioridade deste objecto é também elevada, para minimizar o atraso de transmissão [10].

As mensagens de emergência são difundidas uma só vez, com alta prioridade, pelos nós nos quais ocorrem situações de erro fatais, de forma a avisar os restantes nós [10]. A utilização dos NMTs prende-se com a gestão da rede e adopta uma topologia do tipo cliente-servidor, com servidor fixo. A gestão da rede envolve serviços de controlo de erros, serviços de configuração de nós remotos e serviços de inicialização [10]. Dicionário de objectos: O bloco mais importante de um dispositivo CANOpen é o dicionário de objectos, composto por um grupo ordenado de definições de objectos acessíveis pela rede. Cada nó da rede tem o seu dicionário que utiliza para interagir com os outros nós, através dos objectos de comunicação já descritos. Cada dicionário tem grupos de objectos standard, grupos de objectos definidos para o ambiente de utilização pretendido (geralmente definidos pelos fabricantes em standards públicos), e ainda grupos de objectos a definir pelo utilizador [10]. No dicionário, estão os objectos de comunicação, os tipos de dados que os nós podem trocar entre si, os objectos de erro, etc. Sempre que um nó pretende executar uma tarefa, qualquer que ela seja, tem de retirar a informação a tratar do dicionário, chamar o objecto de comunicação adequado do dicionário e, opcionalmente, verificar o sucesso da sua tarefa através de um outro acesso ao seu dicionário ou a um dicionário remoto. Interface de aplicação: Este é o bloco da camada CANOpen mais próxima do hardware. Neste nível, os fabricantes definem perfis de objectos aplicáveis aos diversos cenários de utilização. Os perfis são compostos por conjuntos de objectos de aplicação suportados, objectos de erro (códigos e mensagens) e tipos de dados. Cada perfil é aplicado no dicionário de objectos e define de forma grosseira a função da rede no ambiente em que esta se insere. Por exemplo, existem perfis de servos e controlo de movimento, interface pessoa-máquina, dispositivos de medida, codificadores, etc. [10]. Através da utilização da família de protocolos CANOpen e da escolha adequada do perfil de objectos, a comunicação entre os nós de rede torna-se muito simplificada e permite a interacção de dispositivos desenvolvidos separadamente. 8. Conclusões O funcionamento aparentemente complexo das duas primeiras camadas do nó CAN justifica-se pelos rigorosos requisitos utilizados na sua especificação. O campo de aplicação das redes CAN é praticamente ilimitado. Desde aplicações triviais como o controlo da

abertura de vidros eléctricos num automóvel até aplicações críticas utilizadas, por exemplo, em medicina, a rede CAN mostra-se versátil e tolerante a erros de forma a garantir o seu funcionamento fiável. A rede CAN é o fieldbus preferido pela indústria (figura 24), tornando natural o desenvolvimento de dispositivos, não porque é “moda” mas sim para garantir a compatibilidade face aos que já existem.

0 1000000 2000000 3000000 4000000 5000000 6000000

CAN

BITBUS

LONWORKS

Interbus-S

PROFIBUS

WorldFIP

P-Net

Number of Units Figura 24 – Utilização do fieldbus CAN face a concorrentes.

Através da utilização da camada de aplicação CANOpen, torna-se fácil, numa rede CAN, a interacção entre os dispositivos do mesmo ambiente de funcionamento. Além disso, a camada CANOpen permite também facilitar a integração de novos dispositivos na rede, possivelmente desenvolvidos por entidades alheias à rede, através da utilização do perfil de aplicação adequado. 9. Agradecimentos Ao Professor José Rufino pelo material gentilmente cedido. 10. Referências [1] CiA, CANOpen@space, CANSpace december 5th, 2002 Noordwijk (Netherland). [2] http://www.dspclips.com/fieldbus.htm [3] CiA, CAN Application Fields [4] http://www.canopen.org/applications/ [5] CiA, CAN Physical Layer [6] J. Rufino, Controller Area Network – an overview, 1997 [7] F. Hartwich, A. Bassemir, The configuration of the CAN bit timing, 6th International CAN Conference, Turin (Italy) [8] CiA, CAN Implementation [9] CiA, CAN Data Link Layer [10] CiA, CAN CANOpen