Jak wykorzystać bezpłatną licencję AVEVA InTouch HMI do systemu z interaktywną mapą?

Niejednokrotnie zdarza się, że projektując systemy pracujące w przemyśle i energetyce (zwłaszcza odnawialnej), a nawet budując projekty hobbystyczne, możemy mieć potrzebę stworzenia aplikacji przedstawiającej pewne dane z wykorzystaniem interaktywnej mapy. Mając odpowiednią wiedzę programistyczną można taką aplikację napisać samodzielnie, od zera – wymaga to jednak sporego zaangażowania i może być trudne w utrzymaniu oraz skalowaniu.

W tym artykule chciałbym podzielić się doświadczeniami, jak można wykorzystać gotowe narzędzia, które pozwalają na realizację takiej (i wielu innych) funkcji. W przykładzie wykorzystane zostało oprogramowanie AVEVA InTouch HMI. To narzędzie klasy SCADA jest szeroko wykorzystywane w różnych branżach w przemyśle. Część z nich, takie jak wod-kan, ciepłownictwo, czy w ostatnich latach coraz bardziej OZE – wymagają przedstawiania monitorowanych danych nie tylko w formie klasycznych ekranów operatorskich, ale również w formie map, na których nanoszone są informacje gromadzone w systemie.

Źródła danych w tego typu aplikacjach mogą być przeróżne – od urządzeń pomiarowych poprzez sterowniki PLC aż po inwertery fotowoltaiczne, czy nawet API pogodowe. Integrację informacji z tych źródeł ułatwiać będzie szeroka gama najpopularniejszych protokołów komunikacyjnych, z możliwością połączenia do w zasadzie dowolnego źródła danych, poprzez protokoły takie jak MQTT czy OPC UA.

Przykładowa aplikacja zrealizowana w InTouch HMI

Aplikacja wykorzystana w tym przykładzie jest bardzo prosta. Jej założeniem jest zebranie informacji z kilku rozproszonych geograficznie obiektów, w tym przypadku przepompowni, a następnie wyświetlenie części monitorowanych parametrów na mapie.

Struktura pojedynczej przepompowni, jako przykład – nie jest bardzo rozbudowana. Schematycznie została przedstawiona na rysunku 3. Jednymi z wielu parametrów pracy takiej przepompowni są wartości poziomów, przepływów oraz parametry pracy i sterowania dwóch pomp, będących sercem takiego obiektu.

Kluczowe jest to, że struktura takiej przepompowni jest drzewiasta oraz zawiera powtarzalne obiekty – właściwość ta będzie mogła być wykorzystana przy odwzorowaniu fizycznych urządzeń w formie szablonów obiektów – przygotowanych jednokrotnie i następnie wykorzystanych wiele razy.

Część z tych parametrów jest wysyłana do systemu centralnego. W tym celu został wykorzystany protokół MQTT, znany z zastosowania w aplikacjach typu IIoT. W naszym przypadku została wykorzystana komunikacja w specyfikacji SparkPlug, co daje ciekawe możliwości z punktu widzenia konfiguracji programu komunikacyjnego.

Sposobów wymiany danych w takiej architekturze jest oczywiście więcej – jeżeli obiekty są połączone z centralnym systemem poprzez tunel VPN, często taka komunikacja jest realizowana po protokole Modbus TCP lub OPC UA.

Wykorzystanie specyfikacji SparkPlug ogranicza możliwość jawnego odczytania danych, ale z drugiej strony – ustandaryzowany sposób przesyłania pozwala na łatwiejszą obsługę tych informacji na poziomie programu komunikacyjnego.

Konfiguracja odczytu danych po protokole komunikacyjnym MQTT

W pierwszym kroku budowania naszej aplikacji konieczne jest skonfigurowanie programu komunikacyjnego, który będzie odczytywał dane z urządzeń / lokalizacji końcowych. W tym przypadku wykorzystujemy program komunikacyjny OI.MQTT. Jeżeli nie mamy potrzeby zabezpieczania brokera szyfrowaniem lub autentykacją (bo przykładowo broker pracuje w sieci lokalnej i tylko my mamy do niego dostęp) – konfiguracja sprowadza się do wskazania adresu brokera i ewentualnej zmiany portu, na którym następuje połączenie.

