Gerar PDF

HART 7 ®: DETALHANDO O PROTOCOLO

INTRODUÇÃO
HART® (Highway Addressable Remote Transducer) é um protocolo de comunicação bidirecional, introduzido em 1990. Utilizado em plantas industriais, no qual controla de modo padronizado o envio e recebimento de dados digitais através de cabos analógicos, entre dispositivos inteligentes e sistemas host (centralizado), é o protocolo mais difundido no mundo.
 
O host pode ser qualquer aplicativo de software, dispositivo portátil, sistema de segurança, gerenciamento de ativos, controle de processos da fábrica ou qualquer outro sistema que utilize alguma plataforma de controle.
HART é a tecnologia mais utilizada atualmente nas redes de automação industrial, instalada em mais de 30 milhões de dispositivos em todo mundo, oferecendo uma solução confiável e duradoura.
 
Os dados digitais são comunicados simultaneamente com o sinal 4-20 mA, utilizando o padrão Bell-202 de chaveamento por deslocamento de frequência FSK (Frequency Shift Key) a uma taxa de 1200 bps.



Figura 1 – Sinais HART®: digital e 4-20mA.
 
O sinal digital em baixo nível é superposto no sinal analógico 4-20 mA.

1200 Hz = "1"
2200 Hz = "0"
 
Sinal 4-20 mA: indica a PV (variável principal) do equipamento.

Sinal Digital: comunicação via comandos (status, configurações, diagnósticos, etc).

 
TOPOLOGIA
O protocolo se baseia na comunicação mestre/escravo com sua topologia podendo ser ponto a ponto ou multidrop (Figura 2) e permite a utilização de até dois mestres simultâneos (Figura 3). O mestre primário é um computador, CLP ou multiplexador. O mestre secundário geralmente é representado por handhelds ou softwares de configuração e calibração.




Figura 2 – Topologias ponto a ponto e multidrop.


Figura 3 – Conexão Mestre/Escravo HART®.
O modo multidrop permite que vários equipamentos sejam conectados em um mesmo barramento, ficando acessível a um único ponto de comunicação pelo host. A versão 7 do protocolo permite até 64 equipamentos conectados em multidrop (endereços 0 a 63), enquanto as versões anteriores permitem apenas 16 equipamentos (endereços 0 a 15).
 
O PROTOCOLO
Uma  grande  mudança  na versão  7  do  protocolo  HART®  ocorreu  com  a definição  do  modelo  sem  fio, chamado de WirelessHART. A Figura 4 exemplifica as diferenças entre as camadas para as definições com fio e sem fio do protocolo.



Figura 4 – Modelo OSI de camadas para HART® 7 (com fio e sem fio).
 
A camada física do modelo WirelessHART é definida pela norma IEEE 802.15.4, na faixa de 2,4 GHz (mesma do ZigBee). A camada de dados possui um protocolo intrínseco de controle e sincronismo de tempo (TDMA/CSMA). A camada de rede possui um protocolo de auto-organização e otimização de consumo do tipo Mesh.

Para maiores detalhes sobre a especificação WirelessHART no protocolo HART® 7, veja o artigo sobre WirelessHART em https://www.vivaceinstruments.com.br/.
 
PACOTE DE DADOS (FRAME)
O protocolo define um conjunto de comandos, no qual permite comunicação uniforme e consistente para todos  os  dispositivos  de  campo.  Para  que  estes  comandos  sejam  interpretados  corretamente pelo equipamento ao qual foi destinado, o protocolo especifica uma estrutura de dados, conhecida por frame HART®, que possui campos de sincronismo, endereçamento, comando, dados e segurança dos dados, como mostrado na Figura 5, a seguir.
 


Figura 5 – Estrutura de dados para comunicação HART® (frame).
A parte superior da figura, representada por vários bytes 0xFF é denominada de Preâmbulo e tem como função sincronizar o início de uma nova mensagem entre equipamento e host. Usualmente, ao menos cinco bytes de Preâmbulo são enviados em um frame, porém, de acordo com a especificação do protocolo, apenas dois bytes já são suficientes para validar um frame HART®.

