Лекція 2.2. Передача даних в архітектурі IIoT: MQTT

1. Мережі в архітектурі IIoT

У архітектурі IIoT (рис.1) усі апаратні та програмні складові розосереджені і потребують мережних комунікацій. Ці мережі умовно можна поділити на:

• мережі датчиків; від датчика/ВМ до IoT Edge пристрою, наприклад:
  • бездротові Zig Bee, Blue Tooth,
  • бездротові промислові: Wireless Hart, ISA 100…
  • дротові: 1-wire, I²C…
  • дротові промислові: Hart, AS-i, Profibus PA, I/O Link…
• промислові мережі рівня контролерів; від контролеру/периферійного засобу до Edge пристрою, наприклад: Modbus, Profibus DP, Profinet IO   
• локальні мережі; між Edge пристроями та маршрутизаторами, комп’ютерами, гаджетами: Ethernet, Wireless 802.11
• глобальна мережа Internet; між компонентами (вузлами, сервісами, прикладними програмами);    

Для цих мереж характерне різне призначення та використовуються різні протоколи.

Мережі рівня датчиків призначені для підключення датчиків безпосередньо до IoT/IIoT Edge пристрою. Тобто їх задача – забезпечити доставку вимірювальних даних для їх первинної обробки та відправки іншим вузлам IoT/IIoT архітектури. Розгляд бездротових та дротових мереж на рівні датчиків виходить за рамки даної дисципліни. Слід відмітити, що використання звичайних (непромислових) мереж з точки зору промислового виконання IIoT є досить обмеженим.

Промислові мережі рівня контролерів характерні для IIoT архітектури і призначені для підключення розумних пристроїв типу контролер, розподілена периферія (засоби розподіленого I/O, приводи, тощо) до Edge пристрою з метою проміжної обробки і маршрутизації даних в архітектурі IIoT. Протоколи промислових мереж розглядаються в інших дисциплінах. Вважається, що читач знайомий з основами роботи Modbus RTU та Modbus TCP/IP.

Під локальними мережами розуміється мережі на базі провідного і безпровідного Ethernet (в широкому сенсі) та протоколів TCP/IP, що використовуються для різних задач об’єднання вузлів на стороні Edge та кінцевих користувачів. Ці мережі не розглядаються в даному курсі, передбачається що читач знайомий з основами роботи Ethernet та TCP/IP  на рівні користувача.

  В даному курсі розглядаються ті протоколи, що використовуються для зв’язку між компонентами IoT/IIoT від Edge до хмари та між компонентами в Internet за межами Edge.   

Мережні технології за межами Edge широко використовуються в Інтернет вже кілька десятків років. Розподілені застосунки в Інтернет передбачають взаємодію як мінімум 2-х програм – на стороні серверу, де відбувається збереження та/або обробка даних, та клієнта, де ці результати необхідні. Велика частина застосунків передбачає наявність взаємопов’язаних серверних компонентів. Враховуючи популярність протоколу HTTP, як правило, саме він використовується в якості транспорту для обміну між ними. Для відкритого (але нерідко обмеженого) доступу до наявних сервісів серверних застосунків, використовуються WEB API. Тому розуміння WEB API має велике значення для проектування архітектури IIoT та розробки компонентів. У наступному розділі розглядається WEB API та RESTFul.

         Взаємодія між пристроями Edge (концентратори, маршрутизатори, шлюзи) або інтелектуальними IoT/IIoT пристроями та серверними компонентами слугує для передачі даних з/на польового рівня. Тут також можуть використовуватися HTTP протоколи, однак в багатьох випадках WEB технології можуть не підійти до таких задач. Пристрої IoT/IIoT можуть мати досить суттєві обмеження в обчислювальних ресурсах та полосі пропускання в мережі. Тому для керування великою кількістю таких пристроїв в різноманітних мережних топологіях необхідні більш ефективні, безпечні і масштабовані протоколи. Багато з таких протоколів представляють собою реалізації проміжного ПЗ, орієнтованого на повідомлення (message oriented middleware, MOM). Додатково про MOM можна почитати за посиланням. Основна задача такого ПЗ забезпечити зв’язок між декількома програмними компонентами з використанням черги повідомлень. Одні компоненти розміщують повідомлення в черзі, інші їх зчитують з неї. Деякі реалізації передбачають наявність в структурі в якості провайдера повідомлень окремого посередника, який також називається брокером. У цьому випадку, одні клієнти публікують дані на брокері, а інші отримують ці дані за підпискою (рис.2). До таких протоколів відносяться AMQP, MQTT, STOMP та інші. У даному курсі ми розглянемо протокол MQTT, як один із самих популярних на сьогоднішній день.    

