Маршрутизация сообщений IoT Hub и Event Grid — почему телеметрия и события — это не одна и та же задача

Телеметрия, показания температуры, выборки вибрации, цикл работы машины и отключение устройства могут все описываться как события, но они не представляют одну и ту же архитектурную задачу. В промышленном IoT и производственных средах смешение непрерывной телеметрии с дискретными событиями может приводить к шумным рабочим процессам, неполной истории производства, избыточной обработке и системам, которые реагируют без достаточного контекста.

В этом выпуске мы разбираем архитектурное различие между Azure IoT Hub Message Routing и Azure Event Grid на примере реалистичного производственного сценария. Линия прессов непрерывно передает данные о температуре, вибрации, счетчике циклов, энергопотреблении и состоянии машины через промышленный шлюз. Эти измерения формируют операционную историю, которую инженерам, командам по обработке данных, службам технического обслуживания и производственным системам может понадобиться анализировать позже. Отключение устройства отличается тем, что оно представляет собой изменение, на которое может потребоваться реакция другой системы или человека.

ТЕЛЕМЕТРИЯ — ЭТО ЗАПИСЬ, А НЕ ОПОВЕЩЕНИЕ
Телеметрия представляет собой повторяющиеся измерения во времени. Одно значение температуры или одно измерение вибрации обычно мало что говорит само по себе. Реальная информация содержится в последовательности: насколько быстро менялись значения, что делала машина в тот момент, что произошло перед остановкой, пропадали ли измерения во время сбоя сети и повторялось ли то же поведение в предыдущих производственных циклах.


Типичная промышленная телеметрия включает:
• Температуру, вибрацию, давление, энергопотребление и потребляемый ток
• Состояния машины, такие как работа, простой, остановка или авария
• Счетчики циклов, производственные счетчики и технологические измерения
• Временные метки источника, идентификаторы устройств, порядковые номера и информацию для корреляции

Эти записи впоследствии могут использоваться для мониторинга состояния, расследования качества, анализа энергопотребления, расчетов OEE, аналитики в Microsoft Fabric, отчетности в Power BI и оптимизации производства. Поэтому телеметрии необходимы хранение, воспроизведение, обработка дубликатов, независимые потребители и надежный способ восстановления производственной временной шкалы.

IOT HUB MESSAGE ROUTING КАК ПЛОСКОСТЬ ДАННЫХ ТЕЛЕМЕТРИИ
Azure IoT Hub обеспечивает контролируемую границу между устройствами и облаком. Устройства и шлюзы аутентифицируются со своими собственными идентификаторами, отправляют сообщения «устройство — облако», поддерживают состояние управления устройствами и могут участвовать в контролируемой передаче сообщений «облако — устройство».

Как только телеметрическое сообщение попадает в IoT Hub, Message Routing определяет, куда должны быть направлены эти данные. Маршрутизация может анализировать свойства сообщения, системные свойства, части тела сообщения и информацию device twin. Это позволяет разделить производственную телеметрию, данные об энергопотреблении, диагностику или другие классы сообщений до того, как они попадут к последующим потребителям.
Типичная архитектура может выглядеть так: промышленный шлюз → Azure IoT Hub → Message Routing → Event Hubs или Storage → обработка → Microsoft Fabric.

Один потребитель может выполнять анализ почти в реальном времени, а другой — хранить необработанный архив. Третий потребитель может подготавливать курированные операционные данные для Microsoft Fabric. Каждый потребитель может работать независимо, не превращая каждое показание телеметрии в запуск рабочего процесса.

ПОЧЕМУ ВАЖЕН ПОРЯДОК
Промышленная телеметрия особенно чувствительна к последовательности. Представьте, что машина сообщает о переходе в рабочее состояние, затем передает несколько значений счетчика циклов, после этого фиксируется отклонение процесса и, наконец, состояние остановки. Если эти записи будут восстановлены неправильно, последующая система может сделать вывод, что машина производила детали во время остановки, или что отклонение процесса произошло после завершения производства.

Та же проблема затрагивает расчеты простоев, OEE, подсчет продукции и мониторинг состояния. Поэтому необходимо различать момент, когда источник зафиксировал событие, момент, когда IoT Hub получил сообщение, и момент, когда последующая система его обработала.

Надежная архитектура телеметрии должна поэтому учитывать:
• Временные метки источника и временные метки получения в облаке
• Стабильное разбиение на разделы, соответствующее активу или рабочей нагрузке
• Идентификаторы сообщений или порядковые номера для обнаружения дубликатов
• Идемпотентных потребителей, способных обрабатывать доставку «как минимум один раз»

Сетевые сбои делают это особенно важным. Шлюз может буферизовать телеметрию и отправлять ее при восстановлении связи, поэтому время поступления в Azure может значительно отставать от реальной временной метки машины.

EVENT GRID РЕШАЕТ ДРУГУЮ ЗАДАЧУ
Azure Event Grid построен на модели публикации и подписки для уведомлений. Вместо того чтобы непрерывно восстанавливать состояние машины по тысячам показаний, Event Grid сообщает заинтересованным системам, что что-то изменилось, и дает подписчикам возможность отреагировать.
Примеры в IoT-среде включают создание устройства, удаление устройства, подключение, отключение или тщательно отобранные условия, полученные из телеметрии. Событие создания устройства может запустить процесс ввода актива в эксплуатацию. Событие отключения устройства может начать техническое расследование. Обнаруженное инженерное условие может запустить рабочий процесс технического обслуживания.

Типичные подписчики включают:
• Azure Functions
• Logic Apps
• Webhooks
• Рабочие процессы безопасности
• Системы управления активами
• Операционные приложения

Фундаментальное архитектурное различие простое: телеметрия отвечает на вопрос, что делал актив, тогда как событие отвечает на вопрос, что изменилось и нужно ли на это реагировать.

СОБЫТИЯ ДОЛЖНЫ ЗАПУСКАТЬ РАССЛЕДОВАНИЯ, А НЕ ОПРЕДЕЛЯТЬ РЕАЛЬНОСТЬ
Event Grid, как правило, следует рассматривать как механизм уведомлений, а не как окончательное авторитетное состояние физического мира. Доставка событий может повторяться, и подписчик не должен слепо интерпретировать события как окончательное текущее состояние без проверки.
Поэтому событие отключения устройства обычно должно запускать проверку состояния. Azure Function может проверить текущее состояние устройства, изучить недавнюю телеметрию, проверить соответствующую информацию в реестре, а затем решить, должно ли расследование оставаться открытым.

Обработчики должны проектироваться с учетом:
• Идемпотентной обработки
• Проверки текущего состояния
• Идентификации событий и временных меток
• Четко определенного владения результирующим действием

Это важно, потому что повторяющиеся события не должны создавать дублирующие заявки, дублирующие оповещения или конфликтующие операционные записи.

ОТКЛЮЧЕНИЕ УСТРОЙСТВА НЕ ОЗНАЧАЕТ, ЧТО МАШИНА ОСТАНОВИЛАСЬ
Одно из важнейших различий в промышленном IoT — это разница между облачным подключением, состоянием сбора данных и производственным состоянием. Если промышленный шлюз отключается от IoT Hub, облако теряет видимость этого шлюза. Это автоматически не означает, что физическая машина остановилась.

ПЛК может продолжать управлять оборудованием локально, пока шлюз временно теряет связь. Производство может идти нормально, а шлюз даже может буферизовать телеметрию и загрузить ее позже. Возможна и обратная ситуация: шлюз может оставаться подключенным к Azure, в то время как связь с ПЛК или локальным оборудованием нарушена.

Поэтому полезная архитектура разделяет состояние облачного подключения, состояние здоровья шлюза, производственное состояние машины и состояние рабочего задания MES. Только объединив эти источники, бизнес может определить, повлияла ли техническая проблема со связью на реальное производство.

ФИЛЬТРАЦИЯ В IOT HUB И ФИЛЬТРАЦИЯ В EVENT GRID
Обе технологии поддерживают фильтрацию, но их назначение различно. Фильтрация в IoT Hub Message Routing отвечает на вопрос, какие операционные сообщения должны попасть в определенный путь передачи данных. Фильтрация подписок Event Grid отвечает на вопрос, какие уведомления должен получать конкретный подписчик.

Например, производственная телеметрия может направляться в один поток Event Hubs, а данные об энергопотреблении — в другое место назначения. В то же время рабочий процесс поддержки может подписываться только на события отключения от определенного