MQTT, OPC UA ou comunicação direta com o PLC: como escolher o modelo de troca de dados num projeto industrial?

A escolha entre MQTT, OPC UA e a comunicação direta com o PLC deixou de ser uma decisão puramente técnica. Hoje, essa escolha afeta simultaneamente a arquitetura do sistema, o custo de arranque, o âmbito de responsabilidade dos fornecedores e o ritmo das aceitações. Na prática, a questão não é qual protocolo é “melhor”, mas qual modelo de troca de dados corresponde à função real do projeto: se é necessária uma integração simples de sinais de uma única máquina, a supervisão de uma linha, a troca de dados com sistemas de nível superior ou, eventualmente, um controlo distribuído que será desenvolvido ao longo dos próximos anos. Um erro nesta fase normalmente não se revela de imediato em laboratório, mas mais tarde: no arranque, na validação, na mudança de fornecedor do PLC ou quando a equipa de manutenção tenta reconstituir a causa de uma perturbação e descobre que os dados são inconsistentes, chegam com atraso ou não têm contexto.

Do ponto de vista do projeto, o mais perigoso é adotar um modelo de comunicação “por hábito”. A comunicação direta com o PLC pode ser tentadora, porque dá acesso rápido aos registos e muitas vezes encurta a primeira fase da implementação. No entanto, essa escolha liga facilmente a aplicação de nível superior a um controlador específico, ao endereçamento da memória e à forma de implementação do fabricante. Quando há mudança de versão do programa, migração de hardware ou ampliação da linha, o custo regressa sob a forma de alterações, testes de regressão e discussões sobre a responsabilidade pelos dados de processo. Por sua vez, o MQTT funciona bem onde é importante uma distribuição leve da informação e a separação entre emissores e recetores, mas exige uma definição consciente da semântica dos dados, da qualidade de entrega e das regras de manutenção do broker. O OPC UA é frequentemente escolhido como compromisso entre interoperabilidade e estrutura da informação, mas também não resolve os problemas por si só: se o modelo de dados for inadequado, uma comunicação formalmente correta continuará a conduzir a más decisões operacionais.

O critério prático para decidir é simples, embora muitas vezes seja ignorado: primeiro é preciso determinar se essa troca diz respeito a informação, controlo ou a uma função com impacto na segurança de funcionamento da máquina. Se o canal servir apenas para monitorização, reporte ou transmissão de receitas em modo controlado, é possível comparar soluções em termos de manutenção, escalabilidade e integração. Mas, se por esse mesmo caminho tiverem de passar comandos que influenciam o movimento, a sequência de funcionamento, os bloqueios ou o estado de prontidão do equipamento, o tema deixa imediatamente de ser apenas informático. Nesse caso, é necessário avaliar não só o atraso e a fiabilidade da transmissão, mas também a previsibilidade do comportamento em caso de perda de comunicação, após reinício do sistema, após alteração da versão do software e perante uma interpretação incorreta do estado por um sistema externo. É neste momento que o tema passa naturalmente para uma análise de risco aplicada às decisões de projeto e, por vezes, também para o domínio da proteção contra o arranque inesperado.

Um exemplo típico em unidades industriais costuma seguir o mesmo padrão: no início, o objetivo é apenas ler dados da máquina para visualização ou para um sistema de reporte, pelo que a equipa opta por uma ligação rápida diretamente ao PLC. Alguns meses depois, esse mesmo canal começa a servir para escrita de parâmetros, confirmação de alarmes e, mais tarde, também para comandos remotos de assistência. Formalmente, o sistema continua a “funcionar”, mas a arquitetura deixa de corresponder à responsabilidade real. Já não é claro que camada é a fonte de verdade para o estado da máquina, quem responde pela autorização das alterações e como demonstrar que a comunicação externa não cria uma via para um arranque não intencional. Neste ponto, surgem questões não apenas sobre o protocolo, mas também sobre a divisão de funções entre a camada de controlo, de supervisão e de segurança e, em cenários de comunicação direta com o PLC, sobre as consequências para a camada elétrica e para as ligações na máquina.

O significado normativo e de conformidade desta escolha surge, portanto, quando o modelo de troca de dados influencia o comportamento da máquina em estados normais e de perturbação. Nem toda a integração entra de imediato no âmbito dos requisitos relativos às funções de segurança, mas todas devem ser avaliadas quanto aos efeitos de falha, à perda de comunicação e à sequência incorreta de ações. Se, através de uma interface externa, for possível alterar o estado da máquina, libertar um bloqueio, retomar um ciclo ou contornar a lógica prevista localmente, então a decisão sobre a comunicação tem de ser ligada à análise de risco e, nos casos adequados, também aos requisitos relativos à prevenção do arranque inesperado. Por isso, este tema exige uma decisão desde já, na fase de pressupostos e de arquitetura, e não apenas no arranque. É precisamente nessa fase que ainda é possível definir critérios mensuráveis: quem é o responsável pelo modelo de dados, qual é o efeito admissível da perda de comunicação, quantos pontos de integração terão de ser mantidos após a mudança do PLC e como será demonstrado que a comunicação não transfere responsabilidades para fora do âmbito planeado do sistema.

Onde o custo ou o risco mais frequentemente aumentam

A maior parte dos problemas não resulta da escolha entre MQTT, OPC UA e comunicação direta com o PLC, mas sim da atribuição incorreta do papel dessa comunicação na arquitetura da máquina ou da instalação. O projeto começa a encarecer quando um canal previsto para troca de dados auxiliares passa a suportar decisões operacionais das quais dependem a continuidade do processo, o estado do equipamento ou o comportamento do operador. Na prática, isto significa que a equipa implementa uma solução aparentemente mais barata e mais rápida e, mais tarde, acrescenta soluções de contorno: sinais de hardware adicionais, bloqueios locais, exceções na lógica do controlador, mecanismos separados de confirmação e reposição do estado após perda de comunicação. São precisamente estas correções tardias que geram custo, atraso e conflito quanto à responsabilidade entre o integrador, o fornecedor de software e o utilizador final. O critério prático de avaliação é simples: é preciso determinar se, após a perda de comunicação, o sistema deve apenas “deixar de reportar” ou se pode entrar num estado perigoso, tecnologicamente incorreto ou oneroso do ponto de vista produtivo.

Nos modelos baseados em comunicação direta com o PLC, o risco aumenta normalmente quando a interface passa a depender de um fabricante específico, da versão do software e da estrutura de memória do controlador. Na fase de arranque, isso muitas vezes funciona bem, mas o custo torna-se evidente quando há substituição do controlador, modernização da linha ou integração de mais um sistema de supervisão. Cada alteração deste tipo exige novo mapeamento de dados, verificação de tipos, endereços, permissões e comportamento em caso de erro de transmissão. Do ponto de vista do proprietário do produto, isto é relevante, porque a manutenção deixa de ser previsível: a documentação perde rapidamente atualidade, o conhecimento fica do lado do executante e a responsabilidade pela correção dos dados torna-se difusa. Se a equipa não consegue indicar quem é o responsável pelo modelo de dados e qual é o procedimento para a sua alteração após uma atualização do PLC, então o custo da integração futura já está incorporado no projeto, mesmo que ainda não seja visível hoje.

No caso do MQTT e do OPC UA, o erro mais frequente é outro: parte-se do princípio de que a camada de comunicação, por si só, resolverá o problema da semântica dos dados e da fiabilidade das decisões. No entanto, o MQTT transporta bem eventos e telemetria, mas, sem uma definição cuidada dos tópicos, da qualidade de entrega, da retenção e da identificação da origem, é fácil chegar a uma situação em que o destinatário recebe dados formalmente corretos, mas inúteis ou atrasados em relação ao processo. Já o OPC UA organiza o modelo de informação e facilita a interoperabilidade, mas a sua implementação tende a ser subestimada quando os equipamentos não têm uma estrutura coerente de objetos, estados e métodos. Um exemplo prático surge nas receitas, na confirmação de lotes ou no reinício remoto do ciclo: se não estiver claramente definido qual das partes confirma a receção do comando, qual confirma a execução e qual apenas regista a operação, então, após o primeiro incidente, torna-se difícil demonstrar se o erro surgiu na camada aplicacional, na comunicação ou na lógica da máquina. Um bom critério de decisão aqui não é a “modernidade” do protocolo, mas sim saber se é possível descrever de forma inequívoca o estado, a origem do comando, as condições de validade e a forma de restabelecer o funcionamento após uma perturbação. No contexto do modelo de troca de dados na automação industrial, é precisamente isso que determina se a solução será sustentável na prática.

Uma fonte de custo à parte é a mistura entre requisitos de exploração e requisitos de segurança e conformidade. Se, através de MQTT, OPC UA ou acesso direto ao PLC, for possível influenciar o movimento da máquina, a libertação de bloqueios, a sequência de arranque ou parâmetros com relevância protetiva, então o tema deixa de ser exclusivamente informático. Neste ponto, a questão passa naturalmente para uma análise do impacto da comunicação na segurança de máquinas e linhas: é necessário avaliar não o protocolo em si, mas as consequências de um comando incorreto, da perda de atualidade dos dados, da alteração não autorizada de parâmetros e da inconsistência entre o estado local e o estado externo. Nos sistemas de atuação, incluindo os hidráulicos, a decisão sobre a comunicação pode influenciar a forma de execução das funções de paragem, alívio, bloqueio de movimento e regresso seguro ao funcionamento, pelo que pode estar ligada aos requisitos de projeto aplicados na avaliação da conformidade. Se a interface externa começar a interferir com funções de proteção ou com comportamentos que o operador perceciona como parte da proteção, então isso deve ser tratado como um elemento da arquitetura de segurança, e não como um simples complemento conveniente de integração.

Do ponto de vista da gestão do projeto, a decisão mais segura é aquela que pode ser defendida não só tecnicamente, mas também do ponto de vista organizacional. Por isso, antes de escolher o modelo de troca de dados, vale a pena definir alguns critérios mensuráveis: o tempo necessário para restabelecer o funcionamento correto após perda de comunicação, o número de pontos em que é necessário manter o mapeamento de dados, a forma de versionamento do modelo de informação, o âmbito dos testes de regressão após alteração do PLC e a prova de que a comunicação externa não contorna os mecanismos locais de proteção. Quando as respostas a estas questões são pouco claras, o projeto entra normalmente numa área em que a própria decisão sobre a comunicação já deve ser sujeita a uma avaliação de risco mais formal e, em parte das aplicações, também coordenada com os requisitos de projeto relativos aos elementos de atuação e aos meios de bloqueio. É neste momento que a escolha entre MQTT, OPC UA e comunicação direta deixa de ser uma questão de preferência técnica e passa a ser uma decisão sobre custos de manutenção, limites de responsabilidade e robustez de toda a solução perante o erro.

Como abordar o tema na prática

Na prática, a escolha entre MQTT, OPC UA e comunicação direta com o PLC deve começar não pela tecnologia, mas pela pergunta: que efeito operacional a troca de dados deve produzir e quem assume a responsabilidade pelo seu resultado. Se os dados servem apenas para supervisão, reporte ou alimentação de sistemas de nível superior, a prioridade será a robustez da integração face a alterações e um modelo de informação claro. Se, pelo contrário, do outro lado surgirem comandos que influenciam o ciclo, as receitas, os estados de funcionamento ou as condições de arranque, a decisão deixa de ser apenas informática. Nesse momento, a forma de comunicação passa a afetar o limite de responsabilidades entre o integrador, o fabricante da máquina, a manutenção e o proprietário do processo. Isto tem consequências diretas no projeto: um âmbito diferente dos testes de aceitação, documentação de alterações diferente, uma escala distinta de regressão após a modificação do programa do controlador e um custo de manutenção diferente após a implementação.

