OpenADR 2.0
Vodič kroz program za odgovor na potražnju
Broj revizije: 0.92
Status dokumenta: Radni tekst
Broj dokumenta: 20140701
Autorska prava © OpenADR Alliance (2014/15). Sva prava pridržana. Informacije u ovom dokumentu vlasništvo su OpenADR alijanse i njihova upotreba i otkrivanje su ograničeni.
SADRŽAJ
5 Tipovi programa za odgovor na zahtjev 9
7 Scenarij implementacije i mapiranje programa DR 16
8 Odabir predloška programa DR 18
9 Šabloni programa za odgovor na zahtjev 21
9.1 Program kritičnih vršnih cijena (CPP) 21
9.1.1 Karakteristike programa CPP DR 21
9.1.2 OpenADR karakteristike za CPP programe 22
9.2 Program licitiranja kapaciteta 24
9.2.1 Ponuda za kapacitet Karakteristike programa DR 24
9.2.2 OpenADR karakteristike za programe licitiranja kapaciteta 25
9.3 Program stambenog termostata 27
9.3.1 Karakteristike programa DR stambenog termostata 27
9.3.2 OpenADR karakteristike za programe stambenih termostata 28
9.4.1 Karakteristike Fast DR Dispatch Program 29
9.4.2 OpenADR karakteristike za programe licitiranja kapaciteta 31
9.5 Program vremena korištenja stambenih električnih vozila (EV) (TOU) 33
9.5.1 Karakteristike programa EV TOU za stanovanje 33
9.5.2 OpenADR karakteristike za stambene EV TOU programe 33
9.6 Program određivanja cijena u realnom vremenu za električna vozila javnih stanica (EV) 34
9.6.1 Karakteristike programa javne stanice EV RTP 34
9.6.2 OpenADR karakteristike za javne stanice EV RTP programe 34
9.7 Distribuirani energetski resursi (DER) DR Program 35
9.7.1 Karakteristike programa distribuiranih energetskih resursa (DER) 35
9.7.2 OpenADR karakteristike za distribuirane energetske resurse (DER) 35
Aneks A – Sample Predlošci podataka i tereta 36
A.1 Program kritičnih vršnih cijena (CPP) 36
A.1.1 CPP scenario 1 – Jednostavan slučaj upotrebe, A ili B Profile 36
A.1.2 CPP scenario 2 – Tipičan slučaj upotrebe, B profile 36
A.1.3 CPP scenario 3 – Složeni slučaj upotrebe 37
A.1.4 CPP Sample Event Payload – Tipično B Profile Slučaj upotrebe 37
A.2 Program licitiranja kapaciteta (CBP) 39
A.2.1 CBP scenario 1 – Jednostavan slučaj upotrebe, A ili B Profile 39
A.2.2 CBP scenario 2 – Tipičan slučaj upotrebe, B profile 39
A.2.3 CBP scenario 3 – Složeni slučaj upotrebe 40
A.2.4 CBP Sample Event Payload – Tipično B Profile Slučaj upotrebe 40
A.3 Program stambenog termostata 42
A.3.1 Rezidencijalni termostat Scenarij 1 – Jednostavan slučaj upotrebe, A ili B Profile 42
A.3.2 Stambeni termostat Scenarij 2 – Tipičan slučaj upotrebe, B profile 42
A.3.3 Scenarij 3 stambenog termostata – Složeni slučaj upotrebe 43
A.3.4 Stambeni termostat Sample Event Payload – Tipično B Profile Slučaj upotrebe 43
A.4.1 Brzi DR Scenarij 1 – Jednostavan slučaj upotrebe, A ili B Profile 45
A.4.2 Brzi DR Scenarij 2 – Tipičan slučaj upotrebe, B profile 45
A.4.3 Brzi DR Scenarij 3 – Složeni slučaj upotrebe 46
A.4.4 Brzi DR Sample Event Payload – Tipično B Profile Slučaj upotrebe 46
A.4.5 Brzi DR Sample Report Metadata Payload – Typical B Profile Slučaj upotrebe 48
A.4.6 Brzi DR Sample Report Request Payload – Tipično B Profile Slučaj upotrebe 48
A.4.7 Brzi DR Sample Report Data Payload – Tipično B Profile Slučaj upotrebe 49
A.5 Program vremena korištenja stambenih električnih vozila (EV) (TOU) 49
A.5.1 Rezidencijalni EV scenario 1 – Jednostavan slučaj upotrebe, A ili B Profile 49
A.5.2 Rezidencijalni EV scenario 2 – Tipičan slučaj upotrebe, B profile 50
A.5.3 EV Sample Event Payload – Tipično B Profile Slučaj upotrebe 50
A.6 Program određivanja cijena u realnom vremenu za električna vozila javnih stanica (EV) 53
A.6.1 Javna stanica EV Scenarij 1 – Tipičan slučaj upotrebe, B profile 53
A.6.2 Javna stanica EV Sample Event Payload – Tipično B Profile Slučaj upotrebe 53
A.7 Distribuirani energetski resursi (DER) DR Program 54
Aneks B – Definicije usluge i tereta 55
B.1 Otvoreni ADR podržava sljedeće usluge: 55
Aneks C – Definicije usluge i tereta 56
C.1 Korisno opterećenje EiEvent 56
C.2 Korisno opterećenje EiReporta 56
C.4 EiRegisterParty korisni tereti 57
C.5 Korisna opterećenja OadrPoll 57
Aneks D – Pojmovnik elemenata korisnog opterećenja sheme 58
Aneks E Pojmovnik nabrojanih vrijednosti 65
Aneks F – OpenADR A i B Profile Razlike 70
Aneks G – OpenADR sigurnosni certifikati 71
Uvod
Ciljna publika ovog vodiča su komunalna preduzeća koja planiraju implementaciju programa Reagovanje na zahtjev (DR) koji koriste OpenADR 2.0 za komuniciranje poruka povezanih s DR događajima između komunalnih i nizvodnih entiteta, te proizvođača opreme koja olakšava tu razmjenu komunikacije. Pretpostavlja se da čitalac ima osnovno konceptualno razumevanje i odgovora na potražnju i OpenADR-a 2.0 (koji se od ove tačke naziva jednostavno OpenADR).
OpenADR profile specifikacije jasno definiraju očekivano ponašanje pri razmjeni informacija vezanih za DR događaje, međutim postoji dovoljno opcija u OpenADR-u da postavljanje servera (VTN-ova) u pomoćnom programu i klijenata (VEN-ova) na nizvodnim lokacijama nije plug-n-play iskustvo. OpenADR karakteristike kao što su signali događaja, formati izvještaja i ciljanje moraju biti specificirani na bazi DR programa po program.
Ne postoji takva stvar kao što je standardizovani DR program. Svaki dizajn programa DR ima tendenciju da bude jedinstven, uklapajući se u strukturne i regulatorne zahtjeve geografskog regiona u kojem je raspoređen. Za svaki DR program postoje brojni mogući scenariji implementacije koji uključuju različite aktere.
Promjenjivost u dizajnu programa DR, scenarijima implementacije i karakteristikama OpenADR-a su inhibitor proširene primjene DR-a i upotrebe OpenADR-a. Ova varijabilnost je najvećim dijelom odraz fragmentirane i složene prirode pametne mreže.
Komunalije trebaju examptipičnih DR programa tako da se mogu koristiti kao modeli za sopstvene implementacije DR programa. Proizvođači opreme moraju razumjeti tipične modele korištenja DR programa kako bi mogli potvrditi interoperabilnost kao dio procesa razvoja, a ne na bazi specifičnoj za implementaciju DR programa. Namjera ovog vodiča je da postigne oba ova cilja na sljedeći način:
- Definirajte mali skup standardnih predložaka DR programa po uzoru na zajedničke karakteristike najpopularnijih DR programa koji su do sada implementirani
- Definirajte mali skup scenarija implementacije po uzoru na implementacije u stvarnom svijetu, s jasno identificiranim akterima i ulogama
- Definirajte preporuke najbolje prakse za karakteristike OpenADR specifične za svaki od predložaka DR programa
- Omogućite stablo odlučivanja koje komunalna preduzeća mogu koristiti za identifikaciju korisnih predložaka DR programa i scenarija implementacije na osnovu njihovih poslovnih potreba
Naglasak u ovom vodiču bit će na tome da stvari budu jednostavne pružanjem malog skupa jasnih preporuka koje će se baviti većinom detalja potrebnih za implementaciju tipičnog DR programa i omogućiti testiranje interoperabilnosti opreme raspoređene u programima koristeći preporuke u ovom vodiču. vodič.
Reference
- OpenADR Profile Specifikacija i šema – www.openadr.org
Termini i definicije
U ovom dokumentu se koriste sljedeći termini i definicije.
- Demand Response: Mehanizam za upravljanje potražnjom za opterećenjem kupaca kao odgovor na uvjete ponude, kao što su cijene ili signali dostupnosti
- Agregator Party – Ovo je stranka koja agregira više Resursa zajedno i predstavlja ih Partiji Programa DR kao jedan Resurs u svojim Programima DR.
- Posrednička infrastruktura agregatora – Ovo je infrastruktura, odvojena od infrastrukture na strani potražnje, koju koristi posrednička strana agregatora za interakciju sa resursima i entitetima na strani mreže
- Sporazum: Ugovorni sporazum između strana koje igraju ulogu u programu DR u kojem se navode odgovornosti i kompenzacije
- Asset – Tip Resursa koji predstavlja određenu kolekciju fizičkih opterećenja. Resursi se mogu sastojati od sredstava, a imovina može biti resurs, ali se sredstva ne mogu dalje rastaviti na više sredstava ili resursa.
- Associated: Osigurati programsko povezivanje između dva entiteta, kroz konfiguraciju uređaja baze podataka. Na primjer, povezani resursi s VEN
- Polazne crte: Izračunata ili izmjerena potrošnja energije (potražnja) od strane dijela opreme ili lokacije prije događaja kao što je utvrđeno anketama, inspekcijama i/ili mjerenjem na lokaciji.
- BMS – Ovo je sistem upravljanja zgradom koji se može koristiti za kontrolu resursa. Ovo se ponekad naziva i Sistem upravljanja energijom.
- Compound Resource – Ovo je poseban tip Resursa koji je skup više fizičkih sredstava od kojih svako ima svoja sredstva kontrole opterećenja.
- Customer Incentive: Podsticanje dato vlasniku/agregatoru resursa na strani potražnje za učešće u programu DR.
- Infrastruktura na strani potražnje – Ovo je infrastruktura u kojoj se nalaze Resursi koji su upisani u DR programe
- DR Logic: Algoritmi ili logika koji pretvaraju DR signale u radnu kontrolu opterećenja. Imajte na umu da DR Logic može biti implementiran na mnogo različitih lokacija i u nekim slučajevima biti distribuiran među više podsistema.
- DR Program Party – ovo je subjekt koji je odgovoran za mrežnu infrastrukturu i dalje za upravljanje programima DR koji se koriste za ublažavanje problema sa mrežom. Ovo je obično uslužni program ili ISO.
- Upisan: Vlasnik/agregator resursa na strani potražnje bira da učestvuje u DR programu i može pružiti informacije o specifičnim resursima koji mogu biti ciljani za DR događaje
- Aktivni period događaja: je period u vremenu tokom kojeg se mijenja profile se traži kao dio DR događaja
- Ograničenja događaja: Vremenski okviri tokom kojih kupac može očekivati da će primiti događaje i povezana ograničenja kao što su bez događaja vikendom ili uzastopnim danima
- Event Days: Dan kada se dogodi DR događaj. Većina programa ima ograničenja u pogledu broja dana događaja koji su dozvoljeni u datom kalendarskom periodu
- Deskriptor događaja: Dio OpenADR objekta događaja koji opisuje metapodatke o događaju, kao što su naziv programa i prioritet događaja
- Trajanje događaja: Dužina događaja. Većina programa definira ograničenja u pogledu dužine događaja, kao i sati u danu tokom kojih se događaj može dogoditi
- Signali događaja: Informacije koje se mogu preduzeti sadržane u događaju kao što je cijena električne energije ili specifični nivoi rasterećenja zatražene koje obično pokreću neko unaprijed programirano ponašanje rasterećenja od strane primaoca događaja. Definicija DR programa treba specificirati tipove korištenih signala događaja
- Ciljanje događaja: Resursi za rasterećenje opterećenja koji su predviđeni primalac za DR događaj. To može biti geografsko područje, određena klasa uređaja, identifikator grupe, ID resursa ili drugi identifikator. Definicija DR programa bi trebala specificirati kako će određeni resursi biti ciljani.
- Događaji: Događaj je obavijest od pomoćnog programa da zahtijeva sporedne resurse koji zahtijevaju smanjenje opterećenja počevši u određeno vrijeme, tokom određenog trajanja, i može uključivati informacije o ciljanju koje određuju određene resurse koji bi trebali sudjelovati u događaju
- Facilitator Posrednička infrastruktura – Ovo je infrastruktura, odvojena od infrastrukture na strani potražnje, koju koristi Posrednička strana Facilitator za interakciju sa resursima i entitetima na strani mreže.
- Facilitator: Treća strana koja upravlja nekim ili cijelim izvršavanjem DR programa u ime komunalnog preduzeća
- Mrežna infrastruktura – Ovo je infrastruktura koja je u vlasništvu ili kojom upravljaju Strane u programu DR. Ova infrastruktura uključuje implementaciju OpenADR VTN-a koji se koristi za slanje DR signala Resursima upisanim u DR programe
- Intermediary Party – Ovo je stranka koja obično radi u ime Resursne stranke kako bi olakšala njihovo učešće u programima DR.
- Kontrola opterećenja – ovo je infrastruktura koja se odnosi na Resurs koji je odgovoran za stvarnu kontrolu Resursa i proizvodnju specifičnog opterećenjafile.
- Load Profile Cilj: Ova motivacija iza razvoja programa DR i izdavanja događaja. Kao što je želja za brijanjem vršnih opterećenja.
- Obavijest: Vremenski period prije vremena početka događaja u kojem je vlasnik resursa na strani potražnje obaviješten o događaju na čekanju
- Opt Behavior: Očekivani odgovor vlasnika resursa na strani potražnje po prijemu događaja. Ovaj odgovor može imati oblik i OptIn ili OptOut naznaka hoće li resurs sudjelovati u događaju ili ne
- Opt Responses: Da li bi određeni program trebao zahtijevati odgovor resursa na strani potražnje kao odgovor na događaj i kakvi su ti odgovori tipično.
- Opt Services: Rasporedi koji se komuniciraju preko OpenADR-a da ukažu na privremene promjene u dostupnosti resursa za učešće u događajima.
- Preduvjet: Kriterijumi koji moraju biti ispunjeni da bi se vlasnik resursa na strani potražnje upisao u program DR. Ovo može uključivati dostupnost intervalnog sastanka ili neki minimalni kapacitet rasterećenja
- Primary Drivers: Primarna motivacija od strane komunalnog preduzeća za kreiranje DR programa i izdavanje događaja. Kao što je „Smanjenje najveće potražnje i adekvatnost resursa“
- Programi – Ovo su DR programi u koje su Resursi upisani.
- Opis programa: Narativni opis kako program radi. Dio predložaka DR programa definiranih u ovom dokumentu
- Vremenski okvir programa: Doba godine ili godišnja doba tokom programa DR su obično aktivni
- Rate Design: Specifične modifikacije strukture stopa ili poticaja koji se plaćaju da motivišu vlasnike resursa na strani potražnje da učestvuju u programu
- Usluge registracije: Usluga koju koristi OpenADR protokol za uspostavljanje osnovne interoperabilnosti između VTN-a i VEN-a i za provjeru valjanosti da je VEN povezan s računom korisnika komunalnih usluga.
- Reporting Services: Usluga koju koristi OpenADR kako bi omogućila VEN-ovima da pruže izvještaje VEN-ovima. DR program treba specificirati zahtjeve za izvještavanje za program.
- Resurs Party – Ovo je strana koja posjeduje resurse na strani potražnje koji mogu biti upisani u programe DR
- Resurs – Ovo je entitet koji je upisan u DR programe i sposoban je isporučiti neku vrstu promjene za svoje opterećenje profile kao odgovor na prijem DR signala od VTN-a.
- Ciljni kupac: Profile resursa na strani potražnje koji se mogu uključiti u određene programe DR, kao što su stambeni, industrijski ili možda na osnovu nivoa potrošnje električne energije.
- Target Loads: Resursi na strani potražnje čije opterećenje treba modificirati nakon prijema a
- VEN – Ovo je OpenADR virtuelni krajnji čvor koji se koristi za interakciju sa VTN-om.
- VTN – Ovo je OpenADR virtuelni gornji čvor koji se koristi za interakciju sa Resursima upisanim u DR programe.
Skraćenice
- BMS: Sistem upravljanja zgradama
- C&I: Komercijalni i industrijski
- Comm: Komunikacija između dva entiteta
- DR: Odgovor na zahtjev
- EMS: Sistem upravljanja energijom
- OpenADR: Otvorite Automated Demand Response
- Programi: Referenca na program(e) odgovora na potražnju
- VEN: Virtuelni krajnji čvor
- VTN: Virtuelni gornji čvor
Tipovi programa za odgovor na zahtjev
Ovaj dokument sadrži predloške za DR programe prikazane ispod.
1. Critical Peak Pricing: Stopa i/ili struktura cijena dizajnirana da podstakne smanjenu potrošnju tokom perioda visokih veleprodajnih tržišnih cijena ili nepredviđenih situacija u sistemu nametanjem unaprijed određene visoke stope ili cijene za ograničen broj dana ili sati.
2. Program licitiranja kapaciteta: Program koji omogućava resursu potražnje na maloprodajnim i veleprodajnim tržištima da ponudi smanjenje opterećenja po cijeni, ili da identifikuje koliko opterećenja je spreman smanjiti po određenoj cijeni.
3. Program stambenog termostata/direktna kontrola opterećenja: Aktivnost odgovora na potražnju kojom sponzor programa daljinski upravlja električnom opremom korisnika (npr. klima uređajem) u kratkom roku. Ovi programi se prvenstveno nude rezidencijalnim ili malim komercijalnim korisnicima.
4. Program brze DR otpreme/pomoćnih usluga: Program odgovora na potražnju koji pruža poticajna plaćanja kupcima za odgovor na opterećenje tokom događaja hitnog odgovora na potražnju. Nenormalno stanje sistema (nprampsistemska ograničenja i lokalna ograničenja kapaciteta) koja zahtijeva automatsku ili neposrednu ručnu radnju kako bi se spriječio ili ograničio kvar prijenosnih postrojenja ili proizvodnog napajanja koji bi mogao negativno utjecati na pouzdanost rasutog električnog sistema. Ova vrsta programa se ponekad može nazvati i „Pomoćnim uslugama“.
5. Program DR za električna vozila (EV).: Aktivnost odgovora na potražnju kojom se mijenja cijena punjenja električnih vozila kako bi potrošači promijenili obrasce potrošnje.
6. Distributed Energy Resources (DER) DR Program: Aktivnost odgovora na potražnju koja se koristi za glatku integraciju distribuiranih energetskih resursa u pametnu mrežu.
Scenariji raspoređivanja
Način na koji je DR program raspoređen je donekle nezavisan od karakteristika samog DR programa. Sljedeći dijagrami pokazuju različite načine na koje se DR program može primijeniti. Sljedeći odjeljak pruža unakrsnu referencu između scenarija implementacije i DR programa s kojima će se najvjerovatnije koristiti.
Dijagrami u ovom odjeljku pokazuju odnose između entiteta u različitim scenarijima.
Direktno 1
Ovo je jednostavan scenario u kojem postoji direktna veza između Partije programa DR i Stranke resursa. Resursna strana je odgovorna za upis vlastitih Resursa u DR programe, a Mrežna infrastruktura je u direktnoj interakciji sa Resursima preko VEN-a koji se nalazi unutar Infrastrukture na strani potražnje. Nadalje, VEN je u vlasništvu Resursne stranke i odvojen je od Resursa i njihovih kontrolora. Kada VEN primi DR signal, on obično ne implementira nikakvu logiku kontrole opterećenja, već jednostavno prosljeđuje signale kontrolerima opterećenja koji poduzimaju odgovarajuću akciju. Prampdijelovi ovog scenarija bi uključivali C&I zgrade koje mogu instalirati gateway koji sadrži OpenADR VEN i kada taj gateway primi signal, on ga jednostavno prevodi u neki drugi protokol i prosljeđuje samim kontrolerima opterećenja.
Direktno 2
Ovo je vrlo slično scenariju Direct 1. Glavna razlika je u tome kako se VEN instancira i interakcija sa VTN-om je olakšana. VEN je instanciran u entitetu poput centraliziranog BMS-a koji može implementirati DR logiku i komunicirati sa Compound Resourceom i njihovim mnogim različitim kontrolerima opterećenja sa centraliziranije lokacije. Prampuključuju velike zgrade sa BMS-om koji kontroliraju mnogo različitih opterećenja u zgradi (npr. rasvjeta, HVAC, industrijski procesi, itd.) do campkoristi koje mogu imati više objekata sa centralizovanim sistemom upravljanja.
Direktno 3
Ovaj scenario je vrlo sličan scenariju Direct 1. Glavna razlika je u tome što se VEN instancira direktno u resursu i njegovom kontroleru opterećenja. U ovom slučaju DR signali se šalju direktno na resurs i njegov kontroler opterećenja. U ovu kategoriju spada takozvani scenarij “cijene uređaja”. Pramples bi uključivao bilo koju vrstu kontrolera opterećenja kao što je HVAC (tj. termostat) koji ima ugrađeni VEN koji je sposoban za direktnu interakciju sa entitetima na strani mreže VTN.
Direktno 4
Ovo je kombinacija vrsta scenarija Direct 1 i Direct 2. Glavna razlika je u tome što su višestruki VEN povezani s jednim složenim resursom koji se sastoji od više sredstava s vlastitim kontrolerima opterećenja. Svaki od kontrolera opterećenja koji se sastoji od složenog resursa može biti povezan s različitim VEN-om. Imajte na umu da bi svi VEN-ovi bili pod kontrolom iste Resursne stranke koja posjeduje Složeni Resurs. Ovaj scenario postoji kako bi se olakšale infrastrukture na strani potražnje koje imaju složene resurse, ali nemaju centralizirani BMS kao što je Direct 2 scenario. Pramples može uključivati zgrade sa različitim kontrolerima opterećenja na svakom spratu, ali bez centralizovanog BMS-a, ili campkoristi sa različitim kontrolerima u svakoj zgradi, ali ne campnas široki kontroler. Budući da iz perspektive Stranke programa DR postoji samo jedan resurs upisan u program kada želi poslati DR signal resursu, on može jednostavno poslati iste signale svakom od naznačenih VEN-ova koji su povezani sa Resursom.
Facilitator 1
U ovom scenariju postoji posrednik koji olakšava interakciju između Stranke programa DR i Resursa. Posrednička strana obično radi u ime Resursne strane kako bi im pomogla da upravljaju svojim Resursima. Stranke Resursa imaju direktne odnose sa Stranom Programa DR i upisuju svoje Resurse u Programe DR. Tako Partija programa DR viewje svaka Resursna strana kao poseban Resurs i može komunicirati sa njima pojedinačno. Uloga posredničke strane je da djeluje kao posrednik za sve interakcije povezane s OpenADR-om, tako da se VEN instancira unutar posredničke infrastrukture Facilitatora. Takva infrastruktura je često baza u oblaku i nudi se Resursnim stranama kao softver kao usluga (SaaS). Kada fasilitatorov VEN primi DR signal, može se desiti niz različitih radnji uključujući prosljeđivanje DR signala odgovarajućem Resursu i eventualnu implementaciju neke vrste DR logike i slanje komandi kontrole opterećenja kontroleru opterećenja svakog Resursa. Prampelementi ovog scenarija uključuju:
- Prodavci koji upravljaju objektima za velike komercijalne lance kao što su veletrgovci na malo.
- Posrednici u industrijskoj kontroli.
- Kompanije za energetske usluge (ESCO)
- Sistemi za upravljanje uređajima i uređajima zasnovani na oblaku, kao što su novi proizvođači termostata za pametnu komunikaciju.
Agregator 1
Ovaj scenario je sličan scenariju Facilitatora. Glavna razlika je u tome što Partija agregatora ima odnos sa Partijom programa DR za razliku od Resursnih strana. Agregator strana objedinjuje višestruku imovinu korisnika u jedan Resurs koji upisuje u DR programe. Partija programa DR nema uvid u pojedinačna sredstva kojima agregator upravlja. Kao i kod Facilitatora, agregator ima vlastitu infrastrukturu u kojoj se instancira VEN. Razlika je u tome što kada se primi DR signal on upućuje na jedan resurs i agregator implementira neku vrstu DR logike nad svim sredstvima u svom portfelju kako bi postigao ciljeve navedene u DR signalu.
Scenarij implementacije i mapiranje programa DR
Tabela u nastavku daje informacije o tome koji su scenariji implementacije najčešći za određeni DR program.
| Scenario implementacije | |||
| DR Template | Direktno 1, 2, 3, 4 | Facilitator 1 | Agregator 1 |
| CPP program | ∆ | ∆ | |
| Program licitiranja kapaciteta | ∆ | ||
| Stambeni termostat
Program |
∆ | ||
| Brza otprema DR | ∆ | ||
| Program DR za električna vozila (EV). | ∆ | ∆ | |
| Distributed Energy Resources (DER) DR Program | ∆ | ∆ | |
Odabir predloška programa DR
Slijedi skup pitanja koja su relevantna za svako komunalno preduzeće koje namjerava implementirati novi DR program. Ovo nije zamišljeno da bude sveobuhvatno, ali predstavlja neka od važnijih pitanja. Svrha ovih pitanja je da pomognu u vođenju komunalnih preduzeća prema odgovarajućem skupu predložaka DR programa.
P: Zašto želite da radite DR? Koje stanje mreže ili operativni problem pokušavate ublažiti DR?
Ovo je daleko najvažnije pitanje i čini osnovu za sveukupne zahtjeve i ciljeve za ono što bi program DR trebao postići. Odgovor na ovo pitanje definira kako opterećenje na strani potražnje profile trebalo bi da bude oblikovan DR programom. Svi ostali zahtjevi proizilaze iz odgovora na ovo pitanje.
- Pokušavate li obrijati vrhove?
- Da li želite da ispunite stomak patke?
- Pokušavate li zaštititi spot cijenu struje?
- Jeste li zabrinuti za pouzdanost mreže?
- Pokušavate li očuvati sredstva mreže?
- Itd. Itd. Itd.
Tabela ispod daje neki dodatni kontekst motivacije iza želje da se razvije DR Program
| Pouzdanost i sigurnost mreže | Frekvencija i Voltage Stabilnost |
| Adekvatnost resursa | |
| Peak Capacity | |
| Ramping | |
| Nepredviđeno | |
| Nabavka energije | Spot tržišne cijene |
| Arbitraža cijena | |
| Asset Management | Prevencija oštećenja |
| Redukcija održavanja | |
| Lifetime Extension | |
| Upravljanje kapacitetima | Ekonomske koristi |
| Upravljanje u hitnim slučajevima | |
| Environmental | Negawatt |
| Čista energija |
P: Da li postoji postojeći DR program ili tarifa za ovaj program?
- Često su pravila programa eksplicitno navedena u tarifi.
P: Na koji segment tržišta na strani potražnje ciljate ovim programom?
Ovo može pomoći u određivanju ciljanja resursa u događaju i vrste signala.
- Stambeni
- Veliki C&I
- Mali C&I
- Poljoprivreda
- Upravljanje vodama
- Električna vozila
- itd, itd itd
P: Pokušavate li ciljati određene vrste opterećenja?
- Termostati
- Električna vozila
- Ag pumpe
- itd.
P: Koji je vaš model implementacije?
Odgovor na ovo pitanje može uticati na to kako su resursi definisani u okviru programa i odrediti kako su ti resursi ciljani u okviru događaja.
- Direktno do kupaca
- Preko posrednika poput agregatora ili fasilitatora
- Kupac odgovoran za nabavku i postavljanje vlastite VEN opreme?
- itd.
P: Na kom nivou specifičnosti želite da komunicirate sa opterećenjem na strani potražnje?
Ovo pitanje je donekle povezano sa modelom implementacije i određuje kako su resursi u programu definisani i ciljani. To je jedno od najvažnijih i možda najkompleksnijih pitanja.
- Interakcija sa svakim pojedinačnim resursom
- Interakcija putem fasilitatora ili agregatora bez specifikacije resursa koji stoje iza njih
- Interagujte preko fasilitatora ili agregatora I navedite koji resursi iza njih trebaju biti poslani
- Koristite lokaciju kao atribut za određivanje resursa
- Koristite neku vrstu mehanizma grupisanja definiranog uslužnim programom da odredite resurse
- Ciljajte pojedinačna sredstva kao što su termostati
- Interakcija bez ikakvih resursa i samo emitiranje DR događaja
- itd.
P: Koji obrazac interakcije želite koristiti da biste utjecali na opterećenje vaših kupacafiles?
Ovo pitanje određuje vrstu DR signala koji će biti poslani učesnicima u programu.
- Poticaji (npr. dinamičko određivanje cijena)
- Otprema tereta (npr. pomoćne usluge)
- Direktna kontrola opterećenja
- Generički signal događaja
- itd.
P: Koji su opći atributi programa za planiranje resursa?
- Datumi i vremena kada se događaji mogu pozvati
- Učestalost događaja
- Trajanje događaja
- Dozvoljene latencije za propagaciju događaja
- itd.
P: Kako se utvrđuje dostupnost resursa u programu?
- Po strogim programskim pravilima
- Kao dio nekog procesa nominacije ili licitiranja koji vrši resurs
- Dozvoljeno uključivanje/isključivanje?
- itd.
P: Koja vrsta vidljivosti vam je potrebna za performanse resursa?
Ovo je vrlo široko pitanje i određuje koja vrsta informacija se vraća iz resursa u programu DR. Općenito, ovo određuje vrstu izvještaja koji su potrebni.
- Online / Offline
- Upotreba (trenutna i/ili istorijska)
- Potencijal odgovora na opterećenje
- Dostupnost učitavanja
- Učitavanje/stanje imovine (trenutno i/ili povijesno)
- itd, itd itd.
Predlošci programa za odgovor na zahtjev
Program kritičnih vršnih cijena (CPP)
Karakteristike programa CPP DR
| Load Profile Cilj | -Smanjenje vršne potražnje |
| Primary Drivers | -Smanjeni kapitalni izdaci i smanjeni troškovi energije |
| Opis programa | Kada komunalna preduzeća primete ili predvide visoke veleprodajne tržišne cene ili vanredne situacije u elektroenergetskom sistemu, mogu nazvati kritične događaje tokom određenog vremenskog perioda (npr. 3:6-XNUMX:XNUMX toplog letnjeg radnog dana), cena električne energije tokom ovih vremenskih perioda je značajno podignuta. |
| Customer Incentive | Kupcima se mogu ponuditi snižene cijene energije u vrijeme nevršnih opterećenja kao poticaj za učešće u programu. |
| Rate Design | CPP je cjenovni program sa stopama koje rastu tokom kritičnih vrhova potrošnje energije. Tipično CPP stope su sabirač ili množilac ravnih, višeslojnih ili TOU osnovnih stopa. |
| Ciljni kupac | -Rezidencijalni ili C&I |
| Target Load | -Bilo koji |
| Preduvjet | -Kupac mora imati intervalno mjerenje
-C&I kupci će možda morati da ispune kriterijum potražnje |
| Vremenski okvir programa | - Obično obuhvata mjesece u godini u kojima se javlja vršna potrošnja energije, iako u nekim slučajevima može biti i cijele godine. |
| Ograničenja događaja | -Uobičajeno od ponedjeljka do petka, isključujući praznike, s uobičajenim uzastopnim dnevnim događajima |
| Event Days | -Uobičajeno 9 do 15 godišnje |
| Trajanje događaja | -Uobičajeno tokom fiksnog vremenskog okvira za sve događaje u rasponu od 4 do 6 sati tokom perioda najveće potrošnje energije u danu. |
| Obavijest | -Uobičajeno dan unapred |
| Opt Behavior | -Uobičajeno, kupci nisu obavezni da učestvuju u događajima |
| Certifikacija
Događaji |
-Obično nikakve |
OpenADR karakteristike za CPP programe
| Signali događaja | –JEDNOSTAVAN signal sa nivoima od 1 do 3 mapiran na uticaj CPP događaja na cene. Ako CPP program ima jednu komponentu cijena, treba je mapirati na nivo 1. Za CPP programe sa više komponenti cijena, najmanja komponenta cijene treba biti mapirana na nivo 1, dok se ostale komponente cijene mapiraju na nivoe 2 i 3 u rastućem stepenu uticaja na cene.
-Ako implementacija podržava B profile VENs, pored signala SIMPLE, može biti uključen i signal ELECTRICITY_PRICE u korisnom učitavanju sa tipom priceRelative, priceApsolute ili priceMultiplier u zavisnosti od prirode programa. Vidi Aneks A npramples. |
| Opt Responses | -VTN-ovi koji šalju događaje treba postaviti element oadrResponseRequired na "uvijek", zahtijevajući da VEN odgovori optIn ili optOut
-Pošto je učešće u CPP programu vježba „najbolji napor“, nema formalnog značenja da se odlučite ili odjavite osim ljubaznosti naznake dostupnosti o namjeri učešća. Mi to preporučujemo VEN-ovi odgovaraju optIn-om osim ako je korisnik poduzeo neku specifičnu akciju nadjačavanja. -OadrCreateOpt korisni teret se obično ne bi koristio za kvalificiranje resursa koji učestvuju u događajima. |
| Deskriptor događaja | -Događaj prioritet treba postaviti na 1 osim ako pravila programa ili VTN konfiguracija ne određuju drugačije
–Test događaji se obično ne koriste sa CPP programima. Međutim, ako su dozvoljeni, element testEvent bi trebao biti postavljen na “true” kako bi se označio testni događaj. Ako su dodatne parametrizirane informacije potrebne u ovom elementu, može slijediti “true” odvojeno razmakom s ovim dodatnim informacijama. |
| Aktivni period događaja | – eiRampUp, eiRecovery, elementi tolerancije se obično ne koriste |
| Polazne crte | –Osnovne postavke obično nisu uključene u sadržaj događaja |
| Ciljanje događaja | -CPP programi obično ne prave razliku između resursa za datog kupca. Ciljanje obično specificira venID, ukazujući da svi resursi povezani sa VEN treba da učestvuju, ili listu svih ID-ova resursa povezan sa VEN. |
| Reporting Services | –Izvještavanje o telemetriji se obično ne koristi jer nije apsolutno neophodno za CPP programe.
Pogledajte Aneks B za nprampnekoliko izvještaja pilota komunalnih preduzeća koji bi mogli biti primjenjivi na ovu vrstu programa. |
| Opt Services | –Korišćenje Opt usluge da komuniciraju rasporede privremene dostupnosti obično se ne bi koristio kao dio CPP programa. Međutim, neke implementacije bi mogle koristiti ovu uslugu da sačuvaju dostupne dane događaja za klijente koji ukazuju na nedostatak dostupnosti. |
| Usluge registracije | Intervali anketiranja VTN zahtijeva za tipične CPP programe za dan unaprijed nisu obavezni da budu češće nego jednom na sat. Međutim, upotreba anketiranja za otkrivanje otkucaja srca može zahtijevati češće ispitivanje. |
Program licitiranja kapaciteta
Karakteristike programa za licitiranje kapaciteta DR
| Load Profile Cilj | - Vrhunsko smanjenje potražnje i adekvatnost resursa |
| Primary Drivers | -Smanjeni kapitalni izdaci i smanjeni troškovi energije |
| Opis programa | ISO/komunalne kompanije koriste program licitiranja kapaciteta da bi dobili unaprijed određeni kapacitet za smanjenje opterećenja od agregatora ili samoagregiranih kupaca. Ovaj unapred opredeljeni kapacitet rasterećenja koriste ISO/komunalne kompanije kada posmatraju ili predviđaju visoke veleprodajne tržišne cene, vanredne uslove elektroenergetskog sistema ili kao deo normalnog korišćenja energetskih resursa pozivanjem DR događaja tokom određenog vremenskog perioda.
Imajte na umu da je svaki agregator obično odgovoran za dizajniranje vlastitog programa odgovora na potražnju, kao i akviziciju kupaca i obavještavanje o događajima kako bi ispunio obaveze kapaciteta preuzetih kao dio ovog programa. |
| Customer Incentive | Agregatori/kupci dobijaju dvije vrste poticaja. Prvo, oni primaju uplatu za kapacitet za držanje određene količine kapaciteta rasterećenja raspoloživog za DR događaje tokom budućeg vremenskog prozora. Drugo, ako je događaj pozvan tokom budućeg vremenskog prozora, može se izvršiti plaćanje energije za rasterećenje tokom trajanja događaja. |
| Rate Design | Učesnici u programu daju ponudu za “nominaciju kapaciteta” ukazujući na kapacitet rasterećenja koji su spremni da drže dostupnim tokom budućeg vremenskog perioda. Ponuda takođe može uključivati podsticaj koji je agregator/kupac spreman da prihvati za smanjenje opterećenja ispod osnovne vrednosti.
Na tržištima komunalnih usluga obaveza kapaciteta je tipično za sljedeći kalendarski mjesec, iako se na ISO tržištima koriste mnogo duži vremenski okviri. Kao dio nominacije kapaciteta, korisnik može biti u mogućnosti da bira između brojnih karakteristika uključujući dan unaprijed ili dan prije obavijesti i vremenski okvir trajanja događaja (kao što je 1-4 sata, 2-6 sati,…). Plaćanje kapaciteta se vrši korisniku za ovu prethodnu obavezu čak i ako nema pozvanih događaja tokom vremenskog okvira. Ako se događaj pozove tokom vremenskog perioda, kupac može primiti plaćanje energije za rasterećenje u odnosu na osnovnu liniju, međutim kazne se mogu primijeniti ako se isporuči manji kapacitet od unaprijed određenog kapaciteta u trenutku pozivanja događaja. |
| Ciljni kupac | -Agregatori i samoagregirani C&I kupci |
| Target Loads | - Bilo koji |
| Preduvjet | -Kupac mora imati intervalno mjerenje
-C&I kupci će možda morati da ispune kriterij potražnje ili ponude |
| Vremenski okvir programa | -U bilo koje vrijeme |
| Ograničenja događaja | -Uobičajeno od ponedjeljka do petka, isključujući praznike, s uobičajenim uzastopnim dnevnim događajima |
| Event Days | -Uobičajeno najviše 30 sati mjesečno |
| Trajanje događaja | -Uobičajeno tokom fiksnog vremenskog okvira za sve događaje tokom perioda najveće potrošnje energije u danu.). Trajanje događaja ovisi o opredjeljenosti korisnika prema kapacitetu, s preferencijama u rasponu od 1 do 8 sati ili kako je određeno dizajnom programa |
| Obavijest | - Dan unaprijed ili dan-danas ovisno o preferencijama posvećenosti kapaciteta kupaca ili dizajnu programa |
| Opt Behavior | -Uobičajeno je da se kupci odaberu na događaje s obzirom na to da imaju unaprijed određeni kapacitet za smanjenje opterećenja. |
| Certifikacija
Događaji |
-Uobičajeno dva godišnje (test) |
OpenADR karakteristike za programe licitiranja kapaciteta
| Signali događaja | –JEDNOSTAVAN signal sa nivoima od 1 do 3 mapiranim na količinu rasterećenja. Ako program podržava samo jedan nivo smanjenja opterećenja, to bi trebalo mapirati na nivo 1. Za programe sa više nivoa smanjenja opterećenja, najmanju promjenu od normalnog rada treba preslikati na nivo 1, sa vrijednostima smanjenja opterećenja mapiranim na nivoa 2 i 3 u rastućem stepenu rasterećenja.
-Ako implementacija podržava B profile VENs, pored signala SIMPLE, može biti uključen signal BID_LOAD i/ili BID_PRICE u nosivosti sa tipovima signala zadate vrijednosti i cijene, te jedinicama powerReal i currencyPerKW respektivno. BID_LOAD bi odražavao traženo opterećenje do iznosa kapaciteta koji je ponudio agregator/kupac, a BID_PRICE bi odražavao poticajnu ponudu agregatora/kupca. Vidi Aneks A npramples. |
| Opt Responses | -VTN-ovi koji šalju događaje treba postaviti element oadrResponseRequired na "uvijek", zahtijevajući da VEN odgovori optIn ili optOut
-Kao agregatori/kupci imaju unapred angažovani kapacitet VEN-ovi bi trebali odgovoriti sa optIn. Opt-out se može poslati kao odgovor na događaj, ali ovo je neformalna indikacija dostupnosti, a ne formalno odustajanje od događaja. -The oadrCreateOpt korisni teret se obično ne bi koristio da se kvalifikuju resursi koji učestvuju u događajima jer je obično opterećenje jedan agregirani entitet. |
| Deskriptor događaja | -Događaj prioritet treba postaviti na 1 osim ako pravila programa ili VTN konfiguracija ne određuju drugačije
–Mogu se koristiti test događaji sa programima za licitiranje kapaciteta. Ako su dozvoljeni, element testEvent bi trebao biti postavljen na “true” kako bi se označio testni događaj. Ako su dodatne parametrizirane informacije potrebne u ovom elementu, može slijediti “true” odvojeno razmakom s ovim dodatnim informacijama. |
| Aktivni period događaja | – eiRampUp, eiRecovery, elementi tolerancije se obično ne koriste |
| Polazne crte | –Osnovne postavke obično nisu uključene u sadržaj događaja pošto ti podaci obično nisu dostupni u trenutku kada je događaj pokrenut. Međutim, i komunalna preduzeća i agregatori/kupci bi view uključivanje osnovnih informacija u događaje kao korisne. |
| Ciljanje događaja | - Programi za licitiranje kapaciteta obično ne prave razliku između resursa za datog kupca. Ciljanje obično specificira venID, ukazujući da svi resursi povezani sa VEN treba da učestvuju, ili uključuje resourceID koji predstavlja agregirano opterećenje povezan sa VEN. |
| Reporting Services | ISO programi za licitiranje kapaciteta obično zahtijevaju TELEMETRY_USAGE izvještaje sa powerReal data pointovima. Vidi pramples u Aneksu A.
Izvještavanje o telemetriji za licitiranje kapaciteta preduzeća obično nije potrebno. Imajte na umu da je za telemetrijsko izvještavanje potreban B profile VENs. Pogledajte Aneks B za nprampnekoliko izvještaja pilota komunalnih preduzeća koji bi mogli biti primjenjivi na ovu vrstu programa. |
| Opt Services | –Korišćenje Opt usluge da komuniciraju rasporede privremene dostupnosti obično se ne bi koristio kao dio programa licitiranja kapaciteta jer su klijenti unaprijed potvrdili svoju dostupnost. Međutim, ova usluga može biti korisna kao neformalni način za učesnike da ukažu na nedostatak dostupnosti zbog olakšavajućih razloga kao što je kvar opreme. |
| Usluge registracije | Intervali anketiranja VTN zahtijeva za tipične programe za dan unaprijed nisu obavezni da budu češće nego jednom na sat. Međutim, upotreba anketiranja za otkrivanje otkucaja srca ili dnevnih programa može zahtijevati češće ispitivanje. |
Program stambenog termostata
Ovaj program je reprezentativan za direktnu kontrolu opterećenja (DLC) gdje signal odgovora na zahtjev direktno modificira ponašanje resursa za rasterećenje opterećenja, bez sloja apstrakcije između prijema signala i određene akcije smanjenja opterećenja.
Karakteristike programa DR za stambeni termostat
| Load Profile Cilj | -Smanjenje vršne potražnje |
| Primary Drivers | -Smanjeni kapitalni izdaci i smanjeni troškovi energije |
| Opis programa | -Kada komunalna preduzeća primete ili predvide visoke veleprodajne tržišne cene ili vanredne situacije u elektroenergetskom sistemu, mogu pokrenuti događaj koji modifikuje ponašanje korisnikovog programabilnog komunikacionog termostata (PCT) tokom određenog vremenskog perioda (npr. 3:6-XNUMX:XNUMX na vrućem ljetni radni dan) kako bi se smanjila potrošnja energije.
- Promjena ponašanja PCT-a kao odgovor na događaj može biti jednostavna promjena zadane temperature za vrijeme trajanja događaja ili složeniji skup promjena, uključujući prethodno hlađenje, koje minimiziraju utjecaj događaja na udobnost korisnika nivo. |
| Customer Incentive | -Podsticaji imaju dva opšta oblika. Prvo, kupcima se može obezbijediti besplatan PCT ili ponuditi popuste/popuste na kupce PCT-ove kao poticaj da se upišu u DR program. Drugo, korisnici mogu dobiti stalnu godišnju stipendiju za nastavak upisa u program. Manje uobičajeni bi bili stalni podsticaji koji se isplaćuju kupcima na osnovu stvarnog smanjenja energije tokom događaja. |
| Rate Design | -Primarno poticajni program, gdje kupci dobijaju snižene ili besplatne PCT-ove za upis u DR program. Neki programi mogu plaćati periodičnu stipendiju ili podsticajna plaćanja na osnovu smanjenja energije tokom događaja.
|
| Ciljni kupac | -Stambeni |
| Target Load | -HVAC |
| Preduvjet | -Uobičajeno nikakav, pošto korisnici dobijaju PCT kao deo upisa u program
|
| Vremenski okvir programa | - Obično obuhvata mjesece u godini u kojima se javlja vršna potrošnja energije, iako u nekim slučajevima može biti i cijele godine. |
| Ograničenja događaja | -Uobičajeno od ponedjeljka do petka, isključujući praznike, s uobičajenim uzastopnim dnevnim događajima. |
| Event Days | -Uobičajeno 9 do 15 godišnje |
| Trajanje događaja | - Događaji se mogu dogoditi u bilo koje vrijeme, sa trajanjem od 2 do 4 sata, iako se obično događaji dešavaju u doba najveće potrošnje energije u danu. |
| Obavijest | -Uobičajeno dan unaprijed, iako neki programi mogu imati vrijeme obavještenja i do 10 minuta. |
| Opt Behavior | -Kupci nisu obavezni da učestvuju u događajima, ali će automatski biti uključeni u događaje osim ako ne preduzmu radnju da zaobiđu događaj ili izvrše ručna podešavanja temperature tokom događaja. |
| Certifikacija
Događaji |
-Obično nikakve |
OpenADR karakteristike za programe stambenih termostata
| Signali događaja | –JEDNOSTAVAN signal sa nivoima od 1 do 3 mapiranim na promjenu pomaka zadane vrijednosti PCT temperature ili procenta termostatskog ciklusatage . Ako program stambenog termostata ima jednu komponentu pomaka/ciklusa, treba je mapirati na nivo 1. Za programe s više komponenata pomaka/ciklusa, najmanja promjena od normalnog rada treba biti mapirana na nivo 1, s drugim vrijednostima pomaka/ciklusa mapiran na nivoe 2 i 3 u rastućem stepenu uticaja rasterećenja.
-Ako implementacija podržava B profile VENs, pored signala SIMPLE, može biti uključen i LOAD_CONTROL signal u nosivosti sa vrstom x-loadControlLevelOffset ili x-loadControlCapacity da odredite željeni pomak zadane vrijednosti temperature ili postotak termostatskog ciklusatage respektivno. Ponovo se počinje da a tip jedinice "temperature" koji se koristi u korisnim opterećenjima koristeći x-loadControlLevelOffset signalType za označavanje Celzijusa ili Farenhajta za pomak. Vidi Aneks A npramples. |
| Opt Responses | -VTN-ovi koji šalju događaje treba postaviti element oadrResponseRequired na "uvijek", zahtijevajući da VEN odgovori optIn ili optOut
– VEN-ovi bi trebali odgovoriti optIn-om osim ako je korisnik poduzeo neku specifičnu radnju nadjačavanja. -The VEN-ovi mogu koristiti oadrCreateOpt korisni teret da se kvalifikuje učešće resursa na događaju. Na primjer, događaj može ciljati ID-ove resursa dva termostata koji kontroliraju odvojene HVAC sisteme. Ako kupac odluči da samo jedan od HVAC sistema može sudjelovati u događaju, to će biti priopćeno VTN-u pomoću oadrCreateOpt korisnog opterećenja. Imajte na umu da oadrCreateOpt korisni teret podržava samo B profile VENs |
| Deskriptor događaja | -Događaj prioritet treba postaviti na 1 osim ako pravila programa ili VTN konfiguracija ne određuju drugačije
–Test događaji se obično ne koriste sa programima stambenog termostata. Međutim, ako su dozvoljeni, element testEvent bi trebao biti postavljen na “true” kako bi se označio testni događaj. Ako su dodatne parametrizirane informacije potrebne u ovom elementu, može slijediti “true” odvojeno razmakom s ovim dodatnim informacijama. |
| Aktivni period događaja | –Randomizacija se obično koristi za događaje stambenog termostata koristeći element tolerancije
– eiRampElementi Up i eiRecovery se obično ne koriste |
| Polazne crte | –Osnovne postavke obično nisu uključene u sadržaj događaja |
| Ciljanje događaja | -Programi stambenih termostata ciljaju HVAC resurse koje kontroliraju PCT-ovi. Ciljanje obično specificira ID-ove resursa HVAC sistema (tj. termostata) povezanih sa VEN ili venID sa ciljem klase uređaja signala događaja postavljenom na Termostat |
| Reporting Services | –Izvještavanje o telemetriji se obično ne koristi jer nije apsolutno neophodan za programe stambenih termostata
Pogledajte Aneks B za nprampnekoliko izvještaja pilota komunalnih preduzeća koji bi mogli biti primjenjivi na ovu vrstu programa. |
| Opt Services | –Korišćenje Opt usluge da komuniciraju rasporede privremene dostupnosti obično se ne bi koristio kao dio CPP programa. |
| Usluge registracije | Intervali anketiranja VTN zahtijeva za tipične programe stambenih termostata za dan unaprijed nisu obavezni da budu češće nego jednom na sat. Međutim, upotreba prozivanja za otkrivanje otkucaja srca može zahtijevati češće ispitivanje, kao i programi stambenih termostata sa znatno kraćim vremenom obavještavanja. |
Brza otprema DR
Karakteristike Fast DR Dispatch programa
| Load Profile Cilj | -Dispečirati resurse za postizanje odgovora na opterećenje u "realnom vremenu" |
| Primary Drivers | -Pouzdanost mreže i pomoćne usluge |
| Opis programa | Brzi DR koriste ISO/uslužni programi za dobijanje unapred predanog odgovora na opterećenje u „realnom vremenu“. Ovaj unapred opredeljeni odgovor opterećenja koriste ISO/komunalne kompanije kada posmatraju uslove koji zahtevaju neposrednu akciju za održavanje stabilnosti i integriteta mreže. Realno vrijeme znači da se resursi obično šalju s kašnjenjem u rasponu od 10 minuta za resurse koji se koriste kao rezerve do 2 sekunde za resurse koji se koriste u regulacijske svrhe.
Veličina odgovora opterećenja mora biti dovoljno velika da napravi razliku u ublažavanju stanja mreže i stoga su resursi obično vrlo veliki i često njima upravljaju agregatori kao dio agregiranog resursa. Minimalne veličine za odgovor opterećenja za resurs koji se kvalifikuje za učešće u pomoćnim uslugama su obično oko 500 kW, ali mogu biti i do 100 kW za neke programe. Imajte na umu da ako se resurs koristi kao rezerva, obično će biti pozvan da smanji (tj. rastereti) opterećenje, ali ako se koristi u regulacijske svrhe, može se poslati da poveća ili smanji opterećenje. |
| Customer Incentive | Agregatori/kupci obično primaju dvije vrste poticaja. Prvo, primaju uplatu za preuzimanje i stavljanje na raspolaganje određene količine odgovora učitavanja dostupnog za DR događaje tokom budućeg vremenskog prozora. Količina odgovora na opterećenje, vremenski okvir dostupnosti i iznos koji treba platiti obično postavlja agregator/kupac. Drugo, ako se događaj pozove tokom budućeg vremenskog prozora, plaćanje se zasniva na količini odgovora na opterećenje tokom trajanja događaja. |
| Rate Design | Učesnici u programu podnose ponudu sa naznakom odgovora na opterećenje koje su spremni učiniti dostupnim tokom budućeg vremenskog perioda. Ponuda obično uključuje i plaćanje koje je agregator/kupac spreman prihvatiti za odgovor opterećenja.
Na komunalnim/ISO tržištima ponuda se obično podnosi ili dan unaprijed ili na dan vremenskog perioda za koji se obaveza preuzima. Kao dio njihove kvalifikacije i registracije na tržištima različiti parametri omotača performansi povezani su sa resursom kao što je ramp brzina i minimalne i maksimalne radne granice. Takvi parametri određuju način na koji će biti poslat. Ako je ponuda učesnika prihvaćena, može se izvršiti uplata kupcu za njihovu prethodnu obavezu čak i ako nema događaja koji se pozivaju tokom vremenskog perioda. Ako se događaj pozove tokom vremenskog okvira, korisnik može dobiti dodatna plaćanja za svoj nastup tokom događaja. Takva plaćanja zasnovana na učinku mogu se zasnivati na brojnim faktorima, uključujući količinu energije, snagu, koliko pažljivo resurs prati uputstva za otpremu i plaćanje „kilometraže“ koje odražava koliko je njihov teret profile bio je obavezan da se promijeni tokom događaja. Neki od ovih parametara kao što su energija i snaga mogu biti u odnosu na osnovnu liniju. |
| Ciljni kupac | -Agregatori i samoagregirani C&I kupci |
| Target Loads | – Oni koji mogu da odgovore na depeše u realnom vremenu. |
| Preduvjet | -Kupac mora imati intervalno mjerenje
-Mora zadovoljiti zahtjeve za minimalnu veličinu za odgovor na opterećenje -Mora biti u stanju da odgovori na depeše u realnom vremenu -Uobičajeno je potrebno dostaviti telemetriju u realnom vremenu koja pokazuje trenutni odgovor opterećenja |
| Vremenski okvir programa | -U bilo koje vrijeme |
| Ograničenja događaja | -nema |
| Event Days | -nema |
| Trajanje događaja | -Uobičajeno kratko (manje od 30 minuta), ali u svakom slučaju nikada neće prekoračiti vremenski okvir koji je učesnik stavio na raspolaganje resursu kada je predao svoju ponudu. |
| Obavijest | -nema |
| Opt Behavior | -Kupci su uključeni u događaje prema zadanim postavkama s obzirom na to da imaju unaprijed predani odgovor na opterećenje |
| Certifikacija
Događaji |
-Uobičajeno jedan godišnje (test) |
OpenADR karakteristike za programe licitiranja kapaciteta
| Signali događaja | –JEDNOSTAVAN signal sa nivoima od 1 do 3 mapiranim na količinu odziva opterećenja. Ako program podržava samo jedan nivo odgovora na opterećenje, to bi trebalo mapirati na nivo 1. Za programe sa više nivoa odgovora na opterećenje, najmanju promjenu od normalnog rada treba preslikati na nivo 1, sa vrijednostima ograničenja opterećenja mapiranim na nivoa 2 i 3 u rastućem stepenu odgovora na opterećenje.
-Ako implementacija podržava B profile VENs, pored SIMPLE signala, može biti uključena i otprema u obliku LOAD_DISPATCH signala u korisnom opterećenju s tipovima signala zadane vrijednosti ili delta, i jedinicama powerReal. Ovaj signal predstavlja željenu “radnu tačku” opterećenja i može se izraziti ili kao apsolutna količina mW (tj. zadana vrijednost) ili neki relativni broj mW (tj. delta) od trenutne radne točke resursa. Vidi Aneks A npramples. |
| Opt Responses | -VTN-ovi koji šalju događaje treba postaviti element oadrResponseRequired na "uvijek", zahtijevajući da VEN odgovori optIn ili optOut
-Kao agregatori/kupci imaju unapred angažovani kapacitet VEN-ovi bi trebali odgovoriti sa optIn. Opt-out se može poslati kao odgovor na događaj, ali ovo je neformalna indikacija dostupnosti, a ne formalno odustajanje od događaja. -The oadrCreateOpt korisni teret se obično ne bi koristio da se kvalifikuju resursi koji učestvuju u događajima jer je obično opterećenje jedan agregirani entitet. |
| Deskriptor događaja | -Događaj prioritet treba postaviti na 1 osim ako pravila programa ili VTN konfiguracija ne određuju drugačije
–Mogu se koristiti test događaji, posebno prilikom registracije i kvalifikacije resursa. Ako su dozvoljeni, element testEvent bi trebao biti postavljen na “true” kako bi se označio testni događaj. Ako su dodatne parametrizirane informacije potrebne u ovom elementu, može slijediti “true” odvojeno razmakom s ovim dodatnim informacijama. |
| Aktivni period događaja | – Elementi tolerancije se ne koriste. eiRampUp i eiRecovery periodi su tipično dio parametara resursa kada se registruju i mogu se koristiti. Zbog prirode slanja, one mogu biti otvorene i stoga možda neće biti vremena završetka događaja. |
| Polazne crte | –Osnovne postavke obično nisu uključene u sadržaj događaja pošto ovi podaci obično nisu dostupni u trenutku kada je događaj pokrenut. Međutim, i komunalna preduzeća i agregatori/kupci bi view uključivanje osnovnih informacija u događaje kao korisne. |
| Ciljanje događaja | - Programi za licitiranje kapaciteta obično ne prave razliku između resursa za datog kupca. Ciljanje obično specificira venID, ukazujući da svi resursi povezani sa VEN treba da učestvuju, ili uključuje resourceID koji predstavlja agregirano opterećenje povezan sa VEN. |
| Reporting Services | Brzi DR programi obično zahtijevaju TELEMETRY_USAGE izvještaje sa powerReal data pointovima. Izvještaj o korištenju prikazuje trenutnu radnu tačku resursa i koristi ga Uslužni program/ISO da odredi koliko pažljivo resurs prati instrukciju za otpremu koja je poslana.
U nekim slučajevima telemetrija može uključivati druge tačke podataka kao što su voltagOčitavanja i stanje napunjenosti (tj. energija) u slučaju kada su resursi neki oblik skladištenja. U nekim slučajevima učestalost javljanja može biti visoka i na svake 2 sekunde. Imajte na umu da je za telemetrijsko izvještavanje potreban B profile VENs. Vidi Aneks A npramples. Također pogledajte Aneks B nprampnekoliko izvještaja pilota komunalnih preduzeća koji bi mogli biti primjenjivi na ovu vrstu programa. |
| Opt Services | –Korišćenje usluge Opt za saopštavanje privremene dostupnosti rasporedi obično se ne bi koristio pošto su se kupci unaprijed obavezali na svoju dostupnost. Međutim, ova usluga može biti korisna kao neformalni način za učesnike da ukažu na nedostatak dostupnosti zbog olakšavajućih razloga kao što je kvar opreme. |
| Usluge registracije | Zbog zahtjeva za niskim kašnjenjem pošiljaka u realnom vremenu koriste se samo obrasci push interakcije. |
Program vremena korištenja stambenih električnih vozila (EV) (TOU).
Karakteristike programa EV TOU za stanovanje
| Load Profile Cilj | Struktura stope po kojoj se trošak punjenja električnih vozila modificira kako bi potrošači promijenili obrasce potrošnje. |
| Primary Drivers | Potrošnja energije u stambenim objektima dostiže vrhunac u večernjim satima. Budući da EV punjenje traje 4-8 sati, može se odgoditi nekoliko sati kako bi se pomjerili vrhovi opterećenja. |
| Opis programa | Kupci koji imaju električno vozilo mogu se prijaviti za tarifu za vrijeme upotrebe električnog vozila (EV-TOU) i dobiti niže cijene za punjenje svog vozila u vrijeme van vršnih sati, kao što je između ponoći i 5 ujutro, cijene EV-TOU su ponudio da ohrabri kupce da ograniče dnevnu upotrebu električne energije, kada je potražnja za električnom energijom najveća. |
| Customer Incentive | Jeftinije punjenje za EV. |
| Rate Design | TOU sa najvišom sredinom dana, jutarnjim i večernjim sredinom i 12-5 sati van špice |
| Ciljni kupac | Vlasnik EV sa profesionalcem za opterećenjefile koji dostiže vrhunac uveče. |
| Target Loads | EV punjači |
| Preduvjet | Kupac mora imati pametno brojilo i EV |
| Vremenski okvir programa | Cijele godine |
| Ograničenja događaja | Nema |
| Event Days | Svaki dan ili samo radnim danima |
| Trajanje događaja | 5-8 sata |
| Obavijest | Kupac se obavještava o nivoima cijena na svojim mjesečnim računima, a VTN-ovi šalju signale o događajima dan unaprijed. |
| Opt Behavior | Obveznici plaćanja mogu promijeniti svoj tarifni plan kao što bi inače radili sa komunalnim preduzećima. |
| Certifikacija
Događaji |
OpenADR karakteristike za stambene EV TOU programe
| Signali događaja | ELECTRICITY_PRICE signali sa stvarnim nivoima cijena, kao i SIMPLE signali koji omogućavaju učešće 2.0a VEN-a
Vidi Aneks A npramples. |
| Opt Responses | Uvijek optIn od strane VEN-a |
| Deskriptor događaja | Jedan događaj sedmično, sa intervalima događaja za svaki nivo cijene |
| Aktivni period događaja | Treba koristiti obavještenje od najmanje 24 sata. Svaki interval događaja treba da obuhvati nivo stope TOU |
| Polazne crte | N/A |
| Ciljanje događaja | Nije potrebno napredno ciljanje, samo ciljanje na nivou VEN. |
| Reporting Services | Nije potrebno izvještavanje, svi podaci mogu doći sa brojila.
Pogledajte Aneks B za nprampnekoliko izvještaja pilota komunalnih preduzeća koji bi mogli biti primjenjivi na ovu vrstu programa. |
| Opt Services | Opt usluge ne bi bile relevantne za ovaj tip programa. |
| Usluge registracije | Potrošači bi unaprijed obezbijedili svoj VEN sa uslužnim programom za primanje signala o cijenama. |
Program određivanja cijena u realnom vremenu za električna vozila javnih stanica (EV).
Karakteristike programa javne stanice EV RTP
| Load Profile Cilj | Aktivnost odgovora na potražnju kojom se mijenja cijena punjenja električnih vozila kako bi se stvarnost vršnih cijena prebacila na potrošače. |
| Primary Drivers | Cijena električne energije je promjenjiva tokom jednog dana. Ovaj program ima za cilj da efikasnije uskladi cijenu naplate sa troškom električne energije. |
| Opis programa | Javni punjači mogu postojati na radnim mjestima, na javnim parkiralištima iu maloprodajnim objektima. Ovaj program prenosi cijene u realnom vremenu potencijalnim punjačima prije nego što se uključe, tako da mogu donijeti informiranu odluku o tome hoće li puniti svoj automobil ili ne. |
| Customer Incentive | Jeftinije punjenje tokom vremena van vršnog opterećenja. |
| Rate Design | Cijene se mogu promijeniti hourly, ali kada kupac odluči da uključi svoj automobil, cijena se postavlja za vrijeme trajanja punjenja. |
| Ciljni kupac | Svako ko ima EV koji treba da se puni dok nije od kuće. |
| Target Loads | Javni EV punjači |
| Preduvjet | EV punjači moraju biti povezani na internet i OpenADR2.0b certificirani ili povezani na OpenADR2.0b VEN gateway. |
| Vremenski okvir programa | Cijele godine |
| Ograničenja događaja | Nema |
| Event Days | Svaki dan ili samo radnim danima |
| Trajanje događaja | 1 sat ili duže |
| Obavijest | Kupac je obaviješten o preovlađujućoj stopi kada odluči da uključi svoj automobil. |
| Opt Behavior | Kupci se mogu odbiti tako što će odlučiti da ne naplaćuju. |
| Certifikacija
Događaji |
OpenADR karakteristike za javne stanice EV RTP programe
| Signali događaja | ELECTRICITY_PRICE signali s cijenama.
Vidi Aneks A npramples. |
| Opt Responses | Uvijek optIn od strane VEN-a |
| Deskriptor događaja | Događaji moraju biti uzastopni i sadržavati jedan interval. |
| Aktivni period događaja | Treba koristiti obavještenje od najmanje 1 sata, međutim komunalne usluge mogu odabrati korištenje obavještenja dan unaprijed. |
| Polazne crte | N/A |
| Ciljanje događaja | Nije potrebno napredno ciljanje, ali ciljanje se može koristiti za slanje cijena određenim transformatorima, napojnim jedinicama ili geografskim područjima. |
| Reporting Services | Nije potrebno izvještavanje, ali se može koristiti po želji.
Pogledajte Aneks B za nprampnekoliko izvještaja pilota komunalnih preduzeća koji bi mogli biti primjenjivi na ovu vrstu programa. |
| Opt Services | Opt usluge ne bi bile relevantne za ovaj tip programa. |
| Usluge registracije | Prodavac stanica za punjenje bi svojim uređajima opskrbio VTN komunalne usluge. |
Distributed Energy Resources (DER) DR Program
Sljedeći opis programa je hipotetički i zasnovan je na istraživačkom radu (referenca na Rishov rad) koji opisuje kako korisnici komunalnih usluga mogu koristiti DER resurse za skladištenje da bi učestvovali u DR programima kao što su programi određivanja cijena u realnom vremenu (RTP).
Karakteristike programa distribuiranih energetskih resursa (DER).
| Load Profile Cilj | Aktivnost odgovora na potražnju koja se koristi za glatku integraciju distribuiranih energetskih resursa u pametnu mrežu. |
| Primary Drivers | -Smanjeni kapitalni izdaci i smanjeni troškovi energije |
| Opis programa | Kupci sa DER resursima koji mogu sakupljati energiju i skladištiti je mogu minimizirati troškove kupovine električne energije iz mreže tokom perioda visokih cijena tako što će prvo koristiti uskladištene izvore energije, nakon čega slijedi implementacija strategija za smanjenje opterećenja |
| Customer Incentive | Sposobnost kontrole troškova u vrijeme visokih cijena električne energije korištenjem uskladištene energije proizvedene putem fotonaponskih ili drugih sredstava i implementacijom strategija za smanjenje opterećenja |
| Rate Design | Cijene električne energije variraju u zavisnosti od veleprodajnih tržišnih cijena ili tarife koja varira u zavisnosti od doba dana, sezone ili temperature |
| Ciljni kupac | Kupci sa resursima za skladištenje energije |
| Target Loads | Bilo koji |
| Preduvjet | Resursi za skladištenje energije |
| Vremenski okvir programa | Bilo kada |
| Ograničenja događaja | Nema |
| Event Days | Svaki dan |
| Trajanje događaja | 24 sati |
| Obavijest | Dan unaprijed |
| Opt Behavior | N/A – Program najboljeg truda |
| Certifikacija
Događaji |
Nema |
OpenADR karakteristike za distribuirane energetske resurse (DER)
| Signali događaja | ELECTRICITY_PRICE signali sa 24 jednosatnih intervala cijena u periodu od 24 sata. Ovaj signal će zahtijevati B profile. Ovaj program nije pogodan za JEDNOSTAVNU signalizaciju za A profile VENs.
Vidi Aneks A npramples. |
|
| Opt Responses | -VTN-ovi koji šalju događaje treba postaviti element oadrResponseRequired na "nikad", sprečavajući VEN-ove da reaguju. | |
| Deskriptor događaja | -Događaj prioritet treba postaviti na 1 osim ako pravila programa ili VTN konfiguracija ne određuju drugačije | |
| Aktivni period događaja | 24 sata sa intervalima od 1 sata sa obavještenjem dan unaprijed | |
| Polazne crte | N/A | |
| Ciljanje događaja | Nije potrebno napredno ciljanje osim venID-a | |
| Reporting Services | Nije potrebno izvještavanje
Pogledajte Aneks B za nprampnekoliko izvještaja pilota komunalnih preduzeća koji bi mogli biti primjenjivi na ovu vrstu programa. |
|
| Opt Services | Nije korišteno | |
| Usluge registracije | Intervali anketiranja VTN zahtijeva za tipične t programe za dan unaprijed nisu obavezni da budu češće nego jednom na sat. Međutim, upotreba prozivanja za otkrivanje otkucaja srca može zahtijevati češće ispitivanje, kao i programi stambenih termostata sa znatno kraćim vremenom obavještavanja. |
– Sample Data and Payload Templates
Sljedeće tablice i XML korisni teret samples će implementatorima pružiti opipljive exampinformacije o tome kako treba implementirati DR šablone u ovom dokumentu. Sljedeći prefiksi prostora imena se koriste u korisnom učitavanju examples:
- xmlns:oadr=”http://openadr.org/oadr-2.0b/2012/07″
- xmlns:pyld=”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
- xmlns:ei=”http://docs.oasis-open.org/ns/energyinterop/201110″
- xmlns:scale=”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
- xmlns:emix=”http://docs.oasis-open.org/ns/emix/2011/06″
- xmlns:strm=”urn:ietf:params:xml:ns:icalendar-2.0:stream”
- xmlns:xcal=”urn:ietf:params:xml:ns:icalendar-2.0″
- xmlns:power=”http://docs.oasis-open.org/ns/emix/2011/06/power”
Program kritičnih vršnih cijena (CPP)
CPP scenario 1 – Jednostavan slučaj upotrebe, A ili B Profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 4 sata
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 1
- Naziv signala: SIMPLE
- Vrsta signala: nivo
- Jedinice: N/A
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 1
- Cilj signala: N/A
- Cilj(i) događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
CPP scenario 2 – Tipičan slučaj upotrebe, B profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 4 sati
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 2
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0, 1, 2, 3
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 1 ili 2
- Cilj signala: nema
- Naziv signala: ELECTRICITY_PRICE
- Vrsta signala: cijena
- Jedinice: USD po Kwh
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: $0.10 do $1.00
- Cilj signala: nema
- Ciljevi događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
CPP scenario 3 – Složen slučaj upotrebe
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 2:XNUMX
- Trajanje: 6 sati
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala:2
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0,1, 2, 3)
- Broj intervala 3
- Trajanje intervala: 1 sat, 4 sata, 1 sat
- Tipične vrijednosti intervala: 1, 2, 1 (za svaki interval respektivno)
- Cilj signala: nema
- Naziv signala: ELECTRICITY_PRICE
- Vrsta signala: cijena
- Jedinice: USD po Kwh
- Broj intervala 3
- Trajanje intervala: 1 sat, 4 sata, 1 sat
- Tipične vrijednosti intervala: $0.50, $0.75, $0.50 (za svaki interval respektivno)
- Cilj signala: nema
- Ciljevi događaja: Resurs_1, Resurs_2, Resurs_3
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
CPP Sample Event Payload – Tipično B Profile Slučaj upotrebe
OadrDisReq091214_043740_513
TH_VTN
Event091214_043741_028_0
0
http://MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
daleko
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
JEDNOSTAVNO
nivo
SIG_01
0.0
PT4H
0
0.75
ELECTRICITY_PRICE
cijena
SIG_02
valutaPerKWh
USD
nijedan
0.0
venID_1234
uvijek
Program licitiranja kapaciteta (CBP)
CBP scenario 1 – Jednostavan slučaj upotrebe, A ili B Profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 4 sata
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 1
- Naziv signala: SIMPLE
- Vrsta signala: nivo
- Jedinice: N/A
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 1
- Cilj signala: N/A
- Cilj(i) događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
CBP scenario 2 – Tipičan slučaj upotrebe, B profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 4 sati
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 2
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0,1, 2, 3
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 1 ili 2
- Cilj signala: nema
- Naziv signala: BID_LOAD
- Tip signala: zadana vrijednost
- Jedinice: powerReal
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 20kW do 100kW
- Cilj signala: nema
- Ciljevi događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
CBP scenario 3 – Složen slučaj upotrebe
- Događaj
- Obaveštenje: Dan događaja (koliko sati?)
- Vrijeme početka: 1:XNUMX
- Trajanje: 6 sati
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala:3
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0,1, 2, 3)
- Broj intervala: 2
- Trajanje intervala: 3 sata, 3 sata
- Tipične vrijednosti intervala: 1, 2 (za svaki interval respektivno)
- Cilj signala: nema
- Naziv signala: BID_LOAD
- Tip signala: zadana vrijednost
- Jedinice: powerReal
- Broj intervala 2
- Trajanje intervala: 3 sata, 3 sata
- Tipične vrijednosti intervala: 40kW, 80kW (za svaki interval respektivno)
- Cilj signala: nema
- Naziv signala: BID_PRICE
- Vrsta signala: cijena
- Jedinice: valuta PerKW
- Broj intervala 1
- Trajanje intervala: 6 sata
- Tipične vrijednosti intervala: 3.10 USD
- Cilj signala: nema
- Ciljevi događaja: Resurs_1, Resurs_2, Resurs_3
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- izvještaj(i)
- Naziv izvještaja: TELEMETRY_USAGE
- Vrsta izvještaja: korištenje
- Jedinice: powerReal
- Vrsta čitanja: Direktno čitanje
- Učestalost javljanja: svakih 1 sat
CBP Sample Event Payload – Tipično B Profile Slučaj upotrebe
OadrDisReq091214_043740_513
TH_VTN
Event091214_043741_028_0
0
http://MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
daleko
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
JEDNOSTAVNO
nivo
SIG_01
0.0
PT4H
0
80.0
BID_LOAD
setpoint
SIG_02
RealPower
W
k
60.0
<power:voltage>220.0tage>
istina
0.0
venID_1234
uvijek
Stambeni termostat Scenarij 1 – Jednostavan slučaj upotrebe, A ili B Profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 4 sata
- Slučajni odabir: 10 minuta
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 1
- Naziv signala: SIMPLE
- Vrsta signala: nivo
- Jedinice: N/A
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 1
- Cilj signala: N/A
- Ciljevi događaja: Resurs_1
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
Stambeni termostat Scenarij 2 – Tipičan slučaj upotrebe, B profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 4 sati
- Slučajni odabir: 10 minuta
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 2
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0,1, 2, 3
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 1 ili 2
- Cilj signala: nema
- Naziv signala: LOAD_CONTROL
- Tip signala: x-loadControlLevelOffset
- Jedinice: Temperatura
- Broj intervala 1
- Trajanje intervala: 4 sata
- Tipične vrijednosti intervala: 2 do 6 stepeni Farenhajta
- Cilj signala: nema
- Ciljevi događaja: Resurs_1, Resurs_2
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn, Mogući izlaz (oadrCreateOpt)
- Izvještaji
- Nema
Stambeni termostat Scenarij 3 – Složen slučaj upotrebe
- Događaj
- Obaveštenje: Dan događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 6 sati
- Slučajni odabir: 10 minuta
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala:3
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0,1, 2, 3)
- Broj intervala: 2
- Trajanje intervala: 3 sata, 3 sata
- Tipične vrijednosti intervala: 1, 2 (za svaki interval respektivno)
- Cilj signala: nema
- Naziv signala: BID_LOAD
- Tip signala: x-loadControlCapacity
- Jedinice: Nema
- Broj intervala 2
- Trajanje intervala: 3 sata, 3 sata
- Tipične vrijednosti intervala: 0.9, 0.8 (za svaki interval respektivno)
- Cilj signala: nema
- Ciljevi događaja: Resurs_1, Resurs_2, Resurs_3
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn, Mogući izlaz (oadrCreateOpt)
- izvještaj(i)
- Nema
Stambeni termostat Sample Event Payload – Tipično B Profile Slučaj upotrebe
OadrDisReq091214_043740_513
TH_VTN
Event091214_043741_028_0
0
http://MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
daleko
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT10M
PT24H
PT4H
0
2.0
JEDNOSTAVNO
nivo
SIG_01
0.0
PT4H
0
6.0
LOAD_CONTROL
x-loadControlLevelOffset
SIG_02
temperatura
Fahrenheit
nijedan
0.0
resurs_1
resurs_2
uvijek
Brzi DR Scenarij 1 – Jednostavan slučaj upotrebe, A ili B Profile
- Događaj
- Obavijest: 10 minuta
- Vrijeme početka: 1:XNUMX
- Trajanje: 0 (Otvoreno)
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 1
- Naziv signala: SIMPLE
- Vrsta signala: nivo
- Jedinice: N/A
- Broj intervala 1
- Trajanje intervala: 0 (Otvoreno)
- Tipične vrijednosti intervala: 1
- Cilj signala: N/A
- Cilj(i) događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
Fast DR Scenario 2 – Tipičan slučaj upotrebe, B profile
- Događaj
- Obavijest: 10 minuta
- Vrijeme početka: 1:XNUMX
- Trajanje: 30 minuta
- Randomizacija: nema
- Ramp Gore: 5 minuta
- Oporavak: 5 minuta
- Broj signala: 2
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0,1, 2, 3
- Broj intervala 1
- Trajanje intervala: 30 minuta
- Tipične vrijednosti intervala: 1 ili 2
- Cilj signala: nema
- Naziv signala: LOAD_DISPATCH
- Tip signala: delta
- Jedinice: powerReal
- Broj intervala 1
- Trajanje intervala: 30 minuta
- Tipične vrijednosti intervala: 500 kW do 2mW
- Cilj signala: nema
- Ciljevi događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Naziv izvještaja: TELEMETRY_USAGE
- Vrsta izvještaja: korištenje
- Jedinice: powerReal
- Vrsta čitanja: Direktno čitanje
- Učestalost javljanja: svakih 1 minut
Brzi DR Scenarij 3 – Složen slučaj upotrebe
- Događaj
- Obavijest: 10 minuta
- Vrijeme početka: 1:XNUMX
- Trajanje: 30 minuta
- Randomizacija: nema
- Ramp Gore: 5 minuta
- Oporavak: 5 minuta
- Broj signala:2
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0,1, 2, 3)
- Broj intervala: 2
- Trajanje intervala: 15 minuta, 15 minuta
- Tipične vrijednosti intervala: 1, 2 (za svaki interval respektivno)
- Cilj signala: nema
- Naziv signala: LOAD_DISPATCH
- Tip signala: zadana vrijednost
- Jedinice: powerReal
- Broj intervala 2
- Trajanje intervala: 15 minuta, 15 minuta
- Tipične vrijednosti intervala: 800kW, 900kW (za svaki interval respektivno)
- Cilj signala: nema
- Ciljevi događaja: Resurs_1
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- izvještaj(i)
- Naziv izvještaja: TELEMETRY_USAGE
- Vrsta izvještaja: korištenje
- Jedinice: powerReal i voltage
- Vrsta čitanja: Direktno čitanje
- Učestalost javljanja: svakih 5 sekundi
Brzi DR Sample Event Payload – Tipično B Profile Slučaj upotrebe
OadrDisReq091214_043740_513
TH_VTN
Event091214_043741_028_0
0
http://MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
daleko
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT10M
PT10M
<ei:x-eiRampGore>
PT5M
</ei:x-eiRampGore>
PT5M
PT10M
0
2.0
JEDNOSTAVNO
nivo
SIG_01
0.0
PT10M
0
500.0
LOAD_DISPATCH
delta
SIG_02
RealPower
W
k
60.0
<power:voltage>220.0tage>
istina
0.0
venID_1234
uvijek
Brzi DR Sample Report Metadata Payload – Typical B Profile Slučaj upotrebe
RegReq120615_122508_975
PT10M
rID120615_122512_981_0
resurs1
upotreba
RealEnergy
Wh
k
Direktno čitanje
http://MarketContext1
<oadr:oadrSamplingRate>
PT1M
PT10M
false
</oadr:oadrSamplingRate>
0
ReportSpecID120615_122512_481_2
METADATA_TELEMETRY_USAGE
<ei:createdDateTime>2015-06-12T19:25:12Z</ei:createdDateTime>
ec27de207837e1048fd3
Brzi DR Sample Report Request Payload – Tipično B Profile Slučaj upotrebe
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
Brzi DR Sample Report Data Payload – Tipično B Profile Slučaj upotrebe
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
Kvalitet dobar – nespecifičan
RP_54321
ReportReqID130615_192625_730
ReportSpecID120615_122512_481_2
TELEMETRY_USAGE
<ei:createdDateTime>2015-06-14T02:27:29Z</ei:createdDateTime>
VEN130615_192312_582
Program vremena korištenja stambenih električnih vozila (EV) (TOU).
Imajte na umu da kako program komunicira nivoe tarifa u prilično strukturiranom obliku prikazani su samo jednostavni i tipični slučajevi upotrebe
Rezidencijalni EV scenario 1 – Jednostavan slučaj upotrebe, A ili B Profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: 1:XNUMX
- Trajanje: 24 sata
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 1
- Naziv signala: SIMPLE
- Vrsta signala: nivo
- Jedinice: N/A
- Broj intervala; jednake promjene nivoa TOU za 24 sata (2 – 6)
- Trajanje intervala: aktivni vremenski okvir na nivou TOU (tj. 6 sati)
- Tipične vrijednosti intervala: 0 – 4 mapirano na TOU nivoe
- Cilj signala: N/A
- Cilj(i) događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
Rezidencijalni EV scenario 2 – Tipičan slučaj upotrebe, B profile
- Događaj
- Obavijest: Dan prije događaja
- Vrijeme početka: ponoć
- Trajanje: 24 sati
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 2
- Naziv signala: Simple
- Vrsta signala: nivo
- Jedinice: Nivo 0, 1, 2, 3
- Broj intervala: jednak TOU Promjena nivoa u 24 sata (2 – 6)
- Trajanje intervala: aktivni vremenski okvir na nivou TOU (tj. 6 sati)
- Tipične vrijednosti intervala: 0 – 4 mapirano na TOU nivoe (0 – najjeftiniji nivo)
- Cilj signala: nema
- Naziv signala: ELECTRICITY_PRICE
- Vrsta signala: cijena
- Jedinice: USD po Kwh
- Broj intervala: jednake promjene nivoa TOU u 24 sata (2 – 6)
- Trajanje intervala: aktivni vremenski okvir na nivou TOU (tj. 6 sati)
- Tipične vrijednosti intervala: $0.10 do $1.00 (trenutni nivo)
- Cilj signala: nema
- Ciljevi događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
Stambeni EV Sample Event Payload – Tipično B Profile Slučaj upotrebe
OadrDisReq091214_043740_513
TH_VTN
Event091214_043741_028_0
0
http://MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
daleko
<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
JEDNOSTAVNO
nivo
SIG_01
0.0
PT5H
0
0.35
PT7H
1
0.55
PT7H
2
0.75
PT5H
3
0.55
ELECTRICITY_PRICE
cijena
SIG_02
valutaPerKWh
USD
nijedan
0.0
venID_1234
uvijek
Program određivanja cijena u realnom vremenu za električna vozila javnih stanica (EV).
Imajte na umu da kako je ovo program za određivanje cijena u stvarnom vremenu, zaista nema razlike između jednostavnog, tipičnog i složenog slučaja upotrebe. Stoga sample podaci će biti prikazani samo za tipičan slučaj upotrebe.
Javna stanica EV Scenarij 1 – Tipičan slučaj upotrebe, B profile
- Događaj
- Obavijest: 1 sat unaprijed
- Vrijeme početka: 1:XNUMX
- Trajanje: 1 sati
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 1
- Naziv signala: ELECTRICITY_PRICE
- Vrsta signala: cijena
- Jedinice: USD po Kwh
- Broj intervala 1
- Trajanje intervala: 1 sata
- Tipične vrijednosti intervala: $0.10 do $1.00
- Cilj signala: nema
- Ciljevi događaja: venID_1234
- Prioritet: 1
- Potreban VEN odgovor: uvijek
- VEN Očekivani odgovor: optIn
- Izvještaji
- Nema
Javna stanica EV Sample Event Payload – Tipično B Profile Slučaj upotrebe
OadrDisReq091214_043740_513
TH_VTN
Event091214_043741_028_0
0
http://MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
daleko
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT1H
PT1H
PT1H
0
0.75
ELECTRICITY_PRICE
cijena
SIG_01
valutaPerKWh
USD
nijedan
0.0
venID_1234
uvijek
Distributed Energy Resources (DER) DR Program
Imajte na umu da kako je ovo program za određivanje cijena u stvarnom vremenu, zaista nema razlike između jednostavnog, tipičnog i složenog slučaja upotrebe. Stoga sample podaci će biti prikazani samo za tipičan slučaj upotrebe.
Javna stanica EV Scenarij 1 – Tipičan slučaj upotrebe, B profile
- Događaj
- Obavijest: Dan unaprijed
- Vrijeme početka: ponoć
- Trajanje: 24 sati
- Randomizacija: nema
- Ramp Gore: Nema
- Oporavak: nema
- Broj signala: 24
- Naziv signala: ELECTRICITY_PRICE
- Vrsta signala: cijena
- Jedinice: USD po Kwh
- Broj intervala 1
- Trajanje intervala: 1 sata
- Tipične vrijednosti intervala: $0.10 do $1.00
- Cilj signala: nema
- Ciljevi događaja: venID_1234
- Prioritet: 1
- VEN Potreban odgovor: nikad
- VEN Očekivani odgovor: n/a
- Izvještaji
- Nema
Javna stanica EV Sample Event Payload – Tipično B Profile Slučaj upotrebe
OadrDisReq091214_043740_513
TH_VTN
Event091214_043741_028_0
0
http://MarketContext1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
daleko
<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>
PT24H
PT24H
PT1H
0
0.75
PT1H
1
0.80
ELECTRICITY_PRICE
cijena
SIG_01
valutaPerKWh
USD
nijedan
0.0
venID_1234
nikad
– Prample Reports from Utility Pilots
Članovi OpenADR Alijanse su obezbedili sledeće B Profile oadrUpdateReport nosivost sampdatoteke iz komunalnih pilot programa u kojima su njihovi VEN-ovi bili raspoređeni. Sljedeće bilješke su pratile tri korisna tereta samppruženo:
Termostat Korisno opterećenje Cilj:
- Potrebno je znati status termostata (temperatura, zadane vrijednosti, stanja ventilatora i načina rada)
- Ako je uključeno, da li je kupac promijenio postavke termostata (poruke o ručnom poništavanju)
M&V za rabate Cilj opterećenja:
- Status resursa i ručno nadjačavanje u slučaju uključivanja
- Podaci o intervalima iz KYZ pulsnog brojača ili monitora energije za ukupnu energiju u KWH i trenutnu potražnju u KW
Smart Meter/AMI Interval Data Payload Cilj:
- Interval očitavanja AMI mjerača je oko 15 minuta do 1 sat. Iako koristan, nije dovoljno precizan za procjene naplate u skoro realnom vremenu
- Ukupna energija u KWH, delta energija u KWH, trenutna potražnja u KW
Sljedeći prefiksi prostora imena se koriste u korisnom učitavanju examples:
- xmlns:oadr=”http://openadr.org/oadr-2.0b/2012/07″
- xmlns:pyld=”http://docs.oasis-open.org/ns/energyinterop/201110/payloads”
- xmlns:ei=”http://docs.oasis-open.org/ns/energyinterop/201110″
- xmlns:scale=”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
- xmlns:emix=”http://docs.oasis-open.org/ns/emix/2011/06″
- xmlns:strm=”urn:ietf:params:xml:ns:icalendar-2.0:stream”
- xmlns:xcal=”urn:ietf:params:xml:ns:icalendar-2.0″
- xmlns:power=”http://docs.oasis-open.org/ns/emix/2011/06/power”
Termostat Izvještaj Korisno opterećenje 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
istina
false
0
Nema nove vrijednosti – korištena je prethodna vrijednost
Trenutna temp
77.000000
Nema nove vrijednosti – korištena je prethodna vrijednost
Postavka temperature grijanja
64.000000
Nema nove vrijednosti – korištena je prethodna vrijednost
Cool Temp Setting
86.000000
Nema nove vrijednosti – korištena je prethodna vrijednost
Podešavanje HVAC režima
3
Nema nove vrijednosti – korištena je prethodna vrijednost
Trenutni HVAC način rada
0.000000
Nema kvalitete – nema vrijednosti
Podešavanje načina rada ventilatora
2
Nema nove vrijednosti – korištena je prethodna vrijednost
Current Hold Mode
2
Nema nove vrijednosti – korištena je prethodna vrijednost
Trenutni način rada u gostima
0
Nema nove vrijednosti – korištena je prethodna vrijednost
Trenutna vlažnost
0.000000
Nema kvalitete – nema vrijednosti
RP21
REQ:RReq:1395368583267
0013A20040980FAE
TELEMETRY_STATUS
<ei:createdDateTime>2014-03-21T02:26:04Z</ei:createdDateTime>
VEN.ID:1395090780716
M&Vfor Rebates Izvještaj Korisno opterećenje Sample
RUP-10
<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>
PT30S
<xcal:date-time>2015-08-21T17:41:14Z</xcal:date-time>
PT30S
Status
istina
false
Kvalitet dobar – nespecifičan
Pulse Count
34750.000000
Kvalitet dobar – nespecifičan
Energija
33985.500000
Kvalitet dobar – nespecifičan
Snaga
1.26
Kvalitet dobar – nespecifičan
RP15
REQ:RReq:10453335019195698
0000000000522613 60
TELEMETRY_USAGE
<ei:createdDateTime>2015-08-21T17:41:50Z</ei:createdDateTime>
VEN.ID:1439831430142
Smart Meter/AMI Interval Data Report Korisno opterećenje 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
Nema nove vrijednosti – korištena je prethodna vrijednost
intervalDataDelivered
0.051000
Nema nove vrijednosti – korištena je prethodna vrijednost
currSumDelivered
12172.052000
Nema nove vrijednosti – korištena je prethodna vrijednost
<xcal:date-time>2014-09-10T06:27:07Z</xcal:date-time>
PT15S
instantaneousDemand
6.114000
Nema nove vrijednosti – korištena je prethodna vrijednost
intervalDataDelivered
0.051000
Nema nove vrijednosti – korištena je prethodna vrijednost
currSumDelivered
12172.052000
Nema nove vrijednosti – korištena je prethodna vrijednost
<xcal:date-time>2014-09-10T06:27:22Z</xcal:date-time>
PT15S
instantaneousDemand
6.113000
Nema nove vrijednosti – korištena je prethodna vrijednost
intervalDataDelivered
0.051000
Nema nove vrijednosti – korištena je prethodna vrijednost
currSumDelivered
12172.142000
Nema nove vrijednosti – korištena je prethodna vrijednost
<xcal:date-time>2014-09-10T06:27:37Z</xcal:date-time>
PT15S
instantaneousDemand
6.112000
Nema nove vrijednosti – korištena je prethodna vrijednost
intervalDataDelivered
0.051000
Nema nove vrijednosti – korištena je prethodna vrijednost
currSumDelivered
12172.142000
Nema nove vrijednosti – korištena je prethodna vrijednost
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 podržava sljedeće usluge:
- EiEvent Service – Koriste ga VTN-ovi za slanje događaja odgovora na potražnju VEN-ovima, a koriste ga VEN-ovi da naznače da li će resursi učestvovati u događaju. Jedina usluga koju podržava A profile je EiEvent
- EiReport Service – Koriste ga VEN-ovi i VTN-ovi za razmjenu historijskih izvještaja, izvještaja o telemetriji i prognozama
- EiOpt usluga – Koristi ga VEN za priopćavanje privremenog rasporeda dostupnosti VTN-ovima ili za kvalifikaciju resursa koji učestvuju u događaju
- EiRegisterParty Service – Iniciran od strane VEN-a, a koriste ga i VEN i VTN za razmjenu informacija potrebnih za osiguranje interoperabilne razmjene tereta
- OadrPoll Service – Koriste ga VEN-ovi za anketiranje VTN-a za korisne terete iz bilo koje druge usluge
A i B profile operacije usluge su definirane korijenskim elementom svakog korisnog opterećenja, isključujući omote oadrPayload i oadrSignedObject koji se koriste na svim B profile nosivosti.
- oadrRequestEvent – Koristi se u modelu razmjene povlačenja od strane VEN za preuzimanje svih relevantnih događaja iz VTN-a. Koristi se kao primarni mehanizam glasanja za A profile VEN, ali se koristi samo na B VEN-ovima za sinhronizaciju sa VTN-om.
- oadrDistributeEvent – Koristi VTN za isporuku događaja odgovora na potražnju VEN-u
- oadrCreatedEvent – Koristi se od strane VEN-a da saopšti da li namerava da učestvuje u događaju tako što će se uključiti ili odjaviti
- oadrResponse – Koristi VTN za potvrdu prijema optIn ili optOut od VEN
Imajte na umu da i VEN i VTN mogu biti i proizvođači izvještaja i zahtjevi za izvještaje, tako da sve dolje navedene korisne podatke može pokrenuti bilo koja strana.
- oadrRegisterReport – Koristi se za objavljivanje svojih mogućnosti izvještavanja u izvještaju o metapodacima
- oadrRegisteredReport -Potvrdite prijem oadrRegisterReporta, po želji zatražite jedan od ponuđenih izvještaja
- oadrCreateReport – Koristi se za traženje izvještaja koji je prethodno ponudio VEN ili VTN
- oadrCreatedReport – Potvrdite prijem zahtjeva za izvještaj
- oadrUpdateReport -Dostaviti traženi izvještaj koji sadrži intervalne podatke
- oadrUpdatedReport – Potvrdite prijem dostavljenog izvještaja
- oadrCancelReport – Otkažite prethodno traženi periodični izvještaj
- oadrCanceledReport – Potvrdite otkazivanje periodičnog izvještaja
- oadrResponse – Koristi se kao odgovor za čuvanje mjesta u nekim obrascima razmjene povlačenja kada se odgovor sloja aplikacije isporučuje u zahtjevu transportnog sloja.
- oadrCreateOpt – Koristi se u dvije potpuno različite svrhe
- Da VEN VTN-u prenese raspored privremene dostupnosti u vezi sa njegovom sposobnošću da učestvuje u DR događajima
- Da VEN kvalifikuje resurse koji učestvuju u događaju
- oadrCreatedOpt – Potvrdite prijem oadrCreateOpt korisnog opterećenja
- oadrCancelOpt -Otkažite raspored privremene dostupnosti
- oadrCanceledOpt – Potvrdite otkazivanje izvještaja o privremenoj dostupnosti
- oadrQueryRegistration – Način na koji VEN traži informacije o registraciji VTN-a bez stvarne registracije.
- oadrCreatePartyRegistration – Zahtjev od VEN do VTN za registraciju. Sadrži informacije o mogućnostima VEN-a.
- oadrCreatedPartyRegistration – Odgovor na oadrQueryRegistration ili na oadrCreatePartyRegistration. Sadrži VTN mogućnosti i informacije o registraciji koje su potrebne da VEN interoperira
- oadrCancelPartyRegistration – Koristi ga ili VEN ili VTN za otkazivanje registracije
- oadrCanceledPartyRegistration – Odgovor na oadrCancelPartyRegistration. Potvrđuje prijem otkazivanja registracije
- oadrRequestReregistration – Ovo korisno opterećenje koristi VTN u modelu razmjene povlačenja da signalizira VEN-u da ponovo pokrene sekvencu registracije
- oadrResponse – Koristi se kao odgovor za čuvanje mjesta u nekim obrascima razmjene povlačenja kada se odgovor sloja aplikacije isporučuje u zahtjevu transportnog sloja.
- oadrPoll – Generički mehanizam za biranje za B profile koji vraća teret za bilo koju drugu uslugu koja je nova ili je ažurirana.
- oadrResponse – Koristi se za označavanje da nema dostupnih novih ili ažuriranih korisnih opterećenja
– Pojmovnik elemenata korisnog opterećenja sheme
Slijedi abecedni popis elemenata sheme koji se koriste u OpenADR 2.0 korisnim učitavanjima. Narativ opisuje njihovu upotrebu kako se odnosi na OpenADR i njihovu upotrebu u korisnim opterećenjima. Kada se definicija elementa promijeni na osnovu korisnog opterećenja u kojem je sadržan ili njegovog konteksta upotrebe, to će biti zabilježeno u narativu. Korijenske definicije korisnog opterećenja su isključene jer su definirane u Aneksu C.
- ac – Boolean vrijednost koja pokazuje da li je proizvod naizmjenične struje
- tačnost - Broj je u istim jedinicama kao varijabla korisnog opterećenja za Interval. Kada je prisutan sa Pouzdanjem, ukazuje na verovatnu varijabilnost predviđanja. Kada je prisutan sa ReadingType, ukazuje na vjerovatnu grešku čitanja.
- agregiraniPnode – Čvor agregiranih cijena je specijalizirani tip cjenovnog čvora koji se koristi za modeliranje stavki kao što su sistemska zona, zona zadane cijene, zona prilagođenih cijena, kontrolno područje, agregirana generacija, agregirano opterećenje, agregirano opterećenje bez učešća, trgovačko središte, zona DCA
- dostupan – Objekt koji sadrži datum-vrijeme i trajanje za EiOpt raspored dostupnosti
- osnovni ID – Jedinstveni ID za određenu osnovnu liniju
- baselineName – Opisno ime za osnovnu liniju
- komponente –
- samopouzdanje – Statistička vjerovatnoća da je prijavljena tačka podataka tačna
- createdDateTime – Datum i vrijeme kada je korisni teret kreiran
- valuta –
- valutaPerKW –
- valutaPerKWh –
- valutaPerThm –
- struja –
- currentValue – PayloadFloat vrijednost intervala događaja koji se trenutno izvršava.
- customUnit – Koristi se za definiranje prilagođene jedinice mjere za prilagođene izvještaje
- datum-vrijeme –
- dtstart – Vrijeme početka promjene aktivnosti, podataka ili stanja
- trajanje – Vremenski period za događaj, izvještavanje ili vremenski interval dostupnosti
- trajanje - Trajanje aktivnosti, podataka ili stanja
- eiActivePeriod – Vremenski okviri relevantni za cjelokupni događaj
- eiCreatedEvent – Odgovorite na DR događaj sa optIn ili optOut
- eiEvent -Objekat koji sadrži sve informacije za jedan događaj
- eiEventBaseline – B profile
- eiEventSignal – Objekt koji sadrži sve informacije za jedan signal u događaju
- eiEventSignals – Podaci o intervalima za jedan ili više signala događaja i/ili osnovnih linija
- eiMarketContext – URI koji jedinstveno identifikuje program odgovora na potražnju
- eiReportID – Referentni ID za izvještaj
- eiRequestEvent – Zatražite događaj od VTN-a u načinu povlačenja
- eiResponse – Navedite da li je primljeni teret prihvatljiv
- eiTarget – Identificira resurse povezane s logičkim VEN sučeljem. Za događaje, specificirane vrijednosti su cilj za događaj
- endDeviceAsset – EndDeviceAssets su fizički uređaj ili uređaji koji mogu biti brojila ili drugi tipovi uređaja koji mogu biti od interesa
- prividna energija – Prividna energija, mjerena u volt-ampprije sati (VAh)
- energyItem –
- energetska reaktivna – Reaktivna energija, volt-amperes reaktivni sati (VARh)
- energyReal – Stvarna energija, vat sati (Wh)
- deskriptor događaja – Informacije o događaju
- eventID – Vrijednost ID-a koja identificira specifičnu instancu DR događaja.
- eventResponse – Objekt koji sadrži VENs odgovor na zahtjev za učešće u događaju
- eventResponses – optIn ili optOut odgovori za primljene događaje
- eventStatus – Trenutni status događaja (daleko, blizu, aktivan, itd.)
- FeatureCollection/Location/Polygon/Exterior/LinearRing
- frekvencija –
- granularnost – Ovo je vremenski interval između sampvodi podatke u zahtjevu za izvještaj.
- ID grupe -Ova vrsta cilja se koristi za događaje, izvještaje i opt rasporede. Vrijednost bi obično dodijelio uslužni program tokom upisa u DR program
- groupName – Ova vrsta cilja se koristi za događaje, izvještaje i rasporede opcija. Vrijednost bi obično dodijelio uslužni program tokom upisa u DR program
- herca –
- interval – Objekat koji sadrži podatke-vrijeme i/ili trajanje, i radnji vrijednost u slučaju događaja ili podatke u slučaju izvještaja
- intervali - Jedan ili više vremenskih intervala tokom kojih je DR događaj aktivan ili su podaci izvještaja dostupni
- Opis artikla – Opis jedinice mjere u izvještaju
- itemUnits – Osnovna jedinica mjere za tačku podataka izvještaja
- marketContext – URI koji identificira DR program
- meterAsset – MeterAsset je fizički uređaj ili uređaji koji obavljaju ulogu mjerača
- modificationDateTime – Kada je događaj izmijenjen
- broj modifikacije – Povećava se svaki put kada se događaj promijeni.
- Razlog izmjene – Zašto je događaj izmijenjen
- mrid – mRID identifikuje fizički uređaj koji može biti CustomerMeter ili druge vrste krajnjih uređaja.
- čvor – Čvor je mjesto gdje se nešto mijenja (često vlasništvo) ili povezuje na mreži. Mnogi čvorovi su povezani s brojilima, ali nisu svi.
- numDataSources –
- oadrCapacity –
- oadrCurrent –
- oadrDataQuality –
- oadrDeviceClass – Cilj klase uređaja – koristite samo endDeviceAsset.
- oadrEvent – Objekt koji sadrži događaj odgovora na zahtjev
- oadrExtension –
- oadrExtensionName –
- oadrExtensions –
- oadrHttpPullModel – Boolean koji pokazuje da li VEN želi koristiti model razmjene povlačenja
- oadrInfo – Par ključnih vrijednosti registracijskih informacija specifičnih za uslugu
- oadrKey –
- oadrLevelOffset –
- oadrLoadControlState –
- oadrManualOverride – Ako je istina, onda je kontrola opterećenja ručno nadjačana
- oadrMax –
- oadrMaxPeriod – Maksimum sampling period
- oadrMin –
- oadrMinPeriod – Minimalno sampling period
- oadrNormal –
- oadrOnChange – Ako je istinito, podaci će biti zabilježeni kada se promijene, ali ne većom frekvencijom od one koju je specificirao minPeriod.
- oadrOnline – Ako je tačno, onda je resurs/sredstvo na mreži, ako je netačno onda je van mreže.
- oadrPayload –
- oadrPayloadResourceStatus – Informacije o trenutnom statusu resursa
- oadrPendingReports – Lista periodičnih izvještaja i dalje aktivnih
- oadrPercentOffset –
- oadrProfile – zafile podržava VEN ili VTN
- oadrProfileIme – OpenADR profile naziv kao što je 2.0a ili 2.0b.
- oadrProfiles – OpenADR profilepodržano implementacijom
- oadrReport -Objekat koji sadrži sve informacije za jedan izvještaj
- oadrReportDescription – Opis karakteristika izvještaja koje nudi proizvođač izvještaja. Sadržano u izvještaju o metapodacima
- oadrReportOnly – ReportOnlyDeviceFlag
- oadrReportPayload – Vrijednosti tačaka podataka za izvještaje
- oadrRequestedOadrPollFreq – VEN će poslati oadrPoll korisni teret VTN-u najviše jednom za svako trajanje određeno ovim elementom
- oadrResponseRequired – Kontrolira kada je potreban optIn/optOut odgovor. Može biti uvijek ili nikad
- oadrSamplingRate – Sampling rate za podatke tipa telemetrije
- oadrService –
- oadrServiceName – Ova vrsta cilja se koristi za događaje, izvještaje i rasporede opcija. Vrijednost bi obično dodijelio uslužni program tokom upisa u DR program
- oadrServiceSpecificInfo – Informacije o registraciji specifične za uslugu
- oadrSetPoint –
- oadrSignedObject –
- oadrTransport – Naziv transporta koji podržava VEN ili VTN
- oadrTransportAddress – Korijenska adresa koja se koristi za komunikaciju sa drugom stranom. Treba uključiti port ako je potrebno
- oadrTransportName – OpenADR transportno ime kao što je simpleHttp ili xmpp
- oadrTransports – OpenADR transporti podržani implementacijom
- oadrUpdatedReport – Potvrdite prijem izvještaja
- oadrUpdateReport – Pošaljite prethodno traženi izvještaj
- oadrValue –
- oadrVenName – VEN ime. Može se koristiti u VTN GUI
- oadrXmlSignature – Implementacija podržava XML potpis
- optID – Identifikator za opt interakciju
- optReason – Nabrojana vrijednost za razlog izbora kao što je x-raspored
- optType – optIn ili optOut od događaja, ili se koristi za označavanje tipa opt rasporeda definiranog u vavailablityObject za EiOpt uslugu
- partyID – Ova vrsta cilja se koristi za događaje, izvještaje i rasporede opcija. Vrijednost bi obično dodijelio uslužni program tokom upisa u DR program
- nosivostFloat – Vrijednost točke podataka za signale događaja ili za izvještavanje o trenutnim ili povijesnim vrijednostima.
- pnode – Čvor cijena je direktno povezan s čvorom povezivanja. To je lokacija za utvrđivanje cijena za koju učesnici na tržištu podnose svoje ponude, ponude, kupuju/prodaju CRR-ove i podmiruju se.
- pointOfDelivery –
- pointOfReceipt –
- posList –
- powerApparent – Prividna snaga mjerena u volt-amperes (VA)
- powerAttributes
- powerItem
- powerReactive – Reaktivna snaga, mjerena u volt-amperes reactive (VAR)
- powerReal – Stvarna snaga mjerena u vatima (W) ili džulima/sekundi (J/s)
- prioritet - Prioritet događaja u odnosu na druge događaje (Što je manji broj veći je prioritet. Vrijednost nula (0) označava da nema prioriteta, što je po defaultu najniži prioritet).
- svojstva –
- pulseCount – Tačka podataka za izvještavanje
- faktor pulsa – kWh po broju
- qualifiedEventID – Jedinstveni ID za događaj
- Vrsta čitanja – Metapodaci o očitanjima, kao što su srednja vrijednost ili izvedeni
- registracijski ID – Identifikator za transakciju registracije. Nije uključeno u odgovor na registraciju upita osim ako je već registrovano
- replyLimit – Maksimalni broj događaja za vraćanje u oadrDistributeEvent korisnom učitavanju
- reportBackDuration – Izvještavajte sa izvještajem do datuma za svaki prolazak ovog trajanja.
- reportDataSource – Izvori podataka u ovom izvještaju. PrampUključuju metre ili podmetre. Za nprampAko je mjerač sposoban da pruži dvije različite vrste mjerenja, onda bi svaki mjerni tok bio zasebno identificiran.
- reportInterval – Ovo je cjelokupni period izvještavanja.
- reportName – Opcijski naziv za izvještaj.
- reportRequestID – Identifikator za određeni zahtjev za izvještaj
- reportSpecifier – Navedite željene tačke podataka u određenoj instanci izvještaja
- reportSpecifierID – Identifikator za određenu specifikaciju izvještaja o metapodacima
- Predmet izvještaja – Cilj klase uređaja – koristite samo endDeviceAsset.
- reportToFollow – Označava da li će se izvještaj (u obliku UpdateReport-a) vratiti nakon otkazivanja izvještaja
- reportType – Vrsta izvještaja kao što je upotreba ili cijena
- ID zahtjeva – ID koji se koristi za usklađivanje zahtjeva za logičku transakciju i odgovora
- ID resursa – Ova vrsta cilja se koristi za događaje, izvještaje i rasporede opcija. Vrijednost bi obično dodijelio uslužni program tokom upisa u DR program
- odgovor –
- responseCode – 3-cifreni kod odgovora
- odgovorOpis – Narativni opis statusa odgovora
- odgovore –
- rID – ReferenceID za ovu tačku podataka
- serviceArea – Ova vrsta cilja se koristi za događaje, izvještaje i rasporede opcija. Vrijednost bi obično dodijelio uslužni program tokom upisa u DR program
- serviceDeliveryPoint – Logična tačka na mreži gde vlasništvo nad servisom prelazi u ruke. To je jedna od potencijalno mnogih servisnih tačaka unutar ServiceLocation, koja pruža uslugu u skladu sa Ugovorom o korisniku. Koristi se na mjestu gdje se može instalirati mjerač.
- lokacija usluge – Korisnička ServiceLocation ima jednu ili više ServiceDeliveryPoint(a), koje se zauzvrat odnose na brojila. Lokacija može biti tačka ili poligon, ovisno o specifičnim okolnostima. Za distribuciju, ServiceLocation je obično lokacija prostorija korisnika komunalnih usluga.
- signalID – jedinstveni identifikator za određeni signal događaja
- signalName – Naziv signala kao što je SIMPLE
- signalPayload – Vrijednosti signala za događaje i osnovne linije
- siScaleCode – Faktor skaliranja za osnovnu jedinicu mjere za izvještaj
- specificerPayload – Otvoreno
- startafter – Prozor slučajnog odabira za početak događaja
- statusDateTime – Datum i vrijeme na koje se ovaj artefakt odnosi.
- temperaturu –
- testEvent – Sve osim netačno ukazuje na testni događaj
- tekst –
- Therm –
- tolerancija - Podobjekat koji sadrži zahtjeve za slučajni odabir događaja
- tolerisati – Objekt koji sadrži zahtjeve randomizacije za događaj
- transportno sučelje – Transportni interfejs ocrtava ivice na oba kraja transportnog segmenta.
- uid – Koristi se kao indeks za identifikaciju intervala. Jedinstveni identifikator
- vrijednost –
- dostupnost - Raspored koji odražava dostupnost uređaja za učešće u DR događajima
- venID – Jedinstveni identifikator za VEN
- voltage –
- vtnComment – Bilo koji tekst
- vtnID – Jedinstveni identifikator za VTN
- x-eiNotification – VEN bi trebao primiti korisni teret DR događaja prije dtstart minus ovo trajanje.
- x-eiRampgore – Trajanje prije ili nakon početka događaja tokom kojeg bi tovarni prostor trebao proći.
- x-eiRecovery – Trajanje prije ili nakon vremena završetka događaja tokom kojeg bi rasterećenje trebalo proći.
Pojmovnik nabrojanih vrijednosti
- aktivan – Događaj je pokrenut i trenutno je aktivan.
- otkazan – Događaj je otkazan.
- završeno – Događaj je završen.
- daleko – Događaj na čekanju u dalekoj budućnosti. Tačna definicija koliko daleko u budućnosti se ovo odnosi ovisi o kontekstu tržišta, ali obično znači sljedeći dan.
- blizu – Događaj na čekanju u bliskoj budućnosti. Tačna definicija koliko je blizu u budućnosti aktivan događaj na čekanju zavisi od konteksta tržišta. .Počinje istovremeno sa efektivnim početkom događaja x-eiRampUp time. Ako je x-eiRampGore nije definirano za događaj, ovaj status se neće koristiti za događaj.
- nijedan – Nema događaja na čekanju
- Valuta
- USD – američki dolar
- Mnogima da se ovdje navedu, pogledajte šemu
- powerReal
- J/s – Džul-sekunda
- W – Watts
- temperaturu
- celzijusa –
- Fahrenheit –
- Nema nove vrijednosti – korištena je prethodna vrijednost –
- Nema kvalitete – nema vrijednosti –
- Kvalitet loš – neuspjeh komunikacije –
- Kvaliteta loša – greška u konfiguraciji –
- Kvalitet loš – kvar uređaja –
- Kvalitet loš – posljednja poznata vrijednost –
- Kvalitet loš – nespecifičan –
- Kvalitet loš – nije povezan –
- Kvalitet loš – van usluge –
- Kvalitet loš – kvar senzora –
- Kvalitet dobar – Lokalno preklapanje –
- Kvalitet dobar – nespecifičan –
- Granica kvaliteta – polje/konstanta –
- Granica kvaliteta – polje/visoka –
- Granica kvaliteta – polje/niska –
- Ograničenje kvaliteta – polje/ne –
- Kvalitet neizvjestan – EU jedinice premašene –
- Kvaliteta neizvjesna – posljednja upotrebljiva vrijednost –
- Kvaliteta neizvjesna – nespecifična –
- Kvaliteta nije sigurna – senzor nije tačan –
- Kvaliteta neizvjesna – ispod normalnog –
- uvijek – Uvijek pošaljite odgovor za svaki primljeni događaj.
- nikad – Nikada ne odgovaraj.
Nabrojani razlozi za izbor.
- ekonomski –
- hitan slučaj –
- mustRun –
- notParticipating –
- outageRunStatus –
- overrideStatus –
- učestvujući –
- x-raspored –
- simpleHttp –
- xmpp –
- optIn – Indikacija da će VEN sudjelovati u događaju, ili u slučaju EiOpt usluge tip rasporeda koji ukazuje da će resurs biti dostupan
- optOut – Indikacija da VEN neće učestvovati u događaju, ili u slučaju EiOpt usluge tip rasporeda koji ukazuje da resurs neće biti dostupan
- Dodijeljeno – Merač pokriva nekoliko [resursa] i upotreba se zaključuje kroz neku vrstu proračuna profesionalnih podataka.
- Ugovor – Označava da je čitanje pro forma, odnosno da se izvještava po dogovorenim stopama
- Izvedeno – Upotreba se zaključuje kroz poznavanje vremena rada, normalnog rada itd.
- Direktno čitanje – Očitavanje se očitava sa uređaja koji se monotono povećava, a korištenje se mora izračunati iz parova očitavanja početka i zaustavljanja.
- Procijenjeno – Koristi se kada očitavanje nema u nizu u kojem je prisutna većina očitanja.
- Hibrid – Ako je agregirano, odnosi se na različite vrste očitavanja u zbirnom broju.
- Zlo – Očitavanje je srednja vrijednost tokom perioda naznačenog u Granularnosti
- Net – Mjerač ili [resurs] priprema vlastiti proračun ukupne potrošnje tokom vremena.
- Peak – Očitavanje je vršna (najviša) vrijednost tokom perioda naznačenog u granularnosti. Za neka mjerenja može imati više smisla kao najniža vrijednost. Možda nije u skladu sa zbirnim očitanjima. Vrijedi samo za baze stavki brzine protoka, tj. Snaga ne energija.
- Projektovano – Označava da je očitavanje u budućnosti i još nije izmjereno.
- Summed – Nekoliko metara zajedno daje očitavanje za ovaj [izvor]. Ovo se posebno razlikuje od agregiranog, što se odnosi na višestruke [resurse] u istom korisnom učitavanju. Vidi također Hibrid.
- x-notApplicable - Nije primjenjivo
- x-RMS – Srednji kvadrat
- HISTORY_GREENBUTTON – Izvještaj koji sadrži podatke zelenog dugmeta u strukturi šeme atomskog feeda
- HISTORY_USAGE – Izvještaj koji sadrži povijesne podatke o korištenju energije
- METADATA_HISTORY_GREENBUTTON – Izvještaj o metapodacima koji definira mogućnosti izvještavanja za HISTORY_GREENBUTTON izvještaje
- METADATA_HISTORY_USAGE – Izvještaj o metapodacima koji definira mogućnosti izvještavanja za HISTORY_USAGE izvještaje
- METADATA_TELEMETRY_STATUS – Izvještaj o metapodacima koji definira mogućnosti izvještavanja za TELEMETRY_STATUS izvještaje
- METADATA_TELEMETRY_USAGE – Izvještaj o metapodacima koji definira mogućnosti izvještavanja za TELEMETRY_USAGE izvještaje
- TELEMETRY_STATUS – Izvještaj koji sadrži informacije o statusu resursa u realnom vremenu kao što je stanje na mreži
- TELEMETRY_USAGE – Izvještaj koji sadrži informacije o potrošnji energije u realnom vremenu
Nabrojana vrijednost koja daje tip izvještaja koji se daje.
- availableEnergyStorage – Kapacitet dostupan za dalje skladištenje energije, možda da se dođe do Target Energy Storage
- avgDemand – Prosječna upotreba tokom trajanja označenog Granularnošću. Pogledajte potražnju za više informacija.
- avgUsage – Prosječna upotreba tokom trajanja označenog Granularnošću. Pogledajte upotrebu za više informacija.
- osnovna linija – Može biti potražnja ili upotreba, kako je naznačeno ItemBase-om. Označava šta bi [mjerenje] bilo da nije bilo događaja ili propisa. Izvještaj je u formatu Baseline.
- deltaDemand – Promjena potražnje u odnosu na osnovnu liniju. Pogledajte potražnju za više informacija
- deltaSetPoint – Promjene zadane vrijednosti u odnosu na prethodni raspored.
- deltaUsage – Promjena upotrebe u odnosu na osnovnu liniju. Za više informacija pogledajte upotrebu
- potražnja – Izvještaj označava količinu jedinica (denominiranih u ItemBase ili u EMIX proizvodu). Vrsta nosivosti je Količina. Tipična ItemBase je Real Power.
- odstupanje – Razlika između neke upute i stvarnog stanja.
- downRegulationCapacityAvailable – Kapacitet Down Regulation dostupan za otpremu, izražen u EMIX Real Power. Nosivost se uvijek izražava kao pozitivna količina.
- nivo – Jednostavan nivo sa tržišta u svakom intervalu.
- operativnaState – Generalno stanje resursa kao što je uključeno/isključeno, zauzetost zgrade, itd. No ItemBase nije relevantno. Zahtijeva proširenje korisnog opterećenja specifičnog za aplikaciju.
- procenat potražnje – Percentage potražnje
- postotak upotrebe – Percentage upotrebe
- powerFactor – Faktor snage za resurs
- cijena – Cijena po predmetnoj bazi u svakom intervalu
- čitanje – Izveštaj pokazuje očitanje, kao sa brojila. Očitavanja su momenti u vremenskim promjenama tokom vremena koji se mogu izračunati iz razlike između uzastopnih očitavanja. Tip nosivosti je plutajući
- RegulationSetpoint – Regulaciona zadana vrijednost prema uputama kao dio usluga regulacije
- setPoint – Izvještaj pokazuje iznos (denominiran u ItemBase ili u EMIX proizvodu) trenutno postavljen. Može biti potvrda/povrat kontrolne vrijednosti zadane vrijednosti poslane iz VTN-a. Vrsta nosivosti je Količina. Tipična ItemBase je Real Power.
- storedEnergy – Pohranjena energija se izražava kao stvarna energija, a nosivost je izražena kao količina.
- targetEnergyStorage – Ciljna energija je izražena kao stvarna energija, a nosivost je izražena kao količina.
- upRegulationCapacityAvailable – Up Regulacioni kapacitet dostupan za otpremu, izražen u EMIX Real Power. Nosivost se uvijek izražava kao pozitivna količina.
- upotreba – Izvještaj ukazuje na količinu jedinica (denominiranih u ItemBase ili u EMIX proizvodu) tokom perioda. Vrsta nosivosti je Količina. Tipična ItemBase je RealEnergy
- x-resourceStatus – Percentage potražnje
- p – Pico 10**-12
- n – Nano 10**-9
- mikro – Mikro 10**-6
- m – Milli 10**-3
- c – Centi 10**-2
- d – Deci 10**-1
- k – Kilogram 10**3
- M – Mega 10**6
- G – Giga 10**9
- T – Tera 10**12
- nijedan – Native Scale
- BID_ENERGY – Ovo je količina energije iz resursa koja je licitirana u program
- BID_LOAD – Ovo je količina opterećenja koju je resurs ponudio u program
- BID_PRICE – Ovo je cijena koju je ponudio resurs
- CHARGE_STATE – Stanje resursa za skladištenje energije
- DEMAND_CHARGE – Ovo je naknada po zahtjevu
- ELECTRICITY_PRICE – Ovo je trošak struje
- ENERGY_PRICE – Ovo je trošak energije
- LOAD_CONTROL -Postavite izlaz opterećenja na relativne vrijednosti
- LOAD_DISPATCH – Ovo se koristi za otpremu tereta
- jednostavno – amortizovano – za kompatibilnost unatrag sa A profile
- JEDNOSTAVNO – Jednostavni nivoi (usaglašeni sa OpenADR 2.0a)
Nabrojana vrijednost koja opisuje tip signala kao što je nivo ili cijena
- delta – Signal označava količinu za promjenu u odnosu na ono što bi se koristilo bez signala.
- nivo – Signal označava nivo programa.
- umnožitir – Signal označava množitelj primijenjen na trenutnu brzinu isporuke ili korištenja u odnosu na ono što bi se koristilo bez signala.
- cijena – Signal pokazuje cijenu.
- priceMultiplier – Signal označava multiplikator cijene. Proširena cijena je izračunata vrijednost cijene pomnožena brojem jedinica.
- cijenaRelativna – Signal označava relativnu cijenu.
- set lopta – Signal označava ciljnu količinu jedinica.
- x-loadControlCapacity – Ovo je instrukcija za regulator opterećenja da radi na nivou koji je neki procenattage njegovog maksimalnog kapaciteta potrošnje opterećenja. Ovo se može mapirati na određene kontrolere opterećenja za obavljanje stvari kao što je radni biciklizam. Imajte na umu da se 1.0 odnosi na 100% potrošnju. U slučaju jednostavnih uređaja tipa ON/OFF onda 0 = OFF i 1 = ON.
- x-loadControlLevelOffset – Diskretni celobrojni nivoi koji su relativni u odnosu na normalne operacije gde je 0 normalne operacije.
- x-loadControlPercentOffset – Percentage promjena od normalnih operacija kontrole opterećenja.
- x-loadControlSetpoint – Učitajte zadane točke regulatora opterećenja.
– OpenADR A i B Profile Razlike
Jedina usluga koju podržava A profile je EiEvent usluga. EiEvent objekat je pojednostavljen u A profile sa sljedećim ograničenjima:
- Dozvoljen je samo jedan signal po događaju i taj signal mora biti OpenADR dobro poznati signal SIMPLE.
- Postoji ograničeno ciljanje događaja s podržanim samo venID, groupID, resourceID i partyID.(eiEvent:eiTarget).
- Ciljanje na razini signala s klasama uređaja nije podržano (eiEventSignal:eiTarget:endDeviceAsset).
- Osnovne linije nisu podržane (eiEvent:eiEventSignals:eiEventBaseline).
- modificationDateTime i modificationReason nisu podržani.
- Krajnja točka URL za jednostavan HTTP u 2.0b je:
- https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>
Neki elementi nosivosti koji su bili potrebni u A profile su sada opcioni u B profile, uključujući:
- currentValue
– OpenADR sigurnosni certifikati
Pravila usaglašenosti OpenADR-a zahtijevaju sljedeće:
- TLS verzija 1.2 se koristi za razmjenu X.509 certifikata
- VTN-ovi moraju imati i SHA256 ECC i RSA certifikate
- VEN-ovi mogu podržavati SHA256 ECC i RSA certifikate, a mogu podržavati oba
- I VTN i VEN moraju biti konfigurirani da traže klijentske certifikate ako će igrati ulogu transportnog servera (tj. odgovarati na zahtjeve druge strane)
- I VTN i VEN moraju pružiti certifikat klijenta kada to zatraži druga strana kao dio procesa pregovaranja o TLS-u
Certifikati koje pruža NetworkFX bit će specifični za RSA ili ECC. Kreiranje ovih sertifikata može se desiti kao rezultat popunjavanja obrazaca na NetworkFX-u web lokacija za traženje testnih certifikata ili može biti rezultat zahtjeva za proizvodne certifikate putem zahtjeva za potpisivanje certifikata (CSR). Bez obzira na metodu, sljedeće files će biti dostavljeni (nprampprikazane su:
- Root Certificate
- Srednji korijenski certifikat
- Sertifikat uređaja
- Privatni ključ
Općenito, privatni ključ se koristi za šifriranje korisnih podataka koje šalje VEN ili VTN. Sertifikat uređaja je skup jedinstvenih identifikacionih informacija o VEN-u ili VTN-u koje je kreiralo izdavanje sertifikata i šifrovano korišćenjem privatnog ključa. Korijen i srednji files se koriste za dešifriranje certifikata uređaja i potvrđivanje da je certifikat došao od pouzdanog tijela.
U Java okruženju koje koristi JSSE, postoje dva skladišta certifikata. Jedan se zove Trust Store i koristi se za držanje korijenskog certifikata. Drugi se zove Key Store i koristi se za pohranjivanje lanca certifikata koji se sastoji od srednjeg certifikata uređaja, kao i privatnog ključa
Imajte na umu da kada koristite XMPP transport, VEN komunicira sa XMPP serverom, a NE direktno sa VTN-om. Dakle, konfiguracija certifikata na XMPP serveru MORA biti ekvivalentna onoj na VTN-u. Komunikacija između samog VTN-a i XMPP servera je transparentna za VEN i u suštini je privatna veza. Ipak, većina dobavljača koristi skup VEN certifikata u VTN-u kada komunicira sa XMPP serverom.
Ako koristite OpenFire kao svoj XMPP server, postoji još jedno ograničenje koje morate uzeti u obzir. OpenFire zahtijeva da se CN ime korišteno u certifikatima klijentskog uređaja podudara s korisničkim imenom uređaja XMPP konfiguriranim na XMPP serveru. Ovo može rezultirati nekim čudnim imenima klijenata jer se MAC adresa koristi za CN ime na VEN certifikatima (dio OpenADR sigurnosnih zahtjeva)
Konačno, većina VEN-ova i VTN-ova kada igraju ulogu transportnog klijenta će pokušati potvrditi da CN polje certifikata koje pruža transportni server ima CN ime koje odgovara imenu hosta entiteta koji je dao certifikat. Ovo može biti još jedan izvor problema interoperabilnosti prilikom razmjene certifikata. Provjera imena hosta se obično može programski onemogućiti kako bi se izolirali ove vrste problema.
OpenADR 2.0 Programski vodič za odgovor na zahtjev – Preuzmi [optimizirano]
OpenADR 2.0 Programski vodič za odgovor na zahtjev – Preuzmi
