Sie sind auf Seite 1von 70

CENTRO UNIVERSITÁRIO DO LESTE DE MINAS GERAIS – UNILESTE-MG

Curso de Engenharia Elétrica

REDES INDUSTRIAIS SOB A TECNOLOGIA CAN

DEVICENET, CANOPEN E SDS

Coronel Fabriciano, 2005


RICARDO DUARTE SEBBE

REDES INDUSTRIAIS SOB A TECNOLOGIA CAN

DEVICENET, CANOPEN E SDS

Monografia apresentada ao curso de Engenharia

Elétrica do Centro Universitário do Leste de Minas

Gerais como pré-requisito para obtenção do Título

de Engenheiro Eletricista, orientado pelo professor

Dr. Max Mauro Dias Santos.

Coronel Fabriciano, 2005


RICARDO DUARTE SEBBE

REDES INDUSTRIAIS SOB A TECNOLOGIA CAN

DEVICENET, CANOPEN E SDS

Monografia submetida à Comissão

Examinadora designada pelo Colegiado do

Curso de Engenharia Elétrica como requisito

parcial para a obtenção de grau de Engenheiro

Eletricista. Aprovada em ____ / ____ / ____

Orientador:Prof. Dr. Max Mauro Dias Santos


Centro Universitário do Leste de Minas Gerais

Convidado:

Convidado:
DEDICATÓRIA

Dedico este trabalho a minha família. Meus pais

Jandiro Geraldo Sebbe Fontes e Josina Pereira

Duarte Fontes, meu irmão Rodrigo Duarte Sebbe,

minha noiva Flávia Duarte Trevisani e todas as

pessoas que de alguma forma contribuíram para

realização do mesmo.
AGRADECIMENTOS

Ao Centro Universitário do Leste de Minas Gerais - UnilesteMG, que tem

incentivado à pesquisa, acreditando que esta é uma forma de crescimento e de busca ao

conhecimento científico.

Agradeço ao Professor Dr. Max Mauro Dias Santos, que orientou, esteve presente e

atuante durante toda a realização deste estudo.

Considero muitas pessoas importantes no decorrer do desenvolvimento desse trabalho

de graduação, que não se limitam somente ao projeto e execução desta pesquisa.

De toda forma, sei que algumas incondicionalmente aonde quer que eu vá, estarão

presentes comigo, conferindo uma intensa cumplicidade aos momentos de dificuldades e

conquistas experimentadas. Registro, portanto, neste documento meus sinceros

agradecimentos aos que compartilharam comigo, de alguma forma, mais uma etapa vencida.

O caminho é longo e acredito na força necessária para entender que o mesmo vai

muito além do que poder-se-ia simplesmente ver.

Amor, conhecimento, disposição, trabalho, confiança e incentivo, são algumas das

palavras que, unidas, conduzem ao que representa verdadeiramente, com toda sua rica gama

de significados, este sentimento de gratidão por vocês. Meus pais e irmão.

Agradeço a todos professores, palestrantes, orientadores, colegas do curso, e enfim,

todas as pessoas que estiveram presentes e contribuíram para o enriquecimento do estudo.


EPÍGRAFE

Não existem erros, apenas lições.

O crescimento é um processo de tentativa

e erro e experimentação. As experiências

que não deram certo fazem parte do

processo, assim como as bem sucedidas.

As respostas estão dentro de você. Tudo o

que tem a fazer é analisar, ouvir e acreditar.

Tallulah Bankhead
RESUMO

As tecnologias de comunicação têm sido determinantes no desenvolvimento de

tecnologias para a automação. A capacidade de comunicação entre dispositivos e o uso de

mecanismos padronizados, abertos e transparentes, são componentes indispensáveis no

conceito da automação atual. Nas fábricas de hoje, os dispositivos analógicos usados são

ligados individualmente a um controlador central. As ligações ponto a ponto é o padrão

usado atualmente, mas estes são muito limitados na informação que transmitem e que

recebem. Na indústria, é necessário saber o estado das máquinas, ao mesmo tempo que se

controlam as aplicações, para que tudo funcione da melhor maneira e qualquer erro seja

corrigido o mais depressa possível. Para isso, a rede que interliga as máquinas umas com as

outras, e estas aos seus controladores, é muito importante, pois tem que permitir rapidez,

desempenho e confiabilidade, ao mesmo tempo que deve ser fácil de instalar e configurar.

No entanto, existem muitos tipos de tecnologias diferentes num mercado muito fragmentado

onde várias empresas buscam uma melhor solução para redes industriais.

Atualmente, o mercado oferece produtos que contêm um grande conjunto de sensores

e atuadores, como automóveis, indústrias e sistemas de segurança. Integrar as informações

destes sensores e atuadores não é uma tarefa fácil, já que muitas vezes é exigido um meio

físico construído com uma grande quantidade de fiação, isto sem contar o número de

conectores. Grande quantidade de fios, implica numa linha de montagem mais cara,

complexa e lenta, o que inviabiliza seu uso em larga escala. Motivados pelas aplicações

industriais, várias companhias, vêm investindo no projeto de controladores que pudessem

gerenciar o tráfego de informações com interfaces através de um meio físico reduzido,

possivelmente um barramento, porém capaz de possibilitar a multiplexação dessas

informações.
A rede CAN (Controller área Network) é considerada aceitável devido a sua

capacidade de comunicação em tempo real. CAN é um protocolo extremamente robusto com

características de detecção e correção de erro extensa que facilmente resiste o ambiente físico

e elétrico severo apresentado em uma indústria. Este trabalho apresenta um estudo teórico

baseado nas redes industriais sob a tecnologias CAN (DeviceNet, CANOpen e SDS).

Palavras-chave: Redes industriais, Controller área Network, CAN, DeviceNet, CANOpen e

SDS.
LISTA DE FIGURAS

FIGURA 1 APLICAÇÃO DE UMA REDE CAN EM AUTOMÓVEIS ................................................... 27

FIGURA 2 CAMADAS DO PROTOCOLO CAN.............................................................................. 29

FIGURA 3 PADRÕES DE FRAMES CAN...................................................................................... 30

FIGURA 4 FRAME DE DADOS .................................................................................................... 32

FIGURA 5 FRAME REMOTO ....................................................................................................... 32

FIGURA 6 FRAME DE ERRO ....................................................................................................... 33

FIGURA 7 PROCESSO DE ARBITRAGEM ..................................................................................... 37

FIGURA 8 INSTALAÇÃO DA REDE DEVICENET PARA 125 KBITS/S ............................................ 41

FIGURA 9 CONFIGURAÇÃO DA DIP SWITCH .............................................................................. 45

FIGURA 10 LOCALIZAÇÃO DOS RESISTORES DE TERMINAÇÃO .................................................. 48

FIGURA 11 CORRENTE DE CONSUMO DOS EQUIPAMENTOS ....................................................... 49

FIGURA 12 ATERRAMENTO DA REDE DEVICENET.................................................................... 52

FIGURA 13 ATERRAMENTO COM DUAS FONTES NA REDE DEVICENET ..................................... 53

FIGURA 14 ESTRUTURA DE DISPOSITIVOS CANOPEN............................................................... 57

FIGURA 15 ROBÔS INDUSTRIAIS MANIPULADORES ................................................................... 61

FIGURA 16 EXEMPLO SIMPLIFICADO DE UM SISTEMA SDS ....................................................... 63

FIGURA 17 MODELO FÍSICO SDS.............................................................................................. 65

FIGURA 18 REPRESENTAÇÃO BÁSICA DAS PRIMITIVAS DE SERVIÇO .......................................... 66


LISTA DE TABELAS

TABELA 1 MODELO ISO/OSI ................................................................................................... 22

TABELA 2 DISTÂNCIAS VARIÁVEIS DA REDE DE INÍCIO A FIM COM A TAXA DE TRANSMISSÃO .. 46

TABELA 3 FÓRMULA PARA CÁLCULO DA QUEDA DE TENSÃO NO CABO..................................... 49

TABELA 4 MODELOS ISSO/OSI E SDS. ................................................................................... 64


SUMÁRIO

1 INTRODUÇÃO ................................................................................................................. 13
1.1 MOTIVAÇÃO ................................................................................................................ 15
1.2 ESTADO DA ARTE .............................................................................................................. 16
2 SISTEMA DE AUTOMAÇÃO INDUSTRIAL .............................................................. 18
2.1 A COMUNICAÇÃO EM SISTEMAS DISTRIBUÍDOS ............................................................... 19
2.1.2 MODELO CLIENTE-SERVIDOR:......................................................................................... 19
2.1.3 MODELO MULTICAST ..................................................................................................... 20
2.2 DIVISÃO EM CAMADAS ..................................................................................................... 21
3 A TECNOLOGIA CAN .................................................................................................... 25
3.1 INTRODUÇÃO .................................................................................................................... 25
3.2. ÁREA DE APLICAÇÃO....................................................................................................... 27
3.2.1 EM AUTOMÓVEIS ............................................................................................................ 27
3.2.2 EM INDÚSTRIAS .............................................................................................................. 28
3.2.3 ESTRUTURA DE CAMADAS DO CAN ................................................................................ 28
3.2.4 PADRÕES CAN ............................................................................................................... 30
3.2.5 FORMATO DE FRAMES ...................................................................................................... 32
3.2.6 VERIFICAÇÃO E SINALIZAÇÃO DE ERROS ......................................................................... 33
3.2.7 LIMITAÇÃO DE ERROS ..................................................................................................... 35
3.2.8 PROCESSO DE ARBITRAGEM ............................................................................................ 36
4. DEVICENET .................................................................................................................... 38
4.1 INTRODUÇÃO .................................................................................................................... 38
4.2 A ARQUITETURA DEVICENET .......................................................................................... 39
4.2.1 A CAMADA FÍSICA .......................................................................................................... 39
4.2.2 A CAMADA LINK DE DADOS............................................................................................. 41
4.3 SERVIÇOS DE CONTROLE.................................................................................................. 42
4.4 QUALIDADE DO PROJETO DA REDE DEVICENET ............................................................. 44
4.4.1 INTRODUÇÃO .................................................................................................................. 44
4.4.2 ENDEREÇAMENTO DO INSTRUMENTO NA REDE DEVICENET ............................................ 44
4.4.3 COMPRIMENTO DOS CABOS ............................................................................................. 45
4.4.4 TAXA DE COMUNICAÇÃO ................................................................................................ 46
4.4.5 RESISTORES DE TERMINAÇÃO ......................................................................................... 47
4.4.6 POSICIONAMENTO DA FONTE .......................................................................................... 48
4.4.7 CÁLCULO DAS CORRENTES ............................................................................................. 48
4.4.8 CÁLCULO DA TENSÃO NOS EQUIPAMENTOS ..................................................................... 50
4.4.9 ATERRAMENTO ............................................................................................................... 52
5 CANOPEN ......................................................................................................................... 54
5.1 INTRODUÇÃO .................................................................................................................... 54
5.2 MODELO DE COMUNICAÇÕES .......................................................................................... 55
5.2.1 MESTRE-ESCRAVO (MASTER-SLAVE) ............................................................................ 55
5.2.2 CLIENTE – SERVIDOR (CLIENT – SERVER)........................................................................ 55
5.2.3 PRODUTOR – CONSUMIDOR (PRODUCTER – CONSUMER) ................................................. 56
5.3 MODELO DO DISPOSITIVO CANOPEN .............................................................................. 56
5.3.1 ESTRUTURA DO DICIONÁRIO DE OBJETOS ........................................................................ 57
5.4 OBJETOS DE DADOS DE SERVIÇO ...................................................................................... 58
5.4.1 SDO (SERVICE DATA OBJECTS) ..................................................................................... 58
5.4.2 (PDO) PROCESS DATA OBJECTS ..................................................................................... 59
5.5 VANTAGENS ...................................................................................................................... 60
5.6 BREVE COMPARAÇÃO COM AS REDES CONVENCIONAIS .................................................. 60
5.7 EXEMPLO DE APLICAÇÃO ................................................................................................ 60
6 SDS (SMART DISTRIBUTED SYSTEM)...................................................................... 62
6.1 INTRODUÇÃO .................................................................................................................... 62
6.2 MODELO FÍSICO ............................................................................................................... 63
6.2.1 ESPECIFICAÇÃO DA ALIMENTAÇÃO ELÉTRICA DO BARRAMENTO SDS ............................ 65
6.3 SERVIÇOS DA CAMADA DE APLICAÇÃO ............................................................................ 65
7 CONCLUSÕES E RECOMENDAÇÕES ....................................................................... 67
8 REFERÊNCIAS BIBLIOGRÁFICAS ............................................................................ 68
9 BIBLIOGRAFIA RECOMENDADA.............................................................................. 69
1 INTRODUÇÃO

