Modbus w chmurze, czyli Przemysł 4.0 w praktyce

Przemysł 4.0, IIoT i rozwiązania chmurowe to obecnie bardzo popularne frazy w świecie przemysłu jak i IT. Hasła te przez wielu są interpretowane jako czysty marketing i wymyślanie koła na nowo, jednak nic bardziej mylnego. W przeszłości istniały podobne urządzenia i usługi, i można było tworzyć podobne aplikacje do tych dzisiejszych, jednak było to znacznie trudniejsze i bardziej kosztowne niż dziś. Obecnie tworzenie rozwiązań i usług w chmurze jest najtańsze i najprostsze w historii, co jeszcze bardziej zwiększa powszechność usług i produktów z zakresu IIoT i przemysłu 4.0. Obecnie uruchomienie dedykowanego serwera bądź maszyny wirtualnej pod naszą aplikację u najpopularniejszych dostawców chmurowych takich jak:  AWS, Azure lub Google Cloud platform wymaga od użytkownika tylko „wyklikania” konfiguracji. Ponadto, dostawcy udostępniają coraz więcej usług pracujących bezserwerowo (j ang. „serverless”), to znaczy że dostawca dostarcza jedynie wąską funkcjonalność z której korzysta użytkownik zajmując się wszystkim co dzieje się pod maską. Oznacza to że użytkownik nie musi zajmować się konfiguracją i utrzymaniem serwerów, i może skupic się nad samą funkcjonalnością. Jedną z takich usług jest tzw. IoT Core od AWS, który jest gotowym brokerem protokołu MQTT. We wpisie tym zaprezentuję integrację oprogramowania ThingsPro na komputerze UC-8112-LX firmy Moxa, właśnie z usługą AWS IoT Core, oraz dalsze przetwarzanie danych. Oprogramowanie ThingsPro posiada funkcje zbierania danych z urządzeń Modbus RTU/TCP, więc niskim kosztem i nakładem sił można zbudować rozwiązanie do odczytu danych z urządzeń używających protokołu Modbus, takich jaki liczniki energii, liczniki mediów, czujniki ciśnienia, dataloggery itp., i eksport takich danych do chmury, np. w celu archiwizacji, dalszej analizy czy wizualizacji itp..

Topologia

Topologia jest zgodna z powyższym schematem. Do komputera UC-8112 jest podłączony moduł wejść IO - ioLogik E1210 z którego odczytywany jest stan licznika wejścia cyfrowego, oraz podłączony jest analizator energii UMG 604, z którego odczytywane jest całkowite zużycie energii na wszystkich fazach. Na komputerze UC-8112 skonfigurowany jest klient usługi AWS IoT, który wysyła dane odczytywane z urządzeń Modbus jeśli stan tych rejestrów się zmienił od ostatniego zapytania. Następnie w infrastrukturze AWS dane te są kierowane do przetworzenia przez funkcję „Lambda”, która zmienia format json na csv, aby następnie zapisać dane w „S3” (dysk w chmurze). Na tym etapie mamy już załatwioną archiwizację danych w chmurze, dane automatycznie będą spływać i zapisywać się w usłudze S3, czyli na dysku sieciowym. Następnym krokiem jest wczytanie danych z S3 do QuickSight, czyli do edycji i wizualizacji. Na końcu wpisu przedstawię dodatkowe alternatywne usługi i działanie jakie można przeprowadzić na danych , a tymczasem poniżej Instrukcja krok po kroku, jak utworzyć takie rozwiązanie.

Nagranie z konfiguracji

Poniżej zapis konfiguracji opisywanej aplikacji:

Utworzenie konta w AWS

Pierwszym krokiem jest utworzenie darmowego konta w Amazon Web Services, wystarczy karta kredytowa i 15 minut na wypełnienie formularza. Przez okrągły rok można działać w ramach „Free Tier” czyli zupełnie za darmo testować większość usług AWS, oczywiście w ustalonych granicach. Prosty poradnik jak założyć konto na AWS:

https://chmurowisko.pl/uruchomic-swoj-wlasny-serwer-amazon-aws-darmo/

Następnie możemy przejść do konsoli AWS IoT.

Utworzenie  „Rzeczy” w AWS IoT core

Następnym krokiem jest utworzenie „Rzeczy” AWS IoT Core. Jest to dość dobrze opisane w instrukcji przygotowanej przez producenta, zapraszam do lektury:

https://www.moxa.com/doc/tech_notes/Moxa_Tech_Note---ThingsPro_AWS_IoT_Application.pdf

Konfiguracja UC-8112-LX ThingsPro

 

Następna w kolejności jest  konfiguracja ThingsPro na komputerze UC-8112-LX.  ThingsPro to oprogramowanie które jest dostępne oddzielnie, tzn. sam komputer UC-8112 nie zawiera go w zestawie. W pierwszej kolejności należy skonfigurować interfejs Ethernet, można użyć statycznego adresu, lub dynamicznego (DHCP). Dobrze też ustawić właściwy czas, aby dodawana stopka czasowa była prawidłowa. Następnym krokiem jest skonfigurowanie „Modbus Logging”. Należy zacząć od utworzenia szablonu (Template) który przechowuje informację na temat rejestrów Modbus urządzania z którego chcemy odczytywać dane. W naszym przykładzie komputer będzie odczytywał dane z modułu wejść ioLogik E1210 firmy Moxa, i dla tego urządzenia jest już przygotowany szablon, jedyne co dodałem to odczytywanie licznika dla wejścia nr 0. Odczytywany jest również analizator energii firmy Janitza, a konkretnie jeden parametr całkowite zużycie energii czynnej.

Konfiguracja interfejsu sieciowego

Widok szablonów slave'ów, czyli opisów struktury rejestrów urządzeń Modbusa

Dodawanie nowego tagu Modbus do szablonu.

Kolejnym krokiem jest przejście do ustawień komunikacji urządzeń Modbus. Należy dodać urządzenie z interfejsem Modbus, wpisać jego adres IP, port TCP na który trzeba się łączyć oraz interwał zapytań i maks. czas oczekiwania na odpowiedź. Następnie należy wybrać dodany wcześniej szablon wg którego mają być odczytywane dane z dodanego slave’a Modbus. Klikając „TEST” można sprawdzić czy rzeczywiście jakieś dane są odczytywane, powinniśmy zobaczyć odpowiedź w formacie json.

Widok slave'ów Modbus, ustawienia adresów IP

Formatka do dodania nowego slave

"Doklejenie" szablonu rejestrów do dodanego przed chwilą slave:

"TEST" nowo dodanego slave'a z wynikiem pozytywnym

Na tym etapie komputer już odczytuje dane z urządzeń protokołem Modbus, ale nie ma jeszcze połączenia z chmurą.

Kolejnym krokiem jest konfiguracja klienta AWS IoT. W tym formularzu wystarczy wpisać wszystkie dane przygotowane wcześniej zgodnie z instrukcją producenta.

Nawigacja do AWS IoT client

Formularz konfiguracji AWS IoT w ThingsPro

Poniżej opisy poszczególnych pól:

Target Host: jest to unikalny adres naszego IoT Huba, tzw. Rest API Endpoint. Można go znaleźć w konsoli AWS IoT wchodząc w parametry „rzeczy” Manage Things->Utworzona rzecz->Interact.

Port: Jest to port TCP na którym nasłuchuje usługa AWS IoT. Domyślnie 8883.

Topic: jest ciągiem znaków UTF-8, który jest używany przez broker(AWS IoT) do filtrowania wiadomości dla każdego podłączonego klienta. Topic można znaleźć w konsoli AWS – Manage Things->Utworzona rzecz->Interact.

