OpenADR 2.0

Кіраўніцтва праграмы рэагавання на попыт

Нумар рэвізіі: 0.92

Статус дакумента: працоўны тэкст

Нумар дакумента: 20140701

Аўтарскае права © OpenADR Alliance (2014/15). Усе правы абаронены. Інфармацыя ў гэтым дакуменце з'яўляецца ўласнасцю OpenADR Alliance, яе выкарыстанне і раскрыццё забаронена.

ЗМЕСТ

1 Уводзіны 6

2 Спасылкі 6

3 Тэрміны і азначэнні 6

4 Скарачэнні 9

5 тыпаў праграм рэагавання на попыт 9

6 Сцэнарыі разгортвання 10

6.1 Прамы 1 11

6.2 Прамы 2 12

6.3 Прамы 3 13

6.4 Прамы 4 14

6.5 Вядоўца 1 15

6.6 Агрэгатар 1 16

7 Сцэнар разгортвання і адлюстраванне праграмы DR 16

8 Выбар шаблону праграмы DR 18

9 шаблонаў праграмы рэагавання на попыт 21

9.1 Праграма крытычнага пікавага цэнаўтварэння (CPP) 21

9.1.1 Характарыстыкі праграмы CPP DR 21

9.1.2 Характарыстыкі OpenADR для праграм CPP 22

9.2 Праграма заяўкі на магутнасць 24

9.2.1 Характарыстыкі праграмы DR таргоў магутнасцю 24

9.2.2 Характарыстыкі OpenADR для праграм стаўкі магутнасці 25

9.3 Праграма тэрмастата для жылых памяшканняў 27

9.3.1 Характарыстыкі праграмы DR тэрмастата для жылых памяшканняў 27

9.3.2 Характарыстыкі OpenADR для праграм жылых тэрмастатаў 28

9.4 Хуткая адпраўка DR 29

9.4.1 Характарыстыкі праграмы Fast DR Dispatch 29

9.4.2 Характарыстыкі OpenADR для праграм стаўкі магутнасці 31

9.5 Праграма часу выкарыстання (TOU) жылых электрамабіляў (EV) 33

9.5.1 Характарыстыкі праграмы Residential EV TOU 33

9.5.2 Характарыстыкі OpenADR для жылых праграм EV TOU 33

9.6 Праграма цэнаўтварэння ў рэжыме рэальнага часу на электрамабіль грамадскага карыстання (EV) 34

9.6.1 Характарыстыкі праграмы Public Station EV RTP 34

9.6.2 Характарыстыкі OpenADR для праграм Public Station EV RTP 34

9.7 Праграма 35 размеркаваных энергетычных рэсурсаў (DER).

9.7.1 Характарыстыкі праграмы размеркаваных энергетычных рэсурсаў (DER) 35

9.7.2 Характарыстыкі OpenADR для размеркаваных энергетычных рэсурсаў (DER) 35

Дадатак A – SampШаблоны дадзеных і карыснай нагрузкі 36

A.1 Праграма крытычнага пікавага цэнаўтварэння (CPP) 36

A.1.1 Сцэнар CPP 1 – просты варыянт выкарыстання, A ці B Profile 36

A.1.2 Сцэнар CPP 2 – Тыповы варыянт выкарыстання, B profile 36

A.1.3 Сцэнар CPP 3 – складаны варыянт выкарыстання 37

A.1.4 CPP SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання 37

A.2 Праграма таргоў па ёмістасці (CBP) 39

A.2.1 Сцэнар CBP 1 – просты варыянт выкарыстання, A або B Profile 39

A.2.2 Сцэнар CBP 2 – Тыповы варыянт выкарыстання, B profile 39

A.2.3 Сцэнар CBP 3 – складаны варыянт выкарыстання 40

A.2.4 CBP SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання 40

A.3 Праграма тэрмастата для жылых памяшканняў 42

A.3.1 Сцэнар жылога тэрмастата 1 – просты варыянт выкарыстання, A або B Profile 42

A.3.2 Сцэнар 2 жылога тэрмастата – тыповы варыянт выкарыстання, B profile 42

A.3.3 Сцэнар 3 жылога тэрмастата – складаны варыянт выкарыстання 43

A.3.4 Тэрмастат для жылых памяшканняў SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання 43

A.4 Хуткая адпраўка DR 45

A.4.1 Сцэнар хуткага аднаўленьня 1 – Просты варыянт выкарыстаньня, A ці B Profile 45

A.4.2 Сцэнар хуткага аднаўленьня 2 – тыповы варыянт выкарыстаньня, B profile 45

A.4.3 Сцэнар хуткага аднаўлення 3 - складаны варыянт выкарыстання 46

A.4.4 Хуткі DR SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання 46

A.4.5 Хуткі DR Sample Карысная нагрузка метаданых справаздачы – Тыповы B Profile Выпадак выкарыстання 48

A.4.6 Хуткі DR Sample Карысная нагрузка запыту на справаздачу – Тыповы B Profile Выпадак выкарыстання 48

A.4.7 Хуткі DR SampКарысная нагрузка даных справаздач – тыповы B Profile Выпадак выкарыстання 49

A.5 Праграма часу выкарыстання (TOU) жылых электрамабіляў (EV) 49

A.5.1 Сцэнар 1 для жылых электрамабіляў – просты варыянт выкарыстання, A або B Profile 49

A.5.2 Сцэнар 2 для жылых электрамабіляў – тыповы варыянт выкарыстання, B profile 50

A.5.3 Жылы EV SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання 50

A.6 Праграма цэнаўтварэння ў рэжыме рэальнага часу на электрычных транспартных сродках (EV) грамадскіх станцый 53

A.6.1 Грамадская станцыя EV Сцэнар 1 – Тыповы варыянт выкарыстання, B profile 53

A.6.2 Грамадская станцыя EV SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання 53

A.7 Праграма 54 размеркаваных энергетычных рэсурсаў (DER).

Дадатак B – Вызначэнні паслуг і карыснай нагрузкі 55

B.1 Open ADR падтрымлівае наступныя паслугі: 55

Дадатак C – Вызначэнні паслуг і карыснай нагрузкі 56

C.1 Карысныя нагрузкі EiEvent 56

C.2 Карысныя нагрузкі EiReport 56

C.3 Карысныя нагрузкі EiOpt 56

C.4 Карысная нагрузка EiRegisterParty 57

C.5 Карысныя нагрузкі OadrPoll 57

Дадатак D – Гласарый элементаў карыснай нагрузкі схемы 58

Дадатак E Гласарый пералічаных значэнняў 65

E.1 Статус падзеі 65

E.2 пункт Адзінкі 65

E.3 oadrDataQuality 65

E.4 oadrResponseRequired 66

E.5 optReason 66

E.6 oadrTransportName 66

E.7 OptType 66

E.8 readingType 66

E.9 ReportName 67

E.10 reportType 67

Шкала E.11Код 68

E.12 Імя сігналу 68

E.13 сігнал, тып 69

Дадатак F – OpenADR A і B Profile Адрозненні 70

Дадатак G – Сертыфікаты бяспекі OpenADR 71

Уводзіны

Мэтавая аўдыторыя гэтага кіраўніцтва - камунальныя службы, якія плануюць разгарнуць праграмы рэагавання на патрабаванні (DR), якія выкарыстоўваюць OpenADR 2.0 для перадачы паведамленняў, звязаных з падзеямі DR, паміж камунальнай службай і суб'ектамі далейшага патоку, а таксама вытворцы абсталявання, якое палягчае гэты абмен. Мяркуецца, што чытач мае асноўнае канцэптуальнае разуменне як адказу на попыт, так і OpenADR 2.0 (з гэтага моманту будзе называцца проста OpenADR).

OpenADR profile спецыфікацыі дакладна вызначаюць чаканыя паводзіны пры абмене інфармацыяй, звязанай з падзеямі DR, аднак у OpenADR ёсць дастаткова дадатковых магчымасцей, каб разгортванне сервераў (VTN) на ўтыліце і кліентаў (VEN) на ніжэйстаячых сайтах не было вопытам plug-n-play. Характарыстыкі OpenADR, такія як сігналы падзей, фарматы справаздач і таргетынг, павінны вызначацца на аснове DR для кожнай праграмы.

Стандартызаванай праграмы DR не існуе. Кожная праграма DR мае тэндэнцыю быць унікальнай, адпаведнай структурным і нарматыўным патрабаванням геаграфічнага рэгіёну, у якім яна разгорнута. Для кожнай праграмы DR існуе мноства магчымых сцэнарыяў разгортвання з удзелам розных удзельнікаў.

Зменлівасць дызайну праграм DR, сцэнарыяў разгортвання і характарыстык OpenADR перашкаджаюць пашыранаму разгортванню DR і выкарыстанню OpenADR. Гэтая зменлівасць па большай частцы з'яўляецца адлюстраваннем фрагментарнай і складанай прыроды разумнай сеткі.

Камунальныя паслугі маюць патрэбу ў эксampтыповых праграм DR, каб іх можна было выкарыстоўваць у якасці мадэляў для іх уласных рэалізацый праграм DR. Вытворцы абсталявання павінны разумець тыповыя мадэлі выкарыстання праграмы DR, каб яны маглі правяраць узаемадзеянне ў рамках працэсу распрацоўкі, а не на аснове канкрэтнага разгортвання праграмы DR. Мэтай гэтага кіраўніцтва з'яўляецца дасягненне абедзвюх гэтых мэтаў наступным чынам:

• Вызначце невялікі набор стандартных шаблонаў праграм DR, створаных паводле агульных характарыстык найбольш папулярных праграм DR, рэалізаваных на сённяшні дзень
• Вызначце невялікі набор сцэнарыяў разгортвання па ўзоры рэальных разгортванняў з дакладна вызначанымі дзеючымі асобамі і ролямі
• Вызначце лепшыя практычныя рэкамендацыі для характарыстык OpenADR, характэрных для кожнага з шаблонаў праграмы DR
• Забяспечце дрэва рашэнняў, якое камунальныя службы могуць выкарыстоўваць для вызначэння карысных шаблонаў праграм DR і сцэнарыяў разгортвання ў залежнасці ад іх бізнес-патрэб

У гэтым кіраўніцтве акцэнт будзе зроблены на тым, каб усё было проста, шляхам прадастаўлення невялікага набору выразных рэкамендацый, якія датычаць большасці дэталяў, неабходных для разгортвання тыповай праграмы DR, а таксама на правядзенне тэсціравання ўзаемадзеяння абсталявання, разгорнутага ў праграмах, з выкарыстаннем рэкамендацый у гэтым кіраўніцтва.

Спасылкі

• OpenADR Profile Спецыфікацыя і схема – www.openadr.org

Тэрміны і азначэнні

У гэтым дакуменце выкарыстоўваюцца наступныя тэрміны і азначэнні.

• Рэакцыя на попыт: механізм для кіравання попытам кліентаў на нагрузку ў адказ на ўмовы паставак, такія як цэны або сігналы даступнасці
• Партыя-агрэгатар – Гэта бок, які аб'ядноўвае некалькі рэсурсаў разам і прадстаўляе іх удзельніку праграмы DR як адзіны рэсурс у сваіх праграмах DR.
• Пасрэдніцкая інфраструктура агрэгатара – Гэта інфраструктура, асобная ад інфраструктуры попыту, якая выкарыстоўваецца бокам-пасярэднікам агрэгатара для ўзаемадзеяння як з рэсурсамі, так і з суб'ектамі сеткі.
• Пагадненне: Кантрактнае пагадненне паміж бакамі, якія ўдзельнічаюць у праграме DR, з указаннем абавязкаў і кампенсацыі.
• актыў – Тып рэсурсу, які прадстаўляе пэўны набор фізічных нагрузак. Рэсурсы могуць складацца з Актываў, і Актывы могуць быць Рэсурсамі, але Актывы не могуць быць разбіты на некалькі Актываў або Рэсурсаў.
• Звязаны: Забяспечыць праграмную асацыяцыю паміж двума аб'ектамі праз канфігурацыю прылады базы дадзеных. Напрыклад, звязаныя рэсурсы з VEN
• Базавыя лініі: разлічанае або вымеранае спажыванне энергіі (патрэба) часткай абсталявання або пляцоўкай да падзеі, вызначанае шляхам даследаванняў, праверак і/або вымярэнняў на пляцоўцы.
• BMS – Гэта сістэма кіравання будынкам, якая можа выкарыстоўвацца для кантролю рэсурсаў. Гэта часам называюць сістэмай кіравання энергіяй.
• Складаны рэсурс – Гэта асаблівы тып рэсурсаў, які ўяўляе сабой сукупнасць некалькіх фізічных актываў, кожны з якіх мае ўласныя сродкі кантролю нагрузкі.
• Заахвочванне кліентаў: заахвочванне, якое прадастаўляецца ўладальніку/агрэгатару рэсурсаў з боку попыту для ўдзелу ў праграме DR.
• Інфраструктура попыту – Гэта інфраструктура, якая змяшчае рэсурсы, зарэгістраваныя ў праграмах DR
• DR Логіка: Алгарытмы або логіка, якія пераўтвараюць сігналы DR у дзейсны кантроль нагрузкі. Звярніце ўвагу, што DR Logic можа быць рэалізаваны ў розных месцах і ў некаторых выпадках можа быць размеркаваны паміж некалькімі падсістэмамі.
• DR Program Party – гэта суб'ект, які адказвае за інфраструктуру сеткі і, акрамя таго, за кіраванне праграмамі DR, якія выкарыстоўваюцца для змякчэння праблем з сеткай. Звычайна гэта ўтыліта або ISO.
• Паступіў: Уладальнік/агрэгатар рэсурсаў з боку попыту выбірае ўдзел у праграме DR і можа прадастаўляць інфармацыю аб канкрэтных рэсурсах, якія могуць быць накіраваны на падзеі DR.
• Актыўны перыяд падзеі: гэта перыяд часу, на працягу якога адбываецца змяненне нагрузкі праfile запытваецца ў рамках мерапрыемства DR
• Абмежаванні падзей: Прамежкі часу, на працягу якіх кліент можа разлічваць на атрыманне падзей, і звязаныя з імі абмежаванні, такія як адсутнасць падзей у выхадныя ці дні запар.
• Дні мерапрыемстваў: Дзень, калі адбываецца падзея DR. У большасці праграм ёсць абмежаванні на колькасць дзён правядзення мерапрыемстваў, дазволеных у пэўны каляндарны перыяд
• Дэскрыптар падзеі: частка аб'екта падзеі OpenADR, якая апісвае метададзеныя пра падзею, такія як назва праграмы і прыярытэт падзеі
• Працягласць мерапрыемства: Працягласць мерапрыемства. Большасць праграм вызначаюць абмежаванні адносна працягласці падзеі, а таксама гадзін у суткі, у якія падзея можа адбыцца
• Сігналы падзей: Карысная інфармацыя, якая змяшчаецца ў падзеі, напрыклад цэны на электраэнергію або пэўныя ўзроўні зняцця нагрузкі, запытаныя, якія звычайна выклікаюць некаторыя загадзя запраграмаваныя паводзіны па зніжэнні нагрузкі атрымальнікам падзеі. Вызначэнне праграмы DR павінна вызначаць тыпы выкарыстоўваных сігналаў падзей
• Таргетынг падзей: Рэсурсы зняцця нагрузкі, якія з'яўляюцца меркаваным атрымальнікам падзеі DR. Гэта можа быць геаграфічная вобласць, пэўны клас прылад, ідэнтыфікатар групы, ідэнтыфікатар рэсурсу або іншы ідэнтыфікатар. Вызначэнне праграмы DR павінна вызначаць, як канкрэтныя рэсурсы будуць арыентаваны.
• Падзеі: Падзея - гэта апавяшчэнне ад утыліты аб запатрабаванні пабочных рэсурсаў з запытам аб зніжэнні нагрузкі, пачынаючы з пэўнага часу і на працягу вызначанага перыяду, і можа ўключаць у сябе інфармацыю аб мэтавым прызначэнні пэўных рэсурсаў, якія павінны ўдзельнічаць у падзеі.
• Пасярэдніцкая інфраструктура фасілітатара – Гэта інфраструктура, асобная ад інфраструктуры з боку попыту, якая выкарыстоўваецца бокам-пасярэднікам для ўзаемадзеяння як з рэсурсамі, так і з суб'ектамі на баку сеткі.
• Фасілітатар: Трэці бок, які кіруе часткова або цалкам выкананнем праграмы DR ад імя ўтыліты
• Грыд-інфраструктура – Гэта інфраструктура, якая належыць або кіруецца бакамі праграмы DR. Гэтая інфраструктура ўключае ў сябе рэалізацыю OpenADR VTN, якая выкарыстоўваецца для адпраўкі сігналаў DR да рэсурсаў, зарэгістраваных у праграмах DR
• Партыя-пасярэднік – Гэта бок, які звычайна працуе ад імя Партыі рэсурсаў, каб спрыяць іх удзелу ў праграмах DR.
• Кантроль нагрузкі – гэта інфраструктура, звязаная з рэсурсам, якая адказвае за фактычны кантроль над рэсурсам і стварэнне пэўнай нагрузкіfile.
• Загрузіць Profile Мэта: Гэта матывацыя распрацоўкі праграмы DR і правядзення мерапрыемстваў. Напрыклад, жаданне згаліць пікавыя нагрузкі.
• Апавяшчэнне: перыяд часу перад пачаткам падзеі, калі ўладальнік рэсурсу з боку попыту паведамляецца аб незавершанай падзеі
• Opt Паводзіны: чаканая рэакцыя ад уладальніка рэсурсу з боку попыту пасля атрымання падзеі. Гэты адказ можа мець форму і ўказанне OptIn або OptOut, ці будзе рэсурс удзельнічаць у мерапрыемстве.
• Выбраць адказы: ці павінна пэўная праграма патрабаваць рэакцыі рэсурсаў з боку попыту ў адказ на падзею, і якія гэтыя рэакцыі звычайна бываюць.
• Opt Services: Расклады перадаюцца праз OpenADR, каб паказаць часовыя змены ў даступнасці рэсурсаў для ўдзелу ў мерапрыемствах.
• Абавязковая ўмова: Крытэрыі, якія павінны быць выкананы для таго, каб уладальнік рэсурсу з боку попыту мог зарэгістравацца ў праграме DR. Гэта можа ўключаць у сябе наяўнасць інтэрвалаў сустрэч або некаторую мінімальную здольнасць разгрузкі
• Асноўныя драйвера: Асноўная матывацыя з боку ўтыліты для стварэння праграмы DR і выдачы падзей. Такія, як «Пікавае зніжэнне попыту і дастатковасць рэсурсаў»
• Праграмы – Гэта праграмы DR, у якія зарэгістраваны рэсурсы.
• Апісанне праграмы: апісанне таго, як працуе праграма. Частка шаблонаў праграмы DR, вызначаных у гэтым дакуменце
• Тэрмін праграмы: Час года або поры года падчас праграмы DR звычайна актыўныя
• Стаўка Дызайн: Канкрэтныя мадыфікацыі ў структуры ставак або стымулы, якія выплачваюцца, каб матываваць уладальнікаў рэсурсаў з боку попыту ўдзельнічаць у праграме.
• Рэгістрацыйныя паслугі: Сэрвіс, які выкарыстоўваецца пратаколам OpenADR для ўстанаўлення базавай сумяшчальнасці паміж VTN і VEN, а таксама для праверкі таго, што VEN звязаны з уліковым запісам кліентаў камунальнай службы.
• Службы справаздачнасці: Сэрвіс, які выкарыстоўваецца OpenADR, каб дазволіць VENs прадастаўляць справаздачы VEN. Праграма DR павінна вызначаць патрабаванні да справаздачнасці для праграмы.
• Партыя рэсурсаў – Гэта партыя, якая валодае рэсурсамі з боку попыту, якія могуць быць зарэгістраваны ў праграмах DR
• Рэсурс – Гэта суб'ект, які зарэгістраваны ў праграмах DR і здольны ўнесці нейкія змены ў сваю нагрузку Profile у адказ на атрыманне сігналу DR ад VTN.
• Мэтавы кліент: Профіfile рэсурсаў з боку попыту, якія могуць удзельнічаць у канкрэтных праграмах DR, такіх як жылыя, прамысловыя, або, магчыма, на аснове ўзроўню спажывання электраэнергіі.
• Мэтавыя нагрузкі: Рэсурсы з боку попыту, загрузка якіх павінна быць зменена пасля атрымання a
• ВЕН – Гэта віртуальны канцавы вузел OpenADR, які выкарыстоўваецца для ўзаемадзеяння з VTN.
• ВТН – Гэта віртуальны верхні вузел OpenADR, які выкарыстоўваецца для ўзаемадзеяння з рэсурсамі, зарэгістраванымі ў праграмах DR.

