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

Una lectura de temperatura, una muestra de vibración, un ciclo de máquina y una desconexión de dispositivo pueden describirse todos como eventos, pero no representan el mismo problema arquitectónico. En entornos de IoT industrial y manufactura, confundir la telemetría continua con los eventos discretos puede generar flujos de trabajo ruidosos, historiales de producción incompletos, procesamiento innecesario y sistemas que reaccionan sin suficiente contexto.

En este episodio, desglosamos la diferencia arquitectónica entre Azure IoT Hub Message Routing y Azure Event Grid siguiendo un escenario realista de manufactura. Una línea de prensas envía de forma continua información de temperatura, vibración, recuento de ciclos, consumo de energía y estado de la máquina a través de una pasarela industrial. Esas mediciones crean un historial operativo que ingenieros, equipos de datos, equipos de mantenimiento y sistemas de producción pueden necesitar analizar más adelante. Una desconexión de dispositivo es distinta, porque representa un cambio que puede requerir que otro sistema o persona reaccione.

LA TELEMETRÍA ES UN REGISTRO, NO UNA ALERTA
La telemetría representa mediciones repetidas a lo largo del tiempo. Un único valor de temperatura o una única medición de vibración normalmente dicen muy poco por sí solos. La información real existe en la secuencia: qué tan rápido cambiaron los valores, qué estaba haciendo la máquina en ese momento, qué ocurrió antes de una parada, si las mediciones desaparecieron durante una interrupción de red y si el mismo comportamiento apareció en ejecuciones de producción anteriores.


La telemetría industrial típica incluye:
• Temperatura, vibración, presión, consumo de energía y consumo de corriente
• Estados de la máquina como en marcha, inactiva, detenida o con fallo
• Recuentos de ciclos, contadores de producción y mediciones del proceso
• Marcas de tiempo de origen, identificadores de dispositivo, números de secuencia e información de correlación

Esos registros pueden respaldar más adelante la monitorización de condición, las investigaciones de calidad, el análisis energético, los cálculos de OEE, la analítica de Microsoft Fabric, los informes de Power BI y la optimización de la producción. Por eso la telemetría necesita retención, reproducción, gestión de duplicados, consumidores independientes y una forma fiable de reconstruir la línea temporal de producción.

IOT HUB MESSAGE ROUTING COMO PLANO DE DATOS DE TELEMETRÍA
Azure IoT Hub proporciona el límite controlado de comunicación de dispositivo a nube. Los dispositivos y las pasarelas se autentican con sus propias identidades, envían mensajes de dispositivo a nube, mantienen el estado de gestión de dispositivos y pueden participar en una comunicación controlada de nube a dispositivo.

Una vez que un mensaje de telemetría llega a IoT Hub, Message Routing determina a dónde deben ir esos datos. El enrutamiento puede inspeccionar propiedades del mensaje, propiedades del sistema, partes del cuerpo del mensaje y la información del device twin. Esto permite separar la telemetría de producción, las mediciones de energía, los diagnósticos u otras clases de mensajes antes de que lleguen a los consumidores posteriores.
Una arquitectura habitual podría verse así: Pasarela industrial → Azure IoT Hub → Message Routing → Event Hubs o Storage → Procesamiento → Microsoft Fabric.

Un consumidor puede realizar análisis casi en tiempo real, mientras que otro conserva un archivo bruto. Un tercer consumidor puede preparar datos operativos curados para Microsoft Fabric. Cada consumidor puede trabajar de forma independiente sin convertir cada lectura de telemetría en una invocación de flujo de trabajo.

POR QUÉ IMPORTA EL ORDEN
La telemetría industrial es especialmente sensible a la secuencia. Imagine una máquina que informa de que ha entrado en estado de marcha, luego transmite varios recuentos de ciclos, seguidos de una desviación de proceso y, finalmente, de un estado detenido. Si esos registros se reconstruyen incorrectamente, un sistema posterior podría concluir que la máquina produjo piezas mientras estaba parada, o que una desviación de proceso ocurrió después de que la producción ya había terminado.

El mismo problema afecta a los cálculos de tiempo de inactividad, OEE, recuentos de producción y monitorización de condición. Por ello es necesario distinguir entre cuándo la fuente observó algo, cuándo IoT Hub recibió el mensaje y cuándo un sistema posterior lo procesó.

Una arquitectura de telemetría robusta debe considerar, por tanto:
• Marcas de tiempo de origen y marcas de tiempo de recepción en la nube
• Particionado estable adecuado para el activo o la carga de trabajo
• Identificadores de mensaje o números de secuencia para detectar duplicados
• Consumidores idempotentes capaces de gestionar la entrega al menos una vez

Las interrupciones de red hacen que esto sea especialmente importante. Una pasarela puede almacenar en búfer la telemetría y enviarla cuando vuelva la conectividad, lo que significa que la hora de llegada a Azure puede ser mucho posterior a la marca de tiempo real de la máquina.

EVENT GRID RESUELVE UN PROBLEMA DIFERENTE
Azure Event Grid está diseñado en torno a notificaciones de publicación y suscripción. En lugar de reconstruir continuamente el estado de una máquina a partir de miles de lecturas, Event Grid informa a los sistemas interesados de que algo ha cambiado y da a los suscriptores la oportunidad de reaccionar.
Los ejemplos en un entorno de IoT incluyen la creación o eliminación de dispositivos, la conexión o desconexión, o condiciones derivadas de la telemetría cuidadosamente seleccionadas. Un evento de dispositivo creado podría activar un proceso de incorporación de activos. Un evento de dispositivo desconectado podría iniciar una investigación técnica. Una condición de ingeniería detectada podría activar un flujo de trabajo de mantenimiento.

Los suscriptores habituales incluyen:
• Azure Functions
• Logic Apps
• Webhooks
• Flujos de trabajo de seguridad
• Sistemas de gestión de activos
• Aplicaciones operativas

La diferencia arquitectónica fundamental es sencilla: la telemetría pregunta qué ha estado haciendo un activo, mientras que un evento pregunta qué cambió y si algo debe reaccionar.

LOS EVENTOS DEBEN INICIAR INVESTIGACIONES, NO DEFINIR LA REALIDAD
Event Grid debe tratarse, por lo general, como un mecanismo de notificación, no como el estado final y autoritativo del mundo físico. La entrega de eventos puede repetirse, y un suscriptor no debe interpretar ciegamente un evento como el estado actual final sin comprobarlo.
Un evento de dispositivo desconectado debería, por tanto, normalmente desencadenar una comprobación de estado. Una Azure Function podría verificar el estado actual del dispositivo, inspeccionar la telemetría reciente, consultar la información de registro pertinente y decidir después si la investigación debe permanecer abierta.

Los manejadores deben diseñarse en torno a:
• Procesamiento idempotente
• Verificación del estado actual
• Identidad y marcas de tiempo del evento
• Propiedad claramente definida de la acción resultante

Esto importa porque los eventos duplicados no deberían crear tickets, alertas o registros operativos duplicados o contradictorios.

UNA DESCONEXIÓN DEL DISPOSITIVO NO SIGNIFICA QUE LA MÁQUINA SE HAYA DETENIDO
Una de las distinciones más importantes en el IoT industrial es la diferencia entre conectividad en la nube, salud de la recogida de datos y estado de producción. Si una pasarela industrial se desconecta de IoT Hub, la nube ha perdido visibilidad sobre esa pasarela. Eso no significa automáticamente que la máquina física se haya detenido.

El PLC puede seguir controlando el equipo localmente mientras la pasarela pierde temporalmente la conectividad. La producción puede continuar con normalidad, e incluso la pasarela puede almacenar en búfer la telemetría y subirla más tarde. También puede ocurrir lo contrario: una pasarela puede seguir conectada a Azure mientras su conexión con el PLC o con el equipo local ha fallado.

Una arquitectura útil separa, por tanto, el estado de conexión con la nube, la salud de la pasarela, el estado de producción de la máquina y el estado de la orden de trabajo en el MES. Solo combinando esas fuentes puede el negocio determinar si un problema técnico de conectividad afectó realmente a la producción.

FILTRADO EN IOT HUB FRENTE A FILTRADO EN EVENT GRID
Ambas tecnologías admiten filtrado, pero su finalidad es distinta. El filtrado de IoT Hub Message Routing responde a qué mensajes operativos deben entrar en una ruta de datos concreta. El filtrado de suscripciones de Event Grid responde a qué notificaciones debe recibir un suscriptor determinado.

Por ejemplo, la telemetría de producción puede ir a un flujo de Event Hubs, mientras que los datos de energía van a otro destino. Al mismo tiempo, un flujo de trabajo de soporte puede suscribirse únicamente a los eventos de desconexión de un determinado