Paramètres de l'application

1- Formats de messages

IoTRoutes propose plusieurs formats de messages standard dès son installation, optimisés pour un échange de données efficace et performant. Les administrateurs peuvent personnaliser ces formats ou en créer de nouveaux pour les adapter à leurs écosystèmes de périphériques spécifiques.

La plateforme prend en charge plusieurs formats d'échange : JSON, XML et Protobuf. Chaque format peut être activé ou désactivé, permettant ainsi aux administrateurs de contrôler les types de messages acceptés et traités par les brokers.

Chaque définition de format de message décrit la structure et l'interprétation des messages de l'appareil par la plateforme.  L'écran de liste ci-dessous permet d'ajouter, de modifier ou de consulter les paramètres d'un format, qui varient selon le type d'échange sélectionné.

Chaque définition de format de message décrit la structure et l'interprétation des messages des appareils par la plateforme.

La vue liste permet d'ajouter, de modifier ou de consulter les paramètres de format de message, qui varient selon le type d'échange sélectionné. Chaque format, quel que soit son type d'origine, doit inclure un schéma JSON équivalent.

Ce schéma permet à la plateforme d'interpréter, de normaliser et de convertir les messages en un modèle JSON interne cohérent, permettant ainsi aux flux de travail, aux interpréteurs et aux modules de stockage de lire et de mapper de manière transparente tous les éléments des messages.

Paramètres principaux :

• Name: Code unique identifiant le format ; utilisé lors du processus de conversion.
• Exchange Type: Indique si le message est au format JSON, XML ou Protobuf.
• Message Definition:
  • Pour Protobuf : la structure .proto définissant le message.
  • Pour JSON/XML : un exemple de message illustrant la structure des données.
• JSON Schema: Équivalent JSON standard du message, décrivant sa structure. Le schéma peut être généré automatiquement en cliquant sur le bouton « Générer à partir du message ».

Formats intégrés :

L'installation par défaut comprend plusieurs formats prédéfinis, tels que :
STD_J001, STD_J002, STD_JMS, STD_PR01 — qui servent de modèles prêts à l'emploi pour différents types d'échanges.

• Exemple: STD_J002 (Standard Json format 002)

  Il s'agit d'une charge utile standard de la plateforme, un message optimisé contenant un tableau d'attributs (ID et valeurs). Ce format est compatible avec la structure de charge utile de la plateforme. L'attribut ID correspond à l'identifiant d'une mesure, d'une configuration ou d'un événement.

{
  "deviceId": "d15922X",
  "timestamp": "2023-11-23T18:25:43.511Z",
  "temperature": 32.8,
  "humidity": 12.0,
  "batteryLevel": 90
}

• STD_JPMS (Standard Json PMS)

Structure de message de plateforme JSON standard (PMS) : ce format ne nécessite aucun processus de conversion de base car il est aligné sur la structure de message de la plateforme.

{
  "ResponseToMessageId": 0,
  "SentOn": "2025-05-04T14:31:39",
  "Payloads": [
    {
      "NodeId": "node001",
      "DateTime": "2025-05-04T12:31:39Z",
      "Attributes": [
        {
          "Id": 100,
          "Value": "41.5"
        },
        {
          "Id": 110,
          "Value": "20"
        }
      ]
    }
  ]
}

• Example STD_PR01 (Standard Proto format 01)

  Un message prototype de structure de plateforme (PMS)

Lors de la définition d'un format Protobuf, le système génère automatiquement un schéma JSON équivalent à partir de la structure .proto fournie. Le message binaire reçu est ensuite converti et désérialisé au format JSON pour une utilisation ultérieure.

Le nom du format de message doit correspondre au type Proto principal défini dans le schéma.

• Format  PMS 

Lorsque l'option PMS est activée, le message suit la norme de message de la plateforme (PMS) — la structure native utilisée en interne par IoTRoutes.
Les messages alignés sur le PMS ne nécessitent aucune conversion et sont acquis directement de manière optimisée.   Les messages PMS peuvent être de type JSON, XML ou Protobuf.

2- Cycle de vie des messages

Le cycle de vie des messages IoT définit la séquence des étapes que traverse un message IoTRoutes, de son émission ou création initiale à son traitement, transmission ou archivage final.

Ce cycle de vie fournit un modèle structuré de la manière dont la plateforme gère les messages entrants et sortants, garantissant la traçabilité, l'automatisation et la cohérence opérationnelle tout au long du pipeline de données.

En formalisant ces étapes, IoTRoutes permet:

• Suivi précis du parcours de chaque message.
• Traitement automatisé et prise de décision basé sur les flux de travail.
• Classification et gestion des erreurs pour les messages invalides.

Statuts prédéfinis

IoTRoutes intègre un ensemble de statuts de message prédéfinis qui représentent les états standard d'un message au cours de son cycle de vie.

Ces statuts système sont réservés au traitement interne, mais les administrateurs peuvent définir des statuts personnalisés supplémentaires pour s'adapter aux flux de travail métier ou aux besoins spécifiques du domaine. Les statuts sont automatiquement mis à jour par les actions du flux de travail à mesure que chaque message traverse son pipeline configuré.

Statuts personnalisés

