Opcje protokołu warstwy aplikacji dla komunikacji maszyna-maszyna (M2M) i Internetu rzeczy (IoT)

Wraz z popularyzacją funkcji Internetu rzeczy (IoT) i Przemysłu 4.0 urządzenia są coraz częściej łączone za pośrednictwem protokołów przemysłowych. Co więcej, w dzisiejszym świecie komunikacja maszyna-maszyna (M2M) szybko dostosowuje się do tych protokołów. Sprawę komplikuje fakt, że protokoły IoT nie opisują pojedynczego protokołu warstwy aplikacji, ponieważ funkcjonuje kilka standardów. Tak więc, chociaż we wczesnych implementacjach IoT wykorzystywano standardowe protokoły internetowe, obecnie dostępne są również dedykowane protokoły IoT.

Modelowanie struktur komunikacyjnych i identyfikacja odpowiedniego protokołu dla określonego zastosowania mogą być zniechęcające. W niniejszym artykule opisano sposób działania poszczególnych protokołów, a także dostępne dla nich opcje, co pozwoli inżynierom-projektantom łatwiej wybrać protokół najbardziej odpowiadający ich potrzebom.

Ilustracja 1: funkcje przemysłowego Internetu rzeczy (IIoT) w automatyce przemysłowej opierają się na coraz lepiej połączonych urządzeniach wykorzystujących protokoły przemysłowe do tworzenia sieci. Odseparowane warstwy tych sieci nie wymagają znajomości podstawowych funkcji warstw. Dlatego inżynieria projektowa w tak dużym stopniu koncentruje się na górnej warstwie sieci (aplikacji) maszyn. (Źródło ilustracji: Getty Images)

Definiowanie protokołu warstwy aplikacji dla sieci przemysłowych

Struktury protokołów komunikacyjnych dla cyfrowych systemów komunikacji maszyna-maszyna (M2M) w ramach Internetu rzeczy dzielą się koncepcyjnie na abstrakcyjne warstwy, przy czym najpopularniejsze modele mają trzy, cztery, pięć lub siedem warstw. Te ramy koncepcyjne zakładają, że każda warstwa zasadniczo „ukrywa” szczegółowe działanie danego urządzenia lub warstwy oprogramowania przed innymi urządzeniami lub algorytmami, z którymi się komunikuje. Dzieje się tak, ponieważ warstwy są zdefiniowane jako zawierające wystarczającą ilość informacji do wymiany danych.

Ilustracja 2: tradycyjne architektury systemów są hierarchiczne, ale przetwarzanie w chmurze i mgle zatarło granice między funkcjami komponentów. To skłoniło do zastosowania nowych modeli protokołów sieciowych. (Źródło ilustracji: motioncontroltips.com)

We wszystkich modelach najwyższą warstwą abstrakcji między komunikującymi się ze sobą urządzeniami jest warstwa aplikacji. Rozważmy warstwę aplikacji jako koncepcję modelu połączenia systemów otwartych (OSI) - która została po raz pierwszy dla komunikacji sieciowej zdefiniowana przez Międzynarodową Organizację Normalizacyjną (ISO) prawie trzy dekady temu. Ten klasyczny model siedmiowarstwowy jest nieco zbyt skomplikowany do opisu niektórych współczesnych protokołów, jednak nadal pomaga w pełni zrozumieć przepływy danych w systemach:

Warstwa fizyczna protokołu umożliwia przesyłanie surowych danych (bitów cyfrowych) w postaci sygnałów elektrycznych, radiowych lub optycznych. Ta warstwa określa układy wtyków, poziomy napięcia, szybkości transmisji danych i wartości impedancji liniowej fizycznych elementów przenoszących dane. Powszechnym protokołem warstwy fizycznej jest Ethernet. Więcej informacji na ten temat można znaleźć w artykule DigiKey pt. „EtherNet/IP kontra PROFINET”.

Warstwa łącza danych łączy węzły sieciowe, aby umożliwić urządzeniom nawiązywanie połączeń i korygowanie błędów w warstwie fizycznej. W ramach standardu IEEE 802 warstwa łącza danych jest podzielona na warstwę kontroli dostępu do mediów (MAC) (ponownie, aby umożliwić łączenie urządzeń) i warstwę Logical Link Control kontrola łączy logicznych (LLC) w celu identyfikacji następnej używanej warstwy (warstwy sieciowej), a także sprawdzenia błędów i synchronizacji. Więcej informacji o funkcjach warstwy łącza danych można znaleźć w artykule DigiKey pt. „Wdrażanie przemysłowych sieci Ethernet z wykorzystaniem 32-bitowych mikrokontrolerów MCU”. Warstwa sieciowa natomiast umożliwia przekazywanie pakietów danych na adresy sieciowe. Tam, gdzie protokoły internetowe odnoszą się do modelu protokołu kontroli transmisji i protokołu internetowego (TCP/IP) (omówione w następnej części niniejszego artykułu), między łączem danych a warstwami sieciowymi istnieje warstwa internetowa. W rzeczywistości warstwę internetową często uważa się za część warstwy sieciowej.

