Главная
|
История записей
Поиск:
Можно читать на разных языках:
####  2021-04-12
Что такое MQTT и для чего он нужен в IIoT? Описание протокола MQTT
>С развитием промышленности увеличивается количество устройств, которые нужно контролировать и получать от них различные данные. Для решения проблем взаимодействия большого количества устройств и проблем объединения устройств в одну сеть была создана концепция Интернета вещей (англ. Internet of Things, IoT) – это когда устройства объединяются по какому-то признаку в одну сеть, потом уже несколько подобных сетей объединяются в другую большую сеть и так далее. Устройства в таких сетях взаимодействуют друг с другом по средствам различных интерфейсов и протоколов передачи данных. Так как мы говорим о промышленном применении концепции IoT, в которой должны использоваться промышленное оборудование со своими протоколами и аппаратными средствами, то мы переходим к концепции IIoT (Промышленного Интернета вещей). Для взаимодействия между собой устройства используют различные промышленные протоколы, одним из популярных протоколов для этой цели является MQTT. ### Что такое MQTT? MQTT или Message Queue Telemetry Transport – это легкий, компактный и открытый протокол обмена данными созданный для передачи данных на удалённых локациях, где требуется небольшой размер кода и есть ограничения по пропускной способности канала. Вышеперечисленные достоинства позволяют применять его в системах M2M (Машинно-Машинное взаимодействие) и IIoT (Промышленный Интернет вещей). Также существует версия протокола MQTT-SN (MQTT for Sensor Networks), ранее известная как MQTT-S, которая предназначена для встраиваемых беспроводных устройств без поддержки TCP/IP сетей, например, Zigbee. ### Особенности протокола MQTT Основные особенности протокола MQTT: - Асинхронный протокол - Компактные сообщения - Работа в условиях нестабильной связи на линии передачи данных - Поддержка нескольких уровней качества обслуживания (QoS) - Легкая интеграция новых устройств Протокол MQTT работает на прикладном уровне поверх TCP/IP и использует по умолчанию 1883 порт (8883 при подключении через SSL). Обмен сообщениями в протоколе MQTT осуществляется между клиентом (client), который может быть издателем или подписчиком (publisher/subscriber) сообщений, и брокером (broker) сообщений (например, Mosquitto MQTT). Издатель отправляет данные на MQTT брокер, указывая в сообщении определенную тему, топик (topic). Подписчики могут получать разные данные от множества издателей в зависимости от подписки на соответствующие топики. Устройства MQTT используют определенные типы сообщений для взаимодействия с брокером, ниже представлены основные: Connect – установить соединение с брокером Disconnect – разорвать соединение с брокером Publish – опубликовать данные в топик на брокере Subscribe – подписаться на топик на брокере Unsubscribe – отписаться от топика Схема простого взаимодействия между подписчиком, издателем и брокером ### Семантика топиков Топики представляют собой символы с кодировкой UTF-8. Иерархическая структура топиков имеет формат «дерева», что упрощает их организацию и доступ к данным. Топики состоят из одного или нескольких уровней, которые разделены между собой символом «/». Пример топика в который датчик температуры, расположенный в спальной комнате публикует данные брокеру: /home/living-space/living-room1/temperature Подписчик может так же получать данные сразу с нескольких топиков, для этого существуют wildcard. Они бывают двух типов: одноуровневые и многоуровневые. Для более простого понимания рассмотрим в примерах каждый из них: Одноуровневый wildcard. Для его использования применяется символ «+» К примеру, нам необходимо получить данные о температуры во всех спальных комнатах: /home/living-space/+/temperature В результате получаем данные с топиков: /home/living-space/living-room1/temperature /home/living-space/living-room2/temperature /home/living-space/living-room3/temperature Многоуровневый wildcard. Для его использования применяется символ «#» К примеру, чтобы получить данные с различных датчиков всех спален в доме: /home/living-space/# В результате получаем данные с топиков: /home/living-space/living-room1/temperature /home/living-space/living-room1/light1 /home/living-space/living-room1/light2 /home/living-space/living-room1/humidity /home/living-space/living-room2/temperature /home/living-space/living-room2/light1 ### Структура сообщений MQTT сообщение состоит из нескольких частей: Фиксированный заголовок (присутствует по всех сообщениях) Переменный заголовок (присутствует только в определенных сообщениях) Данные, «нагрузка» (присутствует только в определенных сообщениях) ### Фиксированный заголовок Message Type – это тип сообщения, например: CONNECT, SUBSCRIBE, PUBLISH и другие. Flags specific to each MQTT packet – эти 4 бита отведены под вспомогательные флаги, наличие и состояние которых зависит от типа сообщения. Remaining Length – представляет длину текущего сообщения(переменный заголовок + данные), может занимать от 1 до 4 байта. Всего в протоколе MQTT существует 15 типов сообщений: | Тип сообщения | Значение | Направление передачи | Описание | |--------------- |----------- |---------------------- |----------------------------------------- | | Reserved | 0000 (0) | нет | Зарезервирован | | CONNECT | 0001 (1) | К* -> С** | Запрос клиента на подключение к серверу | | CONNACK | 0010 (2) | К <- С | Подтверждение успешного подключения | | PUBLISH | 0011 (3) | К <- С, К -> С | Публикация сообщения | | PUBACK | 0100 (4) | К <- С, К -> С | Подтверждение публикации | | PUBREC | 0101 (5) | К <- С, К -> С | Публикация получена | | PUBREL | 0110 (6) | К <- С, К -> С | Разрешение на удаление сообщения | | PUBCOMP | 0111 (7) | К <- С, К -> С | Публикация завершена | | SUBSCRIBE | 1000 (8) | К -> С | Запрос на подписку | | SUBACK | 1001 (9) | К <- С | Запрос на подписку принят | | UNSUBSCRIBE | 1010 (10) | К -> С | Запрос на отписку | | UNSUBACK | 1011 (11) | К <- С | Запрос на отписку принят | | PINGREQ | 1100 (12) | К -> С | PING запрос | | PINGRESP | 1101 (13) | К <- С | PING ответ | | DISCONNECT | 1110 (14) | К -> С | Сообщение об отключении от сервера | | Reserved | 1111 (15) | | Зарезервирован | *К – клиент, **С – сервер ### Флаги Четыре старших бита первого байта фиксированного заголовка отведены под специальные флаги: Протокол MQTT - флаги DUP – флаг дубликата устанавливается, когда клиент или MQTT брокер совершает повторную отправку пакета (используется в типах PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PUBREL). При установленном флаге переменный заголовок должен содержать Message ID (идентификатор сообщения) QoS – качество обслуживания (0,1,2) RETAIN – при публикации данных с установленным флагом retain, брокер сохранит его. При следующей подписке на этот топик брокер незамедлительно отправит сообщение с этим флагом. Используется только в сообщениях с типом PUBLISH. Переменный заголовок Переменный заголовок содержится в некоторых заголовках. В нём помещаются следующие данные: Packet identifier – идентификатор пакета, присутствует во всех типах сообщений, кроме: CONNECT, CONNACK, PUBLISH(с QoS <1), PINGREQ, PINGRESP, DISCONNECT Protocol name – название протокола (только в сообщениях типа CONNECT) Protocol version – версия протокола (только в сообщениях типа CONNECT) Connect flags – флаги указывающие на поведение клиента при подключении Сообщение MQTT - переменный заголовок User name – при наличии этого флага в «нагрузке» должно быть указано имя пользователя (используется для аутентификации клиента) Password – при наличии этого флага в «нагрузке» должен быть указан пароль (используется для аутентификации клиента) Will Retain – при установке в 1, брокер хранит у себя Will Message. Will QoS– качество обслуживания для Will Message, при установленном флаге Will Flag, Will QoS и Will retain являются обязательными. Will Flag - при установленном флаге, после того, как клиент отключится от брокера без отправки команды DISCONNECT(в случаях непредсказуемого обрыва связи и т.д.), брокер оповестит об этом всех подключенных к нему клиентов через так называемый Will Message. Clean Session – очистить сессию. При установленном «0» брокер сохранит сессию, все подписки клиента, а так же передаст ему все сообщения с QoS1 и QoS2, которые были получены брокером во время отключения клиента, при его следующем подключении. Соответственно при установленной «1», при повторном подключении клиенту будет необходимо заново подписываться на топики. Session Present – применяется в сообщении с типом CONNACK. Если брокер принимает подключение с Clean Session = 1 он должен установить «0» в бит Session Present(SP). Если брокер принимает подключение с Clean Session = 0, то значение бита SP зависит от того, сохранял ли брокер ранее сессию с этим клиентом (если так, то в SP выставляется 1 и наоборот). То есть этот параметр позволяет клиенту определить была ли сохранена брокером предыдущая сессия. Connect Return code – если брокер по каким то причинам не может принять правильно сформированный CONNECT пакет от клиента, то во втором байте CONNACK пакета он должен установить соответствующее значение из нижеуказанного списка: | Тип сообщения | Значение | Направление передачи | Описание | |--------------- |----------- |---------------------- |----------------------------------------- | | Reserved | 0000 (0) | нет | Зарезервирован | | CONNECT | 0001 (1) | К* -> С** | Запрос клиента на подключение к серверу | | CONNACK | 0010 (2) | К <- С | Подтверждение успешного подключения | | PUBLISH | 0011 (3) | К <- С, К -> С | Публикация сообщения | | PUBACK | 0100 (4) | К <- С, К -> С | Подтверждение публикации | | PUBREC | 0101 (5) | К <- С, К -> С | Публикация получена | | PUBREL | 0110 (6) | К <- С, К -> С | Разрешение на удаление сообщения | | PUBCOMP | 0111 (7) | К <- С, К -> С | Публикация завершена | | SUBSCRIBE | 1000 (8) | К -> С | Запрос на подписку | | SUBACK | 1001 (9) | К <- С | Запрос на подписку принят | | UNSUBSCRIBE | 1010 (10) | К -> С | Запрос на отписку | | UNSUBACK | 1011 (11) | К <- С | Запрос на отписку принят | | PINGREQ | 1100 (12) | К -> С | PING запрос | | PINGRESP | 1101 (13) | К <- С | PING ответ | | DISCONNECT | 1110 (14) | К -> С | Сообщение об отключении от сервера | | Reserved | 1111 (15) | | Зарезервирован | Topic Name – название топика Данные, нагрузка Содержание и формат данных, передаваемых в MQTT сообщениях, определяются в приложении. Размер данных может быть вычислен путём вычитания из Remaining Length длины переменного заголовка. ### Качество обслуживания в протоколе MQTT (QoS) MQTT поддерживает три уровня качества обслуживания (QoS) при передаче сообщений. QoS 0 At most once. На этом уровне издатель один раз отправляет сообщение брокеру и не ждет подтверждения от него, то есть отправил и забыл. QoS 0 At most once QoS 1 At least once. Этот уровень гарантирует, что сообщение точно будет доставлено брокеру, но есть вероятность дублирования сообщений от издателя. После получения дубликата сообщения, брокер снова рассылает это сообщение подписчикам, а издателю снова отправляет подтверждение о получении сообщения. Если издатель не получил PUBACK сообщения от брокера, он повторно отправляет этот пакет, при этом в DUP устанавливается «1». QoS 1 At least once QoS 2 Exactly once. На этом уровне гарантируется доставка сообщений подписчику и исключается возможное дублирование отправленных сообщений. QoS 2 Exactly once Издатель отправляет сообщение брокеру. В этом сообщении указывается уникальный Packet ID, QoS=2 и DUP=0. Издатель хранит сообщение неподтвержденным пока не получит от брокера ответ PUBREC. Брокер отвечает сообщением PUBREC в котором содержится тот же Packet ID. После его получения издатель отправляет PUBREL с тем же Packet ID. До того, как брокер получит PUBREL он должен хранить копию сообщения у себя. После получения PUBREL он удаляет копию сообщения и отправляет издателю сообщение PUBCOMP о том, что транзакция завершена. ### Защита передачи данных Для обеспечения безопасности в MQTT протоколе реализованы следующие методы защиты: Аутентификация клиентов. Пакет CONNECT может содержать в себе поля USERNAME и PASSWORD. При реализации брокера можно использовать эти поля для аутентификации клиента Контроль доступа клиентов через Client ID Подключение к брокеру через TLS/SSL ### Оборудование для IIoT с поддержкой MQTT Для построения систем промышленного интернета вещей, а также интегрирования существующего оборудования в облачные системы используются специальные устройства. ### Оборудование для IIoT с поддержкой MQTT Web-программируемые IIoT контроллеры IIoT модули удаленного ввода/вывода Шлюзы IIoT IIoT платформы, сервера MQTT Измерители CO, CO2, температуры и влажности ------------
Назад на сайт
Лента
Телефон
Почта
В закладки
Распечатать
