derick-silva

•

Humanas / Sociais

Revisando com resumos

27/03/2023

E aí, curtiu este material?

Ajude a incentivar outros estudantes a melhorar o conteúdo

Gostou desse material? Compartilhe! 🧡

Trabalho de Conclusão de Curso - TCC

95.999 Materiais compartilhados

Baixe o app para aproveitar ainda mais

Leia os materiais offline, sem usar a internet. Além de vários outros recursos!

Prévia do material em texto

UNIVERSIDADE FEDERAL DE MINAS GERAIS
ESCOLA DE ENGENHARIA

CURSO DE GRADUAÇÃO EM ENGENHARIA DE CONTROLE E AUTOMAÇÃO

IMPLEMENTAÇÃO DE UMA REDE CANOPEN PARA CONTROLE DE VEÍCULOS
AUTÔNOMOS

Derick Henrique de Jesus Silva

Monografia de Graduação submetida à banca
examinadora designada pelo Colegiado do Curso de
Graduação em Engenharia de Controle e
Automação da Universidade Federal de Minas
Gerais, como parte dos requisitos necessários à
aprovação na disciplina Projeto Final de Curso II.

07 de Julho de 2011
2

ResumoResumoResumoResumo

Palavras-chave: Controller Area Network (CAN), CANopen, Dicionário de Objetos.
O protocolo CAN (Controller Area Network) desenvolvido pela Bosch e padronizado pela
norma ISO 11898, é um dos mais disseminados na indústria automobilística e utilizado na
maioria dos sistemas embarcados presentes nos automóveis. No projeto de um veículo
autônomo, é mais adequado que os sistemas sejam implementados usando CAN para criar
um conjunto homogêneo que possa comunicar entre si mais facilmente. O protocolo CAN
especifica as características da camada física e de enlace segundo o modelo OSI/ISO. Uma
grande gama de protocolos para camada de aplicação está disponível no mercado e, no que
diz respeito a construção de sistemas embarcados, as opções para o desenvolvedor são
amplas. Neste projeto, o protocolo da camada de aplicação utilizado é o CANopen. O
funcionamento deste protocolo gira em torno do Dicionário de Objetos, estrutura presente
em todos os nós da rede, e que contém todos os dados relativos aos objetos de
comunicação, configuração do nó e da comunicação entre nós. Os objetivos centrais deste
projeto são: implementar uma rede CANopen, construir um mestre que possa gerenciar a
rede agregando as principais funcionalidades necessárias ao protocolo, desenvolver as
funções de comunicação na forma de uma Interface de Aplicação para que possam ser
usadas futuramente em outros programas. Acima de tudo, essa rede deve ser projetada
visando a sua utilização em veículos autônomos e semi-autônomos desenvolvidos pelo
Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos – PDVA, da Escola de
Engenharia da Universidade Federal de Minas Gerais.

AbstractAbstractAbstractAbstract

Keywords: Controller Area Network (CAN), CANopen, Object Dictionary.

The CAN protocol (Controller Area Network) developed by Bosch and standardized by
ISO 11898, is one of the most widespread in automotive industry and used in most
embedded systems present in cars. In the design of an autonomous vehicle, is more
appropriate for the systems being implemented using CAN to create a homogeneous set
that can communicate with each other easily. The CAN protocol specifies the
characteristics of the physical layer and data link according to the OSI/ISO model. A
wide range of protocols for application layer is available in market and, regarding the
construction of embedded systems, the developer options are broad. In this project, the
protocol application layer used is the CANopen. The operation of this protocol revolves
around object dictionary; structure presents in all network nodes, and contains all data
relating to objects communication, node configuration and communication between
nodes. The main goals of this project are: implement a CANopen network, build a master
who can manage the network by aggregating all main protocol features necessary to
develop the functions of communication in the form of an Application Interface that can
be used in future in other programs. Above all, this network must be designed for their
application in autonomous vehicles and semi-autonomous developed by the Grupo de
Pesquisa e Desenvolvimento de Veículos Autônomos - PDVA, School of Engineering, of
Universidade Federal de Minas Gerais.

SumárioSumárioSumárioSumário

Lista de Figuras ............................................................................................................... 6
Lista de Tabelas .............................................................................................................. 8
Capítulo 1 ......................................................................................................................... 9
Introdução .................................................................................................................... 9
1.1 Apresentação ...................................................................................................................................... 9
1.2 A Instituição .................................................................................................................................... 11
1.3 Motivação ......................................................................................................................................... 11
1.4 Objetivos do Projeto ...................................................................................................................... 12
1.5 Organização do Trabalho .............................................................................................................. 12
Capítulo 2 ....................................................................................................................... 13
Revisão Bibliográfica .................................................................................................. 13
2.1 Introdução ........................................................................................................................................ 13
2.2 Protocolo CAN ............................................................................................................................... 14
2.2.1 Camada Física .................................................................................................................................. 14
2.2.2 Camada de Enlace de Dados......................................................................................................... 15
2.2.3 Detecção e Controle de Erros ...................................................................................................... 19
2.2.4 Filtragem das Mensagens ............................................................................................................... 19
2.2.5 Características Gerais ...................................................................................................................... 20
2.3 CANopen .................................................................................................................................... 20
2.3.1 O Dicionário de Objetos .......................................................................................................... 21
2.3.2 Interface de Comunicação ....................................................................................................... 22
2.3.2.1 SDO – Service Data Object .......................................................................................... 22
2.3.2.2 PDO – Process Data Object ......................................................................................... 24
2.3.2.4 EMCY – Mensagens de Emergência ........................................................................... 28
2.3.2.5 NMT – Network Management ..................................................................................... 28
2.3.3 HeartBeat .................................................................................................................................... 30
2.3.4 Node Guarding ........................................................................................................................... 30
2.4 Adaptador CANUSB ...................................................................................................................... 312.5 EPOS Maxon .................................................................................................................................... 32
2.6 Conclusão .......................................................................................................................................... 35
Capítulo 3 ....................................................................................................................... 36
Desenvolvimento ............................................................................................................ 36
3.1 Introdução ........................................................................................................................................... 36
3.2 Rede CAN ........................................................................................................................................... 36
3.3 Mestre CANopen ............................................................................................................................... 37
3.4 Conclusão ............................................................................................................................................. 46
Capítulo 4 ....................................................................................................................... 47
Resultados ...................................................................................................................... 47
4.1 Introdução ............................................................................................................................................ 47
5

4.2 Requisitos do Protocolo ................................................................................................................... 48
4.3 Resposta Temporal ............................................................................................................................. 49
4.4 Conclusão ............................................................................................................................................. 57
Capítulo 5 ....................................................................................................................... 59
Conclusão ....................................................................................................................... 59
5.1 O Trabalho Realizado ....................................................................................................................... 59
5.2 Propostas de Trabalhos Futuros ..................................................................................................... 60
Bibliografia ..................................................................................................................... 61
Anexo 1 ........................................................................................................................... 63
Anexo 2 ........................................................................................................................... 65
Anexo 3 ........................................................................................................................... 66
Anexo 4 ........................................................................................................................... 68

Lista de FigurasLista de FigurasLista de FigurasLista de Figuras

Figura 1 - Sistemas de controle automático no veículo Chevrolet Astra - adaptada de (Silva,
2009). 10
Figura 2 - Representação dos bits e níveis de tensão no barramento CAN 14
Figura 3 - Velocidade de transmissão em função do comprimento do barramento. Retirada de
(Guimarães, 2003). 15
Figura 4 - Formato do quadro CAN 2.0A. Retirada de (Guimarães, 2003). 16
Figura 5 - Formato do quadro CAN 2.0B. Retirada de (Guimarães, 2003). 16
Figura 6 - Quadro de dados no formato CAN 2.0A. Retirada de (Sousa, 2002). 17
Figura 7 - Quadro de dados no formato CAN 2.0B. Retirada de (Sousa, 2002). 18
Figura 8 - Quadro remoto no formato CAN 2.0B. Retirada de (Sousa, 2002). 18
Figura 9 - Formato básico de uma mensagem SDO. 23
Figura 10 - Mensagens enviadas quando um nó deseja ler um objeto do dicionário de outro nó
da rede. 24
Figura 11 - Mensagens enviadas quando un nó deseja escrever em um objeto do dicionário de
outro nó da rede. 24
Figura 12 - Relação entre o PDO parameter e o PDO mapping do Dicionário de Objetos e a
montagem da mensagem do tipo PDO. 26
Figura 13 - Mecanismo de produção de SYNCs e envio de PDO's síncronos. 27
Figura 14 - Máquina de estados finita mínima de um nó CANopen. Retirada de (Boterenbrood,
2000). 28
Figura 15 - Node Guarding, Life Guarding e parâmetros relacionados. 31
Figura 16 - Adaptador CANUSB. 32
Figura 17 - EPOS 24/5 da Maxon. Retirada de (Maxon Motor, 2007). 33
Figura 18 - Máquina de estados do funcionamento da EPOS. Retirada de (Maxon Motor, 2010).
34
Figura 19- Estrutura da classe CANusb_hw com as interfaces de leitura e escrita no
barramento. 39
Figura 20 - Estrutura SlaveList. 40
Figura 21 - Estruturas Node, EstruturaPDO e ObjProcesso e a relação entre eles. 40
Figura 22 - Fluxograma que representa a execução da thread de HeartBeat. 41
Figura 23 - Fluxograma de execução da thread de Node Guarding. 42
Figura 24 - Fluxograma do funcionamento das funções de comunicação SDO e requisição de
PDO. (SendFrameSDO() e RequestTxPDO()) 43
Figura 25 - Fluxograma detalhando as etapas do processo de configuração de PDO's 44
Figura 26 - Módulo de teste do mestre CANopen. 47
Figura 27 - Tela do programa de teste à esquerda e a tela do EPOSUserInterface à direita. Em
destaque o valor da velocidade em ambos os programas. 49
Figura 28 - Tempo de resposta da função SendFrameSDO no Programa 1. 50
Figura 29 - Tempo de resposta da função SendFrameSDO do Programa 2. 51
Figura 30 - Tempo de resposta da função SendFrameSDO do Programa 2 com a resolução de
timer do Windows alterada para 1 ms. 52
Figura 31 - Tempo de resposta da função SendFrameSDO do Programa 2 medido através do
contador de performance. 53
Figura 32 - Tempo de resposta da função SendFrameSDO do Programa 2 no computador com
processador Intel Core 2 Duo, com resolução do timer aterada para 1 ms. 54
7