Logo   após  os   bytes   de  Preâmbulo,  aparece  o   campo denominado Delimitador, que tem como função identificar o tipo de endereço e frame (longo ou curto), além do tipo da mensagem (do equipamento para o host, do host para  o equipamento ou burst). A distribuição dos bits que realizam estas identificações está indicada na Figura 6. O frame de tipo STX é conhecido como requisição, pois representa o envio do mestre ao escravo.
 

Figura 6 – Delimitador HART®.

 
Similarmente,  o  frame  do  tipo  ACK  é  conhecido como resposta, pois representa o retorno  da  requisição, do escravo ao mestre.
 
Além disso, o frame do tipo BACK é conhecido por modo Burst, onde o equipamento é programado pelo host para enviar mensagens específicas (geralmente comandos de monitoração ou status) em espaços de tempo pré-determinados. Veja mais sobre este modo no artigo sobre o protocolo WirelessHART.
 
O campo seguinte ao Delimitador é o responsável pelo endereçamento do equipamento ao qual o frame é destinado. Sendo assim, este campo, conhecido como Endereço, indica ao equipamento que recebe o
frame  se  deve  continuar  a  interpretá-lo  ou  se  pode  ignorá-lo,  a  partir  daquele  momento.  O   campo
Endereço pode possuir um ou cinco bytes, dependendo do tipo de frame, especificado no Delimitador. A Figura 7 exemplifica os modelos de frame curto e longo.
 
 


Figura 7 – Frames curto e longo HART®.

O frame curto possui um byte e é utilizado apenas com o comando zero, para identificação inicial do equipamento. Supondo que o host não conheça o fabricante ou o modelo do equipamento ao qual está se conectando, a única informação disponível é o chamado Polling Address, ou seja, o endereço curto do equipamento no barramento HART®, explicado anteriormente. Lembrando que a partir da versão 7 do protocolo HART®, este endereço passou a ser configurável entre 0 e 63 (os seis bits menos significativos do byte de endereço curto).

Os dois bits mais significativos indicam, respectivamente, o tipo de mestre host (primário ou secundário) e se o equipamento está em modo Burst. Estes dois bits são utilizados também no frame longo.
 
O  frame  longo,  além   dos dois  bits  já  citados,  possui  ainda  14     bits que  identificam  o  modelo   do equipamento, chamado de Expanded Device Type. Este valor é definido pela HART® Foundation no  momento do registro do equipamento pelo fabricante. Sendo assim, não existem fabricantes  ou  produtos  que possuam este código com valores idênticos.

Completando o campo Endereço do frame longo, existem ainda três bytes que identificam o equipamento propriamente dito, conhecidos como Unique Device Identifier (ou apenas Device ID). Supondo que um barramento possua dois equipamentos do mesmo fabricante e do mesmo modelo (por exemplo, dois transmissores de temperatura da Vivace), é necessário que o host possa identificá-los separadamente. Nesta caso, o fabricante gera um valor de identificação único para cada equipamento no momento de sua fabricação.
 
Após o campo de endereçamento, finalmente aparece o campo Comando, propriamente dito. Este campo especifica a qual comando se referem os dados contidos no frame em análise. A norma do protocolo especifica faixas de comandos para identificar seus tipos. As faixas de comando estão descritas na Tabela 1.
 
COMANDOS FAIXA DESCRIÇÃO
 UNIVERSAIS  0-30, 38 e 48  Obrigatórios a todos os equipamentos.
 PRÁTICA-COMUM 32-121, exceto 38 e 48  Funções comuns, não obrigatórios.
 ESPECÍFICOS  128-253 Funções exclusivas de um equipamento.
 PRÁTICA-COMUM  ADICIONAIS  512-767  Funções comuns, não obrigatórios.
 WIRELESSHART  768-1023 Funções para equipamentos sem fio.
 FAMÍLIA  1024-33791 Funções padronizadas para famílias de  equipamentos.
 ESPECÍFICOS  WIRELESSHART 64512-64765 Funções para equipamentos sem fio.
 ESPECÍFICOS ADICIONAIS  64768-65021 Funções exclusivas de um equipamento.

