Jak przesłać Modbus TCP za pomocą MQTT przez sieć WAN

04.09.2019 How to / Komunikacja przemysłowa

Piotr Gocłowski Były pracownik Elmark Automatyka S.A.

Producent: MOXA

Zakłady przemysłowe

Wstęp

Co jakiś czas wraca do nas temat zdalnego dostępu do urządzeń i maszyn przez sieć WAN, wszystkie wpisy z tej tematyki można znaleźć pod tym adresem: Zdalny dostęp. Bardzo często zachodzi potrzeba przesłania danych pomiędzy urządzeniami w różnych lokalizacjach. Sposobów na to jest cała masa, część z nich opisywaliśmy już na naszym blogu. W tym wpisie skupimy się na ciekawym sposobie przesyłania danych, konkretnie protokołu Modbus TCP, za pośrednictwem protokołu MQTT. Firma Moxa opublikowała na wiosnę nowy firmware do konwertera protokołów MGate 5105 który wspiera od teraz protokół MQTT. Ale czym właściwie jest ten protokół, jak działa? W dużym skrócie jest to lekki protokół komunikacyjny działający zgodnie z wzorcem publikacja / subskrypcja. Nie wymaga on dużej przepustowości, jest łatwy w użyciu i elastyczny, ponieważ umożliwia realizację komunikacji w schematach jeden do jednego, jeden do wielu, wielu do jednego. Do komunikacji pomiędzy urządzeniami zawsze potrzebny jest jeden broker MQTT, czyli serwer pośredniczący w komunikacji. Dużą zaletą tego protokołu jest to że każdy podłączony klient może zarówno publikować w brokerze pod danych tematem (topic), jak i subskrybować inny. Po tym przydługim wstępie przejdźmy do opisu topologii.

Opis topologii

W powyższym scenariuszu MGate 5105 po lewej stronie odczytuje dane protokołem Modbus TCP z ioLogik E1210, do którego podłączone są 3 przełączniki elektryczne zmieniające stan wejść cyfrowych, odczytuje również energię czynną z analizatora energii Janitza UMG 96RM-E. Dane te są zapisywane w pamięci MGate 5105 i wysyłane do IOT huba w chmurze Amazon Web Services (AWS), który jest w istocie brokerem MQTT. MGate 5105 po prawej stronie subskrybuje dane wysyłane przez pierwszego MGate 5105, a więc jak tylko pojawią się one w brokerze to są one odbierane w bramce po prawej, i mapowane w pamięci. Jeśli stan tych rejestrów się zmieni to do ioLogik E1214 zostanie wysłane zapytanie Modbus, aby zmienić stan wyjścia cyfrowego, do którego podłączona jest kolumna sygnalizacyjna, tym samym zapali się lub zgaśnie konkretny sygnalizator kolumny. MGate 5105 będzie również wysyłał cyklicznie komendę Modbus ze zużyciem energii z analizatora energii UMG z innej lokalizacji, która została otrzymana z AWS IoT hub. Komenda ta będzie wysyłana do sterownika PLC Unitronics US7-B5-B1, gdzie uruchomiona jest wizualizacja tej wielkości oraz jej trendu.

Całość ma na celu zaprezentowania jak dosyć niskim kosztem można przesłać dane Modbus pomiędzy dwiema niezależnymi lokalizacjami, z użyciem protokołu MQTT. Nie są wymagane publiczne adresy IP, wystarczy dostęp do Internetu w obu lokalizacjach, a konkretnie do usługi AWS IoT hub.

Konfiguracja

Poniżej konfiguracja tej topologii w punktach:

Utworzenie 2 rzeczy w AWS IoT hub i pobranie kluczy i certyfikatu
Konfiguracja MGate 5105 z lewej strony topologii:
- Ustawienia sieciowe – wymagana jest brama (Gateway) umożliwiająca dostęp do Internetu
- Wariant konwersji – ustawienie klienta brokera MQTT (Json) oraz Modbus TCP server jako urządzenie, z którym MGate się łączy
- Modbus TCP client – tworzenie zapytań do odpytywania ioLogik E1210 i analizatora UMG 96RM-E
- MQTT, konfiguracja brokera oraz formatu wiadomości json
- Mapowanie danych Modbus – MQTT
- Sprawdzenie, czy dane dochodzą do AWS IoT hub w konsoli AWS
Konfiguracja MGate 5105 po prawej stronie topologii:
- Ustawienia sieciowe, również wymagany dostęp do Internetu
- Wariant konwersji, w tym przypadku brama ponownie jest masterem Modbus, i klientem MQTT
- Modbus TCP client – konfiguracja zapytań zapisujących rejestry w sterowniku Unitronics, a także ioLogiku sterującym więżą sygnalizacyjną
- MQTT, konfiguracja brokera oraz formatu wiadomości json. Wiadomość oraz topic muszą być zgodne z konfiguracją pierwszego MGate, inaczej dane nie zostaną odczytane z brokera.
- Mapowanie danych Modbus – MQTT
- Sprawdzenie, czy dane z 5105 po lewej stronie przechodzą do bramki po prawej stronie topologii, np. za pomocą I/O data view, w obu bramkach.
- Sprawdzenie, czy rejestry Modbus są zapisywane poprawnie, wizualizacja na sterowniku i na wieży sygnalizacyjnej

