| |
ICS 33.200; 35.240.50 Červen 2008
|
Rozhraní aplikačního programu pro systémy řízení |
ČSN 33 4910 |
idt IEC 61970- 405:2007
Energy management system application program interface (EMS-API) -
Part 405: Generic Eventing and Subscription (GES)
Interface de programmation d’application pour système de gestion d’énergie (EMS-API) -
Partie 405: Evénements génériques et souscriptions (GES)
Schnittstelle für Anwendungsprogramme für Energiemanagementsysteme (EMS-API) -
Teil 405: Übermitteln von Ereignismeldungen (GES)
Tato norma je českou verzí evropské normy EN 61970- 405:2007. Překlad byl zajištěn Českým normalizačním institutem. Má stejný status jako oficiální verze.
This standard is the Czech version of the European Standard EN 61970- 405:2007. It was translated by Czech Standards Institute. It has the same status as the official version.
 | © Český normalizační institut, 2008 Podle zákona č. 22/1997 Sb. smějí být české technické normy rozmnožovány a rozšiřovány jen se souhlasem Českého normalizačního institutu. | 81164 |
Národní předmluva
Informace o citovaných normativních dokumentech
IEC 61970-1:2005 zavedena v ČSN EN 61970-1:2006 (33 4910) Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 1: Směrnice a obecné požadavky (idt EN 61970-1:2006, idt IEC 61970-1:2005)
IEC/TS 61970-2 nezavedena
IEC 61970-301:2003 zavedena v ČSN EN 61970-301:2006 (33 4910) Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 301: Základ obecného informačního modelu (CIM) (idt EN 61970-301:2004, idt IEC 61970-301:2003)
IEC/TS 61970-401 nezavedena
IEC 61970-402 dosud nezavedena
OMG DAIS A&E:2005 nezavedeno
OMG DAF:2005 nezavedeno
OPC A&E:2002 nezavedeno
Obdobné mezinárodní normy
IEC 61970-405:2007 Energy management system application program interface (EMS-API) - Part 405: Generic Eventing and Subscription
(Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 405: Generické zpracování událostí a vyžádání)
Porovnání s mezinárodní normou
Obsah normy je identický s IEC 61970-405:2007 a navíc obsahuje normativní přílohu ZA, kterou doplnil CENELEC.
Informativní údaje z IEC 61970- 405:2007
Mezinárodní norma IEC 61970- 405 byla připravena technickou komisí IEC TC 57: Řízení elektrizační soustavy a příslušná výměna informací.
Text této normy vychází z těchto dokumentů:
|
FDIS |
Zpráva o hlasování |
|
57/888/FDIS |
57/907/RVD |
Úplné informace o hlasování při schvalování této normy je možné nalézt ve zprávě o hlasování uvedené v tabulce.
Seznam všech Částí souboru IEC 61970 lze nalézt na internetové adrese IEC pod společným názvem Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API).
Komise rozhodla, že obsah této publikace se nebude měnit až do konečného data vyznačeného na internetové adrese IEC „http://webstore.iec.ch“ v termínu příslušejícímu dané publikaci. Po tomto termínu bude publikace
· znovu potvrzena;
· zrušena;
· nahrazena revidovaným vydáním, nebo
· změněna.
Dvoujazyčná verze této publikace může být vydána později.
Vypracování normy
Zpracovatel: ÚJV Řež a.s., divize Energoprojekt Praha, IČ 46356088, Ing. Jaroslav Mezera
Technická normalizační komise: TNK 97 Elektroenergetika
Pracovník Českého normalizačního institutu: Ing. Jiří Holub
|
EVROPSKÁ NORMA
EN 61970- 405 |
ICS 33.200
|
Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Energy management system application program interface (EMS-API) - |
|
|
Interface de programmation d’application |
Schnittstelle für Anwendungsprogramme |
Tato evropská norma byla schválena CENELEC 2007-09-01. Členové CENELEC jsou povinni splnit Vnitřní předpisy CEN/CENELEC, v nichž jsou stanoveny podmínky, za kterých se musí této evropské normě bez jakýchkoliv modifikací dát status národní normy.
Aktualizované seznamy a bibliografické citace týkající se těchto národních norem lze obdržet na vyžádání v Ústředním sekretariátu nebo u kteréhokoliv člena CENELEC.
Tato evropská norma existuje ve třech oficiálních verzích (anglické, francouzské, německé). Verze v každém jiném jazyce přeložená členem CENELEC do jeho vlastního jazyka, za kterou zodpovídá a kterou notifikuje Ústřednímu sekretariátu, má stejný status jako oficiální verze.
Členy CENELEC jsou národní elektrotechnické komitéty Belgie, Bulharska, České republiky, Dánska, Estonska, Finska, Francie, Irska, Islandu, Itálie, Kypru, Litvy, Lotyšska, Lucemburska, Maďarska, Malty, Německa, Nizozemska, Norska, Polska, Portugalska, Rakouska, Rumunska, Řecka, Slovenska, Slovinska, Spojeného království, Španělska, Švédska a Švýcarska.
|
CENELEC Evropský výbor pro normalizaci v elektrotechnice European Committee for Electrotechnical Standardization Comité Européen de Normalisation Electrotechnique Europäisches Komitee für Elektrotechnische Normung Ústřední sekretariát: rue de Stassart 35, B-1050 Brusel © 2007 CENELEC Veškerá
práva pro využití v jakékoli formě a jakýmikoli prostředky |
Předmluva
Text dokumentu 57/888/FDIS, budoucího 1. vydání IEC 61970-405, vypracovaný v technické komisi IEC TC 57, Řízení elektrizační soustavy a příslušná výměna informací, byl předložen k paralelnímu hlasování IEC-CENELEC a byl schválen CENELEC jako EN 61970-405 dne 2007-09-01.
Byla stanovena tato data:
|
– nejzazší datum zavedení EN na národní úrovni |
(dop) |
2008-06-01 |
|
– nejzazší datum zrušení národních norem, |
(dow) |
2010-09-01 |
Přílohu ZA doplnil CENELEC.
Oznámení o schválení
Text mezinárodní normy IEC 61970- 404:2007 byl schválen CENELEC jako evropská norma bez jakýchkoliv modifikací.
Obsah
Strana
Úvod................................................................................................................................................................................................... 6
1 Rozsah platnosti................................................................................................................................................................. 6
2 Citované normativní dokumenty....................................................................................................................................... 7
3 Termíny a definice............................................................................................................................................................... 7
4 Generické zpracování událostí a vyžádání (normativní)............................................................................................... 8
4.1 Přehled.................................................................................................................................................................................. 8
4.1.1 Všeobecně........................................................................................................................................................................... 8
4.1.2 Vhodnost GES pro integraci různorodých kategorií aplikací....................................................................................... 8
4.1.3 Vhodnost GES pro integraci mimo řídicí centrum........................................................................................................ 8
4.1.4 Vhodnost GES pro integraci úzce provázaných a volně provázaných aplikací (informativní)................................ 9
4.2 Použití GES A&E jednoduchého zpracování událostí pro generické zpracování zpráv........................................ 10
4.2.1 Všeobecně.......................................................................................................................................................................... 10
4.2.2 GES zprávy.......................................................................................................................................................................... 11
4.2.3 Stromové struktury pro problematiku zpracování událostí a vyžádání (informativní)............................................ 11
4.2.4 Filtrování vyžádání.............................................................................................................................................................. 11
4.2.5 GES pseudoštítky Předání/Vyžádání.............................................................................................................................. 11
4.2.6 Prohledávání IECTC57 rozsahů názvů v GES.............................................................................................................. 12
5 Generické Výstrahy a Události při Vyžádání Událostí................................................................................................. 13
5.1 Podmínky vzniku (informativní)........................................................................................................................................ 13
5.2 Možnost použití SCADA (informativní)............................................................................................................................ 14
5.3 Datový model (normativní)............................................................................................................................................... 15
5.4 Zprávy (normativní)............................................................................................................................................................ 16
5.5 Rozhraní (normativní)....................................................................................................................................................... 18
5.5.1 Objekty a rozhraní.............................................................................................................................................................. 18
5.5.2 Rozhraní Serveru a Relace.............................................................................................................................................. 20
5.5.3 Prohledávací rozhraní....................................................................................................................................................... 20
5.5.4 Rozhraní klienta................................................................................................................................................................. 21
5.5.5 Mapování DAIS A&E na soubor IEC 61970-3XX......................................................................................................... 21
Příloha A (informativní) Proxy sekvence Vyžádání Událostí.................................................................................................. 22
Bibliografie...................................................................................................................................................................................... 25
Příloha ZA (normativní) Normativní odkazy na mezinárodní publikace a na jim příslušející evropské publikace..... 26
Obrázek 1 - Vyžádání dat................................................................................................................................................................ 8
Obrázek 2 - Architektura složek..................................................................................................................................................... 9
Obrázek 3 - Rozvedený příklad rozsahu názvů pro IECTC57FyzickýModel (informativní)................................................. 12
Obrázek 4 - Obvyklé toky DAIS výstrah a událostí u SCADA................................................................................................... 14
Obrázek 5 - GES A&E datový model........................................................................................................................................... 15
Obrázek 6 - Zprávy s událostmi................................................................................................................................................... 17
Obrázek 7 - GES A&E objekty a rozhraní................................................................................................................................... 18
Obrázek 8 - Typická interakce mezi DAIS A&E objekty........................................................................................................... 19
Obrázek A.1 - Proxy sekvence vyžádání a zpětného dotazu s více servery.......................................................................... 22
Obrázek A.2 - Proxy sekvence vyžádání s více klienty.............................................................................................................. 23
Obrázek A.3 - Proxy sekvence zpětného dotazu s více servery.............................................................................................. 23
Obrázek A.4 - Proxy sekvence zpětného dotazu s více klienty................................................................................................ 24
Úvod
Tato Část IEC 61970 je součástí souboru IEC 61970, který definuje rozhraní aplikačního programu (API - Application Program Interface) pro systém řízení elektrické energie (EMS - Energy Management System). Dokumenty souboru IEC 61970-4XX a IEC 61970-5XX obsahují specifikace rozhraní složek (CIS - Component Interface Specification). CIS v souboru IEC 61970-4XX jsou určeny jako modely nezávislé na platformě (PIM - Platform Independent Model) což znamená, že jsou nezávislé na vlastní technologii použité k jejich realizaci. Specifikace PIM se rovněž označují jako specifikace Úrovně 1. Oproti tomu jsou CIS v souboru IEC 61970-5XX určeny jako modely specifické pro platformu (PSM - Platform Specific Model). Specifikace PSM se rovněž označují jako specifikace Úrovně 2.
CIS v IEC 61970-4XX stanovují funkční požadavky na rozhraní, která mají realizovat určitou složku (nebo aplikaci) pro výměnu informací s ostatními složkami (nebo aplikacemi) a/nebo pro přístup k veřejně dostupným datům standardním způsobem. Rozhraní složek popisují konkrétní typy událostí a obsahy zpráv, které mohou aplikace k tomuto účelu použít.
IEC 61970-405 definuje rozhraní pro efektivní přenos zpráv s událostmi a zpráv s potvrzeními výstrah v rozloženém prostředí. Malé počty zpráv jsou přenášeny s krátkým zpožděním, přičemž i velké objemy dat jsou přeneseny v krátkém čase, i když s poněkud větším zpožděním. Toto je běžný požadavek u SCADA systému, který pracuje jako poskytovatel dat v reálném čase pro ostatní dílčí systémy. Tyto charakteristiky rozhraní generického zpracování událostí a vyžádání (GES - Generic Eventing and Subscription) mohou být užitečné i pro jiné systémy než je SCADA. GES je velmi vhodný, požadují-li se krátké časy zpoždění a rovněž hromadný přenos dat.
Tyto specifikace rozhraní složek se odvolávají na objekty entit pro oblast elektrizační soustavy definované v souboru IEC 61970-3XX, včetně IEC 61970-301.
1 Rozsah platnosti
Specifikace generického zpracování událostí a vyžádání (GES) v IEC 61970-405 definuje univerzální rozhraní pro efektivní výměnu zpráv. Specifikace uvažuje čekací doby (latence) způsobené místní sítí (LAN) zajišťující efektivní výměnu dat i po dalších místních sítích. API pro generické zpracování událostí a vyžádání (GES) je uvažováno pro poskytnutí jednoho z primárních prostředků pro dosažení integrace aplikací. Kromě této náplně GES API určují ostatní API vysokou výkonnost, potřeby interakce v reálném čase pro aplikaci v pracujícím systému a rovněž generický přístup k datům na principu požadavku/odpovědi.
IEC 61970-405 vychází ze specifikace oddílu Výstrahy a Události ze Sběru dat v průmyslových systémech (DAIS A&E) od Skupiny pro správu objektů (OMG). Základem pro OMG DAIS A&E jsou specifikace OMG Prostředků pro přístup k datům (DAF) a OPC Výstrahy a Události (A&E). OMG DAIS A&E je model specifický pro platformu (PSM) s CORBA jako platformou a OPC A&E je PSM s Microsoft COM jako platformou. Realizátoři, kteří potřebují úvod do OMG DAIS A&E a OPC A&E, si musí přečíst tyto dokumenty.
GES rozhraní je určeno pro spolupráci s ostatními rozhraními vycházejícími z IEC 61970. Z tohoto důvodu je možno použít informace vybrané z ostatních rozhraní pro přístup k téže informaci pomocí tohoto rozhraní, například:
· identifikátory objektů,
· názvy nebo identifikátory atributů,
· názvy nebo identifikátory tříd.
Způsob organizování dat v serveru realizujícím GES rozhraní lze vidět pomocí prohledávacích rozhraní pro data a metadata. Je možno rovněž použít přímo rozhraní pro přístup k datům bez použití prohledávacích rozhraní, pokud klient předem zná identifikátory objektu, třídy a atributu. Identifikátory objektů lze získat pomocí dat z jiných rozhraní, například CIMXML souboru nebo rozhraní z IEC 61970-404. Informace o tom, jaké třídy a atributy jsou k dispozici budou uvedeny v dokumentech IEC 61970-45X.
IEC 61970-405 uvádí funkce způsobem nezávislým na technologii, tj. jako specifikaci nezávislou na platformě (PIM). Proto objasňuje funkce na úrovni, kterou lze použít k vytvoření dalších PSM nebo která slouží jako úvod do existujících PSM, tj. DAIS A&E a OPC A&E. Realizátoři, kteří potřebují úvod do OMG DAIS A&E a OPC A&E, si musí přečíst tyto dokumenty.
IEC 61970-405 se skládá ze dvou částí:
· SCADA výstrahy a události, což je specifikace nezávislá na platformě (PIM) převzatá z DAIS A&E a OPC A&E. Tato část se nazývá „Generické zpracování událostí a vyžádání výstrah a událostí“ (GES A&E).
· Generické zpracování zpráv, což je generalizace SCADA výstrah a událostí. Tato část se nazývá pouze „Generické zpracování událostí a vyžádání“ (GES).
IEC 61970-1 poskytuje referenční model EMS-API, z něhož vychází tato norma. V tomto referenčním modelu je zavedena terminologie použitá v této Části IEC 61970 a objasněna funkce CIS.
IEC 61970-401 poskytuje přehled a strukturu norem CIS (IEC 61970-4XX). IEC 61970-402 poskytuje základní služby a používá se společně s ostatními dokumenty IEC 61970-4XX. Tato specifikace rozšiřuje Obecné Služby tak, aby se zajistil pro aplikace při výměně CIM dat mechanizmus založený na vyžádání událostí.
Mapování IEC 61970-405 na realizaci konkrétních technologií nebo modelů specifických pro platformu (PSM) je dále uvedeno v samostatném souboru dokumentů, tj. připravované IEC 61970-5XX. U skutečných realizací se použijí připravovaná IEC 61970-5XX, OMG DAIS A&E, OMG DAF nebo OPC A&E.
2 Citované normativní dokumenty
Pro používání tohoto dokumentu jsou nezbytné dále uvedené referenční dokumenty. U datovaných odkazů platí pouze citovaná vydání. U nedatovaných odkazů platí poslední vydání referenčního dokumentu (včetně změn).
IEC 61970-1:2005 Energy management system application program interface (EMS-API) - Part 1: Guidelines and general requirements
(Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 1: Směrnice a obecné požadavky)
IEC/TS 61970-2 Energy management system application program interface (EMS-API) - Part 2: Glossary
(Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 2: Výklad zvláštních výrazů)
IEC 61970-301:2005 Energy management system application program interface (EMS-API) - Part 301: Common Information Model (CIM) base
(Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 301: Základ obecného informačního modelu (CIM))
IEC 61970-401 Energy management system application program interface (EMS-API) - Part 401: Component Interface Specification (CIS) Framework
(Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 401: Struktura specifikace rozhraní složek (CIS))
IEC 61970-402 Energy management system application program interface (EMS-API) - Part 402: Component Interface Specification (CIS) - Common Services
(Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API) - Část 402: Specifikace rozhraní složek (CIS) - Obecné služby)
Data Acquisition from Industrial Systems section Alarms and Events (DAIS A&E), OMG Adopted Specification, Version 1.1, formal/2005-06-01, June 2005 (Referred herein as „OMG DAIS A&E“)
(Sběr dat z průmyslových systémů oddíl Výstrahy a Události (DAIS A&E), specifikace převzatá OMG, Verze 1.1, oficiální/2005-06-01, červen 2005 (Zde označovaná jako „OMG DAIS A&E“))
Utility Management System (UMS) Data Access Facility (DAF), OMG Adopted Specification, Version 2.0.1, formal/05-06-03, July 2005 (Referred herein as „OMG DAF“)
(Prostředky pro přístup k datům (DAF) v řídicím systému společnosti (UMS), specifikace převzatá OMG, Verze 2.0.1, oficiální/05-06-03, červenec 2005 (Zde označovaná jako „OMG DAF“))
OPC Alarm and Events Specification, Version 1.10, OPC Foundation, October 2002 (Referred to herein as „OPC A&E“)
(Specifikace výstrah a událostí OPC, Verze 1.10, OPC nadace, říjen 2002 (Zde označovaná jako „OPC A&E“))
3 Termíny a definice
Pro účely tohoto dokumentu platí termíny a definice uvedené v IEC/TS 61970-2.
POZNÁMKA Definice obecných zvláštních výrazů viz mezinárodní elektrotechnický slovník, IEC 60050.
4 Generické zpracování událostí a vyžádání (normativní)
4.1 Přehled
4.1.1 Všeobecně
Obrázek 1 znázorňuje interakci mezi klientem a serverem při generickém zpracování událostí a vyžádání výstrah a událostí (GES A&E). Vyžádání znamená, že server předem nezná své klienty. Jakmile je navázáno spojení, volá server zpět klientům, když jsou daná data k dispozici nebo když jsou aktualizována.
Tato kapitola probírá generické zpracování událostí a vyžádání (GES), které je generalizací generického zpracování událostí a vyžádání výstrah a událostí (GES A&E). GES A&E je uveden v kapitole 5. Náplň GES A&E je určena pro SCADA výměnu dat, jak uvádí kapitola 5. Jednoduché události GES A&E lze použít pro mnohem širší rozsah a je základem pro GES.
4.1.2 Vhodnost GES pro integraci různorodých kategorií aplikací
Použití GES se neomezuje na data orientovaná na SCADA. GES lze použít pro kategorie aplikací vyměňujících si data nepocházející ze SCADA, což zahrnuje:
· Systémy pro řízení vypínání
· Síťové aplikace
· Řízení výroby
· Geografické informační systémy
· Systémy pro řízení elektrické energie
· Systémy pro řízení aktiv (kmenového majetku) a práce
· Jiné kategorie aplikací použité v provozu elektrizační soustavy uvedené v příloze B v IEC 61970-1 (2005).
4.1.3 Vhodnost GES pro integraci mimo řídicí centrum
I když cílem této IEC normy je technická oblast řídicího centra, obsahuje GES obecný soubor pojmů, které lze použít pro řadu typů systémů. Příklady takovýchto systémů zahrnují:
· Informační systémy pro odběratele.
· Automatizované systémy stanice. U integrace automatizovaných systémů stanice nutno poznamenat, že již existují některé specifikace týkající se komunikace, například soubor IEC 61850 pro komunikaci se stanicemi a IEC 60870-5 pro komunikaci s RTU. Záměrem této Části IEC 61970 je popsat rozhraní služeb jež může obsáhnout takováto řešení komunikace.
· Jiné typy technicky orientovaných provozních obchodních systémů.
Na základě poznání, že je často nezbytná integrace mezi aplikacemi ve dvou či více takovýchto systémech, je záměrem této Části IEC 61970 naplnit obecné požadavky GES v takovém rozsahu, aby byly obecné pro různé typy systémů i když fakticky určují potřeby řídicího centra.
4.1.4 Vhodnost GES pro integraci úzce provázaných a volně provázaných aplikací (informativní)
V posledních pár letech softwarové společnosti pochopily, že jsou nezbytné různé architektury software když se integrují úzce provázané aplikace (například aplikace přenosové sítě existující v řídicím centru společnosti) a když se integrují volně provázané aplikace (například aplikace distribuční sítě existující jako internetové služby). V případě úzce provázaných aplikací může integrační architektura vycházet z CORBA IIOP, Java RMI, Microsoft DCOM nebo i centralizované databáze. V případě volně provázaných aplikací je však obecně přípustné, aby se upřednostnila architektura zpracování zpráv vycházející z XML. Jedním z cílů GES je umožnit vývoj dané složky bez předchozí znalosti prostředí, ve kterém bude existovat. Tudíž mohou být například složky v GES rozhraní vzájemně provázány pomocí infrastruktury založené na volání dálkové procedury CORBA nebo na XML sběrnici zpráv.
Podle IEC 61970-1 je GES rozhraním složek a neobsahuje přístup k funkcím specifickým pro aplikační programové prostředky, například zpracování zpráv o kvalitě služby (QOS). I když GES neposkytuje rozhraní orientované na zprostředkovatele zpráv, lze GES použít jako rozhraní pro adaptér složek, který naopak zpřístupňuje rozhraní orientované na zprostředkovatele zpráv jako je například JMS nebo OAMAS.
Jsou možné specializace GES pro následující technologie rozhraní, z nichž některé jsou specifické pro určitý jazyk a některé z nich jsou specifické pro aplikační programové prostředky:
· C++ jazyk.
· C jazyk.
· CORBA.
· COM.
· Java.
· XML. XML specializace umožní funkční spolupráci mezi nezávisle vyvinutými složkami v GES rozhraní, pokud se použije jako integrační technologie zpracování zpráv založené na XML. Přesný formát tohoto XML se určí použitím specifikace, například XML protokol W3C.
Obrázek 2 níže znázorňuje, jak může být složka se specializací specifickou pro jazyk nebo pro technologii rozhraní u GES rozhraní přizpůsobena pro práci prostřednictvím realizace specifické pro aplikační programové prostředky. Tudíž v případě, kdy byla aplikační složka vyvinuta s použitím specializace specifické pro konkrétní jazyk, například CORBA, umožní použití adaptéru složkám komunikovat pomocí konkrétního aplikačního programového prostředku, například XML zpracování zpráv. GES je tudíž nezávislé na tom, jaká se použije přenosová technologie, například IIOP nebo XML protokol.
Obrázek 2 - Architektura složek
Nezávislost na prostředí rozmístění je základní aspekt funkční spolupráce složek a rovněž způsob pro snižování nákladů na vývoj těchto složek. Například tato specifikace poskytuje obecný způsob pro vyžadování a filtrování událostí malého objektu (rovněž nazývaného komerční objekt). COM neposkytuje žádný normalizovaný způsob pro vyžadování událostí týkajících se konkrétního malého objektu (například konkrétního jističe). Proto pokud pracuje prostřednictvím infrastruktury na bázi Microsoft je většinou až záležitostí integrátora systému, aby zajistil tyto funkce. Možnost pracovníků vyvíjejících komponenty s vyžadováním doplnit funkce pro filtrování událostí malého objektu „vně skříně“ (což se provádí u samostatných OPC klientů) snižuje čas a úsilí nezbytné pro integraci složek.
Možnost filtrování malého objektu ve složce neruší v žádném případě dohody mezi složkami, adaptéry složek a systémy realizace složek. Použití filtrování u malých objektů neurčuje rozhraní aplikačních programových prostředků. Důkaz pro to lze vidět v tom, že jak OPC tak DAIS poskytují filtrování událostí u malých objektů. DAIS/OPC se nepoužívají jako rozhraní aplikačních programových prostředků. Spíše se používají v rozhraní složek. API pro aplikační programové prostředky, například JMS a CORBA Notifikace, zahrnují sémantiku pro přenos, například QOS (např. charakteristiky dodání jako je spolehlivost, priorita a konečný čas) a rovněž administrativní (správní) funkce (např. vyrovnání zatížení sdělovacího kanálu událostí). QOS a administrativní funkce jsou specifické pro použité aplikační programové prostředky. Na druhou stranu je filtrování malých objektů obecné pro jakékoliv použité aplikační programové prostředky.
Použití funkcí předání/vyžádání existujících v rozhraní složek znamená, že kód filtrování událostí nemusí být přepsán při každém odlišném scénáři realizace. Filtrování událostí provádí složka a ne adaptér složky; proto lze namísto generických nástrojů pro filtrování událostí použít nástroje pro filtrování událostí specifické pro elektrizační soustavu (na základě CIM). Filtrování událostí na základě CIM poskytuje přirozenější a rovněž dynamičtější a snazší použití řízení konfigurace.
Kromě toho, protože lze GES API umístit nezávisle na jakémkoliv informačním modelu specifickém pro kategorii aplikací, není nutno GES rozhraní složek znovu kompilovat, když se informační model změní. Změny informačního modelu pro kategorii aplikací lze tudíž obsloužit pomocí deklarační akce spíše než pomocí programátorské akce.
4.2 Použití GES A&E jednoduchého zpracování událostí pro generické zpracování zpráv
4.2.1 Všeobecně
GES lze použít pro sestavení systému pro výměnu dokumentů. Zatímco rozhraní vysokorychlostního přístupu k datům (HSDA) uvedené v IEC 61970-404 zajišťuje vyžadování měření, parametru a dalších jednoduchých dat, rozhraní GES A&E uvedené v kapitole 5 umožňuje složkám vydávat a vyžadovat dokumenty neobsahující měření (například příkazy k práci) jako kontrast k sestavě bodů měření. Rozhraní pro zpracování událostí umožňuje složkám vydávat a vyžadovat takové dokumenty, jako jsou příkazy k práci, bez toho, že by musely vyžadovat každou charakteristiku příkazu k práci.
Přesněji, použití „Jednoduchých Událostí“ v rozhraních GES A&E se neomezuje na SCADA data. Jednoduché Události GES A&E mohou obsahovat užitečný obsah podle dokumentu, který může vyslat nebo přijmout libovolná aplikace řídicího centra. Takto jsou Jednoduché Události GES A&E užitečné pro získávání kompletního obecného informačního modelu (CIM). Data přenášená přes GES rozhraní jsou nezávislá na GES jazyku pro definování rozhraní (IDL - Interface Definition Language). GES lze tedy použít pro zjištění a přenos libovolného modelu výměny informací.
Schéma Jednoduchých Událostí GES A&E je generické. Jednoduché Události GES A&E mají následující vlastnosti:
· Zdroj - označení objektu, který generoval událost. Toto může být buď určitá položka, například konkrétní měření, nebo obecněji název CIM třídy a rovněž kategorie aplikace.
· Název cesty pro zdroj - úplný kvalifikovaný název cesty z IECTC57FyzickéhoModelu pro zdroj.
· Časový údaj - čas kdy došlo k dané události.
· Zpráva - textový řetězec popisující událost.
· Hlavní kategorie - u Jednotlivých Událostí to je pole obsahující ID prostředku pro Jednoduchou Událost.
· Kategorie - ID prostředku pro daný typ události. Každá kategorie odpovídá konkrétnímu schématu události.
· Název kategorie - název typu události.
· Závažnost - oznámení od serveru o stupni závažnosti této události.
· Vlastnosti - seznam mapovaných a/nebo indexovaných vlastností.
Například pole Zdroj může obsahovat odkaz na Systém Řízení Prací, pole Zpráva může obsahovat „Nový Příkaz K Práci“, Kategorie může obsahovat ID prostředku pro typ události „Požadavek Na Instalaci Transformátoru“, pole Název kategorie může obsahovat „Požadavek Na Instalaci Transformátoru“ a vlastnosti pak mohou být ta data, která náleží tomuto Požadavku Na Instalaci Transformátoru. Jak možno vidět z tohoto příkladu, mají v podstatě Jednoduché Události obecný účel - tj. může je použít libovolná kategorie aplikace pro výměnu informací.
4.2.2 GES zprávy
Obecný informační model uvedený v IEC 61970-301 definuje normalizovaný datový model pro použití při integraci aplikací řídicího centra. Připravované specifikace rozhraní složek IEC 61970-450 až IEC 61970-499 poskytnou přehledy dat, které nejsou normalizovány v IEC 61970-301. Například pokud jsou objekty z IEC 61970-301, jako jsou transformátory a zatížení, různých tříd, budou specifikace rozhraní složek v IEC 61970-450 až IEC 61970-499 definovat styl dokumentu tříd rozhraní, který může kombinovat několik vlastností z více normalizovaných tříd, jako jsou transformátory a zatížení. CIS dokumenty (typy událostí) v IEC 61970-450 až IEC 61970-499 poskytnou konkrétní způsoby aplikace pro seskupování nebo posuzování souboru vlastností.
4.2.3 Stromové struktury pro problematiku zpracování událostí a vyžádání (informativní)
Události mohou obsahovat dokumenty, které jsou předávány asynchronně. Zprávy mohou obsahovat dokumenty, použití termínu „zpráva“ však rovněž znamená přenosový mechanizmus orientovaný na zprostředkovatele. Termín událost je tudíž obecnější než zpráva.
GES zpracování událostí je obdobné jako rozhraní služby zpracování zpráv Java (JMS) s jediným podstatným rozdílem; GES zpracování událostí nezahrnuje přístup k funkcím specifickým pro zpracování zpráv, například službu zprostředkovatele zpráv QOS. Protože však GES zpracování událostí je rozhraní složek, které je nezávislé na tom, jaké aplikační programové prostředky se nacházejí mezi složkami, je nepřítomnost rozhraní specifického pro zpracování zpráv přípustná.
JMS model Předání/Vyžádání definuje, jaké složky JMS používá pro předání a vyžádání zpráv příslušejících přesně určenému uzlu v hierarchii podle obsahu. GES zpracování událostí nazývá tyto uzly Oblasti a JMS nazývá tyto uzly problematika. Předáváním na oblast/problematiku zprostředkovaně jsou editoři události/zprávy udržováni nezávislí vůči příjemcům a opačně. Řada poskytovatelů služby zpracování zpráv, například MQSeries, seskupují problematiku do hierarchií a poskytují různé možnosti pro vyžadování částí této hierarchie. Řetězce GES Oblasti se skládají z oblasti s názvy oblastí (plně kvalifikované názvy cesty) vytvořené jako výsledek navigace v hierarchické mapě oblastí. Ani GES zpracování událostí ani JMS neklade žádné omezení tomu, co představuje objekt oblast/problematika. Může být buď listem v hierarchii problematik nebo může být větší částí této hierarchie (pro vyžádání obecné třídy informací).
Často chtějí uživatelé mít data organizovaná podle přesně určené hierarchie problematik. GES nenormalizuje zobrazení přesně určených (např. podle CIM) hierarchických přehledů. IECTC57 Rozsahynázvů uvedené ve specifikaci Obecné Služby v IEC 61970-402 se používají v GES stejným způsobem, jako se používá OPC Dávka v OPC Přístupu K Datům a v OPC Výstrahách a Událostech pro poskytování prostředků jejichž pomocí mohou servery zobrazovat přesně určené hierarchické přehledy. Použití IECTC57 Rozsahůnázvů společně s rozhraními IOblast/IKategorie/ITyp (viz obrázek 7) poskytují základ pro vyžádání podle CIM. GES s Obecnými Službami tudíž poskytují standardní mechanizmus pro popisování, jak jsou CIM objekty uspořádány v hierarchii a rovněž způsob, jak komponenty použijí tyto hierarchie při sestavování vyžádáních událostí (dokumentů).
4.2.4 Filtrování vyžádání
GES filtrování vyžádání poskytuje možnost určit charakteristické hodnoty, jež jsou použity pro kvalifikování vyžádání. Z hlediska SQL je toto doplnění GES Filtrování ekvivalentní doplnění podmínky „kde“. Například účastník může určit, že chce přijmout události Instalace Nového Transformátoru a rovněž určit, že očekává pouze přijetí událostí Instalace Nového Transformátoru týkající se transformátorů vyráběných daným výrobcem.
GES objekt Vyžádání (viz obrázek 7) udržuje specifikaci filtru nastavenou klientem. Filtr se používá pro určení, jaká sdělení musí být odeslána klientovi. Server může zajistit různé funkce filtru a klient se může dotázat objektu Výchozí Místo Vyžádání (Subscription Home), jaké funkce filtru jsou zajištěny. Výchozí místo vyžádání se rovněž používá k vytvoření libovolného počtu objektů pro řízení vyžádání. Každý řídicí program vyžádání přísluší klientovi, který má realizován objekt zpětného dotazu, takže server může tomuto klientovi odeslat oznámení výstrah a událostí.
4.2.5 GES pseudoštítky Předání/Vyžádání
4.2.5.1 Všeobecně
GES Zpracování Událostí nezajišťuje funkce „pseudoštítku“ v důležitých řetězcích vyžádání. GES Zpracování Událostí například umožňuje složkám vyžádat si události podle Kategorie událostí (např. „Požadavek Na Instalaci Transformátoru“) nebo podle problematiky (např. všechny příkazy k práci pro jističe), ale neexistuje možnost
zvolit všechny oblasti v dané úrovni. Tato specifikace rozšiřuje GES Zpracování Událostí o zajištění pseudoštítků u filtrování podle problematiky. Rozhraní GES Zpracování Událostí se kvůli doplnění zajištění pseudoštítků v cestách oblasti nemění. Tato specifikace vyžaduje pro pseudoštítek dobrou znalost URI. URI pro pseudoštítek je: http://omg.org/schema/GES#WILDCARD.
4.2.5.2 Příklad hierarchií podle problematiky (informativní)
Pro znázornění jak se používají stromové struktury pro vyžádání podle problematiky se uvažuje stromová struktura problematik, která obsahuje hierarchii CIM modelu sestavy jak uvádí obrázek 3. Příklad řetězce oblasti vytvořený navigováním u výše uvedené stromové struktury může být „IECTC57FyzickýModel/SeverníOblast/StaniceLetiště“. V tomto případě může účastník přijmout všechny události patřící do této problematiky - zahrnující události týkající se jističe, transformátoru a zatížení. Pokud si však tento účastník chce vyžádat události týkající se jističe ze všech stanic, pak GES vyžaduje, aby tento uživatel konkrétně uvedl název každého uzlu stanice o nějž by měl zájem. Tato specifikace obsahuje dodatečnou možnost vytvořit řetězec oblasti (pole názvů oblasti), aniž by bylo nutno manuálně navigovat každý uzel o nějž je zájem. Takovýto řetězec problematiky může vypadat takto „IECTC57FyzickýModel/*/*/Jističe“.
Obrázek 3 - Rozvedený příklad rozsahu názvů pro IECTC57FyzickýModel (informativní)
4.2.6 Prohledávání IECTC57 rozsahů názvů v GES
4.2.6.1 Všeobecně
IEC 61970-402 Obecné Služby definuje tři stromové struktury či dílčí stromové struktury použité pro vyžádání podle problematiky:
· IECTC57FyzickýModel
· IECTC57ModelTříd
· IECTC57ISModel
IECTC57FyzickýModel obsahuje uzly vyžádání pode problematiky představující vymezující hierarchii případů CIM tříd, například řídicí oblasti, stanice, pole, jističe, apod. Pro prohledání této hierarchie používá GES prohledávací rozhraní IOblast (viz obrázek 7).
IECTC57ModelTříd obsahuje uzly vyžádání pode problematiky představující hierarchii tříd pro CIM třídy, například třída Prostředek Elektrizační Soustavy, třída AC Rozvodné Zařízení, třída Spínač, třída Jistič, apod. Pro prohledání této hierarchie používá GES prohledávací rozhraní ITyp (viz obrázek 7).
IECTC57ISModel obsahuje uzly vyžádání pode problematiky představující hierarchii typů událostí. Pro prohledání této hierarchie používá GES prohledávací rozhraní IKategorie (viz obrázek 7).
Pomocí OPC v GES klienti vyhledávají všechny uzly vyžádání pode problematiky prohledáváním Oblasti jejím procházením v téže stromové struktuře. Stromová struktura jednotlivých OPC rozsahů názvů může být rozdělena do tří dílčích stromových struktur: IECTC57FyzickýModel, IECTC57ModelTříd a IECTC57ISModel. Protože se data popisující vlastnosti liší v závislosti na zmíněné dílčí stromové struktuře, je záměrem GES mít prohledávače specifické pro dílčí stromové struktury, které předkládají data specifická pro tyto dílčí stromové struktury, tj. IOblast, ITyp a IKategorie (viz obrázek 7) pro charakteristické stromové struktury IECTC57FyzickýModel, IECTC57ModelTříd respektive IECTC57ISModel. GES prohledávání tudíž nežádá tři dílčí stromové struktury.
Použitím GES se IECTC57FyzickýModel, IECTC57ModelTříd a IECTC57ISModel stávají základem nezávislých charakteristických stromových struktur.
4.2.6.2 Mapování GES prohledávání na OPC prohledávání
4.2.6.2.1 Všeobecně
Aby se nahradilo nedostatečné zajištění problematiky u ID Prostředku a Typu v OPC musí se do OPC rozsahu názvu vyhovujícího GES zavést zvláštní charakteristiky.
4.2.6.2.2 Zákaznická charakteristika nezbytná pro ID Prostředku
OPC se liší od DAIS v tom, že pro vyžádání událostí lze použít pouze názvy. Pro zajištění shodného mapování z OPC na DAIS musí mít každý uzel v OPC realizaci IECTC57 Rozsahůnázvů definovanou zákaznickou charakteristiku pojmenovanou „ID Prostředku“. Tato charakteristika obsahuje hodnotu ID Prostředku pro tento objekt. Index OPC Zákaznické Charakteristiky pro tuto charakteristiku musí být 10 000. Formát této charakteristiky musí být znázornění ASCII řetězce hexadecimálních číslic: {xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx}.
4.2.6.2.3 Zákaznická charakteristika nezbytná pro Typ Prostředku
OPC se liší od GES v tom, že pro vyžádání událostí lze použít pouze názvy. Pro zajištění shodného mapování z OPC na GES musí mít každý uzel v OPC realizaci IECTC57 Rozsahůnázvů definovanou zákaznickou charakteristiku pojmenovanou „ID Prostředku“. Tato charakteristika obsahuje hodnotu ID Prostředku pro tento objekt. Index OPC Zákaznické Charakteristiky pro tuto charakteristiku musí být 10 001. Hodnota této zákaznické charakteristiky pro položky v IECTC57FyzickémModelu musí být stejná jako GES Typ v IECTC57ModeluTříd.
4.2.6.2.4 Zákaznická charakteristika nezbytná pro ID Typu Prostředku
OPC se liší od GES v tom, že pro vyžádání událostí lze použít pouze názvy. Pro zajištění shodného mapování z OPC na GES musí mít každý uzel v OPC realizaci IECTC57 Rozsahunázvů definovanou zákaznickou charakteristiku pojmenovanou „ID Typu Prostředku“. Tato charakteristika obsahuje hodnotu ID Prostředku pro určitý typ tohoto objektu. Index OPC Zákaznické Charakteristiky pro tuto charakteristiku musí být 10 002. Formát této charakteristiky musí být znázornění ASCII řetězce hexadecimálních číslic: {xxxxxxxx-xxxxxxxx-xxxxxxxx-xxxxxxxx}.
4.2.6.2.5 Zákaznická charakteristika nezbytná pro Typ Generického Přístupu K Datům
OPC se liší od GES v tom, že pro vyžádání událostí lze použít pouze názvy. Pro zajištění shodného mapování z OPC na GES musí mít každý atribut uzlu v OPC realizaci IECTC57 Rozsahůnázvů definovanou zákaznickou charakteristiku pojmenovanou „Typ Generického Přístupu K Datům“. Tato charakteristika určuje GDA typ dat Jednoduchá Hodnota u daného atributu. Index OPC Zákaznické Charakteristiky pro tuto charakteristiku musí být 10 003.
4.2.6.2.6 Zákaznická charakteristika nezbytná pro Modelováno
OPC se liší od GES v tom, že pro vyžádání událostí lze použít pouze názvy. Pro zajištění shodného mapování z OPC na GES musí mít každý atribut uzlu v OPC realizaci Rozsahunázvů v IECTC57ISModelu definovanou zákaznickou charakteristiku pojmenovanou „Modelováno“. Tato charakteristika určuje, mohou-li být atributy mapovány na ID prostředku použitím SlužbyIDProstředku. U atributů, které mohou být mapovány, je hodnota této charakteristiky ASCII řetězec „Mapováno“. U atributů, které nemohou být mapovány, je hodnota této charakteristiky ASCII řetězce „Indexováno“. Index OPC Zákaznické Charakteristiky pro tuto charakteristiku musí být 10 004.
5 Generické Výstrahy a Události při Vyžádání Událostí
5.1 Podmínky vzniku (informativní)
Z historických důvodů se řídicí systémy pro různé průmyslové procesy vyvíjely různými směry. Řídicí systémy pro elektrizační soustavy byly vyvíjeny na bázi UNIX a řídicí systémy pro většinu ostatních průmyslových procesů byly vyvíjeny na bázi Windows. U řídicích systémů na bázi Windows se stal rozhodující normou OPC. U systémů založených na bázi UNIX byl vyvinut DAIS API definovaný v Jazyku pro definování rozhraní (IDL - Interface Definition Language) Architektury zprostředkovatele požadavků na obecný objekt (CORBA - Common Object Request Broker Architecture). DAIS vychází z OPC těžíce z úspěšnosti OPC a umožňuje snadnou emulaci na OPC. S tímto záměrem zahájila Skupina pro správu objektů (OMG) v roce 1997 vývoj rozhraní založeného na CORBA se stejnými funkcemi jako OPC. GES A&E má funkce z OMG DAIS A&E a OPC A&E uvedeny způsobem nezávislým na technologii, protože GES A&E je zamýšlen jako model nezávislý na platformě (PIM).
5.2 Možnost použití SCADA (informativní)
Výstrahy jsou generovány se záměrem upoutat pozornost na poruchové stavy vyžadující zásah obsluhy. Proto jsou výstrahy zaznamenávány a předkládány obsluze. Předložení obvykle zahrnuje akustickou signalizaci a určité zvýraznění, například červená barva a/nebo blikání, apod. Události jsou obecnější a mohou být generovány z různých důvodů a jsou předávány těm klientům, kteří mají zájem na konkrétních informačních problematikách. GES A&E se může použít ke sledování a řízení elektrizační soustavy mající následující hlavní části:
· Přístrojové vybavení procesu poskytující data z čidel a možnosti ovládání.
· Vzdálené terminály (RTU) nebo řídicí systémy stanice snímající data z čidel a řídící ovládače.
· Komunikační jednotky procesu připojené na RTU nebo řídicí systémy stanice.
· Dílčí systém SCADA poskytující zpracovaná data z čidel a možnosti ovládání obsluze, aplikacím nebo jiným systémům.
· Systémy řízení elektrické energie (EMS) používající dílčí systémy SCADA pro rozšířené zpracování a řízení.
U SCADA/EMS se dílčí systém SCADA obvykle soustřeďuje na předkládání výstrah a událostí týkajících se zařízení v terénu. U takovéhoto systému postupují data tak, jak znázorňuje obrázek 4.
Obrázek 4 - Obvyklé toky DAIS výstrah a událostí u SCADA
Servery Výstrah a Událostí mohou být hierarchicky uspořádány, když jednotlivé servery generují výstrahy, které snímají servery mající vyšší funkce, například filtrování výstrah a jejich ukládání do paměti.
Rozhraní DAIS Výstrah a Událostí lze použít pro řadu různých účelů:
· Předkládání výstrah nebo událostí z procesu v seznamech událostí.
· Tisk výstrah a událostí na papír.
· Archivování výstrah a událostí.
· Sběr výstrah a událostí z jednotlivých zdrojů nadřazenými servery obsluhujícími výstrahy a události.
· Potvrzení výstrah.
Pro možnost použití existují dva hlavní aktivní účastníci
· Technik údržby, který konfiguruje výstrahy a vyžádání událostí.
· Obsluha (operátor), která si vyžaduje předložení seznamů výstrah, prohlíží výstrahy vytištěné na papír nebo potvrzuje výstrahy. Obsluha může rovněž filtrovat výstrahy předkládané v seznamech. Předpokládá se, že v tomto případě existuje GUI, které doplňuje specifikaci parametrů filtrování.
5.3 Datový model (normativní)
GES A&E datový model popisuje, jak jsou data získávaná prostřednictvím GES A&E rozhraní organizována v serveru. Realizace serveru může organizovat data různě, ale klient používající GES A&E uvidí datový model tak, jak je uveden na obrázku 5.
Obrázek 5 - GES A&E datový model
Hlavní objekty nacházející se v serveru výstrah a událostí jsou:
· Oblasti, které organizují Zdroje do hierarchické struktury.
· Zdroje, které jsou objekty z nichž pocházejí výstrahy.
· Kategorie, které jsou kategorizací zpracování výstrah.
· RozsahyStavu, které definují typy zpracování výstrah.
· Stavy, které definují stavy výstrah.
· Typ, který definuje typ zdroje.
· Vlastnost, která definuje vlastnosti určené pro daný Typ a která může být obsažena v Kategoriích.
· Vyžádání a Filtry.
Zdroj označuje původce události, například:
· Poloha jističe, analogové měření, nádrž, generátor, apod.
· Aplikační program, například Informační Systém Zákazníka.
Oblasti se používají pro vytvoření hierarchického uspořádání Zdrojů. Oblasti se obvykle používají pro zajištění oprávnění obsluhy. Určitá oblast může zahrnovat jiné Oblasti nebo Zdroje. Klient může filtrovat vyžádání události definováním konkrétní oblasti, aby omezil přijatá oznámení událostí.
Kategorie se používají k popisu zpracování výstrah. Jsou definovány následující základní kategorie.
· Jednoduchá, která se používá pro události bez výstrahy.
· Sledování, která se používá ke sledování činností obsluhy, rovněž bez výstrahy.
· Stavu, která se používá pro výstrahy.
Všechnu tři mohou být dále specializovány do dílčích kategorií.
RozsahStavu definuje typ zpracování výstrahy, například hladina nádrže s pěti mezními hodnotami, jistič s polohami vypnuto, zapnuto a mezipolohou.
Stav definuje stav náležící do RozsahuStavu. Stav je popsán určitým stavem, který je aktivní. Rovněž je popsán výstražnou signalizací realizovanou v případě aktivní výstrahy, například závažností. Každý Stav je popsán pomocí pravidel uvádějících rozsah hodnot, například
· „Vypnuto“, pokud poloha jističe = rozepnut.
· Stav Horní Výstraha, když hodnota > horní mez pro výstrahu.
· „Disková Paměť Plná“, když je přeplněn paměťový prostor u Informačního Systému Zákazníka.
StavZdroje popisuje aktuální aktivní Stav u Zdroje. Ač může mít Zdroj definováno několik svých RozsahůStavu, bude mít každý RozsahStavu pro určitý Zdroj jeden StavZdroje. StavZdroje má následující data popisující stav výstrahy:
· Aktivován, který indikuje, zda je pro daný Zdroj aktivován tento RozsahStavu.
· Aktuální aktivní Stav, je-li aktivován.
· Aktivní, který udává, zda aktuální aktivní Stav indikuje poruchu.
· Výstraha, který udává, existuje-li nějaká nepotvrzená výstraha.
Typ definuje typ Zdroje, například měření, jistič, nádrž, generátor, apod.
Vyžádání umožňuje klientovi přijímat události asynchronně. Filtry se používají pro vymezení, jaké události a výstrahy klient přijímá.
5.4 Zprávy (normativní)
Zdroj může vyvolat následující hlavní typy zpráv:
· JednoducháUdálost, která náleží do JednoduchéKategorie.
· UdálostSledování, která náleží do KategorieSledování.
· UdálostStavu, která náleží do KategorieStavu.
Obrázek 6 uvádí typy zpráv.
Obrázek 6 - Zprávy s událostmi
JednoduchéUdálosti obsahují následující data:
· Označení objektu Zdroj.
· Časový údaj udávající kdy událost vznikla.
· Text zprávy.
· Označení Kategorie.
· Závažnost události.
· Zákaznický seznam charakteristických hodnot, tj. dvojic název hodnota.
UdálostiSledování jsou způsobeny aktivním účastníkem či obsluhou. Typickými akcemi jsou zápisy dat, povely nebo potvrzení. Událost sledování je stejná jako JednoducháUdálost s následujícími dalšími daty:
· Označení aktivního účastníka nebo obsluhy.
UdálostiStavu jsou výstrahy obsahující navíc oproti JednoduchéUdálosti následující informace:
· Označení RozsahuStavu.
· Označení aktuálního Stavu, například „Horní výstraha“, „Plný Disk“.
· Nepotvrzenou výstrahu, tj. aktuální Stav vyžadující potvrzení.
· Čas, kdy tento aktuální Stav byl aktivován.
· Specifikaci změny udávající co se změnilo.
· Aktuální stav výstrah u Zdroje a RozsahStavu, tj. výstražná signalizace je aktivována, existuje nepotvrzená výstraha nebo existuje porucha (je aktivní Stav indikující poruchu).
· Identifikaci potvrzování použitou při následném potvrzení obsluhou.
· Kvalitu hodnoty vyvolávající výstrahu.
Pokud potvrzuje obsluha výstrahu, je toto hlášeno pomocí zprávy UdálostSledování obsahující jméno obsluhy (operátora).
5.5 Rozhraní (normativní)
5.5.1 Objekty a rozhraní
Typy objektů (např. Server, Klient, Relace, apod.) uvedené v této kapitole musí všechny existovat v jakékoliv realizaci, pokud není uvedeno jinak. U libovolné realizace je přípustné vytvořit více typů objektů než jsou objekty uvedené dále, například namísto realizování určitého typu objektu více rozhraními může každé rozhraní realizovat specifický typ objektu jako u OMG DAIS A&E.
GES A&E rozhraní, objekty a jejich vazby jsou uvedeny na obrázku 7.
Obrázek 7 - GES A&E objekty a rozhraní
GES A&E Server je objekt, který může mít určitý počet Klientů jež jej používají. Má řadu objektů Relace. Rovněž nutno poznamenat, že objekty Server a Relace mohou být zkombinovány do jednoho objektu jako v OPC A&E.
Prohledávací rozhraní (tj. Typ, Vlastnost, Oblast, Zdroj, RozsahStavu, StavZdroje a Kategorie) přímo odpovídají objektům v datovém modelu uvedeném na obrázku 5. Objekt Relace má řadu rozhraní:
· IRelace, které se používá k řízení relace.
· Prohledávač IOblast, který se používá k získání objektů Oblasti.
· Prohledávač IZdroj, který se používá k získání objektů Zdroje.
· Prohledávač IRozsahStavu, který se používá k získání objektů RozsahuStavu a jejich objektů Stav.
· Prohledávač IStavZdroje, který se používá k získání objektů StavZdroje.
· Prohledávač IKategorie, který se používá k získání objektů Kategorie a dílčí-Kategorie.
· Prohledávač ITyp, který se používá k nalezení metadat o datových objektech (tj. tříd) realizovaných HSDA serverem.
· Prohledávač IVlastnost, který se používá k nalezení metadat o datech daného objektu (tj. vlastností) realizovaných HSDA serverem.
· Rozhraní IVyžádání, které se používá k vytvoření objektů Vyžádání.
Objekt Relace má řadu objektů Vyžádání používaných Klienty pro řízení Vyžádání prostřednictvím rozhraní IŘízeníVyžádání. Každé Vyžádání je popsáno SpecifikacíFiltru. ZpětnýDotaz je objekt, který realizuje rozhraní IAEZpětnýDotaz a který je realizován klientem. Objekt ZpětnýDotaz používá server pro předání výstrah nebo událostí podle SpecifikaceFiltru ve Vyžádání. Existují následující parametry SpecifikaceFiltru definující co musí obsahovat vyžádání:
· FormátUdálosti, který definuje typy zpráv uvedené v 5.4.
· Kategorie.
· Horní a dolní mez pro Závažnost.
· Zdroje.
· Oblasti.
· Typy.
Ponechání některého z těchto parametrů nedefinovaného znamená, že všechny objekty u tohoto parametru musí být obsaženy ve vyžádání.
Posloupnost typických interakcí mezi GES A&E Serverem a Klientem je uvedena na obrázku 8.
Obrázek 8 - Typická interakce mezi DAIS A&E objekty
Obrázek 8 rovněž uvádí data zpráv s výstrahami či událostmi uvedenými v 5.4.
Klient obvykle začíná prohledáváním serveru, aby zjistil, která data jsou k dispozici. K tomuto se používají prohledávací API (Oblast, Zdroj, RozsahStavu a StavZdroje). Získané informace se použijí k definování počtu filtrů. Klient bude mít pravděpodobně GUI, které pomáhá při vytváření specifikací filtrů.
Později, například při žádosti o seznam výstrah nebo událostí, budou uložené specifikace filtrů opětovně vyvolány a použity pro sestavení vyžádání. Samozřejmě to, jak je volena specifikace filtru závisí na realizaci.
5.5.2 Rozhraní Serveru a Relace
Rozhraní IServer má následující atributy a metody:
· vytvoření_relace_výstrah_a_událostí().
· vytvoření_relace_výstrah_a_událostí_pro_přehled(). Tuto metodu lze použít, pokud server zajišťuje více hierarchií. Každá hierarchie pak odpovídá určitému přehledu.
· nalezení_přehledů(), která vrací přehledy zajišťované serverem.
· čtení pouze atributu Status serveru, který sděluje status Serveru, například informace dodavatele, čas spuštění, aktuální čas, apod.
· čtení pouze atributu, který sděluje funkce zajišťované rozhraním.
Rozhraní IDARelace má následující atributy a metody:
· čtení pouze atributu statusu, který sděluje status Relace, například název, čas spuštění, aktuální čas a počet skupin.
· atribut uchovávající nepovinný objekt Vypnutí.
5.5.3 Prohledávací rozhraní
Rozhraní IUzel, ITyp, IOblast, IZdroj a IKategorie mají následující společné metody:
· nalezení(), která vrací více informací o jednom objektu určeném jeho id.
· nalezení_každého(), která vrací více informací o počtu objektů určených jejich id.
· nalezení_podle_původce(), která vrací všechny odvozené objekty z původního objektu s určeným id.
· nalezení_podle_typu(), která rekurzívně vrací všechny odvozené objekty s daným Typ.id z původního objektu s určeným id.
· získání_názvů_cest(), která přenáší počet názvů cest pro příslušné id.
· získání_ids(), která přenáší počet id pro názvy cest.
Rozhraní IOblast má navíc metody:
· aktivace_stavu(), která se používá k aktivaci hlášení výstrah u všech Zdrojů náležících do dané Oblasti.
· deaktivace_stavu(), která se používá k deaktivaci hlášení výstrah u všech Zdrojů náležících do dané Oblasti.
Rozhraní IZdroj má navíc metody:
· aktivace_stavu(), která se používá k aktivaci hlášení výstrah u určeného Zdroje.
· deaktivace_stavu(), která se používá k deaktivaci hlášení výstrah u určeného Zdroje.
· převod_na_ids_položky(), která se používá pro zjištění identit DAIS DA Uzlů odpovídajících určeným Zdrojům.
Rozhraní IKategorie má navíc metody:
· získání_vlastností_události(), která se používá k získání zákaznických charakteristik, jež může server doplnit do zprávy JednoducháUdálost.
Rozhraní IRozsahStavu má následující metody:
· nalezení(), která vrací více informací o jednom RozsahuStavu určeném jeho id.
· nalezení_každého(), která vrací více informací o určitém počtu RozsahůStavu určených jejich id.
· nalezení_podle_kategorie(), která vrací všechny RozsahyStavu pro určenou Kategorii.
· nalezení_podle_zdroje(), která vrací všechny RozsahyStavu pro určený Zdroj.
· získání_názvů_cest(), která přenáší počet názvů cest pro příslušné id.
· získání_ids(), která přenáší počet id pro názvy cest.
Rozhraní IStavZdroje má následující metody:
· nalezení(), která vrací více informací o jednom StavuZdroje určeném jeho id.
· nalezení_každého(), která vrací více informací o určitém počtu StavuZdroje určených jejich id.
· stav_potvrzení(), která se používá k potvrzení určitého počtu výstrah, kdy každá výstraha je určena pomocí identifikace Potvrzení z výstražné zprávy.
Rozhraní IVyžádání má následující atributy a metody:
· dotaz_na_dostupné_filtry(), která vrací možnosti filtrování realizované serverem.
· vytvoření_vyžádání(), která vytváří objekt Řízení vyžádání.
Rozhraní IŘízeníVyžádání má následující atributy a metody:
· atribut zpětný dotaz, který udržuje objekt zajištěný pro klienta, který vytvořil objekt Vyžádání. Klient musí tento atribut aktualizovat v objektu zpětného dotazu.
· nastavení_filtru(), která poskytuje SpecifikaciFiltru pro vyžádání.
· získání_filtru(), která získá aktuální SpecifikaciFiltru z vyžádání.
· volba_vracených_vlastností(), která se používá k určení HodnotVlastností, které musí být obsaženy ve zprávách s událostmi.
· získání_vracených_vlastností(), která se používá k získání těch HodnotVlastností, které jsou aktuálně obsaženy ve zprávách s událostmi.
· obnovení(), která požaduje od serveru nahlášení všech aktuálně aktivních nebo nepotvrzených Stavů tvořících SpecifikaciFiltru.
· asynchronní_čtení_historie() hlásí určený počet výstrah a událostí od daného počátečního času.
· zrušení(), která se používá k přerušení stále pokračujícího hlášení z důvodu obnovení() nebo asynchronního_
čtení_historie().
· získání_stavu(), která se používá k získání následujících informací na vyžádání: je-li aktivní, maximální doba čekání před vysláním vyrovnávací paměti zpráv, maximální velikost vyrovnávací paměti zpráv před vysláním jejích zpráv a minimální čas před vysíláním zpráv.
· nastavení_stavu(), která se používá k nastavení výše uvedených dat.
· rozmnožení(), která se používá k rozmnožování vyžádání.
· odstranění(), která se používá k odstranění vyžádání a jeho prostředků.
5.5.4 Rozhraní klienta
Pro zajištění vyžádáních musí Klient realizovat rozhraní IZpětnýDotaz s objektem ZpětnýDotaz s následujícími metodami:
· při_události(), kterou používá server k hlášení výstrah a zpráv s událostmi (viz 5.4) odpovídajících aktivní SpecifikaceFiltru pro vyžádání. Požadování obnovení() klientem bude mít rovněž za následek hlášení zpráv.
· při_kompletním_čtení(), která se používá k hlášení výstrah a událostí požadovaných klientem pomocí vyžadování asynchronního_čtení_historie().
5.5.5 Mapování DAIS A&E na soubor IEC 61970-3XX
GES A&E rozhraní mohou přenášet data pocházející z datového zdroje vyhovujícího IEC 61970-301. U serveru vyhovujícího IEC 61970-301, který zajišťuje GES, se musí rozhraní použít následovně:
· Prohledávací rozhraní IOblast poskytuje hierarchickou organizaci Zdrojů podle 4.2. V IEC 61970 neexistuje model odpovídající datům Oblasti.
· Prohledávací rozhraní IZdroj poskytuje objekty Zdrojů, které mohou mít výstražné Stavy. Objekty Zdrojů mohou být libovolného Typu. Takovéto typy objektů jsou definovány v IEC 61970-301 nebo jsou to rozšíření vycházející z IEC 61970-301.
· Rozhraní IRozsahStavu, IStavZdroje, IKategorie a IVyžádání poskytují data, která jsou specifická pro zpracování výstrah a událostí a neobsahují ta data, která jsou definována v IEC 61970.
· Prohledávací rozhraní ITyp poskytuje třídy (metadata) definované v IEC 61970-301, například Stanice, Pole, Měření, apod. Třídy jsou poskytovány v ploché struktuře, tj. přebírání mezi třídami není poskytováno jako hierarchická struktura. Je to PřehledTříd uvedený v IEC 61970-402.
· Prohledávací rozhraní Vlastnost poskytuje vlastnosti (metadata) definované pro danou třídu v IEC 61970-301.
Příloha A (informativní)
Proxy sekvence Vyžádání Událostí
Obrázky A.1 až A.4 znázorňují delegování vyžádání a zpětných dotazů přes proxy GES server.
Obrázek A.1 - Proxy sekvence vyžádání a zpětného dotazu s více servery
Obrázek A.1 znázorňuje dva způsoby delegování vyžádání přes proxy GES server na dva servery. V prvním případě proxy neví, jaká data který server poskytuje. V tomto případě jsou prostě všechny zprávy s vyžádáními předány na všechny servery. Z hlediska klientů existuje pouze jeden server, daný klient tudíž netuší umístění serverů. To napomáhá ke zrušení vazby klientů a serverů, jelikož konfigurace klienta se nemusí při změně umístění serveru měnit. V druhém případě ví proxy jaká data který server poskytuje. V tomto případě jsou vyžádání zaslána pouze na příslušný server. Tato modernější konfigurace minimalizuje komunikační provoz po síti a rovněž poskytuje základní funkce nezbytné k sestavení systému v němž klient obdrží oznámení, pokud nejsou data, která vyžaduje, k dispozici.
Obrázek A.2 - Proxy sekvence vyžádání s více klienty
Obrázek A.2 znázorňuje delegování vyžádání přes proxy GES server od dvou klientů. V tomto případě server neví, jaká data který klient vyžaduje. Z hlediska serveru existuje pouze jeden klient, server tudíž netuší umístění klientů. To napomáhá ke zrušení vazby klientů a serverů, jelikož konfigurace serveru nesleduje více klientů.
Obrázek A.3 - Proxy sekvence zpětného dotazu s více servery
Proxy GES poskytovatel (editor) musí realizovat volající stranu IO::ZpětnýDotaz::při_události. Obrázek A.3 znázorňuje dva způsoby předání zpráv při_události přes proxy GES server od dvou serverů. V prvním případě proxy prostě předá všechny zprávy tak, jak je přijal. Ve druhém případě proxy sdruží (strukturuje) zprávy při_události tak, aby klient přijal zprávy s ohledem na rychlost aktualizace nastavenou při procesu vyžádání.
Pro zkombinování zdrojů událostí se musí proxy připojit ke všem rozhodujícím GES poskytovatelům a přijmout jejich zprávy při_události. Pak musí poskytnout službu pro danou událost klientům. Každá událost od každého GES poskytovatele je předána klientům.
Obrázek A.4 - Proxy sekvence zpětného dotazu s více klienty
Obrázek A.4 znázorňuje delegování zpráv při_události přes proxy GES server na dva klienty. V tomto případě ví proxy jaká data má který klient vyžádána a zprávy při_události jsou vyslány pouze na příslušného klienta. Tato modernější konfigurace může výrazně snížit zatížení serveru a umožnit decentralizaci zpracování dat v systému.
Bibliografie
IEC 61850-7-2, Communication networks and systems in substations - Part 7-2: Basic communication structure for substation and feeder equipment - Abstract communication service interface (ACSI)
(Komunikační sítě a systémy v podřízených stanicích - Část 7-2: Základní komunikační struktura pro podřízené stanice a napájecí zařízení - Abstraktní rozhraní pro komunikační služby (ACSI))
POZNÁMKA Je v souladu s EN 61850-7-2:2003 (bez modifikací).
IEC 61968-1, Application integration at electric utilities - System interfaces for distribution management - Part 1:
Interface architecture and general requirements
(Integrace aplikací v energetických společnostech - Systémová rozhraní pro řízení dodávky elektrické energie -
Část 1: Architektura rozhraní a obecné požadavky)
POZNÁMKA Je v souladu s EN 61968-1:2004 (bez modifikací).
IEC 61968-3, Application integration at electric utilities - System interfaces for distribution management - Part 3:
Interface for network operations
(Integrace aplikací v energetických společnostech - Systémová rozhraní pro řízení dodávky elektrické energie -
Část 3: Rozhraní pro provoz soustavy)
POZNÁMKA Je v souladu s EN 61968-3:2004 (bez modifikací).
Control Center Application Program Interface (CCAPI) Project: API Standard Proposal Requirements for Generic
Interface Definition (GID), EPRI, Palo Alto, CA: 2001. 1001975
(Projekt Rozhraní Aplikačního Programu Řídicího Centra (CCAPI): Požadavky Návrhu API Normy pro Definování Generického Rozhraní (GID), EPRI, Palo Alto, CA: 2001. 1001975)
OMG, Utility Management System Data Access Facility, document formal/2001-06-01
(OMG, Prostředky Pro Přístup k Datům v Řídicím Systému Společnosti, oficiální dokument/2001-06-01)
OPC Foundation, OPC Data Access Custom Interface Specification
(OPC Nadace, Zákaznická Specifikace Rozhraní pro OPC Přístup k Datům)
OPC Foundation, OPC Historical Data Access Custom Interface Specification
(OPC Nadace, Zákaznická Specifikace Rozhraní pro OPC Přístup k Historickým Datům)
OPC Foundation, OPC XML Specification
(OPC Nadace, OPC XML Specifikace)
OPC Foundation, OPC Batch Custom Interface Specification
(OPC Nadace, Zákaznická Specifikace Rozhraní pro OPC Dávky)
Sun Microsystems, Java 2 Enterprise Edition, J2EE Connector Architecture Specification
(Sun Microsystems, Podnikové Vydání Java 2, Specifikace Architektury Konektoru J2EE)
Sun Microsystems, Java Messaging Service Specification
(Sun Microsystems, Specifikace Služby Zpracování Zpráv Java)
Open Applications Group, Open Applications Middleware API Specification
(Skupina pro Základní Aplikace, Specifikace API Aplikačních Programových Prostředků pro Základní Aplikace)
Resource Description Framework (RDF) Model and Syntax Specification, W3C Recommendation, 22 February 1999 http://www.w3.org/TR/REC-rdf-syntax, Ora Lassila, Ralph R. Swick
(Definiční Struktura Prostředků (RDF), Specifikace Modelu a Syntaxe, Doporučení W3C, 22. února 1999,
http://www.w3.org/TR/REC-rdf-syntax, Ora Lassila, Ralph R. Swick)
Resource Description Framework (RDF) Schema Specification, W3C Proposed Recommendation, 03 March 1999 http://www.w3.org/TR/PR-rdf-schema, Dan Brickley, R.V. Guha, Netscape
(Definiční Struktura Prostředků (RDF), Specifikace Schéma, Návrh Doporučení W3C, 3. března 1999,
http://www.w3.org/TR/PR-rdf-schema, Dan Brickley, R.V. Guha, Netscape)
Uniform Resource Identifiers (URI): Generic Syntax; Berners-Lee, Fielding, Masinter, Internet Draft Standard August, 1998; RFC2396
(Jednotné Identifikátory Prostředků (URI): Generická Syntaxe, Berners-Lee, Fielding, Masinter, Internetový Návrh Normy, srpen 1998, RFC2396)
Namespaces in XML; Bray, Hollander, Layman eds., W3C Recommendation; http://www.w3.org/TR/1999/REC-xml-names-19990114
(Rozsahy Názvů v XML, Bray, Hollander, Layman a spol., Doporučení W3C, http://www.w3.org/TR/1999/REC-xml-names-19990114)
Příloha ZA (normativní)
Normativní odkazy na mezinárodní publikace a na jim příslušející evropské publikace
Pro používání tohoto dokumentu jsou nezbytné dále uvedené referenční dokumenty. U datovaných odkazů platí pouze citovaná vydání. U nedatovaných odkazů platí poslední vydání referenčního dokumentu (včetně změn).
POZNÁMKA Pokud byla mezinárodní publikace upravena společnou modifikací, vyznačenou pomocí (mod), používá se příslušná EN/HD.
Publikace Rok Název EN/HD Rok
IEC 61970-1 2005 Rozhraní aplikačního programu pro systémy EN 61970-1 2006
řízení elektrické energie (EMS-API) -
Část 1: Směrnice a obecné požadavky
IEC/TS 61970-2 -1) Rozhraní aplikačního programu pro systémy CLC/TS 61970-2 20052)
řízení elektrické energie (EMS-API) -
Část 2: Výklad zvláštních výrazů
IEC 61970-301 2003 Rozhraní aplikačního programu pro systémy EN 61970-301 2004
řízení elektrické energie (EMS-API) -
Část 301: Základ obecného informačního
modelu (CIM))
IEC/TS 61970-401 -1) Rozhraní aplikačního programu pro systémy - -
řízení elektrické energie (EMS-API) -
Část 401: Struktura specifikace rozhraní
složek (CIS)
IEC 61970-402 -3) Rozhraní aplikačního programu pro systémy - -
řízení elektrické energie (EMS-API) -
Část 402: Specifikace rozhraní složek (CIS) -
Obecné služby
OMG DAIS A&E 2005 Sběr dat z průmyslových systémů - -
oddíl Výstrahy a Události (DAIS A&E)
OMG DAF 2005 Prostředky pro přístup k datům (DAF) v řídicím - -
systému společnosti (UMS)
OPC A&E 2002 Specifikace výstrah a událostí OPC - -
_______________
1) Nedatovaný odkaz.
2) Platná edice v době vydání.
3) Ve stádiu návrhu.
Prázdná strana
-- Vynechaný text --