Como criar lógica de CLP para manutenção preditiva para reduzir o combate a incêndios reativo

A lógica de CLP para manutenção preditiva desloca os diagnósticos da detecção binária de falhas para a análise de tendências analógicas. Ao monitorar o desvio, a variância, o atraso de resposta e o comportamento de erro PID dentro da camada de controle, os engenheiros podem gerar avisos de manutenção antecipados antes que ocorram paradas críticas, reduzindo o tempo de inatividade não planejado e as chamadas fora do horário de expediente que geralmente ocorrem.

A manutenção reativa é frequentemente descrita como um problema de estratégia de ativos. Na prática, é também um problema de carga de trabalho de controles. Quando os diagnósticos reagem apenas após um limite rígido, falha de prova ou condição de desligamento, o sistema de controle torna-se um anunciador de danos em vez de um instrumento para intervenção precoce.

Durante o benchmarking interno de cenários de controle de bombas no OLLA Lab, uma média móvel de 10 segundos aplicada a uma variável de controle PID simulada identificou a aderência (stiction) do atuador 42 minutos de simulação antes que uma falha de estado final discreta fosse acionada. Metodologia: n=12 execuções de degradação de válvula de bomba simulada; tarefa definida como detectar o aumento do atrito do atuador antes do estado de falha discreta; o comparador de linha de base foi um degrau de falha rígida padrão usando apenas prova discreta; observado durante uma sessão de simulação delimitada por execução. Isso sustenta um ponto restrito: a lógica de tendência analógica pode criar janelas de aviso mais precoces do que a lógica de falha discreta em uma simulação controlada. Isso não sustenta uma afirmação universal de tempo de campo em todos os ativos, malhas ou programas de manutenção.

A literatura mais ampla sobre trabalho e operações aponta na mesma direção, com o escopo adequado. Relatórios de vagas na manufatura e lacunas de habilidades da Deloitte e do BLS indicam uma tensão persistente nos mercados de trabalho técnico, enquanto discussões do setor alinhadas à ISA vinculam consistentemente o tempo de inatividade não planejado e a intervenção fora do horário comercial à pressão de retenção para equipes técnicas experientes. Isso não prova um modelo de esgotamento de causa única. Sugere, no entanto, que o tratamento reativo de falhas não é um padrão inofensivo. É caro, disruptivo e geralmente chega em um horário inconveniente.

A diferença técnica é a detecção de estado binário versus a detecção de degradação analógica.

A lógica de CLP reativa espera que uma condição se torne inequivocamente ruim. A lógica preditiva avalia se o comportamento do processo está tendendo à falha antes que a falha rígida ocorra. Em termos de tipos de dados, a mudança é frequentemente de intertravamentos baseados principalmente em BOOL para uma combinação de valores BOOL, REAL, TIME e estatísticos derivados.

Uma distinção concisa ajuda:

- A lógica reativa pergunta: A condição de falha aconteceu? - A lógica preditiva pergunta: A assinatura do processo está se movendo em direção à falha?

Essa distinção é importante porque a maioria das degradações mecânicas não nasce como um evento discreto. Ela aparece primeiro como desvio, ruído, atraso, saturação, esforço excessivo de correção ou recuperação instável. O equipamento geralmente "sussurra" antes de "tropeçar".

Os limites da segurança discreta

A lógica de falha discreta continua sendo necessária. Ela não é a vilã aqui. Paradas rígidas, permissivos, feedbacks de prova, botões de emergência e intertravamentos de desligamento são essenciais para proteção e resposta determinística.

A limitação é mais restrita: a lógica discreta geralmente chega tarde para o diagnóstico de manutenção.

Exemplos são familiares:

• Uma chave de limite de fechamento de válvula nunca prova dentro do tempo limite.
• Uma sobrecarga de bomba desarma após a corrente subir além do limite.
• Uma boia de nível muito alto desarma apenas após o tanque já estar em excursão.
• Uma chave de velocidade zero de transportador falha apenas após o movimento já ter sido perdido.

Estes são eventos de proteção válidos. Eles são instrumentos de aviso prévio pobres. No momento em que uma falha discreta confirma a falha, o processo já absorveu estresse, a produção já foi interrompida, ou ambos.

A mudança analógica preditiva

A lógica preditiva usa sinais contínuos e tendências derivadas para detectar comportamentos anormais mais cedo.

Entradas preditivas comuns incluem:

• Feedback de posição de 4–20 mA
• Corrente do motor
• Sinais de pressão, vazão, nível ou temperatura
• Tempo de curso da válvula
• Magnitude do erro PID ao longo do tempo
• Duração da saturação da variável de controle
• Atraso do comando para o feedback

Na prática, a lógica de CLP para manutenção preditiva geralmente combina:

• médias móveis para suavizar o ruído,
• cálculos de taxa de variação para detectar a velocidade do desvio,
• bandas de desvio para comparar o comportamento atual com a linha de base,
• temporizadores para garantir a persistência antes de alarmar,
• comparadores para separar o aviso do desarme,
• diagnósticos PID para inferir resistência mecânica ou instabilidade do processo.

Isso não é misticismo de IA. É interpretação disciplinada de sinais dentro da camada de controle.

As assinaturas de degradação analógica são importantes porque o desgaste físico geralmente aparece no software como uma mudança no comportamento do sinal antes de aparecer como uma falha rígida.

Esse é o significado operacional dos diagnósticos baseados em software neste artigo: usar funções matemáticas de CLP e rastreamento de erro PID para acionar avisos de manutenção com base em assinaturas de degradação mecânica.

Três assinaturas de degradação comuns

1. Desvio da linha de base (drift) Um sensor que deveria ler 4,0 mA no zero físico começa a ler 4,2 mA ou 4,3 mA sob a mesma condição. Isso pode indicar desvio de calibração, incrustação, acúmulo ou erro de referência.
2. Aumento da variância (ruído) Um valor analógico anteriormente estável começa a mostrar micro-picos erráticos ou bandas de oscilação alargadas. Isso pode indicar cavitação, desgaste de rolamento, fiação solta, interferência elétrica ou hidráulica de processo instável.
3. Resposta atrasada (lentidão) O tempo decorrido entre a emissão do comando e a resposta medida aumenta ao longo de ciclos repetidos. Isso geralmente aponta para atrito do atuador, válvulas presas, arrasto mecânico ou fraqueza pneumática.

O ponto importante não é apenas que o sinal mudou. É que o padrão mudou de uma forma que mapeia para uma degradação física plausível.

Por que o desvio importa mais do que muitas equipes admitem

O desvio é frequentemente descartado até que cruze um limite de calibração. Essa é uma visão administrativa organizada, nem sempre útil operacionalmente.

Um pequeno desvio na linha de base pode produzir:

• falsa confiança na posição real do processo,
• esforço desnecessário de correção PID,
• resposta de alarme atrasada,
• desarmes incômodos causados por comparadores a jusante mais rígidos,
• perda oculta de margem de controle.

Uma malha pode permanecer "em funcionamento" enquanto se torna progressivamente menos confiável.

### Exemplo: um sinal de vazão em degradação

Considere uma malha de recirculação de bomba com uma banda de vazão esperada estável sob condições operacionais fixas.

Um padrão de lógica preditiva pode procurar por:

• vazão média móvel abaixo da linha de base histórica,
• variância crescente em janela curta,
• aumento do tempo para estabilizar após a partida da bomba,
• excursões repetidas da saída PID acima da faixa normal de correção.

Qualquer sinal isolado pode ser ambíguo. Juntos, eles formam uma assinatura de degradação mais defensável. Bons diagnósticos geralmente vêm da correlação, não de uma única tag.

As malhas PID não são apenas dispositivos de controle. Elas também são testemunhas diagnósticas.

Uma malha bem instrumentada registra o quanto o controlador deve trabalhar para manter o setpoint. Se esse esforço aumenta com o tempo enquanto a demanda do processo permanece comparável, o sistema físico pode estar se degradando.

Monitoramento de windup integral e esforço de correção

