Protocolos Modbus, Hart e

Wireless Hart

Brasília-DF.
Elaboração

Alex Estevão

Produção

Equipe Técnica de Avaliação, Revisão Linguística e Editoração

Sumário

APRESENTAÇÃO.................................................................................................................................. 5

ORGANIZAÇÃO DO CADERNO DE ESTUDOS E PESQUISA..................................................................... 6

INTRODUÇÃO.................................................................................................................................... 8

UNIDADE I
INTRODUÇÃO........................................................................................................................................ 9

CAPÍTULO 1
HISTÓRICO DE REDES INDUSTRIAIS............................................................................................. 9

CAPÍTULO 2
INTRODUÇÃO A REDES INDUSTRIAIS ........................................................................................ 17

CAPÍTULO 3
PROTOCOLOS DE REDES INDUSTRIAIS...................................................................................... 29

UNIDADE II
PROTOCOLO MODBUS......................................................................................................................... 37

CAPÍTULO 1
INTRODUÇÃO AO MODBUS .................................................................................................... 37

CAPÍTULO 2
CODIFICAÇÃO....................................................................................................................... 52

CAPÍTULO 3
ENDEREÇAMENTO E FUNÇÕES................................................................................................ 56

CAPÍTULO 4
FERRAMENTAS DE DIAGNÓSTICO E APLICAÇÕES .................................................................... 69

UNIDADE III
PROTOCOLO HART............................................................................................................................... 89

CAPÍTULO 1
INTRODUÇÃO AO HART .......................................................................................................... 89

CAPÍTULO 2
CODIFICAÇÃO..................................................................................................................... 108

CAPÍTULO 3
APLICAÇÕES E BENEFÍCIOS................................................................................................... 110
 CAPÍTULO 4
EQUIPAMENTOS INDUSTRIAIS HART.......................................................................................... 114

UNIDADE IV
PROTOCOLO WIRELESS HART.............................................................................................................. 120

CAPÍTULO 1
INTRODUÇÃO AO WIRELESS HART.......................................................................................... 120

CAPÍTULO 2
CODIFICAÇÃO..................................................................................................................... 131

CAPÍTULO 3
LIMITAÇÕES E SEGURANÇA................................................................................................... 136

CAPÍTULO 4
EQUIPAMENTOS INDUSTRIAIS HART.......................................................................................... 140

REFERÊNCIAS................................................................................................................................. 145
Apresentação

Caro aluno

A proposta editorial deste Caderno de Estudos e Pesquisa reúne elementos que se

entendem necessários para o desenvolvimento do estudo com segurança e qualidade.
Caracteriza-se pela atualidade, dinâmica e pertinência de seu conteúdo, bem como pela
interatividade e modernidade de sua estrutura formal, adequadas à metodologia da
Educação a Distância – EaD.

Pretende-se, com este material, levá-lo à reflexão e à compreensão da pluralidade

dos conhecimentos a serem oferecidos, possibilitando-lhe ampliar conceitos
específicos da área e atuar de forma competente e conscienciosa, como convém
ao profissional que busca a formação continuada para vencer os desafios que a
evolução científico-tecnológica impõe ao mundo contemporâneo.

Elaborou-se a presente publicação com a intenção de torná-la subsídio valioso, de modo

a facilitar sua caminhada na trajetória a ser percorrida tanto na vida pessoal quanto na
profissional. Utilize-a como instrumento para seu sucesso na carreira.

Conselho Editorial

5
 Organização do Caderno
de Estudos e Pesquisa

Para facilitar seu estudo, os conteúdos são organizados em unidades, subdivididas em

capítulos, de forma didática, objetiva e coerente. Eles serão abordados por meio de textos
básicos, com questões para reflexão, entre outros recursos editoriais que visam tornar
sua leitura mais agradável. Ao final, serão indicadas, também, fontes de consulta para
aprofundar seus estudos com leituras e pesquisas complementares.

A seguir, apresentamos uma breve descrição dos ícones utilizados na organização dos
Cadernos de Estudos e Pesquisa.

Provocação

Textos que buscam instigar o aluno a refletir sobre determinado assunto antes
mesmo de iniciar sua leitura ou após algum trecho pertinente para o autor
conteudista.

Para refletir

Questões inseridas no decorrer do estudo a fim de que o aluno faça uma pausa e reflita
sobre o conteúdo estudado ou temas que o ajudem em seu raciocínio. É importante
que ele verifique seus conhecimentos, suas experiências e seus sentimentos. As
reflexões são o ponto de partida para a construção de suas conclusões.

Sugestão de estudo complementar

Sugestões de leituras adicionais, filmes e sites para aprofundamento do estudo,

discussões em fóruns ou encontros presenciais quando for o caso.

Atenção

Chamadas para alertar detalhes/tópicos importantes que contribuam para a

síntese/conclusão do assunto abordado.

6
Saiba mais

Informações complementares para elucidar a construção das sínteses/conclusões

sobre o assunto abordado.

Sintetizando

Trecho que busca resumir informações relevantes do conteúdo, facilitando o

entendimento pelo aluno sobre trechos mais complexos.

Para (não) finalizar

Texto integrador, ao final do módulo, que motiva o aluno a continuar a aprendizagem

ou estimula ponderações complementares sobre o módulo estudado.

7
 Introdução

Pode-se dizer que a precursora na implementação e desenvolvimento das redes

industriais foi a indústria automobilística. O objetivo inicial era minimizar custos e
melhorar a efetividade de seus processos.

Diante da enorme demanda na fabricação de automóveis, foi necessário investir

em tecnologia, a fim de otimizar suas linhas de produção, diminuindo gastos e
melhorando o controle e efetividade dos processos. Em concordância com este
cenário, as indústrias farmacêuticas e as de bens de consumo também iniciaram o
processo de automatização de suas linhas de produção.

Vislumbrando o enorme potencial comercial que este mercado demonstrava,

muitas empresas da área de automação iniciaram o desenvolvimento de novos
produtos e soluções para atender aos novos conceitos e necessidades do chão de
fábrica. Dessa forma, foi-se então configurando as diversas modelagens de redes
industriais que conhecemos, dentre elas uma das pioneiras e que estudaremos
nesta disciplina, a rede AS-interface.

Figura 1. Protocolos de redes industriais.

Fonte: Mckautomacao. Disponível em: <http://www.mckautomacao.com.br/images/redesindustriais/img1.png>.

Objetivos
» Introdução a redes industriais.

» Protocolo Modbus.

» Protocolo Hart.

» Protocolo Wireless Hart.

8
 INTRODUÇÃO UNIDADE I

CAPÍTULO 1
Histórico de redes industriais

Histórico de redes
Todo o princípio de uma rede de comunicação se baseia na descoberta – e posterior
evolução – dos computadores e sistemas industriais. De modo geral, os primeiros
computadores eram máquinas grandes, complexas e caras que necessitavam de
ambientes grandes, isolados e com temperatura controlada para sua instalação.

Eram máquinas tão complexas que só poderiam ser operadas por especialistas,
e sua programação era feita por meio da inserção de cartões perfurados os quais
a máquina interpretava e executava a programação. A Figura 2 ilustra um dos
primeiros computadores digitais, o ENIAC (1946).

Figura 2. Computador ENIAC.

Fonte: <https://unicamania.com.br/images/canais/primeira-vez/2107/mai/05/eniac-principal.jpg>.

9
 UNIDADE I │ INTRODUÇÃO

Para maiores informações sobre o ENIAC, veja o vídeo “A história do

ENIAC – TecMundo”, do TecMundo, disponível em: <https://www.
youtube.com/watch?v=dy0wpDfnpzo>.

Na década seguinte, nos anos 1960, os computadores continuaram sua evolução,

permitindo, assim, que os usuários pudessem conectar-se aos computadores por
meio de terminais. Para esta conexão, eram necessárias técnicas de comunicação
de dados com os computadores de processamento central. Com isso, dá-se início às
redes de comunicação de dados. A Figura 3 ilustra um sistema utilizado na época
denominado de MultiUser, o terminal Televídeo 925.

Figura 3. Televídeo 925.

Fonte: Cnblogs. Disponível em: <https://images0.cnblogs.com/blog/564490/201501/151523326048605.jpg>.

Ainda na década de 1960, inúmeros esforços e definições foram realizados a fim

de concretizar a evolução das redes de comunicação de dados. Podemos destacar
alguns pontos marcantes desta década, como:

» Melhora da interação entre computador e usuários.

» Surgimento de técnicas de time-sharing, primeiros sistemas

multiusuários.

» Conexão de usuários ao computador central por meio de terminais.

Nas comunicações entre terminais e o computador central, foram definidos:

» Interface (serial, paralela), conectores, cabos etc.

» Definição de unidade básica de informação bit (binary unit).

10
 INTRODUÇÃO │ UNIDADE I

» Definição de duração de sinais 0 e 1, sincronização.

» Definição de códigos para representar letras, números e outros

símbolos alfanuméricos, ASCII, EBCDIC.

» Definição de protocolos para envio, recepção, detecção de erros etc.

Dessa forma, por meio destas definições realizadas, na década de 1960 surgiram
as primeiras técnicas de comunicação de dados. A partir da década seguinte,
nos anos 1970, com o advento dos microprocessadores, houve uma evolução nos
computadores, de forma a se tornarem muito mais baratos e por consequência
muito mais acessíveis, dessa forma caracterizando uma difusão no seu uso.
Algumas evoluções e características a partir de então:

» Desenvolvimento de computadores, pelas grandes indústrias, cada

vez mais velozes, de menor tamanho e preço mais acessível.

» Incremento na capacidade de cálculo e armazenamento.

» Aplicações cada vez mais complexas requeriam computadores cada vez

mais poderosos, impulsionando, assim, a indústria eletro/eletrônica
ao desenvolvimento de novos modelos.

» Concepção de sistemas de informação distribuídos a fim de melhorar

o desempenho do sistema (menor custo).

» Aparecia a necessidade de desenvolver técnicas para interconexão

de computadores, redes de dados.

» Informatização crescente nas empresas, assim como os sistemas de

bancos de dados extremamente úteis para a época.

» Os primeiros setores a serem informatizados eram o de finanças,

folha de pagamento, compras, vendas, setor de pessoal.

» Posteriormente, a informatização do chão de fábrica por meio das

CNCs, CLPs, RC, IC, sistemas de aquisição de dados, sensores e
atuadores microprocessados etc.

Dessa forma, permitiu-se a abertura para a concepção de desenvolvimentos de

novas técnicas e sistemas de comunicação de dados, principalmente referenciadas
as redes industriais de chão de fábrica.

11
 UNIDADE I │ INTRODUÇÃO

“Informação” atualmente é a palavra-chave em empresas de qualquer setor, assim

como no ramo industrial, também influenciado pelos avanços nas tecnologias de
transmissão de dados. A integração entre os diversos níveis de equipamentos
e sistemas de controle tem se tornado essencial para se alcançar o aumento de
eficiência, flexibilidade e confiabilidade dos sistemas produtivos.

As redes industriais são essencialmente sistemas distribuídos, ou seja, diversos

elementos que trabalham de forma simultânea a fim de supervisionar e controlar
um determinado processo. Tais elementos (sensores, atuadores, CLPs, CNCs,
PCs etc.) necessitam estar interligados e trocando informações de forma rápida
e precisa, haja vista que o ambiente industrial é geralmente hostil, de maneira
que os dispositivos e equipamentos pertencentes a uma rede industrial devem ser
confiáveis, rápidos e robustos.

Um contrassenso entre tecnologias abertas ou não é que, atualmente, os fabricantes

de sistemas de integração industrial tendem a lançar produtos compatíveis
com sua arquitetura própria, o que leva a graves problemas de compatibilidade
entre as diversas redes e sub-redes presentes nos sistemas, em diversos níveis,
equipamentos, dispositivos, hardware e software. Essa é a vantagem das
arquiteturas de sistemas abertos, que tendem a seguir padrões, de maneira que o
usuário pode encontrar diversas soluções diferentes para o mesmo problema.

Fazendo um paralelo entre os sistemas de controle antigos – aqueles mencionados

anteriormente no início deste capítulo – com relação aos sistemas de redes
industriais modernos, podemos dizer que os sistemas de controle tradicional
se caracterizavam por possuír alto custo de instalação, manutenção, ampliação,
projeto e cabeamento.

Para minimizar esses custos, foi introduzido o conceito de rede de comunicação

digital, possibilitando:

» Menores custos de instalação.

» Melhores procedimentos de manutenção.

» Opções de upgrades.

» Informação de controle de qualidade.

» Informações de instrumentos para manutenção.

» Configurações dos instrumentos à distância etc.

12
 INTRODUÇÃO │ UNIDADE I

Para maiores informações sobre o terminal e sua relação com o computador

principal, leia o artigo “O que é o terminal? (ou, venha conhecer a tela
preta!)”. Disponível em: <https://www.programaria.org/o-que-e-o-terminal-
ou-venha-conhecer-tela-preta/>.

Evolução das redes

Para que seja possível a realização de um controle industrial por meio de

qualquer tipo de rede industrial, alguns componentes como sensores, chaves fim
de curso, válvulas, motores, variáveis analógicas provenientes de transdutores
de temperatura, entre outros, precisam estar interligados aos CLPs, PCs, SDCD
etc. A Figura 4 ilustra um CLP da Modicom, imaginado pela General Motors em
alternativa definitiva para os sistemas de controle a relés.

Figura 4. Primeiro CLP.

Fonte: microcontrollertips . Disponível em: < https://rh6stzxdcl1wf9gj1fkj14uc-wpengine.netdna-ssl.com/wp-content/

uploads/2019/01/WHTH_FAQ_PLCs_Pt2_Fig3-1.png >.

Quando qualquer máquina ou processo é automatizado utilizando uma

arquitetura pré-estabelecida, chamamos esse sistema de centralizado, pois todos
os dispositivos no campo estarão ligados fio a fio nesse painel, formando uma
ligação paralela.

Com a evolução dos cartões de comunicação de um CLP, foi possível aumentar

a efetividade de componentes monitorados nos processos industriais. A figura 5
ilustra um CLP atual composto por diversos módulos de comunicação.

13
 UNIDADE I │ INTRODUÇÃO

Figura 5. CLP atual.

Fonte: Igsautomação. Disponível em: <https://www.lgsautomacao.com.br/wp-content/uploads/2016/11/CLP-Ge-Fanuc-01-1.

png>.

Com o passar dos anos, a automação foi evoluindo juntamente com o número
de pontos (número de elementos de entrada e saída) de uma aplicação. Para
uma automação centralizada, isso começa a representar um problema, pois
aumentando o número de pontos aumenta-se também:

» O dimensional do painel elétrico.

» O número de fios e multicabos entrando no painel.

» Erros nas ligações dos fios.

» Espaço físico onde os painéis estão instalados etc.

Para contornar esses problemas, foi realizada a descentralização das placas de

entrada e saída de um CLP, ou seja, foram retiradas do rack do CLP as placas
que causam a maior concentração de pontos do sistema, permanecendo apenas
a fonte, a CPU e também uma placa responsável por converter os dados que
provêm serialmente do campo e disponibilizá-los para o CLP. Dessa forma,
estava nascendo o conceito Fieldbus, um sistema serial para a troca de dados
entre o campo e o CLP. A Figura 6 ilustra essa evolução na automatização de
redes industriais.
Figura 6. Conceito Fieldbus.

HSE

Fieldbus Controller

PV, Mode, Variables, Alarm

Diagnostic etc
H1

Fieldbus Multiple Variables (Both Directions)

Fonte: Automationforum. Disponível em: <https://automationforum.co/wp-content/uploads/2018/03/ff4-434x385.jpg>.

14
 INTRODUÇÃO │ UNIDADE I

Juntamente com este novo conceito de rede industrial, também surgiram alguns
problemas com o crescente uso desse sistema. Como existiam vários fabricantes de
CLPs e milhares de fabricantes de dispositivos de entrada e saída, fez-se necessário
criar uma padronização para as redes industriais.

No ano 2000, foi definida uma norma na tentativa de se padronizar as redes de

automação industrial, norma IEC 61158, que padroniza oito protocolos de redes
distintos, sendo eles:

» Tipo 1: FOUNDATION Fieldbus H1.

» Tipo 2: Controlnet.

» Tipo 3: PROFIBUS.

» Tipo 4: P-Net.

» Tipo 5: FOUNDATION Fieldbus HSE (High Speed Ethernet).

» Tipo 6: Interbus.

» Tipo 7: SwiftNet.

» Tipo 8: WorldFIP.

Mesmo com estes padrões, não foi possível abranger todas as aplicações na
indústria. Mais tarde, então, foi criada a IEC 61784, com uma definição dos
chamados “profiles”, e também foram corrigidas as especificações IEC 61158. O
Quadro 1 ilustra os padrões e seus respectivos “profiles”.

Quadro 1. Padrões e protocolos de acordo com a IEC 61784 e a IEC 61158.

IEC 61784 IEC 61158

MEIO FISICO DATA LINK LAYER
CPF-1/1 TIPO 1 TIPO 1 FUNDATION FIELDBUS (H1)
CPF-1/2 ETHERNET TCP/UDP/IP FUNDATION FIELDBUS (HSE)
CPF-1/3 TIPO 1 TIPO 1 FUNDATION FIELDBUS (H2)
CPF-2/1 TIPO 2 TIPO 2 CONTROL NET
CPF-2/2 ETHERNET TCP/UDP/IP ETHERNET/IP
CPF-3/1 TIPO 3 TIPO 3 PROFIBUS-DP
CPF-3/2 TIPO 1 TIPO 3 PROFIBUS-PA
CPF-3/3 ETHERNET TCP/UDP/IP PROFINET
CPF-4/1 TIPO 4 TIPO 4 P-NET RS-485
CPF-4/1 TIPO 4 TIPO 4 P-NET RS-232

15
 UNIDADE I │ INTRODUÇÃO

IEC 61784 IEC 61158

MEIO FISICO DATA LINK LAYER
CPF-5/1 TIPO 1 TIPO 7 WORLDFIP (MPS, MCS)
TIPO 1 TIPO 7 WORLDFIP (MPS, MCS, sub
CPF-5/2
MMS)
CPF-5/3 TIPO 1 TIPO 7 WORLDFIP (MPS)
CPF-6/1 TIPO 8 TIPO 8 INTERBUS
CPF-6/2 TIPO 8 TIPO 8 INTERBUS TCP/IP
CPF-6/3 TIPO 8 TIPO 8 INTERBUS SUBSET
CPF-7/1 TIPO 6 TIPO 6 SWIFTNET TRANSPORT
CPF-7/2 TIPO 6 TIPO 6 SWIFTNET FULL STACK
Fonte: Elaborada pelo autor.

Apenas a título de curiosidade, a composição do mercado atual de redes industriais

está distribuída entre Europa x EUA (Siemens x Rockwell – maiores fabricantes
mundiais no segmento de redes industriais).

» Siemens: Profibus DP/PA e Profinet.

» Rockwell: DeviceNet e Ethernet/IP.

Para maiores informações sobre o IEC 61784 e IEC 61158, leia o artigo “The
Fieldbus Standards: History and Structures” escrito por Max Felser. Disponível
em: < https://www.felser.ch/papers/FE-TR-0205.pdf>.

Leia tambem o artigo “O que é PROFIBUS?”. Disponível em: < https://www.

smar.com/brasil/profibus>.

16
CAPÍTULO 2
Introdução a redes industriais

Introdução
Para que seja possível uma comunicação entre computadores, é necessário que
algumas regras sejam estabelecidas. Esse conjunto de normas e padrões que
definem como se dará esse contato é conhecido como protocolos de comunicação.

Assim, os protocolos de comunicação são um conjunto de normas que permitem

que dois ou mais dispositivos conectadas a uma rede se comuniquem entre
si. Funciona como uma linguagem universal, que pode ser interpretada por
dispositivos de qualquer fabricante, por meio de qualquer sistema operacional.

Eles são responsáveis por pegar os dados transmitidos pela rede e dividi-los em
pequenos pedaços, que são chamados de pacotes. Cada pacote carrega em si
informações de endereçamento de origem e destino. Os protocolos também são
responsáveis pela sistematização das fases de estabelecimento, controle, tráfego e
encerramento.

Existem três elementos-chave que definem os protocolos de rede. São eles:

» sintaxe: representa o formato dos dados e a ordem pela qual eles são
apresentados;

» semântica: refere-se ao significado de cada conjunto sintático que dá

sentido à mensagem enviada;

» temporização: define uma velocidade aceitável de transmissão dos

pacotes.

Ao mesmo tempo, pensava-se que as redes de automação industrial eram

diferentes dos tipos de redes usadas para TI. De fato, as primeiras redes de
automação nem sequer eram consideradas redes, e sim barramentos seriais.
O termo Fieldbus decorre desses pensamentos. Naturalmente, cada rede foi
projetada para resolver um problema, depois estendida para resolver outro,
talvez relacionado. O modelo foi direcionado para um nicho de negócios um
pouco distinto, o barramento resultante acabou sendo diferente de qualquer
outro.

17
 UNIDADE I │ INTRODUÇÃO

As redes de automação industrial, sendo lentas e sem complicações, fez com

que nenhum componente especial fosse necessário. EIA-232,1 EIA-422/423 e
EIA-485, por exemplo, eram frequentemente usados para as camadas físicas,
suportados por semicondutores de commodities. Os protocolos anteriores eram
simples o suficiente para serem executados em microprocessadores 8 bits como o
8051, Z80 ou 6809. Quando a velocidade ficou mais alta e os protocolos ficaram
mais ricos em funcionalidade, tornou-se necessário o silício personalizado para
implementar essas redes. O design de chip personalizado é caro e, como os
volumes são pequenos em comparação com volumes de chips de mercado, são
caros de fabricar.

Figura 7. Microprocessador Z80.

Fonte: Z80. Disponível em: <http://www.z80.info/gfx/z0840004.jpg>.

A primeira abordagem para corrigir esse problema foi padronizar redes de

automação industrial através de comitês de padrões ou o estabelecimento de
padrões de fato, abrindo as especificações para comitês de múltiplos fornecedores.
A teoria era que se muitos fornecedores de sistemas usassem o mesmo chip,
haveria economia de escala e menor custo de fabricação.

A tendência é claramente esconder a ideia de que as redes de automação industrial

são de alguma forma diferentes das redes de TI. Uma tendência clara é usar
componentes comerciais prontos para uso e adaptá-los por meio de software
para aplicação de automação industrial. Como a Ethernet foi a vencedora clara
no mercado do setor de TI, não é surpresa que ela seja a base para as mais
novas evoluções das redes de automação industrial, pelo menos na parte de
alto desempenho. As redes de nível mais baixo usadas para conectar sensores
e atuadores têm uma solução diferente. Essas redes também estão migrando
e convergindo. Algumas redes de baixo nível provavelmente usarão versões
reduzidas das redes de automação industrial de alto desempenho, enquanto
outras usarão chips de baixo custo desenvolvido para outros mercados.

18
 INTRODUÇÃO │ UNIDADE I

Finalmente, deve ser óbvio agora que qualquer discussão sobre redes de automação
industrial deve considerar o software usado para a camada do nível superior,
visível ao usuário final. Todas as arquiteturas de rede são descritas pelas normas
ISO e o modelo de referência básico OSI (Open System Interconnection), padrão
ISO/IEC 7498-1:1994. Este modelo é ilustrado na figura 8 e é dividido em sete
partes. Quando dizemos protocolo de rede, estamos falando sobre coisas nessas
camadas. O usuário final se preocupa apenas com o conexão com a camada
física (fios saindo pela parte inferior, sinais de rádio) e os recursos e funções
disponibilizados no topo. O protocolo se encarrega de levar a informação de uma
ponta a outra.

Figura 8. Camadas de rede.

Interação da Camada de Rede

Computador Computador
Enviando recebendo
Aplicação para
Aplicação para
interação de rede Aplicação Aplicação interação de rede
interaction

Compactação e C
Compactação e
sequência de Apresentação Apresentação
sequência de
se
dados dados
Gerenciar
abertura e Gerenciar
/fechamento de
Sessão Sessão negociação de
conexão conexão

Encapsulamento Transporte Transporte Avalia porta de

porta de destino destino

Endereço de rede Avalia

Encapsulation Rede Rede endereço de
rede

Encapsulamento
Avalia
endereço de Data Link Data Link endereço de
hardware
Transferência hardware
de dados
Física Física

Fonte: Pinimg. Disponível em: <https://i.pinimg.com/originals/7f/97/b9/7f97b946cc5c4203a50e38ff0952e126.jpg>.

Observe que existem duas camadas acima das sete camadas ISO/OSI. O objeto
vinculado e incorporado para controle de processo (OCP) tem o benefício de
adaptar as camadas da rede ao sistema host. Assim, a camada de usuário do
cliente só precisa ser criada sabendo que será usada com um servidor executando
o software OCP compatível. Com o OCP, os detalhes das camadas de rede são
efetivamente ocultas. Também deve ser observado que existem outros métodos de

19
 UNIDADE I │ INTRODUÇÃO

isolar a camada de aplicativo de rede do software da camada de usuário usando

outras tecnologias, incorporadas na camada do usuário, que não usam OCP. Isso
é ilustrado pelo acoplamento direto da camada do usuário para o topo da pilha
do protocolo de comunicação. Geralmente, isso é para tirar proveito da eficiência
das conexões da camada de usuário e tornar as transferências de dados mais
determinísticas do que o permitido pelo OCP.

Finalmente, a ligação da rede é desenhada como uma seta entre emissor e o

receptor. Essa seta representa a rede física como mais do que apenas fios e cabos.
Muitas vezes, existem comutadores e conversores ativos nessas redes por vários
motivos que não discutiremos aqui. A palavra cabo é frequentemente usada, pois
inclui fiação metálica e fibra ótica. Também deve incluir conexões sem fio.

A seguir, serão apresentados os tipos genéricos de redes usados no automação

industrial.

Rede de sensores

No nível mais baixo da funcionalidade de rede estão os sensores de redes.

Geralmente, os próprios sensores estão na parte inferior da cadeia de valor do
sistema de automação industrial e são projetados para serem baratos, pois muitos
sensores (e atuadores também) são necessários para aplicativos típicos. Sensores
fornecem dados para o sistema de controle, como a presença de um objeto ou
propriedade física como temperatura. Seus mecanismos variam de acordo com a
precisão e confiabilidade desejadas.

O sensor mais simples é o fim de curso eletromecânico usado para indicar que um
objeto está presente ou não. Por exemplo, chaves fim de curso frequentemente
são usadas para detectar caixas em uma esteira que passam por uma estação de
leitura. Eles também são usados no controle de válvulas para indicar quando
elas estão totalmente abertas ou totalmente fechadas. Os interruptores de limite
devem ser energizados (às vezes chamados de polarizados) para detectar a
posição do interruptor aberto/fechado. Quando usado com um CLP, cada chave
fim de curso normalmente requer dois fios para conectar-se às terminações de
entrada e saída (E/S) em uma placa de entrada digital ou interface do módulo de
terminação conectada a um slot em um multiplexador, geralmente chamado de
E/S remota ou unidade de E/S de bloco. Esses valores digitais são normalmente
relatados ao controlador como um bit em um registro de entrada.

20
 INTRODUÇÃO │ UNIDADE I

Outras tecnologias usadas para detectar a posição são fotocélulas e detectores de

proximidade. Ambas as tecnologias são um pouco mais caras que os interruptores
de limite, mas fornecem mais informações do que a posição do interruptor ligado
ou desligado (ON/OFF). No entanto, eles não têm peças móveis e geralmente
têm uma vida útil mais longa. As fotocélulas requerem uma fonte de luz além
do detector sensível à luz. Os detectores de proximidade podem ser magnéticos
e não requerem fonte de energia separada para detectar objetos de ferro ou
aço (magnéticos). Quando o objeto é composto de elementos não magnéticos
materiais, como papel, plástico ou alumínio, uma fonte de energia é usado para
gerar um campo indutivo que será modificado pela massa do objeto que pode ser
detectada.

As redes de sensores são projetadas para reduzir a fiação ponto a ponto necessária
para conectar a chave limitadora, o sensor de proximidade, a válvula solenoide ou a
fotocélula à interface de E/S. Isso é feito em de duas maneiras:

» coloque um driver de rede dentro do próprio sensor ou atuador; ou

» aproxime a interface de E/S do sensor ou atuador para que as

conexões sejam muito curtas.

Existem produtos no mercado que fazem isso nos dois sentidos. A interface de
E/S normalmente possui de 4 a 16 pontos de E/S e está conectada ao CLP ou
outro tipo de controlador pela rede de sensores que transmite dados digitais
para todos os pontos.

A E/S da rede do sensor detecta eletricamente os estados do sensor e o converte

em 1 ou 0 em uma palavra de status. A palavra status é depois transmitida pela
rede para um dispositivo de terminação chamado de scanner que geralmente
está em um rack de E/S remota, um PLC ou um computador. O scanner é
responsável pela montagem da palavra de status de cada nó de E/S da rede
de sensores em um registro no dispositivo. Cada rede de sensores possui seu
próprio método para mapear o status do sensor para os registros de E/S. O
fator distintivo das redes de sensores é que o sensor, atuador e rede nó não
fazem nada além de converter o estado do sensor ou do atuador de ou para a
palavra de status da rede. Nenhum condicionamento do sinal ou qualquer outro
cálculo é fornecido. A maioria das redes de sensores é projetada para transmitir
energia para os sensores para que seu status atual possa ser detectado sem uma
fonte de energia separada para cada dispositivo. Na maioria dos casos, há um
módulo no nó de E/S da rede que permite a terminação de mais de um ponto
de E/S. Normalmente, isso é conveniente, pois os sensores são frequentemente

21
 UNIDADE I │ INTRODUÇÃO

agrupados juntos em torno de um equipamento comum. Algumas redes de

sensores são conectadas em uma série ou multiponto topologia que reduz
ao máximo o cabeamento. Outras redes de sensores são conectadas em uma
topologia em estrela para reduzir atrasos na latência da transmissão de dados.
Outras redes de sensores, ainda, são conectadas em uma topologia em anel para
confiabilidade da rede. A Figura 9 ilustra essas e outras topologias de rede.

Figura 9. Topologias de rede.

Ring Mesh Star Fully Connected

Line Tree Bus

Fonte: Proeminente. Disponível em: <https://www.proeminente.com.br/thumb.php?w=750&h=370&src=midia/news/21cbad83

6799937a7456d3c7a8842b1c.png>.

Rede de sensores wireless

Grande parte do custo de instalação de redes com fio é para o cabeamento

propriamente. Instalação do cabeamento em um ambiente de fábrica é caro.
A conclusão é eliminar os fios usando as redes de sensores wireless (RSW). A
topologia natural de uma RSW é a malha, como ilustrado na figura 10. Observe
que os sensores de uma malha também servem como hubs de comunicação
para dispositivos que estão fora do rádio alcance para alcançar o gateway ou o
dispositivo host. Observe também que pode haver caminhos alternativos entre
dois dispositivos. Essas são algumas das vantagens da RSW.

Também possui custos não associados a fios e fibra ótica. A capacidade de

