OpenADR 2.0

Gvidilo pri Programa Respondo al Postulo

Revizia Numero: 0.92

Dokumenta Stato: Laboranta Teksto

Dokumenta Nombro: 20140701

Kopirajto © OpenADR Alliance (2014/15). Ĉiuj rajtoj rezervitaj. La informoj en ĉi tiu dokumento estas propraĵo de la OpenADR-Alianco kaj ĝia uzo kaj malkaŝo estas limigitaj.

ENHAVO

1 Enkonduko 6

2 Referencoj 6

3 Kondiĉoj kaj Difinoj 6

4 Mallongigoj 9

5 Programoj pri Postuloj-Respondo 9

6 Deplojaj Scenaroj 10

6.1 Rekta 1 11

6.2 Rekta 2 12

6.3 Rekta 3 13

6.4 Rekta 4 14

6.5 Faciliganto 1 15

6.6 Agregator 1 16

7 Deploja Scenaro kaj DR-Programa Mapado 16

8 Elekti DR-Programan Ŝablonon 18

9 Ŝablonoj pri Programaj Respondoj al Postulo 21

9.1 Programo pri Kritika Pinta Prezado (ĈP) 21

9.1.1 CPP DR-Programaj Karakterizaĵoj 21

9.1.2 OpenADR-Karakterizaĵoj por ĈPP-Programoj 22

9.2 Kapacita Oferta Programo 24

9.2.1 Karakterizaĵoj de la Programo DR pri Kapacita Oferto 24

9.2.2 Karakterizaĵoj de OpenADR por Programoj pri Kapacita Oferto 25

9.3 Loĝa Termostata Programo 27

9.3.1 Karakterizaĵoj de Programo DR de Loĝejo-Termostato 27

9.3.2 Karakterizaĵoj de OpenADR por Programoj de Loĝaj Termostatoj 28

9.4 Rapida DR-Forsendo 29

9.4.1 Karakterizaĵoj de Programo Rapida Sendado 29

9.4.2 Karakterizaĵoj de OpenADR por Programoj pri Kapacita Oferto 31

9.5 Loĝtaga Programo pri Uzado de Elektra Veturilo (EV) 33

9.5.1 Loĝaj EV TOU-Programaj Karakterizaĵoj 33

9.5.2 OpenADR-Karakterizaĵoj por Loĝejaj EV TOU-Programoj 33

9.6 Programo pri Reala Tempo pri Elektra Veturilo (EV) de Publika Stacio 34

9.6.1 Karakterizaĵoj de la Programo de Publika Stacio EV RTP 34

9.6.2 Karakterizaĵoj de OpenADR por Programoj RTP de Publika Stacio EV 34

9.7 Distribuita Energio-Rimedoj (DER) DR-Programo 35

9.7.1 Karakterizaĵoj de Programo Distribuita Energio (DER) 35

9.7.2 Karakterizaĵoj de OpenADR por Distribuitaj Energiaj Rimedoj (DER) 35

Anekso A - SampŜablonoj de Datumoj kaj Utila Ŝarĝo 36

A.1 Kritika Pinta Prezprogramo (ĈP) 36

A.1.1 CPP-Scenaro 1 - Simpla Uzkazo, A aŭ B Profile 36

A.1.2 CPP-Scenaro 2 - Tipa Uzokazo, B profile 36

A.1.3 CPP-Scenaro 3 - Kompleksa Uzokazo 37

A.1.4 CPP Sample Event Payload - Tipa B Profile Uzokazo 37

A.2 Kapacita Oferta Programo (CBP) 39

A.2.1 CBP-Scenaro 1 - Simpla Uzkazo, A aŭ B Profile 39

A.2.2 CBP-Scenaro 2 - Tipa Uzokazo, B profile 39

A.2.3 CBP-Scenaro 3 - Kompleksa Uzokazo 40

A.2.4 CBP Sample Event Payload - Tipa B Profile Uzokazo 40

A.3 Loĝa Termostata Programo 42

A.3.1 Loĝa Termostato Scenaro 1 - Simpla Uzkazo, A aŭ B Profile 42

A.3.2 Loĝeja Termostato Scenaro 2 - Tipa Uzokazo, B profile 42

A.3.3 Loĝa Termostato Scenaro 3 - Kompleksa Uzokazo 43

A.3.4 Loĝa Termostato Sample Event Payload - Tipa B Profile Uzokazo 43

A.4 Rapida DR-Forsendo 45

A.4.1 Rapida DR Scenaro 1 - Simpla Uzkazo, A aŭ B Profile 45

A.4.2 Rapida DR-Scenaro 2 - Tipa Uzokazo, B profile 45

A.4.3 Rapida DR-Scenaro 3 - Kompleksa Uzokazo 46

A.4.4 Rapida DR Sample Event Payload - Tipa B Profile Uzokazo 46

A.4.5 Rapida DR Sample Raporta Metadatumo Utila Ŝarĝo – Tipa B Profile Uzokazo 48

A.4.6 Rapida DR Sample Raporta Peto Utila Ŝarĝo - Tipa B Profile Uzokazo 48

A.4.7 Rapida DR Sample Raporto Datumoj Utila Ŝarĝo – Tipa B Profile Uzokazo 49

A.5 Programo pri Uzotempo (TOU) por Loĝveturilo (EV) 49

A.5.1 Loĝa EV-Scenaro 1 - Simpla Uzkazo, A aŭ B Profile 49

A.5.2 Loĝdoma EV-Scenaro 2 – Tipa Uzkazo, B profile 50

A.5.3 Loĝeja EV Sample Event Payload - Tipa B Profile Uzokazo 50

A.6 Programo pri Reala Tempo pri Elektra Veturilo de Publika Stacio (EV) 53

A.6.1 Publika Stacio EV-Scenaro 1 - Tipa Uzokazo, B profile 53

A.6.2 Publika Stacio EV Sample Event Payload - Tipa B Profile Uzokazo 53

A.7 Distribuita Energia Rimedo (DER) DR-Programo 54

Anekso B - Difinoj pri Servo kaj Utila Ŝarĝo 55

B.1 Open ADR subtenas jenajn servojn: 55

Aneksaĵo C - Difinoj pri Servo kaj Utila Ŝarĝo 56

C.1 EiEvent-Utilaj Ŝarĝoj 56

C.2 EiReport Utilaj Ŝarĝoj 56

C.3 EiOpt Utilaj Ŝarĝoj 56

C.4 EiRegisterParty Utilaj Ŝarĝoj 57

C.5 OadrPoll Utilaj Ŝarĝoj 57

Aneksaĵo D - Terminaro de Schema Utila Ŝarĝo-Elementoj 58

Aneksa E Glosaro de Nombritaj Valoroj 65

E.1-evento 65

E.2 ero Unuoj 65

E.3 oadrDatkvalito 65

E.4 oadrRespondoNecese 66

E.5 optReason 66

E.6 oadrTransportNomo 66

E.7 OptType 66

E.8-legado Tipo 66

E.9 raporto Nomo 67

E.10 raporto Tipo 67

Skalo E.11 Kodo 68

E.12 signalName 68

Signalo E.13 Tipo 69

Anekso F – OpenADR A kaj B Profile Diferencoj 70

Anekso G - Sekurecaj Atestoj de OpenADR 71

Enkonduko

La celgrupo por ĉi tiu gvidilo estas servoj, kiuj planas disfaldi programojn Demand Response (DR), kiuj uzas OpenADR 2.0 por komuniki mesaĝojn rilatajn al DR-evento inter la kompanio kaj laŭflue, kaj la fabrikantoj de ekipaĵoj, kiuj faciligas tiun komunikan interŝanĝon. Oni supozas, ke la leganto havas bazan konceptan komprenon pri kaj postulrespondo kaj OpenADR 2.0 (nomata simple kiel OpenADR de ĉi tiu punkto antaŭen).

La OpenADR-profesiulofile specifoj klare difinas la atendatan konduton dum interŝanĝo de informoj pri DR-okazaĵoj, tamen ekzistas sufiĉe da ebleco en OpenADR, ke la disfaldado de serviloj (VTNs) ĉe la utilaĵo kaj klientoj (VENs) ĉe kontraŭfluaj lokoj ne estas plug-n-play sperto. OpenADR-trajtoj kiel eventaj signaloj, raportaj formatoj kaj celado devas esti precizigitaj laŭ program-DR bazo.

Ne ekzistas normigita DR-programo. Ĉiu DR-programo-projekto tendencas esti unika, taŭga al la strukturaj kaj reguligaj postuloj de la geografia regiono, en kiu ĝi estas disfaldita. Por ĉiu DR-programo ekzistas multaj eblaj disfaldaj scenaroj kun diversaj aktoroj.

La ŝanĝebleco en DR-programaj projektoj, disfaldaj scenoj kaj OpenADR-karakterizaĵoj estas malhelpilo al vastigita deplojo de DR kaj la uzo de OpenADR. Ĉi tiu ŝanĝebleco plejparte reflektas la fragmentan kaj kompleksan naturon de la inteligenta krado.

Servoj bezonas ekzample de tipaj DR-programoj tiel ke ili povas esti uzataj kiel modeloj por siaj propraj DR-programaj efektivigoj. Ekipaĵaj fabrikantoj devas kompreni tipajn uzadajn modelojn de DR-Programo, por ke ili povu validigi kunfunkcieblecon kiel parton de la disvolva procezo anstataŭ laŭ specifa bazo de DR-programo. La intenco de ĉi tiu gvidilo estas plenumi ambaŭ ĉi tiujn celojn jene:

• Difinu malgrandan aron de normaj DR-Programaj ŝablonoj laŭ la komunaj trajtoj de la plej popularaj ĝisnunaj DR-programoj
• Difinu malgrandan aron de deplojaj scenaroj laŭ modeloj de reala mondo, kun aktoroj kaj roloj klare identigitaj
• Difinu rekomendojn pri plej bonaj praktikoj por OpenADR-trajtoj specifaj por ĉiu el la ŝablonoj de la Programo DR
• Provizu decidan arbon, kiun servaĵoj povas uzi por identigi la utilajn DR-programajn ŝablonojn kaj disfaldajn scenarojn bazitajn sur siaj komercaj bezonoj

La emfazo en ĉi tiu gvidilo estos simpligi aferojn per provizado de malgranda aro de klaraj rekomendoj, kiuj traktos la plimulton de la detaloj necesaj por disfaldi tipan DR-programon, kaj ebligi kunfunkcieblan testadon de ekipaĵoj deplojitaj en programoj uzantaj la rekomendojn en ĉi tiu gvidilo.

Referencoj

• OpenADR Profile Specifo kaj skemo - www.openadr.org

Terminoj kaj Difinoj

La jenaj terminoj kaj difinoj estas uzataj en ĉi tiu dokumento.

• Postulo-Respondo: Mekanismo administri ŝarĝan postulon de kliento responde al provizaj kondiĉoj, kiel prezoj aŭ disponeblaj signaloj
• Agregator Party - Ĉi tio estas partio, kiu kunigas plurajn Resursojn kaj prezentas ilin al la Partio pri Programo DR kiel ununura Rimedo en iliaj Programoj DR.
• Agregator Intermediate Infrastructure - Ĉi tiu estas la infrastrukturo, aparta de la Postula Flanka Infrastrukturo, kiun uzas la Interregula Partio por Agordi kaj interagi kun la Rimedoj kaj la krad-flankaj entoj.
• Interkonsento: Kontrakta interkonsento inter partioj ludantaj rolon en DR-programo priskribanta respondecojn kaj kompenson
• Aktivo - Speco de Rimedo, kiu reprezentas specifan kolekton de fizikaj ŝarĝoj. Rimedoj povas esti kunmetitaj de Aktivaĵoj, kaj Aktivaĵo povas esti Rimedo, sed Aktivaĵoj ne plu povas malkomponiĝi en multoblajn Aktivaĵojn aŭ Rimedojn.
• Asociita: Provizu programan asocion inter du entoj, per agordo de aparato de datumbazo. Ekzemple, asociitaj rimedoj kun VEN
• Bazlinioj: La kalkulita aŭ mezurita energio-uzado (postulo) de ekipaĵo aŭ ejo antaŭ la evento laŭ determinita per enketoj, inspektadoj kaj / aŭ mezurado ĉe la ejo.
• BMS - Jen la Konstrua Administrada Sistemo, kiu povas esti uzata por regi rimedojn. Ĉi tio estas iam nomata Energitrakta Sistemo.
• Kunmetita Rimedo - Ĉi tio estas speciala tipo de Rimedo, kiu estas aro de multaj fizikaj havaĵoj, kiuj havas siajn proprajn rimedojn por kontroli ŝarĝon.
• Klienta Instigo: Instigo donita al la posedanto / agreganto de postulataj flankaj rimedoj por partopreno en DR-programo.
• Postula Flanka Infrastrukturo - Jen la infrastrukturo, kiu enhavas la Rimedojn enskribitajn en la Programoj DR
• DR Logiko: Algoritmoj aŭ logiko, kiuj konvertas DR-signalojn en efektivigeblan ŝarĝan kontrolon. Notu, ke DR Logic povas esti efektivigita en multaj malsamaj lokoj kaj en iuj kazoj disdonita inter multaj sub-sistemoj.
• Programa Partio DR - ĉi tiu estas la ento respondeca pri la Krada Infrastrukturo kaj krome pri administrado de la DR-Programoj uzataj por mildigi kradajn problemojn. Ĉi tio estas tipe Utileco aŭ ISO.
• Enskribiĝis: La posedanto / agreganto de mendaj flankaj rimedoj elektas partopreni DR-programon kaj povas doni informojn pri la specifaj rimedoj, kiuj povas esti celitaj por DR-eventoj.
• Aktiva Aktiva Periodo: La estas la periodo en la de tempo dum kiu ŝanĝo en la ŝarĝo profile estas petata kadre de DR-Evento
• Eventaj Limoj: La tempokadroj dum kiuj la kliento povas atendi ricevi eventojn kaj rilatajn limojn kiel neniuj eventoj dum semajnfinoj aŭ sinsekvaj tagoj
• Eventaj Tagoj: Tago, kiam okazas DR-evento. Plej multaj programoj havas limojn pri la nombro de eventaj tagoj, kiuj estas permesitaj en difinita kalendara periodo
• Eventa Priskribilo: Parto de la evento OpenADR-objekto, kiu priskribas metadatenojn pri la evento, kiel programo-nomo kaj evento-prioritato
• Eventdaŭro: La daŭro de la evento. Plej multaj programoj difinas limojn pri la daŭro de evento, same kiel la horojn de la tago dum kiuj la evento povas okazi
• Eventaj Signaloj: La prilaboreblaj informoj enhavitaj en evento kiel elektroprezado aŭ specifaj niveloj de ŝarĝoŝipo petis tion tipe ekigi iun antaŭprogramitan ŝarĝan konduton de la ricevanto de la evento. Difino de DR-programo devas specifi la specojn de eventaj signaloj uzataj
• Eventa Celado: La ŝarĝo forĵetanta rimedojn, kiuj estas la celita ricevanto por la DR-evento. La eble temas pri geografia areo, aparta klaso de aparatoj, grupa identigilo, rimeda identigilo aŭ alia identigilo. Difino de DR-programo devas specifi, kiel specifaj rimedoj celos.
• Eventoj: Evento estas sciigo de la programo por postuli flankajn rimedojn petantajn ŝarĝejon ekde specifa tempo, dum difinita daŭro, kaj povas inkluzivi celajn informojn nomumantajn specifajn rimedojn, kiuj devas partopreni la eventon.
• Faciliga Meza Infrastrukturo - Ĉi tiu estas la infrastrukturo, aparta de la Demanda Flanka Infrastrukturo, kiun uzas la Faciliga Intermedia Partio por interagi kaj kun la Rimedoj kaj kun la krad-flankaj entoj.
• Faciliganto: Tria, kiu administras parton aŭ la tutan plenumon de la DR-programo nome de la programo
• Krada Infrastrukturo - Ĉi tiu estas la infrastrukturo posedata aŭ administrata de la Partioj de la Programo DR. Ĉi tiu infrastrukturo inkluzivas la efektivigon de la OpenADR VTN, kiu estas uzata por sendi DR-signalojn al Rimedoj enskribitaj en la DR-Programoj
• Intermedia Partio - Ĉi tio estas partio, kiu kutime laboras nome de la Resursa Partio por faciligi ilian partoprenon en Programoj pri DR.
• Ŝarĝo Kontrolo - ĉi tio estas la infrastrukturo rilata al Rimedo, kiu respondecas pri efektive kontroli la Rimedon kaj produkti specifan ŝarĝonfile.
• Ŝarĝi Avantaĝonfile Objektivo: Ĉi tiu instigo malantaŭ disvolvi DR-programon kaj eldoni eventojn. Kiel ekzemple la deziro razi pintajn ŝarĝojn.
• Sciigo: Tempodaŭro antaŭ la komenca tempo de evento, kie la postulanto de la rimedposedanto estas sciigita pri pritraktata evento
• Opt Konduto: La atendita respondo de la posedanto de rimedposedanto post ricevo de evento. Ĉi tiu respondo povas preni la formon de kaj OptIn aŭ OptOut-indiko ĉu rimedo partoprenos aŭ ne la eventon
• Elekti Respondojn: Ĉu specifa programo devas postuli respondon de postulaj flankaj rimedoj responde al evento, kaj kiaj estas tiuj respondoj tipe.
• Elektaj Servoj: Horaroj komunikitaj per OpenADR por indiki provizorajn ŝanĝojn en rimedhavebleco por partopreni eventojn.
• Antaŭkondiĉo: Kriterioj plenumendaj por ke posedanto de postulata rimedo enskribiĝu en DR-programo. Ĉi tio povas inkluzivi la haveblecon de intervala kunveno aŭ iom da minimuma ŝarĝo
• Ĉefaj Ŝoforoj: La ĉefa instigo fare de la ilo por krei la DR-programon kaj eldoni eventojn. Kiel "Pinta postula redukto kaj taŭga rimedo"
• Programoj - Jen la DR-Programoj, en kiuj la Rimedoj estas enskribitaj.
• Programo Priskribo: Rakonta priskribo de kiel programo funkcias. Parto de la ŝablonoj de la Programo DR difinita en ĉi tiu dokumento
• Programa Tempokadro: La tempo de la jaro aŭ sezonoj dum kun DR-programo estas kutime aktiva
• Imposto-Dezajno: La specifaj modifoj al la tarifa strukturo aŭ instigoj pagitaj por instigi postulemajn rimedposedantojn partopreni la programon
• Aliĝaj Servoj: Servo uzata de la protokolo OpenADR por establi bazan kunfunkcieblecon inter VTN kaj VEN, kaj konfirmi, ke la VEN estas asociita kun la konto de klientoj.
• Raportaj Servoj: Servo uzita de la OpenADR por ebligi al VEN-oj doni raportojn al VEN-oj. DR-Programo devas specifi la raportajn postulojn por la programo.
• Rimedfesto - Ĉi tiu estas la partio, kiu posedas la postulojn pri Rimedoj, kiuj eble enskribiĝos en DR-Programoj
• Rimedo - Ĉi tiu estas la ento, kiu estas enskribita en la DR-Programoj kaj kapablas liveri ian ŝanĝon al sia ŝarĝo profile responde al ricevado de DR-signalo de VTN.
• Celata Kliento: La profesiulofile de postulaj flankaj rimedoj, kiuj povas enskribiĝi en specifaj DR-programoj kiel loĝdoma, industria aŭ eble bazita sur nivelo de elektrokonsumo.
• Celaj Ŝarĝoj: La postulaj flankaj rimedoj, kies ŝarĝo devas esti modifita post ricevo de
• VEN - Ĉi tio estas la OpenADR Virtuala Fina Nodo, kiu estas uzata por interagi kun la VTN.
• VTN - Ĉi tio estas la OpenADR-Virtuala Supra Nodo, kiu estas uzata por interagi kun la Rimedoj enskribitaj en la DR-Programoj.