Należy pamiętać, że przy wykorzystaniu brokera publicznego / otwartego nie wolno przesyłać danych wrażliwych, ani prowadzić sterowania – dowolna osoba podłączająca się do takiego brokera może mieć wpływ na to, co dzieje się w naszej instalacji!

Sam program komunikacyjny wspiera zabezpieczenia komunikacji na dwóch poziomach, które warto wykorzystać:

1. Szyfrowanie z użyciem TLS.

2. Autentykacja użytkowników podłączających się do brokera.

Dzięki tym możliwościom uruchamiając swój własny broker MQTT i samodzielnie zarządzając jego konfiguracją możliwe jest bardzo efektywne zabezpieczenie komunikacji w budowanym systemie.

Jeżeli dane są publikowane przez klientów w specyfikacji SparkPlug, korzystając z zakładki MQTT Browser możliwe jest podglądnięcie całej struktury przesyłanych danych, co widać na rysunku 6.

Na tym poziomie możemy zrealizować również mapowanie  rozbudowanych topików po stronie MQTT do przyjaznych (a na pewno krótszych) nazw zmiennych, wykorzystywanych później na poziomie systemu SCADA. Przydatny do tego celu może być eksport referencji zmiennych do pliku CSV, w którym możemy edytować te nazwy wedle uznania – do późniejszego importu w konfiguracji.

Program komunikacyjny to tylko jeden z wielu elementów składowych docelowego systemu. Będzie on źródłem danych, odczytywanych następnie przez InToucha. Pozostałe główne funkcjonalności oprogramowania to:

• wizualizacja odczytywanych parametrów w różnej formie graficznej,
• logowanie historyczne parametrów oraz alarmowanie,
• integracja z bazami danych, w tym przemysłową bazą danych Historian, na potrzeby archiwizacji danych procesowych,
• realizacja logiki, w ramach wbudowanych skryptów,
• dostęp do wizualizacji w formie klasycznej aplikacji okienkowej, a także przez przeglądarkę obsługującą HTML5.

Powtarzalne obiekty – idealne do implementacji w ramach UDT (User Defined Type)

W scenariuszu monitorowania wielu, rozproszonych i podobnych obiektów, idealnie sprawdzi się wykorzystanie UDT (User Defined Type). Mechanizm ten pozwala na utworzenie szablonu obiektu, zawierającego wszystkie zmienne i parametry, które powinny pojawić się w definicji struktury takiego obiektu. Następnie szablon taki, jest źródłem instancji obiektów – przypisanych już do konkretnych, fizycznych urządzeń i zmiennych – odczytywanych za pośrednictwem programów komunikacyjnych.

Takie podejście sprawia, że utworzenie oraz modyfikacja nawet dużej aplikacji, ale składającej się z podobnych obiektów – może być o wiele szybsza i łatwiejsza, ze względu na to że zmiany wykonane na poziomie szablonu – automatycznie propagują się do wszystkich instancji oraz szablonów pochodnych, pracujących w systemie.

Każda ze zmiennych, wchodząca w skład struktury UDT posiada szereg właściwości – zależnych od wybranego typu zmiennej. Pozwalają one na ustawienie (między innymi): opisu, parametrów alarmowania, czy logowania historycznego, zakresu wartości w jednostkach inżynierskich, etc.

Szablon reprezentujący obiekt przepompowni

Korzystając z funkcjonalności UDT można zatem bez żadnego problemu odwzorować przykładową strukturę obiektu, przedstawioną na rysunku 3. W tym przykładzie zostało utworzonych kilka instancji takiego obiektu, odwołujące się do konkretnych wartości – odczytywanych po protokole MQTT, co zostało opisane wcześniej.

Ciekawym mechanizmem, który może zostać wykorzystany do masowego tworzenia nowych lub edycji istniejących instancji, jest eksport utworzonej konfiguracji od pliku tekstowego w formacie JSON. Znajdują się w nim wszystkie informacje, konieczne do odwzorowania całej struktury UDT w projekcie. Korzystając z narzędzi do edycji obiektu JSON (np. programowanie w Python) możemy zarządzać konfiguracją w sposób masowy – poprzez dodawanie / usuwanie / modyfikacje dziesiątek lub setek instancji i szablonów jedocześnie. Ma to szczególnie istotne znaczenie zwłaszcza w przypadku dużych aplikacji.

Bardzo ważnym elementem, z punktu widzenia wykorzystania mapy, jest konieczność dodania w szablonie atrybutów Longitude oraz Latitude. Obiekty, które posiadają te dwie zmienne, automatycznie traktowane są jako przywiązane do konkretnej lokalizacji. Parametry te mogą być statyczne, ale również mogą zmieniać się w czasie i jeżeli na ekranie wizualizacji będą reprezentowane przez obiekt graficzny – będzie on w trybie Runtime zmieniał swoje położenie na mapie. To sprawia, że możliwa jest prezentacja na mapie zarówno statycznych obiektów (jak w tym przykładzie), ale również tych poruszających się i udostępniających swoją lokalizację, na przykład na podstawie odbiornika GPS.

Konfiguracja mapy

Mając zdefiniowane obiekty, zawierające dodatkowo atrybuty związane z położeniem geograficznym, możemy przejść do skonfigurowania samej mapy. Czy jest to trudne? Widget obsługujący tę funkcjonalność udostępnia nam trzy zakładki:

1. Source – pozwala wybrać dostawcę mapy. Domyślnie jest nim Open Street Map, ale mamy do wyboru kilku innych, takich jak Google Maps czy ArcGis. W takiej konfiguracji, aby mapa mogła działać, wymagany jest dostęp do internetu z komputera, na którym pracuje wizualizacja. Możliwe jest również skonfigurowanie oprogramowania, aby korzystało z mapy w trybie offline.

2. Zoom Layer – pozwala zdefiniować warstwy związane z aktualnym powiększeniem. Wykorzystuje się je potem do zróżnicowania wyświetlanych symboli – w zależności od stopnia powiększenia mapy.

3. Locations – w ramach tej zakładki pojawiają się wszystkie instancje obiektów UDT, które posiadają zdefiniowane współrzędne geograficzne. W tym miejscu podpinamy do obiektów konkretne symbole graficzne (w kolumnie Graphic), które następnie będą wyświetlane na mapie.

Frontend aplikacji

Oprogramowanie InTouch HMI w warstwie graficznej bazuje na technologii Industrial Graphics (znanej wcześniej jako ArchestrA Graphics). Jest to środowisko w pełni wektorowe, z bardzo bogatą biblioteką gotowych elementów oraz możliwościami tworzenia, animowania i skryptowania własnych symboli, okien i synoptyk. Wizualizacja przygotowana w oparciu o Industrial Graphics jest dostępna do uruchomienia zarówno w formie klasycznej aplikacji „okienkowej”, jak również przez przeglądarkę internetową, wspierającą HTML5.

Korzystając z gotowych elementów (łącznie z gotowymi szablonami całej aplikacji z oknami, menu nawigacyjnym, itp.) oraz budując własne obiekty – możemy stworzyć bardzo rozbudowaną aplikację. Symbole, które mają znaleźć się na mapie, muszą zostać podpięte we wskazanej wcześniej konfiguracji widgeta Map_App i od tego momentu będą wyświetlać się na mapie we wskazanych współrzędnymi geograficznymi lokalizacjach.

Jak można zacząć pracę z InTouch?

Oprogramowanie InTouch nie wymaga do pracy licencji inżynierskiej – działa od razu po instalacji i pozwala na zbudowanie aplikacji o dowolnej wielkości. Środowisko wykonawcze (Runtime) oprogramowania będzie działało przez 2 godziny od uruchomienia, po czym się wyłączy – praca w trybie ciągłym wymaga licencji o odpowiedniej wielkości.

Jeżeli w aplikacji zdefiniujemy mniej niż 64 zmienne – Runtime będzie działał w trybie ciągłym bezpłatnie i może być wykorzystywany komercyjnie. To sprawia, że może to być świetna baza do budowania niewielkich aplikacji produkcyjnych lub projektów hobbystycznych.

Więcej informacji można znaleźć na stronie https://www.astor.com.pl/oferta/oprogramowanie-przemyslowe/systemy-scada/aveva-intouch.html