Notícias

» » Artigo: Modelos Cliente-servidor Do Modbus Tcp E Publish-subscribe Do Mqtt: Quando Utilizar Cada Um Deles E Quais Suas Vantagens E Desvantagens?

25/01/2019

Artigo: Modelos Cliente-Servidor do Modbus TCP e Publish-Subscribe do MQTT: quando utilizar cada um deles e quais suas vantagens e desvantagens?

Autor: FABIO COELHO DE SOUZA SILVA 

Coordenador de Projetos

 

Introdução

 

O protocolo Modbus TCP é um velho conhecido no meio industrial e tem sido utilizado há anos em aplicações de automação. Pode-se dizer que esse protocolo foi uma evolução do Modbus Serial (RS485) que passou a trafegar sobre redes TCP/IP.


O modelo Cliente-Servidor (Mestre-Escravo) do Modbus TCP resolve uma grande gama de aplicações. Porém, com o advento de conceitos como Indústria 4.0, IoT e IIoT, 3G/4G e dispositivos wireless geograficamente distribuídos, surgem novas necessidades que dificultam bastante a utilização do Modbus TCP e seu modelo Cliente-Servidor. Para ajudar a resolver a comunicação de dados em aplicações em que o modelo Cliente-Servidor não resolve, este artigo apresenta o modelo Publish-Subscribe (“Publica-Assina") utilizado no MQTT, protocolo amplamente utilizado em soluções de IoT.


Esse artigo irá demonstrar as características, vantagens e desvantagens destes dois protocolos e de suas arquiteturas, além dos tipos de aplicações em que é indicado utilizar um ou outro.

 

Modelo Cliente-Servidor

 

Em computação, este modelo é uma estrutura de aplicação que distribui tarefas e cargas de trabalho entre os fornecedores de um recurso ou serviço, designados como servidores, e os requerentes dos serviços, chamados de clientes. Esse modelo foi desenvolvido pela Xerox PARC na década de 70 e atualmente é largamente utilizado nas mais diversas áreas da tecnologia.


Em resumo, cada cliente abre uma conexão direta com um servidor, formando uma conexão 1x1 (um para um) onde o servidor aguarda requisições dos clientes para responder. Clientes têm a função de realizar a conexão com o servidor, fazer as requisições e receber as respostas do servidor. Clientes nunca se conectam a outros clientes e não respondem a requisições. Servidores, por sua vez, aguardam conexões e requisições de clientes e atendem a elas com os dados solicitados. Servidores nunca realizam requisições.

 

Imagem 1: Topologia básica Cliente-Servidor

O protocolo Modbus TCP

 

O Modbus TCP utiliza o modelo Cliente-Servidor e tem algumas similaridades com seu “irmão mais velho”, o Modbus RTU. Uma delas é que o modelo Mestre-Escravo do Modbus RTU é muito parecido com o modelo Cliente-Servidor, onde o Mestre faz o papel do Cliente e o Escravo o do Servidor dos dados. Diferentemente do Modbus RTU, o Modbus TCP permite que um Escravo/Servidor se comunique com vários Mestres/Clientes.

Imagem 2: Exemplo de topologia Modbus TCP
 

O protocolo possui um identificador de transações (Transaction ID), o que é um ótimo recurso em uma rede que pode ter várias requisições simultâneas, garantindo que os clientes não confundam as respostas enviadas pelo servidor. Por exemplo, o cliente pode enviar requisições com ID 1, 2 e 3 e o escravo pode responder na ordem 3, 2 e 1. Devido ao Transaction ID, o cliente consegue associar o par requisição/reposta sem maiores problemas. Outra característica do protocolo Modbus TCP é a garantia de entrega das mensagens, pelo fato de transitar sobre a camada TCP, garantindo assim a coerência e entrega dos dados.


Quanto à segurança do protocolo, não existe nenhum mecanismo previsto no Modbus TCP: não possui senha, autorização, certificados ou qualquer outro mecanismo de segurança existente. Para tentar mitigar alguns destes problemas, muitos fabricantes criam seus próprios mecanismos de proteção para seus dispositivos, mas ainda assim todas as informações transitam de forma transparente na rede, que pode ser monitorada para fins maliciosos. A verdade é que, se você puder acessar um dispositivo Modbus em uma rede, você poderá “tomar conta” do dispositivo e poderá ler ou escrever qualquer registrador disponível.

 

Modelo Publish/Subscribe


A arquitetura Publish/Subscribe possui um conceito diferente. Aqui, há dispositivos/entidades que produzem e publicam dados (Publishers) e dispositivos/entidades que consomem esses dados (Subscribers). Além disso, há uma entidade que age como centralizador nessa troca de dados, comumente chamado de Message Broker. Assim, dispositivos passam a criar novos dados e enviá-los ao Broker através de mensagens. O Broker recebe e organiza essas mensagens por tópicos e distribui aos Subscribers as mensagens com os dados de seu interesse. Esse interesse é formalizado quando um Subscriber se inscreve para receber as informações de um tópico, que chamamos de assinatura. Uma vez feita a inscrição/assinatura de um tópico, toda a informação que chegar ao Message Broker endereçada a esse tópico será reenviada aos Subscribers inscritos.


Neste modelo, é importante salientar que os Subscribers nunca se comunicam com os Publishers, quem faz o laço de ligação entre Publisher e Subscriber é sempre o Message Broker. Eventualmente, o mesmo dispositivo pode ser um Publisher e um Subscriber.

Imagem 3: Arquitetura básica Publish - Subscriber

 

Neste modelo temos então os seguintes personagens:


* Publisher: É o provedor de informações e se conecta ao Broker para enviar mensagens em formato de tópicos. Um Publisher pode publicar um ou vários tópicos e, se tiver capacidade, pode fazer publicações em mais de um Message Broker.


* Subscriber: É o consumidor de informações e se conecta ao Message Broker para se inscrever nos tópicos cujas informações deseja receber. Tem a responsabilidade de manter a conexão ativa com o Message Broker de forma a poder receber as informações.


* Message Broker: É um middleware que faz a gestão de tópicos e gerencia publicadores e assinantes. Responsável por receber as mensagens dos publishers e enviar aos subscribers conectados, ele garante a interoperabilidade da aplicação.

 

Imagem 4: interoperabilidade de sistemas com publish/subscribe

 

* Tópicos: São os identificadores das mensagens enviadas pelos publishers. Agem como uma chave que deve ser utilizada pelos subscribers para se inscrever nas mensagens desejadas. Exemplo de um tópico publicado pelo LogBox Wi-Fi:


novus//status/channels: A cada novo registro gravado na memória, é enviada uma mensagem com informações sobre os valores dos canais, o timestamp em que o registro foi realizado, o estado de alarme dos canais e outras informações.

 

O protocolo MQTT

 

O MQTT (Message Queue Telemetry Transport) é um protocolo de aplicação leve, que apesar de ter “fila de mensagens” em seu nome (Message Queue), é baseado na arquitetura publish/subscribe para envio de mensagens e se tornou o padrão para comunicações de IoT. Assim como o protocolo Modbus TCP, o MQTT transita sobre a pilha TCP/IP. Criado pela IBM nos finais dos anos 1990, sua aplicação original era vincular sensores em pipelines de petróleo e satélites. Em 2014, o MQTT se tornou um padrão aberto, com suporte em diversas linguagens de programação e usando diversas implementações de software livre.


Os princípios do protocolo são:


 Minimizar os requerimentos de recursos dos dispositivos oferecendo uma interface extremamente leve, simples e com baixo overhead (entre 2 e 4 bytes).


 Otimizar seu trânsito em redes não confiáveis e de baixa latência.


 Realizar a comunicação de forma assíncrona entre as partes, de forma ao emissor e receptor estarem desacoplados tanto no espaço quanto no tempo.


Devido ao fato de utilizar a arquitetura publish/subscribe o protocolo garante alta escalabilidade nas suas aplicações, onde inúmeros dispositivos podem publicar mensagens e vários outros assinantes podem consumir suas informações.


O MQTT, apesar de ser um protocolo simples, não deixa de contemplar características de segurança nos envios de suas mensagens. As conexões entre clientes e Broker podem ser criptografadas (TLS) para proteger os dados em trânsito. Além disso, Brokers podem requerer login e senha para aceitar uma conexão. Como o MQTT não restringe o formato dos dados de suas mensagens, o payload ainda pode ser criptografado pelo publicador e depois descriptografado quando seus assinantes receberem as mensagens.

 

 

Imagem 5: Protocolo MQTT e seu sistema de mensagens.

 

O protocolo ainda possui mecanismos como qualidade de serviço (QoS), que define como é realizada a troca de mensagens entre Broker e os clientes (publishers e subscribers). Quanto maior o grau de qualidade de serviço, mais segurança na entrega das mensagens, mas com mais lentidão na troca de mensagens, além de um maior trafego de dados na rede.


O protocolo MQTT, com suas características de interoperabilidade e facilidade de implementação, é uma ótima solução para aplicações de IIoT e sistemas de automação industrial que procuram ter aderência com o conceito de “Indústria 4.0”. Deve-se considerar o protocolo pela facilidade com que os dados gerados por dispositivos podem ser acessados simultaneamente por diversos sistemas, sejam do tipo SCADA, ERP, Sistemas “Big Data” ou de “Machine Learning”. Da mesma maneira, é possível conectar o mundo externo (logística, fornecedores, clima, serviços em Nuvem) aos sistemas internos das organizações. A imagem abaixo demonstra estas possibilidades de integração com a utilização do protocolo MQTT.

 

Imagem 6: Interoperabilidade entre sistemas e aplicações

 

MQTT x Modbus TCP: quando utilizá-los

 

A decisão de utilizar ou não uma nova tecnologia geralmente causa dúvidas. Nesses momentos, deve-se verificar se a tecnologia que esteve sendo utilizada até então continua atendendo todas as necessidades da nova aplicação. Muitas vezes, uma nova tecnologia pode resolver problemas de uma forma melhor e mais barata do que a utilizada atualmente, ou mesmo abrir novas possibilidades de integração entre os setores da organização. Por outro lado, não devemos abrir mão de uma análise e adotar cegamente uma nova tecnologia apenas porque ela é nova!


Segue alguns prós e contras de cada um dos protocolos/arquiteturas:

 


 Vantagens do protocolo MQTT


o Não é necessário saber a rede, endereço ou local físico dos dispositivos que geram os dados (publishers), basta os assinantes se conectarem ao broker e assinar os tópicos dos dispositivos para receberem suas informações.


o O envio de dados dos publicadores não requer uma pergunta (request). Dessa forma, o publicador administra o melhor momento para enviar seus dados ao broker, o que possibilita um gerenciamento de energia mais eficiente.


o Com um broker hospedado fora da rede local da empresa, alguns problemas que envolvem segurança de TI e TA podem ser evitados, como a abertura de portas de entrada para que um supervisório receba dados dos dispositivos.


o Facilidade em implementar aplicações geograficamente distribuídas com o uso de redes 2G, 3G ou 4G, devido ao problema do IP dos dispositivos ser alterado a cada nova conexão e o acesso “de fora” se tornar complicado. No MQTT, todos os publicadores e assinantes possuem a iniciativa da conexão, apontando para o broker.


o É um protocolo com camadas de segurança implementadas, login e senha para acesso aos brokers e TLS para troca de mensagens.


o Possíveis aplicações onde muitos assinantes podem receber informações de muitos publicadores.


o A grande maioria dos serviços em Nuvem tem compatibilidade com esse protocolo: Amazon AWS, Microsoft Azure, IBM Bluemix e Google Cloud, entre as mais conhecidas.


 Vantagens do Protocolo Modbus TCP


o Não necessita de um intermediário (broker), pois a conexão é feita ponto a ponto.


o Garante o recebimento da informação no destinatário final, ou seja, o cliente sabe que a sua pergunta chegou ao servidor e o servidor sabe que a resposta chegou ao cliente.


o Servidores que permitem múltiplas conexões conseguem atender a múltiplos clientes simultaneamente, o que torna possível, por exemplo, que um software SCADA e um supervisório mobile se comuniquem com o mesmo dispositivo para ler seus dados.


o Clientes podem obter informações do servidor a qualquer momento, sem ter que aguardar o envio espontâneo por parte dos clientes.


o Praticamente todos os softwares SCADA e supervisórios em geral dão suporte ao protocolo, pois há décadas é largamente utilizado no meio industrial.


o É possível que um dispositivo servidor também funcione como gateway de uma rede Modbus RTU. Desta forma, os clientes podem se comunicar com todos os dispositivos na mesma conexão simplesmente endereçando as suas perguntas ao dispositivo correto.

 

Perfil de aplicações para cada um dos protocolos

 

Abaixo temos uma tabela com diversos perfis de aplicação e com qual protocolo tais aplicações podem ser mais bem resolvidas. Em diversos casos será possível utilizar qualquer um dos protocolos e, nesses casos, é preciso analisar fatores como custo de implementação e complexidade da solução como critérios para escolha.

 

Tabela 1: Perfil de aplicações x Protocolo ideal
 

Conclusão

 

Com tudo o que foi apresentado, podemos concluir que não existe um protocolo melhor ou pior que o outro, mas sim aplicações mais adequadas para uma ou outra arquitetura/protocolo.


Por que utilizar o MQTT se o Modbus sempre satisfez minhas necessidades? A novidade do MQTT em relação à tradição do Modbus TCP deve ser sempre avaliada caso a caso: em alguns casos a vantagem em mudar é evidente, em outros não há a menor necessidade.

 

Gostou do artigo? Clique aqui para fazer o download em PDF!

Produtos Relacionados

Mais notícias

Transmissor de ultra baixa pressão diferencial da NOVUS chega ao mercado

03/07/2019

O NP785 garante compensação de temperatura para estabilidade em longo prazo e obedece a padrões de compatibilidade eletromagnética. Além disso, ele pode operar bidirecionalmente, sendo capaz de medir faixas de pressão diferencial que variam do vácuo à pressão positiva.

Novo módulo de I/O da NOVUS leva a indústria 4.0 para o trilho DIN

03/07/2019

O DigiRail Connect pode ser usado como dispositivo escravo em redes Modbus RTU com interface RS485 ou como dispositivo servidor em redes Modbus TCP sob Ethernet.

Artigo: Medição de pressão e a metrologia

01/07/2019

O procedimento de medição da pressão está amplamente difundido dentro dos processos industriais, e sua confiabilidade está associada à questões comerciais, de qualidade, saúde e segurança, uma vez que uma medição errônea pode acarretar desde problemas de qualidade no processo industrial até mesmo acidentes fatais. Confira no artigo algumas definições sobre o tema e um exemplo que demonstra a importância da metrologia dentro da indústria.

NOVUS apresenta na FIEE lançamentos com destaque em conectividade

18/06/2019

De 23 a 26 de julho, a NOVUS apresenta na feira seus principais lançamentos de 2019 voltados para a indústria 4.0 e alinhados com tendências mundiais na automação industrial.

Artigo: Fatos e mitos sobre Sistemas em Nuvem

17/06/2019

As tecnologias de computação em nuvem já são uma realidade consolidada no mercado. Entretanto, muitas pessoas ainda impõem diversos obstáculos para incorporar a nuvem em processos dentro da sua empresa, embora a utilizem no seu cotidiano. O objetivo deste artigo é elucidar fatos e mitos em relação a essa tecnologia e facilitar a decisão entre implantar ou não sistemas de supervisão em nuvem na sua empresa.

Aviso de Privacidade Global NOVUS

A NOVUS tem o compromisso de proteger a privacidade e a segurança de suas informações pessoais. As informações que você compartilha com a NOVUS nos permite proporcionar uma melhor experiência quando você usa nossos produtos e serviços. Garantimos a total privacidade aos seus dados, usados exclusivamente para comunicações entre a NOVUS e você.

Neste comunicado afirmamos:

  1. A NOVUS não vende ou negocia informações de clientes;
  2. Seus dados ficam armazenados em ambiente seguro e controlado;
  3. Usamos seus dados apenas para comunicações de seu interesse;
  4. A qualquer momento você pode optar por sair da lista de comunicados;

Por favor, consulte nossa Política de Privacidade completa.

Após ler nossa Política de Privacidade, escolha a opção abaixo: