MQTT vs OPC UA – który protokół wybrać do komunikacji w przemyśle?

Co to jest protokół MQTT?

MQTT to lekki protokół komunikacyjny do telemetrii, czujników i urządzeń pracujących w sieciach o ograniczonej przepustowości. Pełna nazwa MQTT to Message Queuing Telemetry Transport, a protokół MQTT działa na TCP/IP i wykorzystuje model publish subscribe do wymiany danych.

MQTT został zapoczątkowany w 1999 roku przez Andy’ego Stanforda-Clarka z IBM oraz Arlena Nippera z Eurotech. Protokół MQTT ogranicza narzut nagłówków, dlatego czujniki bateryjne zużywają mniej energii podczas wysyłania wiadomości.

System MQTT składa się z brokera, klientów, tematów oraz reguł subskrypcji. Broker MQTT zarządza przesyłaniem wiadomości między publisherami a subscriberami, a klient MQTT publikuje albo odbiera wiadomości przypisane do tematów.

QoS i tematy w MQTT

Jakość usług w MQTT ma trzy poziomy: QoS 0 oznacza at most once, QoS 1 oznacza at least once, a QoS 2 oznacza exactly once. QoS 2 podnosi niezawodność, lecz złożoność potwierdzeń zwiększa opóźnienia i obciążenie sieci.

Jak działa komunikacja MQTT – broker, publisher, subscriber

MQTT działa przez połączenie inicjowane przez klienta, więc komunikacja dwukierunkowa wymaga mniej reguł zapór ogniowych niż klasyczne połączenia przychodzące. Protokół MQTT przekazuje wiadomości w hierarchii tematów, co upraszcza wymianę danych między tysiącami punktów pomiarowych.

Publisher wysyła wiadomości do tematu, subscriber odbiera wiadomości z tematu, a broker utrzymuje mapę subskrypcji. Taka architektura odseparowuje nadawcę od odbiorcy i pozwala dodawać aplikacje bez modyfikacji sterowników PLC.

MQTT obsługuje Last Will and Testament, czyli wiadomości publikowane przez broker po utracie połączenia z urządzeniem. Retained Messages przechowują ostatni stan tematu, dlatego nowy subscriber otrzymuje aktualną wartość bez czekania na kolejny cykl pomiaru.

MQTT 5.0 – co nowego wprowadza najnowsza wersja protokołu?

MQTT 5.0 porządkuje obsługę błędów, sesji i skalowania odbiorców. MQTT 5.0 daje brokerowi kontrolę nad odrzucaniem wiadomości oraz nad czasem życia sesji i komunikatów.

Negative acknowledgements pozwalają brokerowi odrzucać określone wiadomości na podstawie limitów, uprawnień albo przeciążenia. Shared subscriptions rozdzielają wiadomości między wiele instancji aplikacji, co jest przydatne przy zapisie do baz danych.

Session expiry interval określa czas przechowywania sesji po rozłączeniu klienta. Message expiry interval usuwa przeterminowane wiadomości, dlatego aplikacje raportowe nie zapisują do baz danych danych starszych niż ustalone SLA.

Czy MQTT jest bezpieczny? Poziomy zabezpieczeń protokołu

MQTT nie jest bezpieczny bez konfiguracji, ponieważ standardowo przesyła dane tekstem jawnym. Bezpieczeństwo danych w MQTT wymaga TLS/SSL, uwierzytelniania oraz kontroli dostępu do tematów.

Poziom sieci obejmuje segmentację VLAN, VPN i listy ACL. Poziom transportu obejmuje szyfrowanie TLS/SSL, a poziom aplikacji obejmuje login, hasło, identyfikator klienta i reguły autoryzacji.

Protokół TLS/SSL chroni wiadomości przed odczytem podczas transmisji MQTT, ale MQTT wymaga stałego połączenia i pełnego stosu TLS. Szyfrowanie zwiększa użycie CPU, więc urządzenia brzegowe muszą mieć zapas pamięci i mocy obliczeniowej.

Darmowe i komercyjne brokery MQTT – przegląd

Darmowy broker MQTT istnieje, a najczęściej wybieranym przykładem jest Eclipse Mosquitto. Mosquitto jest open source, działa na Linuxie, Windowsie i Raspberry Pi, a protokół MQTT obsługuje bez opłat licencyjnych.

