PLC vs RTU : quelle différence pour la supervision à distance ?
Dans les conversations entre automaticiens et chefs de projet, les termes PLC et RTU sont souvent utilisés de manière interchangeable — ou, à l'inverse, brandis comme s'opposant radicalement. La réalité est plus nuancée : PLC et RTU sont deux familles d'équipements nés pour répondre à des besoins distincts, qui se sont progressivement rapprochés avec l'IIoT, mais qui conservent des différences fondamentales déterminantes pour le choix d'une architecture de supervision à distance.
Ce guide démêle les définitions, compare les deux technologies sur les critères qui comptent réellement et explique comment superviser chacune à distance dans une architecture SCADA ou cloud moderne.
Qu'est-ce qu'un PLC (API) ?
Un PLC (Programmable Logic Controller), appelé API (Automate Programmable Industriel) en français, est un calculateur industriel conçu pour exécuter un programme de contrôle-commande en temps réel sur un process industriel local. Son rôle premier est de traiter des entrées/sorties (capteurs, actionneurs) à une fréquence élevée et d'exécuter une logique de séquencement ou de régulation.
Fonctionnement
Le PLC fonctionne en boucle cyclique : acquisition des entrées, exécution du programme, mise à jour des sorties, recommencer. Le temps de cycle est typiquement de 1 à 100 ms selon la complexité du programme et la puissance de la CPU. Les langages de programmation sont standardisés par la norme IEC 61131-3 : Ladder Diagram (LD), Function Block Diagram (FBD), Structured Text (ST), Instruction List (IL) et Sequential Function Chart (SFC).
Exemples représentatifs
- Siemens : S7-1200, S7-1500, S7-300 (historique)
- Schneider Electric : Modicon M340, M580, M262
- Allen-Bradley (Rockwell) : ControlLogix, CompactLogix, MicroLogix
- Omron : CX-Programmer, NX/NJ Series
- Mitsubishi : MELSEC Q Series, iQ-R Series
Domaines d'application typiques
Un PLC se retrouve partout où il faut exécuter une logique complexe localement : ligne de production automobile, machine d'emballage, cellule de soudure robotisée, convoyeur multi-axes, process agroalimentaire avec gestion de recettes, régulation de température multi-zones.
La caractéristique clé : le PLC est au cœur d'un process local qui ne peut pas se permettre d'attendre une instruction cloud pour prendre une décision en quelques millisecondes.
Qu'est-ce qu'un RTU ?
Un RTU (Remote Terminal Unit — Unité Terminale Distante) est un équipement conçu pour collecter des données de mesure sur un site distant, les concentrer et les transmettre à un système central (SCADA, centre de supervision) via un réseau de communication — historiquement radio ou RTC, aujourd'hui GPRS/4G ou fibre. Sa capacité de traitement local est limitée ; son rôle principal est la télégestion : remonter des informations et, dans certains cas, exécuter des commandes simples reçues du central.
Fonctionnement
Le RTU scrute ses entrées (4–20 mA, tout-ou-rien, impulsions de comptage), stocke les valeurs en mémoire tampon, et les transmet périodiquement ou sur événement vers le SCADA central. En cas de coupure communication, il continue à stocker localement (horodatage embarqué) et transmet les données en différé à la reprise. Cette fonction de mémorisation horodatée est critique dans les applications eau, énergie et télégestion.
Domaines d'application
- Distribution d'eau et assainissement : télécontrôle de stations de pompage, surveillance de réservoirs, détection de fuites
- Distribution d'énergie : sous-stations électriques HTA/HTB, contrôle de postes de transformation
- Gaz : surveillance de postes de livraison, comptage grande distance
- Environnement : stations météo, mesure de débit de cours d'eau, qualité de l'air
- Agriculture : irrigation automatisée, sondes terrain distantes
La caractéristique clé : le RTU est un équipement satellite déployé sur des sites distants et souvent non gardés, dont la fonction principale est de remonter l'état de l'installation vers un centre de contrôle centralisé.
Tableau comparatif PLC vs RTU
| Critère | PLC (API) | RTU |
|---|---|---|
| Puissance de traitement | Élevée — cycles de 1 à 100 ms, logique complexe | Faible à moyenne — traitement simple, pas de régulation multi-axe |
| Interface terrain (I/O) | I/O numériques et analogiques modulaires, haute densité | I/O analogiques (4–20 mA), TOR, comptage impulsion, mesure |
| Protocoles natifs | Modbus TCP/RTU, OPC-UA, PROFIBUS, EtherNet/IP, PROFINET | Modbus RTU, DNP3, IEC 60870-5-101/104, IEC 61968 |
| Consommation électrique | Moyenne à élevée (alimentation 24 V DC, plusieurs ampères) | Faible (conçu pour alimentation solaire/batterie possible) |
| Robustesse environnement | Grade industriel, mais optimisé pour installation fixe sous armoire | Conçu pour sites non gardés, grand froid, chaleur, humidité extrême |
| Usage typique | Automatisme local, machines, lignes de production | Télégestion, SCADA eau/énergie, sites distants |
| Prix | 500 € à 10 000 € selon puissance et I/O | 300 € à 3 000 € selon I/O et protocoles |
| Programmation | IEC 61131-3 (LD, FBD, ST…) — ingénieur automaticien | Paramétrage simplifié ou langage constructeur — technicien télécontrôle |
| Communication distante | OPC-UA, Modbus TCP, via passerelle | DNP3, IEC 104, Modbus RTU sur 4G, natif réseau WAN |
| Redondance / buffer offline | Limitée — conçu pour rester connecté | Native — mémorisation horodatée en cas de coupure réseau |
Quand choisir un PLC ?
Le PLC est le bon choix lorsque les critères suivants sont réunis :
Logique locale complexe. Si votre installation nécessite un séquencement multi-étapes, une régulation PID multi-boucles, une gestion de recettes ou une coordination multi-actionneurs, seul un PLC dispose de la puissance de traitement et de l'environnement de développement adapté.
Temps de réponse critique. Un convoyeur qui doit détecter un bourrage en 10 ms et couper la ligne ne peut pas dépendre d'une décision venue du cloud. Le PLC décide localement, en temps réel.
Environnement controlé. L'équipement est installé dans une armoire électrique d'atelier, sous température contrôlée, avec une alimentation stabilisée. Les contraintes environnementales extrêmes (grand froid extérieur, alimentation batterie, site non gardé) ne sont pas présentes.
Exemples concrets :
- Robot de soudure sur ligne automobile : PLC gère la synchronisation des axes, la séquence de soudure et les interlocks de sécurité.
- Machine de conditionnement pharmaceutique : PLC gère le flux produit, la pesée, l'étiquetage et la traçabilité en conformité FDA 21 CFR Part 11.
- Station de traitement d'eau usées avec 6 bassins : PLC gère les séquences de remplissage/vidange, les pompes et les aérateurs avec une logique de régulation complexe.
Quand choisir un RTU ?
Le RTU est le bon choix dans les situations suivantes :
Sites distants non gardés. Une station de relevage à 40 km du centre de supervision, alimentée par un groupe électrogène avec batterie de secours, dans un puits ou un local sans climatisation. Le RTU est conçu pour cette réalité.
Flotte de points de mesure nombreux. Un réseau de distribution d'eau peut comporter 200 stations de pompage et 500 points de mesure. Déployer des PLCs sur chacun serait hors budget et sur-dimensionné. Les RTUs, plus économiques et plus simples à configurer, sont le choix naturel.
Protocoles SCADA natifs. Si votre SCADA central parle DNP3 ou IEC 60870-5-104 (protocoles conçus pour la télégestion avec gestion de l'horodatage, des séquences d'événements et de la communication intermittente), un RTU implémentera ces protocoles nativement, là où un PLC nécessitera une passerelle.
Autonomie sur coupure réseau. Le RTU stocke les mesures localement avec horodatage précis et les transmet en bloc à la reprise de la communication. Cette fonction est imposée dans de nombreux cahiers des charges de télégestion eau et énergie.
Exemples concrets :
- Réseau de stations de mesure de qualité de l'air : 80 stations transmettant toutes les 15 minutes des valeurs de PM2.5, NO2 et O3 au serveur central via 4G.
- Postes de livraison gaz : RTU avec IEC 101 sur liaison RTC puis migration IEC 104 sur IP, supervision par le dispatching.
- Irrigation agricole sur 500 ha : RTUs sur chaque vanne de secteur, pilotés depuis la centrale d'exploitation via SCADA.
Superviser un PLC à distance
La supervision à distance d'un PLC repose sur l'extraction des variables process depuis l'automate et leur transmission vers un système de supervision centralisé ou cloud. Plusieurs méthodes coexistent selon la génération d'automate et l'infrastructure disponible.
OPC-UA : la méthode moderne (S7-1500, Modicon M580, ControlLogix)
Les PLCs modernes (depuis 2015 environ) implémentent un serveur OPC-UA embarqué. La passerelle IoT ou le serveur SCADA se connecte en tant que client OPC-UA, souscrit aux variables d'intérêt et reçoit les mises à jour en temps réel ou sur changement de valeur. La sécurité est intégrée (chiffrement, certificats, authentification par username/password ou certificat client).
Modbus TCP : la méthode universelle
Modbus TCP est supporté par pratiquement tous les PLCs modernes et de nombreux PLCs anciens via modules de communication (CP pour Siemens, NOE pour Schneider). La passerelle IoT poll les registres Modbus à intervalle fixe et transmet les valeurs au cloud. Simple, universel, mais sans mécanisme natif de notification sur changement.
Passerelle IoT locale
Pour les PLCs sans connectivité réseau native (S7-300 sans CP Ethernet, Modicon Quantum), une passerelle IoT se connecte au port série RS-485 ou RS-232 de l'automate en Modbus RTU et assure la remontée vers le cloud. Cette approche est transparente pour le programme automate.
Accès direct via VPN
Pour la maintenance et le diagnostic, l'ingénieur accède à l'automate depuis son poste via un tunnel VPN. Il voit le PLC comme s'il était sur le réseau local : TIA Portal pour un S7, Unity Pro pour un Modicon, Studio 5000 pour un ControlLogix. Aucun port ouvert côté site industriel.
Superviser un RTU à distance
La supervision à distance est la raison d'être du RTU. Les protocoles et méthodes sont différents de ceux des PLCs, car ils ont été conçus dès le départ pour la communication sur des liens WAN instables.
DNP3 : le protocole historique des utilities
DNP3 (Distributed Network Protocol 3) est le protocole de télégestion dominant en Amérique du Nord pour les réseaux électriques et les systèmes de distribution d'eau. Il gère nativement la communication intermittente, l'horodatage des événements, les rapports sur exception (rapport uniquement si la valeur change) et les classes de données (classes 0, 1, 2, 3 pour prioriser les alarmes).
Un RTU DNP3 se connecte au master SCADA central via TCP/IP (DNP3 sur IP) ou via liaison série sur radio. Sur 4G, le RTU établit une session DNP3 TCP vers le serveur maître.
IEC 60870-5-101 et IEC 60870-5-104
Ces protocoles de la norme IEC sont les équivalents européens de DNP3, largement utilisés dans les réseaux d'énergie et de distribution d'eau en France et en Europe. IEC 101 est la variante série (RS-232/485), IEC 104 est la variante TCP/IP (le choix actuel pour les déploiements 4G et fibre).
Un RTU IEC 104 établit une connexion TCP vers le SCADA maître sur le port 2404. Il transmet les données en mode spontané (sur changement) ou en réponse à des interrogations générales du maître.
Modbus RTU sur 4G
Pour les déploiements plus simples ou les parcs d'équipements existants, un RTU peut transmettre ses données via Modbus TCP encapsulé sur 4G. La passerelle 4G du site crée un tunnel VPN vers le SCADA central ; le SCADA interroge le RTU en Modbus TCP via ce tunnel comme s'il était sur le réseau local.
Exemple de déploiement RTU eau
Un syndicat des eaux supervise 45 stations de pompage via un SCADA central. Chaque station dispose d'un RTU avec :
- 8 entrées analogiques 4–20 mA (débit, pression, niveau)
- 16 entrées TOR (états pompes, alarmes)
- 4 sorties TOR (commandes pompes)
- Communication IEC 104 sur 4G LTE avec failover sur SIM secondaire
Le SCADA interroge chaque RTU toutes les 5 minutes (interrogation générale) et reçoit les alarmes en mode spontané. En cas de dépassement de seuil, l'alarme est transmise en moins de 10 secondes.
La convergence PLC/RTU dans l'IIoT
Les frontières entre PLC et RTU se brouillent depuis une dizaine d'années, sous l'impulsion de l'IIoT et de la demande de supervision cloud :
Les PLCs modernes intègrent des fonctions RTU. Les Modicon M262, les Siemens S7-1500T ou les CompactLogix 5380 intègrent des connecteurs cloud natifs (MQTT, OPC-UA), des fonctions de mémorisation locale et des protocoles de télégestion. Un S7-1500 avec passerelle IoT peut jouer le rôle d'un RTU performant.
Les RTUs modernes intègrent de la logique PLC. Des équipements comme le Schneider Electric SCADAPack 470 ou le Wago 750-8207 offrent une puissance de traitement et un environnement de programmation IEC 61131-3 comparables à des PLCs compacts, tout en conservant les protocoles de télégestion natifs (DNP3, IEC 104).
L'edge computing efface la frontière. La tendance est à des équipements polyvalents capables de traitement local avancé (machine learning sur données capteurs, analyse de vibrations, détection d'anomalies), de communication multiprotocole et de supervision cloud simultanée. Ces "edge controllers" héritent du meilleur des deux mondes.
Recommandation pratique. Pour les nouvelles installations, la dichotomie PLC/RTU est de moins en moins structurante. Le vrai critère est : avez-vous besoin de logique temps réel locale (→ PLC), de télégestion sur site distant avec protocoles utility (→ RTU), ou les deux (→ edge controller avec les deux capacités) ? Dans tous les cas, la supervision à distance passe aujourd'hui par une passerelle IoT qui abstrait le protocole terrain et expose une API cloud standard.
Exemple d'architecture : superviser PLC et RTU depuis une même plateforme
Dans la réalité des parcs installés, PLC et RTU cohabitent : un atelier piloté par des S7-1200, des stations distantes équipées de RTU historiques, quelques armoires avec de simples capteurs Modbus. Plutôt que d'empiler les outils de supervision, l'architecture unifiée passe par la passerelle :
PLC (Modbus TCP, S7, OPC-UA) + RTU (Modbus RTU, DNP3) + capteurs RS-485 → gateway Eziwan → carte SIM M2M 4G ou Ethernet → tunnel VPN sortant → cloud Eziwan → supervision unifiée, alertes et accès distant par équipement.
La gateway abstrait le protocole terrain : côté plateforme, un registre de RTU des années 2000 et une variable OPC-UA d'un S7-1500 neuf se supervisent exactement de la même façon. C'est ce qui permet de moderniser la supervision sans attendre le renouvellement du parc.
Coût de modernisation : remplacer ou connecter ?
Avant de remplacer un RTU vieillissant par un PLC moderne, comparez les deux scénarios :
| Scénario | Coût typique par site | Délai | Risque |
|---|---|---|---|
| Remplacement complet du RTU par un PLC communicant | 5 000 à 15 000 € (matériel + études + recâblage + tests) | Plusieurs semaines, arrêt du site | Régression fonctionnelle, requalification |
| Ajout d'une gateway 4G sur l'existant | Quelques centaines d'euros + abonnement | Moins d'une journée, sans arrêt | Quasi nul (lecture seule possible) |
Dans la majorité des cas, la gateway répond au besoin réel — supervision cloud, alertes, accès distant — pour une fraction du coût, et laisse le remplacement matériel se planifier sereinement sur plusieurs années.
FAQ
Peut-on remplacer un RTU par un PLC dans une application de télégestion eau ? Techniquement oui, mais avec des nuances. Si votre SCADA central parle DNP3 ou IEC 104, un PLC sans module de communication dédié ne peut pas implémenter ces protocoles nativement. Il faudra une passerelle DNP3/IEC 104 → Modbus ou OPC-UA. De plus, les PLCs sont généralement plus énergivores et moins adaptés aux alimentations batterie/solaire. Le RTU reste le choix optimal pour les parcs de télégestion eau/énergie.
Un RTU peut-il remplacer un PLC sur une ligne de production ? Non, pour deux raisons : la puissance de traitement est insuffisante pour les logiques complexes de séquencement et de régulation, et les RTUs ne sont pas conçus pour les temps de cycle inférieurs à 100 ms. Un RTU peut en revanche superviser des équipements simples sur une ligne (capteurs de niveaux, états de vannes manuelles) en complément d'un PLC principal.
Comment superviser un vieux RTU dont le protocole n'est pas supporté par mon SCADA cloud ? Une passerelle de protocole (Moxa, Advantech, Eziwan) peut convertir un protocole terrain hérité (DNP3, IEC 101, BSAP) vers MQTT ou OPC-UA compréhensible par un SCADA cloud moderne. C'est souvent plus économique que de remplacer les RTUs sur des parcs de centaines d'équipements.
Quelle est la différence entre un RTU et un data logger ? Un data logger enregistre passivrement des mesures dans sa mémoire pour une lecture ultérieure (souvent en USB ou SD card). Un RTU transmet activement les données vers un système central en temps quasi réel ou sur événement. Certains équipements modernes combinent les deux fonctions (data logger avec transmission 4G), mais la distinction fonctionnelle reste pertinente.
Pour aller plus loin
- Blog : connecter un automate Siemens S7 au cloud — guide technique
- Blog : connecter un automate Schneider M340/M221 au cloud
- Blog : Modbus TCP vs RTU — quel protocole pour la supervision à distance ?
- Blog : supervision eau et assainissement 4G — cas d'usage RTU terrain
- Docs : compatibilité Siemens S7-1200/S7-1500
Vous supervisez un parc d'automates PLCs ou de RTUs et souhaitez centraliser la supervision à distance ? Découvrez les solutions Eziwan pour l'accès distant automate et PLC.
Ressources complémentaires
- Accès distant automate PLC — solutions d'accès distant sécurisé pour automates industriels
- SCADA cloud — supervision SCADA centralisée depuis le cloud
- Supervision et téléassistance industrielle — supervision à distance de vos PLCs et RTUs
- Télediagnostic industriel — diagnostic à distance de vos équipements industriels