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

Машина отправляет показания температуры, данные вибрации, счётчики циклов, потребление энергии и рабочие состояния каждые несколько секунд. Затем шлюз внезапно отключается. Можно ли считать все эти сообщения просто «событиями»? Технически — да. Архитектурно — это может создать серьёзные проблемы. Azure IoT Hub Message Routing и Azure Event Grid решают разные задачи. Один путь рассчитан на сохранение и распространение эксплуатационных данных. Другой — на уведомление систем о том, что что-то изменилось и, возможно, требует реакции. Считать их взаимозаменяемыми — значит получить дорогостоящие процессы, обрабатывающие рутинные данные датчиков, либо важные сигналы, затерянные внутри конвейера телеметрии, за которым никто активно не следит. В этом выпуске M365 FM мы проследим путь производственной машины через реальную архитектуру Azure IoT и объясним, где на самом деле должны находиться IoT Hub, Event Grid, Event Hubs, Microsoft Fabric, Power BI, MES, ERP, Functions и Logic Apps.

ЧТО ВЫ УЗНАЕТЕ
В этом выпуске мы рассмотрим:

• Почему телеметрия оборудования и дискретные бизнес- или жизненные события требуют разных архитектурных шаблонов
• Как работает Azure IoT Hub Message Routing как часть плоскости данных телеметрии
• Где Azure Event Grid занимает место в событийно-ориентированных и реактивных архитектурах
• Почему порядок сообщений важен для производственной телеметрии
• Почему Event Grid не должен становиться основной высоконагруженной шиной телеметрии
• Почему маршрутизацию IoT Hub не нужно навязывать каждому процессу уведомлений
• Как IoT Hub и Event Grid могут работать вместе в одной архитектуре
• Как Event Hubs может поддерживать независимых потребителей потоковой обработки
• Почему необработанную телеметрию часто стоит хранить для прослеживаемости и последующего расследования
• Как Microsoft Fabric и Power BI могут использовать подготовленные эксплуатационные данные
• Почему MES, ERP и модели активов дают контекст, которого не могут дать одни только данные устройств
• Как интерпретировать события разрыва связи устройства, не предполагая автоматически, что производство остановилось
• Как дублирование доставки, повторные попытки, метки времени и идемпотентность влияют на надёжность промышленных архитектур
• Как проектировать мониторинг состояния, предиктивное обслуживание, прослеживаемость качества и процессы реагирования на остановку производства
• Как решить, относится ли сообщение к плоскости данных, пути реагирования или к обоим

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

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

Одно значение температуры может мало что значить. История вокруг этого показания рассказывает целую картину. Прогревалась ли машина? Уже ли она выпускала продукцию? Одновременно ли росла вибрация? Начало ли увеличиваться время цикла? Остановилась ли машина вскоре после этого? Поэтому телеметрия требует пути, построенного вокруг последовательности, хранения, повторного воспроизведения, независимых потребителей и прослеживаемости.

СОБЫТИЯ СУЩЕСТВУЮТ, ЧТОБЫ ЗАПУСТИТЬ РЕАКЦИЮ
Событие служит другой цели. Событие говорит: что-то изменилось. Система или человек может потребовать реакции. Примеры:

• Зарегистрировано новое устройство
• Шлюз отключился от IoT Hub
• Устройство переподключилось
• Устройство было удалено
• Процесс мониторинга обнаружил состояние, требующее расследования
• Проверка завершена, и может начаться другой процесс

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

• Запуск Azure Function
• Запуск Logic App
• Открытие обращения в службу поддержки
• Обновление записи об активе
• Проверку текущего состояния устройства
• Вызов внешнего приложения через webhook
• Уведомление команды, ответственной за затронутую систему

Событие запускает расследование. Оно не обязательно содержит все факты, необходимые для окончательного эксплуатационного решения.

ПОЧЕМУ ПРИНЦИП «ВСЁ — СОБЫТИЕ» ДАЁТ СБОЙ
Отправка каждого измерения датчика в процессы, запускаемые событиями, может выглядеть привлекательно на этапе пилотного проекта. Затем наступает масштаб производства. Каждое показание запускает ещё одну Function. Другая Logic App что-то оценивает. Другая интеграция получает очередное сообщение. Обслуживание создаёт собственную подписку. Качество — ещё одну. Энергоменеджмент — ещё одну. Вскоре каждая команда использует слегка разную фильтрацию, управление состоянием, обработку повторов и логику хранения. Измерение температуры автоматически не является инцидентом. Оно может впоследствии способствовать инциденту, но непрерывные измерения должны оставаться доступными как доказательства. Когда рутинная телеметрия начинает генерировать постоянные уведомления, пользователи также могут начать игнорировать оповещения, потому что система приучила их к шуму, а не к полезной информации.

ЧТО НА САМОМ ДЕЛЕ ДЕЛАЕТ AZURE IOT HUB
Azure IoT Hub обеспечивает облачную границу, обращённую к устройствам. Он поддерживает такие области, как:

• Безопасные идентификаторы устройств
• Обмен сообщениями «устройство — облако»
• Связь «облако — устройство»
• Управление устройствами
• Device twins
• Контролируемый доступ между подключённым оборудованием и службами Azure

IoT Hub знает, что аутентифицированное устройство отправило сообщение. Он автоматически не понимает, что это сообщение означает для производства. Шлюз может сообщить: state = running Но «running» может означать:

• Выпуск одобренных деталей
• Холостой цикл
• Выполнение наладки
• Выполнение переделки
• Перемещение без материала

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

Поддержать этот подкаст: https://www.spreaker.com/podcast/m365-fm-a-microsoft-mvp-podcast-by-mirko-peters--6704921/support.