Cílovým publikem této příručky jsou nástroje, které plánují nasadit programy Demand Response (DR), které využívají OpenADR 2.0 ke komunikaci zpráv souvisejících s událostmi DR mezi obslužnými a následnými entitami, a výrobci zařízení, které tuto výměnu komunikace usnadňují. Předpokládá se, že čtenář má základní koncepční porozumění jak odezvě na poptávku, tak OpenADR 2.0 (od tohoto okamžiku označované jednoduše jako OpenADR).

OpenADR profile specifikace jasně definují očekávané chování při výměně informací souvisejících s událostmi DR, nicméně v OpenADR je dostatek volitelnosti, že nasazení serverů (VTN) v obslužném programu a klientů (VEN) na navazujících webech není zážitkem plug-n-play. Charakteristiky OpenADR, jako jsou signály událostí, formáty zpráv a cílení, musí být specifikovány na základě programu DR po jednotlivých programech.

Neexistuje nic jako standardizovaný program DR. Každý návrh programu DR má tendenci být jedinečný a odpovídá strukturálním a regulačním požadavkům geografické oblasti, ve které je nasazen. Pro každý program DR existuje řada možných scénářů nasazení zahrnujících celou řadu aktérů.

Variabilita návrhů programů DR, scénářů nasazení a charakteristik OpenADR jsou inhibitorem rozšířeného nasazení DR a používání OpenADR. Tato variabilita je z velké části odrazem fragmentované a složité povahy inteligentní sítě.

Nástroje potřebují napřampsoubory typických programů DR, aby mohly být použity jako modely pro vlastní implementace programů DR. Výrobci zařízení musí rozumět typickým modelům používání programu DR, aby mohli ověřit interoperabilitu jako součást vývojového procesu, a nikoli na základě konkrétního nasazení programu DR. Účelem této příručky je dosáhnout obou těchto cílů následujícím způsobem:

Definujte malou sadu standardních šablon programů DR po vzoru společných charakteristik nejpopulárnějších programů DR implementovaných doposud
Definujte malou sadu scénářů nasazení modelovaných po nasazeních v reálném světě s jasně identifikovanými aktéry a rolemi

Definujte doporučení osvědčených postupů pro charakteristiky OpenADR specifické pro každou ze šablon programu DR
Poskytněte rozhodovací strom, který mohou obslužné programy použít k identifikaci užitečných šablon programů DR a scénářů nasazení na základě jejich obchodních potřeb

Důraz v této příručce bude kladen na udržování jednoduchých věcí poskytnutím malé sady jasných doporučení, která se budou zabývat většinou podrobností požadovaných pro nasazení typického programu DR, a umožněním testování interoperability zařízení nasazených v programech s využitím doporučení v této průvodce.

Reference

OpenADR Profile Specifikace a schéma - www.openadr.org

Termíny a definice

V tomto dokumentu jsou použity následující termíny a definice.

Odezva na poptávku: Mechanismus pro správu poptávky zákazníků v reakci na podmínky nabídky, jako jsou ceny nebo signály dostupnosti

Agregátorská párty - Toto je strana, která agreguje více zdrojů dohromady a prezentuje je programové straně DR jako jeden zdroj ve svých programech DR.
Infrastruktura agregátoru - Jedná se o infrastrukturu, oddělenou od infrastruktury na straně poptávky, kterou používá zprostředkující strana agregátoru k interakci jak se zdroji, tak se subjekty na straně mřížky
Dohoda: Smluvní dohoda mezi stranami hrajícími roli v programu DR s popisem odpovědnosti a kompenzace

Aktivum - Typ zdroje, který představuje konkrétní kolekci fyzických zátěží. Prostředky mohou být složeny z aktiv a aktivem může být zdroj, ale aktiva nelze dále rozložit na více aktiv nebo zdrojů.
Přidružený: Poskytněte programové přidružení mezi dvěma entitami prostřednictvím konfigurace zařízení databáze. Například přidružené prostředky k VEN
Základní linie: Vypočtená nebo naměřená spotřeba energie (poptávka) zařízením nebo místem před událostí, jak je určeno průzkumy, inspekcemi a / nebo měřením na místě.

BMS - Toto je systém správy budov, který lze použít k řízení zdrojů. Toto se někdy označuje jako systém řízení energie.
Složený zdroj - Toto je speciální typ zdroje, který je agregací více fyzických aktiv, z nichž každý má své vlastní prostředky řízení zátěže.
Pobídka pro zákazníka: Podnět poskytnutý vlastníkovi / agregátorovi zdrojů na straně poptávky k účasti v programu DR.

Infrastruktura na straně poptávky - Toto je infrastruktura, která obsahuje zdroje, které jsou zapsány do programů DR
Logika DR: Algoritmy nebo logika, které převádějí signály DR na použitelné řízení zátěže. Upozorňujeme, že DR Logic může být implementován na mnoha různých místech a v některých případech může být distribuován mezi více podsystémů.
Programová strana DR - toto je subjekt, který je zodpovědný za Grid Infrastructure a dále za správu DR programů používaných ke zmírnění problémů s Gridem. To je obvykle Utility nebo ISO.

Zapsáno: Vlastník / agregátor zdrojů na straně poptávky se rozhodne účastnit se programu DR a může poskytnout informace o konkrétních zdrojích, které mohou být zaměřeny na události DR
Aktivní období události: Je doba, během které se mění zátěž profile je požadováno jako součást události DR
Omezení událostí: Časové rámce, během kterých může zákazník očekávat příjem událostí a souvisejících omezení, jako například žádné události o víkendech nebo po sobě jdoucích dnech

Dny událostí: Den, kdy dojde k události DR. Většina programů má omezení, pokud jde o počet dnů událostí, které jsou povoleny v daném kalendářním období
Deskriptor události: Část objektu události OpenADR, která popisuje metadata o události, například název programu a prioritu události
Trvání události: Délka akce. Většina programů definuje omezení, pokud jde o délku události a hodiny v průběhu dne, během kterých k události může dojít

Signály událostí: Vyžádané informace obsažené v události, jako je stanovení ceny elektřiny nebo konkrétní úroveň uvolnění zátěže, které obvykle spouštějí určité předprogramované chování uvolnění zátěže příjemcem události. Definice programu DR by měla specifikovat typy použitých signálů událostí
Cílení na události: Prostředky uvolňující zatížení, které jsou zamýšleným příjemcem události DR. Může to být geografická oblast, konkrétní třída zařízení, identifikátor skupiny, ID prostředku nebo jiný identifikátor. Definice programu DR by měla specifikovat, jak budou zaměřeny konkrétní zdroje.
Události: Událost je oznámení od obslužného programu požadovat zdroje na straně strany požadující uvolnění zátěže počínaje v určitém čase, po stanovenou dobu, a může zahrnovat informace o cílení určující konkrétní zdroje, které by se měly akce účastnit

Zprostředkovatelská infrastruktura zprostředkovatele - Toto je infrastruktura, oddělená od infrastruktury na straně poptávky, kterou využívá zprostředkující strana zprostředkovatele k interakci jak se zdroji, tak se subjekty na straně mřížky.
Facilitátor: Třetí strana, která jménem obslužného programu řídí část nebo celé provádění programu DR
Infrastruktura sítě - Toto je infrastruktura, kterou vlastní nebo spravují strany programu DR. Tato infrastruktura zahrnuje implementaci OpenADR VTN, která se používá k odesílání signálů DR do zdrojů zapsaných v programech DR

Zprostředkující strana - Toto je strana, která obvykle pracuje jménem zdrojové strany, aby usnadnila jejich účast v programech DR.
Řízení zátěže - toto je infrastruktura související se zdrojem, který je zodpovědný za skutečné ovládání zdroje a vytváření specifického zatížení profile.
Načíst Profile Objektivní: Tato motivace stojí za vývojem programu DR a vydáváním událostí. Například touha po oholení špičkových zátěží.

Oznámení: Časové období před začátkem události, kdy je vlastník prostředku na straně poptávky informován o nevyřízené události
Optické chování: Očekávaná odpověď od vlastníka zdroje na straně poptávky po přijetí události. Tato odpověď může mít formu a označení OptIn nebo OptOut, zda se na akci bude podílet prostředek
Optické odpovědi: Zda by měl konkrétní program vyžadovat reakci od zdrojů na straně poptávky v reakci na událost a jaké jsou tyto reakce obvykle.

Volit služby: Plány komunikované přes OpenADR k označení dočasných změn v dostupnosti prostředků pro účast na událostech.
Předpoklad: Kritéria, která musí být splněna, aby se vlastník prostředku na straně poptávky mohl zaregistrovat do programu DR. To může zahrnovat dostupnost schůzky v intervalu nebo určitou minimální kapacitu prolévání
Primární ovladače: Primární motivace ze strany nástroje pro vytváření programu DR a vydávání událostí. Například „Snížení špičkové poptávky a přiměřenost zdrojů“

Programy - Jedná se o programy DR, do kterých jsou zdroje zapsány.
Popis programu: Popisný popis fungování programu. Část šablon programů DR definovaných v tomto dokumentu
Časový rámec programu: Čas roku nebo roční období během programu DR je obvykle aktivní

Ohodnoťte design: Specifické úpravy struktury sazeb nebo pobídky vyplácené za účelem motivace vlastníků zdrojů na straně poptávky k účasti v programu
Registrační služby: Služba používaná protokolem OpenADR k navázání základní interoperability mezi VTN a VEN ak ověření, že je VEN přidružen k účtu zákazníků služeb.
Reporting Services: Služba používaná OpenADR k tomu, aby VEN mohla poskytovat hlášení VEN. Program DR by měl specifikovat požadavky na podávání zpráv pro tento program.

Strana zdrojů - Toto je strana, která vlastní zdroje na straně poptávky, které mohou být zapsány do programů DR
Zdroj - Jedná se o entitu, která je zapsána v programech DR a je schopna poskytnout nějakou změnu jejich zátěžefile v reakci na příjem signálu DR z VTN.
Cílový zákazník: Profesionálfile zdrojů na straně poptávky, které se mohou zapsat do konkrétních programů DR, jako jsou obytné, průmyslové nebo možná založené na úrovni spotřeby elektrické energie.

Cílové zatížení: Zdroje na straně poptávky, jejichž zatížení by mělo být upraveno po přijetí a
VEN - Toto je virtuální koncový uzel OpenADR, který se používá k interakci s VTN.
VTN - Toto je virtuální horní uzel OpenADR, který se používá k interakci se zdroji zapsanými v programech DR.

Zkratky

BMS: Systém správy budov
C&I: Obchodní a průmyslové
Comm: Komunikace mezi dvěma entitami
DR: Odezva na poptávku
EMS: Systém řízení energie
OpenADR: Otevřená automatizovaná odezva na poptávku
Programy: Odkaz na programy odezvy na poptávku
VEN: Virtuální koncový uzel
VTN: Virtuální horní uzel

Typy programů odezvy na poptávku

Tento dokument obsahuje šablony pro programy DR uvedené níže.

1. Cena za kritický vrchol: Struktura sazeb a / nebo cen určená k podpoře snížené spotřeby během období vysokých velkoobchodních cen na trhu nebo systémových nepředvídaných událostí zavedením předem určené vysoké sazby nebo ceny na omezený počet dní nebo hodin.

2. Program nabízení kapacit: Program, který umožňuje zdroji poptávky na maloobchodních a velkoobchodních trzích nabízet snížení zátěže za cenu nebo určit, kolik zátěže je ochoten omezit za konkrétní cenu.

3. Rezidenční termostatový program / ovládání přímého zatížení: Aktivita reakce na poptávku, kterou sponzor programu v krátké době na dálku ovládá elektrické zařízení zákazníka (např. Klimatizaci). Tyto programy jsou primárně nabízeny rezidenčním nebo malým komerčním zákazníkům.

4. Program rychlého odeslání DR / doplňkových služeb: Program reakce na poptávku, který poskytuje pobídkové platby zákazníkům za reakci na zátěž během události reakce na nouzovou poptávku. Abnormální stav systému (napřampsystémová omezení a omezení místní kapacity), která vyžaduje automatické nebo okamžité ruční opatření k prevenci nebo omezení selhání přenosových zařízení nebo dodávek energie, které by mohly nepříznivě ovlivnit spolehlivost hromadné elektrické soustavy. Tyto typy programů mohou být někdy označovány jako „doplňkové služby“.

5. Program DR pro elektrická vozidla (EV): Činnost reakce na poptávku, při které jsou náklady na nabíjení elektrických vozidel upraveny tak, aby spotřebitelé posunuli vzorce spotřeby.

6. Program DR s distribuovanou energií (DER): Aktivita reakce na poptávku využívaná k hladké integraci distribuovaných energetických zdrojů do inteligentní sítě.

Scénáře nasazení

Způsob, jakým je program DR nasazen, je poněkud nezávislý na vlastnostech samotného programu DR. Následující diagramy ukazují celou řadu způsobů, jakými může být program DR nasazen. Následující část poskytuje křížový odkaz mezi scénáři nasazení a programy DR, s nimiž se s největší pravděpodobností budou používat.

Diagramy v této části ukazují vztahy mezi entitami v různých scénářích.

Přímo 1

Jedná se o jednoduchý scénář, ve kterém existuje přímý vztah mezi programovou stranou DR a stranou zdrojů. Strana zdrojů je zodpovědná za registraci svých vlastních zdrojů do programů DR a síťová infrastruktura interaguje přímo se zdroji prostřednictvím VEN, která sídlí v infrastruktuře na straně poptávky. Kromě toho je VEN ve vlastnictví strany zdrojů a je oddělená od zdrojů a jejich správců. Když je signál DR přijat VEN, obvykle to neimplementuje žádnou logiku řízení zátěže, ale jednoduše předává signály řídicím jednotkám zátěže, kteří provádějí příslušnou akci. PřampTento scénář by zahrnoval budovy C&I, které mohou instalovat bránu, která obsahuje OpenADR VEN, a když je touto bránou přijat signál, jednoduše ji převede do jiného protokolu a předá samotným kontrolérům zatížení.

Přímo 2

To je velmi podobné scénáři Direct 1. Hlavní rozdíl spočívá v tom, jak je VEN vytvořena a interakce s VTN usnadněna. VEN je vytvořen jako entita jako centralizovaný BMS, který může implementovat logiku DR a komunikovat s Compound Resource a jejich mnoha různými řadiči zatížení z centralizovanějšího umístění. Přampzahrnují velké budovy s BMS, které ovládají mnoho různých zátěží v budově (např. osvětlení, HVAC, průmyslové procesy atd.) až camppoužití, která mohou mít více zařízení s centralizovaným řídicím systémem.

