MQTT в промышленной автоматизации: практическое руководство для производителей

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

Что такое MQTT?

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

История

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

Ранние коммерческие применения

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

Принятие в автоматизации

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

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

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

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

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

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

Архитектура

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

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

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

Часто корпоративное приложение использует данные со всех своих заводов. Для этого сценария MQTT поддерживает использование моста (bridging), похожего на систему store-and-forward. В этой архитектуре один брокер публикует или транслирует часть или всё свое пространство имен другому брокеру. Иными словами, заводской брокер транслирует данные корпоративному брокеру. И публикуемые топики, и структура пространства имен могут быть определены. Это и ограничивает объем публикуемых данных, и предоставляет контекст для принимающего брокера.

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

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

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

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

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

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

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