Gdy czujnik temperatury, sterownik PLC i panel operatorski mają wymieniać dane przez sieć, szybko pojawia się pytanie, jak zrobić to lekko, czytelnie i bez tworzenia dziesiątek bezpośrednich połączeń. MQTT to protokół, który rozwiązuje ten problem dzięki modelowi publikowania i subskrybowania wiadomości. Wyjaśniam, co oznacza MQTT, jak działa broker, czym różnią się poziomy QoS oraz gdzie ten standard ma sens w automatyce i sterowaniu.
MQTT w kilku zdaniach pozwala sprawnie łączyć urządzenia IoT i systemy automatyki
- MQTT to lekki protokół komunikacyjny działający najczęściej nad TCP/IP.
- Urządzenia nie komunikują się bezpośrednio, lecz korzystają z pośrednika nazywanego brokerem.
- Dane są przesyłane w modelu publish/subscribe za pomocą tematów, czyli topiców.
- Poziomy QoS 0, 1 i 2 określają sposób potwierdzania dostarczenia wiadomości.
- MQTT dobrze pasuje do monitoringu, telemetrii, inteligentnych budynków i integracji sterowników.
- Nie zastępuje automatyki bezpieczeństwa ani deterministycznych magistral czasu rzeczywistego.
Co to jest MQTT i dlaczego zyskał popularność
MQTT jest lekkim protokołem przesyłania wiadomości przeznaczonym przede wszystkim do komunikacji między urządzeniami. Jego pełna historyczna nazwa to Message Queuing Telemetry Transport, ale dziś najczęściej używa się po prostu skrótu MQTT. Standard został zaprojektowany z myślą o urządzeniach o małej mocy obliczeniowej, ograniczonej pamięci i połączeniach, które nie zawsze są stabilne.
Najważniejsza różnica względem klasycznej komunikacji klient-serwer polega na rozdzieleniu nadawcy i odbiorcy. Czujnik publikuje dane, a zainteresowane urządzenia subskrybują wybrany temat. Dzięki temu producent wiadomości nie musi znać adresu każdego odbiorcy, co znacznie upraszcza rozbudowę instalacji.
Broker, klient i topic
W typowej instalacji występują trzy elementy. Klient MQTT to każde urządzenie lub program łączący się z brokerem. Może nim być sterownik PLC, mikrokontroler, komputer przemysłowy, aplikacja mobilna albo system SCADA.
Broker odbiera wiadomości, sprawdza subskrypcje i przekazuje dane właściwym klientom. Topic, czyli temat, działa jak adres logiczny wiadomości. Przykładowa struktura może wyglądać tak: hala1/linia2/silnik3/temperatura. Taki układ jest prosty dla człowieka i łatwo go rozszerzać o kolejne hale, linie oraz urządzenia.
Sam broker nie rozumie, czy przesyłana wartość oznacza temperaturę, ciśnienie czy stan zaworu. MQTT transportuje dane, ale ich znaczenie wynika z przyjętego przez projektanta formatu. W praktyce warto od początku ustalić, czy wiadomości zawierają pojedynczą liczbę, tekst, czy strukturę JSON z wartością, jednostką i znacznikiem czasu.
Jak działa komunikacja MQTT krok po kroku
Najpierw klient nawiązuje połączenie z brokerem. Może się uwierzytelnić loginem i hasłem, certyfikatem albo innym mechanizmem obsługiwanym przez konkretną implementację. Po połączeniu urządzenie może publikować dane, zapisywać subskrypcje lub robić jedno i drugie jednocześnie.
Przykładowo czujnik wibracji publikuje wartość w temacie maszyna1/wibracje/rms. Panel operatorski ma subskrypcję tego tematu, a system analityczny może dodatkowo słuchać całej gałęzi maszyna1/#. Broker dostarcza wiadomość do obu odbiorców bez konieczności konfigurowania osobnego połączenia między czujnikiem a każdym systemem.
Wildcardy ułatwiają organizację danych
MQTT pozwala stosować symbole wieloznaczne w subskrypcjach. Znak + zastępuje jeden poziom, a # obejmuje dany poziom i wszystkie kolejne. Subskrypcja hala1/+/temperatura może odebrać temperaturę z wielu urządzeń w hali, natomiast hala1/# pozwala monitorować całą strukturę.
Ta wygoda bywa też źródłem błędów. Zbyt szeroka subskrypcja może dostarczyć aplikacji tysiące niepotrzebnych komunikatów, a nieprzemyślany schemat topiców utrudni później filtrowanie danych. Ja zwykle zaczynam od stałej hierarchii obejmującej lokalizację, urządzenie, parametr i rodzaj danych, na przykład zaklad/linia01/prasa02/stan.
Publikowanie danych i wysyłanie poleceń
MQTT nadaje się nie tylko do telemetrii. Ten sam mechanizm może przesyłać polecenia, na przykład budynek1/ogrzewanie/kociol/set. Warto jednak wyraźnie rozdzielić topiki z pomiarami od topików sterujących i ustalić format odpowiedzi, aby system wiedział, czy polecenie zostało przyjęte, wykonane lub odrzucone.
W instalacjach przemysłowych nie wysyłałbym bezpośrednio przez MQTT poleceń, które mają zastępować funkcje awaryjne. Protokół może być dobrym kanałem dla nastawy temperatury albo trybu pracy, ale obwód bezpieczeństwa powinien działać niezależnie i reagować nawet wtedy, gdy broker lub sieć przestanie odpowiadać.
QoS, wiadomości retained i Last Will bez technicznego zamieszania
Jedną z największych zalet MQTT jest możliwość dobrania sposobu dostarczania wiadomości do znaczenia danych. Służy do tego QoS, czyli Quality of Service. Wyższy poziom zwiększa kontrolę nad dostarczeniem, ale zwykle oznacza większą liczbę potwierdzeń, większy ruch i większe opóźnienie.
| Poziom QoS | Znaczenie | Kiedy użyć |
|---|---|---|
| QoS 0 | Wiadomość jest wysyłana bez potwierdzenia | Częste pomiary, gdzie utrata pojedynczej próbki nie ma dużego znaczenia |
| QoS 1 | Wiadomość ma dotrzeć co najmniej raz, więc może pojawić się ponownie | Alarmy, stany urządzeń i dane, których nie chcemy łatwo zgubić |
| QoS 2 | Protokół zapewnia dostarczenie dokładnie raz | Wybrane operacje, w których duplikat wiadomości byłby szczególnie problematyczny |
QoS 1 nie oznacza dostarczenia dokładnie raz. Po ponownym połączeniu lub przy problemach z potwierdzeniem odbiorca może dostać tę samą wiadomość ponownie, dlatego aplikacja powinna umieć rozpoznać duplikat. Z kolei QoS 2 daje silniejsze gwarancje protokołu, ale nie sprawia automatycznie, że fizyczne urządzenie wykona polecenie tylko raz.
Retained message przechowuje ostatni znany stan
Wiadomość oznaczona jako retained zostaje zapamiętana przez brokera jako ostatnia wartość dla danego topicu. Gdy nowy klient zasubskrybuje temat, może od razu otrzymać ostatni stan zamiast czekać na kolejny pomiar. To bardzo praktyczne przy parametrach takich jak tryb pracy, stan zaworu albo temperatura zadana.
Retain nie jest jednak historią pomiarów. Broker zwykle przechowuje tylko ostatnią wiadomość dla konkretnego tematu. Do archiwizacji trendów potrzebna jest osobna baza danych lub system SCADA.
Last Will informuje o nagłym rozłączeniu
Mechanizm Last Will and Testament pozwala klientowi ustawić wiadomość publikowaną przez brokera, gdy urządzenie niespodziewanie straci połączenie. Przykładowo sterownik może mieć stan online, a broker po wykryciu zerwania komunikacji opublikuje offline.
W monitoringu maszyn jest to często cenniejsze niż samo sprawdzanie, kiedy ostatnio przyszedł pomiar. Trzeba tylko dobrać rozsądny czas keep alive, ponieważ zbyt agresywne ustawienie może powodować fałszywe alarmy przy chwilowych problemach z siecią.
Gdzie MQTT sprawdza się w automatyce i sterowaniu
MQTT szczególnie dobrze pasuje do warstwy, w której dane trzeba zebrać z wielu urządzeń i udostępnić je różnym systemom. Nie wymaga, aby każdy odbiorca znał protokół konkretnego czujnika. Wystarczy, że urządzenie brzegowe lub sterownik przetłumaczy dane na ustalone topiki.
Monitoring maszyn i predykcyjne utrzymanie ruchu
Czujniki temperatury, drgań, prądu i ciśnienia mogą publikować pomiary do brokera. Panel operatorski pokazuje bieżący stan, a system analityczny wykrywa niepokojące trendy. To dobre zastosowanie, ponieważ pojedyncza utracona próbka zwykle nie przekreśla analizy, więc dla części danych wystarczy QoS 0.
Inteligentne budynki i instalacje HVAC
W budynku MQTT może przenosić informacje o temperaturze, wilgotności, obecności, stanie siłowników i zapotrzebowaniu na ciepło. Jeden broker może obsługiwać automatykę, aplikację użytkownika oraz wizualizację, pod warunkiem że uprawnienia ograniczają dostęp każdego klienta do potrzebnych tematów.
Integracja sterowników, bramek i systemów nadrzędnych
MQTT często pełni rolę warstwy integracyjnej. Bramka komunikacyjna pobiera dane z Modbus RTU, CAN albo wejść cyfrowych i publikuje je w sieci Ethernet. Dzięki temu system nadrzędny nie musi znać szczegółów każdego urządzenia polowego.
Takie rozwiązanie ma sens szczególnie przy modernizacji istniejącej instalacji. Nie trzeba od razu wymieniać wszystkich sterowników, ponieważ można dodać urządzenie pośredniczące i stopniowo włączać kolejne fragmenty automatyki do wspólnego systemu.
MQTT a HTTP, Modbus TCP i OPC UA
MQTT nie jest uniwersalnym zamiennikiem każdego protokołu. Najlepszy wybór zależy od tego, czy potrzebujemy przesyłać zdarzenia, odczytywać rejestry, wymieniać dane z pełnym opisem obiektów, czy zapewnić ścisły czas reakcji.
| Protokół | Najmocniejsza strona | Typowe zastosowanie | Ograniczenie |
|---|---|---|---|
| MQTT | Lekka komunikacja publish/subscribe | IoT, telemetria, alarmy, integracja systemów | Zależność od brokera i brak gwarancji deterministycznego czasu reakcji |
| HTTP | Prosta komunikacja żądanie-odpowiedź | API, konfiguracja, przesyłanie danych do usług internetowych | Większy narzut przy częstych, małych komunikatach |
| Modbus TCP | Prosty odczyt i zapis rejestrów | Sterowniki PLC, falowniki, liczniki, urządzenia przemysłowe | Brak natywnego modelu publikowania i subskrypcji |
| OPC UA | Rozbudowany model danych i interoperacyjność przemysłowa | SCADA, MES, integracja urządzeń i systemów produkcyjnych | Większa złożoność oraz wymagania sprzętowe |
W praktyce często łączy się te technologie zamiast wybierać tylko jedną. Sterownik może odczytywać falownik przez Modbus TCP, bramka publikuje wynik przez MQTT, a system produkcyjny pobiera dane przez OPC UA. Taki podział jest rozsądny, bo każdy protokół wykonuje zadanie, do którego został najlepiej dopasowany.
Nie traktowałbym MQTT jako magistrali do sterowania ruchem osi, szybkich pętli regulacji czy funkcji bezpieczeństwa. Przy takich zadaniach liczy się przewidywalny czas transmisji, a komunikacja przez broker i typową sieć Ethernet nie daje takiej deterministyczności jak rozwiązania czasu rzeczywistego.
Jak bezpiecznie wdrożyć MQTT w instalacji
Uruchomienie brokera na komputerze testowym jest proste, ale instalacja produkcyjna wymaga kilku decyzji. Najpierw trzeba ustalić, gdzie broker będzie działał, jak urządzenia dostaną adres serwera oraz co stanie się z komunikacją po awarii sieci. W małej instalacji wystarczy niewielki komputer przemysłowy, natomiast większy system może wymagać klastra brokerów i trwałego zapisu sesji.
Przeczytaj również: Sterownik PLC - jak działa i jak dobrać go do maszyny
Podstawowe zasady konfiguracji
- Włącz TLS, gdy dane opuszczają zaufaną, odizolowaną sieć.
- Używaj osobnych kont i uprawnień dla urządzeń, operatorów oraz aplikacji.
- Ograniczaj publikowanie i subskrybowanie za pomocą ACL, czyli list kontroli dostępu.
- Nie pozostawiaj brokera z anonimowym dostępem w sieci produkcyjnej.
- Ustal jednolity schemat topiców i dokumentuj jednostki oraz format danych.
- Monitoruj opóźnienia, liczbę połączeń, odrzucone logowania i stan brokera.
Najczęstszy błąd polega na zabezpieczeniu samego brokera, ale pominięciu urządzeń końcowych. Jeżeli sterownik ma zapisane hasło w otwartej konfiguracji albo działa w tej samej sieci co komputery biurowe, szyfrowanie połączenia nie rozwiązuje całego problemu. W automatyce rozsądnie jest oddzielić sieć urządzeń od sieci biurowej i dopuścić tylko wymagany ruch.
Drugim problemem bywa nadmierne używanie QoS 2. Najwyższy poziom nie jest automatycznie najlepszy. Dla szybkich pomiarów może powodować niepotrzebny ruch, a dla krytycznych poleceń i tak nie zastąpi potwierdzenia wykonania po stronie aplikacji.
Co sprawdzić przed podłączeniem pierwszego urządzenia
Na początek warto zbudować mały test z jednym brokerem, jednym klientem publikującym i jednym odbiorcą. Sprawdź wtedy, jak zachowują się reconnect, retained message, QoS i Last Will, a nie tylko sam przesył danych przy idealnym połączeniu.
Przed wdrożeniem przygotuj też listę topiców, jednostek, częstotliwości pomiarów i reakcji na brak komunikacji. Jeżeli połączenie MQTT zniknie, sterownik powinien mieć jasno określony tryb awaryjny, na przykład utrzymanie ostatniej bezpiecznej nastawy, zatrzymanie procesu albo przejście na lokalne sterowanie.
Najkrócej mówiąc, MQTT jest świetnym wyborem do lekkiej, elastycznej wymiany danych między urządzeniami i systemami automatyki. Najwięcej daje wtedy, gdy broker, struktura topiców, uprawnienia i zachowanie po awarii są zaprojektowane równie starannie jak sam program sterownika.