Os grandes avanços tecnológicos nas áreas de microeletrônica e engenharia de

software impulsionaram o surgimento de produtos com melhor desempenho, maior

versatilidade e menor custo. Estas características acompanham uma tendência mundial de

descentralização das aplicações. Neste novo modelo, as novas aplicações devem possuir

partes mais independentes, mas com a possibilidade de compartilhamento de serviços e

informações com as demais. Isto nos leva a um modelo distribuído, onde não apenas as

informações são distribuídas, mas o conhecimento da aplicação. Um importante exemplo é o

dos sistemas de automação industrial, principalmente pelas novas exigências de controle,

distribuição e armazenamento de informações impostas pelo mercado.

Desde meados dos anos 80, vários protocolos de comunicação para sistemas de

automação foram desenvolvidos. Nas fábricas de hoje, os dispositivos analógicos usados são

ligados individualmente a um controlador central. As ligações ponto a ponto é o padrão

usado atualmente, mas estes são muito limitados nas informações que transmitem e que

recebem. As únicas maneiras existentes para solucionar estes problemas é adotar tecnologias

de comunicação digitais proprietárias, mas, com isso o consumidor terá que adquirir

equipamentos que suportem apenas o protocolo específico da rede que foi comprada.

A idéia principal atrás de todo este desenvolvimento é oferecer um método padrão

industrial para que se possa trocar informação entre um dispositivo da rede, tanto sobre as

funções a realizar como sobre as informações de diagnóstico, com um controlador ou uma

aplicação. No entanto, existem muitos tipos de tecnologias diferentes num mercado muito

fragmentado onde várias empresas buscam uma melhor solução para redes industriais.

A utilização de redes permite que dispositivos de campo como sensores, atuadores e

controladores sejam interconectados a um custo baixo, utilizando uma quantidade de

cabeamento menor e requerendo menor manutenção que as conexões ponto-a-ponto. Como


exemplo, a rede CAN (Controller Area Network) (ISO 11898, 1993) foi originalmente

projetada para área automotiva, mas devido à sua comprovada confiabilidade e robustez

também está sendo adotada em aplicações industriais em sistemas que necessitam de

controle distribuído em tempo real.


1.1 Motivação

Atualmente o mercado de automação industrial oferece uma vasta gama de soluções

baseada em redes, que contêm um grande conjunto de sensores e atuadores, como

automóveis, sistemas de segurança ou sistemas de telemetria. Integrar as informações destes

sensores e atuadores não é uma tarefa fácil, já que muitas vezes é exigido um meio físico

construído com uma fiação enorme, isto sem contar o número de conectores. Vários fios

implica numa linha de montagem mais cara, complexa e lenta, o que inviabiliza seu uso em

larga escala. Diversos fornecedores possuem soluções de redes de campo proprietárias,

fazendo com que o cliente fique dependente de produtos, serviços e manutenção de um único

fabricante.

Com o objetivo principal da interoperabilidade e flexibilidade de operação, grupos de

desenvolvedores definem normas de padrão aberto para o desenvolvimento de redes de

campo por todos os interessados. Com isto todos ganham, os desenvolvedores tendo a

flexibilidade de desenvolvimento de linhas de produtos em função da demanda, e o cliente

não ficando totalmente dependente de apenas um fornecedor. Atualmente, diversas redes de

campo de padrão aberto de vários fabricantes estão disponíveis no mercado.

Dentre os protocolos existentes para comunicação industrial, o protocolo CAN

(Controller Area Network) com seu baixo custo, alta confiabilidade, simplicidade e com

características de tempo-real, apresenta-se como uma alternativa adequada para o

desenvolvimento de sistemas de automação industrial.


1.2 Estado da arte

O barramento CAN [1] [2] [3] [4] é um protocolo de comunicação serial

desenvolvido inicialmente pela Bosch para aplicações automotivas e que vem sendo utilizado

em sistemas de automação industrial. Baseado no conceito de multi-mestre, onde todos os

módulos podem se tornar mestre em determinado momento e escravo em outro, suas

mensagens podem ser enviadas em regime multicast. Outro ponto forte da rede CAN, é o

protocolo MAC (Medium Access Control) que tem como função principal o controle de

acesso ao meio físico, além de detecção/sinalização de erros reconhecimento de mensagens

recebidas e desencapsulamento das mensagens. Isso significa que todos os módulos

verificam o estado do barramento, analisando se outro módulo está ou não a enviar

mensagens com maior prioridade, hierarquizando-se assim o processo.

A rede DeviceNet é baseada no protocolo CAN, desenvolvido pela Bosh

originalmente para aplicação automobilística. É uma rede muito versátil, sendo utilizada em

milhares de produtos fornecidos por vários fabricantes, desde sensores inteligentes até

interfaces homem-máquina, suportando vários tipos de mensagens fazendo com que a rede

trabalhe da maneira mais inteligente.

A rede CANOpen [9] foi pré-desenvolvida em um projeto sob a presidência de

Robert Bosh, Alemanha. Em 1995, a especificação da rede CANOpen foi passada para CAN

in Automation (Cia), grupo internacional de usuários e fabricantes. Originalmente, o perfil de

comunicação CANOpen é baseado no protocolo da camada de aplicação CAN. Ela foi

desenvolvida como uma rede embarcada padronizada com capacidade de configuração

altamente flexível. Foi projetada para redes de controle de máquina orientadas por sinal, tal

como sistemas manuais.

Equipamentos, ferramentas e pilhas de protocolo estão largamente disponíveis a

preços razoáveis. Para projetistas de sistemas é muito importante reusar software de


aplicação. Isto requer não somente compatibilidade de comunicação, mas também

interoperabilidade e interconectividade dos equipamentos nos perfis de equipamentos e

interface CANOpen, objetos de aplicação definidos existem para realizar a

interconectividade dos equipamentos CANOpen.

A SDS (Smart Distributed System) é um tipo de rede CAN desenvolvido para unir os

requesitos de velocidade, confiabilidade e flexibilidade incluindo os requerimentos para

controle em tempo real. A SDS desenvolvida pela divisão Micro Switch da Honeywell, é um

avançado sistema de barramento para sensores inteligentes e atuadores.

Os sensores e atuadores inteligentes fazem mais que apenas ligar e desligar, pois os

dispositivos de uma SDS têm um avançado nível de funções, incluindo diagnóstico de

dispositivo. A especificação da Smart Distributed System (SDS) compreende um sistema

padronizado de interconexão para dispositivos inteligentes (Smart Devices), com resposta

rápida e baixo custo em uso industrial. Este sistema é baseado em CAN, a qual é definida

pela Bosch V2.0 CAN Specification.

Em uma implementação Smart Distributed System, cada barramento (um ou mais)

interconecta-se a um grupo de Smart Devices. Isto reduz significativamente a ligação ponto a

ponto entre os dispositivos.


2 SISTEMA DE AUTOMAÇÃO INDUSTRIAL

Os sistemas de automação industrial atualmente em operação caracterizam-se por um

grande número de dispositivos sensores e atuadores interligados. Estes dispositivos oferecem

informações sobre o estado do sistema e permitem aos controladores atuarem para modificar

o estado do mesmo. A natureza deste tipo de sistema tende a impor requisitos temporais para

tomadas de decisões e de reação a determinados eventos. Desta forma, os sistemas de

automação encontram-se inseridos no contexto dos sistemas distribuídos de tempo real.

A evolução da indústria da microeletrônica fez com que componentes de alto

desempenho, como microcontroladores, microprocessadores, memórias, sensores e

atuadores, tivessem seu custo reduzido a patamares suficientemente baixos para incentivar o

desenvolvimento de dispositivos autônomos. Neste sentido pode-se idealizar sistemas onde,

ao invés de grandes controladores coordenando dezenas ou centenas de dispositivos de I/O,

tem-se dispositivos de I/O com capacidade de controlar e coordenar operações de forma

sincronizada entre eles.

Este enfoque favorece a ampliação e manutenção das aplicações, além de favorecer a

implementação de aplicações com processamento paralelo (desempenho) e/ou redundante

(tolerância a falhas). Mas ele também obriga a definição de garantias de sincronização,

segurança e integridade das informações disponíveis por todos os elementos distribuídos, o

que aumenta a complexidade da aplicação.

Os componentes desses sistemas podem ser das mais diferentes plataformas de

software/hardware. Em um mesmo sistema, pode-se ter, por exemplo, PCs,

sensores/atuadores microcontrolados, ou qualquer outro tipo de componente.

Os PCs podem ter diferentes sistemas operacionais, como Linux, Windows, Unix,

etc., e os microcontroladores podem ser gerenciados por aplicações distintas. Desta forma, os

sistemas de automação podem ser reclassificados como sistemas heterogêneos distribuídos


de tempo real. Neste contexto, um aspecto deve ser comum em todos os componentes do

sistema, o protocolo de comunicação

2.1 A comunicação em sistemas distribuídos

No ambiente industrial normalmente os elementos distribuídos de uma aplicação

podem estar alguns quilômetros distantes entre si, sofrendo muitas interferências

eletromagnéticas geradas por motores, sistemas de solda, etc. Estas características obrigam

que o meio de comunicação seja serial, por causa da distância, digital, por causa das

interferências e de alta velocidade, por causa do grande número de mensagens que circulam

pelo meio de comunicação. Além disso, a topologia para a interligação dos dispositivos é o

barramento, pois qualquer outro modelo se torna inviável pelo gigantesco número de

ligações e conseqüente cabeamento que deve ser implementado.

2.1.2 Modelo cliente-servidor:

Neste modelo, o transmissor estabelece uma conexão com o receptor, conhecida

como "canal de bits" e inicia a transmissão. Não há nenhum problema aparente com este

modelo, mas acontece um overhead (utiliza toda a largura de banda) considerável, já que

existe um acúmulo excessivo de bits em cada quadro de dados transmitido porque cada

camada do modelo OSI acrescenta um cabeçalho ao quadro. É por esta razão que a maioria

dos sistemas de automação não usa todas as camadas definidas pelo modelo de referência

OSI/ISO (Open System Interconnection /International Standard Organization) e sim somente

um subconjunto das mesmas.


2.1.3 Modelo Multicast

O modelo anterior parte do princípio de que para que haja a comunicação deve existir

um transmissor e um receptor. Acontece que, em determinadas circunstâncias, a

comunicação envolve muito mais do que dois elementos. Um sistema de automação é um

exemplo típico: podem existir dezenas (até centenas) de sensores microcontrolados

espalhados por uma fábrica, e se deseja enviar a mesma informação a todos eles. Pelo

modelo cliente-servidor, seria necessário enviar a mesma mensagem para cada sensor.

Demoraria muito mais para que todos recebessem e, é claro, não haveria jeito de que todos

processassem a informação ao mesmo tempo.

O mesmo não acontece no modelo multicast, ou comunicação grupal, onde pode-se

enviar uma mesma mensagem a vários componentes de uma rede com garantia de que todos

processarão a mesma mensagem, dando um maior controle sobre o tempo-real e utilizando

de uma forma mais otimizada o barramento, já que em um sistema de automação há grandes

chances de haverem diversos componentes similares, que necessitem receber as mesmas

mensagens ao mesmo tempo. Para implementar este tipo de comunicação é preciso haver um

mecanismo de filtragem de mensagens, ao nível de hardware, como ocorre no protocolo

CAN, estudado neste trabalho. É preciso, portanto, escolher o modelo de comunicação que

melhor adapte ao sistema em projeto. Em sistemas que necessitem de comunicação do tipo,

um para muitos, ou mesmo de tempo-real, o modelo de comunicação grupal é mais

recomendado. Ao contrário, em sistemas que trabalhem no sistema ponto-a-ponto, isto é, a

comunicação se dá entre um transmissor e um receptor, o modelo cliente-servidor é melhor.


2.2 Divisão em camadas

No modelo de distribuição dos sistemas automatizados, cada elemento é autônomo,

ou seja, possui seu conjunto próprio de recursos, distribuindo apenas os resultados da

utilização destes recursos. Sendo assim toda a comunicação ocorrerá pela troca e

sincronização de mensagens.

Apesar disto parecer relativamente simples, é necessário que os participantes da troca

de mensagens (emissor, receptor) concordem quanto ao significado dos bits enviados de um

a outro. Existe a necessidade de que ambos concordem em diversos níveis, isto é, desde os

bits de mais baixo nível, como detalhes da transmissão dos bits, até os de mais alto nível,

como aqueles que tratam de como a informação deve ser expressa.

Para que se possa fazer o tratamento adequado em cada camada, a ISO (International

Standard Organization) criou o modelo OSI (Open System Interconnection), um modelo de

referência que identifica claramente os níveis envolvidos em um processo de comunicação,

apontando quais os tipos de trabalhos que devem ser realizados por cada um dos níveis. Cabe

salientar ainda que existem dois tipos genéricos de protocolos: os orientados à conexão, em

que antes da transmissão transmissor e receptor estabelecem uma conexão explícita, e os sem

conexão, em que não há necessidade de procedimentos anteriores à troca de mensagens.


Tabela 1 modelo ISO/OSI

7 Aplicação

6 Apresentação

5 Sessão

4 Transporte

3 Rede

2 Enlace

1 Física

• Camada 1 - Física

A camada 1 é responsável pela codificação/decodificação de símbolos e caracteres

em sinais elétricos lançados no meio físico, que fica logo abaixo dessa camada. O

nível físico tem a função de transmitir uma seqüência de bits através de um canal de

comunicação. As funções típicas dos protocolos deste nível são fazer com que um bit

"1" transmitido por uma estação seja entendido pelo receptor como bit "1" e não

como bit "0". Assim, este nível trabalha basicamente com as características

mecânicas e elétricas do meio físico, como por exemplo:

Número de volts que devem representar os níveis lógicos "1" e "0”.

• Camada 2 - Enlace De Dados

A camada 2 é responsável pela conexão confiável sobre um meio físico, recebendo e

transmitindo uma seqüência de bits do/para o nível físico e transformá-los em uma

linha que esteja livre de erros de transmissão, a fim de que essa informação seja

utilizada pelo nível de rede. Controla a taxa de transmissão dos quadros, evitando que
o sistema transmissor envie dados a uma taxa maior do que o receptor consegue

processar.

• Camada 3 - Rede

A camada 3 é responsável por tornar transparente para a camada de transporte a

forma como os recursos dos níveis inferiores são utilizados para implementar

conexões de rede. Deve também equalizar as diferenças entre as diversas sub-redes

utilizadas de forma a fornecer um serviço único a seus usuários (independente da rede

utilizada). Controla a operação da rede de um modo geral.

• Camada 5 – Sessão

A camada 5 é responsável por administrar e sincronizar diálogos entre dois processos

de aplicação. Neste nível ocorre a quebra de um pacote com o posicionamento de

uma marca lógica ao longo do diálogo. Esta marca tem como finalidade identificar os

blocos recebidos para que não ocorra uma recarga, quando ocorrer erros na

transmissão. Para se evitar, por exemplo, a perda de um volume de dados muito

grande que estão sendo transmitidos em uma rede não confiável, utiliza-se o conceito

de ponto de sincronização. O ponto de sincronização corresponde a marcas lógicas

posicionadas ao longo do diálogo. Toda vez que um usuário recebe um ponto de

sincronização deve enviar uma resposta, confirmando que este foi recebido. Caso a

transmissão, por algum motivo, seja interrompida, ela pode ser reiniciada a partir do

último ponto de sincronização confirmado;

• Camada 6 - Apresentação

A camada 6 é responsável por assegurar que a informação seja transmitida de tal

forma que possa ser entendida e usada pelo receptor. Ao contrário das camadas
inferiores, já não se preocupa com os dados ao nível de bits, mas sim com a sua

sintaxe, ou seja, sua representação. Nela é definida a sintaxe abstrata, ou seja, a forma

como os tipos e os valores dos dados são definidos, independentemente do sistema

computacional utilizado e a sintaxe de transferência, ou seja, a maneira como é

realizada esta codificação. Exemplificando: através da sintaxe abstrata define-se que

um caracter A deve ser transmitido. A sintaxe de transferência especifica como este

dado será codificado (por exemplo, em ASCII ou EBCDIC) ao ser entregue à camada

de sessão.

Resumindo, pode-se modificar a sintaxe da mensagem, desde que sua semântica seja

preservada. É responsável pela conversão de dados quando a transmissão é feita com

criptografia e a tradução de arquivos com formatos diferentes. Nesta camada, quando

é utilizada a criptografia, é realizada a proteção dos dados tanto no armazenamento

quanto no transporte de informações.

• Camada 7 - Aplicação

A camada 7 é responsável por fornecer ao usuário uma interface que permite acesso a

diversos serviços de aplicação, convertendo as diferenças entre diferentes fabricantes

para um denominador comum. Por exemplo, em uma transferência de arquivos entre

máquinas de diferentes fabricantes pode haver convenções de nomes diferentes (DOS

tem uma limitação de somente 8 caracteres para o nome de arquivo, UNIX não),

formas diferentes de representar as linhas, e assim por diante.


3 A TECNOLOGIA CAN

3.1 Introdução

A rede CAN [1] foi apresentada inicialmente pela BOSCH em 1986, como uma

aplicação para integração distribuída de diversos dispositivos microprocessados (nodos) nos

sistemas automotivos.

Por suas características determinísticas, ideais para aplicações de tempo real

distribuída e grande aceitação no mercado, torna-se também um padrão de redes normalizado

pela ISO11898 e pela SAE J1850 (Society of Automotive Engineers).

A rede CAN é também empregada na automação industrial através de variantes de

seu protocolo, tais como: DeviceNet [20], SDS, CANopen, etc. A rede CAN implementa um

mecanismo de acesso ao barramento baseado em prioridade sob mensagem com o protocolo

CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance). Uma estação tem

acesso ao barramento assim que o mesmo estiver ocioso.

O CAN é considerado um sistema de barramento serial com comunicação baseada em

eventos (event-triggered), ideal para ligar em rede subsistemas inteligentes, tais como

unidades microprocessadas, sensores e atuadores. As mensagens transmitidas pela rede

possuem tamanhos curtos. Assim, cada mensagem CAN (frame CAN) pode conter no

máximo 8 bytes de carga útil, sendo, no entanto possível transmitir blocos maiores de dados

recorrendo a segmentação em vários frames.

A taxa máxima de transmissão especificada é de 1 Mbit/s, correspondendo sistemas

com comprimento de barramento de até 40 m. Para distâncias superiores, a taxa de

transmissão recomendada diminui, alguns dos valores recomendados pela a CiA - CAN in

Automation são:
ƒ 500 Kbit/s para distâncias até 100 metros;

ƒ 250 Kbit/s para distâncias até 250 metros;

ƒ 125 Kbit/s para distâncias até 500 metros;

ƒ 50 Kbit/s para distâncias até 1 Km.

Outra característica importante é o fato do controlador CAN de cada estação, registrar os

erros, avaliando-os estatisticamente, e realizando ações a eles relacionados. Estas ações

podem corresponder ao desligar ou não a estação que provoca erros, tornando este protocolo

eficaz em ambientes ruidosos.

A ISO (International Standard Organization) e a SAE (Society of Automotive

Engineers) aprovaram o CAN como protocolo padrão que se divide em duas categorias,

sendo a diferença na camada física, onde a ISO 11898 suporta aplicações com velocidades

até 1Mbit/s e a ISO 11519 que tem um limite superior de 125Kbit/s. Assim, o protocolo

CAN implementa apenas as duas camadas inferiores do modelo de referência OSI (Open

Systems Interconnection). O grande interesse pelo CAN por parte da engenharia de

automação industrial foi devido a diversas características marcantes, que são as seguintes:

ƒ Protocolo padrão ISO;

ƒ Considerável imunidade a ruído;

ƒ Capacidade de detectar e sinalizar erros;

ƒ Reduzido tempo de latência;

ƒ Capacidade multi-mestre;

ƒ Capacidade multicast;

ƒ Flexibilidade de configuração;

ƒ Retransmissão automática de mensagens “em espera” logo que o barramento esteja

livre;

ƒ Atribuição de prioridade às mensagens;


ƒ Distinção entre erros temporários e erros permanentes dos nodos;

ƒ Baixo custo.

3.2. Área de aplicação

3.2.1 Em automóveis

Obedecendo às duas áreas de aplicação em automóveis (corpo e sistemas eletrônicos)

uma rede CAN [1] pode ser utilizada na interligação de:

ƒ dispositivos de rede no chassi controlando, por exemplo, lâmpadas, ar condicionado,

