Couche de collecte des données

Structure et composition de la couche de collecte des données

La couche de collecte des données est un composant clé de la Plateforme IIoT qui assure l’intégration avec les appareils. Elle regroupe un ensemble d’applications spécialisées, chacune conçue pour interagir avec un type particulier d’appareil IoT (compteurs, capteurs, etc.). Ces applications fonctionnent comme des services réseau : elles traitent les connexions entrantes via des ports dédiés et gèrent le transfert de données entre les appareils et la plateforme. Cette architecture garantit l’évolutivité et la souplesse nécessaires pour travailler avec des équipements hétérogènes.

La structure et la composition des applications de la couche de collecte des données sont résumées ci-dessous :

flowchart TD
    A(Household energy meters) <-->|Data transfer| B("Data collection daemon (Type-J)")
    C(Industrial energy meters) <-->|Data transfer| D("Data collection daemon (Type-T)")
    E(Smart sensors) <-->|Data transfer| F("Data collection daemon (DDT)")
    subgraph " "
    B("Data collection daemon (Type-J)") <--> I{"Balancer (Pgbouncer)"}
    D("Data collection daemon (Type-T)") <--> I{"Balancer (Pgbouncer)"}
    F("Data collection daemon (DDT)") <--> I{"Balancer (Pgbouncer)"}
    X@{ shape: braces, label: "Data Polling Subsystem" }
    end
    I{"Balancer (Pgbouncer)"} <--> J[(DBMS PostgreSQL)]

Les échanges avec les appareils terminaux s’effectuent via une connexion TCP, chaque démon de collecte mettant en œuvre son propre protocole d’échange applicatif pour desservir un type particulier d’appareil IoT.

Ces démons partagent plusieurs caractéristiques architecturales communes, décrites ci-dessous.

Caractéristiques de l’architecture

• Chaque conteneur intègre une application spécialisée dans un protocole particulier.
• Des images de base légères sont utilisées (alpine dans la configuration de base) afin de réduire au minimum la surcharge. Il est toutefois possible de construire des images adaptées au système d’exploitation du client.
• Pour gérer les dépendances entre les services (comme l’accès à la base de données), les sections depends_on et health-check sont renseignées dans Docker Compose.
• Les démons Compose s’exécutent en plusieurs instances (réplicas) afin de répartir la charge. Dans ce cas, chaque démon de collecte peut desservir simultanément des dizaines de milliers de connexions.
• Un répartiteur de charge (HAProxy, Nginx Stream) dirige le trafic vers les démons disponibles à l’aide des algorithmes Round Robin ou Least Connections.
• Dans les environnements cloud, vous pouvez ajouter une mise à l’échelle automatique fondée sur des métriques (CPU, nombre de connexions).
• Toutes les communications avec les appareils sont consignées en détail dans des fichiers, afin de pouvoir être analysées en cas de détection de problèmes et de défaillances.

Principes d’échange de données

Voici un diagramme d’une session de communication entre un appareil IoT et le démon de collecte :

sequenceDiagram
    autonumber
    participant D as IoT device
    participant I as Data collection <br/>daemon
    Note over I,D: Stages of interaction
    D->>I: Session start, authentication
    I-->>D: Sending request parameters
    D->>I: Data acquisition
    I-->>D: Sending the next session time

Principes d’organisation de l’échange de données :

• Initiation d’une session de communication.
  Une session de communication est toujours initiée par l’appareil IoT. Après avoir établi une connexion avec le démon de collecte des données, l’appareil transmet un paquet d’identification.

• Procédure d’authentification
  Le démon de collecte des données authentifie l’appareil. Si l’authentification réussit, il effectue :

  • La récupération de la configuration enregistrée de l’appareil depuis la base de données.
  • L’envoi des paramètres d’interface actuels à l’appareil.

• Transfert de données
  En fonction de la requête reçue, l’appareil transmet au serveur de collecte :

  • Les relevés actuels de l’appareil.
  • Les enregistrements archivés (le cas échéant).

• Planification de la session suivante
  Une fois la réception des données terminée, le démon de collecte :

  • Génère l’horodatage de la session suivante.
  • Transmet l’horodatage de la session suivante à l’appareil.
  • Lance la fermeture de la connexion.

• Traitement et stockage des données
  Les informations reçues sont :

  • Agrégées dans des objets JSON structurés.
  • Stockées dans une base de données PostgreSQL intermédiaire.
  • Mises en forme conformément à la spécification du protocole d’un démon particulier.

