Rozwój systemów Przemysłowego Internetu Rzeczy (IIoT) jest nieunikniony. Sprawą kluczową jest zrozumienie, które technologie połączeń sieciowych powinny być wykorzystywane w jego aplikacjach.

Konsorcjum Przemysłowego Internetu Rzeczy (IIC – Industrial Internet Consortium – organizacja non profit utworzona przez pięć czołowych firm z sektora IT), po dwóch latach analizowania różnych technologii dedykowanych dla aplikacji IIoT, opublikowało niedawno dokument o nazwie „Podstawowe Zasady Połączeń Sieciowych Przemysłowego Internetu Rzeczy” (IICF – Industrial Internet Connectivity Framework). W raporcie tym zawarto spostrzeżenia i opinie ekspertów, w tym przedstawicieli czołowych konsorcjów przemysłowych, wielu firm, a także informacje o najważniejszych standardach sieciowych.

Najbardziej zaskakującą konkluzją konsorcjum jest to, że Przemysłowy Internet Rzeczy to pojęcie i koncepcja naprawdę wielka. Jest ona tak wielka, że technologie stosowane w różnych obszarach i aplikacjach IIoT nie nakładają się.

W efekcie projektanci aplikacji systemowych dla IIoT mogą pomyśleć o wybraniu dowolnego standardu połączeń sieciowych, takiego jak DDS, OPC UA, MQTT lub oneM2M, i odnieść sukces. Ale wynika z tego błędne przekonanie, że w przestrzeni rozwiązań połączeń sieciowych dla IIoT występuje nakładanie się technologii, jak pokazano na rys. 1.

Rys. 1. Diagram pokazujący powszechne błędne przekonanie, że wiele technologii spełnia wymagania w przestrzeni połączeń sieciowych IIoT. Możliwymi opcjami wyboru, biorąc pod uwagę każdą aplikację (X oznacza naszą aplikację), są B lub C. Jeśli te technologie w rzeczywistości nakładają się, to będzie działała albo B albo C.

Rzeczywistość jest jednak zupełnie inna. Technologia IIoT obejmuje wiele gałęzi przemysłu i wiele przypadków użycia (use cases) – aplikacji, w tym automatykę przemysłową, robotykę, samochody autonomiczne, lotnictwo, produkcję, sterowanie procesami, duże elektrownie i dystrybucję energii odnawialnej. To tylko kilka przykładów z setek firm i tysięcy aplikacji w przestrzeni IIoT.

Dlatego właśnie w rzeczywistości przestrzeń IIoT jest tak wielka, że opcje technologiczne rzadko się nakładają, jeśli w ogóle. Współcześnie wyzwaniem dla wyboru architektury sieciowej w przestrzeni IIoT nie jest zatem to, że nie tylko jedna z wybieranych nakładających się technologii może całkiem rozwiązać problem. Wyzwaniem jest zrozumienie tych technologii, porównanie ich zamierzonych obszarów aplikacyjnych i wybór takiej, która najlepiej pasuje do specyficznych wyzwań dla danej aplikacji. Na pewno rozciąganie obszarów aplikacyjnych jakiejś technologii poza wszelkie proporcje może sprawić, że wszystko będzie działać. Ale będzie to wymagało dużo dodatkowej pracy i projektu, który w efekcie końcowym nie jest optymalnym rozwiązaniem. Jeśli poszukujemy bardziej realistycznej mapy sytuacji, to lepszym rozwiązaniem będzie pokazany na rys. 2 rozrzucony diagram Venna, niż nakładające się obszary pokazane na rys. 1.

Brak nakładania się różnych technologii wykorzystywanych w przestrzeni IIoT właściwie znacznie upraszcza pracę architekta sieci. Rzeczywistym problemem nie jest wybór pomiędzy podobnymi opcjami, tylko zrozumienie bardzo różniących się od siebie opcji i przezwyciężenie swoich uprzedzeń. Dokument IICF bezpośrednio zajmuje się tym problemem.

Rys. 2. Diagram Venna jest bliższy rzeczywistości, niż pokazany na rys. 1. Okazuje się, że technologie połączeń sieciowych nie nakładają się na siebie. Większość aplikacji może tylko logicznie wykorzystać jedną technologię. Wyzwaniem jest często wybranie rozwiązania niedoskonałego, jego dopasowanie i wdrożenie.

Wybór technologii dla IIoT