Figura 33 - Tempo de resposta da função SendFrameSDO do Programa 2 no computador com
processador Intel Core 2 Duo, utilizando contador de performance. 54
Figura 34 - Tempo de resposta das funções de Escrita e Leitura no adaptador CANUSB,
incluso o tempo de codificação e decodificação da mensagem no formato ASCII. 56
Figura 35 - Tempos de resposta da função SendFrameSDO medidos no computador com
processador Intel Core 2 Duo com a CPU operando sem carga e com carga. 57

Lista de TabelasLista de TabelasLista de TabelasLista de Tabelas

Tabela 1 - Estrutura geral do Dicionário de Objetos com os índices em hexadecimal. Tabela
retirada de (Boterenbrood, 2000). ....................................................................................... 22
Tabela 2 - Estrutura do COB-ID de 11 bits. ................................................................................ 22
Tabela 3 - Formato padrão da mensagem SYNC. ...................................................................... 26
Tabela 4 - Formato das mensagens de Emergência. .................................................................. 28
Tabela 5- Formato de uma mensagem NMT Module Control. *CS = Command Specifier. ..... 29
Tabela 6 - Formato de uma mensagem de Boot-up. .................................................................. 29
Tabela 7 - Resposta à requisição do tipo Node Guarding. ......................................................... 30
Tabela 8 - Estadose seus valores correspondentes dentro das mensagens de resposta ao Node
Guarding. ............................................................................................................................ 30
Tabela 9 - Funções globais de manipulação de mensagens CAN no programa mestre............. 45

Capítulo 1Capítulo 1Capítulo 1Capítulo 1

IntroduçãoIntroduçãoIntroduçãoIntrodução

1.11.11.11.1 ApresentaçãoApresentaçãoApresentaçãoApresentação

O projeto final de curso apresentado nesta monografia tem como foco a implementação de
uma rede CAN (Controller Area Network) para interligar diversos dispositivos, incluindo sensores,
atuadores, computadores e outras unidades de processamento, utilizando o protocolo CANopen na
camada de aplicação.
CAN é uma rede de comunicação serial especialmente voltada para conectar dispositivos
inteligentes em sistemas de controle e criada inicialmente para indústria automobilística. É uma rede
de amplo uso em sistemas embarcados em automóveis. Atualmente, sua utilização abrange também
a área industrial por ser uma rede confiável, imune a interferências eletromagnéticas, que garante a
consistência de dados, alta velocidade, flexibilidade, permitindo introdução de novos nós
dinamicamente. Um número muito grande de instrumentos e componentes eletrônicos disponíveis
no mercado possuem interface CAN embutida, e grande parte destes equipamentos podem ser
conectados diretamente no barramento. A construção de nós CAN também é facilitada pela grande
disponibilidade de microcontroladores que já possuem o módulo controlador CAN embutido em
sua estrutura. Os protocolos existentes para a camada de aplicação segundo o modelo ISO/OSI são
muitos. Podem ser citados: CANopen, DeviceNet e SDS (Smart Distributed System).
O foco deste trabalho consistiu na implementação de um mestre para uma rede CANopen,
com o objetivo de usá-lo no projeto de veículos autônomos e semi-autônomos. A Figura 1 mostra
o interior do carro autônomo desenvolvido pelo Laboratório de Computação e Robótica da Escola
de Engenharia da UFMG. Os sistemas de controle deste veículo utilizam uma EPOS (Embedded
Parallel Operating System) construída pela Maxon Motor. A EPOS é uma unidade de processamento
embarcada que, entre outras coisas, implementa o controle de posição, velocidade ou corrente para
diversos tipos de motores. Segundo (Fröhlich, 2002), a EPOS é um processador programável,
altamente personalizável, projetado para uso em aplicações embutidas e paralelas, disponibilizando
recursos que impliquem em menor sobrecarga possível para a rede.
10

Figura 1 - Sistemas de controle automático no veículo Chevrolet Astra - adaptada de (Silva, 2009).

Para análises dos requisitos do sistema para o qual o mestre desenvolvido deve ser
utilizado, considerou-se o sistema de direção do veículo autônomo, o CADU. No sistema de
controle de direção, é utilizado um GPS (Global Positioning System) modelo Garmin GPS18 como
sensor. Esse GPS atualiza e envia dados a uma taxa de 1Hz. O CADU, possui também sensores de
velocidades do tipo relutância magnética que, juntamente com o circuito processador do sinal,
transmitem o valor da velocidade a uma taxa de 50 Hz. A fusão sensorial do carro é feita utilizando
o Filtro de Kalman Estendido (R.Freitas, Vinti, & Santos, 2009), aumentando a frequência do sinal
de realimentação do sistema de controle de posição para 50Hz. O maior atraso de tempo presente
no carro é de 0,8 s percebido na dinâmica dos freios. O sistema de controle proposto é constituído
de dois níveis. Um mais interno realizado pela EPOS, e outro em cascata no qual o mestre
construído operaria através do recebimento dos sinais do GPS, realizando um cálculo para o sinal
de referência da malha interna implementada na EPOS. Dada essa configuração, para o programa a
ser implementado, alguns requisitos podem ser levantados: deve permitir a operação a uma taxa de
amostragem de no máximo 50Hz e pode ser Soft Real Time.
O mestre desenvolvido pode ser utilizado em qualquer sistema que use a EPOS, como
robôs e veículos ou aviões autônomos e semi-autônomos. Foi construída uma rede com duas
EPOS, comandadas por um computador, para verificar o funcionamento adequado do mestre.
Algumas funções desenvolvidas são específicas para a EPOS da Maxon, mas o mestre foi
implementado de forma que qualquer outro dispositivo CANopen possa ser incorporado à rede.
Neste Capítulo são apresentados a instituição onde o projeto foi desenvolvido, a
motivação, objetivos e organização do trabalho na monografia.

1.21.21.21.2 A InstituiçãoA InstituiçãoA InstituiçãoA Instituição

O projeto de fim de curso foi desenvolvido na Universidade Federal de Minas Gerais, no
Laboratório de Computação e Robótica (CORO), onde foi disponibilizado todo material e
equipamento necessário para o desenvolvimento da rede CANopen.
O CORO realiza projetos de pesquisa e desenvolvimento nas áreas de robótica,
processamento de imagens digitais, visão computacional, sistemas integrados, sistemas a eventos
discretos, instrumentação e controle por computador, e conta com a participação de professores,
mestrandos e alunos da graduação.
O CORO é associado ao Grupo de Pesquisa e Desenvolvimento de Veículos Autônomos -
PDVA que possui duas frentes de pesquisa principais:
• Desenvolvimento de sistemas embarcados de controle e instrumentação para veículos
aéreos autônomos ou tripulados.
• Desenvolvimento de um veículo de passeio autônomo.

O Laboratório CORO tem como responsáveis os professores Guilherme Augusto Silva
Pereira e Carlos Andrey Maia, ambos do Departamento de Engenharia Elétrica da UFMG. Nele
são desenvolvidos, atualmente, os seguintes projetos:
• Desenvolvimento de Dispositivos e Técnicas para Análise Cinemática e Dinâmica de
Veículos.
• Desenvolvimento de um sistema de simulação para robôs móveis.
• Desenvolvimento de um mini-helicóptero autônomo.
• Navegação de veículos autônomos em ambientes externos.

1.31.31.31.3 MotivaçãoMotivaçãoMotivaçãoMotivação

A principal motivação deste projeto é contribuir para o desenvolvimento da tecnologia de
veículos autônomos e semi-autônomos, que atualmente é foco de estudo de diversos centros de
pesquisa. Segundo (Jung, Osáro, Kleber, & Heinen, 2005), a automação veicular apresenta diversos
benefícios: segurança e conforto para os usuários, maior estabilidade e rendimento, fazendo com
que a indústria invista intensamente no desenvolvimento de sistemas eletrônicos embarcados. Os
sistemas em um automóvel autônomo podem guiar o carro, controlando velocidade, aceleração e
posição; escolher a melhor rota, e auxiliar o motorista na execução de tarefas ou até mesmo assumir
o controle em casos de emergência.
O automóvel Astra utilizado como plataforma de desenvolvimento e testes do projeto do
veículo autônomo já possui sistemas de automação e controle implementados. Estes sistemas
permitem que o carro se desloque e seja conduzido sem a presença de um motorista. No entanto,
todo o sistema de instrumentação e controle atual é realizado por meio de comunicação USB ponto
a ponto. Com este trabalho, será possível a substituição deste sistema de comunicação via USB por
uma rede CAN, devido a sua grande utilização em sistemas eletrônicos de automóveis além das suas
características de robustez, confiabilidade e flexibilidade.
Todo trabalho desenvolvido consiste no projeto final de curso necessário para formação
em Engenharia de Controle e Automação pela Universidade Federal de Minas Gerais. Tal projeto
deve permitir que o aluno aplique os conceitos, ferramentas e conhecimentos obtidos ao longo do
curso, participando efetivamente de todas suas etapas.
12

1.41.41.41.4 ObjetivosObjetivosObjetivosObjetivos do Projetodo Projetodo Projetodo Projeto