Přímo 3

Tento scénář je velmi podobný scénáři Direct 1. Hlavní rozdíl spočívá v tom, že VEN je vytvořen přímo ve zdroji a jeho řadiči zatížení. V tomto případě jsou signály DR posílány přímo do zdroje a jeho řadiče zatížení. Do této kategorie spadá takzvaný scénář „ceny za zařízení“. Přampby zahrnovaly jakýkoli druh regulátoru zátěže, jako je HVAC (tj. termostat), který má vestavěný VEN, který je schopen interagovat přímo s entitami VTN na straně sítě.

Přímo 4

Toto je kombinace různých scénářů Direct 1 a Direct 2. Hlavním rozdílem je, že více VEN je spojeno s jedním složeným zdrojem, který se skládá z více aktiv s vlastními řadiči zatížení. Každý z řadičů zatížení, které obsahují Složený zdroj, může být spojen s jinou VEN. Všimněte si, že všechny VEN by byly pod kontrolou stejné strany zdrojů, která vlastní složený zdroj. Tento scénář existuje za účelem usnadnění infrastruktur na straně poptávky, které mají složené zdroje, ale nemají centralizovaný BMS jako scénář Direct 2. Přampmohou zahrnovat budovy s různými regulátory zatížení v každém patře, ale bez centralizovaného BMS nebo camppoužití s různými regulátory v každé budově, ale ne campnáš široký ovladač. Protože z pohledu strany DR Programu je do programu zapsán pouze jeden zdroj, když chce odeslat signál DR do zdroje, může jednoduše odeslat stejné signály každému z určených VEN, které byly přidruženy ke zdroji.

Facilitátor 1

V tomto scénáři existuje zprostředkovatel, který usnadňuje interakce mezi stranou programu DR a prostředky. Zprostředkující strana obvykle pracuje jménem Strany zdrojů, aby jim pomohla spravovat jejich zdroje. Strany zdrojů mají přímé vztahy se stranou programu DR a do programů DR registrují své vlastní zdroje. Tedy DR Program Party views každá strana zdroje jako samostatný zdroj a může s nimi jednotlivě komunikovat. Úlohou zprostředkující strany je jednat jako prostředník mezi všemi interakcemi souvisejícími s OpenADR, takže VEN je vytvořena v rámci zprostředkovatelské infrastruktury zprostředkovatele. Taková infrastruktura je často cloudová základna a je nabízena stranám zdrojů jako software jako služba (SaaS). Když je VEN přijímače přijat signál DR, může proběhnout řada různých akcí, včetně předání signálu DR příslušnému zdroji a případně implementace nějakého druhu logiky DR a odeslání příkazů pro řízení zatížení do každého řadiče načítání zdroje. Přampk tomuto scénáři patří:

Prodejci, kteří spravují zařízení pro velké obchodní řetězce, jako jsou velkoobchody.
Zprostředkovatelé průmyslové kontroly.
Společnosti poskytující energetické služby (ESCO)
Cloudové systémy pro správu zařízení a zařízení, jako jsou noví inteligentní komunikující prodejci termostatů.

Agregátor 1

Tento scénář je podobný scénáři Facilitator. Hlavní rozdíl spočívá v tom, že strana agregátoru má ve vztahu ke straně programu DR ve srovnání se stranami zdrojů. Agregátorová strana agreguje více aktiv zákazníků do jednoho zdroje, který zaregistruje do programů DR. Strana programu DR nemá viditelnost jednotlivých aktiv, která agregátor spravuje. Stejně jako Facilitátor má agregátor vlastní infrastrukturu, kde je vytvořena instance VEN. Rozdíl spočívá v tom, že když je přijat signál DR, odkazuje na jeden zdroj a agregátor implementuje nějaký druh logiky DR přes všechna aktiva v jejich portfoliu, aby dosáhl cílů specifikovaných v signálu DR.

Scénář nasazení a mapování programu DR

Níže uvedená tabulka uvádí, které scénáře nasazení jsou pro konkrétní program DR nejběžnější.

	Scénář nasazení
Šablona DR	Přímé 1, 2, 3, 4	Facilitátor 1	Agregátor 1
Program CPP	∆	∆
Program nabízení kapacit			∆
Obytný termostat Naprogramovat		∆
Rychlé odeslání DR			∆
Program DR pro elektrická vozidla (EV)	∆	∆
Program DR s distribuovanou energií (DER)	∆	∆

Výběr šablony programu DR

Následuje seznam otázek, které jsou relevantní pro jakýkoli nástroj, který se chystá implementovat nový program DR. To nemá být komplexní, ale představuje některé z relevantnějších otázek. Záměrem těchto otázek je pomoci vést obslužné programy k příslušné sadě šablon programů DR.

Otázka: Proč chcete dělat DR? Jaký stav sítě nebo provozní problém se snažíte zmírnit pomocí DR?

Toto je zdaleka nejdůležitější otázka a tvoří základ celkových požadavků a cílů, kterých má program DR dosáhnout. Odpověď na tuto otázku definuje, jak zatížení strany poptávky profile má být formován programem DR. Všechny další požadavky vyplývají z odpovědi na tuto otázku.

Snažíte se oholit vrcholy?
Chcete naplnit břicho kachny?
Snažíte se zajistit okamžitou cenu elektřiny?
Zajímá vás spolehlivost sítě?
Snažíte se zachovat aktiva mřížky?
Atd. Atd.

Níže uvedená tabulka poskytuje další kontext motivací, které stojí za vývojem programu DR

Spolehlivost a bezpečnost sítě	Frekvence a objemtage Stabilita
	Přiměřenost zdrojů
	Maximální kapacita
	RampIng
	Pohotovost
Nákup energie	Ceny na spotovém trhu
Nákup energie	Cenová arbitráž
Správa aktiv	Prevence škod
	Snížení údržby
	Doživotní prodloužení
Řízení kapacity	Ekonomické výhody
Řízení kapacity	Emergency Management
Environmentální	Negawatt
Environmentální	Čistá energie

Otázka: Existuje pro tento program již nějaký program DR nebo tarif?

Pravidla programu jsou často výslovně uvedena v tarifu.

Otázka: Na jaký segment trhu na straně poptávky cílíte s tímto programem?

To může pomoci určit cílení zdrojů v případě a typ signálu.

Obytný
Velká C&I
Malé C&I
Zemědělství
Vodní hospodářství
Elektrická vozidla
Atd, atd, atd

Otázka: Pokoušíte se cílit na konkrétní typy zátěží?

Termostaty
Elektrická vozidla
Ag čerpadla
atd.

Otázka: Jaký je váš model nasazení?

Odpověď na tuto otázku může ovlivnit, jak jsou zdroje definovány v rámci programu, a určit, jak jsou tyto zdroje v rámci událostí zacíleny.

Přímo k zákazníkům
Prostřednictvím zprostředkovatelů, jako jsou agregátoři nebo zprostředkovatelé
Zákazník odpovědný za pořízení a nasazení vlastního vybavení VEN?
atd.

Otázka: Na jaké úrovni konkrétnosti chcete interagovat se zátěží na straně poptávky?

Tato otázka poněkud souvisí s modelem nasazení a určuje, jak jsou prostředky v programu definovány a zacíleny. Je to jedna z nejdůležitějších a možná nejsložitějších otázek.

Interakce s každým jednotlivým zdrojem
Interakce prostřednictvím zprostředkovatele nebo agregátoru bez specifikace zdrojů za nimi
Interakce prostřednictvím zprostředkovatele nebo agregátoru A určete, které zdroje za nimi by měly být odeslány
Použijte umístění jako atribut k určení zdrojů
K určení prostředků použijte nějaký mechanismus seskupování definovaný pomocí nástroje
Zacilte na jednotlivá aktiva, jako jsou termostaty
Interakce bez jakýchkoli prostředků a pouze vysílání událostí DR
atd.

Otázka: Jaký vzor interakce chcete použít k ovlivnění zátěže vašich zákazníkůfiles?

Tato otázka určuje typ signálů DR, které budou odeslány účastníkům programu.

Pobídky (např. Dynamické stanovení cen)
Načíst odeslání (např. Doplňkové služby)
Přímé ovládání zátěže
Obecný signál události
atd.

Otázka: Jaké jsou obecné atributy plánování zdrojů programu?

Data a časy, kdy lze události vyvolat
Četnost událostí
Doba trvání událostí
Povolené latence pro šíření událostí
atd.

Otázka: Jak se určuje dostupnost zdrojů v programu?

Podle přísných pravidel programu
Jako součást procesu nominace nebo nabídkového řízení provedeného zdrojem
Je povoleno přihlášení / odhlášení?
atd.

Otázka: Jaký typ viditelnosti potřebujete pro výkon zdroje?

Jedná se o velmi širokou otázku, která určuje, jaký typ informací je získáván zpět ze zdrojů v programu DR. Obecně to určuje typ požadovaných zpráv.

Online / offline
Použití (aktuální a / nebo historické)
Potenciál odezvy na zatížení
Dostupnost zatížení
Stav zatížení / aktiva (aktuální a / nebo historický)
Atd. Atd.

Šablony programů na vyžádání

Kritický špičkový cenový program (CPP)

Charakteristiky programu CPP DR


Načíst Profile Objektivní	-Snížení maximální poptávky
Primární ovladače	-Snížené kapitálové výdaje a snížené náklady na energii
Popis programu	Pokud společnosti sledují nebo očekávají vysoké velkoobchodní ceny na trhu nebo nouzové podmínky energetického systému, mohou volat kritické události během stanoveného časového období (např. 3:6 - XNUMX:XNUMX v horkém letním pracovním dni), cena elektřiny během těchto časových období je podstatně zvednutý.
Pobídka pro zákazníka	Zákazníkům může být nabídnuta zlevněná cena energie v době mimo špičku jako pobídka k účasti v programu.
Ohodnoťte design	CPP je cenový program, jehož sazby rostou během kritických špiček ve spotřebě energie. Sazby CPP jsou obvykle základní sazby sčítače nebo multiplikátoru na ploché, odstupňované nebo TOU.
Cílový zákazník	- Rezidenční nebo C&I
Cílové zatížení	-Žádný
Předpoklad	- Zákazník musí mít intervalové měření Zákazníci společnosti C&I možná budou muset splnit kritérium poptávky
Časový rámec programu	-Typicky zahrnuje měsíce v roce, kdy dochází ke špičkové spotřebě energie, i když v některých případech může být celoroční.
Omezení událostí	-Typicky od pondělí do pátku, s výjimkou svátků, s po sobě následujícími denními událostmi, které jsou obvykle povoleny
Dny událostí	-Typicky 9 až 15 ročně
Trvání události	-Typicky během pevného časového rámce pro všechny události v rozmezí od 4 do 6 hodin během nejvyšší doby spotřeby energie dne.
Oznámení	-Typicky den dopředu
Optické chování	- Zákazníci obvykle nejsou povinni účastnit se událostí
Osvědčení Události	-Typicky žádný

Charakteristika OpenADR pro programy CPP

Signály událostí	–JEDNODUCHÝ signál s úrovněmi 1 až 3 mapovaný na cenový dopad události CPP. Pokud má program CPP jednu cenovou složku, měl by být mapován na úroveň 1. U programů CPP s více cenovými složkami by měla být nejmenší cenová složka mapována na úroveň 1, přičemž ostatní cenové složky by měly být ve zvyšující se míře mapovány na úrovně 2 a 3. dopadu na ceny. -Pokud nasazení podporuje B profile VENS, kromě JEDNODUCHÉHO signálu může být zahrnut i signál ELECTRICITY_PRICE v užitečném zatížení s typem priceRelative, priceAbsolute nebo priceMultiplier v závislosti na povaze programu. Viz příloha A, napřamples.
Optické odpovědi	-VTN odesílající události by měl nastavit prvek oadrResponseRequired na „always“vyžadující, aby VEN reagoval optIn nebo optOut - Jelikož účast v programu CPP představuje cvičení „s nejlepším úsilím“, nemá optIn nebo optOut žádný formální význam nad rámec zdvořilostní dostupnosti úmyslu účastnit se. To doporučujeme VEN reagují s optIn, pokud zákazník neprovedl nějaké konkrétní přepsání akce. - Náklad oadrCreateOpt by se obvykle nepoužíval ke kvalifikaci zdrojů účastnících se událostí.
Deskriptor události	-Událost priorita by měla být nastavena na 1 pokud pravidla programu nebo konfigurace VTN nestanoví jinak –Testovací události se obvykle nepoužívají s programy CPP. Pokud jsou však povoleny, měl by být prvek testEvent nastaven na „true“, aby indikoval testovací událost. Pokud je v tomto prvku vyžadována další parametrizovaná informace, může následovat „true“ oddělená mezerou s těmito dalšími informacemi.
Aktivní období události	– eRampUp, eiRecovery, prvky tolerance se obvykle nepoužívají
Základní linie	–Základní úrovně nejsou obvykle zahrnuty v užitečném zatížení události
Cílení na události	Programy CPP obvykle nerozlišují mezi zdroji pro daného zákazníka. Cílení obvykle určuje venID, což znamená, že by se měly účastnit všechny zdroje spojené s VEN, nebo seznam všech ID prostředků spojené s VEN.
Reporting Services	–Telemetrické hlášení se obvykle nepoužívá protože to není u programů CPP absolutně nutné. Viz příloha B, napřampsoubory zpráv od obslužných pilotů, které by mohly být použitelné pro tento typ programu.

Volit služby	–Využívání služby Opt komunikovat dočasné plány dostupnosti obvykle by se nepoužíval jako součást programu CPP. Některá nasazení by však mohla tuto službu použít k uchování dostupných dnů událostí pro zákazníky, kteří označují nedostatečnou dostupnost.
Registrační služby	Intervaly dotazování požadované VTN pro typické denní CPP programy nemusí být častější než jednou za hodinu. Použití dotazování k detekci srdečního rytmu však může vyžadovat častější dotazování.

Program nabízení kapacit

Nabízení kapacity DR Charakteristiky programu

