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:
MIKULKA, Jan. Ovládání komunikace dle IEC 870-5-101. Brno, 2007. 72 s. , 10. VUT v Brně. Diplomová práce.
47-11
