Что такое MQTT и как его могут использовать компании промышленной автоматизации?

Если вы вообще занимаетесь промышленным Интернетом вещей (IIoT), вы обязательно увидите новую аббревиатуру, используемую повсюду:MQTT. Хотя MQTT является относительно новым для автоматизации, он существует уже более 20 лет. Первоначально он был разработан как протокол для получения данных с удаленных нефтяных месторождений, но до недавнего времени не получил широкого распространения за пределами этого нишевого приложения. В настоящее время он становится одним из основных протоколов для проектов цифровой трансформации производства.

Что такое MQTT?

MQTT расшифровывается как Message Queuing Telemetry Transport. Это клиент-серверный транспортный протокол обмена сообщениями для публикации/подписки, который считается упрощенным протоколом обмена сообщениями для отправки небольших пакетов информации в приложениях с ограниченной пропускной способностью. По своей сути он считается стандартом OASIS, лежащим в основе подключения к Интернету вещей.

История

В конце 1990-х возникла потребность в облегченном протоколе связи, который мог бы передавать данные с удаленных нефтяных месторождений с чрезвычайно низкой скоростью соединения, возможно, всего 300 бод. Стратегия заключалась в том, чтобы воспользоваться возможностями, уже предлагаемыми на транспортном уровне, который использует протокол TCP. Предлагаемый прикладной протокол устранит любую избыточность, которая добавляется к полезной нагрузке передачи. Он также должен был сохранять состояние и сообщать только об исключениях. Помня об этих ограничениях, Phillips 66 работал с Арленом Ниппером из Cirrus Link Solutions и Энди Стэнфорд-Кларком из IBM, чтобы разработать то, что сейчас известно как протокол MQTT.

Раннее коммерческое использование

Хотя в начале 2000-х к компаниям, занимающимся автоматизацией, обращались с протоколом MQTT, единственным другим коммерческим использованием его были приложения Facebook Messenger и Apple Messages. Основная интересующая особенность заключается в том, что протокол обеспечивает состояние и качество данных. Когда отправитель печатал, получатель видел на экране теперь уже слишком знакомые три точки. Он также использовался в некоторых приложениях для домашнего мониторинга и данных о погоде, но на тот момент использование MQTT было довольно ограниченным.

Внедрение автоматизации

В середине 2010-х Арлен Ниппер снова обратился к компаниям по автоматизации с просьбой продвигать использование MQTT. Возникла потребность в агрегировании дополнительных производственных данных без значительного сетевого спроса. Однако были некоторые дополнительные возможности, которые необходимо было разработать, чтобы получить признание в производстве. Cirrus Link Solutions вместе с Inductive Automation продолжили разработку того, что сейчас является стандартом Sparkplug, который включает атрибуты, необходимые для автоматизации, а именно определенный набор тем, стандартную полезную нагрузку и сжатие сообщений.

Обзор структуры

MQTT использует структуру, похожую на структуру папок компьютера. В качестве примера я буду использовать рабочий стол Windows. На рабочем столе есть папка Мои документы. В «Моих документах» есть еще одна папка «Семья», и в этой папке есть папка для каждого члена семьи. Путь к моей папке будет «Рабочий стол/Мои документы/Семья/Дэвид». Я бы сохранил (опубликовал) все свои документы Дэвиду. Любой, кто хотел прочитать мои документы, открывал (подписывался) на Дэвида.

Устройства, использующие протокол MQTT, будут публиковать и подписываться на аналогичный путь раздела, называемый пространством имен. Подобно компьютеру, он организован от наиболее общего к наиболее частному. Чем выше уровень, на который я подписываюсь, тем больше данных я получу. Существуют также подстановочные знаки, которые можно использовать для определения пути темы. Звездочка (*) включает все, начиная с текущего уровня и ниже. Плюс (+) перемещает путь на один уровень ниже. Я включил несколько примеров далее в статью.

Соответствие стандартам ISA

Стандарт ISA-95 хорошо известен в производстве. Он описывает стандартную модель и терминологию интерфейса между предприятием и системами управления. Хотя обычно он реализуется как иерархия, начиная с ERP наверху и устройств внизу, стандарт в основном касается производственных данных и того, как они должны быть структурированы. Поскольку MQTT использует пространство имен тем, их можно легко привести в соответствие с иерархией ISA-95. При построении пространства имен темы рекомендуется указывать Enterprise, Site, Area, Line и Cell. Корневая папка издателя/подписчика также должна существовать на должном уровне. Например, ПЛК, управляющий ячейкой, должен публиковать свои данные в разделе Предприятие/Площадка/Область/Линия/Ячейка. Если архиватор процессов предназначен для определенной области, он должен подписывать все данные на уровне предприятия/сайта/области.

