Roteamento de Mensagens do IoT Hub vs Event Grid — Por que Telemetria e Eventos Não são o Mesmo Problema

Uma leitura de temperatura, uma amostra de vibração, um ciclo de máquina e a desconexão de um dispositivo podem todos ser descritos como eventos, mas não representam o mesmo problema de arquitetura. Em ambientes de IoT industrial e manufatura, confundir telemetria contínua com eventos discretos pode criar fluxos de trabalho ruidosos, históricos de produção incompletos, processamento desnecessário e sistemas que reagem sem contexto suficiente.

Neste episódio, detalhamos a diferença arquitetural entre o Roteamento de Mensagens do Azure IoT Hub e o Azure Event Grid, acompanhando um cenário realista de manufatura. Uma linha de prensas envia continuamente, por meio de um gateway industrial, informações de temperatura, vibração, contagem de ciclos, consumo de energia e estado da máquina. Essas medições criam um histórico operacional que engenheiros, equipes de dados, equipes de manutenção e sistemas de produção podem precisar analisar posteriormente. A desconexão de um dispositivo é diferente, pois representa uma mudança que pode exigir que outro sistema ou pessoa reaja.

A TELEMETRIA É UM REGISTRO, NÃO UM ALERTA
A telemetria representa medições repetidas ao longo do tempo. Um único valor de temperatura ou uma medição de vibração normalmente diz muito pouco por si só. A informação real existe na sequência: com que rapidez os valores mudaram, o que a máquina estava fazendo naquele momento, o que aconteceu antes de uma parada, se as medições desapareceram durante uma interrupção de rede e se o mesmo comportamento apareceu em execuções de produção anteriores.


A telemetria industrial típica inclui:
• Temperatura, vibração, pressão, consumo de energia e corrente elétrica
• Estados da máquina, como em operação, ociosa, parada ou com falha
• Contagens de ciclos, contadores de produção e medições de processo
• Carimbos de tempo de origem, identificadores de dispositivo, números de sequência e informações de correlação

Esses registros podem, posteriormente, dar suporte à monitoração de condição, investigações de qualidade, análise de energia, cálculos de OEE, análises no Microsoft Fabric, relatórios no Power BI e otimização da produção. Por isso, a telemetria exige retenção, reprocessamento, tratamento de duplicidades, consumidores independentes e uma forma confiável de reconstruir a linha do tempo da produção.

O ROTEAMENTO DE MENSAGENS DO IOT HUB COMO PLANO DE DADOS DE TELEMETRIA
O Azure IoT Hub fornece a fronteira controlada de comunicação do dispositivo para a nuvem. Dispositivos e gateways se autenticam com suas próprias identidades, enviam mensagens de dispositivo para nuvem, mantêm o estado de gerenciamento dos dispositivos e podem participar de uma comunicação controlada da nuvem para o dispositivo.

Quando uma mensagem de telemetria chega ao IoT Hub, o Roteamento de Mensagens determina para onde esses dados devem ir. O roteamento pode inspecionar propriedades da mensagem, propriedades do sistema, partes do corpo da mensagem e informações do device twin. Isso torna possível separar telemetria de produção, medições de energia, diagnósticos ou outras classes de mensagens antes que cheguem aos consumidores posteriores.
Uma arquitetura comum pode ser assim: Gateway industrial → Azure IoT Hub → Roteamento de Mensagens → Event Hubs ou Storage → Processamento → Microsoft Fabric.

Um consumidor pode realizar análises quase em tempo real, enquanto outro mantém um arquivo bruto. Um terceiro consumidor pode preparar dados operacionais curados para o Microsoft Fabric. Cada consumidor pode trabalhar de forma independente, sem transformar cada leitura de telemetria em uma invocação de fluxo de trabalho.

POR QUE A ORDENAÇÃO IMPORTA
A telemetria industrial é particularmente sensível à sequência. Imagine uma máquina informando que entrou em estado de operação, depois transmitindo várias contagens de ciclos, seguidas de um desvio de processo e, por fim, de um estado de parada. Se esses registros forem reconstruídos incorretamente, um sistema posterior poderia concluir que a máquina produziu peças enquanto estava parada ou que um desvio de processo ocorreu depois de a produção já ter terminado.

O mesmo problema afeta os cálculos de tempo de parada, OEE, contagens de produção e monitoração de condição. Por isso, é preciso distinguir entre quando a origem observou algo, quando o IoT Hub recebeu a mensagem e quando um sistema posterior a processou.

Uma arquitetura de telemetria robusta deve, portanto, considerar:
• Carimbos de tempo de origem e carimbos de recebimento na nuvem
• Particionamento estável adequado ao ativo ou à carga de trabalho
• IDs de mensagem ou números de sequência para detecção de duplicidades
• Consumidores idempotentes capazes de lidar com entrega do tipo pelo menos uma vez

Interrupções de rede tornam isso especialmente importante. Um gateway pode armazenar telemetria em buffer e enviá-la quando a conectividade retornar, o que significa que o horário de chegada no Azure pode ser muito posterior ao carimbo de tempo real da máquina.

O EVENT GRID RESOLVE UM PROBLEMA DIFERENTE
O Azure Event Grid é projetado em torno de notificações do tipo publicação e assinatura. Em vez de reconstruir continuamente o estado de uma máquina a partir de milhares de leituras, o Event Grid informa aos sistemas interessados que algo mudou e oferece aos assinantes a oportunidade de reagir.
Exemplos em um ambiente de IoT incluem criação de dispositivo, exclusão de dispositivo, conexão, desconexão ou condições selecionadas cuidadosamente derivadas da telemetria. Um evento de dispositivo criado pode disparar um processo de integração de ativos. Um evento de dispositivo desconectado pode iniciar uma investigação técnica. Uma condição de engenharia detectada pode disparar um fluxo de trabalho de manutenção.

Assinantes típicos incluem:
• Azure Functions
• Logic Apps
• Webhooks
• Fluxos de trabalho de segurança
• Sistemas de gestão de ativos
• Aplicações operacionais

A diferença arquitetural fundamental é simples: a telemetria pergunta o que um ativo vem fazendo, enquanto um evento pergunta o que mudou e se algo deve reagir.

EVENTOS DEVEM INICIAR INVESTIGAÇÕES, NÃO DEFINIR A REALIDADE
O Event Grid deve geralmente ser tratado como um mecanismo de notificação, e não como o estado autoritativo final do mundo físico. A entrega de eventos pode ser repetida, e um assinante não deve interpretar cegamente um evento como o estado atual final sem verificar.
Um evento de dispositivo desconectado, portanto, normalmente deve disparar uma verificação de estado. Uma Azure Function pode confirmar o estado atual do dispositivo, inspecionar a telemetria recente, consultar informações relevantes do registro e então decidir se a investigação deve permanecer aberta.

Os manipuladores devem ser projetados em torno de:
• Processamento idempotente
• Verificação do estado atual
• Identidade e carimbos de tempo do evento
• Propriedade claramente definida da ação resultante

Isso é importante porque eventos duplicados não devem gerar chamados, alertas ou registros operacionais duplicados ou conflitantes.

UMA DESCONEXÃO DE DISPOSITIVO NÃO SIGNIFICA QUE A MÁQUINA PAROU
Uma das distinções mais importantes em IoT industrial é a diferença entre conectividade com a nuvem, saúde da coleta de dados e estado de produção. Se um gateway industrial se desconecta do IoT Hub, a nuvem perdeu a visibilidade sobre esse gateway. Isso não significa automaticamente que a máquina física parou.

O CLP pode continuar controlando o equipamento localmente enquanto o gateway temporariamente perde a conectividade. A produção pode continuar normalmente, e o gateway pode até armazenar a telemetria em buffer e enviá-la mais tarde. O inverso também pode acontecer: um gateway pode permanecer conectado ao Azure enquanto sua conexão com o CLP ou com o equipamento local falhou.

Uma arquitetura útil, portanto, separa o estado de conexão com a nuvem, a saúde do gateway, o estado de produção da máquina e o estado da ordem de trabalho no MES. Somente combinando essas fontes o negócio pode determinar se um problema técnico de conectividade realmente afetou a produção.

FILTRAGEM NO IOT HUB VS FILTRAGEM NO EVENT GRID
Ambas as tecnologias oferecem suporte a filtragem, mas com finalidades diferentes. A filtragem do Roteamento de Mensagens do IoT Hub responde quais mensagens operacionais devem entrar em um caminho de dados específico. A filtragem de assinaturas do Event Grid responde quais notificações um assinante específico deve receber.

Por exemplo, a telemetria de produção pode ir para um fluxo do Event Hubs, enquanto os dados de energia vão para outro destino. Ao mesmo tempo, um fluxo de suporte pode assinar apenas os eventos de desconexão de um determinado