Comment corriger les erreurs de totalisateur de débit en mathématiques PLC (Entier vs Réel)

Les erreurs de totalisateur de débit dans les automates (PLC) proviennent généralement de deux défaillances mathématiques distinctes : la troncature des entiers et la perte de précision des nombres à virgule flottante simple précision. Les balises INT rejettent le débit fractionnaire, tandis que les balises REAL 32 bits peuvent finir par ne plus enregistrer les petits incréments par rapport à un total accumulé important. Une totalisation fiable nécessite une discipline rigoureuse sur les types de données, une conception adaptée au basculement (rollover) et une validation basée sur la simulation.

Un totalisateur de débit peut être erroné même lorsque le transmetteur, la pompe et la tuyauterie fonctionnent correctement. La défaillance se situe souvent dans le modèle arithmétique de l'automate, et non dans le processus. Cette distinction est importante car les erreurs mathématiques sont plus discrètes que les pannes matérielles.

Lors d'une simulation de 24 heures de fonctionnement d'une pompe dans OLLA Lab, en testant un totalisateur INT 16 bits face à un incrément répété de 0,4 gallon, l'accumulateur a enregistré 0 gallon alors que le processus simulé déplaçait 576 gallons. Méthodologie : taille de l'échantillon = 1 tâche de simulation contrôlée utilisant des incréments fixes répétés ; comparateur de référence = accumulation arithmétique attendue de 0,4 gallon sur 1 440 minutes ; fenêtre temporelle = 24 heures simulées. Cela confirme un point précis : la troncature des entiers peut entraîner une perte totale du débit fractionnaire dans un cas de test déterministe. Cela n'établit pas un taux de défaillance universel sur le terrain.

C'est ici que la différence entre « syntaxe » et « déployabilité » devient réelle. Un barreau (rung) peut sembler correct, compiler sans erreur et continuer à induire les opérateurs en erreur pendant des semaines.

Les erreurs de troncature surviennent lorsqu'un automate stocke ou traite un débit fractionnaire en utilisant un type de données entier incapable de représenter les décimales. Si l'incrément entrant est de 0,8 et que la destination est un INT, la partie fractionnaire est supprimée avant même d'être comptabilisée.

Dans les environnements IEC 61131-3, ce comportement est normal pour ce type de données. L'erreur consiste à supposer que le processus « pardonnera » cette perte.

Les limites des entiers signés 16 bits

Un entier signé 16 bits (`INT`) possède une plage finie :

- Minimum : `-32 768` - Maximum : `32 767`

Si un totalisateur accumule directement des comptages d'impulsions ou un volume mis à l'échelle dans un `INT`, deux modes de défaillance apparaissent rapidement :

- Dépassement (Overflow) : une fois que la valeur dépasse `32 767`, elle bascule dans la plage négative ou génère une erreur, selon le comportement de la plateforme et la gestion des instructions. - Suppression fractionnaire : toute valeur inférieure à 1,0 est tronquée lors de la conversion ou de l'écriture dans une destination entière.

Pour une application d'impulsions par unité, le dépassement peut survenir étonnamment vite. Pour un totalisateur incrémental dérivé d'un signal analogique, la troncature peut se produire à chaque cycle de balayage (scan). L'un est spectaculaire ; l'autre est souvent plus difficile à remarquer.

Pourquoi les totalisateurs entiers suppriment silencieusement le débit réel

Les mathématiques entières ne « s'arrondissent pas un peu ». Elles suppriment le reste. Si votre logique calcule :

• `Incrément_Débit = 0,8 gallon par cycle`
• `Total_INT = Total_INT + Incrément_Débit`

alors l'addition effective devient :

• `Total_INT = Total_INT + 0`

Le processus a déplacé du fluide. L'automate n'a rien enregistré.

Il s'agit d'une erreur de conception courante lorsque les ingénieurs mettent à l'échelle un signal de débit 4–20 mA en unités techniques, divisent par une base de temps, puis écrivent le résultat dans un accumulateur entier. Le barreau peut être syntaxiquement valide, mais le totalisateur est déjà compromis.

Pourquoi la vitesse de balayage aggrave le problème

Des cycles de balayage rapides augmentent la probabilité que chaque volume incrémental soit faible. Cela signifie qu'un plus grand nombre d'additions tombe en dessous de 1,0 unité technique et est perdu si la destination est basée sur des entiers.

Un totalisateur haute résolution nécessite donc plus qu'un simple bloc ADD. Il exige une cohérence entre :

