Que consigner avant de récupérer un CPU d’automate fail-safe ?

Un CPU fail-safe, généralement noté F-CPU, exécute deux programmes à la fois : le programme de contrôle normal et un programme de sécurité distinct que le runtime du fabricant maintient isolé du premier. Vous sortez un CPU, vous lisez la famille et le numéro, et tout semble standard. Puis la machine refuse d’accepter un programme de sécurité. C’est le piège du fail-safe.

Schéma système agrandi

×

La séparation est fonctionnelle, pas physique : les deux programmes tournent sur la même unité, mais le volet sécurité est isolé par le runtime.

Siemens livre des variantes fail-safe dans les familles S7-1200F et S7-1500F, et le marquage F apparaît dans le numéro de commande et sur l’étiquette du boîtier. Le matériel n’annonce pas la différence de lui-même, donc le marquage est la première chose à vérifier et la première à consigner. Un caractère supplémentaire dans le numéro de commande sépare une unité qui accepte un projet de sécurité d’une unité qui ne le peut pas.

Les deux programmes restent séparés par conception. Le programme de sécurité tourne sous ses propres règles de runtime, et le programme standard ne peut pas le modifier. Cette isolation explique pourquoi un CPU standard ne peut pas simplement être chargé avec un projet de sécurité, et pourquoi le statut F façonne chaque question de récupération qui suit.

Vous pouvez repérer le marquage F sans rien ouvrir. Dans les numéros de commande Siemens, la capacité fail-safe figure dans la référence même, et l’étiquette du boîtier porte aussi le marquage. L’outil d’ingénierie l’affiche également, une fois l’unité sur le réseau. Ce que vous ne pouvez pas faire, c’est le déduire du comportement de la machine, car un CPU standard peut exécuter le même procédé jusqu’au moment où quelqu’un tente de charger un projet de sécurité. Le marquage est un fait imprimé, alors traitez-le comme tel et lisez-le.

Le marquage change ce qu’une référence de correspondance doit inclure. Deux CPU qui partagent le numéro de base peuvent différer quant à l’acceptation même d’un programme de sécurité, et cette capacité est liée à l’unité précise et à sa configuration. Voilà pourquoi le statut F figure en première ligne de votre dossier, avant la révision ou les photos.

Schéma système agrandi

×

Le numéro de base ouvre la porte, mais le dossier F décide de ce qui peut la franchir. C’est un contrôle fonctionnel, pas un contrôle de câblage.

Le programme de sécurité et sa configuration F, les réglages qui lient la fonction de sécurité à l’unité, font partie de l’identité d’une seconde manière. Une unité au numéro de commande correct peut encore refuser d’exécuter un projet de sécurité si la configuration ne correspond pas à ce que le projet attend. Aucune valeur de plaque signalétique ne prouve qu’un remplacement acceptera le projet. Cette preuve doit être consignée, jamais supposée. La liste des modules F protège aussi la vérification d’un second piège : un CPU de remplacement qui semble complet sur le papier pendant que l’ensemble configuré autour de lui reste non consigné.

Les modules d’E/S fail-safe connectés, les modules F, appartiennent au même ensemble configuré. Un F-CPU et ses E/S F sont configurés ensemble dans le projet, et une modification d’un membre quelconque de cet ensemble peut exiger la revalidation du programme de sécurité. La question de la correspondance ne s’arrête donc jamais au CPU ; elle s’étend à chaque module F autour de lui. Cette distinction est invisible depuis l’extérieur de l’armoire, et voilà pourquoi le marquage imprimé pèse si lourd.

Pour une demande, la conséquence pratique est le périmètre. Dites que le CPU se trouve dans une application fail-safe même si votre question ne porte que sur le CPU, car le vérificateur ne peut pas savoir si les modules F autour de lui font partie de la question tant que vous ne le dites pas. Un vérificateur qui découvre les modules F en cours de vérification doit rouvrir la prise en charge, et les références des modules F que vous avez listées plus tôt deviennent la raison pour laquelle la vérification n’a pas eu à le faire.

Relevez le numéro de commande complet avec son marquage F, la version du firmware telle qu’imprimée et la génération matérielle. Photographiez la plaque signalétique et tout étiquetage lié à la sécurité dans l’armoire, y compris les panneaux ou documents qui nomment la fonction de sécurité que le CPU sert. Les photographies reproduisent le libellé exactement, et des étiquettes de sécurité reformulées perdent leur sens dans un dossier. Deux sources d’étiquette pour la même unité, c’est normal, et chacune photographiée est un détail en moins à reconstituer de mémoire.

Schéma système agrandi

×

Quatre groupes de consignation alimentent le dossier. Chacun répond à une question que le vérificateur devrait sinon poser deux fois.