Um bom critério de decisão é definir onde deve estar a fonte de verdade sobre o estado da máquina e a lógica de autorização de funcionamento. A comunicação direta com o PLC pode ser justificada quando contam a simplicidade do percurso de execução, o número reduzido de intermediários e a previsibilidade total do comportamento do lado do controlador. O preço a pagar é, normalmente, uma forte dependência da solução em relação a um programa PLC específico, a um endereço de dados e às práticas de um único fornecedor. O OPC UA é uma opção sensata quando o projeto exige um modelo de dados mais estável, melhor separação entre a camada aplicacional e o programa do controlador, e maior clareza na semântica dos sinais. O MQTT é especialmente adequado quando os dados têm de ser distribuídos por vários destinatários, para além de uma relação única entre sistema e controlador, e quando é aceitável um modelo de comunicação indireta. No entanto, esta não é uma escolha neutra: quanto mais camadas intermédias, brokers, tradutores e mapeamentos existirem, maior será a superfície de erro e mais difícil será demonstrar que uma alteração do lado da integração não compromete os pressupostos adotados para o controlo local.

Um erro típico de projeto consiste em a equipa escolher um modelo conveniente para a integração na fase de arranque e só mais tarde descobrir o custo de manutenção. Exemplo prático: o sistema de nível superior deve gravar receitas e comutar os modos de funcionamento de vários postos. Se isto for feito por escrita direta em áreas de memória do PLC, a solução será inicialmente rápida, mas qualquer alteração da estrutura de dados no controlador irá desencadear testes em ambos os lados da interface, e a responsabilidade pela consistência das receitas começará a diluir-se. Se o mesmo caso for baseado em objetos e estados claramente definidos do lado do OPC UA, torna-se mais fácil separar a alteração do programa da máquina da alteração no sistema de nível superior, mas será necessário manter o modelo de informação e o seu versionamento. Por sua vez, a utilização de MQTT neste cenário só faz sentido quando existe efetivamente necessidade de distribuir dados por vários sistemas e quando o controlo dos atrasos, a confirmação de entrega e a reposição do estado após perda de ligação tiverem sido descritos e verificados em testes. Caso contrário, a equipa adquire uma flexibilidade que não irá utilizar e fica com pontos adicionais de falha.

É também neste ponto que o tema passa naturalmente para uma análise prática do risco nas decisões de projeto. Se o canal de comunicação puder alterar o estado da máquina, desbloquear uma sequência, retomar o funcionamento após perda de ligação ou influenciar indiretamente os elementos atuadores, é necessário avaliar não só a fiabilidade da transmissão, mas também as consequências de um comando incorreto ou tardio. Em parte das aplicações, este tema já toca nos requisitos de proteção contra arranque inesperado, porque mesmo uma integração tecnicamente correta não pode criar uma via de contorno às medidas locais de bloqueio ou aos procedimentos de corte de energia. Neste âmbito, a escolha da comunicação deve ser coordenada com a arquitetura de controlo, a camada elétrica e as regras de alteração do software, e não tomada como uma decisão isolada de integração. Na perspetiva do gestor, isto traduz-se numa regra simples: o modelo de troca de dados só é adequado quando se consegue demonstrar quem aprova a alteração, como se repõe o estado seguro após uma falha e que KPI serão medidos após a implementação, por exemplo o tempo de reposição do funcionamento, o número de incidentes após alterações e o número de pontos que mantêm o mapeamento de dados.

O que ter em atenção na implementação

Na implementação, o maior risco não é a escolha em si entre MQTT, OPC UA e comunicação direta com o PLC, mas os pressupostos ocultos que a equipa adota sem validação formal. Na prática de projeto, as situações mais dispendiosas são aquelas em que o modelo de troca de dados é escolhido para demonstrar a funcionalidade, e não para o modo real de exploração, manutenção e responsabilidade pelas alterações. O MQTT é por vezes implementado com a premissa de uma simples transmissão de dados para sistemas de nível superior e, passados alguns meses, começa a transportar comandos operacionais. O OPC UA é escolhido como solução “universal”, mas sem definir que serviços, modelos de dados e mecanismos de permissões serão efetivamente utilizados. A comunicação direta com o PLC parece ser o caminho mais curto, até se verificar que cada novo destinatário dos dados exige um mapeamento próprio, testes de regressão e alinhamento com o fornecedor do controlador. Para o gestor, isto tem uma consequência simples: o custo da implementação não termina quando a ligação entra em funcionamento, mas prolonga-se por todo o ciclo de alterações, avarias e aceitações técnicas.