Скарачэнні

• BMS: Сістэма кіравання будынкам
• C&I: Гандлёва-прамысловы
• Comm: Сувязь паміж двума суб'ектамі
• DR: Адказ на попыт
• EMS: Сістэма кіравання энергіяй
• OpenADR: Адкрыйце аўтаматызаваны адказ на попыт
• Праграмы: Спасылка на праграму(ы) рэагавання на попыт
• ВЕН: Віртуальны канцавы вузел
• ВТН: Віртуальны верхні вузел

Тыпы праграм рэагавання на попыт

Гэты дакумент змяшчае шаблоны для праграм DR, паказаных ніжэй.

 

1. Крытычны пік цэнаўтварэння: Структура ставак і/або коштаў, прызначаных для стымулявання зніжэння спажывання ў перыяды высокіх аптовых рынкавых цэн або непрадбачаных сітуацый сістэмы шляхам увядзення загадзя вызначанай высокай стаўкі або цаны на абмежаваную колькасць дзён ці гадзін.

2. Праграма таргоў па ёмістасці: праграма, якая дазваляе рэсурсу попыту на рознічных і аптовых рынках прапаноўваць зніжэнне нагрузкі па пэўнай цане або вызначаць, якую нагрузку яна гатовая скараціць па пэўнай цане.

 

3. Праграма тэрмастата для жылых памяшканняў/прамое кіраванне нагрузкай: Мерапрыемства рэагавання на попыт, з дапамогай якога спонсар праграмы дыстанцыйна кіруе электрычным абсталяваннем кліента (напрыклад, кандыцыянерам) у кароткія тэрміны. Гэтыя праграмы ў асноўным прапануюцца жылым або невялікім камерцыйным кліентам.

4. Праграма хуткай дыспетчарскай адпраўкі/дапаможных паслуг: Праграма рэагавання на попыт, якая забяспечвае заахвочвальныя выплаты кліентам за рэагаванне на нагрузку падчас надзвычайнай падзеі рэагавання на попыт. Ненармальны стан сістэмы (напрыклад,ample, сістэмныя абмежаванні і лакальныя абмежаванні прапускной здольнасці), якія патрабуюць аўтаматычных або неадкладных дзеянняў уручную для прадухілення або абмежавання збою перадачы або электразабеспячэння, які можа негатыўна паўплываць на надзейнасць Bulk Electric System. Гэты тып праграм часам можа называцца "Дапаможнымі паслугамі".

5. Праграма DR для электрамабіляў (EV).: Мерапрыемства па рэагаванні на попыт, з дапамогай якога кошт зарадкі электрамабіляў мадыфікуецца, каб прымусіць спажыўцоў змяніць схемы спажывання.

6. Праграма размеркаваных энергетычных рэсурсаў (DER) DR: дзейнасць па рэагаванні на попыт, якая выкарыстоўваецца для згладжвання інтэграцыі размеркавальных энергетычных рэсурсаў у разумную сетку.

 

Сцэнарыі разгортвання

Спосаб разгортвання праграмы DR збольшага не залежыць ад характарыстык самой праграмы DR. На наступных дыяграмах паказаны розныя спосабы разгортвання праграмы DR. У наступным раздзеле даецца перакрыжаваная спасылка паміж сцэнарыямі разгортвання і праграмамі DR, з якімі яны, хутчэй за ўсё, будуць выкарыстоўвацца.

Дыяграмы ў гэтым раздзеле паказваюць адносіны паміж сутнасцямі ў розных сцэнарыях.

Прамы 1

Гэта просты сцэнар, у якім існуе прамая сувязь паміж партыяй праграмы DR і партыяй рэсурсаў. Бок рэсурсаў нясе адказнасць за рэгістрацыю сваіх уласных рэсурсаў у праграмах DR, і інфраструктура сеткі ўзаемадзейнічае непасрэдна з рэсурсамі праз VEN, які знаходзіцца ў інфраструктуры з боку попыту. Акрамя таго, VEN належыць баку рэсурсаў і асобна ад рэсурсаў і іх кантралёраў. Калі VEN прымае сігнал DR, ён звычайна не рэалізуе ніякай логікі кіравання нагрузкай, а проста накіроўвае сігналы кантролерам нагрузкі, якія прымаюць адпаведныя меры. напрыкладampЧастка гэтага сцэнарыя будзе ўключаць будынкі C&I, якія могуць усталяваць шлюз, які змяшчае OpenADR VEN, і калі сігнал прымаецца гэтым шлюзам, ён проста перакладае яго ў нейкі іншы пратакол і накіроўвае самім кантролерам нагрузкі.

Прамы 2

Гэта вельмі падобна на сцэнар Direct 1. Асноўнае адрозненне заключаецца ў тым, як ствараецца асобнік VEN і спрыяе ўзаемадзеянню з VTN. VEN створаны ў такім аб'екце, як цэнтралізаваная BMS, якая можа рэалізаваць логіку DR і ўзаемадзейнічаць з Compound Resource і іх мноствам розных кантролераў нагрузкі з больш цэнтралізаванага месца. напрыкладampуключаюць вялікія будынкі з BMS, якія кантралююць мноства розных нагрузак у будынку (напрыклад, асвятленне, вентыляцыя, вентыляцыя, кандыцыяніраванне, прамысловыя працэсы і г.д.), каб сampвыкарыстання, якія могуць мець некалькі аб'ектаў з цэнтралізаванай сістэмай кіравання.

Прамы 3

Гэты сцэнар вельмі падобны на сцэнар Direct 1. Галоўнае адрозненне ў тым, што VEN ствараецца непасрэдна ў рэсурсе і кантролеры яго загрузкі. У гэтым выпадку сігналы DR адпраўляюцца непасрэдна на рэсурс і кантролер яго загрузкі. У гэту катэгорыю трапляе так званы сцэнарый "цаны на прылады". напрыкладamples будзе ўключаць у сябе любы кантролер нагрузкі, такі як HVAC (г.зн. тэрмастат), які мае ўбудаваны VEN, які здольны ўзаемадзейнічаць непасрэдна з аб'ектамі VTN на баку сеткі.

Прамы 4

Гэта камбінацыя сцэнарыяў Direct 1 і Direct 2. Галоўнае адрозненне заключаецца ў тым, што некалькі VEN звязаны з адным складаным рэсурсам, які складаецца з некалькіх актываў з уласнымі кантролерамі нагрузкі. Кожны з кантролераў нагрузкі, якія ўваходзяць у склад Compound Resource, можа быць звязаны з розным VEN. Звярніце ўвагу, што ўсе VEN будуць знаходзіцца пад кантролем той жа партыі рэсурсаў, якая валодае рэсурсам Compound. Гэты сцэнар існуе для таго, каб садзейнічаць інфраструктурам з боку попыту, якія маюць складаныя рэсурсы, але не маюць цэнтралізаванай BMS, як сцэнар Direct 2. напрыкладamples можа ўключаць будынкі з рознымі кантролерамі нагрузкі на кожным паверсе, але без цэнтралізаванай BMS, або campвыкарыстоўвае з рознымі кантролерамі ў кожным будынку, але не campнам шырокі кантролер. Паколькі з пункту гледжання ўдзельніка праграмы DR, у праграме зарэгістраваны толькі адзін рэсурс, калі ён хоча адправіць сігнал DR рэсурсу, ён можа проста адправіць тыя ж сігналы кожнаму з прызначаных VEN, якія былі звязаны з рэсурсам.

Вядоўца 1

У гэтым сцэнарыі ёсць пасярэднік, які спрыяе ўзаемадзеянню паміж удзельнікам праграмы DR і рэсурсамі. Звычайна бок-пасярэднік працуе ад імя боку рэсурсаў, каб дапамагчы ім кіраваць іх рэсурсамі. Бакі рэсурсаў маюць прамыя адносіны з удзельнікам праграмы DR і залічваюць свае ўласныя рэсурсы ў праграмы DR. Такім чынам партыя праграмы DR viewкожны з удзельнікаў рэсурсаў як асобны рэсурс і можа ўзаемадзейнічаць з імі індывідуальна. Роля боку-пасярэдніка заключаецца ў тым, каб выступаць у якасці прамежкавага звяна для ўсіх узаемадзеянняў, звязаных з OpenADR, такім чынам, VEN ствараецца ў інфраструктуры пасярэдніка-пасрэдніка. Такая інфраструктура часта з'яўляецца воблачнымі базамі і прапануецца бакам рэсурсаў як праграмнае забеспячэнне як паслуга (SaaS). Калі VEN пасярэдніка прымае сігнал DR, можа адбыцца шэраг розных дзеянняў, уключаючы перанакіраванне сігналу DR да адпаведнага рэсурсу і, магчыма, рэалізацыю нейкай логікі DR і адпраўку каманд кіравання нагрузкай на кантролер нагрузкі кожнага рэсурсу. напрыкладampфайлы гэтага сцэнара ўключаюць:

• Пастаўшчыкі, якія кіруюць аб'ектамі для буйных камерцыйных сетак, такіх як буйныя рознічныя гандляры.
• Пасярэднікі прамысловага кантролю.
• Энергасэрвісныя кампаніі (ESCO)
• Воблачныя сістэмы кіравання прыборамі і прыладамі, такія як новыя пастаўшчыкі разумных камунікацыйных тэрмастата.

Агрэгатар 1

Гэты сцэнар падобны да сцэнарыя пасярэдніка. Галоўнае адрозненне заключаецца ў тым, што партыя-агрэгатар мае адносіны з партыяй праграмы DR у адрозненне ад бакоў-рэсурсаў. Бок-агрэгатар аб'ядноўвае некалькі актываў кліентаў у адзін рэсурс, які ён рэгіструе ў праграмах DR. Удзельнік праграмы DR не можа бачыць асобныя актывы, якімі кіруе агрэгатар. Як і ў выпадку з пасярэднікам, агрэгатар мае ўласную інфраструктуру, дзе ствараецца асобнік VEN. Розніца ў тым, што пры атрыманні сігналу DR ён спасылаецца на адзін рэсурс, а агрэгатар рэалізуе нейкую логіку DR для ўсіх актываў у сваім партфелі для дасягнення мэтаў, указаных у сігнале DR.

 

Сцэнар разгортвання і адлюстраванне праграмы DR

У табліцы ніжэй паказваецца, якія сцэнарыі разгортвання найбольш распаўсюджаныя для канкрэтнай праграмы хуткага апынення.

	Сцэнар разгортвання
DR шаблон	Прамы 1, 2, 3, 4	Вядоўца 1	Агрэгатар 1
Праграма cpp	∆	∆
Праграма таргоў па ёмістасці			∆
Жылы тэрмастат праграма		∆
Хуткая адпраўка DR			∆
Праграма DR для электрамабіляў (EV).	∆	∆
Праграма размеркаваных энергетычных рэсурсаў (DER) DR	∆	∆

Выбар шаблону праграмы DR

Ніжэй прыведзены набор пытанняў, якія маюць дачыненне да любой камунальнай кампаніі, якая збіраецца ўкараніць новую праграму DR. Гэта не павінна быць усёабдымнай, але ўяўляе некаторыя з найбольш актуальных пытанняў. Мэта гэтых пытанняў - дапамагчы ўтылітам знайсці адпаведны набор шаблонаў праграм DR.

Пытанне: Чаму вы хочаце зрабіць DR? Якія ўмовы сеткі або эксплуатацыйныя праблемы вы спрабуеце змякчыць з дапамогай DR?

Гэта, безумоўна, самае важнае пытанне, якое ляжыць у аснове агульных патрабаванняў і мэтаў, якіх павінна дасягнуць праграма DR. Адказ на гэтае пытанне вызначае, як нагрузка з боку попыту праfile Мяркуецца, што фарміруецца праграмай DR. Усе астатнія патрабаванні вынікаюць з адказу на гэтае пытанне.

• Вы спрабуеце згаліць пікі?
• Хочаш набіць качыны жывот?
• Вы спрабуеце застрахавацца ад спотавай цаны на электраэнергію?
• Вас турбуе надзейнасць сеткі?
• Вы спрабуеце захаваць актывы сеткі?
• І г.д. і г.д.

Прыведзеная ніжэй табліца дае дадатковы кантэкст для матывацыі жадання распрацаваць праграму DR

Надзейнасць і бяспека сеткі	Частата і Voltage Стабільнасць
	Адэкватнасць рэсурсаў
	Пікавая ёмістасць
	Rampінж
	Непрадбачаныя абставіны
Закупка энергіі	Цэны спотавага рынку
	Цэнавы арбітраж
Кіраванне актывамі	Прадухіленне пашкоджанняў
	Скарачэнне тэхнічнага абслугоўвання
	Падаўжэнне тэрміну службы
Кіраванне ёмістасцю	Эканамічныя выгады
	Кіраванне надзвычайнымі сітуацыямі
Экалагічныя	Негават
	Чыстая энергія

Пытанне: Ці існуе ўжо існуючая праграма DR або тарыф для гэтай праграмы?

• Часта правілы праграмы выразна прапісаны ў тарыфе.

Пытанне: На які сегмент рынку попыту вы арыентуецеся з дапамогай гэтай праграмы?

Гэта можа дапамагчы вызначыць арыентацыю рэсурсаў у падзеі і тып сігналу.

• Жылая
• Вялікі C&I
• Малы C&I
• Сельская гаспадарка
• Водная гаспадарка
• Электрычныя транспартныя сродкі
• І г.д., і г.д

Пытанне: Вы спрабуеце арыентавацца на пэўныя тыпы нагрузак?

• Тэрмастаты
• Электрамабілі
• Ag помпы
• г.д.

Пытанне: Якая ваша мадэль разгортвання?

Адказ на гэтае пытанне можа паўплываць на тое, як вызначаюцца рэсурсы ў праграме, і вызначыць, як гэтыя рэсурсы арыентуюцца на мерапрыемствы.

• Напрамую да кліентаў
• Праз пасярэднікаў, такіх як агрэгатары або пасярэднікі
• Кліент нясе адказнасць за набыццё і разгортванне ўласнага абсталявання VEN?
• г.д.

Пытанне: на якім узроўні канкрэтнасці вы хочаце ўзаемадзейнічаць з нагрузкамі з боку попыту?

Гэтае пытанне ў некаторай ступені звязана з мадэллю разгортвання і вызначае, як вызначаюцца і нацэлены рэсурсы ў праграме. Гэта адно з самых важных і, магчыма, складаных пытанняў.

• Узаемадзейнічайце з кожным асобным рэсурсам
• Узаемадзейнічайце праз пасярэдніка або агрэгатар без указання рэсурсаў, якія стаяць за імі
• Узаемадзейнічайце праз пасярэдніка або агрэгатар І ўкажыце, якія рэсурсы за імі павінны быць накіраваны
• Выкарыстоўвайце месцазнаходжанне як атрыбут для ўказання рэсурсаў
• Выкарыстоўвайце пэўны механізм групоўкі, вызначаны ўтылітай, каб вызначыць рэсурсы
• Нацэльвайце асобныя актывы, такія як тэрмастаты
• Узаемадзейнічайце без рэсурсаў і проста транслюйце падзеі DR
• г.д.

Пытанне: які шаблон узаемадзеяння вы хочаце выкарыстоўваць, каб паўплываць на нагрузку кліентаўfiles?

Гэтае пытанне вызначае тып сігналаў DR, якія будуць адпраўляцца ўдзельнікам праграмы.

• Стымулы (напрыклад, дынамічнае цэнаўтварэнне)
• Адпраўка грузаў (напрыклад, дапаможныя паслугі)
• Прамы кантроль нагрузкі
• Агульны сігнал падзеі
• г.д.

Пытанне: Якія агульныя атрыбуты планавання рэсурсаў праграмы?

• Даты і час, калі падзеі могуць называцца
• Перыядычнасць падзей
• Працягласць мерапрыемстваў
• Дапушчальныя затрымкі для распаўсюджвання падзей
• г.д.

Пытанне: Як вызначаецца наяўнасць рэсурсаў у праграме?

• Па строгіх правілах праграмы
• У рамках некаторага працэсу вылучэння або таргоў, зробленага рэсурсам
• Дазволены ўключэнне/адключэнне?
• г.д.

Q: Які тып бачнасці вам патрэбны для прадукцыйнасці рэсурсу?

Гэта вельмі шырокае пытанне, якое вызначае тып інфармацыі, якая паступае з рэсурсаў праграмы DR. У цэлым гэта вызначае тып неабходных справаздач.

