Na całym świecie do sieci podłączonych jest obecnie 30-50 miliardów urządzeń. I choć trudno stwierdzić, ile z nich stosowanych jest w przemyśle, jedno jest pewne: Internet Rzeczy nie stanowi już tylko sloganu reklamowego producentów automatyki. Jest rzeczywistym zjawiskiem, z którym każdy przetwórca prędzej czy później będzie musiał się zmierzyć. A skoro tak, warto wiedzieć, z czym właściwie mamy do czynienia.

Koncepcja Internetu Rzeczy narodziła się później niż sam IoT: pierwsze urządzenie podłączone na stałe do sieci – automat vendingowy Coca-Coli z funkcją monitorowania stanu zapasów oraz warunków temperaturowych panujących w jego wnętrzu – stanęło w 1982 r. na Uniwersytecie Carnegie Mellon w amerykańskim Pittsburghu. Zaś definiujące jego funkcjonalności pojęcie Internetu Rzeczy, a właściwie „internetu przedmiotów” zostało ukute przez Kevina Ashtona z Procter & Gamble w 1999 r. i przez długie lata, zanim zaczęło żyć własnym życiem, funkcjonowało ściśle w kontekście RFID.

Internet Rzeczy, czyli co?

Czym właściwie jest IoT? Można go rozumieć na dwa sposoby: jako fizyczną infrastrukturę do gromadzenia, przetwarzania i wymiany danych między jednoznacznie identyfikowanymi urządzeniami podłączonymi do wspólnej sieci lub też jako zdolność owych urządzeń do takiej wymiany. Niezależnie, którą z definicji wybierzemy, kluczowym aspektem w każdym przypadku jest „jednoznaczna identyfikowalność”: aby obiekty fizyczne funkcjonujące w ramach sieci mogły efektywnie się ze sobą komunikować, muszą posiadać indywidualne, różnicujące je od siebie identyfikatory. Stąd istotna rola RFID jako źródła owej identyfikacji w budowaniu Internetu Rzeczy.

Sieć taka obejmuje zarówno urządzenia komercyjne (sprzęt RTV i AGD, oświetlenie, urządzenia noszone, systemy HVAC), jak i typowo przemysłowe (czujniki, maszyny, roboty, automatykę budynkową). W ujęciu statystycznym nie sposób oddzielić od siebie tych dwóch światów: intuicyjnie zdajemy sobie sprawę, że IoT rozwija się w tempie szybszym niż IIoT, ale o skali różnicy w tempie owego rozwoju wiele powiedzieć nie można.

Dlatego w raportach dotyczących Przemysłowego Internetu Rzeczy analitycy bazują na danych dotyczących wszystkich form Internetu Rzeczy. A trzeba przyznać, że dane te działają na wyobraźnię: według instytutu badawczego McKinsey na całym globie do sieci może być podłączonych nawet 30-50 miliardów urządzeń, a co sekundę na świecie z Internetem łączy się 127 obiektów.

Już dawno przekroczono więc próg, który Cisco definiowało jako początek Internetu Rzeczy, tj. moment, kiedy przedmiotów podłączonych do sieci będzie więcej niż ludzi. Nastąpił on zdaniem producenta gdzieś między 2003 a 2010 r., w którym stosunek rzeczy do ludzi w sieci wynosił już 1,84.

Proporcjonalnie do wzrostu znaczenia IoT rosną również związane z nim wydatki inwestycyjne: w 2019 r. wyniosły one 750 mld dolarów, tj. o 15,4% więcej niż rok wcześniej. Analitycy IDC szacują, że taki dwucyfrowy wzrost utrzyma się do ok. 2022 r. – i niestraszna mu będzie nawet epidemia Covid–19, która w wielu sektorach wręcz napędziła rozwój Internetu Rzeczy.

Percepcja – transport – aplikacja

Mówiąc o inwestycjach w rozwój infrastruktury IoT, badacze nie mają przy tym na myśli jedyni e interoperacyjnych urządzeń zdolnych do integracji z globalną siecią komunikacyjną. Fizyczne elementy sieci stanowią bowiem istotną, ale nie jedyną składową architektury Internetu Rzeczy. W różnych ujęciach elementy te definiuje się różnorako, ale najprościej można je podzielić na trzy główne warstwy: percepcji, transportową i aplikacji.

W przemyśle na warstwę percepcji składają się głównie czujniki, a także systemy elektronicznej identyfikacji obiektów (m.in. RFID). Urządzenia te zbierają dane z otoczenia i za pomocą kolejnej warstwy (transportowej) przesyłają je dalej do platformy IoT. W warstwie transportowej zbiory danych zgromadzone przez czujniki są nie tylko przesyłane z punktu A do punktu B, ale także procesowane (przetwarzane) i przechowywane w lokalnych bazach danych. Jest ona więc najbardziej rozbudowana: obejmuje zarówno infrastrukturę przesyłową, jak też komponenty do lokalnego gromadzenia i analizy danych.

Całość spaja warstwa aplikacji, której zadaniem jest zapewnienie dostępu do gromadzonych przez system danych przez stworzenie spójnej platformy ich wymiany, analizy, ważenia i tworzenia korelacji. Platformy takie, zwane platformami IoT, stanowią de facto ogromne bazy danych wyposażone w funkcje ich eksploracji. Mogą funkcjonować lokalnie (serwery przedsiębiorstwa) lub w chmurze, a coraz częściej spotyka się także wersje hybrydowe składające się z chmury publicznej do przechowywania danych niewrażliwych i chmury lokalnej do gromadzenia informacji istotnych z punktu widzenia zachowania ciągłości działania przedsiębiorstwa.

Nieco inaczej ten sam podział ujmuje firma IoT Sense: amerykański dostawca platform Internetu Rzeczy dzieli elementy architektury IoT na pięć głównych grup: czujniki, moduły I/O do zbierania i transferu danych pomiędzy poszczególnymi urządzeniami, oprogramowanie do analizy owych danych, sieć przesyłową oraz aplikacje i platformy spajające pozostałe komponenty i tworzące faktyczną wartość dodaną dla użytkownika.

Wszechstronna interoperacyjność

Dane zebrane przez czujniki przesyłane są dalej do wspomnianych węzłów brzegowych, a następnie do sterownika PLC. Sterownik ten w sieciach IoT pełni jednak nieco inne funkcje niż w standardowych sieciach przemysłowych – podobnie zresztą jak cała architektura Internetu Rzeczy, która, choć w dużej mierze przypomina tę stosowaną od dekad do budowy klasycznych sieci przesyłowych, nie jest z nią jednak tożsama.

Jak podkreśla firma Beckhoff – producent systemów sterowania i automatyki dla przemysłu – Przemysłowy Internet Rzeczy funkcjonuje na zupełnie innych zasadach: informacje nie są tu już przesyłane według schematu góra–dół, lecz w dwóch kierunkach. Oznacza to, że w przeciwieństwie do klasycznych modeli architektury, w których sygnały inicjujące komunikację generowane są przez użytkownika, zaś dolna warstwa pełni funkcję serwera reagującego, w architekturze IoT każde urządzenie lub system może samodzielnie inicjować komunikację z innymi elementami sieci.

Powoduje to, że komunikacja w sieci IoT przebiega już nie według jednego modelu (B2M), lecz według trzech różnych schematów: B2B, B2M i M2M. Pierwszy – B2B (Business to Business) obejmuje procesy zachodzące między warstwą biznesową (ERP i MES, HMI i MES, MES i MES). W modelu B2M warstwa biznesowa (MES) wchodzi w interakcje z maszyną (sterownikiem PLC). Zaś w ramach komunikacji M2M (Machine to Machine) dochodzi do wymiany danych między dwoma systemami sterowania maszyn, przy czym zainicjowana w ten sposób komunikacja może mieć wymiar horyzontalny (dwa równorzędne systemy sterowania) lub wertykalny (np. platforma sterowania i system sterowania robotem).

Podział ten jest ważny z co najmniej dwóch powodów: po pierwsze, uwypukla rolę semantyki w budowie i prawidłowym funkcjonowaniu architektury IoT, a po drugie – stanowi podstawę definiowania standardów przesyłu danych w ramach Internetu Rzeczy. Standardy te nie bazują już bowiem wyłącznie na interoperacyjności samych danych, ale także ich warstwy semantycznej, co oznacza, że w procesie ich konstruowania konieczne jest stworzenie języków opisu i usług dostępnych dla poszczególnych modeli komunikacji.

Tłumacz Internetu Rzeczy

Wspomniane standardy przesyłu danych nie ułatwiają zadania projektantom systemów IoT. W aplikacjach przemysłowych zarówno one, jak i odpowiadające im protokoły komunikacyjne mogą się bowiem znacznie od siebie różnić – w zależności od producenta danego urządzenia i typu sieci przemysłowej. W efekcie urządzenia te porozumiewają się w różnych językach i aby w ogóle mówić o ich integracji w ramach jednej sieci, trzeba owe języki sprowadzić do wspólnego mianownika, tj. przetłumaczyć na jeden konkretny język komunikacji.

Początkowo zadanie to realizowały wyłącznie platformy IoT: ich twórcy wyposażali je w możliwość pośredniej i bezpośredniej konwersji różnych protokołów komunikacyjnych, takich jak CoAP, AMQP, http czy MQTT. Rozwiązanie to funkcjonowało poprawnie, ale utrudniało płynny przesył danych na różnych poziomach komunikacji. Dlatego w 2006 r. powstała inicjatywa mająca na celu utworzenie jednego uniwersalnego standardu. Tak powstał OPC UA (Unified Architecture) zapewniający integrację modeli wymiany danych stosowanych przez takie organizacje jak BACnet, PLCopen, IEC 61850, AIM AutoID czy MES-DACH.

Architektura OPC UA składa się z dwóch komponentów: serwera OPC UA i klienta OPC UA. Serwer ów wspiera standard komunikacji zgodny z normą IEC 61131-3, dzięki czemu gromadzone na nim dane mogą być bez problemu wywoływane na urządzeniach różnych producentów. Oprócz serwera centralnego funkcjonującego w ramach systemu MES/ERP architektura OPC UA dopuszcza możliwość tworzenia niemal nieskończonej liczby serwerów lokalnych – de facto każde urządzenie zintegrowane w sieci może funkcjonować zarówno jako serwer, jak i klient OPC UA.

W pierwszej roli reaguje na żądania innych urządzeń i systemów nadrzędnych (SCADA, MES, ERP), w drugiej – samodzielnie inicjuje komunikację z innymi uczestnikami procesu wymiany danych. Weźmy za przykład standardowy sterownik PLC wyposażony w bloki funkcyjne CANopen-OPC UA: w funkcji serwera odbiera on, przetwarza i realizuje programy wykonawcze wygenerowane na innych urządzeniach, zaś w funkcji klienta przekazuje dane na zewnątrz (np. do celów wizualizacji) – i to w sposób semantycznie identyczny niezależnie od jego producenta. Co więcej, może się on w ten sposób komunikować zarówno w wymiarze horyzontalnym (z innymi kontrolerami), jak i wertykalnym (z nadrzędnym systemem MES/ERP). Może także uruchamiać usługi OPC UA na innych urządzeniach, np. w systemie wizyjnym czy czytniku RFID.

Aby móc korzystać z tego typu funkcji, trzeba je najpierw zaimplementować do sterowników, załadować na dyski CPU i uruchomić w czasie rzeczywistym – niezależnie na każdym urządzeniu. Możliwość taką oferuje oprogramowanie z funkcją obsługi standardu OPC UA, np. TwinCAT 3 firmy Beckhoff, w którym aby zaprogramować sterownik jako serwer i klienta OPC UA, wystarczy dodać wiersz polecenia uruchamiający usługę w urządzeniu.

Nie tylko Ethernet

Nacisk na maksymalną uniwersalizację standardów komunikacji, a przede wszystkim postępy poczynione do tej pory w tym zakresie są jednym z dwóch elementów, które wyraźnie odróżniają Przemysłowy Internet Rzeczy od jego komercyjnego odpowiednika. Drugim są stosowane sieci przesyłowe: w przeciwieństwie do sieci komercyjnych są one bowiem przystosowane do transferu małych ilości danych w regularnych, częstych interwałach czasowych, a dodatkowo muszą cechować się niezawodnością i odpornością na zakłócenia, która w wielu przypadkach wyklucza stosowanie nadajników i odbiorników bezprzewodowych. Z tego względu największą popularnością w aplikacjach przemysłowych cieszą się trzy sieci: CC Link IE, Ethernet/IP oraz EtherCAT. Wszystkie są sieciami przewodowymi, a ich ewolucja sprowadza się w gruncie rzeczy do zwiększania przepustowości łączy oraz integracji funkcji komunikacyjnych i zasilania w jednym przewodzie.

Stosowane w złożonych systemach sterowania kablowe sieci przemysłowe bez problemu radzą sobie także z obsługą aplikacji z zakresu Internetu Rzeczy. Nie oznacza to jednak, że są rozwiązaniem jedynym: co jakiś czas podejmowane są próby wykorzystania w tej roli także sieci bezprzewodowych krótkiego i dalekiego zasięgu, które mają tę podstawową zaletę, że redukują nakłady na okablowanie, zwiększają mobilność wyposażenia, a dodatkowo zapewniają więcej wolnej przestrzeni w hali produkcyjnej. Pomijając nieprzystosowane do pracy w środowiskach przemysłowych sieci Wi-Fi, do grupy tej zalicza się m.in. standardy Bluetooth i ZigBee oraz sieci GPRS bazujące na kartach SIM. Te ostatnie mają sporo wad: są drogie i zużywają sporo energii, więc wymuszają stałe zasilanie peryferiów.

Alternatywą dla nich są rozwijane od lat 90. XX w. sieci dalekiego zasięgu małej mocy, tzw. LPWAN (Low Power Wide Area Network). Pozbawione słabości swoich starszych konkurentów, zapewniają niskie koszty użytkowania i zużycie energii, ale jednocześnie oferują relatywnie małe prędkości przesyłu danych, co dotąd skutecznie zniechęcało przedsiębiorców do eksperymentowania z tego typu rozwiązaniami. Przemysł coraz częściej wymaga bowiem reakcji w czasie rzeczywistym, a tego sieci RPMA, Weightless czy Strij zapewnić nie mogły.
Może się to jednak zmienić za sprawą dwóch projektów: SigFox i LoRa dedykowanych aplikacjom z zakresu IoT. Oba działają na wolnym paśmie częstotliwości, dzięki czemu nie wymagają zakupu licencji. Z tego samego względu umożliwiają jednak przesyłanie tylko niewielkich pakietów danych (12 B) w liczbie 140 wiadomości na dzień. Jeszcze gorzej jest z odbiorem danych: tutaj SigFox oferuje 4 wiadomości na dzień. Atrakcyjna formuła sieci globalnej i otwarty standard stanowią jednak potężny argument w aplikacjach, w których dane są zbierane i wysyłane rzadziej.

W ostatnim czasie powstała jeszcze jedna sieć dedykowana IoT – NB–IOT (Narrow Band IOT) stworzona przez operatorów sieci GSM w odpowiedzi na dynamiczny rozwój sieci LPWAN. Rozwiązanie to, oparte na sieci 4G, oferuje niskie zużycie energii przy ograniczonej przepustowości. Jego zaletą jest bez wątpienia globalny zasięg, jednak bez możliwości budowy sieci prywatnych.

Plastime Magazine

Tekst ukazał się w „Plastime Magazine” nr 2/2021. Chcesz mieć dostęp do pełnej wersji miesięcznika? Zapisz się na bezpłatny „Polimerowy Przegląd Prasy” – odbiorcy naszego newslettera otrzymują darmowy dostęp do kolejnych wydań. Zapisz się!