Como Corrigir Erros em Totalizadores de Vazão com Matemática de Inteiros vs. Real em CLPs

Erros em totalizadores de vazão em CLPs geralmente surgem de duas falhas matemáticas distintas: truncamento de inteiros e perda de precisão em ponto flutuante de precisão simples. Tags do tipo INT descartam a vazão fracionária, enquanto tags REAL de 32 bits podem eventualmente parar de registrar pequenos incrementos em relação a um grande total acumulado. Uma totalização confiável requer disciplina quanto aos tipos de dados, projeto de rollover e validação baseada em simulação.

Um totalizador de vazão pode estar incorreto mesmo quando o transmissor, a bomba e a tubulação estão operando corretamente. A falha geralmente está dentro do modelo aritmético do CLP, não no processo. Essa distinção é importante porque uma matemática incorreta é mais silenciosa do que uma falha de hardware.

Durante uma execução simulada de 24 horas de uma bomba no OLLA Lab, testando um totalizador INT de 16 bits contra um incremento repetido de 0,4 galões, o acumulador registrou 0 galões, enquanto o processo simulado movimentou 576 galões. Metodologia: tamanho da amostra = 1 tarefa de simulação controlada usando incrementos fixos repetidos; comparador de linha de base = acúmulo aritmético esperado de 0,4 galões ao longo de 1.440 minutos; janela de tempo = 24 horas simuladas. Isso sustenta um ponto específico: o truncamento de inteiros pode produzir perda total de vazão fracionada em um caso de teste determinístico. Isso não estabelece uma taxa de falha universal em campo.

É aqui que a "sintaxe versus capacidade de implantação" se torna real. Um degrau (rung) pode parecer correto, compilar sem erros e ainda induzir a operação ao erro por semanas.

Erros de truncamento ocorrem quando um CLP armazena ou processa vazão fracionária usando um tipo de dado inteiro que não consegue representar decimais. Se o incremento de entrada for 0,8 e o destino for um INT, a parte fracionária é descartada antes mesmo de se tornar inventário.

Em ambientes IEC 61131-3, esse comportamento é normal para o tipo de dado. O erro é assumir que o processo irá perdoá-lo.

Os limites de inteiros com sinal de 16 bits

Um inteiro de 16 bits com sinal (`INT`) possui uma faixa finita:

- Mínimo: `-32.768` - Máximo: `32.767`

Se um totalizador acumula contagens de pulsos ou volume escalonado diretamente em um `INT`, dois modos de falha aparecem rapidamente:

- Overflow (Estouro): uma vez que o valor excede `32.767`, ele entra na faixa negativa ou gera falha, dependendo do comportamento da plataforma e do tratamento da instrução. - Exclusão fracionária: qualquer valor abaixo de 1,0 é truncado quando convertido ou gravado em um destino inteiro.

Para uma aplicação de pulsos por unidade, o overflow pode acontecer surpreendentemente rápido. Para um totalizador incremental derivado de sinal analógico, o truncamento pode ocorrer a cada ciclo de varredura (scan). Um é dramático; o outro é frequentemente mais difícil de notar.

Por que totalizadores de inteiros deletam silenciosamente a vazão real

A matemática de inteiros não "arredonda um pouco". Ela remove o resto. Se a sua lógica calcula:

• `Incremento_Vazao = 0,8 galões por scan`
• `Total_INT = Total_INT + Incremento_Vazao`

então a adição efetiva torna-se:

• `Total_INT = Total_INT + 0`

O processo movimentou fluido. O CLP não registrou nada.

Este é um erro de projeto comum quando engenheiros escalonam um sinal de vazão de 4–20 mA em unidades de engenharia, dividem por uma base de tempo e, em seguida, gravam o resultado em um acumulador inteiro. O degrau pode ser sintaticamente válido, mas o totalizador já está comprometido.

Por que a taxa de varredura (scan rate) piora o problema

Ciclos de varredura rápidos aumentam a chance de que cada volume incremental seja pequeno. Isso significa que mais adições caem abaixo de 1,0 unidade de engenharia e são perdidas se o destino for baseado em inteiros.

Um totalizador de alta resolução, portanto, requer mais do que um bloco ADD. Ele requer alinhamento entre:

• escalonamento de sinal,
• intervalo de varredura,
• unidades de engenharia,
• tipo de dado do acumulador.

Um REAL de 32 bits resolve o problema da fração, mas introduz uma falha diferente: perda de precisão em valores acumulados grandes. Uma vez que o total se torna grande o suficiente, pequenos incrementos de entrada não alteram mais o número armazenado.

Este é um comportamento do IEEE 754, não necessariamente um defeito de software. É assim que funciona o ponto flutuante de precisão simples.

O limite de precisão de ponto flutuante

A maioria dos tipos `REAL` de CLPs são valores de ponto flutuante de precisão simples IEEE 754. Em termos práticos de engenharia, eles fornecem cerca de 7 dígitos decimais significativos de precisão.

Isso significa que o tamanho da menor mudança representável depende da magnitude do número já armazenado.

Exemplos:

• Perto de `10,0`, adicionar `0,01` é geralmente representável.
• Perto de `1.000.000,0`, adicionar `0,01` pode ser pequeno demais para alterar o valor armazenado.
• Perto de totais maiores, até mesmo incrementos modestos podem ser "engolidos".

O totalizador não falha porque o processo parou. Ele falha porque a resolução numérica do acumulador tornou-se mais grosseira do que o incremento que está sendo adicionado.

Como é o efeito de "engolimento"

O sintoma clássico é simples:

• o transmissor de vazão indica vazão ativa,
• a bomba está funcionando,
• o processo está fisicamente movimentando produto,
• mas o totalizador do SCADA permanece estagnado.

Nesse ponto, os operadores frequentemente suspeitam de comunicações, atraso no historiador ou desvio de instrumentação. Às vezes, o problema é muito menos glamoroso: o acumulador esgotou sua granularidade útil.

Um `REAL` pode representar números grandes ou pequenos incrementos bem o suficiente para muitas tarefas. Ele não pode fazer ambos indefinidamente em um totalizador crescente sem controles de projeto.

Por que isso importa em bateladas, utilidades e relatórios de custódia

Nem todo totalizador é financeiramente crítico, mas muitos são operacionalmente consequentes. Erros na vazão acumulada podem distorcer:

• cálculos de rendimento de batelada,
• registros de dosagem química,
• relatórios de balanço hídrico,
• estimativas de uso de CIP,
• reconciliação de inventário de tanques,
• decisões de manutenção vinculadas à produção.

Este artigo não faz uma reivindicação de conformidade de transferência de custódia. Ele faz uma reivindicação de engenharia mais restrita: se a arquitetura do acumulador for fraca, o volume reportado pode divergir materialmente da realidade física.

A resposta correta depende do que você está acumulando: pulsos, unidades de engenharia escalonadas ou incrementos de tempo fracionados. Não existe uma escolha de tag universal única, mas existem padrões defensáveis.

Use DINT para acúmulo de contagem inteira sempre que possível

Se a fonte for um fluxo de pulsos e cada pulso representar uma quantidade fixa, um `DINT` é geralmente mais seguro do que um `INT`.

Por que:

• Um `DINT` de 32 bits com sinal varia de `-2.147.483.648` a `2.147.483.647`
• Ele atrasa drasticamente o overflow em relação ao `INT`
• Ele preserva contagens de números inteiros exatos

Para totalização de pulsos, contar inteiros como inteiros é geralmente o projeto mais limpo.

Use REAL com cuidado para acúmulo de trabalho fracionário

Se o incremento de origem for fracionário, um `REAL` pode ser útil como um acumulador de trabalho, nem sempre como o único totalizador de vida útil.

Bons casos de uso:

• acumular vazão fracionária de janela curta,
• manter um subtotal antes do rollover,
• suportar totais diários ou de batelada visíveis ao operador com intervalos de reset limitados.

Caso de uso arriscado:

• deixar um único REAL de 32 bits crescer indefinidamente enquanto adiciona incrementos muito pequenos.

É aí que a erosão de precisão se torna um problema de projeto, e não teórico.

Use LREAL se sua plataforma suportar e a aplicação justificar

Um `LREAL` de 64 bits oferece precisão e alcance muito maiores do que um `REAL` de 32 bits. Em plataformas que o suportam de forma confiável nas camadas de controlador, IHM, historiador e interface, é frequentemente uma solução mais limpa para totalização fracionária de longa duração.

