L'écriture de consignes issues d'une optimisation IA vers un automate (PLC) en station d'épuration (STEP) est un point d'architecture critique : arbitrage des modes Manuel/Auto, interverrouillages, validation des mesures, limitations dynamiques (rampe, rate limit), transitions sans à-coup et stratégies de repli. Cet article propose une démarche pratique, orientée terrain, pour sécuriser l'interface IA-PLC et éviter les oscillations de régulation en aération, pompage et dosage de réactifs.
Pourquoi l'interface IA-PLC est un point critique
De l'optimum calculé à la consigne réellement appliquée
En station d'épuration (STEP), une IA peut proposer des consignes optimisées (énergie, performance épuratoire, coûts d'exploitation). Sur le terrain, la valeur réelle se joue dans un point unique : l'écriture de la consigne sur l'automate (PLC), qui pilote les actionneurs (soufflantes/surpresseurs, vannes d'air, pompes, injection de réactifs, postes de relèvement).
Cette interface ne doit pas se limiter à un « write tag » : elle doit intégrer une hiérarchie de priorités, des garde-fous déterministes et une gestion de dynamique pour éviter instabilités et à-coups. En exploitation, la robustesse perçue conditionne directement l'acceptation du pilotage avancé par les équipes de conduite.
Chez PURECONTROL SAS, l'industrialisation d'approches IA sur l'assainissement s'appuie précisément sur cette séparation des rôles : l'IA optimise et le PLC arbitre et sécurise (modes, interverrouillages, contraintes, repli), afin d'obtenir une performance exploitable 24/7 sur des procédés soumis à variabilité hydraulique et organique.
Les architectures STEP combinent généralement boucles PID, séquences (type SFC/GRAFCET) et interverrouillages. Pour le développement logiciel automate, le cadre de langages industriels est décrit par l'IEC 61131-3 (Programmable controllers – Part 3: Programming languages). Le message clé : l'IA s'intègre au-dessus de ces briques, mais les mécanismes de sûreté de fonctionnement doivent rester dans le PLC et rester explicites.
Cybersécurité OT : ne pas transformer l'écriture de consigne en point d'entrée
1) Priorités de modes ambiguës (et perte de confiance)
Un cas fréquent : un équipement passe en manuel local (pupitre/armoire), tandis qu'une supervision ou un module d'optimisation continue d'écrire des consignes amont. Sans arbitrage explicite, cela génère :
Conflits de commande (consigne « écrite » mais non appliquée, puis reprise brutale au retour en auto),
Transitoires violents au changement de mode (absence de transition sans à-coup),
Opacité d'exploitation (les opérateurs ne savent plus « qui commande »).
2) Défauts de communication et dérives de capteurs
Sans règles de validation et de repli, une perte de communication peut figer une consigne obsolète, et une dérive de mesure (ex. encrassement sonde O2) peut pousser l'optimisation dans une direction erronée. Les limites « statiques » (min/max) ne suffisent pas : il faut des limites dynamiques et des critères d'éligibilité liés au contexte procédé.
3) Oscillations et chattering (instabilité multi-boucles)
Les oscillations apparaissent lorsqu'on superpose des dynamiques différentes : décision IA (minutes), PID (secondes à minutes), actionneurs (inerties mécaniques), procédé (temps de séjour, mélange). Exemples typiques :
Aération : oscillations DO (oxygène dissous) et cycles courts soufflantes/VFD, avec impacts énergie et usure.
Déphosphatation : surdosage/corrections successives si la mesure (ou son proxy) présente latence et bruit.
Postes de relèvement : alternances marche/arrêt trop rapides, surintensités et risques hydrauliques en événements pluvieux.
Architecture recommandée : une consigne IA encadrée
Principe : l'IA demande, le PLC dispose
Une écriture fiable repose sur une règle simple : la consigne IA n'est jamais appliquée « brute ». Elle est reçue comme une demande, puis transformée par le PLC en consigne appliquée après arbitrage des modes, validation des données et limitation de dynamique.
Cette logique est particulièrement adaptée aux déploiements d'optimisation d'aération, de dosage et de pompage portés par PURECONTROL SAS, où l'objectif est d'industrialiser l'intégration dans des architectures PLC/SCADA existantes.
Hiérarchie des modes : manuel toujours prioritaire
Arbitre de modes implémenté côté automate
Une hiérarchie robuste (à adapter au site) peut être structurée ainsi :
Niveau 1 – Manuel local : commande armoire/pupitre, prioritaire sur toute écriture distante.
Niveau 2 – Manuel supervision : forçage SCADA, tracé et horodaté, prioritaire sur l'IA.
Niveau 3 – Automatique PLC : séquences, PID, consignes internes.
Niveau 4 – Optimisation IA : active uniquement si autorisation explicite et conditions d'éligibilité vraies.
En pratique : l'IA écrit une variable de demande (ex. AI_SP_Request), et le PLC calcule SP_Applied via un arbitre. Ce design évite qu'une défaillance amont (service, réseau, supervision) ne « prenne la main » sur l'usine.
Validation et interverrouillages : éligibilité avant performance
Plages statiques, dynamiques et qualité de mesure
Avant toute application, la consigne IA doit passer un « filtre procédé » déterministe :
Plages statiques : min/max équipement (Hz variateur, % vanne, débit max pompe, débit max injection).
Éligibilité capteurs : inhibition pendant nettoyage/maintenance, détection de dérive, capteur en défaut.
Qualité de données : plausibilité, détection de « valeur figée », contrôle de vitesse de variation, gestion valeurs manquantes.
Bonne pratique : dissocier la mesure utilisée par l'IA (qui peut intégrer des proxys/modèles) et la mesure de sécurité PLC (simple, robuste, testée), notamment pour les protections de procédé.
Anti-oscillations : maîtriser la dynamique de consigne
Limiter dSP/dt, filtrer les basculements et gérer les transitions
Pour réduire chattering, cycles courts et instabilités multi-boucles, les mécanismes suivants sont généralement nécessaires :
Rampe de consigne (slew rate) : limitation de dSP/dt (ex. %/min, Hz/min, m3/h/min selon actionneur).
Rate limit + temps minimal entre changements : éviter les mises à jour trop fréquentes par rapport à la constante de temps procédé.
Hystérésis / deadband : empêcher les micro-basculements autour d'un seuil.
Transition sans à-coup : synchroniser les états internes au passage Manuel/Auto/IA pour éviter le « saut » de consigne appliquée.
Anti-windup PID : si un PID existe en aval, éviter l'emballement de l'intégrateur quand l'action est saturée ou bridée.
Exemple d'approche : si l'IA recalcule toutes les 1 à 5 minutes mais que le procédé a une constante de temps de 20 à 60 minutes, le PLC doit imposer une dynamique compatible (rampe + deadband temporel), faute de quoi le système devient « nerveux » sans gain de qualité.
Watchdog et repli : définir un comportement sûr
Expiration de consigne et modes dégradés
Une architecture exploitable doit prévoir explicitement les pannes « ordinaires » : arrêt du service IA, coupure réseau, blocage d'échange, latence anormale. Les briques minimales :
Heartbeat IA-PLC (bit ou timestamp) avec temporisation côté automate.
Expiration de consigne : si la consigne est trop ancienne, retour à une stratégie sûre (consigne opérateur, profil horaire, PID local).
En réseau d'assainissement et postes de relèvement, ce point est critique en épisodes pluvieux : la priorité est la continuité de service et la maîtrise hydraulique, l'optimalité énergétique devenant secondaire pendant la perturbation.
Contrat d'interface PLC/SCADA/IA : standardiser les tags
Rendre l'intégration multi-sites reproductible
Le « contrat » d'interface réduit les ambiguïtés de mise en service et accélère le diagnostic. Un socle de tags typique :
AI_Mode_Reason (codes et libellés compréhensibles terrain)
Cette approche facilite la montée en compétences des équipes automatisme/exploitation et limite les effets « boîte noire ».
Application : aération en boues activées
Cas d'usage et points de réglage typiques
En aération, la consigne IA (ex. consigne DO ou consigne débit d'air) se superpose souvent à un existant (PID DO, cascade débit/pression, séquences soufflantes). Les points clés sont :
Cadence d'écriture cohérente avec la dynamique bassin (mélange + temps de réponse sonde O2).
Rampe et deadband pour éviter les cycles courts sur soufflantes et variateurs.
Repli vers une stratégie interne (PID local) en cas de perte IA.
Dans ce contexte, la solution PurePilot Aération s'inscrit comme une couche d'optimisation qui doit impérativement s'adosser à un PLC « arbitre » robuste (modes, validations, limitations), afin que l'optimisation reste stable et exploitable.
Limites et points de vigilance en exploitation
Instrumentation, multi-objectifs, et gouvernance des modes
Instrumentation : sans plan de maintenance et validation, l'optimisation peut converger vers un optimum basé sur une mesure fausse. Les tests de plausibilité et le mode dégradé ne sont pas optionnels.
Multi-objectif procédé : réduire l'énergie d'aération peut entrer en tension avec nitrification/dénitrification selon température et charge. Les contraintes process (ex. seuils NH4, DO mini, séquences) doivent primer sur l'optimum instantané.
Exploitation : le manuel doit rester simple, prioritaire et traçable. Sans transparence, le système est souvent désactivé, même s'il est performant.
Cybersécurité : segmentation et contrôle des flux, durcissement des passerelles, comptes/roles, et supervision des accès réduisent le risque de commande non autorisée (cf. recommandations ANSSI).
Perspectives
Vers des architectures d'optimisation mieux garanties
À moyen terme, l'évolution la plus utile reste l'industrialisation de schémas de contrôle hiérarchiques, plus formels et mieux auditables, combinant performance et stabilité sans complexifier l'exploitation.
Conclusion : performance IA, mais commande sous contrôle PLC
Les bénéfices attendus quand les garde-fous sont en place
Une IA de pilotage n'apporte de valeur en STEP que si l'interface IA-PLC est conçue comme un système de commande complet : priorités de modes explicites (manuel prioritaire), interverrouillages et validation des données, mécanismes anti-oscillations (rampe, rate limit, hystérésis, transition sans à-coup), watchdog et repli, traçabilité des décisions.
Vous souhaitez sécuriser l'écriture de consignes IA sur vos automates et stabiliser le pilotage (aération, dosage, pompage, réseaux) ? Contactez PURECONTROL SAS pour demander un devis et cadrer une intégration compatible avec vos contraintes d'exploitation et de conformité.
