MQTT na Automação Industrial: Guia Prático para Fabricantes

Se você está se envolvendo com Internet Industrial das Coisas (IIoT), certamente verá um novo acrônimo em todo lugar: MQTT. Embora relativamente novo na automação, existe há mais de 20 anos. Originalmente desenvolvido como protocolo para obter dados de campos de petróleo remotos, só recentemente ganhou adoção fora deste nicho. Agora emerge como um dos principais protocolos para projetos de transformação digital na manufatura.

O que é MQTT?

MQTT significa Message Queuing Telemetry Transport. É protocolo de transporte de mensagens cliente-servidor publish/subscribe, considerado protocolo de mensagens leve para envio de pequenos pacotes de informação em aplicações de largura de banda limitada. No núcleo, é padrão OASIS no coração da conectividade IoT.

História

No final dos anos 1990, surgiu necessidade de protocolo de comunicação leve para transmitir dados de locais remotos de petróleo com velocidades de conexão extremamente baixas, talvez 300 baud. A estratégia era aproveitar capacidades já oferecidas na camada de transporte, que usava protocolo TCP. O protocolo de aplicação proposto removeria redundância que aumentava a carga de transmissão. Também precisava ser stateful e reportar apenas por exceção. Com estas restrições, Phillips 66 trabalhou com Arlen Nipper (Cirrus Link Solutions) e Andy Stanford-Clark (IBM) para desenvolver o que hoje é o protocolo MQTT.

Usos Comerciais Iniciais

Empresas de automação foram abordadas com MQTT no início dos anos 2000, mas seu único outro uso comercial foi no Facebook Messenger e Apple Messages. A característica de interesse: protocolo garante estado e qualidade dos dados. Quando remetente digitava, destinatário via os três pontos familiares. Também usado em monitoramento residencial e dados meteorológicos, mas uso era limitado.

Adoção na Automação

Meados de 2010, Arlen Nipper novamente abordou empresas de automação para promover MQTT. Havia necessidade emergente de agregar dados de manufatura sem demanda significativa de rede. Porém, capacidades adicionais precisavam ser desenvolvidas para aceitação na manufatura. Cirrus Link Solutions, com Inductive Automation, desenvolveu o padrão Sparkplug, que inclui atributos necessários para automação: conjunto definido de tópicos, payload padrão, compressão de mensagem.

Visão Geral da Estrutura

MQTT usa estrutura similar à de pastas de computador. Exemplo: Área de Trabalho tem pasta Meus Documentos. Dentro, pasta Família, e dentro, pasta para cada membro. Caminho para minha pasta: Área de Trabalho/Meus Documentos/Família/David. Salvo (publico) documentos em David. Quem quiser ler abre (assina) David.

Dispositivos MQTT publicam e assinam caminho de tópico similar chamado namespace. Organizado do mais geral ao mais específico. Quanto mais alto o nível assinado, mais dados recebo. Curingas ajudam a definir caminho: asterisco (*) inclui tudo do nível atual para baixo; mais (+) move um nível abaixo. Exemplos adiante.

Alinhamento com Padrões ISA

ISA-95 é bem entendido na manufatura. Descreve modelo padrão e terminologia para interface entre sistemas corporativos e de controle. Embora geralmente visto como hierarquia (ERP no topo, dispositivos na base), lida principalmente com dados de manufatura e sua estrutura. Como MQTT usa namespace de tópicos, podem ser alinhados com hierarquia ISA-95. Recomenda-se que namespace siga Empresa, Planta, Área, Linha, Célula. Pasta raiz do publisher/subscriber deve existir no nível adequado. Ex.: CLP controlando célula deve publicar dados em tópico Empresa/Planta/Área/Linha/Célula. Se historiador de processo é específico a uma área, deve assinar todos dados no nível Empresa/Planta/Área.

Arquitetura

Pergunta comum: o que acontece com perda de conectividade? Várias opções mitigam:

Store-and-forward (armazenar e encaminhar): Sistemas SCADA na camada de controle continuam coletando dados até reconexão ao broker MQTT. Timestamps dos dados armazenados permanecem intactos.

Brokers de backup: Enquanto há broker primário, se conexão perdida, nós conectados alternam automaticamente para outro broker. Relacionamento geralmente configurado via aplicação (ex.: SCADA) que suporta esta feature.

Clustering: Típico para aplicações que não toleram perda de dados. Vários brokers MQTT em cluster, todos cientes uns dos outros, compartilham mensagens. Quando conectividade perdida, publishers e subscribers roteiam dados a outro broker sem perdas.

Bridging: Comum para aplicação empresarial usar dados de todas as plantas. Um broker publica ou faz bridge de parte ou todo seu namespace para outro broker. Broker da planta faz bridge para broker empresarial. Tópicos publicados e estrutura de namespace podem ser definidos. Limita dados publicados e dá contexto ao broker receptor.

Publicar todos dados como estão com asterisco (*) sem definir estrutura é mais simples, mas pode resultar em dados desnecessários e confusos. Para dar contexto, tópico pode ser adicionado ao início do namespace publicado. Ex.: Empresa/Planta adicionado a Área/+/Célula resulta em Empresa/Planta/Área/+/Célula enviado ao broker empresarial. Dados de nível Célula de todas Linhas disponíveis (note uso do curinga +).

Todos cenários implantáveis. SCADA pode usar store-and-forward para cluster MQTT. Poderia haver clusters primário e backup, mas adicionaria complexidade desnecessária. Finalmente, cluster da planta faz bridge para cluster empresarial maximizando integridade dos dados. Ótimo para analytics empresarial e machine learning, que requerem grandes volumes de dados de qualidade.

Segurança

Principal preocupação ao enviar/receber dados de manufatura pela internet: cibersegurança. Embora única forma verdadeiramente segura seja air gap, isso impede transformação digital. Benefício-chave do MQTT: segurança. Enquanto outros protocolos exigem abertura de portas de rede, MQTT só requer conexão de saída ao broker. Plantas não precisam abrir portas de entrada, muito atraente para TI.

Considerações Futuras

Em artigos futuros, explorarei aplicações comuns com MQTT. Embora protocolo seja plug-and-play, haverá interesse em detalhes técnicos. Líderes de negócio devem considerar como MQTT afetará esforços atuais de transformação digital. Líderes de engenharia definitivamente quererão saber impacto do MQTT.

Em suma, MQTT não deve ser considerado substituto da arquitetura existente. Alinhado com requisitos Indústria 4.0, aproveita o que já existe. Continuará havendo necessidade de OPC UA e outros protocolos, mais verbosos para aplicações de controle. Porém, para agregar grandes volumes de dados, MQTT é excelente escolha.