Passer un automate programmable (PLC) critique d'une configuration mono-maître vers une architecture redondante en shadow controller sans arrêter la production est l'un de ces challenges qui mêlent rigueur, préparation et un peu d'audace mesurée. J'ai réalisé ce type de migration sur plusieurs sites industriels et je partage ici une méthode opérationnelle, des retours d'expérience et des points de vigilance pour vous aider à réussir ce type d'intervention.
Pourquoi choisir le mode shadow controller ?
Le mode shadow controller (ou contrôleur fantôme) permet d'avoir un second PLC qui exécute la même logique en parallèle mais sans prendre le contrôle actif du process tant qu'il n'est pas basculé. L'avantage principal est la capacité à valider le comportement du second automate en conditions réelles avant de le mettre en production, puis de basculer sans interruption. C'est une stratégie idéale quand l'arrêt est impossible ou trop coûteux.
Étapes préalables indispensables
Avant toute intervention, je mène toujours une phase de préparation approfondie :
Cartographie complète du système : I/O, réseaux (Ethernet, Profibus, Profinet), HMI/SCADA, automates existants, redondances existantes.Recueil des contraintes opérationnelles : plages de production sensibles, opérations manuelles en cours, exigences de sécurité fonctionnelle (SIL) et maintenance.Plan de rollback clair : si la migration rencontre un problème, comment revenir instantanément à l'état précédent ?Validation avec l'exploitant et les opérateurs : fenêtres d'intervention, modes opératoires, formations succinctes si nécessaire.Architectures possibles et choix techniques
Selon le fournisseur et l'architecture du site, le mode shadow peut être implémenté de plusieurs manières :
Shadow sur même réseau via réplication des blocs de programme et synchronisation des I/O (ex. : Rockwell ControlLogix avec module de redondance, Siemens S7 avec dual CPU).Shadow sur réseau isolé, puis synchronisation progressive vers le réseau de production — pratique pour validation sans impact réseau.Shadow via virtualisation (PLC virtualisé) où un hyperviseur exécute deux instances en shadow, utile sur plateformes modernes.J'utilise fréquemment des contrôleurs compatibles Redundancy (par ex. Siemens S7-1500R ou Allen-Bradley GuardLogix avec redondance) car ils offrent des outils intégrés pour la synchronisation et le basculement, ce qui réduit le risque d'écarts entre maîtres et shadows.
Déploiement pas à pas
Voici le déroulé que j'applique systématiquement :
1. Sauvegarde complète : sauvegarde des programmes PLC, configuration réseau, images HMI/SCADA et copies de sécurité vérifiées (hors-site si possible).2. Mise en place du PLC shadow : installer physiquement/virtuellement le contrôleur, configurer l'IP distincte, préparer la structure des tags et la cartographie des I/O sans toucher au bus physique actif si possible.3. Réplication logicielle : importer la logique existante dans le shadow (export/import de projet), puis appliquer une procédure de comparaison (checksums, comparateur de blocs) pour détecter les différences.4. Synchronisation des paramètres : synchroniser les paramètres non-logiques (temps processeur, watchdogs, paramètres de modules I/O, drivers spécifiques). Très souvent, les différences se cachent dans les paramètres matériels et provoquent des écarts de comportement.5. Jumelage I/O virtuel : si possible, configurer un mappage I/O virtuel pour que le shadow lise les mêmes valeurs que le maître sans influencer les actionneurs. Sur certains systèmes, cela se fait via un switch mirror ou via des modules d'E/S redondantes.6. Tests hors-ligne puis in-situ : réaliser des tests unitaires sur le programme (simulateur) puis des tests en lecture seule sur l'E/S (monitoring passif) afin de comparer les logs entre maître et shadow.7. Période d'observation (monitoring parallèle) : laisser le shadow fonctionner en mode passif pendant plusieurs cycles de production, collecter les différences, ajuster les délais et traitements temps réel si nécessaire.8. Préparation du basculement : définir des critères clairs pour déclencher le basculement (ex. : test réussi X heures, divergence < seuil), préparer l'équipe d'astreinte et un plan rollback instantané.9. Basculement contrôlé : activer le shadow en mode actif selon le mécanisme du constructeur (commande de bascule, takeover). Sur S7-1500R ou ControlLogix Redundancy, cela se fait par une commande définie et documentée.10. Vérification post-basculement : surveiller étroitement tous les KPIs : temps de cycle, alarmes, consignation SCADA, et réagir immédiatement aux écarts.Tableau : checklist d'intervention
| Étape | Validé (O/N) | Commentaires |
| Sauvegarde complète | | |
| Inventaire I/O et réseaux | | |
| Import programme dans shadow | | |
| Comparaison blocs / checksums | | |
| Paramètres matériels synchronisés | | |
| Tests monitoring passif | | |
| Plan rollback et responsables définis | | |
| Basculement et observation post-basculement | | |
Points critiques et erreurs fréquentes
Voici ce que j'ai vu poser problème :
Incohérences de temps réel : latences réseau ou différences de scan time provoquent des comportements divergents. Mesurez et alignez les temps de scan.Tags non synchronisés : tags locaux ou variables masquées qui ne sont pas répliquées créent des états différents.Paramètres matériels oubliés : adresses physiques d'E/S, temps de watchdog, paramètres de sécurité.HMI/SCADA non aligné : panneaux HMI pointant vers l'ancien contrôleur ou archivage SCADA non configuré pour le shadow.Sécurité et cybersécurité
La redondance n'est pas une excuse pour négliger la sécurité. Je recommande :
Segmenter le réseau de contrôle et appliquer des ACL pour restreindre l'accès au shadow.Tenir les firmwares et outils de programmation à jour et signer les projets si possible.Journaliser toutes les opérations de basculement, accès et modifications (SIEM côté industriel si disponible).Valider la conformité SIL/FMECA si l'automate est impliqué dans la sécurité fonctionnelle.Retour d'expérience : cas concret
Sur une ligne de production pharmaceutique, j'ai migré un PLC Allen-Bradley ControlLogix vers une solution redondante avec GuardLogix en shadow. Points clés :
Nous avons d'abord cloné le programme et utilisé le module de redondance pour synchroniser les tags. La période d'observation a duré 72 heures pendant lesquelles l'équipe de production a validé l'absence d'impact.Un problème mineur est apparu : certaines variables de temporisation n'étaient pas identiques entre maîtres et shadow à cause d'un module tiers (convertisseur de signaux) — correction via calibration logicielle.Le basculement s'est fait pendant un quart, en coordination avec l'atelier. Aucun arrêt n'a été nécessaire et le délai de reprise a été inférieur à 2 secondes grâce à la configuration matérielle et réseau adaptée.Ce type d'intervention demande méthode, rigueur et communication. Si vous souhaitez, je peux partager un template de procédure d'intervention ou un script de comparaison des blocs adapté à Siemens ou Rockwell pour vous aider à démarrer.
