Streszczenie
Wprowadzenie łączy ethernetowych w urządzeniach EAZ stworzyło dogodne warunki do implementacji protokołu komunikacyjnego IEC 61850 – rozwiązania powszechnie stosowanego, dającego największe możliwości dostępne do tej pory na rynku m.in. pod względem prędkości przesyłania danych czy ich czytelności – w obiektach sektora wytwarzania i dystrybucji energii średniego i wysokiego napięcia.
Sterowniki zabezpieczeniowe SN i WN z serii e²TANGO z protokołem IEC 61850, zaimplementowane w obiektach klientów Elektrometal Energetyka SA w Polsce i Europie dostarczają wielu ciekawych doświadczeń eksploatacyjnych, stanowiących zarówno wyzwanie w dalszym doskonaleniu rozwiązań, jak i kreujące nowe możliwości dla kolejnych realizacji. W referacie poruszono kwestie związane m.in. z różnicami w implementacji protokołu pomiędzy producentami czy różnego poziomu dostosowania urządzeń w stosunku do standardu, jak również perspektywy rozwoju systemów w poszczególnych obiektach, zalety prostoty użytkowania i ograniczenie awaryjności systemu.
Wstęp
Takie czynniki jak rozwój urządzeń sieciowych, wzrost wydajności procesorów czy spadek kosztów komponentów pozwoliły na zastosowanie w standardzie łączy ethernetowych w urządzeniach elektroenergetycznej automatyki zabezpieczeniowej. Takie rozwiązanie sprzyja implementacji protokołów komunikacyjnych z większymi możliwościami oraz bardziej przejrzystą semantyką bez utraty na szybkości działania w porównaniu do istniejących i powszechnie stosowanych protokołów komunikacyjnych w energetyce jak Modbus, IEC 60870-5-103, DNP3. Jedynym rozwijanym, ustandaryzowanym, powszechnym i przyjętym przez rynek protokołem jest sposób komunikacji oparty o normę IEC 61850. Normę która w założeniach miała jednoznacznie określić wymagania dla urządzeń komunikacyjnych, serwerów danych, klientów danych, komunikacji pionowej (system nadrzędny <-> serwery danych), komunikacji poziomej między różnymi urządzeniami (serwer danych <-> serwer danych), wprowadzić znacznie czytelniejszą i przyjazną semantykę w porównaniu do wcześniejszych protokołów komunikacyjnych oraz jednocześnie zachować wszystko co dobre w poprzednich rozwiązaniach.
Przed opracowaniem protokołu IEC 61850 wszystkie powszechnie stosowane protokoły wywodziły się z czasów komunikacji szeregowej, co wprowadzało ograniczenia w możliwej prędkości oraz ilości przesyłanych danych, najczęściej ograniczając się do przesyłania adresu, wartości oraz stempla czasowego dla danego sygnału bez jakiegokolwiek opisu, co dany sygnał reprezentuje. W takim wypadku równolegle do protokołu komunikacyjnego musi istnieć pełna dokumentacja papierowa z charakterystyką znaczenia danego sygnału. W przypadku IEC 61850 umożliwiono objaśnianie poszczególnych elementów własnymi opisami, sygnały mogą używać właściwości typowych bloków opisujących powszechne funkcje jak np. blok PTOC przeznaczony dla zabezpieczeń nadprądowych zwłocznych. Ponadto eksploracja i podgląd każdego serwera danych będzie możliwy przez dowolnego klienta zgodnego z normą IEC 61850. Takie podejście znacząco podwyższa rozpoznawanie, jakie funkcje posiada dane urządzenie, oraz jakie dane jest w stanie wysyłać do innych urządzeń lub systemu SCADA, a jednocześnie w jak największym stopniu upraszcza i unifikuje konfigurację, wymianę danych do innych urządzeń oraz systemów SCADA.
Tabela 1. Porównanie funkcjonalności poszczególnych protokołów komunikacyjnych
| Protokół | Komunikacja SCADA <-> IED | Komunikacja IED <-> IED | Przesyłanie plików rejestracji | Stempel czasowy wystąpienia |
| Modbus | Tak | Nie | Nie | Nie |
| IEC 608750-5-103 | Tak | Nie | Tak | Tak |
| DNP 3 | Tak | Nie | Tak | Tak |
| IEC 61850 | Tak | Tak | Tak | Tak |
Norma IEC 61850 a rzeczywistość
Norma IEC 61850 jako dokument wiedzy technicznej jednoznacznie określa w jaki sposób ma zostać zaimplementowana komunikacja MMS (do systemu SCADA), GOOSE (pomiędzy urządzeniami), synchronizacja czasu, wymiana plików itp. Definiuje strukturę i zawartość oraz język dla cyfrowych plików opisujących model urządzenia oraz dostępnych węzłów logicznych (pliki ICD, IID, SCD itp.) oraz papierowych dokumentów opisujących pozostałe parametry oraz cechy urządzenia niemożliwe do opisania w wersji cyfrowej (dokumenty MICS, PICS, PIXIT, TIXIT). Pomimo szczytnych założeń, że wymienione wcześniej dokumenty w jednoznaczny sposób opiszą standard komunikacyjny, rzeczywistość pokazała, że w opisie powstały miejsca do indywidualnej interpretacji, a sam standard jest na tyle skomplikowany, że do jego implementacji wykreowały się wyspecjalizowane firmy zajmujące się bezpośrednio implementacją standardu na zlecenie danego producenta w jego urządzeniach lub dostarczaniu gotowych bibliotek programistycznych do własnoręcznego wdrożenia. Z tego też powodu doświadczenia rynkowe pokazały, że pomiędzy poszczególnymi producentami występują różnice w implementacji oraz mniejszy lub większy poziom dostosowania się jednych urządzeń do drugich niekoniecznie w całości zgodnie ze standardem. Dobrym przykładem tutaj jest kolejność ułożenia atrybutów w danym bloku, która jest narzucona przez normę i teoretycznie urządzenie ze złą kolejnością nie powinno być obsługiwane. W praktyce jednak większość klientów poprawnie podłączy się do takiego urządzenia i będzie je obsługiwać bez najmniejszych problemów.
Przykład błędnego ułożenia atrybutów w danym bloku:
<DOType id=”LD0MMXU1_PPV_DEL_phsAB_CMV” cdc=”CMV”>
<DA name=”cVal” bType=”Struct” dchg=”true”
type=”LD0MMXU1_PPV_DEL_phsAB_CMV_cVal_Vector” fc=”MX”/>
<DA name=”q” bType=”Quality” qchg=”true” fc=”MX”/>
<DA name=”t” bType=”Timestamp” fc=”MX”/>
<DA name=”d” bType=”VisString255” fc=”DC”/>
<DA name=”units” bType=”Struct” dchg=”true”
type=”LD0I0GGIO45_AnIn1_MV_units_Unit” fc=”CF”/>
</DOType>
Przykład poprawnego ułożenia atrybutów w danym bloku:
<DOType id=”LD0MMXU1_PPV_DEL_phsAB_CMV”cdc=”CMV”>
<DA name=”cVal” bType=”Struct” dchg=”true”
type=”LD0MMXU1_PPV_DEL_phsAB_CMV_cVal_Vector” fc=”MX”/>
<DA name=”q” bType=”Quality” qchg=”true” fc=”MX”/>
<DA name=”t” bType=”Timestamp” fc=”MX”/>
<DA name=”units” bType=”Struct” dchg=”true”
type=”LD0I0GGIO45_AnIn1_MV_units_Unit” fc=”CF”/>
<DA name=”d” bType=”VisString255” fc=”DC”/>
</DOType>
Innymi przykładami liberalizmu klientów względem normy jest np. niestosowanie się do limitów w nazwach poszczególnych bloków funkcyjnych czy brak sprawdzania poprawności numerowania ich instancji. Standard IEC 61850 obecnie składa się z trzech edycji (Edycja 1, Edycja 2, Edycja 2 Amendment 1) które wprowadzają zmiany w większości niekompatybilne z edycjami poprzednimi. Potrafi to prowadzić do dużych problemów implementacyjnych w przypadku kiedy system SCADA ma zaimplementowaną komunikację w edycji innej niż urządzenia podrzędne. Z naszych doświadczeń połączenie klienta edycji 1 z urządzeniami e²TANGO, posiadającymi komunikację w edycji 2, wymagało skrócenia nazw bloków do limitów obowiązujących w edycji 1 (edycja 2 wprowadza możliwość stosowania dłuższych nazw), oraz uzupełnienia atrybutów, które w edycji 1 są wymagane, a w edycji 2 stały się opcjonalne.
Doświadczenia z implementacji dla PGE Dystrybucja oddział Białystok
Ciekawym przypadkiem implementacji i użycia protokołu IEC 61850 jest system SCADA w PGE Dystrybucja oddział Białystok. Wszystkie nowe oraz modernizowane instalacje oparte są tylko o urządzenia komunikujące się w protokole IEC 61850 i w przeciwieństwie do innych oddziałów nie praktykuje się stosowania koncentratorów danych na stacjach GPZ. Wszystkie urządzenia podłączane są bezpośrednio do serwera danych SCADA, a listy sygnałów konfigurowane są na poziomie dataset-ów urządzeń na stacjach. Takie podejście ogranicza ilość sprzętu, który może ulec uszkodzeniu, a podczas uruchomień w znacznym stopniu przyspiesza sprawdzenie urządzeń i upraszcza ich konfigurację . Jednocześnie w przyszłości, jeżeli nastąpi potrzeba dodania dodatkowych kanałów komunikacji lub wprowadzenia nowej funkcjonalności, będzie to w znacznym stopniu uproszczone i nie zachodzi ryzyko, że koncentratory stacyjne będą elementami limitującymi z powodu braku odpowiedniej funkcjonalności. Z możliwości protokołu wykorzystywana jest obecnie tylko komunikacja pionowa MMS do komunikacji z systemem SCADA, oraz wymagana jest możliwość pobierania zapisów z rejestratora zakłóceń w postaci plików COMTRADE poprzez podfunkcje File Transfer.
Doświadczenia implementacji z innych obiektów w Polsce
W pozostałych przypadkach większość obiektów nadal implementowana jest w sposób tradycyjny, gdzie komunikacja w protokole IEC 61850 odbywa się tylko na drodze od zabezpieczenia e2TANGO do koncentratora stacyjnego, w którym następuje konwersja na inny starszy protokół np. DNP3. Tutaj również najczęściej wykorzystywana jest tylko pionowa komunikacja MMS, sporadycznie pojedyncze blokady realizowane są przy pomocy komunikacji poziomej GOOSE. Na uwagę zasługują implementacje, gdzie do zabezpieczeń łączy się kilka różnych systemów, wykorzystując wiele połączeń i możliwości konfiguracji indywidualnych dataset-ów oraz bloków raportujących dla każdego z nich. Najczęściej takie instalacje spotykane są w obiektach, gdzie istnieją oddzielne systemy energetyczne oraz technologiczne, np. elektrowniach, elektrociepłowniach czy spalarniach. W takich przypadkach najczęściej jedno lub dwa połączenia zajmuje system energetyczny ze skonfigurowaną indywidualną listą sygnałów odpowiednią dla obsługi elektrycznej oraz kolejne jedno lub dwa połączenia wykorzystuje system technologiczny dla którego skonfigurowano tylko sygnały wymagane przez technologię i obsługę technologiczną. Takie podejście pozwala również zrezygnować z koncentratorów danych, jednocześnie upraszczając cały układ, zmniejszając awaryjność. Ułatwia również późniejszą rozbudowę, ponieważ urządzenia e2TANGO pozwalają na podłączenie maksymalnie do 10 klientów, więc w takim wypadku w każdej chwili jesteśmy w stanie dodać kolejny system, konfigurując tylko w urządzeniu listy sygnałów dla nowego systemu lub wykorzystując domyślne prekonfigurowane listy sygnałów.
Doświadczenia implementacji obiektów na Litwie
Od kilku lat energetyka litewska stawia na najnowsze rozwiązania, co wiąże się z tym, że nowe i modernizowane instalacje realizowane są tylko w protokole komunikacyjnym IEC 61850.
W przeciwieństwie do większości instalacji polskich w tym wypadku wykorzystywana jest nie tylko komunikacja pionowa MMS do systemu SCADA, ale również w zaawansowanym zakresie komunikacja pozioma GOOSE. W ramach komunikacji GOOSE realizowane są automatyki ZS oraz LRW, wyłączenia od zabezpieczeń łukoochronnych, blokady międzypolowe oraz wyłączenia i blokady na rozdzielniach nadrzędnych. Z racji realizacji krytycznych czasowo wyłączeń dla zabezpieczenia łukoochronnego wymagane jest spełnienie klasy wydajnościowej P2/P3 dla sygnałów typu 1A (wyłączenia, blokady zabezpieczenia szyn), co oznacza, że czas transmisji takich sygnałów musi wynosić maksymalnie 3 ms od momentu nadania przez jedno urządzenie do momentu odebrania przez inne urządzenia.
Również ze względu na realizację krytycznych automatyk i zabezpieczeń przy pomocy komunikacji cyfrowej, każde urządzenie musi być wyposażone w bezstratną komunikację redundantną, najczęściej realizowaną jako podwójną gwiazdę (Parallel Redundancy Protocol), w takim przypadku do każdego urządzenia podłączone są dwie niezależne drogi komunikacyjne i wszystkie przesyłane informacje są dublowane przez urządzenia nadawcze na obydwie drogi komunikacyjne, natomiast urządzenie odbiorcze przetwarza komunikat, który dotrze do niego pierwszy, a zdublowany komunikat z drugiej drogi odrzuca. W takim wypadku utrata jednej z dróg nie spowoduje utraty nawet pojedynczej informacji.
Elektrometal energetyka, jako jedyny polski producent Elektroenergetycznej Automatyki Zabezpieczeniowej średniego napięcia, i jako jeden z niewielu na świecie, może się poszczycić międzynarodowym certyfikatem instytutu KEMA, otrzymanym po serii pomyślnych testów, sprawdzających zgodność zabezpieczeń e²TANGO z normą IEC 61850 Edycji 2.0., wykonanych w niezależnym laboratorium DNV-GL w Holandii, w poprawnością implementacji w e²TANGO protokołu IEC 61850 potwierdzoną certyfikatem poziomu A (najwyższy).
mgr inż. Wojciech Stępniak, dr inż. Adam Gawłowski, inż. Sebastian Jaworowicz
Elektrometal Energetyka S.A.
Literatura:
[1] IEC 61850-5:2013 Communication networks and systems for power utility automation – Part 5: Communication requirements for functions and device models (Systemy i sieci komunikacyjne automatyzacji przedsiębiorstw elektroenergetycznych — Część 5: Wymagania komunikacyjne dla modeli funkcji i urządzeń)
[2] IEC 61850-6:2009 Communication networks and systems for power utility automation – Part 6: Configuration description language for communication in electrical substations related to IEDs (Systemy i sieci komunikacyjne w stacjach elektroenergetycznych — Część 6: Język opisu konfiguracji komunikacji pomiędzy urządzeniami IED w stacjach elektroenergetycznych)
[3] IEC 61850-7-4:2010 Communication networks and systems for power utility automation – Part 7-4: Basic communication structure – Compatible logical node classes and data object classes (Systemy i sieci komunikacyjne w stacjach elektroenergetycznych — Część 7-4: Podstawowa struktura komunikacyjna — Kompatybilne klasy węzłów logicznych i danych)
[4] Wimmer, Wolfgang. (2014). IEC 61850 Edition 2 and Engineering. pacworld.