Tendo em vista o exposto acima, este projeto tem por objetivos:• Desenvolver um mestre CANopen que possa coordenar em uma rede várias
EPOS;
• Criar funções de software que possam ser utilizadas no desenvolvimento de novas
aplicações;
• Criar um programa que possa atender aos requisitos para utilização com o sistema
de direção do veículo autônomo.

Para isto, as seguintes etapas de trabalho foram definidas:

• Criar uma rede CAN entre dois ou mais computadores.
• Realizar a comunicação do computador com uma EPOS via rede CANopen
comandando um motor CC.
• Colocar em rede e realizar a comunicação de várias EPOS e um ou mais
computadores.
• Implementar um mestre disponibilizando um conjunto de funções que permitam
o desenvolvimento de novas aplicações com dispositivos CANopen.
• Realizar testes na rede e analisar os resultados.

1.51.51.51.5 Organização do TrabalhoOrganização do TrabalhoOrganização do TrabalhoOrganização do Trabalho

O trabalho apresentado nesta monografia está dividido em cinco capítulos. O primeiro
Capítulo apresentou uma introdução do projeto, a empresa onde o trabalho foi realizado e os
objetivos e motivações. O Capítulo 2 consiste na revisão bibliográfica, descrevendo os princípios
básicos e características do protocolo CAN e do CANopen, e dos dispositivos utilizados. O
Capítulo 3 apresenta a metodologia utilizada e as etapas de implementação do projeto. No Capítulo
4 são expostos os testes e resultados dos mesmos. No Capítulo 5 tem-se a conclusão da
monografia, bem como sugestões e dificuldades encontradas na realização do projeto.

Capítulo 2Capítulo 2Capítulo 2Capítulo 2

Revisão BibliogRevisão BibliogRevisão BibliogRevisão Bibliográficaráficaráficaráfica

2.12.12.12.1 IntroduçãoIntroduçãoIntroduçãoIntrodução

Os conhecimentos necessários para implementação da rede CAN ( Controller Area Network )
dependem, em grande parte, dos instrumentos e equipamentos ligados à rede e dos componentes
utilizados para a construção dos nós. Para desenvolver nós com funções específicas, geralmente
utiliza-se de microcontroladores, o que permite inclusive criar interfaces com outros protocolos.
Por se tratar de um protocolo para as camadas de mais baixo nível das redes de automação,
segundo o modelo OSI/ISO, todos os equipamentos encontrados no mercado, com interface
CAN, possuem um protocolo superior – da camada de aplicação – implementado, sendo o
DeviceNet e o CANopen os mais largamente conhecidos. Inclusive, alguns CLP’s ( Controladores
Lógico Programáveis) no mercado, são nativos CANopen, como o caso dos CLP’s da Moller, ou
nativos DeviceNet, como os CLP’s da Rockwell das linhas: MicroLogix, ControlLogix e
CompactLogix.
A EPOS utilizada no projeto, fabricada pela Maxon Motor, para o controle de motores de
corrente contínua, é um dispositivo CANopen. Por isto, esse é o protocolo de alto nível que foi
utilizado nesse trabalho. Outro equipamento de grande importância no desenvolvimento do projeto
foi o adaptador CANUSB, fabricado pela LAWICEL, que conecta o computador ao barramento
CAN através da porta USB. Os comandos necessários para configuração e funcionamento do nó na
rede são enviados como um conjunto de caracteres ASCII para a porta criada pelo driver do
adaptador.
Neste Capítulo, serão abordados: os protocolos CAN, CANopen e o funcionamento dos
principais dispositivos envolvidos no desenvolvimento da rede deste trabalho. A revisão
bibliográfica do CAN e CANopen não foi feita utilizando as normas dos respectivos protocolos.
Para isso foram utilizadas as seguintes referências: (Godoy, 2010), (Guimarães, 2003) e (Sousa,
2002) para o protocolo CAN, e (IXXAT Automation GmbH, 2011), (Boterenbrood, 2000) e
(Softing, 2011) para o CANopen, entre outras que são citadas ao longo deste Capítulo.

2.22.22.22.2 Protocolo CANProtocolo CANProtocolo CANProtocolo CAN

O protocolo CAN foi desenvolvido inicialmente para aplicações na indústria
automobilística. Publicado pela Bosch em 1986, ao longo do tempo ganhou grande aceitação e
aplicação em sistemas automotivos, sendo que o primeiro carro a usar CAN foi produzido pela
Mercedes-Benz em 1992. Em virtude de suas características, tais como robustez, desempenho e
diferentes possibilidades de aplicação, atualmente é empregado em diversas áreas da indústria. Em
1993, o protocolo CAN foi padronizado mundialmente na norma ISO 11898, para aplicações de
alta velocidade e pela norma ISO 11519, para aplicações de baixa velocidade, geradas pela
International Society of Organization.
Segundo o modelo OSI/ISO para redes, o protocolo CAN especifica apenas a camada
física e de enlace de dados, que são apresentadas nas próximas seções.

2.2.1 2.2.1 2.2.1 2.2.1 Camada FísicaCamada FísicaCamada FísicaCamada Física

A codificação dos bits na rede CAN segue o formato NRZ (No-Return-to-Zero). Neste tipo
de codificação, o bit é representado por um sinal de tensão que permanece constante durante um
tempo pré-determinado. A regra de violação de bits (Bit-Stuffing) é utilizada, de forma a assegurar o
sincronismo entre os nós da rede. A cada cinco bits iguais consecutivos, o trasmissor insere um bit
de valor complementar que é removido pelo receptor.
O conceito de dominância de bit é muito importante nessa rede. O bit '1' recessivo
enquanto o bit '0' é dominante. A escrita de um bit dominante no barramento em qualquer instante,
sobrescreve o estado de bit recessivo.
Os níveis lógicos são indicados através da tensão diferencial entre dois fios, utilizados
como meio de transmissão: CAN_H (CAN High) e CAN_L (CAN Low). Em estado de repouso, a
tensão diferencial entre esses canais mantem a rede em estado de bit recessivo. Mesmo não
havendo informação a ser transmitida, há um fluxo constante de bits na rede. Para que seja gerado
um bit dominante, a tensão no CAN_H aumenta até cerca de 3,5V e a tensão em CAN_L cai até
cerca de 1,5V. Passa a existir uma diferença de potencial de aproximadamente 2,0V entre os fios.
Essa representação pode ser vista na Figura 2 .

Figura 2 - Representação dos bits e níveis de tensão no barramento CAN
O meio de transmissão do barramento CAN pode ser constituído de 3 formas: com 1, 2 ou
4 fios. No primeiro modelo, o único fio presente é conhecido como linha CAN e é por onde todos
15

os dados são transmitidos. A codificação dos bits segue o formato NRZ mas os níveis lógicos são
indicados apenas pela tensão no fio em relação ao aterramento de toda a rede, diminuindo a
robustez e a imunidade da rede à interferências eletromagnéticas. Em redes veículares com
barramento de 1 fio, a determinação dos bits é realizada pela diferença de potencial entre a linha
CAN e a carcaça do veículo. O modelo de dois fios possui os canais CAN_H e CAN_L, e ao
modelo de 4 fios acrescenta-se os canais de alimentação (VCC) e o terra (GND).
Quando alguma das seguintes falhas ocorre, a rede de 2 ou 4 fios consegue continuar
operando (em modo de segurança):

• Curto do CAN_H (ou CAN_L) para GND (ou VCC);
• Curto entre CAN_H e CAN_L;
• Ruptura de um dos fios de dados: CAN_H ou CAN_L.

O protocolo CAN não define uma mídia para implementação do barramento. Podem ser
usados: par trançado, par trançado blindado, fibra ótica, entre outros. Usando par trançado,
qualquer interferência que provoque alterações no nível de tensão no barramento será percebida
nos dois fios, CAN_H e CAN_L, ao mesmo tempo. Dessa forma, a informação é preservada, pois
a diferença de tensão entre os fios permanecerá a mesma. Algumas normas mais específicas como a
ISO 11783, que padroniza redes CAN em máquinas e implementos agrícolas, define o cabo para o
barramento do tipo par trançado, não blindado e com quatro pares de condutores elétricos.
A velocidade de transmissão dos dados em uma rede CAN diminui a medida que se
aumenta o comprimento do barramento. A maior velocidade alcançada é de 1 Mbps, podendo
ocorrer em um barramento de até 40metros. A relação entre o tamanho do barramento e a
velocidade de transmissão da rede pode ser vista na Figura 3.

Figura 3 - Velocidade de transmissão em função do comprimento do barramento. Retirada de
(Guimarães, 2003).

2.2.2 2.2.2 2.2.2 2.2.2 Camada de Enlace de DadosCamada de Enlace de DadosCamada de Enlace de DadosCamada de Enlace de Dados

Na rede CAN, a arbitragem do barramento é definida pela mensagem e não pelos nós.
Todos os nós do barramento são considerados iguais e não possuem endereço específico. Toda
16

informação de endereçamento e prioridade está contida no identificador da mensagem. O
mecanismo de acesso ao meio implementado é chamado CSMA/CD+AMP - Carrier Sense Multiple
Access with Collision Detection and Arbitration on Message Priority (Acesso Múltiplo com Detecção de
Colisão e Arbitragem pela Prioridade da Mensagem). Neste método, quando um nó deseja
transmitir, ele monitora a rede durante um tempo e caso não exista atividade no barramento, inicia
a transmissão. Se houver atividade no barramento, o nó aguarda durante um tempo aleatório e
depois tenta transmitir novamente. Esse mecanismo só é possível porque todo nó realiza a leitura
do barramento quando está transmitindo. Ao enviar um bit, o nó verifica o barramento, e se seu
nível lógico não for igual ao nível do bit enviado, significa que uma colisão ocorreu.
Os conflitos de transmissão são resolvidos de acordo com a prioridade das mensagens,
definida no seu identificador. Quanto menor o número do identificador maior a prioridade. A
mensagem de maior prioridade sobrescreve a de menor prioridade. Por isso, esse método apresenta
uma forma de arbitragem não destrutiva.
Existem dois formatos básicos de mensagens CAN no que diz respeito ao tamanho do
identificador:

