Przemysłowy Internet Rzeczy (IIoT) oraz informatyczne systemy nadzorujące przebieg procesu technologicznego lub produkcyjnego (SCADA) mogą usprawnić operacje realizowane w aplikacjach przemysłowych.
Termin SCADA (Supervisory Control And Data Acquisition), czyli nadzór i akwizycja danych, odnosi się do zestawu aplikacji oprogramowania dla przemysłu, które mogą być skonfigurowane tak, aby wspierały zarządzanie prawie każdym rodzajem produkcji dyskretnej lub procesowej. Systemy SCADA znajdują się wszędzie, gdzie konieczna jest agregacja danych dotyczących sterowanego procesu przemysłowego lub koordynacja operacji związanych z takim procesem produkcyjnym.
Czy w świecie automatyki przemysłowej, podlegającym znacznym przeobrażeniom i reorganizacji związanej z ekspansją nowych technologii Przemysłowego Internetu Rzeczy, rola systemów SCADA zmieni się lub osłabnie?
Odpowiedź brzmi „nie”. W rzeczywistości IIoT poprawia działanie systemów SCADA, nawet zanim zostaną one włączone do sieci internetowej lub chmury. Wykorzystanie tzw. lekkiego protokołu transmisji danych – MQTT (Message Queueing Telemetry Transport), w połączeniu z narzędziami brokerów informacji w oprogramowaniu pośredniczącym zorientowanym na przetwarzanie komunikatów (Message-Oriented Middleware – MOM), „modernizuje” infrastruktury systemów SCADA. Jeżeli istnieje możliwość sięgnięcia po łączność w sieci IIoT, to zamiast inwestowania zasobów w ponowne opracowanie, ponowną integrację i reorganizację systemu SCADA opartego na protokołach liczących sobie 35 lat, lepiej poświęcić czas na opracowywanie aplikacji wykorzystujących zalety np. technologii chmury i zaawansowanego przetwarzania danych oraz analityki.
Innymi słowy technologie IIoT mogą niejako przeskoczyć nad istniejącymi, przestarzałymi infrastrukturami oraz obecnie zainstalowaną bazą urządzeń z rozwiązaniami i strategiami migracji, które działają w połączeniu z nimi. Już dzisiaj zainstalowane na poziomie obiektowym urządzenia brzegowe zapewniają łączność z istniejącymi sterownikami PLC, czujnikami bezprzewodowymi oraz innymi węzłami sieci i publikują zmienne procesowe w czasie rzeczywistym, wykorzystując protokół MQTT.
MQTT to dwukierunkowy, lekki, z wywoływaniem zdarzeniowym, zorientowany na przetwarzanie komunikatów protokół transportowy danych, który umożliwia wydajną komunikację urządzeń z systemami backendowymi (najbardziej oddalonymi od klienta) poprzez sieci z ograniczoną przepustowością. Protokół MQTT eliminuje tzw. protokoły odpytywania cyklicznego (poll/response), zaś poprzez wdrożenie dojrzałych technologii MOM systemy SCADA połączone z siecią IIoT udostępniają szerszemu kręgowi odbiorców dane dotyczące urządzeń. Urządzenia nie są już dłużej bezpośrednio połączone z aplikacją SCADA, zostają skutecznie od niej oddzielone. System SCADA oparty na zasadach MOM redukuje czas oczekiwania na kluczowe dane dotyczące sterowania i pomiarowe.
Aktualna przepustowość sieci – w porównaniu z poprzednio wymaganą dla protokołów odpytywania cyklicznego – jest zredukowana nawet o 85%. Dzięki temu informacje, które są często pozostawione bezużytecznie w urządzeniach, stają się dostępne. Ponadto zapewnia to pojedynczy punkt zarządzania bezpieczeństwem dla urządzeń i aplikacji obiektowych, upraszcza topologię infrastruktury dla celów redundancji, zwiększa dostępność i skalowalność oraz eliminuje budzące niejednokrotnie strach przejścia z jednej wersji SCADA na inną. Zapewnia także oddzielenie urządzeń, wymagane dla dodatkowego umożliwienia pracy w sieci IIoT.
Implementacja istniejących systemów SCADA
Typowy, prawidłowo wybrany pod względem sprzętu system SCADA obejmuje komputerowe stacje robocze, programowalne sterowniki logiczne PLC oraz oprzyrządowanie modułów wejść i wyjść systemowych (I/O). Innymi elementami systemu SCADA są: rozproszona baza danych i znaczniki (tagi) lub punkty danych. Każdy znacznik reprezentuje pojedynczą wartość wejściową lub wyjściową systemu.
Pętla sprzężenia zwrotnego sterowania procesem jest realizowana przez sterownik PLC, podczas gdy system SCADA monitoruje jej działanie. Oznacza to, że sterowniki PLC przyjmują jakieś parametry sterowania, zaś operatorzy monitorują wyniki i np. zmieniają punkty nastaw. Może występować brak komunikacji typu peer-to-peer pomiędzy sterownikami.
Systemy SCADA zasadniczo nie zmieniły się w ciągu ostatnich czterdziestu lat. Sprzęt i systemy operacyjne zostały ulepszone, zgodnie z prawem Moore’a, jednak infrastruktura i sposób przesyłania informacji do systemu z urządzeń i czujników pozostały w dużym stopniu takie same.
W większości systemów SCADA nadal znajdziemy system hostujący, bezpośrednio połączony szeregowo z dowolnym urządzeniem obiektowym wykorzystującym protokoły odpytywania cyklicznego. Te sterowniki protokołów odpytywania cyklicznego narzucają bezpośrednie łączenie urządzeń z aplikacją hosta SCADA.
Z punktu widzenia operacji systemy te się sprawdziły. Z drugiej strony, funkcje biznesowe potrzebują często dostępu do danych, których dostarczają urządzenia inteligentne i czujniki. Aby zapewnić ten dostęp, w tablicach hosta SCADA muszą być umieszczone dodatkowe cykliczne mechanizmy odpytywania (polls). Dostęp do danych wymaga dodatkowych aplikacji. Muszą być podane parametry odnoszące się do bezpieczeństwa i kontroli dostępu. Operacje muszą zarządzać dodatkowymi odpytywaniami cyklicznymi i unikać wszelkich negatywnych wpływów na prędkość aktualizacji.
System SCADA zbiera teraz dane, nie zawsze mu potrzebne – tylko po to, aby przekazać je do innych aplikacji. Z czasem jako element koordynacji operacji SCADA funkcjonuje coraz bardziej jak oprogramowanie pośredniczące, przetwarzające komunikaty, chociaż nigdy nie miało takim być. A ponieważ aplikacja hostująca SCADA ewoluuje, staje się trudna do zarządzania. Stąd wysiłki mające na celu uzyskanie korzyści z dodatkowych informacji zbieranych z urządzeń obiektowych zmierzają ku końcowi.
Na drodze adaptacji nowych technologii przeszkodą są także dawne praktyki bezpośredniego podłączania urządzeń do systemu SCADA, z wykorzystaniem sieci protokołów odpytywania cyklicznego. Po wdrożeniu protokołu użytkownicy stają przed dylematem, co stanie się, gdy będzie dostępna nowa technologia. W nowych urządzeniach mogą się pojawić protokoły nieobsługiwane przez istniejący system SCADA. Nie można sprawdzić i ocenić działania alternatywnego hosta SCADA równolegle z istniejącym hostem na funkcjonującym już systemie. Podłączanie urządzeń do aplikacji przy wykorzystaniu protokołów odpytywania cyklicznego może być stosowane do tworzenia rozwiązań tymczasowych, gdyż są one później trudne do zaktualizowania.
**********
Kilka uwag na temat protokołu MQTT
Protokół MQTT został po raz pierwszy użyty w latach 90. XX wieku, w mającym kluczowe znaczenie systemie czasu rzeczywistego SCADA, działającym w przemyśle ropy i gazu. Dla większości takich systemów podstawę sieci komunikacyjnej stanowiła technologia nadawania sygnału telewizyjnego VSAT (Very Small Aperture Terminal), a zatem jej przepustowość była minimalna. Wykorzystanie w systemach SCADA protokołu MQTT okazało się być atrakcyjne, ponieważ jest on:
→ natywnie wbudowany na szczycie stosu protokołów TCP/IP, z umożliwieniem realizacji sesji TCP/IP po stronie klienta;
→ prosty do zrozumienia i do wdrożenia;
→ wydajny pod względem przepustowości sieci;
→ niedookreślony pod względem danych – może działać z różnymi systemami.
Jeśli wyeliminuje się HTTP jako opłacalny protokół transportowy dla systemu SCADA (ponieważ jest on bezstanowy i wymaga dużej przepustowości), pojawia się wtedy MQTT jako opłacalny protokół transportowy dla szerokiego obszaru aplikacji IIoT. Dodatkowo MQTT został oryginalnie zaprojektowany dla infrastruktury VSAT SCADA. Pozwala 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 w 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.
**********
Możliwości modernizacji systemu SCADA
Wykorzystując urządzenia sieciowe, które natywnie wdrażają protokół MQTT, można zbudować system SCADA oparty na technologii MOM, jak pokazano na rys. 3. Zachowane są komponenty istniejącej infrastruktury odpytywania cyklicznego. Zasadniczą zmianą topologii sieci staje się dodanie serwera MQTT.
Istniejące urządzenia obiektowe mogą obsługiwać protokół MQTT, wykorzystując dostępne urządzenia typu brzegowa brama sieciowa (edge-of-network gateway), stosujące natywny protokół odpytywania cyklicznego, a następnie konwertują informacje dotyczące zmiennych rejestrowych/procesowych na komunikaty MQTT, publikowane w czasie rzeczywistym na zasadzie raportowania wyjątków (report-by-exception).
W dostępnych obecnie urządzeniach SCADA natywnie zainstalowano protokół MQTT, mogą więc być one natychmiast dodane do istniejącej infrastruktury. Wykorzystanie technologii MOM oznacza, że urządzenia końcowe publikują wszystkie dane operacyjne w czasie rzeczywistym, do wykorzystania przez system SCADA, i inne zintegrowane funkcje biznesowe. Również metadane, informacje dotyczące zasobów, diagnostyczne, konfiguracyjne czy inne dane – wszystkie są dostępne w czasie rzeczywistym.
Host SCADA we współczesnych aplikacjach systemowych jest oddzielony od zdalnych urządzeń obiektowych. System nie jest ograniczony przez jakąś specyficzną implementację protokołu odpytywania cyklicznego lub aplikację hosta SCADA. W nowoczesnych architekturach systemowych istnieje relacja „jeden do wielu” (one-to-many) między publikowanymi danymi z urządzeń obiektowych a aplikacjami zainteresowanymi subskrybowaniem tych informacji. Host SCADA może w 100% skoncentrować się raczej na byciu hostem niż nie w pełni spełniającym swe funkcje oprogramowaniem pośredniczącym – jego funkcjonowanie w takiej roli nie było nigdy planowane. Wszystkie połączenia urządzeń zdalnych z brokerem MQTT są nawiązywane po stronie klienta, zaś wszystkie urządzenia zdalne – przy założeniu normalnego działania – są łączone równocześnie.
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ść, obsługujący większą ilość danych.
**********
Zalety 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 aplikacji. 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 ze sobą sprzężone, 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 pozostaje niesprecyzowany. Mógłby on być plikiem binarnym JPEG lub dokumentem XML. Transport wiadomości pozwala 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.
**********
Przygotowanie do wdrożenia nowego systemu
Protokół MQTT został po raz pierwszy wydany w 1999 r. jako protokół transportowy danych, zorientowany na systemy SCADA. Na szerszych rynkach pozostał jednak w dużym stopniu nieznany. W ciągu ostatnich pięciu lat jego wykorzystanie w rozwiązaniach związanych z wdrożeniem IIoT zyskało jednak znaczną akceptację. Chodzi o to, że każdy obecny na współczesnym rynku produkt typu „oprogramowanie pośredniczące zorientowane na przetwarzanie komunikatów” 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. Producenci urządzeń SCADA, dostawcy platform deweloperskich i rozwiązań końcowych zapowiedzieli wbudowanie pewnego stopnia obsługi MQTT w swoich produktach.
Wraz z pojawiającym się i dostępnym ekosystemem producenci urządzeń, deweloperzy SCADA, integratorzy systemów i użytkownicy końcowi mogą tworzyć własne infrastruktury obsługujące protokół MQTT – podstawę do wycofywania się z systemów opartych na istniejących, starszych protokołach odpytywania cyklicznego. Technologia MOM jest przetestowana, wdrażana i akceptowana w branży informatycznej. Zastosowanie jej w systemach SCADA wykorzystujących protokół MQTT może zaowocować nowoczesnym wdrożeniem, zapewniającym najlepsze dostępne parametry, wykorzystując więcej standardowych komponentów dostępnych od ręki, przy jednoczesnym zmniejszeniu wymogów dotyczących dostosowania do użytkownika oraz integracji aplikacji działających w bezpośrednim otoczeniu hosta SCADA. Dodatkowo możemy uzyskać dostęp do inteligentnych urządzeń obiektowych, co da się wykorzystać w aplikacjach specyficznych dla działalności prowadzonej przez firmę, bez wywierania wpływu lub modyfikowania aplikacji hosta SCADA.
Autor: Arlen Nipper jest prezesem i dyrektorem generalnym ds. technicznych firmy Cirrus Link Solutions.