На рис.3 показана робота MOM у порівнянні з RESTful. Для МОМ багато клієнтів можуть бути як видавцями (publish) так і абонентами (subscribe) і  інформація може як зберігатися так і не зберігатися на брокері. В RESTFul взаємодія відбувається безпосередньо між клієнтом і сервером.

2. Історія MQTT

Технологія IBM Websphere Message Queue була вперше придумана в 1993 р для вирішення проблем в незалежних і неконкурентних розподілених системах для забезпечення захищеного зв'язку. Похідна від Web Sphere Message Queue була створена Енді Стенфордом-Кларком і Арлен Ніппер в IBM в 1999 р для вирішення конкретних проблем, пов'язаних з підключенням віддалених нафто- і газопроводів через супутниковий зв'язок. Цей протокол став відомий як MQTT.

При розгляді протоколу найкраще користуватися стандартним сайтом (www.mqtt.org), згідно якого: «MQTT- це MQ Telemetry Transport, який є простим і легким протоколом обміну повідомленнями, призначений для обмежених пристроїв і мереж з низькою пропускною здатністю, з високою затримкою або ненадійністю. Розроблено на принципах мінімізації пропускної здатності мережі та вимог до ресурсів пристроїв, намагаючись в той же час забезпечити надійність і деяку ступінь впевненості в доставці. Ці принципи також роблять цей протокол ідеальним для появи світу підключених пристроїв типу «машина-машина» (M2M) або «Інтернет речей», а також для мобільних додатків, де вкрай важливі пропускна здатність і заряд батареї ».

MQTT був внутрішнім і пропрієтарним протоколом для IBM протягом багатьох років, поки не був випущений у версії 3.1 в 2010 р в якості безкоштовного продукту. У 2013 р MQTT був стандартизований і прийнятий в консорціум OASIS. У 2014 р OASIS опублікував його публічно як версію MQTT 3.1.1. MQTT також є стандартом ISO (ISO / IECPRF 20922). MQTT базується на стеці TCP/IP.

3. Основні принципи взаємодії MQTT

У той час як архітектури клієнт-сервер багато років є основою для сервісів центрів обробки, моделі публікація-підписка (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 Кб. З іншого боку, опубліковане повідомлення може включати корисне навантаження нульової довжини. Поле корисного навантаження не є обов'язковим. Доцільно звірити відповідність розмірів корисного навантаження з вашим хмарним провайдером. Недотримання цієї вимоги призведе до помилок і відмови у доступі до хмарного брокера.

4. Деталі архітектури MQTT

MQTT може зберігати повідомлення в брокері необмежено довго. Цей режим роботи керується прапорцем. Збережене на брокері повідомлення відправляється будь-якому клієнту, який підписується на цю тематичну гілку MQTT. Повідомлення негайно відправляється цьому новому клієнту. Це дозволяє йому отримати статус або сигнал з теми, на яку він недавно підписався, без очікування. Як правило, клієнт, що підписується на тему, може очікувати годину або навіть дні, перш ніж інший клієнт-видавець опублікує нові дані.

MQTT означує додатковий об'єкт під назвою Остання воля і заповіт (LWT). LWT - це повідомлення, яке вказує клієнт під час етапу підключення. LWT містить тему «Остання воля», QoS і фактичне повідомлення. Якщо клієнт неправильно відключається від брокерського з'єднання (наприклад, тайм-аут keep-alive, помилка введення-виведення або клієнт закриває сеанс без відключення), тоді брокер зобов'язаний транслювати повідомлення LWT всім іншим підписаним на цю тему клієнтам.

Незважаючи на те, що MQTT заснований на TCP, з'єднання все ще можуть обриватися, особливо в разі бездротових датчиків. Пристрій може втратити живленя, зв'язок, або може бути просто польова поломка, і сеанс перейде в напіввідкритий стан (тобто з одного боку вважається що з’єднання є, а з іншого воно відсутнє). Тоді сервер буде вважати, що з'єднання як і раніше є надійним і очікувати дані. Щоб вийти з цього напіввідкритого стану, MQTT використовує систему keep-alive (утримування). Використовуючи цю систему, як брокер MQTT, так і клієнт мають гарантію того, що з'єднання залишається працездатним, навіть якщо протягом деякого часу не було передачі. Після отримання чергового будь-якого пакету, таймери keep-alive скидаються на клієнті і сервері і починають відлік. Якщо протягом часу keep-alive клієнти не мають даних для відправки, вони повинні сформувати відправити пакет PINGREQ брокеру, який, в свою чергу, підтверджує повідомлення за допомогою PINGRESP. Якщо протягом півтора часу keep-alive пакет не буде отримано, брокер закриє з’єднання і відправить LWT-пакет всім клієнтам. Максимальний час  keep-alive – 18 годин 12 хвилин 15 секунд.

MQTT дозволяє також підтримувати постійні з’єднання. Постійні з’єднання зберігає на стороні брокера наступне:

• всі підписки клієнта
• всі повідомлення QoS, які не були підтверджені клієнтом
• всі нові повідомлення QoS, пропущені клієнтом 

Параметр client_id посилається на цю інформацію для унікальної ідентифікації клієнтів. Клієнт може запитувати постійне з'єднання, проте брокер може відхилити запит і примусово перезапустити новий сеанс. При з'єднанні брокером використовується прапорець cleanSession для дозволу або заборони постійних з'єднань. Клієнт може визначити, чи збереглося постійне з'єднання за допомогою повідомлення CONNACK.

Постійні сеанси повинні використовуватися для клієнтів, які повинні отримувати всі повідомлення, навіть коли немає зв'язку. Вони не повинні використовуватися в ситуаціях, коли клієнт тільки публікує (записує) дані в теми.

5. Рівні якості обслуговування MQTT

У MQTT є три рівня якості обслуговування:

• QoS-0 (незавірена передача) - це мінімальний рівень QoS. Це аналогічно моделі «спалити і забути», докладно описаної в деяких бездротових протоколах. Це найефективніший процес доставки без підтвердження одержувачем повідомлення і без повторної передачі повідомлення відправником;
• QoS-1 (гарантована передача) - цей режим гарантує доставку повідомлення хоча б один раз одержувачу. Повідомлення може бути доставлено кілька разів, і одержувач відправить назад підтвердження з відповіддю PUBACK;
• QoS-2 (гарантований сервіс для додатків) - це найвищий рівень QoS, який переконується в доставці і інформує відправника і одержувача, що повідомлення було передано правильно. Цей режим генерує більше трафіку через багатокрокове рукостискання між відправником і отримувачем. Якщо одержувач отримує повідомлення з рівнем обслуговування QoS-2, він відповість відправнику повідомленням PUBREC. Це підтверджує повідомлення, і відправник відповість повідомленням PUBREL. PUBREL дозволяє одержувачеві безпечно відкинути будь-які повторні передачі цього повідомлення. Потім PUBREL підтверджується одержувачем за допомогою PUBCOMP. Поки повідомлення PUBCOMP передано не буде, приймач буде кешувати вихідне повідомлення для забезпечення безпеки.

QoS в MQTT визначається і контролюється відправником, і у кожного відправника може бути своя політика.

Типові випадки використання:

• QoS-0 слід використовувати, коли повідомлення не потрібно зберігати в черзі. QoS-0 найкраще підходить для провідного підключення або коли система сильно обмежена в пропускної здатності;
• Qos-1 слід використовувати за замовчуванням. QoS1 набагато швидше, ніж QoS2, і значно знижує вартість передачі;
• QoS-2 - для критично важливих застосунків. Крім того, для випадків, коли повторна передача дубльованого повідомлення може привести до помилок.

6. Обмін повідомленнями в MQTT

Нижче наведені процедури та повідомлення, що використовуються в MQTT. 

6.1. Процедура з’єднання

https://www.hivemq.com/blog/mqtt-essentials-part-3-client-broker-connection-establishment/

З'єднання з використанням MQTT починається з того, що клієнт відправляє повідомлення CONNECT брокеру. Тільки клієнт може ініціювати сеанс, і жоден клієнт не може безпосередньо зв'язатися з іншим клієнтом. У відповідь на повідомлення CONNECT брокер завжди буде відсилати CONNACK і код статусу. Після встановлення з'єднання, воно починає працювати.

У табл.1 наведені дані для з’єднання п процедурі CONNECT MQTT.

При відповіді CONNACK, сервер (брокер) буде повертати код відповіді, які наведені в таблиці 2.

6.2. Публікація повідомлення

Клієнт MQTT може публікувати повідомлення, як тільки він підключається до брокера. MQTT використовує фільтрування повідомлень на брокері на основі тем. Кожне повідомлення має містити тему, яку брокер може використовувати для пересилання повідомлення зацікавленим клієнтам. Як правило, кожне повідомлення має корисну інформацію, яка містить дані для передачі у форматі байтів MQTT.

Клієнт, що публікує дані (видавець) вирішує, чи хоче він відправити двійкові, текстові дані або навіть повноцінні XML або JSON. Повідомлення публікації (PUBLISH) у MQTT має кілька атрибутів, які вказані в таблиці 3:

Коли клієнт надсилає повідомлення до MQTT брокера для публікації, брокер читає повідомлення, підтверджує його (відповідно до рівня QoS) і обробляє. Обробка брокером включає в себе визначення того, які клієнти підписалися на тему та надсилання їм повідомлення.

Клієнт, який спочатку публікує повідомлення, турбується тільки про доставку повідомлення PUBLISH брокеру. Як тільки брокер отримує повідомлення PUBLISH, він зобов'язаний доставити його всім абонентам. Видавець не отримує жодних відгуків щодо того, хто цікавиться опублікованим повідомленням, чи скільки клієнтів отримали повідомлення від брокера.

6.3. Підписка на повідомлення

Щоб отримувати повідомлення на потрібні теми, клієнт надсилає до брокера MQTT повідомлення SUBSCRIBE. Це повідомлення містить унікальний ідентифікатор пакета та список підписок на теми (перелік topicID).

Повідомлення SUBSCRIBE може містити кілька підписок для абонента. Кожна підписка складається з теми та рівня QoS. Тема в повідомленні підписки може містити підстановки, які дозволяють підписатися на теми за вказаним шаблоном, а не на одну конкретну тему. Якщо для одного клієнта існує паралельне підключення, брокер доставляє повідомлення, яке має найвищий рівень QoS для цієї теми.

Для підписки на декілька тем в одному повідомленні можуть використовуватися знаки підстановки. Детальніше про це читайте в наступному пункті.

Щоб підтвердити кожну підписку, брокер надсилає Клієнту повідомлення про підтвердження SUBAK. Це повідомлення містить ідентифікатор пакета оригінального повідомлення SUBSCRIBE (щоб чітко ідентифікувати повідомлення) та список кодів повернення.

• 0 -    Успішно, Maximum QoS 0
• 1 -    Успішно, Maximum QoS 1
• 2 -    Успішно, Maximum QoS 2
• 128 - Відмова

Для відписки від теми використовується пакет Unsubscribe

7. Теми повідомлень та використання шаблонів MQTT

https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/

Теми повідомлень (Topic)

У MQTT слово «тема» («topic») відноситься до рядка UTF-8, який брокер використовує для фільтрування повідомлень для кожного зв'язаного клієнта. Тема складається з одного або декількох рівнів. Кожен рівень теми розділений косою рискою  (роздільник рівня теми).

Клієнтові не потрібно створювати потрібну тему, перш ніж її публікувати або підписатися на неї. Брокер приймає кожну дійсну тему без попередньої ініціалізації.

Приклад теми:

Зверніть увагу, що кожна тема повинна містити щонайменше 1 символ і що рядок теми може мати пробіли. Теми є чутливими до регістру.

Коли клієнт підписується на тему, він може підписатися на конкретну тему опублікованого повідомлення, або використовувати шаблони для підписки на кілька тем одночасно. Шаблони (Wildcards) можуть використовуватися лише для підписки на теми, а не для публікації повідомлення. Існує два різних типи шаблонів: single-level(однорівневий) та multi-level(багаторівневий).

7.1. Single Level: +

Як випливає з назви, однорівневий шаблон замінює один рівень теми. Символ «+» є однорівневий символ у темі.

Будь-яка тема відповідає темі з однорівневим шаблоном, якщо вона містить довільний рядок замість символу підстановки («+») в шаблоні. Наприклад, підписка на

myhome/groundfloor/+/temperature

може дати наступні результати:

7.2. Multi Level: #

Багаторівневий шаблон охоплює багато рівнів тем і позначається символом «#». Для того, щоб брокер визначив, які теми співпадають, багаторівневий підзаголовок слід розміщувати як останній символ у темі, перед яким передує коса риска.

Коли клієнт підписується на тему з багаторівневим шаблоном, він отримує всі повідомлення тем, які починаються з шаблону перед символом підстановки, незалежно від того, яка довга назва цієї теми. Якщо ви вказали лише багаторівневий шаблон як тему (#), ви отримуєте всі повідомлення, які надсилаються брокеру MQTT.

7.3. Спеціальні теми: $

Як правило, клієнти можуть публікувати теми MQTT з будь якими назвами, за виключенням тих, що починаються з символу «$». Такі теми зарезервовані для внутрішньої статистики брокера MQTT, тому клієнти не можуть публікувати повідомлення з такими назвами тем. Наразі немає офіційної стандартизації на використання тем з «$». Зазвичай, використовується теми з «$SYS», але реалізація брокерів змінюється. Для прикладів нижче за тему вибрано повний шлях: