Routage de messages d'IoT Hub contre Event Grid — Pourquoi la télémétrie et les événements ne posent pas le même problème

Une lecture de température, un échantillon de vibration, un cycle machine et une déconnexion d'appareil peuvent tous être décrits comme des événements, mais ils ne représentent pas le même problème d'architecture. Dans les environnements IoT industriels et de fabrication, confondre la télémétrie continue avec des événements discrets peut créer des flux de travail bruyants, des historiques de production incomplets, des traitements inutiles et des systèmes qui réagissent sans suffisamment de contexte.

Dans cet épisode, nous décomposons la différence architecturale entre le routage de messages d'Azure IoT Hub et Azure Event Grid à travers un scénario de fabrication réaliste. Une ligne de presse envoie en continu des informations de température, de vibration, de compteur de cycles, de consommation d'énergie et d'état de la machine via une passerelle industrielle. Ces mesures constituent un historique opérationnel que les ingénieurs, les équipes de données, les équipes de maintenance et les systèmes de production peuvent avoir besoin d'analyser ultérieurement. Une déconnexion d'appareil est différente, car elle représente un changement qui peut nécessiter une réaction d'un autre système ou d'une personne.

LA TÉLÉMÉTRIE EST UN ENREGISTREMENT, PAS UNE ALERTE
La télémétrie représente des mesures répétées dans le temps. Une valeur de température ou une mesure de vibration seule vous apprend généralement très peu de choses. L'information réelle réside dans la séquence : à quelle vitesse les valeurs ont changé, ce que faisait la machine à ce moment-là, ce qui s'est passé avant un arrêt, si des mesures ont disparu pendant une interruption réseau, et si le même comportement est apparu lors de cycles de production antérieurs.


La télémétrie industrielle typique comprend :
• La température, la vibration, la pression, la consommation d'énergie et le courant absorbé
• Les états de la machine, tels que en marche, au ralenti, arrêtée ou en défaut
• Les compteurs de cycles, les compteurs de production et les mesures de processus
• Les horodatages source, les identifiants d'appareil, les numéros de séquence et les informations de corrélation

Ces enregistrements peuvent ensuite servir à la surveillance de l'état, aux investigations qualité, à l'analyse énergétique, aux calculs de TRS (OEE), à l'analytique Microsoft Fabric, aux rapports Power BI et à l'optimisation de la production. C'est pourquoi la télémétrie nécessite une conservation, une relecture, une gestion des doublons, des consommateurs indépendants et un moyen fiable de reconstruire la chronologie de production.

LE ROUTAGE DE MESSAGES IOT HUB COMME PLAN DE DONNÉES DE TÉLÉMÉTRIE
Azure IoT Hub fournit la frontière contrôlée entre les appareils et le cloud. Les appareils et les passerelles s'authentifient avec leurs propres identités, envoient des messages de l'appareil vers le cloud, maintiennent l'état de gestion des appareils et peuvent participer à une communication contrôlée du cloud vers l'appareil.

Une fois qu'un message de télémétrie atteint IoT Hub, le routage de messages détermine où ces données doivent aller. Le routage peut inspecter les propriétés des messages, les propriétés système, certaines parties du corps du message et les informations du device twin. Cela permet de séparer les données de télémétrie de production, les mesures énergétiques, les diagnostics ou d'autres classes de messages avant qu'ils n'atteignent les consommateurs en aval.
Une architecture courante pourrait ressembler à ceci : Passerelle industrielle → Azure IoT Hub → Routage de messages → Event Hubs ou Storage → Traitement → Microsoft Fabric.

Un consommateur peut effectuer une analyse quasi temps réel tandis qu'un autre conserve une archive brute. Un troisième consommateur peut préparer des données opérationnelles organisées pour Microsoft Fabric. Chaque consommateur peut fonctionner indépendamment sans transformer chaque lecture de télémétrie en invocation de flux de travail.

POURQUOI L'ORDRE EST IMPORTANT
La télémétrie industrielle est particulièrement sensible à la séquence. Imaginez une machine signalant qu'elle est passée en état de marche, transmettant ensuite plusieurs compteurs de cycles, suivis d'un écart de processus et enfin d'un état arrêté. Si ces enregistrements sont reconstruits de manière incorrecte, un système en aval pourrait conclure que la machine a produit des pièces alors qu'elle était arrêtée, ou qu'un écart de processus s'est produit après la fin de la production.

Le même problème affecte les calculs de temps d'arrêt, le TRS, les comptages de production et la surveillance de l'état. Vous devez donc distinguer le moment où la source a observé quelque chose, le moment où IoT Hub a reçu le message et le moment où un système en aval l'a traité.

Une architecture de télémétrie robuste doit donc prendre en compte :
• Les horodatages source et les horodatages de réception dans le cloud
• Un partitionnement stable adapté à l'actif ou à la charge de travail
• Des identifiants de message ou des numéros de séquence pour la détection des doublons
• Des consommateurs idempotents capables de gérer une livraison au moins une fois

Les interruptions réseau rendent ce point particulièrement important. Une passerelle peut mettre la télémétrie en mémoire tampon et l'envoyer lorsque la connectivité revient, ce qui signifie que l'heure d'arrivée dans Azure peut être bien postérieure à l'horodatage réel de la machine.

EVENT GRID RÉSOUT UN AUTRE PROBLÈME
Azure Event Grid est conçu autour de notifications de type publication-abonnement. Au lieu de reconstruire en continu l'état d'une machine à partir de milliers de relevés, Event Grid indique aux systèmes intéressés qu'un changement s'est produit et donne aux abonnés la possibilité de réagir.
Les exemples dans un environnement IoT incluent la création ou la suppression d'un appareil, la connexion, la déconnexion, ou certaines conditions soigneusement sélectionnées dérivées de la télémétrie. Un événement de création d'appareil peut déclencher un processus d'intégration d'actif. Un événement de déconnexion d'appareil peut lancer une investigation technique. Une condition d'ingénierie détectée peut déclencher un flux de travail de maintenance.

Les abonnés typiques comprennent :
• Azure Functions
• Logic Apps
• Webhooks
• Flux de travail de sécurité
• Systèmes de gestion d'actifs
• Applications opérationnelles

La différence architecturale fondamentale est simple : la télémétrie demande ce qu'un actif a fait, tandis qu'un événement demande ce qui a changé et si quelque chose doit réagir.

LES ÉVÉNEMENTS DOIVENT DÉCLENCHER DES INVESTIGATIONS, PAS DÉFINIR LA RÉALITÉ
Event Grid doit généralement être considéré comme un mécanisme de notification, et non comme l'état final et faisant autorité du monde physique. La livraison d'événements peut être répétée, et un abonné ne doit pas interpréter aveuglément un événement comme l'état actuel final sans vérification.
Un événement de déconnexion d'appareil doit donc généralement déclencher une vérification d'état. Une Azure Function peut vérifier l'état actuel de l'appareil, inspecter la télémétrie récente, consulter les informations de registre pertinentes, puis décider si l'investigation doit rester ouverte.

Les gestionnaires doivent être conçus autour de :
• Un traitement idempotent
• La vérification de l'état actuel
• L'identité et les horodatages des événements
• Une propriété clairement définie de l'action qui en résulte

C'est important, car les événements en double ne doivent pas créer de tickets, d'alertes ou d'enregistrements opérationnels en double ou contradictoires.

UNE DÉCONNEXION D'APPAREIL NE SIGNIFIE PAS QUE LA MACHINE S'EST ARRÊTÉE
L'une des distinctions les plus importantes en IoT industriel est la différence entre la connectivité cloud, l'état de la collecte de données et l'état de production. Si une passerelle industrielle se déconnecte d'IoT Hub, le cloud a perdu la visibilité sur cette passerelle. Cela ne signifie pas automatiquement que la machine physique s'est arrêtée.

L'automate peut continuer à contrôler l'équipement localement pendant que la passerelle perd temporairement sa connectivité. La production peut se poursuivre normalement, et la passerelle peut même mettre les données en mémoire tampon pour les téléverser plus tard. Le contraire peut aussi se produire : une passerelle peut rester connectée à Azure alors que sa connexion à l'automate ou à l'équipement local a échoué.

Une architecture utile sépare donc l'état de connexion cloud, la santé de la passerelle, l'état de production de la machine et l'état de l'ordre de travail MES. Ce n'est qu'en combinant ces sources que l'entreprise peut déterminer si un problème technique de connectivité a réellement affecté la production.

FILTRAGE DANS IOT HUB VS FILTRAGE DANS EVENT GRID
Les deux technologies prennent en charge le filtrage, mais leur finalité diffère. Le filtrage du routage de messages IoT Hub répond à la question de savoir quels messages opérationnels doivent entrer dans un chemin de données spécifique. Le filtrage d'abonnement Event Grid répond à la question de savoir quelles notifications un abonné particulier doit recevoir.

Par exemple, la télémétrie de production peut aller vers un flux Event Hubs, tandis que les données énergétiques vont vers une autre destination. Dans le même temps, un flux de travail de support peut s'abonner uniquement aux événements de déconnexion provenant d'un