Mallongigoj

• BMS: Konstrua Administrada Sistemo
• C&I: Komerca kaj Industria
• Kom: Komunikadoj inter du entoj
• DR: Postula Respondo
• EMS: Energitrakta Sistemo
• OpenADR: Malferma Aŭtomata Postula Respondo
• Programoj: Referenco al Programo (j) pri Postula Respondo (j)
• VEN: Virtuala Fina Nodo
• VTN: Virtuala Supra Nodo

Programoj-Tipoj pri Postula Respondo

Ĉi tiu dokumento enhavas ŝablonojn por la DR-programoj montritaj sube.

 

1. Kritika Pinta Prezado: Imposto kaj / aŭ prezstrukturo desegnita por instigi reduktitan konsumon dum periodoj de altaj pograndaj merkataj prezoj aŭ sistemaj eventualaĵoj per trudado de antaŭdifinita alta imposto aŭ prezo por limigita nombro da tagoj aŭ horoj.

2. Kapacita Oferta Programo: Programo, kiu permesas postulan rimedon en podetalaj kaj pograndaj merkatoj oferti ŝarĝajn reduktojn je prezo, aŭ identigi kiom da ŝarĝo ĝi pretas limigi je specifa prezo.

 

3. Programo pri Loĝa Termostato / Rekta Ŝarĝa Kontrolo: Postula responda agado, per kiu la programo-sponsoro remotore regas la elektran ekipaĵon de kliento (ekz. Klimatizilo) kun mallonga avizo. Ĉi tiuj programoj estas ĉefe ofertataj al loĝaj aŭ malgrandaj komercaj klientoj.

4. Rapida DR-Forsenda / Flanka Servoj-Programo: Programo pri postula respondo, kiu provizas instigajn pagojn al klientoj por ŝarĝa respondo dum Krizokaza Respondo-Evento. Nenormala sistemo-kondiĉo (ekzample, sistemaj limigoj kaj lokaj kapacitlimoj) kiu postulas aŭtomatan aŭ tujan manan agadon por malhelpi aŭ limigi la fiaskon de dissendaj instalaĵoj aŭ generacia provizo kiu povus negative influi la fidindecon de la Bulka Elektra Sistemo. Ĉi tiaspecaj programoj foje povas esti nomataj "Flankaj Servoj".

5. Programo pri Elektra Veturilo (EV): Ago pri postula respondo, per kiu la kosto de ŝargado de elektraj veturiloj estas modifita por igi konsumantojn ŝanĝi konsumajn mastrojn.

6. Programo pri Distribuitaj Energiaj Rimedoj (DER): Ago pri postula respondo uzata por mildigi la integriĝon de distribuaj energiaj rimedoj en la inteligentan reton.

 

Deplojaj Scenaroj

La maniero laŭ kiu DR-programo estas deplojita estas iom sendependa de la karakterizaĵoj de la DR-programo mem. La sekvaj diagramoj montras diversajn manierojn, kiel DR-programo povus esti deplojita. La sekva sekcio disponigas krucreferencon inter la deplojaj scenaroj kaj la DR-Programoj, kun kiuj ili plej verŝajne estos uzataj.

La diagramoj en ĉi tiu sekcio montras la rilatojn inter la entoj en la diversaj scenaroj.

Rekta 1

Ĉi tio estas simpla scenaro, en kiu ekzistas rekta rilato inter la Programo-Partio DR kaj la Rimeda Partio. La Rimeda Partio respondecas pri rekrutado de siaj propraj Rimedoj en la DR-Programojn kaj la Reto-Infrastrukturo interagas rekte kun la Rimedoj per VEN kiu loĝas ene de la Posta Flanka Infrastrukturo. Krome la VEN estas posedata fare de la Rimeda Partio kaj estas aparta de la Rimedoj kaj iliaj regiloj. Kiam DR-signalo estas ricevita fare de la VEN ĝi tipe ne efektivigas ajnan ŝarĝkontrollogikon, sed simple plusendas la signalojn al la ŝarĝregiloj kiuj prenas la konvenan agon. EkzampLa scenoj inkluzivus konstruaĵojn C&I, kiuj povas instali enirejon, kiu enhavas OpenADR VEN kaj kiam signalo ricevas per tiu enirejo, ĝi simple tradukas ĝin al iu alia protokolo kaj plusendas al la ŝarĝaj regiloj mem.

Rekta 2

Ĉi tio estas tre simila al la Rekta 1-scenaro. La ĉefa diferenco estas en kiel la VEN estas instantiigita kaj la interagoj kun la VTN faciligita. La VEN estas instantiigita en ento kiel alcentrigita BMS kiu povas efektivigi DR-logikon kaj interagi kun Compound Resource kaj iliaj multaj malsamaj ŝarĝregiloj de pli centralizita loko. Ekzampili inkluzivas grandajn konstruaĵojn kun BMS kiu kontrolas multajn malsamajn ŝarĝojn en konstruaĵo (ekz. lumigado, HVAC, industriaj procezoj, ktp.) al c.ampuzoj, kiuj povas havi multoblajn instalaĵojn kun centralizita kontrola sistemo.

Rekta 3

Ĉi tiu scenaro estas tre simila al la Rekta 1-scenaro. La ĉefa diferenco estas, ke la VEN estas instantiigita rekte en la rimedo kaj ĝia ŝarĝregilo. En ĉi tiu kazo la DR-signaloj estas senditaj rekte al la rimedo kaj ĝia ŝarĝregilo. La tiel nomata "prezoj al aparatoj" scenaro apartenas al ĉi tiu kategorio. Ekzamples inkluzivus ajnan specon de ŝarĝregilo kiel ekzemple HVAC (te termostato) kiu havas enigitan VEN kiu kapablas interagi rekte kun la kradaj flankaj unuoj VTN.

Rekta 4

Ĉi tio estas kombinaĵo de specoj de la scenoj Rekta 1 kaj Rekta 2. La ĉefa diferenco estas, ke multoblaj VEN-oj rilatas al ununura Kompona Rimedo, kiu konsistas el multnombraj aktivoj kun siaj propraj ŝarĝaj regiloj. Ĉiu el la ŝarĝaj regiloj, kiuj konsistas el la Kunmetita Rimedo, povas esti asociita kun malsama VEN. Notu, ke ĉiuj VEN-oj estus sub kontrolo de la sama Resurso-Partio, kiu posedas la Kunmetitan Rimedon. Ĉi tiu scenaro ekzistas por faciligi Demandajn Flankajn Infrastrukturojn, kiuj havas Kunmetitajn Resursojn, sed ne havas centralizitan BMS kiel la Rekta 2-scenaro. Ekzampili povus inkluzivi konstruaĵojn kun malsamaj ŝarĝaj regiloj sur ĉiu etaĝo, sed neniu centralizita BMS, aŭ ĉampuzas kun malsamaj regiloj en ĉiu konstruaĵo, sed ne ĉampus larĝa regilo. Ĉar de la perspektivo de la DR Program Party ekzistas nur ununura rimedo rekrutita en la programo kiam ĝi volas sendi DR-signalon al la rimedo ĝi povas simple sendi la samajn signalojn al ĉiu el la elektitaj VENoj kiuj estis asociitaj kun la Rimedo.

Faciliganto 1

En ĉi tiu scenaro ekzistas peranto, kiu faciligas interagojn inter la Programo-Partio DR kaj la Rimedoj. Tipe la Peranto-Partio laboras nome de la Rimeda Partio por helpi ilin administri siajn Rimedojn. La Rimedaj Partioj havas rektajn rilatojn kun la DR Programo-Partio kaj ili enskribas siajn proprajn Rimedojn en la DR-Programojn. Tiel la Programo-Partio DR views ĉiu Rimeda Partio kiel aparta Rimedo kaj povas interagi kun ili individue. La rolo de la Intermedia Partio estas agi kiel interŝanĝo por ĉiuj OpenADR-rilataj interagoj, tiel la VEN estas kreita ene de la Faciliga Intermedia Infrastrukturo. Tia infrastrukturo ofte estas nubaj bazoj kaj ofertitaj al la Rimedaj Partioj kiel Programaro kiel Servo (SaaS). Kiam la DR-signalo estas ricevita de la VEN de la Faciliganto kelkaj malsamaj agoj povas okazi inkluzive de plusendado de la DR-signalo al la konvena Rimedo kaj eventuale efektivigado de ia DR-Logiko kaj sendado de ŝarĝkontrolkomandoj al la ŝarĝregilo de ĉiu Rimedo. EkzampLa dosieroj de ĉi tiu scenaro inkluzivas:

• Vendistoj, kiuj administras la instalaĵojn por grandaj komercaj ĉenoj kiel ekzemple grandaj kestaj podetalistoj.
• Perantoj de industria kontrolo.
• Kompanioj pri Energiaj Servoj (ESCO)
• Nubaj aparatoj kaj aparataj mastrumaj sistemoj kiel la emerĝaj inteligentaj komunikaj termostataj vendistoj.

Agregator 1

Ĉi tiu scenaro similas al la scenaro de Faciliganto. La ĉefa diferenco estas, ke la Partio Agregator havas la rilaton kun la Partio Programo DR kontraste al la Partioj Resurso. La Agregacia Partio agregas multnombrajn Klientajn Aktivaĵojn en unu Resurson, kiun ĝi enskribas en la Programojn DR. La Programa Partio DR ne havas videblecon pri la unuopaj Aktivaĵoj, kiujn la Agregilo administras. Kiel kun la Faciliganto, la Agregator havas sian propran infrastrukturon, kie la VEN estas kreita. La diferenco estas, ke kiam DR-signalo ricevas, ĝi referencas al unu sola rimedo kaj la Agregilo efektivigas ian DR-logikon super ĉiuj Aktivaĵoj en sia biletujo por atingi la celojn specifitajn en la DR-signalo.

 

Deplena Scenaro kaj DR-Programa Mapado

La suba tabelo provizas pri kiuj deplojaj scenaroj plej oftas por specifa DR-Programo.

	Deploja Scenaro
DR-Ŝablono	Rekta 1, 2, 3, 4	Faciliganto 1	Agregator 1
CPP-Programo	∆	∆
Kapacita Oferta Programo			∆
Loĝa Termostato Programo		∆
Rapida DR-Forsendo			∆
Programo pri Elektra Veturilo (EV)	∆	∆
Programo pri Distribuitaj Energiaj Rimedoj (DER)	∆	∆

Elektante DR-Programan Ŝablonon

La jenaj estas aro de demandoj, kiuj rilatas al iu ajn programo, kiu intencas efektivigi novan DR-programon. Ĉi tio ne celas esti ampleksa, sed reprezentas iujn el la pli trafaj aferoj. La intenco de ĉi tiuj demandoj estas helpi gvidi servojn al taŭga aro de ŝablonoj de Programo DR.

Q: Kial vi volas fari DR? Kiun kradan kondiĉon aŭ operacian problemon vi provas mildigi per DR?

Ĉi tio estas senkompare la plej grava demando kaj formas la bazon por la ĝeneralaj postuloj kaj celoj por tio, kion la DR-programo supozeble atingos. La respondo al ĉi tiu demando difinas kiel la postulo ŝarĝas profile supozeble estas formita de la DR-programo. Ĉiuj aliaj postuloj fluas de la respondo al ĉi tiu demando.

• Ĉu vi provas razi pintojn?
• Ĉu vi volas plenigi la ventron de la anaso?
• Ĉu vi provas kovri la tujan prezon de elektro?
• Ĉu vi zorgas pri krada fidindeco?
• Ĉu vi provas konservi kradajn aktivaĵojn?
• Ktp ktp ktp

La suba tabelo donas iom da aldona kunteksto al la motivoj malantaŭ voli disvolvi DR-Programon

Krada Fidindeco kaj Sekureco	Ofteco kaj Voltage Stabileco
	Rimedo-Taŭgeco
	Pinta Kapacito
	Ramping
	Eventualo
Akiro de Energio	Spotaj Merkataj Prezoj
	Preza Arbitracio
Aktiva Administrado	Damaĝo Preventado
	Redukto de Bontenado
	Dumviva Plilongigo
Kapacita Administrado	Ekonomiaj Profitoj
	Administrado de Krizo
Media	Negavato
	Pura Energio

D: Ĉu ekzistas jam ekzistanta DR-programo aŭ tarifo por ĉi tiu programo?

• Ofte la programaj reguloj estas eksplicite klarigitaj en tarifo.

Q: Kiun postulan flankan merkatan segmenton vi celas per ĉi tiu programo?

Ĉi tio eble helpos determini la celadon de la rimedoj en la evento kaj la specon de signalo.

• Loĝdoma
• Granda C&I
• Malgranda C&I
• Agrikulturo
• Akvoadministrado
• Elektraj Veturiloj
• Ktp, ktp, ktp

D: Ĉu vi provas celi specifajn specojn de ŝarĝoj?

• Termostatoj
• Elektraj veturiloj
• Ag pumpiloj
• ktp.

Q: Kio estas via deploja modelo?

La respondo al ĉi tiu demando povas influi kiel rimedoj estas difinitaj ene de la programo kaj determini kiel tiuj rimedoj celas ene de eventoj.

• Rekta al klientoj
• Per perantoj kiel agregantoj aŭ faciligantoj
• Kliento respondeca pri akirado kaj disfaldado de sia propra VEN-ekipaĵo?
• ktp.

P: Je kia specifa nivelo vi volas interagi kun la postulaj flankaj ŝarĝoj?

Ĉi tiu demando iom rilatas al la deplojmodelo kaj determinas kiel la rimedoj en la programo estas difinitaj kaj celitaj. Ĝi estas unu el la plej gravaj kaj eble kompleksaj demandoj.

• Interagi kun ĉiu individua rimedo
• Interrilati per faciligilo aŭ agreganto sen specifo de la rimedoj malantaŭ ili
• Interrilati per faciligilo aŭ agreganto KAJ precizigi, kiuj rimedoj malantaŭ ili devas esti senditaj
• Uzu lokon kiel atributon por specifi rimedojn
• Uzu ian difinitan grupan mekanismon por specifi rimedojn
• Celu individuajn aktivojn kiel termostatoj
• Interrilati tute sen rimedoj kaj nur elsendi DR-eventojn
• ktp.