Архитектура

Один из распространенных вопросов, возникающих при использовании MQTT, заключается в том, что происходит при потере подключения. Есть несколько вариантов, которые можно использовать для смягчения этих ситуаций. Распространенным решением является использование метода «с промежуточным хранением». Например, системы SCADA, находящиеся на уровне управления, будут продолжать собирать данные до тех пор, пока не будет возобновлено соединение с брокером MQTT. Следует отметить, что при возобновлении соединения с брокером временные метки всех сохраненных данных остаются нетронутыми.

MQTT также поддерживает использование брокеров резервного копирования. Пока есть основной брокер, если это соединение потеряно, подключенные узлы автоматически переключатся на другого брокера. Связь обычно настраивается через приложение (например, систему SCADA), которое поддерживает эту функцию.

Другое решение достигается за счет использования кластеризации. Это типично для приложений, которые не могут допустить потери данных. Обычная установка состоит в том, чтобы несколько брокеров MQTT были объединены в кластер. Все эти брокеры знают друг о друге и будут обмениваться сообщениями внутри кластера. При потере связи издатели и подписчики данных будут беспрепятственно перенаправлять данные другому брокеру без каких-либо потерь.

Обычно корпоративное приложение использует данные со всех своих заводов. Для этого сценария MQTT поддерживает использование моста, аналогичного системе промежуточного хранения. В этой архитектуре один брокер будет публиковать или соединять часть или все пространство имен с другим брокером. Иными словами, заводской брокер будет соединяться с корпоративным брокером. Можно определить как опубликованные темы, так и структуру пространства имен. Это одновременно ограничивает объем публикуемых данных и обеспечивает контекст для принимающего брокера.

Опубликовать все данные как есть со звездочкой (*) и не определять какую-либо структуру — это самый простой способ, но это может привести к большому количеству ненужных и потенциально запутанных данных. Чтобы обеспечить некоторый контекст данных, тема может быть добавлена ​​в начало пространства имен опубликованной темы. Например, Enterprise/Site можно добавить в пространство имен plant Area/+/Cell, что приведет к отправке Enterprise/Site/Area/+/Cell брокеру Enterprise. В результате из этой системы будут доступны данные уровня соты для всех линий (обратите внимание на использование подстановочного знака +).

Все эти сценарии могут быть развернуты. Система SCADA может использовать промежуточное хранение в кластере MQTT. Могут быть первичные и резервные кластеры, но это, вероятно, добавит ненужной сложности. Наконец, кластер завода может соединяться с кластером предприятия, чтобы максимизировать целостность данных. Это отлично подходит для корпоративной аналитики и машинного обучения, так как для этого требуется значительный объем данных хорошего качества.

Безопасность

Одной из основных проблем, связанных с отправкой и получением производственных данных через Интернет, является кибербезопасность. Хотя единственный способ по-настоящему обезопасить себя — использовать воздушный зазор, это помешает организации осуществить цифровую трансформацию. Одним из ключевых преимуществ MQTT является безопасность. В то время как другие протоколы связи требуют открытия сетевых портов, для MQTT требуется только исходящее соединение с брокером. Заводам не требуется открывать какие-либо входящие порты, что очень привлекательно для ИТ-организаций.

Соображения на будущее

В будущих статьях я рассмотрю распространенные приложения с MQTT. Хотя протокол предназначен для работы по принципу plug-and-play, вероятно, будут интересны дополнительные технические детали. Бизнес-лидеры могут подумать, как MQTT повлияет на их текущие усилия по цифровой трансформации. И, конечно же, инженеры-руководители обязательно захотят узнать, как MQTT повлияет на них.

В заключение, MQTT не следует рассматривать как замену существующей архитектуре. В соответствии с требованиями Индустрии 4.0 он использует то, что уже есть. Сохранится потребность в OPC UA и других протоколах, поскольку они более многословны для управляющих приложений. Однако, когда дело доходит до агрегирования значительных объемов данных, MQTT является отличным выбором.