A ação integral acumula erro ao longo do tempo para eliminar o offset. Se a malha agora requer materialmente mais contribuição integral do que exigia sob condições operacionais semelhantes, algo no caminho do processo pode ter mudado.

Exemplos incluem:

• aumento do atrito da gaxeta da válvula,
• incrustação de superfícies de transferência de calor,
• declínio da eficiência da bomba,
• amortecedores tornando-se pegajosos,
• desvio de viés do instrumento.

Um padrão de diagnóstico prático é monitorar a tendência de:

• setpoint,
• variável de processo,
• variável de controle,
• termo integral acumulado ou proxy de correção equivalente,
• tempo na banda após perturbação.

Se a malha precisa de 20% a mais de esforço corretivo este mês para atingir o mesmo envelope de resposta, o controlador pode estar relatando uma história mecânica, quer a manutenção já tenha ouvido ou não.

Alarmes de saturação de CV

A saturação da Variável de Controle (CV) é um dos indicadores precoces mais claros de problemas ocultos.

Se a saída PID permanecer em ou perto de 100% ou 0% por mais tempo do que o ajuste normal e as condições do processo justificam, a malha pode estar compensando por:

• vazão restrita,
• limites de curso do atuador,
• equipamento subdimensionado ou degradado,
• viés do sensor,
• perturbação do processo além do envelope esperado.

Um degrau de aviso delimitado pode ser escrito para sinalizar a saturação sustentada antes que ocorra um desarme do processo.

Elementos lógicos típicos incluem:

• comparador para CV > limite superior,
• temporizador de atraso (on-delay) para persistência,
• permissivo para excluir transiente de partida,
• verificação opcional de que o erro de PV permanece elevado,
• bit de aviso de manutenção em vez de bit de desligamento.

Essa última distinção é importante. A lógica de aviso e a lógica de proteção não devem ser fundidas casualmente. Uma é diagnóstica. A outra é autoritativa.

### Um exemplo compacto: lógica de taxa de variação e média móvel

Abaixo está uma ilustração simples de como a lógica preditiva pode ser implementada como uma camada matemática antes do alarme.

( Intervalo de amostragem assumido como constante ) PV_Filtrada := (PV_0 + PV_1 + PV_2 + PV_3 + PV_4) / 5.0;

ROC := (PV_Filtrada - PV_Filtrada_Anterior) / Tempo_Amostragem_Segundos;

Proxy_Variancia := ABS(PV_Bruta - PV_Filtrada);

IF Proxy_Variancia > Limite_Variancia THEN Temporizador_Ruido := Temporizador_Ruido + Tempo_Amostragem_Segundos; ELSE Temporizador_Ruido := 0.0; END_IF;

IF (Temporizador_Ruido >= 10.0) AND (CV > 85.0) AND (ABS(SP - PV_Filtrada) > Limite_Erro) THEN Aviso_Maint_Preditiva := TRUE; END_IF;

PV_Filtrada_Anterior := PV_Filtrada;

Isso é intencionalmente simples. Implementações reais devem levar em conta o tempo de varredura (scan), escalonamento, supressão de partida, status de modo, desvios de manutenção e contexto do estado do processo.

Um fluxo de trabalho de lógica preditiva defensável começa com o comportamento de degradação observável, não com um rótulo "preditivo" genérico.

Construa a lógica nesta ordem:

Exemplo: aderência da válvula, cavitação da bomba, incrustação do sensor, resposta lenta do atuador.

Exemplo: aumento da variância, desvio da linha de base, aumento do tempo de curso, saturação persistente da CV.

Exemplo: média móvel, banda morta, taxa de variação, persistência do temporizador, desvio da linha de base.

1. Defina o modo de falha
2. Identifique a assinatura visível por software mais precoce
3. Escolha o tratamento de sinal correto
4. Separe o aviso do desarme Os avisos de manutenção preditiva geralmente devem notificar e registrar, não desligar diretamente, a menos que a condição também viole um limite de proteção.
5. Defina uma definição operacional de "correto" "Correto" significa que o aviso aparece cedo o suficiente, sob as condições certas, com comportamento de falso positivo aceitável, e redefine apenas quando o processo retorna a um estado normal verificado.
6. Valide contra cenários anormais Teste a partida, rajadas de ruído, modo manual, perda de sensor e estados de desvio de manutenção.

