OpenADR 2.0

Vodnik po programu za odziv na povpraševanje

Številka revizije: 0.92

Status dokumenta: Delovno besedilo

Številka dokumenta: 20140701

Avtorske pravice © OpenADR Alliance (2014/15). Vse pravice pridržane. Informacije v tem dokumentu so last združenja OpenADR Alliance, njihova uporaba in razkritje pa sta omejena.

VSEBINA

1 Uvod 6

2 Reference 6

3 Izrazi in definicije 6

4 Okrajšave 9

5 Vrste programov za odziv na povpraševanje 9

6 Scenariji uvajanja 10

6.1 Neposredno 1 11

6.2 Neposredno 2 12

6.3 Neposredno 3 13

6.4 Neposredno 4 14

6.5 Moderator 1 15

6.6 Zbiralnik 1 16

7 Scenarij uvajanja in preslikava programa DR 16

8 Izbira predloge programa DR 18

9 Predloge programa odzivanja na povpraševanje 21

9.1 Program kritičnih najvišjih cen (CPP) 21

9.1.1 Značilnosti programa CPP DR 21

9.1.2 Značilnosti OpenADR za programe CPP 22

9.2 Program ponudb za zmogljivost 24

9.2.1 Značilnosti programa DR za ponujanje zmogljivosti 24

9.2.2 Značilnosti OpenADR za programe za ponudbe zmogljivosti 25

9.3 Program stanovanjskega termostata 27

9.3.1 Značilnosti programa bivalnega termostata DR 27

9.3.2 Značilnosti OpenADR za programe stanovanjskih termostatov 28

9.4 Hitro pošiljanje DR 29

9.4.1 Značilnosti programa za hitro pošiljanje DR 29

9.4.2 Značilnosti OpenADR za programe za ponudbe zmogljivosti 31

9.5 Program časa uporabe (TOU) za stanovanjska električna vozila (EV) 33

9.5.1 Značilnosti programa rezidenčnega EV TOU 33

9.5.2 Značilnosti OpenADR za rezidenčne programe EV TOU 33

9.6 Program za določanje cen v realnem času za javna električna vozila (EV) 34

9.6.1 Značilnosti programa javne postaje EV RTP 34

9.6.2 Značilnosti OpenADR za programe javne postaje EV RTP 34

9.7 Program DR za razpršene vire energije (DER) 35

9.7.1 Značilnosti programa za razpršene vire energije (DER) 35

9.7.2 Značilnosti OpenADR za porazdeljene vire energije (DER) 35

Priloga A – Sample Podatki in predloge tovora 36

A.1 Program kritičnih koničnih cen (CPP) 36

A.1.1 Scenarij CPP 1 – primer preproste uporabe, A ali B Profile 36

A.1.2 Scenarij CPP 2 – tipičen primer uporabe, B profile 36

A.1.3 Scenarij CPP 3 – primer zapletene uporabe 37

A.1.4 CPP Sample Event Payload – tipično B Profile Primer uporabe 37

A.2 Program zbiranja ponudb za zmogljivost (CBP) 39

A.2.1 Scenarij CBP 1 – primer preproste uporabe, A ali B Profile 39

A.2.2 Scenarij CBP 2 – tipičen primer uporabe, B profile 39

A.2.3 Scenarij CBP 3 – primer zapletene uporabe 40

A.2.4 CBP Sample Event Payload – tipično B Profile Primer uporabe 40

A.3 Program stanovanjskih termostatov 42

A.3.1 Stanovanjski termostat, scenarij 1 – primer preproste uporabe, A ali B Profile 42

A.3.2 Stanovanjski termostat, scenarij 2 – tipičen primer uporabe, B profile 42

A.3.3 Stanovanjski termostat, scenarij 3 – zapleten primer uporabe 43

A.3.4 Bivalni termostat Sample Event Payload – tipično B Profile Primer uporabe 43

A.4 Hitro pošiljanje DR 45

A.4.1 Fast DR Scenarij 1 – Primer preproste uporabe, A ali B Profile 45

A.4.2 Scenarij hitrega DR 2 – tipičen primer uporabe, B profile 45

A.4.3 Scenarij hitrega DR 3 – zapleten primer uporabe 46

A.4.4 Hitri DR Sample Event Payload – tipično B Profile Primer uporabe 46

A.4.5 Hitri DR Sample Poročilo o metapodatkih Koristno – tipično B Profile Primer uporabe 48

A.4.6 Hitri DR Sample Report Request Payload – Tipično B Profile Primer uporabe 48

A.4.7 Hitri DR Sample obremenitev podatkov poročila – tipično B Profile Primer uporabe 49

A.5 Program časa uporabe (TOU) za stanovanjska električna vozila (EV) 49

A.5.1 Scenarij 1 stanovanjskega električnega vozila – primer preproste uporabe, A ali B Profile 49

A.5.2 Stanovanjski EV, scenarij 2 – tipičen primer uporabe, B profile 50

A.5.3 Stanovanjski EV Sample Event Payload – tipično B Profile Primer uporabe 50

A.6 Program za določanje cen v realnem času za električna vozila javne postaje (EV) 53

A.6.1 Javna postaja EV Scenarij 1 – tipičen primer uporabe, B profile 53

A.6.2 Javna postaja EV Sample Event Payload – tipično B Profile Primer uporabe 53

A.7 Program razpršenih energetskih virov (DER) DR 54

Priloga B – Opredelitve storitve in tovora 55

B.1 Open ADR podpira naslednje storitve: 55

Priloga C – Definicije storitve in tovora 56

C.1 Koristne obremenitve EiEvent 56

C.2 Obremenitve EiReport 56

C.3 Koristne obremenitve EiOpt 56

C.4 Obremenitve EiRegisterParty 57

C.5 Obremenitve OadrPoll 57

Dodatek D – Glosar elementov koristne obremenitve sheme 58

Dodatek E Glosar oštevilčenih vrednosti 65

E.1 status dogodka 65

E.2 itemUnits 65

E.3 oadrDataQuality 65

E.4 oadrResponseRequired 66

E.5 optReason 66

E.6 oadrTransportName 66

E.7 OptType 66

E.8 readingType 66

E.9 ime poročila 67

E.10 reportType 67

E.11 lestvicaCode 68

E.12 ime signala 68

E.13 Vrsta signala 69

Priloga F – OpenADR A in B Profile Razlike 70

Priloga G – Varnostna potrdila OpenADR 71

Uvod

Ciljna skupina za ta priročnik so pripomočki, ki načrtujejo uvedbo programov odzivanja na povpraševanje (DR), ki uporabljajo OpenADR 2.0 za sporočanje sporočil, povezanih z dogodki DR, med pripomočkom in nadaljnjimi subjekti ter proizvajalci opreme, ki olajšajo to komunikacijsko izmenjavo. Predvideva se, da ima bralec osnovno konceptualno razumevanje odziva na povpraševanje in OpenADR 2.0 (od tu naprej imenovan preprosto OpenADR).

OpenADR profile specifikacije jasno opredeljujejo pričakovano vedenje pri izmenjavi informacij, povezanih z dogodki DR, vendar je v OpenADR dovolj možnosti, da uvedba strežnikov (VTN) pri pripomočku in odjemalcev (VEN) na nižjih mestih ni izkušnja plug-n-play. Značilnosti OpenADR, kot so signali dogodkov, formati poročil in ciljanje, je treba določiti na podlagi programa DR za vsak program posebej.

Ne obstaja standardiziran program DR. Vsaka zasnova programa DR je ponavadi edinstvena in ustreza strukturnim in regulativnim zahtevam geografske regije, v kateri je nameščen. Za vsak program DR obstajajo številni možni scenariji uvedbe, ki vključujejo različne akterje.

Spremenljivost v zasnovah programa DR, scenarijih uvajanja in značilnostih OpenADR zavira razširjeno uvajanje DR in uporabo OpenADR. Ta spremenljivost je večinoma odraz razdrobljene in kompleksne narave pametnega omrežja.

Komunale potrebujejo exampdatoteke tipičnih programov DR, tako da jih je mogoče uporabiti kot modele za lastne implementacije programov DR. Proizvajalci opreme morajo razumeti tipične modele uporabe programa DR, da lahko potrdijo interoperabilnost kot del razvojnega procesa in ne na podlagi specifične uvedbe programa DR. Namen tega vodnika je doseči oba cilja na naslednji način:

• Določite majhen nabor standardnih predlog programov DR, oblikovanih po skupnih značilnostih najbolj priljubljenih programov DR, implementiranih do danes
• Določite majhen niz scenarijev uvajanja po vzoru uvajanja v resničnem svetu, z jasno opredeljenimi akterji in vlogami
• Določite priporočila za najboljše prakse za značilnosti OpenADR, specifične za vsako od predlog programa DR
• Zagotovite drevo odločitev, ki ga lahko pripomočki uporabijo za prepoznavanje uporabnih predlog programov DR in scenarijev uvajanja na podlagi njihovih poslovnih potreb

Poudarek v tem priročniku bo na ohranjanju preprostih stvari z zagotavljanjem majhnega nabora jasnih priporočil, ki bodo obravnavala večino podrobnosti, potrebnih za uvedbo tipičnega programa DR, in omogočila testiranje interoperabilnosti opreme, nameščene v programih, z uporabo priporočil v tem vodnik.

Reference

• OpenADR Profile Specifikacija in shema – www.openadr.org

Izrazi in definicije

V tem dokumentu so uporabljeni naslednji izrazi in definicije.

• Odziv na povpraševanje: Mehanizem za upravljanje povpraševanja po obremenitvah strank kot odgovor na pogoje dobave, kot so cene ali signali razpoložljivosti
• Agregator Party – To je stranka, ki združuje več virov in jih predstavi stranki programa DR kot en sam vir v svojih programih DR.
• Vmesna infrastruktura zbiralnika – To je infrastruktura, ločena od infrastrukture na strani povpraševanja, ki jo posredniška stranka agregator uporablja za interakcijo z viri in subjekti na strani omrežja
• dogovor: Pogodbeni sporazum med strankami, ki igrajo vlogo v programu DR, ki opisuje odgovornosti in nadomestila
• Sredstvo – Vrsta vira, ki predstavlja specifično zbirko fizičnih obremenitev. Viri so lahko sestavljeni iz sredstev in sredstvo je lahko vir, vendar sredstev ni mogoče nadalje razčleniti na več sredstev ali virov.
• Povezano: Zagotovite programsko povezavo med dvema entitetama prek konfiguracije naprave baze podatkov. Na primer, povezani viri z VEN
• Osnovne črte: Izračunana ali izmerjena poraba energije (povpraševanje) za del opreme ali mesto pred dogodkom, kot je določeno z raziskavami, inšpekcijami in/ali merjenjem na mestu.
• BMS – To je sistem za upravljanje stavbe, ki se lahko uporablja za nadzor virov. To se včasih imenuje sistem upravljanja z energijo.
• Sestavljeni vir – To je posebna vrsta vira, ki je skupek več fizičnih sredstev, od katerih ima vsako svoje sredstvo za nadzor obremenitve.
• Spodbuda za stranke: Spodbuda, zagotovljena lastniku/združevalcu virov na strani povpraševanja za sodelovanje v programu DR.
• Infrastruktura na strani povpraševanja – To je infrastruktura, v kateri so viri, ki so vpisani v programe DR
• DR Logika: Algoritmi ali logika, ki pretvorijo signale DR v uporabno kontrolo obremenitve. Upoštevajte, da je DR Logic mogoče implementirati na več različnih lokacijah in v nekaterih primerih razdeliti med več podsistemov.
• Stranka programa DR – to je subjekt, ki je odgovoren za infrastrukturo omrežja in poleg tega za upravljanje programov DR, ki se uporabljajo za ublažitev težav z omrežjem. To je običajno Utility ali ISO.
• Vpisana: Lastnik/združevalec virov na strani povpraševanja se odloči za sodelovanje v programu DR in lahko zagotovi informacije o specifičnih virih, ki so lahko ciljni za dogodke DR.
• Aktivno obdobje dogodka: je obdobje v času, v katerem se spremeni obremenitev profile se zahteva kot del dogodka DR
• Omejitve dogodkov: Časovni okviri, v katerih lahko stranka pričakuje, da bo prejela dogodke in s tem povezane omejitve, kot je brez dogodkov ob vikendih ali zaporednih dneh.
• Dnevi dogodkov: dan, ko se zgodi dogodek DR. Večina programov ima omejitve glede števila dni dogodkov, ki so dovoljeni v določenem koledarskem obdobju
• Deskriptor dogodka: del predmeta dogodka OpenADR, ki opisuje metapodatke o dogodku, kot sta ime programa in prednost dogodka
• Trajanje dogodka: Dolžina dogodka. Večina programov določa omejitve glede dolžine dogodka, pa tudi ur v dnevu, v katerih se dogodek lahko zgodi
• Signali dogodkov: Informacije, ki jih je mogoče ukrepati, vsebovane v dogodku, kot je cena električne energije ali zahtevana določena raven zmanjšanja obremenitve, ki običajno sproži določeno vnaprej programirano vedenje zmanjšanja obremenitve s strani prejemnika dogodka. Definicija programa DR bi morala določati vrste uporabljenih signalov dogodkov
• Ciljanje na dogodek: Viri za razbremenitev, ki so predvideni prejemniki za dogodek DR. Lahko je geografsko območje, določen razred naprav, identifikator skupine, ID vira ali drug identifikator. Opredelitev programa DR bi morala določati, kako bodo določeni viri ciljno usmerjeni.
• Dogodki: Dogodek je obvestilo pripomočka za vire na strani povpraševanja, ki zahtevajo zmanjšanje obremenitve, ki se začne ob določenem času, v določenem trajanju, in lahko vključuje informacije o ciljanju, ki določajo posebne vire, ki bi morali sodelovati pri dogodku
• Infrastruktura posrednika posrednika – To je infrastruktura, ločena od infrastrukture na strani povpraševanja, ki jo uporablja povezovalna posredniška stranka za interakcijo z viri in entitetami na strani omrežja.
• Pospeševalec: Tretja oseba, ki upravlja del ali celotno izvajanje programa DR v imenu pripomočka
• Mrežna infrastruktura – To je infrastruktura, ki je v lasti ali upravljanju pogodbenic programa DR. Ta infrastruktura vključuje implementacijo OpenADR VTN, ki se uporablja za pošiljanje signalov DR do virov, vpisanih v programe DR
• posredniška stranka – To je stranka, ki običajno deluje v imenu Resource Party, da olajša njihovo sodelovanje v programih DR.
• Nadzor obremenitve – to je infrastruktura, povezana z virom, ki je odgovorna za dejanski nadzor nad virom in ustvarjanje specifičnega obremenitvenega profile.
• Naloži Profile Cilj: Ta motivacija za razvoj programa DR in izdajanje dogodkov. Kot na primer želja po britju koničnih obremenitev.
• Obvestilo: Časovno obdobje pred začetnim časom dogodka, ko je lastnik vira na strani povpraševanja obveščen o čakajočem dogodku
• Opt Behavior: pričakovan odziv lastnika vira na strani povpraševanja po prejemu dogodka. Ta odgovor ima lahko obliko in navedbo OptIn ali OptOut, ali bo vir sodeloval ali ne
• Opt Responses: Ali naj določen program zahteva odziv virov na strani povpraševanja kot odgovor na dogodek in kakšni so ti odzivi.
• Opt Storitve: Razporedi, posredovani prek OpenADR, ki označujejo začasne spremembe v razpoložljivosti virov za udeležbo na dogodkih.
• Predpogoj: Merila, ki morajo biti izpolnjena, da se lahko lastnik virov na strani povpraševanja vpiše v program DR. To lahko vključuje razpoložljivost intervalnih sestankov ali minimalno zmogljivost razbremenitve
• Primarni gonilniki: Osnovna motivacija s strani pripomočka za ustvarjanje programa DR in izdajanje dogodkov. Kot na primer »Zmanjšanje največjega povpraševanja in zadostnost virov«
• Programi – To so programi DR, v katere so vpisani viri.
• Opis programa: pripovedni opis delovanja programa. Del predlog programa DR, opredeljenih v tem dokumentu
• Časovni okvir programa: letni čas ali letni časi med programom DR so običajno aktivni
• Ocenite oblikovanje: Posebne spremembe strukture obrestne mere ali spodbude, plačane za motiviranje lastnikov virov na strani povpraševanja, da sodelujejo v programu
• Registracijske storitve: Storitev, ki jo uporablja protokol OpenADR za vzpostavitev osnovne interoperabilnosti med VTN in VEN ter za preverjanje, ali je VEN povezan z računom odjemalcev javnega podjetja.
• Storitve poročanja: Storitev, ki jo OpenADR uporablja za omogočanje VEN-jem poročanja VEN-jem. Program DR mora določiti zahteve za poročanje za program.
• Resource Party – To je stranka, ki ima v lasti vire na strani povpraševanja, ki so lahko vključeni v programe DR
• Vir – To je entiteta, ki je vpisana v programe DR in je sposobna zagotoviti nekakšno spremembo svojemu nalagalnemu profile kot odgovor na sprejem signala DR od VTN.
• Ciljna stranka: Profesionalecfile virov na strani povpraševanja, ki se lahko vključijo v posebne programe DR, kot so stanovanjski, industrijski ali morda na podlagi ravni porabe električne energije.
• Ciljne obremenitve: Viri na strani povpraševanja, katerih obremenitev je treba spremeniti po prejemu a
• VEN – To je navidezno končno vozlišče OpenADR, ki se uporablja za interakcijo z VTN.
• VTN – To je navidezno zgornje vozlišče OpenADR, ki se uporablja za interakcijo z viri, vpisanimi v programe DR.

