IoT Hub проти Event Hubs — чому більшість виробників обирають не той сервіс

1. СИМПТОМ НА ВИРОБНИЧОМУ ЦЕХУ ТА ОСНОВНА ПРОБЛЕМА. Команди часто надсилають телеметрію з обладнання до Azure, використовуючи той сервіс, який здається правильним на початкових воркшопах, і лише через кілька місяців виявляють, що шлях даних не може забезпечити реальну роботу виробництва. Це часто призводить до того, що кілька дашбордів показують суперечливі значення (наприклад, 5-хвилинні середні порівняно з максимальними значеннями або тривогами), похідні від копій одного і того самого сигналу. Зрештою, цей технічний розрив створює проблему довіри, а не просту програмну помилку. Коренева помилка полягає у трактуванні всіх вхідних даних від машин як загальної телеметрії замість розділення керування пристроями, стану конфігурації, команд і обробки потоків.

2. КЛАСИФІКАЦІЯ ТРАФІКУ ФАБРИКИ. Перш ніж вибирати сервіси Azure, трафік має бути класифікований за назвою, напрямком і власником, щоб забезпечити належну обробку.

• Події являють собою факти, прив'язані до конкретного моменту часу, що описують, що сталося і коли, наприклад, завершений цикл преса або вимірювання вібрації, що перевищило межу. Це записи лише для додавання, які не слід редагувати на наступних етапах.
• Команди є запитами, які вказують пристрою або шлюзу виконати дію з конкретною метою, наприклад зібрати діагностику або перевірити з'єднання. Вони несуть відповідальність за виконання і мають дотримуватися локальних меж програмованих логічних контролерів (PLC) та безпеки.
• Стан відображає поточний відомий стан пристрою, наприклад його версію програмного забезпечення або активне відповідність рецептур, а не його повну хронологічну історію. Стан, як правило, керується через бажані та звітовані властивості.
• Бізнес-повідомлення стосуються операційної роботи, яка має бути виконана і відстежена, зокрема утримання якості та запити на технічне обслуговування. Їх ніколи не слід безпосередньо змішувати з конвеєрами сирих подій із датчиків.

3. МЕНТАЛЬНА МОДЕЛЬ: ШЛЮЗ ІДЕНТИЧНОСТІ ПРОТИ ШЛЯХУ ДАНИХ. Azure IoT Hub діє як контрольований шлюз, зосереджений насамперед на зв'язках із пристроями та їх життєвих циклах через реєстр ідентифікації, автентифікацію та статус увімкнено або вимкнено. Це дозволяє службам безпеки ізолювати або вимкнути один скомпрометований чи підозрілий шлюз, наприклад шлюз лінії 4, під час інциденту, не зупиняючи весь шлях телеметрії заводу. Натомість Azure Event Hubs служить шляхом даних, повністю орієнтованим на обробку потоків і передачу великих обсягів для багатьох незалежних читачів. Event Hubs не керує життєвими циклами пристроїв, прошивками чи бажаними конфігураціями; його основне завдання полягає в ефективному переміщенні трафіку через розділи та групи споживачів.

4. УПРАВЛІННЯ ПРИСТРОЯМИ ТА БЕЗПЕКА. Варіанти автентифікації сильно залежать від можливостей апаратного забезпечення та архітектури безпеки. Симетричні ключі з використанням токенів SAS добре підходять для обмеженого апаратного забезпечення та шлюзів, але вимагають безпечного апаратного зберігання для запобігання викраденню ключів. Альтернативно, сертифікати X.509 забезпечують чистіші ланцюги через довірений центр сертифікації для великих парків пристроїв, хоча вони вимагають надійного керування ротацією та життєвим циклом. Життєвий цикл пристрою слідує за шаблоном реєстрації, зміни, вимкнення та заміни, гарантуючи, що замінний апаратний блок чисто пов'язується зі своєю операційною роллю та хмарною ідентичністю без порушення наступних конвеєрів або створення фантомних активів. Крім того, двійники пристроїв використовують бажані та звітовані стани для керування конфігурацією та статусом справності, однак телеметрію з високою частотою ніколи не слід зберігати в двійниках пристроїв.

5. ОБРОБКА ПОТОКІВ ТА МЕХАНІКА МАРШРУТИЗАЦІЇ. Розділи поділяють потоки на впорядковані смуги, де гарантії порядку суворо діють лише в межах одного розділу, як правило, розподіленого за ідентифікатором машини, лінії або шлюзу відповідно до бізнес-логіки. Групи споживачів дозволяють кільком наступним системам, таким як калькулятори OEE, інструменти моніторингу стану та сервіси завантаження в data lake, незалежно читати один і той самий потік без конкуренції за позиції читання. Зберігання потоку забезпечує робоче вікно для короткострокового відновлення, відмовостійкості та виправлення логіки через повторне відтворення. Однак зберігання потоку не замінює довговічний історик або lakehouse для довгострокового ведення записів.

6. ПІДСУМОК АРХІТЕКТУРНОГО РІШЕННЯ. Під час оцінки сервісів Azure IoT Hub найкраще використовувати для керованих периферійних шлюзів, віддалених конфігурацій та ізоляції безпеки пристроїв через реєстр для кожного пристрою та вбудовані двійники пристроїв. Azure Event Hubs найкраще використовувати для безперервної телеметрії великого обсягу, що розподіляється між кількома споживачами з використанням політик доступу на рівні простору імен, без вбудованого керування життєвим циклом пристроїв. Надійна архітектура фабрики часто поєднує обидва варіанти: IoT Hub на межі підключення для керування довірою, ідентичністю та конфігурацією, а Event Hubs на наступних етапах для безпечного розподілу потоку подій великого обсягу між незалежними споживачами.






Станьте підтримувачем цього подкасту: https://www.spreaker.com/podcast/m365-fm-microsoft-365-azure-cloud-power-platform-ai--6704921/support.