Tabela 1 – Faixas de comandos HART®.
 
Os campos definidos até este momento têm seu tamanho fixo, mesmo no caso do Endereço, pois o campo Delimitador define qual o tipo de frame. O campo de dados possui tamanho variado, pois os dados a serem enviados, seja na requisição ou na resposta, dependerão do comando a ser enviado e da necessidade do usuário para alguns comandos. Para resolver este problema, existe um campo, denominado Byte Count, responsável por identificar quantos bytes de dados estão sendo enviados no frame.
 

Quando o frame for do tipo STX (requisição do mestre ao escravo), a sequência de campo após o Comando será (Byte Count + Dados). Porém, quando se tratar de uma resposta (ACK ou BACK), dois bytes relativos à qualidade da resposta serão inseridos após o Byte Count.

O primeiro byte é denominado Response Code e indica possíveis erros de comunicação ou tratamento dos comandos (veja alguns exemplos na Tabela 2), podendo ser uma notificação, um aviso ou um erro. No caso do   erro,  o   comando   não   é  executado.  O   segundo   byte,  denominado   Status  indica  alterações   no comportamento do equipamento, definidas pelo protocolo de acordo com a Tabela 3.

 
RESP.CODE DEFINIÇÃO
  0xC0 Erro de comunicação: paridade no frame recebido.
  0xA0 Erro de comunicação: overrun. Byte sobrescrito.
  0x90   Erro de comunicação: framing. Stop bit não detectado.
  0x88   Erro de comunicação: checksum  calculado.
  0x82   Erro de comunicação: overflow. Frame muito longo.
  0x02 Erro de comando: seleção inválida.
  0x05 Erro de comando: poucos dados recebidos.
  0x07   Erro de comando: escrita protegida.

Tabela 2 - Exemplos de Response Code.
 
STATUS DEFINIÇÃO
0x80   Mau funcionamento do  equipamento.
  0x40   Configuração alterada.
  0x20   Reinicialização do equipamento.
  0x10   Status adicionais disponíveis.
  0x08   Corrente de saída em modo fixo.
  0x04   Corrente de saída saturada.
  0x02   Variável não-primária fora dos limites.
0x01   Variável primária fora dos limites.

Tabela 3 - Byte de Status do Equipamento.
 
O campo Dados traz as informações requeridas pelo comando enviado, sejam elas relativas a   monitoração de  variáveis, configuração de  parâmetros  ou  status  do  equipamento.  O tamanho  do  campo  Dados  é especificado  pelo  comando,  seja  ele  padrão  do  protocolo  ou  específico  do  equipamento.  Deve  ser acrescentado  no  contador Byte  Count  para  que  a  máquina  de  estados de  recepção  (no  host  ou  no equipamento) saiba em qual o byte finalizar este campo.
 
Aqui  surge  a  primeira grande  novidade existente a partir  da versão  6  do  protocolo HART®, porém mais evidente na versão 7 por ser utilizada em todos os comandos WirelessHAR. Como descrito anteriormente, o campo Comando oferece faixas destinadas a comandos padrões, específicos, WirelessHART, etc. Estes comando possuem valores de 0 a 65021, porém o campo Comando é definido como apenas um byte (0 a 255), pois era suficiente para as versões antigas do protocolo.

Como  solução  para  este  problema,  o  protocolo  criou  um  recurso  chamado  de  Comando   Expandido, indicado no campo Comando pelo valor 0x1F (flag de expansão), equivalente ao comando 31, não utilizado (veja na Tabela 1). Desta forma, quando a máquina de estado de recepção identifica este valor no campo Comando, entende que os primeiros dois bytes do campo Dados (após Response Code e Status, no caso de um frame de resposta) especificarão o comando expandido, garantindo a faixa até 65535.

