Le Hub
Une couche d'abstraction événementielle, universelle, flexible, quel que soit le protocole ? C'est ce que permet le Hub. En ingérant des demandes hétéroclites issues d'outils de supervision, le Hub peut déterminer le protocole le plus adapté pour joindre cette donnée. Il s'assurera au travers d'une façade fonctionnelle unique, que les clients demandeurs soient tenus au courant de toute évolution d'état ou de valeur de cette donnée.
Présentation
Un Hub a pour rôle de recevoir des demandes issues de consommateurs de données IOT dédiés à la supervision ou à la maintenance et de fournir en réponse une information adaptée aux besoins de ses consommateurs.
Le Hub expose deux façades de connexion, la première, dédiée aux clients/applicatifs consommateurs de données IOT, permet de pouvoir contacter le Hub et de lui envoyer des requêtes au travers d’une façade REST. La seconde façade, technique, permet au Hub de récupérer des données au travers d’un protocole dédié.
Architecture
Le Hub repose sur une architecture N-Tiers ou la source est le protocole et le client l'outil de supervision'.
En interne, le Hub repose sur trois notions :
- Le Handle
- La Session
- Le Connecteur
Handle
Le Hub repose sur une architecture N-Tiers ou la source est le protocole et le client l'outil de supervision'.
Les handles représentent une route d’accès à une donnée. Elle se compose :
- D’un identifiant unique pour le demandeur associé à cette donnée
- D’un path, représentant « la chaîne de connexion » vers la donnée
- D’un type de données représentant la nature de la donnée ciblée (booléen, chaine de caractères, entier …)
Le path doit permettre de déterminer le protocole et les moyens pour accéder à la donnée. Il s’apparente à une chaine de description qui permet au Hub de lancer la bonne technologie/protocole de connexion et de savoir comment « joindre » la donnée pour la récupérer.
Prenons l’exemple d’un équipement « capteur de température ». Celui-ci pourrait être associé à trois propriétés :
- La température courante détectée.
- La température minimale acceptée au-dessous de laquelle une alerte doit être générée.
- La température maximale au-dessus de laquelle une alerte doit être déterminée.
Imaginons maintenant que la première propriété est une donnée accessible au travers du protocole OPC UA et que les deux suivantes puissent être accessibles via un fichier excel stocké sur une GED comme un Sharepoint.
Les trois paths ainsi nécessaires pour avoir les données de ce capteur de température seraient respectivement :
• ns=3;s=BAT6062.ETAG2.TEMP.T652145
• XLSX://SITE/GESTBAT/QUALITVIE.xslx?Sheet=Temps&col=C&cell=22
• XLSX://SITE/GESTBAT/QUALITVIE.xslx?Sheet=Temps&col=D&cell=22
Charge au Hub d’interpréter ces paths, d’accéder à la donnée et de toujours renvoyer aux acteurs logiciels intéressés une valeur à jour de cette donnée.
Si la température change, le Hub va reposer sur le protocole OPC UA pour récupérer la valeur courante, si les seuils maximum et minimum de température acceptables changent, le Hub doit s’assurer de pouvoir lire la cellule du ou des fichiers Excel concernés pour en récupérer la valeur.
Session
Une session représente un accès réalisé par un consommateur (logiciel de supervision, synoptique, ou processus) désirant à la fois accéder à des données mais aussi être tenu au courant des évolutions dans le temps de ces données.
Lorsqu’un bâtiment est supervisé, il expose un nombre déterminé d‘équipements qui eux-mêmes sont associés à des données (ciblées par les Handles). Voir l’exemple de capteur de température dans le point précédent.
Le Hub reçoit, de la part de la session cette liste de Handles. Elle va demander au Hub de récupérer les valeurs liées et d’être tenue à jour de leur évolution à venir.
Ainsi, lorsque le Hub détecte l’évolution de la valeur ciblée par un handle, il veille à ce que la session ou les sessions qui ont demandé à traiter la donnée la reçoivent lorsqu’elles feront une demande de mise à jour.
Connecteurs
Un connecteur représente un canal d’accès à des données au travers d’un protocole particulier (OPC UA, Excel, REST, SQL, Modbus, …).
Un connecteur peut être vu comme un plug’in qui va se rajouter au Hub pour étendre des possibilités. GraphicStream expose une interface de programmation API en .Net permettant de créer un connecteur pour un protocole particulier permettant à une session d’émettre des demandes de supervision de Handles ciblant des données accessibles dans ce protocole.
Le connecteur a deux rôles au sein du Hub :
- Accéder à la donnée
- S’assurer de tenir le Hub au courant des évolutions de ces données dans le temps
Lorsqu’une session émet une demande de Handles. Le Hub va, pour chacun d'eux faire une demande de prise en charge à tous les connecteurs. Si un connecteur gère le protocole exposé par le path d’un handle, il répondra favorablement à la demande du Hub et aura pour charge de tenter de récupérer la donnée et de s’assurer de se tenir à jour des évolutions de cette donnée.
Fonctionnement
Le hub représente une couche d'indirection universelle entre un outil de synoptique (comme Immersive Beholder) et les données.
L'intelligence du Hub réside dans sa gestion des les protocoles et normes nécessaires acceder à ces données.
Le Hub expose la notion de connecteurs. Un connecteur représente un moyen technique et logicielle de contacter une donnée via un protocole.
De nombreux protocoles sont gérés de base par le Hub, comme OPC UA, MQTT, Modbus, Excel, CSV ...
Il est de plus tout à fait possible d'étendre la connaissance du Hub en implémentant ses propres connecteurs pour répondre à un nouveau protocole ou accéder aux données de votre propre SI.
Principe
Le schéma à la fin de ce point montre la connexion d’une session au Hub et la mise en place d’un processus interne pour prendre en charge les handles qui seront émis par la session.
La première étape de tout accès au Hub passe par la création d’une session. Le client va donc émettre une demande d’ouverture de session auprès du Hub.
Si cette demande est acceptée, le Hub renvoie un identifiant de session (un GUID) qui sera employé par le client pour s’identifier dans les futurs échanges.
Lorsque le Hub reçoit une liste de handles à traiter il va déterminer pour chacun d’eux si leur path (chemin de connexion) indiqué est déjà connu.
Si c’est le cas il associe le handle à la session et place la valeur courante connue dans la liste des valeurs à renvoyer à cette session. Le traitement pour ce handle s’arrête là.
Si le handle n’est pas connu au contraire, il va « démarcher » l’ensemble des connecteurs. Le Hub place alors les handles à connecter dans une liste spéciale qui va être dépilée progressivement. Chaque handle ainsi dépilé va être soumis aux différents connecteurs. Les connecteurs capables de prendre en charge la valeur vont se manifester et le Hub leur demandera de gérer ce handle.
Un connecteur qui prend en charge un handle va d’abord tenter d’en récupérer la valeur. Pour cela, il ouvre une connexion dans le protocole ciblé (si ce n’est pas déjà fait) puis tente de joindre le handle. Il construit ainsi une association path, valeur, état et timestamp. L’état permet de préciser la viabilité de la démarche de récupération de la valeur.
Le connecteur renvoie au Hub cette association. Le Hub la stocke en interne et préviens la ou les sessions intéressées par ce path.
Pluginisation
Le Hub représente un système extensible permettant la récupération et le partage de données issues du terrain de manière fiable quelque soit la source.
.
De base le Hub gère un grand nombre de protocoles parmis les plus connus comme OPC UA, Modbus ou MQTT.
Il est possible avec peu de développement d'étendre la connaissance du Hub en implémentant ses propres connecteurs pour accéder à des données via un protocole normé ou une API située dans votre IT.
Visual studio
Profitez de la puissance de .Net et etendez le Hub
Implémenter son propre protocole consiste simplement à référencer une DLL Microsoft .Net et à implémenter une interface dont le contrat permettra au Hub de controller le connecteur ainsi développé.
L'utilisation des technologies Microsoft associé à Visual Studio permet de développer un connecteur rapidement et de profiter de tous les packages et API disponibles dans l'univers .Net.
Flexibilité dans la gestion
Profitez d'une interface Web simple et puissante
Le Hub s'accompagne d'une interface Web permettant la gestion des connecteurs, des sessions et des handles.
L'administration du Hub est simplifié et permet un controle accru des données en cours de gestion.
Historisation
Si le Hub récupère les données pour les partager vers les synoptiques il peut aussi les stocker avec leur état dans un but d'historisation.
Couplé avec Immersive Beholder il est alors possible de rejouer des sessions passées dans un but d'analyse'.
Les données, stockées en SQL en physique ou sur le Cloud peuvent aisément être exploitée par tout les outils de mise en forme Big Data.
Téléchargez le launcher
Installez Immersive, accédez à des démos, commencez votre expérience et apprentissage.
