W ciągu ostatniej dekady urządzenia obiektowe stały się „bardziej inteligentne”, jednak większość z tej dodatkowej inteligencji pozostaje niewykorzystana. Topologia pokazana na rys. 4 przedstawia nowoczesny system SCADA ze zredukowanym zapotrzebowaniem na przepustowość, umożliwiający obsługę większej ilości danych.
Przygotowanie do wdrożenia nowego systemu
Protokół MQTT został po raz pierwszy wydany w 1999 r. jako protokół transportowy danych, zorientowany na systemy SCADA, jednak pozostał w dużym stopniu nieznany na szerszych rynkach. Ale w ciągu ostatnich 4 lat jego wykorzystanie w rozwiązaniach zorientowanych na implementację technologii IIoT zyskało znaczną akceptację. Chodzi o to, że każdy produkt typu oprogramowanie pośredniczące zorientowane na przetwarzanie komunikatów, obecny na współczesnym rynku, natywnie obsługuje protokół MQTT. Dla tego protokołu są dostępne zarówno narzędzia typu open-source, jak i tutoriale oraz informacje techniczne. W ciągu ostatnich 18 miesięcy producenci urządzeń SCADA, dostawcy platform deweloperskich i rozwiązań końcowych zapowiedzieli wbudowanie pewnego stopnia obsługi MQTT w swoich produktach.
Aby dostarczyć wytyczne i najlepsze praktyki dla wdrażania systemów SCADA zorientowanych na przetwarzanie komunikatów (MOM-centric SCADA) oraz strategii migracji wymaganych dla większości istniejących starszych systemów, firma Cirrus Link Solutions opracowała otwartą specyfikację o nazwie “Sparkplug” (“świeca zapłonowa”), która definiuje wydajny system SCADA, oparty na protokole MQTT. Sparkplug definiuje standaryzowane komponenty, które są wymagane dla urządzeń i aplikacji, w celu efektywnego wykorzystania MQTT w systemach SCADA czasu rzeczywistego, w kategoriach tematycznych przestrzeni nazw, definicji danych właściwych i zarządzania stanem sesji.
Specyfikacja ta jest dostępna publicznie w internetowym serwisie Github, wraz z prostym, referencyjnym kodem implementacji w językach C, Java, JavaScript i Python. Podano przykłady wykorzystania dla popularnego narzędzia wizualnego Node-RED, służącego do tworzenia połączeń w sieciach IIoT. Wykorzystanie specyfikacji Sparkplug dla wydajnego przesyłania komunikatów i zarządzania stanem sesji umożliwia dostawcom rozwiązań hostów SCADA oraz producentom urządzeń końcowych, bezproblemową komunikację z rozwiązaniami SCADA czasu rzeczywistego. Aplikacje mogą “łączyć się” z infrastrukturą, aby szybko uzyskiwać dostęp do informacji w czasie rzeczywistym.
Aplikacje do referencyjnych implementacji Sparkplug mogą być wykonywane na platformie sprzętowej Raspberry Pi, podłączonej do dowolnego serwera MQTT z otwartym kodem źródłowym. Infrastruktury kontroli jakości wyrobów mogą być tworzone przy wykorzystaniu rozwiązań już implementujących specyfikację Sparkplug, w tym rozwiązań firm: Inductive Automatiom, Node-RED, Advantech, Elecsys, Hilscher, Magnetrol, Moxa, Opto 22, and Tyrion.
Wraz z tym pojawiającym się i dostępnym ekosystemem, producenci urządzeń, deweloperzy oprogramowania SCADA, integratorzy systemów oraz użytkownicy końcowi mogą teraz tworzyć własne infrastruktury obsługujące protokół MQTT, będące podstawą do wycofywania się z systemów opartych na istniejących, starszych protokołach odpytywania cyklicznego. Technologia MOM jest dobrze przetestowana, wdrażana i akceptowana w branży informatycznej. Zastosowanie jej w systemach SCADA wykorzystujących protokół MQTT daje w wyniku wdrożenie, które jest nowoczesne i posiada najlepsze obecnie dostępne parametry, wykorzystując więcej standardowych komponentów dostępnych od ręki, przy jednoczesnym zmniejszeniu wymogów w zakresie dostosowania do użytkownika oraz integracji aplikacji działających w bezpośrednim otoczeniu hosta SCADA. Dodatkowo może być uzyskany dostęp do inteligentnych urządzeń obiektowych, co może być wykorzystane w aplikacjach specyficznych dla działalności prowadzonej przez firmę, bez wywierania wpływu lub modyfikowania aplikacji hosta SCADA.
Zalety wykorzystywania oprogramowania pośredniczącego, zorientowanego na przetwarzanie komunikatów
Używane w sektorze informatyki od ponad dekady oprogramowanie pośredniczące, zorientowane na przetwarzanie komunikatów (MOM), sprzyja rozdzielaniu aplikacje. Systemy oparte na starszych technologiach informatycznych działały w dużym stopniu podobnie do współczesnych systemów SCADA, wykorzystujących protokoły odpytywania cyklicznego. Aplikacje były ściśle sprzężone ze sobą, wykorzystując definicję protokołu do określania sposobu komunikowania się aplikacji A z aplikacją B. Jako rozwiązanie tymczasowe działało to dobrze. Ale w miarę upływu czasu, ścisłe sprzęganie i ścisłe definicje uczyniły aktualizowanie istniejących aplikacji IT zadaniem trudnym, jeśli nie niemożliwym.
Z drugiej strony za pomocą technologii MOM, aplikacje publikują dane bez zwracania uwagi na to, kto subskrybuje te dane. Deweloperzy oprogramowania koncentrują się na tworzeniu aplikacji wartości dodanej (value-add applications), które publikują i subskrybują dane w granicach infrastruktury MOM.
Ponadto w technologii MOM fragment przesyłanych danych, będący formą wiadomości (payload), jest definiowany przez temat wiadomości, a nie przez protokół, co oznacza że ten fragment wiadomości MOM jest agnostyczny. Mógłby on być plikiem binarnym JPEG lub dokumentem XML. Transporty wiadomości pozwalają deweloperom publikować w formacie, który jest najbardziej sensowny dla danego rozwiązania bez ograniczeń ze strony jakiejkolwiek definicji protokołu.
Ta sama infrastruktura powinna być wykorzystana dla systemów SCADA z obsługą sieci IIoT. Architektury SCADA zorientowane na technologię MOM, pozwalają urządzeniom na przesyłanie danych w czasie rzeczywistym na centralny serwer MOM. Aplikacja hosta SCADA uczestniczy w tym, jako subskrybent zmiennych procesowych czasu rzeczywistego oraz czynnik publikujący polecenia dla urządzeń. Ponadto przerywa ona błędne koło rozwoju i wspierania protokołu, ponieważ mogą być tworzone dodatkowe tematy wiadomości, według zmieniających się wymagań dotyczących danego rozwiązania.
Kilka uwag na temat protokołu MQTT
Protokół MQTT został po raz pierwszy użyty w posiadającym kluczowe znaczenie systemie czasu rzeczywistego SCADA w przemyśle ropy i gazu. Dla większości takich systemów technologia nadawania sygnału telewizyjnego VSAT (very small aperture terminal) była podstawową wykorzystywaną w sieci komunikacyjnej, a zatem jej przepustowość była minimalna. Protokół MQTT okazał się być atrakcyjny do wykorzystania w systemach SCADA, ponieważ jest on:
- Natywnie wbudowany na szczycie stosu protokołów TCP/IP, z umożliwieniem realizacji sesji TCP/IP po stronie klienta
- Stanowy (stateful), ze stałą świadomością sesji
- Wydajny pod względem przepustowości sieci
- Agnostyczny pod względem danych (data-agnostic, może działać z różnymi systemami)
- Prosty w zrozumieniu i we wdrożeniu
Jeśli wyeliminuje się HTTP jako opłacalny protokół transportowy dla systemu SCADA, ponieważ jest on bezstanowy (stateless) i wymaga dużej przepustowości, to pojawia się wtedy MQTT, jako opłacalny protokół transportowy dla szerokiego obszaru aplikacji IIoT. Dodatkowo MQTT został oryginalnie zaprojektowany dla infrastruktury VSAT SCADA. Pozwala on na optymalizację segmentów przestrzeni VSAT pod względem liczby zdalnych miejsc w zakresie segmentu przestrzeni.
A zatem, po ustanowieniu sesji klienta MQTT, całkowita wielkość metadanych typu overhead dla wiadomości to tylko trzy bajty. Ponadto MQTT w pełni wykorzystuje leżącą poniżej warstwę transportową TCP/IP. Oznacza to, że protokół MQTT jest ekstremalnie lekki i mało wymagający pod względem przepustowości, szczególnie dla topologii VSAT i sieci komórkowych. Dla systemów SCADA na hali fabrycznej może to oznaczać wielką redukcję ruchu w sieci.
Protokół MQTT jest obecnie globalnym standardem, wspieranym przez kilka wiodących organizacji normalizacyjnych, w tym OASIS, ISO i IEC.
Autor: Arlen Nipper – prezes i dyrektor generalny d/s technicznych firmy Cirrus Link Solutions.