Des sources multiples. Un accès commun aux données.
Le Hub relie les applications de supervision aux systèmes qui produisent les données. Il confie chaque accès au connecteur adapté, suit les évolutions des valeurs et les rend disponibles aux applications intéressées.
Comprendre le chemin d’une donnée.
Une application demande des informations pour un équipement. Le Hub organise leur acquisition et leur suivi, tandis que les connecteurs prennent en charge les particularités de chaque source. Beholder peut ainsi exploiter ensemble des données provenant de systèmes différents.
Deux interfaces, un même service.
Côté application, une interface REST reçoit les demandes des consommateurs de données : supervision, synoptique ou processus métier. Côté terrain, les connecteurs accèdent aux sources avec leur protocole propre.
Cette séparation permet de faire évoluer une source ou un connecteur sans imposer son fonctionnement technique à chaque interface utilisateur. Les échanges sont organisés autour des données demandées et de leur évolution.
Une architecture qui sépare les responsabilités.
Les clients expriment leurs besoins, le Hub coordonne les demandes et les connecteurs dialoguent avec les sources. Trois notions structurent ce fonctionnement : le handle, la session et le connecteur.
Le handle : désigner la donnée
Un handle décrit l’accès à une donnée avec un identifiant pour le demandeur, un chemin d’accès et un type de valeur, par exemple un nombre, un texte ou un booléen. Le chemin fournit les informations nécessaires pour sélectionner un connecteur et joindre la source.
La session : suivre une demande
Une session représente un consommateur de données. Elle enregistre les handles qui l’intéressent, récupère leurs valeurs et demande leurs mises à jour. Plusieurs sessions peuvent suivre une même source sans définir la logique du protocole dans chaque client.
Le connecteur : accéder à la source
Le connecteur sait communiquer avec un protocole ou un système donné. Il acquiert les valeurs, indique leur état et informe le Hub de leurs évolutions selon les possibilités de la source.
Un capteur, trois valeurs, deux sources.
Prenons une sonde de température : la mesure courante et les seuils de fonctionnement peuvent provenir de systèmes différents. Le Hub rassemble ces informations pour l’application qui les exploite.
La mesure courante
Un premier handle cible la température exposée par un serveur OPC UA.
Les seuils attendus
Deux autres handles peuvent viser les cellules d’un fichier Excel contenant les seuils minimum et maximum, selon le connecteur déployé.
Le suivi des changements
Une nouvelle mesure ou un seuil modifié devient disponible pour les sessions concernées, selon le mode et la fréquence d’acquisition de chaque source.
Relier des protocoles et des formats différents.
Les connecteurs couvrent des sources telles qu’OPC UA, MQTT, Modbus, des services REST, des bases SQL ou des fichiers Excel et CSV. Les possibilités effectives dépendent des connecteurs installés et de leur configuration.
Le chemin d’un handle décrit la donnée recherchée. Un connecteur compatible prend en charge l’accès, tandis que le client continue d’utiliser l’interface commune du Hub.
De la session à la valeur actualisée.
Le client ouvre une session puis transmet ses handles. Si un chemin est déjà suivi, le Hub lui associe la nouvelle demande et la valeur connue. Sinon, il recherche un connecteur disponible et compatible. L’acquisition produit une valeur, un état et un horodatage, puis les mises à jour sont mises à disposition des sessions concernées. Un accès non pris en charge reste en attente d’un connecteur adapté ; l’état de la donnée permet d’apprécier le résultat de l’acquisition.
Étendre les connexions avec des plugins.
Un connecteur ajoute au Hub la connaissance d’un protocole ou d’une API métier. Vous pouvez compléter les connecteurs existants pour accéder à un système spécifique de votre environnement.
Cette extension conserve le modèle commun des handles et des sessions. L’application de supervision continue de demander les informations dont elle a besoin sans intégrer directement chaque protocole.
Développer un connecteur en .NET.
Les développeurs s’appuient sur les bibliothèques et les contrats de programmation du Hub pour implémenter un connecteur. L’écosystème .NET et Visual Studio fournissent les outils pour dialoguer avec les systèmes à intégrer.
Le connecteur doit gérer l’accès aux valeurs et leur évolution, ainsi que les états de connexion et les erreurs. Son intégration se valide avec les données, les contraintes réseau et les usages du projet.
Une administration accessible depuis le Web.
L’interface d’administration rassemble les connecteurs, les sessions et les handles. Elle permet d’examiner les données en cours de gestion et de comprendre les relations entre les consommateurs et les sources.
Cette vue accompagne la configuration et le diagnostic : identifier une session, vérifier la prise en charge d’une donnée et examiner l’état des connexions. Son accès s’organise selon le déploiement et les responsabilités d’administration.
Conserver l’histoire des valeurs et des états.
Lorsque l’historisation est configurée, les valeurs et leurs états peuvent être enregistrés dans un stockage SQL, sur votre infrastructure ou dans le cloud selon l’architecture retenue.
Ces données permettent de revenir sur une situation passée dans Beholder lorsque le scénario le prévoit, et d’alimenter des analyses ou des restitutions externes. La fréquence de collecte et la conservation doivent être définies en fonction des besoins métier.
Votre prochain projet commence ici.
Passez de la découverte à la pratique avec le Developer Network. Retrouvez les articles techniques, les tutoriels et les ressources pour créer vos cartes, connecter vos équipements et personnaliser Immersive.
Relions votre terrain à vos applications.
Identifions vos sources de données, les connecteurs nécessaires et les conditions de mise à jour pour construire une supervision adaptée à votre environnement.