• Formato CAN 2.0A (Standard frame)- Mensagem com identificador de 11 bits.

Com esse formato, pode-se ter até 2048 mensagens distintas. O quadro CAN 2.0A
pode ser visto na Figura 4.

Figura 4 - Formato do quadro CAN 2.0A. Retirada de (Guimarães, 2003).

• Formato CAN 2.0B (Extended frame)- Mensagem com identificador de 29 bits.

Figura 5 - Formato do quadro CAN 2.0B. Retirada de (Guimarães, 2003).

O quadro CAN 2.0B é mostrado na Figura 5. Com esse formato, pode-se obter
aproximadamente 537 milhões de mensagens distintas. Entretanto, segundo (Guimarães, 2003), em
alguns casos, o acréscimo de 18 bits no identificador aumenta o overhead da mensagem, podendo
caracterizar um problema para determinadas aplicações em tempo real.
A CAN suporta ainda quatro tipos diferentes de quadros: Quadro de Dados ( Data Frame )
e Quadro Remoto (Remote Frame), enviados quando a rede está em estado funcional; e Quadro de
Erros ( Error Frame ) e Quadro de Sobrecarga (Overload Frame), enviados quando a rede está em
algum estado de erro. Os dois primeiros quadros suportam ambos os formatos CAN 2.0A e CAN
2.0B. Estes tipos são detalhados a seguir:

• Quadro de dados

Em ambos os formatos, padrão (CAN 2.0A) ou estendido (CAN 2.0B), um quadro de
dados possui um campo identificador, um campo de controle e verificação e pode conter até 8
Bytes (64 bits) de dados.

A Figura 6 mostra um quadro de dados no formato CAN 2.0A.

Figura 6 - Quadro de dados no formato CAN 2.0A. Retirada de (Sousa, 2002).
Podem ser destacados os seguintes campos:

� SOF (Start of Frame)- Campo de início do quadro. Consiste de apenas um bit
dominante.
� Arbitration Field (Campo de arbitragem) - Composto pelo identificador de 11 bits
da mensagem e um bit chamado RTR (Remote Transmission Request). Em quadros de
dados, RTR = '0', em quadros remotos, RTR = '1'.
� Control Field (Campo de Controle) - Composto pelo bit IDE (Identifier Extended Bit)
usado para diferenciar o formato do quadro: IDE = '0', para formato padrão e
IDE = '1', para formato estendido; pelo bit r0 que é um bit reservado com valor
'0'; e os 4 bits que formam o DLC (Data Length Code) que indica o número de bytes
no campo de dados.
� Data Field (Campo de Dados)- Pode conter de 0 a 8 bytes que representam a
informação concreta que o nó deseja transmitir.
� CRC (Cyclic Redundance Check) - Campo para verificação de redundância cíclica
formado por 16 bits. 15 bits implementam o código CRC e 1 bit, recessivo,
delimita o final do campo. O cálculo do código depende do polinômio CRC
especificado para o CAN e utiliza os campos: SOF, Arbitration Field , Control Field e
Data Field.
� ACK (Acknowledge) - Composto por dois bits: ACK Slot e ACK Delimiter, ambos
recessivos. Servem para realizar a confirmação de recepção da mensagem por
algum nó da rede. Durante a recepção, o nó que está recebendo a mensagem
corretamente, envia um bit dominante durante o ACK Slot. Se o transmissor
detecta um bit dominante no ACK ele sabe que ao menos um nó na rede recebeu
o quadro corretamente.
� EOF (End Of Frame) - Delimita o quadro de dados indicando seu fim. É composto
por 7 bits recessivos.

O quadro estendido difere do padrão por possuir um identificador com 29 bits. Nessa
versão, o campo de arbitragem possui um bit SRR (Substitute Remote Request) recessivo, de forma a
18

garantir uma prioridade menor ao quadro estendido em relação ao quadro padrão, em uma rede
com nós com diferentes versões do protocolo CAN; 18 bits de extensão do identificador; e o bit
IDE, que no formato padrão pertence ao campo de controle.
O campo de controle possui mais um bit reservado: r1. A Figura 7 mostra o quadro de
dados na versão CAN 2.0B.

Figura 7 - Quadro de dados no formato CAN 2.0B. Retirada de (Sousa, 2002).

• Quadro Remoto

Este quadro é utilizado por um nó (cliente) para requisitar a outro nó remoto da rede
(servidor), o envio de algum dado. Esse dado é enviado de forma automática em um quadro de
dados com mesmo identificador do quadro remoto. A maior diferença entre esse quadro e o quadro
de dados é a ausência do campo de dados, e o valor do bit RTR que deve ser recessivo.

A Figura 8 ilustra o formato de um quadro remoto no padrão CAN 2.0B.

Figura 8 - Quadro remoto no formato CAN 2.0B. Retirada de (Sousa, 2002).

• Quadro de Erro

Um quadro de erro é gerado por qualquer nó que detecta um erro no barramento. O
quadro consiste de um campo de flags e um delimitador. O delimitador é uma sequência de 8 bits
recessivos. Existem dois tipos de flags de erro: ativo - 6 bits dominantes, e passivo - 6 bits recessivos
(podem ser sobrepostos por bits dominantes enviados por outros nós). Esse quadro viola a regra de
bit-stuffing, fazendo com que outros nós também transmitam um quadro de erro.
Um quadro de erro só é gerado quando ocorre erro na transmissão ou recepção de uma
mensagem. Erros na própria mensagem são tratados com retransmissão e contagem de tentativas.

• Quadro de Sobrecarga

Esse quadro é formado por um campo de flags (6 bits dominantes) e um delimitador (8 bits
recessivos). É transmitido por um nó em duas situações:

� Ocorrência de um bit dominante no espaço interquadros que é a sequência de bits
entre dois quadros de dado e/ou remoto.
� Quando um receptor precisa de mais tempo para receber um quadro de dado ou
remoto.

Além das definições dos tipos de quadros, o protocolo CAN, a nível da camada de enlace,
também define os mecanismos de detecção e controle de erros descritos na seção a seguir.

2.2.3 2.2.3 2.2.3 2.2.3 Detecção e Controle de ErrosDetecção e Controle de ErrosDetecção e Controle de ErrosDetecção e Controle de Erros

Existe em cada nó CAN dois contadores: o REC (Receiver Error Counter) e o TEC (Transmite
Error Counter). O REC tem 7 bits e acumula o número de recepções erradas; e o TEC acumula o
número de transmissões erradas.
Basicamente, erros de transmissão valem 8 pontos e erros de recepção, 1 ponto. Quando
esses erros ocorrem no nó, os respectivos valores são somados no respectivo contador. Por outro
lado, mensagens recebidas ouenviadas corretamente decrementam os respectivos contadores.
Inicialmente, todo nó está em estado "error active". Neste estado, o nó pode participar
normalmente da comunicação no barramento, mas ao detectar um erro no barramento, ele envia
uma flag de erro ativo. Se algum dos contadores superar 127 pontos, este nó entrará em estado "error
passive", onde participará normalmente da comunicação no barramento, esperando um certo tempo
entre transmissões sucessivas. Entretanto, em casos de detecção de erro de comunicação, este nó
enviará flags de erro passivo. O nó entrará em estado de "bus off" quando algum de seus contadores
superar 255 pontos. Neste estado, o nó não participa de nenhuma comunicação no barramento.
Existem 5 tipos de erros que podem causar o incremento dos contadores:

� Erro de bit: ocorre quando o bit transmitido não é igual ao bit lido no barramento;
� Erro de stuff: ocorrência de mais de 5 bits iguais consecutivos em campos do quadro
codificados pelo método de bit-stuffing;
� Erro de CRC: ocorre quando o CRC calculado pelo receptor é diferente daquele calculado
pelo transmissor;
� Erro de Formato: ocorre quando algum bit que possui valor pré-definido não apresenta
esse valor;
� Erro de Confirmação: ocorre quando o nó transmissor não recebe confirmação de
qualquer outro nó da rede. O bit ACK Slot no campo de ACK permanece em estado
recessivo.

2.2.4 2.2.4 2.2.4 2.2.4 Filtragem das MensagensFiltragem das MensagensFiltragem das MensagensFiltragem das Mensagens

Para otimizar a tarefa de processamento de mensagem por um nó, pode-se selecionar qual
mensagem ou conjunto de mensagens que determinado nó irá processar ou armazenar. Isto é
possível através de um processo de filtragem baseado no identificador das mensagens. Para que a
filtragem funcione, é necessário construir duas estruturas: a máscara e o filtro de aceitação.
20

A máscara define quais bits do identificador da mensagem serão verificados durante a
filtragem. Pode-se escolher um bit, ou até mesmo todo o identificador, como máscara. Supondo
que apenas os três primeiros bits do identificador de 11 bits sejam relevantes para filtragem, a
máscara do filtro será: 11100000000.
O filtro especifica os valores dos bits da máscara. Quando a mensagem possui os bits
definidos pela máscara iguais aos do filtro, ela é recebida e processada pelo nó. Para o exemplo
dado anteriormente, um possível filtro seria: 01100000000. Neste caso, apenas as mensagens com
os três bits mais significativos iguais a 011 seriam aceitas pelo nó.

2.2.5 Car2.2.5 Car2.2.5 Car2.2.5 Características Geraisacterísticas Geraisacterísticas Geraisacterísticas Gerais

