Protokoły telemetryczne w e!COCKPIT: DNP3

Protokoły telemetryczyne umożliwiają coraz większą cyfrową integrację otaczającego nas świata. Korzystając ze swoich unikatowych cech zapewniają komunikację nie tylko pewną, ale również oszczędną w ilości transmitowanych danych.

Główne różnice pomiędzy takimi rozwiązaniami a protokołami czasu rzeczywistego opisano już w TYM artykule. Większe możliwości oznaczają jednak większą złożoność jeśli chodzi o konfigurację. Dlatego zarówno w CODESYS 2.3, jak i od niedawna w e!COCKPIT, funkcjonalności te wprowadzone są nie tylko w formie biblioteki, ale też w postaci graficznego konfiguratora, który znacząco przyspiesza pracę nad projektem i zmniejsza prawdopodobieństwo popełnienia błędów. W tym artykule ograniczę się do rozwiązania dostępnego w e!COCKPIT.
Z protokołów telemetrycznych można korzystać tylko na odpowiednich sterownikach. Większość jednostek głównych PFC200 posiada swoją wersję telemetryczną. Kompletne portfolio można znaleźć we wspomnianym wcześniej artykule.

Struktura aplikacji PLC

Celem instalowania rozproszonych systemów telesterowania jest zdalny monitoring i kontrola różnych obiektów. Aplikacja wykorzystująca komunikację DNP3 ma najczęściej określoną strukturę. Najprostszym programem, jaki można stworzyć jest bezpośrednie udostępnienie fizycznych wejść i wyjść w protokole DNP3. Dzięki konfiguratorom taka aplikacja nie wymaga praktycznie żadnego programowania. W tle może oczywiście działać osobny program PLC realizując funkcjonalności niekoniecznie związane z komunikacją.
Najczęściej jednak istnieje konieczność integracji z innymi urządzeniami, które same nie są wyposażone w odpowiednie interfejsy komunikacyjne. Sterownik pełni wtedy rolę uniwersalnego gatewaya komunikacyjnego.

W oparciu o powyższy schemat można wyróżnić 4 części typowej aplikacji PLC telecontrol:

• zbieranie sygnałów
• program PLC
• konfiguracja DNP3
• mapowanie zmiennych pomiędzy programem PLC a DNP3

Te zagadnienia zostaną opisane w kolejnych częściach opracowania.

Konfiguracja sterownika PLC

Tworzenie prawie każdej aplikacji należy rozpocząć od przeskanowania węzła WAGO w poszukiwaniu podłączonych modułów oraz przypisania nazw do poszczególnych kanałów. Aby nadać nazwy, trzeba w Network view kliknąć w wybrany sterownik, a następnie na odpowiedni moduł. Pojawi się tabela, w której możliwe jest przypisanie nazw kolejnym wejściom i wyjściom fizycznym.

Konfigurator telecontrol

Pozostając w tym samym widoku można teraz zaznaczyć jednostkę główną. Na dole, w tym samym miejscu, gdzie wcześniej nadawaliśmy nazwy symboliczne pojawiło się menu kontekstowe dotyczące dostępnych protokołów komunikacyjnych, takich jak MODBUS czy właśnie protokoły telemetryczne. W celu konfiguracji DNP3 należy przejść do zakładki Telecontrol. Oprócz konfiguratora, w dolnej części ekranu pojawia się też odpowiednie menu na wstążce, w górnej jego części.

Pierwszym etapem jest wybór interesującego nas protokołu. W tym momencie mamy do wyboru tylko DNP3, IEC60870-5-101, IEC60870-5-104 – wszystkie w konfiguracji serwerów (nazywane slave/substation). Więcej możliwości, w tym klient/serwer IEC61850 lub klient IEC60870, obecne są tylko w CODESYS 2.3, ale będą sukcesywnie przenoszone do e!COCKPIT.

Gdy slave DNP3 zostanie dodany, pojawi się drzewo konfiguracji protokołu. Warto pamiętać, że w obrębie jednego projektu możliwe jest dodanie tylko jednego takiego obiektu. W pierwszej kolejności należy ustawić adres DNP3 sterownika. Okno ustawień ogólnych zawiera o wiele więcej parametrów. Ich zastosowanie wytłumaczone zostanie w innym opracowaniu. W większości przypadków nie ma jednak konieczności zmieniania ustawień domyślnych.

Następnym krokiem jest parametryzacja samej komunikacji. Zaznaczając nagłówek Link layer i korzystając ze wstążki Telecontrol należy dodać konieczne połączenia. Możliwe jest skonfigurowanie komunikacji szeregowej i/lub do 4 równoległych połączeń Ethernet. Dla każdego stworzonego połączenia przypisany zostanie niezależny bufor zdarzeń. Dzięki temu, jeśli wystąpi przerwa w komunikacji, wszystkie systemy SCADA dostaną komplet danych historycznych po ponownym nawiązaniu komunikacji.

