La mise en service a une odeur. Armoires électriques chaudes, poussière de carton, café froid à 2 heures du matin. Et elle a un son que j'ai appris à redouter : le silence d'une ligne de convoyeurs qui devrait tourner.
La semaine dernière, j'étais sur un démarrage dans l'Inland Empire — un 3PL de 80 000 pieds carrés qui traite des retours de vêtements, avec un nouveau WCS à brancher sur un système de contrôle de convoyeurs existant. Une palette est restée morte sur un aiguillage. Le moniteur du WCS affichait, en grandes lettres vertes, « RELEASED ». L'ingénieur de contrôle, devant l'armoire du PLC, regardait ses voyants d'E/S et a dit : « Nous n'avons jamais reçu la libération ».
Nous avons perdu deux jours à cause de cette palette. La cause racine était presque embarrassante : le programmeur du WCS travaillait avec la révision 7 de la table de signaux. Le PLC sur le terrain tournait avec la révision 9. Entre les deux, l'équipe du site avait refait le câblage deux fois et ajouté deux cellules photoélectriques, et personne n'avait mis la table à jour. La demande de libération est arrivée sur une adresse libre qui ne signifiait rien pour le programme du PLC. Personne n'écoutait sur ce canal.
En vingt ans, j'ai vu ce film une douzaine de fois. Le matériel est bon. Les deux logiciels sont bons. Ce qui tue l'intégration, c'est le document entre les deux — la table de signaux d'E/S. Voici comment j'en construis une qui ne revient pas me hanter.
Triez chaque signal dans trois seaux avant d'ouvrir Excel
L'erreur de débutant, c'est d'ouvrir un tableur et de taper ligne après ligne jusqu'à avoir une centaine de signaux sans savoir ce que la moitié d'entre eux fait. Je trie d'abord, je liste ensuite.
Seau un : les commandes, du WCS vers le PLC. Démarrage, arrêt, libération, reset, changement de mode. Une commande qui n'a pas besoin de réponse, je la supprime — si le PLC n'a pas à répondre, vous n'avez rien pour dépanner quand ça tourne mal à minuit.
Seau deux : les états, du PLC vers le WCS. En position, en marche, en défaut, arrêt d'urgence, mode manuel/auto. Les états sont en lecture seule. Le WCS regarde ; il n'écrit jamais. Bien des projets meurent ici même, quand un programmeur WCS prend un raccourci et écrit directement sur un bit d'état que le PLC possède. Deux écrivains, un bit, des signaux qui clignotent à la mise en service, et le bug s'avère être un tir ami.
Seau trois : le heartbeat. Le WCS bascule un bit toutes les secondes ou deux ; le PLC en bascule un en retour. Chaque côté surveille le pouls de l'autre et alarme quand il s'aplatit. C'est l'assurance la moins chère de toute la table, et celle qu'on supprime le plus souvent pour faire des économies. L'argument est toujours le même : « le switch réseau alarmera si le lien tombe ». Une alarme de switch vous dit que le câble est tombé. Un heartbeat vous dit si la machine à l'autre bout est vivante, morte, ou morte cérébrale avec son programme planté. Ce sont des faits différents, et à 2 heures du matin, la différence compte.
Prenez « libérer une palette » comme exemple. Il faut exactement quatre signaux : demande de libération (WCS vers PLC), demande reçue (PLC vers WCS), libération terminée (PLC vers WCS), plus le heartbeat. Quatre signaux, un travail, une propriété limpide. Toute ligne de la table qui ne peut pas répondre à « à quoi ça sert, qui l'écrit, qui le lit » est supprimée. Une table de signaux n'est pas meilleure parce qu'elle est plus longue. Chaque signal non maintenu est un suspect de plus quand la mise en service déraille.
Le handshake en trois étapes, et pourquoi deux étapes vous brûleront
Mon diagramme de temps a trois étapes et je ne négocie pas là-dessus. Le WCS positionne « demande de libération ». Le PLC le voit et positionne « demande reçue ». Le PLC exécute la libération, la palette arrive, et le PLC positionne « libération terminée ». Le WCS voit « terminée » et réinitialise « demande ». Le PLC voit « demande » disparaître et réinitialise « terminée ». Boucle complète, retour à un état de repos propre.
Pourquoi trois étapes ? Parce que j'ai personnellement payé pour les deux raccourcis. Raccourci un : le WCS tire et oublie. La demande part, le PLC la rate sur un rebond de signal, la palette ne part jamais — mais le WCS croit qu'elle est partie et envoie la tâche suivante. Toute la ligne se bloque. Raccourci deux : le PLC agit mais ne rend jamais compte. La libération a eu lieu, le WCS ne le sait pas, il expire et renvoie la demande, et la même palette est libérée deux fois. L'aiguillage en aval devient un derby de démolition.
Le but du handshake en trois étapes, c'est une boucle fermée : rien n'avance tant que l'étape précédente n'est pas confirmée, et rien ne se réinitialise tant que la réinitialisation n'est pas vue. Il y a un bonus dont personne ne parle. Si l'un des côtés perd le réseau ou se bloque, le handshake se fige au milieu d'une étape — visiblement, bruyamment, avec une alarme. Figé, c'est bien. Ce qui vous tue, c'est la défaillance silencieuse, celle que vous découvrez trois palettes plus tard quand les dégâts sont déjà faits.
La checklist de pré-mise en service que je passe sur chaque site
Table terminée, code écrit — n'allez pas encore à l'intégration de ligne complète. Faites d'abord ces tests élémentaires. Ils économisent à peu près la moitié des larmes de la nuit de mise en service.
Anti-rebond d'abord. Les cellules photoélectriques et les détecteurs de proximité rebondissent sur le front mécanique. Quelques dizaines de millisecondes d'anti-rebond d'entrée dans le programme du PLC, c'est la mise de base. Et le côté WCS ne devrait pas non plus faire confiance à un seul balayage — exigez deux balayages consécutifs avant d'accepter un changement d'état. Le rebond est invisible en test et apparaît exactement quand le volume culmine.
Auditez les adresses. Prenez la table et vérifiez chaque signal contre l'adresse réelle dans le programme du PLC, un par un. Les recâblages sur site et les ajouts de dernière minute arrivent sur chaque projet ; la révision de la table et celle du programme doivent correspondre. Ma règle désormais : la table porte un numéro de révision, et ce numéro apparaît à la fois dans les commentaires du programme du PLC et dans la configuration du WCS. Le désastre révision-7-contre-9 de mon histoire d'ouverture, c'est exactement ce que ça empêche.
Tirez le câble. Débranchez un câble réseau et chronométrez le temps que met le WCS à remarquer que le PLC a disparu — c'est votre test de heartbeat. Appuyez sur l'arrêt d'urgence et vérifiez que l'état « arrêt d'urgence » vu par le WCS correspond à ce que la machine a réellement fait. Un principe ici : le circuit d'arrêt d'urgence lui-même fonctionne sur des relais de sécurité câblés. Le « statut d'arrêt d'urgence » envoyé au WCS n'est qu'un miroir. Ne suspendez jamais une fonction de sécurité à un signal logiciel.
Testez le signal de mode. Quand le PLC passe en manuel, le WCS doit le savoir — et doit arrêter d'envoyer des tâches. J'ai une fois vu un WCS continuer à envoyer des libérations pendant qu'un technicien avançait le convoyeur à la main. Une palette a été poussée dehors par une commande de libération que personne n'attendait. Personne n'a été blessé, mais c'était de la chance, pas du design. Le mode est un sujet de sécurité, pas une option.
Puis faites-le tremper. Deux heures de marche continue, avec un arrêt d'urgence aléatoire, une coupure réseau aléatoire et une intervention manuelle aléatoire en chemin. Le temps de mise en service est le temps le plus cher du projet. Répéter les pannes vaut mieux que les jouer devant le client.
Si vous entrez demain sur un site de mise en service, apportez une chose : une table de signaux imprimée, signée par les deux parties, avec un numéro de révision correspondant au code. Cela seul bloque la moitié des modes de défaillance. La checklist ci-dessus gère le reste, un élément à la fois.
Traduit de l'anglais. En cas de divergence, la version anglaise fait foi.
