Routage de messages IoT Hub vs Event Grid — pourquoi la télémétrie et les événements ne sont pas le même problème

Une machine envoie des relevés de température, des données de vibration, des compteurs de cycles, la consommation électrique et les états de fonctionnement toutes les quelques secondes. Puis la passerelle se déconnecte soudainement. Tous ces messages ne sont-ils que des « événements » ? Techniquement, on peut les décrire ainsi. Sur le plan architectural, cela peut créer de sérieux problèmes. Azure IoT Hub Message Routing et Azure Event Grid résolvent des problèmes différents. Un chemin est conçu pour préserver et distribuer les données opérationnelles. L'autre est conçu pour notifier les systèmes qu'un changement a eu lieu et qu'une réponse peut être nécessaire. Les traiter comme interchangeables peut conduire à des workflows coûteux qui traitent des données de capteurs de routine, ou à des signaux importants enfouis dans un pipeline de télémétrie que personne ne surveille activement. Dans cet épisode de M365 FM, nous suivons une machine de production à travers une architecture IoT Azure réelle et expliquons où IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions et Logic Apps trouvent réellement leur place.

CE QUE VOUS APPRENDREZ
Dans cet épisode, nous explorons :

• Pourquoi la télémétrie des machines et les événements métier ou de cycle de vie discrets nécessitent des modèles d'architecture différents
• Comment fonctionne Azure IoT Hub Message Routing dans le cadre d'un plan de données de télémétrie
• Où Azure Event Grid s'intègre dans les architectures événementielles et réactives
• Pourquoi l'ordre des messages compte pour la télémétrie industrielle
• Pourquoi Event Grid ne doit pas devenir votre bus de télémétrie principal à fort volume
• Pourquoi le routage IoT Hub ne doit pas être imposé à chaque workflow de notification
• Comment IoT Hub et Event Grid peuvent fonctionner ensemble dans la même architecture
• Comment Event Hubs peut prendre en charge des consommateurs indépendants de traitement de flux
• Pourquoi les données brutes de télémétrie doivent souvent être conservées pour la traçabilité et les investigations ultérieures
• Comment Microsoft Fabric et Power BI peuvent consommer des données opérationnelles préparées
• Pourquoi MES, ERP et les modèles d'actifs fournissent un contexte que les seules données des appareils ne peuvent pas fournir
• Comment interpréter les événements de déconnexion d'un appareil sans supposer automatiquement que la production s'est arrêtée
• Comment les livraisons en double, les nouvelles tentatives, les horodatages et l'idempotence affectent la fiabilité des architectures industrielles
• Comment concevoir la surveillance de l'état, la maintenance prédictive, la traçabilité qualité et les workflows de perturbation de production
• Comment décider si un message appartient au plan de données, au chemin de réponse, ou aux deux

LA TÉLÉMÉTRIE EST UN ENREGISTREMENT DANS LE TEMPS
La télémétrie n'a pas de valeur parce qu'un relevé de température est arrivé. Elle devient précieuse parce que des milliers de relevés ensemble décrivent ce qui s'est passé. Une machine de production peut signaler en continu :

• Des mesures de température et de vibration
• Le courant moteur et la consommation d'énergie
• Les compteurs de cycles et de production
• Les états en marche, au ralenti, arrêtée ou en défaut
• Les horodatages source et les informations de séquence
• Les informations de diagnostic et de santé des équipements

Une seule valeur de température peut signifier très peu de chose. La séquence autour de ce relevé raconte l'histoire. La machine se réchauffait-elle ? Produisait-elle déjà ? La vibration augmentait-elle en même temps ? Le temps de cycle a-t-il commencé à s'allonger ? La machine s'est-elle arrêtée peu après ? La télémétrie nécessite donc un chemin conçu autour de la séquence, de la rétention, du rejeu, des consommateurs indépendants et de la traçabilité.

LES ÉVÉNEMENTS EXISTENT POUR DÉCLENCHER UNE RÉPONSE
Un événement remplit un autre rôle. Un événement signifie : quelque chose a changé. Un système ou une personne peut devoir réagir. Par exemple :

• Un nouvel appareil a été enregistré
• Une passerelle s'est déconnectée d'IoT Hub
• Un appareil s'est reconnecté
• Un appareil a été supprimé
• Un processus de surveillance a détecté une condition nécessitant une investigation
• Une inspection est terminée et un autre workflow peut commencer

Le destinataire n'a généralement pas besoin de plusieurs heures de télémétrie avant de lancer la première étape. Il a besoin de suffisamment d'informations pour identifier ce qui s'est passé et déterminer la réponse appropriée. Cette réponse peut impliquer :

• Le démarrage d'une Azure Function
• Le déclenchement d'une Logic App
• L'ouverture d'une investigation de support
• La mise à jour d'un enregistrement d'actif
• La vérification de l'état actuel de l'appareil
• L'appel d'une application externe via un webhook
• La notification de l'équipe responsable du système affecté

L'événement déclenche l'investigation. Il ne contient pas nécessairement tous les faits nécessaires à la décision opérationnelle finale.

POURQUOI « TOUT EST UN ÉVÉNEMENT » ÉCHOUE
Envoyer chaque mesure de capteur vers des workflows déclenchés par événements peut sembler attrayant lors d'une preuve de concept. Puis vient la mise à l'échelle en production. Chaque relevé déclenche une autre Function. Une autre Logic App évalue quelque chose. Une autre intégration reçoit un autre message. La maintenance crée son propre abonnement. La qualité en crée un autre. La gestion de l'énergie en crée un autre. Bientôt, chaque équipe dispose d'un filtrage, d'une gestion d'état, d'une gestion des nouvelles tentatives et d'une logique de stockage légèrement différents. Une mesure de température n'est pas automatiquement un incident. Elle peut contribuer à un incident plus tard, mais les mesures continues doivent rester disponibles comme preuves. Lorsque la télémétrie de routine génère des notifications constantes, les utilisateurs peuvent aussi commencer à ignorer les alertes, car le système les a habitués au bruit plutôt qu'à des informations exploitables.

CE QUE FAIT RÉELLEMENT AZURE IOT HUB
Azure IoT Hub fournit la frontière cloud orientée appareils. Il prend en charge des domaines tels que :

• Les identités sécurisées des appareils
• La messagerie appareil vers cloud
• La communication cloud vers appareil
• La gestion des appareils
• Les jumeaux d'appareils (device twins)
• Un accès contrôlé entre les équipements connectés et les services Azure

IoT Hub sait qu'un appareil authentifié a envoyé un message. Il ne comprend pas automatiquement ce que ce message signifie pour la production. Une passerelle pourrait signaler : state = running Mais « running » pourrait signifier :

• Produire des pièces approuvées
• Un cycle à vide
• Un réglage en cours
• Un retravail
• Un mouvement sans matière

Ce contexte provient généralement de systèmes supplémentaires tels que le MES, l'ERP, le modèle d'actifs ou l'application de production.

Devenez un supporter de ce podcast : https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.