Mas "suportar" deve significar suporte de ponta a ponta:

• comportamento da instrução do controlador,
• transporte de tags,
• compatibilidade com SCADA/IHM,
• tipo de armazenamento do historiador,
• interpretação da camada de relatório.

Uma tag de controlador matematicamente sólida não é suficiente se o restante da pilha a converter silenciosamente para um tipo inferior.

Um totalizador de rollover em cascata separa o acúmulo fracionário do armazenamento de longo prazo. Este padrão é frequentemente mais robusto do que manter um único total de ponto flutuante que cresce continuamente.

O princípio de projeto é simples:

• acumular pequenos incrementos em um registrador capaz de lidar com frações,
• transferir pedaços maiores para um total inteiro de longo alcance,
• reter apenas o resto no registrador fracionário.

Isso reduz a chance de que pequenas adições desapareçam em relação a um número de ponto flutuante muito grande.

Exemplo de padrão de lógica

Passo 1: Acumular o incremento de vazão bruto em um total de trabalho REAL.

`ADD Incremento_Vazao, Total_Trabalho_Real, Total_Trabalho_Real`

Passo 2: Verificar se o total de trabalho atingiu um limite de transferência.

`CMP Total_Trabalho_Real >= 100.0`

Passo 3: Mover o valor do limite para um total mestre inteiro de longo alcance.

`ADD 100, Total_Mestre_DINT, Total_Mestre_DINT`

`SUB Total_Trabalho_Real, 100.0, Total_Trabalho_Real`

Por que este padrão funciona

O benefício de engenharia é a estabilidade numérica.

Um projeto em cascata oferece:

• retenção de fração no registrador de trabalho,
• armazenamento de longo alcance no total mestre inteiro,
• redução da perda de precisão de ponto flutuante porque o subtotal REAL permanece relativamente pequeno,
• auditoria clara de como o total é construído.

Você também pode estender o padrão com:

• totais de batelada,
• registradores de reset diário,
• totais retidos não voláteis,
• verificações de alarme para anomalias de rollover,
• intertravamentos de sequência que impedem atualizações durante estados inválidos do instrumento.

O que "correto" significa para um projeto de totalizador

Um totalizador não é "correto" porque o degrau compila ou o número na IHM muda. Ele é correto quando a lógica satisfaz uma definição operacional como:

• o volume acumulado corresponde à aritmética esperada dentro da tolerância definida,
• o comportamento de overflow é evitado ou explicitamente tratado,
• estados de entrada inválidos não criam acúmulo falso,
• o comportamento de reset é controlado e auditável,
• a precisão de longo prazo permanece adequada para o propósito do relatório.

Esse é o padrão que importa no comissionamento.

O OLLA Lab é útil aqui como um ambiente de validação delimitado, não como um oráculo. Seu valor reside no fato de que os engenheiros podem observar o comportamento scan-a-scan, manipular entradas com segurança e comparar o estado da lógica ladder contra o comportamento do processo simulado antes que um sistema real herde o erro.

Em termos práticos, isso significa que você pode testar se a matemática do totalizador se comporta corretamente sob condições operacionais realistas, em vez de confiar em um degrau visualmente organizado.

O que o OLLA Lab torna observável

Usando o Editor de Lógica Ladder, Modo de Simulação e Painel de Variáveis, um usuário pode:

• construir um totalizador usando lógica `INT`, `DINT`, `REAL` ou de tipos mistos,
• injetar incrementos de vazão fixos ou variáveis,
• monitorar valores de acumuladores em tempo real,
• comparar o comportamento da entrada contra a matemática da saída,
• acelerar a simulação para expor problemas de precisão de longo prazo mais rapidamente.

Isso é operacionalmente útil porque muitas dessas falhas são lentas em campo. Na simulação, elas se tornam inspecionáveis.

Definição operacional de "Pronto para Simulação"

Neste contexto, Pronto para Simulação significa que um engenheiro pode:

• provar o comportamento de controle pretendido,
• observar o efeito de cada entrada e transição de estado,
• diagnosticar falhas numéricas e de sequenciamento,
• fortalecer a lógica contra o comportamento realista do processo,
• documentar por que a lógica revisada é mais confiável antes que ela chegue a um processo real.

Isso não significa competência local, certificação ou prontidão automática para comissionamento sem supervisão. A simulação é um ensaio, não uma absolvição legal.

Um fluxo de trabalho de validação prático no OLLA Lab

Uma sequência de validação útil no OLLA Lab seria:

1. Criar uma fonte de vazão simulada com comportamento incremental conhecido.
2. Construir um totalizador usando `INT` e outro usando `REAL`.
3. Executar ambos sob incrementos idênticos.
4. Observar o truncamento no caminho do inteiro.
5. Aumentar o acumulador REAL até que pequenos incrementos parem de alterar o total.
6. Substituir o projeto por um rollover em cascata ou estratégia de maior precisão.
7. Executar o cenário novamente e comparar os resultados.

É aqui que o OLLA Lab se torna operacionalmente útil. Ele dá visibilidade a uma classe de falhas que frequentemente sobrevivem à revisão de mesa e só se tornam óbvias após a reconciliação de inventário se tornar difícil.

Uma captura de tela de um degrau não é evidência de engenharia. Ela é apenas ilustrativa, a menos que esteja vinculada ao comportamento, injeção de falhas e histórico de revisões.

Se você deseja demonstrar um trabalho de controle sério, use um pacote de evidências compacto com seis partes:

Documente a falha exata introduzida: truncamento de inteiro, overflow, engolimento de ponto flutuante, escalonamento incorreto ou condição de corrida de reset.

Explique a mudança de projeto: migração para `DINT`, adoção de `LREAL`, rollover em cascata, lógica de transferência de limite ou acúmulo com porta lógica.

1. Descrição do Sistema Defina o contexto do processo, fonte de sinal, unidades, premissas de varredura e objetivo da totalização.
2. Definição operacional de "correto" Declare o comportamento aritmético esperado, tolerância, regras de reset e tratamento de estados inválidos.
3. Lógica Ladder e estado do equipamento simulado Mostre a lógica e o comportamento do processo simulado correspondente juntos, não isoladamente.
4. O caso de falha injetado
5. A revisão feita
6. Lições aprendidas Capture o que o teste provou, quais premissas falharam e o que deve se tornar um padrão de projeto.

Essa estrutura está mais próxima de uma evidência de comissionamento do que de um simples instantâneo de portfólio.

O comportamento subjacente do tipo de dado é fundamentado em princípios padrão de programação industrial e computação numérica, não em folclore de plataforma.

Âncoras relevantes incluem:

• IEC 61131-3 para linguagens de programação de CLP e convenções de tipos de dados usadas em sistemas de controle industrial.
• IEEE 754 para comportamento de aritmética de ponto flutuante, incluindo precisão finita e limites representacionais.
• IEC 61508 para o princípio mais amplo de que erros sistemáticos de projeto em sistemas programáveis devem ser identificados e controlados por meio de processos de engenharia disciplinados.
• Literatura de simulação e gêmeos digitais em automação industrial, que geralmente apoia o uso de ambientes modelados para validar o comportamento de controle antes da implantação, especialmente onde testes reais são caros ou arriscados.

Este artigo não afirma que um simulador sozinho estabelece conformidade, integridade de segurança ou aceitação em campo. Ele faz uma reivindicação mais restrita: a simulação melhora a observabilidade de falhas lógicas determinísticas que, de outra forma, são caras de detectar tardiamente.

Erros em totalizadores de vazão são frequentemente causados por escolhas inadequadas de tipos de dados. Tags `INT` deletam frações, tags `REAL` podem eventualmente perder pequenos incrementos em relação a totais grandes, e ambas as falhas podem permanecer invisíveis por tempo suficiente para prejudicar relatórios, a confiança no inventário e a confiança do operador.

A correção de engenharia é direta em princípio: use a arquitetura numérica correta para o sinal, defina o que "correto" significa antes do comissionamento e valide o comportamento sob carga. Essa é a diferença entre um programa ladder que roda e uma estratégia de controle que permanece confiável na produção.

- IEEE Std 754-2019 — Floating-Point Arithmetic - IEC 61131-3 — PLC programming languages - IEC 61508 Functional Safety overview - Kritzinger et al. (2018), Digital twin in manufacturing (IFAC) - Tao et al. (2019), Digital twin in industry (IEEE TII)