loading...

Czasy, gdy otaczały nas tylko i wyłącznie urządzenia mechaniczne i analogowe minął bezpowrotnie. Obecnie praktycznie każde urządzenie wyposażone jest chociaż w najprostszy cyfrowy układ logiczny. W ostatnich latach wraz z upowszechnieniem komunikacji bezprzewodowej, w szczególności z wykorzystaniem sieci GSM, pojawił się trend, aby te urządzenia zaczęły się ze sobą komunikować na szeroką skalę. Ma on wpływ nie tylko na sprzęty codziennego użytku. Przede wszystkim pojawia się tam, gdzie mamy do czynienia z rozległymi instalacjami.

Infrastruktura wodociągowa, energetyczna, gazociągowa, przepompownie ścieków – wszędzie tam pojawia się problem zarządzania dużą ilością rozproszonych układów sterowania lub monitorowania. Bez komunikacji każdy z nich pracuje autonomicznie aż do czasu awarii. Wtedy konieczny jest przyjazd służb serwisowych. O ile w przypadku linii produkcyjnej, która mieści się w jednej hali znalezienie usterki nie jest wielkim problemem, to w przypadku awarii w sieci obiektów rozsianych po całej Polsce czy chociaż województwie przypominałoby szukanie igły w stogu siana.

Do niedawna przesyłane dane ograniczały się do niezbędnego minimum i pozwalały jedynie na zlokalizowanie usterki. W XXI w. to jednak za mało. Aby być konkurencyjnym na bardzo dynamicznym rynku, nie można pozwolić sobie np. na przestoje w dostawach energii, wody czy innych mediów. Z kolei przy zarządzaniu rozległym zespołem hal produkcyjnych, każda nieplanowana akcja serwisowa pociąga za sobą wymierne straty finansowe.
Żeby skutecznie kontrolować całą sieć rozproszonych układów sterowania, musimy zbierać wszystkie niezbędne dane. Tylko wtedy możliwe będzie szybkie zdiagnozowanie przyczyny ewentualnej awarii. Po pewnym czasie, w oparciu o dane historyczne i aktualnie przesyłane przez urządzenia, system będzie w stanie nawet prognozować i zapobiegać podobnym zdarzeniom.

Transmisja dużej ilości danych na duże odległości niesie ze sobą poważne wyzwania. Okazuje się, że najpopularniejsze protokoły komunikacyjne, mimo że są wykorzystywane w tym celu, nie do końca spełniają stawiane im wymagania.

Protokoły Real Time w aplikacjach telecontrol

Istnieje wiele przemysłowych protokołów komunikacyjnych. Wśród nich można wyróżnić sporą grupę tzw. protokołów czasu rzeczywistego, jak MODBUS czy PROFINET. Ich istotą jest cykliczne odpytywanie wszystkich urządzeń przez system centralny. Cechują się one dużą szybkością działania oraz stałym i powtarzalnym czasem cyklu komunikacyjnego, dlatego są powszechnie stosowane w układach sterujących, takich jak linie produkcyjne.

To, co sprawdza się nawet w złożonych liniach produkcyjnych okazuje się jednak problematyczne, gdy mamy do czynienia z rozproszoną siecią stacji oddalonych(tzw. RTU – Remote Terminal Units). Komunikacja na duże odległości, często z wykorzystaniem łączy radiowych wprowadza opóźnienia w transferze danych, które mogą wpływać na niezawodność działania protokołów RT. Nie mniej ważny jest fakt, że opieranie komunikacji o schemat zapytanie<>odpowiedź generuje duży, najczęściej niepotrzebny ruch sieciowy, co w przypadku komunikacji po GSM może zwiększać koszty utrzymania instalacji.

Większym wyzwaniem są jednak potencjalne opóźnienia i przerwy w komunikacji. Dotyczy to zwłaszcza transferu z wykorzystaniem sieci GSM. W momencie kiedy priorytetem nie jest już szybkość, ale kompletność informacji jakie otrzymujemy, niedopuszczalne jest, aby okres braku komunikacji był dla nas „białą plamą”. Zwłaszcza, że analiza tego co działo się tuż przed i po utracie łączności mogłoby pomóc zapobiegać takim wydarzeniom w przyszłości.