Konfiguracja krok po kroku w formie galerii:

Galerie można też pobrać tu:

Galeria

Kalkulacja kosztów AWS

W podanym przykładzie dane z lokalizacji 1 są wysyłane tylko w razie zmiany wartości rejestru Modbus. Wyznaczę pewne założenia, aby móc zaprezentować kalkulację. Całkowity koszt AWS IoT hub składa się z kosztu łączności, czyli ilości czasu gdy połączenie pomiędzy bramkami a brokerem było ustanowione, a także z kosztów wysłanych wiadomości. Koszt wiadomości składa się kosztów publikowanie wiadomości w brokerze, a także z kosztów wysyłania danych z brokera do innych urządzeń, poniżej wzory:

Koszt wiadomości + koszt połączenia = całkowity koszt

Koszt wiadomości = koszt publikowania + koszt wysyłania przez broker

W przykładzie z tego wpisu w tym samym czasie połączone są 2 bramki do brokera. Czyli łączny czas połączenia obu bramek w ciągu miesiąca wyniesie:

2 połączenia x 60 minut x 24 godziny x 30 dni = 86 400 minut połączenia w ciągu miesiąca.

Zakładając że każdy rejestr będzie się zmieniał raz na 10 sekund i generował 1 wiadomość to kalkulacja wygląda następująco:

4 rejestry x 6 wystąpień/min x 60 min/h x 24 h/dobę x 30 dni = 1 036 800 wiadomości publikowanych miesięcznie, ta sama ilość dotyczy wiadomości wysyłanych przez broker do MGate 5105 po prawej stronie, co oznacza że całkowita ilość wiadomości to 2 073 600.

Koszt łączności = 0.096 $ / 1 milion minut połączenia

Koszt wiadomości (do maks. 1 miliarda wiadomości) = 1.2 $ / 1 milion wiadomości

Czyli ostateczna kalkulacja będzie wyglądała tak:

2 073 600 x 1,2$/1 000 000 + 86 400 x 0,096$/1 000 000 = 2,49$ + 0,01 $ =2,5 $

Przy obecnym kursie wynoszącym 3,93 zł / 1 $, koszty te wyniosą 9,82 zł za miesiąc. Jak widać nie jest to kwota wygórowana biorąc pod uwagę, że można w ten sposób przesyłać dane pomiędzy każdą lokalizacją, wystarczy tylko dostęp do Internetu i bramka MGate 5105. Dodatkowo takie dane można też przetwarzać w chmurze AWS niezależnie, i np. zapisywać je w bazie danych, wykonywać dodatkową logikę, używać do uczenia maszynowego i wiele więcej.

Warto też dodać, że MGate 5105 wspiera też darmowe, brokery opensource, np. Mosquito, co daje jeszcze większą elastyczność, i jeśli dany użytkownik posiada i używa już serwerów VPS, to dodając tam taki broker MQTT, można nie płacić ani grosza Amazonowi. Instalacja i konfiguracja nie jest skomplikowana, i nie powinna zająć więcej niż 15 minut. Można też używać brokera w sieci lokalnej, ale wtedy tylko klienci z tej sieci będą mogli publikować i subskrybować dane.

Podsumowanie

I w ten oto sposób udało się uzyskać transfer danych z protokołu Modbus TCP za pośrednictwem protokołu MQTT do innej lokalizacji. Nie jest to zbyt skomplikowane, wymaga nieco czasu i odrobinę cierpliwości. MGate 5105 i protokół MQTT można też wykorzystywać na inne sposoby, np. publikować dane w brokerze lokalnym, tak aby lokalna SCADA lub inny system informatyczny był w stanie te dane odczytywać.

Poniżej zalety opisywanej topologii: