La mise en service virtuelle devient utile lorsque la scène simulée se comporte comme une machine contrôlée plutôt que comme une animation déconnectée. Pour un projet d’automate Mitsubishi, cela nécessite un chemin de données traçable depuis le simulateur d’ingénierie GX, via un serveur OPC compatible, jusqu’aux tags de Factory I/O.

L’objectif n’est pas simplement de faire avancer un convoyeur. Une configuration utile vérifie la propriété des adresses, le sens des signaux, le comportement de la séquence, les interverrouillages, la temporisation, la réaction à une perte de communication et la logique de redémarrage avant même que les E/S physiques soient disponibles.

Un petit convoyeur virtuel peut révéler des défauts de mappage, de temporisation et de récupération avant qu’ils n’atteignent un véritable tableau de commande.

Vérifiez la compatibilité logicielle avant de mapper les tags

« GX Simulator » peut désigner des fonctions de simulation associées à différentes générations de GX Works et familles de processeurs MELSEC. Les produits OPC diffèrent également selon leur version et selon qu’ils prennent en charge OPC DA ou OPC UA. Factory I/O propose des choix de pilotes qui peuvent ne pas prendre en charge toutes les combinaisons de la même manière.

Notez la famille exacte de l’automate, la version de GX Works, le composant de simulation, le produit et la version du serveur OPC, le type d’interface et la version de Factory I/O. Vérifiez ensuite que le serveur OPC peut se connecter à ce processeur simulé. Ne supposez pas qu’une méthode de connexion fonctionnant avec un module Ethernet physique fonctionnera automatiquement avec un simulateur logiciel.

Mitsubishi décrit MX OPC comme un logiciel qui expose les données des automates programmables MELSEC via OPC. Les matériels MELSEC iQ-R plus récents peuvent également utiliser un module serveur OPC UA intégré, mais cette architecture diffère d’un serveur hébergé sur PC et connecté à un automate simulé. Gardez ces chemins distincts dans vos notes de conception et de dépannage.

Établissez le contrat de données avant de configurer le logiciel

Créez une liste d’E/S comportant une ligne pour chaque signal. Incluez le tag Factory I/O, l’adresse du dispositif Mitsubishi, le type de données, le sens, la signification fonctionnelle, l’état par défaut, l’état sûr, l’exigence de mise à jour et le propriétaire. La simulation doit normalement gérer les états des entrées de terrain, tandis que la logique de l’automate gère les commandes des actionneurs.

Cette règle de propriété empêche deux applications d’écrire sur le même point. Un détecteur photoélectrique simulé peut écrire sur un dispositif d’entrée de l’automate, tandis que l’automate écrit une commande de moteur lue par Factory I/O. Si les deux côtés écrivent sur un même tag, l’affichage peut scintiller ou sembler aléatoire, même si chaque connexion individuelle est techniquement active.

Les dispositifs binaires, les mots, les entiers signés, les valeurs à virgule flottante et les tableaux nécessitent une gestion explicite des types. Un client OPC peut afficher une valeur correctement alors que Factory I/O interprète un type ou un ordre des bits incorrect. Commencez par un point booléen et un mot dont les valeurs changeantes sont évidentes. N’étendez la configuration qu’après avoir vérifié le sens et la mise à l’échelle.

Construisez et testez la connexion par couches

Commencez par créer un programme d’automate minimal et exécutez-le dans le simulateur GX pris en charge. Forcez ou faites basculer un dispositif interne connu et vérifiez que le moniteur ladder affiche l’état attendu. Cela confirme que le programme, le processeur sélectionné et le simulateur fonctionnent.

Configurez ensuite le serveur OPC pour cet automate simulé. Ne créez que quelques tags de test. Utilisez le client propre au serveur ou sa vue de diagnostic pour confirmer la qualité, l’horodatage, la valeur et la capacité d’écriture. Une valeur marquée « mauvaise » ou « incertaine » doit être corrigée à ce niveau avant d’ouvrir Factory I/O.

Configurez ensuite le client OPC de Factory I/O et recherchez ou saisissez les tags vérifiés. Mappez un capteur simulé et une commande d’actionneur. Confirmez séparément les deux sens : modifiez l’entrée de la scène et observez la mémoire de l’automate, puis modifiez la sortie de l’automate et observez la scène.

Cette méthode par couches sépare les défauts. Si la mémoire GX ne change pas, le problème vient de la simulation de l’automate. Si GX change mais pas le client OPC, examinez la configuration du serveur et l’adressage des dispositifs. Si le serveur OPC fonctionne correctement mais que Factory I/O reste statique, vérifiez la connexion du client, les noms des éléments, les droits d’accès et le mappage des tags.

La vérification couche par couche permet d’isoler les défauts de configuration de l’automate, du serveur OPC et de Factory I/O.

Tenez compte de la temporisation entre trois systèmes indépendants

Le cycle de l’automate, l’interrogation du serveur OPC, l’abonnement du client et la mise à jour de la physique de Factory I/O ne se produisent pas au même instant. Une impulsion de capteur plus courte que l’intervalle d’échantillonnage combiné peut disparaître avant que l’automate ne l’observe. La charge du réseau ou du PC peut ajouter de la gigue, même sur un poste de travail local.

Les événements importants doivent être conçus pour résister à l’échantillonnage. Un dispositif simulé peut maintenir un état jusqu’à sa confirmation, ou la logique de l’automate peut mémoriser une transition détectée jusqu’à ce que la séquence la consomme. Allonger chaque impulsion est pratique pour les démonstrations, mais peut masquer des défauts de gestion des fronts. Adaptez le comportement de test au capteur physique et à la vitesse de production prévus.

Mesurez le délai effectif de bout en bout au lieu de supposer que le taux de mise à jour OPC configuré représente toute la latence. Lorsque la temporisation est importante pour la séquence, enregistrez la transition de la scène, l’horodatage OPC, l’observation par l’automate, la décision de sortie et l’action résultante dans la scène.

Prévoyez les contraintes d’OPC DA et du poste de travail

OPC DA classique utilise la technologie COM de Microsoft. Lorsque toutes les applications s’exécutent sous le même compte Windows sur un seul ordinateur, la configuration est généralement plus simple. Les configurations distribuées introduisent des problèmes liés à l’identité DCOM, aux autorisations, au pare-feu et aux comptes de service. Une connexion qui fonctionne en session interactive peut échouer après un redémarrage si le serveur OPC démarre sous un autre compte.

OPC UA utilise un modèle de sécurité différent, avec des points de terminaison, des certificats et des stratégies. Il évite DCOM, mais nécessite tout de même la confiance dans les certificats, les autorisations utilisateur et des modèles de données compatibles. Utilisez l’interface effectivement prise en charge par le logiciel sélectionné, plutôt que de considérer DA et UA comme des appellations interchangeables.

Testez volontairement les états de défaillance et de redémarrage

Déconnectez le client OPC pendant que le convoyeur fonctionne. Arrêtez le simulateur de l’automate. Redémarrez le serveur OPC. Rouvrez Factory I/O alors que certaines sorties étaient précédemment activées. La machine ne doit pas reprendre un mouvement dangereux simplement parce que des valeurs obsolètes réapparaissent ou qu’un client se reconnecte.

Définissez la réaction à une qualité de données mauvaise, à une perte de communication et aux valeurs de démarrage. Selon le processus, les commandes peuvent être forcées à l’arrêt, maintenues ou gérées par un arrêt contrôlé. Les entrées peuvent nécessiter un bit explicite d’état de communication afin que l’automate puisse distinguer un état réellement faux de données indisponibles.

Testez également le démarrage à froid, le redémarrage à chaud, la conservation des compteurs, les incompatibilités de recettes, les capteurs obstrués, les arrivées simultanées et la réinitialisation opérateur. Documentez l’état initial de chaque tag inscriptible ainsi que la séquence nécessaire pour passer en mode automatique.

Transformez la cellule virtuelle en banc de test

Utilisez des cas d’acceptation reproductibles : aucun actionneur avant les autorisations de démarrage ; un comptage pour chaque produit ; un arrêt contrôlé à la cible ; une temporisation dépassée en cas de capteur obstrué ; un défaut en cas de perte de communication ; et une récupération prévisible après reconnexion. Les tendances des tags et les relevés réussite/échec fournissent des preuves plus solides que des captures d’écran d’une scène en mouvement.

Les options d’automates Mitsubishi peuvent être consultées dans la collection Mitsubishi Electric, tandis que le matériel d’automatisation plus général se trouve dans la collection Systèmes PLC & PAC.

OPC n’est que la couche de transport. La valeur d’ingénierie apparaît lorsque la cellule virtuelle devient un environnement de test reproductible du comportement de l’automate, de la propriété des signaux, des hypothèses de temporisation, de la réaction aux défauts et de la logique de redémarrage qui seront transposées à la machine physique.