• Intégration avec le système de gestion
  Les données deviennent disponibles pour le niveau supérieur du système (sous-système de gestion) en vue de :

  • Leur traitement analytique ultérieur.
  • Leur visualisation dans les interfaces de gestion.
  • La génération de rapports automatisés.

Interaction avec la couche de gestion de la plateforme

Architecture d’interconnexion des sous-systèmes

Les démons de collecte des données s’intègrent au système de niveau supérieur (couche de gestion) par l’intermédiaire d’une base de données intermédiaire. Pour permettre cette interaction, on utilise un conteneur Docker hébergeant un SGBD PostgreSQL déployé.

Les résultats des interactions réussies avec les appareils sont automatiquement enregistrés par les démons dans une table spécialisée de cette même base de données, garantissant la transparence du transfert de données entre le niveau de gestion et les appareils.

Le schéma d’interaction des sous-systèmes est présenté ci-dessous :

flowchart LR
A@{ shape: procs, label: "Data Polling Subsystem"} -->|Readings data| B[(DBMS PostgreSQL)]
B[(DBMS PostgreSQL)] -->|Configuration| A@{ shape: procs, label: "Data Polling Subsystem"}
B[(DBMS PostgreSQL)] -->|Readings data| C@{ shape: procs, label: "Control Subsystem"}
C@{ shape: procs, label: "Control Subsystem"} -->|Configuration| B[(DBMS PostgreSQL)]

Configuration des appareils

La configuration d’un appareil comprend les informations suivantes :

• Dates des derniers relevés par archive : horaire, journalière, mensuelle. Ces paramètres indiquent la date à partir de laquelle les données de l’archive correspondante doivent être lues.
• Code de l’appareil de mesure (pour les appareils IoT utilisant le protocole Type-T). Ce paramètre n’est requis que pour les démons de collecte desservant le protocole Type-T ; il indique au serveur de collecte quel algorithme employer pour communiquer avec l’appareil.
• Vitesse du port série (pour les appareils IoT fonctionnant sous le protocole Type-T). Ce paramètre indique à l’appareil IoT à quelle vitesse il doit communiquer avec le compteur. Le démon de collecte l’envoie au début d’une session d’échange.
• Planning de communication. Le sous-système de gestion enregistre tous les plannings dans une base de données intermédiaire, et le démon de collecte calcule la date la plus proche à partir des plannings reçus, puis l’envoie à l’appareil.
• Commandes de contrôle de l’appareil. Selon le type d’appareil IoT et ses capacités, les commandes de gestion comprennent :
  • Une commande de mise à jour du logiciel de la partie télémétrie de l’appareil IoT. À la réception de cette commande, l’appareil télécharge le nouveau micrologiciel depuis le serveur et effectue la mise à jour.
  • Une commande de relecture de la configuration de l’appareil de mesure.
  • Une commande de fermeture ou d’ouverture de la vanne (si une vanne est présente et prise en charge par le logiciel de l’appareil IoT).
  • Une commande de définition des paramètres de fonctionnement de l’appareil de mesure (selon le modèle).
  • Une commande de redémarrage de l’appareil IoT.

L’essentiel de la configuration de l’appareil est stocké dans une base de données intermédiaire au format JSON.

Un exemple de configuration est présenté ci-dessous :

{
  "settings": "1",
  "day_event": 1706140800,
  "hour_event": 1706140800,
  "month_event": 1673857740,
  "net_address": 58
}

Ici, day_event, hour_event et month_event sont des horodatages au format unixtime des enregistrements les plus récemment sauvegardés des archives journalière, horaire et mensuelle, respectivement.

Les plannings sont stockés séparément, également au format JSON. La chaîne de planning elle-même est formée et traitée au format CRON. Cette approche offre une grande souplesse pour la configuration et le traitement de n’importe quel planning.

Voici un exemple de stockage de plusieurs plannings pour un appareil :

[
  { "crontab": "10 * * * *", "schedule_id": 6 },
  { "crontab": "40 * * * *", "schedule_id": 7 }
]

Selon ces plannings, l’appareil doit se connecter à 10 et 40 minutes après chaque heure. Le démon détermine lui-même le planning le plus approprié au moment de la communication avec l’appareil et transmet le plus proche.