MQTT в производството: Защо IoT протоколът превзе производствения цех

Основни изводи

• MQTT е лек pub/sub протокол за обмен на съобщения. Първоначално създаден за телеметрия с ниска пропускателна способност, сега е навсякъде в производството.
• Той разгражда зависимостта между публикуващите (PLC-та, сензори, машини) и абонатите (OEE платформи, облак, аналитика) чрез брокер.
• Стандартният модел в модерните цехове е Sparkplug B — спецификация върху MQTT, която добавя моделиране на данни, съобщения за включване/изключване и проследяване на състоянието.
• MQTT мащабира до хиляди устройства с минимална пропускателна способност, затова граничните IIoT решения се съсредоточиха върху него.
• Той допълва OPC UA, не го заменя. Много стекове използват и двата.

Кратък отговор: MQTT е pub/sub протокол за съобщения, проектиран за IoT с ниска пропускателна способност, но възприет в мащаб в производството, защото разделя производителите на данни (машини) от консуматорите на данни (OEE платформи, облак, аналитика). Модерните индустриални внедрявания използват спецификацията Sparkplug B върху MQTT, за да добавят моделиране на данни и проследяване на състоянието, които суровият MQTT няма. MQTT и OPC UA решават припокриващи се проблеми; много стекове използват и двата. Вижте също OEE за пакетно производство.

Какво представлява MQTT

MQTT (Message Queuing Telemetry Transport) е publish/subscribe протокол за съобщения, изобретен през 1999 г. в IBM за телеметрия с ниска пропускателна способност в петролния и газовия сектор. Архитектурата е проста:

• Публикуващи изпращат съобщения към теми (именовани канали) на брокер.
• Абонати молят брокера за съобщения от теми, които ги интересуват.
• Брокер маршрутизира съобщенията от публикуващите към абонатите, без едната страна да познава другата.

Развързването е ключовата полза. PLC публикува състоянието си на тема; който се абонира, получава данните. PLC-то не знае и не се интересува кой е потребителят.

Защо MQTT завладя телекомуникациите в производството

Три причини:

• Ефективност на пропускателната способност. Малък overhead на съобщенията, постоянни връзки, минимален ръкостискане. Работи по мобилни и ограничени мрежи.
• Мащабируемост. Един брокер може да обработва хиляди устройства, публикуващи едновременно.
• Развързване. Добавяйте или премахвайте абонати без да пипате източниците на данни. Опитайте да направите това с point-to-point интеграции.

За OEE платформа, която консумира данни от над 50 машини в завод, MQTT е естествен избор. Един брокер, много публикуващи, много абонати.

Защо суровият MQTT не стига

Суровият MQTT няма мнение относно съдържанието на съобщенията. PLC, който публикува "423" в тема "line5/cycle", е добре докато два различни PLC-та използват различни конвенции за темите, единици или формати на съобщенията. Интеграцията става хаос.

Решението е Sparkplug B, отворена спецификация върху MQTT, която добавя:

• Стандартно пространство от имена за теми (group/edge node/device/metric).
• Съобщения за включване и изключване, така че абонатите да знаят кога дадено устройство се присъединява или напуска.
• Проследяване на състоянието и запазване на стойности (брокерът поддържа последната известна стойност).
• Силно типизиране на метриките (int, float, boolean, datetime).

Повечето модерни индустриални MQTT внедрявания използват Sparkplug B. Суровият MQTT работи за нови инсталации с строга дисциплина на темите, но рядко мащабира.

MQTT срещу OPC UA

Те се припокриват, но решават различни проблеми:

• MQTT е pub/sub, базиран на брокер, лек, идеален за много-към-много телеметрия в мащаб.
• OPC UA е клиент-сървър (с опционален pub/sub), point-to-point, структуриран, идеален за надежмен обмен на данни със силно типизиране и сигурност.

Много модерни стекове използват и двата: OPC UA за структуриран обмен на данни на линия (PLC към шлюз), MQTT/Sparkplug B за високомащабна телеметрия от шлюза към облака или централна OEE платформа.

Какво означава "унифицирано пространство от имена" и защо MQTT го улеснява

Унифицирано пространство от имена (UNS) е архитектурен модел, при който всяка система публикува в един споделен MQTT брокер. Брокерът става единствен източник на истината за всички реалновременни заводски данни. ERP, MES, OEE платформа, историзатор, аналитика — всички се абонират за темите, които им трябват, без point-to-point интеграции.

UNS заменя стриктната йерархия PLC → SCADA → MES → ERP с плоска pub/sub шина. Той е много подходящ за нови дигитални трансформации и за модернизация чрез "lift-and-shift" на заводи със стари SCADA системи.

Какво означава това за избора на OEE платформа

• Поддържа ли OEE платформата MQTT нативно?
• Поддържа ли Sparkplug B (а не само суров MQTT)?
• Може ли да работи на място срещу вече съществуващ брокер?
• Може ли да функционира като публикуващ (записвайки изчислени OEE стойности обратно), освен като абонат?

За малки и средни производители без съществуващ брокер, само OPC UA често е по-просто. За по-големи или многосайтови операции, MQTT + Sparkplug B обикновено печели по отношение на дългосрочната мащабируемост.

OEE модулът на Fabrico поддържа както OPC UA, така и MQTT/Sparkplug B като източници на данни и може да публикува обратно изчислени OEE метрики в MQTT за низходящи потребители.

Вижте как Fabrico улавя това автоматично — разгледайте OEE за производството или запазете демонстрация.

Свързано четиво

• OEE за пакетно производство
• Диаграма на Парето в производството
• KPI срещу OKR в производството
• Manufacturing Data Lake срещу Data Warehouse

Често задавани въпроси

Трябва ли да използвам MQTT или OPC UA за OEE?

За повечето малки и средни заводи OPC UA е достатъчен и по-прост. За многосайтови или стратегии с унифицирано пространство от имена, MQTT/Sparkplug B е по-добрата дългосрочна опция.

Какво е Sparkplug B?

Отворена спецификация върху MQTT, която добавя стандартно именуване на теми, съобщения за включване/изключване, проследяване на състоянието и типизирани метрики. Де факто стандартът за индустриален MQTT.

Трябва ли ми отделен брокер?

Да. MQTT е изграден около брокер. Често използвани варианти: HiveMQ, EMQX, Mosquitto (отворен код) или облачни брокери (AWS IoT, Azure IoT Hub).

MQTT сигурен ли е?

Да, с TLS криптиране и автентикация. Анонимен, нешифрован MQTT в продукция не е безопасен.

Как се сравнява MQTT с REST/HTTP за телеметрия?

MQTT е много по-ефективен за непрекъсната телеметрия. HTTP е подходящ за случайни API повиквания. За машинни данни, които текат на всеки няколко секунди от хиляди устройства, MQTT печели категорично.