Diagramme d'architecture IoT : appareils, MQTT, traitement de flux et stockage

La plupart des diagrammes IoT comportent trois boîtes : des appareils, une icône de cloud et un tableau de bord. Les questions importantes se trouvent entre les deux. Comment le broker sait-il quel appareil parle ? Que se passe-t-il quand un site perd sa connexion pendant une heure ? Quels messages peuvent être perdus ou livrés deux fois ? Comment une commande atteint-elle un capteur parmi des milliers ?

Un diagramme d'architecture IoT devrait répondre à ces questions sur la page. Cet article en construit un pour un cas concret, la surveillance de la température dans des entrepôts frigorifiques, et passe en revue les décisions derrière chaque étape : MQTT et ses niveaux de qualité de service, la conception des topics, l'identité des appareils, les sites hors ligne et le temps d'événement, et l'endroit où les données aboutissent.

Les couches d'un système IoT

Tous les systèmes n'ont pas besoin de toutes les couches. Les appareils dotés d'un module cellulaire ou Wi-Fi publient souvent directement vers le broker, sans passerelle. Dessinez les couches que vous exploitez réellement.

Pourquoi MQTT

MQTT est un protocole de publication/abonnement dans lequel les clients se connectent à un broker et échangent des messages par topic. La spécification MQTT 5.0, standard OASIS depuis mars 2019, le décrit comme léger, ouvert et simple à implémenter. Le port 1883 est enregistré auprès de l'IANA pour MQTT sans TLS et le port 8883 pour MQTT sur TLS. Tout ce qui quitte le site devrait utiliser 8883.

Chaque message est publié avec un niveau de qualité de service (QoS) :

La QoS s'applique à chaque saut, pas de bout en bout : un abonné reçoit un message avec la plus basse des deux QoS, celle de la publication et celle accordée à son abonnement. Avec la QoS 1, le broker peut livrer des doublons ; chaque consommateur doit donc supporter de recevoir deux fois la même mesure. Un identifiant de message généré par l'appareil ou un horodatage par capteur facilite cela.

MQTT 5 ajoute quelques fonctionnalités qui méritent leur place sur le diagramme :

• Messages retenus (retained). Le broker conserve le dernier message d'un topic et l'envoie aux nouveaux abonnés, ce qui convient à l'état courant d'un appareil.
• Messages de testament (will). Le broker publie le message de testament d'un client quand sa connexion tombe sans déconnexion propre ; une passerelle peut ainsi annoncer qu'elle est hors ligne.
• Expiration des messages. Si un message expire avant le début de la livraison, le broker le supprime. Utilisez-la pour les commandes qui ne sont valables qu'un temps.
• Abonnements partagés. Plusieurs consommateurs partagent un abonnement et chaque message ne va qu'à l'un d'eux ; le pont vers la plateforme de streaming peut ainsi monter en charge.

La conception des topics

Les topics sont hiérarchiques, et les abonnés utilisent + pour un niveau et # pour le reste. Une structure comme site/{site}/device/{id}/telemetry permet de s'abonner à un site, à un appareil ou à tout, et permet au broker de limiter chaque appareil à ses propres topics. Les topics qui commencent par $ sont réservés au broker, et les filtres qui commencent par un joker ne les reconnaissent pas.

Réservez les topics au routage et aux permissions. Mettez la version du schéma et l'heure de mesure dans la charge utile, où elles peuvent changer sans casser chaque abonnement.

L'identité des appareils

Donnez à chaque appareil ou passerelle son propre certificat X.509 signé par votre CA d'appareils, et faites exiger les certificats clients par le broker. Le sujet du certificat devient l'identifiant du client, et le broker accorde les topics sur cette base. Un appareil volé peut alors être révoqué individuellement, et aucun mot de passe partagé ne dort dans le firmware de milliers d'unités. Décidez comment les certificats sont émis, en fabrication ou au premier démarrage, et comment ils sont renouvelés avant leur expiration, et dessinez la CA sur le diagramme.

Les sites hors ligne et le temps d'événement

Les sites perdent leur connexion. Une passerelle qui met les mesures en tampon localement envoie une heure de données d'un coup quand le lien revient : les données arrivent en retard et dans le désordre. Horodatez chaque mesure à l'instant où elle a été prise, gardez les horloges des passerelles synchronisées et traitez en temps d'événement avec une marge pour les retards. Une alerte comme « congélateur au-dessus de -18 °C pendant dix minutes » doit être calculée selon le moment où les mesures ont été prises, pas celui où elles sont arrivées. Le même raisonnement vaut pour toute architecture orientée événements.

L'exemple : la surveillance d'entrepôts frigorifiques

Chaque entrepôt compte une quarantaine de capteurs de congélateurs qui envoient une mesure toutes les 30 secondes et une douzaine de capteurs de portes qui signalent chaque changement. Une passerelle de site collecte leurs mesures par radio locale, les met en tampon hors ligne et les publie vers le broker MQTT en QoS 1 sur TLS mutuel. Le broker vérifie chaque certificat client auprès de la CA d'appareils. Un pont avec un abonnement partagé copie la télémétrie dans Kafka. Un consommateur archive les messages bruts dans un stockage objet ; un processeur de flux calcule des agrégats d'une minute en temps d'événement, les écrit dans une base de séries temporelles pour les tableaux de bord et déclenche les alertes de température. La gestion des appareils renvoie commandes et configuration par le broker.

Comment le lire :

• À gauche, le site. Les capteurs ne parlent qu'à la passerelle de site ; la passerelle est le seul client que le broker voit de ce site.
• Au milieu, le broker. La télémétrie monte en QoS 1. Les liens en pointillé sont les commandes qui descendent vers le site et la vérification des certificats auprès de la CA d'appareils.
• À droite, le chemin des données. Kafka alimente l'archive brute et le processeur de flux, qui écrit les agrégats dans la base de séries temporelles et déclenche les alertes.
• Le bloc Markdown contient la structure des topics, la QoS par topic et la règle d'identité.

Ce qu'il faut étiqueter

• Le protocole, le port et la QoS sur le lien entre le site et le broker.
• Les débits de messages par classe d'appareils. Quarante capteurs toutes les 30 secondes, cela fait 80 messages par minute et par site ; multipliez par le nombre de sites avant de dimensionner le broker.
• L'identité : quel certificat, quelle CA, et comment les certificats sont renouvelés et révoqués.
• La mise en tampon : combien de temps la passerelle peut conserver les données hors ligne.
• La rétention de chaque stockage, de quelques heures dans le flux à des années dans l'archive.
• Le chemin des commandes, y compris l'expiration des messages et ce que fait un appareil d'une commande inconnue.

Erreurs courantes

• Des identifiants partagés entre appareils. Un seul mot de passe divulgué ouvre alors tous les appareils. Utilisez un certificat par appareil.
• Le port 1883 sur Internet. Sans TLS, mesures et identifiants circulent en clair.
• Supposer une livraison exactement une fois. La QoS 1 peut livrer des doublons ; rendez les consommateurs idempotents au lieu d'utiliser la QoS 2 partout.
• Traiter selon l'heure d'arrivée. Les données mises en tampon déclenchent alors de fausses alertes, ou en masquent de vraies.
• Des appareils qui écrivent directement dans la base de données. Vous perdez l'authentification, la mise en tampon et la diffusion du broker.
• Aucun chemin de mise à jour. Les mises à jour de firmware et les changements de configuration font partie de l'architecture ; dessinez-les.
• Des permissions avec jokers pour les appareils. Un appareil autorisé à s'abonner à # peut lire les données de tous les autres appareils.

Le diagramme de topologie réseau couvre le réseau propre au site, qu'un diagramme IoT laisse généralement de côté.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez un Cadre du pack Base pour le site. À l'intérieur, depuis le pack Réseau, ajoutez un Appareil pour chaque groupe de capteurs avec le type IoT / maison connectée, et un autre Appareil de type Modem / passerelle pour la passerelle de site.
3. Depuis le pack Modèle C4, ajoutez des nœuds Conteneur pour le broker MQTT, la gestion des appareils et le processeur de flux, et une Base de données pour la base de séries temporelles.
4. Depuis le pack Sécurité, ajoutez un Certificat pour la CA d'appareils.
5. Depuis le pack Données, ajoutez Kafka et un Magasin d'objets pour l'archive brute. Depuis le pack DevOps, ajoutez Métriques pour les tableaux de bord et un nœud Alerte.
6. Reliez-les de gauche à droite, étiquetez la liaison montante avec sa QoS, dessinez en pointillé les commandes et la vérification des certificats, et ajoutez un bloc Markdown du pack Base avec la conception des topics.

L'exemple utilise 14 nœuds de diagramme et reste dans les limites de l'offre Free. La page diagramme réseau présente le reste du pack Réseau.

FAQ

Les appareils IoT doivent-ils utiliser MQTT ou HTTP ? MQTT garde une connexion ouverte, ce qui permet au cloud de pousser des commandes, et son surcoût par message est faible. HTTP est plus simple pour les appareils qui remontent rarement des données et ne reçoivent jamais de commandes.

Quel niveau de QoS utiliser ? La QoS 1 pour la plupart de la télémétrie et des commandes, avec des consommateurs qui tolèrent les doublons. La QoS 0 pour les mesures à haute fréquence que vous pouvez vous permettre de perdre. La QoS 2 seulement là où les doublons ne peuvent pas être gérés en aval.

Ai-je besoin de Kafka si j'ai déjà un broker MQTT ? Pas toujours. Le broker route les messages vers les abonnés connectés ; ce n'est pas un journal à long terme que l'on peut rejouer. Ajoutez une plateforme de streaming quand plusieurs consommateurs ont besoin des mêmes données, ou quand vous devez retraiter l'historique.

Comment les appareils obtiennent-ils leurs certificats ? En fabrication ou au premier démarrage, via un service de provisionnement, chacun avec sa propre paire de clés. Conservez la clé privée dans un matériel sécurisé lorsque l'appareil en dispose.

Les règles doivent-elles s'exécuter en périphérie ou dans le cloud ? Les règles qui doivent fonctionner pendant une panne, comme une alarme locale pour une porte restée ouverte, s'exécutent sur la passerelle. Les règles qui ont besoin des données de nombreux sites s'exécutent dans le cloud.

Commencez gratuitement — un siège, sans carte bancaire.