Q: Kian interagan ŝablonon vi volas uzi por influi viajn klientojn ŝarĝi profesiajnfiles?

Ĉi tiu demando determinas la specon de DR-signaloj, kiuj estos senditaj al partoprenantoj en programo.

• Instigoj (ekz. Dinamika prezado)
• Ŝarĝaj sendoj (ekz. Helpaj servoj)
• Rekta ŝarĝa kontrolo
• Senmarka evento-signalo
• ktp.

Q: Kio estas la ĝeneralaj rimedaj planaj atributoj de la programo?

• Datoj kaj horoj, kiujn eventoj povas nomi
• Ofteco de eventoj
• Daŭro de la eventoj
• Permeseblaj latentecoj por disvastigo de eventoj
• ktp.

Q: Kiel estas difinita la havebleco de rimedoj en la programo?

• Per striktaj programaj reguloj
• Kiel parto de iu nomuma aŭ ofertprocezo farita de la rimedo
• Ĉu rajtas elekti / eliri?
• ktp.

Q: Kian videblecon vi bezonas por la agado de la rimedo?

Ĉi tio estas tre vasta demando kaj determinas, kian informon retroefikas la rimedoj en la DR-programo. Ĝenerale ĉi tio determinas la specon de raportoj necesaj.

• Interreta / eksterrete
• Uzado (aktuala kaj / aŭ historia)
• Ŝarĝa responda potencialo
• Ŝarĝu haveblecon
• Ŝarĝo / aktiva stato (aktuala kaj / aŭ historia)
• Ktp, ktp ktp.

Programaj Ŝablonoj pri Postula Respondo

Kritika Pinta Preziga Programo (ĈPP)

CPP DR-Programaj Karakterizaĵoj

Ŝarĝi Avantaĝonfile Objektivo	-Pinta postula redukto
Ĉefaj Ŝoforoj	-Reduktitaj kapitalelspezoj kaj reduktitaj energiaj kostoj
Programo Priskribo	Kiam kompanioj observas aŭ antaŭvidas altajn pograndajn merkatajn prezojn aŭ krizajn kondiĉojn de elektrosistemo, ili povas alvoki kritikajn eventojn dum difinita periodo (ekz. 3:6 - XNUMX:XNUMX en varma somera labortago), la prezo por elektro dum ĉi tiuj periodoj estas sufiĉe levita.
Klienta Instigo	Al klientoj povas esti ofertitaj rabatitaj energiprezoj dum ne-pintaj tempoj kiel instigo partopreni la programon.
Imposto-Dezajno	CPP estas prezo-programo kun tarifoj kreskantaj dum kritikaj pintoj en energikonsumo. Tipe CPP-tarifoj estas sumigilo aŭ multiplikanto al plataj, tieritaj aŭ TOU-bazaj tarifoj.
Celata Kliento	-Reza aŭ C&I
Celŝarĝo	-Ajn
Antaŭkondiĉo	-Kliento devas havi intervalon -C & I-klientoj eble devos plenumi postulan kriterion
Programa Tempokadro	-Tipe ampleksas monatojn de la jaro, kie okazas pinta energikonsumo, kvankam eble iujare en iuj kazoj.
Eventaj Limoj	-Tipe lunde ĝis vendrede, krom festotagoj, kun sinsekvaj tagokazaĵoj tipe permesataj
Eventaj Tagoj	-Tipe 9 ĝis 15 jare
Eventdaŭro	-Tipe dum fiksa tempokadro por ĉiuj eventoj de 4 ĝis 6 horoj dum la plej altaj energikonsumaj horoj de la tago.
Sciigo	-Tipe antaŭ tago
Opt Konduto	-Tipe klientoj ne bezonas partopreni eventojn
Atestado Eventoj	-Tipe neniu

Karakterizaĵoj de OpenADR por Programoj de ĈPP

Eventaj Signaloj	–SIMPLA signalo kun niveloj 1 ĝis 3 mapita al la prezo-efiko de la CPP-evento. Se CPP-programo havas ununuran prezigan komponenton ĝi estu mapita al nivelo 1. Por CPP-programoj kun multnombraj prezaj komponantoj, la plej malgranda prezkomponento estu mapita al nivelo 1, kun la aliaj prezaj komponantoj mapitaj al niveloj 2 kaj 3 laŭ kreskanta grado de prezo-efiko. -Se la deplojo subtenas B profile VENoj, aldone al la SIMPLA signalo, ELECTRICITY_PRICE-signalo povas esti inkluzivita en la utila ŝarĝo kun speco de prezo Relativa, prezo Absoluta aŭ prezo Multiplikanto depende de la naturo de la programo. Vidu Anekson A por ekzamples.
Elekti Respondojn	-VTN-oj sendantaj eventojn devas agordi la elementon oadrResponseRequired al "ĉiam", postulante la VEN respondi per optIn aŭ optOut -Ĉar partopreno en CPP-programo estas "plej bona peno" ekzerco, ne ekzistas formala signifo por elekti aŭ elekti ekster ĝentileco pri indico pri partopreno. Ni rekomendas tion VENoj respondas per optIn krom se okazis iu specifa anstataŭiga ago farita de la kliento. -La utila ŝarĝo de oadrCreateOpt kutime ne uzus por kvalifiki rimedojn partoprenantajn eventojn.
Eventa Priskribilo	-La evento prioritato estu fiksita al 1 krom se la programaj reguloj aŭ VTN-agordo specifas alie –Testokazaĵoj kutime ne estas uzataj kun CPP-programoj. Tamen se ili rajtas, la elemento testEvent estu agordita al "vera" por indiki la testan eventon. Se aldonaj parametrigitaj informoj necesas en ĉi tiu elemento, ĝi povas sekvi "vera" apartigita per spaco kun ĉi tiuj aldonaj informoj.
Aktiva Aktiva Periodo	– eiRampSupre, eiRecovery, tolerelementoj kutime ne estas uzataj
Bazlinioj	–Bazlinioj estas kutime ne inkluzivitaj en la evento utila ŝarĝo
Eventa Celado	-CPP-programoj kutime ne diferencas inter rimedoj por donita kliento. Celado tipe specifas la venID, indikante ke ĉiuj rimedoj asociitaj kun la VEN devas partopreni, aŭ listo de ĉiuj rimedaj IDoj asociita kun VEN.
Raportaj Servoj	–Telemetria raportado kutime ne estas uzata ĉar ĝi ne estas absolute necesa por CPP-programoj. Vidu al Anekso B por ekzampraportoj de utilaj pilotoj, kiuj povus esti aplikeblaj al ĉi tiu speco de programo.

Elektaj Servoj	–Uzo de la Opt-servo komuniki provizorajn disponeblajn horarojn kutime ne estus uzata kadre de programo de ĈPP. Tamen iuj deplojoj povus uzi ĉi tiun servon por konservi disponeblajn eventajn tagojn por klientoj, kiuj indikas mankon de havebleco.
Aliĝaj Servoj	Intervokaj intervaloj petita de VTN por tipaj tag-antaŭaj CPP-programoj ne devas esti pli oftaj ol unufoje hore. Tamen la uzo de voĉdonado por detekto de korbatoj povas postuli pli oftan voĉdonadon.

Kapacita Oferta Programo

Kapablaj Ofertaj DR-Programaj Karakterizaĵoj

Ŝarĝi Avantaĝonfile Objektivo	-Pinta postula redukto kaj taŭga rimedo
Ĉefaj Ŝoforoj	-Reduktitaj kapitalelspezoj kaj reduktitaj energiaj kostoj
Programo Priskribo	La kapabla ofertprogramo estas uzata de ISO / utilaĵoj por akiri antaŭ-engaĝitan ŝarĝan kapaciton de agregantoj aŭ memagregitaj klientoj. Ĉi tiu antaŭfiksita kapacita ŝarĝa kapablo estas uzata de ISO / utilaĵoj kiam ili observas aŭ antaŭvidas altajn pograndajn merkatajn prezojn, krizajn kondiĉojn de elektrosistemo, aŭ kiel parton de normala energi-rimeda uzado vokante DR-eventojn dum difinita tempoperiodo.   Rimarku, ke ĉiu agreganto kutime respondecas pri projektado de sia propra postula respondoprogramo same kiel akiro de klientoj, kaj sciigo pri evento por plenumi la kapablajn devontigojn faritajn kiel parto de ĉi tiu programo.
Klienta Instigo	Agregantoj / klientoj ricevas du specojn de instigoj. Unue, ili ricevas kapacitan pagon pro tenado de specifa kvanto de ŝarĝoŝarĝita kapablo havebla por DR-eventoj dum estonta tempofenestro. Due, se evento estas alvokita dum la estonta tempofenestro, energipago povas esti farita por ŝarĝo deĵetita dum la daŭro de la evento.
Imposto-Dezajno	Partoprenantoj en la programo ofertas "kapacitan nomumon", indikante la ŝarĝan kapaciton, kiun ili pretas teni kiel haveblan dum estonta tempofenestro. La oferto ankaŭ povas inkluzivi la instigon, kiun la agreganto / kliento pretas akcepti por ŝarĝo deŝutita sub baza valoro. En utilaj merkatoj la kapacita devontigo kutime estas por la sekva kalendara monato, kvankam multe pli longaj tempokadroj estas uzataj en ISO-merkatoj. Kadre de la kandidatiga kandidato, la kliento eble povos elekti inter kelkaj trajtoj inkluzive de antaŭtaga aŭ taga avizo kaj la daŭro de la evento (kiel 1-4 horoj, 2-6 horoj, ...). Kapacita pago estas farita al la kliento por ĉi tiu antaŭ-devontigo eĉ se ne okazas eventoj dum la tempofenestro. Se okazaĵo estas anoncita dum la tempofenestro la kliento povas ricevi energipagon por la ŝarĝoŝedo rilate al bazlinio, tamen punoj povas validi se malpli ol la antaŭ-engaĝita ŝarĝoŝedkapacito estas liverita tiutempe kiam la okazaĵo estas anoncita.
Celata Kliento	-Agregantoj kaj mem agregitaj klientoj de C&I
Celaj Ŝarĝoj	- Ajna

Antaŭkondiĉo	-Kliento devas havi intervalon -C & I-klientoj eble devos plenumi postulan aŭ ofertan kriterion
Programa Tempokadro	-Kiam ajn
Eventaj Limoj	-Tipe lunde ĝis vendrede, krom festotagoj, kun sinsekvaj tagokazaĵoj tipe permesataj
Eventaj Tagoj	-Tipe maksimume 30 horojn monate
Eventdaŭro	-Tipe dum fiksa tempofenestro por ĉiuj eventoj dum la plej altaj energikonsumaj horoj de la tago.). Eventa daŭro varias laŭ klienta kapablo-devo kun preferoj de 1 ĝis 8 horoj aŭ laŭ specifo de la projekto de la programo
Sciigo	-Tage-antaŭen aŭ tage-depende de kliento kapablo devontigo preferoj aŭ la projekto de la programo
Opt Konduto	-Tipe klientoj elektus partopreni eventojn, ĉar ĉar ili antaŭdecidis ŝarĝon.
Atestado Eventoj	-Tipe du jare (Testo)

Karakterizaĵoj de OpenADR por Programoj pri Kapacitaj Ofertoj

Eventaj Signaloj	–SIMPLA signalo kun niveloj 1 ĝis 3 mapita al la kvanto de ŝarĝo verŝita. Se la programo nur subtenas ununuran nivelon de ŝarĝoŝovo, tio devas esti mapita al nivelo 1. Por programoj kun multnombraj niveloj de ŝarĝoŝovo, la plej malgranda ŝanĝo de normala funkciado devas esti mapita al la nivelo 1, kun la ŝarĝoŝipo valoroj mapitaj al niveloj 2 kaj 3 en kreskanta grado da ŝarĝoŝedo. -Se la deplojo subtenas B profile VENoj, krom la SIMPLE signalo, BID_LOAD kaj / aŭ BID_PRICE-signalo povas esti inkluzivita en la utila ŝarĝo kun signalaj specoj de setpoint kaj prezo, kaj unuoj de potencoReal kaj currencyPerKW respektive. La BID_LOAD reflektus la petitan ŝarĝon supren al kapacita kvanto ofertita de la agreganto / kliento, kaj la BID_PRICE reflektus la instigan oferton de la agreganto / kliento. Vidu Anekson A por ekzamples.
Elekti Respondojn	-VTN-oj sendantaj eventojn devas agordi la elementon oadrResponseRequired al "ĉiam", postulante la VEN respondi per optIn aŭ optOut -Kiel agregantoj / klientoj havas antaŭ-engaĝitan kapablon VEN-oj devas respondi per optIn. Malpermeso povas esti sendita kiel respondo al la evento, sed ĉi tio estas neformala indiko pri havebleco, ne formala elekto el la evento. -La oadrCreateOpt-utila ŝarĝo kutime ne estus uzata kvalifiki rimedojn partoprenantajn eventojn kiel kutime la ŝarĝo estas ununura ento.
Eventa Priskribilo	-La evento prioritato estu fiksita al 1 krom se la programaj reguloj aŭ VTN-agordo specifas alie –Testokazaĵoj povas esti uzataj kun programoj pri Kapacita Oferto. Se ili rajtas, la elemento testEvent estu agordita al "vera" por indiki la testan eventon. Se aldonaj parametrigitaj informoj necesas en ĉi tiu elemento, ĝi povas sekvi "vera" apartigita per spaco kun ĉi tiuj aldonaj informoj.
Aktiva Aktiva Periodo	– eiRampSupre, eiRecovery, tolerelementoj kutime ne estas uzataj
Bazlinioj	–Bazlinioj estas kutime ne inkluzivitaj en la evento utila ŝarĝo ĉar ĉi tiuj datumoj kutime ne haveblas en la momento de la evento. Tamen ambaŭ servoj kaj agregantoj / klientoj farus tion view la inkludo de bazliniaj informoj en eventoj kiel utila.
Eventa Celado	-Kapacitaj Ofertaj programoj kutime ne diferencas inter rimedoj por donita kliento. Celado tipe specifas la venID, indikante ke ĉiuj rimedoj asociitaj kun la VEN devas partopreni, aŭ inkluzivas resourceID-reprezentanton de la entuta ŝarĝo asociita kun VEN.
Raportaj Servoj	Programoj pri Ofertaj Kapabloj de ISO kutime postulas TELEMETRY_USAGE-raportojn kun powerReal datumpunktoj. Vidu ekzamples en Anekso A. Telemetria raportado pri utila Kapacita Oferto kutime ne necesas. Notu, ke telemetria raportado postulas B profile VENoj. Vidu al Anekso B por ekzampraportoj de utilaj pilotoj, kiuj povus esti aplikeblaj al ĉi tiu speco de programo.
Elektaj Servoj	–Uzo de la Opt-servo komuniki provizorajn disponeblajn horarojn kutime ne estus uzata kadre de programo de Kapacita Oferto, ĉar klientoj antaŭdifinis sian haveblecon. Tamen ĉi tiu servo povas esti utila kiel neformala maniero por partoprenantoj indiki mankon de havebleco pro mildigaj kialoj kiel fiaska ekipaĵo.
Aliĝaj Servoj	Intervokaj intervaloj petita de VTN por tipaj tagaj programoj ne devas esti pli oftaj ol unufoje hore. Tamen, la uzo de voĉdonado por detektado de korbatoj aŭ taga programo povas postuli pli oftan voĉdonadon.

Loĝa Termostata Programo

Ĉi tiu programo estas reprezenta de Rekta Ŝarĝa Kontrolo (DLC), kie la signala Demanda Respondo rekte modifas la konduton de ŝarĝo deĵetanta rimedojn, sen tavolo de abstraktado inter ricevo de la signalo kaj la specifa ŝarĝo deĵetanta agon.

Loĝaj Termostatoj DR-Programaj Karakterizaĵoj