Ustawienia komunikacji Ethernet obejmują takie parametry, jak adres DNP3 systemu SCADA, protokół komunikacji, port komunikacyjny oraz opcjonalne ustawienia dotyczące filtrowania adresów IP i weryfikację adresów DNP3. Wszystkie te dane, razem z adresem DNP3 sterownika, powinny zostać udostępnione przez osoby odpowiedzialne za integrację systemu od strony systemu SCADA.

Niemniej ważnymi ustawieniami są parametry komunikacji spontanicznej. Jest ona prawdziwą siłą protokołów telemetrycznych. W zależności od tego jaki tryb komunikacji spontanicznej został wybrany, taki pojawia się zestaw parametrów komunikacyjnych. Ustawienia te mają na celu przede wszystkim optymalizację transferu danych. Timeout oraz Unsolicited retries gwarantują, że po określonej liczbie prób wysyłki danych komunikacja spontaniczna będzie zawieszona i będzie czekać na ponowne połączenie z systemem SCADA. Ostatnie dwa parametry odpowiadają za „zbieranie” zdarzeń w pakiety i zbiorcze wysyłanie do systemu nadrzędnego.

Mode	Event threshold	Delay Time	Timer – Mode	Opis
Disabled	xxx	xxx	xxx	Komunikacja spontaniczna nieaktywna
A	>0	xxx	xxx	Telegram zostanie wysłany, jeśli liczba zdarzeń w buforze przekroczy określoną wartość.
B	xxx	>0s	Zerowanie opóźnienia	Telegram zostanie wysłany, jeśli od momentu pojawienia się ostatniego zdarzenia w buforze minie określony czas. Każde kolejne zdarzenie w buforze zeruje odliczanie czasu.
C	>0	>0s	Zerowanie opóźnienia	Telegram zostanie wysłany, jeśli od momentu pojawienia się ostatniego zdarzenia w buforze minie określony czas lub liczba zdarzeń w buforze przekroczy określoną wartość. Każde kolejne zdarzenie w buforze zeruje odliczanie czasu.
D	xxx	>0s	xxx	Telegram zostanie wysłany, jeśli od momentu pojawienia się pierwszego zdarzenia w buforze minie określony czas.
E	>0	>0s	xxx	Telegram zostanie wysłany, jeśli od momentu pojawienia się pierwszego zdarzenia w buforze minie określony czas lub liczba zdarzeń w buforze przekroczy określoną wartość.

 

Domyślnie sterownik będzie czekał z wysłaniem danych przez czas określony parametrem Delay time. W tym czasie każde zdarzenie zostanie dodane do paczki danych. Jeśli jednak wcześniej osiągnięta zostanie liczba określona parametrem Event threshold, dane zostaną wysłane mimo nieosiągnięcia czasu opóźnienia. Parametry te należy ustawić zgodnie ze specyfikacją monitorowanego obiektu oraz wymaganiami aplikacji. Najbardziej uniwersalnym wyborem jest Mode E.

Tworzenie obiektów komunikacyjnych DNP3

Odpowiednie obiekty komunikacyjne dodawane są w podobny sposób co połączenia Ethernet. Najpierw należy zaznaczyć w drzewie konfiguratora rodzaj obiektu jaki chcemy dodać, po czym wybrać odpowiednią opcję na wstążce.

Jeśli chcemy, by zmiana tej zmiennej była wysyłana w ramach komunikacji spontanicznej i zapisana w buforze zdarzeń, należy zmienić parametr Event. Najczęściej zmienne typu BI przypisywane są do grupy eventów 1.

W podobny sposób tworzone są obiekty typu Analog Input. Tu mamy jednak do wyboru 3 rodzaje zmiennych: REAL, 16 bit i 32 bit. Wyboru można dokonać z menu rozwijalnego przed utworzeniem zmiennej lub modyfikując odpowiednie pole po jej stworzeniu.

Tak jak w przypadku obiektów BI, tak i tu możemy przypisać zmienną analogową do grupy event. Jeśli to zrobimy, każda zmiana wartości będzie wysłana do systemu nadrzędnego. Aby nie generować zbędnego ruchu sieciowego, konieczne jest ustawienie odpowiedniej wartości histerezy. Zdarzenie może być też niezależnie generowane cyklicznie, bez względu na przekroczenie wartości histerezy. Jest to dość ciekawe rozwiązanie umożliwiające cykliczną komunikację pomiędzy SCADĄ a sterownikiem, bez konieczności ciągłego wysyłania zapytań przez system nadrzędny oraz z automatycznym buforowaniem wartości historycznych na wypadek przerwy w komunikacji.

Ostatnim często wykorzystywanym obiektem jest Binary Output. Ekran konfiguracyjny umożliwia wybór trybu sterowania oraz podłączenia odpowiednich zmiennych procesowych.