HiveMQ oferuje wersje komercyjne z klastrami, monitoringiem i integracją enterprise. EMQX zapewnia skalowanie horyzontalne oraz konektory do baz danych, a VerneMQ wspiera architektury rozproszone i wysoką liczbę połączeń.

W projektach pilotażowych broker MQTT na Raspberry Pi wystarcza do testów kilku tysięcy wiadomości na minutę. W produkcji broker MQTT powinien mieć redundancję, monitoring opóźnień, kontrolę certyfikatów i politykę retencji.

Co to jest OPC UA i co oznacza ten skrót?

OPC UA to standard komunikacji przemysłowej dla maszyn, sterowników PLC, systemów SCADA oraz aplikacji IT. OPC UA oznacza OPC Unified Architecture, gdzie OPC pochodzi od Open Platform Communications, a historycznie od Ole for Process Control.

OPC UA został opracowany przez OPC Foundation jako następca OPC Classic. OPC Foundation zarządza rozwojem standardu OPC, publikuje specyfikacje OPC UA Part 1-14 i utrzymuje zgodność implementacji. Interfejs OPC UA oznacza zestaw usług, przestrzeń adresową i zasady bezpiecznego dostępu do danych urządzeń.

OPC Unified Architecture, czyli opc unified architecture, odcina standardu OPC od technologii Windows COM/DCOM. Unified Architecture oznacza niezależność platformową, model usług, bezpieczeństwo oraz semantyczny opis danych procesowych.

Open Platform Communications opisuje współczesny kierunek rozwoju OPC, w którym standardu OPC używa się poza ekosystemem Windows. Ten kierunek wspiera przemysłu 4.0, ponieważ serwer OPC, klient OPC i aplikacje IT mogą pracować na różnych systemach operacyjnych.

OPC DA, OPC HDA i OPC A&E

OPC Classic obejmował OPC DA dla danych bieżących, OPC HDA dla danych historycznych oraz OPC A&E dla alarmów i zdarzeń. OPC DA działał dobrze w środowisku Windows, ale OPC Classic wymagał DCOM, co utrudniało segmentację sieci i zdalną administrację.

Architektura OPC UA – serwer OPC UA, klient OPC, model informacyjny

Serwer OPC UA udostępnia dane, metody, zdarzenia i strukturę obiektów, a klient OPC odczytuje albo zapisuje wartości przez usługi standardu OPC. Serwer OPC pełni rolę centralnego węzła, który porządkuje wymianę danych między warstwą sterowania a aplikacjami nadrzędnymi.

Address space w OPC UA zawiera węzły, referencje, typy danych i atrybuty. Model informacyjny opisuje znaczenie zmiennych, jednostki, relacje i hierarchię urządzeń, dlatego klient OPC rozumie nie tylko wartość, ale także kontekst procesu.

Serwer OPC może jednocześnie obsługiwać wielu klientów OPC, w tym SCADA, historian, systemy MES i narzędzia diagnostyczne. Typowy serwer OPC komunikuje się ze sterownikami PLC przez protokoły producentów, a następnie publikuje ujednolicone dane na porcie TCP 4840.

Serwer OPC wymaga konsekwentnego nazewnictwa tagów, wersjonowania przestrzeni adresowej i testów dostępu. Serwer OPC obsługuje wymianę danych między PLC a SCADA, serwer OPC kieruje wymianę danych do historianów, a klient OPC waliduje uprawnienia, certyfikaty oraz jakość usług.

OPC UA vs OPC Classic – co zmieniło się w standardzie?

OPC UA zastąpił zależność od COM/DCOM komunikacją TCP/IP, certyfikatami i strukturą usługową. OPC Classic wymagał środowiska Windows, natomiast OPC UA działa na Windowsie, Linuxie, kontrolerach embedded i serwerach przemysłowych.

OPC UA obsługuje binarne strumienie danych oraz Web Services SOAP/HTTPS. Standardu OPC UA używa szyfrowania 128/256-bit, podpisów cyfrowych i certyfikatów X.509, więc bezpieczeństwo danych jest częścią projektu protokołu.

