Quels PLC fonctionnent avec MSF ? Des drivers natifs pour Siemens, Allen-Bradley, Schneider, Beckhoff, Mitsubishi, Omron, Delta, Keyence et WAGO

Toute évaluation d’un MES arrive au même moment : l’automaticien lève les yeux et demande « très bien, mais est-ce qu’il parle vraiment à nos PLC ? ». C’est la bonne question — la connectivité machines est l’endroit où la digitalisation de l’atelier réussit ou meurt en silence. Alors, au lieu du vague « nous supportons tous les grands constructeurs » habituel, voici la vraie matrice de compatibilité MSF, driver par driver.

Siemens : communication S7 native (S7comm / Step7) plus S7-Light pour les contrôleurs compacts — de quoi couvrir des vétérans S7-300/400 jusqu’aux gammes S7-1200/1500. Rockwell Automation / Allen-Bradley : drivers natifs AB-ETH, Logix et DF1, si bien que ControlLogix, CompactLogix et les anciennes familles PLC-5/SLC remontent toutes en direct. Schneider Electric : UMAS natif, le protocole que les contrôleurs Modicon parlent réellement entre eux.

Beckhoff : ADS natif, la voie directe vers les systèmes TwinCAT. Mitsubishi Electric : MC Protocol natif sur les séries FX et Q. Omron : FINS natif. Delta : le protocole natif DVP. Keyence : le protocole natif KV. WAGO : le protocole natif propre à WAGO. Neuf familles de constructeurs où MSF lit le contrôleur dans sa langue maternelle — pas de boîtier passerelle, pas de licence middleware, pas de « veuillez d’abord mettre à niveau votre PLC ».

Les drivers natifs comptent pour une raison simple : fidélité et vitesse. Parler S7 à un Siemens ou ADS à un Beckhoff, c’est lire les vrais blocs de données et symboles que les ingénieurs maintiennent déjà, à des cadences proches du cycle, sans traduction intermédiaire qui perd du contexte ou ajoute de la latence. C’est aussi une mise en service qui se mesure en heures — pointez le driver sur l’IP, mappez les tags, regardez les données circuler.

Pour tout ce qui dépasse ces neuf-là — ou là où les standards de l’usine l’exigent — MSF parle les protocoles ouverts : OPC UA d’abord (le standard indépendant des constructeurs sur lequel l’industrie a convergé), Modbus TCP et Modbus RTU pour l’énorme parc installé de variateurs, compteurs et contrôleurs anciens, EtherNet/IP dans les usines centrées Rockwell et Omron, et MQTT là où un pipeline publish-subscribe apprécié des équipes IT convient mieux. En pratique, la question n’est jamais « peut-il se connecter » mais « laquelle de trois options fonctionnelles préférons-nous ».

Les usines qui exploitent un SCADA ou un serveur OPC ont une troisième voie : MSF se connecte au serveur OPC UA/DA existant et consomme l’arborescence de tags déjà entretenue. Pas d’accès direct aux PLC, pas de nouvelles connexions sur le réseau de contrôle, des données standardisées et indépendantes des constructeurs — souvent le chemin le plus rapide dans les environnements réglementés ou prudents en matière de sécurité, où personne ne veut d’un appareil de plus parlant directement aux contrôleurs.

Et les machines sans PLC digne de ce nom — la presse de 1995 avec son armoire à contacteurs ? C’est à cela que sert le matériel de rétrofit : les modules META Smart I/O se câblent sur les signaux de marche, les compteurs et les alarmes et les publient sur les mêmes protocoles ouverts, tandis que les analyseurs d’énergie de classe iMeter ajoutent les données de puissance par machine. Dans une usine typique, les drivers natifs couvrent la moitié moderne, l’E/S en rétrofit couvre la moitié vétérane, et le MES voit un flux cohérent unique venant des deux.

Les listes de compatibilité vieillissent ; le principe de fonctionnement compte donc plus que n’importe quel instantané : si votre contrôleur parle S7, AB-ETH, Logix, DF1, UMAS, ADS, MC, FINS, DVP, KV, un dialecte WAGO, OPC UA, Modbus TCP/RTU, EtherNet/IP ou MQTT — MSF lui parle dès aujourd’hui. Apportez votre liste de contrôleurs à une démo et nous la mapperons en direct ; la conversation connectivité prend généralement quinze minutes, soit exactement le temps qu’elle devrait prendre.