Données et intégration

Transmettre les données d’un automate à un tableau de bord web

Conserver le sens et la qualité des lectures autorisées jusqu’à l’écran utilisateur.

Transmettre des données d’automate à un tableau de bord web ne signifie pas connecter directement le navigateur à l’automate. Un collecteur autorisé lit généralement le contrôleur, normalise les informations et les envoie au serveur. L’écran obtient les données permises via une interface applicative, en maintenant une frontière entre réseau de commande et Internet.

Vérifier le sens des signaux

Commencez par la liste des variables ou registres. Bit de marche, code défaut, compteur de cycles et quantité produite se comportent différemment. Leur sens peut dépendre du programme, du mode machine ou de la recette. Confirmez-le avec le responsable de l’automatisme au lieu de déduire la production d’un simple libellé.

Le dictionnaire précise type, échelle, ordre des mots, unité et qualité. Une remise à zéro n’est pas une perte de production. Un bit défaut effacé ne prouve pas l’examen de l’incident. Réglez ces distinctions avant qu’elles deviennent des hypothèses du tableau de bord.

Séparer les responsabilités

Automate → collecteur → validation et stockage → API → tableau de bord utilisateur

Le collecteur gère accès approuvé et charge d’interrogation. Le stockage garde temps d’événement, identité et qualité. L’API contrôle l’accès aux équipements et l’interface explique mesure et âge. Tout réunir sans structure complique le diagnostic.

Le navigateur ne reçoit ni mots de passe d’automate ni privilèges étendus sur le réseau industriel. Authentification et autorisation sont distinctes : se connecter n’ouvre pas toutes les machines, et superviser n’autorise pas automatiquement à commander.

Chronologie illustrative

Une machine expose marche, attente et défaut. Enregistrez les transitions horodatées et définissez la priorité si plusieurs signaux sont actifs. Une coupure de communication devient un intervalle inconnu, pas un état de production à deviner. La distinction doit figurer dans les totaux comme dans le graphique.

À l’ouverture d’un arrêt, montrez les codes défaut et les données justificatives disponibles. Un opérateur autorisé peut confirmer la cause inconnue. Toute correction ultérieure garde auteur, contenu, date et justification au lieu de remplacer discrètement l’ancien enregistrement.

Tester redémarrage et reconnexion

Lire l’état actuel après redémarrage du collecteur ne récupère pas nécessairement les transitions manquées. Un tampon d’événements, un compteur automate ou une autre source peut être nécessaire. Le logiciel n’invente pas les événements jamais enregistrés. La lacune reste visible jusqu’à son comblement par une source fiable.

Rafraîchissement d’écran et interrogation automate sont distincts. Un navigateur actualisé chaque seconde ne démontre pas une nouvelle lecture terrain chaque seconde. Présentez heure source et connexion ensemble. L’âge acceptable découle de la tâche utilisateur.

Liste de mise en service

  • Comparer transitions connues et événements stockés.
  • Mesurer la charge de collecte pendant la production.
  • Vérifier les permissions entre machines et utilisateurs.
  • Tester coupure, redémarrage du collecteur et événements tardifs.
  • Remonter d’un enregistrement affiché jusqu’à la source.

Une première version en lecture seule maîtrise le périmètre. L’ajout de commandes constitue un projet distinct, avec validations, conditions locales et sécurité physique. Un bouton supplémentaire dans une API ne démontre pas une commande distante sûre.

Suivre un événement à travers l’application

Lors d’un exercice illustratif, l’équipe d’automatisme autorisée identifie une transition connue. Consignez son signal et l’origine de l’heure. Suivez l’enregistrement collecteur, l’événement stocké et la réponse API avant le graphique. Si l’intervalle diffère entre couches, les preuves doivent montrer si collecte, conversion ou affichage l’expliquent. Un écran plausible ne suffit pas.

Incluez un changement de produit. Le compteur peut continuer entre recettes tandis que le cycle attendu change. Conservez contexte produit et date d’effet au lieu d’écraser une cible globale. Testez une remise à zéro sans grande quantité négative apparente. Si l’automate n’expose pas assez d’informations, notez la limite plutôt que fabriquer une précision à partir de signaux incomplets.

Demandez le même équipement à l’API avec un compte sans droit. Le serveur rejette même l’identifiant saisi manuellement. Testez également une session expirée avec l’écran ouvert : l’interface indique la fin de l’accès et cesse d’afficher de nouvelles informations restreintes. Le filtrage navigateur est de la présentation, pas une frontière de sécurité.

Organiser les changements avec l’automaticien

La configuration machine évolue. Une variable peut être renommée, un registre réaffecté, une interface modifiée par le firmware. Gardez version approuvée de la correspondance et procédure de vérification des changements. Après maintenance, comparez lorsque possible identité et configuration attendues avant de reprendre l’interprétation en production normale.

La remise comprend un petit message annoté, les priorités d’état, les resets, les permissions et le comportement observé au redémarrage. Précisez qui autorise une nouvelle cadence et quand la tester. Ne l’augmentez pas simplement pour une animation plus rapide : vérifiez actualisation réelle de la source et charge de l’automate.

Apportez modèle, interface de lecture et quelques questions opérationnelles au premier échange. Avez-vous besoin d’état actuel, de compteurs ou d’un historique récupérable ? Ces besoins conduisent à des choix différents et déterminent ce qu’un tableau de bord professionnel peut réellement montrer.

Quelles données devez-vous voir ? Quel procédé pourrait mieux fonctionner ?

Présentez-nous vos équipements et vos besoins. Explorons ensemble une approche adaptée.

Parlons de votre projet