Paramétrage de l'application

1. Formats des Messages

   Plusieurs formats standard sont fournis avec l'installation initiale. Ils sont optimisés pour un échange optimale et rapide. L'administrateur peut les modifier pour les adapter à son besoin ou d'ajouter d'autres . La capture ci-dessous montre quelques formats avec leurs descriptions. Un format peut être activé ou désactivé pour contrôler son utilisation par les brokers. Les formats ajoutés peuvent être de type d'échange JSON ou XML ou Protobuf.

   

    

   L'écran du détail sert à ajouter, consulter ou modifier des formats de messages. Les champs visibles sur cet écran dépendent du type d'échange sélectionné. 

   Chaque Format, quelque soit son type , doit avoir générer un schéma équivalent en JSON donnant la possibilité à la plateforme pour comprendre et convertir le message en JSON. Pour Chaque type on trouve alors :

   1. Le nom : Code unique du format, il est utilisé dans le processus de conversion.
   2. Le type d'échange : JSON ou XML ou Protobuf
   3. Définition de message : Structure proto pour le type protobuf ou un exemple de message pour les types JSON ou XML.
   4. Schéma JSON :  l'équivalent du message en schéma JSON , permet de décrire une structure standard pour le message échangé. Le schéma peut être généré automatiquement en cliquant sur le bouton "Générer à partir du message".

    

       - Exemple d'échange en JSON

     

       - Exemple d'échange en protobuf

   

   Pour un échange en protobuf , il faut définir le schéma proto dans le volet gauche. Le système génère alors le schéma équivalent dans lequel le message reçu sera converti et désérialisé en JSON.

   Le nom du format doit porter le même que celui du type proto principal dans le schéma.

   Format PMS 

   

   En créant un format de message avec la case PMS coché , signifie que le message est aligné avec la structure par défaut coté plateforme. Pa conséquent aucune conversion n'est nécessaire et l'acquisition du message sera fluide est optimisée. Les messages PMS peuvent être de type Json, Proto ou XML.

    

2. Cycle de vie des messages

   Le cycle de vie des messages IoT correspond à une succession d'étapes ou de statuts par lesquels ces messages transitent, depuis leur émission par les appareils jusqu'à leur traitement final. Il permet de structurer et de modéliser le parcours des messages, en définissant les différentes phases de réception, de validation, de traitement, et éventuellement de stockage ou d'archivage. Ce mécanisme facilite la gestion, le suivi et l’exécution des processus nécessaires tout au long de la chaîne de traitement des données transmises par les objets connectés.

    

3. Interpréteurs de valeurs d'attributs

   Les Interpréteurs de valeurs d'attributs sont de processus d'analyse ou de comparaison des valeurs des attributs envoyés par les objets connectés dans les messages IoT. 

   Selon le domaine IoT et les attributs concernés, Ils permettent de classer les valeurs reçus selon des niveaux. Ainsi, les flows du système peuvent immédiatement déterminer les messages urgents ou qui ont des valeurs critiques et notifier à temps ou exécuter un processus défini. 

   Les niveaux sont paramétrés dans l'application comme montré par la capture ci-dessous. Un niveau de valeur est défini par  le numéro de niveau, le nom, la description et un couleur qui sera affiché dans les KPI ou les tableaux d'analyses. 

   L'exemple ci-dessous  pour un niveau '5' dont le nom est 'Critical', de couleur rouge, pour une valeur qui dépasse beaucoup la valeur standard.

   

    

   L’application propose deux modes d’interprétation des valeurs reçues des objets connectés. Le mode simple permet de comparer automatiquement chaque valeur à des seuils prédéfinis, afin de savoir si elle est normale, élevée ou critique. Ce mode est facile à utiliser et adapté aux données classiques comme la température ou la pression.

   

   Le mode avancé, quant à lui, est destiné aux administrateurs ou aux développeurs. Il offre la possibilité d’écrire des fonctions personnalisées en utilisant un langage de développement intégré. Cela permet une analyse plus poussée, notamment pour traiter des données complexes comme des images, des fichiers audio ou d’autres types de médias.

    

4. Entités

   Les entités dans IoTRoutes sont de structure hiérarchique et représentent des regroupements, des divisions ou des individus, et se divisent en deux catégories : internes (telles que des filiales, départements ou services) et externes (généralement des clients).

    Leur rôle principal est d'associer des objets connectés à un groupe spécifique, afin de restreindre l'accès des utilisateurs uniquement aux données qui leur sont attribuées. Dans un environnement mutualisé, cela permet par exemple à un client d'accéder uniquement à ses propres objets et à un utilisateur d'un département de n'avoir accès qu'aux données de son service.

   Accessible depuis Application Settings >> Entities , l'écran ci-dessous permet d'afficher et de gérer la liste des entités.

   

    

   L'écran détail montré dans la capture ci-dessous permet la création, la modification des entités ainsi l'association des appareils, l'affectation des utilisateurs et la liaison des sous entités. Un utilisateur affecté à un entité dans la hiérarchie aura accès à l'entité et tous les entités fils.

   

    

5. Paramètres généraux

   Permet de définir et de gérer un ensemble de paramètres essentiels au fonctionnement de la plateforme IoTRoutes ainsi que des processus qui s’y exécutent. Cette section sert de point central de configuration pour adapter l’application à différents environnements ou contextes d’utilisation.

Elle offre la possibilité de créer et d’enregistrer plusieurs configurations distinctes, par exemple :

Une configuration pour l’environnement de production, Une pour les tests, Une autre pour la formation ou la démonstration, etc.

Cependant, une seule configuration peut être active à la fois, garantissant ainsi que l’application fonctionne toujours selon un ensemble cohérent et contrôlé de paramètres.

Cette flexibilité permet d’ajuster rapidement le comportement de l’application en fonction des besoins sans devoir modifier manuellement les paramètres à chaque changement de contexte.

On trouve deux groupes de paramètres comme représenté dans la capture: Paramètres de l'application et paramètres des processus exécutés.

• Topic d'évènements intra-serveurs: Le topic utilisé pour les évènements communiqué entre les serveurs ou les services internes.
• Payload max autorisé : Taille maximale du message envoyé par les objets connectés.
• Enregistrer le Payload comme blob à partir : Taille limite au delà les attributs seront sauvegardés en tant que blob (base de données de media) géré par le gestionnaire de stockage de fichiers.
• Calcul du Timestamp: méthode spécifique de calcul du timestamp permet de convertir la valeur d'une date en valeur entier de petite taille servant à une communication optimisé entre la plateforme et les appareils. Exemple la date sera représentée par le nombre de millisecondes, secondes ou minutes depuis le 01 janvier 2020.

• Intervalle d'actualisation des paramètres:  Les services en exécution continue chargent leurs configurations au démarrage de la plateforme, toute modification des configurations est prise en charge automatiquement à une intervalle spécifiée en nombre de minutes

Suivant :  Les Workflows