trava de portas e regulação elétrica do assento e do espelho retrovisor. Os valores

típicos da taxa de transmissão para estes dispositivos gira em torno de 50Kbits/s.

ƒ dispositivos de controle situados no motor permitem obter um melhor rendimento,

controle de freios e suspensão.

A Figura 1 apresenta a utilização da rede CAN em automóveis (esta imagem é

ilustrativa).

Figura 1 Aplicação de uma rede CAN em automóveis

Fonte: www.audi.com
3.2.2 Em indústrias

Os requisitos de um sistema em rede em automóvel e os requisitos necessários a

qualquer rede de sensores/atuadores de aplicação industrial são os mesmos, tais como: o

baixo custo de instalação e manutenção, a capacidade de operar em condições e ambientes

adversos, as necessidades de comunicação de tempo real e a facilidade de utilização.

Não foram somente os fabricantes de automóveis e máquinas agrícolas que

escolheram o CAN, essa foi também a escolha dos fabricantes de aparelhos médicos, de

máquinas têxteis, controle de elevadores e controle de processos, entre outros.

A indústria têxtil foi uma das pioneiras do CAN [1], equipando a primeira fábrica em

1990. O primeiro tear era composto por um sistema de controle modular conectado através

de uma rede CAN em tempo real, entretanto, muitos fabricantes de maquinaria têxtil uniram-

se formando o CAN Textile Users Group, que por sua vez faz parte do grupo internacional

de fabricantes CAN in Automation.

Além da segurança e do bom desempenho do CAN, o baixo custo dos dispositivos de

ligação foram, sem dúvida, um argumento decisivo. Em aplicações onde o custo é um fator

crítico, é essencial que exista disponível no mercado uma grande variedade de chips. Mais

uma vez, o tamanho, a robustez e o fato de serem bastante compactos, foram elementos de

especial importância a favor do CAN.

3.2.3 Estrutura de camadas do CAN

O protocolo CAN é estruturado basicamente com as seguintes camadas apresentada

na Figura 2, comparando-o com o modelo OSI/ISO.


Figura 2 Camadas do protocolo CAN

A Camada de Enlace de Dados divide-se em Controle de Enlace Lógico (LLC - Logic Link

Control) que é responsável pelo controle de aceitação de mensagens que são recebidas, e

notificação de sobrecarga do nodo conectado à rede CAN, e Controle de Acesso ao Meio

(MAC - Medium Access Control) que é considerado o kernel1 do módulo CAN, tendo como

função principal o controle de acesso ao meio físico além de detecção/sinalização de erros e

reconhecimento de mensagens recebidas.

Finalmente, a Camada Física define o nível de sinal de transmissão e a representação

dos bits recebidos através do barramento, além de ser responsável pelo ajuste de tempo de bit

(Bit Timing) e sincronização entre os nodos que participam do processo de arbitragem.

1
Considerado o núcleo de sistema computacional, responsável por manter e oferecer condições básicas para a

operação de um sistema.
3.2.4 Padrões CAN

Existem duas versões do protocolo, CAN 1.0 e CAN 2.0. A versão 2.0 é

completamente compatível com a versão 1.0. e possui duas variantes, a 2.0A standard e a

2.0B extended (Figura 3). Tanto na versão 1.0 como na 2.0A o campo identificador possui 11

bits de comprimento, e na versão 2.0B pode ter tanto 11 bits quanto 29 bits.

Por forma a manter a compatibilidade com as versões anteriores, a versão 2.0B pode

ser tanto do tipo passivo como ativo. A versão 2.0B passiva ignora todas as frames do tipo

extended (com 29 bits de identificador). A versão ativa permite o envio e recepção de

qualquer frame extended e standard, existindo algumas regras de compatibilidade, que são as

seguintes:

ƒ Controladores CAN do tipo 2.0B ativo podem enviar e receber tanto frames com o

formato standard como com o formato extended.

ƒ Controladores CAN 2.0B passivos enviam e recebem frames standard, ignorando os

extended.

ƒ Controladores CAN 1.0 geram erros sempre que recebam um frame (mensagem) com

formato extended.

Figura 3 Padrões de frames CAN

SOF (1 bit) Start of Frame: Caracteriza o início de uma mensagem, e é utilizado para

sincronizar os nodos sob o barramento para uma transmissão.


Identificador (11 bits CAN 1.0 e 2.0A e 29 bits CAN 2.0B): Define a identificação e a

prioridade de uma mensagem. O menor valor binário possui a maior prioridade de

transmissão.

RTR (1 bit) Remote Transmission Request: indica uma requisição de transmissão remota.

SRR (1 bit) Substitute Remote Request: é transmitido no frame extend na posição do bit RTR

do frame standard.

IDE (1 bit) Identifier Extension: corresponde a uma extensão do identificador. Se nenhum

bit está sendo transmitido como valor lógico 0 (dominante), significa que não existe mais bit

identificadores a serem enviados.

R0 (1 bit): Bit reservado para utilização de variantes do CAN.

DLC (4 bits) Data Length Code: corresponde ao código de controle de dados. Contém o

número de bytes de dados a serem transmitidos.

Dados (64 bits): Contém os dados da mensagem da aplicação.

CRC (16 bits): Cyclic Redundancy Check contém a técnica de detecção e correção de erros

CRC. A distância de Hamming do código CRC utilizado é de 6, sendo possível detectar até 6

erros de bit simples.

ACK (2 bits) Acknowledge: o nodo que recebe uma mensagem correta subscreve este bit

recessivo na mensagem original com um bit dominante, indicando que recebeu uma

mensagem sem erros.

EOF (7 bits) End Of Frame: identifica o fim de um frame CAN e desabilita o bit stuffing,

indicando um erro de stuffing quando dominante. Quando 5 bits de mesmo valor lógico

ocorrem durante uma operação normal, um bit de nível lógico oposto é stuffed dentro do

campo de dados.
IFS (7 bits) Inter Frame Space: contém a quantidade de tempo requerido pelo controlador

CAN para mover um frame corretamente recebido para a posição própria em uma área de

armazenamento de mensagens.

3.2.5 Formato de frames

Na comunicação entre os nodos de uma rede CAN são transmitidos diferentes tipos

de frames, cada um com sua respectiva função. São quatro formatos de frames: frame de

dados, remoto, erro e sobrecarga.

O frame de dados apresentado na Figura 4 tem a função de transmissão de dados

(carga útil) entre os nodos da rede CAN. Em seu formato, contém os dados que são

transmitidos entre o emissor e receptor.

Figura 4 Frame de dados

Um nodo na rede que necessite de uma dada mensagem, o mesmo pode solicitá-la

através da transmissão de um frame remoto (Figura 5). O campo RTR que caracteriza um

frame remoto é ajustado para valor lógico 1. Como se trata de uma solicitação, não existe

carga útil para este frame.

Figura 5 Frame remoto


O frame de erro tem a função de notificar um erro no recebimento de um frame,

qualquer nodo na rede pode gerar esse frame. Este frame é formado por dois campos,

conforme apresentado na Figura 6.

Figura 6 Frame de erro

ƒ Flag de erro: este campo indica a existência do erro informando se é um erro passivo

ou ativo (esse assunto será tratado com detalhes na seção 3.2.7). Para erro ativo o flag

de erro conterá bits dominantes2 e para erro passivo conterá bits recessivos3.

ƒ Delimitador de erro: tem a função de ativar a comunicação no barramento CAN após

uma falha, sendo enviado pelo nodo que gerou o erro.

A função do frame de sobrecarga é similar ao frame de erro, sinalizando sobrecarga

em um nodo, impossibilitando-o de receber o frame de dados, tendo que o transmissor

aguardar o próximo processo de arbitragem.

O frame de sobrecarga tem o mesmo formato do frame de erro, tendo um campo flag

de sobrecarga e um delimitador. No campo flag de sobrecarga, seu valor será sempre bits

dominantes.

3.2.6 Verificação e sinalização de erros

ƒ Bit Stuffing: essa técnica é usada para detecção de erros nos frames transmitidos. A

após cada conjunto de 5 bits iguais é inserido um bit stuffing. Esta técnica é aplicada

2
Bit dominante é um bit de nível lógico 0.
3
Bit recessivo é um bit de nível lógico 1.
somente nos frames de dados e remotos: os campos CRC, ACK e EOF não passam

por essa técnica.

ƒ CRC: antes da transmissão de um frame, seu CRC é calculado (os valores de bits que

são colocados no campo CRC durante a transmissão da mensagem) e seu resultado

inserido no campo CRC. Na recepção deste frame, o cálculo é refeito e comparado

com o resultado no campo CRC do frame recebido. No caso de erro, um frame de

erro é transmitido imediatamente. O cálculo de CRC é usado nos frames de dados e

remotos e é calculado a partir do campo SOF até o último campo, EOF.

ƒ Reconhecimento: quando um nodo enviar uma mensagem sob a rede CAN, o mesmo

envia o campo ACK com bits recessivos. No receptor, o mesmo retornará esses bits

como dominantes. Quando o transmissor recebe ACK em dominante significa que a

mensagem foi recebida com sucesso.

ƒ Contadores de erro: o protocolo CAN define os contadores de erro TXECTR

(contador de erros de transmissão) e RXCTR (contador de erro de recepção). Estes

contadores definem os estados de erro de um determinado nodo, que podem ser um

erro ativo ou erro passivo.

ƒ Erro ativo: representa o estado normal de um nodo quando é iniciado. Neste estado o

nodo pode enviar flag de erro ativo.

ƒ Erro passivo: representa que o nodo está com erros freqüentes. Quando os

contadores TXECTR ou RXCTR ultrapassam 127 erros, o nodo passa do estado ativo

para o estado passivo. Nesta situação, flags de erro passivo são enviados. Isso garante

maior eficiência do barramento CAN, impedindo que nodos com erros freqüentes

possam sobrecarregar o barramento de comunicação.

ƒ Barramento Off: Um nodo que atinge 255 erros (no TXECTR) será desligado do

barramento e somente será iniciado através de um reset.


3.2.7 Limitação de erros

Para prevenir que uma ou um grupo de estações defeituosas perturbem a rede com

constantes interrupções de mensagens, a norma CAN prevê a retirada dessas estações da

rede, por iniciativa própria. Para realizar esse efeito utiliza um algoritmo complexo e que

possui por base dois contadores. Os conteúdos desses contadores definem os três estados em

que uma estação pode se encontrar.

• Error Active (erro ativo) - uma estação que esteja neste estado pode tomar parte das

comunicações da rede sem restrições. Uma vez detectada uma situação de erro, esta

tem a certeza que esse erro não é da sua responsabilidade. Os erros são assinalados

com uma mensagem de Error Flag ativa.

• Error Passive (erro passivo) - neste estado, os dispositivos podem comunicar mas

quando detectam a ocorrência de um erro suspeitam que a causa esteja neles. Desta

forma assinalam o erro com um Error Flag passiva. A Error Flag passiva é composta

por seis bits recessivos, portanto, o dispositivo só poderá interromper uma

transmissão se ele for transmissor ou é o único receptor.

• Bus Off (barramento desligado) - neste estado as estações acreditam que são a

causa do erro, isto é, que não são capazes de comunicar corretamente e são auto-

