Rejestrowanie danych pomiarowych w środowisku przemysłowym z wykorzystaniem RESTful API

Dynamiczny rozwój technologii sprawia, że coraz więcej przedsiębiorstw produkcyjnych korzysta z systemów IT, które pozwalają na monitorowanie urządzeń przemysłowych i procesów produkcyjnych oraz zarządzanie nimi. W takich środowiskach istotną rzeczą jest warstwa komunikacyjna wykorzystywana do wymiany danych między systemami webowymi np. klasy ERP, a urządzeniami przemysłowymi. W artykule omówimy zastosowanie Restful API w środowiskach OT oraz jakie korzyści płyną z ich wykorzystania.

Czym jest RESTful API?

API (z ang. Application Programming Interface), czyli Interfejs Programistyczny Aplikacji jest niczym innym jak zestawem reguł definiujących sposób, w jaki te aplikacje czy urządzenia mogą się ze sobą komunikować.

REST (z ang. Representational State Transfer) jest stylem architektonicznym, który zakłada:

  • komunikację klient <-> serwer (pytanie <-> odpowiedź)
  • bezstanowość – serwer nie musi przechowywać żądnych parametrów w pamięci, aby odpowiedzieć na otrzymanie zapytanie od klienta. Wszystkie potrzebne parametry powinny być zamieszczone w pytaniu od klienta
  • identyfikacja zasobów przez URL – interfejs udostępniający zasoby powinny być identyfikowane poprzez adresy URL (konkretny punkt dostępowy do zasobu to tzw. Endpoint).

Połączenie obu haseł, daje tzw. RESTful API, co narzuca pewien standard w dostępie do naszej aplikacji i definiuje to, jak możemy z niej skorzystać. Informacje przesyłane pomiędzy klientem a serwerem zazwyczaj przyjmują format JSON lub XML. Często też RESTful API wiąże się z protokołem HTTP.
Protokół ten udostępnia szereg metod, takich jak:

  • GET – pobieranie zasobu
  • POST – tworzenie nowego zasobu
  • PUT – aktualizowanie istniejącego zasobu
  • DELETE – usuwanie zasobu
  • PATCH – częściowe aktualizowanie zasobu

Do czego przydaje się RESTFUL API w projektach IIoT?

Komunikacja, a w zasadzie jej brak, spędzała sen z powiek podczas wielu wdrożeń systemu i testowała cierpliwość niejednego inżyniera. W sieciach OT (ang. Operational Technology), czyli wszelkich sieciach automatyki, często możemy spotkać podziały, na różne media transmisyjne (np. światłowody, połączenia miedziane, Wi-Fi) oraz protokoły i standardy komunikacyjne. Branża przemysłowa pracowała i dalej pracuje nad wspólnym standardem, który uprościłby komunikację, ale póki co wygląda to jak wygląda…

Dziś głównym standardem jest Ethernet, który przy nowotworzonych projektach z reguły bywa pierwszym wyborem. W starszych systemach niejednokrotnie można spotkać standardy RS-232/485.Powodem są urządzenia, które komunikowały się głównie w ten sposób, ale czasem taki wybór bywa też kwestią bezpieczeństwa. Okazuje się, że nieco trudniej o cyberatak w komunikacji szeregowej, dlatego w przypadku przesyłania lekkich, ale istotnych danych, jak np. klucze dostępowe, czasami wybierane są jeszcze standardy szeregowe. Ale to stosunkowo rzadki wybór i możemy go uznać za ciekawostkę.

Najważniejszym celem w komunikacji jest po prostu wymiana danych pomiędzy urządzeniami. Jak i z pomocą których protokołów jest ona realizowana, jest już kwestią wyboru. Natomiast tworząc aplikację pod system IIoT zależy nam na tym, aby przejść już na standardy bliższe IT. A tutaj RESTful API nie trzeba już nikomu przedstawiać…

Wyzwania rzucane przez sieci OT

Wykonując projekt od A do Z nie unikniemy zejścia do samego źródła, z którego pobieramy parametry lub je zadajemy (np. gdy chcemy coś wysterować). Często spotkamy się tam z sygnałami cyfrowymi/analogowymi, czujnikami temperatury, urządzeniami komunikującymi się po portach RS (np. w protokole Modbus RTU), jak również po standardach Ethernet (np. w protokole Modbus TCP).

Wyspa ioLogik

Stosowanie danych protokołów jest zależne również od branży.
W energetyce standardem są protokoły DNP3, IEC 61850, IEC 60870-5-101, IEC 60870-5-104, które określają, jak można komunikować się w obrębie stacji energetycznych. W systemach biurowych, czyli popularnych BMS’ach, króluje BACnet. Na liniach produkcyjnych często spotykamy PROFIBUS/PROFINET, czyli standardy narzucone głównie przez sterowniki Siemensa.

Aby ujednolicić między sobą różne standardy, stosuje się konwertery protokołów, np. takie jak rodzina MGate od Moxa.

ioThinx

Jak wygląda dostęp do wysp I/O przez API?

Skoro omówiliśmy to, czym jest REST API oraz do czego może nam się przydać w IIoT (i z czym przychodzi się mierzyć po stronie OT) przejdźmy do meritum.

Jak uzyskać dostęp do OT za pomocą RESTFul API?

Skupimy się na rozwiązaniach Moxa w tym zakresie.
Gdy przyjdzie nam obsłużyć sygnały wejść/wyjść cyfrowych/analogowych, możemy skorzystać z wysp I/O z rodziny ioLogik lub bardziej zaawansowanej serii o nazwie ioThinx.

Wyspa pozwala na odczyt konfiguracji oraz rejestrów wejść/wyjść. Spójrzmy, jak to wygląda w praktyce.