Client ID , My Thing Name: Są to parametry nie używane przez usługę AWS IoT. Można wpisać dowolny ciąg znaków.

Root CA file: Tutaj trzeba zaimportować certyfikat publiczny, można go pobrać ze strony Symantec:

https://www.symantec.com/content/en/us/enterprise/verisign/roots/VeriSign-Class%203-Public-Primary-Certification-Authority-G5.pem

Należy zapisać go w formacie .pem

Certificate File: Jest to certyfikat wystawiony przez AWS, pobrany zgodnie z instrukcją producenta przy rejestrowaniu „rzeczy”.

Private Key File: Prywatny klucz wygenerowany przez AWS, pobrany razem z paczką „connect_device_package.zip” w trakcie rejestrowania „rzeczy”.

Po kliknięciu Save naszym oczom powinien ukazać się komunikat „AWS IoT data Update successful!”, co oznacza oczywiście sukces. Od teraz gdy któryś z odpytywanych rejestrów Modbus się zmieni, to UC-8112 wyśle wiadomość protokołem MQTT do chmury z nową wartością rejestru. Warto sprawdzić czy dane rzeczywiście dochodzą do AWS, co można łatwo przetestować dzięki wbudowanemu klientowi AWS IoT. Wystarczy przejść w konsoli AWS IoT do „Test”, wpisać odpowiedni „Topic” i kliknąć „Subscribe”. Od tego momentu otrzymujemy wszystkie wiadomości wysłane właśnie z takim „Topic”. Symbol „#” jest dziką kartą, czyli umożliwia nasłuchiwanie wszystkich wiadomości z danej kategorii, z tym samym przedrostkiem. Np. $aws/things/# umożliwia nasłuchiwanie wiadomości od wszystkich utworzonych rzeczy. Ogólnie można przyjąć że „Topic” do wysyłania informacji (update) w AWS IoT ma następującą składnię:

$aws/things/<nazwa rzeczy w AWS>/shadow/update/<Nazwa urządzenia z ustawień połączenia Modbus>/<Nazwa tagu(rejestru) który się zmianił>

 

Sprawdzanie czy wiadomości od ThingsPro dochodzą do AWS IoT Core

Jeśli widzimy że dane nie dochodzą to znaczy że trzeba dokładnie przejrzeć wszystkie wprowadzone dane i certyfikaty w UC-8112. W trakcie testów warto też używać najbardziej ogólnych „Topic” z „#” na końcu, aby mieć pewność że słuchamy wszystkich wiadomości.

Co dalej możemy zrobić z takimi danymi? O tym w następnym akapicie.

Reguły i skrypty

Następnym krokiem jest dodanie 2 reguł reagujących na otrzymanie konkretnych topików. W tym celu należy przejść do Act->Create i wypełnić formularz. Tam należy nazwać naszą regułę wraz z opisem, podać atrybuty jakie mają być przekazywane (w naszym przypadku wystarczy podać * aby wszystkie atrybuty z danego topika były przekazywane), podać topik na którym będziemy nasłuchiwać wiadomości oraz opcjonalny warunek związany z wartością atrybutu. Następnie należy wybrać akcję, czyli usługę do której zostanie wysłany strumień danych, czyli wartości odpytywanych rejestrów Modbus.

Można wybrać usługę Amazon Kinesis Stream, i później przekierować w niej dane do dysku S3, ale format w jakim jest to realizowane to partycjonowany (rok/miesiąc/dzień/godzina) plik json, a chcemy aby dane można było łatwo wyeksportować i używać ich w innych usługach, np. w QuickSight. W tym celu trzeba utworzyć prostą funkcję do konwersji strumienia danych do pliku CSV, w usłudze „Lambda” w AWS. Lambda to usługa bezserwerowa która umożliwia hostowanie funkcji napisanych w różnych językach programowania, można je wywoływać z innych usług AWS, bądź zgodnie z harmonogramem (cron). Tworzymy funkcje, należy ją nazwać, wybrać język programowania, utworzyć odpowiednią rolę aby skrypt mógł zapisywać dane w S3.