Načíst Profile Objektivní	- Špičkové snížení poptávky a přiměřenost zdrojů
Primární ovladače	-Snížené kapitálové výdaje a snížené náklady na energii
Popis programu	Program nabízení kapacity využívá ISO / utilities k získání předem určené kapacity pro uvolnění zátěže od agregátorů nebo samo agregovaných zákazníků. Tuto předem přidělenou kapacitu pro uvolnění zátěže využívají ISO / utility, když sledují nebo očekávají vysoké velkoobchodní tržní ceny, nouzové podmínky energetického systému nebo jako součást běžného využití energetických zdrojů voláním událostí DR během stanoveného časového období. Všimněte si, že každý agregátor je obvykle zodpovědný za navrhování vlastního programu reakce na poptávku, jakož i získávání zákazníků a upozornění na události, aby splnil kapacitní závazky přijaté jako součást tohoto programu.
Pobídka pro zákazníka	Agregátory / zákazníci dostávají dva typy pobídek. Nejprve dostanou platbu za kapacitu pro zadržení konkrétního množství kapacity přístřešku dostupné pro události DR během budoucího časového okna. Zadruhé, pokud je událost vyvolána během budoucího časového okna, může být provedena platba energie za odlehčení zátěže po celou dobu trvání události.
Ohodnoťte design	Účastníci programu učiní nabídku „nominaci kapacity“, která udává kapacitu prolévané kapacity, kterou jsou ochotni držet jako dostupnou během budoucího časového okna. Nabídka může také zahrnovat pobídku, kterou je agregátor / zákazník ochoten přijmout pro snížení zatížení pod základní hodnotu. Na trzích s nástroji je závazek kapacity obvykle pro příští kalendářní měsíc, ačkoli na trzích ISO se používají mnohem delší časové rámce. V rámci nominace kapacity si zákazník může vybrat mezi řadou charakteristik, včetně oznámení o dni dopředu nebo dne oznámení a o délce trvání události (například 1–4 hodiny, 2–6 hodin,…). Platba kapacity za tuto předběžnou vazbu je provedena zákazníkovi, i když během časového okna nedojde k žádným událostem. Pokud je událost volána během časového okna, může zákazník obdržet platbu energie za přístřešek ve vztahu k základní linii, ale mohou být uplatněny pokuty, pokud je v době volání události dodána menší než předem přidělená kapacita přístřešku.
Cílový zákazník	- Agregátoři a samostatně agregovaní zákazníci C&I
Cílové zatížení	- Jakékoli

Předpoklad	- Zákazník musí mít intervalové měření Zákazníci společnosti C&I možná budou muset splnit kritérium poptávky nebo nabídky
Časový rámec programu	-Kdykoli
Omezení událostí	-Typicky od pondělí do pátku, s výjimkou svátků, s po sobě následujícími denními událostmi, které jsou obvykle povoleny
Dny událostí	-Typicky maximálně 30 hodin měsíčně
Trvání události	-Typicky během pevného časového okna pro všechny události během nejvyšší doby spotřeby energie dne.). Délka akce se liší podle závazku kapacity zákazníka s preferencemi od 1 do 8 hodin nebo podle specifikace programu
Oznámení	-Den dopředu nebo den v závislosti na preferencích závazků zákaznických kapacit nebo designu programu
Optické chování	- Zákazníci se typicky přihlásí k událostem, protože mají předem přidělenou kapacitu pro uvolnění zátěže.
Osvědčení Události	-Typicky dva za rok (test)

Charakteristiky OpenADR pro programy nabízení kapacity

Signály událostí	–JEDNODUCHÝ signál s úrovněmi 1 až 3 mapovaný na množství prošlé zátěže. Pokud program podporuje pouze jednu úroveň přístřešku zátěže, která by měla být mapována na úroveň 1. U programů s více úrovněmi přístřešku zátěže by měla být nejmenší změna z normálního provozu mapována na úroveň 1, přičemž hodnoty přístřešku jsou mapovány na úrovně 2 a 3 ve zvyšujícím se stupni odlehčení. -Pokud nasazení podporuje B profile VENS, kromě SIMPLE signálu může být zahrnut signál BID_LOAD a / nebo BID_PRICE v užitečném zatížení s typy signálu požadované hodnoty a ceny a jednotek powerReal a currencyPerKW. Hodnota BID_LOAD by odrážela požadovanou ztrátu zatížení na nabídku kapacity agregátorem / zákazníkem a BID_PRICE by odrážela motivační nabídku agregátoru / zákazníka. Viz příloha A, napřamples.
Optické odpovědi	-VTN odesílající události by měl nastavit prvek oadrResponseRequired na „always“vyžadující, aby VEN reagoval optIn nebo optOut -Jak agregátoři / zákazníci mají předem vyhrazenou kapacitu VEN by měly reagovat optIn. V reakci na událost může být zasláno odhlášení, ale jedná se o informativní informaci o dostupnosti, nikoli o formální odhlášení z akce. - Užitečné zatížení oadrCreateOpt by se obvykle nepoužívalo kvalifikovat prostředky účastnící se událostí jako obvykle zatížení je jedna agregovaná entita.
Deskriptor události	-Událost priorita by měla být nastavena na 1 pokud pravidla programu nebo konfigurace VTN nestanoví jinak –Lze použít testovací události s programy nabídek kapacity. Pokud jsou povoleny, měl by být prvek testEvent nastaven na „true“, aby indikoval testovací událost. Pokud je v tomto prvku vyžadována další parametrizovaná informace, může následovat „true“ oddělená mezerou s těmito dalšími informacemi.
Aktivní období události	– eRampUp, eiRecovery, prvky tolerance se obvykle nepoužívají
Základní linie	–Základní úrovně nejsou obvykle zahrnuty v užitečném zatížení události protože tato data obvykle nejsou k dispozici v době zahájení události. Pomohly by však jak nástroje, tak agregátory/zákazníci view zahrnutí základních informací do událostí jako užitečné.
Cílení na události	- Programy nabízení cen za kapacitu obvykle nerozlišují mezi zdroji pro daného zákazníka. Cílení obvykle určuje venID, což znamená, že by se měly účastnit všechny zdroje spojené s VEN, nebo obsahuje ID prostředku představující agregované zatížení spojené s VEN.
Reporting Services	Programy nabízení kapacit ISO obvykle vyžadují TELEMETRY_USAGE zprávy s datovými body powerReal. Viz examples v příloze A. Telemetrické hlášení pro nabízení kapacity kapacity se obvykle nevyžaduje. Hlášení telemetrie vyžaduje B profile VEN. Viz příloha B, napřampsoubory zpráv od obslužných pilotů, které by mohly být použitelné pro tento typ programu.
Volit služby	–Využívání služby Opt komunikovat dočasné plány dostupnosti obvykle by se nepoužíval jako součást programu nabízení kapacit, protože zákazníci předem potvrdili svou dostupnost. Tato služba však může být užitečná jako neformální způsob, jak mohou účastníci upozornit na nedostatečnou dostupnost z polehčujících důvodů, jako je porucha zařízení.
Registrační služby	Intervaly dotazování požadované VTN pro typické denní programy nemusí být častější než jednou za hodinu. Použití dotazování k detekci srdečního rytmu nebo denních programů však může vyžadovat častější dotazování.

Program bytových termostatů

Tento program představuje přímé řízení zátěže (DLC), kde signál odezvy na vyžádání přímo upravuje chování zdrojů uvolňování zátěže, aniž by mezi přijetím signálu a konkrétní akcí uvolnění zátěže byla provedena vrstva abstrakce.

Vlastnosti programového vybavení obytného termostatu DR

Načíst Profile Objektivní	-Snížení maximální poptávky
Primární ovladače	-Snížené kapitálové výdaje a snížené náklady na energii
Popis programu	-Když společnosti sledují nebo očekávají vysoké velkoobchodní ceny na trhu nebo nouzové podmínky energetického systému, mohou zahájit událost, která mění chování programovatelného komunikujícího termostatu (PCT) zákazníka po stanovenou dobu (např. 3:6 - XNUMX:XNUMX za horkého počasí) letní den) za účelem snížení spotřeby energie. -Změnou chování PCT v reakci na událost může být jednoduchá změna nastavené teploty po dobu trvání události nebo složitější sada změn, včetně předchlazení, které minimalizují dopad události na pohodlí zákazníka úroveň.
Pobídka pro zákazníka	- Pobídky mají dvě obecné formy. Za prvé může být zákazníkům poskytnuta bezplatná PCT nebo nabídnuta sleva / sleva na PCT zakoupené zákazníkem jako pobídka k registraci do programu DR. Zadruhé, zákazníci mohou obdržet průběžné roční stipendium pro pokračování v registraci do programu. Méně časté by byly trvalé pobídky vyplácené zákazníkům na základě skutečného snížení energie během událostí.
Ohodnoťte design	- Především pobídkový program, kde zákazníci dostávají zlevněné nebo bezplatné PCT za registraci do programu DR. Některé programy mohou platit pravidelné stipendium nebo pobídkové platby na základě snížení energie během událostí.
Cílový zákazník	-Obytný
Cílové zatížení	-VVK
Předpoklad	-Typicky žádný, protože zákazníci obdrží PCT jako součást registrace do programu
Časový rámec programu	-Typicky zahrnuje měsíce v roce, kdy dochází ke špičkové spotřebě energie, i když v některých případech může být celoroční.
Omezení událostí	-Typicky od pondělí do pátku, s výjimkou svátků, s po sobě následujícími denními událostmi, které jsou obvykle povoleny.
Dny událostí	-Typicky 9 až 15 ročně
Trvání události	-Události se mohou objevit kdykoli, s dobou trvání od 2 do 4 hodin, i když k událostem obvykle dochází během nejvyšší doby spotřeby energie dne.
Oznámení	-Typicky den dopředu, i když u některých programů může být doba oznámení kratší než 10 minut.
Optické chování	- Zákazníci nejsou povinni účastnit se událostí, budou však automaticky přihlášeni k událostem, pokud nepřijmou opatření k potlačení události nebo k ruční úpravě teploty během akce.
Osvědčení Události	-Typicky žádný

Charakteristika OpenADR pro programy obytných termostatů

Signály událostí	–JEDNODUCHÝ signál s úrovněmi 1 až 3 mapovanými na změnu offsetů žádaných hodnot teploty PCT nebo procenta termostatického cyklovánítage . Pokud má program bytového termostatu jednu složku offset / cyklování, měl by být mapován na úroveň 1. U programů s více komponentami offset / cyklování by měla být nejmenší změna oproti normálnímu provozu mapována na úroveň 1 s ostatními hodnotami offset / cyklování mapováno na úrovně 2 a 3 ve zvyšující se míře dopadu zatížení. -Pokud nasazení podporuje B profile VENS, kromě JEDNODUCHÉHO signálu může být zahrnut i signál LOAD_CONTROL v užitečném zatížení s typem x-loadControlLevelOffset nebo x-loadControlCapacity pro zadání požadovaného posunu žádané teploty nebo procenta termostatického cyklovánítage resp. Doporučuje se, aby a typ jednotky „teplota“ použitý v užitečných nákladech využívajících x-loadControlLevelOffset signalType pro označení Celsia nebo Fahrenheita pro posun. Viz příloha A, napřamples.
Optické odpovědi	-VTN odesílající události by měl nastavit prvek oadrResponseRequired na „always“vyžadující, aby VEN reagoval optIn nebo optOut – VEN by měla reagovat s optIn, pokud zákazník neprovedl nějaké konkrétní přepsání akce. - Užitečné zatížení oadrCreateOpt mohou používat VEN kvalifikovat účast zdrojů na akci. Událost může například cílit na ID prostředku dvou termostatů, které řídí samostatné systémy HVAC. Pokud se zákazník rozhodne, že se události může účastnit pouze jeden ze systémů HVAC, bylo by to oznámeno VTN pomocí užitečného zatížení oadrCreateOpt. Všimněte si toho, že užitečné zatížení oadrCreateOpt podporuje pouze B profile VEN
Deskriptor události	-Událost priorita by měla být nastavena na 1 pokud pravidla programu nebo konfigurace VTN nestanoví jinak –Testovací události se obvykle nepoužívají s programy Rezidenční termostat. Pokud jsou však povoleny, měl by být prvek testEvent nastaven na „true“, aby indikoval událost testu. Pokud je v tomto prvku vyžadována další parametrizovaná informace, může následovat „true“ oddělená mezerou s těmito dalšími informacemi.
Aktivní období události	–Randomizace se obvykle používá pro události termostatu v domácnosti s použitím prvku tolerance – eRampPrvky Up a eiRecovery se obvykle nepoužívají
Základní linie	–Základní úrovně nejsou obvykle zahrnuty v užitečném zatížení události
Cílení na události	- Programy Rezidenční termostat se zaměřují na zdroje HVAC řízené PCT. Cílení obvykle určuje ID prostředku systémů HVAC (tj. termostatu) spojených s VEN nebo venID s cílem třídy zařízení signalizace události nastaveným na Termostat
Reporting Services	–Telemetrické hlášení se obvykle nepoužívá protože to není absolutně nutné pro programy bytových termostatů Viz příloha B, napřampsoubory zpráv od obslužných pilotů, které by mohly být použitelné pro tento typ programu.
Volit služby	–Využívání služby Opt komunikovat dočasné plány dostupnosti obvykle by se nepoužíval jako součást programu CPP.
Registrační služby	Intervaly dotazování požadované VTN pro typické denní programy obytných termostatů nemusí být častější než jednou za hodinu. Použití dotazování k detekci srdečního rytmu však může vyžadovat častější dotazování, stejně jako programy bytových termostatů s podstatně kratšími časy oznámení.

Rychlé odeslání DR

Charakteristiky rychlého dispečerského programu

Načíst Profile Objektivní	-Dispečink zdrojů k dosažení reakce na zátěž v „reálném čase“
Primární ovladače	- Spolehlivost mřížky a podpůrné služby
Popis programu	Fast DR je používán ISO / obslužnými programy k získání předem určené reakce na zátěž v „reálném čase“. Tato předem určená reakce na zátěž je využívána ISO / utilities, když sledují podmínky, které vyžadují okamžité opatření k udržení stability a integrity sítě. Real-time znamená, že prostředky se obvykle odesílají s latencí v rozmezí od 10 minut pro prostředky, které se používají jako rezervy, do 2 sekund pro prostředky, které se používají pro účely regulace. Velikost odezvy na zatížení musí být dostatečně velká, aby se změnil stav zmírnění stavu mřížky, a proto jsou zdroje obvykle velmi velké a často jsou spravovány agregátory jako součást agregovaného prostředku. Minimální velikosti pro odezvu na zátěž pro prostředek, který se kvalifikuje k účasti na podpůrných službách, jsou obvykle kolem 500 kW, ale u některých programů mohou být až 100 kW. Všimněte si, že pokud je prostředek používán jako rezerva, bude obvykle vyvolán ke snížení (tj. Zbavení se) zátěže, ale pokud je používán pro regulační účely, může být odeslán ke zvýšení nebo snížení zátěže.
Pobídka pro zákazníka	Agregátory / zákazníci obvykle dostávají dva typy pobídek. Nejprve obdrží platbu za potvrzení a zpřístupnění konkrétního množství odpovědi na zátěž dostupné pro události DR během budoucího časového okna. Výši odezvy na zatížení, časové okno dostupnosti a částku k zaplacení obvykle stanoví agregátor / zákazník. Zadruhé, je-li událost volána v budoucím časovém okně, je platba založena na množství reakce na zátěž během trvání události.
Ohodnoťte design	Účastníci programu předloží nabídku označující reakci na zatížení, kterou jsou ochotni zpřístupnit během budoucího časového okna. Nabídka obvykle zahrnuje také platbu, kterou je agregátor / zákazník ochoten přijmout za reakci na zatížení. Na trzích s nástroji/ISO je nabídka obvykle podána buď den předem, nebo v den časového období, na které je závazek učiněn. Jako součást jejich kvalifikace a registrace na trzích jsou se zdrojem spojeny různé parametry balíčků výkonu, jako je ramp rychlost a minimální a maximální provozní limity. Tyto parametry určují, jak bude odeslán. Pokud je nabídka účastníka přijata, může být zákazníkovi provedena platba za jeho předběžný závazek, i když během časového okna nejsou vyvolány žádné události. Pokud je během časového okna vyvolána událost, může zákazník obdržet další platby za svůj výkon během události. Takové platby založené na výkonu mohou být založeny na řadě faktorů, včetně množství energie, energie, toho, jak přesně zdroj dodržuje pokyny pro odeslání, a platby za „ujeté kilometry“, které odrážejí, kolik jejich zátěž profile bylo nutné během akce změnit. Některé z těchto parametrů, jako je energie a výkon, mohou být s ohledem na základní linii.
Cílový zákazník	- Agregátoři a autoagregovaní zákazníci C&I
Cílové zatížení	- Ti, kteří mohou reagovat na odeslání v reálném čase.

Předpoklad	- Zákazník musí mít intervalové měření -Musí splňovat minimální požadavky na velikost pro odezvu na zatížení -Musí být schopni reagovat na odeslání v reálném čase -Typicky musí dodávat telemetrii v reálném čase, která ukazuje aktuální odezvu na zatížení
Časový rámec programu	-Kdykoli
Omezení událostí	-žádný
Dny událostí	-žádný
Trvání události	-Typicky krátký (méně než 30 minut), ale v žádném případě nikdy nepřekročí časové okno, které účastník zpřístupnil, když podal nabídku.
Oznámení	-žádný
Optické chování	- Zákazníci jsou ve výchozím nastavení přihlášeni k událostem, protože mají předem zadanou odpověď na zatížení
Osvědčení Události	-Obvykle jeden za rok (test)

Charakteristiky OpenADR pro programy nabízení kapacity

Signály událostí	–JEDNODUCHÝ signál s úrovněmi 1 až 3 mapovanými na míru odezvy na zátěž. Pokud program podporuje pouze jednu úroveň odezvy na zátěž, měla by být mapována na úroveň 1. U programů s více úrovněmi odezvy na zátěž by měla být nejmenší změna od normálního provozu mapována na úroveň 1, s hodnotami proložení zátěže na úrovně 2 a 3 při zvyšování stupně odezvy na zátěž. -Pokud nasazení podporuje B profile VENS, kromě JEDNODUCHÉHO signálu může být zahrnuto i odeslání ve formě signálu LOAD_DISPATCH v užitečném zatížení s typy signálu požadované hodnoty nebo delty a jednotky powerReal. Tento signál představuje požadovaný „pracovní bod“ zátěže a lze jej vyjádřit buď jako absolutní množství mW (tj. Požadovaná hodnota), nebo jako relativní počet mW (tj. Delta) od aktuálního provozního bodu zdrojů. Viz příloha A, napřamples.
Optické odpovědi	-VTN odesílající události by měl nastavit prvek oadrResponseRequired na „always“vyžadující, aby VEN reagoval optIn nebo optOut -Jak agregátoři / zákazníci mají předem vyhrazenou kapacitu VEN by měly reagovat optIn. V reakci na událost může být zasláno odhlášení, ale jedná se o informativní informaci o dostupnosti, nikoli o formální odhlášení z akce. - Užitečné zatížení oadrCreateOpt by se obvykle nepoužívalo kvalifikovat prostředky účastnící se událostí jako obvykle zatížení je jedna agregovaná entita.
Deskriptor události	-Událost priorita by měla být nastavena na 1 pokud pravidla programu nebo konfigurace VTN nestanoví jinak –Lze použít testovací události, zejména při registraci a kvalifikaci zdroje. Pokud jsou povoleny, měl by být prvek testEvent nastaven na „true“, aby indikoval testovací událost. Pokud je v tomto prvku vyžadována další parametrizovaná informace, může následovat „true“ oddělená mezerou s těmito dalšími informacemi.
Aktivní období události	– Toleranční prvky se nepoužívají. EiRampObdobí nahoru a eiRecovery jsou obvykle součástí parametrů zdroje, když se registrují a mohou být použity. Vzhledem k povaze zásilek mohou být otevřené a pro událost tedy nemusí být žádný čas ukončení.
Základní linie	–Základní úrovně nejsou obvykle zahrnuty v užitečném zatížení události protože tato data obvykle nejsou k dispozici v době zahájení události. Pomohly by však jak nástroje, tak agregátory/zákazníci view zahrnutí základních informací do událostí jako užitečné.
Cílení na události	- Programy nabízení cen za kapacitu obvykle nerozlišují mezi zdroji pro daného zákazníka. Cílení obvykle určuje venID, což znamená, že by se měly účastnit všechny zdroje spojené s VEN, nebo obsahuje ID prostředku představující agregované zatížení spojené s VEN.
Reporting Services	Rychlé programy DR obvykle vyžadují TELEMETRY_USAGE zprávy s datovými body powerReal. Zpráva o použití zobrazuje aktuální provozní bod prostředků a používá ji Utility / ISO k určení, jak přesně prostředek sleduje odesílací instrukci. V některých případech může telemetrie zahrnovat další datové body, jako napřtagOdečty a stav nabití (tj. energie) v případě, že prostředky jsou nějakou formou úložiště. V některých případech může být frekvence hlášení až každé 2 sekundy. Hlášení telemetrie vyžaduje B profile VEN. Viz příloha A, napřamples. Viz také příloha B, napřampsoubory zpráv od obslužných pilotů, které by mohly být použitelné pro tento typ programu.
Volit služby	–Použití služby Opt ke komunikaci dočasné dostupnosti jízdní řády obvykle by se nepoužíval protože zákazníci předem potvrdili svou dostupnost. Tato služba však může být užitečná jako neformální způsob, jak mohou účastníci upozornit na nedostatečnou dostupnost z polehčujících důvodů, jako je porucha zařízení.
Registrační služby	Z důvodu požadavků na nízkou latenci odeslání v reálném čase používají se pouze vzory interakce push.

Program doby používání obytných elektrických vozidel (EV) (TOU)

Charakteristiky rezidenčního programu EV TOU

Načíst Profile Objektivní	Struktura sazeb, pomocí které se upravují náklady na nabíjení elektrických vozidel tak, aby spotřebitelé posunuli vzorce spotřeby.
Primární ovladače	Spotřeba energie na bydlení vrcholí večer. Vzhledem k tomu, že nabíjení EV trvá 4 až 8 hodin, lze posunutí špiček zatížení odložit o několik hodin.
Popis programu	Zákazníci, kteří mají elektrické vozidlo, se mohou zaregistrovat k sazbě doby používání elektrického vozidla (EV-TOU) a získat nižší sazby za nabíjení svého vozidla mimo špičku, například mezi půlnocí a 5:XNUMX, sazby EV-TOU jsou nabízeny k povzbuzení zákazníků k omezení denního používání elektřiny, když je poptávka po elektřině nejvyšší.
Pobídka pro zákazníka	Méně nákladné nabíjení EV.
Ohodnoťte design	TOU se středním vrcholem, ranním a večerním středním vrcholem a mimo špičku od 12:5 do XNUMX:XNUMX
Cílový zákazník	Majitel EV se zátěží profile který vrcholí večer.
Cílové zatížení	Nabíječky EV
Předpoklad	Zákazník musí mít inteligentní měřič a EV
Časový rámec programu	Celý rok
Omezení událostí	Žádný
Dny událostí	Každý den nebo pouze ve všední dny
Trvání události	5-8 hodin
Oznámení	Zákazník je informován o cenových úrovních svých měsíčních účtů a VTN odesílají signály událostí den předem.
Optické chování	Poplatníci mohou svůj tarif změnit, jak by to obvykle udělali s nástrojem.
Osvědčení Události

Charakteristika OpenADR pro rezidenční programy EV TOU

Signály událostí	Signály ELECTRICITY_PRICE se skutečnými cenovými úrovněmi, stejně jako JEDNODUCHÉ signály umožňující účast 2.0 VEN Viz příloha A, napřamples.
Optické odpovědi	Vždy se přihlaste pomocí VEN
Deskriptor události	Jedna událost týdně s intervaly událostí pro každou cenovou úroveň
Aktivní období události	Mělo by být použito alespoň 24hodinové oznámení. Každý interval události by měl zachytit úroveň rychlosti TOU
Základní linie	N/A
Cílení na události	Není nutné žádné pokročilé cílení, pouze cílení na úrovni VEN.
Reporting Services	Není třeba hlášení, všechna data mohou pocházet z měřiče. Viz příloha B, napřampsoubory zpráv od obslužných pilotů, které by mohly být použitelné pro tento typ programu.
Volit služby	Služby opt by nebyly relevantní pro tento typ programu.
Registrační služby	Spotřebitelé by předem poskytli své VEN nástroji pro příjem cenových signálů.

Cenový program pro elektrická vozidla na veřejných stanicích (EV) v reálném čase

Charakteristika veřejné stanice EV RTP

Načíst Profile Objektivní	Aktivita reakce na poptávku, při které se upravují náklady na nabíjení elektrických vozidel tak, aby se realita špičkových cen přesunula na spotřebitele.
Primární ovladače	Cena elektřiny je proměnlivá v průběhu dne. Cílem tohoto programu je efektivnější přizpůsobení ceny nabíjení nákladům na elektřinu.
Popis programu	Veřejné nabíječky mohou existovat na pracovištích, na veřejných parkovištích a v maloobchodech. Tento program přenáší ceny v reálném čase na potenciální nabíječky před připojením, aby mohli učinit informované rozhodnutí o tom, zda mají nebo nemají nabíjet své auto.
Pobídka pro zákazníka	Méně nákladné nabíjení v době mimo špičku.
Ohodnoťte design	Ceny se mohou změniturly, ale jakmile se zákazník rozhodne připojit svůj vůz, sazba se nastaví na dobu nabíjení.
Cílový zákazník	Kdokoli s EV, který potřebuje nabíjet, když není doma.
Cílové zatížení	Veřejné nabíječky EV
Předpoklad	Nabíječky EV musí být připojeny k internetu a certifikovány OpenADR2.0b nebo připojeny k bráně OpenADR2.0b VEN.
Časový rámec programu	Celý rok
Omezení událostí	Žádný
Dny událostí	Každý den nebo pouze ve všední dny
Trvání události	1 hodinu nebo déle
Oznámení	Zákazník je informován o převládající sazbě, když se rozhodne zapojit své auto.
Optické chování	Zákazníci se mohou odhlásit tím, že se rozhodnou neúčtovat poplatky.
Osvědčení Události

Charakteristika OpenADR pro programy veřejné stanice EV RTP

Signály událostí	Signály ELECTRICITY_PRICE s cenami. Viz příloha A, napřamples.
Optické odpovědi	Vždy se přihlaste pomocí VEN
Deskriptor události	Události musí být souvislé a obsahovat jeden interval.
Aktivní období události	Mělo by být použito alespoň 1hodinové oznámení, avšak obslužné programy se mohou rozhodnout použít denní oznámení.
Základní linie	N/A
Cílení na události	Není nutné žádné pokročilé cílení, ale cílení lze použít k zasílání cen konkrétním transformátorům, napáječům nebo geografickým oblastem.
Reporting Services	Není třeba hlášení, ale lze je použít, pokud je to požadováno. Viz příloha B, napřampsoubory zpráv od obslužných pilotů, které by mohly být použitelné pro tento typ programu.
Volit služby	Služby opt by nebyly relevantní pro tento typ programu.
Registrační služby	Prodejce nabíjecích stanic by opatřil svá zařízení pomocí VTN utility.

Program DR s distribuovanou energií (DER)

Následující popis programu je hypotetický a je založen na výzkumné práci (referenční Rishova práce) popisující, jak mohou zákazníci veřejných služeb využívat úložné prostředky DER k účasti na programech DR, jako jsou programy cen v reálném čase (RTP).

Charakteristika programu Distribuované energetické zdroje (DER)

Načíst Profile Objektivní	Činnost reakce na poptávku využívaná k hladké integraci distribuovaných zdrojů energie do inteligentní sítě.
Primární ovladače	-Snížené kapitálové výdaje a snížené náklady na energii
Popis programu	Zákazníci se zdroji DER, kteří mohou sklízet energii a ukládat ji, mohou minimalizovat náklady na nákup elektřiny ze sítě během období vysokých cen tím, že nejprve využijí uložené zdroje energie a poté implementují strategie odlehčení
Pobídka pro zákazníka	Schopnost kontrolovat náklady v době vysokých cen elektřiny využitím akumulované energie vyrobené z FV nebo jinými prostředky a implementací strategií snižování zátěže
Ohodnoťte design	Sazby elektřiny se liší podle velkoobchodních tržních cen nebo tarifu, který se liší v závislosti na denní době, ročním období nebo teplotě
Cílový zákazník	Zákazníci se zdroji pro skladování energie
Cílové zatížení	Žádný
Předpoklad	Zdroje pro skladování energie
Časový rámec programu	Kdykoli
Omezení událostí	Žádný
Dny událostí	Každý den
Trvání události	24 hodin
Oznámení	Den před námi
Optické chování	N / A - program s nejlepším úsilím
Osvědčení Události	Žádný

Charakteristika OpenADR pro distribuované energetické zdroje (DER)

