Défauts de communication entre automate et SCADA : symptômes, causes et comment les diagnostiquer
Automates et SCADA · Diagnostic
Un défaut de communication entre l'automate et le SCADA se localise couche par couche : d'abord la couche physique (câble, connecteurs, bruit électrique), puis le réseau (switchs, boucles, adresses IP), ensuite le protocole (délais d'attente et codes d'erreur de Modbus, PROFINET ou OPC UA) et enfin l'application (combien de variables sont demandées, à quelle fréquence et avec quelle horloge).
Ce guide s'adresse à ceux qui ont le problème sous les yeux. Si vous avez besoin de vous situer d'abord, nous expliquons ce qu'est un automate programmable, qui pilote la machine, et ce qu'est un système SCADA, le logiciel qui supervise et enregistre l'usine.
Avant de redémarrer quoi que ce soit : notez à quelle heure la panne survient, quels équipements se retrouvent sans données et ce que dit le système (qualité de la donnée, code d'erreur, message du driver). Redémarrer le serveur ou le switch rétablit généralement la communication, et le redémarrage efface les compteurs du switch et ce que le driver n'enregistre pas sur disque, c'est-à-dire précisément ce qui expliquait pourquoi la communication avait été perdue.
Sur cette page
- Symptômes et ce qu'ils indiquent
- Tableau de diagnostic
- Couche physique
- Couche réseau
- Couche protocole : Modbus, PROFINET et OPC UA
- Couche application
- Diagnostic pas à pas
- Solutions pour que cela ne se reproduise pas
- Ce qui change dans une usine agroalimentaire
- Comment nous travaillons chez ER Ingeniería
- Questions fréquentes
- Sources
Symptômes d'une perte de communication et ce qu'ils indiquent
Cela commence rarement par une coupure totale. Le plus souvent, ce sont de petits signes :
- Variables figées. La valeur ne bouge pas alors que le procédé, lui, évolue. Beaucoup de drivers conservent la dernière valeur lue quand la connexion tombe, et si l'écran n'affiche pas la qualité de la donnée, l'opérateur voit un chiffre crédible qui ne correspond plus à la réalité.
- Qualité « Bad » ou « Uncertain ». En OPC UA, chaque valeur circule avec un code d'état : Good désigne une valeur de bonne qualité, Uncertain une valeur de qualité douteuse et Bad une valeur inutilisable [4]. Le code précis en dit souvent plus que l'alarme.
- Alarmes de communication intermittentes. Elles apparaissent et disparaissent d'elles-mêmes. Si elles coïncident avec le démarrage d'un gros moteur, un changement d'équipe ou un lavage, l'heure est le meilleur indice.
- Trous dans les historiques. La courbe de tendance relie deux points par une droite ou des enregistrements d'un lot manquent et, sans mémoire tampon en amont, ce trou ne peut plus être comblé.
- Écritures qui n'arrivent pas. Une consigne ou une recette part du SCADA et l'automate ne l'exécute pas, ou l'exécute en retard.
- Valeurs absurdes mais stables. Un nombre énorme ou négatif là où il devrait y avoir une température. La donnée arrive, mais elle est mal interprétée : nous le voyons dans la couche application.
Tableau de diagnostic : symptôme, cause probable et vérification
| Symptôme | Cause probable | Que vérifier |
|---|---|---|
| Toutes les variables d'un équipement figées, sans alarme | Connexion perdue et driver qui conserve la dernière valeur ; abonnement OPC UA fermé ou non récupéré à la reconnexion | Qualité des tags et état de la connexion dans le driver ; liaison du port sur le switch |
| Qualité « Bad » sur un groupe de variables | Équipement qui ne répond pas, adresse mal mappée, passerelle qui n'atteint pas l'esclave | Le code : en Modbus, 02 signifie adresse illégale et 0B, esclave derrière la passerelle qui ne répond pas [1] |
| Alarme qui va et vient, surtout au démarrage des moteurs | Bruit électrique, blindage du câble mal raccordé, câbles de données à côté des câbles de puissance | Compteurs d'erreurs CRC/FCS du port, et s'ils augmentent au démarrage des moteurs |
| Tout un tronçon tombe et ne revient qu'une fois un câble retiré | Boucle et tempête de diffusion (broadcast) | LED d'activité qui clignote sans arrêt ; nouveau cordon de brassage qui ferme une boucle ; compteurs de diffusion si le switch est administrable |
| Plusieurs équipements tombent quelques secondes et reviennent seuls | La redondance (STP ou anneau) se reconfigure après une coupure | Changements de topologie dans le journal du switch ; dans les anneaux PROFINET, watchdog comparé au temps de reconfiguration [2] |
| Un équipement cesse de communiquer quand un autre est mis sous tension | Adresse IP dupliquée | Adresse MAC de cette IP qui change ; arping ou capture avec deux réponses |
| Défaillances ponctuelles de station PROFINET | Watchdog trop court pour le réseau réel, anneau qui se reconfigure | Tampon de diagnostic du contrôleur ; temps de rafraîchissement et cycles acceptés sans données [2] |
| Écrans lents et timeouts aux heures de pointe | Trop de variables, scrutation plus rapide que nécessaire, adresses dispersées | Requêtes par cycle et temps de réponse, dans le driver ou dans une capture |
| Trous dans l'historique ou événements dans le désordre | Coupure sans mémoire tampon avant le tronçon tombé ; horloges non synchronisées | Journal du service d'historique ; heure de l'automate comparée à celle du serveur |
Couche physique : câble, connecteurs et bruit électrique
C'est la première à écarter et celle que l'on saute le plus souvent. Causes typiques : connecteurs RJ45 montés sur chantier qui se desserrent avec les vibrations, entrées de câbles dans les boîtiers de terrain sans étanchéité, humidité qui reste à l'intérieur après les lavages et blindages de câble non raccordés ou raccordés autrement que ne l'indique le fabricant du bus.
Le bruit électrique suit un schéma reconnaissable : les erreurs augmentent quand un gros moteur démarre ou qu'un variateur accélère. Si le câble de données partage la goulotte avec les sorties des variateurs, le problème ne se règle pas en touchant au logiciel.
Comment le vérifier : compteurs d'erreurs du port (trames avec un CRC ou un FCS erroné) sur le switch ou dans le diagnostic des ports de l'automate. S'ils augmentent, testeur de câble et cordon de brassage d'usine à la place du cordon suspect. Si les erreurs suivent le cordon, la panne vient de lui.
Couche réseau : switchs, boucles, IP dupliquées et VLAN
Un switch non administrable dans une armoire d'usine fonctionne, mais il ne fournit pas de compteurs par port et ne permet pas de copier le trafic pour le capturer.
Boucles. Un cordon de brassage qui relie deux prises du même switch, ou deux switchs reliés par deux chemins sans protocole qui gère la redondance, crée une boucle dans laquelle les trames de diffusion tournent sans fin. Cela arrive souvent après une extension ou une réparation faite à la hâte : tout le tronçon tombe d'un coup et ne revient que lorsqu'on retire le câble qui ferme la boucle. Avec de la redondance (STP ou anneau), un câble coupé ne fait pas tomber le tronçon, même si de brèves coupures peuvent se produire pendant que le réseau se reconfigure.
IP dupliquées. Une pièce de rechange configurée avec l'IP d'un équipement toujours connecté, l'ordinateur portable d'un technicien extérieur, un nouvel écran avec son IP d'usine. Deux équipements communiquent à tour de rôle : l'adresse MAC de cette IP change d'une requête à l'autre, et un arping ou une capture montre deux équipements qui répondent à la même IP.
Segmentation. Le guide du NIST sur la sécurité des technologies opérationnelles décrit la segmentation du réseau d'usine en zones, physique avec des switchs distincts ou logique avec des VLAN [6]. En plus de protéger, elle évite que le trafic de diffusion des bureaux n'atteigne les automates.
Couche protocole : Modbus, PROFINET et OPC UA
Modbus : un timeout et une exception ne disent pas la même chose
La spécification Modbus distingue deux cas que l'on confond à l'écran. Si la requête n'atteint pas l'esclave, ou arrive avec une erreur de parité ou de CRC, il n'y a pas de réponse et le client finit par enregistrer un délai d'attente dépassé. Si elle arrive correctement mais que l'équipement ne peut pas la traiter, il renvoie une réponse d'exception : le code de fonction plus 80 hexadécimal et un code indiquant le motif [1].
Autrement dit : un timeout signifie qu'aucune réponse n'est arrivée. Il oriente vers le câble, le réseau, la passerelle, un équipement éteint ou des paramètres qui ne concordent pas (adresse d'esclave, vitesse, parité), car l'esclave ne répond ni à une trame qui ne lui est pas destinée ni à une trame qui arrive avec des erreurs [1]. Une exception indique que l'équipement a reçu la requête et pourquoi il ne la traite pas : les codes 01 et 02 relèvent généralement de la configuration, le 04 est une panne de l'équipement et les 0A et 0B désignent la passerelle ou ce qui se trouve derrière. Les codes les plus parlants :
| Code | Nom | Signification habituelle |
|---|---|---|
| 01 | Illegal Function | L'équipement n'accepte pas cette fonction, ou n'est pas en état de la traiter [1] |
| 02 | Illegal Data Address | La requête sort de la table : sur un équipement de 100 registres, lire 5 registres à partir du 96 échoue car le 100 n'existe pas [1] |
| 04 | Server Device Failure | Erreur irrécupérable dans l'équipement lors de l'exécution de la requête [1] |
| 0A | Gateway Path Unavailable | Passerelle mal configurée ou surchargée [1] |
| 0B | Gateway Target Device Failed to Respond | La passerelle a interrogé l'esclave et celui-ci n'a pas répondu ; en général, il n'est pas sur le réseau [1] |
Augmenter le timeout du driver peut faire disparaître l'alarme sans supprimer la cause : les données continuent d'arriver en retard et, sur une liaison série où le maître interroge les esclaves un par un, chaque attente retarde les requêtes suivantes.
PROFINET : le temps de surveillance
PROFINET IO relie l'automate à sa périphérie et à ses variateurs. Le SCADA communique généralement avec l'automate en S7 ou en OPC UA, si bien que cette panne lui parvient par ricochet : sous forme d'alarme de défaillance de station, si l'automate la signale, ou de lectures qui ne sont plus valides.
Le watchdog PROFINET est le temps que le contrôleur ou le périphérique IO acceptent sans recevoir de données. S'il est dépassé, le périphérique applique des valeurs de remplacement et le contrôleur l'enregistre comme une défaillance de station. Dans le logiciel de Siemens, il se règle comme un multiple entier du temps de rafraîchissement [2].
Le tampon de diagnostic du contrôleur indique quel périphérique est tombé et quand. Dans les anneaux, MRP, le protocole de redondance de la norme IEC 62439-2, a un temps de reconfiguration typique de 200 ms et accepte jusqu'à 50 appareils par anneau, et Siemens demande un watchdog de 256 ms ou plus lorsque plusieurs anneaux sont couplés [2]. Un watchdog plus court que la reconfiguration transforme une coupure que l'anneau devrait absorber en arrêt.
OPC UA : des abonnements qui se perdent
Avec OPC UA, le SCADA s'abonne généralement aux variables. Le serveur envoie les changements à chaque intervalle de publication et, si plusieurs cycles consécutifs passent sans changement, un message de maintien (keep-alive). Si trop de cycles passent sans que le client demande de publications, le compteur de durée de vie s'épuise et l'abonnement est fermé [3].
Les abonnements sont conçus pour survivre à une coupure de la connexion et de la session [3], mais il existe un scénario typique : la connexion revient et un groupe de variables reste figé, parce que la coupure a duré plus longtemps que la durée de vie de l'abonnement ou parce que le client a ouvert une nouvelle session sans le transférer ni le recréer. La spécification prévoit une file de retransmission pour récupérer les notifications perdues avec le service Republish [3] ; que le client l'utilise dépend de sa configuration.
Couche application : variables, scrutation et horloges
Scrutation excessive. Demander toutes les variables chaque seconde charge le processeur de communication de l'automate et le driver. Une température de cuve n'a pas besoin de la fréquence d'une bascule en pleine pesée.
Adresses dispersées. Une lecture Modbus de registres accepte de 1 à 125 registres contigus [1]. Si les variables sont réparties dans la mémoire de l'automate, il faut de nombreuses petites requêtes par cycle ; regroupées dans une zone d'échange contiguë, il en faut beaucoup moins.
Signal de vie (heartbeat). Un compteur que l'automate incrémente et que le SCADA surveille : s'il cesse de changer, les données sont anciennes même si la connexion semble ouverte. L'inverse fonctionne aussi : l'automate surveille un signal de vie du SCADA et, si celui-ci s'arrête, il cesse d'accepter les consignes à distance et passe dans un état sûr défini.
Horloges. Avec une horloge différente dans l'automate, le serveur et l'historien, les événements apparaissent dans le désordre. NTP est le protocole standard de synchronisation des horloges en réseau [7], et le NIST rappelle que la synchronisation horaire est nécessaire pour corréler les événements et les journaux [6].
Types de données. Les valeurs absurdes sont généralement un entier signé lu comme non signé, ou un réel qui circule sur deux registres et se recompose avec l'ordre des mots inversé. On le confirme en comparant la valeur en ligne dans l'automate avec celle du SCADA.
Comment diagnostiquer un défaut de communication entre automate et SCADA, pas à pas
- Délimitez la portée. Un équipement, une ligne ou toute l'usine ? Tout le temps, par intermittence, à certaines heures ? Si tout tombe en même temps, regardez le réseau ou le serveur ; si un seul équipement tombe, son câble, son port ou sa configuration.
- Lisez ce que dit déjà le système. Qualité des variables, erreur du driver (timeout ou exception, et laquelle), tampon de diagnostic de l'automate et événements du serveur.
- Regardez les compteurs. Sur le switch administrable : erreurs CRC, trames rejetées, pertes de liaison et diffusion par port. Sur l'automate : diagnostic des ports et des stations. Remettez-les à zéro, attendez que le défaut se reproduise et comparez.
- Capturez le trafic. Wireshark, l'analyseur de réseau libre, décode Modbus/TCP, PROFINET IO et OPC UA [8]. Sur un réseau commuté, un ordinateur portable branché sur un port quelconque ne voit que son propre trafic et celui de diffusion : il faut un port miroir (port mirroring ou SPAN) sur un switch administrable, ou un tap réseau. Le port miroir doit être au moins aussi rapide que celui qu'il copie et il ne retransmet pas les trames endommagées ; les erreurs CRC se voient donc dans les compteurs, pas dans la capture [5].
- Isolez, avec prudence. Branchez un ordinateur portable directement sur l'équipement avec un client de test en lecture seule, par un second port libre ou pendant un arrêt s'il faut le sortir du réseau. Auparavant, vérifiez quels verrouillages entre automates passent par ce réseau : le déconnecter les coupe. S'il communique alors correctement pendant des heures, le problème vient du réseau ou de la charge ; s'il échoue de la même façon, de l'équipement ou de sa configuration.
- Changez une seule chose à la fois. Si vous en changez trois en même temps et que la panne disparaît, vous ne saurez pas laquelle était en cause.
Solutions pour que cela ne se reproduise pas
Trouver la cause règle la panne d'aujourd'hui. La suivante se prévient par l'architecture :
| Mesure | Ce qu'elle évite | Quand elle est rentable |
|---|---|---|
| Réseau de contrôle séparé, avec ses propres switchs ou des VLAN [6] | Le trafic des bureaux sur les automates ; qu'une boucle dans un bureau fasse tomber l'usine | Si le contrôle et les bureaux partagent des switchs |
| Switchs administrables de gamme industrielle | Les pannes sans trace : ils fournissent des compteurs par port et permettent de capturer [5] | Là où se rejoignent automates et serveurs |
| Anneau avec MRP et watchdog adapté [2] | Qu'un câble coupé laisse la moitié d'un tronçon sans communication | Lignes où un arrêt coûte plus cher que l'anneau |
| Scrutation selon la criticité et zones d'échange contiguës [1] | La saturation de l'automate et du driver ; les timeouts aux heures de pointe | Écrans lents ou timeouts sans erreurs physiques |
| Mémoire tampon horodatée avant le tronçon qui se coupe (dans l'automate ou dans l'équipement de collecte en bord de ligne), qui se vide à la reconnexion | Les trous dans les historiques et les lots incomplets après une coupure | Quand ces enregistrements servent à la traçabilité |
| NTP sur les automates, les serveurs et l'historien [7] | Les événements dans le désordre et les lots aux horaires incohérents | Toujours |
| Signal de vie et état sûr programmés dans l'automate | Agir sur des données anciennes ; des consignes à contretemps | Là où des consignes ou des recettes en dépendent |
Ce qui change dans une usine agroalimentaire
Avec des lavages fréquents, l'humidité entre par les connecteurs et les presse-étoupes non étanches, et les pannes apparaissent après le nettoyage. Dans les usines d'aliments pour animaux, la poussière s'accumule dans les armoires et les switchs mal fermés. En cave vinicole, le réseau est à pleine charge pendant les vendanges, au moment où l'on peut le moins s'arrêter : les modifications du réseau se testent hors campagne.
Dans toute usine alimentaire, les trous dans l'historique laissent incomplet l'enregistrement du lot. Ce qu'exige la loi est expliqué dans notre article sur la traçabilité alimentaire.
Si la cause est l'âge du système (automates sans pièces de rechange, SCADA sur un système d'exploitation qui n'est plus pris en charge, drivers que personne ne peut mettre à jour), le diagnostic débouche sur un plan de migration. La façon de la mener sans arrêter la production est expliquée dans le guide de modernisation des SCADA et des automates.
Comment nous travaillons chez ER Ingeniería
Nous travaillons dans les installations électriques et l'automatisation depuis 1981, et nous avons automatisé 45 usines agroalimentaires, entre usines d'aliments pour animaux, caves vinicoles et usines alimentaires. Quand une usine perd la communication, nous établissons le diagnostic couche par couche, sur place. C'est ce que couvre notre service d'automatisation de caves vinicoles et d'usines d'aliments pour animaux, de l'armoire électrique au logiciel.
Pour les données, nous avons SuitER, notre logiciel industriel : son module SuitER Server relie le réseau des automates au réseau de gestion, collecte les données en temps réel et les enregistre dans une base de données. Pour les usines déjà en fonctionnement, il y a notre service technique SatER.
Votre SCADA perd la communication avec les automates ?
Dites-nous quel protocole utilise votre usine et depuis quand vous remarquez les symptômes. Avec cela, nous vous dirons par où nous commencerions à chercher.
Parlez à notre équipeOu appelez-nous au 967 140 850
Questions fréquentes sur les défauts de communication automate et SCADA
Pourquoi le SCADA perd-il la communication avec l'automate ?
Les causes se répartissent sur quatre couches : physique (câble, connecteurs, bruit des variateurs et des moteurs), réseau (switchs non administrables, boucles, IP dupliquées), protocole (timeouts, codes d'exception Modbus, watchdog PROFINET, abonnements OPC UA) et application (trop de variables, scrutation trop rapide, horloges non synchronisées). On les vérifie dans cet ordre.
Quelle est la différence entre un timeout et une exception en Modbus ?
Un timeout signifie qu'aucune réponse n'est arrivée : la requête s'est perdue, est arrivée endommagée ou ne correspondait pas à l'équipement (adresse d'esclave, vitesse ou parité différentes). Une exception est une réponse : l'équipement a reçu la requête et indique pourquoi il ne la traite pas. Le code 02, par exemple, correspond à une adresse de registre qui n'existe pas dans sa table ; le 04, à une panne de l'équipement lui-même ; et le 0B, à un esclave qui ne répond pas derrière une passerelle.
Que signifie une variable de qualité Bad ou Uncertain dans le SCADA ?
C'est l'état de qualité qui accompagne la valeur. En OPC UA, Good désigne une valeur de bonne qualité, Uncertain une valeur de qualité douteuse et Bad une valeur inutilisable. Le code précis qui accompagne Bad indique généralement la cause mieux que l'alarme de communication générique.
Qu'est-ce que le watchdog en PROFINET ?
C'est le temps que le contrôleur ou le périphérique IO acceptent sans recevoir de données. S'il est dépassé, le périphérique applique des valeurs de remplacement sur ses sorties et le contrôleur l'enregistre comme une défaillance de station. Dans le logiciel de Siemens, il se règle comme un multiple du temps de rafraîchissement.
Est-il utile d'augmenter le timeout du driver ?
Cela peut faire disparaître l'alarme sans supprimer la cause. La donnée arrive plus tard et, sur une liaison série, chaque attente retarde les requêtes suivantes. Mieux vaut ne l'augmenter que lorsqu'on sait pourquoi c'est nécessaire.
Comment capturer le trafic entre l'automate et le SCADA avec Wireshark ?
Avec un switch administrable doté d'un port miroir (port mirroring ou SPAN) ou avec un tap réseau : un ordinateur portable branché sur un port quelconque d'un switch ne voit que son propre trafic et celui de diffusion. Les trames avec une erreur CRC n'apparaissent pas dans une capture par port miroir ; ces erreurs se consultent donc dans les compteurs du switch.
Pourquoi y a-t-il des trous dans les historiques du SCADA ?
Le plus souvent, les données se sont perdues sur le tronçon tombé et personne ne les avait enregistrées en amont. On l'évite avec une mémoire tampon horodatée avant ce tronçon, dans l'automate ou dans l'équipement qui collecte les données, qui se vide à la reconnexion ; les décalages d'heure, en synchronisant tous les équipements avec NTP.
Sources
- Modbus Organization. (2012). MODBUS Application Protocol Specification V1.1b3 (section 7 et fonction 03). modbus.org (PDF)
- Siemens AG. (2022). SIMATIC PROFINET with STEP 7: Function Manual (11/2022, A5E03444486-AM ; sections 3.1 et 6.4). cache.industry.siemens.com (PDF)
- OPC Foundation. (s. d.). OPC 10000-4: OPC Unified Architecture Part 4: Services (v1.05.07, 5.14.1.1). reference.opcfoundation.org
- OPC Foundation. (s. d.). OPC Unified Architecture Part 4: Services (v1.04, 7.34.1 StatusCode). reference.opcfoundation.org
- Wireshark Foundation. (s. d.). CaptureSetup/Ethernet. wiki.wireshark.org
- Stouffer, K. et al. (2023). Guide to Operational Technology (OT) Security (NIST SP 800-82r3 ; sections 6.2.1.3 et 6.2.12). csrc.nist.gov
- Mills, D., Martin, J., Burbank, J. et Kasch, W. (2010). RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification. IETF. rfc-editor.org
- Wireshark Foundation. (s. d.). Display Filter Reference: Modbus/TCP (ainsi que celles de PROFINET IO et OpcUa Binary Protocol). wireshark.org