Artykul - 04.2013 - JM

TECHNOLOGIE, PRODUKTY – INFORMACJE FIRMOWE
Implementacja standardu
IEC 61850 w zabezpieczeniach
i rozdzielnicach JM-TRONIK
Artykuł opisuje praktyczne aspekty związane z przystosowywaniem urządzenia megaMUZ-2
produkcji JM-Tronik do wymagań komunikacji zgodnej ze standardem IEC 61850. Przy okazji
opisu starano się zwracać uwagę na pozytywne i negatywne aspekty wprowadzania standardu
w kontekście zastępowanie protokołów i rozwiązań już istniejących.
Rozdział 2 przedstawia zarys podstawowych cech protokołu IEC 61850. W rozdziale 3 pokazano
wybrane aspekty implementacji protokołu w urządzeniu megaMUZ-2, a w szczególności problemy
związane z określeniem modelu danych urządzenia oraz wybranych abstrakcyjnych usług
komunikacyjnych. Rozdział 4 jest krótką syntezą grupującą wady i zalety zastosowania protokołu
w subiektywnym ujęciu, w odniesieniu do stacji elektroenergetycznych średniego napięcia.
Wstęp
Rozpowszechnienie się sieci lokalnych
opartych o technologię Ethernet od
pewnego czasu obejmuje też swoim
działaniem obszar automatyki elektroenergetycznej. Spośród wykorzystywanych na podstacjach protokołów telekomunikacyjnych najpełniej możliwości
Ethernetu wykorzystuje wdrażany już
od kilku lat protokół oparty o międzynarodową normę IEC 61850 [1]. Producenci urządzeń automatyki elektroenergetycznej stają przed niełatwym zadaniem
dostosowania swych produktów do wymagań zawartych w tym standardzie.
W pracy tej starano się skupić na
praktycznych aspektach związanych
z wdrażaniem IEC 61850. Zwracano
przy tym uwagę zarówno na zalety jak
i na wady, jakie niesie ze sobą implementacja protokołu
Opis protokołu
IEC 61850 wykorzystuje technologię sieci komputerowych LAN (ang. Local Area
Network). Protokół ten, a także jego poprzednik, mniej popularny w Europie
UCA v2.0 (ang. Utility Communications
Architecture), powstały w odpowiedzi
na potrzebę stworzenia wspólnego,
ujednoliconego dla różnych producentów protokołu komunikacyjnego, który
nadążałby za rozwojem wykorzystywanych technologii telekomunikacyjnych.
Norma IEC 61850 definiuje hierarchiczną
strukturę wymiany informacji wprowadzając podział na tzw. magistralę stacyjną i na magistralę procesową. Magistrala
stacyjna sprzęga urządzenia zabezpie-
2
czeniowe, sterowniki polowe oraz system sterowania i nadzoru stacji. Z kolei
do magistrali procesowej podłącza się
urządzenia pierwotne mające możliwość komunikacji zgodnej z IEC 61850
a także podobnie jak w przypadku magistrali stacyjnej zabezpieczenia i sterowniki polowe. Przy okazji hierarchii
należy nadmienić, że w ramach normy
możliwa jest zarówno komunikacja między urządzeniami równorzędnymi (np.
sterownikami polowymi) jak i między
urządzeniami na różnych poziomach
hierarchii (np. komputera systemu sterowania i nadzoru z urządzeniami zabezpieczeniowymi). Schemat hierarchicznej struktury wymiany informacji
IEC 61850 pokazano na rys. 1.
Ujednolicenie komunikacji przewidziano w IEC 61850 przy użyciu dwóch elementów. Pierwszym z nich jest zestandaryzowany model danych, a drugim
tzw. ACSI (ang. Abstract Communication Service Interface), czyli abstrakcyjny interfejs usług komunikacyjnych.
Model danych jest złożoną strukturą, będącą reprezentacją funkcjonalności danego urządzenia współpracującego z IEC
61850. Poszczególne elementy wchodzące w skład tej struktury muszą odpowiadać zdefiniowanym w normie abstrakcyjnym obiektom i klasom danych. Każde
urządzenie zgodnie ze standardem jest
w modelu danych reprezentowane jako
serwer, w którego skład musi wchodzi
przynajmniej jedno urządzenie logiczne
– LD (ang. Logical Device). Każde urządzenie logiczne zbudowane jest natomiast
z węzłów logicznych – LN (ang. Logical
Nodes). Węzły logiczne grupują parametry poszczególnych funkcjonalności, np.
dla zabezpieczenia nadprądowego, sterowania wyłącznikiem lub pomiarów. Elementami składowymi węzłów są obiekty
Rys. 1. Hierarchiczna struktura wymiany informacji IEC 61850
URZĄDZENIA DLA ENERGETYKI 4/2013
TECHNOLOGIE, PRODUKTY – INFORMACJE FIRMOWE
danych – DO (ang. Data Objects), które
to z kolei składają się z atrybutów danych
– DA (Data Attributes), przy czym trzeba nadmienić, że stopień złożoności poszczególnych węzłów logicznych różni
się w zależności od funkcjonalności jaką
węzeł reprezentuje.
Abstrakcyjny interfejs usług komunikacyjnych opisuje poszczególne mechanizmy
wykorzystywane w wymianie informacji
pomiędzy urządzeniami niezależnie od
zastosowanego stosu protokołów, stąd
jego nazwa. Wprawdzie norma w rozdziale 8 [1] przedstawia odwzorowanie
usług za pomocą protokołu MMS(ang.
Manufacturing Message Specification)
w warstwie aplikacji wraz ze stosem TCP/
IP, jednak w założeniach zdefiniowany
w standardzie abstrakcyjny interfejs został zaprojektowany tak, aby nadążać za
rozwojem technologii telekomunikacyjnych. W ACSI przewidziano dwa zasadnicze modele wymiany informacji: model klient/serwer oraz model wydawca/
subskrybent. W oparciu o model klient/
serwer norma definiuje takie usługi jak:
yy raportowanie;
yy wysyłanie rejestracji (logów);
yy sterowanie;
yy edycja nastaw i zmiana aktywnego
banku nastaw;
yy przesyłanie plików.
W oparciu o model wydawca/subskrybent zdefiniowano w standardzie następujące mechanizmy:
yy szybka wymiana między polami informacji zorientowanych obiektowo
GOOSE (ang. General Object Oriented Substation Event);
yy szybka wymiana między polami informacji dwustanowych GSSE (ang.
General Substation State Event);
yy Transmisja wartości spróbkowanych
– SV (ang. Sampled Values).
Komunikacja w modelu klient/serwer
wymaga nawiązania asocjacji (połączenia) między urządzeniami. Po nawiązaniu połączenia klient pobiera całą strukturę modelu danych serwera i uzyskuje
możliwość realizacji zaimplementowanych w danym urządzeniu abstrakcyjnych usług komunikacyjnych. Nie zawsze klient musi odpytywać serwer
chcąc uzyskać dane. Dobrym przykładem na to jest mechanizm raportowania, który wyposażono w rozmaite
sposoby pobudzenia. Mechanizm ten
umożliwia spontaniczną transmisję raportów pod wpływem zmiany wartości jednej z raportowanych danych lub
upłynięcia określonego interwału czasu.
Model wydawca/subskrybent przeznaczony jest do szybkiej wymiany krótkich informacji. W związku z tym, w celu
uproszczenia komunikacji, mechanizmy
ACSI są tu mapowane bezpośrednio na
protokół warstwy łącza. Uproszczenie
to ma również za zadanie umożliwienie przesyłania danych w czasie rzędu milisekund. Komunikacja w modelu wydawca/subskrybent odbywa się
na zasadzie transmisji rozgłoszeniowej,
gdzie wydawca rozsyła komunikaty do
wszystkich podłączonych do sieci subskrybentów. Urządzenia subskrybujące
w zależności od wartości wybranych
znaczników ramki, mogą te komunikaty
interpretować.
Przy okazji opisu protokołu trzeba też
wspomnieć o określonym w rozdziale 6
[1] normy języku komunikacji podstacji
– SCL (ang. Substation Communication
Language). Jest to język oparty na xml’u.
Założeniem tego języka było stworzenie zunifikowanego sposobu konfiguracji urządzeń IED (ang. Inteligent Electronic Devices, czyli inteligentne urządzenia elektroniczne), do których zalicza się zgodne z IEC 61850 urządzenia
zabezpieczeniowe i sterowniki polowe.
Każde takie urządzenie powinno mieć
możliwość wygenerowania pliku ICD
(ang. IED Capability Description), który zawiera opis zaimplementowanych
w urządzeniu funkcji wraz z ich aktualną konfiguracją. Do pliku ICD dołącza
się plik SSD (ang. System Specification
Description) opisujący schemat stacji
w jakiej dane urządzenie jest zainstalowane. Pliki te są plikami wejściowymi
dla specjalnego oprogramowania do
konfiguracji stacji (np. Visual SCL - [2],),
które na ich podstawie generuje opisujący całą stację plik SCD (ang. Substation
Configuration Description). Następnie
wymagane jest, aby z gotowego pliku
SCD będącego końcowym produktem
konfiguracji stacji można było skonfigurować poszczególne urządzenia automatyki. Standard opisuje tu możliwość
utworzenia plików CID (ang. Configured
IED Description), zawierających okrojony
do funkcjonalności poszczególnych IED
plik SCD. W tym przypadku urządzenie
automatyki powinno mieć możliwość
zaimportowania takiego pliku CID, wraz
ze skonfigurowanymi parametrami.
Schemat procesu konfiguracji stacji wg.
[3] przedstawiono na rys. 2.
Zastosowanie IEC 61850
w sterowniku polowym
megaMUZ-2
W firmie JM-Tronik wykonano pracę nad
dostosowaniem sterownika polowego
megaMUZ-2 do standardu IEC 61850. Interfejsem dla protokołu jest dodatkowa
karta z dostępnym modułem SoC (ang.
System on Chip). Aplikacja zapewniająca funkcjonalność serwera IEC 61850
pracuje pod systemem operacyjnym
GNU/Linux. Jest ona przygotowywana w oparciu o jeden z dostępnych na
rynku stosów IEC 61850, które znacznie
ułatwiają zaimplementowanie funkcjonalności serwera (komunikacja w oparciu o model klient-serwer oparta jest na
8-warstwowym stosie, więc jej implementacja jest bardzo czasochłonna). Komunikację między modułem SoC, a procesorem głównym sterownika polowego megaMUZ-2 oparto o magistralę SPI,
a interfejsem warstwy fizycznej dla IEC
61850 jest 100Base-Tx Ethernet.
Dość skomplikowanym etapem związanym z dostosowaniem urządzenia
do IEC 61850 było określenie modelu
danych, a więc opisanej wcześniej rozbudowanej struktury oraz wykorzystanych abstrakcyjnych usług komunikacyjnych. Tu pojawia się pierwszy kłopot związany z faktem, że każdy producent urządzeń zabezpieczeniowych
i sterowników polowych nieco inaczej
parametryzuje i opisuje wykorzystane
w urządzeniu automatyki oraz funkcje zabezpieczeniowe. Zdefiniowane
w rozdziale 7-4 [1] klasy węzłów logicznych, pomimo że opisano ich ponad 90,
nie oddają wielu spośród funkcji, które
zaimplementowano w megaMUZ’ie-2.
Rys. 2. Schemat procesu konfiguracji stacji IEC 61850 z wykorzystaniem języka
SCL wg [3]
URZĄDZENIA DLA ENERGETYKI 4/2013
3
TECHNOLOGIE, PRODUKTY – INFORMACJE FIRMOWE
Przykładem takich funkcjonalności mogą być chociażby takie automatyki jak
SCO i SZR. Nie oznacza to jednak, że
funkcje te nie mogą być odwzorowane
w IEC 61850. Protokół udostępnia węzły
logiczne ogólnego przeznaczenia takie
jak GGIO odwzorowujący binarne informacje ogólnego przeznaczenia, jak
i GAPC składający się między innymi
z obiektów danych związanych z pobudzeniem i zadziałaniem funkcji zabezpieczeniowych. Za pomocą tych właśnie węzłów logicznych odwzorowano
funkcje zabezpieczeniowe, automatyki
oraz sygnały dwustanowe, dla których
nie wyspecyfikowano w standardzie
dedykowanych węzłów logicznych.
Przy wyborze wykorzystanych w pierwszej implementacji abstrakcyjnych usług
komunikacyjnych zapewniono urządzeniu podstawową funkcjonalność zgodną z protokołem przy jednocześnie
możliwie prostej i czytelnej obsłudze.
Pozostawiono tym samym pewne pole
do rozbudowy funkcjonalności komunikacyjnej w razie potrzeby.
Jako podstawowy mechanizm dla sygnalizacji do systemu nadrzędnego wykorzystano raporty buforowane i niebuforowane. Raporty buforowane różnią się od niebuforowanych zastosowaniem kolejki (FIFO), w której raporty są
przechowywane, a więc w przypadku
kiedy serwer nie może wysłać raportu
do klienta lub w razie wystąpienia błędu transmisji raport nie ginie. W obecnej fazie implementacji przewiduje się
wykorzystanie 2 bloków kontroli raportów buforowanych i 2 bloków kontroli
raportów niebuforowanych. Bloki te są
strukturami za pomocą, których klient
może sterować mechanizmem raportowania. Wykorzystanie bloku przez danego klienta oznacza, że raport związany
z tym blokiem nie może w danej chwili
być używany przez innego klienta. Dane
przesyłane w ramach raportów są grupowane w zestawy (Data Sets). Każdy raport zawiera odniesienie do odpowiedniego zestawu danych. Przewidziano
możliwość dynamicznego definiowania
zestawów danych za pomocą programu klienckiego jak również możliwość
zmiany zestawu danych powiązanego
z konkretnym raportem.
Kolejną zastosowaną w modelu komunikacyjnym usługą jest sterowanie, które umożliwia systemowi nadrzędnemu
kontrolę wszystkich współpracujących
ze sterownikiem megaMUZ-2 łączników.
Spośród 4 modeli sterowania zdefiniowanych w standardzie wybrano 2, których zastosowanie uznano za wystarczające dla założonej funkcjonalności. Modele te to model sterowania bezpośred-
4
Rys. 3. Model danych urządzenia megaMUZ-2 podczas wykonywania usługi Operate
za pomocą aplikacji klienckiej
niego z zabezpieczeniem normalnym
(ang. direct control with normal security)
oraz model sterowania SBO z zabezpieczeniem normalnym (ang. SBO control
with normal security). Pierwszy z modeli umożliwia sterowanie łącznikiem za
pomocą usługi Operate, bez żadnych
dodatkowych ograniczeń. Model drugi,
wykorzystuje tzw. SBO (ang. Select Before Operate), które polega na tym, że
zanim wykonana zostanie usługa Operate, należy wykonać dla danego obiektu sterowania usługę wyboru - Select.
Obiekt sterowania jest wybrany tylko
przez określony (konfigurowalny) czas.
Wybór obiektu sterowania można również anulować przy użyciu usługi Cancel. Implementację przedstawionych tu
usług modelu klient-serwer testowano
przy wykorzystaniu dostępnej na rynku
przeglądarki MMS zorientowanej na prezentację zgodnych z IEC 61850 struktur
o nazwie 61850 Avenue, produkcji firmy
Info Tech [4]. Podobne przeglądarki oferują też między innymi firmy SISCO oraz
Omicron. Ekran przedstawiający model
danych urządzenia megaMUZ-2 podczas
wykonywania za pomocą aplikacji Avenue usługi Operate pokazano na rys. 3.
W ramach implementacji IEC 61850
w megaMUZ’ie-2 zrealizowano komunikację w oparciu o model wydawca/subskrybent przy użyciu mechanizmu GOOSE. W ogólności za pomocą tej usługi
można wysyłać dowolne informacje dostępne w powiązanym z blokiem kontroli GOOSE’ów zestawie danych (Data
Set), a więc informacje dwustanowe,
różnego rodzaju pomiary itd. Jednak
w przypadku zastosowanego w urządzeniu megaMUZ-2 mechanizmu GOOSE zdecydowano, że za jego pomocą,
będzie można wymieniać jedynie dane
dwustanowe. Jest to związane z przewidywanym na ten moment obszarem
zastosowań tej komunikacji. Zakłada
się, że GOOSE’y wykorzystywane będą
w megaMUZ’ie-2 do realizacji automatyk wymagających wymiany sygnałów
binarnych między urządzeniami zabezpieczeniowymi takich jak zabezpieczenie szyn (ZS), lokalna rezerwa wyłącznikowa (LRW), blokady międzypolowe itd.
Realizacja tych automatyk nie wymaga
sygnałów innych niż binarne, stąd decyzja o ich niestosowaniu.
Jako interfejs do wymiany komunikatów GOOSE stworzono w urządzeniu
megaMUZ-2 struktury zwane zdalnymi
wejściami (remote inputs) oraz zdalnymi wyjściami (remote outputs). Zaimplementowano 32 zdalne wejścia oraz 32
zdalne wyjścia. Do obsługi 32 zdalnych
wyjść z poziomu modelu danych stworzono oddzielny węzeł logiczny nazwany roGGIO1, a ponieważ wydawca usługi GOOSE odwołuje się do danych zgrupowanych w ramach zestawu, wszystkie
stany z węzła roGGIO1 pogrupowano
w zestaw danych o nazwie goDataSet.
Jeśli chodzi o subskrybenta usługi GOOSE to należy podkreślić, że sposób jego
realizacji nie jest precyzowany w ramach
standardu IEC 61850. Specyficznym problemem jest przy tej okazji sposób weryfikacji, od którego wydawcy przychodzą
określone komunikaty. Aby rozróżniać
źródło komunikatu GOOSE należy zastosować filtrację, wykorzystując jeden
z dostępnych w ramce identyfikatorów.
W urządzeniu megaMUZ-2 przyjęto, że
posłuży do tego pole identyfikatora aplikacji – AppID (ang. Application ID), będące 16-bitową liczbą. Dla każdego zdalne-
URZĄDZENIA DLA ENERGETYKI 4/2013
TECHNOLOGIE, PRODUKTY – INFORMACJE FIRMOWE
go wejścia będzie można ustawić, dla jakiego AppID powinno się subskrybować
określony sygnał dwustanowy. Dzięki temu, określonym zdalnym wejściom będzie można przyporządkować zdalne
wyjścia konkretnych urządzeń w stacji.
Planowane jest, aby do zdalnych wejść
i wyjść można było przypisywać wybrane sygnały dwustanowe megaMUZ’a-2
korzystając z programowalnej logiki
urządzenia, co pozwoli na realizację wybranych automatyk i blokad.
Wybrane aspekty wynikające
z zastosowania na stacji
protokołu IEC 61850
w kontekście zastąpienia
istniejących rozwiązań
Norma IEC 61850 w istocie niesie ze sobą kilka nowości. Możliwość ściągnięcia przez aplikację kliencką modelu danych i operowania bezpośrednio na nim
umożliwia dość przejrzyste wykorzystywanie usług sterowania i raportowania.
Trzeba przy tym nadmienić, że wymaga
to pewnej znajomości odwzorowania
danego urządzenia do modelu danych
oraz samej semantyki modelu opisanej
w rozdziałach 7-1, 7-3 i 7-4 [1].
Jeśli chodzi o możliwości zastosowania
abstrakcyjnych usług komunikacyjnych
wnoszone przez IEC 61850, takie jak rozbudowane mechanizmy spontanicznego generowania raportów czy zastosowane modele sterowania, to spośród
stosowanych na stacjach protokołów
jedynie DNP 3.0 oferuje porównywalny
zakres możliwości. Trzeba przy tym pamiętać, że DNP 3.0 często używa RS485
w warstwie fizycznej, co stwarza ryzyko kolizji w przypadku spontanicznej
transmisji od wielu urządzeń. Z kolei IEC
61850 od początku był tworzony z myślą o wykorzystaniu Ethernetu, w którym problem ten eliminowany jest chociażby poprzez zastosowanie protokołu
CSMA/CD (ang. Carrier Sense Multiple
Access with Collision Detection) w warstwie łącza danych.
Usługi modelu wydawca/subskrybent
takie jak GOOSE czy SV są swego rodzaju nowością, oferującą wspomniane
wcześniej możliwości realizacji automatyk stacyjnych, blokad międzypolowych
oraz przesyłania spróbkowanych wartości z wykorzystaniem Ethernetu. Należy
jednak pamiętać o tym, że cyfrowa
transmisja tego rodzaju sygnałów
poprzez LAN może być dużo bardziej zawodna niż konwencjonalne
metody. Jest to kwestia bardzo istotna, bo w grę może wchodzić poprawne
funkcjonowanie kosztownych urządzeń
pierwotnych, a także w skrajnych przypadkach ludzkie życie. Trzeba się wobec
tego liczyć z tym, że może upłynąć jeszcze dość duży czas, zanim rozwiązania
te się upowszechnią (jeżeli w ogóle do
tego dojdzie). Inną sprawą jest fakt, że
na średnich napięciach, gdzie odległości między polami są relatywnie małe
w stosunku do wysokich i najwyższych
napięć, oszczędność wynikająca z zastąpienia konwencjonalnego oprzewodowania Ethernetem może być niewielka.
Mogą w ten sposób zostać zaimplementowane automatyki takie jak ZS, LRW,
SCO z SPZ po SCO, ewentualne blokady
międzypolowe, być może też SZR.
Na koniec warto się odnieść do bardzo
istotnej kwestii, a mianowicie zakładanej
i mocno lansowanej przy okazji promocji standardu interoperacyjności. Tu trzeba wziąć pod uwagę, że norma zostawia
mimo wszystko dużą swobodę w doprecyzowywaniu mechanizmów działania niektórych usług abstrakcyjnych.
Dobrym przykładem jest wspomniany
subskrybent GOOSE, którego sposób
działania nie jest praktycznie w normie definiowany. Dodać należy, że wielu z producentów wprowadziło pewne własne modyfikacje do opisanych
w standardzie mechanizmów. Np. firma
GE określiła dodatkowy sposób komunikacji w ramach mechanizmu GOOSE
noszący nawę Fixed GOOSE, wykorzystujący jedynie informacje dwustanowe
określone jako komplementarne pary
bitów. Generalnie zapewnienie interoperacyjności między urządzeniami różnych producentów wymaga ścisłej kooperacji między firmami produkującymi
te urządzenia. W praktyce to najwięksi
producenci dyktują warunki, a mniejsi
muszą się do nich dostosować. Jest to
warunek konieczny, aby ich urządzenia
mogły wymieniać dane w systemie au-
tomatyki podstacji opartym o urządzenia od różnych producentów (np. za pomocą mechanizmu GOOSE). Wiąże się
to z włączeniem do implementacji etapu testów komunikacji z IED konkurencyjnych firm, tak, aby pewna interoperacyjność była możliwa.
Podsumowanie
W celu dokonania podsumowania
przedstawionych w artykule rozważań
wykonano proste zestawienie zawierające subiektywne wady i zalety protokołu IEC 61850 w kontekście zastosowania go, jako alternatywy do wykorzystywanych na stacjach SN rozwiązań. Zestawienie przedstawiono w tabl. 1.
Bez wątpienia IEC 61850 niesie ze sobą
szereg ciekawych rozwiązań, z których
część prawdopodobnie na stałe już zagości w systemach automatyki stacyjnej. Należy jednak być ostrożnym i nie
dać się oszukać marketingowym sztuczkom, a zamiast tego spróbować rzetelnie
ocenić korzyści i słabe punkty związane
z wdrożeniem normy. Czas bez wątpienia
zweryfikuje wiele z wątpliwości.
n
mgr inż. Marcin Krakowski
JM-TRONIK: konstruktor Działu Rozwoju
Literatura:
1. IEC 61850-1: 2003 Communications
networks and systems in substations. Części od 1 do 10
2. http://www.ase-systems.com/iec61850/visual-scl.asp
3. Babś A., Świderski J., Matejek E., Gurzyński J., Tarasiuk M.: Rozbudowa
urządzeń automatyki elektroenergetycznej w celu uzyskania zgodności z normą IEC 61850.
4. http://www.infotech.pl
Tabl. 1. Subiektywne zestawienie wad i zalet protokołu IEC 61850
Wady
Zalety
yy Niedostosowanie zdefiniowanych przez
normę węzłów logicznych do względnie
dużej ilości wykorzystywanych przez urządzenia zabezpieczeniowe funkcji;
yy Złożoność protokołu, przekłada się na
konieczność dużego nakładu pracy w celu implementacji go w urządzeniach. Aby
w pełni wykorzystywać możliwości standardu konieczna jest relatywnie duża moc
obliczeniowa i pamięć systemu mikroprocesorowego urządzenia serwera;
yy Zwłaszcza na średnich napięciach dyskusyjna jest oszczędność na oprzewodowaniu
w wyniku wykonania automatyk stacyjnych
i blokad międzypolowych w formie komunikatów GOOSE. Również niezawodność
tego typu komunikacji nie jest oczywista.
yy Największy spośród wykorzystywanych
w systemach automatyki stacyjnej wybór
usług komunikacyjnych w ramach protokołu;
yy Pełniejsze niż w innych protokołach używanych na stacjach wykorzystanie możliwości
Ethernetu;
yy Możliwość komunikacji pomiędzy urządzeniami poziomu pola (sterownikami polowymi i urządzeniami zabezpieczeniowymi,
a nie tylko między urządzeniem poziomu
pola, a systemem nadrzędnym;
yy Zastosowanie języka SCL zwiększającego
możliwości konfiguracji stacji;
yy Wykorzystanie obiektowego modelu danych – zwiększenie przejrzystości usług
komunikacyjnych;
yy Potencjalne umożliwienie komunikacji
z urządzeniami pierwotnymi za pomocą
Ethernetu przy wykorzystaniu magistrali
procesowej i usługi SV (Sampled Values) –
ewentualne perspektywy na przyszłość.
URZĄDZENIA DLA ENERGETYKI 4/2013
5