Signály událostí	Signály ELECTRICITY_PRICE s 24 hodinovými intervaly cen po dobu 24 hodin. Tento signál bude vyžadovat B profile. Tento program se nehodí k JEDNODUCHÉ signalizaci pro profesionálafile VEN. Viz příloha A, napřamples.
Optické odpovědi	-VTN odesílající události by měl nastavit prvek oadrResponseRequired na „nikdy“, brání VEN v reakci.
Deskriptor události	-Událost priorita by měla být nastavena na 1 pokud pravidla programu nebo konfigurace VTN nestanoví jinak
Aktivní období události	24 hodin s hodinovými intervaly s oznámením o dni dopředu
Základní linie	N/A
Cílení na události	Kromě venID není vyžadováno žádné pokročilé cílení
Reporting Services	Není třeba hlášení Viz příloha B, napřampsoubory zpráv od obslužných pilotů, které by mohly být použitelné pro tento typ programu.
Volit služby	Nepoužito
Registrační služby	Intervaly dotazování požadované VTN pro typické denní t programy nemusí být častější než jednou za hodinu. Použití dotazování k detekci srdečního rytmu však může vyžadovat častější dotazování, stejně jako programy bytových termostatů s podstatně kratšími časy oznámení.

– Sampšablony dat a užitečného zatížení

Následující tabulky a užitečné zatížení XML samples poskytne implementátorům hmatatelné exampjak by měly být implementovány šablony DR v tomto dokumentu. V datové části ex se používají následující předpony oboru názvůamples:

xmlns: oadr = ”http://openadr.org/oadr-2.0b/2012/07“
xmlns: pyld = ”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
xmlns: ei = ”http://docs.oasis-open.org/ns/energyinterop/201110 ″
xmlns: scale = ”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
xmlns: emix = ”http://docs.oasis-open.org/ns/emix/2011/06 ″
xmlns: strm = ”urn: ietf: params: xml: ns: icalendar-2.0: stream”
xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0 ″
xmlns: power = ”http://docs.oasis-open.org/ns/emix/2011/06/power”

Kritický špičkový cenový program (CPP)

Scénář CPP 1 - Jednoduchý případ použití, A nebo B Profile

Událost
- Oznámení: Den před akcí
- Začátek: 1:XNUMX
- Doba trvání: 4 hodiny
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 1
- Název signálu: JEDNODUCHÝ
  - Typ signálu: úroveň
  - Jednotky: N / A
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 1
  - Cíl signálu: N / A
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

Scénář CPP 2 - Typický případ použití, B profile

Událost
- Oznámení: Den před akcí
- Čas zahájení: 1:XNUMX
- Délka: 4 hodin
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 2
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0, 1, 2, 3
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 1 nebo 2
  - Cíl signálu: Žádný
- Název signálu: ELECTRICITY_PRICE
  - Typ signálu: cena
  - Jednotky: USD za Kwh
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 0.10 až 1.00 USD
  - Cíl signálu: Žádný
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

CPP Scénář 3 - Komplexní případ použití

Událost
- Oznámení: Den před akcí
- Začátek: 2:XNUMX
- Délka: 6 hodin
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 2
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0,1, 2, 3)
  - Počet intervalů 3
  - Trvání intervalu: 1 hodina, 4 hodiny, 1 hodina
  - Typické hodnoty intervalu: 1, 2, 1 (pro každý interval)
  - Cíl signálu: Žádný
- Název signálu: ELECTRICITY_PRICE
  - Typ signálu: cena
  - Jednotky: USD za Kwh
  - Počet intervalů 3
  - Trvání intervalu: 1 hodina, 4 hodiny, 1 hodina
  - Typická hodnota intervalu: 0.50 $, 0.75 $, 0.50 $ (pro každý interval)
  - Cíl signálu: Žádný
- Cíle události: Resource_1, Resource_2, Resource_3
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

CPP Sampužitečné zatížení události - typický B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Událost091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

daleko

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT24H

PT4H

2.0

JEDNODUCHÝ

úroveň

SIG_01

0.0

PT4H

0.75

ELECTRICITY_PRICE

cena

SIG_02

měnaPerKWh

americký dolar

žádný

0.0

venID_1234

vždy

Program nabízení kapacity (CBP)

CBP Scenario 1 - Jednoduchý případ použití, A nebo B Profile

Událost
- Oznámení: Den před akcí
- Začátek: 1:XNUMX
- Doba trvání: 4 hodiny
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 1
- Název signálu: JEDNODUCHÝ
  - Typ signálu: úroveň
  - Jednotky: N / A
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 1
  - Cíl signálu: N / A
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

CBP Scenario 2 - Typický případ použití, B profile

Událost
- Oznámení: Den před akcí
- Čas zahájení: 1:XNUMX
- Délka: 4 hodin
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 2
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0,1, 2, 3
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 1 nebo 2
  - Cíl signálu: Žádný
- Název signálu: BID_LOAD
  - Typ signálu: nastavená hodnota
  - Jednotky: powerReal
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 20kW až 100kW
  - Cíl signálu: Žádný
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

CBP Scénář 3 - Komplexní případ použití

Událost
- Oznámení: Den akce (kolik hodin?)
- Začátek: 1:XNUMX
- Délka: 6 hodin
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 3
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0,1, 2, 3)
  - Počet intervalů: 2
  - Trvání intervalu: 3 hodiny, 3 hodiny
  - Typická hodnota intervalu: 1, 2 (pro každý interval)
  - Cíl signálu: Žádný
- Název signálu: BID_LOAD
  - Typ signálu: nastavená hodnota
  - Jednotky: powerReal
  - Počet intervalů 2
  - Trvání intervalu: 3 hodiny, 3 hodiny
  - Typické hodnoty intervalu: 40kW, 80kW (pro každý interval)
  - Cíl signálu: Žádný
- Název signálu: BID_PRICE
  - Typ signálu: cena
  - Jednotky: currencyPerKW
  - Počet intervalů 1
  - Délka intervalu: 6 hodiny
  - Typické hodnoty intervalu: 3.10 $
  - Cíl signálu: Žádný
- Cíle události: Resource_1, Resource_2, Resource_3
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Název sestavy: TELEMETRY_USAGE
- Typ zprávy: využití
- Jednotky: powerReal
- Typ čtení: Přímé čtení
- Četnost hlášení: každou 1 hodinu

CBP Sampužitečné zatížení události - typický B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Událost091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

daleko

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT24H

PT4H

2.0

JEDNODUCHÝ

úroveň

SIG_01

0.0

PT4H

80.0

BID_LOAD

žádaná hodnota

SIG_02

RealPower

60.0

<power:voltage> 220.0tage>

skutečný

0.0

venID_1234

vždy

Program bytových termostatů

Rezidenční termostat Scénář 1 - Jednoduché použití, A nebo B Profile

Událost
- Oznámení: Den před akcí
- Začátek: 1:XNUMX
- Doba trvání: 4 hodiny
- Randomizace: 10 minut
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 1
- Název signálu: JEDNODUCHÝ
  - Typ signálu: úroveň
  - Jednotky: N / A
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 1
  - Cíl signálu: N / A
- Cíle události: Resource_1
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

Obytný termostat, scénář 2 - Typický případ použití, B profile

Událost
- Oznámení: Den před akcí
- Čas zahájení: 1:XNUMX
- Délka: 4 hodin
- Randomizace: 10 minut
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 2
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0,1, 2, 3
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typické hodnoty intervalu: 1 nebo 2
  - Cíl signálu: Žádný
- Název signálu: LOAD_CONTROL
  - Typ signálu: x-loadControlLevelOffset
  - Jednotky: Teplota
  - Počet intervalů 1
  - Délka intervalu: 4 hodiny
  - Typická hodnota intervalu: 2 až 6 stupňů Fahrenheita
  - Cíl signálu: Žádný
- Cíle události: Resource_1, Resource_2
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn, Possible outOut (oadrCreateOpt)
Zprávy
- Žádný

Scénář 3 - Rezidenční termostat - Komplexní případ použití

Událost
- Oznámení: Den akce
- Začátek: 1:XNUMX
- Délka: 6 hodin
- Randomizace: 10 minut
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 3
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0,1, 2, 3)
  - Počet intervalů: 2
  - Trvání intervalu: 3 hodiny, 3 hodiny
  - Typická hodnota intervalu: 1, 2 (pro každý interval)
  - Cíl signálu: Žádný
- Název signálu: BID_LOAD
  - Typ signálu: x-loadControlCapacity
  - Jednotky: Žádné
  - Počet intervalů 2
  - Trvání intervalu: 3 hodiny, 3 hodiny
  - Typická hodnota intervalu: 0.9, 0.8 (pro každý interval)
  - Cíl signálu: Žádný
- Cíle události: Resource_1, Resource_2, Resource_3
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn, Possible outOut (oadrCreateOpt)
Zprávy
- Žádný

Obytný termostat Sampužitečné zatížení události - typický B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Událost091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

daleko

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT4H

PT10M

PT24H

PT4H

2.0

JEDNODUCHÝ

úroveň

SIG_01

0.0

PT4H

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

teplota

Fahrenheita

žádný

0.0

zdroj_1

zdroj_2

vždy

Rychlé odeslání DR

Rychlý scénář DR 1 - Jednoduchý případ použití, A nebo B Profile

Událost
- Oznámení: 10 minut
- Začátek: 1:XNUMX
- Doba trvání: 0 (otevřeno)
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 1
- Název signálu: JEDNODUCHÝ
  - Typ signálu: úroveň
  - Jednotky: N / A
  - Počet intervalů 1
  - Délka intervalu: 0 (otevřený konec)
  - Typické hodnoty intervalu: 1
  - Cíl signálu: N / A
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

Rychlý scénář DR 2 - typický případ použití, B profile

Událost
- Oznámení: 10 minut
- Čas zahájení: 1:XNUMX
- Délka: 30 minut
- Randomizace: Žádná
- Ramp Nahoru: 5 minut
- Obnova: 5 minut
- Počet signálů: 2
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0,1, 2, 3
  - Počet intervalů 1
  - Interval trvání: 30 minut
  - Typické hodnoty intervalu: 1 nebo 2
  - Cíl signálu: Žádný
- Název signálu: LOAD_DISPATCH
  - Typ signálu: delta
  - Jednotky: powerReal
  - Počet intervalů 1
  - Interval trvání: 30 minut
  - Typická hodnota intervalu: 500 kW až 2 mW
  - Cíl signálu: Žádný
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Název sestavy: TELEMETRY_USAGE
- Typ zprávy: využití
- Jednotky: powerReal
- Typ čtení: Přímé čtení
- Četnost hlášení: každou 1 minutu

Rychlý scénář 3 - komplexní případ použití

Událost
- Oznámení: 10 minut
- Začátek: 1:XNUMX
- Délka: 30 minut
- Randomizace: Žádná
- Ramp Nahoru: 5 minut
- Obnova: 5 minut
- Počet signálů: 2
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0,1, 2, 3)
  - Počet intervalů: 2
  - Délka intervalu: 15 minut, 15 minut
  - Typická hodnota intervalu: 1, 2 (pro každý interval)
  - Cíl signálu: Žádný
- Název signálu: LOAD_DISPATCH
  - Typ signálu: nastavená hodnota
  - Jednotky: powerReal
  - Počet intervalů 2
  - Délka intervalu: 15 minut, 15 minut
  - Typické hodnoty intervalu: 800kW, 900kW (pro každý interval)
  - Cíl signálu: Žádný
- Cíle události: Resource_1
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Název sestavy: TELEMETRY_USAGE
- Typ zprávy: využití
- Jednotky: powerReal a voltage
- Typ čtení: Přímé čtení
- Četnost hlášení: každých 5 sekund

Rychlý DR S.ampužitečné zatížení události - typický B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Událost091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

daleko

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT10M

<ei:x-eiRampNahoru>

PT5M

</ei:x-eiRampNahoru>

PT5M

PT10M

2.0

JEDNODUCHÝ

úroveň

SIG_01

0.0

PT10M

500.0

LOAD_DISPATCH

delta

SIG_02

RealPower

60.0

<power:voltage> 220.0tage>

skutečný

0.0

venID_1234

vždy

Rychlý DR S.ample Report Metadata Payload - Typical B Profile Use Case

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

zdroj1

používání

RealEnergy

Přímé čtení

http: // MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

Nepravdivé

</oadr:oadrSamplingRate>

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

<ei:createdDateTime>2015-06-12T19:25:12Z</ei:createdDateTime>

ec27de207837e1048fd3

Rychlý DR S.ample Report Request Payload - Typical B Profile Use Case

ReportReqID130615_192625_230

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

PT1M

<xcal:date-time>2015-06-14T13:00:00Z</xcal:date-time>

PT10M

rID120615_122512_981_0

x-notApplicable

VEN130615_192312_582

Rychlý DR S.ample Report Data Payload - Typical B Profile Use Case

ReportUpdReqID130615_192730_445

<xcal:date-time>2015-06-14T02:27:29Z</xcal:date-time>

rID120615_122512_981_0

100

0.0

500.0

Kvalita dobrá - nespecifická

RP_54321

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

TELEMETRY_USAGE

<ei:createdDateTime>2015-06-14T02:27:29Z</ei:createdDateTime>

VEN130615_192312_582

Program doby používání obytných elektrických vozidel (EV) (TOU)

Všimněte si, že když program komunikuje úrovně rychlosti v poměrně strukturované formě, zobrazí se pouze jednoduché a typické případy použití

Residential EV Scenario 1 - Jednoduché použití, A nebo B Profile

Událost
- Oznámení: Den před akcí
- Začátek: 1:XNUMX
- Doba trvání: 24 hodiny
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 1
- Název signálu: JEDNODUCHÝ
  - Typ signálu: úroveň
  - Jednotky: N / A
  - Počet intervalů; stejné změny úrovně TOU za 24 hodin (2 - 6)
  - Doba trvání: aktivní časový rámec úrovně TOU (tj. 6 hodin)
  - Typické hodnoty intervalu: 0 - 4 mapované na úrovně TOU
  - Cíl signálu: N / A
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

Residential EV Scenario 2 - Typický případ použití, B profile

Událost
- Oznámení: Den před akcí
- Čas zahájení: půlnoc
- Délka: 24 hodin
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 2
- Název signálu: Jednoduchý
  - Typ signálu: úroveň
  - Jednotky: úroveň 0, 1, 2, 3
  - Počet intervalů: stejná změna úrovně TOU za 24 hodin (2 - 6)
  - Doba trvání: aktivní časový rámec úrovně TOU (tj. 6 hodin)
  - Typické hodnoty intervalu: 0 - 4 mapované na úrovně TOU (0 - nejlevnější úroveň)
  - Cíl signálu: Žádný
