Connecter OPC UA à KEPServerEX / Kepware

Avant de commencer

• Une licence couvrant chaque driver dont vous avez besoin ainsi que le nombre de clients et de connexions que vous comptez exploiter. Les licences de drivers sont ce qui surprend les projets ; confirmez-les auprès de PTC avant d'arrêter une conception.
• Un hôte Windows disposant des ressources nécessaires pour scruter tous les tags que vous importez, plus une décision sur son statut de machine virtuelle, et sur l'inclusion ou non de cette machine dans le périmètre de patching OT.
• Des chemins réseau depuis l'hôte vers chaque contrôleur sur le protocole industriel, et depuis vos clients vers son endpoint OPC UA.
• Des listes de tags revues, exportées depuis les projets des contrôleurs, pour que l'ensemble de tags importé soit délibéré plutôt que ce que le browse a renvoyé.

Mise en place

1. Construisez délibérément la hiérarchie canal, équipement, tagUn canal porte un driver et ses paramètres de communication, un équipement est un automate sur ce canal, et les tags se rattachent aux équipements. Cette structure à trois niveaux devient votre chemin de browse OPC UA et vos identifiants de NodeId : nommez-la donc pour l'usine, pas pour l'ordre de mise en service.
2. Importez les tags au lieu de les saisir, puis élaguezUtilisez la génération automatique de tags du driver ou l'import d'un export d'automate, puis supprimez ce dont vous n'avez pas besoin. Chaque tag conservé est de la charge de scrutation et un MonitoredItem potentiel, et un serveur sur-importé est la raison habituelle pour laquelle l'hôte d'une passerelle chauffe.
3. Réglez les scan rates par device et par groupe de tagsLe scan rate du device est la vraie résolution de tout ce qui vient ensuite. Donnez aux compteurs et aux mots d'état un groupe rapide, aux analogiques un groupe lent. Aucun intervalle d'échantillonnage OPC UA ne peut être plus fin que la scrutation qui l'alimente.
4. Configurez l'endpoint OPC UA dans le gestionnaire de configurationL'endpoint OPC UA, ses politiques de sécurité et sa liste de confiance client se configurent dans le gestionnaire de configuration séparé, et non dans l'arborescence principale du projet. Notez que les changements d'endpoint et de certificats exigent généralement de réinitialiser ou de redémarrer le service runtime avant de prendre effet.
5. Approuvez explicitement le certificat clientConnectez-vous une fois depuis votre client, laissez échouer, puis approuvez le certificat client dans la liste de confiance clients du configuration manager, et faites confiance au certificat du serveur côté client. C'est sur cette étape à deux faces que calent la plupart des intégrations le premier jour.
6. Vérifiez ce qui se passe quand l'automate disparaîtCoupez la connexion à l'automate et observez le côté OPC UA. Vous voulez que les items concernés remontent un statut Bad plutôt qu'une valeur figée présentée comme bonne, car tout calcul de temps d'arrêt en aval dépend de la capacité à distinguer les deux.
7. Notez l'URI d'espace de noms et le format des identifiantsLisez le NamespaceArray et notez l'URI de l'espace de noms des tags. Les identifiants suivent le chemin channel, device et tag : stockez donc l'URI d'espace de noms plus la chaîne d'identifiant dans la configuration, et résolvez l'index à la connexion.

À quoi ressemble l'espace d'adressage

L'espace d'adressage reflète l'arborescence du projet : un espace de noms contenant des nœuds dont les identifiants de type chaîne sont le chemin pointé channel, device et tag, si bien qu'un tag arrive sous une forme comme ns=2;s=Channel1.Device1.MachineState. C'est une liste de tags avec des dossiers, pas un modèle d'information. Il n'y a pas d'identité machine, pas de machine d'état standard, pas de compteur standard et pas de contenu de spécification companion, et il ne peut pas y en avoir, parce que le driver ne voit que ce que le protocole industriel expose. La discipline de nommage que vous appliquez aux channels, devices et tags est donc la seule sémantique dont disposeront vos consommateurs, ce qui justifie de traiter l'arborescence du projet comme une interface publiée avec un processus de gestion des modifications, plutôt que comme une configuration interne.

Les pièges

• Les licences de drivers et de connexions sont le risque planning. Un projet qui découvre en pleine mise en service qu'une deuxième famille de contrôleurs demande une autre licence de driver perd des jours en achats, pas en ingénierie. Établissez la portée des licences avec PTC dès le départ.
• Les horodatages naissent au scan de la passerelle, pas dans l'automate. Le SourceTimestamp correspond en pratique à l'instant de l'interrogation : la chronométrie des événements est donc quantifiée à la cadence de scrutation. S'il vous faut des instants de transition précis, horodatez dans le PLC et publiez cela comme une valeur.
• Renommer un channel, un device ou un tag change l'identifiant du NodeId et casse tous les clients qui l'avaient stocké, avec BadNodeIdUnknown sur des nœuds qui semblent toujours présents. Renommer lors d'un rangement est une vraie cause d'arrêt.
• L'approbation des certificats est le principal obstacle pratique au déploiement, et elle se trouve dans un gestionnaire de configuration séparé dont les ingénieurs qui découvrent le produit ignorent l'existence.
• Les changements d'endpoint et de sécurité nécessitent souvent un redémarrage du runtime, qui coupe tous les clients connectés d'un coup. Planifiez-les.
• Un tag configuré avec un type de données inapproprié se lira mais s'écrira mal, renvoyant BadTypeMismatch ou tronquant silencieusement. Vérifiez le type configuré du tag contre le type réel dans le contrôleur plutôt que de faire confiance à la génération automatique.
• La passerelle est désormais une dépendance de production qui demande sauvegarde, gestion de versions de son fichier projet, correctifs et supervision comme tout autre serveur.

En extraire les données OEE

Une passerelle vous donne des comptages, un signal d'état et des codes motifs, et s'arrête là. Une disponibilité déduite d'un bit de marche scruté manquera les arrêts plus courts que l'intervalle de scrutation et placera les autres de façon imprécise ; le schéma exact consiste donc à maintenir l'état, les compteurs et un code motif dans l'automate et à laisser la passerelle les transporter comme valeurs. Le traitement du débordement et des remises à zéro relève de l'aval et doit être explicite. Rien dans l'espace d'adressage d'une passerelle n'est normalisé : la correspondance entre noms de tags et signification TRS est propre au programme de chaque automate, doit être documentée comme donnée projet, et sera à refaire pour la machine suivante. Le temps de production planifié, les calendriers d'équipe, le contexte d'ordre de fabrication et les temps de cycle standard ne sont ici disponibles à aucun prix de configuration.

Dernière vérification le 7 septembre 2026 par rapport à OPC UA 1.05.07. OPC UA Connect est une ressource pédagogique et n'est pas affiliée à l'OPC Foundation.