• la mise à l'échelle du signal,
• l'intervalle de balayage,
• les unités techniques,
• le type de données de l'accumulateur.

Un REAL 32 bits résout le problème des fractions, mais introduit une défaillance différente : la perte de précision sur les grandes valeurs accumulées. Une fois que le total devient suffisamment important, les petits incréments entrants ne modifient plus le nombre stocké.

Il s'agit d'un comportement IEEE 754, et non nécessairement d'un défaut logiciel. C'est ainsi que fonctionne la virgule flottante simple précision.

La limite de précision de la virgule flottante

La plupart des types `REAL` des automates sont des valeurs IEEE 754 en virgule flottante simple précision. En termes d'ingénierie pratique, ils offrent environ 7 chiffres décimaux significatifs de précision.

Cela signifie que la taille du plus petit changement représentable dépend de la magnitude du nombre déjà stocké.

Exemples :

• Près de `10,0`, l'ajout de `0,01` est généralement représentable.
• Près de `1 000 000,0`, l'ajout de `0,01` peut être trop faible pour modifier la valeur stockée.
• Près de totaux plus importants, même des incréments modestes peuvent être « avalés ».

Le totalisateur ne tombe pas en panne parce que le processus s'est arrêté. Il échoue parce que la résolution numérique de l'accumulateur est devenue plus grossière que l'incrément ajouté.

À quoi ressemble l'effet « d'absorption »

Le symptôme classique est simple :

• le transmetteur de débit indique un débit actif,
• la pompe fonctionne,
• le processus déplace physiquement le produit,
• mais le totalisateur SCADA reste plat.

À ce stade, les opérateurs suspectent souvent les communications, le retard de l'historien ou la dérive de l'instrumentation. Parfois, le problème est beaucoup moins glamour : l'accumulateur a épuisé sa granularité utile.

Un `REAL` peut représenter des nombres importants ou de petits incréments suffisamment bien pour de nombreuses tâches. Il ne peut pas faire les deux indéfiniment dans un totalisateur croissant sans contrôles de conception.

Pourquoi cela est important dans le dosage, les services publics et les rapports de garde

Tous les totalisateurs ne sont pas critiques sur le plan financier, mais beaucoup ont des conséquences opérationnelles. Les erreurs dans le débit accumulé peuvent fausser :

• les calculs de rendement des lots,
• les enregistrements de dosage chimique,
• les rapports de bilan hydrique,
• les estimations de consommation CIP,
• le rapprochement des stocks de réservoirs,
• les décisions de maintenance liées au débit.

Cet article ne prétend pas à la conformité pour le transfert de garde. Il avance une thèse d'ingénierie plus étroite : si l'architecture de l'accumulateur est faible, le volume rapporté peut diverger matériellement de la réalité physique.

La réponse correcte dépend de ce que vous accumulez : impulsions, unités techniques mises à l'échelle ou incréments de pas de temps fractionnaires. Il n'existe pas de choix de balise universel, mais il existe des modèles défendables.

Utilisez DINT pour l'accumulation de comptages entiers si possible

Si la source est un flux d'impulsions et que chaque impulsion représente une quantité fixe, un `DINT` est généralement plus sûr qu'un `INT`.

Pourquoi :

• Un `DINT` signé 32 bits varie de `-2 147 483 648` à `2 147 483 647`.
• Il retarde considérablement le dépassement par rapport à `INT`.
• Il préserve les comptages exacts en nombres entiers.

Pour la totalisation d'impulsions, compter des entiers comme des entiers est généralement la conception la plus propre.

Utilisez REAL avec précaution pour l'accumulation de travail fractionnaire

Si l'incrément source est fractionnaire, un `REAL` peut être utile comme accumulateur de travail, et non toujours comme seul totalisateur à vie.

Bons cas d'utilisation :

• accumulation de débit fractionnaire sur une courte fenêtre,
• maintien d'un sous-total avant basculement,
• support des totaux quotidiens ou par lot visibles par l'opérateur avec des intervalles de réinitialisation bornés.

Cas d'utilisation risqué :

• laisser un seul REAL 32 bits croître indéfiniment tout en ajoutant de très petits incréments.

C'est là que l'érosion de la précision devient un problème de conception plutôt que théorique.

Utilisez LREAL si votre plateforme le supporte et que l'application le justifie

Un `LREAL` 64 bits offre une précision et une plage bien supérieures à un `REAL` 32 bits. Sur les plateformes qui le supportent de manière fiable au niveau du contrôleur, de l'IHM, de l'historien et des couches d'interface, c'est souvent une solution plus propre pour la totalisation fractionnaire à long terme.