É aqui que o "Simulation-Ready" precisa de uma definição precisa. No uso da Ampergon Vallis, um engenheiro "Simulation-Ready" é aquele que pode provar, observar, diagnosticar e endurecer a lógica de controle contra o comportamento realista do processo antes que ele chegue a um processo real. Não alguém que pode apenas colocar contatos e bobinas na ordem correta.

Construa evidências de engenharia, não uma galeria de capturas de tela

Se você deseja demonstrar habilidade diagnóstica real, documente um corpo compacto de evidências de engenharia:

Descreva a degradação introduzida: desvio, ruído, aderência, atraso, saturação ou viés.

Explique o que mudou após o primeiro teste: limites, filtros, temporização, histerese ou intertravamentos.

1. Descrição do sistema Defina a unidade de processo, objetivo de controle, E/S e envelope operacional.
2. Definição operacional de "correto" Declare exatamente o que a lógica deve detectar, quão cedo, sob quais condições e com quais regras de supressão.
3. Lógica ladder e estado do equipamento simulado Mostre a lógica de degraus e o comportamento do processo correspondente na simulação.
4. O caso de falha injetada
5. A revisão feita
6. Lições aprendidas Registre falsos positivos, detecções perdidas, dependências do estado do processo e implicações de comissionamento.

Essa estrutura é mais credível do que uma pasta cheia de capturas de tela polidas.

Um ambiente de simulação com risco contido é útil porque muitos comportamentos de manutenção preditiva não podem ser ensaiados com segurança em equipamentos reais.

Geralmente, você não pode pedir a um engenheiro júnior que injete desvio analógico em uma malha de produção, force uma válvula a uma aderência progressiva ou desestabilize deliberadamente um skid de processo apenas para ver se um aviso de manutenção funciona. O exercício derrotaria seu próprio propósito.

É aqui que o OLLA Lab se torna operacionalmente útil. O OLLA Lab é um simulador de lógica ladder e gêmeo digital interativo baseado na web que permite aos engenheiros construir lógica ladder, executar simulação, inspecionar E/S e variáveis, e validar a lógica contra o comportamento realista da máquina em um ambiente contido. No contexto delimitado deste artigo, seu valor é específico: ele fornece um local para ensaiar a lógica matemática preditiva contra padrões de degradação simulados antes que qualquer decisão de implementação exista.

Injetando desvio, ruído e assinaturas de desgaste

Dentro de um fluxo de trabalho de simulação, os engenheiros podem praticar:

• alterar linhas de base de entrada analógica para imitar o desvio do sensor,
• adicionar variância ou oscilação para imitar instrumentação ruidosa,
• aumentar o atraso de comando para feedback para imitar o desgaste do atuador,
• observar o comportamento da saída PID sob resistência crescente do processo,
• testar se os limites de aviso são acionados antes de falhas rígidas.

O principal benefício não é a conveniência. É a repetibilidade.

Um exercício útil de manutenção preditiva no OLLA Lab incluiria:

• um cenário de bomba, válvula ou tanque,
• tags analógicas visíveis no painel de variáveis,
• ferramentas PID ou comparadores quando relevante,
• uma sequência de degradação definida,
• comportamento de aviso esperado,
• uma etapa de verificação contra o estado do equipamento simulado.

Essa última etapa é importante. A lógica não deve ser validada apenas contra mudanças de tag. Ela também deve ser verificada contra a consequência virtual do processo. Um aviso que parece elegante na visualização de degraus, mas chega depois que o tanque virtual transborda, não é um aviso antecipado.

Validando a lógica contra gêmeos digitais

A validação de gêmeo digital deve ser definida de forma restrita aqui: testar se a lógica de controle produz o comportamento esperado quando aplicada a um modelo virtual realista de equipamento ou estado de processo.

Isso significa observar se:

• o aviso ocorre antes que o processo cruze um limite prejudicial,
• a lógica permanece estável sob ruído operacional normal,
• os modos de partida e manual não geram alarmes incômodos,
• os desvios de manutenção se comportam conforme o pretendido,
• a resposta do equipamento simulado corresponde à interpretação do estado da ladder.

Isso não é o mesmo que certificação formal de segurança, verificação SIL ou aceitação no local. É ensaio e validação em um ambiente delimitado.

Um fluxo de trabalho prático do OLLA Lab para diagnósticos preditivos

Uma sequência de laboratório disciplinada poderia ser assim:

Essa ordem reflete o julgamento de comissionamento: estabelecer o normal, injetar o anormal, verificar a resposta, revisar, repetir.

1. Construa a lógica ladder base para a unidade de processo.
2. Execute o cenário sob condições nominais e registre o comportamento analógico da linha de base.
3. Adicione um bloco de média móvel ou taxa de variação.
4. Introduza uma assinatura de degradação de cada vez.
5. Ajuste os limites de aviso e temporizadores de persistência.
6. Compare os alarmes do estado da ladder com o comportamento do equipamento simulado.
7. Revise a lógica para reduzir falsos positivos.
8. Execute novamente o cenário com um perfil de perturbação diferente.

Os padrões e a literatura não dizem "use exatamente este degrau". Eles apoiam a lógica de engenharia subjacente: detectar comportamento anormal precocemente, validar o comportamento de controle antes da implementação sempre que possível e tratar os diagnósticos como parte da confiabilidade do sistema, em vez de uma reflexão tardia.

A fundamentação relevante inclui:

- IEC 61508: enfatiza a disciplina do ciclo de vida, integridade sistemática e rigor de validação para sistemas relacionados à segurança elétricos/eletrônicos/programáveis. Embora a lógica de manutenção preditiva não seja automaticamente uma função de segurança, a mentalidade de validação do padrão permanece instrutiva. - Orientação da exida e prática de segurança funcional: distinguem repetidamente entre cobertura de diagnóstico, comportamento de prova e resposta validada do sistema. - IFAC e literatura de controle de processo: apoiam o uso de avaliação de desempenho de controle, comportamento de malha e assinaturas de atuador ou sensor como indicadores de degradação. - Literatura de sensores e monitoramento de condição: apoia a análise de tendências, análise de variância e detecção de anomalias em sinais industriais para fins de manutenção. - Estudos da força de trabalho manufatureira da Deloitte e BLS: apoiam o contexto mais amplo de que a pressão de pessoal técnico e a exposição ao tempo de inatividade permanecem preocupações operacionais sérias, embora não devam ser reduzidas a uma única estatística de manchete.

A conclusão prática é modesta e defensável: a lógica de CLP para manutenção preditiva é mais forte quando traduz a degradação física em comportamento de sinal observável, e então valida a lógica de aviso contra a resposta realista do processo antes da implementação.

Uma boa implementação inclui limites claros entre diagnósticos, ação de manutenção e proteção.

Use esta lista de verificação:

• modo de falha definido
• envelope operacional normal conhecido
• escalonamento e filtragem de sinal
• temporização de persistência
• supressão de partida e modo
• separação entre aviso e desarme
• texto de alarme voltado para o operador
• caminho de registro de manutenção
• validação estilo simulação ou FAT
• histórico de revisão após testes anormais

Se um desses itens estiver faltando, a lógica ainda pode rodar, mas é menos provável que sobreviva ao contato com um processo real.

- U.S. Bureau of Labor Statistics (BLS) – Occupational Outlook Handbook - Deloitte Insights – 2025 Manufacturing Industry Outlook - The Manufacturing Institute & Deloitte – Talent and workforce research - European Commission – Industry 5.0 - IEC 61131-3 standard overview (IEC) - IEC 61508 functional safety standard overview (IEC) - ISO 10218 industrial robot safety standard overview (ISO) - International Federation of Robotics – World Robotics reports - IFAC-PapersOnLine journal homepage - Sensors journal – industrial digital twin and monitoring research