ICS 33.200; 35.240.50 Prosinec 2006
|
Rozhraní aplikačního programu pro systémy řízení |
ČSN 33 4910 |
idt IEC 61970-1:2005
Energy management system application program interface (EMS-API) -
Part 1: Guidelines and general requirements
Interface de programmation d’application pour système de gestion d’énergie (EMS-API) -
Partie 1: Lignes directrices et exigences générales
Schnittstelle der Anwendungsprotokolle von Energieverwaltungssystemen (EMS-API) -
Teil 1: Leitfaden und allgemeine Anforderungen
Tato norma je českou verzí evropské normy EN 61970-1:2006. 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-1:2006. It was translated by Czech Standards Institute. It has the same status as the official version.
 | © Český normalizační institut, 2006 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. | 77384 |
Národní předmluva
Informace o citovaných normativních dokumentech
IEC TS 61970-2 nezavedena
IEC 61970-301 zavedena v ČSN EN 61970-301 (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)
Obdobné mezinárodní normy
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)
Porovnání s mezinárodní normou
Obsah normy je identický s IEC 61970-1:2005 a navíc obsahuje normativní přílohu ZA, kterou doplnil CENELEC.
Informativní údaje z IEC 61970-1:2005
Mezinárodní norma IEC 61970-1 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/777/FDIS |
57/795/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.
Tato norma byla vypracována podle Směrnic ISO/IEC, Část 2.
IEC 61970 se skládá z následujících Částí se společným názvem Rozhraní aplikačního programu pro systémy řízení elektrické energie (EMS-API):
Část 1: Směrnice a obecné požadavky
Část 2: Výklad zvláštních výrazů
Část 301: Základ obecného informačního modelu (CIM)
Část 302: Obecný informační model (CIM) - Financování, plánování a zajištění elektrické energie1)
Část 401: Struktura specifikace rozhraní složek (CIS)
Část 402: Specifikace rozhraní složek (CIS) - Obecné služby1)
Část 403: Specifikace rozhraní složek (CIS) - Generický přístup k datům1)
Část 404: Specifikace rozhraní složek (CIS) - Vysokorychlostní přístup k datům1)
Část 405: Specifikace rozhraní složek (CIS) - Generické zpracování událostí a indexování1)
Část 407: Specifikace rozhraní složek (CIS) - Přístup k datům v časové řadě1)
Část 453: Výměna definic grafických diagramů (Obecná grafická výměna)1)
Část 501: Obecný informační model (CIM) - XML kodifikace pro programovatelné reference a výměnu dat modelu
_______________
1) Připravuje se.
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.
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
Prázdná strana
|
|
ICS 33.200
|
Rozhraní aplikačního programu pro systémy řízení elektrické energie Energy management system application program interface (EMS-API) |
|
|
Interface de programmation d’application pour |
Schnittstelle der Anwendungsprotokolle von |
Tato evropská norma byla schválena CENELEC 2005-12-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, Č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 © 2006 CENELEC Veškerá práva pro využití
v jakékoli formě a jakýmikoli prostředky |
Předmluva
Text dokumentu 57/777/FDIS, budoucího 1. vydání IEC 61970-1, 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-1 dne 2005-12-01.
Byla stanovena tato data:
- nejzazší datum zavedení EN na národní úrovni
vydáním identické národní normy nebo vydáním
oznámení o schválení EN k přímému používání
jako normy národní (dop) 2006-12-01
- nejzazší datum zrušení národních norem,
které jsou s EN v rozporu (dow) 2008-12-01
Přílohu ZA doplnil CENELEC.
Oznámení o schválení
Text mezinárodní normy IEC 61970-1:2005 byl schválen CENELEC jako evropská norma bez jakýchkoliv modifikací.
Obsah
Strana
Úvod................................................................................................................................................................................................... 9
1 Rozsah použití....................................................................................................................................................................... 10
2 Citované normativní dokumenty......................................................................................................................................... 10
3 Termíny a definice................................................................................................................................................................ 10
4 Integrace systému................................................................................................................................................................ 10
4.1 Scénář integrace................................................................................................................................................................... 10
4.2 Hlediska integrace............................................................................................................................................................... 11
4.3 Rozhraní založená na složkách.......................................................................................................................................... 12
4.4 Vazba na soubor norem IEC 61968.................................................................................................................................. 14
5 Referenční model EMS-API................................................................................................................................................ 14
5.1 Všeobecně............................................................................................................................................................................. 14
5.2 Prostředí řídicího centra...................................................................................................................................................... 15
5.3 Aplikační kontext.................................................................................................................................................................... 15
5.4 Aplikace.................................................................................................................................................................................. 16
5.5 Složka...................................................................................................................................................................................... 16
5.6 Tradiční (legacy) aplikace a wrappery (začleňovací programy)................................................................................... 16
5.7 Model složky........................................................................................................................................................................... 17
5.8 Sestava složky....................................................................................................................................................................... 17
5.9 Adaptér složky........................................................................................................................................................................ 17
5.10 Systém realizace složek...................................................................................................................................................... 18
5.11 Aplikační programové prostředky...................................................................................................................................... 18
5.12 Komunikační profily.............................................................................................................................................................. 19
5.13 Příklady referenčního modelu............................................................................................................................................ 19
6 EMS-API normy...................................................................................................................................................................... 20
6.1 Všeobecně............................................................................................................................................................................. 20
6.2 CIM (IEC 61970-3XX)........................................................................................................................................................... 20
6.3 CIS (IEC 61970-4XX)............................................................................................................................................................ 22
6.4 Mapování CIS techniky (IEC 61970-5XX).......................................................................................................................... 23
7 Obecná předpokládaná funkčnost infrastruktury............................................................................................................ 23
7.1 Všeobecně............................................................................................................................................................................. 23
7.2 Sestava Složek...................................................................................................................................................................... 24
7.3 Aplikační programové prostředky...................................................................................................................................... 25
7.4 Služby Komunikačního Profilu............................................................................................................................................ 25
7.5 Služby specifické pro společnost...................................................................................................................................... 25
Příloha A (informativní) Modely složek....................................................................................................................................... 26
Příloha B (informativní) Typické aplikace a funkce.................................................................................................................. 29
Příloha C (informativní) Problematika normalizovaných modelů složek u společnosti................................................... 34
Příloha D (informativní) Příklady systémů realizace složek a produktů aplikačního programového vybavení............. 35
Příloha ZA (normativní) Normativní odkazy na mezinárodní publikace a na jim příslušející evropské publikace...... 37
Bibliografie...................................................................................................................................................................................... 36
Strana
Obrázek 1 - Referenční model EMS-API.................................................................................................................................... 15
Obrázek 2 - EMS používající normalizované rozhraní složek EMS-API................................................................................. 19
Tabulka 1 - Výhody rozhraní založených na složkách.............................................................................................................. 14
Tabulka 2 - Příklady EMS aplikačních kontextů........................................................................................................................ 16
Tabulka B.1 - Typické aplikace a funkce.................................................................................................................................... 29
Úvod
Tato norma je Částí souboru IEC 61970 definujícího rozhraní aplikačního programu (API) pro systémy řízení elektrické energie (EMS). Tato norma vychází z velkého rozsahu prací na výzkumném projektu (RP-3654-1) API Řídicího Centra (CCAPI) EPRI. Základní cíle projektu EPRI CCAPI jsou:
– snížit náklady a čas nezbytné na doplnění nových aplikací do EMS nebo dalších systémů2);
– chránit investice v existujících aplikacích, které pracují efektivně;
– zdokonalit schopnost výměny informací mezi nesourodými systémy jak uvnitř prostředí řídicího centra, tak vně tohoto prostředí.
Technický přístup je poskytnout ucelený systém pro propojování existujících aplikací/systémů, který je
– založen na obecné architektuře a informačním modelu;
– nezávislý na vlastní technologii.
Základním úkolem souboru norem IEC 61970 je vypracovat soubor směrnic a norem umožňující 1) integraci aplikací vyvinutých různými dodavateli v prostředí řídicího centra3) a 2) výměnu informací se systémy vně prostředí řídicího centra. Náplň těchto technických podmínek zahrnuje další přenosové systémy a rovněž distribuční a výrobní systémy vně řídicího centra, které si potřebují vyměňovat provozní data v reálném čase s tímto řídicím centrem. Dalším souvisícím cílem těchto norem tudíž je umožnit integraci existujících tradičních systémů a rovněž nových systémů sestavených tak, aby vyhověly těmto normám v daných oblastech aplikace.
Kompletní soubor norem obsahuje následující Části:
Část 1: Směrnice a obecné požadavky
Část 2: Výklad zvláštních výrazů
Část 3XX: Obecný informační model (CIM)
Část 4XX: Specifikace rozhraní složek (CIS)
Část 5XX: Mapování CIS technologií
IEC 61970-1 poskytuje soubor směrnic a obecných možností infrastruktury nezbytných pro použití norem pro rozhraní EMS-API. Popisuje referenční model, který poskytuje základ pro použití ostatních Částí norem pro EMS-API. Tento referenční model vychází z architektury složek, která určuje směrování zájmu těchto norem na rozhraní složek pro výměnu informací mezi aplikacemi v prostředí řídicího centra. Model lze rovněž použít pro obdobné výměny informací mezi aplikacemi řídicího centra a systémy vně prostředí tohoto řídicího centra, například jinými řídicími centry, obsluhou nezávislých systémů (ISO), obsluhou regionálních přenosů (RTO) a systémy pro řízení distribuce elektrické energie (DMS - Distribution Management System).
IEC 61970-1 rovněž obsahuje obecné možnosti integrační infrastruktury, která ač není součástí této normy je uvažována pro poskytování některých nezbytných služeb při zajišťování norem rozhraní EMS-API.
_______________
2) V ideálním případě má být aplikace instalována do systému s minimální námahou a bez modifikace zdrojového kódu, tj. cílové softwarové sady jsou instalovány na stolním počítači. Cílem projektu EMS-API je alespoň se přiblížit tomuto ideálu snížením opakovaných důležitých prací aktuálně nezbytných pro instalování aplikací se třemi účastníky v EMS.
3) Prostředí řídicího centra zahrnuje tradiční řízení přenosů ve společnosti a rovněž nověji obsluhu nezávislých systémů (ISO – Independent System Operator) a obsluhu regionálních přenosů (RTO – Regional Transmission Operator), které nejsou členy žádné jiné společnosti.
1 Rozsah použití
Tato Část souboru IEC 61970 poskytuje soubor směrnic a obecných možností infrastruktury nezbytných pro použití norem pro rozhraní EMS-API. Tato Část souboru IEC 61970 popisuje typické scénáře integrace u nichž jsou tyto normy používány a typy integrovaných aplikací. Pro poskytnutí základu pro používání ostatních Částí těchto EMS-API norem je definován referenční model. Tento referenční model vychází z architektury složek, která určuje směrování zájmu těchto norem na rozhraní složek pro výměnu informací mezi aplikacemi v prostředí řídicího centra. I když je primárním cílem EMS-API zajistit integraci aplikací v řídicím centru, lze referenční model rovněž použít pro výměny informací mezi aplikacemi řídicího centra a systémy vně prostředí tohoto řídicího centra, například jinými řídicími centry, ISO, RTO a distribučními systémy. Tato norma popisuje úlohu ostatních Částí normy, které obsahují obecný informační model (CIM) v souboru IEC 61970-3XX, specifikace rozhraní složek (CIS) v souboru IEC 61970-4XX a mapování technologií v souboru IEC 61970-5XX,
Tato Část souboru IEC 61970 rovněž zahrnuje obecné možnosti, které potřebuje mít integrační infrastruktura aby usnadnila výměnu informací pomocí rozhraní složek určených CIS. Ačkoliv vlastní integrační infrastruktura není součástí této normy, je uvažována pro poskytování některých nezbytných služeb při zajišťování norem rozhraní EMS-API. Tyto služby jsou vyjmenovány v kapitole 6.
Tato Část souboru IEC 61970 neurčuje jednotlivé realizace nebo produkty, ani neomezuje zobrazování informací při aplikaci počítačového systému. Tato norma definuje navenek viditelná rozhraní, včetně sémantiky a syntaxe, nezbytná pro zajištění funkční spolupráce produktů dodaných různými dodavateli.
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-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 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))
3 Termíny a definice
Pro účely tohoto dokumentu platí termíny a definice uvedené v IEC 61970-2.
4 Integrace systému
Systémy řízení elektrické energie jsou sestaveny z různých softwarových podsystémů (SCADA, řízení výroby, prognóza zatížení, apod.). Směrnice vytvořené pro tuto oblast (nebo její části) platí pro řadu různých scénářů integrace. Tato činnost zjišťuje, zda existující systémy s jejich specifickými rozhraními budou potřebovat umožnit použití rozhraní definovaných při této činnosti. Předpokládají se dále uvedené různé typy situací při integraci. Pokud to jsou typické scénáře, pak jsou pouze podsouborem možných příkladů.
a) Integrování aplikací vyvinutých různými dodavateli do jednoho homogenního systému:
V tomto scénáři jsou nezávisle vyvinuté aplikační složky (například optimalizace toku výkonu (OPF - Optimal Power Flow)) integrovány do systému (který obsahuje podpůrnou infrastrukturu). To umožňuje integrátorovi systému snadněji integrovat jednotlivé složky do libovolného systému, ať jde o existující systém nebo o nově vyvíjený systém.
b) Přímá (on-line) výměna dat mezi samostatnými systémy:
Řídicí centrum potřebuje komunikovat s dalšími, samostatnými systémy v rámci společnosti a mezi závody. Pro výměnu informací jsou potřebná volně sdružená schémata integrace. Příklady jsou výměny informací s DMS, účetními systémy společnosti nebo jiným EMS. Do této kategorie obecně náleží scénáře integrace závodů.
c) Integrování samostatných systémů sdílejících některá technická data:
Toto odpovídá situaci, kdy aplikační sestavy od různých dodavatelů používají částečně se překrývající technická modelová data (například impedance úseku vedení).
d) Výměna utříděných dat mezi stejnými aplikacemi různých systémů:
Omezenou integraci lze dosáhnout použitím technik přenosu souborů. Pro tento typ výměny export/import se použije dohoda o formátu. Příkladem tohoto scénáře je použití protokolu pro přenos souborů (FTP - File Transport Protocol) a souboru (nebo dokumentu) s formátem vycházejícím z rozšiřitelného vyššího jazyka (XML - eXtensible Markup Language) pro výměnu modelů elektrizační soustavy.
e) Vývoj nové aplikace v homogenním systému:
Toto odpovídá situaci, kdy dodavatelé nebo společnosti vyvíjející nové aplikace používají tyto normy na aplikační rozhraní pro integraci těchto aplikací do jejich existujících systémů (jako protiklad integrace u jiných systémů).
4.2 Hlediska integrace
4.2.1 Všeobecně
Sféra integrace zajišťované pomocí těchto norem spočívá ve dvou volně definovaných kategoriích:
a) Integrace softwarových složek pro realizaci EMS nebo obdobného systému.
b) Integrace nezávislých systémů.
Pro správnou interakci potřebují jak softwarové složky tak systémy obecný informační model (CIM) zajišťující obecný logický význam (tj. sémantiku) vyměňovaných nebo získávaných informací. Například pro výměnu informací o impedanci transformátoru je nezbytná klasifikace části vybavení jakožto transformátoru společně s názvem atributu pro hodnotu impedance. Pomocí těchto informací lze určit konkrétní případ transformátoru včetně jeho impedance. Sémantický název těchto skutečných obecných objektů (společně s jejich atributy, popisy a vzájemnými vazbami na další skutečné objekty) poskytuje CIM (viz 6.2).
Avšak z jiného pohledu, tak jak jsou tyto dvě kategorie integrace uváděny v následujících kapitolách, mají poněkud odlišné požadavky. Záměrem souboru norem EMS-API je určit oboje, a oboje je znázorněno jako existující rozhraní složek.
4.2.2 Integrace softwarových složek do systému
4.2.2.1 Všeobecně
Pro integraci nezávisle vyvinutých softwarových složek do systému je třeba určit některé problémy.
a) Interakce softwarových složek:
Aby systém správně fungoval, potřebují softwarové složky vzájemně spolupracovat. Tato interakce může mít formu přístupu k charakteristikám, vyvolání metody a zpracování události. Pro zajištění integrace softwarových složek se musí určit společná rozhraní obsahující charakteristiky, metody a události a musí se specifikovat dohoda pro jejich používání. Pokud v systému existuje obdobný scénář interakce, zjednoduší specifikace shodných vzorů rozhraní integraci a udržování systému.
b) Společná technická data modelu pro iniciaci:
Fyzická elektrizační soustava a příslušné informace jsou simulovány pomocí technických dat uvažovaných v CIM. Softwarové složky sdílejí aspekty těchto technických dat při provádění svých funkcí. Po spuštění softwarové složky potřebuje být tato složka iniciována shodným přesným modelem skutečné soustavy, kterou simuluje. Obecné rozhraní pro přístup ke společným sdíleným datům poskytuje softwarovým složkám odpovídající mechanizmus pro iniciaci jejich vnitřních modelů. Jakmile jsou iniciovány, lze interakční mechanizmy softwarových složek použít pro udržování jejich technických modelů včetně data.
c) Sdružování pro rozmístění:
Softwarové složky potřebují být realizovány specifickým způsobem pro sdružování a předání pro integraci systému. Dnes existuje v softwarovém průmyslu několik hlavních technologických struktur, každá má svůj vlastní formát pro sdružování. Specifikování norem má pomoci prosadit pružnost při realizaci možností usnadňujících integraci nezávisle vyvinutého software. Aby se toho dosáhlo, mají se abstraktně specifikovat interakce softwarových složek, kterých je schopna konkrétní technologie, a jazykové specializace.
Pro zajištění tohoto typu scénáře integrace je třeba normalizovat charakteristiky, metody a události použité u rozhraní složek a rovněž obsah dat pro výměnu informací.
4.2.2.2 Kategorie aplikací
Náplň norem EMS-API zahrnuje všechny aplikace, které se obvykle vyskytují v prostředí řídicího centra a rovněž rozhraní s vnějšími systémy potřebnými pro zajištění řízení v reálném čase. Jelikož však účelem normy EMS-API je definovat spíše normy pro rozhraní než definovat normalizované aplikace, lze náplň projektu nejlépe vyložit uvážením seznamu kategorií aplikací zajišťovaných normami EMS-API. Skutečné sdružování rozhraní složek specifikovaných v CIS do aplikací je ponecháno na dodavatelích aplikací; každý pokus definovat seznam jednotlivých aplikací pomocí názvu tudíž zbytečně omezí dodavatele.
Seznam kategorií aplikací a typické aplikace zajišťované touto normou jsou uvedeny v tabulce B.1. Dále je uveden obsah tohoto seznamu:
· dispečerské řízení a sběr dat (SCADA);
· zpracování výstrah;
· zpracování topologie;
· síťové aplikace;
· řízení zatížení;
· řízení výroby;
· prognóza zatížení;
· plánování přenosů elektrické energie;
· účetnictví;
· plánování údržby;
· archivace historických informací;
· řízení dat;
· generické rozhraní uživatele;
· dynamická simulace;
· simulátor pro výcvik dispečerů;
· vnější systémy (např. DMS, počasí, velkoobchod s elektrickou energií, apod.).
4.2.3 Integrace systémů
U integrace heterogenních systémů, kde existuje pravděpodobnost, že si nebudou podobné z hlediska provozního prostředí ani řízení v něm, je kladen důraz spíše na zajištění volně spojovaných asynchronních výměn „dokumentu“. Z tohoto hlediska může být „dokument“ myšlen jako velká bohatá datová struktura, například jako XML dokument. Výměna dokumentů znamená, že vyměňovaná data jsou komplexní, strukturovaná a samostatně popisná. Výměna pravděpodobněji zahrnuje přenosy jednotlivých konečných informací, kdy veškeré informace týkající se obsluhy informací a/nebo činnosti, které jsou nezbytné pro přenos, jsou spíše samostatné, než vícestupňové transakce kde obsluha přenosu informací může být závislá na předchozích přenosech informací nebo událostech.
4.3 Rozhraní založená na složkách
Jedním z cílů norem EMS-API je podpořit nezávislý vývoj opakovaně použitelných softwarových složek a umožnit jejich integraci při budování systémů řídicího centra pomocí vypracování norem pro rozhraní složek. Softwarový průmysl, včetně hlavních prodejců systémů pro řízení elektrické energie (EMS) a dodavatelů aplikačního software pro EMS, prošel vývojem od základních koncepcí technických návrhů software, návrhu modulárního software shora dolů, objektově orientovaných přístupů, po nejnovější zdokonalení používající architektury založené na složkách. Nejlépe tento trend dokládají modely složek používané
Common Object Request Broker Architecture (CORBA®)4), Sun®5)'s Enterprise Java Beans® (EJB®) a Microsoft®6)'s Distributed Common Object Modeling (DCOM). (Popis těchto tří modelů složek viz příloha A).
Tyto přístupy založené na složkách rovněž usnadňují integraci software a kompletních systémů z různých zdrojů. U tohoto typu integrace vše se vším (any to any - A2A) poskytují XML webové služby další model integrace založený na internetu. XML webové služby umožňují aplikacím komunikovat a sdílet data po internetu s použitím typu výměny informací jednodušeji označeného jako „výměna dokumentu“, bez ohledu na operační systém nebo programovací jazyk. Tyto služby poskytují jiný příklad prostředí pro provádění složek příslušející běžněji výměnám informací pro elektronické obchodování (B2B: Business-to-Business). (Popis XML webových služeb viz příloha A).
Efektem u EMS-API je přenést pozornost spíše na vypracovávání norem pro rozhraní softwarových složek pro výměnu a získávání společných informací, než na normalizování rámcových služeb pro integraci, které poskytují tyto možnosti. Předpokládá se, že aplikace dodržující tyto normy lze pak samostatně dodávat a opakovaně používat ve více systémech. I když v reálném systému mohou být potřebné další služby dané infrastruktury, například služby adresáře a zabezpečení, tyto nejsou cílem této normy. Prakticky mohou být spíše považovány za oblast integrátora systému nebo dodavatele systému (tj. za základní část EMS systému nikoliv za opakovaně použitelnou složku „na klíč“).
Cílem není vypracovat normalizovaná rozhraní pro aplikační programové prostředky. Prakticky je cíl právě opačný - být nezávislý na jakémkoliv konkrétním souboru služeb aplikačních programových prostředků. To umožňuje integrátorům zvolit pro každý systém správný typ a rozsah infrastruktury. Umožňuje to navrhnout u dané služby vývoj a inovaci a rovněž to zjednodušuje vývoj složek.
Znamená to rovněž, že programátor se nemá přímo zabývat těmito službami. Integrátor systému tvoří „lepidlo“ pro zavádění těchto složek do prostředí systému. To poskytuje integrátorovi větší volnost při konfigurování složek a pro volbu služeb nejvhodnějších pro potřeby realizovaného systému (tj. charakteristiky, pohotovost, apod.).
Následující dva příklady dokládají tuto nezávislost složek:
– CORBA složky konkrétně nevyžadují použití CORBA Notifikace (ani žádnou konkrétní službu) jako svého systému událostí.
– COM+ složky jsou zapsány přesně stejným způsobem, jakým jsou umístěny v prostředí s koordinátorem rozložených transakcí (DTC - Distributed Transaction Coordinator) a/nebo frontou zpráv Microsoftu (MSMQ - Microsoft Message Queue) nebo bez nich.
Tabulka 1 uvádí přehled výhod tohoto přístupu založeného na složkách pro normy rozhraní.
4) CORBA je obchodní název produktu dodávaného OMG. Tato informace je poskytována pro potřeby uživatelům této mezinárodní normy a netvoří dodatek IEC pro jmenovaný produkt. Lze použít rovnocenné produkty, pokud u nich lze prokázat, že vedou ke stejným výsledkům.
5) Sun je zkratka pro Sun Microsystems, společnost založenou v USA. Tato informace je poskytována pro potřeby uživatelům této mezinárodní normy a netvoří dodatek IEC pro jmenovanou společnost.
6) Microsoft je zkratka pro Microsoft Corporation, společnost založenou v USA. Tato informace je poskytována pro potřeby uživatelům této mezinárodní normy a netvoří dodatek IEC pro jmenovanou společnost.
Tabulka 1 - Výhody rozhraní založených na složkách
|
Explicitně určuje cíl navrhování software EMS-API „na klíč“ |
|
Nestanovuje celkový návrh systému ani výběr a návrh služeb |
|
Sleduje celkové zaměření softwarového průmyslu pro umožnění použití základních prostředků pro vývoj složek a konfigurování systémů |
|
Umožňuje u EMS-API projektu řešení řady problémů software „na klíč“ na základě nových objevů a vynálezů |
|
Poskytuje kompletnější řešení zahrnující důležité oblasti, například zhušťování (co se vejde na CD disk se složkami), dokumentace, vytváření verzí, atd. |
|
Nevyžaduje navrhování a/nebo určování služeb aplikačních programových prostředků, služeb pro konkrétní událost, pojmenování a transakci, ale spíše umožňuje pro zajištění těchto služeb použít komerčně dostupné produkty |
|
Poskytuje kanonický tvar normám specifickým pro danou společnost vypracovaným v rámci projektu, který umožňuje vývojovým pracovníkům přímý strojový převod definic rozhraní do jimi preferovaného jazyka pro rozhraní: Skupina pro řízení objektů (OMG - Object Management Group)/Jazyk pro definování rozhraní (IDL - Interface Definition Language) Mezinárodní organizace pro normalizaci (ISO - International Standards Organization), syntaxe rozhraní Java®7) nebo Microsoft IDL |
|
Umožňuje zaměřit se v projektu EMS-API na navrhování rozhraní a událostí pro aplikace společnosti, aniž by se muselo vyčkat na vyřešení všech problémů. To umožňuje prodejcům rychleji vstupovat na trh s rozhraními vyhovujícími EMS-API v jejich produktech pro danou aplikaci |
4.4 Vazba na soubor norem IEC 61968
Soubor norem IEC 61968 se zabývá systémovými rozhraními pro systémy řízení dodávky elektrické energie. Zde existuje značná podobnost mezi těmito normami a normami obsaženými v souboru norem IEC 61970, nejen proto, že se jejich náplň poněkud překrývá, ale proto, že soubor norem IEC 61968 rovněž vychází z CIM. Soubor norem IEC 61968 staví, kde je to možné, na Základě CIM definovaném v IEC 61970-301 pomocí jeho rozšiřování při zahrnutí dalších specializací existujících tříd, ale rovněž doplňování zcela nových souborů tříd do objektů modelu vyskytujících se v doméně problematiky distribuce elektrické energie. Takže pro pochopení celého rozsahu CIM je nezbytné seznámit se jak se souborem norem IEC 61970 tak IEC 61968, které se zabývají CIM.
Soubor norem IEC 61968 se rovněž zabývá definováním normalizovaných výměn informací mezi obchodními funkcemi pro distribuci elektrické energie, obdobně jako normy IEC 61970-4XX, ale nesnaží se definovat rozhraní aplikačního programu (tj. služby realizované pomocí složek). Soubor norem IEC 61968 však předpokládá, že normalizované zprávy tam definované lze přenést přes API definované v tomto souboru norem IEC 61970.
5 Referenční model EMS-API
5.1 Všeobecně
Referenční model EMS-API je abstraktní architektura, která provádí vizualizaci určeného okruhu problémů, poskytuje jazyk pro popisování a projednávání výsledků, definuje terminologii a poskytuje další obdobné prostředky pro všestranné pochopení problému řešeného v normách EMS-API.
Referenční model není návrh, ani není určen pro popis vrstev software, i když metodě vytváření vrstev je obtížné se vyhnout a je zahrnuta. Základní funkcí je jasně ukázat, které části daného okruhu problémů jsou předmětem norem EMS-API a naopak, které leží mimo oblast projektu EMS-API a proč. Záměrem je rovněž ukázat, jak různé části této normy váží navzájem.
Obrázek 1 je schéma referenčního modelu, kde stínované oblasti představují ty části referenčního modelu, které jsou předmětem této normy. Nestínované oblasti představují části systému, které jsou podstatné při vytváření struktury pro opakované použití aplikačních složek. Každá část tohoto modelu je následně v tomto dokumentu probírána.
_______________
7) Java je obchodní název produktu dodávaného Sun Microsystems. Tato informace je poskytována pro potřeby uživatelům této mezinárodní normy a netvoří dodatek IEC pro jmenovaný produkt. Lze použít rovnocenné produkty, pokud u nich lze prokázat, že vedou ke stejným výsledkům.
Obrázek 1 - Referenční model EMS-API
5.2 Prostředí řídicího centra
Referenční model je speciálně určen pro použití pro prostředí řídicích center, která obvykle zahrnují počítačové sítě připojené na místní sítě (LAN - Local Area Network) a někdy na dálkové sítě (WAN - Wide Area Network). Řídicí centrum může obsahovat velký počet systémů pro zajišťování funkcí společnosti, včetně EMS, DMS a dalších systémů potřebných pro ISO a RTO obchodní činnosti. Zajišťuje řadu různých skupin uživatelů a funkcí organizace, včetně provozní obsluhy, dozoru, výcviku obsluhy, plánování provozu, udržování databáze a vývoje software. V EMS se mnoho aplikací používá v řadě takovýchto kontextů a je důležité, aby daná aplikace mohla být snadno konfigurována (zejména automaticky) pro použití ve více kontextech. Toho je dosaženo spíše použitím charakteristik, které se váží ke každému rozhraní složek, než změnami vnitřního kódu složky.
5.3 Aplikační kontext
Aplikační kontext zahrnuje skupinu aplikací pracujících společně jako organizační jednotka pro splnění určitého vysokého cíle. 8) Aplikační kontext definuje časový rámec a prostředí pro realizaci. Tabulka 2 obsahuje příklady kontextů pro EMS aplikace:
8) Je třeba poznamenat, že výraz kontext se používá odlišně při probírání modelů složek například u EJB a u CORBA, kdy se kontext používá ve spojení se sestavou složek provádějící realizace složek pomocí přístupu ke službám realizovaným touto sestavou, které jsou právě v činnosti. Tyto služby zahrnují transakce, zabezpečení, události a trvalost.
Tabulka 2 - Příklady EMS aplikačních kontextů
|
Reálný čas |
Přímé (on-line) řízení elektrizační soustavy |
|
Studie provozu (příprava provozu) |
Vyhotovení síťových aplikací pro studii a/nebo analýzu provozních postupů (krátkodobý termín) |
|
Rozšířená plánovací studie (dlouhodobá příprava provozu) |
Vyhotovení síťových a/nebo simulačních studií pro vyhodnocení možností (výhledový/dlouhodobý termín) |
|
Výcvik |
Vytvoření prostředí pro výcvik obsluhy, které vyžaduje simulační a analytické aplikace |
I když to není vyloženě znázorněno v referenčním modelu je samozřejmé, že může současně existovat několik kontextů, z nichž každý obsahuje případně tytéž aplikace v různých datových výměnách. Může tudíž být více současně existujících případů konkrétního kontextu. Mohou například existovat dvě či více studií probíhající paralelně u dvou různých pracovníků obsluhy v kontextu Studie provozu, zatímco se současně stejné aplikace provádějí v kontextu Reálného času.
5.4 Aplikace
Aplikace se skládá z jedné či více složek, které provádějí určitou obchodní funkci v dané doméně. Toto navrhuje a zaznamenává specialista pro tuto doménu. Členitost složek tvořících danou aplikaci záleží na volbě projektanta. Tvůrci aplikace mohou při sestavování aplikace kombinovat složky od různých vývojových projektantů nebo od různých prodejců.
Vývojový projektant dané aplikace může být schopen plně zprovoznit určitou složku bez vyžádání přístupu k jejímu zdrojovému kódu. Složky lze vytvořit na zakázku, aby vyhovovaly konkrétním požadavkům určité aplikace, pomocí souboru hodnot externích charakteristik. Například složka „tlačítko“ má charakteristiku, kterou určuje název, jenž se může nacházet na tomto tlačítku. Samozřejmě objem možné výroby na zakázku závisí na prozíravosti vývojového projektanta složek při poskytování dostatečného množství hodnot externích charakteristik. Je to takřka ekvivalent staršího pojmu u navrhování programu při tvorbě programu na zakázku pomocí stanovení příslušných hodnot konfiguračních parametrů přednostně před nutností měnit zdrojový kód.
Seznam kategorií aplikací, abstraktních názvů a prováděných funkcí viz tabulka B.1.
5.5 Složka
Složka je opakovaně použitelný softwarový stavební blok. Je to předem sestavená část se zahrnutým aplikačním kódem, kterou lze kombinovat s jinými složkami a s ručně psaným kódem pro rychlé vytvoření zakázkové aplikace.
Aby ji bylo možno kvalifikovat jako složku, musí aplikační kód poskytovat standardní rozhraní umožňující ostatním částem aplikace vyvolat její funkce a získat data v této složce a manipulovat s nimi. Model složky definuje strukturu tohoto rozhraní.
Členitost složek se mění. Složka může být velmi malá, například jednoduchý mechanizmus (například tlačítka) u grafického uživatelského rozhraní (GUI - Graphic User Interface), nebo může realizovat celou složitou aplikaci, například aplikaci estimátoru stavů. V tomto posledním případě může být aplikace navržena pracovně jako jedna složka, nebo může zahrnovat tradiční (legacy) aplikaci začleněnou pro vyhovění normám pro rozhraní složek (pojednání o tradičních aplikacích viz dále).
Složka může být umístěna na přenosné médium, například CD, a předána k použití do systému, který zajišťuje sestavy složek.
Obecně složky veřejně vykazují metody, charakteristiky a „události“ prostřednictvím integrační infrastruktury. Události jsou zvláště zajímavé, neboť umožňují integraci nezávisle vyvinutých složek. Při použití normalizovaného souboru událostí nepotřebuje Složka A znát jakékoliv další podrobnosti o rozhraní se Složkou B nebo ani zda Složka B existuje. Zásadní je, že jde o rozhraní se složkou, které je normalizované, ne o integrační infrastrukturu.
5.6 Tradiční (legacy) aplikace a wrappery (začleňovací programy)
Tradiční aplikace je zcela odlišná oproti předchozí uvedené definici aplikace. Tradiční aplikace může být jednoduchá aplikace provádějící určitou obchodní funkci, kterou daná společnost může získat nebo samostatně vyvinout před zavedením libovolného modelu složek pro účely integrace, nebo to může být celý systém, který je zdrojem/příjemcem dat potřebných/předávaných ostatními systémy, které oboje potřebují být integrovány pro usnadnění výměny informací.
Příklady zahrnují:
– aplikaci propojování jednotek realizovanou ve FORTRANU bez ohledu na rozhraní složek;
– kompletní přenos EMS bez otevřených zveřejněných rozhraní, který je potřebný pro předání dat ze SCADA do distribučních systémů a naopak pro příjem aktualizací do svého modelu elektrizační soustavy ze systémů řízení vypínání.
Tradiční (legacy) wrapper se používá pro začlenění tradiční aplikace nebo systému, které nevyhovují normám pro rozhraní složek. Převádí vstup/výstup tradičního programu na jedno či více rozhraní složek tak, aby se tento program mohl účastnit výměny informací v architektuře systému založené na složkách.
Účelem použití tradičního wrapperu pak je umožnit tradiční aplikaci nebo systému pracovat jako složka „na klíč“, která je schopná výměny informací s ostatními složkami pomocí společné infrastruktury nebo struktury.
Tradiční wrapper může navrhnout a realizovat specialista pro tuto doménu, který vyvinul nebo vlastní tradiční aplikaci nebo systém (např. prodejce EMS), jenž pak dodává tento wrapper pro použití ve více instalacích systému u nichž se používá technika složek. Nebo pokud je tradiční program jedním z typů zákaznické „závodové“ aplikace bude možná integrátor systému muset sestavit wrapper a skončí tím, že se použije pouze v jednom systému.
5.7 Model složky
Model složky definuje základní architekturu složky, se stanovením struktury jejích rozhraní a mechanizmů pomocí nichž vzájemně reaguje s její sestavou a s ostatními složkami. Model složky poskytuje návod pro vytvoření a realizaci složek, které mohou společně vytvářet větší aplikaci.
Sestavovatel složky nemá mít při realizaci u žádné složky paralelní zpracování zpráv, souběžné řízení, sdílení prostředků, zabezpečení a řízení transakcí. Mimo to, jestliže byly tyto služby u každé služby realizovány, může být vytvoření správné skladby aplikace „na klíč“ velice obtížné. Model složky normalizuje a automatizuje použití těchto služeb.
Dnes v softwarovém průmyslu existují čtyři základní obecně akceptované modely složky. Tyto modely složky jsou uvedeny v příloze A. Softwarový průmysl učinil rozhodnutí, jež se promítlo do všech čtyřech těchto modelů složky, že odstranění příslušnosti složek k určité sestavě nebo infrastruktuře je hlavním krokem světového trendu, aby bylo možno složky nezávisle vyvíjet, sestavovat a rozmisťovat. Avšak vzhledem k tomu, že existují čtyři samostatné modely, mohou prodejci složek chtít pokaždé zajistit nepatrně odlišnou verzi, aby usnadnili použití všech dostupných prostředků vlastní sestavy a exekutivního systému, se základními charakteristickými výhodami, které to se sebou nese. Toto však není vyloženě nezbytné. Pokud prodejci složek omezí svůj návrh složek na zajištění jejich správné činnosti v některém z těchto čtyř modelů, mohou rozdíly upravit adaptéry složek dodané integrátorem systému, který zvolil konkrétní techniku složek použitou pro konkrétní realizaci systému. Nebo se může integrátor systému rozhodnout zkombinovat více technik složek a použít techniky přemosťování pro umožnění spolupráce různých technik (například exekutivní systém CORBA spolupracující s exekutivním systémem Microsoft DCOM).
5.8 Sestava složky
Složky se realizují v sestavě. Sestava poskytuje kontext jedné či více složkám a zajišťuje těmto složkám služby správy a řízení. U reálných systémů zajišťuje sestava zpracování nebo plynulý postup operačního systému v němž se složka realizuje. To odděluje složku od provozní základny. Pokud klient vyvolá složku serveru, sestava automaticky rozvrhne plynulý postup zpracování a iniciuje danou složku. Sestava řídí všechny prostředky za danou složku a řídí všechny interakce mezi složkou a vnějšími systémy.
Sestavy složek obvykle zajišťují dodavatelé systému jako součást systému realizace složek. Typickými službami zajišťovanými pro složky jsou pojmenování, události, transakce, zabezpečení a trvalost. Veškeré služby, které potřebuje aplikace dané společnosti v reálném čase, nemusí být zajišťovány jako součást normalizovaných služeb sestavy nabízených dodavateli komerčního software. Příloha C uvádí, jak mohou být tyto služby zajištěny u konkrétní realizace.
5.9 Adaptér složky
Činnosti a chování sestavy jsou definovány a určovány jejím modelem složek. Model složek určuje dohodu o tom, jak musí být zajištěny služby a rozhraní sestavy. V důsledku toho složky vyvinuté pro jeden typ exekutivního systému nebo prostředí obvykle nejsou přímo přenosné na žádný jiný typ exekutivního prostředí.
Aby se tedy dosáhlo opakovaného použití ve více exekutivních systémech, je nezbytný pro každý exekutivní systém adaptér složek, s výjimkou systému, pro který byla složka navržena. Jinak lze rozhraní složek definovat podle nějaké neutrální normy a potom bude adaptér složek nezbytný pro všechny sestavy pro mapování normalizovaných rozhraní na rozhraní poskytovaná danou sestavou. Toto je zhruba ekvivalent „úrovně přenositelnosti“, která je součástí Java Enterprise Platform, jež je systémem realizace složek pro EJB.
Adaptér složek je definován jako část software, umístěného mezi aplikací (nebo složkou) a sestavou složek a integrační infrastrukturou, která poskytuje základní služby pro zajištění složek (např. vydávání/odebírání, vytváření front zpráv, pojmenování, apod.). Adaptér se může, je-li to třeba, věnovat rozdílům protokolů, transformaci dat a převodu dat. Adaptér může navíc zajišťovat zabezpečení, transakce a trvalost složek (alespoň z hlediska okolí aplikace), pokud toto nezajišťuje vlastní prostředí realizace složek.
Adaptéry složek se zabývají rozdíly jak mezi a) rozhraním složky a zvoleným prostředím exekučního systému a technikou sestavy tak mezi b) rozhraním složky a rozhraními dalších složek použitých ve zbytku systému. Toto zahrnuje rozdíly v definicích událostí. K těmto rozdílům dochází protože:
– Systém je vytvořen z nezávisle vyvinutých složek, jejichž rozhraní nebyla předem koordinována (tj. nebyla normalizována, což je pravděpodobně obvyklé).
– Systém obsahuje zčásti normalizované složky, avšak nenormalizované části nejsou kompatibilní.
– Normalizované části nejsou ještě kompatibilní, protože představují různé verze normy.
V závislosti na prostředí a prostředcích zajištěných sestavou složek může adaptér složek rovněž spojit portály událostí složek s příslušnými tématy událostí a vyhledat složky se správnou závislostí, pokud nějaké jsou.
Adaptéry složek mohou rovněž realizovat služby specifické pro společnost nezbytné k tomu, aby složky fungovaly v počátečně určeném kontextu EMS, které nejsou k dispozici v samostatných systémech realizace složek.
Integrátor systému nebo dodavatel exekučního systému obvykle zajišťují adaptéry složek. Ty obvykle obsahují zapsaný kód 1) pro přizpůsobení typů událostí a typů dat a služeb předpokládaných danou složkou službám předpokládaným ostatními složkami v konkrétním realizovaném systému a 2) pro konfiguraci toků systémových informací pro danou složku. V důsledku toho integrátoři systému sestavují adaptéry na zakázku pro daný systém a pro danou složku.
5.10 Systém realizace složek
Složky serveru se realizují v prostředí zajišťovaném danou aplikací nebo systémem realizace složek. Výraz systém realizace složek zahrnuje celý referenční model od úrovně sestavy směrem dolů, včetně sestavy složek, služeb aplikačních programových prostředků a komunikačních profilů. Obsahuje rovněž neuvedené další běžné služby zajištěné základnou, včetně operačního systému, permanentní paměti, apod. Označují se rovněž jako systémy sestav, protože sestava poskytuje primární rozhraní pro normy rozhraní, které jsou náplní této normy.
Systémy sestav obsahují existující produkty aplikačních programových prostředků, které dodržují dohodu pro sestavu a zásady modelu složky využívaných systémem. Kvalifikují se všechny struktury exekučního systému, které dodrží dohodu u sestavy pro zajišťování složek. Například dodavatel EMS může navrhnout exekuční systém EMS aplikace pro zajištění sestav, čímž připouští používání složek vyvinutých interně nebo na zakázku jiným dodavatelem složek. Další komerční příklady jsou uvedeny v příloze D.
Systémy realizace složek obvykle zajišťují dodavatelé systému.
5.11 Aplikační programové prostředky
Výraz aplikační programové prostředky se používá k popisu jiné skupiny softwarových produktů, které slouží jako integrační, převáděcí a/nebo překladová úroveň. Aplikační programové prostředky poskytují generická rozhraní pro události, zpracování zpráv, přístup k datům, transakce, apod.
Prodejci aplikačních programových prostředků poskytují produkty pro zajištění určité kombinace těchto generických služeb pomocí jejich vlastních autorizovaných rozhraní. Obecně to není cílem příslušného průmyslu, i když často poskytuje převodníky pro širší použití aplikací, například PeopleSoft®9), SAP, apod. Ty mohou nebo nemusí zajišťovat všechny služby potřebné v prostředí řízení společnosti v reálném čase.
_______________
9) PeopleSoft je obchodní název produktu dodávaného Oracle. Tato informace je poskytována pro potřeby uživatelům této mezinárodní normy a netvoří dodatek IEC pro jmenovaný produkt. Lze použít rovnocenné produkty, pokud u nich lze prokázat, že vedou ke stejným výsledkům.
Každá společnost může zvolit jiného prodejce aplikačních programových prostředků v důsledku rozhodnutí o informační technice (IT) pro celý závod, což určí celopodnikovou normu, kterou nelze snadno změnit. Normy rozhraní složek EMS-API musí být tudíž napsány tak, aby mohly být umístěny v různých produktech aplikačních programových prostředků.
Produkty aplikačních programových prostředků se trvale vyvíjejí. Normy rozhraní složek EMS-API nemají bránit použití nejlepších dostupných produktů při realizaci snahy o integraci. Příloha D poskytuje některé příklady komerčních produktů.
5.12 Komunikační profily
Komunikační profily určují konkrétní protokoly a služby protokolu, které se použijí pro výměnu informací mezi samostatnými základnami serveru v systému realizace složek. Některé produkty aplikačních programových prostředků pracují na základě normalizovaných profilů, například CORBA a EJB, které používají internetový vnitřní-ORB protokol (IIOP - Internet Inter-ORB Protocol) pomocí protokolu řízení přenosů/internetového protokolu (TCP/IP - Transport Control Protocol/Internet Protocol) pro provoz buď po internetu nebo po soukromých intranetech. Jiné používají autorizované protokoly a služby.
Smyslem technických podmínek EMS-API rozhraní je být nezávislé na všech konkrétních komunikačních profilech.
5.13 Příklady referenčního modelu
Pro objasnění použití pojmů referenční model u skutečných systémů jsou uvedeny dva příklady.
5.13.1 Příklad sestavení EMS pomocí norem EMS-API
Obrázek 2 znázorňuje EMS systém, který vyhovuje referenčnímu modelu EMS-API. Jednotlivé aplikační složky jsou vzájemně propojeny pomocí systému realizace složek a adaptérů složek, které poskytují služby infrastruktury jež potřebují složky pro zjišťování ostatních složek a vzájemnou komunikaci s nimi a s paměťmi společných dat při různých kontextech EMS. V tomto příkladu se uvažuje systém realizace složek CORBA, který přímo podporuje CORBA složky. Aplikace, které vyhovují modelu složek CORBA pak nepotřebují adaptéry složek. Provozní SCADA data v reálném čase se získávají z 1) tradičního SCADA systému, který je začleněn pomocí tradičního wrapperu, aby se zajistila nezbytná rozhraní složek a 2) datového serveru s protokolem pro komunikaci mezi řídicími centry (ICCP - Inter-Control Center Communication Protocol) připojeného na ostatní řídicí centra nebo rozvodny. Oba zdroje SCADA dat zveřejňují aktualizace pomocí identických rozhraní složek jakmile jsou k dispozici, a aplikace, které potřebují aktualizace v reálném čase, požadují jejich přijetí nezávisle na tom, jaký zdroj dodává data. Je rovněž znázorněn DMS systém vně řídicího centra, který může přijímat stejné aktualizace SCADA dat jakmile se objeví, rovněž pomocí jejich vyžádání. Rovněž je zajištěna řada dalších interakcí aplikací.
Obrázek 2 - EMS používající normalizované rozhraní složek EMS-API
5.13.2 Scénář s použitím tradičních wrapperů i adaptérů složek
Jiným příkladem je prodejce SCADA mající existující systém (například typickou aplikaci sběru a řízení dat SCADA), který potřebuje být zkompletován jako CORBA složka tak, aby mohl být prodán jako aplikace „na klíč“ propojená na systém sestav CORBA. Existující SCADA aplikace již má autorizované API, které existuje roky, je ověřené a řádně vyzkoušené a použité v různých instalacích. Existuje oprávněnost malých nákladů při přepracování libovolné části této aplikace pouze na CORBA složku.
Logický přístup pak je předřadit tuto „tradiční aplikaci“ wrapperem, který zajišťuje nezbytná rozhraní složek. Wrapper poskytuje tuto aplikaci (nebo spíše menší část této aplikace) jako normalizovanou CORBA složku. Tento wrapper bude pravděpodobně odpovědný za mapování existujícího autorizovaného API na rozhraní určené pro složku. Toto mapování může být poměrně komplikované.
Zákazník, který má objednánu SCADA aplikaci převedenou na složky prodejcem SCADA, nyní očekává její integraci do svého závodu. Co je dnes takřka jisté je to, že většina těchto aplikací integrovaných ve SCADA aplikaci nebude vyhovovat jednomu normalizovanému modelu složky, nebo když na to přijde, žádnému normalizovanému modelu složky.
Zákazník musí pro pomoc s úkolem celkové integrace zvolit produkt integračních aplikačních programových prostředků. Jednou ze základních příčin, proč společnost kupuje produkt integračních aplikačních programových prostředků je, že to usnadňuje přizpůsobení různých aplikačních rozhraní, složky nebo dalšího prvku obecným službám a modelu výměny informací poskytovaným produktem integračních aplikačních programových prostředků. Produkt integračních aplikačních programových prostředků závodu nemusí přímo zajišťovat model složky použitý SCADA složkou, nebo nemusí zajišťovat model složky vůbec. Prodejce aplikačních programových prostředků nebo integrátor systému tudíž zavede adaptér složek.
Tento scénář znázorňuje rozdíl mezi tradičním wrapperem a adaptérem složek v referenčním modelu. Zde je za wrapper odpovědný prodejce SCADA a za adaptér prodejce aplikačních programových prostředků (společnost by pochopitelně měla zvolit použití autorizovaného SCADA rozhraní a wrapper by ani nemusel být zaveden). V případě, že wrapper poskytuje SCADA aplikaci jako normalizovanou složku, může být adaptér prodejce aplikačních programových prostředků normalizovaný. Prakticky dodavatelé integračních aplikačních programových prostředků nabízejí normalizované adaptéry, obvykle pro systémy řízení relační databáze (RDBMS - Relational Data Base Management System) (např. Oracle, Structured Query Language (SQL) Server, apod.), obecné normalizované aplikace (např. SAP, Peoplesoft, apod.) a další obecné prostředky (např. MQSeries, apod.).
6 EMS-API normy
6.1 Všeobecně
Jak uvádí referenční model jsou obecný informační model (CIM) a specifikace rozhraní složek (CIS) hlavními částmi modelu, které se normalizují. Prakticky jsou částmi souboru norem IEC 61970, které připravila technická komise IEC TC 57 pod názvem EMS-API. Reálná struktura dokumentů IEC 61970 je následující:
Část 1: Směrnice a obecné požadavky
Část 2: Výklad zvláštních výrazů
Část 3XX: Obecný informační model (CIM)
Část 4XX: Specifikace rozhraní složek (CIS)
Část 5XX: Mapování CIS techniky
6.2 CIM (IEC 61970-3XX)
6.2.1 Všeobecně
Aplikační složky SCADA/EMS/DMS obecně vyžadují podrobně zpracovaný model zahrnující měření, propojení sítě, charakteristiky zařízení, apod., aby mohly fungovat. CIM poskytuje takovýto model, zajišťující tyto aplikační složky s vyčerpávajícím logickým znázorněním elektrizační soustavy. CIM je abstraktní model, který znázorňuje všechny hlavní objekty u více aplikací. Tento model obsahuje pro tyto objekty společné (veřejné) třídy a atributy a rovněž vazby mezi nimi (viz IEC 61970-301). Tento model je popsán v jednotném modelovacím jazyce (UML) a udržován jako jeden soubor modelu Rational ROSE. Hlavní části dokumentů IEC 61970-3XX jsou automaticky vytvářeny z tohoto souboru modelu pomocí Rational SODA.
CIM je částí celkové struktury EMS-API. Poskytováním normalizovaného způsobu znázorňování prostředků elektrizační soustavy jako tříd a atributů objektů, spolu s jejich vazbami, usnadňuje CIM integraci EMS aplikací nezávisle vyvinutých různými dodavateli, mezi kompletními EMS systémy vyvinutými nezávisle, nebo mezi EMS systémem a ostatními systémy vážícími se k různým aspektům řízení elektrizační soustavy, například řízení výroby nebo distribuce elektrické energie. Toho je dosaženo definováním obecného jazyka (tj. sémantiky a syntaxe) v závislosti na CIM, aby se umožnilo těmto aplikacím nebo systémům získat společná data a vyměňovat si informace nezávisle na tom, jak jsou tyto informace znázorněny vnitřně.
6.2.2 Zamýšlené použití CIM
Objekty znázorňované v CIM jsou v podstatě abstraktní a mohou být použity u rozsáhlého okruhu aplikací. Použití CIM přesahuje jeho aplikaci v SCADA/EMS/DMS. Tato norma se má chápat jako prostředek pro umožnění integrace v libovolné oblasti, kde je obecný model elektrizační soustavy nezbytný pro usnadnění funkční spolupráce a kompatibility připojení aplikací a systémů nezávisle na jakékoliv konkrétní realizaci. Konkrétní předpokládaná použití CIM zahrnují:
– Iniciaci aplikačních složek pomocí konfiguračních dat.
Běžně před tím, než lze aplikační složku zprovoznit, musí být tato iniciována informacemi o reálném stavu a událostech dané fáze konfigurace (někdy se nazývá technická údržba dat) podle tohoto modelu. Během doby životnosti aplikační složky jsou v elektrizační soustavě prováděna rozšíření vyžadující změny v modelu a tudíž konfiguračních dat.
– Opakované použití konfiguračních dat z tradičních systémů.
– Začlenění existujících konfiguračních dat z cizích systémů.
– Vytvoření databáze pro zajištění přímé (on-line) výměny dat mezi aplikačními složkami.
Data vytvořená aplikačními složkami při přímém (on-line) provozu jsou předkládána obsluze a zpřístupněna jako vstup pro jiné aplikace. Aplikační složky jsou rovněž příjemci dat z ostatních aplikačních složek. Zatímco tato přímá výměna dat je předmětem CIS norem uvedených v 6.3, obsah výměny dat závisí na CIM.
6.2.3 Kontext a čas
Definice CIM implicitně připouští u všech entit více případů objektů ve více časech.
Pro rozlišení mezi CIM entitami nacházejícími se ve stejných aplikačních složkách se předpokládá, že informace vyměňované mezi složkami obsahují kontext nebo prostředí. Toto lze realizovat jako alfanumerický řetězec, například VÝCVIK, REÁLNÝČAS, NEPŘÍMÉ (OFFLINE), STUDIE a ZÁZNAM. Samotné složky však nemají být informovány o kontextu v němž pracují.
Všechny události výměny dat mezi dvěma aplikacemi vycházejícími z CIM musí zahrnovat pojem čas. V závislosti na aplikaci může být čas buď implicitní (tj. tento čas je čas u přijímající aplikace) nebo explicitní (tj. datové prvky mají časová označení, buď jednotlivě nebo pro celé bloky).
U aplikací mohou CIM entity, například ProstředekElektrizačníSoustavy nebo HodnotaMěření, obsahovat nestandardní datum a čas počátku, datum a čas konce a okamžitý datum a čas. Různé aplikace mohou udržovat čas různými způsoby, například globální proměnná udržovaná jako atribut v jednotlivých objektech, jako sdružený objekt, apod. Toto se považuje za problém návrhu a tudíž není náplní normy.
Kromě toho budou data v operačním systému obvykle uvolňována v závislosti na čase. Objekty budou vytvářeny nebo rušeny a jejich charakteristické hodnoty se budou měnit. Z tohoto důvodu bude mít každý objekt čas vzniku a případně čas zrušení. Charakteristické hodnoty budou mít jeden či více časů, kdy byly vytvořeny nebo zrušeny. CIM toto explicitně nemodeluje s výjimkou HodnotyMěření, která má explicitní časový údaj pro čas poslední aktualizace. To, že chybí explicitní časové údaje u zbylých objektů a charakteristických hodnot nebrání použití tohoto modelu u aplikací, kde je čas zaznamenáván, například u aplikací uchovávajících data v centrální databázi. U takovýchto aplikací se doporučuje aby
– všechny objekty měly časový údaj „vzniku“ a časový údaj „zrušení“;
– všechny charakteristické hodnoty měly časový údaj „naposledy aktualizováno“;
– historie byla udržována pro všechny charakteristické časové údaje „naposledy aktualizováno“ s příslušnými hodnotami.
Hodnoty dat spolu s příslušnými časovými údaji lze získat prostřednictvím API, jak definují CIS normy IEC 61970-4XX.
6.2.4 Shoda vazeb a atributů
CIM představuje soubor entit, vazeb a atributů elektrické sítě v určitém stavu. Tento dokument neurčuje, jak má aplikace řídit shodu vazeb a atributů u objektů, které obsahuje. Například mění-li se stav spínače může být nezbytné znovu určit topologické vazby a získat nový soubor hodnot měření. Toto se může týkat více aplikací než jedné.
Aplikační rozhraní mají odpovědnost za poskytování informací o stavu shody nezbytných pro kvalifikaci výměn informací (například vyčíslení „ModelPlatný“, „TopologiePlatná“, „RozloženíZatíženíPlatné“).
U konkrétní konfigurace sítě lze rozvodné zařízení seskupit do napájecích vedení a uzly propojení mohou být seskupeny do topologických uzlů. Je součástí kontextu výměny informací definovat, zda informace označuje „POSESTAVENÍ“, „AKTUÁLNÍ“, apod. Toto platí stejně pro hodnoty měření a další jednoduché atributy jako pro topologické vazby.
Například databázová aplikace může udržovat případy v jejich stavu „POSESTAVENÍ“ a SCADA aplikace může udržovat případy v jejich „AKTUÁLNÍM“ stavu. CIM model je stejný pro obě aplikace. Případy v každé aplikaci mohou mít různé hodnoty.
6.2.5 Vazba na soubor norem IEC 61968
Jak bylo uvedeno dříve v kapitole 4.4, soubor norem IEC 61968 rovněž staví na CIM, rozšířením Základu CIM obsaženého v IEC 61970-301, kde je to možné, na základě jeho rozšiřování zahrnutím dalších specializací existujících tříd, ale rovněž doplňováním zcela nových souborů tříd do objektů modelu vyskytujících se v doméně problematiky distribuce elektrické energie. Takže pro pochopení celého rozsahu CIM je nezbytné seznámit se s CIM uvedeným jak v souboru norem IEC 61970 tak IEC 6196810).
6.3 CIS (IEC 61970-4XX)
Účelem CIS dokumentů v IEC 61970-4XX je definovat rozhraní, která musí složky použít pro usnadnění integrace s ostatními nezávisle vyvinutými složkami. I když jsou typické aplikace a funkce určeny v příloze B pro pomoc při definování typů informací, které se musí přenášet, není účelem pokusit se definovat složky samy o sobě. Dodavatelé složek mají mít volnost při seskupování různých skupin rozhraní složek do bloků složek, pokud stále zůstávají ve shodě s normami EMS-API.
CIS definuje dvě hlavní části rozhraní složek:
a) Rozhraní, která složka (nebo aplikace) má realizovat, aby byla schopna si vyměňovat informace s ostatními složkami (nebo aplikacemi) a/nebo získávat veřejně přístupná data standardním způsobem. Rozhraní složky popisují konkrétní události, metody a charakteristiky, které pro tyto účely mohou aplikace použít.
b) Obsah informací nebo zprávy, které si složka vyměňuje s ostatními složkami. Toto se někdy označuje jako model výměny informací.
IEC 61970-4XX je uspořádána do těchto dvou částí samostatných dokumentů:
a) Části 401 až 449:
Jsou vyhrazeny pro definování generických služeb zajišťovaných rozhraními složky. Tyto specifikace popisně uvádějí termíny v textu, notaci jednotného modelovacího jazyka (UML) a IDL u funkcí, které se normalizují. Tyto specifikace definují generické služby, které libovolná aplikace může použít pro výměnu informací s jinou aplikací nebo pro získání společných dat.
b) Části 450 až 499:
Jsou vyhrazeny pro specifikace, které určují požadavky na konkrétní výměnu informací pro typické kategorie aplikací, definované v příloze B. Tyto specifikace definují informační obsah normalizovaných výměn informací mezi aplikacemi. Ty jsou definovány jako události, ale mohou být vyměňovány různými způsoby, včetně toho, že budou vydávány jako zprávy, notifikace po nichž následuje požadavek, nebo budou v některých případech vyměňovány jako XML dokumenty. Charakteristiky a metody zajišťované každým rozhraním mohou být rovněž určeny, pokud je to požadováno. Doprovodná dokumentace obsahuje případy použití a časové diagramy událostí.
_______________
10) Rozšířený CIM UML model zajišťující oba soubory norem udržuje IEC TC 57 WG14, která odpovídá za soubor
IEC 61968.
V závislosti na typu výměny uvažovaném pro určitou kategorii událostí mohou být určeny konkrétní generické služby pro zajištění funkční spolupráce mezi složkami vyvinutými různými dodavateli. Záměrem pro použití těchto norem je poskytnout co možná největší pružnost u aplikačních programových prostředků zvolených pro skutečnou realizaci výměn informací, pokud to ještě zajistí funkční spolupráci.
Informační obsah je dokumentován v modelu výměny informací (IEM - Information Exchange Model) pro každou kategorii aplikací.
Specifikace CIS v IEC 61970-4XX jsou dokumentovány způsobem, který je nezávislý na vlastní technice použité pro jejich realizaci. Dokumenty souboru IEC 61970-4XX jsou tudíž někdy označovány jako CIS Úrovně 1. CIS dokumenty souboru IEC 61970-5XX uvedené v 6.4 provádějí mapování CIS specifikací z IEC 61970-4XX na konkrétní techniku dané infrastruktury a jsou tedy někdy označovány jako CIS Úrovně 2.
6.4 Mapování CIS techniky (IEC 61970-5XX)
Protože jsou CIS dokumenty nezávislé na návrhu vlastní techniky infrastruktury, musí být pro účely realizace mapovány na konkrétní techniky. Aby se zajistila funkční spolupráce, musí existovat normalizované mapování každého rozhraní na každou techniku. Je-li například za realizační techniku vybrána Java, pak je třeba normalizované mapování služeb pro vydávání zpráv a indexování událostí určených v CIS dokumentu na Java služby.
Obdobně potřebují být definice událostí shromážděné v IEM z CIS dokumentů pro každou kategorii aplikací mapovány na konkrétní jazyk použitý pro přenos informací. Například použije-li se pro předání XML zpráv zprostředkovatel zpráv, pak CIS události potřebují být mapovány na XML.
Předpokládá se, že se následující mapování nebo specializace stanou společnou normou u tohoto souboru, podle rozvržení těchto norem. Některé jsou specifické pro jazyk a některé jsou specifické pro aplikační programové prostředky:
· C++ jazyk;
· C jazyk;
· CORBA®;
· DCOM;
· Java®;
· XML. XML specializace zajistí funkční spolupráci mezi nezávisle vyvinutými složkami s GID rozhraním, pokud se jako integrační technika použije zpracování zpráv na základě XML.
7 Obecná předpokládaná funkčnost infrastruktury
7.1 Všeobecně
Tato kapitola popisuje schopnosti infrastruktury mezi aplikacemi společnosti nezbytné pro integraci distribuovaných složek. Tyto služby poskytuje systém realizace složek popsaný v referenčním modelu EMS-API v kapitole 4. Uvedené služby a funkce jsou nezávislé na vlastní technice použité pro tuto infrastrukturu.
Z hlediska následujících požadavků je „událost“ jednotka výměny informací, kterou asynchronně předává její zdroj („push“). „Složka“ je opakovaně použitelný modul aplikačního software na integrační sběrnici sloužící buď jako editor nebo jako účastník (příjemce) při výměně informací.
Dále je uveden seznam schopností, které má zajistit systém realizace složek, aby měl plně charakteristickou schopnost integrace mezi aplikacemi. Tím však není implicitně míněno, že každá realizace musí zajistit vše a každou funkci. Seznam je poskytován jako počáteční bod pro přípravu specifikace rozvinutí těchto norem u skutečného systému.
Konkrétní požadavky důležité pro toto rozvinutí budou záviset ve velké míře na konkrétních potřebách provozu a charakteristikách propojovaných systémů.
Systém realizace složek:
a) má umožňovat složkám vyměňovat si libovolně složité informace;
b) má být schopen realizace pomocí různých forem techniky distribuovaných složek (např. CORBA, DCOM, zprostředkovatelů zpráv, aplikačního programového vybavení orientovaného na zprávy, relačních databází, objektově orientovaných databází, nebo jiných) (viz kapitola 6);
c) má umožnit správcům systémů umístit složky editora a/nebo účastníka nezávisle na ostatních složkách;
d) má zajistit, že vydávané informace jsou zcela opakovaně použitelné v tom smyslu, že jakmile je předán daný typ události, může jakákoliv nově oprávněná entita tuto událost získat, aniž by musela provést nějaké změny či doplnění ve složce editora;
e) má poskytnout generický prostředek pro historii událostí jako složku. To umožní uchovávat všechny nebo vybrané výměny informací v permanentní paměti;
f) má zajistit schéma Historie Událostí vycházející z modelu metadat pro výměnu informací;
g) má poskytnout složku Historie Událostí pro záznam času, ve kterém předávající složka předala každou událost;
h) má být schopen zajistit verze modelu informací o událostech a verze složek. (To umožňuje uchovávat kompletní prověřovací záznam, který je schopen zajistit přesnou rekonstrukci historie, jestliže vznikne takovýto požadavek.);
i) má poskytnout složku Mezi-aplikačního Supervizoru (dohlížecího programu), která analyzuje stav každého rozhraní aplikační složky napojené na služby společnosti. Může být aktivována a deaktivována a má schopnost zajistit možnosti trvalého sledování. Její prvky pomůžou zajistit statistické údaje pro určení problémů nebo oblastí kde je výhledově nutná náprava. Tyto informace jsou vyžadovány, aby pomohly správcům konfigurovat informace vyměňované mezi složkami a zajistit dostupnost;
j) má umožnit složce vyslat nebo požadovat informace, aniž by znala kde je přijímající složka fyzicky umístěna nebo zda je aktuálně připojena. Příjemce může být nedosažitelný z důvodu problému sítě, nebo může být samozřejmě odpojen jako v případě mobilních uživatelů, kteří se připojují pouze periodicky. Složky mohou být nedostupné protože selhaly nebo protože pracují pouze v určitých hodinách; pokud se stane síť dostupnou nebo pokud je přijímající aplikace připravena zpracovat požadavky, musí se předat informace o čekání.
Následující články poskytují obecné schopnosti předpokládané u různých částí systému realizace složek EMS-API.
7.2 Sestava Složek
Sestavy Složek zajišťují u složek množinu API pro vyvolání služeb zajišťovaných sestavami. Dále uvedené služby jsou běžně poskytovány jako součást komerčně dostupných samostatných Sestav Složek. Seznam těchto obecných distribuovaných výpočtových služeb nezbytných pro zajištění EMS-API je:
a) Služba Cyklu Životnosti (Existence) Složky: tato služba umožňuje spouštění, zastavování a řízení realizovaných složek.
b) Služba Pojmenování: tato služba provádí službu pojmenovávání složek, které zajišťuje hierarchickou strukturu a umožňuje složce lokalizovat ostatní složky pomocí názvu čitelného pro člověka. Služba pojmenování zajišťuje použití existujících názvů společnosti a rovněž vytvoření názvů, odstranění názvů a přejmenování.
c) Služba Času: tato služba poskytuje distribuovaným složkám způsob pro to, aby měly všechny stejný čas s konfigurovatelnou přesností.
d) Služba Řízení Souběžnosti: tato služba usnadňuje řízení sdílených obdobných prvků, které jsou rozloženy, například když více složek se ve skutečnosti stará o různé části (výměny, typy výměn) stejného obchodního objektu.
e) Služba Zabezpečení: tato služba umožňuje aplikaci nastavit a ověřit stupeň zvláštního oprávnění složek a uživatelů, se kterým se provádějí výměny a rovněž kódování a dekódování jednotlivých výměn. Tato služba rovněž zajišťuje základní oprávnění, tj. oprávnění uzlu(ů).
f) Služba Transakcí: tato služba umožňuje aplikaci deklarovat začátek a konec transakce o více krocích, která buď uspěla nebo selhala jako konečná jednotka.
g) Služba Interakce Složek: tato služba provádí spolehlivý přenos zpráv s volitelnou Kvalitou Služby. Provádí rovněž řízení cyklu životnosti interakce služeb (vytvoření, zrušení, kopírování a přesouvání) a dotazování stanovené interakce (platí hlavně pro interakce Vydávání a Odebírání).
h) Služba Zpracování Zpráv při Vydávání a Odebírání: tato služba provádí synchronní a asynchronní přenos zpráv mezi nespřaženými (anonymními) případy složek.
i) Služba Zpracování Zpráv při Požadavku/Odpovědi: tato služba poskytuje spolehlivý synchronní přenos zpráv mezi spřaženými, určenými případy složek.
j) Služba Zpracování Zpráv při Vydávání/Odpovědi: tato služba provádí nespřaženou iniciaci přenosu zpráv (Vydávání), která je zakončena spřaženým přenosem (Odpověď).
k) Služba Průběhu Práce: tato služba umožňuje programátorům aplikační úrovně vytvořit a uvést do činnosti faktory automatizace obchodního procesu.
7.3 Aplikační programové prostředky
Služby aplikačních programových prostředků jsou nezbytné pro zajištění sestavy složek se základními službami požadovanými pro rozložené aplikace, nezávislé na použití modelů složek. Vymezení aplikačních programových prostředků a sestav složek je spíše abstraktní než konkrétní.
7.4 Služby Komunikačního Profilu
Integrování dvou složek vyžaduje spojení mezi nimi. Protože existuje více typů sítě, znají různé prostředky různé protokoly, například IIOP a hypertextový přenosový protokol (HTTP - Hyper-Text Transport Protocol). Aby spojil více složek, musí integrační systém srovnat odlišnosti sítě a protokolů transparentně vůči složkám.
Soubor norem IEC 61970 vyžaduje, že služby Komunikačního Profilu mají:
a) zaručit dodání zpráv po síti do jejich místa určení v této síti (je-li aktivní);
b) provádět zaručené dodání, zajišťující, že zprávy po síti jsou doručeny přesně jednou, bez ohledu na poruchy sítě nebo změny v síti;
c) provádět zaručené řazení, udržující sekvenci vysílání zdroje po dobu předávání zpráv, bez ohledu na poruchy sítě nebo změny v síti;
d) zaručit, že pokud nelze zprávu po síti dodat na místo určení v této síti, přijme zdroj v této síti zprávu indikující nedodání;
e) zajistit volitelnou kvalitu služby pro určování priorit zpráv v síti nebo jejich dodání zvláštními cestami v síti;
f) provádět dynamické přizpůsobení rychlosti zpracování zpráv ze sítě v místě určení v této síti pro umožnění pomalejším místům určení pracovat s těmito službami.
7.5 Služby specifické pro společnost
Existuje řada služeb specifických pro danou společnost, které mohou být nezbytné pro zajištění složek v EMS, které nemají k dispozici komerčně dostupné systémy realizace složek. Seznam možných služeb, které spadají do této kategorie, je uveden v příloze C jako příklady společně s možnostmi poskytování těchto služeb. Předpokládá se, že pokud jsou některé z těchto služeb nezbytné pro zajištění výměny informací mezi aplikacemi, budou určeny při vypracovávání CIS v souboru IEC 61970-4XX a stanou se součástí těchto norem.
Příloha A (informativní)
Modely složek
A.1 Model složky
Model složky definuje základní architekturu složky, určující strukturu jejích rozhraní a mechanizmy pomocí nichž konverzuje s její sestavou a s ostatními složkami. Model složky poskytuje návod pro tvorbu a realizaci složek, které mohou spolupracovat na vytvoření větší aplikace.
Existují čtyři základní modely složek dnes všeobecně akceptované softwarovým průmyslem, které jsou popsány v následujících článcích.
A.2 Enterprise JavaBeans®11)
Specifikace Enterprise JavaBeans (EJB) definuje model složky serveru pro JavaBeans® [2]12). Enterprise JavaBeans jsou specializované nezobrazené JavaBeans, které fungují spíše u serveru než u klienta. Enterprise JavaBean lze pro vytvoření nové aplikace sestavovat s ostatními Beans. S Enterprise Bean lze pracovat a přizpůsobovat jej potřebám uživatele pomocí jeho tabulky charakteristik a metod přizpůsobování potřebám uživatele.
Model složky Enterprise JavaBeans definuje vztah mezi složkou Enterprise Bean a systémem sestavy Enterprise Bean. Enterprise JavaBeans nevyžaduje použití žádného zvláštního systému sestavy. Libovolný systém realizace složek lze přizpůsobit pro zajištění Enterprise JavaBeans dodatečným zajištěním služeb definovaných v této specifikaci. Služby určují dohodu mezi Enterprise Bean a sestavou, tudíž vytvářejí stupeň přenositelnosti. To odpovídá adaptéru složek pro Enterprise JavaBeans, který je nezbytný pro každý výkonný systém s výjimkou Enterprise JavaBeans výkonného systému nazvaného Enterprise JavaBeans Server (EJB server). To umožňuje každému Enterprise Bean fungovat v jakémkoliv systému realizace aplikace nebo složce, které zajišťují dohody s Enterprise JavaBeans.
EJB server poskytuje normalizovaný soubor služeb pro zajištění Enterprise Bean složek. Protože jsou Enterprise JavaBeans transakční, má EJB server poskytovat přístup k rozložené službě řízení transakcí. Má rovněž pro Enterprise Bean zajistit sestavu, nazývanou Enterprise JavaBeans sestava (EJB sestava). EJB sestava realizuje služby správy a řízení pro určitou třídu z Enterprise JavaBeans tříd. Poskytuje rovněž následující služby:
– řízení cyklu životnosti (existence);
– řízení transakcí;
– řízení trvalosti;
– služby transparentní distribuce;
– služby zabezpečení.
A.3 Složky CORBA
CORBA má definován model složky obdobně jako specifikace EJB [3]. Model složky CORBA® definuje:
a) Složku fungující jako poskytovatel jednoho či více rozhraní CORBA. Složka:
· může poskytovat a používat jedno či více samostatných rozhraní CORBA;
· může vysílat nebo přijmout jednu či více konkrétních událostí;
· má konfigurovatelné charakteristiky návrh-čas;
· má provozní atributy;
· deklaruje průmyslové rozhraní, které lze použít pro vytvoření případů složky.
_______________
11) Enterprise JavaBeans je obchodní název produktu dodávaného Sun Microsystems. Tato informace je poskytována pro potřeby uživatelům této mezinárodní normy a netvoří dodatek IEC pro jmenovaný produkt. Lze použít rovnocenné produkty, pokud u nich lze prokázat, že vedou ke stejným výsledkům.
12) Čísla v hranatých závorkách odkazují na bibliografii.
b) Model sestavy pro zavádění systémových služeb do provozního prostředí složky CORBA. Model sestavy definuje:
· lokálně omezená rozhraní složek pro interakci s jejich sestavou;
· zjednodušenou verzi CORBA transakcí;
· zajištění cyklu životnosti pro optimalizaci prostředku použitého v procesu;
· zásady zabezpečení zajišťující ověřování oprávnění na základě určení klienta a udělení oprávnění podle zabezpečovací služby CORBA;
· trvalé řízení stavu.
Mapování na EJB umožňuje, aby EJB byl zajištěn jako složka CORBA v sestavě, která zajišťuje aktivaci, transakce, zabezpečení a trvalost. Pro zajištění EJB čistě v sestavě CORBA je nezbytná transformace EJB Java API na Java mapování příslušných CORBA API. Naopak složku CORBA, která se sama omezuje na funkčnost definovanou specifikací EJB a je vypracována v Java, má být možno umístit v EJB sestavě.
CORBA Sestavy jsou provozní kontexty poskytující rozhraní s klienty a obousměrná (místně vymezená) rozhraní s případy složek, které vyčleňují systémové služby pro realizaci složky. Sestavy budou poskytovat metody a/nebo API pro zajištění transakcí, zabezpečení, řízení stavů a trvání. Například metody pro transakce a zabezpečení jsou definovány v deskriptoru umístění složky. Sestava použije tyto deskriptory pro realizaci příslušných vyvolání služby transakcí CORBA a CORBA zabezpečení před iniciací požadované činnosti u složky.
Sestava poskytuje své složce následující funkce:
· Všechny případy složky vytváří a řídí její sestava za provozu.
· Určitá metadata (např. transakce, zabezpečení, události a trvání) jsou oddělena od realizace složky, aby s nimi bylo možno manipulovat před umístěním.
· Složka má být přizpůsobena potřebám uživatele pomocí editování jejích metadat.
· Oprávnění k přístupu klienta k rozhraním poskytovaným složkou uděluje sestava v níž je složka umístěna.
· Sestavy poskytují složce normalizovaný soubor systémových služeb, umožňujících složce být obsažena v různých realizacích sestav.
A.4 Microsoft® COM/DCOM
Model objektu složky (COM) Microsoft byl původně vyvinut pro zajištění integrace stolních aplikací na bázi Windows [4]. COM vznikl jako jeden z výsledků snahy Microsoft zdokonalit OLE (Object Linking and Embedding - sestavování a vkládání objektů) z verze 1 na verzi 2. COM původně nezajišťoval rozložené prostředí. Verze COM, která zajišťuje rozložení se nazývá DCOM.
Problémem vyřešeným COM/DCOM je usnadnění rozkládání systému software skládajícího se z jedné či více tříd na samostatné bloky, které lze vyvíjet a udržovat nezávisle na ostatních.
Zajištění složek v COM je zcela jednoduché a zahrnuje dvě hlavní části:
1) popisný jazyk rozhraní nazvaný Microsoft jazyk pro definování rozhraní (MIDL - Microsoft Interface Definition Language) a prostředky zajišťující překlad MIDL kódu na popisy rozhraní C++ nebo Visual Basic;
2) provozní prostředí zajišťující vyhledávání a aktivaci složek.
DCOM pak doplňuje zajištění dálkové komunikace s provozním prostředím.
Na vrchol COM/DCOM doplnil Microsoft soubor normalizovaných rozhraní vykazující různé systémové funkce a služby, například zpětné dotazy (připojitelných objektů), trvalost, služba pro jednoduché pojmenování (přezdívky), knihovna typů a dynamické vyvolání rozhraní (OLE automatika), apod. Tato rozhraní, jejich příslušné zajištění provozu a COM/DCOM je to, co provádí OLE 2.0.
COM je nově rozšířen na úplný systém realizace složek nazvaný COM+. COM+ zajišťuje jednodušší vývoj složek, jednodušší instalaci složek, obsluhu transakcí, události, vydávání a odebírání a řazení zpráv do fronty.
V COM+ definuje Microsoft logické a fyzické sdružování. Logické sdružování znamená rozdělování tříd a rozhraní na samostatné rozsahy názvů, tudíž snižování kolizí názvů tříd čitelných pro člověka. Fyzické sdružování je jednotka pro rozmístění odpovídající skutečné složce nebo modulu, obvykle jeden nebo více proveditelných bloků (.EXE) nebo dynamických spojových zaváděných modulů (.DLL). V případě, když DLL realizuje třídy (na rozdíl od čistých proxy DLL), lze postup zavádění považovat za sestavu, především pokud postup zavádění zahrnuje pouze základní nebo strukturální funkce. Složka nebo modul obvykle realizuje jednu či více tříd a rovněž rozhraní. Neexistují žádná omezení na to, jak složky nebo moduly realizují třídy nebo rozhraní. Toto je volba realizátora.
COM/DCOM je rovněž k dispozici u dalších počítačových bází jako je Digital Unix a Solaris. Strojově orientované zajištění pro COM/DCOM je poměrně přenosné. Méně přenosné jsou funkce souvisící s Windows pro stolní počítače (např. registr).
A.5 XML webové služby a Microsoft .NET
XML webové služby poskytují model integrace založený na Internetu pro integraci vše se vším. XML webové služby umožňují aplikacím komunikovat a sdílet data po internetu, bez ohledu na operační systém či programovací jazyk. Jsou jako složky.
XML webové služby poskytují model integrace založený na Internetu pro integraci vše se vším. Hlavní služby jsou:
· UDDI (Universal Description and Discovery Information - universální popisné a vyhledávací informace) - Zveřejňuje a vyhledává ostatní služby.
· XML a http - Komunikační prostředky a obsah dat.
· SOAP (Simple Object Access Protocol - jednoduchý protokol pro přístup k objektům) - Služba na základě transakcí pro vyměňování informací a vyvolávání služeb v rámci všech rozložených aplikací.
.NET je strategie Microsoft a nabízí všude využití XML webových služeb, a je v zásadě základem XML webových služeb. Existuje pět hlavních oblastí na něž je třeba se zaměřit při tvorbě základu XML webových služeb:
a) Klienti - všechny typy PC a inteligentních (programovatelných) zařízení, které znají XML.
b) Služby - takové, jako je Microsoft .NET služba ověřování oprávnění, která poskytuje jednoduchou možnost přihlášení pro libovolné místo na webu.
c) Servery - integrovaná sada (programů) pro provádění, řízení, instrumentaci webových služeb a aplikací, které mohou ukládat, směrovat, přeměňovat a emulovat přebíraná data.
d) Vývojové prostředky - například Visual Studio .NET a .NET Framework.
e) Zkušenosti a řešení - kombinují nejlepší místní aplikace a internetové služby.
.NET je softwarová báze Microsoft, která určuje všechny ostatní oblasti.
Báze Microsoft.NET® zahrnuje úplnou řadu produktů založených na XML a internetových průmyslových normách, které zajišťují každý aspekt vyvíjení, řízení, používání a kvalifikování XML webových služeb.
.NET Framework je vícejazyčné prostředí realizace aplikace s vysokou produktivitou založené na normách, které poskytuje základní služby infrastruktury a usnadňuje umístění. Poskytuje prostředí realizace aplikace, které řídí paměť, určuje problematiku stanovení verzí a zlepšuje spolehlivost, přizpůsobitelnost a zabezpečení této aplikace. .NET Framework se skládá z několika částí včetně provádění obecného jazyka, rozsáhlé množiny knihoven tříd pro sestavování XML webových služeb a ASP .NET.
Příloha B (informativní)
Typické aplikace a funkce
Tabulka B.1 - Typické aplikace a funkce
|
Kategorie aplikace |
|
Účastník (obsluha) |
|
|
|
Název aplikace |
Komentář/vysvětlivka |
|
|
SCADA |
|
Obsluha v terénu |
|
|
|
Časová synchronizace |
Synchronizace nastavení času v RTU |
|
|
|
Komunikace RTU a PLC |
Sběr dat z terénu pomocí RP570, |
Obsluha stanice (rozvodny) |
|
|
Dálková komunikace s centrem |
Prostředky pro komunikaci mezi pracovišti používající ICCP, ELCOM, … |
|
|
|
Zpracování signálů |
Filtrování, převod technických jednotek, převod na technické jednotky, kontrola kvality, kontrola mezí |
|
|
|
Zpracování dat |
Zpracování obecných výpočtů, stavových, analogových a integrovaných hodnot, kvality |
|
|
|
Označování |
Označování je používáno k doplnění označení u libovolných obecných objektů znázorňovaných v SCADA |
|
|
|
Jednopólová schémata |
Bloková grafická zobrazení provozu |
|
|
|
Přehledy stavů |
SCADA/EMS zprávy o stavech objektů |
|
|
|
Dispečerské řízení |
Řízení zařízení a sekvenční řízení |
|
|
|
Řízení soustavy |
|
|
|
|
Vnitřní řízení |
|
|
|
|
Řízení mezních hodnot |
Dynamický podmíněný výběr ze souborů mezních hodnot |
|
|
|
Zpracování časově označených dat |
Snímání, ukládání a zobrazování časově označených dat na zobrazovačích tabulek/trendů |
|
|
|
Sběr poruchových dat |
Zaznamenávání posloupnosti událostí a následná analýza (post mortem) |
|
|
|
Statistika zařízení |
Ukládání údajů o provozu zařízení |
|
|
|
Plány spínání |
|
|
|
|
|
|
|
|
Zpracování výstrah |
Zpracování výstrah a událostí |
|
|
|
|
|
|
|
|
Zpracování topologie |
Vyhodnocuje propojení zařízení a stav pod napětím a sestavuje model sběrnice pro zajištění funkcí sítě pro zobrazení zapojení sítě na zobrazovačích uživatele. Může zahrnovat analýzu zemního spojení pro analýzu poruch. |
Obsluha přenosu, obsluha regulační oblasti |
|
(pokračování)
Tabulka B.1 (pokračování)
|
Kategorie aplikace |
|
Účastník (obsluha) |
|
|
|
Název aplikace |
Komentář/vysvětlivka |
|
|
Síťové aplikace |
Množina prostředků pro analýzu bezpečnosti přenosové soustavy, zvýšení bezpečnosti a optimalizaci sítě |
Obsluha přenosu, analyzátor přenosů, obsluha regulační oblasti |
|
|
|
Estimátor stavů |
Včetně aktualizace parametrů sítě a toku výkonu přípojnicemi |
|
|
|
Ekvivalentní zapojení sítě |
Výpočet náhradních sítí z neúplných dat |
|
|
|
Rozdělení toku výkonu |
Rozborová činnost při výpadku zařízení elektrizační soustavy, změnách výroby, změnách zatížení přípojnic a libovolných dalších změnách veličin v soustavě nebo v dané oblasti (zatížení, výroby, výměny a napětí) |
|
|
|
Řízení dané bezpečností |
OPF použitý k určení povelů daných bezpečností a nepředvídaných skutečností |
|
|
|
Analýzy zkratů |
|
|
|
|
Bezpečnostní analýza |
Přezkoumání a vyhodnocení nepředvídaných skutečností |
|
|
|
Citlivost sítě |
Určení penalizačního součinitele |
|
|
|
Výkonová přenosová schopnost |
|
|
|
|
Dynamická analýza bezpečnosti |
|
|
|
|
Vyhodnocení přenosů s měnícím se směrem |
|
|
|
|
Pomocné řízení bezpečnosti |
OPF použitý k určení povelů daných bezpečností a nepředvídaných skutečností |
|
|
|
Stabilita přenosu |
|
|
|
|
Omezení sítě |
|
|
|
|
Přizpůsobení parametrů sítě (rozvrhovač sběrnice) |
|
|
|
|
Použitelná přenosová schopnost (ATC - Available Transmission Capacity) |
|
|
|
|
Optimální tok výkonu (OPF - Optimal Power Flow) |
|
|
|
|
OPF daný bezpečností |
|
|
|
|
Cenová analýza podle lokality |
|
|
|
|
Bezpečnostně zajištěné spínání |
DLF použité pro kontrolu a vzájemné blokování povelů před provedením |
|
|
|
Určení stability napětí |
|
|
|
|
Vyhodnocení přenosových ztrát |
Určení součinitele ztrát sítě |
|
|
|
Analýza přetížení |
|
|
|
|
Intervence pro obnovení |
|
|
|
|
Sledování stavů |
Podmínky systému sledování pro ověření, že elektrizační soustava je provozována v souladu s aktuálními plány a postupy |
|
(pokračování)
Tabulka B.1 (pokračování)
|
Kategorie aplikace |
|
Účastník (obsluha) |
||
|
|
Název aplikace |
Komentář/vysvětlivka |
|
|
|
|
Varianty spínání |
|
|
|
|
|
Plány |
|
|
|
|
|
Regulace napětí jalovým výkonem |
Regulace zajišťující splnění požadavků na napěťový profil sítě |
||
|
|
Sledování bezpečnosti sítě |
Sledování podmínek sítě pro ověření, že elektrizační soustava je provozována v souladu s aktuálními plány a postupy, určení zařízení pracujícího v blízkosti provozních mezních hodnot |
||
|
Řízení zatížení |
Toto je nová kategorie aplikací |
|
||
|
|
Odpojování zatížení |
Střídání a blokování odpojování zatížení |
|
|
|
|
Plánování zatížení |
Plánování zatížení při podnormální výrobě nebo podle ceny |
|
|
|
|
|
|
|
|
|
Řízení výroby (výkonové aplikace) |
|
Obsluha elektrárny |
||
|
|
AGC (Automation Generator Control - Automatické řízení generátoru) |
Stanovení ACE pro automatické nastavení výkonu generátorů v regulační oblasti společnosti a v případě nezbytnosti vydání výstrah |
|
|
|
|
Ekonomické řízení/dynamické řízení |
|
|
|
|
|
Omezené ekonomické řízení |
|
|
|
|
|
Sledování rezervy |
Sleduje pohotové rezervy a generuje výstrahy vždy, když nastane krátkodobý pokles |
|
|
|
|
Náklady na výrobu |
|
|
|
|
|
Rozdělení výroby a řízení bloku |
|
|
|
|
|
Regulace kmitočtu a zátěže (LFC - Load Frequency Control) |
|
|
|
|
|
Sledování řídicích charakteristik |
Sledování AGC podle prvotních ACE hodnot |
|
|
|
|
Vyhodnocení výměnných transakcí A |
Krátkodobé používání stejných jednotek, hodiny |
|
|
|
|
Optimalizace paliva |
|
|
|
|
|
Plánování kmitočtu |
Informace o plánování kmitočtu požadované AGC funkcí |
||
|
|
|
|
|
|
|
Prognóza zatížení |
Zpracovává prognózy zatížení na základě průběhu zatížení a povětrnostních údajů a předpovědi počasí. Může zahrnovat stanovení krátkodobých trendů zatížení až do jedné hodiny |
|
||
|
|
|
|
|
|
|
Prognóza výroby |
Zpracovává prognózy výroby |
|
||
|
|
|
|
|
|
(pokračování)
Tabulka B.1 (pokračování)
|
Kategorie aplikace |
|
Účastník (obsluha) |
|
|
|
Název aplikace |
Komentář/vysvětlivka |
|
|
Plánování přenosu energie |
|
Obchodník s přenosy energie |
|
|
|
Plán výměnných transakcí |
|
Plánovač provozu |
|
|
Vyhodnocení výměnných transakcí B |
Jednotky dlouhodobých změn, dny |
Plán energie |
|
|
Plánování přenosu |
|
Plánovač soustavy (dlouhodobé) |
|
|
Nasazení jednotek |
|
Koordinátor plánování |
|
|
Nasazování jednotek dané bezpečností |
|
|
|
|
Nasazování jednotek do více oblastí |
|
|
|
|
Vyhodnocení transakcí |
Transakce energií a přenosů |
Obchodník s energií pro velkoodběratele |
|
|
Optimalizace/koordinace vodních a tepelných elektráren |
|
|
|
|
Plánování vodních elektráren |
|
|
|
|
Dlouhodobé plánování provozu |
|
|
|
|
Prognóza přítoku |
|
|
|
|
Uzavírání smluv |
Databáze a prostředky pro čerpání smluvních informací |
|
|
|
|
|
|
|
Plánování údržby |
|
Dozor výstavby/údržby |
|
|
|
Plánovač odstávek |
Předběžný plán odstávek přenosového zařízení |
Plánovač údržby |
|
|
|
|
|
|
Řízení přenosových prostředků |
ATC výpočet a určení dopadu výměnných transakcí na elektrizační soustavu plus sledování přenosové kapacity, kterou lze prodat. Může zahrnovat smlouvy na oprávnění k přenosu |
||
|
|
|
|
|
|
|
|
|
|
|
Účetnictví |
|
Kontrolor oddělení fakturací (přenosu) |
|
|
|
Zpracování tarifů |
Zajištění různých tarifů pro různé časy během dne |
|
|
|
Účetní zprávy |
|
|
|
|
Účtování elektrické energie |
Hodinové odečty a bilance |
|
|
|
|
|
|
(pokračování)
Tabulka B.1 (dokončení)
|
Kategorie aplikace |
|
Účastník (obsluha) |
||
|
|
Název aplikace |
Komentář/vysvětlivka |
|
|
|
HIS (Historical Information System) (Archivace) |
Informační systém s historickými daty (aplikace centrální databanky) 1) StavováData (např. hodinové hodnoty zatížení) a DataSeZměnamiStavů (např. události vedoucí k výstrahám), 2) Data pro audit, 3) Data splňující požadavky nařízené archivace. |
|
||
|
|
|
|
|
|
|
Technická správa dat |
|
Technik údržby databáze |
||
|
|
|
|
Správce systému |
|
|
(Generické uživatelské rozhraní) |
|
|
||
|
|
|
|
|
|
|
Dynamická simulace |
Dynamická simulace sítě, kratší časové úseky než OTS |
|
||
|
Simulátor (trenažér) pro výcvik dispečerů |
|
Instruktor výcviku |
||
|
|
Rozhraní instruktora a řízení relace |
Zahrnuje uchovávání základních úloh (uchovávání trvalých úloh) a pomocné funkce pro instruktora (sestavování scénářů) |
|
|
|
|
Model/simulátor elektrizační soustavy |
|
|
|
|
|
Simulátor systému sběru dat |
|
|
|
|
|
|
|
|
|
|
Obchodní operace |
|
|
||
|
|
Marginální (mezní) ceny pro dané lokality |
Určení marginálních cen pro dané lokality |
|
|
|
|
OASIS |
Rozhraní pro vysílání dat na otevřený informační systém se současným přístupem (OASIS - Open-Access Same-time Information System) a získávání dat z něho |
|
|
|
|
E-Tag |
Elektronická označení transakcí |
|
|
|
|
Ostatní |
a) |
|
|
|
|
|
|
|
|
|
Vnější |
|
|
||
|
|
DMS |
|
|
|
|
|
Počasí |
|
|
|
|
|
Obchodování s velkoodběrateli elektrické energie |
|
|
|
|
a) Vypracování množiny funkcí v době vydání. Pro obsluhu nezávislých systémů (ISO) a obsluhu regionálních přenosů (RTO) budou nezbytné bilance, vyúčtování, profily zatížení odběratelů, apod. |
||||
Příloha C (informativní)
Problematika normalizovaných modelů složek u společnosti
Všechny služby, které potřebuje daná aplikace společnosti v reálném čase nemusí být poskytovány jako součást normalizovaných služeb sestavy. Zejména následující služby nemusí mít komerční prodejci aplikačních programových prostředků ihned k dispozici:
a) Služba přístupu k modelu výměny informací: tato služba umožňuje rozloženým složkám, které jsou registrovány, zavést a zjistit syntaxi pro výměnu obecného modelu (například formát a typ výměn) a být seznámeny se změnami, ke kterým došlo.
b) Adresářové služby: tyto služby umožňují přístup k výchozí i provozní množině dostupných objektů a služeb u systému. U této služby lze definovat různé aspekty závisící na konkrétních charakteristikách. Například to umožňuje definovat charakteristický aspekt rozložení u kritických prvků, který lze porovnat s provozním charakteristickým aspektem pro určení, zda tyto prvky existují u těchto Služeb. Adresář obsahuje kromě jiného ID pro složku a šablony (třídy) komerčních objektů a rovněž případy.
c) Vytvoření ID prostředků: tato služba umožňuje vytvoření jednoznačného ID příslušejícího případům objektu elektrizační soustavy. V závislosti na konkrétních zásadách pro každý typ může existovat více typů ID. Například může jeden ID příslušet části zařízení po celou její životnost, pokud je tato považována za aktivum (kmenový majetek), bez ohledu na to, kde se v síti dané elektrizační soustavy toto aktivum použije. Jiný typ ID může příslušet topologickému místu v síti dané elektrizační soustavy nacházející se v určité lokalitě, bez ohledu na konkrétní kmenové vybavení příslušející tomuto místu.
d) Správa systému: toto rozhraní služby umožňuje správu a sledování výměn a složek u služeb. Součástí této služby jsou rovněž bilancování poruch složek a zatížení. Součástí této služby je též sledování fyzického stavu systému pro spolehlivý provoz systému.
e) Konfigurace podle obecného modelu: tato služba poskytuje rozhraní složkám, aby při iniciaci nebo při provádění poté, co byla určitá složka částečně konfigurována místně, získaly svoji konfiguraci podle obecného modelu z permanentní datové paměti.
f) Filtrování podle obecného modelu: tato služba umožňuje určit a používat filtry podle typů a obsahů výměn.
g) Vlastní zajištění CIS API z IEC 61970-4XX: soubor IEC 61970-4XX uvádí API použitá pro výměnu informací mezi složkami řídicího centra. Zajištění těchto API umožňuje složkám vyhovujícím IEC 61970-4XX „zapojit se“ do integrační infrastruktury s minimálním objemem zakázkového programování.
h) Jsou vyvinuty další služby, které mohou být určeny jako CIS normy v IEC 61970-4XX.
Možnosti pro zajištění těchto služeb jsou následující:
1) Získání těchto služeb jako nových složek fungujících v existujících sestavách. Zvolí-li se tato možnost, pak ostatní složky budou potřebovat vědět o těchto složkách, aby je mohly zaregistrovat pro používání.
2) Změna nebo rozšíření existujících sestav pro zajištění těchto služeb pro tyto složky, obdobně jako u služby transakcí nebo pojmenování.
3) Realizace jako součást úrovně adaptéru složek, takže tato úroveň bude mít dvě hlavní funkce:
– poskytnout služby specifické pro danou společnost;
– provést převedení API dané sestavy pro složky určené pro jiné prostředí výkonného systému.
Příloha D (informativní)
Příklady systémů realizace složek a produktů aplikačního programového vybavení
D.1 Typické systémy realizace složek
Systémy Realizace Složek (známé rovněž jako Systémy Sestav) obsahují existující produkty aplikačního programového vybavení, které dodržují dohodu pro sestavu a zásady modelu složky využívaných daným systémem. Některé příklady produktů aplikačního programového vybavení majících realizovány API sestavy zahrnují:
– Báze CORBA, například Borland VisiBroker13) nebo Iona Orbix.
– Servery Transakcí Složek (CTS - Component Transaction Servers), například Sybase Jaguar CTS nebo Transakční Server Microsoft.
– Monitory Transakčního Procesoru (TP - Transaction Processor), které obsahují transakce a řídí sdílené prostředky pro danou transakci. Společně pak může probíhat více transakcí, spoléhajících se při koordinaci rozšířené transakce na TP monitor. Příklady zahrnují IBM TXSérie (CICS a Encina) a BEA Tuxedo.
– Webové servery, které obsahují požadavky na webové stránky. Více webových klientů může předávat na webový server současné požadavky na stránky. Webový server předává HTML stránky nebo vyvolává jiné funkce pomocí povelových souborů nebo programů iniciace služeb obecného grafického rozhraní (CGI - Common Graphics Interface) v odpovědi na požadavky. Příklady zahrnují Java Web Server, Netscape Enterprise Server, nebo Oracle Application Server.
– Systémy řízení databáze (DBMS), které obsahují požadavky na databázi. Více klientů databáze může předávat současně požadavky na databázi a spoléhat se na DBMS, že zkoordinuje blokování a transakce. Příklady zahrnují Oracle, Sybase, nebo IBM DB2.
– Jakékoliv další struktury výkonného systému, které dodržují dohodu se sestavou pro zajišťování složek. Například dodavatel EMS může navrhnout EMS systém realizace aplikace pro zajištění sestav, připouštějící použití složek vyvinutých buď interně nebo na zakázku od jiného dodavatele složek.
Dodavatel systému obvykle zajišťuje systémy realizace složek.
D.2 Typické produkty aplikačního programového vybavení
Příklady patentovaného a fakticky normalizovaného aplikačního programového vybavení zahrnují:
– Produkty aplikačního programového vybavení a hradla pro přístup k databázi (například Open DataBase Connectivity (ODBC), Information Builders SQL, apod.).
– Aplikační programové vybavení pro komunikaci mezi aplikacemi, například CORBA ORB, aplikační programové vybavení orientované na zprávy (např. Vitria, Active Software, Tibco, apod.), TP monitory.
_______________
13) Borland VisiBroker a další obchodní názvy použité v této příloze jsou příklady vhodných komerčně dostupných produktů. Tato informace je poskytována pro potřeby uživatelům této mezinárodní normy a netvoří dodatek IEC pro tyto produkty.
Bibliografie
[1] IEC 61968 (all parts), Application integration at electric utilities - System interfaces for distribution management
(Integrace aplikací v energetických společnostech - Systémová rozhraní pro řízení distribuce elektrické energie)
POZNÁMKA Je v souladu se souborem EN 61968 (nemodifikován).
[2] Enterprise JavaBeans® Specification, Version 2.1, Final Release, November 12, 2003, available from Sun Microsystems®, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A.
(Specifikace Enterprise JavaBeans®, Verze 2.1, konečné vydání, 12. listopadu 2003, k dispozici u Sun Microsystems®, Inc., 4150 Network Circle, Santa Clara, California 95054, U.S.A.)
[3] CORBA® Components, Version 3.0, formal/02-06-65, June 2002, available from the Object
Management Group (OMG) at www.omg.org.
(Složky CORBA®, Verze 3.0, oficiální/02-06-65, červen 2002, k dispozici u Object Management Group (OMG) na www.omg.org)
[4] The Component Object Model Specification, Draft Version 0.9, October 24, 1995, available from the Microsoft® Corporation.
(Specifikace Modelu Objektu Složky, Návrh Verze 0.9, 24. října 1995, k dispozici u Microsoft® Corporation)
[5] Guidelines for Control Center Application Program Interfaces, EPRI Technical Report TR-106324, Project 3654-01, Final Report, June 1996
(Směrnice pro rozhraní aplikačního programu v řídicím centru, technická zpráva EPRI TR-106324, projekt 3654-01, závěrečná zpráva, červen 1996)
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-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 -1) Rozhraní aplikačního programu pro systémy EN 61970-301 20042)
řízení elektrické energie (EMS-API)
Část 301: Základ obecného informačního
modelu (CIM)
_______________
1) Nedatovaný odkaz.
2) Platná edice v době vydání.
Prázdná strana
-- Vynechaný text --
Zdroj: www.cni.cz