OpenADR 2.0

Pandhuan Program Respon Permintaan

Nomer Revisi: 0.92

Status Dokumen: Teks Makarya

Nomer Dokumen: 20140701

Hak cipta © OpenADR Alliance (2014/15). Kabeh hak dilindhungi undhang-undhang. Informasi ing dokumen iki minangka properti saka OpenADR Alliance lan panggunaan lan pambocoran diwatesi.

ISI

1 Pambuka 6

2 Referensi 6

3 Syarat lan Definisi 6

4 Cekakan 9

5 Jinis Program Tanggepan Panjaluk 9

6 Skenario Penyebaran 10

6.1 Langsung 1 11

6.2 Langsung 2 12

6.3 Langsung 3 13

6.4 Langsung 4 14

6.5 Fasilitator 1 15

6.6 Agregator 1 16

7 Skenario Penyebaran lan Pemetaan Program DR 16

8 Milih Cithakan Program DR 18

9 Cithakan Program Tanggepan Panjaluk 21

9.1 Program Harga Puncak Kritik (CPP) 21

9.1.1 Karakteristik Program DR CPP 21

9.1.2 Karakteristik OpenADR kanggo Program CPP 22

9.2 Program Penawaran Kapasitas 24

9.2.1 Karakteristik Program DR Penawaran Kapasitas 24

9.2.2 Karakteristik OpenADR kanggo Program Penawaran Kapasitas 25

9.3 Program Termostat Perumahan 27

9.3.1 Karakteristik Program DR Thermostat Perumahan 27

9.3.2 Karakteristik OpenADR kanggo Program Termostat Perumahan 28

9.4 Pengiriman DR Cepet 29

9.4.1 Karakteristik Program Pengiriman DR Cepet 29

9.4.2 Karakteristik OpenADR kanggo Program Penawaran Kapasitas 31

9.5 Program Nggunakake Kendaraan Listrik (EV) Wektu Gunakake (TOU) 33

9.5.1 Karakteristik Program EV TOU Residential 33

9.5.2 Karakteristik OpenADR kanggo Program EV TOU Residential 33

9.6 Program Penetapan Warta Listrik Stasiun Publik (EV) Real-Time 34

9.6.1 Karakteristik Program EV RTP Stasiun Publik 34

9.6.2 Karakteristik OpenADR kanggo Program RTP EV Stasiun Publik 34

9.7 Program DR Sumber Daya Energi Disebar (DER) 35

9.7.1 Karakteristik Program Sumber Daya Energi Distribusi (DER) 35

9.7.2 Karakteristik OpenADR kanggo Sumber Daya Energi Disebar (DER) 35

Lampiran A – SampCithakan Data lan Muatan 36

A.1 Program Harga Puncak Kritik (CPP) 36

A.1.1 CPP Skenario 1 – Prasaja Gunakake cilik, A utawa B Profile 36

A.1.2 Skenario CPP 2 – Kasus Panggunaan Khas, B profile 36

A.1.3 Skenario CPP 3 - Kasus Panganggone Komplek 37

A.1.4 CPP SampBeban Acara - Khas B Profile Gunakake Kasus 37

A.2 Program Penawaran Kapasitas (CBP) 39

A.2.1 CBP Skenario 1 – Prasaja Gunakake cilik, A utawa B Profile 39

A.2.2 Skenario CBP 2 – Kasus Panggunaan Khas, B profile 39

A.2.3 Skenario CBP 3 - Kasus Panganggone Komplek 40

A.2.4 CBP SampBeban Acara - Khas B Profile Gunakake Kasus 40

A.3 Program Termostat Perumahan 42

A.3.1 Residential Thermostat Skenario 1 – Prasaja Gunakake cilik, A utawa B Profile 42

A.3.2 Skenario Termostat Residential 2 – Kasus Panggunaan Khas, B profile 42

A.3.3 Skenario Termostat Perumahan 3 - Kasus Panganggone Komplek 43

A.3.4 Termostat Perumahan SampBeban Acara - Khas B Profile Gunakake Kasus 43

A.4 Pengiriman DR Cepet 45

A.4.1 Skenario DR Cepet 1 - Kasus Gunakake Prasaja, A utawa B Profile 45

A.4.2 Skenario DR Cepet 2 - Kasus Gunakake Khas, B profile 45

A.4.3 Skenario DR Cepet 3 - Kasus Panganggone Komplek 46

A.4.4 Cepet DR SampBeban Acara - Khas B Profile Gunakake Kasus 46

A.4.5 Cepet DR Sample Laporan Metadata Payload - Khas B Profile Gunakake Kasus 48

A.4.6 Cepet DR Sample Report Request Payload - Khas B Profile Gunakake Kasus 48

A.4.7 Cepet DR Sample Laporan Payload Data - Khas B Profile Gunakake Kasus 49

A.5 Program Nggunakake Kendaraan Listrik (EV) Waktu Gunakake (TOU) 49

A.5.1 Residential EV Skenario 1 – Prasaja Gunakake cilik, A utawa B Profile 49

A.5.2 Skenario EV Residential 2 – Kasus Gunakake Khas, B profile 50

A.5.3 Perumahan EV SampBeban Acara - Khas B Profile Gunakake Kasus 50

A.6 Program Penetapan Real-Time Kendaraan Listrik (EV) 53

A.6.1 Skenario EV Stasiun Umum 1 - Kasus Gunakake Khas, B profile 53

A.6.2 Stasiun Umum EV SampBeban Acara - Khas B Profile Gunakake Kasus 53

A.7 Program DR Sumber Daya Energi Disebar (DER) 54

Annex B - Definisi Layanan lan Payload 55

B.1 Open ADR ndhukung layanan ing ngisor iki: 55

Annex C - Definisi Layanan lan Payload 56

C.1 Beban EiEvent 56

C.2 Beban EiReport 56

C.3 Beban EiOpt 56

C.4 Beban Partai EiRegister 57

C.5 Beban OadrPoll 57

Annex D - Glosarium Unsur Payload Skema 58

Annex E Glosari Nilai Enominasi 65

Acara E.1Status 65

E.2 itemUnit 65

E.3 oadrDataQualitas 65

E.4 oadrReponseRequired 66

E.5 milihAlasan 66

E.6 oadrTransportName 66

E.7 OptType 66

Wacan E.8Jinis 66

Laporan E.9Name 67

Laporan E.10Jenise 67

Skala E.11 Kode 68

Sinyal E.12Name 68

Sinyal E.13Jenis 69

Lampiran F - OpenADR A lan B Profile Bedane 70

Annex G - Sertifikat Keamanan OpenADR 71

Pambuka

Target pamirsa kanggo pandhuan iki yaiku ngrancang utilitas kanggo nggunakake program Respon Tanggepan (DR) sing nggunakake OpenADR 2.0 kanggo komunikasi pesen sing ana gandhengane karo DR antarane entitas utilitas lan hilir, lan pabrikan peralatan sing nggampangake pertukaran komunikasi kasebut. Dianggep manawa pamaca duwe pangerten konsep dhasar babagan respon panjaluk lan OpenADR 2.0 (mung diarani OpenADR wiwit saiki).

OpenADR profile specifications cetha nemtokake prilaku samesthine nalika ijol-ijolan informasi DR acara related, Nanging ana cukup pilihan ing OpenADR sing penyebaran prajurit (VTNs) ing sarana lan klien (VEN) ing situs hilir ora plug-n-play pengalaman. Karakteristik OpenADR kayata sinyal acara, format laporan, lan nargetake kudu ditemtokake ing basis program-by-program DR.

Ora ana sing diarani program DR standar. Saben desain program DR cenderung unik, cocog karo persyaratan struktural lan peraturan ing wilayah geografis sing digunakake. Kanggo saben program DR, bisa uga ana skenario penyebaran sing ana gandhengane karo macem-macem aktor.

Variabilitas ing desain program DR, skenario penyebaran, lan karakteristik OpenADR minangka hambatan kanggo nambah penyebaran DR lan panggunaan OpenADR. Variabilitas iki umume nggambarake fragment lan sifat kompleks grid sing cerdas.

Utilitas kudu examples saka program DR khas supaya padha bisa digunakake minangka model kanggo implementasine program DR dhewe. Produsen peralatan kudu ngerti model panggunaan Program DR sing khas supaya bisa ngesyahke interoperabilitas minangka bagean saka proses pangembangan tinimbang ing basis khusus penyebaran program DR. Tujuan saka pandhuan iki yaiku kanggo ngrampungake loro tujuan kasebut:

• Netepake sakumpulan template DR Program standar sing dimodelake miturut karakteristik umum program DR paling populer sing diterapake nganti saiki
• Temtokake sawetara skenario penyebaran cilik sing dimodelake sawise tugas nyata, kanthi aktor lan peran sing wis dingerteni kanthi jelas
• Temtokake rekomendasi praktik paling apik kanggo karakteristik OpenADR khusus kanggo saben template Program DR
• Nyedhiyakake wit keputusan sing bisa digunakake utilitas kanggo ngenali template program DR lan skenario penyebaran sing migunani adhedhasar kabutuhan bisnis

Penekanan ing pandhuan iki yaiku supaya tetep gampang, kanthi menehi sawetara rekomendasi sing jelas sing bakal ngatasi mayoritas rincian sing dibutuhake kanggo nyebarke program DR khas, lan supaya bisa nyoba tes interoperabilitas piranti sing digunakake ing program nggunakake rekomendasi ing pandhuan.

Referensi

• OpenADR Profile Spesifikasi lan skema - www.openadr.org

Sarat lan Definition

Syarat lan definisi ing ngisor iki digunakake ing dokumen iki.

• Tanggapan Panjaluk: Mekanisme kanggo ngatur permintaan beban pelanggan kanggo nanggepi kondisi pasokan, kayata rega utawa sinyal kasedhiyan
• Partai Aggregator - Iki minangka partai sing nggabungake macem-macem Sumber Daya lan diwenehake menyang Partai Program DR minangka Sumber Daya ing Program DR.
• Infrastruktur Perantara Aggregator - Iki minangka infrastruktur, kapisah saka Infrastruktur Sisih Permintaan, sing digunakake dening Partai Perantara Aggregator kanggo sesambungan karo Sumber Daya lan entitas sisi kisi
• kasepakatan: Kesepakatan kontrak antarane pihak sing duwe peran ing program DR sing negesake tanggung jawab lan kompensasi
• Aset - Jinis Sumber Daya sing makili koleksi beban fisik tartamtu. Sumber bisa digawe saka Aset, lan Aset bisa uga Sumber Daya, nanging Aset ora bisa dibusuk dadi pirang-pirang Aset utawa Sumber Daya.
• Digandhengake: Nyedhiyakake asosiasi programmatic ing antarane rong entitas, liwat konfigurasi piranti database. Contone, sumber daya sing gegandhengan karo VEN
• Dhasar: Panggunaan (panjaluk) energi sing diwilang utawa diukur dening peralatan utawa situs sadurunge kedadeyan kaya sing ditemtokake liwat survey, inspeksi, lan / utawa pengukuran ing situs kasebut.
• BMS - Iki minangka Sistem Manajemen Bangunan sing bisa digunakake kanggo ngontrol sumber daya. Kadhangkala iki diarani Sistem Manajemen Energi.
• Sumber Senyawa - Iki minangka jinis Sumber Daya khusus sing dadi gabungan saka macem-macem aset fisik sing masing-masing duwe cara kontrol beban dhewe-dhewe.
• Insentif Pelanggan: Induksi kanggo pemilik / agregator sumber daya panjaluk kanggo partisipasi ing program DR.
• Infrastruktur Sisih Panjaluk - Iki minangka prasarana sing nyedhiyakake Sumber Daya sing wis terdaftar ing Program DR
• Logika DR: Algoritma utawa logika sing ngowahi sinyal DR dadi kontrol beban sing bisa ditindakake. Elinga yen DR Logic bisa uga diterapake ing macem-macem lokasi lan ing sawetara kasus disebarake ing macem-macem sub-sistem.
• Partai Program DR - iki minangka entitas sing tanggung jawab kanggo Infrastruktur Grid lan uga kanggo ngatur Program DR sing digunakake kanggo ngatasi masalah kothak. Iki biasane Utility utawa ISO.
• Ndhaptar: Pamilik / agregator sumber daya permintaan milih melu program DR lan bisa menehi informasi babagan sumber daya tartamtu sing bisa ditargetake kanggo acara DR
• Periode Aktif Acara: Ing iku wektu ing wektu nalika owah-owahan ing pro mbukakfile dijaluk minangka bagéan saka Acara DR
• Watesan Acara: Jangka wektu sajrone pelanggan bisa ngarep-arep nampa acara lan alangan sing gegandhengan kayata ora ana acara ing akhir minggu utawa dina berturut-turut
• Dina acara: Dina nalika ana acara DR. Umume program duwe watesan babagan jumlah dina acara sing diidini ing wektu tanggalan tartamtu
• Descriptor Acara: Bagéan saka obyek acara OpenADR sing njlentrehake metadata babagan acara kasebut, kayata jeneng program lan prioritas acara
• Duration saka acara: Suwene adicara. Umume program nemtokake watesan babagan dawa acara, uga jam dina sajrone kedadeyan kasebut bisa kedadeyan
• Sinyal Acara: Informasi sing bisa ditindakake sing ana ing sawijining acara kayata rega listrik utawa level gudang khusus sing dijaluk sing biasane nyebabake sawetara prilaku ngeculake pra-diprogram dening panampa acara kasebut. Definisi program DR kudu nemtokake jinis sinyal acara sing digunakake
• Penargetan Acara: Sumber daya tumpahan momotan sing bakal dadi panampa acara DR. Bisa uga wilayah geografis, kelas piranti tartamtu, pengenal klompok, ID sumber, utawa pengenal liyane. Definisi program DR kudu nemtokake cara sumber daya tartamtu sing bakal dituju.
• Acara: Acara minangka kabar saka sarana kanggo nuntut sumber daya sisih sing njaluk gudang diwiwiti ing wektu tartamtu, sajrone wektu sing ditemtokake, lan bisa uga kalebu informasi nargetake kanggo milih sumber daya tartamtu sing kudu melu ing acara kasebut
• Infrastruktur Perantara Fasilitator - Iki minangka prasarana, beda karo Infrastruktur Sisih Permintaan, sing digunakake dening Partai Perantara Fasilitator kanggo berinteraksi karo Sumber Daya lan entitas sisi kisi.
• Fasilitator: Pihak katelu sing ngatur sawetara utawa kabeh eksekusi program DR atas jenenge utilitas
• Infrastruktur Kisi - Iki minangka infrastruktur sing diduweni utawa dikelola dening Partai Program DR. Infrastruktur iki kalebu implementasi OpenADR VTN sing digunakake kanggo ngirim sinyal DR menyang Sumber Daya sing didhaptar ing Program DR
• Partai Penengah - Iki minangka partai sing biasane digunakake kanggo pihak Partai Sumber Daya kanggo nggampangake partisipasi ing Program DR.
• Kontrol beban - iki minangka infrastruktur sing ana gandhengane karo Sumber Daya sing tanggung jawab kanggo ngontrol Sumber Daya lan ngasilake beban khusus.file.
• Mbukak Profile Tujuane: Motivasi iki nggawe program DR lan nerbitake acara. Kayata kepinginan kanggo nyukur beban puncak.
• Notifikasi: Periode wektu sadurunge wektu wiwitan acara ing endi pamilik sumber daya dikarepake dikabari babagan acara sing ditundha
• Milih Tumindak: Tanggepan sing diarepake saka pamilik sumber daya sisih panjaluk nalika nampa acara. Tanggepan iki bisa uga wujud lan pratondo OptIn utawa OptOut manawa sumber daya bakal melu ing acara kasebut
• Milih Tanggepan: Apa program tartamtu mbutuhake respon saka sumber daya panjaluk kanggo nanggepi acara, lan apa tanggepan kasebut biasane.
• Layanan Opt: Jadwal dikomunikasikake liwat OpenADR kanggo nunjukake pangowahan sementara sing kasedhiya kanggo melu acara.
• Prasyarat: Kriteria sing kudu dipenuhi supaya pamilik sumber daya sing dikarepake kudu ndhaptar ing program DR. Iki bisa uga kalebu kasedhiyan rapat interval utawa sawetara kapasitas minimum load load
• Drivers Utama: Motivasi utama bagean saka sarana kanggo nggawe program DR lan nerbitake acara. Kayata "Pangurangan permintaan puncak lan kecukupan sumber daya"
• Program - Iki minangka Program DR sing didaftarake Sumber Daya.
• Deskripsi Program: Katrangan narasi babagan cara kerja program. Bagéan saka template Program DR sing ditemtokake ing dokumen iki
• Bingkai Wektu Program: Wektu taun utawa musim sajrone program DR biasane aktif
• Desain Rating: Modifikasi spesifik kanggo struktur tarif utawa insentif sing dibayar kanggo motivasi pamilik sumber daya sisih dikarepake supaya melu ing program kasebut
• Layanan Registrasi: Layanan sing digunakake dening protokol OpenADR kanggo nggawe interoperabilitas dhasar antarane VTN lan VEN, lan kanggo ngesyahake manawa VEN digandhengake karo akun pelanggan utilitas.
• Layanan Reporting: Layanan sing digunakake dening OpenADR kanggo ngaktifake VENs kanggo nglaporake VEN. Program DR kudu nemtokake syarat pelaporan kanggo program kasebut.
• Partai Sumber Daya - Iki minangka pihak sing duwe Sumber Daya panjaluk sing bisa didaftar ing Program DR
• sumber daya - Iki minangka entitas sing didaftarkan ing Program DR lan bisa ngirim sawetara owah-owahan menyang pro load.file kanggo nanggepi sinyal DR saka VTN.
• Target Pelanggan: Ing profile sumber daya sisih dikarepake sing bisa ndaftar ing program DR tartamtu kayata omah, industri, utawa mbok menawa adhedhasar tingkat konsumsi listrik.
• Beban Target: Sumber daya panjaluk sing beban sing kudu diowahi nalika ditampa a
• VEN - Iki minangka OpenADR Virtual End Node sing digunakake kanggo sesambungan karo VTN.
• VTN - Iki minangka OpenADR Virtual Top Node sing digunakake kanggo sesambungan karo Sumber Daya sing didaftar ing Program DR.

Singkatan

• BMS: Sistem Manajemen Bangunan
• C&I: Komersial lan Industri
• Comm: Komunikasi antarane rong entitas
• DR: Tanggepan Panjaluk
• EMS: Sistem Manajemen Energi
• OpenADR: Respon Permintaan Otomatis Mbukak
• Program: Referensi Program Respon Permintaan
• VEN: Virtual End Node
• VTN: Node Top Virtual

Jinis Program Respon Permintaan

Dokumen iki ngemot template kanggo program DR sing ditampilake ing ngisor iki.

 

1. Rega Puncak Kritikal: Struktur tarif lan / utawa rega sing dirancang kanggo nyengkuyung konsumsi suda ing rega pasar grosir utawa kontingensi sistem kanthi ngetrapake tarif utawa rega sing wis ditemtokake sawetara dina utawa jam winates.

2. Program Penawaran Kapasitas: Program sing ngidini sumber panjaluk ing pasar ritel lan grosir nawakake pengurangan muatan kanthi rega, utawa kanggo ngerteni pira momotan sing dikepengini kanthi rega tartamtu.

 

3. Program Termostat Perumahan / Kontrol Muat Langsung: Kegiatan tanggepan panjaluk sing sponsor program mbatalake ngontrol peralatan listrik pelanggan (kayata AC) kanthi cepet. Program kasebut utamane ditawakake kanggo pelanggan komersial utawa perumahan cilik.

4. Program Layanan DR Cepat / Ancillary DR: Program nanggepi panjaluk sing menehi pambayaran insentif kanggo para pelanggan kanggo nanggepi beban sajrone Acara Tanggapan Permintaan Darurat. Kondisi sistem abnormal (misample, alangan sistem lan alangan kapasitas lokal) sing mbutuhake tumindak manual otomatis utawa langsung kanggo nyegah utawa matesi Gagal fasilitas transmisi utawa sumber generasi sing bisa mengaruhi linuwih saka Bulk Electric System. Jinis program iki kadhangkala bisa diarani minangka "Layanan Tambahan".

5. Program DR Kendaraan Listrik (EV): Kegiatan tanggepan panjaluk kanthi biaya ngisi daya kendaraan listrik diowahi supaya konsumen ngowahi pola konsumsi.

6. Program DR Sumber Daya Energi Disebar (DER): Kegiatan tanggepan panjaluk digunakake kanggo lancar integrasi distribusi sumber energi menyang kothak cerdas.

 

Skenario Penyebaran

Cara nggelar program DR rada bebas karo karakteristik program DR kasebut dhewe. Diagram ing ngisor iki nuduhake macem-macem cara program DR bisa digunakake. Bagean ing ngisor iki menehi referensi silang antarane skenario penyebaran lan Program DR sing umume bisa digunakake.

Diagram ing bagean iki nuduhake hubungan antarane entitas ing macem-macem skenario.

Langsung 1

Iki minangka skenario prasaja sing ana hubungan langsung antarane Partai Program DR lan Partai Sumber Daya. Partai Sumber Daya tanggung jawab kanggo ndhaptar Sumber Daya dhewe menyang Program DR lan Infrastruktur Grid sesambungan langsung karo Sumber Daya liwat VEN sing manggon ing Infrastruktur Sisih Permintaan. Salajengipun VEN diduweni dening Partai Sumber Daya lan kapisah saka Sumber Daya lan pengontrole. Nalika sinyal DR ditampa dening VEN biasane ora ngleksanakake sembarang logika kontrol mbukak, nanging mung forwards sinyal menyang controller mbukak sing njupuk tindakan cocok. Examples saka skenario iki bakal kalebu C & bangunan aku sing bisa nginstal gateway sing ngemot OpenADR VEN lan nalika sinyal ditampa dening gateway iku mung nerjemahake menyang sawetara protokol liyane lan nerusake menyang controller mbukak piyambak.

Langsung 2

Iki meh padha karo skenario Direct 1. Bentenipun utama ing cara VEN instantiated lan interaksi karo VTN difasilitasi. VEN wis instantiated ing entitas kaya BMS terpusat sing bisa ngleksanakake logika DR lan sesambungan karo Compound Resource lan akeh macem-macem controller mbukak saka lokasi sing luwih terpusat. Exampkalebu bangunan gedhe kanthi BMS sing ngontrol macem-macem beban ing sawijining bangunan (contone, lampu, HVAC, proses industri, lsp) nganti camppanggunaan sing bisa uga duwe macem-macem fasilitas kanthi sistem kontrol terpusat.

Langsung 3

Skenario iki meh padha karo skenario Direct 1. Bentenipun utama sing VEN instantiated langsung ing sumber lan controller mbukak. Ing kasus iki sinyal DR dikirim langsung menyang sumber lan controller mbukak. Skenario "rega kanggo piranti" kalebu ing kategori iki. Examples bakal kalebu sembarang Urut saka mbukak controller kayata HVAC (IE thermostat) sing wis ditempelake VEN sing saged sesambungan langsung karo èntitas sisih kothak VTN.

Langsung 4

Iki minangka kombinasi saka skenario Direct 1 lan Direct 2. Bentenane utama yaiku macem-macem VEN digandhengake karo siji Sumber Senyawa sing kalebu macem-macem aset kanthi pengontrol beban dhewe. Saben pengontrol beban sing kalebu Sumber Daya Senyawa bisa digandhengake karo VEN sing beda. Elinga yen kabeh VEN bakal dikendhaleni dening Partai Sumber Daya sing padha sing nduweni Sumber Daya Senyawa. Skenario iki ana kanggo nggampangake Infrastruktur Sisi Permintaan sing nduweni Sumber Daya Senyawa, nanging ora duwe BMS terpusat kaya skenario Direct 2. Examples bisa kalebu bangunan karo controller mbukak beda ing saben lantai, nanging ora BMS terpusat, utawa campnggunakake karo pengontrol beda ing saben bangunan, nanging ora campkita controller sudhut. Wiwit saka perspektif Partai Program DR mung ana siji sumber sing didaftar ing program nalika arep ngirim sinyal DR kanggo sumber bisa mung ngirim sinyal padha kanggo saben VEN ditetepake sing wis digandhengake karo Resource.

Fasilitator 1

Ing skenario iki ana perantara sing nggampangake interaksi antarane DR Program Party lan Resources. Biasane Partai Perantara kerja atas jenenge Partai Sumber Daya kanggo mbantu ngatur Sumber Daya. Pihak Sumber Daya duwe hubungan langsung karo Partai Program DR lan ndhaptar Sumber Daya dhewe menyang Program DR. Mangkono Partai Program DR viewSaben Partai Sumber Daya minangka Sumber Daya sing kapisah lan bisa sesambungan kanthi individu. Peran Partai Perantara yaiku tumindak minangka perantara kanggo kabeh interaksi sing gegandhengan karo OpenADR, saéngga VEN diwujudake ing Infrastruktur Perantara Fasilitator. Infrastruktur kasebut asring dadi basis awan lan ditawakake menyang Pihak Sumber Daya minangka Piranti Lunak minangka Layanan (SaaS). Nalika sinyal DR ditampa dening VEN Fasilitator sawetara tumindak beda bisa njupuk Panggonan kalebu nerusake sinyal DR kanggo Resource cocok lan bisa ngleksanakake sawetara Urut saka DR Logic lan ngirim printah kontrol mbukak kanggo saben Resource kang mbukak controller. Exampskenario iki kalebu:

• Vendor sing ngatur fasilitas kanggo rantai komersial gedhe kayata pengecer kothak gedhe.
• Perantara kontrol industri.
• Perusahaan Jasa Energi (ESCO)
• Sistem manajemen alat lan piranti adhedhasar awan kayata vendor termostat komunikasi cerdas.

Agregator 1

Skenario iki padha karo skenario Fasilitator. Bedane utama yaiku Partai Aggregator duwe hubungan karo Partai Program DR sing beda karo Partai Sumber Daya. Partai Aggregator nggabungake pirang-pirang Aset pelanggan dadi siji Sumber Daya sing didaftar ing Program DR. Partai Program DR ora duwe visibilitas menyang Aset individu sing diatur Aggregator. Kaya Fasilitator, Aggregator duwe prasarana dhewe-dhewe ing endi VEN diwiwiti. Bedane yaiku nalika sinyal DR ditampa referensi sumber tunggal lan Aggregator ngetrapake sawetara logika DR ing kabeh Aset ing portofolio kanggo nggayuh tujuan sing ditemtokake ing sinyal DR.

 

Skenario Penyebaran lan Pemetaan Program DR

Tabel ing ngisor iki nyedhiyakake skenario penyebaran sing paling umum kanggo Program DR tartamtu.

	Skenario Panyebaran
Cithakan DR	Langsung 1, 2, 3, 4	Fasilitator 1	Agregator 1
Program CPP	∆	∆
Program Penawaran Kapasitas			∆
Termostat Perumahan Program		∆
Pengiriman DR Cepet			∆
Program DR Kendaraan Listrik (EV)	∆	∆
Program DR Sumber Daya Energi Disebar (DER)	∆	∆

Milih Cithakan Program DR

Ing ngisor iki minangka sawetara pitakon sing ana gandhengane karo utilitas apa wae babagan implementasi program DR anyar. Iki ora dimaksudake kanggo lengkap, nanging nuduhake sawetara masalah sing luwih penting. Tujuan saka pitakon kasebut yaiku supaya bisa nuntun utilitas menyang cithakan Program DR sing cocog.

P: Napa sampeyan pengin nggawe DR? Apa kahanan kothak utawa masalah operasional sing sampeyan cobaatasi karo DR?

Iki minangka pitakonan sing paling penting lan dadi dhasar kanggo syarat lan tujuan sakabèhé kanggo apa sing kudu digayuh program DR. Jawaban kanggo pitakonan iki nemtokake cara panjaluk sisih mbukak profile mesthine bakal dibentuk dening program DR. Kabeh syarat liyane mili saka jawaban kanggo pitakonan iki.

• Apa sampeyan nyoba nyukur pucuk?
• Apa sampeyan pengin ngisi weteng bebek?
• Apa sampeyan nyoba ngalangi rega listrik?
• Apa sampeyan prelu dipercaya karo grid?
• Apa sampeyan nyoba ngreksa aset jaringan?
• Lsp. Lsp.

Tabel ing ngisor iki nyedhiyakake sawetara konteks tambahan kanggo motivasi sing pengin nggawe Program DR

Keandalan & Keamanan Grid	Frekuensi lan Voltage Stabilitas
	Kecukupan Sumber Daya
	Kapasitas Puncak
	Ramping
	Kontingensi
Pengadaan Energi	Regane Pasar Spot
	Arbitrase rega
Manajemen Aset	Nyegah karusakan
	Pangopènan Ngurangi
	Ekstensi Seumur Hidup
Manajemen Kapasitas	Paedah Ekonomi
	Manajemen Darurat
lingkungan	Negawatt
	Energi resik

P: Apa ana program DR utawa tarif sing wis kasedhiya kanggo program iki?

• Asring kaping aturan program kasebut dieja kanthi jelas kanthi tarif.

P: Segmen pasar sisih panjaluk apa sing sampeyan targetake karo program iki?

Iki bisa mbantu nemtokake target sumber daya ing acara lan jinis sinyal.

• omah
• C&I Gedhe
• C&I Cilik
• tetanèn
• Manajemen banyu
• Kendaraan Listrik
• lsp, lsp

P: Apa sampeyan nyoba target jinis beban tartamtu?

• Thermostat
• Kendaraan listrik
• Pompa ag
• lsp.

P: Apa model penyebaran sampeyan?

Wangsulan kanggo pitakon iki bisa mengaruhi kepiye sumber daya ditetepake ing program lan nemtokake kepiye sumber daya ditargetake sajrone kedadeyan.

• Langsung menyang pelanggan
• Liwat perantara kaya agregator utawa fasilitator
• Pelanggan sing tanggung jawab kanggo golek lan nggunakake peralatan VEN dhewe?
• lsp.

P: Tingkat kekhususan apa sampeyan pengin sesambungan karo beban sing dikarepake?

Pitakon iki rada gegandhengan karo model penyebaran lan nemtokake kepiye sumber daya ing program kasebut ditetepake lan ditarget. Iki minangka salah sawijining pitakon sing paling penting lan bisa uga rumit.

• Berinteraksi karo saben sumber daya individu
• Berinteraksi liwat fasilitator utawa agregator tanpa spesifikasi sumber daya sing ana ing mburine
• Berinteraksi liwat fasilitator utawa agregator lan nemtokake sumber daya sing kudu dikirim
• Gunakake lokasi minangka atribut kanggo nemtokake sumber daya
• Gunakake sawetara mekanisme klompok sing ditetepake sarana kanggo nemtokake sumber daya
• Target aset individu kayata termostat
• Berinteraksi tanpa sumber daya babar pisan lan mung siaran acara DR
• lsp.

P: Pola interaksi apa sing pengin sampeyan gunakake kanggo mengaruhi pelanggan mbukak profiles?

Pitakon iki nemtokake jinis sinyal DR sing bakal dikirim menyang peserta program.

• Insentif (kayata rega dinamis)
• Pangiriman muatan (kayata layanan tambahan)
• Kontrol beban langsung
• Sinyal acara umum
• lsp.

P: Apa atribut jadwal program umum kanggo program?

• Tanggal lan wektu acara bisa uga diarani
• Frekuensi acara
• Durasi acara
• Latensi sing diidini kanggo nyebarake acara
• lsp.

P: Kepiye kasedhiyan sumber daya ing program kasebut ditemtokake?

• Miturut aturan program sing ketat
• Minangka bagean saka sawetara proses nominasi utawa penawaran sing ditindakake dening sumber daya
• Diijini mlebu / metu?
• lsp.

P: Jinis visibilitas apa sing sampeyan butuhake kanggo kinerja sumber daya?

Iki minangka pitakon sing jembar banget lan nemtokake jinis informasi apa sing diwenehake saka sumber daya ing program DR. Umume iki nemtokake jinis laporan sing dibutuhake.

• Online / Offline
• Panggunaan (saiki lan / utawa sejarah)
• Potensi tanggepan
• Kasedhiyan momotan
• Negara beban / aset (saiki lan / utawa sejarah)
• Lsp. Lsp.

Cithakan Program Tanggepan Panjaluk

Program Harga Puncak Kritikal (CPP)

Karakteristik Program DR CPP

Mbukak Profile Tujuane	-Kurang permintaan panjaluk
Drivers Utama	-Mengurangi pangeluaran modal lan nyuda biaya energi
Deskripsi Program	Nalika keperluan ngamatake utawa ngantisipasi rega pasar grosir utawa kahanan darurat sistem tenaga listrik, bisa uga diarani kedadeyan kritis sajrone periode wektu sing ditemtokake (kayata, 3 pm - 6 sore ing dina kerja panas musim panas), rega listrik sajrone wektu kasebut wungu.
Insentif Pelanggan	Pelanggan bisa uga ditawakake rega energi diskon sajrone wektu non-puncak minangka insentif kanggo melu program.
Desain Rating	CPP minangka program rega kanthi tarif sing saya mundhak sajrone puncak kritis konsumsi energi. Biasane tarif CPP minangka tambahan utawa tambahan kanggo tarif dhasar sing rata, berjenjang, utawa TOU.
Target Pelanggan	-Residen utawa C&I
Target Target	-Sapa wae
Prasyarat	-Pelanggan kudu duwe metering interval -C & Pelanggan bisa uga kudu memenuhi kriteria panjaluk
Bingkai Wektu Program	-Sacara biasane mbuwang pirang-pirang taun ing taun iki, ing endi konsumsi energi puncak ana, sanajan bisa uga umure nganti sawetara taun.
Watesan Acara	-Sacara biasane dina Senen nganti Jumuah, ora kalebu preinan, kanthi acara dina berturut-turut biasane diidini
Dina acara	-Biasane 9 nganti 15 saben taun
Duration saka acara	-Biasane sajrone pigura wektu tetep kanggo kabeh acara wiwit 4 nganti 6 jam sajrone konsumsi energi paling dhuwur saben dina.
Notifikasi	-Biasane dina ngarep
Milih Tumindak	-Sacara biasane para pelanggan ora diwajibake melu acara
Sertifikasi Acara	-Biasane ora ana

Karakteristik OpenADR kanggo Program CPP

Sinyal Acara	–Sinyal SIMPLE kanthi level 1 nganti 3 sing dipetakan kanggo pengaruh rega acara CPP. Yen program CPP duwe komponen rega siji, mesthine bisa dipetakan menyang level 1. Kanggo program CPP kanthi macem-macem komponen rega, komponen rega paling cilik kudu dipetakan menyang level 1, kanthi komponen rega liyane dipetakan menyang level 2 lan 3 kanthi nambah derajat pengaruh rega. -Yen panyebaran ndhukung B profile VEN, saliyane sinyal SIMPLE, sinyal ELECTRICITY_PRICE bisa uga dilebokake ing muatan kanthi jinis regaHubungan, regaAbsolute, utawa regaMultiplikator gumantung karo jinis program. Waca Annex A kanggo examples.
Milih Tanggepan	-VTN ngirim acara kudu nyetel elemen oadrResponseRequired dadi "tansah", mbutuhake VEN kanggo nanggapi optIn utawa optOut -Kaya partisipasi ing program CPP minangka latihan "upaya paling apik", ora ana teges formal kanggo milih utawa milih ing njaba pratandha kasedhiyan sopan santun kanggo melu. Disaranake VENs nanggapi optIn kajaba ana sawetara tumindak nolak tartamtu sing ditindakake dening pelanggan. -Upload oadrCreateOpt biasane ora digunakake kanggo kualifikasi sumber daya sing melu acara.
Descriptor Acara	-Kegiatan kasebut prioritas kudu disetel dadi 1 kajaba aturan program utawa konfigurasi VTN sing ditemtokake –Acara tes biasane ora digunakake kanthi program CPP. Nanging yen diidini elemen testEvent kudu disetel dadi "bener" kanggo nunjukake kedadeyan tes. Yen dibutuhake informasi paramèter tambahan ing elemen iki, bisa ngetutake "bener" sing dipisahake karo spasi kanthi informasi tambahan iki.
Periode Aktif Acara	– eiRampMunggah, eiRecovery, unsur toleransi biasane ora digunakake
Dhasar	–Baseline biasane ora kalebu ing payload acara
Penargetan Acara	-Mrogram CPP biasane ora mbedakake sumber kanggo pelanggan tartamtu. Target biasane nemtokake venID, nuduhake manawa kabeh sumber daya sing gegandhengan karo VEN kudu melu, utawa dhaptar kabeh resourceIDs digandhengake karo VEN.
Layanan Reporting	–Pelaporan telemetri biasane ora digunakake amarga ora prelu banget kanggo program CPP. Waca Annex B kanggo examplaporan saka pilot utilitas sing bisa ditrapake kanggo jinis program iki.

Layanan Opt	–Nggunakake layanan Opt kanggo komunikasi jadwal kasedhiyan sementara biasane ora bakal digunakake minangka bagean saka program CPP. Nanging, sawetara panyebaran bisa nggunakake layanan iki kanggo ngreksa dina acara sing kasedhiya kanggo pelanggan sing ora duwe kasedhiyan.
Layanan Registrasi	Interval Polling dijaluk dening VTN kanggo program CPP dina-dina sing khas ora diwajibake luwih kerep yen saben jam. Nanging, panggunaan poling kanggo deteksi detak jantung bisa mbutuhake poling sing luwih asring.

Program Penawaran Kapasitas

Karakteristik Program DR Bidding Kapasitas

Mbukak Profile Tujuane	-Ngurangan pengurangan permintaan lan kecukupan sumber daya
Drivers Utama	-Mengurangi pangeluaran modal lan nyuda biaya energi
Deskripsi Program	Program penawaran kapasitas digunakake dening ISO / utilities kanggo entuk kapasitas ngeculake pra-komitmen saka agregator utawa pelanggan gabungan dhewe. Kapasitas ngeculake beban pra-komitmen iki digunakake dening ISO / utilitas nalika ndeleng utawa ngantisipasi rega pasar grosir sing dhuwur, kahanan darurat sistem tenaga, utawa minangka bagean saka pemanfaatan sumber daya energi normal kanthi nelpon acara DR sajrone wektu sing ditemtokake.   Elinga yen saben agregator biasane tanggung jawab kanggo ngrancang program tanggepan panjaluk dhewe uga akuisisi pelanggan, lan kabar acara kanggo memenuhi komitmen kapasitas sing digawe minangka bagean saka program iki.
Insentif Pelanggan	Aggregator / pelanggan nampa rong jinis insentif. Kaping pisanan, dheweke nampa pambayaran kapasitas kanggo nyepetake kapasitas muatan muatan tartamtu sing kasedhiya kanggo acara DR sajrone jendela wektu mbesuk. Kapindho, yen ana acara dipanggil sajrone jendhela wektu mbesuk, pembayaran energi bisa ditindakake kanggo ngeculake beban sajrone acara kasebut ditindakake.
Desain Rating	Peserta ing program nggawe bid "nominasi kapasitas" sing nuduhake kapasitas ngeculake beban sing bakal kasedhiya nalika kasedhiya ing wektu ngarep. Tawaran kasebut bisa uga kalebu insentif agregator / pelanggan sing gelem nampa kanggo ngeculake beban ing sangisore nilai awal. Ing pasar utilitas komitmen kapasitas biasane kanggo wulan tanggalan sabanjure, sanajan pigura wektu luwih dawa digunakake ing pasar ISO. Minangka bagean saka nominasi kapasitas, pelanggan bisa uga milih ing antarane sawetara karakteristik kalebu notifikasi sedina utawa sedina lan jendhela durasi acara (kayata 1-4 jam, 2-6 jam,…). Pembayaran kapasitas digawe kanggo pelanggan kanggo prasetya iki sanajan ora ana acara sing diarani nalika jendhela wektu. Yen acara ditelpon sajrone jendhela wektu, pelanggan bisa uga nampa pambayaran energi kanggo gudang sing ana gandhengane karo garis awal, nanging penalti bisa uga ditrapake yen kurang saka kapasitas ngeculake beban sing wis ditindakake sadurunge dikirim.
Target Pelanggan	-Agregator lan pelanggan C&I gabungan kanthi mandhiri
Beban Target	- Sembarang

Prasyarat	-Pelanggan kudu duwe metering interval -C & Pelanggan bisa uga kudu memenuhi kriteria panjaluk utawa bid
Bingkai Wektu Program	-Kapan kapan wae
Watesan Acara	-Sacara biasane dina Senen nganti Jumuah, ora kalebu preinan, kanthi acara dina berturut-turut biasane diidini
Dina acara	-Biasane maksimal 30 jam saben wulan
Duration saka acara	-Biasane sajrone jendela wektu tetep kanggo kabeh acara sajrone konsumsi energi paling dhuwur saben dina.). Durasi acara beda-beda miturut komitmen kapasitas pelanggan kanthi pilihan wiwit 1 nganti 8 jam utawa kaya sing ditemtokake dening desain program
Notifikasi	-Day-ahead utawa day-of gumantung saka pilihan komitmen kapasitas pelanggan utawa desain program
Milih Tumindak	-Sacara biasane pelanggan bakal milih acara sing diwenehake amarga duwe kapasitas ngeculake beban sadurunge.
Sertifikasi Acara	-Biasane loro saben taun (Tes)

Karakteristik OpenADR kanggo Program Penawaran Kapasitas

Sinyal Acara	–Sinyal SIMPLE kanthi level 1 nganti 3 dipetakan nganti jumlah gudang. Yen program mung ndhukung siji level gudang, mula kudu dipetakan menyang level 1. Kanggo program kanthi macem-macem level load load, pangowahan paling cilik saka operasi normal kudu dipetakan menyang level 1, kanthi nilai load load dipetakan menyang level 2 lan 3 kanggo nambah derajat tumpahan beban. -Yen panyebaran ndhukung B profile VEN, saliyane sinyal SIMPLE, sinyal BID_LOAD lan / utawa BID_PRICE bisa uga dilebokake ing muatan kanthi jinis sinyal setpoint lan rega, lan unit powerReal lan currencyPerKW. BID_LOAD bakal nggambarake mbukak beban sing dijaluk nganti tawaran jumlah kapasitas dening agregator / pelanggan, lan BID_PRICE bakal nuduhake tawaran insentif dening agregator / pelanggan. Waca Annex A kanggo examples.
Milih Tanggepan	-VTN ngirim acara kudu nyetel elemen oadrResponseRequired dadi "tansah", mbutuhake VEN kanggo nanggapi optIn utawa optOut -Kaya agregator / pelanggan duwe kapasitas pra-komitmen VEN kudu nanggapi optIn. Milih bisa uga dikirim kanggo nanggepi acara kasebut, nanging iki minangka pratondho kasedhiyan informal, dudu pamilih formal saka acara kasebut. -Ing oadrCreateOpt mbayar biasane ora digunakake kanggo kualifikasi sumber daya sing melu acara kaya biasane beban minangka entitas gabungan.
Descriptor Acara	-Kegiatan kasebut prioritas kudu disetel dadi 1 kajaba aturan program utawa konfigurasi VTN sing ditemtokake –Acara uji coba bisa digunakake kanthi program Penawaran Kapasitas. Yen diidini, elemen testEvent kudu disetel dadi "bener" kanggo nunjukake kedadeyan tes. Yen dibutuhake informasi paramèter tambahan ing elemen iki, bisa ngetutake "bener" sing dipisahake karo spasi kanthi informasi tambahan iki.
Periode Aktif Acara	– eiRampMunggah, eiRecovery, unsur toleransi biasane ora digunakake
Dhasar	–Baseline biasane ora kalebu ing payload acara amarga data iki biasane ora kasedhiya nalika acara diwiwiti. Nanging, utilitas lan aggregator / pelanggan bakal view Gawan informasi dhasar ing acara minangka migunani.
Penargetan Acara	-Program Penawaran Kapasitas biasane ora mbedakake sumber kanggo pelanggan tartamtu. Target biasane nemtokake venID, nuduhake manawa kabeh sumber daya sing gegandhengan karo VEN kudu melu, utawa kalebu wakil resourceID saka jumlah gabungan digandhengake karo VEN.
Layanan Reporting	Program Penawaran Kapasitas ISO biasane mbutuhake laporan TELEMETRY_USAGE karo titik data powerReal. Ndeleng mantanamping Annex A. Pelaporan telemetri kanggo Penawaran Kapasitas utilitas biasane ora dibutuhake. Elinga yen laporan telemetri mbutuhake B profile VEN. Waca Annex B kanggo examplaporan saka pilot utilitas sing bisa ditrapake kanggo jinis program iki.
Layanan Opt	–Nggunakake layanan Opt kanggo komunikasi jadwal kasedhiyan sementara biasane ora bakal digunakake minangka bagean saka program Penawaran Kapasitas amarga pelanggan wis nggawe kasedhiyan sadurunge. Nanging, layanan iki bisa uga migunani minangka cara informal kanggo para peserta kanggo nunjukake kurang kasedhiyan amarga nyebabake alasan kayata kegagalan peralatan.
Layanan Registrasi	Interval Polling dijaluk dening VTN kanggo program khas awan ora diwajibake luwih kerep yen saben jam. Nanging, panggunaan polling kanggo deteksi detak jantung utawa program dina bisa mbutuhake poling sing luwih asring.

Program Termostat Warga

Program iki minangka perwakilan Direct Load Control (DLC) ing endi sinyal Respon Response langsung ngowahi prilaku sumber daya tumpahan, tanpa lapisan abstraksi antarane panrima sinyal lan tumindak ngeculake beban tartamtu sing ditindakake.

Karakteristik Program DR Thermostat Karesidenan

Mbukak Profile Tujuane	-Kurang permintaan panjaluk
Drivers Utama	-Mengurangi pangeluaran modal lan nyuda biaya energi
Deskripsi Program	-Nalika utilitas mirsani utawa ngantisipasi rega pasar grosir sing dhuwur utawa kahanan darurat sistem tenaga, bisa uga miwiti prastawa sing ngowahi prilaku termostat komunikasi (PCT) sing bisa diprogram pelanggan sajrone wektu tartamtu (kayata, 3 sore - 6 sore nalika panas dina kerja ing musim panas) kanggo nyuda konsumsi energi. -Ganti prilaku PCT kanggo nanggepi acara bisa uga ana owah-owahan sing ditemtokake ing suhu kanggo suwene acara utawa owah-owahan sing luwih kompleks, kalebu pre-pendinginan, sing nyuda pengaruh saka acara kasebut ing kenyamanan pelanggan tingkat
Insentif Pelanggan	-Incentives duwe rong bentuk umum. Kaping pisanan, pelanggan bisa uga diwenehi PCT gratis utawa diskon / potongan harga kanggo PCT sing dituku pelanggan minangka insentif kanggo ndaftar ing program DR. Kapindho, pelanggan bisa uga entuk stipend tahunan kanggo ndaftar terus ing program kasebut. Kurang umum yaiku insentif sing terus dibayar kanggo pelanggan adhedhasar nyuda energi nyata sajrone prastawa.
Desain Rating	-Program utama kanggo insentif, ing endi para pelanggan nampa PCT diskon utawa gratis kanggo ndhaptar program DR. Sawetara program bisa mbayar stipend periodik utawa pembayaran insentif adhedhasar pengurangan energi sajrone prastawa.
Target Pelanggan	-Residen
Target Target	-HVAC
Prasyarat	-Biasane ora ana, amarga pelanggan nampa PCT minangka bagean saka dhaptar program
Bingkai Wektu Program	-Sacara biasane mbuwang pirang-pirang taun ing taun iki, ing endi konsumsi energi puncak ana, sanajan bisa uga umure nganti sawetara taun.
Watesan Acara	-Sacara biasane dina Senen nganti Jumuah, ora kalebu preinan, kanthi acara dina berturut-turut biasane diidini.
Dina acara	-Biasane 9 nganti 15 saben taun
Duration saka acara	-Kajadian bisa kedadeyan kapan wae, kanthi durasi wiwit 2 nganti 4 jam, sanajan umume kedadeyan kedadeyan sajrone konsumsi energi paling dhuwur saben dina.
Notifikasi	-Biasane dina ngarep, sanajan sawetara program bisa uga duwe wektu notifikasi kurang luwih 10 menit.
Milih Tumindak	-Pelanggan ora diwajibake melu acara, nanging kanthi otomatis bakal bisa milih acara kajaba ora njupuk tindakan kanggo nolak acara kasebut utawa nggawe pangaturan manual kanggo suhu sajrone acara kasebut.
Sertifikasi Acara	-Biasane ora ana

Karakteristik OpenADR kanggo Program Termostat Perumahan

Sinyal Acara	–Sinyal SIMPLE kanthi level 1 nganti 3 dipetakan menyang owah-owahan ing offset setpoint suhu PCT utawa persentase siklus termostatiktage. Yen program termostat omah duwe komponen offset / bersepeda, mula kudu dipetakan menyang level 1. Kanggo program kanthi komponen offset / bersepeda, pangowahan paling cilik saka operasi normal kudu dipetakan menyang level 1, kanthi nilai offset / bersepeda liyane dipetakan menyang level 2 lan 3 kanggo nambah derajat pengaruh tumpahan beban. -Yen panyebaran ndhukung B profile VEN, saliyane sinyal SIMPLE, sinyal LOAD_CONTROL bisa uga dilebokake ing payload kanthi jinis x-loadControlLevelOffset utawa x-loadControlCapacity kanggo nemtokake setpoint suhu sing dipengini ngimbangi utawa thermostatic muter persentage mungguh. Dipunwiwiti a jinis unit "suhu" sing digunakake ing muatan nggunakake sinyal x-loadControlLevelOffset sinyalJenis kanggo nunjukake Celsius utawa Fahrenheit kanggo nutup kerugian. Waca Annex A kanggo examples.
Milih Tanggepan	-VTN ngirim acara kudu nyetel elemen oadrResponseRequired dadi "tansah", mbutuhake VEN kanggo nanggapi optIn utawa optOut – VENs Apa kudu nanggapi optIn kajaba ana sawetara tumindak nolak tartamtu sing ditindakake dening pelanggan. -Ing muatan oadrCreateOpt bisa digunakake dening VENs kanggo nduweni partisipasi sumber daya ing sawijining acara. Contone, acara bisa target sumber daya saka rong termostat sing ngontrol sistem HVAC sing kapisah. Yen pelanggan mutusake manawa mung siji sistem HVAC sing bisa melu acara kasebut, mula bakal dikomunikasikake karo VTN nggunakake muatan oadrCreateOpt. Elinga yen muatan oadrCreateOpt mung didhukung dening B profile VEN
Descriptor Acara	-Kegiatan kasebut prioritas kudu disetel dadi 1 kajaba aturan program utawa konfigurasi VTN sing ditemtokake –Acara tes biasane ora digunakake kanthi program Termostat Residential. Nanging yen diidini elemen testEvent kudu disetel dadi "bener" kanggo nunjukake kedadeyan tes. Yen dibutuhake informasi paramèter tambahan ing elemen iki, bisa ngetutake "bener" sing dipisahake karo spasi kanthi informasi tambahan iki.
Periode Aktif Acara	–Randomisasi biasane digunakake kanggo acara termostat omah kanthi nggunakake elemen toleransi – eiRampElemen munggah lan eiRecovery biasane ora digunakake
Dhasar	–Baseline biasane ora kalebu ing payload acara
Penargetan Acara	-Sistem Termostat Perumahan target sumber daya HVAC sing dikontrol dening PCTs. Target biasane nemtokake resourceIDs saka sistem HVAC (yaiku termostat) sing ana gandhengane karo VEN utawa venID kanthi target target kelas piranti sinyal sing disetel menyang Thermostat
Layanan Reporting	–Pelaporan telemetri biasane ora digunakake amarga ora prelu banget kanggo program termostat omah Waca Annex B kanggo examplaporan saka pilot utilitas sing bisa ditrapake kanggo jinis program iki.
Layanan Opt	–Nggunakake layanan Opt kanggo komunikasi jadwal kasedhiyan sementara biasane ora bakal digunakake minangka bagean saka program CPP.
Layanan Registrasi	Interval Polling dijaluk dening VTN kanggo program Theropat Perumahan paling umum sadina ora diwajibake luwih kerep yen saben jam. Nanging, panggunaan polling kanggo deteksi detak jantung bisa uga mbutuhake poling sing luwih asring uga program termostat omah kanthi wektu notifikasi sing luwih cekak.

Pengiriman DR Cepet

Karakteristik Program Diskatch DR Cepet

Mbukak Profile Tujuane	-Kaya sumber daya kanggo entuk respon mbukak kanthi "real-time"
Drivers Utama	-Luwih andal lan layanan tambahan
Deskripsi Program	DR Cepet digunakake dening ISO / utilities kanggo entuk tanggepan muatan sing wis digawe kanthi "real-time". Tanggepan beban pra-komitmen iki digunakake dening ISO / utilitas nalika ngerteni kahanan sing mbutuhake tumindak cepet kanggo njaga stabilitas lan integritas kisi. Real-time tegese sumber daya biasane dikirim kanthi latensi wiwit 10 menit kanggo sumber sing digunakake minangka cadangan nganti 2 detik kanggo sumber daya sing digunakake kanggo tujuan regulasi. Ukuran respon beban kudu cukup gedhe kanggo nggawe prabédan kanggo nyuda kahanan kothak lan mula sumber daya umume gedhe banget lan asring dikelola dening agregator minangka bagean saka sumber daya gabungan. Ukuran minimal kanggo nanggepi momotan kanggo kualifikasi kanggo melu layanan tambahan umume udakara 500 kW, nanging bisa nganti 100 kW kanggo sawetara program. Elinga yen yen sumber daya digunakake minangka cadangan, biasane bakal diarani nyuda (yaiku ngeculake), nanging yen digunakake kanggo tujuan regulasi, bisa uga dikirim utawa nambah beban.
Insentif Pelanggan	Aggregator / pelanggan biasane nampa rong jinis insentif. Kaping pisanan, dheweke nampa pambayaran kanggo nindakake lan nyediakake jumlah respons tanggepan tartamtu sing kasedhiya kanggo acara DR sajrone jendela wektu mbesuk. Jumlah respon mbukak, jendhela wektu kasedhiyan lan jumlah sing kudu dibayar biasane disetel dening agregator / pelanggan. Kapindho, yen ana acara dipanggil sajrone jendhela wektu mbesuk, pembayaran adhedhasar jumlah respon beban sajrone acara kasebut.
Desain Rating	Peserta ing program ngirim tawaran sing nuduhake respon beban sing bakal kasedhiya nalika ana wektu ngarep. Tawaran kasebut biasane uga kalebu pembayaran sing bakal ditampa agregator / pelanggan kanggo nanggepi beban. Ing pasar utilitas/ISO, bid biasane diajukake ing dina ngarep utawa dina periode wektu nalika komitmen kasebut ditindakake. Minangka bagéan saka kualifikasi lan registrasi ing pasar macem-macem kinerja envelops paramèter digandhengake karo sumber daya kayata ramp tarif lan min lan max watesan operasi. Parameter kasebut ngatur carane bakal dikirim. Yen tawaran peserta ditampa, pambayaran bisa ditindakake marang pelanggan kanggo prasetya sanajan ora ana acara sing diarani sajrone wektu kasebut. Yen acara diarani sajrone wektu, pelanggan bisa nampa pembayaran tambahan kanggo kinerja sajrone acara kasebut. Pembayaran adhedhasar kinerja kasebut bisa didhasarake ing sawetara faktor kalebu jumlah energi, daya, sepira sumber daya ngetutake instruksi kiriman, lan pembayaran "jalur tempuh" sing nuduhake jumlah muatan pro.file kudu diganti nalika acara kasebut. Sawetara paramèter kasebut kayata energi lan daya bisa uga ana hubungane karo garis dasar.
Target Pelanggan	-Agregator lan pelanggan C&I gabungan kanthi otomatis
Beban Target	- Sing bisa nanggapi pangiriman wektu nyata.

Prasyarat	-Pelanggan kudu duwe metering interval -Kudu nyukupi syarat ukuran minimal kanggo respon beban -Kudu bisa nanggapi pangiriman wektu nyata -Biasane kudu nyuplai telemetri wektu nyata sing nuduhake tanggapan beban saiki
Bingkai Wektu Program	-Kapan kapan wae
Watesan Acara	- ora ana
Dina acara	- ora ana
Duration saka acara	-Biasane cekak (kurang saka 30 menit), nanging ing kasus apa wae, ora bakal ngluwihi jendhela wektu yen peserta nyedhiyakake sumber daya nalika kasedhiya.
Notifikasi	- ora ana
Milih Tumindak	-Pelanggan milih acara kanthi gawan yen wis nanggepi beban pra-komitmen
Sertifikasi Acara	-Biasane setaun (Tes)

Karakteristik OpenADR kanggo Program Penawaran Kapasitas

Sinyal Acara	–Sinyal SIMPLE kanthi level 1 nganti 3 dipetakan kanthi jumlah respon beban. Yen program mung ndhukung level respons respon siji, mesthine kudu dipetakan menyang level 1. Kanggo program kanthi tingkat mutiple respon beban, pangowahan sing paling cilik saka operasi normal kudu dipetakan menyang level 1, kanthi nilai gudang diwetokake menyang level 2 lan 3 kanggo nambah derajat respon beban. -Yen panyebaran ndhukung B profile VEN, saliyane sinyal SIMPLE, pengiriman sing kalebu sinyal LOAD_DISPATCH bisa uga dilebokake ing muatan kanthi jinis sinyal saka titik titik utawa delta, lan unit dayaReal. Sinyal iki nggambarake "titik operasi" sing dipengini saka beban lan bisa ditulis kanthi mW (IE setpoint) utawa sawetara jumlah mW (IE delta) saka titik operasi saiki. Waca Annex A kanggo examples.
Milih Tanggepan	-VTN ngirim acara kudu nyetel elemen oadrResponseRequired dadi "tansah", mbutuhake VEN kanggo nanggapi optIn utawa optOut -Kaya agregator / pelanggan duwe kapasitas pra-komitmen VEN kudu nanggapi optIn. Milih bisa uga dikirim kanggo nanggepi acara kasebut, nanging iki minangka pratondho kasedhiyan informal, dudu pamilih formal saka acara kasebut. -Ing oadrCreateOpt mbayar biasane ora digunakake kanggo kualifikasi sumber daya sing melu acara kaya biasane beban minangka entitas gabungan.
Descriptor Acara	-Kegiatan kasebut prioritas kudu disetel dadi 1 kajaba aturan program utawa konfigurasi VTN sing ditemtokake –Acara uji coba bisa digunakake, utamane sajrone registrasi lan kualifikasi sumber daya. Yen diidini, elemen testEvent kudu disetel dadi "bener" kanggo nunjukake kedadeyan tes. Yen dibutuhake informasi paramèter tambahan ing elemen iki, bisa ngetutake "bener" sing dipisahake karo spasi kanthi informasi tambahan iki.
Periode Aktif Acara	– Unsur toleransi ora digunakake. Ing eRampWektu munggah lan eiRecovery biasane bagean saka paramèter sumber daya nalika ndhaftar lan bisa digunakake. Amarga sifat kiriman kasebut bisa uga mbukak lan mula ora ana wektu pungkasan kanggo acara kasebut.
Dhasar	–Baseline biasane ora kalebu ing payload acara amarga data iki biasane ora kasedhiya nalika acara diwiwiti. Nanging, utilitas lan aggregator / pelanggan bakal view Gawan informasi dhasar ing acara minangka migunani.
Penargetan Acara	-Program Penawaran Kapasitas biasane ora mbedakake sumber kanggo pelanggan tartamtu. Target biasane nemtokake venID, nuduhake manawa kabeh sumber daya sing gegandhengan karo VEN kudu melu, utawa kalebu wakil resourceID saka jumlah gabungan digandhengake karo VEN.
Layanan Reporting	Program DR cepet biasane mbutuhake laporan TELEMETRY_USAGE kanthi poin data powerReal. Laporan panggunaan nggambarake titik operasi saiki sumber daya lan digunakake dening Utility / ISO kanggo nemtokake sepira cedhak sumber kasebut nderek instruksi pengiriman sing dikirim. Ing sawetara kasus, telemetri bisa uga kalebu titik data liyane kayata voltage maca lan negara daya (IE energi) ing cilik ngendi sumber daya sawetara wangun panyimpenan. Ing sawetara kasus, frekuensi nglaporake bisa nganti saben 2 detik. Elinga yen laporan telemetri mbutuhake B profile VEN. Waca Annex A kanggo examples. Uga deleng Annex B kanggo examplaporan saka pilot utilitas sing bisa ditrapake kanggo jinis program iki.
Layanan Opt	–Nggunakake layanan Opt kanggo komunikasi kasedhiyan sementara jadwal biasane ora bakal digunakake amarga pelanggan wis nggawe kasedhiyan sadurunge. Nanging, layanan iki bisa uga migunani minangka cara informal kanggo para peserta kanggo nunjukake kurang kasedhiyan amarga nyebabake alasan kayata gagal peralatan.
Layanan Registrasi	Amarga sarat latensi sing murah kanggo pengiriman wektu nyata mung pola interaksi push sing digunakake.

Program Wektu Gunakake (TOU) Kendaraan Listrik Residen (EV)

Karakteristik Program EV TOU Karesidenan

Mbukak Profile Tujuane	Struktur tarif sing biaya kanggo ngisi kendaraan listrik diowahi supaya konsumen ngowahi pola konsumsi.
Drivers Utama	Energi perumahan nggunakake puncak ing wayah sore. Amarga pangisian daya EV mbutuhake 4-8 jam, bisa ditundha nganti pirang-pirang jam kanggo nggeser pucuk beban.
Deskripsi Program	Pelanggan sing duwe kendharaan listrik bisa ndaftar kanggo tarif Gunakake Listrik Kendaraan Listrik (EV-TOU) lan nampa tarif sing luwih murah kanggo ngisi daya kendharane sajrone jam suwene, kayata antara tengah wengi lan jam 5 AM EV-TOU ditawakake kanggo nyengkuyung pelanggan supaya matesi panggunaan listrik awan awan, yen panjaluk listrik paling dhuwur.
Insentif Pelanggan	Ngisi daya sing luwih murah kanggo EV.
Desain Rating	TOU kanthi puncak awan, esuk lan sore tengah puncak, lan puncak puncak tanggal 12 AM-5AM
Target Pelanggan	EV Owner karo beban profile sing puncak ing wayah sore.
Beban Target	Pangisi daya EV
Prasyarat	Pelanggan kudu duwe meter cerdas lan EV
Bingkai Wektu Program	Kabeh taun
Watesan Acara	ora ana
Dina acara	Saben dina, utawa mung dina kerja
Duration saka acara	5-8 jam
Notifikasi	Pelanggan dikabari babagan undakan rega tagihan bulanan, lan VTN ngirim sinyal acara nganti saiki.
Milih Tumindak	Ratepayers bisa ngganti rencana tarif kaya biasane karo utilitas.
Sertifikasi Acara

Karakteristik OpenADR kanggo Program TOU Residential

Sinyal Acara	Sinyal ELECTRICITY_PRICE kanthi undakan rega nyata, uga sinyal SIMPLE supaya ora bisa melu 2.0a VEN Waca Annex A kanggo examples.
Milih Tanggepan	Tansah milih dening VENs
Descriptor Acara	Siji acara saben minggu, kanthi interval acara kanggo saben undakan rega
Periode Aktif Acara	Paling ora notifikasi 24 jam kudu digunakake. Saben interval acara kudu entuk undakan tingkat TOU
Dhasar	N/A
Penargetan Acara	Ora butuh penargetan lanjutan, mung penargetan level VEN.
Layanan Reporting	Ora perlu dilaporake, kabeh data bisa diwiwiti saka meter. Waca Annex B kanggo examplaporan saka pilot utilitas sing bisa ditrapake kanggo jinis program iki.
Layanan Opt	Layanan opt ora cocog karo jinis program iki.
Layanan Registrasi	Pelanggan bakal nyedhiyakake VEN kanthi utilitas kanggo nampa sinyal rega.

Program Penetapan Real-Time Vehicle Electric Station (EV)

Karakteristik Program EV RTP Stasiun Publik

Mbukak Profile Tujuane	Kegiatan tanggepan panjaluk kanthi biaya kanggo ngisi kendaraan listrik diowahi kanggo ngowahi kasunyatan rega paling dhuwur menyang konsumen.
Drivers Utama	Rega listrik beda-beda sajrone sedina. Program iki ngarahake luwih cocog karo rega pangisian daya karo biaya listrik.
Deskripsi Program	Pengisi daya umum bisa ana ing papan kerja, ing parkiran umum, lan ing toko-toko. Program iki ngirimake rega wektu nyata menyang pangisi daya potensial sadurunge dipasang, supaya bisa njupuk keputusan babagan ngisi mobil utawa ora.
Insentif Pelanggan	Ngisi daya sing luwih murah sajrone wektu sing ora dibayar.
Desain Rating	Regane bisa gantiurly, nanging sawise pelanggan milih plug in mobil, tarif disetel kanggo sajrone ngisi daya.
Target Pelanggan	Sapa wae sing duwe EV sing kudu diisi daya nalika ora ana ing omah.
Beban Target	Pangisi daya EV Umum
Prasyarat	Pangisi daya EV kudu gegandhengan karo internet lan disertifikasi OpenADR2.0b, utawa nyambung menyang gateway OpenADR2.0b VEN.
Bingkai Wektu Program	Kabeh taun
Watesan Acara	ora ana
Dina acara	Saben dina, utawa mung dina kerja
Duration saka acara	1 jam utawa luwih
Notifikasi	Pelanggan dikabari babagan tarif sing ana nalika milih plug in mobil.
Milih Tumindak	Pelanggan bisa milih kanthi milih ora ngisi biaya.
Sertifikasi Acara

Karakteristik OpenADR kanggo Program RTP Stasiun Publik

Sinyal Acara	Sinyal ELECTRICITY_PRICE kanthi rega. Waca Annex A kanggo examples.
Milih Tanggepan	Tansah milih dening VENs
Descriptor Acara	Acara kudu jejer, lan ngemot interval siji.
Periode Aktif Acara	Paling ora notifikasi 1 jam kudu digunakake, nanging utilitas bisa milih nggunakake notifikasi sedina wae.
Dhasar	N/A
Penargetan Acara	Ora mbutuhake penargetan lanjutan, nanging penargetan bisa digunakake kanggo ngirim rega menyang trafo, feeder, utawa wilayah geografis tartamtu.
Layanan Reporting	Ora perlu dilaporake, nanging bisa digunakake yen pengin. Waca Annex B kanggo examplaporan saka pilot utilitas sing bisa ditrapake kanggo jinis program iki.
Layanan Opt	Layanan opt ora cocog karo jinis program iki.
Layanan Registrasi	Vendor stasiun pengisian daya bakal nyedhiyakake piranti kasebut karo VTN sarana.

Program DR Sumber Daya Energi Disebar (DER)

Deskripsi program ing ngisor iki hipotesis lan adhedhasar makalah riset (makalah referensi Rish) sing nggambarake kepiye pelanggan bisa nggunakake sumber panyimpenan DER kanggo melu program DR kayata program pricing real time (RTP).

Karakteristik Program Sumber Daya Energi Disebar (DER)

Mbukak Profile Tujuane	Kegiatan tanggepan panjaluk digunakake kanggo lancar integrasi sumber daya energi sing disebarake menyang kothak cerdas.
Drivers Utama	-Mengurangi pangeluaran modal lan nyuda biaya energi
Deskripsi Program	Pelanggan kanthi sumber daya DER sing bisa panen energi lan nyimpen bisa nyilikake biaya tuku listrik saka kothak sajrone rega regane kanthi luwih dhisik nggunakake sumber energi sing disimpen, banjur ngetrapake strategi ngeculake beban
Insentif Pelanggan	Kemampuan kanggo ngontrol biaya nalika rega listrik larang banget kanthi nggunakake energi disimpen sing digawe liwat PV utawa cara liya lan ngetrapake strategi ngeculake beban
Desain Rating	Tarif listrik beda-beda gumantung karo rega pasar grosir utawa tarif sing beda-beda dadi fungsi wayah awan, musim, utawa suhu
Target Pelanggan	Pelanggan kanthi sumber daya panyimpenan energi
Beban Target	Sembarang
Prasyarat	Sumber daya panyimpenan energi
Bingkai Wektu Program	Kapan wae
Watesan Acara	ora ana
Dina acara	Saben dina
Duration saka acara	24 jam
Notifikasi	Dina ahead
Milih Tumindak	N / A - Program gaweyan paling apik
Sertifikasi Acara	ora ana

Karakteristik OpenADR kanggo Sumber Daya Energi Distribusi (DER)

Sinyal Acara	Sinyal ELECTRICITY_PRICE kanthi interval rega 24 jam sajrone wektu 24 jam. Sinyal iki mbutuhake B profile. Program iki ora menehi tandha SIMPLE kanggo A profile VEN. Waca Annex A kanggo examples.
Milih Tanggepan	-VTN ngirim acara kudu nyetel elemen oadrResponseRequired dadi "ora tau", ngalangi VENs supaya ora nanggapi.
Descriptor Acara	-Kegiatan kasebut prioritas kudu disetel dadi 1 kajaba aturan program utawa konfigurasi VTN sing ditemtokake
Periode Aktif Acara	24 jam kanthi interval 1 jam kanthi kabar sadurunge
Dhasar	N/A
Penargetan Acara	Ora ana target target sing luwih maju tinimbang venID
Layanan Reporting	Ora perlu dilaporake Waca Annex B kanggo examplaporan saka pilot utilitas sing bisa ditrapake kanggo jinis program iki.
Layanan Opt	Ora digunakake
Layanan Registrasi	Interval Polling dijaluk dening VTN kanggo program t dina sing khas ora diwajibake luwih kerep yen saben jam. Nanging, panggunaan polling kanggo deteksi detak jantung bisa uga mbutuhake poling sing luwih asring uga program termostat omah kanthi wektu notifikasi sing luwih cekak.

– Sample Data lan Payload Cithakan

Ing ngisor iki tabel lan XML payload samples bakal nyedhiyani implementers karo nyata examples carane Cithakan DR ing document iki kudu dipun ginakaken. Ater-ater namespace ing ngisor iki digunakake ing 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/ -2011/06/XNUMX/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/ -2011/06/XNUMX/power”

Program Harga Puncak Kritikal (CPP)

Skenario CPP 1 - Kasus Gunakake Sederhana, A utawa B Profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu wiwitan: 1pm
  • Duration: 4 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 1
  • Jeneng Sinyal: SIMPLE
    • Tipe Sinyal: level
    • Unit: N / A
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 1
    • Target Sinyal: N / A
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Skenario CPP 2 - Kasus Penggunaan Biasa, B profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu Mulai: 1pm
  • Duration: 4 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 2
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Level 0, 1, 2, 3
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 1 utawa 2
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: ELECTRICITY_PRICE
    • Tipe Sinyal: rega
    • Unit: USD saben Kwh
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: $ 0.10 nganti $ 1.00
    • Target Sinyal: Ora Ana
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Skenario CPP 3 - Kasus Panganggone Komplek

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu wiwitan: 2pm
  • Duration: 6 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 2
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Level 0,1, 2, 3)
    • Cacah interval 3
    • Durasi interval: 1 jam, 4 jam, 1 jam
    • Nilai Interval Biasa: 1, 2, 1 (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: ELECTRICITY_PRICE
    • Tipe Sinyal: rega
    • Unit: USD saben Kwh
    • Cacah interval 3
    • Durasi interval: 1 jam, 4 jam, 1 jam
    • Nilai Interval Biasa: $ 0.50, $ 0.75, $ 0.50 (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Target Acara: Resource_1, Resource_2, Resource_3
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

CPP SampBeban Acara - Khas B Profile Gunakake Case

OadrDisReq091214_043740_513

TH_VTN

Acara091214_043741_028_0

0

http: // MarketContext1

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

adoh

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

PT4H

PT24H

PT4H

0

2.0

SIMPLE

tingkat

SIG_01

0.0

PT4H

0

0.75

LISTRIK_PRICE

regane

SIG_02

itunganPerKWh

USD

ora ana

0.0

venID_1234

tansah

Program Penawaran Kapasitas (CBP)

Skenario CBP 1 - Kasus Gunakake Sederhana, A utawa B Profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu wiwitan: 1pm
  • Duration: 4 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 1
  • Jeneng Sinyal: SIMPLE
    • Tipe Sinyal: level
    • Unit: N / A
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 1
    • Target Sinyal: N / A
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Skenario CBP 2 - Kasus Penggunaan Biasa, B profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu Mulai: 1pm
  • Duration: 4 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 2
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Tingkat 0,1, 2, 3
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 1 utawa 2
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: BID_LOAD
    • Tipe Sinyal: setpoint
    • Unit: powerReal
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 20kW nganti 100kW
    • Target Sinyal: Ora Ana
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Skenario CBP 3 - Kasus Panganggone Komplek

• Acara
  • Kabar: Dina acara (pirang-pirang jam?)
  • Wektu wiwitan: 1pm
  • Duration: 6 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 3
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Level 0,1, 2, 3)
    • Cacah interval: 2
    • Durasi interval: 3 jam, 3 jam
    • Nilai Interval Biasa: 1, 2 (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: BID_LOAD
    • Tipe Sinyal: setpoint
    • Unit: powerReal
    • Cacah interval 2
    • Durasi interval: 3 jam, 3 jam
    • Nilai Interval Biasa: 40kW, 80kW (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: BID_PRICE
    • Tipe Sinyal: rega
    • Unit: currencyPerKW
    • Cacah interval 1
    • Durasi interval: 6 jam
    • Nilai Interval Biasa: $ 3.10
    • Target Sinyal: Ora Ana
  • Target Acara: Resource_1, Resource_2, Resource_3
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • Jeneng Laporan: TELEMETRY_USAGE
  • Jinis Laporan: panggunaan
  • Unit: powerReal
  • Jinis Maca: Maca Langsung
  • Laporan Frekuensi: saben 1 jam

CBP SampBeban Acara - Khas B Profile Gunakake Case

OadrDisReq091214_043740_513

TH_VTN

Acara091214_043741_028_0

0

http: // MarketContext1

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

adoh

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

PT4H

PT24H

PT4H

0

2.0

SIMPLE

tingkat

SIG_01

0.0

PT4H

0

80.0

BID_LOAD

titik titik

SIG_02

Tenaga Tenaga

W

k

60.0

<daya: voltage>220.0tage>

bener

0.0

venID_1234

tansah

Program Termostat Warga

Skenario Termostat Residential 1 - Kasus Gunakake Sederhana, A utawa B Profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu wiwitan: 1pm
  • Duration: 4 jam
  • Randomisasi: 10 menit
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 1
  • Jeneng Sinyal: SIMPLE
    • Tipe Sinyal: level
    • Unit: N / A
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 1
    • Target Sinyal: N / A
  • Target Acara: Resource_1
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Skenario Termostat Residential 2 - Kasus Penggunaan Biasa, B profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu Mulai: 1pm
  • Duration: 4 jam
  • Randomisasi: 10 menit
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 2
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Tingkat 0,1, 2, 3
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 1 utawa 2
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: LOAD_CONTROL
    • Tipe Sinyal: x-loadControlLevelOffset
    • Unit: Suhu
    • Cacah interval 1
    • Durasi interval: 4 jam
    • Nilai Interval Biasa: 2 nganti 6 derajat Fahrenheit
    • Target Sinyal: Ora Ana
  • Target Acara: Resource_1, Resource_2
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Response sing Diarepake: optIn, Bisa outOut (oadrCreateOpt)
• Laporan
  • ora ana

Skenario Termostat Warga 3 - Kasus Panganggone Komplek

• Acara
  • Kabar: Dina acara
  • Wektu wiwitan: 1pm
  • Duration: 6 jam
  • Randomisasi: 10 menit
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 3
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Level 0,1, 2, 3)
    • Cacah interval: 2
    • Durasi interval: 3 jam, 3 jam
    • Nilai Interval Biasa: 1, 2 (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: BID_LOAD
    • Tipe Sinyal: x-loadControlCapacity
    • Unit: Ora ana
    • Cacah interval 2
    • Durasi interval: 3 jam, 3 jam
    • Nilai Interval Biasa: 0.9, 0.8 (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Target Acara: Resource_1, Resource_2, Resource_3
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Response sing Diarepake: optIn, Bisa outOut (oadrCreateOpt)
• Laporan
  • ora ana

Termostat Perumahan SampBeban Acara - Khas B Profile Gunakake Case

OadrDisReq091214_043740_513

TH_VTN

Acara091214_043741_028_0

0

http: // MarketContext1

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

adoh

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

PT4H

PT10M

PT24H

PT4H

0

2.0

SIMPLE

tingkat

SIG_01

0.0

PT4H

0

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

suhu

fahrenheit

ora ana

0.0

sumber_1

sumber_2

tansah

Pengiriman DR Cepet

Skenario DR Cepet 1 - Kasus Gunakake Prasaja, A utawa B Profile

• Acara
  • Kabar: 10 menit
  • Wektu wiwitan: 1pm
  • Duration: 0 (Open Ended)
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 1
  • Jeneng Sinyal: SIMPLE
    • Tipe Sinyal: level
    • Unit: N / A
    • Cacah interval 1
    • Durasi interval: 0 (Open Ended)
    • Nilai Interval Biasa: 1
    • Target Sinyal: N / A
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Skenario DR Cepet 2 - Kasus Gunakake Khas, B profile

• Acara
  • Kabar: 10 menit
  • Wektu Mulai: 1pm
  • Duration: 30 menit
  • Randomisasi: Ora Ana
  • Ramp Nganti: 5 menit
  • Pamulihan: 5 menit
  • Jumlah sinyal: 2
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Tingkat 0,1, 2, 3
    • Cacah interval 1
    • Durasi interval: 30 menit
    • Nilai Interval Biasa: 1 utawa 2
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: LOAD_DISPATCH
    • Tipe Sinyal: delta
    • Unit: powerReal
    • Cacah interval 1
    • Durasi interval: 30 menit
    • Nilai Interval Biasa: 500 kW nganti 2mW
    • Target Sinyal: Ora Ana
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • Jeneng Laporan: TELEMETRY_USAGE
  • Jinis Laporan: panggunaan
  • Unit: powerReal
  • Jinis Maca: Maca Langsung
  • Laporan Frekuensi: saben 1 menit

Skenario DR Cepet 3 - Kasus Panganggone Komplek

• Acara
  • Kabar: 10 menit
  • Wektu wiwitan: 1pm
  • Duration: 30 menit
  • Randomisasi: Ora Ana
  • Ramp Nganti: 5 menit
  • Pamulihan: 5 menit
  • Jumlah sinyal: 2
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Level 0,1, 2, 3)
    • Cacah interval: 2
    • Durasi interval: 15 menit, 15 menit
    • Nilai Interval Biasa: 1, 2 (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: LOAD_DISPATCH
    • Tipe Sinyal: setpoint
    • Unit: powerReal
    • Cacah interval 2
    • Durasi interval: 15 menit, 15 menit
    • Nilai Interval Biasa: 800kW, 900kW (kanggo saben interval)
    • Target Sinyal: Ora Ana
  • Target Acara: Resource_1
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • Jeneng Laporan: TELEMETRY_USAGE
  • Jinis Laporan: panggunaan
  • Unit: powerReal lan voltage
  • Jinis Maca: Maca Langsung
  • Laporan Frekuensi: saben 5 detik

Cepet DR SampBeban Acara - Khas B Profile Gunakake Case

OadrDisReq091214_043740_513

TH_VTN

Acara091214_043741_028_0

0

http: // MarketContext1

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

adoh

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

PT10M

PT10M

<ei:x-eiRampmunggah>

PT5M

</ei:x-eiRampmunggah>

PT5M

PT10M

0

2.0

SIMPLE

tingkat

SIG_01

0.0

PT10M

0

500.0

LOAD_DISPATCH

delta

SIG_02

Tenaga Tenaga

W

k

60.0

<daya: voltage>220.0tage>

bener

0.0

venID_1234

tansah

Cepet DR Sample Laporan Metadata Payload - Khas B Profile Gunakake Case

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

sumber1

panggunaan

RealEnergy

Wh

k

Maca Langsung

http: // MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

palsu

</oadr:oadrSamplingRate>

0

LaporanSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

Cepet DR Sample Report Request Payload - Khas B Profile Gunakake Case

LaporanReqID130615_192625_230

LaporanReqID130615_192625_730

LaporanSpecID120615_122512_481_2

PT1M

PT1M

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

PT10M

rID120615_122512_981_0

x-not Ditrapake

VEN130615_192312_582

Cepet DR Sample Laporan Payload Data - Khas B Profile Gunakake Case

LaporanUpdReqID130615_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

Kualitas apik - Non Spesifik

RP_54321

LaporanReqID130615_192625_730

LaporanSpecID120615_122512_481_2

TELEMETRY_USAGE

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

VEN130615_192312_582

Program Wektu Gunakake (TOU) Kendaraan Listrik Residen (EV)

Elinga yen program ngandhani tingkat tingkat kanthi bentuk sing cukup strukture, mung kasus panggunaan sing sederhana lan khas sing ditampilake

Skenario EV Residential 1 - Kasus Gunakake Sederhana, A utawa B Profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu wiwitan: 1pm
  • Duration: 24 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 1
  • Jeneng Sinyal: SIMPLE
    • Tipe Sinyal: level
    • Unit: N / A
    • Jumlah interval; pangowahan TOU undakan padha karo 24 jam (2 - 6)
    • Durasi interval: TOU bingkai wektu aktif tingkat (yaiku 6 jam)
    • Nilai Interval Biasa: 0 - 4 dipetakan menyang TOU Tiers
    • Target Sinyal: N / A
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Skenario EV Residential 2 - Kasus Gunakake Khas, B profile

• Acara
  • Kabar: Dina sadurunge acara
  • Wektu Mulai: tengah wengi
  • Duration: 24 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 2
  • Jeneng Sinyal: Prima
    • Tipe Sinyal: level
    • Unit: Level 0, 1, 2, 3
    • Jumlah interval: TOU Tier Tier sing padha ing 24 jam (2 - 6)
    • Durasi interval: TOU bingkai wektu aktif tingkat (yaiku 6 jam)
    • Nilai Interval Biasa: 0 - 4 dipetakan menyang TOU Tiers (0 - Tingkat Paling Murah)
    • Target Sinyal: Ora Ana
  • Jeneng Sinyal: ELECTRICITY_PRICE
    • Tipe Sinyal: rega
    • Unit: USD saben Kwh
    • Jumlah interval: pangowahan TOU Tier sing padha sajrone 24 jam (2 - 6)
    • Durasi interval: TOU bingkai wektu aktif tingkat (yaiku 6 jam)
    • Nilai Interval Biasa: $ 0.10 nganti $ 1.00 (tingkat undakan saiki)
    • Target Sinyal: Ora Ana
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Perumahan EV SampBeban Acara - Khas B Profile Gunakake Case

OadrDisReq091214_043740_513

TH_VTN

Acara091214_043741_028_0

0

http: // MarketContext1

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

adoh

<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

tingkat

SIG_01

0.0

PT5H

0

0.35

PT7H

1

0.55

PT7H

2

0.75

PT5H

3

0.55

LISTRIK_PRICE

regane

SIG_02

itunganPerKWh

USD

ora ana

0.0

venID_1234

tansah

Program Penetapan Real-Time Vehicle Electric Station (EV)

Elinga yen iki minangka program rega wektu nyata, ora ana bedane antarane kasus panggunaan sing prasaja, khas, lan rumit. Mulane sampdata le mung bakal ditampilake kanggo kasus panggunaan khas.

Skenario EV Stasiun Umum 1 - Kasus Gunakake Khas, B profile

• Acara
  • Kabar: 1 jam luwih dhisik
  • Wektu Mulai: 1pm
  • Duration: 1 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 1
  • Jeneng Sinyal: ELECTRICITY_PRICE
    • Tipe Sinyal: rega
    • Unit: USD saben Kwh
    • Cacah interval 1
    • Durasi interval: 1 jam
    • Nilai Interval Biasa: $ 0.10 nganti $ 1.00
    • Target Sinyal: Ora Ana
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: tansah
  • VEN Respon sing Diarepake: optIn
• Laporan
  • ora ana

Stasiun Umum EV SampBeban Acara - Khas B Profile Gunakake Case

OadrDisReq091214_043740_513

TH_VTN

Acara091214_043741_028_0

0

http: // MarketContext1

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

adoh

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

PT1H

PT1H

PT1H

0

0.75

LISTRIK_PRICE

regane

SIG_01

itunganPerKWh

USD

ora ana

0.0

venID_1234

tansah

Program DR Sumber Daya Energi Disebar (DER)

Elinga yen iki minangka program rega wektu nyata, ora ana bedane antarane kasus panggunaan sing prasaja, khas, lan rumit. Mulane sampdata le mung bakal ditampilake kanggo kasus panggunaan khas.

Skenario EV Stasiun Umum 1 - Kasus Gunakake Khas, B profile

• Acara
  • Kabar: Dina ngarep
  • Wektu Mulai: tengah wengi
  • Duration: 24 jam
  • Randomisasi: Ora Ana
  • Ramp Up: Ora ana
  • Pamulihan: Ora ana
  • Jumlah sinyal: 24
  • Jeneng Sinyal: ELECTRICITY_PRICE
    • Tipe Sinyal: rega
    • Unit: USD saben Kwh
    • Cacah interval 1
    • Durasi interval: 1 jam
    • Nilai Interval Biasa: $ 0.10 nganti $ 1.00
    • Target Sinyal: Ora Ana
  • Target Acara: venID_1234
  • Prioritas: 1
  • VEN Tanggepan dibutuhake: ora tau
  • VEN Ditanggepi Respon: n / a
• Laporan
  • ora ana

Stasiun Umum EV SampBeban Acara - Khas B Profile Gunakake Case

OadrDisReq091214_043740_513

TH_VTN

Acara091214_043741_028_0

0

http: // MarketContext1

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

adoh

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

PT24H

PT24H

PT1H

0

0.75

PT1H

1

0.80

LISTRIK_PRICE

regane

SIG_01

itunganPerKWh

USD

ora ana

0.0

venID_1234

ora nate

– Example Lapuran Saka Utility Pilots

Anggota OpenADR Alliance nyedhiyakake B Pro ing ngisor ikifile oadrUpdateReport muatan samples saka program pilot utilitas ngendi VENs wis disebarake. Cathetan ing ngisor iki diiringi telung payloads sampkasedhiya:

Tujuan Mbayar Termostat:

• Kudu ngerti status termostat (tempo, set point, kipas lan mode mode)
• Yen sampeyan milih, apa pelanggan ngganti setelan termostat (pesen override manual)

M&V kanggo Tujuan Mbayar Rebat:

• Status sumber daya lan override manual nalika milih
• Data interval saka Counter Pulsa KYZ utawa Monitor Energi kanggo total energi ing KWH lan panjaluk cepet ing KW

Tujuan Pembayaran Data Interval Smart Meter / AMI:

• Interval maca meter AMI udakara 15 menit nganti 1 jam. Sanajan migunani, ora cukup butiran kanggo prakiraan tagihan wektu nyata
• Total Energi ing KWH, energi delta ing KWH, panjaluk cepet ing KW

Ater-ater namespace ing ngisor iki digunakake ing 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/ -2011/06/XNUMX/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/ -2011/06/XNUMX/power”

Thermostat Report Payload 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

Status

bener

palsu

0

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Temp Saiki

77.000000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Setelan Temp Panas

64.000000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Setelan Tempel Keren

86.000000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Setelan Mode HVAC

3

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Mode HVAC Saiki

0.000000

Ora Ana Kualitas - Ora Ana Regane

Setelan Mode Kipas

2

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Mode Tahan Saiki

2

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Mode Away Saiki

0

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

Asor Saiki

0.000000

Ora Ana Kualitas - Ora Ana Regane

RP21

REQ: RReq: 1395368583267

0013A20040980FAE

TELEMETRY_STATUS

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

VEN.ID: 1395090780716

M&Vfor Rebate 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

Status

bener

palsu

Kualitas apik - Non Spesifik

Count Pulsa

34750.000000

Kualitas apik - Non Spesifik

Energi

33985.500000

Kualitas apik - Non Spesifik

Kekuwatan

1.26

Kualitas apik - Non Spesifik

RP15

REQ: RReq: 10453335019195698

0000000000522613 60

TELEMETRY_USAGE

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

VEN.ID: 1439831430142

Laporan Data Interval Smart Meter/AMI 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

instantaneousDemand

6.167000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

intervalDataDelivered

0.051000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

currSumDhantar

12172.052000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

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

PT15S

instantaneousDemand

6.114000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

intervalDataDelivered

0.051000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

currSumDhantar

12172.052000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

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

PT15S

instantaneousDemand

6.113000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

intervalDataDelivered

0.051000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

currSumDhantar

12172.142000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

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

PT15S

instantaneousDemand

6.112000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

intervalDataDelivered

0.051000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

currSumDhantar

12172.142000

Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake

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>

- Layanan

Bukak ADR ndhukung layanan ing ngisor iki:

• Layanan EiEvent - Digunakake dening VTNs kanggo ngirim acara nanggepi dikarepake kanggo VENs, lan digunakake dening VEN kanggo nunjukaké apa sumber bakal melu ing acara. Mung layanan sing didhukung dening A profile yaiku EiEvent
• Layanan EiReport - Digunakake dening VENs lan VTN kanggo ngganti laporan sejarah, telemetri, lan ramalan
• Layanan EiOpt - Digunakake dening VEN kanggo komunikasi jadwal kasedhiyan sementara menyang VTNs utawa kanggo kualifikasi sumber daya sing melu acara
• Layanan EiRegisterParty - Diwiwiti dening VEN, lan digunakake dening VEN lan VTN kanggo njaluk informasi sing dibutuhake kanggo njamin pertukaran muatan sing bisa ditindakake
• Layanan OadrPoll - Digunakake dening VENs kanggo jajak pendapat VTN kanggo muatan saka layanan liyane

A lan B profile operasi layanan ditetepake dening unsur ROOT saben muatan, ora kalebu oadrPayload lan oadrSignedObject pambungkus digunakake ing kabeh B profile muatan.

- Definisi Payload

EiEvent Payloads

• oadrRequestEvent – Digunakake ing model exchange narik dening VEN kanggo njupuk kabeh acara cocog saka VTN. Digunakake minangka mekanisme polling utami kanggo A profile VEN, nanging mung digunakake ing B VEN kanggo sinkronisasi karo VTN.
• oadrDistribusiEvent - Digunakake dening VTN kanggo ngirim acara tanggapan panjaluk menyang VEN
• oadrCreatedEvent - Digunakake dening VEN kanggo komunikasi apa arep melu ing acara kanthi milih utawa metu
• oadrResponse - Digunakake dening VTN kanggo ngakoni panrimo optIn utawa optOut saka VEN

Beban EiReport

Elinga yen VEN lan VTN bisa dadi produsen laporan lan panyuwunan laporan, mula kabeh muatan ing ngisor iki bisa diwiwiti dening salah siji pihak.

• oadrRegisterReport - Digunakake kanggo nerbitake kapabilitas nglaporake ing laporan metadata
• oadrRegistrReport -Akui kuitansi oadrRegisterReport, opsional njaluk salah sawijining laporan sing ditawakake
• oadrCreateReport - Digunakake kanggo njaluk laporan sing sadurunge ditawakake VEN utawa VTN
• oadrCreatedReport - Ngakoni panrimo panjaluk laporan
• oadrUpdateReport -Kirimake laporan sing dijaluk ngemot data interval
• oadrUpdatedReport - Ngakoni panrimo laporan sing dikirim
• oadrCancelReport - Batal laporan periodik sing dijaluk sadurunge
• oadrCanceledReport - Ngakoni pambatalan laporan periodik
• oadrResponse - Digunakake minangka respons placeholder ing sawetara pola pertukaran narik nalika respons lapisan aplikasi dikirim ing panjaluk lapisan transportasi.

EiOpt Payloads

• oadrCreateOpt - Digunakake kanggo rong tujuan sing beda banget
  • Supaya VEN komunikasi jadwal kasedhiyan sementara menyang VTN babagan kemampuane melu acara DR
  • Supaya VEN entuk kualifikasi sumber daya sing melu acara
• oadrCreatedOpt - Ngakoni kuitansi pambayaran oadrCreateOpt
• oadrCancelOpt -Batalake jadwal kasedhiyan sementara
• oadrCancelOpt - Ngakoni pambatalan laporan kasedhiyan sementara

 

Beban EiRegisterParty

• oadrQueryRegistrasi - Cara kanggo VEN nggoleki informasi registrasi VTNs tanpa ndaftar kanthi nyata.
• oadrCreatePartyReg registrasi - Panjaluk saka VEN menyang VTN kanggo ndhaptar. Ngemot informasi babagan kemampuan VENs.
• oadrCreatedPartyReg registrasi - Respon kanggo salah siji oadrQueryReg registrasi utawa oadrCreatePartyReg registrasi. Ngemot Kapabilitas VTN lan informasi registrasi sing dibutuhake kanggo VEN kanggo makarya
• oadrCancelPartyRegistrasi - Digunakake dening VEN utawa VTN kanggo mbatalake registrasi
• oadrCanceledPartyReg registrasi - Baleni maneh menyang oadrCancelPartyRegistrasi. Ngakoni panrimo saka pambatalan registrasi
• oadrRequestReregistrasi - Payload iki digunakake dening VTN ing model exchange exchange kanggo menehi tandha VEN kanggo miwiti urutan registrasi
• oadrResponse - Digunakake minangka respons placeholder ing sawetara pola pertukaran narik nalika respons lapisan aplikasi dikirim ing panjaluk lapisan transportasi.

Payload OadrPoll

• oadrPoll - Mekanisme poling umum kanggo B profile sing ngasilake muatan kanggo layanan liyane sing anyar utawa wis dianyari.
• oadrResponse - Digunakake kanggo nunjukake yen ora ana muatan anyar utawa sing dianyari

- Glosarium Unsur Pembayaran Skema

Ing ngisor iki minangka dhaptar unsur skema abjad sing digunakake ing muatan OpenADR 2.0. Narasi kasebut nggambarake panggunaan sing ana gandhengane karo OpenADR lan panggunaan payloads .. Yen definisi elemen diganti adhedhasar muatan sing ana ing utawa konteks panggunaan, iki bakal dicathet ing narasi. Definisi muatan root wis dikatutake kaya sing wis ditemtokake ing Annex C.

• ac - Nilai Boolean sing nuduhake manawa produk tenaga ganti saiki
• akurasi - Nomer ana ing unit sing padha karo variabel muatan kanggo interval. Yen wis yakin, nuduhake kemungkinan variasi ramalan kasebut. Yen saiki karo jinis maca, nuduhake kemungkinan kesalahan maos.
• agregatedPnode - Simpul rega agregat minangka jinis simpul rega khusus sing digunakake kanggo model barang kayata Zona Sistem, Zona Rega Default, Zona Rega Khusus, Area Kontrol, Generasi Gabungan, Beban Partisipasi Aggregasi, Beban Non-Partisipasi Aggregat, Hub Dagang, Zona DCA
• kasedhiya - Obyek sing ngemot tanggal-wektu lan durasi kanggo jadwal kasedhiyan EiOpt
• baselineID - ID unik kanggo garis dasar tartamtu
• baselineName - Jeneng deskriptif kanggo garis awal
• komponen –
• kapercayan - Kemungkinan statistik yen titik data sing dilaporake akurat
• digaweDateTime - DateTime payload digawe
• mata uang –
• itunganPerKW –
• itunganPerKWh –
• itunganPerThm –
• saiki –
• saikiValue - Nilai payloadFloat interval acara sing lagi ditindakake.
• customUnit - Digunakake kanggo netepake unit langkah khusus kanggo laporan kustom
• tanggal-wektu –
• dtstart - Wektu wiwitan kanggo kegiyatan, data, utawa pangowahan negara
• suwene - Periode wektu kanggo acara, nglaporake, utawa interval wektu sing kasedhiya
• durasi - Suwene kegiatan, data, utawa negara
• eiActivePeriod - Bingkai wektu cocog kanggo acara umum
• eiCreatedEvent - Nanggepi Acara DR kanthi optIn utawa optOut
• eiAcara -O obyek sing ngemot kabeh informasi kanggo sawijining acara
• eiEventBaseline - B profile
• eiEventSignal - Obyek sing ngemot kabeh informasi kanggo sinyal siji ing sawijining acara
• eiEventSignals - Data interval kanggo siji utawa luwih sinyal acara lan / utawa garis dasar
• eiMarketContext - URI kanthi unik ngenali program tanggapan panjaluk
• eiReportID - ID Referensi kanggo laporan
• eiRequestEvent - Nyuwun Acara saka VTN ing mode tarik
• eiResponse - Tandha manawa nampa bayaran bisa ditampa
• eiTarget - Ngidentifikasi sumber daya sing ana gandhengane karo antarmuka VEN logis. Kanggo acara, nilai sing ditemtokake minangka target acara kasebut
• endDeviceAsset - EndDeviceAssets minangka piranti fisik utawa piranti sing bisa uga meter utawa jinis piranti liyane sing bisa narik kawigaten
• energiParent - Energi sing katon, diukur ing volt-ampjam sadurunge (VAh)
• energiItem –
• energiReaktif - Energi reaktif, volt-ampjam reaktif (VARh)
• energiReal - Energi Nyata, Jam Watt (Wh)
• eventDescriptor - Informasi babagan acara
• eventID - Nilai ID sing ngenali kedadeyan acara DR tartamtu.
• acaraResponse - Obyek sing ngemot tanggepan VEN kanggo panjaluk melu acara
• eventResponses - optIn utawa optOut nanggepi acara sing ditampa
• status acara - Status acara saiki (adoh, cedhak, aktif, lsp)
• FeatureCollection / location / Polygon / exterior / LinearRing
• frekuensi –
• granularity – Iki interval wektu antarane sampdata mimpin ing request laporan.
• klompokID -Jinis target iki digunakake kanggo acara, laporan, lan jadwal milih. Nilai kasebut biasane bakal diwenehake dening utilitas nalika ndhaptar ing program DR
• jeneng grup - Target jinis iki digunakake kanggo acara, laporan, lan jadwal milih. Nilai kasebut biasane bakal diwenehake dening utilitas nalika ndhaptar ing program DR
• hertz –
• interval - Obyek sing ngemot data-time lan / utawa durasi, lan nilai sing bisa ditrapake yen ana kedadeyan utawa data nalika ana laporan
• interval - Siji utawa luwih interval wektu sajrone acara DR aktif utawa data laporan kasedhiya
• itemDeskripsi - Katrangan babagan unit laporan ukuran
• itemUnits - Unit dhasar pangukuran kanggo titik data laporan
• pasarKonteks - URI sing ngenali Program DR
• meterAsset - MeterAsset minangka piranti fisik utawa piranti sing nindakake peran meter
• modifikasiDateTime - Nalika acara diowahi
• modifikasi Nomer - Ditambah saben acara diowahi.
• Alasan - Napa acara diowahi
• mrid - MRID ngenali piranti fisik sing bisa uga minangka CustomerMeter utawa jinis EndDevices liyane.
• simpul - Node minangka papan sing ana pangowahan (asring kepemilikan) utawa nyambung ing kothak. Akeh simpul sing ana gandhengane karo meter, nanging ora kabeh.
• numDataSource –
• oadrKapasitas –
• oadr Saiki –
• oadrDataQualitas –
• oadrDeviceClass - Target Kelas Piranti - gunakake mung endDeviceAsset.
• oadrEvent - Obyek sing ngemot acara panjaluk panjaluk
• oadrExtension –
• oadrExtensionName -
• oadrExtensions –
• oadrHttpPullModel - Boolean sing nuduhake manawa VEN pengin nggunakake model exchange exchange
• oadrInfo - Pasangan nilai kunci informasi registrasi khusus layanan
• oadrKey –
• oadrLevelOffset –
• oadrLoadControlState –
• oadrManualOverride - Yen bener, kontrol beban wis diganti
• oadrMax –
• oadrMaxPeriod - Maksimum sampwektu ling
• oadrMin –
• oadrMinPeriod - Minimal sampwektu ling
• oadrNormal –
• oadrOnChange - Yen bener, data bakal direkam nalika ganti, nanging frekuensi ora luwih saka sing kasebut dening minPeriod.
• oadrOnline - Yen bener mula sumber / aset online, yen salah banjur offline.
• oadrPayload –
• oadrPayloadResourceStatus - Informasi status sumber saiki
• oadrPendingReports - Dhaptar laporan berkala sing isih aktif
• oadrPercentOffset –
• oadrProfile – kanggofile didhukung dening VEN utawa VTN
• oadrProfileJeneng - OpenADR profile jeneng kayata 2.0a utawa 2.0b.
• oadrProfiles – OpenADR profiles didhukung dening implementasine
• oadrReport -O obyek sing ngemot kabeh informasi kanggo siji laporan
• oadrReportDescription - Ngandharake ciri laporan sing ditawakake dening produsen laporan. Dikandhani ing laporan metadata
• oadrReportOnly - ReportOnlyDeviceFlag
• oadrReportPayload - Nilai titik data kanggo laporan
• oadrRequestedOadrPollFreq - VEN bakal ngirim muatan oadrPoll menyang VTN paling sepisan kanggo saben durasi sing ditemtokake dening elemen iki
• oadrResponseRequired - Kontrol yen milih nanggepi optIn / optOut dibutuhake. Bisa mesthi utawa ora tau
• oadrSamplingRate - Sampling rate kanggo data jinis telemetri
• oadrService –
• oadrServiceName - Target jinis iki digunakake kanggo acara, laporan, lan jadwal milih. Nilai kasebut biasane bakal diwenehake dening utilitas nalika ndhaptar ing program DR
• oadrServiceSpecificInfo - Informasi registrasi khusus layanan
• oadrSetPoint –
• oadrSignedObject –
• oadrTransport - Jeneng transportasi sing didhukung dening VEN utawa VTN
• oadrTransportAddress - Alamat ROOT digunakake kanggo komunikasi karo pihak liyane. Kudu kalebu port yen dibutuhake
• oadrTransportName - Jeneng transportasi OpenADR kayata simpleHttp utawa xmpp
• oadrTransports - OpenADR transports didhukung dening implementasi
• oadrUpdatedReport - Ngakoni panrimo laporan
• oadrUpdateReport - Kirim laporan sing dijaluk sadurunge
• oadrValue –
• oadrVenName - Jeneng VEN. Bisa digunakake ing VTN GUI
• oadrXmlSignature - Implementasi ndhukung tandha tangan XML
• optID - Pengenal kanggo interaksi opt
• optReason - Nilai sing dietung amarga alasan pilihan kayata x-jadwal
• optType - optIn utawa optOut saka acara, utawa digunakake kanggo nunjukake jinis jadwal pilihan sing ditetepake ing vavailablityObject kanggo layanan EiOpt
• partyID - Target jinis iki digunakake kanggo acara, laporan, lan jadwal milih. Nilai kasebut biasane bakal diwenehake dening utilitas nalika ndhaptar ing program DR
• payloadFloat - Nilai titik data kanggo sinyal acara utawa kanggo nglaporake nilai saiki utawa sejarah.
• pnode - Node rega langsung digandhengake karo simpul konektivitas. Iki minangka lokasi rega sing para peserta pasar ngirim tawaran, nawakake, tuku / adol CRR, lan ngrampungake.
• pointOfDelivery –
• pointOfReceipt –
• dhaptar Dhaptar –
• powerParent - Daya semu diukur ing volt-amperes (VA)
• dayaAttribut
• dayaItem
• dayaReaktif - Daya reaktif, diukur ing volt-ampreaktif (VAR)
• powerReal - Daya nyata sing diukur ing Watt (W) utawa Joule / detik (J / s)
• prioritas - Prioritas acara ana hubungane karo acara liyane (Nomer ngisor luwih dhuwur tinimbang prioritas. Nilai nol (0) ora nuduhake prioritas, yaiku prioritas paling endhek minangka standar).
• properti –
• pulsaCount - Titik data sing nglaporake
• pulseFactor - kWh saben dietung
• kualifikasiEventID - KTP unik kanggo sawijining acara
• jinis maca - Metadata babagan Waosan, kayata tegese utawa asale
• registrasiID - Pengenal transaksi Registrasi. Ora kalebu nanggepi registrasi query kajaba sing wis ndhaptar
• wangsulan - Jumlah acara maksimal kanggo bali kanthi pambayaran oadrDistributEvent
• reportBackDuration - Laporake maneh karo Laporan-Kanggo-Tanggal kanggo saben Durasi iki.
• reportDataSource - Sumber data ing laporan iki. Examples kalebu meter utawa submeter. Kanggo exampNanging, yen meter bisa nyedhiyakake rong jinis pangukuran, mula saben aliran pangukuran bakal diidentifikasi kanthi kapisah.
• reportInterval - Iki minangka periode pelaporan sakabèhé.
• reportName - Jeneng opsional kanggo laporan.
• reportRequestID - Pengenal kanggo panjaluk laporan tartamtu
• reportSpecifier - Nemtokake data sing dikarepake ing conto laporan tartamtu
• reportSpecifierID - Pengenal spesifikasi laporan Metadata tartamtu
• laporanSubjek - Target Kelas Piranti - gunakake mung endDeviceAsset.
• laporToFollow - Nuduhake yen laporan (ing bentuk UpdateReport) bakal dibalekake sawise dibatalake Laporan
• jinis laporan - Jinis laporan kayata panggunaan utawa rega
• requestID - ID sing digunakake kanggo cocog karo panjaluk lan tanggapan transaksi logis
• sumberID - Target jinis iki digunakake kanggo acara, laporan, lan jadwal milih. Nilai kasebut biasane bakal diwenehake dening utilitas nalika ndhaptar ing program DR
• wangsulan –
• kode respon - Kode respons 3 digit
• nanggepiDeskripsi - Katrangan narasi babagan status respons
• wangsulan –
• rID - ReferenceID kanggo titik data iki
• layananArea - Target jinis iki digunakake kanggo acara, laporan, lan jadwal milih. Nilai kasebut biasane bakal diwenehake dening utilitas nalika ndhaptar ing program DR
• serviceDeliveryPoint - Titik logis ing jaringan sing kepemilikan saka layanan ganti tangan. Iki minangka salah sawijining titik layanan sing bisa ditemtokake ing ServiceLocation, ngirim layanan sesuai karo Perjanjian Pelanggan. Digunakake ing papan sing bisa dipasang mèter.
• serviceLocation - A ServiceLocation pelanggan duwe siji utawa luwih ServiceDeliveryPoint (s), sing banjur gegayutan karo Meter. Lokasi kasebut bisa uga minangka titik utawa poligon, gumantung karo kahanan tartamtu. Kanggo distribusi, ServiceLocation biasane dadi lokasi premis pelanggan utilitas.
• signalID - Identifier unik kanggo sinyal acara tartamtu
• jeneng sinyal - Jeneng sinyal kayata SIMPLE
• signalPayload - Nilai sinyal kanggo acara lan garis dasar
• siScaleCode - Faktor skala kanggo unit dhasar pangukuran kanggo laporan
• specifierPayload - Mbukak
• wiwitane - Jendhela acak kanggo wiwitan acara
• statusDateTime - Tanggal lan wektu referensi artefak iki.
• suhu –
• testEvent - Apa wae sing ora bener nuduhake kedadeyan tes
• teks –
• Therm –
• toleransi - Sub obyek sing ngemot syarat acak kanggo sawijining acara
• ngidinke - Obyek sing ngemot syarat acak kanggo acara
• transportInterface - Antarmuka Transportasi nemtokake pinggiran ing salah sawijining ujung segmen transportasi.
• uid - Digunakake minangka indeks kanggo ngenali interval. Pengenal Unik
• nilai –
• vavailability - Jadwal sing nuduhake kasedhiyan piranti kanggo melu acara DR
• venid - Pengenal unik kanggo VEN
• voltage –
• vtnComment - Teks apa wae
• vtnID - Pengenal unik kanggo VTN
• x-eiNotifikasi - VEN kudu nampa pambayaran acara DR sadurunge dikurangi kanthi durasi iki.
• x-eiRampmunggah - Durasi sadurunge utawa sawise acara diwiwiti nalika gudang kudu transit.
• x-eiRec Recovery - Durasi sadurunge utawa sawise wektu pungkasan acara sajrone gudang kudu transit.

 

Glosarium Nilai Enumerated

status acara

• aktif - Acara kasebut wis diwiwiti lan saiki lagi aktif.
• dibatalake - Acara kasebut wis dibatalake.
• rampung - Acara wis rampung.
• adoh - Acara ditundha ing mangsa ngarep. Definisi sing tepat babagan wektu mbesuk sing diarani gumantung karo konteks pasar, nanging biasane tegese dina sabanjure.
• cedhak - Acara sing ditundha ing mangsa ngarep. Dhéfinisi sing tepat babagan sepira cedhak acara sing ditundha aktif gumantung ing konteks pasar. .Miwiti bebarengan karo wiwitan efektif saka acara x-eiRampWektu munggah. Yen x-eiRampUp ora ditetepake kanggo acara, status iki ora bakal digunakake kanggo acara.
• ora ana - Ora ana acara sing ditundha

itemUnit

• mata uang
  • USD - Dolar Amerika Serikat
  • Kanggo akeh dhaptar ing kene, waca skema
• daya Nyata
  • J/s - Joule-detik
  • W - Watts
• suhu
  • celsius –
  • fahrenheit –

oadrDataQualitas

• Ora Ana Nilai Anyar - Nilai Sadurunge Digunakake –
• Ora Ana Kualitas - Ora Ana Regane –
• Kualitas Ala - Gagal Kom –
• Kualitas Ala - Kesalahan Konfigurasi –
• Kualitas Ala - Gagal Piranti –
• Kualitas Ala - Nilai Paling Dikenal –
• Kualitas Ala - Ora Khusus –
• Kualitas Ala - Ora Sambung –
• Kualitas Ala - Ora Ana Layanan –
• Kualitas Ala - Gagal Sensor –
• Kualitas apik - Ngatasi Lokal –
• Kualitas apik - Non Spesifik –
• Watesan Kualitas - Lapangan / Constant –
• Watesan Kualitas - Lapangan / Dhuwur –
• Watesan Kualitas - Lapangan / Kurang –
• Watesan Kualitas - Lapangan / Ora –
• Kahanan Ora mesthi - Unit UE wis ngluwihi –
• Kualitas Ora mesthi - Nilai Paling Bisa Dienggo –
• Kualitas Ora mesthi - Ora Khusus –
• Kualitas Ora mesthi - Sensor Ora Akurat –
• Kualitas Ora mesthi - Sub Normal –

oadrResponseRequired

• tansah - Tansah ngirim tanggepan kanggo saben acara sing ditampa.
• ora tau - Aja nate nanggapi.

optReason

Alasan pilihan kanggo milih.

• ekonomi –
• darurat –
• kuduRun –
• oraPartisipasi –
• outageRunStatus –
• overrideStatus –
• melu –
• x-jadwal –

oadrTransportName

• prasajaHttp –
• xmpp –

OptType

• milih - Indikasi manawa VEN bakal melu acara, utawa ing layanan EiOpt, ana jinis jadwal sing nuduhake sumber bakal kasedhiya
• milih metu - Indikasi manawa VEN ora bakal melu acara, utawa ing layanan EiOpt, ana jinis jadwal sing nuduhake manawa sumber daya ora kasedhiya

jinis maca

• Dialokasikan - Meter nutupi sawetara [sumber] lan panggunaan disimpulake liwat sawetara komputasi data pro.
• Kontrak - Nuduhake manawa maca minangka pro forma, yaiku dilaporake kanthi tarif sing disepakati
• Asale - Panggunaan bisa dingerteni liwat ilmu babagan run-time, operasi normal, lsp.
• Maca Langsung - Maca diwaca saka piranti sing nambah kanthi monoton, lan panggunaan kudu diitung saka wiwitan maca lan mungkasi maca.
• Dikira-kira - Digunakake nalika maca ora ana ing seri sing umume maca.
• Hibrida - Yen digabungake, deleng macem-macem jinis maca ing jumlah ongko.
• Tegese - Maca minangka nilai rata-rata sajrone wektu sing dituduhake ing Granularity
• Net - Meter utawa [sumber] nyiyapake pitungan total panggunaan liwat wektu.
• Puncak - Maca minangka nilai Puncak (paling dhuwur) sajrone wektu sing dituduhake ing granularitas. Kanggo sawetara pangukuran, bisa uga nduweni arti luwih kanggo nilai paling murah. Bisa uga ora cocog karo waosan agregat. Mung valid kanggo aliran Item-rate Base, yaiku, Daya dudu Energi.
• Diproyeksikan - Nuduhake yen diwaca mengko, lan durung bisa diukur.
• Summed - Pirang-pirang meter bebarengan nyedhiyakake wacan kanggo [sumber] iki. Iki khusus beda karo gabungan, sing nuduhake macem-macem [sumber] ing muatan sing padha. Deleng uga Sato.
• x-not Ditrapake - Ora Ditrapake
• x-RMS - Alon Rata-Rata Root

laporanName

• HISTORY_GREENBUTTON - Laporan sing ngemot data tombol ijo ing struktur skema feed atom
• SEJARAH_USAGE - Laporan sing ngemot data panggunaan energi histrorical
• METADATA_HISTORY_GREENBUTTON - Laporan metadata sing nemtokake kapabilitas nglaporake kanggo laporan HISTORY_GREENBUTTON
• METADATA_HISTORY_USAGE - Laporan metadata sing nemtokake kapabilitas nglaporake kanggo laporan HISTORY_USAGE
• METADATA_TELEMETRY_STATUS - Laporan metadata sing nemtokake kapabilitas nglaporake kanggo laporan TELEMETRY_STATUS
• METADATA_TELEMETRY_USAGE - Laporan metadata sing nemtokake kapabilitas nglaporake kanggo laporan TELEMETRY_USAGE
• STATUS_TELEMETRY - Laporan sing ngemot informasi status sumber daya wektu nyata kayata negara online
• TELEMETRY_USAGE - Laporan sing ngemot informasi panggunaan energi nyata

jinis laporan

Nilai sing diétung sing menehi jinis laporan sing disedhiyakake.

• kasedhiyaEnergyStorage - Kapasitas sing kasedhiya kanggo panyimpenan energi luwih akeh, bisa uga tekan Target Energi
• avgDemand - Rata-rata panggunaan sajrone durasi sing dituduhake dening Granularity. Waca panjaluk kanggo informasi luwih lengkap.
• avgUkur - Rata-rata panggunaan sajrone durasi sing dituduhake dening Granularity. Deleng panggunaan kanggo informasi luwih lengkap.
• dhasar - Bisa dadi panjaluk utawa panggunaan, kaya sing dituduhake dening ItemBase. Nuduhake apa [pangukuran] yen ora kanggo acara utawa peraturan. Laporan kalebu format Baseline.
• deltaDemand - Owahi panjaluk dibandhingake karo garis awal. Waca panjaluk kanggo informasi luwih lengkap
• deltaSetPoint - Pangowahan ing titik pungkasan saka jadwal sadurunge.
• deltaUsage - Owahi panggunaan dibandhingake karo garis dasar. Deleng panggunaan kanggo informasi luwih lengkap
• panjaluk - Laporan nuduhake jumlah unit (denominasi ing ItemBase utawa ing Produk EMIX). Jinis muatan yaiku Quantity. ItemBase khas yaiku Daya Nyata.
• panyimpangan - Bedane sawetara instruksi lan negara nyata.
• downRegulationCapacityA kasedhiya - Kapasitas Regulasi Down sing kasedhiya kanggo dikirim, ditulis ing EMIX Real Power. Payload mesthi ditulis minangka Quantity positif.
• tingkat - Tingkat sederhana saka pasar ing saben interval.
• operasiState - Negara sumber umum kayata on / off, hunian bangunan, lsp. Ora Ana ItemBase sing relevan. Mbukak Ekstensi Payload Khusus Aplikasi.
• persenPanjaluk - Persentage saka panjaluk
• persenKanggo - Persentage panggunaan
• panguwasa - Faktor daya kanggo sumber daya
• regane - Rega saben ItemBase ing saben interval
• maca - Laporan nuduhake maca, kaya saka meter. Maca minangka wayahe pangowahan wektu kanthi suwe bisa dietung saka prabédan ing antarane maos berturut-turut. Jinis muatan yaiku ngambang
• angger-anggerSetpoint - Setpoint regulasi kaya sing diwenehake minangka bagean saka layanan regulasi
• ongko terakhir sing menentukan - Laporan nuduhake jumlah (denominasi ing ItemBase utawa ing Produk EMIX) sing saiki disetel. Bisa uga konfirmasi / bali saka nilai kontrol setpoint sing dikirim saka VTN. Jinis muatan yaiku Quantity. ItemBase khas yaiku Daya Nyata.
• disimpenEnergy - Energi sing Disimpen ditulis minangka Energi Nyata lan Payload ditulis minangka Quantity.
• targetEnergyStorage - Target Energi ditulis minangka Energi Nyata lan Payload ditulis minangka Quantity.
• upRegulationCapacityA kasedhiya - Kapasitas Regulasi sing kasedhiya kanggo dikirim, ditulis ing EMIX Real Power. Payload mesthi ditulis minangka Quantity positif.
• panggunaan - Laporan nuduhake jumlah unit (denominasi ing ItemBase utawa ing Produk EMIX) sajrone wektu. Jinis muatan yaiku Quantity. ItemBase khas yaiku RealEnergy
• x-resourceStatus - Persentage saka panjaluk

kode skala

• p - Pico 10 ** - 12
• n - Nano 10 ** - 9
• mikro - Mikro 10 ** - 6
• m - Milli 10 ** - 3
• c - Centi 10 ** - 2
• d - Desember 10 ** - 1
• k - Kilo 10 ** 3
• M - Mega 10 ** 6
• G - Giga 10 ** 9
• T - Tera 10 ** 12
• ora ana - Skala Asli

jeneng sinyal

• BID_ENERGY - Iki jumlah energi saka sumber sing ditawakake program
• BID_LOAD - Iki jumlah muatan sing ditawakake sumber menyang program
• BID_PRICE - Iki rega sing ditawakake sumber
• CHARGE_STATE - Negara sumber energi panyimpenan
• DEMAND_CHARGE - Iki biaya panjaluk
• LISTRIK_PRICE - Iki regane listrik
• ENERGY_PRICE - Iki biaya energi
• LOAD_CONTROL -Setel output output menyang nilai relatif
• LOAD_DISPATCH - Iki digunakake kanggo ngirim momotan
• prasaja - disusut - kanggo kompatibilitas mundur karo A profile
• SIMPLE - Tingkat sederhana (tundhuk OpenADR 2.0a)

jinis sinyal

Nilai sing dietung nggambarake jinis sinyal kayata level utawa rega

• delta - Sinyal nuduhake jumlah sing bakal diganti saka sing bakal digunakake tanpa sinyal.
• tingkat - Sinyal nuduhake level program.
• multipliedr - Signal nuduhake multiplier sing ditrapake kanggo tarif pangiriman utawa panggunaan saiki saka sing bakal digunakake tanpa sinyal.
• regane - Sinyal nuduhake rega.
• regaMultiplier - Sinyal nuduhake multiplier rega. Rega sing ditambahi yaiku rega regane sing dietung kaping pirang-pirang unit.
• regaHubungan - Sinyal nuduhake rega relatif.
• titik titik - Sinyal nuduhake jumlah target unit.
• x-loadControlKapasitas – Iki instruksi kanggo mbukak controller kanggo operate ing tingkat sing sawetara persentage saka kapasitas konsumsi mbukak maksimum sawijining. Iki bisa dipetakan menyang pengontrol beban khusus kanggo nindakake kaya tugas muter. Elinga yen 1.0 nuduhake konsumsi 100%. Ing kasus piranti jinis ON / OFF prasaja banjur 0 = OFF lan 1 = ON.
• x-loadControlLevelOffset - Tingkat bilangan bulat diskriminasi sing relatif karo operasi normal ing 0 yaiku operasi normal.
• x-loadControlPercentOffset - Persentage owah-owahan saka operasi kontrol beban normal.
• x-loadControlSetpoint - Load set set controller.

- OpenADR A lan B Profile Bedane

Mung layanan sing didhukung dening A profile yaiku layanan EiEvent. Obyek EiEvent wis simplified ing A profile kanthi watesan ing ngisor iki:

• Mung siji sinyal saben acara sing diidini lan sinyal kasebut kudune minangka sinyal OpenADR sing SIMPLE.
• Ana target target winates sing mung didhukung venID, groupID, resourceID, lan partyID. (EiEvent: eiTarget).
• Target ing level sinyal karo kelas piranti ora didhukung (eiEventSignal: eiTarget: endDeviceAsset).
• Baseline ora didhukung (eiEvent: eiEventSignals: eiEventBaseline).
• modifikasiDateTime lan modifikasiReason ora didhukung.
• Titik pungkasan URL kanggo HTTP sederhana ing 2.0b yaiku:
  • https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Sawetara unsur muatan sing dibutuhake ing A profile saiki opsional ing B profile, kalebu:

• Nilai saiki

- Sertifikat Keamanan OpenADR

Aturan kesesuaian OpenADR mbutuhake ing ngisor iki:

• TLS Versi 1.2 digunakake kanggo ijolan sertifikat X.509
• VTN kudu duwe sertifikat SHA256 ECC lan RSA
• VEN bisa ndhukung sertifikat SHA256 ECC lan RSA, lan bisa ndhukung kalorone
• VTN lan VEN kalorone kudu dikonfigurasi kanggo njaluk sertifikat klien yen bakal duwe peran server transportasi (yaiku nanggepi panjaluk saka pihak liyane)
• VTN lan VEN kudu nyedhiyakake sertifikat klien yen dijaluk pihak liya minangka bagean saka proses negosiasi TLS

Sertifikat sing diwenehake dening NetworkFX bakal khusus kanggo RSA utawa ECC. Nggawe sertifikat kasebut bisa kedadeyan minangka asil ngisi formulir ing NetworkFX web situs kanggo njaluk sertifikat test utawa bisa uga minangka asil saka njaluk sertifikat produksi liwat Certificate Signing Request (CSR). Preduli saka cara, ing ngisor iki files bakal diwenehake (misamples ditampilake):

• Sertifikat Root
• Sertifikat ROOT Penengah
• Sertifikat Piranti
• Kunci Pribadi

Umumé, Kunci Pribadi digunakake kanggo ndhelik muatan sing dikirim dening VEN utawa VTN. Sertifikat Piranti minangka kumpulan informasi identifikasi unik babagan VEN utawa VTN sing digawe dening Otoritas Sertifikat lan dienkripsi nggunakake Kunci Pribadi. Root lan Penengah files digunakake kanggo dekripsi Sertifikat Piranti lan verifikasi manawa sertifikat kasebut asale saka panguwasa sing dipercaya.

Ing lingkungan Jawa sing nggunakake JSSE, ana rong toko sertifikat. Siji diarani Trust Store lan digunakake kanggo nyekel Root Certificate. Sing nomer loro diarani Key Store lan digunakake kanggo nyimpen rantai sertifikat sing kasusun saka sertifikat tengah sertifikat piranti, uga kunci pribadi

Elinga yen nggunakake transportasi XMPP, VEN komunikasi karo server XMPP lan ora langsung karo VTN. Dadi konfigurasi sertifikat ing server XMPP Kudu padha karo VTN. Komunikasi antarane VTN dhewe lan server XMPP transparan karo VEN lan intine link pribadi. Nanging, umume vendor nggunakake set cerdas VEN ing VTN nalika komunikasi karo server XMPP.

Yen sampeyan nggunakake OpenFire minangka server XMPP, ana kendala liyane sing kudu sampeyan pikirake. OpenFire mbutuhake jeneng CN sing digunakake ing sertifikat piranti klien cocog karo jeneng pangguna XMPP piranti sing wis diatur ing server XMPP. Iki bisa nyebabake sawetara jeneng klien sing ganjil amarga alamat MAC kaya digunakake kanggo jeneng CN ing sertifikat VEN (Bagéan saka Syarat Keamanan OpenADR)

Pungkasan, umume VEN lan VTN nalika main peran klien transportasi bakal nyoba validasi manawa bidang sertifikat CN sing diwenehake dening server transportasi duwe jeneng CN sing cocog karo jeneng host entitas sing nyedhiyakake sertifikat kasebut. Iki bisa uga dadi sumber masalah interoperabilitas liyane nalika ijolan sertifikat. Verifikasi Jeneng Host biasane bisa dipateni kanthi cara pemrograman kanggo ngisolasi jinis masalah kasebut.

Pandhuan Program Respon Permintaan OpenADR 2.0 - Download [dioptimalake]
Pandhuan Program Respon Permintaan OpenADR 2.0 - Ngundhuh

Referensi

• Manual pangguna