MQTT w przemyśle: dlaczego protokół IoT opanował halę produkcyjną

Kluczowe wnioski

• MQTT to lekki protokół komunikacyjny publish/subscribe. Początkowo stworzony do telemetrii o niskiej przepustowości, dziś powszechny w przemyśle.
• Oddziela nadawców (PLC, czujniki, maszyny) od subskrybentów (platformy OEE, chmura, analityka) za pośrednictwem brokera.
• Standardowym wzorcem w nowoczesnych zakładach jest Sparkplug B, specyfikacja MQTT, która dodaje modelowanie danych, komunikaty birth/death oraz śledzenie stanu.
• MQTT skaluje się do tysięcy urządzeń przy minimalnym zużyciu pasma, dlatego rozwiązania edge IIoT skupiły się na nim.
• Uzupełnia OPC UA, nie zastępuje go. Wiele stosów używa obu.

Krótka odpowiedź: MQTT to protokół publish/subscribe zaprojektowany dla IoT o niskiej przepustowości, ale przyjęty na szeroką skalę w przemyśle, ponieważ oddziela producentów danych (maszyny) od konsumentów danych (platformy OEE, chmura, analityka). Nowoczesne wdrożenia przemysłowe stosują specyfikację Sparkplug B na bazie MQTT, aby dodać modelowanie danych i śledzenie stanu, których surowe MQTT nie posiada.

MQTT i OPC UA rozwiązują pokrywające się problemy; wiele stosów używa obu. Zobacz także OEE dla produkcji wsadowej.

Czym jest MQTT

MQTT (Message Queuing Telemetry Transport) to protokół komunikacyjny publish/subscribe wynaleziony w 1999 roku w IBM do telemetrii w sektorze nafty i gazu przy niskiej przepustowości. Architektura jest prosta:

• Nadawcy (publishers) wysyłają wiadomości na tematy (nazwane kanały) do brokera.
• Subskrybenci zgłaszają brokerowi zapotrzebowanie na wiadomości z tematów, które ich interesują.
• Broker kieruje wiadomości od nadawców do subskrybentów bez konieczności wzajemnej znajomości.

Wartością jest rozdzielenie. PLC publikuje stan pracy na temat; każdy, kto subskrybuje, otrzymuje dane. PLC nie zna ani nie interesuje się, kto jest konsumentem.

Dlaczego MQTT przejął telemetrię w przemyśle

Trzy powody:

• Efektywność pasma. Niewielkie narzuty wiadomości, połączenia utrzymywane, minimalny handshake. Działa w sieciach komórkowych i ograniczonych.
• Skalowalność. Jeden broker może obsłużyć tysiące urządzeń publikujących jednocześnie.
• Rozdzielenie. Dodawaj lub usuwaj subskrybentów bez ingerencji w źródła danych. Spróbuj zrobić to za pomocą integracji punkt, punkt.

Dla platformy OEE konsumującej dane z ponad 50 maszyn w zakładzie, MQTT jest naturalnym wyborem. Jeden broker, wielu nadawców, wielu subskrybentów.

Dlaczego surowe MQTT nie wystarcza

Surowe MQTT nie narzuca formatu wiadomości. PLC publikujące "423" na temacie "line5/cycle" jest w porządku dopóki dwa różne PLC nie stosują różnych konwencji tematów, jednostek lub formatów wiadomości. Integracja staje się chaotyczna.

Rozwiązaniem jest Sparkplug B, otwarta specyfikacja oparta na MQTT, która dodaje:

• Standardową przestrzeń nazw tematów (group/edge node/device/metric).
• Komunikaty pojawienia się i zniknięcia (birth/death), dzięki którym subskrybenci wiedzą, kiedy urządzenie dołącza lub opuszcza sieć.
• Śledzenie stanu i utrzymywanie wartości (broker przechowuje ostatnio znaną wartość).
• Silne typowanie metryk (int, float, boolean, datetime).

Większość nowoczesnych przemysłowych wdrożeń MQTT używa Sparkplug B. Surowe MQTT sprawdza się w greenfield (projektach od podstaw) przy ścisłej dyscyplinie tematów, ale rzadko skaluje się dobrze.

MQTT vs OPC UA

Pokrywają się, ale rozwiązują różne problemy:

• MQTT to pub/sub z brokerem, lekki, idealny do telemetrii many-to-many na dużą skalę.
• OPC UA to klient‑serwer (z opcjonalnym pub/sub), punkt, punkt, strukturalny, idealny do niezawodnej wymiany danych z silnym typowaniem i zabezpieczeniami.

Wiele nowoczesnych stosów używa obu: OPC UA do strukturalnej wymiany danych na poziomie linii (PLC → bramka), MQTT/Sparkplug B do telemetrycznej komunikacji na dużą skalę od bramki do chmury lub centralnej platformy OEE.

Co oznacza „jednolita przestrzeń nazw” i dlaczego MQTT ją umożliwia

Jednolita przestrzeń nazw (UNS) to wzorzec architektoniczny, w którym każdy system publikuje do jednego wspólnego brokera MQTT. Broker staje się jednym źródłem prawdy dla wszystkich danych czasu rzeczywistego w zakładzie. ERP, MES, platforma OEE, historian, analityka, wszyscy subskrybują potrzebne tematy bez integracji punkt, punkt.

UNS zastępuje sztywną hierarchię PLC → SCADA → MES → ERP płaską magistralą pub/sub. Jest to dobre rozwiązanie dla projektów greenfield oraz modernizacji typu lift-and-shift zakładów z istniejącym SCADA.

Co to oznacza przy wyborze platformy OEE

• Czy platforma OEE natywnie obsługuje MQTT?
• Czy obsługuje Sparkplug B (nie tylko surowe MQTT)?
• Czy może działać lokalnie (on‑premises) z istniejącym brokerem?
• Czy może pełnić rolę wydawcy (publikować obliczone wartości OEE), oprócz roli subskrybenta?

Dla producentów z sektora MŚP bez istniejącego brokera, samo OPC UA bywa prostsze. Dla większych lub wielozakładowych operacji MQTT + Sparkplug B zwykle wygrywa pod względem długoterminowej skalowalności.

Moduł OEE Fabrico obsługuje zarówno OPC UA, jak i MQTT/Sparkplug B jako źródła danych i może publikować obliczone metryki OEE z powrotem do MQTT dla konsumentów downstream.

Zobacz, jak Fabrico robi to automatycznie, poznaj OEE dla produkcji lub zarezerwuj demo.

Polecane lektury

• OEE dla produkcji wsadowej
• Wykres Pareto w produkcji
• KPI vs OKR w produkcji
• Data Lake kontra Data Warehouse w produkcji

Najczęściej zadawane pytania

Czy powinienem używać MQTT czy OPC UA do OEE?

Dla większości zakładów MŚP OPC UA jest wystarczające i prostsze. Dla operacji wielozakładowych lub strategii jednolitej przestrzeni nazw lepszym długoterminowym wyborem jest MQTT/Sparkplug B.

Czym jest Sparkplug B?

Otwartą specyfikacją opartą na MQTT, która dodaje standardowe nazewnictwo tematów, komunikaty birth/death, śledzenie stanu i typowane metryki. De facto standard dla przemysłowego MQTT.

Czy potrzebuję oddzielnego brokera?

Tak. MQTT jest zbudowane wokół brokera. Popularne wybory: HiveMQ, EMQX, Mosquitto (open source) lub brokerzy chmurowi (AWS IoT, Azure IoT Hub).

Czy MQTT jest bezpieczny?

Tak, przy użyciu szyfrowania TLS i uwierzytelniania. Anonimowe, niezaszyfrowane MQTT w środowisku produkcyjnym nie jest bezpieczne.

Jak MQTT wypada w porównaniu z REST/HTTP dla telemetrii?

MQTT jest znacznie wydajniejsze dla ciągłej telemetrii. HTTP jest w porządku do sporadycznych wywołań API. Dla danych maszyn przesyłanych co kilka sekund z tysięcy urządzeń MQTT wygrywa zdecydowanie.