Маршрутизація повідомлень 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 і моделі активів надають контекст, якого самі лише дані пристроїв не дають
• Як інтерпретувати події відключення пристрою, не припускаючи автоматично, що виробництво зупинилося
• Як дубльована доставка, повторні спроби, мітки часу та ідемпотентність впливають на надійність промислових архітектур
• Як проєктувати workflow для моніторингу стану, предиктивного обслуговування, простежуваності якості та порушень виробництва
• Як вирішити, чи належить повідомлення до площини даних, шляху реагування або до обох

ТЕЛЕМЕТРІЯ — ЦЕ ЗАПИС У ЧАСІ
Телеметрія цінна не тому, що надійшло одне значення температури. Вона стає цінною, коли тисячі показників разом описують, що сталося. Виробнича машина може безперервно передавати:

• Вимірювання температури та вібрації
• Струм двигуна та споживання енергії
• Лічильники циклів і виробничі лічильники
• Стани «працює», «простій», «зупинено» або «несправність»
• Вихідні мітки часу та інформацію про послідовність
• Діагностичну інформацію та дані про стан обладнання

Одне значення температури може мало що означати. Послідовність навколо нього розповідає історію. Чи машина прогрівалася? Чи вона вже виробляла продукцію? Чи одночасно зростала вібрація? Чи почав збільшуватися час циклу? Чи зупинилася машина невдовзі після цього? Тому телеметрія потребує шляху, розробленого з урахуванням послідовності, зберігання, відтворення, незалежних споживачів і простежуваності.

ПОДІЇ ІСНУЮТЬ, ЩОБ ПОЧАТИ РЕАКЦІЮ
Подія має інше призначення. Подія каже: щось змінилося. Система або людина може потребувати реакції. Приклади:

• Зареєстровано новий пристрій
• Шлюз відключився від 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.