À mesure que les procédés de traitement de l’eau sont devenus plus exigeants — évaporation-cristallisation à rejet liquide zéro, eau ultrapure de qualité semi-conducteur, séparation profonde des sels et détoxication des métaux lourds pour des effluents industriels difficiles — la couche d’automatisation qui les sous-tend a dû évoluer en conséquence. Deux architectures dominent ce terrain depuis des décennies : le système de contrôle distribué (DCS) et l’automate programmable (PLC). Le matériel et le logiciel ont convergé quelque peu au fil des années, donnant naissance à des plateformes DCS hybrides et à des contrôleurs d’automatisation programmables (PAC) qui brouillent la frontière sur le papier. Mais sous cette convergence, les deux architectures reposent toujours sur des postulats différents en matière de structure de base de données, d’ordonnancement des tâches, de redondance et de profondeur des boucles de régulation — des différences qui pèsent bien plus lourd que le vieux raccourci « le PLC gère le tout-ou-rien, le DCS gère l’analogique » ne le laisse entendre.
Deux philosophies concurrentes : la machine et le procédé
L’héritage du PLC, centré sur la machine. La filiation du PLC remonte au remplacement de la logique à relais sur les chaînes de montage automobile. Il a été conçu pour traiter une logique discrète rapide et déterministe, avec une attention centrée sur des équipements pris individuellement — une pompe, une vanne, un racleur — et sur leurs transitions d’état, leur séquencement et leurs verrouillages de sécurité. Son modèle mental est entrée, logique, sortie, et il privilégie la vitesse de réponse ainsi qu’une autonomie autosuffisante au sein d’un seul contrôleur.
L’héritage du DCS, centré sur le procédé. Le DCS est né dans les industries pétrochimiques et de procédés continus, conçu pour piloter de vastes procédés physico-chimiques à l’échelle de l’usine — évaporation thermique, extraction, réaction continue — comme un système fluidique unique et indivisible. Son modèle mental est celui de l’équilibre du procédé, de la régulation multi-boucles et de la supervision à l’échelle de l’installation ; il privilégie le couplage dynamique entre variables, la précision en régime stationnaire du contrôle analogique, et une cohérence absolue des données sur l’ensemble du site.
Architecture de base de données : un modèle unifié contre deux systèmes assemblés
Un DCS est bâti de haut en bas autour d’une base de données globale unique. Dans l’environnement d’ingénierie, un tag, son type de variable, son adresse d’E/S matérielle, ses seuils d’alarme, ses unités d’ingénierie, ses paramètres d’historisation et ses synoptiques HMI sont tous liés au sein de la même base de données unifiée. Lorsqu’un ingénieur définit un bloc PID ou un bloc de contrôle de vanne au niveau du contrôleur, le système génère automatiquement le synoptique opérateur correspondant, l’élément de tendance et l’entrée du journal d’alarmes. Toute modification en ligne de la logique ou des propriétés d’une variable se propage à tous les nœuds concernés sans étape de synchronisation distincte, ce qui réduit fortement le risque de désynchronisation des tags qui mine les projets d’ingénierie de longue durée.
Un PLC, à l’inverse, a traditionnellement recours à une base de données centrée sur le matériel, construite du bas vers le haut. Son cœur est un contrôleur autonome exécutant une logique à haute vitesse, et sa base de données est fondamentalement une cartographie mémoire matérielle — des adresses mémoire ou des tags indépendants. Le PLC et le système de supervision (SCADA/HMI) sont généralement deux produits logiciels entièrement séparés. Les ingénieurs définissent les E/S et les variables intermédiaires dans l’environnement du PLC, puis mappent ces variables dans la base de données propre au système SCADA via l’OPC (Open Platform Communications) ou un pilote de communication dédié. Cette structure à double base de données signifie que les conversions de type de données, les modifications de seuils d’alarme et les paramètres d’archivage des tendances doivent tous être configurés et maintenus deux fois — une fois dans le PLC, une fois dans le SCADA. Si l’adresse mémoire d’une variable change côté PLC, le côté SCADA doit être remappé manuellement, sous peine de rupture de communication ou de valeur faussée en silence.
Ordonnancement des tâches : cycles de scrutation fixes contre multitâche en tranches de temps
Un PLC fonctionne selon une exécution cyclique basée sur la scrutation : échantillonnage des entrées, balayage de la logique du programme, rafraîchissement des sorties et gestion des communications, selon une boucle fixe en quatre étapes. Les temps de scrutation se situent typiquement dans la plage à (environ 1-10 ms), principalement déterminés par le nombre de lignes de code que le cycle doit exécuter. Cela confère au PLC un excellent déterminisme temporel et un débit très rapide pour la logique discrète — exactement ce dont ont besoin les verrouillages à haute vitesse et le contrôle séquentiel.
Un DCS fonctionne au contraire selon un ordonnancement multitâche, en tranches de temps, piloté par interruptions. La logique de contrôle est répartie en tâches périodiques dotées de priorités d’exécution différentes : les verrouillages de sécurité et la logique haute vitesse reçoivent la priorité la plus élevée (un cycle de 50 ms, par exemple), tandis que les régulations PID continues complexes, le contrôle de découplage et les algorithmes de contrôle de procédé avancé (APC/MPC) tournent sur des tâches périodiques de priorité inférieure (cycles de 200-500 ms). C’est ce modèle d’ordonnancement qui empêche un CPU de bégayer ou de déclencher un dépassement de temporisateur de surveillance (watchdog) lorsqu’il pilote plusieurs centaines, voire plusieurs milliers, de boucles PID simultanées dans un grand procédé continu.
Redondance : architecture native du système contre module additionnel
La haute disponibilité est tout l’enjeu du contrôle de procédé, et le DCS et le PLC diffèrent fondamentalement sur la façon — et la transparence avec laquelle — ils l’assurent.
Un DCS a été conçu dès l’origine pour une production ininterrompue, 24 heures sur 24 et 365 jours par an ; sa redondance est donc native au niveau du système. Les contrôleurs, les modules d’alimentation, le bus de contrôle de procédé, le bus d’E/S et les voies d’E/S individuelles sont généralement construits avec une bascule à chaud sans coupure. Les contrôleurs primaire et de secours restent synchronisés à la milliseconde près via une liaison matérielle dédiée de mise en miroir de la mémoire — état d’exécution, variables intermédiaires, image mémoire, tout y passe. Si le contrôleur primaire subit une panne matérielle ou une perte d’alimentation, le secours prend le relais sans à-coup : aucune discontinuité sur aucune sortie analogique, aucun soubresaut au niveau de la vanne de régulation, et aucun code supplémentaire de synchronisation de redondance à écrire pour l’ingénieur. Le vote tolérant aux pannes au niveau de la carte et de la voie (schémas 1oo2, 2oo3) est généralement intégré directement dans le matériel et le logiciel de configuration.
La redondance d’un PLC est généralement assemblée à partir de modules de redondance matérielle externes, de châssis à double CPU et de modules de communication de redondance dédiés. Les PLC modernes de moyenne à grande taille peuvent tout à fait atteindre une bascule à chaud du contrôleur, mais le degré de fluidité réel de cette bascule, et la part de celle-ci prise en charge de manière transparente par la plateforme, dépendent fortement de l’implémentation spécifique. Dans une configuration de redondance PLC typique, les ingénieurs doivent souvent configurer explicitement des blocs de synchronisation de données, mapper des drapeaux d’état et, dans certains cas, gérer eux-mêmes le comportement de maintien de modules spécifiques — une carte de sortie analogique, par exemple — pendant la transition de bascule.
Quel que soit l’endroit où cette bascule finit par se répercuter, elle se situe en aval de l’organe final de régulation proprement dit. Quelle que soit l’architecture qui émet la commande, la vanne de régulation ou la pompe de dosage qui la reçoit a son propre problème de dimensionnement distinct — le sélecteur d’actionneurs pneumatiques de ce site traite spécifiquement cet aspect.
Profondeur des algorithmes de contrôle
La bibliothèque de contrôle de procédé du DCS. Un DCS est livré avec une vaste bibliothèque de blocs de contrôle de procédé d’ordre élevé, éprouvés industriellement. Son bloc PID intègre nativement l’anti-emballement (anti-windup), le transfert manuel/automatique sans à-coup, la compensation anticipative (feedforward), le contrôle de ratio, le gain adaptatif, les prédicteurs de Smith pour les retards fixes, ainsi que des algorithmes de découplage multivariable. Configurer un PID en cascade ou un PID anticipatif-rétroactif consiste essentiellement à relier deux broches de blocs fonctionnels ; l’algorithme gère en interne le suivi d’état maître/esclave et la logique de commutation manuel/automatique.
Comment un PLC implémente les mêmes calculs. Un PLC propose lui aussi un bloc fonctionnel PID de base, mais au-delà de cela, il ne calcule typiquement que la formule PID standard en temps discret :
Dès que le procédé nécessite un découplage multivariable, une superposition anticipative ou une commutation d’état manuel/automatique, l’ingénieur doit écrire du code supplémentaire en texte structuré (ST) pour gérer manuellement le verrouillage de l’état intégral, l’écrêtage de sortie et la gestion des variables de suivi. La moindre lacune dans cette logique tend à se traduire par un à-coup de sortie de contrôle précisément au moment du transfert manuel/automatique, que la vanne de terrain ressent comme une secousse brutale.
Trois dimensions du cycle de vie d’ingénierie qui déterminent le véritable gagnant
Au-delà des différences d’architecture informatique, c’est « l’ergonomie » et l’expérience opérationnelle au quotidien d’un système de contrôle sur l’ensemble du cycle de vie d’un projet qui déterminent réellement si un choix était le bon.
Facilité d’ingénierie et de mise en œuvre
L’ergonomie porte sur la vitesse de développement — de la conception d’ingénierie et de l’écriture de la logique, en passant par la configuration des écrans, jusqu’à la mise en service sur site.
Pour la configuration des boucles de contrôle, la riche bibliothèque de blocs fonctionnels d’un DCS — anti-emballement, transfert sans à-coup, anticipation, contrôle de ratio, découplage multivariable, tout est intégré — permet à un ingénieur de configurer une boucle complexe essentiellement en glissant des connexions entre blocs préconstruits et en renseignant des paramètres. Un PLC, ne disposant que d’un bloc PID de base, exige des ingénieurs qu’ils écrivent du code supplémentaire en schéma à contacts (LD) ou en texte structuré (ST) pour la cascade, l’anticipation ou le découplage, en gérant manuellement l’emballement intégral, la transition sans à-coup et la fiabilité des valeurs aberrantes — une barre de développement plus élevée pour des résultats moins standardisés.
Pour le développement de l’HMI, un DCS est extrêmement efficace au niveau de la configuration système : ajoutez un nouveau bloc fonctionnel pompe ou vanne au contrôleur, et l’interface opérateur hérite et génère automatiquement un synoptique standard — état de marche, commutateur manuel/automatique, texte d’alarme de défaut, tendance en temps réel, tout y est. Un PLC exige au contraire un « double travail » : après avoir écrit la logique de contrôle dans l’environnement du PLC, l’ingénieur doit ouvrir séparément le logiciel SCADA, dessiner manuellement les graphiques de la vanne, construire manuellement le mappage de communication des tags, et écrire manuellement les scripts de fenêtres contextuelles et la logique de déclenchement des alarmes pour le pupitre opérateur.
Pour l’intégration de skids OEM, la situation s’inverse. Parce qu’un DCS repose sur une base de données unifiée et une architecture matérielle particulière, y intégrer une armoire de contrôle indépendante provenant d’un fournisseur de skid tiers — un skid de pompe haute pression, un skid de générateur d’ozone — tend à être laborieux ; les données du tiers doivent généralement être mappées via une passerelle générique Modbus ou Profinet, ce qui rompt la cohérence de la base de données native. Un PLC, en revanche, est intrinsèquement ouvert et modulaire : l’écrasante majorité des ensembles skid OEM sont nativement construits autour d’un PLC comme contrôleur local, de sorte qu’à l’échelle de l’intégration de l’usine, les systèmes PLC peuvent relier les ensembles skid de différents fournisseurs sur un bus industriel commun avec relativement peu de friction.
Facilité d’exploitation et de maintenance
La maintenabilité détermine directement le délai moyen de rétablissement (MTTR) d’une usine après un défaut imprévu, ainsi que la part d’exploitation quotidienne qui se déroule sans aucune interruption.
Pour la programmation et le téléchargement en ligne, la raison d’être même d’un DCS est de ne jamais s’arrêter. Il prend en charge une véritable compilation en ligne globale et incrémentale, et un téléchargement sans à-coup : lorsqu’un ingénieur modifie la logique de contrôle, retouche un PID ou ajoute une nouvelle variable, le téléchargement n’a aucun effet sur l’état d’exécution du CPU du contrôleur — les sorties vers les vannes de terrain restent lisses, les boucles PID ne sautent pas, et l’écran SCADA ne clignote même pas au niveau de sa liaison de communication. Un PLC moderne de moyenne à grande taille prend en charge la modification en ligne de certains segments de code, mais toute modification de la structure d’un bloc de données, de la configuration matérielle, ou une reconstruction logique à grande échelle, force généralement un téléchargement complet, ce qui peut placer le PLC en mode d’arrêt de quelques millisecondes à quelques secondes, ou interrompre brièvement la communication avec le SCADA — un risque réel dans une étape de procédé chimique ou thermique fortement dangereuse et fonctionnant en continu, comme un évaporateur MVR, où ce type d’interruption peut déclencher un arrêt de sécurité.
Pour le diagnostic et l’échange à chaud, un DCS maintient des zones strictes de confinement des défauts depuis le niveau de la voie, en passant par le niveau de la carte, jusqu’au niveau du bus, avec une capacité native d’échange à chaud (RIOP). Si un court-circuit dans un instrument de terrain détruit une voie d’entrée analogique, la protection interne de limitation de courant de la carte et son isolation optique empêchent le défaut de se propager vers une voie voisine ou vers le bus de fond de panier, et la carte peut être remplacée à chaud sans réinitialisation logicielle. Les plateformes DCS fournissent généralement aussi un enregistrement système des séquences d’événements (SOE) conforme à la norme de gestion des alarmes ISA-18.2, avec des résolutions descendant jusqu’à 1 ms, ce qui facilite grandement la recherche de la cause première réelle d’un incident. Les cartes d’E/S distribuées d’un PLC prennent elles aussi couramment en charge l’échange à chaud, mais l’information de diagnostic doit généralement être extraite par l’ingénieur en appelant un bloc fonctionnel système de diagnostic dédié (SFC/SFB) dans le programme PLC, puis en transmettant explicitement le résultat interprété au SCADA. Si cette routine de diagnostic n’a jamais été écrite, un défaut au niveau d’une carte de terrain peut n’apparaître dans le SCADA que sous la forme abstraite et peu précise d’une simple « perte de communication ».
Évolutivité et pérennité
La capacité de mise à niveau détermine à quel point un actif d’automatisation conserve sa valeur, et combien coûte un renouvellement technologique, sur un cycle de vie d’usine de 10 à 20 ans.
Pour la compatibilité ascendante et le cycle de vie, les fournisseurs de DCS s’engagent en règle générale sur une norme de compatibilité ascendante étonnamment stricte — les cycles de vie système typiques s’étalent sur 15-20 ans ou plus. Un contrôleur DCS de nouvelle génération peut souvent accueillir une carte d’E/S déployée vingt ans plus tôt, et un projet d’ingénierie plus ancien peut migrer vers l’avant avec peu de perturbations. Cette évolution en douceur réduit sensiblement le coût en capital et le risque technique des futures mises à niveau d’automatisation d’une usine. Le cycle d’itération d’un PLC est plus court — les cycles de vie matériels typiques s’étalent sur 8-12 ans — et les composants électroniques grand public qu’il embarque sont retirés du marché plus rapidement. Un saut générationnel d’une famille de plateformes PLC vers sa succession s’accompagne couramment d’un changement complet de protocole de bus, de logiciel de programmation et de fond de panier matériel, de sorte que la migration d’un programme nécessite généralement des outils de conversion dédiés, voire une réécriture pure et simple de la logique.
Pour l’extension matérielle et la topologie réseau, l’extension d’un DCS est généralement construite autour d’une architecture réseau de procédé fixe et redondante : l’ajout d’une nouvelle station d’E/S déportée permet au système d’attribuer automatiquement une adresse de nœud et de compléter la configuration du routage, ce qui est standardisé mais s’accompagne de contraintes de topologie assez rigides. Un PLC dispose d’une flexibilité réseau industrielle nettement supérieure, prenant en charge côte à côte Profinet, EtherNet/IP, Modbus TCP, EtherCAT et d’autres protocoles. Lorsqu’un système de petite à moyenne taille doit être étendu, ou qu’un équipement hétérogène tiers — un variateur de fréquence, un analyseur de qualité d’eau intelligent, un robot — doit être ajouté, l’adaptabilité réseau d’un PLC constitue l’option la plus agile.
Seize dimensions, côte à côte
| Dimension | DCS | PLC |
|---|---|---|
| Philosophie de conception | Centrée sur le procédé, contrôle de procédé continu | Centrée sur la machine, contrôle logique discret |
| Architecture de base de données | Base de données globale unique et unifiée | Base de données propre au contrôleur, mappée vers le SCADA via OPC/pilote |
| Type de contrôle dominant | Analogique, boucles PID complexes, découplage multivariable | Discret/numérique, logique haute vitesse, contrôle séquentiel |
| Exécution de la logique | Ordonnancement multitâche par tranches de temps, tâches périodiques | Exécution cyclique à scrutation fixe |
| Temps de scrutation/réponse | Cycle typique : 50 ms – 500 ms | Très rapide : 1 ms – 10 ms |
| Facilité d’ingénierie | Bibliothèque d’algorithmes native riche ; synoptiques HMI et alarmes générés automatiquement | Bibliothèque d’algorithmes de base, nécessite du code ladder/ST ; HMI configuré séparément |
| Confort d’exploitation/maintenance | Téléchargement en ligne incrémental global sans à-coup ; isolement natif des défauts au niveau des voies | Les téléchargements profonds peuvent forcer un arrêt ; les diagnostics exigent des blocs fonctionnels codés manuellement |
| Redondance | Redondance intégrale native au niveau système (alimentation, contrôleur, réseau, E/S), sans à-coup | Redondance modulaire optionnelle, nécessitant des modules dédiés et une synchronisation au niveau du code |
| Capacité PID analogique | Bibliothèque riche (anticipation, cascade, prédicteur de Smith, MPC), fort découplage | Bloc PID de base, découplage multivariable comparativement difficile |
| HMI | Intégration native profonde ; synoptiques vanne/pompe/PID générés automatiquement | Logiciel SCADA indépendant, écrans et communication des tags construits séparément |
| Cycle de vie et compatibilité | 15-20 ans et plus, forte compatibilité matérielle ascendante, montées en version fluides | 8-12 ans, itération plus rapide, migration générationnelle nécessitant conversion/reconfiguration |
| Efficacité de développement d’ingénierie | Très rapide pour les grands procédés continus, forte réutilisabilité, modifications en ligne sans à-coup | Efficace pour la logique des équipements discrets ; les grands procédés nécessitent un mappage manuel important des tags |
| Topologie réseau et bus | Ethernet industriel hybride ouvert/fermé, réseaux en anneau/doubles à haute redondance | Très ouvert, prend en charge Profinet, EtherNet/IP, Modbus TCP, entre autres |
| Isolement des défauts | Zones strictes de confinement des défauts au niveau du contrôleur et du bus E/S | Le défaut d’une seule carte peut se propager aux autres modules via le bus de fond de panier interne |
| Échelle typique | Nombre d’E/S supérieur à ~2 000 points, forte part analogique (>30 %), systèmes à l’échelle de l’usine | De quelques dizaines à plusieurs milliers de points, distribution flexible, à dominante discrète |
| CAPEX initial | Plus élevé (coûts de contrôleur et de licences logicielles) | Plus faible (excellent rapport prix/performance matériel, avantage net pour les petits systèmes) |
Faire correspondre l’architecture au segment du traitement de l’eau
Les différents procédés de traitement de l’eau présentent des natures physico-chimiques fondamentalement différentes, et c’est précisément ce qui détermine la bonne architecture de contrôle.
L’eau potable municipale et le traitement des eaux usées sont géographiquement dispersés et dominés par des signaux discrets, d’où le recours à des PLC en réseau avec une couche SCADA centrale. Une station municipale de traitement des eaux usées s’étend sur des stations de relevage, des dégrilleurs, des dessableurs, des réacteurs biologiques — A²/O, MBR, ou autre — des clarificateurs secondaires et une déshydratation des boues. L’installation est géographiquement dispersée, avec un degré élevé d’autonomie des sous-stations ; les équipements (pompes, racleurs, vannes) sont dominés par un contrôle en tout-ou-rien, et la logique de contrôle relève surtout d’une commutation séquentielle fondée sur le niveau ou le temps. Les boucles PID (contrôle de l’oxygène dissous du bassin d’aération, contrôle du taux de dosage) sont relativement peu nombreuses et largement indépendantes les unes des autres. L’architecture quasi universelle est celle d’un système de supervision SCADA central au-dessus de sous-stations PLC de terrain régionales : chaque zone de procédé dispose de sa propre armoire PLC gérant les verrouillages d’équipements locaux, tandis que le SCADA agrège les données via un Ethernet industriel — une structure présentant un avantage net tant au niveau du coût en capital que de la flexibilité de l’implantation réseau.
Les eaux usées industrielles à forte difficulté de traitement et le rejet liquide zéro relèvent d’un procédé thermodynamique et chimique fortement couplé, et c’est là le terrain du DCS. Dans les systèmes ZLD construits autour des effluents de l’industrie du charbon, de la pétrochimie ou de la désulfuration des fumées, la chaîne de procédé enchaîne prétraitement, concentration membranaire et évaporation-cristallisation thermique (MVR ou évaporation à effets multiples). Le niveau de l’évaporateur, la pression de vapeur secondaire, le débit de la pompe de circulation et la sursaturation de la liqueur mère interagissent fortement et de façon dynamique entre eux. Les E/S analogiques représentent typiquement 30-50 % du total des E/S, avec un grand nombre de boucles de contrôle en cascade, anticipatives et de découplage. Si un contrôleur tombe hors ligne ou qu’une boucle PID commence à osciller, l’évaporateur peut s’entartrer ou la pompe de circulation forcée peut caviter et se boucher — et le coût d’un arrêt, d’un nettoyage puis d’un redémarrage est sévère. Un DCS natif est ici quasiment incontournable : sa bibliothèque d’algorithmes de découplage, son ordonnancement multitâche déterministe, sa base de données globale unifiée et sa modification en ligne sans à-coup sont ce qui permet à un système ZLD de fonctionner en continu à un état stationnaire.
L’eau ultrapure (UPW) pour semi-conducteurs exige un contrôle des impuretés au niveau de la partie par billion et une résistivité approchant la limite théorique de . Un système UPW est construit à partir d’un grand nombre de skids OEM préfabriqués et densément assemblés — filtration sur sable, RO, EDI, lit mélangé de polissage — et nécessite une surveillance de la qualité de l’eau à très haute fréquence ; dès que la qualité de l’eau sort de la spécification, une vanne doit se fermer en quelques millisecondes pour protéger la ligne de production de plaquettes en aval. L’architecture quasi universelle est hybride : des skids PLC distribués à haute vitesse plus un DCS ou SCADA de supervision centrale. Chaque skid est développé et mis en service de manière indépendante par son fournisseur OEM autour d’un PLC, ce qui assure une efficacité de livraison modulaire et une réponse de protection à l’échelle de la milliseconde ; la couche de supervision centrale est ensuite unifiée dans le DCS de l’usine ou un grand système SCADA, offrant une planification de l’équilibre hydrique à l’échelle de l’installation et une traçabilité de la qualité. L’article de ce site consacré à la contamination à l’état de traces de l’eau ultrapure pour semi-conducteurs approfondit le volet pureté de ce tableau.
Le traitement des eaux usées à métaux lourds et spéciales — effluents miniers, métallurgiques et de galvanoplastie chargés en arsenic, antimoine, plomb, cadmium ou cyanure — demande deux choses à la fois : un dosage chimique extrêmement précis (ajusté en continu en fonction de l’ORP, du pH et de la concentration en métaux lourds à l’entrée, une boucle de contrôle que le calculateur de dosage chimique de ce site peut aider à dimensionner), et des verrouillages de sécurité extrêmement fiables, puisqu’un rejet non conforme doit être coupé et redirigé vers un bassin de confinement d’urgence en quelques secondes. L’architecture typique est un grand PLC à double redondance à chaud, ou un micro-DCS, choisi spécifiquement pour son fort traitement analogique associé à une redondance matérielle.
Trois cas de terrain
Cas 1 : ZLD à forte salinité et cristallisation par séparation des sels dans l’industrie du charbon
Le projet de rejet liquide zéro d’un grand complexe carbochimique, dimensionné à 12 000 m³/j, traite un influent chargé à environ 42 000 mg/L de TDS (dont un sulfate d’environ 17 000 mg/L et un chlorure d’environ 11 000 mg/L) à travers une filière associant nanofiltration à deux étages pour la séparation des sels, cristallisation évaporative du sulfate de sodium, concentration par RO et cristallisation évaporative du chlorure de sodium — récupérant au final du sulfate de sodium à une pureté et du chlorure de sodium à une pureté , avec une fraction de sels mixtes d’environ 10 % seulement.
Au début du projet, une option PLC+SCADA a été testée en face-à-face contre un DCS. Dans l’étape d’évaporation-cristallisation par circulation forcée MVR, le DCS a montré trois avantages décisifs :
Découplage thermodynamique complexe. Le niveau du cristallisoir, la pression de vapeur et le débit de la pompe de circulation interagissent fortement. Le DCS faisait tourner un algorithme d’anticipation-cascade via son module intégré de contrôle de procédé avancé (APC) :
fonctionnant en régime stationnaire sur un cycle de contrôle de 200 ms et maintenant précisément la sursaturation de cristallisation dans la zone métastable. Le système PLC testé en parallèle, dépourvu d’algorithme de découplage natif, montrait un pompage sévère entre les boucles PID, déclenchant de fréquentes surpressions de l’évaporateur.
Modifications en ligne sans à-coup. Pendant la phase de montée en cadence et de mise au point, la logique de ratio de dosage nécessitait des ajustements fréquents. La compilation en ligne incrémentale globale du DCS prenait effet sans accroc, sans perturbation d’aucune sortie PID. Dans le test PLC, la tentative de téléchargement d’un bloc de données modifié a déclenché une brève déconnexion du SCADA, et la vanne de dosage est momentanément retombée à zéro.
Isolement matériel au niveau des voies. En cours d’exploitation, un court-circuit dans le densimètre de la liqueur mère a provoqué un reflux à haute pression. L’isolement de voie de la carte DCS a réussi à bloquer la propagation du défaut ; le contrôleur a automatiquement maintenu sa sortie précédente, levé une alarme, et permis le remplacement à chaud de la carte défaillante, sans arrêt (RIOP natif).
Cas 2 : système d’eau ultrapure d’une usine de semi-conducteurs
Le système UPW d’une usine de plaquettes de 12 pouces, dimensionné à 15 000 m³/j, fonctionne selon une architecture « skids PLC plus SCADA/DCS central ».
Protection à l’échelle de la milliseconde. Lorsqu’un analyseur TOC en ligne, situé au point d’usage, détecte un écart de qualité de l’eau (au-delà d’environ 2 ppb), le PLC local du skid exécute une routine d’interruption terminale cyclique fixe de 5 ms, achevant l’action d’une vanne d’arrêt trois voies en 40 ms — bloquant avec succès toute eau non conforme avant qu’elle n’atteigne la ligne de production.
Livraison modulaire OEM. Dix-huit skids indépendants (filtration sur sable, RO, EDI, lit mélangé) ont chacun été programmés et mis en service en interne par différents fournisseurs à l’aide d’un PLC, puis connectés au système central sur site via les protocoles standard Profinet et OPC UA — comprimant nettement le calendrier de construction de l’usine.
Cas 3 : station municipale de traitement des eaux usées de 100 000 m³/j, modernisation intelligente
Une station municipale de traitement des eaux usées de 100 000 m³/j a reconstruit son installation d’origine, composée de « sept sous-stations PLC indépendantes plus SCADA », en un système de contrôle hybride unifié.
Distribution des contrôleurs. Avant la modernisation : sept sous-stations PLC indépendantes sans communication directe de contrôleur à contrôleur. Après : une architecture de contrôle distribué intégrée sur une plateforme unifiée.
Gestion de la base de données. Avant : sept bases de données PLC distinctes plus une base de données SCADA, chacune configurée indépendamment. Après : une base de données d’ingénierie unique, centralisée et unifiée.
Contrôle de l’oxygène dissous en aération. Avant la modernisation, l’OD était maintenu par un simple contrôle marche/arrêt temporisé, oscillant sur environ . Après la modernisation, l’OD fonctionnait selon un PID anticipation-cascade, suivant :
maintenant l’OD stable à environ de la consigne.
Maintenance et extension. Avant la modernisation, la modification d’une variable exigeait de configurer les deux extrémités et un bref arrêt pour le téléchargement ; après, l’installation prend en charge le téléchargement en ligne global sans à-coup, et la maintenance en est considérablement facilitée.
Énergie. Après la modernisation, la consommation énergétique globale des surpresseurs a chuté de 12 %, et la consommation de réactifs de dosage de 8 %.
Un modèle de décision quantitatif
Le choix entre DCS et PLC ne devrait pas relever d’une préférence subjective — il peut être noté directement en fonction des paramètres du projet. Définissons un indice de sélection :
où chaque paramètre est défini comme suit :
- : part des E/S analogiques (attribuer 1 si supérieure à 30 %, sinon 0).
- : nombre de boucles PID complexes/en cascade/découplées (attribuer 1 si supérieur à 30 boucles, sinon 0).
- : besoin de cohérence globale des données et de modification en ligne sans à-coup (attribuer 1 pour une forte exigence, 0 pour aucune).
- : coût d’une interruption de production continue (attribuer 1 si les pertes liées à un arrêt sont très élevées, 0 si l’arrêt est tolérable).
- : proportion d’équipements en skids OEM tiers indépendants (attribuer 1 si la part des skids dépasse 50 %, sinon 0).
- : coefficients de pondération (recommandés : ).
Règle de décision :
- Si : recommandation forte d’un système DCS.
- Si : recommandation forte d’une architecture PLC en réseau + SCADA.
- Si : recommandation d’un système de contrôle hybride (Hybrid DCS/PAC).
Coût total de possession
Le coût total de possession (TCO) combine les dépenses d’investissement (CAPEX) et les dépenses d’exploitation (OPEX) :
Comment évolue l’équilibre des coûts. Lors de l’achat initial, les coûts de matériel et de licences logicielles d’une solution PLC+SCADA sont typiquement inférieurs de 30-50 % à ceux d’un DCS, et cet avantage CAPEX est particulièrement marqué pour les projets de petite à moyenne taille. Pendant l’ingénierie et la mise en service, pour des procédés complexes à forte intensité analogique comme le ZLD, la base de données globale et la bibliothèque d’algorithmes native d’un DCS peuvent raccourcir le temps de mise en service sur site d’environ 40 %, réduisant le coût de main-d’œuvre d’ingénierie. Sur une durée d’exploitation de 10 à 15 ans, le téléchargement en ligne sans à-coup, l’isolement des défauts au niveau des voies, la compatibilité ascendante en douceur et la capacité d’optimisation de procédé (économies d’énergie, réduction de consommation) d’un DCS réduisent fortement les pertes liées aux arrêts et les coûts de maintenance — et en pratique, le coût total de possession d’un DCS passe typiquement sous celui d’un système PLC exigeant des reconfigurations fréquentes autour de la barre des 5-7 ans.
Conclusion
Sur le vaste paysage de l’automatisation du traitement de l’eau, le DCS et le PLC ne sont pas tant des concurrents que deux architectures enracinées dans des gènes techniques différents, chacune accomplissant un travail que l’autre ne peut remplacer :
La force principale du PLC réside dans l’efficacité de la logique discrète, le déterminisme temporel et l’agilité modulaire. Dans l’alimentation en eau et l’assainissement municipaux, les sous-stations de stations d’épuration des eaux usées, et les skids autonomes d’eau ultrapure, une architecture PLC associée à un SCADA constitue le choix le plus rentable et le plus flexible à déployer.
La force principale du DCS réside dans la continuité du contrôle de procédé, la cohérence globale des données et la tolérance aux pannes à haute disponibilité. Dans les eaux usées industrielles à rejet liquide zéro, l’évaporation-cristallisation et les autres procédés thermiques et chimiques complexes, un DCS est l’outil qui maintient une usine entière en fonctionnement sûr, stable et continu.
Pour les futurs projets d’automatisation du traitement de l’eau, le choix du système devrait s’affranchir de tout parti pris envers une étiquette matérielle particulière, examiner en profondeur la nature physico-chimique du procédé lui-même, et trouver le meilleur équilibre entre facilité d’ingénierie, maintenabilité, évolutivité future et coût total de possession.
Pour aller plus loin
- International Society of Automation, ISA-18.2 — Management of Alarm Systems for the Process Industries — la référence normative pour l’enregistrement des séquences d’événements et les pratiques de gestion des alarmes évoquées ci-dessus.
- International Electrotechnical Commission, IEC 61131-3 — Programmable Controllers, Part 3: Programming Languages — la norme régissant la programmation PLC en schéma à contacts et en texte structuré.
- International Electrotechnical Commission, IEC 61508 — Functional Safety of Electrical/Electronic/Programmable Electronic Safety-Related Systems — la référence fondamentale pour les considérations de verrouillage de sécurité et de SIL dans les applications de dosage et de verrouillage à haut risque.
- International Society of Automation, ISA-95 — Enterprise-Control System Integration — le cadre normatif pour l’architecture de données entre les systèmes de contrôle d’usine et les systèmes d’entreprise.