Em síntese, baseado em parte no que foi mencionado nas seções anteriores, algumas
características importantes da rede CAN podem ser destacadas:
• É uma rede multi-mestre;
• Apresenta grande flexibilidade de configuração e os nós podem ser inseridos no
barramento dinamicamente;
• Suporta comunicação Multicasting e Broadcasting;
• Possui alta robustez e imunidade a ruídos e interferências eletromagnéticas;
• Possibilita distinção entre erros temporários e falhas permanentes em nós;
• Garante prioridade de mensagens, tempos de latência e consistência dos dados;
• Possibilita a detecção e a sinalização de erros em todo barramento.

Como o protocolo CAN só define as duas camadas mais baixas do modelo OSI/ISO, são
necessários protocolos de níveis superiores para definir como os campos das mensagens devem ser
utilizados e como os identificadores dos nós podem ser defnidos. O protocolo de aplicação
CANopen utilizado neste trabalho, é descrito na seção seguinte.

2.32.32.32.3 CANopenCANopenCANopenCANopen

Os pioneiros no desenvolvimento de uma camada de aplicação para a CAN foram a
Philips Medical Systems e o Steinbeis Transfer Center for Process Automation - STZP. Em
março de 1992, foi fundada a CiA - “CAN in Automation”, formado por um grupo de
desenvolvedores e usuários do protocolo CAN. Uma das primeiras tarefas da CiA foi
desenvolver um protocolo para camada de aplicação da CAN, e utilizando as especificações
criadas pelo Philips Medical Systems e pelo STZP, foi criado o CAL – CAN Application Layer.
O CAL define 4 elementos básicos de serviços de aplicação:
• Especificação das mensagens baseadas em CAN: criação de objetos do tipo
variável, eventos, domínios, que podem ser acessados através da interface
CAN, de acordo com tipos de mensagens bem definidos.
• Gerenciamento da rede: inicialização e desligamento dos nós, detecção de
falhas e verificação dos estados dos nós.
• Distribuição dinâmica de identificadores CAN: definição dos identificadores
de cada tipo de mensagem que circula na rede. Cada tipo de mensagem é
também chamado de Objeto de Comunicação, e o identicador de cada objeto
é conhecido como COB-ID ( Communication Object Identifier ).
21

• Gerenciamento de camadas da rede: alteração de parâmetros de camadas
mais baixas, como por exemplo a taxa de transferência de dados, o endereço
dos nós e o bit-timing.

O CAL define como os objetos de comunicação são transmitidos, mas não define o que ou
quais tipos de objetos podem circular na rede. O protocolos da camada de aplicação surgem nesta
parte da especificação. O CANopen, por exemplo, é construído no topo do CAL, utilizando um
subconjunto de serviços e especificações definidos pelo mesmo.
No início dos anos 90, empresas americanas empreenderam trabalhos no desenvolvimento
de protocolos de aplicação para CAN. Dois protocolos surgiram: DeviceNet, desenvolvido pela
Allen-Bradley e SDS – Smart Distributed System, desenvolvida pela Honeywell. O DeviceNet foi
desenvolvido especialmente para automação industrial, sendo um concorrente direto de protocolos
como Profibus-DP e Interbus. Em 1993, um consórcio europeu de empresas, lideradas pela Bosch,
começou a desenvolver um protótipo do que se tornou posteriormente o CANopen. Em 1995, o
CANopen, completamente revisado foi publicado e em poucos anos se tornou um importante
padrão para redes embarcadas na Europa.
A seção seguinte apresentará os detalhes da principal estrutura do protocolo CANopen, o
Dicionário de Objetos.

2.3.12.3.12.3.12.3.1 O Dicionário de ObjetosO Dicionário de ObjetosO Dicionário de ObjetosO Dicionário de Objetos

O Dicionário de Objetos é a estrutura mais importante do protocolo CANopen. Todos os
serviços, funções, especificações, enfim, todo o protocolo funciona em torno do Dicionário de
Objetos.
Os objetos que compõem essa estrutura são ordenados por índices de 16 bits. Alguns
objetos, por possuirem características ou propriedades semelhantes, podem ser agrupados em um
mesmo índice, sendo acessados por sub-índices de 8 bits.
Todos os nós da rede CANopen possuem um dicionário de objetos que contem todos os
parâmetros de configuração do dispositivo (ou nó) e de definição do comportamento da rede. Esse
dicionário geralmente existe sob a forma de uma base de dados descrita em um arquivo do tipo
EDS – Eletronic Data Sheet.
Não é necessário que seja possível acessar todos os parâmetros do Dicionário de Objetos
de um nó a qualquer momento através da rede, mas é indispensável que o nó se comporte de
acordo com os parâmetros definidos do Dicionário.
A Tabela 1 mostra a configuração geral de um Dicionário de Objetos com base na divisão
por índices.

Índice Objeto
0000 Não é usado
0001 – 001F Tipos estáticos de dados (tipos de dados padrões como booleano,
inteiro de 16 bits, etc.)
0020 – 003F Tipos complexos de dados
0040 – 005F Tipos complexos de dados específicos de manufatura
0060 – 007F Tipos estáticos de dados específicos do perfil do dispositivo
0080 – 009F Tipos complexos de dados específicos do perfil do dispositivo
00A0 – 0FFF Reservado
1000 – 1FFF Área do perfil de comunicação (Tipo do dispositivo, registrador de
erros, números de PDO’s suportados)
22

2000 – 5FFF Área do perfil específico demanufatura
6000 – 9FFF Área padronizada do perfil de dispositivo
A000 – FFFF Reservado
Tabela 1 - Estrutura geral do Dicionário de Objetos com os índices em hexadecimal. Tabela
retirada de (Boterenbrood, 2000).

Os objetos mais relevantes dentro do Dicionário de Objetos, para o desenvolvimento de
aplicações ou configuração dos dispositivos CANopen encontrados no mercado, estão situados
entre os índices 1000 a 9FFF.

2.3.22.3.22.3.22.3.2 Interface de ComunicaçãoInterface de ComunicaçãoInterface de ComunicaçãoInterface de Comunicação

A interface de comunicação do CANopen é composta por um conjunto de serviços e
objetos (mensagens) pré-definidos que podem circular na rede. Os tipos de mensagens definidos
pelo CANopen serão chamados nesse trabalho de objetos de comunicação (communication objects).
Os objetos de comunicação definidos são:
• PDO – Process Data Object;
• SDO – Service Data Object;
• NMT – Network Management;
• Mensagens SYNC;
• Mensagens EMCY;
• Mensagens Boot-up;

Os identificadores dos objetos – COB-ID’s (que são os identificadores das mensagens
CAN), podem ser modificados dentro do Dicionário, através de um serviço de distribuição
dinâmica. A alocação dos COB-ID’s segue a estrutura definida na Tabela 2.

Número dos Bits
10 9 8 7 6 5 4 3 2 1 0
Código da Função Identificador do Nó – NODE-ID
Tabela 2 - Estrutura do COB-ID de 11 bits.
O Node-ID pode assumir valores entre 1 e 127. O valor 0 é reservado e não pode ser
usado por nenhum nó. Essa distribuição de COB-ID’s corresponde ao conjunto de conexões ponto
a ponto mestre-escravo, pois apenas o mestre conhece os Node-ID de todos os nós da rede. Dois
escravos quaisquer, conectados no barramento, não são capazes de comunicarem entre si, pois, via
de regra, um não conhece o Node-ID do outro.
Essa divisão dos COB-ID’s pode ser estendida para o padrão de 29 bits, utilizando os 11
bits menos significativos do identificador.
A nível de aplicação, apenas 3 campos da mensagem CAN são utilizados: o identificador, o
campo de dados de 64 bits e o campo RTR que serve para diferenciar um quadro de dados de um
quadro remoto. Os objetos de comunicação definidos pelo CANopen são explicados a seguir.

2.3.2.12.3.2.12.3.2.12.3.2.1 SDO SDO SDO SDO –––– Service Data ObjectService Data ObjectService Data ObjectService Data Object

Uma mensagem do tipo SDO é utilizada para acessar o Dicionário de Objetos de um nó.
Dois tipos gerais de serviço são definidos: download e upload, escrita e leitura de dados
respectivamente. Através dessas mensagens, um objeto pode ser acessado pelo seu índice e sub-
índice. Um nó, considerado cliente SDO requisita a leitura ou escrita de determinado objeto de
outro nó, considerado servidor SDO, enquanto a comunicação é firmada.
O formato de uma mensagem SDO pode ser vista na Figura 9 .

Figura 9 - Formato básico de uma mensagem SDO.
Dado uma comunicação do tipo SDO entre dois nós, são necessários dois COB-ID’s
distintos: um para mensagem que sai do cliente para o servidor, e outro para mensagem que transita
no sentido oposto. Quando um nó quer escrever ou ler um objeto do Dicionário de Objetos de
outro nó, ele deve enviar uma mensagem com COB-ID igual a 0x600 + Node-Id do nó de destino
(a notação 0x antes do número indica sua representação em hexadecimal). O nó destino, por sua
vez, responde com uma mensagem cujo COB-ID é igual 0x580 + seu próprio Node-Id. A ação a
ser realizada no nó servidor, seja escrita ou leitura, é definida pelo especificador de comando no
Byte 0 do campo de dados. Os Bytes 1 e 2 contêm o índice do objeto alvo, e o Byte 3 contém o
sub-índice.
O conteúdo dos Bytes 4 a 7 variam conforme a mensagem. Quando se trata de uma
mensagem de requisição de upload, todos estes 4 Bytes são iguais a zero. Cada bit do Byte 0 tem
uma função para compor o especificador de comando.
Como apenas 4 Bytes do campo de dados são utilizados para transmitir o dado desejado,
apenas objetos cujo valor tem tamanho de até 32 bits podem ser transmitidos em uma única
mensagem. Para dados com mais de 32 bits, utiliza-se um mecanismo de transmissão por blocos de
mensagens. Neste caso, existe uma mensagem SDO para iniciar a transferência do bloco, uma para
enviar o segmento de dados, e uma para finalizar a transferência do bloco, cada uma com um
respectivo especificador de comando, que varia também pela função de download ou de upload.
A Figura 10 e a Figura 11 exemplificam os formatos das mensagens enviadas por dois nós
que se comunicam utilizando mensagens SDO para transferência única, que é aquela onde o objeto
pode ser transmitido em apenas uma mensagem.