Mais « supporter » doit signifier un support de bout en bout :

• comportement de l'instruction du contrôleur,
• transport des balises,
• compatibilité SCADA/IHM,
• type de stockage de l'historien,
• interprétation de la couche de rapport.

Une balise de contrôleur mathématiquement saine ne suffit pas si le reste de la pile effectue une conversion descendante silencieuse.

Un totalisateur à basculement en cascade sépare l'accumulation fractionnaire du stockage à long terme. Ce modèle est souvent plus robuste que le maintien d'un total en virgule flottante qui ne cesse de croître.

Le principe de conception est simple :

• accumuler les petits incréments dans un registre capable de gérer les fractions,
• transférer des blocs plus importants dans un total entier à longue portée,
• ne conserver que le reste dans le registre fractionnaire.

Cela réduit le risque que de minuscules ajouts disparaissent face à un nombre en virgule flottante très important.

Exemple de modèle logique

Étape 1 : Accumuler l'incrément de débit brut dans un total de travail REAL.

`ADD Incrément_Débit, Total_Travail_Real, Total_Travail_Real`

Étape 2 : Vérifier si le total de travail a atteint un seuil de transfert.

`CMP Total_Travail_Real >= 100,0`

Étape 3 : Déplacer le montant du seuil dans un total maître entier à longue portée.

`ADD 100, Total_Maître_DINT, Total_Maître_DINT`

`SUB Total_Travail_Real, 100,0, Total_Travail_Real`

Pourquoi ce modèle fonctionne

L'avantage technique est la stabilité numérique.

Une conception en cascade vous offre :

• la rétention des fractions dans le registre de travail,
• un stockage à longue portée dans le total maître entier,
• une perte de précision réduite en virgule flottante car le sous-total REAL reste relativement petit,
• une auditabilité claire de la façon dont le total est construit.

Vous pouvez également étendre le modèle avec :

• des totaux par lot,
• des registres de réinitialisation quotidienne,
• des totaux conservés non volatils,
• des vérifications d'alarme pour les anomalies de basculement,
• des verrouillages de séquence qui empêchent les mises à jour pendant les états d'instrument invalides.

Ce que signifie « correct » pour une conception de totalisateur

Un totalisateur n'est pas « correct » parce que le barreau compile ou que le chiffre de l'IHM change. Il est correct lorsque la logique satisfait une définition opérationnelle telle que :

• le volume accumulé correspond à l'arithmétique attendue dans la tolérance définie,
• le comportement de dépassement est empêché ou explicitement géré,
• les états d'entrée invalides ne créent pas de fausse accumulation,
• le comportement de réinitialisation est contrôlé et auditable,
• la précision à long terme reste adaptée à l'objectif du rapport.

C'est la norme qui compte lors de la mise en service.

OLLA Lab est utile ici comme environnement de validation borné, et non comme un oracle. Sa valeur réside dans le fait que les ingénieurs peuvent observer le comportement cycle par cycle, manipuler les entrées en toute sécurité et comparer l'état de l'échelle (ladder) par rapport au comportement du processus simulé avant qu'un système réel n'hérite de l'erreur.

En termes pratiques, cela signifie que vous pouvez tester si les mathématiques du totalisateur se comportent correctement dans des conditions de fonctionnement réalistes plutôt que de faire confiance à un barreau visuellement propre.

Ce qu'OLLA Lab rend observable

En utilisant l'Éditeur de logique Ladder, le Mode Simulation et le Panneau des variables, un utilisateur peut :

• construire un totalisateur en utilisant une logique `INT`, `DINT`, `REAL` ou de type mixte,
• injecter des incréments de débit fixes ou variables,
• surveiller les valeurs de l'accumulateur en temps réel,
• comparer le comportement des entrées par rapport aux mathématiques de sortie,
• accélérer la simulation pour exposer plus rapidement les problèmes de précision à long terme.

C'est opérationnellement utile car beaucoup de ces défaillances sont lentes sur le terrain. En simulation, elles deviennent inspectables.

Définition opérationnelle de « Simulation-Ready »

Dans ce contexte, Simulation-Ready signifie qu'un ingénieur peut :

• prouver le comportement de contrôle prévu,
• observer l'effet de chaque entrée et transition d'état,
• diagnostiquer les défauts numériques et de séquençage,
• renforcer la logique contre un comportement de processus réaliste,
• documenter pourquoi la logique révisée est plus fiable avant qu'elle n'atteigne un processus réel.

