Маршрутизація повідомлень 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.

Один споживач може виконувати майже реальний аналіз, тоді як інший зберігає сирий архів. Третій споживач може готувати відібрані operational-дані для 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, хмара втрачає видимість цього шлюзу. Це автоматично не означає, що фізичний верстат зупинився.

PLC може продовжувати локально керувати обладнанням, поки шлюз тимчасово втрачає з'єднання. Виробництво може тривати нормально, а шлюз навіть може буферизувати телеметрію і завантажити її пізніше. Можливий і протилежний випадок: шлюз може залишатися підключеним до Azure, тоді як з'єднання з PLC або локальним обладнанням вже втрачено.

Тому корисна архітектура відокремлює стан хмарного з'єднання, стан здоров'я шлюзу, виробничий стан верстата та стан робочого наряду в MES. Лише поєднавши ці джерела, бізнес може визначити, чи технічна проблема зв'язку справді вплинула на виробництво.

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

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