Технології індустрії 4.0

У той час як архітектури клієнт-сервер багато років є основою для сервісів центрів обробки, моделі публікація-підписка (publish-subscribe) представляють собою альтернативу, яка корисна для використання IoT. Публікація-підписка, також відома як pub/sub, є способом відокремити клієнта, що передає повідомлення, від іншого клієнта, який отримує повідомлення. На відміну від традиційної моделі клієнт-сервер, клієнти не обізнані про будь-які фізичні ідентифікатори інтерфейсів пристроїв/програм, на зразок IP-адреси або порту.

MQTT - це архітектура pub/sub, однак не є чергою повідомлень. Черги повідомлень по природі своїй зберігають повідомлення, а MQTT - ні. У MQTT, якщо ніхто не підписується (або не слухає) на тему (topic), повідомлення просто ігноруються і втрачаються. Черги повідомлень також підтримують топологію клієнт-сервер, де один споживач з'єднаний з одним виробником.

Клієнт, що передає повідомлення, називається видавцем (publisher); клієнт, який отримує повідомлення - абонентом (subscriber). У центрі знаходиться MQTT-брокер (MQTT broker), який несе відповідальність за обмін повідомленнями між клієнтами і фільтрацію даних. Такі фільтри забезпечують:

• фільтрацію за темами (Topic Filters) - за задумом, клієнти підписуються на теми (topic) і певні гілки тем і не отримують даних більше, ніж хочуть. Кожне опубліковане повідомлення повинно містити тему (topic), і брокер несе відповідальність за повторну передачу цього повідомлення абонентам або ігнорування його;
• фільтрація по вмісту - брокери мають можливість перевіряти і фільтрувати опубліковані дані. Таким чином, будь-які дані, які не зашифровані, можуть керуватися брокером до того, як зберегти їх або передати іншим клієнтам;
• фільтрація за типом - клієнт, що прослуховує потік даних, на які він підписаний, може також застосовувати свої власні фільтри. Вхідні дані можуть аналізуватися, і в залежності від цього потік даних обробляється далі або ігнорується.

У MQTT може бути багато виробників і багато споживачів, як показано на рис. 3.

Клієнти працюють на краю (Edge), публікують і/або підписуються на теми, керовані брокером MQTT. У прикладі розглянуті дві теми (topic): вологість і температура. Клієнт може підписатися на кілька тем. На рисунку представлені розумні датчики, що володіють достатніми ресурсами для управління власним клієнтом MQTT, а також прикордонні маршрутизатори (Edge Routers), які надають клієнтські послуги MQTT від імені датчиків або пристроїв, які не підтримують MQTT. Одне із особливостей моделі обчислень видавець/абонент полягає в тому, що як видавець, так і абонент повинні знати тему гілки і формат даних перед початком передачі.

MQTT успішно відокремлює видавців від абонентів. Оскільки брокер є керівним органом між видавцями і абонентами, немає необхідності безпосередньо ідентифікувати їх на основі фізичних даних (таких як IP-адреса). Це дуже корисно при розгортанні IoT, оскільки фізичний ідентифікатор може бути невідомим або загальним. MQTT і інші моделі pub/sub також є часово-незалежними. Це значить, що повідомлення, опубліковане одним клієнтом-видавцем, може бути прочитане абонентом в будь-який час. Абонент може перебувати в місці з дуже низьким енергоспоживанням/обмеженою пропускною здатністю і відповісти на повідомлення через кілька хвилин або годин. Через відсутність фізичних і часових залежностей моделі pub/sub дуже добре підходять для підвищення продуктивності.

Керовані хмарно брокери MQTT зазвичай можуть поглинати мільйони повідомлень на годину і підтримувати десятки тисяч видавців.

MQTT не залежить від формату даних. Корисне навантаження (payload) може містити будь-який тип даних, тому і видавці, і абоненти повинні розуміти і погоджувати формат даних. У корисне навантаження можна надсилати текстові повідомлення, дані зображення, звукові дані, зашифровані дані, двійкові дані, об'єкти JSON або практично будь-яку іншу структуру. Однак текстові і двійкові дані JSON є найбільш поширеними типами даних корисного навантаження.

Максимально допустимий розмір пакета в MQTT становить 256 Мб, що дозволяє отримати надзвичайно велике корисне навантаження. Зверніть увагу, однак, що це також залежить від хмари і брокера. Наприклад, IBM Watson дозволяє обробляти дані розміром до 128 Кб, а Google підтримує 256 Кб. З іншого боку, опубліковане повідомлення може включати корисне навантаження нульової довжини. Поле корисного навантаження не є обов'язковим. Доцільно звірити відповідність розмірів корисного навантаження з вашим хмарним провайдером. Недотримання цієї вимоги призведе до помилок і відмови у доступі до хмарного брокера.