Connecter OPC UA à Siemens S7-1500
| Produit | Siemens S7-1500 |
|---|---|
| Catégorie | PLC |
| Rôle OPC UA | Serveur |
Le S7-1500 embarque un serveur OPC UA dans le firmware de la CPU, activé dans TIA Portal et joignable sur opc.tcp://<plc-ip>:4840. Le piège est commercial plutôt que technique : une licence ou une option runtime est normalement nécessaire pour le serveur, et cette licence comme le niveau de firmware minimum doivent être confirmés auprès de Siemens.
Avant de commencer
- Un niveau de firmware CPU qui inclut le serveur OPC UA, et la licence ou l'option runtime qui l'active. Aucun des deux ne peut être supposé à partir d'une fiche technique lue une fois ; les deux dépendent de la référence exacte de la CPU.
- TIA Portal dans une version compatible avec le firmware de la CPU. Un projet réalisé sur une version plus ancienne de TIA peut ne pas exposer les paramètres serveur que vous cherchez.
- La licence présente sur la CPU avant que le serveur ne serve. Traitez l'acquisition de la licence comme un délai au planning du projet, pas comme une étape de configuration à faire le jour de la mise en service.
- Un chemin réseau vers le port TCP 4840 depuis l'endroit où tourne le client, ou un dispositif de reverse connect si la CPU se trouve sous une frontière de niveau Purdue qui n'autorise que les connexions sortantes.
- Une horloge disciplinée. La CPU valide les périodes de validité des certificats : un décalage d'horloge entre l'automate et le client se présente donc comme un défaut de certificat plutôt que comme un problème d'heure.
Mise en place
- Activez le serveur dans les propriétés de la CPUDans la configuration d'appareil, ouvrez les propriétés de la CPU et repérez les réglages du serveur OPC UA. Activez le serveur et notez l'endpoint indiqué par TIA, normalement opc.tcp://<plc-ip>:4840. Définissez le nom d'application délibérément : il se propage dans l'ApplicationUri et dans le certificat d'instance d'application de la CPU, et le changer plus tard invalide toutes les relations de confiance que vous avez établies.
- Décidez tag par tag ce qui est exposéLes tags de l'automate et les membres de blocs de données portent des attributs d'accessibilité qui déterminent s'ils sont visibles pour l'IHM et pour OPC UA et s'ils peuvent être écrits. Un tag dont l'attribut de visibilité est décoché n'apparaît tout simplement pas dans l'espace d'adressage ; un tag visible mais non accessible en écriture apparaît puis refuse l'écriture. Réglez ces attributs comme une décision d'interface délibérée, et non en laissant les valeurs par défaut.
- Construisez une interface serveur plutôt que d'exposer tout le programmeTIA permet de définir une interface serveur : un ensemble choisi de nœuds, avec les noms que vous décidez, découplés des noms de symboles internes. Faites-le. Vous obtenez un contrat stable : un refactoring interne du programme ne casse pas le client, et l'espace d'adressage reste assez réduit pour qu'un serveur embarqué le parcoure rapidement.
- Mappez une spécification compagnon sur l'interface si vous en avez uneImportez le fichier NodeSet2 de la spécification compagnon avec SiOME, mappez les tags automate sur les variables du modèle, et réexportez le résultat dans le projet TIA sous forme d'interface serveur. Le client parcourt alors MachineIdentificationType et une machine à états plutôt qu'une arborescence de blocs de données, et le même code client fonctionne sur la machine suivante.
- Configurez la sécurité et les certificats avant de configurer les donnéesChoisissez les politiques de sécurité et les modes de sécurité des messages que la CPU proposera, tranchez entre jetons d'identité anonyme et nom d'utilisateur, et générez le certificat serveur de la CPU via les paramètres de sécurité globaux du projet. Le certificat doit porter dans son Subject Alternative Name chaque nom d'hôte et adresse IP qu'un client composera réellement, ainsi que l'ApplicationUri sous forme d'entrée URI.
- Compilez, chargez, puis parcourez avec un client indépendantChargez la configuration matérielle, puis connectez-vous avec UaExpert ou opcua-commander d'abord sur un endpoint de sécurité None, pour prouver l'accessibilité, et seulement ensuite sur un endpoint signé et chiffré. La première tentative sécurisée échoue normalement avec BadCertificateUntrusted ; déplacez le certificat client de la liste des rejetés de la CPU vers sa liste de confiance, et faites confiance au certificat de la CPU côté client.
- Lisez le NamespaceArray et résolvez les indices à l'exécutionLisez le NamespaceArray du serveur une fois par connexion, construisez une table de correspondance URI de namespace vers indice, et stockez dans votre configuration l'URI de namespace et l'identifiant. Ne stockez jamais le numéro ns= brut. C'est ce qui empêche le prochain chargement de programme de casser votre client.
- Vérifiez les limites propres à la CPU avant de dimensionner les abonnementsLes caractéristiques techniques de la CPU indiquent le nombre maximal de sessions, d'abonnements et de monitored items, ainsi que les intervalles d'échantillonnage et de publication minimaux pris en charge. Dimensionnez le client sur ces chiffres, et rappelez-vous que le serveur partage la CPU avec le programme cyclique.
À quoi ressemble l'espace d'adressage
Sauf si vous construisez une interface serveur, l'espace d'adressage est une arborescence à la sauce Siemens plutôt qu'un modèle de spécification compagnon : un nœud portant le nom du PLC, avec en dessous des dossiers pour les blocs de données globaux et d'instance, les entrées, les sorties, les mémentos, les compteurs et les temporisations. Les identifiants sont des chaînes qui reprennent les noms symboliques TIA : un membre de bloc de données arrive donc sous une forme telle que ns=3;s="MyDB"."Speed", les éléments de tableau étant indexés dans l'identifiant. Les structures déclarées dans le programme apparaissent comme des valeurs structurées, que votre client ne peut décoder que s'il prend en charge le mécanisme de description de type choisi par le serveur. Une interface serveur remplace tout cela par les noms et la hiérarchie que vous avez définis, et un modèle compagnon mappé avec SiOME le remplace par des types standard sous les URI de namespace standard.
Les pièges
- La licence est le risque de planning le plus courant de toute l'intégration. Un serveur qui ne démarre pas parce qu'une option n'a jamais été commandée ressemble exactement à un problème de pare-feu pendant le premier après-midi. Confirmez les exigences de licence et de firmware en vigueur auprès de Siemens avant que quiconque ne réserve du temps de mise en service.
- Les index de namespace sont attribués au démarrage du serveur et peuvent bouger après un chargement de programme ou un changement de firmware. Un client qui code en dur un numéro ns= échoue alors avec BadNodeIdUnknown sur des nœuds pourtant parfaitement présents. Résolvez les index depuis le NamespaceArray au moment de la connexion.
- Faire accepter le certificat du client par la CPU est en pratique le plus gros obstacle de déploiement, et c'est une opération à deux sens : le client doit faire confiance à la CPU et la CPU doit faire confiance au client. Prévoyez une procédure de liste de confiance, ou une PKI, avant la première machine plutôt qu'après la dixième.
- Un tag visible mais non marqué comme accessible en écriture acceptera la requête d'écriture et renverra un statut Bad. Relisez toujours après écriture pendant la mise en service, et vérifiez le StatusCode renvoyé plutôt que de vous fier à l'absence d'exception.
- Les serveurs embarqués supportent des limites de sessions, d'abonnements et de monitored items bien plus basses qu'un serveur sur PC. Trois clients ouvrant chacun leur propre session avec leur propre intervalle de publication peuvent épuiser une CPU qu'un seul client bien conçu ne dérangerait pas.
- Le comportement des horodatages sur les serveurs embarqués dans les automates est souvent sommaire : le SourceTimestamp n'est parfois pas plus informatif que le ServerTimestamp, et l'horloge de la CPU peut être en heure locale sans décalage indiqué. Décidez quel horodatage vous stockez, vérifiez ce que la CPU renseigne réellement, et gardez NTP actif partout.
- Les périodes de validité des certificats sont contrôlées par rapport à l'horloge de la CPU. Une CPU qui a perdu son horloge lors d'une longue coupure rejette des certificats valides avec une erreur de temps jusqu'à ce que l'horloge soit corrigée.
En extraire les données OEE
Vous pouvez obtenir la disponibilité, les comptages et les motifs depuis un S7-1500, mais uniquement ce que le programme calcule. Rien n'est normalisé par défaut : l'état provient du booléen ou de l'entier qu'a choisi le programmeur, les comptages du compteur qui existe, et les motifs des mots de défaut. Demandez un modèle d'état et un compteur dans le PLC plutôt que de détecter les fronts d'un bit de marche dans votre client, car le client ne voit que des valeurs échantillonnées et manquera les arrêts courts entre deux échantillons. Si le constructeur de la machine accepte de publier une interface serveur mappée sur les types Machinery ou MachineTool, la disponibilité et les comptages deviennent portables d'un fournisseur à l'autre et la mise en correspondance cesse d'être un travail propre à chaque machine. Le temps de production planifié, les calendriers d'équipe, les temps de cycle de référence et le contexte d'ordre de fabrication ne sont pas dans la CPU et doivent venir du MES ou de l'ERP.
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.