Enrutamiento de mensajes de IoT Hub frente a Event Grid: por qué la telemetría y los eventos no son el mismo problema

Una máquina envía lecturas de temperatura, datos de vibración, conteos de ciclos, consumo de energía y estados de operación cada pocos segundos. Luego, la puerta de enlace se desconecta repentinamente. ¿Son todos esos mensajes simplemente “eventos”? Técnicamente, se podría describirlos así. Arquitectónicamente, eso puede generar problemas serios. Azure IoT Hub Message Routing y Azure Event Grid resuelven problemas distintos. Una ruta está diseñada para preservar y distribuir datos operativos. La otra está diseñada para notificar a los sistemas que algo cambió y que quizá requiera una respuesta. Tratarlos como intercambiables puede dejarte con flujos de trabajo costosos que procesan datos rutinarios de sensores, o con señales importantes enterradas dentro de un canal de telemetría que nadie está vigilando activamente. En este episodio de M365 FM, seguimos a una máquina de fabricación a través de una arquitectura real de Azure IoT y explicamos dónde pertenecen realmente IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions y Logic Apps.

QUÉ APRENDERÁS

En este episodio exploramos:

• Por qué la telemetría de máquinas y los eventos discretos de negocio o de ciclo de vida requieren patrones de arquitectura diferentes
• Cómo funciona Azure IoT Hub Message Routing como parte de un plano de datos de telemetría
• Dónde encaja Azure Event Grid en arquitecturas basadas en eventos y reactivas
• Por qué el orden de los mensajes importa para la telemetría de fabricación
• Por qué Event Grid no debería convertirse en tu bus principal de telemetría de alto volumen
• Por qué el enrutamiento de IoT Hub no debería forzarse en todos los flujos de notificación
• Cómo IoT Hub y Event Grid pueden trabajar juntos en la misma arquitectura
• Cómo Event Hubs puede dar soporte a consumidores independientes de procesamiento de flujos
• Por qué los datos brutos de telemetría deben conservarse a menudo para trazabilidad y posterior investigación
• Cómo Microsoft Fabric y Power BI pueden consumir datos operativos preparados
• Por qué MES, ERP y los modelos de activos aportan un contexto que los datos del dispositivo por sí solos no pueden ofrecer
• Cómo interpretar los eventos de desconexión de un dispositivo sin asumir automáticamente que la producción se detuvo
• Cómo la entrega duplicada, los reintentos, las marcas de tiempo y la idempotencia afectan a las arquitecturas industriales fiables
• Cómo diseñar flujos de monitorización de condición, mantenimiento predictivo, trazabilidad de calidad y gestión de interrupciones de producción
• Cómo decidir si un mensaje pertenece al plano de datos, a la ruta de respuesta, o a ambos

LA TELEMETRÍA ES UN REGISTRO A LO LARGO DEL TIEMPO

La telemetría no es valiosa porque llegó una lectura de temperatura. Se vuelve valiosa porque miles de lecturas juntas describen lo que ocurrió. Una máquina de producción puede reportar de forma continua:

• Mediciones de temperatura y vibración
• Corriente del motor y consumo de energía
• Conteos de ciclos y contadores de producción
• Estados de funcionamiento, inactividad, parada o fallo
• Marcas de tiempo de origen e información de secuencia
• Información de diagnóstico y de salud del equipo

Un único valor de temperatura puede significar muy poco. La secuencia alrededor de esa lectura cuenta la historia. ¿La máquina se estaba calentando? ¿Ya estaba produciendo? ¿La vibración estaba aumentando al mismo tiempo? ¿El tiempo de ciclo empezó a crecer? ¿La máquina se detuvo poco después? Por tanto, la telemetría necesita una ruta diseñada en torno a la secuencia, la retención, la reproducción, los consumidores independientes y la trazabilidad.

LOS EVENTOS EXISTEN PARA INICIAR UNA RESPUESTA

Un evento cumple otro propósito. Un evento dice: algo cambió. Un sistema o una persona puede necesitar reaccionar. Algunos ejemplos son:

• Se registró un nuevo dispositivo
• Una puerta de enlace se desconectó de IoT Hub
• Un dispositivo se reconectó
• Un dispositivo fue eliminado
• Un proceso de monitorización detectó una condición que requiere investigación
• Una inspección se completó y puede comenzar otro flujo de trabajo

Normalmente, el destinatario no necesita horas de telemetría antes de comenzar el primer paso. Necesita información suficiente para identificar qué ocurrió y determinar la respuesta adecuada. Esa respuesta podría implicar:

• Iniciar una Azure Function
• Activar una Logic App
• Abrir una investigación de soporte
• Actualizar un registro de activo
• Consultar el estado actual del dispositivo
• Llamar a una aplicación externa mediante un webhook
• Notificar al equipo responsable del sistema afectado

El evento inicia la investigación. No necesariamente contiene todos los hechos necesarios para tomar la decisión operativa final.

POR QUÉ “TODO ES UN EVENTO” FALLA

Enviar cada medición de sensor a flujos de trabajo activados por eventos puede parecer atractivo durante una prueba de concepto. Luego llega la escala de producción. Cada lectura activa otra Function. Otra Logic App evalúa algo. Otra integración recibe otro mensaje. Mantenimiento crea su propia suscripción. Calidad crea otra. Gestión energética crea otra más. Pronto, cada equipo tiene un filtrado, un manejo de estado, una gestión de reintentos y una lógica de almacenamiento ligeramente distintos. Una medición de temperatura no es automáticamente un incidente. Puede contribuir a un incidente más adelante, pero las mediciones continuas deben seguir disponibles como evidencia. Cuando la telemetría rutinaria empieza a generar notificaciones constantes, los usuarios también pueden empezar a ignorar las alertas, porque el sistema les ha enseñado a esperar ruido en lugar de información accionable.

QUÉ HACE REALMENTE AZURE IOT HUB

Azure IoT Hub proporciona el límite en la nube orientado a los dispositivos. Admite áreas como:

• Identidades seguras de dispositivos
• Mensajería de dispositivo a nube
• Comunicación de nube a dispositivo
• Gestión de dispositivos
• Device twins
• Acceso controlado entre equipos conectados y servicios de Azure

IoT Hub sabe que un dispositivo autenticado envió un mensaje. No entiende automáticamente lo que ese mensaje significa para la producción. Una puerta de enlace podría reportar: estado = en funcionamiento. Pero “en funcionamiento” podría significar:

• Produciendo piezas aprobadas
• Ciclando en seco
• Ejecutando preparación
• Realizando retrabajo
• Moviéndose sin material

Ese contexto normalmente proviene de sistemas adicionales como el MES, el ERP, el modelo de activos o la aplicación de producción.

Hazte partidario de este podcast: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.