Ŝarĝi Avantaĝonfile Objektivo	-Pinta postula redukto
Ĉefaj Ŝoforoj	-Reduktitaj kapitalelspezoj kaj reduktitaj energiaj kostoj
Programo Priskribo	-Kiam servaĵoj observas aŭ antaŭvidas altajn pograndajn merkatajn prezojn aŭ krizajn kondiĉojn de elektrosistemo, ili povas komenci eventon, kiu modifas la konduton de la programebla komunika termostato (PCT) de la kliento dum difinita tempo (ekz. 3:6 - XNUMX:XNUMX dum varmego) somera labortago) por redukti energikonsumon. -La ŝanĝo al la PCT-konduto responde al la evento povas esti simpla ŝanĝo de temperaturo-punkto por la daŭro de la evento aŭ pli kompleksa aro de ŝanĝoj, inkluzive antaŭ-malvarmigon, kiuj minimumigas la efikon de la evento sur la komforto de la kliento. nivelo.
Klienta Instigo	-Incentoj prenas du ĝeneralajn formojn. Unue klientoj rajtas ricevi senpagan komputilon aŭ doni rabatojn / rabatojn al aĉetitaj komputiloj kiel klopodo enskribiĝi en la DR-programo. Due, klientoj povas ricevi daŭran jaran stipendion por daŭra enskribo en la programon. Malpli oftaj estus daŭraj instigoj pagitaj al klientoj surbaze de reala energia redukto dum eventoj.
Imposto-Dezajno	-Ĉefe stimula programo, kie klientoj ricevas rabatitajn aŭ senpagajn komputilojn por enskribiĝi en la DR-programo. Iuj programoj povas pagi periodan stipendion aŭ stimulajn pagojn bazitajn sur redukto de energio dum eventoj.
Celata Kliento	-Reza
Celŝarĝo	- HVAC
Antaŭkondiĉo	-Tipe neniu, ĉar klientoj ricevas komputilon kiel parton de la programo-aliĝo
Programa Tempokadro	-Tipe ampleksas monatojn de la jaro, kie okazas pinta energikonsumo, kvankam eble iujare en iuj kazoj.
Eventaj Limoj	-Tipe lunde ĝis vendrede, krom festotagoj, kun sinsekvaj tagokazaĵoj tipe permesataj.
Eventaj Tagoj	-Tipe 9 ĝis 15 jare
Eventdaŭro	-Eventoj povus okazi iam ajn, kun daŭoj de 2 ĝis 4 horoj, kvankam kutime eventoj okazas dum la plej altaj energikonsumaj horoj de la tago.
Sciigo	-Tipe tagon antaŭe, kvankam iuj programoj eble havas sciigajn tempojn tiel mallongajn kiel 10 minutoj.
Opt Konduto	-Klientoj ne devas partopreni eventojn, tamen ili aŭtomate elektos eventojn krom se ili agos por anstataŭigi la eventon aŭ fari manajn alĝustigojn de temperaturo dum la evento.
Atestado Eventoj	-Tipe neniu

Karakterizaĵoj de OpenADR por Programoj pri Loĝaj Termostatoj

Eventaj Signaloj	–SIMPLA signalo kun niveloj 1 ĝis 3 mapitaj al la ŝanĝo en PCT-temperaturstarpunktokomsaĵoj aŭ termostatika biciklado procento.tage . Se loĝa termostata programo havas ununuran kompensan / biciklan komponenton ĝi devas esti mapita al nivelo 1. Por programoj kun multnombraj kompensaj / bicikladaj komponantoj, la plej malgranda ŝanĝo de normala funkciado devas esti mapita al la nivelo 1, kun la aliaj ofsaj / biciklaj valoroj. mapita al niveloj 2 kaj 3 laŭ kreskanta grado da ŝarĝo deĵetita efiko. -Se la deplojo subtenas B profile VENoj, krom la SIMPLA signalo, LOAD_CONTROL-signalo povas esti inkluzivita en la utila ŝarĝo kun speco de x-loadControlLevelOffset aŭ x-loadControlCapacity por specifi la deziratan temperaturan agordan ofseton aŭ termostatan bicikladontage respektive. Oni rekomendas, ke a unuospeco de "temperaturo" per uzata en utilaj ŝarĝoj uzante la x-loadControlLevelOffset signalType indiki Celsius aŭ Fahrenheit por la ofseto. Vidu Anekson A por ekzamples.
Elekti Respondojn	-VTN-oj sendantaj eventojn devas agordi la elementon oadrResponseRequired al "ĉiam", postulante la VEN respondi per optIn aŭ optOut – VEN-oj devas respondi per optIn krom se okazis iu specifa anstataŭiga ago farita de la kliento. -La oadrCreateOpt-utila ŝarĝo povas esti uzata de VEN-oj kvalifiki la partoprenon de rimedoj en evento. Ekzemple, evento povas celi la rimedajn IDojn de du termostatoj, kiuj regas apartajn HVAC-sistemojn. Se la kliento decidos, ke nur unu el la HVAC-sistemoj povas partopreni la eventon, ĉi tio estus komunikita al la VTN per la utila ŝarĝo de oadrCreateOpt. Notu, ke la utila ŝarĝo oadrCreateOpt estas nur subtenata de B profile VENoj
Eventa Priskribilo	-La evento prioritato estu fiksita al 1 krom se la programaj reguloj aŭ VTN-agordo specifas alie –Testokazaĵoj kutime ne estas uzataj kun programoj pri Loĝejaj Termostatoj. Tamen se ili rajtas, la elemento testEvent estu agordita al "vera" por indiki la testan eventon. Se aldonaj parametrigitaj informoj necesas en ĉi tiu elemento, ĝi povas sekvi "vera" apartigita per spaco kun ĉi tiuj aldonaj informoj.
Aktiva Aktiva Periodo	–Hazardado estas kutime uzata por loĝaj termostataj eventoj uzantaj la tolereman elementon – eiRampUp kaj eiRecovery-elementoj kutime ne estas uzataj
Bazlinioj	–Bazlinioj estas kutime ne inkluzivitaj en la evento utila ŝarĝo
Eventa Celado	-Lokaj Termostataj programoj celas HVAC-rimedojn kontrolitajn de PCToj. Celado tipe specifas la rimedajn IDojn de la HVAC-sistemoj (te la termostato) asociitaj kun VEN aŭ la venID kun la evento-signala aparata klaso celita al Termostato
Raportaj Servoj	–Telemetria raportado kutime ne estas uzata ĉar ĝi ne estas absolute necesa por programoj pri loĝaj termostatoj Vidu al Anekso B por ekzampraportoj de utilaj pilotoj, kiuj povus esti aplikeblaj al ĉi tiu speco de programo.
Elektaj Servoj	–Uzo de la Opt-servo komuniki provizorajn disponeblajn horarojn kutime ne estus uzata kadre de programo de ĈPP.
Aliĝaj Servoj	Intervokaj intervaloj petita de la VTN por tipaj tagaj programoj pri Loĝaj Termostatoj ne devas esti pli oftaj ol unufoje hore. Tamen, la uzo de voĉdonado por detektado de korbatoj eble postulos pli oftan voĉdonadon same kiel programoj pri loĝaj termostatoj kun sufiĉe pli mallongaj sciigaj tempoj.

Rapida DR-Forsendo

Karakterizaĵoj de Rapida DR-Forsenda Programo

Ŝarĝi Avantaĝonfile Objektivo	-Sendaj rimedoj por atingi ŝarĝan respondon en "realtempa"
Ĉefaj Ŝoforoj	-Reta fidindeco kaj flankaj servoj
Programo Priskribo	Rapida DR estas uzata de ISO / utilecoj por akiri antaŭfiksitan ŝarĝan respondon en "realtempa". Ĉi tiu antaŭfiksita ŝarĝa respondo estas uzata de ISO / utilecoj kiam ili observas kondiĉojn, kiuj postulas tujan agon por konservi la stabilecon kaj integrecon de la krado. Realtempa signifas, ke rimedoj estas kutime ekspeditaj kun latenteco de 10 minutoj por rimedoj uzataj kiel rezervoj ĝis 2 sekundoj por rimedoj uzataj por reguligaj celoj. La grandeco de la ŝarĝa respondo devas esti sufiĉe granda por fari diferencon en mildigado de la krada stato kaj tiel resursoj estas tipe tre grandaj kaj ofte administrataj de agregantoj kiel parto de agregita rimedo. Minimumaj grandecoj por la ŝarĝa respondo por rimedo kvalifiki partopreni flankajn servojn estas kutime ĉirkaŭ 500 kW, sed povas esti tiel malaltaj kiel 100 kW por iuj programoj. Rimarku, ke se la rimedo estas uzata kiel rezervo, ĝi estas kutime vokita malpliigi (t.e. verŝi) ŝarĝon, sed se ĝi estas uzata por reguligi celojn, ĝi povas esti sendita por pliigi aŭ malpliigi ŝarĝon.
Klienta Instigo	Agregantoj / klientoj kutime ricevas du specojn de instigoj. Unue, ili ricevas pagon por fari kaj disponigi specifan kvanton da ŝarĝa respondo havebla por DR-eventoj dum estonta tempofenestro. La kvanto de ŝarĝa respondo, la tempofenestro de havebleco kaj la pagota kvanto estas kutime fiksitaj de la agreganto / kliento. Due, se evento estas vokita dum la estonta tempofenestro pago bazita sur la kvanto de ŝarĝa respondo dum la daŭro de la evento.
Imposto-Dezajno	Partoprenantoj en la programo prezentas oferton indikante la ŝarĝan respondon, kiun ili pretigas disponigi dum estonta tempofenestro. La oferto kutime inkluzivas la pagon, kiun la agreganto / kliento pretas akcepti por la ŝarĝa respondo. En servaĵo/ISO-merkatoj la oferto estas tipe prezentita aŭ la tagon antaŭe aŭ la tagon de la tempoperiodo por kiu la engaĝiĝo estas farita. Kadre de ilia kvalifiko kaj registriĝo en la merkatoj diversaj parametroj pri agado estas rilataj al la rimedo kiel ramp imposto kaj minimumaj kaj maksimumaj operaciaj limoj. Tiaj parametroj regas kiel ĝi estos sendita. Se la oferto de partoprenanto estas akceptita, pago povas esti farita al la kliento por sia antaŭ-devontigo eĉ se ne okazas eventoj dum la tempofenestro. Se evento estas alvokita dum la tempofenestro la kliento povas ricevi aldonajn pagojn por sia agado dum la evento. Tiaj rendimentaj bazitaj pagoj povas esti bazitaj sur kelkaj faktoroj inkluzive de kvanta energio, potenco, kiom atente la rimedo sekvas la sendajn instrukciojn kaj "kilometra" pago, kiu reflektas kiom multe da ilia ŝarĝofile estis postulata ŝanĝi dum la evento. Kelkaj el tiuj parametroj kiel ekzemple energio kaj potenco povas esti kun respekto al bazlinio.
Celata Kliento	-Agregantoj kaj mem-agregitaj C&I-klientoj
Celaj Ŝarĝoj	- Tiuj, kiuj povas respondi al realtempaj sendoj.

Antaŭkondiĉo	-Kliento devas havi intervalon -Devas plenumi minimumajn grandajn postulojn por la ŝarĝa respondo -Nevas povi respondi al realtempaj sendoj -Tipe devas provizi realtempan telemetrion, kiu montras la nunan ŝarĝan respondon
Programa Tempokadro	-Kiam ajn
Eventaj Limoj	-neniu
Eventaj Tagoj	-neniu
Eventdaŭro	-Tipe mallonga (malpli ol 30 minutoj), sed ĉiukaze neniam superos la tempofenestron, kiam la partoprenanto disponigis la rimedon kiam ili prezentis sian oferton.
Sciigo	-neniu
Opt Konduto	-Klientoj defaŭlte elektas eventojn, ĉar ili havas antaŭaranĝitan ŝarĝan respondon
Atestado Eventoj	-Tipe unu jare (Testo)

Karakterizaĵoj de OpenADR por Programoj pri Kapacitaj Ofertoj

Eventaj Signaloj	–SIMPLA signalo kun niveloj 1 ĝis 3 mapita al la kvanto da ŝarĝa respondo. Se la programo nur subtenas ununuran nivelon de ŝarĝa respondo, tio estu mapita al nivelo 1. Por programoj kun multnombraj niveloj de ŝarĝa respondo, la plej malgranda ŝanĝo de normala funkciado devas esti mapita al la nivelo 1, kun la ŝarĝaj versiaj valoroj mapitaj al niveloj 2 kaj 3 en kreskanta grado de ŝarĝa respondo. -Se la deplojo subtenas B profile VENoj, aldone al la SIMPLA signalo, forsendo en la formo de LOAD_DISPATCH-signalo povas esti inkluzivita en la utila ŝarĝo kun signalaj specoj de arpunkto aŭ delto, kaj unuoj de potencoReal. Ĉi tiu signalo reprezentas la deziratan "operacian punkton" de la ŝarĝo kaj povas esti esprimita aŭ kiel absoluta kvanto de mW (t.e. arpunkto) aŭ iu relativa nombro de mW (t.e. delto) de la aktuala funkciiga punkto. Vidu Anekson A por ekzamples.
Elekti Respondojn	-VTN-oj sendantaj eventojn devas agordi la elementon oadrResponseRequired al "ĉiam", postulante la VEN respondi per optIn aŭ optOut -Kiel agregantoj / klientoj havas antaŭ-engaĝitan kapablon VEN-oj devas respondi per optIn. Malpermeso povas esti sendita kiel respondo al la evento, sed ĉi tio estas neformala indiko pri havebleco, ne formala elekto el la evento. -La oadrCreateOpt-utila ŝarĝo kutime ne estus uzata kvalifiki rimedojn partoprenantajn eventojn kiel kutime la ŝarĝo estas ununura ento.
Eventa Priskribilo	-La evento prioritato estu fiksita al 1 krom se la programaj reguloj aŭ VTN-agordo specifas alie –Testokazaĵoj povas esti uzataj, precipe dum la registrado kaj kvalifiko de rimedo. Se ili rajtas, la elemento testEvent devas esti agordita al "vera" por indiki la testan eventon. Se aldonaj parametrigitaj informoj necesas en ĉi tiu elemento, ĝi povas sekvi "vera" apartigita per spaco kun ĉi tiuj aldonaj informoj.
Aktiva Aktiva Periodo	– Toleremaj elementoj ne estas uzataj. La eiRampUp kaj eiRecovery periodoj estas tipe parto de la parametroj de rimedo kiam ili registras kaj povas esti uzataj. Pro la naturo de la forsendoj ili eble estos malfermitaj kaj tiel eble ne estos fina tempo por la evento.
Bazlinioj	–Bazlinioj estas kutime ne inkluzivitaj en la evento utila ŝarĝo ĉar ĉi tiuj datumoj kutime ne estas disponeblaj kiam la evento estas komencita. Tamen, kaj servaĵoj kaj agregantoj/klientoj farus view la inkludo de bazliniaj informoj en eventoj kiel utila.
Eventa Celado	-Kapacitaj Ofertaj programoj kutime ne diferencas inter rimedoj por donita kliento. Celado tipe specifas la venID, indikante ke ĉiuj rimedoj asociitaj kun la VEN devas partopreni, aŭ inkluzivas resourceID-reprezentanton de la entuta ŝarĝo asociita kun VEN.
Raportaj Servoj	Rapidaj DR-programoj kutime postulas TELEMETRY_USAGE-raportojn kun datumoj de powerReal. La uzada raporto prezentas la aktualan funkcian punkton de la rimedoj kaj estas uzata de la Servaĵo / ISO por determini kiom atente la rimedo sekvas la senditan instrukcion senditan. En iuj kazoj la telemetrio povas inkluzivi aliajn datumajn punktojn kiel voltage legaĵoj kaj ŝargo stato (te energio) en la kazo kie la rimedoj estas ia formo de stokado. En kelkaj kazoj la raporta frekvenco povas esti same alta kiel ĉiujn 2 sekundojn. Notu, ke telemetria raportado postulas B profile VENoj. Vidu Anekson A por ekzamples. Ankaŭ raportu al Anekso B por ekzampraportoj de utilaj pilotoj, kiuj povus esti aplikeblaj al ĉi tiu speco de programo.
Elektaj Servoj	–Uzo de la Opt-servo por komuniki provizoran haveblecon horaroj kutime ne estus uzata ĉar klientoj antaŭdecidis sian haveblecon. Tamen ĉi tiu servo povas esti utila kiel neformala maniero por partoprenantoj indiki mankon de havebleco pro mildigaj kialoj kiel fiaska ekipaĵo.
Aliĝaj Servoj	Pro la malaltaj latentaj postuloj de la realtempaj forsendoj nur puŝaj interagadaj ŝablonoj estas uzataj.

Programo pri Uzotempo (TOU) de Elektra Veturilo (EV)

Loĝaj EV TOU-Programaj Karakterizaĵoj

Ŝarĝi Avantaĝonfile Objektivo	Impostostrukturo per kiu la kosto de ŝargado de elektraj aŭtomobiloj estas modifita por igi konsumantojn ŝanĝi konsumpadronojn.
Ĉefaj Ŝoforoj	Loĝejo-energia uzo pintas vespere. Ĉar EV-ŝargado daŭras 4-8 horojn, ĝi povas prokrasti dum kelkaj horoj por ŝanĝi ŝarĝajn pintojn.
Programo Priskribo	Klientoj, kiuj havas elektran veturilon, povas aliĝi al elektra veturila tempo-uzo (EV-TOU) kaj ricevi pli malaltajn tarifojn pro ŝarĝo de sia veturilo dum malmultaj horoj, ekzemple inter noktomezo kaj 5 a.m. proponis kuraĝigi klientojn limigi tagan uzadon de elektro, kiam postulo de elektro estas plej alta.
Klienta Instigo	Malpli multekosta ŝarĝo por EV-oj.
Imposto-Dezajno	TOU kun meztaga pinto, matene kaj vespere mezpinta, kaj 12 AM-5AM kvieta
Celata Kliento	EV Posedanto kun ŝarĝa profesiulofile tio pintas vespere.
Celaj Ŝarĝoj	EV-Ŝargiloj
Antaŭkondiĉo	Kliento devas havi inteligentan mezurilon kaj EV
Programa Tempokadro	Tutjara
Eventaj Limoj	Neniu
Eventaj Tagoj	Ĉiutage, aŭ nur labortagojn
Eventdaŭro	5-8 horoj
Sciigo	Kliento estas sciigita pri prezaj niveloj de siaj monataj fakturoj, kaj VTN-oj sendas eventajn signalojn tage.
Opt Konduto	Impostpagantoj povas ŝanĝi sian tarifplanon, kiel ili kutime farus kun servilo.
Atestado Eventoj

Karakterizaĵoj de OpenADR por Programoj de Loĝejaj EV TOU

Eventaj Signaloj	ELECTRICITY_PRICE-signaloj kun realaj prezaj niveloj, same kiel SIMPLAJ signaloj por permesi partoprenon de 2.0a VENs Vidu Anekson A por ekzamples.
Elekti Respondojn	Ĉiam elektu per VEN-oj
Eventa Priskribilo	Unu evento semajne, kun eventaj intervaloj por ĉiu prezo
Aktiva Aktiva Periodo	Oni devas uzi almenaŭ 24-horan sciigon. Ĉiu evento-intervalo devas kapti la indicon de TOU
Bazlinioj	N/A
Eventa Celado	Neniu altnivela celado necesas, nur VEN-nivela celado.
Raportaj Servoj	Neniu raportado bezonas, ĉiuj datumoj povas veni de la mezurilo. Vidu al Anekso B por ekzampraportoj de utilaj pilotoj, kiuj povus esti aplikeblaj al ĉi tiu speco de programo.
Elektaj Servoj	Optaj servoj ne koncernus ĉi tiun programon.
Aliĝaj Servoj	Konsumantoj provizus sian VEN per la utilo por ricevi prezajn signalojn.

Programo pri Reala Tempo pri Publika Stacia Elektroveturilo (EV)

Karakterizaĵoj de Programo de Publika Stacio EV RTP

Ŝarĝi Avantaĝonfile Objektivo	Postula responda agado per kiu la kosto de ŝargado de elektraj veturiloj estas modifita por ŝanĝi la realaĵojn de pintoprezado al konsumantoj.
Ĉefaj Ŝoforoj	La prezo de elektro varias dum tago. Ĉi tiu programo celas pli efike egali la prezon de ŝarĝo al la kosto de elektro.
Programo Priskribo	Publikaj ŝargiloj povas ekzisti ĉe laborejoj, en publikaj parkejoj kaj ĉe podetalaj butikoj. Ĉi tiu programo elsendas realtempajn prezojn al eblaj ŝargiloj antaŭ ol ili enŝoviĝas, por ke ili povu informi decidon pri ĉu aŭ ne ŝarĝi sian aŭton.
Klienta Instigo	Malpli multekosta ŝargado dum malaltiĝaj tempoj.
Imposto-Dezajno	Prezoj povas ŝanĝiĝi hourly, sed post kiam kliento elektas enigi sian aŭton, la tarifo estas difinita por la daŭro de ŝargado.
Celata Kliento	Ĉiu kun EV, kiu devas ŝargi dum for de hejmo.
Celaj Ŝarĝoj	Publikaj EV-Ŝargiloj
Antaŭkondiĉo	EV-ŝargiloj devas esti interrete ligitaj kaj OpenADR2.0b atestitaj, aŭ konektitaj al OpenADR2.0b VEN-enirejo.
Programa Tempokadro	Tutjara
Eventaj Limoj	Neniu
Eventaj Tagoj	Ĉiutage, aŭ nur labortagojn
Eventdaŭro	1 horo aŭ pli
Sciigo	Kliento estas sciigita pri la reganta tarifo kiam li elektas enigi sian aŭton.
Opt Konduto	Klientoj povas malakcepti decidante ne ŝargi.
Atestado Eventoj

Karakterizaĵoj OpenADR por Programoj RTP de Publika Stacio EV

Eventaj Signaloj	ELECTRICITY_PRICE signaloj kun prezoj. Vidu Anekson A por ekzamples.
Elekti Respondojn	Ĉiam elektu per VEN-oj
Eventa Priskribilo	Eventoj devas esti apudaj kaj enhavi unu intervalon.
Aktiva Aktiva Periodo	Oni devas uzi almenaŭ 1 horan sciigon, tamen servaĵoj povas elekti uzi tagan antaŭan sciigon.
Bazlinioj	N/A
Eventa Celado	Neniu altnivela celado necesas, sed celado povas esti uzata por sendi prezojn al specifaj transformiloj, nutriloj aŭ geografiaj areoj.
Raportaj Servoj	Neniu raportado bezonas, sed uzeblas se oni deziras. Vidu al Anekso B por ekzampraportoj de utilaj pilotoj, kiuj povus esti aplikeblaj al ĉi tiu speco de programo.
Elektaj Servoj	Optaj servoj ne koncernus ĉi tiun programon.
Aliĝaj Servoj	Ŝarĝa stacia vendisto provizos siajn aparatojn per VTN de kompanio.

Programo pri Distribuitaj Energiaj Rimedoj (DER)

La sekva programo-priskribo estas hipoteza kaj baziĝas sur esplorartikolo (referenca artikolo de Rish) priskribanta kiel servaj klientoj povas uzi stokajn rimedojn DER por partopreni en programoj DR kiel programoj pri realtempaj prezoj (RTP).

Karakterizaĵoj de Distribuitaj Energiaj Rimedoj (DER)

Ŝarĝi Avantaĝonfile Objektivo	Postula responda agado uzata por mildigi la integriĝon de distribuitaj energiaj rimedoj en la inteligentan reton.
Ĉefaj Ŝoforoj	-Reduktitaj kapitalelspezoj kaj reduktitaj energiaj kostoj
Programo Priskribo	Klientoj kun DER-rimedoj, kiuj povas rikolti energion kaj stoki ĝin, povas minimumigi la koston de aĉeto de elektro de la reto dum altaj prezaj periodoj unue uzante stokitajn energiajn rimedojn, sekve de efektivigo de ŝarĝaj strategioj
Klienta Instigo	Kapablo regi kostojn dum altaj elektraj prezoj per ekspluatado de stokita energio generita per PV aŭ aliaj rimedoj kaj efektivigado de ŝarĝaj forĵetaj strategioj
Imposto-Dezajno	Elektraj tarifoj varias laŭ pograndaj merkataj prezoj aŭ tarifo, kiu varias laŭ la horo de la tago, sezono aŭ temperaturo
Celata Kliento	Klientoj kun energiaj stokaj rimedoj
Celaj Ŝarĝoj	Ajna
Antaŭkondiĉo	Rimedoj por konservado de energio
Programa Tempokadro	Kiam ajn
Eventaj Limoj	Neniu
Eventaj Tagoj	Ĉiutage
Eventdaŭro	24 horoj
Sciigo	Tago antaŭen
Opt Konduto	N / A - Plej bona penado
Atestado Eventoj	Neniu

Karakterizaĵoj de OpenADR por Distribuitaj Energiaj Rimedoj (DER)

Eventaj Signaloj	ELECTRICITY_PRICE-signaloj kun 24 unu horaj intervaloj de prezoj dum 24-hora periodo. Ĉi tiu signalo postulos la B-avantaĝonfile. Ĉi tiu programo ne pruntedonas sin al SIMPLA signalado por A-profesiulofile VENoj. Vidu Anekson A por ekzamples.
Elekti Respondojn	-VTN-oj sendantaj eventojn devas agordi la elementon oadrResponseRequired al "neniam", malhelpante VENojn respondi.
Eventa Priskribilo	-La evento prioritato estu fiksita al 1 krom se la programaj reguloj aŭ VTN-agordo specifas alie
Aktiva Aktiva Periodo	24 horoj kun 1 horaj intervaloj kun antaŭtaga sciigo
Bazlinioj	N/A
Eventa Celado	Neniu altnivela celado postulis alian krom la venID
Raportaj Servoj	Neniu raportado necesas Vidu al Anekso B por ekzampraportoj de utilaj pilotoj, kiuj povus esti aplikeblaj al ĉi tiu speco de programo.
Elektaj Servoj	Ne uzata
Aliĝaj Servoj	Intervokaj intervaloj petita de la VTN por tipaj taga programoj ne devas esti pli oftaj ol unufoje hore. Tamen, la uzo de voĉdonado por detektado de korbatoj eble postulos pli oftan voĉdonadon same kiel programoj pri loĝaj termostatoj kun sufiĉe pli mallongaj sciigaj tempoj.

– Sample Datumoj kaj Uzŝarĝaj Ŝablonoj

La sekvaj tabeloj kaj XML utila ŝarĝo samples provizos efektivigantojn per palpeblaj ekzampinformoj pri kiel la DR-ŝablonoj en ĉi tiu dokumento devas esti efektivigitaj. La jenaj nomspacaj prefiksoj estas uzataj en la utila ŝarĝoamples:

• 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: potenco = "http://docs.oasis-open.org/ns/emix/2011/06/power"

Kritika Pinta Preziga Programo (ĈPP)

CPP-Scenaro 1 - Simpla Uzkazo, A aŭ B Profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 1pm
  • Daŭro: 4 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 1
  • Signala Nomo: SIMPLA
    • Signala Tipo: nivelo
    • Unuoj: N / A
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 1
    • Signala Celo: N / A
  • Eventaj Celoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

ĈPP Scenaro 2 - Tipa Uzkazo, B-profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 1:XNUMX
  • Daŭro: 4 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 2
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0, 1, 2, 3
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 1 aŭ 2
    • Signala Celo: Neniu
  • Signala Nomo: ELECTRICITY_PRICE
    • Signala Tipo: prezo
    • Unuoj: USD po Kwh
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): $ 0.10 ĝis $ 1.00
    • Signala Celo: Neniu
  • Celoj pri Eventoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

ĈPP Scenaro 3 - Kompleksa Uzokazo

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 2pm
  • Daŭro: 6 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 2
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0,1, 2, 3)
    • Nombro da intervaloj 3
    • Intervalo Daŭro (j): 1 horo, 4 horoj, 1 horo
    • Tipa Intervalo-Valoro (j): 1, 2, 1 (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Signala Nomo: ELECTRICITY_PRICE
    • Signala Tipo: prezo
    • Unuoj: USD po Kwh
    • Nombro da intervaloj 3
    • Intervalo Daŭro (j): 1 horo, 4 horoj, 1 horo
    • Tipa Intervalo-Valoro (j): $ 0.50, $ 0.75, $ 0.50 (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Celoj pri Eventoj: Rimedo_1, Rimedo_2, Rimedo_3
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

CPP Sample Event Payload - Tipa B Profile Uzkazo

OadrDisReq091214_043740_513

TH_VTN

Event091214_043741_028_0

0

http: // MarketContext1

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

malproksime

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

PT4H

PT24H

PT4H

0

2.0

SIMPLA

nivelo

SIG_01

0.0

PT4H

0

0.75

ELEKTRO_PREZO

prezo

SIG_02

currencyPerKWh

Usona dolaro

neniu

0.0

venID_1234

ĉiam

Kapacita Oferta Programo (CBP)

CBP-Scenaro 1 - Simpla Uzkazo, A aŭ B Profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 1pm
  • Daŭro: 4 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 1
  • Signala Nomo: SIMPLA
    • Signala Tipo: nivelo
    • Unuoj: N / A
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 1
    • Signala Celo: N / A
  • Eventaj Celoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

CBP-Scenaro 2 - Tipa Uzkazo, B profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 1:XNUMX
  • Daŭro: 4 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 2
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0,1, 2, 3
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 1 aŭ 2
    • Signala Celo: Neniu
  • Signala Nomo: BID_LOAD
    • Signala Tipo: setpoint
    • Unuoj: powerReal
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 20kW al 100kW
    • Signala Celo: Neniu
  • Celoj pri Eventoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

CBP-Scenaro 3 - Kompleksa Uzokazo

• Evento
  • Sciigo: Tago de evento (kiom da horoj?)
  • Komenca Tempo: 1pm
  • Daŭro: 6 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 3
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0,1, 2, 3)
    • Nombro da intervaloj: 2
    • Intervalo Daŭro (j): 3 horoj, 3 horoj
    • Tipa Intervalo-Valoro (j): 1, 2 (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Signala Nomo: BID_LOAD
    • Signala Tipo: setpoint
    • Unuoj: powerReal
    • Nombro da intervaloj 2
    • Intervalo Daŭro (j): 3 horoj, 3 horoj
    • Tipa Intervalo-Valoro (j): 40kW, 80kW (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Signala Nomo: BID_PRICE
    • Signala Tipo: prezo
    • Unuoj: currencyPerKW
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 6 horoj
    • Tipa Intervalo-Valoro (j): $ 3.10
    • Signala Celo: Neniu
  • Celoj pri Eventoj: Rimedo_1, Rimedo_2, Rimedo_3
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raporto (j)
  • Raportnomo: TELEMETRY_USAGE
  • Raporta Tipo: uzado
  • Unuoj: powerReal
  • Lega Tipo: Rekta Legado
  • Raporta Ofteco: ĉiu 1 horo

CBP Sample Event Payload - Tipa B Profile Uzkazo

OadrDisReq091214_043740_513

TH_VTN

Event091214_043741_028_0

0

http: // MarketContext1

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

malproksime

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

PT4H

PT24H

PT4H

0

2.0

SIMPLA

nivelo

SIG_01

0.0

PT4H

0

80.0

BID_LOAD

setpoint

SIG_02

RealPower

W

k

60.0

<power:voltage> 220.0tage>

vera

0.0

venID_1234

ĉiam

Loĝa Termostata Programo

Loĝa Termostato Scenaro 1 - Simpla Uzkazo, A aŭ B Profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 1pm
  • Daŭro: 4 horoj
  • Hazardo: 10 minutoj
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 1
  • Signala Nomo: SIMPLA
    • Signala Tipo: nivelo
    • Unuoj: N / A
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 1
    • Signala Celo: N / A
  • Eventaj Celoj: Rimedo_1
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

Loĝdoma Termostato Scenaro 2 - Tipa Uzkazo, B profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 1:XNUMX
  • Daŭro: 4 horoj
  • Hazardo: 10 minutoj
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 2
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0,1, 2, 3
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 1 aŭ 2
    • Signala Celo: Neniu
  • Signala Nomo: LOAD_CONTROL
    • Signala Tipo: x-loadControlLevelOffset
    • Unuoj: Temperaturo
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 4 horoj
    • Tipa Intervalo-Valoro (j): 2 ĝis 6 Fahrenheit-grado
    • Signala Celo: Neniu
  • Celoj pri Eventoj: Rimedo_1, Rimedo_2
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn, Ebla OutOut (oadrCreateOpt)
• Raportoj
  • Neniu

Loĝa Termostato Scenaro 3 - Kompleksa Uzokazo

• Evento
  • Sciigo: Tago de evento
  • Komenca Tempo: 1pm
  • Daŭro: 6 horoj
  • Hazardo: 10 minutoj
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 3
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0,1, 2, 3)
    • Nombro da intervaloj: 2
    • Intervalo Daŭro (j): 3 horoj, 3 horoj
    • Tipa Intervalo-Valoro (j): 1, 2 (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Signala Nomo: BID_LOAD
    • Signala Tipo: x-loadControlCapacity
    • Unuoj: Neniu
    • Nombro da intervaloj 2
    • Intervalo Daŭro (j): 3 horoj, 3 horoj
    • Tipa Intervalo-Valoro (j): 0.9, 0.8 (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Celoj pri Eventoj: Rimedo_1, Rimedo_2, Rimedo_3
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn, Ebla OutOut (oadrCreateOpt)
• Raporto (j)
  • Neniu

Loĝa Termostato Sample Event Payload - Tipa B Profile Uzkazo

OadrDisReq091214_043740_513

TH_VTN

Event091214_043741_028_0

0

http: // MarketContext1

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

malproksime

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

PT4H

PT10M

PT24H

PT4H

0

2.0

SIMPLA

nivelo

SIG_01

0.0

PT4H

0

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

temperaturo

fahrenheit

neniu

0.0

rimedo_1

rimedo_2

ĉiam

Rapida DR-Forsendo

Rapida DR-Scenaro 1 - Simpla Uzkazo, A aŭ B Profile

• Evento
  • Sciigo: 10 minutoj
  • Komenca Tempo: 1pm
  • Daŭro: 0 (Malfermita)
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 1
  • Signala Nomo: SIMPLA
    • Signala Tipo: nivelo
    • Unuoj: N / A
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 0 (Malfermita)
    • Tipa Intervalo-Valoro (j): 1
    • Signala Celo: N / A
  • Eventaj Celoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

Rapida DR-Scenaro 2 - Tipa Uzkazo, B profile

• Evento
  • Sciigo: 10 minutoj
  • Komenca Tempo: 1:XNUMX
  • Daŭro: 30 minutoj
  • Hazardumado: Neniu
  • Ramp Supre: 5 minutoj
  • Reakiro: 5 minutoj
  • Nombro de signaloj: 2
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0,1, 2, 3
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 30 minutoj
    • Tipa Intervalo-Valoro (j): 1 aŭ 2
    • Signala Celo: Neniu
  • Signala Nomo: LOAD_DISPATCH
    • Signala Tipo: delto
    • Unuoj: powerReal
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 30 minutoj
    • Tipa Intervalo-Valoro (j): 500 kW ĝis 2mW
    • Signala Celo: Neniu
  • Celoj pri Eventoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Raportnomo: TELEMETRY_USAGE
  • Raporta Tipo: uzado
  • Unuoj: powerReal
  • Lega Tipo: Rekta Legado
  • Raporta Ofteco: ĉiu 1 minuto

Rapida DR-Scenaro 3 - Kompleksa Uzkazo

• Evento
  • Sciigo: 10 minutoj
  • Komenca Tempo: 1pm
  • Daŭro: 30 minutoj
  • Hazardumado: Neniu
  • Ramp Supre: 5 minutoj
  • Reakiro: 5 minutoj
  • Nombro de signaloj: 2
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0,1, 2, 3)
    • Nombro da intervaloj: 2
    • Intervalo Daŭro (j): 15 minutoj, 15 minutoj
    • Tipa Intervalo-Valoro (j): 1, 2 (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Signala Nomo: LOAD_DISPATCH
    • Signala Tipo: setpoint
    • Unuoj: powerReal
    • Nombro da intervaloj 2
    • Intervalo Daŭro (j): 15 minutoj, 15 minutoj
    • Tipa Intervalo-Valoro (j): 800kW, 900kW (por ĉiu intervalo respektive)
    • Signala Celo: Neniu
  • Celoj pri Eventoj: Rimedo_1
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raporto (j)
  • Raportnomo: TELEMETRY_USAGE
  • Raporta Tipo: uzado
  • Unuoj: powerReal kaj voltage
  • Lega Tipo: Rekta Legado
  • Raporta Ofteco: ĉiun 5 sekundojn

Rapida DR Sample Event Payload - Tipa B Profile Uzkazo

OadrDisReq091214_043740_513

TH_VTN

Event091214_043741_028_0

0

http: // MarketContext1

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

malproksime

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

PT10M

PT10M

<ei:x-eiRampSupren>

PT5M

</ei:x-eiRampSupren>

PT5M

PT10M

0

2.0

SIMPLA

nivelo

SIG_01

0.0

PT10M

0

500.0

LOAD_DISPATCH

delto

SIG_02

RealPower

W

k

60.0

<power:voltage> 220.0tage>

vera

0.0

venID_1234

ĉiam

Rapida DR Sample Raporta Metadatumo Utila Ŝarĝo – Tipa B Profile Uzkazo

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

rimedo1

uzado

RealEnergy

Wh

k

Rekta Legado

http: // MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

falsa

</oadr:oadrSamplingRate>

0

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

Rapida DR Sample Raporta Peto Utila Ŝarĝo - Tipa B Profile Uzkazo

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-notAplikebla

VEN130615_192312_582

Rapida DR Sample Raporto Datumoj Utila Ŝarĝo – Tipa B Profile Uzkazo

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

Kvalito Bona - Nespecifa

RP_54321

ReportReqID130615_192625_730

ReportSpecID120615_122512_481_2

TELEMETRY_USAGE

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

VEN130615_192312_582

Programo pri Uzotempo (TOU) de Elektra Veturilo (EV)

Notu, ke kiel programo komunikas tarifajn nivelojn en sufiĉe strukturita formo, estas montritaj nur la simplaj kaj tipaj uzokazoj

Loĝdoma EV-Scenaro 1 - Simpla Uzkazo, A aŭ B Profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: 1pm
  • Daŭro: 24 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 1
  • Signala Nomo: SIMPLA
    • Signala Tipo: nivelo
    • Unuoj: N / A
    • Nombro de intervaloj; egalaj TOU-nivelŝanĝoj en 24 horoj (2 - 6)
    • Intervalo Daŭro (j): TOU-nivelo aktiva tempokadro (te 6 horoj)
    • Tipa Intervalo-Valoro (j): 0 - 4 mapita al TOU-Niveloj
    • Signala Celo: N / A
  • Eventaj Celoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

Loĝdoma EV Scenaro 2 - Tipa Uzkazo, B profile

• Evento
  • Sciigo: Tagon antaŭ evento
  • Komenca Tempo: noktomezo
  • Daŭro: 24 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 2
  • Signala Nomo: Simpla
    • Signala Tipo: nivelo
    • Unuoj: Nivelo 0, 1, 2, 3
    • Nombro da intervaloj: egala TOU-niveloŝanĝo en 24 horoj (2 - 6)
    • Intervalo Daŭro (j): TOU-nivelo aktiva tempokadro (te 6 horoj)
    • Tipa Intervalo-Valoro (j): 0 - 4 mapitaj al TOU-Niveloj (0 - Plej malmultekosta Nivelo)
    • Signala Celo: Neniu
  • Signala Nomo: ELECTRICITY_PRICE
    • Signala Tipo: prezo
    • Unuoj: USD po Kwh
    • Nombro da intervaloj: egalaj TOU-nivelŝanĝoj en 24 horoj (2 - 6)
    • Intervalo Daŭro (j): TOU-nivelo aktiva tempokadro (te 6 horoj)
    • Tipa Intervalo-Valoro (j): $ 0.10 ĝis $ 1.00 (nuna nivelo)
    • Signala Celo: Neniu
  • Celoj pri Eventoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

Loĝdoma EV Sample Event Payload - Tipa B Profile Uzkazo

OadrDisReq091214_043740_513

TH_VTN

Event091214_043741_028_0

0

http: // MarketContext1

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

malproksime

<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

SIMPLA

nivelo

SIG_01

0.0

PT5H

0

0.35

PT7H

1

0.55

PT7H

2

0.75

PT5H

3

0.55

ELEKTRO_PREZO

prezo

SIG_02

currencyPerKWh

Usona dolaro

neniu

0.0

venID_1234

ĉiam

Programo pri Reala Tempo pri Publika Stacia Elektroveturilo (EV)

Notu, ke ĉar ĉi tio estas realtempa preziga programo, vere ne ekzistas diferencigo inter simpla, tipa kaj kompleksa uzokazo. Tial sampla datumoj montriĝos nur por tipa uzokazo.

Publika Stacio EV Scenaro 1 - Tipa Uzkazo, B-profesiulofile

• Evento
  • Sciigo: 1 horon antaŭe
  • Komenca Tempo: 1:XNUMX
  • Daŭro: 1 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 1
  • Signala Nomo: ELECTRICITY_PRICE
    • Signala Tipo: prezo
    • Unuoj: USD po Kwh
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 1 horoj
    • Tipa Intervalo-Valoro (j): $ 0.10 ĝis $ 1.00
    • Signala Celo: Neniu
  • Celoj pri Eventoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: ĉiam
  • VEN Atendita Respondo: optIn
• Raportoj
  • Neniu

Publika Stacio EV Sample Event Payload - Tipa B Profile Uzkazo

OadrDisReq091214_043740_513

TH_VTN

Event091214_043741_028_0

0

http: // MarketContext1

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

malproksime

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

PT1H

PT1H

PT1H

0

0.75

ELEKTRO_PREZO

prezo

SIG_01

currencyPerKWh

Usona dolaro

neniu

0.0

venID_1234

ĉiam

Programo pri Distribuitaj Energiaj Rimedoj (DER)

Notu, ke ĉar ĉi tio estas realtempa preziga programo, vere ne ekzistas diferencigo inter simpla, tipa kaj kompleksa uzokazo. Tial sampla datumoj montriĝos nur por tipa uzokazo.

Publika Stacio EV Scenaro 1 - Tipa Uzkazo, B-profesiulofile

• Evento
  • Sciigo: Antaŭa tago
  • Komenca Tempo: noktomezo
  • Daŭro: 24 horoj
  • Hazardumado: Neniu
  • Ramp Supre: Neniu
  • Reakiro: Neniu
  • Nombro de signaloj: 24
  • Signala Nomo: ELECTRICITY_PRICE
    • Signala Tipo: prezo
    • Unuoj: USD po Kwh
    • Nombro da intervaloj 1
    • Intervalo Daŭro (j): 1 horoj
    • Tipa Intervalo-Valoro (j): $ 0.10 ĝis $ 1.00
    • Signala Celo: Neniu
  • Celoj pri Eventoj: venID_1234
  • Prioritato: 1
  • Respondo VEN Bezonata: neniam
  • VEN Atendita Respondo: n / a
• Raportoj
  • Neniu

Publika Stacio EV Sample Event Payload - Tipa B Profile Uzkazo

OadrDisReq091214_043740_513

TH_VTN

Event091214_043741_028_0

0

http: // MarketContext1

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

malproksime

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

PT24H

PT24H

PT1H

0

0.75

PT1H

1

0.80

ELEKTRO_PREZO

prezo

SIG_01

currencyPerKWh

Usona dolaro

neniu

0.0

venID_1234

neniam

– Ekzample Raportoj De Utilaj Pilotoj

OpenADR Alliance-membroj disponigis la sekvan B Profile oadrUpdateReport utila ŝarĝoampde programoj pri utilaj pilotoj, kie iliaj VEN-oj estis deplojitaj. La sekvaj notoj akompanis la tri utilajn ŝarĝojnampprovizitaj:

Termostato Utila Ŝarĝo:

• Necesas scii la staton de la termostato (temp, agordoj, ventolilo kaj reĝimaj statoj)
• Se elektita, ĉu la kliento ŝanĝis aŭ ne la agordojn de termostato (manaj anstataŭigaj mesaĝoj)

M&V por Rabatoj Utila Ŝarĝo Celo:

• Stato de rimedoj kaj mana anstataŭigo en la kazo de elekto
• Intervalaj datumoj de KYZ-Pulsa Nombrilo aŭ Energia Monilo por totala energio en KWH kaj tuja postulo en KW

Inteligenta Mezurilo / AMI-Intervala Datuma Utila Ŝarĝo:

• Intervalo de legado de mezurilo AMI estas ĉirkaŭ 15 minutoj ĝis 1 horo. Kvankam utila, ne sufiĉe grajneca por preskaŭ realtempaj fakturaj taksoj
• Tuta Energio en KWH, delta energio en KWH, tuja postulo en KW

La jenaj nomspacaj prefiksoj estas uzataj en la utila ŝarĝoamples:

• 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: potenco = "http://docs.oasis-open.org/ns/emix/2011/06/power"

Termostata Raporto Utila Ŝarĝoample

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

Statuso

vera

falsa

0

Neniu Nova Valoro - Antaŭa Valoro Uzata

Nuna Temp

77.000000

Neniu Nova Valoro - Antaŭa Valoro Uzata

Varma Temp-Agordo

64.000000

Neniu Nova Valoro - Antaŭa Valoro Uzata

Malvarmeta Tempa Agordo

86.000000

Neniu Nova Valoro - Antaŭa Valoro Uzata

Agordo pri reĝimo HVAC

3

Neniu Nova Valoro - Antaŭa Valoro Uzata

Nuna reĝimo HVAC

0.000000

Sen Kvalito - Sen Valoro

Fana Moda Agordo

2

Neniu Nova Valoro - Antaŭa Valoro Uzata

Nuna Tena Reĝimo

2

Neniu Nova Valoro - Antaŭa Valoro Uzata

Nuna For-reĝimo

0

Neniu Nova Valoro - Antaŭa Valoro Uzata

Nuna Humideco

0.000000

Sen Kvalito - Sen Valoro

RP21

REQ: Rekv: 1395368583267

0013A20040980FAE

TELEMETRY_STATUS

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

VEN.ID:1395090780716

M & Vpor Rabatoj Raportas Utilan Ŝarĝonample

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

Statuso

vera

falsa

Kvalito Bona - Nespecifa

Pulsa Kalkulo

34750.000000

Kvalito Bona - Nespecifa

Energio

33985.500000

Kvalito Bona - Nespecifa

Potenco

1.26

Kvalito Bona - Nespecifa

RP15

REQ: Rekv: 10453335019195698

0000000000522613 60

TELEMETRY_USAGE

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

VEN.ID:1439831430142

Smart Meter / AMI-Intervala Datuma Raporto Utila Ŝarĝoample

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

tuja Postulo

6.167000

Neniu Nova Valoro - Antaŭa Valoro Uzata

intervalDataDelivered

0.051000

Neniu Nova Valoro - Antaŭa Valoro Uzata

currSumDelivered

12172.052000

Neniu Nova Valoro - Antaŭa Valoro Uzata

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

PT15S

tuja Postulo

6.114000

Neniu Nova Valoro - Antaŭa Valoro Uzata

intervalDataDelivered

0.051000

Neniu Nova Valoro - Antaŭa Valoro Uzata

currSumDelivered

12172.052000

Neniu Nova Valoro - Antaŭa Valoro Uzata

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

PT15S

tuja Postulo

6.113000

Neniu Nova Valoro - Antaŭa Valoro Uzata

intervalDataDelivered

0.051000

Neniu Nova Valoro - Antaŭa Valoro Uzata

currSumDelivered

12172.142000

Neniu Nova Valoro - Antaŭa Valoro Uzata

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

PT15S

tuja Postulo

6.112000

Neniu Nova Valoro - Antaŭa Valoro Uzata

intervalDataDelivered

0.051000

Neniu Nova Valoro - Antaŭa Valoro Uzata

currSumDelivered

12172.142000

Neniu Nova Valoro - Antaŭa Valoro Uzata

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>

- Servoj

Open ADR subtenas jenajn servojn:

• EiEventa Servo - Uzata de VTN por sendi respondajn eventojn al VEN, kaj uzata de VEN por indiki ĉu rimedoj partoprenos la eventon. La sola servo subtenata de la A-profesiulofile estas EiEvent
• EiReport-Servo - Uzata de VEN kaj VTN por interŝanĝi historiajn, telemetriajn kaj prognozajn raportojn
• EiOpt-Servo - Uzata de VEN por komuniki provizoran horaron de disponebleco al VTN-oj aŭ kvalifiki la rimedojn partoprenantajn en evento
• EiRegisterParty Servo - Iniciatita de VEN, kaj uzata de VEN kaj VTN por interŝanĝi informojn necesajn por certigi interoperacieblan interŝanĝon de utilaj ŝarĝoj.
• Servo OadrPoll - Uzata de VEN por enketi la VTN pri utilaj ŝarĝoj de iuj el la aliaj servoj

A kaj B profile servaj operacioj estas difinitaj per la radika elemento de ĉiu utila ŝarĝo, ekskluzive de la envolvaĵoj oadrPayload kaj oadrSignedObject uzataj sur ĉiuj B profile utilaj ŝarĝoj.

- Difinoj de Utila Ŝarĝo

EiEventaj Utilaj Ŝarĝoj

• oadrPetoEvento - Uzata en modelo de interŝanĝa tirado de VEN por retrovi ĉiujn koncernajn eventojn de la VTN. Uzata kiel la ĉefa voĉdona mekanismo por A-profesiulofile VEN-oj, sed nur uzataj ĉe B-VEN-oj por sinkronigado kun la VTN.
• oadrDistributeEvent - Uzita de la VTN por liveri postulajn respondajn eventojn al la VEN
• oadrCreatedEvent - Uzata de la VEN por komuniki ĉu ĝi intencas partopreni eventon elektante en aŭ eksteren
• oadrResponse - Uzata de la VTN por agnoski la ricevon de la optIn aŭ optOut de la VEN

EiReport Utilaj Ŝarĝoj

Rimarku, ke ambaŭ VEN-oj kaj VTN-oj kapablas esti kaj raporta produktanto kaj raporta petanto, do ĉiuj utilaj ŝarĝoj sube povas esti iniciatitaj de ambaŭ partioj.

• oadrRegister Report - Uzita por publikigi siajn raportajn kapablojn en raporto pri metadatenoj
• oadrRegistrita Raporto - Agnoski la ricevon de oadrRegisterReport, laŭvole peti unu el la proponitaj raportoj
• oadrKrei Raporton - Uzata por peti raporton, kiun antaŭe ofertis VEN aŭ VTN
• oadrKreita Raporto - Agnoski ricevon de raporta peto
• oadrĜisdatigi Raporton -Liveri petitan raporton enhavantan intervalajn datumojn
• oadrĜisdatigita Raporto - Agnoski ricevon de liverita raporto
• oadrCancel Report - Nuligi antaŭe petitan periodan raporton
• oadrNuligita Raporto - Agnoski periodan nuligon de raporto
• oadrResponse - Uzata kiel lokokupila respondo en iuj tiraj interŝanĝaj ŝablonoj kiam aplika tavolo-respondo estas liverita en transporta tavolo-peto.

EiOpt Utilaj Ŝarĝoj

• oadrCreateOpt - Uzata por du klare malsamaj celoj
  • Por ke VEN komuniku provizoran horaron pri havebleco al VTN pri ĝia kapablo partopreni DR-eventojn
  • Por ke la VEN kvalifiku la rimedojn partoprenantajn en evento
• oadrCreatedOpt - Agnoski la ricevon de la utila ŝarĝo de oadrCreateOpt
• oadrCancelOpt -Nuligu provizoran horaran disponeblon
• oadrCanceledOpt - Agnoski provizoran nuligan raporton pri havebleco

 

EiRegisterParty Utilaj Ŝarĝoj

• oadrQueryRegistration - Maniero por la VEN pridemandi la registrajn informojn de VTNs sen efektive registriĝi.
• oadrCreatePartyRegistration - Peto de la VEN al la VTN registriĝi. Enhavas informojn pri la VEN-kapabloj.
• oadrCreatedPartyRegistration - Respondo al aŭ oadrQueryRegistration aŭ oadrCreatePartyRegistration. Enhavas VTN-kapablojn kaj registrajn informojn necesajn por ke la VEN interagadu
• oadrCancelPartyRegistration - Uzata de VEN aŭ VTN por nuligi registriĝon
• oadrCanceledPartyRegistration - Respondo al OadrCancelPartyRegistration. Agnoskas ricevon de la registra nuligo
• oadrRequestReregistration - Ĉi tiu utila ŝarĝo estas uzata de VTN en modelo de interŝanĝo por signalo al la VEN por rekomenci la registran sinsekvon
• oadrResponse - Uzata kiel lokokupila respondo en iuj tiraj interŝanĝaj ŝablonoj kiam aplika tavolo-respondo estas liverita en transporta tavolo-peto.

OadrPoll Utilaj Ŝarĝoj

• oadrPoll – Ĝenerala polingmekanismo por la B-profile kiu redonas utilan ŝarĝon por iu ajn nova servo aŭ ĝisdatigita.
• oadrResponse - Uzita por indiki, ke ne ekzistas novaj aŭ ĝisdatigitaj utilaj ŝarĝoj

- Terminaro de Schema Utila Ŝarĝo-Elementoj

La sekva estas alfabeta listo de skemaj elementoj uzataj en utilaj ŝarĝoj de OpenADR 2.0. La rakonto priskribas ilian uzadon kiel ĝi rilatas al OpenADR kaj ilia uzo en utilaj ŝarĝoj. Kiam elemento-difino ŝanĝiĝas surbaze de la utila ŝarĝo en kiu ĝi estas enhavita aŭ ĝia uzokonteksto, tio estos notita en la rakonto. Radikaj utilŝarĝaj difinoj estis ekskluditaj kiel la difinitaj en Anekso C.

• ac - Bulea valoro indikanta ĉu la elektra produkto estas alterna kurento
• precizeco - Nombro estas en samaj unuoj kiel la utilŝarĝa variablo por Intervalo. Kiam ĉeestas kun Fido, indikas la verŝajnan ŝanĝeblecon de la antaŭdiro. Kiam ĉeestas kun ReadingType, indikas verŝajnan eraron de Reading.
• aggregatedPnode - Agregita preznodo estas speciala speco de preziganta nodo uzata por modeligi erojn kiel Sistemo-Zono, Defaŭlta Preza Zono, Propra Preza Zono, Kontrola Areo, Agregacia Generacio, Agregita Partoprenanta Ŝarĝo, Agregita Ne-Partoprenanta Ŝarĝo, Komerca Nabo, DCA-Zono
• disponebla - Objekto enhavanta datan tempon kaj daŭron por disponebla horaro de EiOpt
• bazlinia ID - Unika identigilo por specifa bazlinio
• bazlinia nomo - Priskriba nomo por bazlinio
• komponantoj –
• konfido - Statistika probablo, ke raportita datuma punkto estas ĝusta
• createdDateTime - La datoTempo kiam la utila ŝarĝo estis kreita
• valuto –
• moneroPerKW –
• valutoPerKWh –
• valutoPerThm –
• aktuala –
• aktualaValoro - La valoro payloadFloat de la evento-intervalo nuntempe plenumanta.
• customUnit - Uzata por difini laŭmezuran mezurunuon por laŭmendaj raportoj
• dato-tempo –
• dtstart - La komenca tempo por la agado, datumoj aŭ ŝtatŝanĝo
• daŭro - Tempodaŭro por evento, raportado aŭ disponebla tempintervalo
• daŭro - La daŭro de la agado, datumoj aŭ stato
• eiActivePeriod - Tempokadroj rilataj al la ĝenerala evento
• eiCreatedEvent - Respondu DR-Eventon per optIn aŭ optOut
• eiEvento -Objekto enhavanta ĉiujn informojn por unu evento
• eiEventBaseline - B profile
• eiEventSignal - Objekto enhavanta ĉiujn informojn por sola signalo en evento
• eiEventSignals - Intervalaj datumoj por unu aŭ pluraj eventaj signaloj kaj / aŭ bazlinioj
• eiMarketContext - URI unike identiganta programon pri postulo
• eiReportID - Referenca ID por raporto
• eiRequestEvent - Petu Eventon de VTN en tir-reĝimo
• eiResponse - Indiku ĉu ricevita utila ŝarĝo estas akceptebla
• eiTarget - Identigas la rimedojn asociitajn kun la logika VEN-interfaco. Por eventoj, la specifaj valoroj estas la celo por la evento
• endDeviceAsset - La EndDeviceAssets estas la fizika aŭ aparatoj, kiuj povus esti mezuriloj aŭ aliaj specoj de aparatoj, kiuj povus interesi
• energyApparent - Ŝajna Energio, mezurita en volt-ampantaŭ horoj (VAh)
• energioItem –
• energioReaktiva - Reaktiva Energio, volt-ampestas reaktivaj horoj (VARh)
• energyReal - Reala Energio, Vattaj Horoj (Wh)
• eventDescriptor - Informoj pri la evento
• ID-evento - ID-valoro, kiu identigas specifan DR-okazaĵon.
• eventResponse - Objekto enhavanta VEN-respondon al peto partopreni eventon
• eventResponses - optIn aŭ optOut-respondoj por ricevitaj eventoj
• EventStatus - La aktuala stato de evento (malproksima, proksima, aktiva, ktp)
• FeatureCollection / location / Plurangulo / ekstera / LinearRing
• frekvenco –
• granulareco – Jen la tempointervalo inter sampgvidis datumojn en raportpeto.
• groupID -Ĉi tiu speco de celo estas uzata por eventoj, raportoj kaj elektaj horaroj. La valoro kutime estus asignita de la programo dum enskribo en DR-programo
• grupoNomo - Ĉi tiu speco de celo estas uzata por eventoj, raportoj kaj elektaj horaroj. La valoro kutime estus asignita de la programo dum enskribo en DR-programo
• herco –
• intervalo - Objekto enhavanta datuman tempon kaj / aŭ daŭron, kaj prilaboreblan valoron en kazo de evento aŭ datumoj en kazo de raporto
• intervaloj - Unu aŭ pluraj tempintervaloj dum kiuj la DR-evento estas aktiva aŭ raportaj datumoj disponeblas
• ero Priskribo - Priskribo de raporta mezurunuo
• itemUnits - La baza mezurunuo por raporta datuma punkto
• marketContext - URI identiganta DR-Programon
• metroAsset - La MeterAsset estas la fizika aŭ aparatoj, kiuj plenumas la rolon de la metro
• modificationDateTime - Kiam evento estas modifita
• modifnombro - Pliigita ĉiufoje kiam evento estas modifita.
• modifoKialo - Kial evento estis modifita
• mrid - La mRID identigas la fizikan aparaton, kiu povas esti CustomerMeter aŭ aliaj specoj de EndDevices.
• nodo - La Nodo estas loko, kie io ŝanĝiĝas (ofte posedas) aŭ konektas sur la krado. Multaj nodoj estas asociitaj kun metroj, sed ne ĉiuj.
• numDataSources –
• oadrCapacity –
• oadrNuna –
• oadrDataQuality –
• oadrDeviceClass - Celo de Aparato-Klaso - uzu nur endDeviceAsset.
• oadrEvent - Objekto enhavanta postulrespondan eventon
• oadrExtension –
• oadrExtensionName -
• oadrExtensions –
• oadrHttpPullModel - Bulea indikanta ĉu la VEN volas uzi tiran interŝanĝan modelon
• oadrInfo - Kerna valora paro de servaj specifaj registraj informoj
• oadrKey –
• oadrLevelOffset –
• oadrLoadControlState –
• oadrManualOverride - Se vere, la kontrolo de la ŝarĝo estis permane anstataŭigita
• oadrMax –
• oadrMaxPeriod - Maksimuma sampling periodo
• oadrMin –
• oadrMinPeriod - Minimuma sampling periodo
• oadrNormala –
• oadrOnChange - Se vere, la datumoj estos registritaj kiam ili ŝanĝiĝos, sed je pli granda ofteco ol tiu specifita de minPeriod.
• oadrRete - Se vera tiam rimedo / valoraĵo estas enreta, se falsa tiam eksterrete.
• oadrPayload –
• oadrPayloadResourceStatus - Aktualaj statoj pri rimedoj
• oadrPendingReports - Listo de periodaj raportoj ankoraŭ aktiva
• oadrProcentOffset –
• oadrProfile – porfile subtenata de VEN aŭ VTN
• oadrProfileNomo - OpenADR profile nomo kiel 2.0a aŭ 2.0b.
• oadrProfiles – OpenADR profiles subtenata de la efektivigo
• oadrRaporto -Objekto enhavanta ĉiujn informojn por sola raporto
• oadrRaportPriskribo - Priskribo de la raportaj trajtoj ofertitaj de la raporta produktanto. Enhavita en raporto pri metadatenoj
• oadrReportOnly - ReportOnlyDeviceFlag
• oadrReportPayload - Datumaj valoroj por raportoj
• oadrRequestedOadrPollFreq - La VEN sendos pagon de oadrPoll al la VTN maksimume unufoje por ĉiu daŭro specifita de ĉi tiu elemento
• oadrResponseRequired - Kontroloj kiam optIn / optOut-respondo necesas. Povas esti ĉiam aŭ neniam
• oadrSamplingRate - Sampling-indico por telemetriaj tipo-datenoj
• oadrServo –
• oadrServiceName - Ĉi tiu speco de celo estas uzata por eventoj, raportoj kaj elektaj horaroj. La valoro kutime estus asignita de la programo dum enskribo en DR-programo
• oadrServiceSpecificInfo - Servaj specifaj registraj informoj
• oadrSetPoint –
• oadrSignedObject –
• oadrTransport - Transporta nomo subtenata de VEN aŭ VTN
• oadrTransportAddress - Radika adreso uzata por komuniki kun alia partio. Enmetu havenon se necese
• oadrTransportName - OpenADR-transporta nomo kiel simpleHttp aŭ xmpp
• oadrTransports - OpenADR-transportoj subtenataj de efektivigo
• oadrUpdatedReport - Agnoski ricevon de raporto
• oadrUpdateReport - Sendu antaŭe petitan raporton
• oadrValue –
• oadrVenName - VEN-nomo. Povas esti uzata en VTN-GUI
• oadrXmlSignature - Efektivigo subtenas XML-subskribon
• optID - Identigilo por elekta interago
• optReason - Nomumita valoro pro la elekta kialo kiel x-horaro
• optType - optIn aŭ optOut de evento, aŭ uzata por indiki la tipon de opt-horaro difinita en la disponebla objekto por la servo EiOpt
• partioID - Ĉi tiu speco de celo estas uzata por eventoj, raportoj kaj elektaj horaroj. La valoro kutime estus asignita de la programo dum enskribo en DR-programo
• utila ŝarĝo Flosilo - Datuma punkta valoro por eventaj signaloj aŭ por raporti aktualajn aŭ historiajn valorojn.
• pnodo - Preznodo estas rekte asociita kun konektebla nodo. Ĝi estas preziga loko, por kiu merkataj partoprenantoj submetas siajn ofertojn, ofertas, aĉetas / vendas CRR-ojn kaj ekloĝas.
• PointOfDelivery –
• punktoDeKvitanco –
• posListo –
• powerApparent - Ŝajna potenco mezurita en volt-amperes (VA)
• potencoAtributoj
• potencoItem
• powerReactive - Reaktiva potenco, mezurita en volt-ampestas reakcia (VAR)
• powerReal - Reala potenco mezurita en Vatoj (W) aŭ lesuloj / sekundo (J / s)
• prioritato - La prioritato de la evento rilate al aliaj eventoj (Ju pli malalta estas la nombro pli alta ol prioritato. Valoro de nulo (0) indikas neniun prioritaton, kiu estas la plej malalta prioritato defaŭlte).
• propraĵoj –
• pulsokalkulo - Raporta datuma punkto
• pulsfaktoro - kWh po kalkulo
• kvalifikitaEventID - Unika identigilo por evento
• legantaTipo - Metadatenoj pri la Legaĵoj, kiel ekzemple meznombro aŭ derivita
• registriĝa ID - Identigilo por Registrada transakcio. Ne inkluzivita kiel respondo al petregistro krom se jam registrita
• respondiLimit - La maksimuma nombro de eventoj revenindaj en utila ŝarĝo de oadrDistributeEvent
• raportoDorsaTempo - Raporti kun la Ĝisdata Raporto por ĉiu pasado de ĉi tiu Daŭro.
• reportDataSource - Fontoj por datumoj en ĉi tiu raporto. Ekzampili inkluzivas metrojn aŭ submetrojn. Ekzample, se metro kapablas provizi du malsamajn specojn de mezuroj, tiam ĉiu mezura fluo estus aparte identigita.
• reportInterval - Ĉi tiu estas la ĝenerala periodo de raportado.
• raportnomo - Laŭvola nomo por raporto.
• reportRequestID - Identigilo por aparta raporta peto
• reportSpecifier - Specifi datumajn punktojn deziratajn en aparta raporta kazo
• reportSpecifierID - Identigilo por specifa specifa raporto pri Metadatenoj
• reportSubject - Celo de Aparato-Klaso - uzu nur endDeviceAsset.
• raportiSekvi - Indikas ĉu raporto (en la formo de UpdateReport) resendota post nuligo de Raporto
• raportaTipo - La speco de raporto kiel uzado aŭ prezo
• petoID - ID uzata por kongrui kun logika transakcia peto kaj respondo
• rimedoID - Ĉi tiu speco de celo estas uzata por eventoj, raportoj kaj elektaj horaroj. La valoro kutime estus asignita de la programo dum enskribo en DR-programo
• respondo –
• respondoKodo - 3-cifera respondkodo
• respondo Priskribo - Rakonta priskribo de responda stato
• respondojn –
• senigi - ReferenceID por ĉi tiu datuma punkto
• servoAreo - Ĉi tiu speco de celo estas uzata por eventoj, raportoj kaj elektaj horaroj. La valoro kutime estus asignita de la programo dum enskribo en DR-programo
• serviceDeliveryPoint - Logika punkto en la reto, kie la posedo de la servo ŝanĝiĝas. Ĝi estas unu el eble multaj servpunktoj ene de ServiceLocation, liverante servon laŭ Klienta Interkonsento. Uzata ĉe la loko, kie metro povas esti instalita.
• serviceLocation - Klienta ServiceLocation havas unu aŭ pli ServiceDeliveryPoint (s), kiuj siavice rilatas al Metroj. La loko povas esti punkto aŭ plurlatero, depende de la specifaj cirkonstancoj. Por distribuo, la ServiceLocation estas tipe la loko de la premiso de la serva kliento.
• signalID - unika Identigilo por specifa evento-signalo
• signalName - La nomo de signalo kiel SIMPLA
• signalPayload - Signalaj valoroj por eventoj kaj bazlinioj
• siScaleCode - Granda faktoro por la baza mezurunuo por raporto
• specifierPayload - Malferma
• komenci post - Hazarda fenestro por komenco de evento
• statusDatoTempo - Dato kaj horo, kiujn ĉi tiu artefakto aludas.
• temperaturo –
• testEvento - Ĉio krom falsa indikas testan eventon
• teksto –
• Therm –
• toleremo - Subobjekto enhavanta la randomigajn postulojn por evento
• toleri - Objekto enhavanta la randomigajn postulojn por evento
• transportInterfaco - La Transporta Interfaco konturas la randojn ĉe ambaŭ finoj de transporta segmento.
• uid - Uzata kiel indekso por identigi intervalojn. Unika Identigilo
• valoro –
• disponebleco - Horaro reflektanta aparatan haveblecon por partoprenado en DR-eventoj
• venID - Unika identigilo por VEN
• voltage –
• vtnComment - Ajna teksto
• vtnID - Unika identigilo por VTN
• x-eiNotigo - La VEN devas ricevi la DR-eventan utilan ŝarĝon antaŭ dtstart malpli tiu daŭro.
• x-eiRampSupre - Daŭro antaŭ aŭ post la okazaĵa komenca tempo dum kiu ŝarĝoŝipo devas transiri.
• x-eiReakiro - Daŭro antaŭ aŭ post la fina tempo, dum kiu ŝarĝoŝipo devas transiri.

 

Terminaro de Nombritaj Valoroj

EventStatus

• aktiva - La evento estis komencita kaj nuntempe aktiva.
• nuligita - La evento estis nuligita.
• kompletigita - La evento finiĝis.
• malproksime - Eventa atendo en la fora estonteco. La ĝusta difino de kiom malproksime en la estonteco ĉi tio raportas dependas de la merkata kunteksto, sed kutime signifas la sekvan tagon.
• proksime – Okazaĵo pritraktata baldaŭ. La preciza difino de kiom proksima en la estonteco la pritraktata evento estas aktiva dependas de la merkata kunteksto. .Komenciĝas samtempe kun efektiva komenco de la evento x-eiRampSupre tempo. Se x-eiRampSupre ne estas difinita por la evento, ĉi tiu stato ne estos uzata por la evento.
• neniu - Neniu evento pritraktata

itemUnuoj

• Monero
  • USD - Usonaj Dolaroj
  • Al multaj listigitaj ĉi tie, raportu al skemo
• potencoReala
  • J/s - leulo-sekundo
  • W - Vatoj
• temperaturo
  • celsius –
  • Fahrenheit –

oadrDataQuality

• Neniu Nova Valoro - Antaŭa Valoro Uzata –
• Sen Kvalito - Sen Valoro –
• Kvalito Malbona - Komuna Fiasko –
• Kvalito Malbona - Agorda Eraro –
• Kvalito Malbona - Fiasko de Aparato –
• Kvalito Malbona - Lasta Konata Valoro –
• Kvalito Malbona - Nespecifa –
• Kvalito Malbona - Ne Ligita –
• Kvalita Malbono - El servo –
• Kvalito Malbona - Sensila Fiasko –
• Kvalito Bona - Loka Anulaĵo –
• Kvalito Bona - Nespecifa –
• Kvalita Limo - Kampo / Konstanto –
• Kvalita Limo - Kampa / Alta –
• Kvalita Limo - Kampa / Malalta –
• Kvalita Limo - Kampo / Ne –
• Kvalito Necerta - EU-Unuoj Superis –
• Kvalito Necerta - Lasta Uzebla Valoro –
• Kvalito Necerta - Nespecifa –
• Kvalito Necerta - Sensilo Ne Preciza –
• Kvalito Necerta - Sub Normala –

oadrResponseRequired

• ĉiam - Ĉiam sendu respondon por ĉiu ricevita evento.
• neniam - Neniam respondu.

optReason

Nomumitaj kialoj por elekti.

• ekonomia –
• krizo –
• devas Kuri –
• nePartoprenanta –
• outageRunStatus –
• overrideStatus –
• partoprenante –
• x-horaro –

oadrTransportName

• simplaHttp –
• xmpp –

OptType

• elektIn - Indiko, ke VEN partoprenos eventon, aŭ en la kazo de la servo EiOpt, speco de horaro indikanta, ke rimedo estos disponebla
• elekti eksteren - Indiko, ke VEN ne partoprenos eventon, aŭ en la kazo de la servo EiOpt, speco de horaro indikanta, ke rimedo ne disponeblos

legantaTipo

• Asignita - Metro kovras plurajn [rimedojn] kaj uzado estas konkludita per ia pro-komputila datumo.
• Kontrakto - Indikas, ke legado estas proforma, te raportita laŭ interkonsentitaj tarifoj
• Derivita - Uzado konkludas per scio pri rultempa, normala funkciado, ktp.
• Rekta Legado - Legado estas legata de aparato, kiu kreskas monotone, kaj uzado devas esti komputita de paroj de komencaj kaj haltaj legadoj.
• Taksita - Uzata kiam legado forestas en serio, en kiu ĉeestas plej multaj legaĵoj.
• Hibrido - Se entute, rilatas al malsamaj legospecoj en la entuta nombro.
• Mean - Legado estas la averaĝa valoro dum la periodo indikita en Granularity
• Reto - Mezurilo aŭ [rimedo] preparas sian propran kalkulon de totala uzo tra la tempo.
• Pinto - Legado estas Pinta (plej alta) valoro dum la periodo indikita en detalo. Por iuj mezuroj, ĝi povas havi pli sencon kiel la plej malalta valoro. Eble ne kongruas kun entutaj legaĵoj. Validas nur por flukvantaj erobazoj, t.e. Potenco ne Energio.
• Projektita - Indikas, ke legado estas en la estonteco, kaj ankoraŭ ne mezuris.
• Resumita - Pluraj metroj kune donas la legadon por ĉi tiu [rimedo]. Ĉi tio estas specife malsama ol agregita, kiu rilatas al pluraj [rimedoj] en la sama utila ŝarĝo. Vidu ankaŭ Hibridon.
• x-notAplikebla - Ne aplikebla
• x-RMS - Radika Mezkvadrato

raportnomo

• HISTORIO_GREENBUTTON - Raporto enhavanta verdbutonajn datumojn en strukturo de atoma fluo
• HISTORIO_UZO - Raporto enhavanta historikajn energi-uzajn datumojn
• METADATA_HISTORY_GREENBUTTON - Raporto pri metadatenoj difinanta la raportajn kapablojn por raportoj HISTORY_GREENBUTTON
• METADATA_HISTORY_USAGE - Raporto pri metadatenoj difinanta la raportajn kapablojn por raportoj HISTORY_USAGE
• METADATA_TELEMETRY_STATUS - Raporto pri metadatenoj difinanta la raportajn kapablojn por TELEMETRY_STATUS-raportoj
• METADATA_TELEMETRY_USAGE - Raporto pri metadatenoj difinanta la raportajn kapablojn por TELEMETRY_USAGE-raportoj
• TELEMETRY_STATUS - Raporto enhavanta realtempajn informojn pri rimedoj kiel interreta stato
• TELEMETRY_USAGE - Raporto enhavanta informojn pri realtempa energio-uzado

raportaTipo

Nomumita valoro, kiu donas la specon de raporto donata.

• disponeblaEnergia Stokado - Kapablo disponebla por plua konservado de energio, eble por atingi Celan Energian Stokadon
• avgDemand - Meza uzado dum la daŭro indikita de la Granularity. Vidu postulon pri pli da informoj.
• mezumo Uzado - Meza uzado dum la daŭro indikita de la Granularity. Vidu uzadon por pliaj informoj.
• bazlinio - Povas esti postulo aŭ uzado, kiel indikas ItemBase. Indikas kio [mezurado] estus se ne por la evento aŭ regularo. Raporto havas la formaton Baseline.
• deltaDemand - Ŝanĝo de postulo kompare kun la baza linio. Vidu postulon pri pli da informoj
• deltaSetPoint - Ŝanĝoj de aro de antaŭa horaro.
• deltaUzado - Ŝanĝo de uzado kompare kun la baza linio. Vidu uzadon por pliaj informoj
• postulo - Raporto indikas kvanton de unuoj (nomitaj en ItemBase aŭ en la Produkto EMIX). Utila ŝarĝo estas Kvanto. Tipa ItemBase estas Reala Potenco.
• devio - Diferenco inter iu instrukcio kaj reala stato.
• downRegulationCapacityAvailable - Malsupren Regula kapablo disponebla por sendado, esprimita en EMIX Reala Potenco. Utila ŝarĝo ĉiam esprimiĝas kiel pozitiva Kvanto.
• nivelo - Simpla nivelo de merkato ĉe ĉiu Intervalo.
• operacianta ŝtato - Ĝeneraligita stato de rimedo kiel enŝalti / malŝalti, konstruado, ktp. Neniu ItemBase gravas. Postulas Aplikan Specifan Utilan Ŝarĝan Etendaĵon.
• procentoPostulo - Percentage de postulo
• procentoUzo - Percentage de uzado
• potencoFaktoro - Potenca faktoro por la rimedo
• prezo - Prezo po ItemBase ĉe ĉiu Intervalo
• legado - Raporto indikas legadon, kiel de metro. Legadoj estas momentoj en tempaj ŝanĝoj kun la tempo, povas esti kalkulitaj de la diferenco inter sinsekvaj legadoj. Utila ŝarĝa tipo estas flosilo
• reguligoSetpoint - Regula starpunkto laŭ instrukcio kiel parto de reguligaj servoj
• starpunkto - Raporto indikas la sumon (nomatan en ItemBase aŭ en la EMIX-Produkto) aktuale agorditan. Povas esti konfirmo / reveno de la kontrolpunkta valoro sendita de la VTN. Utila ŝarĝo estas Kvanto. Tipa ItemBase estas Reala Potenco.
• konservitaEnergio - Stokita Energio estas esprimita kiel Reala Energio kaj Utila Ŝarĝo estas esprimita kiel Kvanto.
• targetEnergyStorage - Cela Energio estas esprimita kiel Reala Energio kaj Utila Ŝarĝo estas esprimita kiel Kvanto.
• upRegulationCapacityAvailable - Supren Regula kapablo disponebla por sendado, esprimita en EMIX Reala Potenco. Utila ŝarĝo ĉiam esprimiĝas kiel pozitiva Kvanto.
• uzado - Raporto indikas kvanton de unuoj (nomitaj en ItemBase aŭ en la Produkto EMIX) dum periodo. Utila ŝarĝo estas Kvanto. Tipa ItemBase estas RealEnergy
• x-resursa stato - Percentage de postulo

skalokodo

• p - Pico 10 ** - 12
• n - Nano 10 ** - 9
• mikro - Mikro 10 ** - 6
• m - Milli 10 ** - 3
• c - Centi 10 ** - 2
• d - Deci 10 ** - 1
• k - Kilogramo 10 ** 3
• M - Mega 10 ** 6
• G - Giga 10 ** 9
• T - Tera 10 ** 12
• neniu - Indiĝena Skalo

signalName

• BID_ENERGY - Jen la kvanto da energio de rimedo, kiu estis enmetita en programon
• BID_LOAD - Ĉi tiu estas la kvanto de ŝarĝo ofertita de rimedo en programon
• BID_PRICE - Jen la prezo ofertita de la rimedo
• CHARGE_STATE - Stato de energikonserva rimedo
• DEMAND_CHARGE - Ĉi tio estas la postulo
• ELEKTRO_PREZO - Jen la kosto de elektro
• ENERGIA_PREZO - Jen la kosto de energio
• LOAD_CONTROL -Agordi ŝarĝan eliron al relativaj valoroj
• LOAD_DISPATCH - Ĉi tio estas uzata por sendi ŝarĝon
• simpla – malplivalorigita – por retrokongruo kun A profile
• SIMPLA - Simplaj niveloj (konformaj al OpenADR 2.0a)

signalType

Nomumita valoro priskribanta la specon de signalo kiel nivelo aŭ prezo

• delto - Signalo indikas la kvanton ŝanĝotan de tio, kion oni uzus sen la signalo.
• nivelo - Signalo indikas programan nivelon.
• multiplikir - Signalo indikas multiplikaton aplikitan al la nuna rapideco de liverado aŭ uzado de tio, kion oni uzus sen la signalo.
• prezo - Signalo indikas la prezon.
• prezoMultiplier - Signalo indikas la prezon multobliganton. Plilongigita prezo estas la komputita prezvaloro multobligita per la nombro da unuoj.
• prezoRelativa - Signalo indikas la relativan prezon.
• starpunkto - Signalo indikas celan kvanton de unuoj.
• x-loadControlCapacity - Ĉi tio estas instrukcio por la ŝarĝa regilo funkcii je iu procentotage de ĝia maksimuma kapabla konsuma kapablo. Ĉi tio povas esti mapita al specifaj ŝarĝregiloj por fari aferojn kiel deĵoran bicikladon. Notu, ke 1.0 rilatas al 100% konsumo. En la kazo de simplaj ON/OFF tipo aparatoj tiam 0 = OFF kaj 1 = ON.
• x-loadControlLevelOffset - Diskretaj entjeraj niveloj, kiuj rilatas al normalaj operacioj, kie 0 estas normalaj operacioj.
• x-loadControlPercentOffset - Percentage ŝanĝo de normalaj ŝarĝkontrolaj operacioj.
• x-loadControlSetpoint - Ŝargi regilajn punktojn.

– OpenADR A kaj B Profile Diferencoj

La sola servo subtenata de la A-profesiulofile estas la servo EiEvent. La objekto EiEvent estas simpligita en la A profile kun la sekvaj limoj:

• Nur unu signalo por evento estas permesita kaj tiu signalo devas esti la konata signalo de OpenADR SIMPLE.
• Estas limigita evento-celado kun nur venID, groupID, resourceID kaj partyID subtenata. (EiEvent: eiTarget).
• Celado je la signala nivelo kun aparataj klasoj ne estas subtenata (eiEventSignal: eiTarget: endDeviceAsset).
• Bazlinioj ne estas subtenataj (eiEvent: eiEventSignals: eiEventBaseline).
• modificationDateTime kaj modificationReason ne estas subtenataj.
• La fina punkto URL ĉar simpla HTTP en 2.0b estas:
  • https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Kelkaj utilaj elementoj kiuj estis postulataj en la A-profesiulofile nun estas laŭvolaj en la B-profile, inkluzive de:

• aktualaValoro

- Sekurecaj Atestoj de OpenADR

La reguloj pri konformeco de OpenADR postulas jenon:

• TLS-Versio 1.2 estas uzata por la interŝanĝo de atestiloj X.509
• VTN-oj devas havi ambaŭ SHA256 ECC kaj RSA-atestilojn
• VENoj povas subteni atestilojn SHA256 ECC kaj RSA, kaj povas subteni ambaŭ
• Kaj VTN kaj VEN devas esti agorditaj por peti klientajn atestilojn se ili ludos la rolon de transporta servilo (te respondi al petoj de la alia partio)
• Kaj VTN kaj VEN devas provizi klientan atestilon, kiam la alia partio petas ĝin kiel parto de la intertrakta procezo pri TLS.

Atestiloj provizitaj de NetworkFX estos specifaj por RSA aŭ ECC. La kreo de ĉi tiuj atestiloj povas okazi kiel rezultoj de plenigado de formularoj en la NetworkFX web retejo por peti testatestojn aŭ povas esti la rezulto de petado de produktadatestiloj per Atestila Subskribo-Peto (CSR). Sendepende de la metodo, la sekva files estos provizitaj (ekzampili estas montritaj):

• Radika Atestilo
• Meza Radika Atestilo
• Aparata Atestilo
• Privata Ŝlosilo

Ĝenerale, la Privata Ŝlosilo estas uzata por ĉifri utilajn ŝarĝojn senditajn de VEN aŭ VTN. La Aparato-Atestilo estas aro de unikaj identigaj informoj pri VEN aŭ VTN, kiu estis kreita de Atestila Aŭtoritato kaj ĉifrita per la Privata Ŝlosilo. La Radiko kaj Meza files estas uzataj por malĉifri la Aparatan Atestilon kaj konfirmi, ke la atestilo venis de fidinda aŭtoritato.

En Java-medio, kiu uzas JSSE, estas du atestilaj butikoj. Unu nomiĝas Trust Store kaj estas uzata por teni la Radikan Atestilon. La dua nomiĝas Ŝlosila Butiko kaj estas uzata por stoki atestilan ĉenon konsistantan el la aparata atestilo intera atestilo, kaj ankaŭ la privata ŝlosilo

Bonvolu noti, ke uzante XMPP-transporton, VEN komunikas kun la XMPP-servilo kaj NE rekte kun la VTN. Do la agordo de atestiloj en la XMPP-servilo DEVAS esti ekvivalenta al tiu de VTN. La komunikado inter la VTN mem kaj la XMPP-servilo estas travidebla al la VEN kaj estas esence privata ligo. Tamen plej multaj vendistoj uzis aron de certigiloj VEN en la VTN dum komunikado kun la XMPP-servilo.

Se vi uzas OpenFire kiel vian XMPP-servilon, vi devas konsideri alian limon. OpenFire postulas, ke la CN-nomo uzata en la atestiloj de klientaj aparatoj kongruas kun la uzantnomo XMPP de la aparatoj agordita sur la XMPP-servilo. Ĉi tio povas rezultigi iujn strangajn klientajn nomojn, ĉar MAC kiel adreso estas uzata por la CN-nomo sur la atestiloj VEN (Parto de la Sekurecaj Postuloj de OpenADR)

Fine, plej multaj VEN-oj kaj VTN-oj ludante la rolon de transporta kliento provos konfirmi, ke la kampo CN de la atestilo provizita de la transporta servilo havas CN-nomon, kiu kongruas kun la gastiga nomo de la ento, kiu provizis la atestilon. Ĉi tio eble estas alia fonto de kunfunkcieblecaj problemoj dum interŝanĝo de atestiloj. Gastiganta Noma Kontrolo povas kutime esti malebligita laŭprograme por izoli ĉi tiajn problemojn.

Gvidilo pri Programo pri Demanda Respondo de OpenADR 2.0 - Elŝuti [optimumigita]
Gvidilo pri Programo pri Demanda Respondo de OpenADR 2.0 - Elŝutu

Referencoj

• Uzanto Manlibro