Les administrateurs peuvent créer des statuts de message personnalisés afin d'étendre leur cycle de vie et de les adapter à des exigences opérationnelles ou analytiques spécifiques. Ces statuts personnalisés peuvent être associés à des règles de flux de travail pour automatiser les transitions en fonction du contenu, du type ou du résultat du traitement du message.

3- Interprètes de valeurs d'attributs

Les interpréteurs de valeurs d'attributs sont des processus permettant d'analyser ou de comparer les valeurs d'attributs envoyées 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çues par niveaux. Ceci permet aux flux système d'identifier immédiatement les messages urgents ou ceux contenant des valeurs critiques et de fournir une notification rapide ou d'exécuter un processus défini.

Les niveaux sont configurés dans l'application comme illustré dans la capture d'écran ci-dessous. Un niveau de valeur est défini par son numéro, son nom, sa description et une couleur qui sera affichée dans les indicateurs clés de performance (KPI) ou les tableaux d'analyse.

L'exemple ci-dessous montre un niveau « 5 » nommé « Critique » (en rouge) pour une valeur qui dépasse significativement la valeur standard.

L'application propose deux modes d'interprétation des valeurs reçues des objets connectés :

Le mode simple compare automatiquement chaque valeur à des seuils prédéfinis afin de déterminer si elle est normale, élevée ou critique. Ce mode est facile à utiliser et convient aux données classiques telles que la température ou la pression..

Mode avancé, En revanche, il est destiné aux administrateurs et aux développeurs. Il offre la possibilité de créer des fonctions personnalisées à l'aide d'un langage de développement intégré. Ceci permet une analyse plus poussée, notamment pour le traitement de données complexes telles que des images, des fichiers audio ou d'autres types de médias.

Exemple de script avancé par défaut :

 /****** IoTRoutes script  sample v0.1 : change code above to write your custom interpreter ****/
    
    var result = new AttributeInterpretResult(); //required. Result to return, contains the assigned Level and the comment and, if eligible, the sub-attributes
   //dynamic apiResponse= Fct.ApiCall(apinName,"/{{Variables.Id}}","",3); // You can call a web api to deep analysing and return result. See 'ApiCall' method schema.
   
   if ( Context.Value >100)  //value already casted based on attribute type definition
    {
        result.ValueLevel = Levels.Faulty;
        result.ValueLevelComment ="Value can't exceed 100";
    }
    else if ( Context.Value >  10 &&  Context.Value<45)
    {
        result.ValueLevel = Levels.Good;
        result.ValueLevelComment ="Good value measured";
    }
    else
    {
        result.ValueLevel =  Levels.Normal;    
        //set sub-attributes extracted from main value. Example media value to metadas like extracting Registration Number and color from car picture. 
        //result.AddSubResult([subAttributeId],apiResponse.myValue ,1,"comment as string"); 
    }
    return result;

4- Entités

Dans IoTRoutes, les entités sont structurées de manière hiérarchique et représentent des groupes, des divisions ou des individus. Elles se répartissent en deux catégories : internes (filiales, départements, services, etc.) et externes (clients, par exemple).

Leur rôle principal est d'associer les objets connectés à un groupe spécifique, afin de limiter l'accès des utilisateurs aux seules données qui leur sont attribuées. Dans un environnement partagé, par exemple, un client peut accéder uniquement à ses propres objets et un utilisateur d'un département uniquement aux données de son département.

Accessible à partir de Application Settings >> Entities, L'écran ci-dessous vous permet de visualiser et de gérer la liste des entités.

L'écran de détail affiché dans la capture d'écran ci-dessous permet la création et la modification d'entités, ainsi que l'association d'appareils, l'attribution d'utilisateurs et la liaison de sous-entités. Un utilisateur affecté à une entité dans la hiérarchie aura accès à cette entité et à toutes ses entités enfants.

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 et des processus qui y sont exécutés. Cette section constitue un point de configuration central pour adapter l'application à différents environnements ou contextes d'utilisation.

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

Une configuration pour l'environnement de production, une autre pour les tests, une troisième pour la formation ou les démonstrations, etc.

Cependant, une seule configuration peut être active à la fois, garantissant ainsi un fonctionnement cohérent et maîtrisé de l'application selon des paramètres précis. Cette flexibilité permet d'adapter rapidement le comportement de l'application en fonction des besoins, sans avoir à modifier manuellement les paramètres à chaque changement de contexte.

Comme le montre la capture d'écran, il existe deux groupes de paramètres : les paramètres de l'application et les paramètres du processus en cours d'exécution.

• Intra-server event topic: Le Topic utilisé pour les événements communiqués entre serveurs ou services internes.
• Maximum allowed payload: Taille maximale autorisée des messages envoyés par les appareils connectés.
• Save payload as blob from: Limite de taille, au-delà de laquelle les attributs seront enregistrés sous forme de blob (base de données multimédia) géré par le gestionnaire de stockage de fichiers.
• Timestamp calculation: La méthode de calcul d'horodatage spécifique convertit une date en un petit entier utilisé pour optimiser la communication entre la plateforme et les appareils. Par exemple, la date sera représentée par le nombre de millisecondes, de secondes ou de minutes écoulées depuis le 1er janvier 2020.

• Parameter Refresh Interval: Les services fonctionnant en continu chargent leur configuration au démarrage de la plateforme ; toute modification de configuration est automatiquement prise en compte à un intervalle spécifié en minutes.

Suivant:  Workflows