Okrajšave

• BMS: Sistem upravljanja zgradb
• C&I: komercialno in industrijsko
• Št: Komunikacije med dvema entitetama
• DR: Odziv na povpraševanje
• EMS: Sistem upravljanja z energijo
• OpenADR: Odprite avtomatiziran odziv na povpraševanje
• Programi: Sklicevanje na programe za odziv na povpraševanje
• VEN: Navidezno končno vozlišče
• VTN: Navidezno zgornje vozlišče

Vrste programov za odziv na povpraševanje

Ta dokument vsebuje predloge za programe DR, prikazane spodaj.

 

1. Kritično najvišje cene: Stopnja in/ali cenovna struktura, zasnovana za spodbujanje zmanjšane porabe v obdobjih visokih veleprodajnih tržnih cen ali nepredvidenih sistemskih težav z uvedbo vnaprej določene visoke stopnje ali cene za omejeno število dni ali ur.

2. Program zbiranja ponudb za zmogljivost: Program, ki viru povpraševanja na maloprodajnih in veleprodajnih trgih omogoča, da ponudi zmanjšanje obremenitve po določeni ceni ali ugotovi, koliko obremenitve je pripravljen zmanjšati po določeni ceni.

 

3. Program stanovanjskega termostata/neposredni nadzor obremenitve: Dejavnost odzivanja na povpraševanje, s katero sponzor programa na daljavo nadzoruje strankino električno opremo (npr. klimatsko napravo) v kratkem času. Ti programi so v prvi vrsti na voljo rezidenčnim ali malim komercialnim uporabnikom.

4. Program hitre dispečerske/pomožne storitve DR: program odzivanja na povpraševanje, ki zagotavlja spodbujevalna plačila strankam za odziv na obremenitev med dogodkom odziva na nujne primere. Nenormalno stanje sistema (nprample, sistemske omejitve in lokalne omejitve zmogljivosti), ki zahteva samodejno ali takojšnje ročno ukrepanje za preprečitev ali omejitev okvare prenosnih naprav ali oskrbe s proizvodnjo, ki bi lahko negativno vplivala na zanesljivost električnega sistema v velikem obsegu. Te vrste programov se lahko včasih imenujejo "pomožne storitve".

5. Program DR za električna vozila (EV).: dejavnost odzivanja na povpraševanje, s katero se stroški polnjenja električnih vozil spremenijo tako, da potrošniki spremenijo vzorce porabe.

6. Program DR za porazdeljene energetske vire (DER).: dejavnost odzivanja na povpraševanje, ki se uporablja za nemoteno integracijo distribucijskih energetskih virov v pametno omrežje.

 

Scenariji uvajanja

Način, na katerega je razporejen program DR, je nekoliko neodvisen od značilnosti samega programa DR. Naslednji diagrami prikazujejo različne načine, na katere je mogoče razmestiti program DR. Naslednji razdelek ponuja navzkrižno sklicevanje med scenariji uvajanja in programi DR, s katerimi se bodo najverjetneje uporabljali.

Diagrami v tem razdelku prikazujejo odnose med entitetami v različnih scenarijih.

Neposredno 1

To je preprost scenarij, v katerem obstaja neposredno razmerje med programsko stranko DR in stranko virov. Stranka za vir je odgovorna za vključitev lastnih virov v programe DR, infrastruktura omrežja pa neposredno komunicira z viri prek VEN, ki se nahaja znotraj infrastrukture na strani povpraševanja. Poleg tega je VEN v lasti stranke virov in je ločen od virov in njihovih upravljavcev. Ko VEN prejme signal DR, običajno ne izvaja nobene logike nadzora obremenitve, ampak preprosto posreduje signale krmilnikom obremenitve, ki izvedejo ustrezen ukrep. nprampLes tega scenarija bi vključeval zgradbe C&I, ki lahko namestijo prehod, ki vsebuje OpenADR VEN, in ko ta prehod sprejme signal, ga preprosto prevede v nek drug protokol in posreduje samim krmilnikom obremenitve.

Neposredno 2

To je zelo podobno scenariju Direct 1. Glavna razlika je v tem, kako se ustvari primerek VEN in omogočijo interakcije z VTN. VEN je instanciran v entiteti, kot je centraliziran BMS, ki lahko izvaja logiko DR in komunicira s Compound Resource in njihovimi številnimi različnimi krmilniki obremenitve z bolj centralizirane lokacije. nprampvključujejo velike zgradbe z BMS, ki nadzorujejo veliko različnih obremenitev v stavbi (npr. razsvetljava, HVAC, industrijski procesi itd.), da campuporabe, ki imajo lahko več objektov s centraliziranim nadzornim sistemom.

Neposredno 3

Ta scenarij je zelo podoben scenariju Direct 1. Glavna razlika je v tem, da je VEN instanciran neposredno v viru in njegovem krmilniku obremenitve. V tem primeru se signali DR pošljejo neposredno viru in njegovemu krmilniku obremenitve. V to kategorijo spada tako imenovani scenarij »prices to devices«. npramples bi vključeval kakršen koli krmilnik obremenitve, kot je HVAC (tj. termostat), ki ima vdelan VEN, ki je sposoben neposredne interakcije z entitetami VTN na strani omrežja.

Neposredno 4

To je kombinacija neke vrste scenarijev Direct 1 in Direct 2. Glavna razlika je v tem, da je več VEN-jev povezanih z enim sestavljenim virom, ki je sestavljen iz več sredstev z lastnimi krmilniki obremenitve. Vsak od krmilnikov obremenitve, ki sestavljajo sestavljeni vir, je lahko povezan z drugim VEN. Upoštevajte, da bi bili vsi VEN-ji pod nadzorom iste stranke virov, ki ima v lasti sestavljeni vir. Ta scenarij obstaja za olajšanje infrastruktur na strani povpraševanja, ki imajo sestavljene vire, vendar nimajo centraliziranega BMS, kot je scenarij Direct 2. npramplahko vključujejo zgradbe z različnimi krmilniki obremenitve v vsakem nadstropju, vendar brez centraliziranega BMS ali campuporablja z različnimi krmilniki v vsaki stavbi, vendar ne campus širok krmilnik. Ker je z vidika stranke programa DR v program vpisan samo en vir, ko želi viru poslati signal DR, lahko preprosto pošlje iste signale vsaki od določenih VEN, ki so bile povezane z virom.

Pospeševalec 1

V tem scenariju obstaja posrednik, ki olajša interakcije med stranko programa DR in viri. Običajno posredniška stranka deluje v imenu stranke virov, da ji pomaga pri upravljanju njihovih virov. Stranke virov imajo neposredne odnose s stranko programa DR in v programe DR vpisujejo lastne vire. Tako Programska stranka DR viewje vsaka stranka vira kot ločen vir in lahko z njimi komunicira posamično. Vloga posredniške stranke je, da deluje kot posrednik za vse interakcije, povezane z OpenADR, zato je VEN instanciran znotraj posredniške infrastrukture posrednika. Takšna infrastruktura so pogosto baze v oblaku in se strankam virov ponujajo kot programska oprema kot storitev (SaaS). Ko moderatorjev VEN prejme signal DR, se lahko zgodi več različnih dejanj, vključno s posredovanjem signala DR ustreznemu viru in morebitno implementacijo neke vrste logike DR ter pošiljanje ukazov za nadzor obremenitve krmilniku obremenitve vsakega vira. nprampdel tega scenarija vključuje:

• Prodajalci, ki upravljajo objekte za velike komercialne verige, kot so veletrgovci na drobno.
• Posredniki za industrijski nadzor.
• Podjetja za energetske storitve (ESCO)
• Sistemi za upravljanje aparatov in naprav, ki temeljijo na oblaku, kot so nastajajoči prodajalci termostatov s pametnim komuniciranjem.

Zbiralnik 1

Ta scenarij je podoben scenariju Facilitator. Glavna razlika je v tem, da ima agregatorska stranka razmerje s programsko stranko DR v nasprotju s strankami virov. Zbiralec združuje več sredstev strank v en sam vir, ki ga vključi v programe DR. Stranka programa DR nima vpogleda v posamezna sredstva, ki jih upravlja združevalec. Tako kot pri pospeševalniku ima tudi zbiralnik lastno infrastrukturo, kjer se VEN instancira. Razlika je v tem, da se ob prejemu signala DR sklicuje na en sam vir, agregator pa izvaja nekakšno logiko DR za vsa sredstva v svojem portfelju, da doseže cilje, določene v signalu DR.

 

Scenarij uvedbe in preslikava programa DR

Spodnja tabela prikazuje, kateri scenariji uvajanja so najpogostejši za določen program DR.

	Scenarij uvajanja
Predloga DR	Neposredno 1, 2, 3, 4	Pospeševalec 1	Zbiralnik 1
Program CPP	∆	∆
Program zbiranja ponudb za zmogljivost			∆
Stanovanjski termostat Program		∆
Hitro odpošiljanje DR			∆
Program DR za električna vozila (EV).	∆	∆
Program DR za porazdeljene energetske vire (DER).	∆	∆

Izbira predloge programa DR

Sledi nabor vprašanj, ki so pomembna za katero koli podjetje, ki bo uvedlo nov program DR. To ni mišljeno kot izčrpno, ampak predstavlja nekaj bolj pomembnih vprašanj. Namen teh vprašanj je pomagati usmerjati pripomočke k ustreznemu nizu predlog programa DR.

V: Zakaj želite delati DR? Kakšno stanje omrežja ali operativno težavo poskušate ublažiti z DR?

To je daleč najpomembnejše vprašanje in tvori osnovo za splošne zahteve in cilje, kaj naj bi program DR dosegel. Odgovor na to vprašanje določa, kako obremenitev na strani povpraševanja profile naj bi oblikoval program DR. Vse druge zahteve izhajajo iz odgovora na to vprašanje.

• Ali poskušate obriti konice?
• Ali želite napolniti račji trebuh?
• Ali poskušate zavarovati promptno ceno električne energije?
• Vas skrbi zanesljivost omrežja?
• Ali poskušate ohraniti sredstva omrežja?
• Itd itd itd.

Spodnja tabela ponuja nekaj dodatnega konteksta za motivacijo za željo po razvoju programa DR

Zanesljivost in varnost omrežja	Frekvenca in voltage Stabilnost
	Ustreznost virov
	Najvišja zmogljivost
	Ramping
	Kontingenca
Nabava energije	Promptne tržne cene
	Arbitraža cen
Upravljanje premoženja	Preprečevanje škode
	Zmanjšanje vzdrževanja
	Podaljšanje življenjske dobe
Upravljanje zmogljivosti	Gospodarske koristi
	Upravljanje v izrednih razmerah
Okoljski	Negavat
	Čista energija

V: Ali za ta program že obstaja program DR ali tarifa?

• Pravila programa so pogosto izrecno navedena v tarifi.

V: Na kateri tržni segment povpraševanja ciljate s tem programom?

To lahko pomaga določiti ciljanje virov v dogodku in vrsto signala.

• Stanovanjski
• Velik C&I
• Mali C&I
• Kmetijstvo
• Upravljanje z vodami
• Električna vozila
• Itd, itd, itd

V: Ali poskušate ciljati na določene vrste obremenitev?

• Termostati
• Električna vozila
• Ag črpalke
• itd.

V: Kakšen je vaš model uvajanja?

Odgovor na to vprašanje lahko vpliva na to, kako so viri opredeljeni v programu, in določi, kako so ti viri ciljno usmerjeni v dogodkih.

• Neposredno do strank
• Prek posrednikov, kot so združevalci ali pospeševalci
• Stranka odgovorna za nabavo in namestitev lastne opreme VEN?
• itd.

V: Na kateri ravni specifičnosti želite komunicirati z obremenitvami na strani povpraševanja?

To vprašanje je nekoliko povezano z modelom uvajanja in določa, kako so viri v programu definirani in ciljno usmerjeni. To je eno najpomembnejših in morda zapletenih vprašanj.

• Interakcija z vsakim posameznim virom
• Interakcija prek posrednika ali zbiralnika brez specifikacije virov, ki stojijo za njimi
• Sodelujte prek pospeševalca ali združevalca IN določite, kateri viri za njimi naj se pošljejo
• Uporabite lokacijo kot atribut za določanje virov
• Za določitev virov uporabite nekakšen mehanizem združevanja, definiran s pripomočkom
• Ciljajte na posamezna sredstva, kot so termostati
• Interakcija brez kakršnih koli virov in samo oddajanje dogodkov DR
• itd.

V: Kakšen vzorec interakcije želite uporabiti, da bi vplivali na nalaganje strankfiles?

To vprašanje določa vrsto signalov DR, ki bodo poslani udeležencem v programu.

• Spodbude (npr. dinamične cene)
• Odpreme tovora (npr. pomožne storitve)
• Direkten nadzor obremenitve
• Generični signal dogodka
• itd.

V: Kakšni so splošni atributi programa za razporejanje virov?

• Datumi in ure, ko se lahko sklicujejo dogodki
• Pogostost dogodkov
• Trajanje dogodkov
• Dovoljene zakasnitve za širjenje dogodkov
• itd.

V: Kako se določi razpoložljivost virov v programu?

• Po strogih programskih pravilih
• Kot del postopka imenovanja ali zbiranja ponudb, ki ga izvede vir
• Ali je možnost vključitve/odjave dovoljena?
• itd.

V: Kakšno vrsto vpogleda potrebujete za delovanje vira?

To je zelo široko vprašanje in določa, katere vrste informacij se vračajo iz virov v programu DR. Na splošno to določa vrsto poročil, ki so potrebna.

• V spletu / brez povezave
• Uporaba (trenutna in/ali pretekla)
• Potencial odziva na obremenitev
• Razpoložljivost obremenitve
• Stanje obremenitve/sredstva (trenutno in/ali preteklo)
• itd. itd. itd.

Predloge programa za odziv na povpraševanje

Program kritičnih najvišjih cen (CPP)

Značilnosti programa CPP DR

