Ovládání komunikace dle IEC 870-5-101 - UTEE

2007/47– 22.11.2007
Ovládání komunikace dle IEC 870-5-101
Ing. Jan Mikulka
Vysoké učení technické v Brně, Fakulta elektrotechniky a komunikačních technologií,
Ústav teoretické a experimentální elektrotechniky,
Kolejní 2906/4, 612 00 Brno, Česká republika.
Email: [email protected]
Článek demonstruje postup při vytváření knihovny funkcí pro komunikaci
s průmyslovými zařízeními. Konkrétně se jedná o komunikační standard IEC 870-5-101, který
je určen ke vzdálenému řízení a sběru telemetrických dat v energetice. Je tedy často využíván
v oblasti SCADA systémů ve spojení s komplexem distribuovaných zařízení. Při tvorbě
knihovny byl na tyto skutečnosti brán zřetel a byla navržena tak, aby byla použitelná ve
standardech řídicí a měřicí techniky jako jsou systémy LabVIEW, či CVI. Na těchto systémech
je potom možné velmi jednoduše vytvořit testovací aplikace a za použití profesionálního
testovacího software, např. firmy Triangle MicroWorks funkce knihovny prověřit.
1. Úvod
Téměř žádný automatizovaný proces se dnes neobejde bez vizualizace a možnosti
vzdáleného řízení. Tuto oblast nejvíce reprezentují známé SCADA (Supervisory Control And
Data Acquistion) systémy, známé jako univerzální nástroje pro tyto účely. Ke komunikaci se
vzdáleným zařízením neodmyslitelně patří komunikační protokoly, které definují datové typy
hodnot přenášených veličin, resp. procesních příkazů, přenosové rychlosti, zabezpečení a
způsob komunikace vůbec.
Standard IEC 870-5-101 je určen ke komunikaci v průmyslu, zvláště v energetických
soustavách. Jeho norma je dostupná na Internetu [1], jde o otevřený systém a výrobci ho
mohou bez problémů implementovat do svých průmyslových zařízení. Za zmínku stojí např.
SCADA systém firmy ABB – S.P.I.D.E.R. MicroScada. Mezi základní funkce tohoto systému
patří snímání dat z procesu, ovládání, zobrazení dat, zpracování událostí a alarmů,
automatické řídicí funkce, ukládání a zobrazení průběhu analogových a binárních vstupů,
zpracování výkazů el. energií (proudů a výkonů), komunikace s ochranami ABB, komunikace
s jinými systémy (pomocí IEC 870-5-101), dohled na systém, tiskové výstupy apod. Ke
snímání dat slouží převážně řídicí a ochranné terminály z produkce ABB (RTU 2xx, 5xx,
apod.). Tyto terminály zajistí snímání změn vstupů a jejich vyslání do MicroScady s přesností
na 1 ms. Jedná se o vstupy typu jednobitových, dvoubitových, analogových a pulzních
hodnot. Ovládání může být provedeno v jednom kroku (okamžitě po vyslání příkazu) nebo ve
dvou krocích (s možností zrušení povelu). Pojmem automatizační řídicí funkce znamená
zadávání sekvenčních povelů, časové řízení (jednorázově/cyklicky), řízení výkonovými
špičkami apod. Systém je tvořen třemi částmi – základní jednotka, komunikační systém a
rozhraní pro komunikaci s obsluhou. Co se týče sériového rozhraní počítače COM, musí být
nainstalována součást zvaná PC-NET. Tento ovladač umí obsloužit max. 4 sériové porty,
s přídavnou kartou RocketPort až 8 portů. PC-NET překládá telegramy z procesních jednotek
na telegramy ACP (protokol používaný mezi uzly MicroScada). Má implementovány tyto
protokoly podporující komunikaci s procesními jednotkami i s některými nadřazenými
47-1
2007/47– 22.11.2007
systémy: LON Talk, RP570/571 master, RP570 slave, SPA bus master, IEC 870-5-101 master
i slave, IEC 870-5-103 slave, ACP, IEC 1107, LCU500 master, Alpha meter protocol.
Protokol je definován třemi vrstvami ISO/OSI modelu (fyzická, linková a aplikační).
Norma exaktně určuje funkční význam každé z těchto vrstev.
Obr. 1 Možné topologie sítě: a) přímé spojení dvou stanic, b) přímé spojení více linkami, c)
přímé spojení více stanic jednou linkou, d) redundantní spojení
Nejnižší vrstva – fyzická, určuje typ média. Je stanovena ITU-T doporučením, které
definuje rozhraní mezi DCE a DTE řídicí a řízené stanice. Standardním rozhraním mezi DCE
a DTE je asynchronní V.24/V.28 rozhraní. Spojení mezi DCE zařízeními potom může být
libovolné – kabelem, bezdrátově, opticky apod. V nejjednodušším případě, pokud
propojujeme dva počítače přes rozhraní RS-232, použijeme křížený kabel (nulový modem).
Tento kabel potom realizuje vlastní DCE obvod (modem). Dále tato vrstva definuje topologie
sítí, ty jsou ukázány na Obr. 1. Rychlosti přenosu se u V.24/V.28 spojení podle normy
pohybují v rozsahu 100 – 9600 bit / s.
Nad fyzickou vrstvou se nachází linková vrstva. Funkce této vrstvy se v principu liší
podle typu komunikace. Nabízí se dvě možnosti. Vyvážený režim, kdy jsou si všechny stanice
rovny a každá z těchto stanic může kdykoliv začít s přenosem dat, aniž by k tomu byla
předem vyzvána nadřízenou stanicí. Tento způsob komunikace vyžaduje plný duplex. Druhou
možností je nevyvážený režim. Zde jsou stanice rozděleny na primární (master) a sekundární
(slave), přičemž sekundární stanice posílá data pouze, pokud je k tomu vyzvána stanicí
47-2
2007/47– 22.11.2007
primární. Způsob, jakým jednotlivé stanice přistupují k médiu a předávají si informace, je dán
komunikačními procedurami, které jsou ve standardu znázorněny formou časových diagramů
přenosu jednotlivých rámců.
Nejvyšší vrstvou, která je nejblíže procesu, resp. aplikaci, je aplikační vrstva. Ta definuje
standardní typy dat a jejich kódování. Do rámců linkové vrstvy. Protokol umožňuje přenášet
následující typy dat.
•
Single-point: tento typ můžeme použít pro sledování dvoustavové veličiny. Např.
zapnuto/vypnuto. Je kódován jedním bitem.
•
Double-point: vzhledem k přenosu dvou bitů (4 stavy), můžeme zachytit oproti
single-point typu i přechodný (neurčitý) stav.
•
Step position information: slouží k přenosu hodnoty vícestavové veličiny. Stavy
jsou zde číslovány v intervalu -64 až +63, čili celkem 128 stavů.
•
Bitstring of 32 bit: datový typ k přenosu 32 nezávislých bitů. Je však samozřejmě
možné tento typ použít i k přenosu 4 – bytového čísla, záleží pouze na interpretaci
výsledných dat.
•
Measured value, normalised value: 2 – bytový celočíselný typ.
•
Measured value, short floating point numer: číslo s pohyblivou řádovou čárkou,
kódované čtyřmi byty.
•
Integrated totals: 4 bytový celočíselný typ, který slouží k přenosu stavu čítačů.
Všechny tyto typy je možné používat v monitorovacím směru, tedy např. ze vzdáleného
měřicího systému nebo ochrany směrem k řídicí stanici (SCADA systém). S vlastní hodnotou
je vždy přenášena také skupina atributů, kterými můžeme označit vlastnosti jako překročení
rozsahu (např. při analogovém měření), blokování přenosu (tuto hodnotu nelze přenášet buď
kvůli vzdálenému nebo lokálnímu zablokování), aktuální hodnota (značí, že měření proběhlo
v nastaveném časovém okamžiku a hodnota tudíž není neaktuální), platná hodnota (značí, že
hodnota byla získána korektním měřením). Dále je možné s každou hodnotou přenášet
časovou značku, a to buď ve zkrácené podobě (relativní čas) nebo plné (absolutní čas).
K řízení vzdálené stanice potom slouží procesní příkazy. Těmi lze přenášet podobně jako
v monitorovacím směru také pouze některé datové typy.
•
Single command: nastavení dvoustavové veličiny.
•
Double command: nastavení třístavové veličiny.
•
Regulating step command: inkrementace nebo dekrementace hodnoty typu step
position information.
•
Set-point command, normalised value: nastavení hodnoty celočíselného 2
bytového typu.
Bitsring of 32 bit: hromadné nastavení 32 nezávislých dvoustavových hodnot.
•
47-3
2007/47– 22.11.2007
V řídicím směru jsou dále definovány příkazy pro časovou synchronizaci stanic,
všeobecnou obnovu dat (při inicializaci komunikace tento příkaz zavolá primární stanice pro
okamžité získání aktuálních hodnot všech veličin), vzdálený restart (má dva významy – restart
stanice a uvedení procesu do určitého, např. počátečního nebo bezpečného stavu). Dále je
možné vzdálenou stanici tzv. parametrizovat, což obnáší přenos parametrů, které slouží např.
k nastavení pásma citlivosti (hystereze bránící vyvolání události při velmi malých změnách
měřené hodnoty), parametry filtrování měřených hodnot apod.
Před návrhem knihovny tedy musíme zvolit způsob komunikace, zda-li se jedná o
vyvážený nebo nevyvážený režim, popř. jestli má knihovna poskytovat obojí možnost. Dále
při implementaci komunikačních procedur řešíme buď pouze standardní procedury nebo
procedury pro redundantní spoje, kdy linková vrstva kromě hlídání výpadku komunikace
udržuje spojení také na druhé záložní lince a v případě výpadku jedné linky pokračuje
v komunikaci na lince záložní. Tím se návrh samozřejmě o něco více komplikuje.
Norma [1] definuje také funkce jednotlivých stanic. Jedná se hlavně o funkce řízené
stanice. Předávání dat je založeno na tom principu, že řízená stanice získává z procesu měřené
hodnoty a pokud zjistí, že změna některé z nich překročila určitou úroveň, dojde k tzv.
události. Řídicí stanice potom voláním řízených stanic tyto událostí sbírá a z nich
vyhodnocuje jednotlivé změny, čili sbírá aktuální hodnoty. Z toho plyne první požadavek na
řízenou stanici – musí mít zásobník událostí, jelikož přenosová rychlost, resp. frekvence
přenosu událostí může být při častějších změnách měřené veličiny daleko menší než
frekvence vzniku těchto událostí. Dále je asi ve všech případech nutné nastavovat parametry
řízené stanice, které však nijak nesouvisí s řízeným procesem. I k tomu můžeme podle normy
používat procesní příkazy. Např. pro ovládání LED signalizace použijeme single command
apod. Dále norma definuje, se kterými hodnotami se mohou posílat časové značky a se
kterými ne, definuje priority dat apod.
Důležité je také zmínit se o adresování jednotlivých stanic, resp. procesních veličin.
Každá veličina má svou absolutní adresu, která je dána dvojící adresy informačního elementu
(veličina) a adresou sektoru (zařízení, část zařízení). Jednotlivé adresy mohou být kódovány
jedním nebo několika byty (velikost adresového prostoru je částečně volitelný). Dále se
v normě vyskytuje tzv. adresa linky. Ta jednoznačně identifikuje kanál mezi řídicí a řízenou
stanicí. Na Obr. 2 je zachycen příklad zařízení se dvěma sektory. V každém sektoru jsou
adresovatelné 4 procesní veličiny. Adresy těchto veličin v jednom sektoru mohou být
identické s adresami druhého sektoru, jelikož skutečnou – absolutní adresu – určuje právě
dvojice adresa sektoru + adresa veličiny.
47-4
2007/47– 22.11.2007
Obr. 2 Princip adresování
2. Tvorba knihovny pro ovládání komunikace
Požadavky na knihovnu
Návrh knihovny musí být v první řadě koncipovaný tak, aby knihovna nabízela pouze
funkce aplikační vrstvy a nedovolila aplikaci využívat funkcí nižších vrstev. To by
odporovalo obecnému pojetí OSI modelu. Dále je nutné mít na paměti, že linková i aplikační
vrstva je naprosto odlišná u primárních a sekundárních stanic, čili je vhodné tyto dva celky
oddělit do dvou knihoven. Je také zřejmé, že pokud budeme navrhovat knihovnu např. pro
SCADA systém pro PC, tak bude mít jistě naprosto jinou stavbu než knihovna pro
mikroprocesor řízené stanice. Tento článek je zaměřen výhradně na vývoj DLL knihovny pro
implementaci do aplikací podobných SCADA systémům nebo softwaru typu LabVIEW, CVI
apod. Není možné zde popsat algoritmus všech funkcí nebo dokonce uvádět části zdrojových
kódů. Článek by měl sloužit spíše jako návod k tvorbě knihovny pro komunikaci ať už pro
tento, tak i pro podobné komunikační protokoly.
Realizované řešení
Vývoj knihovny je rozdělen do třech částí podle vrstev.
1. Nejnižší vrstva obsluhuje pouze vysílání a příjem dat mezi portem a zásobníky.
47-5
2007/47– 22.11.2007
2. Druhá vrstva – linková – řešená formou stavového automatu v samostatném vlákně.
Linková vrstva primární stanice má totiž za úkol neustále udržovat spojení se
sekundárními stanicemi. Pokud by tedy neustále automat volal funkce pro I/O operace
na portu ve vlákně samotné aplikace, byl by tímto proces tak vytížen, že by nezbylo
prostředků pro ovládání okna, ovládacích prvků apod. Čili docházelo by k
„zatuhávání“ aplikace. Z tohoto faktu vyplývá nutnost zkušeností s vývojem
vícevláknových aplikací, synchronizace vláken (mutexy, semafory) apod. Tvorba
linkové vrstvy je tedy asi nejnáročnější.
3. Aplikační vrstva je potom tvořena pouze funkcemi, které kódují příkazy do rámců pro
linkovou vrstvu nebo naopak dekódují rámce získané linkovou vrstvou a poskytují je
uživatelské aplikaci. Je tedy tvořena funkcemi pro posílání příkazů a pro získávání
aktuálních hodnot z procesu. Veškeré tyto operace provádí pouze na zásobníku mezi
aplikační a linkovou vrstvou.
Obr. 3 Komunikace mezi jednotlivými vrstvami
47-6
2007/47– 22.11.2007
Při psaní knihovny označíme klíčovým slovem export funkce, které budou později
viditelné naší aplikaci. Je tedy zřejmé, že tímto klíčovým slovem označíme pouze funkce
aplikační vrstvy. Dále bychom se měli dodržovat, aby přístup k proměnným byl uskutečňován
zásadně pomocí funkcí (pro změnu, resp. čtení hodnoty). Funkce totiž můžeme opatřit
mechanismem synchronizace pro zamezení předávání nekompletních dat.
Obr. 3 ukazuje tato pravidla popsané synchronizované komunikace. Červený blok
(linková vrstva) běží v paralelním vlákně s vláknem ostatních vrstev a červené šipky značí
synchronizovanou komunikaci s nadřazenou aplikační vrstvou, která je realizována přes dva
zásobníky – pro události a pro příkazy.
Důvod proč musíme synchronizovat pouze komunikaci mezi linkovou a aplikační vrstvou
je ten, že data ze zásobníku mezi těmito vrstvami používají obě vrstvy zároveň. Linková
vrstva může přímo zapisovat do zásobníku data z přijaté události a zároveň se může
uživatelská aplikace ptát na aktuální hodnotu dané veličiny. Došlo by tedy ke konfliktu.
Jednodušší je to právě u zásobníku mezi fyzickou a linkovou vrstvou, kde funkce pro čtení a
zápis dat fyzické vrstvy (z/na port) volá přímo vlákno linkové vrstvy a nikdo jiný. Nemůže
tedy k žádnému konfliktu dojít.
3. Principy implementace v prostředích National Instruments
V prvé řadě je nutné poznamenat, že oba systémy (LabVIEW, CVI) jsou kompatibilní
s jazykem C. Musíme tedy dbát na to, abychom se při volbě typů návratových hodnot a
parametrů funkcí drželi pouze datových typů jazyka C a nepoužívali objektově orientovaných
prvků. Byly vytvořeny demonstrační aplikace v CVI i LabVIEW, ve kterých jsou volány fce
knihovny pro komunikaci se vzdálených zařízením (testerem).
LabWINDOWS / CVI
V projektech CVI použijeme funkce knihovny velmi jednoduše. Nejprve je
nutné zahrnout do projektu knihovnu importů (lib) a následně hlavičkový soubor
s exportovanými funkcemi. Využijeme zde tzv. callback funkcí, čili funkcí, které se
volají při aktivaci některého z ovládacích prvků. Pokud např. umístíme na okno
aplikace tlačítko, kterým budeme ovládat vzdálené zařízení, prostředí CVI nám samo
vygeneruje tuto funkci, kterou dále můžeme editovat. Následuje příklad s využitím již
hotové knihovní funkce SetSinglePoint, která pošle příkaz vzdálené stanici pro daný
typ.
int CVICALLBACK Switch (int panel, int control, int event,
void *callbackData, int eventData1, int eventData2)
{
BOOL value;
switch (event)
{
case EVENT_COMMIT:
GetCtrlVal(master_handle, control, &value);
SetSinglePoint(1, 2100, value);
}
47-7
2007/47– 22.11.2007
return 0;
}
Funkce je potom volána např. po stisku tlačítka na okně aplikace uživatelem. Funkcí
GetCtrlVal nejdříve zjistíme aktuální stav tlačítka (vypnuto/zapnuto) a tuto hodnotu
potom pošleme funkcí SetSinglePoint na vzdálenou stanici. V tomto konkrétním
případě na adresu 2100 do sektoru 1.
Podobně bychom postupovali při vizualizaci procesních dat, které měříme. Můžeme
buď použít komponentu časovače a v pravidelných intervalech vzorkovat procesní
hodnoty pomocí funkcí aplikační vrstvy nebo vše provádět v samostatném vlákně
aplikace. Následuje příklad pro callback funkci časovače, která obnovuje zobrazení
měřené hodnoty ze vzdálené stanice.
int CVICALLBACK UpDate (int panel, int control, int event,
void *callbackData, int eventData1, int eventData2)
{
PFLOATVALUE pFV;
switch (event)
{
case EVENT_TIMER_TICK:
if ((pFV = GetFloatValueEx(1, 700)) != NULL)
SetCtrlVal(panel, MASTER_FV2, pFV->FPN);
break;
}
return 0;
}
Zde nejprve zjistíme aktuální hodnotu z procesu funkcí GetFloatValue, opět
pomocí dvojice adres. Následuje zobrazení aktuální hodnoty v okně aplikace. Podobně
jako v předchozím příkladě, ale tentokrát pomocí funkce SetCtrlVal. Obr. 4
demonstruje okno aplikace s použitými ovládacími prvky. Dvoupolohový přepínač
(singlepoint) a měřicí přístroj ukazující číslo v pohyblivé řádové čárce.
Obr. 4 Příklad jednoduché aplikace v CVI
47-8
2007/47– 22.11.2007
LabVIEW
Tvorba programu v LabVIEW je oproti CVI naprosto odlišná. Zdrojový kód zde
nahrazují bloková schémata a funkční bloky, které v grafickém prostředí logicky
spojujeme, abychom dosáhli požadované funkce. Funkce pro komunikaci z DLL
potom do programu zakomponujeme podobně jako např. funkci pro ovládání prvku na
okně aplikace. K vyvolání funkce z DLL slouží Call Library Function blok, který
najdeme ve standardní paletě.
Na rozdíl od aplikace v CVI nemáme možnost vložit do projektu knihovnu
importů a z toho vyplývá nutnost nové deklarace funkce, kterou chceme volat.
Obr. 5 Blokové schéma zapojení knihovní funkce pro příkaz singlepoint
Obr. 6 Nastavení Call Library Function node
47-9
2007/47– 22.11.2007
Na Obr. 5 je vidět zapojení Call Library Function bloku po nastavení podle Obr.
6. Do bloku vstupují dvě adresy, jakožto konstantní hodnoty 2100 (adresa
informačního elementu) a 1 (adresa sektoru) a logická hodnota aktuálního stavu
přepínače. Počet vstupů bloku a jejich datové typy se určí nastavením vlastností bloku
tak, jak ukazuje právě Obr. 6. Zadáme cestu k DLL knihovně, dále z roletky vybereme
název funkce a postupně nadefinujeme vstupní parametry a návratový typ funkce. Vše
musí souhlasit se skutečností, jinak dojde při volání funkce k chybě. Potvrzením
nastavení (tlačítko OK) se v bloku objeví patřičný počet vstupů, popř. výstup, které
můžeme zapojit do našeho blokového schématu.
4. Ověření správnosti implementace
K ověření své knihovny jsem použil profesionální testovací software firmy Triangle
MicroWorks – Protocol Test Harness. V plné verzi umožňuje software testovat komunikaci
protokoly DNP3 (velmi podobná americká verze protokolu podle IEC), Modbus a IEC 870-5101 (102, 103, 104). Firma na svých webových stránkách nabízí také DLL knihovnu
s komunikačním rozhraním.
Při testování komunikace máme možnost zvolit, jestli tester bude v roli primární nebo
sekundární stanice. Můžeme tedy testovat jak řídicí, tak řízenou stanici. Pokud potřebujeme
testovat komunikační kanál, je zde i možnost simulovat obě stanice. Můžeme volit režim
komunikace (vyvážený/nevyvážený), velikost adresového prostoru (počet bytů pro kódování
adresy), apod.
Okno testeru zachycuje a převádí do čitelné formy komunikaci na všech vrstvách
protokolu, což je velmi výhodné při ladění. Zobrazování komunikace na různých úrovních
můžeme povolit nebo zakázat. V dalším okně najdeme seznam proměnných, které simulují
procesní hodnoty. Můžeme je ovládat příkazy z naší aplikace, resp. manuálně měnit a tím
simulovat změnu procesní veličiny.
5. Závěr
Komunikační protokol IEC 870-5-101 je určen ke vzdáleném řízení a sběru
telemetrických dat v energetických soustavách. Článek měl za úkol seznámit čtenáře se
základními charakteristikami tohoto protokolu, jako jsou topologie sítě, funkce jednotlivých
vrstev OSI, typy přenášených dat a příkazů, způsob adresování stanic a funkce stanic. Dále je
zde popsán stručně návod, jak postupovat při vývoji dané knihovny pro komunikaci, tzn.
výběr exportovaných funkcí a princip tvorby vícevláknového procesu pro zajištění plynulého
chodu aplikace. Uvedený postup může být samozřejmě použit i pro tvorbu komunikační
knihovny pro jiný podobný protokol.
Byla vytvořena knihovna pro ovládání komunikace v systémech LabVIEW a
LabWINDOWS / CVI. Dále byl demonstrován postup při implementaci knihovny do těchto
systémů. Ačkoliv jsou tyto systémy ve způsobu tvorby programů naprosto odlišné, je možné
vytvořit funkce takovým způsobem, aby byly vzhledem k těmto dvěma systémům naprosto
univerzální.
Knihovna byla testována testovacím programem pro tento a jemu podobné komunikační
protokoly. Software se dá s výhodou použít pro ladění během vývoje knihovny nebo následně
47-10
2007/47– 22.11.2007
pro ladění aplikace využívající tuto knihovnu. Jde o software Protocol Test Harness firmy
Triangle MicroWorks, na jejíchž webových můžeme stáhnout třicetidenní funkční verzi.
Funkční verze DLL je součástí diplomové práce a to včetně demonstračních programů a
zdrojových kódů.
6. Použité zdroje
[1]
[2]
Norwegian IEC 870-5-101 User Conventions [on-line]. c2000, revision 2.0
[cit. 2007-9-21]. Dostupné na World Wide Web:
<http://www.statnett.no/Files/Open/IEC-R20_1.pdf>
MIKULKA, Jan. Ovládání komunikace dle IEC 870-5-101. Brno, 2007. 72 s. , 10.
VUT v Brně. Diplomová práce.
47-11