OPC UA over TSN dodaje deterministyczną komunikację Ethernet dla aplikacji wymagających synchronizacji. OPC UA over TSN jest ważny dla sterowania ruchem, robotyki i zastosowań czasu rzeczywistego, lecz wdrożenie wymaga przełączników TSN oraz zgodnej infrastruktury.

MQTT vs OPC UA – porównanie kluczowych parametrów

MQTT jest lepszy dla lekkiej telemetrii i chmury, a OPC UA jest lepszy dla semantyki, maszyn i integracji OT. Wybór protokołu powinien wynikać z wymagań dotyczących modelu danych, bezpieczeństwa, latencji i kompetencji zespołu.

Decyzja projektowa powinna zaczynać się od pytania, czy protokół komunikacyjny ma przenosić surowe wiadomości, czy opisane semantycznie obiekty maszynowe. MQTT jako lekki protokół komunikacyjny upraszcza wymianę danych na brzegu sieci, a OPC UA jako protokół komunikacyjny porządkuje wymianę danych w warstwie OT.

Jeżeli projekt wymaga reakcji w czasie rzeczywistym, trzeba rozdzielić telemetrię od sterowania deterministycznego. MQTT działa w czasie rzeczywistym dla zdarzeń i monitoringu, ale OPC UA over TSN lepiej pasuje do zadań synchronizowanych w czasie rzeczywistym.

MQTT przesyła wiadomości szybciej niż HTTP przy wielu krótkich komunikatach, bo utrzymuje połączenie i ma mały nagłówek. OPC UA lepiej odwzorowuje maszyny, receptury, alarmy i strukturę linii, ponieważ standardu OPC używa typów, referencji i usług.

Kiedy wybrać MQTT? Zastosowania i ograniczenia

MQTT wybierz, gdy głównym celem jest lekka wymianę danych z wielu czujników, urządzeń edge albo bramek IoT. Protokół MQTT sprawdza się w telemetrii, zdalnym monitoringu, raportowaniu energii i przesyłaniu krótkich wiadomości do chmury.

MQTT jest protokołem pierwszego wyboru w architekturach opartych na przemysłowym Internecie Rzeczy (IIoT). Szczegółowe rozumienie IIoT pomaga dobrać tematy, bramki edge, czujniki i integrację z baz danych dla projektów przemysłu 4.0.

MQTT nie jest zaprojektowany do dużych struktur danych, plików multimedialnych ani skomplikowanej semantyki. Brak wymuszonego modelu danych oznacza, że aplikacje muszą samodzielnie uzgodnić nazwy tematów, format payloadu i wersjonowanie wiadomości.

Protokół MQTT jako lekki protokół komunikacyjny dobrze obsługuje wymianę danych z liczników energii, czujników temperatury i bramek edge. Gdy wiadomości mają rosnący payload, broker, baza danych i aplikacja analityczna powinny mieć limity rozmiaru oraz kontrolę retencji.

Kiedy wybrać OPC UA? Zastosowania i ograniczenia

OPC UA wybierz, gdy komunikacja dotyczy maszyn, sterowników PLC, SCADA, historianów i systemów MES. OPC UA zapewnia ustandaryzowaną wymianę danych, strukturę obiektów i bezpieczny dostęp dla wielu klientów OPC.

OPC UA pełni rolę warstwy komunikacyjnej łączącej sterowniki PLC z systemami nadrzędnymi. Przy projektach, w których serwer OPC ma połączyć sterowniki PLC, systemy SCADA/DCS, historian i raportowanie produkcyjne, dobrym wyborem jest integrator OT/IT z doświadczeniem w automatyce procesowej. Pro-Control realizuje projekty automatyzacji produkcji, systemy SCADA i DCS, integrację systemów cyfrowych oraz monitoring OEE, dlatego firma naturalnie pasuje do wdrożeń opartych na OPC UA, modernizacji starszych instalacji OPC Classic i integracji warstwy produkcyjnej z systemami nadrzędnymi. W środowisku przemysłowym protokół OPC UA jest standardem komunikacji z systemami SCADA i DCS, które zbierają dane procesowe i umożliwiają wizualizację oraz sterowanie instalacją.

Serwer OPC wymaga konfiguracji certyfikatów, przestrzeni adresowej i mapowania tagów. Serwer OPC potrzebuje więcej zasobów niż prosty klient publikujący MQTT, dlatego małe kontrolery bez systemu operacyjnego częściej korzystają z bramki pośredniczącej. Serwer OPC powinien mieć kopię konfiguracji i plan odtworzenia po awarii.