Naloži Profile Cilj	- Zmanjšanje največjega povpraševanja
Primarni gonilniki	- Zmanjšani kapitalski izdatki in zmanjšani stroški energije
Opis programa	Ko javna podjetja opazijo ali predvidevajo visoke veleprodajne tržne cene ali izredne razmere v elektroenergetskem sistemu, lahko kličejo kritične dogodke v določenem časovnem obdobju (npr. od 3 do 6 na vroč poletni dan v tednu), cena električne energije v teh obdobjih je znatno dvignjen.
Spodbuda za stranke	Strankam lahko ponudimo znižane cene energije v času, ko ni konic, kot spodbudo za sodelovanje v programu.
Ocenite oblikovanje	CPP je cenovni program z zvišanjem stopenj med kritičnimi konicami porabe energije. Običajno so stopnje CPP seštevalec ali množitelj k pavšalnim, večstopenjskim ali TOU osnovnim stopnjam.
Ciljna stranka	-Stanovanjsko ali C&I
Ciljna obremenitev	-Kateri koli
Predpogoj	-Odjemalec mora imeti intervalno merjenje - Stranke C&I bodo morda morale izpolniti merilo povpraševanja
Časovni okvir programa	- Običajno zajema mesece v letu, ko pride do največje porabe energije, čeprav je lahko v nekaterih primerih vse leto.
Omejitve dogodkov	- Običajno od ponedeljka do petka, razen praznikov, običajno so dovoljeni zaporedni dnevni dogodki
Dnevi dogodkov	- Običajno 9 do 15 na leto
Trajanje dogodka	- Običajno v določenem časovnem okviru za vse dogodke, ki traja od 4 do 6 ur v času dneva z največjo porabo energije.
Obvestilo	-Običajno dan vnaprej
Opt Behavior	- Običajno strankam ni treba sodelovati na dogodkih
Certificiranje Dogodki	- Običajno nič

Značilnosti OpenADR za programe CPP

Signali dogodkov	–PREPROSTI signal z ravnmi od 1 do 3, preslikanim na vpliv dogodka CPP na cene. Če ima program CPP eno komponento določanja cen, jo je treba preslikati na raven 1. Za programe CPP z več komponentami določanja cen je treba najmanjšo komponento cene preslikati na raven 1, druge komponente cene pa so preslikane na ravni 2 in 3 v vse večji meri vpliva na ceno. -Če uvedba podpira B profile VEN, poleg signala SIMPLE je lahko vključen signal ELECTRICITY_PRICE v nosilcu z vrsto priceRelative, priceAbsolute ali priceMultiplier, odvisno od narave programa. Glej prilogo A za npramples.
Opt Responses	-VTN pošiljanje dogodkov mora element oadrResponseRequired nastaviti na "vedno", ki zahteva, da se VEN odzove z optIn ali optOut -Ker je sodelovanje v programu CPP vaja po najboljših močeh, ni uradnega pomena privolitve ali odjave razen vljudnostne navedbe razpoložljivosti namena sodelovanja. To priporočamo VEN-ji se odzovejo z optIn, razen če je stranka izvedla kakšno posebno preglasitveno dejanje. - Koristni tovor oadrCreateOpt se običajno ne bi uporabljal za kvalificiranje virov, ki sodelujejo v dogodkih.
Deskriptor dogodka	- Dogodek prioriteta mora biti nastavljena na 1 razen če pravila programa ali konfiguracija VTN določajo drugače –Testni dogodki se običajno ne uporabljajo s programi CPP. Če pa so dovoljeni, mora biti element testEvent nastavljen na »true«, da označuje preskusni dogodek. Če so v tem elementu potrebne dodatne parametrizirane informacije, lahko sledi »true«, ločen s presledkom s temi dodatnimi informacijami.
Aktivno obdobje dogodka	– eiRampUp, eiRecovery, tolerančni elementi se običajno ne uporabljajo
Osnovne črte	–Osnovne črte običajno niso vključene v tovor dogodka
Ciljanje na dogodek	- Programi CPP običajno ne razlikujejo med viri za dano stranko. Ciljanje običajno določa venID, ki nakazuje, da morajo sodelovati vsi viri, povezani z VEN, ali seznam vseh ID-jev virov povezana z VEN.
Storitve poročanja	–Poročanje o telemetriji se običajno ne uporablja ker ni nujno potreben za programe CPP. Glejte Prilogo B za nprampdatoteke poročil pilotnih projektov javnih služb, ki bi se lahko uporabljale za to vrsto programa.

Opt Storitve	–Uporaba storitve Opt za sporočanje urnikov začasne razpoložljivosti običajno ne bi uporabljali kot del programa CPP. Vendar bi lahko nekatere uvedbe uporabile to storitev za ohranitev razpoložljivih dni dogodkov za stranke, ki navedejo pomanjkanje razpoložljivosti.
Registracijske storitve	Intervali anketiranja zahteva VTN za tipične programe CPP za dan vnaprej ni potrebno pogosteje kot enkrat na uro. Vendar pa lahko uporaba anketiranja za zaznavanje srčnega utripa zahteva pogostejše anketiranje.

Program zbiranja ponudb za zmogljivost

Značilnosti programa DR za ponudbe zmogljivosti

Naloži Profile Cilj	- Zmanjšanje največjega povpraševanja in zadostnost virov
Primarni gonilniki	- Zmanjšani kapitalski izdatki in zmanjšani stroški energije
Opis programa	Program ponujanja zmogljivosti uporabljajo ISO/komunalne službe za pridobitev vnaprej določene zmogljivosti razbremenitve od agregatorjev ali samozdruženih strank. To vnaprej določeno zmogljivost zmanjšanja obremenitve uporabljajo ISO/oskrba, ko opazijo ali predvidevajo visoke veleprodajne tržne cene, izredne razmere v elektroenergetskem sistemu ali kot del običajne uporabe energetskih virov s klicanjem dogodkov DR v določenem časovnem obdobju.   Upoštevajte, da je vsak agregator običajno odgovoren za oblikovanje lastnega programa odzivanja na povpraševanje, kot tudi za pridobivanje strank in obveščanje o dogodkih, da bi izpolnili zaveze glede zmogljivosti, sprejete kot del tega programa.
Spodbuda za stranke	Zbiralniki/stranke prejmejo dve vrsti spodbud. Prvič, prejmejo plačilo zmogljivosti za zadrževanje določene količine zmogljivosti razbremenitve, ki je na voljo za dogodke DR v prihodnjem časovnem oknu. Drugič, če se dogodek kliče v prihodnjem časovnem oknu, se lahko izvede plačilo energije za zmanjšanje obremenitve med trajanjem dogodka.
Ocenite oblikovanje	Udeleženci v programu podajo ponudbo za "nominacijo zmogljivosti", ki navaja zmogljivost razbremenitve, ki so jo pripravljeni imeti na voljo v prihodnjem časovnem oknu. Ponudba lahko vključuje tudi spodbudo, ki jo je združevalec/stranka pripravljen sprejeti za zmanjšanje obremenitve pod osnovno vrednostjo. Na trgih javnih storitev je zaveza glede zmogljivosti običajno za naslednji koledarski mesec, čeprav se na trgih ISO uporabljajo veliko daljši časovni okviri. Kot del nominacije zmogljivosti lahko stranka izbira med številnimi značilnostmi, vključno z dnevom vnaprej ali dnevom obvestila in oknom trajanja dogodka (kot je 1-4 ure, 2-6 ur, …). Stranki se za to vnaprejšnjo obveznost izplača zmogljivost, tudi če v časovnem oknu ni klicanih dogodkov. Če se med časovnim oknom sproži dogodek, lahko odjemalec prejme plačilo energije za razbremenitev glede na izhodišče, vendar se lahko uporabijo kazni, če je v času klica dogodka dobavljena manjša od vnaprej dogovorjene zmogljivosti razbremenitve.
Ciljna stranka	- Zbiralniki in samozdružene stranke C&I
Ciljne obremenitve	- Kaj

Predpogoj	-Odjemalec mora imeti intervalno merjenje - Stranke C&I bodo morda morale izpolniti merilo povpraševanja ali ponudbe
Časovni okvir programa	-Kadarkoli
Omejitve dogodkov	- Običajno od ponedeljka do petka, razen praznikov, običajno so dovoljeni zaporedni dnevni dogodki
Dnevi dogodkov	- Običajno največ 30 ur na mesec
Trajanje dogodka	- Običajno med fiksnim časovnim oknom za vse dogodke v času največje porabe energije v dnevu.). Trajanje dogodka se razlikuje glede na zavzetost zmogljivosti stranke s preferencami od 1 do 8 ur ali kot je določeno z zasnovo programa
Obvestilo	- Dan vnaprej ali dan naprej, odvisno od preferenc glede zmogljivosti stranke ali zasnove programa
Opt Behavior	- Običajno bi se stranke odločile za udeležbo na dogodkih, saj imajo vnaprej določeno zmogljivost razbremenitve.
Certificiranje Dogodki	- Običajno dva na leto (test)

Značilnosti OpenADR za programe ponujanja zmogljivosti

Signali dogodkov	–PREPROSTI signal s stopnjami od 1 do 3, preslikanimi na količino razbremenitve. Če program podpira samo eno raven razbremenitve, je treba to preslikati na raven 1. Za programe z več ravnemi razbremenitve je treba najmanjšo spremembo običajnega delovanja preslikati na raven 1, pri čemer so vrednosti razbremenitve preslikane v stopnje 2 in 3 v naraščajoči stopnji razbremenitve. -Če uvedba podpira B profile VEN, poleg signala SIMPLE je lahko vključen signal BID_LOAD in/ali BID_PRICE v koristnem tovoru z vrstami signalov nastavljene vrednosti in cene ter enotami PowerReal oziroma valutaPerKW. BID_LOAD bi odražal zahtevano obremenitev, zmanjšano do zneska zmogljivosti, ki ga je ponudil zbiralnik/stranka, BID_PRICE pa bi odražal spodbujevalno ponudbo zbiralnika/stranke. Glej prilogo A za npramples.
Opt Responses	-VTN pošiljanje dogodkov mora element oadrResponseRequired nastaviti na "vedno", ki zahteva, da se VEN odzove z optIn ali optOut - Ker imajo združevalci/stranke vnaprej dodeljene zmogljivosti VEN-ji bi morali odgovoriti z optIn. Zavrnitev je lahko poslana kot odgovor na dogodek, vendar je to neuraden pokazatelj razpoložljivosti, ne uradna zavrnitev dogodka. -The koristni tovor oadrCreateOpt običajno ne bi bil uporabljen za kvalificiranje virov, ki sodelujejo v dogodkih, saj je običajno obremenitev ena sama združena entiteta.
Deskriptor dogodka	- Dogodek prioriteta mora biti nastavljena na 1 razen če pravila programa ali konfiguracija VTN določajo drugače –Uporabijo se lahko preskusni dogodki s programi ponujanja zmogljivosti. Če so dovoljeni, mora biti element testEvent nastavljen na »true«, da označuje preskusni dogodek. Če so v tem elementu potrebne dodatne parametrizirane informacije, lahko sledi »true«, ločen s presledkom s temi dodatnimi informacijami.
Aktivno obdobje dogodka	– eiRampUp, eiRecovery, tolerančni elementi se običajno ne uporabljajo
Osnovne črte	–Osnovne črte običajno niso vključene v tovor dogodka ker ti podatki običajno niso na voljo v času, ko se dogodek začne. Vendar bi tako javne službe kot zbiralci/stranke view vključitev osnovnih informacij v dogodke kot uporabne.
Ciljanje na dogodek	- Programi ponudbe zmogljivosti običajno ne razlikujejo med viri za dano stranko. Ciljanje običajno določa venID, ki nakazuje, da morajo sodelovati vsi viri, povezani z VEN, ali vključuje resourceID, ki predstavlja agregirano obremenitev povezana z VEN.
Storitve poročanja	Programi ISO Capacity Bidding običajno zahtevajo poročila TELEMETRY_USAGE s podatkovnimi točkami powerReal. Glej prampv prilogi A. Poročanje o telemetriji za licitiranje zmogljivosti električnega omrežja običajno ni potrebno. Upoštevajte, da telemetrično poročanje zahteva B profile VENs. Glejte Prilogo B za nprampdatoteke poročil pilotnih projektov javnih služb, ki bi se lahko uporabljale za to vrsto programa.
Opt Storitve	–Uporaba storitve Opt za sporočanje urnikov začasne razpoložljivosti običajno ne bi uporabljali kot del programa ponujanja zmogljivosti, saj so stranke vnaprej določile svojo razpoložljivost. Vendar je ta storitev lahko uporabna kot neuraden način za udeležence, da navedejo pomanjkanje razpoložljivosti zaradi olajševalnih razlogov, kot je okvara opreme.
Registracijske storitve	Intervali anketiranja zahteva VTN za tipične programe za dan vnaprej ni potrebno pogosteje kot enkrat na uro. Vendar pa bo uporaba anketiranja za zaznavanje srčnega utripa ali dnevnih programov morda zahtevala pogostejše anketiranje.

Program stanovanjskih termostatov

Ta program je predstavnik neposrednega nadzora obremenitve (DLC), kjer signal odziva na povpraševanje neposredno spremeni vedenje virov za razbremenitev, brez plasti abstrakcije med prejemom signala in izvedenim specifičnim ukrepom za razbremenitev.

Značilnosti programa bivalnega termostata DR

Naloži Profile Cilj	- Zmanjšanje največjega povpraševanja
Primarni gonilniki	- Zmanjšani kapitalski izdatki in zmanjšani stroški energije
Opis programa	- Ko javna podjetja opazijo ali predvidevajo visoke veleprodajne tržne cene ali izredne razmere v elektroenergetskem sistemu, lahko sprožijo dogodek, ki spremeni vedenje uporabnikovega programabilnega komunikacijskega termostata (PCT) v določenem časovnem obdobju (npr. 3–6 na vročem poletni dan v tednu), da zmanjšate porabo energije. - Sprememba vedenja PCT kot odziv na dogodek je lahko preprosta sprememba nastavljene temperature za čas trajanja dogodka ali bolj zapleten sklop sprememb, vključno s predhodnim hlajenjem, ki zmanjša vpliv dogodka na udobje stranke. raven.
Spodbuda za stranke	-Spodbude imajo dve splošni obliki. Prvič, strankam se lahko zagotovi brezplačen PCT ali ponudijo popusti/rabati na kupljene PCT kot spodbudo za vpis v program DR. Drugič, stranke lahko prejemajo stalno letno štipendijo za nadaljevanje vpisa v program. Manj običajne bi bile stalne spodbude, izplačane strankam na podlagi dejanskega zmanjšanja energije med dogodki.
Ocenite oblikovanje	-Predvsem incentive program, kjer stranke za vpis v program DR prejmejo PCT s popustom ali brezplačno. Nekateri programi lahko izplačujejo periodične štipendije ali spodbude na podlagi zmanjšanja energije med dogodki.
Ciljna stranka	-Stanovanjsko
Ciljna obremenitev	- HVAC
Predpogoj	- Običajno nič, saj stranke prejmejo PCT kot del vpisa v program
Časovni okvir programa	- Običajno zajema mesece v letu, ko pride do največje porabe energije, čeprav je lahko v nekaterih primerih vse leto.
Omejitve dogodkov	- Običajno od ponedeljka do petka, razen praznikov, običajno so dovoljeni zaporedni dnevni dogodki.
Dnevi dogodkov	- Običajno 9 do 15 na leto
Trajanje dogodka	- Dogodki se lahko zgodijo kadar koli in trajajo od 2 do 4 ure, čeprav se običajno dogodki zgodijo v času dneva z največjo porabo energije.
Obvestilo	- Običajno dan vnaprej, čeprav imajo lahko nekateri programi čas obveščanja le 10 minut.
Opt Behavior	- Strankam ni treba sodelovati v dogodkih, vendar bodo samodejno vključene v dogodke, razen če ukrepajo za preglasitev dogodka ali ročno prilagodijo temperaturo med dogodkom.
Certificiranje Dogodki	- Običajno nič