Listez les modules F connectés avec leurs propres références. Nommez chaque module F, sa position d’emplacement ou de station, et son numéro de commande complet, de la même façon que vous avez consigné le CPU lui-même. L’endroit où se trouvent les modules compte, car la question de revalidation suit le câblage.

Si une sauvegarde du projet existe, consignez la version du programme de sécurité et l’endroit où la sauvegarde est stockée, à côté de la version du programme standard. Les deux versions peuvent différer, et un vérificateur a besoin des deux pour juger ce qu’une unité restaurée exécuterait réellement. Si aucune sauvegarde n’existe, écrivez ce fait dans le dossier, car il change chaque voie de récupération qui suit. L’emplacement de stockage compte autant que la version ; une sauvegarde que personne ne retrouve vaut une sauvegarde manquante.

L’étiquetage sécurité mérite une passe délibérée. Cherchez les panneaux d’avertissement à la porte de l’armoire, les pochettes de documentation et toute plaque qui nomme la fonction de sécurité que le CPU sert, et photographiez ce que vous trouvez. Ces éléments portent le libellé avec lequel travaillent les vérificateurs sécurité, et une reformulation dans vos notes ne peut pas le reproduire. Si rien n’est étiqueté, consignez cette absence comme un fait, car elle indique au vérificateur quelle part du contexte sécurité n’est pas documentée.

Datez chaque entrée et gardez le dossier factuel. Les opinions sur ce qui a probablement causé un défaut, ou sur ce qu’un fournisseur pourrait avoir en réserve, n’ont pas leur place à côté des faits mesurés. La date transforme une affirmation en entrée de dossier, car un fait sans date ne peut être revérifié contre aucune source.

Schéma système agrandi

×

La confiance vient de trois champs par ligne. Les lacunes énoncées font partie des preuves, pas d’un échec du dossier.

Un dossier daté et sourcé permet à la personne suivante de vérifier chaque ligne au lieu de la reconstituer. Chaque valeur doit porter sa source : plaque signalétique, outil d’ingénierie ou fichier de projet. Quand deux sources se contredisent, consignez les deux lectures au lieu d’en faire une moyenne, et laissez la vérification trancher le conflit.

La même discipline s’applique aux lacunes. Un état de firmware inconnu ou une sauvegarde manquante est un fait sur le dossier, et l’énoncer ouvertement est une preuve plus solide que deviner. Les lacunes indiquent aussi au vérificateur quelles étapes d’identification répéter en premier.

Quand deux sources se contredisent, consignez les deux lectures avec leurs sources et leurs dates, et laissez le jugement à la vérification. Une valeur de firmware issue de l’outil d’ingénierie et une valeur différente tirée d’une liste de pièces sont une découverte normale dans une usine vieillissante, et choisir l’une discrètement transforme votre dossier en affirmation. Deux lectures consignées sont des preuves ; une lecture choisie est une opinion. Le vérificateur tranche le conflit une fois, avec les sources sous les yeux, au lieu de le découvrir deux fois.

Un CPU fail-safe n’est pas une simple question d’échange standard. Le travail lié à la sécurité appartient au personnel qualifié selon les règles applicables à la machine, et aucune entrée de catalogue, aucune fiche technique, aucune affirmation de fournisseur ne change cela. Le dossier de preuves est une donnée d’entrée pour ce travail, pas un substitut.

Schéma système agrandi

×

Le dossier s’arrête là où commence la qualification sécurité. Les flèches montrent le transfert des questions, pas le transfert du travail.

Consignez ce que vous savez et énoncez ce que vous ne savez pas, puis orientez les questions du programme de sécurité vers les responsables de la machine. Un dossier qui liste ouvertement ses lacunes est plus utile à un vérificateur qu’un dossier qui les recouvre. Là où une lacune existe, dites qui la comblerait normalement et avec quel outil.

Traitez la compatibilité et les résultats comme des questions ouvertes dans la demande. Savoir si un remplacement précis accepte le projet de sécurité existant, et savoir si une réparation peut préserver la configuration F, sont des décisions pour la vérification avec les responsables, appuyées par vos preuves. L’incertitude est normale ici, et l’énoncer, c’est ce qui garde une récupération sécurité honnête.

• Relevez le numéro de commande avec son marquage F, la version du firmware et la génération matérielle.
• Listez chaque module d’E/S fail-safe connecté avec sa propre référence et sa position.
• Consignez les deux versions de programme, ou indiquez clairement qu’aucune sauvegarde n’existe.
• Le travail sur le programme de sécurité revient au personnel qualifié. Notez cette limite dans la demande.

• la page catégorie des CPU d’automate
• le parcours des champs de la plaque signalétique
• le dossier de preuves d’une demande automate