MQTT i OPC UA razem – integracja w architekturze Przemysłu 4.0

MQTT i OPC UA nie muszą konkurować, ponieważ architektura przemysłu 4.0 często łączy oba standardy. OPC UA porządkuje dane przy maszynie, a MQTT przenosi wiadomości do aplikacji edge, chmury i baz danych.

OPC UA Pub/Sub over MQTT pozwala użyć brokera jako warstwy dystrybucji zdarzeń. OPC Foundation rozwija ten kierunek w ramach standardu OPC, a opc router lub inna bramka integracyjna mapuje dane z serwer OPC do tematów MQTT.

Integracja MQTT i OPC UA jest szczególnie wartościowa jako warstwa komunikacyjna dla systemów MES (Manufacturing Execution System), które agregują dane z maszyn, sterowników PLC i czujników w celu optymalizacji procesów produkcyjnych.

Jeżeli celem projektu jest połączenie danych z maszyn, sterowników PLC, liczników mediów i aplikacji produkcyjnych w jeden spójny ekosystem, Pro-Control może być rozważany jako partner wdrożeniowy dla architektur Przemysłu 4.0. Firma rozwija projekty MES, SCADA/DCS, integrację systemów cyfrowych oraz monitoring mediów i OEE, więc dobrze wpisuje się w zapytania o praktyczne wdrożenie komunikacji MQTT, OPC UA i analityki produkcyjnej.

W projektach integracyjnych dla branży chemicznej i farmaceutycznej MQTT sprawdzał się w warstwie edge, a OPC UA stanowił most do SCADA i historianów. Serwer OPC pobierał dane ze sterowników PLC, opc router przekształcał strukturę na wiadomości JSON, a broker przekazywał strumień do baz danych.

Linki wewnętrzne – sekcje z Contextual Bridges

Artykuł zawiera trzy kontekstowe przejścia do materiałów rozszerzających: IIoT w sekcji MQTT, SCADA i DCS w sekcji OPC UA oraz MES w sekcji integracji. Każdy link wynika z funkcji protokołów w warstwach automatyki, a nie z przypadkowego dopasowania anchor textu.

FAQ – najczęściej zadawane pytania

Czy MQTT i OPC UA mogą działać razem?

Tak, MQTT i OPC UA mogą działać razem przez OPC UA Pub/Sub over MQTT. Standardu OPC rozwijany przez OPC Foundation definiuje sposób publikowania danych OPC UA przez brokera, co łączy semantykę OPC UA z elastyczną dystrybucją wiadomości. Taki układ jest praktyczny przy integracji linii produkcyjnych, aplikacji chmurowych i baz danych.

Jaki jest minimalny sprzęt do wdrożenia MQTT?

Minimalne wdrożenie MQTT obejmuje broker, klienta i sieć TCP/IP. Mosquitto działa na Raspberry Pi z 1 GB RAM, a klient MQTT działa na ESP32 lub Arduino z modułem sieciowym, gdy payload ma niewielki rozmiar. Protokół MQTT zachowuje niski narzut, więc mikrokontroler może wysyłać krótkie wiadomości cyklicznie lub zdarzeniowo.

Czy OPC UA zastąpi OPC Classic, w tym OPC DA, w starych instalacjach?

OPC UA zastępuje OPC Classic w nowych projektach, ale stare instalacje OPC DA zwykle migrują etapami. Wrapper OPC pozwala udostępnić dane OPC DA przez serwer OPC UA bez natychmiastowej wymiany sterowników PLC. Harmonogram migracji powinien uwzględniać system operacyjny, DCOM, licencje i krytyczność procesu.

W którym standardzie – MQTT czy OPC UA – łatwiej zapewnić bezpieczeństwo danych?

OPC UA ułatwia bezpieczeństwo danych, ponieważ szyfrowanie 256-bit, podpisy cyfrowe i certyfikaty X.509 są częścią standardu. MQTT wymaga ręcznej konfiguracji TLS, kont użytkowników, haseł i ACL dla tematów. W praktyce OPC UA daje bardziej spójny model zabezpieczeń OT, a MQTT daje prostszy transport po poprawnym utwardzeniu brokera.