W pierwszym kroku należy upewnić się, czy mamy włączoną obsługę RESTful API na urządzeniu. Konfigurację przeprowadzimy przez Web Server dostępny po wpisaniu adresu IP do przeglądarki.

Do wysyłania zapytań http wykorzystamy popularnego Postmana i z jego poziomu potestujemy API.

Rzućmy jeszcze okiem na dokumentację API i zauważmy, że część atrybutów jest tylko do odczytu, a część z nich możemy również nadpisać.

Uwaga: Przy tworzeniu zapytań http musimy pamiętać o dodaniu dwóch nagłówków (headers):

Accept: vdn.dac.v1
Content-Type: application/json

Teraz sprawdźmy, jak wygląda odczyt np. wyjść cyfrowych (DigitalOutput) poprzez API. Widzimy stan czterech wyjść cyfrowych (pierwsze wyjście ma status 1, co oznacza, że jest „załączone”).

Zapytanie typu GET na endpoint /api/slot/0/io/do

IoLogik zwraca odpowiedzi w formacie JSON, co jest łatwe w odczycie i wygodne z punktu widzenia dalszej analizy danych.

Jak zmienić stan wyjścia cyfrowego przez API?
Powinniśmy wysłać zapytanie typu PUT, aby edytować aktualny stan. A co wpisać w polu „Body”? Tutaj najprostszym sposobem jest wysłanie najpierw zapytanie GET, aby otrzymać odpowiedź, a następnie przekopiować całego JSON’a do Body dla zapytania PUT i zmienić odpowiednie wartości wyjść cyfrowych.

Kilka słów o cyberbezpieczeństwie…

Na koniec chciałbym odnieść się do bardzo ważnej kwestii, jaką jest bezpieczeństwo naszego systemu. Korzystanie z API w implementacji na modułach Moxa ioLogik oraz ioThinx nie wymaga wcześniejszego uwierzytelnienia użytkownika. Oznacza to, że każdy, kto ma lub będzie miał dostęp sieciowy do urządzenia, może mieć wpływ na stan wejść/wyjść. Konsekwencje takiego stanu rzeczy mogą być groźne…
Dlatego włączając RESTful API na urządzeniu musimy mieć pewność, że nikt niepowołany nie otrzyma dostępu do sieci. Zalecałbym w tym wypadku wyposażyć sieć w firewalla, tunel VPN, system IPS/IDS lub inne mechanizmy, które zapewnią, że wyspa I/O nie wpadnie w niepowołane ręce. 

Wykorzystać też można Gateway z rodziny UC z RESTFul API: ThingsPro Edge, który po połączeniu pozwali na odczyt danych z ioLogik i ioThinx, ale tylko po przejściu uwierzytelnienia. ThingsPro Edge ma też o wiele więcej mechanizmów bezpieczeństwa.

ThingsPro Edge pozwala na znacznie więcej
Kiedy pobierzemy interesujące nas dane ze środowiska OT planujemy zapewne coś z nimi zrobić – przesłać je do innego oprogramowania IT, zapisać, zwizualizować lub przeanalizować.

Czy ThingsPro Edge potrafi to wszystko? Nie. Ale może w tym pomóc.

AIG-300 – Komputer z preinstalowaną usługa Azure IoT Edge

ThingsPro Edge to oprogramowanie stworzone jako dodatek do gatewayów przemysłowych z rodziny UC od Moxa, które oparte są o system Linux w pełni dostępny dla użytkownika. W zasadzie wszystko możemy zrobić sami: zaprogramować, oskryptować, przetestować, wdrożyć…

Z tym, że ThingsPro Edge jest już gotowe do instalacji, darmowe, przetestowane i pozwala m.in. na przesłanie danych po protokole MQTT czy standardzie Spurkplug, wysłanie danych do chmury Azure, AWS (przez wbudowane wtyczki) czy przesłać dane do oprogramowania OPC UA.
Może również przesyłać dane do Brokera MQTT, Zainstalowanego np. jako oddzielna aplikacja w systemie, a następnie „subskrybować” (w protokole MQTT mamy do czynienia ze wzorcem „publish-subscribe”) je do NodeRED, zapisywać w lokalnej bazie danych, a nawet zwizualizować w Grafanie. Wszystko to można uruchomić na jednym urządzeniu z pomocą oprogramowania ThingsPro Edge.

Lokalna wizualizacja zaimplementowana w oprogramowaniu Grafana na komputerze z rodziny UC

W artykule omówiliśmy wykorzystanie Restful API w środowiskach OT oraz jakie korzyści płyną z ich implementacji. Przedstawiliśmy również przykłady zastosowania Restful API w różnych branżach przemysłowych.

W szczególności, skupiliśmy się na rozwiązaniach oferowanych przez firmę Moxa, takich jak urządzenia ioLogik & ioThinx oraz oprogramowanie ThingsPro Edge. Rozwiązania te umożliwiają monitorowanie i zarządzanie urządzeniami przemysłowymi oraz procesami produkcyjnymi, a Restful API pozwala na łatwe i efektywne udostępnienie danych oraz funkcjonalności urządzeń innym systemom.

Dzięki Restful API oraz urządzeniom ioLogik & ioThinx oraz oprogramowaniu ThingsPro Edge przedsiębiorstwa mogą poprawić efektywność i wydajność swoich procesów produkcyjnych, a także zintegrować swoje systemy OT z innymi systemami informatycznymi. Ostatecznie, wykorzystanie Restful API w środowiskach OT może przyczynić się do osiągnięcia wyższej jakości produktów, lepszej kontroli procesów produkcyjnych i zwiększenia konkurencyjności przedsiębiorstwa na rynku.


Elmark