OPC UA : réussir un premier relevé de données machine

Choisir une décision métier

Commencez par la question à laquelle l’atelier veut répondre : comprendre un arrêt ou suivre un état de fonctionnement, par exemple. Notre proposition est de limiter le pilote à quelques données nécessaires à cette décision. Réunissez exploitation, maintenance, intégration et sécurité pour préciser qui utilisera le résultat. Évitez d’extraire toutes les variables disponibles au seul motif qu’elles existent. Chaque donnée doit avoir un propriétaire capable d’expliquer sa signification et les circonstances dans lesquelles elle devient peu fiable ou indisponible.

Demander un sens commun

L’OPC Foundation présente OPC UA comme une architecture d’échange qui s’appuie sur des modèles d’information. Ses Companion Specifications définissent des modèles pour différents domaines. La présence du protocole ne suffit donc pas à montrer que deux machines expriment exactement le même concept. Demandez quel modèle est implémenté, quelles unités sont utilisées et comment les états sont représentés. Notre fiche de préparation comporte le nom métier, l’identifiant technique, l’unité, la provenance et l’usage attendu de chaque variable retenue.

Faire cadrer les accès

La documentation de sécurité OPC UA précise que ses mécanismes doivent être choisis et configurés en fonction du site. La sécurité globale de l’installation dépasse celle du protocole. Confiez donc à l’équipe compétente la validation des identités, certificats, droits et chemins réseau du pilote. Notre recommandation éditoriale est de demander un périmètre de consultation clairement défini pour ce premier relevé. Ce guide ne fournit aucune procédure de modification d’automate ni de contournement des protections d’un système industriel.

Cas pratique : distinguer un arrêt d’une donnée absente

Une équipe souhaite visualiser l’état d’une machine sur un écran d’atelier. Dans notre exemple, le tableau présente une couleur selon que la machine produit ou s’arrête. La question de réception devient immédiatement plus précise : que montre-t-il lorsque la donnée n’arrive plus ? Si la dernière valeur reste affichée sans indication, une machine peut sembler toujours en production alors que la communication a disparu. Le même défaut peut aussi faire compter un arrêt qui n’a jamais été observé.

La spécification OPC UA décrit un DataValue comprenant la valeur, son statut et des horodatages. Elle précise qu’une valeur dont le statut indique une erreur ne doit pas être interprétée normalement. Nous proposons de définir avec le métier un état distinct « information indisponible » et la manière dont il apparaît dans les graphiques. Demandez à l’intégrateur comment il traite une qualité incertaine, une valeur ancienne et un rétablissement de liaison, selon le système réel. Ces situations doivent être examinées dans un cadre de test autorisé, sans provoquer de panne sur l’atelier. Le livrable attendu inclut les règles d’affichage et de calcul, pas seulement la preuve qu’une valeur numérique apparaît à l’écran.

Recevoir les données avec le métier

Préparez des observations dans plusieurs états de fonctionnement, selon les procédures autorisées de l’atelier. Vérifiez que l’horodatage, l’unité et l’indication de qualité permettent de distinguer une donnée récente d’une valeur ancienne. Demandez ce que voit le tableau de bord lorsque la communication manque. Notre critère de réception est simple : un opérateur et un intégrateur doivent donner la même interprétation à un exemple affiché. Consignez les limites et les responsabilités de maintenance avant d’étendre le relevé à d’autres machines ou à de nouvelles décisions.

Préparer un dictionnaire durable et un périmètre d’usage

Notre fiche de données proposée comporte la signification métier, l’unité, l’origine, les valeurs possibles, la qualité et les limites connues. Ajoutez la version du modèle d’information et un contact responsable de la donnée. Demandez ce qui changera si une machine reçoit une mise à jour ou si un équipement est remplacé. Un identifiant technique stable ne garantit pas à lui seul que l’interprétation métier est restée identique.

Pour les indicateurs calculés, documentez les périodes exclues et le traitement des données manquantes. Un taux construit sur un relevé partiel doit être présenté comme tel. Nous recommandons aussi de séparer les usages autorisés : observation d’atelier, analyse différée ou décision d’exploitation n’impliquent pas la même exigence. Le premier pilote ne valide pas automatiquement un usage temps réel plus critique. Avant extension, faites relire les résultats à une personne de maintenance et à un utilisateur métier, puis consignez les désaccords de vocabulaire. Enfin, prévoyez le maintien des certificats et des droits par les équipes responsables du site. Une connexion OPC UA pérenne repose sur des données comprises, des dépendances connues et une exploitation organisée ; elle ne se résume pas au choix du protocole.