Wybór sposobu sterowania powinien być narzucony przez system SCADA. Różnica polega na zachowaniu zmiennej wyjściowej. W przypadku Activation model zmienna Variable przyjmuje stan wysoki na ściśle ustalony czas wysłany w telegramie DNP3 z systemu SCADA. Z kolei Complementary latch model zmienia wartość zmiennej na stan wysoki, który jest podtrzymywany przez sterownik do czasu odebrania telegramu „Latch Off”. W obu wypadkach odebranie telegramu sygnalizowane jest poprzez nadanie wartości True zmiennej New message na 1 cykl sterownika.

Mapowanie sygnałów z modułów DI

Sygnały z modułów wejść dwustanowych można bezpośrednio podłączyć do obiektów komunikacyjnych DNP3 typu Binary Input. Aby to zrobić, wystarczy rozwinąć menu w polu Status Bit lub wcisnąć klawisz [F2] i wybrać odpowiednią zmienną. Na tym etapie pracę bardzo ułatwiają poprawnie nadane poszczególnym kanałom nazwy symboliczne. Zmienna, która została przypisana już do obiektu DNP3 zaznaczona jest niebieskim łańcuszkiem, co pokazano na grafice poniżej.

Często istnieje konieczność dodania prostej obróbki sygnału przed udostępnieniem do DNP3. Aby dodać taką funkcjonalność, nie trzeba już robić tego samemu w programie PLC. Przy każdej zmiennej z modułu fizycznego w zakładce „Localbus I/O Mapping” znajduje się przycisk z 3 kropkami, który odsyła do odpowiedniego okna dialogowego.

Na tym etapie należy nazwać zmienną będącą wynikiem tego przetwarzania, wybrać rodzaj wstępnej obróbki sygnału i ustalić jej parametry. Po zatwierdzeniu konieczna jest jeszcze zamiana wartości oryginalnej na przetworzoną.

Jak widać na powyższej grafice, zmienna, która została zadeklarowana w oknie „Signal preprocessing ” pojawiła się w menu wybieralnym. Zmienne takie można łatwo poznać, ponieważ znajduje się przy nich symbol błyskawicy.

Mapowanie sygnałów z modułów AI

Proces mapowania sygnałóow analogowych przebiega analogicznie do modułów DI. Trzeba jednak pamiętać o tym, jaki typ obiektu DNP3 wybraliśmy. Jeśli pracujemy na obiektach AI typu REAL, to możemy podłączyć tylko zmienną tego typu. W przypadku prostych modułów analogowych oznaczać to będzie konieczność konwersji danych. Tą mMożna to zrobić bezpośrednio z poziomu konfiguratora.

Mapowanie modułów DO

Istnieje możliwość podłączenia obiektu DNP3 bezpośrednio pod fizyczne wyjście sterownika. Należy jednak pamiętać, że takiego wyjścia nie będzie można wysterować z innych podprogramów PLC.

Mapowanie zmiennych z programu PLC

Do każdego obiektu DNP3 można podłączyć dowolną zmienną zadeklarowaną wewnątrz programu PLC. Proces wygląda podobnie jak w przypadku zmiennych z modułów fizycznych. Po ustawieniu kursora w wybranym polu należy wcisnąć klawisz [F2].

Każda tak zmapowana zmienna pojawia się w drzewie Localbus I/O Mapping razem ze zmiennymi fizycznymi. W przeciwieństwie do sygnałów pobieranych bezpośrednio z modułów nie ma tu możliwości dodatkowego przetwarzania sygnałów. Jest to zrozumiałe, ponieważ i tak wartości te zostały poddane obróbce w ramach aplikacji PLC.

Kompilacja programu

Po skończonej konfiguracji wystarczy przejść do „Programming view” i skompilować aplikację. W drzewie projektu pojawi się wówczas tedy program odpowiedzialny za komunikację DNP3. Automatycznie zostanie też stworzony task, w którym wywołany jest ww. program.

Podsumowanie

W kilku prostych krokach można stworzyć w pełni funkcjonalną aplikację z komunikacją po protokole DNP3. W podobny sposób możliwe jest skonfigurowanie komunikacji z wykorzystaniem standardu IEC60870 (opisane tutaj). Jeśli natomiast aplikacja ogranicza się tylko do obsługi rzeczywistych wejść wyjść za pośrednictwem wybranego protokołu, można skorzystać z samodzielnego narzędzia telecontrol. Znacząco przyspiesza i upraszcza to uruchomienie sterownika i – co nie mniej ważne -, nie wymaga posiadania licencji e!COCKPIT.

Rozwiązanie te zostało krótko pokazane na tym filmie [LINK] i opisane w poniższym artykule: LINK .

Krzysztof Nosal, WAGO.PL

• Tags
• Konfiguracja DNP3
• Konfiguracja sterownika PLC
• Konfigurator telecontrol
• Krzysztof Nosal
• Mapowanie modułów DO
• Mapowanie sygnałów z modułów AI
• protokoły telemetryczne
• Tworzenie obiektów komunikacyjnych DNP3