Przeanalizujmy ten proces nieco dokładniej. Można odpowiedzieć sobie na kilka pytań na temat każdej opcji wyboru technologii i szybko zawęzić dostępne opcje. Pytania te mogą w pewien sposób nazbyt uprościć problem, jednak są one świetnym punktem startowym. Dokument IICF identyfikuje cztery potencjalne „podstawowe standardy połączeń sieciowych”: DDS, OPC UA, oneM2M, i RESTful HTTP. Pierwsze trzy z nich przeanalizowano poniżej. RESTful HTTP (REST – Representational State Transfer, zmiana stanu poprzez reprezentację) jest dobrze znany, więc nie opisano go w artykule. Natomiast zdecydowano się na przeanalizowanie protokołu MQTT ze względu na jego popularność, mimo że nie kwalifikuje się jako „podstawowy standard połączeń sieciowych” według IICF, ponieważ nie ma żadnego standardowego systemu typowania struktur danych, wymaganego dla interoperacyjności.

DDS

DDS (Data Distribution Services, usługi dystrybucji danych, standard opracowany przez konsorcjum Object Management Group) to standard, który opisuje platformę programową Databus („szyna danych”). Oprogramowanie Databus steruje zorientowanym na dane przepływem informacji w sieci IIoT. Jest to koncepcja podobna do bazy danych, która oznacza zorientowane na przechowywanie informacji. Podstawową różnicą jest to, że baza danych zapisuje stare informacje, które mogą być wyszukiwane za pomocą relatywnych właściwości zapisanych danych. Natomiast Databus zarządza przyszłymi informacjami poprzez filtrowanie danych przychodzących, na podstawie ich właściwości. W tej koncepcji należy zarówno zrozumieć treść danych i pozwolić aplikacjom oddziaływać bezpośrednio bardziej na te dane i poprzez te dane, niż ze sobą wzajemnie. Aplikacje wykorzystujące bazę danych lub Databus nie mają bezpośredniego powiązania z aplikacjami peer-to-peer.

Mając wiedzę na temat struktury, treści i oczekiwań wobec danych, oprogramowanie Databus może zarządzać ich przepływem. Może na przykład rozwiązywać problem nadmiarowości danych, eliminując powtarzające się aktualizacje. Databus może kontrolować parametry jakości usługi (QoS – Quality of Service), takie jak prędkość aktualizacji, niezawodność i gwarantowane powiadomienia o przesyłaniu danych na żywo (data liveliness, trwający obecnie przesył danych niebędący odtworzeniem danych uprzednio zapisanych). Może przeglądać aktualizacje i optymalizować sposób ich wysyłania lub podejmować decyzje o niewysyłaniu ich w ogóle. Może także odkrywać, kontrolować i zabezpieczać przepływy danych, oferując je aplikacjom i podobnym narzędziom generycznym. Taki zarządzany dostęp do danych bardzo ułatwia integrację i skalowanie systemu.

OPC UA

Celem technologii OPC UA (OPC Unified Architecture) jest przede wszystkim zagwarantowanie interoperacyjności urządzeń. Przed wprowadzeniem OPC UA (lub jej poprzednika OPC, OLE for process control), aplikacje po prostu uzyskiwały dostęp do urządzeń bezpośrednio za pomocą firmowych interfejsów API (Application Programming Interface, interfejsów programistycznych aplikacji), dostarczanych przez producentów urządzeń. Niestety oznaczało to, że aplikacje stawały się zależne od urządzenia, którym sterowały. Co gorsza, aplikacje wyższego poziomu, takie jak interfejsy operatorskie (HMI – Human-Machine Interfaces) nie miały łatwej drogi do odnalezienia różnych urządzeń w fabrykach, połączenia się z nimi lub sterowania nimi.

Standard OPC UA dzieli oprogramowanie systemowe na klientów i serwery. Serwery zwykle rezydują w urządzeniu lub programowalnym sterowniku logicznym (PLC – Programmable Logic Controller) wyższego poziomu. Umożliwiają one dostęp do urządzenia poprzez standardowy „model urządzenia”. Istnieją standardowe modele dla wielu typów urządzeń, od czujnika do regulatorów. Każdy producent jest odpowiedzialny za dostarczenie takiego serwera, który mapuje model urządzenia generycznego dla swojego konkretnego urządzenia. Serwery te prezentują obiektowo zorientowany, zdalnie wywoływany interfejs API, który wdraża model urządzenia.