Značilnosti OpenADR za programe stanovanjskih termostatov

Signali dogodkov	–PREPROSTI signal z ravnmi od 1 do 3, ki je preslikan na spremembo odmikov nastavljene temperature PCT ali odstotek termostatskega ciklatage . Če ima program stanovanjskega termostata eno komponento zamika/cikla, jo je treba preslikati na raven 1. Za programe z več komponentami zamika/cikla je treba najmanjšo spremembo običajnega delovanja preslikati na raven 1, z drugimi vrednostmi zamika/cikla. preslikana na ravni 2 in 3 glede na naraščajočo stopnjo vpliva razbremenitve. -Če uvedba podpira B profile VEN, poleg signala SIMPLE je lahko vključen signal LOAD_CONTROL v tovoru z vrsto x-loadControlLevelOffset ali x-loadControlCapacity za določitev želenega odmika nastavljene temperature ali termostatskega cikla percentage oz. Ponovno se priporoča, da a vrsta enote "temperatura", ki se uporablja v koristnih tovorih z uporabo signala x-loadControlLevelOffset signalType za navedbo Celzija ali Fahrenheita za odmik. Glej prilogo A za npramples.
Opt Responses	-VTN pošiljanje dogodkov mora element oadrResponseRequired nastaviti na "vedno", ki zahteva, da se VEN odzove z optIn ali optOut – VEN-ji bi se morali odzvati z optIn, razen če je stranka izvedla kakšno posebno preglasitveno dejanje. -The oadrCreateOpt koristno obremenitev lahko uporabljajo VEN-ji kvalificirati sodelovanje virov v dogodku. Na primer, dogodek lahko cilja na ID vira dveh termostatov, ki nadzorujeta ločena sistema HVAC. Če se stranka odloči, da lahko v dogodku sodeluje samo eden od sistemov HVAC, bo to sporočeno VTN z uporabo koristnega tovora oadrCreateOpt. Upoštevajte, da obremenitev oadrCreateOpt podpira samo B profile VEN
Deskriptor dogodka	- Dogodek prioriteta mora biti nastavljena na 1 razen če pravila programa ali konfiguracija VTN določajo drugače –Testni dogodki se običajno ne uporabljajo s programi za stanovanjske termostate. Če pa so dovoljeni, mora biti element testEvent nastavljen na »true«, da označuje preskusni dogodek. Če so v tem elementu potrebne dodatne parametrizirane informacije, lahko sledi »true«, ločen s presledkom s temi dodatnimi informacijami.
Aktivno obdobje dogodka	–Naključna izbira se običajno uporablja za dogodke stanovanjskih termostatov z uporabo elementa tolerance – eiRampElementi Up in eiRecovery se običajno ne uporabljajo
Osnovne črte	–Osnovne črte običajno niso vključene v tovor dogodka
Ciljanje na dogodek	-Programi stanovanjskih termostatov so namenjeni virom HVAC, ki jih nadzirajo PCT. Ciljanje običajno določa ID-je virov sistemov HVAC (tj. termostat), povezanih z VEN ali venID s ciljem razreda naprave signala dogodka, nastavljenim na Termostat
Storitve poročanja	–Poročanje o telemetriji se običajno ne uporablja ker ni nujno potreben za programe stanovanjskih termostatov Glejte Prilogo B za nprampdatoteke poročil pilotnih projektov javnih služb, ki bi se lahko uporabljale za to vrsto programa.
Opt Storitve	–Uporaba storitve Opt za sporočanje urnikov začasne razpoložljivosti običajno ne bi uporabljali kot del programa CPP.
Registracijske storitve	Intervali anketiranja zahteva VTN za tipične programe stanovanjskih termostatov za dan vnaprej ni potrebno pogosteje kot enkrat na uro. Vendar pa lahko uporaba anketiranja za zaznavanje srčnega utripa zahteva pogostejše anketiranje, kot bi to storili programi stanovanjskih termostatov z bistveno krajšimi časi obveščanja.

Hitro odpošiljanje DR

Značilnosti programa za hitro pošiljanje DR

Naloži Profile Cilj	-Pošiljanje virov za doseganje odziva na obremenitev v "realnem času"
Primarni gonilniki	- Zanesljivost omrežja in pomožne storitve
Opis programa	Fast DR uporabljajo ISO/pripomočki za pridobitev vnaprej določenega odziva na obremenitev v "realnem času". Ta vnaprej določen odziv na obremenitev uporabljajo ISO/oskrbe, ko opazijo pogoje, ki zahtevajo takojšnje ukrepanje za ohranitev stabilnosti in celovitosti omrežja. V realnem času pomeni, da se viri običajno pošiljajo z zakasnitvijo v razponu od 10 minut za vire, ki se uporabljajo kot rezerve, do 2 sekund za vire, ki se uporabljajo za namene regulacije. Velikost odziva na obremenitev mora biti dovolj velika, da vpliva na ublažitev stanja omrežja, zato so viri običajno zelo veliki in jih pogosto upravljajo zbiralniki kot del združenega vira. Najmanjše velikosti za odziv na obremenitev za vir, da se kvalificira za sodelovanje v pomožnih storitvah, so običajno okoli 500 kW, vendar so lahko za nekatere programe nizke kot 100 kW. Upoštevajte, da če se vir uporablja kot rezerva, bo običajno pozvan k zmanjšanju (tj. odvajanju) obremenitve, če pa se uporablja za regulacijske namene, se lahko pošlje bodisi za povečanje ali zmanjšanje obremenitve.
Spodbuda za stranke	Zbiralniki/stranke običajno prejmejo dve vrsti spodbud. Najprej prejmejo plačilo za dodelitev in dajanje na voljo določene količine odziva na obremenitev, ki je na voljo za dogodke DR v prihodnjem časovnem oknu. Obseg odziva na obremenitev, časovno okno razpoložljivosti in znesek, ki ga je treba plačati, običajno nastavi zbiralnik/stranka. Drugič, če se dogodek kliče v prihodnjem časovnem oknu, plačilo temelji na količini odziva obremenitve v času trajanja dogodka.
Ocenite oblikovanje	Udeleženci v programu oddajo ponudbo z navedbo odziva na obremenitev, ki so ga pripravljeni dati na voljo v prihodnjem časovnem oknu. Ponudba običajno vključuje tudi plačilo, ki ga je zbiralnik/stranka pripravljen sprejeti za odziv na obremenitev. Na trgih komunalnih storitev/ISO se ponudba običajno odda dan vnaprej ali na dan časovnega obdobja, za katerega je sprejeta zaveza. Kot del njihove kvalifikacije in registracije na trgih so z virom povezani različni parametri ovojnic uspešnosti, kot je ramp hitrost ter najnižje in najvišje delovne omejitve. Ti parametri določajo, kako bo poslano. Če je ponudba udeleženca sprejeta, se stranki lahko izvede plačilo za njihovo predhodno zavezo, tudi če v časovnem oknu ni klicanih dogodkov. Če je dogodek sklican med časovnim oknom, lahko stranka prejme dodatna plačila za svojo uspešnost med dogodkom. Takšna plačila na podlagi uspešnosti lahko temeljijo na številnih dejavnikih, vključno s količino energije, močjo, tem, kako natančno vir sledi navodilom za pošiljanje, in plačilom "kilometrine", ki odraža, koliko je njihova obremenitev profile je bilo potrebno spremeniti med dogodkom. Nekateri od teh parametrov, kot sta energija in moč, se lahko nanašajo na izhodišče.
Ciljna stranka	- Zbiralniki in samozdružene stranke C&I
Ciljne obremenitve	– Tisti, ki se lahko odzovejo na sporočila v realnem času.

Predpogoj	-Odjemalec mora imeti intervalno merjenje - Izpolnjevati mora minimalne zahteve glede velikosti za odziv na obremenitev - Mora biti sposoben odgovoriti na sporočila v realnem času - Običajno je treba zagotoviti telemetrijo v realnem času, ki prikazuje trenutni odziv obremenitve
Časovni okvir programa	-Kadarkoli
Omejitve dogodkov	-nič
Dnevi dogodkov	-nič
Trajanje dogodka	- Običajno kratek (manj kot 30 minut), vendar v nobenem primeru ne bo nikoli presegel časovnega okvira, v katerem je udeleženec dal vir na voljo, ko je oddal svojo ponudbo.
Obvestilo	-nič
Opt Behavior	- Stranke so privzeto vključene v dogodke glede na to, da imajo vnaprej določen odziv na obremenitev
Certificiranje Dogodki	- Običajno enkrat na leto (test)

Značilnosti OpenADR za programe ponujanja zmogljivosti

Signali dogodkov	–PREPROSTI signal z nivoji od 1 do 3, preslikanimi na količino odziva na obremenitev. Če program podpira samo eno raven odziva na obremenitev, je treba to preslikati na raven 1. Pri programih z več ravnmi odziva na obremenitev je treba najmanjšo spremembo običajnega delovanja preslikati na raven 1, pri čemer so vrednosti razbremenitve preslikane na stopnje 2 in 3 v naraščajoči stopnji odziva na obremenitev. -Če uvedba podpira B profile VEN, poleg signala SIMPLE je lahko vključena oddaja v obliki signala LOAD_DISPATCH v koristnem tovoru z vrstami signalov nastavljene vrednosti ali delta in enotami powerReal. Ta signal predstavlja želeno "delovno točko" obremenitve in se lahko izrazi kot absolutna količina mW (tj. nastavljena točka) ali neko relativno število mW (tj. delta) od trenutne delovne točke vira. Glej prilogo A za npramples.
Opt Responses	-VTN pošiljanje dogodkov mora element oadrResponseRequired nastaviti na "vedno", ki zahteva, da se VEN odzove z optIn ali optOut - Ker imajo združevalci/stranke vnaprej dodeljene zmogljivosti VEN-ji bi morali odgovoriti z optIn. Zavrnitev je lahko poslana kot odgovor na dogodek, vendar je to neuraden pokazatelj razpoložljivosti, ne uradna zavrnitev dogodka. -The koristni tovor oadrCreateOpt običajno ne bi bil uporabljen za kvalificiranje virov, ki sodelujejo v dogodkih, saj je običajno obremenitev ena sama združena entiteta.
Deskriptor dogodka	- Dogodek prioriteta mora biti nastavljena na 1 razen če pravila programa ali konfiguracija VTN določajo drugače –Uporabijo se lahko preskusni dogodki, zlasti med registracijo in kvalifikacijo vira. Če so dovoljeni, mora biti element testEvent nastavljen na »true«, da označuje preskusni dogodek. Če so v tem elementu potrebne dodatne parametrizirane informacije, lahko sledi »true«, ločen s presledkom s temi dodatnimi informacijami.
Aktivno obdobje dogodka	– Elementi tolerance se ne uporabljajo. eiRampObdobja up in eiRecovery so običajno del parametrov vira, ko se registrirajo in se lahko uporabljajo. Zaradi narave pošiljanja so lahko odprtega tipa in zato za dogodek morda ni konca.
Osnovne črte	–Osnovne črte običajno niso vključene v tovor dogodka ker ti podatki običajno niso na voljo v času, ko se dogodek začne. Vendar bi tako javne službe kot zbiralci/stranke view vključitev osnovnih informacij v dogodke kot uporabne.
Ciljanje na dogodek	- Programi ponudbe zmogljivosti običajno ne razlikujejo med viri za dano stranko. Ciljanje običajno določa venID, ki nakazuje, da morajo sodelovati vsi viri, povezani z VEN, ali vključuje resourceID, ki predstavlja agregirano obremenitev povezana z VEN.
Storitve poročanja	Programi za hitro reševanje težav običajno zahtevajo poročila TELEMETRY_USAGE s podatkovnimi točkami powerReal. Poročilo o uporabi prikazuje trenutno delovno točko virov in ga uporablja Utility/ISO, da ugotovi, kako natančno vir sledi navodilom za pošiljanje, ki so bila poslana. V nekaterih primerih lahko telemetrija vključuje druge podatkovne točke, kot je voltagOdčitki in stanje napolnjenosti (tj. energija) v primeru, ko je vir neka oblika shranjevanja. V nekaterih primerih je lahko pogostost poročanja tudi vsaki 2 sekundi. Upoštevajte, da telemetrično poročanje zahteva B profile VENs. Glej prilogo A za npramples. Glej tudi Prilogo B za nprampdatoteke poročil pilotnih projektov javnih služb, ki bi se lahko uporabljale za to vrsto programa.
Opt Storitve	–Uporaba storitve Opt za sporočanje začasne razpoložljivosti urniki običajno ne bi uporabljali saj so stranke vnaprej določile njihovo razpoložljivost. Vendar je ta storitev lahko uporabna kot neuraden način za udeležence, da navedejo pomanjkanje razpoložljivosti zaradi olajševalnih razlogov, kot je okvara opreme.
Registracijske storitve	Zaradi nizkih zakasnitev pri pošiljanju v realnem času uporabljeni so samo vzorci potisne interakcije.

Program časa uporabe (TOU) za stanovanjska električna vozila (EV).

Značilnosti rezidenčnega programa EV TOU

Naloži Profile Cilj	Struktura stopnje, po kateri se spremenijo stroški polnjenja električnih vozil, da potrošniki spremenijo vzorce porabe.
Primarni gonilniki	Poraba energije v stanovanjih je največja zvečer. Ker polnjenje EV traja 4-8 ur, ga je mogoče odložiti za nekaj ur, da premaknete največje obremenitve.
Opis programa	Stranke, ki imajo električno vozilo, se lahko prijavijo za tarifo časa uporabe električnega vozila (EV-TOU) in prejmejo nižje tarife za polnjenje svojega vozila v času izven prometne konice, na primer med polnočjo in 5. uro zjutraj. Cene EV-TOU so ponudil, da bi odjemalce spodbudil k omejitvi dnevne porabe električne energije, ko je povpraševanje po električni energiji največje.
Spodbuda za stranke	Cenejše polnjenje za električna vozila.
Ocenite oblikovanje	TOU s konico sredi dneva, zjutraj in zvečer sredi konice ter od 12 do 5 izven konice
Ciljna stranka	EV Lastnik s tovorom profile ki doseže vrh zvečer.
Ciljne obremenitve	EV polnilci
Predpogoj	Stranka mora imeti pametni števec in EV
Časovni okvir programa	Celoletno
Omejitve dogodkov	Noben
Dnevi dogodkov	Vsak dan ali samo med tednom
Trajanje dogodka	5-8 ur
Obvestilo	Stranka je obveščena o cenovnih ravneh na svojih mesečnih računih, VTN pa pošilja signale dogodkov dan vnaprej.
Opt Behavior	Zavezanci lahko spremenijo svoj tarifni načrt, kot bi to običajno storili pri komunalnem podjetju.
Certificiranje Dogodki

Značilnosti OpenADR za rezidenčne programe EV TOU

Signali dogodkov	Signali ELECTRICITY_PRICE z dejanskimi stopnjami cen, kot tudi SIMPLE signali, ki omogočajo sodelovanje 2.0a VEN-jev Glej prilogo A za npramples.
Opt Responses	Vedno se odločite za VEN
Deskriptor dogodka	En dogodek na teden z intervali dogodkov za vsako cenovno raven
Aktivno obdobje dogodka	Uporabiti je treba vsaj 24-urno obveščanje. Vsak interval dogodka bi moral zajeti stopnjo stopnje TOU
Osnovne črte	N/A
Ciljanje na dogodek	Napredno ciljanje ni potrebno, samo ciljanje na ravni VEN.
Storitve poročanja	Poročanje ni potrebno, vsi podatki lahko izvirajo iz števca. Glejte Prilogo B za nprampdatoteke poročil pilotnih projektov javnih služb, ki bi se lahko uporabljale za to vrsto programa.
Opt Storitve	Storitve izbire ne bi bile pomembne za to vrsto programa.
Registracijske storitve	Potrošniki bi svoj VEN vnaprej opremili s pripomočkom za prejemanje cenovnih signalov.

Program za določanje cen v realnem času za električna vozila javne postaje

Značilnosti programa javne postaje EV RTP

Naloži Profile Cilj	Dejavnost odzivanja na povpraševanje, s katero se stroški polnjenja električnih vozil spremenijo tako, da realnost najvišjih cen prenesejo na potrošnike.
Primarni gonilniki	Cena električne energije se čez dan spreminja. Cilj tega programa je učinkovitejša uskladitev cene polnjenja s stroški električne energije.
Opis programa	Javne polnilnice so lahko na delovnih mestih, javnih parkiriščih in v maloprodajnih trgovinah. Ta program posreduje cene v realnem času potencialnim polnilnikom, preden se priklopijo, tako da se lahko informirano odločijo, ali bodo polnili svoj avto ali ne.
Spodbuda za stranke	Cenejše polnjenje v času izven prometnih obremenitev.
Ocenite oblikovanje	Cene se lahko spremenijourly, ko pa se stranka odloči, da bo svoj avto priklopila na električno omrežje, se stopnja nastavi za čas polnjenja.
Ciljna stranka	Vsakdo z električnim vozilom, ki mora polniti, ko je zdoma.
Ciljne obremenitve	Javni polnilniki za električna vozila
Predpogoj	Polnilniki za električna vozila morajo imeti internetno povezavo in certifikat OpenADR2.0b ali pa morajo biti povezani s prehodom OpenADR2.0b VEN.
Časovni okvir programa	Celoletno
Omejitve dogodkov	Noben
Dnevi dogodkov	Vsak dan ali samo med tednom
Trajanje dogodka	1 uro ali več
Obvestilo	Stranka je obveščena o prevladujoči ceni, ko se odloči za priključitev svojega avtomobila.
Opt Behavior	Stranke se lahko odpovejo tako, da se odločijo, da ne bodo zaračunavale.
Certificiranje Dogodki

Značilnosti OpenADR za programe javne postaje EV RTP

Signali dogodkov	ELECTRICITY_PRICE signalizira s cenami. Glej prilogo A za npramples.
Opt Responses	Vedno se odločite za VEN
Deskriptor dogodka	Dogodki morajo biti povezani in vsebovati en interval.
Aktivno obdobje dogodka	Uporabiti je treba vsaj 1-urno obvestilo, vendar se lahko komunalna podjetja odločijo za uporabo obvestila dan vnaprej.
Osnovne črte	N/A
Ciljanje na dogodek	Napredno ciljanje ni potrebno, vendar lahko ciljanje uporabite za pošiljanje cen določenim transformatorjem, napajalnikom ali geografskim območjem.
Storitve poročanja	Poročanje ni potrebno, vendar se lahko uporabi po želji. Glejte Prilogo B za nprampdatoteke poročil pilotnih projektov javnih služb, ki bi se lahko uporabljale za to vrsto programa.
Opt Storitve	Storitve izbire ne bi bile pomembne za to vrsto programa.
Registracijske storitve	Prodajalec polnilne postaje bi svojim napravam zagotovil VTN pripomočka.

Program DR za porazdeljene energetske vire (DER).

Naslednji opis programa je hipotetičen in temelji na raziskovalnem dokumentu (referenčni Rishov dokument), ki opisuje, kako lahko uporabniki komunalnih storitev uporabijo vire za shranjevanje DER za sodelovanje v programih DR, kot so programi za določanje cen v realnem času (RTP).

Značilnosti programa za porazdeljene energetske vire (DER).

Naloži Profile Cilj	Dejavnost odzivanja na povpraševanje, ki se uporablja za gladko integracijo porazdeljenih energetskih virov v pametno omrežje.
Primarni gonilniki	- Zmanjšani kapitalski izdatki in zmanjšani stroški energije
Opis programa	Odjemalci z viri DER, ki lahko pridobivajo energijo in jo shranjujejo, lahko zmanjšajo stroške nakupa električne energije iz omrežja v obdobjih visokih cen tako, da najprej izkoristijo shranjene vire energije, čemur sledi izvajanje strategij razbremenitve.
Spodbuda za stranke	Sposobnost nadzora nad stroški v času visokih cen električne energije z izkoriščanjem shranjene energije, ustvarjene s PV ali drugimi sredstvi, in izvajanjem strategij razbremenitve
Ocenite oblikovanje	Cene električne energije se razlikujejo glede na veleprodajne tržne cene ali tarifo, ki se spreminja glede na čas dneva, letni čas ali temperaturo
Ciljna stranka	Kupci z viri za shranjevanje energije
Ciljne obremenitve	katera koli
Predpogoj	Viri za shranjevanje energije
Časovni okvir programa	Kadarkoli
Omejitve dogodkov	Noben
Dnevi dogodkov	vsak dan
Trajanje dogodka	24 uri
Obvestilo	Dan naprej
Opt Behavior	N/A – Najboljši program
Certificiranje Dogodki	Noben

Značilnosti OpenADR za porazdeljene vire energije (DER)

Signali dogodkov	ELECTRICITY_PRICE signalizira s 24 enournimi intervali cen v 24-urnem obdobju. Ta signal bo zahteval B profile. Ta program ni primeren za SIMPLE signalizacijo za A profile VENs. Glej prilogo A za npramples.
Opt Responses	-VTN pošiljanje dogodkov mora element oadrResponseRequired nastaviti na »nikoli«, kar preprečuje, da bi se VEN-ji odzvali.
Deskriptor dogodka	- Dogodek prioriteta mora biti nastavljena na 1 razen če pravila programa ali konfiguracija VTN določajo drugače
Aktivno obdobje dogodka	24 ur z 1-urnimi intervali z obvestilom dan vnaprej
Osnovne črte	N/A
Ciljanje na dogodek	Razen venID ni potrebno nobeno napredno ciljanje
Storitve poročanja	Poročanje ni potrebno Glejte Prilogo B za nprampdatoteke poročil pilotnih projektov javnih služb, ki bi se lahko uporabljale za to vrsto programa.
Opt Storitve	Ni uporabljeno
Registracijske storitve	Intervali anketiranja zahteva VTN za tipične t programe za dan vnaprej ni potrebno pogosteje kot enkrat na uro. Vendar pa lahko uporaba anketiranja za zaznavanje srčnega utripa zahteva pogostejše anketiranje, kot bi to storili programi stanovanjskih termostatov z bistveno krajšimi časi obveščanja.

– Sample Podatki in predloge tovora

Naslednje tabele in obremenitev XML samples bo izvajalcem zagotovil oprijemljive exampopisuje, kako naj se izvajajo predloge DR v tem dokumentu. Naslednje predpone imenskega prostora so uporabljene v uporabniškem tovoru examples:

• 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”

Program kritičnih najvišjih cen (CPP)

1. scenarij CPP – primer preproste uporabe, A ali B Profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 1
  • Trajanje: 4 ure
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 1
  • Ime signala: PREPROSTO
    • Vrsta signala: raven
    • Enote: N/A
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične intervalne vrednosti: 1
    • Cilj signala: N/A
  • Cilj(i) dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

Scenarij CPP 2 – tipičen primer uporabe, B profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 1
  • Trajanje: 4 ur
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 2
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: Stopnja 0, 1, 2, 3
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične vrednosti intervala: 1 ali 2
    • Cilj signala: Brez
  • Ime signala: ELECTRICITY_PRICE
    • Vrsta signala: cena
    • Enote: USD na Kwh
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične intervalne vrednosti: 0.10 USD do 1.00 USD
    • Cilj signala: Brez
  • Cilji dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

3. scenarij CPP – zapleten primer uporabe

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 2
  • Trajanje: 6 ur
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 2
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: stopnja 0,1, 2, 3)
    • Število intervalov 3
    • Trajanje intervala: 1 ura, 4 ure, 1 ura
    • Tipične intervalne vrednosti: 1, 2, 1 (za vsak interval posebej)
    • Cilj signala: Brez
  • Ime signala: ELECTRICITY_PRICE
    • Vrsta signala: cena
    • Enote: USD na Kwh
    • Število intervalov 3
    • Trajanje intervala: 1 ura, 4 ure, 1 ura
    • Tipične intervalne vrednosti: 0.50 USD, 0.75 USD, 0.50 USD (za vsak interval posebej)
    • Cilj signala: Brez
  • Cilji dogodka: Vir_1, Vir_2, Vir_3
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

CPP Sample Event Payload – tipično B Profile Primer uporabe

OadrDisReq091214_043740_513

TH_VTN

Dogodek091214_043741_028_0

0

http://MarketContext1

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

daleč

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

PT4H

PT24H

PT4H

0

2.0

PREPROSTO

raven

SIG_01

0.0

PT4H

0

0.75

ELEKTRIČNA_CENA

cena

SIG_02

valuta na kWh

USD

nobeden

0.0

venID_1234

vedno

Program ponujanja zmogljivosti (CBP)

1. scenarij CBP – primer preproste uporabe, A ali B Profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 1
  • Trajanje: 4 ure
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 1
  • Ime signala: PREPROSTO
    • Vrsta signala: raven
    • Enote: N/A
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične intervalne vrednosti: 1
    • Cilj signala: N/A
  • Cilj(i) dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

Scenarij CBP 2 – tipičen primer uporabe, B profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 1
  • Trajanje: 4 ur
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 2
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: Stopnja 0,1, 2, 3
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične vrednosti intervala: 1 ali 2
    • Cilj signala: Brez
  • Ime signala: BID_LOAD
    • Vrsta signala: nastavljena točka
    • Enote: moč Real
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične intervalne vrednosti: 20kW do 100kW
    • Cilj signala: Brez
  • Cilji dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

3. scenarij CBP – zapleten primer uporabe

• Dogodek
  • Obvestilo: dan dogodka (koliko ur?)
  • Začetek: 1
  • Trajanje: 6 ur
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 3
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: stopnja 0,1, 2, 3)
    • Število intervalov: 2
    • Trajanje intervala: 3 ure, 3 ure
    • Tipične intervalne vrednosti: 1, 2 (za vsak interval)
    • Cilj signala: Brez
  • Ime signala: BID_LOAD
    • Vrsta signala: nastavljena točka
    • Enote: moč Real
    • Število intervalov 2
    • Trajanje intervala: 3 ure, 3 ure
    • Tipične intervalne vrednosti: 40kW, 80kW (za vsak interval)
    • Cilj signala: Brez
  • Ime signala: BID_PRICE
    • Vrsta signala: cena
    • Enote: valuta na kW
    • Število intervalov 1
    • Trajanje intervala: 6 ure
    • Tipične intervalne vrednosti: 3.10 USD
    • Cilj signala: Brez
  • Cilji dogodka: Vir_1, Vir_2, Vir_3
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• poročilo(a)
  • Ime poročila: TELEMETRY_USAGE
  • Vrsta poročila: uporaba
  • Enote: moč Real
  • Vrsta branja: neposredno branje
  • Pogostost poročanja: vsako 1 uro

CBP Sample Event Payload – tipično B Profile Primer uporabe

OadrDisReq091214_043740_513

TH_VTN

Dogodek091214_043741_028_0

0

http://MarketContext1

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

daleč

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

PT4H

PT24H

PT4H

0

2.0

PREPROSTO

raven

SIG_01

0.0

PT4H

0

80.0

BID_LOAD

nastavljena točka

SIG_02

RealPower

W

k

60.0

<power:voltage>220.0tage>

res

0.0

venID_1234

vedno

Program stanovanjskih termostatov

1. scenarij stanovanjskega termostata – primer preproste uporabe, A ali B Profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 1
  • Trajanje: 4 ure
  • Naključna izbira: 10 minut
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 1
  • Ime signala: PREPROSTO
    • Vrsta signala: raven
    • Enote: N/A
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične intervalne vrednosti: 1
    • Cilj signala: N/A
  • Cilj(i) dogodka: Vir_1
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

2. scenarij stanovanjskega termostata – tipičen primer uporabe, B profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 1
  • Trajanje: 4 ur
  • Naključna izbira: 10 minut
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 2
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: Stopnja 0,1, 2, 3
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične vrednosti intervala: 1 ali 2
    • Cilj signala: Brez
  • Ime signala: LOAD_CONTROL
    • Vrsta signala: x-loadControlLevelOffset
    • Enote: temperatura
    • Število intervalov 1
    • Trajanje intervala: 4 ure
    • Tipične intervalne vrednosti: 2 do 6 stopinj Fahrenheita
    • Cilj signala: Brez
  • Cilji dogodka: Vir_1, Vir_2
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odziv VEN: optIn, Possible outOut (oadrCreateOpt)
• Poročila
  • Noben

Stanovanjski termostat, scenarij 3 – zapleten primer uporabe

• Dogodek
  • Obvestilo: dan dogodka
  • Začetek: 1
  • Trajanje: 6 ur
  • Naključna izbira: 10 minut
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 3
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: stopnja 0,1, 2, 3)
    • Število intervalov: 2
    • Trajanje intervala: 3 ure, 3 ure
    • Tipične intervalne vrednosti: 1, 2 (za vsak interval)
    • Cilj signala: Brez
  • Ime signala: BID_LOAD
    • Vrsta signala: x-loadControlCapacity
    • Enote: Brez
    • Število intervalov 2
    • Trajanje intervala: 3 ure, 3 ure
    • Tipične intervalne vrednosti: 0.9, 0.8 (za vsak interval)
    • Cilj signala: Brez
  • Cilji dogodka: Vir_1, Vir_2, Vir_3
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odziv VEN: optIn, Possible outOut (oadrCreateOpt)
• poročilo(a)
  • Noben

Stanovanjski termostat Sample Event Payload – tipično B Profile Primer uporabe

OadrDisReq091214_043740_513

TH_VTN

Dogodek091214_043741_028_0

0

http://MarketContext1

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

daleč

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

PT4H

PT10M

PT24H

PT4H

0

2.0

PREPROSTO

raven

SIG_01

0.0

PT4H

0

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

temperaturo

Fahrenheit

nobeden

0.0

vir_1

vir_2

vedno

Hitro odpošiljanje DR

Scenarij hitrega DR 1 – primer preproste uporabe, A ali B Profile

• Dogodek
  • Obvestilo: 10 minut
  • Začetek: 1
  • Trajanje: 0 (odprto)
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 1
  • Ime signala: PREPROSTO
    • Vrsta signala: raven
    • Enote: N/A
    • Število intervalov 1
    • Trajanje intervala: 0 (odprto)
    • Tipične intervalne vrednosti: 1
    • Cilj signala: N/A
  • Cilj(i) dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

Scenarij hitrega DR 2 – tipičen primer uporabe, B profile

• Dogodek
  • Obvestilo: 10 minut
  • Začetek: 1
  • Trajanje: 30 minut
  • Naključna izbira: Brez
  • Ramp Gor: 5 minut
  • Okrevanje: 5 minut
  • Število signalov: 2
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: Stopnja 0,1, 2, 3
    • Število intervalov 1
    • Trajanje intervala: 30 minut
    • Tipične vrednosti intervala: 1 ali 2
    • Cilj signala: Brez
  • Ime signala: LOAD_DISPATCH
    • Vrsta signala: delta
    • Enote: moč Real
    • Število intervalov 1
    • Trajanje intervala: 30 minut
    • Tipične intervalne vrednosti: 500 kW do 2 mW
    • Cilj signala: Brez
  • Cilji dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Ime poročila: TELEMETRY_USAGE
  • Vrsta poročila: uporaba
  • Enote: moč Real
  • Vrsta branja: neposredno branje
  • Pogostost poročanja: vsako 1 minuto