Protokoły telemetryczne – geneza

Rozwiązaniem są tzw. protokoły telemetryczne. Rozwijały się one trochę na uboczu głównego nurtu protokołów przemysłowych. Ich twórcy borykali się z wolną transmisją danych, która wtedy odbywała się za pomocą połączeń telefonicznych. Patrząc na ilość danych i obszar z jakiego były zbierane, można je uznać za prekursora idei Internet of Things.

Opierają się one na pięciu podstawowych filarach:

  1. System centralny nie odczytuje danych w sposób ciągły/online. Dane mogą być dostarczane z pewnym opóźnieniem.
  2. System centralny monitoruje, a nie steruje w czasie rzeczywistym.
  3. Transmisja danych ze stemplem czasu. Aby przesłane dane były użyteczne dla systemu centralnego, konieczne jest powiązanie zdarzenia z czasem, w którym wystąpiło. Jeśli transmisja może się opóźnić, oznacza to dodanie tzw. stempla czasu do standardowej ramki komunikacyjnej.
  4. Komunikacja zdarzeniowa. W celu optymalizacji transferu danych schemat komunikacji został odwrócony. Sterownik RTU (stacja oddalona) wysyła do systemu centralnego informacje spontanicznie. Transmisja inicjowana jest np. zmianą wartości monitorowanej.
  5. Buforowanie danych podczas przerw w komunikacji. Protokoły telemetryczne posiadają system buforowania zdarzeń w pamięci urządzeń na wypadek utraty komunikacji. Systemy centralne mogą po odzyskaniu połączenia zażądać przesłania tej historii w celu uzupełnienia własnej bazy danych.

Protokoły telemetryczne – podział

Obecnie powszechnie wykorzystywanych jest tylko kilka standardów takiej komunikacji. Podstawowymi rozwiązaniami są protokoły DNP3 (w wersji ETHERNET i szeregowej), IEC60870-5-104 (po ETHERNET) i IEC60870-5-101 (komunikacja szeregowa). Z kolei do obsługi zabezpieczeń energetycznych i sterowników polowych opracowano protokół IEC60870-5-103.

Najnowszym rozwiązaniem jest protokół IEC61850. Rozszerza on jeszcze bardziej ideę komunikacji na obiektach związanych z produkcją i dystrybucją energii. Aby uporządkować rosnącą ilość danych, wprowadzone zostały struktury danych. Oprócz tego norma zdefiniowała typy danych dla takich obiektów jak stacja transformatorowa, zabezpieczenie energetyczne czy elektrownia wiatrowa. Ułatwia to znacząco integrację urządzeń pochodzących od różnych producentów.

Chyba jednak najważniejszą innowacją wprowadzoną przez standard IEC61850 było dodanie szybkiej komunikacji pomiędzy urządzeniami znajdującymi się na tym samym obiekcie. Każde z urządzeń, np. wyłącznik i zabezpieczenie, niezależnie komunikuje się z systemem SCADA wykorzystując podstawową komunikację IEC61850 bazującą na protokole MMS. Dodatkowo urządzenia mogą komunikować się pomiędzy sobą przy pomocy protokołu GOOSE, który jest częścią ww. standardu. Przy zastosowaniu odpowiednich komponentów sieciowych możliwe jest osiągnięcie czasów reakcji nawet w okolicach 1 ms, co pozwala wykorzystywać to rozwiązanie także w automatyce zabezpieczeniowej.

IEC60870-5-104 – uniwersalne rozwiązanie nie tylko dla energetyki

Mimo że początkowo omawiane rozwiązania rozwijane były dla branży energetycznej, to mogą swobodnie znaleźć zastosowanie w innych obszarach. Przykładem takiego uniwersalnego protokołu jest właśnie standard IEC60870-5-104 zbudowany w oparciu o opisane wcześniej podstawy. Dodatkowo istnieje możliwość tworzenia wielu równoległych kanałów komunikacji na wypadek awarii jednego systemu SCADA.

Oprócz standardowych typów zmiennych przesyłanych przez sterownik do systemu SCADA, IEC60870-5-104 posiada także obiekty komunikacyjne, za pomocą których możliwe jest wysterowanie urządzeń oddalonych.

Niezbędnym dodatkiem są mechanizmy synchronizacji czasu. Tylko jeśli czas na wszystkich urządzeniach w sieci będzie identyczny, zebrane dane można uznać za poprawne i użyteczne do późniejszej analizy. Dotyczy to zwłaszcza analizy sekwencji zdarzeń w celu znalezienia bezpośredniej przyczyny awarii systemu.

WAGO a protokoły telemetryczne

Praktycznie każdy sterownik programowalny WAGO ma swoją wersję telecontrol. Wybierając takie urządzenia dostajemy w oprogramowaniu WAGO- I/O-PRO 32 CAA lub e!COCKPIT dostęp do konfiguratorów komunikacji w oparciu o wybrane protokoły telemetryczne. Graficzny interfejs użytkownika pozwala na konfigurację całej komunikacji, bez konieczności napisania nawet jednej linijki kodu. Dzięki pełnej zgodności z normami późniejsza integracja z systemami SCADA jest sprawna i bezproblemowa.

Sterowniki telemetryczne dostępne są w wersji o podwyższonym zakresie temperatur pracy (-20°C … +60°C). Część z nich jest też dostępna w wariancie XTR. Oznacza to odporność na temperaturę w zakresie -40°C … +70°C oraz na kondensację pary wodnej. Jest to niezbędne przy instalowaniu urządzeń w rozdzielnicach napowietrznych.

Jeśli sterownik nie musi obsługiwać dużej liczby kart wejść/wyjść, optymalnym rozwiązaniem są urządzenia ECO. Liczba modułów I/O ograniczona jest wtedy do 4.

Najbardziej wszechstronny jest sterownik 750-8207/025-001 zintegrowany z routerem GSM. Połączenie 2 urządzeń w jedno daje sporą oszczędność miejsca na szynie montażowej oraz niższy koszt niż przy zastosowaniu oddzielnych urządzeń.

Pełen przegląd oferty poniżej:

Nr katalogowy Nazwa Uwagi
sterowniki ECO
750-880/025-002 sterownik telecontrol ECO maks. 4 moduły
750-8202/025-002 sterownik PFC200 telecontrol ECO maks. 4 moduły + wbudowany RS-232/485
sterowniki XTR (-40°C … +70°C)
750-880/040-001 sterownik telecontrol XTR
750-8202/040-001 sterownik PFC200 telecontrol XTR wbudowany RS-232/485
750-8206/040-001 sterownik PFC200 telecontrol XTR wbudowany RS-232/485 + CAN + ProfiBUS slave
Pozostałe
750-880/025-001 sterownik telecontrol
750-8202/025-001 sterownik PFC200 telecontrol  wbudowany RS-232/485
750-8206/025-001 sterownik PFC200 telecontrol  wbudowany RS-232/485 + CAN + ProfiBUS Slave
750-8208/025-001 sterownik PFC200 telecontrol  wbudowany RS-232/485 + CAN + ProfiBUS Master
750-8207/025-001 sterownik PFC200 telecontrol  wbudowany RS-232/485 + GSM(3G)
750-8212/025-001 sterownik PFC200 G2 telecontrol  wbudowany RS-232/485 + mocniejszy procesor

Modularność się opłaca

Także w tak specyficznych zastosowaniach modularność systemu automatyki WAGO stanowi jego największą siłę. Dzięki różnym modułom wejść/wyjść istnieje możliwość monitorowania praktycznie każdego rodzaju sygnału. Dodatkowo obsługa wielu standardów komunikacji otwiera drogę do tworzenia wszelkiego rodzaju bramek komunikacyjnych. Za pomocą sterowników WAGO można wyposażyć praktycznie dowolne urządzenie w telemetryczny interfejs komunikacyjny.

Krzysztof Nosal, WAGO.PL

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *