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

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

2. КЛАССИФИКАЦИЯ ЗАВОДСКОГО ТРАФИКА
Перед выбором сервисов Azure трафик необходимо классифицировать по назначению, направлению и владельцу, чтобы обеспечить правильную обработку.

• События (Events) — это факты, привязанные к конкретному моменту времени, описывающие, что произошло и когда, например, завершённый цикл пресса или показание вибрации, превысившее предел. Это записи только для добавления (append-only), которые не должны редактироваться на последующих этапах.
• Команды (Commands) — это запросы, предписывающие устройству или шлюзу выполнить действие с определённым намерением, например собрать диагностику или проверить соединение. Они несут ответственность за исполнение и должны соблюдать границы локальных программируемых логических контроллеров (PLC) и систем безопасности.
• Состояние (State) отражает текущее известное состояние устройства, например его версию ПО или активное сопоставление рецептов, а не полную хронологическую историю. Состояние обычно управляется через желаемые и сообщаемые свойства (desired and reported properties).
• Бизнес-сообщения (Business messages) — это операционная работа, которая должна быть выполнена и отслеживаться, включая карантин качества и заявки на техобслуживание. Их никогда не следует смешивать с необработанными конвейерами событий датчиков.

3. МЕНТАЛЬНАЯ МОДЕЛЬ: ШЛЮЗ ИДЕНТИЧНОСТИ И ШИРОКАЯ МАГИСТРАЛЬ ДАННЫХ
Azure IoT Hub выступает как контролируемый шлюз, сосредоточенный прежде всего на отношениях с устройствами и их жизненном цикле через реестр идентификаторов, аутентификацию и статус включено/отключено. Это позволяет службам безопасности изолировать или отключить один скомпрометированный или подозрительный шлюз — например, шлюз линии 4 — во время инцидента, не останавливая весь телеметрический канал завода. Напротив, Azure Event Hubs служит широкой магистралью данных, полностью сосредоточенной на потоковой обработке и высокообъёмном перемещении для множества независимых читателей. Event Hubs не управляет жизненным циклом устройств, прошивками или желаемыми конфигурациями; его основная задача — эффективно пропускать трафик через разделы и группы потребителей.

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

5. МЕХАНИКА ПОТОКОВОЙ ОБРАБОТКИ И МАРШРУТИЗАЦИИ
Разделы (partitions) делят потоки на упорядоченные полосы, где гарантии порядка строго действуют внутри одного раздела; обычно разделение выполняется по ID станка, линии или шлюза в соответствии с бизнес-логикой. Группы потребителей (consumer groups) позволяют нескольким последующим системам — таким как калькуляторы OEE, инструменты мониторинга состояния и службы загрузки в озеро данных — читать один и тот же поток независимо, не конкурируя за позиции чтения. Хранение потока (stream retention) обеспечивает рабочее окно для краткосрочного восстановления, отказоустойчивости и исправления логики через повторное воспроизведение. Однако хранение потока не заменяет долговременный историк или lakehouse для длительного архивного хранения.

6. СВОДКА АРХИТЕКТУРНЫХ РЕШЕНИЙ
При оценке сервисов Azure IoT Hub лучше всего использовать для управляемых пограничных шлюзов, удалённых конфигураций и изоляции безопасности устройств через реестр для каждого устройства и нативные device twins. Azure Event Hubs лучше всего подходит для непрерывной высокообъёмной телеметрии, распределяемой нескольким потребителям с помощью политик доступа на уровне пространства имён, без нативного управления жизненным циклом устройств. Надёжная архитектура завода часто сочетает оба варианта: IoT Hub на границе подключения для управления доверием, идентичностью и конфигурацией, а Event Hubs — ниже по потоку для безопасного распределения высокообъёмного потока событий между независимыми потребителями.

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