Figura 10 - Mensagens enviadas quando um nó deseja ler um objeto do dicionário de outro nó da
rede.

Figura 11 - Mensagens enviadas quando un nó deseja escrever em um objeto do dicionário de outro
nó da rede.

2.3.2.22.3.2.22.3.2.22.3.2.2 PDO PDO PDO PDO –––– Process Data ObjectProcess Data ObjectProcess Data ObjectProcess Data Object

O objeto de comunicação conhecido como PDO é utilizado principalmente para
transferência de dados de processo, ou do valor dos objetos de manufatura contidos no Dicionário.
É um quadro que apresenta prioridade mais elevada do que o SDO e por definição do protocolo, é
utilizado para comunicação em tempo real. Em uma rede CANopen esse é o principal mecanismo
de troca de dados.
Estabelecer uma comunicação utilizando PDO’s, entretanto, não é trivial. Ela requer vários
acessos ao Dicionário de Objetos e necessita obrigatoriamente de uma etapa de configuração dos
PDO’s a serem transmitidos e recebidos pelo nó.
Por definição do protocolo, todo nó deve disponibilizar para utilização pelo menos 4
PDO’s de transmissão e 4 PDO’s de recepção. A configuração destes PDO’s pode ser dinâmica ou
estática. A configuração dinâmica é feita utilizando mensagens do tipo SDO.
Cada PDO possui no Dicionário de Objetos duas entradas principais: PDO parameter
(Parâmetro PDO) e PDO mapping (Mapeamento PDO). O mestre da rede pode configurar a
comunicação através de PDO’s de qualquer nó escravo, apenas enviando mensagens de Download
SDO para escrita nestes dois objetos do Dicionário. O PDO parameter serve para configurar a forma
de comunicação, o PDO mapping serve para definir o que será transmitido.
Como cada nó deve suportar 4 PDO’s de transmissão e 4 de recepção. Existem no mínimo
16 entradas no Dicionário relacionadas à esse objeto de comunicação:
• Receive PDO 1 parameter;
• Receive PDO 2 parameter;
• Receive PDO 3 parameter;
• Receive PDO 4 parameter;
• Receive PDO 1 mapping;
• Receive PDO 2 mapping;
25

• Receive PDO 3 mapping;
• Receive PDO 4 mapping;
• Transmit PDO 1 parameter;
• Transmit PDO 2 parameter;
• Transmit PDO 3 parameter;
• Transmit PDO 4 parameter;
• Transmit PDO 1 mapping;
• Transmit PDO 2 mapping;
• Transmit PDO 3 mapping;
• Transmit PDO 4 mapping.

O objeto Receive PDO parameter contem duas entradas: COB-ID e o tipo do transmissão do
PDO.
O objeto Transmit PDO parameter contem três entradas: COB-ID , o tipo de transmissão do
PDO e o Inhibit time.
Os tipos de transmissão definidos são:
� Trasmissão Síncrona;
� Trasmissão Assíncrona disparada por evento;
� Transmissão Assíncrona diparada pela recepção de mensagens de requisição
remota (mensagens RTR);
A transmissão síncrona utiliza um tipo de mensagem especial denominada SYNC, descrita
na próxima seção.
A transmissão assíncrona pode ser disparada pela recepção de uma mensagem de
requisição ou pela ocorrência de algum evento pré-determinado no dispositivo. Uma mensagem de
requisição de um PDO possui como identificador o COB-ID do PDO requisitado e o bit RTR =
‘1’.
O último parâmetro de configuração da transmissão dos PDO’s é o Inhibit time. Esse
parâmetro define a janela de tempo mínima entre duas transmissões consecutivas de um mesmo
PDO.
O PDO mapping define o número deobjetos mapeados e quais são estes objetos. Uma
mensagem PDO é definida apenas pelo idenficador dado pelo COB-ID e o campo de dados, que
contém os valores dos objetos mapeados. Como o campo de dados possui 64 bits (8 Bytes), é
possível mapear em um PDO de 1 a 8 objetos. No caso de 8 objetos, todos devem ter tamanho de
1 Byte.
O mapeamento é feito através do Dicionário, e para um PDO, existem 8 entradas no PDO
mapping, cada entrada relativa a um objeto mapeado. Essas entradas são ordenadas a partir do sub-
índice 0x01. O sub-índice 0x00 do PDO mapping corresponde ao número de objetos mapeados.
Quando essa entrada é igual a zero, o PDO é desabilitado.
Para mapear o objeto de índice: 0x6040, sub-índice: 0x01, e tamanho 0x20 (32 bits), por
exemplo, como primeiro objeto do PDO, escreve-se no PDO mapping, no sub-índice 0x01, o
valor: 0x60400120. A Figura 12 mostra como é feita a montagem de um PDO de transmissão com
dois objetos mapeados.
26

Figura 12 - Relação entre o PDO parameter e o PDO mapping do Dicionário de Objetos e a
montagem da mensagem do tipo PDO.
Ao receber um PDO, o nó procura no dicionário de objetos, um por um, todos os objetos
mapeados na mensagem. Para cada objeto, ele verifica o tamanho do dado, e retira os bytes
correspondentes do campo de dados.

2.3.2.3 2.3.2.3 2.3.2.3 2.3.2.3 SYNC SYNC SYNC SYNC –––– Mensagens de SincronizaçãoMensagens de SincronizaçãoMensagens de SincronizaçãoMensagens de Sincronização

A mensagem SYNC é uma das mais simples definidas pelo protocolo. Ela possui um COB-
ID igual a 0x080. Na SYNC, todos os 64 bits de dados são iguais a ‘0’. A estrutura da SYNC é vista
na Tabela 3.

SYNC
COB-ID CAMPO DE DADOS
0x080 0 0 0 0 0 0 0 0
Tabela 3 - Formato padrão da mensagem SYNC.

O COB-ID da SYNC pode ser alterado escrevendo no Dicionário de Objetos no índice
0x1005, subíndice 0x00. Outras duas entradas relativas a SYNC estão nos índices 0x1006 –
Communication Cycle Period, e 0x1007 – Synchronous Window Length.
27

O serviço de SYNC funciona de acordo com o mecanismo produtor-consumidor. Na rede
existe apenas um produtor de SYNC’s e todos os outros nós são consumidores. Se nenhum PDO
de um nó está configurado para trasmissão síncrona, a leitura da SYNC no barramento é
transparente.
As SYNC’s são enviadas pelo produtor por um período fixo, definido pelo parâmetro
Communication Cycle Period. Quando um consumidor recebe a SYNC, desencadeia-se a transmissão
dos PDO’s configurados com tipo de transmissão síncrona.
Essa transmissão ocorre após decorrido o tempo definido pelo parâmetro Synchronous
Window Length. Não necessariamente um nó precisa enviar um PDO síncrono toda vez que ele
recebe uma SYNC. O protocolo prevê a possibilidade de se configurar o nó para que o envio seja
disparado após a recepção de ‘n’ SYNC’s consecutivas, sendo n ={1,2,3,4..., 240}.
A Figura 13 mostra o mecanismo de transmissão de SYNC’s, a transmissão dos PDO’s
síncronos de dois nós e a relação com os parâmetros definidos no Dicionário de Objetos (índices:
0x1006 e 0x1007). O nó 1 envia o PDO após toda recepção de SYNC, o nó 2 envia o PDO após a
recepção de duas SYNC’s.

Figura 13 - Mecanismo de produção de SYNCs e envio de PDO's síncronos.
A comunicação síncrona pode ser cíclica ou acíclica. Na cíclica, o envio dos PDO’s é
disparado pela recepção de 1, 2, 3, até 240 SYNC’s. Na comunicação acíclica, o envio é pré-
disparado pelo recebimento de uma mensagem de requisição ou por algum evento interno do
dispositivo, e então o PDO é enviado após a recepção da SYNC seguinte.

2.3.2.42.3.2.42.3.2.42.3.2.4 EMCY EMCY EMCY EMCY –––– Mensagens de EmergênciaMensagens de EmergênciaMensagens de EmergênciaMensagens de Emergência

As mensagens de emergência são disparadas pela ocorrência de algum erro interno em
determinado nó. Elas podem ser enviadas a qualquer instante, e em termos de prioridade, só se
encontram abaixo das mensagens NMT Module Control e SYNC.
A mensagem de emergência só é enviada uma vez, no momento em que ocorre o erro no
dispositivo. A Tabela 4 mostra o formato destas mensagens.

Mensagem de Emergência
Identificador Campo de Dados
COB-ID Byte 0-1 Byte 2 Byte 3-7
0x080 + Node-ID Código do Erro
(Indica o tipo do
erro ocorrido)
Error Register
(Objeto 0x1001, do
Dicionário)
Campo para
especificar o erro.
Tabela 4 - Formato das mensagens de Emergência.

2.3.2.52.3.2.52.3.2.52.3.2.5 NMT NMT NMT NMT –––– Network ManagementNetwork ManagementNetwork ManagementNetwork Management

Os serviços NMT são implementados segundo o mecanismo mestre-escravo. Toda rede
possui apenas um mestre NMT e todos os demais nós são considerados escravos. As mensagens
NMT são utilizadas para o gerenciamento e monitoramento da rede.
Possuem prioridade mais elevada que as SDO’s, PDO’s e SYNC’s.
Existem três categorias principais destas mensagens:
� NMT Module Control: São mensagens enviadas pelo mestre para fazer com que
determinado nó transite entre um estado NMT e outro. A máquina de estados de
um nó CANopen é definida pelo protocolo, e ela pode ser mínima ou estendida.
Qualquer nó deve implementar obrigatoriamente a máquina de estados mínima,
que pode ser vista na Figura 14.

Figura 14 - Máquina de estados finita mínima de um nó CANopen. Retirada de (Boterenbrood,
2000).
29

As letras nos parênteses mostram os objetos de comunicação permitidos dentro
dos diferentes estados: a – NMT, b – Node Guarding, c – SDO, d – Emergency, e –
PDO, f – Boot-up.
As transições entre os estados são provocadas pela recepção das mensagens do
tipo Module Control que são enviadas unicamente pelo mestre NMT da rede. E cada
uma possui um especificador de comando - cs:
1. Iniciar nó remoto (cs = 0x01);
2. Parar nó remoto (cs = 0x02);
3. Entrar no estado pré-operacional (cs = 0x80);
4. Resetar nó (cs = 0x81);
5. Resetar comunicação (cs = 0x82);
6. Inicialização do dispositivo concluída, envia mensagem boot up e entra no
estado pré-operacional automaticamente. Não depende de nenhum
comando NMT.
O formato destas mensagens pode ser visto na Tabela 5.

NMT Module Control
Identificador Campo de Dados
COB-ID Byte 0 Byte 1 Bytes 2-7
0x000 CS Node-ID Não Importa
Tabela 5- Formato de uma mensagem NMT Module Control. *CS = Command Specifier.
As mensagens NMT Module Control são as mensagens de mais alta prioridade entre
aquelas definidas pelo CANopen, uma vez que seu COB-ID é igual a zero. O nó
de destino dessa mensagem é então definido no Byte 1 do campo de dados.
Quando esse Byte é igual a 0, a mensagem é recebida e interpretada por todos os
nós da rede.
As mensagens Module Control não possuem resposta.

� Mensagem de Boot-up

A transição 6 da Figura 14 ocorre automaticamente quando um nó termina seu
processo de inicialização. Então uma mensagem chamada NMT Boot-up é enviada
pelo escravo para sinalizar ao mestre a sua presença na rede. A Tabela 6 mostra o
formato de uma mensagem de Boot-up.

NMT Boot-up
Identificador RTR Campo de Dados
COB-ID Byte 0 Bytes 1-7
0x700 + Node-ID 0 0 Não interessam.
Tabela 6 - Formato de uma mensagem de Boot-up.

� NMT Node Guarding: As mensagens Node Guarding servem para que a qualquer
momento o mestre questione o escravo sobre o seu estado atual. Para isto, o
30

mestre envia um quadro remoto (RTR = 1), com o COB-ID = 0x700 + Node-ID
(do nó escravo).
O escravo então responde com uma mensagem com o mesmo COB-ID e com a
indicação do seu estado conforme a Tabela 7.

Resposta à mensagem de requisição NMT Node Guarding
Identificador Campo de dados
COB-ID Byte 0 Bytes 1-7
0x700+Node-ID bit 7: toggle, bit 6-0: estado Não importam
Tabela 7 - Resposta à requisição do tipo Node Guarding.
O toggle (bit 7 do Byte 0 do campo de dados) alterna entre ‘0’ e ‘1’ para cadarequisição NMT Node Guarding, sendo que seu valor inicial é ‘0’.
O estado (bits 6-0 do Byte 0) pode ser um dos listados na Tabela 8, para um nó
com uma máquina de estados mínima. Outros estados podem ser definidos de
acordo com o dispositivo e sua máquina de estados NMT.

Valor Estado
0 Inicializando
4 Parado
5 Operacional
127 Pré-Operacional
Tabela 8 - Estados e seus valores correspondentes dentro das mensagens de resposta ao Node
Guarding.
As mensagens de Node Guarding fazem parte de uma subcamada dentro do Serviço
NMT, que corresponde exclusivamente à parte de monitoramento da rede.

Nas seções seguintes são descritos os dois mecanismos previstos pelo protocolo para o
monitoramento da rede: o HeartBeat e o Node Guarding.

2.3.3 2.3.3 2.3.3 2.3.3 HeartBeatHeartBeatHeartBeatHeartBeat

No HeartBeat o nó escravo envia periodicamente uma mensagem do tipo HeartBeat para
sinalizar ao nó mestre o seu estado. A mensagem HeartBeat é uma mensagem Node Guarding com o
toggle sempre igual a ‘0’. O período de envio dessas mensagens é definido no Dicionário de Objetos
através do Producer HeartBeat Time (índice: 0x1017, sub-índice: 0x00).
O HeartBeat possui mais alta prioridade que o Node Guarding, e em qualquer momento, o nó
só poderá implementar um dos dois mecanismos. O HeartBeat é desativado colocando o valor do
Producer HeartBeat Time igual a zero.

2.3.42.3.42.3.42.3.4 Node GuardingNode GuardingNode GuardingNode Guarding

No Node Guarding, o mestre requisita periodicamente que o escravo sinalize seu estado
atual. As requisições remotas são enviadas a um período conhecido como Guard Time. Quando o
escravo não recebe essa requisição dentro de um intervalo de tempo dado pelo Life Guard Time, ele
entra em estado de erro (e em estado NMT pré-operacional), enviando uma mensagem de
31

emergência para rede. Esse mecanismo implementado no nó escravo é conhecido como Life
Guarding.
O Life Guard Time é definido pelo produto entre o Guard Time e o Life Time Factor, presentes
no Dicionário de Objetos nos índices: 0x100C e 0x100D, respectivamente. A Figura 15 mostra a
relacão entre estes dois parâmetros.

Figura 15 - Node Guarding, Life Guarding e parâmetros relacionados.

2.42.42.42.4 Adaptador CANUSBAdaptador CANUSBAdaptador CANUSBAdaptador CANUSB

O adaptador CANUSB da LAWICEL, mostrado na Figura 16, utilizado para conectar o
computador ao barramento CAN possui dois tipos de drivers, compatíveis com sistema operacional
Windows ou Linux. Um driver é o Virtual COM Port - VCP que atua como uma porta serial (COM
no Windows ou TTY no Linux) virtual padrão. O outro driver é o D2XX - Direct Driver, que utiliza
funções de uma Biblioteca FTD2XX, diponibilizadas através de arquivos .lib ou .so (para o Linux).
32

Figura 16 - Adaptador CANUSB.

O adaptador oferece suporte aos formatos CAN 2.0A e CAN 2.0B, quadros remotos e
implementa filas FIFO (First In First Out - primeiro a entrar primeiro a sair) para transmissão -
máximo de 8 quadros, e recepção - máximo de 32 quadros. Não necessita de alimentação externa,
sendo alimentado pela própria porta USB. Ele possui um led vermelho para indicar a entrada no
estado “error passive” ou “bus off”.
O adaptador possui limitações quanto ao número de quadros que pode enviar e receber.
Segundo (LAWICEL, 2005), ele é adequado para redes de baixa velocidade, funcionando muito
bem com taxa de transmissão de 250 Kbps ou menor. Podendo ser usado, entretanto, com taxas de
até 1 Mbps, desde que, a carga no barramento não seja elevada. Nessas situações, pode-se
configurar um filtro de mensagens para que apenas determinados quadros sejam aceitos.
A escolha do driver também influencia no desempenho do adaptador. Utilizando o D2XX
a transferência de quadros é mais rápida, porém a implementação de programas de comunicação
com o CANUSB demanda mais tempo de aprendizado, por utilizar uma API (Application Programmer
Interface) dedicada. O controle e a comunicação com o adaptador ocorre através de comandos
ASCII.
Observa-se que o adaptador introduz algumas limitações quanto à velocidade e à taxa de
processamento de dados em alguns nós da rede. Existem medidas que atenuam estas limitações,
mas elas podem não ser viáveis em algumas aplicações. Por exemplo, o adaptador permite
implementar filtros e máscaras de mensagens, mas para desenvolver um mestre, essas estruturas
não são viáveis, pois o mestre deve receber e interpretar todas as mensagens que circula no
barramento.

2.52.52.52.5 EPOS MaxonEPOS MaxonEPOS MaxonEPOS Maxon

A EPOS da Maxon Motor é o dispositivo central de referência para o desenvolvimento
deste trabalho e pode ser vista na Figura 17. Além da interface CAN ela possui também uma porta
33

RS-232. O Dicionário de Objetos pode ser acessado através de qualquer uma das duas interfaces
uma vez que somente através dele é feita a configuração e operação da EPOS.

Figura 17 - EPOS 24/5 da Maxon. Retirada de (Maxon Motor, 2007).

O identificador da EPOS na rede é definido através de um DIP-Switch de 8 pinos,
utilizando codificação binária. Dos 8 pinos, 7 são utilizados na definição do endereço, permitindo
valores entre 1 e 127, o oitavo pino serve para ativar o resistor de terminação do barramento.
Quando a EPOS se encontra na extremidade do barramento, este pino deve estar na posição ON.
Deixando os 7 pinos de endereço na posição OFF, o identificador da EPOS passa a ser definido
pelo valor contido no objeto Node ID (índice: 0x2000, sub-índice: 0x00) do Dicionário de Objetos.
Além dos estados NMT mostrados anteriormente, a EPOS implementa uma máquina de
estados própria mostrada na Figura 18.
Para colocar a EPOS em funcionamento, é necessário seguir ambas as máquinas de
estados, a definida pelo CANopen e a específica do dispositivo. As transições da máquina de
estados da Figura 18 são causadas por eventos internos ou por comandos recebidos através do
objeto Controlword (índice: 0x6040, sub-índice: 0x00).
34

