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, car 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 basé sur Modbus qu’utilise le propre logiciel d’ingénierie de Schneider pour dialoguer avec les contrôleurs Modicon M340 et M580.

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, sans boîtier passerelle, sans licence middleware et sans « 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 que les ingénieurs maintiennent déjà (sur S7-1200/1500, cela suppose d’activer l’accès PUT/GET et d’utiliser des blocs de données non optimisés dans le projet CPU), à 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. C’est 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, comme 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.