Como ajustar um loop PID para um setpoint móvel: O desafio da onda dente de serra

Ajustar um loop PID para um setpoint móvel é um problema de acompanhamento de comando (command-following), não um exercício padrão de rejeição de distúrbios. Uma forma de onda dente de serra expõe tanto o erro de rastreamento de rampa em regime permanente quanto a fraqueza na recuperação transitória na borda de reinicialização, tornando-a um teste de simulação útil para equilíbrio de ganho, controle de windup e restrição derivativa.

Um equívoco comum é que um loop bem ajustado para um teste de degrau está, portanto, bem ajustado para qualquer perfil de setpoint. Isso não é verdade. Um loop que parece aceitável em um pulso estático ainda pode apresentar um atraso significativo quando o alvo se move continuamente, o que é exatamente o que acontece em rampas de batelada, movimento coordenado, controle de tensão e alguns perfis térmicos.

Em testes internos do OLLA Lab, loops PID ajustados apenas para mudanças de setpoint estáticas apresentaram um erro de rastreamento materialmente maior quando acionados por um comando dente de serra repetitivo do que quando avaliados apenas na recuperação simples por degrau [Metodologia: 500 execuções de loop simuladas em exercícios predefinidos de acompanhamento de comando, comparador de linha de base = fluxo de trabalho de ajuste orientado a degrau, janela de tempo = Q1 2026]. Este benchmark interno apoia um ponto restrito: o ajuste apenas por degrau pode ignorar fraquezas no acompanhamento de comandos. Ele não estabelece uma taxa de falha industrial universal.

É aqui que um ambiente de simulação se torna operacionalmente útil. "Pronto para Simulação", no sentido delimitado da Ampergon Vallis, significa que um engenheiro pode provar, observar, diagnosticar e fortalecer a lógica de controle contra o comportamento real do processo antes que ele chegue a um processo real. A sintaxe não é a parte difícil. A parte difícil é o que a sintaxe faz quando a planta para de ser "polida".

Os métodos de ajuste estáticos falham em setpoints móveis porque geralmente são otimizados para rejeição de distúrbios em torno de um alvo operacional fixo, não para rastreamento de trajetória contínua. Essa distinção importa mais do que muitos fluxos de trabalho de treinamento admitem.

Em termos de controle de processo clássico, esta é a diferença entre controle regulatório e controle servo. O controle regulatório pergunta se o controlador consegue manter um setpoint contra distúrbios. O controle servo pergunta se o controlador consegue seguir uma mudança comandada no setpoint ao longo do tempo. A literatura de controle orientada pela ISA trata esses objetivos como relacionados, porém distintos, e as compensações de ajuste não são idênticas.

Um setpoint móvel cria um erro persistente, a menos que o controlador e o processo juntos consigam gerar ação corretiva suficiente para corresponder à taxa de mudança comandada. Apenas com ação proporcional, a variável de processo (PV) geralmente fica atrás do setpoint por um desvio mais ou menos estável durante a rampa. Isso é frequentemente descrito como erro de velocidade ou atraso de rastreamento (tracking lag).

Esse atraso não é uma questão cosmética. Em um processo real, pode significar:

• um perfil de batelada térmica que nunca atinge exatamente a trajetória pretendida,
• um loop de nível ou vazão que segue o tempo da receita com atraso,
• um loop de tensão ou posição que segue comandos com atraso visível,
• ou uma sequência coordenada cuja lógica a jusante assume que o processo está em um ponto que ainda não alcançou.

Um teste de pulso (bump test) ainda é útil. Ele apenas não conta a história toda. A resposta ao degrau diz como um loop reage a uma mudança repentina; ela não diz totalmente como o loop se comporta quando o alvo continua se movendo e depois reinicia bruscamente. Modo de falha diferente, evidência diferente.

Uma forma de onda dente de serra revela duas fraquezas diferentes em um único teste repetitivo: deficiência no rastreamento de rampa e comportamento de recuperação na borda de reinicialização. É por isso que é mais diagnóstico do que um único degrau quando o problema real é o acompanhamento de comando.

Matematicamente, um dente de serra combina:

• uma rampa linear ascendente, onde o setpoint muda continuamente em uma inclinação fixa, e
• uma queda descontínua, onde o setpoint reinicia quase instantaneamente para seu valor inicial.

Essas duas fases estressam partes diferentes do loop. Convenientemente, elas fazem isso sem exigir uma grande matriz de testes.

As duas fases do rastreamento dente de serra

Esta fase testa se o loop consegue seguir um alvo móvel sem acumular atraso inaceitável. Se o ganho proporcional for muito baixo, a PV fica visivelmente atrás. Se a ação integral for muito agressiva ou mal restringida, o controlador pode criar esforço corretivo excessivo enquanto persegue a rampa.

• A rampa linear

Esta fase testa a recuperação transitória após uma reinicialização abrupta do setpoint. Se a ação derivativa for tomada sobre o erro em vez da medição, a borda de queda pode produzir um grande pico de controle, frequentemente descrito como derivative kick. Se a ação integral tiver sofrido windup durante a rampa, a queda pode ser seguida por overshoot, desenrolamento lento ou ambos.

• A queda descontínua

O valor do dente de serra é que ele expõe uma contradição da qual muitos loops não conseguem se esconder: o loop deve rastrear suavemente durante a rampa, mas permanecer estável e não violento na borda de reinicialização. Um controlador que parece aceitável em uma fase pode parecer imprudente na outra.

Um setpoint dente de serra pode ser arriscado em equipamentos físicos porque a borda de reinicialização pode exigir uma resposta abrupta do atuador que o sistema mecânico, o elemento final de controle ou o processo não deveriam experimentar durante o ajuste exploratório. A simulação não é um luxo aqui; é frequentemente o único primeiro local sensato.

O risco é mais óbvio em sistemas com:

• válvulas de controle sensíveis a demandas repentinas de curso,
• sistemas servo ou de acionamento com folga (backlash), saturação ou conformidade mecânica,
• sistemas térmicos com limites de atuador e resposta de processo atrasada,
• e skids de processo onde sequenciamento, permissivos ou disparos interagem com a saída de controle analógico.

Um loop mal ajustado submetido a uma queda de setpoint descontínua pode gerar:

• grandes reversões de saída,
• batida de válvula ou reposicionamento agressivo,
• desgaste desnecessário nos atuadores,
• disparos incômodos de intertravamentos interativos,
• e conclusões de comissionamento enganosas porque o próprio teste se tornou o distúrbio.

Esta é uma das razões pelas quais a validação de gêmeos digitais é útil quando definida corretamente. Neste artigo, validação de gêmeos digitais significa validar o comportamento de controle observável contra um modelo realista de máquina ou processo antes da implantação real: resposta a comandos, mudanças de estado de E/S, tratamento de falhas e a relação entre a lógica ladder ou de controle e o estado do equipamento simulado. Isso não significa que o modelo se tornou um substituto para a aceitação em campo. As plantas não são obrigadas a honrar sua simulação.

O integral windup aparece durante uma rampa móvel quando o controlador continua acumulando correção de erro mais rápido do que o processo consegue responder fisicamente, especialmente perto dos limites de saída ou quando a inclinação comandada excede a capacidade prática do loop. O resultado é um esforço de controle acumulado que se torna óbvio quando o setpoint muda de direção ou reinicia.

Durante a fase de rampa, o termo integral vê um erro persistente e continua somando-o. Esse é o seu trabalho. Mas se o atuador saturar, ou se o processo simplesmente não conseguir acompanhar, o termo integral pode continuar a crescer, apesar do fato de que a saída adicional não é mais útil.

Quando o dente de serra cai, essa ação integral armazenada não desaparece educadamente. Sintomas típicos incluem:

• overshoot abaixo do novo alvo,
• estabilização atrasada enquanto o integrador "desenrola",
• oscilação após a borda de reinicialização,
• e comportamento de saída que parece desproporcionalmente agressivo até que alguém verifique a estratégia anti-windup.

É por isso que o anti-windup não é um refinamento para depois. Ele é parte do design mínimo viável para qualquer loop esperado para seguir comandos móveis. Na prática, proteções úteis podem incluir:

• travamento integral (clamping),
• integração condicional,
• métodos de retrocálculo,
• limitação de saída com rastreamento do integrador,
• e modelagem de comando para que o próprio setpoint respeite a capacidade do processo.

Um loop pode ser estável e ainda assim ser inadequado para acompanhamento de comando. Essa distinção é fácil de perder até que um teste de rampa a exponha.

O acompanhamento de comando geralmente requer uma ênfase de ajuste diferente da rejeição de distúrbios. O controlador deve reduzir o atraso de rastreamento durante a rampa sem se tornar instável ou violento na borda de reinicialização.

A resposta exata depende da dinâmica do processo, tempo morto, limites do atuador e se feedforward ou filtragem de setpoint estão disponíveis. Ainda assim, a direção do ajuste é frequentemente reconhecível.

Ajustes para rastreamento dinâmico

| Parâmetro | Foco no Ajuste Estático | Foco no Dente de Serra Dinâmico | |---|---|---| | Proporcional (P) | Moderado, com ênfase na margem de estabilidade | Mais alto, para reduzir atraso de rampa e ajustar resposta de comando | | Integral (I) | Frequentemente mais forte para remover offset após distúrbios | Moderado e restringido, para reduzir atraso sem windup na reinicialização | | Derivativo (D) | Às vezes útil para amortecer resposta ao degrau | Frequentemente mínimo ou zero se as bordas do setpoint forem abruptas e o derivative kick for um risco |

Vários pontos práticos importam aqui.

Se a PV segue a rampa consistentemente atrás, ação proporcional insuficiente é uma causa comum.

• Ganho proporcional mais alto geralmente ajuda primeiro no rastreamento de rampa.

Se o loop rastreia melhor durante a rampa, mas se torna indisciplinado na queda, a estratégia integral pode estar muito agressiva ou insuficientemente protegida.

• A ação integral deve remover atraso persistente, não criar problemas armazenados.

A derivada pode ajudar em alguns loops, especialmente quando aplicada cuidadosamente à medição em vez do erro. Mas em uma borda de reinicialização dente de serra, o ajuste derivativo descuidado é uma maneira confiável de produzir reclamações dos atuadores.

• A ação derivativa merece suspeita em comandos descontínuos.

Se o perfil de setpoint desejado for conhecido com antecedência, modelar o comando ou adicionar feedforward pode melhorar o rastreamento sem forçar o loop de feedback a compromissos ruins.

• Feedforward ou modelagem de comando podem ser melhores do que aumentos de ganho PID de força bruta.

Um contraste de engenharia útil é este: a rejeição de distúrbios pergunta quão bem o loop resiste a ser empurrado; o acompanhamento de comando pergunta quão bem ele obedece a ser guiado.

Você deve medir o erro de rastreamento, o comportamento da saída e a qualidade da recuperação em ambas as fases da forma de onda. Se você apenas observar se a PV eventualmente chega lá, você perde a maior parte do valor diagnóstico.

No mínimo, capture:

• atraso de rastreamento da fase de rampa entre SP e PV,
• erro de regime permanente durante a rampa,
• comportamento da saída do controlador perto dos limites de saída,
• overshoot ou undershoot após a borda de reinicialização,
• tempo de estabilização após a queda,
• evidências de windup, como recuperação atrasada do integrador,
• e picos de demanda do atuador, especialmente se a ação derivativa estiver habilitada.

Se o ambiente permitir, monitore:

• SP,
• PV,
• saída do controlador,
• contribuição integral,
• contribuição derivativa,
• e quaisquer indicadores de saturação ou travamento.

Este é também o local onde a evidência de engenharia deve ser construída corretamente. Se você precisa mostrar que consegue validar um loop em vez de apenas animar um, documente o trabalho de forma compacta e reproduzível:

1. Descrição do Sistema
2. Definição operacional de comportamento correto
3. Lógica ladder e estado do equipamento simulado
4. O caso de falha injetado
5. A revisão feita
6. Lições aprendidas

Essa estrutura é mais útil do que uma pasta de capturas de tela com nomes de arquivos otimistas. A evidência deve sobreviver ao contato com outro engenheiro.

O OLLA Lab pode ser usado como um ambiente de validação delimitado para testes de acompanhamento de comando porque permite que engenheiros construam lógica, executem simulação, inspecionem variáveis e comparem o comportamento de controle contra o estado do equipamento simulado sem impor o teste diretamente ao hardware físico.

Neste contexto, o OLLA Lab deve ser entendido de forma estreita e credível. É um simulador de lógica ladder e gêmeo digital interativo baseado na web que suporta construção ladder, simulação, inspeção de variáveis, ferramentas analógicas e PID, e cenários industriais realistas. É útil porque permite o ensaio de tarefas de validação de alto risco: observar E/S, rastrear causa e efeito, injetar condições anormais e revisar a lógica antes da exposição no local.

### Passo a passo: executando um teste de rastreamento dente de serra no OLLA Lab

Comece com amplitude e frequência moderadas. Por exemplo: - Amplitude: 100 unidades de engenharia - Frequência: 0,2 Hz - Termo derivativo inicial: 0 ou mínimo

Use a visualização de monitoramento disponível ou ferramentas de tendência estilo osciloscópio para observar:

• atraso SP-para-PV durante a rampa,
• saturação de saída,
• overshoot na borda de reinicialização,
• e quaisquer sinais de windup.

Injete uma condição anormal realista, como:

• limite de atuador,
• resposta de processo atrasada,
• medição ruidosa,
• ou uma interação de permissivo/intertravamento.

1. Crie ou abra um projeto de simulação capaz de PID. Use um cenário com uma variável de processo analógica e um caminho de setpoint controlável.
2. Vincule o setpoint a um sinal de comando gerado. No Painel de Variáveis, atribua a fonte SP a uma forma de onda ou gerador de comando equivalente, se disponível na configuração do cenário.
3. Selecione um perfil dente de serra e defina valores de teste delimitados.
4. Monitore SP, PV e saída do controlador juntos.
5. Ajuste os ganhos uma mudança de cada vez. Aumente o ganho proporcional até que o rastreamento de rampa melhore sem induzir oscilação sustentada. Em seguida, introduza ou refine a ação integral cuidadosamente para reduzir o atraso residual. Adicione derivada apenas se o processo se beneficiar e a implementação evitar comportamento de kick prejudicial.
6. Repita com um caso de falha ou restrição. Um loop que só se comporta em condições ideais não está validado. Ele está apenas sem oposição.
7. Registre a revisão e o resultado. Documente o que mudou, o que melhorou e qual compensação apareceu. Esse é o início do julgamento de comissionamento.

Exemplo de artefato de configuração PID

[Linguagem: Texto Estruturado / Configuração PID]

PID_Target.SP := Waveform_Gen.Sawtooth_Out; PID_Target.Kp := 2.5; // Aumentado para reduzir o atraso de rastreamento de rampa PID_Target.Ki := 1.2; // Moderado e travado para limitar o windup PID_Target.Kd := 0.0; // Zerado inicialmente para evitar o kick na borda de reinicialização

Texto Alternativo da Imagem: Captura de tela de uma visualização de tendência do OLLA Lab mostrando um loop PID rastreando um setpoint dente de serra, com a variável de processo atrasando ligeiramente durante a rampa e recuperando-se após a borda de reinicialização, enquanto o painel de variáveis exibe os valores de ganho proporcional e integral.

O correto deve ser definido operacionalmente antes do início do teste. Caso contrário, o ajuste se transforma em preferência estética com gráficos melhores.

Para um exercício de acompanhamento de comando dente de serra, uma definição operacional de correção pode incluir:

• PV rastreando a rampa dentro de uma banda de erro declarada,
• sem oscilação sustentada,
• sem saturação de saída prolongada,
• overshoot delimitado após a borda de reinicialização,
• tempo de estabilização aceitável após a queda,
• e nenhuma demanda de atuador insegura ou irrealista no modelo de equipamento simulado.

Essa definição deve estar vinculada ao propósito do processo. Uma rampa de batelada térmica, um comando de vazão e um loop de posição tipo servo não compartilham o mesmo envelope de erro aceitável. "Parece muito bom" não é um critério de controle.

Este é também o lugar certo para reafirmar o papel delimitado da simulação. O OLLA Lab pode ajudar engenheiros a validar o comportamento da lógica, comparar o estado ladder com o estado do equipamento simulado e ensaiar revisões conscientes de falhas antes da exposição em campo. Ele não certifica competência no local, conformidade com segurança funcional ou capacidade de implantação por associação. A IEC 61508 e a prática de segurança relacionada não são satisfeitas porque um gráfico pareceu organizado em um navegador.

Você deve considerar feedforward ou modelagem de setpoint quando a trajetória comandada for conhecida, repetível e fisicamente mais exigente do que o loop de feedback consegue rastrear de forma limpa sem compensações de ganho inaceitáveis. Às vezes, a resposta certa não é mais PID.

Feedforward é útil quando:

• o perfil de comando é previsível,
• grandes mudanças de carga são mensuráveis,
• ou o processo tem estrutura suficiente para que a compensação proativa seja credível.

A modelagem de setpoint é útil quando:

• o comando bruto contém descontinuidades,
• a proteção do atuador importa,
• ou o processo não deve ser solicitado a responder a bordas matematicamente abruptas.

Um dente de serra é um sinal diagnóstico útil precisamente porque é severo. Isso não significa que o processo real deva ser comandado com a mesma brutalidade. Sinais de validação e sinais operacionais nem sempre são a mesma coisa.

A distinção entre comportamento servo e regulatório, a importância do anti-windup e o papel da simulação na validação de controle estão bem fundamentados na literatura de engenharia de controle convencional e na prática industrial reconhecida.

O suporte relevante inclui:

• Literatura de controle de processo alinhada à ISA distinguindo objetivos servo e regulatórios,
• textos de sistemas de controle abordando erro de rastreamento de rampa e derivative kick,
• pesquisa de anti-windup em implementação PID industrial,
• ênfase mais ampla da IEC 61508 no rigor do ciclo de vida, verificação e reivindicações delimitadas em torno de sistemas relacionados à segurança,
• e literatura de simulação aplicada mostrando o valor de ambientes digitais para testar o comportamento de controle antes da implantação real.

O ponto cuidadoso é este: a simulação apoia uma validação mais segura e um diagnóstico melhor. Ela não apaga a necessidade de comissionamento em campo, testes de aceitação ou julgamento de engenharia específico do processo.

- Visão geral de Segurança Funcional IEC 61508 - Recursos de Automação e Segurança Funcional exida - Åström & Hägglund, *Advanced PID Control* (ISA) - Skogestad (2003), Regras de ajuste PID00062-8) - Tao et al. (2019), Gêmeos Digitais na Indústria