Comment vérifier une référence successeure de CPU d’automate

Une vérification de successeur compare deux unités : le CPU installé dans votre armoire et le candidat qui pourrait le remplacer. Échanger un CPU contre son successeur paraît simple jusqu’au premier écart de câblage. La comparaison se fait entre blocs de numéros de commande et faits consignés, pas entre noms marketing ou pages de catalogue, et chaque point s’écrit en paire : ce que possède l’unité installée, ce que possède le successeur.

Schéma système agrandi

×

Les deux unités alimentent la même liste de paires. Une paire sans source est une supposition, pas une comparaison.

Les paires écrites sont le livrable. Une comparaison qui vit dans la tête de quelqu’un ne peut pas être vérifiée, et une décision de successeur est précisément le genre de décision qu’une seconde personne devrait pouvoir contrôler. Les paires écrites survivent aussi aux changements de personnel, car des machines qui tournent pendant des décennies survivent aux personnes qui les ont mises en service.

Cette section suit la comparaison dans l’ordre d’apparition des risques : d’abord le matériel qui change le travail en armoire, puis le firmware qui conditionne le projet, puis les liaisons qu’aucune plaque signalétique ne montre. Une photo de chaque unité à côté de sa paire écrite rend la vérification encore plus difficile à contester. L’ordre de la liste est aussi l’ordre du coût : les changements matériels se voient d’abord, les liaisons se révèlent en dernier.

Sachez d’où vient chaque côté de la paire. L’unité installée est décrite par votre propre dossier : photos de plaque signalétique, lecture via l’outil d’ingénierie et position dans le châssis. Le successeur est décrit par la documentation du fabricant : le manuel d’équipement et les données techniques publiées. Une paire qui mélange un fait mesuré et un souvenir est plus faible qu’elle n’y paraît, alors notez la source sur chaque ligne et gardez les deux côtés distinguables.

Commencez par les faits qui changent le travail en armoire : l’entrée d’alimentation, l’étage de sorties intégré et le nombre d’E/S intégrées décident si le câblage existant survit à l’échange. Un CPU 1214C DC/DC/DC (6ES7214-1AG40-0XB0) fournit des sorties transistor 24 V sur ses rangées de bornes. Son homologue AC/DC/relais commute les charges par relais sur une entrée d’alimentation différente. La vraie comparaison se fait donc entre blocs de numéros de commande, pas entre noms marketing.

Schéma système agrandi

×

Chaque ligne matérielle débouche sur une estimation de travail, pas sur un verdict. C’est une comparaison fonctionnelle, pas un schéma de câblage.

Le montage et l’architecture réseau figurent sur la même liste. Passer d’un CPU 1214C compact à un seul port PROFINET à un CPU à deux ports change ce que l’armoire peut connecter sans matériel supplémentaire. Passer à un format différent, comme un ET 200SP CPU 1510SP-1 PN (6ES7510-1SJ01-0AB0), change le rail, les adaptateurs de bus et la famille de modules autour du CPU. Chaque différence devient du travail réel en armoire, donc chacune reçoit une ligne.

Une différence de montage mineure sur une fiche technique devient un problème de goulotte de câblage en pratique. Voilà pourquoi la liste matérielle vient en premier : elle décide si l’échange est un après-midi de reprise de câblage ou un changement de rail et de famille de modules, et les deux réponses sont des issues légitimes d’une comparaison honnête. Écrivez l’estimation du travail à côté de la paire, car une estimation qui reste dans votre tête ne peut pas être discutée. L’estimation est aussi l’endroit où les deux issues se séparent : la reprise de câblage tient dans une fenêtre de maintenance, tandis qu’un changement de rail relève d’un projet.

C’est ici qu’une correspondance matérielle plausible échoue en silence. Un CPU successeur peut exiger une version de firmware plus récente que celle que le projet existant ou le logiciel d’ingénierie installé prend en charge. L’unité convient, le câblage convient, et le projet ne se charge pas ou ne compile pas. Consignez le firmware installé et l’exigence du successeur comme des faits distincts, et contrôlez les deux par rapport à la version du projet avant de commander une unité.

Schéma système agrandi

×

Le filtre ne s’ouvre qu’avec des données citées des deux côtés. Une devinette de catalogue ne vaut pas exigence.

Là où le fabricant publie des données de compatibilité, citez la source publiée dans le dossier au lieu de vous fier à la proximité de catalogue. Deux références côte à côte dans un catalogue ne constituent pas une déclaration de compatibilité. Un chemin de migration qui a fonctionné pour un projet n’est pas une preuve pour le suivant. La citation date aussi la vérification, ce qui compte car les données de compatibilité changent à mesure que les produits sont mis à jour.

