O que é MQTT e como as empresas de automação industrial podem usá-lo?

Se você estiver se envolvendo com a Internet das Coisas industrial (IIoT), verá um novo acrônimo sendo usado em todo lugar:MQTT. Embora o MQTT seja relativamente novo na automação, ele existe há mais de 20 anos. Ele foi originalmente desenvolvido como um protocolo para obter dados de campos petrolíferos remotos, mas até recentemente, nunca ganhou muita adoção fora desse aplicativo de nicho. Agora está emergindo como um dos principais protocolos para projetos de transformação digital para manufatura.

O que é MQTT?

MQTT significa Transporte de Telemetria de Enfileiramento de Mensagens. É um protocolo de transporte de mensagens de publicação/assinatura de servidor cliente, considerado um protocolo de mensagens leve para enviar pequenos pacotes de informações em aplicativos de largura de banda limitada. Em sua essência, é considerado um padrão OASIS no coração da conectividade IoT.

Histórico

No final da década de 1990, havia a necessidade de um protocolo de comunicação leve que pudesse transmitir dados de locais remotos de petróleo com velocidades de conexão extremamente baixas, talvez tão baixas quanto 300 bauds. A estratégia foi aproveitar os recursos já oferecidos na camada de transporte, que utilizava o protocolo TCP. O protocolo de aplicação proposto removeria qualquer redundância adicionada à carga útil de transmissão. Também precisava ser stateful e apenas relatar por exceção. Com essas restrições em mente, Phillips 66 trabalhou com Arlen Nipper da Cirrus Link Solutions e Andy Stanford-Clark da IBM para desenvolver o que hoje é conhecido como protocolo MQTT.

Primeiros usos comerciais

Enquanto as empresas de automação foram abordadas com o protocolo MQTT no início dos anos 2000, seu único outro uso comercial foi com os aplicativos Facebook Messenger e Apple Messages. A principal característica de interesse é que o protocolo garante um estado e qualidade dos dados. Quando um remetente estivesse digitando, o receptor veria os três pontos agora muito familiares na tela. Também foi usado em alguns aplicativos de monitoramento doméstico e dados meteorológicos, mas naquele momento, o uso do MQTT era bastante limitado.

Adoção de automação

Em meados da década de 2010, Arlen Nipper mais uma vez abordou as empresas de automação para promover o uso do MQTT. Havia uma necessidade emergente de obter dados de fabricação adicionais agregados sem uma demanda de rede significativa. No entanto, havia alguns recursos adicionais que precisavam ser desenvolvidos para obter aceitação na fabricação. A Cirrus Link Solutions, juntamente com a Automação Indutiva, prosseguiu com o desenvolvimento do que é agora o padrão Sparkplug, que inclui atributos necessários para a automação, nomeadamente um conjunto definido de tópicos, uma carga útil padrão e compressão de mensagens.

Visão geral da estrutura

O MQTT usa uma estrutura semelhante à estrutura de pastas de um computador. Vou usar a área de trabalho do Windows como exemplo. A área de trabalho tem uma pasta chamada Meus Documentos. Em Meus Documentos, há outra pasta chamada Família, e nessa pasta há uma pasta para cada membro da família. O caminho para minha pasta seria Desktop/Meus Documentos/Família/David. Eu salvaria (publicaria) todos os meus documentos para David. Qualquer um que quisesse ler meus documentos abriria (assinaria) David.

Os dispositivos que usam o protocolo MQTT publicarão e assinarão um caminho de tópico semelhante chamado namespace. Assim como um computador, ele é organizado do mais geral para o mais específico. Quanto maior o nível que eu subscrevo, mais dados vou receber. Há também curingas que podem ser usados ​​para ajudar a definir um caminho de tópico. Um asterisco (*) inclui tudo do nível atual e abaixo. Um sinal de mais (+) move o caminho um nível abaixo. Eu incluí alguns exemplos mais abaixo no artigo.

Alinhamento com os padrões ISA

O padrão ISA-95 é bem compreendido na fabricação. Ele descreve um modelo padrão e terminologia para a interface entre os sistemas corporativos e de controle. Embora geralmente seja realizado como uma hierarquia, começando com um ERP no topo e dispositivos na base, o padrão lida principalmente com dados de fabricação e como eles devem ser estruturados. Como o MQTT usa um namespace de tópico, eles podem ser prontamente alinhados com a hierarquia ISA-95. Recomenda-se que um namespace de tópico siga o Enterprise, Site, Area, Line e Cell quando for construído. A pasta raiz do editor/assinante também deve existir no nível adequado. Por exemplo, um CP que controla uma célula deve publicar seus dados em um tópico de Empresa/Site/Área/Linha/Célula. Se um histórico de processo for específico de uma área, ele deverá registrar todos os dados no nível da Empresa/Site/Área.

Arquitetura

Uma das dúvidas comuns decorrentes do uso do MQTT é o que acontece quando há perda de conectividade. Existem várias opções que podem ser usadas para mitigar essas situações. Uma solução comum é usar um método de "armazenar e encaminhar". Por exemplo, os sistemas SCADA que estão na camada de controle continuarão a coletar dados até que a conexão com o broker MQTT seja retomada. Deve-se observar que quando a conexão do broker é retomada, os registros de data e hora de todos os dados armazenados permanecem intactos.

O MQTT também suporta o uso de agentes de backup. Enquanto houver um broker primário, se esta conexão for perdida, os nós conectados mudarão automaticamente para outro broker. O relacionamento geralmente é configurado por meio de um aplicativo (como um sistema SCADA) que suporta esse recurso.

Outra solução é alcançada através do uso de clustering. Isso é típico para aplicativos que não podem arcar com nenhuma perda de dados. Uma configuração comum é ter vários brokers MQTT organizados em um cluster. Todos esses brokers estão cientes uns dos outros e compartilharão mensagens dentro do cluster. Quando a conectividade é perdida, os editores e assinantes de dados encaminham os dados para outro corretor sem qualquer perda.

É comum que um aplicativo corporativo use dados de todas as suas plantas. Para este cenário, o MQTT suporta o uso de ponte que é semelhante a um sistema de armazenamento e encaminhamento. Nesta arquitetura, um broker publicará ou fará a ponte de algum ou todo o seu namespace para outro broker. Dito de outra forma, um corretor de fábrica faria a ponte para um corretor de empresa. Tanto os tópicos publicados quanto a estrutura do namespace podem ser definidos. Isso limita a quantidade de dados publicados e fornece contexto para o broker de recebimento.

Publicar todos os dados como estão com um asterisco (*) e não definir nenhuma estrutura é a maneira mais simples, mas isso pode resultar em muitos dados desnecessários e potencialmente confusos. Para fornecer algum contexto de dados, um tópico pode ser adicionado ao início do namespace do tópico publicado. Por exemplo, Enterprise/Site pode ser adicionado ao namespace Area/+/Cell da planta, o que resultaria no envio de Enterprise/Site/Area/+/Cell ao agente Enterprise. O resultado é que os dados em nível de célula de todas as linhas estariam disponíveis neste sistema (observe o uso do caractere curinga +).

Todos esses cenários podem ser implantados. Um sistema SCADA pode usar armazenamento e encaminhamento para um cluster MQTT. Pode haver clusters primários e de backup, mas isso provavelmente adicionaria complexidade desnecessária. Por fim, um cluster de fábrica pode conectar-se a um cluster corporativo para maximizar a integridade dos dados. Isso é ótimo para análises corporativas e aprendizado de máquina, pois exigem quantidades significativas de dados de boa qualidade.

Segurança

Uma das principais preocupações com o envio e recebimento de dados de fabricação pela Internet é a segurança cibernética. Embora a única maneira de estar realmente seguro seja por meio do uso de uma lacuna de ar, isso impedirá a capacidade de uma organização de se transformar digitalmente. Um dos principais benefícios do MQTT é a segurança. Enquanto outros protocolos de comunicação requerem a abertura de portas de rede, o MQTT requer apenas uma conexão de saída com o broker. As plantas não precisam abrir nenhuma porta de entrada, o que é muito atraente para as organizações de TI.

Considerações futuras

Em artigos futuros, explorarei aplicativos comuns com o MQTT. Embora o protocolo deva ser bastante plug-and-play, provavelmente haverá interesse em detalhes técnicos adicionais. Os líderes de negócios podem querer considerar como o MQTT afetará seus atuais esforços de transformação digital. E, é claro, os líderes de engenharia definitivamente vão querer saber como o MQTT os afetará.

Para encerrar, o MQTT não deve ser considerado um substituto para a arquitetura existente. Alinhado com os requisitos da Indústria 4.0, ele aproveita o que já está em vigor. Continuará a ser necessário o OPC UA e outros protocolos, pois são mais detalhados para aplicações de controle. No entanto, quando se trata de agregar quantidades significativas de dados, o MQTT é uma excelente escolha.