Hub : Présentation générale
- Bien démarrer
Formation
Le Hub Immersive représente la couche logicielle réalisant l’interface entre l’exposition de données et leur consommation par le Beholder.
Il représente une couche d’indirection universelle entre un consommateur (un player Immersive Beholder par exemple) et des données, quelques soient les protocoles d’accès à celles-ci.
Présentation générale
Le Hub a pour rôle de recevoir des demandes issues de consommateurs de données IOT destinées à 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 connexions, 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é.
En interne, le Hub repose sur trois notions :
- Le handle
- La session
- Le connecteur
Handles
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
Le path doit permettre au Hub de déterminer le protocole et les moyens pour accéder à la donnée. Il s’apparente à une chaine de connexion 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 valeur courante de la température.
- La température max tolérée.
- La température min tolérée.
Ces trois propriétés pourraient être stockés et récupérables via deux protocoles/technologies différents :
- OPC UA : pour la valeur courante.
- Excel : Pour les seuils max et min tolérés.
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
Le premier path est un chemin d'accès classique OPC-UA : ns=3;s=BAT6062.ETAG2.TEMP.T652145, les deux suivants ont été formattés pour être compris par le Connecteur Excel du Hub : Ils indiquent d'ouvrir le fichiers excel situé dans le path relatif SITE/GESTBAT/QUALITVIE.xslx et de lire les colonnes C et D de la ligne 22.
Charge au Hub d’interpréter ces paths, d’accéder à ces données 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 excels concernés pour en récupérer la valeur.
Le formatage du path permet au Hub de déterminer le protocole à employer pour joindre la donnée.
Le Hub n'a aucune idée du rôle métier d'une donnée : ce n'est pas son rôle.
Sessions
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.
La session peut être vue comme une liste de handles.
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.
Connecteur
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. Le Hub possède de base des connecteurs pour un grand nombre de protocoles ou de technologies connus (OPC UA, Excel, MQTT, …).
GraphicStream a développé une interface de programmation API en .Net qui vous permet de créer un connecteur dédié à vos besoins 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
Ainsi lorsqu’une session émet une demande de Handles. Le Hub va, pour chacun deux 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 est donc le logiciel principal, chef d’orchestre gérant le traitement des handles, sessions et connecteurs.
Il peut être comparé à une base de données événementielle qui ; pour chaque donnée traitée ; sait prévenir d’une évolution les acteurs ayant manifesté leur intérêt pour cette donnée.
Connexion d’une session
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.
La seconde étape va consister à créer une liste de Handles à envoyer au Hub. Cette liste est une association entre un handle et son path associé à un identifiant de type entier. Cet identifiant sera utilisé par le Hub lorsque ce dernier renverra une mise à jour de donnée. Pour chaque valeur ciblée par un Handle il indiquera l’identifiant précisée par le session pour ce handle, sa valeur, un état, ainsi qu’un timestamp
Pour résumer, le client émet les données suivants à destination du Hub dans une étape dite de « registration » de handles :
• son identifiant de session<
• une liste de [{id :int, handle}]
Lorsqu’une ou plusieurs valeurs sont détectées comme changées, le Hub renvoie à la ou les sessions intéressées par ces valeurs les données suivants :
• une liste de [{id :int, valeur, date, status}]
Une même session ne doit pas émettre un même identifiant pour deux handles ayant un path différent.
L’identifiant d’un handle est contextuel à la session. Pour un même path, deux sessions différentes peuvent indiquer un ID différent.
Lorsque le Hub reçoit une liste de handles à traiter il va déterminer pour chacun d’eux si le path indiqué est déjà connu.
Si c’est le cas il associe le handle à l’identifiant spécifié par 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évient la ou les sessions intéressées par ce path.
La démarche d’envoi de nouveaux handles au Hub par une session peut être répétée autant de fois que nécessaire. Sur les environnements avec réseau limité il est conseillé de multiplier les appels pour en réduire la taille.
Si un Handle ne peut pas être pris en charge par un connecteur il reste dans le pool de Handle à prendre en charge jusqu’à ce qu’un connecteur accepte de le traiter ou qu’un nouveau connecteur compatible soit ajouté au Hub.
Mise à jour en interne d’une donnée
Le schéma suivant explicite en interne, la mise à jour d’une donnée ciblée par un handle pris en charge. Nous avons vu dans le point précédent que si une donnée intéresse une session une liste d’associations d’identifiants et handles associés est préparée en attendant que la session émette une demande de récupération de mises à jour.
La détection d’une mise à jour de valeurs est à la charge du connecteur. Si le connecteur se base sur un protocole dit ‘evenementiel’ il va attendre un événement indiquant le changement de valeur. Si le connecteur est basé sur une démarche active, il ira régulièrement requêter la source de données pour y détecter les éventuels changements sur les valeurs qu’on lui a demandé de prendre en charge.
En cas de detection de changement le connecteur préviens le Hub du path concerné, de la nouvelle valeur éventuelle, d’une date de modification de cette valeur ou de l’état et d’un état.
Le Hub va analyser ces informations et déterminer la, ou les sessions interessées par ce path. Si aucun session active n’est intéressée il demande aux connecteurs de ne plus prendre en charge ce path et de le décharger.
Il prépare pour chaque session un nouveau package associant l’identifiant de la session pour ce path, la valeur, l’état et un timestamp qui sera renvoyée à la prochaine demande de récupération des mises à jour émise par la session. Il stocke en parallèle la valeur en l’associant au path en interne. Le package contenant les changements pour une session est vidé lorsque la session le récupère.
Status d'un handle
Dans certains cas, l’accès à handle par un connecteur n’est pas possible (soucis de configuration, capteur en panne, infrastructure hs...). Lorsque le hub communique à une session la valeur d’un handle, il doit spécifier son statut.
Voici les différents statuts possibles :
- Unhandled : Le handle ne peut pas être géré par le système.
- UnpluggedConnector : Le connecteur associé au handle n’est pas accessible.
- NoConnectorFound : Le protocole spécifié par le handle ne correspond à aucun connecteur.
- Unreachable : Le connecteur n’arrive pas à récupérer la valeur du handle.
- ConnectorError : Le connecteur est en erreur.
- Good : Le connecteur a correctement récupéré la valeur.
- NeverUpdated : Le handle est bien configuré mais aucune valeur n’est remontée par le système.
- TimedOut : La dernière valeur est trop vieille, elle est time out.
Lorsqu’un statut autre que “Good” est remontée pour un handle donnée, celui-ci apparaitra comme déconnecté dans le système. L’utilisateur pourra au survol de sa variable associée avoir le détail de l’erreur.
Si un client s’est enregistré à un handle, le hub a l’obligation de renvoyer au moins 1 information pour celui-ci, même si le hub ne sait pas comment le traiter ou a un souci pour récupérer sa valeur. Il associe pour ça un des statuts précédents.
Moteur de calcul : traitement des failures
Le hub peut nécessiter l’implémentation d’un moteur de calcul qui sera mis en place pour répondre à des besoins spécifiques métier. Certaines données provenant des capteurs nécessitent un traitement avant d’être exposées aux sessions notamment pour la remontée de défauts.
Pour un capteur de température, le hub peut par exemple associer une liste de défauts liée au dépassement de seuils pour avertir le client d’un défaut : Température trop haute.
Lors de la modification de la valeur d’un handle,, si le moteur de calcul a identifié un défaut, il fournit en plus de la valeur du handle une liste de failures associées qui seront traitées par le player pour afficher la variable associée en tant que défaut dans l’interface.
Lorsqu’une variable évolue dans le temps tel qu’une température, une failure associée peut rester active sur plusieurs mises à jour de sa valeur si sa règle de calcul reste toujours valide. La failure garde l’information de date de l’arrivée du défaut, ainsi si une température a été mise à jour il y a de ça 10 mins, mais qu’elle dépasse un seuil depuis 2h, les 2 informations sont correctement présentées dans les applications clientes.
Les informations inhérentes à une Failure sont les suivantes :
- Le nom
- La date du défaut
- Une liste de métadonnées associées au calcul (le seuil dans le cas d’exemple de la température).
- Un type du défaut. Ces types dépendant du métier, ils doivent être synchronisées entre l’application cliente et les responsables du hub.
Le traitement des failures n’est pas obligatoire pour tous les handles, seulement lorsqu’une règle métier spécifique est nécessaire.
Si un capteur de défaut remonte une valeur boolean avec “true” comme étant le défaut actif, ce handle peut être directement traité comme un défaut dans l’application beholder sans avoir à générer une failure côté Hub.
Etat des connecteurs
En plus des mises à jour des valeurs des handles, le hub a la possibilité de remonter à ses sessions l’état interne de ses connecteurs et la santé du système dans son ensemble.
Ainsi si l’une de ses sources de données est indisponible temporairement, les utilisateurs connectés à un hub sont avertis qu’il y a un problème avec l’un ou plusieurs des sous éléments du système.
L’état des connecteurs est présenté de la façon suivante dans un player Beholder.
L'état des connecteurs est seulement utilisé à titre informatif et n’est pas obligatoire pour le fonctionnement du système.