Scenarij hitrega DR 3 – zapleten primer uporabe

• Dogodek
  • Obvestilo: 10 minut
  • Začetek: 1
  • Trajanje: 30 minut
  • Naključna izbira: Brez
  • Ramp Gor: 5 minut
  • Okrevanje: 5 minut
  • Število signalov: 2
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: stopnja 0,1, 2, 3)
    • Število intervalov: 2
    • Trajanje intervala: 15 minut, 15 minut
    • Tipične intervalne vrednosti: 1, 2 (za vsak interval)
    • Cilj signala: Brez
  • Ime signala: LOAD_DISPATCH
    • Vrsta signala: nastavljena točka
    • Enote: moč Real
    • Število intervalov 2
    • Trajanje intervala: 15 minut, 15 minut
    • Tipične intervalne vrednosti: 800kW, 900kW (za vsak interval)
    • Cilj signala: Brez
  • Cilji dogodka: Resource_1
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• poročilo(a)
  • Ime poročila: TELEMETRY_USAGE
  • Vrsta poročila: uporaba
  • Enote: močReal in voltage
  • Vrsta branja: neposredno branje
  • Pogostost poročanja: vsakih 5 sekund

Hitri DR Sample Event Payload – tipično B Profile Primer uporabe

OadrDisReq091214_043740_513

TH_VTN

Dogodek091214_043741_028_0

0

http://MarketContext1

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

daleč

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

PT10M

PT10M

<ei:x-eiRampGor>

PT5M

</ei:x-eiRampGor>

PT5M

PT10M

0

2.0

PREPROSTO

raven

SIG_01

0.0

PT10M

0

500.0

LOAD_DISPATCH

delta

SIG_02

RealPower

W

k

60.0

<power:voltage>220.0tage>

res

0.0

venID_1234

vedno

Hitri DR Sample Poročilo o metapodatkih Koristno – tipično B Profile Primer uporabe

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

vir1

uporaba

RealEnergy

Wh

k

Neposredno branje

http://MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

lažno

</oadr:oadrSamplingRate>

0

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

Hitri DR Sample Report Request Payload – Tipično B Profile Primer uporabe

ReportReqID130615_192625_230

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

PT1M

PT1M

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

PT10M

rID120615_122512_981_0

x-ni uporabno

VEN130615_192312_582

Hitri DR Sample obremenitev podatkov poročila – tipično B Profile Primer uporabe

ReportUpdReqID130615_192730_445

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

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

rID120615_122512_981_0

100

0.0

500.0

Kakovost dobra – nespecifična

RP_54321

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

TELEMETRY_USAGE

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

VEN130615_192312_582

Program časa uporabe (TOU) za stanovanjska električna vozila (EV).

Upoštevajte, da ker program sporoča stopnje cen v dokaj strukturirani obliki, so prikazani le preprosti in tipični primeri uporabe

Scenarij 1 stanovanjskega električnega vozila – primer preproste uporabe, A ali B Profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: 1
  • Trajanje: 24 ure
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 1
  • Ime signala: PREPROSTO
    • Vrsta signala: raven
    • Enote: N/A
    • Število intervalov; enake spremembe ravni TOU v 24 urah (2 – 6)
    • Trajanje intervala: aktivni časovni okvir stopnje TOU (tj. 6 ur)
    • Tipične intervalne vrednosti: 0 – 4 preslikane v TOU stopnje
    • Cilj signala: N/A
  • Cilj(i) dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

Scenarij 2 stanovanjskega električnega vozila – tipičen primer uporabe, B profile

• Dogodek
  • Obvestilo: Dan pred dogodkom
  • Začetek: polnoč
  • Trajanje: 24 ur
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 2
  • Ime signala: Enostavno
    • Vrsta signala: raven
    • Enote: Stopnja 0, 1, 2, 3
    • Število intervalov: enaka sprememba ravni TOU v 24 urah (2 – 6)
    • Trajanje intervala: aktivni časovni okvir stopnje TOU (tj. 6 ur)
    • Tipične intervalne vrednosti: 0 – 4 preslikane v TOU stopnje (0 – najcenejša stopnja)
    • Cilj signala: Brez
  • Ime signala: ELECTRICITY_PRICE
    • Vrsta signala: cena
    • Enote: USD na Kwh
    • Število intervalov: enake spremembe ravni TOU v 24 urah (2 – 6)
    • Trajanje intervala: aktivni časovni okvir stopnje TOU (tj. 6 ur)
    • Tipične intervalne vrednosti: 0.10 USD do 1.00 USD (trenutni tečaj stopnje)
    • Cilj signala: Brez
  • Cilji dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

Stanovanjski EV Sample Event Payload – tipično B Profile Primer uporabe

OadrDisReq091214_043740_513

TH_VTN

Dogodek091214_043741_028_0

0

http://MarketContext1

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

daleč

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

PT24H

PT24H

PT5H

0

0.0

PT7H

1

1.0

PT47H

2

2.0

PT5H

3

1.0

PREPROSTO

raven

SIG_01

0.0

PT5H

0

0.35

PT7H

1

0.55

PT7H

2

0.75

PT5H

3

0.55

ELEKTRIČNA_CENA

cena

SIG_02

valuta na kWh

USD

nobeden

0.0

venID_1234

vedno

Program za določanje cen v realnem času za električna vozila javne postaje

Upoštevajte, da ker je to program za določanje cen v realnem času, dejansko ni razlike med preprostim, tipičnim in zapletenim primerom uporabe. Zato sampdatotečni podatki bodo prikazani samo za tipičen primer uporabe.

1. scenarij javne postaje EV – tipičen primer uporabe, B profile

• Dogodek
  • Obvestilo: 1 uro naprej
  • Začetek: 1
  • Trajanje: 1 ur
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 1
  • Ime signala: ELECTRICITY_PRICE
    • Vrsta signala: cena
    • Enote: USD na Kwh
    • Število intervalov 1
    • Trajanje intervala: 1 ure
    • Tipične intervalne vrednosti: 0.10 USD do 1.00 USD
    • Cilj signala: Brez
  • Cilji dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odziv VEN: vedno
  • Pričakovani odgovor VEN: optIn
• Poročila
  • Noben

Javna postaja EV Sample Event Payload – tipično B Profile Primer uporabe

OadrDisReq091214_043740_513

TH_VTN

Dogodek091214_043741_028_0

0

http://MarketContext1

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

daleč

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

PT1H

PT1H

PT1H

0

0.75

ELEKTRIČNA_CENA

cena

SIG_01

valuta na kWh

USD

nobeden

0.0

venID_1234

vedno

Program DR za porazdeljene energetske vire (DER).

Upoštevajte, da ker je to program za določanje cen v realnem času, dejansko ni razlike med preprostim, tipičnim in zapletenim primerom uporabe. Zato sampdatotečni podatki bodo prikazani samo za tipičen primer uporabe.

1. scenarij javne postaje EV – tipičen primer uporabe, B profile

• Dogodek
  • Obvestilo: dan naprej
  • Začetek: polnoč
  • Trajanje: 24 ur
  • Naključna izbira: Brez
  • Ramp Gor: Brez
  • Izterjava: Brez
  • Število signalov: 24
  • Ime signala: ELECTRICITY_PRICE
    • Vrsta signala: cena
    • Enote: USD na Kwh
    • Število intervalov 1
    • Trajanje intervala: 1 ure
    • Tipične intervalne vrednosti: 0.10 USD do 1.00 USD
    • Cilj signala: Brez
  • Cilji dogodka: venID_1234
  • Prednost: 1
  • Zahtevan odgovor VEN: nikoli
  • Pričakovani odziv VEN: ni na voljo
• Poročila
  • Noben

Javna postaja EV Sample Event Payload – tipično B Profile Primer uporabe

OadrDisReq091214_043740_513

TH_VTN

Dogodek091214_043741_028_0

0

http://MarketContext1

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

daleč

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

PT24H

PT24H

PT1H

0

0.75

PT1H

1

0.80

ELEKTRIČNA_CENA

cena

SIG_01

valuta na kWh

USD

nobeden

0.0

venID_1234

nikoli

- example Poročila pilotov javnih služb

Člani OpenADR Alliance so zagotovili naslednje B Profile oadrUpdateReport koristni tovor sampiz pilotnih programov javnih služb, kjer so bili nameščeni njihovi VEN. Naslednje opombe so spremljale tri tovore sampzagotovljeno:

Cilj koristne obremenitve termostata:

• Vedeti morate status termostata (temperatura, nastavljene točke, ventilator in stanja načina)
• Če je izbrano, ali je stranka spremenila nastavitve termostata (sporočila o ročni preglasitvi)

M&V za rabate Koristni cilj:

• Stanje virov in ročna preglasitev v primeru izbire
• Intervalni podatki iz števca impulzov KYZ ali monitorja energije za skupno energijo v KWH in trenutno povpraševanje v KW

Pametni merilnik/AMI Intervalni podatki Koristna obremenitev Cilj:

• Interval odčitavanja števca AMI je približno 15 minut do 1 ure. Čeprav je uporaben, ni dovolj natančen za ocene zaračunavanja v skoraj realnem času
• Skupna energija v KWH, delta energija v KWH, trenutna potreba v KW

Naslednje predpone imenskega prostora so uporabljene v uporabniškem tovoru examples:

• 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”

Poročilo o termostatu Tovor 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

Stanje

res

lažno

0

Ni nove vrednosti – uporabljena prejšnja vrednost

Trenutna temp

77.000000

Ni nove vrednosti – uporabljena prejšnja vrednost

Nastavitev temperature ogrevanja

64.000000

Ni nove vrednosti – uporabljena prejšnja vrednost

Nastavitev hladne temperature

86.000000

Ni nove vrednosti – uporabljena prejšnja vrednost

Nastavitev načina HVAC

3

Ni nove vrednosti – uporabljena prejšnja vrednost

Trenutni način HVAC

0.000000

Ni kakovosti – ni vrednosti

Nastavitev načina ventilatorja

2

Ni nove vrednosti – uporabljena prejšnja vrednost

Trenutni način zadrževanja

2

Ni nove vrednosti – uporabljena prejšnja vrednost

Trenutni način odsotnosti

0

Ni nove vrednosti – uporabljena prejšnja vrednost

Trenutna vlažnost

0.000000

Ni kakovosti – ni vrednosti

RP21

REQ:RReq:1395368583267

0013A20040980FAE

TELEMETRIJA_STATUS

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

VEN.ID:1395090780716

M&V za rabate Poročilo o obremenitvi 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

Stanje

res

lažno

Kakovost dobra – nespecifična

Štetje utripa

34750.000000

Kakovost dobra – nespecifična

energija

33985.500000

Kakovost dobra – nespecifična

Moč

1.26

Kakovost dobra – nespecifična

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 Koristna obremenitev 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

instantaneousDemand

6.167000

Ni nove vrednosti – uporabljena prejšnja vrednost

intervalDataDelivered

0.051000

Ni nove vrednosti – uporabljena prejšnja vrednost

currSumDelivered

12172.052000

Ni nove vrednosti – uporabljena prejšnja vrednost

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

PT15S

instantaneousDemand

6.114000

Ni nove vrednosti – uporabljena prejšnja vrednost

intervalDataDelivered

0.051000

Ni nove vrednosti – uporabljena prejšnja vrednost

currSumDelivered

12172.052000

Ni nove vrednosti – uporabljena prejšnja vrednost

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

PT15S

instantaneousDemand

6.113000

Ni nove vrednosti – uporabljena prejšnja vrednost

intervalDataDelivered

0.051000

Ni nove vrednosti – uporabljena prejšnja vrednost

currSumDelivered

12172.142000

Ni nove vrednosti – uporabljena prejšnja vrednost

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

PT15S

instantaneousDemand

6.112000

Ni nove vrednosti – uporabljena prejšnja vrednost

intervalDataDelivered

0.051000

Ni nove vrednosti – uporabljena prejšnja vrednost

currSumDelivered

12172.142000

Ni nove vrednosti – uporabljena prejšnja vrednost

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>

- Storitve

Open ADR podpira naslednje storitve:

• Storitev EiEvent – Uporabljajo ga VTN za pošiljanje dogodkov odziva na povpraševanje VEN-jem, uporabljajo pa jih VEN-ji za označevanje, ali bodo viri sodelovali v dogodku. Edina storitev, ki jo podpira A profile je EiEvent
• Storitev EiReport – Uporabljajo ga VEN in VTN za izmenjavo zgodovinskih, telemetričnih in napovednih poročil
• Storitev EiOpt – Uporablja ga VEN za sporočanje urnika začasne razpoložljivosti VTN-jem ali za kvalificiranje virov, ki sodelujejo v dogodku
• Storitev EiRegisterParty – Sproži ga VEN, uporabljata pa ga tako VEN kot VTN za izmenjavo informacij, potrebnih za zagotovitev interoperabilne izmenjave tovora
• Storitev OadrPoll – Uporabljajo ga VEN-ji za preverjanje VTN za koristne podatke iz katere koli druge storitve

A in B profile Storitvene operacije so definirane s korenskim elementom vsakega koristnega tovora, razen ovojov oadrPayload in oadrSignedObject, ki se uporabljajo na vseh B profile tovora.

– Definicije koristnega tovora

Koristne obremenitve EiEvent

• oadrRequestEvent – Uporablja se v modelu izmenjave vleka s strani VEN za pridobivanje vseh pomembnih dogodkov iz VTN. Uporablja se kot primarni mehanizem glasovanja za A profile VEN, vendar se uporablja samo na B VEN za sinhronizacijo z VTN.
• oadrDistributeEvent – Uporablja ga VTN za dostavo dogodkov odziva na povpraševanje v VEN
• oadrCreatedEvent – Uporablja ga VEN za sporočanje, ali namerava sodelovati na dogodku tako, da se prijavi ali odjavi
• oadrResponse – Uporablja ga VTN za potrditev prejema optIn ali optOut iz VEN

Koristne obremenitve EiReport

Upoštevajte, da sta tako VEN kot VTN zmožna izdelovati poročila in zahtevati poročila, tako da lahko vse koristne obremenitve spodaj sproži katera koli stran.

• oadrRegisterReport – Uporablja se za objavo svojih zmožnosti poročanja v poročilu o metapodatkih
• oadrRegisteredReport -Potrdite prejem oadrRegisterReport, po želji zahtevajte eno od ponujenih poročil
• oadrCreateReport – Uporablja se za zahtevo po poročilu, ki ga je predhodno ponudil VEN ali VTN
• oadrCreatedReport – Potrdite prejem zahteve za poročilo
• oadrUpdateReport - Dostavite zahtevano poročilo, ki vsebuje intervalne podatke
• oadrUpdatedReport – Potrdite prejem dostavljenega poročila
• oadrCancelReport – Preklic predhodno zahtevanega rednega poročila
• oadrCanceledReport – Potrdite preklic periodičnega poročila
• oadrResponse – Uporablja se kot odgovor nadomestnega mesta v nekaterih vzorcih izmenjave vleka, ko je odziv aplikacijske plasti dostavljen v zahtevi transportne plasti.

Koristne obremenitve EiOpt

• oadrCreateOpt – Uporablja se za dva popolnoma različna namena
  • Da VEN sporoči urnik začasne razpoložljivosti VTN v zvezi z njegovo zmožnostjo sodelovanja v dogodkih DR
  • Da VEN kvalificira vire, ki sodelujejo v dogodku
• oadrCreatedOpt – Potrdite prejem tovora oadrCreateOpt
• oadrCancelOpt - Prekličite razpored začasne razpoložljivosti
• oadrCanceledOpt – Potrdite preklic začasnega poročila o razpoložljivosti

 

Obremenitve EiRegisterParty

• oadrQueryRegistration – Način, da VEN poizveduje po informacijah o registraciji VTN, ne da bi se dejansko registriral.
• oadrCreatePartyRegistration – Zahtevek VEN na VTN za registracijo. Vsebuje informacije o zmogljivostih VEN.
• oadrCreatedPartyRegistration – Odgovor na oadrQueryRegistration ali oadrCreatePartyRegistration. Vsebuje zmogljivosti VTN in informacije o registraciji, ki so potrebne za medsebojno delovanje VEN
• oadrCancelPartyRegistration – Uporablja ga VEN ali VTN za preklic registracije
• oadrCanceledPartyRegistration – Odgovor na oadrCancelPartyRegistration. Potrjuje prejem preklica registracije
• oadrRequestReregistration – To koristno obremenitev uporablja VTN v modelu izmenjave vleka, da signalizira VEN, da ponovno sproži zaporedje registracije
• oadrResponse – Uporablja se kot odgovor nadomestnega mesta v nekaterih vzorcih izmenjave vleka, ko je odziv aplikacijske plasti dostavljen v zahtevi transportne plasti.

Obremenitve OadrPoll

• oadrPoll – Generičen mehanizem za poliranje za B profile ki vrne obremenitev za vse druge storitve, ki so nove ali posodobljene.
• oadrResponse – Uporablja se za označevanje, da ni na voljo novih ali posodobljenih uporabnih tovorov

– Glosar elementov koristne obremenitve sheme

Sledi abecedni seznam elementov sheme, ki se uporabljajo v uporabnih obremenitvah OpenADR 2.0. Pripoved opisuje njihovo uporabo, saj se nanaša na OpenADR in njihovo uporabo v uporabnih obremenitvah. Ko se definicija elementa spremeni glede na koristno obremenitev, v kateri je vsebovan, ali kontekst njegove uporabe, bo to zabeleženo v pripovedi. Definicije korenskega koristnega tovora so bile izključene, kot so opredeljene v Prilogi C.

• ac – Logična vrednost, ki označuje, ali je močnostni produkt izmenični tok
• natančnost – Število je v enakih enotah kot spremenljivka obremenitve za interval. Če je prisoten z zaupanjem, označuje verjetnost variabilnosti napovedi. Če je prisoten z ReadingType, označuje verjetno napako pri branju.
• agregatedPnode – Združeno cenovno vozlišče je specializirana vrsta cenovnega vozlišča, ki se uporablja za modeliranje elementov, kot so sistemsko območje, privzeto cenovno območje, cenovno območje po meri, kontrolno območje, združeno ustvarjanje, združeno sodelujoče breme, združeno nesodelujoče breme, trgovalno središče, območje DCA
• na voljo – Objekt, ki vsebuje datum-čas in trajanje za razpored razpoložljivosti EiOpt
• baselineID – Enolični ID za določeno osnovno linijo
• baselineName – Opisno ime za izhodišče
• komponente –
• zaupanje – Statistična verjetnost, da je sporočena podatkovna točka točna
• createdDateTime – Datum in čas, ko je bil tovor ustvarjen
• valuta –
• valutaPerKW –
• valuta na kWh –
• valutaPerThm –
• trenutno –
• trenutna vrednost – Vrednost payloadFloat intervala dogodka, ki se trenutno izvaja.
• customUnit – Uporablja se za določitev merske enote po meri za poročila po meri
• datum-čas –
• dtstart – Začetni čas za spremembo dejavnosti, podatkov ali stanja
• trajanje – Časovno obdobje za dogodek, poročanje ali časovni interval razpoložljivosti
• trajanje - Trajanje dejavnosti, podatkov ali stanja
• eiActivePeriod – Časovni okviri, pomembni za celoten dogodek
• eiCreatedEvent – Na dogodek DR se odzovite z optIn ali optOut
• eiEvent - Objekt, ki vsebuje vse informacije za en dogodek
• eiEventBaseline – B profile
• eiEventSignal – Objekt, ki vsebuje vse informacije za posamezen signal v dogodku
• eiEventSignals – Intervalni podatki za enega ali več signalov dogodkov in/ali osnovnih linij
• eiMarketContext – URI, ki enolično identificira program odzivanja na povpraševanje
• eiReportID – Referenčni ID za poročilo
• eiRequestEvent – Zahtevaj dogodek od VTN v vlečnem načinu
• eiResponse – Navedite, ali je prejeti tovor sprejemljiv
• eiTarget – Identificira vire, povezane z logičnim vmesnikom VEN. Za dogodke so podane vrednosti cilj za dogodek
• endDeviceAsset – EndDeviceAssets so fizična naprava ali naprave, ki so lahko merilniki ali druge vrste naprav, ki bi lahko bile zanimive
• EnergyApparent – Navidezna energija, merjena v volt-ampdo ure (VAh)
• EnergyItem –
• EnergyReactive – Reaktivna energija, volt-amperes reaktivne ure (VARh)
• EnergyReal – Realna energija, vatne ure (Wh)
• eventDescriptor – Informacije o dogodku
• eventID – Vrednost ID-ja, ki identificira določen primerek dogodka DR.
• eventResponse – Objekt, ki vsebuje odgovor VEN na zahtevo za sodelovanje v dogodku
• eventResponses – odgovori optIn ali optOut za prejete dogodke
• dogodekStatus – Trenutno stanje dogodka (daleč, blizu, aktivno itd.)
• FeatureCollection/location/Polygon/exterior/LinearRing
• pogostost –
• zrnatost – To je časovni interval med sampvodenih podatkov v zahtevi za poročilo.
• groupID - Ta vrsta cilja se uporablja za dogodke, poročila in razporede izbir. Vrednost običajno dodeli pripomoček med vpisom v program DR
• ime skupine – Ta vrsta cilja se uporablja za dogodke, poročila in razporede izbir. Vrednost običajno dodeli pripomoček med vpisom v program DR
• hertz –
• interval – Objekt, ki vsebuje podatke-čas in/ali trajanje ter vrednost, ki jo je mogoče uporabiti v primeru dogodka ali podatke v primeru poročila
• intervali – En ali več časovnih intervalov, med katerimi je dogodek DR aktiven ali so na voljo podatki poročila
• itemDescription – Opis merske enote poročila
• itemUnits – Osnovna merska enota za podatkovno točko poročila
• marketContext – URI, ki identificira program DR
• meterAsset – MeterAsset je fizična naprava ali naprave, ki opravljajo vlogo števca
• modificationDateTime – Ko je dogodek spremenjen
• modificationNumber – Poveča se vsakič, ko je dogodek spremenjen.
• modificationReason – Zakaj je bil dogodek spremenjen
• mrid – mRID identificira fizično napravo, ki je lahko CustomerMeter ali druge vrste končnih naprav.
• vozlišče – Vozlišče je kraj, kjer se nekaj spremeni (pogosto lastništvo) ali poveže v omrežje. Številna vozlišča so povezana z merilniki, vendar ne vsa.
• numDataSources –
• oadrCapacity –
• oadrCurrent –
• oadrDataQuality –
• oadrDeviceClass – Cilj razreda naprave – uporabite samo endDeviceAsset.
• oadrEvent – Objekt, ki vsebuje dogodek odziva na zahtevo
• oadrExtension –
• oadrExtensionName –
• oadrExtensions –
• oadrHttpPullModel – Logična vrednost, ki označuje, ali želi VEN uporabiti model izmenjave vleka
• oadrInfo – Par ključnih vrednosti registracijskih informacij, specifičnih za storitev
• oadrKey –
• oadrLevelOffset –
• oadrLoadControlState –
• oadrManualOverride – Če je res, je bil nadzor obremenitve ročno preglasen
• oadrMax –
• oadrMaxPeriod – Največ sampling obdobje
• oadrMin –
• oadrMinPeriod – Najmanj sampling obdobje
• oadrNormal –
• oadrOnChange – Če je res, bodo podatki zabeleženi, ko se spremenijo, vendar ne pogosteje, kot je določeno z minPeriod.
• oadrOnline – Če je true, je vir/sredstvo na spletu, če je false, potem ni na spletu.
• oadrPayload –
• oadrPayloadResourceStatus – Informacije o trenutnem stanju vira
• oadrPendingReports – Seznam periodičnih poročil, ki so še vedno aktivna
• oadrPercentOffset –
• oadrProfile - Profile podpira VEN ali VTN
• oadrProfileIme – OpenADR profile ime, kot je 2.0a ali 2.0b.
• oadrProfiles – OpenADR profiles podporo izvedbe
• oadrReport - Predmet, ki vsebuje vse informacije za eno poročilo
• oadrReportDescription – Opis značilnosti poročila, ki jih ponuja izdelovalec poročila. Vsebovano v poročilu o metapodatkih
• oadrReportOnly – ReportOnlyDeviceFlag
• oadrReportPayload – Vrednosti podatkovnih točk za poročila
• oadrRequestedOadrPollFreq – VEN pošlje koristni tovor oadrPoll v VTN največ enkrat za vsako trajanje, ki ga določa ta element
• oadrResponseRequired – Nadzira, kdaj je potreben odgovor optIn/optOut. Lahko vedno ali nikoli
• oadrSamplingRate – Samphitrost linga za podatke vrste telemetrije
• oadrService –
• oadrServiceName – Ta vrsta cilja se uporablja za dogodke, poročila in razporede izbir. Vrednost običajno dodeli pripomoček med vpisom v program DR
• oadrServiceSpecificInfo – Informacije o registraciji za specifično storitev
• oadrSetPoint –
• oadrSignedObject –
• oadrTransport – Ime prevoza, ki ga podpira VEN ali VTN
• oadrTransportAddress – Korenski naslov, ki se uporablja za komunikacijo z drugo stranko. Po potrebi naj vključuje vrata
• oadrTransportName – Ime transporta OpenADR, kot je simpleHttp ali xmpp
• oadrTransports – Prenosi OpenADR, ki jih podpira implementacija
• oadrUpdatedReport – Potrdite prejem poročila
• oadrUpdateReport – Pošlji predhodno zahtevano poročilo
• oadrValue –
• oadrVenName – Ime VEN. Lahko se uporablja v GUI VTN
• oadrXmlSignature – Izvedba podpira podpis XML
• optID – Identifikator za opt interakcijo
• optReason – Oštevilčena vrednost za razlog izbire, kot je x-razpored
• optType – optIn ali optOut dogodka ali se uporablja za označevanje vrste opt urnika, definiranega v vavailablityObject za storitev EiOpt
• partyID – Ta vrsta cilja se uporablja za dogodke, poročila in razporede izbir. Vrednost običajno dodeli pripomoček med vpisom v program DR
• payloadFloat – Vrednost podatkovne točke za signale dogodkov ali za poročanje o trenutnih ali preteklih vrednostih.
• pnode – Cenovno vozlišče je neposredno povezano s povezovalnim vozliščem. Je cenovna lokacija, za katero udeleženci na trgu oddajajo svoje ponudbe, kupujejo/prodajajo CRR in poravnavajo.
• pointOfDelivery –
• pointOfReceipt –
• posList –
• powerApparent – Navidezna moč, izmerjena v volt-amperes (VA)
• powerAttributes
• powerItem
• powerReactive – Jalova moč, merjena v volt-ampreaktiven (VAR)
• powerReal – Realna moč, izmerjena v vatih (W) ali džulih/sekundo (J/s)
• prioriteta – Prednost dogodka glede na druge dogodke (nižje kot je število, višja je prioriteta. Vrednost nič (0) pomeni, da ni prioritete, kar je privzeto najnižja prioriteta).
• lastnosti –
• pulseCount – Podatkovna točka za poročanje
• pulseFactor – kWh na štetje
• qualifiedEventID – Enolični ID za dogodek
• readingType – Metapodatki o odčitkih, kot so srednji ali izpeljani
• registracijski ID – Identifikator za transakcijo registracije. Ni vključeno v odgovor na registracijo poizvedbe, razen če je že registrirano
• replyLimit – Največje število dogodkov za vrnitev koristnega tovora oadrDistributeEvent
• reportBackDuration – Poročajte nazaj s poročilom do datuma za vsako preteklost tega trajanja.
• reportDataSource – Viri podatkov v tem poročilu. nprampvključujejo števce ali podmetre. Na primerample, če je merilnik sposoben zagotoviti dve različni vrsti meritev, potem bi bil vsak merilni tok ločeno identificiran.
• reportInterval – To je celotno obdobje poročanja.
• ime poročila – Izbirno ime za poročilo.
• reportRequestID – Identifikator za določeno zahtevo za poročilo
• reportSpecifier – Določite želene podatkovne točke v določenem primeru poročila
• reportSpecifierID – Identifikator za določeno specifikacijo poročila o metapodatkih
• reportSubject – Cilj razreda naprave – uporabite samo endDeviceAsset.
• reportToFollow – Označuje, ali bo poročilo (v obliki UpdateReport) vrnjeno po preklicu poročila
• reportType – Vrsta poročila, kot je uporaba ali cena
• ID zahteve – ID, ki se uporablja za ujemanje zahteve za logično transakcijo in odgovora
• ID vira – Ta vrsta cilja se uporablja za dogodke, poročila in razporede izbir. Vrednost običajno dodeli pripomoček med vpisom v program DR
• odgovor –
• responseCode – 3-mestna odzivna koda
• opis odziva – Narativni opis statusa odgovora
• odzivi –
• rID – Referenčni ID za to podatkovno točko
• serviceArea – Ta vrsta cilja se uporablja za dogodke, poročila in razporede izbir. Vrednost običajno dodeli pripomoček med vpisom v program DR
• serviceDeliveryPoint – Logična točka v omrežju, kjer lastništvo storitve zamenja lastnika. Je ena od potencialno mnogih servisnih točk znotraj ServiceLocation, ki zagotavlja storitev v skladu s CustomerAgreement. Uporablja se na mestu namestitve števca.
• serviceLocation – Stranka ServiceLocation ima eno ali več ServiceDeliveryPoint(s), ki se nato nanašajo na merilnike. Lokacija je lahko točka ali poligon, odvisno od posebnih okoliščin. Za distribucijo je ServiceLocation običajno lokacija prostorov naročnika komunalnih storitev.
• ID signala – enolični identifikator za določen signal dogodka
• signalName – Ime signala, kot je SIMPLE
• signalPayload – Vrednosti signala za dogodke in osnovne črte
• siScaleCode – Faktor lestvice za osnovno mersko enoto za poročilo
• specifierPayload – odprto
• začetek po – Naključno okno za začetek dogodka
• statusDateTime – Datum in čas, na katerega se sklicuje ta artefakt.
• temperatura –
• testEvent – Vse, kar ni false, pomeni preskusni dogodek
• besedilo –
• Term –
• toleranca – Podobjekt, ki vsebuje zahteve za naključno izbiro za dogodek
• prenašati – Objekt, ki vsebuje zahteve za naključno izbiro za dogodek
• transportInterface – Transportni vmesnik označuje robove na obeh koncih transportnega segmenta.
• uid – Uporablja se kot indeks za prepoznavanje intervalov. Enolični identifikator
• vrednost –
• nedostopnost – Razpored, ki odraža razpoložljivost naprave za sodelovanje v dogodkih DR
• venID – Enolični identifikator za VEN
• voltage –
• vtnComment – Poljubno besedilo
• vtnID – Enolični identifikator za VTN
• x-eiNotification – VEN bi moral prejeti obremenitev dogodka DR pred dtstart minus to trajanje.
• x-eiRampgor – Trajanje pred ali po začetnem času dogodka, med katerim naj bi potekala razbremenitev.
• x-eiRecovery – Trajanje pred ali po končnem času dogodka, v katerem mora potekati razbremenitev.

 

Slovarček oštevilčenih vrednosti

dogodekStatus

