segunda-feira, 10 de dezembro de 2012

Modbus – Um Protocolo e Diferentes Implementações

Alguns padrões de comunicação simplesmente aparecem e são adotados pelo mercado!

Não é porque eles são empurrados, de cima para baixo, por um grupo de fornecedores grandes ou por uma organização de padronização. Padrões como o Modbus aparecem e são adotados pelo mercado porque eles são bons, simples de implementar e são, como consequência, adotados por inúmeros fabricantes. Devido a isso, o Modbus tornou-se um padrão amplamente aceito nos diversos segmentos do mercado de automação.

Em 1979, a Gould-Modicon lançou para seus CLPs a rede de comunicação Modbus. Ela tinha como base o protocolo de comunicação Modbus serial. Este protocolo era apresentado em duas versões:
  • Modbus serial RTU.
  • e, Modbus serial ASCII.
A rede de comunicação Modbus operava sobre os padrões RS-485 (para redes multiestação) e RS-232 (para conexões entre duas estações).

A Gould-Modicon, após lançar a rede Modbus, disponibilizou publicamente as especificações do protocolo e da rede. De forma que qualquer empresa que quisesse implantar este padrão em seus equipamentos poderia fazê-lo sem ter que pagar qualquer direito de uso à Gould-Modicon.

No início dos anos 80, a Gould-Modicon lançou para seus CLPs a uma evolução da rede de comunicação Modbus, chamada Modbus Plus.

No caso da rede Modbus Plus, a Gould-Modicon não disponibilizou ao público as especificações de protocolo e da rede, transformando-a em uma rede proprietária.
A rede Modbus Plus foi descontinuada ao final dos anos 90 e, na prática, não é mais encontrada.

Como a rede ethernet se popularizou na automação industrial a partir de meados dos anos 90, a comunidade de usuários passou a usar o protocolo Modbus serial neste tipo de rede, usando um método chamado de encapsulamento.

E, finalmente em 1999, foi lançada a especificação do protocolo Modbus para redes ethernet. Esta nova versão do protocolo definiu o uso do TCP/IP para o transporte das mensagens e foi chamada de Modbus TCP.

No início dos anos 2000 a Schneider Electric, sucessora da Gould-Modicon e outros, deu suporte à criação da "The Modbus Organization". Esta organização, sem fins lucrativos, é mantida pela comunidade de usuários do protocolo com objetivo de manter e gerenciar a necessidade de evolução das especificações do protocolo, incentivar seu uso e oferecer informações necessárias para a sua correta implementação (http://www.modbus.org). Esta organização criou e incentiva um programa de testes para certificação de produtos que implementam o protocolo.

Esta iniciativa permite aos usuários evitar a compra de produtos que incorporem drivers Modbus implementados com interpretações particulares das especificações – muito comuns no passado.

As duas maiores dificuldades de uso do protocolo Modbus estão relacionadas a:
  • documentação sobre a interface de comunicação, sua parametrização;
  • mapa de memória do dispositivo;
  • e, implementações com interpretação particularizada das especificações.
Por exemplo, para implantar um sistema composto de um supervisório e alguns dispositivos Modbus (medidores de energia, pequenos CLPs ou outros), são necessários:
  • configurar os parâmetros de rede na interface de comunicação do computador e dos dispositivos;
  • e, ter o mapa de memória do dispositivo listando cada variável do dispositivo com seu endereço Modbus equivalente.
As informações necessárias para executar estas tarefas deveriam fazer parte da documentação (ou de anexos) de cada dispositivo. Mas, na prática, a documentação não apresenta as informações de forma clara e padronizada e muita vezes tem que ser solicitadas ao suporte técnico do fabricante do dispositivo (não vem junto com o dispositivo).

Outro fator de confusão na implementação deste tipo de sistema são as implementações do protocolo com interpretação particularizada das especificações. O protocolo Modbus foi criado faz 30 anos, e, muitos recursos e funcionalidades comuns nos equipamentos de hoje em dia não existiam nos equipamentos naquela época. Com isto, recursos tais como: números muito grandes, números de ponto flutuante, formas de endereçamento e alocação de memória para os diferentes tipos de dados, entre outras, não foram considerados nas definições do protocolo. Com isto as empresas criaram suas próprias definições, a partir de práticas existentes ou fazendo definições particulares.

Por exemplo, existem alguns formatos para os números de ponto flutuante: meia precisão, precisão simples ou dupla, com sinal ou sem sinal.

Que forma armazenar estes números na memória dos dispositivos? Os fabricantes dos dispositivos, uma vez que a especificação do protocolo não faz qualquer definição acerca, podiam optar por algum padrão existente ou criar seu próprio padrão de armazenamento.

Esta falta de definição na especificação do protocolo cria uma dificuldade para o usuário, caso o fabricante do dispositivo não informe de forma clara na documentação qual o formato usado para armazenar os números de ponto flutuante na memória do dispositivo.

Como a questão do ponto flutuante, existem outros desvios ou implementações particularizadas que causam confusão na implantação de sistemas com o protocolo Modbus, tais como:
  • endereçamento das Estações Escravo Modbus (com mais de um byte);
  • modo Broadcast;
  • endereço dos Registros (base 0 x base 1);
  • endereço dos Bits (base 0 x base 1);
  • ordem de transmissão dos bytes nos registros;
  • ordem de transmissão para valores que usam mais de um registro (números de 32 ou 64 bits - inteiros ou ponto flutuante).
Vamos examinar a questão da ordem de transmissão dos bytes nos registros.

O protocolo Modbus especifica que para transmitir um registro (dois bytes) o dispositivo deve transmitir primeiro o byte de ordem superior e depois o byte de ordem inferior. Ou seja, para transmitir o valor 0x35A2 ele deve transmitir 35 no primeiro byte e A2 no segundo byte, desta forma o dispositivo que recebe o valor vai decodificar 0x35A2 e apresentar o valor decimal 13.730.

Porém alguns fabricantes não respeitam esta definição do protocolo e ao invés de transmitir 35 no primeiro byte e A2 no segundo byte, eles fazem a transmissão invertida. Primeiro é transmitido o A2 e depois é transmitido o 35, desta forma o dispositivo que recebe a mensagem vai decodificar 0xA235 e apresentar o valor decimal 41.525, que não corresponde ao valor na memória do dispositivo original.

Alguns drivers, no editor de configuração, têm uma opção que permite desfazer esta inversão. Neste caso é só habilitar esta opção e o driver faz a inversão de bytes a cada dois bytes de dados recebidos.

Se o seu driver não fizer esta inversão, você vai ter que escrever uma rotina de programa para fazê-la.

Este tipo de inversão é mais comum do que se imagina, portanto quando você estiver recebendo um valor diferente do valor de origem faça a conversão do valor na origem e no destino para o formato hexadecimal e verifique se você não está tendo uma inversão de bytes na transmissão.

segunda-feira, 3 de dezembro de 2012

Apresentando dados dinâmicos na web

Sem a necessidade de um sistema SCADA


Os gerentes de empresa sabem que as informações importantes sobre seus processos produtivos estão nos sistemas que controlam a produção. Sendo assim, cada vez mais é importante disponibilizar os dados dinâmicos de chão de fábrica para toda a empresa para que seja possível monitorar, em tempo real, o desempenho e a programação da produção. Quando nós  falamos de dados dinâmicos, nós estamos nos referindo a dados cujo valor altera constantemente. Dados como: dados de processo, métricas KPI de negócios e outros.

E a melhor forma de disponibilizar estes dados é através de páginas de internet. Assim, a partir de qualquer computador com acesso a Internet, é possível visualizar as informações usando apenas um navegador. É interessante poder apresentar os dados em diferentes formatos como: cartas de tendência, tabelas, controles deslizantes, medidores, barras de progresso e outros. Sempre que os dados mudarem de valor os elementos na tela devem atualizados automaticamente, sem a necessidade de fazer o “refresh” da página.

Porém, apresentar dados que mudam constantemente desta forma em uma página de internet sempre foi um desafio para desenvolvedores e para usuários.

Uma solução freqüente é usar cliente web dos softwares SCADA. Porém a tecnologia de internet avança rapidamente, e os principais fornecedores SCADA não. Atualmente todos os grandes fornecedores de software SCADA estão usando tecnologias de internet antigas, tais como ActiveX, Java e ASP. Além disso, em todos os softwares SCADA você precisa pagar pelo número de pontos ou pelo número de conexões de cliente web que você precisa.

Figura 1. Arquitetura de visualização de dados dinâmicos usando SCADA Web Server 


A tecnologia de internet mais recente disponível no mercado é o Silverlight da Microsoft, que permite a criação de telas atraentes e com atualização rápida para a web, e com os mais altos padrões de segurança disponíveis em um navegador. Um software que permite apresentar dados de processo na web de forma dinâmica, sem necessidade de um sistema SCADA e que utiliza a tecnologia Silverlight, é o DataHub WebView da Cogent Real-Time Systems.

O DataHub WebView é um aplicativo do tipo “cloud”, auto hospedado, projetado para a apresentação de telas gráficas dinâmicas (animadas) através da web. Baseado na última tecnologia da Microsoft, o Silverlight 4.0, e no núcleo do DataHub da Cogent, este aplicativo introduz novas formas de apresentar dados de processo em qualquer sistema interligado por rede ou Internet usando browsers de internet. Simples de instalar, ele permite criar em pouco tempo seu sistema baseado em uma “cloud” particular. Você pode controlar quem acessa, quais dados podem ser acessados e quem tem direitos para criar novas telas.


Figura 2. Arquitetura de visualização de dados dinâmicos usando DataHub WebView da Cogent 


O DataHub WebView não cobra por número de ponto nem por número de conexões de cliente. Ou seja, por um custo único você pode criar quantas páginas quiser, com quantos pontos forem necessários, que podem ser acessados por um número ilimitado de clientes.


Figura 3. (a) Tela do DataHub WebView apresentando dados dinâmicos na web e (b) Tela do DataHub WebView em modo de edição de tela pela web


Clique aqui para obter mais informações sobre o DataHub WebView.