excluídas da rede. A transição entre os estados de Error Active e Error Passive é

efetuada automaticamente, dependendo dos conteúdos dos registros REC (Receive

Error Counter) e TEC (Transmit Error Counter). Uma estação que atinja o estado

Bus Off só será reiniciada através de um reset.


3.2.8 Processo de arbitragem

Em um sistema de tempo real distribuído, o instante da transferência de mensagens

pela rede pode causar diferenças significativas quanto à dinâmica do processo que esta sendo

controlado. Um processo que necessite de uma transferência periódica de uma determinada

grandeza (ex. carga do motor) deve ter maior importância com relação a uma grandeza que

varie em uma freqüência menor (ex. temperatura do motor).

Em uma rede CAN, a prioridade com que uma mensagem é transmitida,

relativamente à outra, é definida pelo seu campo identificador. A prioridade das mensagens é

definida durante a fase de projeto do sistema sob a forma de valores binários. Nesta definição

de prioridades é considerado que o identificador de menor valor binário detém maior

prioridade.

O protocolo CAN permite acesso simultâneo ao barramento por diferentes nodos. Se

mais de um nodo acessa o barramento, a arbitragem é requerida.

O método de acesso ao meio físico de comunicação usado no CAN é o CSMA/CA

(Carrier Sense Multiple Access with Collision Avoidance). Os conflitos no acesso à rede são

resolvidos através da arbitragem bit a bit dos identificadores das mensagens. Cada nodo

observa a rede utilizando o mecanismo bit-wise, em que o estado dominante (nível lógico 0)

sobrepõe o estado recessivo (nível lógico 1). A Figura 7 apresenta um processo de

arbitragem entre três nodos.


Figura 7 Processo de arbitragem

Se dois ou mais nodos iniciarem a transmissão ao mesmo tempo, quando o

barramento em estado ocioso, a colisão de mensagem é evitada com processo de arbitragem.

Todos os nodos perdedores tornam-se imediatamente receptores da mensagem com maior

prioridade, e não fazem mais nenhuma tentativa de retransmissão enquanto a rede não estiver

livre.

O CAN é uma rede com resolução de colisões não destrutiva, ou seja: os nodos

atrasam a transmissão se o barramento estiver ocupado, com a capacidade de não destruir a

mensagem a ser enviada.


4. DEVICENET

4.1 Introdução

A rede DeviceNet é baseada no protocolo CAN, desenvolvido pela Bosh nos anos 80

originalmente para aplicação automobilística, posteriormente adaptada ao uso industrial

devido ao excelente desempenho alcançado, pois, em um automóvel temos todas

características críticas que se encontram em uma indústria. Estes atributos fazem da rede

CAN uma tecnologia bem ajustada também para o mercado de automação industrial. Uma

variedade de chips CAN está disponível de fornecedores do mundo todo.

A rede DeviceNet é muito versátil, sendo utilizado em milhares de produtos

fornecidos por vários fabricantes, desde sensores inteligentes até interfaces homem-máquina.

A rede pode suportar vários tipos de mensagens, fazendo com que a rede trabalhe da maneira

mais inteligente.

A rede DeviceNet é uma rede de baixo nível baseada no protocolo CAN, que permite

equipamentos desde os mais simples como: módulos de I/O, sensores e atuadores, até os

mais complexos como: Controladores Lógicos Programáveis, e microcomputadores.

A rede DeviceNet é um rede digital multi-drop, que conecta e serve como uma rede

de comunicação entre os controladores industriais e dispositivos I/O. DeviceNet é uma rede

produtor-consumidor que suporta múltiplas hierarquias de comunicação e priorização de

mensagem. Sistemas DeviceNet podem ser configurados para operar em uma arquitetura

mestre-escravo ou em uma arquitetura de controle distribuída que usa comunicação peer-to-

peer.
DeviceNet também tem a característica única de ter alimentação de força na rede. Isto

permite que dispositivos com limitadas exigências de alimentação sejam alimentados

diretamente da rede, reduzindo pontos de conexão e tamanho físico.

Simplificando a conexão de dispositivos pela aplicação da rede DeviceNet podemos

diminuir o custo total do sistema, o tempo e o dinheiro investido na instalação, startup, teste,

manutenção, e expansão do sistema.

4.2 A arquitetura DeviceNet

A rede DeviceNet especifica uma configuração com tronco, terminações e linhas

secundárias. A Comunicação e alimentação são disponibilizadas no cabo tronco e nas linhas

secundárias. Como resultado, dispositivos podem ser alimentados diretamente do

barramento, como também pode ser feita a comunicação entre dispositivos usando o mesmo

cabo. Para dispositivos auto-alimentados um isolamento ótico é disponível.

Redes DeviceNet seguem o modelo Open Systems Interconnection (OSI), um padrão

da ISO (International Standards Organization) para redes de comunicações que são de

natureza hierárquicas. Redes que seguem este modelo definem todas as funções necessárias

da implementação física até o protocolo e metodologia para comunicar dados de controle e

de informação dentro e através de redes.

4.2.1 A Camada física

Os cabos de alimentação estão contidos na própria rede. Este projeto permite que

dispositivos sejam alimentados pela rede (por exemplo, sensor pequeno) e dispositivos

alimentados externamente (por exemplo, drives de AC). São definidos conectores selados e

de estilo aberto para acomodar dispositivos selados, como um sensor de proximidade. Os

dispositivos abertos são normalmente montados em uma caixa ou painel.


O cabeamento da DeviceNet utiliza uma topologia de linha tronco/ linha secundária.

A linha tronco da rede DeviceNet pode ser implementada com o cabo grosso com seu

comprimento máximo limitado em função da taxa de comunicação.

DeviceNet suporta projetos de dispositivos de camada física isolado e não-isolado.

Uma opção de projeto opto-isolado permite dispositivos alimentados externamente (por

exemplo: drives de partida AC e válvulas de solenóide) compartilhar o mesmo cabo de

barramento.

Podem ser usados vários tipos de conectores para interligação dos dispositivos de

uma rede DeviceNet. O mercado dispõe de vários tipos de conectores. Conectores selados

com tamanhos de plugs grande (míni-style) e pequeno (micro-style), estão disponíveis. Para

produtos que não requerem conectores selados, podem ser usados conectores de estilo aberto

(open-style).

As derivações da rede devem ser instaladas com cabo fino (menor diâmetro) e sua

limitação é de 6m por lance independente de sua taxa de transmissão. A figura 8 a seguir é

um exemplo de uma instalação demonstrando a aplicação da rede DeviceNet para uma taxa

de velocidade em 125 Kbits/s (normalmente utilizado) e de acordo com o manual da sense

(ver seção 4.4.3, tabela 2) o limite do cabo grosso é de até 500m.


Figura 8 instalação da rede DeviceNet para 125 Kbits/s

Conforme observado na figura 8, o comprimento do cabo grosso deve seguir as

especificações de instalação, não excedendo um comprimento maior que 500m. O

comprimento máximo para as derivações é de 6m independentemente da taxa de

comunicação selecionada para rede.

4.2.2 A camada link de dados

A camada de link de dados da DeviceNet está definida pela especificação CAN e pela

implementação de chips de controlador CAN. A especificação CAN define dois estados de

barramento chamados, dominante (lógica 0) e recessivo (lógica 1). Qualquer transmissor

CAN leva o barramento para um estado dominante. O barramento só pode estar no estado

recessivo quando nenhum transmissor estiver em estado dominante. Este fato faz com que

entre em jogo o esquema de arbitragem de barramento empregado por CAN.

Qualquer nó pode tentar transmitir uma mensagem quando nenhum outro nó estiver

transmitindo. Esta característica provê inerente capacidade peer-to-peer. Se dois ou mais nós
CAN tentam ter acesso à rede simultaneamente, um mecanismo não destrutivo de arbitragem

bit-wise soluciona o conflito potencial sem perda de dados ou largura de banda. Por

comparação, a Ethernet utiliza detecção de colisão, que resulta em perda de dados e largura

de banda, uma vez que os dois nós tem que recuar e reenviar seus dados. Os dados são

movidos em DeviceNet utilizando o frame de dados.

Os bits identificador e o RTR (pedido de transmissão remoto - não usado por

DeviceNet) formam juntos o campo de arbitragem. O campo de arbitragem é usado para

facilitar acesso prioritário ao meio. Quando um dispositivo transmite, ele também monitora

(recebe) cada bit enviado, para ter certeza que é o mesmo. Isto permite descoberta de

transmissão simultânea. Se um nó transmitindo um bit recessivo recebe um bit dominante

enquanto enviando, ele deixa de transmitir devido ao campo de arbitragem.

O campo de CRC (cheque de redundância cíclica) é usado por controladores CAN

para descobrir erros de frame. A rede CAN provê uma conferência de erros muito robusta

que emprega vários tipos de detecção de erro. Estes métodos, os quais, são em sua maioria

transparentes a aplicação, evitam que um nó defeituoso possa romper a rede.

4.3 Serviços de controle

CIP (Common Industrial Protocol) [15] é um protocolo baseado em conexão que

logicamente une objetos em uma rede. Troca de dados em conexões podem ser unidirecional,

bidirecional ou multicast. Quando uma conexão de I/O for estabelecida, os dispositivos

concordam nos dados a serem trocados, o time-out entre eles é o mecanismo que dispara a

troca.

Com controle de mensagem I/O (input/output), notificação imediata e precisa de erros

são essenciais para proteger os empregados e equipamentos caros. CIP permite a todos os

lados da conexão manter um cronômetro configurável baseado nas taxas de pacote esperadas,
assim eles podem determinar depressa quando a comunicação estiver perdida. Se um time-

out acontecer, ações de falta são tomadas e o device(s) vai para um estado predeterminado

(baseado em uma configuração de usuário).

CIP também provê indicação run-idle. Indicação run-idle envia conexões para um

estado "inativo" quando o usuário puser o controlador, por exemplo, em modo de programa.

Isto é importante porque quando um dos pontos finais de uma conexão estiver inativo, os

outros passam a ficar atentos de que os dados estão produzindo (ou consumindo) podem não

estar sendo atualizado ativamente (ou aplicado). Dispositivos podem executar então

localmente a ação inativa neles pré-configurada.

CIP foi projetado tendo em mente o roteamento. Provê um método de roteamento

comum de forma que você pode transmitir facilmente em rede informação de EtherNet/IP

para ControlNet para DeviceNet, ou qualquer combinação destas.

É possível usar uma gateway (dispositivo para interconecção de redes) para conectar

redes com camadas de aplicação não similares, no entanto, são mais caras, requerem

configuração e programação significantes e geralmente reduzem os dados disponíveis para os

níveis superiores. Uma vez que o roteamento CIP foi projetado para trabalhar junto com o

roteamento do protocolo de Internet (IP), você pode usar browse de qualquer lugar da

Internet através de um protocolo CIP. Como resultado, você pode ver até o menor sensor em

DeviceNet e pode ver seus diagnósticos ou pode mudar sua configuração (claro que

assumindo acesso de segurança apropriado).


4.4 Qualidade do projeto da rede DeviceNet

4.4.1 Introdução

O ponto de maior importância para o perfeito funcionamento de uma rede DeviceNet

é a qualidade de instalação [16] [17] [18], seguindo critérios e procedimentos definidos pelo

fabricante e garantindo com isto a operação da rede de forma estável e constante.

A instalação de redes sem um pré-projeto, leva a frustrantes resultados operacionais e

muitas vezes de difícil correção, pois normalmente os fundamentos básicos não foram

observados.

Toda a funcionalidade futura da rede DeviceNet começa com um projeto prévio e

detalhado mostrando todos os instrumentos pertencentes à rede com o seu respectivo modelo,

tageamento, localização física bem como entrada e saída do cabo de rede e suas derivações.

4.4.2 Endereçamento do instrumento na rede DeviceNet

O endereçamento (endereço dos equipamentos na rede) dos equipamentos pode ser

feito por hardware ou software [18], sendo que o endereço default para os equipamentos

novos é 63.

O endereçamento via hardware normalmente utiliza duas chaves rotativas que

diretamente indicam o endereço do equipamento ou podem utilizar chaves dipswitch que

utiliza o endereçamento binário. A dipswitch (conjunto de chaves) de endereçamento requer

seis chaves para gerar os 63 endereços disponíveis, e mais duas para a taxa de velocidade de

comunicação.
A indicação do endereçamento no projeto da rede é muito importante, para facilitar a

troca caso algum equipamento necessite de manutenção. O endereçamento errado do módulo

na rede DeviceNet irá causar falha no scanner.

Em equipamentos que utilizam dipswitches (conjunto de chaves) para o

endereçamento de nós é recomendável ter em mãos a tabela de endereçamento que

demonstra todas as possíveis combinações para os endereços DeviceNet utilizando as chaves

dipswitches (S1 a S6) e (S7 e S8) para a taxa de velocidade. É também recomendável que

seja descrito no próprio módulo o nó referente ao endereço DeviceNet para facilitar sua troca

(se possível também as posições das dipswitches configuradas em “ON” e “OFF”). A

dipswitch de endereçamento requer seis chaves para gerar os 63 endereços disponíveis, e

mais duas para a taxa de velocidade de comunicação, conforme ilustra a figura 9:

Figura 9 configuração da Dip Switch

4.4.3 Comprimento dos cabos

O comprimento dos cabos da rede DeviceNet devem estar descritos no fluxograma da

rede, pois com esta informação podemos determinar a queda de tensão dos instrumentos

observando os limites do comprimento de acordo com o tipo do cabo.


Os cabos para redes DeviceNet possuem dois pares de fios, um para alimentação

24Vcc e outro para a comunicação digital. São normalizados e possuem especificações

rígidas que garantem o funcionamento da rede nos comprimentos pré-estabelecidos.

A tabela 2 apresenta o comprimento máximo dos cabos em função da taxa de

comunicação adotada para a rede.

Tabela 2 distâncias variáveis da rede de início a fim com a taxa de transmissão

Taxa de Transmição

Tipo de Cabo Função do Cabo 125Kbits/s 250Kbits/s 500Kbits/s

Cabo Grosso Tronco 500m 250m 100m

Cabo Fino Tronco 100m

Cabo Flat Tronco 380m 200m 75m

Cabo Fino Derivação

Cabo Fino Σ derivações 156m 78m 39m

O limite nos comprimentos dos cabos, foram tecnicamente determinados e

normalizados e devem ser rigorosamente respeitados, para que haja garantia do

funcionamento adequado da rede. Se os limites forem extrapolados, a rede pode inicialmente

funcionar, porém, intermitentemente ocorrerão problemas de comunicação devido a as

instabilidades que ocorrem durante transmissão. Desta forma devemos tomar o máximo

cuidado desde o projeto até a instalação.

4.4.4 Taxa de comunicação

A taxa de comunicação é a velocidade com que os dados são transmitidos no

barramento da rede, e quanto maior a velocidade menor é o tempo de varredura da rede, mas,
em contra partida, menor é o comprimento máximo dos cabos. Na grande maioria das

aplicações, a velocidade ideal é de 125 kbit/s, pois gera a melhor relação custo/benefício,

porque permite o maior comprimento de cabo possível.

Em uma mesma rede DeviceNet, todos os equipamentos devem estar configurados

para a mesma taxa de comunicação, caso contrário se houver algum equipamento

configurado em outra taxa de comunicação provavelmente irá interromper o funcionamento

de toda a rede.

4.4.5 Resistores de terminação

Nos extremos da rede deve-se instalar um resistor de terminação, que possui o

objetivo de reduzir possíveis reflexões do sinal na rede, que causa distúrbios na

comunicação, com constantes e aleatórias paradas e eventualmente interrupção total do seu

funcionamento. O resistor de terminação deve ser de 121Ω, mas admite-se o valor comercial

mais comum de 120 Ω e sendo a potência dissipada mínima, um resistor de 1/4W estaria

adequado.

Para verificar a conexão do resistor, desconectar a alimentação e medir a resistência

através das linhas CANH e CANL (fios azuis e brancos, respectivamente) que deve ser

aproximadamente 60Ω, valor das duas resistências de terminação de 120Ω em paralelo.

Os resistores devem ser conectados entre os fios de comunicação (BR branco e AZ

azul), nos dois extremos da rede, ou nas duas caixas de distribuição nos extremos da rede,

conforme mostrado na figura 10.


Figura 10 localização dos resistores de terminação

4.4.6 Posicionamento da fonte

Quanto maior for o comprimento dos cabos maior será a queda de tensão. Uma

maneira simples de diminuir significativamente a queda de tensão é a mudança de local da

fonte de alimentação externa. O ponto ideal para a colocação da fonte de alimentação na rede

é o mais próximo possível do centro de carga, ou seja, no trecho da rede que mais consome.

Normalmente não se deve instalar a fonte junto ao PLC, pois geralmente está localizado

longe do primeiro equipamento de campo.

4.4.7 Cálculo das correntes

A corrente nos trechos dos cabos é determinada, baseando-se na corrente de consumo

dos equipamentos e pela lei de Kirchoff (A somatória das correntes que chegam em um nó é

igual a somatória das correntes que saem do mesmo). Na figura 11 representaremos as

correntes de cada ponto.


Figura 11 corrente de consumo dos equipamentos

No ponto H temos a soma das correntes consumidas pelos equipamentos J e I. A

corrente que sai ao ponto F vinda da fonte de alimentação, alimentará os equipamentos G, H

e I resultando em 1,5A. Acrescenta-se ao anterior o consumo do equipamento E. Através do

ponto B passa a corrente somente dos equipamentos A e C com total de 1A. No ponto A,

circula somente 0,5A e o trecho até o PLC, que são somente alguns mA, que são desprezíveis

para os nossos cálculos. A tabela 3 apresenta a fórmula para cálculo da queda de tensão no

cabo, considerando a resistividade específica de cada modelo.

Tabela 3 fórmula para cálculo da queda de tensão no cabo

Tipo do Resistividade Fórmula da


Cabo Do Cabo Queda de Tensão
Cabo Grosso 0,015 Ω/m U = 0,015 L x I (V)

Cabo Fino 0,069 Ω/m U = 0,069 L x I (V)

Cabo Flat 0,019 Ω/m U = 0,019 L x I (V)


4.4.8 Cálculo da tensão nos equipamentos

Imprescindível na implementação de uma rede DeviceNet é a avaliação da queda de

tensão ao longo da linha, que é ocasionada pela resistência ohmica do cabo submetida a

corrente de consumo dos equipamentos alimentados pela rede.

Quanto maior o comprimento da rede, maior o número de equipamentos e mais

elevado o consumo dos instrumentos de campo, mais elevadas serão as quedas de tensões,

podendo inclusive não alimentar adequadamente os dispositivos mais distantes. Outro ponto

a considerar é o posicionamento da fonte de alimentação na rede, que quanto mais longe do

centro de carga maior será a queda de tensão. Segundo as especificações da rede DeviceNet

admiti-se uma queda de tensão máxima de 4,65V, ou seja, nenhum elemento ativo deve

receber uma tensão menor do 19,35V entre os fios VM (vermelho) e PR (preto).

Lembramos, no entanto, de que na prática a restrição é maior ainda, pois normalmente as

cargas ligadas aos módulos de saída on/off normalmente admitem uma variação de 10%, ou

seja, não poderiam receber tensão menor do que 21,6V.

Utilizando as fórmulas de queda de tensão vista na tabela 4, podemos calcular as

tensões em cada ponto da nossa rede, utilizando o modelo da figura 11.

Observando a figura 11 vemos que na entrada da fonte de alimentação, temos uma

tensão de 24V. Através da equação 5 calculamos a tensão no dispositivo E.

Considerando o trecho DF de comprimento desprezível teremos uma tensão igual a

do ponto E. No trecho final com 95m e corrente de 1A, temos uma tensão de 22,58V

conforme mostrado na equação abaixo.


No trecho onde nós temos 1A dos Equipamentos I e J sob o cabo fino de 2m, teremos

uma tensão de 22,44V, coforme mostrado na equação 7

No equipamento J no trecho de cabo fino de 2m, teremos uma tensão de 22,30V

conforme equação 8.

No trecho B calculamos a tensão utilizando a equação 9 abaixo.

No equipamento C no cabo fino de 6m teremos uma queda de somente 0,5A, assim

podemos calcular a tensão no dispositivo C, conforme a equação 10.

No trecho A teremos uma tensão de 23,74V conforme mostrado na equação 11.


4.4.9 Aterramento

A rede DeviceNet deverá ser aterrada em um único ponto, preferencialmente onde

entra a alimentação da rede, e neste ponto deve ser ligado o fio shield (proteção) no negativo

da fonte, caso haja mais de uma fonte, esta ligação deve ser feita somente no ponto de

aterramento. O ideal é que se tenha um terra exclusivo para instrumentação, caso o mesmo

não esteja disponível utilize o terra comum.

Figura 12 Aterramento da rede DeviceNet

Quando a rede DeviceNet utiliza duas ou mais fontes, somente uma delas deve estar

com o negativo aterrado em uma haste junto com o fio de dreno da rede.

Toda vez que houver manobras no cabo da rede ou manutenção nos instrumentos

deve ser desligada a conexão do dreno com o negativo da fonte para verificar se a isolação

do fio dreno não está aterrada em qualquer outro ponto da rede, pois as manobras nos cabos,

muitas vezes podem romper a isolação deste conectando-o a malha, a eletrodutos, ou a calhas

aterradas.
Figura 13 Aterramento com duas fontes na rede DeviceNet

O cabo DeviceNet possui uma blindagem externa em forma de malha, que deve ser

sempre cortada e isolada com fita isolante ou tubo plástico isolador em todas as extremidades

em que o cabo for cortado. Devemos tomar este cuidado na entrada de cabos de todos os

equipamentos, principalmente em invólucros metálicos, pois a malha externa do cabo não

deve estar ligada a nenhum ponto e nem se encostar a superfícies aterradas.

Existe ainda um fio de dreno no cabo DeviceNet , que eletricamente está interligado a

malha externa do cabo, e tem como função básica permitir a conexão da malha a bornes

terminais. Inclusive todos os equipamentos DeviceNet possuem um borne para conexão do

fio de dreno, que internamente não está conectado a nenhuma parte do circuito eletrônico, e

normalmente forma uma blindagem em volta do circuito através de pistas da placa de

circuito impresso.

Da mesma forma que a blindagem externa, aconselha-se isolar o fio de dreno em

todas as suas extremidades com tubos plásticos isoladores, a fim de evitar seu contato com

partes metálicas aterradas nos instrumentos.


5 CANOpen

5.1 Introdução

O protocolo CANOpen utiliza-se de perfis de dispositivos padronizados que definem

a funcionalidade básica dos dispositivos ao mesmo tempo que permitem a implementação

pelo fabricante de características específicas. Ela foi desenvolvida como uma rede

embarcada padronizada com capacidade de configuração altamente flexível. Foi projetada

para redes de controle de máquina orientadas por sinal, tal como sistemas manuais. Agora ela

é usada em campos variados como equipamentos médicos, veículos off-rood, eletrônica

marítima, transporte público, automação de edifícios, etc.

CANOpen [9] foi pré-desenvolvida em um projeto sob a presidência da Bosh. Em

1995, a especificação da rede CANOpen foi passada para CAN in Automation (Cia), grupo

internacional de usuários e fabricantes. Originalmente, o perfil de comunicação CANOpen

era baseado no protocolo da camada de aplicação CAN. A versão 4 de CANOpen (Cia DS

301) está padronizada como EN50325-4. A especificação CANOpen abrange camada de

aplicação e perfil de comunicação (Cia DS 301), assim como a estrutura para equipamentos

programáveis (Cia 302), recomendações para cabos e conectores (Cia 303-1) e

representações de prefixos e unidades SI (Cia 303-2). A camada de aplicação assim como os

perfis baseados em CAN são implementados em software.

Perfis padronizados (para equipamentos, interface e aplicação) desenvolvidos pela

CIA simplificam o trabalho de projeto do sistema de integrar o sistema de redes CANOpen.

Equipamentos, ferramentas e pilhas de protocolo estão largamente disponíveis a preços

razoáveis. Para projetistas de sistemas é muito importante reusar software de aplicação. Isto

requer não somente compatibilidade de comunicação mas, também interoperabilidade e


interconectividade dos equipamentos nos perfis de equipamentos e interface CANOpen. A

rede CANOpen é flexível e aberta o bastante para possibilitar funcionalidades específicas do

fabricante que podem ser adicionadas à funcionalidade genérica do equipamento descrita nos

perfis.

5.2 Modelo de comunicações

A norma CAN é extremamente flexível em termos de mecanismos de comunicação.

Essa flexibilidade é traduzida na especificação CANopen através de vários tipos de ligações

lógicas entre dois ou mais dispositivos de rede. A camada de aplicação do CANopen permite

a ligação estabelecimento do tipo Mestre-Escravo, Cliente-Servidor e Produtor-Consumidor.

5.2.1 Mestre-Escravo (Master-Slave)

A qualquer instante na rede um dispositivo pode funcionar como mestre para

determinada função, coordenando todos os outros elementos da rede, os escravos.

Os serviços que realizam este tipo de ligação lógica estão relacionados com aspectos

específicos da gestão da rede.

5.2.2 Cliente – Servidor (Client – Server)

A ligação do tipo cliente-servidor envolve apenas dois elementos da rede. Neste tipo

de ligação, o cliente acede ao servidor através de operações de escrita e leitura. Os serviços

realizados com este tipo de ligação lógica estão relacionados com a configuração de

dispositivos antes do arranque da aplicação de rede (objetos de dados de serviço).


5.2.3 Produtor – Consumidor (Producter – Consumer)

Na ligação produtor-consumidor é realizada a verdadeira potencialidade de difusão de

mensagens apresentada pela rede CAN. O produtor da informação coloca-a na rede e um ou

mais elementos consumidores recebem-na. Os serviços realizados com este tipo de ligação

lógica estão relacionados com a troca de informação em tempo real (objetos de dados do

processo - PDO). Estes serviços podem ser confirmados ou não confirmados.

5.3 Modelo do dispositivo CANopen

Os dispositivos CANOpen apresentam uma estrutura orientada por objetos. Cada

dispositivo é definido por conjunto de objetos que podem ser concordados através da rede.

Qualquer informação sobre o modo de operação, está alojado num ou mais objetos, desta

forma é possível alterar a configuração e o seu estado interno de um lugar remoto, utilizando

apenas os protocolos de rede.

Como podemos observar na figura 14, na estrutura de um dispositivo CANopen

existem duas categorias de objetos:

Objetos de comunicação – cada um, destes objetos, representam uma função de

comunicação específica no dispositivo. Estes objetos são definidos pelo perfil de

comunicações CANopen (DSP 301);

Objetos da aplicação – estes objetos representam a descrição funcional da aplicação

de processo no dispositivo (ex. estado de uma entrada digital). Estes objetos são definidos

pelos perfis de dispositivos (DSP 401, DSP402, DSP 406).

Todos os objetos do dispositivo estão representados no dicionário de objetos e é

através deste que os objetos podem ser acedidos. O dicionário de objetos constitui o núcleo
CANopen que funciona como um mapa da sua estrutura interna. Como se pode observar na

Figura 14, o dicionário fornece a interface entre as comunicações e a aplicação de processo.

Figura 14 Estrutura de dispositivos CANopen

• Interface de comunicação

Fornece os serviços para transmitir e receber os objetos.

• Dicionário de objetos

Descreve os tipos de dados, objetos de comunicação e objetos de aplicação;

Oferece a interface para a interface de aplicação.

• Interface de aplicação

Funcionalidade interna de controle;

Interface com o hardware.

5.3.1 Estrutura do dicionário de objetos

O dicionário de objetos representa e confere de forma padronizada a discrição

funcional através de perfis de dispositivo. As funções de rede e as de processo são definidas

através dos objetos que compõem o dicionário.


O acesso aos objetos é realizado através de um endereço lógico constituído por um

índice e por um sub índice. O índice representa uma entrada (objeto) no dicionário e o sub-

índice apresenta várias funções, dependendo do tipo de objeto. Cada entrada no dicionário

suporta um máximo de 254 elementos. No dicionário existem entradas que são obrigatórias

para que seja assegurado o funcionamento mínimo para possibilitar a interligação de

dispositivos de várias complexidades. As restantes são opcionais e concedem a liberdade de

adaptar o funcionamento do dispositivo às necessidades da aplicação.

5.4 Objetos de dados de serviço

5.4.1 SDO (Service Data Objects)

Os objetos de dados de serviço, na especificação CANopen, são designados por SDO

(Service Data Objects) e são utilizados para estabelecer uma ligação do tipo cliente/servidor

em que o cliente lê e escreve em todas as entradas do dicionário de objetos do dispositivo

servidor. Neste tipo de transferência de dados é o cliente que toma a iniciativa, mas tanto o

cliente como o servidor podem por termo à ligação. A principal utilização deste tipo de

objeto prende-se com a configuração dos dispositivos da rede. Os objetos do tipo SDO

contêm informações (índice e sub índice) para endereçarem os objetos contidos no

dicionário. A combinação dessas informações é designada por “multiplexor” e permite que

uma única ligação com um objeto SDO possa ser usada para varrer toda a área do dicionário.

Os protocolos utilizados para realizarem transferência de dados sobre objetos do tipo

SDO são designados por “SDO Download” e “SDO Upload” e permitem efetuar operações

de escrita e leitura no dicionário, respectivamente. O tamanho dos objetos transferidos por

estes serviços não é constante, pode variar entre um byte a vários kBytes, dependendo do

objeto concordado.
5.4.2 (PDO) Process Data Objects

A segunda modalidade de comunicação é através do uso das transferências de

Objetos de Dados de Processo (Process Data Object - PDO). Mensagens de dados de

processo (síncronas e assíncronas/eventuais) são principalmente usadas para transferências

em tempo real de dados e normalmente tem prioridade mais alta no barramento CAN do que

mensagens de dados de serviço. Cada PDO tem um único identificador e é transmitido por

um único nó, mas pode ser recebido por mais de um (comunicação produtor/consumidor).

Transmissões de PDO podem ser orientados por um evento, ou temporizador interno,

por uma requisição remota, ou por mensagem de sincronização recebida. Na Orientação a

evento e por tempo, um evento (especificado no perfil do equipamento) causa a transmissão

da mensagem. Um período de tempo transcorrido faz com que os nós transmitam

periodicamente.

Na requisição remota, outro equipamento pode inicializar a transmissão de uma PDO

assíncrona pelo envio de uma requisição remota (frame remoto). A transmissão sincronizada,

a fim de inicializar amostragem simultânea dos valores de entrada de todos os nós, uma

mensagem Sync periodicamente transmitida é requerida. A transmissão síncrona de PDO’s

requer espaço no modo de transmissão cíclico e acíclico.

Transmissão cíclica significa que o nó espera por uma mensagem Sync depois que ele

envia seus valores estimados. A transmição acíclica são causadas por um evento definido da

aplicação específica. O nó transmite seus valores com a próxima mensagem Sync mas não

transmitirá novamente até que outro evento da aplicação específica tenha ocorrido.
5.5 Vantagens

O CANopen veio a desenvolver posteriormente como uma versão melhorada do

protocolo CAN. O seu principal trunfo revela-se na transmissão de dados P2P (peer to peer),

eliminando assim um elemento intermédio, passando os intervenientes a comunicar entre si

diretamente. É um protocolo de nível superior adaptado ás características do seu precedente,

retirando-se daí inúmeras vantagens.

5.6 Breve comparação com as redes convencionais

Em redes convencionais de bus de transmissão de dados Master/Slave, a eficiência do

módulo de mestre determina o comportamento em tempo real de toda a rede em que este se

encontra incluído. Geralmente os módulos escravos não conseguem comunicar entre si, o

que ocasionará a aplicação de dois protocolos de comunicação. Isto incrementa

consideravelmente não só as despesas relacionadas com a comunicação mas, sobretudo,

aumenta o risco de erros de transmissão de dados.

O CANopen veio para suprir essas estas falhas. Se apenas alguns dos intervenientes

necessitarem de uma largura de banda excepcional, este protocolo estabelece-a, não sendo

assim necessário colocar todos os dispositivos para comunicar na maior largura de banda, o

que encareceria e em muito o sistema.

5.7 Exemplo de Aplicação

CANOpen foi desenvolvido na década de 80, pela Bosch (Alemanha), viria

inicialmente a ser criada apenas para ser utilizada na indústria de automóvel, encontrando-se

atualmente difundida em inúmeras aplicações. Uma dessas aplicações é na indústria de

robótica e automação.
Os robôs industriais são, de todos os equipamentos usados na Automação Industrial

aqueles que apresentam melhor índice de custo de produção por unidade de produto, em

função do volume de produção para pequenos/médios volumes de produção.

Figura 15 robôs industriais manipuladores

Esse é o caso da esmagadora maioria das pequenas e médias empresas existentes nos

países desenvolvidos ou em vias de desenvolvimento. Na verdade, dadas as características de