Dodawanie nowej funkcji Lambda

Wybór języka programowania

Na tym grafie zaprezentowane są uprawnienia, tj. jakie usługi AWS mogą wywołać funkcję, oraz do jakich usług ma dostęp ta funkcja

W moim przypadku wybrałem python jako język programowania, poniżej kod:

Kod źródłowy funkcji która zapisuje otrzymany strumień danych na dysku chmurowym S3 w formacie CSV

W polu „Handler” wpisujemy nazwę funkcji która będzie domyślnie wywołana ze skryptu. Zapisujemy funkcję i od teraz za każdym razem kiedy komputer UC-8112 wyśle dane to zostanie wywołana jedna z funkcji w usłudze Lambda. Funkcje są 2 ponieważ każda jest wywoływana w zależności od tego czy dane pochodzą od iologik E1210 czy od analizatora energii UMG 604. Funkcje to dość elastyczny sposób na przetwarzanie danych, ponieważ oprócz konwersji do CSV mogą one również zmienić jednostkę, wygenerować dodatkową kolumnę danych itp..

Oczywiście zanim nasz skrypt zacznie działać należy mieć już wcześniej utworzony „bucket” w S3, a po polsku wiaderko, czyli obiekt w którym będziemy przechowywać dane. Można to porównać to partycji na dysku. Nazwa bucket musi być unikalna globalnie, we wszystkich regionach AWS, ponieważ bezwzględnie identyfikuje dane wiaderko. Gdy nasza funkcja jest gotowa i zapisana możemy wrócić do dodawania akcji w IoT Core. Należy dodać akcję, wybrać wywołanie funkcji Lambda i wybrać stworzoną funkcję z rozwijanej listy. Na koniec należy zapisać akcję i przejść do testowania.

Testowanie

Aby sprawdzić czy wszystko działa zgodnie z założeniami należy sprawdzić czy pliki EnergiaCzynna.csv oraz LicznikDI0.csv aktualizują się wraz z każdą zmianą odpytywanych przez UC-8112 rejestrów Modbus. Wystarczy przejść do S3 wybrać odpowiedni bucket i przejść do katalogu w którym zapisywane są dane i pobrać pliki na dysk.

Naszym oczom ukażą się takie oto logi:

Co dalej?

Na tym etapie mamy utworzoną topologię w której komputer UC-8112 odpytuje rejestry Modbus 2 urządzeń, gdy któryś z odczytywanych rejestrów się zmieni to rejestr jest wysyłany do AWS IoT Core. Następnie dzięki zdefiniowanym akcjom dane te są wysyłane do funkcji lambda napisanej w pythonie, konwertowane do formatu CSV i zapisywane w magazynie chmurowym S3. Brzmi to nieco skomplikowanie ale konfiguracja jest stosunkowo prosta, i nie wymaga wielkiej wiedzy. Ale co dalej robić z takimi danymi? Można je zostawić w spokoju i traktować jako archiwum danych Modbus. Można też pobrać na dysk lokalny, zaimportować do Excela i analizować, czy wizualizować dane. Można też zaimportować takie dane w QuickSight AWS czyli usłudze podobnej do Excella, ale bardziej uproszczonej, ułatwiającej analizę i wizualizację danych. Należy przejść do usługi QuickSight i dodać „New data set”. Aby zaimportować poprawnie plik csv należy przygotować plik manifest który opisuje jak ten plik jest sformatowany, oraz gdzie się znajduje, poniżej plik manifest przygotowany do zaimportowania przygotowanych plików csv:

{
    "fileLocations": [
        {
            "URIs": [
                "https://s3.amazonaws.com/wiadro-iot/tmp/LicznikDI0.csv"
            ]
        }
    ],
    "globalUploadSettings": {
        "format": "CSV",
        "delimiter": ",",
        "containsHeader": "true",
        "textqualifier": "'"
    }
}

 

Następnie wystarczy przypisać odpowiednie dane do osi oraz typ wykresu aby cieszyć się wizualizacją naszych danych:

Można też odświeżać źródło danych aby w wizualizacji zawsze pokazywały się aktualne wartości. Można też zaplanować aby dane odświeżały się automatycznie zgodnie z ustalonym harmonogramem. Jest też możliwość tworzenie KPI czyli kluczowych wskaźnik efektywności, na podstawie importowanych danych.

Wnioski

Jeśli czytasz to od początku to dziękuję za wytrwałość, był to dosyć długi wpis. Ciężko było poruszyć ten temat w krótszym formacie nie pomijając najważniejszych rzeczy, a i tak jest to tylko wierzchołek góry lodowej rozwiązań chmurowych.

UC-8112 + oprogramowanie ThingsPro + usługi Chmurowe tworzą bardzo ciekawą synergiczną mieszankę, która umożliwia tworzenie nowoczesnych aplikacji w myśl idei przemysłu 4.0 i IIoT. ThingsPro umożliwia wysyłanie danych z sieci przemysłowych do dostawców chmurowych, a tam dalszą ich obróbkę, przetwarzanie, wizualizowanie, wysyłanie powiadomień email/sms w razie spełnienia zdefiniowanego warunku, uczenie maszynowe, przechowywanie, wizualizowanie, upublicznianie i wiele więcej. Jeśli nawet z jakichś przyczyn użytkownik chce tylko przechowywać dane w S3 AWS, a korzystać z innego dostawcy, np. hostingu, to również nie ma problemu aby takie dane odczytywać za pomocą dostarczanych api i sdk Amazona.

Nie wspominałem też o innych przydatnych funkcjach samego ThingsPro o których warto napisać. Ponieważ komputer UC-8112 bazuje na Linuxie to można na nim uruchamiać i monitorować programy do obróbki odczytywanych danych, udostępniać te dane na inne sposoby, np. za pomocą RESTful api, wysyłać dane do ogólnych brokerów MQTT, łączyć się przez sieć komórkową (modem dostępny oddzielnie), wysyłać log z danymi na zdefiniowany serwer http. Możliwości jest wiele, dlatego ThingsPro jest bardzo elastycznym rozwiązaniem do łączenia danych z sieci przemysłowych z usługami chmurowymi i innymi aplikacjami.

Zapraszam do lektury innych wpisów na naszym blogu!

Źródła i przydatne linki:

Przykładowa podobna aplikacja z bloga AWS:

https://aws.amazon.com/blogs/big-data/build-a-visualization-and-monitoring-dashboard-for-iot-data-with-amazon-kinesis-analytics-and-amazon-quicksight/

Instrukcja AWS IoT od Moxy:

https://www.moxa.com/doc/tech_notes/Moxa_Tech_Note---ThingsPro_AWS_IoT_Application.pdf

Dokumentacja AWS IoT Core:

https://docs.aws.amazon.com/iot/latest/developerguide/iot-gs.html

Jak przetwarzać dane w ThingsPro i wysyłać je do AWS:

https://www.moxa.com/doc/tech_notes/Moxa_Tech_Note---How_to_Publish_Processed_data_to_AWS_IoT.pdf

Jak wysyłać dane Modbus do zdalnej bazy danych z użyciem „Log Upload Function”:

https://www.moxa.com/doc/tech_notes/Moxa_Tech_Note---ThingsPro_Using_Log_Upload.pdf

Zarządzanie zdalnymi urządzeniami polowymi z użyciem VPN i ThingsPro:

https://www.moxa.com/doc/tech_notes/Moxa_Tech_Note---ThingsPro_Using_OpenVPN_Remote_Control.pdf