- Název signálu: ELECTRICITY_PRICE
  - Typ signálu: cena
  - Jednotky: USD za Kwh
  - Počet intervalů: stejné změny úrovně TOU za 24 hodin (2 - 6)
  - Doba trvání: aktivní časový rámec úrovně TOU (tj. 6 hodin)
  - Typické hodnoty intervalu: 0.10 až 1.00 USD (aktuální úroveň)
  - Cíl signálu: Žádný
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

Rezidenční EV Sampužitečné zatížení události - typický B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Událost091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

daleko

<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>

PT24H

PT5H

0.0

PT7H

1.0

PT47H

2.0

PT5H

1.0

JEDNODUCHÝ

úroveň

SIG_01

0.0

PT5H

0.35

PT7H

0.55

PT7H

0.75

PT5H

0.55

ELECTRICITY_PRICE

cena

SIG_02

měnaPerKWh

americký dolar

žádný

0.0

venID_1234

vždy

Cenový program pro elektrická vozidla na veřejných stanicích (EV) v reálném čase

Všimněte si toho, protože se jedná o cenový program v reálném čase, ve skutečnosti neexistuje rozdíl mezi jednoduchým, typickým a složitým případem použití. Proto sampData se zobrazí pouze pro typický případ použití.

Public Station EV Scenario 1 - Typický případ použití, B profile

Událost
- Oznámení: 1 hodinu dopředu
- Čas zahájení: 1:XNUMX
- Délka: 1 hodin
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 1
- Název signálu: ELECTRICITY_PRICE
  - Typ signálu: cena
  - Jednotky: USD za Kwh
  - Počet intervalů 1
  - Délka intervalu: 1 hodiny
  - Typické hodnoty intervalu: 0.10 až 1.00 USD
  - Cíl signálu: Žádný
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: vždy
- Očekávaná odpověď VEN: optIn
Zprávy
- Žádný

Veřejná stanice EV Sampužitečné zatížení události - typický B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Událost091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

daleko

<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>

PT1H

0.75

ELECTRICITY_PRICE

cena

SIG_01

měnaPerKWh

americký dolar

žádný

0.0

venID_1234

vždy

Program DR s distribuovanou energií (DER)

Public Station EV Scenario 1 - Typický případ použití, B profile

Událost
- Oznámení: Den dopředu
- Čas zahájení: půlnoc
- Délka: 24 hodin
- Randomizace: Žádná
- Ramp Nahoru: Žádné
- Obnova: Žádné
- Počet signálů: 24
- Název signálu: ELECTRICITY_PRICE
  - Typ signálu: cena
  - Jednotky: USD za Kwh
  - Počet intervalů 1
  - Délka intervalu: 1 hodiny
  - Typické hodnoty intervalu: 0.10 až 1.00 USD
  - Cíl signálu: Žádný
- Cíle události: venID_1234
- Priorita: 1
- Vyžaduje se odpověď VEN: nikdy
- Očekávaná odpověď VEN: n / a
Zprávy
- Žádný

Veřejná stanice EV Sampužitečné zatížení události - typický B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Událost091214_043741_028_0

http: // MarketContext1

<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>

daleko

<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>

PT24H

PT1H

0.75

PT1H

0.80

ELECTRICITY_PRICE

cena

SIG_01

měnaPerKWh

americký dolar

žádný

0.0

venID_1234

nikdy

- Přample Reports from Utility Pilots

Členové OpenADR Alliance poskytli následující B Profile oadrUpdateReport užitečného zatížení sampz pilotních programů obslužných programů, kde byly nasazeny jejich VEN. Následující poznámky doprovázely tři užitečné zatížení sampza předpokladu:

Cíl užitečného zatížení termostatu:

Potřebujete znát stav termostatu (teplota, žádané hodnoty, stav ventilátoru a režimu)
Pokud je přihlášen, ať zákazník změnil nastavení termostatu či nikoli (zprávy ručního přepsání)

M&V pro rabaty Užitečné zatížení Cíl:

Stav zdrojů a manuální přepsání v případě přihlášení
Intervalová data z čítače pulsů KYZ nebo monitoru energie pro celkovou energii v KWH a okamžitou poptávku v KW

Cíl inteligentního měřiče / AMI Interval Data Payload:

Interval odečtu měřiče AMI je přibližně 15 minut až 1 hodina. I když je to užitečné, není dostatečně podrobné pro fakturační odhady téměř v reálném čase
Celková energie v KWH, delta energie v KWH, okamžitá poptávka v KW

V datové části ex se používají následující předpony oboru názvůamples:

xmlns: oadr = ”http://openadr.org/oadr-2.0b/2012/07“
xmlns: pyld = ”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
xmlns: ei = ”http://docs.oasis-open.org/ns/energyinterop/201110 ″
xmlns: scale = ”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
xmlns: emix = ”http://docs.oasis-open.org/ns/emix/2011/06 ″
xmlns: strm = ”urn: ietf: params: xml: ns: icalendar-2.0: stream”
xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0 ″
xmlns: power = ”http://docs.oasis-open.org/ns/emix/2011/06/power”

Termostat hlásí užitečné zatížení Sample

RUP-18

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

<xcal:date-time>2014-03-21T02:25:03Z</xcal:date-time>

PT1M

Postavení

skutečný

Nepravdivé

Žádná nová hodnota - byla použita předchozí hodnota

Aktuální teplota

77.000000

Žádná nová hodnota - byla použita předchozí hodnota

Nastavení teploty tepla

64.000000

Žádná nová hodnota - byla použita předchozí hodnota

Nastavení chladné teploty

86.000000

Žádná nová hodnota - byla použita předchozí hodnota

Nastavení režimu HVAC

Žádná nová hodnota - byla použita předchozí hodnota

Aktuální režim HVAC

0.000000

Žádná kvalita - žádná hodnota

Nastavení režimu ventilátoru

Žádná nová hodnota - byla použita předchozí hodnota

Aktuální režim pozastavení

Žádná nová hodnota - byla použita předchozí hodnota

Aktuální režim pryč

Žádná nová hodnota - byla použita předchozí hodnota

Aktuální vlhkost

0.000000

Žádná kvalita - žádná hodnota

RP21

REQ: RReq: 1395368583267

0013A20040980FAE

TELEMETRY_STATUS

<ei:createdDateTime>2014-03-21T02:26:04Z</ei:createdDateTime>

VEN.ID:1395090780716

Slevy M & Vfor Nahlásit užitečné zatížení Sample

RUP-10

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>

PT30S

Postavení

skutečný

Nepravdivé

Kvalita dobrá - nespecifická

Počet pulzů

34750.000000

Kvalita dobrá - nespecifická

Energie

33985.500000

Kvalita dobrá - nespecifická

Napájení

1.26

Kvalita dobrá - nespecifická

RP15

REQ: RReq: 10453335019195698

0000000000522613 60

TELEMETRY_USAGE

<ei:createdDateTime>2015-08-21T17:41:50Z</ei:createdDateTime>

VEN.ID:1439831430142

Smart Meter/AMI Interval Data Report Payload Sample

RUP-4096

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT1M

<xcal:date-time>2014-09-10T06:26:52Z</xcal:date-time>

PT15S

okamžitá poptávka

6.167000

Žádná nová hodnota - byla použita předchozí hodnota

intervalDataDelivered

0.051000

Žádná nová hodnota - byla použita předchozí hodnota

curSumDoručeno

12172.052000

Žádná nová hodnota - byla použita předchozí hodnota

<xcal:date-time>2014-09-10T06:27:07Z</xcal:date-time>

PT15S

okamžitá poptávka

6.114000

Žádná nová hodnota - byla použita předchozí hodnota

intervalDataDelivered

0.051000

Žádná nová hodnota - byla použita předchozí hodnota

curSumDoručeno

12172.052000

Žádná nová hodnota - byla použita předchozí hodnota

<xcal:date-time>2014-09-10T06:27:22Z</xcal:date-time>

PT15S

okamžitá poptávka

6.113000

Žádná nová hodnota - byla použita předchozí hodnota

intervalDataDelivered

0.051000

Žádná nová hodnota - byla použita předchozí hodnota

curSumDoručeno

12172.142000

Žádná nová hodnota - byla použita předchozí hodnota

<xcal:date-time>2014-09-10T06:27:37Z</xcal:date-time>

PT15S

okamžitá poptávka

6.112000

Žádná nová hodnota - byla použita předchozí hodnota

intervalDataDelivered

0.051000

Žádná nová hodnota - byla použita předchozí hodnota

curSumDoručeno

12172.142000

Žádná nová hodnota - byla použita předchozí hodnota

RP4101

<ei:reportRequestID>d5f88bf0-1a8d-0132-eab3-0a5317f1edaa</ei:reportRequestID>

<ei:reportSpecifierID>00:21:b9:00:f2:a9</ei:reportSpecifierID>

TELEMETRY_USAGE

<ei:createdDateTime>2014-09-10T06:27:53Z</ei:createdDateTime>

<ei:venID>2b2159c0-19cd-0132-eaa3-0a5317f1edaa</ei:venID>

- Služby

Open ADR podporuje následující služby:

Služba EiEvent - VTN je používají k odesílání událostí odezvy na poptávku do VEN a používají je VEN k označení, zda se na akci chystají zúčastnit zdroje. Jediná služba podporovaná A profile je EiEvent
Služba EiReport - Používají VEN a VTN k výměně historických, telemetrických a předpovědních zpráv
Služba EiOpt - Používá VEN ke komunikaci plánu dočasné dostupnosti s VTN nebo ke kvalifikaci zdrojů účastnících se události
Služba EiRegisterParty - Iniciováno VEN a používáno VEN i VTN k výměně informací potřebných k zajištění interoperabilní výměny užitečných zatížení
Služba OadrPoll - Používá VEN k dotazování VTN na užitečné zatížení z jakékoli jiné služby

A a B profile servisní operace jsou definovány kořenovým prvkem každého užitečného zatížení, s výjimkou obalů oadrPayload a oadrSignedObject použitých na všech B profile užitečné zatížení.

- Definice užitečného zatížení

Užitečné zatížení EiEvent

oadrRequestEvent - Používá se v modelu výměny tahu VEN k načtení všech relevantních událostí z VTN. Používá se jako primární mechanismus dotazování pro A profile VEN, ale používané pouze na B VEN pro synchronizaci s VTN.
oadrDistributeEvent - Používá VTN k doručování událostí reakce na poptávku do VEN
oadrCreatedEvent - Používá ho VEN ke komunikaci, zda má v úmyslu zúčastnit se události přihlášením nebo odhlášením
oadrResponse - Používá VTN k potvrzení přijetí optIn nebo optOut z VEN

Užitečné zatížení EiReport

Všimněte si, že VEN i VTN jsou schopné být producentem i žadatelem o sestavu, takže všechny níže uvedené užitečné zátěže může iniciovat kterákoli strana.

oadrRegisterReport - Používá se k publikování svých možností hlášení v sestavě metadat
oadrRegisteredReport -Potvrďte přijetí oadrRegisterReport, volitelně si vyžádejte jeden z nabízených přehledů
oadrCreateReport - Používá se k vyžádání zprávy, kterou dříve nabídl VEN nebo VTN
oadrCreatedReport - Potvrďte přijetí žádosti o hlášení
oadrUpdateReport -Doručte požadovanou zprávu obsahující data intervalu
oadrUpdatedReport - Potvrďte přijetí doručeného hlášení
oadrCancelReport - Zrušte dříve požadované pravidelné hlášení
oadrCanceledReport - Potvrďte pravidelné zrušení hlášení
oadrResponse - Používá se jako zástupná odezva v některých vzorech výměny vyžádání, když je v žádosti o transportní vrstvu doručena odpověď aplikační vrstvy.

Užitečné zatížení EiOpt

oadrCreateOpt - Používá se pro dva výrazně odlišné účely
- Pro VEN sdělit dočasný plán dostupnosti VTN s ohledem na jeho schopnost účastnit se událostí DR
- Aby VEN kvalifikoval zdroje účastnící se události
oadrCreatedOpt - Potvrďte přijetí užitečného zatížení oadrCreateOpt
oadrCancelOpt -Zrušte dočasný plán dostupnosti
oadrZrušenoOpt - Potvrďte dočasné zrušení hlášení o dostupnosti

Užitečné zatížení EiRegisterParty

oadrQueryRegistrace - Způsob, jakým VEN dotazuje registrační údaje VTN, aniž by se skutečně registroval.
oadrCreatePartyRegistrace - Žádost od VEN k VTN o registraci. Obsahuje informace o schopnostech VEN.
oadrCreatedPartyRegistrace - Odpověď na oadrQueryRegistration nebo oadrCreatePartyRegistration. Obsahuje funkce VTN a registrační informace nezbytné pro interoperabilitu VEN
oadrCancelPartyRegistrace - Používá buď VEN nebo VTN ke zrušení registrace
oadrCanceledPartyRegistrace - Odpověď na oadrCancelPartyRegistration. Potvrzuje přijetí zrušení registrace
oadrRequestReregistration - Toto užitečné zatížení používá VTN v modelu výměny tahu k signalizaci VEN k opětovnému zahájení sekvence registrace
oadrResponse - Používá se jako zástupná odezva v některých vzorech výměny vyžádání, když je v žádosti o transportní vrstvu doručena odpověď aplikační vrstvy.

Užitečné zatížení OadrPoll

oadrPoll - Obecný polovací mechanismus pro B profile která vrací užitečné zatížení pro jakoukoli jinou službu, která je nová nebo byla aktualizována.
oadrResponse - Používá se k označení, že nejsou k dispozici žádná nová nebo aktualizovaná užitečná zatížení

- Glosář prvků schématu užitečného zatížení

Následuje abecední seznam prvků schématu používaných v nákladech OpenADR 2.0. Příběh popisuje jejich použití, protože se týká OpenADR a jejich použití v nákladech. Když se definice prvku změní na základě nákladu, který obsahuje, nebo v kontextu jeho použití, bude to v příběhu uvedeno. Definice kořenového užitečného zatížení byly vyloučeny, protože jsou definovány v příloze C.

ac - Booleovská hodnota označující, zda je u energetického produktu střídavý proud
přesnost - Číslo je ve stejných jednotkách jako proměnná užitečného zatížení pro Interval. Pokud je k dispozici s důvěrou, označuje pravděpodobnou variabilitu predikce. Pokud je k dispozici s ReadingType, označuje pravděpodobnou chybu čtení.
aggregatedPnode - Uzel agregované ceny je specializovaný typ cenového uzlu, který se používá k modelování položek, jako je systémová zóna, výchozí cenová zóna, vlastní cenová zóna, kontrolní oblast, agregovaná generace, agregovaná účastnická zátěž, agregovaná neúčastnická zátěž, obchodní centrum, zóna DCA
k dispozici - Objekt obsahující datum a čas a trvání plánu dostupnosti EiOpt
baselineID - Jedinečné ID pro konkrétní účaří
baselineName - Popisný název pro základní linii
komponenty –
důvěra - Statistická pravděpodobnost, že vykazovaný datový bod je přesný
createdDateTime - DateTime bylo vytvořeno užitečné zatížení
měna –
měnaPerKW –
měnaPerKWh –
měnaPerThm –
proud –
současná cena - Hodnota payloadFloat aktuálně prováděného intervalu událostí.
customUnit - Používá se k definování vlastní měrné jednotky pro vlastní sestavy
datum-čas –
dtstart - Počáteční čas pro aktivitu, data nebo změnu stavu
trvání - Časové období pro událost, hlášení nebo časový interval dostupnosti
doba trvání - Doba trvání aktivity, dat nebo stavu
eiActivePeriod - Časové rámce relevantní pro celkovou událost
eiCreatedEvent - Odpovězte na událost DR pomocí optIn nebo optOut
eiEvent - Objekt obsahující všechny informace pro jednu událost
eiEventBaseline - B profile
eiEventSignal - Objekt obsahující všechny informace o jediném signálu v události
eiEventSignals - Intervalová data pro jeden nebo více signálů událostí a / nebo základních linií
eiMarketContext - URI jednoznačně identifikující program reakce na poptávku
eiReportID - Referenční ID pro zprávu
eiRequestEvent - Vyžádejte si událost z VTN v režimu stahování
eiResponse - Uveďte, zda je přijatelné užitečné zatížení přijatelné
eiTarget - Identifikuje prostředky přidružené k logickému rozhraní VEN. U událostí jsou zadané hodnoty cílem události
endDeviceAsset - EndDeviceAssets jsou fyzické zařízení nebo zařízení, kterými mohou být měřiče nebo jiné typy zařízení, které by mohly být zajímavé
energyApparent - Zdánlivá energie měřená ve voltechamphodiny (VAh)
energyItem –
energieReaktivní - Reaktivní energie, volt-ampreaktivní hodiny (VARh)
energyReal - Skutečná energie, watthodiny (Wh)
eventDescriptor - Informace o akci
eventID - Hodnota ID, která identifikuje konkrétní instanci události DR.
eventResponse - Objekt obsahující odpověď VEN na žádost o účast na události
eventResponses - optIn nebo optOut odpovědi na přijaté události
eventStatus - Aktuální stav události (daleko, blízko, aktivní atd.)
FeatureCollection / umístění / mnohoúhelník / exteriér / LinearRing
frekvence –
zrnitost - Toto je časový interval mezi sampvedená data v žádosti o hlášení.
ID skupiny -Tento typ cíle se používá pro události, zprávy a opt plány. Hodnotu by obvykle přidělil obslužný program během registrace do programu DR
skupinové jméno - Tento typ cíle se používá pro události, přehledy a opt plány. Hodnotu by obvykle přidělil obslužný program během registrace do programu DR
hertz –
interval - Objekt obsahující datový čas a / nebo dobu trvání a použitelnou hodnotu v případě události nebo data v případě zprávy
intervaly - Jeden nebo více časových intervalů, během nichž je aktivní událost DR nebo jsou k dispozici data hlášení
Popis položky - Popis měrné jednotky zprávy
itemUnits - Základní měrná jednotka pro datový bod sestavy
marketContext - URI identifikující program DR
meterAsset - MeterAsset je fyzické zařízení nebo zařízení, která plní roli měřiče
ModifikaceDateTime - Při změně události
číslo úpravy - Zvýší se při každé změně události.
důvod úpravy - Proč byla událost upravena
mrid - MRID identifikuje fyzické zařízení, které může být CustomerMeter nebo jiné typy EndDevices.
uzel - Uzel je místo, kde se něco mění (často vlastnictví) nebo se připojuje na mřížce. Mnoho uzlů je spojeno s měřiči, ale ne všechny jsou.
numDataSources –
oadrKapacita –
oadr Aktuální –
oadrDataQuality –
oadrDeviceClass - Cíl třídy zařízení - použijte pouze endDeviceAsset.
oadrEvent - Objekt obsahující událost odpovědi na požadavek
oadrExtension –
oadrExtensionName -
oadr Rozšíření –
oadrHttpPullModel - Logická hodnota označující, zda VEN chce použít model výměny vyžádané replikace
oadrInfo - Dvojice klíčových hodnot registračních informací specifických pro službu
oadrKey –
oadrLevelOffset –
oadrLoadControlState –
oadrManualOverride - Pokud je to pravda, pak byla kontrola zátěže ručně přepsána
oadrMax –
oadrMaxPeriod - Maximálně sampling období
oadrMin –
oadrMinPeriod - Minimální sampling období
oadrNormální –
oadrOnChange - Pokud je to pravda, data se zaznamenají, když se změní, ale na frekvenci, která není větší než frekvence specifikovaná minPeriod.
oadrOnline - Je-li true, pak je prostředek / aktivum online, pokud je false, pak offline.
oadrVytáhnout –
oadrPayloadResourceStatus - Aktuální informace o stavu zdroje
oadrPendingReports - Seznam pravidelných zpráv je stále aktivní
oadrPercentOffset –
oadrProfile - Profile podporováno VEN nebo VTN
oadrProfileJméno – OpenADR profile název jako 2.0a nebo 2.0b.
oadrProfiles – OpenADR profilejsou podporovány implementací
oadrZpráva - Objekt obsahující všechny informace pro jednu zprávu
oadrReportPopis - Popis charakteristik reportu nabízených producentem reportu. Obsahuje ve zprávě metadat
oadrReportOnly - ReportOnlyDeviceFlag
oadrReportPayload - Hodnoty datových bodů pro sestavy
oadrRequestedOadrPollFreq - VEN pošle užitečné zatížení oadrPoll do VTN maximálně jednou za každé trvání určené tímto prvkem
oadrResponseRequired - Ovládá, kdy je vyžadována odpověď optIn / optOut. Může být vždy nebo nikdy
oadrSamplingRate - Samprychlost pro data typu telemetrie
oadrService –
oadrServiceName - Tento typ cíle se používá pro události, přehledy a opt plány. Hodnotu by obvykle přidělil obslužný program během registrace do programu DR
oadrServiceSpecificInfo - Registrační informace specifické pro službu
oadrSetPoint –
oadrSignedObject –
oadr Přeprava - Název přenosu podporovaný VEN nebo VTN
oadrTransportAddress - Kořenová adresa používaná ke komunikaci s druhou stranou. V případě potřeby by měl obsahovat port
oadrTransportName - Název transportu OpenADR, například simpleHttp nebo xmpp
oadrTransports - Transporty OpenADR podporované implementací
oadrUpdatedReport - Potvrďte přijetí zprávy
oadrUpdateReport - Odešlete dříve požadovaný přehled
oadrValue –
oadrVenName - Název VEN. Může být použit ve VTN GUI
oadrXmlSignature - Implementace podporuje XML podpis
optID - Identifikátor optické interakce
optReason - Výčtová hodnota pro opt důvod, jako je x-harmonogram
optType - optIn nebo optOut události, nebo se používá k označení typu časového plánu opt definovaného v vavailablityObject pro službu EiOpt
ID strany - Tento typ cíle se používá pro události, přehledy a opt plány. Hodnotu by obvykle přidělil obslužný program během registrace do programu DR
payloadFloat - Hodnota datového bodu pro signály událostí nebo pro hlášení aktuálních nebo historických hodnot.
pnode - Cenový uzel je přímo spojen s uzlem připojení. Jedná se o cenové umístění, pro které účastníci trhu předkládají nabídky, nabídky, kupují / prodávají CRR a vypořádávají se.
pointOfDelivery –
pointOfReceipt –
posList –
powerApparent - Zdánlivý výkon měřený ve voltechamperes (VA)
powerAtributes
powerItem
powerReactive - Jalový výkon, měřeno ve voltech-ampreaktivní reaktory (VAR)
powerReal - Skutečný výkon měřený ve wattech (W) nebo v joulech za sekundu (J / s)
priorita - Priorita události ve vztahu k ostatním událostem (Čím nižší číslo, tím vyšší priorita. Hodnota nula (0) označuje žádnou prioritu, což je ve výchozím nastavení nejnižší priorita).
vlastnosti –
pulseCount - Datový bod hlášení
pulseFactor - kWh na počet
kvalifikovanýEventID - Jedinečné ID události
readingType - Metadata o čteních, například průměrná nebo odvozená
registrationID - Identifikátor pro registrační transakci. Není zahrnuto v reakci na registraci dotazu, pokud již není registrováno
odpovědět Omezit - Maximální počet událostí, které se mají vrátit v užitečném obsahu oadrDistributeEvent
reportBackDuration - Hlášení zpět s Report-to-Date pro každé absolvování tohoto trvání.
reportDataSource - Zdroje dat v této sestavě. Přampzahrnují metry nebo submetry. Za exampPokud je měřič schopen poskytovat dva různé typy měření, pak by každý měřicí tok byl identifikován samostatně.
reportInterval - Toto je celkové období podávání zpráv.
reportName - Volitelný název sestavy.
reportRequestID - Identifikátor konkrétní žádosti o zprávu
reportSpecifier - Zadejte požadované datové body v konkrétní instanci sestavy
reportSpecifierID - Identifikátor pro konkrétní specifikaci sestavy metadat
reportSubject - Cíl třídy zařízení - použijte pouze endDeviceAsset.
reportToFollow - Určuje, zda se má zpráva (ve formě UpdateReport) po zrušení Reportu vrátit
typ zprávy - Typ zprávy, například využití nebo cena
ID požadavku - ID použité k porovnání požadavku a odpovědi logické transakce
ID prostředku - Tento typ cíle se používá pro události, přehledy a opt plány. Hodnotu by obvykle přidělil obslužný program během registrace do programu DR
odpověď –
responseCode - 3místný kód odpovědi
responseDescription - Popisný popis stavu odpovědi
odpovědi –
rID - ReferenceID pro tento datový bod
oblast služeb - Tento typ cíle se používá pro události, přehledy a opt plány. Hodnotu by obvykle přidělil obslužný program během registrace do programu DR
serviceDeliveryPoint - Logický bod v síti, kde vlastnictví služby mění majitele. Je to jeden z potenciálně mnoha servisních bodů v rámci ServiceLocation, který poskytuje službu v souladu s CustomerAgreement. Používá se v místě, kde může být instalován měřič.
serviceLocation - Zákazník ServiceLocation má jeden nebo více ServiceDeliveryPoint, které se zase vztahují k metrům. Umístění může být bod nebo mnohoúhelník, v závislosti na konkrétních okolnostech. Pro distribuci je ServiceLocation obvykle umístění provozovny zákazníka utility.
signalID - jedinečný identifikátor pro konkrétní signál události
signálName - Název signálu, například JEDNODUCHÝ
signalPayload - Hodnoty signálu pro události a základní linie
siScaleCode - Faktor měřítka pro základní měrnou jednotku pro zprávu
specifierPayload - Otevřený
začít později - Okno randomizace pro zahájení události
statusDateTime - Datum a čas, na který tento artefakt odkazuje.
teplota –
testEvent - Cokoli jiného než false označuje testovací událost
text –
Therm –
tolerance - Dílčí objekt obsahující požadavky na randomizaci pro událost
tolerovat - Objekt obsahující požadavky na randomizaci události
transportInterface - Transportní rozhraní vymezuje okraje na obou koncích transportního segmentu.
uid - Používá se jako index k identifikaci intervalů. Unikátní identifikátor
hodnota –
dostupnost - Plán odrážející dostupnost zařízení pro účast na událostech DR
venID - Jedinečný identifikátor pro VEN
svtage –
vtnComment - Libovolný text
vtnID - Jedinečný identifikátor pro VTN
x-eiNotification - VEN by mělo obdržet užitečné zatížení události DR před dtstart minus toto trvání.
x-eiRampNahoru – Doba před nebo po začátku události, během které by se měla přeprava nákladu přepravit.
x-eiRecovery - Doba před nebo po době ukončení události, během níž by se měl přístřešek přenášet.

Glosář vyjmenovaných hodnot

eventStatus

aktivní - Událost byla zahájena a je aktuálně aktivní.
zrušeno - Událost byla zrušena.
dokončeno - Událost byla dokončena.
daleko - Událost čeká v daleké budoucnosti. Přesná definice toho, jak daleko to v budoucnu bude odkazovat, závisí na tržním kontextu, ale obvykle znamená následující den.
u - Událost čeká v blízké budoucnosti. Přesná definice toho, jak blízko v budoucnosti je čekající událost aktivní, závisí na kontextu trhu. .Začíná souběžně s efektivním začátkem události x-eiRampDoba up. Pokud x-eiRampNahoru není pro událost definováno, tento stav nebude pro událost použit.
žádný - Žádná událost čeká na vyřízení

itemUnits

Měna
- USD - Americké dolary
- Mnohým, kteří jsou zde uvedení, viz schéma
powerReal
- J/s - Joule sekunda
- W - Watty
teplota
- Celsia –
- Fahrenheita –

oadrDataQuality

Žádná nová hodnota - byla použita předchozí hodnota –
Žádná kvalita - žádná hodnota –
Špatná kvalita - porucha komunikace –
Špatná kvalita - chyba konfigurace –
Špatná kvalita - porucha zařízení –
Špatná kvalita - poslední známá hodnota –
Špatná kvalita - nespecifikováno –
Špatná kvalita - nepřipojeno –
Špatná kvalita - mimo provoz –
Špatná kvalita - porucha snímače –
Kvalita dobrá - místní přepsání –
Kvalita dobrá - nespecifická –
Limit kvality - pole / konstantní –
Limit kvality - pole / vysoká –
Limit kvality - pole / nízká –
Limit kvality - pole / ne –
Nejistá kvalita - jednotky EU byly překročeny –
Nejistá kvalita - poslední použitelná hodnota –
Nejistá kvalita - nespecifická –
Nejistá kvalita - senzor není přesný –
Nejistá kvalita - normální –

oadrResponseRequired

vždy - Vždy pošlete odpověď na každou přijatou událost.
nikdy - Nikdy neodpovídej.

optReason

Výčet důvodů pro volbu.

hospodářský –
stav nouze –
mustRun –
neúčastnící se –
outageRunStatus –
přepsatStatus –
účastnící se –
x-plán –

oadrTransportName

jednoduchýHttp –
xmpp –

OptType

optIn - Indikace, že se VEN zúčastní události, nebo v případě služby EiOpt typ harmonogramu označujícího, že zdroj bude k dispozici
odhlásit se - Indikace, že se VEN nebude účastnit události, nebo v případě služby EiOpt typ harmonogramu označujícího, že zdroj nebude k dispozici

typ čtení

Přiděleno - Meter pokrývá několik [zdrojů] a využití je odvozeno pomocí jakési profi výpočtu dat.
Smlouva - Označuje, že čtení je pro forma, tj. Je hlášeno za dohodnuté sazby
Odvozený - Použití je odvozeno ze znalosti běhu, běžného provozu atd.
Přímé čtení - Čtení se čte ze zařízení, které se monotónně zvyšuje, a využití se musí počítat z dvojic počátečních a koncových hodnot.
Odhadovaný - Používá se, když chybí čtení v sérii, ve které je přítomno nejvíce čtení.
Hybridní - Pokud je agregováno, odkazuje na různé typy čtení v agregovaném počtu.
Střední - Odečet je průměrná hodnota za období uvedené v Granularity
Síť - Měřič nebo [zdroj] připravuje vlastní výpočet celkového využití v čase.
Vrchol - Čtení je nejvyšší (nejvyšší) hodnota za období uvedené v podrobnostech. U některých měření může mít větší smysl jako nejnižší hodnota. Nemusí být v souladu s agregovanými odečty. Platí pouze pro základny položek průtoku, tj. Výkon, ne energie.
Projektováno - Označuje, že čtení je v budoucnosti a ještě nebylo změřeno.
Shrnuto - Několik metrů společně poskytuje odečet tohoto [zdroje]. Toto je konkrétně jiné než agregované, což odkazuje na více [zdrojů] ve stejné užitečné zátěži. Viz také Hybrid.
x-notApplicable - Nelze použít
x-RMS - Střední kvadratická

reportName

HISTORY_GREENBUTTON - Zpráva obsahující data greenbutton ve struktuře schématu přívodu atomu
HISTORY_USAGE - Zpráva obsahující údaje o spotřebě energie z historie
METADATA_HISTORY_GREENBUTTON - Zpráva metadat definující možnosti hlášení pro zprávy HISTORY_GREENBUTTON
METADATA_HISTORY_USAGE - Zpráva metadat definující možnosti hlášení pro zprávy HISTORY_USAGE
METADATA_TELEMETRY_STATUS - Zpráva metadat definující možnosti hlášení pro zprávy TELEMETRY_STATUS
METADATA_TELEMETRY_USAGE - Zpráva metadat definující možnosti hlášení pro zprávy TELEMETRY_USAGE
TELEMETRY_STATUS - Zpráva obsahující informace o stavu zdrojů v reálném čase, jako je například online stav
TELEMETRY_USAGE - Zpráva obsahující informace o využití energie v reálném čase

typ zprávy

Vyčtená hodnota, která udává typ poskytované sestavy.

dostupné úložiště energie - Kapacita k dispozici pro další skladování energie, snad k dosažení cílového úložiště energie
průměr poptávky - Průměrné využití za dobu označenou Granularity. Viz poptávka po více informací.
prům. využití - Průměrné využití za dobu označenou Granularity. Další informace viz použití.
základní linie - Může to být poptávka nebo použití, jak naznačuje ItemBase. Označuje, co by [měření] bylo, kdyby nebylo události nebo regulace. Zpráva má formát Baseline.
deltaDemand - Změna poptávky ve srovnání s výchozí hodnotou. Viz poptávka po více informací
deltaSetPoint - Změny požadované hodnoty oproti předchozímu plánu.
deltaUsage - Změna využití ve srovnání se základní linií. Další informace viz použití
požadovat - Zpráva označuje množství jednotek (vyjádřeno v ItemBase nebo v produktu EMIX). Typ užitečného zatížení je Množství. Typickou položkou ItemBase je Real Power.
odchylka - Rozdíl mezi nějakou instrukcí a skutečným stavem.
downRegulationCapacityAvailable - Kapacita pro regulaci dolů k dispozici pro odeslání, vyjádřená v reálném výkonu EMIX. Užitečné zatížení je vždy vyjádřeno jako kladné množství.
úroveň - Jednoduchá úroveň z trhu při každém intervalu.
provozní stav - Zobecněný stav zdroje, jako je zapnutí / vypnutí, obsazenost budovy atd. Žádná položka BaseBase není relevantní. Vyžaduje rozšíření užitečné zátěže pro konkrétní aplikaci.
procenta poptávky - Procenttage poptávky
procentní využití - Procenttage použití
faktor síly - Účiník zdroje
cena - Cena za BaseBase v každém intervalu
čtení - Zpráva označuje odečet, jako z měřiče. Odečty jsou momenty v časových změnách v čase, které lze vypočítat z rozdílu mezi po sobě následujícími odečty. Typ užitečného zatížení je float
regulace Nastavená hodnota - Požadovaná hodnota regulace podle pokynů v rámci regulačních služeb
setPoint - Zpráva označuje aktuálně nastavenou částku (vyjádřenou v ItemBase nebo v produktu EMIX). Může to být potvrzení / vrácení hodnoty řízení požadované hodnoty odeslané z VTN. Typ užitečného zatížení je Množství. Typickou položkou ItemBase je Real Power.
uložená energie - Uložená energie je vyjádřena jako skutečná energie a užitečné zatížení je vyjádřeno jako množství.
targetEnergyStorage - Cílová energie je vyjádřena jako skutečná energie a užitečné zatížení je vyjádřeno jako množství.
upRegulationCapacityAvailable - Dostupná kapacita regulace pro odeslání, vyjádřená v EMIX Real Power. Užitečné zatížení je vždy vyjádřeno jako kladné množství.
používání - Zpráva označuje množství jednotek (denominovaných v ItemBase nebo v produktu EMIX) za období. Typ užitečného zatížení je Množství. Typickým ItemBase je RealEnergy
x-resourceStatus - Procenttage poptávky

scaleCode

p - Pico 10 ** - 12
n - Nano 10 ** - 9
mikro - Micro 10 ** - 6
m - Milli 10 ** - 3
c - Centi 10 ** - 2
d - Deci 10 ** - 1
k - Kilo 10 ** 3
M - Mega 10 ** 6
G - Giga 10 ** 9
T - Tera 10 ** 12
žádný - Nativní měřítko

signálName

BID_ENERGIE - Toto je množství energie ze zdroje, který byl nabídnut do programu
BID_LOAD - Toto je množství načtení, které bylo nabídnuto prostředkem do programu
BID_PRICE - Toto je cena, kterou nabídl zdroj
CHARGE_STATE - Stav zdroje skladování energie
DEMAND_CHARGE - Toto je poplatek za poptávku
ELEKTRICKÁ_CENA - To jsou náklady na elektřinu
ENERGY_PRICE - To jsou náklady na energii
LOAD_CONTROL -Nastavte výstup zatížení na relativní hodnoty
LOAD_DISPATCH - Používá se k odeslání nákladu
jednoduchý - znehodnocené - pro zpětnou kompatibilitu s A profile
JEDNODUCHÝ - Jednoduché úrovně (kompatibilní s OpenADR 2.0a)

typ signálu

Vyčíslená hodnota popisující typ signálu, jako je úroveň nebo cena

delta - Signál označuje množství, které se má změnit z toho, co by člověk použil bez signálu.
úroveň - Signál označuje úroveň programu.
násobitr - Signál označuje multiplikátor aplikovaný na aktuální rychlost dodávky nebo využití z toho, co by člověk použil bez signálu.
cena - Signál označuje cenu.
cena Násobekr - Signál označuje multiplikátor ceny. Rozšířená cena je vypočítaná hodnota ceny vynásobená počtem jednotek.
cena relativní - Signál označuje relativní cenu.
žádaná hodnota - Signál označuje cílové množství jednotek.
x-loadControlCapacity - Toto je pokyn, aby regulátor zátěže fungoval na úrovni, která je určitá procentatage jeho maximální spotřeby zatížení. To lze namapovat na konkrétní řadiče zátěže a provádět například cyklování provozu. Všimněte si, že 1.0 znamená 100% spotřebu. V případě jednoduchých zařízení typu ZAP/VYP pak 0 = VYPNUTO a 1 = ZAPNUTO.
x-loadControlLevelOffset - Diskrétní celočíselné úrovně, které jsou relativní k normálním operacím, kde 0 je normální operace.
x-loadControlPercentOffset - Procenttage změna oproti běžným operacím ovládání zátěže.
x-loadControlSetpoint - Nastavené hodnoty regulátoru zatížení.

- OpenADR A a B Profile Rozdíly

Jediná služba podporovaná A profile je služba EiEvent. Objekt EiEvent je v A pro zjednodušenfile s následujícími omezeními:

Na jednu událost je povolen pouze jeden signál a tento signál musí být dobře známý signál OpenADR JEDNODUCHÝ.
K dispozici je omezené cílení na události s podporou pouze venID, groupID, resourceID a partyID. (EiEvent: eiTarget).
Cílení na úrovni signálu pomocí tříd zařízení není podporováno (eiEventSignal: eiTarget: endDeviceAsset).
Základní linie nejsou podporovány (eiEvent: eiEventSignals: eiEventBaseline).
ModifikaceDateTime a modifikaceReason nejsou podporovány.
Koncový bod URL pro jednoduchý HTTP v 2.0b je:
- https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Některé prvky užitečného zatížení, které byly vyžadovány v A profile jsou nyní v B pro volitelnéfilevčetně:

současná cena

- Bezpečnostní certifikáty OpenADR

Pravidla shody OpenADR vyžadují následující:

TLS verze 1.2 se používá pro výměnu certifikátů X.509
VTN musí mít oba certifikáty SHA256 ECC a RSA
VEN mohou podporovat certifikáty SHA256 ECC a RSA a mohou podporovat oba
VTN i VEN musí být nakonfigurovány tak, aby vyžadovaly klientské certifikáty, pokud budou hrát roli transportního serveru (tj. Reagovat na požadavky druhé strany)
VTN i VEN musí na žádost druhé strany v rámci procesu vyjednávání TLS poskytnout certifikát klienta

Certifikáty poskytnuté NetworkFX budou specifické pro RSA nebo ECC. Vytvoření těchto certifikátů může nastat jako výsledek vyplňování formulářů na NetworkFX web web k vyžádání testovacích certifikátů nebo může být výsledkem žádosti o produkční certifikáty prostřednictvím žádosti o podpis certifikátu (CSR). Bez ohledu na metodu následující filebudou poskytnuty (napřampjsou zobrazeny soubory):

Kořenový certifikát
Průběžný kořenový certifikát
Certifikát zařízení
Soukromý klíč

Soukromý klíč se obecně používá k šifrování užitečných dat odesílaných VEN nebo VTN. Certifikát zařízení je sada jedinečných identifikačních informací o VEN nebo VTN, která byla vytvořena certifikační autoritou a zašifrována pomocí soukromého klíče. Kořen a meziprodukt files se používají k dešifrování certifikátu zařízení a ověření, že certifikát pochází od důvěryhodného orgánu.

V prostředí Java, které využívá JSSE, existují dvě úložiště certifikátů. Jeden se nazývá Trust Store a slouží k držení kořenového certifikátu. Druhý se nazývá úložiště klíčů a slouží k ukládání řetězce certifikátů skládajícího se z prostředního certifikátu certifikátu zařízení a soukromého klíče

Vezměte prosím na vědomí, že při použití přenosu XMPP komunikuje VEN se serverem XMPP a NE přímo s VTN. Konfigurace certifikátů na serveru XMPP tedy MUSÍ být ekvivalentní konfiguraci VTN. Komunikace mezi samotným VTN a serverem XMPP je pro VEN transparentní a je v zásadě soukromým odkazem. Většina dodavatelů nicméně při komunikaci se serverem XMPP použila sadu certifikátů VEN ve VTN.

Pokud používáte OpenFire jako svůj XMPP server, musíte vzít v úvahu další omezení. OpenFire vyžaduje, aby se název CN používaný v certifikátech klientských zařízení shodoval s uživatelským jménem XMPP zařízení nakonfigurovaným na serveru XMPP. To může mít za následek několik lichých názvů klientů, protože adresa MAC jako adresa se používá pro název CN na certifikátech VEN (součást bezpečnostních požadavků OpenADR)

Nakonec se většina VEN a VTN při hraní role transportního klienta pokusí ověřit, že pole CN certifikátu poskytovaného transportním serverem má název CN, který odpovídá názvu hostitele entity, která certifikát poskytla. Může to být další zdroj problémů s interoperabilitou při výměně certifikátů. Ověření názvu hostitele lze obvykle programově deaktivovat, aby se izolovaly tyto druhy problémů.

Průvodce programem OpenADR 2.0 Demand Response Program - Stáhnout [optimalizováno]
Průvodce programem OpenADR 2.0 Demand Response Program - Stáhnout

Reference

Uživatelská příručka

Zavedení

Reference

Termíny a definice

Zkratky

Typy programů odezvy na poptávku

Scénáře nasazení

Přímo 1

Přímo 2

Přímo 3

Přímo 4

Facilitátor 1

Agregátor 1

Scénář nasazení a mapování programu DR

Výběr šablony programu DR

Šablony programů na vyžádání

Kritický špičkový cenový program (CPP)

Charakteristiky programu CPP DR

Charakteristika OpenADR pro programy CPP

Program nabízení kapacit

Nabízení kapacity DR Charakteristiky programu

Charakteristiky OpenADR pro programy nabízení kapacity

Program bytových termostatů

Vlastnosti programového vybavení obytného termostatu DR

Charakteristika OpenADR pro programy obytných termostatů

Rychlé odeslání DR

Charakteristiky rychlého dispečerského programu

Charakteristiky OpenADR pro programy nabízení kapacity

Program doby používání obytných elektrických vozidel (EV) (TOU)

Charakteristiky rezidenčního programu EV TOU

Charakteristika OpenADR pro rezidenční programy EV TOU

Cenový program pro elektrická vozidla na veřejných stanicích (EV) v reálném čase

Charakteristika veřejné stanice EV RTP

Charakteristika OpenADR pro programy veřejné stanice EV RTP

Program DR s distribuovanou energií (DER)

Charakteristika programu Distribuované energetické zdroje (DER)

Charakteristika OpenADR pro distribuované energetické zdroje (DER)

Reference

Zanechte komentář

Zrušit odpověď