• Online / Offline
• Выкарыстанне (бягучае і/або гістарычнае)
• Патэнцыял рэагавання на нагрузку
• Даступнасць нагрузкі
• Стан загрузкі/актыву (бягучы і/або гістарычны)
• І г.д., і г.д.

Шаблоны праграм рэагавання на попыт

Праграма крытычнага пікавага цэнаўтварэння (CPP)

Характарыстыкі праграмы CPP DR

Загрузіць Profile Мэта	- Пікавае зніжэнне попыту
Асноўныя драйвера	-Зніжэнне капітальных выдаткаў і зніжэнне выдаткаў на энергію
Апісанне праграмы	Калі камунальныя прадпрыемствы назіраюць або чакаюць высокія аптовыя рынкавыя цэны або аварыйныя ўмовы ў энергасістэме, яны могуць выклікаць крытычныя падзеі ў вызначаны перыяд часу (напрыклад, 3:6-XNUMX:XNUMX у гарачы летні працоўны дзень), цана на электраэнергію ў гэтыя перыяды часу істотна падняў.
Заахвочванне кліентаў	Кліентам могуць быць прапанаваны зніжаныя цэны на энергію ў непікавы час у якасці стымулу для ўдзелу ў праграме.
Стаўка Дызайн	CPP - гэта цэнавая праграма з павышэннем ставак падчас крытычных пікаў энергаспажывання. Звычайна стаўкі CPP з'яўляюцца сумай або множнікам да фіксаваных, шматузроўневых або базавых ставак TOU.
Мэтавы кліент	-Residential або C&I
Мэтавая нагрузка	-Любая
Абавязковая ўмова	-Кліент павінен мець інтэрвальны ўлік -Кліенты C&I, магчыма, павінны адпавядаць крытэрам попыту
Тэрмін праграмы	-Звычайна ахоплівае месяцы года, калі адбываецца пік спажывання энергіі, хоць у некаторых выпадках можа быць круглы год.
Абмежаванні падзей	-Звычайна з панядзелка па пятніцу, за выключэннем святочных дзён, звычайна дапускаюцца падзеі паслядоўнага дня
Дні мерапрыемстваў	-Звычайна ад 9 да 15 у год
Працягласць мерапрыемства	- Звычайна на працягу фіксаванага перыяду часу для ўсіх падзей, які складае ад 4 да 6 гадзін у перыяд сутак з самым высокім спажываннем энергіі.
Апавяшчэнне	-Звычайна на дзень наперад
Opt Паводзіны	- Звычайна ад кліентаў не патрабуецца ўдзел у мерапрыемствах
Атэстацыя Падзеі	— Як правіла, ніякага

Характарыстыкі OpenADR для праграм CPP

Сігналы падзей	–ПРОСТЫ сігнал з узроўнямі ад 1 да 3, якія супастаўляюцца з уплывам CPP на цану. Калі праграма CPP мае адзіны кампанент цэнаўтварэння, яго трэба супаставіць з узроўнем 1. Для праграм CPP з некалькімі кампанентамі цэнаўтварэння найменшы кампанент кошту павінен быць супастаўлены з узроўнем 1, а іншыя кампаненты кошту - узроўнямі 2 і 3 ва ўсё большай ступені. уплыву цэнаўтварэння. -Калі разгортванне падтрымлівае B profile VEN, у дадатак да сігналу SIMPLE можа быць уключаны сігнал ELECTRICITY_PRICE у карыснай нагрузцы з тыпам priceRelative, priceAbsolute або priceMultiplier у залежнасці ад характару праграмы. Гл. Дадатак А для прыкладуampлес.
Выбраць адказы	-VTN адпраўка падзей павінен усталяваць элемент oadrResponseRequired на «заўсёды», патрабуючы ад VEN адказу optIn або optOut -Паколькі ўдзел у праграме CPP з'яўляецца «максімальным намаганнем», няма ніякага фармальнага значэння ўключэння або адмовы, акрамя ветлівага ўказання наяўнасці намеру ўдзельнічаць. Мы рэкамендуем гэта VENs адказваюць optIn, калі толькі кліент не прыняў нейкія спецыяльныя дзеянні. - Карысная нагрузка oadrCreateOpt звычайна не выкарыстоўваецца для кваліфікацыі рэсурсаў, якія ўдзельнічаюць у падзеях.
Дэскрыптар падзеі	- Падзея прыярытэт павінен быць усталяваны на 1 калі правіламі праграмы або канфігурацыяй VTN не вызначана іншае –Тэставыя падзеі звычайна не выкарыстоўваюцца з праграмамі CPP. Аднак, калі яны дазволены, элемент testEvent павінен быць усталяваны ў "true", каб паказаць тэставую падзею. Калі ў гэтым элеменце патрабуецца дадатковая наладжаная інфармацыя, яна можа ісці за словам "true", аддзеленым прабелам з гэтай дадатковай інфармацыяй.
Актыўны перыяд падзеі	– eiRampUp, eiRecovery, элементы допуску звычайна не выкарыстоўваюцца
Базавыя лініі	–Базавыя паказчыкі звычайна не ўключаюцца ў карысную нагрузку падзеі
Таргетынг падзей	-Праграмы CPP звычайна не робяць адрозненняў паміж рэсурсамі для дадзенага кліента. Таргетынг звычайна вызначае venID, паказваючы, што ўсе рэсурсы, звязаныя з VEN, павінны ўдзельнічаць, або спіс усіх ідэнтыфікатараў рэсурсаў звязаны з ВЕН.
Службы справаздачнасці	–Тэлеметрычныя справаздачы звычайна не выкарыстоўваюцца паколькі гэта не з'яўляецца абсалютна неабходным для праграм CPP. Звярніцеся да Дадатку B, напрыкладampфайлы справаздач пілотных кампаній, якія могуць быць дастасавальныя да гэтага тыпу праграм.

Opt Services	–Выкарыстанне сэрвісу Opt каб паведаміць графікі часовай даступнасці звычайна не будзе выкарыстоўвацца у рамках праграмы CPP. Тым не менш, некаторыя разгортванні могуць выкарыстоўваць гэтую паслугу для захавання даступных дзён падзей для кліентаў, якія паказваюць на адсутнасць даступнасці.
Рэгістрацыйныя паслугі	Інтэрвалы апытання запытваецца VTN для тыповых праграм CPP на дзень наперад не патрабуецца часцей, чым раз у гадзіну. Аднак выкарыстанне апытання для вызначэння сэрцабіцця можа запатрабаваць больш частага апытання.

Праграма таргоў па ёмістасці

Характарыстыкі праграмы Capacity Bidding DR

Загрузіць Profile Мэта	- Пікавае зніжэнне попыту і дастатковасць рэсурсаў
Асноўныя драйвера	-Зніжэнне капітальных выдаткаў і зніжэнне выдаткаў на энергію
Апісанне праграмы	Праграма таргоў па магутнасці выкарыстоўваецца ISO/камунальнымі службамі для атрымання загадзя замоўленых аб'ёмаў адгрузкі ад агрэгатараў або кліентаў, якія самі аб'ядноўваюцца. Гэтая папярэдне зададзеная магутнасць адключэння нагрузкі выкарыстоўваецца ISO/камунальнымі службамі, калі яны назіраюць або чакаюць высокія аптовыя рынкавыя цэны, аварыйныя ўмовы ў энергасістэме або як частка звычайнага выкарыстання энергетычных рэсурсаў, выклікаючы падзеі DR на працягу вызначанага перыяду часу.   Звярніце ўвагу, што кожны агрэгатар звычайна нясе адказнасць за распрацоўку ўласнай праграмы рэагавання на попыт, а таксама за прыцягненне кліентаў і апавяшчэнне аб падзеях, каб выканаць абавязацельствы па прапускной здольнасці, узятыя ў рамках гэтай праграмы.
Заахвочванне кліентаў	Агрэгатары/кліенты атрымліваюць два тыпу стымулаў. Па-першае, яны атрымліваюць аплату за прапускную здольнасць за ўтрыманне пэўнай колькасці аб'ёмаў разгрузкі, даступных для падзей DR на працягу будучага часовага акна. Па-другое, калі падзея выклікаецца ў будучым часовым акне, можа быць зроблена аплата энергіі за скід нагрузкі на працягу ўсёй падзеі.
Стаўка Дызайн	Удзельнікі праграмы робяць заяўку на «намінацыю ёмістасці», у якой указваюць магутнасць падзення нагрузкі, якую яны гатовыя трымаць як даступную ў будучым часовым акне. Стаўка можа таксама ўключаць у сябе стымул, які агрэгатар/кліент гатовы прыняць за памяншэнне нагрузкі ніжэй базавага значэння. На рынках камунальных паслуг абавязацельствы па магутнасці звычайна прыпадаюць на наступны каляндарны месяц, хаця на рынках ISO выкарыстоўваюцца значна больш працяглыя часовыя рамкі. У рамках намінацыі ёмістасці кліент можа мець магчымасць выбіраць паміж шэрагам характарыстык, уключаючы апавяшчэнне на дзень наперад або дзень паведамлення і акно працягласці падзеі (напрыклад, 1-4 гадзіны, 2-6 гадзін, …). За гэтае папярэдняе абавязацельства кліенту праводзіцца аплата магутнасці, нават калі на працягу часовага акна не выклікаюцца падзеі. Калі падзея выклікаецца падчас часовага акна, кліент можа атрымаць аплату за энергію за скід нагрузкі ў адносінах да базавага ўзроўню, аднак могуць прымяняцца штрафныя санкцыі, калі на момант выкліку падзеі пастаўлена менш, чым папярэдне запланаваная магутнасць скіду нагрузкі.
Мэтавы кліент	-Агрэгатары і кліенты C&I з самаагрэгацыяй
Мэтавыя нагрузкі	– Любы

Абавязковая ўмова	-Кліент павінен мець інтэрвальны ўлік -Кліенты C&I, магчыма, павінны адпавядаць патрабаванням або крытэрам стаўкі
Тэрмін праграмы	-У любы час
Абмежаванні падзей	-Звычайна з панядзелка па пятніцу, за выключэннем святочных дзён, звычайна дапускаюцца падзеі паслядоўнага дня
Дні мерапрыемстваў	- Звычайна максімум 30 гадзін у месяц
Працягласць мерапрыемства	- Звычайна на працягу фіксаванага часовага акна для ўсіх падзей падчас найбольшага спажывання энергіі ў суткі.). Працягласць мерапрыемства вар'іруецца ў залежнасці ад патрабаванняў заказчыка з перавагамі ў дыяпазоне ад 1 да 8 гадзін або ў адпаведнасці з дызайнам праграмы
Апавяшчэнне	- На дзень наперад або на дзень у залежнасці ад пераваг заказчыка або дызайну праграмы
Opt Паводзіны	-Звычайна кліенты выбіраюць удзел у мерапрыемствах, улічваючы, што ў іх ёсць папярэдне абазначаная магутнасць разгрузкі.
Атэстацыя Падзеі	- Звычайна два ў год (тэст)

Характарыстыкі OpenADR для праграм стаўкі магутнасці

Сігналы падзей	–ПРОСТЫ сігнал з узроўнямі ад 1 да 3, якія супастаўляюцца з колькасцю страты нагрузкі. Калі праграма падтрымлівае толькі адзін узровень зняцця нагрузкі, яго трэба супаставіць з узроўнем 1. Для праграм з некалькімі ўзроўнямі зняцця нагрузкі найменшае змяненне звычайнай працы павінна быць адлюстравана на ўзроўні 1, а значэнні зняцця нагрузкі - на ўзроўні 2 і 3 пры павелічэнні ступені падзення нагрузкі. -Калі разгортванне падтрымлівае B profile VEN, у дадатак да сігналу SIMPLE можа быць уключаны сігнал BID_LOAD і/або BID_PRICE у карыснай нагрузцы з тыпамі сігналаў зададзенага значэння і цаны, а таксама адзінак магутнасці Рэальная і валюта за кВт адпаведна. BID_LOAD будзе адлюстроўваць запытаную нагрузку, спушчаную да сумы магутнасці, заяўленую агрэгатарам/кліентам, а BID_PRICE будзе адлюстроўваць заахвочвальную стаўку агрэгатара/кліента. Гл. Дадатак А для прыкладуampлес.
Выбраць адказы	-VTN адпраўка падзей павінен усталяваць элемент oadrResponseRequired на «заўсёды», патрабуючы ад VEN адказу optIn або optOut -Паколькі агрэгатары/кліенты маюць папярэдне замацаваны патэнцыял VEN павінны адказаць optIn. Адмова можа быць адпраўлена ў адказ на падзею, але гэта неафіцыйная прыкмета даступнасці, а не фармальная адмова ад падзеі. -The Карысная нагрузка oadrCreateOpt звычайна не выкарыстоўваецца каб кваліфікаваць рэсурсы, якія ўдзельнічаюць у падзеях, бо звычайна нагрузка ўяўляе сабой адзіную сукупную сутнасць.
Дэскрыптар падзеі	- Падзея прыярытэт павінен быць усталяваны на 1 калі правіламі праграмы або канфігурацыяй VTN не вызначана іншае –Можна выкарыстоўваць тэставыя падзеі з праграмамі Capacity Bidding. Калі яны дазволены, элемент testEvent павінен быць усталяваны ў "true", каб паказаць тэставую падзею. Калі ў гэтым элеменце патрабуецца дадатковая наладжаная інфармацыя, яна можа ісці за словам "true", аддзеленым прабелам з гэтай дадатковай інфармацыяй.
Актыўны перыяд падзеі	– eiRampUp, eiRecovery, элементы допуску звычайна не выкарыстоўваюцца
Базавыя лініі	–Базавыя паказчыкі звычайна не ўключаюцца ў карысную нагрузку падзеі паколькі гэтыя даныя звычайна недаступныя на момант ініцыяцыі падзеі. Аднак як камунальныя службы, так і агрэгатары/кліенты будуць view уключэнне базавай інфармацыі ў падзеі як карыснай.
Таргетынг падзей	-Праграмы таргоў па ёмістасці звычайна не робяць адрозненняў паміж рэсурсамі для дадзенага кліента. Таргетынг звычайна вызначае venID, паказваючы, што ўсе рэсурсы, звязаныя з VEN, павінны ўдзельнічаць, або ўключае resourceID, які прадстаўляе сукупную нагрузку звязаны з ВЕН.
Службы справаздачнасці	Праграмы ISO Capacity Bidding звычайна патрабуюць справаздач TELEMETRY_USAGE з кропкамі дадзеных powerReal. Глядзіце прampу дадатку А. Тэлеметрычная справаздачнасць для таргоў магутнасцю камунальнай службы звычайна не патрабуецца. Звярніце ўвагу, што для тэлеметрычнай справаздачнасці патрабуецца B profile VENs. Звярніцеся да Дадатку B, напрыкладampфайлы справаздач пілотных кампаній, якія могуць быць дастасавальныя да гэтага тыпу праграм.
Opt Services	–Выкарыстанне сэрвісу Opt каб паведаміць графікі часовай даступнасці звычайна не будзе выкарыстоўвацца у рамках праграмы Capacity Bidding, паколькі кліенты папярэдне абавязваліся аб іх даступнасці. Тым не менш, гэтая паслуга можа быць карыснай як неафіцыйны спосаб для ўдзельнікаў пазначыць адсутнасць даступнасці па змякчальных прычынах, такіх як няспраўнасць абсталявання.
Рэгістрацыйныя паслугі	Інтэрвалы апытання запытваецца VTN для тыповых праграм на дзень наперад не патрабуецца часцей, чым раз у гадзіну. Аднак пры выкарыстанні апытання для вызначэння сардэчнага рытму або дзённых праграм можа спатрэбіцца больш частае апытанне.

Праграму тэрмастата для жылых памяшканняў

Гэтая праграма з'яўляецца рэпрэзентатыўнай праграмай Direct Load Control (DLC), дзе сігнал Demand Response непасрэдна змяняе паводзіны рэсурсаў для зняцця нагрузкі без узроўню абстракцыі паміж атрыманнем сігналу і выкананнем канкрэтнага дзеяння па зняцці нагрузкі.

Характарыстыкі праграмы тэрмастата DR для жылых памяшканняў

Загрузіць Profile Мэта	- Пікавае зніжэнне попыту
Асноўныя драйвера	-Зніжэнне капітальных выдаткаў і зніжэнне выдаткаў на энергію
Апісанне праграмы	-Калі камунальныя службы назіраюць або чакаюць высокія аптовыя рынкавыя цэны або аварыйныя ўмовы ў энергасістэме, яны могуць ініцыяваць падзею, якая змяняе паводзіны праграмуемага камунікацыйнага тэрмастата (PCT) кліента на працягу пэўнага перыяду часу (напрыклад, 3:6-XNUMX:XNUMX на гарачым летні працоўны дзень), каб паменшыць спажыванне энергіі. - Змяненне паводзін PCT у адказ на падзею можа быць простым змяненнем зададзенага значэння тэмпературы на працягу ўсяго мерапрыемства або больш складаным наборам змяненняў, уключаючы папярэдняе астуджэнне, якія мінімізуюць уплыў падзеі на камфорт кліента. ўзровень.
Заахвочванне кліентаў	-Стымулы прымаюць дзве агульныя формы. Па-першае, кліентам можа быць прадастаўлены бясплатны PCT або прапанаваны скідкі/зніжкі на набытыя кліентамі PCT у якасці стымулу для ўдзелу ў праграме DR. Па-другое, кліенты могуць атрымліваць пастаянную гадавую стыпендыю за працяг рэгістрацыі ў праграме. Менш распаўсюджанымі будуць пастаянныя стымулы, якія выплачваюцца кліентам на падставе фактычнага зніжэння энергіі падчас мерапрыемстваў.
Стаўка Дызайн	-У першую чаргу гэта праграма стымулявання, у якой кліенты атрымліваюць са зніжкай або бясплатна PCT за рэгістрацыю ў праграме DR. Некаторыя праграмы могуць выплачваць перыядычную стыпендыю або заахвочвальныя выплаты на аснове зніжэння энергіі падчас мерапрыемстваў.
Мэтавы кліент	-Жылы
Мэтавая нагрузка	-HVAC
Абавязковая ўмова	-Як правіла, няма, паколькі кліенты атрымліваюць PCT як частку рэгістрацыі ў праграме
Тэрмін праграмы	-Звычайна ахоплівае месяцы года, калі адбываецца пік спажывання энергіі, хоць у некаторых выпадках можа быць круглы год.
Абмежаванні падзей	-Звычайна з панядзелка па пятніцу, за выключэннем святочных дзён, звычайна дапускаюцца падзеі паслядоўнага дня.
Дні мерапрыемстваў	-Звычайна ад 9 да 15 у год
Працягласць мерапрыемства	-Падзеі могуць адбыцца ў любы час, працягласцю ад 2 да 4 гадзін, хаця звычайна падзеі адбываюцца ў час сутак з найбольшым спажываннем энергіі.
Апавяшчэнне	-Звычайна на дзень наперад, хоць некаторыя праграмы могуць мець час паведамлення да 10 хвілін.
Opt Паводзіны	- Кліенты не абавязаны ўдзельнічаць у мерапрыемствах, аднак яны будуць аўтаматычна падключаны да мерапрыемстваў, калі толькі яны не прымуць меры, каб адмяніць мерапрыемства або ўручную наладзіць тэмпературу падчас мерапрыемства.
Атэстацыя Падзеі	— Як правіла, ніякага

Характарыстыкі OpenADR для праграм тэрмастата для жылых памяшканняў

Сігналы падзей	–ПРОСТЫ сігнал з узроўнямі ад 1 да 3, якія супастаўляюцца са змяненнем зрушэння зададзенага значэння тэмпературы PCT або працэнтаў тэрмастатычнага цыклуtagе . Калі праграма жылога тэрмастата мае адзіны кампанент зрушэння/цыклічнага зруху, яго трэба супаставіць з узроўнем 1. Для праграм з некалькімі кампанентамі зрушэння/зменнага рэжыму найменшае змяненне звычайнай працы павінна быць адлюстравана на ўзроўні 1 з іншымі значэннямі зрушэння/зменнага цыклу супастаўляюцца з узроўнямі 2 і 3 у залежнасці ад уздзеяння павелічэння нагрузкі. -Калі разгортванне падтрымлівае B profile VEN, у дадатак да сігналу SIMPLE можа быць уключаны сігнал LOAD_CONTROL у карыснай нагрузцы з тыпам x-loadControlLevelOffset або x-loadControlCapacity для ўказання жаданага зрушэння зададзенага значэння тэмпературы або тэрмастатычнага цыклу ў працэнтахtagе адпаведна. Адноўлена, што а адзінка тыпу "тэмпература", якая выкарыстоўваецца ў карысных нагрузках з выкарыстаннем x-loadControlLevelOffset signalType каб пазначыць градусы Цэльсія або Фарэнгейта для зрушэння. Гл. Дадатак А для прыкладуampлес.
Выбраць адказы	-VTN адпраўка падзей павінен усталяваць элемент oadrResponseRequired на «заўсёды», патрабуючы ад VEN адказу optIn або optOut – VENs павінны адказаць optIn, калі кліент не прыняў нейкае канкрэтнае дзеянне. -The Карысная нагрузка oadrCreateOpt можа выкарыстоўвацца VEN кваліфікаваць удзел рэсурсаў у мерапрыемстве. Напрыклад, падзея можа быць накіравана на resourceID двух тэрмастатаў, якія кіруюць асобнымі сістэмамі вентыляцыі і вентыляцыі. Калі кліент вырашыць, што ў мерапрыемстве можа ўдзельнічаць толькі адна з сістэм ацяплення, вентыляцыі і кандыцыянавання, гэта будзе перададзена VTN з дапамогай карыснай нагрузкі oadrCreateOpt. Звярніце ўвагу, што карысная нагрузка oadrCreateOpt падтрымліваецца толькі B profile VENs
Дэскрыптар падзеі	- Падзея прыярытэт павінен быць усталяваны на 1 калі правіламі праграмы або канфігурацыяй VTN не вызначана іншае –Тэставыя падзеі звычайна не выкарыстоўваюцца з праграмамі для жылых тэрмастатаў. Аднак, калі яны дазволены, элемент testEvent павінен быць усталяваны ў "true", каб паказаць тэставую падзею. Калі ў гэтым элеменце патрабуецца дадатковая наладжаная інфармацыя, яна можа ісці за словам "true", аддзеленым прабелам з гэтай дадатковай інфармацыяй.
Актыўны перыяд падзеі	–Рандамізацыя звычайна выкарыстоўваецца для жылых тэрмастатаў з выкарыстаннем элемента допуску – eiRampЭлементы Up і eiRecovery звычайна не выкарыстоўваюцца
Базавыя лініі	–Базавыя паказчыкі звычайна не ўключаюцца ў карысную нагрузку падзеі
Таргетынг падзей	- Праграмы тэрмастата для жылых памяшканняў накіраваны на рэсурсы HVAC, якія кантралююцца PCT. Таргетынг звычайна вызначае resourceID сістэм вентыляцыі і кандыцыяніравання (г. зн. тэрмастата), звязаных з VEN або venID з мэтавым класам прылады сігналу падзеі, усталяваным у Тэрмастат
Службы справаздачнасці	–Тэлеметрычныя справаздачы звычайна не выкарыстоўваюцца паколькі гэта не з'яўляецца абсалютна неабходным для праграм тэрмастата для жылых памяшканняў Звярніцеся да Дадатку B, напрыкладampфайлы справаздач пілотных кампаній, якія могуць быць дастасавальныя да гэтага тыпу праграм.
Opt Services	–Выкарыстанне сэрвісу Opt каб паведаміць графікі часовай даступнасці звычайна не будзе выкарыстоўвацца у рамках праграмы CPP.
Рэгістрацыйныя паслугі	Інтэрвалы апытання запытваецца VTN для тыповых праграм тэрмастата для жылых памяшканняў на дзень наперад не патрабуецца часцей, чым раз у гадзіну. Аднак выкарыстанне апытання для выяўлення сардэчнага рытму можа запатрабаваць больш частага апытання, як і праграмы тэрмастата для жылых памяшканняў са значна меншым часам паведамлення.

Хуткая адпраўка DR

Характарыстыкі праграмы Fast DR Dispatch

Загрузіць Profile Мэта	-Распасылка рэсурсаў для дасягнення адказу на нагрузку ў «рэальным часе»
Асноўныя драйвера	-Надзейнасць сеткі і дапаможныя паслугі
Апісанне праграмы	Fast DR выкарыстоўваецца ISO/ўтылітамі для атрымання загадзя зафіксаванай рэакцыі на нагрузку ў «рэальным часе». Гэты загадзя зададзены адказ на нагрузку выкарыстоўваецца ISO/ўтылітамі, калі яны назіраюць за ўмовамі, якія патрабуюць неадкладных дзеянняў для падтрымання стабільнасці і цэласнасці сеткі. Рэальны час азначае, што рэсурсы звычайна адпраўляюцца з затрымкай ад 10 хвілін для рэсурсаў, якія выкарыстоўваюцца ў якасці рэзерву, да 2 секунд для рэсурсаў, якія выкарыстоўваюцца ў мэтах рэгулявання. Памер адказу на нагрузку павінен быць дастаткова вялікім, каб паўплываць на змякчэнне стану сеткі, і, такім чынам, рэсурсы звычайна вельмі вялікія і часта кіруюцца агрэгатарамі як часткай аб'яднанага рэсурсу. Мінімальныя памеры рэакцыі на нагрузку для рэсурсу, каб прэтэндаваць на ўдзел у дапаможных паслугах, звычайна складаюць каля 500 кВт, але для некаторых праграм могуць дасягаць 100 кВт. Звярніце ўвагу, што калі рэсурс выкарыстоўваецца ў якасці рэзерву, ён звычайна будзе патрабавацца для памяншэння (г.зн. зняцця) нагрузкі, але калі ён выкарыстоўваецца ў мэтах рэгулявання, ён можа быць накіраваны для павелічэння або памяншэння нагрузкі.
Заахвочванне кліентаў	Агрэгатары/кліенты звычайна атрымліваюць два тыпы стымулаў. Па-першае, яны атрымліваюць аплату за прыняцце і прадастаўленне пэўнай колькасці адказу нагрузкі, даступнага для падзей DR на працягу будучага часовага акна. Аб'ём адказу на нагрузку, часовае акно даступнасці і сума да аплаты звычайна ўсталёўваюцца агрэгатарам/заказчыкам. Па-другое, калі падзея выклікаецца на працягу будучага часовага акна, аплата залежыць ад колькасці адказу на нагрузку за час падзеі.
Стаўка Дызайн	Удзельнікі праграмы падаюць заяўку з указаннем рэакцыі на нагрузку, якую яны гатовыя зрабіць даступнай у будучым часовым акне. Стаўка звычайна таксама ўключае аплату, якую агрэгатар/кліент гатовы прыняць за адказ на нагрузку. На рынках камунальных паслуг/ISO заяўка звычайна падаецца альбо на наступны дзень, альбо ў дзень перыяду часу, на які бярэцца абавязацельства. У рамках іх кваліфікацыі і рэгістрацыі на рынках з рэсурсам звязаны розныя параметры прадукцыйнасці, такія як рamp хуткасць і мінімальныя і максімальныя межы працы. Такія параметры вызначаюць спосаб адпраўкі. Калі заяўка ўдзельніка прымаецца, кліенту можа быць зроблена аплата за яго папярэдняе абавязацельства, нават калі ў часовым акне не выклікана ніякіх падзей. Калі мерапрыемства праводзіцца ў часовым акне, кліент можа атрымаць дадатковыя выплаты за выступленне падчас мерапрыемства. Такія выплаты, заснаваныя на прадукцыйнасці, могуць грунтавацца на шэрагу фактараў, уключаючы колькасць энергіі, магутнасць, тое, наколькі дакладна рэсурс выконвае інструкцыі па адпраўцы, і аплату "прабегу", якая адлюстроўвае, наколькі моцна іх нагрузка праfile патрабавалася змяніць падчас мерапрыемства. Некаторыя з гэтых параметраў, такіх як энергія і магутнасць, могуць адносіцца да базавага ўзроўню.
Мэтавы кліент	-Агрэгатары і самаагрэгаваныя кліенты C&I
Мэтавыя нагрузкі	– Тыя, якія могуць рэагаваць на паведамленні ў рэжыме рэальнага часу.

Абавязковая ўмова	-Кліент павінен мець інтэрвальны ўлік -Павінен адпавядаць мінімальным патрабаванням да памеру для адказу нагрузкі -Павінен быць у стане рэагаваць на адпраўкі ў рэжыме рэальнага часу -Звычайна трэба пастаўляць тэлеметрыю ў рэжыме рэальнага часу, якая паказвае бягучую рэакцыю нагрузкі
Тэрмін праграмы	-У любы час
Абмежаванні падзей	-ніякага
Дні мерапрыемстваў	-ніякага
Працягласць мерапрыемства	-Звычайна кароткі (менш за 30 хвілін), але ў любым выпадку ніколі не будзе перавышаць часовае акно, якое ўдзельнік зрабіў даступным рэсурс падчас падачы заяўкі.
Апавяшчэнне	-ніякага
Opt Паводзіны	-Кліенты па змаўчанні прымаюць удзел у падзеях, улічваючы, што яны загадзя зафіксавалі адказ на нагрузку
Атэстацыя Падзеі	- Звычайна адзін раз у год (тэст)

Характарыстыкі OpenADR для праграм стаўкі магутнасці

Сігналы падзей	–ПРОСТЫ сігнал з узроўнямі ад 1 да 3, якія супастаўляюцца з велічынёй адказу нагрузкі. Калі праграма падтрымлівае толькі адзін узровень рэакцыі на нагрузку, яе трэба супаставіць з узроўнем 1. Для праграм з некалькімі ўзроўнямі рэакцыі на нагрузку найменшае змяненне звычайнай працы павінна быць супастаўлена з узроўнем 1, а значэнні паніжэння нагрузкі - на ўзроўні 2 і 3 пры павышэнні ступені рэакцыі на нагрузку. -Калі разгортванне падтрымлівае B profile VEN, у дадатак да сігналу SIMPLE можа быць уключана адпраўка ў выглядзе сігналу LOAD_DISPATCH у карыснай нагрузцы з тыпамі сігналаў зададзенага значэння або дэльта і адзінкамі PowerReal. Гэты сігнал уяўляе жаданую «рабочую кропку» нагрузкі і можа быць выражаны або як абсалютная колькасць мВт (г.зн. зададзенае значэнне) або некаторай адноснай колькасцю мВт (г.зн. дэльта) ад бягучай рабочай кропкі рэсурсаў. Гл. Дадатак А для прыкладуampлес.
Выбраць адказы	-VTN адпраўка падзей павінен усталяваць элемент oadrResponseRequired на «заўсёды», патрабуючы ад VEN адказу optIn або optOut -Паколькі агрэгатары/кліенты маюць папярэдне замацаваны патэнцыял VEN павінны адказаць optIn. Адмова можа быць адпраўлена ў адказ на падзею, але гэта неафіцыйная прыкмета даступнасці, а не фармальная адмова ад падзеі. -The Карысная нагрузка oadrCreateOpt звычайна не выкарыстоўваецца каб кваліфікаваць рэсурсы, якія ўдзельнічаюць у падзеях, бо звычайна нагрузка ўяўляе сабой адзіную сукупную сутнасць.
Дэскрыптар падзеі	- Падзея прыярытэт павінен быць усталяваны на 1 калі правіламі праграмы або канфігурацыяй VTN не вызначана іншае –Можна выкарыстоўваць тэставыя падзеі, асабліва падчас рэгістрацыі і кваліфікацыі рэсурсу. Калі яны дазволены, элемент testEvent павінен быць усталяваны ў "true", каб паказаць тэставую падзею. Калі ў гэтым элеменце патрабуецца дадатковая наладжаная інфармацыя, яна можа ісці за словам "true", аддзеленым прабелам з гэтай дадатковай інфармацыяй.
Актыўны перыяд падзеі	– Элементы допуску не выкарыстоўваюцца. eiRampПерыяды Up і eiRecovery звычайна з'яўляюцца часткай параметраў рэсурсаў пры іх рэгістрацыі і могуць выкарыстоўвацца. З-за характару адпраўкі яны могуць быць адкрытымі і, такім чынам, можа не быць часу заканчэння мерапрыемства.
Базавыя лініі	–Базавыя паказчыкі звычайна не ўключаюцца ў карысную нагрузку падзеі паколькі гэтыя даныя звычайна недаступныя ў момант ініцыяцыі падзеі. Аднак як камунальныя службы, так і агрэгатары/кліенты будуць view уключэнне базавай інфармацыі ў падзеі як карыснай.
Таргетынг падзей	-Праграмы таргоў па ёмістасці звычайна не робяць адрозненняў паміж рэсурсамі для дадзенага кліента. Таргетынг звычайна вызначае venID, паказваючы, што ўсе рэсурсы, звязаныя з VEN, павінны ўдзельнічаць, або ўключае resourceID, які прадстаўляе сукупную нагрузку звязаны з ВЕН.
Службы справаздачнасці	Праграмы хуткага аднаўлення звычайна патрабуюць справаздач TELEMETRY_USAGE з кропкамі дадзеных powerReal. Справаздача аб выкарыстанні адлюстроўвае бягучую працоўную кропку рэсурсаў і выкарыстоўваецца ўтылітай/ISO для вызначэння таго, наколькі дакладна рэсурс выконвае адпраўленыя інструкцыі па адпраўцы. У некаторых выпадках тэлеметрыя можа ўключаць іншыя пункты даных, такія як voltagэлектронныя паказанні і стан зарада (г.зн. энергіі) у выпадку, калі рэсурсы з'яўляюцца той ці іншай формай захоўвання. У некаторых выпадках частата справаздач можа дасягаць кожныя 2 секунды. Звярніце ўвагу, што для тэлеметрычнай справаздачнасці патрабуецца B profile VENs. Гл. Дадатак А для прыкладуampлес. Таксама звярніцеся да Дадатку B, напрыкладampфайлы справаздач пілотных кампаній, якія могуць быць дастасавальныя да гэтага тыпу праграм.
Opt Services	–Выкарыстанне службы Opt для паведамлення аб часовай даступнасці расклады звычайна не будзе выкарыстоўвацца так як кліенты папярэдне абавязваліся аб іх наяўнасці. Тым не менш, гэтая паслуга можа быць карыснай як неафіцыйны спосаб для ўдзельнікаў пазначыць адсутнасць даступнасці па змякчальных прычынах, такіх як няспраўнасць абсталявання.
Рэгістрацыйныя паслугі	З-за патрабаванняў да нізкай затрымкі адпраўкі ў рэжыме рэальнага часу выкарыстоўваюцца толькі шаблоны ўзаемадзеяння push.

Праграма часу выкарыстання (TOU) жылых электрамабіляў (EV).

Характарыстыкі праграмы Residential EV TOU

Загрузіць Profile Мэта	Структура ставак, з дапамогай якой кошт зарадкі электрамабіляў мадыфікуецца, каб прымусіць спажыўцоў змяніць схемы спажывання.
Асноўныя драйвера	Пік спажывання энергіі ў жылых памяшканнях прыпадае на вечар. Паколькі зарадка электрамабіля займае 4-8 гадзін, яе можна адкласці на пару гадзін, каб зрушыць пік нагрузкі.
Апісанне праграмы	Кліенты, якія маюць электрамабіль, могуць падпісацца на тарыф часу выкарыстання электрамабіля (EV-TOU) і атрымліваць больш нізкія тарыфы за зарадку свайго аўтамабіля ў непікавы час, напрыклад, з поўначы да 5 раніцы. прапануе заахвоціць кліентаў абмежаваць выкарыстанне электраэнергіі ў дзённы час, калі попыт на электраэнергію самы высокі.
Заахвочванне кліентаў	Менш дарагая зарадка для электрамабіляў.
Стаўка Дызайн	TOU з пікам у сярэдзіне дня, раніцай і ўвечары ў сярэдзіне піку і з 12:5 да XNUMX:XNUMX у непікавы час
Мэтавы кліент	Уладальнік EV з нагрузкай Profile што дасягае піку ўвечары.
Мэтавыя нагрузкі	EV зарадныя прылады
Абавязковая ўмова	Кліент павінен мець разумны лічыльнік і электрамабіль
Тэрмін праграмы	Круглы год
Абмежаванні падзей	Няма
Дні мерапрыемстваў	Кожны дзень, або толькі ў буднія дні
Працягласць мерапрыемства	5-8 гадзін
Апавяшчэнне	Кліент атрымлівае апавяшчэнне аб цэнавых узроўнях на штомесячных рахунках, і VTN рассылае сігналы аб падзеях на дзень наперад.
Opt Паводзіны	Плацельшчыкі могуць змяніць свой тарыфны план, як яны звычайна робяць з камунальнымі паслугамі.
Атэстацыя Падзеі

Характарыстыкі OpenADR для праграм Residential EV TOU

Сігналы падзей	Сігналы ELECTRICITY_PRICE з фактычнымі цэнавымі ўзроўнямі, а таксама ПРОСТЫЯ сігналы, якія дазваляюць удзельнічаць 2.0a VENs Гл. Дадатак А для прыкладуampлес.
Выбраць адказы	Заўсёды выбірайце VENs
Дэскрыптар падзеі	Адна падзея ў тыдзень з інтэрваламі для кожнага цэнавага ўзроўню
Актыўны перыяд падзеі	Варта выкарыстоўваць як мінімум 24-гадзіннае паведамленне. Кожны інтэрвал падзеі павінен ахопліваць узровень стаўкі TOU
Базавыя лініі	Н/Д
Таргетынг падзей	Пашыраны таргетынг не патрабуецца, толькі таргетынг на ўзроўні VEN.
Службы справаздачнасці	Справаздачнасць не патрабуецца, усе дадзеныя могуць паступаць з лічыльніка. Звярніцеся да Дадатку B, напрыкладampфайлы справаздач пілотных кампаній, якія могуць быць дастасавальныя да гэтага тыпу праграм.
Opt Services	Паслугі Opt не будуць мець дачынення да гэтага тыпу праграмы.
Рэгістрацыйныя паслугі	Спажыўцы папярэдне забяспечаць свой VEN утылітай для атрымання цэнавых сігналаў.

Праграма цэнаўтварэння ў рэжыме рэальнага часу на электрамабіль грамадскай станцыі

Характарыстыкі праграмы Public Station EV RTP

Загрузіць Profile Мэта	Дзейнасць па рэагаванні на попыт, з дапамогай якой кошт зарадкі электрамабіляў мадыфікуецца, каб перакласці рэаліі пікавых цэнаў на спажыўцоў.
Асноўныя драйвера	Кошт электраэнергіі змяняецца на працягу дня. Гэтая праграма накіравана на больш эфектыўнае супастаўленне цаны зарадкі з коштам электраэнергіі.
Апісанне праграмы	Грамадскія зарадныя прылады могуць быць на працоўных месцах, на грамадскіх паркоўках і ў рознічных крамах. Гэтая праграма перадае цэны ў рэальным часе патэнцыйным зарадным прыладам перад тым, як яны падключацца, каб яны маглі прыняць абгрунтаванае рашэнне аб тым, зараджаць ці не свой аўтамабіль.
Заахвочванне кліентаў	Менш дарагая зарадка ў непікавы час.
Стаўка Дызайн	Цэны могуць змяняццаurly, але калі кліент вырашыў падключыць свой аўтамабіль да электрасеткі, тарыф усталёўваецца на час зарадкі.
Мэтавы кліент	Усім, у каго ёсць электрамабіль, які трэба зараджаць, знаходзячыся па-за домам.
Мэтавыя нагрузкі	Грамадскія зарадныя прылады для электрамабіляў
Абавязковая ўмова	Зарадныя прылады для электрамабіляў павінны быць падключаны да Інтэрнэту і мець сертыфікацыю OpenADR2.0b або падключацца да вентыляцыйнага шлюза OpenADR2.0b.
Тэрмін праграмы	Круглы год
Абмежаванні падзей	Няма
Дні мерапрыемстваў	Кожны дзень, або толькі ў буднія дні
Працягласць мерапрыемства	1 гадзіна або больш
Апавяшчэнне	Кліент атрымлівае апавяшчэнне аб пераважнай стаўцы пры выбары падключэння свайго аўтамабіля.
Opt Паводзіны	Кліенты могуць адмовіцца, вырашыўшы не спаганяць плату.
Атэстацыя Падзеі

Характарыстыкі OpenADR для праграм Public Station EV RTP

Сігналы падзей	ELECTRICITY_PRICE сігналізуе з цэнамі. Гл. Дадатак А для прыкладуampлес.
Выбраць адказы	Заўсёды выбірайце VENs
Дэскрыптар падзеі	Падзеі павінны быць сумежнымі і ўтрымліваць адзін інтэрвал.
Актыўны перыяд падзеі	Неабходна выкарыстоўваць апавяшчэнне як мінімум за 1 гадзіну, аднак камунальныя службы могуць выбраць апавяшчэнне на дзень наперад.
Базавыя лініі	Н/Д
Таргетынг падзей	Пашыраны таргетынг не патрабуецца, але таргетынг можна выкарыстоўваць для адпраўкі цэн на пэўныя трансфарматары, фідэры або геаграфічныя вобласці.
Службы справаздачнасці	Справаздачнасць не патрабуецца, але можа выкарыстоўвацца пры жаданні. Звярніцеся да Дадатку B, напрыкладampфайлы справаздач пілотных кампаній, якія могуць быць дастасавальныя да гэтага тыпу праграм.
Opt Services	Паслугі Opt не будуць мець дачынення да гэтага тыпу праграмы.
Рэгістрацыйныя паслугі	Пастаўшчык зараднай станцыі забяспечвае свае прылады VTN камунальнай службы.

Праграма размеркаваных энергетычных рэсурсаў (DER) DR

Наступнае апісанне праграмы з'яўляецца гіпатэтычным і заснавана на даследчай працы (спасылка на артыкул Рыша), якая апісвае, як кліенты камунальных паслуг могуць выкарыстоўваць рэсурсы захоўвання DER для ўдзелу ў праграмах DR, такіх як праграмы цэнаўтварэння ў рэжыме рэальнага часу (RTP).

Характарыстыкі праграмы размеркаваных энергетычных рэсурсаў (РЭР).

Загрузіць Profile Мэта	Дзейнасць рэагавання на попыт, якая выкарыстоўваецца для згладжвання інтэграцыі размеркаваных энергетычных рэсурсаў у разумную сетку.
Асноўныя драйвера	-Зніжэнне капітальных выдаткаў і зніжэнне выдаткаў на энергію
Апісанне праграмы	Кліенты з рэсурсамі DER, якія могуць збіраць энергію і захоўваць яе, могуць мінімізаваць выдаткі на набыццё электраэнергіі з сеткі ў перыяды высокіх коштаў, спачатку выкарыстоўваючы назапашаныя энергетычныя рэсурсы, а затым рэалізуючы стратэгіі зніжэння нагрузкі
Заахвочванне кліентаў	Магчымасць кантраляваць выдаткі падчас высокіх коштаў на электраэнергію, выкарыстоўваючы назапашаную энергію, атрыманую з дапамогай фотаэлектрыкі або іншымі спосабамі, і рэалізуючы стратэгіі зніжэння нагрузкі
Стаўка Дызайн	Тарыфы на электраэнергію вар'іруюцца ў залежнасці ад аптовых рынкавых цэн або тарыфу, які змяняецца ў залежнасці ад часу сутак, сезона або тэмпературы
Мэтавы кліент	Кліенты з рэсурсамі захоўвання энергіі
Мэтавыя нагрузкі	Любая
Абавязковая ўмова	Рэсурсы захоўвання энергіі
Тэрмін праграмы	У любы час
Абмежаванні падзей	Няма
Дні мерапрыемстваў	Кожны дзень
Працягласць мерапрыемства	24 гадзіны
Апавяшчэнне	Дзень наперадзе
Opt Паводзіны	N/A – праграма найлепшых намаганняў
Атэстацыя Падзеі	Няма

Характарыстыкі OpenADR для размеркаваных энергетычных рэсурсаў (DER)

Сігналы падзей	Сігналы ELECTRICITY_PRICE з 24-гадзіннымі інтэрваламі коштаў за 24-гадзінны перыяд. Для гэтага сігналу спатрэбіцца B profile. Гэтая праграма не паддаецца ПРОСТАЙ сігналізацыі для A Profile VENs. Гл. Дадатак А для прыкладуampлес.
Выбраць адказы	-VTN адпраўка падзей павінен усталяваць для элемента oadrResponseRequired значэнне «ніколі», не даючы VENs адказаць.
Дэскрыптар падзеі	- Падзея прыярытэт павінен быць усталяваны на 1 калі правіламі праграмы або канфігурацыяй VTN не вызначана іншае
Актыўны перыяд падзеі	24 гадзіны з інтэрвалам у 1 гадзіну з паведамленнем на дзень наперад
Базавыя лініі	Н/Д
Таргетынг падзей	Пашыраны таргетынг не патрабуецца, акрамя venID
Службы справаздачнасці	Справаздачнасць не патрэбна Звярніцеся да Дадатку B, напрыкладampфайлы справаздач пілотных кампаній, якія могуць быць дастасавальныя да гэтага тыпу праграм.
Opt Services	Не выкарыстоўваецца
Рэгістрацыйныя паслугі	Інтэрвалы апытання запытваецца VTN для тыповых праграм на дзень наперад не патрабуецца часцей, чым раз у гадзіну. Аднак выкарыстанне апытання для выяўлення сардэчнага рытму можа запатрабаваць больш частага апытання, як і праграмы тэрмастата для жылых памяшканняў са значна меншым часам паведамлення.

– Сample Шаблоны дадзеных і карыснай нагрузкі

Наступныя табліцы і карысная нагрузка XML samples забяспечыць рэалізатарам адчувальную эксampяк павінны быць рэалізаваны шаблоны DR у гэтым дакуменце. Наступныя прэфіксы прасторы імёнаў выкарыстоўваюцца ў карыснай нагрузцы exampлес:

• xmlns:oadr=”http://openadr.org/oadr-2.0b/2012/07″
• xmlns:pyld=”http://docs.oasis-open.org/ns/energyinterop/201110/карысныя нагрузкі”
• xmlns:ei=”http://docs.oasis-open.org/ns/energyinterop/201110″
• xmlns:scale=”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
• xmlns:emix=”http://docs.oasis-open.org/ns/emix/2011/06″
• xmlns:strm=”urn:ietf:params:xml:ns:icalendar-2.0:stream”
• xmlns:xcal=”urn:ietf:params:xml:ns:icalendar-2.0″
• xmlns:power=”http://docs.oasis-open.org/ns/emix/2011/06/power”

Праграма крытычнага пікавага цэнаўтварэння (CPP)

Сцэнар CPP 1 – Просты варыянт выкарыстання, A ці B Profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 1:XNUMX
  • Працягласць: 4 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 1
  • Назва сігналу: ПРОСТЫ
    • Тып сігналу: узровень
    • Адзінкі: N/A
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1
    • Мэта сігналу: Н/Д
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Сцэнар CPP 2 – Тыповы варыянт выкарыстання, B profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 1:XNUMX
  • Працягласць: 4 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 2
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: Узровень 0, 1, 2, 3
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1 або 2
    • Мэта сігналу: Няма
  • Назва сігналу: ELECTRICITY_PRICE
    • Тып сігналу: кошт
    • Адзінкі: даляры ЗША за кВт/г
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповыя інтэрвалы: ад 0.10 да 1.00 долараў
    • Мэта сігналу: Няма
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Сцэнар CPP 3 – складаны варыянт выкарыстання

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 2:XNUMX
  • Працягласць: 6 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў:2
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: узровень 0,1, 2, 3)
    • Колькасць інтэрвалаў 3
    • Працягласць інтэрвалу: 1 гадзіна, 4 гадзіны, 1 гадзіна
    • Тыповае значэнне(я) інтэрвалу: 1, 2, 1 (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Назва сігналу: ELECTRICITY_PRICE
    • Тып сігналу: кошт
    • Адзінкі: даляры ЗША за кВт/г
    • Колькасць інтэрвалаў 3
    • Працягласць інтэрвалу: 1 гадзіна, 4 гадзіны, 1 гадзіна
    • Тыповыя інтэрвалы: 0.50 $, 0.75 $, 0.50 $ (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Мэты падзеі: Рэсурс_1, Рэсурс_2, Рэсурс_3
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

CPP SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання

OadrDisReq091214_043740_513

TH_VTN

Падзея091214_043741_028_0

0

http://MarketContext1

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

далёка

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

PT4H

PT24H

PT4H

0

2.0

ПРОСТА

ўзровень

SIG_01

0.0

PT4H

0

0.75

ЭЛЕКТРЫЧНАСЦЬ_PRICE

цана

SIG_02

валюта за кВт/г

даляраў ЗША

ні адзін

0.0

venID_1234

заўсёды

Праграма таргоў па ёмістасці (CBP)

Сцэнар CBP 1 – Просты варыянт выкарыстання, A або B Profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 1:XNUMX
  • Працягласць: 4 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 1
  • Назва сігналу: ПРОСТЫ
    • Тып сігналу: узровень
    • Адзінкі: N/A
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1
    • Мэта сігналу: Н/Д
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Сцэнар CBP 2 – Тыповы варыянт выкарыстання, B profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 1:XNUMX
  • Працягласць: 4 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 2
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: Узровень 0,1, 2, 3
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1 або 2
    • Мэта сігналу: Няма
  • Назва сігналу: BID_LOAD
    • Тып сігналу: зададзенае значэнне
    • Адзінкі: powerReal
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповыя значэнні інтэрвалаў: ад 20 кВт да 100 кВт
    • Мэта сігналу: Няма
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Сцэнар CBP 3 – складаны варыянт выкарыстання

• Падзея
  • Апавяшчэнне: дзень падзеі (колькі гадзін?)
  • Час пачатку: 1:XNUMX
  • Працягласць: 6 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў:3
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: узровень 0,1, 2, 3)
    • Колькасць інтэрвалаў: 2
    • Працягласць інтэрвалу: 3 гадзіны, 3 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1, 2 (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Назва сігналу: BID_LOAD
    • Тып сігналу: зададзенае значэнне
    • Адзінкі: powerReal
    • Колькасць інтэрвалаў 2
    • Працягласць інтэрвалу: 3 гадзіны, 3 гадзіны
    • Тыповыя значэнні інтэрвалаў: 40 кВт, 80 кВт (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Назва сігналу: BID_PRICE
    • Тып сігналу: кошт
    • Адзінкі: валюта за кВт
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 6 гадзіны
    • Тыповыя інтэрвалы: 3.10 $
    • Мэта сігналу: Няма
  • Мэты падзеі: Рэсурс_1, Рэсурс_2, Рэсурс_3
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Справаздача(ы)
  • Назва справаздачы: TELEMETRY_USAGE
  • Тып справаздачы: выкарыстанне
  • Адзінкі: powerReal
  • Тып чытання: прамое чытанне
  • Перыядычнасць справаздач: кожныя 1 гадзіну

CBP SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання

OadrDisReq091214_043740_513

TH_VTN

Падзея091214_043741_028_0

0

http://MarketContext1

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

далёка

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

PT4H

PT24H

PT4H

0

2.0

ПРОСТА

ўзровень

SIG_01

0.0

PT4H

0

80.0

BID_LOAD

зададзенае значэнне

SIG_02

RealPower

В

к

60.0

<power:voltage>220.0tage>

праўда

0.0

venID_1234

заўсёды

Праграму тэрмастата для жылых памяшканняў

Сцэнар жылога тэрмастата 1 – просты варыянт выкарыстання, A або B Profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 1:XNUMX
  • Працягласць: 4 гадзіны
  • Рандомізацыя: 10 хвілін
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 1
  • Назва сігналу: ПРОСТЫ
    • Тып сігналу: узровень
    • Адзінкі: N/A
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1
    • Мэта сігналу: Н/Д
  • Мэта(-і) падзеі: Рэсурс_1
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Сцэнар 2 жылога тэрмастата – тыповы варыянт выкарыстання, B profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 1:XNUMX
  • Працягласць: 4 гадзіны
  • Рандомізацыя: 10 хвілін
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 2
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: Узровень 0,1, 2, 3
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1 або 2
    • Мэта сігналу: Няма
  • Назва сігналу: LOAD_CONTROL
    • Тып сігналу: x-loadControlLevelOffset
    • Адзінкі: тэмпература
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 4 гадзіны
    • Тыповае значэнне(я) інтэрвалу: ад 2 да 6 градусаў па Фарэнгейце
    • Мэта сігналу: Няма
  • Мэты падзеі: Resource_1, Resource_2
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn, Possible outOut (oadrCreateOpt)
• Даклады
  • Няма

Сцэнар 3 жылога тэрмастата – складаны варыянт выкарыстання

• Падзея
  • Паведамленне: Дзень мерапрыемства
  • Час пачатку: 1:XNUMX
  • Працягласць: 6 гадзіны
  • Рандомізацыя: 10 хвілін
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў:3
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: узровень 0,1, 2, 3)
    • Колькасць інтэрвалаў: 2
    • Працягласць інтэрвалу: 3 гадзіны, 3 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 1, 2 (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Назва сігналу: BID_LOAD
    • Тып сігналу: x-loadControlCapacity
    • Адзінкі: няма
    • Колькасць інтэрвалаў 2
    • Працягласць інтэрвалу: 3 гадзіны, 3 гадзіны
    • Тыповае значэнне(я) інтэрвалу: 0.9, 0.8 (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Мэты падзеі: Рэсурс_1, Рэсурс_2, Рэсурс_3
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn, Possible outOut (oadrCreateOpt)
• Справаздача(ы)
  • Няма

Жылы тэрмастат SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання

OadrDisReq091214_043740_513

TH_VTN

Падзея091214_043741_028_0

0

http://MarketContext1

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

далёка

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

PT4H

PT10M

PT24H

PT4H

0

2.0

ПРОСТА

ўзровень

SIG_01

0.0

PT4H

0

6.0

LOAD_CONTROL

x-loadControlLevelOffset

SIG_02

тэмпература

па Фарэнгейту

ні адзін

0.0

рэсурс_1

рэсурс_2

заўсёды

Хуткая адпраўка DR

Хуткі сцэнар DR 1 – просты варыянт выкарыстання, A або B Profile

• Падзея
  • Апавяшчэнне: 10 хвілін
  • Час пачатку: 1:XNUMX
  • Працягласць: 0 (адкрыты)
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 1
  • Назва сігналу: ПРОСТЫ
    • Тып сігналу: узровень
    • Адзінкі: N/A
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 0 (адкрыты)
    • Тыповае значэнне(я) інтэрвалу: 1
    • Мэта сігналу: Н/Д
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Хуткі сцэнар DR 2 – Тыповы варыянт выкарыстання, B profile

• Падзея
  • Апавяшчэнне: 10 хвілін
  • Час пачатку: 1:XNUMX
  • Працягласць: 30 хвілін
  • Рандомизация: Няма
  • Ramp Уверх: 5 хвілін
  • Аднаўленне: 5 хвілін
  • Колькасць сігналаў: 2
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: Узровень 0,1, 2, 3
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 30 хвілін
    • Тыповае значэнне(я) інтэрвалу: 1 або 2
    • Мэта сігналу: Няма
  • Назва сігналу: LOAD_DISPATCH
    • Тып сігналу: дэльта
    • Адзінкі: powerReal
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 30 хвілін
    • Тыповыя значэнні інтэрвалаў: ад 500 кВт да 2 мВт
    • Мэта сігналу: Няма
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Назва справаздачы: TELEMETRY_USAGE
  • Тып справаздачы: выкарыстанне
  • Адзінкі: powerReal
  • Тып чытання: прамое чытанне
  • Перыядычнасць справаздач: кожную 1 хвіліну

Хуткі сцэнар 3 - складаны варыянт выкарыстання

• Падзея
  • Апавяшчэнне: 10 хвілін
  • Час пачатку: 1:XNUMX
  • Працягласць: 30 хвілін
  • Рандомизация: Няма
  • Ramp Уверх: 5 хвілін
  • Аднаўленне: 5 хвілін
  • Колькасць сігналаў:2
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: узровень 0,1, 2, 3)
    • Колькасць інтэрвалаў: 2
    • Працягласць інтэрвалу: 15 хвілін, 15 хвілін
    • Тыповае значэнне(я) інтэрвалу: 1, 2 (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Назва сігналу: LOAD_DISPATCH
    • Тып сігналу: зададзенае значэнне
    • Адзінкі: powerReal
    • Колькасць інтэрвалаў 2
    • Працягласць інтэрвалу: 15 хвілін, 15 хвілін
    • Тыповыя значэнні інтэрвалаў: 800 кВт, 900 кВт (для кожнага інтэрвалу адпаведна)
    • Мэта сігналу: Няма
  • Мэты падзеі: Resource_1
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Справаздача(ы)
  • Назва справаздачы: TELEMETRY_USAGE
  • Тып справаздачы: выкарыстанне
  • Адзінкі: powerReal і voltage
  • Тып чытання: прамое чытанне
  • Перыядычнасць справаздач: кожныя 5 секунд

Хуткі DR SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання

OadrDisReq091214_043740_513

TH_VTN

Падзея091214_043741_028_0

0

http://MarketContext1

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

далёка

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

PT10M

PT10M

<ei:x-eiRampУверх>

PT5M

</ei:x-eiRampУверх>

PT5M

PT10M

0

2.0

ПРОСТА

ўзровень

SIG_01

0.0

PT10M

0

500.0

LOAD_DISPATCH

дэльта

SIG_02

RealPower

В

к

60.0

<power:voltage>220.0tage>

праўда

0.0

venID_1234

заўсёды

Хуткі DR Sample Карысная нагрузка метаданых справаздачы – Тыповы B Profile Выпадак выкарыстання

RegReq120615_122508_975

PT10M

rID120615_122512_981_0

рэсурс1

выкарыстанне

RealEnergy

Wh

к

Прамое чытанне

http://MarketContext1

<oadr:oadrSamplingRate>

ПТ1М

PT10M

ілжывы

</oadr:oadrSamplingRate>

0

СправаздачаSpecID120615_122512_481_2

METADATA_TELEMETRY_USAGE

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

ec27de207837e1048fd3

Хуткі DR Sample Карысная нагрузка запыту на справаздачу – Тыповы B Profile Выпадак выкарыстання

ReportReqID130615_192625_230

ReportReqID130615_192625_730

СправаздачаSpecID120615_122512_481_2

PT1M

PT1M

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

PT10M

rID120615_122512_981_0

х-недастасавальна

VEN130615_192312_582

Хуткі DR SampКарысная нагрузка даных справаздач – тыповы B Profile Выпадак выкарыстання

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

Якасць добрая - неспецыфічная

RP_54321

ReportReqID130615_192625_730

СправаздачаSpecID120615_122512_481_2

TELEMETRY_USAGE

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

VEN130615_192312_582

Праграма часу выкарыстання (TOU) жылых электрамабіляў (EV).

Звярніце ўвагу, што, паколькі праграма перадае ўзроўні стаўкі ў даволі структураванай форме, паказваюцца толькі простыя і тыповыя выпадкі выкарыстання

Сцэнар 1 для жылых электрамабіляў – просты варыянт выкарыстання, A або B Profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: 1:XNUMX
  • Працягласць: 24 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 1
  • Назва сігналу: ПРОСТЫ
    • Тып сігналу: узровень
    • Адзінкі: N/A
    • Колькасць інтэрвалаў; роўныя змены ўзроўню TOU за 24 гадзіны (2-6)
    • Працягласць інтэрвалу (працягласць): перыяд актыўнага ўзроўню TOU (г.зн. 6 гадзін)
    • Тыповае(ыя) значэнне(я) інтэрвалу(я): 0 - 4 супастаўляецца з узроўнямі TOU
    • Мэта сігналу: Н/Д
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Сцэнар 2 для жылых электрамабіляў – тыповы варыянт выкарыстання, B profile

• Падзея
  • Паведамленне: за дзень да падзеі
  • Час пачатку: поўнач
  • Працягласць: 24 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 2
  • Назва сігналу: Простая
    • Тып сігналу: узровень
    • Адзінкі: Узровень 0, 1, 2, 3
    • Колькасць інтэрвалаў: аднолькавая змена ўзроўню TOU за 24 гадзіны (2 - 6)
    • Працягласць інтэрвалу (працягласць): перыяд актыўнага ўзроўню TOU (г.зн. 6 гадзін)
    • Тыповыя значэнні(я) інтэрвалу: 0 - 4, супастаўленыя з узроўнямі TOU (0 - самы танны ўзровень)
    • Мэта сігналу: Няма
  • Назва сігналу: ELECTRICITY_PRICE
    • Тып сігналу: кошт
    • Адзінкі: даляры ЗША за кВт/г
    • Колькасць інтэрвалаў: аднолькавыя змены ўзроўню TOU за 24 гадзіны (2 - 6)
    • Працягласць інтэрвалу (працягласць): перыяд актыўнага ўзроўню TOU (г.зн. 6 гадзін)
    • Тыповыя інтэрвалы: ад 0.10 да 1.00 долараў ЗША (бягучая стаўка ўзроўню)
    • Мэта сігналу: Няма
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Жылы EV SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання

OadrDisReq091214_043740_513

TH_VTN

Падзея091214_043741_028_0

0

http://MarketContext1

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

далёка

<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

ПРОСТА

ўзровень

SIG_01

0.0

PT5H

0

0.35

PT7H

1

0.55

PT7H

2

0.75

PT5H

3

0.55

ЭЛЕКТРЫЧНАСЦЬ_PRICE

цана

SIG_02

валюта за кВт/г

даляраў ЗША

ні адзін

0.0

venID_1234

заўсёды

Праграма цэнаўтварэння ў рэжыме рэальнага часу на электрамабіль грамадскай станцыі

Звярніце ўвагу, што, паколькі гэта праграма цэнаўтварэння ў рэжыме рэальнага часу, на самай справе няма адрозненняў паміж простым, тыповым і складаным варыянтам выкарыстання. Таму сampданыя будуць паказаны толькі для тыповага выпадку выкарыстання.

Грамадская станцыя EV Сцэнар 1 – Тыповы варыянт выкарыстання, B profile

• Падзея
  • Апавяшчэнне: за 1 гадзіну наперад
  • Час пачатку: 1:XNUMX
  • Працягласць: 1 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 1
  • Назва сігналу: ELECTRICITY_PRICE
    • Тып сігналу: кошт
    • Адзінкі: даляры ЗША за кВт/г
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 1 гадзіны
    • Тыповыя інтэрвалы: ад 0.10 да 1.00 долараў
    • Мэта сігналу: Няма
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Патрабуецца адказ VEN: заўсёды
  • Чаканы адказ VEN: optIn
• Даклады
  • Няма

Грамадская станцыя EV SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання

OadrDisReq091214_043740_513

TH_VTN

Падзея091214_043741_028_0

0

http://MarketContext1

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

далёка

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

PT1H

PT1H

PT1H

0

0.75

ЭЛЕКТРЫЧНАСЦЬ_PRICE

цана

SIG_01

валюта за кВт/г

даляраў ЗША

ні адзін

0.0

venID_1234

заўсёды

Праграма размеркаваных энергетычных рэсурсаў (DER) DR

Звярніце ўвагу, што, паколькі гэта праграма цэнаўтварэння ў рэжыме рэальнага часу, на самай справе няма адрозненняў паміж простым, тыповым і складаным варыянтам выкарыстання. Таму сampданыя будуць паказаны толькі для тыповага выпадку выкарыстання.

Грамадская станцыя EV Сцэнар 1 – Тыповы варыянт выкарыстання, B profile

• Падзея
  • Апавяшчэнне: на дзень наперад
  • Час пачатку: поўнач
  • Працягласць: 24 гадзіны
  • Рандомизация: Няма
  • Ramp Уверх: Няма
  • Аднаўленне: Няма
  • Колькасць сігналаў: 24
  • Назва сігналу: ELECTRICITY_PRICE
    • Тып сігналу: кошт
    • Адзінкі: даляры ЗША за кВт/г
    • Колькасць інтэрвалаў 1
    • Працягласць інтэрвалу: 1 гадзіны
    • Тыповыя інтэрвалы: ад 0.10 да 1.00 долараў
    • Мэта сігналу: Няма
  • Мэты падзеі: venID_1234
  • Прыярытэт: 1
  • Неабходны адказ VEN: ніколі
  • Чаканы адказ VEN: няма
• Даклады
  • Няма

Грамадская станцыя EV SampКарысная нагрузка падзей – Тыповы B Profile Выпадак выкарыстання

OadrDisReq091214_043740_513

TH_VTN

Падзея091214_043741_028_0

0

http://MarketContext1

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

далёка

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

PT24H

PT24H

PT1H

0

0.75

PT1H

1

0.80

ЭЛЕКТРЫЧНАСЦЬ_PRICE

цана

SIG_01

валюта за кВт/г

даляраў ЗША

ні адзін

0.0

venID_1234

ніколі

- Былыample Справаздачы ад Utility Pilots

Члены OpenADR Alliance прадаставілі наступнае B Profile oadrUpdateReport карысная нагрузка sampз пілотных праграм камунальных службаў, дзе былі разгорнуты іх VEN. Наступныя нататкі суправаджалі тры карысныя нагрузкі sampпры ўмове:

Карысная нагрузка тэрмастата Мэта:

• Неабходна ведаць стан тэрмастата (тэмпература, зададзеныя значэнні, стан вентылятара і рэжыму)
• Калі гэта дазволена, незалежна ад таго, змяніў кліент налады тэрмастата (паведамленні аб адмене ўручную)

M&V для скідак Карысная нагрузка Мэта:

• Статус рэсурсаў і ручное перавызначэнне ў выпадку выбару
• Інтэрвальныя даныя з лічыльніка пульса KYZ або манітора энергіі для агульнай энергіі ў кВт-гадз і імгненнага попыту ў кВт

Карысная нагрузка даных Smart Meter/AMI Interval Мэта:

• Інтэрвал паказанняў лічыльніка AMI складае ад 15 хвілін да 1 гадзіны. Нягледзячы на ​​тое, што гэта карысна, недастаткова дэталёва для ацэнак рахункаў амаль у рэальным часе
• Агульная энергія ў кВт-гадз, дэльта-энергія ў кВт-гадз, імгненны попыт у кВт

Наступныя прэфіксы прасторы імёнаў выкарыстоўваюцца ў карыснай нагрузцы exampлес:

• xmlns:oadr=”http://openadr.org/oadr-2.0b/2012/07″
• xmlns:pyld=”http://docs.oasis-open.org/ns/energyinterop/201110/карысныя нагрузкі”
• xmlns:ei=”http://docs.oasis-open.org/ns/energyinterop/201110″
• xmlns:scale=”http://docs.oasis-open.org/ns/emix/2011/06/siscale”
• xmlns:emix=”http://docs.oasis-open.org/ns/emix/2011/06″
• xmlns:strm=”urn:ietf:params:xml:ns:icalendar-2.0:stream”
• xmlns:xcal=”urn:ietf:params:xml:ns:icalendar-2.0″
• xmlns:power=”http://docs.oasis-open.org/ns/emix/2011/06/power”

Справаздача тэрмастата аб карыснай нагрузцы Sample

РУП-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

Статус

праўда

ілжывы

0

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Бягучая тэмп

77.000000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Налада тэмпературы нагрэву

64.000000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Налада тэмпературы прахалоды

86.000000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Налада рэжыму HVAC

3

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Бягучы рэжым HVAC

0.000000

Няма якасці – няма каштоўнасці

Налада рэжыму вентылятара

2

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Бягучы рэжым утрымання

2

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Бягучы рэжым у ад'ездзе

0

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

Бягучая вільготнасць

0.000000

Няма якасці – няма каштоўнасці

RP21

REQ:RReq:1395368583267

0013A20040980FAE

TELEMETRY_STATUS

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

VEN.ID:1395090780716

Справаздача аб скідках M&Vfor Payload Sample

РУП-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

Статус

праўда

ілжывы

Якасць добрая - неспецыфічная

Падлік пульса

34750.000000

Якасць добрая - неспецыфічная

Энергія

33985.500000

Якасць добрая - неспецыфічная

Магутнасць

1.26

Якасць добрая - неспецыфічная

RP15

REQ:RReq:10453335019195698

0000000000522613 60

TELEMETRY_USAGE

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

VEN.ID:1439831430142

Smart Meter/AMI Interval Data Report Карысная нагрузка Sample

РУП-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

імгненны попыт

6.167000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

intervalDataDelivered

0.051000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

currSumDelivered

12172.052000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

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

PT15S

імгненны попыт

6.114000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

intervalDataDelivered

0.051000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

currSumDelivered

12172.052000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

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

PT15S

імгненны попыт

6.113000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

intervalDataDelivered

0.051000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

currSumDelivered

12172.142000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

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

PT15S

імгненны попыт

6.112000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

intervalDataDelivered

0.051000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

currSumDelivered

12172.142000

Няма новага значэння - выкарыстоўваецца папярэдняе значэнне

RP4101

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

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

TELEMETRY_USAGE

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

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

– Паслугі

Open ADR падтрымлівае наступныя сэрвісы:

• Сэрвіс EiEvent – Выкарыстоўваецца сеткамі VTN для адпраўкі падзей рэагавання на попыт у VEN і выкарыстоўваецца сеткамі VEN, каб паказаць, ці збіраюцца рэсурсы ўдзельнічаць у падзеі. Адзіны сэрвіс, які падтрымліваецца A profile з'яўляецца EiEvent
• Сэрвіс EiReport – Выкарыстоўваецца VEN і VTN для абмену гістарычнымі, тэлеметрычнымі і прагнознымі справаздачамі
• Сэрвіс EiOpt – Выкарыстоўваецца VEN для перадачы раскладу часовай даступнасці VTN або для кваліфікацыі рэсурсаў, якія ўдзельнічаюць у падзеі
• Сэрвіс EiRegisterParty – Ініцыявана VEN і выкарыстоўваецца VEN і VTN для абмену інфармацыяй, неабходнай для забеспячэння сумяшчальнага абмену карыснай нагрузкай
• Сэрвіс OadrPoll – Выкарыстоўваецца VEN для апытання VTN на прадмет карысных нагрузак ад любых іншых службаў

А і Б праfile аперацыі службы вызначаюцца каранёвым элементам кожнай карыснай нагрузкі, за выключэннем абгортак oadrPayload і oadrSignedObject, якія выкарыстоўваюцца на ўсіх B profile карысныя нагрузкі.

– Вызначэння карыснай нагрузкі

Карысныя нагрузкі EiEvent

• oadrRequestEvent – Выкарыстоўваецца VEN у мадэлі абмену прыцягненнем для атрымання ўсіх адпаведных падзей з VTN. Выкарыстоўваецца як асноўны механізм апытання для A profile VEN, але выкарыстоўваецца толькі на B VEN для сінхранізацыі з VTN.
• oadrDistributeEvent – Выкарыстоўваецца VTN для дастаўкі падзей рэагавання на попыт у VEN
• oadrCreatedEvent – Выкарыстоўваецца VEN, каб паведаміць, ці мае намер удзельнічаць у мерапрыемстве шляхам выбару або адмовы
• oadrResponse – Выкарыстоўваецца VTN для пацверджання атрымання optIn або optOut ад VEN

Карысныя нагрузкі EiReport

Звярніце ўвагу, што і VEN, і VTN здольныя быць як стваральнікам справаздачы, так і запытальнікам справаздачы, таму ўсе прыведзеныя ніжэй карысныя нагрузкі могуць быць ініцыяваны любым з бакоў.

• oadrRegisterReport – Выкарыстоўваецца для публікацыі сваіх магчымасцей справаздачнасці ў справаздачы аб метададзеных
• oadrRegisteredReport -Пацвердзіце атрыманне oadrRegisterReport, пры жаданні запытайце адну з прапанаваных справаздач
• oadrCreateReport – Выкарыстоўваецца для запыту справаздачы, якая была раней прапанавана VEN або VTN
• oadrCreatedReport – Пацвердзіце атрыманне запыту на справаздачу
• oadrUpdateReport -Даставіць запытаную справаздачу, якая змяшчае інтэрвальныя даныя
• oadrUpdatedReport – Пацвердзіць атрыманне дастаўленай справаздачы
• oadrCancelReport – Адмяніць раней запытаную перыядычную справаздачу
• oadrCanceledReport – Пацвердзіце адмену перыядычнай справаздачы
• oadrResponse – Выкарыстоўваецца ў якасці адказу-запаўняльніка ў некаторых шаблонах абмену прыцягненнем, калі адказ прыкладнога ўзроўню дастаўляецца ў запыце транспартнага ўзроўню.

Карысныя нагрузкі EiOpt

• oadrCreateOpt – Выкарыстоўваецца для дзвюх цалкам розных мэтаў
  • Для таго, каб VEN паведамляў часовы графік даступнасці ў VTN адносна магчымасці ўдзелу ў мерапрыемствах DR
  • Каб VEN кваліфікаваў рэсурсы, якія ўдзельнічаюць у мерапрыемстве
• oadrCreatedOpt – Пацвердзіце атрыманне карыснай нагрузкі oadrCreateOpt
• oadrCancelOpt -Адмяніць графік часовай даступнасці
• oadrCanceledOpt – Пацвердзіце скасаванне часовай справаздачы аб даступнасці

 

Карысныя нагрузкі EiRegisterParty

• oadrQueryRegistration – Спосаб для VEN запытваць інфармацыю аб рэгістрацыі VTN без фактычнай рэгістрацыі.
• oadrCreatePartyRegistration – Запыт ад ВЕН у ВТН на рэгістрацыю. Змяшчае інфармацыю аб магчымасцях VENs.
• oadrCreatedPartyRegistration – Адказ на oadrQueryRegistration або oadrCreatePartyRegistration. Змяшчае магчымасці VTN і рэгістрацыйную інфармацыю, неабходную для ўзаемадзеяння VEN
• oadrCancelPartyRegistration – Выкарыстоўваецца VEN або VTN для адмены рэгістрацыі
• oadrCanceledPartyRegistration – Адказ на oadrCancelPartyRegistration. Пацвярджае атрыманне адмены рэгістрацыі
• oadrRequestReregistration – Гэтая карысная нагрузка выкарыстоўваецца VTN у мадэлі абмену прыцягненнем, каб сігналізаваць VEN аб паўторным ініцыяванні паслядоўнасці рэгістрацыі
• oadrResponse – Выкарыстоўваецца ў якасці адказу-запаўняльніка ў некаторых шаблонах абмену прыцягненнем, калі адказ прыкладнога ўзроўню дастаўляецца ў запыце транспартнага ўзроўню.

Карысныя нагрузкі OadrPoll

• oadrPoll – Агульны механізм палявання для B profile які вяртае карысную нагрузку для любых іншых новых або абноўленых сэрвісаў.
• oadrResponse – Выкарыстоўваецца, каб паказаць, што няма новых або абноўленых карысных нагрузак

– Гласарый элементаў карыснай нагрузкі схемы

Ніжэй прыведзены алфавітны спіс элементаў схемы, якія выкарыстоўваюцца ў карысных нагрузках OpenADR 2.0. У апавяданні апісваецца іх выкарыстанне ў дачыненні да OpenADR і іх выкарыстання ў карысных нагрузках. Калі вызначэнне элемента змяняецца ў залежнасці ад карыснай нагрузкі, у якой ён утрымліваецца, або кантэксту яго выкарыстання, гэта будзе адзначана ў апавяданні. Вызначэнні каранёвай карыснай нагрузкі былі выключаны, паколькі яны вызначаны ў Дадатку C.

• ac – Лагічнае значэнне, якое паказвае, ці з'яўляецца энергетычны прадукт пераменным токам
• дакладнасць - Лік выражаецца ў тых жа адзінках, што і зменная карыснай нагрузкі для інтэрвалу. Калі прысутнічае з упэўненасцю, паказвае на верагодную зменлівасць прагнозу. Пры наяўнасці з ReadingType паказвае на верагодную памылку чытання.
• aggregatedPnode – Сукупны вузел цэнаўтварэння - гэта спецыялізаваны тып вузла цэнаўтварэння, які выкарыстоўваецца для мадэлявання такіх элементаў, як сістэмная зона, зона цэн па змаўчанні, зона карыстальніцкай цэны, зона кантролю, агрэгаваная генерацыя, агрэгаваная нагрузка, якая ўдзельнічае, агрэгаваная нагрузка, якая не ўдзельнічае, гандлёвы цэнтр, зона DCA
• даступны – Аб’ект, які змяшчае дату-час і працягласць раскладу даступнасці EiOpt
• базавы ID - Унікальны ідэнтыфікатар для пэўнай базавай лініі
• базавая назва - Апісальная назва для базавай лініі
• кампаненты –
• упэўненасць – Статыстычная верагоднасць таго, што справаздачная кропка даных з'яўляецца дакладнай
• створана ДатаЧас – Дата і час стварэння карыснай нагрузкі
• валюта –
• валюта за кВт –
• валюта за кВт/г –
• валютаPerThm –
• ток –
• бягучае значэнне - Значэнне payloadFloat інтэрвалу падзеі, які выконваецца ў дадзены момант.
• customUnit – Выкарыстоўваецца для вызначэння карыстальніцкай адзінкі вымярэння для карыстацкіх справаздач
• дата-час –
• dtstart – Час пачатку дзеяння, даных або змены стану
• працягласць – Перыяд часу для падзеі, справаздачы або інтэрвал часу даступнасці
• працягласць - Працягласць дзеяння, даных або стану
• eiActivePeriod – Часавыя рамкі, якія маюць дачыненне да агульнага мерапрыемства
• eiCreatedEvent – Адкажыце на падзею DR з дапамогай optIn або optOut
• eiEvent -Аб'ект, які змяшчае ўсю інфармацыю для адной падзеі
• eiEventBaseline – B прафесіяналfile
• eiEventSignal – Аб’ект, які змяшчае ўсю інфармацыю для аднаго сігналу ў падзеі
• eiEventSignals – Інтэрвал даных для аднаго або некалькіх сігналаў падзей і/або базавых ліній
• eiMarketContext – URI, які адназначна ідэнтыфікуе праграму рэагавання на попыт
• eiReportID – Ідэнтыфікатар спасылкі для справаздачы
• eiRequestEvent – Запытаць падзею з VTN у рэжыме выцягвання
• eiResponse – Пакажыце, ці прымальная атрыманая карысная нагрузка
• eiTarget – Ідэнтыфікуе рэсурсы, звязаныя з лагічным інтэрфейсам VEN. Для падзей указаныя значэнні з'яўляюцца мэтавымі для падзеі
• endDeviceAsset – EndDeviceAssets - гэта фізічная прылада або прылады, якія могуць быць лічыльнікамі або іншымі тыпамі прылад, якія могуць прадстаўляць цікавасць
• EnergyApparent – Бачная энергія, вымераная ў вольтахampда гадзін (VAh)
• EnergyItem –
• EnergyReactive - Рэактыўная энергія, вольт-ampрэактыўныя гадзіны (VARh)
• EnergyReal - Рэальная энергія, ват-гадзіны (Вт·гадз)
• дэскрыптар падзеі – Інфармацыя аб мерапрыемстве
• ідэнтыфікатар падзеі – Значэнне ідэнтыфікатара, якое ідэнтыфікуе асобнік канкрэтнай падзеі DR.
• eventResponse – Аб’ект, які змяшчае адказ VEN на запыт аб удзеле ў мерапрыемстве
• eventResponses - адказы optIn або optOut для атрыманых падзей
• Статус падзеі – Бягучы статус падзеі (далёка, блізка, актыўна і г.д.)
• FeatureCollection/location/Polygon/exterior/LinearRing
• частата –
• зярністасць – Гэта прамежак часу паміж сampпрывялі дадзеныя ў запыце справаздачы.
• ідэнтыфікатар групы -Гэты тып мэты выкарыстоўваецца для падзей, справаздач і раскладаў выбараў. Значэнне, як правіла, прысвойваецца ўтылітай падчас рэгістрацыі ў праграме DR
• назва групы – Гэты тып мэты выкарыстоўваецца для падзей, справаздач і раскладаў выбараў. Значэнне, як правіла, прысвойваецца ўтылітай падчас рэгістрацыі ў праграме DR
• герц –
• інтэрвал – Аб’ект, які змяшчае даныя-час і/або працягласць, а таксама значэнне дзеяння ў выпадку падзеі або даныя ў выпадку справаздачы
• інтэрвалы - Адзін або некалькі інтэрвалаў часу, на працягу якіх актыўная падзея DR або даступныя даныя справаздачы
• апісанне прадмета - Апісанне справаздачнай адзінкі вымярэння
• itemUnits – Базавая адзінка вымярэння для кропкі даных справаздачы
• рынкавы кантэкст - URI, які ідэнтыфікуе праграму DR
• meterAsset - MeterAsset - гэта фізічная прылада або прылады, якія выконваюць ролю лічыльніка
• modificationDateTime – Калі падзея зменена
• Нумар мадыфікацыі – Павялічваецца кожны раз, калі падзея змяняецца.
• прычына змены - Чаму падзея была зменена
• мрыд - mRID вызначае фізічную прыладу, якая можа быць CustomerMeter або іншымі тыпамі EndDevices.
• вузел - Вузел - гэта месца, дзе нешта мяняецца (часта права ўласнасці) або злучаецца ў сетцы. Многія вузлы звязаны з лічыльнікамі, але не ўсе.
• numDataSources –
• oadrCapacity –
• oadrCurrent –
• oadrDataQuality –
• oadrDeviceClass – Device Class target – выкарыстоўвайце толькі endDeviceAsset.
• oadrEvent – Аб'ект, які змяшчае падзею адказу на патрабаванне
• oadrExtension –
• oadrExtensionName –
• oadrExtensions –
• oadrHttpPullModel – Лагічнае значэнне, якое паказвае, ці хоча VEN выкарыстоўваць мадэль абмену па выцягванні
• oadrInfo – Пара ключавых значэнняў рэгістрацыйнай інфармацыі для канкрэтнай службы
• oadrKey –
• oadrLevelOffset –
• oadrLoadControlState –
• oadrManualOverride – Калі ісціна, кантроль загрузкі быў адменены ўручную
• oadrMax –
• oadrMaxPeriod – Максімум сampпрацяглы перыяд
• oadrMin –
• oadrMinPeriod – Мінімум сampпрацяглы перыяд
• oadrNormal –
• oadrOnChange – Калі ісціна, то даныя будуць запісвацца, калі яны змяняюцца, але не часцей, чым вызначана minPeriod.
• oadrOnline – Калі ісціна, то рэсурс/аб'ект у сетцы, калі ілжыва, то па-за сеткай.
• oadrPayload –
• oadrPayloadResourceStatus – Інфармацыя аб бягучым стане рэсурсу
• oadrPendingReports – Спіс перыядычных справаздач па-ранейшаму актыўны
• oadrPercentOffset –
• oadrProfile - Прафесіяналfile падтрымліваецца VEN або VTN
• oadrProfileімя - OpenADR profile імя, напрыклад 2.0a або 2.0b.
• oadrProfileс - OpenADR profiles падтрымліваецца рэалізацыяй
• oadrReport -Аб'ект, які змяшчае ўсю інфармацыю для аднаго справаздачы
• oadrReportDescription – Апісанне характарыстык справаздачы, прапанаваных вытворцам справаздачы. Змяшчаецца ў справаздачы аб метададзеных
• oadrReportOnly – ReportOnlyDeviceFlag
• oadrReportPayload – Значэнні кропак даных для справаздач
• oadrRequestedOadrPollFreq – VEN павінен адпраўляць карысную нагрузку oadrPoll у VTN не больш за адзін раз за кожную працягласць, вызначаную гэтым элементам
• oadrResponseRequired – Кантралюе, калі патрабуецца адказ OptIn/OptOut. Можа быць заўсёды або ніколі
• oadrSamplingRate – Sampхуткасць лінга для дадзеных тыпу тэлеметрыі
• oadrService –
• oadrServiceName – Гэты тып мэты выкарыстоўваецца для падзей, справаздач і раскладаў выбараў. Значэнне, як правіла, прысвойваецца ўтылітай падчас рэгістрацыі ў праграме DR
• oadrServiceSpecificInfo – Рэгістрацыйная інфармацыя для канкрэтнай службы
• oadrSetPoint –
• oadrSignedObject –
• oadrTransport – Імя транспарту, якое падтрымліваецца VEN або VTN
• oadrTransportAddress – Каранёвы адрас, які выкарыстоўваецца для сувязі з іншым бокам. Пры неабходнасці трэба ўключыць порт
• oadrTransportName – Назва транспарту OpenADR, напрыклад, simpleHttp або xmpp
• oadrTransports – Транспарты OpenADR падтрымліваюцца рэалізацыяй
• oadrUpdatedReport – Пацвердзіць атрыманне справаздачы
• oadrUpdateReport – Адправіць запытаную раней справаздачу
• oadrValue –
• oadrVenName – ВЕН імя. Можа выкарыстоўвацца ў VTN GUI
• oadrXmlSignature – Рэалізацыя падтрымлівае подпіс XML
• optID – Ідэнтыфікатар для ўзаемадзеяння opt
• optReason - Пералічанае значэнне для прычыны выбару, напрыклад, расклад X
• optType – optIn або optOut падзеі, або выкарыстоўваецца для ўказання тыпу раскладу выбару, вызначанага ў vavailablityObject для службы EiOpt
• partyID – Гэты тып мэты выкарыстоўваецца для падзей, справаздач і раскладаў выбараў. Значэнне, як правіла, прысвойваецца ўтылітай падчас рэгістрацыі ў праграме DR
• карысная нагрузкаFloat - Значэнне кропкі даных для сігналаў падзей або для паведамлення аб бягучых або гістарычных значэннях.
• вузел - Вузел цэнаўтварэння непасрэдна звязаны з вузлом падключэння. Гэта цэнавае месца, для якога ўдзельнікі рынку падаюць свае заяўкі, прапановы, купляюць/прадаюць CRR і разлічваюцца.
• pointOfDelivery –
• pointOfReceipt –
• posList –
• powerApparent – Уяўная магутнасць, вымераная ў вольтахampЭрэс (Віргінія)
• powerAttributes
• powerItem
• PowerReactive - Рэактыўная магутнасць, вымераная ў вольтахampэрэс рэактыўны (VAR)
• powerReal - Рэальная магутнасць вымяраецца ў ватах (Вт) або джоўлях/секунду (Дж/с)
• прыярытэт - Прыярытэт падзеі ў адносінах да іншых падзей (чым меншы лік, тым большы прыярытэт. Значэнне нуль (0) азначае адсутнасць прыярытэту, што з'яўляецца самым нізкім прыярытэтам па змаўчанні).
• ўласцівасці –
• pulseCount – Кропка справаздачных даных
• pulseFactor - кВт.гадз на адлік
• кваліфікаваны ідэнтыфікатар падзеі – Унікальны ідэнтыфікатар падзеі
• тып чытання - Метададзеныя аб паказаннях, такія як сярэдняе або вытворнае
• рэгістрацыйны ідэнтыфікатар – Ідэнтыфікатар транзакцыі рэгістрацыі. Не ўключаецца ў адказ на рэгістрацыю запыту, калі яшчэ не зарэгістравана
• replyLimit – Максімальная колькасць падзей для вяртання ў карыснай нагрузцы oadrDistributeEvent
• ReportBackDuration – Давайце справаздачу аб кожным праходжанні гэтай Працягласці.
• ReportDataSource - Крыніцы дадзеных у гэтай справаздачы. напрыкладamples ўключаюць метры або субметры. Напрыкладampнапрыклад, калі лічыльнік здольны забяспечваць два розныя тыпы вымярэнняў, то кожны паток вымярэнняў будзе вызначацца асобна.
• ReportInterval - Гэта агульны перыяд справаздачнасці.
• Назва справаздачы – Неабавязковая назва для справаздачы.
• reportRequestID – Ідэнтыфікатар для канкрэтнага запыту справаздачы
• ReportSpecifier – Укажыце неабходныя пункты даных у асобным асобніку справаздачы
• reportSpecifierID – Ідэнтыфікатар для канкрэтнай спецыфікацыі справаздачы аб метаданых
• Тэма справаздачы – Device Class target – выкарыстоўвайце толькі endDeviceAsset.
• справаздача для сачэння - Паказвае, ці трэба вяртаць справаздачу (у форме UpdateReport) пасля адмены справаздачы
• reportType – Тып справаздачы, напрыклад, выкарыстанне або цана
• ID запыту – Ідэнтыфікатар, які выкарыстоўваецца для супастаўлення запыту лагічнай транзакцыі і адказу
• ID рэсурсу – Гэты тып мэты выкарыстоўваецца для падзей, справаздач і раскладаў выбараў. Значэнне, як правіла, прысвойваецца ўтылітай падчас рэгістрацыі ў праграме DR
• адказ –
• код адказу – 3-значны код адказу
• адказАпісанне - Апісанне стану адказу
• адказы –
• rID - ReferenceID для гэтай кропкі даных
• serviceArea – Гэты тып мэты выкарыстоўваецца для падзей, справаздач і раскладаў выбараў. Значэнне, як правіла, прысвойваецца ўтылітай падчас рэгістрацыі ў праграме DR
• serviceDeliveryPoint – Лагічная кропка ў сетцы, дзе права ўласнасці на паслугу пераходзіць з рук у рукі. Гэта адзін з патэнцыйна многіх пунктаў абслугоўвання ў ServiceLocation, які забяспечвае абслугоўванне ў адпаведнасці з CustomerAgreement. Выкарыстоўваецца ў месцы ўстаноўкі лічыльніка.
• ServiceLocation - ServiceLocation кліента мае адзін або некалькі пунктаў ServiceDeliveryPoint, якія, у сваю чаргу, звязаны з лічыльнікамі. Размяшчэнне можа быць кропкай або шматкутнікам, у залежнасці ад канкрэтных абставінаў. Для распаўсюджвання ServiceLocation звычайна з'яўляецца месцазнаходжаннем памяшкання кліента камунальнай службы.
• ідэнтыфікатар сігналу - унікальны ідэнтыфікатар для пэўнага сігналу падзеі
• імя сігналу – Назва сігналу, напрыклад SIMPLE
• signalPayload - Значэнні сігналаў для падзей і базавых ліній
• siScaleCode – Каэфіцыент маштабавання для базавай адзінкі вымярэння для справаздачы
• specifierPayload – Адкрыты
• пачаць пасля – Акно рандомізацыі для пачатку падзеі
• statusDateTime – Дата і час, на якія спасылаецца гэты артэфакт.
• тэмпература –
• testEvent - Усё, акрамя false, азначае тэставую падзею
• тэкст –
• тэрм –
• талерантнасць - Падаб'ект, які змяшчае патрабаванні рандомізацыі для падзеі
• цярпець – Аб’ект, які змяшчае патрабаванні рандомізацыі для падзеі
• транспартны інтэрфейс - Транспартны інтэрфейс акрэслівае краю на абодвух канцах транспартнага сегмента.
• uid - Выкарыстоўваецца як індэкс для ідэнтыфікацыі інтэрвалаў. Унікальны ідэнтыфікатар
• значэнне –
• даступнасць - Расклад, які адлюстроўвае даступнасць прылады для ўдзелу ў мерапрыемствах DR
• venID – Унікальны ідэнтыфікатар для VEN
• абtage –
• vtnComment – Любы тэкст
• vtnID – Унікальны ідэнтыфікатар для VTN
• x-eiNotification – VEN павінен атрымаць карысную нагрузку падзеі DR да dtstart мінус гэтая працягласць.
• х-ЭІРampУверх - Працягласць часу да або пасля пачатку падзеі, на працягу якога павінна адбыцца падзенне нагрузкі.
• x-eiRecovery – Працягласць да або пасля заканчэння падзеі, падчас якой павінна адбывацца скід нагрузкі.

 

Слоўнік пералічаных значэнняў

Статус падзеі

• актыўны – Мерапрыемства было ініцыявана і зараз дзейнічае.
• адменены – Мерапрыемства адменена.
• завершаны – Мерапрыемства завершана.
• далёка – Падзея чакаецца ў далёкай будучыні. Дакладнае вызначэнне таго, наколькі далёка ў будучыні гэта адносіцца, залежыць ад рынкавага кантэксту, але звычайна азначае наступны дзень.
• побач – Падзея чакаецца ў бліжэйшы час. Дакладнае вызначэнне таго, наколькі блізка ў будучыні незавершаная падзея актыўная, залежыць ад рынкавага кантэксту. .Пачынаецца адначасова з эфектыўным пачаткам падзеі x-eiRampЧас. Калі x-eiRampUp не вызначана для падзеі, гэты статус не будзе выкарыстоўвацца для падзеі.
• ні адзін – Няма чаканых падзей

пунктАдзінкі

• Валюта
  • даляраў ЗША – Долары ЗША
  • Для многіх, каб пералічыць тут, звярніцеся да схемы
• powerReal
  • Дж/с – Джоўль-секунда
  • W – Ватс
• тэмпература
  • па Цэльсіі –
  • Фарэнгейта –

oadrDataQuality

• Няма новага значэння - выкарыстоўваецца папярэдняе значэнне –
• Няма якасці – няма каштоўнасці –
• Дрэнная якасць – збой сувязі –
• Дрэнная якасць – Памылка канфігурацыі –
• Дрэнная якасць - няспраўнасць прылады –
• Дрэнная якасць – апошняе вядомае значэнне –
• Дрэнная якасць – неспецыфічны –
• Дрэнная якасць – не падключана –
• Дрэнная якасць – не працуе –
• Дрэнная якасць – няспраўнасць датчыка –
• Якасць добрая - мясцовае перавызначэнне –
• Якасць добрая - неспецыфічная –
• Абмежаванне якасці – поле/канстанта –
• Абмежаванне якасці – поле/высокае –
• Абмежаванне якасці – поле/нізкі –
• Абмежаванне якасці – поле/не –
• Якасць нявызначаная – адзінкі ЕС перавышаны –
• Якасць нявызначаная – апошняя карысная вартасць –
• Якасць няпэўная – неспецыфічная –
• Якасць няпэўная – датчык недакладны –
• Якасць нявызначаная – ніжэй за норму –

oadrResponseRequired

• заўсёды – Заўсёды адпраўляйце адказ на кожную атрыманую падзею.
• ніколі — Ніколі не адказвай.

optReason

Пералічаныя прычыны выбару.

• эканамічныя –
• надзвычайная сітуацыя –
• mustRun –
• не ўдзельнічае –
• outageRunStatus –
• overrideStatuс -
• якія ўдзельнічаюць –
• х-расклад –

oadrTransportName

• простыHttp –
• xmpp –

OptType

• выбраць – Паказчык таго, што VEN будзе ўдзельнічаць у мерапрыемстве, або ў выпадку службы EiOpt тып раскладу, які паказвае, што рэсурс будзе даступны
• адмовіцца – Паказчык таго, што VEN не будзе ўдзельнічаць у мерапрыемстве, або ў выпадку службы EiOpt тып раскладу, які паказвае, што рэсурс будзе недаступны

readingType

• Выдзелены – Лічыльнік ахоплівае некалькі [рэсурсаў], і выкарыстанне вызначаецца праз нейкае прафесійнае вылічэнне даных.
• Кантракт – Паказвае, што чытанне з'яўляецца праформа, г. зн., паведамляецца па ўзгодненых стаўках
• Вытворны – Выкарыстанне робіцца на аснове ведаў аб часе выканання, нармальнай працы і г.д.
• Прамое чытанне – Чытанне счытваецца з прылады, якое манатонна павялічваецца, і выкарыстанне павінна быць вылічана з пар пачатковых і канчатковых паказанняў.
• Ацэначна – Выкарыстоўваецца, калі паказанне адсутнічае ў серыі, у якой прысутнічае большасць паказанняў.
• Гібрыд – Калі агрэгавана, адносіцца да розных тыпаў чытання ў агульным ліку.
• Сярэдні – Счытванне - гэта сярэдняе значэнне за перыяд, указаны ў дэталізацыі
• Сетка – Лічыльнік або [рэсурс] рыхтуе ўласны разлік агульнага выкарыстання з цягам часу.
• Пікавая – Чытанне з'яўляецца пікавым (самым высокім) значэннем за перыяд, указаны ў дэталізацыі. Для некаторых вымярэнняў гэта можа мець больш сэнсу як самае нізкае значэнне. Можа не адпавядаць сукупным паказанням. Дзейнічае толькі для баз прадметаў хуткасці патоку, г.зн. для магутнасці, а не для энергіі.
• Праектаваны – Паказвае, што паказанні будуць у будучыні і яшчэ не вымяраліся.
• Падсумаваў – Некалькі лічыльнікаў разам даюць паказанні для гэтага [рэсурсу]. Гэта асабліва адрозніваецца ад агрэгаванага, які адносіцца да некалькіх [рэсурсаў] у адной карыснай нагрузцы. Глядзіце таксама Гібрыд.
• х-недастасавальна - Не ўжываецца
• x-RMS – Сярэднеквадратычны

reportName

• HISTORY_GREENBUTTON – Справаздача, якая змяшчае дадзеныя зялёнай кнопкі ў структуры схемы падачы атамаў
• HISTORY_USAGE – Справаздача, якая змяшчае гістарычныя дадзеныя аб спажыванні энергіі
• METADATA_HISTORY_GREENBUTTON – Справаздача аб метададзеных, якая вызначае магчымасці справаздачнасці для справаздач HISTORY_GREENBUTTON
• METADATA_HISTORY_USAGE – Справаздача аб метададзеных, якая вызначае магчымасці справаздачнасці для справаздач HISTORY_USAGE
• METADATA_TELEMETRY_STATUS – Справаздача аб метададзеных, якая вызначае магчымасці справаздачнасці для справаздач TELEMETRY_STATUS
• METADATA_TELEMETRY_USAGE – Справаздача аб метададзеных, якая вызначае магчымасці справаздачнасці для справаздач TELEMETRY_USAGE
• TELEMETRY_STATUS – Справаздача, якая змяшчае інфармацыю аб стане рэсурсу ў рэжыме рэальнага часу, напрыклад, стан у рэжыме онлайн
• TELEMETRY_USAGE – Справаздача, якая змяшчае інфармацыю аб выкарыстанні энергіі ў рэжыме рэальнага часу

reportType

Пералічанае значэнне, якое паказвае тып справаздачы.

• даступны EnergyStorage – Даступная ёмістасць для далейшага захоўвання энергіі, магчыма, каб дабрацца да Target Energy Storage
• сярэдні попыт – Сярэдняе выкарыстанне на працягу перыяду, пазначанага дэталізацыяй. Глядзіце попыт для атрымання дадатковай інфармацыі.
• сярэдняе выкарыстанне – Сярэдняе выкарыстанне на працягу перыяду, пазначанага дэталізацыяй. Глядзіце выкарыстанне для атрымання дадатковай інфармацыі.
• базавая лінія – Можа быць попытам або выкарыстаннем, як паказвае ItemBase. Паказвае, што было б [вымярэнне], калі б не падзея або правіла. Справаздача мае фармат Baseline.
• deltaDemand – Змена попыту ў параўнанні з базавым узроўнем. Глядзіце попыт для атрымання дадатковай інфармацыі
• deltaSetPoint – Змены ў зададзеным значэнні ў параўнанні з папярэднім графікам.
• deltaUsage – Змена выкарыстання ў параўнанні з базавым узроўнем. Глядзіце выкарыстанне для атрымання дадатковай інфармацыі
• попыт – Справаздача паказвае колькасць адзінак (намінаваных у ItemBase або ў прадукце EMIX). Тып карыснай нагрузкі - Колькасць. Тыповая ItemBase - гэта Real Power.
• адхіленне – Розніца паміж некаторымі інструкцыямі і фактычным станам.
• downRegulationCapacityAvailable – Ёмістасць паніжальнага рэгулявання, даступная для адпраўкі, выражаная ў EMIX Real Power. Карысная нагрузка заўсёды выяўляецца як станоўчая колькасць.
• ўзровень – Просты ўзровень з рынку на кожным інтэрвале.
• працоўны стан – Абагульнены стан рэсурсу, напрыклад, уключаны/выключаны, занятасць будынка і г. д. Ніякая база элементаў не мае значэння. Патрабуецца пашырэнне карыснай нагрузкі для канкрэтнага прыкладання.
• працэнтны попыт – Працэнтtagе попыту
• працэнт выкарыстання – Працэнтtagе выкарыстання
• каэфіцыент магутнасці – Каэфіцыент магутнасці для рэсурсу
• цана – Цана за ItemBase на кожным інтэрвале
• чытанне – Справаздача паказвае паказанні, як з лічыльніка. Паказанні - гэта моманты ў часе - змены ў часе можна вылічыць з розніцы паміж паслядоўнымі паказаннямі. Тып карыснай нагрузкі - float
• рэгуляваннеЗададзенае значэнне – Зададзенае значэнне рэгулявання ў адпаведнасці з інструкцыямі ў рамках паслуг рэгулявання
• зададзенае значэнне – У справаздачы паказваецца сума (вызначаная ў ItemBase або ў прадукце EMIX), усталяваная ў цяперашні час. Можа быць пацверджанне/вяртанне кантрольнага значэння ўстаўкі, адпраўленае з VTN. Тып карыснай нагрузкі - Колькасць. Тыповая ItemBase - гэта Real Power.
• назапашанаяэнергія – Назапашаная энергія выяўляецца як рэальная энергія, а карысная нагрузка - як колькасць.
• targetEnergyStorage – Мэтавая энергія выяўляецца як рэальная энергія, а карысная нагрузка - як колькасць.
• upRegulationCapacityAvailable – Ёмістасць Up Regulation, даступная для адпраўкі, выражаная ў EMIX Real Power. Карысная нагрузка заўсёды выяўляецца як станоўчая колькасць.
• выкарыстанне – Справаздача паказвае колькасць адзінак (намінаваных у ItemBase або ў прадукце EMIX) за перыяд. Тып карыснай нагрузкі - Колькасць. Тыповая ItemBase - гэта RealEnergy
• x-resourceStatus – Працэнтtagе попыту

scaleCode

• p – Піка 10**-12
• n – Nano 10**-9
• мікра – Мікра 10**-6
• m – Мілі 10**-3
• c – Цэнці 10**-2
• d – Дэцы 10**-1
• k – Кіла 10**3
• M – Мега 10**6
• G – Гіга 10**9
• T – Тэра 10**12
• ні адзін – Родны маштаб

імя сігналу

• БІД_ЭНЕРГІЯ – Гэта колькасць энергіі з рэсурсу, які быў заяўлены ў праграму
• BID_LOAD – Гэта колькасць нагрузкі, якую рэсурс зрабіў на праграму
• BID_PRICE – Гэта тая цана, якую запрасіў рэсурс
• CHARGE_STATE – Стан рэсурсу захоўвання энергіі
• DEMAND_CHARGE – Гэта плата за попыт
• ЭЛЕКТРЫЧНАСЦЬ_PRICE – Гэта кошт электраэнергіі
• ENERGY_PRICE – Гэта кошт энергіі
• LOAD_CONTROL -Устанавіць выхад нагрузкі на адносныя значэнні
• LOAD_DISPATCH – Гэта выкарыстоўваецца для адпраўкі грузу
• простая – амартызаваны – для зваротнай сумяшчальнасці з A profile
• ПРОСТА - Простыя ўзроўні (сумяшчальны з OpenADR 2.0a)

сігналТып

Пералічанае значэнне, якое апісвае тып сігналу, напрыклад узровень або цана

• дэльта – Сігнал паказвае суму, якую трэба змяніць ад таго, што можна было б выкарыстоўваць без сігналу.
• ўзровень – Сігнал паказвае ўзровень праграмы.
• памнажацьr – Сігнал паказвае множнік, прыменены да бягучай хуткасці дастаўкі або выкарыстання ад таго, што можна было б выкарыстоўваць без сігналу.
• цана – Сігнал паказвае цану.
• PriceMultiplier – сігнал паказвае множнік кошту. Пашыраная цана - гэта вылічанае значэнне цаны, памножанае на колькасць адзінак.
• priceRelative – Сігнал паказвае адносную цану.
• зададзенае значэнне – Сігнал паказвае мэтавую колькасць адзінак.
• x-loadControlCapacity – Гэта інструкцыя, каб кантролер нагрузкі працаваў на ўзроўні, які складае некалькі працэнтаўtage яго максімальнай нагрузачнай здольнасці. Гэта можа быць адлюстравана на пэўных кантролерах нагрузкі, каб рабіць такія рэчы, як цыклы працы. Звярніце ўвагу, што 1.0 адносіцца да 100% спажывання. У выпадку простых прылад тыпу ON/OFF тады 0 = OFF і 1 = ON.
• x-loadControlLevelOffset – Дыскрэтныя цэлыя ўзроўні, якія адносяцца да звычайных аперацый, дзе 0 - звычайныя аперацыі.
• x-loadControlPercentOffset – Працэнтtage змена звычайных аперацый кантролю нагрузкі.
• x-loadControlSetpoint – Зададзеныя значэння кантролера нагрузкі.

– OpenADR A і B Profile Адрозненні

Адзіны сэрвіс, які падтрымліваецца A profile гэта сэрвіс EiEvent. Аб'ект EiEvent спрошчаны ў A profile з наступнымі абмежаваннямі:

• Дазваляецца толькі адзін сігнал на падзею, і гэты сігнал павінен быць вядомым сігналам OpenADR SIMPLE.
• Існуе абмежаванае таргетынг падзей з падтрымкай толькі venID, groupID, resourceID і partyID.(eiEvent:eiTarget).
• Таргетынг на ўзроўні сігналу з дапамогай класаў прылад не падтрымліваецца (eiEventSignal:eiTarget:endDeviceAsset).
• Базавыя паказчыкі не падтрымліваюцца (eiEvent:eiEventSignals:eiEventBaseline).
• modificationDateTime і modificationReason не падтрымліваюцца.
• Канчатковы пункт URL для простага HTTP ў 2.0b гэта:
  • https://<hostname>(:port)/(prefix/)OpenADR2/Simple/2.0b/<service>

Некаторыя элементы карыснай нагрузкі, неабходныя ў A profile цяпер неабавязковыя ў B profile, у тым ліку:

• бягучаеЗначэнне

– Сертыфікаты бяспекі OpenADR

Правілы адпаведнасці OpenADR патрабуюць наступнага:

• TLS версіі 1.2 выкарыстоўваецца для абмену сертыфікатамі X.509
• VTN павінны мець сертыфікаты SHA256 ECC і RSA
• VEN могуць падтрымліваць сертыфікаты SHA256 ECC і RSA, і могуць падтрымліваць абодва
• І VTN, і VEN павінны быць настроены на запыт кліенцкіх сертыфікатаў, калі яны збіраюцца гуляць ролю транспартнага сервера (г.зн. адказваць на запыты іншага боку)
• І VTN, і VEN павінны прадастаўляць кліенцкі сертыфікат па запыту іншага боку ў рамках працэсу ўзгаднення TLS

Сертыфікаты, прадастаўленыя NetworkFX, будуць спецыфічнымі для RSA або ECC. Стварэнне гэтых сертыфікатаў можа адбыцца ў выніку запаўнення формаў у NetworkFX web сайт для запыту сертыфікатаў выпрабаванняў або можа быць вынікам запыту сертыфікатаў вытворчасці праз запыт на подпіс сертыфіката (CSR). Незалежна ад спосабу, наступнае files будзе прадастаўлена (напрampпаказаны файлы):

• Каранёвы сертыфікат
• Прамежкавы каранёвы сертыфікат
• Сертыфікат прылады
• Закрыты ключ

Увогуле, прыватны ключ выкарыстоўваецца для шыфравання карысных нагрузак, адпраўленых VEN або VTN. Сертыфікат прылады - гэта набор унікальнай ідэнтыфікацыйнай інфармацыі аб VEN або VTN, які быў створаны цэнтрам сертыфікацыі і зашыфраваны з дапамогай закрытага ключа. Корань і прамежкавы files выкарыстоўваюцца для расшыфроўкі сертыфіката прылады і праверкі таго, што сертыфікат паходзіць ад даверанай арганізацыі.

У асяроддзі Java, якое выкарыстоўвае JSSE, ёсць два сховішчы сертыфікатаў. Адзін з іх называецца Trust Store і выкарыстоўваецца для захоўвання каранёвага сертыфіката. Другі называецца сховішчам ключоў і выкарыстоўваецца для захоўвання ланцужка сертыфікатаў, які складаецца з прамежкавага сертыфіката сертыфіката прылады, а таксама прыватнага ключа

Звярніце ўвагу, што пры выкарыстанні транспарту XMPP VEN звязваецца з серверам XMPP, а НЕ непасрэдна з VTN. Такім чынам, канфігурацыя сертыфікатаў на серверы XMPP ПАВІННА быць эквівалентнай VTN. Сувязь паміж самой VTN і серверам XMPP празрыстая для VEN і па сутнасці з'яўляецца прыватнай спасылкай. Тым не менш, большасць пастаўшчыкоў выкарыстоўвалі набор сертыфікатаў VEN у VTN пры сувязі з серверам XMPP.

Калі вы выкарыстоўваеце OpenFire у якасці сервера XMPP, ёсць яшчэ адно абмежаванне, якое вы павінны ўлічваць. OpenFire патрабуе, каб імя CN, якое выкарыстоўваецца ў сертыфікатах кліенцкіх прылад, супадала з імем карыстальніка прылады XMPP, наладжаным на серверы XMPP. Гэта можа прывесці да некаторых дзіўных імёнаў кліентаў, паколькі MAC-адрас выкарыстоўваецца для імя CN у сертыфікатах VEN (частка патрабаванняў бяспекі OpenADR)

Нарэшце, большасць VEN і VTN, выконваючы ролю транспартнага кліента, будуць спрабаваць пацвердзіць, што поле CN сертыфіката, прадастаўленага транспартным серверам, мае імя CN, якое супадае з імем хаста суб'екта, які выдаў сертыфікат. Гэта можа быць яшчэ адной крыніцай праблем сумяшчальнасці пры абмене сертыфікатамі. Праверку імя хоста звычайна можна адключыць праграмна, каб ізаляваць такія праблемы.

Кіраўніцтва па праграме OpenADR 2.0 Demand Response – Спампаваць [аптымізавана]
Кіраўніцтва па праграме OpenADR 2.0 Demand Response – Спампаваць

Спасылкі

• Кіраўніцтва карыстальніка