Cela ne signifie pas une compétence sur site, une certification ou une préparation automatique pour une mise en service sans supervision. La simulation est une répétition, pas une absolution légale.

Un flux de travail de validation pratique dans OLLA Lab

Une séquence de validation utile dans OLLA Lab serait :

1. Créer une source de débit simulée avec un comportement incrémental connu.
2. Construire un totalisateur en utilisant `INT` et un autre en utilisant `REAL`.
3. Exécuter les deux sous des incréments identiques.
4. Observer la troncature dans le chemin entier.
5. Augmenter l'accumulateur REAL jusqu'à ce que les petits incréments cessent de modifier le total.
6. Remplacer la conception par un basculement en cascade ou une stratégie de plus haute précision.
7. Relancer le scénario et comparer les résultats.

C'est là qu'OLLA Lab devient opérationnellement utile. Il donne une visibilité sur une classe de défaillances qui survivent souvent à la revue de bureau et ne deviennent évidentes qu'une fois que le rapprochement des stocks devient difficile.

Une capture d'écran d'un barreau n'est pas une preuve d'ingénierie. Elle n'est qu'illustrative à moins d'être liée au comportement, à l'injection de défauts et à l'historique des révisions.

Si vous souhaitez démontrer un travail de contrôle sérieux, utilisez un dossier de preuves compact en six parties :

Documentez la défaillance exacte introduite : troncature entière, dépassement, absorption en virgule flottante, mauvaise mise à l'échelle ou condition de course de réinitialisation.

Expliquez le changement de conception : migration `DINT`, adoption `LREAL`, basculement en cascade, logique de transfert de seuil ou accumulation déclenchée.

1. Description du système Définissez le contexte du processus, la source du signal, les unités, les hypothèses de balayage et l'objectif de totalisation.
2. Définition opérationnelle de « correct » Indiquez le comportement arithmétique attendu, la tolérance, les règles de réinitialisation et la gestion des états invalides.
3. Logique Ladder et état de l'équipement simulé Montrez la logique et le comportement du processus simulé correspondant ensemble, et non isolément.
4. Le cas de défaut injecté
5. La révision effectuée
6. Leçons apprises Capturez ce que le test a prouvé, quelles hypothèses ont échoué et ce qui devrait devenir une norme de conception.

Cette structure est plus proche d'une preuve de mise en service que d'un simple instantané de portefeuille.

Le comportement sous-jacent des types de données est fondé sur la programmation industrielle standard et les principes de calcul numérique, et non sur le folklore des plateformes.

Les ancres pertinentes incluent :

• IEC 61131-3 pour les langages de programmation PLC et les conventions de types de données utilisées dans les systèmes de contrôle industriel.
• IEEE 754 pour le comportement de l'arithmétique en virgule flottante, y compris la précision finie et les limites de représentation.
• IEC 61508 pour le principe plus large selon lequel les erreurs de conception systématiques dans les systèmes programmables doivent être identifiées et contrôlées par des processus d'ingénierie disciplinés.
• La littérature sur la simulation et les jumeaux numériques dans l'automatisation industrielle, qui soutient généralement l'utilisation d'environnements modélisés pour valider le comportement de contrôle avant le déploiement, en particulier lorsque les tests en direct sont coûteux ou risqués.

Cet article ne prétend pas qu'un simulateur seul établit la conformité, l'intégrité de la sécurité ou l'acceptation sur le terrain. Il avance une thèse plus étroite : la simulation améliore l'observabilité des défaillances logiques déterministes qui sont autrement coûteuses à détecter tardivement.

Les erreurs de totalisateur de débit sont souvent causées par des choix de types de données médiocres. Les balises `INT` suppriment les fractions, les balises `REAL` peuvent finir par perdre de petits incréments par rapport à des totaux importants, et les deux défaillances peuvent rester invisibles assez longtemps pour nuire aux rapports, à la confiance dans les stocks et à la confiance des opérateurs.

La correction technique est simple en principe : utilisez l'architecture numérique appropriée pour le signal, définissez ce que signifie « correct » avant la mise en service et validez le comportement sous charge. C'est la différence entre un programme ladder qui s'exécute et une stratégie de contrôle qui reste fiable en production.

- IEEE Std 754-2019 — Arithmétique en virgule flottante - IEC 61131-3 — Langages de programmation PLC - Aperçu de la sécurité fonctionnelle IEC 61508 - Kritzinger et al. (2018), Jumeau numérique dans la fabrication (IFAC) - Tao et al. (2019), Jumeau numérique dans l'industrie (IEEE TII)