OpenADR 2.0

Udhëzuesi i Programit të Reagimit të Kërkesës

Numri i Rishikimit: 0.92

Statusi i dokumentit: Teksti i punës

Numri i dokumentit: 20140701

Të drejtat e autorit © OpenADR Aleanca (2014/15) Të gjitha të drejtat e rezervuara. Informacioni brenda këtij dokumenti është pronë e Aleancës OpenADR dhe përdorimi dhe zbulimi i tij janë të kufizuara.

PËRMBAJTJA

1 Hyrje 6

2 Referencat 6

3 Termat dhe Përkufizimet 6

4 Shkurtesat 9

5 Llojet e Programit të Reagimit të Kërkesës 9

6 Skenarët e vendosjes 10

6.1 Direkt 1 11

6.2 Direkt 2 12

6.3 Direkt 3 13

6.4 Direkt 4 14

6.5 Lehtësuesi 1 15

6.6 Grumbulluesi 1 16

7 Skenari i Vendosjes dhe Hartësimi i Programit DR 16

8 Përzgjedhja e një modeli të programit DR 18

9 Model të Programit të Reagimit të Kërkesës 21

9.1 Programi kritik i çmimeve të pikut (CPP) 21

9.1.1 Karakteristikat e Programit CPP DR 21

9.1.2 Karakteristikat OpenADR për Programet CPP 22

9.2 Programi i Ofertimit të Kapaciteteve 24

9.2.1 Ofertimi i Kapacitetit Karakteristikat e Programit DR 24

9.2.2 Karakteristikat OpenADR për Programet e Ofertimit të Kapaciteteve 25

9.3 Programi i Termostatit Rezidencial 27

9.3.1 Karakteristikat e Programit DR Termostat Rezidencial 27

9.3.2 Karakteristikat OpenADR për Programet e Termostatit Rezidencial 28

9.4 Shpërndarja e shpejtë e DR 29

9.4.1 Karakteristikat e Programit të Shpejtë të Shpërndarjes DR 29

9.4.2 Karakteristikat OpenADR për Programet e Ofertimit të Kapaciteteve 31

9.5 Programi i Automjetit Elektrik Rezidencial (EV) Koha e Përdorimit (TOU) 33

9.5.1 Karakteristikat e Programit Residential EV TOU 33

9.5.2 Karakteristikat OpenADR për Programet Rezidenciale EV TOU 33

9.6 Programi i Çmimeve në kohë Reale të Automjeteve Elektrike të Stacionit Publik 34

9.6.1 Karakteristikat e Programit EV RTP të Stacionit Publik 34

9.6.2 Karakteristikat OpenADR për Programet RTP të Stacionit Publik EV 34

9.7 Programi i Burimeve të Shpërndara të Energjisë (DER) 35

9.7.1 Karakteristikat e Programit të Burimeve të Shpërndara të Energjisë (DER) 35

9.7.2 Karakteristikat OpenADR për Burimet e Shpërndara të Energjisë (DER) 35

Shtojca A – SampModelet e të dhënave dhe ngarkesës 36

A.1 Programi i Çmimeve Kritike të Kulmit (CPP) 36

A.1.1 CPP Skenari 1 – Rasti i përdorimit të thjeshtë, A ose B Profile 36

A.1.2 CPP Skenari 2 – Rasti i Përdorimit tipik, B profile 36

A.1.3 Skenari 3 i CPP - Rasti i Përdorimit Kompleks 37

A.1.4 CPP Sample Event Payload – Typical B Profile Përdorni rastin 37

A.2 Programi i Ofertimit të Kapaciteteve (CBP) 39

A.2.1 Skenari 1 i BKP - Rasti i përdorimit të thjeshtë, A ose B Profile 39

A.2.2 Skenari 2 i BKP - Rasti tipik i përdorimit, B profile 39

A.2.3 Skenari CBP 3 - Rasti i Përdorimit Kompleks 40

A.2.4 CBP Sample Event Payload – Typical B Profile Përdorni rastin 40

A.3 Programi i Termostatit Rezidencial 42

A.3.1 Skenari 1 i termostatit rezidencial – Rasti i përdorimit të thjeshtë, A ose B Profile 42

A.3.2 Skenari 2 i termostatit rezidencial – Rasti tipik i përdorimit, B profile 42

A.3.3 Skenari i Termostatit Rezidencial 3 - Rasti i Përdorimit Kompleks 43

A.3.4 Termostati rezidencial Sample Event Payload – Typical B Profile Përdorni rastin 43

A.4 Shpërndarja e shpejtë e DR 45

A.4.1 Skenari DR i shpejtë 1 – Rasti i përdorimit të thjeshtë, A ose B Profile 45

A.4.2 Skenari 2 i shpejtë DR – Rasti tipik i përdorimit, B profile 45

A.4.3 Skenari i shpejtë DR - Rasti i përdorimit kompleks 3

A.4.4 E shpejtë DR Sample Event Payload – Typical B Profile Përdorni rastin 46

A.4.5 E shpejtë DR SampRaportoni ngarkesën e meta të dhënave – Tipical B Profile Përdorni rastin 48

A.4.6 E shpejtë DR Sample Raporto Kërkesë për ngarkesën – tipike B Profile Përdorni rastin 48

A.4.7 E shpejtë DR SampRaportoni ngarkesën e të dhënave – Tipical B Profile Përdorni rastin 49

Programi A.5 i Automjeteve Elektrike Rezidenciale (EV) Koha e Përdorimit (TOU) 49

A.5.1 Skenari 1 i EV Rezidenciale – Rasti i përdorimit të thjeshtë, A ose B Profile 49

A.5.2 Skenari 2 i EV Rezidenciale – Rasti i Përdorimit tipik, B profile 50

A.5.3 EV S për banimample Event Payload – Typical B Profile Përdorni rastin 50

A.6 Programi i Çmimeve në kohë Reale të Automjeteve Elektrike të Stacionit Publik 53

A.6.1 Stacioni Publik EV Skenari 1 – Rasti i Përdorimit tipik, B profile 53

A.6.2 Stacioni Publik EV Sample Event Payload – Typical B Profile Përdorni rastin 53

A.7 Programi i Burimeve të Shpërndara të Energjisë (DER) 54

Shtojca B - Përkufizimet e Shërbimit dhe Ngarkesës së Pagesave 55

B.1 ADR e Hapur mbështet shërbimet e mëposhtme: 55

Shtojca C - Përkufizimet e Shërbimit dhe Ngarkesës së Pagesës 56

C.1 Ngarkesat EiEvent 56

C.2 Ngarkesat e EiReport 56

C.3 Ngarkesat EiOpt 56

C.4 Ngarkesat e Partisë EiRegisterParty 57

C.5 Ngarkesat e OadrPoll 57

Shtojca D - Fjalori i Elementeve të Ngarkesës së Skemës 58

Aneksi E Fjalori i Vlerave të Renditura 65

E.1 ngjarjeStatusi 65

E.2 artikulliNjësitë 65

E.3 oadrQualiteti i të dhënave 65

E.4 oadrPërgjigjaKërkuar 66

E.5 zgjedhinArsyeja 66

Emri i Transportit E.6 oadr 66

E.7 OptType 66

Leximi E.8Lloji 66

Raporti E.9Emri 67

Raporti E.10Lloji 67

Shkalla E.11 Kodi 68

Sinjali E.12Emri 68

Sinjali E.13Lloji 69

Aneksi F – OpenADR A dhe B Profile Dallimet 70

Shtojca G - Certifikatat e Sigurisë OpenADR 71

Hyrje

Audienca e synuar për këtë udhëzues është shërbimet që planifikojnë të vendosin programe të Reagimit të Kërkesës (DR) që përdorin OpenADR 2.0 për komunikimin e mesazheve të lidhura me ngjarjen DR midis ndërmarrjes dhe njësive të rrymës dhe prodhuesit e pajisjeve që lehtësojnë atë shkëmbim komunikimi. Supozohet se lexuesi ka një kuptim themelor konceptual të përgjigjes së kërkesës dhe OpenADR 2.0 (referuar thjesht si OpenADR nga kjo pikë e tutje).

Pro OpenADRfile specifikimet përcaktojnë qartë sjelljen e pritshme kur shkëmbehet informacioni i lidhur me ngjarjet DR, megjithatë ka mjaft opsione në OpenADR që vendosja e serverëve (VTN) në shërbimin dhe e klientëve (VEN) në faqet e rrjedhës së poshtme nuk është një përvojë plug-n-play. Karakteristikat e OpenADR të tilla si sinjalet e ngjarjeve, formatet e raportit dhe shënjestrimi duhet të specifikohen mbi bazën e programit për program DR.

Nuk ka diçka të tillë si një program i standardizuar DR. Çdo dizajn i programit DR ka tendencë të jetë unik, duke iu përshtatur kërkesave strukturore dhe rregullatore të rajonit gjeografik në të cilin është vendosur. Për secilin program DR ka skenarë të shumtë të mundshëm të vendosjes që përfshijnë një larmi aktorësh.

Ndryshueshmëria në hartimin e programit DR, skenarët e vendosjes dhe karakteristikat OpenADR janë një frenues për vendosjen e zgjeruar të DR dhe përdorimin e OpenADR. Kjo ndryshueshmëri është në pjesën më të madhe një reflektim i natyrës së fragmentuar dhe komplekse të rrjetit inteligjent.

Shërbimet komunale kanë nevojë p.shampmë shumë nga programet tipike DR në mënyrë që ato të mund të përdoren si modele për zbatimin e tyre të programit DR. Prodhuesit e pajisjeve duhet të kuptojnë modelet tipike të përdorimit të Programit DR në mënyrë që ata të mund të vërtetojnë ndërveprimin si pjesë e procesit të zhvillimit dhe jo në një bazë specifike të vendosjes së programit DR. Qëllimi i këtij udhëzuesi është të përmbushë të dy këto qëllime si më poshtë:

• Përcaktoni një grup të vogël të shablloneve standarde të Programit DR të modeluara sipas karakteristikave të përbashkëta të programeve më të njohura DR të implementuara deri më sot
• Përcaktoni një grup të vogël të skenarëve të vendosjes modeluar sipas vendosjeve në botën reale, me aktorë dhe role të identifikuar qartë
• Përcaktoni rekomandimet e praktikave më të mira për karakteristikat e OpenADR specifike për secilin nga modelet e Programit DR
• Siguroni një pemë vendimesh që shërbimet mund të përdorin për të identifikuar modelet e dobishme të programit DR dhe skenarët e vendosjes bazuar në nevojat e tyre të biznesit

Theksi në këtë udhëzues do të jetë në mbajtjen e gjërave të thjeshta duke siguruar një grup të vogël rekomandimesh të qarta që do të adresojnë shumicën e detajeve të kërkuara për të vendosur një program tipik DR dhe për të mundësuar testimin e ndërveprimit të pajisjeve të vendosura në programe duke përdorur rekomandimet në këtë udhëzues.

Referencat

• OpenADR Profile Specifikimi dhe skema – www.openadr.org

Termat dhe Përkufizimet

Termat dhe përkufizimet e mëposhtme janë përdorur në këtë dokument.

• Përgjigja e Kërkesës: Një mekanizëm për të menaxhuar kërkesën e ngarkesës së klientit në përgjigje të kushteve të furnizimit, të tilla si çmimet ose sinjalet e disponueshmërisë
• Partia grumbulluese - Kjo është një palë që grumbullon burime të shumta së bashku dhe i paraqet ato te Partia e Programit DR si një Burim i vetëm në Programet e tyre DR.
• Infrastruktura ndërmjetësuese e grumbulluesit - Kjo është infrastruktura, e ndarë nga Infrastruktura Anësore e Kërkesës, e cila përdoret nga Partia e Ndërmjetësit Aggregator për të bashkëvepruar si me Burimet ashtu edhe me njësitë anësore të rrjetit
• Marrëveshja: Një marrëveshje kontraktuale midis palëve që luajnë një rol në një program DR duke përshkruar përgjegjësitë dhe kompensimin
• Aseti - Një lloj burimi që përfaqëson një koleksion specifik të ngarkesave fizike. Burimet mund të përbëhen nga Asete, dhe një Pasuri mund të jetë Burim, por Pasuritë nuk mund të zbërthehen më tej në Pasuri ose Burime të shumta.
• I lidhur: Siguroni një shoqatë programatike midis dy njësive, përmes konfigurimit të një pajisje të bazës së të dhënave. Për shembull, burimet e shoqëruara me një VEN
• Vijat bazë: Përdorimi (kërkesa) e energjisë e llogaritur ose e matur nga një pjesë e pajisjeve ose një sit para ngjarjes siç përcaktohet përmes sondazheve, inspektimeve dhe / ose matjes në vendndodhje.
• BMS - Ky është Sistemi i Menaxhimit të Ndërtesës që mund të përdoret për të kontrolluar burimet. Kjo ndonjëherë referohet si një Sistem i Menaxhimit të Energjisë.
• Burimi i përbërë - Ky është një lloj i veçantë i Burimeve që është një bashkim i pasurive të shumta fizike që secili ka mjetet e veta të kontrollit të ngarkesës.
• Nxitja e Klientit: Një nxitje që i ofrohet pronarit / grumbulluesit të burimeve anësore të kërkesës për pjesëmarrje në një program DR.
• Infrastruktura anësore e kërkesës - Kjo është infrastruktura që strehon Burimet që janë regjistruar në Programet DR
• Logjika DR: Algoritme ose logjikë që shndërrojnë sinjalet DR në kontroll të veprueshëm të ngarkesës. Vini re se DR Logic mund të zbatohet në shumë vende të ndryshme dhe në disa raste të shpërndahet midis nën-sistemeve të shumta.
• Partia e Programit DR - kjo është entiteti që është përgjegjës për Infrastrukturën e Rrjetit dhe për më tepër për menaxhimin e Programeve DR të përdorura për të zbutur çështjet e rrjetit. Kjo zakonisht është një Utility ose ISO.
• I regjistruar: Pronari / grumbulluesi i burimeve anësore të kërkesës zgjedh të marrë pjesë në një program DR dhe mund të sigurojë informacion në lidhje me burimet specifike që mund të synohen për ngjarjet e DR
• Periudha Aktive e Ngjarjes: Është periudha në kohë gjatë së cilës një ndryshim në ngarkesën profile është duke u kërkuar si pjesë e një Ngjarje DR
• Kufizimet e ngjarjes: Afatet kohore gjatë të cilave klienti mund të presë të marrë ngjarje dhe kufizime të lidhura me to, të tilla si asnjë ngjarje në fundjavë ose ditë rresht
• Ditët e ngjarjeve: Një ditë kur ndodh një ngjarje DR. Shumica e programeve kanë kufizime në lidhje me numrin e ditëve të ngjarjes që lejohen në një periudhë të caktuar kalendarike
• Përshkrimi i ngjarjes: Pjesë e objektit të ngjarjes OpenADR që përshkruan meta të dhëna për ngjarjen, siç janë emri i programit dhe përparësia e ngjarjes
• Kohëzgjatja e ngjarjes: Gjatësia e ngjarjes. Shumica e programeve përcaktojnë kufizimet në lidhje me kohëzgjatjen e një ngjarjeje, si dhe orët e ditës gjatë të cilave mund të ndodhë ngjarja
• Sinjalet e ngjarjes: Informacioni i veprueshëm që përmbahet në një ngjarje siç është çmimi i energjisë elektrike ose nivelet specifike të ngarkesës së kërkuar që zakonisht shkakton disa sjellje të para-programuara të hedhjes së ngarkesës nga marrësi i ngjarjes. Një përkufizim i programit DR duhet të specifikojë llojet e sinjaleve të ngjarjeve të përdorura
• Shënjestrimi i Ngjarjes: Burimet e zvogëlimit të ngarkesës që janë marrësi i synuar për ngjarjen DR. Mund të jetë një zonë gjeografike, një klasë e veçantë pajisjesh, një identifikues i grupit, ID i burimit ose identifikues tjetër. Një përkufizim i programit DR duhet të specifikojë se si do të synohen burimet specifike.
• Ngjarjet: Një ngjarje është një njoftim nga ndërmarrja për të kërkuar burime anësore që kërkojnë ngarkesë të hequr duke filluar në një kohë të caktuar, mbi një kohëzgjatje të caktuar dhe mund të përfshijë informacionin e shënjestrimit që përcakton burime specifike që duhet të marrin pjesë në ngjarje
• Infrastruktura ndërmjetësuese e lehtësuesit - Kjo është infrastruktura, e ndarë nga Infrastruktura Anësore e Kërkesës, e cila përdoret nga Partia Ndërmjetësuese e Lehtësuesit për të bashkëvepruar si me Burimet ashtu edhe me entitetet anësore të rrjetit.
• Lehtësues: Një palë e tretë që menaxhon disa ose të gjitha ekzekutimet e programit DR në emër të ndërmarrjes
• Infrastruktura e Rrjetit - Kjo është infrastruktura që është në pronësi ose administrohet nga Palët e Programit DR. Kjo infrastrukturë përfshin implementimin e OpenADR VTN që përdoret për të dërguar sinjale DR tek Burimet e regjistruara në Programet DR
• Partia ndërmjetësuese - Kjo është një parti që zakonisht punon në emër të Palës së Burimeve për të lehtësuar pjesëmarrjen e tyre në Programet DR.
• Kontrolli i Ngarkesës – kjo është infrastruktura që lidhet me një burim që është përgjegjës për kontrollin e vërtetë të Burimit dhe prodhimin e një ngarkese specifike profile.
• Ngarko Profile Objektiv: Ky motivim pas zhvillimit të një programi DR dhe dhënies së ngjarjeve. Të tilla si dëshira për të rruajtur ngarkesat e pikut.
• Njoftimi: Një periudhë kohe para kohës së fillimit të një ngjarjeje ku pronari i burimit nga ana e kërkesës njoftohet për një ngjarje në pritje
• Sjellja zgjedhore: Përgjigja e pritur nga pronari i burimit nga ana e kërkesës pas marrjes së një ngjarjeje. Kjo përgjigje mund të marrë formën e dhe treguesit OptIn ose OptOut nëse burimi do të marrë pjesë apo jo në ngjarje
• Përgjigjet e zgjedhura: Nëse një program specifik duhet të kërkojë një përgjigje nga burimet e kërkesës në përgjigje të një ngjarjeje dhe cilat janë ato përgjigje zakonisht.
• Shërbimet e zgjedhura: Oraret e komunikuara përmes OpenADR për të treguar ndryshime të përkohshme në disponueshmërinë e burimeve për të marrë pjesë në ngjarje.
• Kusht paraprak: Kriteret që duhet të plotësohen në mënyrë që një pronar i burimit të kërkesës të regjistrohet në një program DR. Kjo mund të përfshijë disponueshmërinë e takimit në interval ose disa kapacitete minimale të shkarkuara nga ngarkesa
• Drejtuesit kryesorë: Motivimi kryesor nga ana e ndërmarrjes për krijimin e programit DR dhe lëshimin e ngjarjeve. Të tilla si "Ulja e kërkesës maksimale dhe mjaftueshmëria e burimeve"
• Programet - Këto janë Programet DR në të cilat janë regjistruar Burimet.
• Përshkrimi i programit: Një përshkrim narrativ se si funksionon një program. Një pjesë e shablloneve të Programit DR të përcaktuara në këtë dokument
• Korniza kohore e programit: Koha e vitit ose sezonet gjatë një programi DR është zakonisht aktive
• Dizajni i Vlerësimit: Modifikimet specifike të strukturës së normës ose stimujt e paguar për të motivuar pronarët e burimeve nga ana e kërkesës për të marrë pjesë në program
• Shërbimet e Regjistrimit: Shërbimi i përdorur nga protokolli OpenADR për të vendosur ndërveprimin bazë midis një VTN dhe VEN, dhe për të vërtetuar që VEN është i lidhur me llogarinë e klientëve të shërbimeve.
• Shërbimet e Raportimit: Shërbimi i përdorur nga OpenADR për të mundësuar VEN-et të sigurojnë raportim për VEN-et. Programi DR duhet të specifikojë kërkesat e raportimit për programin.
• Partia e Burimeve - Kjo është partia që zotëron anën e kërkesës Burimet që mund të regjistrohen në Programet DR
• Burim – Ky është entiteti që është i regjistruar në Programet DR dhe është në gjendje të japë një lloj ndryshimi në load profile në përgjigje të marrjes së një sinjali DR nga një VTN.
• Klienti i synuar: Profile e burimeve të kërkesës që mund të regjistrohen në një program specifik DR, si p.sh. rezidenciale, industriale, ose ndoshta bazuar në nivelin e konsumit të energjisë elektrike.
• Ngarkesat e synuara: Burimet anësore të kërkesës, ngarkesa e të cilave duhet të modifikohet me marrjen e a
• VEN - Kjo është Nyja Virtuale e Fundit OpenADR që përdoret për të bashkëvepruar me VTN.
• VTN - Kjo është Nyja Top Virtuale OpenADR që përdoret për të bashkëvepruar me Burimet e regjistruara në Programet DR.

Shkurtesat

• BMS: Sistemi i Menaxhimit të Ndërtesave
• C&I: Tregtare dhe Industriale
• Kom: Komunikimet midis dy entiteteve
• DR: Përgjigja e kërkesës
• EMS: Sistemi i Menaxhimit të Energjisë
• OpenADR: Përgjigjja e hapur e kërkesës së automatizuar
• Programet: Referencë për një program (a) të përgjigjes ndaj kërkesës
• VEN: Nyja Virtuale e Fundit
• VTN: Nyja Top Virtuale

Llojet e programit të përgjigjes ndaj kërkesës

Ky dokument përmban shabllone për programet DR të paraqitura më poshtë.

 

1. Çmimet kritike të pikut: Shkalla dhe / ose struktura e çmimeve e krijuar për të inkurajuar konsumin e zvogëluar gjatë periudhave me çmime të larta të tregut me shumicë ose paparashikime të sistemit duke vendosur një normë të lartë ose çmim të paracaktuar për një numër të kufizuar ditësh ose orësh.

2. Programi i Ofertimit të Kapaciteteve: Një program i cili lejon një burim kërkese në tregjet me pakicë dhe shumicë të ofrojë ulje të ngarkesës me një çmim, ose të identifikojë se sa ngarkesë është e gatshme të shkurtojë me një çmim specifik.

 

3. Programi i Termostatit Rezidencial / Kontrolli i Drejtpërdrejtë i Ngarkesës: Një aktivitet i përgjigjes ndaj kërkesës me të cilin sponsori i programit kontrollon në distancë pajisjet elektrike të një klienti (p.sh. kondicioneri) me njoftim të shkurtër. Këto programe u ofrohen kryesisht klientëve rezidencialë ose të vegjël komercialë.

4. Programi i Shpejtë i Shpërndarjes së DR / Shërbimeve Ndihmëse: Një program i përgjigjes së kërkesës që ofron pagesa nxitëse për klientët për përgjigjen e ngarkesës gjatë një Ngjarje të Përgjigjes së Kërkesës Emergjente. Një gjendje jonormale e sistemit (p.shample, kufizimet e sistemit dhe kufizimet e kapacitetit lokal) që kërkon veprime manuale automatike ose të menjëhershme për të parandaluar ose kufizuar dështimin e pajisjeve të transmetimit ose furnizimit të gjenerimit që mund të ndikojë negativisht në besueshmërinë e Sistemit Elektrik Bulk. Këto lloj programesh ndonjëherë mund të referohen si "Shërbime Ndihmëse".

5. Programi DR i Automjetit Elektrik (EV): Një aktivitet i përgjigjes ndaj kërkesës me të cilin modifikohet kostoja e karikimit të automjeteve elektrike për të bërë që konsumatorët të zhvendosin modelet e konsumit.

6. Programi DR i Burimeve të Shpërndara të Energjisë (DER): Një aktivitet i përgjigjes së kërkesës i përdorur për të zbutur integrimin e shpërndarjes së burimeve të energjisë në rrjetin inteligjent.

 

Skenarët e vendosjes

Mënyra në të cilën vendoset një program DR është disi i pavarur nga karakteristikat e vetë programit DR. Diagramet e mëposhtme tregojnë një larmi mënyrash në të cilat mund të vendoset një program DR. Seksioni i mëposhtëm ofron një referencë të kryqëzuar midis skenarëve të vendosjes dhe programeve DR, me të cilat ka më shumë gjasa të përdoren.

Diagramet në këtë seksion tregojnë marrëdhëniet ndërmjet entiteteve në skenarët e ndryshëm.

Direkt 1

Ky është një skenar i thjeshtë në të cilin ekziston një marrëdhënie e drejtpërdrejtë midis Palës së Programit DR dhe Palës së Burimeve. Pala e Burimeve është përgjegjëse për regjistrimin e burimeve të veta në Programet DR dhe Infrastruktura e Rrjetit ndërvepron drejtpërdrejt me Burimet nëpërmjet një VEN që ndodhet brenda Infrastrukturës së Anës së Kërkesës. Për më tepër, VEN është në pronësi të Palës së Burimeve dhe është e ndarë nga Burimet dhe kontrollorët e tyre. Kur një sinjal DR merret nga VEN, ai zakonisht nuk zbaton asnjë logjikë të kontrollit të ngarkesës, por thjesht ua përcjell sinjalet kontrolluesve të ngarkesës të cilët ndërmarrin veprimet e duhura. p.shampPjesët e këtij skenari do të përfshinin ndërtesa C&I që mund të instalojnë një portë që përmban një OpenADR VEN dhe kur një sinjal merret nga ajo portë, ai thjesht e përkthen atë në një protokoll tjetër dhe ia përcjell vetë kontrolluesve të ngarkesës.

Direkt 2

Ky është shumë i ngjashëm me skenarin Direct 1. Dallimi kryesor është në mënyrën se si VEN instantohet dhe ndërveprimet me VTN-në lehtësohen. VEN është krijuar në një entitet si një BMS e centralizuar që mund të zbatojë logjikën DR dhe të ndërveprojë me Compound Resource dhe kontrolluesit e tyre të shumtë të ngarkesës nga një vendndodhje më e centralizuar. p.shampato përfshijnë ndërtesa të mëdha me një BMS që kontrollojnë shumë ngarkesa të ndryshme në një ndërtesë (p.sh. ndriçimi, HVAC, proceset industriale, etj.) deri në camppërdorime që mund të kenë objekte të shumta me një sistem kontrolli të centralizuar.

Direkt 3

Ky skenar është shumë i ngjashëm me skenarin Direct 1. Dallimi kryesor është se VEN është instancuar drejtpërdrejt në burim dhe kontrolluesin e tij të ngarkesës. Në këtë rast, sinjalet DR dërgohen drejtpërdrejt te burimi dhe kontrolluesi i ngarkesës së tij. Skenari i ashtuquajtur "çmimet për pajisjet" bie në këtë kategori. p.shampKëto do të përfshinin çdo lloj kontrolluesi të ngarkesës si p.sh. HVAC (dmth termostat) që ka një VEN të integruar që është në gjendje të ndërveprojë drejtpërdrejt me entitetet anësore të rrjetit VTN.

Direkt 4

Ky është një kombinim i llojeve të skenarëve Direct 1 dhe Direct 2. Dallimi kryesor është se VEN-të e shumta janë të lidhura me një burim të vetëm Kompleksi që përbëhet nga shumë asete me kontrolluesit e tyre të ngarkesës. Secili nga kontrollorët e ngarkesës që përbëjnë Burimin Kompleksi mund të shoqërohet me një VEN të ndryshëm. Vini re se të gjitha VEN-të do të jenë nën kontrollin e së njëjtës Palë Burimore që zotëron Burimin e Përbërë. Ky skenar ekziston për të lehtësuar Infrastrukturat e Anës së Kërkesës që kanë burime të përbëra, por nuk kanë një BMS të centralizuar si skenari Direct 2. p.shampKëto mund të përfshijnë ndërtesa me kontrollues të ndryshëm të ngarkesës në çdo kat, por pa BMS të centralizuar, ose camppërdor me kontrollues të ndryshëm në çdo ndërtesë, por jo campne kontrollues të gjerë. Meqenëse nga këndvështrimi i Palës së Programit DR, ekziston vetëm një burim i vetëm i regjistruar në program kur ai dëshiron të dërgojë një sinjal DR tek burimi, ai thjesht mund të dërgojë të njëjtat sinjale në secilin prej VEN-ve të përcaktuara që janë shoqëruar me Burimin.

Lehtësuesi 1

Në këtë skenar ekziston një ndërmjetës që lehtëson ndërveprimet ndërmjet Palës së Programit DR dhe Burimeve. Zakonisht Pala Ndërmjetësuese punon në emër të Palës Burimore për t'i ndihmuar ata të menaxhojnë Burimet e tyre. Palët Burimore kanë marrëdhënie të drejtpërdrejta me Palën e Programit DR dhe ato regjistrojnë burimet e tyre në Programet DR. Kështu Partia e Programit DR viewSecila Palë Burimore si një Burim i veçantë dhe mund të ndërveprojë me ta individualisht. Roli i Palës Ndërmjetëse është të veprojë si një ndërmjetës për të gjitha ndërveprimet e lidhura me OpenADR, kështu që VEN është instancuar brenda Infrastrukturës Ndërmjetësuese të Lehtësuesit. Një infrastrukturë e tillë është shpesh baza cloud dhe u ofrohet Palëve të Burimeve si Softuer si Shërbim (SaaS). Kur sinjali DR merret nga VEN-i i Lehtësuesit, mund të kryhen një sërë veprimesh të ndryshme duke përfshirë përcjelljen e sinjalit DR në burimin e duhur dhe ndoshta zbatimin e një lloj logjike DR dhe dërgimin e komandave të kontrollit të ngarkesës tek kontrolluesi i ngarkesës së çdo burimi. p.shampPjesët e këtij skenari përfshijnë:

• Shitësit që administrojnë pajisjet për zinxhirët e mëdhenj komercialë siç janë shitësit me pakicë të madhe.
• Ndërmjetësuesit e kontrollit industrial.
• Kompanitë e Shërbimeve të Energjisë (ESCO)
• Sistemet e administrimit të pajisjeve dhe pajisjeve të bazuara në re, siç janë shitësit e termostatëve komunikues të zgjuar.

Grumbulluesi 1

Ky skenar është i ngjashëm me skenarin e Lehtësuesit. Dallimi kryesor është se Partia Grumbulluese ka marrëdhënie me Partinë e Programit DR në krahasim me Palët e Burimeve. Partia Grumbulluese grumbullon Pasuri të shumta të klientëve në një Burim të vetëm që regjistron në Programet DR. Partia e Programit DR nuk ka shikueshmëri në Pasuritë individuale që Agreguesi po administron. Ashtu si me Facilitatorin, Aggregatori ka infrastrukturën e vet ku iniciohet VEN. Dallimi është se kur merret një sinjal DR ai referon një burim të vetëm dhe Aggregator zbaton një lloj logjike DR mbi të gjitha Asetet në portofolin e tyre për të arritur objektivat e specifikuara në sinjalin DR.

 

Skenari i vendosjes dhe Hartësimi i Programit DR

Tabela më poshtë jep se cilat skenarë të vendosjes janë më të zakonshme për një Program specifik DR.

	Skenari i vendosjes
Modeli DR	Drejtpërdrejtë 1, 2, 3, 4	Lehtësuesi 1	Grumbulluesi 1
Programi CPP	∆	∆
Programi i Ofertimit të Kapaciteteve			∆
Termostat rezidencial Programi		∆
Shpërndarja e shpejtë e DR			∆
Programi DR i Automjetit Elektrik (EV)	∆	∆
Programi DR i Burimeve të Shpërndara të Energjisë (DER)	∆	∆

Përzgjedhja e një modeli të programit DR

Më poshtë janë një sërë pyetjesh që janë të rëndësishme për çdo ndërmarrje që do të zbatojë një program të ri DR. Kjo nuk ka për qëllim të jetë gjithëpërfshirëse, por përfaqëson disa nga çështjet më përkatëse. Qëllimi i këtyre pyetjeve është të ndihmojë udhëzimin e shërbimeve drejt një grupi të përshtatshëm të shablloneve të Programit DR.

Pyetje: Pse doni të bëni DR? Çfarë gjendje të rrjetit ose çështje operacionale po përpiqeni të zbutni me DR?

Kjo është padyshim pyetja më e rëndësishme dhe përbën bazën për kërkesat dhe objektivat e përgjithshme për atë që programi DR supozohet të arrijë. Përgjigja për këtë pyetje përcakton se si ngarkohet pro nga ana e kërkesësfile supozohet të formësohet nga programi DR. Të gjitha kërkesat e tjera rrjedhin nga përgjigja e kësaj pyetjeje.

• A po përpiqesh të rruash majat?
• A doni të mbushni barkun e rosës?
• A po përpiqeni të mbroni çmimin vendor të energjisë elektrike?
• A jeni i shqetësuar me besueshmërinë e rrjetit?
• A po përpiqeni të ruani asetet e rrjetit?
• Etj etj.

Tabela më poshtë ofron disa kontekste shtesë për motivimet prapa dëshirës për të zhvilluar një Program DR

Besueshmëria dhe siguria e rrjetit	Frekuenca dhe Voltage Stabiliteti
	Mjaftueshmëria e burimeve
	Kapaciteti i pikut
	Ramping
	Kontingjent
Prokurimi i energjisë	Çmimet në treg
	Arbitrazhi i Çmimit
Menaxhimi i Aseteve	Parandalimi i dëmeve
	Reduktimi i Mirëmbajtjes
	Zgjatje gjatë gjithë jetës
Menaxhimi i Kapaciteteve	Përfitimet ekonomike
	Menaxhimi i Emergjencave
Mjedisore	Negavat
	Energji e Pastër

Pyetje: A ekziston tashmë një program ekzistues ose tarifë DR për këtë program?

• Shpesh herë rregullat e programit përcaktohen qartë në një tarifë.

Pyetje: Cilin segment të tregut nga ana e kërkesës po synoni me këtë program?

Kjo mund të ndihmojë në përcaktimin e shënjestrimit të burimeve në ngjarje dhe llojin e sinjalit.

• Rezidenciale
• C & I i madh
• C&I i vogël
• Bujqësia
• Menaxhimi i ujit
• Automjete elektrike
• etj, etj, etj

Pyetje: A po përpiqeni të synoni lloje specifike të ngarkesave?

• Termostatet
• Automjetet elektrike
• Pompa ag
• etj.

Pyetje: Cili është modeli juaj i vendosjes?

Përgjigja për këtë pyetje mund të ndikojë në mënyrën se si përcaktohen burimet brenda programit dhe të përcaktojë se si ato burime synohen brenda ngjarjeve.

• Direkt tek klientët
• Përmes ndërmjetësve si grumbulluesit ose lehtësuesit
• Konsumatori përgjegjës për prokurimin dhe vendosjen e pajisjeve të tyre VEN?
• etj.

Pyetje: Në cilin nivel specifikash dëshironi të ndërveproni me ngarkesat anësore të kërkesës?

Kjo pyetje ka të bëjë disi me modelin e vendosjes dhe përcakton se si burimet në program përcaktohen dhe synohen. Isshtë një nga pyetjet më të rëndësishme dhe ndoshta komplekse.

• Ndërveproni me secilin burim individual
• Ndërveproni përmes një lehtësuesi ose grumbulluesi pa specifikimin e burimeve prapa tyre
• Ndërveproni përmes një lehtësuesi ose grumbulluesi DHE specifikoni se cilat burime duhet të dërgohen
• Përdorni vendndodhjen si një atribut për të specifikuar burimet
• Përdorni një lloj mekanizmi grupimi të përcaktuar nga dobia për të specifikuar burimet
• Synoni pasuritë individuale siç janë termostatet
• Ndërveproni pa burime fare dhe transmetoni thjesht ngjarje DR
• etj.

Pyetje: Çfarë modeli ndërveprimi dëshironi të përdorni për të ndikuar në ngarkesën e klientëve tuaj profiles?

Kjo pyetje përcakton llojin e sinjaleve DR që do t'u dërgohen pjesëmarrësve në një program.

• Nxitjet (p.sh. çmimi dinamik)
• Dërgimet e ngarkesave (p.sh. shërbimet ndihmëse)
• Kontroll i drejtpërdrejtë i ngarkesës
• Sinjali gjenerik i ngjarjes
• etj.

Pyetje: Cilat janë atributet e përgjithshme të planifikimit të burimeve të programit?

• Datat dhe kohët kur ngjarjet mund të quhen
• Frekuenca e ngjarjeve
• Kohëzgjatja e ngjarjeve
• Vonesat e lejueshme për përhapjen e ngjarjeve
• etj.

Pyetje: Si përcaktohet disponueshmëria e burimeve në program?

• Sipas rregullave strikte të programit
• Si pjesë e disa proceseve të nominimit ose ofertës të bëra nga burimi
• Lejohet hyrja / dalja?
• etj.

Pyetje: Çfarë lloj shikueshmërie ju nevojitet në performancën e burimit?

Kjo është një pyetje shumë e gjerë dhe përcakton se çfarë lloj informacioni merret nga burimet në programin DR. Në përgjithësi kjo përcakton llojin e raporteve që kërkohen.

• Në linjë / Jashtë linje
• Përdorimi (aktual dhe / ose historik)
• Potenciali i përgjigjes së ngarkesës
• Disponueshmëria e ngarkesës
• Gjendja e ngarkesës / asetit (aktuale dhe / ose historike)
• Etj, etj etj

Modelet e Programit të Reagimit të Kërkesës

Programi kritik i çmimeve të pikut (CPP)

Karakteristikat e programit CPP DR

Ngarko Profile Objektiv	-Zvogëlimi i kërkesës maksimale
Drejtuesit kryesorë	-Zvogëluar shpenzimet kapitale dhe ulur kostot e energjisë
Përshkrimi i programit	Kur ndërmarrjet vëzhgojnë ose parashikojnë çmime të larta të tregut me shumicë ose kushtet emergjente të sistemit të energjisë, ato mund të quajnë ngjarje kritike gjatë një periudhe të caktuar kohore (p.sh., 3 pasdite - 6 pasdite në një ditë të nxehtë të verës), çmimi i energjisë elektrike gjatë këtyre periudhave kohore është në i ngritur
Nxitja e Klientit	Konsumatorëve mund t'u ofrohen çmime të energjisë së zbritur gjatë periudhave jo të pikut si një nxitje për të marrë pjesë në program.
Dizajni i Vlerësimit	CPP është një program çmimesh me ritme që rriten gjatë kulmeve kritike të konsumit të energjisë. Në mënyrë tipike, normat e CPP janë një mbledhës ose shumëzues i normave bazë të sheshta, të niveleve ose TOU.
Klienti i synuar	-Rezidenciale ose C&I
Ngarkesa e synuar	-Ado
Kusht paraprak	-Konsumatori duhet të ketë matjen e intervalit -Klientët e C & I mund të duhet të plotësojnë një kriter të kërkesës
Korniza kohore e programit	-Tipikisht shtrihet në muaj të vitit ku ndodh kulmi i konsumit të energjisë, edhe pse mund të jetë gjatë gjithë vitit në disa raste.
Kufizimet e ngjarjes	-Tipikisht e hëna deri të premten, me përjashtim të festave, me ngjarje të njëpasnjëshme të lejuara zakonisht
Ditët e ngjarjeve	-Tipike 9 deri në 15 në vit
Kohëzgjatja e ngjarjes	-Tipike gjatë një afati kohor fiks për të gjitha ngjarjet që variojnë nga 4 deri në 6 orë gjatë kohës më të lartë të konsumit të energjisë në ditë.
Njoftimi	-Tipike një ditë përpara
Sjellja e Zgjedhur	-Tipike klientëve nuk u kërkohet të marrin pjesë në ngjarje
Certifikimi Ngjarjet	-Tipikisht asnjë

Karakteristikat OpenADR për Programet CPP

Sinjalet e ngjarjes	–Një sinjal i thjeshtë me nivelet 1 deri në 3 i pasqyruar në ndikimin e çmimit të ngjarjes CPP. Nëse një program CPP ka një përbërës të vetëm çmimi, ai duhet të vendoset në nivelin 1. Për programet CPP me përbërës të shumtë të çmimit, përbërësi më i vogël i çmimit duhet të shënohet në nivelin 1, me përbërësit e tjerë të çmimit të shënuar në nivelet 2 dhe 3 në shkallë në rritje të ndikimit të çmimeve. -Nëse vendosja mbështet B profile VEN, përveç sinjalit SIMPLE, mund të përfshihet një sinjal ELECTRICITY_PRICE në ngarkesën me një lloj çmimi relativ, çmimi absolut, ose çmimi shumëzues në varësi të natyrës së programit. Shih Aneksin A për shembullamples.
Përgjigjet e zgjedhura	-VTN që dërgojnë ngjarje duhet të vendosë elementin oadrResponseRequired në "gjithmonë", duke kërkuar që VEN të përgjigjet me një optIn ose optOut -Siqë pjesëmarrja në një program CPP është një ushtrim "përpjekja më e mirë", nuk ka asnjë kuptim zyrtar të zgjedhësh ose të zgjedhësh përtej një treguesi të disponueshmërisë me mirësjellje të qëllimit për të marrë pjesë. Ne rekomandojmë që VEN-të përgjigjen me optIn nëse nuk ka pasur ndonjë veprim të veçantë të mbivlerësimit të ndërmarrë nga klienti. - Ngarkesa e ngarkesës oadrCreateOpt zakonisht nuk do të përdoret për të kualifikuar burimet që marrin pjesë në ngjarje.
Përshkrimi i ngjarjes	-Ngjarja përparësia duhet të vendoset në 1 përveç nëse rregullat e programit ose konfigurimi i VTN specifikojnë ndryshe –Ngjarjet e provës zakonisht nuk përdoren me programet CPP. Sidoqoftë nëse lejohen, elementi testEvent duhet të vendoset në "true" për të treguar ngjarjen e testit. Nëse kërkohet informacion shtesë i parametrizuar në këtë element, ai mund të ndjekë "të vërtetë" të ndarë nga një hapësirë ​​me këtë informacion shtesë.
Periudha Aktive e Ngjarjes	– eiRampUp, eiRecovery, elementët e tolerancës zakonisht nuk përdoren
Vijat bazë	–Vijat bazë zakonisht nuk përfshihen në ngarkesën e ngjarjeve
Shënjestrimi i Ngjarjes	-Programet e CPP-së zakonisht nuk bëjnë dallimin midis burimeve për një klient të caktuar. Shënjestrimi zakonisht specifikon venID, duke treguar që të gjitha burimet e lidhura me VEN duhet të marrin pjesë, ose një listë e të gjitha burimeve ID shoqerohet me VEN.
Shërbimet e Raportimit	–Raportimi i telemetrisë zakonisht nuk përdoret pasi nuk është absolutisht e nevojshme për programet CPP. Referojuni Aneksit B për shembullampraporte nga pilotët e shërbimeve që mund të jenë të zbatueshme për këtë lloj programi.

Shërbimet e zgjedhura	–Përdorimi i shërbimit Opt për të komunikuar oraret e disponueshmërisë së përkohshme zakonisht nuk do të përdoren si pjesë e një programi CPP. Sidoqoftë, disa vendosje mund ta përdorin këtë shërbim për të ruajtur ditët e mundshme të ngjarjeve për klientët që tregojnë mungesë të disponueshmërisë.
Shërbimet e Regjistrimit	Intervalet e votimit i kërkuar nga VTN për programet tipike të CPP të një dite më parë nuk kërkohet të jenë më të shpeshta se një herë në orë. Sidoqoftë, përdorimi i sondazhit për zbulimin e rrahjeve të zemrës mund të kërkojë sondazh më të shpeshtë.

Programi i Ofertimit të Kapaciteteve

Karakteristikat e Programit DR Ofertimi i Kapacitetit

Ngarko Profile Objektiv	- Ulja e kërkesës së pikut dhe mjaftueshmëria e burimeve
Drejtuesit kryesorë	-Zvogëluar shpenzimet kapitale dhe ulur kostot e energjisë
Përshkrimi i programit	Programi i ofertës së kapacitetit përdoret nga ISO / shërbimet për të marrë kapacitetin e ngarkuar paraprakisht të ngarkuar nga grumbulluesit ose klientët e vetë-grumbulluar. Ky kapacitet i ngarkuar paraprakisht i ngarkuar është shfrytëzuar nga ISO / shërbimet kur ata vëzhgojnë ose parashikojnë çmime të larta të tregut me shumicë, kushtet emergjente të sistemit të energjisë, ose si pjesë e shfrytëzimit normal të burimeve të energjisë duke thirrur ngjarjet DR gjatë një periudhe të caktuar kohe.   Vini re se secili grumbullues është zakonisht përgjegjës për hartimin e programit të tyre të përgjigjes ndaj kërkesës, si dhe blerjen e klientit, dhe njoftimin e ngjarjes në mënyrë që të përmbushë zotimet e kapacitetit të bëra si pjesë e këtij programi.
Nxitja e Klientit	Grumbulluesit / klientët marrin dy lloje stimujsh. Së pari, ata marrin një pagesë të kapacitetit për mbajtjen e një sasie specifike të kapacitetit të zvogëluar të ngarkesës për ngjarjet DR gjatë një afati kohor të ardhshëm. Së dyti, nëse një ngjarje thirret gjatë dritares së ardhshme kohore, një pagesë e energjisë mund të bëhet për ngarkesën e hedhur gjatë kohëzgjatjes së ngjarjes.
Dizajni i Vlerësimit	Pjesëmarrësit në program bëjnë një ofertë për "nominimin e kapacitetit" duke treguar kapacitetin e zvogëluar të ngarkesës që ata janë të gatshëm të mbajnë si të disponueshëm gjatë një afati të ardhshëm kohor. Oferta mund të përfshijë gjithashtu nxitjen që grumbulluesi / klienti është i gatshëm të pranojë për ngarkesën e hedhur poshtë një vlere fillestare. Në tregjet e ndërmarrjeve zotimi i kapacitetit është zakonisht për muajin e ardhshëm kalendarik, megjithëse në tregjet ISO përdoren korniza kohore shumë më të gjata. Si pjesë e emërimit të kapacitetit, klienti mund të jetë në gjendje të zgjedhë midis një numri karakteristikash duke përfshirë njoftimin ditë përpara ose ditën e njoftimit dhe dritaren e kohëzgjatjes së ngjarjes (të tilla si 1-4 orë, 2-6 orë,…). Një pagesë e kapacitetit i bëhet klientit për këtë para-zotim edhe nëse nuk ka ndonjë ngjarje të thirrur gjatë dritares së kohës. Nëse një ngjarje thirret gjatë dritares kohore, konsumatori mund të marrë një pagesë energjie për ngarkesën e hedhur në lidhje me një bazë fillestare, megjithatë gjobat mund të zbatohen nëse dorëzohet më pak se kapaciteti i shkarkimit të ngarkesës së para-kryer në kohën kur thirret ngjarja.
Klienti i synuar	-Agreguesit dhe klientët e vetë-grumbulluar të C&I
Ngarkesat e synuara	- Ndonjë

Kusht paraprak	-Konsumatori duhet të ketë matjen e intervalit -Klientët e C & I mund të duhet të plotësojnë një kriter të kërkesës ose ofertës
Korniza kohore e programit	-Kurdo
Kufizimet e ngjarjes	-Tipikisht e hëna deri të premten, me përjashtim të festave, me ngjarje të njëpasnjëshme të lejuara zakonisht
Ditët e ngjarjeve	-Tipikisht maksimumi 30 orë në muaj
Kohëzgjatja e ngjarjes	-Tipikisht gjatë një dritare kohore fikse për të gjitha ngjarjet gjatë kohës më të lartë të konsumit të energjisë në ditë.). Kohëzgjatja e ngjarjes ndryshon nga angazhimi i kapacitetit të klientit me preferenca që variojnë nga 1 deri në 8 orë ose siç specifikohet nga modeli i programit
Njoftimi	-Ditë përpara ose ditë në varësi të preferencave të zotimit të kapacitetit të klientit ose modelit të programit
Sjellja e Zgjedhur	-Tipikisht klientët do të zgjedhin ngjarjet duke pasur parasysh që pasi ata kanë para-angazhuar kapacitetin e hedhjes së ngarkesave.
Certifikimi Ngjarjet	-Tipikisht dy në vit (Test)

Karakteristikat OpenADR për Programet e Ofertimit të Kapaciteteve

Sinjalet e ngjarjes	–Një sinjal i thjeshtë me nivelet 1 deri në 3 i hartuar në sasinë e ngarkesës së hedhur. Nëse programi mbështet vetëm një nivel të vetëm të shkarkimit të ngarkesës, ai duhet të hartohet në nivelin 1. Për programet me nivele të shumëfishta të shkarkimit të ngarkesës, ndryshimi më i vogël nga funksionimi normal duhet të vendoset në nivelin 1, me vlerat e shkarkimit të ngarkesës të shënuara në nivelet 2 dhe 3 në rritjen e shkallës së ngarkesës së hedhur. -Nëse vendosja mbështet B profile VEN, përveç sinjalit SIMPLE, mund të përfshihet një sinjal BID_LOAD dhe / ose BID_PRICE në ngarkesën me llojet e sinjalit të pikës së caktuar dhe çmimit, dhe njësitë e energjisëReal dhe valutëPerKW përkatësisht. BID_LOAD do të pasqyrojë ngarkesën e kërkuar të ulur deri në ofertën e shumës së kapacitetit nga grumbulluesi / konsumatori, dhe BID_PRICE do të pasqyrojë ofertën stimuluese nga grumbulluesi / klienti. Shih Aneksin A për shembullamples.
Përgjigjet e zgjedhura	-VTN që dërgojnë ngjarje duhet të vendosë elementin oadrResponseRequired në "gjithmonë", duke kërkuar që VEN të përgjigjet me një optIn ose optOut -Si grumbulluesit / klientët kanë kapacitet të para-zotuar VEN-të duhet të përgjigjen me optIn. Një heqje dorë mund të dërgohet në përgjigje të ngjarjes, por ky është një tregues i disponueshmërisë joformale, jo një heqje dorë zyrtare nga ngjarja. -Të ngarkesa e ngarkesës oadrCreateOpt zakonisht nuk do të përdoret për të kualifikuar burimet që marrin pjesë në ngjarje pasi zakonisht ngarkesa është një njësi e vetme e grumbulluar.
Përshkrimi i ngjarjes	-Ngjarja përparësia duhet të vendoset në 1 përveç nëse rregullat e programit ose konfigurimi i VTN specifikojnë ndryshe –Mund të përdoren ngjarjet e provës me programet e Ofertimit të Kapaciteteve. Nëse lejohen, elementi testEvent duhet të vendoset në "true" për të treguar ngjarjen e testit. Nëse kërkohet informacion shtesë i parametrizuar në këtë element, ai mund të ndjekë "të vërtetë" të ndarë nga një hapësirë ​​me këtë informacion shtesë.
Periudha Aktive e Ngjarjes	– eiRampUp, eiRecovery, elementët e tolerancës zakonisht nuk përdoren
Vijat bazë	–Vijat bazë zakonisht nuk përfshihen në ngarkesën e ngjarjeve pasi këto të dhëna zakonisht nuk janë të disponueshme në kohën kur fillon ngjarja. Megjithatë, si shërbimet komunale ashtu edhe grumbulluesit/klientët do ta bënin view përfshirja e informacionit bazë në ngjarje si të dobishme.
Shënjestrimi i Ngjarjes	-Programet e ofertave të kapaciteteve zakonisht nuk bëjnë dallimin midis burimeve për një klient të caktuar. Shënjestrimi zakonisht specifikon venID, duke treguar që të gjitha burimet e lidhura me VEN duhet të marrin pjesë, ose përfshin një përfaqësues të burimitID të ngarkesës së grumbulluar shoqerohet me VEN.
Shërbimet e Raportimit	Programet e Ofertimit të Kapacitetit ISO zakonisht kërkojnë raporte TELEMETRY_USAGE me pikat e të dhënave powerReal. Shih ishamples në Aneksin A. Raportimi i telemetrisë për ofertën e kapacitetit të shërbimeve zakonisht nuk kërkohet. Vini re se raportimi i telemetrisë kërkon B profile VEN. Referojuni Aneksit B për shembullampraporte nga pilotët e shërbimeve që mund të jenë të zbatueshme për këtë lloj programi.
Shërbimet e zgjedhura	–Përdorimi i shërbimit Opt për të komunikuar oraret e disponueshmërisë së përkohshme zakonisht nuk do të përdoren si pjesë e një programi të Ofertimit të Kapaciteteve pasi klientët kanë para-zotuar disponueshmërinë e tyre. Sidoqoftë, ky shërbim mund të jetë i dobishëm si një mënyrë informale për pjesëmarrësit për të treguar mungesën e disponueshmërisë për arsye lehtësuese të tilla si dështimi i pajisjes.
Shërbimet e Regjistrimit	Intervalet e votimit e kërkuar nga VTN për programe tipike të ditës përpara nuk kërkohet të jenë më të shpeshta se një herë në orë. Sidoqoftë, përdorimi i sondazheve për zbulimin e rrahjeve të zemrës ose programeve ditore mund të kërkojë sondazhe më të shpeshta.

Programi i Termostatit Rezidencial

Ky program është përfaqësues i Kontrollit të Ngarkesës së Drejtpërdrejtë (DLC) ku sinjali i Përgjigjes së Kërkesës modifikon drejtpërdrejt sjelljen e burimeve të hedhjes së ngarkesës, pa një shtresë abstraksioni midis marrjes së sinjalit dhe veprimit specifik të hedhjes së ngarkesës të ndërmarrë.

Karakteristikat e Programit të Termostatit Rezidencial DR

Ngarko Profile Objektiv	-Zvogëlimi i kërkesës maksimale
Drejtuesit kryesorë	-Zvogëluar shpenzimet kapitale dhe ulur kostot e energjisë
Përshkrimi i programit	-Kur ndërmarrjet vëzhgojnë ose parashikojnë çmime të larta të tregut me shumicë ose kushtet emergjente të sistemit të energjisë, ato mund të fillojnë një ngjarje që modifikon sjelljen e termostatit të programueshëm të komunikimit të konsumatorit (PCT) gjatë një periudhe kohore të specifikuar (p.sh., 3 pasdite - 6 pasdite në një nxehtë dita e javës së verës) në mënyrë që të zvogëlohet konsumi i energjisë. -Ndryshimi në sjelljen e PCT në përgjigje të ngjarjes mund të jetë një ndryshim i thjeshtë në pikën e caktuar të temperaturës për kohëzgjatjen për ngjarjen ose një grup më kompleks ndryshimesh, duke përfshirë ftohjen paraprake, që minimizojnë ndikimin e ngjarjes në komoditetin e klientit niveli
Nxitja e Klientit	-Nxitjet marrin dy forma të përgjithshme. Së pari, klientët mund të pajisen me një PCT falas ose të ofrojnë zbritje / zbritje për PC-të e blera nga klientët si një nxitje për t'u regjistruar në programin DR. Së dyti, klientët mund të marrin një pagë vjetore të vazhdueshme për regjistrimin e vazhdueshëm në program. Më pak të zakonshme do të ishin stimujt e vazhdueshëm që u paguhen klientëve bazuar në uljen aktuale të energjisë gjatë ngjarjeve.
Dizajni i Vlerësimit	- Kryesisht një program stimulues, ku klientët marrin PCT me zbritje ose falas për t'u regjistruar në programin DR. Disa programe mund të paguajnë një pagë periodike ose pagesa stimuluese bazuar në uljen e energjisë gjatë ngjarjeve.
Klienti i synuar	-Rezidenciale
Ngarkesa e synuar	-HVAC
Kusht paraprak	-Tipikisht asnjë, pasi klientët marrin një PCT si pjesë e regjistrimit të programit
Korniza kohore e programit	-Tipikisht shtrihet në muaj të vitit ku ndodh kulmi i konsumit të energjisë, edhe pse mund të jetë gjatë gjithë vitit në disa raste.
Kufizimet e ngjarjes	-Tipikisht e hëna deri të premten, me përjashtim të festave, me ngjarje ditore radhazi të lejuara zakonisht.
Ditët e ngjarjeve	-Tipike 9 deri në 15 në vit
Kohëzgjatja e ngjarjes	-Ngjarjet mund të ndodhin në çdo kohë, me kohëzgjatje që variojnë nga 2 deri në 4 orë, edhe pse tipikisht ngjarjet ndodhin gjatë kohës më të lartë të konsumit të energjisë në ditë.
Njoftimi	-Tipikisht një ditë përpara, megjithëse disa programe mund të kenë kohë njoftimi më të shkurtër se 10 minuta.
Sjellja e Zgjedhur	-Klientët nuk janë të detyruar të marrin pjesë në ngjarje, megjithatë ata automatikisht do të marrin pjesë në ngjarje nëse nuk marrin masa për të anashkaluar ngjarjen ose për të bërë rregullime manuale të temperaturës gjatë ngjarjes.
Certifikimi Ngjarjet	-Tipikisht asnjë

Karakteristikat OpenADR për Programet e Termostatit Rezidencial

Sinjalet e ngjarjes	–NJË sinjal i thjeshtë me nivelet 1 deri në 3 të krahasuar me ndryshimin në kompensimet e pikës së caktuar të temperaturës PCT ose përqindjen e ciklit termostatiktage . Nëse një program termostati rezidencial ka një komponent të vetëm kompensimi / çiklizmi, ai duhet të vendoset në nivelin 1. Për programet me komponentë të shumëfishtë kompensimi / çiklizmi, ndryshimi më i vogël nga funksionimi normal duhet të vendoset në nivelin 1, me vlerat e tjera të kompensimit / çiklizmit hartuar në nivelet 2 dhe 3 në rritjen e shkallës së ndikimit të hedhur ngarkesës. -Nëse vendosja mbështet B profile VEN, përveç sinjalit SIMPLE, mund të përfshihet një sinjal LOAD_CONTROL në ngarkesën e ngarkesës me një lloj të x-loadControlLevelOffset ose x-loadControlCapacity për të specifikuar kompensimin e dëshiruar të pikës së caktuar të temperaturës ose përqindjen e ciklit termostatiktage respektivisht. Rifillohet që a lloji i njësisë së "temperaturës" duke u përdorur në ngarkesa duke përdorur sinjalin x-loadControlLevelOffsetTip për të treguar Celsius ose Fahrenheit për kompensimin. Shih Aneksin A për shembullamples.
Përgjigjet e zgjedhura	-VTN që dërgojnë ngjarje duhet të vendosë elementin oadrResponseRequired në "gjithmonë", duke kërkuar që VEN të përgjigjet me një optIn ose optOut – VEN-të duhet të përgjigjen me optIn nëse nuk ka pasur ndonjë veprim specifik të mbivlerësimit të ndërmarrë nga klienti. -Të Ngarkesa e ngarkesës oadrCreateOpt mund të përdoret nga VEN për të kualifikuar pjesëmarrjen e burimeve në një ngjarje. Për shembull, një ngjarje mund të synojë ID e burimeve të dy termostateve që kontrollojnë sisteme të ndara HVAC. Nëse klienti vendos që vetëm një nga sistemet HVAC mund të marrë pjesë në ngjarje, kjo do të komunikohet në VTN duke përdorur ngarkesën oadrCreateOpt. Vini re se ngarkesa e pagesës oadrCreateOpt mbështetet vetëm nga B profile VEN-at
Përshkrimi i ngjarjes	-Ngjarja përparësia duhet të vendoset në 1 përveç nëse rregullat e programit ose konfigurimi i VTN specifikojnë ndryshe –Ngjarjet e provës zakonisht nuk përdoren me programet e Termostatit Rezidencial. Sidoqoftë nëse lejohen, elementi testEvent duhet të vendoset në "true" për të treguar ngjarjen e testit. Nëse kërkohet informacion shtesë i parametrizuar në këtë element, ai mund të ndjekë "të vërtetë" të ndarë nga një hapësirë ​​me këtë informacion shtesë.
Periudha Aktive e Ngjarjes	–Randomizimi zakonisht përdoret për ngjarjet e termostatit të banimit duke përdorur elementin e tolerancës – eiRampElementet Up dhe eiRecovery zakonisht nuk përdoren
Vijat bazë	–Vijat bazë zakonisht nuk përfshihen në ngarkesën e ngjarjeve
Shënjestrimi i Ngjarjes	-Programet e Termostatit Rezidencial synojnë burimet HVAC të kontrolluara nga PCT. Shënjestrimi në mënyrë tipike specifikon burimet ID të sistemeve HVAC (dmth. termostati) i lidhur me VEN ose venID me synimin e klasës së pajisjes së sinjalit të ngjarjes vendosur në Termostat
Shërbimet e Raportimit	–Raportimi i telemetrisë zakonisht nuk përdoret pasi nuk është absolutisht e nevojshme për programet rezidenciale të termostatit Referojuni Aneksit B për shembullampraporte nga pilotët e shërbimeve që mund të jenë të zbatueshme për këtë lloj programi.
Shërbimet e zgjedhura	–Përdorimi i shërbimit Opt për të komunikuar oraret e disponueshmërisë së përkohshme zakonisht nuk do të përdoren si pjesë e një programi CPP.
Shërbimet e Regjistrimit	Intervalet e votimit e kërkuar nga VTN për programet tipike të Termostatit Rezidencial të një dite përpara nuk kërkohet të jenë më të shpeshta se një herë në orë. Sidoqoftë, përdorimi i sondazhit për zbulimin e rrahjeve të zemrës mund të kërkojë sondazh më të shpeshtë siç do programet e termostatit të banimit me kohë njoftimi dukshëm më të shkurtër.

Shpërndarja e shpejtë e DR

Karakteristikat e Programit të Shpejtë të Shpërndarjes DR

Ngarko Profile Objektiv	-Dërgoni burimet për të arritur përgjigjen e ngarkesës në "kohë reale"
Drejtuesit kryesorë	-Besueshmëria e rrjetit dhe shërbimet ndihmëse
Përshkrimi i programit	Fast DR përdoret nga ISO / shërbimet komunale për të marrë përgjigje të ngarkuar paraprakisht në "kohë reale". Kjo përgjigje e ngarkuar paraprakisht shfrytëzohet nga ISO / shërbimet kur ata respektojnë kushtet që kërkojnë veprim të menjëhershëm për të ruajtur stabilitetin dhe integritetin e rrjetit. Në kohë reale do të thotë që burimet zakonisht dërgohen me një vonesë që varion nga 10 minuta për burimet që përdoren si rezerva deri në 2 sekonda për burimet që përdoren për qëllime rregullimi. Madhësia e përgjigjes së ngarkesës duhet të jetë mjaft e madhe për të bërë një ndryshim në zbutjen e gjendjes së rrjetit dhe kështu burimet janë zakonisht shumë të mëdha dhe shpesh menaxhohen nga grumbulluesit si pjesë e një burimi të grumbulluar. Madhësitë minimale për përgjigjen e ngarkesës për një burim për t'u kualifikuar për të marrë pjesë në shërbimet ndihmëse janë zakonisht rreth 500 kW, por mund të jenë deri në 100 kW për disa programe. Vini re se nëse burimi përdoret si rezervë, zakonisht do të thirret për të ulur (dmth. Hedhur) ngarkesën, por nëse përdoret për qëllime rregullimi, mund të dërgohet për të rritur ose ulur ngarkesën.
Nxitja e Klientit	Grumbulluesit / klientët zakonisht marrin dy lloje stimujsh. Së pari, ata marrin një pagesë për kryerjen dhe vënien në dispozicion të një sasie specifike të përgjigjes së ngarkesës në dispozicion për ngjarjet DR gjatë një afati kohor të ardhshëm. Shuma e përgjigjes së ngarkesës, afati i disponueshmërisë dhe shuma që duhet paguar përcaktohet zakonisht nga grumbulluesi / klienti. Së dyti, nëse një ngjarje thirret gjatë dritares së kohës së ardhshme një pagesë e bazuar në sasinë e përgjigjes së ngarkesës gjatë kohëzgjatjes së ngjarjes.
Dizajni i Vlerësimit	Pjesëmarrësit në program paraqesin një ofertë që tregon përgjigjen e ngarkesës që ata janë të gatshëm të vënë në dispozicion gjatë një afati kohor të ardhshëm. Oferta zakonisht përfshin edhe pagesën që grumbulluesi / klienti është i gatshëm të pranojë për përgjigjen e ngarkesës. Në tregjet e shërbimeve/ISO oferta zakonisht dorëzohet ose një ditë përpara ose në ditën e periudhës kohore për të cilën është bërë zotimi. Si pjesë e kualifikimit dhe regjistrimit të tyre në tregje, parametra të ndryshëm të mbështjelljes së performancës lidhen me burimin si p.sh.amp norma dhe kufijtë min dhe maksimal të funksionimit. Parametra të tillë përcaktojnë se si do të dërgohet. Nëse oferta e një pjesëmarrësi pranohet, një pagesë mund t'i bëhet klientit për zotimin e tyre paraprakisht edhe nëse nuk ka ngjarje të thirrura gjatë periudhës kohore. Nëse një ngjarje thirret gjatë periudhës kohore, klienti mund të marrë pagesa shtesë për performancën e tyre gjatë ngjarjes. Pagesa të tilla të bazuara në performancë mund të bazohen në një sërë faktorësh duke përfshirë sasinë e energjisë, fuqinë, sa afër ndjek burimi udhëzimet e dërgimit dhe një pagesë "mileazhi" që pasqyron sa ngarkesën e tyre profile kërkohej të ndryshonte gjatë ngjarjes. Disa nga këto parametra si energjia dhe fuqia mund të jenë në lidhje me një bazë.
Klienti i synuar	-Agreguesit dhe klientët e vetë-grumbulluar të C&I
Ngarkesat e synuara	- Ato që mund të përgjigjen në dërgimet në kohë reale.

Kusht paraprak	-Konsumatori duhet të ketë matjen e intervalit -Duhet të plotësoni kërkesat e madhësisë minimale për përgjigjen e ngarkesës -Duhet të jeni në gjendje t'u përgjigjeni dërgimeve në kohë reale -Tipikisht duhet të furnizoni telemetri në kohë reale që tregon përgjigjen aktuale të ngarkesës
Korniza kohore e programit	-Kurdo
Kufizimet e ngjarjes	-asnjë
Ditët e ngjarjeve	-asnjë
Kohëzgjatja e ngjarjes	-Tipikisht e shkurtër (më pak se 30 minuta), por në asnjë rast nuk do të kalojë kurrë dritaren e kohës që pjesëmarrësi e vuri në dispozicion burimin kur ata dorëzuan ofertën e tyre.
Njoftimi	-asnjë
Sjellja e Zgjedhur	-Klientët vendosin të marrin pjesë në ngjarje si parazgjedhje, duke pasur parasysh se ata kanë përgjigje të ngarkuar paraprakisht
Certifikimi Ngjarjet	-Tipikisht një në vit (Test)

Karakteristikat OpenADR për Programet e Ofertimit të Kapaciteteve

Sinjalet e ngjarjes	–Një sinjal i thjeshtë me nivelet 1 deri në 3 i hartuar në sasinë e përgjigjes së ngarkesës. Nëse programi mbështet vetëm një nivel të vetëm të përgjigjes së ngarkesës, ajo duhet të jetë e shënuar në nivelin 1. Për programet me nivele të ulta të përgjigjes së ngarkesës, ndryshimi më i vogël nga funksionimi normal duhet të vendoset në nivelin 1, me vlerat e shkarkimit të ngarkuar të shënuar në nivelet 2 dhe 3 në rritjen e shkallës së reagimit të ngarkesës. -Nëse vendosja mbështet B profile VEN, përveç sinjalit SIMPLE, mund të përfshihet një dërgim në formën e një sinjali LOAD_DISPATCH në ngarkesën me llojet e sinjalit të pikës së caktuar ose deltës, dhe njësive të energjisëReal. Ky sinjal përfaqëson "pikën e funksionimit" të dëshiruar të ngarkesës dhe mund të shprehet ose si një sasi absolute e mW (p.sh. pika e caktuar) ose ndonjë numër relativ i mW (d.m.th. delta) nga burimet e pikës aktuale të funksionimit. Shih Aneksin A për shembullamples.
Përgjigjet e zgjedhura	-VTN që dërgojnë ngjarje duhet të vendosë elementin oadrResponseRequired në "gjithmonë", duke kërkuar që VEN të përgjigjet me një optIn ose optOut -Si grumbulluesit / klientët kanë kapacitet të para-zotuar VEN-të duhet të përgjigjen me optIn. Një heqje dorë mund të dërgohet në përgjigje të ngjarjes, por ky është një tregues i disponueshmërisë joformale, jo një heqje dorë zyrtare nga ngjarja. -Të ngarkesa e ngarkesës oadrCreateOpt zakonisht nuk do të përdoret për të kualifikuar burimet që marrin pjesë në ngjarje pasi zakonisht ngarkesa është një njësi e vetme e grumbulluar.
Përshkrimi i ngjarjes	-Ngjarja përparësia duhet të vendoset në 1 përveç nëse rregullat e programit ose konfigurimi i VTN specifikojnë ndryshe –Mund të përdoren ngjarjet e provës, veçanërisht gjatë regjistrimit dhe kualifikimit të një burimi. Nëse lejohen, elementi testEvent duhet të vendoset në "true" për të treguar ngjarjen e testit. Nëse kërkohet informacion shtesë i parametrizuar në këtë element, ai mund të ndjekë "të vërtetë" të ndarë nga një hapësirë ​​me këtë informacion shtesë.
Periudha Aktive e Ngjarjes	– Elementet e tolerancës nuk përdoren. EiRampPeriudhat Up dhe eiRecovery janë zakonisht pjesë e parametrave të një burimi kur regjistrohen dhe mund të përdoren. Për shkak të natyrës së dërgesave ato mund të jenë të hapura dhe kështu mund të mos ketë kohë përfundimi për ngjarjen.
Vijat bazë	–Vijat bazë zakonisht nuk përfshihen në ngarkesën e ngjarjeve pasi këto të dhëna zakonisht nuk janë të disponueshme në momentin e fillimit të ngjarjes. Megjithatë, si shërbimet komunale ashtu edhe grumbulluesit/klientët do ta bënin view përfshirja e informacionit bazë në ngjarje si të dobishme.
Shënjestrimi i Ngjarjes	-Programet e ofertave të kapaciteteve zakonisht nuk bëjnë dallimin midis burimeve për një klient të caktuar. Shënjestrimi zakonisht specifikon venID, duke treguar që të gjitha burimet e lidhura me VEN duhet të marrin pjesë, ose përfshin një përfaqësues të burimitID të ngarkesës së grumbulluar shoqerohet me VEN.
Shërbimet e Raportimit	Programet e shpejta DR zakonisht kërkojnë raporte TELEMETRY_USAGE me fuqiPikat e të dhënave reale. Raporti i përdorimit përshkruan pikat aktuale të funksionimit të burimeve dhe përdoret nga Shërbimi / ISO për të përcaktuar se sa nga afër burimi ndjek udhëzimet e dërgimit që janë dërguar. Në disa raste telemetria mund të përfshijë pika të tjera të dhënash si voltagleximet dhe gjendja e ngarkesës (dmth. energjia) në rastin kur burimet janë një formë ruajtjeje. Në disa raste, frekuenca e raportimit mund të jetë deri në çdo 2 sekonda. Vini re se raportimi i telemetrisë kërkon B profile VEN. Shih Aneksin A për shembullamples. Gjithashtu referojuni Shtojcës B për shembullampraporte nga pilotët e shërbimeve që mund të jenë të zbatueshme për këtë lloj programi.
Shërbimet e zgjedhura	–Përdorimi i shërbimit Opt për të komunikuar disponueshmërinë e përkohshme oraret zakonisht nuk do të përdoren pasi klientët e kanë parakushtuar disponueshmërinë e tyre. Sidoqoftë, ky shërbim mund të jetë i dobishëm si një mënyrë informale për pjesëmarrësit për të treguar mungesën e disponueshmërisë për arsye lehtësuese të tilla si dështimi i pajisjes.
Shërbimet e Regjistrimit	Për shkak të kërkesave të ulëta të latente të dërgimeve në kohë reale përdoren vetëm modelet e ndërveprimit me shtytje.

Programi për kohën e përdorimit të automjeteve elektrike rezidenciale (EV)

Karakteristikat e Programit Rezidencial EV TOU

Ngarko Profile Objektiv	Një strukturë norme me të cilën modifikohet kostoja e karikimit të automjeteve elektrike për të bërë që konsumatorët të zhvendosin modelet e konsumit.
Drejtuesit kryesorë	Përdorimi i energjisë rezidenciale arrin kulmin në mbrëmje. Meqenëse karikimi EV kërkon 4-8 orë, mund të vonohet për disa orë për të zhvendosur majat e ngarkesës.
Përshkrimi i programit	Klientët që kanë një automjet elektrik mund të regjistrohen për një tarifë të Kohës së Përdorimit të Automjetit Elektrik (EV-TOU) dhe të marrin tarifa më të ulëta për karikimin e automjetit të tyre gjatë orëve jashtë pikut, siç janë tarifat mes mesnatës dhe 5 të mëngjesit EV-TOU ofrohet për të inkurajuar klientët të kufizojnë përdorimin e energjisë elektrike gjatë ditës, kur kërkesa për energji elektrike është më e larta.
Nxitja e Klientit	Karikim më pak i shtrenjtë për EV.
Dizajni i Vlerësimit	TOU me kulmin e mesit të ditës, mes-pikun e mëngjesit dhe mbrëmjes, dhe pikun 12 deri në 5 të mëngjesit
Klienti i synuar	Pronar EV me një profesionist të ngarkesësfile që arrin kulmin në mbrëmje.
Ngarkesat e synuara	Karikuesit EV
Kusht paraprak	Konsumatori duhet të ketë një matës inteligjent dhe EV
Korniza kohore e programit	Gjithë vitin
Kufizimet e ngjarjes	Asnjë
Ditët e ngjarjeve	Çdo ditë, ose vetëm gjatë ditëve të javës
Kohëzgjatja e ngjarjes	5-8 orë
Njoftimi	Konsumatori njoftohet për nivelet e çmimeve në faturat e tyre mujore dhe VTN-të dërgojnë sinjale të ngjarjeve një ditë më parë.
Sjellja e Zgjedhur	Pagesat e tarifave mund të ndryshojnë planin e tyre të normës siç do të bënin normalisht me një ndërmarrje.
Certifikimi Ngjarjet

Karakteristikat OpenADR për Programet Rezidenciale EV TOU

Sinjalet e ngjarjes	Sinjalet ELECTRICITY_PRICE me nivele aktuale të çmimeve, si dhe sinjale të thjeshta për të lejuar pjesëmarrjen nga 2.0a VEN Shih Aneksin A për shembullamples.
Përgjigjet e zgjedhura	Gjithmonë vendosni nga VEN
Përshkrimi i ngjarjes	Një ngjarje në javë, me intervale të ngjarjeve për secilën shtresë të çmimeve
Periudha Aktive e Ngjarjes	Duhet të përdoret së paku njoftimi 24 orësh. Çdo interval i ngjarjes duhet të kapë nivelin e shkallës TOU
Vijat bazë	N/A
Shënjestrimi i Ngjarjes	Nuk kërkohet shënjestrim i përparuar, vetëm shënjestrim në nivelin VEN.
Shërbimet e Raportimit	Nuk ka nevojë për raportim, të gjitha të dhënat mund të vijnë nga njehsori. Referojuni Aneksit B për shembullampraporte nga pilotët e shërbimeve që mund të jenë të zbatueshme për këtë lloj programi.
Shërbimet e zgjedhura	Shërbimet e zgjedhura nuk do të ishin të rëndësishme për këtë lloj programi.
Shërbimet e Regjistrimit	Konsumatorët do të siguronin paraprakisht VEN-in e tyre me shërbimin për të marrë sinjale çmimi.

Programi i Çmimeve në kohë Reale të Automjeteve Elektrike të Stacionit Publik (EV)

Karakteristikat e Programit EV RTP të Stacionit Publik

Ngarko Profile Objektiv	Një aktivitet i përgjigjes ndaj kërkesës me të cilin modifikohet kostoja e karikimit të automjeteve elektrike për të zhvendosur realitetet e pikut të çmimit te konsumatorët.
Drejtuesit kryesorë	Çmimi i energjisë elektrike është i ndryshueshëm gjatë një dite. Ky program synon të përputhë në mënyrë më efikase çmimin e tarifimit me koston e energjisë elektrike.
Përshkrimi i programit	Karikuesit publik mund të ekzistojnë në vendet e punës, në parkingje publike dhe në dyqanet me pakicë. Ky program transmeton çmimet në kohë reale tek karikuesit e mundshëm para se të lidhen, në mënyrë që ata të marrin një vendim të informuar nëse do të karikojnë ose jo makinën e tyre.
Nxitja e Klientit	Karikim më pak i shtrenjtë gjatë periudhave jashtë pikut.
Dizajni i Vlerësimit	Çmimet mund të ndryshojnëurly, por sapo një klient të zgjedhë të lidhë makinën e tij, tarifa caktohet për kohëzgjatjen e tarifimit.
Klienti i synuar	Kushdo me një EV që duhet të karikojë ndërsa është larg shtëpisë.
Ngarkesat e synuara	Karikuesit EV EV
Kusht paraprak	Karikuesit EV duhet të jenë të lidhur në internet dhe të çertifikuar OpenADR2.0b, ose të lidhur me një portë OpenADR2.0b VEN.
Korniza kohore e programit	Gjithë vitin
Kufizimet e ngjarjes	Asnjë
Ditët e ngjarjeve	Çdo ditë, ose vetëm gjatë ditëve të javës
Kohëzgjatja e ngjarjes	1 orë ose më gjatë
Njoftimi	Konsumatori njoftohet për normën mbizotëruese kur zgjedh të fusë makinën e tij.
Sjellja e Zgjedhur	Klientët mund të zgjedhin zgjedhjet duke vendosur të mos tarifojnë.
Certifikimi Ngjarjet

Karakteristikat OpenADR për Programet RTP të Stacionit Publik EV

Sinjalet e ngjarjes	ELECTRICITY_PRICE sinjale me çmime. Shih Aneksin A për shembullamples.
Përgjigjet e zgjedhura	Gjithmonë vendosni nga VEN
Përshkrimi i ngjarjes	Ngjarjet duhet të jenë të afërta dhe të përmbajnë një interval.
Periudha Aktive e Ngjarjes	Duhet të përdoret së paku 1 orë njoftim, megjithatë shërbimet mund të zgjedhin të përdorin njoftimin një ditë përpara.
Vijat bazë	N/A
Shënjestrimi i Ngjarjes	Nuk kërkohet shënjestrim i avancuar, por shënjestrimi mund të përdoret për të dërguar çmime në transformatorë, furnizues ose zona gjeografike specifike.
Shërbimet e Raportimit	Nuk ka nevojë për raportim, por mund të përdoret nëse dëshironi. Referojuni Aneksit B për shembullampraporte nga pilotët e shërbimeve që mund të jenë të zbatueshme për këtë lloj programi.
Shërbimet e zgjedhura	Shërbimet e zgjedhura nuk do të ishin të rëndësishme për këtë lloj programi.
Shërbimet e Regjistrimit	Një shitës i stacionit të karikimit do t'i furnizonte pajisjet e tyre me një ndërmarrje VTN.

Programi DR i Burimeve të Shpërndara të Energjisë (DER)

Përshkrimi i mëposhtëm i programit është hipotetik dhe bazohet në një letër kërkimore (referencë në letrën e Rish) që përshkruan se si klientët e shërbimeve mund të përdorin burimet e magazinimit DER për të marrë pjesë në programet DR siç janë programet e çmimeve në kohë reale (RTP).

Karakteristikat e Programit të Burimeve të Shpërndara të Energjisë (DER)

Ngarko Profile Objektiv	Një aktivitet i përgjigjes ndaj kërkesës i përdorur për të zbutur integrimin e burimeve të energjisë të shpërndara në rrjetin inteligjent.
Drejtuesit kryesorë	-Zvogëluar shpenzimet kapitale dhe ulur kostot e energjisë
Përshkrimi i programit	Klientët me burime DER që mund të mbledhin energji dhe ta ruajnë atë mund të minimizojnë koston e blerjes së energjisë elektrike nga rrjeti gjatë periudhave me çmime të larta duke përdorur fillimisht burimet e ruajtura të energjisë, pasuar nga zbatimi i strategjive të zvogëlimit të ngarkesës.
Nxitja e Klientit	Aftësia për të kontrolluar kostot gjatë kohës së çmimeve të larta të energjisë elektrike duke përdorur energjinë e depozituar të gjeneruar përmes PV ose mjeteve të tjera dhe duke zbatuar strategjitë e zvogëlimit të ngarkesës
Dizajni i Vlerësimit	Normat e elektricitetit ndryshojnë me çmimet e tregut me shumicë ose një tarifë që ndryshon në varësi të kohës së ditës, sezonit ose temperaturës
Klienti i synuar	Klientët me burime të ruajtjes së energjisë
Ngarkesat e synuara	Çdo
Kusht paraprak	Burimet e ruajtjes së energjisë
Korniza kohore e programit	Në çdo kohë
Kufizimet e ngjarjes	Asnjë
Ditët e ngjarjeve	Çdo ditë
Kohëzgjatja e ngjarjes	24 orë
Njoftimi	Dita përpara
Sjellja e Zgjedhur	N / A - Një program më i mirë i përpjekjeve
Certifikimi Ngjarjet	Asnjë

Karakteristikat OpenADR për Burimet e Shpërndara të Energjisë (DER)

Sinjalet e ngjarjes	ELECTRICITY_PRICE sinjalizon me 24 intervale njëorëshe çmimesh gjatë një periudhe 24 ore. Ky sinjal do të kërkojë B profile. Ky program nuk i jep mundësi sinjalizimit të thjeshtë për një profesionistfile VEN. Shih Aneksin A për shembullamples.
Përgjigjet e zgjedhura	-VTN që dërgojnë ngjarje duhet të vendosë elementin oadrResponseRequired në "kurrë", duke parandaluar që VEN të përgjigjen.
Përshkrimi i ngjarjes	-Ngjarja përparësia duhet të vendoset në 1 përveç nëse rregullat e programit ose konfigurimi i VTN specifikojnë ndryshe
Periudha Aktive e Ngjarjes	24 orë me interval 1 orë me njoftimin ditë përpara
Vijat bazë	N/A
Shënjestrimi i Ngjarjes	Asnjë shënjestrim i avancuar nuk kërkonte tjetër përveç venID
Shërbimet e Raportimit	Nuk ka nevojë për raportim Referojuni Aneksit B për shembullampraporte nga pilotët e shërbimeve që mund të jenë të zbatueshme për këtë lloj programi.
Shërbimet e zgjedhura	I pa perdorur
Shërbimet e Regjistrimit	Intervalet e votimit e kërkuar nga VTN për programe tipike ditore përpara nuk kërkohet të jenë më të shpeshta se një herë në orë. Sidoqoftë, përdorimi i sondazhit për zbulimin e rrahjeve të zemrës mund të kërkojë sondazh më të shpeshtë siç do programet e termostatit të banimit me kohë njoftimi dukshëm më të shkurtër.

- Sampshabllonet e të dhënave dhe ngarkesës

Tabelat e mëposhtme dhe ngarkesa e XML-sëamples do t'u sigurojë zbatuesve ish të prekshëmampse si duhet të zbatohen shabllonet DR në këtë dokument. Prefikset e mëposhtme të hapësirës së emrave përdoren në ngarkesën e dobishme, p.shamples:

• 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: lumë”
• xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0
• xmlns: pushtet = "http://docs.oasis-open.org/ns/emix/2011/06/power"

Programi kritik i çmimeve të pikut (CPP)

Skenari 1 i CPP - Rasti i përdorimit të thjeshtë, A ose B Profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 4 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 1
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: N / A
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 1
    • Synimi i sinjalit: N / A
  • Synimi (et) e ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

CPP Skenari 2 – Rasti tipik i përdorimit, B profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Koha e fillimit: 1 pasdite
  • Kohëzgjatja: 4 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 2
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0, 1, 2, 3
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 1 ose 2
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: ELECTRICITY_PRICE
    • Lloji i sinjalit: çmimi
    • Njësitë: USD për Kwh
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 0.10 dollarë deri 1.00 dollarë
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Skenari 3 i CPP - Rasti i Përdorimit Kompleks

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Ora e fillimit: 2:XNUMX
  • Kohëzgjatja: 6 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 2
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0,1, 2, 3)
    • Numri i intervaleve 3
    • Kohëzgjatja e intervalit: 1 orë, 4 orë, 1 orë
    • Vlera (et) tipike të intervalit: 1, 2, 1 (përkatësisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: ELECTRICITY_PRICE
    • Lloji i sinjalit: çmimi
    • Njësitë: USD për Kwh
    • Numri i intervaleve 3
    • Kohëzgjatja e intervalit: 1 orë, 4 orë, 1 orë
    • Vlera (et) tipike të intervalit: 0.50 $, 0.75 $, 0.50 $ (respektivisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: Resource_1, Resource_2, Resource_3
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

CPP Sample Event Payload – Typical B Profile Rasti i përdorimit

OadrDisReq091214_043740_513

TH_VTN

Ngjarja091214_043741_028_0

0

http: // MarketContext1

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

larg

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

PT4H

PT24H

PT4H

0

2.0

E thjeshtë

niveli

SIG_01

0.0

PT4H

0

0.75

ELECTRICITY_PRICE

çmimi

SIG_02

monedhaPerKWh

USD

asnje

0.0

venID_1234

gjithmone

Programi i Ofertimit të Kapaciteteve (CBP)

Skenari 1 CBP - Rasti i përdorimit të thjeshtë, A ose B Profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 4 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 1
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: N / A
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 1
    • Synimi i sinjalit: N / A
  • Synimi (et) e ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Skenari 2 i BKP - Rasti tipik i përdorimit, B profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Koha e fillimit: 1 pasdite
  • Kohëzgjatja: 4 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 2
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0,1, 2, 3
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 1 ose 2
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: BID_LOAD
    • Lloji i sinjalit: pika e caktuar
    • Njësitë: fuqiReal
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 20kW deri 100kW
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Skenari 3 i CBP - Rasti i Përdorimit Kompleks

• Ngjarje
  • Njoftimi: Dita e ngjarjes (sa orë?)
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 6 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 3
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0,1, 2, 3)
    • Numri i intervaleve: 2
    • Kohëzgjatja e intervalit: 3 orë, 3 orë
    • Vlera (et) tipike të intervalit: 1, 2 (përkatësisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: BID_LOAD
    • Lloji i sinjalit: pika e caktuar
    • Njësitë: fuqiReal
    • Numri i intervaleve 2
    • Kohëzgjatja e intervalit: 3 orë, 3 orë
    • Vlera tipike e intervalit: 40kW, 80kW (respektivisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: BID_PRICE
    • Lloji i sinjalit: çmimi
    • Njësitë: currencyPerKW
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 6 orë
    • Vlera (et) tipike të intervalit: 3.10 dollarë
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: Resource_1, Resource_2, Resource_3
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raporti (t)
  • Emri i raportit: TELEMETRY_USAGE
  • Lloji i raportit: përdorimi
  • Njësitë: fuqiReal
  • Lloji i leximit: Lexoni drejtpërdrejt
  • Raportoni Frekuencën: çdo 1 orë

CBP Sample Event Payload – Typical B Profile Rasti i përdorimit

OadrDisReq091214_043740_513

TH_VTN

Ngjarja091214_043741_028_0

0

http: // MarketContext1

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

larg

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

PT4H

PT24H

PT4H

0

2.0

E thjeshtë

niveli

SIG_01

0.0

PT4H

0

80.0

BID_LOAD

pikë e caktuar

SIG_02

RealPower

W

k

60.0

<power:voltage>220.0tage>

e vërtetë

0.0

venID_1234

gjithmone

Programi i Termostatit Rezidencial

Skenari 1 i termostatit rezidencial – Rasti i përdorimit të thjeshtë, A ose B Profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 4 orë
  • Randomizimi: 10 minuta
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 1
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: N / A
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 1
    • Synimi i sinjalit: N / A
  • Synimi (et) e ngjarjes: Resource_1
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Skenari 2 i termostatit rezidencial – Rasti tipik i përdorimit, B profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Koha e fillimit: 1 pasdite
  • Kohëzgjatja: 4 orë
  • Randomizimi: 10 minuta
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 2
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0,1, 2, 3
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 1 ose 2
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: LOAD_CONTROL
    • Lloji i sinjalit: x-loadControlLevelOffset
    • Njësitë: Temperatura
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 4 orë
    • Vlera (et) tipike të intervalit: 2 deri në 6 gradë Fahrenheit
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: Burimi_1, Burimi_2
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: zgjedhja, dalja e mundshme (oadrCreateOpt)
• Raportet
  • Asnjë

Skenari i Termostatit Rezidencial 3 - Rasti i Përdorimit Kompleks

• Ngjarje
  • Njoftimi: Dita e ngjarjes
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 6 orë
  • Randomizimi: 10 minuta
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 3
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0,1, 2, 3)
    • Numri i intervaleve: 2
    • Kohëzgjatja e intervalit: 3 orë, 3 orë
    • Vlera (et) tipike të intervalit: 1, 2 (përkatësisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: BID_LOAD
    • Lloji i sinjalit: x-loadControl Kapaciteti
    • Njësitë: Asnjë
    • Numri i intervaleve 2
    • Kohëzgjatja e intervalit: 3 orë, 3 orë
    • Vlera (et) tipike të intervalit: 0.9, 0.8 (përkatësisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: Resource_1, Resource_2, Resource_3
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: zgjedhja, dalja e mundshme (oadrCreateOpt)
• Raporti (t)
  • Asnjë

Termostati i banimit Sample Event Payload – Typical B Profile Rasti i përdorimit

OadrDisReq091214_043740_513

TH_VTN

Ngjarja091214_043741_028_0

0

http: // MarketContext1

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

larg

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

PT4H

PT10M

PT24H

PT4H

0

2.0

E thjeshtë

niveli

SIG_01

0.0

PT4H

0

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

temperatura

fahrenheit

asnje

0.0

burimi_1

burimi_2

gjithmone

Shpërndarja e shpejtë e DR

Skenari i shpejtë DR 1 – Rasti i përdorimit të thjeshtë, A ose B Profile

• Ngjarje
  • Njoftimi: 10 minuta
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 0 (Fundi i Hapur)
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 1
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: N / A
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 0 (Përfundoi e Hapur)
    • Vlera (et) tipike të intervalit: 1
    • Synimi i sinjalit: N / A
  • Synimi (et) e ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Skenari DR i shpejtë 2 – Rasti tipik i përdorimit, B profile

• Ngjarje
  • Njoftimi: 10 minuta
  • Koha e fillimit: 1 pasdite
  • Kohëzgjatja: 30 minuta
  • Randomizimi: Asnjë
  • Ramp Lart: 5 minuta
  • Rikuperimi: 5 minuta
  • Numri i sinjaleve: 2
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0,1, 2, 3
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 30 minuta
    • Vlera (et) tipike të intervalit: 1 ose 2
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: LOAD_DISPATCH
    • Lloji i sinjalit: delta
    • Njësitë: fuqiReal
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 30 minuta
    • Vlera (et) tipike të intervalit: 500 kW deri në 2mW
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Emri i raportit: TELEMETRY_USAGE
  • Lloji i raportit: përdorimi
  • Njësitë: fuqiReal
  • Lloji i leximit: Lexoni drejtpërdrejt
  • Raportoni Frekuencën: çdo 1 minutë

Skenari i shpejtë DR - Rasti i përdorimit kompleks

• Ngjarje
  • Njoftimi: 10 minuta
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 30 minuta
  • Randomizimi: Asnjë
  • Ramp Lart: 5 minuta
  • Rikuperimi: 5 minuta
  • Numri i sinjaleve: 2
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0,1, 2, 3)
    • Numri i intervaleve: 2
    • Kohëzgjatja e intervalit: 15 minuta, 15 minuta
    • Vlera (et) tipike të intervalit: 1, 2 (përkatësisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: LOAD_DISPATCH
    • Lloji i sinjalit: pika e caktuar
    • Njësitë: fuqiReal
    • Numri i intervaleve 2
    • Kohëzgjatja e intervalit: 15 minuta, 15 minuta
    • Vlera tipike e intervalit: 800kW, 900kW (respektivisht për çdo interval)
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: Burimi_1
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raporti (t)
  • Emri i raportit: TELEMETRY_USAGE
  • Lloji i raportit: përdorimi
  • Njësitë: powerReal dhe voltage
  • Lloji i leximit: Lexoni drejtpërdrejt
  • Raportoni Frekuencën: çdo 5 sekonda

I shpejtë DR Sample Event Payload – Typical B Profile Rasti i përdorimit

OadrDisReq091214_043740_513

TH_VTN

Ngjarja091214_043741_028_0

0

http: // MarketContext1

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

larg

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

PT10M

PT10M

<ei:x-eiRampLart>

PT5M

</ei:x-eiRampLart>

PT5M

PT10M

0

2.0

E thjeshtë

niveli

SIG_01

0.0

PT10M

0

500.0

LOAD_DISPATCH

delta

SIG_02

RealPower

W

k

60.0

<power:voltage>220.0tage>

e vërtetë

0.0

venID_1234

gjithmone

I shpejtë DR SampRaportoni ngarkesën e meta të dhënave – Tipical B Profile Rasti i përdorimit

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

burimi1

përdorimi

RealEnergy

Wh

k

Lexoni drejtpërdrejt

http: // MarketContext1

<oadr:oadrSamplingRate>

PT1M

PT10M

i rremë

</oadr:oadrSamplingRate>

0

RaportoSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

I shpejtë DR Sample Raporto Kërkesë për ngarkesën – tipike B Profile Rasti i përdorimit

ReportReqID130615_192625_230

ReportReqID130615_192625_730

RaportoSpecID120615_122512_481_2

PT1M

PT1M

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

PT10M

rID120615_122512_981_0

x-joE zbatueshme

VEN130615_192312_582

I shpejtë DR SampRaportoni ngarkesën e të dhënave – Tipical B Profile Rasti i përdorimit

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

Cilësia e mirë - Jo specifike

RP_54321

ReportReqID130615_192625_730

RaportoSpecID120615_122512_481_2

TELEMETRIA_PAGERDORIMI

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

VEN130615_192312_582

Programi për kohën e përdorimit të automjeteve elektrike rezidenciale (EV)

Vini re se ndërsa programi komunikon nivelet e normave në një formë mjaft të strukturuar tregohen vetëm rastet e përdorimit të thjeshtë dhe tipik

Rezidenciale EV Skenari 1 – Rasti i përdorimit të thjeshtë, A ose B Profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Ora e fillimit: 1:XNUMX
  • Kohëzgjatja: 24 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 1
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: N / A
    • Numri i intervaleve; ndryshime të barabarta të nivelit TOU në 24 orë (2 - 6)
    • Kohëzgjatja (et) e intervalit: Korniza kohore aktive e nivelit TOU (dmth. 6 orë)
    • Vlera (et) tipike të intervalit: 0 - 4 të shënuara në TOU Tiers
    • Synimi i sinjalit: N / A
  • Synimi (et) e ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Rezidenciale EV Skenari 2 – Rasti tipik i përdorimit, B profile

• Ngjarje
  • Njoftimi: Një ditë para ngjarjes
  • Koha e fillimit: mesnatë
  • Kohëzgjatja: 24 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 2
  • Emri i sinjalit: I thjeshtë
    • Lloji i sinjalit: niveli
    • Njësitë: Niveli 0, 1, 2, 3
    • Numri i intervaleve: ndryshimi i barabartë i TOU i nivelit në 24 orë (2 - 6)
    • Kohëzgjatja (et) e intervalit: Korniza kohore aktive e nivelit TOU (dmth. 6 orë)
    • Vlera (a) intervale tipike: 0 - 4 të shënuara në TOU Tiers (0 - Niveli më i lirë)
    • Synimi i sinjalit: Asnjë
  • Emri i sinjalit: ELECTRICITY_PRICE
    • Lloji i sinjalit: çmimi
    • Njësitë: USD për Kwh
    • Numri i intervaleve: Ndryshimet e barabarta të TOU Tier në 24 orë (2 - 6)
    • Kohëzgjatja (et) e intervalit: Korniza kohore aktive e nivelit TOU (dmth. 6 orë)
    • Vlera (et) tipike të intervalit: 0.10 dollarë deri 1.00 dollarë (niveli aktual i nivelit)
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Rezidenciale EV Sample Event Payload – Typical B Profile Rasti i përdorimit

OadrDisReq091214_043740_513

TH_VTN

Ngjarja091214_043741_028_0

0

http: // MarketContext1

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

larg

<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

E thjeshtë

niveli

SIG_01

0.0

PT5H

0

0.35

PT7H

1

0.55

PT7H

2

0.75

PT5H

3

0.55

ELECTRICITY_PRICE

çmimi

SIG_02

monedhaPerKWh

USD

asnje

0.0

venID_1234

gjithmone

Programi i Çmimeve në kohë Reale të Automjeteve Elektrike të Stacionit Publik (EV)

Vini re se duke qenë se ky është një program çmimi në kohë reale, në të vërtetë nuk ka asnjë dallim midis një rasti të thjeshtë, tipik dhe kompleks përdorimi. Prandaj sampTë dhënat do të shfaqen vetëm për një rast përdorimi tipik.

Stacioni Publik EV Skenari 1 – Rasti tipik i përdorimit, B profile

• Ngjarje
  • Njoftimi: 1 orë përpara
  • Koha e fillimit: 1 pasdite
  • Kohëzgjatja: 1 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 1
  • Emri i sinjalit: ELECTRICITY_PRICE
    • Lloji i sinjalit: çmimi
    • Njësitë: USD për Kwh
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 1 orë
    • Vlera (et) tipike të intervalit: 0.10 dollarë deri 1.00 dollarë
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: gjithmonë
  • Përgjigja e pritur e VEN: optIn
• Raportet
  • Asnjë

Stacioni Publik EV Sample Event Payload – Typical B Profile Rasti i përdorimit

OadrDisReq091214_043740_513

TH_VTN

Ngjarja091214_043741_028_0

0

http: // MarketContext1

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

larg

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

PT1H

PT1H

PT1H

0

0.75

ELECTRICITY_PRICE

çmimi

SIG_01

monedhaPerKWh

USD

asnje

0.0

venID_1234

gjithmone

Programi DR i Burimeve të Shpërndara të Energjisë (DER)

Vini re se duke qenë se ky është një program çmimi në kohë reale, në të vërtetë nuk ka asnjë dallim midis një rasti të thjeshtë, tipik dhe kompleks përdorimi. Prandaj sampTë dhënat do të shfaqen vetëm për një rast përdorimi tipik.

Stacioni Publik EV Skenari 1 – Rasti tipik i përdorimit, B profile

• Ngjarje
  • Njoftimi: Një ditë përpara
  • Koha e fillimit: mesnatë
  • Kohëzgjatja: 24 orë
  • Randomizimi: Asnjë
  • Ramp Lart: Asnjë
  • Rikuperimi: Asnjë
  • Numri i sinjaleve: 24
  • Emri i sinjalit: ELECTRICITY_PRICE
    • Lloji i sinjalit: çmimi
    • Njësitë: USD për Kwh
    • Numri i intervaleve 1
    • Kohëzgjatja e intervalit: 1 orë
    • Vlera (et) tipike të intervalit: 0.10 dollarë deri 1.00 dollarë
    • Synimi i sinjalit: Asnjë
  • Synimet e Ngjarjes: venID_1234
  • Prioriteti: 1
  • Kërkohet përgjigja e VEN: asnjëherë
  • VEN Përgjigja e Pritshme: n / a
• Raportet
  • Asnjë

Stacioni Publik EV Sample Event Payload – Typical B Profile Rasti i përdorimit

OadrDisReq091214_043740_513

TH_VTN

Ngjarja091214_043741_028_0

0

http: // MarketContext1

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

larg

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

PT24H

PT24H

PT1H

0

0.75

PT1H

1

0.80

ELECTRICITY_PRICE

çmimi

SIG_01

monedhaPerKWh

USD

asnje

0.0

venID_1234

asnjëherë

– P.shampRaportet nga Pilotët e Utility

Anëtarët e Aleancës OpenADR ofruan B Pro-në e mëposhtmefile oadrUpdateRaporto ngarkesën sampmë pak nga programet pilot të shërbimeve ku ishin vendosur VEN-të e tyre. Shënimet e mëposhtme shoqëruan tre ngarkesat samptë ofruara:

Objektivi i Ngarkesës së Termostatit:

• Duhet të dini statusin e termostatit (temp, pikat e vendosura, tifozët dhe gjendjet e modalitetit)
• Nëse vendoset, nëse klienti i ka ndryshuar ose jo cilësimet e termostatit (mesazhet e anashkalimit manual)

M&V për Objektivin e Ngarkesës së Rimbushjeve:

• Statusi i burimeve dhe mbivendosja manuale në rastin e zgjedhjes
• Të dhëna intervale nga një Kontrollues Pulsi KYZ ose Monitor i Energjisë për energji totale në KWH dhe kërkesë të menjëhershme në KW

Objektivi i ngarkesës së të dhënave të matësit inteligjent / intervalit AMI:

• Intervali i leximit të njehsorit AMI është rreth 15 minuta deri në 1 orë. Edhe pse i dobishëm, jo ​​mjaft i grimcuar për vlerësimet e faturimit në kohë reale
• Energjia totale në KWH, energjia delta në KWH, kërkesa e menjëhershme në KW

Prefikset e mëposhtme të hapësirës së emrave përdoren në ngarkesën e dobishme, p.shamples:

• 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: lumë”
• xmlns: xcal = ”urn: ietf: params: xml: ns: icalendar-2.0
• xmlns: pushtet = "http://docs.oasis-open.org/ns/emix/2011/06/power"

Raporti i termostatit të ngarkesës 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

Statusi

e vërtetë

i rremë

0

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Koha aktuale

77.000000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Vendosja e Temperaturës së Nxehtësisë

64.000000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Vendosja e kohes se ftohte

86.000000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Vendosja e modalitetit HVAC

3

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Modaliteti aktual HVAC

0.000000

Pa cilësi - pa vlerë

Vendosja e modalitetit të tifozit

2

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Modaliteti aktual i mbajtjes

2

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Modaliteti aktual i larguar

0

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

Lagështia aktuale

0.000000

Pa cilësi - pa vlerë

RP21

REQ: RReq: 1395368583267

0013A20040980FAE

TELEMETRI_STATUS

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

VEN.ID:1395090780716

M&Vfor Rebatet Raporto ngarkesën 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

Statusi

e vërtetë

i rremë

Cilësia e mirë - Jo specifike

Numërimi i pulsit

34750.000000

Cilësia e mirë - Jo specifike

Energjia

33985.500000

Cilësia e mirë - Jo specifike

Fuqia

1.26

Cilësia e mirë - Jo specifike

RP15

REQ: RReq: 10453335019195698

0000000000522613 60

TELEMETRIA_PAGERDORIMI

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

VEN.ID:1439831430142

Matësi inteligjent/Raporti i të dhënave të intervalit AMI të ngarkesës 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

çastitKërkesa

6.167000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

intervalDataDelivered

0.051000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

currSumDelivered

12172.052000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

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

PT15S

çastitKërkesa

6.114000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

intervalDataDelivered

0.051000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

currSumDelivered

12172.052000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

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

PT15S

çastitKërkesa

6.113000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

intervalDataDelivered

0.051000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

currSumDelivered

12172.142000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

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

PT15S

çastitKërkesa

6.112000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

intervalDataDelivered

0.051000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

currSumDelivered

12172.142000

Nuk ka vlerë të re - Vlera e mëparshme e përdorur

RP4101

<ei:reportRequestID>d5f88bf0-1a8d-0132-eab3-0a5317f1edaa</ei:reportRequestID>

<ei:reportSpecifierID>00:21:b9:00:f2:a9</ei:reportSpecifierID>

TELEMETRIA_PAGERDORIMI

<ei:createdDateTime>2014-09-10T06:27:53Z</ei:createdDateTime>

<ei:venID>2b2159c0-19cd-0132-eaa3-0a5317f1edaa</ei:venID>

- Shërbimet

Open ADR mbështet shërbimet e mëposhtme:

• Shërbimi EiEvent – Përdoret nga VTN-të për të dërguar ngjarje të përgjigjes së kërkesës tek VEN-të dhe përdoret nga VEN-të për të treguar nëse burimet do të marrin pjesë në ngjarje. I vetmi shërbim i mbështetur nga A profile është EiEvent
• Shërbimi EiReport - Përdoret nga VEN dhe VTN për të shkëmbyer raporte historike, telemetrike dhe parashikuese
• Shërbimi EiOpt - Përdoret nga VEN për të komunikuar me orarin e përkohshëm të disponueshmërisë VTN ose për të kualifikuar burimet që marrin pjesë në një ngjarje
• Shërbimi i Partisë EiRegisterParty - Iniciuar nga VEN, dhe përdorur nga të dy VEN dhe VTN për të shkëmbyer informacionin e kërkuar për të siguruar shkëmbimin ndërveprues të ngarkesave
• Shërbimi OadrPoll - Përdoret nga VENs për të sonduar VTN për ngarkesat nga ndonjë prej shërbimeve të tjera

A dhe B profile operacionet e shërbimit përcaktohen nga elementi rrënjësor i secilës ngarkesë, duke përjashtuar mbështjellësit oadrPayload dhe oadrSignedObject të përdorura në të gjitha B profile ngarkesat e dobishme.

- Përkufizimet e ngarkesës

Ngarkesat EiEvent

• oadrKërkesëEvent – Përdoret në një model të shkëmbimit tërheqës nga VEN për të tërhequr të gjitha ngjarjet përkatëse nga VTN. Përdoret si mekanizmi kryesor i votimit për A profile VEN, por përdoren vetëm në B VEN për sinkronizim me VTN.
• oadrDistributeEvent - Përdoret nga VTN për të dhënë ngjarje të përgjigjes ndaj kërkesës në VEN
• oadrNgjarje e Krijuar - Përdoret nga VEN për të komunikuar nëse ka ndërmend të marrë pjesë në një ngjarje duke zgjedhur ose jashtë
• oadrPërgjigje - Përdoret nga VTN për të pranuar marrjen e optIn ose optOut nga VEN

Ngarkesat EiReport

Vini re se të dy VEN-të dhe VTN-të janë të afta të jenë edhe prodhues raporti edhe kërkues raportesh, kështu që të gjitha ngarkesat më poshtë mund të iniciohen nga secila palë.

• oadrRegjistroRaport - Përdoren për të publikuar aftësitë e tyre raportuese në një raport të meta të dhënave
• oadrRegisteredRaporti -Njohni pranimin e oadrRegisterReport, në mënyrë opsionale kërkoni një nga raportet e ofruara
• oadrCreateReport - Përdoret për të kërkuar një raport që është ofruar më parë nga VEN ose VTN
• raporti i krijuar - Pranoni pranimin e një kërkese raporti
• oadrUpdateReport -Dërgoni një raport të kërkuar që përmban të dhëna intervali
• raporti i azhurnuar - Pranoni pranimin e një raporti të dorëzuar
• oadrAnuloRaport - Anuloni një raport periodik të kërkuar më parë
• raporti i anuluar - Pranoni anulimin e raportit periodik
• oadrPërgjigje - Përdoret si një përgjigje e mbajtësit të vendit në disa modele shkëmbimi tërheqës kur një përgjigje e shtresës së aplikacionit dorëzohet në një kërkesë të shtresës së transportit.

Ngarkesat EiOpt

• oadrCreateOpt - Përdoret për dy qëllime dukshëm të ndryshme
  • Që VEN të komunikojë një orar të përkohshëm disponueshmërie me VTN në lidhje me aftësinë e tij për të marrë pjesë në ngjarjet e DR
  • Që VEN të kualifikojë burimet pjesëmarrëse në një ngjarje
• oadrKrijuarOpt - Pranoni marrjen e ngarkesës së oadrCreateOpt
• oadrCancelOpt -Anulloni një orar të përkohshëm të disponueshmërisë
• oadrCancledOpt - Pranoni anulimin e raportit të përkohshëm të disponueshmërisë

 

Ngarkesat EiRegisterParty

• oadrQueryRegjistrimi - Një mënyrë që VEN të kërkojë informacionin e regjistrimit të VTN pa regjistruar në të vërtetë.
• oadrCreatePartyRegjistrimi - Një kërkesë nga VEN për VTN për t'u regjistruar. Përmban informacion në lidhje me aftësitë e VENs.
• Regjistrimi i partisë së krijuar - Përgjigje ose për një regjistrim të pyetjeve të oadrQuery ose për një regjistrim oadrCreateParty. Përmban aftësitë VTN dhe informacionin e regjistrimit të nevojshëm për ndërveprimin e VEN
• oadrCancelPartyRegjistrimi - Përdoret ose nga VEN ose VTN për të anuluar regjistrimin
• Regjistrimi i anuluarPartia - Përgjigjja ndaj një regjistrimi të anulluarPancës së Partisë. Pranon marrjen e anulimit të regjistrimit
• oadrKërkesëRregjistrimi - Kjo ngarkesë përdoret nga një VTN në një model shkëmbimi tërheqës për të sinjalizuar VEN për të rifilluar sekuencën e regjistrimit
• oadrPërgjigje - Përdoret si një përgjigje e mbajtësit të vendit në disa modele shkëmbimi tërheqës kur një përgjigje e shtresës së aplikacionit dorëzohet në një kërkesë të shtresës së transportit.

Ngarkesat OadrPoll

• oadrPoll – Një mekanizëm i përgjithshëm polemizimi për B profile që kthen ngarkesën për çdo shërbim tjetër që është i ri ose i përditësuar.
• oadrPërgjigje - Përdoret për të treguar se nuk ka ngarkesa të reja ose të azhurnuara të disponueshme

- Fjalori i Elementeve të Ngarkesës së Skemës

Më poshtë është një listë alfabetike e elementeve të skemës të përdorura në ngarkesat e OpenADR 2.0. Narrativa përshkruan përdorimin e tyre pasi ka të bëjë me OpenADR dhe përdorimin e tyre në ngarkesat e ngarkesës. Kur një përkufizim i elementit ndryshon bazuar në ngarkesën në të cilën përmbahet ose kontekstin e tij të përdorimit, kjo do të shënohet në rrëfim. Përkufizimet e ngarkesës rrënjësore janë përjashtuar siç përcaktohen në Shtojcën C.

• ac - Një vlerë Boolean që tregon nëse produkti i energjisë është rrymë alternative
• saktësia - Numri është në të njëjtën njësi me ndryshoren e ngarkesës për një Interval. Kur është i pranishëm me Besim, tregon ndryshueshmërinë e mundshme të parashikimit. Kur është i pranishëm me ReadingType, tregon gabimin e mundshëm të Leximit.
• grumbulluar Pnode - Një nyje e përmbledhur e çmimeve është një lloj i specializuar i nyjes së çmimit që përdoret për të modeluar artikuj të tillë si Zona e Sistemit, Zona e Çmimeve të Paracaktuara, Zona e Çmimeve të Zakonshme, Zona e Kontrollit, Gjenerimi i Përmbledhur, Ngarkesa Pjesëmarrëse e Grumbulluar, Ngarkesa e Përbashkët Jo-Pjesëmarrëse, Qendra e Tregtisë, Zona DCA
• në dispozicion - Një objekt që përmban një datë-kohë dhe kohëzgjatje për një orar të disponueshmërisë EiOpt
• baselineID - ID unike për një bazë specifike
• Emri bazë - Emri përshkrues për vijën bazë
• komponentët –
• besimin - Një probabilitet statistikor që një pikë e të dhënave e raportuar të jetë e saktë
• krijuarDateTime - DataTime është krijuar ngarkesa e ngarkesës
• valutë –
• monedha PerKW –
• monedhaPerKWh –
• monedhaPerThm –
• aktuale –
• vlera e tanishme - Vlera e ngarkesësFloat të intervalit të ngjarjes që ekzekutohet aktualisht.
• njësia e personalizuar - Përdoret për të përcaktuar një njësi matëse të personalizuar për raportet e personalizuara
• datë-kohë –
• dtstart - Koha e fillimit për aktivitetin, të dhënat ose ndryshimin e gjendjes
• kohëzgjatja - Një periudhë kohore për një ngjarje, raportim ose interval kohor të disponueshmërisë
• kohëzgjatja - Kohëzgjatja e aktivitetit, të dhënave ose gjendjes
• Periudha eiActive - Afatet kohore të rëndësishme për ngjarjen e përgjithshme
• eiCreatedEvent - Përgjigjuni një ngjarjeje DR me optIn ose optOut
• eiEvent -Një objekt që përmban të gjithë informacionin për një ngjarje të vetme
• eiEventBaseline - B profile
• eiEventSignal - Një objekt që përmban të gjithë informacionin për një sinjal të vetëm në një ngjarje
• eiEventSignals - Të dhënat e intervalit për një ose më shumë sinjale të ngjarjeve dhe / ose linjat bazë
• eiMarketContext - Një URI identifikon në mënyrë unike një program të përgjigjes ndaj kërkesës
• eiReportID - ID e referencës për një raport
• eiRequestEvent - Kërkoni ngjarje nga një VTN në mënyrën tërheqëse
• eiResponse - Tregoni nëse ngarkesa e pranuar është e pranueshme
• eiTarget - Identifikon burimet e shoqëruara me ndërfaqen logjike VEN. Për ngjarjet, vlerat e specifikuara janë shënjestra e ngjarjes
• fundi i pajisjes - EndDeviceAssets janë pajisja fizike ose pajisjet të cilat mund të jenë njehsorë ose lloje të tjerë të pajisjeve që mund të jenë me interes
• energjia e dukshme - Energjia e dukshme, e matur në volt-amppak orë (VAh)
• energjiaSytem –
• energji Reaktive - Energjia Reaktive, volt-amporët reaktive (VARh)
• energji e vërtetë - Energji e vërtetë, orë Watt (Wh)
• përshkruesi i ngjarjes - Informacion rreth ngjarjes
• eventID - Një vlerë ID që identifikon një rast specifik të ngjarjes DR.
• ngjarjePërgjigje - Një objekt që përmban përgjigjen e VEN-ve ndaj një kërkese për të marrë pjesë në një ngjarje
• ngjarjePërgjigjet - përgjigjet optIn ose optOut për ngjarjet e marra
• Statusi i ngjarjes - Statusi aktual i një ngjarjeje (larg, afër, aktive, etj)
• TipariKoleksioni / vendndodhja / Poligoni / i jashtmi / LinearRing
• frekuenca –
• granularitet – Ky është intervali kohor ndërmjet samptë dhëna të udhëhequra në një kërkesë raporti.
• grupID -Ky lloj i synimit përdoret për ngjarje, raporte dhe orare të zgjedhura. Vlera zakonisht caktohet nga ndërmarrja gjatë regjistrimit në një program DR
• Emri i grupit - Ky lloj synimi përdoret për ngjarjet, raportet dhe oraret e zgjedhjes. Vlera zakonisht caktohet nga ndërmarrja gjatë regjistrimit në një program DR
• herc –
• intervali - Një objekt që përmban kohën e të dhënave dhe / ose kohëzgjatjen, dhe një vlerë të veprueshme në rastin e një ngjarjeje ose të dhëne në rastin e një raporti
• intervale - Një ose më shumë intervale kohore gjatë të cilave ngjarja DR është aktive ose të dhënat e raportit janë të disponueshme
• Përshkrimi i artikullit - Një përshkrim i njësisë së masës raportuese
• Njësia njësi - Njësia bazë e matjes për një pikë të dhënash raporti
• marketContext - Një URI që identifikon një Program DR
• metërAset - MeterAsset është pajisja fizike ose pajisjet që kryejnë rolin e njehsorit
• modifikimiDateTime - Kur një ngjarje modifikohet
• modifikimi Numri - Rritet sa herë që modifikohet një ngjarje.
• modifikimi Arsyeja - Pse u modifikua një ngjarje?
• mes - MRID identifikon pajisjen fizike që mund të jetë një CustomerMeter ose lloje të tjerë të EndDevices.
• nyja - Nyja është një vend ku diçka ndryshon (shpesh pronësia) ose lidhet në rrjet. Shumë nyje shoqërohen me njehsorë, por jo të gjitha janë.
• burimet e numData –
• kapaciteti –
• oadrRrjedha –
• oadrDataCuality –
• oadrDeviceClass - Objektivi i Klasës së Pajisjes - përdorni vetëm endDeviceAsset.
• oadrEvent - Një objekt që përmban një ngjarje të përgjigjes ndaj kërkesës
• oadrExtension –
• oadrExensionName -
• oadrZgjerimet –
• oadrHttpPullModel - Një boolean që tregon nëse VEN dëshiron të përdorë një model shkëmbimi tërheqës
• oadrInfo - Një çift i vlerave kryesore të informacionit specifik të regjistrimit të shërbimit
• oadrKellesa –
• oadrLevelOffset –
• oadrLoadControlState –
• oadrManualOverride - Nëse është e vërtetë, atëherë kontrolli i ngarkesës është anashkaluar manualisht
• oadrMax –
• Periudha oadrMax - S maksimaleampperiudhë ling
• oadrMin –
• Periudha oadrMin - Minimumi i sampperiudhë ling
• oadrNormale –
• oadrOnChange - Nëse është e vërtetë, të dhënat do të regjistrohen kur ato ndryshojnë, por jo më shumë se një frekuencë e specifikuar nga minPeriod.
• oadrOnline - Nëse është e vërtetë, atëherë burimi / aktivi është në internet, nëse është i gabuar, atëherë jashtë linje.
• oadrPagesa –
• oadrPayloadResourceStatus - Informacioni aktual i statusit të burimeve
• oadrPendingRaportet - Një listë e raporteve periodike akoma aktive
• oadrPercentOffset –
• oadrProfile - Profile mbështetur nga VEN ose VTN
• oadrProfileEmri - OpenADR profile emër si 2.0a ose 2.0b.
• oadrProfiles - OpenADR profiles mbështetur nga zbatimi
• oadrRaport -Një objekt që përmban të gjithë informacionin për një raport të vetëm
• oadrPërshkrimi i Raportit - Përshkrim i karakteristikave të raportit të ofruara nga prodhuesi i raportit. Përmbajtur në një raport të meta të dhënave
• oadrReportOnly - ReportOnlyDeviceFlag
• oadrReportPayload - Vlerat e pikave të të dhënave për raportet
• oadrKërkuarOadrPollFreq - VEN-i do të dërgojë një ngarkesë oadrPoll në VTN më së shumti një herë për secilën kohëzgjatje të specifikuar nga ky element
• oadrResponseKërkuar - Kontrollon kur kërkohet përgjigja optIn / optOut. Mund të jetë gjithmonë ose kurrë
• oadrSampNorma e lingut - Sampshkalla e lidhjes për të dhënat e tipit telemetrik
• oadrShërbimi –
• emri oadrService - Ky lloj synimi përdoret për ngjarjet, raportet dhe oraret e zgjedhjes. Vlera zakonisht caktohet nga ndërmarrja gjatë regjistrimit në një program DR
• oadrServiceSpecificInfo - Shërbimi i informacionit specifik të regjistrimit
• oadrSetPoint –
• oadrNënshkruarObjekti –
• oadrTransporti - Një emër transporti i mbështetur nga një VEN ose VTN
• oadrTransportAdresa - Adresa e rrënjës përdoret për të komunikuar me palën tjetër. Duhet të përfshijë port nëse kërkohet
• emri oadrTransport - Emri i transportit OpenADR siç është simpleHttp ose xmpp
• oadrTransportet - Transportet OpenADR mbështetur nga implementimi
• Raporti i azhurnuar - Pranoni pranimin e një raporti
• oadrUpdateReport - Dërgoni një raport të kërkuar më parë
• oadrVlera –
• Emri oadrVen - Emri VEN. Mund të përdoret në VTN GUI
• oadrXmlNënshkrimi - Zbatimi mbështet nënshkrimin XML
• optID - Identifikuesi për një ndërveprim të zgjedhë
• arsyetoni - Vlera e numëruar për arsyen e zgjedhjes siç është orari x
• lloji opt - zgjedhja ose zgjedhja e një ngjarjeje, ose përdoret për të treguar llojin e orarit të përcaktuar të përcaktuar në vavailablityObject për shërbimin EiOpt
• partiaID - Ky lloj synimi përdoret për ngjarjet, raportet dhe oraret e zgjedhjes. Vlera zakonisht caktohet nga ndërmarrja gjatë regjistrimit në një program DR
• ngarkesa e ngarkesës Float - Vlera e pikës së të dhënave për sinjalet e ngjarjes ose për raportimin e vlerave aktuale ose historike.
• pnode - Një nyje e çmimit është e lidhur drejtpërdrejt me një nyje të lidhjes. Shtë një vend çmimi për të cilin pjesëmarrësit e tregut paraqesin ofertat e tyre, ofertat, blejnë / shesin CRR dhe vendosen.
• pika e dorëzimit –
• pikaOfReceipt –
• poslista –
• fuqia e dukshme - Fuqia e dukshme e matur në volt-amperes (VA)
• atributet e fuqisë
• fuqiaAtem
• fuqia reaktive - Fuqia reaktive, e matur në volt-amperes reaktive (VAR)
• fuqia e vërtetë - Fuqia reale e matur në Watts (W) ose Joules / sekondë (J / s)
• përparësia - Prioriteti i ngjarjes në lidhje me ngjarjet e tjera (Sa më i ulët numri të jetë më i lartë përparësia. Një vlerë zero (0) nuk tregon asnjë përparësi, e cila është përparësia më e ulët si parazgjedhje).
• vetitë –
• pulsiLlogaritja - Një pikë e të dhënave raportuese
• impuls Faktori - kWh për numërim
• i kualifikuarEventID - Një ID unike për një ngjarje
• lloji i leximit - Metadata për leximet, të tilla si mesatare ose të prejardhura
• regjistrimi ID - Identifikuesi për transaksionin e Regjistrimit. Nuk përfshihet në përgjigje të regjistrimit të pyetjes nëse nuk është regjistruar tashmë
• përgjigjeLimit - Numri maksimal i ngjarjeve për t'u kthyer në një ngarkesë oadrDistributeEvent
• reportBackDuration - Raportoni përsëri me Raportin deri më tani për çdo kalim të kësaj Kohëzgjatjeje.
• reportDataSource - Burimet e të dhënave në këtë raport. p.shamples përfshijnë njehsorët ose nënmetrat. Për shembullampLe, nëse një matës është i aftë të sigurojë dy lloje të ndryshme matjesh, atëherë çdo rrjedhë matje do të identifikohej veçmas.
• reportInterval - Kjo është periudha e përgjithshme e raportimit.
• reportName - Emri opsional për një raport.
• reportRequestID - Identifikuesi për një kërkesë të veçantë raporti
• raport specifikuesi - Specifikoni pikat e të dhënave të dëshiruara në një shembull të veçantë raporti
• reportSpecifierID - Identifikues për një specifikim të veçantë të raportit Metadata
• raportiTema - Objektivi i Klasës së Pajisjes - përdorni vetëm endDeviceAsset.
• reportToFollow - Tregon nëse raporti (në formën e UpdateReport) do të kthehet pas anulimit të Raportit
• lloji i raportit - Lloji i një raporti siç është përdorimi ose çmimi
• kërkesaID - Një ID e përdorur për të përputhur një kërkesë dhe përgjigje logjike të transaksionit
• burimID - Ky lloj synimi përdoret për ngjarjet, raportet dhe oraret e zgjedhjes. Vlera zakonisht caktohet nga ndërmarrja gjatë regjistrimit në një program DR
• përgjigje –
• Kodi i përgjigjes - Një kod përgjigje 3 shifror
• përgjigjePërshkrimi - Përshkrimi përshkrues i statusit të përgjigjes
• përgjigjet –
• RID - ReferencaID për këtë pikë të dhënash
• zona e shërbimit - Ky lloj synimi përdoret për ngjarjet, raportet dhe oraret e zgjedhjes. Vlera zakonisht caktohet nga ndërmarrja gjatë regjistrimit në një program DR
• serviceDeliveryPoint - Pika logjike në rrjet ku pronësia e shërbimit ndryshon duart. Isshtë një nga pikat e mundshme të shërbimit brenda një Vendndodhja të Shërbimit, duke ofruar shërbim në përputhje me një Marrëveshje të Klientit. Përdoret në vendin ku mund të instalohet njehsor.
• vendndodhja e shërbimit - Një vend i shërbimit për klientin ka një ose më shumë PointDelivery Service (s), të cilat nga ana e tyre kanë të bëjnë me Matësit. Vendndodhja mund të jetë një pikë ose një shumëkëndësh, në varësi të rrethanave specifike. Për shpërndarje, Vendndodhja e Shërbimit është zakonisht vendndodhja e lokalit të klientit të shërbimeve.
• sinjal ID - Identifikues unik për një sinjal specifik të ngjarjes
• emri i sinjalit - Emri i një sinjali të tillë si SIMPLE
• SignPayload - Vlerat e sinjalit për ngjarjet dhe linjat bazë
• siScaleCode - Një faktor shkallëzimi për njësinë bazë të matjes për një raport
• specifikuesPagesa - Një e hapur
• fillimi - Dritarja e Randomizimit për fillimin e ngjarjes
• statusDateTime - Data dhe ora referimet e këtij artefakti.
• temperatura –
• testEvent - Çdo gjë tjetër përveç false është një ngjarje prove
• teksti –
• term –
• tolerancë - Një nën-objekt që përmban kërkesat e randomizimit për një ngjarje
• tolerojë - Një objekt që përmban kërkesat e randomizimit për një ngjarje
• ndërfaqja e transportit - Ndërfaqja e Transportit përcakton skajet në të dy skajet e një segmenti transporti.
• uid - Përdoret si indeks për të identifikuar intervalet. Identifikues unik
• vlerë –
• disponueshmëria - Një orar që pasqyron disponueshmërinë e pajisjes për pjesëmarrjen në ngjarjet DR
• venID - Një identifikues unik për një VEN
• vëlltage –
• vtnComent - Çdo tekst
• vtnID - Një identifikues unik për një VTN
• njoftimi x-ei - VEN duhet të marrë ngarkesën e ngjarjes DR përpara fillimit të minutës minus këtë kohëzgjatje.
• x-eiRamplart - Një kohëzgjatje para ose pas kohës së fillimit të ngjarjes gjatë së cilës ngarkesa duhet të kalojë.
• rikuperimi x-ei - Një kohëzgjatje para ose pas kohës së përfundimit të ngjarjes gjatë së cilës ngarkesa duhet të kalojë.

 

Fjalori i vlerave të numëruara

Statusi i ngjarjes

• aktive - Ngjarja është iniciuar dhe aktualisht është aktive.
• anuluar - Ngjarja është anuluar.
• përfunduar - Ngjarja ka përfunduar.
• larg - Ngjarja në pritje në të ardhmen e largët. Përkufizimi i saktë se sa larg në të ardhmen i referohet kjo varet nga konteksti i tregut, por zakonisht do të thotë të nesërmen.
• afër – Ngjarja në pritje në të ardhmen e afërt. Përkufizimi i saktë se sa afër në të ardhmen është aktive ngjarja në pritje varet nga konteksti i tregut. .Fillon njëkohësisht me fillimin efektiv të ngjarjes x-eiRampKoha e fundit. Nëse x-eiRampUp nuk është përcaktuar për ngjarjen, ky status nuk do të përdoret për ngjarjen.
• asnjë - Asnjë ngjarje në pritje

artikulliNjësitë

• Monedha
  • USD - Dollarë të Shteteve të Bashkuara
  • Për shumë për të renditur këtu, referojuni skemës
• fuqia e vërtetë
  • J/s - Xhul-sekondë
  • W - Watts
• temperatura
  • celsius –
  • fahrenheit –

oadrDataCuality

• Nuk ka vlerë të re - Vlera e mëparshme e përdorur –
• Pa cilësi - pa vlerë –
• Dështimi i Cilësisë së Keqe - Comm –
• Cilësia e gabuar - Gabim në konfigurim –
• Cilësia e keqe - Dështimi i pajisjes –
• Cilësia e keqe - Vlera e njohur e fundit –
• Cilësia e keqe - jo specifike –
• Cilësia e keqe - e pa lidhur –
• Cilësia e keqe - jashtë shërbimit –
• Cilësia e keqe - Dështimi i sensorit –
• Cilësia e mirë - Anashkalimi lokal –
• Cilësia e mirë - Jo specifike –
• Kufiri i Cilësisë - Fusha / Konstantja –
• Kufiri i Cilësisë - Fusha / E Lartë –
• Kufiri i Cilësisë - Fusha / E Ulët –
• Kufiri i Cilësisë - Fusha / Jo –
• Cilësia e pasigurt - Njësitë e BE-së tejkaluar –
• Cilësia e pasigurt - Vlera e fundit e përdorshme –
• Cilësia e pasigurt - Jo specifike –
• Cilësia e pasigurt - Sensori jo i saktë –
• Cilësia e pasigurt - Nën Normale –

oadrResponseKërkohet

• gjithmonë - Gjithmonë dërgoni një përgjigje për çdo ngjarje të marrë.
• kurrë - Mos u përgjigj kurrë.

arsyetoni

Rreshtohen arsyet e zgjedhjes.

• ekonomike –
• emergjente –
• duhet të ekzekutohet –
• joPjesëmarrja –
• outageRunStatus –
• anulojStatus -
• duke marrë pjesë –
• x-orar –

Emri oadrTransport

• e thjeshtëHttp –
• xmpp –

Lloji i tipit

• zgjedhin - Një tregues që VEN do të marrë pjesë në një ngjarje, ose në rastin e shërbimit EiOpt një lloj orari që tregon se burimi do të jetë i disponueshëm
• zgjedh - Një tregues që VEN nuk do të marrë pjesë në një ngjarje, ose në rastin e shërbimit EiOpt një lloj orari që tregon se burimi nuk do të jetë i disponueshëm

lexim Lloji

• Alokuar - Matësi mbulon disa [burime] dhe përdorimi nxirret përmes një lloj llogaritjeje të të dhënave pro.
• Kontrata - Tregon se leximi është pro forma, d.m.th., raportohet me norma të dakorduara
• E derivuar - Përdorimi nxirret përmes njohurisë për kohën e funksionimit, funksionimin normal, etj.
• Lexoni drejtpërdrejt - Leximi lexohet nga një pajisje që rritet monotonisht dhe përdorimi duhet të llogaritet nga çiftet e leximeve të fillimit dhe ndalimit.
• e vlerësuar - Përdoret kur një lexim mungon në një seri në të cilën shumica e leximeve janë të pranishme.
• Hibrid - Nëse është i grumbulluar, i referohet llojeve të ndryshme të leximit në numrin e përgjithshëm.
• Mesatarja - Leximi është vlera mesatare gjatë periudhës së treguar në Granularity
• Net - Matësi ose [burimi] përgatit llogaritjen e tij të përdorimit total me kalimin e kohës.
• Maja - Leximi është vlera e pikut (më e larta) gjatë periudhës së treguar në grimcim. Për disa matje, mund të ketë më kuptim si vlera më e ulët. Mund të mos jetë në përputhje me leximet e përgjithshme. E vlefshme vetëm për bazat e artikullit me shpejtësi të rrjedhës, dmth., Energjia jo energjia.
• Projektuar - Tregon se leximi është në të ardhmen dhe nuk është matur ende.
• Përmblodhi - Disa metra së bashku sigurojnë leximin për këtë [burim]. Kjo është posaçërisht një ndryshe nga e grumbulluar, e cila i referohet [burimeve] të shumëfishta në të njëjtën ngarkesë. Shih gjithashtu Hibrid.
• x-joE zbatueshme - Nuk aplikohet
• x-RMS - Sheshi Rrënjë

raporti Emri

• HISTORI_BUTONI I GJELBR - Një raport që përmban të dhëna të butonit të gjelbër në një strukturë të skemës së ushqimit të atomit
• HISTORY_USAGE - Një raport që përmban të dhëna historike të përdorimit të energjisë
• BUTONI METADATA_HISTORY_GREEN - Një raport i meta të dhënave që përcakton aftësitë e raportimit për raportet HISTORY_GREENBUTTON
• METADATA_HISTORY_USAGE - Një raport i meta të dhënave që përcakton aftësitë e raportimit për raportet HISTORY_USAGE
• METADATA_TELEMETRY_STATUS - Një raport i meta të dhënave që përcakton aftësitë e raportimit për raportet TELEMETRY_STATUS
• METADATA_TELEMETRY_USAGE - Një raport i meta të dhënave që përcakton aftësitë e raportimit për raportet TELEMETRY_USAGE
• TELEMETRI_STATUS - Një raport që përmban informacione mbi statusin e burimeve në kohë reale siç është gjendja në internet
• TELEMETRY_USAGE - Një raport që përmban informacionin e përdorimit të energjisë në kohë reale

lloji i raportit

Një vlerë e numëruar që jep llojin e raportit që ofrohet.

• në dispozicionEnergyStorage - Kapaciteti në dispozicion për ruajtjen e mëtejshme të energjisë, ndoshta për të arritur në Storage Energy Storage
• avgKërkesa - Përdorimi mesatar gjatë kohëzgjatjes së treguar nga Granularity. Shihni kërkesën për më shumë informacion.
• përdorimi mesatar - Përdorimi mesatar gjatë kohëzgjatjes së treguar nga Granularity. Shihni përdorimin për më shumë informacion.
• bazë - Mund të jetë kërkesë ose përdorim, siç tregohet nga ItemBase. Tregon se çfarë do të ishte [matja] nëse nuk do të ishte ngjarja ose rregullorja. Raporti është i formatit Bazë.
• deltaKërkesa - Ndryshimi i kërkesës krahasuar me vijën fillestare. Shihni kërkesën për më shumë informacion
• deltaSetPoint - Ndryshimet në pikën e caktuar nga orari i mëparshëm.
• deltaPërdorimi - Ndryshimi i përdorimit në krahasim me vijën fillestare. Shihni përdorimin për më shumë informacion
• kërkesa - Raporti tregon një sasi njësish (të shprehura në ItemBase ose në Produktin EMIX). Lloji i ngarkesës është Sasia. Një ItemBase tipike është Fuqia e Vërtetë.
• devijimi - Diferenca midis disa udhëzimeve dhe gjendjes aktuale.
• poshtëRregullimi Kapaciteti i disponueshëm - Kapaciteti i rregullimit poshtë për disponim, shprehur në EMIX Real Power. Ngarkesa e ngarkesës shprehet gjithmonë si Sasia pozitive.
• niveli - Nivel i thjeshtë nga tregu në çdo interval.
• Shteti operativ - Gjendja e përgjithësuar e një burimi të tillë si ndezja / fikja, shfrytëzimi i ndërtesës, etj. Asnjë Baza e Artikullit nuk është e rëndësishme. Kërkon një shtesë ngarkese specifike për aplikacionin.
• për qind Kërkesa – Përqindjatage të kërkesës
• përqindja e përdorimit – Përqindjatage të përdorimit
• fuqiaFaktori - Faktori i fuqisë për burimin
• çmimi - Çmimi për artikull bazë në çdo interval
• duke lexuar - Raporti tregon një lexim, si nga njehsori. Leximet janë momente në kohë, ndryshimet me kalimin e kohës mund të llogariten nga ndryshimi midis leximeve të njëpasnjëshme. Lloji i ngarkesës është notues
• rregullimiPika e pikës - Pika e përcaktuar e rregullores siç udhëzohet si pjesë e shërbimeve rregulluese
• setPoint - Raporti tregon shumën (e shprehur në ItemBase ose në Produktin EMIX) e vendosur aktualisht. Mund të jetë një konfirmim / kthim i vlerës së kontrollit të pikës së caktuar dërguar nga VTN. Lloji i ngarkesës është Sasia. Një ItemBase tipike është Fuqia e Vërtetë.
• ruajturEnergjia - Energjia e depozituar shprehet si energji reale dhe ngarkesa e ngarkesës shprehet si sasi.
• targetEnergyStorage - Energjia e synuar shprehet si Energji Reale dhe Ngarkesa është e shprehur si Sasi.
• lartRregullimi Kapaciteti i disponueshëm - Kapaciteti rregullues i disponueshëm për dërgim, i shprehur në EMIX Real Power. Ngarkesa e ngarkesës shprehet gjithmonë si Sasia pozitive.
• përdorimi - Raporti tregon një sasi njësish (të shprehura në ItemBase ose në Produktin EMIX) gjatë një periudhe. Lloji i ngarkesës është Sasia. Një ItemBase tipike është RealEnergy
• x-burimStatusi – Përqindjatage të kërkesës

kodi i shkallës

• p - Pico 10 ** - 12
• n - Nano 10 ** - 9
• mikro - Mikro 10 ** - 6
• m - Milli 10 ** - 3
• c - Centi 10 ** - 2
• d - Dhjetor 10 ** - 1
• k - Kilo 10 ** 3
• M - Mega 10 ** 6
• G - Giga 10 ** 9
• T - Tera 10 ** 12
• asnjë - Shkalla amtare

emri i sinjalit

• BID_ENERGJIA - Kjo është sasia e energjisë nga një burim që është ofruar në një program
• BID_LOAD - Kjo është sasia e ngarkesës që është ofruar nga një burim në një program
• BID_PRICE - Ky është çmimi që është ofruar nga burimi
• CHARGE_STATE - Gjendja e burimit të ruajtjes së energjisë
• KËRKESA_SHARIME - Kjo është pagesa e kërkesës
• ELECTRICTY_PRICE - Kjo është kostoja e energjisë elektrike
• ENERGY_PRICE - Kjo është kostoja e energjisë
• LOAD_CONTROL -Vendosni daljen e ngarkesës në vlerat relative
• LOAD_DISPATCH - Kjo përdoret për të dërguar ngarkesën
• thjeshtë – i zhvlerësuar – për pajtueshmëri me A profile
• E THJESHTË - Nivele të thjeshta (në përputhje me OpenADR 2.0a)

tipi i sinjalit

Një vlerë e numëruar që përshkruan llojin e sinjalit siç është niveli ose çmimi

• delta - Sinjali tregon sasinë që duhet të ndryshojë nga ajo që do të kishte përdorur pa sinjalin.
• niveli - Sinjali tregon një nivel programi.
• shumohenr - Sinjali tregon një shumëzues të aplikuar në normën aktuale të dorëzimit ose përdorimit nga ajo që dikush do të kishte përdorur pa sinjalin.
• çmimi - Sinjali tregon çmimin.
• çmimiMultiplier - Sinjali tregon shumëzuesin e çmimit. Çmimi i zgjatur është vlera e llogaritur e çmimit shumëzuar me numrin e njësive.
• çmimi relativ - Sinjali tregon çmimin relativ.
• pika e caktuar - Sinjali tregon një sasi të synuar të njësive.
• x-loadControl Kapaciteti – Ky është një udhëzim për kontrolluesin e ngarkesës që të funksionojë në një nivel që është disa përqindtage të kapacitetit maksimal të konsumit të ngarkesës. Kjo mund të krahasohet me kontrollues specifikë të ngarkesës për të bërë gjëra të tilla si çiklizmi. Vini re se 1.0 i referohet konsumit 100%. Në rastin e pajisjeve të thjeshta të tipit ON/OFF atëherë 0 = OFF dhe 1 = ON.
• x-loadControlLevelOffset - Nivelet diskrete të plota që janë relative me operacionet normale ku 0 është operacione normale.
• x-loadControlPercentOffset – Përqindjatage ndryshim nga operacionet normale të kontrollit të ngarkesës.
• x-loadControlSetpoint - Vendosni pikat e vendosura të kontrolluesit.

– OpenADR A dhe B Profile Dallimet

I vetmi shërbim i mbështetur nga A profile është shërbimi EiEvent. Objekti EiEvent është thjeshtuar në A profile me kufizimet e mëposhtme:

• Lejohet vetëm një sinjal për ngjarje dhe ai sinjal duhet të jetë sinjali i mirënjohur OpenADR SIMPLE.
• Ekziston një shënjestrim i kufizuar i ngjarjeve vetëm me venID, groupID, burimID dhe partiID të mbështetur. (EiEvent: eiTarget).
• Shënjestrimi në nivelin e sinjalit me klasat e pajisjes nuk mbështetet (eiEventSignal: eiTarget: endDeviceAsset).
• Vijat bazë nuk mbështeten (eiEvent: eiEventSignals: eiEventBaseline).
• modifikimi Data dhe koha e modifikimit nuk mbështeten.
• Pika përfundimtare URL për HTTP të thjeshtë në 2.0b është:
  • https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Disa elementë të ngarkesës që kërkoheshin në A profile tani janë opsionale në B profile, duke përfshirë:

• vlera e tanishme

- Certifikatat e Sigurisë OpenADR

Rregullat e konformitetit OpenADR kërkojnë sa vijon:

• TLS Version 1.2 përdoret për shkëmbimin e certifikatave X.509
• VTN-të duhet të kenë si SHA256 ECC ashtu edhe certifikata RSA
• VEN-të mund të mbështesin çertifikatat SHA256 ECC dhe RSA dhe mund të mbështesin të dyja
• Të dy VTN-të dhe VEN-të duhet të konfigurohen për të kërkuar çertifikata të klientit nëse do të luajnë rolin e një serveri transporti (p.sh. duke iu përgjigjur kërkesave nga pala tjetër)
• Të dy VTN-të dhe VEN-të duhet të sigurojnë një certifikatë klienti kur kërkohet nga pala tjetër si pjesë e procesit të negociatave të TLS

Certifikatat e ofruara nga NetworkFX do të jenë specifike për RSA ose ECC. Krijimi i këtyre certifikatave mund të ndodhë si rezultat i plotësimit të formularëve në NetworkFX web vend për të kërkuar certifikata testimi ose mund të jetë rezultat i kërkesës së certifikatave të prodhimit nëpërmjet një kërkese për nënshkrimin e certifikatës (CSR). Pavarësisht nga metoda, sa vijon filedo të sigurohen (p.shamptregohen):

• Certifikata rrënjësore
• Certifikata e Rrënjës së Mesme
• Certifikata e pajisjes
• Çelësi Privat

Në përgjithësi, çelësi privat përdoret për të enkriptuar ngarkesat e dërguara nga një VEN ose VTN. Certifikata e pajisjes është një grup informacioni identifikues unik për një VEN ose VTN që është krijuar nga një Autoritet Certifikues dhe është koduar duke përdorur Çelësin Privat. Rrënja dhe e ndërmjetme files përdoren për të deshifruar certifikatën e pajisjes dhe për të vërtetuar që certifikata erdhi nga një autoritet i besuar.

Në një mjedis Java që përdor JSSE, ekzistojnë dy dyqane të certifikatave. Njëri quhet Trust Store dhe përdoret për të mbajtur Certifikatën Root. E dyta quhet Key Store dhe përdoret për të ruajtur një zinxhir certifikatash që përbëhet nga çertifikata e ndërmjetme e çertifikatës së pajisjes, si dhe çelësi privat

Ju lutemi vini re se kur përdorni një transport XMPP VEN po komunikon me serverin XMPP dhe JO direkt me VTN. Pra, konfigurimi i certifikatave në serverin XMPP DUHET të jetë ekuivalent me atë të një VTN. Komunikimi midis vetë VTN dhe serverit XMPP është transparent për VEN dhe është në thelb një lidhje private. Sidoqoftë, shumica e shitësve përdorën një sërë certifikatash VEN në VTN kur komunikonin me serverin XMPP.

Nëse jeni duke përdorur OpenFire si serverin tuaj XMPP, ekziston një kufizim tjetër që duhet të merrni parasysh. OpenFire kërkon që emri CN i përdorur në çertifikatat e pajisjes klient të përputhet me emrin e përdoruesit të pajisjeve XMPP të konfiguruar në serverin XMPP. Kjo mund të rezultojë në disa emra klientësh të çuditshëm pasi një adresë si MAC përdoret për emrin CN në certifikatat VEN (Pjesë e Kërkesave të Sigurisë OpenADR)

Më në fund, shumica e VEN-ve dhe VTN-ve kur luajnë rolin e një klienti transporti do të përpiqen të vërtetojnë që fusha CN e certifikatës së dhënë nga serveri i transportit ka një emër CN që përputhet me emrin e hostit të njësisë që ka dhënë certifikatën. Ky mund të jetë një burim tjetër i problemeve të ndërveprimit gjatë shkëmbimit të certifikatave. Verifikimi i emrit të hostit zakonisht mund të çaktivizohet në mënyrë programore për të izoluar këto lloje çështjesh.

Udhëzuesi i Programit të Reagimit të Kërkesës OpenADR 2.0 - Shkarkoni [optimizuar]
Udhëzuesi i Programit të Reagimit të Kërkesës OpenADR 2.0 - Shkarkoni

Referencat

• Manuali i Përdoruesit