transmitir e receber dados por um link de rádio (sem fio) nem sempre funciona
com o mesmo grau de certeza como um link com fio. Condições atmosféricas
como chuva, nevoeiro ou neve podem afetar drasticamente a transmissão de
sinais sem fio. Outro problema pode ser atribuído aos “cânions de aço”, um termo
que descreve muitas plantas de processo e até fábricas. Quando sinais de rádio
refletem em equipamentos de aço, sinais que atingem dispositivos remotos devem
percorrer uma longa distância em vez do caminho direto. Isso é chamado de sinal

22
 INTRODUÇÃO │ UNIDADE I

de caminhos múltiplos e faz com que o sinal que percorre o caminho mais longo
saia da fase com o sinal direto, resultando em um cancelamento de sinal que é
frequentemente chamado de desbotamento. A instalação da RSW deve levar em
consideração o caminho múltiplo e a capacidade dos sinais a serem recebidos.

Figura 10. Redes de sensores sem fio.

Wireless Sensor Network

Point-to-Point

Mesh Network

Star Network
Fonte: Scientechworld. Disponível em: <https://www.scientechworld.com/blog/wp-content/uploads/communication-network.
jpg>.

Rede Fieldbus

O Fieldbus originalmente foi padronizado pelo ISA como ANSI/ISA50.02 a

partir de 1992, com a especificação final publicada em 1998. A versão de controle
de processo deste padrão foi usada como base da especificação H1 da Fieldbus
Foundation (agora chamado de grupo FieldComm). Em submissão ao IEC para
os padrões internacionais, houve muita controvérsia e debate, levando à adoção
de mais sete opções de arquitetura de rede em sua norma IEC 61158, publicada
pela primeira vez em 2000. Esta norma IEC define o termo Fieldbus. O escopo
do Fieldbus inclui todas as redes projetadas para instalação na fábrica ou no
chão de fábrica e nas quais há distribuição de inteligência programável em
cada nó da rede. Portanto, essa classificação inclui todas as redes classificadas
anteriormente como barramentos de dispositivos.

Muitas vezes, é necessário medir a posição de um objeto mais precisamente do

que presente ou ausente. O dispositivo de medição de posição mais simples é
um transformador diferencial variável linear (LVDT) ou, quando o movimento

23
 UNIDADE I │ INTRODUÇÃO

rotativo é usado, um transformador diferencial variável rotativo (RVDT).

Esses dispositivos são transformadores que, quando influenciados por uma
corrente CA, medem o movimento com precisão como uma relutância variável
proporcional à posição. A relutância é então convertida em um valor digital para
ser usado pelo controlador. Os CLPs geralmente relatam valores como a saída
do conversor analógico-digital (A/D) que ocupa um local de registro. Outros
dispositivos, como síncronos, são usados para medir a posição ou o movimento
rotativo de maneira semelhante. Os codificadores ópticos fornecem a posição
rotativa como um sinal digital baseado em um disco codificado (encoder) que
gira com o eixo do instrumento.

Variáveis como temperatura, pressão, vazão, nível, corrente, tensão e pH são

medidas por instrumentos analógicos. O termo O analógico ainda é usado para tais
medições porque elas representam um valor escalar, mesmo quando o mecanismo
subjacente é puramente digital. Tais medições resultam em um valor digital que
aos poucos será convertido em unidades de engenharia. Dispositivos que medem
essas variáveis são consideravelmente mais complexos que simples pontos
digitais discretos, e eles geralmente exigem muitos parâmetros para executar
o dimensionamento e a filtragem do medição bruta. Isso leva a um requisito
para comunicações bidirecional com esses sensores. FOUNDATION Fieldbus e
PROFIBUS-PA foram projetados para esses sensores inteligentes. Além disso,
muitas das redes projetadas originalmente para a comunicação de dados binários
discretos do sensor podem ser adaptadas para transmitir valores escalares de
sensores e atuadores.

Claramente, é necessária uma rede diferente para transmitir dados digitais

discretos do sensor daqueles necessários para trocar dados paramétricos –
dados escalares com sensores analógicos inteligentes. Foi para esta tarefa que
redes Fieldbus foram criadas. O termo Fieldbus é usado quando um dispositivo
programado (microprocessador) está localizado no nó da rede e existe a capacidade
de controlar a execução de download de programas ou dados de configuração.
Apesar de programas poderem ser permanentemente armazenados na ROM,
eles também podem ser baixados e armazenados para execução. Os dados para
processamento de sinal e talvez controle (chamado configuração) também são
baixados de um computador host. Os conjuntos de dados são então transferidos
para o computador host sob demanda, dentro do cronograma ou em uma condição
excepcional. As comunicações com um sensor inteligente são realmente um
intercâmbio de dados de computador para computador através de uma rede de
informações denominada Fieldbus.

24
 INTRODUÇÃO │ UNIDADE I

As informações do sensor inteligente geralmente são transferidas em termos

de conjunto de dados amostrados ao mesmo tempo, chamado de conjunto de
dados atômicos. A coerência do tempo é importante e nunca pode ser realizado
por consultas sucessivas. A sincronização do tempo é também importante para o
controle dinâmico e não pode ser alcançado sem uma rede síncrona. O controle
dinâmico com o Algoritmo PID (proporcional, integral, derivativo) usado no
controle de processos, controle de posicionamento, robótica, posicionamento e
controle de movimento é baseado em um conjunto de dados atômicos amostrados
em intervalos de tempo uniformes e exatos.

Muitos dos sensores ou transmissores usados no controle de processos precisam

de energia elétrica para operação. Essa energia era anteriormente entregue
em conexões analógicas de 4 a 20 mA e agora deve ser entregue usando a
rede Fieldbus ou outra fonte de energia. Geralmente, a instrumentação de
campo de controle de processo é instalada em áreas com potencial para gases
combustíveis ou poeiras. Essas áreas classificadas como perigosas pelo Código
Nacional de Energia Elétrica (NEC), NFPA-70,2 Artigo 500. Mesmo quando a
instrumentação de campo é instalada em gabinetes à prova de explosão ou com
purga de gás inerte, a energia elétrica transportada em um cabo de barramento
de campo pode apresentar perigo se o cabo for rompido acidentalmente,
a menos que sejam tomadas medidas para limitar a energia elétrica usando
dispositivos de segurança intrínsecos chamados barreiras. Barreiras de
segurança intrínseca instaladas no Fieldbus limitam o fluxo de corrente do cabo
para impedir a geração de uma faísca quando houver energia suficiente para
inflamar um gás, mistura de vapor ou poeira. Alguns métodos de transmissão
de dados são considerados inerentemente seguros, como sem fio, pneumático e
sensores de fibra óptica quando energizados por fontes de LED, não por lasers.
Os Fieldbuses destinados ao uso no controle de processos foram substituídos
pelos 4-20 mA, que emitiam o sinal e ligavam o instrumento por cabo de dois
fios intrinsecamente seguros. A entrega de energia para os sensores de campo
com segurança intrínseca é uma realização difícil para alguns barramentos de
campo.

Enquanto as redes de sensores com fio fornecem energia para os dispositivos

simples que eles conectam, os barramentos de campo projetados para conexão de
E/S discreta precisam de mais controle da energia para os microprocessadores
nos nós da rede. Muitos desses locais nas indústrias de processo irão também
exigir especificações de segurança intrínsecas, enquanto as aplicações em linha de
fabricação, embalagem e montagem de peças discretas geralmente não requerem
projetos de segurança intrínsecos. Além disso, embora um pequeno número de

25
 UNIDADE I │ INTRODUÇÃO

sensores e atuadores possa ser agrupado em um local, a maioria dos barramentos

de campo destinados ao controle da linha de fabricação e montagem conecta
esses dispositivos ao longo de uma máquina ou linha de transferência. O número
de sensores e atuadores de E/S para fabricação de peças discretas, embalagens
e manuseio de materiais geralmente pode ser muito grande, levando ao uso de
multiplexação de nós conectando muitas E/S em um local de rede.

O uso de conexões sem fio para aquisição de dados do processo e controle começou
com alguns equipamentos não padronizados e proprietários. ISA100 sem fio
(ANSI/ISA-100.11a-2011, IEC 62734) é um padrão projetado para aplicativos de
controle de processo e atualmente está instalado em vários locais. WirelessHART
(Highway Addressable Remote Transducer, IEC 62591) está disponível desde
2009 e é usado em vários aplicativos de monitoramento de processos.

Os padrões de rede de sensores sem fio da indústria de fabricação de peças

discretas são de grande interesse e foram criados, mas só foram usados em redes
proprietárias a partir de 2015.

Para maiores informações sobre ANSI/ISA50.02, consulte o site da ISA.

Disponível em: < https://www.isa.org/>.

Redes de controle

As redes de nível de controle visam a permitir que sistemas de controle possam

se conectar, servindo como o caminho para a conexão de barramento de campo,
para controlar sistemas e para sistemas de controle se conectarem a sistemas de
negócios. Como grandes quantidades de dados podem passar por essas redes e os
comprimentos das mensagens tendem a ser maiores, as taxas de transmissão de
dados tendem a ser mais rápidas do que nas redes de Fieldbus. No entanto, como
elas podem ser usadas para passar dados críticos de tempo entre controladores,
as redes de controle devem também ser determinísticas e atender ao tempo
dependente (geralmente tempo real) das aplicações pretendidas.

O determinismo em um contexto de rede é definido como: um atraso de pior caso

especificado entre a detecção de um item de dados e sua entrega ao dispositivo de
controle. O tempo real neste contexto é definido como “o tempo suficientemente
para atingir os objetivos da aplicação” e é medido como o tempo de latência.
Determinismo e latência são requisitos separados, mas complementares. Tanto
o determinismo quanto uma latência específica são necessários para alcançar
sincronização. Se a mesma rede de controle for usada para trocar informações

26
 INTRODUÇÃO │ UNIDADE I

em tempo real, dados entre controladores e informações comerciais entre

controladores e sistemas de negócios, claramente deve haver alguma maneira de
impedir que as informações comerciais interfiram nas respostas determinísticas
em tempo real. Muitos protocolos complexos foram construídos para esse fim,
mas a maioria das redes de controle depende apenas da natureza subjacente do
protocolo de rede escolhido. Normalmente, o determinismo é alcançado impedindo
colisões de mensagens e limitando o tamanho máximo da mensagem. A baixa
latência é alcançada usando mídia de alta velocidade e minimizando o número de
vezes que um sinal deve ser retransmitido, em uma rede mesh.

O benefício de usar um protocolo de rede padrão, como protocolo de Controle

de Transporte/Protocolo da Internet (TCP/IP) Rede Ethernet é um custo menor.
Simplesmente selecionando o padrão de Cabeamento Ethernet e uso de switches
Ethernet full-duplex em vez de hubs passivos, uma rede de controle construída
sobre essa tecnologia pode garantir que não haverá colisões na rede, tornando
essas redes determinísticas. Usando alta velocidade como 100 ou 1000 Mbps
e Ethernet padrão, o tamanho máximo do pacote de 1.500 bytes alcança baixa
latência e significa que outros aplicativos não podem “dominar o fio”, impedindo
transferências de dados com tempo crítico. No entanto, Lembre-se de que a
definição de tempo real e determinismo requer que a rede faça sua largura de banda
disponível para transferências de dados críticos em tempo menor que o período
máximo permitido para o sistema de controle. Por exemplo, se um aplicativo de
negócios transferir um tamanho máximo de Mensagem Ethernet (1.500 bytes)
a 100 Mbps, a rede seria bloqueada por um tempo máximo de cerca de 150 µs.
Normalmente, essa magnitude de atraso é perfeitamente aceitável para ambos o
controle de processo e a automação de fábrica, mas pode não ser aceitável para
controle de movimento ou controle de máquina.

Seria bom se redes de controle e redes de Fieldbus não pudessem ser usadas
para as mesmas aplicações, mas elas podem. Também seria bom se as redes de
controle estivessem sempre confinadas a ambientes de negócios ou de sala de
controle, mas cada vez mais estão sendo estendidas para o campo e para o chão
de fábrica. Em alguns casos, redes de controle estão sendo usadas em aplicativos
normalmente requerendo um Fieldbus. De fato, todas as redes de controle foram
desenvolvidas a partir de uma ou mais redes de Fieldbus e usam os mesmos
protocolos de camada de aplicação e camada de usuário. Como as redes de
controle estão relacionadas ao barramento de campo, continuará a haver uma
linha divisória muito frouxa entre eles.

27
 UNIDADE I │ INTRODUÇÃO

As redes de nível de controle sem fio já são de uso comum, quando o popular
padrão IEEE 802.11a/b/g/n/ ac (também conhecido como Wi-Fi ou como
“Ethernet sem fio”). Como a maioria das redes populares de nível de controle é
baseada em Ethernet, é fácil substituir Wi-Fi em um ou todos os segmentos e não
requer nenhuma alteração no aplicativo e na camada de usuário. Geralmente, a
substituição do Wi-Fi em qualquer segmento da rede de controle é feita pelo
usuário e funciona bem, mas pode não ser suportado por nenhum dos padrões
para o nível de controle de redes.

28
CAPÍTULO 3
Protocolos de redes industriais

Introdução
Hoje, há vários tipos de redes industriais disponíveis no mercado. É preciso
realizar uma análise profunda para compreender qual é a mais adequada para
as suas necessidades. As redes Fieldbus, também chamadas de redes de campo,
ainda podem ser uma boa escolha para seu projeto, mesmo que ainda não tenha
iniciado a utilização de redes industriais. Conheça um pouco mais sobre elas a
seguir:

DeviceNet

DeviceNet é um protocolo de camada de aplicação. O que isso significa? Implica

que o DeviceNet lida mais com os dados da aplicação do que com um protocolo
de camada inferior ou sem aplicação. Por exemplo, um protocolo de camada de
link é projetado simplesmente para mover alguns bytes do ponto A para o ponto
B. Ele não tem interesse e não transmite informações inerentes ao conteúdo da
mensagem. Como o DeviceNet é um protocolo de camada de aplicativo, suas
mensagens transmitem informações. Uma mensagem explícita do DeviceNet
possui informações específicas em bytes específicos de uma mensagem. Há um
byte para um número de classe, um byte para um código de serviço, e assim por
diante.

Na rede DeviceNet, você pode conectar até 64 nós. Cada nó pode conter
sensores simples ou instrumentos relacionados ao processo ou controlador
lógico programável (PLC). DeviceNet segue o protocolo CAN, dispositivos
para comunicação entre si. Na automação de processos, você pode encontrar o
DeviceNet com sensores simples e instrumento e atuador de campo.

Figura 11. DeviceNet.

Fonte: Br-automation. Disponível em: <https://www.br-automation.com/fileadmin/1288381739663-en-html-1.0.jpg>.

29
 UNIDADE I │ INTRODUÇÃO

Um dos focos dessa rede é a preocupação com a velocidade de transmissão de

dados. Pode também operar com diversos dispositivos, incluindo os analógicos.
Além disso, os módulos utilizados nela podem ser trocados enquanto a rede está
ligada e operando.

Profibus

O PROFIBUS se comunica através de um protocolo serial por trás do qual

máquinas complexas são alojadas para transportar os dados de maneira confiável
através de um ambiente industrial. O protocolo define o design da mensagem,
o acesso à rede e o controle de falhas. Existem ASICs (chips) disponíveis que
coordenam todo o protocolo. Dessa forma, o desenvolvedor do produto não
precisa se envolver muito no PROFIBUS para construir um instrumento de
campo.

O PROFIBUS estabeleceu quatro tipos de mensagens. Todo tipo de mensagem tem

um aplicativo e configuração fixa:

» SD1 (verificação de contato).

» SD2 (transporte de dados).

» SD4 (token).

» SC (resposta curta).

Cada mensagem começa com um cabeçalho, seguido pelos dados. A mensagem

é fechada com um rodapé. Os bytes no cabeçalho e rodapé têm uma função e
significado fixos. Os bytes nas mensagens são 11 bits grandes no cabo do
barramento, 8 bits de dados mais bit de startbit, stopbit e paridade.

Para criar uma hierarquia na rede, o PROFIBUS distingue entre dois tipos de
estações: senhores e escravos. Um mestre é o único dispositivo que pode enviar
mensagens por sua própria iniciativa e geralmente é o único elemento em que o
processo gira. Os exemplos incluem CLPs, sistemas DCS e PCs. Os escravos são os
dispositivos que realmente medem ou direcionam algo, por exemplo, E/S remota,
sensores e atuadores. Um escravo só pode enviar dados se o mestre instruí-lo a
fazê-lo.

Na maioria dos casos, as transações são feitas pelo mestre com um dispositivo.
Isso significa que um mestre envia uma mensagem e o escravo responde. Após
receber a resposta, o mestre se direciona para o próximo escravo.

30
 INTRODUÇÃO │ UNIDADE I

Uma rede pode ser composta de vários mestres. Os mestres concedem direitos de
transmissão entre si por meio de tokens. Essas são pequenas mensagens usadas
por um mestre para indicar que ele terminou e está transferindo o controle para
outro mestre. Isso pode ser comparado a uma corrida de revezamento. É um
sistema operacional totalmente independente, no qual os mestres são adicionados
ou removidos; o usuário não precisa configurar nada. Um mestre que possui o
token lida com os escravos programados com ele (a configuração). Depois de
manipular os escravos, o mestre envia o token para o próximo mestre.

Figura 12. PROFIBUS.

Fonte: Embarcados. Disponível em: <https://www.embarcados.com.br/wp-content/uploads/2016/07/Protocolo-Profibus-

destaque-696x418.jpg>.

Interface AS

A substituição de sensores e atuadores simples por sensores e atuadores

Interface AS é uma tendência quente na automação hoje, e por boas razões.
Interface AS já é um padrão mundial de fato para redes simples de E/S. Seu
potencial para substituir de maneira econômica o ninho de fios de ratos que
permeia a maioria das instalações industriais é extremamente atraente em
muitos setores.

Das redes de substituição de sensores/atuadores de baixo nível disponíveis, a

Interface AS oferece o melhor desempenho pelo menor custo. Devido às suas
raízes como rede da Siemens, a Interface AS já conta com o apoio entusiástico da
comunidade de automação industrial na Europa. Agora, muitos fornecedores de
automação nos EUA estão ficando atraídos pelo seu sistema de alta velocidade,
potência no barramento, simplicidade de operação e fiação de deslocamento de
isolamento.

Com os engenheiros de controle cada vez mais confortáveis com um sistema de

rede estratificado, o Interface AS é a solução perfeita para o nível mais baixo
da arquitetura de rede, aqueles sensores e atuadores simples e de baixo nível

31
 UNIDADE I │ INTRODUÇÃO

que consomem a maioria das despesas de instalação, inicialização e solução de

problemas em andamento. Francamente, com o crescimento da rede Interface AS,
para muitos fornecedores de automação, agora é um erro não oferecer suporte à
Interface AS.

Figura 13. Interface AS.

Fonte: Pepperl-fuchs. Disponível em: <https://www.pepperl-fuchs.com/usa/campaigns/cumulus_img/EC_JB_20181126_03_ASi-

Logo_neu_rdax_614x402_75.jpg>.

A Interface AS conecta até 62 dispositivos de campo em um único par de fios que

fornece sinal e energia. A Interface do sensor do atuador, ou Interface AS, foi
desenvolvida por um grupo de fabricantes de sensores e introduzida no mercado
em 1994. Desde então, tornou-se o padrão de fato para sensores discretos nas
indústrias de processo em todo o mundo. A Interface AS pode ser usada em
ambientes de processos perigosos usando conceitos de proteção à prova de
explosão, cabo de bandeja e para fiação não incendiária.

CANopen

CANopen é um protocolo de comunicação e especificação de perfil de dispositivo

para sistemas embarcados usados em automação. Em termos do modelo OSI,
o CANopen implementa as camadas superiores, incluindo a camada de rede. O
padrão CANopen consiste em um esquema de endereçamento, vários pequenos
protocolos de comunicação e uma camada de aplicação definida por um perfil de
dispositivo. Os protocolos de comunicação têm suporte para gerenciamento de
rede, monitoramento de dispositivos e comunicação entre nós, incluindo uma
camada de transporte simples para mensagens de segmentação/dessegmentação.
O protocolo de nível inferior implementa o link de dados e a camada física
geralmente é uma rede de controle em área (CAN), embora os dispositivos
que usem outros meios de comunicação (como EtherCAT) também possam
implementar o perfil do dispositivo CANopen.

32
 INTRODUÇÃO │ UNIDADE I

CANopen é um protocolo de camada superior baseado em CAN. É desenvolvido

como um padrão de rede incorporada com recursos de configuração altamente
flexíveis. CANopen é projetado para redes de controle de máquinas orientadas
ao movimento, como sistemas de manuseio. É usado em vários campos,
equipamentos médicos, veículos off-road, eletrônicos marítimos, transporte
público, construção automação etc.

Figura 14. CANopen.

Fonte: <https://assets.new.siemens.com/siemens/assets/api/uuid:d6cbf21d-f388-4d6b-84e6-06ae4adde774/width:640/
quality:high/version:1573142398/drives-communications-canopen-logo.png>.

Modbus

O Modbus RTU é um protocolo serial aberto derivado da arquitetura Master/Slave,

originalmente desenvolvida por Modicon (agora Schneider Electric). É amplamente
aceito devido à sua facilidade de uso e confiabilidade. O Modbus RTU é muito
utilizado nos Sistemas de Gerenciamento de Edifícios (BMS) e nos Sistemas de
Automação Industrial (IAS).

As mensagens Modbus RTU são uma estrutura simples de 16 bits com um CRC
(soma de verificação cíclica-redundante). A simplicidade dessas mensagens
é garantir a confiabilidade. Devido a essa simplicidade, a estrutura básica do
registro Modbus RTU de 16 bits pode ser usada para empacotar ponto flutuante,
tabelas, texto ASCII, filas e outros dados não relacionados.

Este protocolo utiliza principalmente interfaces de série RS-232 ou RS-485 para

comunicações e é suportado por quase todos os programas comerciais SCADA,
HMI, OPC Server e software de aquisição de dados no mercado. Isso facilita
muito a integração de equipamentos compatíveis com Modbus em aplicações de
monitoramento e controle novas ou já existentes.

Figura 15. Modbus.

Fonte: <https://www.eltima.com/images/upload/products/spm/articles/modbus/modbus.png>.

33
 UNIDADE I │ INTRODUÇÃO

Hart

Uma maneira de monitorar o equipamento de campo automaticamente é

através de transmissores de sensor com sinal analógico de 4-20 mA. A variável
primária (PV) é comunicada como um nível de corrente entre 4 mA e 20 mA em
um sistema alimentado por loop de dois fios. Uma desvantagem deste método é
que você pode monitorar apenas uma variável por vez.

No final dos anos 90, a indústria de telecomunicações adotou o padrão Bell 202
para transmitir informações de identificação de chamadas na mesma linha que
os sinais de voz. O chaveamento de mudança de frequência de áudio (FSK), que
usa tons modulados para produzir um sinal digital, transfere as informações
digitais que contêm o número de telefone. Os dados são transferidos a uma taxa
de 1.200 bits por segundo (bps), usando as frequências de 1.200 Hz e 2.200 Hz,
representando 1 ou 0 binário.

Neste contexto, o protocolo HART (Highway Addressable Remote Transducer)

permite a transferência de mais informações no mesmo sistema de dois fios. O
modem HART modula e demodula o sinal usando FSK, assim como o sistema
Bell 202. Com isso, informações digitais, como informações de identificação do
sensor ou dispositivo, dados de calibração ou outros diagnósticos, agora podem
ser transferidas pelo mesmo loop de dois fios que o sinal de 4-20mA. Esse sistema
é normalmente chamado de sistema “híbrido”, pois combina sinais digitais e
analógicos.

Figura 16. Hart.

Fonte: <https://fieldcommgroup.org/sites/default/files/fcg_logos/hart_protocol_logo_color_300dpi.png>.

PROFINET

PROFINET é a solução Ethernet Industrial mais avançada do mundo. É um

protocolo de comunicação para troca de dados entre controladores e dispositivos.
Os controladores podem ser PLCs, DCSs ou PACs. Os dispositivos podem ser
blocos de E/S, sistemas de visão, leitores RFID, unidades, instrumentos de
processo, proxies ou mesmo outros controladores.

34
 INTRODUÇÃO │ UNIDADE I

Com base em suas experiências com o PROFIBUS, um Fieldbus em tempo real

que é a solução de rede de automação mais popular atualmente na área, os grupos
de trabalho PI, com mais de 500 especialistas dos principais fornecedores de
automação, passaram muitos anos criando uma solução Ethernet abrangente
para automação em tempo real: PROFINET.

Essa solução é capaz de operar em ambientes industriais difíceis e é capaz de

fornecer a velocidade e a precisão exigidas pelas fábricas. Também pode fornecer
funções adicionais, por exemplo, segurança, gerenciamento de energia e integração
de TI. Estes podem ser usados em combinação com as funções de controle e
monitoramento. Os usuários podem escolher quais serviços eles gostariam de
utilizar.

Aqui estão algumas outras vantagens de trabalhar com o PROFINET no nível de IO:

» Arquiteturas altamente escalonáveis.

» Acesso a dispositivos de campo pela rede.

» Manutenção e serviços de qualquer lugar (mesmo pela Internet).

» Melhor diagnóstico da classe.

» Custos mais baixos para monitoramento de dados de produção/qualidade.

Figura 17. PROFINET.

Fonte: <https://assets.new.siemens.com/siemens/assets/api/uuid:0da6064f-6400-41a8-8197-f1d32ee301a7/width:640/
quality:high/version:1573142223/drives-communications-profinet-logo.png >.

Algumas das suas versões ou ramificações são:

» Profinet IO.

» Profinet IRT.

» Profinet Energy.

» Profinet Safe.
35
 UNIDADE I │ INTRODUÇÃO

IO-Link

O IO-Link é um padrão de rede digital, com fio e ponto a ponto. Ele funciona a
uma curta distância – não mais que vinte metros – usando um conector padrão de
quatro ou cinco pinos. A instalação deve ter um mestre IO-Link para fornecer
uma interface ao controlador ou PLC.

O objetivo de cada dispositivo IO-Link conectado ao mestre é atuar como

um sensor ou atuador inteligente. A maior parte dos dados é usada para
manutenção e serviços preventivos, como a condição de um sensor óptico que
talvez precise ser limpo no futuro. Os dados de diagnóstico enviados pelos
dispositivos IO-Link são usados para evitar problemas futuros. Além disso,
as informações coletadas pelo dispositivo são de leitura/gravação, permitindo
que os parâmetros sejam ajustados pelo PLC durante a operação no caso de
ajustes em tempo real.

Existem quatro componentes básicos do protocolo de comunicação – portas,

modos de comunicação, tipos de dados e velocidades de transmissão. As portas
de comunicação localizadas fisicamente no mestre do IO-Link recebem dados
sobre o estado do sensor ou atuador, detalhes do dispositivo, como números de
série ou informações de diagnóstico ou notificações de eventos específicos e os
transmitem de volta ao PLC. A velocidade de transmissão pode ser configurada
para melhor se adequar ao aplicativo e à rede conectada.

Figura 18. IO-Link.

Fonte: <http://blog.murrelektronik.com.br/wp-content/uploads/2016/06/Link-840x420.png>.

36
 PROTOCOLO UNIDADE II
MODBUS

CAPÍTULO 1
Introdução ao Modbus

Histórico
Alguns padrões de comunicação simplesmente surgem, não por imposição de um
grande grupo de fornecedores ou por uma organização de padrões especiais. Padrões
como a interface Modbus emergem porque são bons, simples de implementar e,
portanto, são adaptados por muitos fabricantes. Por esse motivo, o Modbus se
tornou o primeiro padrão de Fieldbus amplamente aceito.

O Modbus tem suas raízes no final dos anos 1970. Em 1979, quando o fabricante
de PLC Modicon – agora uma marca da Telemecanique Schneider Electric –
publicou a interface de comunicação Modbus para uma rede multiponto baseada
em uma arquitetura mestre/escravo, como ilustra a figura 19. A comunicação
entre os nós Modbus foi concebida através de mensagens. Originalmente era um
padrão fechado que descrevia a estrutura das mensagens. A camada física da
interface Modbus, por sua vez, era de livre escolha.

Figura 19. Comunicação mestre/escravo.

ENVIA REQUISIÇÃO

LÊ RESPOSTA
MESTRE ESCRAVO

Fonte: Elaborada pelo autor.

37
 UNIDADE II │ PROTOCOLO MODBUS

A interface Modbus inicialmente era executada no RS-232, mas a maioria das

implementações posteriores do Modbus usavam o RS-485 porque, entre outras
características, permitia distâncias maiores, velocidades mais altas e a possibilidade
de uma verdadeira rede multiponto. Em pouco tempo, centenas de fornecedores
implementaram o sistema de mensagens Modbus em seus dispositivos e o Modbus
tornou-se o padrão de fato para redes de comunicação industrial.

Uma característica importante do padrão Modbus é a flexibilidade, mas ao mesmo

tempo a sua fácil implementação. Não apenas dispositivos inteligentes como
microcontroladores, CLPs etc. são capazes de se comunicar com o Modbus, mas
também muitos sensores inteligentes são equipados com uma interface Modbus
para a comunicação de seus dados aos sistemas host. Embora o Modbus tenha sido
usado principalmente em linhas de comunicação serial com fio, também existem
extensões ao padrão para comunicações sem fio e redes TCP/IP.

Para maiores informações sobre RS232, veja o artigo “Desvendando a

Comunicação RS232”, de Cristiano Bertulucci Silveira, disponível em:
<https://www.citisystems.com.br/rs232/>.

Já para o RS485, veja o artigo “Redes de comunicação em RS-485” escrito

por Carlos Márcio Freitas, disponível em: <https://www.embarcados.com.br/
redes-de-comunicacao-em-rs-485/>.

Outro artigo importante e o comparativo entre esses dois tipos de

comunicação, trata se do artigo “Por que o RS485 é Mais Eficiente do que
o RS232?” escrito por Cristiano Bertulucci Silveira. Disponível em: https://
www.citisystems.com.br/rs485/.

Introdução
Inicialmente, o objetivo principal do protocolo Modbus era a troca de dados entre
PLCs e outros dispositivos na área de produção. Por ser um dos protocolos de
comunicação mais antigos, o padrão serial de fato do setor desde 1979 ele usa uma
abordagem mais tradicional para conectar dispositivos. Essa abordagem geralmente
é baseada em um sistema mestre/escravo em uma linha serial (RS-232/485).
Dependendo do protocolo Modbus usado, a comunicação pode ser simples ou ponto
a ponto. Apesar disso hoje, o suporte à estrutura simples e elegante do Modbus
continua a crescer. A comunidade da Internet pode acessar o Modbus em uma porta
do sistema reservada 502 na pilha TCP/IP.

38
 PROTOCOLO MODBUS │ UNIDADE II

MODBUS é um protocolo de mensagens da camada de aplicação, posicionado

no nível 7 do modelo OSI, que fornece comunicação cliente/servidor entre
dispositivos conectados em diferentes tipos de barramentos ou redes. A figura
20 ilustra a distribuição da pilha Modbus e suas variações em comparação como
o modelo OSI.

As variações do protocolo Modbus disponíveis incluem:

» Modbus ASCII/RTU.

» Modbus PLUS.

» Modbus TCP/IP.

Figura 20. Pilha Modbus.

OSI-MODEL Modbus-ASCII/RTU Modbus-Plus Modbus-TCP/IP

Layer 7 Modbus Application Layer Modbus Application Layer Modbus Application Layer

Layer 6

