Lekki protokół transmisji danych (MQ Telemetry Transport (MQTT)) odpowiada na wiele wyzwań związanych z dzisiejszymi coraz bardziej złożonymi sieciami przemysłowymi i może przyspieszyć inicjatywy transformacji cyfrowej.
Przemysł 4.0, inteligentna fabryka i systemy cyberfizyczne to odrębne inicjatywy, ale mają jedną wspólną cechę – wszystkie zależą od masowo równoległej komunikacji maszyna-maszyna. Analitycy z całego świata przewidują, że globalny rynek Przemysłowego Internetu Rzeczy (IIoT) osiągnie wartość setek miliardów dolarów do końca dekady. Niezależnie od tego, czy są to czujniki, silniki, sterowniki czy interfejsy człowiek-maszyna (HMI), wszystkie one muszą łączyć się z coraz większą liczbą użytkowników, od systemów kontroli nadzorczej i gromadzenia danych (SCADA) i systemów realizacji produkcji (MES) po programowalne sterowniki logiczne (PLC), a nawet producentów oryginalnego sprzętu (OEM) i usługi niezawodnościowe innych firm. Posiadanie danych nie wystarczy – muszą one być dostępne i wykorzystywane w odpowiednim czasie. W tym miejscu pojawia się transport telemetryczny z kolejkowaniem komunikatów (MQTT).
MQTT, protokół komunikacyjny typu open source opracowany dla krytycznych systemów rurociągowych SCADA w przemyśle naftowym i gazowym, odpowiada na wiele wyzwań związanych z dzisiejszymi coraz bardziej złożonymi sieciami przemysłowymi. Obecne protokoły komunikacji przemysłowej opierają się na bezpośrednich połączeniach między źródłem danych a odbiorcą danych. Są one skuteczne w operacjach na poziomie maszyn, ale jeśli chodzi o łączenie dużej liczby urządzeń z aplikacjami zewnętrznymi, ich wdrożenie i utrzymanie może być złożone i czasochłonne. Brakuje im elastyczności i skalowalności, aby obsłużyć nowe środowisko oparte na danych.
MQTT został zaprojektowany z myślą o komunikacji maszyna-maszyna. Jego usprawniona architektura sieciowa i lekka specyfikacja pakietów sprawiają, że jest wystarczająco elastyczny dla rekonfigurowalnych linii produkcyjnych i wystarczająco skalowalny, aby obsługiwać dodawanie setek, a nawet tysięcy podłączonych urządzeń. “To właściwy paradygmat dla produkcji” – powiedział Mike Bowers, główny architekt w FairCom (Sandy, Utah). “Mocno wierzę, że MQTT zrobi dla produkcji to, co Internet zrobił dla wszystkiego innego”.
Publikowanie/subskrybowanie MQTT
MQTT jest protokołem warstwy aplikacji, który wykorzystuje TCP/IP jako warstwę transportową. W ten sposób przypomina aplikację HTTP używaną w Internecie. Protokół HTTP wymaga jednak długich i złożonych nagłówków, podczas gdy nagłówek MQTT jest lekki i ma rozmiar 2 B. Maksymalny rozmiar ładunku wiadomości MQTT wynosi 256 MB. Zawartość jest niezależna od formatu – ładunki mogą zawierać dane binarne, dane tekstowe, pliki obrazów, takie jak JPEG, XML, notacja obiektów JavaScript (JSON) i inne. MQTT obsługuje również zaszyfrowane pliki.
Specyfikacja wiadomości jest ważna, ale niektóre z największych zalet MQTT wynikają z jego architektury. Obecne przemysłowe protokoły sieciowe opierają się na komunikacji typu ankieta/odpowiedź poprzez bezpośrednie połączenia między urządzeniami. Połączone urządzenia odpowiadają na ankietę lub wysyłają aktualizacje w regularnych odstępach czasu. Protokoły te są wysoce skuteczne w przypadku wymiany danych w czasie rzeczywistym wymaganej na poziomie maszyny, np. między enkoderami i silnikami lub silnikami i sterownikami. Jednak wraz ze wzrostem liczby aplikacji i urządzeń, które muszą wymieniać dane poza bezpośrednim poziomem maszyny, sieć, a nawet same urządzenia stają się coraz bardziej obciążone. I nie zapominajmy, że modele te są nadal ograniczone potrzebą bezpośredniego połączenia. Nawet w przypadku protokołów zgodnych z modelem producent-konsument, konsument nadal musi znać tożsamość urządzenia produkującego.
Aby uniknąć tych problemów, MQTT opiera się na modelu publikuj/subskrybuj (pub/sub). Urządzenia i aplikacje, zwane klientami, łączą się za pośrednictwem oprogramowania pośredniczącego znanego jako broker. Klienci nie łączą się ze sobą ani nie wysyłają zapytań o dane na określony adres. Zamiast tego wszyscy klienci łączą się z brokerem, który działa jak poczta, przyjmując informacje od klientów-wydawców i przekazując je klientom-subskrybentom.
MQTT obejmuje pojedyncze połączenie TCP/IP od klienta do brokera. Każdy klient ma przypisany unikalny identyfikator klienta, ale jest on używany tylko przez brokera do nawiązania połączenia. Rzeczywiste gromadzenie danych jest regulowane przez tematy. Temat MQTT to ciąg tekstowy identyfikujący publikowane dane. Rozważmy silnik z wbudowanymi czujnikami temperatury i prądu podłączonymi do brokera jako klienci publikujący (bezpośrednio lub za pośrednictwem innego podłączonego urządzenia). Ich tematy mogą być zdefiniowane w następujący sposób:
komórkaB/silnikA/czujnik/temperatura
lub
komórkaB/silnikA/czujnik/prąd
Aplikacja predykcyjnego utrzymania ruchu (PM) może subskrybować te dwa tematy, aby otrzymywać aktualizacje z czujników. Aby jeszcze bardziej uprościć proces, tematy mogą być używane z symbolami wieloznacznymi, więc aplikacja PM subskrybowałaby cellB/+/sensor/current, aby uzyskać dostęp do zmian w poborze prądu dla wszystkich silników w komórce (jednopoziomowy symbol wieloznaczny) lub cellB/motorA/sensor/#, aby otrzymać wszystkie dane czujnika dla tego silnika (wielopoziomowy symbol wieloznaczny). Podobnie, system SCADA, MES lub historyk danych, a także aplikacja PM, mogą subskrybować odpowiednią ścieżkę tematyczną, aby uzyskać status z bezpiecznego sterownika PLC, aby być na bieżąco ze stanem maszyny.
Subskrybowanie według tematu oznacza, że proces otrzymywania opublikowanych danych jest niezależny od typu lub adresu IP klienta publikującego. Można to porównać do Twittera dla maszyn, w porównaniu do tradycyjnych systemów ankiet/odpowiedzi, które są bardziej zbliżone do poczty elektronicznej. Jeśli czujnik zostanie wymieniony, ale przypisany do tego samego tematu, wszelkie zmiany w jego szczegółach są przezroczyste dla klientów subskrybujących.
“Nie wiążę moich tematów z urządzeniami” – powiedział Bowers. “Wiążę je z tym, co robią, a nie z tym, czym są. Dzięki temu fabryka może być bardziej elastyczna”. Jak zauważa, klienci korzystający z konwencjonalnych sieci typu ankieta/odpowiedź nie byli w stanie łatwo przeprojektować lub zmienić konfiguracji linii produkcyjnych. MQTT stanowi dla nich alternatywę. “Teraz mogą dynamicznie zmieniać, który sprzęt komunikuje się z każdym innym urządzeniem, po prostu zmieniając tematy i subskrypcje. Dodawanie nowych urządzeń oraz zmiana kształtu i reorganizacja linii jest bardzo szybka i łatwa”.
Dyskusja na temat publikowania przywołuje kolejną kluczową zaletę MQTT, którą jest raportowanie w drodze wyjątku. W konwencjonalnej sieci przemysłowej aplikacje odpytywały urządzenia w celu uzyskania aktualizacji. Jeśli cztery różne aplikacje muszą przechwycić dane z czujników zagregowane przez sterownik PLC, a także sprawdzić jego status, każda z czterech aplikacji odpytywała sterownik PLC. Problem polega na tym, że sprzęt przemysłowy jest budowany z myślą o trwałości, więc zdecydowana większość odczytów jest maszynowym odpowiednikiem “wszystko w porządku”. Wraz ze wzrostem liczby urządzeń, te odczyty status quo zapychają sieć, dodając jednocześnie niewielką wartość.
Dzięki MQTT klient publikujący wysyła dane do brokera tylko wtedy, gdy reprezentują one zmianę powyżej określonego progu. Podejście to rozwiązuje problem “nic mi nie jest”, znacznie zmniejszając ruch sieciowy i pozwalając aplikacjom skoncentrować się na istotnych danych. Klienci wysyłają 16-bitowy komunikat “keep alive” do brokera w określonych odstępach czasu (zazwyczaj 60 sekund), ale nie ma to znaczącego wpływu na przepustowość sieci.
Bliższe spojrzenie na brokera
Protokół MQTT został zaprojektowany do przenoszenia ogromnej liczby pakietów wiadomości przy jednoczesnym minimalizowaniu opóźnień. Aby pomóc osiągnąć te cele, broker jest oprogramowaniem pośredniczącym. W związku z tym może znajdować się na dowolnym serwerze w dowolnej lokalizacji – w chmurze, w siedzibie lub w obu. Jego funkcją jest filtrowanie i przekazywanie wiadomości, dzięki czemu jest wysoce skalowalny. “Pojedynczy broker może skalować się do milionów tematów” – powiedział Benson Hougland, wiceprezes ds. strategii produktowej w Opto 22 (Temecula, Kalifornia). “Jeśli potrzebujesz większej pojemności, po prostu dodajesz kolejnego brokera i możesz równoważyć obciążenie między nimi”. Wiele brokerów można zainstalować w celu automatycznego przełączania awaryjnego, aby zapewnić nieprzerwaną łączność. “Istnieje wiele możliwości, nawet na poziomie brokera, aby zbudować odporną sieć”.
Podstawowy broker MQTT przechowuje tylko najnowsze wartości opublikowane przez aktywnych klientów. Aby utrzymać rekord, implementacja potrzebuje historyka danych lub rejestratora danych subskrybującego odpowiednie ścieżki tematyczne. Tutaj po raz kolejny model pub/sub wnosi wartość, ponieważ historyk może również publikować swoje dane innym subskrybentom, takim jak MES lub zewnętrzny dostawca niezawodności. Alternatywnie, zaawansowany broker MQTT przechowuje swoje wiadomości we wbudowanej bazie danych lub integruje się z bazą danych. The
Cztery opcje łączności MQTT
MQTT zawiera kilka postanowień mających na celu zapewnienie bezpieczeństwa i niezawodności, które są niezbędne dla operacji przemysłowych.
1. Bezpieczeństwo
Jedną z największych zalet modelu klient-broker jest bezpieczeństwo. MQTT musiał zapewnić bezpieczne połączenia, ale dodanie go do kodu byłoby sprzeczne z celem lekkiego transportu wiadomości. Zamiast tego jego twórcy przyjęli inną taktykę. “W MQTT nie zdefiniowano modelu bezpieczeństwa. I to rzeczywiście było celowe” – powiedział Arlen Nipper, prezes i CTO w Cirrus Link (Stillwater, Oklahoma). Pracując dla Arcom Controls, Nipper współpracował z Andrew Stanford-Clarkiem z IBM, aby stworzyć MQTT. “MQTT jest zbudowany na bazie TCP, więc zdecydowaliśmy, że pozwólmy TCP wykonać ciężką pracę. Zastosujmy najlepsze w swojej klasie zabezpieczenia TCP/IP. Obecnie jest to TLS, ale wraz z postępem technologicznym w TCP, MQTT będzie w stanie współpracować z nim natywnie”.
Jedną z obaw związanych z sieciami przemysłowymi zawsze była perspektywa podłączenia zasobów do Internetu. Tutaj do gry wkracza architektura MQTT. Dzięki MQTT urządzenie nawiązuje tylko jedno połączenie – z brokerem. Jedynym otwartym portem w całym systemie jest port brokera, który jest chroniony przez zaporę sieciową. Ponieważ MQTT używa TLS, wszelkie połączenia z tym portem muszą być uwierzytelnione i zaszyfrowane. A ponieważ każdy klient MQTT łączy się z brokerem tylko za pośrednictwem jednego bezpiecznego, uwierzytelnionego połączenia, klient jest chroniony. “Piękno MQTT polega na tym, że nie wymaga on otwierania żadnych portów na kliencie” – powiedział Hougland. Wydawca danych, powiedzmy sterownik PLC z obsługą MQTT, wysyła swoje dane do brokera za pośrednictwem połączenia wychodzącego. “Nie ma połączenia przychodzącego do klienta, więc od samego początku nie ma podatności na cyberbezpieczeństwo”.
Nie oznacza to jednak, że MQTT nie obsługuje komunikacji dwukierunkowej. “Kiedy po raz pierwszy łączymy się z brokerem MQTT, nawiązujemy uwierzytelnione połączenie szyfrowane TLS” – powiedział Hougland. “Jeśli aplikacja SCADA musi wydać polecenie, może to zrobić bezpiecznie za pośrednictwem brokera i z powrotem do sterownika PLC bez otwartych portów. Możemy zweryfikować, czy polecenie pochodzi z zaufanego źródła i zainicjować działanie. Wszystko to odbywa się w ciągu milisekund”.
Bowers powiedział: “Aby upewnić się, że zaufane źródła publikują i subskrybują tematy, broker może zastosować kontrolę dostępu do tematów”.
2. Konfiguracje połączeń
Połączenia klient-broker mogą być zdefiniowane jako czyste lub trwałe:
- Czyste sesje: klient wymienia wiadomości z brokerem przez czas trwania sesji. Gdy połączenie zostaje przerwane, sesja jest zamykana i żadne dane nie są zachowywane.
- Trwałe sesje: broker utrzymuje uwierzytelnioną sesję nawet w przypadku zerwania połączenia. Zachowuje informacje o subskrypcji i przechowuje wszelkie komunikaty QoS 1 lub 2, które są publikowane w buforze. Gdy urządzenie ponownie się połączy, otrzyma te wiadomości w porządku chronologicznym.
Typ sesji jest definiowany w momencie połączenia. Czyste sesje są przydatne do rozwiązywania problemów i monitorowania. Trwałe sesje są szczególnie korzystne w przypadku krytycznej misji i/lub komunikacji dwukierunkowej. Gdy połączenie zostanie zaszyfrowane i uwierzytelnione, klient może bezpiecznie odbierać dane wejściowe bez opóźnień.
3. Jakość usług
MQTT został zaprojektowany ze specjalnymi funkcjami zapewniającymi dostarczanie wiadomości i monitorowanie łączności urządzeń w sieci. Protokół definiuje trzy poziomy jakości usług (QoS):
- QoS 0: opublikuj raz, bez wymaganego potwierdzenia (przynajmniej raz)
- QoS 1: publikuj wielokrotnie do momentu wysłania potwierdzenia (maksymalnie raz)
- QoS 2: publikuj wielokrotnie i zagwarantuj pojedynczy odbiór (dokładnie raz).
Przypisanie QoS dla ścieżki tematu jest częścią konfiguracji klienta. Użytkownicy mają również możliwość skonfigurowania tematu jako zachowanej wiadomości. W takim przypadku broker MQTT będzie przechowywać najnowszą aktualizację otrzymaną dla tej ścieżki tematu. Każdy nowy subskrybent otrzymuje ostatnią zachowaną wiadomość natychmiast po nawiązaniu połączenia, co jest szczególnie korzystne w przypadku komunikowania statusu urządzenia.
Klientów MQTT można również skonfigurować za pomocą wiadomości “ostatniej woli i testamentu” (LWT), która jest wysyłana do brokera po nawiązaniu połączenia. Wszystkie ustawienia LWT obejmują ścieżkę tematu, QoS i wartość timera keep-alive. Gdy klient utraci połączenie z brokerem na czas przekraczający wartość timera utrzymania przy życiu, broker dystrybuuje wiadomość LWT do subskrybentów. Jest to przydatne do powiadamiania klientów, że urządzenie przeszło w tryb offline.
4. Świeca zapłonowa B
Niektóre z tych samych funkcji, które zapewniają MQTT tak dużą elastyczność i konfigurowalność, mogą być problematyczne w środowisku przemysłowym. Na przykład brak konwencji nazewnictwa tematów może sprawić, że budowanie sieci i dodawanie dużej liczby nowych urządzeń od różnych dostawców będzie bardzo pracochłonne. Minimalnie zdefiniowany charakter pakietu MQTT zwiększa elastyczność, ale stanowi również barierę dla interoperacyjności. Aby rozwiązać te i kilka innych problemów, ten sam zespół, który opracował MQTT, stworzył Sparkplug i udostępnił specyfikację społeczności open source, zarządzanej przez Eclipse Foundation. Sparkplug B nie jest odmianą MQTT, ale dodatkiem. Sparkplug B jest dla MQTT tym, czym HTML jest dla HTTP – środkiem do serwowania danych.
Nipper opisuje motywację stojącą za rozwojem Sparkplug B. “Widzieliśmy wiele osób korzystających z MQTT, ale miały one różne przestrzenie nazw tematów i różne definicje ładunku” – powiedział. “Specyfikacja Sparkplug w ogóle nie zmienia MQTT. Wszystko, co mówi, to hej, jeśli zamierzasz stworzyć operacyjny system czasu rzeczywistego o znaczeniu krytycznym, to prawdopodobnie jest to dobre miejsce na rozpoczęcie”.
Sparkplug B to szczegółowa specyfikacja, ale tutaj podkreślamy kilka kluczowych aspektów:
