OpenADR 2.0

Patnubay sa Programa ng Pagtugon sa Demand

Numero ng Rebisyon: 0.92

Katayuan ng Dokumento: Teksto sa Paggawa

Numero ng Dokumento: 20140701

Copyright © OpenADR Alliance (2014/15). Nakareserba ang lahat ng mga karapatan. Ang impormasyon sa loob ng dokumentong ito ay pag-aari ng OpenADR Alliance at ang paggamit at pagsisiwalat nito ay pinaghihigpitan.

NILALAMAN

1 Panimula 6

2 Mga Sanggunian 6

3 Mga Tuntunin at Kahulugan 6

4 Mga pagpapaikli 9

5 Mga Uri ng Programa ng Pagtugon sa Demand 9

6 Mga Pangyayari sa Pag-deploy 10

6.1 Direkta 1 11

6.2 Direkta 2 12

6.3 Direkta 3 13

6.4 Direkta 4 14

6.5 Facilitator 1 15

6.6 Aggregator 1 16

7 Scenario ng Pag-deploy at Pagmamapa ng Program sa DR 16

8 Pagpili ng isang Template ng DR Program 18

9 Mga Template ng Programa ng Pagtugon sa Demand 21

9.1 Programa ng Kritikal na Pagpepresyo sa Pataas (CPP) 21

9.1.1 Mga Katangian ng Programang CPP DR 21

9.1.2 OpenADR Mga Katangian para sa Mga Programang CPP 22

9.2 Programa sa Pag-bid sa Kapasidad 24

9.2.1 Pag-bid sa Kapasidad sa DR Mga Katangian ng Programa 24

9.2.2 Mga Katangian ng OpenADR para sa Mga Programa sa Pag-bid sa Kapasidad 25

9.3 Program sa Residential Thermostat 27

9.3.1 Mga Katangian ng Programa ng Residential Thermostat DR. 27

9.3.2 OpenADR Mga Katangian para sa Mga Programang Residential Thermostat 28

9.4 Mabilis na DR Dispatch 29

9.4.1 Mabilis na Mga Katangian ng Program sa Dispatch Program 29

9.4.2 Mga Katangian ng OpenADR para sa Mga Programa sa Pag-bid sa Kapasidad 31

9.5 Programang Residential Electric Vehicle (EV) Oras ng Paggamit (TOU) 33

9.5.1 Mga Katangian ng Programa ng Residential EV TOU 33

9.5.2 OpenADR Mga Katangian para sa Residential EV TOU Programs 33

9.6 Programang Real-Time na Pagpepresyo ng Pampublikong Istasyong Electric Vehicle (EV) 34

9.6.1 Public Station EV RTP Program Mga Katangian 34

9.6.2 OpenADR Mga Katangian para sa Public Station EV RTP Programs 34

9.7 Ibinahagi na Mga Mapagkukunang Enerhiya (DER) DR Program 35

9.7.1 Mga Katangian ng Program na Pinamamahagi ng Enerhiya (DER) 35

9.7.2 Mga Katangian ng OpenADR para sa Ipinamahaging Mga Mapagkukunang Enerhiya (DER) 35

Annex A - Sample Mga Template ng Data at Payload 36

A.1 Programa ng Kritikal na Pagpepresyo sa Pataas (CPP) 36

A.1.1 CPP Scenario 1 - Kaso ng Simpleng Paggamit, A o B Profile 36

A.1.2 CPP Scenario 2 - Karaniwang Kaso ng Paggamit, B profile 36

A.1.3 CPP Scenario 3 - Kaso ng Paggamit ng Komplikado 37

A.1.4 CPP Sample Payload ng Kaganapan - Karaniwang B Profile Gumamit ng Kaso 37

A.2 Program sa Pag-bid sa Kapasidad (CBP) 39

A.2.1 CBP Scenario 1 - Kaso ng Simpleng Paggamit, A o B Profile 39

A.2.2 CBP Scenario 2 - Karaniwang Kaso ng Paggamit, B profile 39

A.2.3 CBP Scenario 3 - Kaso ng Paggamit ng Komplikado 40

A.2.4 CBP Sample Payload ng Kaganapan - Karaniwang B Profile Gumamit ng Kaso 40

A.3 Programang Residential Thermostat 42

A.3.1 Residential Thermostat Scenario 1 - Simpleng kaso ng Paggamit, A o B Profile 42

A.3.2 Residential Thermostat Scenario 2 - Karsikal na Paggamit ng Kaso, B profile 42

A.3.3 Residential Thermostat Scenario 3 - Kaso ng Paggamit ng Komplikadong 43

A.3.4 Residential Thermostat Sample Payload ng Kaganapan - Karaniwang B Profile Gumamit ng Kaso 43

A.4 Mabilis na DR Dispatch 45

A.4.1 Mabilis na Senaryo ng DR 1 - Kaso ng Simpleng Paggamit, A o B Profile 45

A.4.2 Mabilis na senaryo ng DR 2 - Karaniwang Kaso ng Paggamit, B profile 45

A.4.3 Mabilis na Scenario ng DR 3 - Kaso ng Paggamit ng Komplikado 46

A.4.4 Mabilis na DR Sample Payload ng Kaganapan - Karaniwang B Profile Gumamit ng Kaso 46

A.4.5 Mabilis na DR Sample Iulat ang Metadata Payload - Karaniwang B Profile Gumamit ng Kaso 48

A.4.6 Mabilis na DR Sample Report Humiling ng Payload - Karaniwang B Profile Gumamit ng Kaso 48

A.4.7 Mabilis na DR Sample Mag-ulat ng Data Payload - Karaniwang B Profile Gumamit ng Kaso 49

A.5 Programang Residential Electric Vehicle (EV) Oras ng Paggamit (TOU) 49

A.5.1 Residential EV Scenario 1 - Simpleng kaso ng Paggamit, A o B Profile 49

A.5.2 Residential EV Scenario 2 - Karaniwang Kaso ng Paggamit, B profile 50

A.5.3 Residential EV Sample Payload ng Kaganapan - Karaniwang B Profile Gumamit ng Kaso 50

A.6 Programang Real-Time na Pagpepresyo ng Pampublikong Istasyong Electric Vehicle (EV) 53

A.6.1 Public Station EV Scenario 1 - Karaniwang Kaso ng Paggamit, B profile 53

A.6.2 Pampublikong Istasyon EV Sample Payload ng Kaganapan - Karaniwang B Profile Gumamit ng Kaso 53

A.7 Ibinahagi na Mga Mapagkukunang Enerhiya (DER) DR Program 54

Annex B - Mga Kahulugan sa Serbisyo at Payload 55

Sinusuportahan ng B.1 Open ADR ang mga sumusunod na serbisyo: 55

Annex C - Mga Kahulugan sa Serbisyo at Payload 56

C.1 EiEvent Payloads 56

C.2 EiReport Payloads 56

C.3 EiOpt Payloads 56

C.4 Mga Payload ng EiRegisterParty 57

C.5 Mga Payload sa OadrPoll 57

Annex D - Talasalitaan ng Mga Elemento ng Payload ng Schema 58

Annex E Glossary ng Enumerated Values ​​65

E.1 kaganapanStatus 65

E.2 aytemMga Yunit 65

E.3 oadrDataKwalidad 65

E.4 oadrRequired 66

E.5 optReason 66

E.6 oadrTransportName 66

E.7 OptType 66

E.8 pagbasaType 66

Ulat ng E.9Name 67

E.10 ulatType 67

E.11 scaleCode 68

E.12 Pangalan ng signal 68

E.13 signalUri 69

Annex F - OpenADR A at B Profile Mga Pagkakaiba 70

Annex G - Mga Sertipiko sa Seguridad ng OpenADR 71

Panimula

Ang target na madla para sa patnubay na ito ay ang pagpaplano ng mga utility upang mag-deploy ng mga programa ng Demand Response (DR) na gumagamit ng OpenADR 2.0 para sa pakikipag-usap ng mga mensahe na nauugnay sa kaganapan sa DR sa pagitan ng mga utility at hilagang entity, at mga tagagawa ng kagamitan na nagpapadali sa pagpapalitan ng komunikasyon. Ipinapalagay na ang mambabasa ay may pangunahing pag-unawa sa konsepto ng parehong tugon sa demand at OpenADR 2.0 (tinukoy lamang bilang OpenADR mula sa puntong ito pasulong).

Ang OpenADR profile malinaw na tinukoy ng mga pagtutukoy ang inaasahang pag-uugali kapag nagpapalitan ng impormasyon na nauugnay sa kaganapan sa DR, subalit mayroong sapat na pagpipilian sa OpenADR na ang pag-deploy ng mga server (VTN) sa utility at mga kliyente (VEN) sa mga downstream na site ay hindi isang karanasan sa plug-n-play. Ang mga katangian ng OpenADR tulad ng mga signal ng kaganapan, mga format ng ulat, at pag-target ay dapat na tinukoy sa isang batayan ng programa ng DR.

Walang kagaya ng isang pamantayan na programa ng DR. Ang bawat disenyo ng programa ng DR ay may kaugaliang natatangi, na umaangkop sa mga kinakailangan sa istruktura at regulasyon ng heograpikong rehiyon kung saan ito naka-deploy. Para sa bawat programa ng DR maraming mga posibleng sitwasyon sa pag-deploy na kinasasangkutan ng iba't ibang mga artista.

Ang pagkakaiba-iba sa mga disenyo ng programa ng DR, mga sitwasyon sa paglawak, at mga katangian ng OpenADR ay isang inhibitor sa pinalawak na paglawak ng DR at ang paggamit ng OpenADR. Ang pagkakaiba-iba na ito ay para sa pinaka-bahagi ng isang pagsasalamin ng fragmented at kumplikadong likas na katangian ng matalinong grid.

Kailangan ng mga utility ang datingamples ng mga tipikal na programa ng DR upang maaari silang magamit bilang mga modelo para sa kanilang sariling pagpapatupad ng programa ng DR. Kailangang maunawaan ng mga tagagawa ng kagamitan ang mga tipikal na modelo ng paggamit ng DR Program upang mapatunayan nila ang interoperability bilang bahagi ng proseso ng pag-unlad kaysa sa isang tiyak na batayan ng pag-deploy ng programa ng DR. Ang hangarin ng gabay na ito ay upang makamit ang parehong mga layuning ito tulad ng sumusunod:

• Tukuyin ang isang maliit na hanay ng karaniwang mga template ng DR Program na na-modelo ayon sa karaniwang mga katangian ng pinakatanyag na mga programa ng DR na ipinatupad hanggang ngayon
• Tukuyin ang isang maliit na hanay ng mga sitwasyon sa pag-deploy na na-modelo pagkatapos ng mga totoong pag-deploy ng mundo, na may malinaw na pagkilala sa mga aktor at tungkulin
• Tukuyin ang mga rekomendasyong pinakamahusay na kasanayan para sa mga katangian ng OpenADR na tukoy para sa bawat isa sa mga template ng DR Program
• Magbigay ng isang puno ng pagpapasya na maaaring magamit ng mga utility upang makilala ang kapaki-pakinabang na mga template ng programa ng DR at mga sitwasyon sa paglawak batay sa kanilang mga pangangailangan sa negosyo

Ang diin sa patnubay na ito ay magiging sa pagpapanatili ng mga bagay na simple sa pamamagitan ng pagbibigay ng isang maliit na hanay ng mga malinaw na rekomendasyon na tatalakayin ang karamihan ng mga detalyeng kinakailangan upang mag-deploy ng isang tipikal na programa ng DR, at upang paganahin ang interoperability test ng mga kagamitan na na-deploy sa mga programa gamit ang mga rekomendasyon dito gabay.

Mga sanggunian

• OpenADR Profile Pagtukoy at iskema - www.openadr.org

Mga Tuntunin at Kahulugan

Ang mga sumusunod na termino at kahulugan ay ginagamit sa dokumentong ito.

• Tugon sa Demand: Isang mekanismo upang pamahalaan ang demand ng pag-load ng customer bilang tugon sa mga kundisyon ng supply, tulad ng mga presyo o signal ng kakayahang magamit
• Aggregator Party - Ito ay isang partido na pinagsasama-sama ang maraming Mga Mapagkukunan at ipinapakita ang mga ito sa DR Program Party bilang isang solong Mapagkukunan sa kanilang mga DR Program.
• Aggregator Intermediary Infrastructure - Ito ang imprastraktura, hiwalay sa Demand Side Infrastructure, na ginagamit ng Aggregator Intermediary Party upang makipag-ugnay sa parehong Mga Mapagkukunan at mga grid side entity
• Kasunduan: Isang kasunduan sa kontraktwal sa pagitan ng mga partido na may papel sa isang programa ng DR na nagbabalangkas ng mga responsibilidad at kabayaran
• Asset - Isang uri ng Mapagkukunan na kumakatawan sa isang tukoy na koleksyon ng mga pisikal na pag-load. Ang mga mapagkukunan ay maaaring binubuo ng Mga Asset, at ang isang Asset ay maaaring mapagkukunan, ngunit ang Mga Asset ay hindi maaaring karagdagang decomposed sa maraming Asset o Mga Mapagkukunan.
• Nauugnay: Magbigay ng isang programmatic na ugnayan sa pagitan ng dalawang mga nilalang, sa pamamagitan ng pagsasaayos ng isang aparato ng database. Halimbawa, mga nauugnay na mapagkukunan sa isang VEN
• Mga baseline: Ang kinakalkula o sinusukat na paggamit ng enerhiya (demand) ng isang piraso ng kagamitan o isang site bago ang kaganapan na tinukoy ng mga survey, inspeksyon, at / o pagsukat sa site.
• BMS - Ito ang Building Management System na maaaring magamit upang makontrol ang mga mapagkukunan. Minsan ito ay tinukoy bilang isang Energy Management System.
• Compound Resource - Ito ay isang espesyal na uri ng Mapagkukunan na isang pagsasama-sama ng maraming mga pisikal na pag-aari na ang bawat isa ay may sariling paraan ng kontrol sa pag-load.
• Insentibo sa Customer: Isang pampasigla na ibinigay sa may-ari / pinagsama-sama ng mga mapagkukunang panig ng hinihingi para sa pakikilahok sa isang programa ng DR.
• Pangangailangan ng Side Infrastructure - Ito ang imprastraktura na naglalaman ng Mga Mapagkukunan na naka-enrol sa DR Programs
• Logic ng DR: Mga algorithm o lohika na nag-convert ng mga signal ng DR sa naaaksyong pagkontrol sa pag-load. Tandaan na ang DR Logic ay maaaring ipatupad sa maraming iba't ibang mga lokasyon at sa ilang kaso ay maipamahagi sa maraming mga sub-system.
• DR Program Party - ito ang entity na responsable para sa Grid Infrastructure at saka para sa pamamahala ng mga DR Program na ginamit upang pagaanin ang mga isyu sa grid. Karaniwan itong isang Utility o ISO.
• Naka-enroll: Ang may-ari / pinagsama-sama ng mga mapagkukunang panig ng hiniling ay hinirang na lumahok sa isang programa ng DR at maaaring magbigay ng impormasyon tungkol sa mga tukoy na mapagkukunan na maaaring ma-target para sa mga kaganapan sa DR
• Panahon ng Aktibo ng Kaganapan: Ang ay ang panahon sa oras kung saan ang isang pagbabago sa pro ng pag-loadfile hinihiling bilang bahagi ng isang Kaganapan sa DR
• Mga Pagpipigil sa Kaganapan: Ang mga time frame kung saan maaaring asahan ng customer na makatanggap ng mga kaganapan at mga kaugnay na hadlang tulad ng walang mga kaganapan sa katapusan ng linggo o magkakasunod na araw
• Mga Araw ng Kaganapan: Isang araw kapag nangyari ang isang kaganapan sa DR. Karamihan sa mga programa ay may mga limitasyon sa bilang ng mga araw ng kaganapan na pinapayagan sa isang naibigay na panahon ng kalendaryo
• Kaganapan Descriptor: Bahagi ng object ng kaganapan ng OpenADR na naglalarawan sa metadata tungkol sa kaganapan, tulad ng pangalan ng programa at prayoridad ng kaganapan
• Tagal ng Kaganapan: Ang haba ng kaganapan. Karamihan sa mga programa ay tumutukoy sa mga hadlang sa haba ng isang kaganapan, pati na rin ang mga oras ng araw kung saan maaaring mangyari ang kaganapan
• Mga Senyas sa Kaganapan: Ang naaaksyunang impormasyon na nilalaman sa isang kaganapan tulad ng pagpepresyo ng elektrisidad o tukoy na mga antas ng pag-load ng karga na hiniling na karaniwang nagpapalitaw ng ilang paunang na-program na pag-uugali ng pag-load ng load ng tatanggap ng kaganapan. Ang isang kahulugan ng programa ng DR ay dapat na tukuyin ang mga uri ng ginamit na signal ng kaganapan
• Pag-target sa Kaganapan: Ang mga mapagkukunan ng pagpapadanak ng load na ang inilaan na tatanggap para sa kaganapan sa DR. Ang maaaring isang lugar na pangheograpiya, isang partikular na klase ng mga aparato, isang tagakilala ng pangkat, resource ID, o iba pang pagkakakilanlan. Ang isang kahulugan ng programa ng DR ay dapat tukuyin kung paano ang mga tukoy na mapagkukunan ay mai-target.
• Mga kaganapan: Ang isang kaganapan ay isang abiso mula sa utility upang humiling ng mga mapagkukunang panig na humihiling ng pag-load na nagsisimula sa isang tukoy na oras, sa isang tinukoy na tagal, at maaaring isama ang pag-target ng impormasyon na tumutukoy sa mga partikular na mapagkukunan na dapat lumahok sa kaganapan
• Imprastraktura ng Tagapamagitan ng Facilitator - Ito ang imprastraktura, hiwalay sa Demand Side Infrastructure, na ginagamit ng Facilitator Intermediary Party upang makipag-ugnay sa parehong Mga Mapagkukunan at mga grid side entity.
• Facilitator: Isang pangatlong partido na namamahala sa ilan o lahat ng pagpapatupad ng programa ng DR sa ngalan ng utility
• Imprastraktura ng Grid - Ito ang imprastraktura na pagmamay-ari o pinamamahalaan ng mga DR Program Parties. Kasama sa imprastrakturang ito ang pagpapatupad ng OpenADR VTN na ginagamit upang magpadala ng mga DR signal sa Mga Mapagkukunang nakatala sa mga DR Program.
• Tagapamagitan Party - Ito ay isang partido na karaniwang gumagana sa ngalan ng Resource Party upang mapabilis ang kanilang pakikilahok sa mga DR Program.
• Kontrol sa Pag-load - ito ang imprastrakturang nauugnay sa isang mapagkukunan na responsable para sa aktwal na pagkontrol sa mapagkukunan at paggawa ng isang tukoy na pro ng pag-loadfile.
• Mag-load ng Profile Layunin: Ang pagganyak na ito sa likod ng pagbuo ng isang programa ng DR at pag-isyu ng mga kaganapan. Tulad ng pagnanais na mag-ahit ng rurok na mga pag-load.
• Abiso: Isang tagal ng oras bago ang oras ng pagsisimula ng isang kaganapan kung saan aabisuhan ang may-ari ng mapagkukunang bahagi ng demand ng isang nakabinbing kaganapan
• Pagpipilian sa Pag-uugali: Ang inaasahang tugon mula sa may-ari ng panig ng hinihingi sa pagtanggap sa isang kaganapan. Ang tugon na ito ay maaaring magkaroon ng anyo ng at pahiwatig ng OptIn o OptOut kung ang mapagkukunan ay lumahok sa kaganapan
• Mga tugon sa Pagpipilian: Kung ang isang tiyak na programa ay dapat mangailangan ng isang tugon mula sa mga mapagkukunang panig ng demand bilang tugon sa isang kaganapan, at kung ano ang karaniwang mga tugon na iyon.
• Mga Serbisyo sa Pagpipilian: Nakipag-usap ang mga iskedyul sa OpenADR upang ipahiwatig ang pansamantalang pagbabago sa pagkakaroon ng mapagkukunan upang lumahok sa mga kaganapan.
• Prerequisite: Mga pamantayan na dapat matugunan upang ang isang may-ari ng mapagkukunang panig na mag-enrol sa isang programa ng DR. Maaaring isama dito ang pagkakaroon ng pagpupulong ng agwat o ilang minimum na kapasidad ng load load
• Pangunahing Mga Driver: Ang pangunahing pagganyak sa bahagi ng utility para sa paglikha ng programa ng DR at pag-isyu ng mga kaganapan. Tulad ng "Pinapababang demand ng rurok at pagiging sapat ng mapagkukunan"
• Mga programa - Ito ang mga DR Program na naka-enrol ang Mga Mapagkukunan.
• Paglalarawan ng Programa: Isang pagsasalarawan na pagsasalaysay kung paano gumagana ang isang programa. Bahagi ng mga template ng DR Program na tinukoy sa dokumentong ito
• Programa ng Frame ng Oras: Ang oras ng taon o panahon sa panahon ng isang programa ng DR ay karaniwang aktibo
• Disenyo ng Rate: Ang tukoy na mga pagbabago sa istraktura ng rate o mga insentibo na binayaran upang maganyak ang mga may-ari ng hinahangad na panig na humiling na lumahok sa programa
• Mga Serbisyo sa Rehistro: Serbisyong ginamit ng OpenADR protocol upang maitaguyod ang pangunahing interoperability sa pagitan ng isang VTN at VEN, at upang mapatunayan na ang VEN ay nauugnay sa account ng mga customer ng utility.
• Mga Serbisyo sa Pag-uulat: Serbisyong ginamit ng OpenADR upang paganahin ang mga VEN na magbigay ng pag-uulat sa mga VEN. Dapat tukuyin ng DR Program ang mga kinakailangan sa pag-uulat para sa programa.
• Resource Party - Ito ang partido na nagmamay-ari ng demand na Mga mapagkukunan na maaaring ma-enrol sa DR Programs
• mapagkukunan - Ito ang entity na naka-enrol sa DR Programs at may kakayahang maghatid ng ilang uri ng pagbabago sa kanilang load profile bilang tugon sa pagtanggap ng isang DR signal mula sa isang VTN.
• Target na Customer: Ang profile ng mga mapagkukunang panig ng demand na maaaring magpatala sa isang tukoy na programa ng DR tulad ng tirahan, pang-industriya, o marahil batay sa antas ng pagkonsumo ng kuryente.
• Mga Target na Pag-load: Ang mga mapagkukunang panig ng demand na ang pagkarga ay dapat mabago sa pagtanggap ng a
• VEN - Ito ang OpenADR Virtual End Node na ginagamit upang makipag-ugnay sa VTN.
• VTN - Ito ang OpenADR Virtual Top Node na ginagamit upang makipag-ugnay sa Mga Mapagkukunang nakatala sa mga DR Program.

Mga pagdadaglat

• BMS: Sistema ng pamamahala ng gusali
• C&I: Komersyal at Pang-industriya
• Sinabi ni Comm: Mga komunikasyon sa pagitan ng dalawang entity
• DR: Tugon sa Demand
• EMS: Sistema ng Pamamahala ng Enerhiya
• OpenADR: Buksan ang Tugon sa Awtomatikong Demand
• Mga programa: Sanggunian sa isang (Mga) Programa ng Pagtugon sa Demand
• VEN: Virtual End Node
• VTN: Virtual Nangungunang Node

Mga Uri ng Programa ng Pagtugon sa Demand

Naglalaman ang dokumentong ito ng mga template para sa mga programang DR na ipinakita sa ibaba.

 

1. Kritikal na Pagpepresyo ng Pinakamataas: Ang istraktura ng rate at / o presyo na idinisenyo upang hikayatin ang pinababang pagkonsumo sa mga panahon ng mataas na presyo ng maramihang pakyawan o mga contingency ng system sa pamamagitan ng pagpapataw ng isang paunang tinukoy na mataas na rate o presyo para sa isang limitadong bilang ng mga araw o oras.

2. Programa sa Pag-bid sa Kapasidad: Isang programa na nagbibigay-daan sa isang mapagkukunan ng demand sa mga merkado ng tingi at pakyawan upang mag-alok ng mga pagbawas ng pagkarga sa isang presyo, o upang makilala kung gaano karaming karga ang nais nitong bawasan ang isang partikular na presyo.

 

3. Residential Thermostat Program / Direct Load Control: Isang aktibidad ng pagtugon sa demand na kung saan malayo na kinokontrol ng sponsor ng programa ang mga de-koryenteng kagamitan ng isang customer (hal. Aircon) sa maikling abiso. Ang mga programang ito ay pangunahing inaalok sa tirahan o maliit na mga komersyal na customer.

4. Mabilis na DR Dispatch / Ancillary Services Program: Isang programa sa pagtugon sa demand na nagbibigay ng mga pagbabayad sa insentibo sa mga customer para sa pagtugon sa pag-load habang isang Kaganapan sa Pagtugon sa Demand na Pangangailangan. Isang abnormal na kondisyon ng system (para sa halample, mga hadlang ng system at mga hadlang sa lokal na kapasidad) na nangangailangan ng awtomatiko o agarang manu-manong pagkilos upang maiwasan o limitahan ang pagkabigo ng mga pasilidad sa paghahatid o suplay ng henerasyon na maaaring makaapekto sa pagiging maaasahan ng Bulk Electric System. Ang ganitong uri ng mga programa ay maaaring minsan ay tinukoy bilang "Mga Serbisyong Ancillary".

5. Programa ng Electric Vehicle (EV) DR: Isang aktibidad ng pagtugon sa demand kung saan binago ang gastos ng pagsingil ng mga de-koryenteng sasakyan upang maging sanhi ng paglilipat ng mga pattern ng pagkonsumo sa mga consumer.

6. Naipamahagi na Program na Pinagkaloob na Mga mapagkukunang enerhiya (DER): Isang aktibidad ng pagtugon sa demand na ginamit upang makinis ang pagsasama ng pamamahagi ng mga mapagkukunan ng enerhiya sa smart grid.

 

Mga Scenario ng Pag-deploy

Ang paraan kung saan naka-deploy ang isang programa ng DR ay medyo independiyente sa mga katangian ng mismong programa ng DR. Ang mga sumusunod na diagram ay nagpapakita ng iba't ibang mga paraan kung saan maaaring ma-deploy ang isang programa ng DR. Ang sumusunod na seksyon ay nagbibigay ng isang cross reference sa pagitan ng mga sitwasyon sa paglawak at mga DR Program na malamang na magamit nila.

Ang mga diagram sa seksyong ito ay nagpapakita ng mga ugnayan sa pagitan ng mga entity sa iba't ibang mga sitwasyon.

Direkta 1

Ito ay isang simpleng senaryo kung saan mayroong direktang ugnayan sa pagitan ng DR Program Party at ng Resource Party. Ang Resource Party ay responsable para sa pagpapatala ng kanilang sariling Mga mapagkukunan sa DR Programs at ang Grid Infrastructure ay direktang nakikipag-ugnay sa Mga Mapagkukunan sa pamamagitan ng isang VEN na naninirahan sa loob ng Demand Side Infrastructure. Bukod dito ang VEN ay pagmamay-ari ng Resource Party at hiwalay mula sa Mga Mapagkukunan at kanilang mga kumokontrol. Kapag ang isang senyas ng DR ay natanggap ng VEN karaniwang hindi ito nagpapatupad ng anumang lohika ng pagkontrol sa pag-load, ngunit pasulong lamang ang mga signal sa mga control ng load na gumawa ng naaangkop na pagkilos. HalampAng les ng senaryong ito ay magsasama ng mga gusali ng C&I na maaaring mag-install ng isang gateway na naglalaman ng isang OpenADR VEN at kapag ang isang senyas na natanggap ng gateway na iyon ay isinasalin lamang ito sa ilang iba pang mga protokol at pasulong sa mga tagakontrol ng load mismo.

Direkta 2

Ito ay halos kapareho sa sitwasyon ng Direktang 1. Ang pangunahing pagkakaiba sa kung paano nabago ang VEN at pinadali ang mga pakikipag-ugnay sa VTN. Ang VEN ay itinatag sa isang nilalang tulad ng isang sentralisadong BMS na maaaring magpatupad ng DR lohika at makipag-ugnay sa Compound Resource at kanilang maraming iba't ibang mga tagakontrol ng karga mula sa isang mas sentralisadong lokasyon. Halamples isama ang malalaking gusali na may isang BMS na kumokontrol sa maraming iba't ibang mga karga sa isang gusali (hal. pag-iilaw, HVAC, mga pang-industriya na proseso, atbp.) hanggang sa campmga paggamit na maaaring may maraming mga pasilidad na may isang sentralisadong sistema ng kontrol.

Direkta 3

Ang senaryong ito ay halos kapareho ng senaryo ng Direktang 1. Ang pangunahing pagkakaiba ay ang VEN ay instantiated nang direkta sa mapagkukunan at ang load controller. Sa kasong ito ang mga DR signal ay ipinapadala nang direkta sa mapagkukunan at sa load controller. Ang senaryo na tinatawag na "mga presyo sa mga aparato" ay nasa kategoryang ito. Halamples ay isasama ang anumang uri ng load controller tulad ng HVAC (ie termostat) na may isang naka-embed na VEN na may kakayahang makipag-ugnay nang direkta sa mga gilid ng entity na VTN.

Direkta 4

Ito ay isang kumbinasyon ng mga uri ng direktang 1 at Direktang 2 na mga sitwasyon. Ang pangunahing kaibahan na ang maraming VEN ay nauugnay sa isang solong Mapagkukunan ng Compound na binubuo ng maraming mga assets sa kanilang sariling mga tagakontrol ng karga. Ang bawat isa sa mga control control na naglalaman ng Compound Resource ay maaaring maiugnay sa ibang VEN. Tandaan na ang lahat ng VEN ay nasa ilalim ng kontrol ng parehong Resource Party na nagmamay-ari ng Compound Resource. Ang senaryong ito ay umiiral upang mapadali ang Mga Pangangailangan ng Mga Side Infrastrukture na mayroong Mga Pinagmumulan ng Pinagmulan, ngunit walang sentralisadong BMS tulad ng direktang 2 na senaryo. Halamples ay maaaring magsama ng mga gusali na may iba't ibang mga control control sa bawat palapag, ngunit walang sentralisadong BMS, o campgumagamit ng iba't ibang mga kontrol sa bawat gusali, ngunit walang campsa amin malawak na controller. Dahil mula sa pananaw ng DR Program Party mayroon lamang isang solong mapagkukunan na nakatala sa programa kapag nais nitong magpadala ng isang DR signal sa mapagkukunan maaari lamang itong magpadala ng parehong mga signal sa bawat isang itinalagang VEN na naiugnay sa Resource.

Facilitator 1

Sa senaryong ito mayroong isang tagapamagitan na nagpapabilis sa mga pakikipag-ugnayan sa pagitan ng DR Program Party at ng Mga Mapagkukunan. Kadalasan ang Partido ng Tagapamagitan ay gumagana sa ngalan ng Resource Party upang matulungan silang pamahalaan ang kanilang Mga Mapagkukunan. Ang Mga Partido ng Mapagkukunan ay may direktang pakikipag-ugnay sa DR Program Party at ipinatala nila ang kanilang sariling Mga Mapagkukunan sa mga DR Program. Sa gayon ang DR Program Party views bawat Resource Party bilang isang hiwalay na mapagkukunan at maaaring makipag-ugnay sa kanila nang paisa-isa. Ang papel na ginagampanan ng Partido ng Tagapamagitan ay kumilos bilang isang lakad sa pagitan ng lahat ng mga pakikipag-ugnay na kaugnay sa OpenADR, kaya't ang VEN ay nabago sa loob ng Facilitator Intermediary Infrastructure. Ang nasabing mga imprastraktura ay madalas na mga cloud base at inaalok sa mga Resource Parties bilang Software bilang isang Serbisyo (SaaS). Kapag ang signal ng DR ay natanggap ng VEN ng Facilitator ang isang bilang ng iba't ibang mga aksyon ay maaaring maganap kasama ang pagpapasa ng DR signal sa naaangkop na Resource at posibleng pagpapatupad ng isang uri ng DR Logic at pagpapadala ng mga utos ng control sa load sa bawat control ng load ng Resource. HalampAng les ng senaryong ito ay kinabibilangan ng:

• Ang mga vendor na namamahala ng mga pasilidad para sa mga malalaking chain ng komersyo tulad ng mga malalaking tagatingi ng kahon.
• Mga tagapamagitan sa pagkontrol ng industriya.
• Mga Kumpanya ng Mga Serbisyo ng Enerhiya (ESCO's)
• Cloud based appliance at mga sistema ng pamamahala ng aparato tulad ng umuusbong na matalinong pakikipag-usap ng mga nagbebenta ng termostat.

Aggregator 1

Ang senaryong ito ay katulad ng senaryo ng Facilitator. Ang pangunahing pagkakaiba ay ang Aggregator Party na may kaugnayan sa DR Program Party na taliwas sa Mga Resource Parties. Pinagsasama-sama ng Aggregator Party ang maraming Mga Asset ng customer sa isang solong Mapagkukunan na pinapasok nito sa mga DR Program. Ang DR Program Party ay walang kakayahang makita sa mga indibidwal na Asset na pinamamahalaan ng Aggregator. Tulad ng sa Facilitator ang Aggregator ay may sariling imprastraktura kung saan ang VEN ay instantiated. Ang pagkakaiba-iba na kapag natanggap ang isang signal ng DR ay tumutukoy ito sa isang solong mapagkukunan at nagpapatupad ang Aggregator ng ilang uri ng DR lohika sa lahat ng mga Asset sa kanilang portfolio upang makamit ang mga layunin na tinukoy sa signal ng DR.

 

Scenario ng Pag-deploy at Pagmamapa ng Program sa DR

Ang talahanayan sa ibaba ay nagbibigay ng kung aling mga sitwasyon sa pag-deploy ang pinakakaraniwan para sa isang tukoy na DR Program.

	Sitwasyon ng Deployment
Template ng DR	Direkta sa 1, 2, 3, 4	Facilitator 1	Aggregator 1
Programa ng CPP	∆	∆
Programa sa Pag-bid sa Kapasidad			∆
Residential Thermostat Programa		∆
Mabilis na DR Dispatch			∆
Programa ng Electric Vehicle (EV) DR	∆	∆
Naipamahagi na Program na Pinagkaloob na Mga mapagkukunang enerhiya (DER)	∆	∆

Pagpili ng isang Template ng Program sa DR

Ang mga sumusunod ay isang hanay ng mga katanungan na nauugnay sa anumang utility tungkol sa pagpapatupad ng isang bagong programa ng DR. Hindi ito sinadya upang maging komprehensibo, ngunit kumakatawan sa ilan sa mga mas nauugnay na isyu. Ang layunin ng mga katanungang ito ay upang makatulong na gabayan ang mga utility patungo sa isang naaangkop na hanay ng mga template ng DR Program.

Q: Bakit mo nais na gawin ang DR? Anong kalagayan sa grid o isyu sa pagpapatakbo ang sinusubukan mong pagaanin sa DR?

Ito ang pinakamahalagang katanungan at bumubuo ng batayan para sa pangkalahatang mga kinakailangan at layunin para sa kung ano ang dapat makamit ng programa ng DR. Ang sagot sa katanungang ito ay tumutukoy kung paano ang pro sa pagkarga ng profile ay dapat na hugis ng programa ng DR. Ang lahat ng iba pang mga kinakailangan ay dumadaloy mula sa sagot sa tanong na ito.

• Sinusubukan mo bang mag-ahit ng mga tuktok?
• Nais mo bang punan ang tiyan ng pato?
• Sinusubukan mo bang hadlangan ang spot presyo ng kuryente?
• Nag-aalala ka ba sa pagiging maaasahan ng grid?
• Sinusubukan mo bang mapanatili ang mga assets ng grid?
• Atbp atbp atbp.

Ang talahanayan sa ibaba ay nagbibigay ng ilang karagdagang konteksto sa mga pagganyak sa likod ng pagnanais na bumuo ng isang DR Program

Kahusayan at Kaligtasan ng Grid	Dalas at Voltage Katatagan
	Pagkakasunod sa Mapagkukunan
	Kapasidad sa Rurok
	Ramping
	Contingency
Pagkuha ng Enerhiya	Mga presyo ng Spot Market
	Arbitrage ng Presyo
Pamamahala ng Asset	Pag-iwas sa Pinsala
	Pagbawas sa Pagpapanatili
	Pang-habambuhay na Extension
Pamamahala ng Kapasidad	Mga Benepisyo sa Ekonomiya
	Pamamahala ng Emergency
Pangkapaligiran	Negawatt
	Malinis na Enerhiya

T: Mayroon bang mayroon nang programa sa DR o taripa na para sa program na ito?

• Kadalasan ang mga patakaran ng programa ay malinaw na binabaybay nang malinaw sa isang taripa.

Q: Ano ang hinihiling na market segment na tina-target mo sa program na ito?

Maaari itong makatulong na matukoy ang pag-target ng mga mapagkukunan sa kaganapan at ang uri ng signal.

• Residential
• Malaking C&I
• Maliit na C&I
• Agrikultura
• Pamamahala ng tubig
• Mga Sasakyang de-kuryente
• Atbp, atbp, atbp

T: Sinusubukan mo bang mag-target ng mga tukoy na uri ng pag-load?

• Mga thermostat
• Mga de-kuryenteng sasakyan
• Ag pump
• atbp.

Q: Ano ang iyong modelo ng pag-deploy?

Ang sagot sa katanungang ito ay maaaring maka-impluwensya kung paano tinukoy ang mga mapagkukunan sa loob ng programa at matukoy kung paano naka-target ang mga mapagkukunang iyon sa loob ng mga kaganapan.

• Direkta sa mga customer
• Sa pamamagitan ng mga tagapamagitan tulad ng mga pinagsama-sama o tagapagpadali
• May pananagutan ang Customer sa pagkuha at pag-deploy ng kanilang sariling kagamitan sa VEN?
• atbp.

Q: Sa anong antas ng pagiging tiyak na nais mong makipag-ugnay sa mga naglo-load ng demand na bahagi?

Ang katanungang ito ay medyo nauugnay sa modelo ng paglawak at tumutukoy kung paano tinukoy at naka-target ang mga mapagkukunan sa programa. Ito ay isa sa pinakamahalaga at posibleng kumplikadong mga katanungan.

• Makipag-ugnay sa bawat indibidwal na mapagkukunan
• Makipag-ugnay sa pamamagitan ng isang tagadali o pinagsama-sama na walang detalye sa mga mapagkukunan sa likuran nila
• Makipag-ugnay sa pamamagitan ng isang tagadali o pinagsama AT Tukuyin kung aling mga mapagkukunan sa likod ng mga ito ang dapat na maipadala
• Gumamit ng lokasyon bilang isang katangian upang tukuyin ang mga mapagkukunan
• Gumamit ng ilang uri ng tinukoy na mekanismo ng pagpapangkat ng grupo upang tukuyin ang mga mapagkukunan
• Mag-target ng mga indibidwal na assets tulad ng mga termostat
• Makipag-ugnay nang walang mga mapagkukunan sa lahat at i-broadcast lamang ang mga kaganapan sa DR
• atbp.

Q: Anong pattern ng pakikipag-ugnay ang nais mong gamitin upang maimpluwensyahan ang iyong mga customer na mag-load ng profiles?

Tinutukoy ng katanungang ito ang uri ng mga DR signal na ipapadala sa mga kalahok sa isang programa.

• Mga Insentibo (hal. Pabagu-bago na pagpepresyo)
• Mga pagpapadala ng load (hal. Mga serbisyong pantulong)
• Direktang pagkontrol sa pag-load
• Generic signal ng kaganapan
• atbp.

Q: Ano ang mga pangkalahatang katangian ng pag-iiskedyul ng mapagkukunan ng programa?

• Mga petsa at oras na maaaring tawagan ang mga kaganapan
• Dalas ng mga kaganapan
• Tagal ng mga kaganapan
• Pinapayagan na mga latency para sa paglaganap ng mga kaganapan
• atbp.

Q: Paano natutukoy ang pagkakaroon ng mga mapagkukunan sa programa?

• Sa pamamagitan ng mahigpit na mga patakaran ng programa
• Bilang bahagi ng ilang nominasyon o proseso ng pag-bid na ginawa ng mapagkukunan
• Pinapayagan ang mag-opt In / Out?
• atbp.

Q: Anong uri ng kakayahang makita ang kailangan mo sa pagganap ng mapagkukunan?

Ito ay isang napakalawak na tanong at tumutukoy kung anong uri ng impormasyon ang pinakain mula sa mga mapagkukunan sa programa ng DR. Sa pangkalahatan tinutukoy nito ang uri ng mga ulat na kinakailangan.

• Online / Offline
• Paggamit (kasalukuyan at / o makasaysayang)
• Potensyal ng pag-load
• Kakayahang magamit
• Load / estado ng pag-aari (kasalukuyan at / o makasaysayang)
• Atbp, atbp atbp.

Mga Template ng Programa ng Pagtugon sa Demand

Kritikal na Programa sa Pagpepresyo ng Pataas (CPP)

Mga Katangian ng Programang CPP DR

Mag-load ng Profile Layunin	-Peak magbawas ng demand
Pangunahing Mga Driver	-Nabawas ang mga paggasta sa kapital at nabawasan ang mga gastos sa enerhiya
Paglalarawan ng Programa	Kapag naobserbahan o inaasahan ng mga utility ang mataas na presyo ng maramihang pakyawan o mga kundisyon ng emergency system, maaari silang tumawag sa mga kritikal na kaganapan sa isang tinukoy na tagal ng panahon (hal. 3 pm — 6 pm sa isang mainit na araw ng tag-araw sa tag-init), ang presyo para sa elektrisidad sa mga panahong ito ay malaki itinaas.
Insentibo sa Customer	Maaaring alukin ang mga customer ng mga presyong may diskwento sa enerhiya sa mga oras na hindi pang-rurok bilang isang insentibo na lumahok sa programa.
Disenyo ng Rate	Ang CPP ay isang programa ng presyo na may pagtaas ng mga rate sa panahon ng mga kritikal na taluktok sa pagkonsumo ng enerhiya. Kadalasan ang mga rate ng CPP ay isang adder o multiplier sa flat, tiered, o mga rate ng base sa TOU.
Target na Customer	-Residential o C&I
Target na Pag-load	-Anumang
Prerequisite	-Ang customer ay dapat na mayroong pagsukat ng agwat Ang mga customer ng C & I ay maaaring kailangang matugunan ang isang pamantayan sa demand
Programa ng Frame ng Oras	-Karaniwang sumasaklaw sa mga buwan ng taon kung saan nangyayari ang pinakamataas na pagkonsumo ng enerhiya, kahit na maaaring buong taon sa ilang mga kaso.
Mga Pagpipigil sa Kaganapan	-Karaniwang Lunes hanggang Biyernes, hindi kasama ang mga piyesta opisyal, na may kasunod na mga kaganapan sa araw na karaniwang pinapayagan
Mga Araw ng Kaganapan	-Karaniwan na 9 hanggang 15 bawat taon
Tagal ng Kaganapan	-Karaniwan sa panahon ng isang nakapirming time frame para sa lahat ng mga kaganapan mula 4 hanggang 6 na oras sa panahon ng pinakamataas na oras ng pagkonsumo ng enerhiya sa araw.
Abiso	-Karaniwan na maaga
Pagpipilian sa Pag-uugali	-K Karaniwan ang mga customer ay hindi kinakailangan na lumahok sa mga kaganapan
Sertipikasyon Mga kaganapan	-Karaniwan wala

OpenADR Mga Katangian para sa mga Programang CPP

Mga Senyas sa Kaganapan	–Isang SIMPLE signal na may mga antas 1 hanggang 3 na nai-map sa epekto sa pagpepresyo ng kaganapan sa CPP. Kung ang isang programa sa CPP ay may isang bahagi ng pagpepresyo dapat itong ma-map sa antas 1. Para sa mga programang CPP na may maraming bahagi ng pagpepresyo, ang pinakamaliit na sangkap ng presyo ay dapat na ma-map sa antas 1, kasama ang iba pang mga bahagi ng presyo na na-map sa mga antas 2 at 3 sa pagtaas ng degree ng epekto sa pagpepresyo. -Kung sinusuportahan ng paglawak ang B profile mga VEN, bilang karagdagan sa signal na SIMPLE, maaaring maisama ang isang signal na elektroniko_PRICE sa payload na may isang uri ng presyo Kaugnay, presyoAbsolute, o presyoMultiplier depende sa likas na katangian ng programa. Tingnan ang Annex A para sa datingamples.
Mga tugon sa Pagpipilian	-VTNs na nagpapadala ng mga kaganapan dapat itakda ang elemento ng oadrResponseRequired na "palaging", na nangangailangan ng VEN na tumugon sa isang optIn o optOut -Bilang isang pakikilahok sa isang programa sa CPP ay isang "pinakamahusay na pagsisikap" na ehersisyo, walang pormal na kahulugan na mag-optIn o mag-optOut na lampas sa isang kagandahang-loob na pagkakaroon ng indikasyon ng hangarin na lumahok. Inirerekumenda namin iyon Ang mga VEN ay tumutugon sa optIn maliban kung mayroong ilang partikular na pagkilos na labis na pag-override na kinuha ng customer. -Ang oadrCreateOpt payload ay karaniwang hindi gagamitin upang maging kuwalipikado ng mga mapagkukunan na nakikilahok sa mga kaganapan.
Kaganapan Descriptor	-Ang kaganapan dapat itakda ang prioridad sa 1 maliban kung ang mga patakaran ng programa o pagsasaayos ng VTN ay tumutukoy sa ibang paraan –Karaniwang hindi ginagamit ang mga kaganapan sa pagsubok kasama ang mga programa ng CPP. Gayunpaman kung pinapayagan sila ay dapat itakda ang elemento ng testEvent sa "totoo" upang ipahiwatig ang kaganapan sa pagsubok. Kung ang karagdagang impormasyon na may parameter na kinakailangan sa sangkap na ito maaari itong sundin ang "totoo" na pinaghihiwalay ng isang puwang na may karagdagang impormasyong ito.
Panahon ng Aktibo ng Kaganapan	– eiRampPataas, eiRec Recovery, mga elemento ng pagpapaubaya ay karaniwang hindi ginagamit
Mga baseline	–Karaniwang hindi kasama ang mga baseline sa payload ng kaganapan
Pag-target sa Kaganapan	Karaniwang hindi naiiba ang mga programa sa CPP sa pagitan ng mga mapagkukunan para sa isang naibigay na customer. Karaniwang tinutukoy ng pag-target ang venID, na nagpapahiwatig na ang lahat ng mga mapagkukunang nauugnay sa VEN ay dapat lumahok, o isang listahan ng lahat ng mga resourceID nauugnay kay VEN.
Mga Serbisyo sa Pag-uulat	–Karaniwang hindi ginagamit ang pag-uulat ng telemetry dahil hindi ito ganap na kinakailangan para sa mga programa ng CPP. Sumangguni sa Annex B para sa datingamples ng mga ulat mula sa mga pilot ng utility na maaaring mailalapat sa ganitong uri ng programa.

Mga Serbisyo sa Pagpipilian	–Paggamit ng serbisyo ng Opt upang makipag-usap ng pansamantalang mga iskedyul ng pagkakaroon karaniwang hindi gagamitin bilang bahagi ng isang programa ng CPP. Gayunpaman, maaaring magamit ng ilang deployment ang serbisyong ito upang mapanatili ang magagamit na mga araw ng kaganapan para sa mga customer na nagpapahiwatig na walang kakayahang magamit.
Mga Serbisyo sa Rehistro	Mga agwat ng botohan hiniling ng VTN para sa mga tipikal na programang CPP na pang-araw ay hindi kinakailangan na maging mas madalas na minsan sa isang oras. Gayunpaman, ang paggamit ng botohan para sa pagtuklas ng tibok ng puso ay maaaring mangailangan ng mas madalas na botohan.

Programa sa Pag-bid sa Kapasidad

Mga Kakayahang Program sa Pag-bid sa Kapasidad DR

Mag-load ng Profile Layunin	-Peak na pagbawas ng demand at pagiging sapat ng mapagkukunan
Pangunahing Mga Driver	-Nabawas ang mga paggasta sa kapital at nabawasan ang mga gastos sa enerhiya
Paglalarawan ng Programa	Ang programa sa pag-bid sa kapasidad ay ginagamit ng ISO / utilities upang makakuha ng paunang nakatuon na kapasidad na malaglag mula sa mga pinagsama-samang o mga pinagsamang customer. Ang paunang nakatuon na kapasidad ng load load ay ginagamit ng ISO / utilities kapag naobserbahan o inaasahan nila ang mataas na presyo ng maramihang pakyawan, mga kondisyon ng emergency system ng kuryente, o bilang bahagi ng normal na paggamit ng mapagkukunan ng enerhiya sa pamamagitan ng pagtawag sa mga kaganapan sa DR sa isang tinukoy na tagal ng panahon.   Tandaan na ang bawat pinagsama-sama ay karaniwang responsable para sa pagdidisenyo ng kanilang sariling programa ng pagtugon sa demand pati na rin ang pagkuha ng customer, at pag-abiso sa kaganapan upang matugunan ang mga pangako sa kakayahan na ginawa bilang bahagi ng program na ito.
Insentibo sa Customer	Ang mga agregator / customer ay tumatanggap ng dalawang uri ng mga insentibo. Una, nakatanggap sila ng isang pagbabayad ng kapasidad para sa paghawak ng isang tukoy na halaga ng kapasidad ng load shed na magagamit para sa mga kaganapan sa DR sa isang window ng oras sa hinaharap. Pangalawa, kung ang isang kaganapan ay tinawag sa panahon ng window ng hinaharap na oras ang isang pagbabayad ng enerhiya ay maaaring gawin para sa load na nalaglag sa tagal ng kaganapan.
Disenyo ng Rate	Ang mga kalahok sa programa ay gumagawa ng isang bid na "nominasyon ng kapasidad" na nagpapahiwatig ng kapasidad ng pag-load na nais nilang hawakan bilang magagamit sa isang bukas na oras ng window. Maaari ring isama sa bid ang insentibo na pinagsama-sama ng pinagsama-sama / kostumer para sa load na nalaglag sa ibaba ng halagang baseline. Sa mga merkado ng utility ang pasalig sa kakayahan ay karaniwang para sa susunod na buwan ng kalendaryo, kahit na mas matagal ang mga time frame na ginagamit sa mga merkado ng ISO. Bilang bahagi ng nominasyon ng kapasidad, maaaring pumili ang customer sa pagitan ng isang bilang ng mga katangian kabilang ang pang-abiso o araw-ng abiso at ang window ng tagal ng kaganapan (tulad ng 1-4 na oras, 2-6 na oras,…). Ginagawa ang isang pagbabayad ng kakayahan sa customer para sa paunang pagtatalaga na ito kahit na walang mga kaganapan na tinawag sa window ng oras. Kung ang isang kaganapan ay tinawag sa oras ng window ng oras ang customer ay maaaring makatanggap ng isang pagbabayad ng enerhiya para sa pag-load ng karga na may kaugnayan sa isang baseline, subalit ang mga parusa ay maaaring mailapat kung mas mababa kaysa sa paunang nakagawa na kapasidad na malaglag ay naihatid sa oras na tawagan ang kaganapan.
Target na Customer	-Aggregator at pinagsamang sarili ng mga customer ng C&I
Mga Target na Pag-load	- Anumang

Prerequisite	-Ang customer ay dapat na mayroong pagsukat ng agwat Ang mga customer ng C & I ay maaaring kailangang matugunan ang isang demand o pamantayan sa pag-bid
Programa ng Frame ng Oras	-Anumang oras
Mga Pagpipigil sa Kaganapan	-Karaniwang Lunes hanggang Biyernes, hindi kasama ang mga piyesta opisyal, na may kasunod na mga kaganapan sa araw na karaniwang pinapayagan
Mga Araw ng Kaganapan	-Karaniwan isang maximum na 30 oras bawat buwan
Tagal ng Kaganapan	-Karaniwan sa panahon ng isang nakapirming window ng oras para sa lahat ng mga kaganapan sa panahon ng pinakamataas na oras ng pagkonsumo ng enerhiya ng araw.). Ang tagal ng kaganapan ay nag-iiba sa pamamagitan ng pangako ng kakayahan ng customer na may mga kagustuhan mula sa 1 hanggang 8 oras o tulad ng tinukoy ng disenyo ng programa
Abiso	-Day-maaga o araw-ng depende sa mga kagustuhan sa pasalig ng kakayahan ng customer o ang disenyo ng programa
Pagpipilian sa Pag-uugali	-Karaniwan na ang mga customer ay mag-opt-in sa mga kaganapan na ibinigay na dahil mayroon silang paunang naisagawa na kapasidad ng pag-load.
Sertipikasyon Mga kaganapan	-Karaniwan dalawa bawat taon (Pagsubok)

Mga Katangian ng OpenADR para sa Mga Programa sa Pag-bid sa Kapasidad

Mga Senyas sa Kaganapan	–Isang SIMPLE signal na may mga antas 1 hanggang 3 na nai-map sa dami ng na-load na load. Kung sinusuportahan lamang ng programa ang isang solong antas ng pag-load ng pag-load, dapat itong ma-map sa antas 1. Para sa mga program na may maraming mga antas ng pag-load ng pag-load, ang pinakamaliit na pagbabago mula sa normal na operasyon ay dapat na ma-map sa antas 1, kasama ang mga halaga ng pag-load ng load na nai-map sa mga antas 2 at 3 sa pagtaas ng antas ng pag-load ng pag-load. -Kung sinusuportahan ng paglawak ang B profile mga VEN, bilang karagdagan sa signal na SIMPLE, maaaring maisama ang isang signal na BID_LOAD at / o BID_PRICE sa payload na may mga uri ng signal ng setpoint at presyo, at mga yunit ng powerReal at currencyPerKW ayon sa pagkakabanggit. Masasalamin ng BID_LOAD ang hiniling na pag-load na ibinuhos sa pag-bid na halaga ng kapasidad ng pinagsama-sama / customer, at ang BID_PRICE ay magpapakita ng insentibo na bid ng pinagsama-sama / customer. Tingnan ang Annex A para sa datingamples.
Mga tugon sa Pagpipilian	-VTNs na nagpapadala ng mga kaganapan dapat itakda ang elemento ng oadrResponseRequired na "palaging", na nangangailangan ng VEN na tumugon sa isang optIn o optOut -Bilang isang pinagsama-sama / customer ay may paunang nakatuon na kakayahan Dapat tumugon ang mga VEN sa optIn. Maaaring magpadala ng isang opt out bilang tugon sa kaganapan, ngunit ito ay isang pahiwatig na impormal na kakayahang magamit, hindi isang pormal na pag-opt out sa kaganapan. -Ang oadrCreateOpt payload ay karaniwang hindi gagamitin upang maging karapat-dapat sa mga mapagkukunang kasali sa mga kaganapan tulad ng karaniwang pag-load ay isang solong pinagsamang entity.
Kaganapan Descriptor	-Ang kaganapan dapat itakda ang prioridad sa 1 maliban kung ang mga patakaran ng programa o pagsasaayos ng VTN ay tumutukoy sa ibang paraan –Maaaring magamit ang mga kaganapan sa pagsubok na may mga programa sa Pag-bid sa Kapasidad. Kung pinapayagan sila, ang elemento ng testEvent ay dapat itakda sa "totoo" upang ipahiwatig ang kaganapan sa pagsubok. Kung ang karagdagang impormasyon na may parameter na kinakailangan sa sangkap na ito maaari itong sundin ang "totoo" na pinaghihiwalay ng isang puwang na may karagdagang impormasyong ito.
Panahon ng Aktibo ng Kaganapan	– eiRampPataas, eiRec Recovery, mga elemento ng pagpapaubaya ay karaniwang hindi ginagamit
Mga baseline	–Karaniwang hindi kasama ang mga baseline sa payload ng kaganapan dahil ang data na ito ay karaniwang hindi magagamit sa oras na pinasimulan ang kaganapan. Gayunpaman, ang parehong mga kagamitan at pinagsama-sama / kostumer ay gagawin view ang pagsasama ng baseline na impormasyon sa mga kaganapan na kapaki-pakinabang.
Pag-target sa Kaganapan	Karaniwang hindi naiiba ang mga programa sa Pag-bid sa Kapasidad sa pagitan ng mga mapagkukunan para sa isang naibigay na customer. Karaniwang tinutukoy ng pag-target ang venID, na nagpapahiwatig na ang lahat ng mga mapagkukunang nauugnay sa VEN ay dapat lumahok, o may kasamang isang resourceID na kinatawan ng pinagsamang load nauugnay kay VEN.
Mga Serbisyo sa Pag-uulat	Karaniwang nangangailangan ng mga ulat ng TELEMETRY_USAGE ng mga programa ang Pag-bid sa Kapasidad ng ISO na may mga puntos ng data ng powerReal. Tingnan ang datingamples sa Annex A. Ang pag-uulat ng telemetry para sa utility na karaniwang Pag-bid sa Kapasidad ay hindi kinakailangan. Tandaan na ang pag-uulat ng telemetry ay nangangailangan ng B profile Mga VEN. Sumangguni sa Annex B para sa datingamples ng mga ulat mula sa mga pilot ng utility na maaaring mailalapat sa ganitong uri ng programa.
Mga Serbisyo sa Pagpipilian	–Paggamit ng serbisyo ng Opt upang makipag-usap ng pansamantalang mga iskedyul ng pagkakaroon karaniwang hindi gagamitin bilang bahagi ng isang programa sa Pag-bid sa Kapasidad habang ang mga customer ay paunang nakatuon sa kanilang kakayahang magamit. Gayunpaman, ang serbisyong ito ay maaaring maging kapaki-pakinabang bilang isang impormal na paraan para sa mga kalahok na ipahiwatig ang isang kakulangan ng kakayahang magamit para sa mga kadahilanang pinapatay tulad ng pagkabigo ng kagamitan.
Mga Serbisyo sa Rehistro	Mga agwat ng botohan hiniling ng VTN para sa mga tipikal na programa na pang-araw ay hindi kinakailangan na maging mas madalas na minsan sa isang oras. Gayunpaman, ang paggamit ng botohan para sa pagtuklas ng tibok ng puso o pang-araw na mga programa ay maaaring mangailangan ng mas madalas na botohan.

Programa ng Residential Thermostat

Ang program na ito ay kinatawan ng Direct Load Control (DLC) kung saan ang signal ng Demand Response ay direktang nagbabago sa pag-uugali ng mga mapagkukunan ng pag-load ng pag-load, nang walang isang layer ng abstraction sa pagitan ng pagtanggap ng signal at ang partikular na pagkilos na nagpapadanak ng pagkarga.

Mga Katangian ng Programa ng Residential Thermostat DR

Mag-load ng Profile Layunin	-Peak magbawas ng demand
Pangunahing Mga Driver	-Nabawas ang mga paggasta sa kapital at nabawasan ang mga gastos sa enerhiya
Paglalarawan ng Programa	-Kapag sinusunod o inaasahan ng mga utility ang mataas na presyo ng maramihang pakyawan o mga kundisyon ng emergency system, maaari silang magpasimula ng isang kaganapan na nagbabago sa pag-uugali ng programmable na pakikipag-usap ng termostat (PCT) ng customer sa isang tinukoy na tagal ng panahon (hal, 3 pm — 6 pm sa isang mainit summer weekday) upang mabawasan ang pagkonsumo ng enerhiya. -Ang pagbabago sa pag-uugali ng PCT bilang tugon sa kaganapan ay maaaring isang simpleng pagbabago sa setpoint ng temperatura para sa tagal ng kaganapan o isang mas kumplikadong hanay ng mga pagbabago, kabilang ang paunang paglamig, na binabawasan ang epekto ng kaganapan sa ginhawa ng customer antas
Insentibo sa Customer	-Ang mga intentibo ay kumukuha ng dalawang pangkalahatang anyo. Una, ang mga customer ay maaaring bigyan ng isang libreng PCT o inaalok na mga diskwento / rebate sa mga binili ng PCT ng customer bilang isang insentibo na magpatala sa programa ng DR. Pangalawa, ang mga customer ay maaaring makatanggap ng isang patuloy na taunang bayad para sa patuloy na pagpapatala sa programa. Hindi gaanong pangkaraniwan ang patuloy na mga insentibo na binabayaran sa mga customer batay sa aktwal na pagbawas ng enerhiya sa mga kaganapan.
Disenyo ng Rate	-Primarily isang insentibo na programa, kung saan ang mga customer ay tumatanggap ng mga diskwento o libreng PCT para sa pagpapatala sa programa ng DR. Ang ilang mga programa ay maaaring magbayad ng isang pana-panahong stipend o insentibo na pagbabayad batay sa pagbawas ng enerhiya sa mga kaganapan.
Target na Customer	-Mga Kapanlalahanan
Target na Pag-load	-HVAC
Prerequisite	-Karaniwan wala, dahil ang mga customer ay tumatanggap ng isang PCT bilang bahagi ng pagpapatala ng programa
Programa ng Frame ng Oras	-Karaniwang sumasaklaw sa mga buwan ng taon kung saan nangyayari ang pinakamataas na pagkonsumo ng enerhiya, kahit na maaaring buong taon sa ilang mga kaso.
Mga Pagpipigil sa Kaganapan	-Karaniwang Lunes hanggang Biyernes, hindi kasama ang mga piyesta opisyal, na may kasunod na mga kaganapan sa araw na karaniwang pinapayagan.
Mga Araw ng Kaganapan	-Karaniwan na 9 hanggang 15 bawat taon
Tagal ng Kaganapan	-Maaaring mangyari ang mga kaganapan sa anumang oras, na may tagal na 2 hanggang 4 na oras, bagaman karaniwang nangyayari ang mga kaganapan sa panahon ng pinakamataas na oras ng pagkonsumo ng enerhiya sa araw.
Abiso	-Karaniwan na araw sa unahan, kahit na ang ilang mga programa ay maaaring may mga oras ng abiso na kasing liit ng 10 minuto.
Pagpipilian sa Pag-uugali	-Ang mga customer ay hindi kinakailangang lumahok sa mga kaganapan, gayunpaman awtomatiko silang mag-opt in sa mga kaganapan maliban kung gumawa sila ng pagkilos upang ma-override ang kaganapan o gumawa ng manu-manong pagsasaayos sa temperatura sa panahon ng kaganapan.
Sertipikasyon Mga kaganapan	-Karaniwan wala

OpenADR Mga Katangian para sa Mga Programa sa Residential Therostat

Mga Senyas sa Kaganapan	–Isang SIMPLE signal na may mga antas na 1 hanggang 3 na nai-map sa pagbabago ng mga offset na setpoint ng temperatura ng PCT o thermostatic cycling percentage . Kung ang isang programa ng tirahan na termostat ay may isang solong bahagi ng offset / pagbibisikleta dapat itong ma-map sa antas 1. Para sa mga program na may maraming bahagi ng offset / pagbibisikleta, ang pinakamaliit na pagbabago mula sa normal na operasyon ay dapat na ma-map sa antas 1, kasama ang iba pang mga halaga ng offset / pagbibisikleta na-map sa mga antas 2 at 3 sa pagtaas ng antas ng epekto ng pag-load ng load. -Kung sinusuportahan ng paglawak ang B profile mga VEN, bilang karagdagan sa signal ng SIMPLE, maaaring maisama ang isang signal na LOAD_CONTROL sa payload na may isang uri ng x-loadControlLevelOffset o x-loadControlCapacity upang tukuyin ang nais na temperatura setpoint offset o thermostatic cycling percentage ayon sa pagkakabanggit. Inirekomenda na a uri ng yunit ng "temperatura" ng ginamit sa mga payload na gumagamit ng x-loadControlLevelOffset signalType upang ipahiwatig ang Celsius o Fahrenheit para sa offset. Tingnan ang Annex A para sa datingamples.
Mga tugon sa Pagpipilian	-VTNs na nagpapadala ng mga kaganapan dapat itakda ang elemento ng oadrResponseRequired na "palaging", na nangangailangan ng VEN na tumugon sa isang optIn o optOut – Ang mga VEN ay Dapat tumugon sa optIn maliban kung mayroong ilang partikular na pagkilos na labis na pag-override na kinuha ng customer. -Ang Ang oadrCreateOpt na payload ay maaaring magamit ng mga VEN upang maging karapat-dapat sa pakikilahok ng mga mapagkukunan sa isang kaganapan. Halimbawa, maaaring ma-target ng isang kaganapan ang resourceID's ng dalawang termostat na kumokontrol sa magkakahiwalay na mga sistema ng HVAC. Kung magpasya ang customer na isa lamang sa mga sistema ng HVAC ang maaaring lumahok sa kaganapan, makikipag-usap ito sa VTN gamit ang oadrCreateOpt payload. Tandaan na ang oadrCreateOpt payload ay suportado lamang ng B profile Mga VEN
Kaganapan Descriptor	-Ang kaganapan dapat itakda ang prioridad sa 1 maliban kung ang mga patakaran ng programa o pagsasaayos ng VTN ay tumutukoy sa ibang paraan –Karaniwang hindi ginagamit ang mga kaganapan sa pagsubok kasama ang mga programa ng Residential Thermostat. Gayunpaman kung pinapayagan sila ay dapat itakda ang elemento ng testEvent sa "totoo" upang ipahiwatig ang kaganapan sa pagsubok. Kung ang karagdagang impormasyon na may parameter na kinakailangan sa sangkap na ito maaari itong sundin ang "totoo" na pinaghihiwalay ng isang puwang na may karagdagang impormasyong ito.
Panahon ng Aktibo ng Kaganapan	–Karaniwang ginagamit ang Randomization para sa mga kaganapan sa termostat ng tirahan gamit ang elemento ng pagpapaubaya – eiRampKaraniwang hindi ginagamit ang mga elemento ng pataas at eiRec Recovery
Mga baseline	–Karaniwang hindi kasama ang mga baseline sa payload ng kaganapan
Pag-target sa Kaganapan	-Target ng mga programa ng Residential Thermostat ang mga mapagkukunan ng HVAC na kinokontrol ng PCTs. Karaniwang tumutukoy ang pag-target sa mga resourceID ng mga sistema ng HVAC (ibig sabihin, ang termostat) na nauugnay sa VEN o ang venID na may target na klase ng aparato ng signal ng aparato na nakatakda sa Therostat
Mga Serbisyo sa Pag-uulat	–Karaniwang hindi ginagamit ang pag-uulat ng telemetry dahil hindi ito ganap na kinakailangan para sa mga programang paninirahan sa termostat Sumangguni sa Annex B para sa datingamples ng mga ulat mula sa mga pilot ng utility na maaaring mailalapat sa ganitong uri ng programa.
Mga Serbisyo sa Pagpipilian	–Paggamit ng serbisyo ng Opt upang makipag-usap ng pansamantalang mga iskedyul ng pagkakaroon karaniwang hindi gagamitin bilang bahagi ng isang programa ng CPP.
Mga Serbisyo sa Rehistro	Mga agwat ng botohan hiniling ng VTN para sa mga tipikal na programa sa Residential Thermostat na bukas pa ay hindi kinakailangan na maging mas madalas na minsan sa isang oras. Gayunpaman, ang paggamit ng botohan para sa pagtuklas ng tibok ng puso ay maaaring mangailangan ng mas madalas na botohan tulad ng mga programa ng termostat ng tirahan na may mas maiikling oras ng pag-abiso.

Mabilis na DR Dispatch

Mabilis na Mga Katangian ng Program na Dispatch ng DR

Mag-load ng Profile Layunin	-Mga mapagkukunang mapagkukunan upang makamit ang tugon sa pag-load sa "real-time"
Pangunahing Mga Driver	-Grid pagiging maaasahan at mga serbisyong pandagdag
Paglalarawan ng Programa	Ang Mabilis na DR ay ginagamit ng ISO / utilities upang makakuha ng paunang nakatuon na pagtugon sa pag-load sa "real-time". Ang paunang nagawa na tugon sa pag-load ay ginagamit ng ISO / utilities kapag naobserbahan nila ang mga kundisyon na nangangailangan ng agarang pagkilos upang mapanatili ang katatagan at integridad ng grid. Ang ibig sabihin ng real-time na ang mga mapagkukunan ay karaniwang naipadala na may isang latency mula 10 minuto para sa mga mapagkukunan na ginagamit bilang mga reserba hanggang 2 segundo para sa mga mapagkukunan na ginagamit para sa mga layuning pang-regulasyon. Ang laki ng tugon sa pag-load ay dapat sapat na malaki upang makagawa ng isang pagkakaiba sa pagpapagaan ng kundisyon ng grid at sa gayon ang mga mapagkukunan ay karaniwang napakalaki at madalas na pinamamahalaan ng mga pinagsama bilang bahagi ng pinagsamang mapagkukunan. Ang mga pinakamaliit na laki para sa pag-load ng tugon para sa isang mapagkukunan upang maging kwalipikado upang lumahok sa mga serbisyong pandagdag ay karaniwang nasa paligid ng 500 kW, ngunit maaaring maging kasing baba ng 100 kW para sa ilang mga programa. Tandaan na kung ang mapagkukunan ay ginamit bilang isang reserba ito ay karaniwang tatawagin upang bawasan (ibig sabihin malaglag) ang pagkarga, ngunit kung ginagamit ito para sa mga layuning pang-regulasyon maaari itong maipadala upang madagdagan o bawasan ang pagkarga.
Insentibo sa Customer	Karaniwang tumatanggap ang mga agregator / customer ng dalawang uri ng mga insentibo. Una, nakatanggap sila ng isang pagbabayad para sa paggawa at pag-aalok ng isang tukoy na halaga ng pagtugon sa pag-load na magagamit para sa mga kaganapan sa DR sa isang window ng oras sa hinaharap. Ang dami ng tugon sa pag-load, ang window ng oras ng pagkakaroon at ang halagang babayaran ay karaniwang itinatakda ng pinagsama-sama / customer. Pangalawa, kung ang isang kaganapan ay tinawag sa window ng hinaharap na oras ng isang pagbabayad batay sa dami ng tugon sa pag-load sa tagal ng kaganapan.
Disenyo ng Rate	Ang mga kalahok sa programa ay nagsumite ng isang bid na nagpapahiwatig ng tugon sa pag-load na nais nilang gawing magagamit sa panahon ng window ng hinaharap. Karaniwang may kasamang pagbabayad din ang bid na handang tanggapin ng pinagsama-sama / customer para sa tugon sa pag-load. Sa mga merkado ng utility / ISO ang bid ay karaniwang isinumite alinman sa araw na maaga o sa araw ng tagal ng panahon kung saan ginagawa ang pangako. Bilang bahagi ng kanilang kwalipikasyon at pagpaparehistro sa mga merkado iba't ibang mga parameter ng sobre ng pagganap ay nauugnay sa mapagkukunan tulad ng ramp rate at min at max na mga limitasyon sa pagpapatakbo. Ang nasabing mga parameter ay namamahala kung paano ito ipapadala. Kung tatanggapin ang tawad ng isang kalahok ay maaaring magawa ang isang pagbabayad sa customer para sa kanilang paunang pagtatalaga kahit na walang mga kaganapan na tinawag sa window ng oras. Kung ang isang kaganapan ay tinawag sa oras ng window ng oras ang customer ay maaaring makatanggap ng mga karagdagang pagbabayad para sa kanilang pagganap sa panahon ng kaganapan. Ang nasabing mga pagbabayad batay sa pagganap ay maaaring batay sa isang bilang ng mga kadahilanan kabilang ang dami ng lakas, lakas, gaano kalapit ang pagsunod ng mapagkukunan sa mga tagubilin sa pagpapadala, at isang pagbabayad na "agwat ng mga milyahe" na sumasalamin kung magkano ang kanilang load profile ay kinakailangan upang baguhin sa panahon ng kaganapan. Ang ilan sa mga parameter na ito tulad ng enerhiya at lakas ay maaaring may paggalang sa isang baseline.
Target na Customer	-Aggregator at pinagsamang sariling mga customer ng C&I
Mga Target na Pag-load	- Ang mga maaaring tumugon sa mga real-time na pagpapadala.

Prerequisite	-Ang customer ay dapat na mayroong pagsukat ng agwat -Kailangang matugunan ang mga kinakailangan sa maliit na laki para sa tugon sa pag-load -Marapat na tumugon sa mga real-time na pagpapadala -Karaniwan na kailangang magbigay ng real-time na telemetry na nagpapakita ng kasalukuyang tugon sa pag-load
Programa ng Frame ng Oras	-Anumang oras
Mga Pagpipigil sa Kaganapan	-wala
Mga Araw ng Kaganapan	-wala
Tagal ng Kaganapan	-Karaniwang maikli (mas mababa sa 30 minuto), ngunit sa anumang kaso ay hindi lalampas sa window ng oras na ginawang magagamit ng kalahok ang mapagkukunan nang isumite nila ang kanilang bid.
Abiso	-wala
Pagpipilian sa Pag-uugali	-Mga customer ay nag-opt in sa mga kaganapan sa pamamagitan ng default na ibinigay na mayroon silang paunang paunang nakatuon na tugon sa pag-load
Sertipikasyon Mga kaganapan	-M Karaniwang isa bawat taon (Pagsubok)

Mga Katangian ng OpenADR para sa Mga Programa sa Pag-bid sa Kapasidad

Mga Senyas sa Kaganapan	–Isang SIMPLE signal na may mga antas 1 hanggang 3 na nai-map sa dami ng tugon sa pag-load. Kung sinusuportahan lamang ng programa ang isang solong antas ng pagtugon sa pag-load, dapat itong ma-map sa antas 1. Para sa mga program na may mutiple na antas ng pagtugon sa pag-load, ang pinakamaliit na pagbabago mula sa normal na operasyon ay dapat na ma-map sa antas 1, kasama ang mga halaga ng load na nalaglag na na-map sa mga antas 2 at 3 sa pagtaas ng antas ng tugon sa pag-load. -Kung sinusuportahan ng paglawak ang B profile mga VEN, bilang karagdagan sa signal ng SIMPLE, maaaring maisama ang isang pagpapadala sa anyo ng isang LOAD_DISPATCH signal sa payload na may mga uri ng signal ng setpoint o delta, at mga yunit ng powerReal. Ang senyas na ito ay kumakatawan sa nais na "operating point" ng pagkarga at maaaring ipahayag alinman sa isang ganap na halaga ng mW (ie setpoint) o ilang kamag-anak na bilang ng mW (ie delta) mula sa kasalukuyang mapagkukunang operating point. Tingnan ang Annex A para sa datingamples.
Mga tugon sa Pagpipilian	-VTNs na nagpapadala ng mga kaganapan dapat itakda ang elemento ng oadrResponseRequired na "palaging", na nangangailangan ng VEN na tumugon sa isang optIn o optOut -Bilang isang pinagsama-sama / customer ay may paunang nakatuon na kakayahan Dapat tumugon ang mga VEN sa optIn. Maaaring magpadala ng isang opt out bilang tugon sa kaganapan, ngunit ito ay isang pahiwatig na impormal na kakayahang magamit, hindi isang pormal na pag-opt out sa kaganapan. -Ang oadrCreateOpt payload ay karaniwang hindi gagamitin upang maging karapat-dapat sa mga mapagkukunang kasali sa mga kaganapan tulad ng karaniwang pag-load ay isang solong pinagsamang entity.
Kaganapan Descriptor	-Ang kaganapan dapat itakda ang prioridad sa 1 maliban kung ang mga patakaran ng programa o pagsasaayos ng VTN ay tumutukoy sa ibang paraan –Maaaring magamit ang mga kaganapan sa pagsubok, lalo na sa panahon ng pagpaparehistro at kwalipikasyon ng isang mapagkukunan. Kung pinapayagan sila, ang elemento ng testEvent ay dapat itakda sa "totoo" upang ipahiwatig ang kaganapan sa pagsubok. Kung ang karagdagang impormasyon na may parameter na kinakailangan sa sangkap na ito maaari itong sundin ang "totoo" na pinaghihiwalay ng isang puwang na may karagdagang impormasyong ito.
Panahon ng Aktibo ng Kaganapan	– Hindi ginagamit ang mga elemento ng pagpaparaya. Ang eiRampAng mga panahon ng pataas at eiRec Recovery ay karaniwang bahagi ng mga parameter ng isang mapagkukunan kapag nagparehistro sila at maaaring magamit. Dahil sa likas na katangian ng mga pagpapadala maaari silang maging bukas na natapos at sa gayon ay maaaring walang oras ng pagtatapos para sa kaganapan.
Mga baseline	–Karaniwang hindi kasama ang mga baseline sa payload ng kaganapan dahil ang data na ito ay karaniwang hindi magagamit sa oras na pinasimulan ang kaganapan. Gayunpaman, ang parehong mga kagamitan at pinagsama-sama / kostumer ay gagawin view ang pagsasama ng baseline na impormasyon sa mga kaganapan na kapaki-pakinabang.
Pag-target sa Kaganapan	Karaniwang hindi naiiba ang mga programa sa Pag-bid sa Kapasidad sa pagitan ng mga mapagkukunan para sa isang naibigay na customer. Karaniwang tinutukoy ng pag-target ang venID, na nagpapahiwatig na ang lahat ng mga mapagkukunang nauugnay sa VEN ay dapat lumahok, o may kasamang isang resourceID na kinatawan ng pinagsamang load nauugnay kay VEN.
Mga Serbisyo sa Pag-uulat	Karaniwang nangangailangan ang mga programa ng Mabilis na DR ng mga ulat ng TELEMETRY_USAGE na may mga puntos ng data ng powerReal. Inilalarawan ng ulat sa paggamit ang mga kasalukuyang mapagkukunan ng operating point at ginagamit ng Utility / ISO upang matukoy kung gaano kalapit ang pagsunod ng mapagkukunan sa ipinadala na tagubilin. Sa ilang mga kaso ang telemetry ay maaaring magsama ng iba pang mga puntos ng data tulad ng voltage pagbasa at pagsingil ng estado (ie enerhiya) sa kaso kung saan ang mga mapagkukunan ay ilang uri ng pag-iimbak. Sa ilang mga kaso ang dalas ng pag-uulat ay maaaring maging kasing taas ng bawat 2 segundo. Tandaan na ang pag-uulat ng telemetry ay nangangailangan ng B profile Mga VEN. Tingnan ang Annex A para sa datingamples. Sumangguni rin sa Annex B para sa datingamples ng mga ulat mula sa mga pilot ng utility na maaaring mailalapat sa ganitong uri ng programa.
Mga Serbisyo sa Pagpipilian	–Paggamit ng serbisyo ng Opt upang makipag-usap pansamantalang pagkakaroon mga iskedyul karaniwang hindi gagamitin dahil ang mga customer ay paunang nakatuon sa kanilang kakayahang magamit. Gayunpaman, ang serbisyong ito ay maaaring maging kapaki-pakinabang bilang isang impormal na paraan para sa mga kalahok na ipahiwatig ang isang kakulangan ng kakayahang magamit para sa mga kadahilanang pinapatay tulad ng pagkabigo ng kagamitan.
Mga Serbisyo sa Rehistro	Dahil sa mababang kinakailangan ng latency ng mga real-time na pagpapadala push pattern ng pakikipag-ugnayan lamang ang ginagamit.

Programa ng Oras ng Paggamit (TOU) ng Residential Electric Vehicle (EV) Oras ng Paggamit

Mga Katangian ng Programa ng Residential EV TOU

Mag-load ng Profile Layunin	Ang isang istraktura ng rate na kung saan ang gastos ng pagsingil ng mga de-koryenteng sasakyan ay binago upang maging sanhi ng mga consumer na ilipat ang mga pattern ng pagkonsumo.
Pangunahing Mga Driver	Ang mga lakas ng tirahan ay gumagamit ng mga tuktok sa gabi. Dahil ang pagsingil ng EV ay tumatagal ng 4-8 na oras, maaari itong maantala nang ilang oras upang ilipat ang mga pagtaas ng pag-load.
Paglalarawan ng Programa	Ang mga kustomer na mayroong de-koryenteng sasakyan ay maaaring mag-sign up para sa rate ng Electric Vehicle Time-of-Use (EV-TOU) na rate at makatanggap ng mas mababang mga rate para sa pagsingil sa kanilang sasakyan sa oras na wala sa rurok, tulad ng sa pagitan ng hatinggabi at 5 AM na mga rate ng EV-TOU ay inaalok upang hikayatin ang mga customer na limitahan ang pang-araw-araw na paggamit ng kuryente, kung ang demand para sa elektrisidad ay pinakamataas.
Insentibo sa Customer	Mas mura ang singilin para sa mga EV.
Disenyo ng Rate	TOU na may kalagitnaan ng rurok ng umaga, umaga at gabi na kalagitnaan ng rurok, at 12 AM-5AM na off-peak
Target na Customer	EV May-ari na may isang load profile na ang taluktok sa gabi.
Mga Target na Pag-load	EV Charger
Prerequisite	Dapat mayroong isang matalinong metro at EV ang customer
Programa ng Frame ng Oras	Buong taon
Mga Pagpipigil sa Kaganapan	wala
Mga Araw ng Kaganapan	Araw-araw, o karaniwang araw lamang
Tagal ng Kaganapan	5-8 na oras
Abiso	Naabisuhan ang customer tungkol sa mga tier ng presyo sa kanilang buwanang singil, at ang VTN ay nagpapadala ng mga signal ng kaganapan nang maaga.
Pagpipilian sa Pag-uugali	Maaaring baguhin ng mga Ratepayer ang kanilang rate plan tulad ng karaniwang gagawin nila sa isang utility.
Sertipikasyon Mga kaganapan

OpenADR Mga Katangian para sa Residential na EV TOU Programs

Mga Senyas sa Kaganapan	Ang mga signal ng ELECTRICITY_PRICE na may tunay na mga tier ng presyo, pati na rin mga SIMPLE signal upang payagan ang pakikilahok ng 2.0a VENs Tingnan ang Annex A para sa datingamples.
Mga tugon sa Pagpipilian	Laging optIn ng mga VEN
Kaganapan Descriptor	Isang kaganapan bawat linggo, na may mga agwat ng kaganapan para sa bawat antas ng presyo
Panahon ng Aktibo ng Kaganapan	Hindi bababa sa 24 na oras na abiso ang dapat gamitin. Dapat makuha ng bawat agwat ng kaganapan ang antas ng rate ng TOU
Mga baseline	N/A
Pag-target sa Kaganapan	Walang kinakailangang advanced na pag-target, ang pag-target lamang sa antas ng VEN.
Mga Serbisyo sa Pag-uulat	Hindi kinakailangan ng pag-uulat, ang lahat ng data ay maaaring magmula sa metro. Sumangguni sa Annex B para sa datingamples ng mga ulat mula sa mga pilot ng utility na maaaring mailalapat sa ganitong uri ng programa.
Mga Serbisyo sa Pagpipilian	Ang mga serbisyo sa pag-opt ay hindi maiugnay sa uri ng program na ito.
Mga Serbisyo sa Rehistro	Ang mga mamimili ay paunang maglalaan ng kanilang VEN ng utility upang makatanggap ng mga signal ng pagpepresyo.

Public Station Electric Vehicle (EV) Programang Pagpepresyo ng Real-Time

Mga Katangian ng Programa ng Public Station EV RTP

Mag-load ng Profile Layunin	Ang isang aktibidad ng pagtugon sa demand na kung saan ang gastos ng pagsingil ng mga sasakyang de-kuryente ay binago upang ilipat ang mga katotohanan ng pinakamataas na pagpepresyo sa mga consumer.
Pangunahing Mga Driver	Ang presyo ng kuryente ay variable sa isang araw. Nilalayon ng program na ito na mas mahusay na maitugma ang presyo ng singilin sa gastos ng kuryente.
Paglalarawan ng Programa	Ang mga pampublikong charger ay maaaring mayroon sa mga lugar ng trabaho, sa mga pampublikong paradahan, at sa mga tingiang tindahan. Ipinapasa ng program na ito ang mga presyo ng real-time sa mga potensyal na charger bago sila mag-plug in, upang makagawa sila ng isang kaalamang desisyon tungkol sa kung sisingilin o hindi ang kanilang kotse.
Insentibo sa Customer	Hindi gaanong mamahaling singilin sa mga oras na wala sa rurok.
Disenyo ng Rate	Maaaring magbago ang mga presyourly, ngunit sa sandaling pipiliin ng isang customer na mag-plug sa kanilang kotse, ang rate ay nakatakda para sa tagal ng pagsingil.
Target na Customer	Sinumang may EV na kailangang singilin habang wala sa bahay.
Mga Target na Pag-load	Mga Public Charger na EV
Prerequisite	Ang mga EV charger ay dapat na konektado sa internet at sertipikado ng OpenADR2.0b, o konektado sa isang OpenADR2.0b VEN gateway.
Programa ng Frame ng Oras	Buong taon
Mga Pagpipigil sa Kaganapan	wala
Mga Araw ng Kaganapan	Araw-araw, o karaniwang araw lamang
Tagal ng Kaganapan	1 oras o mas mahaba
Abiso	Naabisuhan ang customer tungkol sa umiiral na rate kapag pumipili na mag-plug sa kanilang kotse.
Pagpipilian sa Pag-uugali	Ang mga customer ay maaaring mag-opt out sa pamamagitan ng pagpapasya na hindi singilin.
Sertipikasyon Mga kaganapan

OpenADR Mga Katangian para sa Public Station EV RTP Programs

Mga Senyas sa Kaganapan	Signal ng ELECTRICITY_PRICE na may mga presyo. Tingnan ang Annex A para sa datingamples.
Mga tugon sa Pagpipilian	Laging optIn ng mga VEN
Kaganapan Descriptor	Ang mga kaganapan ay dapat na magkadikit, at naglalaman ng isang agwat.
Panahon ng Aktibo ng Kaganapan	Hindi bababa sa 1 oras na abiso ang dapat gamitin, subalit ang mga utility ay maaaring pumili na gumamit ng paunang abiso.
Mga baseline	N/A
Pag-target sa Kaganapan	Walang kinakailangang advanced na pag-target, ngunit maaaring magamit ang pag-target upang magpadala ng mga presyo sa mga tukoy na transformer, feeder, o heyograpikong lugar.
Mga Serbisyo sa Pag-uulat	Hindi kinakailangan ng pag-uulat, ngunit maaaring magamit kung ninanais. Sumangguni sa Annex B para sa datingamples ng mga ulat mula sa mga pilot ng utility na maaaring mailalapat sa ganitong uri ng programa.
Mga Serbisyo sa Pagpipilian	Ang mga serbisyo sa pag-opt ay hindi maiugnay sa uri ng program na ito.
Mga Serbisyo sa Rehistro	Ang isang nagbebenta ng istasyon ng singilin ay magkakaloob ng kanilang mga aparato ng VTN ng isang utility.

Naipamahagi na Program na Pinagkaloob na Mga mapagkukunang enerhiya (DER)

Ang sumusunod na paglalarawan ng programa ay mapaghula at batay sa isang papel sa pagsasaliksik (sanggunian ang papel ni Rish) na naglalarawan kung paano magagamit ng mga kostumer ng utility ang mga mapagkukunang imbakan ng DER upang lumahok sa mga programa ng DR tulad ng mga programa sa real time pricing (RTP).

Mga Katangian ng Program na Naipamahagi na Mga Mapagkukunang Enerhiya (DER)

Mag-load ng Profile Layunin	Isang aktibidad ng pagtugon sa demand na ginamit upang makinis ang pagsasama ng ibinahagi na mga mapagkukunan ng enerhiya sa smart grid.
Pangunahing Mga Driver	-Nabawas ang mga paggasta sa kapital at nabawasan ang mga gastos sa enerhiya
Paglalarawan ng Programa	Ang mga kustomer na may mga mapagkukunang DER na maaaring mag-ani ng enerhiya at maiimbak ay maaaring mabawasan ang gastos ng pagbili ng kuryente mula sa grid sa panahon ng mataas na presyo sa pamamagitan ng unang paggamit ng nakaimbak na mga mapagkukunan ng enerhiya, na sinusundan ng pagpapatupad ng mga diskarte sa pag-load ng pag-load
Insentibo sa Customer	Kakayahang kontrolin ang mga gastos sa mga oras ng mataas na presyo ng kuryente sa pamamagitan ng paggamit ng nakaimbak na enerhiya na nabuo sa pamamagitan ng PV o iba pang paraan at pagpapatupad ng mga diskarte sa pagpapadanak ng karga
Disenyo ng Rate	Ang mga rate ng kuryente ay nag-iiba sa mga presyo ng pakyawan sa merkado o isang taripa na nag-iiba bilang isang pagpapaandar ng oras ng araw, panahon, o temperatura
Target na Customer	Ang mga customer na may mapagkukunan ng pag-iimbak ng enerhiya
Mga Target na Pag-load	Anuman
Prerequisite	Mga mapagkukunan ng pag-iimbak ng enerhiya
Programa ng Frame ng Oras	Kahit anong oras
Mga Pagpipigil sa Kaganapan	wala
Mga Araw ng Kaganapan	Araw-araw
Tagal ng Kaganapan	24 oras
Abiso	Araw ng maaga
Pagpipilian sa Pag-uugali	N / A - Isang pinakamahusay na programa sa pagsisikap
Sertipikasyon Mga kaganapan	wala

Mga Katangian ng OpenADR para sa Ipinamahaging Mga Mapagkukunang Enerhiya (DER)

Mga Senyas sa Kaganapan	Mga signal ng ELECTRICITY_PRICE na may 24 na oras na agwat ng mga presyo sa loob ng 24 na oras. Ang signal na ito ay mangangailangan ng B profile. Ang program na ito ay hindi nagpapahiram sa sarili sa simpleng pag-sign ng SIM para sa isang profile Mga VEN. Tingnan ang Annex A para sa datingamples.
Mga tugon sa Pagpipilian	-VTNs na nagpapadala ng mga kaganapan dapat itakda ang oadrResponseRequired na elemento na "hindi kailanman", pinipigilan ang mga VEN mula sa pagtugon.
Kaganapan Descriptor	-Ang kaganapan dapat itakda ang prioridad sa 1 maliban kung ang mga patakaran ng programa o pagsasaayos ng VTN ay tumutukoy sa ibang paraan
Panahon ng Aktibo ng Kaganapan	24 na oras na may 1 oras na agwat na may paunang abiso
Mga baseline	N/A
Pag-target sa Kaganapan	Walang kinakailangang advanced na pag-target bukod sa venID
Mga Serbisyo sa Pag-uulat	Hindi kinakailangan ng pag-uulat Sumangguni sa Annex B para sa datingamples ng mga ulat mula sa mga pilot ng utility na maaaring mailalapat sa ganitong uri ng programa.
Mga Serbisyo sa Pagpipilian	Hindi ginagamit
Mga Serbisyo sa Rehistro	Mga agwat ng botohan hiniling ng VTN para sa mga tipikal na programang pang-araw ay hindi kinakailangan na maging mas madalas na minsan sa isang oras. Gayunpaman, ang paggamit ng botohan para sa pagtuklas ng tibok ng puso ay maaaring mangailangan ng mas madalas na botohan tulad ng mga programa ng termostat ng tirahan na may mas maiikling oras ng pag-abiso.

– Sample Mga Template ng Data at Payload

Ang mga sumusunod na talahanayan at XML payload samples ay magbibigay ng mga nagpapatupad ng nasasalat na datingamples kung paano dapat ipatupad ang mga template ng DR sa dokumentong ito. Ang mga sumusunod na mga awtomatikong namespace ay ginagamit sa payload examples:

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

Kritikal na Programa sa Pagpepresyo ng Pataas (CPP)

Scenario ng CPP 1 - Kaso ng Simpleng Paggamit, A o B Profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal:4 na oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 1
  • Pangalan ng Signal: SIMPLE
    • Uri ng Signal: antas
    • Mga Yunit: N / A
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 1
    • Target ng Signal: N / A
  • Mga Target ng Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

CPP Scenario 2 - Karaniwang Kaso ng Paggamit, B profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal: 4 oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 2
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0, 1, 2, 3
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 1 o 2
    • Target ng Signal: Wala
  • Pangalan ng Signal: ELECTRICITY_PRICE
    • Uri ng Signal: presyo
    • Mga Yunit: USD bawat Kwh
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: $ 0.10 hanggang $ 1.00
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

CPP Scenario 3 - Kaso ng Paggamit ng Komplikado

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 2pm
  • Tagal: 6 oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 2
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0,1, 2, 3)
    • Bilang ng mga agwat 3
    • (Mga) Tagal ng Agwat: 1 oras, 4 na oras, 1 oras
    • Karaniwang (mga) Halaga ng Pagitan: 1, 2, 1 (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Pangalan ng Signal: ELECTRICITY_PRICE
    • Uri ng Signal: presyo
    • Mga Yunit: USD bawat Kwh
    • Bilang ng mga agwat 3
    • (Mga) Tagal ng Agwat: 1 oras, 4 na oras, 1 oras
    • Karaniwang (mga) Halaga ng Pagitan: $ 0.50, $ 0.75, $ 0.50 (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: Resource_1, Resource_2, Resource_3
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

Ang CPP Sample Payload ng Kaganapan - Karaniwang B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Kaganapan091214_043741_028_0

0

http: // MarketContext1

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

malayo

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

PT4H

PT24H

PT4H

0

2.0

SIMPLE

antas

SIG_01

0.0

PT4H

0

0.75

ELECTRICITY_PRICE

presyo

SIG_02

peraPerKWh

USD

wala

0.0

venID_1234

palagi

Capacity Bidding Program (CBP)

CBP Scenario 1 - Kaso ng Simpleng Paggamit, A o B Profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal:4 na oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 1
  • Pangalan ng Signal: SIMPLE
    • Uri ng Signal: antas
    • Mga Yunit: N / A
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 1
    • Target ng Signal: N / A
  • Mga Target ng Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

CBP Scenario 2 - Karaniwang Kaso ng Paggamit, B profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal: 4 oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 2
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0,1, 2, 3
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 1 o 2
    • Target ng Signal: Wala
  • Pangalan ng Signal: BID_LOAD
    • Uri ng Signal: setpoint
    • Mga Yunit: powerReal
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 20kW hanggang 100kW
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

CBP Scenario 3 - Kaso ng Paggamit ng Komplikado

• Kaganapan
  • Abiso: Araw ng kaganapan (ilang oras?)
  • Oras ng Pagsisimula: 1pm
  • Tagal: 6 oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 3
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0,1, 2, 3)
    • Bilang ng mga agwat: 2
    • (Mga) Tagal ng Agwat: 3 oras, 3 oras
    • Karaniwang (mga) Halaga ng Pagitan: 1, 2 (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Pangalan ng Signal: BID_LOAD
    • Uri ng Signal: setpoint
    • Mga Yunit: powerReal
    • Bilang ng mga agwat 2
    • (Mga) Tagal ng Agwat: 3 oras, 3 oras
    • Karaniwang (mga) Halaga ng Pagitan: 40kW, 80kW (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Pangalan ng Signal: BID_PRICE
    • Uri ng Signal: presyo
    • Mga Yunit: currencyPerKW
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 6 na oras
    • Karaniwang (mga) Halaga ng Pagitan: $ 3.10
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: Resource_1, Resource_2, Resource_3
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• (Mga) Ulat
  • Pangalan ng Ulat: TELEMETRY_USAGE
  • Uri ng Ulat: paggamit
  • Mga Yunit: powerReal
  • Uri ng Pagbasa: Direktang Basahin
  • Dalas ng Pag-ulat: bawat 1 oras

Ang CBP Sample Payload ng Kaganapan - Karaniwang B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Kaganapan091214_043741_028_0

0

http: // MarketContext1

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

malayo

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

PT4H

PT24H

PT4H

0

2.0

SIMPLE

antas

SIG_01

0.0

PT4H

0

80.0

BID_LOAD

setpoint

SIG_02

RealPower

W

k

60.0

<power:voltage> 220.0tage>

totoo

0.0

venID_1234

palagi

Programa ng Residential Thermostat

Residential Thermostat Scenario 1 - Simpleng kaso ng Paggamit, A o B Profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal:4 na oras
  • Randomization: 10 minuto
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 1
  • Pangalan ng Signal: SIMPLE
    • Uri ng Signal: antas
    • Mga Yunit: N / A
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 1
    • Target ng Signal: N / A
  • Mga Target ng Kaganapan: Resource_1
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

Residential Thermostat Scenario 2 - Karaniwang Kaso ng Paggamit, B profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal: 4 oras
  • Randomization: 10 minuto
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 2
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0,1, 2, 3
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 1 o 2
    • Target ng Signal: Wala
  • Pangalan ng Signal: LOAD_CONTROL
    • Uri ng Signal: x-loadControlLevelOffset
    • Mga Yunit: Temperatura
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 4 na oras
    • Karaniwang (mga) Halaga ng Pagitan: 2 hanggang 6 degree Fahrenheit
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: Resource_1, Resource_2
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • Inaasahang Tugon ng VEN: optIn, Posibleng outOut (oadrCreateOpt)
• Mga ulat
  • wala

Residential Thermostat Scenario 3 - Kaso ng Paggamit ng Komplikado

• Kaganapan
  • Abiso: Araw ng kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal: 6 oras
  • Randomization: 10 minuto
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 3
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0,1, 2, 3)
    • Bilang ng mga agwat: 2
    • (Mga) Tagal ng Agwat: 3 oras, 3 oras
    • Karaniwang (mga) Halaga ng Pagitan: 1, 2 (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Pangalan ng Signal: BID_LOAD
    • Uri ng Signal: x-loadControlCapacity
    • Mga Yunit: Wala
    • Bilang ng mga agwat 2
    • (Mga) Tagal ng Agwat: 3 oras, 3 oras
    • Karaniwang (mga) Halaga ng Pagitan: 0.9, 0.8 (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: Resource_1, Resource_2, Resource_3
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • Inaasahang Tugon ng VEN: optIn, Posibleng outOut (oadrCreateOpt)
• (Mga) Ulat
  • wala

Residential Thermostat Sample Payload ng Kaganapan - Karaniwang B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Kaganapan091214_043741_028_0

0

http: // MarketContext1

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

malayo

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

PT4H

PT10M

PT24H

PT4H

0

2.0

SIMPLE

antas

SIG_01

0.0

PT4H

0

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

temperatura

fahrenheit

wala

0.0

mapagkukunan_1

mapagkukunan_2

palagi

Mabilis na DR Dispatch

Mabilis na senaryo ng DR 1 - Kasing Simpleng Paggamit, A o B Profile

• Kaganapan
  • Abiso: 10 minuto
  • Oras ng Pagsisimula: 1pm
  • Tagal: 0 (Open Ended)
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 1
  • Pangalan ng Signal: SIMPLE
    • Uri ng Signal: antas
    • Mga Yunit: N / A
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng Agwat: 0 (Open Ended)
    • Karaniwang (mga) Halaga ng Pagitan: 1
    • Target ng Signal: N / A
  • Mga Target ng Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

Mabilis na DR Scenario 2 - Karaniwang Kaso ng Paggamit, B profile

• Kaganapan
  • Abiso: 10 minuto
  • Oras ng Pagsisimula: 1pm
  • Tagal: 30 minuto
  • Randomization: Wala
  • Ramp Pataas: 5 minuto
  • Pagbawi: 5 minuto
  • Bilang ng mga signal: 2
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0,1, 2, 3
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng Agwat: 30 minuto
    • Karaniwang (mga) Halaga ng Pagitan: 1 o 2
    • Target ng Signal: Wala
  • Pangalan ng Signal: LOAD_DISPATCH
    • Uri ng Signal: delta
    • Mga Yunit: powerReal
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng Agwat: 30 minuto
    • Karaniwang (mga) Halaga ng Pagitan: 500 kW hanggang 2mW
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • Pangalan ng Ulat: TELEMETRY_USAGE
  • Uri ng Ulat: paggamit
  • Mga Yunit: powerReal
  • Uri ng Pagbasa: Direktang Basahin
  • Dalas ng Pag-ulat: bawat 1 minuto

Mabilis na senaryo ng DR 3 - Kaso ng Paggamit ng Komplikado

• Kaganapan
  • Abiso: 10 minuto
  • Oras ng Pagsisimula: 1pm
  • Tagal: 30 minuto
  • Randomization: Wala
  • Ramp Pataas: 5 minuto
  • Pagbawi: 5 minuto
  • Bilang ng mga signal: 2
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0,1, 2, 3)
    • Bilang ng mga agwat: 2
    • (Mga) Tagal ng Agwat: 15 minuto, 15 minuto
    • Karaniwang (mga) Halaga ng Pagitan: 1, 2 (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Pangalan ng Signal: LOAD_DISPATCH
    • Uri ng Signal: setpoint
    • Mga Yunit: powerReal
    • Bilang ng mga agwat 2
    • (Mga) Tagal ng Agwat: 15 minuto, 15 minuto
    • Karaniwang (mga) Halaga ng Pagitan: 800kW, 900kW (para sa bawat agwat ayon sa pagkakabanggit)
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: Resource_1
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• (Mga) Ulat
  • Pangalan ng Ulat: TELEMETRY_USAGE
  • Uri ng Ulat: paggamit
  • Mga Yunit: powerReal at voltage
  • Uri ng Pagbasa: Direktang Basahin
  • Dalas ng Pag-ulat: bawat 5 segundo

Mabilis na DR Sample Payload ng Kaganapan - Karaniwang B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Kaganapan091214_043741_028_0

0

http: // MarketContext1

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

malayo

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

PT10M

PT10M

<ei:x-eiRampPataas>

PT5M

</ei:x-eiRampPataas>

PT5M

PT10M

0

2.0

SIMPLE

antas

SIG_01

0.0

PT10M

0

500.0

LOAD_DISPATCH

delta

SIG_02

RealPower

W

k

60.0

<power:voltage> 220.0tage>

totoo

0.0

venID_1234

palagi

Mabilis na DR Sample Iulat ang Metadata Payload - Karaniwang B Profile Use Case

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

mapagkukunan1

paggamit

RealEnergy

Wh

k

Direktang Basahin

http: // MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

hindi totoo

</oadr:oadrSamplingRate>

0

ReportSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

Mabilis na DR Sample Report Humiling ng Payload - Karaniwang B Profile Use Case

Iulat angReqID130615_192625_230

Iulat angReqID130615_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-notApplicable

VEN130615_192312_582

Mabilis na DR Sample Mag-ulat ng Data Payload - Karaniwang B Profile Use Case

Iulat ang 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

Kalidad na Mabuti - Hindi Tiyak

RP_54321

Iulat angReqID130615_192625_730

ReportSpecID120615_122512_481_2

TELEMETRY_USAGE

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

VEN130615_192312_582

Programa ng Oras ng Paggamit (TOU) ng Residential Electric Vehicle (EV) Oras ng Paggamit

Tandaan na habang ipinapahiwatig ng programa ang mga antas ng rate sa isang medyo nakabalangkas na form lamang ang simple at karaniwang mga kaso ng paggamit ay ipinapakita

Residential EV Scenario 1 - Simpleng kaso ng Paggamit, A o B Profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: 1pm
  • Tagal:24 na oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 1
  • Pangalan ng Signal: SIMPLE
    • Uri ng Signal: antas
    • Mga Yunit: N / A
    • Bilang ng mga agwat; pantay na mga pagbabago sa TOU Tier sa loob ng 24 na oras (2 - 6)
    • (Mga) Tagal ng pagitan: TOU tier aktibong time frame (ie 6 na oras)
    • Karaniwang (mga) Halaga ng Pagitan: 0 - 4 na nai-map sa TOU Tiers
    • Target ng Signal: N / A
  • Mga Target ng Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

Residential EV Scenario 2 - Karaniwang Kaso ng Paggamit, B profile

• Kaganapan
  • Abiso: Araw bago ang kaganapan
  • Oras ng Pagsisimula: hatinggabi
  • Tagal: 24 oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 2
  • Pangalan ng Signal: Simple
    • Uri ng Signal: antas
    • Mga Yunit: Antas 0, 1, 2, 3
    • Bilang ng mga agwat: pantay na pagbabago sa TOU Tier sa loob ng 24 na oras (2 - 6)
    • (Mga) Tagal ng pagitan: TOU tier aktibong time frame (ie 6 na oras)
    • Karaniwang (mga) Halaga ng Pagitan: 0 - 4 na nai-map sa TOU Tiers (0 - Cheapest Tier)
    • Target ng Signal: Wala
  • Pangalan ng Signal: ELECTRICITY_PRICE
    • Uri ng Signal: presyo
    • Mga Yunit: USD bawat Kwh
    • Bilang ng mga agwat: pantay na mga pagbabago sa TOU Tier sa loob ng 24 na oras (2 - 6)
    • (Mga) Tagal ng pagitan: TOU tier aktibong time frame (ie 6 na oras)
    • Karaniwang (mga) Halaga ng Pagitan: $ 0.10 hanggang $ 1.00 (kasalukuyang antas ng tier)
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

Ang tirahan EV Sample Payload ng Kaganapan - Karaniwang B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Kaganapan091214_043741_028_0

0

http: // MarketContext1

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

malayo

<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

SIMPLE

antas

SIG_01

0.0

PT5H

0

0.35

PT7H

1

0.55

PT7H

2

0.75

PT5H

3

0.55

ELECTRICITY_PRICE

presyo

SIG_02

peraPerKWh

USD

wala

0.0

venID_1234

palagi

Public Station Electric Vehicle (EV) Programang Pagpepresyo ng Real-Time

Tandaan na dahil ito ay isang programa sa pagpepresyo ng real time wala talagang pagkakaiba sa pagitan ng isang simple, tipikal, at kumplikadong kaso ng paggamit. Samakatuwid sampipapakita lamang ang le data para sa isang karaniwang kaso ng paggamit.

Public Station EV Scenario 1 - Karaniwang Kaso ng Paggamit, B profile

• Kaganapan
  • Abiso: 1 oras nang maaga
  • Oras ng Pagsisimula: 1pm
  • Tagal: 1 oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 1
  • Pangalan ng Signal: ELECTRICITY_PRICE
    • Uri ng Signal: presyo
    • Mga Yunit: USD bawat Kwh
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 1 na oras
    • Karaniwang (mga) Halaga ng Pagitan: $ 0.10 hanggang $ 1.00
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang VEN Response: palagi
  • VEN Inaasahang Tugon: optIn
• Mga ulat
  • wala

Pampublikong Istasyon EV Sample Payload ng Kaganapan - Karaniwang B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Kaganapan091214_043741_028_0

0

http: // MarketContext1

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

malayo

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

PT1H

PT1H

PT1H

0

0.75

ELECTRICITY_PRICE

presyo

SIG_01

peraPerKWh

USD

wala

0.0

venID_1234

palagi

Naipamahagi na Program na Pinagkaloob na Mga mapagkukunang enerhiya (DER)

Tandaan na dahil ito ay isang programa sa pagpepresyo ng real time wala talagang pagkakaiba sa pagitan ng isang simple, tipikal, at kumplikadong kaso ng paggamit. Samakatuwid sampipapakita lamang ang le data para sa isang karaniwang kaso ng paggamit.

Public Station EV Scenario 1 - Karaniwang Kaso ng Paggamit, B profile

• Kaganapan
  • Abiso: Maaga pa
  • Oras ng Pagsisimula: hatinggabi
  • Tagal: 24 oras
  • Randomization: Wala
  • Ramp Pataas: Wala
  • Pagbawi: Wala
  • Bilang ng mga signal: 24
  • Pangalan ng Signal: ELECTRICITY_PRICE
    • Uri ng Signal: presyo
    • Mga Yunit: USD bawat Kwh
    • Bilang ng mga agwat 1
    • (Mga) Tagal ng pagitan: 1 na oras
    • Karaniwang (mga) Halaga ng Pagitan: $ 0.10 hanggang $ 1.00
    • Target ng Signal: Wala
  • Mga Target sa Kaganapan: venID_1234
  • Priyoridad: 1
  • Kinakailangan ang Tugon ng VEN: hindi kailanman
  • Inaasahang Tugon ng VEN: n / a
• Mga ulat
  • wala

Pampublikong Istasyon EV Sample Payload ng Kaganapan - Karaniwang B Profile Use Case

OadrDisReq091214_043740_513

TH_VTN

Kaganapan091214_043741_028_0

0

http: // MarketContext1

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

malayo

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

PT24H

PT24H

PT1H

0

0.75

PT1H

1

0.80

ELECTRICITY_PRICE

presyo

SIG_01

peraPerKWh

USD

wala

0.0

venID_1234

hindi kailanman

- Halample Mga Ulat Mula sa Mga Piloto ng Utility

Ang mga miyembro ng OpenADR Alliance ay nagbigay ng sumusunod na B Profile oadrUpdateReport payload samples mula sa mga utility pilot program kung saan na-deploy ang kanilang mga VEN. Ang mga sumusunod na tala ay sinamahan ang tatlong mga kargamento sampibinigay ng les:

Layunin ng Termostat Payload:

• Kailangang malaman ang katayuan ng termostat (temp, set point, fan at mode na estado)
• Kung nagpasyang sumali, binago man o hindi ng customer ang mga setting ng termostat (mga manu-manong mensahe na override)

M&V para sa Rebates Payload Layunin:

• Katayuan ng mga mapagkukunan at manu-manong pag-override sa kaso ng pag-opt in
• Ang data ng agwat mula sa isang KYZ Pulse Counter o Energy Monitor para sa kabuuang enerhiya sa KWH at instant na pangangailangan sa KW

Layunin ng Pag-load ng Data ng Smart Meter / AMI:

• Ang agwat ng pagbasa ng metro ng AMI ay halos 15 minuto hanggang 1 oras. Bagaman kapaki-pakinabang, hindi sapat na butil-butil para sa mga pagtatantya ng real time na pagsingil
• Kabuuang Enerhiya sa KWH, enerhiya ng delta sa KWH, instant na pangangailangan sa KW

Ang mga sumusunod na mga awtomatikong namespace ay ginagamit sa payload examples:

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

Payload ng Ulat ng Thermostat Sample

RUP-18

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

PT1M

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

PT1M

Katayuan

totoo

hindi totoo

0

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Kasalukuyang Temp

77.000000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Setting ng Heat Temp

64.000000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Cool na setting ng Temp

86.000000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Pagtatakda ng Mode ng HVAC

3

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Kasalukuyang Mode ng HVAC

0.000000

Walang Kalidad - Walang Halaga

Pagtatakda ng Fan Mode

2

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Kasalukuyang Hold Mode

2

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Kasalukuyang Away Mode

0

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

Kasalukuyang Humidity

0.000000

Walang Kalidad - Walang Halaga

RP21

REQ: RReq: 1395368583267

0013A20040980FAE

TELEMETRY_STATUS

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

VEN.ID:1395090780716

M & Vfor Rebates Report Payload Sample

RUP-10

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

PT30S

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

PT30S

Katayuan

totoo

hindi totoo

Kalidad na Mabuti - Hindi Tiyak

Bilang ng Pulso

34750.000000

Kalidad na Mabuti - Hindi Tiyak

Enerhiya

33985.500000

Kalidad na Mabuti - Hindi Tiyak

Lakas

1.26

Kalidad na Mabuti - Hindi Tiyak

RP15

REQ: RReq: 10453335019195698

0000000000522613 60

TELEMETRY_USAGE

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

VEN.ID:1439831430142

Smart Meter / AMI Interval Data Report Payload Sample

RUP-4096

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

PT1M

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

PT15S

agarangDemand

6.167000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

intervalDataDelivered

0.051000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

naihatid ng currSum

12172.052000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

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

PT15S

agarangDemand

6.114000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

intervalDataDelivered

0.051000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

naihatid ng currSum

12172.052000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

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

PT15S

agarangDemand

6.113000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

intervalDataDelivered

0.051000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

naihatid ng currSum

12172.142000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

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

PT15S

agarangDemand

6.112000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

intervalDataDelivered

0.051000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

naihatid ng currSum

12172.142000

Walang Bagong Halaga - Ginamit ang Nakaraang Halaga

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>

- Mga Serbisyo

Sinusuportahan ng bukas na ADR ang mga sumusunod na serbisyo:

• Serbisyo ng EiEvent - Ginamit ng mga VTN upang magpadala ng mga kaganapan sa pagtugon sa demand sa mga VEN, at ginamit ng mga VEN upang ipahiwatig kung ang mga mapagkukunan ay lalahok sa kaganapan. Ang nag-iisang serbisyo na suportado ng A profile ay si EiEvent
• Serbisyo ng EiReport - Ginamit ng mga VEN at VTN upang makipagpalitan ng mga ulat sa kasaysayan, telemetry, at forecast
• Serbisyo ng EiOpt - Ginamit ng VEN upang makipag-usap ng pansamantalang iskedyul ng kakayahang magamit sa mga VTN o upang maging kuwalipikado sa mga mapagkukunang kasali sa isang kaganapan
• Serbisyo ng EiRegisterParty - Pinasimulan ng VEN, at ginamit ng parehong VEN at VTN upang mahukay ang impormasyong kinakailangan upang matiyak na magkakaugnay na palitan ng mga kargamento
• Serbisyo ng OadrPoll - Ginamit ng mga VEN upang i-poll ang VTN para sa mga kargamento mula sa alinman sa iba pang mga serbisyo

A at B profile ang mga pagpapatakbo ng serbisyo ay tinukoy ng root element ng bawat payload, hindi kasama ang oadrPayload at oadrSignedObject wrappers na ginamit sa lahat ng B profile mga payload.

- Mga Kahulugan ng Payload

Mga Payload ng EiEvent

• oadrRequestEvent - Ginamit sa isang modelo ng pull exchange ng VEN upang makuha ang lahat ng nauugnay na mga kaganapan mula sa VTN. Ginamit bilang pangunahing mekanismo ng botohan para sa A profile Ang mga VEN, ngunit ginagamit lamang sa B VENs para sa pag-sync sa VTN.
• oadrDistributionEvent - Ginamit ng VTN upang maihatid ang mga kaganapan sa pagtugon sa demand sa VEN
• oadrCreatedEvent - Ginamit ng VEN upang makipag-usap kung balak nitong lumahok sa isang kaganapan sa pamamagitan ng pagpili o paglabas
• oadrResponse - Ginamit ng VTN upang kilalanin ang resibo ng optIn o optOut mula sa VEN

Mga EiReport Payload

Tandaan na ang parehong mga VEN at VTN ay may kakayahang maging parehong tagagawa ng ulat at isang humiling ng ulat, kaya ang lahat ng mga kargamento sa ibaba ay maaaring pasimulan ng alinmang partido.

• oadrRegisterReport - Ginamit upang mai-publish ang kanilang mga kakayahan sa pag-uulat sa isang ulat sa metadata
• oadrRegistrReport -Kilala ang resibo ng oadrRegisterReport, opsyonal na humiling ng isa sa mga inaalok na ulat
• oadrCreateReport - Ginamit upang humiling ng isang ulat na naunang inalok ng VEN o VTN
• oadrCreatedReport - Kilalanin ang pagtanggap ng isang kahilingan sa ulat
• oadrUpdateReport -Maghatid ng isang hiniling na ulat na naglalaman ng data ng agwat
• oadrUpdatedReport - Kilalanin ang pagtanggap ng isang naihatid na ulat
• oadrCancelReport - Kanselahin ang dati nang hiniling na pana-panahong ulat
• oadrCanceledReport - Kilalanin ang isang pana-panahong pagkansela ng ulat
• oadrResponse - Ginamit bilang isang tugon sa placeholder sa ilang mga pattern ng exchange exchange kapag ang isang tugon sa layer ng application ay naihatid sa isang kahilingan sa layer ng transportasyon.

Mga EiOpt Payload

• oadrCreateOpt - Ginamit para sa dalawang malinaw na magkakaibang mga layunin
  • Upang maipaabot ng VEN ang isang pansamantalang iskedyul ng kakayahang magamit sa VTN patungkol sa kakayahang lumahok sa mga kaganapan sa DR
  • Para maging karapat-dapat ang VEN sa mga mapagkukunang kasali sa isang kaganapan
• oadrCreatedOpt - Kilalanin ang resibo ng oadrCreateOpt na kargamento
• oadrCancelOpt -Cancel isang pansamantalang iskedyul ng kakayahang magamit
• oadrCanceledOpt - Kilalanin ang isang pansamantalang pagkansela ng ulat sa kakayahang magamit

 

Mga Payload ng EiRegisterParty

• oadrQueryRegistro - Isang paraan para magtanong ang VEN sa impormasyon ng pagpaparehistro ng VTN nang hindi talaga nagrerehistro.
• oadrCreatePartyRegistro - Isang kahilingan mula sa VEN sa VTN upang magparehistro. Naglalaman ng impormasyon tungkol sa mga kakayahan ng VENs.
• oadrCreatedPartyRegistro - Ang tugon sa alinman sa isang oadrQueryRegistro o isang oadrCreatePartyRegibution. Naglalaman ng mga kakayahan ng VTN at impormasyon sa pagpaparehistro kinakailangan upang makipagtulungan ang VEN
• oadrCancelPartyRegistro - Ginamit ng alinman sa VEN o VTN upang kanselahin ang pagpaparehistro
• oadrCanceledPartyRegistro - Tumugon muli sa isang oadrCancelPartyRegistro. Kinikilala ang pagtanggap ng pagkansela sa pagpaparehistro
• oadrRequestRereg registration - Ang payload na ito ay ginagamit ng isang VTN sa isang modelo ng pull exchange upang senyasan ang VEN upang muling simulan ang pagkakasunud-sunod ng pagpaparehistro
• oadrResponse - Ginamit bilang isang tugon sa placeholder sa ilang mga pattern ng exchange exchange kapag ang isang tugon sa layer ng application ay naihatid sa isang kahilingan sa layer ng transportasyon.

Mga Payload ng OadrPoll

• oadrPoll - Isang generic na poling na mekanismo para sa B profile na nagbabalik ng kargamento para sa anumang iba pang serbisyo na bago o na-update.
• oadrResponse - Ginamit upang ipahiwatig na walang mga bago o na-update na mga kargamento na magagamit

- Talasalitaan ng Mga Elemento ng Payload ng Schema

Ang sumusunod ay isang listahan ng alpabetikong mga elemento ng iskema na ginamit sa OpenADR 2.0 payloads. Inilalarawan ng salaysay ang kanilang paggamit na nauugnay sa OpenADR at sa kanilang paggamit sa mga payload .. Kapag nagbago ang isang kahulugan ng elemento batay sa payload na nilalaman nito o sa konteksto ng paggamit nito, mapapansin ito sa pagsasalaysay. Ang mga kahulugan ng ugat ng pag-load ay naibukod dahil ang tinukoy sa Annex C.

• ac - Isang halaga ng Boolean na nagpapahiwatig kung ang produkto ng kuryente ay alternating kasalukuyang
• kawastuhan - Ang numero ay nasa parehong mga yunit ng variable ng payload para sa isang pagitan. Kapag naroroon sa Kumpiyansa, ipinapahiwatig ang posibilidad ng pagkakaiba-iba ng hula. Kapag naroroon sa ReadingType, ipinapahiwatig ang malamang pagkakamali sa Pagbasa.
• pinagsamangPnode - Ang pinagsamang node ng pagpepresyo ay isang dalubhasang uri ng node ng pagpepresyo na ginamit upang i-modelo ang mga item tulad ng System Zone, Default na Sona ng Presyo, Pasadyang Sona ng Presyo, Lugar ng Pagkontrol, Pinagsama-samang Henerasyon, Pinagsama na Sumasangkot na Pag-load, Pinagsama-sama na Hindi Sumasali na Pag-load, Trading Hub, DCA Zone
• magagamit - Isang bagay na naglalaman ng isang petsa ng oras at tagal para sa isang iskedyul ng kakayahang magamit ng EiOpt
• baselineID - Natatanging ID para sa isang tukoy na baseline
• baselineName - Naglarawang pangalan para sa baseline
• mga bahagi –
• kumpiyansa - Isang posibilidad na pang-istatistika na ang isang naiulat na data point ay tumpak
• nilikhaDateTime - Ang dateTime ang payload ay nilikha
• pera –
• peraPerKW –
• peraPerKWh –
• currencyPerThm –
• kasalukuyang –
• kasalukuyangValue - Ang halaga ng payloadFloat ng agwat ng kaganapan na kasalukuyang ipinapatupad.
• pasadya - Ginamit upang tukuyin ang isang pasadyang yunit ng pagsukat para sa mga pasadyang ulat
• petsa-oras –
• dtstart - Ang oras ng pagsisimula para sa aktibidad, data, o pagbabago ng estado
• tagal - Isang tagal ng oras para sa isang kaganapan, pag-uulat, o agwat ng oras ng kakayahang magamit
• tagal - Ang tagal ng aktibidad, data, o estado
• eiActivePeriod - Mga time frame na nauugnay sa pangkalahatang kaganapan
• eiCreatedEvent - Tumugon sa isang Kaganapan sa DR na may optIn o optOut
• eiEvent -Ang isang bagay na naglalaman ng lahat ng impormasyon para sa isang solong kaganapan
• eiEventBaseline - B profile
• eiEventSignal - Isang bagay na naglalaman ng lahat ng impormasyon para sa isang solong signal sa isang kaganapan
• eiEventSignals - Ang data ng agwat para sa isa o higit pang mga signal ng kaganapan at / o mga baseline
• eiMarketContext - Isang natatanging pagkilala ng URI ng isang programa ng pagtugon sa demand
• eiReportID - Reference ID para sa isang ulat
• eiRequestEvent - Humiling ng Kaganapan mula sa isang VTN sa pull mode
• eiResponse - Ipahiwatig kung ang natanggap na kargamento ay katanggap-tanggap
• eiTarget - Kinikilala ang mga mapagkukunan na nauugnay sa lohikal na interface ng VEN. Para sa mga kaganapan, ang mga tinukoy na halaga ay ang target para sa kaganapan
• endDeviceAsset - Ang EndDeviceAssets ay ang pisikal na aparato o mga aparato na maaaring metro o iba pang mga uri ng mga aparato na maaaring maging interesado
• enerhiyaAparent - Maliwanag na Enerhiya, sinusukat sa volt-ampere oras (VAh)
• enerhiyaItem –
• reaktibo - Reaktibong Enerhiya, volt-amporas ng reaktibo (VARh)
• enerhiyaReal - Tunay na Enerhiya, Mga Oras ng Watt (Wh)
• eventDescriptor - Impormasyon tungkol sa kaganapan
• eventID - Isang halaga ng ID na tumutukoy sa isang tukoy na halimbawa ng kaganapan sa DR.
• eventResponse - Isang bagay na naglalaman ng mga tugon ng VENs sa isang kahilingan na lumahok sa isang kaganapan
• eventResponses - mag-optIn o mag-optOut ng mga tugon para sa mga natanggap na kaganapan
• kaganapanStatus - Ang kasalukuyang katayuan ng isang kaganapan (malayo, malapit, aktibo, atbp)
• TampokCollection / lokasyon / Polygon / exterior / LinearRing
• dalas –
• granularity - Ito ang agwat ng oras sa pagitan ng samphumantong data sa isang kahilingan sa ulat.
• pangkatID -Ang ganitong uri ng target ay ginagamit para sa mga kaganapan, ulat, at iskedyul ng opt. Karaniwang itatalaga ng utility ang halaga sa panahon ng pagpapatala sa isang programa ng DR
• Pangalan ng grupo - Ang ganitong uri ng target ay ginagamit para sa mga kaganapan, ulat, at iskedyul ng opt. Karaniwang itatalaga ng utility ang halaga sa panahon ng pagpapatala sa isang programa ng DR
• hertz –
• pagitan - Isang bagay na naglalaman ng oras ng data at / o tagal, at isang naaaksyong halaga sa kaso ng isang kaganapan o data sa kaso ng isang ulat
• agwat - Isa o higit pang mga agwat ng oras kung saan aktibo ang kaganapan sa DR o magagamit ang data ng ulat
• itemDescription - Isang paglalarawan ng isang yunit ng pagsukat ng ulat
• itemUnits - Ang batayang yunit ng panukalang para sa isang punto ng data ng ulat
• marketContext - Isang URI na kinikilala ang isang DR Program
• meterAsset - Ang MeterAsset ay ang pisikal na aparato o mga aparato na gumaganap ng papel na ginagampanan ng metro
• modificationDateTime - Kapag ang isang kaganapan ay nabago
• pagbabago ng numero - Nadagdagan sa tuwing nabago ang isang kaganapan.
• modificationReason - Bakit binago ang isang kaganapan
• mrid - Kinikilala ng mRID ang pisikal na aparato na maaaring isang CustomerMeter o iba pang mga uri ng EndDevices.
• node - Ang Node ay isang lugar kung saan may nagbabago (madalas na pagmamay-ari) o kumokonekta sa grid. Maraming mga node ay naiugnay sa metro, ngunit hindi lahat ay.
• numDataSource –
• oadrKapasidad –
• oadrKasalukuyan –
• oadrDataQualidad –
• oadrDeviceClass - Target ng Class ng Device - gamitin lamang ang endDeviceAsset.
• oadrEvent - Isang bagay na naglalaman ng isang kaganapan sa pagtugon sa demand
• oadrExtension –
• oadrExtensionName -
• oadrExtensions –
• oadrHttpPullModel - Isang boolean na nagpapahiwatig kung nais ng VEN na gumamit ng isang modelo ng pull exchange
• oadrInfo - Isang pangunahing pares ng halaga ng impormasyon na partikular sa pagpaparehistro ng serbisyo
• oadrKey –
• oadrLevelOffset –
• oadrLoadControlState –
• oadrManualOverride - Kung totoo kung gayon ang kontrol ng pag-load ay manu-manong na-override
• oadrMax –
• oadrMaxPeriod - Pinakamataas na samppanahon ng ling
• oadrMin –
• oadrMinPeriod - Pinakamababang samppanahon ng ling
• oadrNormal –
• oadrOnChange - Kung totoo kung gayon ang data ay maitatala kapag nagbabago ito, ngunit walang mas mataas na dalas kaysa sa tinukoy ng minPeriod.
• oadrOnline - Kung totoo kung gayon ang mapagkukunan / pag-aari ay online, kung mali pagkatapos ay offline.
• oadrPayload –
• oadrPayloadResourceStatus - Kasalukuyang impormasyon sa katayuan ng mapagkukunan
• oadrPendingReports - Isang listahan ng mga pana-panahong ulat na aktibo pa rin
• oadrPercentOffset –
• oadrProfile - Profile suportado ng VEN o VTN
• oadrProfilePangalan – OpenADR profile pangalan tulad ng 2.0a o 2.0b.
• oadrProfiles – OpenADR profiles suportado ng pagpapatupad
• oadrReport -Ang isang bagay na naglalaman ng lahat ng impormasyon para sa isang solong ulat
• oadrReportDescription - Paglalahad ng mga katangian ng ulat na inaalok ng gumagawa ng ulat. Na nilalaman sa isang ulat ng metadata
• oadrReportOnly - ReportOnlyDeviceFlag
• oadrReportPayload - Mga halaga ng punto ng data para sa mga ulat
• oadrRequestedOadrPollFreq - Ang VEN ay magpapadala ng isang oadrPoll payload sa VTN kahit minsan para sa bawat tagal na tinukoy ng elementong ito
• oadrResponseRequired - Kinokontrol kung kinakailangan ang tugon na optIn / optOut. Maaaring maging palagi o hindi kailanman
• oadrSamplingRate - Sampling rate para sa data ng uri ng telemetry
• oadrService –
• oadrServiceName - Ang ganitong uri ng target ay ginagamit para sa mga kaganapan, ulat, at iskedyul ng opt. Karaniwang itatalaga ng utility ang halaga sa panahon ng pagpapatala sa isang programa ng DR
• oadrServiceSpecificInfo - Impormasyon sa partikular na pagpaparehistro ng serbisyo
• oadrSetPoint –
• oadrSignedObject –
• oadrTransport - Isang pangalan ng transportasyon na suportado ng isang VEN o VTN
• oadrTransportAddress - Ginamit ang root address upang makipag-usap sa ibang partido. Dapat isama ang port kung kinakailangan
• oadrTransportName - Pangalan ng transportasyon ng OpenADR tulad ng simpleHttp o xmpp
• oadrTransports - Sinusuportahan ng OpenADR ang pagsuporta sa pagpapatupad
• oadrUpdatedReport - Kilalanin ang pagtanggap ng isang ulat
• oadrUpdateReport - Magpadala ng dati nang hiniling na ulat
• oadrValue –
• oadrVenName - VEN pangalan. Maaaring magamit sa VTN GUI
• oadrXmlSignature - Sinusuportahan ng pagpapatupad ang lagda ng XML
• optID - Tukoy para sa isang pakikipag-ugnayan sa opt
• optReason - Naitala ang halaga para sa opt na dahilan tulad ng x-iskedyul
• optType - optIn o optOut ng isang kaganapan, o ginamit upang ipahiwatig ang uri ng iskedyul ng opt na tinukoy sa vavailablityObject para sa serbisyo ng EiOpt
• nag-partyID - Ang ganitong uri ng target ay ginagamit para sa mga kaganapan, ulat, at iskedyul ng opt. Karaniwang itatalaga ng utility ang halaga sa panahon ng pagpapatala sa isang programa ng DR
• payloadFloat - Halaga ng data point para sa mga signal ng kaganapan o para sa pag-uulat ng mga kasalukuyan o makasaysayang halaga.
• pnode - Ang isang node ng pagpepresyo ay direktang nauugnay sa isang node ng pagkakakonekta. Ito ay isang lokasyon ng pagpepresyo kung saan ang mga kalahok sa merkado ay nagsumite ng kanilang mga bid, alok, bumili / magbenta ng mga CRR, at manirahan.
• pointOfDelivery –
• pointOfReceipt –
• postList –
• powerApparent - Maliit na Kuryente na sinusukat sa volt-amperes (VA)
• kapangyarihanAtributo
• kapangyarihanItem
• powerReactive - Reaktibong lakas, sinusukat sa volt-ampreaktibo (VAR)
• powerReal - Sinusukat ang tunay na lakas sa Watts (W) o Joules / segundo (J / s)
• prayoridad - Ang priyoridad ng kaganapan na nauugnay sa iba pang mga kaganapan (Ang mas mababa ang bilang na mas mataas ang priyoridad. Ang isang halaga ng zero (0) ay nagpapahiwatig ng walang priyoridad, na kung saan ay ang pinakamababang priyoridad bilang default).
• ari-arian –
• pulsoCount - Isang punto ng data ng pag-uulat
• pulseFactor - kWh bawat bilang
• kwalipikadoEventID - Isang natatanging ID para sa isang kaganapan
• uri ng pagbasa - Metadata tungkol sa mga Pagbasa, tulad ng mean o nagmula
• registrationID - Identifier para sa transaksyon sa Rehistro. Hindi kasama bilang tugon sa pagpaparehistro ng query maliban kung nakarehistro na
• replyLimit - Ang maximum na bilang ng mga kaganapan upang bumalik sa isang oadrDistributionEvent payload
• reportBackDuration - Iulat muli kasama ang Ulat-Sa-Petsa para sa bawat pagpasa ng Tagal na ito.
• reportDataSource - Mga mapagkukunan para sa data sa ulat na ito. Halamples isama ang mga metro o submeters. Para kay exampkung, kung ang isang metro ay may kakayahang magbigay ng dalawang magkakaibang uri ng mga sukat, pagkatapos ang bawat stream ng pagsukat ay magkakahiwalay na makikilala.
• reportInterval - Ito ang pangkalahatang panahon ng pag-uulat.
• reportName - Opsyonal na pangalan para sa isang ulat.
• reportRequestID - Tukoy para sa isang partikular na kahilingan sa ulat
• reportSpecifier - Tukuyin ang mga puntos ng data na nais sa isang partikular na halimbawa ng ulat
• reportSpecifierID - Tukoy para sa isang partikular na detalye ng ulat ng Metadata
• reportSubject - Target ng Class ng Device - gamitin lamang ang endDeviceAsset.
• reportToFollow - Ipinapahiwatig kung ang ulat (sa anyo ng UpdateReport) na ibabalik kasunod sa pagkansela ng Ulat
• ulat ng uri - Ang uri ng isang ulat tulad ng paggamit o presyo
• requestID - Ginamit ang isang ID upang tumugma sa isang lohikal na kahilingan at tugon sa transaksyon
• mapagkukunanID - Ang ganitong uri ng target ay ginagamit para sa mga kaganapan, ulat, at iskedyul ng opt. Karaniwang itatalaga ng utility ang halaga sa panahon ng pagpapatala sa isang programa ng DR
• tugon –
• sagot sa Code - Isang 3 digit na code sa pagtugon
• sagotDescription - Narrative na paglalarawan ng katayuan sa pagtugon
• mga tugon –
• rID - ReferenceID para sa puntong ito ng data
• serbisyoArea - Ang ganitong uri ng target ay ginagamit para sa mga kaganapan, ulat, at iskedyul ng opt. Karaniwang itatalaga ng utility ang halaga sa panahon ng pagpapatala sa isang programa ng DR
• serviceDeliveryPoint - Lohikal na punto sa network kung saan ang pagmamay-ari ng serbisyo ay nagbabago ng mga kamay. Ito ay isa sa potensyal na maraming mga punto ng serbisyo sa loob ng isang ServiceLocation, naghahatid ng serbisyo alinsunod sa isang CustomerAg agreement. Ginamit sa lugar kung saan maaaring mai-install ang isang metro.
• serviceLocation - Ang isang Customer ServiceLocation ay may isa o higit pang (mga) ServiceDeliveryPoint, na kung saan ay nauugnay sa Mga Metro. Ang lokasyon ay maaaring isang punto o isang polygon, depende sa mga tukoy na pangyayari. Para sa pamamahagi, ang ServiceLocation ay karaniwang lokasyon ng premise ng customer ng utility.
• signalID - natatanging Identifier para sa isang tukoy na signal ng kaganapan
• signalName - Ang pangalan ng isang senyas tulad ng SIMPLE
• signalPayload - Mga halaga ng signal para sa mga kaganapan at baseline
• siScaleCode - Isang kadahilanan sa pag-scale para sa pangunahing yunit ng sukat para sa isang ulat
• specifierPayload - Isang bukas
• simula pa - Ang window ng Randomization para sa pagsisimula ng kaganapan
• statusDateTime - Petsa at oras ng mga sangguniang artifact na ito.
• temperatura –
• testEvent - Anumang maliban sa maling ay nagpapahiwatig ng isang kaganapan sa pagsubok
• text –
• term –
• pagpapaubaya - Isang sub-object na naglalaman ng mga kinakailangan sa randomization para sa isang kaganapan
• magparaya - Isang bagay na naglalaman ng mga kinakailangan sa pag-random para sa isang kaganapan
• transportInterface - Ang Transport Interface ay naglalarawan sa mga gilid sa magkabilang dulo ng isang segment ng transportasyon.
• uid - Ginamit bilang isang index upang makilala ang mga agwat. Natatanging Kilalanin
• halaga –
• kakayahang magamit - Isang iskedyul na sumasalamin sa pagkakaroon ng aparato para sa pakikilahok sa mga kaganapan sa DR
• masugid - Isang natatanging identifier para sa isang VEN
• voltage –
• vtnComment - Kahit anong text
• vtnID - Isang natatanging identifier para sa isang VTN
• x-eiNotification - Dapat makatanggap ang VEN ng payload ng kaganapan sa DR bago ang dtstart na minus sa tagal na ito.
• x-eiRamppataas – Isang tagal bago o pagkatapos ng oras ng pagsisimula ng kaganapan kung saan dapat mag-transit ang load shed.
• x-eiRecover - Isang tagal bago o pagkatapos ng oras ng pagtatapos ng kaganapan kung saan dapat mag-transit ang load shed.

 

Talasalitaan ng Mga Naihahalagang Halaga

kaganapanStatus

• aktibo - Ang kaganapan ay sinimulan at kasalukuyang aktibo.
• kinansela - Nakansela ang kaganapan.
• natapos - Nakumpleto ang kaganapan.
• malayo - Nakabinbin ang kaganapan sa hinaharap. Ang eksaktong kahulugan ng kung gaano kalayo sa hinaharap na tumutukoy ito ay nakasalalay sa konteksto ng merkado, ngunit karaniwang nangangahulugang sa susunod na araw.
• malapit na - Nakabinbin ang kaganapan sa malapit na hinaharap. Ang eksaktong kahulugan kung gaano kalapit sa hinaharap ang nakabinbing kaganapan ay aktibo ay nakasalalay sa konteksto ng merkado. . Sinimulan kasabay ng mabisang pagsisimula ng kaganapan x-eiRampOras ng pag-up Kung x-eiRampHindi tinukoy ang pataas para sa kaganapan, ang katayuang ito ay hindi gagamitin para sa kaganapan.
• wala - Walang nakabinbing kaganapan

itemUnit

• Pera
  • USD - Mga Dolyar ng Estados Unidos
  • Sa marami na ililista dito, sumangguni sa schema
• kapangyarihanReal
  • J/s - Joule-segundo
  • W - Watts
• temperatura
  • celsius –
  • fahrenheit –

oadrDataQualidad

• Walang Bagong Halaga - Ginamit ang Nakaraang Halaga –
• Walang Kalidad - Walang Halaga –
• Marka ng Bad - pagkabigo ng Comm –
• Kalidad na Hindi Masama - Error sa Pag-configure –
• Kalidad na Hindi Magagawa - Nabigo ang Device –
• Kalidad na Hindi maganda - Huling Kilalang Halaga –
• Hindi Mabuti ang Kalidad - Hindi Tiyak –
• Hindi Mabuti ang Kalidad - Hindi Nakakonekta –
• Kalidad na Hindi Masama - Wala sa Serbisyo –
• Marka ng Bad - pagkabigo ng Sensor –
• Kalidad na Mabuti - Lokal na Pag-override –
• Kalidad na Mabuti - Hindi Tiyak –
• Limitasyon sa Kalidad - Patlang / Patuloy –
• Limitasyon sa Kalidad - Patlang / Mataas –
• Limitasyon sa Kalidad - Patlang / Mababa –
• Limitasyon sa Kalidad - Patlang / Hindi –
• Hindi Tinitiyak ang Kalidad - Lumagpas ang Mga Yunit ng EU –
• Hindi Tiyak sa Kalidad - Huling Magagamit na Halaga –
• Hindi Tiyak na Kalidad - Hindi Tiyak –
• Hindi Tinitiyak ang Kalidad - Hindi Tumpak ang Sensor –
• Hindi Tiyak sa Kalidad - Sub Normal –

oadrResponseRequired

• palagi - Palaging magpadala ng tugon para sa bawat natanggap na kaganapan.
• hindi kailanman - Huwag kailanman tumugon.

optReason

Naitala ang mga kadahilanan para sa pagpili.

• pangkabuhayan –
• emergency –
• mustRun –
• hindi Nakikilahok –
• outageRunStatus –
• overrideStatus –
• nakikilahok –
• x-iskedyul –

oadrTransportName

• simplengHttp –
• xmpp –

OptType

• optIn - Isang pahiwatig na lalahok ang VEN sa isang kaganapan, o sa kaso ng serbisyo ng EiOpt isang uri ng iskedyul na nagpapahiwatig na magagamit ang mapagkukunan
• mag-optout - Isang pahiwatig na ang VEN ay hindi lalahok sa isang kaganapan, o sa kaso ng serbisyo ng EiOpt isang uri ng iskedyul na nagpapahiwatig na ang mapagkukunan ay hindi magagamit

uri ng pagbabasa

• Inilaan - Sinasaklaw ng metro ang maraming [mapagkukunan] at ang paggamit ay napagpasyahan sa pamamagitan ng ilang uri ng pagkalkula ng data ng pro.
• Kontrata - Isinasaad ang pagbabasa ay pro forma, ibig sabihin, iniulat sa napagkasunduang mga rate
• Nagmula - Ang paggamit ay napagpasyahan sa pamamagitan ng kaalaman sa run-time, normal na operasyon, atbp.
• Direktang Basahin - Ang pagbabasa ay binabasa mula sa isang aparato na nagdaragdag ng monotonically, at ang paggamit ay dapat na kalkulahin mula sa mga pares ng pagsisimula at itigil ang pagbabasa.
• Tinatantya - Ginamit kapag ang isang pagbabasa ay wala sa isang serye kung saan ang karamihan sa mga pagbabasa ay naroroon.
• Hybrid - Kung pinagsama, tumutukoy sa iba't ibang mga uri ng pagbabasa sa pinagsamang bilang.
• ibig sabihin - Ang pagbabasa ay ang ibig sabihin ng halaga sa loob ng panahong ipinahiwatig sa Granularity
• Net - Naghahanda ang metro o [mapagkukunan] ng sarili nitong pagkalkula ng kabuuang paggamit sa paglipas ng panahon.
• Tuktok - Ang pagbabasa ay Puro (pinakamataas) na halaga sa paglipas ng panahon na ipinahiwatig sa granularity. Para sa ilang mga sukat, maaari itong magkaroon ng higit na kahulugan bilang pinakamababang halaga. Maaaring hindi kaayon sa pinagsamang pagbabasa. May bisa lang para sa flow-rate na Mga Base sa Item, ibig sabihin, Power not Energy.
• Inaasahang - Isinasaad ang pagbabasa ay sa hinaharap, at hindi pa nasusukat.
• Na-summed - Maraming metro na magkakasama na nagbibigay ng pagbabasa para sa [mapagkukunang] ito. Partikular itong naiiba kaysa sa pinagsama, na tumutukoy sa maraming [mapagkukunan] sa parehong kargamento. Tingnan din ang Hybrid.
• x-notApplicable - Hindi maaari
• x-RMS - Root ibig sabihin ng square

ulat ng Pangalan

• HISTORY_GREENBUTTON - Isang ulat na naglalaman ng data ng greenbutton sa isang istraktura ng feed ng atom feed
• KASAYSAYAN_USAGE - Isang ulat na naglalaman ng data ng paggamit ng enerhiya na histrorical
• METADATA_HISTORY_GREENBUTTON - Isang ulat ng metadata na tumutukoy sa mga kakayahan sa pag-uulat para sa mga ulat sa HISTORY_GREENBUTTON
• METADATA_HISTORY_USAGE - Isang ulat sa metadata na tumutukoy sa mga kakayahan sa pag-uulat para sa mga ulat sa HISTORY_USAGE
• METADATA_TELEMETRY_STATUS - Isang ulat ng metadata na tumutukoy sa mga kakayahan sa pag-uulat para sa mga ulat sa TELEMETRY_STATUS
• METADATA_TELEMETRY_USAGE - Isang ulat ng metadata na tumutukoy sa mga kakayahan sa pag-uulat para sa mga ulat sa TELEMETRY_USAGE
• TELEMETRY_STATUS - Isang ulat na naglalaman ng impormasyon sa katayuan ng real time na mapagkukunan tulad ng online na estado
• TELEMETRY_USAGE - Isang ulat na naglalaman ng impormasyon ng paggamit ng enerhiya sa real time

ulat ng uri

Isang binilang na halagang nagbibigay ng uri ng ulat na ibinigay.

• magagamitEnergyStorage - Magagamit ang kapasidad para sa karagdagang pag-iimbak ng enerhiya, marahil upang makapunta sa Target na Imbakan ng Enerhiya
• avgDemand - Average na paggamit sa tagal na ipinahiwatig ng Granularity. Tingnan ang pangangailangan para sa karagdagang impormasyon.
• avgUsage - Average na paggamit sa tagal na ipinahiwatig ng Granularity. Tingnan ang paggamit para sa karagdagang impormasyon.
• baseline - Maaaring maging demand o paggamit, tulad ng ipinahiwatig ng ItemBase. Isinasaad kung ano ang [pagsukat] kung hindi para sa kaganapan o regulasyon. Ang ulat ay nasa format na Baseline.
• deltaDemand - Pagbabago ng pangangailangan kumpara sa baseline. Tingnan ang pangangailangan para sa karagdagang impormasyon
• deltaSetPoint - Mga pagbabago sa setpoint mula sa nakaraang iskedyul.
• deltaUsage - Pagbabago sa paggamit kumpara sa baseline. Tingnan ang paggamit para sa karagdagang impormasyon
• demand - Ang ulat ay nagpapahiwatig ng isang halaga ng mga yunit (denominated sa ItemBase o sa EMIX Product). Ang uri ng payload ay Dami. Ang isang tipikal na ItemBase ay Tunay na Lakas.
• paglihis - Pagkakaiba sa pagitan ng ilang mga tagubilin at tunay na estado.
• downRegulationCapacity Magagamit - Magagamit ang Down na kakayahan sa Regulasyon para sa pagpapadala, na ipinahayag sa EMIX Real Power. Ang payload ay laging ipinahayag bilang positibong Dami.
• antas - simpleng antas mula sa merkado sa bawat pagitan.
• operatingState - Pangkalahatang estado ng isang mapagkukunan tulad ng on / off, pananatili ng gusali, atbp Walang ItemBase na nauugnay. Nangangailangan ng isang Extension ng Partikular na Payload ng Application.
• porsyentoDemand - Percentage ng demand
• porsyentoGamit - Percentage ng paggamit
• powerFactor - Power factor para sa mapagkukunan
• presyo - Presyo bawat ItemBase sa bawat Pagitan
• pagbabasa - Ang ulat ay nagpapahiwatig ng pagbasa, mula sa isang metro. Ang mga pagbasa ay sandali sa mga pagbabago sa oras sa paglipas ng panahon ay maaaring makalkula mula sa pagkakaiba sa pagitan ng sunud-sunod na pagbabasa. Ang uri ng payload ay float
• regulasyonSetpoint - Ang setpoint ng regulasyon na itinuro bilang bahagi ng mga serbisyo sa regulasyon
• setPoint - Isinasaad ng ulat ang halaga (denominado sa ItemBase o sa Produkto ng EMIX) na kasalukuyang itinakda. Maaaring isang kumpirmasyon / pagbabalik ng halaga ng kontrol ng setpoint na ipinadala mula sa VTN. Ang uri ng payload ay Dami. Ang isang tipikal na ItemBase ay Tunay na Lakas.
• nakaimbakEnergy - Ang Nakaimbak na Enerhiya ay ipinahayag bilang Tunay na Enerhiya at Payload ay ipinahiwatig bilang isang Dami.
• targetEnergyStorage - Target na Enerhiya ay ipinahayag bilang Real Enerhiya at Payload ay ipinahayag bilang isang Dami.
• upRegulationCapacityA magagamit - Up na Kakayahang umayos na magagamit para sa pagpapadala, na ipinahayag sa EMIX Real Power. Ang payload ay laging ipinahayag bilang positibong Dami.
• paggamit - Ang ulat ay nagpapahiwatig ng isang halaga ng mga yunit (denominated sa ItemBase o sa EMIX Product) sa loob ng isang panahon. Ang uri ng payload ay Dami. Ang isang tipikal na ItemBase ay RealEnergy
• x-resourceStatus - Percentage ng demand

scaleCode

• p - Pico 10 ** - 12
• n - Nano 10 ** - 9
• micro - Micro 10 ** - 6
• m - Milli 10 ** - 3
• c - Centi 10 ** - 2
• d - Deci 10 ** - 1
• k - Kilo 10 ** 3
• M - Mega 10 ** 6
• G - Giga 10 ** 9
• T - Tera 10 ** 12
• wala - Likas na Kalakasan

signalName

• BID_ENERGY - Ito ang halaga ng enerhiya mula sa isang mapagkukunan na nai-bid sa isang programa
• BID_LOAD - Ito ang halaga ng load na na-bid ng isang mapagkukunan sa isang programa
• BID_PRICE - Ito ang presyo na na-bid ng mapagkukunan
• CHARGE_STATE - Estado ng mapagkukunan ng imbakan ng enerhiya
• DEMAND_CHARGE - Ito ang singil sa demand
• ELECTRICITY_PRICE - Ito ang gastos ng kuryente
• ENERGY_PRICE - Ito ang gastos ng enerhiya
• LOAD_CONTROL -Takda ang output ng pag-load sa mga kamag-anak na halaga
• LOAD_DISPATCH - Ginagamit ito upang maipadala ang pagkarga
• simple lang - nabawasan - para sa paatras na pagiging tugma sa Isang profile
• SIMPLE - Mga simpleng antas (sumusunod sa OpenADR 2.0a)

uri ng signal

Isang binilang na halagang naglalarawan sa uri ng signal tulad ng antas o presyo

• delta - Isinasaad ng signal ang halaga upang mabago mula sa kung ano ang maaaring magamit nang walang signal.
• antas - Ang senyas ay nagpapahiwatig ng antas ng programa.
• dumamir - Ang senyas ay nagpapahiwatig ng isang multiplier na inilapat sa kasalukuyang rate ng paghahatid o paggamit mula sa kung ano ang maaaring magamit nang walang signal.
• presyo - Sinasaad ng signal ang presyo.
• presyoMultiplier - Ipinapahiwatig ng signal ang multiplier ng presyo. Ang pinalawig na presyo ay ang compute na halaga ng presyo na pinarami ng bilang ng mga yunit.
• Kaugnay - Sinasaad ng signal ang kamag-anak na presyo.
• setpoint - Ang senyas ay nagpapahiwatig ng isang target na halaga ng mga yunit.
• x-loadControlCapacity - Ito ay isang tagubilin para sa load controller upang mapatakbo sa isang antas na ilang percentage ng maximum na kapasidad sa pagkonsumo ng pagkarga nito. Maaari itong mapa sa tukoy na mga tagakontrol ng pag-load upang magawa ang mga bagay tulad ng duty cycling. Tandaan na ang 1.0 ay tumutukoy sa 100% na pagkonsumo. Sa kaso ng mga simpleng uri ng ON / OFF na aparato pagkatapos 0 = OFF at 1 = ON.
• x-loadControlLevelOffset - Discrete antas ng integer na kaugnay sa normal na operasyon kung saan 0 ay normal na operasyon.
• x-loadControlPercentOffset - Percentage pagbabago mula sa normal na pagpapatakbo ng pagkontrol sa pag-load.
• x-loadControlSetpoint - Mga puntos na itinakda ng load ng controller.

- OpenADR A at B Profile Mga Pagkakaiba

Ang nag-iisang serbisyo na suportado ng A profile ay ang serbisyo ng EiEvent. Ang object ng EiEvent ay pinasimple sa A profile na may mga sumusunod na hadlang:

• Isang signal lang bawat kaganapan ang pinapayagan at ang signal na iyon ay dapat na isang kilalang signal na OpenADR na SIMPLE.
• Mayroong isang limitadong pag-target sa kaganapan na sinusuportahan lamang ang venID, groupID, resourceID, at partyID. (EiEvent: eiTarget).
• Ang pag-target sa antas ng signal na may mga klase ng aparato ay hindi suportado (eiEventSignal: eiTarget: endDeviceAsset).
• Hindi sinusuportahan ang mga baseline (eiEvent: eiEventSignals: eiEventBaseline).
• Ang modificationDateTime at modificationReason ay hindi suportado.
• Ang endpoint URL para sa simpleng HTTP sa 2.0b ay:
  • https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Ang ilang mga elemento ng payload na kinakailangan sa A profile opsyonal ngayon sa B profile, kabilang ang:

• kasalukuyangValue

- Mga OpenADR Security Certificate

Ang mga patakaran sa pagsunod sa OpenADR ay nangangailangan ng sumusunod:

• Ang TLS Bersyon 1.2 ay ginagamit para sa palitan ng mga sertipiko ng X.509
• Ang VTN ay dapat mayroong parehong SHA256 ECC at RSA na mga sertipiko
• Maaaring suportahan ng mga VEN ang alinman sa mga sertipiko ng SHA256 ECC at RSA, at maaaring suportahan ang pareho
• Parehong dapat na mai-configure ang parehong mga VTN at VEN upang humiling ng mga sertipiko ng kliyente kung gampanan nila ang papel ng isang server ng transportasyon (hal. Pagtugon sa mga kahilingan mula sa kabilang partido)
• Ang parehong mga VTN at VEN ay dapat magbigay ng isang sertipiko ng kliyente kapag hiniling ng ibang partido bilang bahagi ng proseso ng negosasyon ng TLS

Ang mga sertipiko na ibinigay ng NetworkFX ay magiging tukoy sa RSA o ECC. Ang paglikha ng mga sertipiko na ito ay maaaring mangyari bilang mga resulta ng pagpuno ng mga form sa NetworkFX web site upang humiling ng mga sertipiko ng pagsubok o maaaring maging resulta ng paghiling ng mga sertipiko ng produksyon sa pamamagitan ng isang Kahilingan sa Pag-sign ng Certificate (CSR). Anuman ang pamamaraan, ang sumusunod files ay ibibigay (halampipinakita ang les):

• Sertipiko ng ugat
• Intermediate Root Certificate
• Sertipiko ng Device
• Pribadong Susi

Sa pangkalahatan, ginagamit ang Pribadong Susi upang mag-encrypt ng mga kargamento na ipinadala ng isang VEN o VTN. Ang Device Certificate ay isang hanay ng natatanging impormasyon sa pagkilala tungkol sa isang VEN o VTN na nilikha ng isang Certificate Authority at naka-encrypt gamit ang Pribadong Key. Ang Root at Intermediate fileginagamit ang mga s upang mai-decrypt ang Device Certificate at patunayan na ang sertipiko ay nagmula sa isang pinagkakatiwalaang awtoridad.

Sa isang kapaligiran sa Java na gumagamit ng JSSE, mayroong dalawang mga tindahan ng sertipiko. Ang isa ay tinatawag na Trust Store at ginagamit upang hawakan ang Root Certificate. Ang pangalawa ay tinawag na isang Key Store at ginagamit upang mag-imbak ng isang sertipiko ng sertipiko na binubuo ng sertipiko ng pansamantalang sertipiko ng aparato, pati na rin ang pribadong key

Mangyaring tandaan na kapag gumagamit ng isang XMPP transport ang VEN ay nakikipag-usap sa server ng XMPP at HINDI direkta sa VTN. Kaya ang pagsasaayos ng mga sertipiko sa server ng XMPP ay DAPAT na katumbas ng isang VTN. Ang komunikasyon sa pagitan mismo ng VTN at ng server ng XMPP ay transparent sa VEN at mahalagang isang pribadong link. Gayunpaman, ang karamihan sa mga vendor ay gumamit ng isang hanay ng mga VEN certs sa VTN kapag nakikipag-usap sa server ng XMPP.

Kung gumagamit ka ng OpenFire bilang iyong XMPP server, may isa pang pagpipigil na dapat mong isaalang-alang. Kinakailangan ng OpenFire na ang pangalan ng CN na ginamit sa mga sertipiko ng aparato ng client ay tumutugma sa mga aparato XMPP username na na-configure sa XMPP server. Maaari itong magresulta sa ilang mga kakatwang mga pangalan ng kliyente tulad ng isang MAC tulad ng address na ginagamit para sa pangalan ng CN sa mga sertipiko ng VEN (Bahagi ng Mga Kinakailangan sa OpenADR Security)

Sa wakas, ang karamihan sa mga VEN at VTN kapag ginagampanan ang papel ng isang client ng transportasyon ay susubukan na patunayan na ang patlang ng sertipiko na ibinigay ng CN ng server ng transport ay may isang pangalan na CN na tumutugma sa host na pangalan ng nilalang na nagbigay ng sertipiko. Maaaring ito ay isa pang mapagkukunan ng mga problema sa interoperability kapag nagpapalitan ng mga sertipiko. Karaniwang maaaring hindi paganahin ang Pag-verify ng Pangalan ng Host nang programatic upang ihiwalay ang mga ganitong uri ng isyu.

OpenADR 2.0 Gabay sa Programa ng Pagtugon sa Demand - I-download ang [na-optimize]
OpenADR 2.0 Gabay sa Programa ng Pagtugon sa Demand - I-download

Mga sanggunian

• User Manual