ivan roberto timochenko de moraes - tmors.com.br · ivan roberto timochenko de moraes paulo...
Post on 03-Dec-2018
216 Views
Preview:
TRANSCRIPT
CENTRO UNIVERSITÁRIO RADIAL
IVAN ROBERTO TIMOCHENKO DE MORAES PAULO HENRIQUE ELOY MACHADO
INTEGRAÇÃO DOS PROTOCOLOS ZIGBEE E MODBUS NA AUTOMAÇÃO INDUSTRIAL
São Paulo 2009
IVAN ROBERTO TIMOCHENKO DE MORAES
PAULO HENRIQUE ELOY MACHADO
INTEGRAÇÃO DOS PROTOCOLOS ZIGBEE E MODBUS NA AUTOMAÇÃO INDUSTRIAL
Monografia apresentada ao Centro
Universitário Radial para obtenção
do Título de Bacharel em
Engenharia.
Área de Concentração: Engenharia Eletrônica Orientador: Prof. Sidney Fernandes da Luz
São Paulo
2009
RESUMO
O protocolo de comunicação sem fio ZigBee, embora desenvolvido para uso
industrial, se apresenta à indústria com custos e tempo para implementação altos,
pois possui um formato de transmissão de dados que requer que um programa
dedicado seja desenvolvido para o tratamento dos dados de acordo com cada
necessidade. Tomou-se como objetivo tornar o protocolo ZigBee mais compatível
com aplicações industriais, permitindo sua integração ao protocolo Modbus, já
utilizado no setor industrial, por meio de um dispositivo que converta as linhas de
comando Modbus para ZigBee e vice-versa. Desenvolveu-se ainda, unidades
eletrônicas de transmissão sem fio capazes de ler e controlar variáveis de campo,
completando a integração entre os protocolos. Esta interface ZigBee-Modbus
permitirá que Controladores Lógicos Programáveis (CLP) ou Sistemas
Supervisórios sejam capazes de monitorar e controlar variáveis de campo de forma
flexível, com redução no uso de cabeamento e sem a necessidade de se
adaptarem à programação ZigBee.
A principal conquista alcançada neste projeto foi permitir que a comunicação entre
dispositivos de monitoramento e controle de variáveis de processos industriais
sejam feitos por meio de tecnologia de transmissão de dados sem fio, a partir de
um protocolo de comunicação desenvolvido para aplicações industriais, porém, de
forma simples e eficiente.
PALAVRAS-CHAVE: protocolo ZigBee, protocolo Modbus, transmissão de dados
sem fio, automação industrial.
ABSTRACT
The ZigBee wireless communication protocol, although developed for industrial use,
is introduced to the industry with high costs and timing consuming for
implementation due its transmission data format that requires the developing of a
dedicated software to handle the data according to each application. The objective
assumed was to turn the ZigBee protocol more compatible to industrial applications,
integrating it with the Modbus protocol, which is already widely used at industry,
through a device able to covert the Modbus commands to ZigBee commands and
vice-versa. Also, wireless electronic units able to read and control field
instrumentation were developed, completing the integration between the protocols.
This ZigBee-Modbus interface will allow that Programmable Logic Controllers (PLC)
or Supervisory Systems to monitor and control field instrumentation in a flexible way,
reducing cabling costs and without ZigBee programming adaptation.
The main reward in this Project was to allow a simple and efficient communication
among monitoring and controlling devices with wireless technology, using a protocol
already developed for industrial applications.
KEYWORDS: ZigBee protocol, Modbus protocol, wireless data transmission,
industrial automation.
SUMÁRIO
LISTA DE TABELAS LISTA DE FIGURAS 1. INTRODUÇÃO.......................................................................................01
1.1. Objetivo .......................................................................................01
1.2. Justificativa..................................................................................03
2. FUNDAMENTOS TEÓRICOS................................................................05 2.1. Fundamentos do protocolo ZigBee..............................................05
2.1.1. Tipos de nós .................................................................06
2.1.2. Pilha protocolar .............................................................07
2.1.3. Topologias de rede .......................................................09
2.1.4. Formação da Rede ZigBee ...........................................12
2.1.5. Endereçamento de dispositivos ....................................16
2.1.6. Modo de transmissão ....................................................16
2.2. Fundamentos do protocolo Modbus ...........................................17
2.2.1. Estados de operação do Mestre e Escravos em uma
rede Modbus .................................................................20
2.2.2. Modo de transmissão RTU ...........................................29
2.2.3. Descrição do quadro Modbus .......................................23
3. DESENVOLVIMENTO DO PROJETO ..................................................26 3.1. Módulo ZigBee ...........................................................................27
3.2. Unidade Remota ZigBus (URZ) ..................................................28
3.2.1. Circuito de alimentação .................................................29
3.2.2. Entradas digitais ............................................................30
3.2.3. Saídas digitais ...............................................................31
3.2.4. Entradas Analógicas .....................................................31
3.2.4.1. Circuito de proteção ......................................32
3.2.5. Circuito do módulo ZigBee ............................................33
3.3. Base ZigBus (BZ) .......................................................................34
3.3.1. Programa ......................................................................35
3.3.2. Fluxograma ...................................................................38
3.3.3. Endereçamento Modbus ...............................................41 4. ENSAIOS ..............................................................................................42
4.1. Análise do circuito de proteção das entradas analógicas ...........42
4.2. Resposta do conversor analógico-digital ....................................45
4.3. Teste do projeto ..........................................................................47
5. CONSIDERAÇÕES FINAIS ..................................................................49 5.1. Conclusões .................................................................................49
5.2. Contribuições .............................................................................49
5.3. Proposta para trabalhos futuros .................................................49
6. BIBLIOGRAFIA ....................................................................................51 7. ANEXOS................................................................................................55
Anexo A – Especificações do módulo XBee
Anexo B – Circuito eletrônico Unidade Remota ZigBus
Anexo C – Catálogo comercial do microprocessador RCM300
LISTA DE TABELAS
TABELA I – Tipos de dispositivos segundo a IEEE 802.15.4 [5] ................................06
TABELA II – Padrões de Comunicação IEEE [12] [14] ...............................................13
TABELA III – Acesso aos endereços Modbus das Unidades Remotas ZigBus ..........41
TABELA IV – Resposta do conversor analógico-digital .............................................46
LISTA DE FIGURAS
FIGURA 1 – Exemplo de rede ZigBee [7] ...................................................................07
FIGURA 2 – Pilha do protocolo ZigBee [9] ..................................................................08
FIGURA 3 – Redes Estrela e Árvore [11] ....................................................................10
FIGURA 4 – Rede sem fio Mesh [13] .........................................................................11
FIGURA 5 – Modelo de rede Mesh [12] ......................................................................12
FIGURA 6 – Modo de transmissão em uma rede ZigBee [7] ......................................17
FIGURA 7 – Ciclo de Pergunta e Resposta em uma rede Modbus [17] .....................19
FIGURA 8 – Sequência de mensagens sem erro [16] ................................................22
FIGURA 9 – Sequência de mensagens com erro [16] ................................................22
FIGURA 10 – Mensagem Modbus RTU [16] ..............................................................25
FIGURA 11 – Funcionamento básico do projeto ........................................................27
FIGURA 12 – Diagrama de blocos da Unidade Remota ZigBus (URZ) .....................28
FIGURA 13 – Circuito de alimentação das URZs .......................................................30
FIGURA 14 – Circuito das entradas digitais das URZs ..............................................30
FIGURA 15 – Circuito das saídas digitais das URZs .................................................31
FIGURA 16 – Circuito de entrada analógica das URZs .............................................33
FIGURA 17 – Circuito do módulo ZigBee ...................................................................33
FIGURA 18 – Diagrama de blocos da Base ZigBus (BZ) ...........................................35
FIGURA 19 – API de requisição de comandos locais [7] ...........................................36
FIGURA 20 – API de resposta de comandos locais [7] ..............................................36
FIGURA 21 – API de requisição de comandos remotos [7] .......................................37
FIGURA 22 – API de resposta de comandos remotos [7] ..........................................37
FIGURA 23 – Fluxograma de funcionamento do programa – Parte 1 ........................39
FIGURA 24 – Fluxograma de funcionamento do programa – Parte 2 ........................40
FIGURA 25 – Tensão de disparo do circuito de proteção mediante aumento
lento e gradativo da tensão de entrada ......................................................................42
FIGURA 26 – Resposta do circuito de proteção mediante aplicação de
tensão de 5 volts ........................................................................................................43
FIGURA 27 – Resposta do circuito de proteção mediante aplicação de
tensão de 10 volts ......................................................................................................43
FIGURA 28 – Resposta do circuito de proteção mediante aplicação de
tensão de 20 volts ......................................................................................................44
FIGURA 29 – Resposta do circuito de proteção mediante aplicação de
tensão de 30 volts ......................................................................................................44
FIGURA 30 – Resposta do circuito de proteção mediante aumentos
repentinos e cíclicos no nível de tensão de entrada ..................................................45
FIGURA 31 – Resposta da entrada analógica da Unidade Remota ZigBus ...............46
FIGURA 32 – Supervisório Elipse SCADA .................................................................48
INTRODUÇÃO
1.1. OBJETIVO
No segundo semestre de 2007 iniciou-se uma pesquisa sobre o protocolo de
comunicação sem fio ZigBee e desenvolveu-se uma interface de comunicação
capaz de monitorar o estado lógico de sinais digitais por meio de um computador,
simulando uma aplicação destinada a sistemas de controle de alarmes em prédios
comerciais.
Dando continuidade à pesquisa feita sobre o assunto, em 2008 tomou-se
como objetivo tornar o protocolo ZigBee mais compatível com aplicações
industriais, a fim de permitir sua integração ao protocolo de transmissão de dados
Modbus, já amplamente utilizado no setor industrial devido à sua confiabilidade e
simplicidade, por meio de um dispositivo microprocessado que converta as linhas
de comando Modbus para ZigBee e vice-versa.
Iniciou-se ainda, o desenvolvimento de unidades eletrônicas remotas
capazes de ler e controlar variáveis analógicas e digitais de campo compatíveis
com os módulos de transmissão de dados ZigBee, de forma a completar sua
integração às aplicações industriais.
Como Trabalho de Conclusão de Curso, pretende-se completar a
construção da interface de comunicação entre os protocolos ZigBee e Modbus e
das unidades remotas de aquisição e controle de variáveis. A interface, ou gateway,
entre os protocolos será totalmente transparente ao mestre da rede Modbus, não
sendo necessária nenhuma programação adicional ao dispositivo para que este
esteja apto a ler ou a comandar as variáveis de processo conectadas às entradas e
saídas das unidades remotas. Cada unidade remota se comunicará com o gateway
por meio do protocolo ZigBee em distâncias que podem variar de dezenas a
algumas centenas de metros e possuirão: 03 entradas para leitura de sensores
analógicos de saída padronizada 4-20mA; 03 entradas digitais para leitura de
sensores de saída discreta; e 03 saídas digitais a relé para controle de atuadores.
A possibilidade de transmitir e ler comandos de uma rede Modbus, por meio
do protocolo ZigBee, permitirá que Controladores Lógicos Programáveis ou
Sistemas Supervisórios sejam capazes de monitorar e controlar variáveis de campo
1
de forma flexível, com redução no uso de cabeamento e sem a necessidade de se
adaptarem à interface de programação ZigBee.
2
1.2. JUSTIFICATIVA
A aplicação da tecnologia wireless no setor industrial tem se intensificado
durante os últimos anos com a chegada de protocolos de comunicação e sistemas
preparados para suportar as diversas fontes de interferência que as plantas
industriais apresentam, além da robustez exigida neste tipo de ambiente.
O protocolo de comunicação ZigBee, ainda pouco difundido no Brasil,
embora também tenha sido desenvolvido para uso em aplicações industriais que
exijam baixo custo e alta confiabilidade, possui um formato de transmissão de
dados que requer quase sempre que um programa aplicativo seja desenvolvido
para o tratamento dos dados de acordo com cada necessidade. Desta forma, este
se apresenta à indústria com custos e tempo para implementação altos,
destinando-se à aplicações específicas. Não sendo assim atrativo às aplicações
que requerem soluções simples e rápidas.
Basicamente, uma rede de automação industrial consiste em um controlador
lógico programável (CLP) que se comunica com sensores remotos para aquisição
de variáveis de processo como temperatura, pressão, vazão, vibração e peso.
Quando a aplicação inclui funções de controle, os CLPs agem enviando comandos
que organizam o processo por meio de motores, atuadores, solenóides e válvulas.
O sucesso desta automação depende da confiabilidade na comunicação
entre CLPs e os sensores/atuadores. Esta comunicação tem sido tradicionalmente
feita fisicamente, por meio de fios que percorrem toda a planta industrial a fim de
interligar todos os componentes da rede. [1]
A transmissão de dados sem fio, seja de um sensor instalado em um local
de difícil acesso ou num atuador localizado em ambiente agressivo ao operador,
mostra-se uma solução prática e de custo acessível; a fim de eliminar a passagem
de cabeamento ao longo de plantas e galpões industriais, facilitando os serviços de
instalação, eliminando problemas de indução e rompimento de fios e aumentando a
flexibilidade na movimentação dos instrumentos de medição e controle.
Umas das principais observações feitas nos resultados apresentados por um
experimento feito com uma rede ZigBee em uma instalação de automação industrial
em uma companhia de mineração sueca, com o intuito de demonstrar que o novo
padrão ZigBee se comporta bem mesmo em ambientes industriais pesados, foi que
a rede de sensores sem fio aparentava estar funcionando satisfatoriamente, mesmo
além da máxima distância especificada no padrão ZigBee (30 metros). O ambiente
3
industrial hostil a radiofrequência aparentemente não estava prejudicando o
desempenho a um grau perceptível. Um modelo de sincronização de tempo simples
mostrou ser suficiente para o ciclo ativo da rede. Isto permitiu um melhor
gerenciamento de energia ao custo da redução do rendimento de toda a rede. [2]
Os trabalhos relacionados, ao padrão ZigBee, apesar de serem poucos por
esse ser um padrão recente, confirmaram que o ZigBee se comporta bem mesmo
para ambientes industriais pesados.
Tendo em vista a potencialidade do protocolo ZigBee em implementar a
construção de redes indústrias de automação que permitam mobilidade sem
desgaste mecânico do meio de transmissão de dados de forma confiável e robusta,
surge a necessidade de integrar este protocolo de comunicação às interfaces de
dados já existentes no setor industrial, de forma mais atrativa e transparente, com
menor tempo e custo de implementação.
4
2. FUNDAMENTOS TEÓRICOS
2.1. FUNDAMENTOS DO PROTOCOLO ZIGBEE
A tecnologia sem fio, ou wireless, descreve os sistemas de telecomunicação
em que as ondas eletromagnéticas carregam o sinal sobre parte ou todo o trajeto
de comunicação sem a utilização de cabos. [3]
ZigBee é nome de uma tecnologia de transmissão de dados sem fio,
desenvolvida sob padrões de endereçamento com o objetivo de criar redes de
baixo custo e baixo consumo de energia para comunicação de dispositivos
alimentados por baterias com autonomia por anos de uso. Este padrão possui todas
as vantagens e características físicas do padrão IEEE (Institute of Electric and
Electronic Engineers) 802.15.4 somadas a funcionalidades de rede, operando em
bandas livres de licença como 2.400-2.484 GHz (Global), 902-928 MHz (América) e
868,0-868,6 MHz (Europa). [4] O protocolo ZigBee foi desenvolvido por volta do ano de 2002 pela ZigBee
Alliance, um consórcio criado por líderes de fabricação de semicondutores,
integradores e usuários finais de tecnologia, criado e projetado para transmitir
dados através de ambientes de rádio freqüência hostis, geralmente encontrados em
aplicações industriais e comerciais com as seguintes características:
• Baixo consumo de energia elétrica;
• Suporte de diversas topologias de rede: estática, dinâmica, estrela ou
mesh;
• Espalhamento Espectral em Seqüência Direta (DSSS – Direct
Sequence Spread Spectrum);
• Capacidade de até 65.000 nós por rede;
• Encriptação de dados AES 128-bit (Advanced Encryption Algorithm)
que garante segurança na comunicação entre dispositivos;
• Prevenção de colisão de pacotes de dados;
• Transmissão de dados até 250kbps;
• Re-tentativas de transmissão e confirmações de recebimento de
pacotes de dados.
5
2.1.1. Tipos de nós
O padrão IEEE 802.15.4 define dois tipos de dispositivos conforme a Tabela
I:
TABELA I – Tipos de dispositivos segundo a IEEE 802.15.4 [5]
Tipos de dispositivo
Funcionalidades oferecidas
disponíveis no protocolo
Fonte de alimentação
típica
Configuração típica do receptor
Full Function Device (FFD) A maioria ou todas Principal Ligado quando
em espera
Reduced Function Device (RFD) Limitada Bateria
Desligado quando em
espera
Full Function Device (FFD) - pode funcionar em qualquer topologia do
padrão, desempenhando a função de coordenador da rede ou roteador e
conseqüentemente ter acesso a todos os outros dispositivos dentro de seu alcance
de transmissão. São dispositivos mais completos.
Reduced Function Device (RFD) - dispositivo mais simples, com menos
memória, utilizado nas pontas da rede sem atribuições de reenvio de mensagem,
ou seja, não pode atuar como um coordenador de rede ou roteador. Pode
comunicar-se apenas com um FFD. Cada rede consiste de múltiplos FFDs e RFDs,
com um dos FFDs designado como coordenador da rede. [6]
Conforme ilustrado na Figura 1, o protocolo ZigBee define três tipos de
dispositivos de acordo com as funcionalidades oferecidas e consumo de energia:
Coordenador (Coordinator) Também chamado de ZC (ZigBee Coordinator), é o único FFD responsável
pela formação de uma rede ZigBee; fato que lhe confere presença obrigatória em
todas as redes. O Coordenador estabelece um canal de operação e o número
lógico para formar a rede. Uma vez estabelecido estes parâmetros, o coordenador
pode formar uma rede permitindo que roteadores e dispositivos finais se integrem a
esta. Após a formação da rede, o coordenador funciona como um roteador,
podendo participar no redirecionamento de pacotes de dados e ser uma fonte ou
destino de pacotes de dados. [7]
6
Roteador (Router) O roteador ou ZR (ZigBee Router) é um nó FFD que cria e/ou mantém as
informações da rede e as utiliza para determinar a melhor rota para um pacote de
dados. Os roteadores podem participar no redirecionamento de pacotes de dados e
ser uma fonte ou destino de pacotes de dados. Sempre se integram à rede antes de
permitir que outros roteadores e dispositivos finais se integrem a ele. [7]
Dispositivo final (End device)
Um dispositivo final ou ZEB (ZigBee End Device) é classificado como um
RFD e deve sempre interagir com o seu nó pai (ou um roteador ou um
coordenador) na rede para receber ou transmitir dados; podendo ser uma fonte ou
destino de dados, porém, não possuindo a capacidade de redirecionamento de
informações. Possui como principal característica a alimentação por baterias, pois
possui modos de operação com baixo consumo de energia elétrica. [7]
FIGURA 1 – Exemplo de rede ZigBee [7]
2.1.2. Pilha protocolar A pilha protocolar ZigBee é formada pelas camada física PHY (Physical
Layer) e pela camada MAC (Media Access Control Layer), especificadas conforme
o padrão IEEE 802.15.4, pela camada de rede (NWK) e pela camada de aplicação,
que contém as subcamadas de suporte à aplicação (APS) e ZigBee Device Object
(ZDO). Na estrutura também são adicionados os objetos de aplicação definidos
pelo usuário. A estrutura completa é mostrada na Figura 2. [8]
7
FIGURA 2 – Pilha do protocolo ZigBee [9]
Camada PHY A camada mais baixa da pilha protocolar, a camada física, é definida pelo
padrão 802.15.4 da IEEE, e é implementada em silício. A camada física codifica os
bits que são enviados e decodifica os que são recebidos. Parte da informação
disponível na camada física é fornecida para a camada MAC, como por exemplo, a
estimativa de canal livre, a indicação da qualidade da conexão e a indicação da
potência do sinal recebido. [10]
A norma IEEE 802.15.4 define 27 canais na camada PHY distribuídos da
seguinte forma:
• 16 canais com taxa de 250kbps na banda livre ISM (Industrial,
Scientific and Medical) 2,4 - 2,4835 GHz disponível globalmente;
• 10 canais com taxa de 40kbps na banda ISM 902 - 928 MHz,
disponível na América do Norte;
• 1 canal com taxa de 20kbps na banda 868,0 - 868,6 MHz, disponível
na Europa.
8
Camada MAC A camada MAC controla o acesso ao canal de rádio compartilhado. Esta
gera e reconhece os endereços e verifica as seqüências das estruturas de controle
(frame check), além de ser responsável pela sincronização das transmissões. [10]
Camada de Rede A camada de rede (NWK) está relacionada ao nível de comunicação.
Controla a estrutura de rede e cuida do roteamento e das funções de segurança
das mensagens transmitidas.
A rede ZigBee é uma rede dinâmica e a camada de rede precisa manter as
informações sobre os nós dentro da rede. As propriedades e parâmetros da rede
são especificados na aplicação como configurações de pilha da camada de rede.
Isto inclui a topologia, segurança e outros. [10]
Camada de Aplicação A camada de aplicação carrega o código de cada aplicação feita
individualmente.
De acordo com a especificação ZigBee, este código é escrito dentro do
campo ZDO (ZigBee Device Object), onde a função do dispositivo é especificada.
Aqui é definido se o dispositivo será do tipo FFD ou RFD, as funções de segurança
de rede, as resposta e atos para cada evento do sistema.
A subcamada de suporte à aplicação (APS) forma o nível baixo da camada
de aplicação. Aqui, as ligações (binding) e a descoberta da vizinhança dos
dispositivos são realizadas. [10]
2.1.3. Topologias de rede A especificação do protocolo ZigBee permite que três topologias de rede
diferentes possam ser implementadas, dependendo da aplicação. [11]
São elas: Estrela (Star), Árvore (Cluster Tree) e Malha (Mesh). Estas
topologias são discutidas a seguir:
• Estrela (Star): Na configuração Estrela um dispositivo atua como o
coordenador da rede ZigBee, o qual se encarrega de toda a
comunicação em um dado canal de rádio. O coordenador da rede deve
ser capaz de se comunicar com qualquer outro dispositivo na rede. O
RFD pode apenas se comunicar com um FFD.
9
• Árvore (Cluster Tree): A topologia Árvore é formada apenas
modificando a topologia Estrela. Um ou mais dos RFDs conectados ao
coordenador da rede ZigBee é substituído por um FFD, e destes FFDs,
mais RFDs ou FFDs podem ser conectados. Uma vantagem desta
topologia é que ela pode ser usada para aumentar a cobertura
geográfica da rede.
A Figura 3 apresenta modelos de redes em Estrela e Árvore.
FIGURA 3 – Redes Estrela e Árvore [11]
• Malha (Mesh): O principal componente do protocolo ZigBee é a
habilidade de suportar redes em malha, também denominadas redes
mesh ou ad hoc. O que caracteriza essas redes é a capacidade que
seus nós possuem de redirecionar os pacotes de informação por
diferentes caminhos pela rede, “saltando” por outros nós, até atingirem
seu destino. Se um determinado caminho (canal ou nó) é interrompido
ou perde a qualidade, a rede automaticamente procura um novo
caminho (canal ou nó), mais adequado para manter o tráfego de dados.
[12]
Um nó da rede Mesh pode ter apenas a função de comunicação, ou
ainda, ter suas funcionalidades particulares além de retransmitir os
sinais dos seus nós vizinhos.
Um exemplo de comunicação entre dois dispositivos dessa rede é
ilustrado na Figura 4 e descrito a seguir:
10
FIGURA 4 – Rede sem fio Mesh [13]
− N4 vai enviar informações para N1;
− N4 envia um pacote de dados para N1, requisitando confirmação de
recebimento;
− N1 está fora do alcance de N4. Os nós N2 e N3 recebem os pacotes;
− N2 e N3 identificam que o endereço do destinatário é outro nó;
− N2 e N3 retransmitem o pacote de dados e gravam a identificação do
pacote para evitar retransmissões;
− N4 recebe o pacote de dados retransmitido de N2 e N3 e descarta os
pacotes repetidos;
− N1 recebe um pacote retransmitido de N2 ou N3, dependendo de
qual dos dois retransmitiu primeiro;
− N1 se identifica como receptor da transmissão e envia um pacote de
dados endereçado a N4;
− N1 recebe o segundo pacote retransmitido por N2 ou N3 e o ignora;
− N2 e N3 recebem a confirmação de N4, já que N1 está fora do
alcance de N4;
− N2 e N3 identificam que o endereço do receptor é outro nó;
− N2 e N3 retransmitem a confirmação para N4;
− N1 recebe a confirmação retransmitida e descarta as retransmissões;
− N4 recebe a confirmação de N2 ou N3, dependendo de qual dos dois
nós retransmitiu primeiro;
− N4 se identifica como receptor da confirmação e completa a
comunicação com N1;
− N4 recebe a segunda confirmação retransmitida e a descarta.
11
As redes em malha normalmente são utilizadas em aplicações móveis
ou em ambiente com obstáculos. A busca de caminhos alternativos para
que os nós possam se comunicar, mesmo estando fora do raio de ação,
é uma das principais características destas redes.
As redes em malha também podem operar através de tabelas de
conexões, ou seja, os nós têm a capacidade, a todo instante, de
aprender quais nós fazem parte da rede e essas informações são
armazenadas em tabelas em cada nó. Assim, se algum elemento quiser
enviar dados a outro, ele irá verificar em sua tabela qual o menor
percurso até o destino. [13]
A Figura 5 mostra o modelo conceitual de comunicação entre os nós de
uma rede Mesh.
FIGURA 5 – Modelo de rede Mesh [12]
Com relação aos protocolos de comunicação similares ao ZigBee, foram
citadas as principais diferenças entre estes na Tabela II a seguir:
12
TABELA II – Padrões de Comunicação IEEE [12] [14]
Norma IEEE
(nome de mercado) 802.15.4 (ZigBee)
802.11b (Wi-Fi)
802.15.1 (Bluetooth)
Aplicação principal Controle e monitoração
Internet, e-mail, multimídia
Eliminar fiação atual
Freqüência de operação 2,4 GHz 2,4 GHz 2,4 GHz
Taxa de comunicação (kbps) 20 – 250 11.000 1.000 – 3.000
Distâncias alcançadas com visada direta (m)
30 – 70, 100+ (com amplificador
externo)
100+ (antenas direcionais)
30 (Classe 2) 100+ (Classe 1)
Número de nós em uma rede 65.000 32 7
Autonomia da bateria (dias) 100-1000+ 0,5 – 5 1 –7
Consumo na transmissão 30 mA 300 mA 45mA (Classe 2) <150mA (Classe
1)
Conveniência para controle e supervisão em aplicações industriais
Boa (Bom compromisso
entre taxa e custo de conexão)
Baixa (Taxa alta, mas conexão inicial lenta)
Baixa (Boa média, mas
conexão inicial lenta)
Tecnologia de espalhamento espectral
DSSS (Direct Sequence
Spread Spectrum)
DSSS (Direct Sequence
Spread Spectrum)
FHSS (Frequency
Hopping Spread Spectrum)
Vantagens relativas Potência, custo Velocidade, Flexibilidade
Custo, Flexibilidade
Dentre as diversas possibilidades de aplicações de monitoramento e
controle utilizando o protocolo ZigBee, destacam-se: controle de luminosidade,
detectores de fumaça, telemetria, controle de temperatura, segurança doméstica,
controles ambientais, automação predial e outros.
13
2.1.4. Formação da Rede ZigBee
A formação de uma nova rede ZigBee, também chamada de PAN (Personal
Area Network), consiste em um coordenador e um ou mais roteadores e/ou
dispositivos finais, e é iniciada através de uma primitiva da camada de rede que é
restrita ao coordenador ZigBee, que não pertence a nenhuma rede. Para iniciar
uma rede, um coordenador da rede executa uma série de rastreamentos para
descobrir o nível de atividade RF em diferentes canais de freqüência, e também
detectar a presença de outras redes ZigBee. O coordenador então procura em cada
canal por dispositivos ou redes ZigBee. Baseado neste resultado, o coordenador
escolhe o melhor canal para criar uma nova rede, dando preferência para canais
nos quais não foram encontradas outras redes e onde há baixo nível de energia RF.
Por fim, o coordenador escolhe um identificador lógico de rede (PAN ID –
Identificador da rede) que será atribuído a todo dispositivo que ingressar na rede.
Finalmente o coordenador permite outros dispositivos ingressarem na rede.
Como parte do processo de ingressar em uma rede, cada dispositivo recebe
um endereço de rede lógico de 16 bits. Em redes ZigBee, os endereços de rede
são atribuídos ou por um coordenador ou por um roteador, usando um algoritmo de
árvore estruturada. [15]
Quando um roteador é inicializado pela primeira vez, este localiza e se junta
a uma rede ZigBee. Para fazer isso, este emite um comando de requisição
denominado 802.15.4 beacon request em múltiplos canais para localizar as redes
mais próximas. Roteadores e coordenadores próximos, que já se integraram a uma
rede, respondem à requisição com outra beacon request, indicando qual canal e
PAN ID estão operando. O roteador escuta todos os canais aguardando uma
resposta. Se uma rede válida é encontrada, o roteador emite uma requisição de
integração (joining request) para o dispositivo que respondeu à sua solicitação. Se
a integração é inicializada, o roteador irá receber uma confirmação de integração
deste dispositivo, indicando que a integração está completa. [7]
Uma vez que o roteador se juntou à rede, este pode se comunicar com
outros dispositivos da rede e permitir que outros dispositivos se juntem a esta. Esta
junção estabelece uma relação pai/filho entre dois nós da rede. O nó que permitiu a
junção/integração é o pai e o nó que foi incorporado à rede é denominado filho.
Dispositivos finais seguem o mesmo processo dos roteadores para se
integrar a uma rede. Uma vez que o dispositivo final se integrou com sucesso a
14
uma rede, este pode comunicar-se com outros dispositivos da rede. Entretanto,
uma vez que dispositivos finais não podem redirecionar dados, eles devem sempre
se comunicar diretamente com seus pais e permitir que estes redirecionem os
dados para si.
No mais alto nível da estrutura (no dispositivo coordenador) da rede está
definida uma entidade conhecida como "stack profile". O stack profile é um conjunto
de parâmetros que incluem definições da profundidade máxima da rede, o número
máximo de filhos roteadores e o número máximo de filhos (dispositivos finais) que
podem se comunicar com um roteador individual. Estes parâmetros determinam a
forma da árvore da rede. Por exemplo, a profundidade da rede determina o número
máximo de saltos entre qualquer dispositivo e o coordenador de rede.
O algoritmo de roteamento ZigBee utiliza uma métrica de cálculo de custo
de caminho para comparação de rota durante a descoberta e manutenção de rotas.
Para computar esta métrica, um custo é associado a cada enlace no caminho entre
fonte e destino, e estes valores são somados para produzir o custo do caminho
inteiro. Este procedimento de descoberta de rota é baseado no protocolo de
roteamento AODV (Ad hoc On Demand Distance Vector) e é utilizado caso o
roteador não esteja diretamente ligado ao dispositivo de destino, mas possui
“capacidade de roteamento”. [15]
Quando um nó da rede necessita descobrir uma rota de destino até um
outro nó, este envia um comando de requisição de rota para todos os nós. Este
comando contém o endereço de rede do nó de origem, o endereço de rede do nó
de destino e um campo de custo de enlace. Uma vez que o comando de requisição
de rota é propagado pela rede, cada nó que retransmite a mensagem atualiza o
campo de custo de enlace e cria uma entrada temporária em sua tabela de rotas
descobertas.
Quando o nó de destino recebe a requisição, este compara o custo de
enlace com os outros recebidos anteriormente. Se o custo de enlace recebido no
comando de requisição de rota é melhor que o anterior, o nó de destino transmitirá
um pacote de resposta ao nó que originou a requisição. Imediatamente, os nós
recebem e encaminham o pacote de resposta ao nó de origem (que gerou a
requisição de descoberta de rota). [7]
15
2.1.5. Endereçamento de dispositivos
O protocolo 802.15.4, o qual o protocolo ZigBee é baseado, especifica dois
tipos de endereços:
• Endereços de rede de 16 bits (16-bit network addresses)
É atribuído a um nó quando se integra à rede e é único para cada nó na
rede. Entretanto, podem se alterar devido às seguintes condições:
1. Se um dispositivo final não pode se comunicar com o seu pai e deve
deixar a rede e se reintegrar para encontrar um novo pai.
2. Se o tipo de dispositivo é alterado de roteador para dispositivo final,
ou vice-versa, o dispositivo irá deixar a rede e se reintegrar como um
novo dispositivo.
• Endereços de 64 bits (64-bit Addresses)
Cada nó contém um endereço único de 64 bits que o identifica na rede e
é permanente.
2.1.6. Modo de transmissão
Conforme ilustrado na Figura 6, quando um dado é enviado ao módulo RF
(radiofreqüência) que contém o protocolo ZigBee, este módulo sai do modo ocioso
(Idle Mode) para iniciar a transmissão de dados. O endereço de destino determina
qual nó receberá a informação.
Antes que inicie a transmissão, o módulo certifica-se que o endereço de 16 bits e a
rota para nó de destino tenha se estabelecido. Caso este endereço de destino ou a
rota não seja conhecido, procedimentos de descoberta de endereço ou rota
respectivamente são acionados. Caso, ainda assim, o endereço ou a rota não seja
descoberto, o pacote de dados é descartado. [7]
16
FIGURA 6 – Modo de transmissão em uma rede ZigBee [7]
2.2. FUNDAMENTOS DO PROTOCOLO MODBUS
O Modbus é um protocolo de comunicação aberto e dos mais simples
utilizados na automação industrial (Industrial Automation System – IAS). Situado na
camada 7 do modelo OSI (Open Systems Interconnection), que fornece um serviço
do tipo client/server (cliente/servidor) entre equipamentos ligados a um barramento
ou a uma rede. O Modbus foi introduzido no mercado pela empresa Modicon
(atualmente Schneider Electric) em 1979, rapidamente tornou-se um padrão
industrial e tem sido implementado por centenas de fabricantes nas mais variadas
aplicações e segmentos industriais. A sua popularidade aumentou devido à sua
simplicidade de implementação bem como pela disponibilidade de código fonte
gratuito. [16]
O protocolo Modbus é baseado em um modelo de comunicação mestre-
escravo, onde um único dispositivo, o mestre, pode iniciar transações denominadas
17
queries. Os demais dispositivos da rede (escravos) respondem, suprindo os dados
requisitados pelo mestre ou executando uma ação por ele comandada. Geralmente
o mestre é um sistema supervisório e os escravos são controladores lógicos
programáveis ou equipamentos periféricos (válvula, drive de rede ou outro
dispositivo de medição). Os papéis de mestre e escravo são fixos quando se utiliza
comunicação serial, mas em outros tipos de rede, um dispositivo pode assumir
ambos os papéis, embora não simultaneamente. [17]
Isso significa que somente um mestre é conectado ao barramento ao
mesmo tempo. Quanto aos escravos, um ou mais nós (número máximo de 247)
podem ser conectados a este mesmo barramento.
Como dito anteriormente, uma comunicação Modbus é sempre iniciada pelo
mestre. O nó mestre inicia somente uma transação Modbus por vez. Esta transação
(ou requisição) pode ser enviada de dois modos:
• Unicast: o mestre endereça a requisição para somente um escravo.
Depois de receber e processar a requisição, o escravo retorna uma
mensagem de resposta para o mestre, conforme a Figura 7. Neste
modo, uma transação Modbus consiste de duas mensagens: uma
requisição do mestre e uma resposta do escravo. Cada escravo deve ter
um endereço único (de 1 a 247) de forma a poder ser endereçado
independentemente de outros nós;
• Broadcast: o nó mestre pode enviar uma mensagem para todos os
escravos. Nenhuma resposta deve ser retornada para requisições
broadcast enviadas pelo mestre. As requisições broadcast são
necessariamente mensagens de escrita. Todos os dispositivos devem aceitar mensagens broadcast para escrita. O
endereço 0 (zero) é reservado para identificar uma mensagem broadcast. [18]
18
FIGURA 7 – Ciclo de Pergunta e Resposta em uma rede Modbus [17]
Na camada física, os sistemas Modbus podem usar diferentes interfaces
físicas (RS485, RS232, ethernet, e outras). A interface RS485 de 2 fios é a mais
comum. A interface serial RS232 só poderá ser utilizada quando uma comunicação
ponto a ponto de curta distância for requerida.
Diversas variantes deste protocolo estão disponíveis atualmente. A seguir
são resumidas as versões mais difundidas do Modbus:
1. Modbus RTU (Remote Terminal Unit): a variante mais comum, e a
base de outras, utiliza o RS-232 ou RS-485 como meio físico de
transmissão. A transmissão de dados é realizada em hexadecimal
onde apenas é permitida a existência de um único mestre, podendo
haver vários escravos;
2. Modbus ASCII (American Standard Code for Information
Interchange): também utiliza o RS232 e RS485 como meio de
transmissão. A transmissão dos dados neste caso é realizada em
formato ASCII (American Standard Code for Information
Interchange). Apenas é permitida a existência de um mestre,
podendo haver vários escravos;
3. Modbus TCP/IP (Transmission Control Protocol, Internet
Protocol): utiliza como meio físico de transmissão uma rede
ethernet. Os dados são transmitidos em formato hexadecimal. Esta
variante permite utilizar vários mestres e vários escravos numa
mesma rede. [16]
Nota: Na execução deste projeto será utilizada a variante RTU do protocolo
Modbus. Por este motivo, o enfoque nesta versão será maior.
19
2.2.1. Estados de operação do Mestre e Escravos em uma rede Modbus A seguir é apresentada a descrição dos estados de um mestre e um
escravo, que são independentes do modo de transmissão utilizado:
Dispositivo Mestre:
• Estado “idle” (ocioso) - Nenhuma requisição pendente. Este é o estado
inicial após a alimentação de um nó mestre. Uma requisição somente
pode ser enviada a partir de um estado “idle”. Depois de enviar uma
requisição, o mestre sai do modo “idle” e não pode enviar uma segunda
requisição até voltar a este modo;
• Quando uma requisição é enviada para um único escravo, o mestre
entra em um estado de espera por resposta (Waiting for Reply) e um
contador de espera é iniciado. Este contador previne o mestre de ficar
indefinidamente no modo de espera de resposta. O valor do tempo de
espera por uma resposta é dependente da aplicação;
• Quando uma resposta é recebida, o mestre verifica a resposta antes de
iniciar o processamento dos dados. A verificação pode resultar em um
erro. Exemplos de possíveis erros são as respostas por um escravo não
esperado ou um erro no quadro recebido. No caso de uma resposta
recebida por um escravo não esperado, o contador de espera continuará
sendo executado. No caso de um erro ser detectado no quadro
recebido, uma nova tentativa deve ser executada;
• Se nenhuma resposta é recebida, o contador expira e um erro é gerado.
Então o mestre entra no modo “idle”, habilitando uma requisição para
nova tentativa. O número máximo de tentativas é definido nas
configurações do mestre;
• Quando uma mensagem broadcast é enviada no barramento serial,
nenhuma resposta é retornada pelos escravos. Contudo, um tempo de
espera é respeitado pelo mestre no sentido de permitir que qualquer
escravo processe a requisição antes que o mestre envie uma nova
mensagem. Portanto, o mestre entra em um estado de espera (Waiting
Turnaround Delay) antes de voltar para o estado “idle” e, portanto, antes
de ser capaz de enviar outra requisição;
• Em modo unicast, o tempo de espera deve ser escolhido de forma que
qualquer escravo possa processar a requisição e retornar uma resposta.
20
No modo broadcast o tempo de espera deve ser longo o suficiente para
que qualquer escravo processe somente a requisição e esteja apto a
receber uma nova requisição. Devido a isso, o tempo de espera em
modo broadcast deve ser menor que em modo unicast. Tipicamente o
tempo de espera em modo unicast é de 1 segundo até vários segundos
para uma comunicação em 9600 bauds e o tempo de espera em modo
broadcast entre 100ms e 200ms. [18]
Dispositivo Escravo:
• Estado “idle” - Nenhuma requisição pendente. Este é o estado inicial
após a alimentação de um nó escravo;
• Quando uma requisição é recebida, o escravo verifica o pacote antes de
executar a ação solicitada no pacote. Diferentes erros podem ocorrer:
erro do formato da requisição, ação inválida, e outros. No caso de um
erro, uma resposta deve ser enviada para o mestre;
• Uma mensagem unicast requer que uma resposta seja formatada e
enviada para o mestre assim que a ação requisitada é completada;
• Se um escravo detecta um erro no quadro recebido, nenhuma resposta
é retornada para o mestre;
• Os contadores de diagnóstico Modbus são definidos e devem ser
gerenciados por qualquer escravo no sentido de prover informações de
diagnóstico. Estes contadores de diagnóstico podem ser adquiridos
através da função de diagnóstico Modbus. [18]
2.2.2. Modo de transmissão RTU Quando dispositivos se comunicam em um barramento serial Modbus,
utilizando o modo RTU, cada byte (8 bits) na mensagem irá conter 2 caracteres
hexadecimais de 4 bits. A principal vantagem deste modo é que sua maior
densidade de caracteres permite um melhor processamento de dados do que o
modo ASCII para um mesmo baud rate.
Uma mensagem Modbus é colocada pelo transmissor em um quadro que
tem um começo e fim bem definidos. Isto permite que dispositivos, que recebam um
novo quadro, conheçam o início da mensagem e também quando a mesma é
completada. Mensagens parciais devem ser detectadas e erros devem ser gerados
como resultado desta detecção. [18]
21
Cada mensagem deve ser transmitida em um fluxo contínuo de caracteres.
O formato para cada byte no modo Modbus RTU é:
− 1 bit de início (start bit)
− 8 bits de dados, sendo o de menor significado enviado primeiro.
− 1 bit de paridade (parity)
− 1 bit de parada (stop bit)
O bit de paridade, por padrão, é par (even parity), mas também pode ser
ímpar (odd parity) ou sem paridade (no parity). Todos os equipamentos ligados no
barramento ou rede devem ter a paridade configurada da mesma forma.
Quando não é utilizada a paridade (no parity), então passa a haver 2 stop
bits, desta forma a “palavra” mantém o tamanho de 11 bits.
Adicionalmente, é realizada a detecção de erro ao nível da mensagem. No
caso da transmissão em RTU o método utilizado tem o nome de CRC (Cyclical
Redundancy Checking). [16]
Uma determinada mensagem deve ser transmitida por uma seqüência de
“palavras” sem interrupção. Entre cada mensagem deve haver uma interrupção
(silêncio na linha) de pelo menos 3,5 vezes o tempo de um caractere, conforme
ilustrado na Figura 8.
FIGURA 8 - Sequência de mensagens sem erro [16]
Caso a mensagem ainda não tenha sido totalmente recebida e seja
detectado um silêncio na linha superior a 1,5 vezes o tempo de um caractere, então
a mensagem é descartada pelo receptor e interpretado como um erro, conforme a
Figura 9. [16]
FIGURA 9 - Sequência de mensagens com erro [16]
22
Como foi dito anteriormente, em Modbus RTU é realizada uma verificação
de erros na mensagem com o método CRC. Esta verificação é sempre realizada
mesmo que não esteja implementada a verificação de paridade (no parity).
O campo CRC é o último da mensagem e tem o tamanho de 16 bits. Neste
campo não é utilizado o start e stop bit e nem a paridade.
O byte CRC de maior ordem é o último byte enviado na mensagem. O valor
do CRC é calculado pelo dispositivo que transmitiu o quadro (mensagem). O
dispositivo que recebe o quadro recalcula o CRC durante a recepção da
mensagem, e compara o campo de CRC recebido com o CRC calculado. Se os
valores não são iguais, o dispositivo retorna um erro.
O cálculo do CRC é iniciado carregando-se um registrador de 16 bits com
todos os bits 1's (65535 decimal). Então um processo se inicia aplicando-se
sucessivamente bytes de 8 bits ao conteúdo deste registrador. Somente os 8 bits
de dados são utilizados para a geração do CRC. Os bits de início, parada e
paridade não participam do cálculo do CRC.
Durante a geração do CRC, cada caractere de 8 bits passa por uma
operação de “ou exclusivo” [19] com o conteúdo do registrador de 16 bits. Então o
resultado desta operação é deslocado no sentido do bit menos significativo com o
bit mais significativo, sendo preenchido por um zero. O bit menos significativo é
extraído e examinado. Se este bit for 1, o conteúdo do registrador sofre nova
operação de “ou exclusivo” com o polinômio gerador do CRC16. Se o bit for 0,
nenhum ação é executada. Este processo é repetido até que 8 deslocamentos
tenham sido realizados. Depois do último deslocamento, o próximo byte de 8 bits
sofre a mesma operação “ou exclusivo” e deslocamentos descrito acima. O
conteúdo final do registrador, depois de todos os bytes da mensagem terem
passado por este processo, é o valor do CRC. [18]
2.2.3. Descrição do quadro Modbus O protocolo de aplicação Modbus define uma unidade simples de dados de
protocolo (Protocol Data Unit – PDU), independentemente das camadas
adjacentes.
• As características do protocolo Modbus, em um barramento ou topologia
de rede específica, introduzem alguns campos adicionais ao PDU. O
mestre que inicializa uma transação Modbus constrói um Modbus PDU
23
e, então adiciona campos para que construa o PDU apropriado para
uma dada comunicação. [8]
O protocolo Modbus define três tipos de PDU:
• Modbus request: mensagem enviada do mestre para o escravo para
solicitar determinada informação ou para executar uma tarefa qualquer;
• Modbus response: mensagem enviada de um escravo para o mestre
com a informação solicitada pelo mestre ou a confirmação de que a
tarefa solicitada será executada;
• Modbus exception response: mensagem enviada do escravo para o
mestre com informação de que não é possível tratar o pedido solicitado.
[16]
Cada PDU possui quatro campos de dados. São eles:
• Endereço (Address Field): A faixa de endereços válidos vai de 0 a 247
(0x00 a 0xF7 hexadecimal), sendo que os dispositivos recebem
endereços de 1 a 247. O endereço zero é reservado para broadcast, ou
seja, mensagens com esse valor de endereço são reconhecidas por
todos os elementos da rede.
• Código de Função (Function Code): Varia de 1 a 255 (0x01 a 0xFF),
mas apenas a faixa de 1 a 127 (0x01 a 0x7F) é utilizada, já que o bit
mais significativo é reservado para indicar respostas de exceção.
Normalmente, uma resposta inclui o código de função da requisição que
lhe deu origem. No entanto, em caso de falha, o bit mais significativo do
código é ativado para indicar que o conteúdo do campo de dados não é
a resposta esperada, mas sim um código de diagnóstico.
• Dados (Data): Tamanho e conteúdo do campo de dados variam com a
função e o papel da mensagem, requisição ou resposta, podendo ser um
campo vazio. [17]
• CRC ou LRC (Cyclical Redundancy Checking, Longitudinal
Redundancy Checking): Campo para verificação de erros na
mensagem. Conforme visto, este campo é calculado durante o envio da
mensagem e verificado durante a recepção da mensagem. [16]
Assim, uma mensagem em Modbus RTU é constituída conforme ilustrado na
Figura 10:
24
FIGURA 10 – Mensagem Modbus RTU [16]
− Address field: 1 (um) byte (11 bits);
− Function code: 1 (um) byte (11 bits);
− Data: de 0 (zero) até 252 bytes (cada byte tem 11 bits);
− CRC: 2 bytes (16 bits).
25
3. DESENVOLVIMENTO DO PROJETO Este projeto tem o objetivo de criar uma interface de comunicação sem fio
entre sensores e atuadores industriais e equipamentos de controle de variáveis tais
como Controladores Lógicos Programáveis (CLP) ou Sistemas Supervisórios que
sejam compatíveis com o protocolo Modbus. Para tanto, duas unidades eletrônicas
distintas foram projetadas: a primeira, aqui denominada Unidade Remota ZigBus
(URZ), possui entradas e saídas de sinais de campo (sinais analógicos e digitais)
que são transmitidos por um módulo ZigBee presente em cada URZ; a segunda,
aqui denominada Base ZigBus (BZ), é responsável por receber mensagens de
requisição Modbus do mestre da rede (CLP ou Sistema Supervisório), convertê-las
para o protocolo ZigBee, enviá-las à URZ correspondente à requisição, converter a
resposta recebida da URZ para o protocolo Modbus, e então, responder ao mestre
da rede Modbus.
Em conjunto, estas unidades são capazes de realizar a leitura e escrita de
sinais analógicos e digitais utilizando o protocolo sem fio ZigBee, conforme a
requisição de um sistema operando em protocolo Modbus.
A Figura 11 apresenta uma rede formada por três Unidades Remotas
ZigBus, endereçadas conforme o protocolo Modbus, e uma Base ZigBus conectada
a um mestre Modbus, por meio de uma interface RS232.
A composição e funcionamento detalhado de cada unidade eletrônica são
apresentados a seguir.
26
FIGURA 11 – Funcionamento básico do projeto
3.1. MÓDULO ZIGBEE
O módulo de comunicação ZigBee modelo XBee ZB do fabricante Digi
International foi escolhido para este projeto, pois disponibiliza em um único
hardware o circuito de radiofreqüência, pinos de entradas e saída digitais, porta de
comunicação UART (Universal Asynchronous Receiver/Transmitter) e pinos para
conversão analógico-digital.
Estas características permitiram a construção de circuitos de entradas e
saídas de sinais digitais e analógicos sem a necessidade da interface de
microcontroladores nas URZs. Entretanto, foi necessário criar circuitos de interface
entre as variáveis de campo e o módulo.
Dentre as características do modelo do módulo escolhido, destacam-se:
• Duas versões de potência de transmissão RF (2mW e 50mW)
intercambiáveis, o que permite estender o alcance da rede em
algumas centenas de metros;
• Alimentação elétrica 3.3 volts;
• Banda de frequência: 2.4GHz;
• Pilha protocolar com a versão atualizada conforme a ZigBee Alliance;
27
• Antena integrada ao módulo, o que dispensa a construção de
circuitos de transmissão e recepção de dados;
O Anexo A apresenta todas as especificações técnicas do módulo de
comunicação ZigBee utilizado neste projeto.
3.2. UNIDADE REMOTA ZIGBUS (URZ) A Figura 12 apresenta a composição básica da Unidade Remota ZigBus
desenvolvida neste projeto que tem como função realizar a interface entre sensores
e atuadores industriais diversos e o módulo de comunicação ZigBee.
FIGURA 12 – Diagrama de blocos da Unidade Remota ZigBus (URZ)
28
Neste dispositivo eletrônico destacam-se as seguintes características:
• 03 (três) entradas analógicas de 0 a 20mA (miliampères), destinadas
ao uso de transmissores analógicos como medidores de
temperatura, pressão, vazão, nível, posição, entre outros;
• 03 (três) entradas digitais foto-acopladas destinadas a ligação de
sensores discretos como chaves fim-de-curso, chaves de fluxo,
sensores capacitivos, indutivos e foto-elétricos, entre outros;
• 03 (três) saídas digitais a relé para acionamento de atuadores
elétricos, válvulas solenóides, chaves contatoras, entre outros;
• Possibilidade de uso de módulos ZigBee de 2mW ou 50mW de
potência de transmissão RF;
• Circuito de proteção da entrada analógica que evita que
sobretensões nas entradas analógicas de até 30 volts danifiquem o
módulo ZigBee e demais componentes da unidade;
O funcionamento de cada um destes itens é apresentado a seguir e circuito
eletrônico completo da placa é apresentado no Anexo B.
3.2.1. Circuito de alimentação Cada URZ possui alimentação de 24 ±10% volts. Escolheu-se este nível
tensão por ser um padrão em equipamentos de uso industrial em diversos países.
Assim as fontes de alimentação elétrica disponíveis em painéis de instrumentação
serão compatíveis com as URZs.
O módulo ZigBee por sua vez, por ser de construção CMOS
(Complementary Metal-Oxide-Semiconductor), possui alimentação de 3,3 volts.
Para a redução no nível de tensão de alimentação da URZ (24 volts) para a
alimentação do módulo ZigBee (3,3 volts) foram utilizados dois reguladores de
tensão em cascata de 12 volts (U6) e 3,3 volts (U7) respectivamente, conforme o
circuito apresentado na Figura 13.
Ainda sobre o circuito de alimentação, cabem as seguintes informações:
• Os capacitores C16, C17 e C18 têm a função de filtro e são
recomendados pelos fabricantes dos reguladores de tensão;
• O LED (Light Emitting Diode – Diodo Emissor de Luz) D11 tem a
função de indicar quando a URZ está alimentada;
• O diodo D9 tem a função de proteção do circuito no caso de inversão
de polaridade na entrada de alimentação;
29
• Os fusíveis F1 e F2 têm a função de proteção da URZ caso circulem
correntes indevidas acima de 500mA.
FIGURA 13 – Circuito de alimentação das URZs
3.2.2. Entradas digitais As três entradas digitais existentes em cada URZ permitem que sinais de
tensão de 12 a 24 volts sejam detectados pelo módulo ZigBee como nível lógico 1.
Estas entradas são oticamente isoladas do módulo ZigBee, a fim de garantir sua
integridade no caso de sobretensões vindas do campo.
Na figura 14, temos o circuito elétrico da entrada digital projetada. Ao aplicar
uma tensão entre 12 e 24 volts entre os terminais 3 e 4, uma corrente limitada pelo
resistor R14 aciona o foto-transistor de uso geral U9, fazendo com que o nível de
tensão na entrada digital do módulo ZigBee passe de 0 (zero) para
aproximadamente 3,3 volts. Dessa forma, o módulo ZigBee passa a identificar a
alteração de nível lógico 0 para 1 em sua entrada digital.
O LED D29 tem a função de indicar quando a entrada digital está em nível
lógico 1, ou seja, quando há tensão entre os terminais da entrada. A corrente
necessária para o acionamento da entrada digital e que será fornecida pelo
instrumento ligado a esta não é superior a 5mA.
FIGURA 14 – Circuito das entradas digitais das URZs
30
3.2.3. Saídas digitais As URZs possuem três saídas digitais do tipo relé eletromecânico de contato
normalmente aberto, com capacidade de suportar correntes de até 2A. Estes relés
são acionados exclusivamente por comandos Modbus enviados pelo mestre da
rede.
Neste circuito (Figura 15), ao receber a instrução de acionamento de uma
saída digital, o módulo ZigBee eleva o nível de tensão no respectivo pino da saída
para 3,3 volts, permitindo que o transistor Q1 chaveie a alimentação da bobina do
relé K1. São os contatos deste relé que são disponibilizados para o acionamento de
dispositivos de campo através dos terminais 9 e 10.
O LED D16 é responsável por indicar quando o relé está energizado, ou
seja, quando a respectiva saída digital está em nível lógico 1.
O diodo D15 é usado para a proteção do circuito contra a tensão reversa
gerada no momento em que a bobina do relé é desenergizada. Os resistores R15,
R22 e R24 são utilizados como limitadores de corrente.
FIGURA 15 – Circuito das saídas digitais das URZs
3.2.4. Entradas analógicas O circuito ilustrado na Figura 16 converte o sinais de corrente de 0 a 20mA
provenientes medidores diversos (de pressão, nível, temperatura, entre outros) em
um sinal de tensão proporcional à corrente de entrada, que então é lido e
processado pelo conversor analógico-digital do módulo ZigBee.
A máxima tensão de conversão do módulo ZigBee é de 1,2 volts, desta
forma utilizou-se um resistor de 56 ohms (R11) em série com o loop de corrente
31
para que uma tensão proporcional a corrente de entrada seja gerada sobre este
resistor, variando de 0 a 1,12 volts. Esta tensão é então entregue a um dos pinos
de conversão analógico-digital do módulo ZigBee para a devida digitalização do
sinal.
A resolução do conversor analógico-digital é de 10 bits, o que significa que
sua resolução mínima é de 1,2 volts dividido por (210 - 1), ou seja, aproximadamente
1,17 milivolts. Para o resistor R11, o incremento de 1,17 milivolts corresponde a um
aumento de corrente de aproximadamente 0,02mA. Portanto, a resolução nominal
da entrada analógica projetada é de 0,02mA, o que é aceitável para a grande
maioria dos processos industriais de medição a partir de sinais 4-20mA.
No Capítulo 4, é apresentado a resposta do circuito de conversão analógico-
digital perante a injeção de sinais de 0 a 20mA.
3.2.4.1. Circuito de proteção A fim de proteger as entradas analógicas do módulo ZigBee contra
eventuais picos de tensão por descargas atmosféricas indiretas ou ligações
elétricas incorretas por parte do usuário, projetou-se um circuito capaz de
interromper o sinal de tensão no pino analógico-digital do módulo ZigBee quando a
tensão de entrada é próxima a máxima tensão suportada por este pino, que é de
3,3 volts. Esta proteção foi implementada a partir de um transistor MOSFET (Metal
Oxide Semiconductor Field Effect Transistor) Q2 que aciona a bobina do relé K2
quando a tensão de entrada entre os terminais 15 e 16 é superior a
aproximadamente 1,5 volts. Ao ser acionado, os contatos do relé K2 abrem o
circuito entre os terminais 15 e 16, cessando a circulação de corrente no circuito e a
tensão sobre o conversor analógico-digital, conforme apresentado na Figura 16.
Durante o curto período necessário para o acionamento dos contatos do relé
de proteção K2, o diodo zener D35 exerce a função de limitar a tensão no pino do
módulo ZigBee em 2,4 volts, fazendo com que o excedente de tensão fique sobre o
resistor R9.
O LED D13 é ligado quando o relé de proteção K2 é acionado, e tem a
função de alertar o usuário de que algo de errado está ocorrendo no sinal de
corrente gerado pelo transmissor em campo.
Ao retirar-se a condição de sobretensão entre os terminais 15 e 16, o
transistor Q2 entra em corte e, por conseqüência, o relé de proteção K2 é
desacionado, fazendo com que o circuito volte à condição normal de operação.
32
O diodo D12 é usado para a proteção do circuito contra a tensão reversa
gerada no momento em que a bobina do relé K2 é desenergizada. Já o diodo D10 é
utilizado no caso de inversão de polaridade entre os terminais 15 e 16.
No Capítulo 4, são apresentados os tempos de resposta do circuito perante
sobretensões de até 30 volts.
FIGURA 16 – Circuito de entrada analógica das URZs
3.2.5. Circuito do módulo ZigBee A Figura 17 apresenta o circuito elétrico montado ao redor do módulo
ZigBee.
A chave SW3 tem a função de reset na alimentação do módulo ZigBee e a
chave SW4 faz com que o módulo ZigBee envie um pacote de dados em broadcast
contendo sua identificação (endereço de 16 e 64 bits).
Os capacitores C19 e C20 são de recomendação do fabricante do módulo
ZigBee.
FIGURA 17 – Circuito do módulo ZigBee
33
3.3. BASE ZIGBUS (BZ) A Figura 18 apresenta o diagrama de blocos da Base ZigBus (BZ)
desenvolvida neste projeto que tem como função realizar a interface entre os
protocolos ZigBee e Modbus. Trata-se de um gateway que recebe instruções de um
mestre da rede Modbus através de uma porta serial RS-232; identifica para qual nó
da rede ZigBee o endereço Modbus requisitado corresponde; converte a
mensagem Modbus em uma requisição no padrão de comunicação ZigBee; envia a
requisição ZigBee para a rede sem fio; recebe a resposta ZigBee vinda da rede
sem fio (originada na Unidade Remota ZigBus correspondente à solicitação
Modbus); e finalmente converte a resposta ZigBee recebida em resposta Modbus,
para então, enviá-la ao mestre da rede Modbus. O fluxograma de operação
detalhado é apresentado nas Figuras 23 e 24.
A Base ZigBus é composta basicamente por um microprocessador modelo
RCM3000 RabbitCore do fabricante Digi International, cujo catálogo comercial
encontra-se no Anexo C, e um módulo ZigBee XBee ZB (o mesmo utilizado nas
Unidades Remotas ZigBus), também do fabricante Digi International.
As principais características que levaram à escolha deste microprocessador
foram:
• Operação em sistema multitarefa, o que permite maior agilidade no
processamento das informações;
• Plataforma de desenvolvimento gratuita (Software Dynamic C);
• Tensão de alimentação compatível com o módulo ZigBee (3,3 volts);
• Processador de alta capacidade – 29,4 MHz;
• Memória flash de programação de 512 Kbytes;
34
FIGURA 18 – Diagrama de blocos da Base ZigBus (BZ)
3.3.1. Programa O programa (ou software) desenvolvido para realizar o tratamento de dados
e interface entre os protocolos ZigBee e Modbus foi desenvolvido em Linguagem de
Programação C e compilado no microprocessador RCM3000 RabbitCore por meio
da plataforma de desenvolvimento Dynamic C. O programa utiliza 50 Kbytes de
memória do processador e possui cerca de 1200 linhas de comando,
desconsiderando as bibliotecas utilizadas.
O principal desafio na elaboração do programa foi criar rotinas de montagem
e desmembramento de pacotes de dados pertinentes a dois protocolos de
comunicação diferentes. Para isso foi necessário compreender cada tipo de
requisição e resposta de ambos os protocolos, com enfoque principal nas rotinas do
protocolo ZigBee devido à sua maior complexidade quando comparado ao
protocolo Modbus. O segundo desafio foi fazer com que o banco de dados fosse
capaz de armazenar informações das redes Modbus e ZigBee de forma acessível
aos dois protocolos.
A requisição e resposta de comandos realizados pelos módulos ZigBee
empregados neste projeto utilizam de estruturas de dados denominadas API
(Application Programming Interface ou Interface de Programação de Aplicativo).
Estas estruturas são definidas conforme a natureza da informação (requisição ou
resposta) que carregam. Para o programa de interface criado, foi utilizado um total
de quatro APIs diferentes, conforme descrito a seguir:
35
• API 0x08 (Figura 19): Requisição utilizada para requisição e escrita
de comandos de parametrização do módulo ZigBee, leitura e escrita
nos pinos de entradas/saídas e execução de comandos de rede.
Todas estas requisições devem ser feitas localmente, ou seja, o
comando deve ser recebido pela UART do módulo ZigBee objeto da
requisição.
FIGURA 19 – API de requisição de comandos locais [7]
• API 0x88 (Figura 20): Trata-se da resposta enviada pelo módulo
ZigBee ao receber uma requisição de API 0x08. Dentre as
informações contidas nesta estrutura, destaca-se o sucesso na
execução, ou não, da requisição recebida pelo módulo (Byte 5).
FIGURA 20 – API de resposta de comandos locais [7]
• API 0x17 (Figura 21): Requisição utilizada para requisição e escrita
de comandos de parametrização do módulo ZigBee, leitura e escrita
nos pinos de entradas/saídas e execução de comandos de rede. Sua
diferença para a API 0x08 é que, desta vez, a requisição é feita
remotamente, ou seja, a API possui em sua estrutura o endereço
ZigBee do módulo para o qual se deseja fazer uma requisição. Esta
36
é a API utilizada durante a requisição de leitura das entradas
analógicas e digitais das Unidades Remotas ZigBus, assim como os
comandos de escrita nas saídas digitais destas unidades. No
software desenvolvido, todo o comando Modbus válido é convertido
em uma API deste tipo.
FIGURA 21 – API de requisição de comandos remotos [7]
• API 0x97 (Figura 22): Trata-se da resposta enviada pelo módulo
ZigBee ao receber uma requisição de API 0x17. Dentre as
informações contidas nesta estrutura, destaca-se o sucesso na
execução, ou não, da requisição recebida pelo módulo (Byte 18).
FIGURA 22 – API de resposta de comandos remotos
37
3.3.2. Fluxograma O fluxograma apresentado na Figuras 23 e 24 a seguir, detalha a rotina de
operação do programa desenvolvido para interface entre os protocolos ZigBee e
Modbus.
38
Inicio
Configurações iniciais
Nova mensagem de requisçãoem protocolo MODBUS?
Sim
Não
A mensagem está correta?SimNão
Existe o endereço Zigbeede 16 e 64 bits doescravo solicitado?
SimNão
Solicita à rede Zigbee o endereçode 16 e 64bits do escravo desejado.
Resposta da rede Zigbee OK?
Prepara mensagem de erropara falha na solicitação do
escravo."SLAVE_DEVICE_FAILURE"
Salva os endereços de16 e 64 bits
SimNão
AB
Prepara mensagemde erro da solicitação.
"ILLEGAL_FUNCTION"
C
FIGURA 23 – Fluxograma de funcionamento do programa – Parte 1
39
B
Houve alguma falha narequisição do escravo?
Sim
Envia a mensagem na rede Zigbee.
Resposta ZigBeereportou erro?
Prepara mensagem de erropara falha na solicitação do
escravo "SLAVE_DEVICE_FAILURE"
Desmembra a resposta,salva os dados para
encaminhar a respostaao mestre em Modbus
NãoSim
Envia a mensagem de respostaao mestre da rede Modbus
A
Monta a mensagem do protocoloZigbee solicitando o comando
informado pela requisição Modbus.
Não
C
FIGURA 24 – Fluxograma de funcionamento do programa – Parte 2
40
3.3.3. Endereçamento Modbus A Tabela III apresenta as instruções Modbus criadas para leitura e escrita de
variáveis nas unidades remotas ZigBee. Cabe ressaltar que cada uma das URZs
possui um endereço único na rede Modbus, que é configurado previamente no
módulo ZigBee por meio do software X-CTU fornecido pelo fabricante Digi
International.
TABELA III – Acesso aos endereços Modbus das Unidades Remotas ZigBus
Endereço Modbus da
URZ Comando Descrição da
Entrada/Saída Endereço da
Entrada/Saída Definição Escala
Entrada Digital #1 0x0000
Entrada Digital #2 0x0001 0x02 - Leitura de bit (read discrete
inputs) Entrada Digital #3 0x0002
0 = Desacionado 1 = Acionado –
Saída Digital #1 0x0000
Saída Digital #2 0x0001
0x01 - Leitura de bit (read coils)
0x05 – Escrita de bit (write single
coil) Saída Digital #3 0x0002
0 = Desacionado 1 = Acionado –
Entrada Analógica #1 0x0000
Entrada Analógica #2 0x0001
0x01 – 0x7F
0x04 – Leitura de byte (read holding
registers) Entrada
Analógica #3 0x0002
0 – 2000d (0 – 20mA) 0,01
41
4. ENSAIOS 4.1. ANÁLISE DO CIRCUITO DE PROTEÇÃO DAS ENTRADAS
ANALÓGICAS Tomou-se como objetivo verificar o tempo de resposta e o nível de proteção
do circuito de proteção das entradas analógicas da Unidade Remota ZigBus
descrito na seção 3.2.4.1.
Primeiramente, verificou-se nível de tensão necessário para atuação do
circuito de proteção a partir de um aumento lento e gradativo da tensão entre os
terminais 15 e 16 da URZ (Figura 16).
Conforme registro do osciloscópio digital utilizado para os testes (Figura 25),
o disparo do circuito de proteção ocorreu quando a tensão no pino de conversão
analógico-digital do módulo ZigBee atingiu 1,5 volts (ou 1500mV), fazendo com que
o circuito fosse aberto, e a tensão extinta.
Considerando que a conversão analógico-digital no módulo ZigBee é
realizada até 1,2V e que o módulo suporta com segurança até 3,3 V, o circuito de
proteção mostrou-se eficiente neste teste.
FIGURA 25 – Tensão de disparo do circuito de proteção mediante aumento lento e
gradativo da tensão de entrada
Encontrado o primeiro ponto de disparo do circuito de proteção, verificou-se
a resposta deste circuito mediante a aplicação de tensões superiores ao limite
suportado pelo módulo ZigBee. Para este teste, foi utilizada uma chave comutadora
42
entre uma fonte de tensão e os terminais 15 e 16 da URZ. No momento da
comutação, a tensão registrada no pino de conversão analógico-digital deve-se
elevar instantaneamente até que o relé de proteção K2 atue, abrindo o circuito e
cessando a tensão no pino.
Foram simuladas a aplicação de quatro níveis de tensão diferentes nas
entradas analógicas da URZ e os resultados são apresentados nas Figuras 26, 27,
28 e 29, onde a linha 1 em cada imagem representa a tensão no pino do módulo
ZigBee e a linha 2 representa a tensão aplicada aos terminais 15 e 16 da Unidade
Remota ZigBus.
FIGURA 26 – Resposta do circuito de proteção mediante aplicação de tensão de 5
volts
FIGURA 27 – Resposta do circuito de proteção mediante aplicação de tensão de 10
volts
43
FIGURA 28 – Resposta do circuito de proteção mediante aplicação de tensão de 20
volts
FIGURA 29 – Resposta do circuito de proteção mediante aplicação de tensão de 30
volts
Notou-se que o circuito de proteção, embora tenha apresentado uma
velocidade de resposta bastante satisfatória para um sistema eletromecânico (de 4
a 5 milissegundos), teve sua tensão de disparo aumentada para cerca de 2,9 volts
quando aplicado 30 volts ao circuito. Notou-se ainda que esta tensão de disparo
diminui, conforme a tensão aplicada diminui.
A fim de garantir a integridade do módulo ZigBee, definiu-se que o circuito
de proteção do circuito é eficaz para sobretensões de até 30 volts.
Por último, verificou-se a resposta do circuito de proteção perante aumentos
repentinos e cíclicos no nível de tensão de entrada, que variou de 0 a 30 volts, em
uma frequência de aproximadamente 1Hz.
Conforme é possível notar na Figura 30, a tensão no pino do módulo ZigBee
(representada pela linha 1) teve como picos valores de tensão entre 1,5 e 1,8 volts,
44
Conforme é possível notar na Figura 30, a tensão no pino do módulo ZigBee
(representada pela linha 1) teve como picos valores de tensão entre 1,5 e 1,8 volts,
o que confirmou a eficiência do circuito de proteção para tensões de até 30 volts.
Os picos secundários de aproximadamente 1,4 volts ocorreram quando o nível de
tensão aplicado retornava de 30 para 0 volts; quando a tensão passa a ser menor
que o limite de atuação, o circuito é novamente estabelecido e passa a surgir
tensão novamente no pino de conversão analógico-digital do módulo ZigBee.
FIGURA 30 – Resposta do circuito de proteção mediante aumentos repentinos e
cíclicos no nível de tensão de entrada
4.2. RESPOSTA DO CONVERSOR ANALÓGICO-DIGITAL
A Tabela IV a seguir apresenta os resultados do teste de linearidade e
precisão realizados em uma das entradas analógicas da Unidade Remota ZigBus.
Para este teste, foi utilizado um gerador de corrente modelo UPS-III do fabricante
GE Druck conectado aos terminais 15 e 16 da URZ. O gerador foi calibrado por
laboratório credenciado a Rede Brasileira de Calibração (RBC).
Foram colhidos os dados de conversor analógico-digital do módulo ZigBee e
também a resposta da Base ZigBus quando requisitado o comando Modbus de
leitura da entrada analógica em teste.
45
TABELA IV – Resposta do conversor analógico-digital
Valor de Referência
[mA]
Módulo ZigBee - Conversor Analógico-Digital (faixa de trabalho: 0 – 1023)
Resposta Modbus para o comando de leitura da
entrada analógica em teste [mA]
Erro [mA]
0,000 0 0,00 0,00 4,000 186 3,96 - 0,04 8,000 375 7,99 -0,01
12,000 563 12,00 0,00 16,000 752 16,02 0,02 20,000 940 20,03 0,03
A Figura 31 apresenta o gráfico referente à Tabela IV, onde é possível
visualizar o desvio característico da entrada analógica projetada na Unidade
Remota ZigBus. Notou-se que o sistema, apresentou erro máximo de 0,04 mA com
relação à corrente de referência, o que representa apenas 0,2% da escala total da
entrada analógica e que se considerou aceitável para o objetivo do projeto.
0,00
4,00
8,00
12,00
16,00
20,00
0,000 4,000 8,000 12,000 16,000 20,000
Valor de Referência [mA]
Res
post
a M
odbu
s [m
A]
Resposta Modbus Valor de Referência
FIGURA 31 – Resposta da entrada analógica da Unidade Remota ZigBus
46
4.3. TESTE DO PROJETO
Neste teste, foi simulado o funcionamento do projeto como um todo, ou seja,
Unidades Remotas ZigBus comunicando-se com uma Base ZigBus, e esta última
conectada a um mestre de rede Modbus, de forma similar ao ilustrado na Figura 11.
Foi verificado o tempo de resposta da rede ZigBee e a capacidade de
processamento da Base ZigBus ao receber requisições contínuas para diferentes
escravos Modbus.
É importante ressaltar que este teste foi realizado em um laboratório e não
se procurou analisar as características de distância máxima de transmissão entre
os módulos ZigBee, pois entende-se que este tipo de teste deve ser realizado em
um ambiente industrial onde as condições de trabalho são mais agressivas devido
às diversas fontes de ruído para a transmissão de dados sem fio.
Para o teste, utilizou-se como mestre da rede Modbus o programa para
criação de sistemas supervisórios Elipse SCADA, do fabricante Elipse Software.
Este programa de computador possui uma interface de programação amigável e
permite a leitura e escrita de até dezoito variáveis Modbus em tempo real.
Foram utilizadas quatro URZs, onde em cada uma fez-se uso de uma
entrada analógica, uma entrada digital e duas saídas digitais, totalizando 16
endereços de variáveis para o programa supervisório. Na entrada analógica
utilizada em cada URZ foi conectado um gerador de corrente 0-20mA; na entrada
digital foi conectada uma botoeira de contato normalmente aberto; e as saídas
digitais foram utilizadas para o acionamento de chaves contatoras.
Conforme as premissas do protocolo Modbus, cada URZ, ou seja, cada
escravo da rede Modbus, recebeu um endereço diferente e dentro da faixa de
valores permitidos pelo protocolo (1 a 247). De forma aleatória, atribui-se a cada
URZ os endereços: 1, 2, 3 e 15.
A escrita do respectivo endereço Modbus foi feita no módulo ZigBee de cada
URZ a partir do programa X-CTU, disponibilizado pelo fabricante do módulo.
Finalizado o endereçamento dos escravos Modbus e a programação do
supervisório Elipse SCADA, distanciou-se as URZs em um raio de cerca de 5
metros da Base ZigBus, e cerca de 1 metro entre URZs.
Ao iniciar o aplicativo criado no supervisório para leitura e controle das URZs
(Figura 32), as requisições Modbus são enviadas à Base ZigBus que,
primeiramente, necessita conhecer os endereços ZigBee correspondentes a cada
47
endereço de escravo Modbus requisitado, conforme apresentado no diagrama de
funcionamento do software nas Figuras 23 e 24. O período necessário para este
reconhecimento da rede e criação da relação de endereçamento entre os
protocolos ZigBee e Modbus foi de aproximadamente 6 segundos. Passado este
período inicial, a comunicação entre supervisório e unidades remotas se mostrou
eficaz e sem falhas.
Desconsiderando, as mensagens de estouro de timeout apresentadas pelo
programa supervisório relativas ao período de inicialização do sistema comentado
no parágrafo anterior, o menor tempo encontrado para timeout da comunicação
Modbus no sistema em teste foi de 1000 milissegundos, o que se considerou
aceitável devido às características de rede do próprio protocolo ZigBee.
FIGURA 32 – Supervisório Elipse SCADA
48
5. CONSIDERAÇÕES FINAIS 5.1. CONCLUSÕES A proposta do projeto foi realizar a integração dos protocolos de
comunicação ZigBee e Modbus nos processos de automação industrial. Para tanto,
foi desenvolvida uma interface eletrônica entre os dois protocolos, e também
unidades eletrônicas remotas para aquisição e controle de variáveis de processo
com comunicação sem fio, por meio do protocolo ZigBee. Este desenvolvimento
mostrou que a integração entre os protocolos é possível e viável para aplicações
em automação industrial.
Os testes realizados nas unidades remotas desenvolvidas evidenciaram boa
resposta dos circuitos desenvolvidos para a interligação de equipamentos
característicos da automação industrial.
A principal conquista alcançada neste projeto foi permitir que a comunicação
entre dispositivos de monitoramento e controle de variáveis de processos industriais
sejam feitos por meio de tecnologia de transmissão de dados sem fio, a partir de
um protocolo de comunicação desenvolvido para aplicações industriais, porém, de
forma simples e rápida, pois se alcançou um nível de integração entre os protocolos
Modbus e ZigBee tal que a comunicação sem fio passou a ser somente um meio de
transmissão dos dados, não impactando nas rotinas já existentes do protocolo de
comunicação Modbus.
5.2. CONTRIBUIÇÕES Por ser o protocolo ZigBee um assunto ainda pouco difundido e estudado no
Brasil, este trabalho representa uma contribuição para aqueles interessados em
desenvolver soluções que utilizem este padrão.
A idéia da criação de interfaces entre protocolos já difundidos e protocolos
em ascensão pode facilitar a entrada de novas tecnologias no mercado, tornando
os processos de adaptação mais naturais.
5.3. PROPOSTA PARA TRABALHOS FUTUROS
• Testar o projeto desenvolvido com um maior número de unidades
remotas, dispondo-as no local de instalação de forma a forçar o
roteamento de dados entre módulos da rede, a fim de verificar os
49
tempos de resposta envolvidos nestes saltos e o impacto sobre a
comunicação Modbus;
• Testar confiabilidade e robustez a rede ZigBee em uma ambiente
tipicamente industrial, identificando todas as possíveis fontes de
interferência do sinal de radiofrequência e o impacto sobre a
qualidade na comunicação da rede sem fio;
• Otimização das rotinas do programa desenvolvido para uso de um
microprocessador de menor capacidade e menor custo.
50
6. BIBLIOGRAFIA
[1] CUTLER, Tim. Deploying ZigBee in existing industrial automation networks.
Revista Industrial Embedded Systems, St. Clair Shores, Michigan, EUA, n.1, p34-
36, outubro 2005.
[2] AAKVAAG, N.; MATHIESEN, M.; THONET, G. (2005). Timing and power issues
in wireless sensor networks - an industrial test case. In: IEEE 34th International
Conference Workshops on Parallel Processing. Oslo, Noruega: [s.n.], p. 419–426.
[3] JINDAL, S.; JINDAL, A.; GUPTA, N. (2005). Grouping wi-max, 3g and wi-fi for
wireless broadband. In: The First IEEE and IFIP International Conference in Central
Asia on Internet, 2005. Hyatt Regency Hotel, Bishkek, Kyrgyz Republic: [s.n.], p. 5.
[4] DIGI International. ZigBee Wireless Standard. Disponível em:
<http://www.digi.com/technology/rf-articles/wireless-zigbee.jsp>. Acesso em: 12
setembro 2009.
[5] FLOWERS, David, OTTEN, Yifeng, RAJBHARTI, Nilesh. Microchip Stack for the ZigBee Protocol. Disponível em:
<ww1.microchip.com/downloads/en/AppNotes/00965c.pdf>. Acesso em: 02
setembro 2007.
[6] SANTOS, Sergio Torres dos. Redes de sensores sem fio em monitoramento e controle. Universidade Federal Do Rio De Janeiro, 2007.
[7] DIGI International. XBee/Xbee-Pro ZB OEM RF Modules. Disponível em:
<http://ftp1.digi.com/support/documentation/90000976_a.pdf>. Acesso em: 11
outubro 2008.
[8] ONDREJ, S.; ZDENEK, B.; PETR, F.; ONDREJ, H. (2006). Zigbee technology
and device design. In: IEEE International Conference on Networking, International
Conference on Systems and International Conference on Mobile Communications
and Learning Technologies, ICN/ICONS/MCL. Mauritius: [s.n.], p. 129 – 129.
51
[9] ZIGBEE, a technical overview of wireless technology. Disponível em:
<http://zigbee.hasse.nl/>. Acesso em: 19 agosto 2009.
[10] DING, G.; SAHINOGLU, Z.; BHARGAVA, B.; ORLIK, P.; ZHANG;, J. (2005).
Reliable broadcast in zigbee networks. In: Second Annual IEEE Communications
Society Conference on Sensor and Ad Hoc Communications and Networks, 2005.
Santa Clara, California, USA: [s.n.], p. 510–520.
[11] STREETON, M.; STANFIELD, C. (2005). Zigbee: the telemetry solution? In:
The IEE Seminar on Telemetry and Telematics. Savoy Place, London, UK: [s.n.], p.
8/1 – 8/4.
[12] MATA, Rogério Souza da. Automação Industrial Wireless 2ª parte. Revista
Mecatrônica Atual, São Paulo, n.28, p38-42, jun./jul. 2006.
[13] NORDIC Semiconductor. Introduction to wireless network. Disponível em:
<http://www.nordicsemi.no/files/Product/white_paper/Introduction_to_wireless_netw
ork.pdf>. Acesso em: 19 de junho de 2005.
[14] ZIGBEE Alliance FAQ. Disponível em: <www.zigbee.org/en/about/faq.asp>.
Acesso em: 18 agosto 2007.
[15] AZEVEDO, Tiago. Roteamento ZigBee. Universidade Federal do Rio de
Janeiro. Disponível em:
<www.gta.ufrj.br/ensino/CPE825/2006/resumos/TrabalhoZigbee.pdf>. Acesso em:
12 setembro 2009.
[16] SILVA, Adelino, FELGUEIRAS, Mário. Protocolo de Comunicação MODBUS.
Disponível em:
<http://ave.dee.isep.ipp.pt/~malves/act_lect/RECIN/Trabalhos/RECIN_Modbus.pdf>
. Acesso em: 25 setembro 2008.
[17] FILHO, Constantino Seixas. Protocolos Orientados a Caracter. Disponível
em: <www.eletronica.org/arq_artigos/ProtocolosCaracterMBUS.pdf>. Acesso em:
21 setembro 2008.
52
[18] MODBUS. Disponível em: <http://www.cerne-tec.com.br/Modbus.pdf>. Acesso
em: 20 setembro 2008.
[19] IDOETA, I. V., CAPUANO, F. G. Elementos de Eletrônica Digital. 34.ed. São
Paulo. Editora Érica, 1998.
RABBIT Inc. 802.15.4 and ZigBee. Disponível em:
<http://www.rabbit.com/documentation/docs/articles/Demystifying-ZigBee-and-
802154.pdf>. Acesso em: 12 setembro 2009.
PINHEIRO, José Maurício Santos. As redes ZigBee. Disponível em:
<http://www2.eletronica.org/artigos/eletronica-digital/as-redes-com-zigbee>. Acesso
em: 18 Agosto de 2007.
DEITEL, M. D., DEITEL, Paul J. C++: Como Programar. 3.ed. Porto Alegre,
Bookman, 2001.
COZZO, Reinaldo. Tecnologia Industrial Wireless. Conceitos básicos. Revista
Mecatrônica Atual, São Paulo, n.38, p18-25 set./out. 2008
DIGI International. XBee ZigBee Addressing. Disponível em:
<http://www.digi.com/support/kbase/kbaseresultdetl.jsp?kb=191>. Acesso em: 12
setembro 2009.
DIGI International. XBee ZigBee Route Discovery and Network Address Discovery. Disponível em:
<http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=2192>. Acesso em: 12
Setembro 2009.
DIGI International. ZigBee Absolute Addressing. Disponível em:
<http://www.digi.com/support/kbase/kbaseresultdetl.jsp?id=2211>. Acesso em: 12
setembro de 2009.
53
VISÃO Geral dos Protocolos Modbus. Centro Federal de Educação Tecnológica do
Rio Grande do Norte. Disponível em: <http://www.cefetrn.br/~walmy/RI_A4.pdf>.
Acesso em 04 outubro 2008.
SOUZA, Vitor Amadeu. O Protocolo Modbus. Disponível em: <http://www.cerne-
tec.com.br/Modbus.pdf>. Acesso em: 04 outubro 2008.
54
7. ANEXOS
55
ANEXO A – Especificações do módulo XBee
56
ANEXO B – Circuito eletrônico da Unidade Remota Zigbus
57
ANEXO C – Catálogo comercial do microprocessador RCM3000
58
59
top related