Klienci mogą się połączyć z urządzeniem i wywoływać funkcje z generycznego modelu urządzenia. W ten sposób oprogramowanie klienckie jest niezależne od aktualnego urządzenia, zaś pracujący w fabryce integratorzy systemów mogą dowolnie wybierać producentów lub modele urządzeń czy modułów automatyki według potrzeb. Tak więc OPC UA umożliwia połączenia sieciowe, które są wymagane do sterowania systemem. Należy zauważyć, że model urządzenia umożliwia także poziom interoperacyjności „semantycznej”, ponieważ model urządzenia definiuje interfejsy API obiektu generycznego w znanych jednostkach i określonych punktach odniesienia.

OneM2M

Standard oneM2M (opracowany przez organizację o tej samej nazwie, która zajmuje się m.in. technologią wymiany informacji pomiędzy maszynami, M2M – Machine-to-Machine) wynika ze współpracy pomiędzy wieloma dostawcami urządzeń mobilnych i bezprzewodowych. Dotyczy on sieci urządzeń mobilnych, które komunikują się głównie/wyłącznie poprzez infrastrukturę stacji bazowych.

Podstawowym przeznaczeniem oneM2M jest zdefiniowanie usług, które mogą być wykorzystane przez urządzenia mobilne do współpracy i integracji. Jeśli zamierzamy otwarcie wykorzystać te usługi, to musimy się z nimi połączyć. Będą one uruchomione w warstwie platformy (chmurze obliczeniowej) połączonej z urządzeniami, zwykle za pomocą infrastruktury sieci komórkowej. Inne technologie także wykorzystują ruch sieciowy IP w sieci komórkowej, jednak zwykle także w dużym stopniu w swoich projektach wykorzystują technologie sieciowe LAN, lokalnych sieci bezprzewodowych lub WAN.

MQTT

MQTT (MQ Telemetry Transport) jest prostym protokołem przeznaczonym głównie do „zbierania danych”. Nie kwalifikuje się on jako „podstawowy standard połączeń sieciowych” według wytycznych IICF, ponieważ nie ma żadnego standardowego systemu typowania struktur danych. W ten sposób może obsługiwać tylko przesył danych nieprzejrzystych (opaque data), a nie typowane struktury danych. Bez systemu typowania protokół ten nie potrafi zaoferować standardowej i wymaganej interoperacyjności na „syntaktycznym” poziomie struktury danych.

Niemniej jednak MQTT cieszy się znaczną popularnością z powodu swojej prostoty. Dlatego też w procesie decyzyjnym odpowiedzi na kilka pytań dotyczących systemu sieciowego w danej aplikacji pomogą w określeniu, czy MQTT będzie w danym przypadku dobrym rozwiązaniem.

Współpraca systemów i technologii

Większość wytycznych IICT jest dedykowana architekturze integracji tych technologii. Jest to sprawa kluczowa dla pojawienia się „internetowej” części IIoT. Architektura referencyjna wymaga opartych na standardach podstawowych bram sieciowych pomiędzy podstawowymi standardami połączeń sieciowych.

Kiedyś w przyszłości zostaną wykonane integracje, np. systemu produkcyjnego z transportem i energetyką. Złożone oprogramowanie autonomiczne dokona ponownej konfiguracji gniazd roboczych, tworząc odważny nowy świat dla producentów urządzeń i komponentów. Systemy bezprzewodowe 5G będą współpracować ze sterownikami ruchu bezkolizyjnego (ang. freeway controllers) i pojazdami autonomicznymi. Sieć bezprzewodowa 5G może nawet bezpośrednio sterować urządzeniami w fabrykach, eliminując potrzebę układania przewodów i kabli.

Jednak projektanci powinni przeanalizować rozległość przestrzeni IIoT. Obecnie istnieje kilka konkretnych potrzeb, aby zlikwidować ogromne różnice pomiędzy wykorzystywanymi w systemowych aplikacjach przemysłowych technologiami połączeń. Nie oznacza to, że przemysł nie reaguje na tę oczywistą potrzebę. Na przykład niedawno na komputerze testowym IIC zademonstrowano „most” pomiędzy standardami DDS a OPC UA. W perspektywie długoterminowej tego typu integracje umożliwią większym systemom łączenie technologii. Obecnie projektanci muszą zrozumieć te duże różnice pomiędzy technologiami, żeby wybrać najbardziej optymalne rozwiązanie.

Dr Stan Schneider jest dyrektorem generalnym firmy Real-Time Innovations Inc. oraz członkiem Komitetu Sterującego Konsorcjum Przemysłowego Internetu Rzeczy.

Redakcja: Control Engineering Polska