Toda planta que roda com CLP já tem o dado de produção dentro do controlador: início e fim de ciclo, contagem de peças, estado de cada equipamento, alarme ativo. O problema não costuma ser gerar o dado, é tirar esse dado de dentro do CLP sem interferir na lógica que já está rodando a máquina, e sem exigir uma parada de linha que a maioria das plantas de processo contínuo (turno de alimentício e frigorífico incluído) simplesmente não tem disponível.
Por que alterar a lógica do CLP é o caminho errado
A forma mais direta, e mais arriscada, de tirar dado de um CLP é editar o programa que já está rodando para adicionar rotinas de comunicação ou registradores extras. Isso expõe a máquina a regressão: qualquer alteração na lógica de controle, mesmo pequena, tem potencial de afetar o comportamento da máquina em produção, e validar essa alteração com segurança normalmente exige parada da linha, algo que planta de processo contínuo evita ao máximo.
O caminho tecnicamente correto é ler o dado pelo protocolo de comunicação nativo do próprio controlador, sem tocar na lógica de controle. Um controlador Allen-Bradley/Rockwell expõe seus dados via Ethernet/IP; um controlador Siemens via PROFINET; equipamentos mais antigos ou de outros fabricantes, via Modbus serial ou TCP. Em todos os casos, a leitura acontece de fora, como um cliente adicional consultando os registradores que o CLP já disponibiliza, sem escrever nada de volta na lógica de produção. O CLP continua rodando exatamente o programa que já rodava; o sistema de coleta apenas observa.
O que dá para extrair sem tocar na máquina
Com esse tipo de leitura, os indicadores que alimentam OEE (Overall Equipment Effectiveness) e controle de produção passam a ser calculados a partir de dado real do controlador, não de apontamento manual de operador:
- Tempo de máquina parada, e a causa associada a cada parada
- Produção por máquina e por hora, direto da contagem que o CLP já mantém
- Início e fim de cada processo produtivo
- Eficiência de cada máquina ao longo do turno
- Rastreabilidade do processo, ciclo a ciclo
- Alarmes, status de equipamento e controle de turno, com alerta automático por e-mail quando um indicador sai da faixa esperada
Onde esse tipo de leitura já foi aplicado
A Sadhas desenvolveu supervisórios que leem diretamente de controladores em produção, sem alterar a lógica de máquina, em plantas de alimentício e frigorífico. Na Ferreira International, em Três Rios/RJ, o supervisório da linha Jack Link’s cobre o retrofit de 11 estufas de cozimento, lendo de controlador CompactLogix 1769-L16ER via protocolo ABCIP, com IHM PanelView Plus 7 e histórico de produção em SQL Express. Na JBS/Seara de Dourados/MS, o supervisório da linha de apresuntado integra 9 tanques de cozimento e 9 de resfriamento a partir de um CPU Siemens S7-1500 com ET200SP, usando protocolo MPROT, com IHM SIMATIC KTP900 Basic e supervisório Elipse E3. Em ambos os casos, a leitura de dado convive com a lógica de produção original do CLP, sem substituí-la.
A plataforma própria de coleta da Sadhas, chamada CID (Coleta Inteligente de Dados), é construída sobre esse mesmo princípio: um gateway que fala LoRa, Wi-Fi, Ethernet/IP, Modbus e serial ao mesmo tempo, conectando diretamente ao controlador de cada máquina, com servidor próprio e dashboard web e mobile para acompanhar o resultado.
Rede industrial e supervisório entram na mesma arquitetura
A leitura por protocolo nativo depende de a rede industrial da planta estar mapeada e acessível: Ethernet/IP, PROFINET e Modbus convivem com frequência na mesma fábrica, cada um ligado a controladores de fabricantes diferentes, e o sistema de coleta precisa falar todos eles ao mesmo tempo, sem exigir que a planta padronize numa única rede antes de começar. É por isso que o gateway de coleta funciona como ponto único de tradução entre protocolos: ele lê cada controlador na linguagem nativa dele e entrega o dado consolidado para o supervisório ou para o dashboard, sem que a planta precise trocar equipamento só para ser lida.
O supervisório, construído em plataforma como o Elipse E3, é a camada que transforma o dado bruto lido do CLP em tela de acompanhamento, histórico de produção e alarme visível para o operador. O histórico gravado em banco de dados, como SQL Express, é o que permite depois cruzar tempo de parada, causa de parada e produção por turno ao longo de semanas ou meses, não só olhar o estado instantâneo da máquina.
Segmentos onde esse tipo de coleta é mais crítico
Plantas de processo contínuo, como frigorífico e alimentício, têm janela de parada programada limitada, geralmente concentrada em manutenção preventiva já agendada. Nesses segmentos, qualquer projeto de coleta de dado que dependa de parar a linha para ser implantado compete diretamente com produção, o que costuma adiar o projeto indefinidamente. A leitura por protocolo nativo, que não exige parada, é o que viabiliza implantar coleta de dado em planta que já está rodando em regime contínuo, sem esperar a próxima grande parada de manutenção para começar.
O papel da engenharia de campo na implantação
Ler dado de um controlador em produção, sem interferir na lógica de controle, exige mapear primeiro a topologia de rede da planta: quais controladores existem, em qual protocolo cada um fala, e quais registradores ou blocos de dados dentro de cada CLP contêm a informação de produção relevante. Esse levantamento é trabalho de engenharia de campo, geralmente feito com o controlador já rodando, sem necessidade de interromper a produção para inspecionar a rede. Só depois desse mapeamento é que o gateway de coleta é configurado para ler exatamente os pontos de dado identificados, e não uma varredura genérica de tudo o que o controlador expõe, o que reduziria tráfego desnecessário na rede industrial e o risco de sobrecarregar uma rede que já está dedicada a rodar a produção em tempo real.
Comissionamento sem impacto na produção
A etapa de comissionamento de um sistema de coleta que lê por protocolo nativo também não exige parada de linha: o gateway é conectado à rede industrial existente, a leitura é validada comparando o valor lido com o valor observado diretamente na IHM da máquina, e o histórico começa a ser gravado a partir desse ponto. Se a leitura de um ponto específico não confere, o ajuste acontece na configuração do gateway, não na lógica do CLP, o que mantém a máquina fora de qualquer risco de regressão durante todo o processo de implantação, do levantamento inicial até a entrega do dashboard funcionando.
O que perguntar antes de contratar um sistema de coleta
Para quem avalia proposta de coleta de dado de chão de fábrica, a pergunta que separa uma solução segura de uma arriscada é: a leitura acontece por protocolo nativo do controlador, sem alteração da lógica de produção, ou o fornecedor precisa reprogramar o CLP para expor o dado? A primeira opção não exige parada de linha para ser implantada, nem coloca em risco a lógica que já está validada e rodando; a segunda, normalmente exige as duas coisas, e é por isso que costuma ficar parada na fila de projetos de uma planta que não tem folga de parada disponível.