OpenADR 2.0
Programgids vir vraagreaksie
Hersienommer: 0.92
Dokumentstatus: Werkteks
Dokumentnommer: 20140701
Kopiereg © OpenADR Alliance (2014/15). Alle regte voorbehou. Die inligting in hierdie dokument is die eiendom van die OpenADR Alliance en die gebruik en openbaarmaking daarvan word beperk.
INHOUD
7 Ontplooiingsscenario en DR-programkartering 16
8 Kies 'n DR-programsjabloon 18
9 Vraagreaksie-programsjablone 21
9.1 Kritieke piekpryse-program (CPP) 21
9.1.1 CPP DR-programkenmerke 21
9.1.2 OpenADR-kenmerke vir CPP-programme 22
9.2.1 Kapasiteitsaanbod DR-programkenmerke 24
9.2.2 OpenADR-kenmerke vir kapasiteitsbiedprogramme 25
9.3 Residensiële termostaatprogram 27
9.3.1 Residensiële termostaat DR-programkenmerke 27
9.3.2 OpenADR-kenmerke vir residensiële termostaatprogramme 28
9.4.1 Vinnige DR-versendingsprogramkenmerke 29
9.4.2 OpenADR-kenmerke vir kapasiteitsbiedprogramme 31
9.5 Residensiële Elektriese Voertuig (EV) Tyd van Gebruik (TOU) Program 33
9.5.1 Residensiële EV TOU-programkenmerke 33
9.5.2 OpenADR-kenmerke vir residensiële EV TOU-programme 33
9.6 Openbare stasie elektriese voertuig (EV) intydse prysbepalingsprogram 34
9.6.1 Openbare Stasie EV RTP-programkenmerke 34
9.6.2 OpenADR-kenmerke vir openbare stasie EV RTP-programme 34
9.7 Verspreide Energiehulpbronne (DER) DR-program 35
9.7.1 Verspreide Energiehulpbronne (DER) Programkenmerke 35
9.7.2 OpenADR-kenmerke vir verspreide energiebronne (DER) 35
Bylae A – Sample Data- en loonvrag-sjablone 36
A.1 Kritieke Piekprysbepalingsprogram (CPP) 36
A.1.1 CPP Scenario 1 – Eenvoudige gebruik geval, A of B Profile 36
A.1.2 CPP Scenario 2 – Tipiese gebruiksgeval, B profile 36
A.1.3 CPP Scenario 3 – Komplekse gebruiksgeval 37
A.1.4 CPP Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Geval 37
A.2 Kapasiteitsbodprogram (KBP) 39
A.2.1 CBP Scenario 1 – Eenvoudige gebruik geval, A of B Profile 39
A.2.2 CBP Scenario 2 – Tipiese gebruiksgeval, B profile 39
A.2.3 CBP Scenario 3 – Komplekse gebruiksgeval 40
A.2.4 CBP Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Geval 40
A.3 Residensiële termostaatprogram 42
A.3.1 Residensiële termostaat Scenario 1 – Eenvoudige gebruik geval, A of B Profile 42
A.3.2 Residensiële termostaat Scenario 2 – Tipiese gebruiksgeval, B profile 42
A.3.3 Residensiële termostaat Scenario 3 – Komplekse gebruiksgeval 43
A.3.4 Residensiële termostaat Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Geval 43
A.4.1 Vinnige DR Scenario 1 – Eenvoudige gebruik geval, A of B Profile 45
A.4.2 Vinnige DR Scenario 2 – Tipiese gebruiksgeval, B profile 45
A.4.3 Vinnige DR Scenario 3 – Komplekse gebruiksgeval 46
A.4.4 Vinnige DR Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Geval 46
A.4.5 Vinnige DR Sample Rapporteer Metadata Loonvrag – Tipiese B Profile Gebruik Geval 48
A.4.6 Vinnige DR Sample Verslagversoek loonvrag – Tipiese B Profile Gebruik Geval 48
A.4.7 Vinnige DR Sample Rapporteer Data Loonvrag – Tipiese B Profile Gebruik Geval 49
A.5 Residensiële Elektriese Voertuig (EV) Tyd van Gebruik (TOU) Program 49
A.5.1 Residensiële EV Scenario 1 – Eenvoudige gebruik geval, A of B Profile 49
A.5.2 Residensiële EV Scenario 2 – Tipiese gebruiksgeval, B profile 50
A.5.3 Residensiële EV Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Geval 50
A.6 Openbare stasie elektriese voertuig (EV) Intydse prysbepalingsprogram 53
A.6.1 Openbare Stasie EV Scenario 1 – Tipiese gebruiksgeval, B profile 53
A.6.2 Openbare Stasie EV Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Geval 53
A.7 Verspreide Energiehulpbronne (DER) DR-program 54
Bylae B – Diens- en loonvragdefinisies 55
B.1 Oop ADR ondersteun die volgende dienste: 55
Bylae C – Diens- en loonvragdefinisies 56
C.4 EiRegisterParty Loonvragte 57
Bylae D – Woordelys van Skema-loonvragelemente 58
Bylae E Woordelys van opgesomde waardes 65
Bylae F – OpenADR A en B Profile Verskille 70
Bylae G – OpenADR-sekuriteitsertifikate 71
Inleiding
Die teikengehoor vir hierdie gids is nutsdienste wat beplan om Demand Response (DR)-programme te ontplooi wat OpenADR 2.0 gebruik vir die kommunikasie van DR-gebeurtenisverwante boodskappe tussen die nuts- en stroomaf-entiteite, en die vervaardigers van toerusting wat daardie kommunikasie-uitruiling fasiliteer. Daar word aanvaar dat die leser 'n basiese konseptuele begrip van beide aanvraagrespons en OpenADR 2.0 het (van hierdie punt af na bloot verwys as OpenADR).
Die OpenADR profile spesifikasies definieer duidelik die verwagte gedrag wanneer DR-gebeurtenisverwante inligting uitgeruil word, maar daar is genoeg opsioneel in OpenADR dat die ontplooiing van bedieners (VTN'e) by die nutsprogram en kliënte (VENs) by stroomaf-webwerwe nie 'n plug-n-play ervaring is nie. OpenADR-kenmerke soos gebeurtenisseine, verslagformate en teikening moet op 'n DR-program-vir-program-basis gespesifiseer word.
Daar is nie iets soos 'n gestandaardiseerde DR-program nie. Elke DR-programontwerp is geneig om uniek te wees en pas by die strukturele en regulatoriese vereistes van die geografiese streek waarin dit ontplooi word. Vir elke DR-program is daar talle moontlike ontplooiingscenario's wat 'n verskeidenheid akteurs betrek.
Die variasie in DR-programontwerpe, ontplooiingscenario's en OpenADR-eienskappe is 'n inhibeerder vir uitgebreide ontplooiing van DR en die gebruik van OpenADR. Hierdie veranderlikheid is vir die grootste deel 'n weerspieëling van die gefragmenteerde en komplekse aard van die slimnetwerk.
Nuts benodig bvamples van tipiese DR-programme sodat hulle as modelle vir hul eie DR-programimplementerings gebruik kan word. Toerustingvervaardigers moet tipiese DR-programgebruiksmodelle verstaan sodat hulle interoperabiliteit as deel van die ontwikkelingsproses kan bekragtig eerder as op 'n DR-program-ontplooiing spesifieke basis. Die bedoeling van hierdie gids is om beide hierdie doelwitte soos volg te bereik:
- Definieer 'n klein stel standaard DR-programsjablone gemodelleer volgens die algemene kenmerke van die gewildste DR-programme wat tot dusver geïmplementeer is
- Definieer 'n klein stel ontplooiingscenario's wat gemodelleer is na werklike ontplooiing, met akteurs en rolle duidelik geïdentifiseer
- Definieer aanbevelings vir beste praktyke vir OpenADR-eienskappe spesifiek vir elk van die DR-programsjablone
- Verskaf 'n besluitboom wat nutsdienste kan gebruik om die nuttige DR-programsjablone en ontplooiingscenario's te identifiseer gebaseer op hul besigheidsbehoeftes
Die klem in hierdie gids sal daarop wees om dinge eenvoudig te hou deur 'n klein stel duidelike aanbevelings te verskaf wat die meerderheid van die besonderhede sal aanspreek wat nodig is om 'n tipiese DR-program te ontplooi, en om interoperabiliteitstoetsing van toerusting wat in programme ontplooi word moontlik te maak deur die aanbevelings in hierdie gids.
Verwysings
- OpenADR Profile Spesifikasie en skema – www.openadr.org
Terme en definisies
Die volgende terme en definisies word in hierdie dokument gebruik.
- Eis reaksie: 'n Meganisme om klantladingvraag te bestuur in reaksie op voorsieningstoestande, soos pryse of beskikbaarheidseine
- Aggregator Party – Dit is 'n party wat verskeie hulpbronne saamvoeg en dit aan die DR-programpartytjie as 'n enkele hulpbron in hul DR-programme aanbied.
- Aggregator Tussenganger Infrastruktuur – Dit is die infrastruktuur, apart van die Vraagkant-infrastruktuur, wat deur die Aggregator Tussengangerparty gebruik word om met beide die Hulpbronne en die roosterkant-entiteite te kommunikeer
- Ooreenkoms: 'n Kontraktuele ooreenkoms tussen partye wat 'n rol speel in 'n DR-program wat verantwoordelikhede en vergoeding uiteensit
- Bate – 'n Tipe Hulpbron wat 'n spesifieke versameling fisiese ladings verteenwoordig. Hulpbronne kan saamgestel word uit bates, en 'n bate kan hulpbron wees, maar bates kan nie verder ontbind word in veelvuldige bates of hulpbronne nie.
- Geassosieerde: Verskaf 'n programmatiese assosiasie tussen twee entiteite, deur die konfigurasie van 'n toestel van databasis. Byvoorbeeld, geassosieerde hulpbronne met 'n VEN
- Basislyne: Die berekende of gemete energieverbruik (aanvraag) deur 'n stuk toerusting of 'n terrein voor die geleentheid soos bepaal deur opnames, inspeksies en/of meting by die terrein.
- BMS – Dit is die geboubestuurstelsel wat gebruik kan word om hulpbronne te beheer. Dit word soms na verwys as 'n Energiebestuurstelsel.
- Saamgestelde hulpbron – Dit is 'n spesiale soort hulpbron wat 'n samevoeging is van veelvuldige fisiese bates wat elkeen hul eie maniere van vragbeheer het.
- Kliëntaansporing: 'n Aansporing verskaf aan die eienaar/aggregator van vraagkanthulpbronne vir deelname aan 'n DR-program.
- Vraagkant-infrastruktuur – Dit is die infrastruktuur wat die Hulpbronne huisves wat by die DR-programme ingeskryf is
- DR Logika: Algoritmes of logika wat DR-seine omskakel in uitvoerbare lasbeheer. Let daarop dat DR Logic op baie verskillende plekke geïmplementeer kan word en in sommige gevalle onder verskeie substelsels versprei kan word.
- DR Programpartytjie – dit is die entiteit wat verantwoordelik is vir die netwerkinfrastruktuur en verder vir die bestuur van die DR-programme wat gebruik word om netwerkkwessies te versag. Dit is tipies 'n Utility of ISO.
- Ingeskryf: Die eienaar/samesteller van vraagkanthulpbronne kies om aan 'n DR-program deel te neem en kan inligting verskaf oor die spesifieke hulpbronne wat vir DR-geleenthede geteiken kan word
- Gebeurtenis aktiewe tydperk: Die is die tydperk in die tyd waartydens 'n verandering in die las profile word aangevra as deel van 'n DR-geleentheid
- Gebeurtenisbeperkings: Die tydraamwerke waartydens die kliënt kan verwag om gebeurtenisse en verwante beperkings te ontvang, soos geen gebeurtenisse oor naweke of opeenvolgende dae
- Gebeurtenis Dae: 'n Dag wanneer 'n DR-gebeurtenis plaasvind. Die meeste programme het beperkings ten opsigte van die aantal gebeurtenisdae wat in 'n gegewe kalenderperiode toegelaat word
- Gebeurtenisbeskrywer: Deel van die OpenADR-gebeurtenisvoorwerp wat metadata oor die gebeurtenis beskryf, soos programnaam en gebeurtenisprioriteit
- Gebeurtenis Duur: Die lengte van die geleentheid. Die meeste programme definieer beperkings ten opsigte van die lengte van 'n gebeurtenis, sowel as die ure van die dag waartydens die gebeurtenis kan plaasvind
- Gebeurtenis seine: Die uitvoerbare inligting vervat in 'n gebeurtenis soos elektrisiteitspryse of spesifieke vlakke van beurtkrag wat versoek word wat tipies vooraf geprogrammeerde beurtkraggedrag deur die ontvanger van die gebeurtenis veroorsaak. 'n DR-programdefinisie moet die tipe gebeurtenisseine spesifiseer wat gebruik word
- Gebeurtenis-teikening: Die beurtkraghulpbronne wat die beoogde ontvanger vir die DR-geleentheid is. Dit kan 'n geografiese gebied, 'n spesifieke klas toestelle, 'n groepidentifiseerder, hulpbron-ID of ander identifiseerder wees. 'n DR-programdefinisie moet spesifiseer hoe spesifieke hulpbronne geteiken gaan word.
- Gebeurtenisse: 'n Geleentheid is 'n kennisgewing van die nutsprogram om syhulpbronne te eis wat beurtkrag versoek wat op 'n spesifieke tyd, oor 'n bepaalde duur begin, en kan teikeninligting insluit wat spesifieke hulpbronne aanwys wat aan die geleentheid behoort deel te neem
- Fasiliteerder Tussenganger Infrastruktuur – Dit is die infrastruktuur, apart van die Vraagkant-infrastruktuur, wat deur die Fasiliteerder-tussengangerparty gebruik word om met beide die Hulpbronne en die roosterkant-entiteite te kommunikeer.
- Fasiliteerder: 'n Derde party wat sommige of die hele uitvoering van die DR-program namens die nutsprogram bestuur
- Net-infrastruktuur – Dit is die infrastruktuur wat deur die DR-programpartye besit of bestuur word. Hierdie infrastruktuur sluit die implementering van die OpenADR VTN in wat gebruik word om DR-seine te stuur na Hulpbronne wat by die DR-programme ingeskryf is
- Tussengangerparty – Dit is 'n party wat tipies namens die Hulpbronparty werk om hul deelname aan DR-programme te vergemaklik.
- Vragbeheer – dit is die infrastruktuur wat verband hou met 'n Hulpbron wat verantwoordelik is vir die werklike beheer van die Hulpbron en die vervaardiging van 'n spesifieke laai profile.
- Laai Profile Doelwit: Hierdie motivering agter die ontwikkeling van 'n DR-program en die uitreiking van gebeure. Soos die begeerte om piekvragte te skeer.
- Kennisgewing: 'n Tydperk voor die begintyd van 'n gebeurtenis waar die vraagkant-hulpbroneienaar in kennis gestel word van 'n hangende gebeurtenis
- Kies Gedrag: Die verwagte reaksie van die vraagkanthulpbroneienaar by ontvangs van 'n gebeurtenis. Hierdie reaksie kan die vorm aanneem van 'n OptIn of OptOut aanduiding of hulpbron aan die geleentheid sal deelneem of nie
- Kies antwoorde: Of 'n spesifieke program 'n reaksie van vraagkanthulpbronne moet vereis in reaksie op 'n gebeurtenis, en wat daardie reaksies tipies is.
- Opt Dienste: Skedules gekommunikeer oor OpenADR om tydelike veranderinge in hulpbronbeskikbaarheid aan te dui om aan geleenthede deel te neem.
- Voorvereiste: Kriteria waaraan voldoen moet word sodat 'n vraagkant-hulpbroneienaar by 'n DR-program kan inskryf. Dit kan die beskikbaarheid van intervalvergaderings of 'n minimum beurtkragkapasiteit insluit
- Primêre drywers: Die primêre motivering aan die kant van die nut vir die skep van die DR-program en die uitreiking van gebeure. Soos "Piekvraagvermindering en hulpbrontoereikendheid"
- Programme – Dit is die DR-programme waarin die hulpbronne ingeskryf is.
- Programbeskrywing: 'n Narratiewe beskrywing van hoe 'n program werk. Deel van die DR-programsjablone wat in hierdie dokument gedefinieer word
- Program Tydsraamwerk: Die tyd van die jaar of seisoene tydens met 'n DR-program is tipies aktief
- Beoordeel ontwerp: Die spesifieke wysigings aan die tariefstruktuur of aansporings wat betaal word om eienaars van die vraagkanthulpbron te motiveer om aan die program deel te neem
- Registrasie Dienste: Diens wat deur die OpenADR-protokol gebruik word om basiese interoperabiliteit tussen 'n VTN en VEN te vestig, en om te bevestig dat die VEN met die nutskliënterekening geassosieer word.
- Verslagdoeningsdienste: Diens wat deur die OpenADR gebruik word om VENs in staat te stel om verslagdoening aan VENs te verskaf. DR-program moet die verslagdoeningsvereistes vir die program spesifiseer.
- Hulpbronparty – Dit is die party wat die aanvraagkant Hulpbronne besit wat by DR-programme ingeskryf kan word
- Hulpbron - Dit is die entiteit wat by die DR-programme ingeskryf is en in staat is om 'n soort verandering aan hul load pro te lewerfile in reaksie op die ontvangs van 'n DR-sein van 'n VTN.
- Teikenkliënt: Die profile van vraagkant-hulpbronne wat kan inskryf vir 'n spesifieke DR-programme soos residensiële, industriële, of dalk gebaseer op vlak van elektrisiteitsverbruik.
- Teikenladings: Die vraagkanthulpbronne waarvan die vrag gewysig moet word by ontvangs van 'n
- VEN – Dit is die OpenADR Virtual End Node wat gebruik word om met die VTN te kommunikeer.
- VTN – Dit is die OpenADR Virtual Top Node wat gebruik word om interaksie te hê met die hulpbronne wat by die DR-programme ingeskryf is.
Afkortings
- BMS: Geboubestuurstelsel
- C&I: Kommersieel en Nywerheid
- komm: Kommunikasie tussen twee entiteite
- DR: Vraag reaksie
- EBW: Energiebestuurstelsel
- OpenADR: Maak outomatiese aanvraagreaksie oop
- Programme: Verwysing na 'n aanvraagreaksieprogram(me)
- VEN: Virtuele Eindknoop
- VTN: Virtuele Top Node
Vraagreaksie-programtipes
Hierdie dokument bevat sjablone vir die DR-programme wat hieronder getoon word.
1. Kritieke piekpryse: Tarief en/of prysstruktuur wat ontwerp is om verminderde verbruik gedurende periodes van hoë groothandelmarkpryse of stelselgebeurlikhede aan te moedig deur 'n voorafbepaalde hoë tarief of prys vir 'n beperkte aantal dae of ure op te lê.
2. Kapasiteitsaanbodprogram: 'n Program wat 'n aanvraaghulpbron in kleinhandel- en groothandelmarkte toelaat om vragverlagings teen 'n prys aan te bied, of om te identifiseer hoeveel vrag dit bereid is om teen 'n spesifieke prys te beperk.
3. Residensiële termostaatprogram/direkte lasbeheer: 'n Vraagreaksie-aktiwiteit waardeur die programborg 'n kliënt se elektriese toerusting (bv. lugversorger) op kort kennisgewing op afstand beheer. Hierdie programme word hoofsaaklik aan residensiële of klein kommersiële kliënte aangebied.
4. Vinnige DR-versending/bykomende dienste-program: 'n Vraagreaksieprogram wat aansporingsbetalings aan kliënte verskaf vir beladingsreaksie tydens 'n Noodvraagreaksiegebeurtenis. 'n Abnormale stelseltoestand (bvample, stelselbeperkings en plaaslike kapasiteitsbeperkings) wat outomatiese of onmiddellike handaksie vereis om die mislukking van transmissiefasiliteite of opwekkingstoevoer te voorkom of te beperk wat die betroubaarheid van die grootmaat-elektriese stelsel nadelig kan beïnvloed. Daar kan soms na hierdie tipe programme verwys word as "Aanvullende Dienste".
5. Elektriese Voertuig (EV) DR-program: 'n Vraagreaksie-aktiwiteit waardeur die koste van die laai van elektriese voertuie aangepas word om te veroorsaak dat verbruikers verbruikspatrone verskuif.
6. Verspreide Energiehulpbronne (DER) DR-program: 'n Vraagreaksie-aktiwiteit wat gebruik word om die integrasie van verspreide energiebronne in die slimnetwerk glad te maak.
Implementeringscenario's
Die wyse waarop 'n DR-program ontplooi word, is ietwat onafhanklik van die kenmerke van die DR-program self. Die volgende diagramme toon 'n verskeidenheid maniere waarop 'n DR-program ontplooi kan word. Die volgende afdeling verskaf 'n kruisverwysing tussen die ontplooiingscenario's en die DR-programme waarmee hulle waarskynlik gebruik sal word.
Die diagramme in hierdie afdeling toon die verwantskappe tussen die entiteite in die verskillende scenario's.
direk 1
Dit is 'n eenvoudige scenario waarin daar 'n direkte verband tussen die DR Programparty en die Hulpbronparty is. Die Hulpbronparty is verantwoordelik om hul eie Hulpbronne by die DR-programme in te skryf en die Net-infrastruktuur is direk in wisselwerking met die Hulpbronne via 'n VEN wat binne die Vraagkant-infrastruktuur woon. Verder word die VEN deur die Hulpbronparty besit en is dit apart van die Hulpbronne en hul beheerders. Wanneer 'n DR-sein deur die VEN ontvang word, implementeer dit tipies geen lasbeheerlogika nie, maar stuur die seine bloot aan die lasbeheerders wat die toepaslike aksie neem. BvampLese van hierdie scenario sal C&I-geboue insluit wat 'n poort kan installeer wat 'n OpenADR VEN bevat en wanneer 'n sein deur daardie poort ontvang word, vertaal dit dit eenvoudig in 'n ander protokol en stuur dit aan na die lasbeheerders self.
direk 2
Dit is baie soortgelyk aan die Direct 1-scenario. Die belangrikste verskil is in hoe die VEN geïnstansieer word en die interaksies met die VTN gefasiliteer. Die VEN is geïnstansieer in 'n entiteit soos 'n gesentraliseerde BMS wat DR-logika kan implementeer en in wisselwerking kan tree met Compound Resource en hul baie verskillende lasbeheerders vanaf 'n meer gesentraliseerde ligging. Bvamples sluit in groot geboue met 'n BMS wat baie verskillende vragte in 'n gebou beheer (bv. beligting, HVAC, industriële prosesse, ens.) tot campgebruike wat verskeie fasiliteite kan hê met 'n gesentraliseerde beheerstelsel.
direk 3
Hierdie scenario is baie soortgelyk aan die Direct 1-scenario. Die belangrikste verskil is dat die VEN direk in die hulpbron en sy lasbeheerder geïnstantieer word. In hierdie geval word die DR-seine direk na die hulpbron en sy lasbeheerder gestuur. Die sogenaamde "pryse vir toestelle"-scenario val in hierdie kategorie. Bvamples sal enige soort lasbeheerder insluit soos HVAC (dws termostaat) wat 'n ingeboude VEN het wat in staat is om direk met die roosterkant-entiteite VTN te kommunikeer.
direk 4
Dit is 'n kombinasie van soorte Direct 1 en Direct 2 scenario's. Die belangrikste verskil is dat veelvuldige VEN's geassosieer word met 'n enkele saamgestelde hulpbron wat bestaan uit veelvuldige bates met hul eie lasbeheerders. Elkeen van die lasbeheerders wat die saamgestelde hulpbron uitmaak, kan met 'n ander VEN geassosieer word. Let daarop dat al die VEN's onder beheer sal wees van dieselfde Hulpbronparty wat die Saamgestelde Hulpbron besit. Hierdie scenario bestaan om vraagkant-infrastruktuur te fasiliteer wat saamgestelde hulpbronne het, maar nie 'n gesentraliseerde BBS soos die Direct 2-scenario het nie. Bvamples kan geboue insluit met verskillende lasbeheerders op elke vloer, maar geen gesentraliseerde BMS nie, of campgebruik met verskillende beheerders in elke gebou, maar geen campons wye kontroleerder. Aangesien daar vanuit die DR Programparty se perspektief slegs 'n enkele hulpbron by die program ingeskryf is wanneer dit 'n DR-sein na die hulpbron wil stuur, kan dit eenvoudig dieselfde seine stuur na elk van die aangewese VENs wat met die Hulpbron geassosieer is.
Fasiliteerder 1
In hierdie scenario is daar 'n tussenganger wat interaksies tussen die DR Programparty en die Hulpbronne fasiliteer. Tipies werk die Tussengangerparty namens die Hulpbronparty om hulle te help om hul Hulpbronne te bestuur. Die Hulpbronpartye het direkte verhoudings met die DR Programparty en hulle skryf hul eie Hulpbronne by die DR-programme in. Dus die DR Programparty views elke Hulpbronparty as 'n aparte Hulpbron en kan individueel met hulle interaksie hê. Die rol van die Tussengangerparty is om op te tree as 'n tussenganger vir al die OpenADR-verwante interaksies, dus word die VEN binne die Fasiliteerder Tussenganger-infrastruktuur geïnstansieer. Sulke infrastruktuur is dikwels wolkbasisse en word as sagteware as 'n diens (SaaS) aan die hulpbronpartye aangebied. Wanneer die DR-sein deur die fasiliteerder se VEN ontvang word, kan 'n aantal verskillende aksies plaasvind, insluitend die aanstuur van die DR-sein na die toepaslike hulpbron en moontlik die implementering van 'n soort DR-logika en die stuur van lasbeheeropdragte na elke hulpbron se lasbeheerder. BvampLese van hierdie scenario sluit in:
- Verkopers wat die fasiliteite vir groot kommersiële kettings soos groot boks kleinhandelaars bestuur.
- Industriële beheer tussengangers.
- Energiedienstemaatskappye (ESCO's)
- Wolkgebaseerde toestel- en toestelbestuurstelsels soos die opkomende slimkommunikerende termostaatverkopers.
Aggregator 1
Hierdie scenario is soortgelyk aan die Fasiliteerder-scenario. Die belangrikste verskil is dat die Aggregator Party die verhouding met die DR Program Party het in teenstelling met die Hulpbronpartye. Die Aggregator Party voeg verskeie klantbates saam in 'n enkele hulpbron wat dit by die DR-programme inskryf. Die DR Programparty het nie sigbaarheid in die individuele bates wat die Aggregator bestuur nie. Soos met die Fasiliteerder het die Aggregator hul eie infrastruktuur waar die VEN geïnstansieer word. Die verskil is dat wanneer 'n DR-sein ontvang word dit 'n enkele hulpbron verwys en die Aggregator implementeer 'n soort DR-logika oor al die bates in hul portefeulje om die doelwitte te bereik wat in die DR-sein gespesifiseer word.
Ontplooiing Scenario en DR Program Kartering
Die tabel hieronder verskaf watter ontplooiingscenario's die algemeenste is vir 'n spesifieke DR-program.
| Ontplooiing Scenario | |||
| DR-sjabloon | Direkte 1, 2, 3, 4 | Fasiliteerder 1 | Aggregator 1 |
| CPP-program | ∆ | ∆ | |
| Kapasiteitsaanbodprogram | ∆ | ||
| Residensiële termostaat
Program |
∆ | ||
| Vinnige DR-versending | ∆ | ||
| Elektriese Voertuig (EV) DR-program | ∆ | ∆ | |
| Verspreide Energiehulpbronne (DER) DR-program | ∆ | ∆ | |
Kies 'n DR-programsjabloon
Die volgende is 'n stel vrae wat relevant is vir enige hulpprogram wat 'n nuwe DR-program wil implementeer. Dit is nie bedoel om omvattend te wees nie, maar verteenwoordig sommige van die meer pertinente kwessies. Die bedoeling van hierdie vrae is om hulpprogramme te help lei na 'n gepaste stel DR-programsjablone.
V: Hoekom wil jy DR doen? Watter roostertoestand of bedryfskwessie probeer jy met DR versag?
Dit is verreweg die belangrikste vraag en vorm die basis vir die algehele vereistes en doelwitte vir wat die DR-program veronderstel is om te bereik. Die antwoord op hierdie vraag definieer hoe die vraagkantlading profile is veronderstel om deur die DR-program gevorm te word. Alle ander vereistes vloei voort uit die antwoord op hierdie vraag.
- Probeer jy pieke skeer?
- Wil jy die maag van die eend vul?
- Probeer jy om die lokoprys van elektrisiteit te verskans?
- Is jy bekommerd oor roosterbetroubaarheid?
- Probeer jy netbates bewaar?
- Ens ens ens.
Die tabel hieronder verskaf 'n bietjie bykomende konteks tot die motiverings agter die wil om 'n DR-program te ontwikkel
| Roosterbetroubaarheid en -veiligheid | Frekwensie en Voltage Stabiliteit |
| Hulpbrontoereikendheid | |
| Piekkapasiteit | |
| Ramping | |
| Gebeurlikheid | |
| Verkryging van Energie | Spotmarkpryse |
| Prys Arbitrage | |
| Batebestuur | Skadevoorkoming |
| Onderhoudsvermindering | |
| Lewenslange verlenging | |
| Kapasiteitsbestuur | Ekonomiese voordele |
| Noodbestuur | |
| Omgewing | Negawatt |
| Skoon Energie |
V: Is daar 'n bestaande DR-program of -tarief reeds vir hierdie program in plek?
- Dikwels word die programreëls eksplisiet in 'n tarief uitgespel.
V: Watter vraagkant-marksegment teiken jy met hierdie program?
Dit kan help om die teiken van die hulpbronne in die gebeurtenis en die tipe sein te bepaal.
- Residensieel
- Groot C&I
- Klein C&I
- Landbou
- Waterbestuur
- Elektriese voertuie
- Ens, ens, ens
V: Probeer jy spesifieke soorte vragte teiken?
- Termostate
- Elektriese voertuie
- Ag pompe
- ens.
V: Wat is jou ontplooiingsmodel?
Die antwoord op hierdie vraag kan beïnvloed hoe hulpbronne binne die program gedefinieer word en bepaal hoe daardie hulpbronne binne gebeure geteiken word.
- Regstreeks aan kliënte
- Deur tussengangers soos aggregators of fasiliteerders
- Klant verantwoordelik vir die verkryging en implementering van hul eie VEN-toerusting?
- ens.
V: Op watter vlak van spesifisiteit wil jy interaksie hê met die vraagkantladings?
Hierdie vraag hou ietwat verband met die ontplooiingsmodel en bepaal hoe die hulpbronne in die program gedefinieer en geteiken word. Dit is een van die belangrikste en moontlik komplekse vrae.
- Interaksie met elke individuele hulpbron
- Interaksie deur 'n fasiliteerder of samevoeger met geen spesifikasie van die hulpbronne daaragter nie
- Interaksie deur 'n fasiliteerder of samevoeger EN spesifiseer watter hulpbronne agter hulle gestuur moet word
- Gebruik ligging as 'n kenmerk om hulpbronne te spesifiseer
- Gebruik 'n soort nutsgedefinieerde groeperingsmeganisme om hulpbronne te spesifiseer
- Teiken individuele bates soos termostate
- Interaksie met geen hulpbronne en saai net DR-geleenthede uit
- ens.
V: Watter interaksiepatroon wil jy gebruik om jou kliënte se laai pro te beïnvloedfiles?
Hierdie vraag bepaal die tipe DR-seine wat aan deelnemers aan 'n program gestuur sal word.
- Aansporings (bv. dinamiese pryse)
- Vragversendings (bv. aanvullende dienste)
- Direkte vragbeheer
- Generiese gebeurtenis sein
- ens.
V: Wat is die algemene hulpbronskeduleringskenmerke van die program?
- Datums en tye wat gebeurtenisse genoem kan word
- Frekwensie van gebeure
- Duur van gebeure
- Toelaatbare vertragings vir die verspreiding van gebeure
- ens.
V: Hoe word die beskikbaarheid van hulpbronne in die program bepaal?
- Deur streng programreëls
- As deel van een of ander nominasie- of bodproses wat deur die hulpbron gedoen word
- In-/uitteken toegelaat?
- ens.
V: Watter tipe sigbaarheid het jy nodig in die hulpbron se werkverrigting?
Dit is 'n baie breë vraag en bepaal watter tipe inligting uit die hulpbronne in die DR-program teruggevoer word. Oor die algemeen bepaal dit die tipe verslae wat vereis word.
- Aanlyn / vanlyn
- Gebruik (huidige en/of historiese)
- Laai reaksie potensiaal
- Laai beskikbaarheid
- Laai-/batetoestand (huidig en/of histories)
- Ens., ens. ens.
Vraag-reaksie-programsjablone
Kritiese piekprysprogram (CPP)
CPP DR Program Kenmerke
| Laai Profile Doelwit | - Piekaanvraagvermindering |
| Primêre drywers | -Verminderde kapitaaluitgawes en verlaagde energiekoste |
| Programbeskrywing | Wanneer nutsdienste hoë groothandelmarkpryse of kragstelselnoodtoestande waarneem of verwag, kan hulle kritieke gebeurtenisse gedurende 'n bepaalde tydperk (bv. 3:6-XNUMX:XNUMX op 'n warm somer weekdag) oproep, is die prys vir elektrisiteit gedurende hierdie tydperke aansienlik opgewek. |
| Kliëntaansporing | Kliënte kan afslag op energiepryse aangebied word tydens nie-spitstye as 'n aansporing om aan die program deel te neem. |
| Beoordeel ontwerp | CPP is 'n prysprogram met tariewe wat tydens kritieke pieke in energieverbruik styg. Tipies is CPP-koerse 'n opteller of vermenigvuldiger tot plat-, vlak- of TOU-basiskoerse. |
| Teikenkliënt | -Residensieel of C&I |
| Teikenlading | -Enige |
| Voorvereiste | -Klant moet intervalmeting hê
-C&I-kliënte sal dalk aan 'n aanvraagkriterium moet voldoen |
| Program Tydsraamwerk | - Dek tipies maande van die jaar waar piek energieverbruik voorkom, hoewel dit in sommige gevalle die hele jaar deur kan wees. |
| Gebeurtenisbeperkings | - Tipies Maandag tot Vrydag, vakansiedae uitgesluit, met opeenvolgende daggebeurtenisse gewoonlik toegelaat |
| Gebeurtenis Dae | -Gewoonlik 9 tot 15 per jaar |
| Gebeurtenis Duur | -Gewoonlik gedurende 'n vaste tydraamwerk vir alle gebeurtenisse wat wissel van 4 tot 6 uur gedurende die hoogste energieverbruik tye van die dag. |
| Kennisgewing | - Tipies dag wat voorlê |
| Kies Gedrag | - Daar word gewoonlik nie van kliënte vereis om aan geleenthede deel te neem nie |
| Sertifisering
Gebeurtenisse |
-Gewoonlik geen |
OpenADR-kenmerke vir CPP-programme
| Gebeurtenis seine | –'N EENVOUDIGE sein met vlakke 1 tot 3 gekarteer na die prysimpak van die CPP-gebeurtenis. As 'n CPP-program 'n enkele pryskomponent het, moet dit na vlak 1 gekarteer word. Vir CPP-programme met veelvuldige pryskomponente, moet die kleinste pryskomponent na vlak 1 gekarteer word, met die ander pryskomponente gekarteer na vlakke 2 en 3 in toenemende mate van prysimpak.
-As die ontplooiing B pro ondersteunfile VENs, bykomend tot die SIMPLE sein, kan 'n ELECTRICITY_PRICE sein ingesluit word in die loonvrag met 'n tipe priceRelative, priceAbsolute, of priceMultiplier, afhangende van die aard van die program. Sien Bylae A vir bvamples. |
| Kies antwoorde | -VTN'e wat gebeure stuur moet die oadrResponseRequired-element op "altyd" stel, wat vereis dat die VEN reageer met 'n optIn of optOut
-Aangesien deelname aan 'n CPP-program 'n "beste poging"-oefening is, is daar geen formele betekenis om in te teken of te onttrek nie, behalwe 'n vriendelike beskikbaarheidsaanduiding van voorneme om deel te neem. Ons beveel dit aan VENs reageer met optIn tensy daar 'n spesifieke oorheersingsaksie deur die kliënt geneem is. -Die oadrCreateOpt-loonvrag sal tipies nie gebruik word om hulpbronne wat aan geleenthede deelneem, te kwalifiseer nie. |
| Gebeurtenisbeskrywer | -Die gebeurtenis prioriteit moet op 1 gestel word tensy die programreëls of VTN-konfigurasie anders spesifiseer
–Toetsgebeurtenisse word gewoonlik nie gebruik nie met CPP-programme. As hulle egter toegelaat word, moet die testEvent-element op "true" gestel word om die toetsgebeurtenis aan te dui. As bykomende geparameteriseerde inligting in hierdie element vereis word, kan dit volg op "waar" geskei deur 'n spasie met hierdie bykomende inligting. |
| Gebeurtenis aktiewe tydperk | – eiRampUp, eiRecovery, toleransie-elemente word tipies nie gebruik nie |
| Basislyne | –Basislyne is tipies nie by die geleentheid se loonvrag ingesluit nie |
| Gebeurtenis-teikening | -CPP-programme onderskei gewoonlik nie tussen hulpbronne vir 'n gegewe kliënt nie. Teikening spesifiseer gewoonlik die venID, wat aandui dat al die hulpbronne wat met die VEN geassosieer word, moet deelneem, of 'n lys van al die hulpbron-ID's geassosieer met VEN. |
| Verslagdoeningsdienste | –Telemetrie-verslaggewing word gewoonlik nie gebruik nie aangesien dit nie absoluut nodig is vir CPP-programme nie.
Verwys na Bylae B vir bvamples van verslae van nutsvlieëniers wat van toepassing kan wees op hierdie tipe program. |
| Opt Dienste | –Gebruik van die Opt-diens om tydelike beskikbaarheidskedules te kommunikeer sal gewoonlik nie gebruik word nie as deel van 'n CPP-program. Sommige implementerings kan egter hierdie diens gebruik om beskikbare gebeurtenisdae te bewaar vir kliënte wat 'n gebrek aan beskikbaarheid aandui. |
| Registrasie Dienste | Polling intervalle deur die VTN aangevra vir tipiese dag-vooruit CPP-programme word nie vereis om meer gereeld as een keer per uur te wees nie. Die gebruik van peiling vir hartklopopsporing kan egter meer gereelde peiling vereis. |
Kapasiteitsaanbodprogram
Kapasiteit Bied DR Program Kenmerke
| Laai Profile Doelwit | - Piekaanvraagvermindering en hulpbrontoereikendheid |
| Primêre drywers | -Verminderde kapitaaluitgawes en verlaagde energiekoste |
| Programbeskrywing | Die kapasiteitsaanbodprogram word deur ISO/nutsdienste gebruik om vooraf-toegewyde beurtkragkapasiteit van aggregators of self-aggregeerde kliënte te verkry. Hierdie vooraf-toegewyde beurtkragkapasiteit word deur ISO/nutsdienste gebruik wanneer hulle hoë groothandelmarkpryse, kragstelselnoodtoestande waarneem of verwag, of as deel van normale energiehulpbronbenutting deur DR-geleenthede gedurende 'n bepaalde tydperk te bel.
Let daarop dat elke aggregator tipies verantwoordelik is vir die ontwerp van hul eie vraagreaksieprogram sowel as kliëntverkryging en gebeurteniskennisgewing om die kapasiteitsverpligtinge wat as deel van hierdie program gemaak is, na te kom. |
| Kliëntaansporing | Aggregeerders/kliënte ontvang twee tipes aansporings. Eerstens ontvang hulle 'n kapasiteitsbetaling om 'n spesifieke hoeveelheid beurtkragkapasiteit beskikbaar te hou vir DR-geleenthede gedurende 'n toekomstige tydvenster. Tweedens, as 'n gebeurtenis gedurende die toekomstige tydvenster uitgeroep word, kan 'n energiebetaling vir beurtkrag oor die duur van die gebeurtenis gemaak word. |
| Beoordeel ontwerp | Deelnemers aan die program maak 'n "kapasiteitsbenoeming"-bod wat die beurtkragkapasiteit aandui wat hulle bereid is om te hou soos beskikbaar gedurende 'n toekomstige tydvenster. Die bod kan ook die aansporing insluit wat die aggregator/kliënt bereid is om te aanvaar vir beurtkrag onder 'n basislynwaarde.
In nutsmarkte is die kapasiteitsverbintenis tipies vir die volgende kalendermaand, hoewel baie langer tydraamwerke in ISO-markte gebruik word. As deel van die kapasiteitsbenoeming kan die kliënt kies tussen 'n aantal kenmerke, insluitend dag-voor- of dag-kennisgewing en die geleentheidsduurvenster (soos 1-4 uur, 2-6 uur, …). 'n Kapasiteitsbetaling word aan die kliënt gemaak vir hierdie voorafverbintenis, selfs al is daar geen gebeurtenisse wat gedurende die tydvenster genoem word nie. Indien 'n gebeurtenis gedurende die tydsperiode uitgeroep word, kan die kliënt 'n energiebetaling vir die beurtkrag in verhouding tot 'n basislyn ontvang, maar boetes kan van toepassing wees indien minder as die voorafbepaalde beurtkragkapasiteit gelewer word op die tydstip waarop die gebeurtenis uitgeroep word. |
| Teikenkliënt | -Aggregeerders en self-aggregeerde C&I-kliënte |
| Teikenladings | - Enige |
| Voorvereiste | -Klant moet intervalmeting hê
-C&I-kliënte sal dalk aan 'n vraag- of bodkriterium moet voldoen |
| Program Tydsraamwerk | - Enige tyd |
| Gebeurtenisbeperkings | - Tipies Maandag tot Vrydag, vakansiedae uitgesluit, met opeenvolgende daggebeurtenisse gewoonlik toegelaat |
| Gebeurtenis Dae | -Gewoonlik 'n maksimum van 30 uur per maand |
| Gebeurtenis Duur | -Gewoonlik gedurende 'n vaste tydvenster vir alle gebeurtenisse tydens die hoogste energieverbruik tye van die dag.). Gebeurtenisduur wissel volgens klantkapasiteitverbintenis met voorkeure wat wissel van 1 tot 8 uur of soos gespesifiseer deur die ontwerp van die program |
| Kennisgewing | -Dag-voor- of dag-van, afhangende van klante se kapasiteitsverbintenisvoorkeure of die ontwerp van die program |
| Kies Gedrag | -Klante sal tipies inteken op geleenthede, aangesien hulle vooraf toegewyde beurtkragkapasiteit het. |
| Sertifisering
Gebeurtenisse |
- Tipies twee per jaar (Toets) |
OpenADR-kenmerke vir kapasiteitsbiedprogramme
| Gebeurtenis seine | –'N EENVOUDIGE sein met vlakke 1 tot 3 gekarteer na die hoeveelheid beurtkrag. As die program slegs 'n enkele vlak van beurtkrag ondersteun, moet dit na vlak 1 gekarteer word. Vir programme met veelvuldige vlakke van beurtkrag, moet die kleinste verandering van normale werking na die vlak 1 gekarteer word, met die beurtkragwaardes gekarteer na vlakke 2 en 3 in toenemende mate van beurtkrag.
-As die ontplooiing B pro ondersteunfile VENs, bykomend tot die EENVOUDIGE sein, kan 'n BID_LOAD en/of BID_PRICE sein ingesluit word in die loonvrag met seintipes stelpunt en prys, en eenhede van kragReële en valutaPerKW onderskeidelik. Die BID_LOAD sal die versoekte beurtkrag tot kapasiteitsbedrag bod deur die aggregator/kliënt weerspieël, en die BID_PRICE sal die aansporingsbod deur die aggregator/kliënt weerspieël. Sien Bylae A vir bvamples. |
| Kies antwoorde | -VTN'e wat gebeure stuur moet die oadrResponseRequired-element op "altyd" stel, wat vereis dat die VEN reageer met 'n optIn of optOut
-As aggregators/kliënte het vooraf-toegewyde kapasiteit VENs moet reageer met optIn. 'n Wegtrekking kan in reaksie op die geleentheid gestuur word, maar dit is 'n informele beskikbaarheidsaanduiding, nie 'n formele onttrekking van die geleentheid nie. - Die oadrCreateOpt loonvrag sal tipies nie gebruik word nie om hulpbronne wat aan geleenthede deelneem, te kwalifiseer aangesien die vrag tipies 'n enkele saamgevoegde entiteit is. |
| Gebeurtenisbeskrywer | -Die gebeurtenis prioriteit moet op 1 gestel word tensy die programreëls of VTN-konfigurasie anders spesifiseer
–Toetsgebeurtenisse kan gebruik word met Capacity Bidding-programme. As hulle toegelaat word, moet die testEvent-element op "true" gestel word om die toetsgebeurtenis aan te dui. As bykomende geparameteriseerde inligting in hierdie element vereis word, kan dit volg op "waar" geskei deur 'n spasie met hierdie bykomende inligting. |
| Gebeurtenis aktiewe tydperk | – eiRampUp, eiRecovery, toleransie-elemente word tipies nie gebruik nie |
| Basislyne | –Basislyne is tipies nie by die geleentheid se loonvrag ingesluit nie aangesien hierdie data gewoonlik nie beskikbaar is op die tydstip waarop die geleentheid begin word nie. Beide nutsdienste en aggregators/kliënte sou egter view die insluiting van basislyninligting by gebeurtenisse as nuttig. |
| Gebeurtenis-teikening | -Kapasiteitbiedprogramme onderskei gewoonlik nie tussen hulpbronne vir 'n gegewe kliënt nie. Teikening spesifiseer gewoonlik die venID, wat aandui dat al die hulpbronne wat met die VEN geassosieer word, moet deelneem, of sluit 'n hulpbron-ID verteenwoordiger van die saamgevoegde vrag in geassosieer met VEN. |
| Verslagdoeningsdienste | ISO Capacity Bidding-programme vereis tipies TELEMETRY_USAGE verslae met powerReal datapunte. Sien bvamples in Bylae A.
Telemetrie-verslagdoening vir nuts-kapasiteitsbieding word gewoonlik nie vereis nie. Let daarop dat telemetrie-verslagdoening B pro vereisfile VENs. Verwys na Bylae B vir bvamples van verslae van nutsvlieëniers wat van toepassing kan wees op hierdie tipe program. |
| Opt Dienste | –Gebruik van die Opt-diens om tydelike beskikbaarheidskedules te kommunikeer sal gewoonlik nie gebruik word nie as deel van 'n kapasiteitsbiedprogram aangesien kliënte vooraf hul beskikbaarheid verbind het. Hierdie diens kan egter nuttig wees as 'n informele manier vir deelnemers om 'n gebrek aan beskikbaarheid aan te dui vir versagtende redes soos toerustingonderbreking. |
| Registrasie Dienste | Polling intervalle deur die VTN aangevra vir tipiese dag-voor-programme word nie vereis om meer gereeld as een keer per uur te wees nie. Die gebruik van peiling vir hartklopopsporing of dagprogramme kan egter meer gereelde peiling vereis. |
Residensiële Termostaat Program
Hierdie program is verteenwoordigend van Direct Load Control (DLC) waar die Demand Response-sein die gedrag van beurtkraghulpbronne direk verander, sonder 'n laag van abstraksie tussen die ontvangs van die sein en die spesifieke beurtkragaksie wat geneem is.
Residensiële Termostaat DR Program Kenmerke
| Laai Profile Doelwit | - Piekaanvraagvermindering |
| Primêre drywers | -Verminderde kapitaaluitgawes en verlaagde energiekoste |
| Programbeskrywing | -Wanneer nutsdienste hoë groothandelmarkpryse of kragstelselnoodtoestande waarneem of verwag, kan hulle 'n gebeurtenis inisieer wat die gedrag van die kliënt se programmeerbare kommunikerende termostaat (PCT) oor 'n bepaalde tydperk (bv. 3:6-XNUMX:XNUMX op 'n warm) somer weekdag) om energieverbruik te verminder.
-Die verandering aan die PCT-gedrag in reaksie op die gebeurtenis kan 'n eenvoudige verandering in temperatuurstelpunt vir die duur van die gebeurtenis wees of 'n meer komplekse stel veranderinge, insluitend voorafverkoeling, wat die impak van die gebeurtenis op die kliënt se gemak verminder. vlak. |
| Kliëntaansporing | -Aansporings neem twee algemene vorme aan. Eerstens kan kliënte van 'n gratis PCT voorsien word of afslag/kortings aangebied word op PCT's wat deur klante gekoop is as 'n aansporing om by die DR-program in te skryf. Tweedens kan kliënte 'n deurlopende jaarlikse toelae ontvang vir voortgesette inskrywing in die program. Minder algemeen sal deurlopende aansporings wees wat aan kliënte betaal word op grond van werklike energievermindering tydens geleenthede. |
| Beoordeel ontwerp | - Hoofsaaklik 'n aansporingsprogram, waar kliënte afslag of gratis PCT's ontvang om by die DR-program in te skryf. Sommige programme kan 'n periodieke toelae of aansporingsbetalings betaal op grond van energievermindering tydens geleenthede.
|
| Teikenkliënt | -Residensieel |
| Teikenlading | -HVAC |
| Voorvereiste | -Gewoonlik geen, aangesien kliënte 'n PCT ontvang as deel van die programinskrywing
|
| Program Tydsraamwerk | - Dek tipies maande van die jaar waar piek energieverbruik voorkom, hoewel dit in sommige gevalle die hele jaar deur kan wees. |
| Gebeurtenisbeperkings | - Tipies Maandag tot Vrydag, vakansiedae uitgesluit, met opeenvolgende daggebeurtenisse gewoonlik toegelaat. |
| Gebeurtenis Dae | -Gewoonlik 9 tot 15 per jaar |
| Gebeurtenis Duur | -Gebeure kan enige tyd plaasvind, met duur wat wissel van 2 tot 4 uur, alhoewel gebeure tipies tydens die hoogste energieverbruik tye van die dag plaasvind. |
| Kennisgewing | - Tipies 'n dag wat voorlê, hoewel sommige programme kennisgewingstye so kort as 10 minute kan hê. |
| Kies Gedrag | - Daar word nie van klante vereis om aan geleenthede deel te neem nie, maar hulle sal outomaties ingeskryf word vir geleenthede, tensy hulle stappe doen om die geleentheid te ignoreer of handmatige aanpassings aan temperatuur tydens die geleentheid te maak. |
| Sertifisering
Gebeurtenisse |
-Gewoonlik geen |
OpenADR-kenmerke vir residensiële termostaatprogramme
| Gebeurtenis seine | –'N EENVOUDIGE sein met vlakke 1 tot 3 gekarteer na die verandering in PCT temperatuur stelpunt offset of termostatiese fietsry persentasietage. As 'n residensiële termostaatprogram 'n enkele verstelling/fietsry-komponent het, moet dit na vlak 1 gekarteer word. Vir programme met veelvuldige verstelling/fietsrykomponente, moet die kleinste verandering van normale werking na die vlak 1 gekarteer word, met die ander verstelling/fietsrywaardes gekarteer na vlak 2 en 3 in toenemende mate van beurtkrag impak.
-As die ontplooiing B pro ondersteunfile VENs, bykomend tot die SIMPLE sein, kan 'n LOAD_CONTROL sein ingesluit word in die loonvrag met 'n tipe van x-loadControlLevelOffset of x-loadControlCapacity om die verlangde temperatuurstelpuntverstelling of termostatiese fietsrypersentasie te spesifiseertage onderskeidelik. Daar word weer begin dat a eenheidstipe "temperatuur" word gebruik in loonvragte wat die x-loadControlLevelOffset seintipe gebruik om Celsius of Fahrenheit vir die afwyking aan te dui. Sien Bylae A vir bvamples. |
| Kies antwoorde | -VTN'e wat gebeure stuur moet die oadrResponseRequired-element op "altyd" stel, wat vereis dat die VEN reageer met 'n optIn of optOut
– VENs moet reageer met optIn, tensy daar 'n spesifieke oorheersingsaksie deur die kliënt geneem is. - Die oadrCreateOpt loonvrag kan deur VENs gebruik word om die deelname van hulpbronne aan 'n geleentheid te kwalifiseer. Byvoorbeeld, 'n gebeurtenis kan die hulpbron-ID's van twee termostate teiken wat afsonderlike HVAC-stelsels beheer. As die kliënt besluit dat slegs een van die HVAC-stelsels aan die geleentheid kan deelneem, sal dit met die oadrCreateOpt-loonvrag aan die VTN gekommunikeer word. Let daarop dat die oadrCreateOpt loonvrag slegs deur B pro ondersteun wordfile VENs |
| Gebeurtenisbeskrywer | -Die gebeurtenis prioriteit moet op 1 gestel word tensy die programreëls of VTN-konfigurasie anders spesifiseer
–Toetsgebeurtenisse word gewoonlik nie gebruik nie met Residensiële Termostaat-programme. As hulle egter toegelaat word, moet die testEvent-element op "true" gestel word om die toetsgebeurtenis aan te dui. As bykomende geparameteriseerde inligting in hierdie element vereis word, kan dit volg op "waar" geskei deur 'n spasie met hierdie bykomende inligting. |
| Gebeurtenis aktiewe tydperk | –Randomisering word tipies gebruik vir residensiële termostaatgebeurtenisse deur die toleransie-element te gebruik
– eiRampUp- en eiRecovery-elemente word gewoonlik nie gebruik nie |
| Basislyne | –Basislyne is tipies nie by die geleentheid se loonvrag ingesluit nie |
| Gebeurtenis-teikening | -Residensiële termostaatprogramme teiken HVAC-hulpbronne wat deur PCT's beheer word. Teikening spesifiseer gewoonlik die hulpbron-ID's van die HVAC-stelsels (dws die termostaat) wat met VEN geassosieer word of die venID met die gebeurtenissein toestelklas teiken gestel op Termostaat |
| Verslagdoeningsdienste | –Telemetrie-verslaggewing word gewoonlik nie gebruik nie aangesien dit nie absoluut nodig is vir residensiële termostaatprogramme nie
Verwys na Bylae B vir bvamples van verslae van nutsvlieëniers wat van toepassing kan wees op hierdie tipe program. |
| Opt Dienste | –Gebruik van die Opt-diens om tydelike beskikbaarheidskedules te kommunikeer sal gewoonlik nie gebruik word nie as deel van 'n CPP-program. |
| Registrasie Dienste | Polling intervalle deur die VTN aangevra vir tipiese dag-vooruit Residensiële Termostaat-programme word nie vereis om meer gereeld as een keer per uur te wees nie. Die gebruik van peiling vir hartklopopsporing kan egter meer gereelde peiling vereis, net soos residensiële termostaatprogramme met aansienlik korter kennisgewingstye. |
Vinnige DR-versending
Vinnige DR-versendingsprogramkenmerke
| Laai Profile Doelwit | -Verstuur hulpbronne om lasreaksie in "intydse" te bereik |
| Primêre drywers | -Grid betroubaarheid en bykomende dienste |
| Programbeskrywing | Vinnige DR word deur ISO/hulpprogramme gebruik om vooraf-toegewyde lasreaksie in "intydse" te verkry. Hierdie vooraf-toegewyde lasreaksie word deur ISO/nutsdienste gebruik wanneer hulle toestande waarneem wat onmiddellike optrede vereis om die stabiliteit en integriteit van die rooster te handhaaf. Intydse beteken dat hulpbronne tipies versend word met 'n vertraging wat wissel van 10 minute vir hulpbronne wat as reserwes gebruik word tot 2 sekondes vir hulpbronne wat vir reguleringsdoeleindes gebruik word.
Die grootte van die lasreaksie moet groot genoeg wees om 'n verskil te maak in die versagting van die roostertoestand en dus is hulpbronne tipies baie groot en word dit dikwels deur aggregators bestuur as deel van 'n saamgevoegde hulpbron. Minimum groottes vir die lasreaksie vir 'n hulpbron om te kwalifiseer om aan bykomende dienste deel te neem, is tipies ongeveer 500 kW, maar kan so laag as 100 kW vir sommige programme wees. Let daarop dat indien die hulpbron as 'n reserwe gebruik word, dit tipies gevra sal word om vrag te verminder (dws af te werp), maar as dit vir reguleringsdoeleindes gebruik word, kan dit versend word om vrag óf te verhoog óf te verminder. |
| Kliëntaansporing | Aggregeerders/kliënte ontvang tipies twee tipes aansporings. Eerstens ontvang hulle 'n betaling om 'n spesifieke hoeveelheid lasreaksie beskikbaar te stel vir DR-geleenthede gedurende 'n toekomstige tydvenster. Die hoeveelheid lasreaksie, die tydvenster van beskikbaarheid en die bedrag wat betaal moet word, word tipies deur die aggregator/kliënt bepaal. Tweedens, as 'n gebeurtenis gedurende die toekomstige tydvenster geroep word, 'n betaling gebaseer op die hoeveelheid lasreaksie oor die duur van die gebeurtenis. |
| Beoordeel ontwerp | Deelnemers aan die program dien 'n bod in wat die lasreaksie aandui wat hulle bereid is om gedurende 'n toekomstige tydvenster beskikbaar te stel. Die bod sluit tipies ook die betaling in wat die aggregator/kliënt bereid is om te aanvaar vir die lasreaksie.
In nuts-/ISO-markte word die bod tipies óf die dag vooruit óf die dag van die tydperk waarvoor die verbintenis gemaak word ingedien. As deel van hul kwalifikasie en registrasie in die markte word verskeie prestasie-omhul-parameters met die hulpbron geassosieer, soos ramp tempo en minimum en maksimum bedryfslimiete. Sulke parameters bepaal hoe dit versend sal word. As 'n deelnemer se bod aanvaar word, kan 'n betaling aan die kliënt gemaak word vir hul voorafverbintenis, selfs al is daar geen gebeurtenisse wat gedurende die tydvenster genoem word nie. As 'n geleentheid gedurende die tydsperiode uitgeroep word, kan die kliënt bykomende betalings ontvang vir hul prestasie tydens die geleentheid. Sulke prestasie-gebaseerde betalings kan gebaseer wees op 'n aantal faktore, insluitend hoeveelheid energie, krag, hoe noukeurig die hulpbron die versendinginstruksies volg, en 'n "kilometer" betaling wat weerspieël hoeveel hul vrag profile moes verander tydens die geleentheid. Sommige van hierdie parameters soos energie en krag kan met betrekking tot 'n basislyn wees. |
| Teikenkliënt | -Aggregeerders en self-aggregeerde C&I-kliënte |
| Teikenladings | – Diegene wat kan reageer op intydse versendings. |
| Voorvereiste | -Klant moet intervalmeting hê
-Moet voldoen aan minimum grootte vereistes vir die lasreaksie -Moet in staat wees om op intydse versendings te reageer - Moet tipies intydse telemetrie verskaf wat die huidige lasreaksie toon |
| Program Tydsraamwerk | - Enige tyd |
| Gebeurtenisbeperkings | -geen |
| Gebeurtenis Dae | -geen |
| Gebeurtenis Duur | - Tipies kort (minder as 30 minute), maar sal in elk geval nooit die tydsperiode oorskry wat die deelnemer die hulpbron beskikbaar gestel het toe hulle hul bod ingedien het nie. |
| Kennisgewing | -geen |
| Kies Gedrag | -Kliënte word by verstek ingeteken op gebeurtenisse, aangesien hulle voorafbepaalde lasreaksie het |
| Sertifisering
Gebeurtenisse |
- Tipies een per jaar (Toets) |
OpenADR-kenmerke vir kapasiteitsbiedprogramme
| Gebeurtenis seine | –'N EENVOUDIGE sein met vlakke 1 tot 3 gekarteer na die hoeveelheid lasreaksie. As die program slegs 'n enkele vlak van lasreaksie ondersteun, moet dit na vlak 1 gekarteer word. Vir programme met veelvuldige vlakke van lasreaksie, moet die kleinste verandering van normale werking na vlak 1 gekarteer word, met die beurtkragwaardes gekarteer na vlakke 2 en 3 in toenemende mate van lasreaksie.
-As die ontplooiing B pro ondersteunfile VENs, bykomend tot die SIMPLE sein, kan 'n versending in die vorm van 'n LOAD_DISPATCH sein ingesluit word in die loonvrag met sein tipes stelpunt of delta, en eenhede van kragReal. Hierdie sein verteenwoordig die verlangde "bedryfspunt" van die las en kan uitgedruk word as 'n absolute hoeveelheid mW (dws stelpunt) of 'n relatiewe aantal mW (dws delta) vanaf die hulpbronne huidige werkspunt. Sien Bylae A vir bvamples. |
| Kies antwoorde | -VTN'e wat gebeure stuur moet die oadrResponseRequired-element op "altyd" stel, wat vereis dat die VEN reageer met 'n optIn of optOut
-As aggregators/kliënte het vooraf-toegewyde kapasiteit VENs moet reageer met optIn. 'n Wegtrekking kan in reaksie op die geleentheid gestuur word, maar dit is 'n informele beskikbaarheidsaanduiding, nie 'n formele onttrekking van die geleentheid nie. - Die oadrCreateOpt loonvrag sal tipies nie gebruik word nie om hulpbronne wat aan geleenthede deelneem, te kwalifiseer aangesien die vrag tipies 'n enkele saamgevoegde entiteit is. |
| Gebeurtenisbeskrywer | -Die gebeurtenis prioriteit moet op 1 gestel word tensy die programreëls of VTN-konfigurasie anders spesifiseer
–Toetsgebeurtenisse kan gebruik word, veral tydens die registrasie en kwalifikasie van 'n hulpbron. As hulle toegelaat word, moet die testEvent-element op "true" gestel word om die toetsgebeurtenis aan te dui. As bykomende geparameteriseerde inligting in hierdie element vereis word, kan dit volg op "waar" geskei deur 'n spasie met hierdie bykomende inligting. |
| Gebeurtenis aktiewe tydperk | – Toleransie-elemente word nie gebruik nie. Die eiRampUp- en eiRecovery-periodes is tipies deel van 'n hulpbron se parameters wanneer hulle registreer en kan gebruik word. As gevolg van die aard van die versendings kan dit oop wees en daar mag dus geen eindtyd vir die geleentheid wees nie. |
| Basislyne | –Basislyne is tipies nie by die geleentheid se loonvrag ingesluit nie aangesien hierdie data gewoonlik nie beskikbaar is op die tydstip waarop die geleentheid begin word nie. Beide nutsdienste en aggregators/kliënte sou egter view die insluiting van basislyninligting by gebeurtenisse as nuttig. |
| Gebeurtenis-teikening | -Kapasiteitbiedprogramme onderskei gewoonlik nie tussen hulpbronne vir 'n gegewe kliënt nie. Teikening spesifiseer gewoonlik die venID, wat aandui dat al die hulpbronne wat met die VEN geassosieer word, moet deelneem, of sluit 'n hulpbron-ID verteenwoordiger van die saamgevoegde vrag in geassosieer met VEN. |
| Verslagdoeningsdienste | Vinnige DR-programme vereis gewoonlik TELEMETRY_USAGE verslae met powerReal datapunte. Die gebruiksverslag beeld die hulpbronne se huidige bedryfspunt uit en word deur die Utility/ISO gebruik om te bepaal hoe noukeurig die hulpbron die versendinginstruksie volg wat gestuur is.
In sommige gevalle kan die telemetrie ander datapunte insluit soos voltage lesings en ladingtoestand (dws energie) in die geval waar die hulpbronne een of ander vorm van berging is. In sommige gevalle kan die rapporteringsfrekwensie so hoog as elke 2 sekondes wees. Let daarop dat telemetrie-verslagdoening B pro vereisfile VENs. Sien Bylae A vir bvamples. Verwys ook na Bylae B vir bvamples van verslae van nutsvlieëniers wat van toepassing kan wees op hierdie tipe program. |
| Opt Dienste | –Gebruik van die Opt-diens om tydelike beskikbaarheid te kommunikeer skedules sal gewoonlik nie gebruik word nie aangesien kliënte vooraf hul beskikbaarheid verbind het. Hierdie diens kan egter nuttig wees as 'n informele manier vir deelnemers om 'n gebrek aan beskikbaarheid aan te dui vir versagtende redes soos toerustingonderbreking. |
| Registrasie Dienste | As gevolg van die lae vertragingsvereistes van die intydse versendings slegs stootinteraksiepatrone word gebruik. |
Residensiële Elektriese Voertuig (EV) Tyd van Gebruik (TOU) Program
Residensiële EV TOU Program Kenmerke
| Laai Profile Doelwit | 'n Tariefstruktuur waardeur die koste van die laai van elektriese voertuie aangepas word om verbruikers te laat verander verbruikspatrone. |
| Primêre drywers | Residensiële energieverbruik bereik pieke in die aand. Aangesien EV-laai 4-8 uur neem, kan dit vir 'n paar uur vertraag word om vragpieke te verskuif. |
| Programbeskrywing | Kliënte wat 'n elektriese voertuig het, kan inteken vir 'n EV-TOU-tarief (Elektriese Voertuig Tyd-van-Gebruik) en laer tariewe ontvang vir die laai van hul voertuig gedurende spitstye, soos tussen middernag en 5:XNUMX EV-TOU-tariewe is aangebied om kliënte aan te moedig om daaglikse gebruik van elektrisiteit te beperk, wanneer die vraag na elektrisiteit die hoogste is. |
| Kliëntaansporing | Minder duur laai vir EV's. |
| Beoordeel ontwerp | TOU met mid-dag spits, oggend en aand mid-piek, en 12AM-5AM buite spits |
| Teikenkliënt | EV Eienaar met 'n vrag profile wat in die aand 'n hoogtepunt bereik. |
| Teikenladings | EV-laaiers |
| Voorvereiste | Kliënt moet 'n slim meter en EV hê |
| Program Tydsraamwerk | Die hele jaar |
| Gebeurtenisbeperkings | Geen |
| Gebeurtenis Dae | Elke dag, of slegs weeksdae |
| Gebeurtenis Duur | 5-8 uur |
| Kennisgewing | Kliënt word in kennis gestel van prysvlakke op hul maandelikse rekeninge, en VTN'e stuur gebeurtenisseine dag vooruit. |
| Kies Gedrag | Belastingbetalers kan hul tariefplan verander soos hulle normaalweg met 'n nutsdiens sou doen. |
| Sertifisering
Gebeurtenisse |
OpenADR-kenmerke vir residensiële EV TOU-programme
| Gebeurtenis seine | ELECTRICITY_PRICE seine met werklike prysvlakke, sowel as EENVOUDIGE seine om deelname deur 2.0a VENs moontlik te maak
Sien Bylae A vir bvamples. |
| Kies antwoorde | Teken altyd in deur VENs |
| Gebeurtenisbeskrywer | Een geleentheid per week, met geleentheidsintervalle vir elke prysvlak |
| Gebeurtenis aktiewe tydperk | Ten minste 24 uur kennisgewing moet gebruik word. Elke gebeurtenisinterval behoort die TOU-koersvlak vas te lê |
| Basislyne | NVT |
| Gebeurtenis-teikening | Geen gevorderde teikening vereis nie, slegs VEN-vlak teiken. |
| Verslagdoeningsdienste | Geen verslagdoening nodig nie, alle data kan van die meter af kom.
Verwys na Bylae B vir bvamples van verslae van nutsvlieëniers wat van toepassing kan wees op hierdie tipe program. |
| Opt Dienste | Opt-dienste sal nie relevant wees vir hierdie programtipe nie. |
| Registrasie Dienste | Verbruikers sal hul VEN vooraf voorsien met die nutsmiddel om prysseine te ontvang. |
Openbare stasie elektriese voertuig (EV) Real-Time Pryse Program
Publieke Stasie EV RTP Program Kenmerke
| Laai Profile Doelwit | 'n Vraagreaksie-aktiwiteit waardeur die koste van die laai van elektriese voertuie aangepas word om die realiteite van piekpryse na verbruikers te verskuif. |
| Primêre drywers | Die prys van elektrisiteit is veranderlik oor 'n dag. Hierdie program het ten doel om die prys van heffing meer doeltreffend te pas by die koste van elektrisiteit. |
| Programbeskrywing | Openbare laaiers kan by werkplekke, in openbare parkeerterreine en by kleinhandelwinkels bestaan. Hierdie program stuur intydse pryse deur aan potensiële laaiers voordat hulle inprop, sodat hulle 'n ingeligte besluit kan neem of hulle hul motor wil laai of nie. |
| Kliëntaansporing | Minder duur laai tydens spitstye. |
| Beoordeel ontwerp | Pryse kan verander hourly, maar sodra 'n klant kies om hul motor aan te sluit, word die tarief vasgestel vir die duur van laai. |
| Teikenkliënt | Enigiemand met 'n EV wat moet laai terwyl hy weg is van die huis af. |
| Teikenladings | Openbare EV-laaiers |
| Voorvereiste | EV-laaiers moet internetgekoppel en OpenADR2.0b-gesertifiseer wees, of aan 'n OpenADR2.0b VEN-poort gekoppel wees. |
| Program Tydsraamwerk | Die hele jaar |
| Gebeurtenisbeperkings | Geen |
| Gebeurtenis Dae | Elke dag, of slegs weeksdae |
| Gebeurtenis Duur | 1 uur of langer |
| Kennisgewing | Kliënt word in kennis gestel van die heersende tarief wanneer hulle kies om hul motor in te prop. |
| Kies Gedrag | Kliënte kan onttrek deur te besluit om nie te hef nie. |
| Sertifisering
Gebeurtenisse |
OpenADR-kenmerke vir openbare stasie EV RTP-programme
| Gebeurtenis seine | ELECTRICITY_PRICE seine met pryse.
Sien Bylae A vir bvamples. |
| Kies antwoorde | Teken altyd in deur VENs |
| Gebeurtenisbeskrywer | Gebeurtenisse moet aaneenlopend wees en een interval bevat. |
| Gebeurtenis aktiewe tydperk | Ten minste 1 uur-kennisgewing moet gebruik word, maar nutsdienste kan kies om dag-voor-kennisgewing te gebruik. |
| Basislyne | NVT |
| Gebeurtenis-teikening | Geen gevorderde teiken word vereis nie, maar teiken kan gebruik word om pryse na spesifieke transformators, toevoerders of geografiese gebiede te stuur. |
| Verslagdoeningsdienste | Geen verslagdoening nodig nie, maar kan gebruik word indien verlang.
Verwys na Bylae B vir bvamples van verslae van nutsvlieëniers wat van toepassing kan wees op hierdie tipe program. |
| Opt Dienste | Opt-dienste sal nie relevant wees vir hierdie programtipe nie. |
| Registrasie Dienste | 'n Laaistasieverkoper sal hul toestelle van 'n nutsmaatskappy se VTN voorsien. |
Verspreide Energiehulpbronne (DER) DR-program
Die volgende programbeskrywing is hipoteties en is gebaseer op 'n navorsingsartikel (verwysing na Rish se referaat) wat beskryf hoe nutskliënte DER-bergingsbronne kan gebruik om deel te neem aan DR-programme soos intydse prysbepaling (RTP)-programme.
Verspreide Energiehulpbronne (DER) Programkenmerke
| Laai Profile Doelwit | 'n Vraagreaksie-aktiwiteit wat gebruik word om die integrasie van verspreide energiebronne in die slimnetwerk glad te maak. |
| Primêre drywers | -Verminderde kapitaaluitgawes en verlaagde energiekoste |
| Programbeskrywing | Kliënte met DER-hulpbronne wat energie kan oes en dit kan stoor, kan die koste van die aankoop van elektrisiteit vanaf die netwerk gedurende hoë prysperiodes verminder deur eers gestoorde energiebronne te gebruik, gevolg deur die implementering van beurtkragstrategieë |
| Kliëntaansporing | Vermoë om koste te beheer gedurende tye van hoë elektrisiteitspryse deur gebruik te maak van gestoorde energie wat deur PV of ander maniere gegenereer word en beurtkragstrategieë te implementeer |
| Beoordeel ontwerp | Elektrisiteitstariewe wissel met groothandelmarkpryse of 'n tarief wat wissel as 'n funksie van tyd van die dag, seisoen of temperatuur |
| Teikenkliënt | Kliënte met hulpbronne vir energieberging |
| Teikenladings | Enige |
| Voorvereiste | Energiebergingsbronne |
| Program Tydsraamwerk | Enige tyd |
| Gebeurtenisbeperkings | Geen |
| Gebeurtenis Dae | Elke dag |
| Gebeurtenis Duur | 24 uur |
| Kennisgewing | Dag wat voorlê |
| Kies Gedrag | NVT – 'n Beste poging-program |
| Sertifisering
Gebeurtenisse |
Geen |
OpenADR-kenmerke vir verspreide energiebronne (DER)
| Gebeurtenis seine | ELECTRICITY_PRICE seine met 24 een uur intervalle van pryse oor 'n 24 uur tydperk. Hierdie sein sal die B pro vereisfile. Hierdie program leen hom nie tot EENVOUDIGE sein vir A pro niefile VENs.
Sien Bylae A vir bvamples. |
|
| Kies antwoorde | -VTN'e wat gebeure stuur moet die oadrResponseRequired-element op "nooit" stel, wat verhoed dat VENs reageer. | |
| Gebeurtenisbeskrywer | -Die gebeurtenis prioriteit moet op 1 gestel word tensy die programreëls of VTN-konfigurasie anders spesifiseer | |
| Gebeurtenis aktiewe tydperk | 24 uur met 1 uur intervalle met dag vooruit kennisgewing | |
| Basislyne | NVT | |
| Gebeurtenis-teikening | Geen gevorderde teiken word vereis anders as die venID nie | |
| Verslagdoeningsdienste | Geen verslagdoening nodig nie
Verwys na Bylae B vir bvamples van verslae van nutsvlieëniers wat van toepassing kan wees op hierdie tipe program. |
|
| Opt Dienste | Nie gebruik nie | |
| Registrasie Dienste | Polling intervalle deur die VTN aangevra vir tipiese dagvooruit-programme word nie vereis om meer gereeld as een keer per uur te wees nie. Die gebruik van peiling vir hartklopopsporing kan egter meer gereelde peiling vereis, net soos residensiële termostaatprogramme met aansienlik korter kennisgewingstye. |
– Sample Data en loonvrag sjablone
Die volgende tabelle en XML-loonvrag samples sal implementeerders van tasbare examplees van hoe die DR-sjablone in hierdie dokument geïmplementeer moet word. Die volgende naamruimtevoorvoegsels word in die loonvrag bvamples:
- 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”
Kritiese piekprysprogram (CPP)
CPP Scenario 1 – Eenvoudige gebruik geval, A of B Profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begin Tyd: 1:XNUMX
- Tydsduur: 4 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 1
- Seinnaam: EENVOUDIG
- Sein Tipe: vlak
- Eenhede: NVT
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 1
- Seinteiken: NVT
- Gebeurtenisteiken(s): venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
CPP Scenario 2 – Tipiese gebruiksgeval, B profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begintyd: 1:XNUMX
- Tydsduur: 4 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 2
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0, 1, 2, 3
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 1 of 2
- Sein teiken: Geen
- Seinnaam: ELECTRICITY_PRICE
- Sein Tipe: prys
- Eenhede: USD per Kwh
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): $0.10 tot $1.00
- Sein teiken: Geen
- Gebeurtenisteikens: venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
CPP Scenario 3 – Komplekse gebruiksgeval
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begin Tyd: 2:XNUMX
- Tydsduur: 6 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine:2
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0,1, 2, 3)
- Aantal intervalle 3
- Interval Duur(e): 1 uur, 4 uur, 1 uur
- Tipiese intervalwaarde(s): 1, 2, 1 (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Seinnaam: ELECTRICITY_PRICE
- Sein Tipe: prys
- Eenhede: USD per Kwh
- Aantal intervalle 3
- Interval Duur(e): 1 uur, 4 uur, 1 uur
- Tipiese intervalwaarde(s): $0.50, $0.75, $0.50 (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Gebeurtenis-teikens: Hulpbron_1, Hulpbron_2, Hulpbron_3
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
CPP Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Case
OadrDisReq091214_043740_513
TH_VTN
Gebeurtenis091214_043741_028_0
0
http://Markkonteks1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
ver
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
EENVOUDIG
vlak
SIG_01
0.0
PT4H
0
0.75
ELECTRICITY_PRICE
prys
SIG_02
geldeenheidPerKWh
USD
geen
0.0
venID_1234
altyd
CBP Scenario 1 – Eenvoudige gebruik geval, A of B Profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begin Tyd: 1:XNUMX
- Tydsduur: 4 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 1
- Seinnaam: EENVOUDIG
- Sein Tipe: vlak
- Eenhede: NVT
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 1
- Seinteiken: NVT
- Gebeurtenisteiken(s): venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
CBP Scenario 2 – Tipiese gebruiksgeval, B profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begintyd: 1:XNUMX
- Tydsduur: 4 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 2
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0,1, 2, 3
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 1 of 2
- Sein teiken: Geen
- Seinnaam: BID_LOAD
- Seintipe: stelpunt
- Eenhede: powerReal
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 20kW tot 100kW
- Sein teiken: Geen
- Gebeurtenisteikens: venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
CBP Scenario 3 – Komplekse gebruiksgeval
- Gebeurtenis
- Kennisgewing: Dag van gebeurtenis (hoeveel ure?)
- Begin Tyd: 1:XNUMX
- Tydsduur: 6 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine:3
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0,1, 2, 3)
- Aantal intervalle: 2
- Interval Duur(e): 3 uur, 3 uur
- Tipiese intervalwaarde(s): 1, 2 (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Seinnaam: BID_LOAD
- Seintipe: stelpunt
- Eenhede: powerReal
- Aantal intervalle 2
- Interval Duur(e): 3 uur, 3 uur
- Tipiese intervalwaarde(s): 40kW, 80kW (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Seinnaam: BID_PRICE
- Sein Tipe: prys
- Eenhede: valutaPerKW
- Aantal intervalle 1
- Interval Duur(e): 6 uur
- Tipiese intervalwaarde(s): $3.10
- Sein teiken: Geen
- Gebeurtenis-teikens: Hulpbron_1, Hulpbron_2, Hulpbron_3
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Berigte)
- Verslag Naam: TELEMETRY_USAGE
- Verslag Tipe: gebruik
- Eenhede: powerReal
- Leestipe: Direkte lees
- Rapporteerfrekwensie: elke 1 uur
CBP Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Case
OadrDisReq091214_043740_513
TH_VTN
Gebeurtenis091214_043741_028_0
0
http://Markkonteks1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
ver
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT24H
PT4H
0
2.0
EENVOUDIG
vlak
SIG_01
0.0
PT4H
0
80.0
BID_LOAD
stelpunt
SIG_02
RealPower
W
k
60.0
<power:voltage>220.0tage>
waar
0.0
venID_1234
altyd
Residensiële Termostaat Program
Residensiële termostaat scenario 1 – Eenvoudige gebruik geval, A of B Profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begin Tyd: 1:XNUMX
- Tydsduur: 4 uur
- Randomisering: 10 minute
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 1
- Seinnaam: EENVOUDIG
- Sein Tipe: vlak
- Eenhede: NVT
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 1
- Seinteiken: NVT
- Gebeurtenisteiken(s): Hulpbron_1
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
Residensiële termostaat Scenario 2 – Tipiese gebruiksgeval, B profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begintyd: 1:XNUMX
- Tydsduur: 4 uur
- Randomisering: 10 minute
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 2
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0,1, 2, 3
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 1 of 2
- Sein teiken: Geen
- Seinnaam: LOAD_CONTROL
- Seintipe: x-loadControlLevelOffset
- Eenhede: Temperatuur
- Aantal intervalle 1
- Interval Duur(e): 4 uur
- Tipiese intervalwaarde(s): 2 tot 6 grade Fahrenheit
- Sein teiken: Geen
- Gebeurtenisteikens: Hulpbron_1, Hulpbron_2
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN verwagte reaksie: optIn, Possible outOut (oadrCreateOpt)
- Verslae
- Geen
Residensiële termostaat Scenario 3 – Komplekse gebruiksgeval
- Gebeurtenis
- Kennisgewing: Dag van gebeurtenis
- Begin Tyd: 1:XNUMX
- Tydsduur: 6 uur
- Randomisering: 10 minute
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine:3
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0,1, 2, 3)
- Aantal intervalle: 2
- Interval Duur(e): 3 uur, 3 uur
- Tipiese intervalwaarde(s): 1, 2 (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Seinnaam: BID_LOAD
- Seintipe: x-loadControlCapacity
- Eenhede: Geen
- Aantal intervalle 2
- Interval Duur(e): 3 uur, 3 uur
- Tipiese intervalwaarde(s): 0.9, 0.8 (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Gebeurtenis-teikens: Hulpbron_1, Hulpbron_2, Hulpbron_3
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN verwagte reaksie: optIn, Possible outOut (oadrCreateOpt)
- Berigte)
- Geen
Residensiële termostaat Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Case
OadrDisReq091214_043740_513
TH_VTN
Gebeurtenis091214_043741_028_0
0
http://Markkonteks1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
ver
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT4H
PT10M
PT24H
PT4H
0
2.0
EENVOUDIG
vlak
SIG_01
0.0
PT4H
0
6.0
LAA_BEHEER
x-loadControlLevelOffset
SIG_02
temperatuur
fahrenheit
geen
0.0
hulpbron_1
hulpbron_2
altyd
Vinnige DR Scenario 1 – Eenvoudige gebruik geval, A of B Profile
- Gebeurtenis
- Kennisgewing: 10 minute
- Begin Tyd: 1:XNUMX
- Tydsduur: 0 (oop geëindig)
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 1
- Seinnaam: EENVOUDIG
- Sein Tipe: vlak
- Eenhede: NVT
- Aantal intervalle 1
- Interval Tydsduur(s): 0 (oop geëindig)
- Tipiese intervalwaarde(s): 1
- Seinteiken: NVT
- Gebeurtenisteiken(s): venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
Vinnige DR Scenario 2 – Tipiese gebruiksgeval, B profile
- Gebeurtenis
- Kennisgewing: 10 minute
- Begintyd: 1:XNUMX
- Tydsduur: 30 minute
- Randomisering: Geen
- Ramp Op: 5 minute
- Herstel: 5 minute
- Aantal seine: 2
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0,1, 2, 3
- Aantal intervalle 1
- Interval Duur(e): 30 minute
- Tipiese intervalwaarde(s): 1 of 2
- Sein teiken: Geen
- Seinnaam: LOAD_DISPATCH
- Sein Tipe: delta
- Eenhede: powerReal
- Aantal intervalle 1
- Interval Duur(e): 30 minute
- Tipiese intervalwaarde(s): 500 kW tot 2mW
- Sein teiken: Geen
- Gebeurtenisteikens: venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Verslag Naam: TELEMETRY_USAGE
- Verslag Tipe: gebruik
- Eenhede: powerReal
- Leestipe: Direkte lees
- Rapporteerfrekwensie: elke 1 minuut
Vinnige DR Scenario 3 – Komplekse gebruiksgeval
- Gebeurtenis
- Kennisgewing: 10 minute
- Begin Tyd: 1:XNUMX
- Tydsduur: 30 minute
- Randomisering: Geen
- Ramp Op: 5 minute
- Herstel: 5 minute
- Aantal seine:2
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0,1, 2, 3)
- Aantal intervalle: 2
- Interval Duur(e): 15 minute, 15 minute
- Tipiese intervalwaarde(s): 1, 2 (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Seinnaam: LOAD_DISPATCH
- Seintipe: stelpunt
- Eenhede: powerReal
- Aantal intervalle 2
- Interval Duur(e): 15 minute, 15 minute
- Tipiese intervalwaarde(s): 800kW, 900kW (vir elke interval onderskeidelik)
- Sein teiken: Geen
- Gebeurtenisteikens: Hulpbron_1
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Berigte)
- Verslag Naam: TELEMETRY_USAGE
- Verslag Tipe: gebruik
- Eenhede: powerReal en voltage
- Leestipe: Direkte lees
- Rapporteerfrekwensie: elke 5 sekondes
Vinnige DR Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Case
OadrDisReq091214_043740_513
TH_VTN
Gebeurtenis091214_043741_028_0
0
http://Markkonteks1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
ver
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT10M
PT10M
<ei:x-eiRampOp>
PT5M
</ei:x-eiRampOp>
PT5M
PT10M
0
2.0
EENVOUDIG
vlak
SIG_01
0.0
PT10M
0
500.0
LAA_VERSENDING
delta
SIG_02
RealPower
W
k
60.0
<power:voltage>220.0tage>
waar
0.0
venID_1234
altyd
Vinnige DR Sample Rapporteer Metadata Loonvrag – Tipiese B Profile Gebruik Case
RegReq120615_122508_975
PT10M
rID120615_122512_981_0
hulpbron 1
gebruik
Regte Energie
Wh
k
Direkte lees
http://Markkonteks1
<oadr:oadrSamplingKoers>
PT1M
PT10M
onwaar
</oadr:oadrSamplingKoers>
0
ReportSpecID120615_122512_481_2
METADATA_TELEMETRY_USAGE
<ei:createdDateTime>2015-06-12T19:25:12Z</ei:createdDateTime>
ec27de207837e1048fd3
Vinnige DR Sample Verslagversoek loonvrag – Tipiese B Profile Gebruik Case
VerslagReqID130615_192625_230
VerslagReqID130615_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-nie van toepassing nie
VEN130615_192312_582
Vinnige DR Sample Rapporteer Data Loonvrag – Tipiese B Profile Gebruik Case
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
Kwaliteit goed – nie spesifiek nie
RP_54321
VerslagReqID130615_192625_730
ReportSpecID120615_122512_481_2
TELEMETRY_USAGE
<ei:createdDateTime>2015-06-14T02:27:29Z</ei:createdDateTime>
VEN130615_192312_582
Residensiële Elektriese Voertuig (EV) Tyd van Gebruik (TOU) Program
Let daarop dat, aangesien die program koersvlakke in 'n redelik gestruktureerde vorm kommunikeer, word slegs die eenvoudige en tipiese gebruiksgevalle getoon
Residensiële EV Scenario 1 – Eenvoudige gebruik geval, A of B Profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begin Tyd: 1:XNUMX
- Tydsduur: 24 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 1
- Seinnaam: EENVOUDIG
- Sein Tipe: vlak
- Eenhede: NVT
- Aantal intervalle; gelyke TOU-vlakveranderings binne 24 uur (2 – 6)
- Interval Duur(e): TOU-vlak aktiewe tydraamwerk (dws 6 uur)
- Tipiese intervalwaarde(s): 0 – 4 gekarteer na TOU-vlakke
- Seinteiken: NVT
- Gebeurtenisteiken(s): venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
Residensiële EV Scenario 2 – Tipiese gebruiksgeval, B profile
- Gebeurtenis
- Kennisgewing: Dag voor geleentheid
- Begintyd: middernag
- Tydsduur: 24 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 2
- Seinnaam: Eenvoudig
- Sein Tipe: vlak
- Eenhede: Vlak 0, 1, 2, 3
- Aantal intervalle: gelyke TOU-vlakverandering in 24 uur (2 – 6)
- Interval Duur(e): TOU-vlak aktiewe tydraamwerk (dws 6 uur)
- Tipiese intervalwaarde(s): 0 – 4 gekarteer na TOU-vlakke (0 – goedkoopste vlak)
- Sein teiken: Geen
- Seinnaam: ELECTRICITY_PRICE
- Sein Tipe: prys
- Eenhede: USD per Kwh
- Aantal intervalle: gelyke TOU-vlakveranderings in 24 uur (2 – 6)
- Interval Duur(e): TOU-vlak aktiewe tydraamwerk (dws 6 uur)
- Tipiese intervalwaarde(s): $0.10 tot $1.00 (huidige vlakkoers)
- Sein teiken: Geen
- Gebeurtenisteikens: venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
Residensiële EV Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Case
OadrDisReq091214_043740_513
TH_VTN
Gebeurtenis091214_043741_028_0
0
http://Markkonteks1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
ver
<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
EENVOUDIG
vlak
SIG_01
0.0
PT5H
0
0.35
PT7H
1
0.55
PT7H
2
0.75
PT5H
3
0.55
ELECTRICITY_PRICE
prys
SIG_02
geldeenheidPerKWh
USD
geen
0.0
venID_1234
altyd
Openbare stasie elektriese voertuig (EV) Real-Time Pryse Program
Let daarop dat aangesien dit 'n intydse prysprogram is, is daar regtig geen onderskeid tussen 'n eenvoudige, tipiese en komplekse gebruiksgeval nie. Daarom sample data sal slegs vir 'n tipiese gebruiksgeval gewys word.
Openbare Stasie EV Scenario 1 – Tipiese gebruiksgeval, B profile
- Gebeurtenis
- Kennisgewing: 1 uur vooruit
- Begintyd: 1:XNUMX
- Tydsduur: 1 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 1
- Seinnaam: ELECTRICITY_PRICE
- Sein Tipe: prys
- Eenhede: USD per Kwh
- Aantal intervalle 1
- Interval Duur(e): 1 uur
- Tipiese intervalwaarde(s): $0.10 tot $1.00
- Sein teiken: Geen
- Gebeurtenisteikens: venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: altyd
- VEN Verwagte reaksie: optIn
- Verslae
- Geen
Openbare Stasie EV Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Case
OadrDisReq091214_043740_513
TH_VTN
Gebeurtenis091214_043741_028_0
0
http://Markkonteks1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
ver
<xcal:date-time>2014-12-09T13:00:00Z</xcal:date-time>
PT1H
PT1H
PT1H
0
0.75
ELECTRICITY_PRICE
prys
SIG_01
geldeenheidPerKWh
USD
geen
0.0
venID_1234
altyd
Verspreide Energiehulpbronne (DER) DR-program
Let daarop dat aangesien dit 'n intydse prysprogram is, is daar regtig geen onderskeid tussen 'n eenvoudige, tipiese en komplekse gebruiksgeval nie. Daarom sample data sal slegs vir 'n tipiese gebruiksgeval gewys word.
Openbare Stasie EV Scenario 1 – Tipiese gebruiksgeval, B profile
- Gebeurtenis
- Kennisgewing: Dag wat voorlê
- Begintyd: middernag
- Tydsduur: 24 uur
- Randomisering: Geen
- Ramp Op: Geen
- Herstel: Geen
- Aantal seine: 24
- Seinnaam: ELECTRICITY_PRICE
- Sein Tipe: prys
- Eenhede: USD per Kwh
- Aantal intervalle 1
- Interval Duur(e): 1 uur
- Tipiese intervalwaarde(s): $0.10 tot $1.00
- Sein teiken: Geen
- Gebeurtenisteikens: venID_1234
- Prioriteit: 1
- VEN-reaksie vereis: nooit
- VEN Verwagte reaksie: nvt
- Verslae
- Geen
Openbare Stasie EV Sample Gebeurtenisloonvrag – Tipiese B Profile Gebruik Case
OadrDisReq091214_043740_513
TH_VTN
Gebeurtenis091214_043741_028_0
0
http://Markkonteks1
<ei:createdDateTime>2014-12-09T12:37:40Z</ei:createdDateTime>
ver
<xcal:date-time>2014-12-09T00:00:00Z</xcal:date-time>
PT24H
PT24H
PT1H
0
0.75
PT1H
1
0.80
ELECTRICITY_PRICE
prys
SIG_01
geldeenheidPerKWh
USD
geen
0.0
venID_1234
nooit
- Eksample Verslae van Nutsvlieëniers
Lede van die OpenADR-alliansie het die volgende B Pro verskaffile oadrUpdateReport loonvrag samples van nut-loodsprogramme waar hul VENs ontplooi is. Die volgende aantekeninge het die drie loonvragte s vergeselamples verskaf:
Termostaat Loonvrag Doelwit:
- Moet die status van die termostaat ken (temp, stelpunte, waaier- en modustoestande)
- Indien ingeteken, of die kliënt die termostaatinstellings verander het (handmatige oorheersingsboodskappe)
M&V vir Kortings Loonvrag Doelwit:
- Status van hulpbronne en handmatige ignorering in die geval van intekening
- Intervaldata vanaf 'n KYZ-pulsteller of energiemonitor vir totale energie in KWH en oombliklike aanvraag in KW
Slimmeter/AMI-intervaldata loonvragdoelwit:
- AMI meterlesingsinterval is ongeveer 15 minute tot 1 uur. Alhoewel nuttig, nie korrelig genoeg vir byna intydse faktuurberamings nie
- Totale energie in KWH, delta-energie in KWH, oombliklike aanvraag in KW
Die volgende naamruimtevoorvoegsels word in die loonvrag bvamples:
- 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”
Termostaatverslag loonvrag 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
waar
onwaar
0
Geen nuwe waarde nie – vorige waarde gebruik
Huidige Temp
77.000000
Geen nuwe waarde nie – vorige waarde gebruik
Hitte Temp instelling
64.000000
Geen nuwe waarde nie – vorige waarde gebruik
Koel Temp instelling
86.000000
Geen nuwe waarde nie – vorige waarde gebruik
HVAC-modus-instelling
3
Geen nuwe waarde nie – vorige waarde gebruik
Huidige HVAC-modus
0.000000
Geen kwaliteit - geen waarde nie
Waaiermodus-instelling
2
Geen nuwe waarde nie – vorige waarde gebruik
Huidige houmodus
2
Geen nuwe waarde nie – vorige waarde gebruik
Huidige Wegmodus
0
Geen nuwe waarde nie – vorige waarde gebruik
Huidige humiditeit
0.000000
Geen kwaliteit - geen waarde nie
RP21
GEVRA: RR Req: 1395368583267
0013A20040980FAE
TELEMETRY_STATUS
<ei:createdDateTime>2014-03-21T02:26:04Z</ei:createdDateTime>
VEN.ID:1395090780716
M&V vir kortingsverslag loonvrag 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
waar
onwaar
Kwaliteit goed – nie spesifiek nie
Polstelling
34750.000000
Kwaliteit goed – nie spesifiek nie
Energie
33985.500000
Kwaliteit goed – nie spesifiek nie
Krag
1.26
Kwaliteit goed – nie spesifiek nie
RP15
GEVRA: RR Req: 10453335019195698
0000000000522613 60
TELEMETRY_USAGE
<ei:createdDateTime>2015-08-21T17:41:50Z</ei:createdDateTime>
VEN.ID:1439831430142
Slimmeter/AMI-intervaldataverslag loonvrag 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
oombliklike aanvraag
6.167000
Geen nuwe waarde nie – vorige waarde gebruik
intervalDataDelivered
0.051000
Geen nuwe waarde nie – vorige waarde gebruik
currSumAfgelewer
12172.052000
Geen nuwe waarde nie – vorige waarde gebruik
<xcal:date-time>2014-09-10T06:27:07Z</xcal:date-time>
PT15S
oombliklike aanvraag
6.114000
Geen nuwe waarde nie – vorige waarde gebruik
intervalDataDelivered
0.051000
Geen nuwe waarde nie – vorige waarde gebruik
currSumAfgelewer
12172.052000
Geen nuwe waarde nie – vorige waarde gebruik
<xcal:date-time>2014-09-10T06:27:22Z</xcal:date-time>
PT15S
oombliklike aanvraag
6.113000
Geen nuwe waarde nie – vorige waarde gebruik
intervalDataDelivered
0.051000
Geen nuwe waarde nie – vorige waarde gebruik
currSumAfgelewer
12172.142000
Geen nuwe waarde nie – vorige waarde gebruik
<xcal:date-time>2014-09-10T06:27:37Z</xcal:date-time>
PT15S
oombliklike aanvraag
6.112000
Geen nuwe waarde nie – vorige waarde gebruik
intervalDataDelivered
0.051000
Geen nuwe waarde nie – vorige waarde gebruik
currSumAfgelewer
12172.142000
Geen nuwe waarde nie – vorige waarde gebruik
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>
Oop ADR ondersteun die volgende dienste:
- EiEvent Diens – Word deur VTN'e gebruik om aanvraagreaksie-geleenthede na VEN'e te stuur, en deur VEN'e gebruik om aan te dui of hulpbronne aan die geleentheid gaan deelneem. Die enigste diens wat deur die A profile is EiEvent
- EiRapportdiens - Word deur VEN'e en VTN'e gebruik om historiese, telemetrie- en voorspellingsverslae uit te ruil
- EiOpt Diens – Word deur VEN gebruik om tydelike beskikbaarheidskedule aan VTN'e te kommunikeer of om die hulpbronne wat aan 'n geleentheid deelneem te kwalifiseer
- EiRegisterParty-diens – Geïnisieer deur die VEN, en gebruik deur beide VEN en VTN om inligting uit te ruil wat nodig is om interoperabele uitruil van loonvragte te verseker
- OadrPoll Diens – Word deur VENs gebruik om die VTN vir loonvragte van enige van die ander dienste te poll
A en B profile diensbedrywighede word gedefinieer deur die wortelelement van elke loonvrag, uitgesluit die oadrPayload- en oadrSignedObject-omhulsels wat op alle B pro gebruik wordfile loonvragte.
- oadrRequestEvent – Gebruik in 'n trekuitruilmodel deur die VEN om alle relevante gebeurtenisse uit die VTN te haal. Word gebruik as die primêre stemmeganisme vir A profile VENs, maar word slegs op B VENs gebruik om met die VTN te sinchroniseer.
- oadrDistributeEvent – Word deur die VTN gebruik om vraagreaksie-geleenthede aan die VEN te lewer
- oadrCreatedEvent – Word deur die VEN gebruik om te kommunikeer of dit van plan is om aan 'n geleentheid deel te neem deur in- of uit te teken
- oadrReaksie – Word deur die VTN gebruik om die ontvangs van die optIn of opt-out van die VEN te erken
Let daarop dat beide VEN'e en VTN'e in staat is om beide 'n verslagvervaardiger en 'n verslagversoeker te wees, dus kan al die loonvragte hieronder deur enige party geïnisieer word.
- oadrRegisterReport – Word gebruik om hul verslagdoeningsvermoëns in 'n metadataverslag te publiseer
- oadrGeregistreerde Verslag -Erken die ontvangs van oadrRegisterReport, versoek opsioneel een van die aangebied verslae
- oadrCreateReport – Word gebruik om 'n verslag aan te vra wat voorheen deur die VEN of VTN aangebied is
- oadrCreatedReport – Erken ontvangs van 'n verslagversoek
- oadrUpdateReport -Lewer 'n gevraagde verslag wat intervaldata bevat
- oadrUpdated Report – Erken ontvangs van 'n gelewerde verslag
- oadrCancelReport – Kanselleer 'n voorheen versoekte periodieke verslag
- oadrGekanselleerRapport – Erken 'n periodieke verslagkansellasie
- oadrReaksie – Word gebruik as 'n plekhouerreaksie in sommige trekuitruilpatrone wanneer 'n toepassingslaagreaksie in 'n vervoerlaagversoek afgelewer word.
- oadrSkepOpt – Gebruik vir twee duidelik verskillende doeleindes
- Vir die VEN om 'n tydelike beskikbaarheidskedule aan die VTN te kommunikeer met betrekking tot sy vermoë om aan DR-geleenthede deel te neem
- Vir die VEN om die hulpbronne wat aan 'n geleentheid deelneem, te kwalifiseer
- oadrGeskepOpt – Erken die ontvangs van die oadrCreateOpt-loonvrag
- oadrKanselleerOpt -Kanselleer 'n tydelike beskikbaarheidskedule
- oadrGekanselleerOpt – Erken 'n kansellasie van 'n tydelike beskikbaarheidsverslag
- oadrQueryRegistrasie – 'n Manier vir die VEN om die VTN se registrasie-inligting te bevraagteken sonder om werklik te registreer.
- oadrCreatePartyRegistration – ’n Versoek van die VEN aan die VTN om te registreer. Bevat inligting oor die VENs-vermoëns.
- oadrCreatedPartyRegistration – Antwoord op óf 'n oadrQueryRegistration óf 'n oadrCreatePartyRegistration. Bevat VTN-vermoëns en registrasie-inligting wat nodig is vir die VEN om saam te werk
- oadrCancelPartyRegistration – Word deur óf die VEN óf VTN gebruik om registrasie te kanselleer
- oadrCanceledPartyRegistration – Antwoord op 'n oadrCancelPartyRegistration. Erken ontvangs van die registrasiekansellasie
- oadrRequestReregistration – Hierdie loonvrag word deur 'n VTN in 'n trekuitruilmodel gebruik om die VEN aan te dui om die registrasievolgorde weer te begin
- oadrReaksie – Word gebruik as 'n plekhouerreaksie in sommige trekuitruilpatrone wanneer 'n toepassingslaagreaksie in 'n vervoerlaagversoek afgelewer word.
- oadrPoll – 'n Generiese paalmeganisme vir die B profile wat loonvrag terugstuur vir enige ander diens wat nuut is of opgedateer is.
- oadrReaksie – Word gebruik om aan te dui dat daar geen nuwe of opgedateerde loonvragte beskikbaar is nie
– Woordelys van Skema Loonvrag Elemente
Die volgende is 'n alfabetiese lys van skema-elemente wat in OpenADR 2.0-loonvragte gebruik word. Die narratief beskryf hul gebruik soos dit betrekking het op OpenADR en hul gebruik in loonvragte. Wanneer 'n elementdefinisie verander op grond van die loonvrag waarin dit vervat is of sy gebruikskonteks, sal dit in die vertelling opgemerk word. Wortelloonvragdefinisies is uitgesluit soos dit in Bylae C gedefinieer word.
- ac – 'n Boolese waarde wat aandui of die kragproduk wisselstroom is
- akkuraatheid - Getal is in dieselfde eenhede as die loonvragveranderlike vir 'n interval. Wanneer teenwoordig met vertroue, dui die waarskynlike veranderlikheid van die voorspelling aan. Wanneer dit by ReadingType teenwoordig is, dui dit op waarskynlike leesfout.
- aggregatedPnode – 'n Geaggregeerde prysknooppunt is 'n gespesialiseerde tipe prysknooppunt wat gebruik word om items soos stelselsone, verstekpryssone, pasgemaakte pryssone, beheerarea, saamgevoegde generasie, saamgevoegde deelnemende lading, saamgevoegde nie-deelnemende las, handelssentrum, DCA-sone te modelleer
- beskikbaar – 'n Voorwerp wat 'n datum-tyd en tydsduur vir 'n EiOpt-beskikbaarheidskedule bevat
- basislyn-ID – Unieke ID vir 'n spesifieke basislyn
- basislynnaam – Beskrywende naam vir basislyn
- komponente –
- selfvertroue – 'n Statistiese waarskynlikheid dat 'n gerapporteerde datapunt akkuraat is
- geskep Datum Tyd - Die datumTyd waarop die loonvrag geskep is
- geldeenheid –
- geldeenheidPerKW –
- geldeenheidPerKWh –
- valutaPerThm –
- huidige –
- huidige waarde - Die loonvragFloat-waarde van die gebeurtenisinterval wat tans uitgevoer word.
- pasgemaakte Eenheid – Word gebruik om 'n pasgemaakte maateenheid vir pasgemaakte verslae te definieer
- datum-tyd –
- dtstart - Die begintyd vir die aktiwiteit, data of toestandverandering
- duur – 'n Tydperiode vir 'n gebeurtenis, verslagdoening of beskikbaarheidstydinterval
- duur - Die duur van die aktiwiteit, data of toestand
- eiActivePeriod – Tydraamwerke wat relevant is vir die algehele gebeurtenis
- eiCreatedEvent – Reageer op 'n DR-geleentheid met optIn of optOut
- eiGebeurtenis -'n Voorwerp wat al die inligting vir 'n enkele gebeurtenis bevat
- eiEventBaseline – B profile
- eiEventSignaal – 'n Voorwerp wat al die inligting vir 'n enkele sein in 'n gebeurtenis bevat
- eiEventSignals – Intervaldata vir een of meer gebeurtenisseine en/of basislyne
- eiMarkkonteks – 'n URI wat 'n aanvraagreaksieprogram uniek identifiseer
- eiRapportID – Verwysings-ID vir 'n verslag
- eiRequestEvent – Versoek Gebeurtenis van 'n VTN in trekmodus
- eiRespons – Dui aan of ontvangde loonvrag aanvaarbaar is
- eiTarget – Identifiseer die hulpbronne wat met die logiese VEN-koppelvlak geassosieer word. Vir gebeurtenisse is die waardes wat gespesifiseer is die teiken vir die gebeurtenis
- endDeviceAsset – Die EndDevice Assets is die fisiese toestel of toestelle wat meters of ander soorte toestelle kan wees wat van belang kan wees
- energyApparent – Skynbare energie, gemeet in volt-ampoor ure (VAh)
- energie Item –
- energie Reaktief - Reaktiewe energie, volt-amperes reaktiewe ure (VARh)
- energieReal - Werklike energie, wattuur (Wh)
- gebeurtenisbeskrywing - Inligting oor die geleentheid
- gebeurtenisID – 'n ID-waarde wat 'n spesifieke DR-gebeurtenisinstansie identifiseer.
- gebeurtenisReaksie – 'n Voorwerp wat VEN se reaksie bevat op 'n versoek om aan 'n geleentheid deel te neem
- gebeurtenisantwoorde – optIn of optout-reaksies vir ontvangde gebeurtenisse
- gebeurtenis Status - Die huidige status van 'n gebeurtenis (ver, naby, aktief, ens.)
- Kenmerkversameling/ligging/Polygon/buitekant/Lineêre Ring
- frekwensie –
- korreligheid – Dit is die tydsinterval tussen sampgelei data in 'n verslag versoek.
- groepID -Hierdie tipe teiken word gebruik vir gebeure, verslae en kiesskedules. Die waarde sal tipies deur die nutsprogram toegeken word tydens inskrywing in 'n DR-program
- groepnaam - Hierdie tipe teiken word gebruik vir gebeure, verslae en kiesskedules. Die waarde sal tipies deur die nutsprogram toegeken word tydens inskrywing in 'n DR-program
- hertz –
- interval – 'n Voorwerp wat data-tyd en/of tydsduur bevat, en 'n uitvoerbare waarde in die geval van 'n gebeurtenis of data in die geval van 'n verslag
- intervalle - Een of meer tydintervalle waartydens die DR-gebeurtenis aktief is of verslagdata is beskikbaar
- itembeskrywing - 'n Beskrywing van 'n verslagmaateenheid
- item Eenhede – Die basismaateenheid vir 'n verslagdatapunt
- markkonteks – 'n URI wat 'n DR-program identifiseer
- meterAsset – Die MeterAsset is die fisiese toestel of toestelle wat die rol van die meter verrig
- wysigingDatumTyd – Wanneer 'n gebeurtenis gewysig word
- wysigingsnommer – Verhoog elke keer as 'n gebeurtenis gewysig word.
- wysiging Rede – Waarom 'n gebeurtenis gewysig is
- mrid - Die mRID identifiseer die fisiese toestel wat 'n CustomerMeter of ander tipe eindtoestelle kan wees.
- nodus - Die Node is 'n plek waar iets verander (dikwels eienaarskap) of verbind op die rooster. Baie nodusse word met meters geassosieer, maar nie almal is nie.
- numDataSources –
- oadrKapasiteit –
- oadr Huidig –
- oadrDataQuality –
- oadrDeviceClass – Toestelklas-teiken – gebruik slegs endDeviceAsset.
- oadrEvent – 'n Voorwerp wat 'n vraagreaksie-gebeurtenis bevat
- oadrUitbreiding –
- oadrExtensionName –
- oadr Uitbreidings –
- oadrHttpPullModel – 'n Boole waarde wat aandui of die VEN 'n trekuitruilmodel wil gebruik
- oadrInfo – 'n Sleutelwaardepaar van diensspesifieke registrasie-inligting
- oadrKey –
- oadrLevelOffset –
- oadrLoadControlState –
- oadrManualOverride – As dit waar is, is die beheer van die vrag met die hand omgekeer
- oadrMax –
- oadrMaxPeriod – Maksimum sampling tydperk
- oadrMin –
- oadrMinPeriod – Minimum sampling tydperk
- oadrNormaal –
- oadrOnChange – As dit waar is, sal die data aangeteken word wanneer dit verander, maar nie teen 'n groter frekwensie as wat deur minPeriod gespesifiseer word nie.
- oadrAanlyn – As dit waar is, is hulpbron/bate aanlyn, indien onwaar dan vanlyn.
- oadrPayload –
- oadrPayloadResourceStatus – Huidige hulpbronstatusinligting
- oadrPendingReports – 'n Lys van periodieke verslae wat steeds aktief is
- oadrPersentOffset –
- oadrProfile - Profile ondersteun deur VEN of VTN
- oadrProfileNaam - OpenADR profile naam soos 2.0a of 2.0b.
- oadrProfiles - OpenADR profiles ondersteun deur die implementering
- oadrRapport -'n Voorwerp wat al die inligting vir 'n enkele verslag bevat
- oadrVerslagBeskrywing – Beskrywing van die verslagkenmerke wat deur die verslagvervaardiger aangebied word. Vervat in 'n metadataverslag
- oadrReportOnly – ReportOnlyDeviceVlag
- oadrReportPayload – Datapuntwaardes vir verslae
- oadrRequestedOadrPollFreq – Die VEN sal hoogstens een keer 'n oadrPoll loonvrag na die VTN stuur vir elke tydsduur wat deur hierdie element gespesifiseer word
- oadrResponseRequired – Beheer wanneer optIn/optout-reaksie vereis word. Kan altyd of nooit wees nie
- oadrSamplingRate – Samplingtempo vir telemetrietipe data
- oadrDiens –
- oadrDiensnaam - Hierdie tipe teiken word gebruik vir gebeure, verslae en kiesskedules. Die waarde sal tipies deur die nutsprogram toegeken word tydens inskrywing in 'n DR-program
- oadrServiceSpecificInfo – Diensspesifieke registrasie-inligting
- oadrSetPoint –
- oadrSignedObject –
- oadrVervoer – 'n Vervoernaam wat deur 'n VEN of VTN ondersteun word
- oadrTransportAddress – Hoofadres wat gebruik word om met ander party te kommunikeer. Moet poort insluit indien nodig
- oadrTransportName – OpenADR-vervoernaam soos simpleHttp of xmpp
- oadrTransports – OpenADR-vervoer ondersteun deur implementering
- oadrUpdated Report – Erken ontvangs van 'n verslag
- oadrUpdateReport – Stuur 'n voorheen versoekte verslag
- oadrWaarde –
- oadrVenName – VEN naam. Kan in VTN GUI gebruik word
- oadrXmlSignature – Implementering ondersteun XML handtekening
- optID – Identifiseerder vir 'n opt interaksie
- optReason – Opgesomde waarde vir die opt-rede soos x-skedule
- optType – optIn of optout van 'n gebeurtenis, of gebruik om die tipe opt-skedule aan te dui wat in die vavailablityObject vir die EiOpt-diens gedefinieer is
- partyID - Hierdie tipe teiken word gebruik vir gebeure, verslae en kiesskedules. Die waarde sal tipies deur die nutsprogram toegeken word tydens inskrywing in 'n DR-program
- loonvragFloat – Datapuntwaarde vir gebeurtenisseine of vir die rapportering van huidige of historiese waardes.
- pnode - 'n Prysknooppunt word direk met 'n verbindingsnodus geassosieer. Dit is 'n prysbepalingsligging waarvoor markdeelnemers hul bod, aanbiedings indien, CRR's koop/verkoop en vereffen.
- pointOfDelivery –
- ontvangspunt –
- posLys –
- powerApparent – Skynbare drywing gemeet in volt-amperes (VA)
- kragEienskappe
- kragItem
- kragReaktief – Reaktiewe drywing, gemeet in volt-amperes reaktief (VAR)
- powerReal - Werklike drywing gemeet in Watt (W) of Joules/sekonde (J/s)
- prioriteit - Die prioriteit van die gebeurtenis in verhouding tot ander gebeurtenisse (Hoe laer die getal hoër die prioriteit. 'n Waarde van nul (0) dui op geen prioriteit nie, wat by verstek die laagste prioriteit is).
- eiendomme –
- polstelling – ’n Rapporteerdatapunt
- pulsfaktor – kWh per telling
- gekwalifiseerde Gebeurtenis-ID - 'n Unieke ID vir 'n geleentheid
- leestipe – Metadata oor die lesings, soos gemiddelde of afgelei
- registrasie-ID - Identifiseerder vir registrasietransaksie. Nie ingesluit in reaksie op navraagregistrasie nie, tensy reeds geregistreer
- antwoordlimiet – Die maksimum aantal gebeurtenisse om terug te keer in 'n oadrDistributeEvent-loonvrag
- verslagTerugDuration – Rapporteer terug met die Verslag-Tot-Datum vir elke verbygaan van hierdie Tydsduur.
- verslagdatabron – Bronne vir data in hierdie verslag. Bvamples sluit meters of submeters in. Byvoorbeeldample, as 'n meter in staat is om twee verskillende tipes metings te verskaf, dan sal elke meetstroom afsonderlik geïdentifiseer word.
- verslagInterval – Dit is die algehele tydperk van verslagdoening.
- verslagNaam – Opsionele naam vir 'n verslag.
- verslagVersoekID – Identifiseerder vir 'n spesifieke verslagversoek
- reportSpesifier – Spesifiseer datapunte wat verlang word in 'n spesifieke verslaggeval
- reportSpesifierID – Identifiseerder vir 'n spesifieke Metadataverslagspesifikasie
- verslagOnderwerp – Toestelklas-teiken – gebruik slegs endDeviceAsset.
- rapporteer om te volg – Dui aan of verslag (in die vorm van UpdateReport) teruggestuur moet word na kansellasie van verslag
- verslagtipe – Die tipe verslag soos gebruik of prys
- versoek-ID – 'n ID wat gebruik word om 'n logiese transaksieversoek en -antwoord te pas
- hulpbronID - Hierdie tipe teiken word gebruik vir gebeure, verslae en kiesskedules. Die waarde sal tipies deur die nutsprogram toegeken word tydens inskrywing in 'n DR-program
- reaksie –
- reaksiekode - 'n 3-syfer-antwoordkode
- antwoordbeskrywing - Narratiewe beskrywing van reaksiestatus
- antwoorde –
- ontslae - Verwysings-ID vir hierdie datapunt
- diensarea - Hierdie tipe teiken word gebruik vir gebeure, verslae en kiesskedules. Die waarde sal tipies deur die nutsprogram toegeken word tydens inskrywing in 'n DR-program
- diensleweringspunt – Logiese punt op die netwerk waar die eienaarskap van die diens van eienaar verander. Dit is een van potensieel baie dienspunte binne 'n diensligging, wat diens lewer in ooreenstemming met 'n klanteooreenkoms. Word gebruik op die plek waar 'n meter geïnstalleer kan word.
- diensligging – 'n Kliëntediensligging het een of meer Diensafleweringspunt(e), wat op hul beurt met meters verband hou. Die ligging kan 'n punt of 'n veelhoek wees, afhangende van die spesifieke omstandighede. Vir verspreiding is die ServiceLocation tipies die ligging van die nutskliënt se perseel.
- seinID – unieke Identifiseerder vir 'n spesifieke gebeurtenissein
- seinNaam – Die naam van 'n sein soos SIMPLE
- seinPayload – Seinwaardes vir gebeure en basislyne
- siScaleCode – 'n Skaalfaktor vir die basismaateenheid vir 'n verslag
- spesifiseerderPayload – ’n Oop
- begin daarna - Randomiseringsvenster vir die begin van die gebeurtenis
- statusDatumTyd – Datum en tyd wat hierdie artefak verwys.
- temperatuur –
- toetsgebeurtenis – Enigiets anders as onwaar dui op 'n toetsgebeurtenis
- teks –
- Therm –
- verdraagsaamheid - 'n Sub-voorwerp wat die randomiseringsvereistes vir 'n gebeurtenis bevat
- verdra – 'n Voorwerp wat die randomiseringsvereistes vir 'n gebeurtenis bevat
- vervoerkoppelvlak – Die vervoerkoppelvlak omlyn die rande aan weerskante van 'n vervoersegment.
- uid - Word gebruik as 'n indeks om intervalle te identifiseer. Unieke Identifiseerder
- waarde –
- beskikbaarheid - 'n Skedule wat toestelbeskikbaarheid weerspieël vir deelname aan DR-geleenthede
- venID – 'n Unieke identifiseerder vir 'n VEN
- voltage –
- vtnComment - Enige teks
- vtnID – 'n Unieke identifiseerder vir 'n VTN
- x-eiNotification – Die VEN moet die DR gebeurtenis loonvrag ontvang voor dtstart minus hierdie tydsduur.
- x-eiRampOp - 'n Tydsduur voor of na die geleentheid se begintyd waartydens beurtkrag moet deurgaan.
- x-eiRecovery – 'n Tydsduur voor of na die geleentheid se eindtyd waartydens beurtkrag moet vervoer.
Woordelys van opgesomde waardes
- aktief – Die geleentheid is begin en is tans aktief.
- gekanselleer – Die geleentheid is gekanselleer.
- voltooi – Die geleentheid is voltooi.
- ver – Gebeurtenis hangende in die verre toekoms. Die presiese definisie van hoe ver in die toekoms dit verwys is afhanklik van die markkonteks, maar beteken gewoonlik die volgende dag.
- naby – Gebeurtenis hangende in die nabye toekoms. Die presiese definisie van hoe naby in die toekoms die hangende gebeurtenis aktief is, hang af van die markkonteks. .Begin gelyktydig met die effektiewe begin van die gebeurtenis x-eiRampOp tyd. As x-eiRampUp is nie gedefinieer vir die geleentheid nie, hierdie status sal nie vir die geleentheid gebruik word nie.
- geen – Geen geleentheid hangende nie
- Geldeenheid
- USD - Amerikaanse dollars
- Vir baie om hier te lys, verwys na skema
- kragRegtig
- J/s – Joule-sekonde
- W – Watts
- temperatuur
- celsius –
- fahrenheit –
- Geen nuwe waarde nie – vorige waarde gebruik –
- Geen kwaliteit - geen waarde nie –
- Kwaliteit sleg – kommunikasie mislukking –
- Kwaliteit sleg – konfigurasiefout –
- Kwaliteit sleg – toestelfout –
- Kwaliteit swak – Laas bekende waarde –
- Slegte kwaliteit – nie spesifiek nie –
- Kwaliteit sleg – nie gekoppel nie –
- Kwaliteit sleg – buite diens –
- Kwaliteit sleg – sensorfout –
- Kwaliteit goed – Plaaslike oorheersing –
- Kwaliteit goed – nie spesifiek nie –
- Kwaliteitsbeperking – Veld/Konstant –
- Kwaliteitsbeperking – Veld/Hoog –
- Kwaliteitsbeperking – Veld/Laag –
- Kwaliteitsbeperking – Veld/Nie –
- Kwaliteit onseker – EU-eenhede oorskry –
- Kwaliteit onseker – Laaste bruikbare waarde –
- Kwaliteit onseker – Nie-spesifiek –
- Kwaliteit onseker – Sensor nie akkuraat nie –
- Kwaliteit onseker – Subnormaal –
- altyd - Stuur altyd 'n antwoord vir elke gebeurtenis wat ontvang word.
- nooit – Moet nooit reageer nie.
Genoemde redes om te kies.
- ekonomiese –
- noodgeval –
- moet hardloop –
- nie deelneem nie –
- outageRunStatus –
- oorheersStatus -
- deelneem –
- x-skedule –
- eenvoudigeHttp –
- xmpp –
- optIn – 'n Aanduiding dat die VEN aan 'n geleentheid sal deelneem, of in die geval van die EiOpt-diens 'n tipe skedule wat aandui dat hulpbron beskikbaar sal wees
- onttrek – 'n Aanduiding dat die VEN nie aan 'n geleentheid sal deelneem nie, of in die geval van die EiOpt-diens 'n tipe skedule wat aandui dat hulpbron nie beskikbaar sal wees nie
- Toegewys - Meter dek verskeie [bronne] en gebruik word afgelei deur 'n soort pro-databerekening.
- Kontrak – Dui aan dat lesing pro forma is, dit wil sê, teen ooreengekome tariewe gerapporteer word
- Afgelei - Gebruik word afgelei deur kennis van looptyd, normale werking, ens.
- Direkte lees – Lees word gelees vanaf 'n toestel wat eentonig toeneem, en gebruik moet uit pare begin- en stoplesings bereken word.
- Geskatte – Word gebruik wanneer 'n lesing afwesig is in 'n reeks waarin die meeste lesings teenwoordig is.
- Hibried – Indien saamgevoeg, verwys na verskillende leestipes in die totale getal.
- Gemiddeld – Lesing is die gemiddelde waarde oor die tydperk wat in Granulariteit aangedui word
- Netto – Meter of [hulpbron] berei sy eie berekening van totale gebruik oor tyd voor.
- Piek – Lesing is Piek (hoogste) waarde oor die tydperk wat in korreligheid aangedui word. Vir sommige metings kan dit meer sin maak as die laagste waarde. Mag nie ooreenstem met totale lesings nie. Slegs geldig vir vloeitempo-itembasisse, dws Krag nie Energie nie.
- Geprojekteer – Dui aan lees is in die toekoms, en is nog nie gemeet nie.
- Opgesom – Verskeie meters saam verskaf die lesing vir hierdie [hulpbron]. Dit is spesifiek 'n ander as saamgevoeg, wat verwys na veelvuldige [hulpbronne] in dieselfde loonvrag. Sien ook Hibriede.
- x-nie van toepassing nie - Nie van toepassing nie
- x-RMS – Wortel Mean Square
- GESKIEDENIS_GREENBUTTON – 'n Verslag wat groenknoppie-data in 'n atoomvoerskemastruktuur bevat
- GESKIEDENIS_GEBRUIK – 'n Verslag wat historiese energieverbruikdata bevat
- METADATA_HISTORY_GREENBUTTON – 'n Metadataverslag wat die verslagdoeningsvermoëns vir HISTORY_GREENBUTTON-verslae definieer
- METADATA_HISTORY_USAGE – 'n Metadataverslag wat die verslagdoeningsvermoëns vir HISTORY_USAGE-verslae definieer
- METADATA_TELEMETRY_STATUS – 'n Metadataverslag wat die verslagdoeningsvermoëns vir TELEMETRY_STATUS-verslae definieer
- METADATA_TELEMETRY_USAGE – 'n Metadataverslag wat die verslagdoeningsvermoëns vir TELEMETRY_USAGE-verslae definieer
- TELEMETRY_STATUS – 'n Verslag wat intydse hulpbronstatusinligting soos aanlynstatus bevat
- TELEMETRY_USAGE - 'n Verslag wat intydse inligting oor energieverbruik bevat
'n Genoemde waarde wat die tipe verslag gee wat verskaf word.
- beskikbaar EnergieStoor – Kapasiteit beskikbaar vir verdere energieberging, miskien om by Target Energy Storage uit te kom
- avgDemand – Gemiddelde gebruik oor die tydsduur wat deur die Granulariteit aangedui word. Sien aanvraag vir meer inligting.
- gemiddelde gebruik – Gemiddelde gebruik oor die tydsduur wat deur die Granulariteit aangedui word. Sien gebruik vir meer inligting.
- basislyn – Kan aanvraag of gebruik wees, soos aangedui deur ItemBase. Dui aan wat [meting] sou wees as nie vir die gebeurtenis of regulasie nie. Verslag is van die formaat Basislyn.
- deltaDemand – Verandering in vraag in vergelyking met die basislyn. Sien aanvraag vir meer inligting
- deltaSetPoint - Veranderinge in stelpunt vanaf vorige skedule.
- deltaGebruik - Verandering in gebruik in vergelyking met die basislyn. Sien gebruik vir meer inligting
- vraag – Verslag dui 'n hoeveelheid eenhede aan (gedenomineer in ItemBase of in die EMIX-produk). Loonvrag tipe is Hoeveelheid. 'n Tipiese ItemBase is Real Power.
- afwyking – Verskil tussen een of ander instruksie en werklike toestand.
- downRegulationCapacity Beskikbaar – Afwaartse reguleringskapasiteit beskikbaar vir versending, uitgedruk in EMIX Real Power. Loonvrag word altyd as positiewe Hoeveelheid uitgedruk.
- vlak - Eenvoudige vlak van die mark op elke interval.
- bedryfsstaat – Algemene toestand van 'n hulpbron soos aan/af, besetting van gebou, ens. Geen ItemBase is relevant nie. Vereis 'n toepassingspesifieke loonvraguitbreiding.
- persent Vraag – Persentasietage van aanvraag
- persentasie gebruik – Persentasietage van gebruik
- krag faktor – Kragfaktor vir die hulpbron
- prys – Prys per ItemBase by elke Interval
- lees – Verslag dui 'n lesing aan, soos vanaf 'n meter. Lesings is oomblikke in tydsveranderinge oor tyd wat uit die verskil tussen opeenvolgende lesings bereken kan word. Loonvrag tipe is dryf
- regulasie Stelpunt – Regulasiestelpunt soos aangedui as deel van regulasiedienste
- stelpunt – Verslag dui die bedrag aan (gedenomineer in ItemBase of in die EMIX-produk) wat tans gestel is. Kan 'n bevestiging/terugsending wees van die stelpuntbeheerwaarde wat vanaf die VTN gestuur word. Loonvrag tipe is Hoeveelheid. 'n Tipiese ItemBase is Real Power.
- gestoor Energie – Gestoorde energie word uitgedruk as werklike energie en loonvrag word uitgedruk as 'n Hoeveelheid.
- targetEnergyStorage – Teikenenergie word uitgedruk as werklike energie en loonvrag word uitgedruk as 'n Hoeveelheid.
- upRegulationCapacity Beskikbaar – Up Regulering kapasiteit beskikbaar vir versending, uitgedruk in EMIX Real Power. Loonvrag word altyd as positiewe Hoeveelheid uitgedruk.
- gebruik – Verslag dui 'n hoeveelheid eenhede aan (gedenomineer in ItemBase of in die EMIX-produk) oor 'n tydperk. Loonvrag tipe is Hoeveelheid. 'n Tipiese ItemBase is RealEnergy
- x-hulpbronstatus – Persentasietage van aanvraag
- p – Pico 10**-12
- n – Nano 10**-9
- mikro – Mikro 10**-6
- m – Milli 10**-3
- c – Centi 10**-2
- d – Desi 10**-1
- k – Kilo 10**3
- M – Mega 10**6
- G – Giga 10**9
- T – Tera 10**12
- geen - Inheemse skaal
- BID_ENERGIE – Dit is die hoeveelheid energie van 'n hulpbron wat in 'n program aangebied is
- BID_LOAD – Dit is die hoeveelheid vrag wat deur 'n hulpbron in 'n program aangebied is
- BID_PRICE – Dit is die prys wat die hulpbron bied
- CHARGE_STATE – Toestand van energiebergingshulpbron
- DEMAND_CHARGE – Dit is die aanvraagheffing
- ELECTRICITY_PRICE – Dit is die koste van elektrisiteit
- ENERGY_PRICE – Dit is die koste van energie
- LAA_BEHEER -Stel lasuitset na relatiewe waardes
- LAA_VERSENDING – Dit word gebruik om vrag te stuur
- eenvoudig – afgeskryf – vir terugwaartse versoenbaarheid met A profile
- EENVOUDIG - Eenvoudige vlakke (voldoen aan OpenADR 2.0a)
'n Genoemde waarde wat die tipe sein beskryf soos vlak of prys
- delta – Sein dui die bedrag aan wat verander moet word van wat 'n mens sonder die sein sou gebruik het.
- vlak – Sein dui 'n programvlak aan.
- vermenigvuldigr – Sein dui 'n vermenigvuldiger aan wat toegepas word op die huidige koers van aflewering of gebruik vanaf wat 'n mens sonder die sein sou gebruik het.
- prys – Sein dui die prys aan.
- prysVermenigvuldigr – Sein dui die prysvermenigvuldiger aan. Uitgebreide prys is die berekende pryswaarde vermenigvuldig met die aantal eenhede.
- prys Relatief – Sein dui die relatiewe prys aan.
- Setpoint – Sein dui 'n teiken aantal eenhede aan.
- x-loadControlCapacity – Dit is 'n instruksie vir die lasbeheerder om op 'n vlak van 'n persentasie te werktage van sy maksimum vragverbruikkapasiteit. Dit kan na spesifieke lasbeheerders gekarteer word om dinge soos diensfietsry te doen. Let daarop dat 1.0 verwys na 100% verbruik. In die geval van eenvoudige AAN/UIT tipe toestelle dan 0 = AF en 1 = AAN.
- x-loadControlLevelOffset – Diskrete heelgetalvlakke wat relatief tot normale bewerkings is waar 0 normale bewerkings is.
- x-loadControlPercentOffset – Persentasietage verandering van normale lasbeheerbedrywighede.
- x-loadControlSetpoint – Stelpunte vir lasbeheerder.
– OpenADR A en B Profile Verskille
Die enigste diens wat deur die A profile is die EiEvent-diens. Die EiEvent-objek is vereenvoudig in die A profile met die volgende beperkings:
- Slegs een sein per gebeurtenis word toegelaat en daardie sein moet die OpenADR-bekende sein SIMPLE wees.
- Daar is 'n beperkte gebeurtenis-teikening met slegs venID, groep-ID, hulpbron-ID en party-ID ondersteun.(eiEvent:eiTarget).
- Teiken op die seinvlak met toestelklasse word nie ondersteun nie (eiEventSignal:eiTarget:endDeviceAsset).
- Basislyne word nie ondersteun nie (eiEvent:eiEventSignals:eiEventBaseline).
- modificationDateTime en modificationReason word nie ondersteun nie.
- Die eindpunt URL vir eenvoudige HTTP in 2.0b is:
- https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>
Sommige loonvragelemente wat in die A profile is nou opsioneel in die B profile, insluitend:
- huidige waarde
– OpenADR-sekuriteitsertifikate
Die OpenADR-nakomingsreëls vereis die volgende:
- TLS Weergawe 1.2 word gebruik vir die uitruil van X.509-sertifikate
- VTN's moet beide SHA256 ECC en RSA sertifikate hê
- VENs kan óf SHA256 ECC- en RSA-sertifikate ondersteun, en kan albei ondersteun
- Beide VTN'e en VENs moet gekonfigureer word om kliëntsertifikate aan te vra as hulle die rol van 'n vervoerbediener gaan speel (dws om op versoeke van die ander party te reageer)
- Beide VTN'e en VENs moet 'n kliëntsertifikaat verskaf wanneer dit deur die ander party versoek word as deel van die TLS-onderhandelingsproses
Sertifikate wat deur NetworkFX verskaf word, sal spesifiek vir RSA of ECC wees. Die skepping van hierdie sertifikate kan voorkom as die resultate van die invul van vorms op die NetworkFX web webwerf om toetssertifikate aan te vra of kan die gevolg wees van die versoek van produksiesertifikate via 'n Certificate Signing Request (CSR). Ongeag die metode, die volgende files sal verskaf word (bvamples word gewys):
- Wortelsertifikaat
- Intermediêre wortelsertifikaat
- Toestel Sertifikaat
- Privaat sleutel
Oor die algemeen word die Privaat Sleutel gebruik om loonvragte wat deur 'n VEN of VTN gestuur word, te enkripteer. Die Toestelsertifikaat is 'n stel unieke identifiserende inligting oor 'n VEN of VTN wat deur 'n Sertifikaat-owerheid geskep en geïnkripteer is met behulp van die Privaat Sleutel. Die Wortel en Intermediêre files word gebruik om die Toestelsertifikaat te dekripteer en te bevestig dat die sertifikaat van 'n betroubare owerheid afkomstig is.
In 'n Java-omgewing wat JSSE gebruik, is daar twee sertifikaatwinkels. Een word 'n Trustwinkel genoem en word gebruik om die Wortelsertifikaat te hou. Die tweede word 'n Sleutelwinkel genoem en word gebruik om 'n sertifikaatketting te stoor wat bestaan uit die toestelsertifikaat-intermediêre sertifikaat, sowel as die private sleutel
Neem asseblief kennis dat wanneer 'n XMPP-vervoer gebruik word, die VEN met die XMPP-bediener kommunikeer en NIE direk met die VTN nie. Die konfigurasie van sertifikate in die XMPP-bediener MOET dus gelykstaande wees aan dié van 'n VTN. Die kommunikasie tussen die VTN self en die XMPP-bediener is deursigtig vir die VEN en is in wese 'n private skakel. Nietemin het die meeste verkopers 'n stel VEN-sertifikate in die VTN gebruik wanneer hulle met die XMPP-bediener gekommunikeer het.
As u OpenFire as u XMPP-bediener gebruik, is daar nog 'n beperking wat u moet oorweeg. OpenFire vereis dat die CN-naam wat in die kliënttoestelsertifikate gebruik word, ooreenstem met die toestelle se XMPP-gebruikersnaam wat op die XMPP-bediener opgestel is. Dit kan tot 'n paar vreemde kliëntname lei aangesien 'n MAC-agtige adres gebruik word vir die CN-naam op die VEN-sertifikate (Deel van die OpenADR-sekuriteitsvereistes)
Laastens, die meeste VEN'e en VTN'e sal, wanneer hulle die rol van 'n vervoerkliënt speel, poog om te bevestig dat die CN-veld van die sertifikaat wat deur die vervoerbediener verskaf word, 'n CN-naam het wat ooreenstem met die gasheernaam van die entiteit wat die sertifikaat verskaf het. Dit kan nog 'n bron van interoperabiliteitsprobleme wees wanneer sertifikate uitgeruil word. Gasheernaamverifikasie kan tipies programmaties gedeaktiveer word om hierdie soort kwessies te isoleer.
OpenADR 2.0 Vraagreaksie-programgids – Aflaai [geoptimaliseer]
OpenADR 2.0 Vraagreaksie-programgids – Laai af