Une affirmation de compatibilité sans source citée est précisément le mode de défaillance que cette vérification existe pour prévenir. Une citation datée donne aussi au prochain vérificateur un point de départ quand les données changent, ce qui est probable, car les familles successeures avancent pendant que votre projet installé reste en place. Les affirmations de compatibilité vieillissent vite, donc une affirmation sans date est une affirmation indéfendable.

Consignez la version du logiciel d’ingénierie à côté des versions de firmware, car la compatibilité va dans les deux sens. Un successeur qui exige une version de projet que vous ne pouvez pas installer est aussi bloqué qu’un successeur au firmware incompatible, et le blocage se révèle au poste d’ingénierie plutôt qu’en armoire. La version du logiciel installé se lit pendant que la machine tourne, donc elle a sa place dans le dossier avant que la comparaison ne commence.

Le programme de contrôle n’est pas la seule liaison à vérifier. Le projet IHM référence des variables du CPU. Les variateurs connectés et les E/S déportées entretiennent des relations avec lui. Une application fail-safe ajoute à la liste le programme de sécurité et sa configuration F. Chaque liaison est un endroit où un successeur d’apparence compatible peut encore casser la machine.

Schéma système agrandi

×

Quatre familles de liaisons entourent le CPU. Les branches sont des relations de projet, pas du câblage réseau.

Énumérez chaque projet qui dialogue avec l’unité et confirmez, pour chacun, comment il serait mis à jour ou migré. La liste des équipements issue du dossier réseau est la liste de contrôle naturelle ici, car chaque équipement connecté est une liaison potentielle. Comptez les projets IHM séparément des variateurs, car ils migrent par des outils différents. L’ordre d’énumération suggère aussi l’ordre de restauration, car les dépendances entre liaisons apparaissent à mesure que vous les listez.

Un successeur accepté sans ces contrôles peut arrêter une machine pour des raisons qu’aucune plaque signalétique ne montre. Les liaisons sont invisibles sur l’unité même ; elles vivent dans les projets qui l’entourent, et voilà pourquoi l’énumération, pas l’intuition, est la preuve. L’énumération dit aussi combien de temps prendrait une restauration si le successeur est accepté.

Construisez la liste des liaisons à partir du dossier réseau plutôt que de mémoire. La liste des équipements connectés, les noms des projets IHM et les références des variateurs sont déjà consignés dans le contexte réseau si l’armoire a été documentée plus tôt, et l’énumération devient alors surtout une formalité de relevé. Là où le dossier manque, notez la lacune au lieu de supposer que la liaison n’existe pas. Une liste vide supposée est la version de cette vérification qui échoue.

Terminez la comparaison par un verdict explicite par point : conforme, non conforme ou non résolu. Un successeur avec trois points conformes et un point non résolu n’est pas accepté. Il est en attente. Le dossier doit dire quelle preuve résoudrait le point ouvert, pour que la décision ne glisse pas sur la force de ses contrôles les plus solides. L’attente est une issue normale, pas un échec du processus.

Schéma système agrandi

×

Les verdicts sont par point, pas par unité. Une seule ligne non résolue maintient toute la décision en attente.

Gardez le dossier de comparaison séparé de la décision de commande. Le dossier dit ce qui a été comparé et ce qui a été trouvé. La décision dit qui a approuvé la suite et quand. Séparer les deux permet à un vérificateur de distinguer plus tard un écart documenté d’un écart non documenté, et elle offre à la prochaine migration sur la même machine un point de départ qui existe déjà.

Traitez le résultat comme conditionnel tant que le successeur n’a pas été contrôlé contre le vrai projet. Les comparaisons matérielle, firmware et projet réduisent le risque. Elles ne transforment pas un successeur en remplacement direct prouvé. Le dossier honnête dit ce qui a été vérifié sur le papier et ce qui reste à prouver sur la machine, et cette distinction est exactement ce dont une décision vérifiée a besoin. Ce qui reste à prouver sur la machine est précisément la liste qu’un plan de mise en service devrait absorber.

• Comparez entrée d’alimentation, étage de sorties, E/S intégrées, montage et ports réseau en paires écrites.
• Contrôlez les exigences de firmware par rapport aux versions du projet et du logiciel d’ingénierie, avec des sources citées.
• Listez chaque projet qui dialogue avec le CPU : IHM, variateurs, E/S déportées et tout programme de sécurité.
• Un point non résolu signifie en attente, pas accepté. Dites quelle preuve le clôturerait.

• notre couverture automates et CPU
• le guide de planification pour CPU obsolète
• pourquoi le contexte réseau change un remplacement