MQTT – najłatwiejszy sposób przesyłania danych do chmury!

105

Spis treści [Ukryj]

Dlaczego MQTT?

Poprawa jakości życia od zawsze była główną motywacją do poszukiwania nowych oraz coraz lepszych technologii. Obecny trend podłączania coraz większej liczby urządzeń do Internetu sprawia, że opracowanie niezawodnych urządzeń do aplikacji IIoT staje się ogromnym wyzwaniem. Wspomniane urządzenia, zwane często urządzeniami brzegowymi, dostarczają dane zwykle do systemu centralnego. Dokładnie efektywne zbieranie danych z takich urządzeń wymaga wdrażania nowych rozwiązań. Do tego celu można wykorzystać kilka protokołów takich jak: MQTT, AMQP czy CoAP. Jednak, to właśnie MQTT jest najchętniej wykorzystywanym protokołem przez programistów do tworzenia aplikacji IIoT jest protokół MQTT. Na poniższym wykresie można zauważyć, iż ponad połowa programistów IoT wykorzystuje protokół MQTT do swoich aplikacji.

MQTT jest najczęściej wykorzystywanym protokołem w aplikacjach IoT

Jak działa MQTT?

Wzorzec publish-subscribe

Protokół MQTT został opracowany w 1999 roku przez firmy IBM oraz Circus Link. Natomiast, w 2013 roku został oficjalnie uznany jako standard ISO. MQTT oparty jest o wzorzec publish-subscribe. W takiej architekturze wiadomości wysyłane przez nadawców (publisher) trafiają do serwera pośredniczącego (broker), a nie bezpośrednio do odbiorców (subscriber). Wiadomość publikowana jest na tzw. temat (topic). Klienci którzy subskrybują dany temat (topic) otrzymują opublikowane na nim wiadomości. Dane publikowane przy użyciu protokołu MQTT są danymi tekstowymi. Oznacza to, że z łatwością możemy przekształcić strukturę danych do formatu JSON (lub innego dowolnego formatu tekstowego), a następnie ją opublikować.

Idea działania MQTT opiera się na zasadzie publish-subscribe

W porównaniu do innych protokołów działających na zasadzie zapytanie-odpowiedź, MQTT pozwala rozwiązać powszechny problem z dostępnością urządzeń. W standardowych przypadku, klient oraz serwer muszą być online w tym samym czasie, aby nawiązać komunikację i wymienić między sobą informacje. W przypadku aplikacji IIoT, w których urządzenia często umieszczone są na obiektach przemysłowych, gdzie mogą występować częste utrudnienia związane z komunikacją, rozwiązanie klient-serwer nie zawsze jest odpowiednie. Do tego celu idealnie nadaje się protokół MQTT. Wymagane jest jedynie, aby broker był aktywny cały czas. Broker, przed przesłaniem wiadomości, sprawdza czy klient jest aktywny. Jeżeli nie, broker może czekać z wysłaniem wiadomości, do czasu, gdy klient będzie online. Klienci, zarówno publikujący jak i subskrybujący informacje mogą być aktywni tylko wtedy, gdy potrzebują wysłać lub odebrać informacje.

Broker MQTT

Klienci nie komunikują się ze sobą bezpośrednio, a w oparciu o element pośredniczący, którym jest broker. Broker pełni rolę serwera, z którym łączą się klienci, aby za jego pośrednictwem publikować informacje. Jego zadaniem jest odbieranie wiadomości od klientów publikujących i rozsyłanie jej do odpowiednich klientów subskrybujących. Taki model pozwala na udostępnianie danych innym klientom bez znajomości ich adresu IP. Dzięki temu możliwa jest wymiana danych pomiędzy wieloma klientami w tym samym czasie.

Taki serwer można zaimplementować samodzielnie. Jednak ze względu na sporą ilość gotowych i sprawdzonych rozwiązań, np. broker Mosquitto, VerneMQ. Broker MQTT można z powodzeniem zainstalować nawet na bardzo kompaktowych komputerach Moxa z systemem Linux – UC-2100.

QoS – priorytetyzacja ruchu

Przy transmisji danych w sieciach komputerowych, często spotykamy się z pojęciem QoS – Quality of Service. Jest ono wykorzystywane także w przypadku protokołu MQTT, który zapewnia trzy poziomy QoS, w odniesieniu do gwarancji dostarczania wiadomości pomiędzy serwerem a clientami.

QoS 0: at most once

W tym przypadku Client wysyła wiadomość do brokera tylko raz. Broker nie wysyła potwierdzenie do Clienta o otrzymaniej wiadomości. Wiadomość do Clienta, który subskrybuje dany topic, może zostać dostarczona co najwyżej raz, albo nie zostanie dostarczona w ogóle. Przy tak ustawionej wartości QoS, wiadomości nie są przechowywane rzez nadawce i nie są wykorzystywane potwierdzenia odbioru oraz realizowane ewentualne retransmisje. QoS 0 jest zdecydowanie najszybszą metodą prorytetyzacji ruchu, ale również jest najbardziej zawodną metodą.

QoS 1: at least once

W tym przypadku wiadomość zostanie dostarczona co najmniej raz. Może dojść również do zduplikowania wiadomości. Przy tak ustawionej wartości QoS, Client (nadawca) oczekuje potwierdzenia otrzymania wiadomości od Brokera i przechowuje wiadomość na wypadek konieczności retransmisji. Jeżeli nadawca nie otrzyma potwierdzenia w określonym interwale czasu, wyśle ponownie wiadomość, aż do otrzymania potwierdzenia.

QoS 2: exactly once

Wybór tej wartości QoS zapewnia najwyższą jakość i gwarantuje dostarczenie wiadomości dokładnie raz. Wymaga jednak najbardziej złożonego systemu potwierdzeń, co powoduje, iż jest to zarazem najbardziej niezawodny, a także najwolniejszy sposób wymiany wiadomości.

Warto jeszcze tutaj zwrócić uwagę na jedną rzecz: publisher przesyłając wiadomość do brokera ustawia jej określoną wartość QoS. Subscriber odbierający wiadomość od brokera także może to robić z dowolną wartością QoS. W związku z tym, poziom QoS jednej wiadomości przekazywanej na drodze publisher – broker i broker – subscriber może mieć różne wartości. Dlatego wiadomość wysłana przez publishera z QoS 1 lub QoS 2 mimo wszystko może nie dojść do subscribera, jeśli ten będzie subskrybwał dany temat z QoS 0.

Bezpieczeństwo przesyłanych danych

Utrzymanie bezpieczeństwa sieci to jeden z głównych problemów aplikacji IIoT. Z przeszłości wiemy, iż większość ataków przychodzi z zewnątrz. Dlatego pierwszym krokiem do poprawy cyberbezpieczeństwa infrastruktury przemysłowej powinno być zaimplementowanie firewalla i w ogólności ciągłe uaktualnienie zabezpieczeń m.in. poprzez instalację najnowszego oprogramowania. Praktyka pokazuje, iż urządzenia przemysłowe bardzo rzadko chronione są w prawidłowy sposób. Powszechnie używany protokół – Modbus, nie jest w żaden sposób szyfrowany.

Aby chronić dane użytkowników, seria ioThinx 4510 wykorzystuje protokół TLS v1.2 do szyfrowania danych wysyłanych za pośrednictwem protokołu MQTT. IoThinx 4510 wspiera również uwierzytelnienie brokera poprzez podanie loginu oraz hasła. Chroni to przed wysłaniem danych do nieautoryzowanego brokera.

Urządzenia Moxa ze wsparciem protokołu MQTT

Firma MOXA posiada w swojej ofercie szereg rozwiązań kontrolno-pomiarowych, które umożliwiają przesyłanie danych i sygnałów bezpośrednio do chmury. Na szczególną uwagę trzy serie urządzeń polowych Moxa, które można wykorzystywać do zbierania sygnałów. Są to: serwer portów szeregowych NPort IAW5000A-I/O, konwerter protokołów MGate 5105-MB-EIP oraz seria modułowych wejść/wyjść ioThinx 4500. Dane do chmury można wysłać z wykorzystaniem protokołu MQTT. Dla ułatwienia, do urządzeń dostarczone są narzędzia programistyczne SDK, które ułatwiają przesłanie danych do chmury Azure lub Alibaba.

Urządzenia polowe Moxa umożliwiają łatwe przesłanie danych do chmury dzięki wsparciu protokołu MQTT

Zachęcamy do zapoznania się z poniższym artykułem, opisującym możliwości bramki przemysłowej MGate 5105-MB-EIP.

MQTT z ioThinx 4510

Prosta topologia, którą można zbudować, aby zaprezentować możliwości ioThinx 4510 w zakresie współpracy z protokołem MQTT przedstawiona jest na poniższym rysunku:

  • moduły kontrolno-pomiarowe zbierają sygnały I/O (wejścia/wyjścia analogowo/cyfrowe
  • ioThinx 4510 jako Client MQTT publikuje, a także subskrybuje wiadomości MQTT
  • komputer UC-2100 pełni rolę brokera MQTT
  • również na komputerze UC-2100 zainstalowane jest darmowe oprogramowanie Node-RED, które może być wykorzystane do wizualizacji procesu, czy sygnałów. Tutaj można wykorzystać dowolnie inne oprogramowanie, które współpracuje z protokołem MQTT.
  • wizualizacja może być wyświetlana na wielu nośnikach (np. laptop, smartfon, tablet).

Zachęcam do zapoznania się z poniższym artykułem, aby poznać szerszy zakres możliwości, które oferują moduły kontrolno-pomiarowe z serii ioThinx 4500.

Instalacja brokera MQTT na komputerze UC-2100

Wiemy już jak protokół działa w teorii, czas przejść do praktyki. 
Zaczniemy od instalacji brokera. Istnieją jego różne implementacje, bardzo popularny jest np. open-sourcowy broker Eclipse Mosquitto i właśnie go tutaj wykorzystamy. Broker ten może być z powodzeniem zainstalowany na wielu platformach (Windows, Linux, Debian). My do tego celu wykorzystamy Armowy komputer Moxa – UC-2100.

Poniżej przedstawiona metoda pozwoli zainstalować Mosquitto na systemach typu Ubuntu/Debian oraz Raspbian. Należy uruchomić terminal i wywołać następujące polecenia:

sudo apt-get update
sudo apt-get upgrade
sudo apt-get install mosquitto

po zakończonej instalacji możemy sprawdzić, czy nasz serwer MQTT działa. Możemy to wykonać przy pomocy polecenia:

systemctl status mosquitto

Jeżeli otrzymaliśmy komunikat zawierający linię w stylu:

Active: active (running) since Sun 2018-04-08 21:17:19 UTC; 41min ago

To znaczy, że nasz broker Mosquitto działa poprawnie.

ioThinx 4510

Aktywacja MQTT

W kolejnym kroku należy aktywować usługę MQTT Client. W tym celu należy przejść do zakładki Security->Servise Settings i wybrać odpowiednią pozycję. Jeżeli na poniższej liście nie pojawia się opcja MQTT Client, należy zaktualizować oprogramowanie do wersji v1.1.0. Link do pobrania tutaj. Ustawienia należy potwierdzić klikając Save & Restart.

Aktywacja usługi MQTT Client na ioThinx 4510

Wybierając opcję MQTT z menu po lewej stronie, możemy ustawić parametry połączenia z brokerem, m.in. adres IP brokera, numer portu, szyfrowanie, dane do logowania itp.

Konfiguracja parametrów połączenia z brokerem MQTT

Publikacja topiców

Klient, publikując wiadomość, dodaje do niej dodatkową informację – tekst nazwany tematem (ang. topic). W zakładce MQTT->Topic Settings-> Publisher możemy wskazać tematy, które będą publikowane, QoS itp.

Publikacja topiców

Istotną rzeczą jest to, że w ioThinx 4510 istnieje możliwość tworzenia tematów wielopoziomowych. Każdy poziom oddzielany jest znakiem „/”, np.

ioThinx_4510/read/wieza@ostrzezenie/diStatus

Struktura wygląda następująco:

nazwa_urządzenia/read lub write/nazwa_modulu@nazwa_zmiennej/atrybut

Wiadomości publikowane są w formacie JSON o poniższej strukturze

{"value":X}

Subskrypcja topiców

Analogicznie, jak w przypadku publikacji topiców, w zakładce MQTT->Topic Settings-> Subscriber możemy wskazać tematy, które będzie subskrybował ioThinx.

Subskrypcja topiców

Przykładowo: jeżeli do brokera trafi wiadomość o topicu: ioThinx_4510/write/wieza@czerwony/doStatus oraz zawartości {„value”:1}, to ioThinx, który subskrybuje ten topic, ustawi stan wysoki na wyjściu cyfrowym.

Więcej szczegółowych informacji o konfiguracji MQTT można znaleźć w instrukcji użytkownika.

Możliwości wykorzystania danych

Moduły kontrolno-pomiarowe oraz bramy przemysłowe we współpracy z usługami chmurowymi tworzą bardzo ciekawą synergiczną mieszankę, która umożliwia tworzenie nowoczesnych systemów w myśl idei Przemysłu 4.0 i IIoT. Urządzenia Moxa umożliwiają wysyłanie danych z sieci przemysłowych do dostawców chmurowych, a tam dalszą ich obróbkę, przetwarzanie, wizualizowanie, wysyłanie powiadomień e-mail/SMS, uczenie maszynowe, predictive maintenance, przechowywanie, wizualizowanie, upublicznianie i wiele więcej.

Do stworzenia prostej wizualizacji można wykorzystać darmowe oprogramowanie Node-RED, które również może być zainstalowane na komputerach UC-2100.
Konfiguracja Node-REDa jest bardzo intuicyjna i nie wymaga od użytkownika specjalistycznej wiedzy programistycznej.

Źródło: Elmark

 

ZOSTAW ODPOWIEDŹ

Wprowadź swój komentarz!
Wprowadź swoje imię