Layer 5

Layer 4 TCP

Layer 3 IP

Layer 2 Master/Slave Modbus+HDLC Ethernet 802.3 MAC/LLC

Layer 1 Physical Layer Ethernet Physical Layer

RS232/RS485

Fonte: <https://docplayer.it/docs-images/57/40589234/images/45-0.jpg>.

O modelo OSI (Open System Interconnection) é um modelo conceitual

que caracteriza e padroniza as funções de comunicação de um sistema de
telecomunicações ou computação sem levar em consideração sua estrutura
e tecnologia internas subjacentes. Seu objetivo é a interoperabilidade
de diversos sistemas de comunicação com protocolos de comunicação
padrão. O modelo particiona um sistema de comunicação em camadas de
abstração. A versão original do modelo tinha sete camadas.

Para maiores informações sobre o modelo OSI, veja o artigo “Layers of OSI
Model”, disponível em: <https://www.geeksforgeeks.org/layers-of-osi-
model/>.

39
 UNIDADE II │ PROTOCOLO MODBUS

Veja, também, o artigo “What is OSI Model?”, disponível em: <https://www.

youtube.com/watch?v=Ilk7UXzV_Qc>.

O fato de o protocolo Modbus ser um protocolo aberto, geralmente serial (RS-232

ou RS-485), baseado na arquitetura mestre/escravo ou cliente/servidor, fez dele
um protocolo popular, bem estabelecido, relativamente fácil de implementar e
confiável. Por ser tão fácil de implementar, o Modbus ganhou ampla aceitação
no mercado sempre que os sistemas de automação industrial ou sistemas de
gerenciamento de edifícios precisavam se comunicar com outros dispositivos. De
fato, o Modbus é provavelmente o protocolo de automação mais implementado.

As mensagens Modbus, embora simples, contêm um CRC (cyclic redundancy check

error) de 16 bits para garantir a confiabilidade. A simplicidade das mensagens
Modbus pode ser boa ou ruim. Se por um lado, a estrutura de mensagens simples
garante uma implementação ampla, rápida e precisa, por outro lado, várias
empresas corromperam a estrutura básica de registros Modbus de 16 bits para
compactar em ponto flutuante, filas, texto ASCII, tabelas e outras tipos de dados
não nativos do Modbus.

Os controladores Modbus usam um método de comunicação mestre/escravo.

Isso significa que apenas um dispositivo, ou seja, o mestre, pode iniciar a
comunicação. Os outros dispositivos, os escravos, respondem às mensagens de
comunicação dos mestres. Eles enviam de volta os dados solicitados ou realizam a
operação solicitada pelo mestre. O mestre pode conversar com unidades escravas
individuais ou com todas as unidades escravas ao mesmo tempo, por exemplo,
com mensagens de broadcast (para todos). Independentemente do “modo”
de transmissão, ou seja, ASCII ou RTU, o ciclo e o conteúdo da comunicação
permanecem os mesmos. O quadro de mensagem contém os seguintes campos:

» Endereço do dispositivo.

» Código da função.

» Bytes de dados de 8 bits.

» Verificação de erros.

O protocolo Modbus define um PDU (Protocol Data Unit), trata-se de uma

unidade de dados de protocolo simples independente da camadas de comunicação
subjacentes, conforme ilustra a figura 21.
40
 PROTOCOLO MODBUS │ UNIDADE II

Figura 21. Modbus PDU.

PDU

FUNCTION
DATA
CODE

0 1 253(máx)
Fonte: Elaborada pelo autor.

O tamanho da PDU Modbus é limitado pela restrição de tamanho herdada da

primeira implementação Modbus em rede de linha serial. Portanto:

» PDU MODBUS para comunicação em linha serial = 256 – Endereço

do servidor (1 byte) - CRC (2bytes) = 253 bytes.

Assim, dos 253 bytes máximos possíveis para o PDU Modbus, 1 byte sempre é
destinado ao código da função e os demais bytes compõem os dados referente à
execução da função.

O protocolo Modbus define três PDUs:

» PDU de solicitação Modbus, mb_req_pdu.

» PDU de resposta Modbus, mb_rsp_pdu.

» PDU de resposta de exceção Modbus, mb_excep_rsp_pdu.

O mb_req_pdu é definido como: mb_req_pdu = {function_code, request_data}, onde:

» function_code = [1 byte] código da função Modbus;

» request_data = [n bytes] este campo depende do código da função e

geralmente contém informações como referências variáveis, contagens
de variáveis, compensações de dados, códigos de subfunção etc.

O mb_rsp_pdu é definido como: mb_rsp_pdu = {function_code, response_data},

onde:

» function_code = [1 byte] código da função Modbus;

41
 UNIDADE II │ PROTOCOLO MODBUS

» response_data = [n bytes] este campo depende do código de função

e geralmente contém as mesmas informações, como descrito no
mb_req_pdu.

O mb_excep_rsp_pdu é definido como: mb_excep_rsp_pdu = {exception-function_

code, request_data}, onde:

» exception-function_code = [1 byte] código da função Modbus + 0x80.;

» exception_code = [1 byte] código de exceção Modbus. Mais adiante,

veremos uma tabela com as definições de códigos de exceção Modbus.

Para a transmissão das funções definidas no núcleo do PDU do protocolo Modbus,

é possível usar diversos protocolos de rede. Os protocolos mais usados são o
TCP/IP e serial (RS232 e RS485), mas também é possível utilizar outros, como
o UDP, sendo pouco comum. Para transmitir os dados necessários do Modbus
em todas as camadas (modelo OSI), o Modbus inclui um ADU (Application Data
Unit), trata-se de um conjunto de variantes feitas especificamente para cada
protocolo de rede.

O Modbus requer determinados recursos para fornecer comunicação confiável.

O endereço é usado em todos os formatos de ADU para fornecer informações
de roteamento à camada de aplicação. Cada ADU é fornecida com uma PDU
completa, incluindo o código de função e os dados associados a uma determinada
requisição. Para aumentar a confiabilidade, todas as mensagens contêm
informações de CRC para a verificação de erro. Além disso, todas as ADUs
possuem um mecanismo que determina o início e o fim do quadro da requisição,
mas os implementa de formas diferentes.

No Modbus, existem três formatos padrão para as ADUs, sendo eles o TCP,
RTU e ASCII. As ADUs dos tipos RTU e ASCII são utilizadas tradicionalmente
por uma linha serial, enquanto o TCP é usado em redes TCP/IP ou UDP/IP
modernas.

O ADU RTU contém apenas duas partes de informação além do PDU base, conforme
ilustra a Figura 22. Em primeiro lugar, um endereço é usado para definir a qual
escravo a PDU é destinada. Na maior parte das redes, a utilização do endereço
0 refere se a um endereço de broadcast. Isso significa que se um mestre enviar
um comando ao endereço 0, todos os escravos deverão processar a requisição,
mas nenhum deles deverá responder; isso é um tanto quanto óbvio, pois se todos
os escravos respondessem, haveria uma colisão das informações enviadas, não
sendo possível receber nada. Além desse endereço, um CRC também é enviado e
na recepção é usado para verificar a integridade dos dados.
42
 PROTOCOLO MODBUS │ UNIDADE II

Figura 22. Modbus ADU RTU.

PDU

ADRESS FUNCTIO DATA CRC

SILENCE N CODE SILENCE
3.5CH 3.5CH

ADU RTU
Fonte: Elaborada pelo autor.

A ADU do Modbus RTU parece ser muito simples, entretanto, nas implementações a
realidade está muito longe disso. O pacote é delimitado por um par de intervalos de
silêncio, ou seja, períodos nos quais não há comunicação no barramento, conforme
vemos na figura 22.

O período de silêncio é limitado a um intervalo de 3.5 caracteres. Por exemplo, para

uma taxa de transmissão da serial de 9600bps (bits por segundo), esse intervalo
é de aproximadamente 4 ms. O padrão também define um intervalo de silêncio
mínimo que é independente da taxa de bauds, sendo aproximadamente de 2 ms.

A primeira desvantagem desse intervalo de silêncio é o desempenho, uma vez que

o dispositivo precisa esperar o término do intervalo antes de processar o pacote.
Ou seja, o dispositivo deve aguardar o fim do intervalo de silêncio para que a
transmissão da mensagem seja encerrada sem erros.

Entretanto, um problema maior surge com o uso das novas tecnologias de

transferência serial. Tais tecnologias utilizam taxas de comunicação muito
superiores às taxas utilizadas na concepção do protocolo Modbus.

Ao utilizar um cabo de conversão USB-serial, por exemplo, não é possível ter

controle sobre o empacotamento e transferência dos dados. Neste caso, ocorrem
lacunas de tamanho variável no feixe de dados, o que pode confundir o dispositivo
na recepção, fazendo-o acreditar que a mensagem foi concluída. Como a mensagem
não está completa, isso normalmente leva a um CRC inválido e à interpretação
pelo dispositivo de que a ADU foi corrompida.

Esse tipo de problema pode ser contornado utilizado um determinado método.

Esse método consiste em separar a camada de abstração entre a PDU do Modbus
e a camada de rede. Dessa forma, o código serial interroga o pacote da PDU do
Modbus a fim de determinar o código da função. Assim, pode-se determinar o final
do pacote mais facilmente. É possível usar um tempo de timeout muito maior,
e o polling da aplicação pode ocorrer muito mais lentamente. Esse mecanismo

43
 UNIDADE II │ PROTOCOLO MODBUS

é altamente recomendado para novos desenvolvimentos, pois evita ter uma

quantidade de pacotes “corrompidos” maior que a esperada.

Para finalizar, o comprimento dessa ADU Modbus RTU é:

» RS232/RS485 ADU = 253 bytes + Endereço do servidor (1 byte) + CRC

(2 bytes) = 256 bytes.

A ADU do ASCII é mais complexa que a RTU, mas também evita muitos dos
problemas do pacote RTU que comentamos anteriormente. Entretanto, ela
também tem suas próprias desvantagens.

Figura 23. Modbus ADU ASCII.

PDU

FUNCTION
0x3A ADDRESS LRC 0x0D 0x0A
“:” (ASCII) DATA (ASCII) CR LF
CODE

ADU ASCII

Fonte: Elaborada pelo autor.

Para resolver o problema da determinação do tamanho do pacote, a ADU do

ASCII tem início e fim únicos e bem definidos para cada pacote, que é iniciado
por “:” e é encerrado com os caracteres CR (carriage return) e LF (line feed).
Essas características tornam mais fácil processar a transmissão de dados na
linha serial de maneira eficiente nos modernos códigos de aplicações.

A desvantagem da ADU de ASCII é que todos os dados são transferidos como

caracteres hexadecimais codificados em ASCII. Isso significa que em vez de
enviar um único byte para o código de função 3, 0x03, ela envia os caracteres
ASCII “0” e “3”, ou 0x30/0x33. Isso facilita a leitura do protocolo por um ser
humano, mas isso também significa ser necessário transferir o dobro dos dados
pela rede serial, além disso, as aplicações de envio e recepção devem ser capazes
de interpretar os valores ASCII.

Para finalizar, o comprimento dessa ADU Modbus ASCII é:

» RS232/RS485 ADU = 253 bytes + endereço do servidor (1 byte) + CRC (2

bytes) = 256 bytes.

44
 PROTOCOLO MODBUS │ UNIDADE II

ASCII significa Código Padrão Americano para Intercâmbio de Informações.

Os computadores podem entender apenas números; portanto, um código
ASCII é a representação numérica de um caractere como ‘a’ ou ‘@’ ou uma
ação de algum tipo. O ASCII foi desenvolvido há muito tempo e agora os
caracteres não imprimíveis raramente são usados para sua finalidade
original.

O ASCII foi realmente projetado para uso com teletipos e, portanto, as

descrições são um tanto obscuras. No formato ASCII, significa que o texto é
“sem formatação”, como guias, negrito ou sublinhado – o formato bruto que
qualquer computador pode entender. O Notepad.exe cria texto ASCII ou, no
MS Word, você pode salvar um arquivo como “somente texto”.

Para maiores informações e uma leitura completa sobre a tabela ASCII, veja o
site disponível em: <https://www.ascii-code.com/>.

Já as ADUs do tipo TCP são formadas pelo cabeçalho MBAP (Modbus Application
Protocol) concatenado com a PDU do Modbus. O MBAP é um cabeçalho de uso
geral, que depende de uma camada de rede confiável. O formato dessa ADU,
incluindo o header, é mostrado na figura 24.

Figura 24. Modbus ADU TCP.

MBAP PDU

FUNCTION
TRANSACTION ID PROTOCOL ID LENGTH UNIT ID DATA

CODE

ADU TCP

Fonte: Elaborada pelo autor.

Os campos de dados do cabeçalho indicam seu uso. Em primeiro lugar, ele

contém um identificador de transações. Esse é um recurso valioso em uma rede
que pode ter várias requisições em processamento simultaneamente. Com isso,
por exemplo, um mestre pode enviar requisições 1, 2 e 3. Em algum ponto,
posteriormente, um escravo pode responder na ordem 2, 1, 3. Nesse caso, o
mestre pode combinar as requisições com suas respostas e interpretar os dados
corretamente. Esse é um recurso útil para redes Ethernet.

45
 UNIDADE II │ PROTOCOLO MODBUS

O identificador do protocolo normalmente é zero, mas você pode usá-lo para

expandir o comportamento do protocolo. O campo Length é usado pelo protocolo
para delinear o comprimento do restante do pacote. A posição desse elemento
também indica a dependência desse formato do cabeçalho em uma camada de
rede confiável. Como os pacotes TCP possuem verificação de erro incorporada
e garantem a coerência e entrega dos dados, o comprimento do pacote pode
estar localizado em qualquer parte do cabeçalho. Em uma rede inerentemente
menos confiável, como uma rede serial, um pacote pode ser perdido. Nesse caso,
mesmo que um feixe de dados lido pela aplicação incluísse informações válidas
de transação e protocolo, a informação corrompida de comprimento tornaria
o cabeçalho inválido. O TCP oferece um razoável grau de proteção contra essa
situação.

O campo Unit ID normalmente não é utilizado para dispositivos TCP/IP.

Entretanto, o Modbus é um protocolo tão utilizado que muitos gateways
diferentes foram desenvolvidos, o que converte o protocolo Modbus em outro
protocolo. Em sua destinação original, o gateway Modbus de TCP/IP para serial
poderia ser usado para permitir a conexão entre novas redes TCP/IP e redes seriais
mais antigas. Em um ambiente como esse, a Unit ID é usada para determinar o
endereço do dispositivo escravo para o qual a PDU é realmente destinada.

Para finalizar, a ADU contém um PDU. O comprimento dessa PDU, como já vimos,
é limitado a 253 bytes pelo protocolo padrão. Por consequência, o tamanho de
um ADU Modbus TCP é:

» TCP MODBUS ADU = 253 bytes + MBAP (7 bytes) = 260 bytes.

Em protocolo de transmissão serial, é necessário especificar qual é a ordem de

transmissão dos bytes. O Modbus usa representação do tipo “big endian” para
endereços e dados. Isso significa que quando uma quantidade numérica maior que
um byte é transmitida, o byte mais significativo é enviado primeiro. O contrário a
esse tipo de representação é chamado de “little”. Sendo assim, por exemplo:

» Para um registrador de 16bits com o valor de: 0x1234, o primeiro

byte enviado é 0x12 e depois 0x34.

A figura 25 traz a ilustração da representação big/little endian.

46
 PROTOCOLO MODBUS │ UNIDADE II

Figura 25. Representação big/little endian.

Big Endian
0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107
0
55 15 03 20 44 76 90 35

Little Endian
0x100 0x101 0x102 0x103 0x104 0x105 0x106 0x107
0
35 90 76 44 20 03 15 55
Fonte: Elaborada pelo autor.

Little e big endian são duas maneiras de armazenar tipos de dados

multibyte (int, float etc). Em pequenas máquinas endian, o último byte da
representação binária do tipo de dados multibyte é armazenado primeiro.
Por outro lado, em máquinas big endian, o primeiro byte de representação
binária do tipo de dados multibyte é armazenado primeiro.

Para maiores informações sobre a representação little e big endian, veja o

site: <https://www.geeksforgeeks.org/little-and-big-endian-mystery/>.

O protocolo Modbus estabelece o formato para a consulta do mestre colocando

nele o endereço do dispositivo (ou transmissão), um código de função que define
a ação solicitada, quaisquer dados a serem enviados e um campo de verificação
de erros. A mensagem de resposta do escravo também é construída usando o
protocolo Modbus. Ele contém campos que confirmam a ação tomada, todos os
dados a serem retornados e um campo de verificação de erros (CRC).

Assim, na comunicação, o mestre envia uma mensagem e o escravo, ao receber,

responde de volta no mesmo formato. É importante observar que todas as mensagens
têm um ponto inicial e final conhecido (caracteres especiais). Isso permite que
os dispositivos receptores saibam que uma mensagem chegou e conseguem
decodifica-la, pois conhecem seu início e término. Ao decodificar a mensagem, o
escravo descobre se se trata de uma mensagem para ele ou não.

A figura 26 ilustra um ciclo de consulta e resposta.

47
 UNIDADE II │ PROTOCOLO MODBUS

Figura 26. Consulta e resposta Modbus.

Mensagem de consulta do mestre

Endereço Endereço
Código Função Código Função

Dados de Dados de
consulta resposta

Verificação (CRC) Verificação (CRC)

Mensagem de resposta do escravo

Fonte: <https://www.researchgate.net/publication/325856572/figure/fig3/AS:639289427759105@1529429885425/Modbus-RTU-
request-and-response-packages.png>.

Já vimos que a ADU Modbus é construída pelo cliente que inicia uma transação
Modbus. O campo do código de função de um PDU Modbus é codificado em um
byte. Códigos válidos estão no intervalo de 1 a 255 decimal, sendo o intervalo 128 a
255 reservado para uso como respostas à exceção (erros). Quando uma mensagem
é enviada de um cliente para um dispositivo servidor, o campo de código da função
informa ao servidor que tipo de ação executar. O código de função “0” não é válido.

Alguns códigos de função utilizam códigos de subfunção para definir várias

ações. Nesse caso, o campo de dados das mensagens enviadas de um cliente para
os dispositivos do servidor contém informações adicionais. informações que
o servidor usa para executar a ação definida pelo código de função. Isso pode
incluir itens como endereços discretos e de registro, a quantidade de itens a
serem manipulados e a contagem de bytes de dados reais no campo.

O campo de dados pode ser inexistente (de comprimento zero) em certos tipos de
solicitações, nesse caso o servidor não requer nenhuma informação adicional. O
código de função sozinho especifica a ação.

Por exemplo, um cliente pode ler os estados ON/OFF (ligado/desligado) de um