Figura 18 - Máquina de estados do funcionamento da EPOS. Retirada de (Maxon Motor, 2010).
O tipo de controle implementado pela EPOS é definido através da seleção do modo de
operação. Esssa seleção é feita escrevendo no objeto Modes of operation (índice: 0x6060, sub-índice:
0x00) do Dicionário de Objetos. A escolha do modo de operação é feita, inclusive, com base no
tipo de motor e sensor conectado à EPOS.
Nos Capítulos seguintes, serão detalhadas mais informações pertinentes sobre o
funcionamento da EPOS e seu Dicionário.

2.62.62.62.6 ConclusãoConclusãoConclusãoConclusão

Durante a pesquisa bibliográfica encontrou-se apenas dois trabalhos, (Bortel, 2002) e
(Hagström, 2010), sobre a implementação de programas para o CANopen, sem utilização de
softwares disponíveis no mercado. Como alternativas, podem ser citadas o canFestival, um
framework de licença livre GPLv2 e LGPLv2, para implementação do protocolo CANopen e o
CANopen Stack produzido pela Vector CANopen. O canFestival não oferece suporte ao CANUSB
da LAWICEL, e (Bortel, 2002) relata em seu trabalho que o canFestival não foi usual para solução
do problema de implementar uma rede CANopen para um veículo autônomo sub-aquático.
Os dispositivos CANopen (comerciais) geralmente possuem um programa para acesso ao
Dicionário de Objetos através de uma outra interface, que não a CAN. Na EPOS, por exemplo,
pode-se configurar o Dicionário através da interface RS-232 utilizando o programa
EPOSUserInterface disponibilizado pela Maxon Motor. Isso objetiva retirar da rede CANopen a
tarefa de configuração do Dicionário de Objetos. O usuário faz a configuração prévia do
dispositivo, e depois é necessário criar um programa simples, cuja única função é enviar e receber as
mensagens pré-definidas.
Entretanto, pela complexidade do CANopen, mesmo utilizando um programa auxiliar para
configurar o Dicionário, é necessário saber como eo que deve ser alterado durante a configuração.
O protocolo possui muitos serviços e a compreensão de todos eles não é intuitiva. Por isso, este
Capítulo teve como foco a explicação detalhada do protocolo para melhor entendimento do
desenvolvimento do mestre da rede.

Capítulo 3Capítulo 3Capítulo 3Capítulo 3

DesenvoDesenvoDesenvoDesenvollllvimentovimentovimentovimento

3.1 Intr3.1 Intr3.1 Intr3.1 Introduçãooduçãooduçãoodução

Durante o desenvolvimento da rede CANopen, diversos programas de implementação de
um mestre foram feitos. Apenas dois resultaram em um conjunto de funções de comunicação e
configuração dos serviços do protocolo que possibilitem o desenvolvimento de novas aplicações
com outros dispositivos CANopen.
Neste Capítulo é descrito o processo de desenvolvimento do software.

3.2 3.2 3.2 3.2 Rede CANRede CANRede CANRede CAN

A primeira etapa do desenvolvimento consistiu em estabelecer a comunicação entre dois
computadores através de um barramento CAN, utilizando um CANUSB em cada computador. O
principal objetivo era criar uma interface de comunicação com o adaptador, sem se importar com a
aplicação que seria desenvolvida. O programa foi desenvolvido em C++, utilizando como
compilador o Dev-C++.
Como mídia de transmissão, utilizou-se par trançado com 4 fios, dois conectores DB-9
fêmea e dois resistores de 120 Ω para terminação do barramento. O adaptador apresenta uma
vantagem de não precisar de uma fonte de alimentação externa para energizar o barramento, pois a
alimentação é feita através da porta USB do computador.
Inicialmente, foi utilizado o driver VCP, citado no Capítulo anterior. O objetivo era criar
uma interface portável que não fosse dependente de drivers dedicados para Sistema Operacional
Windows. Entretanto, o VCP não proporciona muita flexibilidade se comparado ao D2XX, além
de ter uma resposta mais lenta. O driver D2XX possui funções de suporte à configuração e
operação do adaptador que não podem ser implementadas com o VCP. Optou-se por utilizar o
D2XX para facilitar o desenvolvimento do programa e pelo fato de também ser possível utilizá-lo
em Sistema Operacional Linux.
Para utilizar este driver no Linux, é necessário fazer uma conversão dos tipos de dados que
são usados pelas funções da biblioteca “ftd2xx”. Esses tipos de dados são definidos na biblitoteca
“windows.h”. Neste caso, basta utilizar um arquivo disponível em (Lawicel, 2006), chamado
“WinTypes.h” que cria as definições dos tipos do Windows para outros sistemas operacionais.
Estabelecida a troca de mensagens de dados e mensagens remotas entre dois
computadores, utilizando inicialmente o driver VCP e posteriormente o D2XX, iniciou-se o
37

próximo passo, que consistiu em realizar esta comunicação utilizando mensagens do protocolo
CANopen.

3.3 3.3 3.3 3.3 MestreMestreMestreMestre CANopenCANopenCANopenCANopen

A primeira abordagem de desenvolvimento do mestre utilizou como referência uma API
CANopen de código aberto e lincença pública GNU - General Public License, versão 3.0,
desenvolvida por Ulrik Hagstrom, compatível com o adaptador CANUSB e diversos outros
disponíveis no mercado, encontrada em (Hagström, 2010). O objetivo era entender como a API foi
desenvolvida e modificá-la, se necessário, adaptando-a às necessidades do projeto. Entretanto, foi
possível compreender e utilizar apenas a parte do código relativa à interface com o adaptador,
devido a ausência de uma boa documentação da API.
Inicialmente, foram empregados esforços para desenvolver um programa mais genérico,
que implementasse todos os serviços do CANopen e pudesse ser utilizado como mestre ou escravo,
dependendo da aplicação. A abordagem inicial com a API CANopen foi malsucedida por não ter
um conhecimento claro e mais aprofundado sobre o funcionamento do protocolo.
Uma segunda abordagem foi feita utilizando como referência (Bortel, 2002). Ele cita em
um relatório a implementação de um mestre CANopen para rede de um veículo autônomo sub-
aquático, e cita também a forma como o programa foi estruturado (de maneira abstrata).
Utilizando a interface de comunicação com o adaptador criada anteriormente, iniciou-se
uma nova tentativa de implementar um mestre CANopen genérico utilizando o trabalho de (Bortel,
2002) como referência. O resultado foi um programa mal estruturado e com alguns erros de
execução, principalmente devido a falta de compreensão de alguns pontos do protocolo.
Mantendo essa referência, tentou-se uma nova abordagem, iniciando o desenvolvimento do
software pela etapa de projeto conceitual, criando diagramas de classe e de sequência que pudessem
descrever o funcionamento das classes que deveriam compor o programa. Neste ponto do projeto
já estava claro a maneira como o programa deveria funcionar e o que ele deveria fazer para atender
às necessidades do CANopen, mas não se sabia como implementar uma estrutura que pudesse
funcionar da maneira desejada.
A terceira referência utilizada no desenvolvimento do software foi o código fonte de um
programa feito por Valdir Grassi Jr, professor do departamento de Engenharia Elétrica da USP,
utilizado para estabelecer a comunicação entre um computador e uma EPOS. Basicamente, se trata
de um programa simples e limitado, pois restringe a comunicação à utilização de apenas mensagens
do tipo SDO e para somente uma EPOS. É necessário lembrar que essas mensagens são as que
apresentam menor prioridade dentro do CANopen.
A partir desse momento, alterou-se o foco do desenvolvimento, de um programa genérico
para um programa específico de comunicação com a EPOS. Essa abordagem permitiu esclarecer
todas as dúvidas restantes sobre o protocolo e criar estruturas que pudessem implementar os
serviços que o mestre CANopen deveria ter. Posteriormente, as funções específicas para
comunicação com uma EPOS foram facilmente modificadas para permitir a inserção de mais
EPOS’ na rede.
O programa, a partir de agora chamado Programa 1, resultante desta última abordagem
implementa os seguintes serviços (de um mestre CANopen):
• Comunicação SDO com transferência única;
• Configuração dinâmica de PDO’s;
• Comunicação Assíncrona de PDO’s através de mensagens remotas;
• Recepção de mensagens de Emergência;
38

• Consumidor HeartBeat;
• Serviço NMT Node Guarding e Module Control
• Reconhecimento dinâmico de novos nós através de mensagens Boot-up.
E ele não implementa:
• A produção de SYNC’s e nem a comunicação síncrona de PDO’s,
• Comunicação SDO através de blocos de mensagens.
• E não possui um Dicionário de Objetos, nem sabe quais são os objetos presentes
nos Dicionários dos outros nós.

No Anexo 1 se encontra o código fonte com as principais definições e estruturas utilizadas
no programa. O Anexo 2 mostra o diagrama de classe “as built” do Programa 1.
Neste primeiro programa, a classe que implementa a interface direta com o adaptador foi
criada baseada na API CANopen de Ulrik Hagstrom. Como será visto no próximo Capítulo, o
tempo de resposta das funções de comunicação desse programa não foi satisfatório. Para melhorar
o desempenho do mestre, foi desenvolvido um novo programa, com uma classe de interface
baseada no código desenvolvido por Valdir Grassi Jr. O Anexo 3 mostra o diagrama de classe “as
built” deste segundo programa, que será chamado de Programa 2.
O Programa 2 implementa os seguintes serviços:
• Comunicação SDO com transferência única;
• Configuração dinâmica de PDO’s;
• Comunicação Assíncrona de PDO’s através de mensagens remotas;
• Recepção de mensagens de Emergência;
• Serviço NMT Node Guarding e Module Control.
E não implementa:
• Consumidor HeartBeat;
• Reconhecimento dinâmico de novo nós através de mensagens de Boot-up;
• Produção de SYNC’s e comunicação síncrona de PDO’s;
• Comunicação SDO por blocos de mensagens;
• Não possui Dicionário de Objetos