Une machine-outil de vingt ans peut être parfaitement capable de produire, alors même qu’elle reste incapable d’expliquer ce qu’elle fait à un dashboard moderne. C’est là que le retrofit devient séduisant : garder le PLC, ajouter un petit boîtier sur le rail DIN et extraire les mesures utiles sans remplacer une commande qui fonctionne encore.
Edge Link, construit par Mukesh Sankhla autour d’un Arduino UNO Q, montre exactement cette idée.1 Mais son prototype révèle aussi la frontière qu’un article enthousiaste peut facilement faire disparaître : lire une vieille machine et lui donner des ordres à distance sont deux projets différents.
J’ai audité le tutoriel et le dépôt public au commit 2047540, et la démo actuelle se tient bien comme passerelle de télémétrie et plateforme d’analyse locale, tandis que le code publié ne ferme pas encore une boucle de commande avec un PLC industriel réel.
Ce qui tourne
Le boîtier tient sur un rail DIN et, à l’intérieur, l’UNO Q combine un microprocesseur Qualcomm capable d’exécuter Linux avec un microcontrôleur STM32U585 chargé des interactions plus proches du matériel.18
Cette séparation convient bien au rôle imaginé : le MCU peut s’occuper des entrées, sorties et communications déterministes, tandis que la partie Linux gère Python, la télémétrie, l’interface Web, le cloud et les modèles Edge Impulse.1
Le prototype possède aussi des LED d’état et un bornier six voies. La nomenclature du tutoriel relie ce bornier à Rx, Tx, deux masses, VIN 7–24 V et 5 V.1 Ce détail compte : l’appareil démontré expose une liaison série logique. Un raccordement RS-485, RS-232 ou CAN réel demanderait le transceiver et l’adaptation électrique correspondants ; le tutoriel les présente d’ailleurs comme des options de retrofit à ajouter selon la machine.1

La différence entre « peut supporter Modbus » et « ce montage est un convertisseur RS-485 industriel prêt à brancher » commence ici.
Le faux PLC
Sankhla est très clair dans la conclusion de son tutoriel : il n’avait pas accès à une vraie ligne de production ni à un PLC industriel.1
Il a donc écrit en Python un jumeau numérique inspiré d’un Siemens S7-300. Le simulateur reproduit cinq stations d’une ligne de fabrication d’ampoules LED, un cycle OB1 d’environ 10 ms, des blocs mémoire, les entrées et sorties, les alarmes, les compteurs, les recettes, la puissance consommée et des défauts injectables.3
Le trajet réellement testé est simple :
PLC simulé sur PC → série/UART → Edge Link → HMI, stockage cloud et modèles locaux.13
Le repo contient cette chaîne complète. Le serveur Edge Link parse des messages comme PLC_COUNTERS, PLC_TEST ou PLC_ALARM, conserve un historique, alimente son interface et publie les informations structurées vers Firestore.3
C’est déjà un vrai travail d’intégration. Ce n’est simplement pas encore une preuve de compatibilité avec un S7-300 physique, un automate Rockwell de 2004 ou une presse dont personne n’a ouvert le manuel depuis le départ du technicien qui connaissait son protocole.
Lire d’abord
Le point le plus intéressant apparaît en suivant le code, pas la promesse marketing.
Dans la démo publiée, le flux provenant du « PLC » est montant : Edge Link reçoit les informations série et les traite. Le champ nommé send_serial_command dans son interface Web peut prêter à confusion, car le handler correspondant ne renvoie rien vers l’UART du PLC ; il injecte la chaîne dans le parseur local, notamment pour tester les vecteurs d’inférence.3
Les boutons LINE START, LINE STOP, LINE RESET et arrêt d’urgence existent bien dans le projet, toutefois ils appartiennent au serveur Web du simulateur, où ils modifient directement l’état du PLC Python.3 Le dépôt ne montre donc pas encore de canal Edge Link → automate réel.
Le contrôle physique effectivement démontré par la partie MCU reste lui aussi volontairement modeste, puisque les appels RouterBridge pilotent essentiellement les LED d’état du boîtier.3

Pour un premier retrofit, cette asymétrie est plutôt une qualité. Une passerelle en lecture seule peut créer de la valeur sans acquérir immédiatement le pouvoir de modifier le procédé.
Donner un nom
Sortir des nombres n’est d’ailleurs que la moitié du travail, car une vieille machine peut exposer DB12.DBD4, l’adresse Modbus 40127 ou une variable propriétaire dont la signification n’existe plus que dans un classeur et dans la mémoire d’un mainteneur.
L’OPC Foundation décrit exactement ce problème dans son cas d’usage brownfield : les machines existantes portent souvent un modèle implicite, une forme de connaissance tribale qui risque de disparaître lorsque les équipes changent.4
Edge Link choisit un Unified Namespace, ou UNS, pour structurer les informations remontées.1 Dans le dépôt, les données sont organisées par usine, ligne, historiques, tests qualité, alarmes et inférences ML.3
L’intérêt dépasse largement le dashboard. Le vrai retrofit consiste à traduire « registre 17 » en quelque chose qui conserve une unité, un équipement, une signification et un contexte. Sinon on a seulement déplacé l’opacité du PLC vers le cloud, ce qui est une manière très contemporaine de ne rien résoudre.
L’IA locale
Edge Link exécute six modèles Edge Impulse : cinq pour les stations et un pour l’ensemble de la ligne.13 Les variables simulées couvrent vibration, températures, courant, pression, force, mesures optiques ou facteur de puissance selon la station.
L’inférence tourne localement sur l’UNO Q, ce qui laisse au cloud l’historique et les visualisations sans imposer un aller-retour réseau à chaque détection d’état anormal.1
C’est une bonne séparation pour du monitoring. Le tutoriel va plus loin et imagine qu’une décision locale pourrait arrêter une autre machine lorsqu’un problème est détecté ; Arduino évoque même les arrêts de sécurité comme usage possible.2
C’est précisément le moment où il faut changer de niveau d’exigence.
Un modèle qui affiche « vibration anormale » et un modèle autorisé à couper une machine n’ont pas le même impact : faux positif, bug, perte de capteur ou compromission deviennent alors des événements capables d’agir sur le procédé. Une réponse locale très rapide ne transforme pas automatiquement une inférence ML en mécanisme de sécurité certifié.
La porte réseau
Le retrofit ajoute aussi quelque chose que la vieille machine n’avait peut-être jamais eu : un chemin vers des réseaux plus larges.
Pour CISA, il faut réduire au minimum l’exposition réseau des systèmes de contrôle, les placer derrière des pare-feu et les isoler des réseaux métier ; lorsqu’un accès distant devient nécessaire, il constitue lui aussi une frontière de sécurité à concevoir explicitement.56
Ce conseil devient encore plus important si la nouvelle passerelle possède un chemin d’écriture vers le PLC : en lecture seule, la machine devient une source de télémétrie ; en bidirectionnel, la passerelle acquiert une véritable autorité de commande.
Le choix devrait donc être explicite, jusque dans les détails ordinaires qu’un prototype contourne facilement : quelles variables sont lisibles ou modifiables, depuis quelle zone réseau, avec quelle authentification, et que se passe-t-il quand Edge Link tombe, redémarre ou reçoit une valeur incohérente ?
Le vieux PLC n’est pas devenu moins fiable ; on vient simplement de lui ajouter une nouvelle frontière, laquelle doit être traitée avec le même sérieux que la machine qu’elle rejoint.
Le mode test
Le dépôt montre bien qu’Edge Link sait continuer sans Internet : les événements destinés à Firestore sont mis en file dans un fichier local et renvoyés lorsque la connexion revient.3 Cette fonction de store-and-forward est intéressante sur un atelier où le cloud ne devrait jamais conditionner le fonctionnement de la machine.
Mais le guide demande aussi de créer la base Firestore en test mode.3 C’est rapide pour une démonstration, certainement pas une configuration à conserver sur une installation réelle.
La documentation Firebase avertit explicitement que des règles ouvertes utilisées pendant le développement peuvent laisser quiconque atteignant le projet lire, modifier ou supprimer son contenu. Elle demande de ne jamais déployer une règle allow read, write: if true en production.7
Cela ne rend pas Edge Link « non sécurisé ». Il faut plutôt lire le repo pour ce qu’il est aujourd’hui : un prototype fonctionnel dont les hypothèses de déploiement restent encore loin de celles d’un produit OT durci et certifié.
Pas encore libre
Le code du simulateur et de l’application Edge Link est publiquement accessible dans MukeshSankhla/PLC_SIM.3 Au commit audité, GitHub ne détecte toutefois aucune licence et le dépôt ne contient pas de fichier LICENSE.
On peut lire et étudier le code, mais il serait prématuré d’en parler comme d’un projet librement réutilisable sous une licence clairement définie tant que l’auteur n’en a pas ajouté une.
C’est une petite différence pour un prototype personnel ; elle devient importante dès qu’une équipe veut maintenir, modifier et redistribuer ce logiciel pendant les dix prochaines années autour d’une machine censée durer vingt ans de plus.
Moderniser moins
La possibilité de moderniser une seule frontière est finalement plus convaincante que la promesse de transformer d’un coup une ancienne machine en équipement « intelligent ».
Laisser le PLC faire ce qu’il sait faire, copier les mesures utiles, leur donner des noms stables, les mettre en tampon localement et exécuter l’analyse près de la machine permet déjà de moderniser beaucoup de choses sans toucher à la commande ; seul ce qui mérite réellement de sortir de l’atelier remonte ensuite vers le réseau supérieur.
Un canal de commande pourra ensuite être discuté séparément, seulement s’il apporte assez de valeur pour justifier sa nouvelle surface de risque.
Le projet de Sankhla montre déjà très bien cette première moitié et son prototype est probablement plus sain tant que la seconde reste visible comme un chantier d’ingénierie, au lieu de disparaître derrière un joli bouton « START » sur un dashboard.