grupo de saídas ou entradas discretas ou ele pode ler/gravar o conteúdo dos
dados de um grupo de registros. Quando o servidor responde ao cliente, ele usa
o campo de código de função para indicar um resposta normal (sem erros. Para
uma resposta normal, o servidor simplesmente faz eco à solicitação que originou
o código de função.

48
 PROTOCOLO MODBUS │ UNIDADE II

A figura 27 abaixo ilustra um transação Modbus sem erros.

Figura 27. Transação Modbus sem erros.

MESTRE/CLIENTE ESCRAVO/SERVIDOR

INICIA REQUISIÇÃO

REQUISIÇÃO
CÓDIGO FUNÇÃO
DE DADO

GERA RESPOSTA

RESPOSTA DE
CÓDIGO FUNÇÃO DADOS

RECEBE RESPOSTA

Fonte: <http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf>.

Se um erro relacionado à função MODBUS solicitada ocorre, o campo de código de

função contém um código de exceção que o aplicativo do servidor pode usar para
determinar a próxima ação a ser executada referente ao erro ocorrido. Para uma
resposta de exceção, o servidor retorna um código equivalente ao código original da
função PDU de solicitação com seu bit mais significativo, definido como lógico 1.

A Figura 28 abaixo ilustra uma transação Modbus com erros.

Figura 28. Transação Modbus com erros.

MESTRE/CLIENTE ESCRAVO/SERVIDOR

INICIA REQUISIÇÃO

REQUISIÇÃO
CÓDIGO FUNÇÃO DE DADO

GERA RESPOSTA

CÓDIGO FUNÇÃO CÓDIGO

DE EXCEÇÃO DE EXCEÇÃO

RECEBE RESPOSTA

Fonte: Adaptado pelo autor < http://www.modbus.org/docs/Modbus_Application_Protocol_V1_1b.pdf >.

49
 UNIDADE II │ PROTOCOLO MODBUS

Características dos modos RTU, ASCII e TCP

Nos modos ASCII e RTU, os mais tradicionais do Modbus, o usuário escolhe um

dos modos juntamente com os parâmetros da porta serial, por exemplo, taxa de
transmissão, paridade etc. Esses parâmetros devem ser os mesmos para todos os
dispositivos na rede Modbus.

Modo ASCII: Esse modo tem a vantagem de permitir intervalos de tempo de

até 1 segundo entre as transmissões de caracteres sem gerar um erro. É mais útil
quando a comunicação é lenta. Dois caracteres ASCII são enviados como dados
de 8 bits. Um bit de início e parada também é enviado com cada mensagem,
criando um total de 10 bits. 7 bits de dados compreendem a mensagem e 1 bit é
adicionado para paridade par ou ímpar. Se nenhuma paridade for usada, o bit de
parada extra será adicionado para manter uma transmissão total de 10 bits. Ele
também usa o LRC (Longitudinal Redundancy Check) para garantir que o que
enviamos é o que recebemos.

Modo RTU: Esse modo tem a vantagem de enviar mais dados na mesma
quantidade de tempo que no modo ASCII. No entanto, cada mensagem deve
ser transmitida como um fluxo contínuo de dados. Cada mensagem de 8 bits
conterá dois caracteres hexadecimais de 4 bits, enviando a mesma quantidade
de informações em menos tempo. Como usamos um bit de dados extra (8 x
7), enviamos 11 bits no total. Oito bits de dados são usados e 1 bit é usado
para paridade par ou ímpar. Se nenhuma paridade for usada, um bit de parada
adicional será adicionado. Isso eleva nosso total para 11 bits (1 partida + 8
dados + 1 paridade + 1 parada = 11 bits). Esta mensagem usa CRC (Cyclical
Redundancy Check) para verificação de erros.

A interface de comunicação Modbus é construída em torno de mensagens. O

formato dessas mensagens Modbus é independente do tipo de interface física
usada. As mesmas mensagens usadas no Modbus/TCP sobre Ethernet são usadas
no velho e simples RS232. Isso confere à definição da interface Modbus uma
vida útil muito longa. O mesmo protocolo pode ser usado independentemente do
tipo de conexão. Por esse motivo, o Modbus oferece a possibilidade de atualizar
facilmente a estrutura de hardware de uma rede industrial, sem a necessidade
de grandes alterações no software. Um dispositivo também pode se comunicar
com vários nós Modbus de uma só vez, mesmo se estiverem conectados com
diferentes tipos de interface, sem a necessidade de usar um protocolo diferente
para cada conexão.
50
 PROTOCOLO MODBUS │ UNIDADE II

Em interfaces simples como RS485 ou RS232, as mensagens Modbus são

enviadas de forma simples pela rede. Nesse caso, a rede é dedicada ao Modbus.
Ao usar sistemas de rede mais versáteis como TCP/IP, as mensagens Modbus
são incorporadas em pacotes com o formato necessário para a interface física.
Nesse caso, o Modbus e outros tipos de conexões podem coexistir na mesma
interface física ao mesmo tempo. Embora a principal estrutura de mensagens do
Modbus seja ponto a ponto, o Modbus pode funcionar em redes ponto a ponto e
multiponto.

Modo TCP: é uma variante da família Modbus de protocolos de comunicação

simples, destinados à supervisão e ao controle de equipamentos de automação.
Especificamente, abrange o uso de mensagens Modbus em um ambiente de
“Intranet” ou “Internet”, usando os protocolos TCP/IP. O uso mais comum dos
protocolos no momento é para conexão Ethernet de CLPs, módulos de E/S e
gateways a outros barramentos de campo simples ou redes de E/S.

Os desenvolvedores familiarizados com o MODBUS podem se perguntar por

que o protocolo TCP orientado a conexão é usado, e não o UDP orientado a
datagramas. O principal motivo é manter o controle de uma “transação” individual,
colocando-a em uma conexão que pode ser identificada, supervisionada e
cancelada sem exigir uma ação específica por parte dos aplicativos cliente e
servidor. Isso confere ao mecanismo uma ampla tolerância às alterações no
desempenho da rede e permite que recursos de segurança como firewalls e
proxies sejam facilmente adicionados.

51
 CAPÍTULO 2
Codificação

Introdução
A codificação das mensagens no protocolo Modbus segue características próprias
para os diversos modos já comentados. Abaixo, temos como se dá a codificação das
mensagens em cada modo.

Codificação da mensagem ASCII

A mensagem no formato ASCII tem o início (1 caractere) + endereço (2 caracteres) +

função (2 caracteres) + dados (x caracteres) + verificação de erro (2 caracteres) +
final (2 caracteres). No modo ASCII, o caractere inicial é sempre um ‘:’ (ou seja,
dois pontos, sem aspas incluídas). O Quadro 2 ilustra a codificação da mensagem
no modo ASCII.

Quadro 2. Codificação Mensagem ASCII.

START ADRESS FUNCTION DATA LRC CHECK END

1 char 2 chars 2 chars n chars 2 chars 2 chars
“:” CR LF
Fonte: Elaborada pelo autor.

O campo de endereço contém 2 caracteres. Os endereços válidos dos dispositivos

escravos são de 0 a 247. O mestre endereça o dispositivo escravo adequado
colocando o endereço do dispositivo escravo nesse campo. Quando o escravo
responde, ele coloca seu próprio endereço neste campo para que o mestre saiba
qual dispositivo respondeu. O endereço 0 é usado como endereço de broadcast.
Em outras palavras, todos os escravos reagirão a uma mensagem com o endereço 0.

O código da função também contém 2 caracteres. Os códigos de função válidos são

1-255. Alguns códigos são específicos do produto, outros são universais e outros
ainda são reservados para uso futuro. O código da função informa ao dispositivo
escravo o que fazer. Alguns exemplos de códigos de função incluem a leitura
do status da bobina, a leitura do status de entrada, a leitura da localização da
memória, a ativação da bobina, a gravação na memória etc.

52
 PROTOCOLO MODBUS │ UNIDADE II

O campo de dados vem a seguir e contém informações de que os dispositivos

escravos precisarão para processar a solicitação do mestre. Por exemplo, quais
status da bobina devem ser lidos, quais bobinas devem ser forçadas etc.

O campo de dados que o escravo envia de volta ao mestre conterá os dados

solicitados ou um código de erro, se houver um erro. O campo de verificação
de erro no modo ASCII contém o resultado do cálculo do LRC (Longitudinal
Redundancy Check). Este cálculo é simplesmente feito adicionando todos os
bytes da mensagem (excluindo os dois pontos de início), eliminando quaisquer
carregamentos e, em seguida, 2 complementando o resultado.

Por fim, os caracteres CR (retorno de carro) e LF (avanço de linha) são adicionados

à mensagem. Isso informa ao dispositivo receptor que a mensagem terminou.

Codificação da mensagem RTU

As mensagens RTU contêm os mesmos itens das mensagens ASCII, só que em uma
forma mais compacta. Aqui está o formato da mensagem:

Início (tempo de atraso de 4 caracteres) + endereço (8 bits) + código de função (8

bits) + dados (n x 8 bits) + verificação de erro (16 bits) + final (tempo de atraso de 4
caracteres). O Quadro 3 ilustra a codificação da mensagem no modo ASCII.

Quadro 3. Codificação mensagem RTU.

START ADRESS FUNCTION DATA LRC CHECK END

T1, T2, T3, T4 8bits 8bits n x 8bits 16 bits T1, T2, T3, T4
Fonte: Elaborada pelo autor.

É importante observar que, no modo ASCII, pode haver um atraso de até 1

segundo entre a transmissão de cada caractere, mas o modo RTU pode ter no
máximo 1,5 de atraso entre cada caractere.

As únicas diferenças entre os formatos de mensagem ASCII e RTU são a

formação da mensagem, o início/término e a verificação de erros. O início/
fim são simplesmente pausas no tempo de 4 caracteres. A verificação de erro
é o cálculo de CRC (Cyclical Redundancy Check). O Quadro 4 ilustra um
comparativo entre os formatos ASCII e RTU.

53
 UNIDADE II │ PROTOCOLO MODBUS

Quadro 4. Comparativo codificação Modbus ASCII e RTU.

Modbus ASCII Modbus RTU

Caractere ASCII 0...9 e A...F Binário 0...255
Verificação LRC (Longitudinal Redundancy Check) CRC (Longitudinal Redundancy Check)
Início de quadro Caractere “:” 3,5 Caractere de silêncio
Fim de quadro Caractere “CR LF” 3,5 Caractere de silêncio
Lacuna na mensagem 1 sec 1.5 vezes o comprimento do caractere
Bit de início 1 1
Bits de dados 7 8
Paridade Par/ímpar Nenhuma Par/ímpar Nenhuma
Bits de parada 1 2 1 2
Fonte: Elaborada pelo autor.

Codificação da mensagem TCP

Conforme vimos anteriormente, o protocolo Modbus TCP é uma implementação do

protocolo Modbus baseado em TCP/IP. Utiliza a pilha TCP/IP para comunicação
e adiciona ao quadro Modbus um cabeçalho específico chamado MBAP (MODBUS
Application Protocol). A codificação das mensagens Modbus TCP/IP fica da
seguinte forma:
Quadro 5. Codificação Mensagem TCP.

MPAB ADRESS FUNCTION

TI PI L UI xx xx
7 x 8bits 8bits n x 8bits
Fonte: Elaborada pelo autor.

O cabeçalho MBAP tem tamanho de 7 bytes, e é composto pelos seguintes campos:

» Transaction Identifier (TI): usado para identificação da resposta

para a transação (2 bytes).

» Protocol Identifier (PI): 0 (zero) indica Modbus (2 bytes).

» Length(L): contagem de todos os próximos bytes (2 bytes).

» Unit identifier (UI): utilizado para identificar o escravo remoto em

uma rede Modbus RTU (1 byte).

Modbus TCP não acrescenta ao quadro um campo de checagem de erros, entretanto,

o frame Ethernet já utiliza CRC-32, tornando desnecessário outro campo de
checagem. O cliente Modbus TCP deve iniciar uma conexão TCP com o servidor a
fim de enviar as requisições. A porta TCP 502 é a porta padrão para conexão com
servidores Modbus TCP.

54
 PROTOCOLO MODBUS │ UNIDADE II

Para maiores informações sobre os modos RS232, RS485 e TCP, veja o vídeo
“Understanding Modbus Serial and TCP/IP”. Disponível em: <https://www.
youtube.com/watch?v=k993tAFRLSE&list=PLkxqHEyjiG_lmM6yX8tht-
Gbw773P8VbJ>.

55
 CAPÍTULO 3
Endereçamento e funções

Endereçamento
A primeira informação em cada mensagem Modbus é o endereço do receptor. No
Modbus ASCII, é codificado com dois caracteres hexadecimais; no Modbus RTU,
é codificado usando um byte, assim como já vimos anteriormente. Os endereços
válidos estão no intervalo de 0 a 247. Os valores 1.247 são atribuídos a dispositivos
Modbus individuais e 0 é usado como um endereço de broadcast.

As mensagens enviadas para o último endereço serão aceitas por todos os escravos.
Um escravo sempre responde a uma mensagem Modbus. Ao responder, ele usa o
mesmo endereço que o mestre usou na solicitação, ou seja, seu próprio endereço.
Dessa maneira, o mestre pode ver que o dispositivo está realmente respondendo à
solicitação.

Dentro de um dispositivo Modbus, os registros, entradas e saídas de retenção

recebem um número entre 1 e 10000. Espera-se que os mesmos endereços sejam
usados nas mensagens Modbus para ler ou definir valores. Infelizmente, esse não
é o caso.

Nas mensagens do Modbus, os endereços são usados com um valor entre 0 e 9999.
Se você deseja ler o valor da saída (bobina) 18, por exemplo, deve especificar o
valor 17 na mensagem de consulta do Modbus. Mais confuso ainda é que, para
registros de entrada e retenção, um deslocamento deve ser subtraído do endereço
do dispositivo para obter o endereço adequado para colocar na estrutura de
mensagens do Modbus. Isso leva a erros comuns e é preciso tomar muito cuidado
ao projetar aplicativos com o Modbus. O quadro 6 a seguir mostra os intervalos
de endereços para bobinas, entradas e registros de retenção e a maneira como
o endereço na mensagem Modbus é calculado, considerando o endereço real do
item no dispositivo escravo.

Quadro 6. Endereços de dados Modbus.

Device Address Modbus Address Descrição

1... 10000 Address - 1 Bobinas (output)
10001... 20000 Address - 10001 Inputs
30001... 40000 Address - 30001 Input Register
40001... 50000 Address - 40001 Holding Register
Fonte: Elaborada pelo autor.

56
 PROTOCOLO MODBUS │ UNIDADE II

Portanto, analisando o quadro 6, é possível verificar o tratamento necessário para

especificar o endereço de dados Modbus desejado corretamente, sendo, assim,
necessário subtrair a faixa inicial do endereço Modbus. Para bobinas, deve-se
subtrair 1, para inputs subtrai-se 10001 do valor de endereço desejado, e assim por
diante, como demostra o Quadro 6.

Códigos de função

O segundo parâmetro em cada mensagem do Modbus é o código da função. Isso

define o tipo de mensagem e o tipo de ação exigida pelo escravo. O parâmetro
contém um byte de informação. No Modbus ASCII, isso é codificado com dois
caracteres hexadecimais; no Modbus RTU, um byte é usado. Os códigos de
função válidos estão no intervalo de 1 a 255. Nem todos os dispositivos Modbus
reconhecem o mesmo conjunto de códigos de função. Os códigos mais comuns
são discutidos aqui, como ilustra o Quadro 7.

Normalmente, quando um escravo Modbus responde, ele usa o mesmo código de

função que na solicitação. No entanto, quando um erro é detectado, o bit mais
alto do código de função é ativado. Dessa forma, o mestre pode ver a diferença
entre respostas de sucesso e falha.

Quadro 7. Funções Modbus.

Code Descrição
1 Read Coils Status
2 Read Input Status
3 Read holding register
4 Read input register
5 Force single coil
6 Preset single register
7 Read exception status
15 Force multiple coils hold register
16 Preset multi register
17 Report slave
Fonte: Elaborada pelo autor.

As distinções entre entradas e saídas e entre endereçável por bits e endereçável

por palavras itens de dados não implica nenhum comportamento do aplicativo.
É perfeitamente aceitável, e muito comum, considerar as quatro tabelas como
sobrepostas, se esta é a mais natural interpretação na máquina alvo em questão.

Para cada uma das tabelas principais, o protocolo permite a seleção individual
de 65536 itens de dados, e as operações de leitura ou gravação desses itens são

57
 UNIDADE II │ PROTOCOLO MODBUS

projetadas para abranger vários itens de dados até um limite de tamanho de dados
que depende do código de função da transação.

É óbvio que todos os dados manipulados via Modbus (bits, registradores) devem
estar localizados no dispositivo memória de aplicação. Mas o endereço físico na
memória não deve ser confundido com os dados referência. O único requisito é
vincular a referência de dados ao endereço físico.

Os números de referência lógicos Modbus, usados nas funções Modbus, são índices
inteiros não sinalizados, começando em zero.

Mapa de memória

Por ser um protocolo aberto que opera principalmente sobre linhas seriais (RS232
ou RS485), relativamente fácil de implementar e confiável, isso faz do Modbus
um protocolo de automação muito implementado. Assim, em determinadas
implementações, é necessário desenvolver a sua própria aplicação.

Os exemplos abaixo mostram duas maneiras de organizar os dados no dispositivo.

Existem diferentes possibilidades, mas nem todas são descritas aqui, pois cada
dispositivo pode ter sua própria organização dos dados de acordo com sua aplicação.

O exemplo abaixo mostra a organização dos dados em um dispositivo com

entradas e saídas digitais e analógicas. Cada bloco é separado porque os dados
de diferentes blocos não têm correlação. Cada bloco é, portanto, acessível com
diferentes funções Modbus. A figura 29 ilustra essa implementação.

Figura 29. Modelo de implementação com bloco separado.

MEMÓRIA DO DISPOSITIVO

ACESSO MODBUS

Entrada discreta

Requisição
Bobinas Modbus

Registrador
de entrada

Registrador de
retenção

Dispositivo
Servidor Modbus

Fonte: Elaborada pelo autor.

58
 PROTOCOLO MODBUS │ UNIDADE II

Neste outro exemplo, o dispositivo possui apenas um bloco contínuo de dados.

Os mesmos dados podem ser acessados através de várias funções Modbus, por
exemplo, através de um acesso de 16 bits ou através de um acesso de um bit. A
figura 30 ilustra esse tipo de implementação, onde “L” indica uma operação de
leitura e “E” indica uma operação de escrita.
Figura 30. Modelo de implementação com bloco único.

MEMÓRIA DO DISPOSITIVO

ACESSO MODBUS

Entrada discreta
L
E Requisição
Bobinas Modbus

L
Registrador
de entrada

E
Registrador de
retenção

Dispositivo
Servidor Modbus

Fonte: Elaborada pelo autor.

O objetivo desses dois exemplos é deixar claro que o pré-mapeamento entre o

modelo de dados Modbus e o aplicativo do dispositivo é totalmente específico do
dispositivo do fornecedor. Também fica clara a separação entre a organização de
memória do padrão Modbus, a alocação de memória no dispositivo e a necessidade
do remapeamento, conforme ilustra a figura 31.
Figura 31. Mapeamento de memória entre o Modbus e o dispositivo.
DISPOSITIVO
MODELO DE ENDEREÇO PDU
DADOS MODBUS MODBUS

LEITURA ENTRADA 1

Entrada discreta

ESCRITA BOBINA 3
Bobinas

Registrador LEITURA REGISTRADOR 10

de entrada

Registrador de ESCRITA REGISTRADOR 45

retenção

MAPEAMENTO
APLICAÇÃO
PADRÃO MODBUS
ESPECÍFICA

Fonte: Elaborada pelo autor.

59
 UNIDADE II │ PROTOCOLO MODBUS

Função 1 – Read Coils status

Esse código de função é usado para ler o estado de saídas (bobinas) endereçadas
de 1 a 2000 em um dispositivo remoto. O PDU de solicitação especifica o endereço
inicial, ou seja, o endereço da primeira bobina que se deseja ler e o número de
bobinas a serem lidas em sequência. O quadro 8 mostra o PDU de requisição e
resposta sem erro para a leitura do estado de saídas (bobinas).
Quadro 8. PDU Read coils.

Requisição
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x01
Endereço de início 2 bytes 0x0000 a 0xFFFF
Quantidade de bobinas 2 bytes 1 a 2000 (0x7D0)
Resposta
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x01
Número de bytes 1 byte n
Estado das bobinas n byte 0 ou 1 em cada bit referente ao estado da bobina lida

Fonte: Elaborada pelo autor.

Ao receber uma mensagem de consulta Modbus com a função 01, o escravo

coleta os valores de saída necessários e constrói uma mensagem de resposta.
O comprimento dessa mensagem depende do número de valores que devem ser
retornados. Em geral, quando N valores são solicitados, é necessário um número
“n” de bytes para armazenar esses valores. O número real de bytes no bloco de
dados é colocado no primeiro byte do campo de dados.

Já vimos anteriormente que na PDU, as bobinas são endereçadas a partir de zero.

Portanto, é necessário subtrair 1 do endereço a ser inserido na PDU. Por exemplo,
uma leitura de bobinas numeradas de 1 a 16 devem ser endereçadas como 0 a 15.
Exemplo:

Pedido de requisição e sua resposta para a leitura dos estados das saídas de 10 a 28.
Quadro 9. Exemplo Função Read coils.

Requisição Resposta
Campo Valor Campo Valor
Função 0x01 Função 0x01
Endereço de início (parte alta) 0x00 Quantidade de bytes 0x03
Endereço de início (parte baixa) 0x09 Estados saídas 17 - 10 0xCD
Quantidade de saídas (parte alta) 0x00 Estados saídas 25 - 18 0x6B
Quantidade de saídas (parte baixa) 0x13 Estados saídas 28 - 26 0x05
Fonte: Elaborada pelo autor.

60
 PROTOCOLO MODBUS │ UNIDADE II

Na montagem deste PDU para a leitura das saídas 10 a 28, temos primeiramente
o campo de função como valor 1 que corresponde à função de leitura do estado
de saída (bobina). O próximo campo é o endereço de início que, como já vimos,
possui dois bytes. Nele, está inserido o endereço inicial da sequência de saída que
se deseja ler. Nesse exemplo, o valor é 9, lembrando que na montagem do PDU
o endereço é subtraído de um. O campo seguinte corresponde à quantidade de
saídas que se deseja ler. Esse campo também possuí 2 bytes de tamanho. Nesse
exemplo, o valor é 19, que corresponde a saídas de 10 a 28.

A resposta a esse PDU de requisição possui no primeiro campo o código da função,

neste caso 1. O campo seguinte informa a quantidade de bytes que carregam os
estados das saídas desejadas. Nesse exemplo o valor é 3, que corresponde à parte
inteira do resultado de (19+7)/8. Por convenção, os bits dentro de um byte são
mostrados com o MSB (bit mais significativo) à esquerda e o LSB (bit menos
significativo) à direita. Assim, as saídas no primeiro byte de resposta são “17
a 10”, da esquerda para a direita. O próximo byte contém as saídas “25 a 18”,
da esquerda para a direita. O último byte de dados contém o estado das saídas
“38 a 36”. Perceba que o último byte não está completamente preenchido pelos
estados das saídas, assim, os cinco bits restantes são preenchidos com zero.

Função 2 – Read inputs status

No protocolo Modbus, um input é um valor de entrada discreto. A função Modbus

2 pode ser usada para ler o status dessas entradas. Só é possível consultar um
dispositivo por vez e o endereçamento de broadcast não é suportado para esta
função Modbus.

A função read inputs status possui as mesmas atribuições de faixa de endereço e

campo de dados da função read coils status, sendo a única diferença o código da
função.

Função 3 – Read Hold Register

Os valores internos em um dispositivo Modbus são armazenados em registros de

retenção. Esses registradores têm dois bytes de largura e podem ser usados para
vários propósitos. Alguns registradores contêm parâmetros de configuração e
outros são usados para retornar valores de medições (temperaturas, pressão
etc.) para um host. O quadro 9 mostra o PDU de requisição e resposta sem erro
para a leitura de registradores de retenção.

61
 UNIDADE II │ PROTOCOLO MODBUS

Os registradores de retenção em um dispositivo Modbus começam a contar

em 40001. Eles são endereçados no PDU Modbus com endereços iniciando
em 0, sendo assim, deve-se subtrair 40001. A função Modbus 03 é usada para
solicitar um ou mais valores de registro retidos de um dispositivo. Somente
um dispositivo escravo pode ser endereçado por consulta e as consultas de
broadcast com a função 03 não são suportadas. O quadro 9 mostra o PDU de
requisição e resposta sem erro para a leitura de registradores de retenção.

Quadro 10. PDU Read Hold Register.

Requisição
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x03
Endereço de início 2 bytes 0x0000 a 0xFFFF
Quantidade de registradores 2 bytes 1 a 125 (0x7D)
Resposta
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x03
Número de bytes 1 byte 2*N
Valor dos registradores N * 2 byte Valor de cada registrador

Fonte: Elaborada pelo autor.

Exemplo:

Pedido de requisição e sua resposta para a leitura dos registradores de retenção de

40101 a 40102.

Quadro 11. Exemplo Função Read Hold Register.

Requisição Resposta
Campo Valor Campo Valor
Função 0x03 Função 0x03
Endereço de início (parte alta) 0x00 Quantidade de bytes 0x04
Endereço de início (parte baixa) 0x63 Registrador 100 (parte alta) 0x02
Quantidade de saídas (parte alta) 0x00 Registrador 100 (parte baixa) 0x2B
Quantidade de saídas (parte baixa) 0x02 Registrador 101 (parte alta) 0x00
Registrador 101 (parte baixa) 0x64

Fonte: Elaborada pelo autor.

Na montagem deste PDU para a leitura dos registradores 100 a 101, temos
primeiramente o campo de função como valor 3, que corresponde à função de
leitura de registrador de retenção. O próximo campo é o endereço de início
que, como já vimos, possui dois bytes. Nele, está inserido o endereço inicial
da sequência de saída que se deseja ler. Nesse exemplo o valor é 99 (0x63),

62
 PROTOCOLO MODBUS │ UNIDADE II

lembrando que na montagem do PDU o endereço é subtraído de 40001. O campo

seguinte corresponde à quantidade de saídas que se deseja ler. Esse campo
também possuí 2 bytes de tamanho. Nesse exemplo o valor é 2, que corresponde
aos registradores 100 e 101.

A resposta a esse PDU de requisição possui no primeiro campo o código da

função, neste caso 3. O campo seguinte informa a quantidade de bytes que
carregam os valores dos registradores de interesse. Nesse exemplo, o valor é
4, que corresponde a 2 * 2 (registradores). O valor lido do registrador 40101 é
0x022B(555) e o valor lido do registrador 40102 é 0x0064(100).

Função 4 – Read Input Register

Esse código de função é usado para ler registradores de entrada de 1 a 125 de

forma contínua em um dispositivo remoto. A PDU de solicitação especifica o
endereço de registro inicial e o número de registradores que se deseja ler. Os
dados do registro na mensagem de resposta são compactados como dois bytes
por registro. Para cada registro, o primeiro byte contém o bits de ordem superior
e o segundo contém os bits de ordem inferior. O Quadro 10 mostra o PDU de
requisição e resposta sem erro para a leitura de registradores de entrada.

Os registradores de entrada em um dispositivo Modbus começam a contar em

30001. Eles são endereçados no PDU Modbus com endereços iniciando em 0,
sendo assim, deve-se subtrair 30001. A função Modbus 4 é usada para solicitar
um ou mais valores de registradores de entrada de um dispositivo. Somente um
dispositivo escravo pode ser endereçado por consulta e as consultas de broadcast
com a função 03 não são suportadas.

Quadro 12. PDU Read Input Register.

Requisição
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x04
Endereço de início 2 bytes 0x0000 a 0xFFFF
Quantidade de registradores 2 bytes 1 a 125 (0x7D)
Resposta
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x04
Número de bytes 1 byte 2*N
Valor dos registradores N * 2 byte Valor de cada registrador

Fonte: Elaborada pelo autor.

63
 UNIDADE II │ PROTOCOLO MODBUS

A função Read Input Register possui as mesmas atribuições de faixa de endereço

e campo de dados da função Read Hold Register, sendo a única diferença o código
da função.

Função 5 – Write Single Coil

Esse código de função é usado para escrever em uma saída os estados “1” ou
“0” em um dispositivo remoto, o que corresponde a ligar ou desligar a saída,
respectivamente. O estado solicitado é especificado por uma constante no campo
de dados da solicitação. Um valor de 0xFF00 solicita que a saída seja ligada. Um
valor de 0x0000 solicita que seja desligada. Todos os outros valores são ilegais e
não afetarão a saída.

A PDU de solicitação especifica o endereço da bobina a ter seu estado modificado.

As bobinas são endereçadas partir do zero. Portanto, a bobina numerada 1 é
endereçada como 0. O Quadro 11 mostra o PDU de requisição e resposta sem erro
para a escrita em uma única bobina.

Quadro 13. PDU Write Single Coil.

Requisição
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x05
Endereço da saída 2 bytes 0x0000 a 0xFFFF
Valor da saída 2 bytes 0x0000 ou 0xFF00
Resposta
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x05
Endereço da saída 2 byte 0x0000 a 0xFFFF
Valor da saída 2 byte 0x0000 ou 0xFF00

Fonte: Elaborada pelo autor.

Função 6 – Write Single Register

Esse código de função é usado para gravar um único registro de retenção em um

dispositivo remoto. A PDU de solicitação especifica o endereço do registro a ser
gravado. A resposta normal é um eco da solicitação, retornado após o conteúdo do
registro ter sido escrito. O quadro 12 mostra o PDU de requisição e resposta sem
erro para a escrita de um único registrador.

64
 PROTOCOLO MODBUS │ UNIDADE II

Quadro 14. PDU Write Single Register.

Requisição
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x06
Endereço da saída 2 bytes 0x0000 a 0xFFFF
Valor da saída 2 bytes 0x0000 a 0xFFFF
Resposta
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x06
Endereço da saída 2 byte 0x0000 a 0xFFFF
Valor da saída 2 byte 0x0000 a 0xFFFF

Fonte: Elaborada pelo autor.

Exemplo:

Pedido de requisição e sua resposta para a escrita do valor 0x01F4 registradores 2.

Quadro 15. Exemplo Função Read Hold Register.

Requisição Resposta
Campo Valor Campo Valor
Função 0x06 Função 0x06
Endereço do registrador (parte alta) 0x00 Endereço do registrador (parte alta) 0x00
Endereço do registrador (parte baixa) 0x01 Endereço do registrador (parte baixa) 0x01
Valor do registrador (parte alta) 0x01 Valor do registrador (parte alta) 0x01
Valor do registrador (parte baixa) 0xF4 Valor do registrador (parte baixa) 0xF4

Fonte Elaborada pelo autor.

Função 15 – Write Multiple Coils

Esse código de função é usado para forçar o estado de bobinas em uma

sequência de bobinas a ligar ou desligar em um dispositivo remoto. A PDU de
solicitação especifica as referências da bobina a serem forçadas. As bobinas
são endereçadas a partir de zero. Portanto, a bobina numerada 1 é endereçada
como 0.

Os estados ON/OFF solicitados são especificados pelo conteúdo do campo de dados

na solicitação. Um “1” lógico em uma posição de bit do campo solicita que a saída
correspondente seja ligada. Solicitações com “0” lógico correspondem à ação de
desligar a saída.

A resposta normal retorna o código de função, endereço inicial e quantidade de

bobinas forçadas

65
 UNIDADE II │ PROTOCOLO MODBUS

Quadro 16. PDU Write Multiple Coils.

Requisição
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x0F
Endereço das saídas 2 bytes 0x0000 a 0xFFFF
Quantidade de saídas 2 bytes 0x0001 a 0x07B0
Quantidade de bytes 1 byte N
Valor de saída N bytes
Resposta
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x0F
Endereço da saída 2 bytes 0x0000 a 0xFFFF
Valor da saída 2 bytes 0x0001 a 0x07B0

Fonte: Elaborada pelo autor.

Exemplo:

Solicitação para escrever uma série de 10 bobinas começando na bobina 20, ou

seja, da bobina 20 a 29. O conteúdo dos dados da solicitação é de dois bytes:
0xCD01 (1100 1101 0000 0001 binário). Os bits binários e bytes correspondem
às saídas da seguinte maneira:

Quadro 17. Distribuição dos bit nos bytes.

bit 1 1 0 0 1 1 0 1 0 0 0 0 0 0 0 1
Byte 1 2
Saídas 27 26 25 24 23 22 21 20 35 34 33 32 31 30 29 28
Fonte: Elaborada pelo autor.

Quadro 18. Exemplo Função Write Multiple Coils.

Requisição Resposta
Campo Valor Campo Valor
Função 0x0F Função 0x0F
Endereço de início (parte alta) 0x00 Endereço de início (parte alta) 0x00
Endereço de início (parte baixa) 0x13 Endereço de início (parte baixa) 0x13
Quantidade de saídas (parte alta) 0x00 Quantidade de saídas (parte alta) 0x00
Quantidade de saídas (parte baixa) 0x0A Quantidade de saídas (parte baixa) 0x0A
Quantidade de bytes 0x02
Valor da saída (parte alta) 0xCD
Valor da saída (parte baixa) 0x01

Fonte: Elaborada pelo autor.

O primeiro byte transmitido (CD hex) endereça as saídas 27-20, com o bit menos
significativo endereçando a saída mais baixa (20). O próximo byte transmitido

66
 PROTOCOLO MODBUS │ UNIDADE II

(01 hex) endereça as saídas 29-28, com o bit menos significativo endereçando a
saída mais baixa (28). Os bits não utilizados no último byte de dados devem ser
preenchidos com 0.

Função 16 – Write Multiple Register

Esse código de função é usado para escrever um bloco de registros contínuos

(1 a 123 registros) em um dispositivo remoto.

Os valores escritos solicitados são especificados no campo de dados da solicitação.

Os dados são compactados em dois bytes por registro.

A resposta normal retorna o código de função, endereço inicial e quantidade de

registros escritos.

Quadro 19. PDU Write Multiple Register.

Requisição
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x10
Endereço de início 2 bytes 0x0000 a 0xFFFF
Quantidade de registros 2 bytes 0x0001 a 0xFF7B
Quantidade de bytes 1 byte 2*N
Valor do registro N * 2 bytes Valor
Resposta
Descrição do campo Número de bytes Valor
Código da função 1 byte 0x10
Endereço de início 2 byte 0x0000 a 0xFFFF
Quantidade de registros 2 byte 0x0001 a 0xFF7B

Fonte: Elaborada pelo autor.

Exemplo:

Pedido de requisição e sua resposta para a escrita em 2 registradores com os

respectivos valores 0x000A e 0x0102.

Quadro 20. Exemplo Função Write Multiple Register.

Requisição Resposta
Campo Valor Campo Valor
Função 0x10 Função 0x10
Endereço de início (parte alta) 0x00 Endereço de início (parte alta) 0x00
Endereço de início (parte baixa) 0x01 Endereço de início (parte baixa) 0x01
Quantidade de registro (parte alta) 0x00 Quantidade de registro (parte alta) 0x00

67
 UNIDADE II │ PROTOCOLO MODBUS

Requisição Resposta
Campo Valor Campo Valor
Quantidade de registro (parte baixa) 0x02 Quantidade de registro (parte baixa) 0x02
Quantidade de bytes 0x04
Valor do registrador (parte alta) 0x00
Valor do registrador (parte baixa) 0x0A
Valor do registrador (parte alta) 0x01
Valor do registrador (parte baixa) 0x02

Fonte: Elaborada pelo autor.

68
CAPÍTULO 4
Ferramentas de diagnóstico e
aplicações

Diagnósticos e leituras de erros

Quando um dispositivo cliente envia uma solicitação a um dispositivo servidor, ele
espera uma resposta normal. Podem ocorrer quatro eventos possíveis a partir da
consulta do cliente:

» Se o dispositivo servidor receber a solicitação sem erro de comunicação

e puder lidar com a consulta normalmente, ele retorna uma resposta
normal.

» Se o servidor não receber a solicitação devido a um erro de

comunicação, nenhuma resposta é retornada. O programa cliente
acabará processando uma condição de tempo limite para o pedido.

» Se o servidor receber a solicitação, mas detectar um erro de

comunicação (paridade, LRC, CRC etc.), nenhuma resposta é
retornada. O programa cliente acabará processando uma condição
de tempo limite para a solicitação.

» Se o servidor receber a solicitação sem erro de comunicação, mas não

puder lidar com ela (por exemplo, se a solicitação for ler uma saída
ou registro inexistente), o servidor retornará uma resposta de exceção
informando o cliente sobre a natureza do erro.

A mensagem de resposta de exceção possui dois campos que a diferenciam de uma

resposta normal:

» Campo Código da função: em uma resposta normal, o servidor faz

eco do código da função da solicitação original no campo de código
da função da resposta. Todos os códigos de função têm o bit mais
significativo (MSB) igual a 0 (seus valores estão todos abaixo de
0x80). Na resposta de exceção, o servidor define o MSB do código
de função como 1. Isso faz com que o valor do código de função em
uma resposta de exceção seja exatamente 0x80hex maior que o valor
seria para uma resposta normal. Com o conjunto MSB do código de
função, o programa aplicativo do cliente pode reconhecer a resposta
de exceção e examinar o campo de dados para o código de exceção.

69
 UNIDADE II │ PROTOCOLO MODBUS

» Campo de dados: em uma resposta normal, o servidor pode retornar

dados ou estatísticas no campo de dados (qualquer informação
solicitada na solicitação). Em uma resposta de exceção, o servidor
retorna um código de exceção no campo de dados. Isso define a
condição do servidor que causou a exceção.

Quadro 21. Exception Status.

Código Nome
0x01 ILLEGAL FUNCTION
0x02 ILLEGAL DATA ADDRESS
0x03 ILLEGAL DATA VALOR
0x04 SERVER DEVICE FAILURE
0x05 ACKNOWLEDGE
0x06 SERVER DEVICE BUSY
0x08 MEMORY PARITY ERROR
0x0A GATEWAY PATH UNAVAILABLE
0x0B GATEWAY TARGET DEVICE FAILED TO RESPOND

Fonte: Elaborada pelo autor.

Esse código de função é usado para ler o conteúdo de oito saídas de status
de exceção em um dispositivo remoto. A função fornece um método simples
para acessar essas informações, porque na exceção as referências de saída são
conhecidas (nenhuma referência de saída é necessária na função).

A resposta normal contém o status das oito saídas de status de exceção. As

saídas são compactados em um byte de dados, com um bit por saída. O status
da saída mais baixa está contido no bit menos significativo do byte. O conteúdo
das oito saídas de exceção é específico do dispositivo.

O código de função Modbus 08 fornece uma série de testes para verificar o sistema
de comunicação entre um dispositivo cliente e um servidor ou para verificar
várias condições de erro interno.

A função usa um campo de código de subfunção de dois bytes na consulta para

definir o tipo de teste a ser realizado. O servidor reproduz ambos o código de
função e o código de subfunção em uma resposta normal. Alguns dos diagnósticos
fazem com que os dados sejam retornados do dispositivo remoto no campo de
dados de uma resposta normal.

Em geral, a emissão de uma função de diagnóstico para um dispositivo remoto

não afeta a execução do programa do usuário no dispositivo remoto. A lógica do
usuário, como as entradas e saídas discretas, bem como os registradores, não é

70
 PROTOCOLO MODBUS │ UNIDADE II

acessada pelos diagnósticos. Certas funções podem, opcionalmente, redefinir os

contadores de erros no dispositivo remoto.

Um dispositivo de servidor pode, no entanto, ser forçado a entrar no “modo

apenas ouvir”, no qual monitorará as mensagens no sistema de comunicações,
mas não responde a elas. Isso pode afetar o resultado do seu programa aplicativo,
se depender de mais troca de dados com o dispositivo remoto. Geralmente,
esse modo força a remoção de um dispositivo remoto com defeito do sistema de
comunicações.

Simuladores
Existem diversos simuladores Modbus disponíveis na Internet. Com certeza
eles são de grande utilidade e auxiliam no aprendizado do protocolo, ou até
mesmo para teste de protótipos. Abaixo são apresentadas algumas opções de
simuladores Modbus que podem ser encontrados na Internet.

» Modbus PLC Simulator.

» Elipse Modbus Simulator.

» Simuladores ModScan e ModSim.

» Simuladores Modbus Poll e Modbus Slave.

Apresentaremos com mais detalhes e exemplos o uso das ferramentes ModBus Poll
e ModBus Slave, ambas ferramentas da desenvolvedora de software Modbus Tools.
Apesar de serem ferramentas pagas, é possível utilizar a versão demonstrativa para
fins de estudo sem nenhum problema. As características de utilização da versão
demonstrativa incluem:

» 10 minutos do limite de conexão.

» Após 10 minutos, a conexão é desconectada.

» Reiniciar o aplicativo iniciará outro período de demonstração de 10

minutos.

» Após 30 dias, não é possível fazer uma conexão.

Modbus Poll

O Modbus Poll é um simulador mestre Modbus projetado principalmente para

ajudar desenvolvedores de dispositivos escravos Modbus ou outros que desejam
testar e simular o protocolo Modbus.

71
 UNIDADE II │ PROTOCOLO MODBUS

Com a interface de vários documentos, você pode monitorar vários escravos

Modbus e áreas de dados ao mesmo tempo. Para cada janela, basta especificar o
ID do escravo Modbus, função, endereço, tamanho e taxa de pesquisa. Você pode
ler e escrever registros e bobinas a partir de qualquer janela. Se você deseja alterar
um único registro, basta clicar duas vezes no valor, ou você pode alterar vários
registros e bobinas.

Estão disponíveis vários formatos de dados como float, double e long com troca de
ordem de palavras. Erros de exceção são mostrados na linha de status.

Se você é um desenvolvedor de dispositivos escravos, é possível compor e enviar

suas próprias cadeias de teste no “centro de testes” e verificar o resultado do
escravo em números hexadecimais.

O Modbus Poll possui automação OLE para interface com o Excel para interpretar
e mostrar os dados do Modbus de acordo com seus requisitos específicos. Por
exemplo, editar dados no Excel e depois transmitir os dados para o seu dispositivo
escravo. Na figura 32 abaixo temos a ilustração da tela do Modbus Poll.

Figura 32. Tela Inicial Modbus Poll.

Fonte: Elaborada pelo autor.

Para instalar o software do Modbus Poll em seu computador, os seguintes

passos são necessários:

» Baixar o arquivo de instalação. Para isso, acesse a página

do software na Internet por meio do link: <https://www.
modbustools.com/download.html>.

72
 PROTOCOLO MODBUS │ UNIDADE II

» Na página do software, navegue até a opção Modbus Poll e

selecione o arquivo de acordo com seu sistema operacional.

» Executar o arquivo de instalação.

» Na primeira tela que aparece, seleciona “I accept the terms of

license agreement” e clique em “Next”.

» Na próxima tela, clique em “Next”.

» Na próxima que se segue, clique em “Install”.

» Aguarde a instalação do software.

» Após a instalação, na tela que surge, clique em “Next”.

» Por fim, clique em “Finish”

Pronto, o software Modbus Poll está pronto para configuração e utilização.

Vale lembrar que o software utilizado é de versão demonstrativa, com
prazo de expiração.

Modbus Slave

O Modbus Slave é um simulador de dispositivos escravos no qual é possível

simular até 32 dispositivos escravos em 32 janelas. Tem-se um ganho de tempo
na programação de CLP com a utilização dessas ferramentas de simulação, pois
inicia a programação e teste antes mesmo de receber os dispositivos escravos do
fornecedor. Os dados contidos em qualquer documento aberto são acessíveis ao
aplicativo mestre com uma interface de usuário similar à do Modbus Poll.

Possui suporte às funções 01, 02, 03, 04, 05, 06, 15, 16, 22 e 23, monitoramento
de tráfego serial, automação OLE para interface com Visual Basic, Excel etc.,
para interpretar e mostrar os dados do Modbus de acordo com seus requisitos
específicos. Cada janela aberta no Modbus Slave pode ser configurada para
representar dados do mesmo nó ou de outro nó escravo.

73
 UNIDADE II │ PROTOCOLO MODBUS

Figura 33. Tela inicial do Modbus Slave.

Fonte: Elaborada pelo autor.

Para instalar o software do Modbus Slave em seu computador, os seguintes

passos são necessários:

» Baixar o arquivo de instalação. Para isso, acesse a página

do software na Internet por meio do link: <https://www.
modbustools.com/download.html>.

» Na página do software, navegue até a opção Modbus Slave e

selecione o arquivo de acordo com seu sistema operacional.

» Executar o arquivo de instalação.

» Na primeira tela que aparece, seleciona “I accept the terms of

license agreement” e clique em “Next”.

» Na próxima tela, clique em “Next”.

» Na próxima que se segue, clique em “Install”.

» Aguarde a instalação do software.

» Após a instalação, na tela que surge, clique em “Next”.

» Por fim, clique em “Finish”.

74
 PROTOCOLO MODBUS │ UNIDADE II

Pronto, o software Modbus Slave está pronto para configuração e utilização.

Vale lembrar que o software utilizado é de versão demonstrativa, com
prazo de expiração.

Porta serial

De fato, muitos dos computadores que são fabricados atualmente não estão
equipados com nenhuma porta serial. A redução na dependência de portas COM
em máquinas e dispositivos usados para propósitos gerais não eliminou o requisito
de conectividade serial. Há muitos dispositivos para fins especiais que ainda
usam interfaces serial para se comunicarem com computadores. Alguns exemplos
são dispositivos de monitoramento de automação industrial, equipamentos de
monitoramento médico e equipamentos de laboratório especializados.

Os desenvolvedores desses dispositivos serial ou aplicativos que interagem com

eles exigem a capacidade de testar e depurar seus produtos antes de divulgá-los
ao público. Isso pode ser problemático com os computadores atuais, pois pode
não haver portas seriais disponíveis na máquina. A emulação de porta serial é a
resposta para este tipo de situação.

Portanto, para a utilização das ferramentas de simulação Modbus Poll e Modbus

Slave, é necessária a utilização de uma conexão serial virtual. Nesta disciplina,
utilizaremos o software Virtual Serial Port Driver (VSPD) para esse propósito. A
figura 34 ilustra a tela principal do VSPD.

Figura 34. Tela inicial do Virtual Serial Port Driver.

Fonte: Elaborada pelo autor.

75
 UNIDADE II │ PROTOCOLO MODBUS

Para instalar o software do Virtual Serial Port Driver em seu computador,

alguns passos são necessários:

» Baixar o arquivo de instalação. Para isso, acesse a página do

software na Internet por meio do link: <https://www.eltima.
com/products/vspdxp/>.

» Na página do software, navegue até a opção “Download

standard” e a selecione.

» Executar o arquivo de instalação.

» Na primeira tela que aparece, selecione o idioma “Português

(Brasil)” e clique em “OK”.

» Na próxima tela, selecione “Eu aceito os termos de contrato” e

clique em “Avançar”.

» Nas próximas 4 telas que se seguem, clique sempre em avançar.

» Aguarde a instalação do software.

» Após a instalação, na tela que surge, clique em concluir.

» Na próxima tela que surge, clique em “continue demo”.

Pronto, o software está pronto para configuração e utilização. Vale

lembrar que o software utilizado é uma versão demonstrativa com
prazo de expiração. Outros softwares podem ser utilizados, desde que
desempenhem a mesma função.

Configurando as ferramentas
Para as instruções descritas a seguir, considera-se que os softwares VSPD,
Modbus Poll e Modbus Slave já estão instalados na máquina. Sendo assim,
para efetuar a configuração, primeiramente execute o software.

VSPD

Abaixo estão os passos necessários para adicionar um par de portas serial virtual
interconectadas à sua máquina utilizando o VSPD:

» Escolha “Gerenciar portas” (manage ports) na janela principal do

aplicativo.
76
 PROTOCOLO MODBUS │ UNIDADE II

» Clique no botão “Adicionar par” (add pair) para criar um par de

portas serial virtuais. O nome das portas não fica restrito a “COM1”
ou “COM2”, sendo possível renomeá-las como desejar.

O par de portas criado aparecerá no gerenciador de dispositivos do computador

e estará disponível para uso imediatamente após a criação, conforme ilustra a
figura 35.

Figura 35. Gerenciador de dispositivos.

Fonte: Elaborada pelo autor.

Para excluir as portas virtuais criadas, basta clicar na aba “Port pairs”, em
seguida em “Delete All” e confirme clicando em “Sim” na caixa de diálogo que
surge. Assim, todas as portas criadas são deletadas.

Modbus Poll

Ao inicializar, o software já se apresenta com um documento aberto, “Mbpoll1”.

Entretanto, é possível abrir diversos documentos simultaneamente e operá-los
com diferentes IDs (endereço ou identificador do dispositivo). Para isso, basta
clicar na aba “File” e em seguida em “New”.

Com o software aberto, o primeiro passo é conectar-se a uma porta serial e

configurá-la. Para isso, basta clicar na aba “Connection” e em seguida em “connect”,
ou simplesmente aperte a tecla “F3”. Feito isso, a tela da Figura 36 abaixo se
apresenta.

77
 UNIDADE II │ PROTOCOLO MODBUS

Figura 36. Cópia não registrada.

Fonte: Elaborada pelo autor.

Não se preocupe, pois se trata apenas de um aviso de que o software é uma cópia
não registrada e que irá operar na forma demonstrativa por um período de 30
dias. Portanto, basta clicar em “OK” para todas as telas e ignorar os avisos.

Na tela de Connection Setup, ilustrada na figura 37, é possível selecionar o tipo

de conexão, o modo e as configurações da serial, tais como a porta, a taxa de
comunicação número de bits, paridade e stop bit.

Figura 37. Connection Setup Modbus Poll.

Fonte: Elaborada pelo autor.

Aqui, utilizaremos a seguintes configurações:

» Serial Port.

» Modo RTU.

» 9600 baud.

» 8 data bits.

78
 PROTOCOLO MODBUS │ UNIDADE II

» None Parity.

» 1 Stop bit.

» Timeout 2000ms.

» Delay 20ms.

» Porta COM1 -. COM2.

Feitas as configurações de conexão, basta clicar em OK para confirmar as alterações.

Confirmadas as configurações e após um determinado tempo, começa a ser

mostrado um erro na tela (Timeout Error), como ilustra a figura 38. Esse erro
é normal nesse ponto da configuração e está relacionado ao parâmetro timeout
que configuramos anteriormente, bem como ao funcionamento do software
que efetua leitura ou escrita periodicamente (pulling). Sendo assim, quando
configuramos a conexão, o Modbus Poll passa a tentar estabelecer comunicação
com o escravo periodicamente. Como ainda não foi configurado o software
Modbus Slave para de fato responder ao Modbus Poll, ocorre o erro timeout.

Figura 38. Timeout Error.

Fonte: Elaborada pelo autor.

Agora resta configurar a função Modbus que se deseja simular. Para isso, bastar
clicar na aba “Setup” e selecionar “Read/Write Definition” ou simplesmente apertar
a tecla F8. Na tela “Read/write Defination”, ilustrada na figura 39, é possível
configurar diversos itens; dentre eles, os principais são:

» Slave ID – este campo configura o endereço do escravo.

» Function – este campo define a função Modbus a ser emulada. É

possível emular as funções 1, 2, 3, 4, 5, 6, 15, 16.

» Address – configura o endereço inicial do registrador ou campo de

bit que serão lidos ou escritos individualmente ou dentro de uma
sequência.

79
 UNIDADE II │ PROTOCOLO MODBUS

» Quantity – configura a quantidade de registros ou campos de bits

que serão lidos ou alterados pela função.

» Scan Rate – configura o intervalo de comunicação com o escravo. Ou

seja, de quanto em quanto tempo o software efetua uma operação de
escrita ou leitura.

Figura 39. Read/Write Definition.

Fonte: Elaborada pelo autor.

As configurações apresentadas já compreendem o mínimo necessário para

simular as funções básicas do Modbus Poll. Assim, passamos agora a configurar
o Modbus Slave.

Para maiores informações sobre o uso do Modbus Poll, consulte o manual

de usuário disponível no link: <https://www.modbustools.com/mbpoll-
user-manual.html>.

Modbus Slave

Com o software Modbus Slave aberto, o primeiro passo é conectar-se a uma

porta serial e configurá-la. Para isso, basta clicar na aba “Connection” e, em
seguida, em “connect”, ou simplesmente aperte a tecla “F3”. Assim como na
configuração do Modbus Poll, ao clicar em “connect” serão apresentadas algumas
telas referentes ao aviso de software demonstrativo. Portanto, basta clicar em
“OK” para todas as telas e ignorar os avisos. Feito isso, a tela da figura 40 abaixo
será apresentada.

80
 PROTOCOLO MODBUS │ UNIDADE II

Figura 40. Connection Setup Modbus Slave.

Fonte: Elaborada pelo autor.

Utilizaremos a seguintes configurações:

» Serial Port.

» modo RTU.

» 9600 baud.

» 8 data bits.

» None Parity.

» 1 Stop bit.

» Porta COM2 -. COM1.

Aqui cabe uma observação importante. As configurações da porta serial devem ser
idênticas no Modbus Poll e no Modbus Slave, exceto pela porta serial, em que no
Modbus Poll configuramos a porta COM1 e no Modbus Slave a porta COM2.

Feitas as configurações de conexão, basta clicar em OK para confirmar. Agora o

próximo passo é configurar a função que deseja simular no escravo. Para isso,
bastar clicar na aba “Setup” e selecionar “Slave Definition”, ou simplesmente
apertar a tecla F8. Com isso, temos a tela apresentada na figura 41.

81
 UNIDADE II │ PROTOCOLO MODBUS

Figura 41. Slave Definition.

Fonte: Elaborada pelo autor.

Na tela Slave Definition, é possível configurar diversos itens; dentre eles, os

principais são:

» Slave ID – este campo configura o endereço do escravo.

» Function – este campo define a função Modbus a ser emulada. É

possível emular as funções 1, 2, 3, 4.

» Address – configura o endereço inicial do registrador ou campo de

bit que serão lidos ou escritos individualmente ou dentro de uma
sequência.

» Quantity – configura a quantidade de registros ou campos de bits que

serão lidos ou alterados pela função.

» View – número de endereço visíveis na tela software.

Com isso, temos as configurações mínimas necessárias para simular as funções

básicas do Modbus Slave, juntamente com o Modbus Poll.

Para maiores informações sobre o uso do Modbus Slave, consulte o manual

de usuário disponível no link: <https://www.modbustools.com/mbslave-user-
manual.html>.

82
 PROTOCOLO MODBUS │ UNIDADE II

Exemplo de uso

Agora que configuramos os softwares Modbus Poll e Modbus Slave e demais

ferramentas necessárias ao estabelecimento da comunicação, iremos demonstrar
a escrita e leitura em registradores e bobinas (coils). Serão demonstradas as
seguintes funções básicas:

» Read Coils (função 1).

» Write Register (função 16).

Read Coils

Para este exemplo, demonstraremos a leitura dos estados das bobinas de um

escravo de endereço 10. A partir do endereço 15, iremos ler o estado de 17 bobinas.

Para tal, configuramos o Read/Write definition do Modbus Poll e o Slave

definition do Modbus Slave da seguinte maneira:

Quadro 22. Configuração de simulação da função Read Coils.

Configuração
Descrição do campo Modbus Poll Modbus Slave
Slave ID 10 10
Function 01 Read Coils (0x) 01 Read Coils (0x)
Address 12 12
Quantity 13 13
Scan rate 1000 -

Fonte: Elaborada pelo autor.

Um detalhe importante é que os campos de “address” e “quantity” especificados

no Modbus Slave não necessariamente devem ser iguais aos respectivos campos
no Modbus Poll. Entretanto, os respectivos campos do Modbus Poll devem estar
contidos na faixa de endereços determinada pelos campos do Modbus Slave.

Por exemplo, se fosse configurado o valor 11 no campo “Address” do Modbus

Poll, teríamos um erro, pois o Slave não contempla este endereço. A figura 42
ilustra este erro.

83
 UNIDADE II │ PROTOCOLO MODBUS

Figura 42. Ilegal Address.

Fonte: Elaborada pelo autor.

Feitas as configurações corretamente, os softwares se comunicarão periodicamente

com intervalo de tempo determinado pelo campo “Scan Rate” do Modbus Poll.
A figura 43 ilustra ambos os softwares configurados e operando.

Figura 43. Exemplo de Read Coils.

Fonte: Elaborada pelo autor.

Para editar o valor de uma bobina, basta clicar duas vezes com o botão esquerdo
do mouse sobre o valor que se deseja editar. Feito isso, é apresentada a tela da
figura 44, na qual é possível ligar (ON) ou desligar (OFF) uma bobina. A alteração
é confirmada ao clicar em “OK” e o valor é atualizado no Modbus Poll na sua
próxima requisição.
Figura 44. Edit Coil.

Fonte: Elaborada pelo autor.

84
 PROTOCOLO MODBUS │ UNIDADE II

Em ambos os softwares, é possível verificar os dados que são transmitidos e

recebidos pela linha serial. Isso possibilita um maior conhecimento sobre as
mensagens do protocolo. Para visualizar o tráfego de mensagens, basta clicar na
aba “Display” e, em seguida, em “Communication”.

Figura 45. Tráfego de mensagens.

Fonte: Elaborada pelo autor.

Nesta tela do Modbus Poll, verificamos as mensagens transmitidas e recebidas pelo

software. As mensagens transmitidas são indicadas pela sigla TX, seguida pelo
índice da mensagem (TX:000004-). Já as mensagens recebidas são indicadas pela
sigla RX, seguida pelo índice da mensagem (RX:000005-).

A mensagem TX:000004-0A 01 00 0C 00 0D 3C B7 corresponde ao exemplo de

requisição de leitura de bobinas. O valor 0x0A indica o endereço do escravo, 0x01
indica a função, 0x000C indica o endereço inicial de leitura, 0x000D indica a
quantidade de bobinas a serem lidas e 0x1C3D corresponde ao CRC.

Como resposta, temos a mensagem RX:000005-0A 01 02 01 00 1D AD, onde o

valor 0x0A indica o endereço do escravo, 0x01 indica a função, 0x02 indica a
quantidade de bytes de dados necessária para responder a requisição, 0x0100
são os bytes de dados que representarão os estados das bobinas e 0x1DAD
corresponde ao CRC.

Write Register

Para este exemplo, demonstraremos a escrita em registradores de um escravo de

endereço 5. A partir do endereço 4, iremos escrever valores em 3 registradores.

Para tal, configuramos o Read/Write definition do Modbus Poll e o Slave

definition do Modbus Slave da seguinte maneira:

85
 UNIDADE II │ PROTOCOLO MODBUS

Quadro 23. Configuração de simulação da função Write Register.

Configuração
Descrição do campo Modbus Poll Modbus Slave
Slave ID 16 4
Function 01 Read Coils (0x) 01 Read Coils (0x)
Address 4 4
Quantity 3 3
Scan rate 1000 -

Fonte: Elaborada pelo autor.

Os campos de “address” e “quantity” especificados no Modbus Slave não

necessariamente devem ser iguais aos respectivos campos no Modbus Poll.
Entretanto, os respectivos campos do Modbus Poll devem estar contidos na
faixa de endereços determinada pelos campos do Modbus Slave, caso contrário,
teremos um erro tal como ilustra a Figura 42.

Percebam que as funções especificadas para o Modbus Poll e Modbus Slave são
diferentes. Especificamos a função correspondente à escrita em um registrador
no Modbus Poll, a função 16: Write multiple registers. Entretanto, no Modbus
Slave, especificamos a função 03: Read holding registers (4x). Então por que essa
diferença? Analisando o manual de usuário do software, verifica-se que, para o
caso do Modbus Slave, as funções especificam a região de memória emulada pelo
software conforme o Quadro 6. Sendo assim, para a especificação das funções,
seguimos a correspondência do quadro quadro 16.

Quadro 24. Correspondência entre funções Modbus Poll e Modbus Slave.

Especificação nos softwares

Função
Modbus Poll Modbus Slave
1 – Read Coil 01: Read coils (0x) 01: Read coils (0x)
2 – Read Discrete Inputs 02: Read discrete inputs (1x) 02: Read discrete inputs (1x)
3 – Read Holding Registers 03: Read holding registers (4x) 03: Read holding registers (4x)
4 – Read Input Register 04: Read input registers (3x) 04: Read input registers (3x)
5 – Write Single Coil 05: Write single coil 01: Read coils (0x)
6 – Write Single Register 06: Write single register 03: Read holding registers (4x)
15 – Write Multiple Coils 15: Write multiple coils 01: Read coils (0x)
16 – Write Multiple Registers 16: Write multiple registers 03: Read holding registers (4x)
22 – Mask Write Register 22 – Mask Write Register 03: Read holding registers (4x)
23 – Read/Write Multiple Registers 23 – Read/Write Multiple Registers 03: Read holding registers (4x)
Fonte: Elaborada pelo autor.

Feitas as configurações corretamente, os softwares se comunicaram periodicamente

com intervalo de tempo determinado pelo campo “Scan Rate” do Modbus Poll. A
Figura 46 ilustra ambos os softwares configurados e operando.

86
 PROTOCOLO MODBUS │ UNIDADE II

Figura 46. Exemplo de Read Coils.

Fonte: Elaborada pelo autor.

Para editar o valor de um registrador, basta clicar duas vezes com o botão
esquerdo do mouse sobre o valor que se deseja editar no Modbus Poll. Feito
isso, é apresentada a tela da figura 47, na qual é possível especificar um valor
para o registrador. O tipo de variável pode ser selecionado pelas opções da aba
“Display”, signed, unsigned, binário etc. A alteração do valor do registrador é
confirmada ao clicar em “OK” e o valor é atualizado no Modbus Slave na próxima
requisição.

Figura 47. Edit Register.

Fonte: Elaborada pelo autor.

Novamente, em ambos os softwares, para visualizar o tráfego de mensagens

basta clicar na aba “Display” e em seguida em “Communication” e temos a tela
apresentada na figura 48.

Figura 48. Tráfego de mensagens.

Fonte: Elaborada pelo autor.

87
 UNIDADE II │ PROTOCOLO MODBUS

A mensagem TX:000003-0F 10 00 02 00 03 06 FD E8 7D 00 00 7B 7C 71
corresponde ao exemplo de requisição de escrita em múltiplos registradores. O
valor 0x0F indica o endereço do escravo, 0x10 indica a função, 0x0002 indica o
endereço inicial de leitura, 0x0003 indica a quantidade de registradores a serem
escritos, 0x06 indica a quantidade de bytes, 0xFDE8(65000), 0x7D00(32000),
0x007B(123) corresponde aos valores a serem escritos nos registradores e
0x7C71 corresponde ao CRC.

A mensagem RX:000004-0F 10 00 02 00 03 20 E6 corresponde à mensagem de

resposta à requisição, na qual o valor 0x0F indica o endereço do escravo, 0x10
indica a função, 0x0002 indica o endereço inicial de leitura, 0x0003 indica a
quantidade de registradores escritos e 0x20E6 corresponde ao CRC.

Até aqui apresentamos dois exemplos de utilização dos ferramentas de simulação

da Modbus Tools. Logicamente, os softwares não se limitam apenas ao que foi
apresentado, espera-se que o aluno utilize mais intensamente as funções do
software aprendendo ainda mais.

88
 PROTOCOLO HART UNIDADE III

CAPÍTULO 1
Introdução ao HART

Introdução
Atualmente, muito se fala em termos de redes Fieldbus, mas tem-se muitas
aplicações rodando em HART (Highway Addressable Remote Transducer), tendo
vantagens com os equipamentos inteligentes e utilizando-se da comunicação
digital de forma flexível sob o sinal 4-20mA para a parametrização e monitoração
das informações.

Introduzido em 1989, tinha a intenção inicial de permitir fácil calibração, ajustes de

range e damping de equipamentos analógicos. Foi o primeiro protocolo digital de
comunicação bidirecional que não afetava o sinal analógico de controle.

O protocolo HART possibilita que na mesma fiação haja a sobreposição do sinal de

comunicação digital em sinais analógicos de 4-20mA sem que ocorra interferência
entre eles. O HART também proporciona alguns dos benefícios apontados pelo
Fieldbus, mantendo ainda a compatibilidade com a instrumentação analógica além
de aproveitar o que já se conhece sobre os sistemas 4-20mA existentes.

Esse protocolo tem sido testado com sucesso em milhares de aplicações, em vários
segmentos, mesmo em ambientes perigosos. O HART permite o uso de mestres:
um console de engenharia na sala de controle e um segundo mestre no campo, por
exemplo um laptop ou um programador de mão.

Em termos de performance, podemos citar como características do HART:

» Comprovado na prática, projeto simples, fácil operação e manutenção.

89
 UNIDADE III │ PROTOCOLO HART

» Compatível com a instrumentação analógica.

» Sinal analógico e comunicação digital.

» Opção de comunicação ponto a ponto ou multidrop.

» Flexível acesso de dados usando-se até dois mestres.

» Suporta equipamentos multivariáveis.

» 500ms de tempo de resposta (com até duas transações).

» Totalmente aberto com vários fornecedores.

As especificações continuamente são atualizadas de forma a atender todas as

aplicações.

O Protocolo HART permite aos seus usuários o melhor caminho de migração para
usufruir dos benefícios da comunicação digital para a instrumentação inteligente.
Nenhuma outra tecnologia de comunicação pode igualar a estrutura de suporte
ou a grande variedade de instrumentos disponíveis com tecnologia HART hoje.
A tecnologia permite o uso fácil dos produtos compatíveis com Hart que estão
disponíveis no mercado pela maioria dos fornecedores de instrumentação e que
atendem virtualmente todas as medições de processo ou aplicações de controle.

O surgimento do Fieldbus não reduzirá o HART em novas aplicações ou nas

existentes. O HART possibilita aos seus usuários grande parte dos mesmos
benefícios, ao mesmo tempo em que mantém a compatibilidade e a familiaridade
com os sistemas existentes de 4-20 mA. O HART permite os benefícios
econômicos da comunicação remota, a flexibilidade e a precisão da comunicação
de dados digital, o diagnóstico dos instrumentos de campo e o uso de poderosos
instrumentos com múltiplas variáveis, sem que haja a necessidade de trocar
sistemas inteiros.

A conexão com redes de plantas atuais e futuras é assegurada pela capacidade

de comunicação digital e a larga base instalada. O suporte oferecido pela Hart
Communication Foundation assegura que a tecnologia continuará a servir às
necessidades da instrumentação inteligente de hoje e do amanhã.

90
 PROTOCOLO HART │ UNIDADE III

Figura 49. Exemplo Rede Hart.

MESTRE
IMPEDANCIA MESTRE
SECUNDÁRIO
MÍNIMIA PRIMARIO
24VDC
250Ω MODEM HART
RS23/USB
SALA DE
CONTROLE
CAMPO
4-20mA 4-20mA 4-20mA
BARREIRA DE
TRANSMISSOR
SEGURANÇA
DE PRESSÃO POSICIONADOR
INTRÍNSICA
COM PID DE VÁLVULA HART
INTERNO

Fonte: SMAR <http://www.smar.com/images/index150_fig35.jpg>.

A flexibilidade do Protocolo HART é evidente no diagrama de controle da Figura

49. Essa aplicação inovadora usa a capacidade inerente ao Protocolo HART de
transmitir tanto sinais 4-20mA analógicos como sinais digitais de comunicação
simultaneamente pela mesma fiação. Nessa aplicação, o transmissor HART tem
um algoritmo interno de controle PID. O instrumento é configurado de modo que
o loop de corrente 4-20mA seja proporcional à saída de controle PID, executado
no instrumento (e não à variável medida, como, por exemplo, a pressão, como
na maioria das aplicações de instrumentos de campo). Uma vez que o loop
de corrente é controlado pela saída de controle do PID, este é utilizado para
alimentar diretamente o posicionador da válvula de controle.

A malha de controle é executada inteiramente no campo, entre o transmissor

(com PID) e a válvula. A ação de controle é contínua como no sistema tradicional;
o sinal analógico de 4-20mA comanda a válvula. Através da comunicação digital
HART, o operador pode mudar o set-point da malha de controle e ler a variável
primária ou a saída para o posicionador da válvula. Uma economia substancial
pode ser obtida através dessa inovadora arquitetura de controle.

Veremos a seguir alguns detalhes do protocolo HART.

Para maiores informações sobre HART, veja o vídeo “What is HART Protocol?”,
disponível em: <https://www.youtube.com/watch?v=pXkun-PEiY0>.

HART e o padrão 4 a 20mA

Um sinal analógico é qualquer sinal contínuo cuja variação no tempo representa a

variação de uma grandeza física, fazendo assim uma analogia entre a grandeza e sua
representação elétrica.

91
 UNIDADE III │ PROTOCOLO HART

As grandezas físicas em geral podem ser representadas por sinais analógicos, por
exemplo, podemos citar as seguintes grandezas:

» Temperatura.

» Pressão.

» Nível de um líquido ou reservatório.

Nas indústrias onde são utilizados os sinais analógicos, podemos citar exemplos
como os sinais analógicos:

» 0 a 10 V.

» 4 a 20 mA.

Assim, para demostrar essa tipo de representação, por exemplo, podemos definir
que uma temperatura na faixa de 0° C a 100° C será representada por um sinal
analógico de 4 a 20 mA. Dessa maneira, quando a temperatura for 0° C, o sinal terá
4 mA, quando a temperatura for 50° C, o sinal terá 12 mA e quando a temperatura
for 100° C o sinal analógico terá 20 mA. Na figura 50 temos um exemplo de leitura
de um Sensor PTC por um PLC utilizando o padrão de 4 a 20mA por meio de um
transmissor(tx).

Figura 50. Exemplo sensor PT100.

Entrada analógica
SENSOR(PT100)
Do CLP

4-20Ma CURRENT

Até 2 Km
Fonte: Elaborada pelo autor.

Em geral, pode-se dizer que 4mA corresponde a 0% da variável de controle e

20mA corresponde a 100% da variável de controle. A variável de controle, no
caso, representa a grandeza que está sendo medida e convertida em um sinal
elétrico.

Quando nos deparamos pela primeira vez com esse padrão 4 a 20mA, é natural
que surjam alguns questionamentos, tais como:

» Por que transmitir um sinal de corrente e não de tensão?

92
 PROTOCOLO HART │ UNIDADE III

» Por que a faixa vai e 4mA a 20mA?

» Não seria mais apropriado utilizar uma faixa de 0mA a 20mA?

» Por que 20mA e não 50mA ou 100mA?

Primeiramente, os sinais de corrente não sofrem o efeito da queda de tensão

que ocorre na linha, nas conexões e em demais elementos do circuito. Sendo
assim, se transmitíssemos um sinal de tensão, em cada comprimento de linha
de transmissão, teríamos diferentes quedas de tensão. Como resultado, seriam
produzidos erros difíceis de serem conhecidos no sinal recebido.

Já com o sinal de corrente esse problema não se verifica, uma vez que o
transmissor irá manter a corrente constante e proporcional à variável do
processo. Entretanto, para que isso seja possível, a fonte de alimentação deve
suportar o total das quedas de tensão e possíveis elementos inseridos em série
com a linha de transmissão tais com PLCs, medidores etc. Se essas condições
são atendidas, o sinal será transmitido sem alterações.

Em segundo lugar, podemos citar pelo menos duas razões fundamentais para se
utilizar a faixa de 4 a 20mA:

» Se utilizamos 4mA como valor mínimo a ser transmitido, podemos,

seguramente, alimentar nosso circuito transmissor com 3mA.
Isso é fundamental para o transmissor a dois fios, uma vez que
ele não terá uma fonte de alimentação de tensão contínua. Sua
alimentação será retirada da própria linha de transmissão do
sinal (dois fios). Esse procedimento simplifica e reduz o custo do
sistema de medição.

» Qualquer sinal abaixo de 4mA indica que há algum problema no

sensor ou no circuito ou na linha de transmissão (um sinal igual a
zero, por exemplo, pode ser um bom indicativo de que a linha de
transmissão foi interrompida!).

Há vários anos tem sido o sinal analógico de corrente a comunicação de campo

padrão usada pelos equipamentos de controle de processos. Esse sinal de corrente
varia dentro de toda a extensão da faixa de 4-20mA de maneira proporcional
à variável de processo que está sendo representada – isso para a maioria das
aplicações. Virtualmente, todos os sistemas de controle de processos de plantas
industriais usam esse padrão internacional para transmitir a informação da
variável de processo.

93
 UNIDADE III │ PROTOCOLO HART

A figura 51 nos ajuda a entender o funcionamento do padrão 4 a 20mA. Nela

temos um loop de corrente analógica, onde os sinais de um transmissor variam a
corrente que passa por ele de acordo com o processo de medição. O controlador
detecta a variação de corrente através da tensão sob um resistor sensor de
corrente. A corrente de loop varia de 4 a 20mA para frequências usualmente
menores que 10 Hz.

Figura 51. Loop de corrente.

Variável de processo

Fonte de
alimentação
4-20mA
Conversor A/D

Controlador Transmissor

Resistor Sensor de Corrente

Fonte: SMAR disponível em: http://www.smar.com/images/index150_fig32.jpg.

Abaixo, na figura 52, temos o loop de corrente acrescido do dispositivo HART.

Figura 52. Loop de Corrente acrescido do HART.

Variável de processo

Fonte de
alimentação
4-20mA
Conversor A/D
Fonte de
corrente AC

Modem
Amplificador REC

Modem
Amplificador REC

Controlador HART Transmissor

R – resistor sensor de corrente

Fonte: SMAR <http://www.smar.com/images/index150_fig33.jpg>.

94
 PROTOCOLO HART │ UNIDADE III

Vemos que entradas de equipamentos preparados para receberem sinais do

tipo 4 a 20mA (ou 0 a 20mA) possuem uma impedância de entrada baixa,
menor de 500Ω, sendo 250Ω um valor bastante comum, que ajuda a atenuar
o ruído, resultando num sinal mais “limpo”.

Outro detalhe importante a ser observado é que equipamentos com saída em

corrente sempre têm especificada a impedância máxima a ser conectada aos seus
terminais. Embora a saída 4 a 20mA tenha o comportamento de uma fonte de
corrente, ela possui uma limitação quanto à máxima tensão formada sobre a sua
saída. Por exemplo: uma saída de 4 a 20mA aplicado sobre uma impedância de
250Ω ocasionará tensões de até 5V sobre a saída do equipamento (250Ω x 0,020A
= 5V) e, caso este valor de tensão seja demasiadamente alto, poderá provocar a
despolarização da saída do transdutor. Geralmente, as impedâncias de carga não
são superiores a 500Ω para saídas do tipo 4 a 20mA ou 0 a 20mA.

Mas por que 250Ω é um valor comum para uma saída 4 a 20mA? Pois, neste caso,
quando tivermos 4mA, teremos 1V na entrada de sinal (250Ω x 0,004A = 1V) e em
20mA teremos 5V (250Ω x 0,020A = 5V). Na sua grande maioria, os conversores
A/D operam com tensões de entrada com valor máximo de 5V. Portanto, para
adequar o sinal a esse AD, pela lei de Ohm, basta utilizarmos um resistor de
precisão de 250 ohms na entrada do conversor A/D. Assim, ao ser alimentado
por um sinal de 4 a 20mA teremos uma tensão de entrada de 1V a 5V no AD. Esse
sinal poderá ser aplicado diretamente em uma entrada de microcontrolador, que
possui, na maioria das vezes, uma entrada 0 a 5V.

Outra vantagem deste tipo de saída é que se a conexão entre a entrada e a saída do
sinal se romper, será percebida a falta de corrente no circuito, o que resulta 0mA
na entrada de sinal. Como em condições normais a corrente nunca é 0mA (fica
sempre entre 4 e 20mA), a falta de corrente indicaria falha na conexão ou falha em
algum dos equipamentos que estão interligados.

Mais um ponto a favor da saída 4 a 20mA e 0 a 20mA é referente a um melhor

resultado em ligações à distância. Como a saída é em corrente, não há perda
de sinal no caminho. O sinal de corrente nos terminais do equipamento que
recebe o 4 a 20mA sempre será o mesmo sinal de corrente que sai dos terminais
do equipamento que envia o 4 a 20mA. Entretanto, deve-se cuidar para que
as impedâncias dos fios de conexão, somadas às impedâncias de entrada do
equipamento que recebe o sinal, não exceda a impedância máxima especificada
pelo equipamento que envia o sinal em corrente.

95
 UNIDADE III │ PROTOCOLO HART

Poderíamos citar como desvantagem deste padrão de sinal o fato de termos

certa limitação da quantidade de equipamentos a serem conectados em uma
única saída. Ao contrário dos sinais de saída em tensão, não podemos colocar
entradas em paralelo, pois o sinal em corrente se dividiria entre as diferentes
entradas, causando um grande erro de leitura. A alternativa, então, é a conexão
dos equipamentos em série.

Nesse último caso, as impedâncias de entradas dos equipamentos que estão

recebendo o sinal teriam que ser somadas, fazendo com que a tensão aumente
nos terminais do equipamento que está enviando sinal. Normalmente, pode-se
conectar no máximo 2 ou 3 equipamentos em série em uma saída 4 a 20mA (a
soma das impedâncias de entrada não pode exceder a impedância máxima aceita
como carga).

HART e a modulação

O Protocolo HART usa o padrão Bell 202 de chaveamento por deslocamentos de

frequência (FSK) para sobrepor os sinais de comunicação digital ao de 4-20mA.

Por ser o sinal digital FSK simétrico em relação ao zero, não existe nível DC
associado ao sinal e, portanto, ele não interfere no sinal de 4-20mA. A lógica “1”
é representada por uma frequência de 1200Hz e a lógica “0” é representada por
uma frequência de 2200Hz, como mostrado na figura 53.

Figura 53. Modulação sinal HART.

Average current change during communication = 0

+ 0.5 mA Digital
Signal
Analog
0 mA Signal

- 0.5 mA
1200 2200
Hz Hz
“’1” “’0”
Fonte: <https://4.bp.blogspot.com/-Ti0TlMLgZuI/U44A8S7l9BI/AAAAAAAABIA/fvocvKtuNR8/s1600/HART+Signal.jpg>.

96
 PROTOCOLO HART │ UNIDADE III

O sinal HART FSK possibilita a comunicação digital em duas vias, o que torna
possível a transmissão e recepção de informações adicionais, além da normal,
que é a variável de processo em instrumentos de campo inteligentes. O protocolo
HART se propaga a uma taxa de 1200 bits por segundo, sem interromper o sinal
4-20mA e permite uma aplicação tipo “mestre”, possibilitando duas ou mais
atualizações por segundo vindas de um único instrumento de campo. A figura 54
ilustra a sobreposição do sinal HART sobre o padrão 4 a 20mA.

Figura 54. Sinal HART.

+0.5mA
Sinal HART
20mA
2200
-0.5mA Hz
1200 “0”
Hz
“1”

Analogue
Signal

C = command
4mA R = response

Time (sec)

Fonte: <http://www.romilly.co.uk/hartwave.gif>.

Esse tipo de modulação é robusto e possui imunidade a ruídos muito boa. Um

chip de modem HART é usado nas extremidades de envio e recebimento para
modulação e demodulação, respectivamente. Os dispositivos HART suportam
o sinal de corrente convencional de 4 a 20 mA e as comunicações HART
moduladas. Eles ocupam diferentes faixas de comunicação, como é ilustrado
na figura 55. Devido à sua natureza não interferente, como é evidente na figura
acima, ambas as comunicações são possíveis simultaneamente. O sinal de
comunicação HART é filtrado pelos dispositivos analógicos e, como tal, eles
não são afetados pelo sinal HART. Portanto, dispositivos com entrada ou saída
de 4 a 20 mA funcionam bem nos circuitos de controle.

97
 UNIDADE III │ PROTOCOLO HART

Figura 55. Band de frequência do sinal HART.

Frequency Bands For 4-20mA & HART Signals

Frequency Bands Frequency Bands
Response For 4-20mA Signal For HART Signal

DC 25Hz 500Hz 10KHz

Frequency
InstrumentationTools.com

Fonte: <https://instrumentationtools.com/wp-content/uploads/2016/08/instrumentationtools.com_frequency-bands-for-4-20ma-
and-hart-signals.png>.

Modos de comunicação

O sinal de comunicação digital tem um tempo de resposta de aproximadamente 2-3

atualizações de dados por segundo sem interromper o sinal analógico. É necessária
uma impedância mínima do circuito de 230 Ω para a comunicação.

Os dispositivos que suportam o protocolo HART são agrupados em mestre (host)

e dispositivos escravos (de campo). Os dispositivos principais incluem terminais
portáteis, bem como locais de trabalho baseados em PC, por exemplo, na sala
de controle. Dispositivos escravos HART, por outro lado, incluem sensores,
transmissores e vários atuadores. A variedade vai de dispositivos de dois e quatro
fios a versões intrinsecamente seguras para uso em ambientes perigosos.

Alguns dispositivos HART suportam o modo de comunicação burst. O modo burst

permite uma comunicação mais rápida (3 a 4 atualizações de dados por segundo).
Nesse modo, o mestre instrui o dispositivo escravo a transmitir continuamente
uma mensagem de resposta HART padrão (por exemplo, o valor da variável do
processo). O mestre recebe a mensagem com uma taxa mais alta até instruir o
escravo a para o burst.

98
 PROTOCOLO HART │ UNIDADE III

Os dados HART são sobrepostos ao sinal de 4 a 20 mA através de um modem FSK.

Isso permite que os dispositivos se comuniquem digitalmente usando o protocolo
HART, enquanto a transmissão do sinal analógico ocorre ao mesmo tempo.

Os dispositivos de campo e os terminais portáteis compactos possuem um

modem FSK integrado, enquanto as estações de PC possuem uma interface
serial para conectar o modem externamente. A figura 56 mostra um esquema de
conexão típico de um dispositivo host HART e um dispositivo de campo HART.
A comunicação HART é frequentemente usada para conexões ponto a ponto. No
entanto, muitas outras variantes de conexão são possíveis.

Figura 56. Conexão de um dispositivo mestre HART.

PC control station

FSK modem

Field device 4 to 20mA HART

Field device

Fonte: Elaborada pelo autor.

Em sistemas estendidos, o número de dispositivos acessíveis pode ser aumentado

usando um multiplexador. Além disso, o HART permite a conexão em rede de
dispositivos para aplicativos especiais. As variantes de rede incluem multiponto,
barramento FSK e redes para operação em faixa dividida.

Ponto a ponto

A comunicação HART mostrada na figura 57 é referida como conexão ponto a

ponto, ou seja, o dispositivo mestre HART está conectado a um dispositivo HART
de campo. Essa variante de conexão requer que o endereço do dispositivo de
campo seja sempre definido como zero, pois o programa operacional usa esse
endereço para estabelecer a comunicação.

99
 UNIDADE III │ PROTOCOLO HART

No modo ponto a ponto, o sinal de 4-20mA é usado para comunicar uma variável de
processo, enquanto variáveis de processo adicionais, parâmetros de configuração
e outros dados do dispositivo são transferidos digitalmente usando o Protocolo
HART. O sinal analógico de 4-20mA não é afetado pelo sinal HART e pode ser
usado para controle. O sinal digital da comunicação HART fornece acesso a
variáveis secundárias e outros dados que podem ser usados para fins de operação,
comissionamento, manutenção e diagnóstico.

Figura 57. Comunicação ponto a ponto.

Estação de
Controle

Modem HI311
FSK

LD301

Fonte: SMAR <http://www.smar.com/uploads/images/36.JPG>.

Multidrop

O modo de operação multidrop requer apenas um único par de fios e, se

aplicável, barreiras de segurança e uma fonte de alimentação auxiliar para até
15 dispositivos de campo (HART 5) ou 62 dispositivos de campo (HART 7), como
ilustra a figura 58. Todos os valores do processo são transmitidos digitalmente.
No modo multiponto, todos os endereços de pesquisa de dispositivos de
campo devem ser exclusivos no intervalo de 1 a 63 (dependendo da revisão do
protocolo HART) e a corrente em cada dispositivo é fixada em um valor mínimo
(normalmente 4mA).

100
 PROTOCOLO HART │ UNIDADE III

Figura 58. Comunicação multidrop.

IMPEDÂNCIA PARA
FONTE DE
EN
ALIMENTAÇÃO

PSI301
#5
#1 #2 #3 #4

FONTE DE
ALIMENTAÇÃO

Fonte: SMAR <http://www.smar.com/uploads/images/38.JPG>.

Use a conexão multidrop para instalações de controle supervisório que são

amplamente espaçadas, como tubulações, estações de transferência de custódia e
fazendas de tanques.

Multiplexador

A figura 59 mostra o uso de um sistema multiplexador, que permite um grande

número de dispositivos HART a serem conectados em uma rede. O usuário
seleciona um determinado loop de corrente para comunicação via programa
operacional. Quando a comunicação ocorre, o multiplexador conecta o loop atual
ao hospedeiro. Devido à estrutura do multiplexador em cascata, o host pode se
comunicar com muitos dispositivos (.1000), todos com o endereço zero.

Figura 59. Comunicação com multiplex.

Host

Modem
FSK
H311

Multiplexer

Equipamentos Hart

LD30
Controlador 1 Address 0

TT30 Address 0
Controlador 1

FY30 Address 0
Controlador 1

Fonte: SMAR <http://www.smar.com/uploads/images/37.JPG>.

101
 UNIDADE III │ PROTOCOLO HART

Faixa estendida

Existem aplicações especiais que exigem que vários atuadores recebam o mesmo
sinal de controle – geralmente, as aplicações usam dois atuadores. Um exemplo
típico é operação de válvulas de controle em intervalo dividido. Uma válvula opera
na faixa de corrente nominal de 4 a 12 mA, enquanto a outra usa a faixa de 12 a 20
mA. Em operação com faixa dividida, as válvulas de controle são conectadas em
série no circuito de corrente. Quando as duas válvulas têm uma interface HART,
o dispositivo host HART deve ser capaz de distinguir com qual válvula deve se
comunicar.

Figura 60. Comunicação faixa estendida.

Estação de
controle

Modem FSK
HI311

FY301
END = 1
Controlador
Amplificador
isolador

FY301
END = 2

Fonte: SMAR <http://www.smar.com/uploads/images/39.JPG>.

Como é o caso do modo multiponto, cada dispositivo é atribuído a um endereço de

1 a 15. O sinal analógico de 4 a 20 mA preserva sua função específica, que é, para
válvulas de controle, a seleção do curso necessário. Para poder usar as comunicações
HART também para aplicativos como o operação em faixa dividida, o posicionador
HART da SAMSON sempre tira sinal de corrente analógico como variável de
referência, independente do endereço do dispositivo.

Barramento FSK

O protocolo HART pode ser estendido por funções específicas da empresa.

Hartmann & Braun, por exemplo, desenvolveu o barramento FSK. Semelhante
102
 PROTOCOLO HART │ UNIDADE III

a um dispositivo barramento, ele pode conectar aproximadamente 100

dispositivos HART e endereçá-los. Este requer amplificadores de isolamento do
tipo montagem especial. O único motivo do número limitado de dispositivo é que
cada dispositivo adicional aumenta o ruído do sinal. Assim, a qualidade do sinal
não é mais suficiente para avaliar adequadamente o telegrama.

Os dispositivos HART são conectados ao seu sinal de corrente analógico e à

linha de barramento FSK comum através do amplificador de isolamento. Do
ponto de vista do barramento FSK, os amplificadores de isolamento atuam
como conversores de impedância. Isso permite também dispositivos com alta
carga a serem integrados na rede de comunicação.

Comandos HART

O Protocolo HART é um protocolo de comunicação mestre-escravo, o que

significa que durante a operação normal, cada comunicação escrava (um
dispositivo de campo) é iniciada por uma solicitação (ou comando) do dispositivo
de comunicação mestre (host). O mestre ou host é geralmente um controle
distribuído, PLC ou sistema de gerenciamento de ativos baseado em PC, por
exemplo. O dispositivo escravo é tipicamente um dispositivo de medição de
campo, como pressão, nível, temperatura, fluxo ou outros transmissores.

Para garantir que qualquer dispositivo habilitado para HART de qualquer

fornecedor possa se comunicar adequadamente e responder a um comando com
as informações corretas, o conjunto e os tipos de comandos são definidos nas
Especificações HART e implementados em todos os dispositivos registrados
HART.

Os usuários não precisam se preocupar com esses comandos porque eles

estão incluídos nas funções do host. Os recursos e comandos específicos de
um dispositivo estão disponíveis para o host quando ele recebe as instruções
incluídas na descrição do dispositivo (DD) de um dispositivo específico.

Um ponto importante é que as indicações definidas de status do dispositivo

são incluídas em cada resposta de comunicação ao host. O host interpreta esses
indicadores de status e pode fornecer informações básicas de diagnóstico do
dispositivo.

O conjunto de comandos HART fornece comunicação uniforme e consistente

para todos os dispositivos de campo. Os aplicativos host podem implementar

103
 UNIDADE III │ PROTOCOLO HART

qualquer um dos comandos necessários para um aplicativo específico. O

conjunto de comandos inclui três classes:

» Universal: todos os dispositivos que usam o protocolo HART devem

reconhecer e suportar os comandos universais. Os comandos
universais fornecem acesso a informações úteis em operações
normais (por exemplo, leia variáveis e unidades primárias).

Quadro 25. Comandos universais.

Comandos universais
Ler o fabricante e o tipo de dispositivo.
Ler variável primária (PV) e unidades.
Ler a saída atual e porcentagem da faixa.
Ler até quatro variáveis dinâmicas predefinidas.
Ler ou gravar tag de oito caracteres, descritor de 16 caracteres, data.
Ler os valores da faixa do dispositivo, unidades e constante de tempo de amortecimento.
Ler ou escrever o número da montagem final.
Escrever endereço de pesquisa.
Fonte: Elaborada pelo autor.

» Prática comum: os comandos da prática comum fornecem funções

implementadas por muitos, mas não necessariamente todos,
dispositivos de comunicação HART.

Quadro 26. Comandos universais.

Comandos universais
Ler a seleção de até quatro variáveis dinâmicas.
Escrever constante de tempo de amortecimento.
Gravar valores do intervalo do dispositivo.
Calibrar (definir zero, definir intervalo).
Definir corrente de saída fixa.
Executar autoteste.
Ajuste de zero da variável de processo (PV)
Gravar unidade fotovoltaica.
Ajuste de zero e de ganho do conversor analógico digital (DAC)
Função de transferência de gravação (raiz quadrada/linear).
Escrever o número de série do sensor.
Ler ou gravar atribuições de variáveis dinâmicas.
Fonte: Elaborada pelo autor.

» Dispositivo específico: comandos específicos representam funções

que são exclusivas para cada dispositivo de campo. Esses comandos
acessam informações de configuração e calibração, além de

104
 PROTOCOLO HART │ UNIDADE III

informações sobre a construção do dispositivo. Informações sobre

comandos específicos do dispositivo estão disponíveis nos fabricantes
do dispositivo.

Quadro 27. Dispositivo específico.

Dispositivo específico
Ler ou gravar um corte de baixo fluxo.
Iniciar, parar ou limpar o totalizador.
Fator de calibração de densidade de leitura ou gravação.
Escolher PV (massa, fluxo ou densidade).
Ler ou escrever materiais ou informações de construção.
Calibrar o sensor de compensação.
Ativar PID.
Gravar ponto de ajuste do PID.
Caracterização da válvula.
Ponto de ajuste da válvula.
Limites de viagem.
Unidades de usuário.
Informações de exibição local.
Fonte: Elaborada pelo autor.

Os comandos HART são baseados nos serviços das camadas inferiores e permitem
uma comunicação aberta entre o mestre e os dispositivos de campo. Essa abertura
e a intercambialidade dos dispositivos independentes do fabricante estão
disponíveis apenas desde que os dispositivos de campo operem exclusivamente
com os comandos universais e de prática comum, e desde que o usuário não
precise mais do que a simples notação padrão HART para as mensagens de
status e de falha.

Quando o usuário deseja que a mensagem contenha mais informações

relacionadas ao dispositivo ou que propriedades especiais de um dispositivo
de campo também sejam usadas, os comandos de prática comum e universal
não são suficientes. Usar e interpretar os dados requer que o usuário saiba seu
significado. Contudo, esse conhecimento não está disponível em outros sistemas
de extensão que podem integrar novos componentes com opções adicionais.
Para eliminar a adaptação do software do dispositivo principal sempre que
uma mensagem de status adicional for incluída ou um novo componente for
instalado, o idioma de descrição do dispositivo (DDL) foi desenvolvido.

O DDL não se limita ao uso para aplicativos HART. Foi desenvolvido e

especificado para Fieldbus, independente do protocolo HART, pelo workshop
de Interface Humana do International Fieldbus Group (IFG).

105
 UNIDADE III │ PROTOCOLO HART

Os desenvolvedores da linguagem DDL de descrição do dispositivo visavam

alcançar usabilidade versátil. O DDL encontra também uso em redes de campo.
A flexibilidade exigida é garantida na medida em que o DDL não determine por
si só o número e funções das interfaces do dispositivo e sua representação nas
estações de controle. O DDL é uma linguagem semelhante a uma linguagem de
programação que permite aos fabricantes de dispositivos descrever todas as
opções de comunicação de maneira exata e completa.

A DDL permite que o fabricante descreva:

» Atributos e informações adicionais sobre elementos de dados de

comunicação.

» Todos os estados operacionais do dispositivo.

» Todos os comandos e parâmetros do dispositivo.

» A estrutura do menu, fornecendo assim uma representação clara de

todos os recursos funcionais do dispositivo.

Tendo a descrição de um dispositivo de campo e a capacidade de interpretá-lo,

um dispositivo principal está equipado com todas as informações necessárias
para fazer uso dos recursos completos de desempenho do dispositivo de campo.

Assim, os comandos específicos do dispositivo e do fabricante também podem ser

executados e o usuário recebe uma interface de usuário universalmente aplicável e
uniforme, permitindo que ele represente e execute claramente todas as funções do
dispositivo. Graças a essas informações adicionais, a operação e o monitoramento
claros, exatos e, portanto, mais seguros de um processo são possíveis.

Figura 61. DD.

Zero: 40.0 °C

Designation Parameter valor Unit

Additional DD information:

Data type: Fixed-point format

Range of values: 0 to 99.9
Type of access: Readable and changeable
Input mode: via numeric keyboard
Representation format: ##.#

Fonte: Elaborada pelo autor.

106
 PROTOCOLO HART │ UNIDADE III

O dispositivo mestre não lê a descrição do dispositivo como texto legível na

sintaxe DDL, mas como um registro de dados DD curto, codificado em binário,
gerado especialmente pelo codificador DDL. Para dispositivos com capacidade
de armazenamento suficiente, esse pequeno formulário abre a possibilidade
de armazenar a descrição do dispositivo já no firmware do dispositivo de
campo. Durante a fase de parametrização, pode ser lida pelo dispositivo mestre
correspondente.

107
 CAPÍTULO 2
Codificação

Introdução
O formato do quadro de mensagens HART, geralmente chamado de telegrama
HART, é mostrado na figura 62 abaixo. É composto por nove campos.

Figura 62. Telegrama HART.

PREAMBLE START ADDR EXP COM BCTN STATUS DATA CHK

Fonte: Elaborada pelo autor.

PREAMBLE: Preâmbulo é o primeiro campo na mensagem que é enviada;

possui entre 5 e 20 bytes comm valor hexadecimal FF (todos os bits em 1), ajuda
a sincronizar o fluxo de caracteres ativando e sincronizando todos os receptores
dos dispositivos conectados na rede. O start, um campo de byte único, indica o
fim do preâmbulo.

START: O start é um campo inicial e seu conteúdo indica se o quadro é uma

solicitação de um mestre, uma resposta de um escravo ou uma solicitação de um
escravo no modo burst. Também indica se o endereço usado é um endereço de
pesquisa ou um ID exclusivo, bem como a quantidade de bytes no campo EXP.

ADDR: O campo de endereço a seguir pode ser um byte único (formato de quadro
curto) para o endereço de pesquisa ou 5 bytes (formato de quadro longo) para um
endereço de ID exclusivo.

EXP: O campo de expansão permite a inserção de até 3 bytes adicionais entre os

campos de endereço e comando. O número de bytes presentes será indicado pelos
bits 6 e 5 no delimitador de início. Uso desse recurso, introduzido no HART rev.
6, ainda não foi definido.

COM: O byte de comando contém o comando HART para esta mensagem. Os

comandos universais estão no intervalo de 0 a 30; comandos de prática comum
estão no intervalo de 32 a 126; comandos específicos do dispositivo estão no
intervalo de 128 a 253. HART rev. 6 introduziram “comandos estendidos” de 16

108
 PROTOCOLO HART │ UNIDADE III

bits para comandos da família de dispositivos. Eles colocam 31 (hex 1f) nesse byte
e o número do comando de 2 bytes como os 2 primeiros bytes no campo “dados”.

BCTN: Contém o número de bytes a seguir nos bytes de status e dados, excluindo
a soma de verificação. O destinatário pode, assim, verificar o final da mensagem a
partir das informações fornecidas por este campo.

STATUS: O campo de status (também conhecido como “código de resposta”)

é de dois bytes, presente apenas na mensagem de resposta de um escravo.
Ele contém informações sobre erros de comunicação na mensagem de saída,
o status do comando recebido e o status do próprio dispositivo. Este campo
de resposta do escravo indicaria o tipo de erro que ocorreu na mensagem
recebida, se foi recebido erroneamente. A recepção correta da mensagem
também seria indicada por esse campo.

Data: O campo de dados pode ou não estar presente, dependendo do comando

específico. Os comandos universais e de prática comum usam até 33 bytes
de dados, mantendo a duração geral da mensagem razoável (mas alguns
dispositivos possuem comandos específicos do dispositivo, usando campos de
dados mais longos). Os dados não são interpretados na camada de vínculo de
dados e são meramente passados para a camada de aplicativo.

CHK: A soma de verificação é de um byte único e do tipo de verificação de

redundância cíclica longitudinal. Se os dados forem recebidos corretamente,
o valor da soma de verificação final de transmissão será idêntico à soma de
verificação final de recebimento.

O HART usa um modo assíncrono para fins de comunicação. Assim, os dados HART
são transmitidos 1 byte por vez, sem nenhum sinal de clock. Um caractere HART é
composto por 11 bits e mostrado na figura 63.

Figura 63. Caractere HART.

START BIT BIT BIT BIT BIT BIT BIT BIT PARITY STOP
BIT 1 2 3 4 5 6 6 6 6 BIT

Fonte: Elaborada pelo autor.

O caractere começa com um bit inicial, seguido por oito bits de dados, um bit de
paridade e, finalmente, um bit de parada. O bit de paridade fornece integridade
aos dados transmitidos, ou seja, atua como um verificador de erro do byte
transmitido.

Assim, cada caractere do telegrama HART é transmitido seguindo essa definição

de caractere.

109
 CAPÍTULO 3
Aplicações e benefícios

Aplicação no Scada
A tecnologia usada no HART é muito útil para aplicativos SCADA (Supervisory
Control and Data Acquisition). Como o HART suporta valores de processo digital,
ele pode ser aplicado no SCADA. Vários parâmetros de status de PVs obtidos a
partir de medições HART podem ser usados para agendar viagens de campo para
manutenção preventiva. Isso resultaria em menos tempo de inatividade e menos
emprego de mão de obra.

Figura 64. ScadaBR.

Fonte: <https://miro.medium.com/max/5000/1*InQiTp4ru0cECUX4TcGIqw.png>.

Os aplicativos SCADA requerem a atualização dos dados do campo em minutos.

Como a atualização de dados usando o HART requer apenas uma fração de
segundo, ela pode ser aplicada com segurança nos aplicativos SCADA. Outras
áreas de aplicação em que o HART pode ser aplicado no SCADA são gerenciamento
de inventário, leitura automatizada de medidores, monitoramento de dutos
situados em locais distantes e monitoramento remoto de unidades de produção
localizadas remotamente, como ilustra a figura 66.

Figura 65. Aplicação do SCADA.

Servidor Barramento
Interface de usuário Processo controlado
do SCADA (protocolos)
(HMI = Human-Machine Interface) (máquinas/equipamentos)
de comunicação
Sensor. Atuadores e controladores

Fonte: <https://sites.google.com/a/certi.org.br/certi_scadabr/_/rsrc/1468847541134/home/minicursos/iniciando-scadabr/scada-
intro.png>.

110
 PROTOCOLO HART │ UNIDADE III

ScadaBR é um software livre, gratuito e de código-fonte aberto, para

desenvolvimento de aplicações de automação, aquisição de dados e
controle supervisório.

O ScadaBR pretende oferecer todas as funcionalidades de um sistema

SCADA tradicional. Este tipo de software existe desde o final dos anos
1960, e é uma peça fundamental em qualquer tipo de aplicação
computadorizada que envolva máquinas, controladores programáveis
(CLPs), acionamentos eletrônicos e sensores.

Em resumo, podemos dizer que o SCADA funciona como um componente

central de um sistema de automação, monitorando todos os dispositivos e
oferecendo acesso organizado a seus controles e parâmetros.

O público-alvo do ScadaBR abrange profissionais de automação,

universidades, escolas técnicas e empresas de todos os portes, que
necessitam comandar máquinas diversas através de um computador,
executar lógicas de automação, ou simplesmente visualizar dados de
sensores, ambientes e processos industriais.

Também é ideal para “hobbystas” e inventores, em suas próprias garagens

e laboratórios, permitindo manipular uma vasta linha de instrumentos e
acessórios, a partir de qualquer lugar, e em um mesmo sistema.

Para maiores informações sobre o ScadaBR, consulte a site do software,

disponível em: <http://www.scadabr.com.br/>.

Benefícios do Protocolo HART

O protocolo HART é um recurso de comunicação exclusivo que é compatível com

versões anteriores, garantindo que os investimentos existentes em cabeamento da
planta e necessidades de energia permaneçam seguros no futuro. É o único recurso
de comunicação que suporta comunicação analógica e digital (híbrida) ao mesmo
tempo. Ao preservar o sinal tradicional de 4 a 20 mA, ele amplia a capacidade do
sistema para comunicação digital bidirecional com instrumentos multivariáveis
de campo inteligente. Qualquer aplicativo de processo pode ser endereçado pelos
serviços oferecidos pelo protocolo HART.

A simplicidade do protocolo HART e o custo muito baixo dos dispositivos de

campo compatíveis com HART são a base para sua ampla aceitação nos sistemas
de instrumentação de processos. Algumas das outras vantagens decorrentes

111
 UNIDADE III │ PROTOCOLO HART

do emprego de protocolos HART nas indústrias de processo são: padrão de fato

totalmente aberto, vários dispositivos inteligentes ao longo da mesma rodovia,
vários mestres podem controlar o mesmo dispositivo inteligente, comunicação
de longa distância via linhas telefônicas. Usando um conversor HART – CCITT,
é possível cuidar de até 256 PVs pertencentes ao mesmo dispositivo, adição de
novos recursos sem muita dificuldade, acesso aos parâmetros e diagnósticos do
dispositivo, comando e estrutura de dados comuns, uma grande e crescente seleção
de produtos disponíveis.

Em resumo, podemos dizer que:

» A tecnologia HART permite a comunicação digital bidirecional entre

dispositivos inteligentes e sistemas de host ou controle conectados.

» O HART é uma tecnologia capacitadora, o que significa que pode

ser aplicada em muitas aplicações diferentes, incluindo controle,
monitoramento, segurança, gerenciamento de ativos etc.

» O HART fornece dois canais de comunicação simultâneos: o sinal

analógico de 4-20mA e um sinal digital.

» O sinal digital contém informações do dispositivo, incluindo status,

diagnóstico, valores adicionais medidos ou calculados etc.

» O sinal 4-20mA comunica o valor primário medido (no caso de um

instrumento de campo) usando o loop de corrente 4-20mA.

» A parte de comunicação digital da comunicação é um protocolo de

comunicação de solicitação-resposta, o que significa que durante a
operação normal, cada comunicação de dispositivo é iniciada por uma
solicitação de um dispositivo host.

» O sinal digital é composto de duas frequências – 1.200 Hz e 2.200

Hz, representando os bits 1 e 0. As ondas senoidais dessas duas
frequências são sobrepostas ao fio do sinal analógico de corrente
contínua (dc) para fornecer comunicações analógicas e digitais
simultâneas.

» É necessária uma impedância mínima de loop de 230 ohms para

comunicação.

» Os dispositivos HART podem operar em uma das duas configurações

de rede ponto a ponto ou multiponto.

112
 PROTOCOLO HART │ UNIDADE III

» O conjunto de comandos HART inclui três classes: universal, prática

comum e específico do dispositivo.

» Existem 35-40 itens de dados que são padrão em todos os dispositivos

registrados no HART. Os aplicativos host podem implementar
qualquer um dos comandos necessários para um aplicativo específico.

» Os fornecedores de dispositivos HART fornecem um arquivo DD

para cada dispositivo HART e o arquivo DD combina todas as
informações necessárias ao aplicativo host em um único arquivo
estruturado.

» O arquivo DD inclui todas as informações necessárias por um

aplicativo host para se comunicar totalmente com o dispositivo de
campo e acessar todas as informações disponíveis no dispositivo.

» A nova linguagem de descrição de dispositivo aprimorada HART

amplia os recursos do DDL para fornecer visualização avançada de
informações inteligentes do dispositivo.

» O protocolo HART é compatível com a base instalada de sistemas de

instrumentação e controle em uso atualmente. Um novo dispositivo
habilitado para HART pode substituir um dispositivo analógico de
4-20 mA existente com capacidade de medição semelhante sem
alterar o sistema ou fio host.

» A maioria dos dispositivos HART fornece várias variáveis de

processo, que podem ser usadas para monitoramento ou controle
para obter uma melhor compreensão do processo.

» O diagnóstico do dispositivo e as informações de status são

retornados a cada mensagem de comunicação.

» A prática de instalação de um dispositivo de comunicação HART é

semelhante para um instrumento convencional de 4-20mA.

113
 CAPÍTULO 4
Equipamentos industriais HART

Transmissor de temperatura TTS501

A temperatura é uma das variáveis físicas mais importantes que é medida nas
indústrias de processo. É muitas vezes um fator crítico para o processamento
industrial. Se a medição da temperatura não é precisa ou confiável, por qualquer
motivo, ela pode ter um efeito negativo sobre a eficiência do processo, consumo de
energia e qualidade dos produtos manufaturados.

Mesmo um pequeno erro de medição pode gerar grandes aborrecimentos ou sair

muito caro em alguns processos, por isso, é extremamente importante ter certeza
que as medições de temperatura sejam precisas e confiáveis.

A medição de temperatura na indústria é feita tipicamente utilizando um sensor

(geralmente um termopar ou termorresistência) em conjunto com um transmissor
de temperatura que converte o sinal do sensor (mV ou ohm) em um sinal de saída
em corrente ou tensão proporcional ao sinal gerado na entrada.

O TTS50, ilustrado na Figura 66, é um transmissor projetado para medir a

temperatura usando termopares (TCs) ou termorresistências (RTDs), porém outros
sensores com saídas de resistência ou mV podem ser usados com ele. A tecnologia
utilizada na fabricação do transmissor permite um interfaceamento fácil entre
o campo e a sala de controle e outras características interessantes, que reduzem
substancialmente os custos com instalação, operação e manutenção.

Figura 66. Transmissor de temperatura TTS501.

Fonte: <https://www.sense.com.br/arquivos/produtos/arq2/TTS501_Manual_de_Instalacao_Rev_Q.pdf>.

114
 PROTOCOLO HART │ UNIDADE III

O TTS501 foi especialmente projetado para trabalhar com termopar ou

termorresistência, porém outros tipos de sensores com sinais de resistência ou
milivolts podem ser utilizados.

Alguns conceitos básicos dos principais tipos de sensores são apresentados.

O termopar

Os termopares são os sensores mais largamente usados na medida de temperatura

nas indústrias. Consistem em dois fios de metal ou ligas diferentes unidas em um
extremo, chamado de junção de medida. A junção de medição deve ser colocada
no ponto onde se deseja efetuar a medição. O outro extremo do termopar é aberto
e conectado ao transmissor de temperatura. Este ponto é chamado junção de
referência ou junta fria.

Quando há uma diferença de temperatura ao longo de um fio de metal, surgirá

um pequeno potencial elétrico, peculiar em cada liga. Esse fenômeno é chamado
efeito Seebeck. Quando dois metais de materiais diferentes são unidos em uma
extremidade, deixando aberta a outra, uma diferença de temperatura entre as
duas extremidades resultará numa tensão, desde que os potenciais gerados em
cada um dos materiais sejam desiguais e não se cancelem reciprocamente.

Assim sendo, duas coisas importantes podem ser observadas.

» A tensão gerada pelo termopar é proporcional à diferença de

temperatura entre a junção de medição e a junção de junta fria.
Portanto, a temperatura na junção de referência deve ser adicionada
à temperatura da junta fria, para encontrar a temperatura medida.
Isso é chamado de compensação de junta fria, e é realizado
automaticamente pelo TTS501, que tem um sensor de temperatura
no terminal do sensor para esse propósito.

» Cabos de compensação ou extensão do termopar devem ser usados

até os terminais do transmissor, onde é medida a temperatura
da junta de referência. A milivoltagem gerada com relação à
temperatura medida na junção está relacionada em tabelas padrões
de calibração para cada tipo de termopar, com a temperatura de
referência 0 °C.

115
 UNIDADE III │ PROTOCOLO HART

Os termopares são padronizados, e na indústria são utilizados 8 tipos de

termopares distribuídos em 2 grupos:

» termopares de base metálica (tipos J, K, N, E e T);

» termopares de metais nobres (tipos R, S e B).

O quadro 28 apresenta a composição e intervalo de temperaturas de operação,

para os termopares padrão de acordo com a norma NBS.

Quadro 28. Tabela de termopar.

Tipo Positivo Negativo Intervalo de temperaturas (°C)

B Platina, 30% Ródio Platina, 30% Ródio +300 a 1700
C Tungstênio, 5% Ródio Tungstênio, 26% Ródio 0 a 2320
D Tungstênio,3% Rênio Tungstênio, 25% Rênio 0 a 2320
E Níquel,10% Crômo Cobre, 45% Níquel -200 a 900
G Tungstênio Tungstênio, 26% Rênio 0 a 2330
J Ferro Cobre, 45% Níquel -200 a 750
K Níquel, 10% Crômo Níquel, 2% Manganês, 2% Alumínio -200 a 1250
N Níquel, 14% Crômo, 1%Silício Níquel, 4%Si, 0.1%Mg -200 a 1350
R Platina, 13% Ródio Platina 0 a 1450
S Platina, 10% Ródio Platina 0 a 1450
T Cobre Cobre, 45% Níquel -200 a 350
Fonte: <https://www.profelectro.info/aquisicao-e-tratamento-de-dados-%E2%80%93-teoria-8-termopares-sensores-de-
temperatura/>.

A figura 67 ilustra a conexão do termopar com o transmissor TTS501. Pela figura,

observa-se que entre o sensor e o transmissor existe um cabo denominado cabo
de extensão ou compensação. Trata-se de um cabo especialmente projetado
para a ligação dos termopares até seu instrumento de leitura. Os condutores são
constituídos por ligas metálicas que possuem as mesmas características das ligas
metálicas dos termopares. Sendo assim, cada tipo de termopar tem seu cabo de
compensação apropriado.

A ligação do termopar com este tipo de cabo se faz necessária para que o sinal
gerado pelo sensor não apresente erros na leitura, pois ao ser conduzido por um
condutor metálico com características diferentes, o sinal teria perdas e outros
fenômenos elétricos.

116
 PROTOCOLO HART │ UNIDADE III

Figura 67. Termopar.

Junta medição Fios do Fios de Junta de

compensação ou
Termopar extensão referência
Fonte: <https://www.sense.com.br/arquivos/produtos/arq2/TTS501_Manual_de_Instalacao_Rev_Q.pdf>.

Os termopares constituídos de ligas metálicas nobres são mais caros por possuírem
elementos de alto custo em sua composição, como a platina e o ródio, caso
dos termopares tipo R, S e B. Neste caso em especial, são utilizados cabos com
condutores metálicos que compensam a perda de sinal ocorrida, eliminando assim
erros na leitura. Essa solução é utilizada porque os cabos de extensão compostos
pelas mesmas ligas metálicas dos sensores termopares ficaria inviável, do ponto
de vista financeiro.

Termorresistência (RTDs)

Termorresistência (RTD, do inglês Resistance Temperature Detector) é um

sensor de alta precisão e excelente repetibilidade de leitura. O funcionamento
da termorresistência se baseia na variação da resistência ôhmica em função da
temperatura. Seu elemento sensor, na maioria das vezes, é feito de platina de alta
pureza, encapsulado em bulbos de cerâmica ou vidro, conforme ilustra a figura 68.

Figura 68. Termorresistência.

Bubo de resistência Condutores

Rabicho

Isolação Bainha Isolador

mineral cerâmico

Fonte: <https://www.sense.com.br/arquivos/produtos/arq2/TTS501_Manual_de_Instalacao_Rev_Q.pdf>.

Normativamente, a termorresistência é identificada pelo material de sua construção

e pela resistência que gera a uma temperatura de 0 °C. Sendo assim, por exemplo,
uma Pt-100 é uma termorresistência construída com platina e a sua resistência na
temperatura de 0 °C é de 100Ω.

117
 UNIDADE III │ PROTOCOLO HART

Os RTDs padronizados, cujas tabelas estão armazenadas na memória do TTS501,

são os seguintes:

» PT50.

» PT100.

» PT500.

» PT1000.

Para efetuar medições corretas de temperatura utilizando o RTD, é necessário

que se elimine o efeito da resistência dos fios de conexão do sensor com o circuito
de medição. Os fios em questão podem ter extensões de centenas de metros em
determinadas aplicações industriais. Isso é particularmente importante em locais
onde a temperatura ambiente muda bastante.

Configuração

Nesse modo, todos os parâmetros de configuração do transmissor estão

disponíveis e podem ser acessados via programador manual ou software.

O TTS501 pode ser configurado remotamente por:

» Aplicativo – VMT-HART. Esse aplicativo transforma o smartphone

ou tablet Android em um HAND HELD, como ilustra a Figura 69.

» Software PACTware (tecnologia FDT/DTM), como ilustra a Figura 70.

» Outras tecnologias baseadas em FDT/DTM.

Figura 69. VMT-HART.

VMT-HART

TTS501r1

Identification

Configuration

Calibration

General

Monitoring

Loop test

Commit Back

Fonte: <https://www.sense.com.br/arquivos/produtos/arq2/TTS501_Manual_de_Instalacao_Rev_Q.pdf>.

118
 PROTOCOLO HART │ UNIDADE III

Ferramentas baseadas em FDT/DTM podem ser usadas para informação,

configuração, monitoração e visualização de diagnósticos de equipamentos com
a tecnologia HART. Exemplo dessas ferramentas são o PACTware e FieldCare.
A Empresa Sense disponibiliza os DTMs dos seus equipamentos da linha com os
protocolos HART.

Figura 70. PACTware.

Fonte: Elaborada pelo autor.

119
 PROTOCOLO UNIDADE IV
WIRELESS HART

CAPÍTULO 1
Introdução ao Wireless HART

Introdução
O HART com fio se tornou o padrão do setor para comunicações digitais com
instrumentos de campo. Com mais de 40 milhões de instrumentos instalados, o
HART manteve seu domínio diante da concorrência dos dois principais protocolos
de barramento de campo, Profibus e Foundation.

O HART é baseado em um relacionamento simples de resposta de comando entre

um mestre HART (comunicador ou sistema portátil) e o instrumento de campo.
A versão 5 do HART ficou disponível em 1990 e, desde então, houve apenas duas
atualizações para nos levar à versão atual que suporta conectividade sem fio.
Cada atualização do padrão HART adiciona novos recursos e nada é retirado. O
resultado é um padrão que é estável e compatível com versões anteriores.

A aplicação mais comum para o HART com fio é durante o comissionamento e

calibração do instrumento. No entanto, menos de 10% dos instrumentos HART
instalados possuem um link de comunicação direta com o sistema host. A adição
de conectividade sem fio de baixo custo fornece um caminho para os sistemas host
remotos lerem informações de processo e manutenção de instrumentos de campo
sejam eles velhos ou novos.

O WirelessHART faz parte da atualização recente do HART 7 e, como o nome

indica, adiciona capacidade sem fio. A Figura 71 mostra como o HART 7 evoluiu
desde a versão HART 5 inicial. Fica claro neste diagrama que o HART 7 é
construído a partir de HART 5 apenas adicionando novos recursos, sem tirar
nada. Os aspectos WirelessHART do HART 7 descrevem os comandos adicionais e
recursos para fornecer uma rede sem fio segura e robusta.
120
 PROTOCOLO WIRELESS HART │ UNIDADE IV

Figura 71. Evolução do HART.

Time/Condition
Reporting
PV Treading HART 7
Security
Mesh and Star
All PV with
Status
HART 6
Long Tags

Process Monitoring HART 5

Diagnostics
Configuration
Remote Access

4 a 20 mA Loop
Wireless

Fonte: Elaborado pelo autor.

Nos últimos anos, a tecnologia de redes sem fio sofreu grandes avanços
tecnológicos, o que hoje pode proporcionar: segurança, confiabilidade, estabilidade,
auto-organização (mesh), baixo consumo, sistemas de gerenciamento de potência e
baterias de longa duração.

Em termos de benefícios, podemos citar, entre outros:

» a redução de custos e simplificação das instalações;

» a redução de custos de manutenção, pela simplicidade das

instalações;

» monitoração em locais de difícil acesso ou expostos a situações de

riscos;

» escalabilidade;

» integridade física das instalações com uma menor probabilidade a

danos mecânicos e elétricos (rompimentos de cabos, curto circuitos no
barramento, ataque químico etc.).

Hoje, no mercado, vemos várias redes proprietárias e algumas padronizadas.

Existem muitos protocolos relacionados com as camadas superiores da

121
 UNIDADE IV │ PROTOCOLO WIRELESS HART

tecnologia, tais como ZigBee, WirelessHART, ISA SP100. Para as camadas

inferiores, existe o protocolo IEEE 802.15.4, que 4 define as características da
camada física e do controle de acesso ao meio para as LR-WPAN (Low-Rate
Wireless Personal Area Network).

A padronização para redes sem fio mostra que, ainda que existam diferenças, as
normas estão convergindo, como a principal dentre elas, a SP100 e WirelessHART,
da ISA e HART Foundation, que hoje vem sendo adotado como padrão para a
Foundation Fieldbus e Profibus.

A estrutura de uma rede WirelessHART está representada no diagrama da Figura

72, na qual a comunicação de uma rede WirelessHART é feita através de um
gateway. Consequentemente, o gateway precisa ter a funcionalidade de um
roteador de pacotes para um destino específico (instrumento da rede, aplicação
hospedeira ou gerenciador da rede). O gateway usa o padrão de comandos HART
para comunicar com os instrumentos na rede e aplicações hospedeiras.

Figura 72. Estrutura de uma rede WirelessHART.

Plant Automation
Application Host

Network
Gateway
Manager

D1 D..
D..
DN
D2
Wireless Hart
Devices

Fonte: SMAR <http://www.smar.com/images/index150_fig42.jpg>.

Portanto, basicamente uma rede WirelessHART possui três dispositivos principais:

» Instrumentos (Wireless Field devices), equipamentos de campo que

se comunicam bidireccionalmente.

» Porta de ligação (gateways) permitem a comunicação entre os

equipamentos de campo e as aplicações de controle.

122
 PROTOCOLO WIRELESS HART │ UNIDADE IV

» Gerente de rede (Network Manager), responsável pela configuração

da rede, gerenciamento da comunicação entre os dispositivos, rotas
de comunicação e monitoramento do estado da rede. O gerente
de rede também pode ser integrado em um gateway, aplicação no
host ou em um controlador de processo.

No que diz respeito à topologia, como ilustra figura 73, uma rede WirelessHART
pode ser do tipo:

» malha (mesh): é onde todos os nós são roteadores e, por isso, torna-se
uma rede muito confiável, com alta disponibilidade e redundância de
caminhos;

» estrela (star): é caracterizada por possuir apenas um roteador

conectado a vários instrumentos e é geralmente utilizada para
pequenas aplicações;

» estrela-malha (star-mesh): é uma combinação das topologias estrela

(star) e malha (mesh).

Figura 73. Topologias de rede WirelessHART.

Mesh Star Star Mesh

Nós roteadores
Nós terminais

Fonte: <https://www.automacaoindustrial.info/wp-content/uploads/2013/06/topologias-de-rede-WirelessHART.jpg>.

O WirelessHart é o primeiro padrão aberto de comunicação sem fio desenvolvido

especificamente para atender às necessidades da indústria de processo. Na medida
que aumenta a necessidade de medições adicionais do processo, os usuários buscam
um método simples, confiável, seguro e econômico para fornecer novos valores de
medição para controlar os sistemas sem a necessidade de passar mais fios. Com
melhorias no processo, expansões da planta, requisitos regulatórios e demandas de
níveis de segurança para medições adicionais, os usuários procuram a tecnologia
sem fio para essa solução.
123
 UNIDADE IV │ PROTOCOLO WIRELESS HART

Com aproximadamente 40 milhões de dispositivos HART instalados e em serviço

em todo o mundo segundo a fieldcommgroup, a tecnologia HART é o protocolo
de comunicação de campo mais amplamente utilizado para instrumentação
inteligente de processos. Com o recurso adicional de comunicação sem fio, o
legado de benefícios que essa poderosa tecnologia oferece continua a fornecer o
insight operacional que os usuários precisam para permanecer competitivos.

Coexistência

A coexistência é definida como a capacidade de um sistema executar uma

tarefa em um determinado ambiente compartilhado, onde outros sistemas têm
a capacidade de executar sua tarefa e podem ou não estar usando o mesmo
conjunto de regras. A coexistência bem-sucedida é medida pela confiabilidade de
cada rede para entregar suas mensagens ao destino desejado. Portanto, cada rede
deve ser capaz de atingir seu objetivo, sem prejudicar a capacidade de outra rede
de completar o seu.

Os problemas podem ocorrer quando dois ou mais pacotes de informações são

transmitidos ao mesmo tempo e frequência, para que “colidam” no mesmo espaço
físico. Se as redes não forem projetadas para minimizar ou evitar essas ocorrências,
resultarão em comunicações não confiáveis.

Existem várias técnicas que podem ser usadas para minimizar a interferência na
rede:

» Salto de Frequência – alterando a frequência do canal.

» Multiplexagem por divisão de tempo – variando o tempo das

comunicações.

» Modulação de potência – transmissão em baixa potência.

» Espalhamento espectral por sequência direta.

» Rede Mesh – suporta grande espaço físico com instrumentos de

baixa potência.

» Lista negra e avaliação de canais.

Na camada de enlace de dados da especificação WirelessHART, o reconhecimento

de pacotes com nova tentativa automática garante que os dados não sejam
perdidos se ocorrer interferência.
124
 PROTOCOLO WIRELESS HART │ UNIDADE IV

Salto de frequência

Conforme especificado em IEEE802.15.4, a banda de frequência ISM de 2,4

GHZ é dividida em 16 canais de frequência sem sobreposição. Os instrumentos
WirelessHART usam uma sequência de salto de canal pseudoaleatório para
reduzir a chance de interferência em outras redes, como IEEE802.11b/g (Wi-Fi),
que opera na mesma faixa de frequência ISM.

Existe um potencial de sobreposição entre os rádios IEEE802.11ge IEEE802.15.4.

Como os canais 802.11b/g são mais amplos, existem apenas 3 canais não
sobrepostos para redes Wi-Fi. Um determinado ponto de acesso Wi-Fi IEEE802.11
usará apenas 1 dos 3 canais não sobrepostos e transmitirá apenas periodicamente,
para que o canal não esteja em uso contínuo.

O salto pseudoaleatório de canal inerente aos instrumentos WirelessHART

garante que eles não consigam usar um canal usado por uma rede IEEE802.11b/g
por um longo período de tempo. Juntamente com as outras técnicas listadas
acima, a probabilidade de interferência é mínima de qualquer maneira.

Figura 74. Saltos de frequência.

Power

2 4 1 5 3

Frequency

Fonte: <https://hamradioschool.com/wp-content/uploads/2016/11/frequency-hopping.jpg>.

Para maiores informações sobre saltos de frequência, veja o artigo

“FHSS – Frequency Hopping Spread Spectrum”. Disponível em: <https://
www.youtube.com/watch?v=CkhA7s5GIGc>.

125
 UNIDADE IV │ PROTOCOLO WIRELESS HART

Multiplexagem por divisão do tempo

Uma rede WirelessHART utiliza a tecnologia TDMA (Time Division Multiple

Access) para garantir que apenas um instrumento esteja falando em um canal
a qualquer momento. Isso evita colisões de mensagens na rede WirelessHART.
Uma rede é fornecida com uma programação geral dividida em intervalos de
tempo de 10 ms. A qualquer momento, apenas um par de instrumentos está
se comunicando no mesmo canal de frequência, no entanto, é possível que
mais de um par de instrumentos possa se comunicar ao mesmo tempo usando
canais diferentes. Na maioria dos casos, apenas um par de instrumentos está
se comunicando em um determinado intervalo de tempo, para que a rede
WirelessHART não monopolize o espectro de frequências compartilhado com
outras redes sem fio.

Figura 75. TDMA.

Power

Fonte: <https://www.taitradioacademy.com/wp-content/uploads/2014/10/Image-25-800x450.png>.

Modulação de potência

Os rádios IEEE802.15.4 foram escolhidos por serem instrumentos de potência

relativamente baixa, adequados para aplicações de controle de processos sem
fio, além de estarem prontamente disponíveis a um custo razoável. Os rádios são
usados com amplificadores de 10dB para permitir a comunicação de até 200m
para o próximo instrumento, que por sua vez pode servir como roteador para
transmitir a mensagem.

Nos casos em que a distância total não é necessária, os instrumentos

WirelessHART podem transmitir com uma potência mais baixa para reduzir a
chance de interferir com outras redes na banda de frequência ISM. A menor

126
 PROTOCOLO WIRELESS HART │ UNIDADE IV

potência de transmissão dos instrumentos WirelessHART também significa que

qualquer chance de interferir com uma rede Wi-Fi IEEE802.11b/g é pequena.

Para maiores informações sobre ISM, veja o artigo “What are the ISM
Bands, and What Are They Used For?”, disponível em: <https://blog.
pasternack.com/uncategorized/what-are-the-ism-bands-and-what-are-
they-used-for/>.

Espalhamento espectral por sequência direta

A tecnologia DSSS (Direct Sequence Spread Spectrum) fornece cerca de 8dB

de ganho adicional utilizando algoritmos de codificação exclusivos. O sinal
de transmissão é espalhado por toda a banda de frequência do canal 802.15.4
selecionado. Dispositivos com as informações corretas de decodificação podem
receber os dados enquanto outros veem as transmissões como ruído branco e
as desconsideram. Isso permite que vários sinais de rádio sobrepostos sejam
recebidos e entendidos apenas por outros dispositivos de suas próprias redes.
Tal técnica é ilustrada na Figura 76.

Figura 76. Espalhamento espectral por sequência direta.

Signal strength

Spread
RFI signal

Frequency RFI

Data Data
Receiver
Carrier Filter
PN Sequence Spreading PN Sequence
Spreading
generator Signal generator
Signal
Signal
Signal

Transmiter Receiver

Fonte: <https://2.bp.blogspot.com/-riBorA8Vbs0/Ubc38MOhkyI/AAAAAAAAA_Y/z0tKo-HSV8U/s1600/Direct_Sequence_Spread_
Spectrum.jpg>.

127
 UNIDADE IV │ PROTOCOLO WIRELESS HART

Rede Mesh

O uso da tecnologia de rede mesh contempla o uso dos rádios IEEE802.15.4 de

baixa potência. Com a rede mesh, os instrumentos não precisam ter um caminho
de transmissão direto para o gateway da rede. É necessário apenas que qualquer
instrumento possa se comunicar com qualquer outro instrumento na rede mesh.
Cada instrumento de campo WirelessHART é capaz de rotear a mensagem de
outros instrumentos ao longo de uma rota que garantirá que a mensagem seja
recebida no seu destino final de gateway. As redes de malha também fornecem
redundância de caminho e, portanto, alcançam melhor confiabilidade do que
se cada instrumento tivesse que ter um caminho de linha de visão direta para o
gateway. A rede mesh pode se adaptar às mudanças de comunicação e outras
condições ambientais para encontrar um caminho de comunicação confiável
para o gateway.

Figura 77. Rede mesh WirelessHART.

WirelessHART Mesh Network

WirelessHART
Host Application Devices
(e.g. asset HART Device +
Management) WirelessHart adapter

Network Manager

Non-HART Device +
Access WirelessHART Adapter
Point
Connections
HART-IP
Modbus
Ethernet
more WirelessHART
Gateway
WirelessHART
Devices

Process Automation
Controller

Security Manager
WirelessHART
Adapter

Hart All-Digital Multidrop Mode

Fonte: <https://fieldcommgroup.org/sites/default/files/technologies/hart/meshnetwork.png>.

A separação física de 1 m entre os instrumentos WirelessHART e os pontos de

acesso Wi-Fi é tudo o que é necessário para uma coexistência pacífica entre os
dois tipos de redes sem fio.

128
 PROTOCOLO WIRELESS HART │ UNIDADE IV

Uma conexão direta ou ponto a ponto ao gateway também está disponível para
aplicativos que podem exigir velocidades de atualização mais rápidas.

Lista negra e avaliação do canal

Em conjunto com o salto de canal, a rede WirelessHART pode ser configurada para
evitar canais específicos que são altamente utilizados por outras redes e, portanto,
provavelmente causam interferência. No entanto, como a maioria das redes não é
carregada continuamente, isso raramente é necessário.

Para evitar ainda mais conflitos com outras redes vizinhas, um instrumento
WirelessHART ouve o canal de frequência antes de transmitir dados. Se outras
transmissões forem detectadas, o instrumento WirelessHART recuará e tentará a
comunicação em outro intervalo de tempo em uma frequência diferente.

WirelessHART e outras redes Wireless

Existem outros protocolos de rede sem fio que são semelhantes, mas não
idênticos, ao WirelessHART. Alguns são listados aqui em contraste para melhor
compreensão.

WirelessHART versus Bluetooth

O Bluetooth é um padrão popular de comunicação sem fio usado na computação

pessoal e em outros dispositivos eletrônicos pessoais, como fones de ouvido de
telefone celular.

Como o WirelessHART, o Bluetooth suporta salto de canal e usa arbitragem

TDMA. No entanto, o Bluetooth usa uma topologia em rede em estrela muito
mais simples: até sete dispositivos escravos Bluetooth podem se comunicar com
um dispositivo mestre Bluetooth. Por outro lado, o WirelessHART permite um
número maior de dispositivos de campo se comunicando com um dispositivo
Network Manager, e a topologia de rede é de malha, na qual qualquer dispositivo
pode transmitir dados para qualquer outro dispositivo na mesma rede e fazer
com que outro dispositivo “repita” os dados para o Network Manager.

WirelessHART versus ZigBee

O ZigBee é um padrão de comunicação sem fio de rede de malha que encontrou

aplicação em sistemas de automação predial. Aplica o padrão IEEE 802.15.4-2006

129
 UNIDADE IV │ PROTOCOLO WIRELESS HART

para as camadas Physical e Data Link, enquanto o WirelessHART emprega sua

própria camada exclusiva de Data Link, incluindo recursos como “lista negra” de
canais e sincronização de intervalo de tempo para evitar colisões.

Uma grande diferença entre o ZigBee e o WirelessHART são os métodos de

arbitragem de canais usados: o ZigBee usa CSMA/CA enquanto o WirelessHART
usa TDMA. A arbitragem por divisão de tempo tende a ser mais eficiente em
termos de tempo e certamente mais determinística, quando muitos dispositivos
estão dentro do alcance um do outro.

WirelessHART versus Wi-Fi

O Wi-Fi (IEEE 802.11) é um padrão de comunicação sem fio extremamente

popular para acesso à Internet em computadores pessoais. Ao contrário do
WirelessHART, o Wi-Fi não suporta salto de canal para redução de segurança
e interferência. O Wi-Fi, como o ZigBee, também usa a arbitragem de canal
CSMA/CA, enquanto o WirelessHART usa a arbitragem de canal TDMA para
obter determinismo.

130
CAPÍTULO 2
Codificação

Introdução
Opera na frequência de 2.4 GHz ISM usando o Time Division Multiple Access
(TDMA) para sincronizar a comunicação entre os vários equipamentos da rede.
Toda a comunicação é realizada dentro de um slot de tempo de 10ms. Um slot de
tempo formam um superframe.

Suporta chaveamento de canais (channel hopping) a fim de evitar interferências

e reduzir os efeitos de esvanecimento multipercurso (multi-path fadings). O
protocolo HART foi elaborado com base na camada 7 do protocolo OSI. Com a
introdução da tecnologia sem fio ao HART, tem-se duas novas camadas de Data
Link: token-passing e TDMA. Ambas suportam a camada de aplicação HART
conforme ilustra a Figura 78.

Figura 78. Model OSI WirelessHART.

Command oriented, predefined data types

Application and application procedures

Presentatio
n

Session

Auto-segmented transfer of large data set, reliable

Transport
Stream transport, negotiated segment sizes

Power-optimized,
Network redundant
Path mesh network

Token passing Time-synchronized,

Data link maste/slave frequency
protocol Hopping protocol

Simultaneous analog & IEEE 802.15.4-2006,

Physical digital 2.4GHz
Signaling (4-20mA wire)

HART Wireless HART

Fonte: SMAR <http://www.smar.com/images/index109_fig05.jpg>.

131
 UNIDADE IV │ PROTOCOLO WIRELESS HART

Data link layer

A arbitragem de barramento TDMA significa que o Network Manager planeja

e agenda os tempos de transmissão de todos os dispositivos de campo, dando a
cada um o seu tempo dedicado para “falar”. Com esses intervalos de tempo não
sobrepostos agendados e transmitidos a todos os dispositivos de campo, as colisões
são evitadas, ao mesmo tempo assegurando o determinismo (a garantia de que
os pacotes de dados atingirão seu destino dentro de um determinado tempo
especificado), impedindo qualquer interrupção física do padrão de dados.

» Arbitragem de barramento TDMA (Acesso Múltiplo por Divisão de

Tempo), com intervalos de tempo de 10 milissegundos alocados para
transmissão do dispositivo.

» O número de identificação de rede identifica exclusivamente cada

rede WirelessHART, permitindo que várias redes se sobreponham à
mesma área física.

» Canal de lista negra evita automaticamente saltar para canais

ruidosos.

Figura 79. Arquitetura data link WirelessHart.

Network Manager

Interface to Network Layer

Queue
Timer Link Link Superframe
Scheduleru Message
Table Table
Handling
Neighbor Graph Module
Table Table

State Machine
Message
PIB
Handling
Module
WirelessHart Queue
MAC

Interface to Physical Layer

Physical Layer

Fonte: SMAR <http://www.smar.com/images/index109_fig07.jpg>.

Network layer

O Network Manager em uma rede WirelessHART desempenha uma função

semelhante ao Link Active Scheduler (LAS) em um segmento de rede do

132
 PROTOCOLO WIRELESS HART │ UNIDADE IV

FOUNDATION Fieldbus. O Network Manager atribui intervalos de tempo para

dispositivos individuais se comunicarem; determina rotas de comunicação
alternativas, ou seja, projeta e atualiza continuamente a malha e ajusta a energia
de transmissão do dispositivo para garantir a operação ideal. Esse gerenciamento
dinâmico da rede sem fio é extremamente importante para manter tempos de
latência de dados baixos e alta confiabilidade diante das variáveis do ambiente,
como objetos que entram e saem das vias de rádio por exemplo, guindastes,
caminhões, empilhadeiras, elevadores manuais, andaimes e quaisquer outras
estruturas metálicas grandes que possam alterar temporariamente o ambiente
de RF em um ambiente industrial. Como os dispositivos FOUNDATION Fieldbus
LAS, vários gerenciadores de rede redundantes são possíveis dentro de uma rede
WirelessHART, com apenas um ativo a qualquer momento.

» Rede “Mesh” – os dispositivos estabelecem automaticamente links

com outros dispositivos WirelessHART próximos.

» Repetição de sinal – os dispositivos podem atuar como “repetidores”

para outros dispositivos muito distantes da unidade principal.

» Um dispositivo do Network Manager determina rotas de comunicação

entre dispositivos de campo, bem como cronogramas de temporização.

» Quatro níveis de prioridade da mensagem de dados, listados da

maior para a menor as prioridades são: comando – mensagens de
gerenciamento de rede; dados do processo – valores de PV; normal
– todas as mensagens que não sejam comando, processo ou alarme;
alarme – mensagens relatando alarmes e eventos do dispositivo.

Figura 80. Arquitetura Network WirelessHART.

Application Layer

Queue
Transport Session Route Constants
Management Table Table and
Security Transport
Source Attributes
Module Route Service
Table Table Table
Security
Module Transport
Management

Queue State Machine Security

Module
Security
Module
Network Transport Layer

WirelessHART MAC Layer

Fonte: SMAR <http://www.smar.com/images/index109_fig09.jpg>.

133
 UNIDADE IV │ PROTOCOLO WIRELESS HART

Transport Layer

Para suportar a tecnologia de rede mesh, cada equipamento WirelessHARTTM

deve ser capaz de transmitir pacotes “em nome” de outros dispositivos. Há três
modelos de roteamentos definidos:

» Graph Routing: um grafo é uma coleção de caminhos que permitem

a conexão dos nós da rede. Os caminhos de cada grafo são criados
pelo gerente de rede e enviado para cada dispositivo da rede.
Assim, para enviar um pacote de dados, o dispositivo de origem
escreve um ID de um grafo específico (determinado pelo destino)
no cabeçalho da rede. Todos os dispositivos de rede no caminho
para o destino devem ser pré-configurados com informações do
grafo que especifica os vizinhos para que o pacote de dados possa
ser enviado.

» Sourcing Routing: este tipo de roteamento é um complemento do

Graph Routing, visando a diagnósticos de rede. Para enviar um
pacote de dados ao seu destino, o dispositivo inclui no cabeçalho
uma lista ordenada de dispositivos através de qual o pacote deve
percorrer. Como o pacote é roteado, cada dispositivo do roteamento
utilizará o endereço do próximo dispositivo de rede para determinar
o próximo salto até que o dispositivo de destino seja alcançado.

» Superframe Routing: é um tipo especial de Graph Routing, no qual os

pacotes são atribuídos a um superframe.

Figura 81. Transport PDU WirelessHART.

TRANSPORT LAYER Aggregated commands

Device/
Transport CMD#1 CMD#2 ... CMD#n
Extended
byte
Status

Enciphered Payload

Fonte: SMAR <http://www.smar.com/images/index109_fig11.jpg>.

134
 PROTOCOLO WIRELESS HART │ UNIDADE IV

Application layer

A compatibilidade com versões anteriores do WirelessHART com instrumentos

de campo com fio HART é um recurso incrivelmente valioso desse padrão, pois
abre as portas para a integração sem fio de instrumentos HART herdados. Tudo
o que é necessário para tornar um instrumento HART com fio parte de uma rede
WirelessHART em funcionamento é conectar o adaptador apropriado, como ilustra
a Figura 82. Essencialmente, essa etapa adiciona uma antena e os componentes
eletrônicos da interface de rede associados a qualquer instrumento HART
herdado, permitindo que ele se comunique com os instrumentos WirelessHART
nativos e com o gateway sem fio. Essa compatibilidade com versões anteriores
também melhora a integração dos instrumentos WirelessHART, pois eles podem
se comunicar com o aplicativo de software HART herdado tão facilmente quanto
os dispositivos HART com fio. Isso significa que programas são capazes de
interrogar instrumentos HART sem fio com a mesma facilidade que podem com
instrumentos HART com fio, sem alterações no código do programa.

Figura 82. Adaptador WirelessHART.

HOST
4… 20mA + HART AMS
DCS
PLC

HART device

Fonte: <https://www.pepperl-fuchs.com/global/campaigns/cumulus_img/EC_NP_20160309_01_WirelessHART_BULLET_StepVolt_
rdax_75.jpg>.

135
 CAPÍTULO 3
Limitações e segurança

Benefícios de segurança no WirelessHART

Por padrão, todos os dispositivos WirelessHART exigem uma senha conhecida como
chave de associação para poder se conectar à rede. A senha deve ser configurada
no dispositivo antes de ingressar na rede, pois é necessária a troca de pacotes de
controle com o gateway da rede.

Mas o uso da senha exclusiva não é recomendado, pois ela é usada em todas as
comunicações de transmissão, o que significa que é muito usada na rede. Como
alternativa, a lista de controle de acesso (ACL) pode ser usada. Essas ACLs usadas
para controlar o acesso à função de rede usando a verificação pelo gateway da
origem do pacote (através do MAC ou do número de série do transmissor). Se
o elemento for permitido, o pacote será descriptografado para seu tratamento
usando a chave de junção. Depois que o dispositivo for aceito na rede, o restante
dos dispositivos receberá a nova mensagem de membro.

Há outra opção para dar mais segurança à rede, que consiste em misturar a opção
de chave compartilhada e, uma vez que o dispositivo é associado à rede, uma lista
de controle de acesso é criada e os dispositivos recebem uma nova chave. Isso é
feito pelo gateway e pelo gerenciador de segurança.

Uma vez que os dispositivos estão conectados à rede, eles podem se comunicar
entre si e com o gateway. As comunicações entre dois dispositivos também são
permitidas, usando uma chave específica. A negociação dessa chave é realizada
pelo gateway, que a distribui aos dois dispositivos, para que eles possam usá-la
para se comunicar entre si, para que não mais dependa do gateway.

Arquitetura segura

A rede WirelessHART é um sistema de rede segura. Tanto a camada MAC

quanto a camada de rede (network layer) fornecem serviços de segurança.

A camada MAC fornece integridade de dados hop-to-hop – mecanismo usado

para controlar o fluxo de dados em uma rede, que envolve não somente os nós
de origem e de destino, mas alguns ou todos os nós intermédios, permitindo que

136
 PROTOCOLO WIRELESS HART │ UNIDADE IV

dados sejam transmitidos, mesmo que o caminho entre origem e destino não esteja
permanentemente ligado durante a comunicação – usando a combinação de CRC
(Cyclic Redundancy Check) e MIC (Message Integrity Code).

O emissor e o receptor utilizam a modalidade CCM. É um algoritmo de criptografia

autenticada projetado para fornecer autenticação e confidencialidade. É
definido somente para cifras de blocos com um comprimento de bloco de 128
bits, AES-128 juntamente com a AES-128 (Advanced Encryption Standard)
para gerar e comparar o MIC.

A camada de rede emprega várias chaves para garantir a confidencialidade e

integridade dos dados de conexões (end-to-end connections). Quatro tipos de
chaves são definidos na arquitetura de segurança:

» Public keys: as chaves públicas, que são usados para gerar o MICs
na Camada MAC dos dispositivos de união.

» Network keys: chaves de rede, que são compartilhados por todos os

dispositivos de rede e usadas por dispositivos existentes na rede para
gerar o MIC na camada MAC.

» Join keys, que são únicas para cada dispositivo de rede e são usadas
durante o processo de adesão para autenticar o dispositivo que está
entrando na rede com o administrador.

» Session keys, gerada pelo gestor da rede e é única para cada

conexão end-to-end entre dois dispositivos de rede. Ela fornece a
confidencialidade e integridade dos dados.

Figura 83. PDU HART e WirelessHART.

WirelessHART

Physical DataLink Transport Command

PDU PDU Byte Count Data

HART Transport/Application Layer

Data Link Network Transport Command Byte Count Data

PDU PDU PDU

Fonte: SMAR <http://www.smar.com/uploads/images/wirelesshart_figura25.png>.

O gerenciador de segurança no gateway WirelessHART administra três

parâmetros. Os parâmetros incluem:

» ID de rede.

137
 UNIDADE IV │ PROTOCOLO WIRELESS HART

» Tecla de junção.

» Chave de sessão.

A integração de um transmissor WirelessHART em uma rede requer uma

identificação de rede e uma chave de junção. Depois de inseridas, o transmissor
primeiro procura a rede com o ID correto. Se encontrar essa rede, envia uma
mensagem “Solicitação de associação” com a chave configurada. O gateway
WirelessHART verifica a chave de junção do transmissor. Se correta, a rede aceita
o transmissor. Uma chave de sessão criptografa a comunicação. Cada assinante da
rede recebe uma chave de sessão separada. Portanto, é possível apenas ser aceito
em uma rede com a chave de junção, mas isso não descriptografa a comunicação
criptografada dos outros assinantes.

Lista de acesso – Após concluir o comissionamento, a aceitação de novos

assinantes da rede pode ser desativada. Dessa forma, nenhum novo assinante de
rede pode ser integrado a ela, mesmo que o ID da rede e a chave de junção estejam
corretos. Para integrar um novo assinante, esta função pode ser desativada
ou o UID (Identificador Único = número de série do dispositivo exclusivo) do
assinante da rede pode ser inserido manualmente no gateway. Um assinante
de rede que não aparece na lista de assinantes do gateway também é ignorado
pelos outros assinantes da rede quando as mensagens são encaminhadas.

Contador de junção – Se um transmissor WirelessHART estiver integrado a

uma rede, ele registra essas informações no chamado contador de junção. Se o
dispositivo for reiniciado e se conectar à mesma rede, seu contador de junção
aumentará. O assinante da rede e o gateway têm um contador de associação.
Eles não podem ser lidos. Se um dispositivo agora tentar integrar-se a uma rede
com um contador de associação que não corresponde ao gateway, ele o recusará.
Como resultado, não é possível substituir um dispositivo por outro sem que isso
seja notado, mesmo que ambos tenham o mesmo UID.

Contador de nonce – Cada mensagem transmitida possui um contador de

nonce. Este é composto, entre outros, pelo UID e pelo número de mensagens
enviadas pelo transmissor até o momento. Cada mensagem é marcada
exclusivamente com esse mecanismo. Se uma mensagem for interceptada
para reenviá-la mais tarde, será identificada como desatualizada e, portanto,
rejeitada. Esta técnica impede qualquer manipulação na comunicação.

138
 PROTOCOLO WIRELESS HART │ UNIDADE IV

Limitações tecnológicas

Apesar dos esforços da especificação WirelessHART para criar um protocolo

seguro e confiável, ele apresenta alguns pontos fracos que devem ser levados em
consideração ao selecioná-lo e implementá-lo. Entre eles, destacamos o seguinte:

O uso de certificados (criptografia de chave pública) não é suportado, o

que significa que o repúdio não pode ser garantido. Outras medidas, como
autenticação forte, também não são possíveis, pois a senha deve ser enviada
pela rede.

Não há mecanismos especializados para fornecer serviços de autenticação

e registro. O sistema completo de gerenciamento de chaves (gerar, renovar,
revogar, armazenar e negar) não está especificado, enquanto os comandos de
distribuição de chaves foram especificados.

A segurança na parte com fio da rede, por exemplo, dispositivos como o

gerenciador de rede e segurança, não é especificada, nem é aplicada, como
é o caso da integração entre o WirelessHART e os dispositivos HART antigos
especificação HART 6 ou especificações anteriores. No entanto, fornece maneiras
de adicionar dispositivos HART à rede WirelessHART usando adaptadores.

Não há redundância de rota na parte com fio da rede. A comunicação multicast

segura entre dispositivos de campo não é compatível. A arquitetura do gerenciador
de segurança e a arquitetura da interface entre o gerenciador de segurança e o
gateway não estão especificadas nos regulamentos.

Os mecanismos de segurança para proteger a rede WirelessHART não estão

especificados em um documento concreto, mas estão espalhados entre diferentes
documentos que compõem a especificação WirelessHART. Isso dificulta que
designers e desenvolvedores implementem serviços de segurança, pois precisam
explorar toda a especificação WirelessHART.

Também não há mecanismos de segurança para proteger as comunicações entre

o gateway e os possíveis aplicativos (também chamados de aplicativos host) que
usam a tecnologia WirelessHART.

139
 CAPÍTULO 4
Equipamentos industriais HART

Smart Wireless Gateway Emerson1420

O gateway de rede é um componente extremamente importante em um sistema
WirelessHART. É o único canal através do qual todos os dados do dispositivo
de campo são direcionados para o sistema de controle do host. Fisicamente, um
gateway de rede nada mais é do que uma caixa com uma antena e conexões internas
para energia elétrica e redes com fio (por exemplo, Ethernet, EIA/TIA-485).
Aqui é mostrado um Emerson modelo 1420 “Smart Wireless Gateway”:

Figura 84. Smart Wireless Gateway Rosemount 1420.

Fonte: <https://pondtechnical.com/wp-content/themes/pondTechSales/content/images/Wireless/Wireless%20Gateway.jpg>.

Eletricamente, esses dispositivos são bastante complexos. Eles são controlados

por microprocessador e geralmente servem como host físico para o algoritmo do
gerente de rede: orquestrando e ajustando as comunicações de rede sem fio.

Como o WirelessHART é um padrão de comunicação puramente digital, todos

os pontos de dados dos dispositivos de campo são armazenados no gateway em
formato digital e devem ser acessados digitalmente. No caso do Smart Wireless
Gateway da Emerson, os dados podem ser acessados por qualquer sistema host
por meio de comandos de consulta Modbus, comunicados em Serial EIATIA-485,
formato Modbus RTU ou encapsulados em pacotes Ethernet (Modbus TCP).
Existem conexões de terminal de parafuso no gateway Emerson para conectar
um cabo EIA/TIA-485 (RS-485), bem como várias portas Ethernet RJ-45 para
conexão a um hub ou computador, em que outros computadores e sistemas
baseados em Ethernet podem se conectar também.

140
 PROTOCOLO WIRELESS HART │ UNIDADE IV

Figura 85. Conexões Smart Gateway.

Fonte: <https://control.com/uploads/textbooks/wirelesshart_06.jpg>.

O Smart Wireless Gateway possui um servidor da web interno, permitindo acesso

protegido por senha às páginas de configuração usando nada mais do que um
computador pessoal com conectividade Ethernet e um programa de navegador
da Internet. Basta digitar o endereço IP da porta do gateway no campo URL do
navegador e o computador pessoal se conectará ao gateway.

Os pontos de dados do dispositivo individual são mapeados de forma

personalizada pelo usuário para registros Modbus específicos na memória do
gateway, conforme mostrado na página de configuração abaixo.

Figura 86. Página de configuração.

Fonte: <https://control.com/uploads/textbooks/wirelesshart_07.jpg>.

Na Figura 86, vemos as variáveis primárias (PV) de dois transmissores de

temperatura WirelessHART modelo 648 da Rosemount mapeados para os
registradores Modbus 30001 e 30002. Deve-se notar que todos os instrumentos

141
 UNIDADE IV │ PROTOCOLO WIRELESS HART

de campo WirelessHART são dispositivos multivariáveis e, como tal, são capazes

de relatar mais do que uma variável para o gateway. Nesse exemplo, seria possível
atribuir a tensão da bateria como uma variável secundária (SV), variável terciária
(TV) ou variável quaternária (QV) dentro de um ou ambos os transmissores
de temperatura e, em seguida, mapear esses pontos de dados para seu próprio
registrador Modbus no gateway para que um sistema host possa acessar e
monitorar a tensão da bateria para os instrumentos de campo.

Assim como na comunicação com fio HART, é possível a comunicação de dados

multivariáveis de cada transmissor. Isso geralmente não é feito como um recurso
de ação regular com instrumentos HART com fio, devido à taxa de dados muito
lenta do HART com fio, 1200 bps. No entanto, com a taxa de dados muito mais
rápida do WirelessHART 250 kbps, o tempo extra necessário para um instrumento
de campo transmitir três ou quatro variáveis em vez de apenas uma variável é
insignificante em relação às necessidades de medição e controle do processo.

A figura 87 mostra uma parte de um programa PLC simples escrito para consultar
esses dois registradores Modbus dentro do gateway.

Figura 87. Trecho de programação PLC.

Fonte: <https://control.com/uploads/textbooks/wirelesshart_08.jpg>.

A instrução “Receive” no CLP envia um código de função Modbus 04 para ler dois
registros de entrada analógica dentro do dispositivo escravo, sendo ele o Smart
Wireless Gateway endereço Modbus 10 nesta rede EIA/TIA-485.

O resultado dessa consulta Modbus é mostrado na próxima captura de tela, em

que a janela “Data View” do PLC está configurada para exibir os dois valores
inteiros obtidos no comando Modbus 04. Esses valores inteiros armazenados
nos registros DS1 e DS2 na memória do PLC são 60 e 61 representam 60 graus
Fahrenheit e 61 graus Fahrenheit, respectivamente. Os dois transmissores de
temperatura estavam medindo a temperatura ambiente externa no momento em
que esta captura de tela foi feita:
142
 PROTOCOLO WIRELESS HART │ UNIDADE IV

Figura 88. View PLC.

Fonte: <https://control.com/uploads/textbooks/wirelesshart_09.jpg>.

Agora que os dados de temperatura residem nos registros do PLC, o PLC pode ser
programado para executar uma ação nesses dados. Por exemplo, o PLC pode ser
programado para ligar ventiladores quando as temperaturas excederem os limites
predefinidos.

Muitos painéis modernos de HMI (Interface Homem-Máquina) também são capazes

de servir como dispositivos mestre Modbus e podem ler e gravar diretamente no
gateway da rede sem a necessidade de um PLC. Para sistemas WirelessHART que
não exigem controle automático, ou seja, apenas funções de monitoramento e ou
controle manual, a interface de um painel IHM ao gateway é uma solução simples
e prática.

Os gateways de rede fornecem algumas informações estatísticas básicas sobre

dispositivos conectados, que podem ser úteis para diagnosticar problemas. Algumas
dessas estatísticas podem ser vistas na captura de tela do computador a seguir, obtida
de um gateway Emerson modelo 1420:

Figura 89. Status do dispositivo de rede.

Fonte: <https://control.com/uploads/textbooks/wirelesshart_10.jpg>.

143
 UNIDADE IV │ PROTOCOLO WIRELESS HART

“RSSI” refere-se à indicação de intensidade do sinal recebido e é uma medida

da intensidade do sinal de RF recebido de cada dispositivo, em unidades de
dBm. Problemas relacionados a antenas, perda no caminho e interferência
resultarão na diminuição do RSSI para esse dispositivo. Essa mesma página
mostra a voltagem da bateria para cada dispositivo de campo. O parâmetro
“neighbours” nos diz quantos dispositivos WirelessHART estão ao alcance de
cada dispositivo de campo, o gateway de rede é contado entre eles. Assim,
nessa rede WirelessHART simples, composta por dois dispositivos de campo e
um gateway, todos dentro do alcance um do outro, cada dispositivo de campo
relata ter dois vizinhos.

144
Referências

AUTOMATION FORUM. Conceito Fieldbus. Disponível em: <https://

automationforum.co/wp-content/uploads/2018/03/ff4-434x385.jpg>. Acesso em: 20
nov. 2019.

AUTOMAÇÃO INDUSTRIAL. Topologia de rede WirelessHart. Disponível

em: <https://www.automacaoindustrial.info/wp-content/uploads/2013/06/
topologias-de-rede-WirelessHART.jpg>. Acesso em: 20 nov. 2019.

BR-AUTOMATION. DeviceNet. Disponível em: https://www.br-automation.com/

fileadmin/1288381739663-en-html-1.0.jpg. Acesso em: 20 de Novembro de 2019.

CERTI. Aplicação do SCADA. Disponível em: <https://sites.google.com/a/certi.

org.br/certi_scadabr/_/rsrc/1468847541134/home/minicursos/iniciando-scadabr/
scada-intro.png>. Acesso em: 20 nov. 2019.

CITI SYSTEMS. Desvendando a Comunicação RS232. Disponível em: <https://

www.citisystems.com.br/rs232/>. Acesso em: 20 nov. 2019.

CNBLOGS. Televideo 925. Disponível em: <https://images0.cnblogs.com/blog/56449

0/201501/151523326048605.jpg>. Acesso em: 20 nov. 2019.

CONTROL AUTOMATION. Conexões Smart Gateway. Disponível em: <https://

control.com/uploads/textbooks/wirelesshart_06.jpg>. Acesso em: 20 nov. 2019.

CONTROL AUTOMATION. Página de configuração. Disponível em: https://

control.com/uploads/textbooks/wirelesshart_07.jpg. Acesso em: 20 de Novembro de
2019.

CONTROL AUTOMATION. Status do dispositivo de rede. Disponível em:

<https://control.com/uploads/textbooks/wirelesshart_10.jpg>. Acesso em: 20 nov.
2019.

CONTROL AUTOMATION. Trecho de programação PLC. Disponível em:

<https://control.com/uploads/textbooks/wirelesshart_08.jpg>. Acesso em: 20
nov. 2019.

CONTROL AUTOMATION. View PLC. Disponível em: <https://control.com/

uploads/textbooks/wirelesshart_09.jpg>. Acesso em: 20 nov. 2019.

145
 REFERÊNCIAS

DEMIR, B.; TUMAY, A.; OZBEK, M. E.; CAVUS, E. Consulta e resposta Modbus.
Disponível em: https://www.researchgate.net/publication/325856572/figure/fig3/AS
:639289427759105@1529429885425/Modbus-RTU-request-and-response-packages.
png. Acesso em: 20 de Novembro de 2019.

ELTIMA. Modbus. Disponível em: <https://www.eltima.com/images/upload/

products/spm/articles/modbus/modbus.png>. Acesso em: 20 nov. 2019.

ELTIMA. Software Virtual Serial Port Driver. Disponível em: <https://www.

eltima.com/products/vspdxp/>. Acesso em: 20 nov. 2019.

EMMBARCADOS. Profibus. Disponível em: <https://www.embarcados.com.br/wp-

content/uploads/2016/07/Protocolo-Profibus-destaque-696x418.jpg>. Acesso em: 20
nov. 2019.

FELSER MAX. The Fieldbus Standards: History and Structures. Disponível em: <felser.
ch/papers/FE-TR-0205.pdf> . Acesso em: 20 nov. 2019.

FIELDCOMMGROUP. Hart. Disponível em: <https://fieldcommgroup.org/sites/

default/files/fcg_logos/hart_protocol_logo_color_300dpi.png>. Acesso em: 20 nov.
2019.

FIELDCOMMGROUP. Rede mesh WirelessHART. Disponível em: <https://

fieldcommgroup.org/sites/default/files/technologies/hart/meshnetwork.png>.
Acesso em: 20 nov. 2019.

FREITAS, Carlos. Redes de comunicação em RS-485. 2017. Disponível em:

<https://www.embarcados.com.br/redes-de-comunicacao-em-rs-485/>. Acesso em:
20 nov. 2019.

GEEKSFORGEEKS. Layers of OSI Model. Disponível em: <https://www.

geeksforgeeks.org/layers-of-osi-model/>. Acesso em: 20 nov. 2019.

GEEKS FOR GEEKS. Representação little e big endian. Disponível em: <https://
www.geeksforgeeks.org/little-and-big-endian-mystery/>. Acesso em: 20 nov. 2019.

HAMRADIOSCHOOL. Saltos de frequência. Disponível em: <https://

hamradioschool.com/wp-content/uploads/2016/11/frequency-hopping.jpg>. Acesso
em: 20 nov. 2019.

IGSAUTOMAÇÃO. CLP atual. Disponível em: <https://www.lgsautomacao.com.br/

wp-content/uploads/2016/11/CLP-Ge-Fanuc-01-1.png>. Acesso em: 20 nov. 2019.

146
 REFERÊNCIAS

INSTRUMENTATION TOOLBOX. Modulação sinal HART. Disponível em:

https://4.bp.blogspot.com/-Ti0TlMLgZuI/U44A8S7l9BI/AAAAAAAABIA/
fvocvKtuNR8/s1600/HART+Signal.jpg. Acesso em: 20 de Novembro de 2019.

INSTRUMENTATIONTOOLS. Band de frequência do sinal HART. Disponível

em: <https://instrumentationtools.com/wp-content/uploads/2016/08/
instrumentationtools.com_frequency-bands-for-4-20ma-and-hart-signals.png>.
Acesso em: 20 nov. 2019.

JOHNSON, Glenn. Pilha Modbus. Disponível em: <http://production-oms.

s3.amazonaws.com/static/Image/QPF2S1-1-09.jpg>. Acesso em: 20 nov. 2019.

MCKAUTOMAÇÃO. Protocolos de Redes Industriais. Disponível em: <http://

www.mckautomacao.com.br/images/redesindustriais/img1.png>. Acesso em: 20 nov.
2019.

MCNEIL, Peter. What are the ISM Bands, and What Are They Used For?
Pasternack, 2018. Disponível em: <https://blog.pasternack.com/uncategorized/what-
are-the-ism-bands-and-what-are-they-used-for/>. Acesso em: 20 nov. 2019.

MEDIUM. ScadaBR. Disponível em: <https://miro.medium.com/max/5000/1*InQi

Tp4ru0cECUX4TcGIqw.png>. Acesso em: 20 nov. 2019.

Microcontrollertips. Primeiro CLP. Disponível em: https://rh6stzxdcl1wf9gj1fkj14uc-

wpengine.netdna-ssl.com/wp-content/uploads/2019/01/WHTH_FAQ_PLCs_Pt2_
Fig3-1.png . Acesso em: 20 de Novembro de 2019.

MODBUS. Software Modbus Pull. Disponível em: <https://www.modbustools.

com/download.html>. Acesso em: 20 nov. 2019.

MODBUS. Software Modbus Slave. Disponível em: <https://www.modbustools.

com/download.html>. Acesso em: 20 nov. 2019.

MODBUS. Transação Modbus com erros. Disponível em: http://www.modbus.org/

docs/Modbus_Application_Protocol_V1_1b.pdf . Acesso em: 20 de Novembro de 2019.

MODBUS. Transação Modbus sem erros. Disponível em: < http://www.modbus.org/

docs/Modbus_Application_Protocol_V1_1b.pdf >. Acesso em: 20 nov. 2019.

MURRELEKTRONIK. IO-Link. Disponível em: <http://blog.murrelektronik.com.br/

wp-content/uploads/2016/06/Link-840x420.png>. Acesso em: 20 nov. 2019.
147
 REFERÊNCIAS

OLIVEIRA, Carla. O que é o terminal? (ou, venha conhecer a tela preta!).

2016. Disponível em: <https://www.programaria.org/o-que-e-o-terminal-ou-venha-
conhecer-tela-preta/>. Acesso em: 20 nov. 2019.

PEPPERL-FUCHS. Adaptador WirelessHart. Disponível em: <https://www.

pepperl-fuchs.com/global/campaigns/cumulus_img/EC_NP_20160309_01_
WirelessHART_BULLET_StepVolt_rdax_75.jpg>. Acesso em: 20 nov. 2019.

PEPPERL-FUCHS. As-Interface. Disponível em: <https://www.pepperl-fuchs.

com/usa/campaigns/cumulus_img/EC_JB_20181126_03_ASi-Logo_neu_
rdax_614x402_75.jpg>. Acesso em: 20 nov. 2019.

PINIMG. Camadas de rede. Disponível em: <https://i.pinimg.com/originals/7f/97/

b9/7f97b946cc5c4203a50e38ff0952e126.jpg>. Acesso em: 20 nov. 2019.

PONDTECHNICAL. Smart Wireless Gateway Rosemount 1420. Disponível em:

<https://pondtechnical.com/wp-content/themes/pondTechSales/content/images/
Wireless/Wireless%20Gateway.jpg>. Acesso em: 3 fev. 2020.

PROEMINENTE. Topologias de rede. Disponível em: <https://www.proeminente.

com.br/thumb.php?w=750&h=370&src=midia/news/21cbad836799937a7456d3c7a8
842b1c.png>. Acesso em: 20 nov. 2019.

PROFELECTRO. Tabela de Termopar. Disponível em: as <https://www.

profelectro.info/aquisicao-e-tratamento-de-dados-%E2%80%93-teoria-8-
termopares-sensores-de-temperatura/>. Acesso em: 20 nov. 2019.

PROSOFT TECHNOLOGY. Understanding Modbus Serial and TCP/IP.

Disponível em: <https://www.youtube.com/watch?v=k993tAFRLSE&list=PLkxqHEy
jiG_lmM6yX8tht-Gbw773P8VbJ>. Acesso em: 20 nov. 2019.

RC DICTIONARY. Espalhamento espectral por sequência direta. 2013. Disponível

em: https://2.bp.blogspot.com/-riBorA8Vbs0/Ubc38MOhkyI/AAAAAAAAA_Y/
z0tKo-HSV8U/s1600/Direct_Sequence_Spread_Spectrum.jpg. Acesso em: 20 de
Novembro de 2019.

REALPARS. What is HART Protocol?. 2018. Disponível em: <https://www.

youtube.com/watch?v=pXkun-PEiY0>. Acesso em: 20 nov. 2019.

REALPARS. What is OSI Model?. 2019. Disponível em: <https://www.youtube.

com/watch?v=Ilk7UXzV_Qc>. Acesso em: 20 nov. 2019.

148
 REFERÊNCIAS

ROMILLY. Sinal HART. Disponível em: <http://www.romilly.co.uk/hartwave.gif>.

Acesso em: 20 nov. 2019.

zl em: <http://www.smar.com/uploads/images/36.JPG>. Acesso em: 20 nov. 2019.

SMAR. Estrutura de uma rede WirelessHart. Disponível em: <http://www.smar.

com/images/index150_fig42.jpg>. Acesso em: 20 nov. 2019.

SMAR. Exemplo Rede Hart. Disponível em: <http://www.smar.com/images/

index150_fig35.jpg>. Acesso em: 20 nov. 2019.

SMAR. Loop de Corrente. Disponível em: <http://www.smar.com/images/index150_

fig32.jpg>. Acesso em: 20 nov. 2019.

SMAR. Loop de Corrente acrescido o Hart. Disponível em: <http://www.smar.com/

images/index150_fig33.jpg>. Acesso em: 20 nov. 2019.

SMAR. Model OSI WirelessHART. Disponível em: <http://www.smar.com/images/

index109_fig05.jpg>. Acesso em: 20 nov. 2019.

SMAR. O que é PROFIBUS?. Disponível em: <https://www.smar.com/brasil/

profibus>. Acesso em: 20 nov. 2019.SMAR. PDU HART e Wireless HART.
Disponível em: <http://www.smar.com/uploads/images/wirelesshart_figura25.
png>. Acesso em: 20 nov. 2019.

SMAR. Transport PDU WirelessHart. Disponível em: <http://www.smar.com/

images/index109_fig11.jpg>. Acesso em: 20 nov. 2019.

SUNNY CLASSROOM. FHSS – Frequency Hopping Spread Spectrum. 2018.

Disponível em: <https://www.youtube.com/watch?v=CkhA7s5GIGc>. Acesso em: 20
nov. 2019.

TAITRADIOACADEMY. TDMA. Disponível em: <https://www.taitradioacademy.

com/wp-content/uploads/2014/10/Image-25-800x450.png>. Acesso em: 20 nov.
2019.

TECMUNDO. A história do ENIAC. Disponível em: <https://www.youtube.com/

watch?v=dy0wpDfnpzo>. Acesso em: 20 nov. 2019.

UNICAMANIA. Computador ENIAC. Disponível em: <https://unicamania.com.br/

images/canais/primeira-vez/2107/mai/05/eniac-principal.jpg> . Acesso em: 20 nov.
2019.

149
 REFERÊNCIAS

Z80. Microprocessador Z80. Disponível em: <http://www.z80.info/gfx/z0840004.

jpg> . Acesso em: 20 nov. 2019.

Sites
<http://modbus.org/>.

<http://www.smar.com/brasil/index>.

<https://ab.rockwellautomation.com/allenbradley/index.page?>.

<https://control.com/>.

<https://fieldcommgroup.org/>.

<https://www.ascii-code.com>.

<https://www.isa.org/>.

<https://www.modbustools.com/>.

<https://www.sense.com.br/>.

150