mercado (elevada concorrência, produtos definidos em parte pelos clientes, produtos com

tempos de vida curtos, exigência crescente de mais qualidade a mais baixo preço etc.), as

empresas produzem essencialmente por encomenda e não arriscam estoques (para além dos

estoques de segurança). Essa é talvez a razão da utilização crescente de robôs em ambiente

industrial.
6 SDS (Smart Distributed System)

6.1 Introdução

A SDS (Smart Distributed System) [10] é um tipo de rede CAN desenvolvido para

unir velocidade com confiabilidade e flexibilidade incluindo os requerimentos para controle

em tempo real. A SDS desenvolvida pela divisão Micro Switch da Honeywell, é um

avançado sistema de barramento para sensores inteligentes e atuadores. Combinando o poder

da tecnologia CAN e dispositivos de I/O inteligentes, a SDS oferece uma verdadeira solução

integrada. Através de um simples cabo de 4 fios pode-se controlar até 64 nós com um

máximo de 126 endereços além de comunicar-se com computadores de processo e PLCs.

Os sensores e atuadores inteligentes fazem mais que apenas ligar e desligar, pois os

dispositivos de uma SDS têm um avançado nível de funções, incluindo diagnóstico de

dispositivo. A especificação da SDS compreende um sistema padronizado de interconexão

para dispositivos inteligentes (Smart Devices) com resposta rápida e baixo custo em uso

industrial. Este sistema é baseado em CAN, a qual é definida pela Bosch V2.0 CAN

Specification.

A ISO Standard 11898, contém outros pontos relacionados à especificação da Bosch

CAN, como interoperabilidade e consistência na operação da rede. Em uma implementação

SDS, cada barramento (um ou mais) interconecta-se a um grupo de Smart Devices. Isto reduz

significativamente a ligação ponto a ponto entre os dispositivos. A figura 16 mostra um

exemplo simplificado de um sistema SDS.


Figura 16 exemplo simplificado de um sistema SDS

6.2 Modelo físico

Enquanto o modelo de referência ISO/OSI contém sete camadas, o modelo de

referência da SDS (Smart Distributed System) necessita de somente três camadas. O alto

custo de uma implementação total da arquitetura OSI (as 7 camadas), torna-se impraticável

para a maioria das soluções de controle em nível de dispositivos. Entretanto, o modelo de

três camadas do Smart Distributed System é especificado como uma forma simplificada do

modelo ISO/OSI incluindo somente as camadas de Aplicação, Data Link e Física.

Algumas aplicações de controle típicas consistem de loops firmemente acoplados,

rodando sobre um simples link. Estas aplicações não necessitam das funcionalidades das

camadas de apresentação, sessão ou rede. Algumas funcionalidades necessárias da camada

de transporte, são trabalhadas na camada de apresentação.

A tabela 4 nos mostra o modelo de referência da Smart Distributed System.


Tabela 4 modelos ISSO/OSI e SDS.

Camada Função Especificação


OSI-Layer 7 Application especificado pelo projetista
OSI-Layer 6 Presentation vazio
OSI-Layer 5 Session vazio
OSI-Layer 4 Transport vazio
OSI-Layer 3 Network vazio
OSI-Layer 2 Data Link coberto pelo CAN e padrão OSI
OSI-Layer 1 Physical Coberto pela ISO e parcialmente pelo CAN

A camada Data Link provê um meio funcional e procedural para estabelecer, manter

e distribuir conexões entre as entidades da rede e para transferir os dados da rede. Uma

conexão é baseada em uma ou muitas conexões físicas. A camada Física provê um meio

mecânico, elétrico, funcional e procedural para ativar manter e desativar conexões físicas

para múltiplas transmissões entre entidades conectadas.

Um Componente Físico é um simples pacote com um ou mais controladores de rede e

contendo um ou mais dispositivos lógicos (Logical Devices). O Componente Físico provê

uma visão física de um Smart Device independente de qualquer aplicação de rede.

O nó inteligente (Smart Node) é a visão da rede de um componente físico (Physical

Component). Portanto, um Smart Node é um componente físico configurado. O Logical

Device, endereçável em um nó da rede, realiza operações de I/O e funções de controle local

em uma rede Smart Distributed System.


Figura 17 modelo físico SDS

6.2.1 Especificação da alimentação elétrica do Barramento SDS

Uma fonte de alimentação deve ser disponibilizada para todos os nós de um

barramento Smart Distributed System. Isto inclui os componentes físicos, bem como todos os

dispositivos que podem estar ligados ao barramento através de um componente físico. Um

componente físico pode ou não compartilhar esta alimentação com qualquer componente ou

módulo ligado ao barramento. A potência requerida para a fonte de alimentação é a soma das

potencias requeridas de todos nós. Se for necessário o uso de alimentação auxiliar do

barramento, será necessário o uso de isolação galvânica.

6.3 Serviços da camada de aplicação

A camada de Aplicação da Smart Distributed System oferece serviços para uma

máxima performance da rede, observando as limitações da camada Data Link da rede CAN.

O modelo de serviço da SDS utiliza quatro funções primitivas: Request, Response,


Indication, e Confirm, para prover os serviços da camada de aplicação. Estas funções são

mostradas na figuras 18.

Figura 18 representação básica das primitivas de serviço

Uma primitiva Request apresentada para a camada de aplicação, precipita a geração

de uma APDU (Application Protocol Data Unit) pelo dispositivo inicializante. A recepção da

APDU pelo dispositivo destino causa uma indicação (Indication) de mensagem recebida

para o serviço usuário no dispositivo destino. O serviço usuário no dispositivo destino

apresenta uma primitiva Response para a camada de aplicação que precipita a geração de

uma APDU.

A recepção desta APDU pelo dispositivo inicializante causa uma primitiva Confirm

para ser entregue ao serviço usuário no dispositivo inicializante.


7 CONCLUSÕES E RECOMENDAÇÕES

Este trabalho de monografia apresentou a tecnologia das redes industriais sob a

tecnologia CAN (DeviceNet, CANOpen e SDS). Existe grande diversidade de soluções nas

redes de campo atuais. Com a grande disponibilidade e o baixo custo atual da tecnologia de

redes a utilização das redes de computadores para interconectar sensores, atuadores e

controladores está tornando-se amplamente aceita para a implementação de sistemas de

controle realimentado. Dentre os protocolos existentes para comunicação industrial, o

protocolo CAN (Controller Area Network) com seu baixo custo, alta confiabilidade,

simplicidade e com características de tempo-real, apresenta-se como uma alternativa

adequada para o desenvolvimento de sistemas de automação industrial. O campo de

utilização da rede CAN é praticamente ilimitado.

Pode-se concluir que a rede CAN juntamente com suas variantes DeviceNet,

CANOpem e SDS estão cada vez mais evoluídas, buscando uma melhor performa-se e

confiabilidade para as indústrias de automação industrial. Devido a sua capacidade de

detecção de erros e seu mecanismo de arbitragem não destrutivo de mensagens e capacidade

de eliminar as interferências na rede, as variantes do protocolo CAN adaptam-se

perfeitamente em uma área industrial.

Em extensão a este trabalho sugere-se estudos detalhados de forma a estabelecer

procedimentos a serem seguidos nas industrias, de modo a facilitar a escolha, a elaboração de

projeto e a montagem de uma solução de automação utilizando rede de campo.


8 REFERÊNCIAS BIBLIOGRÁFICAS

[1] LAWRENZ, W. CAN System Engineering: From Theory to Pratical Applications,

New York: Springer Verlag, 1997.

[2] Controller Area Network (CAN), an overview. Disponível em:

<http://www.can-cia.de/can/>. Acesso em: 28 jan. 2005.

[3] CAN Specification. Disponível em: <http://www.can.bosh.cm/content/Literature.html>

Acesso em: 26 jan. 2005.

[4] CORIGAN, Steve Introduction to the Controller Area Network (CAN). Application

Report - SLOA101 – Texas Instrumensts, August – 2002.

[5] Network Information & Comparisons. Disponível em:

<http://www.synergetic.com/education/index.html >. Acesso em: 05 abr. 2005.

[6] Higher Layer Protocols. Disponível em: <http://www.can-cia.org/can/ higher-layer/>.

Acesso em: 26 jan. 2005.

[7] Volcano – a revolution in on-board communications. Disponível em:

<http://www.volvo.se/rt/trmag/vtr981/article2/a2no198.html>. Acesso em: 11 fev. 2005.

[8] J1939-based higher layer protocols. Disponível em: <http://www.can-

cia.de/j1939based/>. Acesso em: 25 jan. 2004.

[9] CANopen, an overview. Disponível em: <http://www.can-cia.de/canopen/>. Acesso em:

28 jan. 2005

[10] Smart Distributed System Verification Testing Information. Disponível em:

<http://content.honeywell.com/sensing/prodinfo/sds/verificationtesting.stm>. Acesso em: 21

jan. 2005.

[11] CANKingdom, an overview. Disponível em: <http://www.can-cia.de/cankingdom/>.

Acesso em: 28 jan. 2005.


[12] DeviceNet, an overview. Disponível em: <http://www.can-cia.de/devicenet/> . acesso

em: 21 jan. 2005.

[13] DeviceNet, Technical overview. Disponível em: <http://www.odva.org>.

[14] Introdução à DeviceNet. Disponível em: <http://www.ab.com/manuals/pt/cn/dnet-

br002c-pt-p-pdf>. Acesso em: 17 dez. 2005.

[15] CIP: Not Just Another Pretty Acronym. Disponível em:

<http://www.ab.com/networks/CIPwhitepaper2.html>. Acesso em: 12 mar. 2005.

[16] Planning and Installation Manual - DeviceNetTM Cable System. Disponível em:

<http://www.odva.org>

[17] DeviceNet Cable System – Planning and Installation Manual. DeviceNetTM – (Cat.

No. Dn–6.7.2) May – 1999.

[18] Manual de Instruções Rede DeviceNet – Recomendações de Instalações. Disponível

em: <http://www.sense.com.br>

[19] LAW Bob DeviceNet Technical Bible. Disponível em CDROOM.

[20] ROCKWELL AUTOMATION. DeviceNet Product Overview : Publication DN-2.5,


Rockwell, 1997.

9 BIBLIOGRAFIA RECOMENDADA

. KUROSE, James F. ROSS Keith W. Redes de Computadores e a Internet. São Paulo:

Addison Wesley, 2003.

. TANENBAUM, A. Computer Networks. Englewood Cliÿs:Prentice-Hall, 1989.

. MARTINS, Ronei Ximenes Introdução a redes de Computadores Minas Gerais, 2003.

Disponível em: <http://www.aprocura.com.br/nanicosemfio/doc/introredes.pdf>

. BRUDNA Cristiano. Desenvolvimento de Sistemas de Automação Industrial Baseado

em Objetos Distribuídos e no Barramento CAN.. Dissertação (Mestrado em Engenharia

Elétrica). Universidade Federal do Rio Grande do Sul, 2000.


. ATAIDE Fernado H. Implementação de uma rede CAN utilizando microcontrolador

MCF5282. Programa de Iniciação Cientifica. Centro Universitário do Leste Mineiro –

Unileste – MG, 2004.

Das könnte Ihnen auch gefallen