Ainda sobre o conteúdo do campo Dados, geralmente a resposta de um comando inclui os dados enviados na requisição, seguidos por dados extras, em caso de monitoração. No caso de uma configuração, por exemplo, a resposta será idêntica à requisição, repetindo apenas os bytes enviados. Porém, ocorrendo erros de comunicação ou tratamento do frame HART®, apenas os campos Response Code e Status serão enviados, evidenciando claramente ao host que houve algum problema.

 
A Figura 8 exemplifica o comando 06, de alteração do Polling Address e Loop Current. O primeiro frame é uma requisição STX para alteração do endereço de polling para 01. Como resposta ACK, o equipamento repete no campo Dados os mesmos valores da requisição. Além disso, muda o Byte Count para 04, pois aumenta o frame com a adição do Response Code 00 e o Status 40 (configuração alterada).

 
STX:
FFFFFFFFFF 82 E337000001 06 02 0101 53
 
ACK:
FFFFFFFFFF 86 E337000001 06 04 00 40 0101 57

Figura 8 – Frames HART® STX e ACK sem erro.
 
Já no caso da Figura 9, temos um valor inválido para a alteração do endereço de polling (FF). Desta forma, a resposta ACK ao comando possui apenas dois bytes de dados, correspondentes ao Response Code (02 - Seleção Inválida) e Status.
 
STX:
FFFFFFFFFF 82 E337000001 06 02 FF01 AD
 
ACK:
FFFFFFFFFF 86 E337000001 06 02 02 00 55

Figura 9 – Frames HART® STX e ACK com erro.
 

Como último campo do frame HART®, o Checksum (ou verificação de soma) é responsável pela validação dos bytes transmitidos com uma segurança mínima. Para cada byte enviado a partir do campo Delimitador, uma operação lógica XOR é realizada, formando o byte final que será enviado neste campo. A máquina de recepção realiza as mesmas operações com os bytes recebidos, comparando o resultado final com o byte recebido no campo Checksum. O frame é validado apenas quando estes valores se equivalem. Caso contrário, o erro de comunicação 0x88 (veja Tabela 2) é exibido na resposta do equipamento.
 
APLICAÇÕES  DOS COMANDOS
Como explicado anteriormente, os comandos HART® são divididos em faixas que permitem selecionar quais funcionalidades devem estar presentes nos equipamentos de forma obrigatória ou opcional.
Os comandos Universais obrigatórios abrangem as seguintes funcionalidades:
  • Identificação básica (endereço polling, TAGs, descrição, mensagem, data);
  • Variáveis principais (corrente de loop, PV, SV, TV, QV);
  • Variáveis específicas (comando 9, onde o usuário escolhe o código da variável a ser monitorada);
  • Status adicionais do equipamento.

Os comandos de Prática-Comum opcionais abrangem as seguintes funcionalidades:
  • Calibração da corrente de loop;
  • Configurações da PV;
  • Reinicialização do equipamento;
  • Corrente de saída fixa;
  • Modo Burst;
  • Eventos.

Os comandos Específicos opcionais podem abranger as seguintes funcionalidades:
  • Características do fabricante;
  • Funções especiais do equipamento;
  • Calibrações extras (pressão , posição, temperatura, etc);
  • Diagnósticos específicos.


Figura 10 –Rede completa HART®.
 
Com esta variedade de funcionalidades e aplicações, o protocolo HART® oferece toda a flexibilidade e autonomia  de  que  o  usuário  necessita  para  automatizar  e  otimizar  processos,  com  facilidade  de manutenção, monitoração e diagnósticos de variáveis que sejam importantes para o correto funcionamento da planta.


Sobre o autores

Alex Ginatto é Gerente de Produto e Desenvolvedor R&D na Vivace Process Instruments.
 
Referências
  • HART HCF-Spec081
  • HART HCF-Spec099
  • HART HCF-Spec127r7.1
  • HART HCF-Spec151r10.0

This website uses cookies to ensure you get the best experience. To learn more, read our Privacy Policy. To accept!