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 печели категорично.