Utilizamos cookies para oferecer melhor experiência, melhorar o desempenho, analisar como você interage em nosso site e personalizar conteúdo. Saiba mais sobre nossa política de privacidade.
25/01/2019
O protocolo Modbus TCP tem sido utilizado há anos em aplicações de automação, porém, com o advento de conceitos como Indústria 4.0, IoT e dispositivos wireless, 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 utilizado no MQTT, protocolo amplamente utilizado em soluções de IoT.
Autor: FABIO COELHO DE SOUZA SILVA
Coordenador de Projetos
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.
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.
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.
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.
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.
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.
* 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 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.
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.
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.
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.
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.
Compartilhar:
20/03/2024
Use o código para entrada gratuita
20/02/2024
Desenvolva suas habilidades com a equipe técnica da NOVUS
30/01/2024
A NOVUS Automation é um participante importante da Distributech 2024.
21/12/2023
A NOVUS tem o orgulho de anunciar que investiu na startup Sensify, que acaba de fechar rodada de captação de recursos com investidores estratégicos.
14/11/2023
Veja as datas limite para pedidos e período de férias