A pergunta decisiva mais importante não deve, portanto, ser “o que conseguimos pôr em funcionamento mais depressa”, mas sim “onde termina a responsabilidade pelo significado dos dados e pelos efeitos da sua utilização”. Se a comunicação servir apenas para observar o processo, os critérios de avaliação serão diferentes dos aplicáveis quando o mesmo canal tiver impacto em receitas, parâmetros de funcionamento, bloqueios ou sequências de controlo. Neste ponto, o tema passa naturalmente para uma análise prática do risco nas decisões de projeto: é necessário avaliar não só a probabilidade de perda de comunicação, mas também se um valor incorreto, uma atualização atrasada ou um mapeamento ambíguo de variável pode provocar um funcionamento incorreto da máquina ou da linha. Se a resposta for afirmativa, a arquitetura de comunicação deixa de ser apenas uma questão de integração. Passa a ser um elemento com impacto na função de controlo, na aceitação do sistema e na responsabilidade do integrador ao ligar subsistemas.

Na prática, isso vê-se bem num cenário simples: o sistema de supervisão deve ler estados de vários controladores e, depois de o projeto entrar em funcionamento, o utilizador pede ainda a alteração remota de definições. Na comunicação direta com o PLC, isto muitas vezes acaba na adição de mais registos, exceções e soluções de contorno dependentes de um fabricante específico. No MQTT, o problema costuma ser a perda de univocidade: a mensagem chega, mas sem um contexto bem definido o recetor não sabe se o valor é atual, se está confirmado e de que modo de funcionamento provém. No OPC UA, a armadilha não está no protocolo em si, mas na suposição demasiado otimista de que o modelo de informação do lado do equipamento corresponde ao que a aplicação de supervisão exige. Por isso, um critério prático de avaliação deve abranger três aspetos: quem é o responsável pela semântica dos dados, como se confirma a validade e a atualidade dos valores e como é o procedimento de alteração após a entrada em funcionamento. Se a equipa responder de forma genérica a qualquer uma destas perguntas, ou de modo dependente do fornecedor, isso significa que o custo das futuras modificações acabou de ser transferido para a fase de manutenção.

Outra armadilha é subestimar os efeitos físicos e de instalação. Em projetos em que a escolha do modelo de troca de dados influencia a localização de dispositivos intermédios, a alimentação adicional, o encaminhamento de cabos ou a segmentação da rede, o tema começa a tocar o projeto da camada elétrica e das ligações na máquina. Isto aplica-se sobretudo a soluções com gateways de comunicação adicionais, computadores industriais ou switches que, na documentação, parecem inofensivos, mas que no quadro elétrico significam espaço, arrefecimento, proteções, assistência e mais pontos de falha. Nessa altura, a decisão sobre a comunicação não pode ser separada do projeto de execução. A equipa deve ser capaz de indicar o que acontece após a perda de alimentação do dispositivo intermédio, como será restabelecido o estado da comunicação e se uma falha na camada de transmissão não criará uma imagem ambígua do estado da máquina para o operador ou para o sistema de supervisão.

A referência aos requisitos de conformidade só surge quando o canal de troca de dados afeta a função de controlo, o modo de utilização da máquina ou os limites de responsabilidade entre fornecedores. Nesse âmbito, não basta afirmar que o protocolo é “industrial” ou amplamente utilizado. É necessário demonstrar que a arquitetura adotada foi avaliada no contexto de estados de falha previsíveis, alterações de exploração e interfaces entre subsistemas, o que na prática conduz a uma avaliação metódica do risco de acordo com o âmbito do projeto adotado. Se o sistema for montado a partir de módulos prontos, controladores e camadas de comunicação de diferentes entidades, aumenta também a importância da atribuição formal da responsabilidade do integrador. Normalmente, é neste momento que vale a pena parar o projeto e verificar não só o esquema de troca de dados, mas também os limites das modificações após a aceitação, as regras de validação das alterações e os KPI de manutenção: tempo de restabelecimento da comunicação, número de incidentes após atualizações e número de interfaces que exigem mapeamento manual.