• aktivna – Dogodek je bil sprožen in je trenutno aktiven.
• preklicano – Dogodek je bil odpovedan.
• dokončana – Dogodek je zaključen.
• daleč – Dogodek v daljni prihodnosti. Natančna opredelitev tega, kako daleč v prihodnosti se to nanaša, je odvisna od tržnega konteksta, vendar običajno pomeni naslednji dan.
• blizu – Dogodek v čakanju v bližnji prihodnosti. Natančna opredelitev, kako blizu v prihodnosti je čakajoči dogodek aktiven, je odvisna od tržnega konteksta. .Začne se sočasno z dejanskim začetkom dogodka x-eiRampČas pripravljenosti. Če je x-eiRampGor ni definiran za dogodek, ta status ne bo uporabljen za dogodek.
• nič – Ni čakajočega dogodka

itemUnits

• Valuta
  • USD – Ameriški dolarji
  • Za mnoge, ki jih naštejemo tukaj, se obrnite na shemo
• powerReal
  • J/s – Joule-sekunda
  • W – Watts
• temperatura
  • Celzija –
  • Fahrenheit –

oadrDataQuality

• Ni nove vrednosti – uporabljena prejšnja vrednost –
• Ni kakovosti – ni vrednosti –
• Slaba kakovost – Napaka komunikacije –
• Slaba kakovost – Napaka v konfiguraciji –
• Slaba kakovost – okvara naprave –
• Slaba kakovost – zadnja znana vrednost –
• Slaba kakovost – nespecifično –
• Kakovost je slaba – ni povezano –
• Slaba kakovost – ni v uporabi –
• Slaba kakovost – okvara senzorja –
• Kakovost dobra – lokalna preglasitev –
• Kakovost dobra – nespecifična –
• Omejitev kakovosti – polje/konstanta –
• Omejitev kakovosti – polje/visoko –
• Omejitev kakovosti – polje/nizka –
• Omejitev kakovosti – polje/ne –
• Kakovost negotova – enote EU presežene –
• Kakovost negotova – zadnja uporabna vrednost –
• Kakovost negotova – nespecifična –
• Kakovost negotova – senzor ni natančen –
• Kakovost negotova – podnormalna –

oadrResponseRequired

• vedno – Vedno pošlji odgovor za vsak prejeti dogodek.
• nikoli – Nikoli ne odgovori.

optReason

Našteti razlogi za izbiro.

• gospodarskih –
• nujnost –
• mustRun –
• nesodeluje –
• outageRunStatus –
• overrideStatus –
• ki sodelujejo –
• x-razpored –

oadrTransportName

• preprostHttp –
• xmpp –

OptType

• optIn – Navedba, da bo VEN sodeloval pri dogodku, ali v primeru storitve EiOpt vrsto urnika, ki kaže, da bo vir na voljo
• optOut – Navedba, da VEN ne bo sodelovala pri dogodku, ali v primeru storitve EiOpt vrsta urnika, ki kaže, da vir ne bo na voljo

readingType

• Dodeljeno – Merilnik zajema več [virov] in uporaba je predvidena z nekakšnim profesionalnim izračunom podatkov.
• Pogodba – Označuje, da je branje pro forma, tj. poroča se po dogovorjenih tečajih
• Izpeljano – Na uporabo se sklepa na podlagi poznavanja časa delovanja, običajnega delovanja itd.
• Neposredno branje – Odčitek se bere iz naprave, ki se monotono povečuje, porabo pa je treba izračunati iz parov začetnih in končnih odčitkov.
• Ocenjeno – Uporablja se, ko odčitek ni v nizu, v katerem je prisotnih večina odčitkov.
• Hibrid – Če je agregirano, se nanaša na različne vrste branja v skupnem številu.
• Zlobno – Odčitek je povprečna vrednost v obdobju, navedenem v Zrnatosti
• Net – Merilnik ali [vir] pripravi lasten izračun skupne porabe skozi čas.
• Peak – Odčitek je najvišja (najvišja) vrednost v obdobju, navedenem v razdrobljenosti. Pri nekaterih meritvah je morda bolj smiselna najnižja vrednost. Morda ni v skladu s skupnimi odčitki. Velja samo za osnove postavk pretoka, tj. Moč in ne energija.
• Predvideno – Označuje, da je odčitek v prihodnosti in še ni bil izmerjen.
• Povzeto – Več števcev skupaj zagotavlja odčitek za ta [vir]. To se posebej razlikuje od agregiranega, ki se nanaša na več [virov] v istem tovoru. Glej tudi Hibrid.
• x-ni uporabno - Se ne uporablja
• x-RMS – Kvadratni koren

reportName

• HISTORY_GREENBUTTON – Poročilo, ki vsebuje podatke zelenega gumba v strukturi sheme podajanja atomov
• HISTORY_USAGE – Poročilo, ki vsebuje zgodovinske podatke o porabi energije
• METADATA_HISTORY_GREENBUTTON – Poročilo z metapodatki, ki določa zmožnosti poročanja za poročila HISTORY_GREENBUTTON
• METADATA_HISTORY_USAGE – Poročilo z metapodatki, ki opredeljuje zmožnosti poročanja za poročila HISTORY_USAGE
• METADATA_TELEMETRY_STATUS – Poročilo z metapodatki, ki opredeljuje zmožnosti poročanja za poročila TELEMETRY_STATUS
• METADATA_TELEMETRY_USAGE – Poročilo z metapodatki, ki opredeljuje zmožnosti poročanja za poročila TELEMETRY_USAGE
• TELEMETRIJA_STATUS – Poročilo, ki vsebuje informacije o statusu vira v realnem času, kot je spletno stanje
• TELEMETRY_USAGE – Poročilo z informacijami o porabi energije v realnem času

reportType

Oštevilčena vrednost, ki podaja vrsto predloženega poročila.

• na voljoEnergyStorage – Razpoložljiva zmogljivost za nadaljnje shranjevanje energije, morda za dosego Target Energy Storage
• avgDemand – Povprečna uporaba v času, ki ga označuje zrnatost. Za več informacij glejte povpraševanje.
• avgUsage – Povprečna uporaba v času, ki ga označuje zrnatost. Za več informacij si oglejte uporabo.
• izhodišče – Lahko je povpraševanje ali uporaba, kot navaja ItemBase. Označuje, kaj bi bila [meritev], če ne bi bil dogodek ali predpis. Poročilo je v formatu Baseline.
• deltaDemand – Sprememba povpraševanja v primerjavi z izhodiščem. Za več informacij glejte povpraševanje
• deltaSetPoint – Spremembe nastavljene vrednosti glede na prejšnji razpored.
• deltaUsage – Sprememba uporabe v primerjavi z izhodiščem. Za več informacij si oglejte uporabo
• povpraševanje – Poročilo označuje količino enot (denominiranih v ItemBase ali v izdelku EMIX). Vrsta tovora je količina. Tipična ItemBase je Real Power.
• odstopanje – Razlika med nekim navodilom in dejanskim stanjem.
• downRegulationCapacityAvailable – Zmogljivost navzdol regulacije, ki je na voljo za odpremo, izražena v EMIX Real Power. Tovor je vedno izražen kot pozitivna količina.
• raven – Enostavna raven s trga v vsakem intervalu.
• operativno stanje – Splošno stanje vira, kot je vklopljeno/izklopljeno, zasedenost stavbe itd. Nobena ItemBase ni pomembna. Zahteva razširitev obremenitve, specifične za aplikacijo.
• percentDemand – Odsttage povpraševanja
• percentUsage – Odsttage uporabe
• faktor moči – Faktor moči za vir
• cena – Cena na bazo elementov v vsakem intervalu
• branje – Poročilo prikazuje odčitek, kot iz števca. Odčitki so trenutki v času - spremembe v času se lahko izračunajo iz razlike med zaporednimi odčitki. Vrsta tovora je plavajoča
• reguliranjeSetpoint – Nastavitvena vrednost regulacije po navodilih kot del regulacijskih storitev
• setPoint – Poročilo označuje znesek (denominiran v ItemBase ali v izdelku EMIX), ki je trenutno nastavljen. Lahko je potrditev/vrnitev vrednosti nadzora nastavljene vrednosti, poslana iz VTN. Vrsta tovora je količina. Tipična ItemBase je Real Power.
• shranjena energija – Shranjena energija je izražena kot realna energija, tovor pa kot količina.
• targetEnergyStorage – Ciljna energija je izražena kot realna energija, tovor pa kot količina.
• upRegulationCapacityAvailable – Zmogljivost regulacije navzgor, ki je na voljo za odpremo, izražena v EMIX Real Power. Tovor je vedno izražen kot pozitivna količina.
• uporaba – Poročilo označuje količino enot (denominiranih v ItemBase ali v izdelku EMIX) v določenem obdobju. Vrsta tovora je količina. Tipična ItemBase je RealEnergy
• x-resourceStatus – Odsttage povpraševanja

scaleCode

• p – Pico 10**-12
• n – Nano 10**-9
• mikro – Micro 10**-6
• m – Mili 10**-3
• c – Centi 10**-2
• d – Deci 10**-1
• k – 10**3 kilogramov
• M – Mega 10**6
• G – Giga 10**9
• T – Tera 10**12
• nič – Domače merilo

signalName

• BID_ENERGY – To je količina energije iz vira, ki je bila ponujena v program
• BID_LOAD – To je količina obremenitve, ki jo je vir ponudil v program
• BID_PRICE – To je cena, ki jo je ponudil vir
• CHARGE_STATE – Stanje vira za shranjevanje energije
• DEMAND_CHARGE – To je pristojbina za povpraševanje
• ELEKTRIČNA_CENA – To je strošek električne energije
• ENERGY_PRICE – To je strošek energije
• LOAD_CONTROL -Nastavite izhod obremenitve na relativne vrednosti
• LOAD_DISPATCH – Uporablja se za odpremo tovora
• preprosto – amortiziran – za združljivost za nazaj z A profile
• PREPROSTO – Enostavne ravni (združljivo z OpenADR 2.0a)

signalType

Oštevilčena vrednost, ki opisuje vrsto signala, kot je raven ali cena

• delta – Signal označuje znesek, ki ga je treba spremeniti glede na tisto, kar bi uporabili brez signala.
• raven – Signal označuje nivo programa.
• pomnožitir – Signal označuje množitelj, ki se uporablja za trenutno stopnjo dostave ali uporabe glede na tisto, kar bi uporabili brez signala.
• cena – Signal označuje ceno.
• priceMultiplier – Signal označuje množitelj cene. Razširjena cena je izračunana vrednost cene, pomnožena s številom enot.
• priceRelative – Signal označuje relativno ceno.
• nastavljena vrednost – Signal označuje ciljno količino enot.
• x-loadControlCapacity – To je navodilo za delovanje regulatorja obremenitve na ravni, ki znaša nekaj odstotkovtage njegove največje zmogljivosti porabe obremenitve. To je mogoče preslikati na določene krmilnike obremenitve, da izvajajo stvari, kot je ciklično delovanje. Upoštevajte, da se 1.0 nanaša na 100-odstotno porabo. V primeru enostavnih naprav tipa ON/OFF je 0 = OFF in 1 = ON.
• x-loadControlLevelOffset – Diskretne ravni celih števil, ki so relativne glede na običajne operacije, kjer je 0 normalna operacija.
• x-loadControlPercentOffset – Odsttage sprememba običajnega nadzora obremenitve.
• x-loadControlSetpoint – Nastavljene točke regulatorja obremenitve.

– OpenADR A in B Profile razlike

Edina storitev, ki jo podpira A profile je storitev EiEvent. Objekt EiEvent je v A pro poenostavljenfile z naslednjimi omejitvami:

• Dovoljen je samo en signal na dogodek in ta signal mora biti dobro znani signal OpenADR SIMPLE.
• Obstaja omejeno ciljanje na dogodke, pri čemer so podprti samo venID, groupID, resourceID in partyID. (eiEvent:eiTarget).
• Ciljanje na ravni signala z razredi naprav ni podprto (eiEventSignal:eiTarget:endDeviceAsset).
• Osnovne črte niso podprte (eiEvent:eiEventSignals:eiEventBaseline).
• modificationDateTime in modificationReason nista podprta.
• Končna točka URL za preprost HTTP v 2.0b je:
  • https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Nekateri elementi nosilnosti, ki so bili potrebni v A profile so zdaj neobvezne v B profile, vključno z:

• currentValue

– Varnostni certifikati OpenADR

Pravila skladnosti OpenADR zahtevajo naslednje:

• Za izmenjavo potrdil X.1.2 se uporablja TLS različice 509
• VTN morajo imeti potrdila SHA256 ECC in RSA
• VEN-ji lahko podpirajo potrdila SHA256 ECC in RSA ter lahko podpirajo oboje
• Tako VTN kot VEN morata biti konfigurirana tako, da zahtevata potrdila odjemalca, če bosta igrala vlogo transportnega strežnika (tj. odgovarjata na zahteve druge strani).
• Tako VTN kot VEN morata zagotoviti potrdilo odjemalca, ko to zahteva druga stranka kot del pogajalskega postopka TLS

Certifikati, ki jih zagotavlja NetworkFX, bodo specifični za RSA ali ECC. Ustvarjanje teh potrdil se lahko pojavi kot rezultat izpolnjevanja obrazcev na NetworkFX web spletno mesto za zahtevo po preskusnih potrdilih ali je lahko posledica zahtevanja proizvodnih potrdil prek zahteve za podpis potrdila (CSR). Ne glede na metodo, naslednje filebodo zagotovljeni (nprampso prikazane datoteke):

• Korensko potrdilo
• Vmesno korensko potrdilo
• Potrdilo o napravi
• Zasebni ključ

Na splošno se zasebni ključ uporablja za šifriranje tovora, ki ga pošlje VEN ali VTN. Potrdilo naprave je niz edinstvenih identifikacijskih informacij o VEN ali VTN, ki jih je ustvaril overitelj potrdil in šifriral z zasebnim ključem. Koren in vmesni filese uporabljajo za dešifriranje potrdila naprave in preverjanje, ali je potrdilo prišlo od zaupanja vrednega organa.

V okolju Java, ki uporablja JSSE, obstajata dve shrambi potrdil. Ena se imenuje Trust Store in se uporablja za hrambo korenskega potrdila. Drugi se imenuje shramba ključev in se uporablja za shranjevanje verige potrdil, sestavljene iz vmesnega potrdila potrdila naprave in zasebnega ključa.

Upoštevajte, da pri uporabi transporta XMPP VEN komunicira s strežnikom XMPP in NE neposredno z VTN. Torej MORA biti konfiguracija potrdil v strežniku XMPP enaka tisti za VTN. Komunikacija med samim VTN in strežnikom XMPP je pregledna za VEN in je v bistvu zasebna povezava. Kljub temu je večina prodajalcev uporabila niz potrdil VEN v VTN pri komunikaciji s strežnikom XMPP.

Če kot strežnik XMPP uporabljate OpenFire, morate upoštevati še eno omejitev. OpenFire zahteva, da se ime CN, uporabljeno v potrdilih odjemalske naprave, ujema z uporabniškim imenom XMPP naprave, konfiguriranim na strežniku XMPP. To lahko povzroči nekaj nenavadnih imen strank, saj se za ime CN na potrdilih VEN uporablja naslov, podoben MAC (del varnostnih zahtev OpenADR)

Končno bo večina VEN-jev in VTN-jev, ko igrajo vlogo odjemalca transporta, poskušala preveriti, ali ima polje CN potrdila, ki ga zagotovi transportni strežnik, ime CN, ki se ujema z imenom gostitelja entitete, ki je zagotovila potrdilo. To je lahko še en vir težav z interoperabilnostjo pri izmenjavi potrdil. Preverjanje imena gostitelja je običajno mogoče programsko onemogočiti, da se izolirajo tovrstne težave.

Vodnik po programu OpenADR 2.0 za odziv na povpraševanje – Prenos [optimizirano]
Vodnik po programu OpenADR 2.0 za odziv na povpraševanje – Prenos

Reference

• Uporabniški priročnik