BukaADR 2.0
Panduan Program Respons Permintaan
Nomor Revisi: 0.92
Status Dokumen: Teks Kerja
Nomor Dokumen: 20140701
Hak Cipta © OpenADR Alliance (2014/15). Seluruh hak cipta. Informasi dalam dokumen ini adalah milik OpenADR Alliance dan penggunaan serta pengungkapannya dibatasi.
ISI
5 Jenis Program Respons Permintaan 9
7 Skenario Penerapan dan Pemetaan Program DR 16
8 Memilih Template Program DR 18
9 Template Program Respon Permintaan 21
9.1 Program Penetapan Harga Puncak Kritis (CPP) 21
9.1.1 Karakteristik Program CPP DR 21
9.1.2 Karakteristik OpenADR untuk Program CPP 22
9.2 Program Penawaran Kapasitas 24
9.2.1 Karakteristik Program DR Penawaran Kapasitas 24
9.2.2 Karakteristik OpenADR untuk Program Penawaran Kapasitas 25
9.3 Program Termostat Rumah 27
9.3.1 Karakteristik Program DR Termostat Rumah 27
9.3.2 Karakteristik OpenADR untuk Program Termostat Rumah 28
9.4.1 Karakteristik Program Pengiriman DR Cepat 29
9.4.2 Karakteristik OpenADR untuk Program Penawaran Kapasitas 31
9.5 Program Waktu Penggunaan (TOU) Kendaraan Listrik Rumah (EV) 33
9.5.1 Karakteristik Program EV TOU Perumahan 33
9.5.2 Karakteristik OpenADR untuk Program EV TOU Perumahan 33
9.6 Program Penetapan Harga Real-Time Kendaraan Listrik Stasiun Umum (EV) 34
9.6.1 Karakteristik Program EV RTP Stasiun Umum 34
9.6.2 Karakteristik OpenADR untuk Program EV RTP Stasiun Umum 34
9.7 Program DR Sumber Daya Energi yang Didistribusikan (DER) 35
9.7.1 Karakteristik Program Sumber Daya Energi yang Didistribusikan (DER) 35
9.7.2 Karakteristik OpenADR untuk Sumber Daya Energi Terdistribusi (DER) 35
Lampiran A – Sample Template Data dan Payload 36
A.1 Program Penetapan Harga Puncak Kritis (CPP) 36
A.1.1 CPP Skenario 1 – Kasus Penggunaan Sederhana, A atau B Profile 36
A.1.2 CPP Skenario 2 – Kasus Penggunaan Tipikal, B profile 36
A.1.3 Skenario CPP 3 - Kasus Penggunaan Kompleks 37
A.1.4 CPP Sample Muatan Acara – Khas B Profile Gunakan Kasus 37
A.2 Program Penawaran Kapasitas (CBP) 39
A.2.1 CBP Skenario 1 – Kasus Penggunaan Sederhana, A atau B Profile 39
A.2.2 Skenario 2 CBP – Kasus Penggunaan Tipikal, B profile 39
A.2.3 Skenario 3 CBP - Kasus Penggunaan Kompleks 40
A.2.4 CBP Sample Muatan Acara – Khas B Profile Gunakan Kasus 40
A.3 Program Termostat Rumah 42
A.3.1 Skenario Termostat Perumahan 1 – Kasus Penggunaan Sederhana, A atau B Profile 42
A.3.2 Skenario Termostat Perumahan 2 – Kasus Penggunaan Khusus, B profile 42
A.3.3 Skenario Termostat Perumahan 3 - Kasus Penggunaan yang Kompleks 43
A.3.4 Termostat Perumahan Sample Muatan Acara – Khas B Profile Gunakan Kasus 43
A.4.1 Skenario DR Cepat 1 – Kasus Penggunaan Sederhana, A atau B Profile 45
A.4.2 Skenario DR Cepat 2 – Kasus Penggunaan Tipikal, B profile 45
A.4.3 Skenario DR Cepat 3 - Kasus Penggunaan Kompleks 46
A.4.4 Cepat DR Sample Muatan Acara – Khas B Profile Gunakan Kasus 46
A.4.5 Cepat DR Sample Laporkan Muatan Metadata – Tipikal B Profile Gunakan Kasus 48
A.4.6 Cepat DR Sample Laporan Permintaan Payload – Tipikal B Profile Gunakan Kasus 48
A.4.7 Cepat DR Sample Laporkan Muatan Data – Tipikal B Profile Gunakan Kasus 49
A.5 Program Waktu Penggunaan Kendaraan Listrik Rumah (EV) (TOU) 49
A.5.1 Perumahan EV Skenario 1 – Kasus Penggunaan Sederhana, A atau B Profile 49
A.5.2 Perumahan EV Skenario 2 – Kasus Penggunaan Khusus, B profile 50
A.5.3 EV S Perumahanample Muatan Acara – Khas B Profile Gunakan Kasus 50
A.6 Program Penetapan Harga Real-Time Kendaraan Listrik Stasiun Umum (EV) 53
A.6.1 Stasiun Umum EV Skenario 1 – Kasus Penggunaan Tipikal, B profile 53
A.6.2 Stasiun Umum EV Sample Muatan Acara – Khas B Profile Gunakan Kasus 53
A.7 Program DR Sumber Daya Energi yang Didistribusikan (DER) 54
Lampiran B - Definisi Layanan dan Muatan 55
B.1 Open ADR mendukung layanan berikut: 55
Lampiran C - Definisi Layanan dan Muatan 56
Lampiran D - Glosarium Elemen Muatan Skema 58
Lampiran E Glosarium Nilai Enumerasi 65
Lampiran F – OpenADR A dan B Profile Perbedaan 70
Lampiran G - Sertifikat Keamanan OpenADR 71
Perkenalan
Target audiens untuk panduan ini adalah utilitas yang berencana untuk menyebarkan program Demand Response (DR) yang memanfaatkan OpenADR 2.0 untuk mengkomunikasikan pesan terkait peristiwa DR antara utilitas dan entitas hilir, dan produsen peralatan yang memfasilitasi pertukaran komunikasi tersebut. Diasumsikan bahwa pembaca memiliki pemahaman konseptual dasar dari kedua respon permintaan dan OpenADR 2.0 (dirujuk hanya sebagai OpenADR mulai saat ini).
Pro OpenADRfile spesifikasi dengan jelas mendefinisikan perilaku yang diharapkan saat bertukar informasi terkait peristiwa DR, namun ada cukup banyak pilihan di OpenADR sehingga penerapan server (VTN) di utilitas dan klien (VEN) di situs hilir bukanlah pengalaman plug-n-play. Karakteristik OpenADR seperti sinyal peristiwa, format laporan, dan penargetan harus ditentukan berdasarkan program per program DR.
Tidak ada yang namanya program DR standar. Setiap rancangan program DR cenderung unik, sesuai dengan persyaratan struktural dan peraturan dari wilayah geografis tempat program itu ditempatkan. Untuk setiap program DR ada banyak kemungkinan skenario penyebaran yang melibatkan berbagai pelaku.
Variabilitas dalam desain program DR, skenario penyebaran, dan karakteristik OpenADR merupakan penghambat penyebaran DR yang diperluas dan penggunaan OpenADR. Variabilitas ini sebagian besar merupakan cerminan dari sifat jaringan cerdas yang terfragmentasi dan kompleks.
Utilitas membutuhkan exampbeberapa program DR yang khas sehingga dapat digunakan sebagai model untuk implementasi program DR mereka sendiri. Produsen peralatan perlu memahami model penggunaan Program DR yang khas sehingga mereka dapat memvalidasi interoperabilitas sebagai bagian dari proses pengembangan daripada berdasarkan penerapan program DR secara spesifik. Maksud dari panduan ini adalah untuk mencapai kedua tujuan ini sebagai berikut:
- Tentukan sekumpulan kecil template Program DR standar yang dimodelkan setelah karakteristik umum dari program DR paling populer yang diterapkan hingga saat ini
- Tentukan sekumpulan kecil skenario penerapan yang dimodelkan setelah penerapan dunia nyata, dengan aktor dan peran yang diidentifikasi dengan jelas
- Tentukan rekomendasi praktik terbaik untuk karakteristik OpenADR yang spesifik untuk setiap template DR Program
- Sediakan pohon keputusan yang dapat digunakan utilitas untuk mengidentifikasi templat program DR yang berguna dan skenario penerapan berdasarkan kebutuhan bisnis mereka
Penekanan dalam panduan ini akan menjaga hal-hal sederhana dengan memberikan sekumpulan kecil rekomendasi yang jelas yang akan membahas sebagian besar detail yang diperlukan untuk menerapkan program DR yang khas, dan untuk memungkinkan pengujian interoperabilitas peralatan yang digunakan dalam program menggunakan rekomendasi dalam hal ini. panduan.
Referensi
- OpenADR Profile Spesifikasi dan skema – www.openadr.org
Istilah dan Definisi
Istilah dan definisi berikut digunakan dalam dokumen ini.
- Respon Permintaan: Mekanisme untuk mengelola permintaan beban pelanggan sebagai respons terhadap kondisi pasokan, seperti sinyal harga atau ketersediaan
- Partai Agregator - Ini adalah pihak yang menggabungkan beberapa Sumber Daya bersama-sama dan menyajikannya kepada Pihak Program DR sebagai Sumber Daya tunggal dalam Program DR mereka.
- Infrastruktur Perantara Agregator - Ini adalah infrastruktur, terpisah dari Infrastruktur Sisi Permintaan, yang digunakan oleh Pihak Perantara Agregator untuk berinteraksi dengan Sumber Daya dan entitas sisi jaringan
- Perjanjian: Perjanjian kontrak antara pihak-pihak yang berperan dalam program DR yang menguraikan tanggung jawab dan kompensasi
- Aset - Jenis Sumber Daya yang mewakili kumpulan beban fisik tertentu. Sumber Daya dapat terdiri dari Aset, dan Aset dapat berupa Sumber Daya, tetapi Aset tidak dapat diuraikan lebih lanjut menjadi beberapa Aset atau Sumber Daya.
- Terkait: Menyediakan asosiasi terprogram antara dua entitas, melalui konfigurasi perangkat database. Misalnya, sumber daya terkait dengan VEN
- Dasar: Penggunaan energi yang dihitung atau diukur (permintaan) oleh peralatan atau lokasi sebelum acara seperti yang ditentukan melalui survei, inspeksi, dan / atau pengukuran di lokasi.
- BMS - Ini adalah Sistem Manajemen Gedung yang dapat digunakan untuk mengontrol sumber daya. Ini kadang-kadang disebut sebagai Sistem Manajemen Energi.
- Sumber Daya Gabungan - Ini adalah jenis Sumber Daya khusus yang merupakan agregasi dari beberapa aset fisik yang masing-masing memiliki alat kontrol bebannya sendiri.
- Insentif Pelanggan: Bujukan yang diberikan kepada pemilik / agregator sumber daya sisi permintaan untuk berpartisipasi dalam program DR.
- Infrastruktur Sisi Permintaan - Ini adalah infrastruktur yang menampung Sumber Daya yang terdaftar di Program DR
- DR Logika: Algoritme atau logika yang mengubah sinyal DR menjadi kontrol beban yang dapat ditindaklanjuti. Perhatikan bahwa DR Logic dapat diterapkan di banyak lokasi berbeda dan dalam beberapa kasus didistribusikan di antara beberapa sub-sistem.
- Partai Program DR - ini adalah entitas yang bertanggung jawab atas Infrastruktur Jaringan dan selanjutnya untuk mengelola Program DR yang digunakan untuk mengurangi masalah jaringan. Biasanya ini adalah Utilitas atau ISO.
- Terdaftar: Pemilik / agregator sumber daya sisi permintaan memilih untuk berpartisipasi dalam program DR dan dapat memberikan informasi tentang sumber daya spesifik yang mungkin ditargetkan untuk acara DR
- Periode Aktif Acara: Periode waktu di mana perubahan beban profile sedang diminta sebagai bagian dari Acara DR
- Kendala Acara: Kerangka waktu di mana pelanggan dapat berharap untuk menerima acara dan kendala terkait seperti tidak ada acara pada akhir pekan atau hari berturut-turut
- Hari Acara: Suatu hari ketika peristiwa DR terjadi. Sebagian besar program memiliki batasan jumlah hari acara yang diperbolehkan dalam periode kalender tertentu
- Deskriptor Acara: Bagian dari objek acara OpenADR yang menjelaskan metadata tentang acara, seperti nama program dan prioritas acara
- Durasi Acara: Durasi acara. Sebagian besar program menentukan batasan durasi acara, serta jam acara dapat berlangsung
- Sinyal Peristiwa: Informasi yang dapat ditindaklanjuti yang terkandung dalam suatu peristiwa seperti harga listrik atau tingkat tertentu dari pelepasan muatan yang diminta yang biasanya memicu beberapa perilaku pelepasan muatan yang telah diprogram sebelumnya oleh penerima peristiwa tersebut. Definisi program DR harus menentukan jenis sinyal peristiwa yang digunakan
- Penargetan Acara: Sumber daya pelepasan beban yang merupakan penerima yang dimaksudkan untuk acara DR. Mungkin area geografis, kelas perangkat tertentu, pengenal grup, ID sumber daya, atau pengenal lainnya. Definisi program DR harus menentukan bagaimana sumber daya spesifik akan ditargetkan.
- Acara: Peristiwa adalah pemberitahuan dari utilitas ke sumber daya sisi permintaan yang meminta pelepasan muatan yang dimulai pada waktu tertentu, selama durasi tertentu, dan dapat mencakup informasi penargetan yang menunjuk sumber daya tertentu yang harus berpartisipasi dalam acara tersebut.
- Infrastruktur Perantara Fasilitator - Ini adalah infrastruktur, terpisah dari Infrastruktur Sisi Permintaan, yang digunakan oleh Pihak Perantara Fasilitator untuk berinteraksi dengan Sumber Daya dan entitas sisi jaringan.
- Fasilitator: Pihak ketiga yang mengelola beberapa atau semua eksekusi program DR atas nama utilitas
- Infrastruktur Jaringan - Ini adalah infrastruktur yang dimiliki atau dikelola oleh Pihak Program DR. Infrastruktur ini mencakup implementasi OpenADR VTN yang digunakan untuk mengirim sinyal DR ke Sumber Daya yang terdaftar di Program DR
- Pihak Perantara - Ini adalah pihak yang biasanya bekerja atas nama Resource Party untuk memfasilitasi partisipasi mereka dalam Program DR.
- Kontrol Beban – ini adalah infrastruktur yang terkait dengan Sumber Daya yang bertanggung jawab untuk benar-benar mengendalikan Sumber Daya dan menghasilkan beban tertentufile.
- Muat Profile Tujuan: Motivasi di balik pengembangan program DR dan penerbitan acara. Seperti keinginan mencukur beban puncak.
- Pemberitahuan: Jangka waktu sebelum waktu mulai suatu peristiwa ketika pemilik sumber daya sisi permintaan diberi tahu tentang peristiwa yang menunggu keputusan
- Perilaku Memilih: Respons yang diharapkan dari pemilik sumber daya sisi permintaan setelah menerima suatu peristiwa. Tanggapan ini dapat berupa dan OptIn atau indikasi OptOut apakah sumber daya akan berpartisipasi dalam acara tersebut atau tidak
- Tanggapan Opt: Apakah program tertentu harus memerlukan respons dari sumber daya sisi permintaan sebagai respons terhadap suatu peristiwa, dan apa biasanya respons tersebut.
- Layanan Opt: Jadwal dikomunikasikan melalui OpenADR untuk menunjukkan perubahan sementara dalam ketersediaan sumber daya untuk berpartisipasi dalam acara.
- Prasyarat: Kriteria yang harus dipenuhi agar pemilik sumber daya sisi permintaan untuk mendaftar dalam program DR. Ini mungkin termasuk ketersediaan pertemuan interval atau beberapa kapasitas gudang beban minimum
- Driver Utama: Motivasi utama pada bagian utilitas untuk membuat program DR dan acara penerbitan. Seperti "Penurunan permintaan puncak dan kecukupan sumber daya"
- Program - Ini adalah Program DR tempat Sumber daya terdaftar.
- Deskripsi Program: Deskripsi naratif tentang cara kerja program. Bagian dari template Program DR yang ditentukan dalam dokumen ini
- Jangka Waktu Program: Waktu dalam setahun atau musim selama program DR biasanya aktif
- Tingkat Desain: Modifikasi khusus pada struktur tarif atau insentif yang dibayarkan untuk memotivasi pemilik sumber daya sisi permintaan untuk berpartisipasi dalam program
- Layanan Pendaftaran: Layanan yang digunakan oleh protokol OpenADR untuk membangun interoperabilitas dasar antara VTN dan VEN, dan untuk memvalidasi bahwa VEN dikaitkan dengan akun pelanggan utilitas.
- Layanan Pelaporan: Layanan yang digunakan oleh OpenADR untuk memungkinkan VEN menyediakan pelaporan ke VEN. Program DR harus menentukan persyaratan pelaporan untuk program tersebut.
- Partai Sumber Daya - Ini adalah pihak yang memiliki Sumber Daya sisi permintaan yang mungkin terdaftar di Program DR
- Sumber – Ini adalah entitas yang terdaftar dalam Program DR dan mampu memberikan semacam perubahan pada beban profile dalam menanggapi menerima sinyal DR dari VTN.
- Target Pelanggan: Ahlifile sumber daya sisi permintaan yang dapat mendaftar dalam program DR tertentu seperti perumahan, industri, atau mungkin berdasarkan tingkat konsumsi listrik.
- Beban Target: Sumber daya sisi permintaan yang muatnya harus dimodifikasi setelah menerima a
- Bahasa Indonesia - Ini adalah OpenADR Virtual End Node yang digunakan untuk berinteraksi dengan VTN.
- VTN - Ini adalah OpenADR Virtual Top Node yang digunakan untuk berinteraksi dengan Sumber daya yang terdaftar di Program DR.
Singkatan
- BMS: Sistem Manajemen Gedung
- K&I: Komersial dan Industri
- Comm: Komunikasi antara dua entitas
- DR: Respon Permintaan
- Layanan Medis Darurat: Sistem Manajemen Energi
- BukaADR: Buka Respons Permintaan Otomatis
- Program: Referensi ke Program Respons Permintaan
- Bahasa Indonesia: Node Akhir Virtual
- VTN: Node Atas Virtual
Jenis Program Respons Permintaan
Dokumen ini berisi template untuk program DR yang ditunjukkan di bawah ini.
1. Harga Puncak Kritis: Struktur tarif dan / atau harga yang dirancang untuk mendorong pengurangan konsumsi selama periode harga pasar grosir yang tinggi atau kemungkinan sistem dengan memberlakukan tarif atau harga tinggi yang telah ditentukan sebelumnya untuk beberapa hari atau jam tertentu.
2. Program Penawaran Kapasitas: Program yang memungkinkan sumber daya permintaan di pasar eceran dan grosir untuk menawarkan pengurangan beban dengan harga tertentu, atau untuk mengidentifikasi berapa banyak beban yang bersedia dikurangi dengan harga tertentu.
3. Program Termostat Perumahan / Kontrol Beban Langsung: Aktivitas respons permintaan di mana sponsor program mengontrol peralatan listrik pelanggan dari jarak jauh (mis. AC) dalam waktu singkat. Program-program ini terutama ditawarkan kepada pelanggan perumahan atau komersial kecil.
4. Program Pengiriman DR Cepat / Layanan Tambahan: Program respons permintaan yang memberikan pembayaran insentif kepada pelanggan untuk respons beban selama Peristiwa Tanggap Permintaan Darurat. Kondisi sistem yang tidak normal (misalnyaample, kendala sistem dan kendala kapasitas lokal) yang memerlukan tindakan manual otomatis atau segera untuk mencegah atau membatasi kegagalan fasilitas transmisi atau pasokan pembangkit yang dapat mempengaruhi keandalan Sistem Listrik Curah. Jenis program ini terkadang disebut sebagai “Layanan Tambahan”.
5. Program Kendaraan Listrik (EV) DR: Aktivitas respons permintaan di mana biaya pengisian kendaraan listrik dimodifikasi untuk menyebabkan konsumen mengubah pola konsumsi.
6. Program DR Sumber Daya Energi yang Didistribusikan (DER): Aktivitas respons permintaan yang digunakan untuk memperlancar integrasi pendistribusian sumber daya energi ke jaringan pintar.
Skenario Penerapan
Cara penerapan program DR agak tidak bergantung pada karakteristik program DR itu sendiri. Diagram berikut menunjukkan berbagai cara di mana program DR dapat diterapkan. Bagian berikut ini memberikan referensi silang antara skenario penyebaran dan Program DR yang kemungkinan besar akan mereka gunakan.
Diagram di bagian ini menunjukkan hubungan antara entitas dalam berbagai skenario.
Langsung 1
Ini adalah skenario sederhana di mana ada hubungan langsung antara DR Program Party dan Resource Party. Pihak Sumber Daya bertanggung jawab untuk mendaftarkan Sumber Daya mereka sendiri ke dalam Program DR dan Infrastruktur Jaringan berinteraksi langsung dengan Sumber Daya melalui VEN yang berada di dalam Infrastruktur Sisi Permintaan. Selanjutnya VEN dimiliki oleh Resource Party dan terpisah dari Resources dan pengontrolnya. Ketika sinyal DR diterima oleh VEN, biasanya tidak menerapkan logika kontrol beban apa pun, tetapi hanya meneruskan sinyal ke pengontrol beban yang mengambil tindakan yang sesuai. Mantanample dari skenario ini akan mencakup bangunan K&I yang mungkin memasang gateway yang berisi OpenADR VEN dan ketika sinyal diterima oleh gateway itu, ia hanya menerjemahkannya ke beberapa protokol lain dan meneruskannya ke pengontrol beban itu sendiri.
Langsung 2
Ini sangat mirip dengan skenario Direct 1. Perbedaan utama adalah bagaimana VEN dipakai dan interaksi dengan VTN difasilitasi. VEN dipakai dalam entitas seperti BMS terpusat yang dapat mengimplementasikan logika DR dan berinteraksi dengan Sumber Daya Senyawa dan banyak pengontrol bebannya yang berbeda dari lokasi yang lebih terpusat. Mantanample termasuk bangunan besar dengan BMS yang mengontrol banyak beban yang berbeda dalam sebuah bangunan (misalnya pencahayaan, HVAC, proses industri, dll.) untuk camppenggunaan yang mungkin memiliki beberapa fasilitas dengan sistem kontrol terpusat.
Langsung 3
Skenario ini sangat mirip dengan skenario Direct 1. Perbedaan utama adalah bahwa VEN dipakai langsung di sumber daya dan pengontrol bebannya. Dalam hal ini sinyal DR dikirim langsung ke sumber daya dan pengontrol bebannya. Skenario yang disebut "harga untuk perangkat" termasuk dalam kategori ini. Mantanample akan mencakup pengontrol beban apa pun seperti HVAC (yaitu termostat) yang memiliki VEN tertanam yang mampu berinteraksi langsung dengan entitas sisi kisi VTN.
Langsung 4
Ini adalah kombinasi dari skenario Direct 1 dan Direct 2. Perbedaan utama adalah bahwa beberapa VEN dikaitkan dengan Sumber Daya Senyawa tunggal yang terdiri dari beberapa aset dengan pengontrol bebannya sendiri. Masing-masing pengontrol beban yang terdiri dari Sumber Daya Gabungan dapat dikaitkan dengan VEN yang berbeda. Perhatikan bahwa semua VEN akan berada di bawah kendali Pihak Sumber Daya yang sama yang memiliki Sumber Daya Gabungan. Skenario ini ada untuk memfasilitasi Infrastruktur Sisi Permintaan yang memiliki Sumber Daya Majemuk, tetapi tidak memiliki BMS terpusat seperti skenario Direct 2. Mantanample mungkin termasuk bangunan dengan pengontrol beban yang berbeda di setiap lantai, tetapi tidak ada BMS terpusat, atau campdigunakan dengan pengontrol yang berbeda di setiap gedung, tetapi tidak ada campkami pengontrol lebar. Karena dari sudut pandang DR Program Party hanya ada satu sumber daya yang terdaftar dalam program ketika ingin mengirim sinyal DR ke sumber daya, ia mungkin hanya mengirim sinyal yang sama ke masing-masing VEN yang ditunjuk yang telah dikaitkan dengan Sumber Daya.
Fasilitator 1
Dalam skenario ini ada perantara yang memfasilitasi interaksi antara Pihak Program DR dan Sumber Daya. Biasanya Pihak Perantara bekerja atas nama Pihak Sumber Daya untuk membantu mereka mengelola Sumber Daya mereka. Pihak Sumber Daya memiliki hubungan langsung dengan Pihak Program DR dan mereka mendaftarkan Sumber Daya mereka sendiri ke dalam Program DR. Demikian Partai Program DR views masing-masing Pihak Sumber Daya sebagai Sumber Daya yang terpisah dan dapat berinteraksi dengan mereka secara individual. Peran Pihak Perantara adalah untuk bertindak sebagai perantara untuk semua interaksi terkait OpenADR, sehingga VEN digunakan dalam Infrastruktur Perantara Fasilitator. Infrastruktur semacam itu seringkali berbasis cloud dan ditawarkan kepada Pihak Sumber Daya sebagai Perangkat Lunak sebagai Layanan (SaaS). Ketika sinyal DR diterima oleh VEN Fasilitator, sejumlah tindakan yang berbeda dapat dilakukan termasuk meneruskan sinyal DR ke Sumber Daya yang sesuai dan mungkin menerapkan semacam Logika DR dan mengirimkan perintah kontrol beban ke pengontrol beban masing-masing Sumber Daya. MantanampSkenario ini meliputi:
- Vendor yang mengelola fasilitas untuk rantai komersial besar seperti pengecer kotak besar.
- Perantara kontrol industri.
- Perusahaan Jasa Energi (ESCO's)
- Alat berbasis cloud dan sistem manajemen perangkat seperti vendor termostat komunikasi cerdas yang sedang berkembang.
Agregator 1
Skenario ini mirip dengan skenario Fasilitator. Perbedaan utama adalah bahwa Partai Agregator memiliki hubungan dengan Partai Program DR sebagai lawan dari Partai Sumber Daya. Agregator Party menggabungkan beberapa Aset pelanggan menjadi satu Sumber Daya yang didaftarkan ke Program DR. Pihak Program DR tidak memiliki visibilitas ke masing-masing Aset yang dikelola Agregator. Seperti Fasilitator, Agregator memiliki infrastruktur sendiri di mana VEN dibuat. Perbedaannya adalah bahwa ketika sinyal DR diterima, ia mereferensikan satu sumber daya dan Agregator menerapkan semacam logika DR pada semua Aset dalam portofolionya untuk mencapai tujuan yang ditentukan dalam sinyal DR.
Skenario Penerapan dan Pemetaan Program DR
Tabel di bawah ini memberikan skenario penerapan mana yang paling umum untuk Program DR tertentu.
| Skenario Penyebaran | |||
| Template DR | Langsung 1, 2, 3, 4 | Fasilitator 1 | Agregator 1 |
| Program CPP | ∆ | ∆ | |
| Program Penawaran Kapasitas | ∆ | ||
| Termostat Perumahan
Program |
∆ | ||
| Pengiriman DR Cepat | ∆ | ||
| Program Kendaraan Listrik (EV) DR | ∆ | ∆ | |
| Program DR Sumber Daya Energi yang Didistribusikan (DER) | ∆ | ∆ | |
Memilih Template Program DR
Berikut ini adalah sekumpulan pertanyaan yang relevan dengan utilitas apa pun yang akan mengimplementasikan program DR baru. Ini tidak dimaksudkan untuk menjadi komprehensif, tetapi mewakili beberapa masalah yang lebih relevan. Maksud dari pertanyaan-pertanyaan ini adalah untuk membantu memandu utilitas menuju satu set templat Program DR yang sesuai.
T: Mengapa Anda ingin melakukan DR? Kondisi jaringan atau masalah operasional apa yang Anda coba atasi dengan DR?
Sejauh ini, ini adalah pertanyaan yang paling penting dan menjadi dasar bagi persyaratan dan tujuan keseluruhan untuk apa yang seharusnya dicapai oleh program DR. Jawaban atas pertanyaan ini mendefinisikan bagaimana sisi permintaan memuat profile seharusnya dibentuk oleh program DR. Semua persyaratan lain mengalir dari jawaban atas pertanyaan ini.
- Apakah Anda mencoba mencukur puncak?
- Ingin mengisi perut bebek?
- Apakah Anda mencoba melindungi harga spot listrik?
- Apakah Anda peduli dengan keandalan jaringan?
- Apakah Anda mencoba untuk melestarikan aset jaringan?
- Dll dll dll.
Tabel di bawah ini memberikan beberapa konteks tambahan untuk motivasi di balik keinginan untuk mengembangkan Program DR
| Keandalan & Keamanan Grid | Frekuensi dan Voltage Stabilitas |
| Kecukupan Sumber Daya | |
| Kapasitas Puncak | |
| Rampsedang | |
| Kemungkinan | |
| Pengadaan Energi | Harga Pasar Spot |
| Harga Arbitrase | |
| Manajemen Aset | Pencegahan Kerusakan |
| Pengurangan Pemeliharaan | |
| Perpanjangan Seumur Hidup | |
| Manajemen Kapasitas | Manfaat Ekonomi |
| Manajemen Darurat | |
| Lingkungan Hidup | Negawatt |
| Energi Bersih |
T: Apakah sudah ada program atau tarif DR yang berlaku untuk program ini?
- Seringkali aturan program dijabarkan secara eksplisit dalam tarif.
T: Segmen pasar sisi permintaan apa yang Anda targetkan dengan program ini?
Ini dapat membantu menentukan penargetan sumber daya dalam acara dan jenis sinyal.
- Perumahan
- K&I Besar
- K&I Kecil
- Pertanian
- Pengelolaan air
- Kendaraan Listrik
- Dll, dll, dll
T: Apakah Anda mencoba menargetkan jenis muatan tertentu?
- Termostat
- Kendaraan listrik
- Pompa Ag
- dll.
T: Apa model penerapan Anda?
Jawaban atas pertanyaan ini dapat memengaruhi bagaimana sumber daya didefinisikan dalam program dan menentukan bagaimana sumber daya tersebut ditargetkan dalam acara.
- Langsung ke pelanggan
- Melalui perantara seperti agregator atau fasilitator
- Pelanggan bertanggung jawab untuk mendapatkan dan menggunakan peralatan VEN mereka sendiri?
- dll.
T: Pada tingkat kekhususan apa Anda ingin berinteraksi dengan beban sisi permintaan?
Pertanyaan ini agak terkait dengan model penyebaran dan menentukan bagaimana sumber daya dalam program didefinisikan dan ditargetkan. Ini adalah salah satu pertanyaan yang paling penting dan mungkin rumit.
- Berinteraksi dengan setiap sumber daya individu
- Berinteraksi melalui fasilitator atau agregator tanpa spesifikasi sumber daya di belakang mereka
- Berinteraksi melalui fasilitator atau agregator DAN tentukan sumber daya di belakang mereka yang harus dikirim
- Gunakan lokasi sebagai atribut untuk menentukan sumber daya
- Gunakan semacam mekanisme pengelompokan yang ditentukan utilitas untuk menentukan sumber daya
- Targetkan aset individu seperti termostat
- Berinteraksi tanpa sumber daya sama sekali dan hanya menyiarkan acara DR
- dll.
T: Pola interaksi apa yang ingin Anda terapkan untuk memengaruhi pelanggan Anda memuat profiles?
Pertanyaan ini menentukan jenis sinyal DR yang akan dikirim ke peserta dalam suatu program.
- Insentif (mis. Penetapan harga dinamis)
- Muat kiriman (mis. Layanan tambahan)
- Kontrol beban langsung
- Sinyal acara umum
- dll.
T: Apa atribut penjadwalan sumber daya umum dari program?
- Tanggal dan waktu acara dapat dipanggil
- Frekuensi acara
- Durasi acara
- Latensi yang diizinkan untuk penyebaran peristiwa
- dll.
T: Bagaimana ketersediaan sumber daya dalam program ditentukan?
- Dengan aturan program yang ketat
- Sebagai bagian dari beberapa proses nominasi atau penawaran yang dilakukan oleh sumber daya
- Menyisih / Keluar diizinkan?
- dll.
T: Jenis visibilitas apa yang Anda butuhkan tentang kinerja sumber daya?
Ini adalah pertanyaan yang sangat luas dan menentukan jenis informasi apa yang diumpankan kembali dari sumber daya dalam program DR. Secara umum ini menentukan jenis laporan yang dibutuhkan.
- Online / Offline
- Penggunaan (saat ini dan / atau historis)
- Muatkan potensi respons
- Ketersediaan beban
- Status beban / aset (saat ini dan / atau historis)
- Dll, dll. Dll.
Template Program Respon Permintaan
Program Penetapan Harga Puncak Kritis (CPP)
Karakteristik Program CPP DR
| Muat Profile Tujuan | -Pengurangan permintaan puncak |
| Driver Utama | -Mengurangi pengeluaran modal dan mengurangi biaya energi |
| Deskripsi Program | Ketika penyedia layanan mengamati atau mengantisipasi harga pasar grosir yang tinggi atau kondisi darurat sistem tenaga, mereka dapat memanggil peristiwa penting selama periode waktu tertentu (misalnya, 3 sore-6 sore pada hari kerja musim panas yang panas), harga listrik selama periode waktu ini secara substansial dibesarkan. |
| Insentif Pelanggan | Pelanggan dapat ditawari potongan harga energi selama waktu non-puncak sebagai insentif untuk berpartisipasi dalam program. |
| Tingkat Desain | CPP adalah program harga dengan kenaikan tarif selama puncak kritis dalam konsumsi energi. Biasanya tarif CPP adalah penambah atau pengganda untuk tarif dasar tetap, bertingkat, atau TOU. |
| Target Pelanggan | -Residensial atau K&I |
| Beban Target | -Apa saja |
| Prasyarat | -Pelanggan harus memiliki pengukuran interval
Pelanggan -C & I mungkin harus memenuhi kriteria permintaan |
| Jangka Waktu Program | -Biasanya berlangsung selama berbulan-bulan dalam setahun di mana konsumsi energi puncak terjadi, meskipun mungkin terjadi sepanjang tahun dalam beberapa kasus. |
| Kendala Acara | -Biasanya Senin sampai Jumat, kecuali hari libur, dengan acara hari berturut-turut biasanya diperbolehkan |
| Hari Acara | -Biasanya 9 sampai 15 per tahun |
| Durasi Acara | -Biasanya selama kerangka waktu tetap untuk semua acara mulai dari 4 hingga 6 jam selama waktu konsumsi energi tertinggi dalam sehari. |
| Pemberitahuan | -Biasanya hari depan |
| Perilaku Memilih | -Biasanya pelanggan tidak diharuskan untuk berpartisipasi dalam acara |
| Sertifikasi
Acara |
-Biasanya tidak ada |
Karakteristik OpenADR untuk Program CPP
| Sinyal Peristiwa | –Sinyal SEDERHANA dengan level 1 hingga 3 dipetakan ke dampak harga acara CPP. Jika program CPP memiliki komponen harga tunggal maka harus dipetakan ke level 1. Untuk program CPP dengan beberapa komponen harga, komponen harga terkecil harus dipetakan ke level 1, dengan komponen harga lainnya dipetakan ke level 2 dan 3 dalam derajat yang meningkat dampak harga.
-Jika penyebaran mendukung B profile VEN, selain sinyal SEDERHANA, sinyal ELECTRICITY_PRICE mungkin disertakan di payload dengan jenis priceRelative, priceAbsolute, atau priceMultiplier tergantung pada sifat program. Lihat Lampiran A untuk contohampsedikit. |
| Tanggapan Opt | Acara pengiriman -VTNs harus menyetel elemen oadrResponseRequired ke "selalu", memerlukan VEN untuk merespons dengan optIn atau optOut
-Karena partisipasi dalam program CPP adalah latihan "upaya terbaik", tidak ada arti formal untuk optIn atau optOut di luar indikasi kesediaan untuk berpartisipasi. Kami merekomendasikan itu VEN menanggapi dengan optIn kecuali ada beberapa tindakan penggantian tertentu yang diambil oleh pelanggan. -Mayload oadrCreateOpt biasanya tidak akan digunakan untuk memenuhi syarat sumber daya yang berpartisipasi dalam acara. |
| Deskriptor Acara | -Acara prioritas harus ditetapkan ke 1 kecuali aturan program atau konfigurasi VTN menentukan lain
–Acara uji biasanya tidak digunakan dengan program CPP. Namun, jika diizinkan, elemen testEvent harus disetel ke "true" untuk menunjukkan peristiwa pengujian. Jika informasi parameter tambahan diperlukan dalam elemen ini, ia dapat mengikuti "benar" yang dipisahkan oleh spasi dengan informasi tambahan ini. |
| Periode Aktif Acara | – eRampUp, eiRecovery, elemen toleransi biasanya tidak digunakan |
| Dasar | –Baseline biasanya tidak disertakan dalam event payload |
| Penargetan Acara | Program -CPP biasanya tidak membedakan sumber daya untuk pelanggan tertentu. Penargetan biasanya menentukan venID tersebut, menunjukkan bahwa semua sumber daya yang terkait dengan VEN harus berpartisipasi, atau daftar semua resourceID terkait dengan VEN. |
| Layanan Pelaporan | –Pelaporan telemetri biasanya tidak digunakan karena tidak mutlak diperlukan untuk program CPP.
Lihat Lampiran B untuk contohample laporan dari pilot utilitas yang mungkin berlaku untuk jenis program ini. |
| Layanan Opt | –Penggunaan layanan Opt untuk mengkomunikasikan jadwal ketersediaan sementara biasanya tidak akan digunakan sebagai bagian dari program CPP. Namun, beberapa penerapan dapat menggunakan layanan ini untuk mempertahankan hari acara yang tersedia bagi pelanggan yang menunjukkan kurangnya ketersediaan. |
| Layanan Pendaftaran | Interval polling diminta oleh VTN untuk program CPP sehari-hari biasa tidak perlu lebih sering dari satu jam sekali. Namun, penggunaan polling untuk deteksi detak jantung mungkin memerlukan polling yang lebih sering. |
Program Penawaran Kapasitas
Karakteristik Program DR
| Muat Profile Tujuan | - Pengurangan permintaan puncak dan kecukupan sumber daya |
| Driver Utama | -Mengurangi pengeluaran modal dan mengurangi biaya energi |
| Deskripsi Program | Program penawaran kapasitas digunakan oleh ISO / utilitas untuk mendapatkan kapasitas pelepasan muatan pra-komitmen dari agregator atau pelanggan agregat sendiri. Kapasitas gudang beban pra-komitmen ini digunakan oleh ISO / utilitas ketika mereka mengamati atau mengantisipasi harga pasar grosir yang tinggi, kondisi darurat sistem tenaga, atau sebagai bagian dari pemanfaatan sumber daya energi normal dengan memanggil kejadian DR selama jangka waktu tertentu.
Perhatikan bahwa setiap agregator biasanya bertanggung jawab untuk merancang program respons permintaan mereka sendiri serta akuisisi pelanggan, dan pemberitahuan acara untuk memenuhi komitmen kapasitas yang dibuat sebagai bagian dari program ini. |
| Insentif Pelanggan | Agregator / pelanggan menerima dua jenis insentif. Pertama, mereka menerima pembayaran kapasitas untuk menahan sejumlah kapasitas gudang muat tertentu yang tersedia untuk peristiwa DR selama jendela waktu mendatang. Kedua, jika suatu peristiwa dipanggil selama jendela waktu mendatang, pembayaran energi dapat dilakukan untuk pelepasan muatan selama durasi acara. |
| Tingkat Desain | Peserta dalam program ini membuat penawaran “nominasi kapasitas” yang menunjukkan kapasitas gudang muat yang bersedia mereka pertahankan jika tersedia selama jendela waktu mendatang. Tawaran juga dapat mencakup insentif yang bersedia diterima agregator / pelanggan untuk gudang muatan di bawah nilai dasar.
Di pasar utilitas, komitmen kapasitas biasanya untuk bulan kalender berikutnya, meskipun kerangka waktu yang lebih lama digunakan di pasar ISO. Sebagai bagian dari nominasi kapasitas, pelanggan mungkin dapat memilih di antara sejumlah karakteristik termasuk pemberitahuan sehari sebelumnya atau sehari dan jendela durasi acara (seperti 1-4 jam, 2-6 jam,…). Pembayaran kapasitas dilakukan kepada pelanggan untuk pra-komitmen ini meskipun tidak ada acara yang dipanggil selama jendela waktu. Jika suatu peristiwa dipanggil selama jangka waktu tersebut, pelanggan dapat menerima pembayaran energi untuk gudang muat sehubungan dengan garis dasar, namun penalti mungkin berlaku jika kurang dari kapasitas gudang muat pra-komitmen dikirimkan pada saat peristiwa tersebut dipanggil. |
| Target Pelanggan | -Agregator dan pelanggan K&I yang dikumpulkan sendiri |
| Beban Target | - Any |
| Prasyarat | -Pelanggan harus memiliki pengukuran interval
Pelanggan -C & I mungkin harus memenuhi kriteria permintaan atau penawaran |
| Jangka Waktu Program | -Kapan saja |
| Kendala Acara | -Biasanya Senin sampai Jumat, kecuali hari libur, dengan acara hari berturut-turut biasanya diperbolehkan |
| Hari Acara | -Biasanya maksimal 30 jam per bulan |
| Durasi Acara | -Biasanya selama jendela waktu tetap untuk semua peristiwa selama waktu konsumsi energi tertinggi hari itu.). Durasi acara bervariasi berdasarkan komitmen kapasitas pelanggan dengan preferensi mulai dari 1 hingga 8 jam atau sebagaimana ditentukan oleh desain program |
| Pemberitahuan | -Hari-hari atau hari-hari tergantung pada preferensi komitmen kapasitas pelanggan atau desain program |
| Perilaku Memilih | -Biasanya pelanggan akan ikut serta dalam acara karena mereka memiliki kapasitas pelepasan muatan yang telah ditetapkan sebelumnya. |
| Sertifikasi
Acara |
-Biasanya dua per tahun (Tes) |
Karakteristik OpenADR untuk Program Pelelangan Kapasitas
| Sinyal Peristiwa | –Sinyal SEDERHANA dengan level 1 hingga 3 dipetakan ke jumlah gudang beban. Jika program hanya mendukung satu level gudang beban, itu harus dipetakan ke level 1. Untuk program dengan beberapa level gudang beban, perubahan terkecil dari operasi normal harus dipetakan ke level 1, dengan nilai gudang beban dipetakan ke tingkat 2 dan 3 dalam meningkatkan derajat gudang beban.
-Jika penyebaran mendukung B profile VEN, selain sinyal SEDERHANA, sinyal BID_LOAD dan / atau BID_PRICE mungkin disertakan dalam muatan dengan jenis sinyal setpoint dan harga, dan unit powerReal dan currencyPerKW masing-masing. BID_LOAD akan mencerminkan jumlah muatan yang diminta hingga jumlah kapasitas yang ditawar oleh agregator / pelanggan, dan BID_PRICE akan mencerminkan tawaran insentif oleh agregator / pelanggan. Lihat Lampiran A untuk contohampsedikit. |
| Tanggapan Opt | Acara pengiriman -VTNs harus menyetel elemen oadrResponseRequired ke "selalu", memerlukan VEN untuk merespons dengan optIn atau optOut
-Sebagai agregator / pelanggan memiliki kapasitas pra-komitmen VEN harus merespons dengan optIn. Penyisihan dapat dikirim sebagai tanggapan atas acara tersebut, tetapi ini adalah indikasi ketersediaan informal, bukan penyisihan resmi dari acara tersebut. -Itu Payload oadrCreateOpt biasanya tidak akan digunakan untuk memenuhi syarat sumber daya yang berpartisipasi dalam acara karena biasanya bebannya adalah entitas gabungan tunggal. |
| Deskriptor Acara | -Acara prioritas harus ditetapkan ke 1 kecuali aturan program atau konfigurasi VTN menentukan lain
–Acara uji dapat digunakan dengan program Capacity Bidding. Jika diizinkan, elemen testEvent harus disetel ke "true" untuk menunjukkan peristiwa pengujian. Jika informasi parameter tambahan diperlukan dalam elemen ini, ia dapat mengikuti "benar" yang dipisahkan oleh spasi dengan informasi tambahan ini. |
| Periode Aktif Acara | – eRampUp, eiRecovery, elemen toleransi biasanya tidak digunakan |
| Dasar | –Baseline biasanya tidak disertakan dalam event payload karena data ini biasanya tidak tersedia pada saat acara dimulai. Namun, baik utilitas maupun agregator/pelanggan akan view dimasukkannya informasi dasar dalam acara-acara yang berguna. |
| Penargetan Acara | Program -Capacity Bidding biasanya tidak membedakan sumber daya untuk pelanggan tertentu. Penargetan biasanya menentukan venID tersebut, menunjukkan bahwa semua sumber daya yang terkait dengan VEN harus berpartisipasi, atau menyertakan perwakilan resourceID dari muatan gabungan terkait dengan VEN. |
| Layanan Pelaporan | Program ISO Capacity Bidding biasanya memerlukan laporan TELEMETRY_USAGE dengan titik data powerReal. Lihat mantanamples di Lampiran A.
Pelaporan telemetri untuk Penawaran Kapasitas utilitas biasanya tidak diperlukan. Perhatikan bahwa pelaporan telemetri memerlukan B profile VEN. Lihat Lampiran B untuk contohample laporan dari pilot utilitas yang mungkin berlaku untuk jenis program ini. |
| Layanan Opt | –Penggunaan layanan Opt untuk mengkomunikasikan jadwal ketersediaan sementara biasanya tidak akan digunakan sebagai bagian dari program Penawaran Kapasitas karena pelanggan telah berkomitmen sebelumnya untuk ketersediaan mereka. Namun, layanan ini mungkin berguna sebagai cara informal bagi peserta untuk menunjukkan kurangnya ketersediaan untuk alasan yang menjelaskan seperti kegagalan peralatan. |
| Layanan Pendaftaran | Interval polling diminta oleh VTN untuk program sehari-hari biasa tidak perlu lebih sering dari satu jam sekali. Namun, penggunaan polling untuk deteksi detak jantung atau program hari mungkin memerlukan polling yang lebih sering. |
Program Termostat Perumahan
Program ini merupakan perwakilan dari Direct Load Control (DLC) di mana sinyal Respon Permintaan secara langsung mengubah perilaku sumber daya pelepasan beban, tanpa lapisan abstraksi antara penerimaan sinyal dan tindakan pelepasan beban spesifik yang diambil.
Karakteristik Program Residential Thermostat DR
| Muat Profile Tujuan | -Pengurangan permintaan puncak |
| Driver Utama | -Mengurangi pengeluaran modal dan mengurangi biaya energi |
| Deskripsi Program | -Ketika utilitas mengamati atau mengantisipasi harga pasar grosir yang tinggi atau kondisi darurat sistem tenaga, mereka dapat memulai suatu peristiwa yang mengubah perilaku termostat komunikasi terprogram (PCT) pelanggan selama periode waktu tertentu (misalnya, jam 3 sore - 6 sore saat panas musim panas hari kerja) untuk mengurangi konsumsi energi.
-Perubahan perilaku PCT sebagai respons terhadap peristiwa tersebut dapat berupa perubahan sederhana dalam setpoint suhu selama durasi peristiwa atau serangkaian perubahan yang lebih kompleks, termasuk pendinginan awal, yang meminimalkan dampak peristiwa terhadap kenyamanan pelanggan. tingkat. |
| Insentif Pelanggan | -Incentives mengambil dua bentuk umum. Pertama, pelanggan dapat diberikan PCT gratis atau ditawarkan diskon / rabat untuk PCT yang dibeli pelanggan sebagai insentif untuk mendaftar dalam program DR. Kedua, pelanggan dapat menerima gaji tahunan yang berkelanjutan untuk melanjutkan pendaftaran dalam program ini. Yang kurang umum adalah insentif berkelanjutan yang dibayarkan kepada pelanggan berdasarkan pengurangan energi aktual selama acara. |
| Tingkat Desain | -Terutama program insentif, di mana pelanggan menerima PCT diskon atau gratis untuk mendaftar di program DR. Beberapa program mungkin membayar tunjangan berkala atau pembayaran insentif berdasarkan pengurangan energi selama acara.
|
| Target Pelanggan | -Rumah |
| Beban Target | -HVAC |
| Prasyarat | -Biasanya tidak ada, karena pelanggan menerima PCT sebagai bagian dari pendaftaran program
|
| Jangka Waktu Program | -Biasanya berlangsung selama berbulan-bulan dalam setahun di mana konsumsi energi puncak terjadi, meskipun mungkin terjadi sepanjang tahun dalam beberapa kasus. |
| Kendala Acara | -Biasanya Senin sampai Jumat, kecuali hari libur, dengan acara hari berturut-turut biasanya diperbolehkan. |
| Hari Acara | -Biasanya 9 sampai 15 per tahun |
| Durasi Acara | -Acara dapat terjadi kapan saja, dengan durasi mulai dari 2 hingga 4 jam, meskipun biasanya peristiwa terjadi selama waktu konsumsi energi tertinggi dalam sehari. |
| Pemberitahuan | -Biasanya sehari ke depan, meskipun beberapa program mungkin memiliki waktu notifikasi sesingkat 10 menit. |
| Perilaku Memilih | -Pelanggan tidak diharuskan untuk berpartisipasi dalam acara, namun mereka secara otomatis akan ikut serta dalam acara kecuali jika mereka mengambil tindakan untuk mengganti acara atau membuat penyesuaian manual terhadap suhu selama acara tersebut. |
| Sertifikasi
Acara |
-Biasanya tidak ada |
Karakteristik OpenADR untuk Program Termostat Hunian
| Sinyal Peristiwa | –Sinyal SEDERHANA dengan level 1 hingga 3 yang dipetakan ke perubahan offset setpoint suhu PCT atau persen siklus termostatiktagdan . Jika program termostat perumahan memiliki komponen offset / siklus tunggal, program tersebut harus dipetakan ke level 1. Untuk program dengan beberapa komponen offset / siklus, perubahan terkecil dari operasi normal harus dipetakan ke level 1, dengan nilai offset / siklus lainnya dipetakan ke tingkat 2 dan 3 dalam meningkatkan derajat dampak pelepasan muatan.
-Jika penyebaran mendukung B profile VEN, selain sinyal SEDERHANA, sinyal LOAD_CONTROL mungkin disertakan dalam muatan dengan tipe x-loadControlLevelOffset atau x-loadControlCapacity untuk menentukan offset setpoint suhu yang diinginkan atau persentase siklus termostatiktage masing-masing. Disarankan bahwa jenis unit "suhu" yang digunakan dalam payload yang memanfaatkan signalType x-loadControlLevelOffset untuk menunjukkan Celsius atau Fahrenheit untuk offset. Lihat Lampiran A untuk contohampsedikit. |
| Tanggapan Opt | Acara pengiriman -VTNs harus menyetel elemen oadrResponseRequired ke "selalu", memerlukan VEN untuk merespons dengan optIn atau optOut
– VEN Harus merespons dengan optIn kecuali ada beberapa tindakan penggantian tertentu yang diambil oleh pelanggan. -Itu Payload oadrCreateOpt dapat digunakan oleh VEN untuk memenuhi syarat partisipasi sumber daya dalam sebuah acara. Misalnya, suatu peristiwa mungkin menargetkan resourceID dari dua termostat yang mengontrol sistem HVAC yang terpisah. Jika pelanggan memutuskan bahwa hanya satu dari sistem HVAC yang dapat berpartisipasi dalam acara tersebut, ini akan dikomunikasikan ke VTN menggunakan muatan oadrCreateOpt. Perhatikan bahwa muatan oadrCreateOpt hanya didukung oleh B profile VEN |
| Deskriptor Acara | -Acara prioritas harus ditetapkan ke 1 kecuali aturan program atau konfigurasi VTN menentukan lain
–Acara uji biasanya tidak digunakan dengan program Residential Thermostat. Namun, jika diizinkan, elemen testEvent harus disetel ke "true" untuk menunjukkan peristiwa pengujian. Jika informasi parameter tambahan diperlukan dalam elemen ini, ia dapat mengikuti "benar" yang dipisahkan oleh spasi dengan informasi tambahan ini. |
| Periode Aktif Acara | –Pengacakan biasanya digunakan untuk acara termostat perumahan menggunakan elemen toleransi
– eRampElemen Up dan eiRecovery biasanya tidak digunakan |
| Dasar | –Baseline biasanya tidak disertakan dalam event payload |
| Penargetan Acara | Program Termostat Perumahan menargetkan sumber daya HVAC yang dikendalikan oleh PCT. Penargetan biasanya menentukan resourceID dari sistem HVAC (yaitu termostat) yang terkait dengan VEN atau venID dengan target kelas perangkat sinyal acara yang disetel ke Termostat |
| Layanan Pelaporan | –Pelaporan telemetri biasanya tidak digunakan karena tidak mutlak diperlukan untuk program termostat perumahan
Lihat Lampiran B untuk contohample laporan dari pilot utilitas yang mungkin berlaku untuk jenis program ini. |
| Layanan Opt | –Penggunaan layanan Opt untuk mengkomunikasikan jadwal ketersediaan sementara biasanya tidak akan digunakan sebagai bagian dari program CPP. |
| Layanan Pendaftaran | Interval polling diminta oleh VTN untuk program Residential Thermostat sehari-hari tidak perlu lebih sering dari satu jam sekali. Namun, penggunaan polling untuk deteksi detak jantung mungkin memerlukan polling yang lebih sering seperti halnya program termostat perumahan dengan waktu notifikasi yang jauh lebih singkat. |
Pengiriman DR Cepat
Karakteristik Program Pengiriman DR Cepat
| Muat Profile Tujuan | Sumber daya pengiriman untuk mencapai respons beban secara "real-time" |
| Driver Utama | Keandalan -Grid dan layanan tambahan |
| Deskripsi Program | Fast DR digunakan oleh ISO / utilitas untuk mendapatkan respon beban pra-komitmen secara "real-time". Respons beban pra-komitmen ini digunakan oleh ISO / utilitas ketika mereka mengamati kondisi yang memerlukan tindakan segera untuk menjaga stabilitas dan integritas grid. Waktu nyata berarti bahwa sumber daya biasanya dikirim dengan latensi mulai dari 10 menit untuk sumber daya yang digunakan sebagai cadangan hingga 2 detik untuk sumber daya yang digunakan untuk tujuan regulasi.
Ukuran respons beban harus cukup besar untuk membuat perbedaan dalam mengurangi kondisi jaringan dan dengan demikian sumber daya biasanya sangat besar dan sering kali dikelola oleh agregator sebagai bagian dari sumber daya gabungan. Ukuran minimum respons beban agar sumber daya memenuhi syarat untuk berpartisipasi dalam layanan tambahan biasanya sekitar 500 kW, tetapi bisa serendah 100 kW untuk beberapa program. Perhatikan bahwa jika sumber daya digunakan sebagai cadangan, biasanya akan diminta untuk mengurangi (yaitu melepaskan) beban, tetapi jika digunakan untuk tujuan regulasi, sumber daya tersebut dapat dikirim untuk menambah atau mengurangi beban. |
| Insentif Pelanggan | Agregator / pelanggan biasanya menerima dua jenis insentif. Pertama, mereka menerima pembayaran untuk melakukan dan menyediakan sejumlah respons pemuatan tertentu yang tersedia untuk peristiwa DR selama jendela waktu mendatang. Jumlah respons pemuatan, jangka waktu ketersediaan, dan jumlah yang harus dibayar biasanya ditetapkan oleh agregator / pelanggan. Kedua, jika suatu peristiwa dipanggil selama jendela waktu mendatang, pembayaran didasarkan pada jumlah respons pemuatan selama durasi acara. |
| Tingkat Desain | Peserta dalam program ini mengajukan tawaran yang menunjukkan respons beban yang bersedia mereka sediakan selama jendela waktu mendatang. Tawaran biasanya juga mencakup pembayaran yang bersedia diterima agregator / pelanggan untuk respons pemuatan.
Di pasar utilitas/ISO, tawaran biasanya diajukan sehari sebelumnya atau hari periode waktu di mana komitmen dibuat. Sebagai bagian dari kualifikasi dan pendaftaran mereka di pasar, berbagai parameter kinerja diselimuti dengan sumber daya seperti ramp kecepatan dan batas operasi min dan maks. Parameter tersebut mengatur bagaimana itu akan dikirim. Jika tawaran peserta diterima, pembayaran dapat dilakukan kepada pelanggan untuk pra-komitmen mereka bahkan jika tidak ada acara yang dipanggil selama jangka waktu tersebut. Jika suatu acara dipanggil selama jendela waktu, pelanggan dapat menerima pembayaran tambahan untuk kinerja mereka selama acara tersebut. Pembayaran berbasis kinerja tersebut mungkin didasarkan pada sejumlah faktor termasuk jumlah energi, daya, seberapa dekat sumber daya mengikuti instruksi pengiriman, dan pembayaran "jarak tempuh" yang mencerminkan seberapa besar beban mereka.file diminta untuk berubah selama acara. Beberapa parameter ini seperti energi dan daya mungkin berkaitan dengan garis dasar. |
| Target Pelanggan | -Pengatur dan pelanggan K&I yang dikumpulkan sendiri |
| Beban Target | - Mereka yang dapat menanggapi kiriman waktu nyata. |
| Prasyarat | -Pelanggan harus memiliki pengukuran interval
-Harus memenuhi persyaratan ukuran minimal untuk respons beban -Harus dapat menanggapi kiriman waktu nyata -Biasanya harus menyediakan telemetri real-time yang menunjukkan respons beban saat ini |
| Jangka Waktu Program | -Kapan saja |
| Kendala Acara | -tidak ada |
| Hari Acara | -tidak ada |
| Durasi Acara | -Biasanya pendek (kurang dari 30 menit), tetapi bagaimanapun juga tidak akan pernah melebihi jendela waktu peserta menyediakan sumber daya saat mereka mengajukan tawaran. |
| Pemberitahuan | -tidak ada |
| Perilaku Memilih | -Pelanggan diikutsertakan ke acara secara default karena mereka memiliki respons pemuatan yang telah ditetapkan sebelumnya |
| Sertifikasi
Acara |
-Biasanya satu per tahun (Tes) |
Karakteristik OpenADR untuk Program Pelelangan Kapasitas
| Sinyal Peristiwa | –Sinyal SEDERHANA dengan level 1 hingga 3 dipetakan ke jumlah respons beban. Jika program hanya mendukung satu tingkat respons beban, yang harus dipetakan ke tingkat 1. Untuk program dengan beberapa tingkat respons beban, perubahan terkecil dari operasi normal harus dipetakan ke tingkat 1, dengan nilai gudang beban dipetakan ke tingkat 2 dan 3 dalam meningkatkan derajat respons beban.
-Jika penyebaran mendukung B profile VEN, selain sinyal SEDERHANA, pengiriman dalam bentuk sinyal LOAD_DISPATCH dapat disertakan di payload dengan jenis sinyal setpoint atau delta, dan unit powerReal. Sinyal ini mewakili "titik operasi" yang diinginkan dari beban dan dapat dinyatakan baik sebagai jumlah absolut mW (yaitu setpoint) atau beberapa jumlah relatif mW (yaitu delta) dari titik operasi sumber daya saat ini. Lihat Lampiran A untuk contohampsedikit. |
| Tanggapan Opt | Acara pengiriman -VTNs harus menyetel elemen oadrResponseRequired ke "selalu", memerlukan VEN untuk merespons dengan optIn atau optOut
-Sebagai agregator / pelanggan memiliki kapasitas pra-komitmen VEN harus merespons dengan optIn. Penyisihan dapat dikirim sebagai tanggapan atas acara tersebut, tetapi ini adalah indikasi ketersediaan informal, bukan penyisihan resmi dari acara tersebut. -Itu Payload oadrCreateOpt biasanya tidak akan digunakan untuk memenuhi syarat sumber daya yang berpartisipasi dalam acara karena biasanya bebannya adalah entitas gabungan tunggal. |
| Deskriptor Acara | -Acara prioritas harus ditetapkan ke 1 kecuali aturan program atau konfigurasi VTN menentukan lain
–Acara uji dapat digunakan, terutama selama pendaftaran dan kualifikasi sumber daya. Jika diizinkan, elemen testEvent harus disetel ke "true" untuk menunjukkan peristiwa pengujian. Jika informasi parameter tambahan diperlukan dalam elemen ini, ia dapat mengikuti "benar" yang dipisahkan oleh spasi dengan informasi tambahan ini. |
| Periode Aktif Acara | – Elemen toleransi tidak digunakan. eiRampPeriode naik dan eiRecovery biasanya merupakan bagian dari parameter sumber daya saat mereka mendaftar dan dapat digunakan. Karena sifat pengiriman, mereka mungkin terbuka dan dengan demikian mungkin tidak ada waktu akhir untuk acara tersebut. |
| Dasar | –Baseline biasanya tidak disertakan dalam event payload karena data ini biasanya tidak tersedia pada saat acara dimulai. Namun, baik utilitas maupun agregator/pelanggan akan view dimasukkannya informasi dasar dalam acara-acara yang berguna. |
| Penargetan Acara | Program -Capacity Bidding biasanya tidak membedakan sumber daya untuk pelanggan tertentu. Penargetan biasanya menentukan venID tersebut, menunjukkan bahwa semua sumber daya yang terkait dengan VEN harus berpartisipasi, atau menyertakan perwakilan resourceID dari muatan gabungan terkait dengan VEN. |
| Layanan Pelaporan | Program DR cepat biasanya membutuhkan laporan TELEMETRY_USAGE dengan poin data powerReal. Laporan penggunaan menggambarkan titik operasi sumber daya saat ini dan digunakan oleh Utilitas / ISO untuk menentukan seberapa dekat sumber daya mengikuti instruksi pengiriman yang dikirim.
Dalam beberapa kasus telemetri dapat mencakup titik data lain seperti volumetage pembacaan dan status muatan (yaitu energi) dalam kasus di mana sumber daya adalah beberapa bentuk penyimpanan. Dalam beberapa kasus, frekuensi pelaporan mungkin setinggi setiap 2 detik. Perhatikan bahwa pelaporan telemetri memerlukan B profile VEN. Lihat Lampiran A untuk contohampsedikit. Lihat juga Lampiran B untuk contohample laporan dari pilot utilitas yang mungkin berlaku untuk jenis program ini. |
| Layanan Opt | –Penggunaan layanan Opt untuk mengomunikasikan ketersediaan sementara jadwal biasanya tidak akan digunakan karena pelanggan telah berkomitmen untuk ketersediaan mereka. Namun, layanan ini mungkin berguna sebagai cara informal bagi peserta untuk menunjukkan kurangnya ketersediaan untuk alasan yang menjelaskan seperti kegagalan peralatan. |
| Layanan Pendaftaran | Karena persyaratan latensi rendah dari pengiriman waktu nyata hanya pola interaksi dorong yang digunakan. |
Program Waktu Penggunaan (TOU) Kendaraan Listrik Perumahan (EV)
Karakteristik Program EV TOU Perumahan
| Muat Profile Tujuan | Struktur tarif yang mengubah biaya pengisian kendaraan listrik untuk menyebabkan konsumen mengubah pola konsumsi. |
| Driver Utama | Puncak penggunaan energi perumahan di malam hari. Karena pengisian daya EV membutuhkan 4-8 jam, ini dapat ditunda selama beberapa jam untuk memindahkan beban ke puncak. |
| Deskripsi Program | Pelanggan yang memiliki kendaraan listrik dapat mendaftar untuk tarif Waktu Penggunaan Kendaraan Listrik (EV-TOU) dan menerima tarif yang lebih rendah untuk mengisi daya kendaraan mereka selama jam-jam di luar jam sibuk, seperti antara tengah malam dan 5 pagi tarif EV-TOU adalah ditawarkan untuk mendorong pelanggan membatasi penggunaan listrik di siang hari, saat permintaan listrik paling tinggi. |
| Insentif Pelanggan | Pengisian daya yang lebih murah untuk EV. |
| Tingkat Desain | TOU dengan jam sibuk tengah hari, pagi dan sore hari jam sibuk, dan jam 12-5 di luar jam sibuk |
| Target Pelanggan | Pemilik EV dengan pro bebanfile yang memuncak pada malam hari. |
| Beban Target | Pengisi Daya EV |
| Prasyarat | Pelanggan harus memiliki smart meter dan EV |
| Jangka Waktu Program | Sepanjang tahun |
| Kendala Acara | Tidak ada |
| Hari Acara | Setiap hari, atau hanya hari kerja |
| Durasi Acara | 5-8 jam |
| Pemberitahuan | Pelanggan diberi tahu tentang tingkatan harga pada tagihan bulanan mereka, dan VTN mengirimkan sinyal acara sehari sebelumnya. |
| Perilaku Memilih | Ratepayers dapat mengubah skema harga mereka seperti yang biasanya mereka lakukan dengan utilitas. |
| Sertifikasi
Acara |
Karakteristik OpenADR untuk Program EV TOU Perumahan
| Sinyal Peristiwa | ELECTRICITY_PRICE sinyal dengan tingkatan harga sebenarnya, serta sinyal SEDERHANA untuk memungkinkan partisipasi dengan 2.0a VEN
Lihat Lampiran A untuk contohampsedikit. |
| Tanggapan Opt | Selalu ikut serta menurut VEN |
| Deskriptor Acara | Satu acara per minggu, dengan interval acara untuk setiap tingkatan harga |
| Periode Aktif Acara | Setidaknya 24 jam pemberitahuan harus digunakan. Setiap interval peristiwa harus menangkap tingkat tarif TOU |
| Dasar | Tidak tersedia |
| Penargetan Acara | Tidak diperlukan penargetan lanjutan, hanya penargetan tingkat VEN. |
| Layanan Pelaporan | Tidak perlu pelaporan, semua data dapat berasal dari meteran.
Lihat Lampiran B untuk contohample laporan dari pilot utilitas yang mungkin berlaku untuk jenis program ini. |
| Layanan Opt | Layanan opt tidak akan relevan dengan jenis program ini. |
| Layanan Pendaftaran | Konsumen akan menyediakan VEN mereka terlebih dahulu dengan utilitas untuk menerima sinyal harga. |
Program Penetapan Harga Real-Time Station Electric Vehicle (EV)
Karakteristik Program EV RTP Stasiun Umum
| Muat Profile Tujuan | Aktivitas respons permintaan di mana biaya pengisian kendaraan listrik dimodifikasi untuk menggeser realitas harga puncak ke konsumen. |
| Driver Utama | Harga listrik bervariasi selama sehari. Program ini bertujuan untuk menyesuaikan harga pembebanan dengan biaya listrik secara lebih efisien. |
| Deskripsi Program | Pengisi daya publik dapat tersedia di tempat kerja, di tempat parkir umum, dan di toko ritel. Program ini menyampaikan harga real-time ke pengisi daya potensial sebelum dicolokkan, sehingga mereka dapat membuat keputusan yang tepat tentang apakah akan menagih mobil mereka atau tidak. |
| Insentif Pelanggan | Pengisian lebih murah selama waktu tidak sibuk. |
| Tingkat Desain | Harga bisa berubah hourly, tetapi begitu pelanggan memilih untuk mencolokkan mobil mereka, tarif ditetapkan selama durasi pengisian. |
| Target Pelanggan | Siapapun dengan EV yang perlu mengisi daya saat jauh dari rumah. |
| Beban Target | EV Chargers Umum |
| Prasyarat | Pengisi daya EV harus terhubung ke internet dan bersertifikat OpenADR2.0b, atau terhubung ke gateway VEN OpenADR2.0b. |
| Jangka Waktu Program | Sepanjang tahun |
| Kendala Acara | Tidak ada |
| Hari Acara | Setiap hari, atau hanya hari kerja |
| Durasi Acara | 1 jam atau lebih |
| Pemberitahuan | Pelanggan diberitahu tentang tarif yang berlaku saat memilih untuk mencolokkan mobil mereka. |
| Perilaku Memilih | Pelanggan dapat memilih keluar dengan memutuskan untuk tidak mengenakan biaya. |
| Sertifikasi
Acara |
Karakteristik OpenADR untuk Program EV RTP Stasiun Umum
| Sinyal Peristiwa | ELECTRICITY_PRICE sinyal dengan harga.
Lihat Lampiran A untuk contohampsedikit. |
| Tanggapan Opt | Selalu ikut serta menurut VEN |
| Deskriptor Acara | Peristiwa harus berdekatan, dan berisi satu interval. |
| Periode Aktif Acara | Setidaknya pemberitahuan 1 jam harus digunakan, namun utilitas dapat memilih untuk menggunakan pemberitahuan sehari sebelumnya. |
| Dasar | Tidak tersedia |
| Penargetan Acara | Tidak diperlukan penargetan lanjutan, tetapi penargetan dapat digunakan untuk mengirim harga ke transformator, pengumpan, atau area geografis tertentu. |
| Layanan Pelaporan | Tidak perlu pelaporan, tetapi dapat digunakan jika diinginkan.
Lihat Lampiran B untuk contohample laporan dari pilot utilitas yang mungkin berlaku untuk jenis program ini. |
| Layanan Opt | Layanan opt tidak akan relevan dengan jenis program ini. |
| Layanan Pendaftaran | Vendor stasiun pengisian daya akan menyediakan perangkat mereka dengan VTN utilitas. |
Program DR Sumber Daya Energi yang Didistribusikan (DER)
Deskripsi program berikut bersifat hipotetis dan didasarkan pada makalah penelitian (referensi makalah Rish) yang menjelaskan bagaimana pelanggan utilitas dapat memanfaatkan sumber daya penyimpanan DER untuk berpartisipasi dalam program DR seperti program penetapan harga waktu nyata (RTP).
Karakteristik Program Sumber Daya Energi yang Didistribusikan (DER)
| Muat Profile Tujuan | Aktivitas respons permintaan yang digunakan untuk memperlancar integrasi sumber daya energi yang didistribusikan ke jaringan pintar. |
| Driver Utama | -Mengurangi pengeluaran modal dan mengurangi biaya energi |
| Deskripsi Program | Pelanggan dengan sumber daya DER yang dapat memanen energi dan menyimpannya dapat meminimalkan biaya pembelian listrik dari jaringan selama periode harga tinggi dengan terlebih dahulu memanfaatkan sumber daya energi yang tersimpan, diikuti dengan menerapkan strategi pelepasan muatan. |
| Insentif Pelanggan | Kemampuan untuk mengontrol biaya selama harga listrik tinggi dengan memanfaatkan energi tersimpan yang dihasilkan melalui PV atau cara lain dan menerapkan strategi pelepasan muatan |
| Tingkat Desain | Tarif listrik bervariasi menurut harga pasar grosir atau tarif yang bervariasi sesuai dengan fungsi waktu, musim, atau suhu |
| Target Pelanggan | Pelanggan dengan sumber daya penyimpanan energi |
| Beban Target | Setiap |
| Prasyarat | Sumber daya penyimpanan energi |
| Jangka Waktu Program | Kapan pun |
| Kendala Acara | Tidak ada |
| Hari Acara | Setiap hari |
| Durasi Acara | 24 jam |
| Pemberitahuan | Hari ke depan |
| Perilaku Memilih | T / A - Program upaya terbaik |
| Sertifikasi
Acara |
Tidak ada |
Karakteristik OpenADR untuk Sumber Daya Energi Terdistribusi (DER)
| Sinyal Peristiwa | Sinyal ELECTRICITY_PRICE dengan 24 interval harga satu jam selama periode 24 jam. Sinyal ini akan membutuhkan B profile. Program ini tidak cocok untuk pensinyalan SEDERHANA untuk A profile VEN.
Lihat Lampiran A untuk contohampsedikit. |
|
| Tanggapan Opt | Acara pengiriman -VTNs harus menyetel elemen oadrResponseRequired ke "tidak pernah", mencegah VEN merespons. | |
| Deskriptor Acara | -Acara prioritas harus ditetapkan ke 1 kecuali aturan program atau konfigurasi VTN menentukan lain | |
| Periode Aktif Acara | 24 jam dengan interval 1 jam dengan pemberitahuan sehari ke depan | |
| Dasar | Tidak tersedia | |
| Penargetan Acara | Tidak ada penargetan lanjutan yang diperlukan selain venID | |
| Layanan Pelaporan | Tidak perlu pelaporan
Lihat Lampiran B untuk contohample laporan dari pilot utilitas yang mungkin berlaku untuk jenis program ini. |
|
| Layanan Opt | Tidak digunakan | |
| Layanan Pendaftaran | Interval polling diminta oleh VTN untuk program t sehari-hari biasa tidak perlu lebih sering dari satu jam sekali. Namun, penggunaan polling untuk deteksi detak jantung mungkin memerlukan polling yang lebih sering seperti halnya program termostat perumahan dengan waktu notifikasi yang jauh lebih singkat. |
- Sample Template Data dan Payload
Tabel berikut dan payload XML samples akan memberikan para pelaksana dengan pengalaman nyataample tentang bagaimana template DR dalam dokumen ini harus diterapkan. Awalan namespace berikut digunakan dalam payload exampsedikit:
- xmlns: oadr = ”http://openadr.org/oadr-2.0b/2012/07 ″
- xmlns: pyld = ”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
- xmlns: ei = ”http://docs.oasis-open.org/ns/energyinterop/201110 ″
- xmlns: scale = ”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
- xmlns: emix = ”http://docs.oasis-open.org/ns/emix/2011/06 ″
- xmlns: strm = ”urn: ietf: params: xml: ns: icalendar-2.0: stream”
- xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0 ″
- xmlns: power = ”http://docs.oasis-open.org/ns/emix/2011/06/power”
Program Penetapan Harga Puncak Kritis (CPP)
Skenario CPP 1 – Kasus Penggunaan Sederhana, A atau B Profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 1 siang
- Durasi: 4 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 1
- Nama Sinyal: SEDERHANA
- Jenis Sinyal: level
- Unit: N / A
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 1
- Target Sinyal: N / A
- Target Peristiwa: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Skenario CPP 2 – Kasus Penggunaan Khas, B profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 1 siang
- Durasi: 4 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 2
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0, 1, 2, 3
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 1 atau 2
- Target Sinyal: Tidak ada
- Nama Sinyal: ELECTRICITY_PRICE
- Jenis Sinyal: harga
- Unit: USD per Kwh
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: $ 0.10 hingga $ 1.00
- Target Sinyal: Tidak ada
- Target Acara: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Skenario CPP 3 - Kasus Penggunaan Kompleks
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 2 siang
- Durasi: 6 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 2
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0,1, 2, 3)
- Jumlah interval 3
- Durasi Interval: 1 jam, 4 jam, 1 jam
- Nilai Interval Khas: 1, 2, 1 (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Nama Sinyal: ELECTRICITY_PRICE
- Jenis Sinyal: harga
- Unit: USD per Kwh
- Jumlah interval 3
- Durasi Interval: 1 jam, 4 jam, 1 jam
- Nilai Interval Khas: $ 0.50, $ 0.75, $ 0.50 (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Target Peristiwa: Resource_1, Resource_2, Resource_3
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
CPP Sample Muatan Acara – Khas B Profile Kasus Penggunaan
OadrDisReq091214_043740_513
TH_VTN
Peristiwa091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
jauh
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
SEDERHANA
tingkat
SIG_01
0.0
PT4H
0
0.75
ELECTRICITY_PRICE
harga
SIG_02
currencyPerKWh
USD
tidak ada
0.0
venID_1234
selalu
Program Penawaran Kapasitas (CBP)
Skenario CBP 1 – Kasus Penggunaan Sederhana, A atau B Profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 1 siang
- Durasi: 4 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 1
- Nama Sinyal: SEDERHANA
- Jenis Sinyal: level
- Unit: N / A
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 1
- Target Sinyal: N / A
- Target Peristiwa: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Skenario CBP 2 – Kasus Penggunaan Khas, B profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 1 siang
- Durasi: 4 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 2
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0,1, 2, 3
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 1 atau 2
- Target Sinyal: Tidak ada
- Nama Sinyal: BID_LOAD
- Jenis Sinyal: setpoint
- Unit: powerReal
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 20kW hingga 100kW
- Target Sinyal: Tidak ada
- Target Acara: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Skenario CBP 3 - Kasus Penggunaan Kompleks
- Peristiwa
- Pemberitahuan: Hari acara (berapa jam?)
- Waktu Mulai: 1 siang
- Durasi: 6 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 3
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0,1, 2, 3)
- Jumlah interval: 2
- Durasi Interval: 3 jam, 3 jam
- Nilai Interval Khas: 1, 2 (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Nama Sinyal: BID_LOAD
- Jenis Sinyal: setpoint
- Unit: powerReal
- Jumlah interval 2
- Durasi Interval: 3 jam, 3 jam
- Nilai Interval Khas: 40kW, 80kW (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Nama Sinyal: BID_PRICE
- Jenis Sinyal: harga
- Unit: currencyPerKW
- Jumlah interval 1
- Durasi Interval: 6 jam
- Nilai Interval Khas: $ 3.10
- Target Sinyal: Tidak ada
- Target Peristiwa: Resource_1, Resource_2, Resource_3
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Nama Laporan: TELEMETRY_USAGE
- Jenis Laporan: penggunaan
- Unit: powerReal
- Jenis Bacaan: Baca Langsung
- Frekuensi Laporan: setiap 1 jam
CBP Sample Muatan Acara – Khas B Profile Kasus Penggunaan
OadrDisReq091214_043740_513
TH_VTN
Peristiwa091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
jauh
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
SEDERHANA
tingkat
SIG_01
0.0
PT4H
0
80.0
BID_LOAD
set point
SIG_02
RealPower
W
k
60.0
<kekuatan: jilidtage>220.0tage>
benar
0.0
venID_1234
selalu
Skenario Termostat Perumahan 1 – Kasus Penggunaan Sederhana, A atau B Profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 1 siang
- Durasi: 4 jam
- Pengacakan: 10 menit
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 1
- Nama Sinyal: SEDERHANA
- Jenis Sinyal: level
- Unit: N / A
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 1
- Target Sinyal: N / A
- Target Peristiwa: Sumber daya_1
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Skenario Termostat Perumahan 2 – Kasus Penggunaan Umum, B profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 1 siang
- Durasi: 4 jam
- Pengacakan: 10 menit
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 2
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0,1, 2, 3
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 1 atau 2
- Target Sinyal: Tidak ada
- Nama Sinyal: LOAD_CONTROL
- Jenis Sinyal: x-loadControlLevelOffset
- Unit: Suhu
- Jumlah interval 1
- Durasi Interval: 4 jam
- Nilai Interval Khas: 2 hingga 6 derajat Fahrenheit
- Target Sinyal: Tidak ada
- Target Peristiwa: Sumber Daya_1, Sumber Daya_2
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Respon yang Diharapkan: optIn, Kemungkinan outOut (oadrCreateOpt)
- Laporan
- Tidak ada
Skenario Termostat Perumahan 3 - Kasus Penggunaan Kompleks
- Peristiwa
- Pemberitahuan: Hari acara
- Waktu Mulai: 1 siang
- Durasi: 6 jam
- Pengacakan: 10 menit
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 3
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0,1, 2, 3)
- Jumlah interval: 2
- Durasi Interval: 3 jam, 3 jam
- Nilai Interval Khas: 1, 2 (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Nama Sinyal: BID_LOAD
- Jenis Sinyal: x-loadControlCapacity
- Unit: Tidak ada
- Jumlah interval 2
- Durasi Interval: 3 jam, 3 jam
- Nilai Interval Khas: 0.9, 0.8 (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Target Peristiwa: Resource_1, Resource_2, Resource_3
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Respon yang Diharapkan: optIn, Kemungkinan outOut (oadrCreateOpt)
- Laporan
- Tidak ada
Termostat Perumahan Sample Muatan Acara – Khas B Profile Kasus Penggunaan
OadrDisReq091214_043740_513
TH_VTN
Peristiwa091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
jauh
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT10M
PT24H
PT4H
0
2.0
SEDERHANA
tingkat
SIG_01
0.0
PT4H
0
6.0
LOAD_CONTROL
x-loadControlLevelOffset
SIG_02
suhu
fahrenheit.dll
tidak ada
0.0
resource_1
resource_2
selalu
Skenario DR Cepat 1 – Kasus Penggunaan Sederhana, A atau B Profile
- Peristiwa
- Pemberitahuan: 10 menit
- Waktu Mulai: 1 siang
- Durasi: 0 (Terbuka Berakhir)
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 1
- Nama Sinyal: SEDERHANA
- Jenis Sinyal: level
- Unit: N / A
- Jumlah interval 1
- Durasi Interval: 0 (Terbuka Berakhir)
- Nilai Interval Khas: 1
- Target Sinyal: N / A
- Target Peristiwa: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Skenario DR Cepat 2 – Kasus Penggunaan Umum, B profile
- Peristiwa
- Pemberitahuan: 10 menit
- Waktu Mulai: 1 siang
- Durasi: 30 menit
- Pengacakan: Tidak ada
- Ramp Naik: 5 menit
- Pemulihan: 5 menit
- Jumlah sinyal: 2
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0,1, 2, 3
- Jumlah interval 1
- Durasi Interval: 30 menit
- Nilai Interval Khas: 1 atau 2
- Target Sinyal: Tidak ada
- Nama Sinyal: LOAD_DISPATCH
- Jenis Sinyal: delta
- Unit: powerReal
- Jumlah interval 1
- Durasi Interval: 30 menit
- Nilai Interval Khas: 500 kW hingga 2mW
- Target Sinyal: Tidak ada
- Target Acara: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Nama Laporan: TELEMETRY_USAGE
- Jenis Laporan: penggunaan
- Unit: powerReal
- Jenis Bacaan: Baca Langsung
- Frekuensi Laporan: setiap 1 menit
Skenario DR Cepat 3 - Kasus Penggunaan Kompleks
- Peristiwa
- Pemberitahuan: 10 menit
- Waktu Mulai: 1 siang
- Durasi: 30 menit
- Pengacakan: Tidak ada
- Ramp Naik: 5 menit
- Pemulihan: 5 menit
- Jumlah sinyal: 2
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0,1, 2, 3)
- Jumlah interval: 2
- Durasi Interval: 15 menit, 15 menit
- Nilai Interval Khas: 1, 2 (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Nama Sinyal: LOAD_DISPATCH
- Jenis Sinyal: setpoint
- Unit: powerReal
- Jumlah interval 2
- Durasi Interval: 15 menit, 15 menit
- Nilai Interval Khas: 800kW, 900kW (untuk setiap interval masing-masing)
- Target Sinyal: Tidak ada
- Target Peristiwa: Resource_1
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Nama Laporan: TELEMETRY_USAGE
- Jenis Laporan: penggunaan
- Satuan: powerReal dan voltage
- Jenis Bacaan: Baca Langsung
- Frekuensi Laporan: setiap 5 detik
DR S cepatample Muatan Acara – Khas B Profile Kasus Penggunaan
OadrDisReq091214_043740_513
TH_VTN
Peristiwa091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
jauh
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT10M
PT10M
<ei:x-eiRampNaik>
PT5M
</ei:x-eiRampNaik>
PT5M
PT10M
0
2.0
SEDERHANA
tingkat
SIG_01
0.0
PT10M
0
500.0
LOAD_DISPATCH
delta
SIG_02
RealPower
W
k
60.0
<kekuatan: jilidtage>220.0tage>
benar
0.0
venID_1234
selalu
DR S cepatample Laporkan Muatan Metadata – Tipikal B Profile Kasus Penggunaan
RegReq120615_122508_975
PT10M
rID120615_122512_981_0
resource1
pemakaian
RealEnergy
Wh
k
Baca Langsung
http: // MarketContext1
<oadr:oadrSamplingRate>
PT1M
PT10M
Salah
</loadr:loadrSamplingRate>
0
ReportSpecID120615_122512_481_2
METADATA_TELEMETRY_USAGE
<ei:createdDateTime>2015-06-12T19:25:12Z</ei:createdDateTime>
ec27de207837e1048fd3
DR S cepatample Laporan Permintaan Payload – Tipikal B Profile Kasus Penggunaan
ReportReqID130615_192625_230
ReportReqID130615_192625_730
ReportSpecID120615_122512_481_2
PT1M
PT1M
<xcal:date-time>2015-06-14T13:00:00Z</xcal:date-time>
PT10M
rID120615_122512_981_0
x-notApplicable
VEN130615_192312_582
DR S cepatample Laporkan Muatan Data – Tipikal B Profile Kasus Penggunaan
ReportUpdReqID130615_192730_445
<xcal:date-time>2015-06-14T02:27:29Z</xcal:date-time>
<xcal:date-time>2015-06-14T02:27:29Z</xcal:date-time>
rID120615_122512_981_0
100
0.0
500.0
Kualitas Baik - Tidak Spesifik
RP_54321
ReportReqID130615_192625_730
ReportSpecID120615_122512_481_2
TELEMETRY_USAGE
<ei:createdDateTime>2015-06-14T02:27:29Z</ei:createdDateTime>
VEN130615_192312_582
Program Waktu Penggunaan (TOU) Kendaraan Listrik Perumahan (EV)
Perhatikan bahwa saat program mengkomunikasikan tingkatan tarif dalam bentuk yang cukup terstruktur, hanya kasus penggunaan sederhana dan umum yang ditampilkan
Skenario EV Perumahan 1 – Kasus Penggunaan Sederhana, A atau B Profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: 1 siang
- Durasi: 24 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 1
- Nama Sinyal: SEDERHANA
- Jenis Sinyal: level
- Unit: N / A
- Jumlah interval; Perubahan Tingkat TOU yang sama dalam 24 jam (2-6)
- Durasi Interval: kerangka waktu aktif tingkat TOU (yaitu 6 jam)
- Nilai Interval Khas: 0 - 4 dipetakan ke Tingkat TOU
- Target Sinyal: N / A
- Target Peristiwa: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Skenario EV Perumahan 2 – Kasus Penggunaan Umum, B profile
- Peristiwa
- Pemberitahuan: Sehari sebelum acara
- Waktu Mulai: tengah malam
- Durasi: 24 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 2
- Nama Sinyal: Sederhana
- Jenis Sinyal: level
- Unit: Level 0, 1, 2, 3
- Jumlah interval: perubahan Tingkat TOU yang sama dalam 24 jam (2-6)
- Durasi Interval: kerangka waktu aktif tingkat TOU (yaitu 6 jam)
- Nilai Interval Khas: 0 - 4 dipetakan ke Tingkat TOU (0 - Tingkat Termurah)
- Target Sinyal: Tidak ada
- Nama Sinyal: ELECTRICITY_PRICE
- Jenis Sinyal: harga
- Unit: USD per Kwh
- Jumlah interval: Perubahan Tingkat TOU yang sama dalam 24 jam (2-6)
- Durasi Interval: kerangka waktu aktif tingkat TOU (yaitu 6 jam)
- Nilai Interval Khas: $ 0.10 hingga $ 1.00 (tarif tingkat saat ini)
- Target Sinyal: Tidak ada
- Target Acara: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
EV S perumahanample Muatan Acara – Khas B Profile Kasus Penggunaan
OadrDisReq091214_043740_513
TH_VTN
Peristiwa091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
jauh
<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
SEDERHANA
tingkat
SIG_01
0.0
PT5H
0
0.35
PT7H
1
0.55
PT7H
2
0.75
PT5H
3
0.55
ELECTRICITY_PRICE
harga
SIG_02
currencyPerKWh
USD
tidak ada
0.0
venID_1234
selalu
Program Penetapan Harga Real-Time Station Electric Vehicle (EV)
Perhatikan bahwa karena ini adalah program penetapan harga waktu nyata, tidak ada perbedaan antara kasus penggunaan yang sederhana, tipikal, dan kompleks. Oleh karena itu sample data hanya akan ditampilkan untuk kasus penggunaan biasa.
Stasiun Umum EV Skenario 1 – Kasus Penggunaan Umum, B profile
- Peristiwa
- Notifikasi: 1 jam lebih awal
- Waktu Mulai: 1 siang
- Durasi: 1 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 1
- Nama Sinyal: ELECTRICITY_PRICE
- Jenis Sinyal: harga
- Unit: USD per Kwh
- Jumlah interval 1
- Durasi Interval: 1 jam
- Nilai Interval Khas: $ 0.10 hingga $ 1.00
- Target Sinyal: Tidak ada
- Target Acara: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: selalu
- VEN Tanggapan yang Diharapkan: optIn
- Laporan
- Tidak ada
Stasiun Umum EV Sample Muatan Acara – Khas B Profile Kasus Penggunaan
OadrDisReq091214_043740_513
TH_VTN
Peristiwa091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
jauh
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT1H
PT1H
PT1H
0
0.75
ELECTRICITY_PRICE
harga
SIG_01
currencyPerKWh
USD
tidak ada
0.0
venID_1234
selalu
Program DR Sumber Daya Energi yang Didistribusikan (DER)
Perhatikan bahwa karena ini adalah program penetapan harga waktu nyata, tidak ada perbedaan antara kasus penggunaan yang sederhana, tipikal, dan kompleks. Oleh karena itu sample data hanya akan ditampilkan untuk kasus penggunaan biasa.
Stasiun Umum EV Skenario 1 – Kasus Penggunaan Umum, B profile
- Peristiwa
- Pemberitahuan: Hari depan
- Waktu Mulai: tengah malam
- Durasi: 24 jam
- Pengacakan: Tidak ada
- Ramp Atas: Tidak ada
- Pemulihan: Tidak ada
- Jumlah sinyal: 24
- Nama Sinyal: ELECTRICITY_PRICE
- Jenis Sinyal: harga
- Unit: USD per Kwh
- Jumlah interval 1
- Durasi Interval: 1 jam
- Nilai Interval Khas: $ 0.10 hingga $ 1.00
- Target Sinyal: Tidak ada
- Target Acara: venID_1234
- Prioritas: 1
- VEN Respon Diperlukan: tidak pernah
- VEN Tanggapan yang Diharapkan: n / a
- Laporan
- Tidak ada
Stasiun Umum EV Sample Muatan Acara – Khas B Profile Kasus Penggunaan
OadrDisReq091214_043740_513
TH_VTN
Peristiwa091214_043741_028_0
0
http: // MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
jauh
<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>
PT24H
PT24H
PT1H
0
0.75
PT1H
1
0.80
ELECTRICITY_PRICE
harga
SIG_01
currencyPerKWh
USD
tidak ada
0.0
venID_1234
tidak pernah
- Mantanample Laporan Dari Pilot Utilitas
Anggota OpenADR Alliance menyediakan B Pro berikut ini:file muatan oadrUpdateReport sampfile dari program percontohan utilitas di mana VEN mereka telah dikerahkan. Catatan berikut menyertai tiga muatan samples yang disediakan:
Tujuan Muatan Termostat:
- Perlu mengetahui status termostat (suhu, titik setel, kipas dan mode negara)
- Jika ikut serta, apakah pelanggan mengubah pengaturan termostat atau tidak (pesan timpa manual)
M&V untuk Tujuan Muatan Rabat:
- Status sumber daya dan penggantian manual dalam kasus keikutsertaan
- Data interval dari KYZ Pulse Counter atau Energy Monitor untuk energi total dalam KWH dan permintaan sesaat dalam KW
Smart Meter / AMI Interval Data Payload Tujuan:
- Interval pembacaan AMI meter sekitar 15 menit hingga 1 jam. Meskipun berguna, tidak cukup terperinci untuk perkiraan penagihan yang mendekati waktu nyata
- Energi Total dalam KWH, energi delta dalam KWH, permintaan sesaat dalam KW
Awalan namespace berikut digunakan dalam payload exampsedikit:
- xmlns: oadr = ”http://openadr.org/oadr-2.0b/2012/07 ″
- xmlns: pyld = ”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
- xmlns: ei = ”http://docs.oasis-open.org/ns/energyinterop/201110 ″
- xmlns: scale = ”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
- xmlns: emix = ”http://docs.oasis-open.org/ns/emix/2011/06 ″
- xmlns: strm = ”urn: ietf: params: xml: ns: icalendar-2.0: stream”
- xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0 ″
- xmlns: power = ”http://docs.oasis-open.org/ns/emix/2011/06/power”
Laporan Termostat 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
benar
Salah
0
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Temp saat ini
77.000000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Pengaturan Suhu Panas
64.000000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Pengaturan Suhu Dingin
86.000000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Pengaturan Mode HVAC
3
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Mode HVAC Saat Ini
0.000000
No Quality - No Value
Pengaturan Mode Kipas
2
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Mode Tahan Saat Ini
2
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Mode Jauh Saat Ini
0
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
Kelembaban Saat Ini
0.000000
No Quality - No Value
RP21
REQ: RReq: 1395368583267
0013A20040980FAE
TELEMETRY_STATUS
<ei:createdDateTime>2014-03-21T02:26:04Z</ei:createdDateTime>
VEN.ID:1395090780716
Muatan Laporan M&V untuk Rabatample
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
benar
Salah
Kualitas Baik - Tidak Spesifik
Hitungan Pulsa
34750.000000
Kualitas Baik - Tidak Spesifik
Energi
33985.500000
Kualitas Baik - Tidak Spesifik
Kekuasaan
1.26
Kualitas Baik - Tidak Spesifik
RP15
REQ: RReq: 10453335019195698
0000000000522613 60
TELEMETRY_USAGE
<ei:createdDateTime>2015-08-21T17:41:50Z</ei:createdDateTime>
VEN.ID:1439831430142
Laporan Data Interval Pengukur Cerdas/AMI 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
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
intervalDataDelivered
0.051000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
currentSumDelivered
12172.052000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
<xcal:date-time>2014-09-10T06:27:07Z</xcal:date-time>
PT15S
instantaneousDemand
6.114000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
intervalDataDelivered
0.051000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
currentSumDelivered
12172.052000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
<xcal:date-time>2014-09-10T06:27:22Z</xcal:date-time>
PT15S
instantaneousDemand
6.113000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
intervalDataDelivered
0.051000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
currentSumDelivered
12172.142000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
<xcal:date-time>2014-09-10T06:27:37Z</xcal:date-time>
PT15S
instantaneousDemand
6.112000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
intervalDataDelivered
0.051000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
currentSumDelivered
12172.142000
Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan
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>
Open ADR mendukung layanan berikut:
- Layanan EiEvent – Digunakan oleh VTN untuk mengirim acara respons permintaan ke VEN, dan digunakan oleh VEN untuk menunjukkan apakah sumber daya akan berpartisipasi dalam acara tersebut. Satu-satunya layanan yang didukung oleh A profile adalah EiEvent
- Layanan EiReport - Digunakan oleh VEN dan VTN untuk bertukar laporan historis, telemetri, dan prakiraan
- Layanan EiOpt - Digunakan oleh VEN untuk mengkomunikasikan jadwal ketersediaan sementara ke VTN atau untuk memenuhi syarat sumber daya yang berpartisipasi dalam sebuah acara
- Layanan EiRegisterParty - Dimulai oleh VEN, dan digunakan oleh VEN dan VTN untuk bertukar informasi yang diperlukan untuk memastikan pertukaran muatan yang dapat dioperasikan
- Layanan OadrPoll - Digunakan oleh VEN untuk mengumpulkan VTN untuk payload dari salah satu layanan lainnya
A dan B profile operasi layanan ditentukan oleh elemen root dari setiap payload, tidak termasuk pembungkus oadrPayload dan oadrSignedObject yang digunakan pada semua B profile muatan.
- oadrRequestEvent – Digunakan dalam model pertukaran tarik oleh VEN untuk mengambil semua peristiwa yang relevan dari VTN. Digunakan sebagai mekanisme polling utama untuk A profile VEN, tetapi hanya digunakan pada B VEN untuk sinkronisasi dengan VTN.
- oadrDistributeEvent - Digunakan oleh VTN untuk mengirimkan acara respons permintaan ke VEN
- oadrDibuatAcara - Digunakan oleh VEN untuk mengkomunikasikan apakah itu bermaksud untuk berpartisipasi dalam sebuah acara dengan memilih ikut atau tidak
- oadrRespons - Digunakan oleh VTN untuk mengakui penerimaan optIn atau optOut dari VEN
Perhatikan bahwa baik VEN maupun VTN mampu menjadi pembuat laporan dan pemohon laporan, sehingga semua muatan di bawah ini dapat dimulai oleh salah satu pihak.
- oadrRegisterReport - Digunakan untuk mempublikasikan kemampuan pelaporan mereka dalam laporan metadata
- Laporan Terdaftar oadr -Mengakui penerimaan oadrRegisterReport, secara opsional meminta salah satu laporan yang ditawarkan
- oadrBuatLaporan - Digunakan untuk meminta laporan yang sebelumnya telah ditawarkan oleh VEN atau VTN
- oadrBuatLaporan - Akui penerimaan permintaan laporan
- oadrUpdateLaporan -Memberikan laporan yang diminta berisi data interval
- oadrUpdatedReport - Mengakui penerimaan laporan yang dikirim
- oadrBatalkanLaporan - Membatalkan laporan berkala yang diminta sebelumnya
- oadrDibatalkanLaporan - Akui pembatalan laporan berkala
- oadrRespons - Digunakan sebagai respons placeholder dalam beberapa pola pertukaran tarik ketika respons lapisan aplikasi dikirimkan dalam permintaan lapisan transport.
- oadrCreateOpt - Digunakan untuk dua tujuan yang sangat berbeda
- Agar VEN mengkomunikasikan jadwal ketersediaan sementara ke VTN sehubungan dengan kemampuannya untuk berpartisipasi dalam acara DR
- Agar VEN memenuhi syarat sumber daya yang berpartisipasi dalam suatu acara
- oadrDibuatOpt - Akui penerimaan payload oadrCreateOpt
- oadrBatalOpt -Batal jadwal ketersediaan sementara
- oadrDibatalkanOpt - Akui pembatalan laporan ketersediaan sementara
- odrQueryRegistration - Sebuah cara bagi VEN untuk menanyakan informasi pendaftaran VTN tanpa benar-benar mendaftar.
- oadrCreatePartyRegistration - Permintaan dari VEN ke VTN untuk mendaftar. Berisi informasi tentang kapabilitas VEN.
- oadrCreatedPartyRegistration - Tanggapan untuk oadrQueryRegistration atau oadrCreatePartyRegistration. Berisi kapabilitas VTN dan informasi registrasi yang diperlukan agar VEN dapat beroperasi
- oadrBatalkan Pendaftaran Pesta - Digunakan oleh VEN atau VTN untuk membatalkan pendaftaran
- oadrCanceledPartyRegistrasi - Membalas ke oadrCancelPartyRegistration. Mengakui telah menerima pembatalan pendaftaran
- oadrRequestReregistrasi - Muatan ini digunakan oleh VTN dalam model pertukaran tarik untuk memberi sinyal VEN untuk memulai kembali urutan pendaftaran
- oadrRespons - Digunakan sebagai respons placeholder dalam beberapa pola pertukaran tarik ketika respons lapisan aplikasi dikirimkan dalam permintaan lapisan transport.
- jajak pendapat oadr – Mekanisme poling generik untuk B profile yang mengembalikan muatan untuk layanan lain yang baru atau telah diperbarui.
- oadrRespons - Digunakan untuk menunjukkan bahwa tidak ada payload baru atau yang diperbarui yang tersedia
- Daftar Istilah Elemen Muatan Skema
Berikut ini adalah daftar alfabetis elemen skema yang digunakan dalam payload OpenADR 2.0. Narasi menjelaskan penggunaannya yang berkaitan dengan OpenADR dan penggunaannya dalam payload .. Ketika definisi elemen berubah berdasarkan muatan yang terkandung di dalamnya atau konteks penggunaannya, ini akan dicatat dalam narasi. Definisi muatan root telah dikecualikan sebagaimana didefinisikan dalam Lampiran C.
- ac - Nilai Boolean yang menunjukkan apakah produk daya adalah arus bolak-balik
- akurasi - Angka dalam unit yang sama dengan variabel muatan untuk Interval. Jika ditampilkan dengan Keyakinan, menunjukkan kemungkinan variabilitas prediksi. Saat hadir dengan ReadingType, menunjukkan kemungkinan kesalahan Reading.
- aggregatedPnode - Node harga agregat adalah jenis node harga khusus yang digunakan untuk memodelkan item seperti Zona Sistem, Zona Harga Default, Zona Harga Kustom, Area Kontrol, Generasi Teragregasi, Beban Partisipasi Gabungan, Beban Non-Partisipasi Gabungan, Pusat Perdagangan, Zona DCA
- tersedia - Objek yang berisi tanggal-waktu dan durasi untuk jadwal ketersediaan EiOpt
- baselineID - ID unik untuk garis dasar tertentu
- baselineName - Nama deskriptif untuk baseline
- komponen –
- kepercayaan diri - Probabilitas statistik bahwa titik data yang dilaporkan akurat
- CreatedDateTime - The dateTime payload dibuat
- mata uang –
- mata uangPerKW –
- mata uangPerKWh –
- mata uangPerThm –
- saat ini –
- nilai sekarang - Nilai payloadFloat dari interval peristiwa yang saat ini dijalankan.
- unit khusus - Digunakan untuk menentukan unit ukuran ubahsuaian untuk laporan ubahsuaian
- tanggal-waktu –
- dtstart - Waktu mulai untuk aktivitas, data, atau perubahan status
- lamanya - Jangka waktu untuk acara, pelaporan, atau interval waktu ketersediaan
- durasi - Durasi aktivitas, data, atau status
- eiActivePeriod - Kerangka waktu yang relevan dengan keseluruhan acara
- eiCreatedEvent - Tanggapi Acara DR dengan optIn atau optOut
- eiEvent -Sebuah objek yang berisi semua informasi untuk satu acara
- eiEventBaseline - B profile
- eiEventSignal - Objek yang berisi semua informasi untuk satu sinyal dalam suatu acara
- eiEventSignals - Data interval untuk satu atau lebih sinyal peristiwa dan / atau garis dasar
- eiMarketContext - URI yang secara unik mengidentifikasi program respons permintaan
- eiReportID - ID Referensi untuk laporan
- eiRequestEvent - Minta Acara dari VTN dalam mode tarik
- eiResponse - Tunjukkan apakah payload yang diterima dapat diterima
- eiTarget - Mengidentifikasi sumber daya yang terkait dengan antarmuka VEN logis. Untuk acara, nilai yang ditentukan adalah target acara
- endDeviceAsset - EndDeviceAssets adalah perangkat fisik atau perangkat yang dapat berupa meter atau jenis perangkat lain yang mungkin menarik
- energyApparent - Energi Semu, diukur dalam volt-ampsebelum jam (VAh)
- energiItem –
- energyReactive - Energi Reaktif, volt-amperes reaktif jam (VARh)
- energyReal - Energi Nyata, Watt Jam (Wh)
- eventDescriptor - Informasi tentang acara tersebut
- eventID - Nilai ID yang mengidentifikasi contoh kejadian DR tertentu.
- acaraRespons - Objek yang berisi tanggapan VEN atas permintaan untuk berpartisipasi dalam suatu acara
- eventResponses - optIn atau optOut tanggapan untuk acara yang diterima
- status acara - Status acara saat ini (jauh, dekat, aktif, dll)
- FiturKoleksi / lokasi / Poligon / eksterior / LinearRing
- frekuensi –
- tingkat kehalusan – Ini adalah selang waktu antara sampmemimpin data dalam permintaan laporan.
- ID grup -Jenis target ini digunakan untuk acara, laporan, dan jadwal opt. Nilai biasanya akan ditetapkan oleh utilitas selama pendaftaran dalam program DR
- nama grup - Jenis target ini digunakan untuk acara, laporan, dan jadwal opt. Nilai biasanya akan ditetapkan oleh utilitas selama pendaftaran dalam program DR
- hertz –
- selang - Objek yang berisi data-waktu dan / atau durasi, dan nilai yang dapat ditindaklanjuti dalam kasus peristiwa atau data dalam kasus laporan
- interval - Satu atau beberapa interval waktu selama peristiwa DR aktif atau data laporan tersedia
- Deskripsi barang - Deskripsi unit ukuran laporan
- itemUnits - Satuan dasar untuk titik data laporan
- marketContext - URI yang mengidentifikasi Program DR
- meterAsset - MeterAsset adalah perangkat fisik atau perangkat yang menjalankan peran pengukur
- ModificationDateTime - Saat acara diubah
- ModificationNumber - Bertambah setiap kali acara diubah.
- ModificationReason - Mengapa acara diubah
- mrid - MRID mengidentifikasi perangkat fisik yang mungkin merupakan CustomerMeter atau jenis EndDevices lainnya.
- simpul - Node adalah tempat di mana sesuatu berubah (seringkali kepemilikan) atau terhubung di grid. Banyak node dikaitkan dengan meter, tetapi tidak semuanya.
- numDataSumber –
- kapasitas –
- oadcurrent –
- odrDataQuality –
- oadrDeviceClass - Target Kelas Perangkat - gunakan hanya endDeviceAsset.
- oadrEvent - Objek yang berisi peristiwa respons permintaan
- odrExtension –
- oadrExtensionName -
- oadrEkstensi –
- oadrHttpPullModel - Boolean yang menunjukkan apakah VEN ingin menggunakan model pertukaran tarik
- oadrInfo - Sepasang nilai kunci dari informasi pendaftaran khusus layanan
- oadKey –
- oadrLevelOffset –
- oadrLoadControlState –
- oadrManualOverride - Jika benar maka kontrol beban telah diganti secara manual
- oadrMax –
- oadrMaxPeriod - s maksimumampperiode panjang
- oadrMin –
- oadrMinPeriod - minimal sampperiode panjang
- oadrNormal –
- oadrOnChange - Jika benar maka data akan direkam saat berubah, tetapi pada frekuensi yang tidak lebih besar dari yang ditentukan oleh minPeriod.
- oadrOnline - Jika benar maka sumber daya / aset sedang online, jika salah maka offline.
- odrPayload –
- oadrPayloadResourceStatus - Informasi status sumber daya saat ini
- oadrMenungguLaporan - Daftar laporan berkala yang masih aktif
- oadrPercentOffset –
- oadrProfile - Profile didukung oleh VEN atau VTN
- oadrProfileNama – OpenADR profile nama seperti 2.0a atau 2.0b.
- oadrProfileS - OpenADR profiledidukung oleh pelaksanaannya
- laporan -Sebuah objek yang berisi semua informasi untuk satu laporan
- oadrReportDeskripsi - Penjelasan karakteristik laporan yang ditawarkan oleh pembuat laporan. Berisi dalam laporan metadata
- oadrReportOnly - LaporkanHanyaPerangkatBendera
- oadrReportPayload - Nilai poin data untuk laporan
- oadrRequestedOadrPollFreq - VEN akan mengirimkan muatan oadrPoll ke VTN paling banyak satu kali untuk setiap durasi yang ditentukan oleh elemen ini
- oadrResponseRequired - Mengontrol kapan respons optIn / optOut diperlukan. Bisa selalu atau tidak pernah
- bebanampNilai Ling – Samptingkat ling untuk data jenis telemetri
- layanan oadr –
- oadrNamaLayanan - Jenis target ini digunakan untuk acara, laporan, dan jadwal opt. Nilai biasanya akan ditetapkan oleh utilitas selama pendaftaran dalam program DR
- oadrServiceSpecificInfo - Informasi pendaftaran khusus layanan
- oadrSetPoint –
- oadrSignedObject –
- oadTransport - Nama transportasi yang didukung oleh VEN atau VTN
- oadrTransportAddress - Alamat root digunakan untuk berkomunikasi dengan pihak lain. Harus menyertakan port jika diperlukan
- oadrTransportName - Nama transport OpenADR seperti simpleHttp atau xmpp
- oadrTransportasi - Transport OpenADR didukung oleh implementasi
- oadrUpdatedReport - Akui penerimaan laporan
- oadrUpdateReport - Kirim laporan yang diminta sebelumnya
- Nilai oadr –
- oadrVenName - Nama VEN. Dapat digunakan di VTN GUI
- oadrXmlSignature - Implementasinya mendukung tanda tangan XML
- optID - Pengenal untuk interaksi opt
- optReason - Nilai yang disebutkan untuk alasan memilih seperti jadwal-x
- optType - optIn atau optOut dari suatu acara, atau digunakan untuk menunjukkan jenis jadwal opt yang ditentukan dalam vavailablityObject untuk layanan EiOpt
- ID pesta - Jenis target ini digunakan untuk acara, laporan, dan jadwal opt. Nilai biasanya akan ditetapkan oleh utilitas selama pendaftaran dalam program DR
- payloadFloat - Nilai poin data untuk sinyal peristiwa atau untuk melaporkan nilai saat ini atau historis.
- pnode - Node harga secara langsung dikaitkan dengan node konektivitas. Ini adalah lokasi penetapan harga di mana pelaku pasar mengajukan penawaran, penawaran, membeli / menjual CRR, dan menyelesaikannya.
- titikPengiriman –
- titikPenerimaan –
- daftar pos –
- powerApparent - Daya Semu diukur dalam volt-ampada (VA)
- kekuatan Atribut
- item daya
- powerReactive - Daya reaktif, diukur dalam volt-amperes reaktif (VAR)
- powerReal - Daya nyata diukur dalam Watt (W) atau Joule / detik (J / s)
- prioritas - Prioritas acara dalam kaitannya dengan acara lain (Semakin rendah angkanya semakin tinggi prioritasnya. Nilai nol (0) menunjukkan tidak ada prioritas, yang merupakan prioritas terendah secara default).
- properti –
- hitungan pulsa - Titik data pelaporan
- pulseFactor - kWh per hitungan
- QualifiedEventID - ID unik untuk suatu acara
- readingType - Metadata tentang Bacaan, seperti mean atau turunan
- registrasiID - Pengenal untuk transaksi Pendaftaran. Tidak termasuk dalam menanggapi pendaftaran permintaan kecuali sudah terdaftar
- balasanBatas - Jumlah maksimum kejadian untuk dikembalikan dalam payload oadrDistributeEvent
- reportBackDuration - Laporkan kembali dengan Report-To-Date untuk setiap berlalunya Durasi ini.
- reportDataSource - Sumber data dalam laporan ini. Mantanamptermasuk meter atau submeter. Untuk mantanample, jika meter mampu memberikan dua jenis pengukuran yang berbeda, maka setiap aliran pengukuran akan diidentifikasi secara terpisah.
- reportInterval - Ini adalah periode pelaporan secara keseluruhan.
- reportName - Nama opsional untuk laporan.
- reportRequestID - Pengenal untuk permintaan laporan tertentu
- reportSpecifier - Tentukan poin data yang diinginkan dalam contoh laporan tertentu
- reportSpecifierID - Pengenal untuk spesifikasi laporan Metadata tertentu
- reportSubject - Target Kelas Perangkat - gunakan hanya endDeviceAsset.
- reportToFollow - Menunjukkan apakah laporan (dalam bentuk UpdateReport) akan dikembalikan setelah pembatalan Laporan
- tipe laporan - Jenis laporan seperti penggunaan atau harga
- requestID - ID yang digunakan untuk mencocokkan permintaan dan respons transaksi logis
- ID sumber daya - Jenis target ini digunakan untuk acara, laporan, dan jadwal opt. Nilai biasanya akan ditetapkan oleh utilitas selama pendaftaran dalam program DR
- tanggapan –
- Kode respon - Kode respons 3 digit
- responseDescription - Deskripsi naratif tentang status respons
- tanggapan –
- rID - ReferenceID untuk titik data ini
- area Pelayanan - Jenis target ini digunakan untuk acara, laporan, dan jadwal opt. Nilai biasanya akan ditetapkan oleh utilitas selama pendaftaran dalam program DR
- serviceDeliveryPoint - Titik logis pada jaringan tempat kepemilikan layanan berpindah tangan. Ini adalah salah satu dari banyak titik layanan yang berpotensi dalam ServiceLocation, memberikan layanan sesuai dengan Perjanjian Pelanggan. Digunakan di tempat meteran dapat dipasang.
- serviceLocation - ServiceLocation pelanggan memiliki satu atau lebih ServiceDeliveryPoint (s), yang terkait dengan Pengukur. Lokasinya bisa berupa titik atau poligon, tergantung pada keadaan tertentu. Untuk distribusi, ServiceLocation biasanya merupakan lokasi premis pelanggan utilitas.
- signalID - Pengenal unik untuk sinyal acara tertentu
- nama sinyal - Nama sinyal seperti SIMPLE
- signalPayload - Nilai sinyal untuk acara dan garis dasar
- siScaleCode - Faktor skala untuk satuan ukuran dasar untuk laporan
- penentuPayload - Terbuka
- permulaan - Jendela pengacakan untuk memulai acara
- statusDateTime - Tanggal dan waktu referensi artefak ini.
- suhu –
- testEvent - Apa pun selain false menunjukkan peristiwa pengujian
- teks –
- Satuan panas –
- toleransi - Sub-objek yang berisi persyaratan pengacakan untuk suatu acara
- mentolerir - Objek yang berisi persyaratan pengacakan untuk suatu acara
- transportInterface - Transport Interface menggambarkan tepi di kedua ujung segmen transport.
- uid - Digunakan sebagai indeks untuk mengidentifikasi interval. Pengenal unik
- nilai –
- ketersediaan - Jadwal yang mencerminkan ketersediaan perangkat untuk berpartisipasi dalam acara DR
- VenID - Pengenal unik untuk VEN
- jilidtage –
- vtnComment - Teks apa saja
- vtnID - Pengenal unik untuk VTN
- x-eiNotification - VEN harus menerima muatan peristiwa DR sebelum dtstart dikurangi durasi ini.
- x-eiRampKe atas - Durasi sebelum atau setelah waktu mulai acara selama pelepasan muatan harus transit.
- x-eiRecovery - Durasi sebelum atau setelah waktu berakhir acara selama gudang muatan harus transit.
Daftar Istilah Enumerated Values
- aktif - Acara telah dimulai dan saat ini aktif.
- dibatalkan - Acara telah dibatalkan.
- selesai - Acara telah selesai.
- jauh - Acara tertunda di masa depan. Definisi yang tepat tentang seberapa jauh hal ini di masa mendatang bergantung pada konteks pasar, tetapi biasanya berarti pada hari berikutnya.
- di dekat - Acara tertunda dalam waktu dekat. Definisi yang tepat tentang seberapa dekat di masa depan acara yang tertunda aktif tergantung pada konteks pasar. .Mulai bersamaan dengan awal efektif acara x-eiRampWaktu habis. Jika x-eiRampNaik tidak ditentukan untuk acara tersebut, status ini tidak akan digunakan untuk acara tersebut.
- tidak ada - Tidak ada acara yang tertunda
- Mata uang
- Dolar Amerika - Dolar Amerika Serikat
- Untuk daftar banyak di sini, lihat skema
- kekuatanReal
- J/s - Joule-detik
- W - Watts
- suhu
- Celsius –
- derajat fahrenheit –
- Tidak Ada Nilai Baru - Nilai Sebelumnya Digunakan –
- No Quality - No Value –
- Kualitas Buruk - Kegagalan Komunikasi –
- Kualitas Buruk - Kesalahan Konfigurasi –
- Kualitas Buruk - Kegagalan Perangkat –
- Kualitas Buruk - Nilai Terakhir yang Diketahui –
- Kualitas Buruk - Tidak Spesifik –
- Kualitas Buruk - Tidak Terhubung –
- Kualitas Buruk - Keluar dari Layanan –
- Kualitas Buruk - Kegagalan Sensor –
- Kualitas Bagus - Penimpaan Lokal –
- Kualitas Baik - Tidak Spesifik –
- Batas Kualitas - Bidang / Konstan –
- Batas Kualitas - Bidang / Tinggi –
- Batas Kualitas - Bidang / Rendah –
- Batas Kualitas - Bidang / Tidak –
- Kualitas Tidak Pasti - Unit UE Terlampaui –
- Kualitas Tidak Pasti - Nilai Berguna Terakhir –
- Kualitas Tidak Pasti - Tidak Spesifik –
- Kualitas Tidak Pasti - Sensor Tidak Akurat –
- Kualitas Tidak Pasti - Sub Normal –
- selalu - Selalu kirimkan respon untuk setiap event yang diterima.
- tidak pernah - Jangan pernah merespon.
Alasan disebutkan untuk memilih.
- ekonomis –
- keadaan darurat –
- harus dijalankan –
- tidak Berpartisipasi –
- outageRunStatus –
- menimpaStatusS -
- berpartisipasi –
- x-jadwal –
- sederhanaHttp –
- xmpp –
- memilih di - Indikasi bahwa VEN akan berpartisipasi dalam suatu acara, atau dalam kasus layanan EiOpt, jenis jadwal yang menunjukkan bahwa sumber daya akan tersedia
- memilih keluar - Indikasi bahwa VEN tidak akan berpartisipasi dalam suatu acara, atau dalam kasus layanan EiOpt, jenis jadwal yang menunjukkan bahwa sumber daya tidak akan tersedia
- Dialokasikan - Meter mencakup beberapa [sumber daya] dan penggunaan disimpulkan melalui semacam penghitungan data pro.
- Kontrak - Mengindikasikan membaca adalah pro forma, yaitu dilaporkan dengan tarif yang disepakati
- Berasal dari - Penggunaan disimpulkan melalui pengetahuan run-time, operasi normal, dll.
- Baca Langsung - Pembacaan dibaca dari perangkat yang meningkat secara monoton, dan penggunaan harus dihitung dari pasangan pembacaan awal dan penghentian.
- Diperkirakan - Digunakan ketika pembacaan tidak ada dalam rangkaian di mana sebagian besar pembacaan hadir.
- Hibrida - Jika digabungkan, mengacu pada jenis bacaan yang berbeda di nomor agregat.
- Berarti - Membaca adalah nilai rata-rata selama periode yang ditunjukkan dalam Perincian
- Bersih - Meteran atau [sumber] menyiapkan kalkulasi sendiri dari total penggunaan dari waktu ke waktu.
- Puncak - Pembacaan adalah nilai Puncak (tertinggi) selama periode yang ditunjukkan dalam perincian. Untuk beberapa pengukuran, mungkin lebih masuk akal sebagai nilai terendah. Mungkin tidak konsisten dengan pembacaan agregat. Hanya berlaku untuk Basis Item laju aliran, yaitu, Daya bukan Energi.
- Diproyeksikan - Menunjukkan membaca di masa depan, dan belum diukur.
- Dijumlahkan - Beberapa meter bersama-sama memberikan bacaan untuk [sumber] ini. Ini secara khusus berbeda dari gabungan, yang mengacu pada beberapa [sumber daya] dalam payload yang sama. Lihat juga Hybrid.
- x-tidak Berlaku - Tak dapat diterapkan
- x-RMS - Root Mean Square
- HISTORY_GREENBUTTON - Laporan yang berisi data tombol hijau dalam struktur skema umpan atom
- HISTORY_USAGE - Laporan yang berisi data penggunaan energi historis
- METADATA_HISTORY_GREENBUTTON - Laporan metadata yang menentukan kemampuan pelaporan untuk laporan HISTORY_GREENBUTTON
- METADATA_HISTORY_USAGE - Laporan metadata yang menentukan kemampuan pelaporan untuk laporan HISTORY_USAGE
- METADATA_TELEMETRY_STATUS - Laporan metadata yang menentukan kemampuan pelaporan untuk laporan TELEMETRY_STATUS
- METADATA_TELEMETRY_USAGE - Laporan metadata yang menentukan kemampuan pelaporan untuk laporan TELEMETRY_USAGE
- TELEMETRY_STATUS - Laporan yang berisi informasi status sumber daya waktu nyata seperti status online
- TELEMETRY_USAGE - Laporan yang berisi informasi penggunaan energi waktu nyata
Nilai yang disebutkan yang memberikan jenis laporan yang disediakan.
- tersediaEnergyStorage - Kapasitas yang tersedia untuk penyimpanan energi lebih lanjut, mungkin untuk mencapai Penyimpanan Energi Target
- permintaan rata-rata - Penggunaan rata-rata selama durasi yang ditunjukkan oleh Granularitas. Lihat permintaan untuk informasi lebih lanjut.
- penggunaan rata-rata - Penggunaan rata-rata selama durasi yang ditunjukkan oleh Granularitas. Lihat penggunaan untuk informasi lebih lanjut.
- garis dasar - Bisa permintaan atau penggunaan, seperti yang ditunjukkan oleh ItemBase. Menunjukkan seperti apa [pengukuran] jika bukan karena acara atau regulasi. Laporan dalam format Baseline.
- deltaPermintaan - Perubahan permintaan dibandingkan dengan baseline. Lihat permintaan untuk informasi lebih lanjut
- deltaSetPoint - Perubahan setpoint dari jadwal sebelumnya.
- deltaPenggunaan - Perubahan penggunaan dibandingkan dengan baseline. Lihat penggunaan untuk informasi lebih lanjut
- tuntutan - Laporan menunjukkan jumlah unit (dalam denominasi ItemBase atau dalam Produk EMIX). Jenis muatan adalah Kuantitas. ItemBase tipikal adalah Real Power.
- deviasi - Perbedaan antara beberapa instruksi dan keadaan sebenarnya.
- downRegulationCapacityAvailable - Kapasitas Down Regulation tersedia untuk pengiriman, dinyatakan dalam EMIX Real Power. Muatan selalu dinyatakan sebagai Kuantitas positif.
- tingkat - Level sederhana dari pasar di setiap Interval.
- keadaan operasi - Keadaan sumber daya yang digeneralisasi seperti hidup / mati, hunian gedung, dll. Tidak ada ItemBase yang relevan. Membutuhkan Ekstensi Muatan Khusus Aplikasi.
- persenDemand – Persentage permintaan
- persenUsage – Persentage penggunaan
- faktor kekuatan - Faktor daya untuk sumber daya
- harga - Harga per ItemBase di setiap Interval
- membaca - Laporan menunjukkan pembacaan, mulai dari satu meter. Pembacaan adalah momen-momen dalam perubahan waktu dari waktu ke waktu dapat dihitung dari perbedaan antara pembacaan yang berurutan. Jenis muatan adalah float
- regulasiSetpoint - Setpoint regulasi sebagaimana diinstruksikan sebagai bagian dari layanan regulasi
- set point - Laporan menunjukkan jumlah (dalam denominasi ItemBase atau dalam Produk EMIX) yang saat ini ditetapkan. Mungkin merupakan konfirmasi / pengembalian nilai kontrol setpoint yang dikirim dari VTN. Jenis muatan adalah Kuantitas. ItemBase tipikal adalah Real Power.
- energi yang disimpan - Energi Tersimpan dinyatakan sebagai Energi Nyata dan Muatan dinyatakan sebagai Kuantitas.
- penyimpanan energi target - Energi Target dinyatakan sebagai Energi Nyata dan Muatan dinyatakan sebagai Kuantitas.
- upRegulationCapacityTersedia - Kapasitas Peraturan Naik tersedia untuk pengiriman, dinyatakan dalam EMIX Real Power. Muatan selalu dinyatakan sebagai Kuantitas positif.
- penggunaan - Laporan menunjukkan jumlah unit (dalam denominasi ItemBase atau dalam Produk EMIX) selama suatu periode. Jenis muatan adalah Kuantitas. ItemBase tipikal adalah RealEnergy
- x-resourceStatus – Persentage permintaan
- p - Pico 10 ** - 12
- n - Nano 10 ** - 9
- mikro - Mikro 10 ** - 6
- m - Mili 10 ** - 3
- c - Centi 10 ** - 2
- d - Desi 10 ** - 1
- k - Kilo 10 ** 3
- M - Mega 10 ** 6
- G - Giga 10 ** 9
- T - Tera 10 ** 12
- tidak ada - Skala Asli
- BID_ENERGI - Ini adalah jumlah energi dari sumber daya yang ditawar ke dalam suatu program
- BID_LOAD - Ini adalah jumlah beban yang ditawar oleh sumber daya ke dalam program
- HARGA PENAWARAN - Ini adalah harga yang ditawar oleh sumber daya
- BIAYA_STATE - Keadaan sumber penyimpanan energi
- PERMINTAAN_BIAYA - Ini adalah biaya permintaan
- LISTRIK_HARGA - Ini adalah biaya listrik
- ENERGI_HARGA - Ini adalah biaya energi
- BEBAN_CONTROL -Mengatur keluaran beban ke nilai relatif
- BEBAN_DISPATCH - Ini digunakan untuk mengirimkan beban
- sederhana – disusutkan – untuk kompatibilitas mundur dengan A profile
- SEDERHANA - Level sederhana (kompatibel dengan OpenADR 2.0a)
Nilai yang disebutkan yang menjelaskan jenis sinyal seperti level atau harga
- delta - Sinyal menunjukkan jumlah yang berubah dari apa yang akan digunakan seseorang tanpa sinyal.
- tingkat - Sinyal menunjukkan level program.
- memperbanyakr - Sinyal menunjukkan pengali yang diterapkan pada tingkat pengiriman atau penggunaan saat ini dari apa yang akan digunakan seseorang tanpa sinyal.
- harga - Sinyal menunjukkan harga.
- hargaKelipatanr - Sinyal menunjukkan pengganda harga. Harga diperpanjang adalah nilai harga yang dihitung dikalikan dengan jumlah unit.
- hargaRelatif - Sinyal menunjukkan harga relatif.
- set point - Sinyal menunjukkan jumlah unit target.
- x-loadControlCapacity – Ini adalah instruksi untuk pengontrol beban untuk beroperasi pada tingkat yang beberapa persentage dari kapasitas konsumsi beban maksimumnya. Ini dapat dipetakan ke pengontrol beban tertentu untuk melakukan hal-hal seperti siklus tugas. Perhatikan bahwa 1.0 mengacu pada konsumsi 100%. Dalam kasus perangkat tipe ON/OFF sederhana maka 0 = OFF dan 1 = ON.
- x-loadControlLevelOffset - Tingkat bilangan bulat diskrit yang relatif terhadap operasi normal di mana 0 adalah operasi normal.
- x-loadControlPercentOffset – Persentage perubahan dari operasi kontrol beban normal.
- x-loadControlSetpoint - Muat titik setel pengontrol.
– OpenADR A dan B Profile Perbedaan
Satu-satunya layanan yang didukung oleh A profile adalah layanan EiEvent. Objek EiEvent disederhanakan dalam A profile dengan batasan sebagai berikut:
- Hanya satu sinyal per peristiwa yang diperbolehkan dan sinyal itu harus merupakan sinyal terkenal OpenADR SEDERHANA.
- Ada penargetan acara terbatas dengan hanya mendukung venID, groupID, resourceID, dan partyID. (EiEvent: eiTarget).
- Penargetan pada tingkat sinyal dengan kelas perangkat tidak didukung (eiEventSignal: eiTarget: endDeviceAsset).
- Dasar tidak didukung (eiEvent: eiEventSignals: eiEventBaseline).
- ModificationDateTime dan ModificationReason tidak didukung.
- Titik akhir URL untuk HTTP sederhana di 2.0b adalah:
- https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>
Beberapa elemen payload yang diperlukan dalam A profile sekarang opsional di B profile, termasuk:
- nilai sekarang
Aturan kesesuaian OpenADR membutuhkan yang berikut:
- TLS Versi 1.2 digunakan untuk pertukaran sertifikat X.509
- VTN harus memiliki sertifikat SHA256 ECC dan RSA
- VEN dapat mendukung sertifikat SHA256 ECC dan RSA, dan dapat mendukung keduanya
- Baik VTN dan VEN harus dikonfigurasi untuk meminta sertifikat klien jika mereka akan memainkan peran sebagai server transportasi (yaitu menanggapi permintaan dari pihak lain)
- Baik VTN maupun VEN harus memberikan sertifikat klien ketika diminta oleh pihak lain sebagai bagian dari proses negosiasi TLS
Sertifikat yang diberikan oleh NetworkFX akan khusus untuk RSA atau ECC. Pembuatan sertifikat ini dapat terjadi sebagai hasil dari pengisian formulir di NetworkFX web situs untuk meminta sertifikat uji atau mungkin hasil dari meminta sertifikat produksi melalui Permintaan Penandatanganan Sertifikat (CSR). Terlepas dari metodenya, berikut ini files akan disediakan (misamples ditampilkan):
- Sertifikat Root
- Sertifikat Akar Menengah
- Sertifikat Perangkat
- Kunci Pribadi
Secara umum, Private Key digunakan untuk mengenkripsi muatan yang dikirim oleh VEN atau VTN. Sertifikat Perangkat adalah sekumpulan informasi pengenal unik tentang VEN atau VTN yang telah dibuat oleh Otoritas Sertifikat dan dienkripsi menggunakan Kunci Pribadi. Akar dan Menengah files digunakan untuk mendekripsi Sertifikat Perangkat dan memvalidasi bahwa sertifikat tersebut berasal dari otoritas tepercaya.
Dalam lingkungan Java yang menggunakan JSSE, ada dua penyimpanan sertifikat. Salah satunya disebut Toko Kepercayaan dan digunakan untuk memegang Sertifikat Akar. Yang kedua disebut Penyimpanan Kunci dan digunakan untuk menyimpan rantai sertifikat yang terdiri dari sertifikat perantara sertifikat perangkat, serta kunci privat.
Harap dicatat bahwa saat menggunakan transportasi XMPP, VEN berkomunikasi dengan server XMPP dan BUKAN langsung dengan VTN. Jadi konfigurasi sertifikat di server XMPP HARUS setara dengan VTN. Komunikasi antara VTN itu sendiri dan server XMPP transparan ke VEN dan pada dasarnya merupakan tautan pribadi. Namun demikian, sebagian besar vendor menggunakan satu set sertifikat VEN di VTN saat berkomunikasi dengan server XMPP.
Jika Anda menggunakan OpenFire sebagai server XMPP Anda, ada kendala lain yang harus Anda pertimbangkan. OpenFire mensyaratkan bahwa nama CN yang digunakan dalam sertifikat perangkat klien cocok dengan nama pengguna XMPP perangkat yang dikonfigurasi pada server XMPP. Hal ini dapat mengakibatkan beberapa nama klien yang aneh karena alamat seperti MAC digunakan untuk nama CN pada sertifikat VEN (Bagian dari Persyaratan Keamanan OpenADR)
Akhirnya, sebagian besar VEN dan VTN saat memainkan peran klien transportasi akan mencoba memvalidasi bahwa bidang CN dari sertifikat yang disediakan oleh server transportasi memiliki nama CN yang cocok dengan nama host dari entitas yang menyediakan sertifikat. Ini mungkin menjadi sumber masalah interoperabilitas lain saat bertukar sertifikat. Verifikasi Nama Host biasanya dapat dinonaktifkan secara terprogram untuk mengisolasi jenis masalah ini.
Panduan Program Respons Permintaan OpenADR 2.0 - Unduh [dioptimalkan]
Panduan Program Respons Permintaan OpenADR 2.0 - Unduh