Pierwszą z kolejnych trzech warstw modelu OSI jest warstwa transportowa, która zapewnia niezawodność komunikacji i bezpieczeństwo podczas przesyłania sekwencji danych. Następnie warstwa sesji kontroluje, kiedy urządzenia łączą się ze sobą i czy połączenie jest jednokierunkowe (simplex) czy dwukierunkowe (duplex). Wreszcie warstwa prezentacji umożliwia tłumaczenie danych, aby urządzenia korzystające z różnych składni mogły się komunikować.

Artykuł koncentruje się na warstwie aplikacji - najwyższym poziomem abstrakcji, z którym współdziałają użytkownicy i oprogramowanie systemowe.

Ilustracja 3: nowoczesne protokoły sieciowe (i warstwa aplikacji) są często opisywane przy użyciu klasycznego modelu OSI sieci przemysłowych (i komercyjnych). Trójwarstwowe modele architektury Internetu rzeczy (IoT) stawiają warstwę aplikacji ponad warstwami percepcji i sieciowej, natomiast modele czterowarstwowe stawiają ją ponad warstwami przetwarzania danych, sieciową i wykrywania. Pięciowarstwowe modele protokołów IoT są podobne, z tym, że zawierają dodatkowo warstwy przetwarzania i przedsiębiorstwa. (Źródło ilustracji: Design World)

Protokoły internetowe w automatyce przemysłowej

Protokoły internetowe to systemy przesyłania danych nazwane tak ze względu na sposób, w jaki przekazują dane pomiędzy sieciami (i zwykle też odbierają je od nich) na potrzeby komunikacji międzygranicznej. Ich funkcje często opisuje wspomniany powyżej czterowarstwowy model TCP/IP. Tutaj sieć fizyczna lub warstwa łącza jest taka sama jak warstwa fizyczna modelu OSI. Inaczej jest w protokole TCP/IP, gdzie warstwa internetowa (która w przybliżeniu stanowi kombinację funkcji warstwy łącza danych i warstwy sieciowej modelu OSI) obsługuje zarówno połączenia, jak i pakiety danych. W protokole IPv6 do identyfikacji hostów w sieci ta warstwa używa 128-bitowych adresów IP. Istnieje możliwość wykorzystania więcej niż 10³⁸ unikalnych hostów.

Warstwa transportowa w protokole TCP/IP zazwyczaj składa się z protokołu kontroli transmisji (TCP) lub protokołu datagramów użytkownika (UDP). Protokół TCP jest zwykle używany do operacji wykonywanych przez człowieka, takich jak korzystanie z poczty e-mail i przeglądanie sieci. Zapewnia połączenia logiczne, potwierdzanie przesłanych pakietów, retransmisję utraconych pakietów i kontrolę przepływu. Jednak w systemach wbudowanych używa się protokołu UDP, aby uzyskać niższy narzut i lepszą wydajność w czasie rzeczywistym. Protokół UDP działa z serwerami nazw domen (DNS) i protokołem dynamicznej konfiguracji hosta (DHCP), a także z nowymi aplikacjami Internetu rzeczy (IoT).

Warstwa aplikacji to najwyższy poziom w modelu sieci TCP/IP. Obejmuje ona funkcje związane m.in. z warstwami sesji i prezentacji modelu OSI.

Ogólne protokoły warstwy aplikacji TCP/IP

Różne protokoły warstwy aplikacji mają różne przepustowości danych, możliwości działania w czasie rzeczywistym i wymagania sprzętowe. Czynniki te, obok znajomości protokołu przez pracowników firmy lub zespołu OEM, są często ważnym kryterium wyboru. Starsze protokoły internetowe, w tym protokół przesyłania hipertekstu (HTTP) i prosty protokół przesyłania poczty (SMTP), są w dużej mierze używane do komunikacji nadawanej i odbieranej przez człowieka, natomiast protokoły TCP/IP ukierunkowane na przemysłowy Internet rzeczy są bardziej skoncentrowane na komunikacji maszyna-maszyna (M2M) i innych rodzajach komunikacji przemysłowej.

Sprawę nieco komplikuje wielość przyjętych protokołów warstwy aplikacji używanych w TCP/IP do internetowych interakcji międzyludzkich z informacjami, które są również używane w zastosowaniach konsumenckich i przemysłowym Internecie rzeczy. Z pewnością dotyczy to protokołów HTTP i SMTP, a także bezpiecznej powłoki (SSH) i protokołu przesyłania plików (FTP). Implementacja funkcji Internetu rzeczy z technologiami internetowymi jest zwykle wykonalna przy założeniu wykorzystania dodatkowo języka eXtensible Markup Language (XML) i formatu JavaScript Object Notation (JSON). Jedynym zastrzeżeniem jest to, że używanie protokołu HTTP ma wpływ na bezpieczeństwo. Dlatego zazwyczaj najlepiej jest, jeśli wszystkie urządzenia Internetu rzeczy w takich systemach zawierają tylko klienta - a nie serwer. Zapobiega to odbieraniu przez urządzenie żądań połączenia, które mogłyby umożliwić nieautoryzowany dostęp z zewnątrz do sieci. W tym przypadku protokół WebSocket jest w stanie ustanowić komunikację w trybie pełnego dupleksu za pośrednictwem protokołu HTTP. W przeciwnym razie, w przypadku instalacji, które muszą adresować dużą liczbę urządzeń z dobrym zabezpieczeniem i przesyłaniem danych w czasie rzeczywistym, preferowany może być rozszerzalny protokół przesyłania komunikatów i obecności (XMPP).

Jeśli projekty Internetu rzeczy są realizowane przez personel z doświadczeniem informatycznym, te znane standardy (z czytelnej dla człowieka sieci) mogą być preferowane. Jednak do komunikacji maszyna-maszyna (M2M) i innych typów komunikacji przemysłowej mogą w niektórych przypadkach bardziej nadawać się nowsze protokoły przemysłowego Internetu rzeczy (IIoT).

Protokół MQTT dla funkcji transportu połączeń pionowych

Najszybciej wdrażanym protokołem w przemysłowym Internecie rzeczy jest protokół Message Queuing Telemetry Transport (MQTT) - lekki protokół początkowo przeznaczony do urządzeń Internetu rzeczy z ograniczoną pamięcią. Protokół MQTT został opracowany przez firmę IBM do łączenia czujników w rurociągach naftowych i oferuje działanie przy zachowaniu kompaktowości swojej infrastruktury i minimalnych wymaganiach w zakresie przepustowości. W przeciwieństwie do protokołu ograniczonych aplikacji (CoAP), MQTT został ustandaryzowany w normie ISO/IEC 20922. Protokół MQTT wykorzystuje nieco bardziej zasobochłonną warstwę transportową TCP i dlatego zużywa więcej mocy. Ale komunikaty mogą być dwubajtowe - to nawet mniej niż te z protokołu CoAP.

Ze względu na swój otwarty charakter protokół MQTT może być również szczególnie łatwy do wdrożenia. Nic dziwnego, że w Internecie rzeczy AWS Amazon Web Services wykorzystuje się protokół MQTT do transportu komunikatów i (z pewnymi zastrzeżeniami) jest on obsługiwany tam w oparciu o specyfikację v3.1.1.

Protokół MQTT ma pewne ograniczenia, które mogą wynikać z faktu, że początkowo był przewidziany jako protokół telemetryczny - w przeciwieństwie do lekkiego protokołu maszyna-maszyna (LwM2M) specyficznego dla Internetu rzeczy, który omówiono poniżej. W standardzie nie ma funkcji takich jak monitorowanie obiektów, łączności i zdalne operacje na urządzeniach, więc ich włączenie zwykle zależy od dostawcy, co nieco obniża wartość protokołu w postaci znormalizowanej. Protokół MQTT nie oferuje również możliwości obsługi błędów. Wreszcie, chociaż protokół MQTT można zabezpieczyć za pomocą pełnego protokołu TLS, zwiększa to jego narzut.

Przede wszystkim na poziomie przedsiębiorstwa: AMQP

Kolejnym otwartym standardem z pewnymi podobieństwami do protokołu MQTT jest zaawansowany protokół kolejkowania komunikatów (AMQP). Oferuje on zaawansowane funkcje, takie jak kolejkowanie komunikatów. Jednak narzut protokołu AMQP jest wyższy niż MQTT, co czyni go słabo przystosowanym do łączenia bardzo ograniczonych urządzeń. Nic dziwnego, że jego zastosowanie w przemysłowych aplikacjach Internetu rzeczy jest mniej powszechne niż w wydajnym przesyłaniu komunikatów.

Protokół CoAP do podłączania prostych urządzeń

Opracowany przez stowarzyszenie Internet Engineering Task Force (IETF) protokół aplikacji ograniczonych (CoAP) umożliwia komunikację w sieciach małej mocy między urządzeniami z minimalnymi pamięcią i mocą obliczeniową. Może działać z bardzo niskim narzutem, a żądania i odpowiedzi mogą mieć zaledwie cztery bajty. Protokół CoAP unika używania złożonego stosu transportowego zamiast UDP. Więcej informacji na temat protokołu UDP można znaleźć w artykule DigiKey pt. „EtherNet/IP kontra PROFINET”. Podobnie jak HTTP, protokół CoAP również wykorzystuje model REST - serwery udostępniają zasoby pod adresem URL, a klienci uzyskują do nich dostęp za pomocą metod POST, GET, DELETE i PUT. Co więcej, protokół CoAP można łatwo przetłumaczyć na HTTP w celu integracji z innymi funkcjami sieciowymi. Integruje się on również z XML i JSON. Inżynierowie powinni zauważyć, że łączenie urządzeń IoT przy użyciu protokołu CoAP jest bardzo podobne do łączenia urządzeń przy użyciu internetowego interfejsu API.

Ilustracja 4: układ SiP firmy Nordic to mikrokontroler MCU małej mocy ze zintegrowanym modemem LTE-M i wąskopasmowym IoT, a także modułem GPS. Konfigurację protokołu CoAP umożliwia zestaw rozwojowy oprogramowania. (Źródło ilustracji: Nordic Semiconductor)

Podłączanie urządzeń zasilanych bateryjnie przy użyciu protokołu LwM2M

Protokół warstwy aplikacji firmy Open Mobile Alliance jest protokołem LwM2M zbudowanym specjalnie dla aplikacji Internetu rzeczy (IoT). Protokół LwM2M znajduje zastosowanie w inteligentnych rozwiązaniach miejskich, śledzeniu kontenerów transportowych i towaru, zautomatyzowanych procedurach pozadrogowych i monitorowaniu mediów. Bazuje na protokole CoAP, więc oba mają wiele wspólnych cech. Standard obejmuje szeroki zakres jasno zdefiniowanych i utrzymywanych standardowych obiektów, a także monitorowanie łączności i zdalne operacje na urządzeniach. Zarządzanie urządzeniami podłączonymi do protokołu LwM2M upraszczają również automatyczne aktualizacje oprogramowania układowego. Chociaż włączenie modułów, takich jak JSON, zwiększa narzut, to ułatwia ono również pracę programistom. Ponieważ protokół LwM2M został zaprojektowany specjalnie dla aplikacji Internetu rzeczy, może on również obsługiwać silny protokół bezpieczeństwa DTLS bez zwiększania narzutu.

DDS dla aplikacji rozproszonych w czasie rzeczywistym

Usługa dystrybucji danych (DDS) jest nieco inna i często jest klasyfikowana jako oprogramowanie pośredniczące do komunikacji maszyna-maszyna (M2M), a nie protokół warstwy aplikacji. Zapewnia bezpieczne i wydajne połączenia (między innymi) w pojazdach autonomicznych, systemach wytwarzania energii i kontroli ruchu lotniczego. W tych ustawieniach usługa DDS obsługuje połączenia systemów wbudowanych dla uzyskania sterowania rozproszonego pozbawionego nadmiernej zależności od bram. Usługa DDS obsługuje również kierowanie i dostarczanie komunikatów bez konieczności interwencji ze strony aplikacji. Ponadto jakość parametrów usługi DDS można konfigurować - dzięki czemu operacje sieciowe można zoptymalizować z uwzględnieniem ograniczeń systemu.

Ilustracja 5: oprogramowanie Connext Drive dla pojazdów autonomicznych jest zbudowane w oparciu o oprogramowanie pośredniczące usługi dystrybucji danych (DDS) - które stanowi część fundamentu dla otwartej architektury oprogramowania systemów dla motoryzacji AUTomotive Open System ARchitecture (AUTOSAR) Adaptive i ROS2. To tylko jeden przykład integracji oprogramowania IoT z wykorzystaniem usługi DDS. (Źródło ilustracji: Real-Time Innovations)

Podsumowanie: protokoły warstwy aplikacji przemysłowego Internetu rzeczy (IIoT)

Wszystkie protokoły mają mocne i słabe strony, ale opcje otwartoźródłowe umożliwiające szybkie wdrożenie i bezpieczeństwo (najlepiej z niskim narzutem) najlepiej odpowiadają potrzebom Internetu rzeczy. Systemy wbudowane i układy SoC ze stale rosnącymi możliwościami obliczeniowymi nadal pobudzają proces wdrażania przemysłowego Internetu rzeczy (IIoT) i dalej rozszerzają możliwości w warstwach aplikacji różnych protokołów.